TW202408296A - Systems and methods of requesting buffer status for wireless peer-to-peer (p2p) traffic - Google Patents

Abstract

An access point may include one or more processors. The one or more processors may be configured to generate a first frame to trigger a receiver device to send a response frame that includes buffer status data corresponding to wireless traffic between the receiver device and another device. The one or more processors may be configured to wirelessly transmit, via a transmitter, the generated first frame to one or more devices.

Description

Systems and methods for requesting buffer status for wireless point-to-point traffic

This disclosure generally relates to communications, including but not limited to systems and methods for access point (AP) querying or polling the buffer status of a point-to-point (p2p) link (if one exists) to improve resource allocation. Cross-references to related applications

This application claims priority from U.S. Provisional Patent Application No. 63/333,822, filed on April 22, 2022, which is hereby incorporated by reference in its entirety for all purposes. This application also claims priority from U.S. Provisional Patent Application No. 63/333,872, filed on April 22, 2022, which is hereby incorporated by reference in its entirety for all purposes.

Artificial reality, such as virtual reality (VR), augmented reality (AR) or mixed reality (MR), provides users with an immersive experience. In one example, a user wearing a head wearable display (HWD) may rotate the user's head, so that an image of a virtual object corresponding to the position of the HWD and the direction of the user's gaze may be is displayed on the HWD to allow the user to feel as if the user is moving within an artificial reality space (eg, VR space, AR space, or MR space). Images of virtual objects may be generated by a console communicatively coupled to the HWD. In some embodiments, the console can be connected to the Internet.

Various embodiments disclosed herein relate to a device including one or more processors. In some embodiments, the one or more processors may be configured to generate a first frame to trigger a receiver device to transmit a response frame that includes a response frame corresponding to the response between the receiver device and another Buffer status data for wireless traffic between devices. The one or more processors may be configured to wirelessly send the generated first frame to one or more devices via a transmitter.

In some embodiments, the wireless traffic may include point-to-point (p2p) traffic between the receiver device and the other device. In some embodiments, in generating the first frame, the one or more processors may be configured to set a frame type field of the first frame to indicate a buffer status trigger A type of message frame.

In some embodiments, the first frame may include a first user information field related to a first device. In generating the first frame, the one or more processors may be configured to set a subfield of the first user information field to a first value that indicates the value for the first user information field in the first frame. A buffer status request for wireless traffic between a device and a second device. The first frame may include a second user information field related to a third device. In generating the first frame, the one or more processors may be configured to set a subfield of the second user information field to a second value that indicates the Obtain a buffer status request for wireless traffic between the access point and the third device to trigger the third device to transmit a response frame that includes a response frame corresponding to the connection between the access point and the third device. Buffer status information for the wireless traffic between.

In some embodiments, the first frame may include a common information field that contains information related to multiple users or receiver devices. In generating the first frame, the one or more processors may be configured to set a subfield of the common information field to a value that indicates the value for the receiver device and the A buffer status request for wireless traffic between the other device.

In some embodiments, the first frame may include a common information field. In generating the first frame, the one or more processors may be configured to set a subfield of the common information field to a value to trigger a plurality of users or receiver devices to Send individual response frames containing individual buffer status data corresponding to peer-to-peer (p2p) traffic.

In some embodiments, the first frame may include a frame type field. In generating the first frame, the one or more processors may be configured to set the frame type field to a type indicating a buffer status trigger message for point-to-point (p2p) traffic. frame.

In some embodiments, the first frame may include a common information field that contains information related to multiple users or receiver devices. The frame type field may be a subfield of the common information field.

In some embodiments, the first frame may include a frame type field. In generating the first frame, the one or more processors may be configured to set the frame type field to a type that triggers a plurality of users or receiver devices to transmit respective response messages. Box containing individual buffer status data corresponding to wireless point-to-point (p2p) traffic.

Various embodiments disclosed herein relate to a method that includes generating a first frame by an access point to trigger a receiver device to transmit a response frame that includes corresponding to the Buffer status data for wireless traffic between a device and another device. The method may include wirelessly transmitting the generated first frame to one or more devices via a transmitter of the access point.

In some embodiments, the wireless traffic may include point-to-point (p2p) traffic between the receiver device and the other device. In some embodiments, in generating the first frame, the access point may set a frame type field of the first frame to indicate a type of buffer status triggering frame.

In some embodiments, the first frame may include a first user information field related to a first device. In generating the first frame, the access point may set a subfield of the first user information field to a first value that indicates that the first device is connected to a second user information field. A buffer status request for wireless traffic between devices. The first frame may include a second user information field related to a third device. In generating the first frame, the access point may set a sub-field of the second user information field to a second value that indicates the difference between the access point and the third user information field. A buffer status request for wireless traffic between three devices to trigger the third device to transmit a response frame containing information corresponding to the wireless traffic between the access point and the third device. Buffer status information for traffic.

In some embodiments, the first frame may include a common information field that contains information related to multiple users or receiver devices. In generating the first frame, the access point may set a subfield of the common information field to a value that indicates the value for the communication between the receiver device and the other device. A buffer status request for wireless traffic.

In some embodiments, the first frame may include a common information field. In generating the first frame, the access point may set a subfield of the common information field to a value that triggers multiple users or receiver devices to transmit individual response frames. , which contains individual buffer status data corresponding to peer-to-peer (p2p) traffic.

In some embodiments, the first frame may include a frame type field. In generating the first frame, the access point may set the frame type field to a type indicating a buffer status triggering frame for point-to-point (p2p) traffic. The first frame may include a common information field containing information relevant to multiple users or receiver devices. The frame type field may be a subfield of the common information field.

In some embodiments, the first frame may include a frame type field. In generating the first frame, the access point may set the frame type field to a type that triggers a plurality of users or receiver devices to transmit individual response frames that include responses corresponding to Individual buffer status information for wireless point-to-point (p2p) traffic.

Before turning to the drawings, which depict certain embodiments in detail, it is to be understood that the present disclosure is not limited to the details or methodology set forth in the description or depicted in the drawings. It is also to be understood that the terminology used herein is for the purpose of description only and should not be regarded as limiting.

FIG. 1 is a block diagram of an example artificial reality system environment 100 in which a console 110 operates. Figure 1 provides an example environment in which devices can stream traffic under different latency sensitivities/needs. In some embodiments, the artificial reality system environment 100 includes a HWD 150 worn by a user, and a console 110 that provides artificial reality content to the HWD 150 . A head wearable display (HWD) may be referred to as or includes a head mounted display (HMD), a head mounted device (HMD), a head wearable device (HWD), a head mounted display (HWD), or a head mounted display (HWD). Wearable device (HWD), or part thereof. In one feature, the HWD 150 may include various sensors to detect the position, orientation and/or gaze direction of the user wearing the HWD 150, and provide the detected information through a wired or wireless connection. The measured position, orientation and/or gaze direction is transmitted to the console 110 . The HWD 150 can also recognize objects (eg, body, hands, face).

The console 110 may determine a view within the space of the artificial reality corresponding to the detected position, orientation, and/or the gaze direction, and generate an image depicting the determined view. The console 110 may also receive one or more user inputs and modify the image based on the user inputs. The console 110 may provide the image to the HWD 150 for imaging. An image of the space of the artificial reality corresponding to the user's field of view may be presented to the user. In some embodiments, the artificial reality system environment 100 includes more, fewer, or different components than shown in FIG. 1 . In some embodiments, the functionality of one or more components of the artificial reality system environment 100 may be distributed among the components in a different manner than described herein. For example, certain functions of the console 110 may be performed by the HWD 150 and/or certain functions of the HWD 150 may be performed by the console 110 .

In some embodiments, the HWD 150 is an electronic component wearable by a user and can present or provide an artificial reality experience to the user. The HWD 150 can display one or more images, videos, audios, or some combination thereof to provide the artificial reality experience to the user. In some embodiments, audio is presented via an external device (eg, speakers and/or headphones) that receives audio information from the HWD 150 , the console 110 , or both, and based on The message information is used to display the message. In some embodiments, the HWD 150 includes a sensor 155, an eye tracker 160, a communication interface 165, an imager 170, an electronic display 175, a lens 180, and a compensator 185. These components may operate together to detect the position of the HWD 150 and/or the gaze direction of the user wearing the HWD 150 and correspond to the detected position of the HWD 150 and/or the user's gaze direction. The gaze direction is used to image an image of a view within the artificial reality. In other embodiments, the HWD 150 includes more, fewer, or different components than shown in FIG. 1 .

In some embodiments, the sensor 155 includes electronic components, or a combination of electronic components and software components, that detect the position and/or orientation of the HWD 150 . Examples of sensors 155 may include: one or more imaging sensors, one or more accelerometers, one or more gyroscopes, one or more magnetometers, or another suitable type that detects motion and /or position sensor. For example, one or more accelerometers can measure translational movement (e.g., forward/backward, up/down, left/right), and one or more gyroscopes can measure rotational movement (e.g., pitch, yaw). , tumbling). In some embodiments, the sensor 155 detects the translational movement and/or the rotational movement, and determines the orientation and position of the HWD 150 . In one feature, the sensor 155 can detect translational movement and/or rotational movement related to a previous orientation and position of the HWD 150 and by accumulating or integrating the detected translational movement. The movement and/or rotation is used to determine a new orientation and/or position of the HWD 150 . For example, assuming that the HWD 150 is oriented in a direction 25 degrees away from a reference direction, in response to detecting that the HWD 150 has rotated 20 degrees, the sensor 155 can determine that the HWD 150 is now facing Or oriented in a direction 45 degrees away from said reference direction. For another example, assuming that the HWD 150 was previously located two feet away from a reference point in a first direction, in response to detecting that the HWD 150 has moved three feet in a second direction, the sensing The detector 155 may determine that the HWD 150 is now located at the vector product of two feet in the first direction and three feet in the second direction.

