Low latency method of peer-to-peer (p2p) communication

Abstract

The present disclosure provides a system and method for requesting wireless resources for peer-to-peer (P2P) communication. In some implementations, a wireless communication device transmits a frame over a wireless medium to an access point (AP), the frame including a medium access control (MAC) header carrying a request for the AP to allocate a portion of a transmission opportunity (TXOP) for P2P communication between the wireless communication device and a client device. The wireless communication device receives a trigger frame that allocates the portion of the TXOP for the P2P communication, and transmits or receives P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP. In some instances, the MAC header of the frame includes a quality of service (QoS) control field that carries the request. In some other instances, the MAC header of the frame includes an aggregate control (A-control) subfield that carries the request.

Description

[Technical field]

[0001] cross reference

[0001] This patent application claims the benefit of U.S. patent application Ser. No. 17 / 513,645 by AJAMI et al., entitled "LOW LATENCY SCHEMES FOR PEER-TO-PEER (P2P) COMMUNICATIONS," filed on October 28, 2021, which is assigned to the assignee of this application and expressly incorporated by reference into this specification.

[0002] FIELD OF THE DISCLOSURE The present disclosure relates generally to wireless communications, and more particularly to dynamically scheduling resources of a shared wireless medium for peer-to-peer (P2P) communications. [Background technology]

[0003]

[0003] A wireless local area network (WLAN) may be formed by one or more access points (APs) that provide a shared wireless medium for use by several client devices or stations (STAs). Each AP, which may support a Basic Service Set (BSS), may periodically broadcast a beacon frame to enable any STA within wireless range of the AP to establish and maintain a communication link with the WLAN. WLANs that operate according to the IEEE 802.11 family of standards are commonly referred to as Wi-Fi networks.

[0004]

[0004] Some wireless communication devices may be associated with low-latency applications that have strict end-to-end latency, throughput, and timing requirements for data traffic. Exemplary 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 that provide connectivity to these applications. Some low-latency applications utilize peer-to-peer (P2P) communication between client devices (such as AR / VR headsets) and STAs associated with APs. For example, a wireless communication device running a real-time gaming application may operate as a STA that transmits and receives game data to and from a gaming service via an associated AP, and at the same time, operate as a soft AP that transmits and receives game data to and from an associated AR / VR headset. When a STA operating as a softAP connected to an AR / VR headset (or other client device) via a P2P link executes a real-time gaming application, the P2P communication between the STA and the AR / VR headset may be subject to the latency, throughput, and timing requirements associated with the gaming application. Similarly, gaming data transmitted between the STA and its associated AP may also be subject to the latency, throughput, and timing requirements associated with the gaming application. Summary of the Invention

[0005]

[0005] The systems, methods, and devices of the present disclosure each have several innovative aspects, no single aspect of which is solely responsible for the desirable properties disclosed herein.

[0006]

[0006] One innovative aspect of the subject matter described in this disclosure may be implemented as a method of wireless communication by a wireless communication device. In some implementations, the method may include transmitting a frame over a wireless medium to an access point (AP) that includes a medium access control (MAC) header carrying a request to the AP to allocate a portion of a transmission opportunity (TXOP) for peer-to-peer (P2P) communication between the wireless communication device and a client device. The method may include receiving a trigger frame over the wireless medium from the AP that allocates the portion of the TXOP of the P2P communication to the wireless communication device. The method may include transmitting or receiving P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP. In some aspects, the request indicates one or more of a duration of a requested portion of the TXOP, a requested bandwidth of the P2P communication, a traffic identifier (TID) for the P2P communication, a Stream Classification Service (SCS) identifier (SCSID) for the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval for the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame.

[0007] In some implementations, the MAC header of the frame includes a Quality-of-Service (QoS) control field carrying the request. In some instances, the QoS control field includes a reserved bit set to a value indicating that the frame is a P2P request frame, a TID subfield set to a value indicating that the frame is a P2P request frame and having a value of 8 or greater, or an Acknowledgement (ACK) Policy Indicator subfield set to a value indicating that the frame is a P2P request frame. In some aspects, the QoS control field includes an End Of Service Period (EOSP) subfield, an ACK Policy Indicator subfield following the EOSP subfield, a reserved bit following the ACK Policy Indicator subfield, and an octet following the reserved bit, where the octet indicates one or more of a duration of the requested portion of the TXOP, a queue size of the wireless communication device, or a TXOP shared mode bandwidth based on the value carried in the EOSP subfield and the reserved bit. For example, an EOSP subfield carrying a value of 0 when the reserved bit is set to 1 signals that the octet indicates a duration of the requested portion of a TXOP and the ACK policy indicator subfield signals that the octet indicates a TXOP shared mode bandwidth, and an EOSP subfield carrying a value of 1 when the reserved bit is set to 1 signals that the octet indicates both the TXOP shared mode bandwidth and the duration of the requested portion of the TXOP. In another example, an EOSP subfield carrying a value of 0 when the reserved bit is set to 0 signals that the octet indicates a duration of the requested portion of a TXOP, and an EOSP subfield carrying a value of 1 when the reserved bit is set to 0 signals that the octet indicates a queue size of the wireless communications device.

[0008]

[0008] In some other implementations, the MAC header of the frame includes an Aggregated-Control (A-Control) subfield carrying the request. In some instances, the A-Control subfield includes a Control identification (Control ID) subfield carrying a reserved value indicating that the frame is a P2P request frame, and includes a Control Information subfield carrying one or more parameters of the P2P communication. The one or more parameters of the P2P communication may include one or more of a duration of a requested portion of a TXOP, a requested bandwidth of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a requested type of a trigger frame requesting the P2P communication, a TID of the P2P communication, a SCSID of the P2P communication, a user priority of a traffic flow associated with the P2P communication, a queue size of the wireless communication device, or a delay bound of a service period associated with the P2P communication. In some aspects, the reserved value carried in the Control ID subfield is one of 9, 11, 12, 13, or 14. In some other cases, the A Control subfield carries a control information subfield including a Delta TID subfield set to a reserved value indicating that the frame is a P2P request frame, and Queue Size High and Queue Size All subfields set to values ​​that collectively indicate the duration of the requested portion of the TXOP and the requested TXOP shared mode bandwidth.

[0009] In some instances, the frame may be a TWT request frame including a target wake time (TWT) element indicating a MAC address of the client device and one or more TWT parameters of a restricted TWT (r-TWT) service period (SP) associated with the P2P communication. In some other instances, the frame may be an SCS request frame including a TSPEC element indicating a MAC address of the client device and one or more data rate parameters of an r-TWT SP associated with the P2P communication. In various implementations, the trigger frame may be a multi-user (MU) Request-to-Send (RTS) TXOP sharing (TXS) trigger frame including a TXOP sharing mode subfield indicating a TXOP sharing mode of the P2P communication between the wireless communication device and the client device. In some aspects, the trigger frame identifies the wireless communication device and the client device.

[0010]

[0010] In some implementations, the method further includes receiving a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request. In some cases, the response frame's MAC header includes a QoS control field or an A-control subfield indicating one or more of a duration of a portion of the TXOP to be allocated to the P2P communication, a bandwidth to be allocated to the P2P communication, a TID of the P2P communication, a SCSID of the P2P communication, a start time of a service period associated with the P2P communication, a service interval associated with the P2P communication, a delay bound of a service period associated with the P2P communication, or a requested type of trigger frame. In some aspects, the response frame may be a QoS data frame or a Block Acknowledgement (BA) frame.

[0011] In some other implementations, the method further includes transmitting latency-sensitive traffic to the client device over the wireless medium based on receiving the trigger frame from the AP, transmitting a P2P trigger frame to the client device over the wireless medium after transmitting the latency-sensitive traffic to the client device, and receiving latency-sensitive traffic from the client device over the wireless medium based on the P2P trigger frame. In various implementations, the method further includes operating the wireless communication device as a wireless station (STA) associated with the AP and simultaneously operating the wireless communication device as a softAP with which the client device is associated.

[0012] Another innovative aspect of the subject matter described in this disclosure may 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 together with the at least one modem, is configured to transmit a frame to the AP over a wireless medium, the frame including a MAC header carrying a request for the AP to allocate at least a portion of a TXOP of a P2P communication between the wireless communication device and a client device. Execution of the processor-readable code is configured to receive, over the wireless medium, from the AP, a trigger frame that allocates a portion of the TXOP of the P2P communication to the wireless communication device. Execution of the processor-readable code is configured to transmit or receive P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP. In some aspects, the request indicates one or more of a duration of a requested portion of the TXOP, a requested bandwidth of the P2P communication, a TID of the P2P communication, a SCSID of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame.

[0013] In some implementations, the MAC header of the frame includes a QoS control field carrying the request. In some instances, the QoS control field includes a reserved bit set to a value indicating that the frame is a P2P request frame, a TID subfield set to a value indicating that the frame is a P2P request frame and having a value of 8 or greater, or an ACK policy indicator subfield set to a value indicating that the frame is a P2P request frame. In some aspects, the QoS control field includes an EOSP subfield, an ACK policy indicator subfield following the EOSP subfield, a reserved bit following the ACK policy indicator subfield, and an octet following the reserved bit, where the octet indicates one or more of a duration of the requested portion of the TXOP, a queue size of the wireless communication device, or a TXOP shared mode bandwidth based on the value carried in the EOSP subfield and the reserved bit. For example, an EOSP subfield carrying a value of 0 when the reserved bit is set to 1 signals that the octet indicates a duration of the requested portion of a TXOP and the ACK policy indicator subfield signals that the octet indicates a TXOP shared mode bandwidth, and an EOSP subfield carrying a value of 1 when the reserved bit is set to 1 signals that the octet indicates both the TXOP shared mode bandwidth and the duration of the requested portion of the TXOP. In another example, an EOSP subfield carrying a value of 0 when the reserved bit is set to 0 signals that the octet indicates a duration of the requested portion of a TXOP, and an EOSP subfield carrying a value of 1 when the reserved bit is set to 0 signals that the octet indicates a queue size of the wireless communications device.

[0014]

[0014] In some other implementations, the MAC header of the frame includes an A-control subfield carrying a request. In some instances, the A-control subfield includes a control ID subfield carrying a reserved value indicating that the frame is a P2P request frame, and includes a control information subfield carrying one or more parameters of the P2P communication. The one or more parameters of the P2P communication may include one or more of a duration of a requested portion of a TXOP, a requested bandwidth of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a requested type of a trigger frame requesting the P2P communication, a TID of the P2P communication, a SCSID of the P2P communication, a user priority of a traffic flow associated with the P2P communication, a queue size of the wireless communication device, or a delay bound of a service period associated with the P2P communication. In some aspects, the reserved value carried in the control ID subfield is one of 9, 11, 12, 13, or 14. In some other cases, the A-control subfield carries a control information subfield that includes a Delta TID subfield set to a reserved value indicating that the frame is a P2P request frame, and Queue Size High and Queue Size All subfields set to values ​​that collectively indicate the duration of the requested portion of the TXOP and the requested TXOP shared mode bandwidth.

[0015] In some cases, the frame may be a TWT request frame including a TWT element indicating a MAC address of the client device and one or more TWT parameters of an r-TWT SP associated with the P2P communication. In some other cases, the frame may be an SCS request frame including a TSPEC element indicating a MAC address of the client device and one or more data rate parameters of an r-TWT SP associated with the P2P communication. In various implementations, the trigger frame may be an MU-RTS TXS trigger frame including a TXOP sharing mode subfield indicating a TXOP sharing mode of the P2P communication between the wireless communication device and the client device. In some aspects, the trigger frame identifies the wireless communication device and the client device.

[0016]

[0016] In some implementations, the execution of the processor-readable code may also be configured to receive a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request. In some instances, the response frame's MAC header includes a QoS control field or an A-control subfield indicating one or more of the duration of the requested portion of the TXOP, the bandwidth to be allocated to the P2P communication, the TID of the P2P communication, the SCSID of the P2P communication, the start time of a service period associated with the P2P communication, the service interval associated with the P2P communication, the delay limit of the service period associated with the P2P communication, or the requested type of trigger frame. In some aspects, the response frame may be a QoS data frame or a BA frame.

[0017] In some other implementations, execution of the processor readable code may also be configured to transmit latency-sensitive traffic to the client device over the wireless medium based on receiving the trigger frame from the AP, transmit a P2P trigger frame to the client device over the wireless medium after transmitting the latency-sensitive traffic to the client device, and receive latency-sensitive traffic from the client device over the wireless medium based on the P2P trigger frame. In various implementations, execution of the processor readable code may also be configured to operate the wireless communication device as a STA associated with the AP while simultaneously operating the wireless communication device as a softAP with which the client device is associated. [Brief description of the drawings]

[0018]

[0018] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. Please note that the relative dimensions of the following figures may not be drawn to scale. [Figure 1]

[0019] 1 shows a pictorial diagram of an exemplary wireless communication network. [Figure 2A]

[0020] 1 illustrates an exemplary protocol data unit (PDU) that may be used for communication between an access point (AP) and one or more wireless stations (STAs). [Figure 2B]

[0021] 2B illustrates exemplary fields within the PDU of FIG. 2A. [Figure 3A]

[0022] 4 illustrates another exemplary PDU that may be used for communication between an AP and one or more STAs. [Figure 3B]

[0023] 4 illustrates another exemplary PDU that may be used for communication between an AP and one or more STAs. [Figure 4]

[0024] 1 illustrates an exemplary physical layer convergence protocol (PLCP) protocol data unit (PPDU) that can be used for communication between an AP and several STAs. [Diagram 5]

