Low latency schemes for peer-to-peer (P2P) communications

Abstract

This application provides systems, methods, and apparatus for managing data transfer volume during restricted Target Wake Time (TWT) service periods (SPs). In some embodiments, an access point (AP) receives a request frame from a radio station (STA) associated with a client device via a peer-to-peer (P2P) link. The request frame indicates that the STA intends to exchange P2P communication with the client device during a scheduled r-TWT SP on the radio medium. During the r-TWT SP, the AP acquires a Transmission Opportunity (TXOP) on the radio medium, and the request frame identifies the client device. In response to acquiring the TXOP, the AP sends a trigger frame on the radio medium, which is a portion of the acquired TXOP allocated for P2P communication between the STA and the client device, wherein at least one of the response frame or the trigger frame indicates a Network Assignment Vector (NAV) anomaly for the client device.

Description

[Technical Field]

[0001] This patent application claims priority to U.S. Patent Application No. 17 / 482,417, filed on September 22, 2021, entitled “LOW LATENCY SCHEMES FOR PEER-TO-PEER (p2p) COMMUNICATIONS,” which has been assigned to the assignee of this application and is expressly incorporated herein by reference.

[0002] In summary, this case concerns wireless communications, and more specifically, the amount of data transmitted during managed target wake-up time (TWT) service periods. [Previous Technology]

[0003] A Wireless Local Area Network (WLAN) can be formed by one or more access points (APs) that provide a shared wireless medium for use by multiple client devices or stations (STAs). Each AP, which may correspond to a Basic Service Set (BSS), can periodically broadcast beacon frames, enabling any STA within the wireless range of that AP to establish and maintain a communication link with the WLAN. WLANs operating according to the IEEE 802.11 standard family are often referred to as Wi-Fi networks.

[0004] Some wireless communication devices can be associated with low-latency applications that have stringent end-to-end latency, throughput, and timing requirements for data transfer. Examples of low-latency applications include, but are not limited to, real-time gaming applications, video communications, and augmented reality (AR) and virtual reality (VR) applications (collectively referred to as extended reality (XR) applications). Such low-latency applications may specify various latency, throughput, and timing requirements for the wireless communication systems providing connectivity to these applications. Therefore, it is desirable to ensure that WLANs can meet the various latency, throughput, and timing requirements of such low-latency applications. [Summary of the Invention]

[0005] The systems, methods and apparatuses contained in this case each have several innovative forms, and no single form is solely responsible for the desired properties disclosed herein.

[0006] One innovative aspect of the subject matter described in this case can be implemented as a method for wireless communication by an access point (AP). In some implementations, the method may include receiving a request frame from a radio station (STA) associated with the AP and also associated with a client device via a peer-to-peer (P2P) link, the request frame indicating that the STA intends to exchange P2P communication with the client device during a scheduled restricted target wake-up time (r-TWT) service period (SP) on the radio medium, the request frame identifying the client device. The method may include sending a response frame to the STA on the radio medium in response to receiving the request frame. The method may include obtaining a transmission opportunity (TXOP) on the radio medium during the r-TWT SP. The method may include sending a trigger frame on the radio medium in response to obtaining the TXOP, the trigger frame allocating a portion of the obtained TXOP for P2P communication between the STA and the client device, wherein at least one of the response frame or the trigger frame indicates a network allocation vector (NAV) anomaly for the client device. In some configurations, each item in the response and trigger frames includes the client device's Media Access Control (MAC) address. In some implementations, a NAV exception indicates that the client device will ignore both the NAV duration indicated by the trigger frame and the NAV duration indicated by the Clear Send (CTS) frame in response to the trigger frame. In some configurations, the CTS frame includes the client device's MAC address.

[0007] In some other implementations, the STA includes a co-located softAP configured to communicate with a client device, and at least one of the response frame or trigger frame also indicates a NAV exception for the co-located softAP. In some cases, the NAV exception indicates that the softAP co-located with the STA belonging to the r-TWT SP will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the CTS frame responding to the trigger frame. The request frame may indicate the MAC address of the co-located softAP to the AP, and each of the trigger frame and the CTS frame may include the MAC address of the co-located softAP. In some cases, the trigger frame includes a carrier sensing (CS) request field carrying a value set to 0 to indicate a NAV exception.

[0008] In various implementations, the request frame indicates the MAC address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the CTS frame in response to the trigger frame. In some implementations, the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device. The TWT element may indicate one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or the set of parameters of the r-TWT SP. In some cases, the response frame may be a TWT response frame including a TWT element indicating the set of TWT parameters used by the participating device for the r-TWT SP. In other implementations, the request frame is a Stream Classification Service (SCS) request frame including a Transport Specification (TSPEC) element indicating the MAC address of the client device. The TSPEC element can also indicate the minimum data rate for the r-TWT SP, the average data rate for the r-TWT SP, the latency limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. In some cases, the response frame can be an SCS response frame. In some other implementations, the request frame is a P2P request frame that includes one or more of the following: a TWT element, a TSPEC element, or a vendor-specific information element (VSIE) indicating at least the MAC address of the client device. The TWT element can indicate various TWT parameters proposed for the r-TWT SP, and the P2P element can indicate various P2P parameters proposed for the r-TWT SP. In some cases, the response frame can be a P2P response frame indicating how many devices are members of the r-TWT SP.

[0009] In some implementations, the trigger frame may be a Multi-User (MU) Request Transmit (RTS) TXOP Share (TXS) trigger frame including a TXOP Share Mode subfield indicating a TXOP share mode corresponding to P2P communication associated with a client device. In some cases, the TXOP Share Mode subfield indicates a request from the STA to send a CTS frame in response to the MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device. In some other implementations, the request frame indicates a first time period during which the STA intends to use the wireless media within the r-TWT SP, and the trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with the client device, the second time period being shorter than the first time period. In some cases, the second time period is based on the time period associated with the request for the CTS frame from the STA.

[0010] Another inventive aspect of the subject matter described in this case can be implemented in a wireless communication device. The wireless communication device may include at least one modem, at least one processor communicatively coupled to the at least one modem, and at least one memory communicatively coupled to the at least one processor. In some implementations, the at least one memory stores processor-readable code, which, when executed by the at least one processor in conjunction with the at least one modem, is configured to receive a request frame from a STA associated with an AP and also associated with a client device via a P2P link. The request frame indicates that the STA intends to exchange P2P communication with the client device during a scheduled r-TWT SP on the wireless medium, and the request frame identifies the client device. Execution of the processor-readable code is configured to, in response to receiving the request frame, send a response frame to the STA on the wireless medium. Execution of the processor-readable code is configured to obtain a TXOP on the wireless medium during the r-TWT SP. The execution of processor-readable code is configured to, in response to acquiring a TXOP, send a trigger frame on the wireless media, the trigger frame being a portion of the acquired TXOP allocated for P2P communication between the STA and the client device, wherein at least one of the response frame or the trigger frame includes a NAV exception for the client device.

[0011] In some implementations, each of the response frame and the trigger frame includes the MAC address of the client device. In some cases, the NAV exception indicates that the client device will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the CTS frame responding to the trigger frame. In some cases, the CTS frame indicates the MAC address of the client device.

[0012] In some other implementations, the STA includes a co-located softAP configured to communicate with a client device, and at least one of the response frame or trigger frame also indicates a NAV anomaly for the softAP. In some cases, the NAV anomaly indicates that the softAP co-located with the STA belonging to the r-TWT SP will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the CTS frame responding to the trigger frame. The request frame may indicate the MAC address of the co-located softAP to the AP, and each of the trigger frame and the CTS frame may include the MAC address of the co-located softAP. In some cases, the trigger frame includes a carrier sensing (CS) request field carrying a value set to 0 to indicate a NAV anomaly.

[0013] In various implementations, the request frame indicates the MAC address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the CTS frame in response to the trigger frame. In some implementations, the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device. The TWT element may indicate one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or the set of parameters of the r-TWT SP. In some cases, the response frame may be a TWT response frame including a TWT element indicating the set of TWT parameters used by the participating device for the r-TWT SP. In other implementations, the request frame is a Stream Classification Service (SCS) request frame including a Transport Specification (TSPEC) element indicating the MAC address of the client device. The TSPEC element can also indicate the minimum data rate for the r-TWT SP, the average data rate for the r-TWT SP, the latency limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. In some cases, the response frame can be an SCS response frame. In some other implementations, the request frame is a P2P request frame that includes one or more of the following: a TWT element, a TSPEC element, or a vendor-specific information element (VSIE) indicating at least the MAC address of the client device. The TWT element can indicate various TWT parameters proposed for the r-TWT SP, and the P2P element can indicate various P2P parameters proposed for the r-TWT SP. In some cases, the response frame can be a P2P response frame indicating how many devices are members of the r-TWT SP.

[0014] In some implementations, the trigger frame may be a MU-RTS TXS trigger frame including a TXOP sharing mode subfield indicating a TXOP sharing mode corresponding to P2P communication associated with a client device. In some cases, the TXOP sharing mode subfield indicates a request from the STA to send a CTS frame in response to the MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device. In some other implementations, the request frame indicates a first time period during which the STA intends to use the wireless media within the r-TWT SP, and the trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with the client device, the second time period being shorter than the first time period. In some cases, the second time period is based on the time period associated with the request for the CTS frame from the STA.

[0015] Details of one or more implementations of the subject matter described in this case are set forth in the following figures and description. Other features, appearances, and advantages will become apparent from this description, figures, and claims. Note that the relative dimensions in the following figures may not be drawn to scale.

Implementation Method

[0045] For the purpose of describing the innovative aspects of the subject matter, the following description is directed to certain implementations. However, those skilled in the art will readily recognize that the teachings herein can be applied in many different ways. The described implementations can be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals according to Long Term Evolution (LTE), 3G, 4G, or 5G (New Radio (NR)) standards published by the 3rd Generation Partnership Project (3GPP), the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, the IEEE 802.15 standard, or the Bluetooth® standard defined by the Bluetooth Special Interest Group (SIG), and other standards. The described implementation can be implemented in any device, system, or network capable of transmitting and receiving RF signals according to one or more of the following technologies: Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Single User (SU) Multiple Input Multiple Output (MIMO), and Multiple User (MU) MIMO. The described implementation can also be implemented using other wireless communication protocols or RF signals suitable for use in one or more of the following wireless wide area networks (WWAN), wireless personal area networks (WPAN), wireless local area networks (WLAN), or Internet of Things (IoT) networks.

[0046] Many wireless networks use random channel access mechanisms to control access to shared wireless media. In such wireless networks, wireless communication devices (including access points (APs) and radio stations (STAs)) use Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) technology to contend with each other for access to the wireless media. Generally, the wireless communication device that randomly selects the lowest backoff number (RBO) wins the media access contention operation and is allowed to access the wireless media for a period of time (often called a Transmitter Opportunity (TXOP)). Other wireless communication devices are generally not allowed to transmit during another wireless communication device's TXOP to avoid collisions on the shared wireless media.

[0047] Some random channel access mechanisms (e.g., Enhanced Distributed Channel Access (EDCA)) provide high-priority transmission volumes, making them more likely to gain media access than low-priority transmission volumes. EDCA divides data into different access classes (ACs), such as, for example, Voice (AC_VO), Video (AC_VI), Maximum Effort (AC_BE), and Background (AC_BK). Each AC is associated with a different priority level and can be assigned a different range of RBOs, making higher-priority data more likely to win TXOPs than lower-priority data (e.g., by assigning lower RBOs to higher-priority data and higher RBOs to lower-priority data). Although EDCA increases the likelihood that low-latency data volumes will gain access to the shared wireless media during a given contention period, the unpredictable results of media access contention operations can prevent low-latency applications from achieving specific transmission volume levels or meeting specific latency requirements.

[0048] The IEEE 802.11be revision of the IEEE 802.11 standard describes a limited Target Wake-Up Time (TWT) service period (SP) that can be used to provide more predictable latency, reduced worst-case latency, or reduced signal interference, resulting in higher reliability for latency-sensitive traffic. As used herein, the term "non-traditional STA" can refer to any STA that supports limited TWT operation, while the term "low-latency STA" can refer to any non-traditional STA with latency-sensitive traffic to transmit or receive. In contrast, the term "traditional STA" can refer to any STA that does not support limited TWT operation. The IEEE 802.11be revision requires all non-traditional STAs that are TXOP holders outside of a limited TWT SP to terminate their respective TXOPs before the start of any other limited TWT SP (r-TWT SP) for which they are not members. Although membership in an r-TWT SP is reserved for low-latency STAs, current rules regarding r-TWT SPs do not prevent non-member STAs from acquiring TXOPs during an r-TWT SP. As a result, some non-member STAs can gain access to the shared radio media during the r-TWT SP even before members of the r-TWT SP can obtain channel access. Therefore, new communication protocols and / or new channel protection mechanisms are needed to further protect latency-sensitive transmissions associated with the r-TWT SP.

[0049] The various states generally involve latency-sensitive communications, and more specifically, involve ensuring that latency-sensitive traffic associated with an r-TWT SP is provided with sufficient channel access during the r-TWT SP to meet the various latency, throughput, and timing requirements of such latency-sensitive traffic. In some implementations, the AP can schedule an r-TWT SP for a low-latency STA with low-latency peer-to-peer (P2P) data to be transmitted or received on the radio medium. In some cases, the STA associated with the AP may include a co-located softAP associated with a client device with low-latency P2P communication to be transmitted or received. The softAP and its client device may be associated with a P2P link on which P2P communication can be exchanged between the softAP and the client device. Since neither the softAP nor the client device is associated with the AP, the AP may not identify the softAP or the client device in the trigger frame transmitted on the radio medium during the r-TWT SP. As a result, when the STA intends to use the wireless media for P2P communication associated with the softAP and client devices during the r-TWT SP, the softAP and client devices may inadvertently set their respective NAVs to the duration indicated by the trigger frame, and therefore may be unable to send or receive P2P communication with each other during the r-TWT SP.

[0050] In some implementations, the AP can receive a request frame from a STA associated with the AP and connected to a client device via a P2P link. The request frame indicates that the STA intends to exchange P2P communication with the client device during a scheduled r-TWT SP on the radio media. The request frame identifies the client device and may indicate one or more TWT parameters for the r-TWT SP. The AP may construct a Network Allocation Vector (NAV) exception for the client device based on the information received in the request frame and send a response frame to the STA. The AP may acquire a Transmission Opportunity (TXOP) on the radio media and may send a trigger frame on the radio media during the r-TWT SP. The trigger frame may be a portion of the acquired TXOP allocated for P2P communication between the STA and the client device. At least one of the response frame or the trigger frame indicates a NAV exception for the client. In some cases, the NAV exception indicates that the client device intends to ignore both the NAV duration indicated by the trigger frame and the NAV duration indicated by a Clear Send (CTS) frame in response to the trigger frame. In other words, an NAV anomaly can indicate that a client device will not set its NAV based on the NAV duration indicated by the trigger frame sent during the r-TWT SP. In some cases, the STA may include a co-located softAP that has or can establish a P2P link with the client device. NAV anomalies can also apply to co-located softAPs, for example, causing the co-located softAP to not set its NAV based on the NAV duration indicated by the trigger frame sent during the r-TWT SP.

[0051] A specific implementation of the subject matter described herein can be implemented to achieve one or more of the following potential advantages. By signaling NAV anomalies (which indicate that softAPs (and any associated P2P client devices) associated with or belonging to the r-TWT SP and connected to the AP will not set their respective NAVs for the duration indicated by a trigger frame sent from the AP during the r-TWT SP), the manner of the subject matter can ensure that such softAPs and their associated client devices can exchange delay-sensitive P2P communications with each other during the scheduled portion of the r-TWT SP. In this way, the implementation of the subject matter disclosed herein can ensure that delay-sensitive traffic or P2P communications associated with P2P devices are provided with enhanced channel protection mechanisms.

[0052] Figure 1 illustrates a block diagram of an example wireless communication network 100. Depending on the specific configuration, the wireless communication network 100 may be an example of a wireless local area network (WLAN) such as a Wi-Fi network (and will be referred to WLAN 100 below). For example, WLAN 100 may be a network implementing at least one of the IEEE 802.11 standard family (such as standards defined by the IEEE 802.11-2016 specification or its amendments, including but not limited to 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be). WLAN 100 may include a number of wireless communication devices, such as access points (APs) 102 and multiple stations (STAs) 104. Although only one AP 102 is illustrated, WLAN network 100 may also include multiple APs 102.

[0053] Each of STA 104 may also be referred to as a mobile station (MS), mobile device, mobile phone, wireless phone, access terminal (AT), user equipment (UE), user station (SS), or user unit, etc. STA 104 may represent various devices such as mobile phones, personal digital assistants (PDAs), other handheld devices, notebook computers, tablet computers, laptops, display devices (e.g., TVs, computer monitors, navigation systems, etc.), music or other audio or stereo devices, remote control devices ("remote controllers"), printers, kitchen or other household appliances, remote keys (e.g., for passive keyless entry and start (PKES) systems), and other possible devices.

[0054] The associated set of individual AP 102 and STA 104 can be referred to as a Basic Service Set (BSS), which is managed by the respective AP 102. Figure 1 additionally illustrates an example coverage area 106 of AP 102, which represents the Basic Service Area (BSA) of WLAN 100. The BSS can be identified to users via a Service Set Identifier (SSID) and to other devices via a Basic Service Set Identifier (BSSID), which can be the Media Access Control (MAC) address of AP 102. AP 102 periodically broadcasts a beacon frame ("beacon") including the BSSID so that any STA 104 within the wireless range of AP 102 can "associate" or reassociate with AP 102 to establish a corresponding communication link 108 (hereinafter also referred to as a "Wi-Fi link"), or maintain a communication link 108 with AP 102. For example, a beacon may include an identifier of the primary channel used by the respective AP 102 and a timing synchronization function for establishing or maintaining timing synchronization with AP 102. AP 102 may provide access to the external network to each STA 104 in the WLAN via its respective communication link 108.

[0055] To establish a communication link 108 with AP 102, each of STA 104 is configured to perform passive or active scanning operations ("scanning") on frequency channels in one or more frequency bands (e.g., 2.4 GHz, 5.0 GHz, 6.0 GHz, or 60 GHz bands). To perform a passive scan, STA 104 listens for beacons transmitted by the corresponding AP 102 at periodic time intervals, which are called Target Beacon Transmission Time (TBTT) (measured in units of time (TU), where one TU may be equal to 1024 microseconds (μs)). To perform an active scan, STA 104 generates probe requests and sequentially sends such probe requests on each channel to be scanned, and listens for probe responses from AP 102. Each STA 104 can be configured to identify or select an AP 102 to associate with based on scan information obtained via passive or active scanning, and perform authentication and association operations to establish a communication link 108 with the selected AP 102. At the end of the association operation, AP 102 assigns an Association Identifier (AID) to STA 104, which AP 102 uses to track STA 104.

[0056] Due to the increasing prevalence of wireless networks, STA 104 may have the opportunity to select from one of many BSSs within its range or from multiple APs 102 that together form an Extended Service Set (ESS) (including multiple connected BSSs). The extended network station associated with WLAN 100 can be connected to a wired or wireless distribution system that allows multiple APs 102 to be connected in such an ESS. Thus, STA 104 can be covered by more than one AP 102 and can be associated with different APs 102 at different times for different transmissions. Additionally, after being associated with an AP 102, STA 104 can also be configured to periodically scan its surroundings to find a more suitable AP 102 to associate with. For example, STA 104 moving relative to its associated AP 102 can perform a "roaming" scan to find another AP 102 with more suitable network characteristics (such as a larger Received Signal Strength Indicator (RSSI) or reduced transmission load).