In some embodiments, the eye tracker 160 may include an electronic component or a combination of electronic components and software components that determines the gaze direction of the user of the HWD 150 . In some embodiments, the HWD 150, the console 110, or a combination may incorporate the gaze direction of a user of the HWD 150 to generate image data for artificial reality. In some embodiments, the eye tracker 160 includes two eye trackers, wherein each eye tracker 160 captures an image of a corresponding eye and determines the gaze direction of the eye. In one example, the eye tracker 160 determines an angular rotation of the eye, a translation of the eye, a change in the rotation of the eye, and/or a change in the rotation of the eye based on the captured image of the eye. A change in the shape of the eye, and the relative gaze direction of the HWD 150 is determined based on the determined angular rotation, translation, and change in the rotation of the eye. In one approach, the eye tracker 160 may cast or project a predetermined reference or structured pattern on a portion of the eye and capture an image of the eye to analyze the portion projected on the eye. The pattern on the HWD 150 is used to determine a relative gaze direction of the eye relative to the HWD 150 . In some embodiments, the eye tracker 160 incorporates the orientation of the HWD 150 and the relative gaze direction associated with the HWD 150 to determine a gaze direction of the user. For example, assuming that the HWD 150 is oriented in a direction 30 degrees away from a reference direction, and the relative gaze direction of the HWD 150 is -10 degrees (or 350 degrees) relative to the HWD 150, then the The eye tracker 160 may determine that the user's gaze direction deviates from the reference direction by 20 degrees. In certain embodiments, a user of the HWD 150 may configure the HWD 150 (eg, via user settings) to enable or disable the eye tracker 160 . In some embodiments, the user of the HWD 150 is prompted to enable or disable the eye tracker 160 .

In some embodiments, the hand tracker 162 includes an electronic component, or a combination of an electronic component and a software component, that tracks the user's hand. In some embodiments, the hand tracker 162 includes or is coupled to an imaging sensor (eg, a camera) and an image processor that can detect the shape, position, and/or orientation of the hand. The hand tracker 162 may generate hand tracking measurements that indicate the detected shape, position, and/or orientation of the hand.

In some embodiments, the communication interface 165 includes an electronic component or a combination of an electronic component and a software component that communicates with the console 110 . The communication interface 165 can communicate with a communication interface 115 of the console 110 through a communication link. The communication link may be a wireless link, a wired link, or both. Examples of the wireless link may include cellular communication links, near field communication links, Wi-Fi, Bluetooth, or any wireless communication link. Examples of the wired link may include USB, Ethernet, Firewire, HDMI, or any wired communication link. In an embodiment in which the console 110 and the head wearable display 150 are implemented on a single system, the communication interface 165 may communicate with the communication interface 165 through a bus connection or a conductive line. Console 110 communications. Through the communication link, the communication interface 165 can send sensor measurements to the console 110, which indicates the determined position of the HWD 150, the orientation of the HWD 150, and the user. Judgment of gaze direction, and/or tracking of hand measurements. Furthermore, through the communication link, the communication interface 165 can receive sensor measurements from the console 110 that indicate or correspond to the image to be imaged.

Using the communication interface, the console 110 (or HWD 150) can coordinate operations on link 101 to reduce conflicts or interference. For example, the console 110 may coordinate communications between the console 110 and the HWD 150 . In some embodiments, the console 110 may periodically send a beacon frame to announce/notify the communication between the console 110 and the HWD 150 (or between two HWDs). The existence of a wireless link. In one embodiment, the HWD 150 may monitor or receive the beacon frame from the console 110 and may schedule communications with the HWD 150 (e.g., using information in (for example, an offset value) to avoid conflicts or interference with communications between the console 110 and/or the HWD 150 and other devices.

The console 110 and HWD 150 may communicate using link 101 (eg, an internal link). Data (eg, a traffic stream) may flow in one direction on link 101. For example, the console 110 may communicate with the HWD 150 using a downlink (DL) communication, and the HWD 150 may communicate with the console 110 using an uplink (UL) communication. .

In some embodiments, the imager 170 includes an electronic component or a combination of an electronic component and a software component, which generates one or more objects based on spatial changes that take into account the artificial reality, for example. to the displayed image. In some embodiments, the imager 170 is implemented as a processor (or a graphics processing unit (GPU)) that executes instructions to perform various functions described herein. The image imager 170 may receive data describing an image to be imaged through the communication interface 165 and image the image through the electronic display 175 . In some embodiments, data from the console 110 may be encoded, and the image imager 170 may decode the data to generate and image the image. In one feature, the imager 170 receives the encoded image from the console 110 and decodes the encoded image such that the communication bandwidth between the console 110 and the HWD 150 Can be reduced.

In some embodiments, the imager 170 receives additional data from the console 110 that includes object information indicating the virtual object in the artificial reality space, and indicating the depth (or depth) of the virtual object. is the depth information from the HWD 150). Therefore, the imager 170 can receive object information and/or depth information from the console 110 . The imager 170 may also receive updated sensor measurements from the sensor 155 . The HWD 150 detects the position and orientation of the HWD 150 and/or the gaze direction of the user wearing the HWD 150, and generates and sends a response corresponding to the detected position through the console 110 and a high-resolution image in the gaze direction (e.g., 1920 by 1080 pixels, or 2048 by 1152 pixels) to the HWD 150 may be computationally exhaustive and may not be possible within one frame time (e.g., , less than 11ms or 8ms) to be executed.

In some embodiments, the imager 170 may perform shading, reprojection, and/or blending to update the image of the artificial reality to correspond to the updated position and/or orientation of the HWD 150 . Assuming that the user rotates his head after the initial sensor measurement, the image imager 170 does not regenerate the entire image in response to the updated sensor measurement, but can instead respond to the updated sensor measurement. Subsequent sensor measurements are used to generate a small portion (e.g., 10%) of an image that corresponds to an updated view within the artificial reality, and the portion is appended via reprojection to the image from The image in the image data of the console 110 . The imager 170 may perform shading and/or blending on the additional edges. Therefore, the image imager 170 can generate an image of the artificial reality without regenerating the image of the artificial reality based on the updated sensor measurements.

In other embodiments, when an image from the console 110 is not received within the frame time, the image imager 170 generates one or more images through a rendering process and a re-projection process. image. For example, the shading process and the re-projection process may be adaptively executed based on changes in the space of the artificial reality taking into account.

In some embodiments, the electronic display 175 is an electronic component that displays images. The electronic display 175 may be, for example, a liquid crystal display or an organic light emitting diode display. The electronic display 175 may be a transparent display that allows the user to see through. In some embodiments, the electronic display 175 is located proximate (eg, less than 3 inches) to the user's eyes when the HWD 150 is worn by the user. In one feature, the electronic display 175 emits or projects light toward the user's eyes based on images generated by the imager 170 .

In some embodiments, the lens 180 is a mechanical component that modifies the light received from the electronic display 175 . The lens 180 can amplify light from the electronic display 175 and correct optical errors associated with the light. The lens 180 may be a Fresnel lens, a convex lens, a concave lens, a filter, or any suitable optical component that changes the light from the electronic display 175 . Through the lens 180, light from the electronic display 175 can reach the pupil, so that the user can see the image displayed by the electronic display 175, even though the electronic display 175 is very close to the eye.

In some embodiments, the compensator 185 includes an electronic component or a combination of an electronic component and a software component that performs compensation to compensate for any distortion or aberration. In one feature, the lens 180 introduces optical aberrations such as chromatic aberration, pincushion distortion, barrel distortion, and the like. The compensator 185 may determine a compensation (eg, predistortion) to apply to the image to be imaged from the image imager 170 to compensate for the distortion caused by the lens 180, and apply the determined compensation to Image from the imager 170 . The compensator 185 may provide the predistorted image to the electronic display 175 .

In some embodiments, the console 110 is an electronic component or a combination of an electronic component and a software component that provides content to be imaged to the HWD 150 . In one feature, the console 110 includes a communication interface 115 and a content provider 130 . These components may operate together to determine a view of the artificial reality (e.g., a field of view (FOV) of the user) corresponding to the location of the HWD 150 and/or the direction of gaze of the user of the HWD 150, And an image of the artificial reality corresponding to the determined view can be generated. In other embodiments, the console 110 includes more, fewer, or different components than shown in FIG. 1 . In some embodiments, the console 110 is integrated as part of the HWD 150 . In some embodiments, the communication interface 115 is an electronic component or a combination of an electronic component and a software component that communicates with the HWD 150 . The communication interface 115 may be a corresponding component of the communication interface 165 to communicate with a communication interface 115 of the console 110 through a communication link (eg, USB cable, wireless link). Through the communication link, the communication interface 115 can receive sensor measurements from the HWD 150, which indicate the determined position and/or orientation of the HWD 150, the determined position of the user out gaze direction, and hand tracking measurements. Furthermore, through the communication link, the communication interface 115 can send data describing the image to be imaged to the HWD 150 .

The content provider 130 may include or correspond to a component that generates content to be imaged based on the position and/or orientation of the HWD 150, the user's gaze direction, and/or hand tracking measurements. In one feature, the content provider 130 determines a view of the artificial reality based on the position and orientation of the HWD 150 and/or the gaze direction of the user of the HWD 150 . For example, the content provider 130 maps a location of the HWD 150 in a physical space to a location in an artificial reality space, and along a path corresponding to the mapped location from the artificial reality space. The orientation of the HWD 150 and/or the direction of the user's gaze determines a view of the artificial reality space.

The content provider 130 may generate image data describing an image of the determined view of the artificial reality space and send the image data to the HWD 150 through the communication interface 115 . The content provider may also generate a hand model (or other virtual object) corresponding to the user's hand based on the hand tracking measurement, and generate a shape indicating the hand model in the artificial reality space. , position and orientation hand model data.

In some embodiments, the content provider 130 generates metadata related to the image, including motion vector information, depth information, edge information, object information, etc., and communicates with and through the communication interface 115 The metadata is sent to the HWD 150 along with the image data. The content provider 130 may encode and/or encode data describing the image, and may send the encoded and/or encoded data to the HWD 150 . In some embodiments, the content provider 130 generates and provides the images to the HWD 150 periodically (eg, every second).

Figure 2 is a diagram of a HWD 150 according to an example embodiment. In some embodiments, the HWD 150 includes a front rigid body 205 and a strap 210 . The front rigid body 205 includes the electronic display 175 (not shown in Figure 2), the lens 180 (not shown in Figure 2), the sensor 155, the eye trackers 160A, 160B, the communication interface 165, and the image imager 170. In the embodiment shown in Figure 2, the sensor 155 is located within the front rigid body 205 and may be invisible to the user. In other embodiments, the HWD 150 has a different configuration than that shown in FIG. 2 . For example, the imager 170 , the eye trackers 160A, 160B, and/or the sensor 155 may be in a different location than shown in FIG. 2 .

