EP4497278A1

EP4497278A1 - Systems and methods of signalling target wake time schedule

Info

Publication number: EP4497278A1
Application number: EP23717302.6A
Authority: EP
Inventors: Binita Gupta; Chunyu Hu; Muhammad Kumai HAIDER
Original assignee: Meta Platforms Technologies LLC
Current assignee: Meta Platforms Technologies LLC
Priority date: 2022-03-21
Filing date: 2023-03-20
Publication date: 2025-01-29
Also published as: TW202404398A; WO2023183240A1

Abstract

An access point (AP) device may include one or more processors. The one or more processors may generate a frame including information on a target wake time (TWT) schedule. The one or more processors may set a first subfield of the frame to an address of a receiver device receiving the frame over a wireless local area network (WLAN). The one or more processors may wirelessly transmit, via a transmitter over the WLAN, the generated frame to the receiver device.

Description

SYSTEMS AND METHODS OF SIGNALLING TARGET WAKE TIME SCHEDULE FIELD OF DISCLOSURE

The present disclosure is generally related to communication for rendering artificial reality, including but not limited to improving scheduling in communication for artificial reality by announcing target wake time (TWT) schedules using individually addressed frames.

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, and an image of a virtual object corresponding to a location 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 artificial reality (e.g., a VR space, an AR space, or a MR space).

In one implementation, an image of a virtual object is generated by a console communicatively coupled to the HWD. In one example, the HWD includes various sensors that detect a location and/or orientation of the HWD, and transmits the detected location and/or orientation of the HWD to the console through a wired connection or a wireless connection. The console can determine a user’s view of the space of the artificial reality according to the detected location and/or orientation of the HWD, and generate image data indicating an image of the space of the artificial reality corresponding to the user’s view. The console can transmit the image data 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.

The present disclosure seeks to address, at least in part, any or all of the drawbacks and disadvantages described above.

SUMMARY

According to a first aspect of the present disclosure there is provided an access point (AP) device comprising: one or more processors configured to: generate a frame including information on a target wake time (TWT) schedule; set a first subfield of the frame to an address of a receiver device receiving the frame over a wireless local area network (WLAN); and wirelessly transmit, via a transmitter over the WLAN, the generated frame to the receiver device.

In some embodiments, the TWT schedule may be a restricted TWT (R-TWT) schedule. In some embodiments, the one or more processors may be configured to: determine whether a configuration value of the device is true; and in response to the configuration value of the device being true, set the first subfield of the frame to the address of the receiver device.

In some embodiments, the one or more processors may be configured to set a second subfield of the frame to a value indicating that the frame is to convey the TWT schedule to one or more devices.

In some embodiments, the frame may be one of a Probe Response frame, an Association Response frame, a Reassociation Response frame, a TWT Setup frame, or a TWT Information frame.

In some embodiments, the TWT schedule may include a plurality of TWT schedules including a first TWT schedule and a second TWT schedule; and the one or more processors may be configured to set a second subfield of the frame to a first value indicating that the frame is to convey the first TWT schedule to one or more devices, and set a third subfield of the frame to a second value indicating the frame relates to negotiation of membership in the second TWT schedule.

In some embodiments, the frame may be an Action frame; and the one or more processors may be configured to set an action subfield of the Action frame to a value indicating TWT schedule information.

In some embodiments, the one or more processors may be configured to: receive, via a receiver from the receiver device, another Action frame whose action subfield is set to the value indicating the TWT schedule information; determine whether a request subfield of the another Action frame is set to a third value indicating a request for the TWT schedule information; and in response to the request subfield of the another Action frame being set to the third value, set a request subfield of the Action frame to a fourth value that is different from the third value and indicates a response to the request for the TWT schedule information.

In some embodiments, the one or more processors may be configured to: receive another frame from the receiver device; determine whether a fourth subfield of the another frame is set to a sixth value indicating a request for TWT schedule information; and in response to the fourth subfield of the another frame being set to the sixth value, generate the frame such that the frame is a response frame to the another frame.

In some embodiments, the another frame may be one of a Probe Request frame, a TWT Information frame, or a TWT Setup frame.

According to a second aspect of the present disclosure there is provided a method comprising: generating, by one or more processors of an access point (AP) device, a frame including information on a target wake time (TWT) schedule; setting, by the one or more processors of the AP device, a first subfield of the frame to an address of a receiver device receiving the frame over a wireless local area network (WLAN); and wirelessly transmitting, via a transmitter over the WLAN, the generated frame to the receiver device.

In some embodiments, the TWT schedule may be a restricted TWT (R-TWT) schedule. In some embodiments, the AP device may determine whether a configuration value of the device is true; and in response to the configuration value of the device being true, the AP device may set the first subfield of the frame to the address of the receiver device.

In some embodiments, the AP device may set a second subfield of the frame to a value indicating that the frame is to convey the TWT schedule to one or more devices.

In some embodiments, the TWT schedule may include a plurality of TWT schedules including a first TWT schedule and a second TWT schedule; and the method may further comprise setting a second subfield of the frame to a first value indicating that the frame is to convey the first TWT schedule to one or more devices; and setting a third subfield of the frame to a second value indicating the frame relates to negotiation of membership in the second TWT schedule.

In some embodiments, the frame may be an Action frame; and the method may further comprise setting an action subfield of the Action frame to a value indicating TWT schedule information.

In some embodiments, the method may further comprise: receiving, via a receiver from the receiver device, another Action frame whose action subfield is set to the value indicating the TWT schedule information; determining whether a request subfield of the another Action frame is set to a third value indicating a request for the TWT schedule information; and in response to the request subfield of the another Action frame being set to the third value, setting a request subfield of the Action frame to a fourth value that is different from the third value and indicates a response to the request for the TWT schedule information.

In some embodiments, the method may further comprise: receiving another frame from the receiver device; determining whether a fourth subfield of the another frame is set to a sixth value indicating a request for TWT schedule information; and in response to the fourth subfield of the another frame being set to the sixth value, generating the frame such that the frame is a response frame to the another frame.

It will be appreciated that any features described herein as being suitable for incorporation into one or more aspects or embodiments of the present disclosure are intended to be generalizable across any and all aspects and embodiments of the present disclosure. Other aspects of the present disclosure can be understood by those skilled in the art in light of the description, the claims, and the drawings of the present disclosure. The foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are not intended to be drawn to scale. Like reference numbers and designations in the various drawings indicate like elements. For purposes of clarity, not every component can be labeled in every drawing.

FIG. 1 A is a diagram of a system environment including an artificial reality system, according to one or more embodiments of the present disclosure.

FIG. IB is a diagram of a system environment including an artificial reality system, according to one or more embodiments of the present disclosure.

FIG. 2 is a diagram of a head wearable display, according to one or more embodiments of the present disclosure.

FIG. 3 is a block diagram of a computing environment according to one or more embodiments of the present disclosure.

FIG. 4 illustrates an example format of a target wake time (TWT) element field, according to one or more embodiments of the present disclosure.

FIG. 5A to FIG. 5D illustrate an example format of individually addressed frames using TWT element fields for announcing/sending one or more TWT schedules, according to one or more embodiments of the present disclosure.

FIG. 6 illustrates an example format of an individually addressed frame for announcing/sending one or more TWT schedules, according to one or more embodiments of the present disclosure. FIG. 7 illustrates an example format of a modified TWT element field, according to one or more embodiments of the present disclosure.

FIG. 8A to FIG. 8C illustrate an example format of frames including modified TWT element fields for requesting TWT schedule information, according to one or more embodiments of the present disclosure.

FIG. 9 is a flowchart showing a process of announcing/sending one or more TWT schedules using an individually addressed frame, according to one or more embodiments of the present disclosure.

DETAILED DESCRIPTION

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

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 or characterized, 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 60Hz, 72Hz, 90Hz, or 120Hz. 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 wake 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, active 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, inactive, 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/avoid 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 mterval/period/cycle) based on the TWT. The TWT approach 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 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.

Disclosed herein are systems and methods related to announcing (e.g., sharing, providing, sending, reporting) one or more TWT schedules to a receiver device using an individually addressed frame (e.g., Probe Response frame, Association Response frame, Reassociation Response frame, a TWT Setup frame, a TWT Information frame). In some embodiments, an AP device may have one or more processors. The one more processors may generate a frame including information on a TWT schedule. The one more processors may set a first subfield of the frame to an address of a receiver device (e g., MAC address, IP address, or port of a non-AP STA) receiving the frame over a wireless local area network (WLAN). The one more processors may wirelessly transmit, via a transmitter over the WLAN, the generated frame to the receiver device.

FIG. 1 A is a block diagram of an example artificial reality system environment 100. In some embodiments, the artificial reality system environment 100 includes a HWD 150 worn by a user, and a console (or computing device) 110 providing content of artificial reality to the HWD 150. The HWD 150 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). The HWD 150 may detect its location and/or orientation of the HWD 150 as well as a shape, location, and/or an orientation of the body/hand/face of the user, and provide the detected location/or orientation of the HWD 150 and/or tracking information indicating the shape, location, and/or orientation of the body/hand/face to the console 110. The console 110 may generate image data indicating an image of the artificial reality according to the detected location and/or orientation of the HDM 150, the detected shape, location and/or orientation of the body/hand/face of the user, and/or a user input for the artificial reality, and transmit the image data to the HWD 150 for presentation. In some embodiments, the artificial reality system environment 100 includes more, fewer, or different components than shown in FIG. 1. In some embodiments, functionality of one or more components of the artificial reality system environment 100 can be distributed among the components in a different manner than is described here. For example, some of the functionality of the console 110 may be performed by the HWD 150. For example, some of the functionality of the HWD 150 may be performed by the console 110. In some embodiments, the console 110 is integrated as part of the HWD 150.