[0057] In some cases, STA 104 can form a network without AP 102 or other devices besides STA 104 itself. An example of such a network is an ad hoc network (or wireless ad hoc network). Ad hoc networks can also be referred to as mesh networks or peer-to-peer (P2P) networks. In some cases, ad hoc networks can be implemented within a larger wireless network (e.g., WLAN 100). In such implementations, while STA 104 can communicate with each other via AP 102 using communication link 108, STA 104 can also communicate directly with each other via direct wireless link 110. Alternatively, two STA 104 can communicate via direct communication link 110, regardless of whether the two STA 104 are associated with and served by the same AP 102. In such ad hoc systems, one or more STAs among STA 104 can assume the role played by AP 102 in the BSS. Such STA 104 can be referred to as the group owner (GO) and can coordinate transmissions within the self-organizing network. Examples of direct wireless links 110 include Wi-Fi direct connections, connections established via Wi-Fi Tunnel Direct Link Establishment (TDLS) links, and other P2P group connections.

[0058] AP 102 and STA 104 can operate and communicate (via the corresponding communication link 108) according to the IEEE 802.11 standard family (such as standards defined by the IEEE 802.11-2016 specification or its amendments, including but not limited to 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be). These standards define WLAN radio and baseband protocols for the PHY and Media Access Control (MAC) layers. AP 102 and STA 104 transmit and receive wireless communications to and from each other (hereinafter also referred to as "Wi-Fi communications") in the form of Physical Layer Convergence Protocol (PLCP) Protocol Data Units (PPDUs). AP 102 and STA 104 in WLAN 100 can transmit PPDUs on unlicensed spectrum, which can be a portion of the spectrum including bands traditionally used by Wi-Fi technologies (such as the 2.4 GHz band, 5.0 GHz band, 60 GHz band, 3.6 GHz band, and 900 MHz band). Some implementations of AP 102 and STA 104 described herein can also communicate in other bands (such as the 6.0 GHz band) that can support both licensed and unlicensed communications. AP 102 and STA 104 can also be configured to communicate on other bands, such as those sharing licensed bands, where multiple service providers may have licenses to operate in one or more identical or overlapping bands.

[0059] Each frequency band may include multiple sub-bands or frequency channels. For example, PPDUs conforming to revisions of the IEEE 802.11n, 802.11ac, and 802.11ax standards can be transmitted in the 2.4 and 5.0 GHz bands, each of which is divided into multiple 20 MHz channels. Thus, these PPDUs are transmitted on physical channels with a minimum bandwidth of 20 MHz, but larger channels can be formed by channel combining. For example, PPDUs can be transmitted on physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by combining multiple 20 MHz channels together.

[0060] Each PPDU is a composite structure comprising a PHY preamble and a payload in the form of a PLCP Service Data Unit (PSDU). The information provided in the preamble can be used by the receiving device to decode subsequent data in the PSDU. In the case where the PPDU is transmitted over a concatenated channel, the preamble field can be copied and transmitted in each of the multiple component channels. The PHY preamble may include both a traditional portion (or "traditional preamble") and a non-traditional portion (or "non-traditional preamble"). The traditional preamble can be used for packet detection, automatic gain control, and channel estimation, among other applications. The traditional preamble is also generally used to maintain compatibility with legacy equipment. The format, encoding, and information provided therein of the non-traditional portion of the preamble are based on the specific IEEE 802.11 protocol to be used for transmitting the payload.

[0061] Figure 2A illustrates an example Protocol Data Unit (PDU) 200 that can be used for communication between an AP and multiple STAs. 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 PHY preamble 202 may include a conventional portion, which itself includes a Conventional Short Training Field (L-STF) 206, a Conventional Long Training Field (L-LTF) 208, and a Conventional Signal Transfer Field (L-SIG) 210. The PHY preamble 202 may also include a non-conventional portion (not shown). The L-STF 206 generally enables the receiving device to perform automatic gain control (AGC) and coarse timing and frequency estimation. The L-LTF 208 generally enables the receiving device to perform fine timing and frequency estimation, and also to estimate the radio channel. The L-SIG 210 generally enables the receiving device to determine the duration of the PDU and use the determined duration to avoid transmission on the PDU. For example, L-STF 206, L-LTF 208, and L-SIG 210 can be modulated according to a binary phase-shift keying (BPSK) modulation scheme. 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 suitable modulation scheme. Payload 204 can generally carry higher-level data in the form of, for example, Media Access Control (MAC) Protocol Data Units (MPDUs) or Aggregated MPDUs (A-MPDUs).

[0062] Figure 2B illustrates an example L-SIG field 220 in the PDU of Figure 2A. L-SIG 220 includes a data rate field 222, a reserved bit 224, a length field 226, a co-occurrence bit 228, and a tail field 220. The data rate field 222 indicates the data rate (note that the data rate indicated in the data rate field 222 may not be the actual data rate of the data carried in the payload 204). The length field 226 indicates, for example, the length of the packet in bytes. The co-occurrence bit 228 is used to detect bit errors. The tail field 220 includes a tail portion, which is used by the receiving device to terminate the operation of the decoder (e.g., a Viterbi decoder). The receiving device uses the data rate and length indicated in the data rate field 222 and the length field 226 to determine, for example, the duration of the packet in microseconds (μs).

[0063] Figure 3A illustrates another example PDU 300 that can be used for wireless communication between an AP and one or more STAs. The PDU 300 can be used for SU, OFDMA, or MU-MIMO transmission. The PDU 300 can be formatted as a High Efficiency (HE) WLAN PPDU according to the IEEE 802.11ax revision of the IEEE 802.11 wireless communication protocol standard. The PDU 300 includes a PHY preamble, which includes a traditional portion 302 and a non-traditional portion 304. The PDU 300 may also include a PHY payload 306 (e.g., in the form of a PSDU including data fields 324) after the preamble.

[0064] The conventional portion 302 of the preceding signal includes L-STF 308, L-LTF 310, and L-SIG 312. The non-conventional portion 304 includes a repeat of L-SIG (RL-SIG) 314, a first HE signal field (HE-SIG-A) 316, a short HE training field (HE-STF) 320, and one or more long HE training fields (or symbols) (HE-LTF) 322. For OFDMA or MU-MIMO communication, the second portion 304 also includes a second HE signal field (HE-SIG-B) 318 separately encoded with HE-SIG-A 316. Similar to L-STF 308, L-LTF 310, and L-SIG 312, in cases involving the use of coupled channels, the information in RL-SIG 314 and HE-SIG-A 316 can be copied and transmitted in each of the component 20 MHz channels. In contrast, the contents of HE-SIG-B 318 can be unique for each 20 MHz channel and target-specific STA 104.

[0065] RL-SIG 314 can indicate to an HE-compatible STA 104 that PDU 300 is an HE PPDU. AP 102 can use HE-SIG-A 316 to identify multiple STAs 104 and notify those STAs that the AP has scheduled UL or DL ​​resources for them. For example, HE-SIG-A 316 may include a resource configuration subfield indicating the resource configuration for the identified STA 104. HE-SIG-A 316 can be decoded by each HE-compatible STA 104 served by AP 102. For MU transmissions, HE-SIG-A 316 also includes information that can be used by each identified STA 104 to decode the associated HE-SIG-B 318. For example, HE-SIG-A 316 may indicate the frame format (including the location and length of HE-SIG-B 318), available channel bandwidth, modulation and coding scheme (MCS), and other information. HE-SIG-A 316 may also include HE WLAN signals that can be used by STA 104 other than the identified STA 104.

[0066] HE-SIG-B 318 may carry STA-specific scheduling information, such as, for example, STA-specific (or "user-specific") MCS values ​​and STA-specific RU allocation information. In the context of DL MU-OFDMA, such information enables the corresponding STA 104 to identify and decode the corresponding resource element (RU) in the associated data field 324. Each HE-SIG-B 318 includes a common field and at least one STA-specific field. The common field may indicate RU allocations (including RU assignments in the frequency domain) for multiple STAs 104, indicating which RUs are allocated for MU-MIMO transmissions and which RUs correspond to MU-OFDMA transmissions, as well as the number of users and other instances in the allocation. The common field may be encoded together with common bits, CRC bits, and tail bits. User-specific fields are assigned to a specific STA 104 and may be used to schedule specific RUs and indicate the schedule to other WLAN devices. Each user-specific field may include multiple user block fields. Each user block field may include two user fields, which contain information about the corresponding RU payload in the two corresponding STA decoding data fields 324.

[0067] Figure 3B illustrates another example PPDU 350 that can be used for wireless communication between an AP and one or more STAs. The PDU 350 can be used for SU, OFDMA, or MU-MIMO transmission. The PDU 350 can be formatted as an Extremely High Delivery Rate (EHT) WLAN PPDU according to the IEEE 802.11be revision of the IEEE 802.11 wireless communication protocol standard, or it can be formatted as any future (post-EHT) version of the PPDU that conforms to a new wireless communication protocol (conforming to future IEEE 802.11 wireless communication protocol standards or other wireless communication standards). The PDU 350 includes a PHY preamble, which includes a traditional portion 352 and a non-traditional portion 354. The PDU 350 may also include a PHY payload 356 (e.g., in the form of a PSDU including data fields 376) after the preamble.

[0068] The conventional portion 352 of the preamble includes L-STF 358, L-LTF 360, and L-SIG 362. The non-conventional portion 354 of the preamble includes RL-SIG 364 and signal fields related to multiple radio protocol versions following RL-SIG 364. For example, the non-conventional portion 354 may include a general signal field 366 (referred to herein as "U-SIG 366") and an EHT signal field 368 (referred to herein as "EHT-SIG 368"). One or both of U-SIG 366 and EHT-SIG 368 may be configured to carry version-related information for and for other radio protocol versions besides EHT. The non-traditional portion 354 also includes an additional short training field 372 (referred to herein as "EHT-STF 372", but it may also be configured to carry version-related information for other wireless communication protocol versions besides EHT) and one or more additional long training fields 374 (referred to herein as "EHT-LTF 374", but it may also be configured to carry version-related information for other wireless communication protocol versions besides EHT). Similar to L-STF 358, L-LTF 360, and L-SIG 362, in cases involving the use of joined channels, the information in U-SIG 366 and EHT-SIG 368 may be copied and transmitted in each of the component 20 MHz channels. In some implementations, EHT-SIG 368 may additionally or alternatively carry information different from that carried in the primary 20 MHz channel in one or more non-primary 20 MHz channels.

[0069] EHT-SIG 368 may include one or more jointly encoded symbols and may be encoded in a block different from the block in which U-SIG 366 is encoded. EHT-SIG 368 may be used by the AP to identify multiple STAs 104 and to notify the multiple STAs 104 that the AP has scheduled UL or DL ​​resources for them. EHT-SIG 368 may be decoded by each compatible STA 104 served by AP 102. EHT-SIG 368 may generally be used by the receiving device to interpret the bits in data field 376. For example, EHT-SIG 368 may include RU allocation information, spatial stream configuration information, and per-user signal delivery information (such as MCS) and other instances. EHT-SIG 368 may also include a cyclic redundancy check (CRC) (e.g., four bits) and a tail (e.g., six bits) that may be used for binary cyclotron code (BCC). In some implementations, EHT-SIG 368 may include one or more code blocks, each comprising a CRC and a tail. In some cases, each code block may be encoded individually.

[0070] The EHT-SIG 368 can carry STA-specific scheduling information, such as, for example, user-specific MCS values ​​and user-specific RU allocation information. The EHT-SIG 368 can generally be used by the receiving device to interpret the bits in data field 376. In the context of DL MU-OFDMA, this information enables the corresponding STA 104 to identify and decode the corresponding RU in the associated data field 376. Each EHT-SIG 368 may include a common field and at least one user-specific field. The common field may indicate the RU distribution across multiple STAs 104, indicate RU assignment in the frequency domain, indicate which RUs are allocated for MU-MIMO transmissions and which RUs correspond to MU-OFDMA transmissions, and the number of users and other instances in the allocation. The common field may be encoded with common bits, CRC bits, and tail bits. The user-specific field is assigned to a specific STA 104 and can be used to schedule specific RUs and indicate the schedule to other WLAN devices. Each user-specific field may include multiple user block fields. Each user block field may include, for example, two user fields containing information for two corresponding STAs to decode their respective RU payloads.

[0071] The presence of RL-SIG 364 and U-SIG 366 can indicate to EHT or future version-compatible STA 104 that PPDU 350 is an EHT PPDU or any future (post-EHT) version of the PPDU that complies with the new wireless communication protocol (complying with the future IEEE 802.11 wireless communication protocol standard). For example, U-SIG 366 can be used by the receiving device to interpret bits in one or more of EHT-SIG 368 or data field 376.

[0072] Figure 4 illustrates an example PPDU 400 that can be used for communication between AP 102 and multiple STAs 104. As mentioned above, each PPDU 400 includes a PHY preamble signal 402 and a PSDU 404. Each PSDU 404 may carry one or more MAC Protocol Data Units (MPDUs), such as, for example, an aggregated MPDU (A-MPDU) 406 including multiple MPDU subframes 408. Each MPDU subframe 408 may include a MAC delimiter 412 and a MAC header 414 before an accompanying frame body 416, which includes the data portion or "payload" of the MPDU subframe 408. The frame body 416 may carry one or more MAC Service Data Units (MSDUs), such as, for example, an aggregated MSDU (A-MPDU) 422 including multiple MSDU subframes 424. Each MSDU subframe 424 contains a corresponding MSDU 426, which includes a subframe header 428, a frame body 430, and one or more padding bits 432.

[0073] Referring back to A-MPDU subframe 406, MAC header 414 may include multiple fields containing information that defines or indicates characteristics or attributes of the data encapsulated within frame body 416. MAC header 414 also includes multiple fields indicating the addresses used for the data encapsulated within frame body 416. For example, MAC header 412 may include a combination of source address, transmitter address, receiver address, or destination address. MAC header 414 may include frame control fields containing control information. Frame control fields specify the frame type, such as a data frame, control frame, or management frame. MAC header 414 may also include a duration field indicating the duration from the end of the PPDU to the end of the acknowledgment (ACK) of the last PPDU to be transmitted by the wireless communication device (e.g., block ACK (BA) in the case of A-MPDU). The use of the duration field is to reserve wireless media for the indicated duration, thereby establishing NAV. Each A-MPDU subframe 408 may also include a Frame Check Sequence (FCS) field 418 for error detection. For example, the FCS field 418 may include a Cyclic Redundancy Check (CRC) and may be followed by one or more padding bits 420.

[0074] As mentioned above, AP 102 and STA 104 can support multi-user (MU) communication. That is, concurrent transmission from one device to each of multiple devices (e.g., multiple simultaneous downlink (DL) communications from AP 102 to the corresponding STA 104), or concurrent transmission from multiple devices to a single device (e.g., multiple simultaneous uplink (UL) communications from the corresponding STA 104 to AP 102). To support MU transmission, AP 102 and STA 104 can utilize multi-user multiple-input multiple-output (MU-MIMO) and multi-user orthogonal frequency division multiple access (MU-OFDMA) technologies.

[0075] In the MU-OFDMA scheme, the available spectrum of a radio channel can be divided into multiple resource elements (RUs), each comprising multiple different frequency subcarriers (also referred to as "tones"). Different RUs can be allocated by AP 102 at specific times or assigned to different STAs 104. The size and distribution of RUs can be referred to as RU allocation. In some implementations, RUs can be allocated at 2 MHz intervals, and thus, the minimum RU can include 26 tones consisting of 24 data tones and 2 pilot tones. Therefore, in a 20 MHz channel, up to 9 RUs can be allocated (e.g., 26-tone RUs at 2 MHz) (because some tones are reserved for other purposes). Similarly, in a 160 MHz channel, up to 74 RUs can be allocated. Larger 52-tone, 106-tone, 242-tone, 484-tone, and 996-tone RUs can also be allocated. Adjacent RUs can be separated by empty subcarriers (such as DC subcarriers) to reduce interference between adjacent RUs, reduce receiver DC offset, and avoid transmission center frequency leakage.

[0076] For UL MU transmissions, AP 102 can send a trigger frame to initiate and synchronize UL MU-OFDMA or UL MU-MIMO transmissions from multiple STAs 104 to AP 102. Such a trigger frame allows multiple STAs 104 to concurrently send UL transmissions to AP 102 in time. The trigger frame can address one or more STAs 104 via a corresponding Association Identifier (AID), and can assign one or more RUs to each AID (and thus each STA 104), which can be used to send UL transmissions to AP 102. AP can also specify one or more Random Access (RA) RUs that unscheduled STAs 104 can contend for.

[0077] Figure 5 illustrates a block diagram of an example wireless communication device 500. In some implementations, the wireless communication device 500 may be an instance of a device used in a STA (such as one of the STA 104 described above with reference to Figure 1). In some implementations, the wireless communication device 500 may be an instance of a device used in an AP (such as AP 102 described above with reference to Figure 1). The wireless communication device 500 is capable of sending (or outputting for transmission) and receiving wireless communications (e.g., in the form of wireless packets). For example, the wireless communication device 500 can be configured to transmit and receive packets in the form of Entity Layer Convergence Protocol (PLCP) Protocol Data Units (PPDUs) and Media Access Control (MAC) Protocol Data Units (MPDUs) conforming to IEEE 802.11 standards (such as those defined by the IEEE 802.11-2016 specification or its amendments, including but not limited to 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be).

[0078] The wireless communication device 500 may be or may include a chip, system-on-a-chip (SoC), chipset, package, or device, which includes one or more modems 502, such as a Wi-Fi (compliant with IEEE 802.11) modem. In some implementations, the one or more modems 502 (collectively referred to as "modems 502") additionally include a WWAN modem (e.g., a 3GPP 4G LTE or 5G compatible modem). In some implementations, the wireless communication device 500 also includes one or more radio units 504 (collectively referred to as "radio units 504"). In some implementations, the wireless communication device 500 also includes one or more processors, processing blocks, or processing elements 506 (collectively referred to as "processors 506"), and one or more memory blocks or elements 508 (collectively referred to as "memory 508").

[0079] The modem 502 may include intelligent hardware blocks or devices, such as, for example, application-specific integrated circuits (ASICs) and other possible devices. The modem 502 is generally configured to implement a PHY layer. For example, the modem 502 is configured to modulate packets and output modulated packets to the radio unit 504 for transmission over a wireless medium. Similarly, the modem 502 is configured to receive modulated packets received by the radio unit 504 and demodulate such packets to provide demodulated packets. In addition to modulators and demodulators, the modem 502 may also include digital signal processing (DSP) circuitry, automatic gain control (AGC), encoders, decoders, multiplexers, and demultiplexers. For example, in transmission mode, data obtained from the processor 506 is provided to an encoder, which encodes the data to provide encoded bits. Subsequently, the encoded bits (using a selected MCS) are mapped to points in the modulation cluster to provide modulated symbols. Subsequently, the modulated symbols can be mapped to NSS spatial streams or NSSTS space-time streams. The modulated symbols in the corresponding spatial or space-time streams can then be overridden, transformed via an inverse fast Fourier transform (IFFT) block, and subsequently provided to the DSP circuitry for Tx windowing and filtering. The digital signal can then be provided to a digital-to-analog converter (DAC). The resulting analog signal can then be provided to a frequency upconverter and finally to the radio unit 504. In beamforming implementations, the modulated symbols in the corresponding spatial streams are pre-encoded via a guiding matrix before being provided to the IFFT block.