Various operations described herein may be performed on computer systems. 3 is a block diagram illustrating a representative computing system 314 that may be used to implement the present disclosure. In some embodiments, the console 110, HWD 150, or both of FIG. 1 are implemented by the computing system 314. For example, computing system 314 may be implemented as a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smart watch, glasses, head-mounted display), desktop Computers, laptops, or distributed computing devices may be used. The computing system 314 may be implemented to provide VR, AR, and MR experiences. In some embodiments, the computing system 314 may include conventional computer components, such as a processor 316, a storage device 318, a network interface 320, a user input device 322, and a user output device 324.

Network interface 320 may provide connection to a wide area network (eg, the Internet) to which a remote server system's WAN interface is also connected. Network interface 320 may include a wired interface (e.g., Ethernet) and/or an implementation such as Wi-Fi, Bluetooth, or cellular data network standards (e.g., 3G, 4G, 5G, 60GHz, LTE , etc.) wireless interfaces of various RF data communication standards.

The network interface 320 may include a transceiver to allow the computing system 314 to utilize a transmitter and receiver to send and receive data from a remote device (eg, an AP, a STA). The transceiver may be configured to support transmit/receive, which supports industry standards enabling bidirectional communications. An antenna may be attached to the transceiver housing and electrically coupled to the transceiver. Additionally or alternatively, an array of multiple antennas may be electrically coupled to the transceiver such that multiple beams pointed in different directions may facilitate sending and/or receiving data.

A transmitter may be configured to wirelessly transmit frames, slots, or symbols generated by the processor unit 316. Similarly, a receiver may be configured to receive frames, slots, or symbols, and the processor unit 316 may be configured to process the frames. For example, the processor unit 316 may be configured to determine the type of the frame and process the frame and/or fields of the frame accordingly.

User input device 322 may include any device (or devices) through which a user can provide a signal to computing system 314 ; computing system 314 can interpret the signal as indicating a specific user request or information. User input device 322 may include a keyboard, trackpad, touch screen, mouse or other pointing device, wheel button, click wheel, dial, buttons, switches, keypad, microphone, sensors (e.g., Any or all of motion sensors, eye tracking sensors, etc.), etc.

User output device 324 may include any device through which computing system 314 may provide information to a user. For example, user output device 324 may include a display to display images generated by or transmitted to computing system 314 . The display may incorporate various image-generating technologies such as a liquid crystal display (LCD), a light emitting diode (LED) including an organic light emitting diode (OLED), a projection system, a cathode ray tube (CRT) or the like, and Supported electronic devices (e.g., digital-to-analog or analog-to-digital converters, signal processors, or the like). Devices that function as both input and output devices, such as touch screens, may be utilized. Output device 324 may be provided in addition to or instead of a display. Examples include indicator lights, speakers, tactile "display" devices, printers, etc.

Certain embodiments include electronic components, such as a microprocessor, storage and memory, that store computer program instructions in a computer-readable storage medium (eg, a non-transitory computer-readable medium). Many of the features described in this specification may be implemented as a program, which is specified as a set of program instructions encoded on a computer-readable storage medium. When these program instructions are executed by one or more processors, they cause the processors to perform various operations specified in the program instructions. Examples of program instructions or computer code include machine code generated, for example, by a compiler, and files containing higher-level code that are executed by a computer, electronic component, or microprocessor using an interpreter. Through appropriate programming, processor 316 may provide various functions to computing system 314, including any of the functions described herein as being performed by a server or client, or other functions related to information management services.

It will be appreciated that computing system 314 is illustrative and variations and modifications are possible. Computer systems used in connection with this disclosure may have other functions not expressly described here. Furthermore, although computing system 314 is described with reference to specific blocks, it will be understood that these blocks are defined for convenience of illustration and are not intended to refer to a specific physical structure of the component parts. configuration. For example, different blocks may be located in the same facility, in the same server rack, or on the same motherboard. Furthermore, the blocks need not correspond to actual distinct components. Blocks may be configured to perform various operations, such as by programming the processor or providing appropriate control circuitry, and the various blocks may or may not be reconfigurable, depending on how the original configuration was obtained . Embodiments of the present disclosure may be implemented in a variety of devices, including electronic devices implemented with any combination of circuitry and software.

1. Request a buffer status report for wireless point-to-point (p2p) traffic

IEEE 802.11be Extremely High Throughput (EHT) may be the next generation 802.11 IEEE standard, which may be called Wi-Fi 7. According to certain embodiments of the present disclosure, a signaling method for requesting/polling buffer status reports (BSR) may be defined. A BSR operation can be performed as follows. An AP can send a trigger frame (eg, Buffer Status Report Polling (BSRP) trigger frame) to a STA to query the buffer status. The buffer status can be a quantitative indication of how much traffic (eg, quality of service (QoS) data) is queued at a STA. The STA may indicate a buffer with a unit of data (e.g., bytes) by including either a QoS control field or a BSR control field in the frame transmitted to the AP. condition. The STA may indicate a buffer status in response to a BSRP trigger frame, or in an unsolicited response of its own.

FIG. 4A is a Buffer Status Report (BSR) request (eg, BSRP trigger frame 402) and BSR response (eg, High Efficiency (HE) trigger-based (TB)) in accordance with an example implementation of the present disclosure. Diagram 400 of uplink (UL) Aggregation MAC Protocol Data Unit (A-MPDU) frame 406). As shown in Figure 4, the AP may transmit the BSRP trigger frame 402. After a short inter-frame space (SIFS) 404, the STAs (eg, STA1-STA4) may transmit their respective buffer status contained in the HE TB ULA-MPDU frame 406, which may be received in another SIFS. 408 is followed by a multi-STA block acknowledgment (M-BA) frame 410 for acknowledgment. A buffer status may be contained in a QoS-Control field or a BSR HE control field within a QoS-Data frame or a QoS-None frame. A STA may or may not acknowledge (ACK) a BSR request.

4B is a diagram of a system environment including point-to-point (p2p) traffic in a wireless local area network (WLAN), in accordance with an example implementation of the present disclosure. A first non-AP STA device 470 may be configured to transmit/receive UL/DL (downlink) traffic 472 to and from an AP device 460 , and may be configured to transmit/receive to and from a second non-AP device 480 p2p traffic 474. A third non-AP STA device 490 may be configured to transmit/receive UL/DL traffic 492 to and from the AP device 460 .

Figures 5A, 5B, and 5C depict examples for a BSR trigger frame format 500 (eg, a BSRP trigger frame) in accordance with example implementations of the present disclosure. Figure 5D depicts an example trigger type subfield encoding 590 in accordance with an example implementation of the present disclosure. Referring to Figures 5A to 5D, the BSR trigger frame format 500 may include frame control 501, duration 502, receiver address 503, transmitter address 504, common information ("Common Info") 550, usage User information list 510, which includes a plurality of user information fields (e.g., user information ("User Info") field format 520), padding 505, and/or fields of a frame check sequence (FCS) 506 Bit. The user information field format 520 may include association identifier (AID12) 521, RU (resource unit) allocation 522, UL FEC (forward error correction) encoding type 523, UL HE-MCS (modulation coding design) 524 , UL DCM (Dual Carrier Modulation) 525, SS (Spatial Streaming) allocation/RA-RU information 526, UL target received power 527, reserved 528, and/or trigger-dependent user information 529 subfields. The trigger-dependent user information 529 may or may not exist in the trigger frame. The common information fields 550 may include trigger type 551, UL length 552, more TF (trigger frame) 553, CS (carrier sensing required) 554, UL BW (bandwidth) 555, GI (guard interval) And LTF (Long Training Field) type 556, MU (Multiple User)-MIMO (Multiple Input Multiple Output) HE-LTF mode 557, HE-LTF symbol number and intermediate code period 558, UL STBC (Space-time Block Coding) 559. LDPC (Low Density Parity Check) additional symbol segment 560, AP Tx power 561, padding factor before FEC 562, PE (Packet Extension) disambiguation 563, UL space reuse 564, Doppler 565, UL HE-S1G-A2 reserved 566, reserved 567, and/or trigger dependent common information 568 subfields. The trigger type subfield 551 may be set to a value (eg, 4) that indicates the BSRP as defined in an entry 592 within the trigger type subfield code 590 . The trigger-dependent common information 568 may or may not exist in the trigger frame.

Referring to FIGS. 5A to 5D , the AP may transmit a BSRP trigger frame having the trigger frame format 500 . The trigger type subfield of the BSRP trigger (eg, trigger type 551) may be set to 4 to indicate a BSRP trigger frame (see Figure 5D). The BSRP trigger frame may report its UL buffer status to one or more STAs in a response frame (eg, QoS-Data or QoS-Null frame). These BSR operations may be used in a Target Wake Time (TWT) mechanism, such as Restricted TWT (R-TWT), which is defined in a Wireless Local Area Network (WLAN) protocol (eg, 802.11be). In a TWT mechanism, STAs (such as smartphones or HWD wireless devices) can adopt a wake-up time schedule that causes them to wake up periodically to send/receive data. R-TWT can force all other 802.11be compliant devices to complete their transmissions before the start of a TWT Service Period (SP). R-TWT may be used to provide prioritized access and moderate access protection to a STA's point-to-point (p2p) traffic (eg, p2p traffic 474 of device 470 in Figure 4B). This TWT mechanism (eg, R-TWT) may require the ability to report buffer status for a STA's p2p traffic to perform efficiently. For example, an AP (eg, AP 460 in FIG. 4B ) may allocate p2p traffic to the STA (eg, p2p traffic 474 of the device 470 ) during an R-TWT SP according to the buffer status. Resources (e.g., Transmit Opportunities (TXOP)). During an ongoing SP, if the AP can query the status of a STA's peer-to-peer (p2p) traffic, it will facilitate efficient operation (eg, help the AP allocate resources efficiently). For example, a STA may indicate an empty buffer for p2p to the AP to indicate that the STA has completed delivering delay-sensitive traffic (LST). A TWT SP can be terminated to save power (if uplink/downlink (UL/DL) LSTs are also delivered) so the AP can serve other STAs. The STA may point a non-empty buffer for p2p to the AP near the end of an SP to convey that the STA still has LSTs. The SP may be extended by the AP to allow the STA to deliver remaining buffered traffic. The AP itself can also query the buffer status to make this easy.