In some embodiments, the HWD 150 is an electronic component that can be worn by a user and can present or provide an artificial reality experience to the user. The HWD 150 may 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 HWD 150, the console 110, or both, and presents audio based on the audio information. In some embodiments, the HWD 150 includes sensors 155, eye trackers 160, a hand tracker 162, a communication interface 165, a processor/image Tenderer 170, an electronic display 175, a lens 180, and a compensator 185. These components may operate together to detect a location of the HWD 150 and a gaze direction of the user wearing the HWD 150, and render an image of a view within the artificial reality corresponding to the detected location and/or orientation of the HWD 150. In other embodiments, the HWD 150 includes more, fewer, or different components than shown in FIG. 1.

In some embodiments, the sensors 155 include electronic components or a combination of electronic components and software components that detect a location and an orientation of the HWD 150. Examples of the sensors 155 can include: one or more imaging sensors, one or more accelerometers, one or more gyroscopes, one or more magnetometers, or another suitable ty pe 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 sensors 155 detect the translational movement and the rotational movement, and determine an orientation and location of the HWD 150. In one aspect, the sensors 155 can detect the translational movement and the rotational movement with respect to a previous orientation and location of the HWD 150, and determine anew orientation and/or location of the HWD 150 by accumulating or integrating the detected translational movement and/or the rotational movement. Assuming for an example that the HWD 150 is oriented in a direction 25 degrees from a reference direction, in response to detecting that the HWD 150 has rotated 20 degrees, the sensors 155 may determine that the HWD 150 now faces or is oriented in a direction 45 degrees from the reference direction. Assuming for another example that the HWD 150 was 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 sensors 155 may determine that the HWD 150 is 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 eye trackers 160 include electronic components or a combination of electronic components and software components that determine a gaze direction of the user of the HWD 150. In some embodiments, the HWD 150, the console 110 or a combination of them may incorporate the gaze direction of the user of the HWD 150 to generate image data for artificial reality. In some embodiments, the eye trackers 160 include two eye trackers, where each eye tracker 160 captures an image of a corresponding eye and determines a 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 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 HWD 150, according to the determined angular rotation, translation and the change in the torsion of the eye. In one approach, the eye tracker 1 0 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 HWD 150. In some embodiments, the eye trackers 160 incorporate the orientation of the HWD 150 and the relative gaze direction with respect to the HWD 150 to determine a gate direction of the user. Assuming for an example that the HWD 150 is oriented at a direction 30 degrees from a reference direction, and the relative gaze direction of the HWD 150 is -10 degrees (or 350 degrees) with respect to the HWD 150, the eye trackers 160 may determine that the gaze direction of the user is 20 degrees from the reference direction. In some embodiments, a user of the HWD 150 can configure the HWD 150 (e g., via user settings) to enable or disable the eye trackers 160. In some embodiments, a user of the HWD 150 is prompted to enable or disable the eye trackers 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 a hand of the user. In some embodiments, the hand tracker 162 includes or is coupled to an imaging sensor (e.g., camera) and an image processor that can detect a shape, a location and an orientation of the hand. The hand tracker 162 may generate hand tracking measurements indicating the detected shape, location and 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 may communicate with a communication interface 115 of the console 110 through a communication link. The communication link may be a wireless link. Examples of the wireless link can include a cellular communication link, a near field communication link, Wi-Fi, Bluetooth, 60 GHz wireless link, or any communication wireless communication link. Through the communication link, the communication interface 165 may transmit to the console 110 data indicating the determined location and/or orientation of the HWD 150, the determined gaze direction of the user, and/or hand tracking measurement. Moreover, through the communication link, the communication interface 165 may receive from the console 110 image data indicating or corresponding to an image to be rendered and additional data associated with the image.

In some embodiments, the processor/image Tenderer 170 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 processor/image Tenderer 170 is implemented as a processor (or a graphical processing unit (GPU)) that executes instructions to perform various functions described herein. The processor/image Tenderer 170 may receive, through the communication interface 165, image data describing an image of artificial reality to be rendered and additional data associated with the image, and render the image through the electronic display 175. In some embodiments, the image data from the console 110 may be encoded, and the processor/image Tenderer 170 may decode the image data to render the image. In some embodiments, the processor/image Tenderer 170 receives, from the console 110 in additional data, object information indicating virtual objects in the artificial reality' space and depth information indicating depth (or distances from the HWD 150) of the virtual objects. In one aspect, according to the image of the artificial reality, object information, depth information from the console 110, and/or updated sensor measurements from the sensors 155, the processor/image Tenderer 170 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 HWD 150. Assuming that a user rotated his head after the initial sensor measurements, rather than recreating the entire image responsive to the updated sensor measurements, the processor/image Tenderer 170 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 console 110 through reprojection. The processor/image Tenderer 170 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 processor/image Tenderer 170 can generate the image of the artificial reality. In some embodiments, the processor/image Tenderer 170 receives hand model data indicating a shape, a location and an orientation of a hand model corresponding to the hand of the user, and overlay the hand model on the image of the artificial reality. Such hand model may be presented as a visual feedback to allow a user to provide various interactions within the artificial reality.

In some embodiments, the electronic display 175 is an electronic component that displays an image. The electronic display 175 may, for example, be 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, when the HWD 150 is worn by a user, the electronic display 175 is located proximate (e.g., less than 3 inches) to the user’s eyes. In one aspect, the electronic display 175 emits or projects light towards the user’s eyes according to image generated by the processor/image Tenderer 170.

In some embodiments, the lens 180 is a mechanical component that alters received light from the electronic display 175. The lens 180 may magnify the light from the electronic display 175, and correct for optical error 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 alters the light from the electronic display 175. Through the lens 180, light from the electronic display 175 can reach the pupils, such that the user can see the image displayed by the electronic display 175, despite the close proximity of the electronic display 175 to the eyes.

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 distortions or aberrations. In one aspect, the lens 180 introduces optical aberrations such as a chromatic aberration, a pin-cushion distortion, barrel distortion, etc. The compensator 185 may determine a compensation (e.g., predistortion) to apply to the image to be rendered from the processor/image Tenderer 170 to compensate for the distortions caused by the lens 180, and apply the determined compensation to the image from the processor/image Tenderer 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 rendered to the HWD 150. In one aspect, the console 110 includes a communication interface 115, one or more processors 116, a scheduler 118, and a content provider 130. These components may operate together to determine a view (e.g., a FOV of the user) of the artificial reality corresponding to the location of the HWD 150 and the gaze direction of the user of the HWD 150, and can generate image data indicating an image of the artificial reality corresponding to the determined view. In addition, these components may operate together to generate additional data associated with the image. Additional data may be information associated with presenting or rendering the artificial reality other than the image of the artificial reality. Examples of additional data include, hand model data, mapping information for translating a location and an orientation of the HWD 150 in a physical space into a virtual space (or simultaneous localization and mapping (SLAM) data), eye tracking data, motion vector information, depth information, edge information, object information, etc. The console 110 may provide the image data and the additional data to the HWD 150 for presentation of the artificial reality. In other embodiments, the console 110 includes more, fewer, or different components than shown in FIG. 1 . In some embodiments, the console 1 10 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 counterpart component to the communication interface 165 to communicate with a communication interface 115 of the console 110 through a communication link (e.g., wireless link). Through the communication link, the communication interface 115 may receive from the HWD 150 data indicating the determined location and/or orientation of the HWD 150, the determined gaze direction of the user, and the hand tracking measurement. Moreover, through the communication link, the communication interface 115 may transmit to the HWD 150 image data describing an image to be rendered and additional data associated with the image of the artificial reality.

In some embodiments, the processors 116 includes 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 processors 116 may configure or cause the communication interfaces 115 to toggle, transition, cycle or switch between a sleep mode and a wake up mode. In the wake up mode, the processors 116 may enable the communication interface 115, such that the communication interfaces 115, 165 may exchange data. In the sleep mode, the processors 116 may disable the wireless interface 115, such that the communication interfaces 115, 165 may not consume power, or may reduce power consumption.

In some embodiments, a scheduler 118 may request R-TWT to transmit latency sensitive traffic using P2P communication. Details of the scheduler 118 will be described in the following section.

The content provider 130 can include or correspond to a component that generates content to be rendered according to the location and/or orientation of the HWD 150. In some embodiments, the content provider 130 may incorporate the gaze direction of the user of the HWD 150, and a user interaction in the artificial reality based on hand tracking measurements to generate the content to be rendered. In one aspect, the content provider 130 determines a view of the artificial reality according to the location and/or orientation of the HWD 150. For example, the content provider 130 maps the location of the HWD 150 in 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 the mapped orientation from the mapped location in 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 transmit the image data to the HWD 150 through the communication interface 115. The content provider 130 may also generate a hand model corresponding to a hand of a user of the HWD 150 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. In some embodiments, the content provider 130 may generate additional data including motion vector information, depth information, edge information, object information, hand model data, etc., associated with the image, and transmit the additional data together with the image data to the HWD 150 through the communication interface 115. The content provider 130 may encode the image data describing the image, and can transmit the encoded data to the HWD 150 In some embodiments, the content provider 130 generates and provides the image data to the HWD 150 periodically (e.g., every 11 ms). In one aspect, the communication interface 115 can adaptively transmit the additional data to the HWD 150 as described below with respect to FIGS. 3 through 6. FIG. IB is a block diagram of an example artificial reality system environment 1000. FIG. IB provides an example environment 1000 in which devices may communicate traffic streams with different latency sensitivities/requirements. In some embodiments, the artificial reality system environment 1000 includes an access point (AP) 105, one or more head wearable displays (HWD) 150 (e.g., HWD 150A, 150B) worn by a user, and one or more consoles or computing devices 110 (computing devices 110A, HOB) providing content of artificial reality to the HWDs 150. The computing devices 110A, HOB may have configuration similar to that of computing device 110 shown in FIG. 1A. The HWDs 150A, 150B may have configuration similar to that of HWD 150 shown in FIG. 1 A. The access point 105 may be a router or any network device allowing one or more computing devices 110 and/or one or more HWDs 150 to access a network (e.g., the Internet). The access point 105 may be replaced by any communication device (cell site).