[0025] 1 illustrates a block diagram of an exemplary wireless communication device. [Figure 6A]

[0026] 1 shows a block diagram of an exemplary access point (AP). [Figure 6B]

[0027] 1 shows a block diagram of an exemplary station (STA). [Figure 7]

[0028] 1 shows a pictorial diagram of another example wireless network, according to some implementations. [Figure 8]

[0029] 1 illustrates a timing diagram illustrating an example of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive peer-to-peer (P2P) traffic, according to some implementations. [Figure 9]

[0030] 1 shows a flowchart illustrating another example process of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic, according to some implementations. [Figure 10]

[0031] 1 shows a flowchart illustrating another example process of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic, according to some implementations. [Figure 11]

[0032] 13 shows a flowchart illustrating another example process of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic, according to some other implementations. [Figure 12]

[0033] 1 shows a flowchart illustrating another example process of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic, according to some implementations. [Figure 13]

[0034] 1 illustrates an example configuration of a Medium Access Control (MAC) header that can be used for wireless communications, according to some implementations. [Figure 14A]

[0035] 14 shows a table describing the content and bit assignments of the Quality of Service (QoS) Control field of FIG. 13 for a number of different frame types and subtypes. [Figure 14B]

[0036] 1 illustrates an example configuration of a QoS control field usable for wireless communications, according to some implementations. [Figure 15]

[0037] 1 illustrates an example configuration of an Aggregate Control (A-Control) sub-field available for wireless communication, according to some implementations. [Figure 16]

[0038] 1 illustrates another example configuration of an A control subfield usable for wireless communication, according to some implementations. [Figure 17A]

[0039] 1 illustrates an example configuration of a target wake time (TWT) element usable for wireless communication, according to some implementations. [Figure 17B]

[0040] 1 illustrates an example configuration of a broadcast TWT Parameter Set field available for wireless communication according to some implementations. [Figure 17C]

[0041] 1 illustrates an example configuration of a Request Type field in a Broadcast TWT Parameter Sets field available for wireless communication, according to some implementations. [Figure 18]

[0042] 1 illustrates an example configuration of a Traffic Specification (TSPEC) field that can be used for wireless communications, according to some implementations. [Figure 19]

[0043] 1 shows a block diagram of an example wireless communication device according to some implementations.

[0019]

[0044] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020]

[0045] The following description is directed to some specific implementations for the purpose of illustrating the innovative aspects of the present disclosure. 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 one or more of the Long Term Evolution (LTE), 3G, 4G, or 5G (New Radio (NR)) standards promulgated 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), among others. The described implementations may be implemented in any device, system, or network capable of transmitting and receiving RF signals according to one or more of the following technologies or techniques: code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), single-user (SU) multiple-input multiple-output (MIMO), and multi-user (MU) MIMO.The described implementations may also be implemented using other wireless communications protocols or RF signals suitable for use in one or more of a wireless wide area network (WWAN), a wireless personal area network (WPAN), a wireless local area network (WLAN), or an internet of things (IOT) network.

[0021]

[0046] Many wireless networks use a random channel access mechanism to control access to a shared wireless medium. In these wireless networks, wireless communication devices (including access points (APs) and wireless stations (STAs)) compete with each other using carrier sense multiple access / collision avoidance (CSMA / CA) techniques to gain access to the wireless medium. Generally, the wireless communication device that randomly selects the lowest back-off number (RBO) wins the medium access contention operation and may be granted access to the wireless medium for a period of time commonly referred to as a transmission opportunity (TXOP). Other wireless communication devices are generally not allowed to transmit during the TXOP of another wireless communication device to avoid collisions on the shared wireless medium.

[0022]

[0047] Some random channel access mechanisms, such as enhanced distributed channel access (EDCA), give high priority traffic a higher likelihood of gaining medium access than low priority traffic. EDCA classifies data into different access categories (ACs), such as voice (AC_VO), video (AC_VI), best effort (AC_BE), and background (AC_BK). Each AC is associated with a different priority level and may be assigned a different range of RBOs such that higher priority data is more likely to win a TXOP than lower priority data (e.g., by assigning a lower RBO to higher priority data and a higher RBO to lower priority data). Although EDCA increases the likelihood that low latency data traffic will gain access to the shared wireless medium during a given contention period, the unpredictable outcome of medium access contention behavior may prevent low latency applications from achieving a certain level of throughput or meeting certain latency requirements.

[0023]

[0048] The IEEE 802.11be amendment of the IEEE 802.11 standard describes a limited target wake time (TWT) service period (SP) that may be used to provide more predictable latency, reduced worst-case latency, or reduced jitter with greater reliability for latency-sensitive traffic. As used herein, the term "non-legacy STA" may refer to any STA that supports limited TWT operation, and the term "low latency STA" may refer to any non-legacy STA that has latency-sensitive traffic to transmit or receive. In contrast, the term "legacy STA" may refer to any STA that does not support limited TWT operation. The IEEE 802.11be amendment requires that all non-legacy STAs ("non-member STAs") that are TXOP holders outside of any non-member limited TWT SP (r-TWT SP) terminate their respective TXOP before the start of the r-TWT SP. Although membership in an r-TWT SP may be reserved exclusively for low-latency STAs, the current rules for r-TWT SP do not prevent non-member STAs from obtaining a TXOP during an r-TWT SP. As a result, some non-member STAs may gain access to the shared wireless medium during an r-TWT SP even before members of the r-TWT SP can obtain channel access.

[0024]

[0049] Some latency-sensitive traffic may be exchanged between wireless devices using peer-to-peer (P2P) communications. For example, a wireless communication device, such as a non-AP STA, running a real-time gaming application may operate as a STA that transmits and receives gaming data to and from a gaming service via an associated AP over an access link, and simultaneously operate as a softAP that transmits and receives gaming data to and from an associated AR / VR headset (or another suitable client device) over a P2P link. While the wireless communication device is running the real-time gaming application, the P2P communications between the STA and the AR / VR headset may be subject to latency, throughput, and timing requirements associated with the gaming application. Similarly, the gaming data transmitted between the STA and the associated AP may also be subject to latency, throughput, and timing requirements associated with the gaming application. While latency-sensitive traffic may be given extended channel protection using r-TWT SP, real-time gaming traffic (and other types of latency-sensitive traffic) may benefit from the ability to dynamically request additional wireless resources from the associated AP. For example, if a STA running a real-time gaming application admits additional players to the gaming application, the amount of gaming data sent to (and received from) the STA may suddenly increase, requiring additional resources to avoid violating the latency, throughput, and timing requirements associated with the gaming application.

[0025]

[0050] Various aspects of the subject matter disclosed herein relate generally to wireless communications associated with latency-sensitive applications, and in particular to providing dynamic channel access to low-latency STAs to meet various latency, throughput, and timing requirements of such latency-sensitive applications. In some aspects, a low-latency STA, such as a smartphone or other client device, may transmit a frame to an associated AP including a Medium Access Control (MAC) header carrying a request for the AP to allocate at least a portion of a TXOP obtained by the AP for P2P or other latency-sensitive communications between the low-latency STA and another client device, such as an AR / VR headset. The request may indicate one or more of a duration of a requested portion of the TXOP, a requested bandwidth of the P2P communication, a traffic identifier (TID) of the P2P communication, a Stream Classification Service (SCS) identifier (SCSID) of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame. The AP may acknowledge the request by transmitting a response frame including a MAC header carrying an acknowledgement of the request. In some instances, the MAC header of the response frame may include a Quality of Service (QoS) control field or an Aggregate Control (A-Control) subfield indicating the duration of the requested portion of the TXOP, the bandwidth to be allocated to the P2P communication, the TID of the P2P communication, the SCSID of the P2P communication, the start time of a service period associated with the P2P communication, a service interval associated with the P2P communication, a delay bound for the service period, a requested type of trigger frame, or any combination thereof.

[0026]

[0051] The AP may then transmit a trigger frame that allocates a portion (which may be a requested portion) of the TXOP for P2P communication to the low-latency STA. In some cases, the trigger frame may be a multi-user (MU) request to send (RTS) TXOP share (TXS) trigger frame that includes a TXOP sharing mode subfield that indicates a TXOP sharing mode of P2P communication between the low-latency STA and other client devices. The low-latency STA may receive the trigger frame and transmit or receive P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP. In some cases, the low-latency STA and the client device may exchange P2P data using a P2P link or a link that conforms to the Wi-Fi Direct protocol.

[0027]

[0052] Particular implementations of the subject matter described in this disclosure may be implemented to achieve one or more of the following potential advantages: By enabling a wireless communication device, such as a low-latency STA (e.g., a smartphone) to dynamically request additional wireless resources for latency-sensitive communication with a client device (e.g., an AR / VR headset), aspects of the present disclosure may ensure that the wireless communication device and its associated client device may be dynamically allocated sufficient channel access to meet various latency, throughput, and timing requirements associated with real-time applications. Also, by allowing resource allocation requests to be carried within the MAC headers of frames, such as QoS Null frames and QoS Data frames, aspects of the present disclosure may enable the wireless communication device to dynamically transmit such requests to the AP based on, for example, real-time changes in resources needed to meet various latency, throughput, and timing requirements associated with real-time applications.

[0028]

[0053] FIG. 1 illustrates a block diagram of an exemplary wireless communication network 100. According to some aspects, the wireless communication network 100 may be an example of a wireless local area network (WLAN), such as a Wi-Fi network (also referred to hereinafter as WLAN 100). For example, the WLAN 100 may be a network that implements at least one of the IEEE 802.11 family of standards (such as those defined by the IEEE 802.11-2016 specification or amendments thereto, including but not limited to 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be). The WLAN 100 may include multiple wireless communication devices, such as an access point (AP) 102 and multiple stations (STAs) 104. Although only one AP 102 is shown, the WLAN 100 may also include multiple APs 102.

[0029]

[0054] Each of the STAs 104 may also be referred to as a mobile station (MS), mobile device, mobile handset, wireless handset, access terminal (AT), user equipment (UE), subscriber station (SS), or subscriber unit, among other possible examples. The STAs 104 may represent a variety of devices, such as a mobile phone, a personal digital assistant (PDA), other handheld device, a netbook, a notebook computer, a tablet computer, a laptop, a display device (e.g., a TV, a computer monitor, a navigation system, among others), a music device or other audio or stereo device, a remote control device ("remote"), a printer, a kitchen appliance or other household appliance, a key fob (e.g., for a passive keyless entry and start (PKES) system), among other possible examples.

[0030]

[0055] A single AP 102 and the associated set of STAs 104 may be referred to as a basic service set (BSS) managed by each AP 102. FIG. 1 additionally illustrates an example coverage area 106 of the AP 102, which may represent a basic service area (BSA) of the WLAN 100. The BSS may be identified to users by a service set identifier (SSID) and to other devices by a basic service set identifier (BSSID), which may be a media access control (MAC) address of the AP 102. The AP 102 periodically broadcasts a beacon frame ("beacon") containing the BSSID to allow any STAs 104 within wireless range of the AP 102 to "associate" or reassociate with the AP 102 to establish or maintain a respective communication link 108 with the AP 102 (hereinafter also referred to as a "Wi-Fi link"). For example, the beacon may include an identification of a primary channel used by each AP 102, as well as a timing synchronization function to establish or maintain timing synchronization with the AP 102. The APs 102 may provide access to external networks to various STAs 104 in the WLAN via respective communication links 108.

[0031]

[0056] To establish a communication link 108 with an AP 102, each of the STAs 104 is configured to perform passive or active scanning operations ("scans") on frequency channels in one or more frequency bands (e.g., the 2.4 GHz, 5.0 GHz, 6.0 GHz, or 60 GHz bands). To perform passive scanning, the STAs 104 listen for beacons, which are transmitted by the respective APs 102 at periodic time intervals called target beacon transmission times (TBTTs) (measured in time units (TUs), where one TU may equal 1024 microseconds (μs)). To perform active scanning, the STAs 104 generate probe requests and transmit them continuously on each channel to be scanned, and listen for probe responses from the APs 102. Each STA 104 may be configured to perform authentication and association operations to identify or select an AP 102 to associate with based on scanning information obtained through passive or active scanning, and establish a communication link 108 with the selected AP 102. The AP 102 assigns an association identifier (AID) to the STA 104 during the association operation, which the AP 102 uses to track the STA 104.

[0032]

[0057] As a result of the increasing ubiquity of wireless networks, a STA 104 may have the opportunity to select one of many BSSs within range of the STA, or among multiple APs 102 that together form an extended service set (ESS) that includes multiple connected BSSs. The extended network stations associated with the WLAN 100 may be connected to a wired or wireless distribution system that may allow multiple APs 102 to be connected in such an ESS. Thus, a STA 104 may be covered by more than one AP 102 and may associate with different APs 102 at different times for different transmissions. Additionally, after association with an AP 102, the STA 104 may also be configured to periodically scan its surroundings to find a more suitable AP 102 to associate with. For example, a STA 104 moving with respect to its associated AP 102 may perform a "roaming" scan to find another AP 102 with more desirable network characteristics, such as a greater received signal strength indicator (RSSI) or a lower traffic load.

[0033]

