Asynchronous channel access control for wireless systems

Abstract

The present disclosure provides a system, method, and apparatus for asynchronous channel access control of a wireless system. In some aspects, a device may adjust the priority of one or more PPDUs and perform other operations to secure control of the wireless medium at a particular time while still allowing other devices to communicate on the wireless medium. For example, a device may adjust a back-off counter or one or more EDCA parameters to ensure that it acquires control of the wireless medium to transmit a 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 one or more EDCA parameters to allow other devices to acquire control of the wireless medium in some scenarios (such as for a second device to return information to the device or otherwise transmit using the shared wireless medium).

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS 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.

[0002] The present disclosure relates generally to wireless communications, and more particularly to asynchronous channel access control in 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 compliant with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards is the basic service set (BSS) managed by the AP. Each BSS is identified by a basic service set identifier (BSSID), which is advertised by the AP. The AP periodically broadcasts beacon frames to allow any STA within wireless range of the AP to establish or maintain a communication link with the WLAN. Summary of the Invention [Problem to be solved by the invention]

[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 the respective latency and packet loss requirements. [Means for solving the problem]

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

[0006] One innovative 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 of 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 of 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 of transmitting the one or more subsequent PPDUs over the wireless medium.

[0007] Another innovative 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 of 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 of 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 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 of transmitting the one or more subsequent PPDUs over the wireless medium.

[0008] Another innovative 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 of transmitting the first PPDU over the wireless medium, the first priority being different from a second priority of 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. Obtaining the one or more subsequent PPDUs is associated with a third priority of transmitting the one or more subsequent PPDUs over the wireless medium.

[0009] Another innovative 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 of transmitting the first PPDU over the wireless medium, the first priority being different from a second priority of 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 of transmitting the one or more subsequent PPDUs over the wireless medium.

[0010] Another innovative 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 a PPDU to the second device over the wireless medium. The one or more PPDUs are provided to the second device during a current target wake-up time (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 medium access control layer (MAC).

[0011] Another innovative 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 innovative 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 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 innovative 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 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 MAC.

[0014] Another innovative 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 slice is 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 innovative 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 innovative 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 innovative 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 innovative 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 attempting to provide a plurality of PPDUs associated with one or more video frames of an XR experience to a second device, 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 innovative 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 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.

[0020] Another innovative 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 attempting to provide a plurality of posture data frames associated with one or more video frames of an XR experience to a second device, and measuring one or more of a posture data frame transmission latency associated with attempting to provide the plurality of posture data frames or a posture data frame transmission drop associated with attempting to provide the plurality of posture data frames. One or more parameters of the XR experience are adjusted and associated with one or more of the measurements.

[0021] Another innovative 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 posture 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 posture data frame transmission latency associated with attempting to provide the plurality of posture data frames or a posture data frame transmission drop associated with attempting to provide the plurality of posture data frames. One or more parameters of the XR experience are adjusted and associated with one or more of the measurements.

[0022] Another innovative 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 priority to communications on the second wireless link over communications on the first wireless link.

[0023] Another innovative 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 priority to communications on the second wireless link over communications on the first wireless link.

[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. It should be noted 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] FIG. 1 is a pictorial diagram of an exemplary group of devices for providing an extended reality (XR) experience. [Figure 2A] FIG. 1 illustrates an example protocol data unit (PDU) that may be used for communication between wireless communication devices. [Figure 2B] 2B illustrates exemplary fields in the PDU of FIG. 2A. [Figure 3A] FIG. 1 illustrates another exemplary PDU that can be used for communication between wireless communication devices. [Figure 3B] FIG. 1 illustrates another exemplary PDU that can be used for communication between wireless communication devices. [Figure 4] FIG. 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] FIG. 1 is a block diagram of an example wireless communication device. [Figure 6A] FIG. 1 is a block diagram of an exemplary access point (AP). [Figure 6B] FIG. 1 is a block diagram of an exemplary station (STA). [Figure 7] FIG. 1 is a sequence diagram illustrating an exemplary motion-to-render-to-photon (M2R2P) operation. [Figure 8]1 is a flowchart illustrating an example process for asynchronous channel access control, according to some implementations. [Figure 9] 1 is a flowchart illustrating an example process for asynchronous channel access control, according to some implementations. [Figure 10] FIG. 10 is a sequence diagram illustrating an example transmission between devices for an XR experience. [Figure 11] 1 is a flowchart illustrating an example process for synchronous channel access control based on a target wake-up time (TWT) session, according to some implementations. [Figure 12] 1 is a flowchart illustrating an example process for synchronous channel access control based on a TWT session, according to some implementations. [Figure 13] FIG. 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] FIG. 10 is a sequence diagram illustrating exemplary timing of rendering of pose data frames and video frames associated with M2R latency. [Figure 15A] FIG. 1 is a block diagram illustrating an example of synchronizing the clocks of a rendering device and a display device. [Figure 15B] FIG. 1 is a block diagram illustrating an example of synchronizing the clocks of a rendering device and a display device. [Figure 15C] FIG. 1 is a block diagram illustrating an example of synchronizing the clocks of a rendering device and a display device. [Figure 16] 1 is a flowchart illustrating an example process for managing data for transmission, according to some implementations. [Figure 17] 1 is a flowchart illustrating an example process for managing data for transmission, according to some implementations. [Figure 18]FIG. 10 is a block diagram illustrating an example of generating a queue for one or more video frames. [Figure 19] 1 is a flowchart illustrating an example process for generating feedback, according to some implementations. [Figure 20] 1 is a flowchart illustrating an example process for generating feedback, according to some implementations. [Figure 21] FIG. 2 is a block diagram of an exemplary control field. [Figure 22] 1 is a flowchart illustrating an example process for supporting simultaneous wireless links with multiple devices. [Figure 23] FIG. 10 is a sequence diagram illustrating exemplary timing of XR activity and wireless activity with an AP. DETAILED DESCRIPTION OF THE INVENTION

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

[0027] The following description is directed to several implementations for purposes of describing innovative 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 in accordance with, among other things, 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®). 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] Various implementations generally relate to architectures that provide extended reality (XR) experiences to users. Wireless data associated with XR experiences generally has strict latency and packet loss constraints to prevent a degraded 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. Additionally, 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 latency requirements. Typical wireless systems are not designed with such constraints on data rendering, delivery, and display to ensure minimum frame rates and prevent synchronization issues, stutters, or delays for XR experiences.

[0029] 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 secure 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 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 secure 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] Particular implementations may be implemented to achieve one or more of the following potential advantages: The rendering device may secure control of the wireless medium, which may enable the rendering device to meet latency requirements for an XR experience. The rendering device may allow other devices to transmit on the wireless medium, which may enable sharing of the wireless medium in an environment with multiple devices in a basic service set (BSS) or multiple overlapping basic service sets (OBSS). The rendering device is also configured to allow the display device to provide sensor measurements and other information to the rendering device such that the rendering meets latency and other requirements for the XR experience.

[0031] Some implementations relate more specifically to synchronous channel access control in a wireless system for devices providing XR experiences. According to some aspects of the present disclosure, a rendering device may use a target wake-up time (TWT) session to communicate with a display device during one or more (also referred to as windows) service periods. The TWT session may be configured and managed to secure 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] Particular implementations may be implemented to realize one or more of the following potential advantages: A rendering device may use TWT to secure control of the wireless medium, which may enable the rendering device to meet latency requirements for an XR experience. A rendering device may allow other devices to transmit on the wireless medium, which may enable sharing of the wireless medium in a multi-device environment.

[0033] 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 may manage application data to be transmitted, and a display device may manage received application data to ensure latency requirements for the XR experience are met. The management of data includes generating, queuing, and identifying MSDUs for different video slices to be transmitted, flushing the queues when appropriate, and indicating the flushes to the display device. The management at the display device may be flushing a reordering (REO) queue or otherwise managing an REO queue that receives MSDUs from the rendering device.

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

[0035] 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, the rendering device may transmit a PPDU to the display device and attempt to measure latency or packet drops associated with transmitting the PPDU. The display device may transmit posture data frames or tracking frames and attempt to measure latency or packet drops associated with transmitting the frames. 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 (e.g., measuring increased latency or packet drops). One or more parameters of the XR experience may be adjusted, and the measurements or adjustments may be indicated to the other device.

[0036] 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] Some implementations relate more specifically to support of 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 prioritizing communication with the display device (which may be associated with an XR experience having latency and other requirements). The rendering device or relay device may use a modified set of multi-link operation (MLO) techniques or TWT mode techniques to support the simultaneous links and meet the latency and other requirements of the XR experience. 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 transmitted from the AP to the relay device using a first link and transmitted from the relay device to the display device using a second link simultaneously with the first link.

[0038] 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 still supporting an XR experience. In this way, rendering or relay devices and display devices may be included in a BSS, mesh network, or other environment where the device communicates with multiple other devices while still supporting an XR experience.

[0039] 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] 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 candidates. The STAs 104 may represent a variety of devices such as a mobile phone, a personal digital assistant (PDA), other handheld device, netbook, notebook computer, tablet computer, laptop, display device (e.g., a TV, computer monitor, navigation system, HMD, among others), music or other audio or stereo device, remote control device ("remote control"), printer, kitchen or other household appliance, key fob (e.g., for a passive keyless entry and start (PKES) system), among other candidates.

[0041] 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 the 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 broadcast beacon frame (“beacon”) containing the BSSID to enable any STAs 104 within wireless range of the AP 102 to “associate” or reassociate with the AP 102 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 an identification of the primary channel used by each AP 102, as well as timing synchronization functions for establishing or maintaining timing synchronization with the AP 102. The APs 102 may provide access to external networks for various STAs 104 in the WLAN via their respective communication links 108.

[0042] 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 scan information obtained through passive or active scanning, and 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] 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 may 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. Furthermore, after associating with an AP 102, the STA 104 may also be configured to periodically scan its surroundings to find a more suitable AP 102 to associate with. 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 a lower traffic load.

[0044] In some cases, the STAs 104 may 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 may also communicate with each other directly via a direct wireless communication link 110. Furthermore, two STAs 104 may 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 may assume the role formerly played by the AP 102 in the BSS. Such a STA 104 may be referred to as a group owner (GO) and may 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] The AP 102 and the STAs 104 may 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 layer and medium access control (MAC) layer. 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 may transmit PPDUs over an unlicensed spectrum, which may be a portion of the spectrum that includes 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 may also communicate in other frequency bands, such as the 6.0 GHz band, which may support both licensed and unlicensed communications. The APs 102 and STAs 104 may also be configured to communicate over 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] 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. Thus, 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, a PPDU may be transmitted over a physical channel with a bandwidth of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by bonding multiple 20 MHz channels together.

[0047] 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. The 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 applications. The legacy preamble may also generally be used to maintain compatibility with legacy devices. The format, coding, and information provided in the non-legacy portion of the preamble are based on the specific 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] As noted above, devices (such as STA 104) may communicate directly with each other. In the case of an XR experience, a rendering device may 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] As used herein, an XR experience refers to one or more of a virtual reality (VR) experience (in which the user may be isolated 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 in a display that may appear seamless to the user), which 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] FIG. 1B shows a pictorial diagram of an exemplary group 150 of devices for providing an XR experience. Device 152 is a display device for displaying video frames of the XR experience. While device 152 is illustrated 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 exemplary 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 illustrated 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 illustrated 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 a STA communicatively coupled to device 154 in P2P mode.

[0051] 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] Many of the following examples describe generating, providing, or obtaining PPDUs associated with video frames and video slices of video frames. Aspects of the present disclosure also apply to other types of provided data. 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 concatenated to generate the entire application file. One example of an application file is 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, 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) or 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). Thus, the present disclosure is not limited to the management and transport of video data and devices specific thereto.

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

[0054] 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 shown, 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 enables the receiving device to estimate the wireless channel. The L-SIG 210 generally enables a receiving device to determine the time length of a PDU and use the determined time length to avoid transmitting over the PDU. 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] 2B shows an example L-SIG field 220 in the PDU of FIG. 2A. The L-SIG 220 includes a data rate field 222, spare bits 224, a length field 226, parity bits 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 bits 228 are 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 time length of the packet, e.g., in microseconds (μs).

[0056] 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 following the preamble, e.g., in the form of a PSDU including a data field 324.

[0057] 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 a repetition of 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 HE long training fields (or symbols) (HE-LTF) 322. In the case of 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. In instances involving the use of bonded channels, 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 contrast, the content of HE-SIG-B318 is unique to each 20 MHz channel and may be targeted to specific STAs 104 .

[0058] 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 inform 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 a 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] The HE-SIG-B 318 may carry STA-specific scheduling information, such as 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 assignments 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 encoded with common bits, CRC bits, and tail bits. The user-specific field may be assigned to a particular STA 104 and 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 the data field 324.

[0060] 3B illustrates another exemplary PPDU 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] 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 constructed as and carry version-dependent information for other wireless communication protocol versions beyond EHT. The non-legacy portion 354 further includes an additional (referred to herein as “EHT-STF 370,” although it may be constructed as and carry version-dependent information for other wireless communication protocol versions beyond EHT) short training field 370 and one or more additional (referred to herein as “EHT-LTF 372,” although it may be constructed as and carry version-dependent information for other wireless communication protocol versions beyond EHT) long training fields 372. In instances involving the use of bonded channels, such as 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 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] The EHT-SIG 368 may include one or more jointly encoded 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 to identify and inform 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] 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 to multiple STAs 104, indicate RU allocation in the frequency domain, indicate 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 encoded with common bits, CRC bits, and tail bits. The user-specific field may be assigned to a specific STA 104 and 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, for example, two user fields that store information for two respective STAs to decode the respective RU payloads.

[0064] The presence of RL-SIG 364 and U-SIG 366 may indicate to EHT or later version-compliant STAs 104 that PPDU 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 one or more of EHT-SIG 368 or data field 376.

