Method for server processing task delay measurement and adjustment

Abstract

Systems and methods for fine-grained latency measurement and processing adjustment for augmented reality, extended reality, mixed reality, and / or virtual reality environments and systems are disclosed. In some embodiments, fine-grained processing task latency measurements and mitigation actions, including adjusting media quality and / or exchanging operational functions between the client and server to avoid individual task latencies and improve quality of experience (QoE), can be performed individually or collectively by a client wireless transmit receive unit (WTRU) and an application server.

Description

[0001] Related applications This application is a divisional application of Chinese Patent Application No. 202480037364.9, filed on April 5, 2024, which claims the benefit and priority of European Patent Application No. 23305532.6, filed on April 7, 2023, entitled “Methods for ServerProcessing Task Delays Measurements and Adjustments,” the entire contents of which are incorporated herein by reference. Background Technology

[0002] Extended reality, such as augmented reality, virtual reality, mixed reality, and related reality, can often require significant processing power and bandwidth. For example, to reduce the weight, complexity, and power consumption of wearable devices like extended reality glasses, some implementations offload video processing to remote devices (e.g., laptops, computers, or even servers or virtual clouds via wireless networks). However, even with powerful computing devices, processing time and network throughput limitations can still result in significant latency, negatively impacting the quality of user experience (QoE). For instance, latency exceeding 20 to 50 milliseconds in video can be noticeable and affect immersion, causing nausea, etc. Measuring this latency as end-to-end latency may be too coarse to provide actionable insights for mitigating latency and improving performance. Summary of the Invention

[0003] To address these and other challenges in extended reality (XR) scenarios, the methods, apparatuses, and / or systems disclosed herein provide fine-grained latency measurement and processing adjustments. For example, reducing the travel time of messages sent and received between an XR wireless transmit / receive unit (WTRU) and a server can improve QoE, and latency measurement can precisely indicate where latency occurs and how it can be mitigated. Actions can then be taken, including transferring processing tasks between local and remote devices, to utilize minimal additional latency. Attached Figure Description

[0004] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals in the figures denote the same elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed technologies; Figure 1B This illustrates one or more methods disclosed herein that can be used... Figure 1AThe system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system. Figure 1C This illustrates one or more methods disclosed herein that can be used... Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown. Figure 1D This illustrates one or more methods disclosed herein that can be used... Figure 1A The system diagram shown represents another example RAN and another example CN used within the communication system. Figure 2A and Figure 2B Examples of target use cases for WTRU glasses based on some implementation methods are shown; Figure 3 An example of a 5G interactive immersive service architecture based on a standalone AR WTRU (STAR) is shown, according to some implementation methods; Figure 4 An example of a 5G interactive immersive service architecture based on an edge-dependent AR WTRU (EDGAR) is shown, according to some implementation methods; Figure 5 An example of a split management architecture based on some implementation methods is shown; Figure 6 An example of a high-level call flow for split rendering, based on some implementation methods, is shown; Figure 7 Examples of potential time delays in systems based on some implementation methods are shown; Figure 8 Examples of devices and servers for edge processing that handle the decomposition of delayed tasks are shown, based on some implementation methods. Figure 9 Examples of devices and servers for handling delayed task decomposition for independent processing, based on some implementation methods, are shown; Figure 10 An example flowchart of QoE management based on some implementations is shown.

[0005] Figure 11 An example of a high-level call flow for split rendering for WTRU-centric QoE management is shown, based on some implementations; Figure 12 This illustrates an example of a high-level call flow for split rendering in application server-centric QoE management, based on some implementation methods; and Figure 13 Example flowcharts for methods of QoE management based on some implementations are shown. Detailed Implementation

[0006] Figure 1A This diagram illustrates an example communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. For example, the communication system 100 can employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0007] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0008] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-Bs, eNodeBs (eNBs), home Node-Bs, home eNode Bs, next-generation Node-Bs such as gNode Bs (gNBs), new radio (NR) Node-Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0009] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may employ multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0010] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0011] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 and WTRUs 102a, 102b, and 102c can implement radio technologies, such as using Wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) for air interface 116. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0012] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies, such as using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish Evolved UMTS Terrestrial Radio Access (E-UTRA) for air interface 116.

[0013] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technology, such as using NR to establish NR radio access for air interface 116.

[0014] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use the dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or by transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0015] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0016] Figure 1A Base station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0017] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although... Figure 1AAs not shown, but will be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104. For example, in addition to connecting to RAN 104, which may be utilizing NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0019] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with a base station 114a that can use cellular-based radio technology and with a base station 114b that can use IEEE 802 radio technology.

[0020] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0021] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together in a package or chip.

[0022] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In embodiments, for example, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0023] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0024] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

[0025] The processor 118 of WTRU 102 can be coupled to and receive user input data from: a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information and store data from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data from memory not actually located on WTRU 102, such as on a server or home computer (not shown).

[0026] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to other components in the WTRU 102 and / or control power to those other components. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0027] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0028] The processor 118 can also be connected to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, FM radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. Sensors may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0029] WTRU 102 may include a full-duplex radio, wherein the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, wherein the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0030] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0031] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0032] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0033] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While the foregoing elements are described as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0034] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0035] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during eNode-B handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0036] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0037] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with such an IP gateway as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0038] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0039] In a representative embodiment, the other network 112 may be a WLAN.

[0040] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can have an interface to a Distribution System (DS) or another type of wired / wireless network that loads traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA using a Direct Link Setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0041] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access - Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects the primary signal and / or determines that the primary signal is busy, that particular STA can back off. In a given BSS, at any given time, only one STA (e.g., only one station) can transmit.

[0042] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0043] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0044] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0045] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even if most available frequency bands remain idle.

[0046] In the United States, the available frequency band for 802.11ah is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0047] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0048] RAN 104 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0049] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of digital architecture parameters. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can be varied for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various lengths or scalable lengths, or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

[0050] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0051] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0052] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are described as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0053] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services dependent on Ultra Reliable Low Latency (URLLC) access, services dependent on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (such as WiFi).

[0054] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0055] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0056] CN 106 can facilitate communication with other networks. For example, CN 106 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and local DNs 185a and 185b.

[0057] Given Figures 1A to 1D and Figures 1A to 1D The corresponding descriptions can be performed by one or more emulation devices (not shown) that perform one or more of the functions described herein with respect to: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0058] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0059] One or more simulation devices may perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device may be used to test scenarios in a laboratory and / or undeployed (e.g., under test) wired and / or wireless communication networks to perform testing of one or more components. One or more simulation devices may be test equipment. The simulation device may transmit and / or receive data using direct RF connection and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0060] In some cases, there may be one or more extended reality (XR) services and / or applications, such as interactive immersive services, augmented reality (AR), virtual reality (VR), and / or mixed reality (MR). The systems and methods discussed herein are equally applicable to interactive immersive services, XR, AR, VR, and MR, and many implementations can be interchangeable. Therefore, for example, the discussion of specific embodiments or implementations of XR is equally applicable to, but not limited to, VR.

[0061] A WTRU can correspond to any XR device / node that can take one or more form factors, as described herein. In addition to the definitions already provided herein, WTRUs (e.g., where WTRUs can be interchanged with XR WTRUs) can include, but are not limited to, head-mounted displays (HMDs), optical see-through glasses (sometimes referred to as optical XR or optical AR, or optical see-through), camera-see-through head-mounted displays (HMDs) (sometimes referred to as video XR or video AR, or video see-through), mobile devices with location tracking and cameras, wearable devices, etc. Additionally, different types of XR WTRUs may exist based on the functionality of the XR device, such as one or more of the following features / capabilities: display, camera, sensor, sensor processing, wireless connectivity, XR / media processing, and / or power supply. These additional features / capabilities can be internal and / or external; where they are external, they can be provided and / or accompanied by one or more devices, wearable devices, actuators, sensors, controllers, and / or accessories. One or more XR WTRUs can be grouped into collaborative XR groups to support any number of XR applications, experiences, and / or services.

