SYSTEMS AND METHOD FOR EARLY TERMINATION INDICATION OF TARGET WAKE TIME (TWT) SERVICE PERIOD (SP)

A first device may include one or more processors. The one or more processors may be configured to generate, during a service period of a target wake time (TWT) schedule, a first frame indicating, to an access point in a wireless local area network (WLAN), that the first device is ready to terminate the service period. The one or more processors may be configured to wirelessly transmit, via a transceiver, the generated first frame to the access point.

FIELD OF DISCLOSURE

The present disclosure is generally related to communications, including but not limited to systems and methods of indicating early termination of a target wake time (TWT) service period (SP).

BACKGROUND

Artificial reality, such as a virtual reality (VR), an augmented reality (AR), or a mixed reality (MR), provides immersive experience to a user. In one example, a user wearing a head wearable display (HWD) can turn the user's head to one side, and an image of a virtual object corresponding to a location and/or an orientation of the HWD and a gaze direction of the user can be displayed on the HWD to allow the user to feel as if the user is moving within a space of an artificial reality (e.g., a VR space, an AR space, or a MR space). An image of a virtual object may be generated by a computing device communicatively coupled to the HWD. In some embodiments, the computing device may have access to a network.

SUMMARY

Various embodiments disclosed herein are related to a first device including one or more processors. In some embodiments, the one or more processors may be configured to generate, during a service period of a target wake time (TWT) schedule, a first frame indicating, to an access point in a wireless local area network (WLAN), that the first device is ready to terminate the service period. The one or more processors may be configured to wirelessly transmit, via a transceiver, the generated first frame to the access point.

In some embodiments, the first frame may include a quality of service (QOS) control field that includes 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 that the first device is ready to terminate the service period. The first frame may be a QoS null frame. The first field may be a bit included in the QoS control field.

In some embodiments, the first frame may include a second field indicating a buffer size of traffic corresponding a traffic identifier (TID). In generating the first frame, the one or more processors may be configured to set the second field to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the first frame may include a third field indicating a total buffer size of traffic corresponding a plurality of TIDs. In generating the first frame, the one or more processors are configured to set the third field to a value indicating that the first device is ready to terminate the service period.

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

Various embodiments disclosed herein are related to an access point including one or more processors and/or a transceiver. In some embodiments, the one or more processors may be configured to wirelessly receive, during a service period of a target wake time (TWT) schedule, via a transceiver from a first device in a wireless local area network (WLAN), a first frame indicating that the first device is ready to terminate the service period. In response to the first frame, the one or more processors may be configured to determine whether the access point has pending traffic for the first device for a remainder of the service period. In response to determining that the access point does not have pending traffic for the first device for the remainder of the service period, the one or more processors may be configured to wirelessly transmit, via the transceiver, a second frame indicating that the service period has been terminated.

In some embodiments, in response to determining that the access point has pending traffic for the first device for the remainder of the service period, the one or more processors may be further configured to wirelessly transmit, via the transceiver to the first device, the pending traffic. In response to transmitting the pending traffic, the one or more processors may be further configured to wirelessly transmit, via the transceiver, a third frame indicating that the service period has been terminated.

In some embodiments, the first frame may include a quality of service (QOS) control field that includes a first field. The first field may be set to a value indicating that the first device is ready to terminate the service period. The first frame may be a QoS null frame. The first field may be a bit included in the QoS control field.

In some embodiments, the first frame may include a second field indicating a buffer size of traffic corresponding a traffic identifier (TID). The second field may be set to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the first frame may include a third field indicating a total buffer size of traffic corresponding a plurality of TIDs. The third field may be set to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the one or more processors may be further configured to wirelessly send, via the transceiver of the access point, a fourth frame. In response to the fourth frame, the one or more processors may be further configured to wirelessly receive, via the transceiver, the first frame.

Various embodiments disclosed herein are related to a method including during a service period of a target wake time (TWT) schedule, wirelessly receiving, by an access point from a first device in a wireless local area network (WLAN), a first frame indicating that the first device is ready to terminate the service period. The method may include in response to the first frame, determining, by the access point, whether the access point has pending traffic for the first device for a remainder of the service period. The method may include in response to determining that the access point does not have pending traffic for the first device for the remainder of the service period, wirelessly transmitting, by the access point, a second frame indicating that the service period has been terminated.

In some embodiments, in response to determining that the access point has pending traffic for the first device for the remainder of the service period, the access point may wirelessly transmit, to the first device, the pending traffic. In response to transmitting the pending traffic, the access point may wirelessly transmit a third frame indicating that the service period has been terminated.

In some embodiments, the first frame may include a quality of service (QOS) control field that includes a first field. The first field may be set to a value indicating that the first device is ready to terminate the service period. The first frame may be a QoS null frame. The first field may be a bit included in the QoS control field.

In some embodiments, the first frame may include a second field indicating a buffer size of traffic corresponding a traffic identifier (TID). The second field may be set to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the first frame may include a third field indicating a total buffer size of traffic corresponding a plurality of TIDs. The third field may be set to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the access point may wirelessly send a fourth frame. In response to the fourth frame, the access point may wirelessly receive the first frame.

DETAILED DESCRIPTION

Streams of traffic may be characterized by different types of traffic. For instance, an application may be characterized by latency sensitive traffic (e.g., video/voice (VI/VO), real time interactive applications, and the like) or regular traffic (e.g., best effort/background applications (BE/BK)). Latency sensitive traffic may be identifiable, in part, based on its bursty nature (e.g., periodic bursts of traffic), in some embodiments. For instance, video display traffic may be driven by a refresh rate of 60 Hz, 72 Hz, 90 Hz, or 120 Hz. An application and/or device may have combinations of traffic types (e.g., latency sensitive traffic and non-latency sensitive traffic). Further, each stream of traffic for the application and/or device may be more or less spontaneous and/or aperiodic as compared to the other streams of traffic for the application and/or device. Accordingly, traffic may vary according to applications and/or channel rate dynamics.

TWT can be a time agreed/negotiated upon by devices (e.g., access points (APs) and/or stations (STAs)), or specified/configured by one device (e.g., an AP). During the wake time, a first device (e.g., a STA) may be in an awake state (e.g., its wireless communication module/interface is in a fully powered-up ready, or wake state) and is able to transmit and/or receive. When the first device is not awake (e.g., its wireless communication module/interface is in a powered-down, low power, or sleep state), the first device may enter a low power mode or other sleep mode. The first device may exist in the sleep state until a time instance/window as specified by the TWT.

TWT is a mechanism where a set of service periods (SPs) are defined and shared between devices to reduce medium contention and improve the power efficiency of the devices. For example, the first device can wake up periodically (e.g., at a fixed, configured time interval/period/cycle) based on the TWT. The TWT reduces energy consumption of the devices by limiting the awake time and associated power consumption of the devices.

An AP (e.g., AP and/or other device operating as a soft AP/hotspot) may enhance medium access protection and resource reservation by supporting restricted TWT (R-TWT). The R-TWT SPs may be used to deliver latency sensitive traffic and/or any additional frame that supports latency sensitive traffic.

Latency sensitive traffic that is not prioritized (or protected) may degrade a user experience. For example, in an AR context, latency between a movement of a user wearing an AR device and an image corresponding to the user movement and displayed to the user using the AR device may cause judder, resulting in motion sickness.

In one implementation, an image of a virtual object is generated by a remote computing device communicatively coupled to the HWD, and the image is rendered by the HWD to conserve computational resources and/or achieve bandwidth efficiency. In one example, the HWD includes various sensors that detect a location and/or orientation of the HWD and a gaze direction of the user wearing the HWD, and transmits sensor measurements indicating the detected location and gaze direction to a console device (and/or a remote server, e.g., in the cloud) through a wired connection or a wireless connection. The console device can determine a user's view of the space of the artificial reality according to the sensor measurements, and generate an image of the space of the artificial reality corresponding to the user's view. The console device can transmit the generated image to the HWD, by which the image of the space of the artificial reality corresponding to the user's view can be presented to the user. In one aspect, the process of detecting the location of the HWD and the gaze direction of the user wearing the HWD, and rendering the image to the user should be performed within a frame time (e.g., less than 11 ms). Any latency between a movement of the user wearing the HWD and an image displayed corresponding to the user movement can cause judder, which may result in motion sickness and can degrade the user experience.

