Synchronous channel access control for wireless systems

Abstract

The present disclosure provides a system, method, and apparatus for synchronous channel access control of a wireless system. In some aspects, a device can communicate with a second device during one or more TWT service periods using a TWT session. Uplink and downlink communications may be coordinated to be both within the TWT service period to allow the device to enter a low power mode outside the TWT service period. A TWT session including a service period may be configured and managed by the device or the second device to ensure that communications associated with an XR experience between the devices (such as pause or tracking frames provided as uplink data or video data frames provided as downlink data) meet latency or other requirements for the XR experience. The use of a TWT service period allows other devices to use the wireless medium outside the TWT service period.

Description

Priority claims

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims priority to commonly assigned U.S. patent application Ser. No. 17 / 188,165 entitled "ASYNCHRONOUS CHANNEL ACCESS CONTROL OF A WIRELESS SYSTEM," filed March 1, 2021, and U.S. patent application Ser. No. 17 / 188,275 entitled "SYNCHRONOUS CHANNEL ACCESS CONTROL OF A WIRELESS SYSTEM," filed March 1, 2021. The disclosures of all prior applications are considered part of, and incorporated by reference into, this patent application. [Technical Field]

[0002]

[0002] The present disclosure relates generally to wireless communications, and more particularly to synchronized channel access control for wireless systems. [Background technology]

[0003] A wireless local area network (WLAN) may be formed by one or more access points (APs), which provide a shared wireless communication medium for use by several client devices, also called stations (STAs). The basic building block of a WLAN conforming to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards is a basic service set (BSS) managed by the AP. Each BSS is identified by a basic service set identifier (BSSID) advertised by the AP. The AP periodically broadcasts beacon frames to enable any STA within wireless range of the AP to establish or maintain a communication link with the WLAN.

[0004]

[0004] Some wireless communication devices may be associated with low-latency traffic (such as gaming traffic or extended reality (XR) traffic) that has stringent end-to-end latency, packet loss, and throughput requirements. It is desirable for a WLAN to ensure that such low-latency traffic can be handled without violating their respective latency and packet loss requirements. Summary of the Invention

[0005]

[0005] The systems, methods, and devices of the present disclosure each have several inventive aspects, no single aspect of which may be solely responsible for the desirable attributes disclosed herein.

[0006] One inventive aspect of the subject matter described in this disclosure may be implemented as a method for wireless communication. In some implementations, the method may be performed by a wireless communication device and may include obtaining control of a wireless medium. The control of the wireless medium is associated with a first priority for transmitting a first physical layer protocol data unit (PPDU) of an application file from the wireless communication device to a second device over the wireless medium, the first priority being different from a second priority for transmitting data from the second device to the wireless communication device over the wireless medium. The method may also include providing the first PPDU to the second device. The method may also include providing one or more subsequent PPDUs of the application file to the second device. Providing the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium.

[0007] Another inventive aspect of the subject matter described in this disclosure may be implemented in a wireless communication device. The wireless communication device includes a processing system and an interface. The interface is configured to obtain control of a wireless medium. The control of the wireless medium is associated with a first priority for transmitting a first PPDU of an application file from the wireless communication device to a second device over the wireless medium, the first priority being different from a second priority for transmitting data from the second device to the wireless communication device over the wireless medium. The interface is also configured to provide the first PPDU to the second device and to provide one or more subsequent PPDUs of the application file to the second device. Providing the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium.

[0008] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, the method may be performed by a wireless communication device and may include obtaining a first PPDU of an application file from an AP over a wireless medium. The AP obtains control of the wireless medium. The control of the wireless medium is associated with a first priority for transmitting the first PPDU over the wireless medium, the first priority being different from a second priority for transmitting data from the wireless communication device to the AP over the wireless medium. The method may also include obtaining one or more subsequent PPDUs of the application file from the AP. The obtaining the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium.

[0009] Another inventive aspect of the subject matter described in this disclosure may be implemented in another wireless communication device. The wireless communication device includes a processing system and an interface. The interface is configured to obtain a first PPDU of an application file from an AP over a wireless medium. The AP obtains control of the wireless medium. The control of the wireless medium is associated with a first priority for transmitting the first PPDU over the wireless medium, the first priority being different from a second priority for transmitting data from the wireless communication device to the AP over the wireless medium. The interface is also configured to obtain one or more subsequent PPDUs of the application file from the AP. Obtaining the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium.

[0010] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, the method may be performed by a device and may include obtaining uplink (UL) data from a second device over a wireless medium and providing downlink (DL) data including PPDUs to the second device over the wireless medium. The one or more PPDUs are provided to the second device during a current target wake time (TWT) window, where a start of the current TWT window is associated with one of when a first PPDU of the one or more PPDUs is provided to the second device or when the first PPDU is provided from an application layer of the device to a medium access control layer (MAC).

[0011] Another inventive aspect of the subject matter described in this disclosure may be implemented in a device. The device includes a processing system and an interface. The interface is configured to obtain UL data from a second device over a wireless medium and provide DL data including PPDUs to the second device over the wireless medium. The one or more PPDUs are provided to the second device during a current TWT window, and a start of the current TWT window is associated with one of when a first PPDU of the one or more PPDUs is provided to the second device or when the first PPDU is provided from an application layer of the device to a MAC.

[0012] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communications. In some implementations, the method may be performed by a device and may include providing UL data to a second device over a wireless medium and acquiring DL data from the second device over the wireless medium, the DL data including PPDUs. The one or more PPDUs are acquired from the second device during a current TWT window, and a start of the current TWT window is associated with one of when a first PPDU of the one or more PPDUs is provided by the second device or when the first PPDU is provided to a MAC from an application layer of the second device.

[0013] Another inventive aspect of the subject matter described in this disclosure may be implemented in a device. The device includes a processing system and an interface. The interface is configured to provide UL data to a second device over a wireless medium and to acquire DL data including PPDUs from the second device over the wireless medium. The one or more PPDUs are acquired from the second device during a current TWT window, and a start of the current TWT window is associated with one of a time when a first PPDU of the one or more PPDUs is provided by the second device or a time when the first PPDU is provided to a MAC from an application layer of the second device.

[0014] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, the method may be performed by a device and may include rendering a plurality of video frames to be provided to a second device, dividing each video frame of the plurality of video frames into a plurality of video slices, and generating, for each video slice of the plurality of video slices, a plurality of PPDUs to include the video slice. Each PPDU includes one or more Medium Access Control Layer (MAC) Service Data Units (MSDUs) associated with the video slice, and the video slices are identified by a port number and a differentiated services field codepoint (DSCP) value included in each MSDU of the plurality of PPDUs. The method also includes queuing an MSDU for transmission to the second device for each video slice of the plurality of video slices.

[0015] Another inventive aspect of the subject matter described in this disclosure may be implemented in a device. The device includes a processing system and an interface. The processing system is configured to render a plurality of video frames to be provided to a second device, divide each video frame of the plurality of video frames into a plurality of video slices, and generate a plurality of PPDUs for each video slice of the plurality of video slices to include the video slice. Each PPDU includes one or more MSDUs associated with the video slice, and the video slice is identified by a port number and a DSCP value included in each MSDU of the plurality of PPDUs. The processing system is also configured to queue an MSDU for transmission to the second device for each video slice of the plurality of video slices.

[0016] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, the method may be performed by a device and may include obtaining, from a second device, one or more PPDUs associated with video frames. The second device renders a plurality of video frames to be provided to the device, and the second device divides each video frame of the plurality of video frames into a plurality of video slices. For each video slice of the plurality of video slices, the second device generates a plurality of PPDUs to include the video slice. Each PPDU includes one or more MSDUs associated with the video slice, and the video slice is identified by a port number and a DSCP value included in each MSDU of the plurality of PPDUs. For each video slice of the plurality of video slices, the second device queues an MSDU for transmission to the device.

[0017] Another inventive aspect of the subject matter described in this disclosure may be implemented in a device. The device includes a processing system and an interface. The interface is configured to obtain one or more PPDUs associated with video frames from a second device. The second device renders a plurality of video frames to be provided to the device, and the second device divides each video frame of the plurality of video frames into a plurality of video slices. For each video slice of the plurality of video slices, the second device generates a plurality of PPDUs to include the video slice. Each PPDU includes one or more MSDUs associated with the video slice, and the video slice is identified by a port number and a DSCP value included in each MSDU of the plurality of PPDUs. For each video slice of the plurality of video slices, the second device queues an MSDU for transmission to the device.

[0018] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, a method may be performed by a device and may include attempting to provide, to a second device, a plurality of PPDUs associated with one or more video frames of an XR experience, and measuring one or more of a PPDU transmission latency associated with the attempt to provide the plurality of PPDUs or a PPDU transmission drop associated with the attempt to provide the plurality of PPDUs. One or more parameters of the XR experience are adjusted and associated with one or more of the measurements.

[0019] Another inventive aspect of the subject matter described in this disclosure may be implemented in a device. The device includes a processing system and an interface. The interface is configured to attempt to provide a plurality of PPDUs associated with one or more video frames of an XR experience to a second device. The processing system is configured to measure one or more of a PPDU transmission latency associated with attempting to provide the plurality of PPDUs or a PPDU transmission dropout associated with attempting to provide the plurality of PPDUs. One or more parameters of the XR experience are adjusted and associated with one or more of the measurements.

[0020] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, a method may be performed by a device and may include attempting to provide, to a second device, a plurality of pose data frames associated with one or more video frames of an XR experience, and measuring one or more of a pause data frame transmission latency associated with attempting to provide the plurality of pose data frames or a pause data frame transmission dropout associated with attempting to provide the plurality of pose data frames. One or more parameters of the XR experience are adjusted and associated with one or more of the measurements.

[0021] Another inventive aspect of the subject matter described in this disclosure may be implemented in a device. The device includes a processing system and an interface. The interface is configured to attempt to provide a plurality of pose data frames associated with one or more video frames of an XR experience to a second device. The processing system is configured to measure one or more of a pose data frame transmission latency associated with attempting to provide the plurality of pose data frames or a pose data frame transmission dropout associated with attempting to provide the plurality of pose data frames. One or more parameters of the XR experience are adjusted and associated with one or more of the measurements.

[0022] Another inventive aspect of the subject matter described in this disclosure may be implemented as another method for wireless communication. In some implementations, the method may be performed by a wireless communication device and may include communicating with a first device over a first wireless link and communicating with a second device over a second wireless link. The wireless communication device simultaneously communicates with the first device and the second device using one of a multi-link operation (MLO) technique or a TWT mode, and the wireless communication device is configured to give preference to communication over the second wireless link over communication over the first wireless link.

[0023] Another inventive aspect of the subject matter described in this disclosure may be implemented in a wireless communication device. The wireless communication device includes a processing system and an interface. The interface is configured to communicate with a first device over a first wireless link and with a second device over a second wireless link. The wireless communication device simultaneously communicates with the first device and the second device using one of an MLO technique or a TWT mode, and the wireless communication device is configured to give preference to communications over the second wireless link over communications over the first wireless link.

[0024]

[0024] The details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. Please note that the relative dimensions of the following figures may not be drawn to scale. [Brief explanation of the drawings]

[0025] [Figure 1A] 1 is a pictorial diagram of an exemplary wireless communication network. [Figure 1B]

[0026] A pictorial representation of an exemplary group of devices for providing an extended reality (XR) experience. [Figure 2A]

[0027] 1 illustrates an example protocol data unit (PDU) that can be used for communication between wireless communication devices. [Figure 2B]

[0028] 2B illustrates exemplary fields in the PDU of FIG. 2A. [Figure 3A]

[0029] 1 illustrates another exemplary PDU that can be used for communication between wireless communication devices. [Figure 3B]

[0030] 1 illustrates another exemplary PDU that can be used for communication between wireless communication devices. [Figure 4]

[0031] 1 illustrates an example Physical Layer Convergence Protocol (PLCP) Protocol Data Unit (PPDU) that can be used for communication between wireless communication devices. [Figure 5]

[0032] 1 is a block diagram of an exemplary wireless communication device. [Figure 6A]

[0033] 1 is a block diagram of an exemplary access point (AP). [Figure 6B]

[0034] 1 is a block diagram of an exemplary station (STA). [Figure 7]

[0035] 1 is a sequence diagram illustrating an exemplary motion-to-render-to-photon (M2R2P) operation. [Figure 8]

[0036] 1 is a flowchart illustrating an example process for asynchronous channel access control, according to some implementations. [Figure 9]

[0037] 1 is a flowchart illustrating an example process for asynchronous channel access control, according to some implementations. [Figure 10]

[0038] FIG. 10 is a sequence diagram illustrating an example transmission between devices for an XR experience. [Figure 11]

[0039] 1 is a flowchart illustrating an example process for synchronized channel access control based on a target wake-up time (TWT) session, according to some implementations. [Figure 12]

[0040] 1 is a flowchart illustrating an example process for synchronized channel access control based on TWT sessions, according to some implementations. [Figure 13]

[0041] 1 is a sequence diagram illustrating exemplary timing of rendering of pose data frames and video frames associated with motion-to-render (M2R) latency. [Figure 14]

[0042] 10A and 10B are sequence diagrams illustrating exemplary timing of rendering of pose data frames and video frames associated with M2R latency. [Figure 15A]

[0043] FIG. 1 is a block diagram illustrating an example of synchronizing the clocks of a rendering device and a display device. [Figure 15B]

[0044] FIG. 1 is a block diagram illustrating an example of synchronizing the clocks of a rendering device and a display device. [Figure 15C]

[0045] FIG. 1 is a block diagram illustrating an example of synchronizing the clocks of a rendering device and a display device. [Figure 16]

[0046] 1 is a flowchart illustrating an example process for managing data for transmission, according to some implementations. [Figure 17]

[0047] 1 is a flowchart illustrating an example process for managing data for transmission, according to some implementations. [Figure 18]

[0048] 1 is a block diagram illustrating an example of generating a queue for one or more video frames. [Figure 19]

[0049] 1 is a flowchart illustrating an example process for generating feedback, according to some implementations. [Figure 20]

[0050] 1 is a flowchart illustrating an example process for generating feedback, according to some implementations. [Figure 21]

[0051] FIG. 2 is a block diagram of an exemplary control field. [Figure 22]

[0052] 1 is a flowchart illustrating an example process for supporting simultaneous wireless links with multiple devices. [Figure 23]

[0053] 1A and 1B are sequence diagrams illustrating example timing of XR activity and wireless activity with an AP. DETAILED DESCRIPTION OF THE INVENTION

[0026]

[0054] Like reference numbers and designations in the various drawings indicate like elements.

[0027]

[0055] The following description is directed to several implementations for purposes of describing inventive aspects of the present disclosure. However, those skilled in the art will readily recognize that the teachings herein can be applied in many different ways. The described implementations can be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals according to one or more of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, the IEEE 802.15 standard, the Bluetooth standard defined by the Bluetooth Special Interest Group (SIG), or the Long Term Evolution (LTE), 3G, 4G, or 5G (New Radio (NR)) standards promulgated by the 3rd Generation Partnership Project (3GPP), among others. The described implementations may be implemented in any device, system, or network capable of transmitting and receiving RF signals according to one or more of the following technologies or techniques: code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), single-user (SU) multiple-input multiple-output (MIMO), and multi-user (MU) MIMO. The described implementations may also be implemented using other wireless communication protocols or RF signals suitable for use in one or more of a wireless personal area network (WPAN), a wireless local area network (WLAN), a wireless wide area network (WWAN), or an Internet of Things (IoT) network.

[0028]

[0056] Various implementations generally relate to architectures that provide users with extended reality (XR) experiences. Wireless data associated with XR experiences generally have strict latency and packet loss limits to prevent a degradation of the user experience. For example, packets for video frames or other data (including audio, haptic commands, etc.) must be rendered, delivered to a display device (such as a head-mounted display (HMD), a wearable display, or other such wireless or wired display device), and displayed in near real time. In addition, sensor information from the user's display device or other devices (such as measurements from an inertial measurement unit (IMU)) is used in the rendering, which further complicates the latency requirements. Typical wireless systems are not designed with such limits on data rendering, delivery, and display to guarantee a minimum frame rate and prevent synchronization issues, stutters, or delays for XR experiences.

[0029]

[0057] Some implementations relate more specifically to asynchronous channel access control in a wireless system for devices providing XR experiences. According to some aspects of the present disclosure, a device may adjust the priority of one or more physical layer (PHY) convergence protocol (PLCP) data units (PPDUs) and perform other operations to ensure control of the wireless medium at a particular time while still allowing other devices to communicate on the wireless medium. For example, the device may adjust a back-off counter or adjust one or more enhanced distributed channel access (EDCA) parameters to ensure gaining control of the wireless medium for transmitting the first PPDU of an application file. For one or more subsequent PPDUs of the application file, the device may again adjust a back-off counter or adjust one or more EDCA parameters to allow other devices to gain control of the wireless medium in some scenarios (such as for a display device to return information to the device or for another device to transmit using the shared wireless medium).

[0030]

[0058] Particular implementations may be implemented to realize one or more of the following potential advantages: A rendering device that guarantees control of the wireless medium can enable the rendering device to meet latency requirements for an XR experience. A rendering device that allows other devices to transmit on the wireless medium can enable the wireless medium to be shared in an environment with multiple devices in a basic service set (BSS) or with multiple overlapping basic service sets (OBSS). The rendering device is also configured to enable a display device to provide sensor measurements and other information to the rendering device so that the rendering meets latency and other requirements for an XR experience.

[0031]

[0059] Some implementations relate more specifically to synchronized channel access control in a wireless system for devices providing an XR experience. According to some aspects of the present disclosure, a rendering device can use a target wake-up time (TWT) session to communicate with a display device during one or more TWT service periods (also referred to as windows). The TWT session may be configured and managed to ensure control of the wireless medium to meet latency or other requirements for the XR experience. The TWT window allows other devices to use the wireless medium outside the TWT window.

[0032]

[0060] Particular implementations may be implemented to realize one or more of the following potential advantages: A rendering device that uses TWT to ensure control of the wireless medium can enable the rendering device to meet latency requirements for an XR experience. A rendering device that allows other devices to transmit over the wireless medium can enable the wireless medium to be shared in an environment with multiple devices.

[0033]

[0061] Some implementations relate more specifically to an application-based data transfer mechanism for wireless communication in a synchronous channel-controlled wireless system for an XR experience. According to some aspects of the present disclosure, a rendering device can manage application data to be transmitted, and a display device can manage received application data to ensure that latency requirements for the XR experience are met. Managing data includes generating, queuing, and identifying MSDUs for different video slices to be transmitted, flushing the queues when appropriate, and indicating the flush to the display device. Management at the display device can be flushing a reordering (REO) queue or otherwise managing an REO queue that receives MSDUs from the rendering device.

[0034]

[0062] Particular implementations may be implemented to realize one or more of the following potential advantages: Queue management (including creating and flushing queues) can ensure that latency requirements of an XR experience are met. Queue management can also ensure the removal of stale data that could increase communication latency between rendering and display devices.

[0035]

[0063] Some implementations relate more specifically to providing feedback and adapting an XR experience based on the feedback. According to some aspects of the present disclosure, a rendering device may transmit a PPDU to a display device and attempt to measure latency or packet loss associated with transmitting the PPDU. The display device may transmit a pause data frame or a tracking frame and attempt to measure latency or packet loss associated with transmitting the frame. The rendering device and display device may perform other measurements associated with the XR experience, and the measurements may indicate when the XR experience is affected (such as measuring an increase in latency or packet loss). One or more parameters of the XR experience may be adjusted, and the measurements or adjustments may be indicated to other devices.

[0036]

[0064] Particular implementations may be implemented to realize one or more of the following potential advantages: Generating and providing feedback may enable rendering and display devices to determine when to adjust the XR experience to meet latency or other requirements.

[0037]

[0065] Some implementations relate more specifically to supporting simultaneous wireless links by one or more wireless communication devices. According to some aspects of the present disclosure, a rendering device or relay device includes simultaneous links to an AP or STA and a display device. The rendering device or relay device should support the simultaneous links while giving preferences for communication with the display device (which may be associated with an XR experience having latency and other requirements). The rendering device or relay device can support the simultaneous links and meet the latency and other requirements of the XR experience using multi-link operation (MLO) techniques or an extended set of TWT mode techniques. When the relay device supports simultaneous links with the AP and the display device, rendering of video frames for the XR experience may be performed at the AP or a cloud server behind the AP. Video frames may be sent from the AP to the relay device using a first link and from the relay device to the display device using a second link simultaneously with the first link.

[0038]

[0066] Particular implementations may be implemented to realize one or more of the following potential advantages: Support for simultaneous links may enable a rendering or relay device to continue communicating with an AP or another STA while further supporting an XR experience. In this manner, the rendering or relay device and the display device may be included in a BSS, mesh network, or other environment in which the device communicates with multiple other devices while further supporting an XR experience.

[0039]

[0067] 1A shows a block diagram of an exemplary wireless communication network 100. According to some aspects, the wireless communication network 100 may be an example of a wireless local area network (WLAN), such as a Wi-Fi network (hereinafter referred to as WLAN 100). For example, the WLAN 100 may be a network implementing at least one of the IEEE 802.11 family of standards (such as those defined by the IEEE 802.11-2016 specification or amendments thereto, including, but not limited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be). The WLAN 100 may include multiple wireless communication devices, such as an access point (AP) 102 and multiple stations (STAs) 104. Although only one AP 102 is shown, the WLAN network 100 may also include multiple APs 102.

[0040]

[0068] Each of the STAs 104 may also be referred to as a mobile station (MS), mobile device, mobile handset, wireless handset, access terminal (AT), user equipment (UE), subscriber station (SS), or subscriber unit, among other possibilities. The STAs 104 may represent a variety of devices such as a mobile phone, a personal digital assistant (PDA), other handheld device, a netbook, a notebook computer, a tablet computer, a laptop, a display device (e.g., a TV, a computer monitor, a navigation system, an HMD, among others), a music or other audio or stereo device, a remote control device ("remote control"), a printer, a kitchen or other household appliance, a key fob (e.g., for a passive keyless entry and start (PKES) system), among other possibilities.

[0041]

[0069] A single AP 102 and the associated set of STAs 104 may be referred to as a basic service set (BSS) managed by the respective AP 102. FIG. 1A further illustrates an example coverage area 106 of an AP 102, which may represent a basic service area (BSA) of the WLAN 100. The BSS may be identified to users by a service set identifier (SSID) and to other devices by a basic service set identifier (BSSID), which may be the medium access control (MAC) address of the AP 102. The AP 102 periodically broadcasts a beacon frame (“beacon”) containing the BSSID to allow any STA 104 within wireless range of the AP 102 to “associate” or reassociate with the AP 102 in order to establish or maintain a respective communication link 108 with the AP 102 (hereinafter also referred to as a “Wi-Fi link”). For example, the beacon may include identification of the primary channel used by the respective AP 102, as well as a timing synchronization function for establishing or maintaining timing synchronization with the AP 102. The AP 102 may provide access to external networks to various STAs 104 in the WLAN via respective communication links 108 .

[0042]

[0070] To establish a communication link 108 with an AP 102, each of the STAs 104 is configured to perform passive or active scanning operations (“scans”) on frequency channels in one or more frequency bands (e.g., the 2.4 GHz, 5.0 GHz, 6.0 GHz, or 60 GHz bands). To perform passive scanning, the STAs 104 listen for beacons, which are transmitted by the respective APs 102 at periodic time intervals called target beacon transmission times (TBTTs) (measured in time units (TUs), where one TU may equal 1024 microseconds (μs)). To perform active scanning, the STAs 104 generate and transmit probe requests sequentially on each channel to be scanned and listen for probe responses from the APs 102. Each STA 104 may be configured to identify or select an AP 102 to associate with based on scanning information obtained via passive or active scanning, and to perform authentication and association operations to establish a communication link 108 with the selected AP 102. The AP 102 assigns an association identifier (AID) to the STA 104 at the height of the association operation, and the AP 102 uses the AID to track the STA 104.

[0043]

[0071] As a result of the increasing ubiquity of wireless networks, a STA 104 may have the opportunity to select one of many BSSs within range of the STA or to select from multiple APs 102 that together form an extended service set (ESS) that includes multiple connected BSSs. An extended network station associated with a WLAN 100 may be connected to a wired or wireless distribution system that can allow multiple APs 102 to be connected within such an ESS. Thus, a STA 104 may be covered by more than one AP 102 and may associate with different APs 102 at different times for different transmissions. Additionally, after associating with an AP 102, the STA 104 may also be configured to periodically scan around it to find a more suitable AP 102 with which to associate. For example, a STA 104 moving relative to its associated AP 102 may perform a “roaming” scan to find another AP 102 with more desirable network characteristics, such as a stronger received signal strength indicator (RSSI) or reduced traffic load.

[0044]

[0072] In some cases, the STAs 104 can form a network without any other equipment other than the AP 102 or the STAs 104 themselves. One example of such a network is an ad hoc network (or wireless ad hoc network). An ad hoc network may alternatively be referred to as a mesh network or a peer-to-peer (P2P) network. In some cases, an ad hoc network may be implemented within a larger wireless network, such as a WLAN 100. In such an implementation, the STAs 104 may be able to communicate with each other through the AP 102 using the communication link 108, but the STAs 104 can also communicate with each other directly via a direct wireless communication link 110. Furthermore, two STAs 104 can communicate via the direct communication link 110 regardless of whether both STAs 104 are associated with and served by the same AP 102. In such an ad hoc system, one or more of the STAs 104 can assume the role played by the AP 102 within a BSS. Such a STA 104 may be referred to as a group owner (GO) and can coordinate transmissions within the ad hoc network. Examples of direct wireless links 110 include Wi-Fi direct connections, connections established by using Wi-Fi Tunneled Direct Link Setup (TDLS) links, and other P2P group connections.

[0045]

[0073] The AP 102 and the STAs 104 can function and communicate (via their respective communication links 108) in accordance with the IEEE 802.11 family of standards (such as those defined by the IEEE 802.11-2016 specification or amendments thereto, including, but not limited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be). These standards define WLAN radio and baseband protocols for the PHY and medium access control (MAC) layers. The AP 102 and the STAs 104 send and receive wireless communications between each other (hereinafter also referred to as “Wi-Fi communications”) in the form of Physical Layer Convergence Protocol (PLCP) Protocol Data Units (PPDUs). The APs 102 and STAs 104 in the WLAN 100 can transmit PPDUs over an unlicensed spectrum, which may be a portion of the spectrum including frequency bands traditionally used by Wi-Fi technology, such as the 2.4 GHz band, the 5.0 GHz band, the 60 GHz band, the 3.6 GHz band, and the 900 MHz band. Some implementations of the APs 102 and STAs 104 described herein can also communicate in other frequency bands, such as the 6.0 GHz band, which can support both licensed and unlicensed communications. The APs 102 and STAs 104 can also be configured to communicate on other frequency bands, such as shared licensed frequency bands, where multiple operators may have licenses to operate in the same or one or more overlapping frequency bands.

[0046]

[0074] Each frequency band may include multiple subbands or frequency channels. For example, PPDUs compliant with the IEEE 802.11n, 802.11ac, and 802.11ax standard revisions may be transmitted over the 2.4 GHz and 5.0 GHz bands, each of which is divided into multiple 20 MHz channels. As such, these PPDUs are transmitted over physical channels with a minimum bandwidth of 20 MHz, although larger channels may be formed through channel bonding. For example, PPDUs may be transmitted over physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by bonding multiple 20 MHz channels together.

[0047]

[0075] Each PPDU is a composite structure that includes a PHY preamble and a payload in the form of a PLCP service data unit (PSDU). Information provided in the preamble may be used by a receiving device to decode the subsequent data in the PSDU. In instances where a PPDU is transmitted over bonded channels, the preamble field may be duplicated and transmitted on each of the multiple component channels. A PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble may be used for packet detection, automatic gain control, and channel estimation, among other uses. The legacy preamble may also generally be used to maintain compatibility with legacy devices. The preamble format, coding, and information provided in the non-legacy portion are based on the particular IEEE 802.11 protocol to be used to transmit the payload. A PPDU may also be referred to as a physical layer protocol data unit or PHY protocol data unit.

[0048]