[0062] In some scenarios, such as XR with interactive experiences, the WTRU (e.g., XR WTRU) can interact with an XR server running on an edge computing node to offload computationally intensive tasks, such as video rendering or scene state calculations (e.g., including physical simulations). In an example, the XR WTRU can send tracking, sensor information, gesture information, pose information, and / or interactive information to the XR server in the uplink (UL). The XR server can then generate an XR scene based on the information sent from the XR WTRU. The XR server can rasterize the XR viewport and perform XR pre-rendering, and generate XR media, which is encoded and delivered to the XR WTRU in the downlink (DL). The XR WTRU device can decode the XR media, perform up-to-date pose correction to account for any changes in pose, and render the XR viewport. As discussed herein, application flows can occur between more than two devices (e.g., WTRU <-> Edge <-> Server). Everything behind the edge server can be abstracted by the edge server as "processing". Furthermore, the terms edge and cloud can be used interchangeably (e.g., edge server can be equivalent to cloud server). In some cases, unless otherwise stated, edge server and application server (AS) can be used interchangeably.

[0063] As discussed above, XR implementations can often require significant processing power and bandwidth. For example, to reduce the weight, complexity, and power consumption of wearable devices such as extended reality glasses, some implementations offload video processing to remote devices (e.g., laptops, computers, or even servers or virtual clouds via wireless networks). However, even with powerful computing devices, current limitations in available processing and memory capabilities, processing time, and network throughput can still result in significant latency, negatively impacting the Quality of Experience (QoE). For instance, XR applications may have stringent round-trip requirements to provide an acceptable QoE for the end user, such as a 20 ms motion-to-display latency and / or a 50 ms round-trip interaction latency for ultra-low latency applications. Latencies exceeding these can be noticeable and negatively impact immersion, causing nausea, etc. Measuring this latency as an end-to-end latency may be too coarse to provide actionable insights to mitigate latency and improve performance.

[0064] In some implementations, to address these and other issues in extended reality (XR) scenarios, the methods, apparatuses, and / or systems disclosed herein provide fine-grained latency measurement and processing adjustments. For example, reducing the travel time of messages transmitted between the XR Wireless Transmitter Receiver Unit (WTRU) and the server can improve QoE, and latency measurement can precisely indicate where the latency occurs and how it can be mitigated. Actions can then be taken, including transferring processing tasks between local and remote devices (e.g., between the WTRU and the application server), to utilize minimal additional latency.

[0065] For example, when WTRU does not have sufficient computing power, rendering XR videos or scenes may require offloading processing to more powerful computing units. Figure 2A and Figure 2B The following examples illustrate two use cases where performing processing at an edge server may be beneficial for meeting XR QoE requirements.

[0066] Figure 2AAn example of a target use case 200 for one or more methods described herein is shown. In some cases, the optical see-through device 202 (e.g., XR glasses, which may be a type of WTRU) may have limited computing and battery resources. When a user runs an AR application, the AR glasses 202 may communicate independently or via a smartphone (e.g., a second WTRU, not shown), capturing the user's pose (e.g., head position and / or rotation, viewing direction or angle, hand, finger, and / or controller position, etc.) and sending the user's pose to an edge application server 204. The server application then processes the video stream to render it based on the received pose and may send it back to the AR glasses 202 via a smartphone, where the video stream can be rendered on the glasses. Figure 2B In another use case 200' shown, a video perspective device 202' (e.g., a VR headset, which may be a type of WTRU) can send a first video stream to an edge server 204, which calculates overlay graphics information on the received video and then sends the rendered video stream back to the VR headset 202' (possibly via a second WTRU).

[0067] In some system architectures used for interactive immersive services (e.g., XR), there may be different scenarios regarding how to handle workflows between XR WTRUs and cloud / edge servers. For example, in some systems (e.g., 5G), there may be standalone AR (STAR) WTRU scenarios and / or edge (server) dependent AR (EDGAR) WTRU scenarios.

[0068] Figure 3 An example of a STAR-based interactive immersive service architecture 300 is shown. Similarly, Figure 4 An example of an interactive immersive service architecture 400 based on EDGAR is shown. In this case, most of the rendering can be done on server 404.

[0069] In some use cases, such as shared interactive immersive services, user interactions can be sent from WTRU to the server. The server handles the request by changing the immersive media scene based on the interaction (e.g., changing the context, such as panning, rotating, scaling, and / or adding / interacting with / changing objects in the scene).

[0070] First refer to Figure 3For STAR scenario 300, the UE-XR client or WTRU 302 can execute XR runtime process 312, which can communicate with XR application 310 (e.g., media viewer, video game, productivity application, etc.) to provide functionality. XR runtime process 312 can serve as an interface to hardware components of the UE-XR client or WTRU 302, including sensors (e.g., IMU, accelerometer, buttons, dials, etc.) and cameras or microphones, as well as output components such as actuators (e.g., linear or rotary actuators for "rumble" or haptic effects, or other types of actuators), displays, speakers, or headphones, etc. XR source management 314 may include services, servers, subroutines or other executable logic for interacting with XR runtime 312 and XR application 310 to fulfill requests for media data, and may control whether such requests are provided by a local scene manager 320, rendering engine 322 and renderer 324 and / or a remote scene manager 330 on XR server 304.

[0071] For example, in some implementations, the UE-XR client 302 can detect gesture information or user interaction and can transmit this information to a server 304 (which may include a virtual server or cloud application server provided by one or more physical computing devices) via a network interface card 318 on a network 306 (e.g., a wired network, a wireless network, a combination of wired and wireless networks, etc.). In some cases, user interaction may be a single event that is completely asynchronous with other data streams. Furthermore, the frequency of interaction events may depend on the type of interaction and the use case.

[0072] The XR application 328, executed by server 304, can process pose information and user interactions (e.g., via scene manager 330 and graph processor 332) to generate a processed scene that may include additional media assets 336 and / or commands for actuators or other functions indicated by XR function 334, and sends the processed scene back to the WTRU (via media delivery function 326 protocol and NIC 318) in the form of a scene description update or a completely new scene description. Scene manager 320 can parse the updated and / or scene description to generate a view or image for rendering engine 322, which can use renderer 324 to render the scene to a display.

[0073] refer to Figure 4For EDGAR scene 400 (which can also be referred to as split rendering), WTRU 402 can offload some or all of the scene rendering to server 404. In this implementation, the server's XR application 428 can include renderer 440 (similar to renderer 324) that rasterizes the XR viewport and renders images of XR media for encoding and delivery to the WTRU for display. For example, a high-resolution, complex ray-traced environment may require considerable processing power to accurately calculate reflections and occlusions, while decoding and displaying the resulting video bitstream may be relatively easier. By moving this processing to the high-performance edge server 404, client 402 may require less power and / or processor resources, thus extending battery life, reducing weight, etc. Additionally, the processing on edge server 404 can be highly scalable, with dynamic parallel processing of scenes (e.g., distributing multiple sets of images, frames, or even macroblocks to different virtual servers for rendering). Media asset storage 436 can be offloaded to a dedicated storage server or application provider 440, which similarly contributes to the scalability of server processing and rendering.