[0058] In some cases, the STAs 104 may form a network without involving the AP 102 or other devices other than the STAs 104 themselves. One example of such a network is an ad-hoc network (or wireless ad-hoc network). An ad-hoc network may alternatively be referred to as a mesh network or a peer-to-peer (P2P) network. In some cases, the ad-hoc network may be implemented within a larger wireless network, such as the WLAN 100. In such an implementation, the STAs 104 may be able to communicate with each other via the AP 102 using the communication link 108, but the STAs 104 may also communicate with each other directly via a direct communication link 110. In addition, two STAs 104 may communicate via the direct communication link 110 regardless of whether both STAs 104 are associated with and served by the same AP 102. In such an ad-hoc system, one or more of the STAs 104 may assume the role played by the AP 102 in the BSS. Such STAs 104 may be referred to as group owners (GOs) and may coordinate transmissions within the ad-hoc network. Examples of direct communication links 110 include Wi-Fi direct connections, connections established by using Wi-Fi Tunneled Direct Link Setup (TDLS) links, and other P2P group connections.

[0034]

[0059] The AP 102 and the STAs 104 may function and communicate (via their respective communication links 108) in accordance with the IEEE 802.11 family of standards (such as those defined by the IEEE 802.11-2016 specification or amendments thereto, 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 at the PHY layer and medium access control (MAC) layer. The AP 102 and the STAs 104 transmit and receive wireless communications (hereinafter also referred to as "Wi-Fi communications") between each other in the form of Physical Layer Convergence Protocol (PLCP) Protocol Data Units (PPDUs). The AP 102 and the STAs 104 in the WLAN 100 may transmit PPDUs over an unlicensed spectrum, which may be a portion of a spectrum including frequency bands traditionally used by Wi-Fi technology, such as the 2.4 GHz band, the 5.0 GHz band, the 60 GHz band, the 3.6 GHz band, and the 900 MHz band. Some implementations of the AP 102 and the STAs 104 described herein may also communicate in other frequency bands, such as the 6.0 GHz band, which may support both licensed and unlicensed communications. The AP 102 and the STAs 104 may also be configured to communicate over other frequency bands, such as shared licensed frequency bands, in which multiple operators may have licenses to operate in the same or one or more overlapping frequency bands.

[0035]

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

[0036]

[0061] Each PPDU is a composite structure that includes a PHY preamble and a payload in the form of a PLCP service data unit (PSDU). Information provided in the preamble may be used by a receiving device to decode subsequent data in the PSDU. In cases where the PPDU is transmitted over bonded channels, the preamble field may be replicated and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble may be used for packet detection, automatic gain control, and channel estimation, among other applications. The legacy preamble may also generally be used to maintain compatibility with legacy devices. The format, encoding, and information provided therein of the non-legacy portion of the preamble is based on the particular IEEE 802.11 protocol to be used to transmit the payload.

[0037]

[0062] 2A illustrates an exemplary protocol data unit (PDU) 200 usable for wireless communication between an AP 102 and one or more STAs 104. For example, the PDU 200 may be configured as a PPDU. As shown, the PDU 200 includes a PHY preamble 202 and a PHY payload 204. For example, the preamble 202 may include a legacy portion that itself includes a legacy short training field (L-STF) 206, which may consist of two BPSK symbols, a legacy long training field (L-LTF) 208, which may consist of two BPSK symbols, and a legacy signal field (L-SIG) 210, which may consist of two BPSK symbols. The legacy portion of the preamble 202 may be configured in accordance with the IEEE 802.11a wireless communication protocol standard. The preamble 202 may also include a non-legacy portion that includes one or more non-legacy fields 212 that conform to an IEEE wireless communication protocol, such as, for example, an IEEE 802.11ac, 802.11ax, 802.11be, or later wireless communication protocol standard.

[0038]

[0063] 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 enables the receiving device to perform an initial estimation of the wireless channel. The L-SIG 210 generally enables the receiving device to determine the period of the PDU and use the determined period to avoid transmitting at the beginning of the PDU. For example, the L-STF 206, the L-LTF 208, and the L-SIG 210 may be modulated according to a binary phase shift keying (BPSK) modulation scheme. The payload 204 may 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. The payload 204 may include a PSDU that includes a data field (DATA) 214, which may carry higher layer data, for example in the form of Medium Access Control (MAC) protocol data units (MPDUs) or aggregated MPDUs (A-MPDUs).

[0039]

[0064] 2B illustrates an example L-SIG 210 in the PDU 200 of FIG. 2A. The L-SIG 210 includes a data rate field 222, a reserved bit 224, a length field 226, a parity bit 228, and a tail field 230. The data rate field 222 indicates a 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 the length of the packet, e.g., in units of symbols or bytes. The parity bit 228 may be used to detect bit errors. The tail field 230 includes tail bits that may be used by a receiving device to terminate the operation of a decoder (e.g., a Viterbi decoder). The receiving device may use the data rate and length indicated in the data rate field 222 and length field 226 to determine the time length of the packet, e.g., in units of microseconds (μs) or other time units.

[0040]

[0065] 3A illustrates another exemplary PDU 300 usable for wireless communication between an AP and one or more STAs. The PDU 300 may be used for SU, OFDMA, or MU-MIMO transmissions. The PDU 300 may be formatted as a High Efficiency (HE) WLAN PPDU in accordance with the IEEE 802.11ax amendment to the IEEE 802.11 wireless communication protocol standard. The PDU 300 includes a PHY preamble including a legacy portion 302 and a non-legacy portion 304. The PDU 300 may further include a payload 306 following the preamble, for example in the form of a PSDU including a data field 324.

[0041]

[0066] The legacy portion 302 of the preamble includes an L-STF 308, an L-LTF 310, and an L-SIG 312. The non-legacy portion 304 includes a repetition of the L-SIG (RL-SIG) 314, a first HE signal field (HE-SIG-A) 316, an HE short training field (HE-STF) 320, and one or more HE long training fields (or symbols) (HE-LTF) 322. In the case of OFDMA or MU-MIMO communications, the non-legacy portion 304 further includes a second HE signal field (HE-SIG-B) 318 that is coded separately from the HE-SIG-A 316. In cases involving the use of bonded channels, such as the L-STF 308, L-LTF 310, and L-SIG 312, the information in the RL-SIG 314 and HE-SIG-A 316 may be duplicated and transmitted in each of the 20 MHz component channels. In contrast, the content of the HE-SIG-B 318 may be unique to each 20 MHz channel and the particular STA 104 targeted.

[0042]

[0067] The RL-SIG 314 may indicate to the HE compatible STAs 104 that the PDU 300 is an HE PPDU. The AP 102 may use the HE-SIG-A 316 to inform the STAs 104 that the AP has identified the STAs 104 and scheduled UL or DL ​​resources for the STAs 104. For example, the HE-SIG-A 316 may include a resource allocation subfield indicating the resource allocation for the identified STAs 104. The HE-SIG-A 316 may be decoded by each HE compatible STA 104 served by the AP 102. In the case of a MU transmission, the HE-SIG-A 316 further includes information usable by each identified STA 104 to decode the associated HE-SIG-B 318. For example, the HE-SIG-A 316 may indicate the frame format, including the location and length of the HE-SIG-B 318, the available channel bandwidth, and the modulation and coding scheme (MCS), among other examples. The HE-SIG-A 316 may also include HE WLAN signaling information usable by STAs 104 other than the identified STA 104.

[0043]

[0068] The HE-SIG-B 318 may carry STA-specific scheduling information, such as, for example, a STA-specific (or "user-specific") MCS value and STA-specific RU allocation information. In the context of DL MU-OFDMA, such information allows each STA 104 to identify and decode the corresponding resource unit (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 for multiple STAs 104, including RU assignments in the frequency domain, which RUs are assigned to MU-MIMO transmissions, which RUs correspond to MU-OFDMA transmissions, and the number of users in the allocation, among other examples. The common field may be encoded with common bits, CRC bits, and tail bits. The user-specific field may be assigned to a particular STA 104 and used to schedule specific RUs and indicate the scheduling to other WLAN devices. Each user-specific field may include multiple user block fields. Each user block field may include two user fields containing information for two respective STAs to decode the respective RU payloads in the data field 324.

[0044]

[0069] 3B illustrates another exemplary PPDU 350 usable for wireless communication between an AP and one or more STAs. The PDU 350 may be used for SU, OFDMA, or MU-MIMO transmissions. The PDU 350 may be formatted as an Extreme High Throughput (EHT) WLAN PPDU according to the IEEE 802.11be amendment to the IEEE 802.11 wireless communication protocol standard, or as a PPDU compliant with any later (post-EHT) version of a new wireless communication protocol that complies with a future IEEE 802.11 wireless communication protocol standard or other wireless communication standard. The PDU 350 includes a PHY preamble that includes a legacy portion 352 and a non-legacy portion 354. The PDU 350 may further include a PHY payload 356 following the preamble, for example in the form of a PSDU that includes a data field 376.

[0045]

[0070] The legacy portion 352 of the preamble includes an L-STF 358, an L-LTF 360, and an L-SIG 362. The non-legacy portion 354 of the preamble includes an RL-SIG 364 and a number of wireless communication protocol version-dependent signal fields following the RL-SIG 364. For example, the non-legacy portion 354 may include a universal 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 the U-SIG 366 and the EHT-SIG 368 may be configured as and carry version-dependent information for other wireless communication protocol versions beyond EHT. The non-legacy portion 354 further includes an additional (referred to herein as “EHT-STF 372” although it may be configured as other wireless communication protocol versions beyond EHT and carry version dependent information therefor) short training field 372 and one or more additional (referred to herein as “EHT-LTF 374” although it may be configured as other wireless communication protocol versions beyond EHT and carry version dependent information therefor) long training fields 374. In cases involving the use of bonded channels, such as the L-STF 358, L-LTF 360, and L-SIG 362, the information in the U-SIG 366 and EHT-SIG 368 may be duplicated and transmitted in each of the 20 MHz component channels. In some implementations, the EHT-SIG 368 may additionally or alternatively carry information in one or more 20 MHz non-primary channels that are different from the information being carried in the 20 MHz primary channel.

[0046]

[0071] The EHT-SIG 368 may include one or more jointly encoded symbols and may be encoded in a different block than the block in which the U-SIG 366 is encoded. The EHT-SIG 368 may be used by the AP to inform the STAs 104 that the AP has identified and scheduled UL or DL ​​resources for the STAs 104. The EHT-SIG 368 may be decoded by each compatible STA 104 served by the AP 102. The EHT-SIG 368 may generally be used by a receiving device to interpret bits in the data field 376. For example, the EHT-SIG 368 may include RU allocation information, spatial stream configuration information, and per-user signaling information such as MCS, among other examples. The EHT-SIG 368 may further include a cyclic redundancy check (CRC) (e.g., 4 bits) and a tail (e.g., 6 bits) that may be used for a binary convolutional code (BCC). In some implementations, the EHT-SIG 368 may include one or more code blocks, each including a CRC and a tail. In some aspects, each of the code blocks may be coded separately.

[0047]

[0072] The EHT-SIG 368 may carry STA-specific scheduling information, such as, for example, a user-specific MCS value and user-specific RU allocation information. The EHT-SIG 368 may generally be used by a receiving device to interpret bits in the data field 376. In the context of DL MU-OFDMA, such information allows each 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 RU distribution to multiple STAs 104, indicate RU assignment in the frequency domain, indicate which RUs are assigned to MU-MIMO transmissions, which RUs correspond to MU-OFDMA transmissions, and the number of users in the assignment, among other examples. The common field may be encoded with common bits, CRC bits, and tail bits. The user-specific field may be assigned to a particular STA 104 and used to schedule a specific RU and indicate the scheduling to other WLAN devices. Each user specific field may include multiple user block fields, and each user block field may include, for example, two user fields that store information about two respective STAs for decoding the respective RU payloads.

[0048]

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

[0049]

[0074] 4 illustrates an exemplary PPDU 400 that may be used for communication between an AP 102 and several STAs 104. As discussed above, each PPDU 400 includes a PHY preamble 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 that includes multiple MAC MPDU subframes 408. Each MPDU subframe 408 may include a MAC delimiter 412 and a MAC header 414 before an associated frame body 416 that includes a 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-MSDU) 422 that includes multiple MAC service data unit (MSDU) subframes 424. Each MSDU sub-frame 424 includes a corresponding MSDU 426 , which includes a sub-frame header 428 , a frame body 430 , and one or more padding bits 432 .

[0050]

[0075] Referring again to the A-MPDU subframe 406, the MAC header 414 may include several fields that contain information that defines or indicates characteristics or attributes of the data encapsulated within the frame body 416. The MAC header 414 also includes several fields that indicate the address of the data encapsulated within the frame body 416. For example, the MAC header 414 may include a combination of a source address, a transmitter address, a receiver address, or a destination address. The MAC header 414 may include a frame control field that contains control information. The frame control field specifies the frame type, e.g., a data frame, a control frame, or a management frame. The MAC header 414 may further include a duration field that indicates a period of time that extends from the end of the PPDU to the end of the acknowledgement (ACK) of the last PPDU to be transmitted by the wireless communication device (e.g., a block ACK (BA) in the case of A-MPDU). The use of the duration field serves to reserve the wireless medium for the indicated period of time, thus establishing a 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.

[0051]

[0076] As described above, the AP 102 and the STAs 104 may support multi-user (MU) communications, i.e., simultaneous transmissions from one device to each of multiple devices (e.g., multiple simultaneous downlink (DL) communications from the AP 102 to the corresponding STAs 104) or simultaneous transmissions from multiple devices to a single device (e.g., multiple simultaneous uplink (UL) transmissions from the corresponding STAs 104 to the AP 102). To support MU transmissions, the AP 102 and the STAs 104 may utilize multi-user multiple-input, multiple-output (MU-MIMO) and multi-user orthogonal frequency division multiple access (MU-OFDMA) techniques.

[0052]

[0077] In the MU-OFDMA scheme, the available frequency spectrum of a wireless channel may be divided into multiple resource units (RUs), each including several different frequency subcarriers ("tones"). Different RUs may be allocated or assigned by the AP 102 to different STAs 104 at a particular time. The size and distribution of the RUs may be referred to as the RU allocation. In some implementations, the RUs may be allocated at 2 MHz intervals, so that the smallest RU may include 26 tones, consisting of 24 data tones and 2 pilot tones. As a result, in a 20 MHz channel, a maximum of 9 RUs (such as a 2 MHz, 26-tone RU) may be allocated (as some tones are reserved for other purposes). Similarly, in a 160 MHz channel, a maximum of 74 RUs may be allocated. Larger RUs of 52 tones, 106 tones, 242 tones, 484 tones, and 996 tones may also be allocated. For example, adjacent RUs may be separated by a null subcarrier (such as a DC subcarrier) to reduce interference between adjacent RUs, to reduce the DC offset of the receiver, and to avoid leakage of the transmit center frequency.

[0053]

[0078] For UL MU transmissions, the AP 102 may transmit trigger frames to initiate and synchronize UL MU-OFDMA or UL MU-MIMO transmissions from multiple STAs 104 to the AP 102. Such trigger frames may thus enable multiple STAs 104 to transmit UL traffic to the AP 102 simultaneously in time. The trigger frames may address one or more STAs 104 via their respective association identifiers (AIDs) and may assign to each AID (and thus each STA 104) one or more RUs that may be used to transmit UL traffic to the AP 102. The AP may also designate one or more random access (RA) RUs for which non-scheduled STAs 104 may contend.

[0054]

[0079] 5 shows a block diagram of an example wireless communication device 500. In some implementations, the wireless communication device 500 may be an example of a device for use in a STA, such as one of the STAs 104 described above with reference to FIG. 1. In some implementations, the wireless communication device 500 may be an example of a device for use in an AP, such as the AP 102 described above with reference to FIG. 1. The wireless communication device 500 is capable of transmitting (or outputting for transmission) and receiving wireless communications (e.g., in the form of wireless packets). For example, the wireless communication device 500 may be configured to transmit and receive packets in the form of Physical Layer Convergence Protocol (PLCP) Protocol Data Units (PPDUs) and Medium Access Control (MAC) Protocol Data Units (MPDUs) that conform to IEEE 802.11 standards, such as those defined by the IEEE 802.11-2016 specification or amendments thereof, including, but not limited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be.

[0055]

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

[0056]

[0081] The modem 502 may include an intelligent hardware block or device, such as, for example, an application-specific integrated circuit (ASIC), among other possible examples. The modem 502 is generally configured to implement a PHY layer. For example, the modem 502 is configured to modulate the packet and output a modulated packet to the radio 504 for transmission over a wireless medium. The modem 502 is also configured to obtain a modulated packet received by the radio 504 and demodulate the packet to provide a demodulated packet. In addition to a modulator and a demodulator, the modem 502 may further include a digital signal processing (DSP) circuit, an automatic gain control (AGC), a coder, a decoder, a multiplexer, and a demultiplexer. For example, while in a transmit mode, data obtained from the processor 506 is provided to a coder, which encodes the data to provide coded bits. The coded bits are then mapped to points in a modulation constellation (using a selected MCS) to provide modulated symbols. The modulated symbols are then N SS number of spatial streams or N STS The modulated symbols in each spatial or space-time stream may then be multiplexed and converted via an inverse fast Fourier transform (IFFT) block, followed by being provided to a DSP circuit for Tx windowing and filtering. The digital signal may then be provided to a digital-to-analog converter (DAC). The resulting analog signal may then be provided to a frequency up-converter and ultimately to the radio 504. In an implementation involving beamforming, the modulated symbols in each spatial stream are precoded via a steering matrix before being provided to the IFFT block.

[0057]

[0082] While in the receive mode, the digital signal received from the radio 504 is provided to the DSP circuitry, which is configured to obtain the received signal, for example, by detecting the presence of a signal and estimating an initial timing and frequency offset. The DSP circuitry is further configured to digitally condition the digital signal, for example, using channel (narrowband) filtering, analog impairment adjustment (such as to correct I / Q imbalance), and finally applying a digital gain to obtain a narrowband signal. The output of the DSP circuitry may then be provided to an AGC, which is configured to use information extracted from the digital signal within one or more received training fields, for example, to determine an appropriate gain. The output of the DSP circuitry is also coupled to a demodulator, which is configured to extract modulated symbols from the signal and calculate, for example, logarithm likelihood ratios (LLRs) for each bit position of each subcarrier in each spatial stream. The demodulator is coupled to a decoder, which may be configured to process the LLRs to provide decoded bits. The decoded bits from all of the spatial streams are then provided to a demultiplexer for demultiplexing. The demultiplexed bits may then be descrambled and provided to the MAC layer (processor 506) for processing, evaluation, or interpretation.

[0058]

[0083] The radio 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 RF receiver may each include various DSP circuitry including at least one power amplifier (PA) and at least one low-noise amplifier (LNA). The RF transmitter and RF receiver may then be coupled to one or more antennas. For example, in some implementations, the wireless communication device 500 may include or be coupled to multiple transmit antennas (each with a corresponding transmit chain) and multiple receive antennas (each with a corresponding receive chain). Symbols output from the modem 502 are provided to the radio 504, which then transmits the symbols via the coupled antennas. Similarly, symbols received via the antenna are captured by radio 504 , which then provides the symbols to modem 502 .

[0059]

[0084] The processor 506 may include an intelligent hardware block or device, such as, for example, a processing core, processing block, central processing unit (CPU), microprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), programmable logic device (PLD) such as field programmable gate array (FPGA), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor 506 processes information received via the radio 504 and modem 502, and processes information output via the modem 502 and radio 504 for transmission over a wireless medium. For example, the processor 506 may implement a control plane and 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, space-time block coding (STBC), beamforming, and OFDMA resource allocation, among other operations or techniques. In some implementations, the processor 506 can generally control the modem 502 to cause the modem to perform various operations described above.