[0065] 4 illustrates an exemplary PPDU 400 usable 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 may carry one or more MAC protocol data units (MPDUs). For example, each PSDU 404 may 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 may 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 contains a corresponding MSDU 420 that is preceded by a sub-frame header 422.

[0066] Referring again to the A-MPDU subframe 406, the MAC header 412 may include several fields that store information that defines or indicates 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 that stores 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 time length field that indicates the length of time 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 A-MPDU). Use of the time length field serves to secure the wireless medium for the indicated length of time, thus establishing the 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] 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] 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 to different STAs 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 leakage of the transmit center frequency.

[0069] 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 thus enable multiple STAs 104 to transmit 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 thus each STA 104) one or more RUs that can be used to transmit 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] 5 shows a block diagram of an example wireless communication device 500. In some implementations, the wireless communication device 500 may be an example of a device for use in a 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 associated with 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] 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] 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 converted 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 prior to being provided to the IFFT block.

[0073] During 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 an 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 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 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 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] 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] 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 through the radio 504 and modem 502 and processes information to be output through 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 may generally control the modem 502 to cause the modem to perform the various operations described above.

[0076] 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 that stores 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] 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 to the wireless communication device 610 for transmitting and receiving wireless communications. In some implementations, the AP 602 further includes an application processor 630 coupled to the wireless communication device 610 and a memory 640 coupled to 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). 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] 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. One of the aforementioned components can communicate with another one 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] 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), haptic gloves, or a haptic vest). 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 attitude information. The IMU measures attitude information at defined intervals (such as every 100 microseconds (μs)).

[0080] 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 in the user's field of view (FOV) at 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 video frames to overlay the store name, hours of operation, 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 pose frames) and tracking frames. While rendering is described in the examples as being based on pose frames, rendering may also be based on one or more tracking frames from the display device.

[0081] 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 another suitable memory of the STA 604) and executed by the application processor 635. In this manner, the STA 604 (acting as a SAP) may perform some of the functions of the AP 602.

[0082] 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. For purposes of clarity and brevity only in describing aspects of the present disclosure, AP 602 may be referred to in examples herein when describing a rendering device for an XR experience. The display device for the XR experience is device 152. The STA 604 may be referred to in examples herein when describing a display device for an XR experience. In some implementations, the rendering device and display device may communicate over the 6 GHz frequency band (e.g., for transmitting PPDUs or posture packets between devices). However, any suitable frequency band (such as 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 devices may be configured to have a one-way latency (e.g., on the DL or on the UL) of less than 10 ms.

[0083] 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. The application layer for an XR experience at 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. The application layer for an XR experience at a display device may include displaying video for an XR application executed by the display device.

[0084] 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, a wireless layer of a rendering device may refer to the WCD 610 performing operations at the wireless layer. As used herein, a wireless layer of a display device may refer to the WCD 615 performing operations at the wireless layer.

[0085] The process from measuring 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 entire process from measuring 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 display device are configured such that M2R2P is less than 70 ms (e.g., between 50 ms and 70 ms).

[0086] 7 shows a sequence diagram 700 illustrating exemplary M2R2P operations. The exemplary M2R2P operations relate 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 times than those shown.

[0087] The IMU of the display device generates multiple IMU measurements (702). Each line represents an IMU measurement. As shown, 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 (710) based on the attitude information (or other information) obtained in the IMU measurement packet. The rendering device may generate one or more PPDUs to include the encoded video frame and transmit the one or more PPDUs to the display device during a DL transmission 712 of the transmit / receive window 708. The UL transmission 706 and DL transmission 712 include 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 use a jitter buffer to capture the decoded frame information and smooth the video frame generation time to prevent jitter in the video (716). For example, the jitter buffer is used to ensure a consistent playback schedule of the video frames by removing variations in decoding time. In some implementations, the display device may perform asynchronous time warping (ATW) on one or more video frames (718) to increase the perceived frame rate of the displayed video or to compensate for latency between when IMU measurements are taken and when the video frames are displayed. The display device displays the video frames (720) that are based on the IMU measurements selected in 702.

[0088] As used herein, IMU measurements may be referred to as attitude information, and IMU measurement packets may be referred to as attitude packets or attitude data packets. Attitude information may include the device's orientation with respect to azimuth, the device's motion, the device's location, or other characteristics of a particular location of the device that are used to generate appropriate video frames to be displayed by the device. In FIG. 7 , attitude packets are illustrated as being generated once per video frame. In some implementations, attitude 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 the display device may generate an attitude packet every 2 ms. In this manner, at least eight attitude packets may be generated during the display of one video frame. The display device may select the most recent attitude packet when an attitude packet is to be provided to the rendering device. The rendering device may generate video frames based on the acquired attitude packets. In some implementations, the most recent attitude packet may not be acquired by the rendering device due to DL transmission from the rendering device to the display device. The rendering device may use the most recently acquired attitude packet to generate a video frame. To reduce the latency between the attitude packet and rendering a video frame, the display device may provide multiple attitude packets while rendering and encoding the previous video frame. In some other implementations, the transmission of the attitude packets is synchronized with the rendering and encoding. In this way, the timing of transmitting the attitude packets is ensured such that the rendering device obtains the attitude packet for rendering the next video frame.

[0089] With respect to access to the wireless medium, the M2R2P latency requirements of an XR experience may cause the wireless system to give priority to rendering and display devices to obtain control of the wireless medium. Priority for rendering and display devices may be with respect to other devices in the same BSS or one or more devices from an BSS within range of the rendering or display device. Obtaining control of the wireless medium may 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 may be asynchronous (such as devices competing for the wireless medium during a contention window) or synchronous (such as one or more APs coordinating access to the wireless medium between devices). As described in the following examples, providing priority 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 may be referred to as asynchronous channel access control. Synchronous control of the wireless medium may be referred to as synchronous channel access control. The wireless system may also be configured to prevent collisions between DL traffic and UL traffic between the rendering device and the display device, prevent interference between the link between the rendering device and the AP and the link between the rendering device and the display device, or enable power savings in the rendering device or the display device based on channel access control.

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

[0091] At 802, a device obtains control of a wireless medium. 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 noted 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] At 808, the device provides the first PPDU to the second device.

[0093] 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 act of providing the one or more subsequent PPDUs is associated with a third priority of transmitting the one or more subsequent PPDUs over the wireless medium (812).

[0094] 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 for gaining 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 to indicate the highest priority traffic to be transmitted, the AIFSN may be 1, and for a third priority to indicate traffic having a lower priority than the first priority, the AIFSN may be 3. For a second priority to indicate traffic having a higher priority than the third priority and a lower priority 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] 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 transmission 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., for an attitude packet) from the display device, which may in turn be attempted to be transmitted earlier than one or more subsequent PPDUs (e.g., for a video frame) from the rendering device. In some implementations, the first backoff counter value may be 0, the second backoff counter value may indicate a period greater than a short interframe spacing (SIFS), and the third backoff counter value may indicate a period greater than the period indicated by the second backoff counter value.

[0096] 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 may 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 may also adjust a back-off counter value from a first value to a third value (e.g., by setting the back-off counter value to the third value for subsequent PPDUs) 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 than other devices (including the display device and other devices in the OBSS). Conversely, the display device may transmit data (e.g., an attitude packet) to the rendering device before one or more subsequent PPDUs are transmitted to the display device.

[0097] In some implementations, a rendering device uses a request to send (RTS) / clear to send (CTS) mechanism to obtain control of the wireless medium and reserve the wireless medium. For example, the rendering device may provide (e.g., broadcast) a first RTS frame to obtain control of the wireless medium. The RTS frame may be transmitted based on a first backoff counter value. The first RTS frame includes a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time. The NAV indicates the period for which the wireless medium will be 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 for the indicated length of time to prevent transmitting on the wireless medium for the indicated length of time. An exemplary RTS / CTS mechanism and transmission of data between the rendering device and the display device are described in more detail below with reference to FIG. 10.

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

[0099] 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 wireless communication device implemented in a device (such as device 152 of FIG. 1B) or a device (such as WCD 615 of FIG. 6B). The device performing the operations may be a display device for an XR experience.

[0100] 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 of FIG. 1B acting as an SAP), or another device for providing the PPDU of the application file to the device (in the following examples related 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] The second device obtains control of the wireless medium to provide the 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] At 910, the device obtains one or more subsequent PPDUs of the application file from the second device. The act of 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 (912). As mentioned above, the priority may be associated with one or more of a backoff counter value or a set of EDCA parameters.

[0103] FIG. 10 shows a sequence diagram 1000 illustrating exemplary transmissions between devices for an XR experience. The devices are illustrated as a rendering device and a display device for illustrative purposes, but the described concepts may be extended to other types of devices. The start time t0 may indicate the beginning 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] After a BO period based on the first BO value (time t1), the rendering device may transmit an RTS frame. The end of the RTS frame on the wireless medium is at time t2. The display device transmits a CTS frame to the rendering device a SIFS length after time t2 (time t3). Transmitting the CTS frame may be based on the display device obtaining an RTS frame (which may indicate that the wireless medium is free) and that the display device is 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 transmits a first PPDU of an application file (e.g., an application file for a video frame) to the display device a SIFS length after time t4 (time t5).

[0105] Although not shown, if the CTS frame is not acquired by the rendering device, the rendering device may again wait a BO 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 RTS frame transmission failed. In some implementations, the RTS / CTS mechanism before securing the wireless medium is associated with a video frame. If the RTS transmission fails (and the rendering device is unable to acquire control of the wireless medium), the rendering device may prevent providing the associated frame to the display device and attempt to acquire control of the wireless medium to provide the next frame to the display device. 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 be 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 lower the bandwidth requirements and increase the probability of delivering the video frame to the display device.

[0106] Referring again to FIG. 10, the end of the first PPDU on the wireless medium is at time t6. The display device transmits a Block Acknowledgement (BA) to the rendering device SIFS time after 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 in 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] The end of the BA on the wireless medium is at time t8. The rendering device transmits a second PPDU to the display device at a SIFS time length after time t8 (time t9), and the end of the second PPDU on the wireless medium is at time t 10 The process may 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 transmit the PPDUs at time t 11 The Nth PPDU may be transmitted at time t 12 The display device is 12 After the SIFS time (time t 13 ) to the rendering device, and the termination of the BA on the wireless medium is at time t 14 is located.

[0108] Referring back to the RTS frame, the RTS frame indicates a NAV value to reserve the wireless medium for a length of time greater than the TXOP (such as the original indicated NAV protection time length). For example, the TXOP may be configurable by the rendering device for a length of time of up to 2.5 ms. The RTS frame indicates a NAV value of 2.5 ms or greater 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 prevent the receiving device from transmitting during that length of time. Extending the NAV may refer to the rendering device indicating a NAV padding value or a new NAV value to increase or set the NAV of each receiving device to extend the length of time the receiving device should prevent transmission. The NAV time length and TXOP may begin at the start time of the RTS frame. In some implementations, the rendering device indicates the NAV time length to be set to the TXOP time length (such as 2.5 ms). The rendering device may also indicate a minimum NAV value in each PPDU (such as the first PPDU to the Nth PPDU) to ensure that the remaining NAV is of a minimum length of time or to extend the NAV (such as by indicating 1 ms of NAV padding following the PPDU transmission).

[0109] 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., 0) reaches 0, the display device may transmit data to the rendering device. The data from the display device may include pose information or any other suitable UL data for an XR experience.