[0074] Figure 5 An example of a split management architecture 500 with a UE-XR client or WTRU 502 and a data network (DN) 504 is shown. This split management architecture may include one or more servers (e.g., application providers, split rendering servers, and network nodes that provide Real-Time Communication Application Functionality (RTC AF) in some implementations, collectively referred to as application services or AS). In some cases, a split rendering media service enabler may define the required formats and / or protocols to make split rendering accessible to the media service and application provider. An end-to-end architecture can be depicted as shown, where WTRU 502 includes the functionality shown on the left and data network 504 includes the functionality shown on the right. One or more of the following functions may coexist between WTRU 502 and DN 504: Split Render Client (SRC) 506, which is responsible for acquiring WTRU media capabilities and negotiating with RTC (Real-Time Communication) AF 510 via Media Session Handler 516 to agree on the split rendering process at RTC AF; Split Render Server (SRS) 508, which is responsible for negotiating split rendering (SR) sessions with SRC 506, monitoring the server's edge resource usage, and managing / running the split rendering process; Application Function (AF) 510, which may be responsible for provisioning, QoS allocation, and edge resource discovery; Application Service Provider 512, which is the application provider providing services; XR Application 514, which is the application running on WTRU; and / or Media Session Handler (MSH) 516, which is the entity on WTRU responsible for communicating with the control plane of AF 510.

[0075] Figure 6 An example of a high-level call flow 600 for split rendering is shown. For example, one or more possible scenarios may exist where WTRU is the client and AS is the server, or, for example, AS is the client and WTRU is the server. At 1, the rendering engine can discover the split rendering server and establish a connection with it. The rendering engine can provide information about its rendering capabilities and XR runtime configuration (e.g., OpenXR configuration that can be used for this purpose). At 2, in response, the split rendering server can create split rendering output and a description of the input it expects to receive from WTRU. At 3, the rendering engine can request a buffered stream from the MAF (Media Access Function), which in turn establishes a connection with the split rendering server to stream pose information and retrieve the split rendering buffer. At 4, as part of the rendering loop, the source manager can retrieve poses and user input from the XR runtime. At 5, the source manager can share pose predictions and user input actions with the split rendering server. At 6, the split rendering server can use this information to render frames. At 7, the rendered frames can be encoded and streamed to the MAF. At 8, the MAF can decode and process the buffered frames. At point 9, MAF can pass the raw buffered frame to the rendering engine and / or the XR runtime. At point 10, the XR runtime can composite the received frame and render it to the display.

[0076] Figure 7 Examples of potential time delays in system 700 are illustrated, including communication delays for transmitting data to server 702; server-side delays for buffering, processing responses or other data, and sending said responses or other data to client 704; communication delays for transmitting data back to client 706; and buffering, processing, and rendering data at client 708. The combination of the first three delays 702 to 706 can be measured as a round-trip time 710 (e.g., from the transmission of a request or pose information until the receipt of a processed frame or scene information). Real-time communication and protocols are primarily designed to meet real-time requirements, and packet loss resulting from failure to meet these requirements can lead to poor QoE for the end user. The end-user's QoE requirements (including high-quality time content, tight RTT latency, such as motion-to-display latency, etc.) cannot be addressed solely by post-processing operations such as pose correction or asynchronous time-warping to mitigate such network bandwidth fluctuations.

[0077] This application can have according to Figure 7While methods to calculate the overall WTRU and server processing latency 710 by adjusting processing at the UE and modifying communication protocols may not be known, the detailed QoE impact of each application processing step (such as rendering and / or encoding, which form part of the server-side latency 704) may be unknown. Therefore, applications cannot manipulate processing steps in real time and cannot adjust parameters affecting QoE accordingly.

[0078] The systems and methods discussed herein address these and other issues by providing technologies and protocols for measuring and adjusting the operation of either end (e.g., UE / WRUL or server) or both ends, to reduce time latency that may lead to poor QoE in XR services / experiences. In one or more implementations of these systems, apparatuses, and / or methods, the WTRU and / or application server (AS) (WTRU / AS) can apply one or more QoEs by inserting one or more requests within the application data unit from one apparatus (WTRU / AS) to another, sending one or more task latency measurement and / or task latency adjustment requests. Furthermore, the WTRU / AS can send its processing task latency measurement and / or adjustment responses. As discussed herein, references to the phrase “processing task delay” are interchangeable with similar phrases, where one or more of these words are plural, and no limitation is intended in any of the possible forms of the specific recitation of the phrase, wherein different permutations are interchangeable and may be as follows: processing task delay, which is a delay for processing a single task; processing task delay, which is a delay for processing multiple tasks, where delay can represent a combination of consecutive or non-consecutive tasks; processing task delay, which is multiple delays for processing a single task; processing task delay, which is multiple delays for processing multiple tasks. For all the foregoing examples, there may be one or more measurements and / or adjustments (e.g., there may be a request for one or more measurements and different combinations of tasks at one time; for example, there may be a combination of different task delay measurements). Additionally, any reference to a single delay or task may be interchangeable with multiple delays or tasks, respectively.

[0079] In one scenario, WTRU can calculate the latency of WTRU processing tasks and can request one or more measurements and adjustments to the latency of AS processing tasks from the application server (AS).

[0080] The WTRU can calculate QoE based on its measured processing task latency and / or AS processing task latency measurements received from the AS. The WTRU can calculate AS and WTRU task latency adjustments to meet the expected application QoE, and then adjust the WTRU processing task latency and / or request processing task latency adjustments from the AS.

[0081] In the example, the WTRU may send an "AS processing task delay" request to the AS in the first stream using an application data unit. The request may include one or more actions to be performed by the AS, such as: measuring the AS processing task delay to be performed by the AS; adjusting the AS processing task delay to be performed by the AS; sending the AS processing task delay measurement from the AS to the WTRU; and / or sending the AS processing task delay adjustment from the AS to the WTRU.

[0082] In the example, the AS can send an "AS processing task delay" response to the WTRU in the second stream using an application data unit. The response may include one or more of the following: a measurement of the AS processing task delay performed in the AS and / or an adjustment to the AS processing task delay.

[0083] In one scenario, the application server (AS) can calculate the latency of AS processing tasks and can request measurements and / or adjustments to the latency of WTRU processing tasks from the WTRU.

[0084] The AS can calculate QoE based on its measured processing task latency and / or WTRU processing task latency measurements received from the WTRU. The AS can calculate WTRU and AS task latency adjustments to meet the expected application QoE, and then adjust the AS processing task latency and / or request processing task latency adjustments from the WTRU.

[0085] In the example, the AS can send a "WTRU processing task delay" request to the WTRU in the first stream using an application data unit. The request may include actions to be performed by the WTRU: a measurement of the WTRU processing task delay to be performed by the WTRU; an adjustment of the WTRU processing task delay to be performed by the WTRU; sending the WTRU processing task delay measurement from the WTRU to the AS; and / or sending the WTRU processing task delay adjustment from the WTRU to the AS.

[0086] In the example, the WTRU can send a "WTRU processing task delay" response to the AS in the second stream using an application data unit. The response may include one or more of the following: a measurement of the WTRU processing task delay performed in the WTRU and / or an adjustment to the WTRU processing task delay.

[0087] In some implementations, latency can be calculated as the difference between the measured end time of a task and the measured start time of a task. While this measurement may not be very precise from an application's perspective, it can provide an average deviation of the latency. Other measurements can be used, such as the time from the start time of one task to the start date of the next task, or the time from end time to end time.