FIG.1is a block diagram of an example artificial reality system environment.FIG.1provides an example environment in which devices may communicate traffic streams with different latency sensitivities/requirements. In some embodiments, the artificial reality system environment100includes an access point (AP)105, one or more head wearable displays (HWD)150(e.g., HWD150A,150B) worn by a user, and one or more computing devices110(computing devices110A,110B) providing content of artificial reality to the HWDs150.

The access point105may be a router or any network device allowing one or more computing devices110and/or one or more HWDs150to access a network (e.g., the Internet). The access point105may be replaced by any communication device (cell site). A HWD may be referred to as, include, or be part of a head mounted display (HMD), head mounted device (HMD), head wearable device (HWD), head worn display (HWD) or head worn device (HWD). In one aspect, the HWD150may include various sensors to detect a location, an orientation, and/or a gaze direction of the user wearing the HWD150, and provide the detected location, orientation and/or gaze direction to the computing device110through a wired or wireless connection. The HWD150may also identify objects (e.g., body, hand face).

In some embodiments, the computing devices110A,110B communicate with the access point105through communication links102A,102B (e.g., interlinks), respectively. In some embodiments, the computing device110A may communicate with the HWD150A through a communication link125A (e.g., intralink), and the computing device110B may communicate with the HWD150B through a wireless link125B (e.g., intralink).

The computing device110may be a computing device or a mobile device that can retrieve content from the access point105, and can provide image data of artificial reality to a corresponding HWD150. Each HWD150may present the image of the artificial reality to a user according to the image data.

The computing device110may determine a view within the space of the artificial reality corresponding to the detected location, orientation and/or the gaze direction, and generate an image depicting the determined view detected by the HWD150s. The computing device110may also receive one or more user inputs and modify the image according to the user inputs. The computing device110may provide the image to the HWD150for rendering. The image of the space of the artificial reality corresponding to the user's view can be presented to the user.

In some embodiments, the artificial reality system environment100includes more, fewer, or different components than shown inFIG.1. In some embodiments, functionality of one or more components of the artificial reality system environment100can be distributed among the components in a different manner than is described here. For example, some of the functionality of the computing device110may be performed by the HWD150, and/or some of the functionality of the HWD150may be performed by the computing device110. In some embodiments, the computing device110is integrated as part of the HWD150.

In some embodiments, the HWD150is an electronic component that can be worn by a user and can present or provide an artificial reality experience to the user. The HWD150may render one or more images, video, audio, or some combination thereof to provide the artificial reality experience to the user. In some embodiments, audio is presented via an external device (e.g., speakers and/or headphones) that receives audio information from the HWD150, the computing device110, or both, and presents audio based on the audio information. In some embodiments, the HWD150includes sensors155(e.g., sensors155A,155B) including eye trackers and hand trackers for instance, a communication interface165(e.g., communication interface165A,165B), an electronic display175, and a processor170(e.g., processor170A,170B). These components may operate together to detect a location of the HWD150and/or a gaze direction of the user wearing the HWD150, and render an image of a view within the artificial reality corresponding to the detected location of the HWD150and/or the gaze direction of the user. In other embodiments, the HWD150includes more, fewer, or different components than shown inFIG.1.

In some embodiments, the sensors155include electronic components or a combination of electronic components and software components that detect a location and/or an orientation of the HWD150. Examples of sensors155can include: one or more imaging sensors, one or more accelerometers, one or more gyroscopes, one or more magnetometers, hand trackers, eye trackers, or another suitable type of sensor that detects motion and/or location. For example, one or more accelerometers can measure translational movement (e.g., forward/back, up/down, left/right) and one or more gyroscopes can measure rotational movement (e.g., pitch, yaw, roll). In some embodiments, the sensors155detect the translational movement and/or the rotational movement, and determine an orientation and location of the HWD150. In one aspect, the sensors155can detect the translational movement and/or the rotational movement with respect to a previous orientation and location of the HWD150, and determine a new orientation and/or location of the HWD150by accumulating or integrating the detected translational movement and/or the rotational movement. Assuming for an example that the HWD150is oriented in a direction 25 degrees from a reference direction, in response to detecting that the HWD150has rotated 20 degrees, the sensors155may determine that the HWD150now faces or is oriented in a direction 45 degrees from the reference direction. Assuming for another example that the HWD150was located two feet away from a reference point in a first direction, in response to detecting that the HWD150has moved three feet in a second direction, the sensors155may determine that the HWD150is now located at a vector multiplication of the two feet in the first direction and the three feet in the second direction.

In some embodiments, the sensors155may also include eye trackers with electronic components or a combination of electronic components and software components that determine a gaze direction of the user of the HWD150. In other embodiments, the eye trackers may be a component separate from sensors155. In some embodiments, the HWD150, the computing device110or a combination may incorporate the gaze direction of the user of the HWD150to generate image data for artificial reality. In some embodiments, the eye trackers (as part of the sensors155, for instance) include two eye trackers, where each eye tracker captures an image of a corresponding eye and determines a gaze direction of the eye. In one example, the eye tracker determines an angular rotation of the eye, a translation of the eye, a change in the torsion of the eye, and/or a change in shape of the eye, according to the captured image of the eye, and determines the relative gaze direction with respect to the HWD150, according to the determined angular rotation, translation and the change in the torsion of the eye. In one approach, the eye tracker may shine or project a predetermined reference or structured pattern on a portion of the eye, and capture an image of the eye to analyze the pattern projected on the portion of the eye to determine a relative gaze direction of the eye with respect to the HWD150. In some embodiments, the eye trackers incorporate the orientation of the HWD150and the relative gaze direction with respect to the HWD150to determine a gaze direction of the user. Assuming for an example that the HWD150is oriented at a direction 30 degrees from a reference direction, and the relative gaze direction of the HWD150is −10 degrees (or 350 degrees) with respect to the HWD150, the eye trackers may determine that the gaze direction of the user is 20 degrees from the reference direction. In some embodiments, a user of the HWD150can configure the HWD150(e.g., via user settings) to enable or disable the eye trackers as part of the sensors155. In some embodiments, a user of the HWD150is prompted to enable or disable the eye trackers as part of the sensor155configuration.

In some embodiments, the sensors155include the hand tracker, which includes an electronic component or a combination of an electronic component and a software component that tracks a hand of the user. In other embodiments, the hand tracker may be a component separate from sensors155. In some embodiments, the hand tracker includes or is coupled to an imaging sensor (e.g., camera) and an image processor that can detect a shape, a location and/or an orientation of the hand. The hand tracker may generate hand tracking measurements indicating the detected shape, location and/or orientation of the hand.

In some embodiments, the communication interfaces165(e.g., communication interface165A,165B) of the corresponding HWDs150(e.g., HWD150A,150B) and/or communication interfaces115(e.g., communication interface115A,115B) of the corresponding computing devices (e.g., computing device110A,110B) include an electronic component or a combination of an electronic component and a software component that is used for communication.

The communication interface165may communicate with a communication interface115of the computing device110through an intralink communication link125(e.g., communication link125A,125B). The communication interface165may transmit to the computing device110sensor measurements indicating the determined location of the HWD150, orientation of the HWD150, the determined gaze direction of the user, and/or hand tracking measurements. For example, the computing device110may receive sensor measurements indicating location and the gaze direction of the user of the HWD150and/or hand tracking measurements and provide the image data to the HWD150for presentation of the artificial reality, for example, through the wireless link125(e.g., intralink). For example, the communication interface115may transmit to the HWD150data describing an image to be rendered. The communication interface165may receive from the computing device110sensor measurements indicating or corresponding to an image to be rendered. In some embodiments, the HWD150may communicate with the access point105.

Similarly, the communication interface115(e.g., communication interface115A,115B) of the computing devices110may communicate with the access point105through a communication link102(e.g., communication link102A,102B). In certain embodiments, the computing device110may be considered a soft access point (e.g., a hotspot device). Through the communication link102(e.g., interlink), the communication interface115may transmit and receive from the access point105AR/VR content. The communication interface115of the computing device110may also communicate with communication interface115of a different computing device110through communication link185. As described herein, the communication interface115may be a counterpart component to the communication interface165to communicate with a communication interface115of the computing device110through a communication link (e.g., USB cable, a wireless link).