[0110] The end of the data on the wireless medium is at time t 16 The rendering device is 16After the SIFS time (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, transmitting a video frame may not be completed during the first TXOP, and the remainder of the video frame should be transmitted during one or more subsequent TXOPs. As shown, the original NAV protection is applied when the wireless medium is busy for a time t 18 indicates that it is still reserved by the rendering device after

[0111] 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 (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 shown, a new RTS frame is provided at time t 19 is still within the original NAV protection time length. The new RTS may indicate a new NAV value indicating extended NAV protection (which may be similar in time length to the original NAV protection). In this way, the NAV of each receiving device is reset to the indicated NAV value, effectively extending the reservation of NAV by the rendering device. The new RTS frame may also indicate a new TXOP.

[0112] The end of the RTS frame on the wireless medium occurs at time t 20 The display device is 20 After the SIFS time (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 time (time t 23 ) to the display device. The process may be repeated in the same manner as the first TXOP for one or more further TXOPs.

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

[0114] The rendering device may include a video queue for receiving MSDUs. The MSDU includes a descriptor for indicating a particular video frame with which the MSDU is 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, an MSDU associated with a next video frame may be received in the video queue before all MSDUs associated with a current video frame are successfully provided to the display device. In some implementations, the rendering device may 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 may provide the remaining MSDUs of the current video frame.

[0115] As mentioned above, the rendering device may configure itself for a first priority for the first PPDU of a video frame. In some implementations, the rendering device may 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 receives a first MSDU associated with a second video frame, the rendering device may 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 may enable RTS / CTS (with the first MSDU to be included in the first PPDU of the video frame). Additionally or alternatively, the rendering device may set the number of retries for RTS / CTS to a predetermined 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] The first MSDU may include metadata identifying the first MDSU within the first PPDU of the video frame (e.g., in the sub-frame header 422 of the MSDU sub-frame 416 shown in FIG. 4). A display device acquiring and processing the first PPDU may 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 MDSU within the last PPDU of the video frame (e.g., in the sub-frame header 422 of the MSDU sub-frame 416 shown in FIG. 4). A display device acquiring and processing the PPDU may determine, based on the metadata, that the PPDU includes the last MSDU associated with the video frame. The rendering device may avoid including an indication of NAV padding in the last PPDU or may otherwise use the last PPDU to extend the NAV. In this manner, the rendering device may relinquish control of the wireless medium at the end of the current NAV. Additionally or alternatively, the rendering device may transmit a contention free (CF)-End beacon after providing the last MSDU to instruct the receiving devices to clear their NAV. In this way, the rendering device may relinquish control of the wireless medium before the end of its current NAV.

[0117] In some implementations, the rendering device may shorten one or more TXOPs (such as the first TXOP) from the maximum time length. 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 during times other than the TXOP.

[0118] A device (such as a rendering device) and a second device (such as a display device) may be in a 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 type 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] The rendering device may always obtain control to transmit the first PPDU based on the first priority. For example, a first set of EDCA parameters (associated with the first priority) gives the rendering device priority 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 (for transmitting a subsequent PPDU associated with the third priority) and the display device (for transmitting data associated with the second priority) may have priority over the OBSS device. For example, the EDCA parameters associated with the fourth priority may prevent the OBSS device from transmitting data classified as best-effort.

[0120] In some implementations, the third set of EDCA parameters may be configured to allow the device to transmit data classified as high importance (which may be associated with a set of EDCA parameters that allows 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 data classified as high importance (e.g., based on a differentiated services code point (DSCP) value), the device may transmit the data at time t 18 It may be possible to transmit data (based on its EDCA parameters associated with the DSCP value) after and before the rendering device should transmit the next RTS (associated with the third set of EDCA parameters). If the device is to transmit data classified as best effort (e.g., based on the DSCP value), the device's EDCA parameters associated with the DSCP value may prevent the device from blocking the rendering device from transmitting an RTS associated with the third set of EDCA parameters. The device may attempt to transmit such data (or data classified as high importance) at the end of the NAV time.

[0121] The above examples illustrate 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 in the IEEE 802.11ax standard) coordinated by one or more APs (e.g., pre-802.11ax APs (sometimes referred to as legacy APs)).

[0122] 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 that time. A TWT SP may be referred to herein as a TWT window or window.

[0123] A TWT session (also called TWT) may contain multiple characteristics. - whether it is an individual TWT (between two specific devices) or a broadcast TWT (between three or more devices or between devices that may change during the TWT); - whether it is a solicited TWT (STA initiates TWT with the AP, which may accept, reject, or offer alternatives) or an unsolicited TWT (AP sends unsolicited TWT responses based on a known cycle while the STA is listening to the wireless medium); - Announced TWT (STA indicates when it is awake in TWT SP (e.g., via power save (PS)-Poll or automatic power save delivery (APSD) trigger frame) before the AP can send DL traffic) or non-announced TWT (AP can send DL traffic without waiting for instructions from the STA during TWT SP) Whether the TWT is trigger-enabled (the AP sends a trigger frame to the STA before the STA can send UL traffic) or trigger-less (the STA can send UL traffic without waiting for a trigger frame), and - whether it is implicit TWT (STA calculates the next TWT SP start time a certain amount of time away from the current TWT SP start time) or explicit TWT (STA requests the next TWT SP start time from the AP) Includes.

[0124] A TWT for synchronous channel access control between a rendering device and a display device (such as for an XR experience) may be an individual TWT, a request-based TWT, an announcement-based TWT, a trigger-less TWT, and an implicit TWT. In some implementations, the TWT is a non-request-based TWT. The TWT may include such characteristics to protect the XR activities of the rendering device and the display device. For example, an individual TWT ensures that a TWT window is prepared only for the rendering device and the display device to communicate DL traffic (and UL traffic) with each other, a request-based TWT and an announcement-based TWT 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), a trigger-less TWT allows the display device to transmit attitude data frames at a greater frequency (without requiring the overhead of trigger frames from the rendering device), and an implicit TWT reduces the overhead caused by the display device requesting (and the rendering device providing) the next TWT SP start time. Although an exemplary set of properties for a TWT is shown, any suitable set of properties may be used.

[0125] As used herein, an XR activity may refer to any act 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 activities may include measuring the location of a display device with an IMU of the display device, generating a posture frame or posture packet (also called a posture data frame) from the IMU measurements, generating a tracking frame, providing the posture frame and tracking frame to a rendering device, rendering and encoding one or more video frames based on the posture frame and tracking frame, packetizing the one or more video frames, providing the packets to the 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 activities may additionally or alternatively include operations to provide audio, haptic feedback, or other sensory information to a user during an XR experience.

[0126] 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 transmitted by the display device when available (including outside the TWT window). In some implementations, however, UL traffic is transmitted during the TWT window. As noted above, for an XR experience, UL traffic may include posture frames and tracking frames from the display device. DL traffic may include PPDUs carrying video frame data from the rendering device. PPDUs, posture 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 related to rendering and display devices for XR experiences for ease of describing the aspects, aspects of the present disclosure are not limited to the examples given.

[0127] Referring again to FIG. 7, the rendering and encoding of each video frame by the rendering device (710) may occur at a known interval and periodicity associated with the frame rate of the display (720). A TWT window for a TWT session between the rendering device and the display device may be prepared 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 discussed above, the TWT window includes the time during which the wireless medium is allocated for UL and DL data to be transmitted between the rendering device and the display device. In this manner, the time when UL traffic should be transmitted by the display device may be coordinated with the time when DL traffic should be transmitted, so that both UL and DL traffic can be transmitted during the TWT window. The rendering device may prepare 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] 11 shows a flowchart illustrating an example process 1100 for synchronized channel access control based on a TWT session, according to some implementations. The operations in the example process may be performed by a wireless communication device implemented in a device (such as device 154 of FIG. 1B) or a device (such as WCD 615 of FIG. 6B). The device performing the operations may be a rendering device for an XR experience.

[0129] At 1102, the 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] 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 attitude frames may also be acquired during the current TWT window. In this manner, both UL data and DL data may be transmitted during the current TWT window.

[0131] 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 or DL ​​data is transmitted during the TWT window, the second device (such as a display device) should remain awake and listen for the length of the TWT window that is not used for transmission. Furthermore, 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 noted 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 the 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 manner, 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 at which DL and UL data should be transmitted to reduce any latency between the start of the TWT window and transmission and to reduce any time the rendering device must wait between preparing one or more PPDUs for transmission and transmitting the one or more PPDUs.

[0132] 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 illustrated 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 posture data frame, and a rendering of the video frame is associated with the acquired posture data frame. As described above, a video frame (e.g., a first video frame) includes multiple video slices, and a rendering of the first video frame is associated with a posture data frame most recently acquired 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] The second device listens for DL ​​data during the TWT window. If transmissions of both DL and UL data are coordinated so that they 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 (e.g., by turning off or reducing power to one or more components of its wireless communication device) between TWT windows. In this way, the second device may reduce power consumption. For example, many display devices (such as HMDs) are battery-powered to allow users 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 length of time the display device can be used between charges. Such a low-power mode between TWT sessions may be referred to as a TWD power-save mode.

[0134] 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 low power mode (TWT power save mode) after the current TWT window. The instruction may be included in a power management (PM) field in the MAC header of a packet (e.g., the PM bit in the frame control field set to 0 to instruct the display device not to enter 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 low power mode should be prevented after the current TWT window. 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] 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 be ended 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 solely 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 transmitted after more than 10 ms of inactivity during the TWT window. In some implementations, the rendering device is configured to transmit an EOSP packet after 10 ms of inactivity since the last PPDU.

[0136] 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. When 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 transmit 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 determine to transmit an EOSP packet based on the metadata of the last MSDU.

[0137] The low power mode (TWT power save mode) referred to herein may differ from one or more sleep modes defined in the IEEE 802.11 standard (such as pre-802.11ax standards, including 802.11ba). 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 the standard-defined sleep mode (called deep sleep) designed for traffic classified as best effort 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 to reduce the amount of time spent entering and exiting the low power mode.

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

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

[0140] 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 posture data frame or a tracking frame.

[0141] 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), 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 device or when the first PPDU is provided from an application layer of the second device to a MAC (1208).

[0142] 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 the tracking frame or one or more posture data frames for each video frame to be rendered. In this manner, the frequency at which the tracking frame or one or more posture data frames are provided is the same as the frequency of the video frames. For example, the posture 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 posture data frame before the first PPDU of a video frame is ready for transmission. In some implementations, the TWT window begins when the tracking frame or the first posture data frame of the one or more posture 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 the XR experience.

[0143] FIG. 13 shows a sequence diagram 1300 illustrating example timing for rendering posture data frames and video frames associated with M2R latency. At 1302, a display device acquires posture information. For example, the display device determines to package current IMU measurements into posture data frame N-1 (for any integer N greater than 0) and provide posture 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 posture 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 transmitting posture frame N-1 or using a lower MCS rate to transmit posture frame N-1. After acquiring posture frame N-1 (1306), the rendering device begins rendering video frame N-1 (1308). Time 1310 indicates the rendering time for rendering video frame N-1. Although not shown, 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 shown, PPDUs may be provided before or after encoding of an entire frame is complete. For example, a video slice may be packaged into one or more PPDUs at the same time 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] At 1316, the display device again acquires attitude information. For example, the display device determines to package the current IMU measurements at that time into attitude data frame N. Attitude 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 shown as being greater than UL latency 1304 to illustrate that UL latency may vary.

[0145] At 1322, the rendering device begins rendering video frame N. The video may have a particular frame rate, and the interval between rendering video frames may be fixed based on the frame rate, resolution, encoding, and other video parameters. In this manner, the length of time between time 1308 and time 1322 may be the same as the length 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] The rendering device renders the current frame based on the most recent posture frame acquired from the display device. For video frame N, time 1322 precedes time 1320 (when posture frame N is acquired). Thus, the rendering device does not render video frame N based on posture frame N (because posture frame N has not yet been acquired). If the last posture frame acquired is posture frame N-1, the rendering device renders video frame N based on posture frame N-1. M2R latency may be the latency between an IMU measurement and the rendering of a video frame associated with the IMU measurement. Because video frame N is based on posture data frame N-1, M2R latency 1314 is greater than if posture frame N had been received in time. The M2R latency may be determined based on a default or known UL latency.

[0147] In some implementations, TWT window 1328 may begin at time 1302 (assuming time 1302 is when the display device should transmit posture frame N−1). If the length of time between times 1302 and 1316 is fixed (such as the same length of time as between times 1308 and 1322), the length of TWT window 1328 may be fixed to completely encompass time 1312. Because time 1312 may vary, TWT window 1328 may be of a length to accommodate variations in time 1312 (such as a length to allow for transmission of video frames based on a maximum resolution, a minimum MCS, a minimum channel size, etc.). As mentioned 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 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. Sequence diagram 1300 (and other sequence diagrams shown) is not to scale, and operation may vary. For example, DL (1312) of video frame N-1 may be combined with UL (1320) of posture frame N into one TWT window.

[0148] In the example sequence diagram 1300, the timing of providing posture frames and rendering video frames are not coordinated, which may result in video frames being rendered before new posture data frames are received, increasing M2R latency. The rendering device may coordinate the rendering of video frames, or the display device may coordinate the provision of posture frames to the rendering device (e.g., the rendering device and display device coordinate such that time 1320 is followed by time 1322) so that one or more posture frames are obtained before rendering new video frames. Figure 14 illustrates coordinated timing to reduce M2R latency.

[0149] FIG. 14 shows a sequence diagram 1400 illustrating example timing for rendering posture data frames and video frames associated with M2R latency. At 1402, a display device acquires posture information. For example, the display device determines to package current IMU measurements into posture data frame N-1 (for any integer N greater than 0) and provide posture data frame N-1 to a rendering device. UL latency 1404 is the length of time from the time of the IMU measurement to the time the rendering device acquires posture frame N-1 (at 1406). UL latency 1404 may vary based on the amount of information to transmit 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 transmitting posture frame N-1 or using a lower MCS rate to transmit posture frame N-1. After acquiring posture 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 PPDUs are provided from the rendering device to the display device.

[0150] At 1416, the display device acquires attitude information and provides attitude data frame N to the rendering device. UL latency 1418 is the length of time from the time of the IMU measurement to the time the rendering device acquires attitude data frame N (at 1420). UL latency 1418 for attitude frame N 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] The length of time between time 1408 and time 1422 may be the same as the length of time between 1308 and 1322 in FIG. 13. A difference between FIG. 13 and FIG. 14 may be the timing between the provision of posture frames by the display device and the rendering of video frames by the rendering device. As illustrated in FIG. 14, the timing of rendering video frames is coordinated with the timing of the display device providing posture frames to the rendering device. For example, time 1422 is determined such that time 1422 remains after time 1420. In this manner, posture frame N may be obtained before the rendering of video frame N, and posture frame N may be used to render video frame N. In some implementations, the timing may be based on the UL latency for the posture frames (potential UL latency based on minimum MCS, minimum wireless channel, level of noise, use of FEC, other parameters that slow the throughput of transmitting posture data frames to the rendering device, etc.). 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] When rendering and providing posture 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 the video frame. In some implementations, the first offset may be an M2R latency (such as the M2R latency 1414 before the time 1408 at which the TWT window 1428 begins).

[0153] As illustrated in FIGS. 13 and 14 , posture data frames may be acquired or provided, and video frames may be rendered at the same frequency. In some implementations, at least one posture data frame provided at the beginning of a TWT window may be provided at a first frequency, while two or more posture data frames may be provided during a TWT window (e.g., providing a posture data frame in the middle of the TWT window or toward the end of the TWT window). In this manner, each posture data frame 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 posture data frame during a TWT window (e.g., based on transient interference on the wireless medium), additional posture data frames may be provided during the TWT window. For example, if posture frame N is not acquired by the rendering device of FIG. 14 , but the display device provides an intermediate posture frame at the end of the TWT window 1428, the rendering device may use the intermediate posture frame (instead of posture frame N−1) to render video frame N. In such instances, providing additional posture frames may reduce the latency between when posture information is acquired and when the video frame is rendered.

[0154] Referring back to the posture frames provided at the beginning of the TWT window, acquiring posture frames and rendering video frames are performed at the same frequency, and the timing between rendering video frames and acquiring posture frames is adjusted to reduce M2R latency. Acquiring posture 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 back to FIGS. 6A and 6B , application processor 630 (in cooperation with memory 640) may 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) may 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 acquires 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 for performing application layer operations. In this manner, the application layer clock is used by the device for timing 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] As mentioned 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 attitude data frames, tracking frames, or PPDUs for transmission and managing packet reception may occur in the MAC and be managed by the WCD 610 or 615. The WCD's operations are 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) of the device that is different from the material for the application layer clock. Because the device may use two different crystals (and therefore different logic) to generate the application layer clock and the WCD clock, the application clock and the WCD clock may differ in frequency, resolution, or phase.

