Scheduling enhancements for transmit opportunity sharing

Abstract

The present disclosure provides methods, components, devices, and systems for transmit opportunity (TXOP) sharing (TXS) enhancements. In some cases, a first wireless node may transmit a first frame configured to allow a third wireless node to transmit to a second wireless node during a transmit opportunity (TXOP) shared with the second wireless node; and preventing transmission from the fourth wireless node during the shared TXOP.

Description

Cross Reference to Related Applications

[0001] This application claims priority to U.S. Patent Application No. 18 / 314,797, filed May 9, 2023, and U.S. Patent Application No. 18 / 314,804, filed May 9, 2023, both of which are assigned to the assignee hereof and hereby expressly incorporated by reference in their entirety as if fully set forth below and for all applicable purposes. TECHNICAL FIELD

[0002] The present disclosure relates generally to wireless communication, and more specifically to techniques for scheduling transmit opportunity (TXOP) sharing scenarios. BACKGROUND

[0003] A wireless local area network (WLAN) can be formed by one or more wireless access points (APs) that provide a shared wireless communication medium for use by multiple client devices, also referred to as wireless stations (STAs). The basic building block of a WLAN that adheres to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards is a basic service set (BSS), which is managed by an AP. Each BSS is identified by a basic service set identifier (BSSID) that is advertised by the AP. The AP periodically broadcasts beacon frames to enable any STAs within wireless range of the AP to establish or maintain a communication link with the WLAN. SUMMARY

[0004] The systems, methods, and devices of the present disclosure each have several innovative aspects, none of which is, by itself, responsible for the desirable attributes disclosed herein.

[0005] One innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communications at a first wireless node. The apparatus includes a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the first wireless node to output, for transmission, a first frame configured to allow a third wireless node to transmit to a second wireless node during a transmit opportunity (TXOP) shared with the second wireless node and to prevent transmissions from a fourth wireless node during the shared TXOP; and perform one or more actions during the shared TXOP.

[0006] Another innovative aspect of the subject matter described in this disclosure can be implemented at an apparatus for wireless communications at a second wireless node. The apparatus includes a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the second wireless node to obtain a first frame configured to allow a third wireless node to transmit to the second wireless node and to prevent transmission from a fourth wireless node during a transmit opportunity (TXOP) shared by a first wireless node and the second wireless node, and to perform one or more actions during the shared TXOP.

[0007] Another innovative aspect of the subject matter described in this disclosure can be implemented at an apparatus for wireless communications at a wireless node. The apparatus includes a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the wireless node to output, for transmission, a first frame including a request for a network allocation vector (NAV) setting associated with a shared transmit opportunity (TXOP), obtain a second frame triggering the shared TXOP, and communicate during the shared TXOP with the NAV set in accordance with the request.

[0008] Another innovative aspect of the subject matter described in this disclosure can be implemented at an apparatus for wireless communications at a wireless node. The apparatus includes a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the wireless node to obtain a first frame including a request for a network allocation vector (NAV) setting associated with a shared transmit opportunity (TXOP), output a second frame triggering the shared TXOP, and communicate during the shared TXOP in accordance with the request.

[0009] Details of one or more specific embodiments of the subject matter described in this disclosure are set forth in the accompanying drawings and description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. Note that the relative dimensions of the following figures can not be drawn to scale. BRIEF DESCRIPTION OF DRAWINGS

[0010] FIG. 1 A schematic diagram illustrating an example wireless communication network is shown.

[0011] FIG. 2 An example protocol data unit (PDU) that can be used for communication between a wireless access point (AP) and one or more wireless stations (STAs) is shown.

[0012] FIG. 3A layered format of an example physical layer PDU (PPDU) usable for communications between a wireless AP and one or more wireless STAs is shown.

[0013] FIG. 4 A diagram illustrating another example wireless communication network is shown.

[0014] FIG. 5 An example scenario in which TXOP sharing can be utilized is shown.

[0015] FIG. 6 An example scenario in which TXOP sharing can be utilized is shown.

[0016] FIG. 7 A timing diagram illustrating an example of TXOP sharing is shown.

[0017] FIG. 8 A timing diagram illustrating an example of TXOP sharing with NAV setting according to certain aspects of the present disclosure is shown.

[0018] FIG. 9A And FIG. 9B A diagram illustrating an example shared TXOP scenario with NAV setting mechanism according to certain aspects of the present disclosure is shown.

[0019] FIG. 10 An example frame format according to certain aspects of the present disclosure is shown.

[0020] FIG. 11 A timing diagram illustrating an example of TXOP sharing with NAV setting according to certain aspects of the present disclosure is shown.

[0021] FIG. 12 A timing diagram illustrating an example of TXOP sharing with NAV setting according to certain aspects of the present disclosure is shown.

[0022] FIG. 13 An example frame format according to certain aspects of the present disclosure is shown.

[0023] FIG. 14 A flow diagram illustrating an example process that can be performed by a first wireless node configured as an AP is shown.

[0024] FIG. 15 A flow diagram illustrating an example process that can be performed by a second wireless node configured as a STA is shown.

[0025] FIG. 16 A flow diagram illustrating an example process that can be performed by a first wireless node configured as an AP is shown.

[0026] FIG. 17A flowchart illustrating an example process that can be performed by a second wireless node configured as a STA is shown.

[0027] FIG. 18 A block diagram of an example wireless communication device is shown.

[0028] The same reference numbers and designations in different drawings represent the same elements. DETAILED DESCRIPTION

[0029] The following description relates to certain specific examples and is not intended as limiting—only the claims are limiting. The following description can use directional adjectives, such as “vertical,” “horizontal,” “left,” “right,” “up,” “down,” “top,” “bottom,” “lateral,” “medial,” “superior,” “inferior,” “superior,” “inferior,” “proximal,” “distal,” “clockwise,” “counter clockwise,” “radial,” “axial,” “lateral,” “medial,” “anterior,” “posterior,” “superior,” “inferior,” “interior,” “exterior,” “inner,” “outer,” “end,” “edge,” “side,” “corner,” “face,” “front,” “back,” “port,” “starboard,” “portside,” “starboard side,” “portside,” “starboard side,” “port” and “stboard,” that can be used to describe the orientation or position of one element relative to another element. These adjectives are not intended to limit the component, object or spatial relationship to which they are applied, but instead provide a relative spatial description. It is further recognized that the orientation or position of an element can be described in multiple directions, such as a “left side” and a “right side.” The orientation or position of an element can also be described in terms of movement, such as “upwardly moving” or “downwardly moving.” These directional adjectives are not intended to limit the movement of the element to which they are applied, but instead provide a relative spatial description. ® The described examples can be implemented in any device, system or network that is capable of transmitting and receiving radio frequency (RF) signals according to one or more of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards, the IEEE 802.15 standards, the Bluetooth® standards as defined by the Bluetooth Special Interest Group (SIG), the Long Term Evolution (LTE), 3G, 4G or 5G (New Radio (NR)) standards published by the 3rd Generation Partnership Project (3GPP), among others. The described examples can be implemented in any device, system or network that is capable of transmitting and receiving RF signals according to one or more of the following technologies or techniques: code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), space division multiple access (SDMA), rate- spreading multiple access (RSMA), multi-user shared access (MUSA), single-user (SU) multiple-input multiple-output (MIMO) and multi-user (MU) MIMO. The described examples can also be implemented using other wireless communication protocols or RF signals suitable for use in one or more of a wireless personal area network (WPAN), a wireless local area network (WLAN), a wireless wide area network (WWAN), a wireless metropolitan area network (WMAN) or an Internet of Things (IOT) network.

[0030] Various aspects generally relate to wireless communication. Some aspects more specifically relate to techniques for determining a network allocation vector (NAV) for a shared transmit opportunity (TXOP).

[0031] TXOP sharing generally refers to a mechanism that allows a station that has obtained a TXOP (e.g., has gained access to the wireless medium for a certain duration) (referred to herein as a TXOP sharing station) to share a portion of the TXOP with another station (referred to herein as a TXOP shared station). For example, an access point (AP) can share a TXOP with another AP, an AP can share a TXOP with a non-AP station (STA), or a STA can share a TXOP with another STA. In some cases, a (non-AP) STA can also share a TXOP with an AP. As used herein, the term STA can refer to an AP STA or a non-AP STA. However, for convenience, an AP STA can sometimes be referred to herein simply as an AP, and a non-AP STA can sometimes be referred to simply as a STA.

[0032] A shared TXOP can be triggered by the transmission of some type of frame, e.g., a frame that indicates the recipient (station sharing the TXOP) and the duration. This type of triggered TXOP sharing mechanism can be used to serve low latency traffic. For example, TXOP sharing can be used to serve traffic that originates from real-time applications with strict latency requirements (e.g., 1-10 ms), such as extended reality (XR) or gaming. In a wireless network where stations contend for access to the wireless medium, meeting such strict latency requirements can be challenging.

[0033] When sharing a TXOP, a sharing AP can assume that all devices in the network have set their network allocation vector (NAV) to the duration indicated in the (triggering) frame that triggered the shared TXOP. Stations maintain one or more NAV timers that dictate when the wireless medium is considered busy or idle. A shared TXOP STA typically acknowledges receipt of the TXOP triggering frame by transmitting an allow transmit (CTS) frame, which can also serve as an indicator that other STAs should set their NAVs.

[0034] During a shared TXOP, there are potential challenges with NAV allocation. One potential challenge is how to set the NAV to the optimal duration for certain traffic needs. For example, if the NAV is set to a duration that is too long during the shared TXOP (e.g., for the entire duration of the shared TXOP), uplink traffic from another device and another device associated with the shared TXOP STA (e.g., traffic from an XR headset to a phone) can be suppressed, impacting performance and user experience. Another potential challenge is how to ensure that STAs outside the range of the shared TXOP recipient set their NAVs appropriately. For example, because the STA is outside the range, the STA can not receive the CTS from the shared TXOP STA and thus can ignore the NAV and transmit, potentially disrupting the shared TXOP.

[0035] However, aspects of the present disclosure present solutions that can be considered enhancements to NAV setting for TXOP sharing scenarios and can help address these potential challenges. Certain aspects of the present disclosure provide a signaling mechanism in which a STA can indicate (e.g., to a potential TXOP sharing AP) a particular (desired / preferred) NAV setting for a shared TXOP. For example, if a STA wishes to conduct peer-to-peer (P2P) communications during a shared TXOP, the STA can request a short NAV setting. Once the shorter NAV duration expires, the shared TXOP STA can trigger uplink traffic from a peer in the remaining portion of the shared TXOP.

[0036] Certain aspects of the present disclosure provide a mechanism that can help ensure that STAs outside the range of a shared TXOP STA can properly set their NAVs. Because such STAs are at risk of missing the CTS from the shared TXOP STA acknowledging the shared TXOP trigger frame, an additional (or alternative) frame can be transmitted from the (AP or non-AP) STA sharing the TXOP. In some cases, the frame can have a receive address (RA) set to an address associated with the shared TXOP STA, and can be designed to allow a peer to transmit to the shared TXOP STA during the shared TXOP while protecting such transmissions. For example, the frame can help ensure NAV setting at (AP or non-AP) STAs outside the range of the shared TXOP STA to prevent transmissions from the (AP or non-AP) STAs during the shared TXOP.

[0037] Thus, the NAV setting enhancements presented herein can result in better utilization of wireless resources and reduced shared TXOP interruption, which can improve performance and user experience. These techniques can improve efficiency in P2P scenarios, coordinated AP scenarios, and other types of BSS transmissions.

[0038] Example wireless communication network FIG. 1A block diagram of an example wireless communication network 100 is shown. According to some aspects, the wireless communication network 100 can be an example of a wireless local area network (WLAN) (such as a Wi-Fi network) (and will be referred to as WLAN 100 hereinafter). For example, the WLAN 100 can be a network that implements at least one of the IEEE 802.11 family of wireless communication protocol standards (such as the standards defined by the IEEE 802.11-2020 specification or revisions thereof, including but not limited to 802.11ay, 802.11ax, 802.11az, 802.11ba, 802.11bd, 802.11be, 802.11bf, and 802.11 revisions associated with Wi-Fi 8). The WLAN 100 can include numerous wireless communication devices, such as a wireless access point (AP) 102 and a plurality of wireless stations (STAs) 104. Although FIG. 1 Although only one AP 102 is shown in the middle, the WLAN network 100 can also include multiple APs 102. FIG. 1 The illustrated AP 102 can represent various different types of APs including, but not limited to, enterprise APs, single-band APs, dual-band APs, standalone APs, software-enabled APs (softAPs), and multi-link APs. The coverage area and capacity of a cellular network (such as LTE, 5G NR, etc.) can be further improved by small cells supported by APs acting as micro base stations. In addition, a private cellular network can also be established over a wireless area network using small cells.