The communication interfaces115and165may receive and/or transmit information indicating a communication link (e.g., channel, timing) between the devices (e.g., between the computing devices110A and110B across communication link185, between the HWD150A and computing device110A across communication link125). According to the information indicating the communication link, the devices may coordinate or schedule operations to avoid interference or collisions.

The communication link may be a wireless link, a wired link, or both. In some embodiments, the communication interface165/115includes or is embodied as a transceiver for transmitting and receiving data through a wireless link. Examples of the wireless link can include a cellular communication link, a near field communication link, Wi-Fi, Bluetooth, or any communication wireless communication link. Examples of the wired link can include a USB, Ethernet, Firewire, HDMI, or any wired communication link. In embodiments in which the computing device110and the head wearable display150are implemented on a single system, the communication interface165may communicate with the computing device110through a bus connection or a conductive trace.

Using the communication interface, the computing device110(or HWD150, or AP105) may coordinate operations on links102,185or125to reduce collisions or interferences by scheduling communication. For example, the computing device110may coordinate communication between the computing device110and the HWD150using communication link125. Data (e.g., a traffic stream) may flow in a direction on link125. For example, the computing device110may communicate using a downlink (DL) communication to the HWD150and the HWD150may communicate using an uplink (UL) communication to the computing device110. In some implementations, the computing device110may transmit a beacon frame periodically to announce/advertise a presence of a wireless link between the computing device110and the HWD150(or between HWDs150A and150B). In an implementation, the HWD150may monitor for or receive the beacon frame from the computing device110, and can schedule communication with the HWD150(e.g., using the information in the beacon frame, such as an offset value) to avoid collision or interference with communication between the computing device110and/or HWD150and other devices.

In some embodiments, the processor170may include an image renderer, for instance, which includes an electronic component or a combination of an electronic component and a software component that generates one or more images for display, for example, according to a change in view of the space of the artificial reality. In some embodiments, the image renderer is implemented as processor170(or a graphical processing unit (GPU), one or more central processing unit (CPUs), or a combination of them) that executes instructions to perform various functions described herein. In other embodiments, the image renderer may be a component separate from processor170. The image renderer may receive, through the communication interface165, data describing an image to be rendered, and render the image through the electronic display175. In some embodiments, the data from the computing device110may be encoded, and the image renderer may decode the data to generate and render the image. In one aspect, the image renderer receives the encoded image from the computing device110, and decodes the encoded image, such that a communication bandwidth between the computing device110and the HWD150can be reduced.

In some embodiments, the image renderer receives, from the computing device,110additional data including object information indicating virtual objects in the artificial reality space and depth information indicating depth (or distances from the HWD150) of the virtual objects. Accordingly, the image renderer may receive from the computing device110object information and/or depth information. The image renderer may also receive updated sensor measurements from the sensors155. The process of detecting, by the HWD150, the location and the orientation of the HWD150and/or the gaze direction of the user wearing the HWD150, and generating and transmitting, by the computing device110, a high resolution image (e.g., 1920 by 1080 pixels, or 2048 by 1152 pixels) corresponding to the detected location and the gaze direction to the HWD150may be computationally exhaustive and may not be performed within a frame time (e.g., less than 11 ms or 8 ms).

In some implementations, the image renderer may perform shading, reprojection, and/or blending to update the image of the artificial reality to correspond to the updated location and/or orientation of the HWD150. Assuming that a user rotated their head after the initial sensor measurements, rather than recreating the entire image responsive to the updated sensor measurements, the image renderer may generate a small portion (e.g., 10%) of an image corresponding to an updated view within the artificial reality according to the updated sensor measurements, and append the portion to the image in the image data from the computing device110through reprojection. The image renderer may perform shading and/or blending on the appended edges. Hence, without recreating the image of the artificial reality according to the updated sensor measurements, the image renderer can generate the image of the artificial reality.

In other implementations, the image renderer generates one or more images through a shading process and a reprojection process when an image from the computing device110is not received within the frame time. For example, the shading process and the reprojection process may be performed adaptively, according to a change in view of the space of the artificial reality.

In some embodiments, the electronic display175is an electronic component that displays an image. The electronic display175may, for example, be a liquid crystal display or an organic light emitting diode display. The electronic display175may be a transparent display that allows the user to see through. In some embodiments, when the HWD150is worn by a user, the electronic display175is located proximate (e.g., less than 3 inches) to the user's eyes. In one aspect, the electronic display175emits or projects light towards the user's eyes according to image generated by the processor170(e.g., image renderer).

In some embodiments, the HWD150may include a lens to allow the user to see the display175in a close proximity. The lens may be a mechanical component that alters received light from the electronic display175. The lens may magnify the light from the electronic display175, and correct for optical error associated with the light. The lens may be a Fresnel lens, a convex lens, a concave lens, a filter, or any suitable optical component that alters the light from the electronic display175. Through the lens, light from the electronic display175can reach the pupils, such that the user can see the image displayed by the electronic display175, despite the close proximity of the electronic display175to the eyes.

In some embodiments, the processor170performs compensation to compensate for any distortions or aberrations. In some embodiments, a compensator may be a device separate from the processor170. The compensator includes an electronic component or a combination of an electronic component and a software component that performs compensation. In one aspect, the lens introduces optical aberrations such as a chromatic aberration, a pin-cushion distortion, barrel distortion, etc. The compensator may determine a compensation (e.g., predistortion) to apply to the image to be rendered from the image renderer to compensate for the distortions caused by the lens, and apply the determined compensation to the image from the image renderer. The compensator may provide the predistorted image to the electronic display175.

In some embodiments, the computing device110is an electronic component or a combination of an electronic component and a software component that provides content to be rendered to the HWD150. The computing device110may be embodied as a mobile device (e.g., smart phone, tablet PC, laptop, etc.). The computing device110may operate as a soft access point. In one aspect, the computing device110includes a communication interface115, a processor118, and a content provider130(e.g., content provider130A,130B). These components may operate together to determine a view (e.g., a field of view (FOV) of the user) of the artificial reality corresponding to the location of the HWD150and/or the gaze direction of the user of the HWD150, and can generate an image of the artificial reality corresponding to the determined view.

The processors118,170includes or is embodied as one or more central processing units, graphics processing units, image processors, or any processors for generating images of the artificial reality. In some embodiments, the processors118,170may configure or cause the communication interfaces115,165to toggle, transition, cycle or switch between a sleep mode and a wake up mode. In the wake up mode, the processor118may enable the communication interface115and the processor170may enable the communication interface165, such that the communication interfaces115,165may exchange data. In the sleep mode, the processor118may disable the wireless interface115and the processor170may disable (e.g., may implement low power or reduced operation in) the communication interface165, such that the communication interfaces115,165may not consume power, or may reduce power consumption.

The processors118,170may schedule the communication interfaces115,165to switch between the sleep mode and the wake up mode periodically every frame time (e.g., 11 ms or 16 ms). For example, the communication interfaces115,165may operate in the wake up mode for 2 ms of the frame time, and the communication interfaces115,165may operate in the sleep mode for the remainder (e.g., 9 ms) of the frame time. By disabling the wireless interfaces115,165in the sleep mode, power consumption of the computing device110and the HWD150can be reduced or minimized.

In some embodiments, the processors118,170may configure or cause the communication interfaces115,165to resume communication based on stored information indicating communication between the computing device110and the HWD150. In the wake up mode, the processors118,170may generate and store information (e.g., channel, timing) of the communication between the computing device110and the HWD150. The processors118,170may schedule the communication interfaces115,165to enter a subsequent wake up mode according to timing of the previous communication indicated by the stored information. For example, the communication interfaces115,165may predict/determine when to enter the subsequent wake up mode, according to timing of the previous wake up mode, and can schedule to enter the subsequent wake up mode at the predicted time. After generating and storing the information and scheduling the subsequent wake up mode, the processors118,170may configure or cause the wireless interfaces115,165to enter the sleep mode. When entering the wake up mode, the processors118,170may cause or configure the communication interfaces115,165to resume communication via the channel or frequency band of the previous communication indicated by the stored information. Accordingly, the communication interfaces115, in165entering the wake up mode from the sleep mode may resume communication, while bypassing a scan procedure to search for available channels and/or performing handshake or authentication. Bypassing the scan procedure allows extension of a duration of the communication interfaces115,165operating in the sleep mode, such that the computing device110and the HWD150can reduce power consumption.