[0156] To coordinate the timing between providing posture frames (and tracking frames) and rendering video frames, the display device and the rendering device may synchronize their application layer clocks with the WCD clocks. In this way, the application layer clocks and the WCD clocks may 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 may 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 may 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] Figures 15A to 15C illustrate different blocks that are reference clocks for synchronization: the application layer clock of the display device is illustrated as the reference clock in Figure 15A, the application layer clock of the rendering device is illustrated as the reference clock in Figure 15B, and the WCD clock of the rendering or display device is illustrated as the reference clock in Figure 15C.

[0158] 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] 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 attitude 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] 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 values ​​to the WCD of rendering device 1502 (e.g., via an attitude data frame or a beacon frame from display device 1508 to rendering device 1502). Synchronizing WCD clock 1512 to application layer clock 1510 adjusts the TSF timers of the WCD of display device 1508. Because the indication of the TSF timer values ​​is periodically provided to the WCD of rendering device 1502, the adjusted TSF timer values ​​are indicated to the WCD of rendering device 1502. Rendering device 1502 may adjust its WCD clock based on the adjusted TSF timer values ​​from display device 1508.

[0161] Once 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 its 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 values ​​and the time the packets are sent) may be used in synchronizing the application layer clock 1504.

[0162] 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 the reference clock, and other clocks are synchronized to the application layer clock 1524.

[0163] 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 a 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] 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 rendering device 1502 (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. Once 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 the packet 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] 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] At 1554, WCD clocks 1546 and 1552 are synchronized with each other. For example, when timing information is provided between the devices (as described above with reference to FIG. 15A and FIG. 15B), 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] 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 need not be adjusted during operation. The application layer clock 1510 is not adjusted during operation, and the display of video frames may remain unchanged during operation because the display of video frames is based on the application layer clock 1510 of the display device 1508 (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 TWT window interval, the TWT window size, and the start time of the TWT window. The display device 1508 may align the TWT window with UL traffic (e.g., align the start of the TWT window with the transmission of posture frames). In this manner, the timing at which attitude 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 particular IMU measurements to be used to generate an attitude frame may be based on a TWT schedule determined based on the application layer clock 1510.

[0168] When the WCD clock 1506 and the application layer clock 1504 are synchronized to the application layer clock 1510, the rendering device 1502 may 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 as being at the beginning of the TWT window (including TWT window 1428) based on the TWT schedule. The rendering device may adjust times 1408 and 1422 (for rendering 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 discussed above, the M2R latency 1414 may be known. The first offset may be the M2R latency 1414. In this manner, the rendering device may adjust time 1410 to be the M2R latency 1414 after time 1402.

[0169] In some implementations, the rendering device may trigger times 1408 and 1422 based on obtaining an attitude frame during the TWT window or based on a timeout from the beginning of the TWT window. For example, triggering the rendering of video frame N-1 (at time 1408) may be based on obtaining attitude frame N-1 (at time 1406). In this manner, the difference between times 1406 and 1408 is based on the length of time required to trigger the rendering of the video frame (e.g., processing the attitude frame and providing attitude information by the WCD to the application layer before rendering the video frame at the application layer). As mentioned above, if the rendering device is unable to obtain an attitude 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 may retry providing the attitude frame one or more times (e.g., up to a maximum number of times or up to the timeout length from the beginning 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, at most, the length of time from the beginning of a TWT window (such as times 1402 to 1408) 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 in the TWT session. In this manner, the rendering device begins counting from the beginning of each TWT window, and the rendering device triggers the rendering of a video frame upon reaching the timeout period or upon acquiring an attitude frame, whichever occurs first. If a timeout occurs (the timeout period is reached before acquiring an attitude frame), the rendering device may use the last acquired attitude frame acquired before the TWT window (such as during the last TWT window) to generate the video frame.

[0170] In some implementations, the display device may indicate when the rendering device should begin rendering a video frame. In this manner, 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 between the WCDs, and the rendering device may convert the indicated time into an application layer time at which to render the video frame.

[0171] 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 need not 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 an offset earlier than the rendering time 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 and 1416 (which are the start of the TWT window) to be a first offset (associated with M2R latency) before the set rendering times 1408 and 1422. In some implementations, the first offset may be M2R latency 1414 as described above. As mentioned above, the M2R latency (and the first offset) may be determined taking into account the UL latency.

[0172] 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 may align the TWT window with the UL traffic. For example, referring again to FIG. 14, the display device may determine times 1402 and 1416 as being at the beginning of the TWT window (including TWT window 1428) based on the TWT schedule indicated by the rendering device. The display device 1528 may also align the display time of 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] Referring again to FIG. 15C , if the WCD clock 1546 or 1552 is the reference clock, 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. Using the WCD clock as the reference clock, 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] 14, in some implementations, the rendering device may set times 1408 and 1422 as being a first offset after the start of their respective TWT windows (e.g., for time 1408, the first offset is equal to time 1402 followed by M2R latency 1414). In some implementations, the rendering device may trigger rendering based on obtaining a posture frame (such as those 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] 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 100 μs or more). If the drift is greater than the defined threshold, the device may resynchronize the application layer clock and the WCD clock. Synchronization may be performed as described above in connection with FIGS. 15A-15C and based on which clock is the reference block. If the device includes a reference clock, other devices may also synchronize their clocks based on the synchronization.

[0176] In the above example, the display device may provide two or more attitude frames during the TWT window. For example, the first attitude frame may be provided at the beginning of the TWT window. The display device may also provide one or more additional attitude frames later in the TWT window. In some implementations, the display device may provide additional attitude frames after a defined period of inactivity on the wireless medium during the TWT window. In some implementations, the display device may provide additional attitude 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 attitude frame may be based on new IMU measurements. If an attitude frame is not acquired by the rendering device (e.g., based on interference on the wireless medium), the previous attitude information acquired at the rendering device is no older than if only one attitude frame per TWT window were provided.

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

[0178] 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 traffic classified as being best effort to another device). In this manner, the handling of data and the communication of such data may be based on its use (such as whether it is XR-related data or not).

[0179] For traffic classified as best effort, stations typically provide MSDU-level traffic to a first-in, first-out (FIFO) queue at the WCD for transmission. Management of MSDUs in the queue has no concept of deadlines or latency requirements for data delivery; each MSDU is managed independently of other MSDUs. For XR applications, an application file may require more than one MSDU. Furthermore, time constraints for delivering application data (such as delivering a video frame within a specified length of time) may require that an MSDU carry application data that is to be delivered within a specified length 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 the video slice. In some implementations, the rendering and display devices are configured to manage XR traffic to ensure that all MSDUs of an application file are delivered in time to meet latency requirements for the XR experience.

[0180] FIG. 16 shows a flowchart illustrating an example process 1600 for managing data for transmission, according to some implementations. While the example illustrates data as video frames of 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] At 1602, a device renders a plurality of video frames to be provided to a second device.

[0182] 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 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 incremented 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] The process 1600 illustrated in Figure 16 is from the perspective of a rendering device. The process 1700 illustrated in Figure 17 is similar to the process 1600, but may be from the perspective of a display device.

[0184] 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 to include 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] FIG. 18 shows a block diagram 1800 illustrating an example of generating a queue for one or more video frames. 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 also 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 illustrated as being packaged into the same number of IP packets, each video slice may be packaged into any suitable number of IP packets.

[0186] Each queue may be an MSDU queue generated in software by a rendering device (such as a WCD) and stored in the rendering device's memory. 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 rendering device's WCD 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] The DSCP value may be based on the video frame intended for the XR experience. In this manner, the DSCP value may be based on the usage. 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 may use a previously reserved DSCP value that may be defined by the rendering device and display device as being associated with the priority of a specific video slice.

[0188] 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 may decide to transmit the MSDU of the video slice rather than other data based on the 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 the 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 for transmission by the rendering device than a p-slice (which may be indicated by a different TID).

[0189] Based on the identifiers of the MSDU queues for the specific video slice and frame, the rendering device may schedule MSDUs for transmission in multiple PPDUs to the display device. For example, the rendering device may 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 not provide a BA for a transmitted PPDU, or the display device may provide a BA indicating which MPDUs (including one or more MSDUs) were successfully acquired.

[0190] A video slice is associated with a latency requirement for displaying a video frame on a video device. If one or more MSDUs are not successfully delivered to the display device within a certain length of time to allow the display device to display the video frame (e.g., not receiving a BA indicating one or more MPDUs containing the MSDUs within a set length of time), the rendering device may 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 occurs 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 no longer attempt to deliver 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 (there are 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 start providing the MSDUs in queue N+1. As mentioned 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 so that MSDUs are no longer scheduled for transmission to the display device (the remaining MSDUs are considered stale).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] In some implementations, a rendering device may continue to attempt to deliver MSDUs 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 acquired PPDU. Thus, old i-slices may still be valuable to a display device because they may be used as a reference for subsequent p-slices (e.g., for decoding successive p-slices). When a rendering device renders a new i-slice or p-slice associated with a previous i-slice, it may not flush the MSDU queue associated with the previous i-slice. For example, a rendering device may continue to attempt to deliver MSDUs 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 the fact that frames Q and Q+1 are i-frames (with one or more p-frames between the i-frames (not shown)), the rendering device may render the first i-slices of frame Q and 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 a video frame) and 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] As mentioned 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 a 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] 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 posture 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 illustrated 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 sufficient time to provide a PPDU including 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 time length. 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 spot at the position of the video slice).

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

[0195] In some implementations, the rendering device instructs the display device that an MSDU queue be flushed. The instruction 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 instruction may indicate which video slice is associated with the MSDU queue (e.g., providing the IP address, port number, and DSCP value used to identify the MSDU queue in the MAC header). Based on the instruction, the display device may terminate storing and processing the MSDU 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 reconstruct an application file (e.g., video slices). The REO queue may retrieve one or more MSDUs from the rendering device. When the display device retrieves an instruction that a transmit queue associated with one or more retrieved MSDUs (e.g., an MSDU queue that contained one or more MSDUs at the rendering device) be flushed, the retrieved MSDUs may no longer be used to generate video slices. In this way, the display device may flush the REO queue after retrieving the instruction.

[0196] 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) are not acquired. For example, the REO queue may acquire a portion of the MSDUs associated with the video slice, but the REO queue may not acquire the remainder of the MSDUs associated with the video slice before the REO timeout occurs. The display device may flush the REO queue after not acquiring the remainder of the MSDUs before the REO timeout occurs. In one example, the length of time for the REO timeout may be the time from when the first MSDU of the application file is acquired to the latest when the last MSDU of the application file should be acquired. In another example, the length of time for the REO timeout may be the time indicating when a video slice of an entire video frame should be acquired. In some implementations, the length of time for the REO timeout may be based on the TWT window size. In some implementations, the length 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 length of time for the REO timeout is 10 ms, although any suitable length of time may be used. The length of time may be counted from the beginning 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 length of time of the REO timeout before it has acquired all MSDUs, the display device may flush the REO queue.

[0197] In some implementations, the display device may periodically flush the REO queue. For example, the display device may flush the REO queue between TWT windows. In some implementations, the display device may 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 may generate a command to flush the REO queue because the acquired MSDUs are no longer needed.

[0198] In contrast to requiring acquisition of all MSDUs of an application file (e.g., 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 or may not be used based on the link quality between the rendering device and the display device (e.g., 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 exceeds 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 resolution of the video frames is greater than a threshold resolution, etc. In some implementations, FEC may or may not be used based on one or more parameters of the display device (such as the channel size, which may affect throughput to 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 attitude frames, or by the rendering device to the display device in the MAC header of one or more PPDUs.

[0199] In some implementations that use FEC per video slice, the display device may indicate to the rendering device when sufficient MSDUs are 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 contained sufficient MSDUs to reconstruct the video slice, the display device may indicate to the rendering device in the BA that a sufficient number of MSDUs are obtained. For example, the aggregated control (A-Control) field of the MAC header of the BA may be configured to indicate that a sufficient number of MSDUs for the video slice are obtained. The rendering device may 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 already obtained MSDUs). The rendering device may flush the associated MSDU queue after obtaining the indication.

[0200] Changes in the wireless medium and the XR experience may require changes in the rendering or display device when communicating data to other devices or when performing one or more XR operations. For example, as the wireless medium becomes more congested, as the display device moves farther away from the rendering device, or as more interference exists on the wireless medium, the rendering and display devices may adjust one or more parameters to reduce the amount of information to be communicated between the devices. Exemplary parameters may be associated with an 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., affecting the bitrate between devices and the success in delivering data between devices for the XR experience). The rendering and display devices may be configured to provide feedback to other devices 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 PPDUs to the display device, and the display device may generate feedback based on sending pose frames to the rendering device.

[0201] 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 a plurality of PPDUs associated with one or more video frames of an XR experience to the second device.

[0202] 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 occurs when a BA is not obtained for a transmitted PPDU. In some implementations, the rendering device may determine that a PPDU transmission drop occurs when the rendering device reaches a maximum number of retries for a PPDU and the rendering device should no longer attempt 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 length of time, or another suitable length 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] The rendering device may determine the PPDU transmission latency based on the BA obtained for the PPDU delivered to the 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 may determine the PPDU transmission latency for the PPDU as being the difference between the time when the PPDU was transmitted and the time when the BA was obtained. In some implementations, the rendering device may determine the average PPDU transmission latency, the median PPDU transmission latency, or the distribution of PPDU transmission latency over a number of PPDU transmissions.

[0204] One or more measurements (including PPDU transmission latency or PPDU transmission drops) 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 drops 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 drops increase. 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 (e.g., reduce 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] The process 1900 illustrated in Figure 19 is from the perspective of a rendering device that generates the feedback. The process 2000 illustrated in Figure 20 may be from the perspective of a display device that generates the feedback.