[0060]

[0085] The memory 508 may include a tangible storage medium, such as a random-access memory (RAM) or a read-only memory (ROM), or a combination thereof. The memory 508 may also store non-transitory processor or computer executable software (SW) code that includes instructions that, when executed by the processor 506, cause the processor to perform various operations described herein for wireless communication, including generating, transmitting, receiving, and interpreting MPDUs, frames, or packets. For example, various functions of the components disclosed herein, or various blocks or steps of the methods, operations, processes, or algorithms disclosed herein, may be implemented as one or more modules of one or more computer programs.

[0061]

[0086] FIG. 6A illustrates a block diagram of an exemplary AP 602. For example, the AP 602 may be an exemplary implementation of the AP 102 described with reference to FIG. 1. The AP 602 includes a wireless communication device (WCD) 610. For example, the wireless communication device 610 may be an exemplary implementation of the wireless communication device 500 described with reference to FIG. 5. The AP 602 also includes multiple antennas 620 coupled to the wireless communication device 610 for transmitting and receiving wireless communications. In some implementations, the AP 602 further includes an application processor 630 coupled to the wireless communication device 610 and a memory 640 coupled to the application processor 630. The AP 602 further includes at least one external network interface 650 that enables the AP 602 to communicate with a core network or a backhaul network to gain 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 above-mentioned components may communicate directly or indirectly with some of the other components via at least one bus. The AP 602 further includes a housing that contains the wireless communication device 610, the application processor 630, the memory 640, and at least a portion of the antenna 620 and the external network interface 650.

[0062]

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

[0063]

[0088] As discussed, various aspects of the subject matter disclosed herein relate generally to P2P communications, and more particularly to ensuring that P2P communications associated with latency-sensitive applications are provided with dynamic channel access to meet the various latency, throughput, and timing requirements of such latency-sensitive applications. For example, a wireless communication device running a real-time gaming application may operate as a STA to transmit and receive gaming data to and from a gaming service via an associated AP, while also operating as a softAP to transmit and receive gaming data to and from an associated AR / VR headset. In some implementations, the wireless communication device may transmit a frame including a MAC header carrying a request for the AP to allocate a portion of a TXOP obtained over the wireless medium for P2P communications between the wireless communication device and a client device. The request may also indicate or request one or more timing and / or bandwidth parameters for the P2P communications. In some instances, the frame may be a QoS Null frame or a QoS Data frame. The AP may transmit a trigger frame that acknowledges the request and allocates a portion of the TXOP to the wireless communication device for P2P communications. The wireless communication device may receive the trigger frame and then transmit or receive P2P data to or from the client device over the wireless medium during the assigned portion of the TXOP.

[0064]

[0089] Particular implementations of the subject matter described in this disclosure may be implemented to achieve one or more of the following potential advantages: By enabling a wireless communication device running a real-time application and associated with a client device (such as an AR / VR headset) to dynamically request additional wireless resources for P2P communication with the client device, aspects of the present disclosure may ensure that the wireless communication device and its associated client device are dynamically assigned channel access to meet the various latency, throughput, and timing requirements associated with the real-time application. Also, by enabling requests to an AP to allocate portions of TXOPs obtained on the wireless medium for P2P communication to be carried within the MAC headers of frames such as QoS Null frames and QoS Data frames, aspects of the present disclosure may enable the wireless communication device to dynamically send such requests to the AP based on, for example, real-time changes in bandwidth needed to meet the various latency, throughput, and timing requirements associated with the real-time application.

[0065]

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

[0066]

[0091] In the example of FIG. 7, a first STA 710 is co-located with a first soft AP 711 associated with a first client device 712, and a second STA 720 is co-located with a second soft AP 721 associated with a second client device 722. The first soft AP 711 and the first client device 712 may establish a P2P link 713 over which P2P communications may be exchanged between the first soft AP 711 and the client device 712. The second soft AP 721 and the second client device 722 may establish a P2P link 723 over which P2P communications may be exchanged between the second soft AP 721 and the client device 722. In some cases, the P2P links 713 and 723 may be tunneled direct link setup (TDLS) links established over a wireless medium. In other cases, the P2P links 713 and 723 may be based on a Wi-Fi Direct peer-to-peer communication protocol.

[0067]

[0092] In some implementations, the first STA 710 includes separate MAC entities that can independently perform MAC layer functions for wireless communication with the AP 702 and MAC layer functions 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 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 over the wireless medium from the AP 702 and for constructing and formatting frames for transmission over the wireless medium from the first STA 710 to the AP 702. The second MAC-SAP endpoint A1 may be responsible for decoding frames and packets received over the first P2P link 713 from the client device 712 and for constructing and formatting frames for transmission over the first P2P link 713 from the first softAP 711 to the client device 712. In some cases, the MAC-SAP endpoints S1 and A1 may have different MAC addresses.

[0068]

[0093] Similarly, the second STA 720 may include a first 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 over the wireless medium from the AP 702 and may be responsible for building and formatting frames for transmission over the wireless medium from the second STA 720 to the AP 702. The second MAC-SAP endpoint A2 may be responsible for decoding frames and packets received over the second P2P link 723 from the client device 722 and may be responsible for building and formatting frames for transmission over the second P2P link 723 from the second softAP 721 to the client device 722. In some instances, the MAC-SAP endpoints S2 and A2 may have different MAC addresses.

[0069]

