TW202325067A - Systems and methods of restricted twt for wireless communication - Google Patents

Abstract

A device may include one or more processors. The one or more processors may be configured to determine a capabilities code indicating at least one of a plurality of defined capabilities of the device relating to restricted target wake time (rTWT) operations in a wireless local area network (WLAN). The one or more processors may be configured to wirelessly transmit, via a transmitter, a first frame including the capabilities code.

Description

System and method for constrained target wake-up time for wireless communications

The present disclosure relates generally to communications, including but not limited to systems and methods for securing rTWT operations for wireless communications using restricted target wake-up time (rTWT) operation/support capabilities and operational requirements. Cross-references to related applications

This application claims priority to U.S. Provisional Patent Application No. 63/270,316, filed October 21, 2021, which is hereby incorporated by reference in its entirety for all purposes. This application also claims priority to U.S. Provisional Patent Application No. 63/298,805, filed January 12, 2022, which is hereby incorporated by reference in its entirety for all purposes. This application further claims priority to U.S. non-provisional patent application Ser. No. 17/950,031, filed September 21, 2022, which is hereby incorporated by reference in its entirety for all purposes.

Artificial realities such as VR, AR or MR provide users with an immersive experience. In one example, a user wearing a head wearable display (HWD) can turn his head to one side, and an image of a virtual object corresponding to the HWD's position and/or orientation and the user's gaze direction can be displayed On the HWD to allow the user to feel as if the user is moving within an artificial reality space (eg, VR space, AR space, or MR space).

In one embodiment, images of virtual objects are generated by a remote computing device communicatively coupled to the HWD, and the images are rendered by the HWD to conserve computing resources and/or achieve bandwidth efficiency. In one example, the HWD includes various sensors that detect the position and/or orientation of the HWD and the gaze direction of a user wearing the HWD, and the sensing of the detected position and gaze direction will be indicated via a wired or wireless connection. Device measurements are transmitted to the console device (and/or to a remote server, such as in the cloud). The console device can determine the user's field of view of the artificial reality space according to the sensor measurement, and generate an image corresponding to the user's field of view of the artificial reality space. The console device can transmit the generated image to the HWD, and the HWD can present the image corresponding to the user's field of view of the artificial reality space to the user. In one aspect, the process of detecting the position of the HWD and the gaze direction of the user wearing the HWD and displaying the image to the user should be performed within a frame time (eg, less than 11 ms). The delay between the movement of the user wearing the HWD and the images displayed corresponding to the user's movement can cause judder, which can induce motion sickness and can degrade the user experience.

Various embodiments disclosed herein relate to a device including one or more processors. In some embodiments, the one or more processors can be configured to determine a plurality of defined capabilities indicative of a defined capability of the device related to restricted target wake-up time (rTWT) operation in a wireless area network (WLAN) A capability code for at least one of them. The one or more processors can be configured to wirelessly transmit via a transmitter a first frame including the capability code.

In some embodiments, the first frame may be a management frame including an information element (IE). The capability code may be included in the IE of the management frame. In some embodiments, the plurality of defined capabilities can include the ability to perform one of the rTWT operations. The rTWT operations may include at least one of setting up an rTWT schedule or establishing membership in an rTWT schedule.

In some embodiments, the plurality of defined capabilities may include a capability to complete or terminate a transmission at a start time of an rTWT service period (SP) assigned to another device. The one or more processors can be configured to obtain a transmission opportunity (TXOP) before the start time such that a duration of the TXOP ends before the start time.

Various embodiments disclosed herein relate to an access point that includes one or more processors. In some embodiments, the one or more processors can be configured to determine a restricted target wake-up time (rTWT) indicative of a device associated with the access point in a wireless local area network (WLAN). Manipulates a configuration related to one of the preferences or requirements. The one or more processors may be configured to receive a first frame from the device indicating a request for association with the access point and including a plurality of defined capabilities indicating the device A capability code for at least one of them. The one or more processors may be configured to determine whether to accept the request based on the configuration and the capability code.

In some embodiments, the one or more processors can be configured to determine whether the capability code indicates one or more capabilities related to the rTWT operations. The one or more processors may be configured to deny the request in response to the capability code not indicating one or more capabilities related to the rTWT operations.

In some embodiments, the capability code may indicate at least one of: (1) a capability not related to the rTWT operations; (2) a rTWT service period (SP) assigned to another device A first rTWT capability to complete or terminate a transmission at a start time; or (3) a second rTWT capability to perform the rTWT operations. The configuration may indicate one of the following: (1) a preference that the device supports the first rTWT capability; (2) a request that the device supports the first rTWT capability; or (3) a request that the device supports the first rTWT capability; One of the two rTWT competencies is required. In response to (1) the configuration indicating the preference for the first rTWT capability and (2) the capability code indicating neither the first rTWT capability nor the second rTWT capability, the one or more processors Can be configured to determine whether to accept the request based on one or more conditions of the access point, the one or more conditions including at least one of a traffic condition, a load condition or a path condition. In some embodiments, the one or more processors may be configured to accept the request in response to (1) the configuration indicating the first capability and (2) the capability code indicating the first capability. request, and transmit a response frame in response to the first frame to the device.

Embodiments disclosed herein relate to a method that includes determining, by one or more processors of an access point, an indication for use with a device and the access point in a wireless local area network (WLAN) The associated restricted target wake-up time (rTWT) operates on a configuration of a preference or a requirement. The method may include receiving a first frame from the device indicating a request for association with the access point including a capability indicating at least one of a plurality of defined capabilities of the device code. The method may include determining whether to accept the request based on the configuration and the capability code.

In some embodiments, the one or more processors of the access point can determine whether the capability code indicates one or more capabilities related to the rTWT operations. In response to the capability code not indicating one or more capabilities related to the rTWT operations, the one or more processors may decide to deny the request.

In some embodiments, the capability code indicates at least one of: (1) a capability not related to the rTWT operations; (2) a rTWT service period (SP) assigned to another device A first rTWT capability to complete or terminate a transmission at a start time; or (3) a second rTWT capability to perform the rTWT operations. The configuration may indicate one of the following: (1) a preference that the device supports the first rTWT capability; (2) a request that the device supports the first rTWT capability; or (3) a request that the device supports the first rTWT capability; One of the two rTWT competencies is required.

In some embodiments, in response to (1) the configuration indicates the preference for the first rTWT capability and (2) the capability code indicates neither the first rTWT capability nor the second rTWT capability, the One or more processors may determine whether to accept the request based on one or more conditions of the access point, the one or more conditions including at least one of a traffic condition, a load condition, or a channel condition.

In some embodiments, in response to (1) the configuration indicating the request for the first capability and (2) the capability code indicating the first capability, the one or more processors may decide to accept the request and will A response frame is transmitted to the device in response to the first frame.

In some embodiments, in response to (1) the configuration indicating the request for the second capability and (2) the capability code indicating the second capability, the one or more processors may decide to accept the request and will A response frame is transmitted to the device in response to the first frame.

In some embodiments, the one or more processors can determine whether the device is associated with the access point. In response to determining that the device is associated with the access point, the one or more processors may determine whether the device is to be disassociated from the access point based on the configuration and the capability code.

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

The systems and methods disclosed herein relate to securing rTWT operation for wireless communications using restricted target wake-up time (rTWT) operation/support capabilities and operation requirements. In some embodiments, a device (eg, computing device, HWD, non-AP station (STA), STA of a STA multilink device (MLD)) may include one or more processors. The one or more processors may determine a plurality of defined capabilities of the pointing device related to rTWT operation in a wireless local area network (WLAN) (e.g., rTWT operation support and/or protection rTWT service period (SP) start time The ability code of at least one of the capabilities). The one or more processors may wirelessly transmit via the transmitter a first frame including a capability code (eg, including a capability code in an extremely high throughput (EHT) capability field).