However, other/conventional Buffer Status Request/Polling (BSRP) triggering mechanisms can only request the STA's uplink (UL) buffer status. The AP cannot use the BSRP trigger frame to query the status of the STA's point-to-point (p2p) traffic. So there is a need/benefit to define a new request method for AP to query/poll the buffer status of p2p traffic.

To solve this problem, a signaling method for requesting/polling buffer status reports for p2p traffic can be proposed/defined. In some embodiments, the format of a BSRP trigger frame may be redefined to indicate a request for buffer status for p2p traffic. For example, the common information ("Common Info") field or the subfields/bits of the user information ("User Info") field can be redefined to indicate a buffer for p2p traffic status request. A new trigger type for p2p traffic can be defined using a trigger type field of the common information field.

In one approach, one or more bits (e.g., a reserved bit) in the user information field of a BSRP trigger frame (the "first p2p bit") can be used to indicate a p2p Buffer status request. When the first p2p bit in a trigger frame transmitted by an AP is set, the trigger frame may indicate/request/trigger a STA to utilize a BSR procedure to include traffic targeted for its p2p buffer status in response. For example, when the first p2p bit is set to a first value (eg, 1), the STA may or should transmit the buffer status of its p2p traffic in response to the trigger frame. When the first p2p bit is set to a second value (eg, 0), the STA may transmit the buffer status of its uplink (UL) traffic in response to the trigger frame. Because the trigger frame utilizes the user information field, this trigger method may or may not be used depending on the user or STA. For example, the user information list fields may include a plurality of user information fields, in which a first user information field may indicate a p2p buffer status request to a first user/STA, and a second user information field may indicate a p2p buffer status request to a first user/STA. The user information field may indicate the UL buffer status request to a second user/STA. In some embodiments, one or more defined/repurposed bits from any one or more fields (e.g., in addition to the user information field, or in addition to the user information field) field) may be utilized to indicate to the STA that it contains its buffer status for its p2p traffic and/or other types of traffic (eg, UL and/or DL).

In one approach, one or more bits (e.g., a reserved bit) in the common information field of a BSRP trigger frame (the "second p2p bit") can be used to indicate the p2p buffer District status request. When the second p2p bit in a trigger frame transmitted by an AP is set, the trigger frame may indicate/request/trigger a STA to utilize a BSR procedure to include traffic targeted for its p2p of its buffer status in response. For example, when the second p2p bit is set to a first value (eg, 1), the STA may or should transmit the buffer status of its p2p traffic in response to the trigger frame. When the second p2p bit is set to a second value (eg, 0), the STA may transmit the buffer status of its uplink traffic in response to the trigger frame. Because the trigger frame utilizes the common information field, this trigger method can be used (or triggered) by all users or all STAs that receive the trigger frame. In some embodiments, one or more defined/repurposed bits from any one or more fields (e.g., in addition to the user information field) may be utilized to provide the STA with Point out including its buffer status for its p2p traffic and/or other types of traffic (eg, UL and/or DL).

In one approach, a new BSRP-p2p trigger frame can be defined to indicate a p2p buffer status request. A new/specific trigger frame type for p2p traffic, e.g. "BSRP-p2p trigger frame type" may be added/introduced/defined for use in the trigger type field of the common information field One value. For example, a value such as 8 or any value not used by other types may be used. In some embodiments, the frame format may be the same as or similar to the format of a BSRP trigger frame. When a STA receives a BSRP-p2p trigger frame in which the trigger type field is set to the BSRP-p2p trigger frame type, the STA can or should use a BSR procedure to include information about its p2p traffic. of its buffer status in response.

In one approach, an access point may contain one or more processors. The one or more processors may be configured to generate a first frame to trigger a receiver device to transmit a response frame containing information corresponding to wireless traffic between the receiver device and another device. Buffer status information. The one or more processors may be configured to wirelessly send the generated first frame to one or more devices via a transmitter.

In one approach, the wireless traffic may include point-to-point (p2p) traffic between the receiver device and the other device. In some embodiments, in generating the first frame, the one or more processors may be configured to set a frame type field of the first frame to indicate a buffer status trigger A type of message frame.

In one approach, the first frame may include a first user information field related to a first device. In generating the first frame, the one or more processors may be configured to set a subfield of the first user information field to a first value that indicates the value for the first user information field in the first frame. A buffer status request for wireless traffic between a device and a second device. The first frame may include a second user information field related to a third device. In generating the first frame, the one or more processors may be configured to set a subfield of the second user information field to a second value that indicates the Obtain a buffer status request for wireless traffic between the access point and the third device to trigger the third device to transmit a response frame that includes a response frame corresponding to the connection between the access point and the third device. Buffer status information for the wireless traffic between.

In one approach, the first frame may include a common information field containing information relevant to multiple users or receiver devices. In generating the first frame, the one or more processors may be configured to set a subfield of the common information field to a value that indicates the value for the receiver device and the A buffer status request for wireless traffic between the other device.

In one approach, the first frame may contain a common information field. In generating the first frame, the one or more processors may be configured to set a subfield of the common information field to a value to trigger a plurality of users or receiver devices to Send individual response frames containing individual buffer status data corresponding to peer-to-peer (p2p) traffic.

In one approach, the first frame may include a frame type field. In generating the first frame, the one or more processors may be configured to set the frame type field to a type indicating a buffer status trigger message for point-to-point (p2p) traffic. frame.

In one approach, the first frame may include a common information field containing information relevant to multiple users or receiver devices. The frame type field may be a subfield of the common information field.

In one approach, the first frame may include a frame type field. In generating the first frame, the one or more processors may be configured to set the frame type field to a type that triggers a plurality of users or receiver devices to transmit respective response messages. Box containing individual buffer status data corresponding to wireless point-to-point (p2p) traffic.

Embodiments in the present disclosure have at least the following advantages and benefits. Embodiments in the present disclosure may provide useful techniques for querying the status of a STA's peer-to-peer (p2p) traffic using a BSRP trigger frame, thereby providing a new request method for the AP to query/poll for p2p traffic. Buffer status. In some embodiments, a new request method may be provided by redefining the format of a BSRP trigger frame, or by defining a new trigger frame type for BSR-p2p. In this way, the AP can query/poll the p2p traffic of a specific user (e.g., using the user information field) or all users (e.g., using the common information field). Buffer status.

Figure 6 depicts an example user information ("User Info") field format 600 for indicating peer-to-peer (p2p) traffic, in accordance with an example implementation of the present disclosure. Except for one sub-field 601, the user information field format 600 may be the same as or similar to the user information field format 520. In some embodiments, the subfield 601 of the user information field format 600 may redefine the reserved bit 528 (see FIG. 5B ) to indicate/request/trigger a STA to utilize a BSR procedure to include Buffer status for its p2p traffic in response. In some embodiments, the subfield 601 may be a single bit (eg, bit B39 of the user information field format 600). When bit B39 in a trigger frame is set, a trigger frame transmitted by an AP (eg, AP 460) can indicate/request/trigger a STA (eg, device 470) to utilize a BSR The program responds by including buffer status for its p2p traffic (eg, p2p traffic 474 between the device 470 and the device 480 ). For example, when the bit B39 is set to a first value (eg, 1), the STA may or should transmit the buffer status of its p2p traffic in response to the trigger frame. When bit B39 is set to a second value (eg, 0), the STA may transmit its uplink (UL) traffic (eg, from the device 470 to The buffer status of the AP 460's UL traffic 472). Because the trigger frame utilizes the user information field, based on the user or STA (eg, the user or STA defined by the association ID in the AID12 subfield 521), this Trigger methods may or may not be used. For example, the user information list fields may include a plurality of user information fields (each of which has the user information field format 600), in which a first user information field may be directed to a first user information field. A user/STA (eg, device 470) indicates a p2p buffer status request, and a second user information field may indicate a UL buffer status request to a second user/STA (eg, device 490). In some embodiments, one or more defined/repurposed bits from any one or more fields (e.g., in addition to the user information field 600, or in addition to "the usage (Except the reserved bits "B39" of the User Information field) may be utilized to indicate to the STA its buffers containing data for its p2p traffic and/or other types of traffic (e.g., UL and/or DL) condition.

FIG. 7 depicts an example common information ("Common Info") field format 700 for indicating p2p traffic according to an example implementation of the present disclosure. The common information field format 700 may be the same as or similar to the common information field format 550 except for one sub-field 701 . In some embodiments, subfield 701 of the common information field format 700 may redefine the reserved bit 567 (see Figure 5C) to indicate a p2p buffer status request. In some embodiments, the subfield 701 may be a single bit (eg, bit B63 of the common information field format 700). When bit B63 is set in a trigger frame transmitted by an AP (e.g., AP 460), the trigger frame may indicate/request/trigger a STA (e.g., device 470) to utilize a BSR The program responds by including its buffer status for its p2p traffic (eg, p2p traffic 474 between the device 470 and the device 480 ). For example, when the bit B63 is set to a first value (eg, 1), the STA may or should transmit the buffer status of its p2p traffic in response to the trigger frame. When the bit B63 is set to a second value (eg, 0), the STA may transmit the buffer status of its uplink traffic in response to the trigger frame. Because the trigger frame utilizes the common information field, this trigger method can be used by all users or all STAs that receive the trigger frame (e.g., all STAs associated with the AP 460, including device 470 and device 490) are used (or triggered). In some embodiments, one or more defined/repurposed bits from any one or more fields (eg, in addition to the common information field) may be utilized to provide the STA with Indicates that it contains its buffer status for its p2p traffic and/or other types of traffic (eg, UL and/or DL).

FIG. 8 depicts an example trigger type subfield code 800 for indicating a BSR trigger frame for p2p traffic according to an example implementation of the present disclosure. In one approach, a new BSRP-p2p trigger frame can be defined to indicate a p2p buffer status request. A new trigger frame type 802 for p2p traffic, such as "BSRP-p2p trigger frame type" may be added/introduced/defined as the trigger type field in the common information field (e.g., in Figure A value used in the trigger type field 702) of the common information field 700 in 7. For example, a value such as 8 or any value not used by other types (eg, 8≤N≤15 when the trigger type subfield code 800 is used) may be utilized. In some embodiments, the frame format may be the same as or similar to the format of a BSRP trigger frame (eg, the trigger frame format as shown in Figures 5A, 5B, and 5C). When a STA (eg, device 470) receives a BSRP-p2p trigger frame from an AP (eg, AP 460) with the trigger type field set to the BSRP-p2p trigger frame type, the STAs can or should respond by utilizing a BSR procedure to include their buffer status for their p2p traffic.

FIG. 9 is a flowchart illustrating a process 900 for transmitting a request for buffer status data for p2p traffic according to an example implementation of the present disclosure. In some embodiments, the process 900 is executed through an access point (eg, AP 460 or a software-enabled AP (software AP)). In some embodiments, the process 900 is executed by other entities. In some embodiments, the process 900 includes more, fewer, or different steps than shown in FIG. 10 .

In one approach, the access point (eg, AP 460) may generate 902 a first frame (eg, a BSRP trigger frame containing the user information field format 600, a first frame containing the common BSRP trigger frame of message format 700, or a trigger frame with new BSRP-p2p type 802) to trigger a receiver device (e.g., device 470) to transmit a response frame (e.g., BSR response frame ), which includes buffer state data corresponding to wireless traffic (eg, p2p traffic 474) between the receiver device (eg, device 470) and another device (eg, device 480). In some embodiments, the wireless traffic may include point-to-point (p2p) traffic between the receiver device and the other device. In some embodiments, in generating the first frame, the access point may set a frame type field (eg, trigger type subfield 702) of the first frame to a type , which indicates a buffer status trigger frame (eg, BSRP type 592) because the first frame reuses/redefines the format of the existing BSR trigger type frame.

In some embodiments, the first frame (eg, a BSRP trigger frame including the user information field format 600) may include a first user information field related to a first Device (eg, user information field format 600, wherein the AID12 subfield is set to associate with the first device 470). In generating the first frame, the access point may set a subfield (eg, subfield 601) of the first user information field to a first value (eg, 1), It indicates a buffer status request for wireless traffic between the first device (eg, device 470) and a second device (eg, device 480). The first frame may include a second user information field related to a third device (e.g., user information field format 600, where the AID12 subfield is configured to associate with the third device). Device 490). In generating the first frame, the access point may set a subfield (eg, subfield 601) of the second user information field to a second value (eg, 0), It indicates a buffer status request for wireless traffic (e.g., UL/DL traffic 492) between the access point (e.g., AP 460) and the third device (e.g., device 490) to trigger The third device transmits a response frame containing information corresponding to the wireless traffic between the access point and the third device (e.g., UL traffic 492 from the third device 490) Buffer status information.