[0039] Each of the STAs 104 can also be referred to as a mobile station (MS), a mobile device, a mobile phone, a wireless phone, an access terminal (AT), a user equipment (UE), a subscriber station (SS), or a subscriber unit, among other examples. The STAs 104 can represent various devices such as mobile phones, personal digital assistants (PDAs), other handheld devices, netbooks, notebook computers, tablet computers, laptops, Chromebooks, extended reality (XR) headsets, wearable devices, display devices (e.g., TVs including smart TVs, computer monitors, navigation systems, etc.), music or other audio or stereo devices, remote control devices (“remotes”), printers, kitchen appliances (including smart refrigerators), or other home appliances, key fobs (e.g., for passive keyless entry and start (PKES) systems), Internet of Things (IoT) devices, vehicles, etc. The various STAs 104 in the network are able to communicate with one another via the AP 102.

[0040] A single AP 102 and associated set of STAs 104 can be referred to as a basic service set (BSS), which is managed by the respective AP 102. FIG. 1An example coverage area 108 of the AP 102 is additionally shown, which can represent a basic service area (BSA) of the WLAN 100. A BSS can be identified or indicated to users by a service set identifier (SSID) and to other devices by a basic service set identifier (BSSID), which can be a medium access control (MAC) address of the AP 102. The AP 102 can periodically broadcast beacon frames (“beacons”) that include the BSSID to enable any STAs 104 within wireless range of the AP 102 to “associate” or re-associate with the AP 102 to establish a respective communication link 106 (hereinafter also referred to as a “Wi-Fi link”) with the AP 102 or to maintain a communication link 106 with the AP. For example, a beacon can include an identification or indication of a primary channel used by the respective AP 102 and a timing synchronization function to establish or maintain timing synchronization with the AP 102. The AP 102 can provide access to external networks to various STAs 104 in the WLAN via the respective communication links 106.

[0041] To establish a communication link 106 with an AP 102, each of the STAs 104 is configured to perform a passive or active scanning operation (“scanning”) on a frequency channel in one or more frequency bands (e.g., a 2.4 GHz band, a 5 GHz band, a 6 GHz band, or a 60 GHz band). To perform passive scanning, a STA 104 listens for beacons transmitted by respective APs 102 at periodic time intervals, referred to as target beacon transmission times (TBTTs) (measured in time units (TUs), where one TU can equal 1024 microseconds (µs)). To perform active scanning, a STA 104 generates and transmits probe requests in sequence on each channel to be scanned and listens for probe responses from APs 102. Each STA 104 can identify, determine, discover, or select an AP 102 with which to associate according to scanning information obtained by passive or active scanning and perform authentication and association operations to establish a communication link 106 with the selected AP 102. The AP 102 assigns an association identifier (AID) to the STA 104 at the end of the association operations, which the AP 102 uses to track the STA 104.

[0042] As wireless networks become more ubiquitous, a STA 104 can have the opportunity to select one of many BSSs within range of the STA or among multiple APs 102 that together form an extended service set (ESS), including multiple connected BSSs. An extended network station associated with the WLAN 100 can be connected to a wired or wireless distribution system that can allow for multiple APs 102 to be connected in such an ESS. Thus, a STA 104 can be covered by more than one AP 102 and can associate with different APs 102 at different times for different transmissions. Additionally, a STA 104, after associating with an AP 102, can also periodically scan its surroundings to find a more appropriate AP 102 to associate with. For example, a STA 104 that is moving relative to its associated AP 102 can perform a "roaming" scan to find another AP 102 with more desirable network characteristics, such as a greater received signal strength indicator (RSSI) or a reduced traffic load.

[0043] In some cases, a STA 104 can form a network that does not have an AP 102 or other equipment other than the STAs 104 themselves. One example of such a network is an ad hoc network (or wireless ad hoc network). An ad hoc network can alternatively be referred to as a mesh network or a peer-to-peer (P2P) network. In some cases, an ad hoc network can be implemented within a larger wireless network, such as the WLAN 100. In such examples, while the STAs 104 can be capable of communicating with each other through an AP 102 using the communication links 106, the STAs 104 can also communicate directly with each other via direct wireless communication links 110. Additionally, two STAs 104 can communicate via a direct communication link 110 regardless of whether the two STAs 104 are associated with and served by the same AP 102. In such an ad hoc system, one or more of the STAs 104 can assume the role filled by an AP 102 in a BSS. Such a STA 104 can be referred to as a group owner (GO) and can coordinate transmissions within the ad hoc network. Examples of direct wireless communication links 110 include Wi-Fi Direct connections, connections established through the use of a Wi-Fi Tunneled Direct Link Setup (TDLS) link, and other P2P group connections.

[0044] The APs 102 and STAs 104 can operate and communicate (via respective communication links 106) according to one or more of the IEEE 802.11 wireless communication protocol standards family. These standards define the WLAN radio and baseband protocol for the PHY and MAC layers. The APs 102 and STAs 104 transmit and receive wireless communications (hereinafter also referred to as “Wi-Fi communications” or “wireless packets”) to and from each other in the form of PHY protocol data units (PPDUs). The APs 102 and STAs 104 in the WLAN 100 can transmit PPDUs over an unlicensed spectrum, which can be a portion of the spectrum that includes frequency bands traditionally used by Wi-Fi technology, such as the 2.4 GHz band, the 5 GHz band, the 60 GHz band, the 3.6 GHz band, and the 900 MHz band. Some examples of the APs 102 and STAs 104 described herein can also communicate in other frequency bands that can support both licensed and unlicensed communications, such as the 5.9 GHz band and the 6 GHz band. The APs 102 and STAs 104 can also communicate over other frequency bands, such as a shared licensed band, where multiple operators can have licenses to operate in one or more of the same or overlapping bands.

[0045] Each of the frequency bands can include multiple sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11η, 802.1 lac, 802.1 lax, and 802.1 lbe standard revisions can be transmitted over a 2.4 GHz, 5 GHz, or 6 GHz band, where each band is divided into multiple 20 MHz channels. Thus, these PPDUs are transmitted over physical channels having a minimum bandwidth of 20 MHz, but larger channels can be formed through channel bonding. For example, PPDUs can be transmitted over physical channels having 40 MHz, 80 MHz, 160 MHz, or 320 MHz bandwidths by bonding together multiple 20 MHz channels.

[0046] Each PPDU is a composite structure including a PHY preamble and a payload in the form of a PHY service data unit (PSDU). The information provided in the preamble can be used by a receiving device to decode the subsequent data in the PSDU. In instances where a PPDU is transmitted over a bonded channel, the preamble fields can be repeated and transmitted in each of the multiple component channels. The PHY preamble can include both a legacy portion (or “legacy preamble”) and a non-legacy portion (or “non-legacy preamble”). The legacy preamble can be used for packet detection, automatic gain control, and channel estimation, among other uses. The legacy preamble can also generally be used to maintain compatibility with legacy devices. The format, coding, and information provided in the non-legacy portion of the preamble are associated with the particular IEEE 802.11 protocol to be used to transmit the payload.

[0047] FIG. 2 An example protocol data unit (PDU) 200 usable for wireless communication between a wireless AP 102 and one or more wireless STAs 104 is shown. For example, the PDU 200 can be configured as a PPDU. As shown, the PDU 200 includes a PHY preamble 202 and a PHY payload 204. For example, the preamble 202 can include a legacy portion that itself includes a legacy short training field (L-STF) 206, which can consist of two symbols, a legacy long training field (L-LTF) 208, which can consist of two symbols, and a legacy signal field (L-SIG) 210, which can consist of two symbols. The legacy portion of the preamble 202 can be configured according to the IEEE 802.1 la wireless communication protocol standard. The preamble 202 can also include a non-legacy portion that includes one or more non-legacy fields 212, e.g., that comply with one or more of the IEEE 802.11 family of wireless communication protocol standards.

[0048] The L-STF 206 generally enables a receiving device to perform coarse timing and frequency tracking, as well as automatic gain control (AGC). The L-LTF 208 generally enables a receiving device to perform fine timing and frequency tracking, and also to perform an initial estimate of the wireless channel. The L-SIG 210 generally enables a receiving device to determine (e.g., obtain, select, identify, detect, ascertain, derive, or calculate) a duration of the PDU and to use the determined duration to refrain from transmitting over the PDU. The legacy portion of the preamble, including the L-STF 206, the L-LTF 208, and the L-SIG 210, can be modulated according to a binary phase shift keying (BPSK) modulation scheme. The payload 204 can be modulated according to a BPSK modulation scheme, a quadrature BPSK (Q-BPSK) modulation scheme, a quadrature amplitude modulation (QAM) modulation scheme, or another appropriate modulation scheme. The payload 204 can include a PSDU that includes a data field (DATA) 214, which in turn can carry higher layer data, e.g., in the form of a MAC protocol data unit (MPDU) or an aggregated MPDU (A-MPDU).

[0049] FIG. 3A layered format of an example PPDU usable for communication between a wireless AP 102 and one or more wireless STAs 104 is shown. As described, each PPDU 300 includes a PHY preamble 302 and a PSDU 304. Each PSDU 304 can represent (or "carry") one or more MAC protocol data units (MPDUs) 316. For example, each PSDU 304 can carry an aggregated MPDU (A-MPDU) 306 that includes an aggregation of multiple A-MPDU subframes 308. Each A-MPDU subframe 306 can include an MPDU frame 310 that includes a MAC delimiter 312 and a MAC header 314 preceding an accompanying MPDU 316 that includes a data portion ("payload" or "frame body") of the MPDU frame 310. Each MPDU frame 310 can also include a frame check sequence (FCS) field 318 for error detection (e.g., the FCS field can include a cyclic redundancy check (CRC)) and padding bits 320. The MPDU 316 can carry one or more MAC service data units (MSDUs) 316. For example, the MPDU 316 can carry an aggregated MSDU (A-MSDU) 322 that includes multiple A-MSDU subframes 324. Each A-MSDU subframe 324 contains a corresponding MSDU 330 preceded by a subframe header 328 and, in some cases, followed by padding bits 332.

[0050] Referring back to the MPDU frame 310, the MAC delimiter 312 can serve as a marker of the beginning of the associated MPDU 316 and indicates the length of the associated MPDU 316. The MAC header 314 can include multiple fields containing information defining or indicating characteristics or properties of the data encapsulated within the frame body 316. The MAC header 314 includes a duration field that indicates a duration continuing from the end of the PPDU at least until the end of an acknowledgement (ACK) or block ACK (BA) to be transmitted by a receiving wireless communication device for the PPDU. The use of the duration field serves to reserve the wireless medium for the indicated duration and enables the receiving device to establish its network allocation vector (NAV). The MAC header 314 also includes one or more fields indicating addresses of the data encapsulated within the frame body 316. For example, the MAC header 314 can include a combination of source address, transmitter address, receiver address, or destination address. The MAC header 314 can also include a frame control field containing control information. The frame control field can specify a frame type, such as a data frame, a control frame, or a management frame.

[0051] Some APs and STAs can implement spatial reuse techniques that involve participating in a coordinated communication scheme. According to such techniques, an AP can contend for access to a wireless medium to gain control of the medium for a TXOP. The AP that wins contention (hereinafter also referred to as a “sharing AP”) can select one or more other APs (hereinafter also referred to as “shared APs”) to share resources of the TXOP. The sharing AP and the shared APs can be located in proximity to one another such that at least some of their wireless coverage areas at least partially overlap. Some examples can specifically involve coordinated AP TDMA or OFDMA techniques for sharing time or frequency resources of a TXOP. To share their time or frequency resources, the sharing AP can divide the TXOP into multiple time segments or frequency segments, each including respective time or frequency resources representing a portion of the TXOP. The sharing AP can allocate the time or frequency segments to the shared APs themselves or to one or more of the shared APs. For example, each shared AP can utilize the portion of the TXOP assigned by the sharing AP for uplink or downlink communications with STAs associated with it.