[0080] When in receive mode, the digital signal received from radio unit 504 is provided to a DSP circuit system configured to, for example, acquire the received signal by detecting the presence of the signal and estimating initial timing and frequency offset. The DSP circuit system is also configured to digitally adjust the digital signal, for example, using channel (narrowband) filtering and analog impairment conditioning (such as correcting I / Q imbalance), and applying digital gain to ultimately obtain a narrowband signal. Subsequently, the output of the DSP circuit system can be fed to an AGC, which is configured to use information extracted from the digital signal (e.g., in one or more received training fields) to determine an appropriate gain. The output of the DSP circuit system is also coupled to a demodulator configured to extract modulated symbols from the signal and, for example, calculate the log-probability ratio (LLR) for each bit position of each subcarrier of each spatial stream. The demodulator is coupled to a decoder configured to process the LLR to provide decoded bits. Subsequently, the decoded bits from all spatial streams are fed to a demultiplexer for demultiplexing. The demultiplexed bits can then be descrambled and provided to the MAC layer (processor 506) for processing, evaluation, or interpretation.

[0081] Radio unit 504 generally includes at least one radio frequency (RF) transmitter (or "transmitter chain") and at least one RF receiver (or "receiver chain"), which may be combined into one or more transceivers. For example, the RF transmitter and receiver may include various DSP circuitry systems, each including at least one power amplifier (PA) and at least one low-noise amplifier (LNA). The RF transmitter and receiver may further be coupled to one or more antennas. For example, in some implementations, wireless communication device 500 may include multiple transmitting antennas (each with a corresponding transmitting chain) and multiple receiving antennas (each with a corresponding receiving chain) or coupled to multiple transmitting antennas and multiple receiving antennas. Symbols output from modem 502 are provided to radio unit 504, which then transmits the symbols via the coupled antennas. Similarly, symbols received via the antennas are obtained by radio unit 504, which then provides the symbols to modem 502.

[0082] Processor 506 may include intelligent hardware blocks or devices designed to perform the functions described herein, such as, for example, processing cores, processing blocks, central processing units (CPUs), microprocessors, microcontrollers, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable logic devices (PLDs) (such as field-programmable gate arrays (FPGAs)), individual gate or transistor logic, individual hardware elements, or any combination thereof. Processor 506 processes information received via radio unit 504 and modem 502, and processes information to be output via modem 502 and radio unit 504 for transmission via wireless media. For example, processor 506 may implement a control plane and a MAC layer configured to perform various operations related to the generation and transmission of MPDUs, frames, or packets. The MAC layer is configured to perform or facilitate frame encoding and decoding, spatial multiplexing, spatiotemporal block coding (STBC), beamforming, and OFDMA resource configuration, as well as other operations or techniques. In some implementations, processor 506 can generally control modem 502 to enable modem to perform the various operations described above.

[0083] Memory 508 may include tangible storage media, such as random access memory (RAM) or read-only memory (ROM), or combinations thereof. Memory 508 may also store non-transitory processor or computer-executable software (SW) code containing instructions that, when executed by processor 506, cause the processor to perform various operations for wireless communication described herein, including the generation, transmission, reception, and interpretation of MPDUs, frames, or packets. For example, the various functions of the elements disclosed herein, or the various blocks or steps of the methods, operations, programs, or algorithms disclosed herein, may be implemented as one or more modules of one or more computer programs.

[0084] Figure 6A illustrates a block diagram of an example AP 602. For example, AP 602 may be an example implementation of AP 102 described with reference to Figure 1. AP 602 includes a wireless communication device (WCD) 610. For example, wireless communication device 610 may be an example implementation of wireless communication device 500 described with reference to Figure 5. AP 602 also includes a plurality of antennas 620 coupled to wireless communication device 610 for transmitting and receiving wireless communications. In some implementations, AP 602 additionally includes an application processor 630 coupled to wireless communication device 610 and memory 640 coupled to application processor 630. AP 602 also includes at least one external network interface 650 that enables AP 602 to communicate with a core network or backhaul network to obtain access to external networks, including the Internet. For example, the external network interface 650 may include one or both of a wired (e.g., Ethernet) network interface and a wireless network interface (such as a WWAN interface). Some of the aforementioned components may communicate directly or indirectly with other components on at least one bus. AP 602 also includes a housing that encloses at least a portion of the wireless communication device 610, application processor 630, memory 640, antenna 620, and external network interface 650.

[0085] Figure 6B illustrates a block diagram of an example STA 604. For example, STA 604 may be an example implementation of STA 104 described with reference to Figure 1. STA 604 includes a wireless communication device 615. For example, wireless communication device 615 may be an example implementation of wireless communication device 500 described with reference to Figure 5. STA 604 also includes one or more antennas 625 coupled to wireless communication device 615 for transmitting and receiving wireless communications. STA 604 additionally includes an application processor 635 coupled to wireless communication device 615, and memory 645 coupled to application processor 635. In some implementations, STA 604 also includes a user interface (UI) 655 (such as a touch screen or keyboard) and a display 665, which may be integrated with the UI 655 to form a touch screen display. In some implementations, STA 604 may also include one or more sensors 675 (such as, for example, one or more inertial sensors, accelerometers, temperature sensors, pressure sensors, or altitude sensors). The aforementioned components may communicate directly or indirectly with other components on at least one bus. STA 604 also includes a housing that encloses at least a portion of the wireless communication device 615, application processor 635, memory 645, and antenna 625, UI 655, and display 665.

[0086] As mentioned above, the IEEE 802.11be revision of the IEEE 802.11 standard describes r-TWT SPs that can be used to provide more predictable latency, reduced worst-case latency, or reduced signal interference, resulting in higher reliability for latency-sensitive transmissions. As used herein, the term "non-traditional STA" refers to any STA that supports the IEEE 802.11be revision or future generations of the IEEE 802.11 standard, while the term "low-latency STA" refers to any non-traditional STA with latency-sensitive transmissions to be sent or received. In contrast, the term "traditional STA" can refer to any STA that only supports the IEEE 802.11ax or earlier generations of the IEEE 802.11 standard. Non-traditional STAs that support r-TWT operation and are TXOP holders outside of r-TWT SPs must terminate their respective TXOPs before starting any other r-TWT SP for which they are not members. Furthermore, the AP can suppress traffic from all legacy STAs during the r-TWT SP by scheduling a quiet interval to overlap with the r-TWT SP. However, some non-legacy STAs may not support r-TWT operation and therefore can ignore the quiet interval and the r-TWT SP scheduling. In some cases, such non-legacy STAs may occupy the shared radio media at the start of the r-TWT SP, thereby blocking or delaying access to low-latency STAs that are SP members. Therefore, new communication protocols or mechanisms are needed to further protect latency-sensitive traffic in the r-TWT SP.

[0087] The various states generally involve latency-sensitive communications, and more specifically, involve ensuring that latency-sensitive traffic associated with an r-TWT SP is provided with sufficient channel access during the r-TWT SP to meet the various latency, throughput, and timing requirements of such latency-sensitive traffic. In some implementations, the AP can schedule an r-TWT SP for a low-latency STA with low-latency peer-to-peer (P2P) data to be transmitted or received on the radio medium. In some cases, the STA associated with the AP may include a co-located softAP associated with a client device with low-latency P2P communication to be transmitted or received. The softAP and its client device may be associated with a P2P link on which P2P communication can be exchanged between the softAP and the client device. Since neither the softAP nor the client device is associated with the AP, the AP may not identify the softAP or the client device in the trigger frame transmitted on the radio medium during the r-TWT SP. As a result, when the STA intends to use the wireless media for P2P communication associated with the softAP and client devices during the r-TWT SP, the softAP and client devices may inadvertently set their respective NAVs to the duration indicated by the trigger frame, and therefore may be unable to send or receive P2P communication with each other during the r-TWT SP.

[0088] In some implementations, the AP can receive a request frame from a STA associated with the AP and connected to a client device via a P2P link. The request frame indicates that the STA intends to exchange P2P communication with the client device during a scheduled r-TWT SP on the radio media. The request frame identifies the client device and may indicate one or more TWT parameters for the r-TWT SP. The AP may construct a Network Allocation Vector (NAV) exception for the client device based on the information received in the request frame and send a response frame to the STA. The AP may acquire a Transmission Opportunity (TXOP) on the radio media and may send a trigger frame on the radio media during the r-TWT SP. The trigger frame may be a portion of the acquired TXOP allocated for P2P communication between the STA and the client device. At least one of the response frame or the trigger frame indicates an NAV exception for the client. In some cases, the NAV exception indicates that the client device will ignore both the NAV duration indicated by the trigger frame and the NAV duration indicated by a Clear Send (CTS) frame in response to the trigger frame. In other words, an NAV anomaly can indicate that a client device will not set its NAV based on the NAV duration indicated by the trigger frame sent during the r-TWT SP. In some cases, the STA may include a co-located softAP that has or can establish a P2P link with the client device. NAV anomalies can also apply to co-located softAPs, for example, causing the co-located softAP to not set its NAV based on the NAV duration indicated by the trigger frame sent during the r-TWT SP.

[0089] The specific implementation of the subject matter described herein can be implemented to achieve one or more of the following potential advantages. By signaling NAV anomalies (which indicate that softAPs (and any associated P2P client devices) co-located or associated with STAs (STAs are associated with APs and belong to r-TWT SPs) will not set their respective NAVs for the duration indicated by a trigger frame sent from the AP during the r-TWT SP), the manner of this embodiment can ensure that such softAPs and their associated client devices can exchange latency-sensitive P2P communications with each other during the scheduled portion of the r-TWT SP. In this way, the implementation of the subject matter disclosed herein can ensure that latency-sensitive traffic or P2P communications associated with P2P devices are provided with enhanced channel protection mechanisms.

[0090] Figure 7 illustrates a block diagram of another example wireless network 700 according to some implementations. In some embodiments, wireless network 700 may be an instance of WLAN 100 of Figure 1. Wireless network 700 is shown to include AP 702, first wireless station (STA) 710, second STA 720, and third STA 730. In some implementations, AP 702 may be an instance of AP 102 of Figure 1 or AP 602 of Figure 6A, and may operate a BSS on the wireless medium according to one or more versions of the IEEE 802.11 wireless communication standard family. STAs 710, 720, and 730 may be instances of STA 104 of Figure 1, wireless communication device 500 of Figure 5, or STA 604 of Figure 6B. STAs 710, 720, and 730 are associated with AP 702 and may communicate with AP 702 on the wireless medium according to the BSS operated by AP 702.

[0091] In the example of Figure 7, a first STA 710 is co-located with a first softAP 711, which is associated with a first client device 712, and a second STA 720 is co-located with a second softAP 721, which is associated with a second client device 722. The first softAP 711 and the first client device 712 can establish a P2P link 713, on which P2P communication can be exchanged between the first softAP 711 and the client device 712. The second softAP 721 and the second client device 722 can establish a P2P link 723, on which P2P communication can be exchanged between the second softAP 721 and the client device 722. In some cases, P2P links 713 and 723 can be Tunnel Direct Link Establishment (TDLS) links established over wireless media. In other cases, P2P links 713 and 723 can be based on Wi-Fi direct peer communication protocols.

[0092] In some implementations, the first STA 710 includes a separate MAC entity capable of independently performing MAC layer functions for wireless communication with the AP 702 and for wireless communication with the client device 712. For example, the first STA 710 may include a first MAC Service Access Point (MAC-SAP) endpoint (S1) corresponding to the first STA 710, and may include a second MAC-SAP endpoint (A1) corresponding to the first softAP 711. The first MAC-SAP endpoint S1 may be responsible for decoding frames and packets received from the AP 702 on the wireless medium, and may be responsible for constructing and formatting frames for transmission from the first STA 710 to the AP 702 on the wireless medium. The second MAC-SAP endpoint A1 may be responsible for decoding frames and packets received from the client device 712 on the wireless medium, and may be responsible for constructing and formatting frames for transmission from the first softAP 711 to the client device 712 on the first P2P link 713. In some cases, MAC-SAP endpoints S1 and A1 can have different MAC addresses.

[0093] Similarly, the second STA 720 may include a first MAC Service Access Point (MAC-SAP) endpoint (S2) corresponding to the second STA 720, and may include a second MAC-SAP endpoint (A2) corresponding to the second softAP 721. The first MAC-SAP endpoint S2 may be responsible for decoding frames and packets received from AP 702 on the wireless medium, and may be responsible for constructing and formatting frames for transmission from the second STA 720 to AP 702 on the wireless medium. The second MAC-SAP endpoint A2 may be responsible for decoding frames and packets received from client device 722 on the wireless medium, and may be responsible for constructing and formatting frames for transmission from the second softAP 721 to client device 722 on the second P2P link 723. In some cases, MAC-SAP endpoints S2 and A2 may have different MAC addresses.

[0094] The first STA 710 may provide a first coverage area 715 to a P2P device (such as a first client device 712), and the second STA 720 may provide a second coverage area 725 to a P2P device (such as a second client device 722). In some cases, the first and second coverage areas 715 and 725 may not overlap each other (as shown in the example of FIG. 7). In some other cases, the first and second coverage areas 715 and 725 may overlap each other. Although not illustrated for simplicity, the coverage area provided by AP 702 may include some or all of the first coverage area 715 provided by the first softAP 711 of the first STA 710, and may include some or all of the second coverage area 725 provided by the second softAP 721 of the second STA 720. For example, in some cases, one or both of client devices 712 and 722 may be able to receive and successfully decode frames sent by AP 702, while in other cases, one or both of client devices 712 and 722 may not be able to receive or successfully decode frames sent by AP 702 (e.g., because client devices 712 and 722 are not within the wireless coverage area of ​​AP 702).

[0095] Client devices 712 and 722 can be any suitable device capable of establishing a P2P link with the corresponding softAPs 711 and 721. In the example of Figure 7, client devices 712 and 722 are associated with low-latency applications that have strict end-to-end latency, throughput, and timing requirements for data transfer volumes. In some cases, client devices 712 and 722 can be associated with real-time gaming applications, video communications, or augmented reality (AR) and virtual reality (VR) applications (collectively referred to as extended reality (XR) applications). For example, client devices 712 and 722 can be VR phones associated with softAPs 711 and 721, respectively, which are co-located with the first and second STAs 710 and 720. Thus, each of the first STA 710 and the second STA 720 can be referred to as a low-latency STA. In the case where the third STA 730 is associated with latency-sensitive transfer volumes, the third STA 730 can also be referred to as a low-latency STA.

[0096] As discussed, low-latency applications can specify various latency, throughput, and timing requirements for the WLAN 700, and therefore it is desirable to ensure that the WLAN 700 can meet these various latency, throughput, and timing requirements of such low-latency applications. In some implementations, each of the low-latency STAs 710, 720, and 730 can request the AP 702 to schedule an r-TWT SP by sending a corresponding r-TWT REQ frame to the AP 702 on the wireless medium. Each r-TWT REQ frame may include the MAC address of the AP 702, the MAC address of the corresponding STA, and one or more TWT parameters. In some cases, one or more TWT parameters may include (but are not limited to) the period of the requested r-TWT SP, the duration of the requested r-TWT SP, the sharing mode of the requested r-TWT SP, the wake-up duration of the requested r-TWT SP, the stream type of the requested r-TWT SP, the parameter set of the r-TWT SP, or the intent of the corresponding STA to use the r-TWT SP for P2P communication between the corresponding STA and the associated client device.

[0097] Upon receiving the r-TWT SP REQ, AP 702 can decide to accept, reject, or modify the TWT parameters proposed by each of STAs 710, 720, and 730. Specifically, AP 702 sends an r-TWT SP accept frame to each of the first, second, and third STAs 710, 720, and 730. Each r-TWT SP accept frame may include the MAC address of the corresponding STA and a set of TWT parameters for the r-TWT SP scheduled on the wireless medium. In some cases, AP 702 may accept the TWT parameters proposed by the corresponding STA, and therefore, the set of TWT parameters carried in the corresponding r-TWT SP accept frame may be the same as the proposed TWT parameters. In other cases, AP 702 may propose new or modified TWT parameters to the corresponding STA, and therefore, the set of TWT parameters carried in the corresponding r-TWT SP accept frame may be different from the proposed TWT parameters. In some other cases, AP 702 may reject TWT parameters or r-TWT SPs requested by one or more of STA 710, 720 or 730.

[0098] Figure 8 illustrates a timing diagram 800 depicting an example wireless communication between devices belonging to a BSS. The BSS is shown to include an AP 702, a first STA 710 and a co-located first softAP 711, a first client device 712, a second STA 720 and a second softAP 721, a second client device 722, and a third STA 730, as described with reference to Figure 7. In some implementations, each of the first, second, and third STAs 710, 720, and 730 may be referred to as a low-latency STA. In the example of Figure 8, the first and second STAs 710 and 720 may be members of a scheduled r-TWT SP spanning the time period between time t1 and t9, while the third STA 730 is not a member of the r-TWT SP (and may therefore be referred to as a "non-member STA").

[0099] As discussed with reference to FIG7, the first STA 710 is associated with AP 702 and implements or operates the first softAP 711 associated with the first client device 712 via the first P2P link 713. Similarly, STA 720 operates with AP 702 and implements or operates the second softAP 721 associated with the second client device 722 via the second P2P link 723. In some implementations, the first STA 710 may include two MAC-softAP endpoints S1 and A1, and the second STA 720 may include two MAC-softAP endpoints S2 and A2. The third STA 730 is associated with AP 702 and does not implement or operate the softAP. Although only three STAs are illustrated in the example of FIG8, in actual implementations, the BSS may include any number of STAs (such as low-latency STAs) and may also include any number of non-traditional STAs.

[0100] As discussed, existing rules regarding restricted TWT operation require non-member STAs to terminate their TXOPs before the restricted TWT SP begins. The restricted TWT SP in Figure 8 begins at time t1, and therefore, all non-member STAs (such as the third STA 730) truncate their respective TXOPs (if any) before time t1. In some cases, AP 702 may suppress traffic from all legacy STAs associated with the BSS by scheduling quiet time intervals to overlap with the restricted TWT SP. For example, the duration of the quiet time interval may be indicated by one or more quiet elements included in management frames (such as beacon frames and probe response frames) sent by AP 702 before the restricted TWT SP begins.

[0101] As shown, AP 702 attempts to access the shared wireless media before r-TWT SP. More specifically, before attempting to acquire TXOP, AP 702 senses that the media is idle for at least the SIFS duration (from time t0 to t1) based on channel sensing operations (such as Idle Channel Assessment (CCA)). In some cases, AP 702 may sense that the wireless media is idle for the PIFS duration (such that the time period from time t0 to t1 is the PIFS duration) before attempting to acquire channel access. At time t1, AP 702 senses that the wireless media is still idle and, for example, continues to acquire TXOP by initiating a transmission on the shared media. Specifically, AP 702 sends a trigger frame 810 on the wireless media identifying the first STA 710 and the second STA 720 for trigger-based uplink (UL) transmission. In some cases, the trigger frame 810 includes a per-user information field carrying an association identifier (AID) assigned to the first and second STAs 710 and 720.

