EP4690743A1

EP4690743A1 - Methods for server processing task delays measurements and adjustments

Info

Publication number: EP4690743A1
Application number: EP24718395.7A
Authority: EP
Inventors: Stephane Onno; Loic FONTAINE; Patrice Hirtzlin; Etienne FAIVRE D'ARCIER
Original assignee: InterDigital CE Patent Holdings SAS
Current assignee: InterDigital CE Patent Holdings SAS
Priority date: 2023-04-07
Filing date: 2024-04-05
Publication date: 2026-02-11
Also published as: IL323796A; KR20250167106A; WO2024209097A1; CN121241553A

Abstract

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

Description

METHODS FOR SERVER PROCESSING TASK DELAYS MEASUREMENTS AND ADJUSTMENTS

RELATED APPLICATIONS

[0001] The present application claims the benefit of, and priority to, European Patent Application No. 23305532.6, entitled “Methods for Server Processing Task Delays Measurements and Adjustments,” filed April 7, 2023, the entirety of which is incorporated by reference herein.

BACKGROUND

[0002] Extended reality, such as augmented reality, virtual reality, mixed reality, and related realities may frequently require a lot of processing power and bandwidth. For example, to reduce weight, complexity, and power consumption of wearable devices such as extended reality glasses, some implementations offload video processing to a remote device (e.g. a portable computer, laptop computer, or even via a wireless network to a server or virtual cloud of servers). However, even with powerful computing devices, processing time and network throughput limitations can result in significant delays that adversely affect the user’s quality of experience (QoE). For example, latency in video of more than 20-50 milliseconds may be readily noticeable and impair immersion, cause nausea, etc. Measuring this latency as an end-to-end delay may be too coarse to provide actionable insight to mitigate the delay and improve performance.

SUMMARY

[0003] To address these and other problems with extended reality (XR) scenarios, implementations of the methods, devices, and/or systems disclosed herein provide for fine grained delay measurement and processing adjustments. For example, reducing trip time for messages being sent and received between an XR wireless transmit receive unit (WTRU) and a server may improve QoE, and delay measurements may indicate precisely where delays are occurring and how they may be mitigated. Actions may then be taken, including shifting processing tasks between the local and remote device, to take advantage of the lowest additional delay. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0005] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed techniques may be implemented;

[0006] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRLI) that may be used within the communications system illustrated in FIG. 1A according to one or more approaches disclosed herein;

[0007] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (ON) that may be used within the communications system illustrated in FIG. 1A according to one or more approaches disclosed herein;

[0008] FIG. 1D is a system diagram illustrating a further example RAN and a further example ON that may be used within the communications system illustrated in FIG. 1A according to one or more approaches disclosed herein;

[0009] FIGs. 2A and 2B illustrate examples of target use cases for WTRLI glasses, according to some implementations;

[0010] FIG. 3 illustrates an example of a Standalone AR WTRLI (STAR)-based 5G interactive immersive service architecture, according to some implementations;

[0011] FIG. 4 illustrates an example of Edge-Dependent AR WTRLI (EDGAR)-based 5G interactive immersive service architecture, according to some implementations;

[0012] FIG. 5 illustrates an example of split management architecture, according to some implementations;

[0013] FIG. 6 illustrates an example of high-level call flow for split rendering, according to some implementations;

[0014] FIG. 7 illustrates an example of potential time delays in a system, according to some implementations;

[0015] FIG. 8 illustrates an example of device and server processing delay tasks breakdown for Edge processing, according to some implementations;

[0016] FIG. 9 illustrates an example of device and server processing delay tasks breakdown for standalone processing, according to some implementations;

[0017] FIG. 10 illustrates an example of a flow chart for QoE management, according to some implementations [0018] FIG. 11 illustrates an example of High-level call flow for split rendering for a WTRU- centric QoE management, according to some implementations;

[0019] FIG. 12 illustrates an example of High-level call flow for split rendering for an Application Server-centric QoE management, according to some implementations; and

[0020] FIG. 13 illustrates an example flow chart of a method for QoE management, according to some implementations.

DETAILED DESCRIPTION

[0021] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may 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 Spread OFDM (ZT-UW- DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0022] As shown in FIG. 1A, the communications 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, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 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 a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0023] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0024] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (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 wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

[0025] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0026] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSU PA).

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

[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface 116 using NR.

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0031] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellularbased RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0032] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0033] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0035] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRLI 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. [0036] The processor 118 may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRLI 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0037] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

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

[0039] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRL1 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRLI 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0040] The processor 118 of the WTRLI 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRLI 102, such as on a server or a home computer (not shown).

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

[0042] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRLI 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRLI 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRLI 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like. [0044] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the 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 selfinterference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0045] FIG. 10 is a system diagram illustrating the RAN 104 and the ON 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the ON 106.

[0046] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0047] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1C, the eNode- Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0048] The ON 106 shown in FIG. 1C 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 depicted as part of the ON 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the ON operator.

[0049] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA. [0050] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0051] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0052] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0053] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0054] In representative embodiments, the other network 112 may be a WLAN.

[0055] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0056] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every ST A), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0057] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0058] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0059] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11 ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (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 may support Meter Type Control/Machine-Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, 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 sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0061] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0062] FIG. 1 D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

[0064] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).

[0065] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non- standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0066] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0067] The CN 106 shown in FIG. 1 D 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. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator. [0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AM F 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

[0069] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a U PF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0070] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0071] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0072] In view of FIGs. 1 A-1 D, and the corresponding description of FIGs. 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a- b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0073] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications.

[0074] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0075] 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 may apply equally to interactive immersive services, XR, AR, VR, and MR, and many implementations may be interchangeable. Accordingly, discussion of specific embodiments or implementations in relation to XR may apply equally and without limitation to VR, for example.

[0076] A WTRU may correspond to any XR device/node that may take one or more form factors, as described herein. In addition to the definitions already provided herein, a WTRU (e.g., where WTRU may be interchangeable with XR WTRLI) may include, but is not limited to, Head Mounted Displays (HMD), 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 positional tracking and camera, wearables, and the like. Additionally, there may be different types of XR WTRUs that may be based on XR device functions, such as one or more of the following features/capabilities: displays, cameras, sensors, sensor processing, wireless connectivity, XR/Media processing, and/or power supply. These additional features/capabilities may be internal, and/or external; in an instance where they are external, they may be provided and/or accompanies by one or more devices, wearables, actuators, sensors, controllers, and/or accessories. One or more XR WTRUs may be grouped into a collaborative XR group for supporting any number of XR applications, experiences, and/or services.

[0077] In some cases, such as XR with interactivity experience, a WTRU (e.g., an XR WTRU) may interact with an XR server running on an edge computing node to offload the computationally intensive tasks, such as video rendering or scene state calculation (e.g., including physics simulation). In an example, the XR WTRU may transmit tracking, sensor information, gesture information, pose information, and/or interactivity information in an Up Link (UL) to an XR server. In turn, the XR server may generate the XR Scene based on the transmitted information from the XR WTRU. The XR Server may rasterize the XR viewport and perform XR pre-rendering and generate XR media that is encoded and delivered to the XR WTRU in a Down Link (DL). The XR WTRU device may decode the XR media, perform latest pose correction to address any changes in the pose, and render the XR viewport. As discussed herein, application flows may be between more than 2 devices (e.g., WTRU <-> Edge <-> Server). Everything behind the edge server may be abstracted as “processing” by the edge server. Further, the terms edge and cloud may be interchangeable (e.g., edge server may be equivalent to cloud server). In some cases, edge server and application server (AS) may be interchangeable, unless otherwise specified.