[0052] In some examples of such TDMA techniques, each of the multiple portions of the TXOP includes a set of time resources that do not overlap with any time resources of any other of the multiple portions. In such examples, the scheduling information can include an indication of time resources of the multiple time resources of the TXOP that are associated with each portion of the TXOP. For example, the scheduling information can include an indication of time segments of the TXOP, such as an indication of one or more slots or sets of symbol periods associated with each portion of the TXOP, such as for multi-user TDMA.

[0053] In some other examples of OFDMA techniques, each of the multiple portions of the TXOP includes a set of frequency resources that do not overlap with any frequency resources of any other of the multiple portions. In such implementations, the scheduling information can include an indication of frequency resources of the multiple frequency resources of the TXOP that are associated with each portion of the TXOP. For example, the scheduling information can include an indication of bandwidth portions of a wireless channel, such as an indication of one or more sub-channels or resource units (RUs) associated with each portion of the TXOP, such as for multi-user OFDMA.

[0054] In this way, the shared AP's acquisition of the TXOP enables communication between one or more additional shared APs and their respective BSSs with proper power control and link adaptation. For example, the shared AP can limit the transmit power of the selected shared APs such that interference from the selected APs does not prevent STAs associated with the TXOP owner from successfully decoding packets transmitted by the shared APs. Such techniques can be used to reduce latency, as the other APs can be able to transmit and receive data according to regular CSMA / CA or EDCA techniques without needing to wait to win contention for the TXOP. Additionally, by enabling a group of APs associated with different BSSs to participate in a coordinated AP transmit session during which the group of APs can share at least a portion of a single TXOP acquired by any of the participating APs, such techniques can increase throughput on the BSSs associated with the participating APs and can also enable improvements in throughput fairness. Furthermore, by proper selection of the shared APs and scheduling of their respective time or frequency resources, medium utilization can be maximized or otherwise increased while packet loss due to OBSS interference is minimized or otherwise reduced. Various implementations can achieve these and other advantages without requiring the shared AP or the shared APs to know STAs associated with other BSSs, without requiring a pre-designated or dedicated master AP or group of pre-designated APs, and without requiring backhaul coordination between the APs participating in the TXOP.

[0055] In some examples in which the signal strength or interference level associated with the selected AP is relatively low, such as less than a given value, or when the decoding error rate of the selected AP is relatively low, such as less than a threshold, the start time of the communication between the different BSSs can be synchronized. Conversely, when the signal strength or interference level associated with the selected AP is relatively high, such as greater than a given value, or when the decoding error rate of the selected AP is relatively high, such as greater than a threshold, the start time can be offset from each other by a time period associated with decoding the preamble of a wireless packet and determining from the decoded preamble whether the wireless packet is an intra-BSS packet or an OBSS packet. For example, the time period between the transmission of an intra-BSS packet and the transmission of an OBSS packet can allow the respective APs (or their associated STAs) to decode the preamble of the wireless packet and obtain the BSS color value carried in the wireless packet to determine whether the wireless packet is an intra-BSS packet or an OBSS packet. In this way, each of the participating APs and their associated STAs can be able to receive and decode intra-BSS packets in the presence of OBSS interference.

[0056] In some examples, the sharing AP can perform polling of a set of non- managed or non-co-managed APs that support coordinated reuse to identify candidates for future spatial reuse opportunities. For example, the sharing AP can transmit one or more spatial reuse poll frames as part of determining one or more spatial reuse criteria and selecting one or more other APs to be part of the shared AP. From the polling, the sharing AP can receive responses from one or more of the polled APs. In some particular examples, the sharing AP can transmit a coordinated AP TXOP indication (CTI) frame to the other APs, the CTI frame indicating time and frequency of resources of a TXOP that can be shared. The sharing AP can select one or more candidate APs upon receiving a coordinated AP TXOP request (CTR) frame from a respective candidate AP indicating that the respective AP desires to participate in the TXOP. The polling responses or CTR frames can include a power indication, e.g., a RX power or RSSI measured by the respective AP. In some other examples, the sharing AP can directly measure potential interference of services supported at one or more APs, such as UL transmissions, and select the shared AP based on the measured potential interference. The sharing AP typically selects APs to participate in the coordinated spatial reuse such that it still protects its own transmissions to and from STAs in its BSS, which can be referred to as primary transmissions. Then, as described above, resources can be allocated to the selected APs during the TXOP.

[0057] Retransmission protocols such as hybrid automatic repeat request (HARQ) can also provide performance gains. HARQ protocols can support various HARQ signaling between a transmitting wireless communication device and a receiving wireless communication device, as well as signaling between the PHY layer and the MAC layer, to improve retransmission operations in WLANs. HARQ uses a combination of error detection and error correction. For example, a HARQ transmission can include error detection bits added to data to be transmitted using an error detection (ED) code, such as a cyclic redundancy check (CRC). The error detection bits can be used by a receiving device to determine whether the receiving device has correctly decoded a received HARQ transmission. In some examples, the original data (information bits) to be transmitted can be encoded with a forward error correction (FEC) code, such as a low-density parity-check (LDPC) coding scheme that uses systematic encoding of information bits to produce parity bits. The transmitting device can transmit both the original information bits and the parity bits to the receiving device in the HARQ transmission. The receiving device can be able to use the parity bits to correct errors in the information bits, thereby avoiding retransmission.

[0058] Implementing a HARQ protocol in a WLAN can improve the reliability of data communicated from a transmitting device to a receiving device. The HARQ protocol can support establishment of a HARQ session between two devices. Once a HARQ session is established, if a receiving device fails to properly decode a first HARQ transmission received from a transmitting device (and fails to correct errors), the receiving device can send a HARQ feedback message (e.g., a negative acknowledgement (NACK)) to the transmitting device indicating that at least a portion of the first HARQ transmission was not properly decoded. Such a HARQ feedback message can be different from the traditional block ACK feedback message type associated with a conventional ARQ. In response to receiving the HARQ feedback message, the transmitting device can send a second HARQ transmission to the receiving device to convey at least a portion that further assists the receiving device in decoding the first HARQ transmission. For example, the transmitting device can include some or all of the original information bits, some or all of the original parity bits, and other different parity bits in the second HARQ transmission. The combined HARQ transmissions can be processed for decoding and error correction such that a complete signal associated with the HARQ transmissions can be obtained.

[0059] In some examples, the receiving device can be enabled to control whether to continue with a HARQ procedure or to revert to a non-HARQ retransmission scheme, such as an ARQ protocol. By allowing a device to dynamically switch between an ARQ protocol and a HARQ protocol during a frame exchange, such switching can reduce feedback overhead and increase flexibility of retransmissions. Some implementations can also allow multiplexing of communications employing ARQ with communications employing HARQ.

[0060] Some wireless communication devices, including both APs and STAs, are capable of multi-link operation (MLO). In some examples, MLO supports establishment of multiple different communication links between a STA and an AP, such as a first link over a 2.4 GHz frequency band, a second link over a 5 GHz frequency band, and a third link over a 6 GHz frequency band. Each communication link can support one or more sets of channels or logical entities. In some cases, each communication link associated with a given wireless communication device can be associated with a respective radio of the wireless communication device, which can include one or more transmit / receive (Tx / Rx) chains, including or coupled with one or more physical antennas, or including signal processing components, among other components. A device that is MLO capable can be referred to as a multi-link device (MLD). For example, an AP MLD can include multiple APs that are each configured to communicate with a respective one of multiple STAs of a non-AP MLD (also referred to as a “STA MLD”) over a respective communication link. A STA MLD can communicate with an AP MLD through one or more of multiple communication links at a given time.

[0061] One type of MLO is multi-link aggregation (MLA), in which traffic associated with a single STA is sent concurrently across multiple communication links at the same time to maximize utilization of available resources, enabling higher throughput. That is, during at least some time durations, transmission or portions of transmission can occur concurrently and in parallel over two or more links. In some examples, the parallel wireless communication links can support synchronized transmission. In some other examples, or during some other time durations, transmission over the links can be parallel, but not synchronized or concurrent. In some examples or time durations, two or more of the links can be used for communication between the wireless communication devices in the same direction, such as all uplink or all downlink. In some other examples or time durations, two or more of the links can be used for communication in different directions. For example, one or more links can support uplink communication, and one or more links can support downlink communication. In such examples, at least one of the wireless communication devices operates in a full-duplex mode. Generally, full-duplex operation enables bidirectional communication, in which at least one of the wireless communication devices can transmit and receive at the same time.

[0062] MLA can be implemented in a variety of ways. In some examples, MLA can be packet-based. For packet-based aggregation, frames of a single traffic stream (such as all traffic associated with a given traffic identifier (TID)) can be transmitted concurrently across multiple communication links. In some other examples, MLA can be stream-based. For stream-based aggregation, each traffic stream (such as all traffic associated with a given TID) can be transmitted using a single one of the available communication links. As an example, a single STA MLD can access a web browser while concurrently streaming a video. Traffic associated with the web browser access can be communicated over a first communication link, while traffic associated with the video stream can be concurrently communicated over a second communication link (such that at least some of the data can be transmitted on the first channel concurrently with data transmitted on the second channel).

[0063] In some other examples, MLA can be implemented as a hybrid of stream-based aggregation and packet-based aggregation. For example, an MLD can employ stream-based aggregation where multiple traffic streams are created, and can employ packet-based aggregation in other cases. Determination to switch among MLA techniques or modes can additionally or alternatively be associated with other metrics, such as time of day, traffic load within the network or battery power of the wireless communication devices, among other factors or considerations.

[0064] To support MLO techniques, an AP MLD and a STA MLD can exchange supported MLO capability information, such as supported aggregation types or supported frequency bands, among other information. In some examples, the exchange of information can occur via a beacon signal, a probe request or probe response, an association request or association response frame, a dedicated action frame, or an operation mode indicator (OMI), among other examples. In some examples, an AP MLD can designate a given channel in a given frequency band as an anchor channel, such as a channel on which the AP MLD transmits beacons and other management frames. In such examples, the AP MLD can also transmit beacons on other channels, such as beacons that can contain less information, for discovery purposes.

[0065] MLO techniques can provide a number of benefits to a WLAN. For example, MLO can improve user perceived throughput (UPT), such as by quickly flushing per-user transmit queues. Similarly, MLO can improve throughput by improving utilization of available channels, and can increase spectral utilization, such as increasing the bandwidth-time product. Further, MLO can enable smooth transitions between multi-band radio components, such as where each radio component can be associated with a given RF band, or enable a framework for setting apart control and data channels. Other benefits of MLO include reducing modem on-time, which can be beneficial to wireless communication devices in terms of power consumption. Another benefit of MLO is increased multiplexing opportunities in the case of a single BSS. For example, multi-link aggregation can increase the number of users per multiplexed transmission served by a multi-link AP MLD.

[0066] FIG. 4 A diagram illustrating another example wireless communication network 400 is shown. According to some aspects, the wireless communication network 400 can be an example of a mesh network, an IoT network, or a sensor network according to one or more of the IEEE 802.11 family of wireless communication protocol standards, including the 802.11 ah amendment. The wireless network 400 can include a plurality of wireless communication devices 414. The wireless communication devices 414 can represent various devices, such as display devices (e.g., TVs, computer monitors, navigation systems, and so on), music or other audio or stereo equipment, remote control devices (“remotes”), printers, kitchen or other household appliances, and so on.

[0067] In some examples, the wireless communication devices 414 sense, measure, collect, or otherwise obtain and process data, and subsequently transmit such raw or processed data to the intermediate device 412 for subsequent processing or distribution. Additionally or alternatively, the intermediate device 412 can transmit control information, digital content (e.g., audio or video data), configuration information, or other instructions to the wireless communication devices 414. The intermediate device 412 and the wireless communication devices 414 can communicate with each other via a wireless communication link 416. In some examples, the wireless communication link 416 includes a Bluetooth link or other PAN or short-range communication link.

[0068] In some examples, the intermediate device 412 can also be configured for wireless communication with other networks, such as with a Wi-Fi WLAN or a wireless (e.g., cellular) wide-area network (WW AN), which in turn can provide access to external networks, including the Internet. For example, the intermediate device 412 can associate and communicate with an AP 402 of a WLAN network through a Wi-Fi link 418, which AP can also serve various STAs 404. In some examples, the intermediate device 412 is an example of a network gateway (e.g., an IoT gateway). In this way, the intermediate device 412 can act as an edge bridge providing Wi-Fi core backhaul for an IoT network including the wireless communication devices 414. In some examples, the intermediate device 412 can analyze, pre-process, and aggregate data received from the wireless communication devices 414 that are local at the edge before transmitting the data to other devices or external networks via the Wi-Fi link 418. The intermediate device 412 can also provide additional security for the IoT network and the data it transmits.