In some embodiments, the first frame (eg, a BSRP trigger frame including the common information format 700) may include a common information field that contains information related to multiple users or Receiver device information. In generating the first frame, the access point (eg, AP 460) may set a subfield (eg, subfield) of the common information field (eg, common information format 700) 701) is a value (eg, 1) that indicates a buffer status request for wireless traffic between the receiver device (eg, device 470) and the other device (eg, device 480).

In some embodiments, the first frame (eg, a BSRP trigger frame including the common information format 700) may include a common information field. In generating the first frame, the access point (eg, AP 460) may set a subfield (eg, subfield) of the common information field (eg, common information format 700) 701) is a value (e.g., 1) that triggers multiple user or receiver devices (e.g., device 470 and device 490) to transmit individual response frames containing individual buffers corresponding to peer-to-peer (p2p) traffic District status information.

In some embodiments, the first frame (eg, a trigger frame with new BSRP-p2p type 802) may include a frame type field (eg, trigger type subfield 702). In generating the first frame, the access point may set the frame type field to a type (eg, new BSRP-p2p type 802) that indicates a type for point-to-point (p2p) traffic. Buffer status trigger frame. The first frame may include a common information field that contains information related to multiple user or receiver devices (eg, device 470 and device 490). The frame type field may be a subfield of the common information field (eg, the trigger type subfield 702 of the common information field format 700).

In some embodiments, the first frame (e.g., a trigger frame with new BSRP-p2p type 802) may include a frame type field (e.g., a trigger for common information field format 700 Type subfield 702). In generating the first frame, the access point may set the frame type field to a type (e.g., new BSRP-p2p type 802) to trigger multiple users or receiver devices (e.g., new BSRP-p2p type 802). , device 470 and device 490) to transmit individual response frames containing individual buffer status data corresponding to wireless point-to-point (p2p) traffic.

In one approach, the access point (eg, AP 460) may wirelessly send 906 the generated first frame to one or more devices (eg, device 470) via a transmitter of the access point and device 490).

2. Provide buffer status reporting for wireless point-to-point (p2p) traffic

Figures 10A and 10B show two buffer status reporting procedures – (1) using a Quality of Service (QoS) control field format (Figure 10A) and (2) using an Aggregation Control (A-Control) subfield format ( Figure 10B).

Figure 10A depicts an example QoS control field format 1000 in accordance with an example implementation of the present disclosure. The QoS control field format 1000 may include sub-field 1001 (bits 0-3), sub-field 1002 (bit 4), sub-field 1003 (bits 5-6), sub-field 1004 (bits 5-6). Bit 7), and/or subfield 1005 (bits 8-15). A STA (e.g., device 470) can transmit the frame to an AP by specifying a queue size in a QoS control field in a frame (e.g., a QoS data frame or a QoS null frame). (e.g., AP 460) to report its buffer status. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP (e.g., AP 460), a receiver STA (e.g., device 470) may transmit a QoS data frame or a QoS Data CF (Content-Free)-ACK frame 1010 is sent to the AP to report buffer status data regarding UL traffic for a specific TID (Traffic Identifier). In the QoS control field of the message frame 1010, the STA may set (1) the subfield 1001 to a TID; (2) the subfield 1002 to 1; (3) the subfield Bit 1003 is an Ack policy indicator; (4) the subfield 1004 is a value indicating that an A-MSDU (aggregated MAC Service Data Unit) is present; and/or (5) the subfield 1005 is a queue size for UL traffic for the TID set in subfield 1001. In response to a buffer status report request from the AP, a receiver STA may transmit a QoS empty frame 1020 to the AP to report buffer status information regarding UL traffic for a particular TID. In the QoS control field of the message frame 1020, the STA may set (1) the subfield 1001 to a TID; (2) the subfield 1002 to 1; (3) the subfield Bit 1003 is an Ack policy indicator; and/or (4) the subfield 1005 is a queue size for UL traffic for the TID set in the subfield 1001 . For a QoS empty frame, the subfield 1004 may not be used (or may be "reserved") in reporting buffer status information.

10B depicts an example format of an Aggregation Control (A-Control) subfield 1050 of a control field for BSR control, according to an example implementation of the present disclosure. A high efficiency (HE) variant of the high throughput (HT) control field of the A-control subfield format 1050 may include a plurality of HE controls 1060 (including HE control-1 1060-1, HE control-2 1060 -2,...,1060-N) and a slot that fills 1061. Each HE control may contain fields for a control ID 1070 and control information 1080 . For a BSR response, the control ID field 1070 may be set to a value (eg, 3) indicating the BSR (see Table 1). The control information field (or BSR control field) 1080 may include the ACI (access type identifier) bitmap 1081, delta TID 1082, ACI height 1083, scaling factor 1084, queue size height 1085, and/ Or queue all subfields with size 1086. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP (e.g., AP 460), a receiver STA (e.g., device 470) may respond by Specify a queue size in the Size All subfield 1086 and send the frame to the AP to report its buffer status. The queue size may be reported for the ACI indicated in the ACI bitmap subfield 1081, which indicates the type of access required for the data stored in the STA's buffer. ). Each bit of the ACI bitmap subfield 1081 may indicate the existence of a service intended for a corresponding AC. A value set in the delta TID subfield 1082 may indicate the number of TIDs corresponding to the number of bits set to 1 in the ACI bitmap subfield 1081 . For example, if (1) the number of bits set to 1 in the ACI bitmap subfield is equal to 1, and (2) the delta TID is set to a value of 1, then the delta TID may refer to 2 TIDs. If the number of bits set to 1 in the ACI bitmap subfield is equal to 0, the values 0 to 2 in the delta TID may not be applicable, for example the number of TIDs may not be indicated. A value set in the Queue Size All subfield 1086 may indicate/report a combined queue size for all ACs indicated in the ACI bitmap subfield 1081 . A value set in the queue size high subfield 1085 may indicate/report a queue size for the ACI indicated in the ACI high subfield 1083. Control ID value meaning Control the length of the information subfield (bits) 0 Triggered response schedule (TRS) 26 1 Operating mode (OM) 12 2 HE Link Adaptation (HLA) 26 3 Buffer Status Report (BSR) 26 4 UL power headroom (UPH) 8 5 Bandwidth Query Report (BQR) 10 6 Command and Status (CAS) 8 7-14 reserved 15 Expanders Are Really Needed (ONES) 26 Table 1. Control ID subfield values

A WLAN protocol (eg, 802.11be) may define a TWT mechanism, such as Restricted TWT (R-TWT). In a TWT mechanism, STAs can adopt a wake-up time schedule that causes them to wake up periodically to send/receive data. R-TWT can force all other 802.11be compliant devices to complete/terminate their transmissions before the start of a TWT Service Period (SP). R-TWT can be used to provide priority access and medium access protection to a STA's p2p traffic. This TWT mechanism (eg, R-TWT) may require the ability to report buffer status for a STA's p2p traffic to perform efficiently. For example, an AP may allocate resources according to the buffer status for p2p traffic to the STA during an R-TWT SP. During an ongoing SP, if the AP can query the status of a STA's p2p traffic, it will facilitate efficient operation (eg, help the AP allocate resources efficiently). For example, a STA may indicate an empty buffer for p2p to the AP to indicate that the STA has completed delivering delay-sensitive traffic (LST). A TWT SP can be terminated to save power so the AP can serve other STAs. The STA may point a non-empty buffer for p2p to the AP near the end of an SP to convey that the STA still has LSTs. The SP may be extended to deliver the remaining buffered traffic. The AP itself can also query the buffer status to make this easy.

The conventional buffer status reporting mechanism can only report the buffer status for one STA's uplink traffic. STAs are unable to report buffer status for their p2p traffic. For example, a QoS control field (see Figure 10A) in the QoS data frame and/or QoS null frame cannot indicate or report the buffer status of p2p traffic. A BSR control field (see Figure 10B) within an A-control subfield of a HE variant of the HT control field (see Figure 10B) cannot indicate or report the buffer status of p2p traffic. There is a need/benefit to define a new request method for STAs to report the buffer status of p2p traffic to the AP.