[0102] In some implementations, the trigger frame 810 includes a duration field (in the MAC header) that can be used to protect delay-sensitive transmissions in a restricted TWT SP. As described, existing STAs conforming to the IEEE 802.11 standard must delay media access for at least the duration indicated by the duration field in the trigger frame (such as trigger frame 810). In some implementations, the duration indicated by the duration field may be greater than the duration required to transmit the trigger frame 810. For example, as shown in FIG8, a third STA 730 may set its NAV 803 to the duration indicated by the duration field of the trigger frame 810, which spans the time period between time t2 and t3. In this way, the AP 702 can protect low-latency transmissions from non-triggered STAs using WLAN 700.

[0103] In some other implementations, AP 702 may poll low-latency STAs before the start of a restricted TWT SP to determine which STAs (if any) have UL data to send. For example, AP 702 may send a Buffer Status Report Polling (BSRP) trigger frame to the low-latency STAs associated with the restricted TWT SP. Each low-latency STA responds to the BSRP trigger frame by sending a Buffer Status Report (BSR) to AP 702 indicating the amount of UL data buffered by the STA. AP 702 may use the information carried in each BSR to determine the resource allocation for the TB PPDU requested by the trigger frame (e.g., trigger frame 810).

[0104] First and second STAs 710 and 720 receive trigger frame 810 and determine that their respective AID values ​​match the AID values ​​carried in trigger frame 810. Between times t2 and t3, first STA 710 transmits a first trigger-based (TB) Entity Layer Convergence Protocol (PLCP) Protocol Data Unit (PPDU) 811 to AP 702 over the radio medium, and second STA 720 transmits a second TB PPDU 812 to AP 702 over the radio medium. In some cases, first and second TB PPDUs 811 and 812 may be transmitted as MU UL PPDUs. AP 702 receives TB PPDUs 811 and 812 and acknowledges its reception by transmitting a block ACK frame 813 over the radio medium to first and second STAs 710 and 720 at time t4.

[0105] At time t5, AP 702 acquires a TXOP and transmits a Multi-User (MU) Request Transmission (RTS) TXOP Sharing (TXS) trigger frame 820 on the radio medium. In some implementations, the MU-RTS TXS trigger frame 820 includes a duration field indicating the duration of the acquired TXOP, for example causing a non-triggered STA to set its NAV to the duration indicated in the duration field. In the example of Figure 8, the MU-RTS TXS trigger frame 820 may allocate a portion (T1) of the TXOP acquired by AP 702 to the first STA 710 during r-TWT SP. Specifically, the MU-RTS TXS trigger frame 820 may include the MAC address of the STA and may also include the AID value of the first STA 710 (e.g., to request one or more TB PPDUs from the first STA 710).

[0106] As discussed, the first STA 710 is co-located with a softAP, which is connected to a first client device 712 associated with latency-sensitive traffic. In the example of FIG8, the first STA 710 intends to use the allocation portion of the TXOP to facilitate P2P communication between the co-located softAP and the first client device 712. However, the AP 702 may not be aware that the first STA 710 is co-located with the softAP, and therefore may not be aware that the first STA 710 intends to allow its co-located softAP and the first client device 712 to exchange P2P communication over the wireless medium during the allocation portion of the TXOP. Specifically, although the MU-RTS TXS trigger frame 820 may include the MAC address of the first STA 710, the MU-RTS TXS trigger frame 820 may not include the MAC address of the first softAP 711 or the MAC address of the associated client device 712. Since neither the softAP nor its associated client device 712 is identified by the MU-RTS TXS trigger frame 820, both the softAP and client device 712 can set their respective NAVs 831 and 832 to the duration indicated in the duration field of the MU-RTS TXS trigger frame 820. As a result, neither the first softAP 711 nor the client device 712 may be able to send or receive P2P communication to or from the first softAP 711 during the allocation portion of the TXOP.

[0107] First STA 710 receives MU-RTS TXS trigger frame 820, determines that its AID is carried in MU-RTS TXS trigger frame 820, and determines that a portion of TXOP is allocated to first STA 710. First STA 710 confirms receipt of MU-RTS TXS trigger frame 820 by sending CTS frame 821 to AP 702 at time t7. CTS frame 821 may include the MAC address of AP 702, for example, so that AP 702 can determine that CTS frame 821 is confirming receipt of MU-RTS TXS trigger frame 820. However, since neither the softAP nor its associated client device 712 is identified by the CTS frame 821, the first softAP 711 and the client device 712 can set their respective NAVs 831 and 832 to the duration indicated in the duration field of the CTS frame 821 (unless they have already set their respective NAVs based on the duration indicated in the MU-RTS TXS trigger frame 820). Thus, neither the first softAP 711 nor the client device 712 may be able to send or receive P2P communication to or from each other during the allocation portion of the TXOP. Similarly, since neither the MU-RTS TXS trigger frame 820 nor the CTS frame 821 addresses or otherwise identifies the second STA 720, the second co-located softAP 721, or the client device 722 for use in the allocation portion of the TXOP, each of the second STA 720, the second softAP 721, and the client device 722 sets its respective NAV 840, 841, and 842 to the duration indicated in the CTS frame 821. The third STA 730 also determines that it is not identified by the MU-RTS TXS trigger frame 820 and sets its NAV 843 to the duration indicated in the duration field of the MU-RTS TXS trigger frame 820 or the CTS frame 821.

[0108] Figure 9 illustrates a timing diagram of an example wireless communication 900 between devices belonging to a BSS according to some implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. In the example of Figure 9, the first and second STAs 710 and 720 are members of a scheduled r-TWT SP that spans a time period between time t3 and t15, while the third STA 730 is not a member of the r-TWT SP (and may therefore be referred to as a "non-member STA"). As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first co-located softAP 711 that has or can establish a P2P link 713 with a first client device 712. Similarly, the second STA 720 is associated with AP 702 and implements or operates a second co-located softAP 721, which has or can establish a P2P link 723 with the second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 9, in a real implementation, the BSS can include any number of low-latency STAs, and can also include any number of non-traditional STAs.

[0109] In the example of FIG9, the first STA 710 requests an r-TWT SP for P2P communication between its co-located first softAP 711 and client device 712. Specifically, at time t0, the first STA 710 sends a request (REQ) frame 901 to AP 702 on the radio medium. The request frame 901 may include a request for AP 702 to schedule an r-TWT SP for the first STA 710, during which the first softAP 711 may use the radio medium to send low-latency data to or receive low-latency data from client device 712. In some cases, the request frame 901 identifies the softAP and its client device 712 as participants in a communication exchange scheduled during the r-TWT SP. For example, in some cases, the request frame 901 may include the MAC addresses of the softAP and client device 712. AP 702 can use the MAC address or other suitable identifier of the soft AP and client device 712 to provide enhanced protection for P2P communication exchanged over the wireless media during the r-TWT SP. In some implementations, the request frame 901 may include a TWT element carrying the MAC address of the client device 712. The TWT element may also carry one or more TWT parameters associated with the r-TWT SP. Example TWT parameters may include (but are not limited to) the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, the parameter set of the r-TWT SP, or the soft AP's intent to use the wireless media during the r-TWT SP.

[0110] Between times t0 and t1, AP 702 decodes request frame 901 and obtains the TWT parameters associated with the r-TWT SP requested by the first STA 710. AP 702 can also determine which devices intend to use the wireless media for P2P communication during a portion of the r-TWT SP. In some implementations, AP 702 can use the information decoded from request frame 901 to construct a NAV exception for P2P communication associated with a softAP co-located with an STA belonging to the r-TWT SP. Specifically, in some cases, the NAV exception can identify one or more devices associated with AP 702 or the co-located softAP that will ignore the NAV duration indicated by the MU-RTS TXS trigger frame and the NAV duration indicated by the CTS frame following the MU-RTS TXS trigger frame. In the example of Figure 9, an NAV anomaly can indicate that the first softAP 711 and client device 712 will ignore the NAV duration indicated by the MU-RTS TXS trigger frame subsequently sent from AP 702 and any CTS frames sent in response to the subsequently sent MU-RTS TXS trigger frame. As a result, although the first softAP 711 and client device 712 do not set their respective NAVs based on the duration indicated in the duration field of the MU-RTS TXS trigger frame (or the subsequent CTS frame), other wireless communication devices that are not members of the r-TWT SP or are not identified by the MU-RTS TXS trigger frame set their respective NAVs based on the duration indicated by the MU-RTS TXS trigger frame (or the subsequent CTS frame).

[0111] Between times t1 and t2, AP 702 sends a Resp frame 902 to the first STA 710 on the wireless medium. The Resp frame 902 may include TWT elements carrying a set of TWT parameters for the scheduled r-TWT SP. In some implementations, the Resp frame 902 may also include the MAC addresses of softAP1 and client device 712. In some other implementations, the Resp frame 902 may also indicate how many wireless communication devices are members of the scheduled r-TWT SP. In some cases, this allows the first STA 710 to determine whether it is the sole member of the r-TWT SP and therefore whether it can use an active channel access technique instead of a MU-RTS TXS trigger frame during the r-TWT SP.

[0112] Before attempting to acquire a TXOP, AP 702 senses that the wireless media is idle during the PIFS duration (from time t2 to t3) based on channel sensing operations (such as Idle Channel Assessment (CCA)). At time t3, AP 702 senses that the wireless media is still idle and, for example, continues to acquire a TXOP by initiating a transmission on the shared media. Specifically, at time t3, AP 702 sends a trigger frame 910 on the wireless media. In the example of FIG9, the trigger frame 910 identifies the first STA 710 and the third STA 730, for example, by including the AIDs of the first STA 710 and the third STA 730 in the corresponding user information fields of the trigger frame 910.

[0113] First STA 710 and third STA 730 receive trigger frame 910 and determine their corresponding AID matches the AID carried in trigger frame 910. Between times t4 and t5, first STA 710 transmits first TB PPDU 911 to AP 702 over the radio medium, and second STA 720 transmits second TB PPDU 912 to AP 702 over the radio medium. In some cases, first and second TB PPDUs 911 and 912 can be transmitted as MU UL PPDUs. AP 702 receives TB PPDUs 911 and 912 and confirms its reception by transmitting block ACK frame 913 over the radio medium to first and second STAs 710 and 720 at time t6.

[0114] The second STA 720 receives the trigger frame 910 and determines that it is not identified by the trigger frame 910 for UL transmission. Thus, the second STA 720 sets its NAV 903 to the duration field of the trigger frame 910. In some cases, the duration indicated in the trigger frame 910 may correspond to a time period associated with the transmission of a TB PPDU on the wireless medium. For example, as shown in FIG9, the second STA 720 may set its NAV 903 to the duration indicated by the duration field of the trigger frame 910, which spans the time period between time t4 and t5. In this way, the AP 702 can protect low-latency transmissions from at least a nearby STA using the WLAN 700.

[0115] At time t7 (which may be the SIFS duration after the transmission of block ACK frame 913 ends), AP 702 acquires TXOP and, between times t7 and t8, transmits MU-RTS TXS trigger frame 920 on the wireless medium. MU-RTS TXS trigger frame 920 allocates a portion of the TXOP acquired by AP 702 for P2P communication between client device 712 and first softAP 711 during r-TWT SP. MU-RTS TXS trigger frame 920 includes a duration field indicating a duration (T1) for which TXOP is allocated for P2P communication. In this way, receiving devices not identified by MU-RTS TXS trigger frame 920 set their corresponding NAV to the indicated duration T1, for example, so that low-latency P2P communication between client device 712 and first softAP 711 is not interrupted or degraded.

[0116] In various implementations, the MU-RTS TXS trigger frame 920 signals an NAV exception, which indicates that the first softAP 711 and the client device 712 will ignore the NAV duration indicated by the MU-RTS TXS trigger frame 920 or the NAV duration indicated by the CTS frame following the MU-RTS TXS trigger frame 920. In some embodiments, the MU-RTS TXS trigger frame 920 may include or indicate the MAC addresses of the first softAP 711 and the client device 712, for example, causing the first softAP 711 and the client device 712 to receive and decode the MU-RTS TXS trigger frame 920.

[0117] Between times t8 and t9, the first STA 710 receives and decodes the MU-RTS TXS trigger frame 920 and determines that a portion of the TXOP is allocated for P2P communication associated with the client device 712. At time t9, the first STA 710 confirms the reception of the MU-RTS TXS trigger frame 920 by sending a CTS frame 921 to the AP 702. The CTS frame 921 includes a duration field indicating a duration (T1) for which the TXOP is allocated for P2P communication. In this way, a receiving device that receives the CTS frame but not the MU-RTS TXS trigger frame 920 can set its corresponding NAV to the indicated duration T1. In some cases, CTS frame 921 signals the NAV exception described in reference to MU-RTS TXS trigger frame 920, and also indicates the MAC addresses of client device 712 and first softAP 711, for example, so that first softAP 711 and client device 712 receive and decode CTS frame 921.

[0118] Between times t8 and t9, client device 712 and first softAP 711 can receive and decode MU-RTS TXS trigger frame 920. Specifically, client device 712 and first softAP 711 can decode NAV exceptions signaled by MU-RTS TXS trigger frame 920, and in response to NAV exceptions, not set their corresponding NAVs to the duration indicated in the duration field of MU-RTS TXS trigger frame 920. In some cases, client device 712 and first softAP 711 can also receive and decode CTS frame 921 sent by first STA 710. For example, client device 712 and first softAP 711 can decode NAV exceptions signaled by CTS frame 921, and in response to NAV exceptions, not set their corresponding NAVs to the duration indicated in the duration field of CTS frame 921. Therefore, if client device 712 does not receive or cannot decode the MU-RTS TXS trigger frame 920 (e.g., because client device 712 is outside the wireless coverage area of ​​AP 702), client device 712 can obtain an NAV exception from the CTS frame 921 sent by the first STA 710. In this way, the implementation of the object disclosed herein can ensure that client device 712 and the first softAP 711 can obtain an NAV exception and remain available for exchanging P2P communication with each other during the allocation portion of TXOP, for example by not setting their respective NAVs to the duration indicated by the MU-RTS TXS trigger frame 920.

[0119] At time t10, the first softAP 711 senses that the wireless media is idle and sends a trigger frame 930 to the client device 712 on the wireless media. In the example of FIG9, the trigger frame 930 identifies the client device 712, for example, by including the MAC address (or other suitable identifier) ​​in the user information field included in the trigger frame 930.

[0120] Client device 712 receives trigger frame 930 and determines that trigger frame 930 identifies client device 712. In some cases, trigger frame 930 may request UL P2P transmission from client device 712. In response to trigger frame 930, client device 712 sends TB PPDU 931 to first softAP 711 on the wireless medium between times t11 and t12. First softAP 711 receives TB PPDU 931 and confirms receipt of TB PPDU 931 by sending block ACK frame 932 to client device 712 between times t13 and t14. TXOP allocation to first STA 710 ends at time t14. NAV of second STA 720, its co-located softAP 721, second client device 722, and third STA 730 also ends at time t14. r-TWT SP ends at time t15.

[0121] In some cases, Wi-Fi Tunnel Direct Link Establishment (TDLS) can be used to establish the P2P link 713. In other cases, the P2P link 713 can be a Wi-Fi direct connection. In some other cases, the first STA 710 or the first softAP 711 can be the group owner (GO) and coordinate P2P transmissions to or from the client device 712. In some cases, NAV exceptions can be included in or indicated by a TWT element carried in the P2P response frame 902. In some other cases, NAV exceptions can be included in or associated with other suitable signaling within or related to the P2P response frame 902.

[0122] Figure 10 illustrates a timing diagram of an example wireless communication 1000 between devices belonging to a BSS according to some implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. In the example of Figure 10, the first and second STAs 710 and 720 are members of a scheduled r-TWT SP that spans a time period between time t3 and t15, while the third STA 730 is not a member of the r-TWT SP (and may therefore be referred to as a "non-member STA"). As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first co-located softAP 711 that has or can establish a P2P link 713 with a first client device 712. Similarly, the second STA 720 is associated with AP 702 and implements or operates a second co-located softAP 721, which has or can establish a P2P link 723 with the second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 10, in a real implementation, the BSS can include any number of low-latency STAs, and can also include any number of non-traditional STAs.

[0123] The timing diagram of Figure 10 is similar to that of Figure 9 in many states, and differs from that of Figure 9 in some states. For example, although in the example communication 900 of Figure 9, the NAV exception is signaled to the client device 712 and the first softAP 711 using the MU-R TS TXS trigger frame 920, in the example communication 1000 of Figure 10, the response frame 1002 can be used to signal the NAV exception to the first softAP 711 and its associated client device 712. Specifically, at time t0, the first STA 710 sends a request (REQ) frame 1001 to AP 702 on the wireless medium. Request frame 1001 (which may be an example of request frame 901 in Figure 9) may include a request for AP 702 to schedule r-TWT SP, during which P2P communication may be exchanged over a wireless medium between client device 712 and first softAP 711, with minimal (if any) interference from other nearby wireless communication devices.

[0124] In some cases, request frame 1001 identifies the first softAP 711 and its associated client device 712 as participants in P2P communications scheduled during at least a portion of the r-TWT SP. For example, request frame 1001 may include the MAC addresses of the first softAP 711 and client device 712. AP 702 may use the MAC addresses of the first softAP 711 and client device 712, or other suitable identifiers, to construct NAV exceptions for the first softAP 711 and client device 712. In some cases, AP 702 may construct NAV exceptions for P2P communications associated with a softAP that is co-located with an STA that is associated with AP 702 and is a member of the r-TWT SP.

[0125] AP 702 receives request frame 1001 between time t0 and t1 and obtains the identities of the first softAP 711 and client device 712 (or other devices intending to participate in the r-TWT SP). In some cases, request frame 1001 may indicate the intention of the first STA 710 to use wireless media for P2P communication between the first softAP 711 and its client device 712 during the allocation portion of the TXOP obtained by AP 702. Request frame 1001 may also indicate one or more TWT parameters for the r-TWT SP requested by the first STA 710.

[0126] The AP 702 constructs an NAV exception, which can allow low-latency devices associated with one or more associated STAs (but not part of the BSS) or associated with the AP 702 to send or receive P2P communications during the allocation portion of the r-TWT SP. Specifically, in some cases, the NAV exception can identify one or more devices within the wireless range of the AP 702 or within the wireless range of one or more STAs associated with the AP 702, which will ignore the NAV duration indicated by certain trigger frames sent by the AP 702 and certain response frames sent by the associated STAs.

[0127] In the example of Figure 10, the NAV anomaly constructed by AP 702 can indicate that the first softAP 711 and its client device 712 will ignore the NAV duration indicated by the MU-RTS TXS trigger frame subsequently sent during the r-TWT SP. The NAV anomaly can also indicate that the first softAP 711 and its client device 712 will ignore the NAV duration indicated by the CTS frame following the MU-RTS TXS trigger frame. As a result, although other wireless communication devices that are not members of the r-TWT SP or are not identified by the MU-RTS TXS trigger frame set their respective NAV based on the duration indicated by the MU-RTS TXS trigger frame (or the CTS frame following it), the first softAP 711 and its associated client device 712 do not set their respective NAV based on the duration indicated by the MU-RTS TXS trigger frame or the CTS frame following the MU-RTS TXS trigger frame.