In some embodiments, an access point (eg, AP, soft AP, AP of an AP MLD) may include one or more processors. The one or more processors may determine to indicate a preference or requirement (e.g., a preference or requirement (e.g., configuration of rTWT operational support and/or the ability to protect rTWT SP's start time preferences or requirements). The one or more processors may receive a first frame from the device indicating a request for association with an access point and including a plurality of defined capabilities indicating the device (e.g., included in an EHT capabilities field) The ability code of at least one of the ability codes. The one or more processors can determine whether to accept the request according to the configuration and the capability code.

A traffic stream can be characterized by different types of traffic. For example, applications can be characterized as latency-sensitive traffic (e.g., video/voice (VI/VO), real-time interactive applications, and the like) or general traffic (e.g., best workload/background applications (BE /BK)). In some embodiments, delay-sensitive traffic is identifiable based in part on its bursty nature (eg, a periodic burst of traffic). For example, video display traffic can be driven by refresh rates of 60 Hz, 72 Hz, 90 Hz, or 120 Hz. An application and/or device may have a combination of traffic types (eg, delay sensitive traffic and non-delay sensitive traffic). Furthermore, each traffic stream for an application and/or device may be more or less spontaneous and/or aperiodic compared to other traffic streams for the application and/or device. Thus, traffic can vary dynamically depending on the application and/or lane rate.

TWT may be a time agreed/negotiated by devices (eg, access point (AP) and/or station (STA)) or specified/configured by one device (eg, AP). During the wake-up time, the first device (eg, STA) may be in an awake state (eg, its wireless communication module/interface is in a fully powered-on ready or awake state) and be able to transmit and/or receive. When the first device is not awake (for example, its wireless communication module/interface is in a power-off, low-power or sleep state), the first device can enter a low-power mode or other sleep modes. The first device may exist in the sleep state until a time instance/window as specified by the TWT.

TWT is a mechanism in which a set of service periods (SPs) are defined and shared among devices to reduce media contention and improve power efficiency of the devices. For example, the first device may wake up periodically (eg, at a fixed configured interval/period/cycle) based on the TWT. TWT reduces a device's energy consumption by limiting the device's wake-up time and associated power consumption.

APs (eg, APs and/or other devices used as soft APs/hotspots) can enhance media access protection and resource reservation by supporting restricted TWT (rTWT). The rTWT SP may be used to deliver delay sensitive traffic and/or any additional frames supporting delay sensitive traffic. Exemplary implementations and operations of rTWT are provided in U.S. Patent Application Serial No. 17/490,985, entitled "SYSTEMS AND METHOD OF TARGET WAKE TIME FOR PEER-TO-PEER COMMUNICATION," filed September 30, 2021, the U.S. The patent application is hereby incorporated by reference in its entirety.

Figure 1 is a block diagram of an exemplary artificial reality system environment. Figure 1 provides an exemplary environment in which devices may transmit traffic streams with different delay sensitivities/requirements. In some embodiments, the augmented reality system environment 100 includes an access point (AP) 105, one or more head wearable displays (HWD) 150 (e.g., HWD 150A, 150B) worn by the user, and 150 One or more computing devices 110 (computing devices 110A, 110B) that provide content for the artificial reality.

Access point 105 may be a router or any network device that allows one or more computing devices 110 and/or one or more HWD 150 to access a network (eg, the Internet). Access point 105 can be replaced by any communication device (cell base). A HWD may be referred to as, include, or refer to a head-mounted display (HMD), a head-mounted device (HMD), a head-wearable device (HWD), a head-worn display (HWD), or a head-worn device (HWD). part of. In one aspect, HWD 150 may include various sensors to detect the position, orientation, and/or gaze direction of a user wearing HWD 150, and the detected position, orientation, and/or gaze direction may be transmitted via a wired or wireless connection. The directions are provided to computing device 110 . HWD 150 can also identify objects (eg, body, hands).

In some embodiments, computing devices 110A, 110B communicate with access point 105 via communication links 102A, 102B (eg, interconnect), respectively. In some embodiments, computing device 110A can communicate with HWD 150A via communication link 125A (eg, inline), and computing device 110B can communicate with HWD 150B via wireless link 125B (eg, inline).

The computing device 110 can be a computing device or a mobile device that can retrieve content from the access point 105 , and can provide image data of the artificial reality to the corresponding HWD 150 . Each HWD 150 can present the artificial reality image to the user according to the image data.

Computing device 110 may determine a field of view within the space of the artificial reality that corresponds to the detected position, orientation, and/or gaze direction, and generate an image depicting the determined field of view detected by HWD 150 . Computing device 110 may also receive one or more user inputs and modify the image based on the user inputs. Computing device 110 may provide the imagery to HWD 150 for presentation. An image of the artificial reality space corresponding to the user's field of view may be presented to the user.

In some embodiments, the augmented reality system environment 100 includes more, fewer, or different components than those shown in FIG. 1 . In some embodiments, the functionality of one or more components of the augmented reality system environment 100 may be distributed among the components in a manner different from that described herein. For example, some functionality of computing device 110 may be performed by HWD 150 , and/or some functionality of HWD 150 may be performed by computing device 110 . In some embodiments, computing device 110 is integrated as part of HWD 150 .

In some embodiments, HWD 150 is an electronic component that can be worn by a user and that can present or provide an artificial reality experience to the user. The HWD 150 can display one or more images, videos, audios or a combination thereof to provide an artificial reality experience to the user. In some embodiments, the audio is presented via an external device (e.g., speakers and/or headphones) that receives audio information from the HWD 150, the computing device 110, or both, and presents the audio based on that audio information. . In some embodiments, HWD 150 includes: sensors 155 (eg, sensors 155A, 155B), including, for example, eye trackers and hand trackers; communication interfaces 165 (eg, communication interfaces 165A, 165B); an electronic display 175; and a processor 170 (eg, processors 170A, 170B). These components are operable to detect the location of the HWD 150 and/or the gaze direction of a user wearing the HWD 150 and appear within the artificial reality corresponding to the detected location of the HWD 150 and/or the gaze direction of the user image of the field of view. In other embodiments, HWD 150 includes more, fewer, or different components than shown in FIG. 1 .

In some embodiments, sensor 155 includes electronic components or a combination of electronic and software components that detect the position and/or orientation of HWD 150 . Examples of sensors 155 may include: one or more imaging sensors, one or more accelerometers, one or more gyroscopes, one or more magnetometers, hand trackers, eye trackers, or detectors Another suitable type of sensor of motion and/or position. For example, one or more accelerometers can measure translational movement (e.g., forward/backward, up/down, left/right) and one or more gyroscopes can measure rotational movement (e.g., pitch, yaw, roll). In some embodiments, sensor 155 detects translational and/or rotational movement and determines the orientation and position of HWD 150 . In one aspect, sensor 155 may detect translational and/or rotational movement relative to a previous orientation and position of HWD 150, and determine the HWD by accumulating or integrating the detected translational and/or rotational movements. 150's new orientation and/or location. For example, assuming that HWD 150 is oriented at 25 degrees from a reference direction, in response to detecting that HWD 150 has rotated 20 degrees, sensor 155 may determine that HWD 150 is now facing 45 degrees from the reference direction or at Orient in a direction 45 degrees from the reference direction. As another example, assuming that HWD 150 is positioned two feet away from a reference point in a first direction, in response to detecting that HWD 150 has moved three feet in a second direction, sensor 155 may determine that HWD 150 is now positioned at a second position. The vector product of two feet in one direction and three feet in the second direction.

In some embodiments, the sensors 155 may also include eye trackers having electronic components or a combination of electronic and software components to determine the gaze direction of the user of the HWD 150 . In other embodiments, the eye tracker may be a separate component from sensor 155 . In some embodiments, HWD 150, computing device 110, or a combination may incorporate the gaze direction of the user of HWD 150 to generate image data for artificial reality. In some embodiments, the eye tracker (eg, as part of sensor 155 ) includes two eye trackers, where each eye tracker captures an image of a corresponding eye and determines the gaze direction of the eye. In one example, the eye tracker determines angular rotation of the eye, translation of the eye, change in eye twist, and/or change in shape of the eye based on captured images of the eye, and based on the determined angular rotation, translation, and change in eye twist Instead, a relative gaze direction with respect to HWD 150 is determined. In one approach, an eye tracker may illuminate or project a predetermined reference or structured pattern onto a portion of the eye and capture an image of the eye to analyze the projected pattern on the portion of the eye to determine the position of the eye relative to the HWD 150 . Relative gaze direction. In some embodiments, the eye tracker incorporates the orientation of the HWD 150 and the relative gaze direction relative to the HWD 150 to determine the gaze direction of the user. For example, assuming the HWD 150 is oriented in a direction 30 degrees from a reference direction, and the relative gaze direction of the HWD 150 is -10 degrees (or 350 degrees) relative to the HWD 150, the eye tracker can determine the user's gaze The direction is set 20 degrees from the reference direction. In some embodiments, a user of HWD 150 may configure HWD 150 (eg, via user settings) to enable or disable eye trackers as part of sensor 155 . In some embodiments, a user of the HWD 150 causes the eye tracker to be enabled or disabled as part of the sensor 155 configuration.

In some embodiments, the sensor 155 includes a hand tracker that includes electronic components or a combination of electronic components and software components that track the user's hand. In other embodiments, the hand tracker can be a separate component from the sensor 155 . In some embodiments, the hand tracker includes or is coupled to an imaging sensor (eg, a camera) and an image processor that can detect the shape, position and/or orientation of a hand. The hand tracker can generate hand tracking measurements indicative of the detected shape, position and/or orientation of the hand.

In some embodiments, communication interface 165 (eg, communication interface 165A, 165B) corresponding to HWD 150 (eg, HWD 150A, 150B) and/or communication interface 115 (eg, computing device 110A, 110B) corresponding to computing device ( For example, the communication interfaces 115A, 115B) include electronic components or a combination of electronic components and software components for communication.

Communication interface 165 may communicate with communication interface 115 of computing device 110 via inline communication link 125 (eg, communication link 125A, 125B). Communication interface 165 may transmit sensor measurements to computing device 110 that indicate a determined location of HWD 150 , an orientation of HWD 150 , a user's determined gaze direction, and/or hand tracking measurements. . For example, computing device 110 may receive sensor measurements and/or hand-tracking measurements indicating the location and gaze direction of a user of HWD 150 , and transfer the images, such as via wireless link 125 (eg, inline). The data is provided to HWD 150 for rendering artificial reality. For example, communication interface 115 may transmit to HWD 150 data describing an image to be displayed. Communication interface 165 may receive from computing device 110 indications of sensor measurements corresponding to an image to be visualized. In some embodiments, HWD 150 may communicate with access point 105 .

Similarly, communication interface 115 (eg, communication interface 115A, 115B) of computing device 110 may communicate with access point 105 via communication link 102 (eg, communication link 102A, 102B). In some embodiments, computing device 110 may be considered a soft access point (eg, a hotspot device). The communication interface 115 can transmit and receive AR/VR content from the access point 105 via the communication link 102 (eg, interconnection). The communication interface 115 of the computing device 110 can also communicate with the communication interface 115 of a different computing device 110 via the communication link 185 . As described herein, communication interface 115 may be a counterpart component of communication interface 165 to communicate with communication interface 115 of computing device 110 via a communication link (eg, USB cable, wireless link).

Communication interfaces 115 and 165 may receive and/or transmit instructions indicating communications between devices (e.g., between computing devices 110A and 110B across communication link 185, between HWD 150A and computing device 110A across communication link 125) Link information (eg, channel, timing). Based on the information indicating the communication link, devices can coordinate or schedule operations to avoid interference or conflicts.

The communication link can be a wireless link, a wired link, or both. In some embodiments, communication interface 165/115 includes or is implemented as a transceiver for transmitting and receiving data over a wireless link. Examples of wireless links may include cellular communication links, near field communication links, Wi-Fi, Bluetooth, or any communication wireless communication link. Examples of wired links may include USB, Ethernet, Firewire, HDMI, or any wired communication link. In embodiments where computing device 110 and head wearable display 150 are implemented on a single system, communication interface 165 may communicate with computing device 110 via bus bar connections or conductive traces.

Using the communication interface, computing device 110 (or HWD 150 or AP 105 ) can coordinate operations on links 102, 185, or 125 by scheduling communications to reduce collisions or interference. For example, computing device 110 may coordinate communications between computing device 110 and HWD 150 using communication link 125 . Data (eg, traffic streams) may flow in directions on link 125 . For example, computing device 110 may communicate with HWD 150 using downlink (DL) communications, and HWD 150 may communicate with computing device 110 using uplink (UL) communications. In some implementations, computing device 110 may periodically transmit a beacon frame to announce/advertise the existence of a wireless link between computing device 110 and HWD 150 (or between HWD 150A and 150B). In one implementation, HWD 150 may monitor or receive beacon frames from computing device 110 and may schedule communications with HWD 150 (eg, using information in the beacon frames, such as offset values) to avoid Conflict or interference with communications between computing device 110 and/or HWD 150 and other devices.

In some embodiments, the processor 170 may include, for example, an image display device including electronic components or electronic components and software components for generating one or more images for display based on changes in the spatial field of view of artificial reality, for example. combination. In some embodiments, the image display is implemented as a processor 170 (or a graphics processing unit (GPU), one or more central processing units (CPUs), or a combination thereof) that is implemented to perform the instructions for various functions. In other embodiments, the image display may be a separate component from the processor 170 . The image visualizer may receive data describing an image to be visualized via communication interface 165 and present the image via electronic display 175 . In some embodiments, the data from computing device 110 may be encoded, and the video displayer may decode the data to generate and present an image. In one aspect, the image displayer receives encoded images from computing device 110 and decodes the encoded images such that communication bandwidth between computing device 110 and HWD 150 may be reduced.

In some embodiments, the image display receives additional data from the computing device 110, the additional data includes object information indicating the virtual object in the artificial reality space and depth information indicating the depth (or distance from the HWD 150) of the virtual object . Accordingly, the image display may receive object information and/or depth information from the computing device 110 . The image display may also receive updated sensor measurements from sensor 155 . The following procedures may be computationally exhaustive and may not be performed within frame times (e.g., less than 11 ms or 8 ms): Detecting the position and orientation of HWD 150 by HWD 150 and/or the gaze of a user wearing HWD 150 direction, and a high-resolution image (eg, 1920 by 1080 pixels or 2048 by 1152 pixels) corresponding to the detected position and gaze direction is generated and transmitted to the HWD 150 by the computing device 110 .

In some implementations, the image renderer may perform shading, reprojection, and/or blending to update the imagery of the artificial reality to correspond to the updated position and/or orientation of the HWD 150 . Assuming the user rotates their head after the initial sensor measurement, the image display can generate a small portion (eg, 10%) of the image corresponding to the updated field of view within the artificial reality based on the updated sensor measurement , and append this portion to the image in the image data from computing device 110 via reprojection, rather than recreating the entire image in response to updated sensor measurements. The image visualizer may perform shading and/or blending on the added edges. Thus, the image display can generate an artificial reality image without recreating the artificial reality image from the updated sensor measurements.

In other implementations, when an image from computing device 110 is not received within the frame time, the image displayer generates one or more images through a rendering process and a re-projection process. For example, shading procedures and reprojection procedures may be performed adaptively according to changes in the view of the artificial reality space.

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

In some embodiments, HWD 150 may include a lens to allow a user to view display 175 in close proximity. A lens may be a mechanical component that alters light received from electronic display 175 . The lens can magnify the light from the electronic display 175 and correct optical errors associated with the light. The lenses may be Fresnel lenses, convex lenses, concave lenses, filters, or any suitable optical component that alters the light from the electronic display 175 . Through the lens, the light from the electronic display 175 can reach the pupil so that the user can see the image displayed by the electronic display 175 even though the electronic display 175 is very close to the eyes.

In some embodiments, processor 170 performs compensation to compensate for any distortion or distortion. In some embodiments, the compensator may be a separate device from the processor 170 . Compensators include electronic components or a combination of electronic and software components that perform the compensation. In one aspect, the lens introduces optical aberrations, such as chromatic aberration, pincushion distortion, barrel distortion, and the like. The compensator may determine compensations (eg, pre-distortion) to be applied to the image to be presented from the image display to compensate for the distortion caused by the lens, and apply the determined compensation to the image from the image display. The compensator may provide the pre-distorted image to the electronic display 175 .

In some embodiments, computing device 110 is an electronic component or a combination of electronic and software components that provides content to be rendered to HWD 150 . Computing device 110 may be implemented as a mobile device (eg, smartphone, tablet PC, laptop, etc.). Computing device 110 may serve as a soft access point. In one aspect, computing device 110 includes communication interface 115, processor 118, and content providers 130 (eg, content providers 130A, 130B). These components may operate in conjunction to determine a field of view (e.g., the user's field of view (FOV)) corresponding to the location of HWD 150 and/or the gaze direction of a user of HWD 150, and may generate a field of view corresponding to the determined The image of the artificial reality of the field of view.

Processors 118, 170 include or are implemented as one or more central processing units, graphics processing units, image processors, or any processor for generating images of artificial reality. In some embodiments, the processor 118, 170 may configure or cause the communication interface 115, 165 to toggle, transition, cycle, or switch between sleep mode and wake mode. In the wake-up mode, the processor 118 can enable the communication interface 115 and the processor 170 can enable the communication interface 165 so that the communication interfaces 115, 165 can exchange data. In sleep mode, the processor 118 may disable the wireless interface 115, and the processor 170 may disable the communication interface 165 (eg, may implement low power or reduced operation in the communication interface), so that the communication interfaces 115, 165 No power may be consumed, or power consumption may be reduced.

The processor 118, 170 may schedule the communication interface 115, 165 to periodically switch between the sleep mode and the wake-up mode at each frame time (eg, 11 ms or 16 ms). For example, the communication interface 115, 165 may operate in wake mode for a frame time of 2 ms, and the communication interface 115, 165 may operate in sleep mode for the remainder (eg, 9 ms) of the frame time. By disabling the wireless interfaces 115, 165 in sleep mode, the power consumption of the computing device 110 and the HWD 150 can be reduced or minimized.

In some embodiments, processors 118 , 170 may configure or cause communication interfaces 115 , 165 to resume communication based on stored information indicative of communication between computing device 110 and HWD 150 . In awake mode, processors 118 , 170 may generate and store information (eg, channel, timing) for communications between computing device 110 and HWD 150 . The processor 118, 170 may schedule the communication interface 115, 165 to enter a subsequent wake-up mode according to the timing of previous communications indicated by the stored information. For example, the communication interface 115, 165 can predict/determine when to enter the subsequent wake-up mode according to the timing of the previous wake-up mode, and can schedule to enter the subsequent wake-up mode at the predicted time. After generating and storing the information and scheduling a subsequent wake-up mode, the processor 118, 170 may configure or cause the wireless interface 115, 165 to enter a sleep mode. When entering the wake-up mode, the processor 118, 170 may cause or configure the communication interface 115, 165 to resume communication via the previously communicated channel or frequency band indicated by the stored information. Accordingly, the communication interface 115 can resume communication when entering wake mode from sleep mode at 165 while skipping the scanning process for available channels and/or performing handshaking or authentication. Bypassing the scan procedure allows for an extension of the duration of the communication interface 115, 165 operating in sleep mode so that the computing device 110 and HWD 150 can reduce power consumption.

In some embodiments, computing devices 110A, 110B may operate in coordination to reduce conflict or interference. In one approach, computing device 110A may periodically transmit a beacon frame to announce/advertise the existence of wireless link 125A between computing device 110A and HWD 150A, and may coordinate communications between computing device 110A and HWD 150A . Computing device 110B may monitor or receive beacon frames from computing device 110A, and may schedule communications with HWD 150B (e.g., using information in the beacon frames, such as offset values) to avoid conflicts between computing device 110A and HWD 150B. Communications between HWDs 150A collide or interfere. For example, computing device 110B may schedule computing device 110B and HWD 150B to enter wake mode while computing device 110A and HWD 150A are operating in sleep mode. For example, computing device 110B may schedule computing device 110B and HWD 150B to enter sleep mode while computing device 110A and HWD 150A are operating in wake mode. Accordingly, multiple computing devices 110 and HWD 150 that are in close proximity (eg, within 20 ft) can coexist and operate with reduced interference.

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

Content provider 130 may generate image data describing images of the determined field of view of the artificial reality space and transmit the image data to HWD 150 via communication interface 115 . The content provider may also generate a hand model (or other virtual object) corresponding to the user's hand based on the hand tracking measurements, and generate data indicating the shape, position, and orientation of the hand model in artificial reality space. Hand model information. Content provider 130 may encode image data describing the image and may transmit the encoded data to HWD 150 . In some specific examples, the content provider generates and provides image data to the HWD 150 periodically (eg, every 11 ms or 16 ms).

In some specific examples, the content provider 130 generates metadata including motion vector information, depth information, edge information, object information, etc. associated with the image, and transmits the metadata together with the image data to the HWD 150. Content provider 130 may encode and/or encode data describing the imagery, and may transmit the encoded and/or encoded data to HWD 150 . In some specific examples, the content provider 130 periodically (eg, every second) generates and provides image data to the HWD 150 .

In some embodiments, scheduler 118 (eg, scheduler 118A of computing device 118A and/or scheduler 118B of computing device 110B) may request rTWT to use P2P communication to transmit delay-sensitive traffic. Scheduler 118 of AP 105 and computing device 110 may negotiate (eg, perform a handshake procedure) and may establish membership for a limited TWT schedule. In some embodiments, when AP 105 and scheduler 118 are negotiating, AP 105 may be considered a restricted TWT scheduling AP, and computing device 110 may be considered a restricted TWT scheduling STA.

In some embodiments, HWD 150 may request that P2P traffic be sent to computing device 110 . Accordingly, HWD 150 may be considered a TWT requesting STA (eg, a TWT STA requesting the TWT protocol), and computing device 110 may be considered a TWT responding STA (eg, a TWT STA responding to a TWT request). Communication link 125 between computing device 110 and HWD 150 may be a P2P link (eg, a link for transmission between two non-AP devices). Communication link 102 between computing device 110 and AP 105 may be any channel or other type of link. In some configurations, the HWD 150 may move/become out of range of the access point 105 . In other embodiments, computing device 110 may request to send P2P traffic to HWD 150 such that computing device 110 is considered a TWT requesting STA and HWD 150 is a TWT responding STA.

The scheduler 118 of the computing device 110 can schedule the communication between the computing device 110 and the HWD 150 through the AP 105 so that the communication between the computing device 110 and the HWD 150 is protected. Computing device 110 may initiate this protected P2P communication with HWD 150 by indicating to AP 105 that computing device 110 wishes to schedule P2P communication in the rTWT service period (SP). The scheduler 118 of the computing device may schedule (or negotiate) the requested rTWT SP. The scheduler 118 of the computing device may also indicate whether to request SP only for P2P communication (compared to hybrid P2P communication and non-P2P communication).

FIG. 2 is a diagram of a HWD 150 according to an exemplary embodiment. In some embodiments, HWD 150 includes front rigid body 205 and belt 210 . The front rigid body 205 includes an electronic display 175 (not shown in FIG. 2 ), a lens (not shown in FIG. 2 ), a sensor 155 , an eye tracker, a communication interface 165 and a processor 170 . In the embodiment shown by FIG. 2, the sensor 155 is located within the front rigid body 205 and may not be visible to the user. In other embodiments, HWD 150 has a different configuration than that shown in FIG. 2 . For example, processor 170, eye tracker, and/or sensor 155 may be in a different location than that shown in FIG. 2 .

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

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

Network interface 320 may include transceivers that allow computing system 314 to transmit and receive data from remote devices (eg, APs, STAs) using transmitters and receivers. The transceiver can be configured to support industry standards for transmit/receive for two-way communication. An antenna can be attached to the transceiver housing and electrically coupled to the transceiver. Additionally or alternatively, a multiple antenna array can be electrically coupled to the transceiver such that a plurality of beams pointing in different directions can facilitate transmission and/or reception of data.

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

User input device 322 may include any device (or devices) through which a user may provide a signal to computing system 314; computing system 314 may interpret the signal as indicating a particular user request or information. User input devices 322 may include keyboards, touchpads, touch screens, mice or other pointing devices, scroll wheels, click wheels, dials, buttons, switches, keypads, microphones, sensors (e.g., motion sense sensors, eye-tracking sensors, etc.), etc.) or any or all of them.

User output device 324 may include any device through which computing system 314 may provide information to a user. For example, user output device 324 may include a display for displaying images generated by or delivered to computing system 314 . The display may incorporate various image generating technologies such as liquid crystal displays (LCDs), light emitting diodes (LEDs) including organic light emitting diodes (OLEDs), projection systems, cathode ray tubes (CRTs) or the like, and Support electronics (for example, digital-to-analog or analog-to-digital converters, signal processors, or the like). Devices that function as both input and output devices, such as touch screens, may be used. In addition to or instead of a display, an output device 324 may also be provided. Examples include indicator lights, speakers, tactile "display" devices, printers, and more.

Some implementations include electronic components, such as microprocessors, storage devices, and memories that store computer program instructions in computer-readable storage media (eg, non-transitory computer-readable media). Many of the features described in this specification can be implemented as a program specified as a set of program instructions encoded on a computer readable storage medium. These program instructions, when executed by one or more processors, cause the processors to perform the various operations indicated in the program instructions. Examples of program instructions or computer code include machine code such as produced by a compiler, and files including higher-level code executed by a computer, electronic component, or microprocessor using an interpreter. Properly programmed, processor 316 may provide various functionality to computing system 314, including any of the functionality described herein as being performed by a server or client, or other functionality associated with a message management service. By.

It should be appreciated that computing system 314 is exemplary and that variations and modifications are possible. Computer systems used in conjunction with the present disclosure may have other capabilities not specifically described herein. Furthermore, although computing system 314 is described with reference to particular blocks, it should be understood that such blocks are defined for convenience of description and are not intended to imply a particular physical configuration of component parts. For example, different blocks may be located in the same facility, in the same server rack, or on the same motherboard. Additionally, the blocks do not necessarily correspond to physically distinct components. Blocks can be configured to perform various operations, such as by programming a processor or providing appropriate control circuitry, and individual blocks may or may not be reconfigured depending on how the initial configuration was obtained. Implementations of the present disclosure may be implemented in a variety of apparatuses including electronics implemented using any combination of circuitry and software.

Figures 1-2 illustrate devices transmitting traffic streams, some of which may be delay sensitive (eg, those traffic streams carrying AR/VR information/content). As described herein, the periodic operation of the TWT benefits communication of periodic traffic (eg, delay sensitive traffic) by predictably transmitting the periodic traffic. FIG. 4 is a timing diagram 400 showing wake/sleep scheduling for a computing device utilizing TWT, according to an example implementation of the present disclosure. The TWT start time is indicated by the computing device 110 (eg, a portion of its associated modules/circuitry) waking up at 402 . Computing device 110 may wake up for a duration 404 defined by the SP. After the SP duration 404 , the computing device 110 may enter a sleep state until the next TWT start time at 408 . The time interval between TWT start time 402 and TWT start time 408 may be considered SP interval 406 .

TWT scheduling can be communicated and/or negotiated using broadcast TWT (bTWT) and/or individual TWT (iTWT) signaling. In some embodiments, for signaling iTWT, modes such as Network Allocation Vector (NAV) can be used to transmit TWT scheduling information to specific (individual) devices to protect media access of TWT SP. In contrast, to signal bTWT, in some embodiments a device (such as AP 105) may schedule TWT SPs with other devices (e.g., computing device 110 and/or HWD 150), and may Frames and/or Probe Response Frames share schedule information. Using bTWT to share scheduling information reduces overhead (eg, negotiation overhead) compared to the overhead used when using iTWT to share information.

The TWT mechanism can also be used in peer-to-peer (P2P) communication. For example, TWTs may be defined for Tunneled Direct Link Setup (TDLS) pairs (eg, non-AP STAs), soft APs (such as computing device 110 ) and STAs (such as HWD 150 ), and/or peer groups Group owner (GO) and group client (GC). For example, a TDLS pair device (eg, HWD 150 and computing device 110 ) may request TWT membership for its delay-sensitive traffic over the channel. In another example, a group owner (GO), such as computing device 110, may request TWT membership for delay sensitive traffic over a P2P link.

When P2P communication is established, various channel access rules can control the P2P communication. AP-assisted P2P trigger frame sequences can reduce contention/collisions associated with TWT (or rTWT) in P2P communication. Therefore, a P2P model in which a P2P STA (eg, HWD 150 ) is not associated with a Basic Service Set (BSS) AP can improve P2P communication. A transmission over a P2P link may collide with another transmission in the BSS without assistance or coordination from the AP. In some specific examples, Reverse Protocol (RDP) can be enabled for P2P communication. During RDP, when the transmitting STA has obtained a transmission opportunity (TXOP), the transmitting STA may grant the receiving STA permission to transmit information back to the transmitting STA during the same TXOP. Therefore, if the TWT settings allow P2P transmission and indicate RDP, then P2P communication can be performed after triggering a frame sequence (eg, reverse frame exchange). In other embodiments, other protocols may be enabled for P2P communication. In some embodiments, enabling triggered TWT can reduce media contention and/or collisions between UL and DL transmissions. Trigger-enabled TWTs may be indicated using a TWT Information Element (IE).

FIG. 5 illustrates an interaction/flow diagram showing a procedure 500 for configuring/enabling/extending rTWT for P2P communication according to an exemplary implementation of the present disclosure. In some embodiments, the procedure 500 is performed by a first device 501 (e.g., a restricted TWT scheduling AP, such as AP 105), a second device 520 (e.g., a TWT requesting STA/scheduling STA, such as a computing device 110 or a software AP) and/or a third device 530 (eg, a peer device to communicate with a TWT-scheduling STA or a TWT-responding STA, such as another computing device 110 and/or HWD 150 , via a P2P link). The third device 530 may not be associated with the first device 501 and/or may not be within the range of the first device 501 . Extending rTWT for P2P communication can be performed using bTWT signaling and/or iTWT signaling. In some embodiments, process 500 is performed by other entities. In some embodiments, procedure 500 includes more, fewer or different steps than shown in FIG. 5 .

In some embodiments, the process 500 begins with operation 502 at the first device 501 . In other embodiments, the process 500 begins at operation 521 at the second device 520 .

In more detail of operation 502, the first device 501 may configure a subfield extending rTWT for (eg, to support) P2P communication. For example, the first device 501 may advertise and/or announce the capability of P2P support/in/in one or more rTWT SPs (eg, using beacon frames).

The subfields configured in operation 502 may be configured by using/adding (modifying, inserting) rTWT parameter subfields (eg, optional rTWT subfields) in the TWT parameter set field format. For example, an indication of a TWT parameter set field with optionally added rTWT parameter subfields (e.g., an indication of the presence or use of rTWT parameter subfields) may use one or more of the TWT element fields One bit to indicate. FIG. 6 is an example format 600 of a TWT element field according to an example implementation of the present disclosure. The TWT element 601 may include a control subfield 602 . Control subfield 602 may include reserved bits 604 . One or more bits of reserved bits 604 may be reset (modified/configured) to indicate the presence of an optional rTWT subfield appended to the TWT parameter set field. In other embodiments, other bits (e.g., reserved bits from within or outside the control subfield 602) may be allocated to indicate that an optional rTWT subfield is appended to the TWT parameter set field (or added to the TWT parameter collection field). In one example, bit 6 (B6) (reserved bit), for example, may indicate whether to append the rTWT parameter subfield (e.g., the optional rTWT subfield) to the TWT parameter set field or to the TWT parameter set field), as indicated in Figure 7, is being transmitted. If bit 6 is set (or other reset bits are set), the TWT parameter set field (as seen in FIG. 7 ) may include a rTWT parameter subfield indicating rTWT P2P information.

FIG. 7 is an exemplary format of a modified TWT parameter set field according to an exemplary implementation of the present disclosure. The TWT parameter set field 702 is the TWT parameter set field for iTWT sending, and the TWT parameter set field 704 is the TWT parameter set field for bTWT sending. Both the bTWT parameter set field and the iTWT parameter set field may be transmitted in either direction (e.g., from AP 105 to computing device 110 and/or from computing device 110 to AP 105), and in some cases, between STA between (for example, in P2P communication or configuration). As shown, one or more bits of the TWT parameter set fields 702, 704 can be added (or reset, modified, inserted) to include optional rTWT parameter subfields. It should be appreciated that the optional rTWT parameter subfield may be inserted anywhere within the TWT parameter set fields 702, 704. In some embodiments, the rTWT parameter subfield can be 1 or more octets (eg, the rTWT parameter subfield can be added to the TWT parameter set fields 702, 704). The rTWT parameter subfield may indicate/include P2P information if the associated bit in the control subfield 602 of the TWT element 601 in FIG. 6 is set. If the associated bit in the control subfield 602 of the TWT element 601 in FIG. 6 is not set, the rTWT parameter subfield may not indicate/include P2P information (e.g., the rTWT parameter subfield may not exist in the TWT parameter set in fields 702, 704).

FIG. 8 is an exemplary format of an rTWT parameter subfield 800 according to an exemplary implementation of the present disclosure. In some embodiments, the rTWT parameter subfield 800 can be, for example, at least 3 bits (eg, 8 bits). In other embodiments, the rTWT parameter subfield 800 may have fewer or more bits. It should be appreciated that the position/configuration of bits in the rTWT parameter sub-field 800 may vary. In some embodiments, the bits in the rTWT parameter subfield 800 may be interpreted differently based on the device transmitting the rTWT parameter subfield 800 .

When the AP transmits the rTWT parameter subfield 800 in a frame, bit 0 (or any other predefined bit) 802 may indicate whether P2P is allowed or supported. For example, the first device 501 in FIG. 5 can allow/support the SP to be used for P2P communication, and the first device can be rTWT scheduling AP, such as AP 105 . For example, if bit 0 802 is set, the AP may announce that P2P communication is allowed/supported during one or more rTWT SPs. If bit 0 802 is not set, the AP may announce that one or more rTWT SPs do not support P2P communication.

The AP may also use bit 1 (or any other predefined bit) 804 to advertise the type of traffic supported during one or more rTWT SPs. For example, if bit 1 804 is set, the AP may indicate that only P2P communications may be transmitted during one or more rTWT SPs. If bit 1 804 is not set, the AP may indicate that non-P2P communications may be sent during the rTWT SP, or that a mix of P2P and non-P2P communications may be sent during the rTWT SP (e.g., some P2P traffic or traffic streams and some non-P2P traffic or traffic streams).

In some embodiments, bit 2 (or any other predefined bit) 806 may be used to indicate a protocol governing channel access rules/procedures/methods for P2P communication during rTWT SP. For example, if bit 2 806 is set, the AP can inform non-AP STAs (e.g., computing device 110 or other rTWT scheduling STAs) that RDP can be managed/used as a channel for P2P communication during rTWT SP access method. If bit 2 806 is not set, the AP may be informing the non-AP STA that RDP may not be used as a channel access method for P2P communication. The rTWT parameter subfield 800 may also contain reserved bits (eg, bits 3-7).

In other embodiments, the rTWT can be extended for P2P communication by resetting/modifying one or more bits in the format of the bTWT information subfield. FIG. 9 is an exemplary format of a bTWT information subfield according to an exemplary implementation of the present disclosure. As shown, the reserved bits 902 of the bTWT information subfield can be reset/modified so that the rTWT parameter subfield 920 can be used to extend rTWT for P2P communication. In other embodiments, other bits (e.g., reserved bits from within or outside the bTWT information subfield) may be allocated/configured to indicate the presence or use of an optional rTWT parameter subfield ( ). The rTWT parameter subfield 920 may be the same as (or similar in structure or operation) to the rTWT parameter subfield 800 . In some embodiments, the interpretation of the bits in the rTWT parameter subfield 920 may also have different interpretations based on the device transmission subfield (e.g., different interpretations than the rTWT parameter subfield 800 in FIG. 8 translation similar). In some implementations, the rTWT parameter subfield 920 may not have reserved bits similar to the rTWT parameter subfield 800 . In other embodiments, other bits may be added/reset in the bTWT information subfield 910 so that other bits may be used in the rTWT parameter subfield 920 .

Referring back to FIG. 5 , in operation 510 , the first device 501 may transmit the configured subfields in the message/frame to the second device 520 (and/or other devices not shown). The second device 520 may receive from the first device 501 that the first device 501 allows/supports the second device 520 (and/or the third device 530) via the P2P link during the rTWT SP (eg, by setting such as in FIG. 8 Indication/announcement of P2P) transmission or reception delay-sensitive traffic allowed by bit 0 802. That is, the first device 501 can announce the support for P2P traffic during rTWT SP. Knowing this support obtained from the received configured subfield (e.g., in response to receiving the configured subfield from the first device 501), the second device 520 may respond to the request in operation 521 Extend the subfield of rTWT for P2P communication to configure.

The second device 520 may configure a subfield in operation 521 to request transmission of delay sensitive traffic over a P2P link (eg, between the second device 520 and the third device 530 ) during the rTWT SP. In some embodiments, the third device 530 may indicate to the second device 520 that the third device 530 has delay sensitive traffic that the third device 530 wants or can transmit over the P2P link during the rTWT SP. Additionally or alternatively, the second device 520 may determine that it has delay-sensitive traffic that the second device 520 wishes (or is able to) transmit to the third device 530 via the P2P link during the rTWT SP. In response, the second device 520 may request to extend rTWT for the P2P traffic in operation 521 using the rTWT parameter subfield as discussed with reference to FIGS. 6-9 . The second device 520 may intend to establish an rTWT protocol with the first device 501 so that during the rTWT SP, delivery via a link (e.g., a link between the first device 501 and the second device 520, and/or DL/UL transmission of the P2P link between the second device 520 and the third device 530 ). That is, the first device 501 and the second device 520 can negotiate to set the rTWT schedule.

In more detail of operation 521 , the second device 520 may configure a subfield to extend rTWT for P2P communication. Configured rTWT parameter subfields (eg, Figure 8) can be in the bTWT parameter set field/iTWT parameter set field as described in Figure 7 or in the bTWT information subfield as described in Figure 9 . As described herein, if the second device 520 sets and transmits the bTWT parameter set field and/or the rTWT parameter subfield in the iTWT parameter set field, the second device 520 can pass the TWT element field (e.g., FIG. One or more bits in the TWT element 601 in 6) indicate the presence of the rTWT parameter subfield.

Referring to both Figures 5 and 8, in the case where the second device 520 transmits a request to the first device 501 (eg, using the configured subfield in operation 521), when the first device 501 advertises the rTWT parameter subfield When field 800 (eg, via the configured subfield in operation 502), the bits in the rTWT parameter subfield 800 can be compared to the bits in the rTWT parameter subfield 800 transmitted by the first device 501 interpreted in different ways. For example, when the second device 520 transmits the rTWT parameter subfield 800, bit 0 (or any other predefined bit) 802 may indicate whether the second device 520 (or other rTWT of the requesting STA) has the / P2P traffic sent in rTWT SP (for example, whether P2P traffic exists). For example, if bit 0 is set, the second device 520 may have P2P traffic. If bit 0 is not set, the second device 520 may have no P2P traffic to send.

Continuing with the instance of the rTWT parameter subfield 800 being included in the frame/message transmitted by the second device 520 (eg, as configured in operation 521), bit 1 (or any other bit) 804 may indicate The type of traffic to be transmitted during the rTWT SP (eg, P2P only). For example, if bit 1 804 is set, the second device 520 may intend to only transmit P2P traffic during rTWT SP. If bit 1 804 is not set, the second device 520 can transmit both P2P traffic and non-P2P traffic during the rTWT SP, or can transmit non-P2P traffic during the rTWT SP. In one example, bit 1 804 may be set if the second device 520 and the third device 530 intend to communicate with each other during the entire rTWT SP (eg, P2P only). In contrast, for example, if the second device 520 and the third device 520 intend to communicate with each other during a part of the rTWT SP, and the second device 520 intends to communicate with the first device 501 during a second part of the rTWT SP, Then bit 1 804 may not be set.

In some embodiments, the interpretation of bit 2 (or any other bit) 806 when the second device 520 transmits the rTWT parameter subfield 800 may be the same as when the first device 501 transmits the rTWT parameter in operation 502 Subfield 800 is the same (or similar in structure or operation) interpretation (eg, an indication of whether the RDP protocol governs/is the channel access method used for P2P communication).

In other embodiments, after (or in response to) the message/frame containing the subfield received from the first device 501 in operation 510, the second device 520 may use the received composed The state subfield is used to start the program (eg, in operation 533). For example, the second device 520 can extract information from the subfields configured in operation 502 .

If after extracting the information from the configured subfields received by the first device 501, the second device 520 determines that the first device 501 does not allow/support transmission or reception of delay-sensitive traffic via the P2P link during the rTWT SP ( For example, in some embodiments, the bit 0 802 in FIG. 8 is not set or configured with a value of 0), then the second device 520 may not transmit P2P traffic during rTWT SP. If the first device 501 does allow/support transmission or reception of delay-sensitive traffic via the P2P link during the rTWT SP (eg, in some embodiments, bit 0 802 in FIG. 8 is set to a value of 1, for example), then As shown in operation 536, the second device 520 and the third device 530 may transmit delay sensitive traffic over the P2P link during one or more rTWT SPs.

In operation 516 , the second device 520 may transmit the configured subfields in the message/frame to the first device 501 . In operation 514, the first device 501 may respond to the configured subfield received from the second device 520 by configuring the second subfield to accept requests including P2P communication. In some embodiments, when the first device 501 responds to the second device 520's request, the first device 501 may transmit a response and/or approval reflecting the request from the second device 520 to indicate the second device 520's request rTWT parameter subfield response. For example, the bits in the rTWT parameter subfield transmitted by the second device 520 to the first device 501 may be the same as the bits in the rTWT parameter subfield transmitted by the first device 501 in response or similar. If the first device 501 accepts the request, the first device 501 may perform resource allocation and update the rTWT SP schedule. In other configurations, the first device 501 may transmit a response to modify (or reject or modify) the second device 520's request. In operation 518 , the first device 501 may transmit the configured subfields (or other acknowledgment/rejection) in the message/frame to the second device 520 in operation 514 .

In more detail of operation 533 and in some embodiments, the second device 520 may use the response message received from the first device 501 in operation 518 to initiate the process. For example, the second device 520 may extract information from the response message to determine whether the first device 501 approves or rejects the rTWT parameter subfield configured by the second device 520 in operation 521 . If the rTWT SP for P2P is approved, the second device 520 may transmit an indication of approving the rTWT SP for P2P to the third device 530 . If the rTWT SP for P2P communication is not approved, the second device 520 can further negotiate with the first device 501 .

In operation 536, if P2P communication is approved/supported (indicated via the configured sub-field of the first device 501 at operation 514), the second device 520 and the third device 520 may communicate in one or more rTWT SP During this period, delay-sensitive traffic is transmitted via the P2P link.

Certain devices may operate communications according to rTWT to prioritize and reserve slots for delay sensitive traffic. Meanwhile, legacy systems or devices that do not support rTWT operations may attempt to access channels during reserved periods for devices that support rTWT operations (eg, rTWT Service Period (SP)). Devices that do not support rTWT can interfere with delay sensitive traffic without mechanisms to protect the reservation time slot and/or rTWT operation.

To address these issues, according to certain aspects, embodiments in this disclosure relate to techniques for configuring legacy/existing/specific communication systems or devices to support or comply with rTWT operation. In some embodiments, devices (e.g., STAs, extremely high throughput (EHT) STAs, STAs that are not AP STAs or STA MLDs) may support/comply with/observe protection for rTWT-active or rTWT-supported users/devices channel access rules. For example, non-AP STAs may support/follow/observe channel access rules that protect the start time of the rTWT SP.

In one approach, for example, one or more access point and station devices conforming to the Wi-Fi standard can implement a capability field to protect rTWT operation (eg, to protect rTWT service periods). In one approach, a device (eg, access point or station device) may transmit a rTWT operation support field (transmit a message with the rTWT operation support field) indicating whether the device can support rTWT operation (as a first capability). The rTWT operation support field can be set in the EHT capability field (or information element (IE)). If two devices (eg, an access point and a station device) can support rTWT operation, then both devices can operate according to rTWT operation (eg, according to rTWT access rules). The rTWT operation support field set by the AP may indicate the capability of the AP such that the AP is a rTWT scheduling AP and can set rTWT scheduling and/or establish membership in rTWT scheduling. The rTWT operation support field set by the non-AP STA may indicate the capabilities of the non-AP STA such that the non-AP STA is a rTWT scheduling STA and can set up rTWT scheduling and/or establish membership in rTWT scheduling.

In one approach, a device (e.g., an access point or station device) that may or may not support rTWT operations (e.g., corresponding to its RTWT Operations Support" field) may specify whether the device can support start time (windows) protection A restricted TWT start time protection (RSTP) support capability field (as a second capability) (eg, indicated by transmitting a frame with the restricted TWT start time protection support capability field). For example, the RSTP support capability field may indicate whether the device supports access rules for protecting service periods (SPs) that are reserved for or limited by delay-sensitive traffic. The RSTP support capability field can be set in the EHT capability field (or IE). If the station device does not support RSTP capability (for example, does not send a frame announcing/indicating that its "RSTP support" field is set to 1), and the access point communicates with another device or is scheduled to operate according to rTWT To communicate with another device, the access point may reject or reject association with the station device so that the station device may not interfere with (delay-sensitive or rTWT-based) communications between the access point and the other device. If the station device supports RSTP capability (the RSTP support field of the station device is set to 1), the access point may allow communication with the station device, but may prompt or direct (or agree with) the access rules for rTWT operation Consistent) a station device ends its communication before the service period allocated or reserved for another device begins. In some embodiments, non-AP STAs may support channel access rules that protect the rTWT SP start time by obtaining a transmission opportunity (TXOP) before the rTWT SP start time and ending the TXOP before the rTWT SP start time. Thus, service periods/periods reserved or allocated in accordance with rTWT operation may be protected from interference from legacy or other devices that may not support or operate in accordance with rTWT operation. Thus, for example, delay sensitive traffic for AR/VR content/applications can be operated with reduced latency/delay via rTWT.

In one approach, the capability of rTWT operation support (as a first capability) and/or RSTP support (as a second capability) may be included in an information element (IE ) indicated/specified. In some embodiments, the EHT Capability Information Element (IE) may include fields for Element ID, Length, Element ID Extension, EHT MAC Capability Information, and/or EHT PHY Capability Information.

In some embodiments, the field of EHT MAC capability information may include subfields of rTWT operation support and/or rTWT start time protection (RSTP) support. The sub-fields supported by rTWT operation can be set by AP and/or non-AP STA. A device (eg, AP or non-AP STA) may set the rTWT Operation Support and/or RSTP Support subfields to respective values in a frame, and send a frame announcing those values to one or more devices. In some embodiments, the sub-field of rTWT Operational Support may be different from the field of rTWT Capabilities. The EHT AP can set the rTWT operation support sub-field to 1 (support) or 0 (no support). EHT non-AP STAs can set the rTWT operation support sub-field to 1 (support) or 0 (no support).

In some embodiments, the subfield of RSTP support can be set by the AP and/or non-AP STA. EHT STAs (eg, non-AP STAs) may set the RSTP Support subfield to 1 (support) or 0 (no support). An EHT STA supporting rTWT operation may set both rTWT operation support and RSTP support subfields to 1 in a frame and broadcast/transmit a frame to notify other devices (eg, AP). In some embodiments, the EHT non-AP STA can independently set the rTWT operation support subfield and the RSTP support subfield. In some embodiments, if the STA sets the rTWT operation support subfield to 1, the EHT non-AP STA may set the RSTP support subfield to 1. In some instances, the RSTP support subfield may not be available in frames sent/announced by the EHT AP.

In some embodiments, fields for EHT MAC capability information may include National Security and Emergency Preparedness (NSEP) Priority Access Support, EHT Mode of Operation (OM) Control Support, Triggered Transmission Opportunity (TXOP) Sharing Support, Restricted TWT Support, Stream Classification Service (SCS) Traffic Description Support and/or Reserved subfields. The restricted TWT support subfield may indicate support for rTWT operational support and/or RSTP support capabilities. In some embodiments, the restricted TWT support subfield may be two bits long. For example, a device (e.g., ETH STA or ETH AP) may set the Restricted TWT Support subfield to: (1) (binary) value 00, where rTWT is not implemented in the device (e.g., in case RestrictedTWTImplemented is false); (2) value 01 (alternative value 10), in case device supports/enforces/follows channel access rules protecting rTWT SP start time; and (3) value 10 (alternative value 01), where the device supports/implements rTWT operations that may or may not support/implement channel access rules that protect the rTWT SP start time. The value 11 can be reserved.

In one approach, the AP (e.g., EHT AP) may indicate to the AP whether it requires or prefers that the associated non-AP STA support rTWT operation (as a first capability) and/or support channel access rules to protect the rTWT SP start time (as a second ability). In some embodiments, an EHT Operational Information Element (IE) may be included in a Management Frame (e.g., a Beacon Frame) such that the Management Frame may be broadcast/announced to an EHT STA, which may receive an Operational Information Element from the EHT Obtain channel configuration information (for example, if operating in the 6 GHz band).

In some embodiments, the EHT Operation IE may include fields for Element ID, Length, Element ID Extension, and/or EHT Operation Information. The EHT Operation Information field of the EHT Operation IE and the EHT MAC Capability Information subfield of the EHT Capability IE may be in different frames. The EHT Operation Info field may include a rTWT Required subfield to indicate whether the AP (e.g., EHT AP) requires or prefers that the associated non-AP STA support Tunnel Access Rules to protect rTWT SP start time (as a second capability) And/or support rTWT operations that may or may not support channel access rules to protect rTWT SP start times (as a first capability).

In some embodiments, rTWT-scheduled APs may require EHT non-AP STAs to support RSTP (as a second capability) in order to associate with the AP, or to operate on the link over which the STA associates with the AP. The AP may set the subfield of rTWTRequired (which may be one bit long) to 1 to instruct the AP to require EHT non-AP STAs to support RSTP. In some specific examples, if the AP sets the rTWT operation support field of the EHT MAC capability information field to 1, the AP may set the rTWT requirement subfield of the EHT operation information field to 1. If the AP sets the rTWT Requirement subfield of the EHT Operation Information field to 1, then during association (or re-association), it can only be set to 1 if the STA's RSTP Support field (of the EHT MAC Capability Information field) is set to 1 The EHT non-AP STA is allowed to associate with the AP under the circumstances.

Alternatively, in some embodiments, the rTWT required subfield may be two bits long to indicate whether the AP (e.g., EHT AP) requires or prefers that the associated non-AP STA support the first capability and/or the second capability . For example, an AP (e.g., an ETH AP) may set the rTWT required subfield to: (1) (binary) value 01 (or other specific value) to indicate that the AP prefers non-AP STAs to support RSTP (as a second capability ); (2) a value of 10 (or other specific value) to indicate that the AP requires the non-AP STA to support RSTP (as a second capability) so that the non-AP STA will put the EHT MAC capability information field (transmitted by the non-AP STA) in the When the rTWT support subfield is set to 01 or 10, the non-AP STA meets the requirements; (3) the value is 11 (or other specific value) to indicate that the AP requires the non-AP STA to support rTWT operation (as the first capability) so that In case the non-AP STA sets the rTWT Support subfield in the EHT MAC Capability Information field (transmitted by the non-AP STA) to 10, the non-AP STA complies with the requirement; and (4) otherwise the value 00. In some embodiments, sub-fields required by rTWT may or may not be reserved for non-AP STAs (eg, EHT non-AP STAs).

In one approach, a STA (e.g., AP STA or non-AP STA) may transmit information to announce that the STA is capable of supporting rTWT operation (as a first capability), and/or (at least) based on Ability to operate on channel access rules (as a secondary capability). In some embodiments, the STA may instruct the STA to support rTWT operation including channel access rules protecting the restricted TWT SP start time (eg, including the first capability of the second capability). One or more capabilities may be indicated in a capability information field (eg, EHT MAC capability information field). The capability information field may be in an information element (IE) of a frame (eg, beacon frame, probe request frame, etc.). In some embodiments, one or more capabilities may be independently indicated in individual subfields (eg, subfields of rTWT Operational Support and RSTP Support). In some embodiments, one or more capabilities may be indicated in a single subfield (eg, a restricted TWT support subfield). For example, the restricted TWT support subfield may include, for example, two bits. The restricted TWT support subfield can be set to: (1) a binary value of 00 to indicate that the STA does not support rTWT; (2) a binary value of 01 (or other specific value) to indicate that the STA may not support rTWT operation but may support it RSTP; and (3) a binary value of 10 to indicate that the STA supports rTWT operations (eg, setting rTWT schedules and/or establishing membership in rTWT schedules) and can support RST. For example, a binary value of 11 may be reserved for or may be used for another purpose/function.

In one approach, the AP may transmit information to announce different requirements for association with STAs in the wireless network (eg, the BSS of the WLAN). In some embodiments, the AP may transmit/broadcast/share EHT operational information to notify rTWT requirements. For example, the AP may set the rTWT Required subfield to 01 (or other value) to indicate to the AP that it prefers that non-AP STAs support RSTP (e.g., via the binary bit in the Restricted TWT Support subfield of the Capability Info field value 01 or 10 matches). The AP may set the rTWT Required subfield to the binary value 10 (or other value) to instruct the AP to require non-AP STAs to support RSTP (e.g., via the binary value in the Restricted TWT Support subfield of the CapabilitiesInfo field 01 or 10 match). The AP may set the rTWT Required field to the binary value 11 (or other value) to instruct the AP to require non-AP STAs to support rTWT operations (e.g., via the binary value in the Restricted TWT Support subfield of the Capabilities Info field 10 matches).

In one approach, upon receiving information about the capabilities of a non-AP STA specified in a frame (e.g., a probe request frame or an association request frame), the AP may determine whether the capabilities of the non-AP STA comply with the AP requirements or preferences. In response to determining that the AP's requirements or preferences are not met and the non-AP STA is already associated, the AP may disassociate from the non-AP STA as a non-compliant STA by sending a disassociation frame. In response to determining that the AP's requirements or preferences are not met and the frame is an association request frame (sent during the association procedure), the AP may not associate with a non-AP STA that is a non-compliant STA.

In some embodiments, if the AP sets the rTWT required subfield to a binary value of 01 (indicating the AP's preference for RSTP support as a secondary capability), then upon receiving from a non-AP STA an After a frame with a value of 01 nor a restricted TWT support subfield set to a binary value of 10, the AP may depend on one or more non-TWT conditions including at least one of traffic conditions, load conditions, or channel conditions And it is determined to disassociate or not to associate with the non-AP STA which is a non-compliant STA. For example, the AP may determine whether one or more non-TWT conditions are unfavorable, and in response to determining that one or more non-TWT conditions are unfavorable (e.g., a value indicating a non-TWT condition is less than a threshold value), the AP may communicate with the non-AP The STA disassociates or does not associate with it. In response to determining that one or more non-TWT conditions are good (eg, a value indicating a non-TWT condition is greater than or equal to a threshold value), the AP may associate or maintain association with a non-AP STA. In determining whether one or more non-TWT conditions are bad, the AP can monitor wireless traffic on the current operating channel by configuring the wireless adapter (e.g., wireless network interface 320) in monitor mode or promiscuous mode, by Obtaining BSS load information indicative of the number of STAs associated with a particular BSS or channel usage or the like to monitor network load and/or perform one or more measurements on currently operating wireless channels. The measurements may use metrics including at least one of signal strength, such as received signal strength indicator (RSSI), signal-to-noise ratio (SNR), or packet error rate of the wireless signal. For example, when the rTWT requires subfield is set to 1, the response to the determination indicates that the value of the load condition (eg, BSS load on the uplink (UL) or downlink (DL)) is greater than or equal to the load threshold Limit and/or value indicating channel condition (e.g., RSSI) is greater than or equal to the channel threshold, the AP may determine that a non-compliant STA (with neither binary in the Restricted TWT Support subfield of the Capability Information field) The value 01 also does not have the binary value 10) associated or remains associated with it (if already associated).

In some embodiments, if the AP sets the rTWT required subfield to a binary value of 10 (indicating the AP's requirement for RSTP support as a secondary capability), then upon receiving from a non-AP STA an The AP may decide to disassociate with a non-AP STA that is a non-compliant STA or Not associated with it. On the other hand, the AP may decide to associate with the non-AP STA after receiving a frame from the non-AP STA including the restricted TWT support subfield set to the binary value 01 (indicating the second capability) (during the association procedure period), or remain associated with it (if already associated). In some embodiments, if a binary value of 10 in the Restricted TWT Support subfield (indicating support of the first capability) also indicates support of the second capability, then the include set to the binary value is received from a non-AP STA After the frame of the restricted TWT support subfield with a binary value of 01 or 10, the AP may determine to associate with a non-AP STA or maintain association with it.

In some specific examples, if the AP sets the rTWT requirement sub-field to a binary value of 11 (indicating the AP's requirement for rTWT operation support as the first capability), then upon receiving from a non-AP STA the After the frame of the restricted TWT support subfield with a value of 10 (indicating the first capability), the AP may decide to disassociate or not associate with the non-AP STA which is a non-compliant STA. On the other hand, the AP may decide to associate with the non-AP STA after receiving a frame from the non-AP STA including the restricted TWT support subfield set to the binary value 10 (indicating the first capability) (during the association procedure period), or remain associated with it (if already associated).

In some embodiments, the STA may retain/track/store TWT capability announcements and/or TWT requirements received from the AP. The STA may decide to send the association request frame to the specific AP based on the TWT capability announcement and/or TWT request received from the specific AP, and if so, send the association request frame to the specific AP.

In some embodiments, the AP may retain/track/store TWT capability announcements received from STAs. After receiving an association request from a specific STA, the AP may determine whether the AP is associated with the specific STA based on the TWT capability announcement received from the specific STA. The AP may then send an association response frame to the specific AP indicating whether the association request is accepted/approved. If the specific STA is already associated with the AP, the AP may determine whether the AP maintains association with the specific STA based on the TWT capability announcement received from the specific STA. If the AP determines that the AP is no longer associated with the specific STA, the AP may send a disassociation frame to the specific STA.

In one approach, the AP may be one AP STA of an AP MLD with multiple AP STAs. Here, an MLD is a device that can perform transmission and reception on more than one wireless interface link. In this configuration, each AP STA of the AP MLD may receive the following announcement: STA (e.g., non-AP STA or non-AP MLD STA) has the capability to support rTWT operation (as the first capability), and/or (at least) Ability to operate according to the channel access rules used to protect the rTWT SP start time (as a secondary capability). Each AP STA of the AP MLD may transmit information to declare that the AP STA has the capability to support rTWT operation (as the first capability), and/or (at least) the capability to support RSTP (as the second capability). Each AP STA of the AP MLD may transmit information to announce different requirements for association with STAs in the wireless network using the rTWT Requirements subfield of the EHT Operational Information field.

In some embodiments, a STA may perform communication on a per-link basis regarding association/disassociation with the AP MLD (eg, communication with a selected link of the AP MLD). A STA may perform communications regarding association/disassociation with an AP STA of an AP MLD in a manner similar to how a STA performs communications regarding association/disassociation with a non-MLD AP. For example, the STA can send an association request to the AP STA of the AP MLD, the AP STA of the AP MLD can send an association response to the STA, and/or the AP STA of the AP MLD can be similar to the communication between a STA and a non-MLD AP Disassociation is sent to the STA in the same way.

In some embodiments, if the rTWT Requirements subfield of the EHT Operational Information field acts as a subfield of "RSTP Support Required" to indicate whether RSTP support is required, the AP MLD may include all RSTP support requirements on selected links of the AP MLD. The required subfield is set to 0 or 1. For example, in an AP MLD where there is/is at least one link that does not require RSTP support, if there are any legacy non-AP STAs or if there are any EHT non-AP STAs that do not support RSTP on the link, the AP MLD can target This link sets the RSTP Support Required subfield to 0. In some embodiments, the AP MLD may only set the RSTP Support Required subfield to 1 on the 6 GHz link of the AP MLD, if available, which is a first generation, green channel, and no legacy link. If the AP MLD does not support the 6 GHz link, the AP MLD may set the RSTP Support Required subfield to 1 on the AP MLD's selected 5 GHz link. In some embodiments, the AP MLD may only set the RSTP Support Required subfield to 1 on the AP MLD's 5 GHz link, if available. If the AP MLD does not support the 5 GHz link, the AP MLD may set the RSTP Support Required subfield to 1 on the AP MLD's selected 6 GHz link.

In one approach, an apparatus may include one or more processors. The one or more processors may determine a capability code indicative of at least one of a plurality of defined capabilities of the device related to rTWT operation in a WLAN. The one or more processors may wirelessly transmit via a transmitter a first frame including the capability code.

In some embodiments, the first frame may be a management frame including an Information Element (IE). The capability code may be included in the IE of the management frame. In some embodiments, the plurality of defined capabilities can include the ability to perform one of the rTWT operations. The rTWT operations may include at least one of setting up an rTWT schedule or establishing membership in an rTWT schedule.

In some embodiments, the plurality of defined capabilities may include a capability to complete or terminate a transmission at a start time of an rTWT service period (SP) assigned to another device. The one or more processors can be configured to obtain a transmission opportunity (TXOP) before the start time such that a duration of the TXOP ends before the start time.

In one approach, an access point may include one or more processors. The one or more processors may determine a set indicating a preference or requirement related to restricted target wake-up time (rTWT) operation for a device associated with the access point in a wireless area network (WLAN). state. The one or more processors may receive a first frame from the device indicating a request for association with the access point and including indicating at least one of a plurality of defined capabilities of the device A capability code of the reader. The one or more processors can determine whether to accept the request according to the configuration and the capability code.

In some embodiments, the one or more processors can be configured to determine whether the capability code indicates one or more capabilities related to the rTWT operations. The one or more processors may be configured to deny the request in response to the capability code not indicating one or more capabilities related to the rTWT operations.

In some embodiments, the capability code may indicate at least one of: (1) a capability not related to the rTWT operations; (2) a rTWT service period (SP) assigned to another device A first rTWT capability to complete or terminate a transmission at a start time; or (3) a second rTWT capability to perform the rTWT operations. The configuration may indicate one of the following: (1) a preference that the device supports the first rTWT capability; (2) a request that the device supports the first rTWT capability; or (3) a request that the device supports the first rTWT capability; One of the two rTWT competencies is required. In response to (1) the configuration indicating the preference for the first rTWT capability and (2) the capability code indicating neither the first rTWT capability nor the second rTWT capability, the one or more processors Can be configured to determine whether to accept the request based on one or more conditions of the access point, the one or more conditions including at least one of a traffic condition, a load condition or a path condition. In some embodiments, the one or more processors may be configured to accept the request in response to (1) the configuration indicating the first capability and (2) the capability code indicating the first capability. request, and transmit a response frame in response to the first frame to the device.

Embodiments of the present disclosure have at least the following advantages and benefits.

First, embodiments in this disclosure may provide useful techniques for providing a mechanism for a device to transmit an rTWT operation support field indicating whether the device can support rTWT operation. Therefore, if the rTWT operation support fields of the two devices indicate that the two devices can support rTWT operation, then the two devices can operate according to rTWT operation or rTWT access rules. In this way, a device can perform rTWT operations (eg, for delay sensitive traffic/applications) without interfering with devices that do not support rTWT.

Second, the specific examples in this disclosure may provide useful techniques for providing a mechanism for a device (e.g., STA) to specify an RSTP support capability field indicating whether the device can support rTWT SP's start time (window) protection . The AP may allow communication with the STA if the STA sets the RSTP Support Capability field to indicate that the STA can support rTWT SP start time protection. If the STA does not specify the RSTP support capability field, the AP may not allow communication with the STA. Thus, service periods/periods reserved or allocated in accordance with rTWT operation may be protected from interference from legacy or other devices that may not support or operate in accordance with rTWT operation. Thus, for example, delay sensitive traffic for AR/VR content/applications can be operated with reduced latency/delay via rTWT.

Third, embodiments in this disclosure may provide a mechanism for an AP to indicate whether an associated non-AP STA is required or preferred to support channel access rules to protect rTWT SP start times and/or rTWT operations useful technology. In this way, the AP can selectively associate/disassociate with non-AP STAs based on the AP's requirements/preferences and the non-AP STA's rTWT-related capabilities.

FIG. 10A is an exemplary format for fields of an extremely high throughput (EHT) capability element (or information element (IE)) 1000 according to an exemplary implementation of the present disclosure. In some embodiments, the capability of rTWT operation support (as a first capability) and/or RSTP support (as a second capability) may be indicated/specified in the EHT Capability IE 1000, which is a frame (e.g., message information elements (IEs) such as tags, probe requests, response frames, etc.). In some embodiments, EHT Capability IE 1000 may include fields for Element ID 1010 , Length 1011 , Element ID Extension 1012 , EHT MAC Capability Information 1013 and/or EHT PHY Capability Information 1014 .

In some embodiments, fields for EHT MAC Capability Information 1013 may include National Security and Emergency Preparedness (NSEP) Priority Access Support 1021, EHT Mode of Operation (OM) Control Support 1022, Triggered Transmission Opportunity (TXOP) Sharing Support 1023, rTWT Operation Support 1024, rTWT Start Time Protection (RSTP) Support 1025, Streaming Classification Service (SCS) Traffic Description Support 1027 and/or Reserve 1028 sub-fields. The sub-field of rTWT operation support 1024 can be set by AP and/or non-AP STA. A device (eg, AP or non-AP STA) may set the rTWT Operation Support and/or RSTP Support subfields to respective values in a frame, and send a frame announcing those values to one or more devices. In some embodiments, the rTWT Operational Support 1024 subfield may be different from the rTWT Capabilities field. The EHT AP may set the sub-field of rTWT Operation Support 1024 to 1 (support) or 0 (no support). The EHT non-AP STA may set the rTWT Operation Support 1024 sub-field to 1 (support) or 0 (no support).

In some embodiments, the RSTP Support 1025 subfield can be set by the AP and/or the non-AP STA. EHT STAs (eg, non-AP STAs) may set the RSTP Support 1025 subfield to 1 (support) or 0 (no support). An EHT STA supporting rTWT operation may set both rTWT operation support 1024 and RSTP support 1025 subfields to 1 in a frame and broadcast/transmit the frame to notify other devices (eg, AP). In some embodiments, the EHT non-AP STA can set the rTWT operation support subfield 1024 and the RSTP support subfield 1025 independently. In some embodiments, if the STA sets the rTWT operation support subfield 1024 to 1, the EHT non-AP STA may set the RSTP support subfield 1025 to 1. In some embodiments, the RSTP support subfield 1025 may not be available in frames sent/announced by the EHT AP.

FIG. 10B is another example format for fields of an EHT Capability element (or EHT Capability IE) 1050 according to an example implementation of the present disclosure. EHT Capabilities IE 1050 may include fields for Element ID 1050, Length 1051, Element ID Extension 1052, and/or EHT PHY Capability Information 1054, which are similar to Element ID 1010, Length 1011, Element ID Extension 1012 in EHT Capabilities IE 1050, respectively and/or fields of EHT PHY Capability Information 1014. The EHT Capability IE 1050 may include a field for EHT MAC Capability Information 1053 . EHT MAC capability information 1053 may include subfields of NSEP priority access support 1061, EHT OM control support 1062, TXOP sharing support 1063, SCS traffic description support 1065 and/or reserved 1065, which are similar to EHT MAC capability information respectively NSEP priority access support 1021 , EHT OM control support 1022 , TXOP sharing support 1023 , SCS traffic description support 1027 and/or reserved 1028 subfields in 1013 are defined.

In some embodiments, the EHT MAC Capability Information 1053 field may include a Restricted TWT Support 1064 subfield. The restricted TWT support subfield 1064 may indicate support for the capabilities of rTWT operational support (as a first capability) and/or RSTP support (as a second capability). In some embodiments, the restricted TWT support subfield 1053 can be two bits long. For example, a device (e.g., ETH STA or ETH AP) may set the Restricted TWT Support subfield 1053 to: (1) (binary) value 00, where rTWT is not implemented in the device (e.g. , in case RestrictedTWTImplemented is false); (2) value 01 (alternatively value 10), in case device supports/enforces/follows channel access rules protecting rTWT SP start time; and (3) value 10 ( Alternative value 01), in case the device supports/implements rTWT operations that may or may not support/implement channel access rules that protect the rTWT SP start time. The value 11 can be reserved.

FIG. 11 is an exemplary format of fields of an EHT operation element (or EHT operation IE) 1100 according to an exemplary implementation of the present disclosure. In some embodiments, the AP (e.g., EHT AP) may indicate to the AP whether it requires or prefers that the associated non-AP STA support rTWT operation (as a first capability) and/or support channel access to protect the rTWT SP start time Rules (as a secondary ability). In some embodiments, the EHT Operation IE 1100 can be included in a management frame (e.g., a beacon frame) such that the management frame can be broadcast/announced to the EHT STA, which can obtain the channel set from the EHT Operation Information Element status information (for example, if operating in the 6 GHz band).

In some embodiments, EHT Operation IE 1100 may include fields for Element ID 1110 , Length 1111 , Element ID Extension 1112 , and/or EHT Operation Information 1114 . The EHT Operation Information field 1114 of the EHT Operation IE 1100 (see FIG. 11 ) and the EHT MAC Capability Information subfields 1013, 1053 of the EHT Capability IEs 1000, 1050 (see FIGS. 10A and 10B ) may be in different frames. EHT Operation Information field 1114 may include a subfield of rTWT Requirements 1133 to indicate whether the AP (e.g., EHT AP) requires or prefers that the associated non-AP STA support Tunnel Access Rules to protect the rTWT SP start time (as the second capabilities) and/or support rTWT operations that may or may not support channel access rules to protect rTWT SP start times (as a first capability).

In some embodiments, the rTWT requires that the subfield of 1133 may be one bit long. The rTWT-scheduled AP may require EHT non-AP STAs to support RSTP (as a secondary capability) in order to associate with the AP, or to operate on the link through which the STA associates with the AP. The AP may set the subfield of rTWTRequired 1133 (which may be one bit long) to 1 to instruct the AP to require EHT non-AP STAs to support RSTP. In some specific examples, if the AP sets the rTWT operation support field 1024 of the EHT MAC capability information field 1013 to 1, the AP may set the rTWT requirement subfield 1133 of the EHT operation information field to 1. If the AP sets the rTWT request sub-field 1133 of the EHT operation information field to 1, then during association (or re-association), it can only pass in the RSTP support field 1025 of the STA (of the EHT MAC capability information field 1013) When set to 1, EHT non-AP STAs are allowed to associate with the AP.

Alternatively, in some embodiments, the rTWT Requirements 1133 subfield may be two bits long to indicate whether the AP (e.g., EHT AP) requires or prefers that the associated non-AP STA support the first capability and/or the second capability. ability. For example, an AP (e.g., an ETH AP) may set the rTWT required subfield 1133 to: (1) (binary) value 01 (or other specific value) to indicate to the AP that it prefers that non-AP STAs support RSTP (as a second capability); (2) a value of 10 (or other specific value) to indicate that the AP requires the non-AP STA to support RSTP (as the second capability) so that the EHT MAC capability information field 1053 (transmitted by the non-AP STA) will be sent to the non-AP STA ) in the rTWT support subfield 1064 is set to 01 or 10, the non-AP STA meets the requirements; (3) the value 11 (or other specific value) to indicate that the AP requires the non-AP STA to support rTWT operation (as the first capability ) such that the non-AP STA is compliant if the non-AP STA sets the rTWT support subfield 1064 in the EHT MAC capability information field 1053 (transmitted by the non-AP STA) to 10; and (4) in other The case value is 00. In some embodiments, the subfield of rTWT Requirement 1133 may or may not be reserved for non-AP STAs (eg, EHT non-AP STAs).

12 is a block diagram of a system environment 1200 in which a client device 1210 and an AP 1250 communicate data related to rTWT capabilities and requirements, according to an exemplary implementation of the present disclosure. The client device 1210 can be a non-AP STA, HWD or computing device. In some embodiments, the device 1210 may include a TWT capability manager 1230 for communicating data related to the rTWT capability of the device 1210 . In some embodiments, the TWT capability manager 1230 includes electronic components or a combination of electronic components and software components. For example, the TWT capability manager 1230 may include: a TWT capability/requirement tracker 1232 configured to retain/track/store rTWT requirements received from other devices (e.g., APs); and/or an association requestor 1234, which is configured to send an association request to the AP associated with the client device 1210.

In some embodiments, AP 1250 can be an AP in a WLAN, a soft AP, or a computing device. In some embodiments, the AP 1250 may include a TWT requirement manager 1270 for communicating data related to the rTWT requirements/preferences of the AP 1250 . In some embodiments, TWT requirements manager 1270 includes electronic components or a combination of electronic components and software components. For example, the TWT requirements manager 1270 may include: a non-TWT condition monitor 1272 configured to monitor one or more non-TWT conditions; a TWT capability tracker 1272 configured to retain/track/store rTWT capabilities received by other devices (e.g., client devices); and/or the association manager 1274 configured to send an association response to the client device from which the request for association was received or to send a disassociation to Clients associated with AP 1250.

In some embodiments, a STA (e.g., UE 1210 or AP 1250) may transmit information (e.g., TWT Capability Announcement 1280 transmitted by UE 1210, TWT Capability Announcement 1281 transmitted by AP 1250) to announce The STA has the capability to support rTWT operation (as the first capability), and/or (at least) the capability to operate according to the channel access rules used to protect the rTWT SP start time (as the second capability). In some embodiments, the STA may instruct the STA to support rTWT operation including channel access rules protecting the restricted TWT SP start time (eg, including the first capability of the second capability). One or more capabilities may be indicated in a capability information field (eg, EHT MAC capability information fields 1000, 1050). The capability information field may be in an information element (IE) of a frame (eg, beacon frame, probe request frame, etc.). In some embodiments, one or more capabilities may be independently indicated in individual subfields (eg, subfields of rTWT Operation Support 1024 and RSTP Support 1025 of ETH MAC Capability field 1013). In some embodiments, one or more capabilities may be indicated in a single subfield (eg, restricted TWT support subfield 1064 of ETH MAC capabilities field 1053). For example, the restricted TWT support subfield 1064 may include, for example, two bits. The restricted TWT support subfield 1064 may be set to: (1) a binary value of 00 to indicate that the STA does not support rTWT; (2) a binary value of 01 (or other specific value) to indicate that the STA may not support rTWT operation but may RSTP is supported; and (3) a binary value of 10 to indicate that the STA supports rTWT operations (eg, setting rTWT schedules and/or establishing membership in rTWT schedules) and may support RSTP. For example, a binary value of 11 may be reserved for or may be used for another purpose/function.

In some embodiments, AP 1250 (or TWT Requirement Manager 1270 ) may transmit information to announce different requirements for association with STAs in the wireless network (eg, BSS of a WLAN) (eg, TWT Requirement Announcement 1283 ). In some embodiments, AP 1250 may transmit/broadcast/share EHT operational information to notify rTWT requirements. For example, the AP 1250 may set the rTWT Required subfield 1133 to 01 (or other value) to indicate to the AP that non-AP STAs support RSTP (e.g., via the Restricted TWT Support subfield 1064 of the Capability Info field 1053 The binary value 01 or 10 in matches). The AP 1250 may set the rTWT Requirement subfield 1133 to a binary value of 10 (or other value) to instruct the AP to require non-AP STAs to support RSTP (e.g., via the Restricted TWT Support subfield 1064 of the Capability Info field 1053 The binary value 01 or 10 corresponds). AP 1250 may set rTWT Required field 1133 to binary value 11 (or other value) to instruct AP to require non-AP STAs to support rTWT operations (e.g., via Restricted TWT Support subfield 1064 of Capability Information field 1053 The binary value 10 corresponds to).

In some embodiments, upon receiving information regarding the capabilities of a non-AP STA (e.g., client device 1210) specified in a frame (e.g., a probe request frame or an association request frame), the AP 1250 (or TWT capability tracker 1274) may determine whether the capabilities of the non-AP STA meet the AP's requirements or preferences. In response to determining that the AP's requirements or preferences are not met and the non-AP STA is already associated, the AP (or association manager 1276) may disassociate from the non-AP STA as a non-compliant STA by sending a disassociation frame. In response to determining that the AP's requirements or preferences are not met and the frame is an association request frame (eg, association request 1291 ), association manager 1276 may not associate AP 1250 with a non-AP STA that is a non-compliant STA.

In some embodiments, if the AP 1250 sets the rTWT required subfield 1133 to a binary value of 01 (indicating the AP's preference for RSTP support as a secondary capability), then the non-AP STA (e.g., UE 1210 ) upon receiving a frame that includes the Restricted TWT Support subfield 1133 that is neither set to a binary value of 01 nor set to a binary value of 10, the AP (or TWT Capability Tracker 1274) may depend on including the traffic condition One or more non-TWT conditions of at least one of, load condition, or channel condition determine to disassociate or not associate with a non-AP STA that is a non-compliant STA. For example, AP 1250 (or non-TWT condition monitor 1272) may determine whether one or more non-TWT conditions are bad, and respond to determining that one or more non-TWT conditions are bad (e.g., a value indicating a non-TWT condition of less than threshold), the AP (or Association Manager 1276) may disassociate or not associate with non-AP STAs. In response to determining that one or more non-TWT conditions are good (eg, indicating that the value of the non-TWT condition is greater than or equal to a threshold value), the AP (or association manager 1276 ) may associate or maintain association with the non-AP STA. In determining whether one or more non-TWT conditions are bad, the (or association manager 1276) can monitor the current operating channel by setting the wireless adapter (e.g., wireless network interface 320) in monitor mode or promiscuous mode wireless traffic, monitor network load by obtaining BSS load information indicating the number of STAs associated with a particular BSS or channel usage, or the like, and/or perform one or more Measure. The measurements may use metrics including at least one of signal strength, such as received signal strength indicator (RSSI), signal-to-noise ratio (SNR), or packet error rate of the wireless signal. For example, when rTWT requires subfield 1133 to be set to 1, the value in response to a determination indicating a load condition (e.g., BSS load on the uplink (UL) or downlink (DL)) is greater than or equal to the load Threshold and/or value indicating channel condition (e.g., RSSI) is greater than or equal to the channel threshold, non-TWT condition monitor 1272 or association manager 1276 can determine the same as non-compliant STA (in the capacity information field 1053 subject Only TWT Support subfield 1064 has neither a binary value of 01 nor a binary value of 10) associated with or remains associated with (if already associated).

In some embodiments, if the AP 1250 sets the rTWT required subfield 1133 to a binary value of 10 (indicating the AP's requirement for RSTP support as the second capability), then upon receipt from a non-AP STA including a subfield that is neither set to The AP (or TWT Capability Tracker 1274) may determine the same A non-AP STA that is a non-compliant STA disassociates or does not associate with it. On the other hand, upon receiving a frame from a non-AP STA that includes the restricted TWT support subfield 1064 set to a binary value of 01 (indicating a second capability), the TWT capability tracker 1274 may determine that a non-AP STA is associated with (during the association procedure), or maintain association with it (if already associated). In some embodiments, if a binary value of 10 in the Restricted TWT Support subfield 1064 (indicating support of the first capability) also indicates support of the second capability, then the include set to the binary After the frame of the restricted TWT support subfield with a value of 01 or a binary value of 10, the TWT capability tracker 1274 may determine to associate or maintain association with a non-AP STA.

In some specific examples, if the AP 1250 sets the rTWT requirement subfield 1133 to a binary value of 11 (indicating the AP's requirement for rTWT operation support as the first capability), then the non-AP STA includes an unset After the frame of the restricted TWT support 1064 subfield with a binary value of 10 (indicating the first capability), the AP may determine to disassociate or not associate with the non-AP STA that is a non-compliant STA. On the other hand, the AP (or TWT Capability Tracker 1274 ) may determine the connection to the non-AP STA upon receiving a frame from the non-AP STA including the Restricted TWT Support subfield set to a binary value of 10 (indicating the first capability). AP STA associates (during the association procedure), or maintains association with it (if already associated).

In some embodiments, a non-AP STA (eg, UE 1210 or TWT capability/requirement tracker 1232 ) may retain/track/store TWT capability announcements and/or TWT requirements received from the AP. A non-AP STA (e.g., UE 1210) may decide to associate a request frame based on a TWT Capability Announcement (e.g., TWT Capability Announcement 1281) and/or a TWT Requirement (e.g., TWT Requirement Announcement 1283) received from a particular AP (eg, an association request 1291 ) is sent to a specific AP (eg, AP 1250 ), and if determined, an association request frame 1291 is sent to a specific AP 1250 .

In some embodiments, AP 1250 (or TWT Capability Tracker 1274 ) can retain/track/store TWT Capability Announcements received from STAs. Upon receiving an association request (e.g., association request 1291) from a particular STA (e.g., client device 1210), the TWT capability tracker 1274 may determine whether the AP is associated with the particular STA based on the TWT capability announcement received from the particular STA . The AP (or association manager 1276) may then send an association response frame (eg, association response 1292) to the particular AP indicating whether the association request was accepted/approved. If the particular STA is already associated with the AP 1250, the TWT capability tracker 1274 may determine whether the AP maintains association with the particular STA based on TWT capability announcements received from the particular STA. If the TWT capability tracker 1274 determines that the AP is no longer associated with the particular STA, the association manager 1276 may send a disassociation frame to the particular STA.

13 is a block diagram of a system environment 1300 in which a client device 1310 and an AP multilink device (MLD) 1330 communicate data related to rTWT capabilities and requirements, according to an exemplary implementation of the present disclosure. In some specific examples, the UE 1310 may be a non-AP STA or a non-AP MLD STA. The AP MLD 1330 may have a plurality of AP STAs (eg, AP1 1331 , AP2 1332 , AP3 1333 , AP4 1334 ). Here, an MLD is a device that can perform transmission and reception on more than one wireless interface link.

In some embodiments, device 1310 may include TWT capability manager 1320 having a configuration similar to TWT capability manager 1230 of device 1210 . In some embodiments, the TWT capability manager 1320 may include a TWT capability/requirement tracker 1322 and/or an association requester 1324 having functions similar to the TWT capability/requirement tracker 1232 and/or the association requester 1234 of the device 1210, respectively. configuration.

In some specific examples, the AP MLD 1330 may include a TWT requirements manager 1340 having a configuration similar to that of the TWT requirements manager 1270 of the AP 1250, except that the TWT requirements manager 1340 is relative to the plurality of Each of the AP STAs (eg, AP1 1331 , AP2 1332 , AP3 1333 , AP4 1334 ) manages the TWT capabilities/requirements and associations on a per-link basis. In some embodiments, the TWT requirements manager 1340 can include a non-TWT condition monitor 1342, a TWT capability tracker 1344, and/or an association manager 1346, which have the same functions as the non-TWT condition monitor 1272, the TWT capability tracker 1272, and A similar configuration of/or association manager 1274, except that non-TWT condition monitor 1342, TWT capability tracker 1344, and/or association manager 1346 execute with respect to each of a plurality of AP STAs with client device 1310 Communications on a per-link basis (eg, per-link communications 1370, 1380, 1390).

In some embodiments, each AP STA (e.g., AP1 1331, AP2 1332, AP3 1333, AP4 1334) of the AP MLD may receive the following announcement (e.g., TWT Capability Announcement 1350): STA has the capability to support rTWT operation (as the first first capability), and/or (at least) the ability to operate according to the channel access rules used to protect the rTWT SP start time (as a second capability). Each AP STA of the AP MLD may transmit information (eg, TWT Capability Announcement 1361) to declare that the AP STA has the capability to support rTWT operation (as the first capability), and/or (at least) the capability to support RSTP (as the second capability) . Each AP STA of the AP MLD may transmit information (eg, TWT Requirements Announcement 1362 ) to announce various requirements for association with STAs in the wireless network using the rTWT Requirements subfield 1133 of the EHT Operational Information field 1114 .

In some embodiments, a non-AP STA (e.g., client device 1310 or association requester 1324) may perform communication on a per-link basis regarding association/disassociation with AP MLD (e.g., selected link with AP MLD channel communication; each link communication 1370, 1380, 1390). Non-AP STAs may perform communications regarding association/disassociation with AP STAs of AP MLD in a manner similar to how STAs perform communications regarding association/disassociation with non-MLD APs (eg, AP 1250). For example, the UE 1310 may send an association request 1363 to an AP STA (e.g., AP1 1331) of the AP MLD, and AP1 1331 may send an association response 1363 to the UE 1310, and/or AP1 1331 may be similar to the STA Disassociation 1365 is sent to client device 1310 by way of communication with a non-MLD AP (eg, AP 1250 ).

14 is a flowchart showing a procedure 1400 for securing restricted target wake-up time operations for wireless communications, according to an example implementation of the present disclosure. In some embodiments, the process 1400 is executed by a device (eg, computing device 110, HWD 150, non-AP STA, UE device 1210, 1310). In some embodiments, process 1400 is performed by other entities. In some embodiments, procedure 1400 includes more, fewer or different steps than shown in FIG. 14 .

In one approach, the device may determine 1402 a capability code indicating at least one of a plurality of defined capabilities of the device related to rTWT operation in the WLAN (e.g., a binary bit in the restricted TWT support subfield 1064 values 00, 01, 10). In some embodiments, the plurality of defined capabilities may include the capability to perform rTWT operations (eg, the capability indicated by a binary value of 10 in the restricted TWT support subfield 1064). The rTWT operations may include at least one of setting up an rTWT schedule or establishing membership in an rTWT schedule.

In some embodiments, the plurality of defined capabilities may include the ability to complete or terminate a transmission at the start time of an rTWT Service Period (SP) assigned to another device (e.g., via the Restricted TWT Support subfield 1064 The capability supported by RSTP indicated by the binary value 01). The one or more processors can be configured to obtain a transmission opportunity (TXOP) before the start time such that a duration of the TXOP ends before the start time.

In one approach, the device may wirelessly transmit 1404 via the transmitter a first frame (eg, beacon frame, probe request frame, etc.) including the capability code. In some embodiments, the first frame may be a management frame including an information element (IE) (eg, EHT Capability IE 1000, 1050). Capability codes may be included in IEs of management frames (eg, Restricted TWT Support subfield 1064 of EHT Capabilities IE 1050).

15 is a flowchart showing a procedure 1500 for securing restricted target wake-up time operations for wireless communications, according to an example implementation of the present disclosure. In some embodiments, procedure 1500 is performed by an access point (eg, AP 105, soft AP, non-MLD AP 1250, MLD AP 1330). In some embodiments, process 1500 is performed by other entities. In some embodiments, procedure 1500 includes more, fewer or different steps than shown in FIG. 15 .

In one approach, an access point may determine 1502 an indication related to rTWT operation for a device (e.g., computing device 110, HWD 150, non-AP STA, client device 1210, 1310) to associate with an access point in a WLAN. Configuration of preferences or requirements (eg, binary values 01, 10, 11 in rTWT requirements subfield 1133).

In one approach, the access point may receive 1504 a first frame (e.g., association request frames 1291, 1363) from a device indicating a request for association with the access point and including a plural number indicating the device A capability code for at least one of the defined capabilities (eg, binary values 00, 01, 10 in the restricted TWT support subfield 1064).

In some embodiments, the capability code indicates at least one of: (1) a capability not related to rTWT operation (e.g., a binary value of 00 in the restricted TWT support subfield 1064); (2) The first rTWT capability (e.g., binary value 01 in Restricted TWT Support subfield 1064) to complete or terminate transmission by the start time of the rTWT Service Period (SP) assigned to another device; or (3) execute The second rTWT capability for rTWT operation (eg, a binary value of 10 in the Restricted TWT Support subfield 1064). A configuration may indicate one of the following: (1) a preference for a device to support a first rTWT capability (e.g., a binary value of 01 in rTWT-required subfield 1133); (2) a device to support a first rTWT capability (e.g., , a binary value of 11 in the rTWT request subfield 1133); or (3) a request that the device supports a second rTWT capability (eg, a binary value of 10 in the rTWT request subfield 1133).

In one approach, an access point (eg, AP 1250 or TWT capability tracker 1274 ) can determine 1506 whether to accept a request (eg, association request 1291 ) based on the configuration and capability code. In some embodiments, the access point may determine whether the capability code indicates one or more capabilities related to rTWT operation. In response to the capability code not indicating one or more capabilities related to rTWT operation (eg, binary value 00 in restricted TWT support subfield 1064), the access point may decide to deny the request.

In some embodiments, in response to (1) the configuration indicates a preference for the first rTWT capability (e.g., a binary value of 01 in rTWT requirements subfield 1133) and (2) the capability code neither indicates the first rTWT Capabilities (e.g., binary value 10 in Restricted TWT Support subfield 1064) also do not indicate secondary rTWT capabilities (e.g., binary value 01 in Restricted TWT Support subfield 1064), access points (e.g. , non-TWT condition monitor 1272) may determine whether to accept the request according to one or more conditions of the access point, the one or more conditions including at least one of traffic conditions, load conditions or channel conditions.

In some embodiments, in response to (1) a configuration indicating a first capability (e.g., a binary value of 11 in rTWT requirements subfield 1133) and (2) a capability code indicating a first capability (e.g., restricted TWT supports a binary value of 10 in subfield 1064, and one or more processors may determine that the request is accepted and transmit a response frame (eg, associated response 1292) to the device in response to the first frame.

In some embodiments, in response to (1) a configuration indicating a second capability (e.g., a binary value of 10 in rTWT requirements subfield 1133) and (2) a capability code indicating a second capability (e.g., restricted TWT supports a binary value of 01 in subfield 1064), one or more processors may determine acceptance of the request, and transmit a response frame (eg, associated response 1292 ) to the device in response to the first frame.

In some embodiments, the access point can determine whether the device is associated with the access point. In response to determining that the device is associated with the access point, the one or more processors may determine whether the device is to be disassociated from the access point based on the configuration and the capability code. For example, association manager 1276 of AP 1250 may send disassociation 1295 to client device 1210 in response to determining that the device will disassociate from the access point.

Some implementations include electronic components, such as microprocessors, storage devices, and memories that store computer program instructions in computer-readable storage media (eg, non-transitory computer-readable media). Many of the features described in this specification can be implemented as a program specified as a set of program instructions encoded on a computer readable storage medium. These program instructions, when executed by one or more processors, cause the processors to perform the various operations indicated in the program instructions. Examples of program instructions or computer code include machine code such as produced by a compiler, and files including higher-level code executed by a computer, electronic component, or microprocessor using an interpreter. Properly programmed, processor 316 may provide various functionality to computing system 314, including any of the functionality described herein as being performed by a server or client, or other functionality associated with a message management service. By.

It should be appreciated that computing system 314 is exemplary and that variations and modifications are possible. Computer systems used in conjunction with the present disclosure may have other capabilities not specifically described herein. Furthermore, although computing system 314 is described with reference to particular blocks, it should be understood that such blocks are defined for convenience of description and are not intended to imply a particular physical configuration of component parts. For example, different blocks may be located in the same facility, in the same server rack, or on the same motherboard. Additionally, the blocks do not necessarily correspond to physically distinct components. Blocks can be configured to perform various operations, such as by programming a processor or providing appropriate control circuitry, and individual blocks may or may not be reconfigured depending on how the initial configuration was obtained. Implementations of the present disclosure may be implemented in a variety of apparatuses including electronics implemented using any combination of circuitry and software.

Having described some exemplary embodiments, it will be apparent that the foregoing is illustrative and not restrictive, and has 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 achieve the same goal. There is no intent to exclude acts, elements and characteristics discussed in connection with one embodiment from a similar role in other embodiment(s).

The hardware and data processing components for implementing the various programs, operations, exemplary logic, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be general purpose single or multi-chip processors, digital signal processors ( DSP), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or designed to perform the functions described herein to implement or perform any combination thereof. A general-purpose processor may be a microprocessor, or any known processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration. In some embodiments, specific procedures and methods may be performed by circuitry specific to a given function. The memory (e.g., memory, memory unit, storage device, etc.) may include one or Multiple devices (eg, RAM, ROM, flash memory, hard disk storage, etc.). Memory can be or include volatile memory or non-volatile memory, and can include database components, object code components, script components, or any other components used to support the various activities and information structures described in this disclosure Other types of information structures. According to an illustrative embodiment, the memory is communicatively coupled to the processor via the processing circuit and includes a computer program for executing (e.g., by the processing circuit and/or the processor) one or more of the programs described herein code.

The present disclosure covers methods, systems and program products on any machine-readable medium for performing various operations. Embodiments of the disclosure may be implemented using existing computer processors, or by a dedicated computer processor incorporated for this or another purpose in a suitable system, or by a hardwired system. Embodiments within the scope of the present disclosure include a program product comprising a machine-readable medium 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 may include RAM, ROM, EPROM, EEPROM, or other optical storage devices, magnetic disk storage devices, or other magnetic storage devices, or may be used to carry or store instructions or data structures in the form of machine-executable any other medium in the form of desired program code that can be accessed by a general purpose or special purpose computer or other machine having 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 that cause a general purpose computer, special purpose computer, or special purpose processing machine to perform a certain function or group of functions.

The phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of "comprising", "comprising", "having", "comprising", "involving", "characterized by", "characterized by" and variations thereof herein is meant to encompass the items listed thereafter, their equivalents and additional items, and alternative implementations consisting of the items exclusively enumerated thereafter. In one embodiment, the systems and methods described herein consist of one, each combination or owner of more than one of the described elements, acts or components.

Any reference herein to an implementation or element or act of the systems and methods referred to herein in the singular may also encompass implementations that include a plural of such elements, and reference herein to any implementation or element or act in the plural Any reference may also encompass implementations comprising only a single element. References in the singular or plural are not intended to limit the systems or methods disclosed herein, components, acts, or elements thereof to singular or plural configurations. References to any act or element that are based on any information, act or element may include implementations in which the act or element is based at least in part on any information, act or element.

Any implementation disclosed herein may be combined with any other implementation or specific example, and references to "an implementation," "some implementations," "an implementation," or the like are not necessarily mutually exclusive and are intended to indicate a combined implementation. A particular feature, structure, or characteristic described in the schemes can be included in at least one implementation or embodiment. Such terms as used herein do not necessarily all refer to the same implementation. Any implementation may be combined, inclusively or exclusively, with any other implementation in any manner consistent with the aspects and implementations disclosed herein.

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

The systems and methods described herein may be embodied in other specific forms without departing from their characteristics. References to "approximately", "about", "substantially" or other terms of degree include variations of +/- 10% from a given measurement, unit or range unless expressly indicated otherwise. Coupling elements may be electrically, mechanically or physically coupled to each other directly or via intervening elements. The scope of the systems and methods described herein is thus indicated by the accompanying claims rather than the foregoing description, and variations that come within the meaning and range of equivalents of the claims are intended to be encompassed herein.

The term "couple" and variations thereof include engaging two elements with each other, directly or indirectly. Such engagement may be stationary (eg, permanent or fixed) or removable (eg, removable or releasable). Such joining may be achieved by directly coupling the two components to each other; by coupling the two components to each other using individual intervening components and any additional intermediate components coupled to each other; or by using an integral component with one of the two components. An intervening member formed as a single unit couples the two members to each other. If "coupled" or variations thereof are modified by an additional term (e.g., directly coupled), the general definition of "coupled" provided above is modified by the plain meaning of the additional term (e.g., "directly coupled " means joining two components without any individual intervening components), resulting in a narrower definition than the general definition of "coupled" provided above. Such coupling may be mechanical, electrical or fluidic.

References to "or" may be read inclusively, such that any item described using "or" may denote any of a single, more than one, and all of the described items. References to "at least one of 'A' and 'B'" may include only "A", only "B", and both "A" and "B". Such references used in conjunction with "comprises" or other open terms may include additional items.

Modifications to the described elements and acts, such as changes in size, dimension, structure, shape and proportions of various elements, values of parameters, mounting configurations, use of materials, colors, orientations, may not materially depart from what is disclosed herein. Occurs in the context of the teaching and merits of the subject matter. For example, elements shown as integrally formed may be constructed of multiple parts or elements, the position of elements may be reversed or otherwise varied, and the nature or number or positions of discrete elements may be altered or varied. Other substitutions, modifications, changes and omissions may also be made in the design, operating conditions and arrangement of disclosed elements and operations without departing from the scope of the disclosure.

References herein to the location of elements (eg, "top," "bottom," "above," "below") are merely for describing the orientation of various elements in the drawings. The orientation of the various elements may vary according to other illustrative embodiments, and such variations are intended to be encompassed by this disclosure.

100: Artificial Reality System Environment 102A: Communication link 102B: Communication link 105: Access point/AP 110A: Computing device 110B: Computing device 115A: communication interface 115B: communication interface 118A: Processor/Scheduler 118B: Processor/Scheduler 125A: Communication link/wireless link 125B: wireless link/communication link 130A: Content Provider 130B: Content provider 150:Head wearable display/HWD 150A:HWD 150B:HWD 155: sensor 155A: Sensor 155B: Sensor 165: communication interface/wireless interface 165A: communication interface 165B: communication interface 170: Processor 170A: Processor 170B: Processor 175A: Electronic display 175B: Electronic display 185: Communication link/link 205: Front rigid body 210: belt 314:Computing systems 316: Processor/processor unit 318: storage device 320: Network Interface/Wireless Network Interface 322: User input device 324: User output device / output device 400: Timing diagram 402: TWT start time 404: Duration/SP Duration 406: SP Interval 408: TWT start time 500: program 501: first device 502: Operation 510: Operation 514: Operation 516: Operation 518: Operation 520: second device 521: Operation 530: The third device 533: Operation 536: Operation 600: format 601: TWT element 602: Control subfield 604: reserved bit 702: TWT parameter set field 704: TWT parameter set field 800: rTWT parameter subfield 802: bit 0 804: bit 1 806: bit 2 902: reserved bit 910: bTWT information subfield 920: rTWT parameter subfield 1000: Extremely high throughput capability element/EHT capability IE 1010: Element ID 1011: Length 1012: Element ID extension 1013: EHT MAC capability information/EHT MAC capability information subfield/EHT MAC capability information field/ETH MAC capability field 1014: EHT PHY capability information 1021: National Security and Emergency Preparedness Priority Access Support/NSEP Priority Access Support 1022: EHT operation mode control support/EHT OM control support 1023: Triggered transmission opportunity sharing support/TXOP sharing support 1024: rTWT operation support/rTWT operation support sub-field/rTWT operation support field 1025: rTWT start time protection support/RSTP support/RSTP support subfield/RSTP support field 1027: Stream Classification Service Traffic Description Support/SCS Traffic Description Support 1028: reserved 1050:EHT Capability Element/EHT Capability IE/Element ID 1051: Length 1052: Element ID extension 1053: EHT MAC capability information/EHT MAC capability information subfield/EHT MAC capability information field/ETH MAC capability field/capability information field 1054: EHT PHY capability information 1061:NSEP priority access support 1062: EHT OM control support 1063: TXOP shared support 1064: Restricted TWT Support/Restricted TWT Support Subfield/rTWT Support Subfield 1065:SCS service description support 1066: reserved 1100:EHT operation element/EHT operation IE 1110: Element ID 1111: length 1112: Element ID extension 1114: EHT operation information/EHT operation information field 1133: rTWT request/rTWT request subfield/rTWT request field 1200: system environment 1210: Client device/device 1230: TWT capability manager 1232:TWT Capabilities/Requirements Tracker 1234: Association requester 1250: AP/non-MLD AP 1270:TWT request manager 1272: Non-TWT condition monitor 1274:TWT Ability Tracker 1276: Association Manager 1280:TWT Capability Announcement 1281: TWT Capability Declaration 1283: TWT request declaration 1291:Association Request/Association Request Frame 1292: Association Response 1295: Disassociate 1300: system environment 1310: Client device/device 1320: TWT capability manager 1322:TWT Capabilities/Requirements Tracker 1324: Association Requester 1330:AP multilink device/AP MLD/MLD AP 1331:AP1 1332:AP2 1333:AP3 1334:AP4 1340:TWT request manager 1342: Non-TWT condition monitor 1344:TWT Ability Tracker 1346: Association Manager 1350: TWT Capability Announcement 1361: TWT Capability Declaration 1362: TWT request declaration 1363: Association Request/Association Request Frame 1364: Association Response 1365: Disassociate 1370: Communication per link 1380: Communication per link 1390: Communication per link 1400: program 1402: Step 1404: step 1500: program 1502: step 1504: step 1506: step

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

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

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

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

[ FIG. 4 ] is a timing diagram showing wakeup/sleep scheduling of a computing device utilizing TWT according to an exemplary implementation of the present disclosure.

[ FIG. 5 ] is an interaction/flow diagram showing a procedure for signaling rTWT for P2P communication between three devices according to an exemplary implementation of the present disclosure.

[ FIG. 6 ] An exemplary format of a TWT element field according to an exemplary implementation of the present disclosure.

[ FIG. 7 ] An exemplary format of a modified TWT parameter set field according to an exemplary implementation of the present disclosure.

[ FIG. 8 ] An exemplary format of the rTWT parameter subfield according to an exemplary implementation of the present disclosure.

[ FIG. 9 ] An exemplary format of a bTWT information subfield according to an exemplary implementation of the present disclosure.

[FIG. 10A] is an exemplary format for fields of an extremely high throughput (EHT) capability element according to an exemplary implementation of the present disclosure.

[ FIG. 10B ] is another exemplary format for fields of an EHT capability element according to an exemplary implementation of the present disclosure.

[ FIG. 11 ] An exemplary format of fields of an EHT operational element according to an exemplary implementation of the present disclosure.

[ FIG. 12 ] is a block diagram of a system environment in which client devices and APs transmit data related to rTWT capabilities and requirements according to an exemplary embodiment of the present disclosure.

[ FIG. 13 ] is a block diagram of a system environment in which a client device and an AP multilink device (MLD) transmit data related to rTWT capabilities and requirements according to an exemplary embodiment of the present disclosure.

[ FIG. 14 ] is a flow chart showing a procedure for protecting restricted target wake-up time operations for wireless communication according to an exemplary implementation of the present disclosure.

[ FIG. 15 ] is a flow chart showing a procedure for protecting restricted target wake-up time operations for wireless communication according to an exemplary implementation of the present disclosure.

1400: program

1402: Step

1404: step

Claims (20)

A device comprising: One or more processors configured to: determining a capability code indicative of at least one of a plurality of defined capabilities of the device related to restricted target wake-up time (rTWT) operation in a wireless area network (WLAN); and A first frame including the capability code is wirelessly transmitted via a transmitter. Such as the device of claim 1, wherein: The first frame is a management frame including an information element (IE), and the capability code is included in the information element of the management frame. Such as the device of claim 1, wherein: the plurality of defined capabilities includes the ability to perform one of the restricted target wake-up time operations, and The restricted target wake-up time operations include at least one of setting a restricted target wake-up time schedule or establishing membership in a restricted target wake-up time schedule. The device of claim 1, wherein the plurality of defined capabilities includes a capability to complete or terminate a transmission at a start time of a limited target wake-up time service period (SP) assigned to another device. The device of claim 4, wherein the one or more processors are configured to: A transmission opportunity (TXOP) is obtained before the start time such that a duration of the TXOP ends before the start time. An access point comprising: One or more processors configured to: determining a configuration indicating a preference or requirement related to restricted target wake-up time (rTWT) operation for a device associated with the access point in a wireless area network (WLAN); receiving a first frame from the device indicating a request for association with the access point and including a capability code indicating at least one of a plurality of defined capabilities of the device; and Determine whether to accept the request according to the configuration and the capability code. The access point of claim 6, wherein the one or more processors are configured to: determining whether the capability code indicates one or more capabilities associated with the restricted target wake-up time operations; and The request is determined to be denied in response to the capability code not indicating the one or more capabilities related to the restricted target wake-up time operations. Such as the access point of claim 6, wherein: The capability code indicates at least one of: (1) a capability not associated with the restricted TWAT operation; (2) a restricted TWAT service period (SP) assigned to another device; ) a first restricted target wake-up time capability to start time to complete or terminate a transmission; or (3) a second restricted target wake-up time capability to perform such restricted target wake-up time operations; and The configuration indicates one of the following: (1) a preference that the device supports the first restricted target wake-up time capability; (2) a request that the device supports the first restricted target wake-up time capability; or ( 3) The device supports one of the requirements of the second restricted target wake-up time capability. The access point of claim 8, wherein in response to (1) the configuration indicates the preference for the first restricted target wake-up time capability and (2) the capability code neither indicates the first restricted target wake-up The time capability also does not indicate the second restricted target wake-up time capability, the one or more processors configured to: Whether to accept the request is determined according to one or more conditions of the access point, the one or more conditions including at least one of a traffic condition, a load condition or a channel condition. The access point of claim 8, wherein in response to (1) the request that the configuration indicates the first capability and (2) the capability code indicates the first capability, the one or more processors are configured to : decides to accept the request, and Transmitting a response frame in response to the first frame to the device. The access point of claim 8, wherein in response to (1) the request that the configuration indicates the second capability and (2) the capability code indicates the second capability, the one or more processors are configured to : decides to accept the request, and Transmitting a response frame in response to the first frame to the device. As the access point of claim 6, it further includes: a plurality of network interfaces corresponding to a plurality of wireless links, wherein the one or more processors are configured to: determining the configuration for a first link of the plurality of wireless links; and Another configuration for a second link of the plurality of wireless links is determined. The access point of claim 6, wherein the one or more processors are configured to: determining whether the device is associated with the access point; and In response to determining that the device is associated with the access point, it is determined whether the device is to be disassociated from the access point based on the configuration and the capability code. A method comprising: Determining, by one or more processors of an access point, that the indication relates to one of the restricted target wake-up time (rTWT) operations for a device associated with the access point in a wireless area network (WLAN) a configuration of preferences or a requirement; receiving a first frame from the device indicating a request for association with the access point and including a capability code indicating at least one of a plurality of defined capabilities of the device; and Determine whether to accept the request according to the configuration and the capability code. The method of claim 14, further comprising: determining whether the capability code indicates one or more capabilities associated with the restricted target wake-up time operations; and The request is determined to be denied in response to the capability code not indicating the one or more capabilities related to the restricted target wake-up time operations. The method of claim 14, wherein: The capability code indicates at least one of: (1) a capability not associated with the restricted TWAT operation; (2) a restricted TWAT service period (SP) assigned to another device; ) a first restricted target wake-up time capability to start time to complete or terminate a transmission; or (3) a second restricted target wake-up time capability to perform such restricted target wake-up time operations; and The configuration indicates one of the following: (1) a preference that the device supports the first restricted target wake-up time capability; (2) a request that the device supports the first restricted target wake-up time capability; or ( 3) The device supports one of the requirements of the second restricted target wake-up time capability. The method according to claim 16, further comprising: Responsive to (1) the configuration indicating the preference for the first restricted target wake-up time capability and (2) the capability code indicating neither the first restricted target wake-up time capability nor the second restricted Target Wake Time Capabilities: Whether to accept the request is determined according to one or more conditions of the access point, the one or more conditions including at least one of a traffic condition, a load condition or a channel condition. The method according to claim 16, further comprising: In response to (1) the request that the configuration indicates the first capability and (2) the capability code indicates the first capability: decides to accept the request, and Transmitting a response frame in response to the first frame to the device. The method according to claim 16, further comprising: In response to (1) the request that the configuration indicates the second capability and (2) the capability code indicates the second capability: decides to accept the request, and Transmitting a response frame in response to the first frame to the device. The method of claim 14, further comprising: determining whether the device is associated with the access point; and In response to determining that the device is associated with the access point, it is determined whether the device is to be disassociated from the access point based on the configuration and the capability code.

Images