In some embodiments, the computing devices110A,110B may coordinate operations to reduce collisions or interferences. In one approach, the computing device110A may transmit a beacon frame periodically to announce/advertise a presence of a wireless link125A between the computing device110A and the HWD150A and can coordinate the communication between the computing device110A and the HWD150A. The computing device110B may monitor for or receive the beacon frame from the computing device110A, and can schedule communication with the HWD150B (e.g., using information in the beacon frame, such as an offset value) to avoid collision or interference with communication between the computing device110A and the HWD150A. For example, the computing device110B may schedule the computing device110B and the HWD150B to enter a wake up mode, when the computing device110A and the HWD150A operate in the sleep mode. For example, the computing device110B may schedule the computing device110B and the HWD150B to enter a sleep up mode, when the computing device110A and the HWD150A operate in the wake up mode. Accordingly, multiple computing devices110and HWDs150in proximity (e.g., within 20 ft) may coexist and operate with reduced interference.

The content provider130can include or correspond to a component that generates content to be rendered according to the location and/or orientation of the HWD150, the gaze direction of the user and/or hand tracking measurements. In one aspect, the content provider130determines a view of the artificial reality according to the location and orientation of the HWD150and/or the gaze direction of the user of the HWD150. For example, the content provider130maps the location of the HWD150in a physical space to a location within an artificial reality space, and determines a view of the artificial reality space along a direction corresponding to an orientation of the HWD150and/or the gaze direction of the user from the mapped location in the artificial reality space.

The content provider130may generate image data describing an image of the determined view of the artificial reality space, and transmit the image data to the HWD150through the communication interface115. The content provider may also generate a hand model (or other virtual object) corresponding to a hand of the user according to the hand tracking measurement, and generate hand model data indicating a shape, a location, and an orientation of the hand model in the artificial reality space. The content provider130may encode the image data describing the image, and can transmit the encoded data to the HWD150. In some embodiments, the content provider generates and provides the image data to the HWD150periodically (e.g., every 11 ms or 16 ms).

In some embodiments, the content provider130generates metadata including motion vector information, depth information, edge information, object information, etc., associated with the image, and transmits the metadata with the image data to the HWD150through the communication interface115. The content provider130may encode and/or encode the data describing the image, and can transmit the encoded and/or encoded data to the HWD150. In some embodiments, the content provider130generates and provides the image to the HWD150periodically (e.g., every one second).

In some embodiments, a scheduler118(e.g., scheduler118A of the computing device118A and/or scheduler118B of the computing device110B) may request R-TWT to transmit latency sensitive traffic using P2P communication. The AP105and scheduler118of the computing devices110may negotiate (e.g., perform a handshake process) and may establish a membership of a restricted TWT schedule. In some embodiments, when the AP105and the scheduler118are negotiating, the AP105may be considered a restricted TWT scheduling AP and the computing devices110may be considered a restricted TWT scheduled STA.

In some embodiments, the HWD150may request to send P2P traffic to the computing device110. Accordingly, the HWD150may be considered the TWT requesting STA (e.g., the TWT STA that requests the TWT agreement), and the computing device110may be considered TWT responding STA (e.g., the TWT STA that respond to the TWT request). The communication link125between the computing devices110and the HWDs150may be a P2P link (e.g., a link used for transmission between two non-AP devices). The communication link102between the computing devices110and the AP105may be any channel or other type of link. In some configurations, the HWD150may move/become out of range from the access point105. In other embodiments, the computing device110may request to send P2P traffic to the HWD150such that the computing device110is considered the TWT requesting STA and the HWD150is the TWT responding STA.

The schedulers118of the computing devices110may schedule communication between the computing device(s)110and the HWD(s)150with the AP105such that the communication between the computing device(s)110and HWD(s)150is protected. The computing device(s)110may initiate such protected P2P communication with the HWD(s)150by indicating, to the AP105, that the computing device(s)110wish to schedule P2P communication in R-TWT service periods (SPs). The scheduler118of the computing device(s) may schedule (or negotiate) the requested R-TWT SP(s). The scheduler118of the computing device(s) may also indicate if the SP(s) are requested only for P2P communication (as compared to mixed P2P communication and non-P2P communication).

FIG.2is a diagram of a HWD150, in accordance with an example embodiment. In some embodiments, the HWD150includes a front rigid body205and a band210. The front rigid body205includes the electronic display175(not shown inFIG.2), the lens (not shown inFIG.2), the sensors155, the eye trackers the communication interface165, and the processor170. In the embodiment shown byFIG.2, the sensors155are located within the front rigid body205, and may not visible to the user. In other embodiments, the HWD150has a different configuration than shown inFIG.2. For example, the processor170, the eye trackers, and/or the sensors155may be in different locations than shown inFIG.2.

Various operations described herein can be implemented on computer systems.FIG.3shows a block diagram of a representative computing system314usable to implement the present disclosure. In some embodiments, the computing device110, the HWD150or both ofFIG.1are implemented by the computing system314. Computing system314can be implemented, for example, as a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smart watch, eyeglasses, head wearable display), desktop computer, laptop computer, or implemented with distributed computing devices. The computing system314can be implemented to provide VR, AR, MR experience. In some embodiments, the computing system314can include conventional computer components such as processors316, storage device318, network interface320, user input device322, and user output device324.

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

The network interface320may include a transceiver to allow the computing system314to transmit and receive data from a remote device (e.g., an AP, a STA) using a transmitter and receiver. The transceiver may be configured to support transmission/reception supporting industry standards that enables bi-directional communication. An antenna may be attached to transceiver housing and electrically coupled to the transceiver. Additionally or alternatively, a multi-antenna array may be electrically coupled to the transceiver such that a plurality of beams pointing in distinct directions may facilitate in transmitting and/or receiving data.

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

User input device322can include any device (or devices) via which a user can provide signals to computing system314; computing system314can interpret the signals as indicative of particular user requests or information. User input device322can include any or all of a keyboard, touch pad, touch screen, mouse or other pointing device, scroll wheel, click wheel, dial, button, switch, keypad, microphone, sensors (e.g., a motion sensor, an eye tracking sensor, etc.), and so on.

User output device324can include any device via which computing system314can provide information to a user. For example, user output device324can include a display to display images generated by or delivered to computing system314. The display can incorporate various image generation technologies, e.g., a liquid crystal display (LCD), light-emitting diode (LED) including organic light-emitting diodes (OLED), projection system, cathode ray tube (CRT), or the like, together with supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors, or the like). A device such as a touchscreen that function as both input and output device can be used. Output devices324can be provided in addition to or instead of a display. Examples include indicator lights, speakers, tactile “display” devices, printers, and so on.

FIGS.1-2illustrate devices that communicate traffic streams some of which may be latency sensitive (e.g., those carrying periodic AR/VR information/content). As described herein, the periodic operation of TWT benefits communication of periodic traffic (e.g., latency sensitive traffic) by predictably communicating the periodic traffic.FIG.4is a timing diagram400showing a wake-up/sleep schedule of a computing device utilizing TWT, according to an example implementation of the present disclosure. The TWT start time is indicated by the computing device110(e.g., a portion of its relevant modules/circuitry) waking up at402. The computing device110may wake up for a duration404defined by a SP. After the SP duration404, the computing device110may enter a sleep state until the next TWT start time at408. The interval of time between TWT start time402and TWT start time408may be considered the SP interval406.

A TWT schedule may be communicated and/or negotiated using broadcast TWT (B-TWT) and/or individual TWT (I-TWT) signaling. In some embodiments, to signal I-TWT, TWT schedule information may be communicated to particular (individual) devices using a mode such as a Network Allocation Vector (NAV) to protect the medium access of TWT SPs. In contrast, to signal B-TWT, in some embodiments, a device (such as AP105) may schedule TWT SPs with other devices (e.g., computing devices110and/or HWDs150) and may share schedule information in beacon frames and/or probe response frames. Sharing schedule information using B-TWT may reduce overhead (e.g., negotiation overhead) as compared to the overhead used when sharing information using I-TWT.

The TWT mechanism may also be used in peer-to-peer (P2P) communication. For example, TWT may be defined for tunneled direct link setup (TDLS) pairs (e.g., non-AP STAs), soft APs (such as computing devices110) and STAs (such as HWD150), and/or peer-to-peer group owners (GO) and group clients (GC). For instance, a TDLS pair of devices (e.g., HWD150and computing device110) can request TWT membership for its latency sensitive traffic over a channel. In another example, a group owner (GO), such as a computing device110, may request TWT membership for latency sensitive traffic over the P2P link.