[0128] Specifically, when AP 702 transmits MU-RTS TXS trigger frame 920 on the wireless medium between times t8 and t9, the first softAP 711 and client device 712 ignore the NAV duration indicated by MU-RTS TXS trigger frame 920 based on the NAV exception indicated by AP 702 in response frame 1002. The first softAP 711 and client device 712 may also ignore the NAV duration indicated by CTS frame 921 transmitted by the first STA 710 between times t9 and t10 based on the NAV exception. Thus, the first softAP 711 and its associated client device 712 do not set their respective NAV based on the duration indicated by the MU-RTS TXS trigger frame 920 or the subsequent CTS frame 921, thereby allowing the first softAP 711 and its associated client device 712 to send or receive low-latency P2P communications on the P2P link 713 during the portion of the r-TWT SP allocated to the first STA 710.

[0129] For example, when the first softAP 711 sends a trigger frame 1030 to its associated client device 712 on the wireless medium at time t10, the client device 712 does not set its NAV and can therefore receive and decode the trigger frame 1030. In response to the trigger frame 1030, the client device 712 sends a TB PPDU 1031 to the first softAP 711 between times t11 and t12. The first softAP 711 receives the TB PPDU 1031 and sends a block ACK frame 1032 to the client device 712 at time t13. The second STA 720, the second softAP 721, the second client device 722, and the third STA 730 set their respective NAVs 940-943 to the duration from time t9 to t14 indicated by the MU-RTS TXS trigger frame 1020, and therefore do not attempt to access the wireless media during the r-TWT SP period between time t9 and t14, thereby reducing contention and interference on the wireless media during the allocation portion of the r-TWT SP.

[0130] In some other implementations, softAPs 711 and 721 and their associated client devices 712 and 722 may ignore the NAV duration indicated by certain frames (such as MU-RTS TXS trigger frame 920 and CTS frame 921) based on rules specified by wireless communication protocols (such as the IEEE 802.11 wireless communication standard family) or otherwise defined. In such other implementations, the first softAP 711 and its associated client device 712 may receive an NAV exception during association or authentication operations between the first STA 710 and AP 702. Similarly, the second softAP 721 and its associated client device 722 may receive an NAV exception during association or authentication operations between the second STA 720 and AP 702.

[0131] Figure 11 illustrates a timing diagram depicting an example wireless communication 1100 between devices belonging to a BSS according to other implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first co-located softAP 711 associated with a first client device 712. Similarly, the second STA 720 is associated with the AP 702 and implements or operates a second co-located softAP 721 associated with a second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 11, in actual implementations, the BSS may include any number of low-latency STAs and may also include any number of non-traditional STAs.

[0132] The timing diagram of Figure 11 is similar to the timing diagrams of Figures 9 and 10 in many states, and differs from the timing diagrams of Figures 9 and 10 in some states. For example, although the example communications 900 and 1000 described with reference to Figures 9 and 10 include mechanisms to indicate NAV anomalies to softAPs 711 and 721 and their associated client devices 712 and 722, the example communication 1100 of Figure 11 may not indicate or signal NAV anomalies. Instead, AP 702 may allocate a portion of the TXOP obtained during r-TWT SP for a time period shorter than the time period indicated or requested by one or more associated STAs 710, 720, or 730 for such time-sensitive P2P communications.

[0133] In some implementations, the example of FIG11 uses modified request and response frames that can be used by a STA associated with AP 702 to notify AP 702 of latency-sensitive P2P communication and any corresponding low-latency P2P devices intending to participate in the exchange. For example, in some implementations, a first STA 710 sends a request (REQ) frame 1101 to AP 702 on the wireless medium at time t0. Request frame 1101 (which may be an example of request frame 901 of FIG9 or request frame 1001 of FIG10) may include a request to AP 702 to schedule r-TWT SP for P2P communication between a first softAP 711 and client device 712. Request frame 1101 may identify the first softAP 711 and client device 712 as participants in the P2P communication scheduled during r-TWT SP. In some configurations, request frame 1101 may include the MAC addresses of the first softAP 711 and the client device 712. Request frame 1101 may also indicate a time period T2 for allocating wireless media to the first STA 710 for P2P communication between the first softAP 711 and the client device 712.

[0134] AP 702 receives request frame 1101 between time t0 and t1, and obtains the TWT parameter, the identifiers of the first softAP 711 and the client device 712, and the requested time period T2. As shown in the example of FIG11, AP 702 selects a modified time period T2' shorter than the requested time period T2, and sets the duration field of MU-RTS TXS trigger frame 1020 to the modified (shorter) time period T2'.

[0135] When AP 702 transmits MU-RTS TXS trigger frame 1020 on the wireless medium between times t7 and t8, the first softAP 711 and client device 712 set their respective NAVs to a shorter time period T2' indicated by MU-RTS TXS trigger frame 1020. Specifically, the first softAP 711 and client device 712 set their respective NAVs 1041 and 1042 to a shorter time period T2' that spans from time t8 to tA. As discussed, the shorter time period T2' is sufficient to protect the wireless medium when the first STA 710 receives MU-RTS TXS trigger frame 1020 and transmits CTS frame 1021.

[0136] At time tA, the NAV 1041 of the first softAP 711 expires. After waiting for at least the SIFS duration (from time tA to t10), the first softAP 711 sends a trigger frame 1030 to the client device 712 on the wireless media. In some cases, the first softAP 711 may wait for the PIFS duration before sending the trigger frame 1030 on the wireless media. In the example of FIG11, the trigger frame 1030 identifies the client device 712, for example, by including a MAC address (or other suitable identifier) ​​in the user information field included in the trigger frame 1030.

[0137] Client device 712 (whose NAV 1042 also expires at time tA) receives trigger frame 1030 between times t11 and t12. In some cases, trigger frame 1030 may request UL P2P transmission from client device 712. In response to receiving trigger frame 1030, client device 712 sends TB PPDU 1031 to first softAP 711 over the wireless medium between times t11 and t12. First softAP 711 receives TB PPDU 1031 and acknowledges receipt of TB PPDU 1031 by sending block ACK frame 1032 to client device 712 between times t13 and t14. The time period T2 indicated or requested by first STA 710 ends at time t14. In some cases, NAV 940-943 associated with the second STA 720, the second softAP 721, the second client device 722, and the third STA 730 are set to span a duration from time t8 to t14. The r-TWT SP ends at time t15.

[0138] Figure 12 illustrates a timing diagram depicting an example wireless communication 1200 between devices belonging to a BSS according to other implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first co-located softAP 711 associated with a first client device 712. Similarly, the second STA 720 is associated with the AP 702 and implements or operates a second co-located softAP 721 associated with a second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 12, in actual implementations, the BSS may include any number of low-latency STAs and may also include any number of non-traditional STAs.

[0139] The timing diagram of Figure 12 is similar to that of Figure 8 in many variations, except that the example communication 1200 of Figure 12 does not use a MU-RTS TXS trigger frame. Instead, the example communication 1200 uses a signal transmission that allows the first STA 710 to notify the AP 702 of its intention to use wireless media for P2P communication between the first softAP 711 and the client device 712.

[0140] Specifically, at time t0, the first STA 710 sends a request (REQ) frame 1201 to the AP 702 on the wireless media. The request frame 1201 may include a request for the AP 702 to schedule an r-TWT SP, during which the first softAP 711 may use the wireless media to send low-latency data to or receive low-latency data from the client device 712. In some implementations, the request frame 1201 includes a vendor-specific information element (VSIE) indicating the intent of the first STA 710. In some cases, the VSIE may also indicate various TWT parameters for the requested r-TWT SP. For example, the VSIE may indicate the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or the set of parameters for the r-TWT SP.

[0141] Between time t0 and t1, AP 702 decodes request frame 1201 and obtains TWT parameters and the intent of the first STA 710 to use the wireless media allocated to the first STA 710 during a portion of the r-TWT SP for P2P communication between the first softAP 711 and the client device 712.

[0142] At time t1, AP 702 sends a Resp frame 1202 to the first STA 710 on the wireless media. The Resp frame 1202 may include a VSIE indicating the set of TWT parameters to be used for the scheduled r-TWT SP. In some implementations, the VSIE may also indicate the number of devices that are members of the r-TWT SP. This information allows the first STA 710 to determine whether it is the only member of the r-TWT SP and therefore whether it can use an active channel access technique instead of a MU-RTS TXS trigger frame during the r-TWT SP. In some cases, the VSIE may also identify the first softAP 711 and the client device 712.

[0143] Before attempting to acquire TXOP, the first softAP 711 senses that the wireless media is idle for at least the SIFS duration (from time t3 to t4) based on channel sensing operations (such as idle channel assessment (CCA)). At time t4, the first softAP 711 senses that the wireless media is still idle and sends a trigger frame 1200 on the wireless media. In the example of FIG12, the trigger frame 1200 identifies the client device 712, for example, by including the device identifier (such as a MAC address) of the client device 712 in the user information field of the trigger frame 1200.

[0144] Client device 712 receives trigger frame 1200 and determines that trigger frame 1200 identifies client device 712. In response to receiving trigger frame 1200, client device 712 sends TB PPDU 1220 to first softAP 711 on the wireless medium between times t6 and t7. First softAP 711 receives TB PPDU 1220 and confirms receipt of TB PPDU 1220 by sending block ACK frame 1230 to client device 712 between times t8 and t9. r-TWT SP ends at time t10.

[0145] Figure 13 illustrates a timing diagram depicting an example wireless communication 1300 between devices belonging to a BSS according to other implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first (co-located) softAP 711 associated with a first client device 712. Similarly, the second STA 720 is associated with the AP 702 and implements or operates a second (co-located) softAP 721 associated with a second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 13, in actual implementations, the BSS may include any number of low-latency STAs and may also include any number of non-traditional STAs.

[0146] The timing diagram of Figure 13 is similar to that of Figure 9 in many variations, except that the example communication 1300 of Figure 13 occurs outside any r-TWT SP. In some implementations, AP 702 senses that the media is idle during the PIFS duration (from time t0 to t1) based on channel sensing operations (such as Idle Channel Assessment (CCA)) before attempting to acquire the TXOP. At time t1, AP 702 senses that the wireless media is still idle and, for example, continues to acquire the TXOP by initiating a transmission on the shared media. Specifically, AP 702 sends a CTS to itself (CTS2self) frame 1301 on the wireless media to reserve sufficient length of wireless media to acquire the TXOP. AP 702 acquires the TXOP on the wireless media and at time t3, sends a trigger frame 910 that identifies the first STA 710 and the second STA 720 for trigger-based UL transmission. In some cases, the trigger frame 910 includes a per-user information field carrying an association identifier (AID) assigned to the first and second STAs 710 and 720.

[0147] The frame sequence between times t3 and t14 in the example communication 1300 of Figure 13 is similar to the frame sequence between times t3 and t14 in the example communication 900 of Figure 9. For example, AP 702 transmits a MU-RTS TXS trigger frame 920 on the wireless medium between times t7 and t8. The MU-RTS TXS trigger frame 920 allocates a portion of the TXOP obtained by AP 702 for P2P communication between client device 712 and first softAP1 711 during r-TWT SP. The MU-RTS TXS trigger frame 920 includes a duration field indicating the duration (T1) during which the TXOP is allocated for P2P communication. In this way, receiving devices not identified by the MU-RTS TXS trigger frame 920 set their corresponding NAV to the indicated duration T1, for example, so that the low-latency P2P communication between client device 712 and first softAP 711 is not interrupted or degraded.

[0148] The MU-RTS TXS trigger frame 920 signals an NAV anomaly, indicating that the first softAP 711 and the client device 712 will ignore the NAV duration indicated by the MU-RTS TXS trigger frame 920 or the NAV duration indicated by the CTS frame following the MU-RTS TXS trigger frame 920. In some configurations, the MU-RTS TXS trigger frame 920 may include or indicate the MAC addresses of the first softAP 711 and the client device 712, for example, causing the first softAP 711 and the client device 712 to receive and decode the MU-RTS TXS trigger frame 920. In this way, the first softAP 711 may send a trigger frame 930 to the client device 712 at t10, and the client device 712 may send a TB PPDU 931 to the first softAP 711 between t11 and t12.

[0149] Figure 14 illustrates a timing diagram depicting an example wireless communication 1400 between devices belonging to a BSS according to other implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first co-located softAP 711 associated with a first client device 712. Similarly, the second STA 720 is associated with the AP 702 and implements or operates a second co-located softAP 721 associated with a second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 14, in actual implementations, the BSS may include any number of low-latency STAs and may also include any number of non-traditional STAs. In the example of Figure 14, the AP 702 schedules multiple P2P communication periods within the r-TWT SP in a time-duplex manner.

[0150] For example, at time t1, the AP sends a MU-RTS TXS trigger frame 1410 to allocate a portion of the TXOP obtained by AP 702 for P2P communication associated with the first STA 710. At time t2, the first softAP 711 sends a CTS frame 1511 to AP 702. At time t3, the first softAP 711 senses that the wireless media is idle and sends a trigger frame 1412 to the client device 712 on the wireless media. In the example of FIG. 14, the trigger frame 1412 identifies the client device 712, for example, by including a MAC address (or other suitable identifier) ​​in the user information field included in the trigger frame 1412. The client device 712 receives the trigger frame 1412 and, between times t4 and t5, sends a TB PPDU 931 to the first softAP 711 on the wireless media. The first softAP 711 receives the TB PPDU and confirms the receipt of the TB PPDU by sending a block ACK frame to the client device 712 at time t5.

[0151] Subsequently, at time t6, the AP sends another MU-RTS TXS trigger frame 1420 to allocate a portion of the TXOP obtained by AP 702 for P2P communication associated with the second STA 720. At time t8, the second softAP 721 senses that the wireless media is idle and sends a trigger frame 1422 to the client device 722 on the wireless media. In the example of FIG. 14, the trigger frame 1422 identifies the client device 722, for example, by including the MAC address (or other suitable identifier) ​​in the user information field included in the trigger frame 1422. The client device 722 receives the trigger frame 1422 and, between times t9 and t10, sends a TB PPDU 931 to the second softAP 721 on the wireless media. The second softAP 721 receives the TB PPDU and acknowledges the reception of the TB PPDU by sending a block ACK frame to the client device 722 at time t11.

[0152] Figure 15 illustrates a timing diagram depicting an example wireless communication 1500 between devices belonging to a BSS according to other implementations. The BSS is shown to include an AP 702, a first STA 710, a second STA 720, and a third STA 730 as described with reference to Figure 7. As discussed, the first STA 710 is associated with the AP 702 and implements or operates a first co-located softAP 711 associated with a first client device 712. Similarly, the second STA 720 is associated with the AP 702 and implements or operates a second co-located softAP 721 associated with a second client device 722. Although only three low-latency STAs are illustrated in the example of Figure 15, in actual implementations, the BSS may include any number of low-latency STAs and may also include any number of non-traditional STAs. The timing diagram of Figure 15 is similar to the timing diagram of Figure 14, except that the AP 702 uses frequency multiplexing to concurrently schedule multiple P2P communication periods within the r-TWT SP. As shown, AP 702 schedules P2P communication associated with the first STA 710 in the lower 20 MHz frequency sub-band and schedules P2P communication associated with the second STA 720 in the upper 20 MHz frequency sub-band.

[0153] For example, at time t1, the AP sends a MU-RTS TXS trigger frame 1510 to allocate a portion of the TXOP obtained by AP 702 for P2P communication associated with the first STA 710 on the lower 20 MHz frequency sub-band, and to allocate a portion of the TXOP for P2P communication associated with the second STA 720 on the upper 20 MHz frequency sub-band. At time t2, the first softAP 711 sends a CTS frame 1511 to AP 702. At time t3, the first softAP sends a trigger frame 1512 to the client device 712 on the wireless medium. In the example of FIG. 15, the trigger frame 1512 identifies the client device 712, for example, by including a MAC address (or other suitable identifier) ​​in the user information field included in the trigger frame 1512. Client device 712 receives trigger frame 1512 and, between times t4 and t5, sends a TB PPDU to the first softAP 711 over the wireless media. The first softAP 711 receives the TB PPDU and acknowledges receipt by sending a block ACK frame to client device 712 at time t5. Subsequently, at time t6, the AP sends another MU-RTS TXS trigger frame 1520. At time t8, the first softAP 711 sends trigger frame 1522 to client device 712 over the wireless media.

[0154] Figure 16 illustrates a flowchart of an example program 1600 for wireless communication supporting low-latency communication according to some implementations. Program 1600 can be executed by a wireless communication device (such as wireless communication device 500 described above with reference to Figure 5). In some implementations, program 1600 can be executed by a wireless communication device operating as an AP (such as one of APs 102 and 602 described above with reference to Figures 1 and 6A respectively) or operating within that AP.

[0155] In some implementations, procedure 1600 begins in block 1602 by receiving a request frame from a radio station (STA) associated with the AP and also associated with a client device via a peer-to-peer (P2P) link. The request frame indicates that the STA intends to exchange P2P communication with the client device during a scheduled limited target wake-up time (r-TWT) service period (SP) on the radio medium, and the request frame identifies the client device. In block 1604, procedure 1600 continues by sending a response frame to the STA on the radio medium in response to receiving the request frame. In block 1606, procedure 1600 continues by acquiring a transmission opportunity (TXOP) on the radio medium during the r-TWT SP. In block 1608, procedure 1600 continues by sending a trigger frame on the radio medium in response to acquiring the TXOP. This trigger frame allocates a portion of the acquired TXOP for P2P communication between the STA and the client device, wherein at least one of the response frame or the trigger frame indicates a NAV (Network Access Vulnerability) exception for the client device. In some cases, each of the response frame and the trigger frame may include the media access control (MAC) address of the client device.

[0156] In some implementations, the NAV anomaly indicates that the client device will ignore both the NAV duration indicated by the trigger frame and the NAV duration indicated by the clear transmit (CTS) frame following the trigger frame. In some cases, the trigger frame includes a carrier sensing (CS) request field carrying bits set to 0, wherein bits set to 0 indicate an NAV anomaly.

[0157] The request frame can be any suitable frame that can request the r-TWT SP and signal the STA's intention to use the wireless media for P2P communication with the client device during the r-TWT SP. In some implementations, the request frame can be a TWT request frame that includes a TWT element indicating the MAC address of the client device. In some cases, the TWT element can be used to signal the STA's intention to use the wireless media for P2P communication with the client device during the r-TWT SP. The TWT element can also indicate various TWT parameters, including (but not limited to) the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or the set of parameters of the r-TWT SP.