[0078] As discussed above, XR implementations may frequently require a lot of processing power and bandwidth. For example, to reduce weight, complexity, and power consumption of wearable devices such as extended reality glasses, some implementations offload video processing to a remote device (e.g. a portable computer, laptop computer, or even via a wireless network to a server or virtual cloud of servers). However, even with powerful computing devices, current available processing and memory capabilities, processing time and network throughput limitations can result in significant delays that adversely affect the user’s quality of experience (QoE). For example, XR applications may have strict round-trip requirements to provide an acceptable Quality of Experience (QoE) for the end-user, such as motion to photon of 20ms, and/or roundtrip interaction delay of 50ms for Ultra-low latency applications. Latency of more than this may be readily noticeable and impair immersion, cause nausea, etc. Measuring this latency as an end-to-end delay may be too coarse to provide actionable insight to mitigate the delay and improve performance.

[0079] In some implementations, to address these and other problems with extended reality (XR) scenarios, implementations of the methods, devices, and/or systems disclosed herein provide for fine grained delay measurement and processing adjustments. For example, reducing trip time for messages being sent between an XR wireless transmit receive unit (WTRLI) and a server may improve QoE, and delay measurements may indicate precisely where delays are occurring and how they may be mitigated. Actions may then be taken, including shifting processing tasks between the local and remote device, for example between a WTRLI and an application server, to take advantage of the lowest additional delay.

[0080] For example, rendering an XR video or scene may require offloading processing to a more powerful compute unit when a WTRLI does not have sufficient computing power. The following examples illustrated in FIGs. 2A and 2B show two use-cases where it may be beneficial to perform the processing at an edge server to meet the XR QoE requirements.

[0081] FIG. 2A illustrates an example of a target use case 200 for one or more approaches described herein. In some cases, an optical-see through device 202 (e.g., XR glasses, which may be a type of WTRLI) may have limited computing and battery resources. When the user runs an AR application, the AR glasses 202 may communicate in a standalone manner or via a smartphone (e.g., a second WTRLI, not illustrated) that captures and transmits its user-pose (e.g. head position and/or rotation, viewing direction or angle, positions of hands, fingers, and/or controllers, etc.) to an Edge application server 204. In turn, the server application processes a video stream to render based on the received pose and sends this back, possibly via a smartphone, to the AR glasses 202 where the video stream may be rendered on the glasses. In another use-case 200’ shown in FIG. 2B, a video-see through device 202’ (e.g., a VR headset, which may be a type of WTRLI) may transmit a first video stream to the Edge server 204, which computes overlaid graphical information on the top of the received video before sending back the rendered video stream to the VR headset 202’ (again, potentially via a second WTRLI).

[0082] In some system architectures for interactive immersive services (e.g., XR and the like), there may be different scenarios regarding how workflow is handled between a XR WTRLI and a Cloud/Edge server. For example, in some systems (e.g., 5G) there may be a Standalone AR (STAR) WTRLI scenario and/or an Edge (server) dependent AR (EDGAR) WTRLI scenario.

[0083] FIG. 3 illustrates an example of a STAR-based interactive immersive service architecture 300. Similarly, FIG. 4 illustrates an example of an EDGAR-based interactive immersive service architecture 400. In this case, most of the rendering may be accomplished on the server 404.

[0084] In some use cases, like shared interactive immersive services, a user interaction may be sent from a WTRLI to a server. The server handles this request by altering the immersive media scene based on the interaction (e.g., changing the context such as translation, rotation, scaling, and/or adding/interacting/altering an object in the scene).

[0085] Referring first to FIG. 3, with a STAR scenario 300, a LIE-XR client or WTRLI 302 may execute an XR runtime process 312, which may communicate with an XR application 310 (e.g. a media viewer, a video game, a productivity application, etc.) for providing functionality. The XR runtime process 312 may serve as an interface to hardware components of the LIE-XR client or WTRLI 302, including sensors (e.g. IMlls, accelerometers, buttons, dials, etc.) and cameras or microphones, and output components such as actuators (e.g. linear or rotational actuators for “rumble” or haptic effects, or other types of actuators), displays, speakers or headphones, etc. XR source management 314 may comprise a service, server, sub-routine, or other executable logic for interacting with the XR runtime 312 and XR application 310 to fulfill requests for media data, and may control whether the request is provided by a local scene manager 320, presentation engine 322, and Tenderer 324, and/or a remote scene manager 330 on an XR server 304.

[0086] For example, in some implementations, LIE-XR client 302 may detect pose information or user interactions and may transmit this information via a media access function or application data protocol 316 (e.g. application, session, and/or transport layer protocols) via a network interface card 318 to a server 304 (which may comprise a virtual server or cloud application server provided by one or more physical computing devices) over a network 306 (e.g. wired network, wireless network, a combination of wired and wireless networks, etc.). In some instances, the user interaction may be a single event that is utterly asynchronous from other data flows. Furthermore, the frequency of occurrence of the interaction event may depend on the type of interaction and the use case.

[0087] An XR application 328 executed by the server 304 may process the pose information and user interactions (e.g. via a scene manager 330 and graph handler 332) to generate a processed scene, which may include additional media assets 336 and/or commands for actuators or other functions directed by XR function 334) and sends back to the WTRLI (via media delivery function 326 protocols and NICs 318), the processed scene in the form of a scene description update or a full new scene description. The scene manager 320 may parse the update and/or scene description to generate a view or image for a presentation engine 322, which may use renderer(s) 324 to render the scene to the displays. [0088] Referring to FIG. 4, with the EDGAR scenario 400, which may also be known as split rendering, the WTRLI 402 may offload some or all of the scene rendering to the server 404. In such implementations, the XR application 428 of the server may comprise a Tenderer 440 (similar to Tenderer 324) which may rasterize the XR viewport and render image(s) of the XR media to be encoded and delivered to the WTRLI for presentation by the displays. For example, high resolution complex ray-traced environments may require significant processing power to accurately calculate reflections and occlusion, while decoding and displaying the resulting video bitstream may be relatively easier. By moving this processing to a high-powered edge server 404, the client 402 may require less power and/or processor resources, resulting in extended battery life, lower weight, etc. Additionally, processing on the edge server 404 may be highly scalable, with dynamic parallel processing of scenes (e.g. distributing groups of pictures, frames, or even macroblocks to different virtual servers for rendering, etc.). Media asset storage 436 may be offloaded to dedicated storage servers or application providers 440, similarly aiding scalability of processing and rendering by the server.