[0088] In some implementations, a latency adjustment request can instruct a reduction, increase, or "relaxation" of processing task latency. Reducing latency might trigger the server and / or WTRU to degrade visual quality (e.g., by modifying bit depth, resolution; frame rate; depth of field; gaze angle or center angle, within which the scene is rendered at higher quality relative to areas outside the center angle (considering reduced visual acuity); shader or texture quality; or any other type and form of adjustment) to meet the desired latency. Conversely, relaxing latency or allowing an increase in latency may mean improving quality when the expected latency or QoE is met. Therefore, in some implementations, QoE and / or latency can be calculated and compared to one or more thresholds. If QoE is below a first threshold (or latency is above a first threshold), latency can be reduced or visual quality reduced; if QoE is above a second threshold (or latency is below a second threshold), latency can be relaxed or visual quality improved. In some implementations, if QoE or latency is between these thresholds, quality can be maintained. This may provide some lag and prevent sudden visual or processing changes that could increase their own latency due to variations or overhead (e.g., discarding frames that have already been processed at one resolution in order to reprocess them at a new resolution, etc.).

[0089] In some implementations, a delayed adjustment response may report valid adjustments or adjustment feedback from the AS or WTRU regarding the application of the requested adjustment. The response may include additional adjustment information, such as indications of why adjustments have not yet been performed or have been partially performed.

[0090] In some implementations, QoE can be correlated with round-trip application latency requirements, such as motion-to-display latency constraints. Fine-grained task latency measurements and the associated deviations measured after each round trip can highlight metrics that contribute to the end-user's visual quality (QoE).

[0091] In one scenario, the processing latency of the WTRU and / or AS can vary based on a range of processing latency values ​​between a minimum and a maximum latency value. This depends on the different processing task parameters, as described herein. WTRU and AS can be configured, established, and / or agreed upon for parameter value ranges that apply to different processing tasks. WTRU and AS can be configured to determine how latency changes as parameter values ​​are updated.

[0092] In some implementations, WTRU and AS can configure, establish, and / or agree on handling delay budgets, such as: expected standard / median delay budgets; delay budget adjustment ranges (minimum, median, maximum); and / or delay budget thresholds (critical lower limit, critical upper limit) used to trigger message sending, such as QoE or delay thresholds discussed above.

[0093] In various implementations, the handling of delay budgets can be characterized in one or more ways. For example, in some implementations, the delay budget can be represented by, for instance, ... Figure 7 The description represents the overall AS or WTRU processing latency 704 and 708. For AS, latency 704 may include content access, scene update, rendering, encoding, and / or content delivery latency. For WTRU, latency 708 may include uplink and / or downlink processing tasks (e.g., upload or send, gestures and user interactions, content delivery, download or receive, content access, decoding, post-processing, display, etc.). It should be noted that some of these latency may occur after detecting a user interaction that modifies the scene and before sending gestures or interaction information; and some may occur after receiving the rendered scene or rendering instructions or bitstream and before display.

[0094] In a more granular implementation, the latency budget can be characterized by the latency of a single AS and / or WTRU processing task (e.g., the latency of a rendering task at an AS). For example, the latency budget can be characterized by the association of different tasks performed at the same location, but in some cases, the tasks may not be sequential. Examples include tasks such as: image / video processing tasks, including scene updates, rendering, and encoding; WTRU content access and delivery; AS content access and delivery; and / or any other type and form of task.

[0095] In some implementations, latency budgets can be characterized by the correlation between different tasks processed at different locations / at different locations. This correlation can represent the relationship between different tasks. This correlation can be used for QoE measurement on the AS or WTRU and for QoE tuning of the associated tasks. For example, changing the encoder configuration may affect encoding and decoding latency. Examples include tasks such as: content distribution from WTRU to AS, including WTRU content delivery and AS content access; content distribution from AS to WTRU, including AS content delivery and WTRU content access; encoding / decoding chains, including AS encoding and WTRU decoding; round-trip distribution, including both WTRU and AS content delivery and content access; AR-specific tasks, including pose and / or interaction and / or scene updates; or any other such tasks.

[0096] Figure 8 An example of device and server processing latency in a system using edge processing 800, broken down into fine-grained details, is shown. As illustrated, the overall server processing task latency 804 may be the result of several individual task latencies, which are referred to differently as task latency, processing latency, parameters, or latency parameters, or other similar terms.

[0097] For example, in some implementations, the parameter can be server content access, which could include data deserialization. In one case, it can be aperiodic, where there may be input event handling priorities and / or output message processing priorities. In another case, it can be periodic, where there may be input buffer scheduling priorities, input scheduling periodicity (such as frequency), and / or output message processing priorities.

[0098] For example, in some implementations, the parameter could be a scene update, which could be an update of the scene graph based on received data (e.g., by taking into account, for example, the physical properties of the environment, interactions between users and / or other entities or objects, etc.). For instance, the accuracy level of the scene state calculation could include parameters that affect latency. The scene update latency can be adjusted by increasing / decreasing the accuracy of the scene state (e.g., by adjusting the accuracy of the physical simulation through the use of a simplified mesh geometry for collision detection).

[0099] For example, in some implementations, the parameters can be rendering parameters. These can include: image resolution, frame rate, bit rate, gaze angle, and / or selecting a level of detail to render visually high-quality objects and / or spatially partitioning a large virtual scene, or any other such rendering adjustments or parameters.

[0100] For example, in some implementations, the parameter can be encoding. This can include adjustments to codec profiles or types, compression ratios or types, quality parameters or partitioning parameters, or any other such parameters that can adjust encoding latency or delay.

[0101] For example, in some implementations, parameters can be server content delivery, which may include data serialization or other send-related parameters. In some implementations, adjustments may include buffer management, message priority, send burst size or set size, retransmission rate, error correction parameters, or other such characteristics.

[0102] Figure 8 The latency of WTRU processing tasks described in the text can similarly depend on various specific parameters.

[0103] For example, in some implementations, adjustable delay-related parameters in the UL (pre-transmission) direction may include: pose and user interaction, such as refresh rate for pose prediction; and / or WTRU content delivery, which may include data serialization. For WTRU content delivery, there may be aperiodic patterns or conditions, which may include: input buffer management, including message priority; input event processing priority; and / or output message processing priority. For WTRU content delivery, there may be periodic patterns or conditions, which may include: input buffer scheduling priority; input scheduling periodicity, such as frequency; and output message processing priority.

[0104] In some implementations, the parameters in the DL (post-send) direction can be WTRU content access, which can include data deserialization. For example, WTRU content access can include: buffer management inputs, including message priorities; and / or output buffer management outputs, including message priorities.

[0105] In some implementations, another parameter in the DL direction can be content decoding, which can include encoding parameter selection and execution.

[0106] In some implementations, another parameter in the DL direction can be post-processing, which can include, for example, pose correction, such as time warps used to adjust the latest user pose. For instance, post-processing can include error prediction calculations, which may result in useless time warps. For example, post-processing can include coarse-grained / fine-grained error prediction.

[0107] In some implementations, the parameters in the deep learning (DL) direction can be display-dependent, where the display can provide APIs to control display parameters, such as managing the power consumption of AR glasses. Some parameters can be adjusted. For example, refresh time (such as increasing the refresh time) reduces display task latency or delay. Processing latency, for example, depends on the amount of computing power configured for the application.

[0108] WTRU processing latency can depend on AS processing latency, and vice versa. For example, decoding latency can depend on encoding latency tasks on the AS, as well as different quality and / or partitioning parameters; post-processing latency can depend on scene update processing latency, which depends on the accuracy required to compute scene states (e.g., simplified mesh geometry for collision detection, accuracy of physical simulation); and / or display latency can depend on encoding latency tasks on the AS, where different image resolutions, frame rates, and / or bit rates result in different rendering latencies.