When P2P communication is established, various channel access rules may govern the P2P communication. An AP assisted P2P trigger frame sequence may reduce the contention/collision associated with TWT (or R-TWT) in P2P communication. Accordingly, a P2P model where a P2P STA (e.g., a HWD150) is not associated with an infra-basic service set (BSS) AP, may improve P2P communication. Without AP's assistance or coordination, a transmission over the P2P link may collide with another transmission in the BSS. In some embodiments, a reverse direction protocol (RDP) may be enabled for P2P communication. During RDP, when a transmitting STA has obtained a transmit opportunity (TXOP), the transmitting STA may grant permission for the receiving STA to transmit information back to the transmitting STA during the same TXOP. Accordingly, if a TWT setup allows P2P transmission and indicates RDP, the P2P communication can be performed after a triggered frame sequence (e.g., a reverse direction frame exchange). In other embodiments, other protocols may be enabled for P2P communication. In some embodiments, trigger-enabled TWT can reduce the medium contention and/or collisions between UL and DL transmissions. The trigger-enabled TWT may be indicated using a TWT information element (IE).

In one aspect, an access point (AP) can terminate an ongoing TWT SP (e.g., current TWT SP) by sending a notification that terminates the ongoing SP. An AP may indicate an early termination of an SP by setting an end of service period (EOSP) subfield (e.g., bit 4 of a quality of service (QOS) control field) to 1 in specific frames. An AP may indicate/request/initiate an early termination of an SP by setting a More Data subfield (e.g., bit 13 of a frame control field) to 0 in specific frames. An (early) SP termination has several advantages. For example, a TWT scheduled STA can remain awake from the start of an SP until (1) the end of the SP or (2) an AP indicates an SP termination. If a STA has already delivered and/or received traffic intended for the SP, the STA can sleep (e.g., switch to an inactive state) after the early SP termination and can save power.

In the conventional early SP termination framework, only an AP can terminate an SP, and a STA may not have the ability to terminate an SP. For example, the AP may not wait for any indication from the STA and may terminate anytime the AP decides. That is, SP termination may not be a handshake. It would be beneficial for a STA to have a method/way of indication to the AP that the STA is ready to terminate the SP or the STA is requesting an early termination.

To address this problem, systems and/or methods for indicating early termination of a TWT SP may be provided/defined. In some embodiments, a system can provide a technique for a STA to explicitly indicate about readiness, intention and/or request to terminate an on-going SP of a TWT (e.g., B-TWT (broadcast TWT) or R-TWT (restricted TWT)). In some embodiments, an AP can terminate regardless of what the STA has signaled (even if the AP has not received from a STA an indication to terminate a TWT SP). For example, if the AP sends a notification to terminate a TWT SP, the AP's notification can take priority and terminate the TWT SP regardless of whether the AP receives an early SP termination indication from a STA or not.

In one approach, a new “EOT” (end of traffic) subfield or a new “EOTSP” (end of traffic for service period) subfield as early SP termination indication may be defined in a QoS (quality of service) control field. In some embodiments, a STA may send this early SP termination indication as an unsolicited response. A QoS control field may be carried in a medium access control (MAC) header in QoS Null frames or QoS data frames. QoS Null frames may have a “reserved” subfield in the QoS control field (e.g., bit 7 of the QoS control field) while QoS data frames may not have a “reserved” subfield in the QoS control field. In some embodiments, the reserved bit may be redefined as “EOT” (End of Traffic) subfield or “EOTSP” (end of traffic for service period) subfield or any other subfield with a different name. In some embodiments, a subfield other than the reserved bit (in the MAC header in QoS Data frames or QOS NULL frames) may be redefined as “EOT” subfield or “EOTSP” subfield.

In some embodiments, a QoS control field may include a first subfield (bits 0-3), a second subfield (bit 4), a third subfield (bits 5-6), a fourth subfield (bit 7), and/or a fifth subfield (bits 8-15). The STA may set the subfields of the QoS control field depending on the frame subtype of a frame. For example, if the frame subtype is QOS Null frame, the STA may set (1) the first subfield to a TID; (2) the second subfield to 0; (3) the third subfield to an Ack policy indicator; and/or (4) the fifth subfield to transmission opportunity (TXOP) duration requested for the TID set in the first subfield. The STA can indicate to terminate a TWT SP using the QoS control field. In some embodiments, the STA can set (1) the frame subtype to QoS Null frame; (2) the first subfield to a TID; (3) the second subfield to 1; (4) the third subfield to an Ack policy indicator; (5) the fourth subfield as “EOT” (end of traffic) subfield to a value indicating early SP termination; and/or (6) the fifth subfield to a queue size of traffic for the TID set in the first subfield.

In some embodiments, the EOT subfield may indicate whether there is pending traffic from the transmitting STA during the current SP. For example, the EOT subfield may be set to 1 if the transmitting STA does not have any more pending traffic to be delivered during the current SP; otherwise, the EOT subfield may be set to 0. In other words, the STA may set the EOT subfield to 1 during an on-going TWT SP to indicate to the AP or a peer STA (e.g., using individual TWT) that the STA does not have any pending traffic for the remainder of the current TWT SP.

In some embodiment, the AP may not (early) terminate an on-going SP until the AP receives an EOT indication (using the EOT subfield) from the STA. If the AP receives the EOT indication from the STA and the AP does not have more pending traffic for the STA, the AP may early terminate the SP.

In one approach, the system may allow a STA to implicitly indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status. In some embodiments, a STA may perform buffer status reporting (BSR) by reporting a buffer status to an AP. A buffer status may be a quantitative indication of how much traffic (QOS data) is queued up at the STA. The STA may indicate buffer status in (bytes) by including either of the following fields in frames sent to the AP: (1) QOS control field (e.g., buffer status per TID); or (2) BSR control field (e.g., buffer status per access category (AC) such that more than one TID (e.g., two TIDs) can be mapped to one AC).

In some embodiments, a QoS control field may include a first subfield (bits 0-3), a second subfield (bit 4), a third subfield (bits 5-6), a fourth subfield (bit 7), and/or a fifth subfield (bits 8-15). The STA may set the subfields of the QoS control field depending on the frame subtype of a frame. For example, if the frame subtype is QOS Data frame, the STA may set (1) the first subfield to a TID; (2) the second subfield to 0; (3) the third subfield to an Ack policy indicator; (4) the fourth subfield to a value indicating that that A-MSDU (aggregated MAC service data unit) is present; and/or (5) the fifth subfield to a TXOP duration requested for the TID set in the first subfield. If the frame subtype is QOS Data frame, the STA may set (1) the first subfield to a TID; (2) the second subfield to 1; (3) the third subfield to an Ack policy indicator; (4) the fourth subfield to a value indicating that that A-MSDU is present; and/or (5) the fifth subfield to a queue size of UL traffic for the TID set in the first subfield.

In some embodiments, if the frame subtype is QOS Null frame, the STA may set (1) the first subfield to a TID; (2) the second subfield to 0; (3) the third subfield to an Ack policy indicator; and/or (4) the fifth subfield to a TXOP duration requested for the TID set in the first subfield. If the frame subtype is QOS Null frame, the STA may set (1) the first subfield to a TID; (2) the second subfield to 1; (3) the third subfield to an Ack policy indicator; and/or (4) the fifth subfield to a queue size of UL traffic for the TID set in the first subfield. In this manner, the STA can report a buffer status via the QoS control field by reporting a queue size of UL traffic per TID. The STA may indicate buffer status in response to a buffer status report polling (BSRP) trigger frame or as an unsolicited response.