[0206] 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 the XR experience to the second device. In some implementations, the device also attempts to provide tracking frames to the second device.

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

[0208] The display device may determine a posture data frame transmission latency based on a BA obtained for a posture data frame delivered to a rendering device. For example, the display device tracks the time at which a posture 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 posture data frame is obtained from the rendering device (e.g., based on a WCD clock of the display device). The display device may determine a posture data frame transmission latency for the posture data frame as being the difference between the time at which the posture data frame was transmitted and the time at which the BA was obtained. In some implementations, the display device may determine an average posture data frame transmission latency, a median posture data frame transmission latency, or a distribution of posture data frame transmission latency over a number of posture data frame transmissions.

[0209] Similar to what was described above with reference to FIG. 19 , one or more measurements (including posture data frame transmission latency or posture data frame transmission drop) may be 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 posture data frame transmission latency and posture data frame transmission drop 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) may 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 may implement the one or more adjustment values.

[0210] Referring back to the rendering device, the rendering device may acquire one or more posture data frames from the display device (each of the one or more video frames is associated with a posture data frame). The one or more measurements may include measurements based on the acquired posture data frames. In some implementations, the rendering device may measure a posture data frame delivery latency associated with acquiring one or more posture data frames. For example, using a known TWT window start time and a posture data frame that should be delivered at the beginning of the TWT window, the rendering device may determine the difference between the TWT window start time and the time at which the posture data frame is 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 posture data frame (such as the time indicated by the application layer clock of the display device). Because the WCD clock of the rendering device and the application layer clock of the display device may be synchronized, the rendering device may determine the difference between the time of the IMU measurement and the time at which the posture data frame is acquired. The rendering device may determine the average posture data frame delivery latency, the median posture data frame delivery latency, or the distribution of posture data frame delivery latency over a certain number of posture data frame deliveries (such as over a defined number of TWT windows or a defined length of time).

[0211] The one or more measurements by the rendering device may include a frequency of missing or delayed posture data frames. In some implementations, the rendering device determines whether one or more posture data frames are missing or delayed. For example, the display device may attempt to provide a posture data frame at the beginning of each TWT window until a timeout. If the rendering device does not obtain a posture data frame before the timeout, the rendering device may determine that the posture data frame is missing or delayed. The rendering device may count the number of missing or delayed posture data frames over 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 posture data frames is increasing. If the number decreases as successive TWT windows occur, the rendering device determines that the frequency of missing or delayed posture data frames is decreasing. In some implementations, the frequency may be the number of missing or delayed posture data frames divided by the determined number of TWT windows used in determining whether any posture data frames are missing or delayed.

[0212] Referring back to the display device, the REO queue of the display device may retrieve one or more MSDUs from the rendering device. As noted above, each MSDU may be associated with an application file (e.g., a video slice). The display device may flush the REO queue one or more times to remove one or more MSDUs from the REO queue. For example, the display device may flush the REO queue based on receiving an indication that a transmit queue at the rendering device (e.g., an MSDU queue at the rendering device associated with an MSDU in the REO queue of the display device) has been flushed. In another example, the display device may flush the REO queue periodically (e.g., between TWT windows). In another example, the display device may flush the REO queue when a timeout occurs (e.g., not all MSDUs or a sufficient number of MSDUs are received within a defined length of time to allow construction of a video slice for display). In another example, the display device may 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 may flush the REO queue based on a command from the 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 over a defined length 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] 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) the 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 the 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 the time when the first MSDU is obtained and the time when the last MSDU is obtained from the WCD clock of the display device. The display device may determine the difference between when the first MSDU is obtained and when the last MSDU is obtained as the video frame delivery latency for the video frame. In some implementations, the display device may determine the mean delivery latency, the median delivery latency, or the distribution of delivery latency for a number of video frame delivery latencies.

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

[0215] 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 the video frames to be displayed. As mentioned 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 missing data) and overflows (resulting in too much data that some data may leak 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 measure, over a defined length of time associated with the jitter buffer.

[0216] The missing packets associated with a video frame to be displayed may include missing video slices. The display device may display one or more video frames that are missing one or more video slices. In some implementations, the one or more measurements include a count of the number of displayed video frames that are missing one or more video slices, the number of missing video slices, or another suitable measure of missing packets over a defined length of time.

[0217] For 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 measures indicative of the link quality between the devices. A change in the link quality measure may indicate deteriorating or improving channel conditions.

[0218] 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 or display device may 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 and display devices. 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, where the duty cycle may be the length of the TWT window compared to the length 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 the rendering and display devices communicate. - 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] 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 video quality and video compression. 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] 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 (such as when a link to the rendering device is determined to be poor (e.g., the 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 will 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 through 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] A display or rendering device may indicate to other devices one or more measurements or adjustments made to one or more parameters of the XR experience. In some implementations, a device may 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 for asynchronous channel access, etc.), a data frame (such as one or more PPDUs from the rendering device to the display device, or one or more attitude 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 an attitude data frame). An exemplary A-Control field may be a variation of the HT control field (HE A-Control field) defined in 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] 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 for use.

[0223] In some implementations, an A-Control field (such as subfield 2102) includes a spare 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 spare 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] In some implementations, an A-Control field (such as subfield 2102) includes a spare 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 spare 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 adjustment values.

[0225] 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 discussed above). In some implementations, the link quality may be indicated in binary form as good or poor. 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 reserved bits to indicate link quality (such as 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] In this manner, the display device and the rendering device may 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 in relation to an XR experience, the operations for measuring and providing feedback described above may be applied to other types of data and other types of uses.

[0227] 1B , device 154 may 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] Simultaneous links may be managed using a TWT session (as described above, the AP or other STA communicates outside the TWT window for the display and rendering devices). For legacy devices that do not support TWT, simultaneous links may be supported using multi-link operation (MLO) techniques (such as those defined in the IEEE 802.11 standard).

[0229] 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 another suitable device.

[0230] 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] At 2204, the rendering device communicates with the second device via a second wireless link. For example, the rendering device may communicate with the 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 (also referred to as TWT) technique may include the operations described above with reference to synchronous channel access, application-based data management, and feedback generation. The MLO technique may be similar to some TWT mode techniques, but may be supported by legacy devices that do not support TWT.

[0232] The WCD is configured to prioritize communications on the second wireless link over communications on the first wireless link (2208). For example, the second wireless link may be a link 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, pose 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 attempting to send traffic classified as best effort to other devices). Exemplary operations for a WCD to prioritize communications on the second wireless link over communications on the first wireless link are described in further detail below.

[0233] Simultaneously communicating with a first device (such as an AP) and a second device (such as a display device) may include: The WCD will transmit to a second device during reception of one or more packets from a first device (eg, transmitting to a display device while receiving from an AP). The WCD will 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 will transmit to a second device while transmitting to a first device (e.g., transmitting to a display device while transmitting to an AP), or The WCD will 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] 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 prevents 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 prevents transmission to a first device over a first wireless link when receiving from a second device over the second wireless link. Typical MLO techniques may prevent communications 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 communications with the display device. For example, a WCD may allow transmission to a display device while receiving from another device (such as an AP or STA). In some implementations, a WCD may be configured to ignore CCA when the WCD is to transmit to a display device. Exemplary adjustments to MLO techniques for different exemplary simultaneous communications are described below.

[0235] 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., transmit one or more PPDUs associated with one or more video frames). The WCD may transmit to the second device before completing reception of one or more packets from the first device. The examples described herein refer to the WCD or the device managing the simultaneous link as a rendering device, the second device as a display device, and the first device as an AP, solely for the sake of brevity and clarity of description of aspects of the present disclosure. Note that the examples are not limited to a rendering device, a display device, an AP, or any other particular device.

[0236] A rendering device typically provides a BA to the AP after retrieving one or more packets over a first wireless link. If a transmission over a second wireless link to a display device is still in progress when the rendering device should provide a BA to the AP, CCA indicates that the wireless medium is busy, preventing the rendering device from 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, CCA at the rendering device does not prevent 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 have been 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] In some implementations extending MLO, a rendering device (such as a WCD) prevents providing a BA to the AP to acknowledge receipt of one or more packets. In this way, a BA obtained from the display device does not interfere with a BA to the AP. For example, the rendering device may determine whether the WCD is in a transmit mode for the 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 is prevented from 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 unsuccessful. If the AP does not obtain a BA from the rendering device, the AP may later attempt to send the one or more packets to the rendering device again (with increased latency for delivering the one or more packets from the AP). Increasing the latency on the first wireless link relative to 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] Another exemplary concurrent 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 via a first wireless link at the same time that an attitude data frame, a tracking frame, or other packet is provided by the display device via a second wireless link. The rendering device obtains one or more packets from the display device during reception of 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 may prevent providing a BA to the AP to acknowledge receipt of one or more packets from the AP. For example, transmission on a first antenna or antennas via the first wireless link may cause localized interference on a second antenna or antennas receiving via the second wireless link. Preventing transmission of a BA to the AP prevents localized interference in reception from the display device.

[0239] 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 the 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, typical MLO techniques require the rendering device to determine a CCA (indicating that the wireless medium is busy). In this manner, the rendering device delays transmission to the display device (increasing latency over the second wireless link). One or more extensions to MLO techniques may be applied to attempt to avoid or reduce such delays in transmission to the display device.

[0240] In one exemplary enhancement to the MLO technique, the rendering device synchronizes transmissions to the display device with transmissions to the AP. For example, the start of transmissions to the AP may be synchronized with the start of transmissions to the display device. Synchronizing the start of transmissions 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 time length 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 length of time at which an MSDU should be transmitted to the display device. If so, the rendering device may delay transmissions to the AP to synchronize transmissions 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 the display device, the rendering device may reduce the BO associated with the second wireless link to synchronize transmissions over the first wireless link with transmissions over the second wireless link.

[0241] The transmission to the display device may be shorter than the transmission to the AP. If the transmission to the display device finishes first, a 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 pad the transmission to the display device so that the end of the transmission to the AP is synchronized with the end of the transmission to the display device. Exemplary padding may include zero padding or adding any suitable tail to synchronize the end of the transmission or to the transmission to the display device. 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 throughput measured on 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 so that latency on the second wireless link is not affected.

[0242] In another exemplary extension to the MLO technique, a rendering device may prevent transmissions to an AP outside 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 the 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 the window length, period, and other parameters of 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 the display device (outside the TDM window) is based on the remaining length of the current TDM window.

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

[0244] In another exemplary enhancement to the MLO technique, the rendering device may suspend transmission to the AP so that the rendering device does not further transmit 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 may 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 may indicate that the wireless medium is free for the rendering device to transmit to the display device over the second wireless link.

[0245] Another exemplary extension to the MLO technique may use a CTS-to-Self frame to extend a reservation period of the wireless medium for transmitting to the display device. For example, when a rendering device transmits to an 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). When the reservation period expires, other devices may contend for the wireless medium or be scheduled to transmit over the wireless medium, and the rendering device may wait for the other devices to finish occupying the wireless medium. In some implementations, when the rendering device has an MSDU ready to transmit to the display device, the rendering device determines a length 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 a length 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 may determine whether time remains from the reservation period based on the amount of time remaining to transmit to the AP, and may determine the amount of time to add to the reservation period to allow it to transmit an MSDU to the display device during the same reservation period. In this way, transmissions to the AP and to the display device may occur during the same reservation period (which reduces delay compared to requiring a new reservation period for transmissions to the display device). To extend the reservation period for the wireless medium, the rendering device may broadcast a CTS-to-Self frame. The CTS-to-Self frame may indicate padding for the period during which the wireless medium is 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 padded period is a period long enough to include transmissions to the AP and the display device.

[0246] 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 posture 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 increase the probability that the packet is delivered. For example, the display device may increase the MCS, use FEC, and reduce the transmission rate. The transmission rate may continue to be reduced, causing problems in meeting latency requirements for the XR experience.

[0247] The MLO technique may be extended to avoid or reduce transmission delays or to prevent adjustments of 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] In another exemplary enhancement to the MLO technique, the rendering device may reduce the maximum PPDU length or burst length. As discussed above, reducing the maximum PPDU length or burst length reduces the length of time that the rendering device transmits to the AP. In this way, the length of time that 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] In another example enhancement to the MLO technique, the rendering device may indicate to the display device that the wireless medium will be busy for a length of time associated with transmitting to the AP. For example, the rendering device may provide a frame to the display device indicating a NAV value to reserve the wireless medium for the length of time for transmitting to the AP. In some implementations, the NAV value may be included in a PPDU transmitted from the rendering device to the display device. In this manner, the display device may set its NAV to the indicated NAV value to prevent transmission to the rendering device for the indicated length of time.

[0250] Although the use of TDM windowing and other MLO techniques has been described in connection with 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 a particular simultaneous link support implementation.

[0251] In addition to or instead of using MLO techniques to support simultaneous links, a rendering device may use TWT to support simultaneous links. In some implementations, a rendering device (or display device) may configure a first TWT session with a display device for communication with the display device over a second wireless link, and the rendering device may 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 acquiring one or more posture 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 between the first plurality of TWT windows and the TWT window, and not 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] 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 may 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 a primary TWT session, and the second TWT session may be considered a secondary TWT session. As noted above, the AP may be an IEEE 802.11ax-enabled AP to support TWT (including the second TWT session with the rendering device).