[0076] As described above, devices (such as STA 104) can communicate directly with each other. In the case of an XR experience, a rendering device can communicate directly with a display device. For example, video frame data, audio data, and sensor information may be communicated between devices providing an XR experience to enable rendering and displaying video (or providing audio or other data) synchronized with the movement of the display device.

[0049]

[0077] As used herein, an XR experience refers to one or more of a virtual reality (VR) experience (in which the user may be separated from the real world), an augmented reality (AR) experience (in which a virtual world or virtual information may be overlaid on real-world objects in a display), or a mixed reality (MR) experience (in which virtual and real-world objects may be integrated within a display that may appear seamless to the user) that may be provided to a user. For example, a user may have an HMD (or other display device), audio device, or haptic feedback device (such as haptic gloves or a haptic vest) synchronized to provide information to the user based on the user's movements.

[0050]

[0078] FIG. 1B shows a pictorial diagram of an example group 150 of devices for providing an XR experience. Device 152 is a display device for displaying video frames of the XR experience. Although device 152 is depicted as an HMD, device 152 may be any suitable display device, such as a tablet, smartphone, or glasses. Device 154 is a device for providing video frames to display device 152 via wireless communication link 156. Device 154 may be an example implementation of STA 104 of FIG. 1A. Device 154 may be configured as a software-enabled AP (soft AP or SAP) for display device 152. In some implementations, device 154 is a rendering device configured to render video frames. In some implementations, device 154 is a bridge device for obtaining video frames rendered by a cloud server behind AP 158 or AP 158 itself via wireless communication link 160 and providing the video frames to device 152. Although device 154 is depicted as a smartphone, device 154 may be any suitable device for rendering or providing frames, such as a desktop computer, a laptop computer, or a tablet. Although device 154 is depicted as communicating with AP 158, in some implementations device 154 communicates with another STA in peer-to-peer (P2P) mode. In the provided example, AP may refer to the STA communicatively coupled to device 154 in P2P mode.

[0051]

[0079] In some implementations, device 152 or device 154 is within wireless communication range (also referred to as within range) of one or more other devices. For example, one or more of devices 152 or 154 may be within range of device 162. Device 162 may be within the BSS of AP 158 or may be in another BSS (OBSS) associated with a different AP. Device 162 is configured to communicate on the same wireless medium as device 154 (e.g., within the same frequency band, on the same channel, or on overlapping channels). In this way, devices 154 and 162 share the wireless medium for communicating with other devices.

[0052]

[0080] Many of the following examples describe devices generating, providing, or obtaining PPDUs associated with video frames and video slices of video frames. Aspects of this disclosure also apply to other types of data provided. For example, an application file may be the smallest segment of data recognizable by a receiving device at the application layer. A receiving device cannot process any portion of an application file at the application layer unless all portions of the application file are obtained and spliced ​​to generate the entire application file. One example of an application file includes a video slice of a video frame. As used herein, video slices may also be referred to as video frame slices or slices. When processing video, each frame may be divided into multiple slices (such as pixel columns, pixel rows, groups of macroblocks, or other portions of a video frame), and each video slice may be packaged into one or more PPDUs. While the following examples may refer to video slices and application files, application files may refer to other portions (such as video frames) and may include other data (such as audio, haptic information, documents, application scripts, etc.). In this manner, device 152 may be other than a display device (such as an audio device or a haptic feedback device). As such, the present disclosure is not limited to the management and transport of video data and devices specific thereto.

[0053]

[0081] As described above, many devices (including devices 152 and 154) can provide and obtain PPDUs between each other. For example, AP 158 can provide and obtain PPDUs from device 154. In another example, device 154 can provide PPDUs to device 152. FIGS. 2A-4 depict various exemplary PPDUs. While the figures are described as PPDUs communicated between AP 102 and one or more STAs 104, PPDUs may also be communicated between device 152 and device 154 (e.g., between device 154 as a SAP and device 152 as a STA at the SAP).

[0054]

[0082] 2A illustrates an exemplary protocol data unit (PDU) 200 usable for communication between wireless communication devices. For example, the PDU 200 may be configured as a PPDU. As illustrated, the PDU 200 includes a PHY preamble 202 and a PHY payload 204. For example, the PHY preamble 202 may include a legacy portion that itself includes a legacy short training field (L-STF) 206, a legacy long training field (L-LTF) 208, and a legacy signaling field (L-SIG) 210. The PHY preamble 202 may also include a non-legacy portion (non-legacy field 212). The L-STF 206 generally enables a receiving device to perform automatic gain control (AGC) and coarse timing and frequency estimation. The L-LTF 208 generally enables a receiving device to perform fine timing and frequency estimation, and also to estimate the wireless channel. The L-SIG 210 generally enables a receiving device to determine the duration of a PDU and avoid transmitting on the PDU using the determined duration. For example, the L-STF 206, the L-LTF 208, and the L-SIG 210 may be modulated according to a binary phase shift keying (BPSK) modulation scheme. The payload 204 includes data 214. The payload 204 may be modulated according to a BPSK modulation scheme, a quadrature BPSK (Q-BPSK) modulation scheme, a quadrature amplitude modulation (QAM) modulation scheme, or another suitable modulation scheme. The payload 204 may generally carry upper layer data, for example, in the form of a medium access control (MAC) protocol data unit (MPDU) or an aggregated MPDU (A-MPDU).

[0055]

[0083] 2B shows an example L-SIG field 220 in the PDU of FIG. 2A. The L-SIG 220 includes a data rate field 222, a reserved bit 224, a length field 226, a parity bit 228, and a tail field 230. The data rate field 222 indicates the data rate (note that the data rate indicated in the data rate field 222 may not be the actual data rate of the data carried in the payload 204). The length field 226 indicates the length of the packet, e.g., in bytes. The parity bit 228 is used to detect bit errors. The tail field 230 includes tail bits used by a receiving device to terminate the operation of a decoder (e.g., a Viterbi decoder). The receiving device uses the data rate and length indicated in the data rate field 222 and length field 226 to determine the duration of the packet, e.g., in microseconds (μs).

[0056]

[0084] 3A illustrates another exemplary PDU 300 usable for wireless communication between wireless communication devices. The PDU 300 may be used for SU transmission, OFDMA transmission, or MU-MIMO transmission. The PDU 300 may be formatted as a high-efficiency (HE) WLAN PPDU in accordance with the IEEE 802.11ax amendment to the IEEE 802.11 wireless communication protocol standard. The PDU 300 includes a PHY preamble including a legacy portion 302 and a non-legacy portion 304. The PDU 300 may further include a PHY payload 306 after the preamble, for example, in the form of a PSDU including a data field 324.

[0057]

[0085] The legacy portion 302 of the preamble includes an L-STF 308, an L-LTF 310, and an L-SIG 312. The non-legacy portion 304 includes an L-SIG (RL-SIG) 314, a first HE signal field (HE-SIG-A) 316, an HE short training field (HE-STF) 320, and one or more repetitions of an HE long training field (or symbol) (HE-LTF) 322. For OFDMA or MU-MIMO communications, the second portion 304 further includes a second HE signal field (HE-SIG-B) 318 that is coded separately from the HE-SIG-A 316. Like the L-STF 308, L-LTF 310, and L-SIG 312, the information in the RL-SIG 314 and the HE-SIG-A 316 may be duplicated and transmitted in each of the component 20 MHz channels in an illustrative example involving the use of a bonding channel. In contrast, the content in HE-SIG-B318 is unique to each 20 MHz channel and can be targeted to unique STAs 104 .

[0058]

[0086] The RL-SIG 314 may indicate to the HE-compatible STAs 104 that the PDU 300 is an HE PPDU. The AP 102 may use the HE-SIG-A 316 to identify and notify the multiple STAs 104 that the AP has scheduled UL or DL ​​resources for them. For example, the HE-SIG-A 316 may include a resource allocation subfield indicating the resource allocation for the identified STAs 104. The HE-SIG-A 316 may be decoded by each HE-compatible STA 104 served by the AP 102. In the case of a MU transmission, the HE-SIG-A 316 further includes information usable by each identified STA 104 to decode the associated HE-SIG-B 318. For example, the HE-SIG-A 316 may indicate the frame format, including the location and length of the HE-SIG-B 318, the available channel bandwidth, and the modulation and coding scheme (MCS), among other examples. The HE-SIG-A 316 may also include HE WLAN signaling information usable by STAs 104 other than the identified STA 104.

[0059]

[0087] The HE-SIG-B 318 may carry STA-specific scheduling information, such as, for example, a STA-specific (or "user-specific") MCS value and STA-specific RU allocation information. In the context of DL MU-OFDMA, such information enables each STA 104 to identify and decode the corresponding resource unit (RU) in the associated data field 324. Each HE-SIG-B 318 includes a common field and at least one STA-specific field. The common field may indicate RU allocations for multiple STAs 104, including RU allocations in the frequency domain, which RUs are allocated for MU-MIMO transmissions, which RUs correspond to MU-OFDMA transmissions, and the number of users in the allocation, among other examples. The common field may be coded with common bits, CRC bits, and tail bits. The user-specific field may be assigned to a particular STA 104 and may be used to schedule specific RUs and indicate the scheduling to other WLAN devices. Each user-specific field may include multiple user block fields. Each user block field may include two user fields containing information for two respective STAs to decode the respective RU payloads in data field 324.

[0060]

[0088] 3B illustrates another exemplary PDU 350 usable for wireless communication between wireless communication devices. The PDU 350 may be used for SU transmission, OFDMA transmission, or MU-MIMO transmission. The PDU 350 may be formatted as an Ultra High Throughput (EHT) WLAN PPDU in accordance with the IEEE 802.11be amendment to the IEEE 802.11 wireless communication protocol standard, or as a PPDU compliant with any later (post-EHT) version of a new wireless communication protocol that complies with a future IEEE 802.11 wireless communication protocol standard or other wireless communication standard. The PDU 350 includes a PHY preamble including a legacy portion 352 and a non-legacy portion 354. The PDU 350 may further include a PHY payload 356 after the preamble, for example, in the form of a PSDU including a data field 374.

[0061]

[0089] The legacy portion 352 of the preamble includes an L-STF 358, an L-LTF 360, and an L-SIG 362. The non-legacy portion 354 of the preamble includes an RL-SIG 364 and multiple wireless communication protocol version-dependent signal fields following the RL-SIG 364. For example, the non-legacy portion 354 may include a general purpose signal field 366 (referred to herein as “U-SIG 366”) and an EHT signal field 368 (referred to herein as “EHT-SIG 368”). One or both of the U-SIG 366 and the EHT-SIG 368 may be configured as and carry version-dependent information for other wireless communication protocol versions beyond EHT. The non-legacy portion 354 further includes an additional short training field 370 (referred to herein as “EHT-STF 370,” although it may be configured for and carry version-dependent information for other wireless communication protocol versions beyond EHT) and one or more additional long training fields 372 (referred to herein as “EHT-LTF 372,” although it may be configured for and carry version-dependent information for other wireless communication protocol versions beyond EHT). Like the L-STF 358, L-LTF 360, and L-SIG 362, information in the U-SIG 366 and EHT-SIG 368 may be duplicated and transmitted in each of the component 20 MHz channels in examples involving the use of a bonded channel. In some implementations, the EHT-SIG 368 may additionally or alternatively carry information in one or more non-primary 20 MHz channels that are different from the information carried in the primary 20 MHz channel.

[0062]

[0090] The EHT-SIG 368 may include one or more joint encoding symbols and may be encoded in a block different from the block in which the U-SIG 366 is encoded. The EHT-SIG 368 may be used by an AP to identify and notify multiple STAs 104 that the AP has scheduled UL or DL ​​resources for them. The EHT-SIG 368 may be decoded by each compatible STA 104 served by the AP 102. The EHT-SIG 368 may generally be used by a receiving device to interpret bits in the data field 376. For example, the EHT-SIG 368 may include RU allocation information, spatial stream configuration information, and per-user signaling information such as an MCS, among other examples. The EHT-SIG 368 may further include a cyclic redundancy check (CRC) (e.g., 4 bits) and a tail (e.g., 6 bits), which may be used for a binary convolutional code (BCC). In some implementations, the EHT-SIG 368 may include one or more code blocks, each including a CRC and a tail. In some aspects, each of the code blocks may be coded separately.

[0063]

[0091] The EHT-SIG 368 may carry STA-specific scheduling information, such as a user-specific MCS value and user-specific RU allocation information. The EHT-SIG 368 may generally be used by a receiving device to interpret bits in the data field 376. In the context of DL MU-OFDMA, such information enables each STA 104 to identify and decode the corresponding RU in the associated data field 376. Each EHT-SIG 368 may include a common field and at least one user-specific field. The common field may indicate RU distribution for multiple STAs 104, indicate RU allocation in the frequency domain, indicate which RUs are allocated to MU-MIMO transmissions, which RUs correspond to MU-OFDMA transmissions, and the number of users in the allocation, among other examples. The common field may be encoded with common bits, CRC bits, and tail bits. The user-specific field may be assigned to a specific STA 104 and may be used to schedule specific RUs and indicate the scheduling to other WLAN devices. Each user-specific field may contain multiple user block fields, which may include, for example, two user fields containing information for two respective STAs to decode their respective RU payloads.

[0064]

[0092] The presence of RL-SIG 364 and U-SIG 366 may indicate to EHT or later version-compliant STAs 104 that PDU 350 is an EHT PPDU or a PPDU that complies with any later (post-EHT) version of a new wireless communications protocol that complies with a future IEEE 802.11 wireless communications protocol standard. For example, U-SIG 366 may be used by a receiving device to interpret bits in EHT-SIG 368 or one or more of data fields 376.

[0065]

[0093] 4 illustrates an exemplary PPDU 400 that can be used for communication between the AP 102 and several STAs 104. As described above, each PPDU 400 includes a PHY preamble 402 and a PSDU 404. Each PSDU 404 can carry one or more MAC protocol data units (MPDUs). For example, each PSDU 404 can carry an aggregated MPDU (A-MPDU) 408 that includes an aggregation of multiple A-MPDU subframes 406. Each A-MPDU subframe 406 may include a MAC delimiter 410 and a MAC header 412 before an accompanying MPDU 414 that contains the data portion (the "payload" or "frame body") of the A-MPDU subframe 406. The MPDU 414 can carry one or more MAC service data units (MSDU) subframes 416. For example, the MPDU 414 may carry an aggregated MSDU (A-MSDU) 418 that includes multiple MSDU sub-frames 416. Each MSDU sub-frame 416 includes a corresponding MSDU 420 preceded by a sub-frame header 422.

[0066]

[0094] Referring again to the A-MPDU subframe 406, the MAC header 412 may include several fields containing information that define or indicate characteristics or attributes of the data encapsulated within the frame body 414. The MAC header 412 also includes several fields that indicate addresses for the data encapsulated within the frame body 414. For example, the MAC header 412 may include a combination of a source address, a transmitter address, a receiver address, or a destination address. The MAC header 412 may include a frame control field containing control information. The frame control field specifies the frame type, e.g., a data frame, a control frame, or a management frame. The MAC header 412 may further include a duration field that indicates a duration extending from the end of the PPDU to the end of the acknowledgement (ACK) of the last PPDU to be transmitted by the wireless communication device (e.g., a block ACK (BA) for an A-MPDU). The use of the duration field serves to secure the wireless medium for the indicated duration, thus establishing a NAV. Each A-MPDU subframe 406 may also include a frame check sequence (FCS) field 424 for error detection. For example, the FCS field 424 may include a cyclic redundancy check (CRC).

[0067]

[0095] As described above, the AP 102 and the STAs 104 may support multi-user (MU) communications, i.e., simultaneous transmissions from one device to each of multiple devices (e.g., multiple simultaneous downlink (DL) communications from the AP 102 to corresponding STAs 104), or simultaneous transmissions from multiple devices to a single device (e.g., multiple simultaneous uplink (UL) transmissions from corresponding STAs 104 to the AP 102). To support MU transmissions, the AP 102 and the STAs 104 may utilize multi-user multiple-input multiple-output (MU-MIMO) and multi-user orthogonal frequency division multiple access (MU-OFDMA) techniques.

[0068]

[0096] In a MU-OFDMA system, the available frequency spectrum of a wireless channel may be divided into multiple resource units (RUs), each containing several different frequency subcarriers (“tones”). Different RUs may be allocated or assigned by the AP 102 to different STAs 104 at a particular time. The size and distribution of the RUs may be referred to as the RU allocation. In some implementations, RUs may be allocated at 2 MHz intervals, so the smallest RU may contain 26 tones, consisting of 24 data tones and 2 pilot tones. As a result, in a 20 MHz channel, a maximum of 9 RUs (e.g., a 2 MHz, 26-tone RU) may be allocated (as some tones are reserved for other purposes). Similarly, in a 160 MHz channel, a maximum of 74 RUs may be allocated. Larger RUs with 52, 106, 242, 484, and 996 tones may also be allocated. For example, adjacent RUs may be separated by a null subcarrier (such as a DC subcarrier) to reduce interference between adjacent RUs, to reduce the DC offset of the receiver, and to avoid transmit center frequency leakage.

[0069]

[0097] For UL MU transmissions, the AP 102 may transmit a trigger frame to initiate and synchronize UL MU-OFDMA or UL MU-MIMO transmissions from multiple STAs 104 to the AP 102. Such a trigger frame may therefore enable multiple STAs 104 to send UL traffic to the AP 102 simultaneously in time. The trigger frame may address one or more STAs 104 via their respective association identifiers (AIDs) and may assign each AID (and therefore each STA 104) one or more RUs that may be used to send UL traffic to the AP 102. The AP may also designate one or more random access (RA) RUs for which unscheduled STAs 104 may contend.

[0070]

[0098] 5 shows a block diagram of an exemplary wireless communication device 500. In some implementations, the wireless communication device 500 may be an example of a device for use in an STA, such as one of the STAs 104 described above with reference to FIG. 1A or one or both of the devices 152 or 154 with reference to FIG. 1B. In some implementations, the wireless communication device 500 may be an example of a device for use in an AP, such as the AP 102 described above with reference to FIG. 1A. The wireless communication device 500 is capable of transmitting (or outputting for transmission) and receiving wireless communications (e.g., in the form of wireless packets). For example, a wireless communication device may be configured to transmit and receive packets in the form of PPDUs and MPDUs that comply with IEEE 802.11 standards, such as those defined by the IEEE 802.11-2016 specification or amendments thereof, including, but not limited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be.

[0071]

[0099] The wireless communication device 500 may be or include a chip, system-on-chip (SoC), chipset, package, or device that includes one or more modems 502, e.g., Wi-Fi (IEEE 802.11 compliant) modems. In some implementations, the one or more modems 502 (collectively “modems 502”) further include a WWAN modem (e.g., a 3GPP 4G LTE or 5G compliant modem). In some implementations, the wireless communication device 500 also includes one or more radios 504 (collectively “radios 504”). In some implementations, the wireless communication device 500 further includes one or more processors, processing blocks, or processing elements 506 (collectively “processors 506”) and one or more memory blocks or memory elements 508 (collectively “memory 508”).

[0072]

[0100] The modem 502 may include, for example, an intelligent hardware block or device such as an application specific integrated circuit (ASIC), among other possibilities. The modem 502 is generally configured to implement a PHY layer. For example, the modem 502 is configured to modulate packets and output the modulated packets to the radio 504 for transmission over a wireless medium. The modem 502 is similarly configured to obtain modulated packets received by the radio 504 and demodulate the packets to provide demodulated packets. In addition to the modulator and demodulator, the modem 502 may further include digital signal processing (DSP) circuitry, an automatic gain control (AGC), a coder, a decoder, a multiplexer, and a demultiplexer. For example, while in a transmit mode, data obtained from the processor 506 is provided to the coder, which encodes the data to provide coded bits. The coded bits are mapped to points in a modulation constellation (using a selected MCS) to provide modulated symbols. The modulated symbols are then encoded into N SS spatial streams or N STS The modulated symbols in each spatial or space-time stream may be multiplexed, transformed through an inverse fast Fourier transform (IFFT) block, and then provided to a DSP circuit for Tx windowing and filtering. The digital signal may be provided to a digital-to-analog converter (DAC). The resulting analog signal may be provided to a frequency upconverter and ultimately to the radio 504. In an implementation involving beamforming, the modulated symbols in each spatial stream are precoded via a steering matrix before providing them to the IFFT block.

[0073]

[0101] During the receive mode, the digital signal received from the radio 504 is provided to a DSP circuit configured to acquire the received signal, for example, by detecting the presence of a signal and estimating initial timing and frequency offset. The DSP circuit is further configured to digitally condition the digital signal, for example, using channel (narrowband) filtering, analog impairment adjustment (such as correcting for I / Q imbalance), and applying a digital gain to ultimately obtain a narrowband signal. The output of the DSP circuit may be provided to an AGC, which is configured to use information extracted from the digital signal, for example, in one or more received training fields, to determine an appropriate gain. The output of the DSP circuit is also coupled to a demodulator, which is configured to extract modulated symbols from the signal and, for example, calculate a log-likelihood ratio (LLR) for each bit position of each subcarrier in each spatial stream. The demodulator may be coupled to a decoder, which may be configured to process the LLR to provide decoded bits. The decoded bits from all of the spatial streams are provided to a demultiplexer for demultiplexing. The demultiplexed bits may be descrambled and provided to a MAC layer (processor 506) for processing, evaluation, or interpretation.

[0074]

[0102] The radio 504 generally includes at least one radio frequency (RF) transmitter (or “transmitter chain”) and at least one RF receiver (or “receiver chain”), which may be combined into one or more transceivers. For example, the RF transmitter and RF receiver may each include various DSP circuits, including at least one power amplifier (PA) and at least one low-noise amplifier (LNA). The RF transmitter and RF receiver may then be coupled to one or more antennas. For example, in some implementations, the wireless communication device 500 may include or be coupled to multiple transmit antennas (each with a corresponding transmit chain) and multiple receive antennas (each with a corresponding receive chain). Symbols output from the modem 502 are provided to the radio 504, which transmits the symbols via the coupled antenna. Similarly, symbols received via the antennas are obtained by the radio 504, which provides the symbols to the modem 502.

[0075]

[0103] The processor 506 may include, for example, an intelligent hardware block or device such as a processing core, processing block, central processing unit (CPU), microprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), programmable logic device (PLD) such as field programmable gate array (FPGA), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor 506 processes information received via the radio 504 and modem 502 and processes information to be output via the modem 502 and radio 504 for transmission over a wireless medium. For example, the processor 506 may implement a control plane and MAC layer configured to perform various operations related to the generation and transmission of MPDUs, frames, or packets. The MAC layer is configured to perform or facilitate frame coding and decoding, spatial multiplexing, space-time block coding (STBC), beamforming, and OFDMA resource allocation, among other operations or techniques. In some implementations, the processor 506 can generally control the modem 502 to cause the modem to perform the various operations described above.

[0076]

[0104] The memory 508 may include a tangible storage medium, such as a random access memory (RAM) or a read-only memory (ROM), or a combination thereof. The memory 508 may also store non-transitory processor or computer-executable software (SW) code containing instructions that, when executed by the processor 506, cause the processor to perform various operations described herein for wireless communication, including generating, transmitting, receiving, and interpreting MPDUs, frames, or packets. For example, various functions of the components disclosed herein, or various blocks or steps of the methods, operations, processes, or algorithms disclosed herein, may be implemented as one or more modules of one or more computer programs.

[0077]

[0105] 6A shows a block diagram of an example AP 602. For example, the AP 602 may be an example implementation of the AP 102 described with reference to FIG. 1A or the AP 158 described with reference to FIG. 1B. The AP 602 includes a wireless communication device (WCD) 610. For example, the wireless communication device 610 may be an example implementation of the wireless communication device 500 described with reference to FIG. 5. The AP 602 also includes multiple antennas 620 coupled with the wireless communication device 610 for transmitting and receiving wireless communications. In some implementations, the AP 602 further includes an application processor 630 coupled with the wireless communication device 610 and a memory 640 coupled with the application processor 630. The AP 602 further includes at least one external network interface 650 that enables the AP 602 to communicate with a core network or a backhaul network to gain access to external networks, including the Internet. For example, the external network interface 650 may include one or both of a wired (e.g., Ethernet) network interface and a wireless network interface (such as a WWAN interface). Some of the aforementioned components may communicate with some other of the components directly or indirectly via at least one bus. The AP 602 further includes a housing that encloses the wireless communication device 610, the application processor 630, the memory 640, at least a portion of the antenna 620, and the external network interface 650.

[0078]

[0106] 6B shows a block diagram of an exemplary STA 604. For example, the STA 604 may be an exemplary implementation of the STA 104 described with reference to FIG. 1A or one or more of the devices 152 or 154 described with reference to FIG. 1B. The STA 604 includes a wireless communication device 615. For example, the wireless communication device 615 may be an exemplary implementation of the wireless communication device 500 described with reference to FIG. 5. The STA 604 also includes one or more antennas 624 coupled with the wireless communication device 615 for transmitting and receiving wireless communications. The STA 604 further includes an application processor 635 coupled with the wireless communication device 615 and a memory 645 coupled with the application processor 635. In some implementations, the STA 604 further includes a user interface (UI) 655 (e.g., a touchscreen or keypad) and a display 665 that may be integrated with the UI 655 to form a touchscreen display. In some implementations, the STA 604 may further include one or more sensors 675, such as, for example, one or more inertial sensors, accelerometers, temperature sensors, pressure sensors, or altitude sensors. Some of the aforementioned components may communicate with some other of the components directly or indirectly via at least one bus. The STA 604 further includes a housing enclosing the wireless communication device 615, the application processor 635, the memory 645, at least a portion of the antenna 624, the UI 655, and the display 665.

[0079]

[0107] In some implementations of device 152, STA 604 may be, include, or be coupled to an HMD or other device used to provide an XR experience to a user (such as an audio device (including headphones), a haptic device, a haptic vest, etc.). If STA 604 includes an HMD, display 665 may be integrated into glasses, a monocular, or other head-mounted unit. In this manner, STA 604 may be a display device for an XR experience. Sensors 675 may include an inertial measurement unit (IMU), which may include a gyroscope, an accelerometer, or other sensors, to determine the orientation or movement of STA 604. For example, an IMU may be included in an HMD to measure the orientation or movement of the HMD as a user moves their head. Device orientation information (and sometimes movement information) may be referred to as pose information. The IMU measures the pose information at defined intervals (such as every 100 microseconds (μs)).

[0080]

[0108] In some implementations, a display device (such as an HMD) includes one or more cameras among its sensors 675. The one or more cameras may be used by the display device to generate tracking frames or other tracking information to be used by the rendering device in generating video frames. The tracking information may include markers or points within a user's field of view (FOV) in the HMD that are used to determine the location of information or objects in the video frames. For example, a marker indicating the location of a building door may be used to render a video frame to overlay the name of a business, business hours, etc. near the door in the user's FOV. In this manner, UL traffic from the display device to the rendering device may include pose data frames (also called pause frames) and tracking frames. While rendering is described in the examples as being based on pause frames, rendering may also be based on one or more tracking frames from the display device.

[0081]

[0109] In some implementations of the device 154, the STA 604 may be configured as a SAP for the device 152. Software for enabling the STA 604 to act as a SAP may be stored in the memory 645 (or suitable memory of the STA 604) and executed by the application processor 635. In this manner, the STA 604 (acting as a SAP) can perform some of the functions of the AP 602.

[0082]

[0110] The rendering device for the XR experience may be device 154 (which may be STA 604 acting as an SAP), AP 158 (with device 154 acting as a bridge device), or a combination of both. AP 602 may be referred to in examples herein describing a rendering device for only an XR experience for clarity and brevity when describing aspects of the present disclosure. The display device for the XR experience is device 152. STA 604 may be referred to in examples herein describing a display device for an XR experience. In some implementations, the rendering device and the display device may communicate over the 6 GHz frequency band (e.g., to transmit PPDUs or pause packets between the devices). However, any suitable frequency band (e.g., 5 GHz or other frequency bands defined in the IEEE 802.11 standard) may be used. The downlink (DL) transmission rate from the rendering device to the display device may be at least 50 megabits per second (Mbps) to 120 Mbps to support 45 to 60 frames per second (fps), and the uplink (UL) transmission rate from the display device to the rendering device may be a minimum of 0.5 Mbps to 20 Mbps. The device may be configured to have one-way latency (eg, on the DL or on the UL) of less than 10 ms.

[0083]