In some embodiments, an aggregate control (A-control) subfield of a High Efficiency (HE) variant High Throughput (HT) control field may include the fields of a plurality of HE controls (including HE control-1, HE control-2, . . . , HE control-N) and a padding. Each HE control may include the fields of control ID and control information. For BSR response, the control ID field may be set to a value (e.g., 3) indicating BSR (see Table 1). The control information field (or BSR control field) may include the subfields of ACI (Access Category Identifier) bitmap, delta TID, ACI high, scaling factor, queue size high, and/or queue size all. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP, a receiver STA may report its buffer status by specifying a queue size in the ‘queue size all’ subfield of a frame and sending the frame to the AP. Queue sizes may be reported for ACI indicated in the ACI bitmap subfield, which indicates the access category (or access categories) for which data stored in the STA's buffer is intended. Each bit of the ACI bitmap subfield can indicate the presence of a service intended for a corresponding AC. A value set in the delta TID subfield may indicate the number of TIDs corresponding to the number of bits in the ACI bitmap subfield that are set to 1. For example, if (1) the number of bits in the ACI bitmap subfield that are set to 1 equals 1, and (2) the delta TID is set to value 1, the delta TID may indicate 2 TIDs. If the number of bits in the ACI bitmap subfield that are set to 1 equals 0, values 0 to 2 in the delta TID may not be applicable, e.g., may not indicate the number of TIDs. A value set in the queue size all subfield may indicate/report a combined queue size of all ACs indicated in the ACI bitmap subfield. A value set in the queue size high subfield may indicate/report a queue size of ACI indicated in the ACI high subfield. In this manner, a queue size may be indicated for a specific AC (e.g., using the queue size high subfield), and/or for all backlogged traffic (e.g., using the queue size all subfield).

TABLE 1Control ID subfield valuesLength of the controlControl IDinformationvalueMeaningsubfield (bits)0Triggered response scheduling (TRS)261Operating mode (OM)122HE link adaptation (HLA)263Buffer status report (BSR)264UL power headroom (UPH)85Bandwidth query report (BQR)106Command and status (CAS)87-14Reserved15Ones need expansion surely (ONES)26

In some embodiments, the system may allow/configure/request a STA to indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for all traffic (e.g., all TIDs). If a STA indicates zero buffer status for all TIDs (or ACs) associated with an on-going SP, the zero buffer status indication may serve as EOT indication which indicates that STA has no more traffic to deliver during the on-going SP (e.g., the buffer queue is empty or the buffer size is zero).

In some embodiments, using a QoS control field, a STA may indicate zero buffer status for all TIDs. For example, for each TID of the all TIDs, the STA may indicate zero buffer status by setting (1) the first field to a TID; (2) the second field to 1; and (3) the fifth subfield to zero (e.g., zero buffer status/queue size). In some embodiments, the STA may indicate zero buffer status by aggregating multiple QoS control fields in a single frame.

In some embodiments, using a BSR control subfield, a STA may indicate zero buffer status for all ACs in separate fields (e.g., different TIDs). For example, for each TID of the all TIDs, the STA may indicate zero buffer status by setting (1) the ACI high subfield to a TID; and (2) the queue size high subfield to 0 (e.g., zero buffer status/queue size). In some embodiments, the STA may indicate zero buffer status by setting the queue size all subfield to 0 (e.g., zero buffer status/queue size).

In some embodiments, for R-TWT, a zero buffer status indication corresponding only to R-TWT uplink (UL) TIDs (which can be negotiated during the R-TWT setup) may serve as EOT indication (e.g., SP termination readiness indication). For other TWT schedules (e.g., I-TWT/B-TWT), a zero buffer status indication may serve as EOT indication for all TIDs. In some embodiments, (1) if an AP receives a zero buffer status indication in BSR (e.g., no pending traffic indicated in BSR) for all TIDs corresponding to an on-going SP and (2) if the AP has also delivered all traffic in download (DL) to the STA, the AP may terminate the SP.

In some embodiments, the system may allow a STA to indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for any TID. BSR may be primarily used for UL multi-user (MU) scheduling, and a STA may deliver BSR of any TID when triggered by an AP, or deliver BSR of any TID in unsolicited manner. If the STA has delivered all traffic for some TIDs and has pending traffic for some other TIDs, the STA may keep delivering non-zero buffer status for remaining traffic. In some embodiments, to indicate early termination of a TWT SP, the STA may deliver zero buffer status of any TID only when the STA has finished delivering traffic for the on-going SP. In this manner, zero buffer status received during an on-going SP may serve as EOT indication (e.g., SP termination readiness indication). In some embodiments, a STA may deliver zero buffer status (for any TID or any AC or all ACs) during an on-going TWT SP to indicate to the AP or a peer STA that the STA does not have any pending traffic for the remainder of the on-going TWT SP. In some embodiments, if an AP receives zero buffer status from a STA during an on-going SP, the AP may terminate the SP for the corresponding STA.

One drawback of early SP termination indication using BSR is that buffer status/size of the STA at a certain time instant may be zero, but the STA may be expecting traffic and hence may not want to terminate the SP. This is especially problematic when the AP solicits a buffer report e.g., via BSRP trigger frames. In some embodiments, a STA can indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for all traffic (e.g., all TIDs), only when delivering the zero buffer status as an unsolicited response. In some embodiments, (1) if an AP receives a zero buffer status indication in BSR for all TIDs corresponding to an on-going SP as an unsolicited response, and (2) if the AP has also delivered all traffic to the STA, the AP may terminate the SP. Similarly, a STA can indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for any TID, only when delivering the zero buffer status as an unsolicited response. In some embodiments, (1) if an AP receives a zero buffer status indication in BSR for any TID corresponding to an on-going SP as an unsolicited response, and (2) if the AP has also delivered all traffic to the STA, the AP may terminate the SP.

In some embodiments, at a first step, a STA may send an indication of early termination of an on-going SP of a TWT (e.g., using either EOT subfield, QoS control field, solicited zero buffer status report, unsolicited zero buffer status report). At a second step, the AP may determine that the AP has no more traffic in DL for the STA for the remainder of the on-going SP. At a third step, the AP may send an SP termination notification to the STA. At a fourth step, the on-going SP of the TWT may be terminated.

In some embodiments, at a first step, a STA may send an indication of early termination of an on-going SP of a TWT (e.g., using either EOT subfield, QoS control field, solicited zero buffer status report, unsolicited zero buffer status report). At a second step, the AP may determine that the AP has traffic in DL for the STA for the remainder of the on-going SP. At a third step, the AP may send (all of) the remaining traffic to the STA. At a fourth step, the AP may send an SP termination notification to the STA. In some embodiments, the SP termination notification can be indicated in a last DL data frame sent by the AP. At a fifth step, the on-going SP of the TWT may be terminated. In some embodiments, the AP may terminate an on-going SP only after receiving the early SP termination indication from the STA.

In one approach, a first device may include one or more processors. The one or more processors may generate, during a service period of a target wake time (TWT) schedule, a first frame indicating, to an access point in a wireless local area network (WLAN), that the first device is ready to terminate the service period. The one or more processors may wirelessly transmit, via a transceiver, the generated first frame to the access point.

In some embodiments, the first frame may include a quality of service (QOS) control field that includes 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 that the first device is ready to terminate the service period. The first frame may be a QoS null frame. The first field may be a bit included in the QoS control field.

In some embodiments, the first frame may include a second field indicating a buffer size of traffic corresponding a traffic identifier (TID). In generating the first frame, the one or more processors may be configured to set the second field to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the first frame may include a third field indicating a total buffer size of traffic corresponding a plurality of TIDs. In generating the first frame, the one or more processors are configured to set the third field to a value indicating that the first device is ready to terminate the service period.

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

In one approach, an access point may include one or more processors. The one or more processors may wirelessly receive, during a service period of a target wake time (TWT) schedule, via a transceiver from a first device in a wireless local area network (WLAN), a first frame indicating that the first device is ready to terminate the service period. In response to the first frame, the one or more processors may determine whether the access point has pending traffic for the first device for a remainder of the service period. In response to determining that the access point does not have pending traffic for the first device for the remainder of the service period, the one or more processors may wirelessly transmit, via the transceiver, a second frame indicating that the service period has been terminated.

In some embodiments, in response to determining that the access point has pending traffic for the first device for the remainder of the service period, the one or more processors may be further configured to wirelessly transmit, via the transceiver to the first device, the pending traffic. In response to transmitting the pending traffic, the one or more processors may be further configured to wirelessly transmit, via the transceiver, a third frame indicating that the service period has been terminated.

In some embodiments, the first frame may include a quality of service (QOS) control field that includes a first field. The first field may be set to a value indicating that the first device is ready to terminate the service period. The first frame may be a QoS null frame. The first field may be a bit included in the QoS control field.