To solve this problem, a QoS control field (e.g., QoS control field 1000) or a BSR control field (e.g., control information subfield 1080) can be redefined/repurposed to indicate the specific requirements for p2p traffic. Buffer status (report). In some embodiments, a BSR control field (or other field) may be modified or redefined to indicate (reporting of) p2p traffic. The BSR control subfields may have invalid value combinations based on certain subfield encodings. For example, according to a Delta TID encoding, set the ACI bitmap subfield (or other subfield/bit) to 0 and the delta TID subfield (or other subfield/bit) to 0 May be an invalid combination. The encoding may be modified or redefined such that when (1) the ACI bitmap subfield (or other subfield/bit) is set to 0, and (2) the delta TID subfield (or other subfield/bit) is set to 0 or any inapplicable number (e.g., a value of 0 to 2) in the ACI bitmap subfield and the delta TID subfield The combination of the values may indicate that the buffer status reported in the 'queue size all' subfield is for a STA's p2p traffic. In this example, the ACI high subfield (or other subfield/bit) and the queue size high subfield (or other subfield/bit) may be retained. In some embodiments, the 'queue size all' subfield and the queue size high subfield (or other subfields/bits) may be combined into a single queue size subfield (e.g. , a 16-bit queue size subfield). In this example, the ACI high subfield (or other alternative subfield/bit) may be retained.

In some embodiments, a QoS control field (or other fields/bits) in the QoS data frame and QoS air frame may be modified or redefined to indicate (reporting of) p2p traffic. According to some definitions of the QoS control field, when a STA transmits a QoS empty frame containing a QoS control field, in which bit 4 is set to 1, the bits of the QoS control field 7 may be reserved, and bits 8-15 of the QoS control field may indicate a queue size. In some embodiments, the QoS control field bits (or other fields/bits) may be modified or redefined. For example, when bit 4 is set to 1 and bit 7 is set to 0, the queue size may be for a STA's UL (uplink) traffic that belongs to bits 0-3. TID. When bit 4 is set to 1 and bit 7 is set to 1, the queue size may be for p2p traffic of the STA, and the TID subfield (bits 0-3) and bit 5 -7 may be retained as a non-limiting example.

In some embodiments, a new (type of) BSR-p2p control field, such as a BSR-p2p control field (or other fields/bits) may be added and defined for the HE variant A-control subfield (or other subfield) of the HT control field (or other field). A new control ID can be defined/used to indicate a BSR-p2p frame. For example, a control ID value of 7 or any other available value (eg, 8 to 14 reserved in Table 1) can be redefined and utilized. See Table 2, which contains the new control ID values. The format of the new control field may include a scaling factor subfield (eg, 2 bits) and a queue size subfield (eg, 8 bits). The Scale Factor (SF) subfield (or other subfield/bit) may define an SF byte, and the Queue Size subfield (or other subfield/bit) may indicate the SF byte. The amount of buffered p2p traffic, in bytes (eg, according to the definition of SF bytes as shown in Table 3), intended for the STA's peer STAs on the p2p link. Control ID value meaning Control the length of the information subfield (bits) 0 Triggered response schedule (TRS) 26 1 Operating mode (OM) 12 2 HE Link Adaptation (HLA) 26 3 Buffer Status Report (BSR) 26 4 UL power headroom (UPH) 8 5 Bandwidth Query Report (BQR) 10 6 Command and Status (CAS) 8 7 Buffer status report (BSR-p2p) for p2p traffic 16 8-14 reserved 15 Expanders Are Really Needed (ONES) 26 Table 2. Control ID subfield values (add new control ID values) The value in the Scale Factor subfield Scaling factor SF (bytes) 0 16 1 256 2 2048 3 32768 Table 3. Scaling factor subfield coding

In one approach, a first device may include one or more processors. The one or more processors may be configured to generate a first frame containing buffer status data corresponding to wireless traffic between the first device and a second device. Each of the first device and the second device may not be an access point. The one or more processors may be configured to wirelessly send the generated first frame via a transceiver to an access point in a wireless local area network (WLAN).

In one approach, the one or more processors may be further configured to wirelessly receive a second frame via the transceiver from the access point. In response to the second frame, the one or more processors may be configured to generate the first frame.

In one approach, the wireless traffic may include point-to-point (p2p) traffic between the first device and the second device. In some embodiments, the first frame may include a control identifier field. In generating the first frame, the one or more processors may be configured to set the control identifier field to a value indicating a buffer status report frame.

In one approach, the first frame may include a bitmap field including a plurality of bits corresponding to a plurality of access types. In generating the first frame, the one or more processors may be configured to set each of the plurality of bits to a first value indicating that there is no one corresponding to the bit. Access type related traffic.

In one approach, the first frame may include a traffic identifier number field indicating a number of traffic identifiers for buffered traffic. In generating the first frame, the one or more processors may be configured to set the traffic identifier number field to a second value that indicates the number of traffic identifiers for buffered traffic. The quantity is zero.

In one approach, the first frame may include a quality of service (QoS) control field including a first field. In generating the first frame, the one or more processors may be configured to set the first field to a value indicating the presence of wireless point-to-point (p2p) traffic. The QoS control field includes a second field. In generating the first frame, the one or more processors may be configured to set the second field to a value that indicates the distance between the first device and the second device. A queue size for the wireless traffic.

In one approach, the first frame may include a control identifier field. In generating the first frame, the one or more processors may be configured to set the control identifier field to a value indicating a point-to-point (p2p) buffer status report frame. The first frame may include a queue size field. In generating the first frame, the one or more processors may be configured to set the queue size field to a value indicating a distance between the first device and a second device. A queue size for the wireless traffic.

Embodiments in the present disclosure have at least the following advantages and benefits. Embodiments in this disclosure may provide useful techniques for STAs to report the buffer status of their p2p traffic. In some embodiments, a QoS control field (eg, QoS control field 1000 in FIG. 10A) or a BSR control field (eg, control information subfield 1080 in FIG. 10B) may be Redefine/repurpose to indicate buffer status for p2p traffic, thereby defining a new request method for STAs to report buffer status for p2p traffic to the AP.

11 depicts an example format of a control information subfield (or BSR control subfield) 1100 of an A-control subfield for reporting on p2p traffic, according to an example implementation of the present disclosure. Buffer status. The control information field (or BSR control field) 1100 may include ACI bitmap 1101, delta TID 1102, ACI height 1103, scaling factor 1104, queue size height 1105, and/or queue size 1106 in total. field. In some embodiments, the BSR control subfield (or other fields) 1100 may be modified or redefined to indicate (reporting of) p2p traffic. The BSR control subfields may have invalid value combinations based on certain subfield encodings. For example, according to a Delta TID encoding, set the ACI bitmap subfield (or other subfield/bit) to 0 and the delta TID subfield (or other subfield/bit) to 0 -2 may be an invalid combination. The encoding may be modified or redefined such that when (1) the ACI bitmap subfield 1101 (or other subfield/bit) is set to 0 and (2) the delta TID subfield 1102 (or other subfield/bit) is set to 0 or any previously inapplicable number M (e.g., 0 ≤ M ≤ 2), the ACI bitmap subfield and the delta TID subfield The combination of values in the fields may indicate that the buffer status reported in the queue size subfield 1106 is for a STA's p2p traffic. In this example, the ACI high subfield 1103 (or other subfields/bits) and the queue size high subfield 1105 (or other subfields/bits) may be retained. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP (e.g., AP 460), a receiver STA (e.g., device 470) may report its response to and from a peer device (e.g., device 470). For example, device 480) buffer status for p2p traffic by (1) setting the ACI bitmap subfield 1101 and delta TID subfield 1102 of a frame to 0, (2) setting the frame's Specify a queue size for the p2p traffic in the Queue Size All subfield 1106, and (3) transmit the frame to the AP. In some embodiments, the queue size all subfield 1106 and the queue size high subfield 1105 (or other subfields/bits) may be combined into a single queue size subfield (e.g., , a 16-bit queue size subfield). In this example, the ACI high subfield 1103 (or other alternative subfields/bits) may be retained.

Figure 12 depicts an example QoS control field format 1200 for reporting buffer status for p2p traffic, in accordance with an example implementation of the present disclosure. The QoS control field format 1200 may include sub-field 1201 (bits 0-3), sub-field 1202 (bit 4), sub-field 1203 (bits 5-6), sub-field 1204 (bits 5-6). Bit 7), and/or subfield 1205 (bits 8-15). In some implementations, a QoS control field (or other fields/bits) in the QoS data frame and QoS air frame may be modified or redefined to indicate (reporting of) p2p traffic. According to certain definitions of the QoS control field (eg, QoS control field 1000 in Figure 10A), when a STA transmits a QoS empty frame (eg, QoS empty frame 1020) that includes a QoS control field ), where bit 4 (e.g., subfield 1002) is set to 1, bit 7 of the QoS control field (e.g., subfield 1004) may be reserved, and the QoS control field Bits 8-15 (eg, subfield 1005) may indicate a queue size. In some embodiments, the bits of the QoS control field (or other fields/bits) may be modified or redefined. Referring to Figure 12, when the subfield 1202 (bit 4) of a QoS empty frame 1220 is set to 1, and the subfield 1204 (bit 7) of the QoS empty frame 1220 is set to 0, The queue size set in the subfield 1205 may be for UL traffic of a STA belonging to the TID indicated in the subfield 1201 (bits 0-3). When the subfield 1202 (bit 4) is set to 1 and the subfield 1204 (bit 7) is set to 1, the queue size may be p2p traffic for the STA, And the TID subfield 1201 (bits 0-3) and the subfield 1203 (bits 5-6) can be reserved as a non-limiting example. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP (e.g., AP 460), a receiver STA (e.g., device 470) may report its response to and from a peer device (e.g., device 470). For example, the buffer status of p2p traffic of device 480) is determined by (1) setting subfield 1202 (bit 4) and subfield 1204 (bit 7) of a QoS null frame to 1 and (2) ) specify a queue size for the p2p traffic in subfield 1205 (bits 8-15) of the QoS air frame, and (3) transmit the QoS air frame to the AP.