[0111] The application processor 630 or 635 may be configured to execute one or more host layers of the Open Systems Interconnection (OSI) model, including the application layer. As used herein, the application layer of a rendering device may refer to the application processor 630 or other components that perform operations at the application layer. An application layer for an XR experience on a rendering device may include rendering for an XR application executed by the rendering device. As used herein, the application layer of a display device may refer to the application processor 635 or other components that perform operations at the application layer. An application layer for an XR experience on a display device may include displaying video for an XR application executed by the display device.

[0084]

[0112] The WCD 610 or 615 may be configured to perform one or more layers of the OSI model, such as the network layer, the medium access control layer (MAC), or the physical layer (PHY). One or more of the layers may be referred to as a wireless layer or a Wi-Fi layer. As used herein, the wireless layer of a rendering device may refer to the WCD 610 performing operations at the wireless layer. As used herein, the wireless layer of a display device may refer to the WCD 615 performing operations at the wireless layer.

[0085]

[0113] The process from measuring the pose information to rendering video frames based on the pose information may be referred to as motion-to-render (M2R). The process from rendering video frames to displaying the video frames may be referred to as render-to-photon (R2P). The process from measuring the pose information to rendering video frames using the pose information and displaying the video frames may be referred to as motion-to-render-to-photon (M2R2P). In some implementations, the rendering device and the display device are configured such that M2R2P is less than 70 ms (e.g., between 50 ms and 70 ms).

[0086]

[0114] 7 shows a sequence diagram 700 illustrating exemplary M2R2P operations. The exemplary M2R2P operations refer to one video frame, and the M2R2P operations may be repeated for each video frame. The timing of the operations is not drawn to scale, and some operations may be slightly slower than previous operations or may take longer or shorter amounts of time than depicted.

[0087]

[0115] The IMU of the display device generates multiple IMU measurements (702). Each line represents an IMU measurement. As depicted, the IMU measurements may be periodic, independent of when a video frame is to be rendered or displayed. For a video frame to be rendered or displayed, the display device generates an IMU measurement packet (704) from one of the IMU measurements. The selected IMU measurement may be the current IMU measurement when a request for the packet is obtained from the rendering device or when the packet is to be generated based on a defined periodicity for the packet. After generating the IMU measurement packet, the display device may transmit the packet to the rendering device during a UL transmission 706 of the transmit / receive window 708. The rendering device may render and encode a video frame based on the pause information (or other information) obtained in the IMU measurement packet (710). The rendering device may generate one or more PPDUs to include the encoded video frame data and transmit the one or more PPDUs to the display device during a DL transmission 712 of the transmit / receive window 708. The timing of the UL transmission 706 and DL transmission 712 includes over-the-air (OTA) time and processing time at the wireless layer. The display device may decode the video frames (714). In some implementations, the display device may capture the decoded frame information using a jitter buffer (716) to smooth the video frame generation time to prevent jitter in the video. For example, the jitter buffer is used to ensure a fixed playback schedule of the video frames by removing variations in decoding time. In some implementations, the display device may perform asynchronous time warping (ATW) (718) on one or more video frames to increase the perceived frame rate of the displayed video or to compensate for latency between when the IMU measurements are made and when the video frames are displayed.The display device displays (720) the video frame, which is the video frame based on the IMU measurements selected in 702.

[0088]

[0116] As used herein, IMU measurements may be referred to as pause information, and IMU measurement packets may be referred to as pause packets or pause data packets. The pause information may include device orientation, referring to orientation, device motion, device location, or other characteristics of a particular device location used to generate an appropriate video frame to be displayed by the device. In FIG. 7, pause packets are depicted as being generated once per video frame. In some implementations, pause packets may be generated more frequently than once per video frame. For example, 60 fps video corresponds to 16.67 ms per video frame, and a display device may generate a pause packet every 2 ms. In this manner, at least eight pause packets may be generated during the display of one video frame. The display device may select the most recent pause packet when a pause packet is to be provided to the rendering device. The rendering device may generate a video frame based on the obtained pause packet. In some implementations, the most recent pause packet may not be obtained by the rendering device for DL ​​transmission from the rendering device to the display device. The rendering device may generate a video frame using the most recently obtained pause packet. To reduce the latency between a pause packet and rendering a video frame, a display device can provide multiple pause packets while rendering and encoding a previous video frame. In some other implementations, the transmission of pause packets is synchronized with the rendering and encoding. In this way, the timing of sending pause packets is guaranteed so that the rendering device acquires the pause packet to render the next video frame.

[0089]

[0117] With respect to access to the wireless medium, the M2R2P latency requirements of an XR experience can cause the wireless system to provide preference to rendering and display devices for obtaining control of the wireless medium. Preference for rendering and display devices may refer to other devices in the same BSS or one or more devices from an OBSS within range of the rendering or display device. Obtaining control of the wireless medium can refer to a device (such as a rendering device) obtaining control of one or more wireless channels for transmission or reception. Access to one or more wireless channels can be asynchronous (where devices compete for the wireless medium during a contention window) or synchronous (where one or more APs coordinate access to the wireless medium between devices). As described in the following examples, providing preference may include adjusting one or more contention parameters (such as a backoff timer value or one or more EDCA parameters) or adjusting the transmit / receive window between the rendering and display devices to prevent interference by one or more other devices transmitting on the wireless medium. Asynchronous control of the wireless medium is sometimes referred to as asynchronous channel access control. Synchronized control of the wireless medium may be referred to as synchronized channel access control. The wireless system may also be configured to prevent collisions between DL and UL traffic between a rendering device and a display device, prevent interference between a link between the rendering device and an AP and a link between the rendering device and a display device, or enable power savings in the rendering device or the display device based on the channel access control.

[0090]

[0118] 8 shows a flowchart illustrating an example process 800 for asynchronous channel access control, according to some implementations. Control of the wireless medium and other operations in the example process may be performed by a device (such as device 154 in FIG. 1B) or a wireless communication device implemented within a device (such as WCD 615 in FIG. 6B). The device performing the operations may be a rendering device for an XR experience.

[0091]

[0119] At 802, a device obtains control of a wireless medium. The control of the wireless medium is associated with a first priority for transmitting a first PPDU of an application file from the device to a second device over the wireless medium (804). The first priority is different from a second priority for transmitting data from the second device to the device over the wireless medium (806). As discussed above, an application file may be the smallest portion of data that is whole (without missing portions) that can be processed by a device.

[0092]

[0120] At 808, the device provides the first PPDU to the second device.

[0093]

[0121] At 810, the device provides one or more subsequent PPDUs of the application file to the second device. In some implementations, the second device is a display device, and the application file is associated with a video frame (e.g., including a video slice of the video frame). In this manner, multiple PPDUs (including the first PPDU and one or more subsequent PPDUs) may be associated with the video frame. The action of providing the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium (812).

[0094]

[0122] The first priority may be associated with a first set of EDCA parameters, the second priority may be associated with a second set of EDCA parameters, and the third priority may be associated with a third set of EDCA parameters. The EDCA parameters may include one or more of an arbitration interframe spacing number (AIFSN), a minimum contention window (CWmin), or a maximum contention window (CWmax) used by a rendering or display device to determine when to transmit to other devices (e.g., based on a CW mechanism defined in the IEEE 802.11 standard). For example, the first priority may be associated with aggressive EDCA parameters to gain control of the wireless medium compared to all other devices competing for the wireless medium. In a specific example, the CWmin and CWmax for the first priority are a first length that is smaller than other CWs used by other devices. Additionally or alternatively, the AIFSN for the first priority is a smaller number than other AIFSNs used by other devices. For example, a smaller number may indicate a traffic priority based on the classification of the packet to be transmitted (such as high priority or best effort). Lower or higher priority may refer to a larger or smaller AIFSN, respectively. For a first priority indicating the highest priority traffic to be transmitted, the AIFSN may be 1, and for a third priority indicating traffic having a priority lower than the first priority, the AIFSN may be 3. For a second priority indicating traffic having a priority higher than the third priority and lower than the first priority, the AIFSN may be 2. In some implementations, a rendering device may reserve a CW for both the rendering device and the display device. In this manner, CWmin and CWmax may be set to 0 for the display device.

[0095]

[0123] The first priority may also be associated with a first backoff counter value for contention on the wireless medium, the second priority may also be associated with a second backoff counter value for contention on the wireless medium, and the third priority may also be associated with a third backoff counter value for contention on the wireless medium. The backoff counter is set to the backoff counter value, and the backoff counter counts down to 0 for a transmit opportunity (TXOP) on the wireless medium. When the backoff counter reaches 0, the device attempts to transmit on the wireless medium (e.g., performs carrier sensing to determine if the wireless medium is unoccupied and transmits on the wireless medium based on the carrier sensing). A shorter backoff counter value corresponds to the device attempting to transmit on the wireless medium sooner. In some implementations, the first backoff counter value is less than the second backoff counter value, and the second backoff counter value is less than the third backoff counter value. In this way, a first PPDU (e.g., for a video frame) from the rendering device may be attempted to be transmitted earlier than data (e.g., a pause packet) from the display device, which may in turn be attempted to be transmitted earlier than one or more subsequent PPDUs (e.g., for video frames) from the rendering device. In some implementations, the first backoff counter value may be 0, the second backoff counter value may indicate a time period greater than a short inter-frame space (SIFS), and the third backoff counter value may indicate a time period greater than the time period indicated by the second backoff counter value.

[0096]

[0124] The rendering device provides a first PPDU associated with a first priority and one or more subsequent PPDUs associated with a third priority. The rendering device can configure itself to adjust one or more EDCA parameters from a first set of parameters to a third set of parameters after transmitting the first PPDU. The rendering device can also adjust a back-off counter value from a first value to a third value (e.g., by setting the back-off counter to the third value for the subsequent PPDU) after transmitting the first PPDU. Using different sets of EDCA parameters and back-off counter values, the rendering device has a higher probability of transmitting the first PPDU to other devices (including the display device and other devices in the OBSS). Conversely, the display device can transmit data (e.g., a pause packet) to the rendering device before one or more subsequent PPDUs are transmitted to the display device.

[0097]

[0125] In some implementations, a rendering device uses a request to send (RTS) / clear to send (CTS (clear to send)) mechanism to gain control of and reserve the wireless medium. For example, the rendering device may provide (e.g., broadcast) a first RTS frame to gain control of the wireless medium. The RTS frame may be transmitted based on a first back-off counter value. The first RTS frame includes an indication of a network allocation vector (NAV) to maintain control of the wireless medium for a first period of time. The NAV indicates the period of time for which the wireless medium has been reserved by the device. In this manner, other devices within range of the rendering device receive the RTS frame, process the RTS frame, and set their NAVs to the indicated amount of time to cease transmitting on the wireless medium for the indicated amount of time. An exemplary RTS / CTS mechanism and transmission of data between a rendering device and a display device are described in more detail below with reference to FIG. 10.

[0098]

[0126] Figure 8 depicts an exemplary process from the perspective of a rendering device. Figure 9 depicts an exemplary process from the perspective of a display device.

[0099]

[0127] 9 shows a flowchart illustrating an example process 900 for asynchronous channel access control, according to some implementations. The operations in the example process may be performed by a device (such as device 152 in FIG. 1B) or a wireless communication device implemented within a device (such as WCD 615 in FIG. 6B). The device performing the operations may be a display device of an XR experience.

[0100]

[0128] At 902, a device obtains a first PPDU of an application file from a second device over a wireless medium. In the case of an XR experience, the device may be a display device, and the second device may be a rendering device. The second device may refer to an infrastructure AP, an SAP (such as device 154 in FIG. 1B acting as an SAP), or another device for providing the PPDU of the application file to the device (in the following examples with reference to FIGS. 9 and 10, the second device may be referred to as an AP or a rendering device). In some implementations, the application file includes one or more video slices of a video frame.

[0101]

[0129] The second device obtains control of the wireless medium to provide a first PPDU (904), and the control of the wireless medium is associated with a first priority for transmitting the first PPDU over the wireless medium (906). The first priority is different from a second priority for transmitting data from the device to the second device over the wireless medium (908).

[0102]

[0130] At 910, the device retrieves one or more subsequent PPDUs of the application file from the second device. The action of retrieving the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium (912). As described above, the priority may be associated with one or more of a backoff counter value or a set of EDCA parameters.

[0103]

[0131] FIG. 10 shows a sequence diagram 1000 illustrating an example transmission between devices for an XR experience. The devices are depicted as a rendering device and a display device for purposes of explanation, but the described concepts may be extended to other types of devices. The start time t0 may indicate the start of a CW or other moment when the rendering device should start its backoff (BO) counter (such as when one or more PPDUs are ready for transmission at the rendering device). The BO counter of the rendering device is set to a first backoff counter value (first BO value) associated with the first PPDU of an application file (such as an application file for a video frame). When the display device should start its BO counter, the BO counter of the display device is set to a second backoff counter value (second BO value) associated with data to be transmitted from the display device to the rendering device.

[0104]

[0132] After a BO time period based on the first BO value (time t1), the rendering device can send an RTS frame. The end of the RTS frame on the wireless medium is at time t2. The display device sends a CTS frame to the rendering device after a SIFS duration at time t2 (time t3). Sending the CTS frame may be based on the display device obtaining an RTS frame (which may indicate that the wireless medium is free) and the display device being ready to obtain data from the rendering device. The end of the CTS frame on the wireless medium is at time t4. The rendering device sends a first PPDU of an application file (e.g., an application file for a video frame) to the display device after a SIFS duration at time t4 (time t5).

[0105]

[0133] Although not depicted, if the CTS frame is not acquired by the rendering device, the rendering device may again wait a BO time period and attempt to retransmit the RTS frame to the display device. In some implementations, the rendering device is configured to retry transmitting the RTS frame five times before indicating that the transmission of the RTS frame failed. In some implementations, the RTS / CTS mechanism before securing the wireless medium is associated with a video frame. If the transmission of the RTS fails (and the rendering device is unable to gain control of the wireless medium), the rendering device may cease providing the associated frame to the display device and attempt to gain control of the wireless medium to provide the display device with the next frame. If a video frame is skipped, the display device may repeat the previously displayed video frame or may not display the video frame at the time the missed video frame should have been displayed. In some implementations, if a video frame is skipped, one or more parameters of the DL communication (such as the modulation and coding scheme (MCS), frame rate, forward error correction (FEC)) may be adjusted to attempt to reduce bandwidth requirements and increase the probability of delivering the video frame to the display device.

[0106]

[0134] Referring again to FIG. 10, the end of the first PPDU on the wireless medium is at time t6. The display device sends a block acknowledgement (BA) to the rendering device after the SIFS duration of time t6 (time t7). The BA indicates that the display device has acquired the first PPDU. The BA may also indicate whether any portions (e.g., one or more MPDUs) were corrupted or lost (e.g., by indicating which MPDUs (including one or more MSDUs) were acquired within the first PPDU). If the rendering device does not acquire the BA, the rendering device may attempt to retransmit the first PPDU to the display device.

[0107]

[0135] The end of the BA on the wireless medium is at time t8. The rendering device sends a second PPDU to the display device after the SIFS duration at time t8 (time t9), and the end of the second PPDU on the wireless medium is at time t 10 The process can be repeated for one or more PPDUs to be transmitted from the rendering device to the display device during the TXOP. For example, the rendering device may 11 The Nth PPDU can be sent at time t (where N is equal to or greater than 1). The end of the Nth PPDU on the wireless medium occurs at time t 12 The display device is 12 After the SIFS duration (time t 13 ) to the rendering device, and the termination of the BA on the wireless medium at time t 14 is located.

[0108]

[0136] Referring back to the RTS frame, the RTS frame indicates a NAV value to reserve the wireless medium for a duration greater than the TXOP (such as the indicated original NAV protection duration). For example, the TXOP may be configurable by the rendering device for a duration of up to 2.5 ms. The RTS frame indicates a NAV value of an amount equal to or greater than 2.5 ms if the rendering device should extend the NAV protection. Setting the NAV may refer to the rendering device indicating a value to set the NAV of each receiving device to stop the receiving device from transmitting for an amount of time. Extending the NAV may refer to the rendering device indicating a NAV padding value or a new NAV value that increases or sets the NAV of each receiving device to extend the amount of time the receiving device should stop transmitting. The NAV duration and TXOP may begin at the start time of the RTS frame. In some implementations, the rendering device indicates the NAV duration to be set to the TXOP duration (such as 2.5 ms). The rendering device may also indicate a minimum NAV value within each PPDU (such as the first PPDU through the Nth PPDU) to ensure that the remaining NAV is of a minimum duration or to extend the NAV (such as by indicating 1 ms of NAV padding following the PPDU transmission).

[0109]