[0253] As discussed 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 independently of the second TWT session. In this manner, a first TWT session that would cause a conflict with the second TWT session (e.g., overlapping TWT windows from two TWT sessions) may be adjusted. 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] When configuring or coordinating a TWT session, the rendering device may act as a STA to the AP and as a SAP to the display device. In this manner, the rendering device may be conceptualized as having an STA-associated MAC and an SAP-associated MAC supported by the rendering device's WCD. The SAP-associated MAC is used when configuring and coordinating a first TWT session with the display device, and the STA-associated MAC is used when configuring and coordinating a second TWT session with the AP. If the first TWT session is the primary TWT session, after configuring or coordinating 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 the information or changes to the first TWT session in the STA-associated MAC, the rendering device may negotiate with the AP to configure or coordinate a second TWT session. In some implementations, the AP may have unique TWT requirements (e.g., based on supporting other devices in the BSS). The rendering device may 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] 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] 23 shows a sequence diagram 2300 illustrating example timing of XR activity (referred to as wireless activity) and wireless activity with an AP. A first XR activity 2302 (e.g., from receiving a posture 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 posture 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 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 window corresponding to XR activity 2302 and the TWT window corresponding to XR activity 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 the second TWT session. Start time 2314 may be more than a buffer 2318 after XR activity 2302. For example, as discussed 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 length of time of XR activity 2302 may vary. Buffer 2318 may be a defined length of time to account for variations in the length of time of XR activity (including XR activity 2302). As shown, the start time 2314 is after the buffer 2318 .

[0257] The start time 2314 may also be scheduled to take into account 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 out of low power mode. R and the duration of the XR activity (such as the duration of XR activity 2302) is A R where the buffer time length is z, the typical wireless activity start time is y, and the TWT wake-up interval (e.g., the TWT window interval 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 shown in equations (1) to (3) below.

number

[0258] In this way, the start time 2304 is x+n for any cycle of XR activity. R P R and the start time 2308 may be 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 R The start time 2314 may be y+n W P W and the end time 2316 is y+n W P W +A W P Wis P R When TWT is used for communication 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.).

[0259] The rendering device may use a TDM window that is not defined in the 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 use the varying P R For example, a rendering device may schedule wireless activity during a TWT window similar to that described above, based on possible delays or variations in XR activity. R In this way, it is ensured that wireless activity 2312 does not overlap with any of the XR activities (including XR activities 2302 and 2306).