Figure 13 depicts an example format of an A-control subfield 1300 of a control field for reporting buffer status for p2p traffic, in accordance with an example implementation of the present disclosure. The A-control subfield format 1300 of a HE-morphed HT control field may include a plurality of HE controls 1310 (including HE Control-1 1310-1, HE Control-2 1310-2, ..., 1310-N) and a Fill the slot of 1311. Each HE control may include fields for a control ID 1320 and control information 1330 . In some embodiments, a new (type of) BSR-p2p control field, such as a BSR-p2p control field (or other fields/bits) may be added and defined for the HE variant A-control subfield (or other subfield) of the HT control field (or other field). A new control ID can be defined/used to indicate a BSR-p2p frame. For example, a control ID value of 7 or any other available value (eg, 8 to 14 reserved in Table 1) can be re/explicitly defined and used. See Table 2 which contains the new/specific control ID values. For BSR-p2p responses, the control ID field 1320 may be set to a new/specific value (eg, 7), which indicates BSR-p2p (see Table 2). The control information fields (or BSR control fields) 1330 may include subfields for scaling factor 1331, queue size 1332, and/or reserved 1333. In some implementations, the scaling factor subfield 1331 may be 2 bits and the queue size subfield 1332 may be 8 bits. The scaling factor (SF) subfield 1331 may define SF bytes, and the queue size subfield 1332 may indicate the amount of buffered p2p traffic in units of SF bytes (e.g., based on The definition of the SF byte shown in Table 3) is intended for the STA's peer STA on the p2p link. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP (e.g., AP 460), a receiver STA (e.g., device 470) may report its response to and from a peer device (e.g., device 470). For example, device 480) buffer status for p2p traffic by (1) setting a frame's control ID subfield 1320 to the new value indicating BSR-p2p, (2) setting the frame's control ID subfield 1320 to Specify a queue size for the p2p traffic in the queue size subfield 1332, and (3) transmit the frame to the AP.

14 is a flowchart illustrating a process 1400 for reporting buffer status for p2p traffic according to an example implementation of the present disclosure. In some embodiments, the process 1400 is executed by a first device (eg, STA device 470 or 490). In some embodiments, the process 1400 is executed by other entities. In some embodiments, the process 1400 includes more, fewer, or different steps than shown in FIG. 14 .

In one approach, the first device (e.g., device 470) may generate 1402 a first frame (e.g., a frame including a control information subfield 1100, a QoS An empty frame, a frame containing an A-Control subfield 1300 for reporting buffer status for p2p traffic), which contains a message corresponding to a link between the first device (e.g., device 470) and a Buffer status data for wireless traffic (eg, p2p traffic 474) between a second device (eg, device 480). Each of the first device and the second device may not be an access point.

In some embodiments, the first device may receive a second frame wirelessly via a transceiver from an access point (e.g., AP 460) (e.g., as shown in Figures 5A-8 BSRP trigger frame). In response to the second frame, the first device may generate the first frame. In some embodiments, the wireless traffic may include point-to-point (p2p) traffic between the first device and the second device (eg, p2p traffic 474). In some embodiments, the first frame may include a control identifier field (eg, control ID subfield 1070). In generating the first frame, the first device may set the control identifier field to a value indicating a buffer status report frame (e.g., as shown in Tables 1 and 2, A value of 3 indicates BSR) as this method reuses/redefines the existing A-control subfield format for reporting buffer status for UL/DL traffic.

In some embodiments, the first frame (eg, a frame containing a control information subfield 1100) may include a bitmap field (eg, ACI bitmap 1101) that contains the corresponding A plurality of bits in a plurality of access types. In generating the first frame, the first device may set each of the plurality of bits to a first value (eg, 0) indicating that there is not a memory corresponding to the bit. Get type-related traffic. The first frame may include a traffic identifier number field (eg, delta TID 1102) that indicates a number of traffic identifiers for buffered traffic. In generating the first frame, the first device may set the traffic identifier number field to a second value (eg, 0) that indicates the number of traffic identifiers for buffered traffic. is zero.

In some embodiments, the first frame may include a quality of service (QoS) control field (eg, QoS control field 1200) that includes a first field (eg, subfield 1204). In generating the first frame, the first device may set the first field (eg, subfield 1204) to a value (eg, 1) that indicates the presence of wireless point-to-point (p2p) traffic . The QoS control field includes a second field (eg, subfield 1205). In generating the first frame, the first device may set the second field (e.g., subfield 1205) to a value that indicates when the first device (e.g., device 470) and A queue size for wireless traffic (eg, p2p traffic 474) between the second device (eg, device 480).

In some embodiments, the first frame may include a control identifier field (eg, control ID 1320). In generating the first frame, the first device may set the control identifier field to a value (eg, a value of 7) that indicates a point-to-point (p2p) buffer status report frame (see table 2). The first frame may include a queue size field (eg, queue size 1332). In generating the first frame, the first device may set the queue size field to a value that indicates a gap between the first device (e.g., device 470) and a second device (e.g., A queue size for wireless traffic (e.g., p2p traffic 474) between devices 480).

In one approach, the first device may wirelessly send 1404 the generated first frame to an access point in a wireless local area network (WLAN) via a transceiver of the first device. For example, AP 460).

Having now described certain illustrative embodiments, it is apparent that the foregoing is illustrative and not limiting, having been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts and those elements may be combined in other ways to achieve the same goals. Acts, components, and features discussed with respect to one embodiment are not intended to be excluded from similar roles in other embodiments.

The hardware and data processing components used to implement the various processes, operations, illustrative logic, logic blocks, modules and circuits described in connection with the embodiments disclosed herein may utilize general purpose single or multi-chip processing. processor, digital signal processor (DSP), application special integrated circuit (ASIC), field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete Implemented or performed by hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some embodiments, specific procedures and methods may be performed by circuitry dedicated to a given function. The memory (e.g., memory, memory unit, storage device, etc.) may include one or more devices (e.g., RAM, ROM, flash memory, hard disk storage, etc.) for Store information and/or computer code used to implement or facilitate the various processes, layers and modules described in this disclosure. The memory may be or include volatile memory or non-volatile memory, and may include database components, object code components, text components, or any other type of information structure for supporting the content in this disclosure. The various activities and information structures described in . According to an example embodiment, the memory is communicatively connected to the processor via processing circuitry and includes computer code for execution (e.g., by the processing circuitry and/or the processor) on one or more of the procedures described here.

This disclosure contemplates methods, systems, and program products on any machine-readable medium for performing various operations. Embodiments of the present disclosure may be implemented using existing computer processors, or with special purpose computer processors incorporated for this or other purposes in suitable systems, or with hardwired systems. Embodiments within the scope of the present disclosure include program products that include machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general or special purpose computer, or other machine with a processor. For example, such machine-readable media may include RAM, ROM, EPROM, EEPROM, or other optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other media that may be utilized Contains or stores the required program code in the form of machine-executable instructions or data structures that can be accessed by a general-purpose or special-purpose computer, or other machine with a processor. The above combinations are also included in the category of machine-readable media. Machine-executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing machine to perform a certain function or group of functions.

The phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of "comprises", "includes", "having", "contains", "involving", "characterized by", "characterized by" and variations thereof herein are meant to cover the items listed thereafter, their Equivalents, additional items, and alternative embodiments consist only of the items listed next. In one embodiment, the systems and methods described herein are composed of one, every combination of more than one, or all of the elements, actions, or components.

Any singular reference herein to an embodiment or element or act of the systems and methods described may also encompass embodiments that include a plurality of such elements, and any plural reference herein to any embodiment or element or act may also encompass Includes embodiments containing only a single element. References to the singular or plural form are not intended to limit the presently disclosed system or method, its components, actions, or elements to a single or plural configuration. References to any act or element based on any information, act, or element may include implementations in which the act or element is based, at least in part, on any information, act, or element.

Any embodiment disclosed herein may be combined with any other embodiment or example, and references to "an embodiment," "certain embodiments," "an embodiment," or the like are not necessarily mutually exclusive. , and it is intended to point out that a specific feature, structure or characteristic described in relation to the described embodiments may be included in at least one embodiment or example. Such terms as used herein are not necessarily all referring to the same embodiment. Any embodiment may be included or exclusively combined with any other embodiment in any manner consistent with the features and embodiments disclosed herein.

In the case where a technical feature in the drawings, detailed description, or any claim is followed by an element symbol, the element symbol is added to increase the understandability of the drawing, detailed description, and claim. Thus, the presence or absence of the reference symbol does not have any limiting effect on the scope of any claim element.

The systems and methods described herein may be embodied in other specific forms without departing from their characteristics. Unless expressly stated otherwise, references to terms such as "approximately", "approximately", "substantially" or other degrees include a variation of +/-10% from the given measure, unit or range. Coupled components may be electrically, mechanically, or physically coupled to each other directly or through intervening components. Accordingly, the scope of the systems and methods described herein is indicated by the appended claims, rather than the preceding description, and changes that fall within the equal meaning and scope of the claims are intended to be embraced. included in it.

The term "coupled" and its variations are intended to encompass the direct or indirect engagement of two components with each other. Such engagement may be static (eg, permanent or fixed), or removable (eg, removable or releasable). Such joining may occur where the two members are coupled directly to each other or to each other, where the two members are coupled to each other by a separate intervening member, and any additional intermediate members that are coupled to each other. and coupled to each other, or where the two members are coupled to each other using an intervening member that is integrally formed as a single body with one of the two members. achieved. If "coupled" or its variations are modified by an additional term (e.g., directly coupled), then the upper definition of "coupled" set forth above is the ordinary language meaning of the additional term. (For example, "directly coupled" means the joining of two components without any individually intervening components) This results in a narrower definition than the general definition of "coupled" proposed above. Such coupling may be mechanical, electrical, or fluid.

References to "or" are to be construed as inclusive such that any item recited with "or" may refer to either a single, more than one, or all of the item. References to "at least one of 'A' and 'B'" may include only 'A', only 'B', and both 'A' and 'B'. Such references used in conjunction with "including" or other open-ended terms may include additional items.

Modifications of the components and actions, such as changes in the size, dimensions, structure, shape and proportion, parameter values, installation configurations, use of materials, colors, and orientations of various components, may be made without materially departing from the subject matter disclosed herein. Produced based on the teachings and advantages. For example, elements shown as integrally formed may be constructed from multiple parts or elements, the positions of elements may be reversed or varied, and the nature or number or position of discrete elements may be altered or varied. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and configuration of the disclosed components and operations without departing from the scope of the present disclosure.

References herein to the position of elements (eg, "top," "bottom," "above," "below") are only used to describe the orientation of the various elements in the drawings. The orientation of various elements may be different according to other example embodiments, and such variations are intended to be covered by this disclosure.