[0158] In other implementations, the request frame may be a Stream Classification Service (SCS) request frame that includes a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device. The TSPEC element may also indicate the Transport Volume Stream (TS) associated with P2P communication, the minimum data rate for the limited TWT communication period, the average data rate for the limited TWT communication period, the delay limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. In some other implementations, the request frame may be a P2P request frame that indicates the MAC address of the client device and signals to the STA its intention to use the wireless media for P2P communication with the client device during the r-TWT SP. In some cases, the P2P request frame may include one or more of a TWT element, a TSPEC element, or a Vendor Specific Information (VSIE) element that indicates the MAC address of the client device and signals to the STA its intention. The TWT element, if present in a P2P request frame, can also indicate the TWT parameters associated with the r-TWT SP. The TSPEC element, if present in a P2P request frame, can also indicate various QoS parameters, data rates, access classes, and user priorities for the P2P link associated with the BSS.

[0159] The response frame can be any suitable frame that can confirm the scheduling of the r-TWT SP requested by the STA. In some implementations, the response frame can be a TWT response frame indicating the MAC address of the client device. The TWT response frame may include a TWT element indicating a set of TWT parameters used by the device, which is a member of the r-TWT SP. In other implementations, the response frame can be an SCS response frame indicating the MAC address of the client device. The SCS response frame may include a TSPEC element, which may include a TSPEC indicating the MAC address of the client device. The TSPEC element may also indicate various QoS parameters, data rates, access classes, and user priorities associated with the P2P link associated with the BSS. In some other implementations, the response frame can be a P2P response frame indicating the MAC address of the client device and signaling to the STA its intention to use the radio media for P2P communication with the client device during the r-TWT SP. In some cases, a P2P response frame may include one or more of the following: a TWT element, a TSPEC element, or a VSIE element, which indicates the MAC address of the client device and signals the STA's intention. The TWT element, if present in the P2P response frame, may also indicate the set of TWT parameters used by the member device during the r-TWT SP. The TSPEC element, if present in the P2P response frame, may also indicate various QoS parameters, data rates, access classes, and user priorities.

[0160] In some cases, the response frame can indicate an NAV anomaly for the client device. That is, the response frame can indicate that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the CTS frame in response to the trigger frame. In other cases, the response frame can indicate the number of devices that are members of the r-TWT SP. The number of other devices belonging to the r-TWT SP can be used by the STA to select one or more attributes of the r-TWT SP. For example, if the STA is the only member of the r-TWT SP, the STA can determine that the MU-RTS TXS trigger frame is not necessary (or not preferred) and can request an r-TWT SP that does not include the MU-RTS TXS trigger frame.

[0161] In some implementations, the trigger frame may be a Multi-User (MU) Request to Send (RTS) TXOP Share (TXS) trigger frame. The MU-RTS TXS trigger frame may include a TXOP share mode subfield indicating the TXOP share mode associated with P2P communication between the STA and the client device. In some cases, the TXOP share mode subfield indicates a request from the STA to send a CTS frame in response to the MU-RTS TXS trigger frame. The CTS frame may include a receiver address field containing the MAC address of the client device.

[0162] In some other implementations, the STA may include a co-located softAP that manages P2P communication between the STA and client devices. In some cases, the softAP may have a different MAC address than the STA. For example, the STA may include a separate MAC entity that can communicate independently with the AP and client devices. In some cases, a first MAC-AP endpoint may be associated with a non-AP STA communicating with the AP, and a second MAC-SAP may be associated with a softAP communicating with client devices. In these implementations, a NAV exception may also indicate that the softAP co-located with the STA belonging to the r-TWT SP will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the CTS frame following the trigger frame.

[0163] Figure 17 illustrates a flowchart of an example program 1700 for wireless communication supporting low-latency communication according to some other implementation. Program 1700 can be executed by a wireless communication device (such as wireless communication device 500 described above with reference to FIG5). In some implementations, program 1700 can be executed by a wireless communication device operating as a STA (such as one of STA 104 and 604 described above with reference to FIG1 and 6B respectively) or operating within that STA.

[0164] In some implementations, procedure 1700 begins in block 1702 by: operating the wireless communication device as a wireless station (STA) associated with an access point (AP), which is also associated with a client device via a peer-to-peer (P2P) link. At block 1704, procedure 1700 continues by: sending a request frame to the AP, the request frame indicating that the STA intends to exchange P2P communication with the client device during a scheduled restricted target wake-up time (r-TWT) service period (SP) on the wireless medium, the request frame identifying the client device. At block 1706, procedure 1700 continues by: receiving a response frame from the AP on the wireless medium. At block 1708, procedure 1700 continues by: receiving a first trigger frame on the wireless medium, the first trigger frame allocating a portion of the transmission opportunity (TXOP) obtained by the AP for P2P communication between the STA and the client device, wherein at least one of the response frame or the first trigger frame indicates a NAV (Network Access Vulnerability) anomaly for the client device. At block 1710, procedure 1700 continues: A Clear Transmit (CTS) frame is sent to the AP on the wireless media, the CTS frame including a receiver address field containing the MAC address of the client device. In some formats, each item in the response frame and the first trigger frame includes the MAC address of the client device.

[0165] In some implementations, the NAV anomaly indicates that the client device will ignore both the NAV duration indicated by the trigger frame and the NAV duration indicated by the clear transmit (CTS) frame following the trigger frame. In some cases, the trigger frame includes a carrier sensing (CS) request field carrying bits set to 0, wherein the bits set to 0 indicate an NAV anomaly.

[0166] The request frame can be any suitable frame that can request the r-TWT SP and signal the STA's intention to use the wireless media for P2P communication with the client device during the r-TWT SP. In some implementations, the request frame can be a TWT request frame that includes a TWT element indicating the MAC address of the client device. In some cases, the TWT element can be used to signal the STA's intention to use the wireless media for P2P communication with the client device during the r-TWT SP. The TWT element can also indicate various TWT parameters, including (but not limited to) the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or the set of parameters of the r-TWT SP.

[0167] In other implementations, the request frame may be a Stream Classification Service (SCS) request frame that includes a Transport Specification (TSPEC) element indicating the MAC address of the client device. The TSPEC element may also indicate the Transport Stream (TS) associated with P2P communication, the minimum data rate for the limited TWT communication period, the average data rate for the limited TWT communication period, the delay limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. In some other implementations, the request frame may be a P2P request frame that indicates the MAC address of the client device and signals to the STA its intention to use the wireless media for P2P communication with the client device during the r-TWT SP. In some cases, the P2P request frame may include one or more of a TWT element, a TSPEC element, or a Vendor Specific Information (VSIE) element that indicates the MAC address of the client device and signals to the STA its intention. If the TWT element exists in a P2P request frame, it can also indicate the TWT parameters associated with the r-TWT SP. If the TSPEC element exists in a P2P request frame, it can also indicate various QoS parameters, data rates, access classes, and user priorities for the P2P link associated with the BSS.

[0168] The response frame can be any suitable frame that can confirm the scheduling of the r-TWT SP requested by the STA. In some implementations, the response frame can be a TWT response frame indicating the MAC address of the client device. The TWT response frame may include a TWT element indicating a set of TWT parameters used by the device, which is a member of the r-TWT SP. In other implementations, the response frame can be an SCS response frame indicating the MAC address of the client device. The SCS response frame may include a TSPEC element, which may include a TSPEC indicating the MAC address of the client device. The TSPEC element may also indicate various QoS parameters, data rates, access classes, and user priorities associated with the P2P link associated with the BSS. In some other implementations, the response frame can be a P2P response frame indicating the MAC address of the client device and signaling to the STA its intention to use the radio media for P2P communication with the client device during the r-TWT SP. In some cases, a P2P response frame may include one or more of the following: a TWT element, a TSPEC element, or a VSIE element, which indicates the MAC address of the client device and signals the STA's intent. If present in the P2P response frame, a TWT element may also indicate the set of TWT parameters used by the member device during r-TWT SP. If present in the P2P response frame, a TSPEC element may also indicate various QoS parameters, data rates, access classes, and user priorities.

[0169] In some cases, the response frame can indicate an NAV anomaly for the client device. That is, the response frame can indicate that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the CTS frame in response to the trigger frame. In other cases, the response frame can indicate the number of devices that are members of the r-TWT SP. The number of other devices belonging to the r-TWT SP can be used by the STA to select one or more attributes of the r-TWT SP. For example, if the STA is the only member of the r-TWT SP, the STA can determine that the MU-RTS TXS trigger frame is not necessary (or not preferred) and can request an r-TWT SP that does not include the MU-RTS TXS trigger frame.

[0170] In some implementations, the trigger frame may be a Multi-User (MU) Request to Send (RTS) TXOP Share (TXS) trigger frame. The MU-RTS TXS trigger frame may include a TXOP share mode subfield indicating the TXOP share mode associated with P2P communication between the STA and the client device. In some cases, the TXOP share mode subfield indicates a request from the STA to send a CTS frame in response to the MU-RTS TXS trigger frame. The CTS frame may include a receiver address field containing the MAC address of the client device.

[0171] In some other implementations, the STA may include a co-located softAP that manages P2P communication between the STA and client devices. In some cases, the softAP may have a different MAC address than the STA. For example, the STA may include a separate MAC entity that can communicate independently with the AP and client devices. In some cases, a first MAC-AP endpoint may be associated with a non-AP STA communicating with the AP, and a second MAC-SAP may be associated with a softAP communicating with client devices. In these implementations, a NAV exception may also indicate that the softAP co-located with the STA belonging to the r-TWT SP will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the CTS frame following the trigger frame.

[0172] Figure 18 illustrates a flowchart of an example program 1800 for wireless communication supporting low-latency communication according to some other implementation. Program 1800 can be executed by a wireless communication device (such as wireless communication device 500 described above with reference to Figure 5). In some implementations, program 1800 can be executed by a wireless communication device operating as a STA (such as one of STA 104 and 604 described above with reference to Figures 1 and 6B respectively) or operating within that STA.

[0173] In some implementations, procedure 1800 can be executed after sending a CTS frame in block 1710 of FIG. 17. For example, at block 1802, procedure 1800 begins by sending a second trigger frame on the wireless medium, the second trigger frame requesting P2P communication from a client device, the second trigger frame including the MAC address of the client device. At block 1804, procedure 1800 continues by receiving a P2P transmission from the client device in response to the second trigger frame. In some cases, before sending the second trigger frame to the client device, the STA determines that the wireless medium is idle for at least the Short Inter-Frame Spacing (SIFS) duration. The P2P communication is received on a Tunnel Direct Link Establishment (TDLS) link established between the STA and the client device. In some cases, the second time period can be based on the time period associated with requesting the CTS frame from the STA.

[0174] In some other implementations, the request frame indicates a first time period during which the STA intends to use the wireless media within the r-TWT SP, and the first trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated to the STA, the second time period being shorter than the first time period.

[0175] Figure 19A illustrates an example structure of a TWT element 1900 that can be used for wireless communication according to some implementations. The TWT element 1900 may include an element ID field 1902, a length field 1904, a control field 1906, and a TWT parameter information field 1908. The element ID field 1902 indicates that the element is a TWT element. The length field 1904 indicates the length of the TWT element 1900. The control field 1906 includes various control information for the limited TWT communication period announced by the TWT element 1900. The TWT parameter information field 1908 contains a single, individual TWT parameter set field or one or more broadcast TWT parameter set fields.

[0176] Figure 19B illustrates an example structure of a broadcast TWT parameter set field 1910 for wireless communication according to some implementations. In some cases, the broadcast TWT parameter set field 1910 may be included within the TWT parameter information field 1908 of Figure 19A. The broadcast TWT parameter set field 1910 may include a request type field 1912, a target wake-up time field 1914, a nominal minimum TWT wake-up duration field 1916, a TWT wake-up interval mantissa field 1917, and a broadcast TWT information field 1918. The request type field 1912 indicates the type of TWT communication period requested. The target wake-up time field 1914 carries an unsigned integer corresponding to the TSF time at which the STA requests wake-up. The nominal minimum TWT wake-up duration field 1916 indicates the minimum amount of time that the TWT requests the STA or a TWT-scheduled STA expects to remain in a wake-up state or mode. The TWT wake-up interval mantissa field 1917 can be set to a non-zero value (for periodic TWTs) and a zero value (for aperiodic TWTs). The broadcast TWT information field 1918 may include the broadcast TWT ID for the corresponding restricted TWT communication period and carry information indicating the number of TBTTs during which there are broadcast TWT SPs corresponding to the broadcast TWT parameter set.

[0177] Figure 19C illustrates an example structure of a request type field 1920 for a broadcast TWT parameter set field that can be used for wireless communication, according to some implementations. In some cases, the request type field 1920 may be an instance of the request type field 1912 of Figure 19C. The request type field 1920 may include a TWT request subfield 1922, a TWT setting command subfield 1924, a trigger subfield 1926, a last broadcast parameter set subfield 1928, a stream type subfield 1930, a broadcast TWT recommendation subfield 1932, a TWT wake-up interval index subfield 1934, and multiple reserved bits 1936. The TWT request subfield 1922 may carry a value indicating whether the corresponding TWT information element is sent by a scheduled STA or by a scheduled STA. The TWT setting command subfield 1924 may carry a value indicating the type of TWT command carried in the TWT information element. Trigger subfield 1926 can indicate whether the TWT SP indicated by TWT element 1900 includes a trigger frame or a frame carrying a TRS control field.

[0178] The Last Broadcast Parameter Set subfield 1928 indicates whether another broadcast TWT parameter set follows. For example, the Last Broadcast Parameter Set subfield 1928 can be set to a value of 0 to indicate that another TWT parameter set follows this set, or it can be set to a value of 1 to indicate that this is the last broadcast TWT parameter set in a broadcast TWT element. The Stream Type subfield 1930 indicates the type of interaction between the TWT requesting STA or the TWT-scheduled STA and the TWT responding STA or the TWT-scheduled AP at the TWT. For example, setting the Stream Type subfield 1930 to a value of 0 indicates that the TWT is declared, where the TWT requesting STA or the TWT-scheduled STA sends a PS-Poll or APSD trigger frame to signal its wake-up status. Setting the Stream Type subfield 1930 to a value of 1 indicates that the TWT is not declared, where the TWT responding STA or the TWT-scheduled AP will send a frame at the TWT to the TWT requesting STA or the TWT-scheduled STA without waiting to receive a PS-Poll or APSD trigger frame.

[0179] The Broadcast TWT Recommendation subfield 1932 contains a recommended value indicating the frame type, which is sent by the TWT-scheduled STA and scheduling AP during the Broadcast TWT SP, and is encoded according to the Broadcast TWT Recommendation subfield 1932 used for broadcast TWT elements. In some cases, the Broadcast TWT Recommendation subfield 1932 may indicate whether the restricted TWT communication period is a peer-to-peer TWT communication period or a broadcast TWT communication period. The TWT Wake-up Interval Index subfield 1934 carries a value from which the TWT wake-up interval can be obtained. In some cases, the TWT Wake-up Interval Index subfield 1934 is set to an exponential value of the TWT wake-up interval in microseconds, based on a base-2 value.

[0180] Figure 20A illustrates an example trigger frame 2000 according to some implementations. The trigger frame 2000 can be used as one or more of the trigger frames described with reference to FIG8-15. The trigger frame 2000 is shown to include a frame control field 2001, a duration field 2002, a receiver address (RA) field 2003, a transmitter address (TA) field 2004, a common information field 2005, multiple user information fields 2006(1)-2006(n), an optional padding field 2007, and a frame check sequence (FCS) field 2008. In some implementations, the trigger frame 2000 may be a UL OFDMA trigger frame. In some other implementations, the trigger frame 2000 may be a UL MU-MIMO mode trigger frame. The frame control field 2001 includes a type field and a subtype field (not shown for simplicity). Type field 2001A can store the value indicating that trigger frame 2000 is a control frame, and subtype field 2001B can store the value indicating the type of trigger frame 2000.

[0181] The duration field 2002 may store information indicating the duration or length of the trigger frame 2000. The RA field 2003 may store the address of the receiving device (such as one or more STAs in Figures 8-15). The TA field 1904 may store the address of the transmitting device (such as the AP in Figures 8-15). The shared information field 2005 may store information shared by one or more receiving devices. Each of the user information fields 2006(1)-2006(n) may store information for a specific receiving device, including, for example, the AID of the receiving device. The padding field 2007 may extend the length of the trigger frame 2000, for example, to give the receiving device additional time to generate a response. The FCS field 2008 may store a frame check sequence (such as for error detection).

[0182] Figure 20B illustrates an example user information field 2010 according to some implementation methods. The user information field 2010 can be used in one or more trigger frames described with reference to Figures 8-15. The user information field 2010 is shown to include an AID12 field 2011, an RU allocation field 2012, a ULFEC encoding type field 2013, a UL HE-MCS field 2014, a UL DCM field 2015, an SS allocation / RA-RU information field 2016, a UL target RSSI field 2017, a reserved field 2018, and a trigger-related user information field 2019.

[0183] FIG21 illustrates a block diagram of an example wireless communication device 2100. In some implementations, the wireless communication device 2100 may be configured to execute the program 1600 described above with reference to FIG16. The wireless communication device 2100 may be an example implementation of any of the AP 102 of FIG1, the wireless communication device 500 of FIG5, or the AP 602 of FIG6A. More specifically, the wireless communication device 2100 may be a chip, SoC, chipset, package, or device including at least one processor and at least one modem (e.g., a Wi-Fi (IEEE 802.11) modem or a cellular modem).

[0184] The wireless communication device 2100 includes a receiving element 2110, a communication manager 2120, and a transmitting component 2130. The communication manager 2120 further includes a channel sensing element 2122 and a delay-sensitive (LS) transmission protection element 2124. One or more portions of elements 2122 or 2124 may be at least partially implemented in hardware or firmware. In some implementations, one or more of elements 2122 or 2124 are at least partially implemented as software stored in memory (such as memory 508 in FIG. 5). For example, one or more portions of elements 2122 or 2124 may be implemented as non-transitory instructions (or "code") executable by a processor (such as processor 506 in FIG. 5) to perform the function or operation of the corresponding component.

[0185] The receiving element 2110 is configured to receive RX signals from one or more other wireless communication devices, and the transmitting element 2130 is configured to signal TX to one or more other wireless communication devices. The communication manager 2120 is configured to manage wireless communication with one or more other wireless communication devices. In some implementations, the channel sensing element 2122 can perform a channel sensing operation indicating whether the wireless channel is busy or idle. The LS transmission volume protection element 2124 can send a response frame or a trigger frame indicating a NAV anomaly for a softAP co-located with a STA, and any client device associated with the co-located softAP, which is associated with the AP and is a member of the r-TWT SP. In some cases, the NAV anomaly indicates that the wireless communication device suffering from the NAV anomaly does not set its corresponding NAV based on the duration indicated in the duration field of the trigger frame sent during the r-TWT SP.

[0186] Figure 22 illustrates a block diagram of an example wireless communication device 2200. In some implementations, the wireless communication device 2200 may be configured to execute programs 1700 and 1800 as described with reference to Figures 17 and 18. The wireless communication device 2200 may be an example implementation of any of the STA 104 of Figure 1, the wireless communication device 500 of Figure 5, or the STA 604 of Figure 6B. More specifically, the wireless communication device 2200 may be a chip, SoC, chipset, package, or device that includes at least one processor and at least one modem (e.g., a Wi-Fi (IEEE 802.11) modem or a cellular modem).