In some embodiments, the computing devices 110A, 110B communicate with the access point 105 through communication links 102A, 102B (e.g., interlinks), respectively. In some embodiments, the computing device 110A may communicate with the HWD 150A through a communication link 125 A (e.g., intralink), and the computing device 110B may communicate with the HWD 150B through a wireless link 125B (e.g., intralink).

In some embodiments, a scheduler 118 (e.g., scheduler 118A of the computing device 118A and/or scheduler 118B of the computing device 110B) may request R-TWT to transmit latency sensitive traffic using P2P communication. The AP 105 and scheduler 118 of the computing devices 1 10 may negotiate (e g., perform a handshake process) and may establish a membership of a restricted TWT schedule. In some embodiments, when the AP 105 and the scheduler 118 are negotiating, the AP 105 may be considered a restricted TWT scheduling AP and the computing devices 110 may be considered a restricted TWT scheduled STA.

In some embodiments, the HWD 150 may request to send P2P traffic to the computing device 110. Accordingly, the HWD 150 may be considered the TWT requesting STA (e.g., the TWT STA that requests the TWT agreement), and the computing device 110 may be considered TWT responding STA (e.g., the TWT STA that respond to the TWT request). The communication link 125 between the computing devices HO and the HWDs 150 may be a P2P link (e.g., a link used for transmission between two non-AP devices). The communication link 102 between the computing devices 110 and the AP 105 may be any channel or other type of link. In some configurations, the HWD 150 may move/become out of range from the access point 105. In other embodiments, the computing device 110 may request to send P2P traffic to the HWD 150 such that the computing device 110 is considered the TWT requesting STA and the HWD 150 is the TWT responding STA.

The schedulers 118 of the computing devices 110 may schedule communication between the computing device(s) 110 and the HWD(s) 150 with the AP 105 such that the communication between the computing device(s) 110 and HWD(s) 150 is protected. The computing device(s) 110 may initiate such protected P2P communication with the HWD(s) 150 by indicating, to the AP 105, that the computing device(s) 1 lOwish to schedule P2P communication in R-TWT service periods (SPs). The scheduler 118 of the computing device(s) may schedule (or negotiate) the requested R-TWT SP(s). The scheduler 118 of 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. 2 is a diagram of a HWD 150, in accordance with an example embodiment. In some embodiments, the HWD 150 includes a front rigid body 205 and a band 210. The front rigid body 205 includes the electronic display 175 (not shown in FIG. 2), the lens 180 (not shown in FIG. 2), the sensors 155, the eye trackers 160 A, 160B, the communication interface 165, and the processor/image Tenderer 170. In the embodiment shown by FIG. 2, the communication interface 165, the processor/image Tenderer 170, and the sensors 155 are located within the front rigid body 205, and may not visible to the user. In other embodiments, the HWD 150 has a different configuration than shown in FIG. 2. For example, the communication interface 165, the processor/image Tenderer 170, the eye trackers 160A, 160B, and/or the sensors 155 may be in different locations than shown in FIG. 2.

Various operations described herein can be implemented on computer systems. FIG. 3 shows a block diagram of a representative computing system 314 usable to implement the present disclosure. In some embodiments, the console 110, the HWD 150 or both of FIG. 1 are implemented by the computing system 314. Computing system 314 can 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 system 314 can be implemented to provide VR, AR, MR experience. In some embodiments, the computing system 314 can include conventional computer components such as processors 316, storage device 318, network interface 320, user input device 322, and user output device 324.

Network interface 720 can 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 interface 320 can 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.).

User input device 722 can include any device (or devices) via which a user can provide signals to computing system 314; computing system 314 can interpret the signals as indicative of particular user requests or information. User input device 322 can 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., motion sensor, an eye tracking sensor, etc.), and so on.

User output device 324 can include any device via which computing system 314 can provide information to a user. For example, user output device 324 can include a display to display images generated by or delivered to computing system 314. The display can incorporate various image generation technologies, e.g., a liquid crystal display (LCD), lightemitting 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 devices 324 can be provided in addition to or instead of a display. Examples include indicator lights, speakers, tactile “display” devices, printers, and so on.

Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a computer readable storage medium (e.g., non-transitory computer readable medium). Many of the features described in this specification can be implemented as processes that are 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 operation indicated in the program instructions. Examples of program instructions or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter. Through suitable programming, processor 316 can provide various functionality for computing system 314, including any of the functionality described herein as being performed by a server or client, or other functionality associated with message management services.

It will be appreciated that computing system 314 is illustrative and that variations and modifications are possible. Computer systems used in connection with the present disclosure can have other capabilities not specifically described here. Further, while computing system 314 is described with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. For instance, different blocks can be located in the same facility, in the same server rack, or on the same motherboard. Further, the blocks need not correspond to physically distinct components. Blocks can be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry , and various blocks might or might not be reconfigurable depending on how the initial configuration is obtained. Implementations of the present disclosure can be realized in a variety of apparatus including electronic devices implemented using any combination of circuitry and software.

In some embodiments, broadcast TWT schedules (including restricted TWT (R-TWT) schedules) may be announced via a TWT element with a negotiation type subfield thereof set to 2. FIG. 4 illustrates an example format of a TWT element field (TWT Information element (IE)) 400, according to an example implementation of the present disclosure. The TWT IE 400 may include the fields of element ID 411, length 412, control 413, and TWT parameter information 414 (e g., request type, target wake time, nominal minimum TWT wake duration, TWT wake interval mantissa, and/or broadcast TWT Information). In some embodiments, the control field 413 may include the subfields of null data packet (NDP) paging indicator 421, responder power management (PM) mode 422, negotiation type 423, TWT Information frame disabled 424, wake duration unit 425, link ID bitmap present 426, and/or reserved 427.

In some embodiments, the negotiation ty pe subfield 423 may indicate whether the information included in the TWT element is for the negotiation of parameters of broadcast TWT(s) including R-TWT) or individual TWT(s). For example, the negotiation type subfield set to the value of 2 (referred to as “negotiation type 2”) may indicate that the TWT element may be carrying schedule information (e.g., one or more schedules) of all schedules (or a portion of schedules) that exist in the network (e.g., WLAN). In other words, the TWT element with negotiation type 2 may announce schedules that are active and/or configured. Upon receiving a TWT announcement frame including a TWT element with negotiation type 2, a station (STA) (e.g., associated STA or another AP, receiving the TWT announcement frame) may leam/recognize/detect the announced schedules such that (1) the STA may request membership in the announced schedules and/or (2) the STA may follow rules. In some embodiments, one of the rules is that the STA receiving the TWT announcement frame may stop transmissions before the start of a R-TWT service period (SP) of the announced schedules (e.g., the STA may end its transmit opportunity before the start of the R-TWT SP), thereby reducing/avoiding interference or collision during the R-TWT SP. For example, an AP can make these announcements (using a TWT element with negotiation type 2) via broadcast frames including beacons, broadcast Probe Responses and/or fast initial link setup (FILS) Discovery frames. Such broadcast frames may be transmitted from an AP and received by all STA devices. In some embodiments, TWT schedule information (information of schedules carried in a TWT element with the negotiation type 2) may be delivered as an announcement via broadcast frames, most commonly in periodic beacons.

In a scenario where TWT schedule information is delivered as an announcement via broadcast frames, a STA (associated STA or another AP) may be limited in requesting the latest TWT schedule information from an AP so that the STA may wait for a next broadcast announcement to receive TWT schedule information. For example, a STA may join a network and may miss one or more beacons because the STA may be configured to sleep/save power and may periodically skip processing beacons. There may not be available mechanisms for a neighboring AP to retrieve TWT schedules in another basic service set (BSS).

Moreover, with the TWT schedule announcement mechanism via broadcast frames, an AP may have limited capability in delivering TWT schedule information to a particular STA. For example, an AP may only be configured to broadcast TWT schedules to associated STAs via announcement of schedules to all STAs so that all STAs can consume resources processing the received frame, resulting in inefficient resource management.

Furthermore, in some cases, the request and/or delivery of TWT schedule information may be used for different purposes depending on the device (e.g., depending on whether the device is an association STA or a neighboring AP). For example, for an associated STA, if the STA may miss a periodic beacon (e.g., due to sleep) and may not have the latest schedule information relating to an R-TWT schedule, the STA may not be able to end transmission at the start of the SP of the R-TWT schedule, thereby causing interference. On the other hand, for neighboring APs, it may be beneficial for the neighboring APs to be able to leam/recognize/detect overlapping BSS (OBSS) schedules to coordinate schedules to avoid interference.

To address these problems and/or benefits, disclosed herein includes systems, devices and methods for requesting, and/or delivering (or announcing) TWT schedules to individual STAs and/or APs. In some embodiments, an AP may deliver/announce/provide TWT schedule information in individually addressed frames (e.g., targeted to a specific recipient) such as Probe Response frames, Association Response frames, and Reassociation Response frames, TWT Setup frame, TWT Information frame, or other Action frames. In some embodiments, a new Action frame having the category or type of “TWT schedule information” may be defined such that the new Action frame can be flexibly utilized in schedule delivery of and/or request for TWT schedule information.

In one approach, an AP may deliver/announce/provide TWT schedule information in individually addressed frames to a particular device (e.g., associated STA or a neighboring AP). In some embodiments, a TWT element with negotiation type 2 may be included in individually addressed Probe Response frames. For example, an address of the particular device may be specified/contained in the field of destination address (DA) in a MAC header of a Probe Response frame. The particular device may be configured to support broadcast TWT.