[0109] Figure 9 An example of device and server latency processing in System 900 is shown when rendering occurs at the UE / WTRU. Figure 8 In contrast, the distribution of processing tasks differs slightly. For example, encoding and decoding tasks are absent because the rendering task is not offloaded to the edge server but is part of the WTRU processing task. This reduces server processing latency 904 and round-trip application time latency 910. In some cases, processing at the UE / WTRU may take longer (e.g., rendering may take longer than decoding a compressed or encoded image), but the overall latency may be reduced due to the reduced server latency and the potential reduction in required network throughput (reduced reverse network time latency 906).

[0110] In some cases, WTRU and / or AS may configure, establish, or agree to disclose their ability to measure or adjust latency for any of the different processing tasks (as disclosed herein). For example, AS may indicate that it can consider latency measurements and / or adjustments for image / video processing tasks (e.g., scene updating, encoding, rendering) but not for distribution tasks (e.g., content access and delivery).

[0111] In some implementations, when the WTRU and / or AS can agree on a task latency measurement request, they can be configured with some or all of the following: maximum request frequency; measurement duration; measurement type (e.g., periodic, event-triggered); a measurement statistics pattern defining how latency measurements are performed and corresponding parameters (e.g., standard deviation, mean, median, maximum); and / or the number of latency measurements and reporting periodicity. For example, the WTRU may observe latency reaching a lower or upper limit within a certain duration, or may measure latency reaching a given limit several times. The goal may be to avoid measurement errors or peak variations that the application can handle within a specific duration.

[0112] In some implementations, WTRU and / or AS can be configured with delay budget characteristics such as: standard deviation / variance; average deviation / variance; median deviation / variance; minimum and maximum deviation / variance; and / or probability distributions (e.g., Gaussian distribution, normal distribution), including a set of probability values.

[0113] In some implementations, WTRU and / or AS can agree on task adjustment requests, and they can be configured to: maximum delay adjustment request frequency; delay adjustment reduction; delay adjustment increase; delay prediction, including confidence estimation; and / or delay ranges or thresholds reached (e.g., lower and upper limits, useless lower limit, critical upper limit).

[0114] Figure 10An example flowchart 1000 for QoE management is shown. As illustrated, this flowchart addresses at least two scenarios: WTRU-centric QoE management, where the client is the WTRU and the server is the application server; and server-centric QoE management, where the client is the application server and the server is the WTRU. At 1002, the client can calculate / estimate / determine the application QoE by monitoring and managing both client and server processing task latency. The client may need to enable server processing task latency measurement and adjustment. At 1004, the client can send a request for "server processing task latency" measurement and / or adjustment within an application data unit of the client-to-server flow (e.g., within an application data unit carrying user gestures and / or user interaction input data). At 1006, the server can extract the request from the application data unit received from the client, process the request, and measure and / or adjust the requested latency parameter or task. In some implementations, the server may perform only some of the requested adjustments and / or measurements. At 1008, the server may send a response or reply including measurements and / or confirmation or acknowledgment of ongoing adjustments within the application data unit of the server-to-client stream (such as within the application data unit of a buffered frame). At 1010, the client may extract the response from the application data unit received from the server and process it. At this point, the process may return to 1002. The restart of the process can be dynamic or periodic. The restart of the process can also be based on predetermined / pre-configured thresholds for latency, tasks, and / or QoE values.

[0115] Figure 11 An example of a high-level call flow 1100 for split rendering with WTRU-centric QoE management is shown. As described above (e.g., in conjunction with...) Figure 6 As described, there may be an architecture for a split rendering application, in which the split rendering client (SRC) communicates with the split rendering server (SRS) to enable split rendering services for XR. Figure 11 An example implementation of QoE management centered on the WTRU is described, in which the SRC's WTRU manages the intended application QoE according to a flowchart. The WTRU's XR source management function sends a request to the SRS for measurement and / or adjustment of "server processing task latency" within an application data unit carrying user gestures and / or user input data. Furthermore, the SRS can send a response or reply, including the measurements and / or adjustments performed, within the application data unit of a buffered frame.

[0116] therefore, Figure 6 The process and flow 600 shown, along with the related description, can be enhanced using one or more techniques, such as... Figure 11As shown. At point 1, in some implementations, the rendering engine can discover or identify the Split Render Server (SRS) and establish a connection with it. The rendering engine can provide information about its rendering capabilities and XR configuration (e.g., OpenXR or a similar protocol or standard). At point 2, in some implementations, in response, the SRS can create a description of the split rendering output and the inputs it expects to receive from the WTRU. The WTRU and SRS can configure, establish, or agree to expose processing task latency measurements and adjustments as described herein for fine-grained QoE management. At point 3, in some implementations, the rendering engine can request a buffered stream from the MAF, which can then establish a connection with the SRS to stream pose or interaction information and retrieve the split rendering buffer.

[0117] In the rendering loop, at point 4, in some implementations, the XR source manager can retrieve pose and user input from the XR runtime. At point 5a, in some implementations, the source manager can share pose prediction and user input actions with the SRS. The source manager can insert requests for server-processed task delay measurements and / or adjustments within the pose prediction and user input action groups. In some implementations, the source manager can insert measurement requests (and monitor responses) in several groups or requests to determine which adjustments can be made, and then insert delay or task adjustment requests. At point 6, in some implementations, the SRS can use this information to render frames. The SRS process server can extract and process task delay measurement and / or adjustment requests from application data units. At point 7a, in some implementations, the rendered frames can be encoded and streamed to the MAF. The SRS process server can insert identifiers of completed task delay measurements and / or adjustments within the rendered frames (e.g., within the options field of the header, within the Packet Data Unit (PDU) header extension, within the payload, or anywhere else within the data stream). At point 8, in some implementations, the MAF can decode and process buffered frames. The MAF can extract task latency measurements and / or adjustment acknowledgments or information from the application data unit and process responses. At point 9, in some implementations, the MAF can pass buffered frames to the scene manager and / or the XR runtime. At point 10, the renderer of the XR runtime and / or SRC can composite and render the received frames.

[0118] Figure 12 An example of a high-level call flow 1200 for split rendering for application server-centric QoE management is shown. This diagram illustrates an example of application server-centric QoE management where the SRS manages the intended application QoE. While similar to... Figure 11In process 1100, but in process 1200, at 7b, in some implementations, the SRS sends a request for WTRU processing task delay measurement and / or adjustment to the WTRU within the application data unit of the buffer frame. Furthermore (in subsequent loop iterations), at 5b, in some implementations, the WTRU's XR source management function sends a response, including the ongoing requested measurement or adjustment, within the application data unit carrying user posture and / or user input information.

[0119] Figure 13 An example flowchart of method 1300 for QoE management according to some implementations is shown. At 1302, a device such as a WTRU, UE, application server, rendering server, split rendering server, split rendering client, XR headset, wearable computing device, smartphone, portable computer, or any other such device can generate application data units. In some implementations, application data units may include gestures (head tracking, eye tracking, hand tracking, controller tracking, body tracking, etc.) and / or interaction information (controller buttons or dials, gestures, eye-tracking interactions, etc.) and may be sent to the server by the WTRU or other client device. In some implementations, application data units may include scene and / or image information, media data, physical information, encoded images, fields, frames, or portions of images, fields, or frames, or other image or media data and may be sent to the WTRU or other client device by the server. In some implementations, application data units may include task latency measurements, resource consumption measurements, processing or memory consumption measurements, timestamps, or other such data. In some implementations, the application data unit may include a positive acknowledgment (ACK) or a negative acknowledgment (NACK) of one or more requested delay parameter adjustments or processing adjustments, error codes or other such information.

