System and method for traffic coordinated access point assisted transmission opportunity (TXOP) sharing

Abstract

Systems and methods are disclosed herein that involve transmitting, by a first wireless communication device, a flow classification service (SCS) request frame to a second wireless communication device, the SCS request frame including information of traffic to be transmitted between the first wireless communication device and a third wireless communication device. The first wireless communication device, the second wireless communication device, and the third wireless communication device share a wireless communication channel. The method may include, in response to receiving an indication of sharing a transmission opportunity (TXOP) of a second wireless communication device with the first wireless communication device, communicating, by the first wireless communication device, with the second wireless communication device on a first link during a first portion of the TXOP, and communicating with a third wireless communication device over a second link during a second portion of the TXOP.

Description

Technical Field

[0001] The present disclosure generally relates to coordinating traffic between devices communicating on the same wireless channel, including but not limited to reducing interference in communications for artificial reality and other applications. Background Art

[0002] Artificial realities such as virtual reality (VR), augmented reality (AR), or mixed reality (MR) provide users with an immersive experience. In one example, a user wearing a head wearable display (HWD) can turn the user's head, and an image of a virtual object corresponding to the position of the HWD 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 (e.g., VR space, AR space, or MR space). The image of the virtual object can be generated by a computing device communicatively coupled to the HWD. In some embodiments, the computing device can access a network.

[0003] In one embodiment, the image of the virtual object is generated by a console that is communicatively coupled to the HWD. In one example, the HWD includes various sensors that detect the position and / or orientation of the HWD and transmits the detected position and / or orientation of the HWD to the console via a wired connection or a wireless connection. The console can determine the user's field of view of the artificial reality space based on the detected position and / or orientation of the HWD and generate image data indicating an image of the artificial reality space corresponding to the user's field of view. The console can send the image data to the HWD, and the HWD can present the user with an image of the artificial reality space corresponding to the user's field of view. In one aspect, the process of detecting the position of the HWD and the gaze direction of the user wearing the HWD and rendering the image to the user should be performed within one frame time (e.g., less than 11ms). Any delay caused by interference between the movement of the user wearing the HWD and the image displayed corresponding to the user's movement may cause jitter, which may cause motion sickness and may reduce the user experience. Summary of the Invention

[0004] Disclosed herein are systems and methods for coordinating traffic between multiple devices communicating on the same wireless channel. Some embodiments relate to a method in which a first wireless communication device (e.g., a computing device, a soft access point) sends a stream classification service (SCS) request frame to a second wireless communication device (e.g., an access point), the SCS request frame including information about traffic to be transmitted between the first wireless communication device and a third wireless communication device (e.g., a head wearable device, smart glasses). The first wireless communication device, the second wireless communication device, and the third wireless communication device may share a wireless communication channel. The method may include, in response to receiving an indication of sharing a transmission opportunity (TXOP) of the second wireless communication device with the first wireless communication device, communicating with the second wireless communication device on a first link during a first portion of the TXOP, and communicating with the third wireless communication device on a second link (e.g., on the same wireless communication channel as the first link) during a second portion of the TXOP.

[0005] The method may include: determining, by the first wireless communication device, a target wake time (TWT) schedule for communicating with the second wireless communication device. The method may include: determining, by the first wireless communication device, a wake-up schedule for communicating with the third wireless communication device. The first wireless communication device may determine the TWT schedule based on the wake-up schedule (e.g., align with or adapt to the wake-up schedule). The indication may include a multi-user request to send a TXOP sharing (MU-RTS TXS) frame (e.g., mode 2). The method may also include: receiving, by the first wireless communication device, a message from the second wireless communication device, the message including an enhanced distributed channel access (EDCA) timer value for the first wireless communication device; and / or the first wireless communication device avoiding contention for a wireless communication channel based on the EDCA timer value. The method may include: triggering, by the first wireless communication device, a third wireless communication device via a message, the message being transmitted to the third wireless communication device during the TXOP. The message may include one of the following: a MU-RTS TXS frame (e.g., Mode 1); a trigger-based physical layer protocol data unit (PPDU); a single-user PPDU with a set of reverse direction grant (RDG) bits; or an orthogonal frequency division multiple access (OFDMA) PPDU embedded with a basic trigger. The first part of the TXOP may occur at a time before the second part of the TXOP. The second part of the TXOP may occur at a time before the first part of the TXOP.

[0006] Other embodiments relate to a wireless communication device, comprising: a transceiver; and at least one processor configured to: send a flow classification service (SCS) request frame to a second wireless communication device via the transceiver, the SCS request frame including information of a service to be transmitted between the wireless communication device and a third wireless communication device, wherein the wireless communication device, the second wireless communication device, and the third wireless communication device can share a wireless communication channel; and / or in response to receiving an indication to share a transmission opportunity (TXOP) of the second wireless communication device with the wireless communication device, communicate with the second wireless communication device on a first link during a first part of the TXOP, and / or communicate with the third wireless communication device on a second link during a second part of the TXOP, via the transceiver.

[0007] The at least one processor may be configured to determine a target wake-up time (TWT) schedule with a second wireless communication device. The at least one processor may be configured to determine a wake-up schedule with a third wireless communication device. The at least one processor may be configured to determine the TWT schedule based on the wake-up schedule. The indication may include a multi-user request to send TXOP sharing (MU-RTS TXS) frame (e.g., Mode 2). The at least one processor may be configured to receive a message from the second wireless communication device via a transceiver, the message including an enhanced distributed channel access (EDCA) timer value for the wireless communication device; and / or contention for a wireless communication channel may be avoided based on the EDCA timer value. The at least one processor may be configured to trigger the third wireless communication device via a message sent via the transceiver, the message being transmitted to the third wireless communication device during the TXOP. The message may include one of: a MU-RTS TXS frame (e.g., Mode 1); a triggered physical layer protocol data unit (PPDU); a single-user PPDU with a set of reverse direction grant (RDG) bits; or an orthogonal frequency division multiple access (OFDMA) PPDU embedded with a basic trigger. The first portion of the TXOP may occur at a time before the second portion of the TXOP, or the second portion of the TXOP may occur at a time before the first portion of the TXOP.

[0008] Other embodiments relate to a non-transitory processor-readable medium comprising a plurality of processor-readable instructions, such that when the plurality of processor-readable instructions are executed by one or more processors of a wireless communication device, the one or more processors are caused to: send a flow classification service (SCS) request frame to a second wireless communication device via a transceiver, the SCS request frame including information of a service to be transmitted between the wireless communication device and a third wireless communication device, wherein the wireless communication device, the second wireless communication device, and the third wireless communication device can share a wireless communication channel; and in response to receiving an indication to share a transmission opportunity (TXOP) of the second wireless communication device with the wireless communication device, communicate with the second wireless communication device on a first link during a first part of the TXOP, and communicate with the third wireless communication device on a second link during a second part of the TXOP, via the transceiver. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings are not intended to be drawn to scale. Like reference numerals and names in the various drawings refer to like elements. For clarity, not every component may be labeled in every drawing.

[0010] Figure 1 is a schematic diagram of a system environment including an artificial reality system according to an example embodiment of the present disclosure.

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

[0012] Figure 3 is a block diagram of a computing environment according to an example embodiment of the present disclosure.

[0013] Figure 4 is a timing diagram 400 showing a wakeup / sleep schedule for a computing device utilizing TWT according to an example embodiment of the present disclosure.

[0014] Figure 5 An interaction diagram / flow chart showing a process for coordinating traffic for multiple devices sharing the same wireless communication channel according to an example embodiment of the present disclosure is shown.

[0015] Figure 6 An interaction diagram illustrating a process of coordinating intralink communications and interlink communications within one TXOP through TXOP sharing according to an example embodiment of the present disclosure is shown.

[0016] Figure 7 Another interaction diagram illustrating a process 700 of coordinating intra-link communications and inter-link communications within a TXOP through TXOP sharing is shown according to an example embodiment of the present disclosure.

[0017] Figures 8 to 11 Different ways in which computing device 110 and HWD 150 may coordinate traffic during inter-link communications according to example embodiments of the present disclosure are illustrated. DETAILED DESCRIPTION

[0018] Before turning to the drawings showing certain embodiments in detail, it should be understood that the present disclosure is not limited to the details or methods set forth in the specification or shown in the drawings. It should also be understood that the terminology used herein is for descriptive purposes only and should not be regarded as limiting.