In some embodiments, an AP (or a STA) may determine whether a first set of configuration values (e.g., dotl lTWTOptionActivated, dotl lHEOptionlmplemented, and dotl lFILSOmitReplicateProbeResponses) are true or not. For example, if the AP/STA determines that dotl ITWTOptionActivated, dotl IHEOptionlmplemented, and dotl IFILSOmitReplicateProbeResponses are true, the TWT element may be included or present within a broadcast Probe Response frame. In some embodiments, if the AP/STA determines that the AP/STA supports broadcast TWT, the TWT element may be included or present within a broadcast Probe Response frame. Otherwise, the TWT element may not be present in the Probe Response frame. If the TWT element is present in the (broadcast) Probe Response frame, then the negotiation type subfield of the TWT element may be set to 2.

In some embodiments, an AP (or a STA) may determine whether a second set of configuration values (e.g., dotl lTWTOptionActivated and dotl lHEOptionlmplemented) are true or not. For example, if the AP/STA determines that dotl ITWTOptionActivated and dotl IHEOptionlmplemented are true, the TWT element may be included or present within an individually addressed Probe Response frame (e.g., using the DA field in the MAC header of the Probe Response frame). In some embodiments, if the AP/STA determines that the AP/STA supports broadcast TWT, the TWT element may be included or present within an individually addressed Probe Response frame (e g., using the DA field in the MAC header of the Probe Response frame). Otherwise, the TWT element may not be present.in the Probe Response frame. If the TWT element is present in the (individually addressed) Probe Response frame, then the negotiation type subfield of the TWT element may be set to 2.

In some embodiments, an AP (or a STA) may include a TWT element with negotiation type 2 in individually addressed Association Response frames and/or individually addressed Reassociation Response frames (e.g., using destination address (DA) field in the MAC header of Association/Reassociation Response frames). In some embodiments, an Association/Reassociation Response frame including a TWT element with negotiation type 3 (with the negotiation type subfield set to the value of 3) may be considered/interpreted/decoded as a TWT Setup frame. Setting the negotiation type subfield to the value of 3 may indicate negotiation of membership in a TWT schedule (e.g., negotiation using request/response frames). The TWT element with negotiation type 3 may indicate setup frames for one or more TWT SPs (e.g., indicating information about one or more particular TWT SPs). In some embodiments, Association Response frames and Reassociation Response frames may indicate multiple TWT elements (e.g., a first TWT element with negotiation type 2, a second TWT element with negotiation type 3, or some combination).

In some embodiments, Association Response frames and/or Reassociation Response frames may indicate whether one or more TWT elements with negotiation type 3 are present therein. For example, given an Association Response frame, an AP (or a STA) may determine whether a third set of configuration values (e.g., dotl lTWTOptionActivated) are true or not. If the AP/STA determines that dotl ITWTOptionActivated is true, a TWT element with negotiation type 3 may be included or present within the Association Response frame. In some embodiments, if the AP/STA determines that the AP/STA supports broadcast TWT, a TWT element with negotiation type 3 may be included or present within the Association Response frame. The same indication method may be applied to a Reassociation Response frame.

In some embodiments, Association Response frames and/or Reassociation Response frames may indicate whether one or more TWT elements with negotiation type 2 are present therein. For example, given an Association Response frame, an AP (or a STA) may determine (1) whether a fourth set of configuration values (e.g., dotl lTWTOptionActivated and dotl IHEOptionlmplemented) are true or not; and (2) whether a TWT requester support field in the high-efficiency (HE) capabilities element in an Association Request frame (or Reassociation Request frame) that elicits/solicits/triggers the Association Response frame is set to a particular value (e.g., 1). If the AP/STA determines that (1) dotl ITWTOptionActivated and dotl IHEOptionlmplemented are true and (2) the TWT requester support field is set to the value of 1, the TWT element with negotiation type 2 may be included or present within the Association Response frame. In some embodiments, if the AP/STA determines that (1) the AP/STA supports broadcast TWT and (2) the TWT requester support field is set to the value of 1, the TWT element with negotiation type 2 may be included or present within the Association Response frame. Otherw ise, the TWT element may not be present.in the Association Response frame. The same indication method may be applied to a Reassociation Response frame.

In some embodiments, for a given Association Response frame, if a STA determines that (I) a TWT element with negotiation type 3 is present in an Association Request frame (or Reassociation Request frame) that elicits/solicits/triggers the Association Response frame but that (2) a TWT element with negotiation type 3 is not present in the Association Response frame, then the STA may transmit another TWT request frame to an AP after association with the AP. The same method may be applied to a Reassociation Response frame.

In some embodiments, a TWT element with negotiation type 2 may be included in a TWT Setup frame (or other Action frame) when transmitted by an AP. The TWT Setup frame may be individually addressed (e.g., using the DA field in a MAC header of the TWT Setup frame). In some embodiments, TWT Setup frames may include TWT elements with negotiation type 3. Additionally or alternatively, TWT Setup frames may include TWT elements with negotiation type 2. For example, a TWT Setup frame may include a first TWT element with negotiation type 2, a second TWT element with negotiation type 3, or some combination. In some embodiments, TWT Setup frames may indicate/include/contain one or more TWT elements.

In some embodiments, an AP may include one or more TWT elements with negotiation type 2, thereby enabling the AP to include TWT schedule information (e.g., latest TWT schedule information) at the end of a TWT Setup negotiation. For example, an AP and a STA may negotiate membership of a particular TWT schedule. Nearing the end of the negotiation (e.g., the AP may accept the STA as a member of the TWT schedule), the AP may indicate the latest TWT schedule to the STA using a TWT element with negotiation type 2 in the TWT Setup frame. An example TWT Setup frame action field format is shown in Table 1. In a TWT Setup frame, the Unprotected SIG Action field (see Table 1) may be set to a value indicating “TWT Setup.”

Table 1. Example TWT Setup Frame Action Field Format

In some embodiments, a TWT element with negotiation type 2 may be included in a TWT Information frame (or other Action frame). The TWT Setup frame may be individually addressed (e.g., using the DA field in a MAC header of the TWT Information frame). An example TWT Information frame action field format is shown in Table 2. In a TWT Information frame, the Unprotected SIG Action field (see Table 2) may be set to a value indicating “TWT Information.”

Table 2. Example TWT Information Frame Action Field Format

In one approach, a new Action frame having the category or type of “TWT schedule information” may be defined such that the new Action frame can be flexibly utilized in schedule delivery of and/or request for TWT schedule information. A TWT Schedule Information frame may be a new Unprotected SIG Action frame. An example TWT Schedule Information frame action field format is shown in Table 3.

Table 3. Example TWT Schedule Information Frame Action Field Format

Referring to Table 3, a newly defined TWT Schedule Information frame may include the fields of category, Unprotected SIG Action, schedule information control, and/or TWT element. The category field may be set to a value indicating “Unprotected SIG Action frame.” The Unprotected SIG Action field may be set to a value indicating “TWT schedule information” (e.g., a next available value or any other value). The schedule information control field may be 1 octet (1 byte) long. In some embodiments, the schedule information control field may include the subfields of request and/or reserved. The request subfield may be 1 bit long, indicating whether the TWT Schedule Information frame is a request frame or a response frame. In some embodiments, if the request subfield is set to a first value (e.g., 0), a TWT element with negotiation type 2 may be present in the TWT Schedule Information frame. For example, APs may set the request subfield to the value of 0 to respond/deliver a TWT element with latest TWT schedule information with negotiation type 2. On the other hand, STAs may set the request subfield to a second value (e.g., 1) to request TWT schedule, for example. A TWT element may not be present in a TWT Schedule Information frame if the request subfield in the schedule information control field is set to the second value (e.g., 1).

In one approach, a STA (e.g., STA associated with an AP, or another AP) may request/elicit/solicit TWT schedule information (e.g., latest TWT schedule information) from the AP. In some embodiments, the STA may use a TWT Schedule Information frame as shown in Table 3 to request TWT schedule information from the AP. For example, a STA (associated STA or another AP) may request latest TWT schedule information from an AP by sending a TWT Schedule Information frame with the request subfield (in the schedule information control field) set to the second value (e.g., 1). If an AP (e.g., a TWT scheduling AP) receives a TWT Schedule Information frame from a STA (STA associated with the AP, or another AP) with the request subfield (in the schedule information control field) set to the second value (e.g., 1), the TWT scheduling AP may deli ver/announce/pro vide TWT schedule information (e.g., the latest TWT schedule information) to the corresponding STA by sending a TWT Schedule Information frame carrying a TWT element with negotiation type 2 with the request subfield set to the first value (e.g., 0).

In one approach, a STA (e.g., STA associated with an AP, or another AP) may request/elicit/solicit TWT schedule information from the AP by sending a request frame including a TWT element in a modified format (referred to as “modified TWT (M-TWT) element”). In some embodiments, in an M-TWT element, the control field may be modified to indicate a request for TWT schedule information. In some embodiments, one or more bits of the control field may be repurposed/appended/modified to indicate a request for TWT schedule information. For example, in an M-TWT element, a reserved bit in the control field (e.g., bit 7 of the control field) may be repurposed for the subfield of “TWT schedule request” subfield. The TWT schedule request subfield of the control field in an M-TWT element may be set to a particular value (e.g., 1) to indicate that a frame including the M- TWT element is a request frame (for TWT schedule information). Upon receiving a request frame that carries a modified TWT element, the AP may respond to the request frame according to the request frame (e.g., according to the frame ty pe of the request frame).