[0120] At 1304, in some implementations, the apparatus may measure local processing latency. Measuring local processing latency may include measuring the start and end times of processing tasks, such as generating application data units, loading data into a buffer for transmission, decoding information in a buffer, rendering a frame or a portion of a frame, computing physical interactions, or any other such processing task. In some implementations, the apparatus may monitor other resources, including processing resources, memory resources, and network resources (e.g., throughput, bandwidth, block error rate, congestion indication, retransmission count, round-trip time, etc.). In some implementations, the measurement may be inserted at 1302 into the application data unit for transmission (e.g., in the next iteration of method 1300).

[0121] In some implementations at 1306, the device may request one or more remote latency measurements. A remote latency measurement request may include a request for another device (e.g., a client or server) to measure the start and end times of a processing task, such as generating an application data unit, loading data into a buffer for transmission, decoding information in a buffer, rendering a frame or a portion of a frame, calculating physical interactions, or any other such processing task. In some implementations, the measurement request may include a request to measure other resources, including processing resources, memory resources, and network resources (e.g., throughput, bandwidth, block error rate, congestion indication, retransmission count, round-trip time, etc.). The remote latency measurement request may be sent at 1306 or inserted into the application data unit at 1302 for transmission.

[0122] In some implementations, at 1308, the device may receive an application data unit including the requested remote measurement. In some implementations, the application data unit may include other data, such as gesture and / or interaction information, or scene and / or image information, confirmation or negative confirmation of adjustment or processing of one or more requested delay parameters, error codes, or other such information. In some implementations, the device may extract the measurement and / or processing adjustment. In some implementations, the application data unit may include notification or confirmation of the requested adjustment to be taken by the device (e.g., a local adjustment, rather than a remote adjustment).

[0123] At 1310, in some implementations, the apparatus (e.g., WTRU / server) can determine whether other apparatus (e.g., server / WTRU) has requested adjustments, such as in the received application data unit. Such an adjustment request may not exist in the first iteration of method 1300, but it may exist in subsequent iterations of method 1300. In some implementations, the apparatus can determine to ignore or refuse to perform the requested adjustment. In other implementations, at 1312 or 1314, the apparatus can apply the requested adjustments, such as increasing or decreasing resolution, bit depth, gaze angle, shader quality, buffer size, grouping priority, etc., as discussed above. For example, at 1312, the apparatus can increase local processing. In some implementations, this can reduce remote processing by other apparatuses. For example, the WTRU can enable or activate the local rendering engine, allowing the server to disable rendering and only serve scene or environment data. This can reduce server latency and, in some implementations, reduce network bandwidth requirements and associated latency. In other implementations, the device can increase local processing due to the high QoE, such as by increasing the gazing window, increasing resolution, or bit depth. In another example, at 1314, the device can reduce local processing. In some implementations, this can increase remote processing by other devices. For example, one device can disable its local rendering engine and instruct another device to perform rendering. In other implementations, the device can reduce local processing by decreasing quality, reducing depth of field, decreasing resolution, shrinking the gazing window, etc.

[0124] If no local adjustment is indicated in the received application data unit, at 1316, the device may determine whether the local measurement and / or remote measurement indicates that the QoE is less than a first threshold t1 (or the delay is higher than the first threshold t1). If so, local processing may be increased at 1312 via any of the methods discussed above. In some implementations, the device may also determine at 1320 that a corresponding remote processing adjustment is needed, and generate a request for remote processing adjustment at 1322, which may be sent in a subsequent application data unit at 1302 (e.g., enabling local rendering at 1312 and disabling remote rendering at 1322).

[0125] If the QoE is not less than a first threshold t1, then at 1318, the device can determine whether local and / or remote measurements indicate that the QoE is higher than a second threshold t2 (or the latency is lower than the second threshold t2). If so, local processing can be reduced at 1314 via any of the methods discussed above. In some implementations, the device can also determine at 1320 that a corresponding remote processing adjustment is needed, and generate a request for remote processing adjustment at 1322, which can be sent in a subsequent application data unit at 1302 (e.g., disabling local rendering at 1314 and enabling remote rendering at 1322).

[0126] If the QoE is between the thresholds, then in some implementations, it is possible not to adjust the local device or not to request adjustment from the remote device, and another iteration of 1300 can be performed.

[0127] Tables 1 through 4 provide examples of the syntax and semantics of the JSON format used for QoE requests and responses. Other formats, semantics, and / or syntaxes (e.g., XML data, parameter-value pairs, concatenated strings, data arrays, etc.) may be utilized in various implementations.

[0128] Task latency measurement requests and responses can consist of several fields. In some implementations, the messages can be in JSON format and can follow the syntax and semantics shown in Table 1.

[0129]

[0130] Table 1: Task Delay Measurement Requests and Responses In some implementations, the content of the measured object can be presented in the following format as shown in Table 2.

[0131]

[0132] Table 2: Contents of the Measurement Object Task delay adjustment requests and responses can consist of several fields. In some implementations, the message can be in JSON format and can follow the syntax and semantics shown in Table 3.

[0133]

[0134] Table 3: Task Delay Adjustment Requests and Responses In some implementations, adjusting the content of an object can be done using the following format shown in Table 4.

[0135]

[0136] Table 4: Content of the Adjusted Object In a first aspect, this disclosure relates to a method for measuring and managing task latency for XR processing. Depending on the stream, this method can be implemented by a client / server. A client (e.g., a WTRU or AS) can interact with a server (e.g., a WTRU or AS), or the server can interact with the client; in either case, the potential purpose of the interaction may be in the context of running an XR application. The client can send a measurement request associated with server processing latency for one or more tasks. The client can receive a measurement of the server processing latency for the one or more tasks in response to the measurement request (e.g., where the measurement is performed at the server). The client can calculate the Extended Reality (XR) application Quality of Experience (QoE) based on the measurement of the server processing latency for the one or more tasks. The client can send an adjustment request for the server processing latency of the one or more tasks based on the XR application QoE. In some cases, the measurement request is sent within an application data unit, where the application data unit is related to user gestures or user interaction inputs associated with the XR application. In response to the measurement request, the client can receive the completed processing latency for the one or more tasks. In some cases, the adjustment request is sent within an application data unit, where the application data unit is related to user gestures or user interaction inputs associated with the XR application. In some cases, in response to the adjustment request, the client receives an adjustment confirmation confirming that adjustments to the server processing latency of the one or more tasks have been completed at the server, and sends a second measurement request to determine whether the adjustment has reduced the server processing latency of the one or more tasks (e.g., by comparing a first calculated QoE with a second calculated QoE, or by comparing the QoE with a threshold).

[0137] In a second aspect, this disclosure relates to a method. The method includes sending a request from a first device to a second device for a measurement of processing latency associated with one or more tasks. The method also includes receiving a response from the second device by the first device, the response including the measurement of processing latency associated with the one or more tasks. The method further includes calculating the Quality of Experience (QoE) for an extended reality (XR) application by the first device based on the received measurement of processing latency associated with the one or more tasks. The method also includes sending a request from the first device to the second device, based on the XR application QoE, to adjust processing parameters of at least one of the one or more tasks.

[0138] In some implementations, at least one task includes a portion of a server-client operation performed by a second device, and the method includes adjusting processing parameters of the corresponding portion of the server-client operation performed by the first device. In yet another implementation, at least one task includes media encoding, and the corresponding portion includes media decoding.