100: Artificial reality system environment 101:Link 110:Console 115: Communication interface 130:Content provider 150:Head Mounted Display (HWD) 155: Sensor 160, 160A, 160B: Eye tracker 162:Hand Tracker 165: Communication interface 170:Image imager 175: Electronic display 180:Lens 185:Compensator 205: Front rigid body 210: Strip 314:Computing Systems 316: Processor 318:Storage device 320:Network interface 322: User input device 324:User output device 402: BSRP trigger frame 404: Short space between frames (SIFS) 406: High Efficiency (HE) Trigger-Based (TB) Uplink (UL) Aggregated MAC Protocol Data Unit (A-MPDU) Frame 408: Short inter-frame space (SIFS) 410:Multi-STA block acknowledgment (M-BA) frame 460:AP device 470: First non-AP STA device 472: UL/DL (downlink) traffic 474:p2p traffic 480: Second non-AP device 490: Third non-AP STA device 492:UL/DL traffic 500: BSR trigger frame format 501: Message frame control 502: Duration 503:Receiver address 504: Transmitter address 505: fill position 506: Frame Check Sequence (FCS) 510: User information list 520: User information ("User Info") field format 521: Association identifier (AID12) 522: RU (resource unit) allocation 523:UL FEC (forward error correction) encoding type 524:UL HE-MCS (modulation coding design) 525:UL DCM (dual carrier modulation) 526:SS (spatial streaming) allocation/RA-RU information 527:UL target received power 528: reserved 529:Trigger dependent user information 550: Common information ("Common Info") 551:Trigger type 552:UL length 553: More TF (trigger frame) 554: CS (carrier sensing) required 555:UL BW (bandwidth) 556: GI (guard interval) and LTF (long training field) types 557:MU (Multiple User)-MIMO (Multiple Input Multiple Output) HE-LTF mode 558:HE-LTF symbol number and intermediate code period 559:UL STBC (space-time block coding) 560: LDPC (Low Density Parity Check) extra symbol field 561:AP Tx power 562: Filling factor before FEC 563: PE (Packet Extensions) Disambiguation 564:Reuse of UL space 565:Dubler 566: UL HE-S1G-A2 reserved 567: reserved 568:Trigger common information that depends on each other 590: Trigger type subfield code 592:Project 600: User information field format 601: Subfield 700: Common information field format 701:Subfield 702: Trigger type field 800: Trigger type subfield code 802: Trigger frame type 900:Program 902: Step 906:Step 1000: QoS control field format 1001:Subfield 1002:Subfield 1003:Subfield 1004:Subfield 1005:Subfield 1010: QoS data CF (no contention)-ACK frame 1020: QoS empty message frame 1050: Aggregation control (A-control) subfield 1060:HE control 1060-1:HE control-1 1060-2:HE Control-2 1060-N:HE control-N 1061:fill 1070:Control ID 1080:Control information 1081:CI (access type identifier) bitmap 1082:deltaTID 1083:ACI high 1084: scaling factor 1085:queue size high 1086: Queue size full 1100: Control information subfield/BSR control subfield 1101:ACI bitmap 1102:deltaTID 1103:ACI high 1104: scaling factor 1105:queue size high 1106: Queue size full 1200: QoS control field format 1201: Subfield 1202:Subfield 1203:Subfield 1204:Subfield 1205:Subfield 1220: QoS empty message frame 1300:A-Control subfield format 1310:HE control 1310-1:HE control-1 1310-2:HE Control-2 1310-N:HE control-N 1311:fill 1320:Control ID 1330:Control information 1331: scaling factor 1332:queue size 1333: reserved 1400:Program 1402: Steps 1404: Step

The accompanying drawings are not intended to be drawn to scale. The same reference symbols and nomenclature used in the various drawings identify similar components. For purposes of clarity, not every component may be labeled in every figure.

[FIG. 1] is a diagram of a system environment including an artificial reality system according to an example implementation of the present disclosure.

[FIG. 2] is a diagram of a head wearable display according to an example embodiment of the present disclosure.

[FIG. 3] is a block diagram of a computing environment according to an example implementation of the present disclosure.

[FIG. 4A] is a diagram of a buffer status report (BSR) request and BSR response according to an example implementation of the present disclosure.

[FIG. 4B] is a diagram of a system environment including peer-to-peer (p2p) traffic in a wireless local area network (WLAN), in accordance with an example implementation of the present disclosure.

[FIG. 5A], [FIG. 5B], and [FIG. 5C] depict an example buffer status report polling (BSRP) trigger frame format according to an example implementation of the present disclosure.

[FIG. 5D] depicts an example trigger type subfield encoding according to an example implementation of the present disclosure.

[FIG. 6] depicts an example user information field format for indicating peer-to-peer (p2p) traffic, in accordance with an example implementation of the present disclosure.

[FIG. 7] depicts a common information field format for indicating an example of p2p traffic according to an example implementation of the present disclosure.

[FIG. 8] depicts an example trigger type subfield code for indicating a BSR trigger frame for p2p traffic according to an example implementation of the present disclosure.

[Fig. 9] is a flowchart illustrating a procedure for transmitting a request for buffer status data for p2p traffic according to an example implementation of the present disclosure.

[FIG. 10A] depicts an example quality of service (QoS) control field format according to an example implementation of the present disclosure.

[FIG. 10B] depicts an example format of an Aggregation Control (A-Control) subfield of a control field for BSR control, according to an example implementation of the present disclosure.

[FIG. 11] Depicts an example format of a control information subfield of an A-control subfield for reporting buffer status for p2p traffic according to an example implementation of the present disclosure.

[Figure 12] depicts an example QoS control field format for reporting buffer status for p2p traffic, in accordance with an example implementation of the present disclosure.

[FIG. 13] depicts an example format of an A-Control subfield of a control field for reporting buffer status for p2p traffic, in accordance with an example implementation of the present disclosure.

[FIG. 14] is a flowchart illustrating a procedure for reporting buffer status for p2p traffic according to an example implementation of the present disclosure.

900:Program

902: Step

906:Step

Claims (20)

An access point that includes: One or more processors configured to: Generating a first frame to trigger a receiver device to transmit a response frame including buffer status data corresponding to wireless traffic between the receiver device and another device; and The generated first frame is wirelessly sent to one or more devices via a transmitter. The access point of claim 1, wherein the wireless traffic includes point-to-point (p2p) traffic between the receiver device and the other device. The access point of claim 1, wherein in generating the first frame, the one or more processors are configured to: Set the frame type field of the first frame to indicate the type of buffer status triggering frame. For example, request the access point of item 1, where: The first frame includes a first user information field related to the first device, and In generating the first frame, the one or more processors are configured to: Set a subfield of the first user information field to a first value indicating a buffer status request for wireless traffic between the first device and a second device. For example, request the access point of item 4, where: The first frame includes a second user information field related to the third device, and In generating the first frame, the one or more processors are configured to: Set a subfield of the second user information field to a second value indicating a buffer status request for wireless traffic between the access point and the third device to trigger the third The third device transmits a response frame including buffer status data corresponding to the wireless traffic between the access point and the third device. For example, request the access point of item 1, where: the first frame includes common information fields containing information related to a plurality of users or receiver devices, and In generating the first frame, the one or more processors are configured to set a sub-field of the common information field to indicate a connection between the receiver device and the other device. The value of the buffer status request for wireless traffic. For example, request the access point of item 1, where: the first frame contains common information fields, and In generating the first frame, the one or more processors are configured to set subfields of the common information field to trigger a plurality of users or receiver devices to transmit respective response frames. value, the individual response frames include individual buffer status data corresponding to peer-to-peer (p2p) traffic. For example, request the access point of item 1, where The first frame includes a frame type field, and In generating the first frame, the one or more processors are configured to: Set the frame type field to indicate the type of buffer status triggering frame for peer-to-peer (p2p) traffic. For example, the access point of request item 8, where the first frame includes common information fields containing information related to a plurality of users or receiver devices, and The frame type field is a subfield of the common information field. For example, request the access point of item 1, where The first frame includes a frame type field, and In generating the first frame, the one or more processors are configured to: Setting the frame type field to a type that triggers multiple users or receiver devices to transmit individual response frames including individual buffer status corresponding to wireless point-to-point (p2p) traffic material. A method including: Generating a first frame by the access point to trigger a receiver device to transmit a response frame including buffer status data corresponding to wireless traffic between the receiver device and another device; and The generated first frame is wirelessly sent to one or more devices via a transmitter of the access point. The method of claim 11, wherein the wireless traffic includes point-to-point (p2p) traffic between the receiver device and the other device. The method of claim 11, wherein generating the first frame includes: Set the frame type field of the first frame to indicate the type of buffer status triggering frame. Such as the method of request item 11, wherein: The first frame includes a first user information field related to the first device, and Generating the first frame includes: Set a subfield of the first user information field to a first value indicating a buffer status request for wireless traffic between the first device and a second device. Such as the method of request item 14, wherein: The first frame includes a second user information field related to the third device, and Generating the first frame includes: Set a subfield of the second user information field to a second value indicating a buffer status request for wireless traffic between the access point and the third device to trigger the third The third device transmits a response frame including buffer status data corresponding to the wireless traffic between the access point and the third device. Such as the method of request item 11, wherein: the first frame includes common information fields containing information related to a plurality of users or receiver devices, and Generating the first frame includes setting a subfield of the common information field to a value indicating a buffer status request for wireless traffic between the receiver device and the other device. Such as the method of request item 11, wherein: the first frame contains common information fields, and Generating the first frame includes: Set subfields of the common information field to values that trigger multiple users or receiver devices to send individual response frames, the individual response frames including individual response frames corresponding to peer-to-peer (p2p) traffic. Buffer status data. Such as the method of request item 11, wherein The first frame includes a frame type field, and Generating the first frame includes: Set the frame type field to indicate the type of buffer status triggering frame for peer-to-peer (p2p) traffic. Such as the method of request item 18, where the first frame includes common information fields containing information related to a plurality of users or receiver devices, and The frame type field is a subfield of the common information field. Such as the method of request item 11, wherein The first frame includes a frame type field, and Generating the first frame includes: Setting the frame type field to a type that triggers multiple users or receiver devices to transmit individual response frames including individual buffer status corresponding to wireless point-to-point (p2p) traffic material.