[0089] FIG. 5 illustrates an example of split management architecture 500, with a LIE-XR client or WTRLI 502 and a data network (DN) 504, which may comprise one or more servers (e.g. application providers, split rendering servers, and in some implementations, network nodes providing a real time communication application function (RTC AF), collectively referred to as an application service or AS. In some cases, split rendering media service enabler may define the required formats and/or protocols to make split rendering accessible to media service and application providers. The end-to-end architecture may be depicted as shown, with the WTRLI 502 including functions as illustrated on the left-hand side, and the data network 504 including functions illustrated on the right-hand side. There may be, collectively between the WTRLI 502 and the DN 504, one or more of the following functions: Split-Rendering Client (SRC) 506, where this function is responsible for acquiring the WTRLI media capabilities and negotiating, via a media session handler 516, with the RTC (real-Time Communication) AF 510 to agree on the split-rendering process at the RTC AF; Split-Rendering Server (SRS) 508, where this function is responsible for negotiation of split rendering (SR) session with the SRC 506, monitoring the server’s edge resource usage, and managing/running the split rendering process; Application Function (AF) 510, where this function may be responsible for provisioning, QoS allocation, and edge resource discovery. Application Service Provider 512, which is the application provider that offers the service; XR Application 514, which is the application running on the WTRLI; and/or, the Media Session Handler (MSH) 516, which is the entity on the WTRLI that is responsible for the control plane communication with the AF 510.

[0090] FIG. 6 illustrates an example of high-level call flow 600 for split rendering. There may be one or more possible scenarios, where the WTRLI is the client and the AS is the server, or the AS is the client and the WTRLI is the server, for example. At 1 , the Presentation Engine may discover the split rendering server and may set up a connection to it. The presentation engine may provide information about its rendering capabilities and the XR runtime configuration (e.g., the OpenXR configuration, which may be used for this purpose). At 2, in response, the split rendering server may create a description of the split rendering output and the input it expects to receive from the WTRLI. At 3, the Presentation Engine may request the buffer streams from the MAF (Media Access Function), which in turn establishes a connection to the split rendering server to stream pose information and retrieve split rendering buffers. At 4, as part of the rendering loop, the Source Manager may retrieve pose and user input from the XR runtime. At 5, the Source Manager may share the pose predictions and user input actions with the split rendering server. At 6, the split rendering server may use that information to render the frame. At 7, the rendered frame may be encoded and streamed down to the MAF. At 8, the MAF may decode and process buffer frames. At 9, the MAF may pass raw buffer frames to the presentation engine and/or the XR runtime. At 10, the XR runtime may compose and render the received frame to the displays. [0091] FIG. 7 illustrates an example of potential time delays in a system 700, including communications delays for transmission of data to the server 702; server side delays of buffering, processing, and transmitting responses or other data to the client 704; communications delays for transmission of data back to the client 706; and buffering, processing, and rendering the data at the client 708. The combination of the first three delays 702-706 can be measured as a round trip time 710 (e.g. from transmission of a request or pose information until receipt of processed frame or scene information). Real time communications and protocols are primarily used to meet the real time requirements and when these requirements are not met, the resulting packet losses may result in a poor QoE for the end-user. The QoE requirements for the end-user, including high quality content in time, strict RTT delays such as motion-to-photon, etc., cannot be solved by only post-processing operations such as pose correction or asynchronous time-warping to mitigate such network bandwidth fluctuations.

[0092] The application may have means to compute overall WTRLI and Server processing delays 710 according to FIG. 7 by adjusting processing at the UE, modifying communications protocols, etc., but may have no idea of the detailed QoE impact of the individual application processing steps, such as rendering and/or encoding that form part of the server side delay 704. Therefore, the application has no way to act on processing steps in real time and accordingly to adjust parameters that affect the QoE.

[0093] Implementations of the systems and methods discussed herein address these and other issues by providing techniques and protocols to measure and adjust operations on either end (e.g. UE/WTRU or server) or both ends, to reduce time delay(s) that may cause poor QoE for XR services/experiences. In one or more implementations of these systems, devices, and/or methods, a WTRU and/or an Application Server (AS) (WTRU/AS) may apply one or more QoE(s), transmit one or more task delay measurement(s), and/or task delay adjustment request(s) by inserting one or more requests within application data unit(s) from one device (WTRU/AS) to the other. In turn, the WTRU/AS may transmit their processing task delay measurements and/or adjust responses. As discussed herein, reference to the phrase “processing task delay” may be interchangeable with a similar phrase where one or more of these words are pluralized and the specific recitation of this phrase in any of the possible forms is not intended to be limiting, wherein the different permutations are interchangeable and may be as follows: processing task delay, which is the delay for processing an individual task; processing tasks delay, which is the delay for processing several tasks, where the delay may represent a combination of contiguous or noncontiguous tasks; processing task delays, which is a plurality of delays for processing an individual task; processing tasks delays, which is a plurality of delays for processing several task. For all of the aforementioned examples, there may be one or more measurements and/or adjustments (e.g., there may be a request for one or several measurements at a time, and different compositions of tasks; e.g., there may be a composition of different tasks delays measurements). Additionally, any reference to a single delay or task may be interchangeable with a plurality of delays or tasks, respectively.

[0094] In one case, a WTRU may compute WTRU processing task delay and may request from the Application Server (AS), one or more measurements and adjustments of the AS processing task delay.

[0095] The WTRU may calculate the QoE from its measured processing task delay and/or the AS processing task delay measurements received from the AS. The WTRU may compute the AS and WTRU task delay adjustments to meet the expected application QoE and then, adjust WTRU processing task delay and/or requests processing task delay adjustments from the AS.

[0096] In an example, a WTRU may transmit “AS processing task delay” requests in an application data unit to the AS in a first flow. The requests may comprise one or more actions to be performed by the AS, such as: measurements of AS processing task delay, to be performed by the AS; adjustments of AS processing task delay, to be performed by the AS; transmission of AS processing task delay measurements, from the AS to the WTRU; and/or, transmission of AS processing task delay adjustments, from the AS to the WTRU.

[0097] In an example, an AS may transmit “AS processing task delay” responses in application data unit to the WTRU in a second flow. The answers may comprise one or more of: measurements of AS processing task delay, and/or, adjustments of AS processing task delay done in the AS. [0098] In one case, the Application Server (AS) may compute AS processing task delay and may request from the WTRLI measurements and/or adjustments of WTRLI processing task delay. [0099] The AS may calculate the QoE from its measured processing task delay and/or the WTRLI processing task delay measurements received from the WTRLI. The AS may compute the WTRLI and AS task delay adjustments to meet the expected application QoE and then, adjust AS processing task delay and/or request processing task delay adjustments from the WTRLI.

[0100] In an example, an AS may transmit “WTRLI processing task delay” requests in application data unit to the WTRLI in a first flow. The requests may comprise actions to perform by the WTRLI: measurements of WTRLI processing task delay, to be performed by the WTRLI; adjustments of WTRLI processing task delay, to be performed by the WTRLI; transmission of WTRLI processing task delay measurements, from the WTRLI to the AS; and/or, transmission of the WTRLI processing task delay adjustments, from the WTRLI to the AS.

[0101] In an example, a WTRLI may transmit “WTRLI processing task delay” responses in application data unit to the AS in a second flow. The answers may comprise one or more of: measurements of WTRLI processing task delay, adjustments of WTRLI processing task delay done in the WTRLI.

[0102] In some implementations, a delay measurement may be calculated as the difference between the measured end time of a task minus the measured beginning time of the task. Although, the measurement may be not very precise from an application perspective, it may provide an average deviation of the delay. Other measurements may be used, such as the beginning time of a task to the beginning time of a next task, or end to end.

[0103] In some implementations, a delay adjustment request may indicate to decrease or to increase or “relax” a processing task delay. Decreasing a delay may trigger the server and/or WTRLI to decrease a visual quality (e.g. by modifying a bit-depth; resolution; frame rate; depth of field; foveation angle or central angle within which a scene is rendered at higher quality relative to areas beyond the central angle (accounting for reduced visual acuity); shader or texture quality; or any other type and form of adjustment) to meet the required latency. Conversely, relaxing a delay or allowing a delay to increase may suggest increasing the quality when the expected latency or QoE is met. Accordingly, in some implementations, a QoE and/or delay may be calculated and compared to one or more thresholds. If the QoE is below a first threshold (or delay is above a first threshold), then the delay may be decreased or visual quality reduced; if the QoE is above a second threshold (or delay is below a second threshold), then the delay may be relaxed or visual quality increased. In some implementations, if the QoE or delay is between these thresholds, the quality may be maintained. This may provide some hysteresis and prevent sudden visual changes or processing changes, which may add their own delays due to the change or overhead (e.g. discarding already-processed frames at one resolution to re-process the frames at a new resolution, etc.).

[0104] In some implementations, a delay adjustment response may report the effective adjustment or adjustment feedback that the AS or the WTRLI applies regarding the requested adjustments. The response may include additional adjustment information, for example an indication on why the adjustment has not been done or was partially done.

[0105] In some implementations, the QoE may be associated with a round-trip application delay requirement such as a motion-to-photon time limit. The fine grain task delay measurements and the related deviations measured after each round-trip may highlight metrics that cause the end user visual quality QoE.

[0106] In one instance, WTRLI processing task delay and/or AS processing task delay may vary according to a processing delay range(s) between a minimum and maximum delay value. This depends on different processing task parameters, as described in herein. The WTRLI and the AS may configure, establish, and/or agree on parameters values range applicable to the different processing task adjustments. The WTRLI and the AS may configure how the delay varies from updating parameters values.

[0107] In some implementations, a WTRLI and the AS may configure, establish, and/or agree on a processing delay budget such as: an expected standard/median delay budget; delay budget adjustment ranges (min, median, max); and/or delay budget thresholds to trigger sending a message (critical lower limit, critical upper limit), such as the QoE or delay thresholds discussed above.

[0108] Processing delay budgets may be characterized in one or more ways, in various implementations. For example, in some implementations, a delay budget may be characterized by the entire AS or WTRLI processing delay 704, 708 as described in FIG. 7. For the AS, delay 704 may comprise the content access, scene update, rendering, encoding, and/or content delivery delay. For the WTRLI, delay 708 may comprise uplink and/or downlink processing tasks (e.g., uploading or transmitting, pose & user interaction, content delivery, downloading or receiving, content access, decoding, post processing, display, etc.). Note that some of these delays may occur after detection of a user interaction that modifies a scene and prior to transmission of pose or interaction information; and some may occur after reception of a rendered scene or rendering instructions or a bitstream and prior to display.

[0109] In a more granular implementation, a delay budget may be characterized by individual AS and/or WTRLI processing task delays, for example, a rendering task delay at the AS. For example, a delay budget may be characterized by association of different tasks performed at the same location, but in some instances the tasks may not be contiguous. For instance, tasks such as: image/video processing tasks including scene update, rendering and encoding; WTRLI Content access and delivery; AS content access and delivery; and/or any other type and form of task.

[0110] In some implementations, a delay budget may be characterized by the association of different tasks processing on/at different locations. The association may denote a correlation between the different tasks. The association may be used for QoE measurements on the AS or on the WTRLI and for associated tasks QoE adjustments. For example, changing the encoder configuration can affect both encoding and decoding delays. For instance, tasks such as: content distribution from WTRLI to AS including WTRLI content delivery and AS content access; content distribution from AS to WTRLI including AS content delivery and WTRLI content access; encoding/decoding chain including AS encoding and WTRLI decoding; round trip distribution including both WTRLI and AS content delivery and content access; AR specific tasks including either pose and/or interaction and/or scene update; or any other such tasks.

[0111] FIG. 8 illustrates an example of device and server processing delay times in a system using Edge processing 800, broken down into fine grained detail. As shown, an overall server processing task delay 804 may be a result of several individual task delays, referred to variously as task delays, processing delays, parameters or delay parameters, or by other similar terms.

[0112] For example, in some implementations, a parameter may be server content access, which may include data deserialization. In one instance, it may be aperiodic, where there may be input event handling priority, and/or there may be output message processing priority. In one instance, it may be periodic, where there may be input buffer scheduling priority, input scheduling periodicity such as frequency, and/or, output message processing priority.

[0113] For example, in some implementations, a parameter may be scene update, which may be the update of the scene graph according to the received data (e.g., by taking in account for example physics of the environment, interactions of the user and/or other entities with each other or objects, etc.). For instance, the level of accuracies for the calculation of the scene state may comprise a parameter that affects the delay. The scene update delay may be adjusted by increasing/decreasing the accuracy on the scene state (e.g., by using simplified mesh geometries for collision detection, by adjusting the accuracy of the physics simulation).

[0114] For example, in some implementations, a parameter may be rendering. This may include: image resolution, frame rate, bit rate, foveation angle, and/or selecting the level of details to render high-visual quality objects and/or having a spatial partitioning of huge virtual scene, or any other such rendering adjustment or parameter. [0115] For example, in some implementations, a parameter may be encoding. This may include adjustments to a codec profile or type, compression ratio or type, quality parameter, or partitioning parameters, or any other such parameters that may adjust coding latency or delays.

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

[0117] WTRU processing task delays depicted in FIG. 8 may similarly depend on various specific parameters.

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

[0119] In some implementations, a parameter in the DL (post-transmission) direction may be WTRLI content access, which may include data deserialization. For instance, WTRLI content access may include: input of buffer management including message priority, and/or output of output buffer management including message priority.

[0120] In some implementations, another parameter in the DL direction may be content decoding, which may include encoding parameters selection and enforcement.

[0121] In some implementations, another parameter in the DL direction may be postprocessing, which may include, for example, pose correction, such as time warping for adjusting the latest user-pose. For instance, post-processing may include error prediction calculation, which may result in making useless time warping. For instance, post-processing may include coarse grain/fine grain error prediction.

[0122] In some implementations, a parameter in the DL direction may be display related, where the display may provide an API to control display parameters, for example to manage the power consumption of AR glasses. Some parameters may be adjusted. For instance, the refresh time such as increasing the refresh time reduce the display task delay or latency. For instance, processing delay depending on the amount of computation power configured for an application. [0123] A WTRU processing task delay may depend on the AS processing task delay and vice versa, for example: a decoding delay may depend on encoding delay task on AS, with different quality and/or partitioning parameters; a post processing delay may depend on a scene update processing delay, which depends on the required accuracies for the calculation of the scene state (e.g., simplified mesh geometries for collision detection, accuracy of physics simulation); and/or, a display delay may depend encoding delay task on AS, with different rendering delay with different image resolution, frame rate and/or bit rate.

[0124] FIG. 9 illustrates an example of device and server processing delay times in a system 900 with rendering at the UE/WTRU. The distribution of processing tasks differs slightly as compared to FIG. 8. For example, encoding and decoding tasks are absent, since the rendering task is not offloaded to the Edge server and is part of the WTRU’s processing tasks. As a result, the server processing delay 904 and round trip application time delay 910 is shortened. In some instances, processing at the UE/WTRU may take more time (e.g. rendering may take more time than decoding a compressed or encoded image), but the overall delay may be reduced due to the reduced server delay and potentially smaller network throughput required (reducing reverse network time delay 906).

[0125] In some cases, the WTRU and/or the AS may configure, establish, or agree to expose their capabilities regarding any of the different processing task delay measurements or adjustments (as disclosed herein). For example, the AS may indicate it may consider delay measurements and/or adjustments for the image/video processing (e.g., scene update, encoding, rendering) tasks but not distribution tasks (e.g., content access and delivery).

[0126] In some implementations, when the WTRU and/or the AS may agree on task delay measurement requests, they may configure some or all of: the maximum request frequency; the duration of measurements; the type of measurement (e.g., periodic, event triggered); the measurement statistics mode defining how the delay measurement is done, and corresponding parameters (e.g., standard deviation, average, median, maximum); and/or the number of times to measure a delay and reporting periodicity. For example, the WTRU may observe that a delay reaches a lower bound limit or an upper bound limit for a certain duration or may measure several times that the delay reaches a given limit. The objective may be to avoid measurement error or peak variations that the application may cope with for a certain duration.

[0127] In some implementations, the WTRU and/or the AS may configure delay budget characteristics such as: standard deviation/variation; average deviation/variation; median deviation/variation; minimum and maximum deviation/variation; and/or, probability distribution (e.g., gaussian, Normal) including a set of probability values. [0128] In some implementations, the WTRU and/or the AS may agree on task adjustments request, and they may configure: the maximum delay adjustment request frequency; delay adjustment decrease; delay adjustment increase; delay prediction including confidence estimation; and/or, delay range or threshold reached (e.g., lower and upper bound, useless lower limit, critical upper limit)

[0129] FIG. 10 illustrates an example of a flow chart 1000 for QoE management. As shown, the flow chart addresses at least two cases: a WTRU-centric QoE management where the client is the WTRLI, and the server is an Application Server; and a server-centric QoE management, where the client is an Application Server, and the server is the WTRLI. At 1002, a Client may compute/calculate/determine the application QoE by monitoring and managing both Client and server processing tasks delays. The Client may need to enable server processing tasks delays measurement and adjustments. At 1004, the Client may send a request for “server processing task delay” measurements and/or adjustments within an application data unit of a Client to server flow, for example within an application data unit carrying a user pose and/or user Interaction input data. At 1006, the Server may extract the request from application data unit received from the Client, process the request, and perform measurements of and/or adjustments to the requested delay parameters or tasks. In some implementations, the server may perform only some of the requested adjustments and/or measurements. At 1008, the server may transmit an answer or response comprising the measurement(s) and/or an acknowledgement or confirmation of the adjustment(s) being done within an application data unit of a server to Client flow, such as within an application data unit of a buffer frame. At 1010, the Client may extract the response from the application data unit received from the server, and process the response. At this point, the process may return to 1002. The restarting of the process may be dynamic or periodic. The restarting of the process may also be based on a predetermined/preconfigured threshold of a delay, task, and/or QoE value.

[0130] FIG. 11 illustrates an example of High-level call flow 1100 for split rendering for a WTRLI centric QoE management. As described above (e.g., in connection with FIG. 6), there may be an architecture of a split rendering application where a Split-Rendering Client (SRC) communicates with a Split-Rendering Server (SRS) to enable a split rendering service for XR. FIG. 11 describes an example implementation of a WTRU-centric QoE management where the WTRU of SRC manages expected application QoE according to the flow diagram where the XR Source management function of the WTRU transmits a request for “server processing task delay” measurements and/or adjustments within an application data unit carrying user pose and/or user input data to a SRS. In turn, the SRS may transmit an answer or response comprising the measurement(s) and/or adjustment(s) done within an application data unit of a buffer frame. [0131] Accordingly, the procedures and flow 600 shown in FIG. 6 and the related description may be augmented with one or more techniques, as shown in FIG. 11. At 1 , in some implementations, the Presentation Engine may discover or identify the Split Rendering Server (SRS) and set up a connection to it. The Presentation Engine may provide information about its rendering capabilities and the XR configuration (e.g. OpenXR or similar protocols or standards). At 2, in some implementations, in response the SRS may create a description of the split rendering output and the input it expects to receive from the WTRLI. The WTRLI and the SRS may configure, establish, or agree to expose processing task delay measurements and adjustments as described herein for fine-grained management of the QoE. At 3, in some implementations, the Presentation Engine may request the buffer streams from the MAF, which in turn may establish a connection to the SRS to stream pose or interaction information and retrieve split rendering buffers.

[0132] In the rendering loop, at 4, in some implementations, the XR Source Manager may retrieve pose and user input from the XR runtime. At 5a, in some implementations, the Source Manager may share the pose predictions and user input actions with the SRS. The Source Manager may insert a request for server processing task delay measurements and/or adjustments within pose predictions and user input action packets. In some implementations, the Source Manager may insert measurement requests in several packets or requests (and may monitor responses) to determine which adjustments may be done, and then may insert delay or task adjustment requests. At 6, in some implementations, the SRS may use that information to render the frame. The SRS process server may extract the task delay measurements and/or adjustment requests from the application data unit and process the request. At 7a, in some implementations, the rendered frame may be encoded and streamed down to the MAF. The SRS process server may insert identifications of the task delay measurements and/or adjustments that have been done within rendered frames (e.g. within an options field of a header, with a packet data unit (PDU) header extension, within a payload, or anywhere else within the data stream). At 8, in some implementations, the MAF may decode and process buffer frames. The MAF may extract the task delay measurements and/or adjustment acknowledgements or information from the application data unit and process the answer. At 9, in some implementations, the MAF may pass the buffer frame to the scene manager and/or XR runtime. At 10, the XR runtime and/or a Tenderer of the SRC may compose and render the received frame.

[0133] FIG. 12 illustrates an example of High-level call flow 1200 for split rendering for an Application Server centric QoE management. The illustration shows an Application Server-centric QoE management example in which the SRS manages expected application QoE. While similar to flow 1100 of FIG. 11 , in flow 1200, at 7b, in some implementations, the SRS sends requests for WTRLI processing task delay measurements and/or adjustments within an application data unit of a buffer frame to the WTRLI. In turn (on a subsequent loop iteration), at 5b in some implementations, the XR Source management function of the WTRLI transmits an answer comprising the requested measurement(s) or the adjustment(s) being done within an application data unit carrying user pose and/or user input information.

[0134] FIG. 13 illustrates an example flow chart of a method for QoE management 1300, according to some implementations. At 1302, a device, such as a WTRLI, UE, Application Server, Rendering Server, Split Rendering Server, Split Rendering Client, XR headset, wearable computing device, smartphone, portable computer, or any other such device, may generate an application data unit. In some implementations, the application data unit may comprise pose (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 by a WTRLI or other client device to a server. In some implementations, the application data unit may comprise scene and/or image information, media data, physics information, encoded images, fields, frames, or portions of images, fields, or frames, or other image or media data, and may be sent by a server to a WTRLI or other client device. In some implementations, the application data unit may comprise task delay measurements, resource consumption measurements, processing or memory consumption measurements, timestamps, or other such data. In some implementations, the application data unit may comprise a positive acknowledgement (ACK) or negative acknowledgement (NACK) of one or more requested delay parameter adjustments or processing adjustments, error codes, or other such information.

[0135] At 1304 in some implementations, the device may measure local processing delays. Measuring local processing delays may comprise measuring a start and end time 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 portion of a frame, calculating physics interactions, or any other such processing task. In some implementations, the device may monitor other resources, including processing resources, memory resources, network resources (e.g. throughput, bandwidth, block error rates, congestion indications, retransmission numbers, round trip times, etc.). In some implementations, the measurements may be inserted into an application data unit for transmission at 1302 (e.g. on a next iteration of method 1300)

[0136] In some implementations at 1306, the device may request remote one or more remote delay measurements. Remote delay measurement requests may comprise a request to another device (e.g. client or server) to measure a start and end time 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 portion of a frame, calculating physics interactions, or any other such processing task. In some implementations, the measurement requests may comprise a request for measurements of other resources, including processing resources, memory resources, network resources (e.g. throughput, bandwidth, block error rates, congestion indications, retransmission numbers, round trip times, etc.). The remote delay measurement request may be transmitted at 1306 or inserted into an application data unit at 1302 for transmission.

[0137] In some implementations, at 1308, the device may receive an application data unit comprising the requested remote measurements. In some implementations, the application data unit may include other data, such as pose and/or interaction information, or scene and/or image information, acknowledgements or negative acknowledgements of one or more requested delay parameter adjustments or processing adjustments, error codes, or other such information. The device may extract the measurements and/or processing adjustments in some implementations. In some implementations, the application data unit may include requested adjustments for the device to take (e.g. local adjustments, rather than notification or confirmation of remote adjustments).

[0138] At 1310, in some implementations, the device (e.g. WTRU/server) may determine whether an adjustment has been requested by the other device (e.g. server/WTRU), such as in a received application data unit. In a first iteration of method 1300, such an adjustment request may be absent, but it may be present in further iterations of method 1300. In some implementations, the device may determine to ignore or decline to perform the requested adjustment. In other implementations, at 1312 or 1314, the device may apply the requested adjustment, such as increasing or decreasing a resolution, bit-depth, foveation angle, shader quality, buffer size, packet priority, etc., as discussed above. For example, at 1312, the device may increase local processing. In some implementations, this may reduce remote processing by the other device. For example, a WTRLI may enable or active a local rendering engine, such that a server may disable rendering and merely provide data of the scene or environment. This may reduce server delays and, in some implementations, network bandwidth requirements and associated delays. In other implementations, the device may increase local processing because the QoE is very high, such as increasing a foveation window, increasing a resolution or bit-depth, etc. In another example, at 1314, the device may decrease local processing. In some implementations, this may increase remote processing by the other device. For example, a device may disable a local rendering engine and direct the other device to perform rendering. In other implementations, the device may decrease local processing by reducing quality, decreasing a depth of field, lowering resolution, narrowing a foveation window, etc.

[0139] If no local adjustment is indicated in a received application data unit, then at 1316, the device may determine if the local measurements and/or remote measurements indicate a QoE is less than a first threshold h (or a delay is above a first threshold h). If so, then local processing may be increased at 1312 via any of the methods discussed above. In some implementations, the device may further determine at 1320 that a corresponding remote processing adjustment is needed, and at 1322 generate a request for remote processing adjustments which may be transmitted in a subsequent application data unit at 1302 (for example, enabling local rendering at 1312 and disabling remote rendering at 1322).

[0140] If the QoE is not less than the first threshold ti, then at 1318, the device may determine if the local measurements and/or remote measurements indicate a QoE is above a second threshold t2 (or a delay is below a second threshold t2). If so, then local processing may be decreased at 1314 via any of the methods discussed above. In some implementations, the device may further determine at 1320 that a corresponding remote processing adjustment is needed, and at 1322 generate a request for remote processing adjustments which may be transmitted in a subsequent application data unit at 1302 (for example, disabling local rendering at 1314 and enabling remote rendering at 1322).

[0141] If the QoE is between the thresholds, in some implementations, no adjustments may be made on the local device or requested from the remote device, and another iteration of 1300 may be performed.

[0142] Tables 1-4 provide examples of JSON formatted syntax and semantics for QoE requests and answers. Other formats, semantics, and/or syntaxes may be utilized in various implementations (e.g. XML data, parameter-value pairs, concatenated strings, data arrays, etc.). [0143] The task-delay-measurement requests and answers may be composed of several fields. The messages may be JSON formatted in some implementations, and may follow the syntax and semantics as shown in Table 1.

Table 1 : task-delay-measurements requests and answers

[0144] In some implementations, the contents of the measurement objects may utilize the following format shown in Table 2.

Table 2: content of measurement object

[0145] The task-delay-adjustments requests and answers may be composed of several fields. The messages may be JSON formatted in some implementations, and may follow the syntax and semantics as shown in Table 3.

Table 3: task-delay-adjustments requests and answers

[0146] In some implementations, the contents of the adjustment object may utilize the following format shown in Table 4.

Table 4: content of adjustment object

[0147] In a first aspect, the present disclosure is directed to a method for measurement and management of task delays for XR processing. The method may be implemented by a client/server depending on the flow. The client may (e.g., a WTRLI or AS) interact with a server (e.g., a WTRLI or AS), or the server may interact with the client; in either case, the underlying purpose of the interaction may be in the context of running an XR application. A client may send a measurement request associated with a server processing delay of one or more tasks. The client may receive a measurement of the server processing delay (of the one or more tasks in response to the measurement request (e.g., where the measurement is taken at the server). The client may calculate an extended reality (XR) application Quality of Experience (QoE) based on the measurements of the server processing delay of the one or more tasks. The client may send, based on the XR application QoE, an adjustment request for the server processing delay of the one or more tasks. In some instances, the measurement request is sent within an application data unit, wherein the application data unit is of a user pose related to the XR application or a user interaction input related to the XR application. A client may receive the processing delay that has been done of the one or more tasks in response to the measurement request. In some instances, the adjustment request is sent within an application data unit, wherein the application data unit is of a user pose related to the XR application or a user interaction input related to the XR application. In some instances, in response to the adjustment request, an adjustment confirmation is received by the client confirming an adjustment for the server processing delay of the one or more tasks at the server is completed, and a second measurement request is sent in order to determine if the adjustment reduced the server processing delay of one or more tasks (e.g., by comparing the first calculated QoE with the second calculated QoE, or comparing the QoE with a threshold).

[0148] In a second aspect, the present disclosure is directed to a method. The method includes sending, by a first device to a second device, a request for measurements of processing delays associated with one or more tasks. The method also includes receiving, by the first device from the second device, a response comprising measurements of processing delays associated with the one or more tasks. The method also includes calculating, by the first device, an extended reality (XR) application Quality of Experience (QoE) based on the received measurements of processing delays associated with the one or more tasks. The method also includes sending, by the first device to the second device based on the XR application QoE, a request to adjust a processing parameter of at least one task of the one or more tasks.

[0149] In some implementations, the at least one task comprises part of a server-client operation performed by the second device, and the method includes adjusting a processing parameter, by the first device, of a corresponding part of the server-client operation performed by the first device. In a further implementation, the at least one task comprises media encoding and the corresponding part comprises media decoding.

[0150] In some implementations, the request to adjust a processing parameter comprises a request to disable rendering of XR media by the second device. In a further implementation, the method includes enabling, by the first device, rendering of XR media by the first device.

[0151] In some implementations, the request to adjust a processing parameter comprises a request to reduce a quality of XR media, responsive to the calculated XR application QoE being below a first threshold. In other implementations, the request to adjust a processing parameter comprises a request to increase a quality of XR media, responsive to the calculated XR application QoE being above a second threshold.

[0152] In some implementations, the request for measurements of processing delays is sent within an application data unit, and the application data unit comprises data of a user pose related to the XR application or a user interaction input related to the XR application. In some implementations, the request to adjust a processing parameter of at least one task is sent within an application data unit, and the application data unit comprises data of a user pose related to the XR application or a user interaction input related to the XR application. In some implementations, the method includes receiving, from the second device in response to the request to adjust the processing parameter of at least one task, a response confirming an adjustment of the processing parameter of the at least one task is completed; and transmitting, by the first device to the second device, a second request for measurements of processing delays associated with one or more tasks.

[0153] In another aspect, the present disclosure is directed to a wireless transmit/receive unit (WTRLI) configured to perform at least part of any one of the above disclosed methods. In another aspect, the present disclosure is directed to at least one processor operatively connected to transceiver, the processor and transceiver configured to perform at least part of any one of the above disclosed methods. In another aspect, the present disclosure is directed to a network element configured to perform at least part of any one of the above disclosed methods. In another aspect, the present disclosure is directed to a server configured to perform at least part of any one of the above disclosed methods. In another aspect, the present disclosure is directed to a network node in a 5G network configured to perform at least part of any one of the above disclosed methods. In another aspect, the present disclosure is directed to an application server configured to perform at least part of any one of the above disclosed methods.

[0154] In a variation of one or more examples disclosed herein (e.g., FIG. 1 B) there may be an architecture of an XR processing engine which may be configured to implement the methods described herein. WTRLI may be linked with other devices via their bus and/or via I/O interface. WTRLI may comprise one or more following elements that are linked together by a data and address bus: a microprocessor (or CPU), which is, for example, a DSP (or Digital Signal Processor); a ROM (or Read Only Memory); a RAM (or Random Access Memory); a storage interface; an I/O interface for reception of data to transmit, from an application; an integrated graphics processing unity (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 may use the various internal and/or external components to generate, alter, modify, augment, display, or the like, an extended reality, an augmented reality, and/or a virtual reality. For example, the WTRU may utilize a CPU and a GPU to generate a scene that may contain interactive elements, objects, other users, or the like. The WTRU may present this on a display of the WTRU, or through an external display via a wired or wireless connection. An external display may comprise of a headset/glasses/helmet with displays for each eye, or one display for both eyes. As discussed herein, headset, glasses, helmet, wearable display, may be interchangeable. In some cases, the WTRU may itself be the glasses, and/or be a part of the glasses, and may have a hardware configuration (e.g., with respect to the displays as disclosed herein) to display an AR/XR/VR experience. Regardless of the configuration (e.g., external display or internal display), any configuration of hardware and display (built in or external) may be referred to as WTRU glasses.

[0155] In each of mentioned memory, the word “register” used herein may correspond to area of small capacity (some bits) or to very large area (e.g., a whole program or large amount of received or decoded data). ROM comprises at least a program and parameters. The ROM may store algorithms and instructions to perform techniques in accordance with present principles. When switched on, the CPU uploads the program in the RAM and executes the corresponding instructions. The RAM comprises, in a register, the program executed by the CPU and uploaded after switch-on of the device, input data in a register, intermediate data in different states of the method in a register, and other variables used for the execution of the method in a register. WTRU may be linked, for example via bus to a set of sensors and to a set of rendering devices. Sensors may be, for example, cameras, microphones, temperature sensors, Inertial Measurement Units, GPS, hygrometry sensors, IR or UV light sensors or wind sensors. Rendering devices may be, for example, displays, speakers, vibrators, heat, fan, and the like. [0156] Referring again to a variation of a WTRLI (e.g., as shown in FIG. 1 B), a sequence of scenes (e.g., such as 3D scenes and/or XR scenes), may be provided to an encoder. The encoder may take one scene or a sequence of scenes as input and provides a bit stream representative of the input. The bit stream may be stored in a memory and/or on an electronic data medium and may be transmitted over a network. The bit stream representative of a sequence of scenes may be read from a memory and/or received from a network by a decoder. Decoder is inputted by said bit stream and provides a sequence of scenes, for instance in a point cloud format.

[0157] Encoder may comprise several circuits implementing several steps. In a first step, encoder projects each scene onto at least one picture (e.g., 2D picture). Scene projection is any method of mapping at least three-dimensional points to a smaller dimension, such as a two- dimensional plane. For example, in methods for displaying graphical data based on planar (e.g., pixel information from several bit planes) two-dimensional media, the use of this type of projection may be used in computer graphics, engineering and drafting. A projection circuit provides at least one two-dimensional frame for a scene of sequence. A frame comprises color information and depth information representative of the scene projected onto frame. In a variant, color information, light information, and/or depth information may be encoded in separate frames.

[0158] Metadata may be used and updated by projection circuit. Metadata may comprise information about the projection operation (e.g., projection parameters) and/or about the way other information is organized within frames.

[0159] A video encoding circuit encodes sequence of frames and as a video. Pictures of a scene and/or a sequence of pictures of the scene, may be encoded in a stream by video encoder. Then video data and metadata may be encapsulated in a data stream by a data encapsulation circuit.

[0160] Encoder is for example compliant with an encoder such as: JPEG, specification ISO/CEI 10918-1 LIIT-T Recommendation T.81 ; AVC, also named MPEG-4 AVC or h264. Specified in both UIT-T H.264 and ISO/CEI MPEG-4 Part 10 (ISO/CEI 14496-10), HEVC (T recommendation, H series, h265); 3D-HEVC (an extension of HVEC, T recommendation, H series, h265); VP9; and/or AV1 (AOMedia Video 1).

[0161] The data stream may be stored in a memory that is accessible, for example through a network, by a decoder. Decoder may comprise different circuits implementing different steps of the decoding. Decoder may take a data stream generated by an encoder as an input and provides a sequence of scenes to be rendered and displayed by a volumetric video display device, such as a WTRLI and/or a Head-Mounted Device (HMD). Decoder may obtain the stream from a source. For example, source belongs to a set comprising: a local memory, such as a video memory or a RAM (or Random-Access Memory), a flash memory, a ROM (or Read Only Memory), a hard disk; a storage interface, such as an interface with a mass storage, a RAM, a flash memory, a ROM, an optical disc or a magnetic support; a communication interface, such as a wireline interface (for example a bus interface, a wide area network interface, a local area network interface) or a wireless interface (such as a IEEE 802.11 interface or a Bluetooth® interface); and a user interface such as a Graphical User Interface enabling a user to input data. [0162] Decoder may comprise a circuit for extracting data encoded in the data stream. Circuit may take a data stream as input and provide metadata corresponding to metadata encoded in the stream and a two-dimensional video. The video may be decoded by a video decoder which provides a sequence of frames. Decoded frames comprise information (e.g., color and depth information, and/or any information disclosed herein). In a variant, video decoder provides two sequences of frames, one comprising color information, the other comprising depth information. A circuit uses metadata to un-project information from decoded frames to provide a sequence of scenes. Sequence of scenes may have a possible loss of precision related to the encoding as a 2D video and to the video compression.

[0163] The present principles will be described more fully hereinafter with reference to the accompanying figures, in which examples of the present principles are shown. The present principles may, however, be embodied in many alternate forms and should not be construed as limited to the examples set forth herein. Accordingly, while the present principles are susceptible to various modifications and alternative forms, specific examples thereof are shown by way of examples in the drawings and will herein be described in detail. It should be understood, however, that there is no intent to limit the present principles to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present principles as defined by the claims.

[0164] The terminology used herein is for the purpose of describing particular examples only and is not intended to be limiting of the present principles. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising," "includes" and/or "including" when used in this specification, specify the presence of 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. Moreover, when an element is referred to as being "responsive" or "connected" to another element, it can be directly responsive or connected to the other element, or intervening elements may be present. In contrast, when an element is referred to as being "directly responsive" or "directly connected" to other element, there are no intervening elements present. As used herein the term "and/or" includes any and all combinations of one or more of the associated listed items and may be abbreviated as"/".

[0165] 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 only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element without departing from the teachings of the present principles.

[0166] Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0167] Some examples are described with regard to block diagrams and operational flowcharts in which each block represents a circuit element, module, or portion of code which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in other implementations, the function(s) noted in the blocks may occur out of the order noted. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending on the functionality involved.

[0168] Reference herein to “in accordance with an example” or “in an example” means that a particular feature, structure, or characteristic described in connection with the example can be included in at least one implementation of the present principles. The appearances of the phrase in accordance with an example” or “in an example” in various places in the specification are not necessarily all referring to the same example, nor are separate or alternative examples necessarily mutually exclusive of other examples.

[0169] Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims. While not explicitly described, the present examples and variants may be employed in any combination or sub-combination.

[0170] As described herein, a higher layer may refer to one or more layers in a protocol stack, or a specific sublayer within the protocol stack. The protocol stack may comprise of one or more layers in a WTRLI or a network node (e.g., eNB, gNB, other functional entity, etc.), where each layer may have one or more sublayers. Each layer/sublayer may be responsible for one or more functions. Each layer/sublayer may communicate with one or more of the other layers/sublayers, directly or indirectly. In some cases, these layers may be numbered, such as Layer 1 , Layer 2, and Layer 3. For example, Layer 3 may comprise of one or more of the following: Non-Access Stratum (NAS), Internet Protocol (IP), and/or Radio Resource Control (RRC). For example, Layer 2 may comprise of one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and/or Medium Access Control (MAC). For example, Layer 3 may comprise of physical (PHY) layer type operations. The greater the number of the layer, the higher it is relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the aforementioned examples may be called layers/sublayers themselves irrespective of layer number, and may be referred to as a higher layer as described herein. For example, from highest to lowest, a higher layer may refer to one or more of the following layers/sublayers: a NAS layer, a RRC layer, a PDCP layer, a RLC layer, a MAC layer, and/or a PHY layer. Any reference herein to a higher layer in conjunction with a process, device, or system will refer to a layer that is higher than the layer of the process, device, or system. In some cases, reference to a higher layer herein may refer to a function or operation performed by one or more layers described herein. In some cases, reference to a high layer herein may refer to information that is sent or received by one or more layers described herein. In some cases, reference to a higher layer herein may refer to a configuration that is sent and/or received by one or more layers described herein.

[0171] Although features and elements are described above in particular combinations (e.g., embodiments, methods, examples, etc.), one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. For example, as disclosed herein there may be a method described in association with a figure for illustrative purposes, and one of ordinary skill in the art will appreciate that one or more features or elements from this method may be used alone or in combination with one or more features from another method described elsewhere. A symbol 7’ (e.g., forward slash) may be used herein to represent ‘and/or’, where for example, ‘A/B’ may imply ‘A and/or B’. As used herein, ‘a’ and ‘an’ and similar phrases are to be interpreted as ‘one or more’ and ‘at least one’. Similarly, any term which ends with the suffix ‘(s)’ is to be interpreted as ‘one or more’ and ‘at least one’. The term ‘may’ is to be interpreted as ‘may, for example’ or indicate that something "does happen" or "can happen". In addition, 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 over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random-access memory (RAM), a register, 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 disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method, comprising sending, by a first device to a second device, a request for measurements of processing delays associated with one or more tasks; receiving, by the first device from the second device, a response comprising measurements of processing delays associated with the one or more tasks; calculating, by the first device, an extended reality (XR) application Quality of Experience (QoE) based on the received measurements of processing delays associated with the one or more tasks; and sending, by the first device to the second device based on the XR application QoE, a request to adjust a processing parameter of at least one task of the one or more tasks.

2. The method of claim 1 , wherein the at least one task comprises part of a server-client operation performed by the second device, and further comprising adjusting a processing parameter, by the first device, of a corresponding part of the server-client operation performed by the first device.

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

4. The method of claim 1 , wherein the request to adjust a processing parameter comprises a request to disable rendering of XR media by the second device.

5. The method of claim 4, further comprising enabling, by the first device, rendering of XR media by the first device.

6. The method of any preceding claim, wherein the request to adjust a processing parameter comprises a request to reduce a quality of XR media, responsive to the calculated XR application QoE being below a first threshold.

7. The method of any of claims 1 through 5, wherein the request to adjust a processing parameter comprises a request to increase a quality of XR media, responsive to the calculated XR application QoE being above a second threshold.

8. The method of any preceding claim, wherein the request for measurements of processing delays is sent within an application data unit, wherein the application data unit comprises data of a user pose related to the XR application or a user interaction input related to the XR application.

9. The method of any preceding claim, wherein the request to adjust a processing parameter of at least one task is sent within an application data unit, wherein the application data unit comprises data of a user pose related to the XR application or a user interaction input related to the XR application.

10. The method of any preceding claim, further comprising: receiving, from the second device in response to the request to adjust the processing parameter of at least one task, a response confirming an adjustment of the processing parameter of the at least one task is completed; and transmitting, by the first device to the second device, a second request for measurements of processing delays associated with one or more tasks.

11. The method of any preceding claim, wherein the measurements of processing delays associated with the one or more tasks comprise an average of a plurality of measurements of processing delays associated with a task, a minimum of a plurality of measurements of processing delays associated with a task, a maximum of a plurality of measurements of processing delays associated with a task, an average variation between a plurality of measurements of processing delays associated with a task, a minimum variation between a plurality of measurements of processing delays associated with a task, a maximum variation between a plurality of measurements of processing delays associated with a task, a periodic measurement of processing delays associated with a task, a measurement of processing delays associated with a task over a period of time, or a measurement of processing delays associated with a task sent responsive to a trigger.

12. A wireless transmit/receive unit (WTRLI) configured to perform at least part of any one of the methods of claims 1 through 11.

13. At least one processor operatively connected to transceiver, the processor and transceiver configured to perform at least part of any one of the methods of claims 1 through 11.

14. A network element configured to perform at least part of any one of the methods of claims 1 through 11.

15. A network node in a 5G network configured to perform at least part of any one of the methods of claims 1 through 11.