[0139] In some implementations, the request to adjust processing parameters includes a request to disable rendering of the XR media by the second device. In yet another implementation, the method further includes enabling rendering of the XR media by the first device.

[0140] In some implementations, the request to adjust processing parameters includes: a request to reduce the quality of the XR media in response to a calculated XR application QoE falling below a first threshold. In other implementations, the request to adjust processing parameters includes: a request to increase the quality of the XR media in response to a calculated XR application QoE falling above a second threshold.

[0141] In some implementations, a request to measure processing latency is sent within an application data unit, and the application data unit includes data on user gestures or user interaction inputs related to the XR application. In some implementations, a request to adjust processing parameters of at least one task is sent within the application data unit, and the application data unit includes data on user gestures or user interaction inputs related to the XR application. In some implementations, the method includes: receiving a response from a second device confirming completion of the adjustment of processing parameters for at least one task in response to the request to adjust processing parameters for at least one task; and sending a second request from the first device to the second device to measure processing latency associated with one or more tasks.

[0142] In another aspect, this disclosure relates to a wireless transmit / receive unit (WTRU) configured to perform at least a portion of any of the methods disclosed above. In another aspect, this disclosure relates to at least one processor operatively connected to a transceiver, the processor and the transceiver being configured to perform at least a portion of any of the methods disclosed above. In another aspect, this disclosure relates to a network element configured to perform at least a portion of any of the methods disclosed above. In another aspect, this disclosure relates to a server configured to perform at least a portion of any of the methods disclosed above. In another aspect, this disclosure relates to a network node in a 5G network configured to perform at least a portion of any of the methods disclosed above. In another aspect, this disclosure relates to an application server configured to perform at least a portion of any of the methods disclosed above.