[0260] 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 capable of indicating values ​​with greater fidelity (also called granularity) than the WCD clock. The difference in fidelity is expressed as P R P W This can also be caused by the fact that the P R may be expressed as the time per cycle of a certain number of XR activities (e.g., 50 ms per 3 cycles). However, (P R (equal to)P Wmay be determined for each cycle of wireless activity. For example, P R is 50ms per 3 cycles (which is 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 period of wireless activity 2312 differs from the period of XR activity 2310 (such as up to 1 μs per cycle in the example). W is determined to be 16.666 ms, and P R In an example where P is 50 / 3 ms, wireless activity shifts 3.88 ms every 194 seconds relative to XR activity. W , which is configured to account for 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 start to overlap with previous XR activity after 194 seconds.

[0261] 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 mentioned 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. Furthermore, the crystals may be affected differently by environmental conditions (such as temperature or humidity) that change the resonant frequencies. Although the device may assume the resonant frequencies are the same, wireless activity may drift over time with respect to XR activity based on the difference in resonant frequencies. In an example where the difference in resonant frequencies is 20 cycles per million crystal cycles between the application layer clock and the WCD clock (the crystal associated with the WCD clock has a higher resonant frequency), 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 previous XR activity after 194 seconds.

[0262] One or both of the TWT sessions may be adjusted based on the 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.

[0263] Adjustments to the second TWT session may be made at defined time intervals based on the measured drift. For example, if the drift is P W If the approximation is based on the value of P, the rendering device may determine the interval at which to adjust the second TWT session based on the approximation error and the size of the buffer. W is approximated to 16.666ms, and P R In the above example where the difference in resonant frequencies is 50 / 3 ms and the buffer is 3.88 ms, the rendering device may determine the interval defined as being less than 194 seconds. In the above example where the difference in resonant frequencies is 20 cycles per million cycles and the buffer is 3.88 ms, the rendering device may determine the interval defined as being less than 194 ms. In some implementations, the defined interval may be based on both types of drift (e.g., based on the feature causing the largest drift between the two).

[0264] In addition to, or instead of, adjusting the second TWT session based on the determined time interval associated with the drift, the rendering device may attempt to determine whether the XR activity and the wireless activity begin to overlap. For example, the rendering device may provide a schedule, or the WCD may otherwise estimate when the XR activity should occur (such as the interval when transmitting or receiving over the second wireless link), and the WCD may periodically determine whether the wireless activity will 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.

[0265] As mentioned above, aspects of the present disclosure include a wireless system for giving priority to communications between two devices over other devices while still sharing the wireless medium with the other devices. Priority may be given to communications between a rendering device and a display device of an XR experience that meets latency and packet loss requirements. In some implementations, priority may be given via asynchronous channel control operations. In some implementations, priority may be given via synchronous channel control operations. Sharing of the wireless medium may be through the use of TWT sessions (e.g., for simultaneous link support) or MLO techniques. Aspects of the present disclosure also include generating and providing feedback associated with an XR experience between the rendering device and the display device. Communications between devices (e.g., between a rendering device and a display device or between 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.

[0266] Example implementations are described in the following numbered clauses. 1. A method performed by a wireless communication device for an extended reality (XR) experience, comprising: obtaining control of the 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 of transmitting data from the second device to the wireless communication device over the wireless medium; Steps and providing the first PPDU to a second device; and providing one or more subsequent PPDUs of the application file to the second device, wherein the step of providing the one or more subsequent PPDUs is associated with a third priority of transmitting the one or more subsequent PPDUs over the wireless medium. 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; 10. The method of claim 1, wherein a third priority is associated with a third set of EDCA parameters. 3. The ECDA parameters are arbitration interframe spacing number (AIFSN), Minimum Contention Window (CWmin), or Maximum Contention Window (CWmax) one or more of the methods of clauses 1 to 2, including one or more of the following: 4. Associating the first priority with a first backoff counter value, the first backoff counter value being used by a backoff counter of the wireless communication device to contend for the wireless medium for the first PPDU; the second priority is associated with a second backoff counter value greater than the first backoff counter value; 3. The method of claim 1, wherein the third priority is associated with a third backoff counter value that is greater than the second backoff counter value, and the third backoff counter value is used by a backoff counter of the wireless communication device to contend for the wireless medium for one or more subsequent PPDUs. 5. The method of one or more of clauses 1 to 2 or 4, wherein the first backoff counter value is 0 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); OBSS devices compete for the wireless medium to transmit data classified as high importance, which is associated with a fourth priority; 3. The method of one or more of clauses 1 to 2, wherein the wireless communication device or the second device obtains control of the wireless medium based on a first priority or a second priority. 7. The wireless communication devices contend for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Prevents a second device from competing for the wireless medium, One or more of the methods of clauses 1 to 2 or 6, in which the OBSS device obtains control of the wireless medium based on a fourth priority. 8. Providing a first request to send (RTS) frame to acquire control of the wireless medium, the first RTS frame including a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time, the first period of time being greater than a first transmission opportunity (TXOP) during which a 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 period; the second RTS frame includes a NAV instruction to extend the first period to cover multiple TXOPs; 3. The method of claim 1 or 2, wherein providing the first PPDU is after obtaining the first CTS frame and during the first TXOP. 9. The method of one or more of clauses 1 to 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 to 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 step comprising: 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, Steps and preventing providing another RTS frame to extend the first period after providing the last MSDU to the second device; and releasing control of the wireless medium at the end of the first period. 12. The method of one or more of clauses 1 to 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 comprising obtaining control of the wireless medium to provide one or more PPDUs of the second application file to the second 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; 12. The method of one or more of clauses 1 to 2, 8, or 11, wherein gaining control of the wireless medium is associated with a first set of EDCA parameters. 14. The method of one or more of clauses 1 to 2, 8, 11, or 13, wherein the wireless communications device enables RTS / CTS signaling for the first PPDU for each 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); 15. The method of one or more of clauses 1 to 14, wherein the application file is associated with a video frame to be displayed by the HMD. 16. A wireless communication device configured for an extended reality (XR) experience, comprising: a processing system; Gain control of the 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 the second priority of transmitting data from the second device to the wireless communication device over the wireless medium; providing the first PPDU to a second device; Providing one or more subsequent PPDUs of the application file to the second device and an interface configured to provide one or more subsequent PPDUs, wherein providing one or more subsequent PPDUs is associated with a third priority of transmitting the one or more subsequent PPDUs over the wireless medium. 17. 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; 17. The wireless communications device of clause 16, wherein a third priority is associated with a third set of EDCA parameters. 18. ECDA parameters are arbitration interframe spacing number (AIFSN), Minimum Contention Window (CWmin), or Maximum Contention Window (CWmax) one or more wireless communications devices of clauses 16 to 17, including one or more of: 19. The first priority is associated with a first backoff counter value, the first backoff counter value being used by a backoff counter of the wireless communication device to contend for the wireless medium for the first PPDU; the second priority is associated with a second backoff counter value greater than the first backoff counter value; 18. The one or more wireless communications devices of clauses 16 to 17, wherein a third priority is associated with a third backoff counter value greater than the second backoff counter value, the third backoff counter value being used by a backoff counter of the wireless communications device to contend for the wireless medium for one or more subsequent PPDUs. 20. The wireless communications device or devices of clauses 16-17 or 19, wherein the first backoff counter value is 0 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); OBSS devices compete for the wireless medium to transmit data classified as high importance, which is associated with a fourth priority; One or more wireless communications devices of clauses 16 to 17, wherein the wireless communications device or the second device obtains control of the wireless medium based on the first priority or the second priority. 22. The wireless communication devices contend for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Prevents a second device from competing for the wireless medium, One or more wireless communications devices of clauses 16 to 17 or 21 from which the OBSS device obtains control of the wireless medium on the basis of fourth priority. 23. The interface is further providing a first request to send (RTS) frame to acquire control of the wireless medium, the first RTS frame including a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time, the first period of time being greater than a first transmission opportunity (TXOP) during which the first PPDU is provided; Obtaining the first clear to send (CTS) frame from the second device after providing the first RTS frame; configured to provide a second RTS frame after the first TXOP and before an end of the first period; the second RTS frame includes a NAV instruction to extend the first period to cover multiple TXOPs; 18. The one or more wireless communications devices of clauses 16 to 17, wherein providing the first PPDU is subsequent to obtaining the first CTS frame and during the first TXOP. 24. One or more wireless communications devices 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 further providing the last PPDU of the application file to the second device; 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; preventing the second device from providing another RTS frame to extend the first period after providing the last MSDU to the second device; One or more wireless communications devices of clauses 16 to 17 or 23 configured to release control of the wireless medium at the end of the first period. 27. One or more wireless communications devices of clauses 16 to 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; 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; 27. One or more wireless communications devices of clauses 16-17, 23, or 26, wherein obtaining control of the wireless medium is associated with a first set of EDCA parameters. 29. The wireless communications device of one or more of clauses 16 to 17, 23, 26, or 28, wherein the wireless communications device enables RTS / CTS signaling for the first PPDU for each 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); 30. The one or more wireless communications devices of clauses 16 to 29, wherein the application file is associated with a video frame to be displayed by the HMD. 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 over a wireless medium; A second device gains control of the wireless medium; 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 the second priority of transmitting data from the wireless communication device to the second device over the wireless medium; Steps and and 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 of transmitting the one or more subsequent PPDUs over the wireless medium. 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; 32. The method of claim 31, wherein a third priority is associated with a third set of EDCA parameters. 33. ECDA parameters are arbitration interframe spacing number (AIFSN), Minimum Contention Window (CWmin), or Maximum Contention Window (CWmax) one or more of the methods of clauses 31 to 32, including one or more of: 34. A first priority is associated with a first backoff counter value; the second priority is associated with a second back-off counter value greater than the first back-off counter value, the second back-off counter value being used by a back-off counter of the wireless communication device in determining when to provide data to the AP; 33. The method of one or more of clauses 31-32, wherein the third priority is associated with a third backoff counter value greater than the second backoff counter value. 35. The method of one or more of clauses 31-32 or 34, wherein the first backoff counter value is 0 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); OBSS devices compete for the wireless medium to transmit data classified as high importance, which is associated with a fourth priority; 33. The method of one or more of clauses 31 to 32, wherein the wireless communications device or the second device obtains control of the wireless medium based on the first priority or the second priority. 37. A second device contends for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Prevent wireless communication devices from competing for the wireless medium; One or more of the methods of clauses 31 to 32 or 36, in which the OBSS device obtains control of the wireless medium based on a fourth priority. 38. Obtaining a first request to send (RTS) frame from an AP, the first RTS frame including a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time, the first period of time being greater than a first transmission 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 the end of the first period; the second RTS frame includes a NAV instruction to extend the first period to cover multiple TXOPs; 33. The method or methods of clauses 31 to 32, wherein obtaining the first PPDU is after providing the first CTS frame and during the first TXOP. 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 communications device. 40. The method of one or more of clauses 31-32 or 38, further comprising providing data to the second device after the first TXOP and before obtaining the second RTS frame. 41. The method further includes 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; preventing the second device from providing another RTS frame to extend the first period after providing a last MSDU to the wireless communication device; The method of one or more of clauses 31 to 32 or 38, wherein the second device releases control of the wireless medium at the end of the first period. 42. The method of one or more of clauses 31-32, 38, or 41, further comprising the step of obtaining a contention free (CF) end beacon from the second device after obtaining the last MSDU, the CF end beacon being 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; 42. The method of one or more of clauses 31-32, 38, or 41, wherein obtaining control of the wireless medium by the second device is associated with a first set of EDCA parameters. 44. The second device includes a software-enabled AP (SAP); The wireless communication device is included in a head-mounted display (HMD), 44. The method of one or more of clauses 31 to 43, wherein the application file is associated with a video frame to be displayed by the HMD. 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 over a wireless medium; A second device gains control of the wireless medium; 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 the second priority of transmitting data from the wireless communication device to the second device over the wireless medium; Retrieves one or more subsequent PPDUs of the application file from the AP and an interface configured to: 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; 46. ​​The wireless communications device of clause 45, wherein a third priority is associated with a third set of EDCA parameters. 47. ECDA parameters are arbitration interframe spacing number (AIFSN), Minimum Contention Window (CWmin), or Maximum Contention Window (CWmax) one or more wireless communications devices of clauses 45 to 46, including one or more of: 48. A first priority is associated with a first backoff counter value; the second priority is associated with a second back-off counter value greater than the first back-off counter value, the second back-off counter value being used by a back-off counter of the wireless communication device in determining when to provide data to the AP; 47. The one or more wireless communications devices of clauses 45-46, wherein the third priority is associated with a third backoff counter value greater than the second backoff counter value. 49. The wireless communications device or devices of clauses 45-46 or 48, wherein the first backoff counter value is 0 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); OBSS devices compete for the wireless medium to transmit data classified as high importance, which is associated with a fourth priority; One or more wireless communications devices of clauses 45 to 46, wherein the wireless communications device or the second device obtains control of the wireless medium based on the first priority or the second priority. 51. A second device contends for the wireless medium to transmit one or more subsequent PPDUs associated with a third priority; Prevent wireless communication devices from competing for the wireless medium; One or more wireless communications devices of clauses 45 to 46 or 50, from which the OBSS device obtains control of the wireless medium on the basis of fourth priority. 52. The interface is further obtaining a first request to send (RTS) frame from the AP, the first RTS frame including a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time, the first period of time being 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 receiving the first RTS frame; configured to obtain a second RTS frame from the AP after the first TXOP and before an end of the first period; the second RTS frame includes a NAV instruction to extend the first period to cover multiple TXOPs; 47. The one or more wireless communications devices of clauses 45 to 46, wherein obtaining the first PPDU is subsequent to providing the first CTS frame and during the first TXOP. 53. One or more wireless communications devices 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 one or more wireless communications devices 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 further configured to retrieve 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; preventing the second device from providing another RTS frame to extend the first period after providing a last MSDU to the wireless communication device; One or more wireless communications devices of clauses 45 to 46 or 52, wherein the second device releases control of the wireless medium at the end of the first period. 56. One or more wireless communications devices of clauses 45 to 46, 52, or 55, wherein the interface is further configured to receive a contention free (CF) end beacon from the second device after receiving the last MSDU, the CF end beacon being 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; 56. One or more wireless communications devices of clauses 45-46, 52, or 55, wherein obtaining control of the wireless medium by the second device is associated with a first set of EDCA parameters. 58. The second device includes a software-enabled AP (SAP); The wireless communication device is included in a head-mounted display (HMD), 58. The one or more wireless communications devices of clauses 45 to 57, wherein the application file is associated with a video frame to be displayed by the HMD. 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; 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) A method associated with one of the following: 60. Further comprising the step of 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 includes attitude data frames, The rendering of the video frames is associated with the acquired pose data frames; a first one of the video frames includes a plurality of slices; the rendering of the first video frame is associated with a most recently acquired first frame of pose data from the second device; 59. The method of claim 59, wherein one or more PPDUs are associated with one or more of the plurality of slices. 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; and providing, to the second device, a PPDU associated with a video slice of the first video frame after the current TWT window and before the next TWT window. 62. The method of one or more of clauses 59-60, wherein the start of the current TWT window is further associated with a motion to render (M2R) latency of the first video frame. 63. Further comprising the step of synchronizing an application layer clock of the device with a wireless communication device (WCD) clock; The application layer clock is used by the device to time the rendering of video frames, 63. The method of one or more of clauses 59-60 or 62, wherein the WCD clock is used by the device for timing of wireless communications with a second device. 64. A pose data frame is acquired at a first frequency, 64. The method of one or more of clauses 59-60, 62, or 63, wherein video frames are rendered at a first frequency and each acquired frame of pose data is associated with a rendered video frame. 65. The method of one or more of clauses 59-60, 62, or 63, wherein synchronizing the WCD clock with the device's application layer clock includes synchronizing the WCD clock with the application layer clock. 66. The step of synchronizing a WCD clock to an application layer clock comprises: 66. The method of one or more of clauses 59-60, 62, 63, or 65, comprising aligning a start point of a current TWT window to a first time before a rendering time for beginning to render a first video frame, the first time being before the rendering time by a first offset, the first offset being associated with M2R latency. 67. The method of one or more of clauses 59-60, 62, 63, 65, or 66, further comprising obtaining a first attitude data frame at a start of a current TWT window. 68. Acquiring additional attitude data frames during the current TWT window; and rendering at least a portion of the second video frame during the next TWT window; the second video frame is associated with an additional frame of pose data; The method of one or more of clauses 59-60, 62, 63, or 65-67, wherein the additional pose data frame is a pose data frame most recently acquired prior to rendering the second video frame. 69. The method of one or more of clauses 59-60, 62, or 63, wherein synchronizing the application layer clock and the WCD clock of the device 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. The step of synchronizing an application layer clock to a WCD clock comprises: 69. The method of one or more of clauses 59-60, 62, 63, or 69, comprising aligning a rendering time for starting rendering a first video frame to a first time after a start of a current TWT window, the first time being after the start of the current TWT window by a first offset, the first offset being associated with an M2R latency. 71. The method of one or more of clauses 59-60, 62, or 63, further comprising 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 since the last synchronization of the application layer clock and the WCD clock being greater than a drift threshold. 72. The device includes a software-enabled AP (SAP), 72. The method of one or more of clauses 59 to 71, wherein the second device includes a head mounted display (HMD) for displaying the video frames. 73. A device configured for an extended reality (XR) experience, comprising: a processing system; receiving uplink (UL) data from a second device over a wireless medium; Providing downlink (DL) data including physical layer protocol data units (PPDUs) over a wireless medium to a second device and an interface configured to 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) A device associated with one of the 74. A processing system configured to render video frames to be displayed by a second device; the device includes a rendering device, the second device includes a display device; UL data includes attitude data frames, The rendering of the video frames is associated with the acquired pose data frames; a first one of the video frames includes a plurality of slices; the rendering of the first video frame is associated with a most recently acquired first frame of pose data from the second device; A Clause 73 device in which one or more PPDUs are associated with one or more of a plurality of slices. 75. The interface is further providing, to 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 the current TWT window; The one or more devices of clauses 73 to 74, configured to provide, to 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. 76. The device or devices of clauses 73-74, wherein the start of the current TWT window is further associated with a motion to render (M2R) latency of 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; Used by the device for timing when application layer blocks render video frames, 77. One or more devices of clauses 73-74 or 76, wherein the WCD clock is used by the device for timing of wireless communications with a second device. 78. A pose data frame is acquired at a first frequency; The device of one or more of clauses 73 to 74, 76, or 77, wherein video frames are rendered at a first frequency and each acquired frame of pose data is associated with a rendered video frame. 79. One or more devices of clauses 73 to 74, 76, or 77, wherein synchronizing the WCD clock with the device's application layer clock includes synchronizing the WCD clock to the application layer clock. 80. Synchronizing a WCD clock to an application layer clock 80. The device of one or more of clauses 73 to 74, 76, 77, or 79, including aligning a start point of a current TWT window to a first time before a rendering time for beginning to render a first video frame, the first time being before the rendering time by a first offset, the first offset being associated with M2R latency. 81. The device or devices of clauses 73-74, 76, 77, 79, or 80, wherein the interface is further configured to acquire a first attitude data frame at a start of a current TWT window. 82. The interface is further configured to acquire additional attitude data frames during the current TWT window; the processing system is further configured to render at least a portion of the second video frame during a next TWT window; the second video frame is associated with an additional frame of pose data; The device of one or more of clauses 73-74, 76, 77, or 79-81, wherein the additional pose data frame is a pose data frame most recently acquired prior to rendering the second video frame. 83. One or more devices of clauses 73 to 74, 76, or 77, wherein synchronizing the device's application layer clock and 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 84. The device of one or more of clauses 73 to 74, 76, 77, or 83, including aligning a rendering time for starting to render a first video frame to a first time after a start of a current TWT window, the first time being after the start of the current TWT window by a first offset, the first offset being associated with an M2R latency. 85. One or more devices of clauses 73 to 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 since the last synchronization of the application layer clock with the WCD clock being greater than a drift threshold. 86. The device includes a software-enabled AP (SAP); One or more devices of clauses 73 to 85, wherein the second device includes a head mounted display (HMD) for displaying the video frames. 87. A method performed by a device for an extended reality (XR) experience, comprising: providing uplink (UL) data over a wireless medium to a second device; and receiving downlink (DL) data from the second device over a wireless medium, the DL data including a physical layer protocol data unit (PPDU); 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 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 second device to the medium access control layer (MAC). A method associated with one of the following: 88. A second device will render video frames to be displayed by the device; the second device includes a rendering device; the device includes a display device; UL data includes attitude data frames, 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 slices; the rendering of the first video frame is associated with a first frame of pose data most recently acquired by the second device; 87. The method of claim 87, wherein one or more PPDUs are associated with one or more of the plurality of slices. 89. Obtaining a packet from 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; and obtaining, from the second device, a PPDU associated with a video slice of the first video frame after the current TWT window and before the next TWT window. 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 of the first video frame. 91. Further comprising the step of synchronizing the WCD clock with the device's application layer clock; The application layer clock is used by the device for timing the display of video frames, The method of one or more of clauses 87-88 or 90, wherein the WCD clock is used by the device for timing of wireless communications with a second device. 92. A pose data frame is provided at a first frequency; 92. The method of one or more of clauses 87-88, 90, or 91, wherein video frames are rendered by a second device at a first frequency, and each pose data frame acquired by the second device is associated with the rendered video frame. 93. The method of one or more of clauses 87-88, 90, or 91, wherein synchronizing the WCD clock with the device's application layer clock includes synchronizing the WCD clock with the application layer clock. 94. The step of synchronizing a WCD clock to an application layer clock comprises: aligning a start of a current TWT window to a first time at which first attitude data is provided to the second device; the first time is before a rendering time at which the second device should begin rendering the first video frame; the first time is before the render time by a first offset; The method of one or more of clauses 87-88, 90, 91, or 93, wherein the first offset is associated with M2R latency. 95. The second device acquiring a first attitude data frame at the beginning of the current TWT window; or A timeout from the start of the current TWT window occurs before an attitude data frame is acquired. 94. The method of claim 87, 88, 90, 91, or 93, wherein the method begins rendering the first video frame when one of the following occurs: 96. Further comprising the step of indicating to the second device the time of the start of the current TWT window; 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, and the WCD clock synchronization is associated with the TSF of the device and the TSF in the MAC of the second device; The method of one or more of clauses 87-88, 90, 91, or 93, wherein the application layer clock of the second device is synchronized to the WCD clock of the AP, and 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. 97. The method of one or more of clauses 87-88, 90, or 91, wherein synchronizing the application layer clock and the WCD clock of the device 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. 98. The step of synchronizing an application layer clock to a WCD clock comprises: The method of one or more of clauses 87-88, 90, 91, or 97, including aligning the display time to a time associated with the current TWT window. 99. The method of one or more of clauses 87-88, 90, or 91, further comprising 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 since the last synchronization of the application layer clock and the WCD clock being greater than a drift threshold. 100. A second device includes a software-enabled AP (SAP); The method of one or more of clauses 87 to 99, wherein the device includes a head-mounted display (HMD) for displaying the video frames. 101. A device configured for an extended reality (XR) experience, comprising: a processing system; providing uplink (UL) data over a wireless medium to a second device; Obtain downlink (DL) data including physical layer protocol data units (PPDUs) over a wireless medium from a second device. and an interface configured to 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 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) A device associated with one of the 102. A second device renders video frames to be displayed by the device; the second device includes a rendering device; the device includes a display device; UL data includes attitude data frames, 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 slices; the rendering of the first video frame is associated with a first frame of pose data most recently acquired by the second device; A device of Clause 101, wherein one or more PPDUs are associated with one or more of a plurality of slices. 103. The interface is further receiving, 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; The one or more devices of clauses 101 to 102, configured to obtain, from the 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. 104. The one or more devices of clauses 101-102, wherein the start of the current TWT window is further associated with a motion to render (M2R) latency of the first video frame. 105. A device is configured to synchronize an application layer clock of the device with a WCD clock; The application layer clock is used by the device for timing the display of video frames, One or more devices of clauses 101-102 or 104, wherein the WCD clock is used by the device for timing of wireless communications with a second device. 106. A posture data frame is provided at a first frequency; One or more devices of clauses 101 to 102, 104, or 105, wherein video frames are rendered by the second device at a first frequency, and each pose data frame acquired by the second device is associated with the rendered video frame. 107. One or more devices of clauses 101 through 102, 104, or 105, wherein synchronizing the WCD clock with the device's application layer clock includes synchronizing the WCD clock to 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 first attitude data is provided to the second device; the first time is before a rendering time at which the second device should begin rendering the first video frame; the first time is before the render time by a first offset; The device or devices of clauses 101 to 102, 104, 105, or 107, wherein the first offset is associated with M2R latency. 109. The second device acquiring a first attitude data frame at the beginning of the current TWT window; or A timeout from the start of the current TWT window occurs before an attitude data frame is acquired. When one of the conditions occurs, one or more devices of clauses 101 to 102, 104, 105, or 107 begin rendering a first video frame. 110. The interface is further configured to indicate to the second device the time of the start of the current TWT window; 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, and the WCD clock synchronization is associated with the TSF of the device and the TSF in the MAC of the second device; One or more devices of clauses 101 to 102, 104, 105, or 107, wherein the application layer clock of the second device is synchronized to the WCD clock of the second device, and 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. 111. One or more devices of clauses 101 through 102, 104, or 105, wherein synchronizing the device's application layer clock and 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. 112. Synchronizing an application layer clock to a WCD clock The device of one or more of clauses 101 to 102, 104, 105, or 111, including aligning the display time to a time associated with the current TWT window. 113. One or more devices of clauses 101 through 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 since the last synchronization of the application layer clock with the WCD clock being greater than a drift threshold. 114. The second device includes a software-enabled AP (SAP); One or more devices of clauses 101 to 113, wherein the device includes a head-mounted display (HMD) for displaying the video frames. 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 a plurality of video frames into a plurality of video slices; For each video slice of the plurality of 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; Video slices are identified by port numbers and differentiated services field codepoint (DSCP) values ​​contained in each MSDU of multiple PPDUs. Steps and and c) queuing the MSDU for transmission to a second device. 116. The method of clause 115, wherein queuing the MSDUs includes creating an MSDU queue in software for each video slice, each MSDU queue 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) that is associated with the access category (AC) of the video slice. 118. The method of one or more of clauses 115 to 117, wherein the AC of a video slice is associated with a 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; and 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 the second device. 121. Rendering the first i-slice; generating a first MSDU queue associated with the 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; and providing, to the second device, a PPDU including one or more MSDUs associated with the first i-slice after generating the second MSDU queue. 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; The method of one or more of clauses 115-119, wherein the device flushes an MSDU queue associated with the video slice after unsuccessfully attempting to transmit the PPDU to the second device a threshold number of times. 123. generating a replacement video slice after flushing the MSDU queue; 123. The method of one or more of clauses 115-119 or 122, further comprising: generating a replacement MSDU cue associated with the replacement video slice. 124. The method of one or more of clauses 115-119 or 122, further comprising indicating to the second device that the MSDU queue is to be flushed. 125. The method of clause 115, further comprising using forward error correction (FEC) for transmitting the one or more PPDUs to the second device. 126. Using FEC to transmit one or more PPDUs to a second device 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 one or more of the methods of clause 115 or 125 associated with one or more of the following: 127. A device includes a software-enabled access point (SAP); The method of one or more of clauses 115 to 126, wherein the second device includes a head-mounted display (HMD). 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 the plurality of video slices, generating a plurality of PPDUs to contain the video slices; each PPDU including one or more Medium Access Control Layer (MAC) Service Data Units (MSDUs) associated with a video slice; Video slices are identified by the port number and differentiated services field codepoint (DSCP) value contained in each MSDU of the PPDU, Queueing the MSDU for transmission to a second device and a processing system configured to: 129. The device of clause 128, wherein queuing the MSDUs includes creating an MSDU queue in software for each video slice, each MSDU queue identified by an Internet Protocol (IP) address, a port number, and a DSCP value. 130. One or more devices of clauses 128-129, wherein each video slice is associated with a traffic identifier (TID) that is associated with the access category (AC) of the video slice. 131. The device or devices of clauses 128 to 130, wherein the AC of a video slice is associated with a priority of the video slice. 132. The device of one or more of clauses 128 to 131, wherein the priority of a video slice depends on whether the video slice is an i-slice or a p-slice. 133. The processing system further: Render the first p slice, generating a first MSDU queue associated with the first p-slice; Render the first p slice, then the second p slice, The one or more devices of clauses 128 to 132, configured to flush 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 the second device. 134. The processing system further: Render the first i-slice, generating a first MSDU queue associated with the first i slices; Render the first i-slice, then the second i-slice or p-slice, Create a second MSDU queue associated with the second i-slice. It is configured as follows: 133. The one or more devices of clauses 128 to 132, wherein the interface is configured to provide, to the second device, a PPDU including one or more MSDUs associated with the first i-slice after generating a second MSDU queue. 135. For a PPDU associated with a video slice: the interface is configured to attempt to transmit the PPDU to the second device up to a threshold number of times; The one or more devices of clauses 128-132, wherein the processing system is further configured to flush an MSDU queue associated with the video slice after unsuccessfully attempting to transmit the PPDU to the second device a threshold number of times. 136. The processing system further: Generate a replacement video slice after flushing the MSDU queue, 136. The device or devices of clauses 128 to 132 or 135, configured to generate a replacement MSDU queue associated with the replacement video slice. 137. One or more devices of clauses 128-132 or 135, wherein the interface is further configured to indicate to the second device that the MSDU queue is to be flushed. 138. The device of clause 128, wherein the device is configured to use forward error correction (FEC) for transmitting one or more PPDUs to the second device. 139. Using FEC to transmit one or more PPDUs to a second device 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 one or more devices of clause 128 or 13...