[0069] Example NAV setting As mentioned above, traffic originating from real-time applications such as XR or gaming can have strict latency requirements. For example, FIG. 5 An example scenario 500 is shown in which traffic between a wireless station (STA SI) 504 and a peer device (e.g., an XR headset) 514 can have strict latency requirements. To accommodate such traffic, an AP 512 (e.g., in an infrastructure or “infrastructure” AP) can broadcast information in a beacon (520) indicating how a transmit opportunity (TXOP) 530 can be shared.

[0070] In certain wireless communication standards (e.g., 802.11be), such traffic can be referred to as latency sensitive traffic. In scenarios involving latency sensitive traffic, triggered transmit opportunity (TXOP) sharing mechanisms can be used to serve low latency traffic (e.g., XR traffic). For example, a mechanism referred to as a triggered TXOP sharing procedure can be used in such scenarios, allowing an AP to allocate a portion of time within a gained TXOP to only one non-AP STA for transmitting one or more non-trigger-based (non-TB) PPDUs.

[0071] FIG. 6 An example of TXOP sharing is shown. As illustrated, after successfully contending for access to the wireless medium and gaining a TXOP, an AP can transmit a frame 602 to trigger sharing of the TXOP. Frame 602 can be a frame referred to as a multi-user (MU) request to send (RTS) for TXOP sharing (TXS). Frame 602 can include a receive address (RA) set to the MAC address of STA SI, a transmit address (TA) set to the MAC address of the AP, and a duration field set to a value dl to span to the TXOP.

[0072] STA SI can acknowledge the trigger frame 602 with an allow to send (CTS) frame 604 with the RA set to the MAC address of the AP. STA SI can use the shared TXOP to transmit data to the AP and / or peers as shown at 606 and 608. There are various types of TXOP sharing modes that can utilize aspects of the disclosure. In some cases, a particular TXOP sharing mode can be indicated by a subfield value. For example, a first mode (mode 1) generally refers to a mode in which a MU-RTS initiates a MU-RTS TXOP sharing procedure in which scheduled STAs can only transmit physical layer protocol data units (PPDUs) addressed to their associated AP. A second mode (mode 2) generally refers to a mode in which a MU-RTS initiates a MU-RTS TXOP sharing procedure in which scheduled STAs can transmit PPDUs addressed to their associated AP or addressed to another STA.

[0073] In certain systems, there can be two types of NAVs, a BSS-internal NAV for all frames within a basic service set (BSS) and a basic NAV for overlapping BSS (OBSS) frames (often referred to as inter-BSS frames). When a STA classifies a detected / received frame as a BSS-internal PPDU (e.g., a frame matching the BSS color of the STA or a frame with a BSSID field matching the associated AP of the STA), the STA can set the BSS-internal NAV timer. When a STA detects an OBSS frame with a different BSS color, a frame without a BSS color in the case of legacy frames, or a frame with a BSSID field not matching the associated AP of the STA, the STA sets the basic NAV timer.

[0074] As indicated at 620, the peer can set its basic NAV 632 to the duration di indicated in the trigger frame 602. As illustrated, during the basic NAV, the peer can be restricted to transmit a block acknowledgement (BA) 610, but is not allowed to transmit.

[0075] Certain devices (e.g., devices of pre-802.11ax versions) can use only one NAV, while other devices (e.g., devices of 802.11ax and above versions) can use a BSS-internal NAV and a basic NAV. In addition to the basic NAV and the BSS-internal NAV, other NAV types can be defined. For example, one or more other NAV types can be defined in an ultra-high reliability (UHR) system between STAs that support such a capability, and these STAs can set a new NAV (e.g., a coordinated BSS NAV). This capability can cover CTS-to-TXOP being sent by the shared STA (as described below), as well as TXOP return as part of the TXOP sharing capability.

[0076] Enhanced scheduling for TXOP sharing However, aspects of the present disclosure present solutions that can be considered enhancements to TXOP sharing scenarios and can help address these potential challenges.

[0077] As described above, there are potential challenges with NAV allocation during a shared TXOP. One potential challenge is how to set the NAV to the best duration for certain traffic needs. For example, if the NAV is set to a duration that is too long during the shared TXOP (e.g., for the entire duration of the shared TXOP), uplink traffic from another device and another device associated with the shared TXOP STA (e.g., traffic from an XR headset to a phone) can be throttled, impacting performance and user experience.

[0078] This problem can arise because the AP can not be aware of the NAV requirements of the STAs for the shared TXOP request. For example, when the AP allocates a shared TXOP to a client, the AP (e.g., according to the 802.11be wireless communication standard) can set the NAV for the TXOP to either (1) a long NAV duration covering the entire shared TXOP duration or (2) a short NAV duration.

[0079] FIG. 7 An example of TXOP sharing with a long NAV duration is shown. As illustrated, after successfully contending for access to the wireless medium (e.g., after a random backoff - RBO) and obtaining a TXOP, the AP can send a frame 702 (e.g., a MU-RTS-TXS) to trigger sharing of the TXOP. S1 can acknowledge the trigger frame 702 with a CTS frame 704.

[0080] In the illustrated example, frame 702 has a RA set to the MAC address of STA S1, a TA set to the MAC address of the AP, and a duration field set to a value d1 for a long duration to span the duration of the shared TXOP. As indicated at 732 and 734, the peer and another STA S3 can set their basic NAVs accordingly.

[0081] Unfortunately, as indicated at 706, with the basic NAV set, the peer device (e.g., a headset or XR glasses) cannot ignore the NAV, e.g., when STA S1 (e.g., a phone) attempts to trigger an uplink transmission. Thus, during the shared TXOP, uplink traffic from the peer can be suppressed, impacting performance and user experience.

[0082] If the AP indicates a shorter NAV duration, then when the shared TXOP is triggered, the client STA S1 can already be able to participate in P2P communication with the peer (e.g., phone to XR glasses), including uplink transmissions from the peer back to STA S1 (e.g., phone to XR glasses).

[0083] Certain aspects of the present disclosure provide a signaling mechanism in which a STA can indicate (e.g., to a potential TXOP sharing AP) a particular (desired / preferred) NAV setting for a shared TXOP. For example, if a STA wishes to conduct peer-to-peer (P2P) communication during a shared TXOP, the STA can request a short NAV setting. Once the shorter NAV duration expires, the shared TXOP STA can trigger uplink traffic from the peer in the remaining portion of the shared TXOP.

[0084] FIG. 8A timing diagram illustrating an example 800 of TXOP sharing in which a STA can indicate a particular NAV setting is shown, in accordance with certain aspects of the present disclosure.

[0085] As shown at 810, STA SI can transmit a frame 810 to the AP to indicate / request a particular NAV setting. As will be described in greater detail below, the request can indicate a certain type of NAV setting (e.g., selected from one or more long durations and one or more short durations), or can indicate a particular duration value.

[0086] The illustrated example assumes that STA SI has requested a short NAV duration by the request 810. Accordingly, based on the request, the AP triggers the shared TXOP with a trigger frame 802 having di set to a duration that is substantially shorter than d2 (the duration of the shared TXOP).

[0087] STA SI can acknowledge the trigger frame 802 with a CTS frame 804. As indicated at 832, the peer and STA S3 set their NAVs to the short duration di. In some cases, STA SI can serve the peer, e.g., with a software-based AP (soft-AP) functionality, where the STA acts as an AP, where FIG. 8 The name STA Al is used for STA SI acting in this capacity.

[0088] After the (short) NAV expires, STA Al can trigger an uplink transmission from the peer via a trigger frame 812. As illustrated at 834, the trigger frame 812 can cause STA S3 to set its NAV for the remainder of the shared TXOP, thereby protecting the uplink transmission (e.g., TB PPDU 814) from the peer to STA Al. As illustrated, STA Al can acknowledge the uplink transmission via a BA 816.

[0089] In this way, aspects of the present disclosure can enable an AP to allocate a NAV that is optimal for client operation during a shared TXOP. In some cases, a STA can request a particular NAV setting for a shared TXOP when requesting the shared TXOP allocation.

[0090] The requested particular NAV can depend on a particular goal or scenario. For example, if a STA intends to use the shared TXOP (e.g., only) for DL transmissions to another peer STA, the STA can request long NAV protection. On the other hand, as in the example illustrated in FIG. 8, if the STA intends to use the shared TXOP for both DL and UL transmissions, the STA can request a short NAV setting. FIG. 8In the illustrated example, the STA can request short NAV protection (e.g., until Clear to Send (CTS) or more) to enable UL transmissions from another peer as well as DL and / or necessary control frame transmissions. In certain aspects, the STA can request that the AP set the exact NAV duration in the TXS frame (e.g., in the Duration / ID field).

[0091] In some aspects, the STA can dynamically indicate the NAV setting using, for example, a one-time request in the frame header. The frame header can be a medium access control (MAC) frame header and a PHY header / preamble. In the case of the MAC frame header, the indication can be in the HE variant HT Control field (A Control subfield). In this way, the STA can provide an aperiodic indication of the preferred NAV setting for a single (e.g., next) allocation or subsequent allocations (e.g., overriding or adding to the periodic request until explicitly changed). In some aspects, the STA can indicate the NAV setting for periodic allocations (e.g., using a management frame such as a Stream Classification Service (SCS) Request frame).

[0092] Another potential challenge is how to ensure that STAs outside the range of the shared TXOP receiver set their NAVs appropriately. For example, because the STA is outside the range, the STA can not receive the CTS from the shared TXOP STA and thus can ignore the NAV and transmit, potentially disrupting the shared TXOP.

[0093] This potential challenge can be understood with reference to the scenario 900A illustrated in FIG. 9A In the illustrated example, STA S3 can be outside the range of STA S1. Thus, STA S4 can not hear / detect the CTS response transmitted by STA S1 after receiving the (MU RTS TXS) trigger frame from the AP. Thus, after the NAV times out, STA S3 can contend for channel access and can transmit to the AP, which can cause a collision with the UL transmission back to the AP from STA S1 and can disrupt the sequence within or after the shared TXOP (e.g., if additional p2p transmissions beyond the shared TXOP are expected).

[0094] Aspects of the present disclosure provide a special frame that can help address this challenge. The frame can be designed to allow a peer device to transmit to the shared TXOP STA during the shared TXOP while protecting such transmissions. For example, the frame can help ensure NAV setting at (AP or non-AP) STAs outside the range of the shared TXOP STA to prevent transmissions from the (AP or non-AP) STAs during the shared TXOP.

[0095] For example, the frame can have an address associated with the shared STA, resulting in setting a first type of NAV (e.g., an intra-BSS NAV or a new type of NAV) for the peer setting a second type of NAV (e.g., a basic NAV) at the out-of-range STA to prevent transmissions from the out-of-range STA during the shared TXOP.

[0096] In some cases, such a frame can be a separate frame sent by the AP designed to set an intra-BSS NAV (or a new type of NAV) for the peer of the shared TXOP recipient, while setting a basic NAV for other STAs, so these STAs will not clear the NAV after the NAV expires, as the frame alone can be sufficient to set the basic NAV.

[0097] As FIG. 9A As illustrated at 920, such a frame can be sent from the AP, where the frame is designed to (1) set an intra-BSS NAV at another peer / associated STA of the TXOP shared STA, and (2) cause legacy STAs to not clear their NAV after the NAV expires, as the frame alone can be sufficient to set the NAV. In some cases, the frame can be a CTS frame with the RA set to the MAC address of the shared TXOP STA. Thus, the frame can be referred to as a CTS-to-shared TXOP STA (or CTS-to-STA) frame. In this case, the STA can be an AP or a non-AP STA, and can be capable of forwarding data frames and sharing the TXOP. In some cases, the data frame can carry an identifier (e.g., AID) of the transmitter or destination STA, rather than just the transmitter and / or receiver STA identifier. Such an ID can be carried in the frame header (which can be MAC or PHY). In some cases, the ID can be carried in the HT Control field (e.g., in the A Control subfield). This can help identify which STA the frame is to be sent to (e.g., including a requirement to do so in the shared TXOP, e.g., based on some rules and signaling that can be defined).