[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 coverage area 715 and the second coverage area 725 may not overlap with each other (as shown in the example of FIG. 7). In some other cases, the first coverage area 715 and the second coverage area 725 may overlap with each other. Although not shown for simplicity, the coverage area provided by the AP 702 may include some or all of the first coverage area 715 provided by the first soft AP 711 of the first STA 710 and may include some or all of the second coverage area 725 provided by the second soft AP 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 transmitted by AP 702, while in other cases, one or both of client devices 712 and 722 may not be able to receive and successfully decode frames transmitted by AP 702 (e.g., because client devices 712 and 722 are not within the wireless coverage area of ​​AP 702).

[0070]

[0095] The client devices 712 and 722 may be any suitable devices capable of establishing a P2P link with the respective softAPs 711 and 721. In the example of FIG. 7, the client devices 712 and 722 are associated with low-latency applications having strict end-to-end latency, throughput, and timing requirements for data traffic. In some cases, the client devices 712 and 722 may 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, the client devices 712 and 722 may be AR / VR headsets associated with the softAP 711 co-located with the first STA 710 and the softAP 721 co-located with the second STA 720, respectively. In some cases, each of the first STA 710 and the second STA 720 may be referred to as a low-latency STA. In instances where the third STA 730 is associated with latency sensitive traffic, the third STA 730 may also be referred to as a low latency STA.

[0071]

[0096] As discussed, low latency applications may specify various latency, throughput, and timing requirements of the wireless network 700, and therefore, it is desirable to ensure that the wireless network 700 can meet the various latency, throughput, and timing requirements of such low latency applications. In some implementations, each of the first STA 710 and the second STA 720 may transmit a frame including a request for the AP 702 to allocate a portion of a TXOP obtained on the wireless medium for P2P communication between the respective STA and the client device. In some instances, the request for the AP to allocate a portion of the TXOP for the P2P communication may be carried in a MAC header of the frame. The request may indicate one or more of a duration of the requested portion of the TXOP, a requested bandwidth of the P2P communication, a traffic identifier (TID) of the P2P communication, a stream classification service (SCS) identifier (SCSID) of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a delay bound of a service period associated with the P2P communication, or a requested type of trigger frame.

[0072]

[0097] After receiving the P2P request carried in the MAC header of the frame, the AP 702 can decide to accept or reject the request, and can also decide to accept, reject, or modify one or more of the parameters indicated in the request. Specifically, the AP 702 transmits a response frame to each of the first STA 710 and the second STA 720 to acknowledge receipt of their P2P requests. In some instances, the MAC header of each response frame includes an acknowledgement of the corresponding request. The MAC header of each response frame can also include a QoS control field or an aggregate control (A-control) subfield indicating one or more of the duration of the portion of the TXOP to be allocated to the P2P communication, the bandwidth to be allocated to the P2P communication, the TID of the P2P communication, the SCSID of the P2P communication, the start time of a service period associated with the P2P communication, the service interval associated with the P2P communication, the delay bound of the service period associated with the P2P communication, or the type of trigger frame requested.

[0073]

[0098] The AP 702 obtains a TXOP over the wireless medium and transmits a trigger frame to the first STA 710 and the second STA 720. The trigger frame can allocate requested portions of the TXOP to one or both of the first STA 710 and the second STA 720 for P2P communication with their respective client devices. In some instances, the AP 702 can allocate different portions of the TXOP to the first STA 710 and the second STA 720 (e.g., during different service periods associated with the P2P communication). The first STA 710 and the second STA 720 may then exchange P2P data with their respective client devices during the portions of the TXOP allocated by the AP 702 for P2P communication.

[0074]

[0099] 8 illustrates a timing diagram illustrating an example wireless communication 800 supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic, according to some implementations. The timing diagram is shown to include an AP, a STA, and a client device. In some implementations, the AP may be an example of the AP 702 of FIG. 7, the STA may be an example of the first STA 710 or the second STA 720 of FIG. 7, and the client device may be an example of the client devices 712 and 722 of FIG. 7, respectively. In some other implementations, the AP may be an example of the AP 102 of FIG. 1 or the AP 602 of FIG. 6A, respectively, and the STA may be an example of the STA 104 of FIG. 1 or the STA 604 of FIG. 6B, respectively. Although only one STA and one client device are shown in the example of FIG. 8, in an actual implementation, a BSS operated by an AP may include any suitable number of STAs, and one or more of the STAs may include or implement a softAP capable of exchanging latency-sensitive P2P communications with one or more associated client devices.

[0075]

[0100] As discussed with reference to FIG. 7, the STA implements or operates a softAP that is associated with an AP and with which client devices are associated via a P2P link 810. In some cases, the STA may include two MAC-SAP endpoints S1 and A1 (not shown in FIG. 8 for simplicity). The first MAC-SAP endpoint S1 may be responsible for decoding frames and packets received over the wireless medium from the AP and for building and formatting frames for transmission over the wireless medium from the STA to the AP. The second MAC-SAP endpoint A1 may be responsible for decoding frames and packets received over the P2P link 810 from client devices and for building and formatting frames for transmission over the P2P link 810 from the softAP to the client devices. In some cases, the MAC-SAP endpoints of the STAs may have different MAC addresses.

[0076]

[0101] In some implementations, the STA may be associated with low-latency applications having strict end-to-end latency, throughput, and timing requirements for data traffic. Exemplary 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). In some instances, the STA may utilize peer-to-peer (P2P) communications to exchange latency-sensitive traffic with a client device (which may be an AR / VR headset). For example, in some aspects, the STA executes a real-time gaming application that transmits and receives gaming data to and from a gaming service via an associated AP, while also operating as a softAP that transmits and receives gaming data to and from an associated AR / VR headset via a P2P link. The P2P communications between the STA (or softAP) and the AR / VR headset may be subject to latency, throughput, and timing requirements associated with the real-time gaming application. Similarly, the gaming data transmitted between the STA and the AP may also be subject to latency, throughput, and timing requirements associated with the real-time gaming application.

[0077]

[0102] Prior to time t0, the STA may determine that additional wireless resources are needed. For example, while executing a real-time gaming application, the STA may manage or at least monitor downlink (DL) transmissions from the AP to the STA and associated P2P transmissions from the STA to the client device, and may manage or at least monitor P2P transmissions from the client device to the STA and associated uplink (UL) transmissions from the STA to the AP. Thus, the STA may be able to determine when additional wireless resources are needed to meet various latency, throughput, and timing requirements associated with the real-time gaming application, and more specifically, may be able to dynamically request additional wireless resources for latency-sensitive communications associated with the real-time gaming application.

[0078]

[0103] At time t0, the STA transmits a frame over the wireless medium to the AP, including a MAC header carrying a request (REQ) for the AP to allocate a portion of the TXOP obtained on the wireless medium for P2P communication between the STA and the client device. The frame may be a QoS Null frame, a QoS Data frame, a PS Poll frame, or any other suitable frame including a MAC header in which a request may be sent to the AP. The request carried in the MAC header of the frame may indicate one or more of a duration of the requested portion of the TXOP, a requested bandwidth of the P2P communication, a TID of the P2P communication, a SCSID of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame.

[0079]

[0104] In some implementations, the request may be carried within a QoS control field of the MAC header of the frame. In some cases, the MAC header may include an indication that the frame should be interpreted as a P2P request frame carrying a request for the AP to send a MU-RTS TXS trigger frame that allocates a portion of the TXOP of the P2P communication to the STA. For example, the QoS control field may include a reserved bit set to a value indicating that the frame is a P2P request frame, a TID subfield set to a value indicating that the frame is a P2P request frame (the value is 8 or greater), or an ACK policy indicator subfield set to a value indicating that the frame is a P2P request frame.

[0080]

[0105] In some instances, the QoS Control field may include an EOSP subfield preceding the ACK Policy Indicator subfield and a TXOP Duration Requested subfield following the Reserved bit. The TXOP Duration Requested subfield, which may correspond to the last octet of the QoS Control field, may carry or indicate one or more of the duration of the requested portion of the TXOP, the queue size of the STA, or the TXOP shared mode bandwidth based on the value carried in the EOSP subfield and the Reserved bit. For example, setting the Reserved bit to 1 and the EOSP subfield to 0 may signal that the TXOP Duration Requested subfield carries or indicates the duration of the requested portion of the TXOP and that the ACK Policy Indicator subfield carries or indicates the TXOP shared mode bandwidth, and setting the Reserved bit to 1 and the EOSP subfield to 1 may signal that the TXOP Duration Requested subfield carries or indicates both the TXOP shared mode bandwidth and the duration of the requested portion of the TXOP. In another example, setting the reserved bit to 0 and the EOSP subfield to 0 can signal that the TXOP Duration Request subfield carries or indicates the duration of the requested portion of the TXOP, and setting the reserved bit to 0 and the EOSP subfield to 1 can signal that the TXOP Duration Request subfield carries or indicates the queue size of the STA.

[0081]

[0106] In some other implementations, the request may be carried in an A-Control subfield of the MAC header of the frame. The A-Control subfield, which may be a HE variant HT Control field, may include a Control ID subfield and a Control Information subfield. In some instances, the Control ID subfield is set to a reserved value indicating that the frame is a P2P request frame, and the Control Information subfield carries or indicates various parameters associated with the P2P communication. For example, in some aspects, the reserved value carried in the Control ID subfield may be one of 9, 11, 12, 13, or 14. As discussed, the various parameters may include one or more of a duration of a requested portion of a TXOP, a requested bandwidth of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a requested type of a trigger frame requesting the P2P communication, a TID of the P2P communication, a SCSID of the P2P communication, a user priority of a traffic flow associated with the P2P communication, a queue size of the STA, or a delay bound of a service period associated with the P2P communication.

[0082]

[0107] In some other cases, the control information subfield may include a Buffer Status Report (BSR) Control subfield indicating that the frame is a P2P request frame and carrying the duration of the requested portion of the TXOP and the requested bandwidth of the TXOP sharing mode. For example, in some aspects, the BSR Control subfield may include a Delta TID subfield, a Queue Size High subfield, and a Queue Size All subfield. The Delta TID subfield may be set to a value indicating that the frame is a P2P request frame, and the Queue Size High and Queue Size All subfields may carry values ​​collectively indicating the duration of the requested portion of the TXOP and the requested bandwidth of the TXOP sharing mode.

[0083]

[0108] In some implementations, the frame may be a TWT request frame that includes a TWT element indicating a MAC address of the client device and one or more TWT parameters of a restricted TWT (r-TWT) Service Period (SP) associated with the P2P communication. In some other implementations, the frame may be an SCS request frame that includes a TSPEC element indicating a MAC address of the client device and one or more parameters of an r-TWT SP associated with the P2P communication.

[0084]

[0109] The AP receives the frame carrying the request and acknowledges receipt of the request by sending a response frame (RESP) to the STA at time t1. In some implementations, the response frame includes a MAC header carrying the acknowledgement of the request. In some instances, the MAC header of the response frame may include a QoS control field or an A-control subfield indicating one or more of the duration of the portion of the TXOP to be allocated to the P2P communication, the bandwidth allocated to the P2P communication, the TID of the P2P communication, the SCSID of the P2P communication, the start time of a service period associated with the P2P communication, the service interval associated with the P2P communication, or the delay bound of the service period, the type of trigger frame requested. In some aspects, the response frame may be a QoS data frame or a block acknowledgement (BA) frame.

[0085]

[0110] Between times t2 and t3, the AP senses that the wireless medium is idle for a period of time based on a channel sensing operation (such as a clear channel assessment (CCA)) before attempting to acquire a TXOP on the wireless medium. In some instances, the AP may sense that the wireless medium is idle for a PIFS period before attempting to gain channel access (such that the time period between times t2 and t3 is a PIFS period). At time t3, the AP senses that the wireless medium is still idle and proceeds to acquire a TXOP, e.g., by starting transmission over the wireless medium. Specifically, the AP transmits a trigger frame that allocates a requested portion of the TXOP to the STA for P2P communication. In some aspects, the trigger frame includes a duration field (in the MAC header) that may be used to protect latency-sensitive traffic.

[0086]

[0111] In some implementations, the trigger frame may be an MU-RTS TXS trigger frame that includes a TXOP sharing mode subfield that indicates a TXOP sharing mode of P2P communication between the STA and the client device. The MU-RTS TXS trigger frame may include the MAC address or AID of the STA, for example, the MAC address of the client device, such that the client device does not set its NAV for the time period indicated in the duration field of the trigger frame, but instead remains awake to receive management and / or control frames from the softAP (or STA). In some other implementations, other suitable types of trigger frames may be used by the AP to allocate the requested portion of the TXOP for P2P communication between the softAP (or STA) and the client device.

[0087]

[0112] The STA receives the trigger frame between times t3 and t4 and determines a portion of the TXOP allocated to the STA for P2P communication with the client device. At time t4, the STA acknowledges receipt of the MU-RTS TXS trigger frame by sending a CTS frame to the AP. In some instances, the CTS frame identifies the softAP and the client device, for example, to prevent the STA and the client device from setting their respective NAVs to the time period indicated in the duration field of the CTS frame.

[0088]

[0113] Between times t5 and t6, the softAP (or STA) transmits P2P data to the client device using a P2P link 810. In some cases, the P2P link 810 may be established using a Wi-Fi tunneled direct link setup (TDLS). In other cases, the P2P link 810 may be a Wi-Fi Direct connection. In some other cases, the STA or softAP may be a group owner (GO) and may coordinate P2P transmissions to and from the client device. The client device receives the P2P data and acknowledges its receipt by sending an ACK frame to the softAP (or STA) at time t7.

[0089]

[0114] At time t8, the softAP (or STA) transmits a trigger frame to the client device over the P2P link 810. The trigger frame, which may be a basic trigger frame, requests queued P2P data from the client device. The client device receives the trigger frame and responds by transmitting a trigger signal at times t9 and t 10 The softAP (or STA) transmits P2P data to the softAP (or STA) using a P2P link 810 between the softAP and the STA. The softAP (or STA) receives the P2P data and transmits the P2P data to the softAP (or STA) at time t 11 The client device acknowledges its receipt by sending an ACK frame to the client device at time t 12At , the time period T1 corresponding to the allocated portion of the TXOP expires and the AP can reclaim the remaining TXOP.

[0090]

[0115] 9 shows a flowchart illustrating an example process 900 of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic according to some implementations. Process 900 may be performed by a wireless communication device, such as the wireless communication device 500 described above with reference to FIG. 5. In some instances, process 900 may be performed by a wireless communication device operating as or within a STA, such as one of the STAs 102 and 604 described above with reference to FIG. 1 and FIG. 6B, respectively.

[0091]

[0116] In some implementations, the process 900 begins at block 902 with transmitting a frame to an access point (AP) over a wireless medium, the frame including a medium access control (MAC) header carrying a request to the AP to allocate a portion of a transmission opportunity (TXOP) for peer-to-peer (P2P) communication between the wireless communication device and the client device. At block 904, the process 900 continues with receiving a trigger frame from the AP over the wireless medium, the trigger frame allocating the portion of the TXOP to the wireless communication device for P2P communication. At block 906, the process 900 continues with transmitting or receiving P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP. In some instances, the request indicates one or more of a duration of a requested portion of the TXOP, a requested bandwidth of the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval for the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame.

[0092]