Claims

1. 1. A method performed by a wireless communication device for an extended reality (XR) experience, comprising: obtaining control of the wireless medium; the control of the wireless medium is associated with a first priority of 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 is different from a second priority of transmitting data from the second device to the wireless communication device over the wireless medium; Steps and providing the first PPDU to the second device; providing one or more subsequent PPDUs of the application file to the 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, the first priority being associated with a first set of enhanced distributed channel access (EDCA) parameters, the second priority being associated with a second set of EDCA parameters, and the third priority being associated with a third set of EDCA parameters; providing a first request to send (RTS) frame to acquire the control of the wireless medium, the first RTS frame including an indication of a network allocation vector (NAV) for maintaining the control of the wireless medium for a first period of time, the first period of time being greater than a first transmission 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 period, the second RTS frame includes an instruction in the NAV to extend the first period to cover multiple TXOPs; Providing the first PPDU is after obtaining the first CTS frame and is during the first TXOP. Steps and A method comprising:

2. The method of claim 1, wherein the first priority is associated with a first back-off counter value, the first back-off counter value being used by a back-off counter of the wireless communication device to contend for the wireless medium for the first PPDU; the second priority is associated with a second back-off counter value greater than the first back-off counter value; the third priority is associated with a third back-off counter value greater than the second back-off counter value, the third back-off counter value being used by the back-off counter of the wireless communication device to contend for the wireless medium for the one or more subsequent PPDUs. The method of claim 1.

3. providing a final PPDU of the application file to the second device; the last PPDU comprises a 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. Steps and preventing providing another RTS frame to extend the first period after providing the last MSDU to the second device; releasing control of the wireless medium at the end of the first period; The method of claim 1 further comprising:

4. The method of claim 3 , further comprising providing a contention free (CF) end frame after providing the last MSDU to release control of the wireless medium.

5. obtaining control of the wireless medium to provide one or more PPDUs of a second application file to the second device; a first MSDU of the second application file including metadata identifying the first MSDU of the second application file; the first MSDU is associated with the first set of EDCA parameters; Gaining control of the wireless medium is associated with the first set of EDCA parameters. Steps The method of claim 3 further comprising:

6. 6. The method of claim 5, wherein the wireless communication device enables RTS / CTS signaling for the first PPDU for each application file.

7. The EDCA parameters are: arbitration interframe spacing number (AIFSN), Minimum Contention Window (CWmin), or Maximum Contention Window (CWmax) 10. The method of claim 1, comprising one or more of:

8. 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; The method of claim 1.

9. 1. A wireless communication device configured for an extended reality (XR) experience, comprising: a processing system; an interface, Obtaining control of a wireless medium, the control of the wireless medium is associated with a first priority of 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 is different from a second priority of transmitting data from the second device to the wireless communication device over the wireless medium; To obtain and providing the first PPDU to the second device; providing one or more subsequent PPDUs of the application file to the 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, the first priority being associated with a first set of enhanced distributed channel access (EDCA) parameters, the second priority being associated with a second set of EDCA parameters, and the third priority being associated with a third set of EDCA parameters; providing a first request to send (RTS) frame to acquire the control of the wireless medium, the first RTS frame including an indication of a network allocation vector (NAV) for maintaining the control of the wireless medium for a first period of time, the first period of time being greater than a first transmission 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 period; the second RTS frame includes an instruction in the NAV to extend the first period to cover multiple TXOPs; providing the first PPDU after obtaining the first CTS frame and during the first TXOP; an interface configured to: A wireless communication device comprising:

10. the first priority is associated with a first back-off counter value, the first back-off counter value being used by a back-off counter of the wireless communication device to contend for the wireless medium for the first PPDU; the second priority is associated with a second back-off counter value greater than the first back-off counter value; 10. The wireless communication device of claim 9, wherein the third priority is associated with a third backoff counter value greater than the second backoff counter value, the third backoff counter value being used by the backoff counter of the wireless communication device to contend for the wireless medium for the one or more subsequent PPDUs.

11. the interface further comprising: providing a final PPDU of the application file to the second device; the last PPDU comprises a 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. To provide and preventing providing another RTS frame to extend the first period after providing the last MSDU to the second device; releasing control of the wireless medium at the end of the first period.

10. The wireless communication device of claim 9, configured to:

12. 12. The wireless communication device of claim 11, wherein the interface is further configured to provide a contention free (CF) end beacon after providing the last MSDU to release control of the wireless medium.

13. the interface is further configured to obtain control of the wireless medium to provide one or more PPDUs of a second application file to the second device; a first MSDU of the second application file including metadata identifying the first MSDU of the second application file; the first MSDU is associated with the first set of EDCA parameters; and acquiring control of the wireless medium is associated with the first set of EDCA parameters.

12. The wireless communication device of claim 11.

14. 14. The wireless communication device of claim 13, wherein the wireless communication device enables RTS / CTS signaling for the first PPDU for each 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; 10. The wireless communication device of claim 9.

16. 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 devices contending for the wireless medium to transmit data classified as having high importance associated with a fourth priority; 10. The wireless communication device of claim 9, wherein the wireless communication device or the second device obtains control of the wireless medium based on the first priority or the second priority.

17. The method of claim 16, wherein the wireless communication devices contend for the wireless medium to transmit one or more subsequent PPDUs associated with the third priority; preventing the second device from contending for the wireless medium; 17. The wireless communication device of claim 16, wherein the OBSS device obtains control of the wireless medium based on the fourth priority.

18. 1. 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 over a wireless medium; the second device gains 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 is different from a second priority of transmitting data from the wireless communication device to the second device over the wireless medium; Steps and obtaining one or more subsequent PPDUs of the application file from the second device, 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, the first priority being associated with a first set of enhanced distributed channel access (EDCA) parameters, the second priority being associated with a second set of EDCA parameters, and the third priority being associated with a third set of EDCA parameters; obtaining a first request to send (RTS) frame from the second device, the first RTS frame including a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time, the first period of time being greater than a first transmission opportunity (TXOP) during which the first PPDU is obtained from the second device; 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 second device after the first TXOP and before an end of the first period; the second RTS frame includes an instruction in the NAV to extend the first period to cover multiple TXOPs; obtaining the first PPDU after providing the first CTS frame and during the first TXOP; A method comprising:

19. the first priority is associated with a first backoff counter value; the second priority is associated with a second back-off counter value greater than the first back-off counter value, the second back-off counter value being used by a back-off counter of the wireless communication device in determining when to provide the data to the second device; the third priority is associated with a third back-off counter value greater than the second back-off counter value; 19. The method of claim 18.

20. obtaining a last PPDU of the application file from the second device, the last PPDU comprises a 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; preventing the second device from providing another RTS frame to extend the first 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 period. The method of claim 18 further comprising the steps of:

21. the second device obtaining control of the wireless medium to provide one or more PPDUs of a second application file to the wireless communication device; a first MSDU of the second application file including metadata identifying the first MSDU of the second application file; the first MSDU is associated with the first set of EDCA parameters; and obtaining control of the wireless medium by the second device is associated with the first set of EDCA parameters.

21. The method of claim 20.

22. 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 devices contending for the wireless medium to transmit data classified as having high importance associated with a fourth priority; 20. The method of claim 18, wherein the wireless communication device or the second device obtains control of the wireless medium based on the first priority or the second priority.

23. The method of claim 18, further comprising the step of providing the data to the second device after the first TXOP and before obtaining the second RTS frame.

24. 1. A wireless communication device configured for an extended reality (XR) experience, comprising: a processing system; an interface, obtaining a first physical layer protocol data unit (PPDU) of the application file from a second device over a wireless medium; the second device gains 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 is different from a second priority of transmitting data from the wireless communication device to the second device over the wireless medium; To obtain and obtaining one or more subsequent PPDUs of the application file from the second device, 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, the first priority being associated with a first set of enhanced distributed channel access (EDCA) parameters, the second priority being associated with a second set of EDCA parameters, and the third priority being associated with a third set of EDCA parameters; obtaining a first request to send (RTS) frame from the second device, the first RTS frame including a network allocation vector (NAV) indication for maintaining control of the wireless medium for a first period of time, the first period of time being greater than a first transmission opportunity (TXOP) during which the first PPDU is obtained from the second device; 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 second device after the first TXOP and before an end of the first period; the second RTS frame includes an instruction in the NAV to extend the first period to cover multiple TXOPs; obtaining the first PPDU is after providing the first CTS frame and is during the first TXOP; To obtain and an interface configured to: A wireless communication device comprising:

25. the first priority is associated with a first backoff counter value; the second priority is associated with a second back-off counter value greater than the first back-off counter value, the second back-off counter value being used by a back-off counter of the wireless communication device in determining when to provide the data to the second device; the third priority is associated with a third back-off counter value greater than the second back-off counter value; 25. The wireless communication device of claim 24.

26. The interface: obtaining a last PPDU of the application file from the second device; the last PPDU comprises a 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; preventing the second device from providing another RTS frame to extend the first 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 period.

25. The wireless communication device of claim 24, further configured to: obtain.

27. the second device obtaining control of the wireless medium to provide one or more PPDUs of a second application file to the wireless communication device; a first MSDU of the second application file including metadata identifying the first MSDU of the second application file; the first MSDU is associated with the first set of EDCA parameters; and obtaining control of the wireless medium by the second device is associated with the first set of EDCA parameters.

27. The wireless communication device of claim 26.

28. the second device includes a software-enabled AP (SAP); the wireless communication device is included in a head-mounted display (HMD); 25. The wireless communication device of claim 24, wherein the application file is associated with a video frame to be displayed by the HMD.

29. A wireless communication device as described in claim 24, wherein the first TXOP is shortened by the second device before the second device provides a PPDU associated with the application file to the wireless communication device.

30. The wireless communication device of claim 24, wherein the interface is further configured to provide the data to the second device after the first TXOP and before obtaining the second RTS frame.

Images