In some embodiments, an M-TWT element may be included in a Probe Request frame. In some embodiments, Probe Request frames may indicate whether one or more M- TWT elements are present therein. For example, given a Probe Request frame, an AP (or STA) may determine whether a fifth set of configuration values (e g., dotl ITWTOptionActivated and dotl IHEOptionlmplemented) are true or not. For example, if the AP/STA detennines that dotl ITWTOptionActivated and dotl IHEOptionlmplemented are true, an M-TWT element may be included or present within the Probe Request frame. In some embodiments, when an M-TWT element is present in the Probe Request frame, the TWT schedule request subfield of the control field in the M-TWT element may be set to the particular value (e.g., 1), and the M-TWT element may not contain TWT parameter information field(s). For example, if the TWT schedule request subfield is set to the particular value (e.g., 1) in an M-TWT element included in a Probe Request frame, other subfields in the control field, including the negotiation type subfield, may be reserved and the M-TWT element may not contain TWT parameter information fields. If the TWT scheduling AP receives a Probe Request frame with the M-TWT element, the AP may include a TWT element with negotiation type 2 in a Probe Response frame for TWT schedule delivery.

In some embodiments, an M-TWT element may be included in a TWT Information frame which has a format similar to that shown in Table 2. For example, a STA may set the TWT schedule request in the included M-TWT element to the particular value (e.g., 1) and the STA may not include any TWT parameter information fields in the M-TWT element. If the TWT scheduling AP receives, from a STA, a TWT Information frame carrying an M- TWT element with the TWT schedule request subfield set to the particular value (e.g., 1), the AP may send another TWT Information frame to the corresponding STA and include a TWT element with negotiation type 2 for TWT schedule delivery.

In some embodiments, an M-TWT element may be included in a TWT Setup frame which has a format similar to that shown in Table 1. In this manner, a STA can request TWT schedule information using the existing TWT Setup frame format as shown in Table 1 (except for including the M-TWT element). For example, a STA may set the TWT schedule request in the included M-TWT element to the particular value (e.g., 1) and the STA may not include any TWT parameter information fields in the M-TWT element. The M-TWT element may be carried in the TWT Setup frame if the STA wants/intends to request TWT schedule information (e.g., latest TWT schedule) from the AP and/or establish membership in TWT schedule(s).

In some embodiments, a STA may request for TWT schedule information (e.g., the latest TWT schedule information) using a TWT Setup frame including a M-TWT element in the following two ways. First, when establishing membership in a broadcast TWT schedule, the STA may set the negotiation type subfield in the M-TWT element to the value of 3 such that the M-TWT element may include/contain at least one TWT parameter information field, and can set the TWT schedule request subfield to the particular value (e.g., 1). Second, when separately requesting TWT schedule information in a TWT Setup frame without requesting membership in any broadcast TWT schedule, the STA may set the TWT schedule request subfield to the particular value (e.g., 1) such that the M-TWT element may not include/contain any TWT parameter information field and other subfields in the control field of the M-TWT element (e.g., negotiation type subfield) may be reserved or ignored. In some embodiments, if a STA sets the TWT schedule request subfield (in the control field of a M- TWT element) to the particular value (e.g., 1) in a TWT Setup frame, it may indicate to an AP that the STA is requesting the latest broadcast TWT schedule. If the TWT scheduling AP receives, from a STA, a first TWT Setup frame carrying an M-TWT element with the TWT schedule request subfield set to the particular value (e.g., 1), the AP may include a TWT element with negotiation type 2 in a second TWT Setup frame and may send the second TWT Setup frame (for TWT schedule delivery) as a response to the first TWT Setup frame.

In one approach, an access point (AP) device may have one or more processors. The one more processors may generate a frame including information on a target wake time (TWT) schedule. The one more processors may set a first subfield of the frame to an address of a receiver device receiving the frame over a wireless local area network (WLAN). The one more processors may wirelessly transmit, via a transmitter over the WLAN, the generated frame to the receiver device.

In some embodiments, the TWT schedule may be a restricted TWT (R-TWT) schedule. In some embodiments, the one or more processors may be configured to determine whether a configuration value of the device is true. In response to the configuration value of the device being true, the one or more processors may be configured to set the first subfield of the frame to the address of the receiver device. In some embodiments, the one or more processors may be configured to set a second subfield of the frame to a value indicating that the frame is to convey the TWT schedule to one or more devices. In some embodiments, the frame may be one of a Probe Response frame, an Association Response frame, a Reassociation Response frame, a TWT Setup frame, or a TWT Information frame. In some embodiments, the TWT schedule may include a plurality of TWT schedules including a first TWT schedule and a second TWT schedule. The one or more processors may be configured to set a second subfield of the frame to a first value indicating that the frame is to convey the first TWT schedule to one or more devices, and may set a third subfield of the frame to a second value indicating the frame relates to negotiation of membership in the second TWT schedule.

In some embodiments, the frame may be an Action frame. The one or more processors may be configured to set an action subfield of the Action frame to a value indicating TWT schedule information. The one or more processors may be configured to receive, via a receiver from the receiver device, another Action frame whose action subfield is set to the value indicating the TWT schedule information. The one or more processors may be configured to determine whether a request subfield of the another Action frame is set to a third value indicating a request for the TWT schedule information. In response to the request subfield of the another Action frame being set to the third value, the one or more processors may be configured to set a request subfield of the Action frame to a fourth value that is different from the third value and indicates a response to the request for the TWT schedule information.

In some embodiments, the one or more processors may be configured to receive another frame from the receiver device. The one or more processors may be configured to determine whether a fourth subfield of the another frame is set to a sixth value indicating a request for TWT schedule information. In response to the fourth subfield of the another frame being set to the sixth value, the one or more processors may be configured to generate the frame such that the frame is a response frame to the another frame. The another frame may be one of a Probe Request frame, a TWT Information frame, or a TWT Setup 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 (1) announcing/delivering/providing TWT schedule information to (e g., addressed to) a particular device (e.g., non-AP STA or neighboring AP) using individually addressed frames and (2) requesting/soliciting/eliciting TWT schedule information from an AP. With this configuration, a STA can request the latest TWT schedule information dynamically from an AP without waiting for a next broadcast/scheduled announcement to receive TWT schedule information.

Second, embodiments in the present disclosure can provide useful techniques for announcing/delivering/providing TWT schedule information to only a subset of all STAs. With this configuration, only the desired subset of all the STAs can receive TWT schedule information, such that not all STAs are required/caused to consume resources processing the received frame, resulting in more efficient resource management.

Third, embodiments in the present disclosure can provide useful techniques for coordinating TWT schedules to avoid interference. For example, for an associated STA, if the STA is to miss a periodic beacon (e.g., due to sleep), the STA can request TWT schedule information and can receive from the AP the latest TWT schedule information relating to an R-TWT schedule. In this manner, the STA can (schedule itself to) end transmission before/by/at the start of the SP of the R-TWT schedule, thereby avoiding interference. For neighboring APs, the neighboring APs cans leam/recognize/detect overlapping BSS (OBSS) schedules to coordinate schedules to avoid interference.

FIG. 5 A to FIG. 5D each illustrates an example format of individually addressed frames using TWT element fields for announcing one or more TWT schedules, according to example implementations of the present disclosure. FIG. 5A illustrates an example format of an individually addressed Probe Response frame 500 according to an example implementation of the present disclosure. The Probe Response frame 500 may include an address of a particular device (e.g., MAC address of a particular STA or a neighboring AP) in the destination address field 51 1 of the MAC header 510 of the Probe Response frame. The Probe Response frame 500 may include a TWT element 512.

In some embodiments, Probe Response frames may indicate whether a TWT element is present therein. An AP (or a STA) may determine whether a first set of configuration values (e.g., dotllTWTOptionActivated, dotl IHEOptionlmplemented, and dotl lFILSOmitReplicateProbeResponses) are true or not. For example, if the AP/STA determines that dotl ITWTOptionActivated, dotl IHEOptionlmplemented, and dotl IFILSOmitReplicateProbeResponses are true, a TWT element may be included or present within a broadcast Probe Response frame. In some embodiments, if the AP/STA determines that the AP/STA supports broadcast TWT, the TWT element may be included or present within a broadcast Probe Response frame. Otherwise, a TWT element may not be present, in the (broadcast) Probe Response frame. If the TWT element is present in the (broadcast) Probe Response frame, then the negotiation type subfield of the TWT element (e.g., negotiation type subfield 423 of TWT element 400) may be set to 2. In some embodiments, an AP (or a STA) may determine whether a second set of configuration values (e.g., dotl lTWTOptionActivated and dotl lHEOptionlmplemented) are true or not. For example, if the AP/STA determines that dotl ITWTOptionActivated and dotl IHEOptionlmplemented are true, a TWT element (e.g., TWT IE 512) may be included or present within an individually addressed Probe Response frame (e.g., Probe Response frame 500). The Probe Response frame 500 may be individually addressed using the DA field 511 in the MAC header 510 of the Probe Response frame. In some embodiments, if the AP/STA determines that the AP/STA supports broadcast TWT, a TWT element may be included or present within an individually addressed Probe Response frame (e.g., using the DA field in the MAC header of the Probe Response frame). Otherwise, a TWT element may not be present in the Probe Response frame. If a TWT element 512 is present in the (individually addressed) Probe Response frame 500, then the negotiation ty pe subfield of the TWT element 512 may be set to 2 for example.

FIG. 5B illustrates an example format of an individually addressed association (or reassociation) response frame 520 according to an example implementation of the present disclosure. The Association Response frame 520 may include an address of a particular device (e.g., MAC address of a particular STA or a neighboring AP) in the destination address field 531 of the MAC header 530 of the Association Response frame. The Association Response frame 520 may include one or more TWT elements 532-1, 532-2.