[0117] In some implementations, the MAC header of the frame includes a QoS control field carrying the request. In some cases, the QoS control field includes a reserved bit set to a value indicating that the frame is a P2P request frame, a TID subfield with a value of 8 or greater set to a value indicating that the frame is a P2P request frame, or an ACK policy indicator subfield set to a value indicating that the frame is a P2P request frame. In some other cases, the QoS control field includes an EOSP subfield, an ACK policy indicator subfield following the EOSP subfield, a reserved bit following the ACK policy indicator subfield, and an octet following the reserved bit. The octet, which may correspond to the TXOP duration request subfield, indicates one or more of a duration of the requested portion of the TXOP, a queue size of the wireless communication device, or a TXOP shared mode bandwidth based on the value and the reserved bit carried in the EOSP subfield. For example, setting the reserved bit to 1 and the EOSP subfield to 0 may signal that the octet indicates a duration of the requested portion of the TXOP and the ACK policy indicator subfield indicates the TXOP shared mode bandwidth, and setting the reserved bit to 1 and the EOSP subfield to 1 may signal that the octet indicates both the TXOP shared mode bandwidth and the duration of the requested portion of the TXOP. In another example, setting the reserved bit to 0 and the EOSP subfield to 0 may signal that the octet indicates a duration of the requested portion of the TXOP, and setting the reserved bit to 0 and the EOSP subfield to 1 may signal that the octet indicates a queue size of the wireless communications device.

[0093]

[0118] In some other implementations, the MAC header of the frame may include a HE variant HT control field including an A control subfield carrying a P2P request. In some cases, the A control subfield includes a Control ID subfield set to a reserved value indicating that the frame is a P2P request frame and includes a Control Information subfield carrying parameters associated with the P2P communication between the wireless communication device and the client device. For example, in some aspects, the reserved value carried in the Control ID subfield may be one of 9, 11, 12, 13, or 14. In some other cases, the parameters associated with the P2P communication may indicate one or more of a duration of a requested portion of a TXOP, a requested bandwidth of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval of the P2P communication, a requested type of trigger frame requesting the P2P communication, a user priority of a traffic flow associated with the P2P communication, a queue size of the wireless communication device, or a delay bound associated with the service period.

[0094]

[0119] In some cases, the frame may be a TWT request frame that includes a TWT element indicating a MAC address of the client device and one or more TWT parameters that may be used during one or more service periods associated with the P2P communication between the wireless communication device and the client device. In some other cases, the frame may be an SCS request frame that includes a TSPEC element indicating a MAC address of the client device and one or more parameters of the service period associated with the P2P communication.

[0095]

[0120] In various implementations, the trigger frame may be an MU-RTS TXS trigger frame that includes a TXOP sharing mode subfield that indicates a TXOP sharing mode of the P2P communication between the wireless communication device and the client device. In some instances, the trigger frame identifies the wireless communication device and the client device.

[0096]

[0121] In some other implementations, the wireless communication device may include a co-located softAP that manages P2P communications between the wireless communication device and client devices. In some instances, the softAP may have a different MAC address than the wireless communication device. For example, the wireless communication device may include a separate MAC entity that can communicate independently with the AP and the client device. In some aspects, the wireless communication device may include a first MAC-SAP endpoint responsible for non-AP STA communications with the AP and a second MAC-SAP endpoint responsible for P2P communications between the softAP and the client devices.

[0097]

[0122] 10 shows a flowchart illustrating an example process 1000 of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic according to some other implementations. Process 1000 may be performed by a wireless communication device such as wireless communication device 500 described above with reference to FIG. 5. In some implementations, process 1000 may be performed by a wireless communication device operating as or within a STA such as one of the STAs 104 or 604 described above with reference to FIG. 1 and FIG. 6B, respectively.

[0098]

[0123] In some implementations, the process 1000 may be performed after transmitting a frame carrying a request at block 902 of the process 900 of FIG. 9. For example, the process 1000 begins at block 1002 with receiving a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request. The response frame may be any suitable frame capable of indicating whether the AP has accepted, rejected, or modified one or more P2P parameters requested or indicated by the wireless communication device. In some instances, the response frame may be a TWT response frame carrying the MAC address of the client device and including a TWT element indicating a set of TWT parameters to be used for P2P communications during the assigned portion of the TXOP shared by the AP. In some other instances, the response frame may be an SCS response frame carrying the MAC address of the client device and including a TSPEC element indicating various QoS parameters, data rate, access category, and user priority of the P2P link associated with the BSS.

[0099]

[0124] In some implementations, the MAC header of the response frame includes a QoS control field or A-control subfield indicating one or more of the duration of the requested portion of the TXOP, the bandwidth to be allocated to the P2P communication, the TID associated with the P2P communication, the SCSID associated with the P2P communication, the start time of a service period associated with the P2P communication, the service interval associated with the P2P communication, the delay bound of the service period associated with the P2P communication, or the requested type of trigger frame. In some cases, the response frame may be a QoS data frame. In some other cases, the response frame may be a block acknowledgement (BA) frame.

[0100]

[0125] 11 shows a flowchart illustrating an example process 1100 of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic according to some other implementations. Process 1100 may be performed by a wireless communication device such as the wireless communication device 500 described above with reference to FIG. 5. In some implementations, process 1100 may be performed by a wireless communication device operating as or within a STA such as one of the STAs 104 or 604 described above with reference to FIG. 1 and FIG. 6B, respectively.

[0101]

[0126] In some cases, the process 1100 may be an implementation of transmitting or receiving P2P data in block 906 of FIG. 9. For example, in block 1102, the process 1100 begins with transmitting latency-sensitive traffic to a client device over a wireless medium based on receiving a trigger frame from an AP. In block 1104, the process 1100 continues with transmitting a P2P trigger frame to the client device over a wireless medium after transmitting the latency-sensitive traffic to the client device. In block 1106, the process 1100 continues with receiving latency-sensitive traffic from the client device over a wireless medium based on the P2P trigger frame. In some cases, the P2P communication may be received over a tunneled direct link setup (TDLS) link established between the STA and the client device. In some other cases, the P2P communication may be exchanged between the STA and the client device based on a Wi-Fi Direct peer-to-peer communication protocol.

[0102]

[0127] 12 shows a flowchart illustrating an example process 1200 of wireless communication supporting a request to allocate wireless medium resources for latency-sensitive P2P traffic according to some other implementations. Process 1200 may be performed by a wireless communication device such as the wireless communication device 500 described above with reference to FIG. 5. In some implementations, process 1200 may be performed by a wireless communication device operating as or within a STA such as one of the STAs 104 or 604 described above with reference to FIG. 1 and FIG. 6B, respectively.

[0103]

[0128] In some cases, the process 1200 may be implemented with the process 900 of FIG. 9. For example, in block 1202, the process 1200 begins with operating a wireless communication device as a wireless station (STA) associated with an AP and simultaneously operating the wireless communication device as a softAP with which a client device is associated. As discussed, in some cases, the wireless communication device may include two MAC-SAP endpoints S1 and A1. Specifically, the first MAC-SAP endpoint S1 may be responsible for decoding frames and packets received over the wireless medium from the AP and may be responsible for constructing and formatting frames for transmission over the wireless medium from the wireless communication device to the AP. The second MAC-SAP endpoint A1 may be responsible for decoding frames and packets received over a P2P link from a client device and may be responsible for constructing and formatting frames for transmission over a P2P link from the softAP to the client device.

[0104]

[0129] 13 illustrates an example configuration of a MAC header 1300 usable for wireless communications according to some implementations. The MAC header 1300 may include a Frame Control field 1301, a Duration / ID field 1302, an Address 1 field 1303, an Address 2 field 1304, an Address 3 field 1305, a Sequence Control field 1306, an Address 4 field 1307, a QoS Control field 1308, an HT Control field 1309, a Frame Body 1310, and an FCS field 1311. In some other implementations, the MAC header 1300 may include other, fewer, or more fields.

[0105]

[0130] The frame control field 1301 may indicate a type or function of the corresponding frame that includes the MAC header 1300. For example, the frame control field 1301 may identify the corresponding frame that includes the MAC header 1300 as a particular type of frame (such as a beacon frame or a P2P request frame). The duration / ID field 1302 may indicate the duration of the corresponding frame in milliseconds. The address 1 field 1303 may indicate a destination address of the corresponding frame. In some instances, the address 1 field 1303 may include a broadcast address or a multicast address, for example, if the corresponding frame is intended for multiple wireless communication devices.

[0106]

[0131] The Address 2 field 1304 may indicate a source address of the corresponding frame. For example, the Address 2 field 1304 may include a MAC address of the wireless device that transmitted the corresponding frame. The Address 3 field 1305 may include a BSSID. In some aspects, the BSSID may be the MAC address of the wireless device that transmitted the corresponding frame. The Sequence Control field 1306 includes a sequence number and a fragment number. The sequence number identifies the corresponding MAC frame (e.g., MSDU or A-MSDU), and the fragment number indicates the number of each fragment of the MSDU. The Address 4 field 1307 is optional and may indicate a forwarding address when the corresponding frame is transmitted over the mesh network.

[0107]

[0132] The QoS control field 1308 may include five or eight subfields (depending on the frame type and the capabilities of the transmitting device) and may carry a value indicating the traffic class or traffic stream to which the corresponding frame belongs. The QoS control field 1308 may also indicate other QoS information for the corresponding frame, including (but not limited to) buffer size, queue size, duration of the requested portion of the TXOP, TXOP limits, etc.

[0108]

[0133] The HT control field 1309 may have three variants including an HT variant, a VHT variant, and an HE variant. For example, the HT and VHT variants include a Control Middle subfield, an AC Constraint subfield, and an additional PPDU subfield, while the HE variant includes an A-Control subfield. The frame body 1310 carries data embodied as one or more MSDUs or MDPUs. The FCS field 1311 may include an error detection code that allows for error detection of data within the corresponding frame.

[0109]

[0134] Figure 14A shows a table 1400 describing the content and bit assignments of the QoS control field 1309 of Figure 13 for a number of different frame types and subtypes. Table 1400 is applicable to the IEEE 802.11ax (and subsequent) amendments to the IEEE 802.11 family of wireless communications standards.

[0110]

[0135] 14B illustrates an example QoS control field 1410 that may be used for wireless communications to support requests to allocate wireless medium resources for latency-sensitive P2P traffic, according to some implementations. The QoS control field 1410 is shown to include a TID subfield 1411, an EOSP subfield 1412, an ACK policy indicator subfield 1413, a reserved bit 1414, and a TXOP duration request subfield 1415. In some instances, the TID subfield 1411 includes 4 bits occupying bit positions 0 through 3 of the QoS control field 1410, the EOSP subfield 1412 includes 1 bit occupying bit position 4 of the QoS control field 1410, the ACK policy indicator subfield 1413 includes 2 bits occupying bit positions 5 through 6 of the QoS control field 1410, the reserved bit 1414 includes 1 bit occupying bit position 7 of the QoS control field 1410, and the TXOP duration request subfield 1415 includes 8 bits (e.g., an octet) occupying bit positions 8 through 15 of the QoS control field 1410.

[0111]

[0136] The TID subfield 1411 identifies the traffic class (TC) or traffic stream (TS) to which the corresponding frame belongs. The TID subfield 1411 may also identify the TC or TS of traffic for which a TXOP is being requested, for example, by the value of the TXOP duration request subfield 1415 or queue size. The EOSP subfield 1412 may indicate the end of the current service period. The ACK policy indicator subfield 1413 identifies the ACK policy to be used by the receiving device to acknowledge receipt of the corresponding frame. The TXOP duration request subfield 1415 indicates the duration, in 32 μs units, that the transmitting STA requires for its next TXOP for the specified TID. In some aspects, the TXOP duration request subfield is set to 0 to indicate that no TXOP is requested for the specified TID within the current service period, and is set to a non-zero value to indicate a requested TXOP duration within the range of 32 μs to 8160 μs (in increments of 32 μs).

[0112]

[0137] In some implementations, the QoS control field 1410 may be used to carry a request in the MAC header of a frame transmitted from the STA to the AP. As discussed, the request may be to allocate a portion of the TXOP obtained by the AP for P2P communication between a softAP implemented by or colocated with the STA and a client device associated with the softAP. In some cases, the reserved bit 1414 in the QoS control field 1410 may be set to a value indicating that the frame is a P2P request frame. In other cases, setting the TID subfield 1411 in the QoS control field 1410 to a value of 8 or greater indicates that the frame is a P2P request frame. In some other cases, the ACK policy indicator subfield 1413 may be set to a value indicating that the frame is a P2P request frame.

[0113]

[0138] In some implementations, the content of the TXOP duration request subfield 1415 may be determined by the values ​​carried in the EOSP subfield 1412 and the reserved bit 1414. For example, setting the reserved bit 1414 to 1 and the EOSP subfield 1412 to 0 may signal that the TXOP duration request subfield 1415 indicates the duration of the requested portion of the TXOP and may also signal that the ACK policy indicator subfield 1413 indicates the TXOP shared mode bandwidth. Setting the reserved bit 1414 to 1 and the EOSP subfield 1412 to 1 may signal that the TXOP duration request subfield 1415 indicates both the TXOP shared mode bandwidth and the duration of the requested portion of the TXOP. In another example, setting the reserved bit 1414 to 0 and the EOSP subfield 1412 to 0 can signal that the TXOP duration request subfield 1415 indicates the duration of the requested portion of the TXOP, and setting the reserved bit 1414 to 0 while setting the EOSP subfield 1412 to 1 can signal that the TXOP duration request subfield 1415 indicates a queue size of the wireless communication device.

[0114]