[0137] The display device 14 At the end of the TXOP (e.g., t ), its BO counter may be executed (set to a second BO value). During the BO time, the display device listens to the wireless medium for incoming traffic. (e.g., time t 15 If the wireless medium remains clear until such time as a BO counter (e.g., BO_COUNTER_TIME_TIME, BO_COUNTER ...

[0110]

[0138] The end of the data on the wireless medium is at time t 16The rendering device is 16 After the SIFS duration (time t 17 ) to the display device, and the termination of the BA on the wireless medium is at time t 18 The rendering device may have one or more subsequent PPDUs of the application file to send to the display device. For example, sending a video frame may not be completed during the first TXOP, and the remainder of the video frame should be sent during one or more subsequent TXOPs. As depicted, the original NAV protection is implemented when the wireless medium is busy for a time t 18 indicates that it is still reserved by the rendering device after

[0111]

[0139] As described above, one or more subsequent PPDUs are associated with a third priority (associated with a third backoff counter value (third BO value) or a third set of EDCA parameters). In this manner, the BO counter of the rendering device may be set to the third BO value (and the rendering device may be configured for the third set of EDCA parameters), and the BO counter may be counted until the end of the BA on the wireless medium (at time t 18 ) starts counting down to 0. The BO counter counts down to 0 at time t 19 reaches 0 at time t 19 As depicted, at time t 19 is still within the original NAV protection duration. The new RTS may indicate a new NAV value indicating extended NAV protection (which may be within the same duration as the original NAV protection). In this way, the NAV of each receiving device is reset to the indicated NAV value, effectively extending the NAV reservation by the rendering device. The new RTS frame may also indicate a new TXOP.

[0112]

[0140] The end of the RTS frame on the wireless medium occurs at time t 20 The display device is20 After the SIFS duration (time t 21 ) to the rendering device, and the end of the CTS frame on the wireless medium is at time t 22 The rendering device is 22 After the SIFS duration (time t 23 ) to send the N+1 PPDU to the display device. The process may be repeated in the same manner as the first TXOP for one or more further TXOPs.

[0113]

[0141] In some implementations, the RTS / CTS mechanism may be enabled by the rendering device during the first PPDU of each video frame and disabled during other PPDUs of the video frame. In this manner, the N+1 PPDU may be sent without the RTS / CTS mechanism (e.g., to indicate a new TXOP to the display device). The NAV duration may be extended using the NAV padding indicated within each PPDU. In some implementations, the RTS / CTS mechanism may also be enabled by the rendering device during PPDUs other than the first PPDU (e.g., during one or more subsequent PPDUs depicted in FIG. 10 to indicate a new TXOP).

[0114]

[0142] The rendering device may include a video queue for receiving MSDUs. The MSDUs include a descriptor to indicate a specific video frame with which the MSDUs are associated. In some implementations, the rendering device provides the MSDUs (in one or more PPDUs) to the display device, and one or more obtained BAs indicate the MSDUs received by the display device. The rendering device removes the identified MSDUs from the video queue until all MSDUs are provided to the display device. In some implementations, the MSDUs associated with the next video frame may be received in the video queue before all MSDUs associated with the current video frame are successfully provided to the display device. In some implementations, the rendering device can flush the video queue (skipping the remainder of the current video frame) to begin transmitting the MSDUs of the next video frame. In some implementations, the rendering device can provide the remaining MSDUs of the current video frame.

[0115]

[0143] As described above, the rendering device can configure itself for a first priority of the first PPDU of a video frame. In some implementations, the rendering device can adjust one or more of the EDCA parameters (and BO value), whether the RTS / CTS mechanism is enabled, or the number of retries for RTS / CTS. For example, if the video queue is empty and a first MSDU associated with a second video frame is received, the rendering device can configure itself for a first set of EDCA parameters (which may be associated with the first PPDU of the video frame) and set the BO counter to a first BO value. If RTS / CTS is enabled for only the first PPDU of a video frame, the rendering device can enable RTS / CTS (with the first MSDU to be included in the first PPDU of the video frame). Additionally or alternatively, the rendering device can set the number of retries for RTS / CTS to a defined number (e.g., five retries). The rendering device may adjust the EDCA parameters (and BO value) to those associated with the third priority after completing the transmission of the RTS (e.g., based on obtaining a CTS) or after a defined number of retries. In some implementations, the rendering device may disable RTS / CTS or adjust the number of retries for RTS / CTS after completing the transmission of the RTS (e.g., based on obtaining a CTS) or after a defined number of retries.

[0116]

[0144] The first MSDU may include metadata identifying the first MSDU within the first PPDU of the video frame (e.g., in the sub-frame header 422 of the MSDU sub-frame 416 depicted in FIG. 4). A display device acquiring and processing the first PPDU can determine, based on the metadata, that the PPDU includes an MSDU (including the first MSDU) associated with a new video frame. In some implementations, the last MSDU may include metadata identifying the last MSDU within the last PPDU of the video frame (e.g., in the sub-frame header 422 of the MSDU sub-frame 416 depicted in FIG. 4). A display device acquiring and processing the PPDU can determine, based on the metadata, that the PPDU includes the last MSDU associated with the video frame. The rendering device can prevent including an indication of NAV padding in the last PPDU or otherwise use the last PPDU to extend the NAV. In this way, the rendering device can release control of the wireless medium at the end of the current NAV. Additionally or alternatively, the rendering device can send a contention-free (CF) end beacon after providing the last MSDU to instruct receiving devices to clear their NAVs. In this way, the rendering device can release control of the wireless medium before the end of the current NAV.

[0117]

[0145] In some implementations, the rendering device may shorten one or more TXOPs (such as the first TXOP) from the maximum duration. The rendering device may shorten the TXOP to ensure that the display device can provide UL data to the rendering device frequently enough for an XR experience. Shortening the TXOP may also allow the display device to conserve power by placing one or more components of the WCD in a low power mode for times outside of the TXOP.

[0118]

[0146] A device (such as a rendering device) and a second device (such as a display device) may be in the first BSS. Although not shown in FIG. 10, devices from the OBSS may share the wireless medium with the rendering and display devices. Based on the first, second, and third priorities, the OBSS devices may be prevented from gaining control of the wireless medium to transmit some types of data. For example, the OBSS devices may classify their traffic as best effort, high priority, etc. Data to be transmitted by the OBSS devices is associated with a fourth priority (which may be associated with a fourth set of EDCA parameters or a fourth BO value for the OBSS devices based on the traffic classification). The OBSS devices may contend for the wireless medium to transmit data associated with the fourth priority.

[0119]

[0147] The rendering device may always obtain control to transmit the first PPDU based on the first priority. For example, the first set of EDCA parameters (associated with the first priority) may give the rendering device preference over the display device and the OBSS device in obtaining control of the wireless medium. If data associated with the fourth priority is classified as best-effort data, the rendering device (transmitting a subsequent PPDU associated with the third priority) and the display device (transmitting data associated with the second priority) may have preference over the OBSS device. For example, the EDCA parameters associated with the fourth priority may prevent the OBSS device from transmitting best-effort classified data.

[0120]

[0148] In some implementations, the third set of EDCA parameters may be configured to allow the device to transmit high importance classified data (which may be associated with a set of EDCA parameters to enable transmission before transmission of one or more subsequent PPDUs from the rendering device). For example, referring again to FIG. 10, if a device that did not receive an RTS should transmit high importance classified data (e.g., based on a Differentiated Services Code Point (DSCP) value), the device may transmit the high importance classified data at time t 18 The device may be able to transmit data (based on the EDCA parameters associated with the DSCP value) after and before the rendering device should send the next RTS (associated with the third set of EDCA parameters). If the device should send best-effort classified data (based on the DSCP value, etc.), the device's EDCA parameters associated with the DSCP value may prevent the device from blocking the rendering device from sending an RTS associated with the third set of EDCA parameters. The device may attempt to transmit such data (or high-importance classified data) at the end of the NAV time.

[0121]

[0149] The above examples depict the operation of rendering and display devices for asynchronous channel access control. In some implementations, a wireless system may be configured for synchronous channel access control. Exemplary aspects for synchronous channel access control are described below. In some implementations, synchronous channel access control is based on a target wake-up time (TWT) session defined by one or more APs (e.g., by one or more 802.11ax-capable or subsequent APs, including IEEE 802.11be and other IEEE standards subsequent to IEEE 802.11ax). In some implementations, synchronous channel access control may be based on synchronized transmit / receive windows (which may not conform to the TWT session defined within the IEEE 802.11ax standard) adjusted by one or more APs (e.g., pre-802.11ax APs (sometimes referred to as legacy APs)).

[0122]

[0150] A TWT session may be between a display device (which may be referred to as an STA in terms of the TWT session characteristics) and a rendering device (which may be referred to as an AP in terms of the TWT session characteristics). A TWT session includes one or more TWT service periods (SPs) during which the display device remains awake unless it is determined that no further traffic should be communicated during the SP. A TWT SP may be referred to herein as a TWT window or window.

[0123]

[0151] A TWT session (also called TWT) may contain multiple characteristics. - either individual TWT (between two specific devices) or broadcast TWT (between three or more devices or devices that may change during the TWT); Either solicited TWT (STA initiates TWT with AP, which can accept, reject, or offer alternatives) or unsolicited TWT (AP sends unsolicited TWT responses based on a known cycle while the STA is listening to the wireless medium); Either pre-announced TWT (where the STA indicates when it wakes up within the TWT SP (e.g., via a Power Save (PS) poll or an Automatic Power Save Delivery (APSD) trigger frame) before the AP can send DL traffic), or pre-announced TWT (where the AP can send DL traffic without waiting for instructions from the STA during the TWT SP), Either a trigger-enabled TWT (where the AP sends a trigger frame to the STA before the STA can send UL traffic) or a non-trigger-enabled TWT (where the STA can send UL traffic without waiting for a trigger frame), and Either implicit TWT (STA calculates the next TWT SP start time a fixed amount of time from the current TWT SP start time) or explicit TWT (STA requests the next TWT SP start time from the AP) Includes:

[0124]

[0152] TWTs for synchronous channel access control between a rendering device and a display device (such as for an XR experience) can be individual TWTs, responsive TWTs, pre-announced TWTs, non-trigger-enabled TWTs, and implicit TWTs. In some implementations, the TWT is non-responsive TWT. The TWT may include such characteristics to protect the XR activity of the rendering device and the display device. For example, individual TWTs ensure that TWT windows are set up exclusively for the rendering device and the display device to communicate DL traffic (and UL traffic) between each other, responsive TWTs and pre-announced TWTs ensure that the display device is ready to receive DL traffic from the rendering device (to prevent delays associated with retries as a result of the display device not being ready to receive DL traffic), non-trigger-enabled TWTs allow the display device to send pause data frames at a greater frequency (without requiring the overhead of trigger frames from the rendering device), and implicit TWTs reduce the overhead caused by the display device requesting (and the rendering device providing) the next TWT SP start time. Although an exemplary set of characteristics for a TWT is shown, any suitable set of characteristics may be used.

[0125]

[0153] As used herein, XR activity may refer to any action performed by one or more devices (such as one or more of a rendering device or a display device) to provide an XR experience to a user. XR activity may include measuring the location of a display device with an IMU of the display device, generating pause frames or pause packets (also called pause data frames) from the IMU measurements, generating tracking frames, providing the pause frames and tracking frames to a rendering device, rendering and encoding one or more video frames based on the pause frames and tracking frames, packetizing the one or more video frames, providing the packets to a display device, decoding the video frames from the received packets, processing the video frames (such as dejittering and ATW), and displaying the video frames. XR activity may additionally or alternatively include operations to provide audio, haptic feedback, or other sensory information to a user during an XR experience.

[0126]

[0154] Similar to the asynchronous channel control access described above, synchronous channel control access using TWT should prevent collisions and interference on the wireless medium by aligning traffic between the rendering device and the display device to meet the latency and packet loss requirements for an XR experience. UL traffic may be sent by the display device when available (including outside the TWT window). In some implementations, however, UL traffic is transmitted during the TWT window. As described above, for an XR experience, UL traffic may include pause frames and tracking frames from the display device. DL traffic may include PPDUs carrying video frame data from the rendering device. PPDUs, pause frames, and tracking frames are transmitted during the TWT window, while data from other devices (or other data from the rendering device to the AP or other devices) is transmitted outside the TWT window. Note that the concepts described herein may apply to other types of UL and DL traffic (such as application files not associated with video) and other types of devices. Although some aspects of the present disclosure are described in examples with reference to rendering and display devices for XR experiences for clarity in describing the aspects, aspects of the present disclosure are not limited to the examples provided.

[0127]

[0155] Referring again to FIG. 7 , the rendering and encoding of each video frame by the rendering device (710) may be at a known interval and periodicity associated with the frame rate of the display (720). The TWT window for the TWT session between the rendering device and the display device may be set up to have a known interval based on the known interval and periodicity for rendering. For example, the rendering device may be ready to transmit the PPDU of the next video frame at a known periodicity, and the timing of the TWT window may be based on the periodicity. As described above, the TWT window includes the time during which the wireless medium is allocated for UL data and DL data to be transmitted between the rendering device and the display device. In this manner, the time when UL traffic is to be transmitted by the display device may be adjusted to coincide with the time when DL traffic is to be transmitted so that both can be transmitted during the TWT window. The rendering device may set up a TWT session with the display device (with the duration and length of the TWT window indicated to the display device) based on the rendering of the video frame at the rendering device. The display device may adjust the transmission of UL traffic based on the indicated duration and length of the TWT window. The length of the TWT window allows both UL and DL traffic (also referred to as UL data and DL data, respectively) to be transmitted during the same TWT window.

[0128]

[0156] 11 shows a flowchart illustrating an example process 1100 for synchronized channel access control based on TWT sessions, according to some implementations. The operations in the example process may be performed by a device (such as device 154 in FIG. 1B) or a wireless communication device implemented within a device (such as WCD 615 in FIG. 6B). The device performing the operations may be a rendering device for an XR experience.

[0129]

[0157] At 1102, a device acquires UL data from a second device over a wireless medium. The UL data may include one or more pose frames or one or more tracking frames from the second device, which may be a display device (such as an HMD).

[0130]

[0158] At 1104, the device provides DL data including PPDUs to the second device over the wireless medium. The PPDUs may include video frame data. During the current TWT window, the device may provide one or more of the PPDUs to the second device (1106). One or more pause frames may also be obtained during the current TWT window. In this manner, both UL data and DL data may be transmitted during the current TWT window.

[0131]

[0159] The start time of the TWT window may be adjusted to reduce latency and increase efficiency when using the TWT window. For example, if the TWT window starts a certain amount of time before either UL data or DL ​​data is transmitted during the TWT window, a second device (such as a display device) should remain awake and listen for the amount of time of the TWT window that is not used for transmission. In addition, if a PPDU is ready for transmission outside the TWT window, the rendering device must wait until the next TWT window to transmit the PPDU. If UL data is to be transmitted outside the TWT window, the display device must remain in an active power state for the time outside the TWT window to transmit the UL data. As described above, the period for rendering a video frame is known (when a PPDU for the video frame is available for periodic transmission). If the time that a PPDU (such as a first PPDU) is available for transmission during each period is known, the start of the TWT window may be determined based on when a PPDU is available during each period. In this way, the start of the current TWT window is associated with one of when a first PPDU of the one or more PPDUs is provided to the second device or when the first PPDU is provided from the device's application layer to the MAC 1108. For example, the start of the current TWT window (and other TWT windows) is synchronized with the time of transmitting DL data and UL data so as to reduce any latency between the start of the TWT window and transmission and reduce any time the rendering device must wait between preparing one or more PPDUs for transmission and transmitting the one or more PPDUs.

[0132]

[0160] As described above, DL data and UL data may be associated with a video frame rendered for an XR experience. In some implementations, the device depicted in FIG. 11 (e.g., a rendering device) renders a video frame to be displayed by a second device (e.g., a display device). In this manner, the UL data from the second device includes a pause data frame, and a rendering of the video frame is associated with the acquired pause data frame. As described above, a video frame (e.g., a first video frame) includes multiple video slices, the rendering of the first video frame is associated with the most recently acquired pause data frame from the second device, and one or more PPDUs to be transmitted to the second device are associated with one or more of the multiple video slices. For example, the rendering device divides a video frame into multiple slices, and the rendering device packages each slice into multiple PPDUs to be transmitted during a TWT window. Each TWT window may be used by the rendering device to transmit a PPDU of a video frame to the display device (the next TWT window is used to transmit the PPDU of the next video frame).

[0133]

[0161] The second device listens for DL ​​data during the TWT window. If transmissions of both DL data and UL data are coordinated so that both are transmitted during the TWT window, the second device may not need to transmit outside of the TWT window. The second device (such as a display device) may enter a low-power mode (such as by powering down or reducing power to one or more components of its wireless communication device) during the TWT window. In this way, the second device can reduce power consumption. For example, many display devices (such as HMDs) are battery-powered to allow a user to move around and not restrict the user's freedom of movement. The display device may place one or more components of its radio frequency (RF) front end in a low-power mode between TWT windows to conserve power and extend the amount of time the display device can be used between charges. Such a low-power mode during a TWT session may be referred to as a TWT power-save mode.

[0134]

[0162] The rendering device may determine to continue transmitting to the display device outside the TWT window. For example, the rendering device may determine that one or more PPDUs of a video frame cannot be provided to the display device during the current TWT window. In this manner, one or more PPDUs may be provided after the current TWT window. In some implementations, the rendering device may provide an instruction to the display device not to enter a low power mode (TWT power save mode) after the current TWT window. The instruction may be included in a power management (PM) field of the MAC header of a packet (e.g., the PM bit of the frame control field set to 0 to indicate that the display device will not enter a low power mode) provided to the display device during the current TWT window (e.g., the last packet provided to the display device during the window). The display device processes the packet's header and determines that entering a low power mode after the current TWT window should be prevented. In this manner, the rendering device may provide PPDUs to the display device after the current TWT window and before the next TWT window.

[0135]

[0163] Conversely, the rendering device may end the current TWT window early if no further PPDUs should be transmitted during the current TWT window. For example, if all PPDUs of a video frame are provided to the display device before the end of the current TWT window, the rendering device may indicate to the display device that the current TWT window will end early. In some implementations, the end-of-service-period (EOSP) bit in the quality-of-service (QoS) field of the MAC header of the packet may be set to 1 to indicate that the TWT window is ending. The packet may contain a null data frame and be used exclusively to indicate the end of the TWT window via the EOSP bit in the QoS field (sometimes referred to as an EOSP packet). As defined for a TWT session (e.g., in the IEEE 802.11ax standard), an EOSP packet may be sent after more than 10 ms of inactivity during the TWT window. In some implementations, the rendering device is configured to send an EOSP packet after 10 ms of inactivity after the last PPDU.

[0136]

[0164] In some implementations, the TWT window may end before 10 ms of inactivity has elapsed. For example, as described above, the MSDU may include metadata to indicate that the MSDU is the last MSDU for a video frame. In processing the last MSDU, the display device may determine that no more PPDUs should be received from the rendering device for the video frame, and the display device may enter a low-power mode until the next TWT window (effectively ending the TWT window for the display device). In another example, the rendering device may be configured to send an EOSP packet after less than 10 ms of inactivity (e.g., immediately after the last PPDU). When preparing a PPDU for transmission to the display device, the rendering device may decide to send an EOSP packet based on the metadata of the last MSDU.

[0137]

[0165] The low power mode (TWT power save mode) referred to herein may differ from one or more sleep modes defined within an IEEE 802.11 standard (such as pre-802.11ax standards, including 802.11ba, etc.). For example, the low power mode (TWT power save mode) may be associated with faster sleep-to-wake (S2W) and wake-to-sleep (W2S) times than a sleep mode defined in the standard (called deep sleep) designed for best-effort classified traffic based on a Delivery Traffic Indication Message (DTIM) in the AP's beacon. In some implementations, the minimum low power period (including S2W and W2S) for the low power mode may be approximately 10 ms, and the minimum deep sleep period (including S2W and W2S) for deep sleep may be approximately 40 ms (which may be too long for XR activity for video at 60 fps (approximately 16 ms per video frame)). The low power mode may differ from deep sleep by powering down fewer RF front-end components, maintaining carrier signal lock on the wireless medium, or other actions that reduce the amount of time spent in and out of the low power mode.

[0138]

[0166] Figure 11 depicts an exemplary process from the perspective of a rendering device. Figure 12 depicts an exemplary process from the perspective of a display device.

[0139]

[0167] 12 shows a flowchart illustrating an example process 1200 for synchronized channel access control based on TWT sessions, according to some implementations. The operations in the example process may be performed by a device (such as device 152 in FIG. 1B) or a wireless communication device implemented within a device (such as WCD 615 in FIG. 6B). The device performing the operations may be a display device of an XR experience.

[0140]

[0168] At 1202, a device provides UL data to a second device over a wireless medium. The second device may be a rendering device, and the UL data may include one or more of a pause data frame or a tracking frame.

[0141]

[0169] At 1204, the device acquires DL data including a PPDU from a second device over a wireless medium. For example, the PPDU is associated with one or more video frames to be rendered based on the UL data. The device acquires one or more PPDUs from the second device during a current TWT window (1206), where a start of the current TWT window is associated with one of when a first PPDU of the one or more PPDUs is provided to the device or when the first PPDU is provided from an application layer of the second device to a MAC (1208).

[0142]

[0170] As described above, the start of the TWT window is associated with when the first PPDU is to be transmitted. In some implementations, the start of the TWT window may coincide with when the first PPDU is to be transmitted. In some implementations, the TWT window may begin before when the first PPDU is to be transmitted. The display device may provide one or more of a tracking frame or one or more pause data frames for each video frame to be rendered. In this manner, the frequency at which the tracking frame or one or more pause data frames are provided is the same as the frequency of the video frames. For example, the pause data frames may be provided at a first frequency, and the video frames may be rendered at the first frequency. The display device may provide the pause data frame before when the first PPDU of a video frame is ready for transmission. In some implementations, the TWT window begins when the first of the tracking frame or one or more pause data frames is to be transmitted from the display device to the rendering device. For example, when the TWT window should begin may be based on the M2R latency for an XR experience.

[0143]

[0171] FIG. 13 shows a sequence diagram 1300 illustrating example timing for rendering pause data frames and video frames associated with M2R latency. At 1302, a display device acquires pause information. For example, the display device decides to package current IMU measurements into a pause data frame N-1 (for any integer N greater than 0) and provide the pause data frame N-1 to a rendering device. UL latency 1304 is the latency between the time of the IMU measurement and the time the rendering device acquires the pause data frame N-1 (at 1306). UL latency 1304 may vary based on the amount of UL data to transmit and the condition of the wireless medium. For example, if the wireless medium contains more interference or noise, UL latency 1304 may be greater as a result of retries in sending the pause frame N-1 or transmitting the pause frame N-1 using a lower MCS rate. After acquiring the pause frame N-1 (1306), the rendering device begins rendering the video frame N-1 (1308). Time 1310 indicates the rendering time for rendering video frame N-1. Although not depicted, the rendering time may include the time for rendering and encoding the video frame. The rendering device provides video frame N-1 to the display device in multiple PPDUs. Time 1312 is the time during which PPDUs are provided from the rendering device to the display device. Although not depicted, PPDUs may be provided before or after the encoding of an entire frame is complete. For example, a video slice may be packaged into one or more PPDUs at the same time as another video slice is being processed prior to packaging into one or more PPDUs. In this manner, time 1312 may overlap with time 1310.

[0144]

[0172] At 1316, the display device again acquires pose information. For example, the display device determines that the current IMU measurements at that time should be packaged into pose data frame N. Pose data frame N is acquired by the rendering device at time 1320 (UL latency 1318 is the latency between time 1316 and time 1320). UL latency 1318 is depicted as being greater than UL latency 1304 to depict that UL latency may vary.

[0145]

[0173] At 1322, the rendering device begins rendering video frame N. The video may have an inherent frame rate, and the interval between video frame renderings may be fixed based on the frame rate, resolution, encoding, and other video parameters. In this manner, the amount of time between time 1308 and time 1322 may be the same as the amount of time between time 1322 and the time to begin rendering video frame N+1. Time 1324 indicates the rendering time for rendering video frame N. The rendering device provides video frame N to the display device in multiple PPDUs. Time 1326 is the time during which PPDUs are provided from the rendering device to the display device. Although not shown, times 1312 and 1326 may be variable based on channel conditions, channel size, MCS, use of forward error correction (FEC), number of PPDUs to be transmitted, or other characteristics.

[0146]

[0174] The rendering device renders the current frame based on the most recent pause frame obtained from the display device. For video frame N, time 1322 is before time 1320 (when pause frame N was obtained). Thus, the rendering device does not render video frame N based on pause frame N (because pause frame N has not yet been obtained). If the last pause frame obtained is pause frame N-1, the rendering device renders video frame N based on pause frame N-1. M2R latency may be the latency between the IMU measurement and the rendering of the video frame associated with the IMU measurement. Because video frame N is based on pause frame N-1, M2R latency 1314 is greater than if pause frame N had been received in time. The M2R latency may be determined based on a default or known UL latency.

[0147]

[0175] In some implementations, the TWT window 1328 may begin at time 1302 (assuming time 1302 is when the display device should transmit PAUSE frame N−1). If the amount of time between times 1302 and 1316 is fixed (such as the same amount of time as between times 1308 and 1322), the length of the TWT window 1328 may be fixed to completely include time 1312. Because time 1312 may vary, the TWT window 1328 may be of a length to accommodate variations in time 1312 (such as a length that allows for transmission of video frames based on a maximum resolution, a minimum MCS, a minimum channel size, etc.). As described above, the rendering device may also indicate that one or more PPDUs should be transmitted after the end of the TWT window to transmit PPDUs that are not capable of being transmitted during the TWT window. In an example, the end of the TWT window 1328 may be between the end of time 1312 and time 1316. Although not shown, a new TWT window may begin at time 1316. Note that sequence diagram 1300 (and other depicted sequence diagrams) is not to scale and may vary in operation. For example, DL (1312) of video frame N-1 may be coupled with UL (1320) of pause frame N to one TWT window.

[0148]

[0176] In the example sequence diagram 1300, the timing of providing PAUSE frames and the timing of rendering video frames are not coordinated, which may result in video frames being rendered before new PAUSE data frames are received, increasing M2R latency. A rendering device may coordinate the rendering of video frames, or a display device may coordinate the provision of PAUSE frames to a rendering device, resulting in one or more PAUSE frames being obtained before rendering a new video frame (e.g., the rendering device and display device coordinating such that time 1322 occurs after time 1320). Figure 14 depicts coordinated timing to reduce M2R latency.

[0149]

[0177] FIG. 14 shows a sequence diagram 1400 illustrating example timing for rendering pause data frames and video frames associated with M2R latency. At 1402, a display device acquires pause information. For example, the display device decides to package current IMU measurements into pause data frame N-1 (for any integer N greater than 0) and provide the pause data frame N-1 to a rendering device. UL latency 1404 is the amount of time from the time of the IMU measurement to the time the rendering device acquires pause frame N-1 (at 1406). UL latency 1404 may vary based on the amount of information to be transmitted and the condition of the wireless medium. For example, if the wireless medium contains more interference or noise, UL latency 1404 may be greater as a result of retries in sending pause frame N-1 or transmitting pause frame N-1 using a lower MCS rate. After acquiring pause frame N-1 (1406), the rendering device begins rendering video frame N-1 (1408). Time 1410 indicates the rendering time for rendering video frame N-1. The rendering device provides video frame N-1 to the display device in multiple PPDUs. Time 1412 is the time during which the PPDUs are provided from the rendering device to the display device.

[0150]

[0178] At 1416, the display device acquires pause information and provides pause data frame N to the rendering device. UL latency 1418 is the amount of time from the time of the IMU measurement to the time the rendering device acquires pause data frame N (at 1420). UL latency for pause frame N 1418 is greater than UL latency 1404 to illustrate that UL latency may vary. At 1422, the display device begins rendering video frame N. Time 1424 indicates the rendering time for rendering video frame N. The rendering device provides video frame N to the display device in multiple PPDUs. Time 1426 is the time during which PPDUs are provided from the rendering device to the display device. TWT window 1428 may be the same as TWT window 1328 of FIG. 13.

[0151]

[0179] The amount of time between time 1408 and time 1422 may be the same as the amount of time between 1308 and 1322 in FIG. 13. A difference between FIG. 13 and FIG. 14 may be the timing between providing a pause frame by the display device and rendering a video frame by the rendering device. As depicted in FIG. 14, the timing of rendering a video frame is coordinated with the timing of the display device providing a pause frame to the rendering device. For example, time 1422 is determined such that time 1422 remains after time 1420. In this manner, pause frame N may be obtained before rendering video frame N, and pause frame N may be used to render video frame N. In some implementations, the timing may be based on the UL latency for the pause frame (such as potential UL latency based on the lowest MCS, minimum wireless channel, level of noise, use of FEC, and other parameters that reduce the throughput of transmission of pause data frames to the rendering device). When the rendering is coordinated, M2R latency 1414 is reduced. For example, the M2R latency 1414 is less than the M2R latency 1314 in FIG.

[0152]

[0180] When rendering and providing pause frames are coordinated, the start of the TWT window may be based on the M2R latency. For example, the rendering device may determine the TWT window to begin a first offset before the time to render a video frame. In some implementations, the first offset may be an M2R latency (such as the M2R latency 1414 before the time 1408 that results in the start of the TWT window 1428).

[0153]

[0181] As depicted in FIGS. 13 and 14 , pause data frames may be acquired or provided, and video frames may be rendered at the same frequency. In some implementations, two or more pause data frames may be provided during a TWT window (such as providing a pause data frame in the middle of the TWT window or toward the end of the TWT window), but at least one pause data frame provided at the beginning of the TWT window may be provided at a first frequency. In this way, each of the pause data frames acquired at the beginning of the TWT window may be associated with a video frame to be rendered. If there is a problem acquiring the first pause data frame during the TWT window (e.g., based on temporary interference on the wireless medium), additional pause data frames may be provided during the TWT window. For example, if pause frame N in FIG. 14 is not acquired by the rendering device, but the display device provides an intermediate pause frame at the end of the TWT window 1428, the rendering device may render video frame N using the intermediate pause frame (instead of pause frame N−1). Providing additional pause frames can reduce the latency between when pause information is acquired and when a video frame is rendered in such a case.

[0154]

[0182] Referring again to the pause frame provided at the start of the TWT window, obtaining pause frames and rendering video frames are of the same frequency, and the timing between rendering video frames and obtaining pause frames is adjusted to reduce M2R latency. Obtaining pause information is performed in the application layer of the display device, and rendering video frames is performed in the application layer of the rendering device. Referring again to FIGS. 6A and 6B , application processor 630 (in cooperation with memory 640) can execute an XR application on the rendering device (such as a VR or AR application on a smartphone). Application processor 635 (in cooperation with memory 645) can execute an XR application on the display device (such as a VR or AR application on an HMD). At the application layer, the rendering device renders video frames or generates audio, haptic feedback, or other information for the XR experience, and the display device obtains IMU measurements (such as from sensor 675), displays video, plays audio, or provides other information to the user for the XR experience. Operations at the application layer are based on the device's application layer clock. For example, a device may use a first piezoelectric material (such as a quartz crystal) to generate a host clock that is provided to an application processor to perform application layer operations. In this manner, the application layer clock is used by the device to time the rendering of video frames (by a rendering device) or the display of video frames (by a display device). Such a clock may be referred to as an application layer clock.

[0155]

[0183] As described above, the WCD 610 or 615 is used to perform operations at a lower layer of the OSI model (such as the MAC). For example, managing and scheduling pause data frames, tracking frames, or PPDUs for transmission, as well as managing the reception of packets, are in the MAC and may be managed by the WCD 610 or WCD 615. The WCD's operation is based on a second clock (referred to as the WCD clock). The WCD clock is used by the device for timing wireless communications with a second device. The WCD clock is based on a second piezoelectric material (such as a second crystal) in the device that is different from that used for the application layer clock. The device can use two different crystals (and therefore different logic) to generate the application layer clock and the WCD clock, and the application clock and WCD clock may be at different frequencies, resolutions, or phases.

[0156]

[0184] To coordinate the timing between providing pause frames (and tracking frames) and rendering video frames, the display device and the rendering device can synchronize their application layer clocks and WCD clocks. In this way, the application layer clock and the WCD clock can have the same frequency and phase. In some implementations, the application layer clock may be synchronized to the WCD clock. In some implementations, the WCD clock may be synchronized to the application layer clock. The clock of one device may also be synchronized to the clock of the other device. In this way, one of the four clocks between the rendering device and the display device is a reference clock, and the other three clocks are synchronized to the reference clock. The TWT window timing (such as the offset used to determine the start of the TWT window) may be determined based on the reference clock. If the application layer clock of the display device is the reference clock, the application layer clock of the display device can drive the timing of the TWT window, and if the application layer clock of the rendering device is the reference clock, the application layer clock of the rendering device can drive the timing of the TWT window. If the WCD clock is to be used to synchronize other clocks, a schedule for the TWT window may be set, and one or more of the rendering timing or display timing of the video frames may be adjusted based on the set schedule of the TWT.

[0157]

[0185] 15A-15C depict different clocks as reference clocks for synchronization: the application layer clock of the display device is depicted as the reference clock in FIG. 15A, the application layer of the rendering device is depicted as the reference clock in FIG. 15B, and the WCD clock of the rendering or display device is depicted as the reference clock in FIG. 15C.

[0158]

[0186] 15A shows a block diagram 1500 illustrating an example of synchronizing the clocks of a rendering device 1502 and a display device 1508. The rendering device 1502 includes an application layer clock 1504 and a WCD clock 1506, and the display device 1508 includes an application layer clock 1510 and a WCD clock 1512. In the example, the application layer clock 1510 is a reference clock, and other clocks are synchronized to the application layer clock 1510.

[0159]

[0187] At 1514, the WCD clock 1512 is synchronized to the application layer clock 1510. For example, the time of the application layer clock 1510 may be indicated in pause information or tracking frames to be provided to the rendering device 1502. The information is provided from the application layer to a MAC (such as a WCD) to be scheduled and transmitted to the rendering device 1502. The WCD may obtain the time from the information obtained from the application layer and synchronize the WCD clock based on the indicated time.

[0160]

[0188] At 1516, WCD clock 1506 synchronizes to WCD clock 1512. For example, the WCD of display device 1508 includes a local timing synchronization function (TSF) timer for synchronizing communications over the wireless medium with rendering device 1502. The WCD of rendering device 1502 also includes a local TSF timer. The WCD of display device 1508 periodically provides an indication of its TSF timer value to the WCD of rendering device 1502 (e.g., via a pause data frame or a beacon frame from display device 1508 to rendering device 1502). Synchronizing WCD clock 1512 to application layer clock 1510 causes the TSF timer of the WCD of display device 1508 to be adjusted. Because the indication of the TSF timer value is periodically provided to the WCD of rendering device 1502, the adjusted TSF timer value is indicated to the WCD of rendering device 1502. The rendering device 1502 may adjust its WCD clock based on the adjusted TSF timer value from the display device 1508.

[0161]

[0189] If the WCD clock 1506 of the rendering device 1502 is synchronized to the WCD clock 1512 and the application layer clock 1510 of the display device 1508, the rendering device 1502 may synchronize 1518 the application layer clock 1504 to the WCD clock 1506. In some implementations, the rendering device 1502 may be configured to make the TSF timer values ​​available to the application layer (e.g., via a call from the MAC to an application layer configured for the rendering device 1502). If the TSF timer values ​​are not visible at the application layer, timing information from packets obtained from the display device (e.g., the indicated TSF timer value and the time the packet was sent) may be used in synchronizing the application layer clock 1504.

[0162]

[0190] 15B shows a block diagram 1520 illustrating an example of synchronizing the clocks of a rendering device 1522 and a display device 1528. The rendering device 1522 includes an application layer clock 1524 and a WCD clock 1526, and the display device 1528 includes an application layer clock 1530 and a WCD clock 1532. In the example, the application layer clock 1524 is a reference clock, and other clocks are synchronized to the application layer clock 1524.

[0163]

[0191] At 1534, the WCD clock 1526 is synchronized to the application layer clock 1524. For example, the time of the application layer clock 1524 may be indicated in a video frame or other information to be provided to the display device 1528. The information is provided from the application layer to a MAC (such as the WCD) to be scheduled and transmitted to the display device 1528. The WCD may obtain the time from the information obtained from the application layer and synchronize the WCD clock based on the indicated time.

[0164]

[0192] At 1536, WCD clock 1532 synchronizes to WCD clock 1526 (e.g., based on a local TSF timer value of the WCD of rendering device 1522). For example, the WCD of rendering device 1522 may periodically provide an indication of its TSF timer value or other timing information to the WCD of display device 1528 (e.g., via one or more MAC control elements (CEs) in a PPDU for a video frame), and the local TSF timer of display device 1528 may be adjusted based on the updated timing information after synchronizing WCD clock 1526 to application layer clock 1524. When WCD clock 1532 of display device 1528 is synchronized to WCD clock 1526 and application layer clock 1524 of rendering device 1522, display device 1528 may synchronize its application layer clock 1530 to WCD clock 1532 (1538). 15A, the display device 1528 may be configured to make the TSF timer values ​​available to the application layer (e.g., via a call from the MAC to an application layer configured for the display device 1528). If the TSF timer values ​​are not visible at the application layer, timing information from packets obtained from the rendering device (e.g., the indicated TSF timer value and the time the packet was sent) may be used in synchronizing the application layer clock 1530.

[0165]

[0193] 15C shows a block diagram 1540 illustrating an example of synchronizing the clocks of a rendering device 1542 and a display device 1548. The rendering device 1542 includes an application layer clock 1544 and a WCD clock 1546, and the display device 1548 includes an application layer clock 1550 and a WCD clock 1552. In the example, the WCD clock 1546 or 1552 is a reference clock, and other clocks are synchronized to the WCD clock.

[0166]

[0194] At 1554, WCD clocks 1546 and 1552 are synchronized with each other. For example, if timing information is provided between the devices (as described above with reference to FIG. 15A and FIG. 15B), the TSF timers between the devices may be synchronized. At 1556, rendering device 1542 synchronizes application layer clock 1544 to WCD clock 1546 (as described above with reference to FIG. 15A). At 1558, display device 1548 synchronizes application layer clock 1550 to WCD clock 1552 (as described above with reference to FIG. 15B).

[0167]

[0195] 15A , if the application layer clock 1510 is the reference clock, the application layer clock 1510 may be initially set by the display device 1508 and does not need to be adjusted during operation. Because the application layer clock 1510 is not adjusted during operation and the display of video frames is based on the application layer clock 1510 of the display device 1508, the display of video frames may remain unchanged during operation (the other clocks 1504, 1506, and 1512 are adjusted to remain synchronized to the application layer clock 1510). The display device 1508 may determine a TWT session schedule between the rendering device 1502 and the display device 1508. The schedule may include the interval of the TWT window, the size of the TWT window, and the start time of the TWT window. The display device 1508 may align UL traffic to the TWT window (such as aligning the transmission of a pause frame to the start of the TWT window). In this manner, the timing at which pause information is packaged and provided to the rendering device 1502 is based on a TWT schedule determined based on the application layer clock 1510. For example, the intrinsic IMU measurements to be used to generate a pause frame may be based on a TWT schedule determined based on the application layer clock 1510.

[0168]

[0196] When the WCD clock 1506 and the application layer clock 1504 are synchronized to the application layer clock 1510, the rendering device 1502 can align DL traffic to the TWT window (e.g., align the transmission of PPDUs to a portion of the TWT window). For example, referring again to FIG. 14, the display device determines times 1402 and 1416 to be at the start of a TWT window (including TWT window 1428) based on the TWT schedule. The rendering device can adjust times 1408 and 1422 (to render video frames N-1 and N) to be a first offset from times 1402 and 1416, respectively (the first offset is associated with the M2R latency). As described above, the M2R latency 1414 may be known. The first offset may be the M2R latency 1414. In this way, the rendering device can adjust the time 1410 to be after the M2R latency 1414 of the time 1402.

[0169]

[0197] In some implementations, the rendering device can trigger times 1408 and 1422 based on obtaining a pause frame during the TWT window or based on a timeout from the start of the TWT window. For example, triggering the rendering of video frame N-1 (at time 1408) may be based on obtaining pause frame N-1 (at time 1406). In this manner, the difference between times 1406 and 1408 is based on the amount of time required to trigger the rendering of the video frame (e.g., processing the pause frame and providing pause information to the application layer via a WCD before rendering the video frame at the application layer). As described above, if the rendering device is unable to obtain a pause frame (e.g., based on interference on the wireless medium), the rendering device does not provide an ACK to the display device. The display device can retry to provide the pause frame one or more times (e.g., up to a maximum number of times or up to a timeout amount of time from the start of the TWT window). The timeout may be based on when the rendering device should start rendering the video frame. For example, the timeout period may be the amount of time from the start of a TWT window (such as times 1402-1408) up to the time the rendering device begins rendering a video frame. The timeout period may be determined by the rendering device or may be defined within a TWT session. In this manner, the rendering device begins counting from the start of each TWT window, and the rendering device triggers rendering of a video frame upon reaching the timeout period or acquiring a pause frame, whichever comes first. If a timeout occurs (the timeout period is reached before acquiring a pause frame), the rendering device may generate a video frame using the last acquired pause frame acquired before the TWT window (such as during the last TWT window).

[0170]

[0198] In some implementations, the display device can indicate when the rendering device should begin rendering a video frame. In this way, the rendering device triggers the rendering of each video frame based on explicit instructions from the display device. For example, a vertical synchronization (Vsync) value in the application layer of the display device may be indicated to the WCD to indicate the time at which the rendering device should render the video frame. A time based on the Vsync may be indicated during the WCD, and the rendering device can convert the indicated time into an application layer time at which to render the video frame.

[0171]

[0199] 15B , when the application layer clock 1524 is the reference clock, the application layer clock 1524 may be initially set by the rendering device 1522 and does not need to be adjusted during operation. Because the application layer clock 1524 is not adjusted during operation and the rendering of video frames is based on the application layer clock 1524 of the rendering device 1522, the rendering of video frames may remain unchanged during operation (other clocks 1526, 1532, and 1530 are adjusted to remain synchronized with the application layer clock 1524). The rendering device 1522 may determine a TWT session schedule between the rendering device 1522 and the display device 1528. The schedule may include the interval of the TWT window, the size of the TWT window, and the start time of the TWT window. The rendering device 1522 may determine the start time of the TWT window to be before the rendering time offset defined for the video frame. 14, times 1408 and 1422 may be set based on application layer clock 1530 (FIG. 15B). The rendering device may determine times 1402 (which are the start of the TWT window) and 1416 to be before a first offset (associated with M2R latency) of the set rendering times 1408 and 1422. In some implementations, the first offset may be M2R latency 1414 as described above. As described above, the M2R latency (and the first offset) may be determined to offset the UL latency.

[0172]

[0200] When the WCD clock 1532 and the application layer clock 1530 are synchronized to the application layer clock 1524 (FIG. 15B), the display device 1528 can align the UL traffic with the TWT window. For example, referring again to FIG. 14, the display device can determine times 1402 and 1416 to be at the start of a TWT window (including TWT window 1428) based on the TWT schedule indicated by the rendering device. The display device 1528 can also align the display time for the video frames based on the application layer clock 1530. In this way, the display time of the current video frame is aligned with the time associated with the current TWT window.

[0173]

[0201] Referring again to FIG. 15C , when the WCD clocks 1546 and 1552 are reference clocks, the WCD clocks 1546 and 1552 may initially be set and synchronized based on TSF information provided between the rendering device 1542 and the display device 1548. For example, the rendering device 1542 may provide timing information to the display device 1548, and a local TSF timer may be synchronized based on the timing information. In this manner, the application layer clock 1544 and the application layer clock 1550 are adjusted based on their respective WCD clocks. With the WCD clocks as reference clocks, the TWT session schedule may be based on network resource availability (in addition to latency requirements for XR traffic). For example, the size, interval, and start time of the TWT window may be based on the wireless medium being shared by simultaneous links from the rendering device to the AP and the display device. In another example, the size, interval, and start time of the TWT window may be based on the wireless medium being shared by multiple links between the rendering device and multiple display devices (such as in a mesh network). The TWT session schedule may be determined by either the rendering device or the display device, and the rendering device and the display device may adjust application layer operations based on the TWT session schedule.

[0174]

[0202] 14, in some implementations, the rendering device may set times 1408 and 1422 to be after a first offset of the start of the respective TWT window (such as a first offset equal to M2R latency 1414 after time 1402 relative to time 1408). In some implementations, the rendering device may trigger rendering based on obtaining a pause frame (as described above) or the occurrence of a timeout. The display device may determine the time to display the video frame based on the TWT session schedule.

[0175]

[0203] Over time, synchronized clocks may drift from one another. A rendering or display device may periodically synchronize its clocks as a result of the drift. For example, the WCD clocks may remain synchronized based on the TSF, but the application layer clocks at the display or rendering device may drift from their respective WCD clocks. In some implementations, the device measures the drift between the application layer clock and the WCD clock and determines whether it is greater than a defined threshold (such as 10 μs or more). If the drift is greater than the defined threshold, the device may resynchronize the application layer clock and the WCD clock. The synchronization may be performed based on which clock is the reference clock, as described above with reference to FIGS. 15A-15C. If the device includes a reference clock, other devices may also synchronize their clocks based on the synchronization.

[0176]

[0204] In the above example, the display device may provide two or more pause frames during the TWT window. For example, the first pause frame may be provided at the beginning of the TWT window. The display device may also provide one or more additional pause frames later in the TWT window. In some implementations, the display device may provide additional pause frames after a defined period of inactivity on the wireless medium during the TWT window. In some implementations, the display device may provide additional pause frames toward the end of the TWT window or after the rendering device indicates that no more PPDUs are to be provided (e.g., based on an indication in an MSDU indicating that the MSDU is the last MSDU for a video frame). Each pause frame may be based on new IMU measurements. If a pause frame is not acquired by the rendering device (e.g., based on interference on the wireless medium), the previous pause information acquired at the rendering device is stale than if only one pause frame per TWT window was provided.

[0177]

[0205] In some implementations, the IMU measurements are taken independently of packaging the position information as a pause frame to provide to the rendering device. For example, the IMU may measure the position information at a frequency of 1 kHz (every 1 ms). The display device may use the most recent IMU measurements to generate a pause frame when needed, and the display device may ignore other IMU measurements for the pause frame. In this example, the latency between the IMU measurement and the generation of the pause frame is up to 1 ms. In some implementations, the IMU measurements may be based on when a pause frame should be generated. For example, the IMU measurements may be triggered based on the timing of providing a pause frame to the rendering device.

[0178]

[0206] With synchronous channel access, the timing of communications is managed by the rendering and display devices to ensure that latency requirements are met for XR traffic (such as to ensure smooth display of video frames and to ensure that M2R2P latency is met for an XR experience). The rendering device may treat XR traffic differently from other traffic (such as best-effort classified traffic to another device). In this manner, the processing of data and the communication of such data may be based on the application (such as whether it is XR-related data or not).

[0179]

[0207] For best-effort classified traffic, stations typically provide MSDU-level traffic to a first-in, first-out (FIFO) queue in the WCD for transmission. Management of MSDUs in the queue has no concept of data delivery deadlines or latency requirements, and each MSDU is managed independently of other MSDUs. For XR applications, an application file may require more than one MSDU. Additionally, time constraints for delivering application data (such as delivering a video frame within a defined amount of time) may require that an MSDU carry application data to be delivered within the defined amount of time. If any MSDU is lost or delayed in being acquired by the display device, all other MSDUs acquired for the application file may not be processed and may be useless to the display device. For example, if a video slice is packaged into multiple MSDUs by a rendering device and all but one MSDU is delivered to the display device, the delivered MSDU cannot be used to generate a video slice. In some implementations, the rendering device and display device are configured to manage XR traffic to ensure that all MSDUs of an application file are delivered in time to comply with latency requirements for the XR experience.

[0180]

[0208] FIG. 16 shows a flowchart illustrating an example process 1600 for managing data for transmission, according to some implementations. While the example depicts data as video frames of a video for an XR experience, the data may be any suitable data of an application file (which may or may not be for an XR experience). For example, the suitable data may be audio data, haptic data, or other data for an XR experience. In another example, the suitable data may be other data packaged into multiple MSDUs to be transmitted to a second device. The device performing the operations in process 1600 may be a rendering device, and the second device may be a display device.

[0181]

[0209] At 1602, a device renders a plurality of video frames to be provided to a second device.

[0182]

[0210] At 1604, the device divides each video frame of the multiple video frames into multiple video slices. At 1606, the device generates multiple PPDUs to include the video slice, for each video slice. Each PPDU includes one or more MSDUs associated with the video slice (1608). The video slices associated with the one or more MSDUs may be identified by a port number and a DSCP value included in each MSDU (1610). The port number may be an ID of a source port to be used when transmitting the MSDU, and the DSCP value may be a value indicating a unique video frame of the XR experience. In some implementations, the DSCP value is increased for each successive video frame. At 1612, the device queues the MSDU for transmission to a second device, for each video slice. In some implementations, a queue is generated for each video slice.

[0183]

[0211] The process 1600 depicted in Figure 16 is from the perspective of a rendering device. The process 1700 depicted in Figure 17 is similar to the process 1600, but may be from the perspective of a display device.

[0184]

[0212] FIG. 17 shows a flowchart illustrating an example process 1700 for managing data for transmission according to some implementations. The device performing the operations in process 1700 may be a display device, and the second device may be a rendering device. At 1702, the device obtains one or more PPDUs associated with a video frame from the second device. For the one or more PPDUs, the second device renders a plurality of video frames to be provided to the device (1704). The second device divides each video frame of the plurality of video frames into a plurality of video slices (1706). For each video slice, the second device generates a plurality of PPDUs for inclusion in the video slice (1708). Each PPDU includes one or more MSDUs associated with the video slice (1710). The video slices associated with the one or more MSDUs may be identified by a port number and a DSCP value included in each MSDU (1712). For each video slice, the second device queues an MSDU for transmission to the device (1714). The queues may be MSDU queues generated in software for each video slice, and each MSDU queue may be identified by an IP address (such as a target IP address), a port number, and a DSCP value.

[0185]

[0213] FIG. 18 shows a block diagram 1800 illustrating an example of generating a queue for one or more video frames. A video 1802 includes video frames Q and Q+1 (for an integer Q greater than or equal to 1) that are rendered by a rendering device. The rendering device may divide each video frame into video slices. For example, video frame Q includes N video slices (for an integer N greater than or equal to 1), and video frame Q+1 includes N video slices. The rendering device packages each video slice into multiple IP packets (e.g., R IP packets per video slice, for an integer R greater than or equal to 1), and the rendering device packages each IP packet into an MSDU. As described above, the rendering device may identify the MSDU for IP packet 1 of video slice 1 of video frame Q as the first MSDU for video frame Q, and the rendering device may identify the MSDU for IP packet R of video slice N of video frame Q as the last MSDU for video frame Q. The rendering device may identify the MSDU for IP packet 1 of video slice 1 of video frame Q+1 as the first MSDU for video frame Q+1, and the rendering device may identify the MSDU for IP packet R of video slice N of video frame Q+1 as the last MSDU for video frame Q+1. The rendering device creates queue 1 for the MSDU of video slice 1 of video frame Q, queue N for the MSDU of video slice N of video frame Q, queue N+1 for the MSDU of video slice 1 of video frame Q+1, queue 2*N for the MSDU of video slice N of video frame Q+1, etc. Although each video slice is depicted as being packaged into the same number of IP packets, each video slice may be packaged into any suitable number of IP packets.

[0186]

[0214] Each queue may be an MSDU queue generated in software by a rendering device (such as a WCD) and stored in memory of the rendering device. For example, the queues may be generated and stored in memory 508 (FIG. 5) of a WCD 500, which may be implemented in the rendering device. MSDU queues may be identified and tracked by the WCD of the rendering device based on IP addresses, port numbers, and DSCP values ​​assigned to video frames by the rendering device. All MSDUs in a queue are associated with the same IP address, port, and DSCP value.

[0187]

[0215] The DSCP value may be based on the video frame that is intended for the XR experience. In this way, the DSCP value may be application-based. In some implementations, the DSCP value may also be based on the type of video frame. For example, a reference frame (i-frame) of a video includes an i-slice that may be associated with a different DSCP value than an intermediate frame (p-frame) of a video that includes a p-slice. The rendering device uses a previously reserved DSCP value that may be defined by the rendering device and display device as associated with the priority of a specific video slice.

[0188]

[0216] In some implementations, the rendering device assigns a traffic identifier (TID) for each video slice. The TID may be included in an MPDU MAC header of a PPDU for multiple MSDUs associated with the video slice. The TID may be associated with an access category (AC) of the video slice, and the AC may be associated with a priority of the video slice. In this manner, the rendering device can determine to transmit an MSDU of a video slice compared to other data based on a TID indicating that the priority of the video slice is higher than the priority of other data to be transmitted. In some implementations, the priority of a video slice is based on whether the video slice is an i-slice or a p-slice. For example, an i-slice may be associated with a higher priority than a p-slice for transmission by the rendering device (which may be indicated by a different TID).

[0189]

[0217] Based on the identifiers of the MSDU queues for the specific video slices and video frames, the rendering device can schedule MSDUs for transmission in multiple PPDUs to the display device. For example, the rendering device can attempt to transmit MSDUs from the MSDU queue of a first video slice before transmitting MSDUs from the MSDU queue of a next video slice. The display device may be unable to acquire one or more MSDUs from the rendering device (e.g., as a result of interference on the wireless medium). For example, the display device may be unable to provide a BA for a sent PPDU, or the display device may provide a BA indicating which MPDUs (including one or more MSDUs) were successfully acquired.

[0190]

[0218] A video slice is associated with a latency requirement for displaying a video frame at a video device. If one or more MSDUs are not successfully delivered to a display device within an amount of time that allows the display device to display the video frame (e.g., by not receiving a BA indicating one or more MPDUs containing the MSDUs within a set amount of time), the rendering device can move on to providing MSDUs for a different video slice without completing the delivery of the previous MSDU. For example, referring again to FIG. 18 and assuming video frames Q and Q+1 are p-frames, the rendering device generates queues 1 through N and attempts to deliver MSDUs in those queues. As described above, rendering of frames is at defined intervals. The rendering device proceeds to generate queues N+1 through 2*N at a time after generating queues 1 through N. A rendering device generating a new queue associated with the same video slice may indicate that the rendering device should not attempt to deliver any more MSDUs from the previous queue. For example, video slice 1 of video frame Q and video frame Q+1 may refer to the same region of the video frame (e.g., the same line or column between video frames). If queue 1 is not empty (has more MSDUs from queue 1 to be delivered) by the time queue N+1 is generated, the rendering device may stop attempting to deliver the remaining MSDUs in queue 1 and begin serving the MSDUs in queue N+1. As described above, the video slice may be identified by a port number, which may be used to determine that queue N+1 is associated with queue 1. The rendering device may flush queue 1 (with the remaining MSDUs that are considered stale) so that the MSDUs are no longer scheduled for transmission to the display device.In this way, the first MSDU queue (generated for the first p slice) may be flushed after rendering a second p slice associated with the first p slice (e.g., the same video slice of a consecutive p frame) and before providing a PPDU containing one or more MSDUs associated with the first p slice (e.g., a PPDU containing one or more MSDUs that could not be delivered) to the display device.

[0191]

[0219] In some implementations, a rendering device may continue to attempt to deliver an MSDU associated with an i-slice after a new corresponding i-slice or p-slice is generated. For example, an i-slice may be used as a reference frame for intermediate frames in a video generated by a display device from an obtained PPDU. Thus, old i-slices may still be valuable to a display device because they may be used as a reference for a subsequent p-slice (e.g., to decode a successive p-slice). When a rendering device renders a new i-slice or p-slice associated with a previous i-slice, the rendering device may not flush the MSDU queue associated with the previous i-slice. For example, the rendering device may continue to attempt to deliver an MSDU for an i-slice until a threshold number of successive i-slices, p-slices, or a combination thereof have been rendered (e.g., until the second successive i-slice is rendered, or until the number of p-slices until the next i-slice is rendered). Referring again to FIG. 18, based on frames Q and Q+1 being i-frames (one or more p-frames being between the i-frames (not shown)), the rendering device may render the first i-slices of frame Q, generate a first MSDU queue associated with the first i-slices, render the second i-slices of frame Q+1 associated with the first i-slices (e.g., the same video slice of the video frame), generate a second MSDU queue associated with the second i-slices, and further provide a PPDU including one or more MSDUs having the first i-slices after generating the second MSDU queue.

[0192]

[0220] As described above, a PPDU may be attempted to be transmitted by a rendering device a threshold number of times (e.g., five times). The PPDU includes one or more MSDUs of an application file (e.g., a video slice). If the PPDU cannot be delivered after the threshold number of retries, the PPDU is not attempted again to be delivered to the display device. In this manner, the display device may not obtain one or more MSDUs of the video slice, and because some of the MSDUs are missing, the display device may not be able to generate the video slice from the obtained MSDUs. In some implementations, if the PPDU cannot be delivered after the threshold number of retries, the rendering device (e.g., a WCD) may flush an MSDU queue associated with the video slice.

[0193]

[0221] If the MSDU queue is flushed, the rendering device may generate a replacement video slice after flushing the MSDU queue. The replacement video slice may be a new video slice based on the most recently acquired pause frame or a copy of the original video slice. After generating the replacement video slice, the rendering device may generate a replacement MSDU queue associated with the replacement video slice (similar to that depicted in FIG. 18 for other video slices). If the replacement MSDU queue is generated, the rendering device may attempt to transmit MSDUs from the replacement MSDU queue in one or more PPDUs to the display device. Generating the replacement video slice may be based on whether there is enough time to provide a PPDU containing the replacement video slice to the display device for displaying the video frame. For example, the rendering device may determine not to generate a replacement video slice based on the remaining TWT window being less than a threshold amount of time. In this manner, the display device may display a video slice from the previous video frame or not display a video slice for the video frame (which may include a black dot at the position of the video slice).

[0194]

[0222] In addition to, or as an alternative to, flushing MSDU queues based on the number of PPDU retries or the arrival of new video slices, the rendering device can flush MSDU queues based on an explicit command from the application layer. For example, a user of the rendering device can indicate that a portion of an XR experience should be reset or that the XR experience should end. Scheduled MSDUs no longer need to be transmitted. The rendering device can generate an explicit command to flush one or more MSDU queues at the application layer and provide the command to the WCD. The WCD can flush one or more MSDU queues based on the command.

[0195]

[0223] In some implementations, the rendering device indicates to the display device that an MSDU queue has been flushed. The indication may be included in the MAC header of the packet or in a separate control element from the rendering device to the display device. In this way, the display device is made aware of one or more missing MSDUs. The indication may indicate which video slice is associated with the MSDU queue (e.g., by providing the IP address, port number, and DSCP value used to identify the MSDU queue in the MAC header). Based on the indication, the display device may finish storing and processing the MSDUs associated with the indicated video slice. For example, the WCD of the display device may include a reordering (REO) queue to retrieve and store MSDUs until all or a sufficient number of MSDUs are retrieved to restore an application file (e.g., a video slice). The REO queue may retrieve one or more MSDUs from the rendering device. When the display device retrieves an indication that a transmit queue associated with one or more retrieved MSDUs (e.g., an MSDU queue containing one or more MSDUs at the rendering device) has been flushed, the retrieved MSDUs may no longer be used in generating the video slices. In this way, the display device may flush the REO queue after retrieving the indication.

[0196]

[0224] In some implementations, the display device may flush the REO queue if all (or a sufficient number) of MSDUs associated with an application file (e.g., a video slice) have not been obtained. For example, the REO queue may obtain a portion of the MSDUs associated with a video slice, but the REO queue fails to obtain the remainder of the MSDUs associated with the video slice before a REO timeout occurs. The display device may flush the REO queue after not obtaining the remainder of the MSDUs before a REO timeout occurs. In one example, the amount of time for the REO timeout may be the time from when the first MSDU of the application file is obtained to the latest when the last MSDU of the application file should be obtained. In another example, the amount of time for the REO timeout may be the time indicating when a video slice of an entire video frame should be obtained. In some implementations, the amount of time for the REO timeout may be based on the TWT window size. In some implementations, the amount of time for the REO timeout is based on the AC of the video slice (e.g., based on the TID for the video slice). An exemplary REO timeout amount is 10 ms, but any suitable amount of time may be used. The amount of time may be counted from the start of the TWT window or any other suitable starting point for determining whether a REO timeout has occurred. If the display device counts up to the REO timeout amount before it has retrieved all the MSDUs, the display device can flush the REO queue.

[0197]

[0225] In some implementations, the display device can periodically flush the REO queue. For example, the display device can flush the REO queue during a TWT window. In some implementations, the display device can flush the REO queue based on an explicit command generated at the application layer. For example, the XR experience may be reset or terminated by a user of the display device or otherwise by the XR application layer. In this manner, the display device can generate a command to flush the REO queue because the acquired MSDUs are no longer needed.

[0198]

[0226] In contrast to requiring acquisition of all MSDUs of an application file (such as video slices) to generate the application file, using FEC may enable a display device to generate the application file after acquiring only a portion of the MSDUs associated with the application file. For example, each MSDU may include some FEC bits at the end of the payload. The FEC bits from the acquired MSDUs may be sufficient to construct the missing MSDUs. Because a portion of the MSDU payload is reserved as FEC bits, the amount of payload provided in each MSDU may be reduced, and the number of MSDUs for a video slice may be increased. However, the display device may not need to acquire all MSDUs for a video slice to generate the video slice. In some implementations, FEC may be used or not based on the link quality between the rendering device and the display device (such as a Reference Signal Received Power (RSRP) measurement, a Reference Signal Received Quality (RSRQ) measurement, or a Signal-to-Noise Ratio (SNR) measurement measured by the display device). For example, FEC may be used by display and rendering devices when interference increases above a threshold (as indicated by an SNR drop below a threshold) or channel conditions deteriorate below a threshold (as indicated by an RSRP or RSRQ drop below a threshold). In some implementations, FEC may not be used if the frame rate, resolution, or other parameters of the video frames do not allow for the use of FEC while still meeting latency requirements for the video frames. For example, FEC may not be used if the frame rate is greater than a threshold frame rate, if the video frame resolution is greater than a threshold resolution, etc. In some implementations, FEC may be used or not used based on one or more parameters of the display device (such as the channel size, which may affect throughput for the display device, the MCS used to obtain the PPDU, etc.).The use of FEC may be indicated by the display device to the rendering device in one or more pause frames or by the rendering device to the display device in the MAC header of one or more PPDUs.

[0199]

[0227] In some implementations that use FEC per video slice, the display device can indicate to the rendering device when sufficient MSDUs have been obtained to reconstruct the video slice. For example, the display device provides a BA to the rendering device to indicate that a PPDU has been obtained from the rendering device. If the display device determines that the PPDU contains sufficient MSDUs to reconstruct the video slice, the display device can indicate in the BA to the rendering device that a sufficient number of MSDUs have been obtained. For example, an aggregation control (A-Control) field in the MAC header of the BA may be configured to indicate that a sufficient number of MSDUs for the video slice have been obtained. The rendering device can process the A-Control field to determine that no more PPDUs containing MSDUs for the video slice should be provided to the display device (the display device should generate the video slice from the MSDUs already obtained). The rendering device can flush the associated MSDU queue after obtaining the indication.

[0200]

[0228] Changes in the wireless medium and the XR experience may require changes in the rendering device or display device in communicating data to other devices or performing one or more XR operations. For example, as the wireless medium becomes more congested, the display device moves away from the rendering device, or more interference exists on the wireless medium, the rendering device and display device may adjust one or more parameters to reduce the amount of information to be communicated between the devices. Exemplary parameters may be associated with the XR experience (such as video frame rate, frame resolution, color palette, etc., which affect the size of the video or wireless channel, channel size, MCS, FEC use, TWT window size, etc., and thus affect the bit rate between devices and the success in delivering data between devices for the XR experience). The rendering device and display device may be configured to provide feedback to the other device regarding the provided data, and the devices may be configured to adjust the XR experience based on the feedback. For example, the rendering device may generate feedback based on sending a PPDU to the display device, and the display device may generate feedback based on sending a pause frame to the rendering device.

[0201]

[0229] 19 shows a flowchart illustrating an example process 1900 for generating feedback according to some implementations. The device performing the example process 1900 may be a rendering device, and the second device may be a display device. At 1902, the device attempts to provide to the second device multiple PPDUs associated with one or more video frames of an XR experience.

[0202]

[0230] At 1904, the device measures one or more of a PPDU transmission latency or a PPDU transmission drop associated with attempting to provide multiple PPDUs. For example, the rendering device may observe when a BA is not obtained for one or more PPDUs transmitted to the display device. In some implementations, the rendering device may determine that a PPDU transmission drop occurred when a BA is not obtained for a transmitted PPDU. In some implementations, the rendering device may determine that a PPDU transmission drop occurred when the rendering device reaches a maximum number of retries for a PPDU and the rendering device no longer attempts to deliver the PPDU. The rendering device may count the total number of PPDU transmission drops over time. The time may exceed a TWT window, a set number of TWT windows, a set amount of time, or another suitable amount of time. In some implementations, the rendering device may determine a PPDU transmission drop rate, which may be the number of PPDU transmission drops divided by the total number of PPDUs attempted to be transmitted to the display device.

[0203]

[0231] The rendering device can determine a PPDU transmission latency based on a BA obtained for a PPDU delivered to a display device. For example, the rendering device tracks the time when a PPDU is transmitted to the display device (e.g., based on the rendering device's WCD clock). The rendering device also tracks the time when a BA associated with the PPDU is obtained from the display device (e.g., based on the rendering device's WCD clock). The rendering device can determine a PPDU transmission latency for a PPDU to be the difference between the time when the PPDU is transmitted and the time when the BA is obtained. In some implementations, the rendering device can determine an average PPDU transmission latency, a median PPDU transmission latency, or a distribution of PPDU transmission latency compared to the number of PPDU transmissions.

[0204]

[0232] The one or more measurements (including PPDU transmission latency or PPDU transmission dropout) are associated with one or more parameters of the XR experience, and the one or more parameters of the XR experience may be adjusted after the one or more measurements (1906). In some implementations, the PPDU transmission latency and PPDU transmission dropout may indicate whether channel conditions are improving (based on less interference, a display device moving closer to the rendering device, etc.) or deteriorating (based on more interference, a display device moving away from the rendering device, etc.). The measurements may also indicate whether throughput to the display device is increasing or decreasing. Based on the measurements, the rendering device (and the display device) may determine whether one or more parameters of the XR experience should be adjusted to ensure that video (or other data of the XR experience) still meets latency and packet loss requirements. For example, the rendering device may reduce the channel size, increase the MCS, or use FEC if PPDU transmission dropout increases. Reducing the channel size, increasing the MCS, or using FEC results in a decrease in throughput to the display device. If the reduced throughput is less than the throughput required for the current video, the rendering device may adjust one or more video parameters (such as reducing the resolution, frame rate, etc.). The measurements or adjustments may be communicated to the display device, which may implement the one or more adjustments.

[0205]

[0233] The process 1900 depicted in Figure 19 is from the perspective of a rendering device that generates the feedback. The process 2000 depicted in Figure 20 may be from the perspective of a display device that generates the feedback.

[0206]

[0234] 20 shows a flowchart illustrating an example process 2000 for generating feedback according to some implementations. The device performing the example process 2000 may be a display device, and the second device may be a rendering device. At 2002, the device attempts to provide a plurality of pose data frames associated with one or more video frames of an XR experience to the second device. In some implementations, the device also attempts to provide tracking frames to the second device.

[0207]

[0235] In 2004, the device measures one or more of a pause data frame transmission latency or a pause data frame transmission loss associated with attempting to provide multiple pause data frames. For example, the display device may observe when a BA is not obtained for one or more pause data frames transmitted to the rendering device. In some implementations, the display device may determine that a pause data frame transmission loss occurs when a BA is not obtained for a transmitted pause data frame. In some implementations, the display device may determine that a pause data frame transmission loss occurs when the display device reaches a maximum number of retries for a pause data frame. The rendering device may count the total number of pause data frame transmission losses over time. The time may exceed a TWT window, a set number of TWT windows, a set amount of time, or another suitable amount of time. In some implementations, the display device may determine a pause data frame transmission loss rate, which may be the number of pause data frame transmission losses divided by the total number of pause data frames attempted to be transmitted to the rendering device.

[0208]

[0236] The display device can determine a pause data frame transmission latency based on a BA obtained for a pause data frame delivered to a rendering device. For example, the display device tracks the time at which a pause data frame is transmitted to the rendering device (e.g., based on a WCD clock of the display device). The display device also tracks the time at which a BA associated with the pause data frame is obtained from the rendering device (e.g., based on a WCD clock of the display device). The display device can determine a pause data frame transmission latency for the pause data frame to be the difference between the time at which the pause data frame was transmitted and the time at which the BA was obtained. In some implementations, the display device can determine an average pause data frame transmission latency, a median pause data frame transmission latency, or a distribution of pause data frame transmission latencies compared to the number of pause data frame transmissions.

[0209]

[0237] Similar to what was described above with reference to FIG. 19 , one or more measurements (including pause data frame transmission latency or pause data frame transmission dropout) are associated with one or more parameters of the XR experience, and the one or more parameters of the XR experience may be adjusted after the one or more measurements (2006). In some implementations, the pause data frame transmission latency and pause data frame transmission dropout may indicate whether channel conditions are improving (based on less interference, a display device moving closer to the rendering device, etc.) or whether channel conditions are deteriorating (based on more interference, a display device moving away from the rendering device, etc.). Based on the measurements, the display device (and rendering device) can determine whether one or more parameters of the XR experience should be adjusted to ensure that the video (or other data of the XR experience) still meets the latency and packet loss requirements (as described above). The measurements or adjustment values ​​may be communicated to the rendering device, and the rendering device can implement the one or more adjustment values.

[0210]

[0238] Referring back to the rendering device, the rendering device can acquire one or more pause data frames from the display device (each of the one or more video frames is associated with a pause data frame). The one or more measurements may include measurements based on the acquired pause data frames. In some implementations, the rendering device can measure a pause data frame delivery latency associated with acquiring one or more pause data frames. For example, with a known TWT window start time and a pause data frame that should be delivered at the start of the TWT window, the rendering device can determine the difference between the TWT window start time and the time the pause data frame was acquired (the time is based on the WCD clock of the rendering device). In some implementations, the time of the IMU measurement is included in the pause data frame (e.g., the time indicated by the application layer of the display device). Because the WCD clock of the rendering device and the application layer clock of the display device can be synchronized, the rendering device can determine the difference between the time of the IMU measurement and the time of acquiring the pause data frame. The rendering device can determine an average pause data frame transmission latency, a median pause data frame transmission latency, or a distribution of pause data frame transmission latency compared to the number of pause data frame deliveries (e.g., compared to a defined number of TWT windows or a defined amount of time).

[0211]

[0239] The one or more measurements by the rendering device may include a frequency of missing or delayed pause data frames. In some implementations, the rendering device determines whether one or more pause data frames are missing or delayed. For example, a display device may attempt to provide a pause data frame at the start of each TWT window until a timeout. If the rendering device does not obtain a pause data frame before the timeout, the rendering device may determine that a pause data frame is missing or delayed. The rendering device may count the number of missing or delayed pause data frames compared to a determined number of TWT windows. If the number increases as successive TWT windows occur, the rendering device determines that the frequency of missing or delayed pause data frames has increased. If the number decreases as successive TWT windows occur, the rendering device determines that the frequency of missing or delayed pause data frames has decreased. In some implementations, the frequency may be the number of missing or delayed pause data frames divided by the determined number of TWT windows used in determining whether any pause data frames are missing or delayed.

[0212]

[0240] Referring back to the display device, the REO queue of the display device can retrieve one or more MSDUs from the rendering device. As described above, each MSDU may be associated with an application file (e.g., a video slice). The display device can flush the REO queue one or more times to remove one or more MSDUs from the REO queue. For example, the display device can flush the REO queue based on obtaining an indication that a transmit queue at the rendering device (e.g., an MSDU queue of the rendering device associated with an MSDU in the REO queue of the display device) has been flushed. In another example, the display device can flush the REO queue periodically (e.g., during a TWT window). In another example, the display device can flush the REO queue if a timeout occurs (e.g., not all MSDUs or a sufficient number of MSDUs are received within a defined amount of time to allow construction of a video slice for display). In another example, the display device can flush the REO queue if an MSDU for a subsequent video slice is retrieved before retrieving the remainder of the MSDUs for the previous video slice. In another example, the display device can flush the REO queue based on a command from an application layer of the display device. The one or more measurements at the display device may include an REO flash time associated with flashing the REO cue. In some implementations, the display device counts the number of times the REO cue is flashed compared to a defined amount of time (such as a TWT interval or number of TWT intervals). The REO flash time may be the average number of flashes per TWT interval, the total number of flashes counted by the display device, or another suitable indication of the number of times the REO cue is flashed by the display device.

[0213]

[0241] The one or more measurements at the display device may also include video frame delivery latency. For example, for one or more video frames, the display device obtains (e.g., in the REO queue) a first MSDU associated with the video frame. As described above, the first MSDU may include metadata to indicate that the MSDU is the first MSDU for the video frame. The display device also obtains a last MSDU associated with the video frame, which may include metadata to indicate that the MSDU is the last MSDU for the video frame. In some implementations, the first and last MSDUs may be identified by DSCP values ​​included in the MSDUs. The display device may measure video frame delivery latency associated with obtaining the first and last MSDUs for the video frame. For example, the display device may determine, from the WCD clock of the display device, the time when the first MSDU was obtained and the time when the last MSDU was obtained. The display device may determine the difference between when the first MSDU was obtained and when the last MSDU was obtained as the video frame delivery latency for the video frame. In some implementations, the display device can determine an average delivery latency, a median delivery latency, or a distribution of delivery latencies for several video frame delivery latencies.

[0214]

[0242] An increase in the delivery latency of pause data frames or video frames, the frequency of dropped or missing pause data frames, or the flush time may indicate that channel conditions are deteriorating or that the throughput between devices is somehow limited. Conversely, a decrease in the delivery latency of pause data frames or video frames, the frequency of dropped or missing pause data frames, or the flush time may indicate that channel conditions are improving or that the throughput between devices is increasing.

[0215]

[0243] The one or more measurements at the display device may also include one or more of jitter buffer underflows or overflows, or missing packets associated with a video slice to be displayed. As described above, the display device may perform jitter elimination when processing video frames before display. Jitter elimination uses a jitter buffer of video frame information to enable smooth display of the video frames. If the data in the buffer falls below a lower threshold, the display device may determine a jitter buffer underflow, and if the data in the buffer exceeds an upper threshold, the display device may determine a jitter buffer overflow. Underflows (resulting in a lack of data) and overflows (resulting in too much data such that some data may be leaking from the buffer) may adversely affect jitter elimination by the display device. In some implementations, the display device may count the total number of overflows or underflows, and the average buffer utilization, or other metrics, compared to a defined amount of time associated with the jitter buffer.

[0216]

[0244] The missing packets associated with the video frames to be displayed may include missing video slices. The display device may display one or more video frames missing one or more video slices. In some implementations, the one or more measurements include a count of the number of video frames displayed missing one or more video slices, the number of missing video slices, or another suitable metric of missing packets compared to a defined amount of time.

[0217]

[0245] In the case of a rendering or display device, the one or more measurements may include a link quality measurement of the link quality between the rendering or display device. For example, the display or rendering device may measure RSRP, RSRQ, SNR, or other metrics indicative of the link quality between the devices. A change in the link quality metric may indicate deteriorating or improving channel conditions.

[0218]

[0246] Based on one or more heuristics for one or more measurements (such as one or more thresholds for the measurements) or based on any suitable machine learning model for the one or more measurements, the rendering device or display device can adjust one or more parameters of the XR experience to ensure that latency requirements for the XR experience are met. The one or more parameters of the XR experience may include one or more wireless communication parameters between the rendering device and the display device. Adjusting the one or more wireless communication parameters may include one or more of the following: Adjusting the duty cycle of the TWT window for the TWT power saving mode. The duty cycle can be the length of the TWT window compared to the amount of time outside the TWT window during the TWT window interval. -Enable or disable TWT power saving mode. - Changing the wireless operating channel through which a rendering or display device communicates. - Adjusting wireless operating channel size (such as increasing or decreasing channel size between 20MHz, 40MHz, 80MHz, 80+80MHz, and 160MHz). -Adjusting the MCS. -Enabling or disabling FEC for delivering PPDUs from a rendering device to a display device; or - Adjusting the FEC (such as the code rate of the FEC, which may be related to the number of bits in the payload that should be used for the FEC).

[0219]

[0247] In some implementations, the one or more parameters of the XR experience may include one or more video parameters. Adjusting the one or more video parameters may include adjusting one or more of a video frame rate, a video resolution (such as a frame resolution), a target encoding data rate (also referred to as an encoding bit rate), or a video codec. In some implementations, a rendering device may adjust a rendering rate of video frames based on the video frame rate, the video resolution, the encoding bit rate, or the video codec. In some implementations, a display device may adjust a display rate of video frames based on the video frame rate. Each of the video resolution, the encoding data rate, and the video codec is a trade-off between video quality and file size. For example, the selection of a video codec is based on balancing compression of the video with video quality. The rendering device may adjust the video resolution, the target encoding data rate, or the video codec (such as by switching between available codecs for encoding the video) to balance video quality with file size and latency requirements.

[0220]

[0248] In some implementations, adjusting one or more parameters may include adjusting a functional division of computational tasks between a display device and a rendering device, or between a relay STA to the display device and another device communicatively coupled to the relay STA. For example, based on one or more measurements, the display device may determine that some rendering should be performed at the display device (e.g., when a link to the rendering device is determined to be poor (e.g., link quality is below a threshold or indicated as poor)). For example, one or more p-frames may be rendered at the display device. In this way, fewer PPDUs should be transmitted from the rendering device to the display device. Similarly, if an AP or another STA is to render video frames and the rendered frames are relayed to the display device via a relay STA, the relay STA may determine, based on one or more measurements, that rendering of one or more video frames should be performed at the relay STA instead of the other STA or AP.

[0221]

[0249] A display or rendering device can indicate to other devices one or more measurements or adjustments made to one or more parameters of an XR experience. In some implementations, a device can provide an indication of one or more measurements to other devices in an A-Control field of the header of one or more packets provided to the other device. The one or more packets may be included in an RTS or CTS frame (if RTS / CTS is enabled, such as for asynchronous channel access), a data frame (such as one or more PPDUs from the rendering device to the display device, or one or more pause data frames from the display device to the rendering device), or a BA frame (such as a BA to the rendering device associated with obtaining a PPDU, or a BA to the display device associated with obtaining a pause data frame). An exemplary A-Control field may be a variant of the HE control field (HE A-Control field) defined within the IEEE 802.11ax standard. In one example, the A-Control field may be included in the frame control field of the MAC header of an RTS or CTS frame. In another example, the A-Control field may be included in the non-legacy field 212 of the exemplary PDU of FIG. 2A. In another example, the A-Control field may be included in the Frame Control field of the MAC header 412 in the MPDU sub-frame 406 of Figure 4. In another example, the A-Control field may be included in the Frame Control field of the MAC header of a BA frame.

[0222]

[0250] FIG. 21 shows a block diagram of an exemplary control field 2100. The control field 2100 may be a simplified version of the A-Control field included in one or more frames. The actual A-Control field may include additional subfields not shown (such as an end of header (EOH)). The control field includes a control identifier (ID) subfield 2102 and a control information subfield 2104. The control ID in subfield 2102 indicates what type of control information is included in subfield 2104. For example, based on the HE control field, subfield 2102 may include different numbers as control IDs for different control information. A control ID of 0 may indicate that subfield 2104 includes an ACK, a control ID of 2 may indicate that subfield 2104 includes a BA, and so on. The IEEE 802.11ax standard reserves some control IDs from use.

[0223]

[0251] In some implementations, an A-Control field (such as subfield 2102) includes a reserved control ID to indicate that the A-Control field includes one or more measurements from a display device or a rendering device (such as subfield 2104 being used to include one or more measurements). The reserved control ID may be defined in both the rendering device and the display device to enable encoding and decoding of the A-Control field. In some implementations, different control IDs may be used for different types of measurements.

[0224]

[0252] In some implementations, an A-Control field (such as subfield 2102) includes a reserved control ID to indicate that one or more adjusted parameters are included in the A-Control field (such as subfield 2104 being used to include an indication of one or more adjusted parameters). The reserved control IDs may be defined in both the rendering device and the display device to enable encoding and decoding of the A-Control field. In some implementations, different control IDs may be used for different types of adjustment values.

[0225]

[0253] In indicating one or more measurements, the A-Control field may include an indication of link quality (which may be measured by a rendering or display device, as described above). In some implementations, the link quality may be indicated in binary form as good or bad. For example, if the device measures the SNR, the device may compare the SNR to a threshold. If the SNR is less than the threshold, the link quality may be considered poor. If the SNR is greater than the threshold, the link quality may be considered good. The A-Control field (such as subfield 2104) may include bits reserved to indicate link quality (e.g., 0 for poor and 1 for good). The remaining bits of the subfield may be used to indicate one or more measurements or adjustments to one or more parameters based on the one or more measurements.

[0226]

[0254] In this way, the display device and the rendering device can provide feedback to each other and adjust the XR experience as needed. Providing feedback may be performed for both asynchronous and synchronous channel access. Although the feedback and adjustments are described with reference to an XR experience, the operations for measuring and providing feedback described above may also be applied to other types of data and other types of applications.

[0227]

[0255] 1B , device 154 can support simultaneous links with a first device 152 (such as a display device) and a second device 158 (such as an AP of a BSS or another STA in a mesh network). In some implementations, link 156 may be in the 5 GHz or 6 GHz frequency spectrum, and link 160 may be in the 5 GHz or 6 GHz frequency spectrum. Device 154 is configured to support simultaneous links while further supporting an XR experience (such as prioritizing XR traffic and otherwise managing XR operation to meet latency and other requirements for the XR experience).

[0228]

[0256] Simultaneous links may be managed using TWT sessions (as described above, the AP or other STAs communicate outside the TWT window for display and rendering devices). For legacy devices that do not support TWT, simultaneous links may be supported using multi-link operation (MLO) techniques (as defined within the IEEE 802.11 standard).

[0229]

[0257] 22 shows a flowchart illustrating an example process 2200 for supporting simultaneous wireless links with multiple devices. The example process 2200 may be performed by a WCD (such as a WCD included in a rendering device or another suitable device that supports simultaneous wireless links with a first device and a second device). In some implementations, the second device is a display device. In some implementations, the first device may be an AP (in a BSS) or another STA (in a mesh network). Although the example process 2200 is described below as being performed by a rendering device or a WCD of a rendering device for clarity, the example process 2200 may be performed by any suitable device.

[0230]

[0258] At 2202, a rendering device (such as a WCD of the rendering device) communicates with a first device over a first wireless link, for example, the rendering device communicates with an AP or another STA.

[0231]

[0259] At 2204, the rendering device communicates with a second device via a second wireless link. For example, the rendering device communicates with a display device via a first wireless link configured between the rendering device and the display device for an XR experience. The WCD simultaneously communicates with the first device and the second device using one of an MLO technique or a TWT mode (2206). TWT mode techniques (also referred to as TWT) may include the operations described above with reference to synchronous channel access, application-based data management, and feedback generation. MLO techniques may be similar to some TWT mode techniques, but may be supported by legacy devices that do not support TWT.

[0232]

[0260] The WCD is configured to give preference to communications on the second wireless link over communications on the first wireless link (2208). For example, the second wireless link may be between a rendering device and a display device for an XR experience. XR data to be transmitted between the rendering device and the display device (such as PPDUs, pause data frames, and tracking frames) is associated with latency and packet loss requirements associated with the XR experience. In this manner, communications between the rendering device and the display device may be more important than communications between the rendering device and other devices (such as an AP or a rendering device that attempts to send best-effort classified traffic to other devices). Example operations for a WCD to give preference to communications on the second wireless link over communications on the first wireless link are described in further detail below.

[0233]

[0261] Simultaneously communicating with a first device (such as an AP) and a second device (such as a display device) may include: The WCD should transmit to a second device while receiving one or more packets from a first device (eg, transmitting to a display device while receiving from an AP). The WCD should acquire one or more packets from a second device while receiving one or more packets from a first device (e.g., receiving from a display device while receiving from an AP). The WCD should transmit to a second device while transmitting to a first device (such as transmitting to a display device while transmitting to an AP); or The WCD should get one or more packets from a second device while transmitting to a first device (eg, receiving from a display device while transmitting from an AP).

[0234]

[0262] Typical MLO techniques are defined to prevent transmission on a link when reception is in progress on another link. For example, allowing transmission on a wireless link may be based on a clear channel assessment (CCA) of the wireless medium (including both wireless links). If the CCA indicates that the wireless medium is occupied (such as when the WCD is receiving from a first device), the WCD ceases transmission. In this way, when a WCD is configured for typical MLO, the WCD prevents transmission to a second device over a second wireless link when receiving from a first device over a first wireless link, and the WCD ceases transmission to a first device over a first wireless link when receiving from a second device over the second wireless link. Typical MLO techniques can prevent communication between a rendering device and a display device that would adversely affect the XR experience (such as by not meeting certain latency requirements). If MLO techniques are to be used by a rendering device for simultaneous link support, the WCD of the rendering device may be configured to extend the MLO techniques (and other MAC operations) to provide preferential treatment for communication with the display device. For example, the WCD may enable transmission to the display device while receiving from another device (such as an AP or STA). In some implementations, the WCD may be configured to ignore CCA when the WCD is to transmit to the display device. Exemplary adjustments to MLO techniques for different exemplary simultaneous communication are described below.

[0235]

[0263] One exemplary simultaneous communication includes a WCD receiving one or more packets from a first device and the WCD transmitting to a second device. For example, a rendering device may be in the process of obtaining one or more packets from an AP or STA. While obtaining the one or more packets, the rendering device may determine that the rendering device should transmit to a display device (e.g., transmitting one or more PPDUs associated with one or more video frames). The WCD may transmit to the second device prior to completing reception of the one or more packets from the first device. For brevity and clarity in describing aspects of the present disclosure, the examples described herein exclusively refer to the WCD or the device managing the simultaneous link as the rendering device, the second device as the display device, and the first device as the AP. Note that the examples are not limited to a rendering device, a display device, an AP, or any other particular device.

[0236]

[0264] A rendering device should typically provide a BA to the AP after obtaining one or more packets via a first wireless link. If transmission via a second wireless link to a display device is still in progress when the rendering device should provide a BA to the AP, the CCA should indicate that the wireless medium is busy, and the rendering device should stop providing a BA to the AP. The rendering device obtains a BA from a display device after transmitting to the display device (e.g., obtaining a BA from the display device after delivering a PPDU to the display device). Based on a typical MLO, if the end of reception from the AP coincides with the end of transmission to the display device, the CCA at the rendering device should not stop the rendering device from providing a BA to the AP. However, the BA from the display device may be provided to the AP at approximately the same time that it should be obtained. If the BA to the AP and the BA from the display device overlap on the wireless medium, the rendering device may not successfully obtain a BA from the display device. Not obtaining a BA causes the rendering device to retry transmission to the display device (which increases latency in delivering data to the display device).

[0237]

[0265] In some implementations extending MLO, a rendering device (such as a WCD) prevents the AP from providing a BA to acknowledge receipt of one or more packets. In this way, the BA obtained from the display device is not interfered with by the BA to the AP. For example, the rendering device may determine whether the WCD is in a transmit mode for a second wireless link. If the WCD is in a transmit mode for the second wireless link, the rendering device may prevent providing a BA over the first wireless link. If the rendering device should stop sending a BA to the AP for one or more packets, communication of the one or more packets over the first wireless link may be considered failed. If the AP does not obtain a BA from the rendering device, the AP may later retry sending the one or more packets to the rendering device (with increased latency for delivering the one or more packets from the AP). Increasing the latency on the first wireless link compared to increasing the latency on the second wireless link may be acceptable based on latency requirements between the rendering device and the display device (e.g., for an XR experience).

[0238]

[0266] Another example of simultaneous communication includes a rendering device receiving one or more packets from an AP and a rendering device receiving one or more packets from a display device. For example, the rendering device may be receiving from the AP over a first wireless link when a pause data frame, tracking frame, or other packet is provided by the display device over a second wireless link. The rendering device obtains one or more packets from the display device while receiving the one or more packets from the AP. The rendering device provides a BA to the display device after obtaining the one or more packets from the display device. In some implementations, to prevent interference with reception of information from the display device, the rendering device can stop providing a BA to the AP to acknowledge receipt of one or more packets from the AP. For example, transmission on a first one or more antennas over a first wireless link may cause localized interference on a second one or more antennas receiving over the second wireless link. Stopping transmission of a BA to the AP prevents localized interference from occurring in reception from the display device.

[0239]

[0267] Another example of simultaneous communication includes a rendering device transmitting to an AP and a rendering device transmitting to a display device. For example, the rendering device may be transmitting to an AP over a first wireless link when the rendering device determines to transmit one or more PPDUs to the display device over a second wireless link. If data arrives at the WCD for transmission (such as one or more MSDUs to be included in one or more PPDUs transmitted to the display device) simultaneously with an ongoing transmission to the AP, a typical MLO technique would request the rendering device to determine a CCA (which would indicate that the wireless medium is busy). In this way, the rendering device would delay transmission to the display device (increasing latency over the second wireless link). One or more extensions to the MLO technique may be applied to attempt to avoid or reduce such delays in transmission to the display device.

[0240]

[0268] In one exemplary extension to the MLO technique, the rendering device synchronizes transmission to the display device with transmission to the AP. For example, the start of transmission to the AP and the display device may be synchronized. Synchronizing the start of transmission may be based on a transmission schedule or a known transmission period from the rendering device to the display device. For example, rendering video frames may be at regular intervals, and MSDUs are available for transmission at the regular intervals (which may vary within an allowable amount of time associated with any latency, such as UL latency or rendering latency). Before the rendering device starts transmitting to the AP, the rendering device may determine whether the current time is within a threshold amount of time at which the MSDU should be transmitted to the display device. If so, the rendering device may delay transmission to the AP to synchronize transmission to the AP and the display device. In some implementations, if a BO is used to obtain control of the wireless medium or otherwise transmit to a display, the rendering device may reduce a BO associated with a second wireless link to synchronize transmission over the first wireless link with transmission over the second wireless link.

[0241]

[0269] The transmission to the display device may be shorter than the transmission to the AP. If the transmission to the display device finishes first, the BA may be transmitted by the display device while the rendering device is still transmitting to the AP (which may affect the rendering device receiving the BA). In some implementations that synchronize transmissions, the rendering device may lengthen the transmission to the display device to synchronize the end of the transmission to the AP with the end of the transmission to the display device. Exemplary padding may include zero padding or adding any suitable tail to the transmission to the display device to synchronize the end of the transmission. The rendering device may determine the amount of padding to apply based on the amount of data scheduled to be transmitted to the AP, the amount of data scheduled to be transmitted to the display device, and the measured throughput over the first wireless link and the second wireless link. In some implementations, a reduced BO associated with the second wireless link may compensate for the padding such that latency over the second wireless link is not affected.

[0242]

[0270] In another exemplary extension to the MLO technique, a rendering device may refrain from transmitting to an AP outside of one or more time division multiplexing (TDM) windows. A TWT session may be conceptualized as a form of time division multiplexing of the wireless medium. For example, communication between a rendering device and a display device may be during the TWT window, and communication between the rendering device and another device (such as an AP or STA) may be outside the TWT window. As mentioned above, some legacy devices do not support TWT. A wireless system including one or more legacy devices may be configured to share a wireless medium using TDM windows. For example, an AP of a BSS including a rendering device and a display device may configure one or more TDMs to communicate with the rendering device. Configuring the TDM window may include configuring a window length, period, and other parameters for the TDM window. In this way, transmissions from the rendering device to the AP are during one or more TDM windows, and transmissions from the rendering device to the display device (such as PPDUs sent to the display device) are outside the one or more TDM windows. With a defined TDM window, the maximum delay for transmission to a display device (outside the TDM window) is based on the remaining length of the current TDM window.

[0243]

[0271] In another exemplary extension to the MLO technique, the rendering device may reduce the maximum PPDU duration or burst duration. The PPDU duration may be based on the size and throughput of the PPDU. If the maximum PPDU duration is reduced, the maximum amount of time for transmitting the PPDU may be reduced. The burst duration may be the amount of time for which the rendering device should transmit the PPDU to the display device. Reducing the burst duration reduces the amount of time for which the wireless medium should be reserved exclusively for transmission to the display device. Reducing the amount of time to be reserved for transmitting the PPDU or the duration of transmission to the display device allows the rendering device to more quickly schedule new PPDU transmissions or new TXOPs associated with the burst duration. In this manner, potential delays for transmissions to the display device may be reduced by reducing the maximum PPDU duration or burst duration.

[0244]

[0272] In another exemplary enhancement to the MLO technique, the rendering device can suspend transmission to the AP, such that the rendering device is no longer transmitting to the AP. As described above, one or more MSDUs are ready to be transmitted by the rendering device to the display device while the rendering device is transmitting to the AP. Packets to be transmitted to the AP are included in a transmit buffer of the rendering device's WCD. To suspend transmission to the AP, the rendering device can flush packets from a transmit buffer associated with transmission to the AP. When the transmit buffer is empty, transmission to the AP terminates. In this manner, when the rendering device performs CCA for transmission over the second wireless link, the CCA can indicate that the wireless medium is free for the rendering device to transmit to the display device over the second wireless link.

[0245]

[0273] In another exemplary enhancement to the MLO technique, a rendering device can use a CTS-to-Self frame to enhance the reservation of the wireless medium for transmission to the display device. For example, when the rendering device transmits to the AP, the wireless medium is reserved for the rendering device (as described above with respect to the CTS / RTS mechanism between the rendering device and the display device). Once the reservation ends, other devices may contend for or be scheduled to transmit over the wireless medium, and the rendering device can wait for the other devices to finish occupying the wireless medium. In some implementations, when the rendering device has an MSDU ready for transmission to the display device, the rendering device determines an amount of time to transmit the MSDU (e.g., based on the amount of data in one or more MSDU queues associated with the second wireless link). The rendering device also determines an amount of time remaining to transmit to the AP (e.g., based on the amount of data remaining in a transmit buffer associated with the first wireless link). The rendering device can determine whether any time remains from the reservation based on the amount of time remaining to transmit to the AP, and the rendering device can determine an additional amount of time in the reservation to allow for transmitting the MSDU to the display device during the same reservation. In this way, transmissions to the AP and transmissions to the display device may occur during the same reservation (reducing latency compared to requiring a new reservation for the transmission to the display device). To extend the reservation of the wireless medium, the rendering device may broadcast a CTS-to-Self frame. The CTS-to-Self frame may indicate an extended period of time for which the wireless medium will be reserved (e.g., a value to be added to the current NAV of each device that obtains the CTS-to-Self frame). As described above, the extended period of time is a period of time long enough to include the transmission to the AP and the transmission to the display device.

[0246]

[0274] Another example of simultaneous communication includes a rendering device transmitting to an AP and a rendering device retrieving one or more packets from a display device. For example, the rendering device may be transmitting to an AP over a first wireless link while the display device is transmitting a pause data frame or a tracking frame over a second wireless link. If the rendering device is transmitting over the second wireless link while a packet is being sent by the display device to the rendering device, the rendering device may not be able to retrieve the packet from the display device. If the rendering device does not retrieve the packet from the display device, the rendering device does not provide a BA to the display device, and the display device retransmits the packet to the rendering device. Based on a typical MLO technique, the display device may continue to attempt to transmit the packet until the packet is successfully delivered or a maximum number of retries have been exhausted. As the display device continues to retry, transmission parameters may be adjusted to attempt to increase the likelihood that the packet will be delivered. For example, the display device may increase the MCS, use FEC, and reduce the transmission rate. The transmission rate may continue to decrease, which would cause problems in meeting latency requirements for the XR experience.

[0247]

[0275] The MLO technique may be extended to avoid or reduce transmission delays or prevent adjusting transmission parameters at the display device that may adversely affect communication latency between the display device and the rendering device. In one exemplary extension to the MLO technique, one or more TDM windows may be used to prevent packets from being transmitted by the display device during the TDM windows. The TDM windows reserve the wireless medium for communication between the rendering device and the AP (as described above). For example, transmissions to the AP are during the one or more TDM windows, and receptions from the display device are outside the one or more TDM windows. In this way, the rendering device is prevented from obtaining one or more packets from the display device during the one or more TDM windows.

[0248]

[0276] In another exemplary extension to the MLO technique, the rendering device may reduce the maximum PPDU duration or burst duration. As described above, reducing the maximum PPDU duration or burst duration reduces the amount of time the rendering device transmits to the AP. In this way, the amount of time the display device must retry transmitting to the rendering device is reduced (which reduces the delay associated with the display device transmitting to the rendering device).

[0249]

[0277] In another example enhancement to the MLO technique, a rendering device can indicate to a display device that the wireless medium should be busy for an amount of time associated with transmitting to the AP. For example, the rendering device can provide a frame to the display device indicating a NAV value to reserve the wireless medium for the duration of the transmission to the AP. In some implementations, the NAV value can be included in a PPDU transmitted from the rendering device to the display device. In this manner, the display device can set its NAV to the indicated NAV value to cease transmitting to the rendering device for the indicated duration.

[0250]

[0278] Although the use of TDM windowing and other MLO techniques has been described with reference to legacy devices that do not support TWT, the described techniques may be implemented in any device (including devices that support TWT). Additionally or alternatively, the techniques may be applied outside of MLO, and the techniques are not limited to any particular simultaneous link support implementation.

[0251]

[0279] In addition to or as an alternative to using MLO techniques to support simultaneous links, a rendering device can support simultaneous links using TWT. In some implementations, a rendering device (or display device) can configure a first TWT session with a display device for communication with the display device over a second wireless link, and the rendering device can configure a second TWT session with an AP for communication with the AP over the first wireless link. The first TWT session includes a first plurality of TWT windows, and the first plurality of TWT windows are associated with XR activity at the rendering device (such as obtaining one or more pause data frames or tracking frames from the display device, rendering one or more video frames, and providing one or more video frames to the display device via one or more PPDUs). The second TWT session includes a second plurality of TWT windows interspersed among and non-overlapping with the first plurality of TWT windows. For example, the TWT windows may alternate (such as a TWT window from a first plurality of TWT windows, a TWT window from a second plurality of TWT windows, a TWT window from the first plurality of TWT windows, etc.) In this manner, the rendering device communicates with the display device during the first plurality of TWT windows, and the rendering device communicates with the AP during the second plurality of TWT windows.

[0252]

[0280] The first TWT session is configured by the rendering device or display device to meet any latency or packet loss requirements associated with the XR experience. After the first TWT session is established, the rendering device can begin configuring a second TWT session with the AP, where the second TWT session includes a TWT window outside the TWT window of the first TWT session. When the second TWT session is configured based on the first TWT session, the first TWT session may be considered the primary TWT session, and the second TWT session may be considered a secondary TWT session. As described above, the AP may be an IEEE 802.11ax-enabled AP that supports TWT (including the second TWT session with the rendering device).

[0253]

[0281] As described above with respect to feedback and adjustment, the first TWT session may be adjusted (e.g., adjusting the TWT window length, interval, etc.). The rendering device or display device may adjust the first TWT session without reference to the second TWT session. In this manner, the first TWT session may be adjusted to cause a conflict with the second TWT session (e.g., overlapping TWT windows from two TWT sessions). After the first TWT session is adjusted, the rendering device may begin adjusting the second TWT session with the AP to avoid overlapping TWT windows. In this manner, the second TWT session is adjusted based on the adjustment to the first TWT session.

[0254]

[0282] When configuring or adjusting a TWT session, the rendering device can act as a STA with respect to the AP and as a STA with respect to the display device. In this manner, the rendering device may be conceptualized as having a STA-associated MAC and a SAP-associated MAC supported by the rendering device's WCD. The SAP-associated MAC is used when configuring and adjusting a first TWT session with the display device, and the STA-associated MAC is used when configuring and adjusting a second TWT session with the AP. If the first TWT session is the primary TWT session, after configuring or adjusting the first TWT session, information or changes regarding the first TWT session are communicated from the SAP-associated MAC to the STA-associated MAC. In response to obtaining information or changes to the first TWT session in the STA-associated MAC, the rendering device can negotiate with the AP to configure or adjust a second TWT session. In some implementations, the AP may have its own TWT requirements (e.g., based on supporting other devices in the BSS). The rendering device can configure the second TWT session with the AP to ensure that the AP's requirements are met. The rendering device may also configure the first TWT session before configuring the second TWT session to support the requirements of the AP while also meeting any latency and packet loss requirements associated with the XR experience.

[0255]

[0283] In some implementations, the TWT window of the second TWT session is scheduled to take into account the S2W duration of the WCD for the STA-associated MAC. For example, the TWT window of the second TWT session is scheduled such that the S2W duration does not overlap with XR activity (such as receiving from and transmitting to the display device as described above).

[0256]

[0284] 23 shows a sequence diagram 2300 illustrating example timing of XR activity and wireless activity with an AP (referred to as wireless activity). A first XR activity 2302 (e.g., from receiving a pause data frame over a second wireless link to providing a current video frame) has a start time 2304, and a second XR activity 2306 (e.g., from receiving a next pause data frame over the second wireless link to providing a next video frame) has a start time 2308. In some implementations, the XR activity 2302 corresponds to a first TWT window of a first TWT session, and the XR activity 2306 corresponds to a second TWT window of the first TWT session. The XR activity is periodic (e.g., based on a video display rate or rendering rate), and the period duration 2310 of the periodic activity is the difference between the start times 2308 and 2304. Wireless activity 2312 (associated with communication between the rendering device and the AP over the first wireless link) should be scheduled outside of XR activities 2302 and 2306 (e.g., between the TWT windows corresponding to XR activities 2302 and 2306). Wireless activity 2312 has a start time 2314 and an end time 2316 at which it should be scheduled. Wireless activity 2312 may correspond to the first TWT window of a second TWT session. Start time 2314 may exceed buffer 2318 after XR activity 2302. For example, as described above, one or more PPDUs may be transmitted to the display device after the TWT window, or when the PPDUs are delivered to the display device may vary depending on channel conditions and other latencies. In this manner, the duration of XR activity 2302 may vary. Buffer 2318 may be for a defined amount of time to offset variations in the duration of XR activity (including XR activity 2302). As depicted, the start time 2314 is after the buffer 2318 .

[0257]

[0285] The start time 2314 may also be scheduled to offset the S2W duration at the rendering device to ensure that reception and transmission with the display device (or AP) is not affected by one or more WCD components coming from a low power mode. R and the XR activity duration (e.g., the length of XR activity 2302) is A R where the buffer duration is z, the typical wireless activity start time is y, and the TWT wake-up interval (e.g., the interval of the TWT window during which the WCD should remain in active mode) is P W and the duration of the wireless activity (the difference between the end time 2316 and the start time 2314) is A W Assuming that the wireless activity is periodic, the wireless activity is W ) and any cycle of XR activity (n R ) are scheduled so as not to overlap with XR activities, which is mathematically depicted in equations (1) to (3) below.

[0258]

number

[0259]

[0286] In this way, the start time 2304 is x+n for any cycle of XR activity. R P R and the start time 2308 is x+(n R +1)P R and the end of the XR activity 2302 is x+n R P R +A R and the end of the XR activity 2306 is x+(n R +1)P R +A RThe start time 2314 can be y+n W P W and the end time 2316 is y+n W P W +A W It can be. P W is P R When TWT is used to communicate between a rendering device and a display device, P R is a constant value across all cycles of the XR activity (assuming no adjustments are made to the XR activity based on feedback etc.).

[0260]

[0287] A rendering device may use a TDM window that is not defined within a TWT session. For example, as described above, one or more MLO techniques may include the use of a TDM window. In some implementations, R may vary between different cycles of XR activity (due to delays in transmission or reception due to simultaneous communication, etc.). The rendering device may refer to equations (1)-(3), but with a varying P R Schedule wireless activity during TWT windows similar to those described above for XR activity. For example, a rendering device may schedule wireless activity during TWT windows similar to those described above for XR activity. R In this way, wireless activity 2312 is guaranteed not to overlap with any of the XR activities (including XR activities 2302 and 2306).

[0261]

[0288] Referring back to the use of TWT for simultaneous link support, the device's application layer clock and WCD clock may have different fidelity. For example, the application layer clock may be able to indicate values ​​with greater fidelity (also called granularity) than the WCD clock. The difference in fidelity may also affect P W P shown in a different way R For example, P R is sometimes expressed as time per number of cycles of XR activity (e.g., 50 ms per 3 cycles). However, (P R (equal to)P W may be determined for each cycle of wireless activity. For example, P R is 50ms per 3 cycles (which should be 50 / 3ms per cycle), and P W P R , the rendering device will determine P based on the fidelity of the WCD clock (such as the smallest time unit, 1 μs). W In this example, P W is limited to 16.666 ms or 16.667 ms, which is an approximation of 50 / 3 ms. W As a result of limiting the instruction of P, the cycle duration of the wireless activity 2312 is different from the cycle duration 2310 of the XR activity (such as a maximum of 1 μs per cycle in the example). W is determined to be 16.666ms, and P R In an example where P is 50 / 3 ms, wireless activity shifts 3.88 ms relative to XR activity every 194 seconds. W , which is configured to offset the amount of drift in wireless activity over time due to approximation errors in measuring . If the buffer 2318 is 3.88 ms, wireless activity may begin to overlap with previous XR activity after 194 seconds.

[0262]

[0289] In some implementations, drift between XR activity and wireless activity may occur based on the difference in resonant frequencies associated with the device's application layer clock and WCD clock. As described above, different crystals may be used for the application layer clock and the WCD clock. The crystals may have different resonant frequencies to which the clocks are referenced. In addition, the crystals may be affected differently by environmental conditions (such as temperature or humidity) that change the resonant frequency. Although the devices may be assumed to have the same resonant frequency, wireless activity may drift over time relative to XR activity based on the difference in resonant frequency. In an example where the difference in resonant frequency (associated with the WCD clock with the higher resonant frequency) is 20 cycles per million crystal cycles between the application layer clock and the WCD clock, wireless activity may drift 3.88 ms every 194 seconds. If the buffer 2318 is 3.88 ms, wireless activity may begin to overlap with the previous XR activity after 194 seconds.

[0263]

[0290] One or both of the TWT sessions may be adjusted based on drift. For example, the second TWT session may be periodically adjusted to prevent TWT windows from the second TWT session from overlapping with TWT windows from the first TWT session. In some implementations, the rendering device may measure drift between a first plurality of TWT windows from the first TWT session and a second plurality of TWT windows from the second TWT session. As described above, determining the first TWT session may be based on an application layer clock of the rendering device. The second TWT session may be based on a WCD clock of the rendering device. The rendering device may adjust the timing of one or more of the first plurality of TWT windows or the second plurality of TWT windows. For example, the rendering device may initiate an adjustment of the second TWT session to prevent overlap of the second plurality of TWT windows with the first plurality of TWT windows.

[0264]

[0291] The adjustment of the second TWT session can be at a defined time interval based on the measured drift. For example, if the drift is P W If the approximation is based on P, the rendering device can determine the interval defined to adjust the second TWT session based on the approximation error and the size of the buffer. W is approximated to be 16.666ms, and P R In the example above where the difference in resonant frequency is 50 / 3 ms and the buffer is 3.88 ms, the rendering device may determine the defined interval to be less than 194 seconds. In the example above where the difference in resonant frequency is 20 cycles per million cycles and the buffer is 3.88 ms, the rendering device may determine the defined interval to be less than 194 ms. In some implementations, the defined interval may be based on both types of drift (e.g., based on the feature that causes the largest drift between the two).

[0265]

[0292] In addition to, or as an alternative to, adjusting the second TWT session based on the determined time interval associated with the drift, the rendering device can attempt to determine whether the XR activity and the wireless activity begin to overlap. For example, the rendering device can provide a schedule, or the WCD can otherwise estimate when the XR activity should occur (such as the interval when transmitting or receiving over the second wireless link), and the WCD can periodically determine whether the wireless activity should overlap with the estimated XR activity. The TWT window of the second TWT session with the AP may be advanced or delayed based on the determination to prevent overlap with the TWT window of the first TWT session.

[0266]

[0293] As described above, aspects of the present disclosure include a wireless system for giving preference to communications between two devices over other devices while still sharing a wireless medium with other devices. The preference may be given to communications between a rendering device and a display device of an XR experience that meet latency and packet loss requirements. In some implementations, the preference may be given via asynchronous channel control operations. In some implementations, the preference may be given via synchronous channel control operations. Sharing the wireless medium may be through the use of a TWT session (e.g., for simultaneous link support) or MLO techniques. Aspects of the present disclosure also include generating and providing feedback associated with the XR experience between the rendering device and the display device. Communications between devices (e.g., a rendering device and a display device or a rendering device and an AP) may be adjusted based on the feedback to ensure that latency and packet loss requirements for the XR experience are met. In this manner, an entire system (e.g., a BSS or mesh network) including one or more rendering devices and one or more display devices may be configured to support an XR experience.

[0267]

[0294] The following numbered clauses provide example implementations: 1. A method performed by a wireless communication device for an extended reality (XR) experience, comprising: obtaining control of a wireless medium; Control of the wireless medium is associated with a first priority for transmitting a first physical layer protocol data unit (PPDU) of the application file from the wireless communication device to a second device over the wireless medium; the first priority is different from a second priority for transmitting data from the second device to the wireless communication device over the wireless medium; providing a first PPDU to a second device; providing one or more subsequent PPDUs of the application file to a second device, wherein providing the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium; A method comprising: 2. Associating a first priority with a first set of Enhanced Distributed Channel Access (EDCA) parameters; a second priority associated with a second set of EDCA parameters; a third priority is associated with a third set of EDCA parameters; Clause 1 method. 3. EDCA parameters are: Arbitration Interframe Space Number (AIFSN), The minimum contention window (CWmin), or Maximum Contention Window (CWmax) one or more of the methods set forth in clauses 1-2, including one or more of the following: 4. The first priority is associated with a first back-off counter value, wherein the first back-off counter value is used by a back-off counter of the wireless communication device to contend for the wireless medium for the first PPDU; a second priority associated with a second back-off counter value greater than the first back-off counter value; a third priority is associated with a third back-off counter value greater than the second back-off counter value, wherein the third back-off counter value is used by a back-off counter of the wireless communication device to contend for the wireless medium for one or more subsequent PPDUs; One or more of the methods outlined in clauses 1 and 2. 5. The method of one or more of clauses 1-2 or 4, wherein the first backoff counter value is zero during a first transmit opportunity (TXOP). 6. The wireless communication device and the second device are included in a first basic service set (BSS); the wireless communication device and the second device are within range of a device in another BSS (OBSS); the OBSS device contending for the wireless medium to transmit high importance classified data associated with a fourth priority; the wireless communication device or the second device obtaining control of the wireless medium based on the first priority or the second priority; One or more of the methods outlined in clauses 1 and 2. 7. The wireless communication device contends for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Stopping the second device from competing for the wireless medium; The OBSS device gains control of the wireless medium based on a fourth priority. one or more of the methods set out in clauses 1-2 or 6. 8. Providing a first request to send (RTS) frame to obtain control of the wireless medium, wherein the first RTS frame includes an indication of a network allocation vector (NAV) that maintains control of the wireless medium for a first time period, wherein the first time period is greater than a first transmit opportunity (TXOP) during which the first PPDU is provided; obtaining a first clear to send (CTS) frame from the second device after providing the first RTS frame; providing a second RTS frame after the first TXOP and before an end of the first time period; the second RTS frame includes a NAV indication extending the first time period to cover multiple TXOPs; Providing the first PPDU is after obtaining the first CTS frame and during the first TXOP; One or more of the methods of clauses 1-2 further comprising: 9. The method of one or more of clauses 1-2 or 8, wherein the first TXOP is shortened by the wireless communications device before providing the PPDU associated with the application file to the second device. 10. The method of one or more of clauses 1-2 or 8, further comprising obtaining data from the second device after the first TXOP and before providing the second RTS frame. 11. Providing a final PPDU of the application file to a second device; the last PPDU contains the last Medium Access Control Layer (MAC) Service Data Unit (MSDU) of the application file; The last MSDU contains metadata identifying the last MSDU of the application file; ceasing to provide another RTS frame to extend the first time period after providing the last MSDU to the second device; releasing control of the wireless medium at the end of the first time period; The method of one or more of clauses 1-2 or 8 further comprising: 12. The method of one or more of clauses 1-2, 8, or 11, further comprising providing a contention-free (CF) end beacon after providing the last MSDU to release control of the wireless medium. 13. Further including obtaining control of the wireless medium to provide one or more PPDUs of the second application file to the second device, wherein: the first MSDU of the second application file includes metadata identifying the first MSDU of the second application file; the first MSDU is associated with a first set of EDCA parameters; Gaining control of the wireless medium is associated with a first set of EDCA parameters; one or more of the methods set out in clauses 1-2, 8 or 11. 14. The method of one or more of clauses 1-2, 8, 11, or 13, wherein the wireless communications device enables RTS / CTS signaling for the first PPDU per application file. 15. The wireless communication device is included in a software-enabled access point (SAP); the second device includes a head-mounted display (HMD); The application file is associated with a video frame to be displayed by the HMD; one or more of the methods set out in clauses 1 to 14. 16. A wireless communication device configured for an extended reality (XR) experience, comprising: a processing system; obtaining control of a wireless medium; Control of the wireless medium is associated with a first priority for transmitting a first physical layer protocol data unit (PPDU) of the application file from the wireless communication device to a second device over the wireless medium; the first priority is different from a second priority for transmitting data from the second device to the wireless communication device over the wireless medium; providing a first PPDU to a second device; providing one or more subsequent PPDUs of the application file to a second device, wherein providing the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium; and an interface configured to a wireless communication device comprising: 17. The first priority is associated with a first set of enhanced distributed channel access (EDCA) parameters; a second priority associated with a second set of EDCA parameters; a third priority is associated with a third set of EDCA parameters; Clause 16 Wireless Communication Devices. 18. EDCA parameters are: Arbitration Interframe Space Number (AIFSN), The minimum contention window (CWmin), or Maximum Contention Window (CWmax) A wireless communications device according to one or more of clauses 16-17, including one or more of the following: 19. A first priority is associated with a first backoff counter value, wherein the first backoff counter value is used by a backoff counter of a wireless communication device to contend for the wireless medium for a first PPDU; a second priority associated with a second back-off counter value greater than the first back-off counter value; a third priority is associated with a third back-off counter value greater than the second back-off counter value, wherein the third back-off counter value is used by a back-off counter of the wireless communication device to contend for the wireless medium for one or more subsequent PPDUs; Wireless communications devices in accordance with one or more of clauses 16-17. 20. The wireless communications device of one or more of clauses 16-17 or 19, wherein the first backoff counter value is zero during a first transmit opportunity (TXOP). 21. A wireless communication device and a second device are included in a first basic service set (BSS); the wireless communication device and the second device are within range of a device in another BSS (OBSS); the OBSS device contending for the wireless medium to transmit high importance classified data associated with a fourth priority; the wireless communication device or the second device obtaining control of the wireless medium based on the first priority or the second priority; Wireless communications devices in accordance with one or more of clauses 16-17. 22. The wireless communication device contends for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Stopping the second device from competing for the wireless medium; The OBSS device gains control of the wireless medium based on a fourth priority. Wireless communications devices covered by one or more of clauses 16-17 or 21. 23. The interface is providing a first request to send (RTS) frame to obtain control of the wireless medium, wherein the first RTS frame includes an indication of a network allocation vector (NAV) that maintains control of the wireless medium for a first time period, wherein the first time period is greater than a first transmit opportunity (TXOP) during which the first PPDU is provided; obtaining a first clear to send (CTS) frame from the second device after providing the first RTS frame; providing a second RTS frame after the first TXOP and before an end of the first time period; the second RTS frame includes a NAV indication extending the first time period to cover multiple TXOPs; Providing the first PPDU is after obtaining the first CTS frame and during the first TXOP; The wireless communication device of one or more of clauses 16-17, further configured to: 24. The wireless communications device of one or more of clauses 16-17 or 23, wherein the first TXOP is shortened by the wireless communications device before providing the PPDU associated with the application file to the second device. 25. The wireless communications device of clause 23, wherein the interface is further configured to obtain data from the second device after the first TXOP and before providing the second RTS frame. 26. The interface is providing a final PPDU of the application file to a second device; the last PPDU contains the last Medium Access Control Layer (MAC) Service Data Unit (MSDU) of the application file; The last MSDU contains metadata identifying the last MSDU of the application file; ceasing to provide another RTS frame to extend the first time period after providing the last MSDU to the second device; releasing control of the wireless medium at the end of the first time period; The wireless communications device of one or more of clauses 16-17 or 23, further configured to: 27. The wireless communications device of one or more of clauses 16-17, 23, or 26, wherein the interface is further configured to provide a contention-free (CF) end beacon after providing a last MSDU to release control of the wireless medium. 28. The interface is further configured to obtain control of the wireless medium to provide one or more PPDUs of the second application file to the second device, wherein: the first MSDU of the second application file includes metadata identifying the first MSDU of the second application file; the first MSDU is associated with a first set of EDCA parameters; Gaining control of the wireless medium is associated with a first set of EDCA parameters; Wireless communications devices as set forth in one or more of clauses 16-17, 23, or 26. 29. The wireless communications device of one or more of clauses 16-17, 23, 26, or 28, wherein the wireless communications device enables RTS / CTS signaling for the first PPDU per application file. 30. The wireless communication device is included in a software-enabled access point (SAP); the second device includes a head-mounted display (HMD); The application file is associated with a video frame to be displayed by the HMD; A wireless communications device in accordance with one or more of clauses 16 to 29. 31. A method performed by a wireless communication device, comprising: obtaining a first physical layer protocol data unit (PPDU) of the application file from a second device via a wireless medium; a second device gains control of the wireless medium; The control of the wireless medium is associated with a first priority for transmitting a first PPDU over the wireless medium; the first priority is different from a second priority for transmitting data from the wireless communication device to the second device over the wireless medium; obtaining one or more subsequent PPDUs of the application file from the AP, wherein obtaining the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium; A method comprising: 32. A first priority is associated with a first set of enhanced distributed channel access (EDCA) parameters; a second priority associated with a second set of EDCA parameters; a third priority is associated with a third set of EDCA parameters; Clause 31 Method. 33. EDCA parameters are: Arbitration Interframe Space Number (AIFSN), The minimum contention window (CWmin), or Maximum Contention Window (CWmax) one or more of the methods set forth in clauses 31-32, including one or more of the following: 34. A first priority is associated with a first backoff counter value; a second priority associated with a second back-off counter value greater than the first back-off counter value, wherein the second back-off counter value is used by a back-off counter of the wireless communication device in determining when to provide data to the AP; a third priority is associated with a third back-off counter value that is greater than the second back-off counter value; One or more of the methods set out in clauses 31-32. 35. The method of one or more of clauses 31-32 or 34, wherein the first backoff counter value is zero during a first transmit opportunity (TXOP). 36. A wireless communication device and a second device are included in a first basic service set (BSS); the wireless communication device and the second device are within range of a device in another BSS (OBSS); the OBSS device contending for the wireless medium to transmit high importance classified data associated with a fourth priority; the wireless communication device or the second device obtaining control of the wireless medium based on the first priority or the second priority; One or more of the methods set out in clauses 31-32. 37. A second device contends for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Stopping wireless communication devices from competing for the wireless medium; The OBSS device gains control of the wireless medium based on a fourth priority. one or more of the methods set out in clauses 31-32 or 36. 38. Obtaining a first request to send (RTS) frame from an AP, wherein the first RTS frame includes an indication of a network allocation vector (NAV) that maintains control of the wireless medium for a first time period, wherein the first time period is greater than a first transmit opportunity (TXOP) during which a first PPDU is obtained from the AP; providing a first clear to send (CTS) frame to the second device after obtaining the first RTS frame; obtaining a second RTS frame from the AP after the first TXOP and before an end of the first time period; the second RTS frame includes a NAV indication extending the first time period to cover multiple TXOPs; Obtaining the first PPDU is after providing the first CTS frame and during the first TXOP; One or more of the methods of clauses 31-32 further comprising: 39. The method of one or more of clauses 31-32 or 38, wherein the first TXOP is shortened by the second device before the second device provides the PPDU associated with the application file to the wireless communication device. 40. Providing data to the second device after the first TXOP and before getting the second RTS frame The method of one or more of clauses 31-32 or 38 further comprising: 41. Obtaining the last PPDU of the application file from the AP, wherein: the last PPDU contains the last Medium Access Control Layer (MAC) Service Data Unit (MSDU) of the application file; the last MSDU includes metadata identifying the last MSDU of the application file; the second device ceasing to provide another RTS frame to extend the first time period after providing the last MSDU to the wireless communication device; the second device releasing control of the wireless medium at the end of the first time period; The method of one or more of clauses 31-32 or 38 further comprising: 42. The method of one or more of clauses 31-32, 38, or 41, further including obtaining a contention-free (CF) end beacon from the second device after obtaining the last MSDU, wherein the CF end beacon is used to release control of the wireless medium. 43. A second device obtains control of the wireless medium to provide one or more PPDUs of a second application file to the wireless communication device; the first MSDU of the second application file includes metadata identifying the first MSDU of the second application file; the first MSDU is associated with a first set of EDCA parameters; Gaining control of the wireless medium by the second device is associated with a first set of EDCA parameters; one or more of the methods set out in clauses 31-32, 38 or 41. 44. The second device includes a software-enabled AP (SAP); The wireless communication device is included in a head-mounted display (HMD), The application file is associated with a video frame to be displayed by the HMD; One or more of the methods set out in clauses 31 to 43. 45. A wireless communication device configured for an extended reality (XR) experience, comprising: a processing system; obtaining a first physical layer protocol data unit (PPDU) of the application file from a second device via a wireless medium; a second device gains control of the wireless medium; The control of the wireless medium is associated with a first priority for transmitting a first PPDU over the wireless medium; the first priority is different from a second priority for transmitting data from the wireless communication device to the second device over the wireless medium; obtaining one or more subsequent PPDUs of the application file from the AP, wherein obtaining the one or more subsequent PPDUs is associated with a third priority for transmitting the one or more subsequent PPDUs over the wireless medium; and an interface configured to a wireless communication device comprising: 46. ​​A first priority is associated with a first set of enhanced distributed channel access (EDCA) parameters; a second priority associated with a second set of EDCA parameters; a third priority is associated with a third set of EDCA parameters; Article 45 Wireless Communication Devices. 47. EDCA parameters are: Arbitration Interframe Space Number (AIFSN), The minimum contention window (CWmin), or Maximum Contention Window (CWmax) A wireless communications device according to one or more of clauses 45-46, including one or more of the following: 48. A first priority is associated with a first backoff counter value; a second priority associated with a second back-off counter value greater than the first back-off counter value, wherein the second back-off counter value is used by a back-off counter of the wireless communication device in determining when to provide data to the AP; a third priority is associated with a third back-off counter value that is greater than the second back-off counter value; Any wireless communications device covered by one or more of clauses 45-46. 49. The wireless communications device of one or more of clauses 45-46 or 48, wherein the first backoff counter value is zero during a first transmit opportunity (TXOP). 50. A wireless communication device and a second device are included in a first basic service set (BSS); the wireless communication device and the second device are within range of a device in another BSS (OBSS); the OBSS device contending for the wireless medium to transmit high importance classified data associated with a fourth priority; the wireless communication device or the second device obtaining control of the wireless medium based on the first priority or the second priority; Any wireless communications device covered by one or more of clauses 45-46. 51. A second device contends for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Stopping wireless communication devices from competing for the wireless medium; The OBSS device gains control of the wireless medium based on a fourth priority. Wireless communications devices covered by one or more of clauses 45-46 or 50. 52. The interface is obtaining a first request to send (RTS) frame from the AP, wherein the first RTS frame includes an indication of a network allocation vector (NAV) that maintains control of the wireless medium for a first time period, wherein the first time period is greater than a first transmit opportunity (TXOP) during which a first PPDU is obtained from the AP; providing a first clear to send (CTS) frame to the second device after obtaining the first RTS frame; obtaining a second RTS frame from the AP after the first TXOP and before an end of the first time period; the second RTS frame includes a NAV indication extending the first time period to cover multiple TXOPs; Obtaining the first PPDU is after providing the first CTS frame and during the first TXOP; The wireless communication device of one or more of clauses 45-46, further configured to: 53. The wireless communications device of one or more of clauses 45-46 or 52, wherein the first TXOP is shortened by the second device before the second device provides the wireless communications device with a PPDU associated with the application file. 54. The wireless communications device of one or more of clauses 45-46 or 52, wherein the interface is further configured to provide data to the second device after the first TXOP and before obtaining the second RTS frame. 55. The interface is obtaining the last PPDU of the application file from the AP, the last PPDU contains the last Medium Access Control Layer (MAC) Service Data Unit (MSDU) of the application file; the last MSDU includes metadata identifying the last MSDU of the application file; the second device ceasing to provide another RTS frame to extend the first time period after providing the last MSDU to the wireless communication device; the second device releasing control of the wireless medium at the end of the first time period; 53. The wireless communications device of one or more of clauses 45-46 or 52, further configured to: 56. The wireless communications device of one or more of clauses 45-46, 52, or 55, wherein the interface is further configured to obtain a contention-free (CF) end beacon from the second device after obtaining the last MSDU, and wherein the CF end beacon is used to release control of the wireless medium. 57. A second device obtains control of the wireless medium to provide one or more PPDUs of a second application file to the wireless communication device; the first MSDU of the second application file includes metadata identifying the first MSDU of the second application file; the first MSDU is associated with a first set of EDCA parameters; Gaining control of the wireless medium by the second device is associated with a first set of EDCA parameters; Wireless communications devices under one or more of clauses 45-46, 52, or 55. 58. The second device includes a software-enabled AP (SAP); The wireless communication device is included in a head-mounted display (HMD), The application file is associated with a video frame to be displayed by the HMD; Wireless communications devices covered by one or more of clauses 45 to 57. 59. A method performed by a device for an extended reality (XR) experience, comprising: obtaining uplink (UL) data over a wireless medium from a second device; providing downlink (DL) data including physical layer protocol data units (PPDUs) over a wireless medium to a second device, wherein: one or more PPDUs are provided to the second device during a current target wake-up time (TWT) window; The start of the current TWT window is When a first PPDU of the one or more PPDUs is provided to a second device; or When the first PPDU is provided from the application layer of the device to the medium access control layer (MAC) associated with one of the A method comprising: 60. Rendering a video frame to be displayed by the second device; the device includes a rendering device, the second device includes a display device; UL data contains pause data frames, Rendering of video frames is associated with the acquired pose data frames, wherein: a first one of the video frames includes a plurality of slices; the rendering of the first video frame is associated with the first pose data frame most recently obtained from the second device; One or more PPDUs are associated with one or more of the slices; Article 59 Method. 61. Providing a packet to a second device, the packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after a current TWT window; providing a PPDU associated with a video slice of the first video frame to a second device after a current TWT window and before a next TWT window; One or more of the methods set forth in clauses 59-60, further including: 62. The method of one or more of clauses 59-60, wherein the start of the current TWT window is further related to a motion-to-render (M2R) latency for the first video frame. 63. Further comprising synchronizing an application layer clock of the device with a wireless communication device (WCD) clock, wherein: The application layer clock is used by the device to time the rendering of video frames; the WCD clock is used by the device for timing of wireless communications with a second device; one or more of the methods set out in clauses 59-60 or 62. 64. A pose data frame is acquired at a first frequency, Rendering video frames at a first frequency, wherein each captured pose data frame is associated with a rendered video frame; one or more of clauses 59-60, 62, or 63. 65. The method of one or more of clauses 59-60, 62, or 63, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the WCD clock with the application layer clock. 66. Synchronizing a WCD clock to an application layer clock aligning a start of the current TWT window to a first time before a rendering time to start rendering a first video frame, wherein the first time precedes the rendering time by a first offset, the first offset being associated with M2R latency; one or more of clauses 59-60, 62, 63, or 65, including: 67. The method of one or more of clauses 59-60, 62, 63, 65, or 66, further comprising obtaining a first pause data frame during a start of a current TWT window. 68. Acquiring additional pause data frames during the current TWT window; rendering at least a portion of a second video frame during a next TWT window; and the second video frame is associated with a further frame of pose data; the further pose data frame is the pose data frame most recently acquired prior to rendering the second video frame; Any one or more of clauses 59-60, 62, 63, or 65-67, further including: 69. The method of one or more of clauses 59-60, 62, or 63, wherein synchronizing the application layer clock of the device with the WCD clock includes synchronizing the application layer clock to the WCD clock, and wherein synchronizing the application layer clock to the WCD clock is associated with a timing synchronization function (TSF) in the MAC of the device. 70. Synchronizing an application layer clock to a WCD clock Aligning a rendering time to start rendering a first video frame to a first time after a start of a current TWT window, where the first time follows the start of the current TWT window by a first offset, the first offset being associated with M2R latency; one or more of clauses 59-60, 62, 63, or 69, including: 71. The method of one or more of clauses 59-60, 62, or 63, further including periodically synchronizing the device's application layer clock and the WCD clock, wherein synchronizing the application layer clock and the WCD clock is associated with a drift between the application layer clock and the WCD clock that is greater than a drift threshold since the last synchronization between the application layer clock and the WCD clock. 72. The device includes a software-enabled AP (SAP); the second device includes a head-mounted display (HMD) that displays the video frames; one or more of the methods set out in Articles 59 to 71. 73. A device configured for an extended reality (XR) experience, comprising: a processing system; obtaining uplink (UL) data over a wireless medium from a second device; providing downlink (DL) data including physical layer protocol data units (PPDUs) over a wireless medium to a second device, wherein: one or more PPDUs are provided to the second device during a current target wake-up time (TWT) window; The start of the current TWT window is When a first PPDU of the one or more PPDUs is provided to a second device; or When the first PPDU is provided from the application layer of the device to the medium access control layer (MAC) associated with one of the an interface configured to: Including, the device. 74. A processing system is configured to render video frames to be displayed by a second device, wherein: the device includes a rendering device, the second device includes a display device; UL data contains pause data frames, Rendering of video frames is associated with the acquired pose data frames, wherein: a first one of the video frames includes a plurality of slices; the rendering of the first video frame is associated with the first pose data frame most recently obtained from the second device; One or more PPDUs are associated with one or more of the slices; Clause 73 Devices. 75. The interface is providing a packet to a second device, the packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after a current TWT window; providing a PPDU associated with a video slice of the first video frame to a second device after a current TWT window and before a next TWT window; The device of one or more of clauses 73-74, further configured to: 76. The device of one or more of clauses 73-74, wherein the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame. 77. A device is configured to synchronize an application layer clock of the device with a wireless communication device (WCD) clock, wherein: The application layer clock is used by the device to time the rendering of video frames; the WCD clock is used by the device for timing of wireless communications with a second device; One or more devices of clauses 73-74 or 76. 78. A pose data frame is acquired at a first frequency, Rendering video frames at a first frequency, wherein each captured pose data frame is associated with a rendered video frame; One or more devices of clauses 73-74, 76 or 77. 79. The device of one or more of clauses 73-74, 76, or 77, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the WCD clock with the application layer clock. 80. Synchronizing a WCD clock to an application layer clock aligning a start of the current TWT window to a first time before a rendering time to start rendering a first video frame, wherein the first time precedes the rendering time by a first offset, the first offset being associated with M2R latency; Any device that is one or more of clauses 73-74, 76, 77, or 79, including: 81. The device of one or more of clauses 73-74, 76, 77, 79, or 80, wherein the interface is further configured to obtain a first pause data frame during a start of a current TWT window. 82. The interface is further configured to acquire additional pause data frames during the current TWT window; The processing system is further configured to render at least a portion of a second video frame during a next TWT window, wherein: the second video frame is associated with a further frame of pose data; the further pose data frame is the pose data frame most recently acquired prior to rendering the second video frame; One or more devices of clauses 73-74, 76, 77, or 79-81. 83. The device of one or more of clauses 73-74, 76, or 77, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the application layer clock to the WCD clock, and wherein synchronizing the application layer clock to the WCD clock is associated with a timing synchronization function (TSF) in the device's MAC. 84. Synchronizing an application layer clock to a WCD clock Aligning a rendering time to start rendering a first video frame to a first time after a start of a current TWT window, where the first time follows the start of the current TWT window by a first offset, the first offset being associated with M2R latency; Any device that is one or more of clauses 73-74, 76, 77, or 83, including: 85. The device of one or more of clauses 73-74, 76, or 77, wherein the device is configured to periodically synchronize the device's application layer clock with the WCD clock, and wherein synchronizing the application layer clock with the WCD clock is associated with a drift between the application layer clock and the WCD clock that is greater than a drift threshold since the last synchronization between the application layer clock and the WCD clock. 86. The device includes a software-enabled AP (SAP); the second device includes a head-mounted display (HMD) that displays the video frames; One or more devices of clauses 73 to 85. 87. A method performed by a device for an extended reality (XR) experience, comprising: providing uplink (UL) data to a second device over a wireless medium; obtaining downlink (DL) data including physical layer protocol data units (PPDUs) over a wireless medium from a second device, wherein: one or more PPDUs are acquired from the second device during a current target wake-up time (TWT) window; The start of the current TWT window is When a first of the one or more PPDUs is provided by a second device, or When the first PPDU is provided from the application layer of the second device to the medium access control layer (MAC). associated with one of the A method comprising: 88. A second device should render video frames to be displayed by the device, wherein: the second device includes a rendering device; the device includes a display device; UL data contains pause data frames, Rendering of a video frame is associated with the provided pose data frame, wherein: a first one of the video frames includes a plurality of slices; the rendering of the first video frame is associated with the first pose data frame most recently acquired by the second device; One or more PPDUs are associated with one or more of the slices; Article 87 Method. 89. Obtaining, from a second device, a packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after a current TWT window; obtaining, from a second device, a PPDU associated with a video slice of the first video frame after a current TWT window and before a next TWT window; One or more of the methods set forth in clauses 87-88 further include: 90. The method of one or more of clauses 87-88, wherein the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame. 91. Further comprising synchronizing the device's application layer clock with the WCD clock, wherein: the application layer clock is used by the device to time the display of video frames; the WCD clock is used by the device for timing of wireless communications with a second device; one or more of the methods set out in Articles 87-88 or 90. 92. A pose data frame is provided at a first frequency; video frames are rendered by a second device at a first frequency, wherein each pose data frame acquired by the second device is associated with a rendered video frame; one or more of the methods set forth in clauses 87-88, 90, or 91. 93. The method of one or more of clauses 87-88, 90, or 91, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the WCD clock with the application layer clock. 94. Synchronizing a WCD clock to an application layer clock aligning a start of a current TWT window to a first time at which a first pause data frame is provided to a second device, wherein: the first time precedes a rendering time at which the second device should begin rendering the first video frame; the first time precedes the render time by a first offset; The first offset is associated with the M2R latency; one or more of clauses 87-88, 90, 91, or 93, including: 95. acquiring the first pause data frame during the start of the current TWT window; or Timeout from the start of the current TWT window that occurs before a pause data frame is obtained. the second device begins rendering the first video frame when one of the following occurs: 96. Further including indicating to the second device the time of the start of the current TWT window, wherein: the indication of time is associated with a timing synchronization function (TSF) in the device's MAC after the WCD clock is synchronized to the application layer clock; a WCD clock of the second device is synchronized to the WCD clock of the device, wherein the WCD clock synchronization is associated with a TSF of the device and a TSF in the MAC of the second device; an application layer clock of the second device is synchronized to the WCD clock of the AP, wherein the synchronization of the application layer clock of the second device to the WCD clock of the second device is associated with the TSF of the second device; one or more of clauses 87-88, 90, 91, or 93. 97. The method of one or more of clauses 87-88, 90, or 91, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the application layer clock with the WCD clock, and wherein synchronizing the application layer clock with the WCD clock is associated with a timing synchronization function (TSF) in the device's MAC. 98. Synchronizing an application layer clock to a WCD clock Aligning the display time with the time associated with the current TWT window Any one or more of the methods set forth in clauses 87-88, 90, 91, or 97, including: 99. The method of one or more of clauses 87-88, 90, or 91, further including periodically synchronizing the device's application layer clock and the WCD clock, wherein synchronizing the application layer clock and the WCD clock is associated with a drift between the application layer clock and the WCD clock that is greater than a drift threshold since the last synchronization between the application layer clock and the WCD clock. 100. A second device includes a software-enabled AP (SAP); the device includes a head-mounted display (HMD) that displays the video frames; One or more of the methods set out in Articles 87 to 99. 101. A device configured for an extended reality (XR) experience, comprising: a processing system; providing uplink (UL) data to a second device over a wireless medium; obtaining downlink (DL) data including physical layer protocol data units (PPDUs) over a wireless medium from a second device, wherein: one or more PPDUs are acquired from the second device during a current target wake-up time (TWT) window; The start of the current TWT window is When a first of the one or more PPDUs is provided by a second device, or When the first PPDU is provided from the application layer of the second device to the medium access control layer (MAC). associated with one of the and an interface configured to Including, the device. 102. A second device should render video frames to be displayed by the device, wherein: the second device includes a rendering device; the device includes a display device; UL data contains pause data frames, Rendering of a video frame is associated with the provided pose data frame, wherein: a first one of the video frames includes a plurality of slices; the rendering of the first video frame is associated with the first pose data frame most recently acquired by the second device; One or more PPDUs are associated with one or more of the slices; Article 101 Devices. 103. The interface is obtaining, from a second device, a packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after a current TWT window; obtaining, from a second device, a PPDU associated with a video slice of the first video frame after a current TWT window and before a next TWT window; The device of one or more of clauses 101-102, further configured to: 104. The device of one or more of clauses 101-102, wherein the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame. 105. A device is configured to synchronize an application layer clock of the device with a WCD clock, wherein: the application layer clock is used by the device to time the display of video frames; the WCD clock is used by the device for timing of wireless communications with a second device; One or more devices of clauses 101-102 or 104. 106. A pose data frame is provided at a first frequency; video frames are rendered by a second device at a first frequency, wherein each pose data frame acquired by the second device is associated with a rendered video frame; One or more devices of clauses 101-102, 104, or 105. 107. The device of one or more of clauses 101-102, 104, or 105, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the WCD clock with the application layer clock. 108. Synchronizing a WCD clock to an application layer clock aligning a start of a current TWT window to a first time at which a first pause data frame is provided to a second device, wherein: the first time precedes a rendering time at which the second device should begin rendering the first video frame; the first time precedes the render time by a first offset; The first offset is associated with the M2R latency; Any device that is one or more of clauses 101-102, 104, 105, or 107, including: 109. Obtaining the first pause data frame during the start of the current TWT window; or Timeout from the start of the current TWT window that occurs before a pause data frame is obtained. When one of the conditions occurs, the second device begins rendering the first video frame, and one or more of the conditions of clauses 101-102, 104, 105, or 107 occur. 110. The interface is further configured to indicate to the second device a time of a start of a current TWT window, wherein: the indication of time is associated with a timing synchronization function (TSF) in the device's MAC after the WCD clock is synchronized to the application layer clock; a WCD clock of the second device is synchronized to the WCD clock of the device, wherein the WCD clock synchronization is associated with a TSF of the device and a TSF in the MAC of the second device; an application layer clock of the second device is synchronized to a WCD clock of the second device, wherein the synchronization of the application layer clock of the second device to the WCD clock of the second device is associated with a TSF of the second device; One or more devices of clauses 101-102, 104, 105, or 107. 111. The device of one or more of clauses 101-102, 104, or 105, wherein synchronizing the device's application layer clock with the WCD clock includes synchronizing the application layer clock to the WCD clock, wherein synchronizing the application layer clock to the WCD clock is associated with a timing synchronization function (TSF) in the device's MAC. 112. Synchronizing an application layer clock to a WCD clock Aligning the display time with the time associated with the current TWT window Any device that is one or more of clauses 101-102, 104, 105, or 111, including: 113. One or more of clauses 101-102, 104, or 105, wherein the device is configured to periodically synchronize the device's application layer clock with the WCD clock, and wherein synchronizing the application layer clock with the WCD clock is associated with a drift between the application layer clock and the WCD clock that is greater than a drift threshold since the last synchronization between the application layer clock and the WCD clock. 114. The second device includes a software-enabled AP (SAP); the device includes a head-mounted display (HMD) that displays the video frames; One or more devices of clauses 101 to 113. 115. A method implemented by a device, comprising: Rendering a plurality of video frames to be provided to a second device; Dividing each video frame of the plurality of video frames into a plurality of video slices; For each video slice of multiple video slices, generating a plurality of PPDUs to include the video slices; each PPDU including one or more Medium Access Control Layer (MAC) Service Data Units (MSDUs) associated with a video slice; The video slices are identified by a port number and a differentiated services field code point (DSCP) value included in each MSDU of the multiple PPDUs; queuing the MSDU for transmission to a second device; A method comprising: 116. The method of clause 115, wherein queuing the MSDUs includes creating an MSDU queue in software for each video slice, wherein each MSDU queue is identified by an Internet Protocol (IP) address, a port number, and a DSCP value. 117. The method of one or more of clauses 115-116, wherein each video slice is associated with a traffic identifier (TID) associated with the access category (AC) of the video slice. 118. The method of one or more of clauses 115-117, wherein the AC of a video slice is associated with the priority of the video slice. 119. The method of one or more of clauses 115-118, wherein the priority of a video slice depends on whether the video slice is an i-slice or a p-slice. 120. Rendering a first p slice; generating a first MSDU queue associated with a first p slice; rendering a first p slice followed by a second p slice; flushing the first MSDU queue after rendering the second p-slice and before providing a PPDU including one or more MSDUs associated with the first p-slice to a second device; Any one or more of the methods set forth in clauses 115-119, further including: 121. Rendering the first i-slice; generating a first MSDU queue associated with a first i-slice; rendering a first i-slice followed by a second i-slice or p-slice; generating a second MSDU queue associated with a second i-slice; providing a PPDU including one or more MSDUs associated with the first i-slice to a second device after generating a second MSDU queue; Any one or more of the methods set forth in clauses 115-119, further including: 122. For a PPDU associated with a video slice: The PPDU is attempted to be transmitted to the second device up to a threshold number of times; flushing an MSDU queue associated with the video slice after the device has unsuccessfully attempted to transmit a PPDU to the second device a threshold number of times; One or more of the methods set out in Articles 115 to 119. 123. Generating a replacement video slice after flushing an MSDU queue; generating a replacement MSDU queue associated with the replacement video slice; The method of one or more of clauses 115-119 or 122 further comprising: 124. The method of one or more of clauses 115-119 or 122, further comprising indicating to the second device that the MSDU queue has been flushed. 125. The method of clause 115, further including using forward error correction (FEC) to transmit the one or more PPDUs to the second device. 126. Using FEC to transmit one or more PPDUs to a second device includes: the link quality between the device and a second device; one or more parameters of the second device; or One or more parameters of multiple video frames any one or more of the methods of clauses 115 or 125 associated with any one or more of the methods of clauses 115 or 125. 127. A device includes a software-enabled access point (SAP); the second device includes a head-mounted display (HMD); one or more of the methods set out in Articles 115 to 126. 128. A device configured for an extended reality (XR) experience, comprising: The interface and Rendering a plurality of video frames to be provided to a second device; Dividing each video frame of the plurality of video frames into a plurality of video slices; For each video slice of multiple video slices, generating a plurality of PPDUs to include the video slices; each PPDU including one or more Medium Access Control Layer (MAC) Service Data Units (MSDUs) associated with a video slice; The video slices are identified by the port number and Differentiated Services Field Code Point (DSCP) value included in each MSDU of the PPDU; queuing the MSDU for transmission to a second device; a processing system configured to: Including, the device. 129. The device of clause 128, wherein queuing the MSDUs includes creating an MSDU queue in software for each video slice, wherein each MSDU queue is identified by an Internet Protocol (IP) address, a port number, and a DSCP value. 130. The device of one or more of clauses 128-129, wherein each video slice is associated with a traffic identifier (TID) associated with the access category (AC) of the video slice. 131. A device according to one or more of clauses 128-130, wherein the AC of a video slice is associated with the priority of the video slice. 132. The device of one or more of clauses 128-131, wherein the priority of a video slice depends on whether the video slice is an i-slice or a p-slice. 133. If the processing system: Rendering a first p slice; generating a first MSDU queue associated with a first p slice; rendering a first p slice followed by a second p slice; flushing the first MSDU queue after rendering the second p-slice and before providing a PPDU including o...

Claims

1. 1. A method performed by a device for an extended reality (XR) experience, comprising: Obtaining uplink (UL) data over a wireless medium from a second device; providing downlink (DL) data including a physical layer protocol data unit (PPDU) to the second device over the wireless medium, wherein: one or more PPDUs are provided to the second device during a current target wake-up time (TWT) window; The start of the current TWT window is when a first PPDU of the one or more PPDUs is provided to the second device; or when the first PPDU is provided from an application layer of the device to a medium access control layer (MAC); associated with one of Rendering a video frame to be displayed by the second device; Equipped with the UL data includes a pause data frame; The rendering of the video frame is associated with the acquired pose data frame, wherein: a first one of the video frames includes a plurality of video slices; the rendering of the first video frame is associated with a first pose data frame most recently obtained from the second device; one or more PPDUs associated with one or more of the plurality of video slices; method.

2. The device includes a rendering device, the second device includes a display device; The method of claim 1.

3. providing a packet to the second device, the packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after the current TWT window; providing a PPDU associated with a video slice of the first video frame to the second device after the current TWT window and before a next TWT window; The method of claim 2 further comprising:

4. the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame; Preferably, the method further comprises synchronizing an application layer clock of the device with a wireless communication device (WCD) clock, wherein: the application layer clock is used by the device to time the rendering of the video frames; the WCD clock is used by the device for timing wireless communications with the second device; Most preferably, or synchronizing the application layer clock of the device with the WCD clock includes synchronizing the WCD clock with the application layer clock; Synchronizing the application layer clock of the device with the WCD clock includes synchronizing the application layer clock with the WCD clock, and synchronizing the application layer clock with the WCD clock is associated with a timing synchronization function (TSF) in the MAC of the device. The method of claim 2.

5. 1. A device configured for an extended reality (XR) experience, comprising: a processing system; an interface, the interface comprising: Obtaining uplink (UL) data over a wireless medium from a second device; providing downlink (DL) data including a physical layer protocol data unit (PPDU) over the wireless medium to the second device, wherein: one or more PPDUs are provided to the second device during a current target wake-up time (TWT) window; The start of the current TWT window is when a first PPDU of the one or more PPDUs is provided to the second device; or when the first PPDU is provided from an application layer of the device to a medium access control layer (MAC); associated with one of configured to: the processing system is configured to render video frames to be displayed by the second device; the UL data includes a pause data frame; the rendering of the video frame is associated with the acquired pose data frame; a first one of the video frames includes a plurality of video slices; the rendering of the first video frame is associated with a first pose data frame most recently obtained from the second device; one or more PPDUs associated with one or more of the plurality of video slices; device.

6. The device includes a rendering device, the second device includes a display device; The device of claim 5.

7. The interface is providing a packet to the second device, the packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after the current TWT window; providing a PPDU associated with a video slice of the first video frame to the second device after the current TWT window and before a next TWT window; or the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame; Preferably, The device is configured to synchronize an application layer clock of the device with a wireless communication device (WCD) clock, wherein: the application layer clock is used by the device to time the rendering of the video frames; the WCD clock is used by the device for timing wireless communications with the second device; Most preferably, synchronizing the application layer clock of the device with the WCD clock comprises synchronizing the WCD clock to the application layer clock; or Synchronizing the application layer clock of the device with the WCD clock includes synchronizing the application layer clock with the WCD clock, and synchronizing the application layer clock with the WCD clock is associated with a timing synchronization function (TSF) in the MAC of the device. The device of claim 6.

8. the device includes a software-enabled AP (SAP); the second device includes a head-mounted display (HMD) that displays the video frames; The device of claim 6.

9. 1. A method performed by a device for an extended reality (XR) experience, comprising: providing uplink (UL) data to a second device over a wireless medium; obtaining downlink (DL) data from the second device over the wireless medium, the DL data including a physical layer protocol data unit (PPDU); one or more PPDUs are obtained from the second device during a current target wake-up time (TWT) window; The start of the current TWT window is when a first PPDU of the one or more PPDUs is provided by the second device; or when the first PPDU is provided from an application layer of the second device to a medium access control layer (MAC); associated with one of obtaining, from the second device, rendered video frames to be displayed by the device; and the UL data includes a pause data frame; the rendering of the video frame is associated with the provided pose data frame; a first one of the video frames includes a plurality of video slices; the rendering of the first video frame is associated with a first pose data frame most recently acquired by the second device; one or more PPDUs associated with one or more of the plurality of video slices; A method comprising:

10. The second device includes a rendering device; the device comprises a display device; 10. The method of claim 9.

11. obtaining, from the second device, a packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after the current TWT window; obtaining, from the second device, a PPDU associated with a video slice of the first video frame after the current TWT window and before a next TWT window; or the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame; Preferably, the method further comprises synchronizing an application layer clock of the device with a WCD clock, wherein: the application layer clock is used by the device for timing the display of the video frames; the WCD clock is used by the device for timing wireless communications with the second device; Most preferably, synchronizing the application layer clock of the device with the WCD clock comprises synchronizing the WCD clock to the application layer clock; or synchronizing the application layer clock of the device with the WCD clock includes synchronizing the application layer clock with the WCD clock; Synchronizing the application layer clock to the WCD clock is associated with a timing synchronization function (TSF) in the MAC of the device. The method of claim 10.

12. 1. A device configured for an extended reality (XR) experience, comprising: a processing system; an interface, the interface comprising: providing uplink (UL) data to a second device over a wireless medium; obtaining downlink (DL) data from the second device over the wireless medium, the DL data including a physical layer protocol data unit (PPDU); one or more PPDUs are obtained from the second device during a current target wake-up time (TWT) window; The start of the current TWT window is when a first PPDU of the one or more PPDUs is provided by the second device; or when the first PPDU is provided from an application layer of the second device to a medium access control layer (MAC); associated with one of obtaining, from the second device, rendered video frames to be displayed by the device; and the UL data includes a pause data frame; the rendering of the video frame is associated with the provided pose data frame; a first one of the video frames includes a plurality of video slices; the rendering of the first video frame is associated with a first pose data frame most recently acquired by the second device; one or more PPDUs associated with one or more of the plurality of video slices; A device configured to:

13. The device includes a display device, the UL data includes a pause data frame; The device of claim 12.

14. The interface is obtaining, from the second device, a packet including a MAC header including a power management (PM) field indicating that the second device should not enter a low power mode after the current TWT window; obtaining, from the second device, a PPDU associated with a video slice of the first video frame after the current TWT window and before a next TWT window; or the start of the current TWT window is further associated with a motion-to-render (M2R) latency for the first video frame; Preferably, the device is configured to synchronize an application layer clock of the device with a WCD clock, wherein: the application layer clock is used by the device for timing the display of the video frames; the WCD clock is used by the device for timing wireless communications with the second device; Most preferably, synchronizing the application layer clock of the device with the WCD clock comprises synchronizing the WCD clock to the application layer clock; or Synchronizing the application layer clock of the device with the WCD clock includes synchronizing the application layer clock with the WCD clock, and synchronizing the application layer clock with the WCD clock is associated with a timing synchronization function (TSF) in the MAC of the device. The device of claim 13.

15. the second device includes a software-enabled AP (SAP); the device includes a head-mounted display (HMD) that displays the video frames; The device of claim 13.

Images