[0187] The wireless communication device 2200 includes a receiving element 2210, a communication manager 2220, and a transmitting component 2230. The communication manager 2220 further includes a latency-sensitive (LS) throughput management component 2222. A portion of the LS throughput management component 2222 may be implemented at least partially in hardware or firmware. In some implementations, the LS throughput management component 2222 is implemented at least partially as software stored in memory (such as memory 508 in FIG. 5). For example, a portion of the LS throughput management component 2222 may be implemented as non-transitory instructions (or "code") executable by a processor (such as processor 506 in FIG. 5) to perform the functions or operations of the corresponding components.

[0188] The receiving element 2210 is configured to receive RX signals from one or more other wireless communication devices, and the transmitting element 2230 is configured to signal TX to one or more other wireless communication devices. The communication manager 2220 is configured to manage wireless communication with one or more other wireless communication devices. In some implementations, the channel sensing element 2222 may receive a response frame or trigger frame indicating a NAV anomaly for a softAP co-located with a STA, and any client device associated with the co-located softAP, which is associated with the AP and is a member of the r-TWT SP. In some cases, the NAV anomaly indicates that the wireless communication device suffering from the NAV anomaly does not set its corresponding NAV based on the duration indicated in the duration field of the trigger frame transmitted during the r-TWT SP.

[0189] Examples of implementations are described in the following numbered clauses: 1. A method for wireless communication by an access point (AP), comprising: receiving a request frame from a radio station (STA) associated with the AP and also associated with a client device via a peer-to-peer (P2P) link, the request frame indicating that the STA intends to exchange P2P communication with the client device during a scheduled limited target wake-up time (r-TWT) service period (SP) on a radio medium, the request frame identifying the client device; responding to receiving the request frame by sending a response frame to the STA on the radio medium; acquiring a transmission opportunity (TXOP) on the radio medium during the r-TWT SP; and responding to acquiring the TXOP by sending a trigger frame on the radio medium, the trigger frame being a portion of the acquired TXOP allocated for P2P communication between the STA and the client device, wherein at least one of the response frame or the trigger frame indicates a network allocation vector (NAV) anomaly for the client device. 2. The method of clause 1, wherein each of the response frame and the trigger frame includes a media access control (MAC) address of the client device. 3. The method of Clause 1, wherein the NAV anomaly indicates that the client device will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the Clear Send (CTS) frame in response to the trigger frame. 4. The method of Clause 1, wherein the STA includes a co-located softAP configured to communicate with the client device, and wherein at least one of the response frame or the trigger frame also indicates an NAV anomaly for the softAP. 5. The method of Clause 4, wherein the NAV anomaly indicates that the softAP co-located with the STA belonging to the r-TWT SP will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the Clear Send (CTS) frame in response to the trigger frame. 6. The method of Clause 1, wherein the trigger frame includes a Carrier Sensing (CS) Request field carrying bits set to a value of 0, wherein bits set to a value of 0 indicate an NAV anomaly. 7. The method of Clause 1, wherein the request frame indicates the Media Access Control (MAC) address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the Clear Send (CTS) frame in response to the trigger frame. 8. The method of Clause 7, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element further indicating one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or a set of parameters of the r-TWT SP.9. According to the method of Clause 7, the request frame is a Stream Classification Service (SCS) request frame that includes a Transport Volume Specification (TSPEC) element indicating the MAC address of a client device, the TSPEC element also indicating a minimum data rate for a limited TWT communication period, an average data rate for a limited TWT communication period, a delay limit for the r-TWT SP, and a user priority (UP) for the r-TWT SP. 10. According to the method of Clause 7, the request frame is a P2P request frame that includes one or more of a TWT element, a TSPEC element, or a Vendor Specific Information (VSIE) element indicating the MAC address of a client device. 11. According to the method of Clause 1, the response frame indicates how many devices are members of the r-TWT SP. 12. According to the method of Clause 1, the trigger frame includes a Multi-User (MU) Request Transmission (RTS) TXOP Share (TXS) trigger frame. 13. The method of Clause 12, wherein the MU-RTS TXS trigger frame includes a TXOP sharing mode subfield indicating a TXOP sharing mode corresponding to P2P communication associated with a client device. 14. The method of Clause 13, wherein the TXOP sharing mode subfield indicates a request for the STA to send a Clear Transmit (CTS) frame in response to the MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device. 15. The method of Clause 1, wherein the request frame indicates a first time period during which the STA intends to use the wireless media within the r-TWT SP, and the trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with the client device, the second time period being shorter than the first time period. 16. The method of Clause 15, wherein the second time period is based on the time period associated with the request for the CTS frame from the STA.17. A wireless communication device comprising: at least one modem; at least one processor communicatively coupled to the at least one modem; and at least one memory communicatively coupled to the at least one processor and storing processor-readable code, the processor-readable code being configured, when executed by the at least one processor in conjunction with the at least one modem, to: receive a request frame from a wireless station (STA) associated with an AP and also associated with a client device via a peer-to-peer (P2P) link, the request frame indicating that the STA intends to exchange P2P communication with the client device during a scheduled limited target wake-up time (r-TWT) service period (SP) on a wireless medium, the request frame identifying the client device; in response to receiving the request frame, sending a response frame to the STA on the wireless medium; acquiring a transmission opportunity (TXOP) on the wireless medium during the r-TWT SP; and in response to acquiring the TXOP, sending a trigger frame on the wireless medium, the trigger frame being part of the TXOP acquired for P2P communication allocation between the STA and the client device, wherein at least one of the response frame or the trigger frame indicates a network allocation vector (NAV) anomaly for the client device. 18. A wireless communication device according to Clause 17, wherein each of the response frame and the trigger frame includes a Media Access Control (MAC) address of the client device. 19. A wireless communication device according to Clause 17, wherein a NAV anomaly indicates that the client device will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the Clear Send (CTS) frame responding to the trigger frame. 20. A wireless communication device according to Clause 17, wherein the STA includes a co-located softAP configured to communicate with the client device, and wherein at least one of the response frame or the trigger frame also indicates a NAV anomaly for the softAP. 21. A wireless communication device according to Clause 20, wherein a NAV anomaly indicates that a softAP co-located with an STA belonging to the r-TWT SP will ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by the Clear Send (CTS) frame responding to the trigger frame. 22. A wireless communication device according to Clause 17, wherein the trigger frame includes a carrier sensing (CS) request field carrying bits set to a value of 0, wherein the bits set to a value of 0 indicate a NAV abnormality. 23. A wireless communication device according to Clause 17, wherein a request frame indicates the media access control (MAC) address of the client device, and a response frame indicates that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the clear transmission (CTS) frame in response to the trigger frame.24. The wireless communication device according to Clause 23, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element further indicating one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or a set of parameters of the r-TWT SP. 25. The wireless communication device according to Clause 23, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element further indicating the minimum data rate for the limited TWT communication period, the average data rate for the limited TWT communication period, the delay limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. 26. The wireless communication device of Clause 23, wherein the request frame is a P2P request frame, the P2P request frame including one or more of a TWT element, a TSPEC element, or a Vendor Specific Information Element (VSIE) indicating at least the MAC address of the client device. 27. The wireless communication device of Clause 17, wherein the response frame indicates how many devices are members of the r-TWT SP. 28. The wireless communication device of Clause 17, wherein the trigger frame includes a Multi-User (MU) Request to Transmit (RTS) TXOP Share (TXS) trigger frame, the MU-RTS TXOP trigger frame including a TXOP share mode subfield indicating a TXOP share mode corresponding to P2P communication associated with a client device. 29. The wireless communication device of Clause 28, wherein the TXOP share mode subfield indicates a request for a STA to send a Clear Transmit (CTS) frame in response to a MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device. 30. A wireless communication device pursuant to Clause 17, wherein a request frame indicates a first time period during which the STA intends to use wireless media within the r-TWT SP, and a trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with a client device, the second time period being shorter than the first time period.31. A method for wireless communication by a wireless communication device, comprising: operating the wireless communication device as a wireless station (STA) associated with an access point (AP), the STA also being associated with a client device via a peer-to-peer (P2P) link; sending a request frame to the AP, the request frame indicating that the STA intends to exchange P2P communication with the client device during a scheduled limited target wake-up time (r-TWT) service period (SP) on a wireless medium, the request frame identifying the client device; receiving a response frame from the AP on the wireless medium; receiving a first trigger frame from the AP on the wireless medium, the first trigger frame allocating a transmission opportunity (TXOP) obtained by the AP for P2P communication between the STA and the client device, wherein at least one of the response frame or the first trigger frame indicates a network allocation vector (NAV) anomaly for the client device; and sending a clear send (CTS) frame to the AP on the wireless medium, the CTS frame including a receiver address field containing a media access control (MAC) address of the client device. 32. The method of Clause 31, wherein each of the response frame and the first trigger frame includes the MAC address of the client device. 33. The method of Clause 31, wherein the NAV anomaly indicates that the client device will ignore the NAV duration indicated by the first trigger frame and the NAV duration indicated by the CTS frame. 34. The method of Clause 31, wherein the wireless communication device includes a softAP co-located with the STA, the co-located softAP being configured to communicate with the client device, and wherein at least one of the response frame or the trigger frame further indicates an NAV anomaly for the softAP. 35. The method of Clause 34, wherein the NAV anomaly indicates that the softAP co-located with the STA belonging to the r-TWT SP will ignore the NAV duration indicated by the first trigger frame and the NAV duration indicated by the CTS frame. 36. The method of Clause 31, wherein the first trigger frame includes a carrier sensing (CS) request field carrying bits set to a value of 0, wherein bits set to a value of 0 indicate an NAV anomaly. 37. The method of Clause 31, wherein the request frame indicates the Media Access Control (MAC) address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by the first trigger frame and the CTS frame. 38. The method of Clause 37, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element further indicating one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or a set of parameters of the r-TWT SP.39. The method of Clause 37, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element further indicating a minimum data rate for the limited TWT communication period, an average data rate for the limited TWT communication period, a delay limit for the r-TWT SP, and a user priority (UP) for the r-TWT SP. 40. The method of Clause 37, wherein the request frame is a P2P request frame including one or more of a TWT element, a TSPEC element, or a Vendor Specific Information (VSIE) element indicating the MAC address of the client device. 41. The method of Clause 31, wherein the request frame includes a request for the AP to send a Multi-User (MU) Request Transmission (RTS) TXOP Share (TXS) trigger frame or a basic trigger frame when requesting P2P communication between the STA and the client device. 42. The method of Clause 31, wherein the trigger frame includes a Multi-User (MU) Request Transmission (RTS) TXOP Sharing (TXS) trigger frame, the MU-RTS TXOP trigger frame including a TXOP sharing mode subfield indicating the TXOP sharing mode associated with P2P communication between the STA and the client device. 43. The method of Clause 31, further comprising: transmitting on the wireless media a second trigger frame requesting P2P communication from the client device, the second trigger frame including the MAC address of the client device; and responding to the second trigger frame by receiving a P2P transmission from the client device. 44. The method of Clause 43, wherein before transmitting the second trigger frame to the client device, the STA determines that the wireless media is idle for at least the Short Frame Interval (SIFS) duration. 45. The method of Clause 44, wherein the P2P communication is received on a Tunnel Direct Link Establishment (TDLS) link established between the STA and the client device. 46. ​​The method of Clause 31, wherein the request frame indicates a first time period during which the STA intends to use wireless media within the r-TWT SP, and the first trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with a client device, the second time period being shorter than the first time period. 47. The method of Clause 46, wherein the second time period is based on the time period associated with the CTS frame requested from the STA.48. A wireless communication device, comprising: at least one modem; at least one processor communicatively coupled to the at least one modem; and at least one memory communicatively coupled to the at least one processor and storing processor-readable code, the processor-readable code being configured, when executed by the at least one processor in conjunction with the at least one modem, to: operate the wireless communication device as a wireless station (STA) associated with an access point (AP), the STA also being associated with a client device via a peer-to-peer (P2P) link; send a request frame to the AP, the request frame instructing the STA to intend to exchange P2P communication with the client device during a scheduled limited target wake-up time (r-TWT) service period (SP) on a wireless medium, the request frame identifying the client device; and receive a response frame from the AP on the wireless medium; The device receives a first trigger frame from the AP on the wireless media, the first trigger frame being part of a transmission opportunity (TXOP) allocated by the AP for P2P communication between the STA and the client device, wherein at least one of the response frame or the first trigger frame indicates a Network Assigned Vector (NAV) anomaly for the client device; and sends a Clear Send (CTS) frame to the AP on the wireless media, the CTS frame including a receiver address field containing the Media Access Control (MAC) address of the client device. 49. The wireless communication device of claim 48, wherein each of the response frame and the first trigger frame includes the MAC address of the client device. 50. The wireless communication device of claim 48, wherein an NAV anomaly indicates that the client device intends to ignore the NAV duration indicated by the first trigger frame or the NAV duration indicated by the CTS frame. 51. The wireless communication device of claim 48, wherein the wireless communication device includes a softAP co-located with the STA, the co-located softAP being configured to communicate with the client device, and wherein at least one of the response frame or the trigger frame also indicates an NAV anomaly for the softAP. 52. A wireless communication device according to Clause 51, wherein a softAP co-located with an r-TWT SP and a STA will ignore the NAV duration indicated by a first trigger frame and the NAV duration indicated by a CTS frame. 53. A wireless communication device according to Clause 48, wherein a first trigger frame includes a carrier sensing (CS) request field carrying bits set to a value of 0, wherein bits set to a value of 0 indicate a NAV abnormality. 54. A wireless communication device according to Clause 48, wherein a request frame indicates the media access control (MAC) address of a client device, and a response frame indicates that the client device will ignore the NAV duration set by the first trigger frame and the CTS frame.55. The wireless communication device according to Clause 48, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element also indicating one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or a set of parameters of the r-TWT SP. 56. The wireless communication device according to Clause 55, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element also indicating the minimum data rate for the limited TWT communication period, the average data rate for the limited TWT communication period, the delay limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. 57. The wireless communication device according to Clause 55, wherein the request frame is a P2P request frame, the P2P request frame including one or more of a TWT element, a TSPEC element, or a Vendor Specific Information Element (VSIE) indicating the MAC address of the client device. 58. The wireless communication device according to Clause 48, wherein the request frame includes a request for the AP to send a Multi-User (MU) Request to Transmit (RTS) TXOP Share (TXS) trigger frame or a basic trigger frame when requesting P2P communication between the STA and the client device. 59. The wireless communication device according to Clause 48, wherein the trigger frame includes a Multi-User (MU) Request to Transmit (RTS) TXOP Share (TXS) trigger frame, the MU-RTS TXOP trigger frame including a TXOP share mode subfield indicating the TXOP share mode corresponding to the P2P communication associated with the client device. 60. A wireless communication device according to Clause 48, wherein the execution of processor-readable code is also configured to: transmit a second trigger frame on the wireless medium requesting P2P communication from a client device, the second trigger frame including the MAC address of the client device; and respond to the second trigger frame by receiving P2P transmissions from the client device. 61. A wireless communication device according to Clause 60, wherein before sending the second trigger frame to the client device, the STA determines that the wireless medium is idle for at least the duration of the Short Frame Interval (SIFS). 62. A wireless communication device according to Clause 60, wherein the P2P communication is received on a Tunnel Direct Link Establishment (TDLS) link established between the STA and the client device.63. A wireless communication device pursuant to Clause 48, wherein a request frame indicates a first time period during which the STA intends to use wireless media within an r-TWT SP, and a first trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with a client device, the second time period being shorter than the first time period. 64. A wireless communication device pursuant to Clause 63, wherein the second time period is based on the time period associated with a CTS frame requested from the STA. 65. A method for wireless communication from an access point (AP), comprising: receiving a request frame from a wireless station (STA) associated with the AP and also associated with a client device, the request frame indicating that the STA intends to exchange peer-to-peer (P2P) communication with the client device over a wireless medium, the request frame identifying the client device; obtaining a transmission opportunity (TXOP) on the wireless medium; and in response to obtaining the TXOP, sending a trigger frame on the wireless medium, the trigger frame being a portion of the obtained TXOP allocated for P2P communication between the STA and the client device, wherein at least one of the trigger frame or the response frame indicates a network allocation vector (NAV) anomaly for the client device. 66. The method of claim 65, wherein the trigger frame includes a media access control (MAC) address of the client device. 67. The method of claim 65, wherein an NAV anomaly indicates that the client device intends to ignore the NAV duration indicated by the trigger frame and the NAV duration indicated by a clear send (CTS) frame in response to the trigger frame. 68. The method of Clause 65, wherein the STA is co-located with a softAP configured to communicate with a client device, and wherein the trigger frame also indicates a NAV anomaly for the softAP. 69. The method of Clause 68, wherein the NAV anomaly indication co-located with the STA (associated with the AP) will ignore both the NAV duration indicated by the trigger frame and the NAV duration indicated by a Clear Send (CTS) frame responding to the trigger frame. 70. The method of Clause 65, wherein the trigger frame includes a Carrier Sensing (CS) Request field carrying bits set to a value of 0, wherein bits set to a value of 0 indicate a NAV anomaly. 71. The method of Clause 65, further comprising: responding to a Receive Request frame by sending a response frame on the radio medium to the STA, the response frame indicating a NAV anomaly for the client device. 72. The method according to Clause 71, wherein the request frame indicates the Media Access Control (MAC) address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the Clear Send (CTS) frame in response to the trigger frame.73. The method of Clause 72, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element also indicating the Transport Volume Stream (TS), the minimum data rate for Protocol Data Units (PDUs) associated with the TS, the average data rate for the PDUs associated with the TS, the delay limit for the TS, and the User Priority (UP) for the TS. 74. The method of Clause 72, wherein the request frame is a P2P request frame including one or more of a TWT element, a TSPEC element, or a Vendor Specific Information Element (VSIE) indicating the MAC address of the client device. 75. The method of Clause 65, wherein the trigger frame includes a Multi-User (MU) Request Transmission (RTS) TXOP Share (TXS) trigger frame. 76. The method of Clause 75, wherein the MU-RTS TXS trigger frame includes a TXOP sharing mode subfield indicating a TXOP sharing mode corresponding to P2P communication associated with a client device. 77. The method of Clause 76, wherein the TXOP sharing mode subfield indicates a request for a STA to send a Clear Transmit (CTS) frame in response to the MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device. 78. A wireless communication device comprising: at least one modem; at least one processor communicatively coupled to the at least one modem; and at least one memory communicatively coupled to the at least one processor and storing processor-readable code configured, when executed by the at least one processor in conjunction with the at least one modem, to perform any one or more of the operations of Clauses 65-77. 79. A method for wireless communication by a wireless communication device, comprising: operating the wireless communication device as a wireless station (STA) associated with an access point (AP), the STA also being associated with a client device via a peer-to-peer (P2P) link; sending a request frame to the AP, the request frame indicating that the STA intends to exchange P2P communication with the client device over a wireless medium, the request frame identifying the client device; receiving a first trigger frame from the AP over the wireless medium, the first trigger frame allocating a portion of a transmission opportunity (TXOP) obtained by the AP for P2P communication between the STA and the client device, wherein at least one of the first trigger frame or a response frame indicates a network allocation vector (NAV) anomaly for the client device; and sending a clear send (CTS) frame to the AP over the wireless medium, the CTS frame including a receiver address field containing a media access control (MAC) address of the client device. 80. The method of claim 79, wherein the first trigger frame includes the MAC address of the client device.81. The method of Clause 79, wherein the NAV anomaly indicates that the client device will ignore the NAV duration indicated by the first trigger frame and the NAV duration indicated by the Clear Send (CTS) frame responding to the first trigger frame. 82. The method of Clause 79, wherein the wireless communication device includes a softAP co-located with the STA, the co-located softAP being configured to communicate with the client device, and wherein at least one of the response frame or the first trigger frame also indicates an NAV anomaly for the softAP. 83. The method of Clause 82, wherein the NAV anomaly indicates that the softAP co-located with the STA (associated with the AP) will ignore the NAV duration indicated by the first trigger frame and the NAV duration indicated by the Clear Send (CTS) frame responding to the trigger frame. 84. The method of Clause 79, wherein the first trigger frame includes a Carrier Sensing (CS) Request field carrying bits set to a value of 0, wherein the bits set to a value of 0 indicate an NAV anomaly. 85. The method of Clause 79 further includes: receiving a response frame from the AP on the wireless media, the response frame responding to the request frame and indicating an NAV exception for the client device. 86. The method of Clause 85, wherein the request frame indicates the Media Access Control (MAC) address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by a trigger frame sent from the AP and the NAV duration set by a Clear Send (CTS) frame responding to the trigger frame. 87. The method of Clause 86, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element also indicating the Transport Volume Stream (TS), the minimum data rate for Protocol Data Units (PDUs) associated with the TS, the average data rate for the PDUs associated with the TS, the delay limit for the TS, and the User Priority (UP) for the TS. 88. The method of Clause 86, wherein the request frame is a P2P request frame, the P2P request frame including one or more of the following: a TWT element, a TSPEC element, or a Vendor Specific Information Element (VSIE) indicating the MAC address of the client device. 89. The method of Clause 79, wherein the first trigger frame includes a Multi-User (MU) Request to Send (RTS) TXOP Share (TXS) trigger frame. 90. The method of Clause 89, wherein the MU-RTS TXS trigger frame includes a TXOP share mode subfield indicating the TXOP share mode corresponding to P2P communication associated with the client device.91. The method of Clause 90, wherein the TXOP shared mode subfield indicates a request for the STA to send a Clear Transmit (CTS) frame in response to a MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device. 92. The method of Clause 79, further comprising: sending a second trigger frame on the wireless media requesting P2P communication from the client device, the second trigger frame including the MAC address of the client device; and receiving the P2P transmission from the client device in response to the second trigger frame. 93. The method of Clause 92, wherein before sending the second trigger frame to the client device, the STA determines that the wireless media is idle for at least the Short Frame Interval (SIFS) duration. 94. The method of Clause 92, wherein the P2P communication is received on a Tunnel Direct Link Establishment (TDLS) link established between the softAP and the client device. 95. A wireless communication device comprising: at least one modem; at least one processor communicatively coupled to the at least one modem; and at least one memory communicatively coupled to the at least one processor and storing processor-readable code configured to perform any one or more of the operations of clauses 79-94 when executed by the at least one processor in conjunction with the at least one modem. 96. A method for wireless communication from an access point (AP), comprising: receiving a request frame from a wireless station (STA) associated with and co-located with the AP and a softAP, the softAP being associated with a peer-to-peer (P2P) client device, the request frame indicating that the softAP intends to exchange P2P communication with the client device during a scheduled limited target wake-up time (r-TWT) service period (SP) on a wireless medium; acquiring a transmission opportunity (TXOP) on the wireless medium during the r-TWT SP; and sending a multi-user (MU) request transmission (RTS) TXOP sharing (TXS) trigger frame on the wireless medium to the STA, the MU-RTS TXS trigger frame allocating a portion of the acquired TXOP for P2P communication between the softAP and the client device, the MU-RTS TXS trigger frame indicating a sharing mode associated with a network allocation vector (NAV) for the softAP. 97. The method of claim 96, wherein the request frame includes a vendor-specific information element (VSIE) indicating an intention to exchange P2P communication with the client device. 98. The method of Clause 96, wherein a NAV anomaly indicates that the softAP will ignore the NAV duration indicated by the MU-RTS TXS trigger frame. 99. The method of Clause 98, wherein a NAV anomaly also indicates that the client device will ignore the NAV duration indicated by the MU-RTS TXS trigger frame.100. The method of Clause 99, wherein the MU-RTS TXS trigger frame indicates the Media Access Control (MAC) address of the softAP and the MAC address of the client device. 101. The method of Clause 96, wherein a NAV anomaly indicates that a softAP co-located with a STA belonging to the r-TWT SP will ignore the duration of the NAV indicated by the MU-RTS TXS trigger frame. 102. The method of Clause 96, further comprising: in response to receiving a request frame, sending a response frame on the radio medium to the AP, the response frame indicating how many devices are members of the r-TWT SP. 103. The method of Clause 96, wherein the MU-RTS TXS trigger frame includes a Carrier Sensing (CS) Request field carrying bits set to a value of 0, wherein the bits set to a value of 0 indicate a NAV anomaly. 104. The method of Clause 96, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element further indicating one or more of the following: the period of the r-TWT SP, the duration of the r-TWT SP, the sharing mode of the r-TWT SP, the wake-up duration of the r-TWT SP, the stream type of the r-TWT SP, or a set of parameters of the r-TWT SP. 105. The method of Clause 96, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element also indicating the minimum data rate for the r-TWT SP, the average data rate for the r-TWT SP, the delay limit for the r-TWT SP, and the user priority (UP) for the r-TWT SP. 106. The method of Clause 96, wherein the request frame is a P2P request frame, the P2P request frame including one or more of at least a TWT element, a TSPEC element, or a vendor-specific information element (VSIE) indicating the MAC address of the client device. 107. The method of Clause 96, wherein the request frame indicates a first time period during which the STA intends to use wireless media within the r-TWT SP, and the MU-RTS TXS trigger frame includes a duration field indicating a second time period during which a portion of the TXOP is allocated for P2P communication associated with the client device, the second time period being shorter than the first time period. 108. The method of Clause 107, wherein the second time period is based on the time period associated with requesting the CTS frame from the STA.109. A wireless communication device comprising: at least one modem; at least one processor communicatively coupled to the at least one modem; and at least one memory communicatively coupled to the at least one processor and storing processor-readable code, which, when executed by the at least one processor in conjunction with the at least one modem, is configured to perform any one or more of the operations of clauses 96-108.