In some embodiments, the first frame may include a second field indicating a buffer size of traffic corresponding a traffic identifier (TID). The second field may be set to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the first frame may include a third field indicating a total buffer size of traffic corresponding a plurality of TIDs. The third field may be set to a value indicating that the first device is ready to terminate the service period.

In some embodiments, the one or more processors may be further configured to wirelessly send, via the transceiver of the access point, a fourth frame. In response to the fourth frame, the one or more processors may be further configured to wirelessly receive, via the transceiver, the first frame.

Embodiments in the present disclosure have at least the following advantages and benefits. First, embodiments in the present disclosure can provide useful techniques for a STA to send an indication to the AP that the STA is ready to terminate the SP or the STA is requesting an early termination.

Second, embodiments in the present disclosure can provide useful techniques for the AP and the STA to perform a handshake procedure to early terminate an on-going SP of a TWT. For example, upon receiving an early SP termination indication from the STA during an on-going SP of a TWT, the AP may determine whether the AP has more traffic in DL for the STA for the remainder of the on-going SP. In response to determining that the AP does not have traffic in DL for the STA, the AP may send an SP termination notification to the STA so that the on-going SP of the TWT is terminated.

FIG.5illustrates an example quality of service (QOS) control field format500for indicating early termination of a TWT service period (SP), according to an example implementation of the present disclosure. In some embodiments, a new “EOT” (end of traffic) subfield550or a new “EOTSP” (end of traffic for service period) subfield550as early SP termination indication may be defined in the QoS control field500. A STA may send this early SP termination indication (e.g., EOT/EOTSP550) as an unsolicited response. The QoS control field500may be carried in a MAC header in QoS Null frames or QoS data frames. QoS Null frames may have a “reserved” subfield560in the QoS control field500(e.g., bit 7 of the QoS control field) while QoS data frames may not have a “reserved” subfield in the QoS control field. The reserved bit (e.g., bit 7 of the QoS control field) may be redefined as “EOT” subfield550or “EOTSP” subfield550or any other subfield with a different name. In some embodiments, a subfield other than the reserved bit (in the MAC header in QoS Data frames or QOS NULL frames) may be redefined as “EOT” subfield or “EOTSP” subfield.

Referring toFIG.5, the QoS control field500may include a first subfield501(bits 0-3), a second subfield502(bit 4), a third subfield503(bits 5-6), a fourth subfield504(bit 7), and/or a fifth subfield505(bits 8-15). The STA may set the subfields of the QoS control field depending on the frame subtype510of a frame. For example, if the frame subtype510of a frame520is QOS Null frame, the STA may set (1) the first subfield501to a TID; (2) the second subfield502to 0; (3) the third subfield503to an Ack policy indicator; and/or (4) the fifth subfield505to transmission opportunity (TXOP) duration requested for the TID set in the first subfield501(see the frame520). The STA can indicate to terminate a TWT SP using the QoS control field by setting (1) the frame subtype510to QoS Null frame; (2) the first subfield501to a TID; (3) the second subfield502to 1; (4) the third subfield503to an Ack policy indicator; (5) the fourth subfield504as “EOT” subfield or “EOTSP” subfield to a value indicating early SP termination (e.g., a value “1”); and/or (6) the fifth subfield505to a queue size of traffic for the TID set in the first subfield501(see a frame530).

In some embodiments, the EOT subfield550may indicate whether there is pending traffic from the transmitting STA during the current SP. For example, the EOT subfield550may be set to 1 if the transmitting STA does not have any more pending traffic to be delivered during the current SP; otherwise, the EOT subfield550may be set to 0. In other words, the STA may set the EOT subfield550to 1 during an on-going TWT SP to indicate to the AP or a peer STA (e.g., using individual TWT) that the STA does not have any pending traffic for the remainder of the current TWT SP. In some embodiment, the AP may not (early) terminate an on-going SP until the AP receives an EOT indication (e.g., using the EOT subfield550) from the STA. If the AP receives the EOT indication from the STA and the AP does not have more pending traffic for the STA, the AP may early terminate the SP.

In some embodiments, a system may allow a STA to implicitly indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status. The STA may perform buffer status reporting (BSR) by reporting a buffer status to an AP. A buffer status may be a quantitative indication of how much traffic (QOS data) is queued up at the STA. The STA may indicate buffer status in (bytes) by including either of the following fields in frames sent to the AP: (1) QoS control field (e.g., QoS control field600indicating a buffer status per TID inFIG.6); or (2) BSR control field (e.g., BSR control field730indicating a buffer status per access category (AC) such that more than one TID (e.g., two TIDs) can be mapped to one AC).

FIG.6illustrates another example QoS control field format600for indicating early termination of a TWT SP, according to an example implementation of the present disclosure. The QoS control field600may include a first subfield601(bits 0-3), a second subfield602(bit 4), a third subfield603(bits 5-6), a fourth subfield604(bit 7), and/or a fifth subfield605(bits 8-15). The STA may set the subfields of the QoS control field600depending on the frame subtype610of a frame. For example, if the frame subtype610of a frame621is QoS Data frame620, the STA may set (1) the first subfield601to a TID; (2) the second subfield602to 0; (3) the third subfield603to an Ack policy indicator; (4) the fourth subfield604to a value indicating that that A-MSDU is present; and/or (5) the fifth subfield605to a TXOP duration requested for the TID set in the first subfield601. If the frame subtype610of a frame622is QOS Data frame620, the STA may set (1) the first subfield601to a TID; (2) the second subfield602to 1; (3) the third subfield603to an Ack policy indicator; (4) the fourth subfield604to a value indicating that that A-MSDU is present; and/or (5) the fifth subfield605to a queue size of UL traffic for the TID set in the first subfield601.

Referring toFIG.6, if the frame subtype610of a frame631is QOS Null frame630, the STA may set (1) the first subfield601to a TID; (2) the second subfield602to 0; (3) the third subfield603to an Ack policy indicator; and/or (4) the fifth subfield605to a TXOP duration requested for the TID set in the first subfield601. If the frame subtype610of a frame132is QoS Null frame630, the STA may set (1) the first subfield601to a TID; (2) the second subfield602to 1; (3) the third subfield603to an Ack policy indicator; and/or (4) the fifth subfield605to a queue size of UL traffic for the TID set in the first subfield601. In this manner, the STA can report a buffer status via the QoS control field600by reporting a queue size of UL traffic per TID (e.g., using the fifth subfield605). The STA may indicate buffer status in response to a buffer status report polling (BSRP) trigger frame or as an unsolicited response.

FIG.7illustrates an example format of an aggregate control (A-control) subfield700of a High Efficiency (HE) variant High Throughput (HT) control field for indicating early termination of a TWT SP, according to an example implementation of the present disclosure. The A-control subfield700may include the fields of a plurality of HE controls710(including HE control-1710-1, HE control-2710-2, . . . , HE control-N710-N) and a padding711. Each HE control may include the fields of control ID720and control information730. For BSR response, the control ID field720may be set to a value (e.g., 3) indicating BSR (see Table 1). The control information field (or BSR control field)730may include the subfields of ACI (Access Category Identifier) bitmap731, delta TID732, ACI high733, scaling factor734, queue size high735, and/or queue size all 736. For example, in response to a buffer status report request (e.g., BSRP trigger frame) from an AP, a receiver STA may report its buffer status by specifying a queue size in the ‘queue size all’ subfield736of a frame and sending the frame to the AP. Queue sizes may be reported for ACI indicated in the ACI bitmap subfield731, which indicates the access category (or access categories) for which data stored in the STA's buffer is intended. Each bit of the ACI bitmap subfield731can indicate the presence of a service intended for a corresponding AC. A value set in the delta TID subfield732may indicate the number of TIDs corresponding to the number of bits in the ACI bitmap subfield731that are set to 1. For example, if (1) the number of bits in the ACI bitmap subfield731that are set to 1 equals 1, and (2) the delta TID732is set to value 1, the delta TID732may indicate 2 TIDs. If the number of bits in the ACI bitmap731subfield that are set to 1 equals 0, values 0 to 2 in the delta TID732may not be applicable, e.g., may not indicate the number of TIDs. A value set in the queue size all subfield736may indicate/report a combined queue size of all ACs indicated in the ACI bitmap subfield731. A value set in the queue size high subfield735may indicate/report a queue size of ACI indicated in the ACI high subfield733. In this manner, a queue size may be indicated for a specific AC (e.g., using the queue size high subfield735), and/or for all backlogged traffic (e.g., using the queue size all subfield736).