In some embodiments, an AP (or a STA) may include a TWT element (e.g., TWT IE 532-1) with negotiation type 2 in an individually addressed Association Response frame (e g., Association Response frame 520). The Association Response frame 520 may be individually addressed using the destination address (DA) field 531 in the MAC header 530 of the Association Response frame 520. In some embodiments, an association/reassociation frame including a TWT element (e.g., TWT IE 532-2) with negotiation type 3 (with the negotiation ty pe subfield set to the value of 3) may be considered/interpreted/decoded as a TWT Setup frame. Setting the negotiation type subfield to the value of 3 may indicate negotiation of membership in a TWT schedule (e.g., negotiation using request/response frames). The TWT element with negotiation type 3 may indicate setup frames for one or more TWT SPs (e.g., indicating information about one or more particular TWT SPs). In some embodiments, the Association Response frame 520 may indicate multiple TWT IES 532-1, 532-2 such that the first TWT IE 532-1 with negotiation type 2 and the second TWT IE 532-2 with negotiation ty pe 3.

In some embodiments, Association Response frames and/or Reassociation Response frames may indicate whether one or more TWT elements with negotiation type 3 are present therein. For example, given an Association Response frame (e.g., Association Response frame 520), an AP (or a STA) may determine whether a third set of configuration values (e.g., dotl ITWTOptionActivated) are true or not. If the AP/STA determines that dotl ITWTOptionActivated is true, an TWT element with negotiation type 3 (e.g., TWT IE 532-2) may be included or present within the Association Response frame 520. In some embodiments, if the AP/STA determines that the AP/STA supports broadcast TWT, a TWT element with negotiation type 3 (e g , TWT IE 532-2) may be included or present within the Association Response frame 520. The same indication method may be applied to a Reassociation Response frame.

In some embodiments, Association Response frames and/or Reassociation Response frames may indicate whether one or more TWT elements with negotiation type 2 are present therein. For example, given an Association Response frame (e.g., Association Response frame 520), an AP (or a STA) may determine (1) whether a fourth set of configuration values (e.g., dotl ITWTOptionActivated and dotl IHEOptionlmplemented) are true or not; and (2) whether a TWT requester support field in the high-efficiency (HE) capabilities element (not shown) in the Association Request frame (not shown) that elicits/solicits/triggers the Association Response frame 520 is set to a particular value (e.g., 1). If the AP/STA determines that (1) dotl ITWTOptionActivated and dotl IHEOptionlmplemented are true and (2) the TWT requester support field is set to the value of 1, the TWT element with negotiation type 2 (e g , TWT IE 532-1 ) may be included or present within the Association Response frame 520. In some embodiments, if the AP/STA determines that (1) the AP/STA supports broadcast TWT and (2) the TWT requester support field is set to the value of 1, the TWT element with negotiation type 2 (e.g., TWT IE 532-1) may be included or present within the Association Response frame 520. Otherwise, a TWT element may not be present.in the Association Response frame. The same indication method may be applied to a Reassociation Response frame.

In some embodiments, for a given Association Response frame (e.g., Association Response frame 520), if a STA determines that (I) a TWT element with negotiation type 3 is present in an Association Request frame (not shown) that elicits/solicits/triggers the Association Response frame but that (2) a TWT element with negotiation type 3 is not present in the Association Response frame, then the STA may transmit another TWT request frame to an AP after association with the AP. The same method may be applied to a Reassociation Response frame. FIG. 5C illustrates an example format of an individually addressed TWT Setup frame 540 according to an example implementation of the present disclosure. The TWT Setup frame 540 may include an address of a particular device (e.g., MAC address of a particular STA or a neighboring AP) in the destination address field 551 of the MAC header 550 of the TWT Setup frame 540. The TWT Setup frame 540 may have a format similar to that shown in Table 1. For example, TWT Setup frame 540 may include the fields of category 552, Unprotected SIG Action 554, dialog token 556, and/or one or more TWT elements 558-1, 558-2.

In some embodiments, a TWT element with negotiation type 2 (e.g., TWT IE 558-1) may be included in a TWT Setup frame (e.g., TWT Setup frame 540) when transmitted by an AP. The TWT Setup frame 540 may be individually addressed using the DA field 551 in the MAC header 550 of the TWT Setup frame 540. In some embodiments, TWT Setup frames may include TWT elements with negotiation type 3 (e.g., TWT IE 558-2). Additionally or alternatively, TWT Setup frames may include TWT elements with negotiation type 2 (e.g., TWT IE 558-1). For example, the TWT Setup frame 540 may include a first TWT IE 558-1 with negotiation type 2, a second TWT IE 558-2 with negotiation type 3. In some embodiments, TWT Setup frames may indicate/include/contain one or more TWT elements.

In some embodiments, an AP may include one or more TWT elements with negotiation type 2, thereby enabling the AP to include TWT schedule information (e.g., latest TWT schedule information) at the end of a TWT setup negotiation. For example, an AP and a STA may negotiate membership of a particular TWT schedule. Nearing the end of the negotiation (e.g., the AP may accept the STA as a member of the TWT schedule), the AP may indicate the latest TWT schedule to the STA using a TWT element with negotiation type 2 (e.g., TWT IE 558-1) in the TWT Setup frame 540. An example TWT Setup frame action field format is shown in Table 1. In the TWT Setup frame 540, the Unprotected SIG Action field 554 (see Table 1) may be set to a value indicating “TWT Setup.”

FIG. 5D illustrates an example format of an individually addressed TWT Information frame 560 according to an example implementation of the present disclosure. The TWT Information frame 560 may include an address of a particular device (e.g., MAC address of a particular STA or a neighboring AP) in the destination address field 571 of the MAC header 570 of the TWT Information frame 560. The TWT Information frame 560 may have a format similar to that shown in Table 2. For example, TWT Information frame 560 may include the fields of category 572, Unprotected SIG Action 574, TWT Information 576, and/or a TWT element 578. In some embodiments, a TWT element with negotiation type 2 (e.g., TWT IE 578) may be included in the TWT Information frame 560. The TWT Setup frame 560 may be individually addressed using the DA field 571 in the MAC header 570 of the TWT Information frame 560. An example TWT Information frame action field format is shown in Table 2. In the TWT Information frame 560, the Unprotected SIG Action field 574 (see Table 2) may be set to a value indicating “TWT Information.”

FIG. 6 illustrates an example format of an individually addressed frame 600 for announcing/sending/conveying one or more TWT schedules, according to another example implementation of the present disclosure. The frame 600 may be an Action frame with a newly defined type of “TWT Schedule Information frame.” In some embodiments, a new Action frame having the category or t pe of “TWT schedule information” (e.g., TWT Schedule Information frame 600) may be defined such that the new Action frame can be flexibly utilized in schedule delivery of and/or request for TWT schedule information. The TWT Schedule Information frame 600 may be a new Unprotected SIG Action frame. An example TWT Schedule Information frame action field format is shown in Table 3.

Referring to FIG. 6, the TWT Schedule Information frame 600 may include/indicate/specify an address of a particular device (e.g., MAC address of a particular STA or a neighboring AP) in the destination address field 611 of the MAC header 610 of the TWT Schedule Information frame 600. The TWT Schedule Information frame 600 may include the fields of category' 612, Unprotected SIG Action 614, schedule information control 616, and/or a TWT element 618. The schedule information control field 616 may include the subfield of request 620 and/or reserved 622. The category field 623 may be set to a value indicating “Unprotected SIG Action frame.” The Unprotected SIG Action field 614 may be set to a value indicating “TWT schedule information” (e.g., a next available value or any other value). The schedule information control field 616 may be 1 octet (1 byte) long. In some embodiments, the schedule information control field 616 may include the subfields of request 620 and/or reserved 622. The request subfield 620 may be 1 bit long, indicating whether the TWT Schedule Information frame is a request frame or a response frame. In some embodiments, if the request subfield 620 is set to a first value (e.g., 0), a TWT element with negotiation type 2 (e.g., TWT IE 618) may be present in the TWT Schedule Information frame. For example, APs may set the request subfield to the value of 0 to respond/deliver a TWT element (e.g., TWT IE 618) with latest TWT schedule information with negotiation ty pe 2. On the other hand, STAs may set the request subfield 620 to a second value (e.g., 1) to request TWT schedule information, for example. A TWT element may not be present in a TWT Schedule Information frame if the request subfield 620 in the schedule information control field 616 is set to the second value (e.g., 1).

In some embodiments, a STA (e.g., STA associated with an AP, or another AP) may request/elicit/solicit TWT schedule information (e.g., latest TWT schedule information) from the AP. In some embodiments, the STA may use a TWT Schedule Information frame (e.g., TWT Schedule Information frame 600) to request TWT schedule information from the AP. For example, a STA (associated STA or another AP) may request latest TWT schedule information from an AP by sending the TWT Schedule Information frame 600 with the request subfield 620 (in the schedule information control field 616) set to the second value (e.g., 1). If an AP (e.g., a TWT scheduling AP) receives the TWT Schedule Information frame 600 from a STA (STA associated with the AP, or another AP) with the request subfield 620 (in the schedule information control field) set to the second value (e.g., 1), the TWT scheduling AP may deliver/announce/provide TWT schedule information (e.g., the latest TWT schedule information) to the corresponding STA by sending another TWT Schedule Information frame carrying a TWT element with negotiation type 2 with the request subfield set to the first value (e.g., 0).

FIG. 7 illustrates an example format of a modified TWT (M-TWT) element field (M- TWT IE) 700, according to an example implementation of the present disclosure. In some embodiments, a STA (e.g., STA associated with an AP, or another AP) may request/elicit/solicit TWT schedule information from the AP by sending a request frame including a TWT element in a modified format (referred to as “modified TWT element (M- TWT IE)”). The M-TWT IE 700 may include the fields of element ID 711, length 712, control 713, and TWT parameter information 714 (e.g., request type, target wake time, nominal minimum TWT wake duration, TWT wake interval mantissa, and/or broadcast TWT information). In some embodiments, the control field 713 may include the subfields of NDP paging indicator 721, responder PM mode 722, negotiation type 723, TWT information frame disabled 724, wake duration unit 725, link ID bitmap present 726, and/or TWT schedule request 430. The M-TWT IE 700 may have format similar to that of TWT IE 400 except for the M-TWT IE 700 includes the TWT schedule request subfield 730 instead of the reserved subfield 427 (see FIG. 4).