[0098] Such a frame can also be used to set a basic NAV at a non-AP STA that is not a peer of the shared TXOP STA, e.g., to prevent the non-AP STA from transmitting during the shared TXOP. FIG. 9BThe scenario 900B illustrated in the middle benefits from which two APs (AP1 9121 and AP2 9122) can communicate to coordinate to strive to support Ultra High Reliability (UHR) traffic via Multi-AP coordination. In this case, STA S3 can be out of range of AP2 9122 and thus can not hear / detect the CTS response. This case can apply to a coordinated or cluster based Time Division Multiple Access (C-TDMA) scenario. Thus, AP1 can transmit a CTS-to-Shared-TXOP frame to ensure that STA S3 does not clear its NAV in case it does not hear a CTS from AP2 acknowledging the shared TXOP trigger frame.

[0099] The CTS-to-Shared-TXOP (or CTS-to-STA) frame presented herein can help avoid NAV timeout at a hidden STA that does not hear a CTS frame after a MU RTS TXS frame. As FIG. 10 As shown, the CTS-to-TXOP shared STA can be a CTS frame 1000 with the RA field 1006 set to the address of the STA associated with the STA receiving the shared TXOP. The address can be the MAC address of the shared TXOP STA. In some cases, a STA can be associated with a group or set, such as a Multiple BSSID (MBSSID) set or a Cohosted set, and the RA of the CTS-to-TXOP shared STA frame can be set to the MAC address that is part of the set.

[0100] In general, based on the RA address in the CTS-to-TXOP shared STA frame, a peer STA can be able to transmit in the UL. One approach is to have a rule to ignore the NAV (if considered as a basic NAV or define a new type of NAV) or consider it as an intra-BSS NAV explicitly. For example, some STAs (e.g., UHR / 802.11bn STAs) can be provided with a NAV exception. Such an exception can allow such STAs to ignore the NAV based on an indication in the frame (e.g., a group address or some other field in the MAC frame header or the PHY header), can set the NAV to an intra-BSS NAV based on some indication as mentioned, in which case the STA can ignore the NAV when triggered by its associated AP-based current rules, and / or can set a new NAV type that can be ignored when the STA is triggered from the associated AP or coordinating AP. The coordinating AP for which the STA can ignore the NAV can be communicated to the STA (e.g., via a management frame such as a beacon frame or via a control frame indicating information (e.g., an AID or MAC address) that the STA can detect to perform these actions related to the NAV).

[0101] In some cases, the address that enables the peer STA to transmit in the uplink can be communicated from the AP to the STA, for example. For example, the AP can notify the client via a management frame (e.g., by including elements in a beacon frame or other frame used by the AP coordination protocols (Coordination Media Access, Coordination (R)TWT, Coordination TDMA, etc.)).

[0102] In some cases, special frames (such as CTS to TXOP-shared STA frames, scheduling frames, or other types of existing or new frames) may include scheduling information for at least the shared TXOP STAs. The at least shared TXOP STAs can use the scheduling information to determine when to send and / or postpone channel access. Another STA (e.g., possibly within the range of the TXOP-sharing AP and / or the shared AP / STA, or possibly outside the range of the TXOP-sharing AP and / or the TXOP-shared STA) can use the scheduling information to determine when to postpone channel access. The scheduling information may also indicate the total duration of the shared TXOP. The scheduling information may also indicate the minimum duration for which a first radio node intends to share the TXOP with each of the radio nodes (e.g., the shared TXOP STA, its peers, and / or another STA).

[0103] Different aspects of this disclosure can be used during service periods (e.g., TWT SPs) or during coordinated media access periods (e.g., coordinated TWTs, such as coordinated I-TWTs, coordinated B-TWTs, coordinated R-TWTs, p2p TWTs, or any type of coordinated TWT) coordinated between different APs and / or STAs. In some cases, the transmitting STA (AP or non-AP) may transmit scheduling frames or other frames (such as control frames, such as trigger frames, such as MU RTS TXS trigger frames) before a specific timestamp (e.g., the SP start time, or the coordinated media access timestamp or period, or TWT SP)) to provide better protection for transmission during SPs.

[0104] You can refer to this. FIG. 11 The example timeline 1100 shown illustrates the various functionalities implemented by special frames (such as CTS to TXOP shared STA frames).

[0105] In the illustrated example, the (infrastructure) AP sends a CTS-to-TXOP- shared-STA frame 1120 prior to the MU RTS TXS frame 1102 (or any other one or more frames, e.g., other frames that can be used for TXOP sharing). As illustrated, the CTS-to-TXOP-shared-STA frame can set a NAV 1134 at a hidden (legacy) STA, such as STA S3, thereby avoiding the NAV timeout problem described above (e.g., in the case that STA S3 does not hear the CTS 1104 transmitted by the shared TXOP STA S1).

[0106] The CTS-to-TXOP-shared-STA frame can also allow UL transmissions within the shared TXOP (e.g., from another peer or associated STA with the TXOP-shared AP), as the intra-BSS NAV 1132 can be set at the other peer / associated STA. Thus, when the peer is triggered (e.g., via the trigger frame 1112), the peer is allowed to transmit UL data (TB PPDU 1114) based on the current intra-BSS NAV rules. As mentioned above, a new type of NAV can also be defined, which can be set based on the ID (e.g., MAC address / AID) of the other STA or based on a group address.

[0107] In the example timeline illustrated in FIG. 12 , the (infrastructure) AP sends a CTS-to-TXOP-shared-STA frame 1220 after the MU RTS TXS frame 1202.

[0108] The MU RTS TXS frame 1202 can trigger a shared TXOP duration and a RA set to the address associated with STA S1. STA S1 can acknowledge the MU RTS TXS frame 1202 with a CTS 1204.

[0109] As illustrated, the MU RTS TXS frame 1202 can cause STA S3 to set its basic NAV 1234. In some cases, the peer can be configured to set its intra-BSS NAV 1232 based on the MU RTS TXS frame 1202. As such, STA S1 can send a trigger frame 1212 to prompt uplink traffic (TB PPDU 1214) from the peer.

[0110] As illustrated, the AP can later transmit a CTS-to-TXOP-shared STA frame 1220 with the RA set to the MAC address of STA S3, which can cause STA S1 to set its basic NAV 1236. STA S3 can respond to the CTS-to-TXOP-shared STA frame with a response frame 1222, and can subsequently transmit (e.g., data, control, or management) frames 1224.

[0111] As demonstrated by the examples described above, CTS-to-TXOP-shared STA frames can be used in various ways. In some cases, a CTS-to-TXOP-shared STA frame can be used independently as an initiator frame for sharing a TXOP, where the duration field is set to a time (e.g., in ms) corresponding to the TXOP duration being shared (to set the NAV at other STAs to equal that value). One option can be to require the receiving STA of the CTS-to-TXOP-shared STA to transmit a CTS with the RA address set to the receiving STA and the duration field set to the duration field of the CTS-to-TXOP-shared STA frame minus the CTS frame transmit time minus the SIFS duration. An alternative option can be to rely on detection of transmissions from the STA receiving the CTS-to-TXOP-shared STA.

[0112] As demonstrated in the example shown in FIG. 11 A CTS-to-TXOP-shared STA frame can also be used prior to a MU RTS TXS frame for sharing a TXOP. If the CTS frame after the MU RTS TXS frame is not successfully received, the AP can also transmit a CF-End to clear the NAV set by the CTS-to-TXOP-shared STA.

[0113] A short duration RTS / CTS frame exchange can precede a CTS-to-TXOP-shared STA frame (or other such frame) to ensure that the TXOP-shared STAs are ready to receive the CTS-to-TXOP-shared STA frame. As mentioned above, in some cases, the RA address can be set to a group address (e.g., an address known to the group of STAs / AP), after which the STAs can be allowed to transmit and ignore the NAV. In some cases, the TXOP-shared (AP / non-AP) STAs can indicate that the RA address should be set to what (e.g., set to a group address or an address associated with a group). In some cases, the indication can be via an identifier of the group or an identifier of one or more wireless nodes belonging to the group (e.g., an association ID / AID or another STA or AP ID).