In some embodiments, a system may allow a STA to indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for all traffic (e.g., all TIDs). If a STA indicates zero buffer status for all TIDs (or ACs) associated with an on-going SP, the zero buffer status indication may serve as EOT indication which indicates that STA has no more traffic to deliver during the on-going SP. For example, referring toFIG.6, using a QoS control field600, a STA may indicate zero buffer status for all TIDs. For example, for each TID of all the TIDs, the STA may indicate zero buffer status by setting (1) the first field601to a TID; (2) the second field602to 1; and (3) the fifth subfield605to zero (e.g., zero buffer status/queue size). In some embodiments, the STA may indicate zero buffer status by aggregating multiple QoS control fields in a single frame. Referring toFIG.7, using a BSR control subfield730, a STA may indicate zero buffer status for all ACs in separate fields (e.g., different TIDs). For example, for each TID of all the TIDs, the STA may indicate zero buffer status by setting (1) the ACI high subfield733to a TID; and (2) the queue size high subfield735to 0 (e.g., zero buffer status/queue size). In some embodiments, the STA may indicate zero buffer status by setting the queue size all subfield736to 0 (e.g., zero buffer status/queue size). In some embodiments, for R-TWT, a zero buffer status indication corresponding only to R-TWT uplink (UL) TIDs (which can be negotiated during the R-TWT setup) may serve as EOT indication (e.g., SP termination readiness indication). For other TWT schedules (e.g., I-TWT/B-TWT), a zero buffer status indication may serve as EOT indication for all TIDs. In some embodiments, (1) if an AP receives a zero buffer status indication in BSR (e.g., no pending traffic indicated in BSR) for all TIDs corresponding to an on-going SP (e.g., using the queue size all subfield736) and (2) if the AP has also delivered all traffic in DL to the STA, the AP may terminate the SP.

In some embodiments, the system may allow a STA to indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for any TID. BSR may be primarily used for UL multi-user (MU) scheduling, and a STA may deliver BSR of any TID when triggered by an AP, or may deliver BSR of any TID in unsolicited manner. If the STA has delivered all traffic for some TIDs and has pending traffic for some other TIDs, the STA may keep delivering non-zero buffer status for remaining traffic. In order to indicate early termination of a TWT SP, the STA may deliver zero buffer status of any TID (e.g., using the queue size high subfield735) only when the STA has finished delivering traffic for the on-going SP. In this manner, zero buffer status received during an on-going SP may serve as EOT indication (e.g., SP termination readiness indication). A STA may deliver zero buffer status (for any TID or any AC or all ACs) during an on-going TWT SP to indicate to the AP or a peer STA that the STA does not have any pending traffic for the remainder of the on-going TWT SP. If an AP receives zero buffer status from a STA during an on-going SP, the AP may terminate the SP for the corresponding STA.

In some embodiments, a STA can indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for all traffic (e.g., all TIDs), only when delivering the zero buffer status as an unsolicited response. For example, (1) if an AP receives a zero buffer status indication in BSR for all TIDs (e.g., using the queue size all subfield736) corresponding to an on-going SP as an unsolicited response, and (2) if the AP has also delivered all traffic to the STA, the AP may terminate the SP. Similarly, a STA can indicate (readiness, intention and/or request of) early termination of a TWT SP using zero buffer status for any TID, only when delivering the zero buffer status as an unsolicited response. For example, (1) if an AP receives a zero buffer status indication in BSR for any TID (e.g., using the queue size high subfield735) corresponding to an on-going SP as an unsolicited response, and (2) if the AP has also delivered all traffic to the STA, the AP may terminate the SP.

FIG.8AandFIG.8Billustrate example frame sequences800,850for early termination of a TWT SP, according to an example implementation of the present disclosure. Referring toFIG.8A, at step810, a STA801(e.g., computing device110A,110B, HWD150A,150B) may send, to an AP802(e.g., AP105), an indication of early termination of an on-going SP of a TWT (e.g., using either EOT subfield550inFIG.5, or solicited or unsolicited zero buffer status report (QOS control field600inFIG.6or BSR control field730inFIG.7)). At step812, the AP802may determine whether the AP has traffic in DL for the STA801for the remainder of the on-going SP. At step814, the AP802may determine that the AP has no more traffic in DL for the STA801for the remainder of the on-going SP. At step820, the AP802may send an SP termination notification to the STA801. At step830, the on-going SP of the TWT may be terminated.

Referring toFIG.8B, at step860, the STA801may send, to the AP802, an indication of early termination of an on-going SP of a TWT (e.g., using either EOT subfield550inFIG.5, or solicited or unsolicited zero buffer status report (QOS control field600or BSR control field730)). At step862, the AP802may determine whether the AP has traffic in DL for the STA801for the remainder of the on-going SP. At step864, the AP802may determine that the AP has traffic in DL for the STA801for the remainder of the on-going SP. At step870, the AP802may send (all of) the remaining traffic to the STA801. At step880, the AP802may send an SP termination notification to the STA801. In some embodiments, the SP termination notification sent at step880can be indicated in a last DL data frame sent by the AP802at step870. At step890, the on-going SP of the TWT may be terminated. In some embodiments, the AP802may terminate an on-going SP only after receiving the early SP termination indication from the STA801.

FIG.9is a flowchart showing a process900of performing early termination of a TWT SP, according to an example implementation of the present disclosure. In some embodiments, the process900is performed by an access point (e.g., AP105or AP802). In some embodiments, the process900is performed by other entities. In some embodiments, the process900includes more, fewer, or different steps than shown inFIG.9.

In one approach, during a service period of a TWT schedule, the access point may wirelessly receive902, from a first device (e.g., computing device110A,110B, HWD150A,150B, STA801) in a wireless local area network (WLAN), a first frame indicating that the first device is ready to terminate the service period. In some embodiments, the access point may wirelessly send a fourth frame (e.g., BSRP trigger frame). In response to the fourth frame, the access point may wirelessly receive the first frame (e.g., frame carrying zero buffer status using a QoS control field600or a BSR control field730).

In some embodiments, the first frame may include a QoS control field (e.g., QoS control field500) that includes a first field (e.g., the fourth subfield504as EOT/EOTSP subfield550). The first field may be set to a value (e.g., value 1) indicating that the first device is ready to terminate the service period. The first frame may be a QoS null frame (e.g., frame530). The first field may be a bit (e.g., bit 7) included in the QoS control field (e.g., QoS control field500).

In some embodiments, the first frame may include a second field (e.g., the queue size high subfield735) indicating a buffer size of traffic corresponding a TID (e.g., TID indicated in the ACI high subfield733). The second field may be set to a value (e.g., value 0) indicating that the first device is ready to terminate the service period. In some embodiments, the first frame may include a third field (e.g., the queue size all subfield736) indicating a total buffer size of traffic corresponding a plurality of TIDs (e.g., TIDs indicated in the ACI bitmap subfield731and the delta TID subfield732). The third field may be set to a value (e.g., value 0) indicating that the first device is ready to terminate the service period.

In one approach, in response to the first frame, the access point may determine904whether the access point has pending traffic for the first device for a remainder of the service period (e.g., step812and step862inFIG.8AandFIG.8B, respectively). In one approach, in response to determining that the access point does not have pending traffic for the first device for the remainder of the service period (e.g., step814), the access point may wirelessly transmit906a second frame (e.g., TWT SP termination notification) indicating that the service period has been terminated. In some embodiments (e.g., step820), in response to determining that the access point has pending traffic for the first device for the remainder of the service period (e.g., step864), the access point may wirelessly transmit, to the first device, the pending traffic (e.g., step870). In response to transmitting the pending traffic, the access point may wirelessly transmit a third frame (e.g., TWT SP termination notification) indicating that the service period has been terminated (e.g., step880).

Systems and methods described herein may be embodied in other specific forms without departing from the characteristics thereof. References to “approximately,” “about” “substantially” or other terms of degree include variations of +/−10% from the given measurement, unit, or range unless explicitly indicated otherwise. Coupled elements can be electrically, mechanically, or physically coupled with one another directly or with intervening elements. Scope of the systems and methods described herein is thus indicated by the appended claims, rather than the foregoing description, and changes that come within the meaning and range of equivalency of the claims are embraced therein.