Referring to FIG. 7, in the M-TWT element 700, the control field 713 may indicate a request for TWT schedule information. In some embodiments, one or more bits of the control field 713 may be repurposed/appended/modified/configured/designed to indicate a request for TWT schedule information. For example, in the M-TWT element 700, a reserved bit in the control field (e.g., the bit 7 (as the reserved subfield 427) of the control field 413) may be repurposed/ configured for the subfield of “TWT schedule request” subfield 730. The TWT schedule request subfield 730 of the control field 713 in the M-TWT element 700 may be set to a particular value (e.g., 1) to indicate that a frame including the M-TWT element 700 is a request frame (for TWT schedule information). Upon receiving a request frame that carries an M-TWT IE, the AP may respond to the request frame according to the frame type of the request frame (e.g., Probe Request, TWT Information, or TWT Setup).

FIG. 8A to FIG. 8C illustrate example format(s) of frames including modified TWT element fields (e.g., M-TWT IE as shown in FIG. 7) for requesting TWT schedule information, according to example implementations of the present disclosure.

FIG. 8A illustrates an example format of a Probe Request frame 800 according to an example implementation of the present disclosure. The Probe Request frame 800 may include an M-TWT element (M-TWT IE) 802 with the TWT schedule request subfield 803. In some embodiments, the M-TWT IE 802 may be included in the Probe Request frame 800. In some embodiments, Probe Request frames may indicate whether one or more M-TWT elements are present therein. For example, given a Probe Request frame, an AP (or STA) may determine whether a fifth set of configuration values (e.g., dotl ITWTOptionActivated and dotl IHEOptionlmplemented) are true or not. For example, if the AP/STA determines that dotl ITWTOptionActivated and dotl IHEOptionlmplemented are true, an M-TWT element may be included or present within the Probe Request frame. In some embodiments, when the M-TWT IE 802 is present in the Probe Request frame 800, the TWT schedule request subfield 803 of the control field (not shown) in the M-TWT IE 802 may be set to the particular value (e.g., 1), and the M-TWT IE 802 may not contain TWT parameter information field(s). For example, If the TWT schedule request subfield 803 is set to the particular value (e.g., 1) in the M-TWT IE 802 included in the Probe Request frame 800, other subfields in the control field, including the negotiation type subfield, may be reserved and the M-TWT IE 802 may not contain TWT parameter information fields. If the TWT scheduling AP receives the Probe Request frame 800 including the M-TWT IE 802 (with the TWT schedule request subfield 803 set to I), the AP may include a TWT element with negotiation type 2 in a Probe Response frame for TWT schedule delivery (e.g., Probe Response frame 500 in FIG. 5A).

FIG. 8B illustrates an example format of a TWT Information frame 830 according to an example implementation of the present disclosure. The TWT Information frame 830 may have a format similar to that shown in Table 2. For example, the TWT Information frame 830 may include the fields of category 832, Unprotected SIG Action 834, TWT Information 836, and/or an M-TWT element 838 with the TWT schedule request subfield 839. For example, a STA may set the TWT schedule request 839 in the included M-TWT IE 838 to the particular value (e.g., 1) and the STA may not include any TWT parameter information fields in the M- TWT IE 838. If the TWT scheduling AP receives, from a STA, the TWT Information frame 830 carrying the M-TWT IE 838 with the TWT schedule request subfield 839 set to the particular value (e.g., I), the AP may send another TWT Information frame to the corresponding STA and include a TWT element with negotiation ty pe 2 in the another TWT Information frame for TWT schedule delivery (e.g., TWT Information frame 560 in FIG. 5D).

FIG. 8C illustrates an example format of a TWT Setup frame 850 according to an example implementation of the present disclosure. The TWT Setup frame 850 may have a format similar to that show n in Table 1. For example, the TWT Setup frame 850 may include the fields of category 852, Unprotected SIG Action 854, dialog token 856, and/or an M-TWT IE 858 with the TWT schedule request subfield 859. In some embodiments, the M-TWT IE 858 may be included in the TWT Setup frame 850 which has a format similar to that shown in Table 1. In this manner, a STA can request TWT schedule information using the existing TWT Setup frame format as shown in Table 1 (except for one or more TWT elements are replaced with one or more M-TWT elements). For example, a STA may set the TWT schedule request 859 in the included M-TWT IE 858 to the particular value (e.g., 1) and the STA may not include any TWT parameter information fields in the M-TWT IE 858. In some embodiments, the M-TWT IE 858 may be carried in the TWT Setup frame 850 if the STA wants/intends to request TWT schedule information (e.g., latest TWT schedule) from the AP and/or establish membership in TWT schedule(s).

In some embodiments, a STA may request for TWT schedule information (e.g., the latest TWT schedule information) using a TWT Setup frame (e.g., TWT Setup frame 850) including a M-TWT element (e.g., M-TWT IE 858) in the following two ways. First, when establishing membership in a broadcast TWT schedule, the STA may set the negotiation ty pe subfield in the M-TWT IE 858 to the value of 3 such that the M-TWT IE 858 may contain at least one TWT parameter information field, and set the TWT schedule request subfield 859 to the particular value (e.g., 1). Second, when separately requesting TWT schedule information in a TWT Setup frame (e.g., TWT Setup frame 850) without requesting membership in any broadcast TWT schedule, the STA may set the TWT schedule request subfield 859 to the particular value (e.g., 1) such that the M-TWT IE 858 may not contain any TWT parameter information field and other subfields in the control field of the M-TWT IE 858 (e.g., negotiation type subfield) may be reserved or ignored. In some embodiments, if a STA sets the TWT schedule request subfield 859 in the control field of the M-TWT IE 858 to the particular value (e.g., 1) in the TWT Setup frame 850, it may indicate to an AP that the STA is requesting latest broadcast TWT schedule. If the TWT scheduling AP receives, from a STA, a first TWT Setup frame carrying an M-TWT element with the TWT schedule request subfield set to the particular value (e.g., I), the AP may include a TWT element with negotiation type 2 in a second TWT Setup frame (e g., TWT Setup frame 540 in FIG. 5C) and send the second TWT Setup frame (for TWT schedule delivery) as a response to the first TWT Setup frame.

FIG. 9 is a flowchart showing a process of announcing/providing/conveying one or more TWT schedules using an individually addressed frame, according to an example implementation of the present disclosure. In some embodiments, the process 900 is performed by an AP device (e.g., an AP 105). In some embodiments, the process 900 is performed by other entities. In some embodiments, the process 900 includes more, fewer, or different steps than shown in FIG. 9.

In one approach, the AP device may generate 902 a frame including information on a TWT schedule (e.g., Probe Response frame 500, (Re)association Response frame 520, TWT Setup frame 540, TWT Information frame 560, TWT Schedule Information frame 600). In some embodiments, the TWT schedule may be a restricted TWT (R-TWT) schedule.

In one approach, the AP device may set 904 a first subfield of the frame (e.g., destination address field 511, 531, 551, 572) to an address of a receiver device (e.g., non-AP STA associated with the AP device, or a neighboring AP) receiving the frame over a WLAN. In some embodiments, the AP device may determine whether a configuration value of the device is true (e.g., dotl lTWTOptionActivated and dotl lHEOptionlmplemented are true). In response to the configuration value of the device being true, the AP device may set the first subfield of the frame to the address of the receiver device.

In some embodiments, the AP device may set a second subfield (e.g., negotiation type 423) of the frame to a value (e.g., negotiation type 2) indicating that the frame is to convey the TWT schedule to one or more devices In some embodiments, the TWT schedule may include a plurality of TWT schedules including a first TWT schedule (e.g., TWT schedule specified in TWT IE 532-1) and a second TWT schedule (e.g., TWT schedule specified in TWT IE 532-2). The AP device may set a second subfield (e.g., negotiation type subfield of TWT IE 532-1) of the frame to a first value (e.g., negotiation type 2) indicating that the frame is to convey the first TWT schedule to one or more devices. The AP device may set a third subfield (e.g., negotiation type subfield of TWT IE 532-2) of the frame to a second value (e.g., negotiation type 3) indicating the frame relates to negotiation of membership in the second TWT schedule. In some embodiments, the frame may be one of a Probe Response frame (e.g., Probe Response frame 500), an Association Response frame (e.g., Association Response frame 520), a Reassociation Response frame (e.g., Reassociation Response frame 520), a TWT Setup frame (e g., TWT Setup frame 540), or a TWT Information frame (e.g., TWT Information frame 560).

In some embodiments, the frame may be an Action frame (e.g., TWT Setup frame 540, TWT Information frame 560, or TWT Schedule Information frame 600). The AP device may set an action subfield (e.g., Unprotected SIG Action subfield 614) of the Action frame to a value indicating TWT schedule information. The AP device may receive, via a receiver of the AP device, from the receiver device, another Action frame (e.g., a request frame for TWT schedule information) whose action subfield is set to the value indicating the TWT schedule information. The AP device may determine whether a request subfield (e.g., request subfield 620) of the another Action frame is set to a third value (e.g., 1) indicating a request for the TWT schedule information. In response to the request subfield of the another Action frame being set to the third value, the AP device may set a request subfield (e.g., request subfield 620) of the Action frame (e.g., a response frame in response to the request frame for TWT schedule information) to a fourth value (e.g., 0) that is different from the third value and indicates a response to the request for the TWT schedule information.