[0019] The disclosure herein relates to systems and methods for coordinating traffic between devices communicating on the same wireless channel (e.g., single channel concurrency (SCC)). Coordinating traffic can result in predictable data transmission, allowing devices to enter low power mode / idle mode / sleep mode in a coordinated, more energy-efficient manner. Coordinating traffic between devices and improving the predictability of traffic can improve the performance of low-power (or battery-powered) devices. Specifically, when devices are executing latency-sensitive applications, it is necessary to coordinate traffic between these devices, such as remote rendering of artificial reality spaces (e.g., AR spaces, VR spaces, or MR spaces) or other wireless communication applications.

[0020] Figure 1 is a block diagram of an example artificial reality system environment 100. In some embodiments, the artificial reality system environment 100 includes an access point (AP) 105, one or more HWDs 150 (e.g., HWDs 150A, 150B), and one or more computing devices 110 (computing devices 110A, 110B) that provide artificial reality data to the one or more HWDs 150. The access point 105 may be a router or any network device that allows the one or more computing devices 110 and / or the one or more HWDs 150 to access a network (e.g., the Internet). The access point 105 may be replaced by any communication device (cellular base station). The computing device 110 may be a computing device or mobile device that can obtain content from the access point 105 and can provide artificial reality image data to the corresponding HWD 150. Each HWD 150 can present an image of artificial reality to the user based on the image data. In some embodiments, the artificial reality system environment 100 includes more than one HWD 150. Figure 1 More, fewer, or more of the components shown may be included. Figure 1102B (hereinafter referred to as wireless link 102) and the access point 105. In some embodiments, computing devices 110A and 110B communicate with access point 105 via wireless links 102A and 102B, respectively (referred to herein as wireless link 102). Communication between AP 105 and computing device 110 can be considered "interlink communication" or "infrastructure traffic," where AP 105 and computing device 110 communicate using infrastructure link / AP link 102. In some embodiments, computing device 110A communicates with HWD 150A and HWD 150B via wireless links 125A and 125B, respectively (referred to herein as wireless link 125). Communication between computing device 110 and HWD 150 can be considered "interlink communication" (e.g., peer-to-peer link) or "non-infrastructure traffic." In some embodiments, the functionality of one or more components of artificial reality system environment 100 can be distributed among the components in a manner different from that described herein. For example, some functions of computing device 110 can be performed by HWD 150. Additionally or alternatively, some functions of HWD 150 may be performed by computing device 110 .

[0021] In some embodiments, HWD 150 is an electronic component that can be worn by a user and can present or provide an artificial reality experience to the user. HWD 150 may be referred to as, include, or be part of: a head-mounted display (HMD), a head mounted device (HMD), a head wearable device (HWD), a head worn display (HWD), or a headworn device (HWD). HWD 150 can render one or more images, video, audio, or some combination thereof to provide an artificial reality experience to the user. In some embodiments, audio is presented via an external device (e.g., a speaker and / or headphones) that receives audio information from HWD 150, computing device 110, or both and presents audio based on the audio information. In some embodiments, HWD 150 includes a sensor 155, a wireless interface 165, a processor 170, and a display 175. These components may operate together to detect the position of the HWD 150 and the gaze direction of the user wearing the HWD 150 and render an image of the field of view within the artificial reality that corresponds to the detected position and / or orientation of the HWD 150. In other embodiments, the HWD 150 includes more than Figure 1 More, fewer, or more of the components shown may be included. Figure 1 Components that are different from the components shown in FIG.

[0022] In some embodiments, sensor 155 includes electronic components, or a combination of electronic components and software components, that detect the position and orientation of HWD 150. Examples of sensor 155 may include: one or more imaging sensors; one or more accelerometers; one or more gyroscopes; one or more magnetometers; or another suitable type of sensor that detects motion and / or position. For example, one or more accelerometers may measure translational motion (e.g., forward / backward, up / down, left / right), and one or more gyroscopes may measure rotational motion (e.g., pitch, yaw, roll). In some embodiments, sensor 155 detects translational motion and rotational motion and determines the orientation and position of HWD 150. In one aspect, sensor 155 may detect translational motion and rotational motion relative to a previous orientation and position of HWD 150 and determine a new orientation and / or position of HWD 150 by accumulating or integrating the detected translational motion and / or rotational motion. For example, assuming that HWD 150 is facing a direction 25 degrees from a reference direction, sensor 155 may determine that HWD 150 is now facing or facing a direction 45 degrees from the reference direction in response to detecting that HWD 150 has rotated 20 degrees. For another example, assuming that HWD 150 is located 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 located at the vector product of two feet in the first direction and three feet in the second direction.

[0023] In some embodiments, wireless interface 165 includes electronic components, or a combination of electronic components and software components, for communicating with computing device 110. In some embodiments, wireless interface 165 includes or is embodied as a transceiver for sending and receiving data over a wireless medium. Wireless interface 165 can communicate with wireless interface 115 of a corresponding computing device 110 via wireless link 125 (e.g., intra-link communication). Wireless interface 165 can also communicate with access point 105 via a wireless link (e.g., inter-link communication). Examples of wireless link 125 include a near-field communication link, Wi-Fi Direct, Bluetooth, or any wireless communication link. Wireless interface 165 can send data indicating the determined position and / or orientation of HWD 150, the determined gaze direction of the user, and / or hand tracking measurements to computing device 110 via wireless link 125. In addition, wireless interface 165 can receive image data from computing device 110 via wireless link 125, the image data indicating or corresponding to an image to be rendered.

[0024] In some embodiments, the processor 170 includes, for example, electronic components, or a combination of electronic components and software components, that generate one or more images for display based on changes in the field of view of the artificial reality space. In some embodiments, the processor 170 is implemented as one or more graphics processing units (GPUs), one or more central processing units (CPUs), or a combination thereof that can execute instructions to perform the various functions described herein. The processor 170 can receive image data describing an image of artificial reality to be rendered through the wireless interface 165 and render the image through the display 175. In some embodiments, the image data from the computing device 110 can be encoded, and the processor 170 can decode the image data to render the image. In some embodiments, the processor 170 receives object information and depth information from the computing device 110 through the wireless interface 165, the object information indicating a virtual object in the artificial reality space and the depth information indicating the depth of the virtual object (or the distance from the HWD 150). In one aspect, processor 170 may perform shading, reprojection, and / or blending based on the image of the artificial reality from computing device 110, object information, depth information, and / or updated sensor measurements from sensor 155 to update the image of the artificial reality to correspond to the updated position and / or orientation of HWD 150.

[0025] In some embodiments, display 175 is an electronic component that displays images. Display 175 may be, for example, a liquid crystal display or an organic light-emitting diode display. Display 175 may be a transparent display that allows the user to see through it. In some embodiments, when the user wears HWD 150, display 175 is located near the user's eyes (e.g., less than 3 inches). In one aspect, display 175 emits or projects light toward the user's eyes based on the images generated by processor 170. HWD 150 may include lenses that allow the user to see display 175 at close range.

[0026] In some embodiments, processor 170 performs compensation to compensate for any distortion or aberration. In one aspect, the lens introduces optical aberrations (e.g., chromatic aberration), pincushion distortion, barrel distortion, etc. Processor 170 can determine compensation (e.g., pre-distortion) to be applied to the image to be rendered to compensate for the distortion caused by the lens, and apply the determined compensation to the image from processor 170. Processor 170 can provide the pre-distorted image to display 175.