[0139] FIG. 15 illustrates an example configuration of an A-control subfield 1500 usable for wireless communication, according to some implementations. The A-control subfield 1500 includes a Control List field 1501 and padding 1502. The padding 1502, if present, follows the last control subfield and is set to a sequence of zeros such that the length of the A-control subfield 1500 is 30 bits. The Control List field 1501 includes a Control ID subfield 1511 and a Control Information subfield 1512. The Control ID subfield 1511 indicates the type of information carried in the Control Information subfield 1512. The length of the Control Information subfield 1512 is fixed for each value of the Control ID subfield 1511 that is not reserved.

[0115]

[0140] The control information subfield 1512 may include an ID value subfield 1521, a TXOP duration request subfield 1522, a Bandwidth subfield 1523, a Service Start Time subfield 1524, a Service Interval subfield 1525, a TXS Type subfield 1526, a TID subfield 1527, a Head-of-Line (HOL) Delay subfield 1528, and a Buffer / Queue Size subfield 1529. The ID value subfield 1521 may indicate the type or content of information carried in the control information subfield 1512. The TXOP duration request subfield 1522 indicates a requested duration of a portion of the TXOP to be assigned to or shared with the wireless communication device that transmitted the frame carrying the A-control subfield 1500. The bandwidth subfield 1523 indicates the bandwidth or channel width requested for P2P communication associated with the TXOP sharing mode. The service start time subfield 1524 specifies the time in microseconds when the first scheduled service period starts. The service interval subfield 1525 specifies the time in microseconds between scheduled service periods. The TXS type subfield 1526 indicates the type of trigger frame requested. The TID subfield 1527 indicates the traffic class or traffic stream to which the corresponding frame belongs. The HOL delay subfield 1528 indicates a delay bound for a head-of-line packet after which the packet may be dropped. In some cases, the delay bound may be determined based on the TSF value of the AP. In some other cases, the delay bound may be determined based on the packet transmission time. The buffer / queue size subfield 1529 indicates the size in bytes of the buffer with the HOL delay (delay bound) for the corresponding TID.

[0116]

[0141] 16 illustrates an example configuration of an A-control subfield 1600 usable for wireless communication according to some other implementations. The A-control subfield 1600 includes a control list field 1601 and padding 1602. The padding 1602, if present, follows the last control subfield and is set to a sequence of zeros such that the length of the A-control subfield 1600 is 30 bits. The control list field 1601 includes a control ID subfield 1611 and a control information subfield 1612. The control ID subfield 1611 indicates the type of information carried in the control information subfield 1612. The length of the control information subfield 1612 is fixed for each value of the unreserved control ID subfield 1611.

[0117]

[0142] The control information subfield 1612 may include a Buffer Status Reporting (BSR) Control subfield 1620, which includes an Access Category Indicator (ACI) Bitmap subfield 1621, a Delta TID subfield 1622, an ACI High subfield 1623, a Scaling Factor subfield 1624, a Queue Size High subfield 1625, and a Queue Size All subfield 1626. The ACI Bitmap subfield 1621 indicates the access category for which the buffer status is being reported. The Delta TID subfield 1622 indicates the number of TIDs for which the STA is reporting buffer status along with the value of the ACI Bitmap subfield 1621. The ACI High subfield 1623 indicates the ACI for the access category for which the buffer status report is indicated in the Queue Size High subfield 1625. The Scaling Factor subfield 1624 indicates the units SF, in octets, of the Queue Size High subfield 1625 and the Queue Size All subfield 1626. The Queue Size High subfield 1625 indicates the amount of buffered traffic for the access category identified by the ACI High subfield 1625, for the STA identified by the receiver address of the frame that includes the BSR Control subfield 1620. The Queue Size All subfield 1626 indicates the amount of buffered traffic for all access categories identified by the ACI Bitmap subfield 1621, for the STA identified by the receiver address of the frame that includes the BSR Control subfield 1620.

[0118]

[0143] In some implementations, the BSR control subfield 1620 may be used to indicate that the corresponding frame includes a request to the AP to allocate a portion of a TXOP for P2P communication between the transmitting device and a client device associated with the transmitting device. In some instances, the delta TID subfield 1622 is set to a reserved value indicating that the corresponding frame is a P2P request frame, and the queue size high subfield 1625 and the queue size all subfield 1626 carry values ​​that collectively indicate the duration of the requested portion of the TXOP and the requested TXOP shared mode bandwidth.

[0119]

[0144] 17A illustrates an example configuration of a TWT element 1700 usable for wireless communication, according to some implementations. The TWT element 1700 may include an element ID field 1702, a length field 1704, a control field 1706, and a TWT parameter information field 1708. The element ID field 1702 indicates that the element is a TWT element. The length field 1704 indicates the length of the TWT element 1700. The control field 1706 includes various control information for the restricted TWT session advertised by the TWT element 1700. The TWT parameter information field 1708 includes either a single individual TWT parameter set field or one or more broadcast TWT parameter set fields.

[0120]

[0145] FIG. 17B illustrates an example configuration of a Broadcast TWT Parameter Set field 1710 available for wireless communication according to some implementations. In some instances, the Broadcast TWT Parameter Set field 1710 may be included within the TWT Parameter Information field 1708 of FIG. 17A. The Broadcast TWT Parameter Set field 1710 may include a Request Type field 1712, a Target Wake Time field 1714, a Nominal Minimum TWT Wake Duration field 1716, a TWT Wake Interval Mantissa field 1717, and a Broadcast TWT Info field 1718. The Request Type field 1712 indicates the type of TWT session being requested. The Target Wake Time field 1714 carries an unsigned integer corresponding to the TSF time at which the STA requests to wake up. The nominal minimum TWT wake duration field 1716 indicates the minimum amount of time a TWT requesting or TWT scheduled STA is expected to remain in an awake state or mode. The TWT wake interval mantissa field 1717 may be set to a non-zero value for periodic TWTs and may be set to a zero value for non-periodic TWTs. The broadcast TWT information field 1718 may contain the broadcast TWT ID of the corresponding restricted TWT session and may convey information indicating the number of TBTTs during which the broadcast TWT SP corresponding to the broadcast TWT parameter set exists.

[0121]

[0146] 17C illustrates an example configuration of a Request Type field 1720 of a Broadcast TWT Parameter Set field usable for wireless communication according to some implementations. In some instances, the Request Type field 1720 may be an example of the Request Type field 1712 of FIG. 17B. The Request Type field 1720 may include a TWT Request subfield 1722, a TWT setup command subfield 1724, a trigger subfield 1726, a Last Broadcast Parameter Set subfield 1728, a Flow Type subfield 1730, a Broadcast TWT Recommendation subfield 1732, a TWT Wake Interval Exponent subfield 1734, and a Number of Reserved Bits 1736. The TWT Request subfield 1722 may carry a value indicating whether the corresponding TWT information element was sent by a scheduled STA or a scheduling STA. The TWT Setup Command subfield 1724 may carry a value indicating the type of TWT command carried in the TWT information element. The Trigger subfield 1726 may indicate whether the TWT SP indicated by the TWT element 1700 includes a trigger frame or a frame carrying a TRS Control subfield.

[0122]

[0147] The Last Broadcast Parameter Set subfield 1728 indicates whether another broadcast TWT parameter set follows. For example, the Last Broadcast Parameter Set subfield 1728 may be set to a value of 0 to indicate that there is another TWT parameter set after this set, or may be set to a value of 1 to indicate that this is the last broadcast TWT parameter set in the broadcast TWT element. The Flow Type subfield 1730 indicates the type of interaction between the TWT requesting STA or TWT scheduled STA and the TWT responding STA or TWT scheduling AP in the TWT. For example, setting the Flow Type subfield 1730 to a value of 0 indicates an announced TWT, in which the TWT requesting STA or TWT scheduled STA sends a PS-Poll or APSD trigger frame to signal its awake state. Setting the Flow Type subfield 1730 to a value of 1 indicates an unannounced TWT, in which the TWT responding STA or TWT scheduling AP will send a frame to the TWT requesting STA or TWT scheduled STA in the TWT without waiting to receive a PS-Poll or APSD trigger frame.

[0123]

[0148] The Broadcast TWT Recommendation subfield 1732 includes a value indicating a recommendation regarding the type of frames to be transmitted by the TWT scheduled STAs and the scheduling AP during the Broadcast TWT SP, encoded according to the Broadcast TWT Recommendation subfield 1732 of the Broadcast TWT element. In some cases, the Broadcast TWT Recommendation subfield 1732 may indicate whether the restricted TWT session is a peer-to-peer TWT session or a broadcast TWT session. The TWT wake interval index subfield 1734 carries a value from which the TWT wake interval may be derived. In some cases, the TWT wake interval index subfield 1734 is set to the exponent value of the TWT wake interval value in microseconds, base 2.

[0124]

[0149] 18 illustrates an example configuration of a traffic specification (TSPEC) element 1800 usable for wireless communications according to some implementations. Among other fields, the TSPEC element 1800 may include an element ID field 1801, a length field 1802, a traffic stream (TS) info field 1803, a minimum service interval field 1804, a maximum service interval field 1805, a minimum data rate field 1806, a mean data rate field 1807, and a delay bound field 1808. In some implementations, all fields other than the element ID field 1801, the length field 1802, the TS info field 1803, the minimum service interval field 1804, the maximum service interval field 1805, the minimum data rate field 1806, the mean data rate field 1807, and the delay bound field 1808 may be omitted.

[0125]

[0150] The element ID field 1801 may indicate that the element 1800 is a TSPEC element. In some cases, the element ID field 1801 may indicate that the element 1800 is a reduced TSPEC element that includes only the element ID field 1801, the length field 1802, the TS information field 1803, the minimum service interval field 1804, the maximum service interval field 1805, the minimum data rate field 1806, the average data rate field 1807, and the delay bound field 1808. The length field 1802 may indicate the length of the TSPEC element 1800. The Ts information field 1803 may include a user priority (UP) for the corresponding service period. The minimum service interval field 1804 may indicate a minimum allowed service interval between corresponding service periods. The maximum service interval field 1805 may indicate a maximum allowed service interval between corresponding service periods. The minimum data rate field 1806 may include a minimum data rate for the corresponding service period. The average data rate field 1807 may include an average data rate for the corresponding service period. The delay bound field 1808 may include a delay bound for the corresponding service period.

[0126]

[0151] In some implementations, the TSPEC element 1800 may be used to indicate that the corresponding frame includes a request to the AP to allocate a portion of the TXOP for P2P communication between the transmitting device and a client device associated with the transmitting device.

[0127]

[0152] FIG. 19 illustrates a block diagram of an example wireless communication device 1900. In some implementations, the wireless communication device 1900 may be configured to perform one or more of the processes 900, 1000, 1100, or 1200 described above with reference to FIG. 9, FIG. 10, FIG. 11, and FIG. 12, respectively. The wireless communication device 1900 may be an example implementation of any of the STA 104 of FIG. 1, the wireless communication device 500 of FIG. 5, or the STA 604 of FIG. 6B. More specifically, the wireless communication device 1900 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).

[0128]

[0153] The wireless communication device 1900 includes a receiving component 1910, a communications manager 1920, and a transmitting component 1930. The communications manager 1920 further includes a softAP management component 1922 and a P2P communications component 1924. One or more portions of the components 1922 or 1924 may be implemented at least partially in hardware or firmware. In some implementations, one or more of the components 1922 or 1924 are implemented at least partially as software stored in a memory (such as memory 508 of FIG. 5). For example, one or more portions of the components 1922 or 1924 may be implemented as non-transitory instructions (or “code”) executable by a processor (such as processor 506 of FIG. 5) to perform the functions or operations of the respective components.

[0129]

[0154] The receiving component 1910 is configured to receive RX signals from one or more other wireless communication devices, and the transmitting component 1930 is configured to transmit TX signals to one or more other wireless communication devices. The communications manager 1920 is configured to manage wireless communications with one or more other wireless communication devices. In some implementations, the softAP management component 1922 may implement or manage a softAP co-located or otherwise associated with the wireless communication device 1900. The P2P communications component 1924 may request an AP to allocate a portion of a TXOP obtained on the wireless medium for P2P communications between the wireless communication device 1900 and a client device associated with the wireless communication device 1900. The P2P communications component 1924 may also transmit a trigger frame to a client device to solicit a P2P transmission from the client device.

[0130]