[0190] As used herein, the phrase “at least one of” or “one or more of” in the list of items refers to any combination of those items, including a single member. For example, “at least one of a, b or c” is intended to cover the following possibilities: only a, only b, only c, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a, b and c.

[0191] The various exemplary elements, logic, logic blocks, modules, circuits, operations, and algorithms described herein can be implemented as electronic hardware, firmware, software, or a combination of hardware, firmware, or software, including the structures and their equivalents disclosed herein. This interchangeability of hardware, firmware, and software has been generally described in its functional form and illustrated in the various exemplary elements, blocks, modules, circuits, and programs described above. Whether such functionality is implemented in hardware, firmware, or software depends on the specific application and the design constraints imposed on the overall system.

[0192] Various modifications to the implementation described herein will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the spirit or scope of this document. Therefore, the claim is not intended to be limited to the implementation shown herein, but should be granted the broadest scope consistent with the content of this document, the principles disclosed herein, and the novel features.

[0193] Furthermore, the various features described in this specification in the context of individual implementations may also be implemented in combination in a single implementation. Conversely, the various features described in the context of a single implementation may also be implemented individually or in any suitable combination of subgroups in multiple implementations. Thus, although the features may be described above as operating in a particular combination, and even initially claimed in this way, one or more features from the claimed combination may be removed from that combination in some cases, and the claimed combination may be for subgroup combinations or variations of subgroup combinations.

[0194] Similarly, although the operations are illustrated in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or sequentially, or requiring the execution of all illustrated operations to achieve the desired result. Furthermore, the drawings may schematically illustrate one or more example programs in the form of flowcharts or flow diagrams. However, other operations not illustrated may be incorporated into the schematically illustrated example programs. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the illustrated operations. In some cases, multiplexing and parallel processing may be advantageous. Moreover, the individuality of the various system elements in the implementations described above should not be construed as requiring such individuality in all implementations, and it should be understood that the described program elements and systems can generally be integrated together in a single software product or packaged into multiple software products. [Simplified Explanation of the Diagram]

[0016] Figure 1 illustrates a schematic diagram of an example wireless communication network.

[0017] Figure 2A illustrates an example Protocol Data Unit (PDU) that can be used for communication between an Access Point (AP) and one or more Wireless Stations (STAs).

[0018] Figure 2B shows an example field in the PDU of Figure 2A.

[0019] Figure 3A illustrates another example PDU that can be used for communication between an AP and one or more STAs.

[0020] Figure 3B illustrates another example PDU that can be used for communication between an AP and one or more STAs.

[0021] Figure 4 illustrates an example entity layer convergence protocol (PLCP) protocol data unit (PPDU) that can be used for communication between an AP and multiple STAs.

[0022] Figure 5 illustrates a block diagram of an example wireless communication device.

[0023] Figure 6A illustrates a block diagram of an example access point (AP).

[0024] Figure 6B shows a block diagram of an example station (STA).

[0025] Figure 7 illustrates a timing diagram depicting an example of wireless communication between devices belonging to a Basic Service Set (BSS).

[0026] Figure 8 is a timing diagram illustrating another example of wireless communication that supports latency-sensitive throughput according to some implementations.

[0027] Figure 9 is a timing diagram illustrating another example of wireless communication that supports latency-sensitive throughput according to some implementations.

[0028] Figure 10 illustrates a timing diagram of another example of wireless communication supporting latency-sensitive throughput according to some implementation methods.

[0029] Figure 11 is a timing diagram illustrating another example of wireless communication that supports latency-sensitive throughput according to some implementations.

[0030] Figure 12 is a timing diagram illustrating another example of wireless communication that supports latency-sensitive throughput according to some implementation methods.

[0031] Figure 13 illustrates a timing diagram of another example of wireless communication supporting latency-sensitive throughput according to some implementation methods.

[0032] Figure 14 is a timing diagram illustrating another example of wireless communication that supports latency-sensitive throughput according to some implementations.

[0033] Figure 15 illustrates a timing diagram of another example of wireless communication supporting latency-sensitive throughput according to some implementation methods.

[0034] Figure 16 illustrates a flowchart of an example program for wireless communication that supports low-latency communication according to some implementation methods.

[0035] Figure 17 illustrates a flowchart of an example program for wireless communication that supports low-latency communication according to some other implementations.

[0036] Figure 18 illustrates a flowchart of another example program for wireless communication that supports low-latency communication according to some other implementation.

[0037] Figure 19A illustrates an example structure of a TWT element that can be used for wireless communication according to some implementation methods.

[0038] Figure 19B illustrates an example structure of a broadcast TWT parameter set field that can be used for wireless communication according to some implementation methods.

[0039] Figure 19C illustrates an example structure of the request type field in the broadcast TWT parameter set field that can be used for wireless communication according to some implementations.

[0040] Figure 20A illustrates an example structure of a trigger frame that can be used for wireless communication according to some implementation methods.

[0041] Figure 20B illustrates an example structure of the user information field of the trigger message box in Figure 20A.

[0042] Figure 21 shows a block diagram of an example wireless communication device according to some implementation methods.

[0043] Figure 22 shows a block diagram of another example wireless communication device according to some implementation methods.

[0044] Similar element symbols and markings in the various figures indicate similar elements. [Biomaterial Storage]

[0196] Domestic storage information (please note in order of storage institution, date, and number) None Foreign storage information (please note in order of storage country, institution, date, and number) None

Claims

1. A method for wireless communication by an access point (AP), comprising the steps of: receiving a request frame from a wireless station (STA) associated with the AP and also associated with a client device via a peer-to-peer (P2P) link, the client device being different from the STA, and the request frame indicating that the STA intends to exchange P2P communication with the client device during a limited target wake-up time (r-TWT) service period (SP) scheduled on a wireless medium, the request frame identifying the client device; responding to receiving the request frame by sending a response frame to the STA on the wireless medium; acquiring a transmission opportunity (TXOP) on the wireless medium during the r-TWT SP; and responding to acquiring the TXOP by sending a trigger frame to the STA on the wireless medium, the trigger frame allocating a portion of the acquired TXOP for P2P communication between the STA and the client device, wherein at least one of the response frame sent to the STA or the trigger frame sent to the STA indicates a network allocation vector (NAV) anomaly for the client device.

2. According to the method of request item 1, each of the response frame and the trigger frame includes a media access control (MAC) address of the client device.

3. According to the method of request item 1, wherein the NAV exception indicates that the client device will ignore a NAV duration indicated by the trigger frame and a NAV duration indicated by a clear send (CTS) frame in response to the trigger frame.

4. The method according to request item 1, wherein the STA includes a co-located softAP configured to communicate with the client device, and wherein at least one of the response frame or the trigger frame further indicates a NAV exception for the softAP.

5. According to the method of request item 4, wherein the NAV exception indication and the softAP co-located with the STA belonging to the r-TWT SP will ignore a NAV duration indicated by the trigger frame and a NAV duration indicated by a clear send (CTS) frame in response to the trigger frame.

6. The method according to request item 1, wherein the trigger frame includes a carrier sensing (CS) request field carrying a bit set to a value of 0, wherein the bit set to a value of 0 indicates the NAV abnormality.

7. The method according to request item 1, wherein the request frame indicates a media access control (MAC) address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by the trigger frame sent from the AP and the NAV duration set by the clear send (CTS) frame in response to the trigger frames.

8. The method according to request item 7, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element further indicating one or more of the following: a period of the r-TWT SP, a duration of the r-TWT SP, a sharing mode of the r-TWT SP, a wake-up duration of the r-TWT SP, a stream type of the r-TWT SP, or a set of parameters of the r-TWT SP.

9. The method of request item 7, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element further indicating a minimum data rate for the limited TWT communication period, an average data rate for the limited TWT communication period, a delay limit for the r-TWT SP, and a user priority (UP) for the r-TWT SP.

10. The method according to request item 7, wherein the request frame is a P2P request frame, the P2P request frame including one or more of a TWT element, a TSPEC element or a vendor-specific information element (VSIE) that indicates the MAC address of the client device.

11. According to the method of request item 1, wherein the response message box indicates how many devices are members of the r-TWT SP.

12. The method of request item 1, wherein the triggering frame includes a multi-user (MU) request to send (RTS) TXOP share (TXS) triggering frame.

13. The method of request item 12, wherein the MU-RTS TXS trigger frame includes a TXOP sharing mode subfield indicating a TXOP sharing mode corresponding to the P2P communication associated with the client device.

14. The method of request item 13, wherein the TXOP shared mode subfield indicates a request for the STA to send a clear transmit (CTS) frame in response to the MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device.

15. The method according to claim 1, wherein the request frame indicates a first time period during which the STA intends to use the wireless media within the r-TWT SP, and the trigger frame includes a duration field indicating a second time period during which the portion of the TXOP is allocated for P2P communication associated with the client device, the second time period being shorter than the first time period.

16. The method of request item 15, wherein the second time period is based on a time period associated with requesting the CTS frame from the STA.

17. A wireless communication device configured as an access point (AP), comprising: At least one data center; At least one processor communicatively coupled to the at least one modem; and at least one memory, communicatively coupled to the at least one processor and storing processor-readable code, which, when executed by the at least one processor in conjunction with the at least one modem, is configured to: receive a request frame from a radio station (STA) associated with the AP and also associated with a client device via a peer-to-peer (P2P) link, the client device being different from the STA, and the request frame indicating that the STA intends to exchange P2P communication with the client device during a limited target wake-up time (r-TWT) service period (SP) scheduled on a radio medium, the request frame identifying the client device; respond to receiving the request frame by sending a response frame to the STA on the radio medium; in the r-TWT During SP, a transmission opportunity (TXOP) is obtained on the wireless medium; and in response to obtaining the TXOP, a trigger frame is sent to the STA on the wireless medium, the trigger frame allocating a portion of the obtained TXOP for P2P communication between the STA and the client device, wherein at least one of the response frame sent to the STA or the trigger frame sent to the STA indicates an anomaly in a network allocation vector (NAV) for the client device.

18. The wireless communication device according to request item 17, wherein each of the response frame and the trigger frame includes a media access control (MAC) address of the client device.

19. The wireless communication device according to claim 17, wherein the NAV anomaly indicates that the client device will ignore a NAV duration indicated by the trigger frame and a NAV duration indicated by a clear send (CTS) frame in response to the trigger frame.

20. The wireless communication device according to claim 17, wherein the STA includes a co-located softAP configured to communicate with the client device, and wherein at least one of the response frame or the trigger frame also indicates a NAV exception for the softAP.

21. The wireless communication device according to claim 20, wherein the NAV anomaly indication and the softAP co-located with the STA belonging to the r-TWT SP will ignore a NAV duration indicated by the trigger frame and a NAV duration indicated by a clear transmit (CTS) frame in response to the trigger frame.

22. The wireless communication device according to request item 17, wherein the trigger frame includes a carrier sensing (CS) request field carrying a bit of a value set to 0, wherein the bit of the value set to 0 indicates the NAV abnormality.

23. The wireless communication device according to claim 17, wherein the request frame indicates a media access control (MAC) address of the client device, and the response frame indicates that the client device will ignore the NAV duration set by a trigger frame sent from the AP and the NAV duration set by a clear send (CTS) frame in response to the trigger frames.

24. The wireless communication device according to request item 23, wherein the request frame is a TWT request frame including a TWT element indicating the MAC address of the client device, the TWT element further indicating one or more of the following: a period of the r-TWT SP, a duration of the r-TWT SP, a sharing mode of the r-TWT SP, a wake-up duration of the r-TWT SP, a stream type of the r-TWT SP, or a set of parameters of the r-TWT SP.

25. The wireless communication device according to claim 23, wherein the request frame is a Stream Classification Service (SCS) request frame including a Transport Volume Specification (TSPEC) element indicating the MAC address of the client device, the TSPEC element further indicating a minimum data rate for the limited TWT communication period, an average data rate for the limited TWT communication period, a delay limit for the r-TWT SP, and a user priority (UP) for the r-TWT SP.

26. The wireless communication device according to claim 23, wherein the request frame is a P2P request frame, the P2P request frame including one or more of a TWT element, a TSPEC element or a vendor-specific information element (VSIE) indicating the MAC address of the client device.

27. The wireless communication device according to request item 17, wherein the response frame indicates how many devices are members of the r-TWT SP.

28. The wireless communication device according to claim 17, wherein the trigger frame includes a Multi-User (MU) Request to Send (RTS) TXOP Share (TXS) trigger frame, the MU-RTS TXS trigger frame including a TXOP share mode subfield indicating a TXOP share mode corresponding to the P2P communication associated with the client device.

29. The wireless communication device according to claim 28, wherein the TXOP sharing mode subfield indicates a request for the STA to send a clear transmit (CTS) frame in response to the MU-RTS TXS trigger frame, the CTS frame including a receiver address field containing the MAC address of the client device.

30. The wireless communication device according to claim 17, wherein the request frame indicates a first time period during which the STA intends to use the wireless media within the r-TWT SP, and the trigger frame includes a duration field indicating a second time period during which the portion of the TXOP is allocated for P2P communication associated with the client device, the second time period being shorter than the first time period.

Images