[0143] In variations of one or more examples disclosed herein (e.g., Figure 1B An XR processing engine architecture may exist, which can be configured to implement the methods described herein. The WTRU can be connected to other devices via its bus and / or via I / O interfaces. The WTRU may include one or more of the following elements connected together via data and address buses: a microprocessor (or CPU), such as a DSP (or digital signal processor); ROM (or read-only memory); RAM (or random access memory); a storage interface; an I / O interface for receiving data to be transferred from an application; an integrated graphics processing unit (GPU); a dedicated GPU; and a power supply (e.g., a battery). In one case, the power supply is external to the WTRU. The WTRU can use various internal and / or external components to generate, modify, alter, enhance, display, etc., extended reality, augmented reality, and / or virtual reality. For example, the WTRU may utilize a CPU and GPU to generate scenes that may include interactive elements, objects, other users, etc. The WTRU may present this on its display or via a wired or wireless connection through an external display. The external display may include headphones / glasses / helmets with displays for each eye or a single display for both eyes. As discussed herein, headphones, glasses, helmets, and wearable displays can be interchangeable. In some cases, the WTRU itself can be glasses and / or part of glasses, and can have hardware configurations (e.g., regarding displays as disclosed herein) for displaying AR / XR / VR experiences. Regardless of the configuration (e.g., external or internal display), any configuration of the hardware and display (built-in or external) can be referred to as WTRU glasses.

[0144] In each of the mentioned memories, the term "register" as used herein can correspond to a small area (a few bits) or a very large area (e.g., an entire program or a large amount of received or decoded data). ROM includes at least a program and parameters. ROM can store algorithms and instructions to perform techniques according to the principles of the invention. When powered on, the CPU uploads the program to RAM and executes the corresponding instructions. RAM includes the program executed by the CPU and uploaded after the device is powered on, input data, intermediate data for different states of the method, and other variables for executing the method in the registers. WTRU can, for example, be connected via a bus to a set of sensors and a set of rendering devices. Sensors can be, for example, cameras, microphones, temperature sensors, inertial measurement units, GPS, humidity sensors, IR or UV light sensors, or wind sensors. Rendering devices can be, for example, displays, speakers, vibrators, heaters, fans, etc.

[0145] Refer again to the variants of WTRU (e.g., such as...) Figure 1B As shown, a scene sequence (e.g., such as a 3D scene and / or an XR scene) can be provided to the encoder. The encoder can take a scene or scene sequence as input and provide a bitstream representing the input. The bitstream can be stored in memory and / or on an electronic data medium and can be transmitted over a network. The bitstream representing the scene sequence can be read from memory and / or received from the network by the decoder. The decoder is input to the bitstream and provides the scene sequence, for example, in point cloud format.

[0146] An encoder may include several circuits implementing several steps. In a first step, the encoder projects each scene onto at least one image (e.g., a 2D image). Scene projection is any method of mapping at least three-dimensional points to a smaller dimension (such as a two-dimensional plane). For example, this type of projection can be used in methods for displaying graphic data based on two-dimensional media (e.g., pixel information from several bit planes) in computer graphics, engineering, and drafting. The projection circuitry provides at least one two-dimensional frame for the sequence of scenes. The frame includes color information and depth information representing the scene projected onto the frame. In variations, color information, lighting information, and / or depth information may be encoded in separate frames.

[0147] Metadata can be used and updated by the projection circuitry. Metadata may include information about projection operations (e.g., projection parameters) and / or information about how other information is organized within the frame.

[0148] The video encoding circuit encodes a sequence of frames into video. Scene images and / or sequences of scene images can be encoded into the stream by the video encoder. Video data and metadata can then be encapsulated into the data stream by data encapsulation circuitry.

[0149] For example, encoders conform to encoders such as: JPEG, specification ISO / CEI 10918-1 UIT-T Recommendation T.81; AVC, also known as MPEG-4 AVC or h264. HEVC (T Recommendation, H Series, h265); 3D-HEVC (an extension of HVEC, T Recommendation, H Series, h265); VP9; and / or AV1 (AOMedia Video 1) are specified in UIT-T H.264 and ISO / CEI MPEG-4 Part 10 (ISO / CEI14496-10).

[0150] The data stream can be stored in memory accessible by the decoder via, for example, a network. The decoder may include different circuitry implementing different steps of decoding. The decoder can take the data stream generated by the encoder as input and provide scene sequences for rendering and display by a volumetric video display device (such as a WTRU and / or head-mounted display (HMD)). The decoder can obtain the stream from a source. For example, the source may belong to the following categories: local memory, such as video memory or RAM (or random access memory), flash memory, ROM (or read-only memory), hard disk; storage interfaces, such as interfaces to mass storage devices, RAM, flash memory, ROM, optical discs, or magnetic support; communication interfaces, such as wired interfaces (e.g., bus interfaces, WAN interfaces, LAN interfaces) or wireless interfaces (such as IEEE 802.11 interfaces or Bluetooth® interfaces); and user interfaces, such as graphical user interfaces that enable users to input data.

[0151] The decoder may include circuitry for extracting data encoded in a data stream. The circuitry may take the data stream as input and provide metadata and two-dimensional video corresponding to the metadata encoded in the stream. The video may be decoded by a video decoder that provides a sequence of frames. The decoded frames include information (e.g., color and depth information, and / or any information disclosed herein). In a variant, the video decoder provides two frame sequences, one including color information and the other including depth information. The circuitry uses the metadata to deproject the information from the decoded frames to provide a scene sequence. The scene sequence may have potential accuracy losses related to encoding as 2D video and video compression.

[0152] The principles of the invention will now be described more fully below with reference to the accompanying drawings, in which examples of the principles of the invention are shown. However, the principles of the invention can be embodied in many different forms and should not be construed as limited to the examples set forth herein. Therefore, while the principles of the invention are readily available in various modifications and substitutions, specific examples of the principles of the invention are shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the principles of the invention are not intended to be limited to the specific forms disclosed; rather, this disclosure will cover all modifications, equivalents, and alternatives falling within the spirit and scope of the principles of the invention as defined in the appended claims.

[0153] The terminology used herein is for the purpose of describing particular examples only and is not intended to limit the principles of the invention. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that the terms “comprising,” and / or “including,” as used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Furthermore, when an element is referred to as “in response to” or “connected to” another element, it may be directly “in response to” or “connected to” the other element, or there may be intermediate elements present. Conversely, when an element is referred to as “directly in response to” or “directly connected to” another element, there are no intermediate elements present. As used herein, the terms “and / or” include any and all combinations of one or more of the associated listed items and may be abbreviated to “ / .”

[0154] It will be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the teachings of the principles of the invention.

[0155] Although some diagrams include arrows along the communication path to indicate the main communication direction, it should be understood that communication may occur in the opposite direction to the arrows depicted.

[0156] The block diagrams and operation flowcharts describe some examples, where each block represents a circuit element, module, or code section comprising one or more executable instructions for implementing a specified logical function. It should also be noted that in other implementations, the functions mentioned in a block may occur out of order. For example, depending on the functions involved, two blocks shown consecutively may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order.

[0157] The phrases “according to an example” or “in an example” used herein mean that a particular feature, structure, or characteristic described in connection with that example may be included in at least one implementation of the principles of the invention. The phrases “according to an example” or “in an example” appearing in different places in the specification do not necessarily refer to the same example, nor are they necessarily separate or alternative examples that are mutually exclusive with other examples.

[0158] The reference numerals appearing in the claims are merely illustrative and should not be construed as limiting the scope of the claims. Although not explicitly described, examples and variations of the invention may be used in any combination or sub-combination.

[0159] As described herein, a higher layer can refer to one or more layers in a protocol stack, or a specific sublayer within a protocol stack. A protocol stack can consist of one or more layers in a WTRU or network node (e.g., eNB, gNB, other functional entities, etc.), where each layer can have one or more sublayers. Each layer / sublayer can be responsible for one or more functions. Each layer / sublayer can communicate directly or indirectly with one or more other layers / sublayers. In some cases, these layers can be numbered, such as Layer 1, Layer 2, and Layer 3. For example, Layer 3 can contain one or more of the following: Non-Access Stratum (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 can contain one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Media Access Control (MAC). For example, Layer 3 can contain Physical (PHY) layer type operations. The higher the layer number, the higher its level relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the examples above can themselves be referred to as layers / sublayers, regardless of layer numbering, and can be referred to as higher layers as described herein. For example, from highest to lowest, a higher layer can refer to one or more of the following layers / sublayers: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference herein to a higher layer in connection with a process, apparatus, or system will refer to a layer above that process, apparatus, or system. In some cases, a reference to a higher layer herein can refer to a function or operation performed by one or more layers described herein. In some cases, a reference to a higher layer herein can refer to information transmitted or received by one or more layers described herein. In some cases, a reference to a higher layer herein can refer to configurations transmitted and / or received by one or more layers described herein.

[0160] Although features and elements have been described above in specific combinations (e.g., embodiments, methods, examples, etc.), those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. For example, as disclosed herein, a method may be described in conjunction with the accompanying drawings for illustrative purposes, and those skilled in the art will understand that one or more features or elements in this method may be used alone or in combination with one or more features in another method described elsewhere. The symbol “ / ” (e.g., a forward slash) may be used herein to mean “and / or,” for example, “A / B” may mean “A and / or B.” As used herein, “a” and “an” and similar phrases shall be interpreted as “one or more” and “at least one.” Similarly, any term ending with the suffix “(s)” shall be interpreted as “one or more” and “at least one.” The term “may” shall be interpreted as “may, for example,” or indicating that something “does happen” or “can happen.” Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multifunction disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method executed by a client device for processing task latency measurement and adjustment, the method comprising: Send a request for a measurement of processing latency associated with one or more tasks within an application data unit, wherein the application data unit includes data on user gestures associated with an extended reality XR application or data on user interaction inputs associated with the XR application; Receive a response, the response including a measurement of processing latency associated with the one or more tasks; The XR application experience quality (QoE) is calculated based on the received measurement of processing latency associated with the one or more tasks. as well as Based on the XR application QoE, a request is sent to adjust the server processing latency of at least one of the one or more tasks.

2. The method of claim 1, wherein the at least one task includes a portion of a server-client operation performed by the server, and the method further includes the client device adjusting the processing latency of a corresponding portion of the server-client operation performed by the client device.

3. The method of claim 2, wherein the at least one task includes media encoding, and the corresponding portion includes media decoding.

4. The method of claim 1, wherein the request to adjust processing latency includes disabling the request for rendering of XR media by the server, and the method further includes enabling rendering of XR media by the client device.

5. The method of claim 1, wherein the request to adjust the processing delay includes: In response to a request to reduce the quality of XR media when the calculated QoE of the XR application is below a first threshold.

6. The method of claim 1, wherein the request to adjust the processing delay comprises: In response to a request to improve the quality of XR media when the calculated QoE of the XR application is higher than a second threshold.

7. The method of claim 1, wherein the request for measurement of processing latency is sent within the application data unit, wherein the application data unit includes data on user gestures related to the XR application or data on user interaction input related to the XR application.

8. The method according to claim 1, further comprising: In response to the request to adjust the processing delay of at least one task, a response confirming that the adjustment of the processing delay of the at least one task is complete is received from the server; as well as Send a second request for a measurement of the processing latency associated with one or more tasks.

9. A wireless transmit and receive unit (WTRU) configured to process task delay measurement and adjustment, the WTRU comprising: processor; A transceiver, communicatively connected to the processor, wherein the processor and the transceiver are configured to: Send a request for a measurement of processing latency associated with one or more tasks within an application data unit, wherein the application data unit includes data on user gestures associated with an extended reality XR application or data on user interaction inputs associated with the XR application; Receive a response, the response including a measurement of processing latency associated with the one or more tasks; The XR application experience quality (QoE) is calculated based on the received measurement of processing latency associated with the one or more tasks. as well as Based on the XR application QoE, a request is sent to adjust the server processing latency of at least one of the one or more tasks.

10. The WTRU of claim 9, wherein the at least one task includes a portion of a server-client operation performed by the server, and the processor and the transceiver are further configured to adjust the processing latency of a corresponding portion of the server-client operation, wherein the at least one task includes media encoding, and the corresponding portion includes media decoding.

11. The WTRU of claim 9, wherein the request to adjust processing latency includes a request to disable rendering of XR media by the server, and the processor and the transceiver are further configured to enable rendering of XR media.

12. The WTRU of claim 9, wherein the request to adjust the processing delay includes: In response to a request to reduce the quality of XR media when the calculated QoE of the XR application is below a first threshold.

13. The WTRU of claim 9, wherein the request to adjust the processing delay includes: In response to a request to improve the quality of XR media when the calculated QoE of the XR application is higher than a second threshold.

14. The WTRU of claim 9, wherein the request for measurement of processing latency is transmitted within the application data unit, wherein the application data unit includes data on user gestures related to the XR application or data on user interaction input related to the XR application.

15. The WTRU of claim 9, wherein the processor and the transceiver are further configured to: In response to the request to adjust the processing latency of at least one task, receive from the server a response confirming that the adjustment of the processing latency of the at least one task is complete; and Send a second request for a measurement of the processing latency associated with one or more tasks.

Images