[0155] The following numbered clauses describe example implementations. 1. A method of wireless communication by a wireless communication device, comprising: transmitting a frame to an access point (AP) over a wireless medium, the frame including a medium access control (MAC) header carrying a request to the AP to allocate a portion of a transmission opportunity (TXOP) obtained on the wireless medium for peer-to-peer (P2P) communication between the wireless communication device and a client device; receiving a trigger frame from an AP over a wireless medium, the trigger frame allocating a portion of a TXOP to a wireless communication device for P2P communication; transmitting or receiving P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP; A method comprising: 2. The method of claim 1, wherein the request indicates one or more of a duration of a requested portion of the TXOP, a requested bandwidth for the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval for the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame. 3. The method of any one or both of clauses 1-2, wherein the MAC header of the frame includes a Quality of Service (QoS) control field conveying the request. 4.The QoS control field is A reserved bit set to a value indicating that the frame is a P2P request frame, a Traffic Identifier (TID) subfield set to a value indicating that the frame is a P2P request frame, the TID subfield being equal to or greater than 8; or an Acknowledgement (ACK) Policy Indicator subfield set to a value indicating that the frame is a P2P request frame; 4. The method according to claim 3, comprising: 5. The method of any one or more of clauses 3-4, wherein the QoS Control field includes an End of Service Period (EOSP) subfield, an Acknowledgement (ACK) Policy Indicator subfield following the EOSP subfield, a reserved bit following the ACK Policy Indicator subfield, and an octet following the reserved bit, the octet indicating one or more of a duration of the requested portion of the TXOP, a queue size of the wireless communications device, or a TXOP shared mode bandwidth based on the value carried in the EOSP subfield and the reserved bit. 6. an EOSP subfield carrying a value of 0 when the reserved bit is set to 1 signals that the octet indicates a duration of a requested portion of a TXOP, and an ACK Policy Indicator subfield signals that the TXOP shared mode bandwidth; An EOSP subfield carrying a value of 1 when the reserved bit is set to 1 signals that the octet indicates both the TXOP shared mode bandwidth and the duration of the requested portion of the TXOP. The method described in clause 5. 7. The method of clause 6, wherein an EOSP subfield set to a value of 0 when the reserved bit is set to 0 signals that the octet indicates a duration of a requested portion of a TXOP, and an EOSP subfield set to 1 when the reserved bit is set to 0 signals that the octet indicates a queue size of the wireless communications device. 8. The method of claim 1, wherein the MAC header of the frame includes an Aggregate Control (A-Control) subfield that carries the request. 9.A control subfield: a Control Identification (ID) subfield carrying a reserved value indicating that the frame is a P2P request frame; a control information subfield conveying one or more parameters of a P2P communication associated with the request for the allocated portion of the TXOP; 9. The method according to claim 8, comprising: 10. The method of claim 9, wherein the reserved value carried in the Control ID subfield is one of 9, 11, 12, 13, or 14. 11. The method of any one or more of clauses 9-10, wherein the one or more parameters of the P2P communication include one or more of: a duration of a requested portion of a TXOP, a requested bandwidth of the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval for the P2P communication, a requested type of a trigger frame requesting the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a user priority of a traffic flow associated with the P2P communication, a queue size of the wireless communication device, or a delay bound for a service period associated with the P2P communication. 12.A control subfield is a delta traffic identifier (TID) subfield carrying a reserved value indicating that the frame is a P2P request frame; the Queue Size High and Queue Size All subfields, which collectively carry values ​​indicating the duration of the requested portion of the TXOP and the requested TXOP shared mode bandwidth; 12. The method according to any one or more of clauses 8 to 11, conveying a control information subfield including: 13. The method of any one or more of clauses 1-12, wherein the frame is a TWT request frame including a target wake time (TWT) element indicating a MAC address of the client device and one or more TWT parameters for a limited TWT (r-TWT) service period (SP) associated with the P2P communication. 14. The method of any one or more of clauses 1 to 12, wherein the frame is a stream classification service (SCS) request frame including a traffic specification (TSPEC) element indicating a MAC address of the client device and one or more data rate parameters for a restricted target wake time (r-TWT) service period (SP) associated with the P2P communication. 15. The method of any one or more of clauses 1 to 14, wherein the trigger frame identifies the wireless communication device and the client device. 16. The method of any one or more of clauses 1-15, wherein the trigger frame comprises a multi-user (MU) request to send (RTS) TXOP sharing (TXS) trigger frame including a TXOP sharing mode subfield indicating a TXOP sharing mode of P2P communication between the wireless communication device and the client device. 17. Receiving a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request. 17. The method according to any one or more of clauses 1 to 16, further comprising: 18. The method of clause 17, wherein the MAC header of the response frame includes a QoS control field or an aggregate control (A-control) subfield indicating one or more of the duration of the requested portion of the TXOP, a bandwidth to be allocated to the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a start time of a service period associated with the P2P communication, a service interval associated with the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame. 19. The method of claim 18, wherein the response frame comprises a Quality of Service (QoS) data frame or a block acknowledgement (BA) frame. 20. Sending or receiving P2P data is transmitting latency-sensitive traffic over a wireless medium to a client device based on receiving a trigger frame from the AP; transmitting a P2P trigger frame to the client device over a wireless medium after transmitting latency sensitive traffic to the client device; receiving latency sensitive traffic from a client device over a wireless medium based on the P2P trigger frame; 20. The method according to any one or more of clauses 1 to 19, comprising: 21. The method of any one or more of clauses 1-20, wherein the client device includes a virtual reality (VR) headset or an augmented reality (AR) headset that is associated with the wireless communication device and not associated with the AP. 22. Operate a wireless communication device as a wireless station (STA) associated with an AP and simultaneously operate the wireless communication device as a softAP with associated client devices. 22. The method of any one or more of clauses 1-21, further comprising: 23. At least one modem; at least one processor communicatively coupled to the at least one modem; at least one memory communicatively coupled to the at least one processor and storing processor-readable code; 11. A wireless communication device comprising: a first modem configured to receive a first received signal from a first processor; Transmitting a frame to an access point (AP) over a wireless medium, the frame including a medium access control (MAC) header carrying a request to the AP to allocate a portion of a transmission opportunity (TXOP) obtained on the wireless medium for peer-to-peer (P2P) communication between the wireless communication device and the client device; receiving a trigger frame from an AP over a wireless medium that allocates a portion of a TXOP to a wireless communication device for P2P communication; transmitting or receiving P2P data to or from the client device over the wireless medium during the allocated portion of the TXOP; 1. A wireless communication device configured to: 24. The wireless communications device of clause 23, wherein the request indicates one or more of a duration of a requested portion of the TXOP, a requested bandwidth for the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval for the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame. 25. A wireless communications device according to any one or more of clauses 23-24, wherein the MAC header of the frame includes a Quality of Service (QoS) control field conveying a request. 26. The wireless communications device of clause 25, wherein the QoS Control field includes an End of Service Period (EOSP) subfield, an Acknowledgement (ACK) Policy Indicator subfield following the EOSP subfield, a reserved bit following the ACK Policy Indicator subfield, and an octet following the reserved bit, the octet indicating one or more of a duration of the requested portion of the TXOP, a queue size of the wireless communications device, or a TXOP shared mode bandwidth based on the value carried in the EOSP subfield and the reserved bit. 27. The wireless communications device of clause 23, wherein a MAC header of the frame includes an Aggregate Control (A-Control) subfield that conveys the request. 28. A control subfield: a Control Identification (ID) subfield carrying a reserved value indicating that the frame is a P2P request frame; a control information subfield conveying one or more parameters of a P2P communication associated with the request for the allocated portion of the TXOP; 28. The wireless communication device of claim 27, comprising: 29. Execution of processor-readable code Receive a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request. 29. The wireless communication device of any one or more of clauses 23 to 28, further configured 30. The wireless communications device of clause 29, wherein the MAC header of the response frame includes a QoS control field or an aggregate control (A-control) subfield indicating one or more of a duration of the requested portion of the TXOP, a bandwidth to be allocated to the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a start time of a service period associated with the P2P communication, a service interval associated with the P2P communication, a delay bound for a service period associated with the P2P communication, or a requested type of trigger frame.

[0131]

[0156] As used herein, phrases referring to "at least one of" or "one or more of" a list of items refer to any combination of those items, including single elements. For example, "at least one of a, b, or c" is intended to encompass the possibilities of a only, b only, c only, 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.

[0132]

[0157] The various example components, logic, logic blocks, modules, circuits, operations, and algorithmic processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware, or software, including the structures disclosed herein and structural equivalents thereof. The interchangeability of hardware, firmware, and software has been described generally in terms of functionality and illustrated in the various example components, blocks, modules, circuits, and processes described above. Whether such functionality is implemented in hardware, firmware, or software depends on the particular application and design constraints imposed on the overall system.

[0133]

[0158] Various modifications of the implementations described in this disclosure may be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other implementations without departing from the spirit or scope of the present disclosure. Thus, the claims are not intended to be limited to the implementations shown herein, but are to be accorded the widest scope consistent with the present disclosure, the principles and novel features disclosed herein.

[0134]

[0159] In addition, various features described herein in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented in multiple implementations separately or in any suitable subcombination. Thus, although features may be described above as working in a particular combination and may even initially be claimed as such, in some cases one or more features from the claimed combination may be deleted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0135]

[0160] Similarly, although operations are shown in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order or sequential order shown, or that all of the operations shown be performed, to achieve desirable results. Furthermore, the figures may generally depict one or more exemplary processes in the form of a flow chart or diagram. However, other operations not shown may be incorporated into the generally depicted exemplary process. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the depicted operations. In some situations, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

Claims

1. 1. A method of wireless communication by a wireless communication device, comprising: transmitting a frame over a wireless medium to an access point (AP), the frame including a medium access control (MAC) header carrying a request to the AP to allocate a portion of a contention-based transmission opportunity (TXOP) for peer-to-peer (P2P) communication between the wireless communication device and a client device; receiving a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request to the AP to allocate a portion of the contention-based TXOP obtained by the AP for P2P communication; receiving a trigger frame from the AP over the wireless medium that allocates a portion of the contention-based TXOP to the wireless communication device for the P2P communication based at least in part on receiving the response frame; transmitting or receiving P2P data to or from the client device over the wireless medium during the allocated portion of the contention-based TXOP; A method comprising:

2. 2. The method of claim 1, wherein the request indicates one or more of a duration of the requested portion of the contention-based TXOP, a requested bandwidth for the P2P communication, a traffic identifier (TID) for the P2P communication, a stream classification service (SCS) identifier (SCSID) for the P2P communication, a requested start time of a service period associated with the P2P communication, a requested service interval for the P2P communication, a delay bound for the service period associated with the P2P communication, or a requested type of trigger frame.

3. The method of claim 1 , wherein the MAC header of the frame includes a Quality of Service (QoS) control field that conveys the request.

4. The QoS control field is a reserved bit set to a value indicating that the frame is a P2P request frame; a Traffic Identifier (TID) subfield set to a value indicating that the frame is a P2P request frame, the value being 8 or greater; or an Acknowledgement (ACK) Policy Indicator subfield set to a value indicating that the frame is a P2P request frame; The method of claim 3, comprising:

5. 4. The method of claim 3, wherein the QoS Control field includes an end of service period (EOSP) subfield, an acknowledgement (ACK) policy indicator subfield following the EOSP subfield, a reserved bit following the ACK policy indicator subfield, and an octet following the reserved bit, the octet indicating one or more of a duration of the requested portion of the contention-based TXOP, a queue size of the wireless communication device, or a TXOP shared mode bandwidth based on a value conveyed in the EOSP subfield and the reserved bit.

6. 2. The method of claim 1, wherein the MAC header of the frame includes an Aggregate Control (A-Control) subfield that carries the request.

7. The A control subfield: a Control Identification (ID) subfield carrying a reserved value indicating that the frame is a P2P request frame; a control information subfield conveying one or more parameters of the P2P communication associated with the request for the allocated portion of the contention-based TXOP; The method of claim 6, comprising:

8. The A control subfield: a Delta Traffic Identifier (TID) subfield carrying a reserved value indicating that the frame is a P2P request frame; a Queue Size High subfield and a Queue Size All subfield that carry values that collectively indicate the duration of the requested portion of the contention-based TXOP and the requested TXOP shared mode bandwidth; 7. The method of claim 6, wherein the control information subfield includes:

9. 2. The method of claim 1, wherein the frame is a TWT request frame including a target wake time (TWT) element indicating the MAC address of the client device and one or more TWT parameters of a restricted TWT (r-TWT) service period (SP) associated with the P2P communication.

10. 2. The method of claim 1, wherein the frame is a stream classification service (SCS) request frame that includes a traffic specification (TSPEC) element indicating the MAC address of the client device and one or more data rate parameters of a restricted target wake time (r-TWT) service period (SP) associated with the P2P communication.

11. 2. The method of claim 1, wherein the trigger frame comprises a multi-user (MU) request to send (RTS) TXOP sharing (TXS) trigger frame including a TXOP sharing mode subfield indicating a TXOP sharing mode of the P2P communication between the wireless communication device and the client device.

12. transmitting or receiving the P2P data, transmitting latency-sensitive traffic to the client device over the wireless medium based on receiving the trigger frame from the AP; transmitting a P2P trigger frame to the client device over the wireless medium after transmitting the latency-sensitive traffic to the client device; receiving latency-sensitive traffic from the client device over the wireless medium based on the P2P trigger frame; The method of claim 1 , comprising:

13. Operate the wireless communication device as a wireless station (STA) associated with the AP and simultaneously operate the wireless communication device as a soft AP with which the client device is associated. The method of claim 1 further comprising:

14. at least one processor; at least one memory communicatively coupled to the at least one processor and storing processor-readable code; wherein the processor readable code, when executed by the at least one processor, transmitting a frame over a wireless medium to an access point (AP), the frame including a medium access control (MAC) header carrying a request to the AP to allocate a portion of a contention-based transmission opportunity (TXOP) for peer-to-peer (P2P) communication between the wireless communication device and a client device; receiving a response frame from the AP over the wireless medium, the response frame including a MAC header carrying an acknowledgment of the request to the AP to allocate a portion of the contention-based TXOP obtained by the AP for P2P communication; receiving a trigger frame from the AP over the wireless medium that allocates a portion of the contention-based TXOP to the wireless communication device for the P2P communication based at least in part on receiving the response frame; transmitting or receiving P2P data to or from the client device over the wireless medium during the allocated portion of the contention-based TXOP; 1. A wireless communication device configured to:

15. A computer program comprising instructions for carrying out a method according to any one of claims 1 to 13 when executed by a computer.

Images