[0114] A regular CTS-to-self (with RA set to the transmitter's MAC address) can not achieve the same functionality (as CTS-to-TXOP-shared-STA frame) because CTS-to-self will carry the TXOP-shared-AP MAC address and thus will set the basic NAV for another peer / associated STA that will block UL transmissions.

[0115] The in-BSS NAV can be set at the peer / client based on the associated AP MAC address (e.g., of STA S1 soft AP). When a peer STA receives a CTS-to-STA (CTS-to-TXOP-shared-STA) frame, such frame can carry the MAC address in the RA field only. In this case, if the peer STA (e.g., an associated STA with the TXOP-shared-AP or another AP / non-AP STA) that receives such frame classifies the PPDU as an in-BSS PPDU or other PPDU type (e.g., if the MAC address is the same as its associated AP MAC address or based on a new rule), the peer STA can set the in-BSS NAV. On the other hand, if the STA sees a MAC address other than the associated AP MAC address or another peer MAC address, the STA will set the basic NAV (e.g., STA S3 sets the basic NAV as shown at 1134).

[0116] In the case of a MU RTS trigger frame or other frame that carries both the transmitter address (TA) and receiver address (RA), another STA that receives such frame will set the NAV based on the transmitter MAC address (TA or address 2) in the MAC frame header.

[0117] Thus, the CTS-to-TXOP-shared-STA frame proposed herein can be used to set the in-BSS NAV instead of the basic NAV on another peer / associated STA of another TXOP-shared-AP (e.g., STA S1 soft AP) so that the peer STA can respond with UL transmissions to the trigger frame that is not allowed in case the basic NAV is set. Some special addresses can be used to trigger the in-BSS NAV (or new type of NAV) and thus allow the UHR STA to respond with UL, while other (e.g., legacy) STAs are suppressed by the NAV.

[0118] In some cases, an AP can determine whether a shared TXOP STA successfully receives a CTS-to-TXOP-shared frame and take one or more actions in accordance with the determination. For example, if the AP determines that a shared TXOP STA does not successfully receive a CTS-to-TXOP-shared frame, the AP can decide to release or return some / all of the shared TXOP.

[0119] If the AP follows the legacy failure recovery rule to detect the transmission within the CTS / ACK timeout, the TXOP sharing AP can determine that the CTS-to-TXOP shared STA frame is successful. The timeout can be designed to provide sufficient time for the AP to detect the transmission, which can be the time needed to detect the presence of the over-the-air PPDU (at least a portion of the PHY header).

[0120] In other cases, the TXOP sharing AP can determine that the CTS-to-TXOP shared STA is unsuccessful based on an explicit response frame (e.g., which can be another CTS (CTS-to-self) frame or an ACK / NACK frame). If the AP determines that the CTS-to-TXOP shared STA frame is unsuccessful, the AP can transmit a CF-End to reset the NAV set by the CTS-to-TXOP shared STA frame, or the AP can transmit DL traffic to another STA or another AP within its BSS. In some cases, if the CTS-to-TXOP shared STA frame is successful, in the case that the TXOP shared STA ends the transmission (within the shared TXOP duration) early, the TXOP shared STA can transmit a CF-End to reset the NAV set by the CTS-to-TXOP shared STA frame.

[0121] The CF-End frame can act as an early return of the shared TXOP when transmitted by the TXOP shared STA / AP (which can be considered a TXOP donor). Upon receiving such a CF-End frame from the TXOP shared STA / AP, the TXOP sharing AP can transmit. In some cases, the TXOP sharing AP can transmit within a short duration (e.g., SIFS or PIFS) such that it has priority over other STAs. In other cases, the TXOP sharing AP can perform a random backoff (RBO) before transmitting again.

[0122] In some cases, the CF-End frame can act as a release back to the network, where the TXOP sharing AP can have to contend for channel access again before transmitting any frames. In such cases, the CF-End frame can reset the NAV set at other STAs that receive the CF-End frame. In some cases, the NAV can be a BSS-internal NAV, a basic (inter-BSS) NAV, or any other potential (new) NAV type set at those STAs.

[0123] In some cases, the CF-End frame can be transmitted by the TXOP sharing AP. The CF-End frame can act as a TXOP release back to the network when transmitted by the TXOP shared STA / AP, where the TXOP sharing AP can have to contend for channel access again before transmitting any frames.

[0124] In some cases, as exemplified in the example frame 1300, FIG. 13 As exemplified in the example frame 1300, sharing can be indicated by setting the BSSID (TA) field 1308 (or some such field) of the CF-End frame to the release or return of the shared TXOP by the TXOP shared STA or TXOP sharing STA. In some cases, the duration field can be set to 0 when sent by some type of station (e.g., non-DMG STA and non-S1G STA). In some cases, the RA field can be the broadcast address when sent by some type of STA (e.g., non-DMG STA).

[0125] In some cases, different types of frames (in addition to the CF-End frame, which can be new or existing) can be used to indicate the return or release of the shared TXOP. For example, in some cases, the MAC header of a frame (QoS data / Null frame) can carry an indication of the return of the TXOP or an indication that the shared TXOP is maintained by the TXOP shared STA / AP (TXOP donor). Similar functionality can be achieved when such a frame is sent by the TXOP sharing STA / AP.

[0126] In some cases, the TXOP shared STA / AP can return the unused time of the shared TXOP to the TXOP sharing AP by transmitting a CTS frame carrying an indication of the return of the TXOP. In such cases, the return can be indicated via a special address in the RA field and / or special duration field of the CTS frame. For example, in some cases, the duration field can be set to 0 as an indication of the returned TXOP. In other cases, the duration field can be set to a pre-defined value or any possible value. In some cases, the RA field of the CTS frame can carry the address of the TXOP sharing AP or TXOP shared AP. Such a frame can be referred to as a CTS to STA, CTS to AP, or CTS to TXOP sharing AP frame.

[0127] In some cases, the TXOP shared AP can transmit a management frame to the TXOP sharing AP to return the unused medium time of the shared TXOP. One advantage of this approach can be that it can result in a reliable return of the unused time in the shared TXOP if it is immediately acknowledged. In some cases, no response (ACK) can be needed.

[0128] In some cases, a CTS (e.g., CTS to AP or CTS to STA) frame (e.g., for duration 0) can be followed by a response frame to confirm the receipt of the TXOP return to the TXOP sharing AP. The response frame can be, for example, a CTS to self frame by the TXOP sharing AP (which can also have duration 0 or can have another non-zero duration). In some cases, the response frame can be an ACK frame.

[0129] For coordinated AP transmissions, a MU RTS TXS allocation frame (or in some cases, any other scheduling frame) may be sent first to allocate resources to the AP. In such cases, for example, when it is time to share the TXOP with an AP that shares the TXOP, a CTS to TXOP-shared STA frame may then be sent to that AP.

[0130] In some cases, the STA can also indicate the MAC address it wants the AP to set in the RA that shares the STA (or some other type of frame) from CTS to TXOP, which can be helpful for certain use cases, such as Wi-Fi Direct.

[0131] The signaling mechanism proposed in this paper allows peering STAs (e.g., XR headsets / glasses). In some cases, peers can be served by non-AP STAs via soft AP instances. This can pose a challenge because the MAC addresses of the non-APSTA instance and the (soft) AP instance may differ on the client device (e.g., as shown in the image). FIG. 8 (As indicated by the S1 and A1 labels shown). The (infrastructure) AP may not know the MAC address of the soft AP instance, and the peer STA (i.e., the glasses) may not know the MAC address of the non-AP STA instance associated with the AP. If the AP sends a CTS with the RA having the MAC address set to the non-AP STA instance to the STA, in such a case, the peer STA may not need to set the NAV within the BSS because the non-AP STA instance behaves as an OBSS. Aspects of this disclosure can help address this challenge in various ways. For example, a soft AP may advertise its BSS as part of a co-hosted set or a multi-BSS set, where the 'n' value is chosen such that both addresses fall within the range of that set. MBSSIDIE does not need to include any non-transmitting (non-Tx) BSSID profile because the non-AP STA instance is not a virtual AP (VAP). Some standards (e.g., 8022.11ax) may have rules requiring the setting of the NAV within the BSS for any transmission within the same set. One advantage of this approach is that it works seamlessly without the infrastructure AP or peer STA needing to know the MAC addresses of the soft AP or non-AP STA instances on the client devices.

[0132] In some cases, a (peer) STA receiving a CTS to such an address in the STA can be able to transmit within the UL. One way to achieve this is to have a rule that the STA ignores the NAV in this case. Another way is to define a new type of NAV, and yet another way is to set the NAV within the BSS.

[0133] When an AP transmits TXS using mode 2, the AP can allocate the shared TXOP for both UL and P2P. However, in some cases, based on the requested resources or resource constraints, the AP can want to control the allocation time for UL or p2p only. Various mechanisms are provided by aspects of the present disclosure for this. For example, with a NAV-based mechanism, the AP can control the use of the shared TXOP by setting a long NAV to cover the duration during which the shared TXOP STA can use the NAV for UL or DL without p2p. The AP can set a shorter NAV in the remaining part of the TXOP to enable UL / DL transmissions between peer STAs.

[0134] As another example, with a NAV-based mechanism, the AP can use a CTS-to-self frame so that the TXOP shared STA can use the allocated duration for UL or DL without P2P. The AP can use a CTS-to-TXOP shared STA so that the TXOP shared STA can use the allocated duration for P2P mainly.

[0135] FIG. 14 A flow diagram illustrating a process 1400 that can be performed at a first wireless node in accordance with some aspects of the present disclosure is shown. Operations of the process 1400 can be implemented by a first wireless node or its components as described herein. For example, the process 1400 can be performed by a wireless communication device operating as or within a first wireless node, such as the wireless communication device 1800 described with reference to FIG. 18. In some examples, the process 1400 can be performed by a first wireless node, such as one of the wireless APs 102 or STAs 104 described with reference to FIG. 1. The operations of the process 1400 and the subject matter of the present disclosure can be suitable for use in different systems. For example, the operations of the process 1400 and the subject matter of the present disclosure can be applied in an 802.11s mesh system (as defined in the Institute of Electrical and Electronics Engineers (IEEE) 802.11), a simple mesh system (as defined in the Wi-Fi Alliance), and / or other mesh-based network systems. FIG. 18 FIG. 1 The operations of the process 1400 and the subject matter of the present disclosure can be suitable for use in different systems. For example, the operations of the process 1400 and the subject matter of the present disclosure can be applied in an 802.11s mesh system (as defined in the Institute of Electrical and Electronics Engineers (IEEE) 802.11), a simple mesh system (as defined in the Wi-Fi Alliance), and / or other mesh-based network systems.

[0136] At 1410, the process 1400 includes the first wireless node outputting, for transmission, a first frame configured to allow a third wireless node to transmit to a second wireless node during a transmission opportunity (TXOP) shared with the second wireless node and to prevent transmissions from a fourth wireless node during the shared TXOP.

[0137] At 1420, the process 1400 includes the first wireless node performing one or more actions during the shared TXOP.

[0138] ​In some aspects, the first frame is configured to at least one of set a first network allocation vector (NAV) of a first type during the shared TXOP, where the first NAV allows the third wireless node to transmit to the second wireless node during the shared TXOP, or set a second NAV of a second type for a fourth wireless node, where the second NAV prevents transmissions from the fourth wireless node during the shared TXOP.

[0139] In some aspects, the first frame includes scheduling information for at least the second wireless node.

[0140] In some aspects, the scheduling information indicates at least one of when the at least second wireless node is allowed to transmit, or when the at least second wireless node is to defer channel access.

[0141] In some aspects, the scheduling information indicates when the fourth wireless node is to defer its channel access.

[0142] In some aspects, the scheduling information indicates a total duration of the shared TXOP.

[0143] In some aspects, for each wireless node of one or more wireless nodes including at least the second node, the scheduling information indicates a minimum duration that the first wireless node intends to share the TXOP with the wireless node.

[0144] In some aspects, the first frame is further configured to trigger the shared TXOP.

[0145] In one aspect, the method 1400, or any aspect related thereto, can be performed by a device such as the wireless communication device 1800 described with reference to FIG. 18 The communication device 1100 is described in more detail below.

[0146] Note that FIG. 14 The method 1400 is merely one example, and other methods including fewer, additional, or alternative steps are possible depending on the circumstances.

[0147] FIG. 15 A flow diagram illustrating a process 1500 that can be performed at a second wireless node in accordance with some aspects of the present disclosure is shown. The operations of process 1500 can be implemented by a first wireless node or its components as described herein. For example, the process 1500 can be performed by a wireless communication device operating as or within a first wireless node, such as the wireless communication device 1800 described with reference to FIG. 18 In some examples, the process 1500 can be performed by a first wireless node, such as the wireless communication device 1800 described with reference to FIG. 1The operations of process 1500 and the subject matter of the present disclosure can be applicable to different systems. For example, the operations of process 1500 and the subject matter of the present disclosure can be applied to an 802.11s mesh system (as defined in the Institute of Electrical and Electronics Engineers (IEEE) 802.11), a simple mesh system (as defined in the WiFi Alliance), and / or other mesh-based network systems.

[0148] At 1510, the process 1500 includes the second wireless node obtaining a first frame configured to allow a third wireless node to transmit to the second wireless node and to prevent transmission from a fourth wireless node during a transmit opportunity (TXOP) shared by the first wireless node and the second wireless node.

[0149] At 1520, the process 1500 includes the second wireless node performing one or more actions during the shared TXOP.

[0150] In some aspects, the first frame includes scheduling information for at least the second wireless node, the scheduling information indicating at least one of: when the at least second wireless node is allowed to transmit; or when the at least second wireless node is to defer channel access.

[0151] In some aspects, the method 1500 further includes obtaining a second frame configured to trigger the shared TXOP. In some cases, the operations of this step refer to, are performed by, or are performed with, the circuitry for obtaining and / or the code for obtaining as described with reference to FIG. 18

[0152] In some aspects, the first frame includes a clear to send (CTS) frame.

[0153] In some aspects, the first frame has a first address set to an address associated with the second wireless node.

[0154] In some aspects, the first address includes a receive address (RA) set to an address associated with a group to which the second wireless node belongs.

[0155] In some aspects, the one or more actions include at least one of: outputting at least a second frame indicating that the shared TXOP is terminated early by the second wireless node; or obtaining at least a third frame configured to release or return at least a portion of the shared TXOP.

[0156] In one aspect, the method 1500, or any aspect related thereto, can be performed by an apparatus such as FIG. 18 ​The wireless communication device 1100 performs the method 1500, which includes various components capable of operating, being configured, or adapted to perform the method. The communication device 1100 is described in more detail below.

[0157] It should be noted that FIG. 15 This is merely one example of a method, and other methods consistent with this disclosure, including fewer, additional, or alternative steps, are possible.

[0158] FIG. 16 A flowchart illustrating a process 1600 that can be executed at a wireless node according to some aspects of this disclosure is shown. Operation of process 1600 may be implemented by a first wireless node or its components as described herein. For example, process 1600 may be implemented by a wireless communication device (such as reference 1600) operating as or within the first wireless node. FIG. 18 The described wireless communication device 1800 performs this process. In some examples, process 1600 may be performed by a first wireless node (such as a reference 1800). FIG. 1 The procedure 1600 is performed by either the described wireless AP 102 or STA 104. The operation of procedure 1600 and the subject matter of this disclosure are applicable to different systems. For example, the operation of procedure 1600 and the subject matter of this disclosure are applicable to 802.11s mesh systems (as defined in IEEE 802.11), simplified mesh systems (as defined in the WiFi Alliance), and / or other mesh-based network systems.

[0159] At 1610, process 1600 includes the wireless node outputting a first frame for transmission, the first frame including a request for setting the network allocation vector (NAV) associated with the shared transmission opportunity (TXOP).

[0160] At 1620, process 1600 includes the wireless node acquiring the second frame that triggers the shared TXOP.

[0161] At 1630, process 1600 includes the wireless node communicating using the NAV set according to the request during the shared TXOP.

[0162] In some respects, at least the first of the different durations corresponds to the duration of the shared TXOP.

[0163] In some aspects, the selected NAV setting has a second duration shorter than the first duration; and the method further includes obtaining one or more signals after the NAV set according to the second duration expires.

[0164] In some respects, the request includes a field indicating the duration of the NAV settings.

[0165] In some aspects, the first frame includes a request for a shared transmit opportunity (TXOP).

[0166] In some aspects, the request is for: the network allocation vector (NAV) setting to be applied to only the shared TXOP; or the periodic allocation of the NAV setting to be applied to a shared TXOP.

[0167] In one aspect, the method 1600, or any aspect related thereto, can be performed by a device such as FIG. 18 the wireless communication device 1800, including various components capable of performing the method 1600, as described in more detail below. The communication device 1100 is described in more detail below.

[0168] Note that FIG. 16 The method 1600 is just one example, and other methods including fewer, additional, or alternative steps are possible depending on the circumstances.

[0169] FIG. 17 A flow diagram illustrating a process 1700 that can be performed at a wireless node in accordance with some aspects of the present disclosure is shown. The operations of process 1700 can be implemented by a first wireless node or its components as described herein. For example, process 1700 can be performed by a wireless communication device operating as or within a first wireless node, such as the wireless communication device 1800 described with reference to FIG. 18 In some examples, process 1700 can be performed by a first wireless node, such as one of the wireless APs 102 or STAs 104 described with reference to FIG. 1 The operations of process 1700 and the subject matter of the present disclosure can be applicable to different systems. For example, the operations of process 1700 and the subject matter of the present disclosure can be applied to an 802.11s mesh system (as defined in the Institute of Electrical and Electronics Engineers (IEEE) 802.11), a simple mesh system (as defined in the Wi-Fi Alliance), and / or other mesh-based network systems.

[0170] At 1710, the process 1700 includes the wireless node obtaining a first frame including a request for a network allocation vector (NAV) setting associated with a shared transmit opportunity (TXOP).

[0171] At 1720, the process 1700 includes the wireless node outputting for transmission a second frame triggering the shared TXOP.

[0172] At 1730, the process 1700 includes the wireless node communicating during the shared TXOP in accordance with the request.

[0173] In some aspects, the request includes a field indicating a selection of the NAV setting from a plurality of NAV settings having different durations.

[0174] In some aspects, at least a first duration of the different durations corresponds to a duration of the shared TXOP.

[0175] In some aspects, the request includes a field indicating a duration of the NAV setting.

[0176] In some aspects, the first frame includes a request for the shared TXOP.

[0177] In some aspects, the request is for: the NAV setting to be applied to only the shared TXOP; or the NAV setting to be applied to periodic allocations of the shared TXOP.

[0178] In one aspect, the method 1700, or any aspect related thereto, can be performed by a device such as the wireless communication device 1800, which includes various components able to operate, configured to, or adapted to, perform the method 1700. The communication device 1100 is described in greater detail below. FIG. 18

[0179] Note that, FIG. 17 The method is just one example, and other methods including fewer, additional, or alternative steps are possible consistent with the present disclosure.

[0180] FIG. 18 A block diagram of a wireless communication device 1800, such as an AP or a non-AP STA, in accordance with some aspects of the present disclosure is shown. In one example, the wireless communication device 1800 is configured as or is able to operate the process 1400 described with reference to FIG. 14 In another example, the wireless communication device 1800 is configured as or is able to operate the process 1500 described with reference to FIG. 15 In another example, the wireless communication device 1800 is configured as or is able to operate the process 1600 described with reference to FIG. 16 In another example, the wireless communication device 1500 is configured as or is able to operate the process 1700 described with reference to FIG. 17 In various examples, the wireless communication device 1800 can be a chip, SoC, chipset, package, or a device that can include one or more modems (such as a Wi-Fi (IEEE 802.11) modem or a cellular modem, such as a 3GPP 4G LTE or 5G compliant modem), one or more processors, processing blocks, or processing elements (collectively “processors”), one or more radio parts (collectively “radio parts”), and one or more memories or memory blocks (collectively “memory”).

[0181] ​In some examples, the wireless communication device 1800 can be a device for use in an AP, such as the AP 102 described with reference to FIG. 1

[0182] The wireless communication device 1800 includes an obtaining component 1802, an outputting component 1804, a determining component 1806, an performing component 1808, a communicating component 1810, a selecting component 1812, and / or an including component 1814.

[0183] Portions of one or more of the components 1802, 1804, 1806, 1808, 1810, 1812, and / or 1814 can be implemented at least in part in hardware or firmware. For example, the obtaining component 1802 and the outputting component 1804 can be implemented at least in part by a modem. In some examples, at least some of the components 1802, 1804, 1806, 1808, 1810, 1812, and / or 1814 are implemented at least in part by a processor and are realized as software stored in a memory. For example, portions of one or more of the components 1802, 1804, 1806, 1808, 1810, 1812, and / or 1814 can be implemented as non-transitory instructions (or “code”) executable by a processor to perform the functions or operations of the respective module.

[0184] ​In some implementations, the processor may be a component of a processing system. A processing system generally refers to a system or series of machines or components that receive inputs and process those inputs to produce a set of outputs (which may be passed to other systems or components, such as wireless communication device 1800). For example, the processing system of wireless communication device 1800 may refer to a system that includes various other components or sub-components of wireless communication device 1800, such as a processor, transceiver, communication manager, or other components or combinations thereof of wireless communication device 1800. The processing system of wireless communication device 1800 may interface with other components of wireless communication device 1800 and may process information received from other components (such as inputs or signals) or output information to other components. For example, the chip or modem of wireless communication device 1800 may include a processing system, a first interface for outputting information, and a second interface for receiving information. In some implementations, the first interface may refer to the interface between the processing system of the chip or modem and a transmitter, enabling wireless communication device 1800 to transmit information output from the chip or modem. In some specific implementations, the second interface may refer to the interface between the processing system of the chip or modem and the receiver, enabling the wireless communication device 1800 to receive information or signal input, and such information to be transmitted to the processing system. Those skilled in the art will readily recognize that the first interface can also receive information or signal input, and the second interface can also output information or signal output.

[0185] Various components of the wireless communication device 1800 can provide for performing reference. FIG. 14 The described process 1400, reference FIG. 15 The described process 1500, reference FIG. 16 The described process 1600, reference FIG. 17 The described process 1700 or any aspect thereof. Components for receiving or obtaining may include references. FIG. 1 The described AP 102 includes a transceiver and / or antenna, and / or a wireless communication device 1800, comprising component 1802. Components for transmitting, conveying, or outputting for transmission may include references. FIG. 1 The transceiver and / or antenna of the described AP 102, and / or the output component 1804 of the wireless communication device 1800.

[0186] The component used for identification may include a reference. FIG. 1 The described AP 102 includes one or more processors (such as a receive processor, controller, and / or transmit processor), and / or a defined component 1806 of the wireless communication device 1800. Components used for execution may include references. FIG. 1One or more processors of the described AP 102, such as a receive processor, a controller, and / or a transmit processor, and / or the execution component 1808 of the wireless communication device 1800. Means for communicating can include the FIG. 1 One or more processors of the described AP 102, such as a receive processor, a controller, and / or a transmit processor, and / or the communication component 1810 of the wireless communication device 1800. Means for selecting can include the FIG. 1 One or more processors of the described AP 102, such as a receive processor, a controller, and / or a transmit processor, and / or the selection component 1812 of the wireless communication device 1800. Means for including can include the FIG. 1 One or more processors of the described AP 102, such as a receive processor, a controller, and / or a transmit processor, and / or the inclusion component 1814 of the wireless communication device 1800.

[0187] In some cases, the wireless communication device 1100 can not actually transmit, for example, signals and / or data, but can have an interface (means for outputting) for outputting signals and / or data for transmission. For example, a processor can output signals and / or data to a radio frequency (RF) front end of the wireless communication device 1800 via a bus interface for transmission. In various aspects, the RF front end can include various components including transmit and receive processors, transmit and receive MIMO processors, modulators, demodulators, etc.

[0188] In some cases, the wireless communication device 1800 can not actually receive signals and / or data, but can have an interface (means for obtaining) for obtaining signals and / or data received from another device. For example, a processor can obtain (or receive) signals and / or data from an RF front end of the wireless communication device 1800 via a bus interface for reception. In various aspects, the RF front end can include various components including transmit and receive processors, transmit and receive MIMO processors, modulators, demodulators, etc.

[0189] Example clauses Various implementation examples are described in the following numbered clauses: Clause 1: A method for wireless communication at a first wireless node, comprising: outputting, for transmission, a first frame configured to allow a third wireless node to transmit to a second wireless node during a transmission opportunity (TXOP) shared with the second wireless node and to prevent transmission from a fourth wireless node during the shared TXOP; and performing one or more actions during the shared TXOP.

[0190] Clause 2: The method of clause 1, wherein the first frame is configured to at least one of: set a first network allocation vector (NAV) of a first type during the shared TXOP, wherein the first NAV allows the third wireless node to transmit to the second wireless node during the shared TXOP, or set a second NAV of a second type for the fourth wireless node, wherein the second NAV prevents transmission from the fourth wireless node during the shared TXOP.

[0191] Clause 3: The method of any of clauses 1-2, wherein the first frame includes scheduling information for at least the second wireless node.

[0192] Clause 4: The method of clause 3, wherein the scheduling information indicates at least one of: when at least the second wireless node is allowed to transmit; or when at least the second wireless node is to defer channel access.

[0193] Clause 5: The method of clause 3, wherein the scheduling information indicates when the fourth wireless node is to defer its channel access.

[0194] Clause 6: The method of clause 3, wherein the scheduling information indicates a total duration of the shared TXOP.

[0195] Clause 7: The method of clause 3, wherein the scheduling information indicates, for each of one or more wireless nodes including at least the second node, a minimum duration for which the first wireless node intends to share the TXOP with the wireless node.

[0196] Clause 8: The method of any of clauses 1-7, wherein the first frame is further configured to trigger the shared TXOP.

[0197] Clause 9: The method of any of clauses 1-8, the method further comprising outputting for transmission a second frame configured to trigger the shared TXOP.

[0198] Clause 10: The method of clause 9, wherein the first frame is output for transmission prior to the second frame.

[0199] Clause 11: The method of any of clauses 1-10, wherein the first frame comprises a clear to send (CTS) frame.

[0200] Clause 12: The method of any of clauses 1-11, the method further comprising determining whether the first frame is successfully received by the second wireless node, wherein the one or more actions are dependent on the determination.

[0201] Clause 13: The method of clause 12, further comprising obtaining a response frame from the second wireless node, wherein the determination that the first frame was successfully received by the second wireless is based on the response frame.

[0202] Clause 14: The method of clause 13, wherein, in a case that the determination indicates that the first frame was not successfully received by the second wireless node, the one or more actions comprise outputting for transmission at least a third frame configured to at least one of: reset a first network allocation vector (NAV) set by the first frame; reset a second NAV set by the first frame; or communicate data to another wireless node.

[0203] Clause 15: The method of any of clauses 1-14, wherein the first frame has a first address set to an address associated with the second wireless node.

[0204] Clause 16: The method of clause 15, wherein the first address comprises a receive address (RA).

[0205] Clause 17: The method of clause 16, wherein the RA is set to an address associated with a group to which the second wireless node belongs.

[0206] Clause 18: The method of clause 17, further comprising outputting for transmission an indication of at least one of the address associated with the group or one or more identifiers of wireless nodes belonging to the group.

[0207] Clause 19: The method of clause 17, further comprising obtaining a frame requesting an address to be used to set a RA, wherein the RA of at least one of the first frame or a second frame is set to the requested address.

[0208] Clause 20: The method of any of clauses 1-19, wherein the one or more actions comprise obtaining, from the second wireless node, at least a third frame indicating an early termination of the shared TXOP.

[0209] Clause 21: The method of any of clauses 1-20, wherein the one or more actions comprise outputting for transmission at least a third frame configured to release or return at least a portion of the shared TXOP.

[0210] Clause 22: The method of clause 21, wherein a header of the third frame comprises an indication of the release or the return.

[0211] Clause 23: The method of any one of clauses 1-22, wherein the first frame is further configured to at least one of: prevent communication between the second wireless node and the third wireless node during a portion of the shared TXOP. Or allow communication between the second wireless node and the third wireless node during another portion of the shared TXOP.

[0212] Clause 24: A method for wireless communications at a second wireless node, comprising: outputting, for transmission, a first frame configured to allow a third wireless node to transmit to the second wireless node and prevent transmission from a fourth wireless node during a transmission opportunity (TXOP) shared by a first wireless node and the second wireless node; and performing one or more actions during the shared TXOP.

[0213] Clause 25: The method of clause 24, wherein the first frame includes scheduling information for at least the second wireless node, the scheduling information indicating at least one of: when at least the second wireless node is allowed to transmit; or when at least the second wireless node is to defer channel access.

[0214] Clause 26: The method of any one of clauses 24-25, further comprising obtaining a second frame configured to trigger the shared TXOP.

[0215] Clause 27: The method of any one of clauses 24-26, wherein the first frame comprises a clear to send (CTS) frame.

[0216] Clause 28: The method of any one of clauses 24-27, wherein the first frame has a first address set to an address associated with the second wireless node.

[0217] Clause 29: The method of clause 28, wherein the first address comprises a receive address (RA) set to an address associated with a group to which the second wireless node belongs.

[0218] Clause 30: The method of any one of clauses 24-29, wherein the one or more actions comprise at least one of: outputting at least a second frame indicating early termination of the shared TXOP by the second wireless node; or obtaining at least a third frame configured to release or return at least a portion of the shared TXOP.

[0219] Clause 31: A method for wireless communications at a wireless node, comprising: outputting, for transmission, a first frame comprising a request for a network allocation vector (NAV) setting associated with a shared transmit opportunity (TXOP); obtaining a second frame triggering the shared TXOP; and communicating during the shared TXOP with the NAV set according to the request.

[0220] Clause 32: The method of clause 31, further comprising: selecting the NAV setting from a plurality of NAV settings having different durations; and including in the request a field indicating the selected NAV setting.

[0221] Clause 33: The method of claim 32, wherein at least a first duration of the different durations corresponds to a duration of the shared TXOP.

[0222] Clause 34: The method of clause 33, wherein: the selected NAV setting has a second duration that is shorter than the first duration; and the method further comprises obtaining one or more signals after expiration of the NAV set according to the second duration.

[0223] Clause 35: The method of any of clauses 31-34, wherein the request comprises a field indicating a duration of the NAV setting.

[0224] Clause 36: The method of any of clauses 31-35, wherein the first frame comprises a request for the shared TXOP.

[0225] Clause 37: The method of any of clauses 31-36, wherein the request is for: the NAV setting to be applied to only the shared TXOP; or the NAV setting to be applied to a periodic allocation of shared TXOPs.

[0226] Clause 38: A method for wireless communications at a wireless node, comprising: obtaining a first frame comprising a request for a network allocation vector (NAV) setting associated with a shared transmit opportunity (TXOP); outputting a second frame triggering the shared TXOP; and communicating during the shared TXOP according to the request.

[0227] Clause 39: The method of clause 38, wherein the request comprises a field indicating selection of the NAV setting from a plurality of NAV settings having different durations.

[0228] Clause 40: The method of claim 39, wherein at least a first duration of the different durations corresponds to a duration of the shared TXOP.

[0229] Clause 41 : The method of any one of clauses 38-40, wherein the request includes a field indicating a duration of the NAV setting.

[0230] Clause 42: The method of any one of clauses 38-41, wherein the first frame includes a request for the shared TXOP.

[0231] Clause 43: The method of any one of clauses 38-42, wherein the request is for: the NAV setting to be applied to only the shared TXOP; or the NAV setting to be applied to periodic allocation of shared TXOPs.

[0232] Clause 44: An apparatus comprising: a memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the apparatus to perform the method of any one of clauses 1-43.

[0233] Clause 45: An apparatus comprising means for performing the method of any one of clauses 1-43.

[0234] Clause 46: A non-transitory computer-readable medium comprising executable instructions that, when executed by at least one processor of an apparatus, cause the apparatus to perform the method of any one of clauses 1-43.

[0235] Clause 47: A computer program product embodied on a computer-readable storage medium comprising code for performing the method of any one of clauses 1-43.

[0236] Clause 48: An access point comprising: at least one transceiver; a memory including executable instructions; and a processor configured to execute the executable instructions and cause the access point to perform the method of any one of clauses 1-23, wherein the at least one transceiver is configured to transmit the first frame.

[0237] Clause 49: A wireless station comprising: at least one transceiver; a memory including executable instructions; and a processor configured to execute the executable instructions and cause the wireless station to perform the method of any one of clauses 24-30, wherein the at least one transceiver is configured to receive the first frame.

[0238] Clause 50: A wireless station, comprising: at least one transceiver; a memory comprising executable instructions; and a processor configured to execute the executable instructions and cause the wireless station to perform the method of any of clauses 31-37, wherein the at least one transceiver is configured to at least one of: transmit the first frame or receive the second frame.

[0239] Clause 51: An access point, comprising: at least one transceiver; a memory comprising executable instructions; and a processor configured to execute the executable instructions and cause the access point to perform the method of any of clauses 38-43, wherein the at least one transceiver is configured to at least one of: receive the first frame or transmit the second frame.

[0240] Additional considerations As used herein, the term “determining” encompasses a wide variety of actions and, therefore, “determining” can include calculating, computing, processing, deriving, investigating, looking up (such as via a table, a database, or another data structure), inferring, and the like. Also, “determining” can include receiving (such as receiving information), accessing (such as accessing data in a memory), and the like. Also, “determining” can include resolving, selecting, choosing, establishing, and the like.

[0241] As used herein, the phrase “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c. As used herein, “or” is intended to be interpreted in an inclusive sense unless otherwise indicated. For example, the phrase “a or b” is intended to cover a, b, or a combination of a and b.

[0242] As used herein, “or” is intended to be interpreted in an inclusive sense unless otherwise indicated. For example, “based on” can be used interchangeably with “based, at least in part, on,” “associated with,” or “according to” unless otherwise indicated. Specifically, unless the phrase “based on ‘one’” or equivalent is used in the context, it can be based on “one” alone or on a combination of “one” and one or more other factors, conditions, or information whether it is “based on ‘one’” or “based on ‘one’ at least in part.”

[0243] The various illustrative components, logic, blocks, modules, circuits, operations and algorithm processes described in connection with the examples disclosed herein can be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of their functionality, and herein with respect to the various illustrative components, blocks, modules, circuits and processes described throughout this specification. Such functionality can be implemented in hardware, firmware or software, depending on the particular application.

[0244] Various modifications to the examples described in this disclosure will be readily apparent to those of ordinary skill in the art, and the generic principles defined herein can be applied to other examples without departing from the spirit or scope of the disclosure. Thus, the claims are not intended to be limited to the examples shown herein, but are to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0245] Additionally, various features that are described in the context of separate examples can also be implemented in combination with each other. Conversely, various features that are described in the context of a single example can also be implemented on a number of examples individually or in any suitable sub-combination. As such, although the features can be described above as acting in a specific combination and even initially claimed as such, one or more features from a claimed combination can in some cases be deleted from the combination in accordance with some embodiments and the claimed combination can be directed to a sub-combination or variation of a sub-combination.