In some embodiments, the AP device may receive another frame (e.g., Probe Request frame 800, TWT Information frame 830, TWT Setup frame 850) from the receiver device. The AP device may determine whether a fourth subfield (e.g., TWT schedule request subfield 730, 803, 839, 858) of the another frame is set to a sixth value (e.g., 1) indicating a request for TWT schedule information. In response to the fourth subfield of the another frame being set to the sixth value, the AP device may generate the frame such that the frame is a response frame to the another frame. For example, the AP may generate a Probe Response frame (e.g., Probe Response frame 500) in response to a Probe Request frame (e.g.. Probe Request frame 800). The AP may generate a response TWT Information frame (e g., TWT Information frame 560) in response to a request TWT Information frame (e.g., TWT Information frame 830). The AP may generate a response TWT Setup frame (e.g., TWT Setup frame 540) in response to a request TWT Setup frame (e.g., TWT Setup frame 850). The another frame may be one of a Probe Request frame (e.g., Probe Request frame 800), a TWT Information frame (e.g., TWT Information frame 830), or a TWT Setup frame (e.g., TWT Setup frame 850).

In one approach, the AP device may wirelessly transmit 906, via a transmitter over the WLAN, the generated frame to the receiver device.

Having now described some illustrative implementations, 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 can be combined in other ways to accomplish the same objectives. Acts, elements and features discussed in connection with one implementation are not intended to be excluded from a similar role in other implementations or implementations.

The hardware and data processing components used to implement the various processes, operations, illustrative logics, logical blocks, modules and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete 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 also may 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 in conjunction with a DSP core, or any other such configuration. In some embodiments, particular processes and methods may be performed by circuitry that is specific 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 storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present disclosure. The memory may be or include volatile memory' or non-volatile memory, and may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. According to an exemplary embodiment, the memory is communicably connected to the processor via a processing circuit and includes computer code for executing (e.g., by the processing circuit and/or the processor) the one or more processes described herein. The present disclosure contemplates methods, systems and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising 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 purpose or special purpose computer or other machine with a processor. By way of example, such machine- readable media can comprise RAM, ROM, EPROM, EEPROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including” “comprising” “having” “containing” “involving” “characterized by” “characterized in that” and variations thereof herein, is meant to encompass the items listed thereafter, equivalents thereof, and additional items, as well as alternate implementations consisting of the items listed thereafter exclusively. In one implementation, the systems and methods described herein consist of one, each combination of more than one, or all of the described elements, acts, or components.

Any references to implementations or elements or acts of the systems and methods herein referred to in the singular can also embrace implementations including a plurality of these elements, and any references in plural to any implementation or element or act herein can also embrace implementations including only a single element. References in the singular or plural form are not intended to limit the presently disclosed systems or methods, their components, acts, or elements to single or plural configurations. References to any act or element being based on any information, act or element can include implementations where the act or element is based at least in part on any information, act, or element.

Any implementation disclosed herein can be combined with any other implementation or embodiment, and references to “an implementation,” “some implementations,” “one implementation” or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the implementation can be included in at least one implementation or embodiment. Such terms as used herein are not necessarily all referring to the same implementation. Any implementation can be combined with any other implementation, inclusively or exclusively, in any manner consistent with the aspects and implementations disclosed herein.

Where technical features in the drawings, detailed description or any claim are followed by reference signs, the reference signs have been included to increase the intelligibility of the drawings, detailed description, and claims. Accordingly, neither the reference signs nor their absence have any limiting effect on the scope of any claim elements.

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.

The term “coupled” and variations thereof includes the joining of two members directly or indirectly to one another. Such joining may be stationary (e g , permanent or fixed) or moveable (e.g., removable or releasable). Such joining may be achieved with the two members coupled directly with or to each other, with the two members coupled with each other using a separate intervening member and any additional intermediate members coupled with one another, or with the two members coupled with each other using an intervening member that is integrally formed as a single unitary body with one of the two members. If “coupled” or variations thereof are modified by an additional term (e.g., directly coupled), the generic definition of “coupled” provided above is modified by the plain language meaning of the additional term (e.g., “directly coupled” means the joining of two members without any separate intervening member), resulting in a narrower definition than the generic definition of “coupled” provided above. Such coupling may be mechanical, electrical, or fluidic.

References to “or” can be construed as inclusive so that any terms described using “or” can indicate any of a single, more than one, and all of the described terms. A reference to “at least one of ‘A’ and ‘B’” can include only ‘A’, only ‘B’, as well as both ‘A’ and ‘B’. Such references used in conjunction with “comprising” or other open terminology can include additional items.

Modifications of described elements and acts such as variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, colors, orientations can occur without materially departing from the teachings and advantages of the subject matter disclosed herein. For example, elements shown as integrally formed can be constructed of multiple parts or elements, the position of elements can be reversed or otherwise varied, and the nature or number of discrete elements or positions can be altered or varied. Other substitutions, modifications, changes and omissions can also be made in the design, operating conditions and arrangement of the disclosed elements and operations without departing from the scope of the present disclosure.

References herein to the positions of elements (e.g., “top,” “bottom,” “above,” “below”) are merely used to describe the orientation of various elements in the FIGURES. The orientation of various elements may differ according to other exemplary embodiments, and that such variations are intended to be encompassed by the present disclosure.

Claims

WHAT IS CLAIMED IS:

1. An access point (AP) device comprising: one or more processors configured to: generate a frame including information on a target wake time (TWT) schedule; set a first subfield of the frame to an address of a receiver device receiving the frame over a wireless local area network (WLAN); and wirelessly transmit, via a transmitter over the WLAN, the generated frame to the receiver device.

2. The AP device according to claim 1, wherein the TWT schedule is a restricted TWT (R-TWT) schedule.

3. The AP device according to claim 1 or 2, wherein the one or more processors are configured to: determine whether a configuration value of the device is true; and in response to the configuration value of the device being true, set the first subfield of the frame to the address of the receiver device.

4. The AP device according to any one of the preceding claims, wherein the one or more processors are configured to set a second subfield of the frame to a value indicating that the frame is to convey the TWT schedule to one or more devices.

5. The AP device according to any one of claims 1 to 3, wherein: the TWT schedule includes a plurality of TWT schedules including a first TWT schedule and a second TWT schedule, and the one or more processors are configured to set a second subfield of the frame to a first value indicating that the frame is to convey the first TWT schedule to one or more devices, and set a third subfield of the frame to a second value indicating the frame relates to negotiation of membership in the second TWT schedule.

6. The AP device according to any one of the preceding claims, wherein the frame is one of a Probe Response frame, an Association Response frame, a Reassociation Response frame, a TWT Setup frame, or a TWT Information frame.

7. The AP device according to any one of claims 1 to 5, wherein: the frame is an Action frame, and the one or more processors are configured to set an action subfield of the Action frame to a value indicating TWT schedule information; and preferably wherein the one or more processors are configured to: receive, via a receiver from the receiver device, another Action frame whose action subfield is set to the value indicating the TWT schedule information; determine whether a request subfield of the another Action frame is set to a third value indicating a request for the TWT schedule information; and in response to the request subfield of the another Action frame being set to the third value, set a request subfield of the Action frame to a fourth value that is different from the third value and indicates a response to the request for the TWT schedule information.

8. The AP device according to any one of the preceding claims, wherein the one or more processors are configured to: receive another frame from the receiver device; determine whether a fourth subfield of the another frame is set to a sixth value indicating a request for TWT schedule information; and in response to the fourth subfield of the another frame being set to the sixth value, generate the frame such that the frame is a response frame to the another frame; and preferably wherein the another frame is one of a Probe Request frame, a TWT Information frame, or a TWT Setup frame.

9. A method comprising: generating, by one or more processors of an access point (AP) device, a frame including information on a target wake time (TWT) schedule; setting, by the one or more processors of the AP device, a first subfield of the frame to an address of a receiver device receiving the frame over a wireless local area network (WLAN); and wirelessly transmitting, via a transmitter over the WLAN, the generated frame to the receiver device.

10. The method according to claim 9, wherein the TWT schedule is a restricted TWT (R- TWT) schedule.

11. The method according to claim 9 or 10, further comprising: determining whether a configuration value of the device is true; and in response to the configuration value of the device being true, setting the first subfield of the frame to the address of the receiver device.

12. The method according to any one of claims 9 to 11, further comprising: setting a second subfield of the frame to a value indicating that the frame is to convey the TWT schedule to one or more devices.

13. The method according to any one of claims 9 to 11, wherein: the TWT schedule includes a plurality of TWT schedules including a first TWT schedule and a second TWT schedule, and the method further comprises: setting a second subfield of the frame to a first value indicating that the frame is to convey the first TWT schedule to one or more devices, and setting a third subfield of the frame to a second value indicating the frame relates to negotiation of membership in the second TWT schedule.

14. The method according to any one of claims 9 to 13, wherein the frame is one of a Probe Response frame, an Association Response frame, a Reassociation Response frame, a TWT Setup frame, or a TWT Information frame.

15. The method according to any one of claims 9 to 13, wherein: the frame is an Action frame, and the method further comprises setting an action subfield of the Action frame to a value indicating TWT schedule information; and preferably the method further comprises: receiving, via a receiver from the receiver device, another Action frame whose action subfield is set to the value indicating the TWT schedule information; determining whether a request subfield of the another Action frame is set to a third value indicating a request for the TWT schedule information; and in response to the request subfield of the another Action frame being set to the third value, setting a request subfield of the Action frame to a fourth value that is different from the third value and indicates a response to the request for the TWT schedule information.

16. The method according to any one of claims 9 to 15, further comprising: receiving another frame from the receiver device; determining whether a fourth subfield of the another frame is set to a sixth value indicating a request for TWT schedule information; and in response to the fourth subfield of the another frame being set to the sixth value, generating the frame such that the frame is a response frame to the another frame; and preferably wherein the another frame is one of a Probe Request frame, a TWT Information frame, or a TWT Setup frame.