[0027] 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 can be embodied as a mobile device (e.g., a smartphone, a tablet personal computer (PC), a laptop, etc.). Computing device 110 can operate as a soft access point. In one aspect, computing device 110 includes a wireless interface 115 and a processor 118. These components can operate together to determine a field of view of an artificial reality (e.g., the user's field of view) corresponding to the position of HWD 150 and the gaze direction of the user of HWD 150, and can generate image data indicating an image of the artificial reality corresponding to the determined field of view. Computing device 110 can also communicate with access point 105 and can obtain AR content / VR content from access point 105, for example, via wireless link 102 (e.g., an interconnect link). Computing device 110 can receive sensor measurements indicating the position and gaze direction of the user of HWD 150 and provide image data to HWD 150, for example, via wireless link 125 (e.g., an internal link communication) for rendering artificial reality. In other embodiments, computing device 110 includes Figure 1 More, fewer, or more of the components shown may be included. Figure 1 Components that are different from the components shown in FIG.

[0028] In some embodiments, the wireless interface 115 is an electronic component, or a combination of electronic and software components, that communicates with the HWD 150, the access point 105, another computing device 110, or any combination thereof. In some embodiments, the wireless interface 115 includes or is embodied as a transceiver for sending and receiving data over a wireless medium. The wireless interface 115 can be a counterpart of the wireless interface 165 to communicate with the HWD 150 via a wireless link 125 (e.g., an intra-link communication). The wireless interface 115 can also include components that communicate with the access point 105 via a wireless link 102 (e.g., an inter-link communication). Examples of wireless links 102 include cellular communication links, near-field communication links, Wi-Fi, Bluetooth, 60 GHz wireless links, or any wireless communication links. The wireless interface 115 can also include components that communicate with different computing devices 110 via wireless links 185. Examples of wireless links 185 include near-field communication links, Wi-Fi Direct, Bluetooth, or any wireless communication links. The wireless interface 115 may obtain AR / VR content or other content from the access point 105 via the wireless link 102 (e.g., interlink communication). The wireless interface 115 may receive data indicating the determined position and / or orientation of the HWD 150, the determined gaze direction of the user, and / or hand tracking measurements from the HWD 150 via the wireless link 125 (e.g., interlink communication). In addition, the wireless interface 115 may send image data describing the image to be rendered to the HWD 150 via the wireless link 125 (e.g., interlink communication). The wireless interface 115 may receive or send information indicating the wireless link 125 (e.g., channel, timing) between the computing device 110 and the HWD 150 via the wireless link 185. The computing device 110 may coordinate or schedule operations based on the information indicating the wireless link 125 to avoid interference or conflicts.

[0029] Processor 118 may include or correspond to a component that generates content to be rendered based on the position and / or orientation of HWD 150. In some embodiments, processor 118 includes or is embodied as one or more central processing units, one or more graphics processing units, one or more image processors, or one or more processors for generating images of an artificial reality. In some embodiments, processor 118 may combine the gaze direction of the user of HWD 150 and user interactions within the artificial reality to generate the content to be rendered. In one aspect, processor 118 determines the field of view of the artificial reality based on the position and / or orientation of HWD 150. For example, processor 118 maps the position of HWD 150 in physical space to a position within the artificial reality space, and determines the field of view of the artificial reality space from the mapped position in the artificial reality space along a direction corresponding to the mapped orientation. Processor 118 may generate image data describing an image of the determined field of view of the artificial reality space, and may transmit the image data to HWD 150 via wireless interface 115. Processor 118 may encode the image data describing the image and transmit the encoded data to HWD 150. In some embodiments, processor 118 generates image data periodically (eg, every 11 ms or 16 ms) and provides the image data to HWD 150 .

[0030] In some embodiments, the processor 118 may configure or cause the wireless interface 115 to toggle, transition, cycle, or switch between a sleep mode and an awake mode. In the awake mode, the processor 118 may enable the wireless interface 115 so that the wireless interface 115 can exchange data. In the sleep mode, the processor 118 may disable (e.g., to achieve low-power or reduced operation) the wireless interface 115 so that the wireless interface 115 may not consume power or may reduce power consumption. The processor 118 may schedule the wireless interface 115 to periodically switch between the sleep mode and the awake mode during each frame time (e.g., 11 ms or 16 ms). For example, the wireless interface 115 may operate in the awake mode for 2 ms of the frame time, and the wireless interface 115 may operate in the sleep mode for the remainder of the frame time (e.g., 9 ms). By disabling the wireless interface 115 in the sleep mode, the power consumption of the computing device 110 and the HWD 150 may be reduced or minimized.

[0031] In some embodiments, processor 118 may configure or cause wireless interface 115 to resume communication based on stored information indicating communication between computing device 110 and HWD 150. While in wake mode, processor 118 may generate and store information (e.g., channel, timing) regarding communication between computing device 110 and HWD 150. Processor 118 may schedule wireless interface 115 to enter a subsequent wake mode based on the timing of previous communications indicated by the stored information. For example, wireless interface 115 may predict / determine when to enter a subsequent wake mode based on the timing of previous wake modes and may schedule entry into the subsequent wake mode at the predicted time. After generating and storing the information and scheduling the subsequent wake mode, processor 118 may configure or cause wireless interface 115 to enter a sleep mode. Upon entering the wake mode, processor 118 may cause or configure wireless interface 115 to resume communication via the channel or frequency band of the previous communication indicated by the stored information. Thus, wireless interface 115 entering the wake mode from sleep mode can resume communication while bypassing scanning procedures for searching for available channels and / or performing handshakes or authentication. Bypassing the scanning procedure allows the wireless interface 115 to operate in the sleep mode for an extended period of time, so that the computing device 110 and the HWD 150 can reduce power consumption.

[0032] In some embodiments, computing devices 110A and 110B may coordinate operations to reduce conflicts or interference. In one approach, computing device 110A may periodically send beacon frames 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 or interference with communications between computing device 110A and HWD 150A. For example, when computing device 110A and HWD 150A are operating in sleep mode, computing device 110B may schedule computing device 110B and HWD 150B to enter wake mode. For example, when computing device 110A and HWD 150A are operating in an awake mode, computing device 110B may schedule computing device 110B and HWD 150B to enter a sleep mode. Thus, multiple computing devices 110 and HWD 150 in close proximity (e.g., within 20 feet (ft)) may coexist and operate with reduced interference.

[0033] In some embodiments, a coordinator 180 (e.g., coordinator 180A of computing device 110A and / or coordinator 180B of computing device 110B) may coordinate traffic transmitted over wireless link 125 (inter-link communication) and wireless link 102 (inter-link communication). To coordinate traffic for three devices (e.g., computing device 110, HWD 150, and AP 105), coordinator 180 may coordinate (request, transmit) traffic information to be transmitted over wireless link 125 between computing device 110 and HWD 150 using wireless link 102 with AP 105. The traffic information to be transmitted may include delay / latency / priority information, throughput information, tolerable packet loss, size of traffic to be transmitted, duration of traffic to be transmitted, orientation / motion data such as inertial measurement unit (IMU) data, and the like.

[0034] The AP 105 may use the information received from the coordinator 180 to determine a duration to allocate / allocate / assign for a transmission opportunity (TXOP). A TXOP may be a duration during which a device may use the medium for data transmission. For example, the AP 105 may receive information about traffic to be transmitted over the wireless link 125 between the computing device 110 and the HWD 150, and the AP 105 may know / plan / estimate the traffic to be transmitted between the computing device 110 and the AP 105. Thus, the AP 105 may determine the total time to allocate for the transmission opportunity based on the traffic information to be transmitted over the wireless link 125 between the computing device 110 and the HWD 150 and the traffic to be transmitted between the computing device 110 and the AP 105.

[0035] Coordinator 180 may also coordinate / transmit traffic in response to receiving an indication from AP 105. AP 105 may contend for the medium (e.g., a wireless channel shared to create / support wireless link 102, wireless link 185, and / or wireless link 125). AP 105 may transmit during a TXOP and may then share any remaining time of the TXOP with computing device 110 (e.g., coordinator 180). As described herein, the remaining time of the TXOP (e.g., the duration of the shared TXOP) is the time requested / coordinated by computing device 110. For example, computing device 110 may have indicated traffic information to be transmitted to AP 105, such that the remaining time of the TXOP is the time for internal link data transmission (e.g., between computing device 110 and HWD 150).

[0036] In an example embodiment, coordinator 180 may transmit uplink traffic to AP 105 using wireless link 102 (e.g., interlink communication) and / or transmit downlink traffic to HWD 150 using wireless link 125 (e.g., interlink communication) in response to receiving a message from AP 105 that the AP will share (or is currently sharing) a portion of a TXOP. In some embodiments, the traffic transmitted downlink to HWD 150 may be data / content. In some embodiments, the traffic to be transmitted downlink to HWD 150 may be control information (or information other than data / content). The control information may be used to request data / content from HWD 150.

[0037] The coordinator 180 may coordinate (e.g., align, arrange, schedule) a sleep schedule (or wake-up schedule). The coordinator 180 may coordinate one or more wake-up schedules with the HWD 150 and / or the AP 105. In an example embodiment, the coordinator 180 may coordinate the wake-up schedule with the HWD 150. The coordinator 180 may use the wake-up schedule associated with the HWD 150 to determine the wake-up schedule associated with the AP 105. For example, based on traffic information to be transmitted to the AP 105 and / or the HWD 150 (e.g., the size of the traffic to be transmitted, the duration of the traffic to be transmitted), the coordinator 180 (or the computing device 110) may wake up for a duration prior to the wake-up schedule associated with the HWD 150. In a non-limiting example, if the coordinator 180 (or computing device 110) knows / determines that 10 ms of traffic is to be transmitted to the AP 105 and 6 ms of traffic is to be transmitted to the HWD 150A, the coordinator 180 (or computing device 110) may wake up 10 ms before the HWD 150A so that the coordinator (or computing device 110) can transmit the 10 ms of traffic with the AP 105 before the HWD 150A wakes up. After the computing device 110 transmits the 10 ms of traffic with the AP 105, the HWD 150A may wake up. As a result, the computing device 110 can transmit the 6 ms of traffic with the HWD 150A.

[0038] The coordinator 180 may coordinate one or more parameters associated with the wireless channel. For example, the coordinator 180 may extract / parse / store one or more enhanced distributed channel access (EDCA) parameters. The coordinator 180 may coordinate with the computing device 110 to act / operate based on one or more parameters associated with the wireless channel. For example, the coordinator 180 may cause the computing device 110 to avoid contention for the wireless communication channel based on an EDCA timer value (e.g., a multi-user enhanced distributed access (MU-EDA) timer value configured / set by the AP for the computing device 110 and sent by the AP to the computing device 110). The computing device 110 (e.g., the coordinator 180) may configure / set the EDCA timer value for the HWD 150A so that the HWD 150A avoids contention for the wireless communication channel.

[0039] Figure 2 is a schematic diagram of HWD 150 according to an example embodiment. In some embodiments, HWD 150 includes front rigid body 205, left side 240E, front side 240A, right side 240D, bottom side 240C, top side 240B, and strap 210. Front rigid body 205 includes electronic display 175 ( Figure 2 Not shown), lens 180 ( Figure 2 (not shown), sensor 155, eye tracker 160A, 160B (not shown), communication interface (wireless interface) 165 and processor (image renderer) 170. Figure 2 In the embodiment shown, the communication interface 165, image renderer 170, and sensor 155 are located within the front rigid body 205 and may not be visible to the user. In other embodiments, the HWD 150 has Figure 2 For example, the communication interface 165, image renderer 170, eye trackers 160A, 160B, and / or sensor 155 may be located in a different configuration than that shown in FIG. Figure 2 The positions shown in the figure are different.

[0040] Various operations described herein can be implemented on computer systems. Figure 3 A block diagram of a representative computing system 314 that may be used to implement the present disclosure is shown in accordance with an example embodiment. In some embodiments, Figure 1The console 110, HWD 150, or both are implemented by a computing system 314. The computing system 314 can be implemented as, for example, a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smartwatch, glasses, head wearable display), desktop computer, laptop computer, etc., or the computing system 314 can be implemented using distributed computing devices. The computing system 314 can be implemented to provide VR, AR, MR experiences. In some embodiments, the computing system 314 can include traditional computer components, such as a processor 316, a storage device 318, a network interface 320, a user input device 322, and a user output device 324.

[0041] The network interface 320 may provide a connection to a wide area network (e.g., the Internet) to which a wide area network (WAN) interface of the remote server system is also connected. The network interface 320 may include a wired interface (e.g., Ethernet) and / or a wireless interface implementing various radio frequency (RF) data communication standards, such as Wi-Fi, Bluetooth, or cellular data network standards (e.g., 3rd generation (3G), 4th generation (4G), 5th generation (5G), 60 GHz, long term evolution (LTE), etc.).

[0042] User input device 322 may include any device (or devices) via which a user may provide a signal to computing system 314, which computing system 314 may interpret as indicating a particular user's request for information. User input device 322 may include any or all of the following: a keyboard; a touchpad; a touch screen; a mouse; or other pointing device; a scroll wheel; a click wheel; a dial; a button; a switch; a keypad; a microphone; a sensor (e.g., a motion sensor, an eye-tracking sensor, etc.); or the like.

[0043] User output device 324 may include any device via which computing system 314 can provide information to a user. For example, user output device 324 may include a display for displaying a display image generated by or transmitted to computing system 314. The display may combine various image generation technologies (e.g., liquid crystal display (LCD), light-emitting diodes (LED) including organic light emitting diodes (OLED), projection systems, or cathode ray tubes (CRT), etc.) with supporting electronic devices (e.g., digital-to-analog or analog-to-digital converters or signal processors, etc.). Devices that serve as both input devices and output devices, such as touch screens, may be used. Output device 324 may be provided in addition to or in lieu of a display. Examples include indicator lights, speakers, tactile "display" devices, printers, etc.

[0044] Some embodiments include electronic components, such as microprocessors, storage devices, and memories storing computer program instructions in computer-readable storage media (e.g., non-transitory computer-readable media). Many of the features described in this specification can be implemented as processes designated as a set of program instructions encoded on a computer-readable storage medium. When these program instructions are executed by one or more processors, they cause the processor to perform the various operations indicated in these program instructions. Examples of program instructions or computer codes include machine codes such as those produced by a compiler, and files comprising high-level code executed by a computer, electronic component, or microprocessor using an interpreter. Through appropriate programming, processor 316 can provide various functions for computing system 314, including any functions described herein performed by a server or client, or other functions associated with message management services.

[0045] It will be appreciated that computing system 314 is illustrative and that variations and modifications are possible. The computer systems used in conjunction with the present disclosure may have other capabilities not specifically described herein. Furthermore, while computing system 314 has been described with reference to particular blocks, it will be understood that these blocks are defined for ease of description and are not intended to imply a particular physical arrangement of the components. For example, different blocks may be located in the same facility, in the same server rack, or on the same motherboard. Furthermore, these blocks need not correspond to physically distinct components. Each block may be configured to perform various operations, for example, by programming a processor or providing appropriate control circuitry, and each block may or may not be reconfigurable, depending on how the initial configuration is obtained. Embodiments of the present disclosure may be implemented in a variety of devices, including electronic devices implemented using any combination of circuitry and software.

[0046] A device may be limited by its battery (e.g., the capacity of the battery). For example, a wearable device may have a small battery, resulting in limited performance (e.g., limited charge life, frequent charging of the device). Extending battery life, power efficiency, and / or minimizing / reducing power consumption enhances device performance and / or user experience. To improve the performance of these devices, the devices may be configured to enter one or more power saving modes / one or more reduced power modes. These modes may include wake-up times and sleep states, during which the device operates at full capacity and in sleep states, during which the device operates in a low power mode with limited capacity. Devices such as HWD 150 and / or computing device 110 may share / agreed / negotiate their sleep / low power / idle schedules with other devices (e.g., AP 105). One such sleep mode may be referred to as a target wake time (TWT).

[0047] Figure 4 4 is a timing diagram illustrating a wake-up / sleep schedule for a computing device utilizing TWT according to an example embodiment of the present disclosure. TWT can be a periodic, fixed wake-up schedule. That is, a device can wake up periodically (e.g., at fixed, configured time intervals / cycles / cycles) based on a TWT schedule. TWT scheduling reduces energy consumption of a device by limiting the device's wake-up time and associated power consumption.

[0048] The TWT start time is indicated by the device (e.g., a portion of its related modules / circuits) waking up at 402. The computing device 110 may wake up for a duration 404 defined by a service period (SP). During the wake-up time of the TWT schedule (or another sleep schedule), the device (computing device 110 and / or HWD 150) may be in an awake / active state (e.g., the wireless communication module / interface is in a powered-on state, a ready state, or an awake state) and may be able to send signals, listen to the medium, and / or receive signals / transmissions (e.g., using various contention-based and non-contention-based processes, etc.). After the SP duration 404, the device may enter a sleep state until the next TWT start time at 408. When the device is inactive or not awake (e.g., the wireless communication module / interface is in a powered-off state, a low-power state, or a sleep state), the device may enter a low-power mode or another sleep mode. The device may be in a sleep state until a time instance / window specified by the agreed-upon sleep schedule (e.g., the next wake-up start time 408). The time interval between the TWT start time 402 and the TWT start time 408 may be considered as the SP interval 406 .

[0049] TWT scheduling can be transmitted and / or negotiated using broadcast TWT (bTWT) and / or individual TWT (iTWT) signaling. In some embodiments, for signal iTWT, TWT scheduling information can be transmitted to specific (individual) devices using patterns such as Network Allocation Vector (NAV) to protect medium access for the TWT SP. In contrast, for signal bTWT, in some embodiments, a device (e.g., AP 105) can schedule TWT SPs with other devices (e.g., computing device 110 and / or HWD 150) and can share scheduling information in beacon frames and / or probe response frames.

[0050] When devices (including computing device 110 and / or HWD 150) negotiate and / or agree upon a scheduled sleep / wake schedule (e.g., an iTWT for a particular / specific device), data transmission (e.g., data received by a device and / or data sent by a device) becomes more predictable. A device is expected to receive / send data only when the device is in an awake state. When the device is awake, the device can be expected to receive / send data at any time. A device can go to sleep because it is not expected to communicate with other devices. When utilizing a sleep / wake schedule, a device can save power because the device consumes less power when it is in sleep / idle / low power mode.

[0051] In some cases (e.g., AR / VR applications), a device (e.g., computing device 110) communicates with one or more entities (e.g., AP 105 and / or HWD 150) over the same wireless communication channel. In these cases, each of these devices (e.g., one or more computing devices 110, AP 105, and / or one or more HWD 150) may contend for the same wireless channel and / or there may be an increased chance of data packet collisions. When a packet collision occurs, the devices may wait for a period of time, contend for the wireless channel, and resend the data packet. Competition for the same wireless channel and / or data packet collisions between devices may result in increased packet loss (e.g., packets not reaching their intended destination), increased latency (e.g., devices needing to resend data, devices needing to wait until the next opportunity to transmit their data), and / or jitter in data delivery. Consequently, the user experience and / or device performance may be poor. In these cases, the more devices sharing the same wireless channel, the lower the device and / or user performance. For example, in an AR / VR context, there may be an AP and multiple HWD / computing device pairs sharing the same wireless communication channel.

[0052] Figure 5 An interaction diagram / flowchart showing a process 500 for coordinating traffic for multiple devices sharing the same wireless communication channel according to an example embodiment of the present disclosure is shown. In some embodiments, the process 500 is performed by a first device 501, a second device 502, and / or a third device 503. The first device 501, the second device 502, and the third device 503 may be a computing device 110, an AP 105 / soft AP, and an HWD 150, respectively. In some embodiments, the process 500 is partially / entirely performed by one or more other entities. In some embodiments, the process 500 includes: Figure 5 More, fewer, or more steps than those shown in Figure 5 The steps shown in the are different steps.

[0053] In operation 510, the first device 501 may negotiate / determine a sleep schedule / wake-up schedule with the third device 503. In some embodiments, the sleep schedule / wake-up schedule between the first device 501 and the third device 503 may be preconfigured. For example, the first device 501 and the third device 503 may not agree / negotiate a sleep schedule because the first device 501 and the third device 503 may already be operating according to the sleep schedule / wake-up schedule (e.g., the sleep / wake-up schedule may be determined / preprogrammed by one or more manufacturers). In some embodiments, the periodicity of the sleep schedule / wake-up schedule between the first device 501 and the third device 503 may be based on a heartbeat interval (set by the first device 501 and / or the third device 503).

[0054] In operation 512, the first device 501 may negotiate / determine a sleep schedule / wake-up schedule with the second device 502. By determining (e.g., agreeing on) the sleep schedule / wake-up schedule, the first device 501 may ensure that the second device 502 does not transmit to the first device 501 outside the negotiated / agreed time interval. As described herein, the sleep schedule / wake-up schedule may enhance the predictability of data transmission, thereby allowing devices (e.g., the first device 501 and / or the third device 503) to reduce power consumption. The first device 501 may coordinate the sleep / wake-up schedule with the second device 502 based on the sleep / wake-up schedule with the third device 503. In some embodiments, the first device 501 may determine the start time of the sleep schedule (e.g., iTWT SP) based on the interconnect link traffic profile and the internal link traffic profile. Additionally or alternatively, the first device 501 may determine the periodicity of the sleep schedule (e.g., iTWT SP) based on the heartbeat interval (set by the first device 501 and / or the third device 503). Additionally or alternatively, the first device 501 may determine to wake up a certain incremental time before the third device 503, so that the first device 501 transmits / receives traffic with the second device 502 before the third device 503 wakes up. In other words, the time difference (increment) at which the first device 501 wakes up before the third device 503 may be relative to the wake-up time of the third device 503. It should be appreciated that the remaining operations (e.g., operations 514 to 528) may be performed when the first device 501 and / or the third device 503 wake up.

[0055] In operation 514, the first device 501 may send / transmit one or more flow classification service (SCS) request frames to the second device 502. For example, the one or more SCS request frames may include two SCS request frames to carry service profile information for a link between the first device 501 (e.g., computing device 110) and the second device 502 (e.g., HWD 150), and service profile information for another link between the first device 501 and the third device 503. There may be one SCS request frame for internal link service profile information and another SCS request frame for interconnect link service profile information. For example, the first SCS request frame may be used to indicate internal link service parameters / peer service parameters (e.g., service to be transmitted between the first device 501 and the third device 503) to the second device 502. The second SCS request frame may be used to indicate interconnect link service parameters (e.g., service to be transmitted between the first device 501 and the second device 502) to the second device 502. The SCS request frame may include information about the service to be transmitted, including delay / latency / priority information, throughput information, tolerable packet loss, IMU data, the size of the service to be transmitted, the duration of the service to be transmitted, etc.

[0056] In operation 516, the first device 501 and / or the second device 502 may determine one or more EDCA parameters. EDCA parameters are examples of parameters that may be used to coordinate multiple devices sharing access to a single wireless channel. In some embodiments, the first device 501 and / or the second device 502 may set / determine one or more other parameters configured to coordinate multiple devices sharing access to a single wireless channel. Examples of EDCA parameters include arbitration interframe spacing (AIFS), minimum contention window (CWmin), maximum contention window (CWmax), TXOP, and / or EDCA timer values. To ensure fairness in medium access, multiple wireless devices may probabilistically or randomly set values ​​for EDCA parameters to compete for access to a wireless link. However, accessing a wireless link in a probabilistic manner to promote fairness may result in latency, increased data packet collisions, and / or reduced throughput. Such latency or reduced throughput may be unsuitable for latency-critical applications, such as artificial reality applications. Therefore, the second device 502 may set EDCA parameters for one or more devices sharing a wireless channel. For example, the second device 502 may determine a (eg, sufficient / extended) duration of the TXOP using traffic information to be transmitted (eg, in the SCS request frame received at operation 514).

[0057] In an example embodiment, a second device 502 (e.g., an AP, at 516A) may set an EDCA timer value (e.g., a multi-user EDCA (MU-EDCA) timer) for a first device 501 (e.g., a computing device), while the first device 501 (at 516B) may set an EDCA timer value for a third device 503 (e.g., a HWD). The EDCA timer value may indicate a time window during which the first device 501 and / or the third device 503 do not contend for access to the medium. The second device 502 may set the EDCA timer value for the first device 501 to a large value to prevent the first device 501 from contending for a wireless channel. The first device 501 may set the EDCA timer value for the third device 503 to a large value to prevent the third device 503 from contending for the wireless channel. In some embodiments, the EDCA timer value may extend across the duration of a TXOP. In other embodiments, the EDCA timer value may extend across a portion of a TXOP (e.g., a first portion of a TXOP, which may be either an interlink data transmission or an intralink data transmission).

[0058] As shown in operation 518 (e.g., operation 518A at the first device 501 and operation 518B at the third device 503), the second device 502 may transmit a first EDCA timer value to the first device 501 using a first message, and the first device 501 may transmit a second EDCA timer value to the third device 503 using a second message. As shown in operation 520 (e.g., operation 520A at the first device 501 and operation 520B at the third device 503), the first device 501 and / or the third device 503 may receive the corresponding message containing the EDCA timer value and may / should avoid contention for the wireless channel based on the EDCA timer value. In some embodiments, the EDCA timer values ​​may be the same value.

[0059] In operation 522, the second device 502 can compete for the wireless channel. As shown in the figure, although there are multiple devices (e.g., the first device 501, the second device 502, and the third device 503) sharing the same wireless channel, only the second device 502 can compete for access to the wireless channel due to the high / large / defined EDCA timer value. In some embodiments, the second device 502 can use an aggressive access category (e.g., video input / video output, or another other delay-sensitive service type) to compete for access to the wireless channel. The second device 502 can use the service information to be transmitted / received from the first device 501 in operation 514 to compete for the wireless channel. That is, the SCS request frame can help the second device 502 schedule the duration of the second device's TXOP so that the duration of the TXOP is sufficient for both internal link communication and interconnect link communication.

[0060] The second device 502 may contend for access to the wireless channel for a duration suitable for interlink communication (e.g., communication between the first device 501 and the second device 502) and internal link communication (e.g., communication between the first device 501 and the third device 503). The second device 502 may determine the internal link communication using the traffic information in the SCS frame to be transmitted / received in operation 514. In some instances, the second device 502 receives the traffic to be transmitted for a duration during which the first device 501 requests communication with the third device 503 for internal link data transmission. In some instances, the second device 502 receives the traffic to be transmitted, such as the size of the traffic to be transmitted between the first device 501 and the third device 503. The second device 502 may be configured to determine the duration of the internal link data transmission based on the size of the traffic to be transmitted.

[0061] In operation 524, the second device 502 may transmit traffic to / receive traffic from the first device 501 in response to the second device 502 winning / obtaining / confirming access to the channel. For example, the second device 502 may transmit downlink interlink traffic during a TXOP allocated / assigned / won by the second device 502. Additionally or alternatively, during the TXOP, the second device may receive uplink interlink traffic from the first device 501.

[0062] In operation 526, the second device 502 indicates the remaining duration of the TXOP that it is sharing (or will share) with the first device 501. In some cases, the indication may include a multi-user request to send TXOP sharing (MU-RTS TXS) frame (e.g., Mode 2). The indication may include the duration remaining in the TXOP. It should be appreciated that although Figure 5 Interlink communication between the second device 502 and the first device 501 is shown at operation 524, and then a shared TXOP is shown at operation 526 (see Figure 6 ), but in other embodiments, the second device 502 may share a TXOP with the first device 501 (eg, for transmitting an internal link service) before the first device 501 transmits an interlink service to the second device 502 (see Figure 7 In the case where there are multiple pairs of devices (e.g., HWD 150 and computing device 110, third device 503 and first device 501), the second device (e.g., AP 105) can share different TXOPs (and / or different parts of the TXOP) with different first devices.

[0063] In operation 528, the first device 501 may transmit (e.g., send / receive) both interlink traffic and interlink traffic (e.g., transmit traffic with the second device 502 and / or the third device 503) during a single shared TXOP in response to the first device 501 receiving an indication that the TXOP of the second device 502 is shared (or will be shared) with the first device 501. As described herein, the second device 502 may allocate sufficient time in the TXOP such that the duration of the TXOP supports / facilitates / allows both interlink communication and intralink communication. Thus, the TXOP may be considered to be divided into at least two parts. Figure 6 As shown, the first part of the TXOP (e.g., interlink communication) is performed before the second part of the TXOP (e.g., interlink communication). Figure 7 As shown, the first part of the TXOP (e.g., internal link communication) is performed before the second part of the TXOP (e.g., interlink communication). The first device 501 can determine the order of data exchange based on, for example, the type of application being executed (e.g., AR / VR application), data priority (e.g., latency-sensitive service), and scheduling (e.g., sleep scheduling, pre-configured scheduling).

[0064] Figure 6An interaction diagram illustrating a process 600 for coordinating intra-link communication and inter-link communication within a TXOP through TXOP sharing according to an example embodiment of the present disclosure is shown. It should be appreciated that a first device 501 (e.g., computing device 110) may have negotiated a sleep schedule / wake-up schedule with a second device (e.g., AP 105) or the first device 501 (e.g., computing device 110) may have obtained the sleep schedule / wake-up schedule, and the first device 501 (e.g., computing device 110) may have negotiated a sleep schedule / wake-up schedule with a third device 503 (e.g., HWD 150) or the first device 501 (e.g., computing device 110) may have predefined the sleep schedule / wake-up schedule. It should also be appreciated that the second device 502 may set a high EDCA timer value so that the first device 501 may avoid contending for access to a wireless channel (or may be dormant / in idle mode / low power mode), and the first device 501 may set a high EDCA timer value so that the third device 503 may avoid contending for access to a wireless channel. Thus, the second device 502 has earned / gained access to the channel for the TXOP duration 630, which is sufficient for both interlink communications and intralink communications.

[0065] During the TXOP of the second device 502 (or at the beginning of the TXOP of the second device 502), the first device 501 wakes up at 610. The first device 501 and the second device 502 may transmit interlink traffic 620. For example, the second device 502 may transmit downlink traffic to the first device 501. At some point during the interlink communication 620, the second device 502 may indicate to the first device that it is sharing (or will be sharing) the TXOP. For example, the second device 502 may send a MU-RTS TXS frame (e.g., of Mode 2) to initiate sharing the remaining TXOP time with the first device 501. If the MU-RTS TXS frame is of Mode 2 (e.g., set by the second device), the first device 501 may send uplink traffic to the second device 502 during the interlink communication 620 in the TXOP. In some cases, the first device 501 may not have uplink traffic to send to the second device 502.

[0066] After the interlink communication 620 (e.g., downlink communication from the second device 502 to the first device 501 and / or uplink communication from the first device 501 to the second device 502), the third device 503 may wake up at / near 612. Sharing the TXOP between the second device 502 and the first device 501 may enable the first device 501 to transmit interlink traffic 622 (e.g., downlink communication from the first device 501 to the third device 503 and / or uplink communication from the third device 503 to the first device 501) with the third device 503. The first device 501 may send traffic to the third device 503 and / or request traffic from the third device 503 during the interlink communication 622. Figures 8 to 11 The manner in which the first device 501 may request / trigger traffic from the third device 503 during the internal link communication 622 is shown.

[0067] After the internal link communication 622, the third device 503 and the first device 501 can enter their respective sleep states / idle modes / low power modes until the next scheduled wake-up time (not shown). The third device 503 and the first device 501 can enter the sleep state because the third device 503 and the first device 501 have agreed (with each other and / or with the second device 502) that no further frames / packets / messages will be addressed to the first device 501 and / or the third device 503 before the next pre-agreed schedule.

[0068] Figure 7 Another interaction diagram illustrating a process 700 for coordinating intra-link communications and inter-link communications within a TXOP through TXOP sharing according to an example embodiment of the present disclosure is shown. Figure 6As described, it should be appreciated that the first device 501 (e.g., computing device 110) may have negotiated a sleep schedule / wake schedule with the second device (e.g., AP 105), and the first device 501 (e.g., computing device 110) may have negotiated a sleep schedule / wake schedule with the third device 503 (e.g., HWD 150), or the first device 501 (e.g., computing device 110) may have predefined the sleep schedule / wake schedule. It should also be appreciated that the second device 502 may have set a high EDCA timer value for the first device 501 so that the first device 501 can avoid contending for access to the wireless channel (or be in sleep / idle mode / low power mode), and the first device 501 may have set a high EDCA timer value for the third device 503 so that the third device 503 can avoid contending for access to the wireless channel. Therefore, the second device 502 has won / gained access to the channel for the TXOP duration 730, which is sufficient for both interlink communication and intralink communication.

[0069] During the TXOP of the second device 502 (or at the start of the TXOP of the second device 502), the first device 501 and the third device 503 may wake up at 710. The second device 502 may indicate at / near 710 that the TXOP allocated to the second device 502 is being shared (or will be shared) by the second device 502 and the first device 501. For example, the second device 502 may send a MU-RTS TXS. If the MU-RTS TXS frame is mode 2, the first device 501 may send traffic to the third device 503 during peer-to-peer (inter-link) communication 720. Additionally or alternatively, as described with reference to Figures 8 to 11 As described, the first device 501 can request services from the third device 503 during the internal link communication 720 .

[0070] After the internal link communication 720 (e.g., downlink communication from the first device 501 to the third device 503 and / or uplink communication from the third device 503 to the first device 501), the third device 503 may begin to sleep or enter a sleep state / idle mode / low power mode at / near 712 until the next scheduled wake-up time (not shown). After the internal link communication 720, the first device 501 may communicate interlink traffic 722 (e.g., uplink communication from the first device 501 to the second device 502 and / or downlink communication from the second device 502 to the first device 501) with the second device 502.

[0071] After the interconnect link communication 722, the first device 501 may enter a sleep state / idle mode / low power mode at / near 714 until the next scheduled wake-up time (not shown). It should be appreciated that, in the first data exchange (e.g., with reference to Figure 6 During the first data exchange (e.g., data exchange 630), the first device 501 may transmit interlink traffic followed by intralink traffic. However, during the second data exchange (e.g., data exchange 730), the first device 501 may transmit intralink traffic followed by interlink traffic. The first device 501 may be configured to make such communication decisions based on, for example, the sleep schedule with the third device 503 and the type of traffic (priority, latency sensitivity, etc.) being transmitted (e.g., during intralink or interlink communication).

[0072] Figures 8 to 11 1 illustrates different ways in which computing device 110 and HWD 150 may coordinate traffic during inter-link communications according to example embodiments of the present disclosure. Figures 8 to 11 In each of the figures in FIG, computing device 110 and / or HWD 150 do not compete for channel access. Computing device 110 communicates with HWD 150 using a TXOP shared by AP 105 (or second device 502). As part of service coordination, computing device 110 may use various types of messages during the TXOP to trigger HWD 150 to start / initiate inter-link communications. As part of the inter-link communications, messages / responses such as clear to send (CTS), block acknowledgement (BA), etc. may be transmitted between computing device 110 and / or HWD 150. In addition, such inter-link communications may include intervals between communications, such as short interframe space (SIFS). For example, the total time of the inter-link service (e.g., Figure 8 850 of them, Figure 9 950 of them, Figure 10 1050 in Figure 11 1150) may include such BA, CTS and SIFS.

[0073] like Figure 8As shown, an example downlink message transmitted by computing device 110 may include a MU-RTS TXS frame 802. When computing device 110 sets the MU-RTS TXS frame to Mode 1, computing device 110 may request interlink data from HWD 150. This interlink communication may be beneficial for priority / latency sensitive data (e.g., sensor data sent from HWD 150). In response to MU-RTS TXS frame 802, HWD 150 may transmit interlink traffic (e.g., uplink data) during 804 using a single user (SU) physical layer protocol data unit (PPDU). In some embodiments, computing device 110 may respond to HWD 150 with a SU PPDU 806. During the duration 850 of the interlink communication, computing device 110 and / or HWD 150 may communicate in a back-and-forth manner / iteratively / with each other using the SU PPDU. In this example embodiment, HWD 150 may be configured to support at least seventh generation Wi-Fi such that HWD 150 correctly interprets MU-RTX TXS frame 802 .

[0074] like Figure 9 As shown, an example downlink message transmitted by computing device 110 may include a trigger-based (TB) PPDU 902 (e.g., a basic trigger). When computing device 110 transmits a trigger to HWD 150, computing device 110 may request intra-link data from HWD 150. Such intra-link communication may be beneficial for priority / latency-sensitive data (e.g., sensor data received by computing device 110 from HWD 150). HWD 150 may transmit intra-link traffic (e.g., uplink data) using a TB PPDU during 904 in response to basic trigger 902. In some embodiments, computing device 110 may respond to HWD 150 with a SU PPDU 906. Computing device 110 and / or HWD 150 may communicate iteratively / interactively over a duration 950 of the intra-link communication. In this example embodiment, HWD 150 may be configured to support at least sixth generation Wi-Fi so that HWD 150 can interpret TB PPDUs. In some embodiments, interpreting TB PPDUs may cause HWD 150 to consume additional computing resources to process the TB PPDUs.

[0075] like Figure 10As shown, an example downlink message transmitted by the computing device 110 may include a SU PPDU packet with a reverse direction grant (RDG) bit set 1002 in a high throughput, very high throughput, and / or high efficiency control field (not shown). Setting / enabling RDG allows the computing device 110 and the HWD 150 to initiate a reverse frame exchange in which the HWD 150 responds to the computing device 110. In one example, after the HWD 150 sends a BA acknowledging receipt of the SU PPDU packet with the RDG bit set 1002, the HWD 150 may send its internal link data to the computing device 110 in a SU PPDU 1004. The computing device 110 and / or the HWD 150 may communicate iteratively / with each other for the duration of the internal link communication 1050. In one example embodiment, the HWD 150 may be any legacy compatible device (e.g., the HWD 150 may be configured to support at least fifth generation Wi-Fi). With the reception of Figure 8 and Figure 9 Communication of SU PPDU packets may involve less overhead / processing performed by the HWD 150 compared to the described MU-RTS TXS and / or TBPPDUs.

[0076] like Figure 11 As shown, an example downlink message transmitted by computing device 110 may include an Orthogonal Frequency Division Multiple Access (OFDMA) PPDU 1102 with an embedded basic trigger. HWD 150 may interpret the OFDM APPDU 1102 with an embedded basic trigger as an implicit trigger for transmitting internal link data (as opposed to the implicit triggers in the respective Figures 8 to 10 150). In one example, the HWD 150 may respond to the OFDMA PPDU 1102 with the embedded basic trigger using a TB PPDU 1104. The computing device 110 and / or the HWD 150 may iteratively / interact with each other for the duration of the internal link communication 1150. In this example embodiment, the HWD 150 may be configured to support at least the sixth generation of Wi-Fi. Figures 8 to 10 Communication of OFDMA PPDU packets may involve less overhead / processing performed by the HWD 150 compared to the MU-RTS TXS, TB PPDU, and / or SU PPDU with the RDG bit set described in

[0064] .

[0077] Now that some illustrative embodiments have been described, it will be apparent that the foregoing is illustrative and not restrictive, and that these illustrative embodiments have been presented by way of example. Specifically, although many of the examples presented herein relate to specific combinations of method actions or system elements, these actions and these elements can be combined in other ways to achieve the same goals. Actions, elements, and features discussed in conjunction with one embodiment are not intended to be excluded from similar roles in other embodiments or embodiments.

[0078] The hardware and data processing components for implementing the various processes, operations, exemplary logic, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented as or performed using: a general-purpose single-chip or multi-chip processor; a digital signal processor (DSP); an application-specific integrated circuit (ASIC); a field-programmable gate array (FPGA); or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of multiple computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In some embodiments, specific processes and methods may be performed by circuits specific to a given function. The memory (e.g., memory, storage unit, storage device, etc.) may include one or more devices (e.g., random access memory (RAM), read-only memory (ROM), flash memory, hard disk storage, etc.) for storing data and / or computer code that completes or facilitates the various processes, layers, and modules described in this disclosure. The memory may be or include volatile memory or non-volatile memory, and the memory may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in this disclosure. According to an exemplary embodiment, the memory is communicatively connected to the processor via the processing circuit, and the memory includes computer code for executing (e.g., by the processing circuit and / or the processor) one or more processes described herein.

[0079] The present disclosure contemplates methods, systems, and program products on any machine-readable medium for performing various operations. The embodiments of the present disclosure can be implemented using existing computer processors, or by dedicated computer processors for appropriate systems, combined for one or another purpose, or implemented by hard-wired systems. Embodiments within the scope of the present disclosure include program products that include machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available medium that can be accessed by a general-purpose or special-purpose computer or other machine with a processor. As an example, such machine-readable media can include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of machine-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer or other machine with a processor. The above combinations 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, a special-purpose computer, or a special-purpose processing machine to perform a certain function or a group of functions.

[0080] The phraseology and terminology used herein are for descriptive purposes and should not be construed as limiting. The use of "including," "comprising," "having," "containing," "involving," "characterized by," "characterized by," and variations thereof herein is meant to encompass the items listed thereafter, their equivalents and additional items, and alternative embodiments consisting of the items specifically listed thereafter. In one embodiment, the systems and methods described herein consist of one, more than one, or all of the elements, acts, or components described.

[0081] Any reference herein to an embodiment or element or action of a system or method in the singular may also include embodiments that include a plurality of such elements, and any reference herein to any embodiment, element, or action in the plural may also include embodiments that include only a single element. References in the singular or plural are not intended to limit the presently disclosed systems or methods, their components, actions, or elements to singular or plural configurations. Reference to any action or element based on any information, action, or element may include embodiments in which the action or element is based, at least in part, on any information, action, or element.

[0082] Any embodiment disclosed herein may be combined with any other embodiment or example, and references to "an embodiment," "some embodiments," "an embodiment," etc. are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment or example. These terms as used herein are not necessarily all referring to the same embodiment. Any embodiment may be inclusively or exclusively combined with any other embodiment in any manner consistent with the aspects and embodiments disclosed herein.

[0083] Where technical features in the drawings, detailed description, or any claims are followed by reference numerals, these reference numerals have been included to enhance the intelligibility of the drawings, detailed description, and claims. Therefore, the presence or absence of a reference numeral has no limiting effect on the scope of any claim element.

[0084] The systems and methods described herein may be embodied in other specific forms without departing from their characteristics. Unless expressly stated otherwise, references to "approximately," "about," "substantially," or other terms of degree include variations of ±10% of a given measurement, unit, or range. Coupled elements may be directly electrically, mechanically, or physically coupled to each other, or to intermediate elements. The scope of the systems and methods described herein is therefore indicated by the appended claims, rather than the foregoing description, and changes within the meaning and range of equivalents of the claims are intended to be included therein.

[0085] The term "coupled" and variations thereof include two parts being connected directly or indirectly to one another. Such connection may be fixed (e.g., permanent or immutable) or removable (e.g., removable or releasable). Such connection may be achieved by the two parts being directly coupled together or to one another, by the two parts being coupled to one another using a single intermediate portion and any additional mutually coupled intermediate portions, or by the two parts being coupled to one another using an intermediate portion that is integrally formed as a single unitary body with one of the two parts. 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 language meaning of the additional term (e.g., "directly coupled" refers to the connection of two parts without any separating intermediate portion), thereby producing a narrower definition than the general definition of "coupled" provided above. Such coupling may be mechanical, electrical, or fluidic.

[0086] References to "or" may be interpreted as inclusive, such that any term described using "or" may mean any of a single, more than one, and all of the terms described. References to at least one of "A" and "B" may include only "A," only "B," and both "A" and "B." Such references used in conjunction with "including" or other open-ended terms may include additional items.

[0087] Without materially departing from the teachings and advantages of the subject matter disclosed herein, modifications may be made to the described elements and actions, such as changes in the size, dimensions, structure, shape and proportions of the various elements, parameter values, mounting arrangements, use of materials, colors, orientations, and the like. For example, elements shown as integrally formed may be constructed from multiple parts or elements, the positions of elements may be reversed or otherwise changed, and the nature or number of discrete elements or positions may be altered or varied. Other substitutions, modifications, changes, and omissions may also be made in the design, operating conditions, and arrangement of the disclosed elements and actions without departing from the scope of the present disclosure.

[0088] References herein to the positions of elements (e.g., "top," "top," "above," "below") are merely used to describe the orientation of the various elements in the drawings. The orientation of the various elements may differ according to other exemplary embodiments, and these variations are intended to be encompassed by the present disclosure.

Claims

1. A method, comprising: sending, by a first wireless communication device to a second wireless communication device, at least one flow classification service (SCS) request frame, the SCS request frame including information of a service to be transmitted between the first wireless communication device and at least one of: the second wireless communication device or a third wireless communication device, wherein the first wireless communication device, the second wireless communication device, and the third wireless communication device share a wireless communication channel; and The first wireless communication device communicates with the second wireless communication device on a first link during a first portion of the TXOP, and communicates with the third wireless communication device on a second link during a second portion of the TXOP, in response to receiving an indication to share a transmission opportunity (TXOP) of the second wireless communication device with the first wireless communication device.

2. The method according to claim 1, comprising: A target wake time (TWT) schedule is determined by the first wireless communication device to communicate with the second wireless communication device.

3. The method according to claim 2, comprising: A wake-up schedule is determined by the first wireless communication device to communicate with the third wireless communication device.

4. The method according to claim 3, wherein: The first wireless communication device determines the TWT schedule based on the wake-up schedule.

5. The method according to claim 1, wherein: The indication includes a Multi-User Request to Send TXOP Sharing (MU-RTSTXS) frame.

6. The method according to claim 1, comprising: receiving, by the first wireless communication device, a message from the second wireless communication device, the message comprising an enhanced distributed channel access (EDCA) timer value; as well as The first wireless communication device avoids contention for the wireless communication channel according to the EDCA timer value.

7. The method according to claim 1, comprising: The third wireless communication device is triggered by the first wireless communication device through a message, and the message is transmitted to the third wireless communication device during the TXOP.

8. The method according to claim 7, wherein: The message includes one of: a multi-user request to send TXOP shared MU-RTS TXS frame; a trigger-based physical layer protocol data unit (PPDU); a single-user PPDU with a set of reverse direction grant (RDG) bits; or an orthogonal frequency division multiple access (OFDMA) PPDU embedded with a basic trigger.

9. The method according to claim 1, wherein: The first portion of the TXOP is performed at a time before the second portion of the TXOP.

10. The method according to claim 1, wherein: The second portion of the TXOP is performed at a time before the first portion of the TXOP.

11. A wireless communication device, comprising: Transceiver; as well as at least one processor, the at least one processor being configured to: sending, via the transceiver, at least one flow classification service (SCS) request frame to a second wireless communication device, the SCS request frame including information of a service to be transmitted between the wireless communication device and at least one of: the second wireless communication device or a third wireless communication device, wherein the wireless communication device, the second wireless communication device, and the third wireless communication device share a wireless communication channel; as well as In response to receiving an indication to share a transmission opportunity (TXOP) of the second wireless communication device with the wireless communication device, communicating with the second wireless communication device on a first link during a first portion of the TXOP via the transceiver, and communicating with the third wireless communication device on a second link during a second portion of the TXOP.

12. The wireless communication device according to claim 11, wherein: The at least one processor is configured to determine a target wake time (TWT) schedule with the second wireless communication device.

13. The wireless communication device according to claim 12, wherein: The at least one processor is configured to determine a wake-up schedule with the third wireless communication device.

14. The wireless communication device according to claim 13, wherein: The at least one processor is configured to determine the TWT schedule based on the wake-up schedule.

15. The wireless communication device according to claim 11, wherein: The indication includes a Multi-User Request to Send TXOP Sharing (MU-RTS TXS) frame.

16. The wireless communication device according to claim 11, wherein: The at least one processor is configured to: receiving, via the transceiver, a message from the second wireless communication device, the message comprising an enhanced distributed channel access (EDCA) timer value; and Contention for the wireless communication channel is avoided according to the EDCA timer value.

17. The wireless communication device according to claim 11, wherein: The at least one processor is configured to trigger the third wireless communication device via a message sent via the transceiver, the message being communicated to the third wireless communication device during the TXOP.

18. The wireless communication device according to claim 11, wherein: The message includes one of: a multi-user request to send TXOP shared MU-RTS TXS frame; a trigger-based physical layer protocol data unit (PPDU); a single-user PPDU with a set of reverse direction grant (RDG) bits; or an orthogonal frequency division multiple access (OFDMA) PPDU embedded with a basic trigger.

19. The wireless communication device according to claim 11, wherein: The first portion of the TXOP is performed at a time before the second portion of the TXOP, or wherein the second portion of the TXOP is performed at a time before the first portion of the TXOP.

20. A non-transitory processor-readable medium comprising processor-readable instructions, such that when the processor-readable instructions are executed by one or more processors of a wireless communication device, the one or more processors: sending, via the transceiver, at least one flow classification service (SCS) request frame to a second wireless communication device, the SCS request frame including information of a service to be transmitted between the wireless communication device and at least one of: the second wireless communication device or a third wireless communication device, wherein The wireless communication device, the second wireless communication device and the third wireless communication device share a wireless communication channel; as well as In response to receiving an indication to share a transmission opportunity (TXOP) of the second wireless communication device with the wireless communication device, communicating with the second wireless communication device on a first link via the transceiver during a first portion of the TXOP, and communicating with the third wireless communication device on a second link via the transceiver during a second portion of the TXOP.

Images