[0246] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring such an order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings can schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are illustrated. For example, one or more additional operations can be performed before, after, simultaneously with, or between any of the illustrated operations. In some environments, multitasking and parallel processing can be advantageous. Moreover, the separation of various system components in the examples described above should not be understood as requiring such separation in all examples, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products.

Claims

1. An apparatus for performing wireless communication at a first wireless node, the apparatus comprising: At least one processor; A memory coupled to the processor; as well as Instructions, which are stored in the memory and can be executed by the at least one processor, to cause the device to: Output the first frame for transmission. The first frame is configured as follows: During the Transmission Opportunity (TXOP) shared with the second wireless node, the third wireless node is permitted to transmit to the second wireless node, and Prevent transmission from a fourth wireless node during the shared TXOP; as well as One or more actions are performed during the shared TXOP.

2. The apparatus according to Clause 1, wherein the first frame is configured to perform at least one of the following: During the shared TXOP, a first network allocation vector (NAV) of a first type is set, wherein the first NAV allows the third wireless node to transmit to the second wireless node during the shared TXOP, or A second type of second NAV is set for the fourth wireless node, wherein the second NAV prevents transmissions from the fourth wireless node during the shared TXOP.

3. The apparatus of claim 1, wherein the first frame includes scheduling information for at least the second wireless node.

4. The apparatus of claim 3, wherein the scheduling information indicates at least one of the following: At least when is the second wireless node permitted to transmit; or At least when the second wireless node should postpone channel access.

5. The apparatus of claim 3, wherein the scheduling information indicates when the fourth wireless node should postpone its channel access.

6. The apparatus of claim 3, wherein the scheduling information indicates the total duration of the shared TXOP.

7. The apparatus of claim 3, wherein for each of one or more wireless nodes including at least the second wireless node, the scheduling information indicates that the first wireless node intends to share the minimum duration of the TXOP with the wireless node.

8. The apparatus of claim 1, wherein the first frame is further configured to trigger the shared TXOP.

9. The apparatus of claim 1, wherein the instructions stored in the memory and executable by the at least one processor further cause the apparatus to output a second frame for transmission, the second frame being configured to trigger the shared TXOP.

10. The apparatus of claim 9, wherein the first frame is output for transmission prior to the second frame.

11. The apparatus of claim 1, wherein the first frame includes a transmit-allowed (CTS) frame.

12. The apparatus of claim 1, wherein the instructions stored in the memory and executable by the at least one processor further cause the apparatus to determine whether the first frame has been successfully received by the second wireless node, wherein one or more actions depend on the determination.

13. The apparatus of claim 12, wherein the instructions stored in the memory and executable by the at least one processor further cause the apparatus to: A response frame is obtained from the second wireless node, wherein the determination that the first frame was successfully received by the second wireless node is based on the response frame.

14. The apparatus of claim 13, wherein, in the case that the determination indicates that the first frame was not successfully received by the second wireless node, the one or more actions include outputting at least a third frame for transmission, the third frame being configured to perform at least one of the following: resetting a first network allocation vector (NAV) set by the first frame; resetting a second NAV set by the first frame; or transmitting data to another wireless node.

15. The apparatus of claim 1, wherein the first frame has a first address configured to be associated with the second wireless node.

16. The apparatus of claim 15, wherein the first address includes a receiving address (RA).

17. The apparatus of claim 16, wherein the RA is configured as an address associated with the group to which the second wireless node belongs.

18. The apparatus of claim 17, wherein the instructions stored in the memory and executable by the at least one processor further cause the apparatus to perform at least one of the following: Output an indication of at least one of the address associated with the group or one or more identifiers of one or more wireless nodes belonging to the group for transmission; or Obtain a frame requesting the setting of an address for an RA, wherein the RA in at least one of the first or second frames is set to the requested address.

19. The apparatus of claim 1, wherein the one or more actions comprise at least one of the following: Obtain at least a third frame from the second wireless node indicating the early termination of the shared TXOP; or Output at least a third frame for transmission, the third frame being configured to release or return at least a portion of the shared TXOP.

20. The apparatus of claim 19, wherein the header of the third frame includes an indication of the release or the return.

21. The apparatus of claim 1, wherein the first frame is further configured to perform at least one of the following: Prevent communication between the second wireless node and the third wireless node during a portion of the shared TXOP; or Communication between the second wireless node and the third wireless node is permitted during another portion of the shared TXOP.

22. The apparatus according to claim 1, further comprising: At least one transceiver configured to transmit the first frame, wherein the device is configured as an access point (AP).

23. An apparatus for performing wireless communication at a second wireless node, the apparatus comprising: At least one processor; A memory coupled to the processor; as well as Instructions, which are stored in the memory and can be executed by the processor, to cause the device to: The first frame is obtained, and the first frame is configured as follows: During the Transmission Opportunity (TXOP) shared by the first and second wireless nodes, the third wireless node is permitted to transmit to the second wireless node, and Prevent transmission from a fourth wireless node during the shared TXOP; as well as One or more actions are performed during the shared TXOP.

24. The apparatus of claim 23, wherein the first frame includes scheduling information for at least the second wireless node, the scheduling information indicating at least one of the following: At least when is the second wireless node permitted to transmit; or At least when the second wireless node should postpone channel access.

25. The apparatus of claim 23, wherein the instructions stored in the memory and executable by the at least one processor further cause the apparatus to obtain a second frame, the second frame being configured to trigger the shared TXOP.

26. The apparatus of claim 23, wherein the first frame satisfies at least one of the following: Including the Allow Transmission (CTS) frame; or A first address has an address that is set to be associated with the second wireless node.

27. The apparatus of claim 26, wherein the first address includes a receiving address (RA), the receiving address (RA) being configured as an address associated with the group to which the second wireless node belongs.

28. The apparatus of claim 23, wherein the one or more actions comprise at least one of the following: The output indicates that the second wireless node prematurely terminates at least the second frame of the shared TXOP; or Obtain at least a third frame that is configured to release or return at least a portion of the shared TXOP.

29. The apparatus of claim 23, further comprising: At least one transceiver configured to receive the first frame, wherein the means is configured as a wireless station.

30. A method for performing wireless communication at a first wireless node, the method comprising: Output the first frame for transmission. The first frame is configured as follows: During the Transmission Opportunity (TXOP) shared with the second wireless node, the third wireless node is permitted to transmit to the second wireless node, and Prevent transmission from a fourth wireless node during the shared TXOP; as well as One or more actions are performed during the shared TXOP.

Images