Methods and systems for quality-of-service measurement for extended reality media

Abstract

Methods and systems for initiating, configuring and measuring motion-to-photon quality of service (QoS) for an Extended Reality (XR) service. A user device generates media data based on a detected sensor input and inserts a first timestamp and QoS indicator into the packetized media data transmitted through an access network and control network to a digital world data processing function (DWDPF). The DWDPF processes the media data and generates and packetizes an XR media object. It inserts timestamps and the QoS indicator. Various network functions may insert their own timestamps during transit of the packets based on detection of the QoS indicator. The user device receives the XR media object, extracts the timestamps, determines QoS parameters and reports the QoS parameters.

Description

METHODS AND SYSTEMS FOR QUALITY-OF-SERVICE MEASUREMENT FOR EXTENDED REALITY MEDIA

[0001] CROSS-REFERENCE TO RELATED APPLICATION

[0002] The present application claims priority from U.S. Patent Application No. 63 / 674,015, filed on July 22, 2024 and incorporated herein by reference.FIELD

[0003] The present application relates to Extended Reality (XR) media and, in particular, to quality-of-service measurements for XR media.BACKGROUND

[0004] Quality of service (QoS) may be a significant factor in usability of XR media given it often operates on a “real-time” basis. QoS measurements, such as one-way and round-trip time packet delay, are important tools to monitor the network performance. While packet delay measurement is an important QoS performance for assessing the network performance, it may not provide QoS information particularly relevant to the usability of the XR services. It would be advantageous to provide for methods and systems to configure elements of a computing system to enable QoS performance monitoring so as to enable remedial actions to be taken to address detected excessive delay.

[0005] BRIEF SUMMARY

[0006] In accordance with one aspect, the present application describes a method of determining quality of service for Extended Reality (XR) media. The method may include, at a user device, obtaining data via a sensor; in response to obtaining the data, generating and transmitting a media object having a media payload and media metadata, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp; receiving, at the user device via a network connection, an XR media object associated with the media object; displaying, at a display time, on an output display of the user device, an image based on the XR media object; determining a motion-to-photon (MTP) delay based on a difference between the display time and the first timestamp; and transmitting a report regarding the MTP delay to a remote server.

[0007] In some implementations, determining the MTP delay includes detecting an association between the XR media object and the media object.

[0008] In some implementations, detecting the association includes matching a unique identifier in the media metadata with a corresponding unique identifier in metadata attached to the XR media object.

[0009] In some implementations, the media payload includes at least data regarding the data from the sensor.

[0010] In some implementations, the sensor includes an imaging device and wherein the data includes capture of image data by the imaging device, and the media payload includes the image data.

[0011] In some implementations, the XR media object includes media data, and displaying includes rendering the image on the output display based on the media data.

[0012] In some implementations, the XR media object includes metadata that includes the quality of service monitoring indicator and a server timestamp.

[0013] In some implementations, the XR media object includes a plurality of timestamps including the first timestamp, the server timestamp and a plurality of timestamps associated with one or more access network or core network functions.

[0014] In another aspect, the present application describes a method of determining quality of service for Extended Reality (XR) media. The method may include receiving, at a XR application server, a media object from a user device having a media payload and media metadata, the media payload being associated with data obtain via a sensor within the user device, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp; processing the media object to generate XR media data and creating an XR media object associated with the media object; adding a server timestamp to the XR media object and transmitting the XR media object to the user device; and receiving a communication from the user device containing a report of a  motion-to-photon (MTP) delay based on a difference between a display time of an image based on the XR media object on an output display of the user device and the first timestamp.

[0015] In yet another aspect, the present application describes a user device configured to determine quality of service for Extended Reality (XR) media. The device may include at least one processor; a sensor configured to obtain data and send the data to the at least one processor; an output display coupled to the at least one processor; memory coupled to the at least one processor and storing processor executable instructions that, when executed by the at least one processor, are to cause the at least one processor to: generate and transmit, in response to obtaining the data, a media object having a media payload and media metadata, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp; receive, via a network connection, an XR media object associated with the media object; display, at a display time, on the output display, an image based on the XR media object; determine a motion-to-photon (MTP) delay based on a difference between the display time and the first timestamp; and transmit a report regarding the MTP delay to a remote server.

[0016] In some implementations, the instructions, when executed, are to cause the at least one processor to determine the MTP delay by detecting an association between the XR media object and the media object.

[0017] In some implementations, detecting the association includes matching a unique identifier in the media metadata with a corresponding unique identifier in metadata attached to the XR media object.

[0018] In some implementations, the media payload includes the data from the sensor.

[0019] In some implementations, the sensor includes an imaging device and the data includes capture of image data by the imaging device, and the media payload includes the image data.

[0020] In some implementations, the XR media object includes media data, and the instructions, when executed, are to cause the at least one processor to display by rendering the image on the output display based on the media data.

[0021] In some implementations, the XR media object includes metadata that includes the quality of service indicator and a server timestamp.

[0022] In some implementations, the XR media object includes a plurality of timestamps including the first timestamp, the server timestamp and a plurality of timestamps associated with one or more access network or core network functions.

[0023] In yet a further aspect, the present application describes a computer-readable medium storing computer-executable instructions that, when executed by one or more processors, are to cause the one or more processors to carry out any one of the methods described.

[0024] In another aspect, the present application describes a computer program comprising instructions which, when executed by a computing device, are to cause the computing device to carry out any one of methods described herein.

[0025] In a further aspect, the present application describes a communication apparatus having means to perform any one of the methods described herein.

[0026] In yet a further aspect, the present application describes a communication apparatus having at least one processor and a memory coupled to the at least one processor, wherein the memory stores instructions that, when executed by the at least one processor, are to cause the apparatus to perform any one of the methods described herein.

[0027] Other aspects and features of the present application will be understood by those of ordinary skill in the art from a review of the following description of examples in conjunction with the accompanying figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Reference will now be made, by way of example, to the accompanying drawings in which:

[0029] FIG. 1 shows one example communication system that may be used in the context of an XR application;

[0030] FIG. 2 shows an example of such a communication system in the case of a 5G core network;

[0031] FIG. 3 shows illustrates an example of an apparatus in a communication system;

[0032] FIG. 4 shows examples of packetization formats;

[0033] FIG. 5 shows one example signal diagram illustrating a QoS measurement process involving multiple user devices;

[0034] FIG. 6 shows an example signal diagram illustrating a process for configurating a user device to perform an QoS measurement process;

[0035] FIG. 7 shows a signalling diagram illustrating activation of a QoS measurement process involving intermediate network functions;

[0036] FIG. 8 shows a signalling diagram illustrating a digital world control function originated QoW monitoring process;

[0037] FIG. 9 shows example method of routing QoS reports in various implementations;

[0038] FIG. 10 shows three example methods of access network-initiated QoS report routing; and

[0039] FIG. 11 shows an example signal diagram illustrating three illustrative methods of obtaining a QoS report from a digital world data processing function.

[0040] Like reference numerals are used in the drawings to denote like elements and features.DETAILED DESCRIPTION

[0041] Future mobile networks, such as sixth generation (6G) mobile networks, will provide new digital world (DW) services such as metaverse and augmented reality (AR) , virtual reality (VR) , and / or mixed reality (MR) . These may collectively be referred to as Extended Reality (XR) services or XR media. Quality of service (QoS) can be a significant factor in usability of XR media. In these DW services, the user equipment (UE) may send UE data, such as video, audio, text, and / or sensor data, to an XR application server. The XR application server may process the user data. After processing the user data, the XR application server may generate and send XR data (e.g. XR media) to the UE, such as rendered video and rendered audio data. It is important to minimize the total delay caused by data transmission and processing to avoid motion sickness.

[0042] QoS measurements, such as one-way and round-trip time packet delay, are important tools to monitor the network performance. While packet delay measurement is an important QoS performance for assessing the network performance, it may not provide QoS information particularly relevant to the usability of the XR services. A more relevant measurement for XR services may be termed the motion-to-photon (MTP) delay. The MTP delay is the delay between the time an action happens and the time the action is displayed at the viewer’s device (e.g. head mounted 3D glasses) . In many cases, an MTP delay of less than 20 ms is desirable to avoid motion sickness. The current packet delay measurement methods in fifth generation (5G) mobile networks do not provide MTP delay measurement.

[0043] End-to-end MTP delay may take into account the time T1 the action happens and the time T2 the action is displayed at the user device. Between times T1 and T2, there can be multiple events for an XR application. For example:

[0044] 1. The sensor (s) of user device captures data: for example, the user camera captures an image surrounding the user, or user’s face. In another example, one or more motion sensors may capture one or more movements of a user’s eyes, face, head, arms, legs, hands, and / or body. Other sensors may capture data relating to the user or the user’s environment in other examples.

[0045] 2. The UE sends packets of the captured data, e.g. an image or other sensor data, to an application server (AS) in the mobile network or data network for data processing via an access network (AN) .

[0046] 3. The AN forwards the received packets to the AS.

[0047] 4. The AS processes the sensor data, and creates XR data, e.g. an XR image, for example by combining the received sensor data with a virtual room of a museum, or by creating an avatar that matches with the emotion expression captured in the image and / or movement data and / or other sensor data sent by the UE.

[0048] 5. The AS sends packets of the XR image to the UE via the AN.

[0049] 6. The AN forwards the packets to the UE.

[0050] 7. The head mounted video display of user displays the XR image.

[0051] By measuring MTP delay, various components within the system may identify cases in which MTP delay exceeds a maximum threshold and may take remedial action. Remedial action may include, for example, allocating additional network resources, changing packet processing priority, reducing image or media resolution, throttling other streams, transmitting reports, notifications or warnings regarding the MTP delay, or any other such actions. The present application describes various methods, processes, systems and devices for measuring and reporting MTP delay. In some cases, the performance of particular network segments and data processing functions may be measured separately, so that the resource assignment for the network and AS can be optimized to meet the application QoS requirements.

[0052] In the following description, reference may be made to UEs, user device or electronic devices (EDs) . They should be understood to be equivalent terms and are interchangeable.

[0053] User device is used to connect persons, objects, machines, etc. The user device may be widely used in various scenarios including, for example, cellular communications, device-to-device (D2D) , vehicle to everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , MTC, internet of things (IoT) , virtual reality (VR) , augmented reality (AR) , mixed reality (MR) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0054] Each user device may include such devices (or may be referred to but not limited to) as a user equipment (UE) or a user device or a terminal device, a wireless transmit / receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus in (e.g. module, modem, or chip) or comprising the forgoing devices, among other possibilities. Future generation EDs 110 may be referred to using other terms. When an user device performs (or is configured to perform) a method described herein, it may be interpreted as the ED, one or more module (or units) in the ED, a circuit or chip, or a combination thereof, may perform the method. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, or system in package (SIP) ) , and the like, and may be responsible for one or more communication functions in the user device.

[0055] XR Services Infrastructure

[0056] Reference is now made to FIG. 1, which shows one example communication system 300 that may be used in the context of an XR application.

[0057] User equipment (UE) 302, such as smart phones, cell phones, tablets, laptops, or other computing devices, may be configured to connect over a communication channel to a mobile network 304. The mobile network 304 may include an access network (AN) 306 and a core network (CN) 308. The AN 306 may provide a wireless or wired interface, or both, for the UE 302 to connect with a data network (DN) 310, and network functions (NFs) of the AN 306 and CN 308. The AN 306 may include a radio management unit 312 and transmit (Tx) and receive (Rx) points 314 to support radio transmission and reception, and sensing functionalities.

[0058] The CN 308 may include one or more of following NFs:

[0059] A connection management function (CMF) 316 provides functionalities to support control plane (CP) signaling between the UEs 302, electronic devices, and NFs in the CN 308. The CMF 316 may also manage the mobility of UEs 302 or other electronic devices.

[0060] A session management function (SMF) 318 provides CP functionalities to create and manage user plane or data plane connection between the UEs 302, electronic devices, and NFs, and between the UEs 302, electronic devices, and the DN 310.

[0061] A data storage function (DSF) 320 provides functionalities to store data of one or more of UE data, user data, NF data, application data, and network operation data, and any other types of data.

[0062] A data management function (DMF) 322 provides functionalities to manage one or more of DSFs 320. For example, some NF may send a data record of a data type to the DMF 322, then the DMF 322 may select a DSF 320 instance to store certain types of data.

[0063] A policy function (PF) 324 may create policies for different operations of the network and provide policies to NFs, EDs, UEs 302, AN 306, and / or DN 310.

[0064] A security function (SF) 326 provides one or more of an authorization function, an authentication function, and data security protection for one or more of UEs 302, NF in the AN 306, NF in the CN 308, AN 306, and NF in the DN 310.

[0065] A location management function (LMF) 328 may provide one or more functionalities: detecting the UE 302 location, estimating the UE 302 location, and / or tracking the mobility of electronic devices in the network generally.

[0066] A network entity repository (NER) 330 may provide functionalities for a network entity (NE) to register its NE profile so that other NEs can discover, select, and use the services of that NE.

[0067] A control plane gateway (CP GW) 332 may provide an interface for NFs in the DN 310 or other networks to access the services provided by NFs of the mobile network 304.

[0068] A data plane function (DPF) 334 may provide one or more of receiving data of UEs 302 and NFs; processing the received data; forwarding the received data; and sending processed data.

[0069] A data plane gateway (DP GW) 336 may provide an interface to send or receive data between the mobile network 304 and other entities in the DN 310.

[0070] The mobile network 304 may provide NFs to host or support DW applications. Some examples of DW applications may include digital twin applications, metaverse applications, and other XR applications. The following example NFs may support DW applications:

[0071] A data collection and distribution function (DCDF) 340 may provide one or more of following functionalities: data collection from NEs; data storage management for the collected data stored in, for instance, a sensor data storage function (SDSF) 342; and / or data distribution to other NFs that request the data.

[0072] A DW control function (DWCF) 344 may be configured to perform one or more tasks to create and manage DW applications, such as managing the operation of a DW application.

[0073] An artificial intelligence and machine learning (AIML) model training function (MTF) 346 may use the collected sensor data to derive AI or ML models to support XR applications in some implementations. In some cases, the CN 308 includes an artificial intelligence and machine learning (AIML) model repository function (MRF) 348. The MRF 348 may, for example, store any AIML models derived by the MTF 346 and / or it may distribute AIML models to other NFs and UEs 302.

[0074] An Object Context Repository function (OCRF) 350 may provide one or more of services related to object context, such as storing object context in real-time and / or distributing object contexts to subscribed NFs. Object context may include, for instance, UE context data, NF context data, or other such context data.

[0075] A DW Data Processing Function (DW DPF) 352 provides certain data processing functions related to DW applications, such as an XR application. In some examples, the DW DPF 352 may (a) obtain one or more AIML models from the MRF 348, (b) obtain sensor data from UEs 302 and / or NFs, (c) use one or more AIML models or other methods to process the collected sensor data to detect real world (RW) objects, (d) convert detected RW objects into one or more virtual world (VW) objects that can be used by one or more DW applications, (e) run application software relating to DW applications, (f) generate actuator data for actuator devices, such as, video data for a video game, patient monitoring video in hospitals, robot monitoring in smart factories, vehicle monitoring for intelligent transport systems, lighting control in a smart city, etc., and / or (g) send actuator control command and data to actuator devices.

[0076] The DN 310 may host one or more applications, e.g. DW applications. The DW applications may be implemented by using DW Controller (DWC) and DW Application Server (AS) . The DWC may provide control functionalities. The DW AS may host application software of DW applications. The DWC may also be called an application function (AF) .

[0077] FIG. 2 shows an example system 300 in the case of a 5G CN 408. The network functions of the 5G CN 408 may be modified to implement the above-described functions of a 6G system. Within a control plane (CP) , certain 5G CN 408 NFs may be modified, such as:

[0078] The 5G access and mobility management function may be enhanced (5G AMF+ 416) to provide functionalities of the CMF 316.

[0079] The 5G session management function may be enhanced (5G SMF+ 418) can be enhanced to provide functionalities of the SMF 318.

[0080] The 5G policy control function may be enhanced (5G PCF+ 424) to provide functionalities of the PF 324.

[0081] The 5G network exposure function may be enhanced (5G NEF+ 432) to provide functionalities of the CP GW 332.

[0082] The 5G network repository function may be enhanced (5G NRF+ 430) to provide functionalities of the NER 330.

[0083] The 5G unified data management function may be enhanced (5G UDM+ 422) to provide functionalities of the DMF 322.

[0084] The 5G unified data repository may be enhanced (5G UDR+ 442) to provide functionalities of the SDSF 342.

[0085] The 5G Authentication Server Function may be enhanced (5G AUSF+ 426) to provide functionalities of the SF 326.

[0086] The 5G Data Collection Coordination Function may be enhanced (5G DCCF+ 440) to provide functionalities of the DCDF 340.

[0087] The 5G Location Management Function may be enhanced (5G LMF+ 428) to provide functionalities of the LMF 328.

[0088] The 5G Service Communication Proxy may be enhanced (5G SCP+ 444) to support the DWCF 344 indirect communications with other CP functions.

[0089] Within the 5G CN 408 data plane (DP) , certain NFs may be modified such as:

[0090] The 5G User Plane Function may be enhanced (5G UPF+ 460) to provide functionalities of the DPF 334, DWDPF 352, and DP GW 336.

[0091] The 5G Analytics Data Repository Function may be enhanced (5G ADRF+ 450) to provide functionalities of the OCRF 350, SDSF 342, MRF 348.

[0092] The Network Data Analytics Function (NWDAF) Model Training Logical Function (MTLF) may be enhanced (5G NWDAF-MTLF+ 446) to provide functionalities of the MTF 346.

[0093] Reference will now be made to FIG. 3, which illustrates an example of an apparatus 500 in a communication system (e.g., the 6G network architecture of FIG. 1) . The apparatus 500 may be a computing device, such as a UE, a network node such as AN, any components in AN, CN or any Network Function of CN (AMF+, SMF+ or any other network functions in FIG. 1 or FIG. 2) . The apparatus 500 may include at least one processor 502. Only one processor 502 is illustrated to avoid congestion in the drawing. The processor 502 may perform (or control the apparatus 500 to perform) operations (or methods) described herein as being performed by the apparatus 500.

[0094] When the apparatus is AN, components of the AN or the apparatus is the UE, the apparatus 500 may further include a transmitter 506 and a receiver 508 coupled to one or more antennas. One, some, or all of the antennas may alternatively be panels. The transmitter 506 and the receiver 508 may be integrated, e.g. as a transceiver. The transceiver is configured to modulate data or other content for transmission by at least one antenna or network interface controller (NIC) . The transceiver is also configured to demodulate data or other content received by the at least one antenna. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or processing signals received wirelessly or by wire. Each antenna includes any suitable structure for transmitting and / or receiving wireless or wired signals. In present disclosure, the transceiver (or transmitter 506 and / or receiver 508) may be viewed as an interface circuit.

[0095] The apparatus 500 may include at least one memory 504. The memory 504 stores instructions used to perform operations described herein. The memory 504 may also stores data used, generated, or collected by the apparatus 500. For example, the memory 504 could store software instructions or modules configured to implement some or all of the functionality and / or embodiments described herein and that are executed by one or more processor 502.

[0096] XR applications typically involve the transmission of media data between end points over the computing network. Media data transmitted between, for example, an XR application server and a UE, or from the UE to the application server, is packetized. The packetized media data includes a media payload and media metadata. In one aspect, the present application describes methods and systems for signalling quality of service information using packet data protocols.

[0097] The apparatus 500 may further include one or more sensors 510 configured to detect and / or obtain sensor data from the apparatus environment. Example sensors include one or more image sensors or imaging devices, such as a camera, configured to capture image data such as a still image and / or video image data. In another example, the sensors 510 includes one or more motion sensors, such as three degrees of freedom (3DoF) or six degrees of freedom (6DoF) sensors configured to detect motion and / or track motion of one or more users or user features. For example, the motion sensor may be configured to track movement of a user’s eyes, face, arm, hand, head, legs and / or other body parts and generate corresponding motion data. In other examples, the sensors 510 may include inertial sensors, such as accelerometers, gyroscopes, etc., temperature sensors, magnetic sensors, optical sensors, or other sensors configured to detect or measure some parameter of the user or the user’s environment and generate corresponding sensor data based that parameter.

[0098] Reference is now made to FIG. 4, which shows examples of packetization formats. In a first example, indicated with reference numeral 602, at the application layer a packet (amedia object) includes a media payload 610 and media metadata 612. The media payload 610 may be encrypted for data protection. The media metadata 612 may not be encrypted, so that network nodes such as routers, AN, DPF, etc., can read the media metadata 612 so as to handle the packet transmission according to the importance of the media payload 610. In one example, the media payload 610 includes the image data captured by an imaging device.

[0099] In accordance with one example implementation, a QoS monitoring indicator (QMI) is inserted in the media metadata 612 to signal that quality of service monitoring is enabled. In this manner, all the network nodes and network segments are capable of reading this field and, upon identifying the QMI, enabling any suitable MTP delay measurement method that is to be implemented or carried out by that node or segment.

[0100] In one example implementation, quality of service monitoring may be implemented in Internet Engineering Task Force (IETF) Media over QUIC (MoQ) . QUIC is a UDP-based stream-multiplexing, encrypted transport protocol developed by the IETF, as published in its RFC 9000 and other related RFCs. Media data in MoQ generally has the following defined field structure:

[0101] In the above structure, the media data is put in the object payload field which, still to FIG. 4, would be placed in the media payload 610. The other fields are carried in the media metadata 612 portion of the packet structure. In one example, QMI may be signaled within the media metadata 612 by modifying the OBJECT_STREAM message to include new fields for “Object QoS Monitoring” and “Object Time Information” , such as:

[0102] In another example, the OBJECT_STREAM structure may be modified to add a new value in the existing Object Status field that signals the QMI:

[0103] As an illustrative example, a UE may obtain an image showing the face of a user via an image sensor (e.g. camera) within the UE. The image data is carried in the Object Payload field. As another illustrative example, a UE may obtain motion tracking sensor data showing one or more of, but not limited to, an eye, face, head, body, arm, hand, and / or leg movement of a user. For instances, the motion data may be obtained via one or more 3DoF sensors, and / or 6DoF sensors within the UE. The motion data is  carried in the Object Payload field. The value of Object QoS Monitoring may be set to Yes. The UE may capture the image at time T1 (or T_create) . The UE packetizes the image data and sends out the last packets of the image to the AS at time T2. The UE records the time T1 and T2 within at least the OBJECT_STREAM metadata. The UE may send T1 and / or T2 in the Object Time Information. The AS receives the packets making up the whole image at time T3. The AS processes the image, creates an XR image, and packetizes and sends the XR image to the UE at time T4. The AS may set the value of Object QoS Monitoring to Yes within the packets, and may add times T1, T2, T3 and T4 to the Object Time Information field. Any one of T3 and / or T4 may be referred to as server timestamps. The UE may then receive all the packets of the XR image at time T5 (e.g. the last of the packets may be received at T5) , and the XR image may be reconstructed (e.g. depacketized and decoded) , and displayed at the UE at time T6 (or T_consume) . In some cases, where image or other media data is packetized and multiple packets relate to a singular image or event, all such packets may include a QMI set to yes and only the last packet sent may contain the time of sending timestamp (e.g. T2 and / or T4) , or all packets may contain a time-of-transmission timestamp even if the timestamp may be different for different packets as packets are transmitted at slightly different times.

[0104] The UE may then record times T1, T2, T3, T4, T5 and T6, and calculate the MTP delay of the XR service. For example, the total MTP delay is T6 –T1. It or another component of the system may also determine that the MTP delay caused by UL transmission is T3-T2, the MTP delay caused by image processing is T4-T3, and the MTP delay caused by DL transmission is T5-T4. This may enable the UE, the AS, or other components of the system to assess the quality of the overall MTP delay, i.e. to determined if it exceeds a threshold maximum delay, and if so then to identify segments of the network that may be causing an excessive delay.

[0105] In another example, network functions, such as routers at the IP layer, an AN, a DPF, etc., may participate in MTP delay measurement and assessment. Reference numeral 604 shows a packet structure at the network layer. In addition to the media payload 610 and the media metadata 612, the packet includes transport and network layer headers 614. In a further example, reference numeral 606 shows a packet structure within the mobile network between an AN and DPF and / or DWDPF. In this example, the packet further includes mobile network header 616.

[0106] Because the media metadata 612 is not encrypted, network functions such as IP routers, or the AN or DPF, can read the media metadata 612 and detect the presence of a QoS Monitoring Indicator (QMI) in the media metadata 612. A network function configured to participate in QoS monitoring may therefore add time information to the transport and network packet headers 614, such as in an extension field of an IPv6 packet header. In another example, the AN and / or UPF may add time information in the mobile network header 616, such as in user plane tunnel protocol header. The time information may include one or more of following parameters: an ingress timestamp marking the time that the network function receives the packet and an egress timestamp marking the time that the network function sends the packets.

[0107] For example, during the UL transmission, if the UE sends an image for processing in the DWDPF (or AS) , and the UE wants to measure the MTF delay, the UE may include QMI in the media metadata 612. The routers in the AN and UPF may add ingress and egress timestamps to the IP packet header. The AS receives all the packets belong to the image. The MTF delay caused by UL transmission can be calculated by the DWDPF as follows: T_UL = T_last_ingress_timestamp –T_first_ingress_timestamp, where T_last_ingress_timestamp is the timestamp of the last packet arrived at the DWDPF, the T_first_ingress_timestamp is the timestamp of the first packet that arrives at the AN.

[0108] The DWDPF may create XR media, such as an XR image, from the received image sent from the UE. The DWDPF may send the XR image to the UE in the DL. The DWDPF may include QMI and DWDPF time information in the packet headers. The DWDPF time information may include one or more of following parameters: T_UL, T_DWDPF, T_first_ingress_DWDPF, T_first_egress_AS, and T_last_egress_DWDPF, where T_DWDPF is the time to create XR image, T_first_ingress_AS is the time the first packet of image sent from the UE arrives at the DWDPF, and T_first_egress_DWDPF and T_last_egress_DWDPF is the time the first and last packets of XR image is sent out from the DWDPF towards the UE, respectively. In some implementation, the DWDPF time information may be carried in the Object Time Information field of the modified MoQ protocol, as described above.

[0109] The AN may receive the last packets of the XR image at time T_last_ingress_AN. If the AN finds the presence of QMI in the media metadata 612, the AN may use the AS time information to calculate the MTP delay between the DWDPF and AN in the DL as T_last_ingress_AN -T_first_egress_DWDPF.

[0110] The UE may then receive the last packets of XR image at time T5 and displays the XR image at time T6.

[0111] The additional granular time information from the AN and DWDPF may be used to further refine the analysis of network segments and their relative contribution to the overall MTP delay.

[0112] Reference will now be made to FIG. 5, which shows one example signal diagram illustrating a QoS measurement process 700 involving one or multiple UEs. In this example, the process 700 is initiated by a user device (e.g., a first UE 702) engaged in an XR service. A second UE 704 may be also engaged in the XR service. A DWDPF 706 (digital world data processing function) is involved in the XR service and is configured to receive sensor data or other XR-related data from the UEs 702, 704 and to generate and transmit XR media data to the UEs 702, 704 for display thereon. In this example process 700 the UEs and the DWDPF 706 collaborate in the MTP delay measurement for QoS determination. The DWDPF 706 may be located in the core network, the data network, or elsewhere in the communication network. The DWDPF 706 may be part of an XR application server in some cases. In the process 700, some steps can be optional.

[0113] Activation of the MTP delay measurement process is detected or determined at the first UE 702 in operation 708. The trigger for activating MTP delay measurement may be received by the first UE 702 from the DWDPF 706, from a QoS monitoring function executed by an XR application server in the data network (DN) , from another DW network function, from a user input, or from some other source. The steps of 708 can be omitted.

[0114] The first UE 702 generates and transmits a media object having a media payload and media metadata, the media object can include or be a packet, specially, in operation 710, the first UE 702 adds the QMI to media metadata in the header of one or more packets of XR-related data being generated for transmission. As noted above, in some cases this may include adding or changing a flag or value within a defined metadata header structure to signal activation of the MTP measurement process. In operation 712, the first UE 702 further adds one or more timestamps to the media metadata within the packet header. The timestamp may include a sensor capture or detection time associated with generation of the media being sent in the payload. The timestamp may also or alternatively include a transmission time for the packet. Each packet may include its transmission time or only the last-to-be-sent packet associated with a singular XR event (e.g. one image or one sensor event) may include a timestamp indicating its transmission time. As indicated by operation 714, the packets are sent to the application server and / or DWDPF 706. As an optional operation, before the operation 710 and 712, the first UE may obtain data via a sensor, then the media object is generated in response to obtaining the data.

[0115] At the DWDPF 706, the UE packets are received and the QMI within the packet header (s) is detected, signaling that MTP measurement is active. In response, the timestamp (s) are extracted from the media metadata and recorded in memory at the DWDPF 706 in operation 718. At operation 720, the DWDPF 706 processes the received media object, e.g. the media payload, which may include decrypting, reconstructing, decoding, analyzing, and / or other data processing functions. Based, in part, on the received and processed user-sent media payload, the DWDPF 706 generates XR media object (which can be referred to as XR media data) associated with the media object. The XR media data may be a graphic, an image, a sound, positional data, configuration data, or any other media data relevant to the rendering of XR media at a user device. The DWDPF 706 packetizes the XR media data for transmission to one or more user devices.

[0116] In operations 722 and 724, the DWDPF 706 adds the QMI to the media metadata of the packetized XR media data and adds one or more timestamps to the media metadata. The one or more timestamps include, at least, a server timestamp, where the server timestamp is at least one of the timestamps generated at the DWDPF 706 to record a time of receipt at the DWDPF 706, time of XR media generation, and / or time of transmission from the DWDPF 706. As indicated above, the server timestamps may include one or more of time of receipt of a first packet from the first UE 702, time of receipt of the last of the packets from the first UE 702, time of completion of processing of the user data, time of completion of generation of the XR media, time of transmission of the XR media packets, and / or time of transmission of the last-to-be-sent of the XR media packets. The XR media generated may be common to all user devices or specified XR media may be generated for each user device involved in the XR service.

[0117] The XR media packets are transmitted to the first UE 702 and to the second UE 704 in operations 726 and 728. The transmission may be unicast to each of the UEs 702 and 704. In some cases, if the XR media is common to all user devices, the media packets may be broadcast / multi-cast to subscribers to the XR service, which subscribers include the first UE 702 and the second UE 704.

[0118] At the first UE 702 and the second UE 704, the XR media packets are received via a network connection and the QMI in the media metadata detected. In response, the timestamps are extracted and recorded, as indicated by operations 730 and 732. The UEs 702 and 704 display an image based on the XR media packets on an output display of the UEs at a display time. The UEs 702 and 704 further determine and record time information regarding time of receipt of the last of the XR media packets and time of display of the resultant XR media data. As will be described in greater detail below, various network components within the access network or core network functions, may add one or more timestamps to packets having the QMI in the metadata. Those intermediate timestamps signal times of receipt or transmission of packets by that intermediate network component.

[0119] In operations 734, 736, the first UE 702 and the second UE 704 determine the MTP delay based on the time information extracted from the packets and from the local timestamps relating to display of the media. Determination of the MTP delay may include determining overall MTP delay and delay attributable to one or more segments, e.g., based on one or more of the intermediate timestamps between the timestamp T1 associated with the initial sensor / media capture at the first UE 702 and last timestamp associated the (photon) display time at the respective UE 702, 704. Determination of the MTP delay at the first UE 702 may include detecting an association between the media object that was originally sent by the first UE 702 in operation 714 and the received XR media object received from the DWDPF 706. The detecting may be based on matching a unique identifier in the media metadata with a corresponding unique identifier in metadata attached to the XR media object. The unique identifiers may include one or more of a combination of Subscribe ID (i) , Track Alias (i) , Group ID (i) , Object ID (i) , and Object Send Order (i) in some examples.

[0120] The MTP delay (s) determined by the first UE 702 and the second UE 704 are then reported to one or more network entities, as indicated by operations 738, 740. In some cases, the MTP delay (s) are reported to a network function, such as a DWCF, the DWDPF 706, the XR application server, a QoS-specific function within the CN or the DN, or some other network entity, the network function is also referred to as a remote server.

[0121] In response to the MTP delay (s) reported to the network entity engaged in QoS assessment, the network entity may compare the MTP delay (s) to one or more threshold values to determine whether the delay exceeds a maximum value. If so, then the network entity may take one or more remedial actions. Remedial actions may include alter one or more functions or network parameters to try to alleviate delay issues. This may include allocating additional network resources, altering packet priority, reducing media resolution or other such actions.

[0122] In operation 742, the UE 702 may de-activate the MTP delay measurement. The trigger for de-activation may, in some cases, be a measurement timer that expires, or the UE 702 may receive a request from a NF (e.g. SMF, PF, DWCF, DWDPF 706) or AF to stop the MTP delay measurement.

[0123] In some examples, one or more user entities is a digital or virtual user created by a DW application for interaction with other real-world users operating UEs. In this sense, one of the UEs involved in the MTP measurement process may include a UE that does not have a corresponding real-world user and display.

[0124] Reference is now made to FIG. 6, which shows an example signal diagram illustrating a process 800 for configurating a UE 802 to perform an MTP measurement process. The process 800 is initiated by a DWCF 804 in this example. The DWCF 804 signals the UE 802 to initiate MTP measurement via the network control plane.

[0125] In operation 810, the DWCF 804 generates and transmits a session performance monitoring request to the UE 802 via one or more of the CMF 806 and / or the AN 808. The session performance monitoring request may include one or more parameters. The parameters may include, for example, a UE identifier, which may be an identifier for the UE 802 and / or an identifier of the user operating the UE 802. In some cases, this may include a temporary UE ID, a subscription permanent identifier (SUPI) , a global unique temporary identifier (GUTI) , or a subscriber ID in the MoQ metadata, as examples.

[0126] In some cases, the parameters may include Service ID (or Application ID) to identify the service to be monitored, e.g. XR meeting, XR music performance, XR game. In some cases, the parameters may include a session ID for the XR session between the UE 802 and the DWCF 804, a QoS monitoring request or flag, QoS parameters to be monitored such as MTP delay and segments to be measured, and / or a QoS measurement method (continuous, periodic, selective) . In some cases, the parameters may include a track alias ID to indicate which track alias of an MoQ object stream the QoS is to be monitored. The track alias may be set to a value signalling “all” if all tracks are to be monitored. Similarly, the parameters may include a group ID, an object ID,  and / or an object send order ID relating to the particulars of the stream to be monitored. In each of these cases, the parameter may signal “all” if all such streams are to be monitored.

[0127] The parameters may indicate an on_time and off_time if the QoS measurement method is periodic, so as to specify the window or duration over which the QoS measurement process is to be active, e.g. on_time, and the window or duration over which the QoS measurement process is to be inactive, e.g. off_time. For instance, an on_time may indicate QoS is to be active for 10 seconds and off_time may indicate that QoS is to be inactive or paused for 120 seconds.

[0128] Similarly, the parameters may indicate a start_time and end_time for signaling when the QoS measurement process is to be activated and when it should be deactivated. This may be applicable to any of the QoS measurement methods.

[0129] The parameters may signal the QoS reporting method, which may specify to where a QoS report is to be sent, such as a CP function like the DWCF 804, or a UP function like the DWDPF. The reporting parameters may specify one or more addresses to which reporting is to be sent, such as an NF identifier like an IP address and port number for instance.

[0130] The parameters may indicate a QoS measurement role, such as ‘leader’ or ‘follower’ . In cases where there are multiple UEs involved in the MTP measurement process, one may be designated as a leader and others as followers. A leader UE initiates an MTP measurement by capturing and sends sensor / media data, receiving the processed object, displaying XR data locally, and determining and reporting MTP delay. A follower UE receives a processed XR media object, displays XR data locally, and determines and reports MTP delay.

[0131] One illustrative example of a session performance monitoring request data structure may include:

[0132] -Service ID (XR meeting) ,

[0133] -UE ID (subscriber ID in the MoQ metadata) ,

[0134] -Session ID (1) ,

[0135] -QoS monitoring request () ,

[0136] -QoS parameters to be monitored (MTP delay measurement) ,

[0137] -QoS measurement method (selective) ,

[0138] -Track Alias ID (XR Meeting) ,

[0139] -Group ID (1) ,

[0140] -Object ID (2) ,

[0141] -Object Send Order ID (1) ,

[0142] -Start_Time (10: 20: 00) , End_Time (10: 30: 00) ,

[0143] -QoS reporting method (QoS report over CP) ,

[0144] -QoS report destination information (DWCF ID) ,

[0145] -QoS measurement role (Leader) .

[0146] Referring again to FIG. 6, if the CMF 806 receives the session monitoring performance request from the DWCF 804, it may forward the message to the AN 808. If the AN 808 receives the message from either the DWCF 804 or from the CMF 806, it may forward it to the UE 802.

[0147] In operation 812, the UE 802 that receives the session monitoring performance request message generates and sends a response message to the DWCF 804 via one or more of the AN 808 and CMF 806.

[0148] Assuming the UE 802 is configured to support MTP monitoring, it then activates MTP measurement monitoring as indicated by operation 814. The UE 802 sends one or more session performance reports to the DWCF 804 in operation 816 via one or more of the AN 808 and CMF 806. The session performance report may include various parameters and the QoS data measured by the UE 802, such as one or more MTP measurements. In some examples, the session performance report may include:

[0149] -UE ID, e.g. the temporary UE ID, SUPI, GUTI, and / or subscriber ID

[0150] -Session ID

[0151] -QoS monitoring report

[0152] -QoS parameters to be reported: e.g. MTP delay measurement

[0153] -QoS report ID that uniquely identifiers the QoS report, e.g. the numbering of the QoS report

[0154] -QoS report timestamp to indicate the time the QoS report was generated

[0155] -Track Alias ID

[0156] -Group ID

[0157] -Object ID

[0158] -Object Send Order ID

[0159] -QoS measurement role

[0160] -Measured QoS parameter (s) : e.g. MTP delay

[0161] -Measured QoS value: e.g. 20 ms

[0162] -QoS processing function information, for example, the ID of the DWCF 804, the IP address and port number of the DWCF 804, the URL of the DWCF.

[0163] In operation 820, the DWCF 804 may transmit a session performance report acknowledgement to the UE 802 via one or more of the CMF 806 and the AN 808.

[0164] In another embodiment, as shown in FIG. 8, a DWCF 1004 may transmit a service performance monitoring request 1010 via the UP instead of the CP. In this case, it may initially send the service performance monitoring request 1010 to a DWDPF 1005. The service performance monitoring request 1010 may include some or all of the parameters noted in operation 810 above. The UE ID parameter may include one or more UE IDs such that QoS measurement may be performed at multiple UEs at the same time.

[0165] At the DWDPF 1005, one or more session performance monitoring requests 1012 may be generated for transmission to each respective UE 1002 indicated in the UE ID parameter. Responses 1014, 1016 are returned to the DWDPF 1005 and DWCF 1004, respectively. In particular, the UE 1002 may send the session performance monitoring response 1014 to the DWDPF 1005 via one or more of the AN 1008 and DPF 1006 in the UP. The message may include an indication whether the session performance monitoring request 1012 is accepted or rejected, and a cause for rejected such as “UE unavailable” , “not supported” . The service performance monitoring response 1016 from the DWDPF 1005 to the DWCF 1004 may include one or more parameters for each UE that sent a session performance monitoring response 1014, such as the UE ID, an indication of whether the session performance monitoring request is accepted or rejected, and, if reject, a cause for rejection. As indicated, the session performance monitoring request 1012 may be sent to a DPF 1006, an AN 1008, or directly to the UE 1002.

[0166] The UE may perform session performance monitoring, as indicated by reference numeral 1018. It then sends a session performance report 1020 to the DWDPF 1005, which may be sent via the AN 1008 and / or DPF 1006 on the UP. The DWDPF 1005 sends a session performance report acknowledgement in operation 1022 and assembles and sends a service performance report 1024 to the DWCF 1004, which is acknowledged by service performance report acknowledgement in operation 1026. The service performance report 1024 may include one or more session performance reports 1020 from various UEs 1002. In the service performance report 1024, the DWDPF 1004 may include an average MTP delay for one of the UEs 1002 and / or may include an average MTP delay for two or more of the UEs 1002.

[0167] Reference will now be made to FIG. 7, which shows a signalling diagram illustrating activation of an MTP measurement process 900 involving intermediate network functions. In this example process 900, each UP NF that transfers the media objects of the UE may be configured to report the object transmission delay. In the 3GPP technical specifications, such as TS 23.501, a media object may be transported in the network by a protocol data unit (PDU) set. Each NF, such as AN 904, DPF 908, DWDPF 910, may be configured by a CP NF, such as SMF 912 to measure the transfer delay of the PDU set.

[0168] The process 900 may be initiated by a DWCF 914 sending a session performance monitoring request message to the SMF 912 in operation 916. The DWCF 914 may sent this directly to the SMF 912 or via a CP gateway in some cases. The request message may include a plurality of parameters. Example parameters are described in operation 810 above. A service performance monitoring response or acknowledgement message may be received from the SMF 912. The SMF 912 may identify the DWDPF 910, DPF 908, and / or AN 904 that are providing data connectivity to the UE 902 in connection with the XR session.

[0169] The SMF 912 sends a QoS monitoring request to the DWDPF 910 to configure the DWDPF 910 for MTP delay measurement in operation 918. The message may include many or all of the parameters from the session performance monitoring request. In some cases, the request may further include:

[0170] -QoS report destination information: e.g. SMF ID, DWCF ID

[0171] -Tunnel information, which may include one or more of: tunnel address of NF that receives the packets (e.g. IP address and port number of DWDPF 910) and tunnel endpoint ID

[0172] -Packet filter information, which may include packet header information to identify the packets that deliver media data, for example, the packet filter information may include one or more of: IP address and port number of the source, IP address and port number of the destination, transport protocol (e.g. QUIC, and MoQ) . In some examples, the source could be UE 902, DPF 908, or AN 904

[0173] -Where to include time information in the packet header: e.g. metadata header, or transport protocol header (e.g. QUIC header) , or network protocol header (e.g. IP layer packet header)

[0174] The DWDPF 910 may send a DWDPF QoS monitoring response to the SMF to acknowledge the receipt of message in operation 918.

[0175] A QoS monitoring request 919 may then be sent from the SMF 912 to the DPF 908. In some cases, the SMF 912 may send a QoS monitoring request directly to the AN 904 or to the AN 904 via the CMF 906, as indicated by operation 920. Such a request may include many of the same parameters noted in operation 918 above, and a container that carries a UE QoS monitoring request.

[0176] In operations 922 and 923, the AN 904 may receive the QoS monitoring request and may save the relevant parameters. It may forward the container that carries a UE QoS monitoring request to the UE 902. Various acknowledgements may be fed back through the network elements. The session performance monitoring response may be sent to the DWCF 914 to acknowledge the receipt of the session performance monitoring request 916. The SMF 912 may identify the DWDPF 910, DPF 908, AN 904 that are providing data connection for the session of the UE. The DWDPF 910 may send a DWDPF QoS monitoring response to the SMF 912 to acknowledge the receipt of the message from operation 918. The DPF 908 may send a DPF QoS monitoring response to the SMF 912 to acknowledge the receipt of the message from operation 919. The AN 904 may send an AN QoS monitoring response to the SMF 912 to acknowledge the receipt of the message of operation 922. The AN QoS monitoring response may include the UE QoS monitoring response received from the UE. The message may be sent to the SMF 912 directly or via the CMF 906.

[0177] Having so configured the various network elements or network functions, those elements or functions may then participate in the MTP measurement process. Some example operations are described below.

[0178] During the XR session, the UE 902 may create a media data file at time T_create. The media data file may be split into multiple packets of a PDU set. The UE 902 adds a QMI to the packet header, e.g. in one or more of, but not limited to, metadata header, transport protocol header (e.g. QUIC header) , and network protocol header (e.g. IP layer packet header) . The insertion of the QMI may be in accordance with configuration information / parameters received from the SMF 912.

[0179] The UE 902 may add timestamp (s) to the packet header. For example, the UE may add timestamps to signal the media file creation time, T_create, the transmission of the first packet (T_UE_UL_first_egress) and the last packet (T_UE_UL_last_egress) of a media object (or a PDU set) sent out from the UE 902 to the AN 904 in the UL. Those timestamps are further stored locally at the UE 902 in association with the media file data and / or media object in local storage media.

[0180] The AN 904 is configured to detect the QMI in the packet header in accordance with packet filter information. On detecting the QMI, the AN 904 may store any timestamp (s) in the packet header, such as T_create, T_UE_UL_first_egress and T_UE_UL_last_egress. The AN 904 may further create timestamps marking a time of receipt of the first packet of the media object (or PDU set) , T_AN_UL_first_ingress, a time of receipt of the last packet of the media object (or PDU set) , T_AN_UL_last_ingress, a time of sending the first packet of the media object (or PDU set) , T_AN_UL_first_egress, and / or a time of sending of the last pack of the media object (or PDU set) , T_AN_UL_last_egress. The generated timestamps may be inserted into the packet headers of one or more packets. The AN 904 may classify packets received from the UE 902 into one or more QoS data flows. The AN 904 then sends the packets of the media object (or PDU set) to the next NF, such as the DPF 908 or DWDPF 910 in the UL, e.g. via the IP network, or via one or more UL tunnels.

[0181] When the DPF 908 receives packets from the AN 904, it may detect the QMI according to the configured information received from the SMF 912 and, in response, record the timestamps found in the packet header. It may further create and store timestamps marking a time of receipt of the first packet of the media object (or PDU set) , T_DPF_UL_first_ingress, and a time of receipt of the last packet of the media object (or PDU set) , T_DPF_UL_last_ingress. The DPF 908 may classify packets received from the AN 904 into one or more QoS data flows. It may insert one or more timestamps, e.g. T_DPF_UL_first_ingress and T_DPF_UL_first_egress, which is the timestamp that the DPF 908 sends out the first packet of the media object (or PDU set) , in one  or more packet headers of the first packet of the media object (or PDU set) , e.g. according to the configured information received from the SMF. It may insert one or more timestamps, e.g. T_DPF_UL_last_ingress and T_DPF_UL_last_egress, which is the timestamp that the DPF 908 sends out the last packet of the media object (or PDU set) , in one or more packet headers of the last packet of the media object (or PDU set) . It may further insert timestamps such as, e.g. T_DPF_UL_first_ingress and T_DPF_UL_first_egress, T_DPF_UL_last_ingress, and T_DPF_UL_last_egress, in one or more packet headers of the last packet of the media object (or PDU set) . The DPF 908 may store one or more of timestamps added by the UE in the UL packets, timestamps added by the AN in the UL packets, and timestamps added by the DPF in the UL packets. The DPF 908 sends the packets of the media object to the next NF, such as the DWDPF 910 in the UL, e.g. via the IP network, or one or more of UL tunnel.

[0182] When the DWDPF 910 receives packets from the AN 904 and / or DPF 908 in the UL, it may detect the QMI in the packet header and, in response, extract and store one or more of the timestamps added to the packet headers by the UE 902, the AN 904, and the DPF 908. It may also record the timestamps indicating the time of receipt of the first packet of the media object (or PDU set) and the time of receipt of the last packet of the media object, e.g. T_DWDPF_UL_first_ingress and T_DWDPF_UL_last_ingress.

[0183] The DWDPF 910 then recovers data from the media payload fields of the received data packets and processes the data. Processing may include decrypting, decoding, assembling, reconstructing, analyzing, or otherwise processing the received data. In response to the received data, the DWDPF 910 may generate one or more XR media objects, which it then packetizes to create an XR PDU set for transmission of the XR media object to the UE 902. The DWDPF 910 may insert the QMI into the packet headers along with a plurality of timestamps.

[0184] In one example, the DWDPF 910 may insert one or more timestamps into one or more of packet headers of the first packet of the media object (or PDU set) , such as: T_DWDPF_UL_first_ingress, T_DWDPF_DL_first_egress which marks the time that the DWDPF 910 sends out the first packet of the XR media object (or XR PDU set) , and T_Object_Processing_Time which marks the time the DWDPF 910 spent to create the XR media object from the received data files.

[0185] The DWDPF 910 may insert one or more timestamps into one or more of packet headers of the last packet of the media object, such as: T_DWDPF_UL_last_ingress, T_DWDPF_DL_last_egress which is the timestamp that the DWDPF 910 sends out the last packet of the media object (or PDU set) , and T_Object_Processing_Time. In some cases, the DWDPF 910 may further insert one or more of the T_DWDPF_UL_first_ingress and T_DWDPF_DL_first_egress timestamps in one or more of packet headers of the last packet.

[0186] The DWDPF 910 may store one or more of timestamps added by the UE in the UL packets) , timestamps added by the AN in the UL packets, timestamps added by the DPF in the UL packets, and timestamps added by the DWDPF in the DL packets.

[0187] The DWDPF 910 may classify XR packets into one or more DL QoS data flows. It sends the packets of the XR media object with timestamp data to the next NF, such as the DPF 908 or the AN 904 in the DL, e.g. via the IP network, or one or more of DL tunnel. When the DPF 908 receives XR media object packets in the DL from the DWDPF 910, it may perform one or more of the following actions:

[0188] 1. The DPF may check the packet headers and detect the QMI according to the packet filter information received from the SMF,

[0189] 2. If QMI is present, the DPF may record one or more of timestamps that have been added to the packet header by the UE in the UL, AN in the UL, DPF in the UL, and DWDPF, e.g. according to the configured information received from the SMF.

[0190] 3. The DPF may record the timestamp that the first packet of the XR media object (or XR PDU set) , T_DPF_DL_first_ingress, received by the DPF, and record the timestamp that the last packet of the XR media object (or XR PDU set) , T_DPF_DL_last_ingress, received by the DPF in the DL;

[0191] 4. The DPF may classify packets received from the DWDPF into one or more of QoS data flow.

[0192] 5. The DPF may insert one or more timestamps, e.g. T_DPF_DL_first_ingress and T_DPF_DL_first_egress (timestamp that the DPF sends out the first packet of the XR media object (or XR PDU set) to the AN) , in one or more of packet headers of the first packet of the XR media object (or XR PDU set) , e.g. according to the configured information received from the SMF.

[0193] 6. The DPF may insert one or more timestamps, e.g. T_DPF_DL_last_ingress, and T_DPF_DL_last_egress (timestamp that the DPF sends out the last packet of the XR media object (or XR PDU set) to the AN) , in one or more of packet headers of the last packet of the XR media object (or XR PDU set) , e.g. according to the configured information received from the SMF.

[0194] 7. The DPF may insert one or more timestamps, e.g. T_DPF_DL_first_ingress, T_DPF_DL_first_egress, T_DPF_DL_last_ingress, T_DPF_DL_last_egress, in one or more of packet headers of the last packet of the XR media object (or XR PDU set) , e.g. according to the configured information received from the SMF.

[0195] 8. The DPF may record the one or more of timestamps added by the UE in the UL packets (e.g. T_UE_UL_first_egress, T_UE_UL_last_egress) , timestamps added by the AN in the UL packets (e.g. T_AN_UL_first_ingress, T_AN_UL_first_egress, T_AN_UL_last_ingress, T_AN_UL_last_egress) , timestamps added by the DPF in the UL packets (e.g. T_DPF_UL_first_ingress, T_DPF_UL_first_egress, T_DPF_UL_last_ingress, T_DPF_UL_last_egress) , timestamps added by the DWDPF in the DL packets (e.g. T_DWDPF_UL_first_ingress, T_DWDPF_DL_first_egress, T_DWDPF_UL_last_ingress, T_DWDPF_DL_last_egress, and T_Object_Processing_Time) , and timestamps added by the DPF in the DL packets (e.g. T_DPF_DL_first_ingress, T_DPF_DL_first_egress, T_DPF_DL_last_ingress, and T_DPF_DL_last_egress) .

[0196] 9. The DPF may send the packets of the XR media object (or XR PDU set) with timestamp information to the next NF, such as AN in the DL, e.g. via the IP network, or one or more of the DL tunnels.

[0197] When the AN 904 receives XR media object packets in the DL from the DPF 908 or DWDPF 910, it may perform one or more of the following actions:

[0198] 1. The AN may check the packet header sent from the DPF or the DWDPF according to the packet filter information, including detection of QMI field in the packet header, e.g. according to the configured information received from the SMF.

[0199] 2. If QMI is present, the AN may record one or more of timestamps that have been added to the packet header by the UE in the UL, AN in the UL, DPF in the UL, DWDPF, and DPF in the DL, e.g. according to the configured information received from the SMF.

[0200] 3. The AN may record the timestamp that the first packet of the XR media object (or XR PDU set) , T_AN_DL_first_ingress, received by the AN, and record the timestamp that the last packet of the XR media object (or XR PDU set) , T_AN_DL_last_ingress, received by the AN in the DL;

[0201] 4. The AN may classify packets received from the DPF into one or more of QoS data flow to be sent to the UE in the DL air interface.

[0202] 5. The AN may insert one or more timestamps, e.g. T_AN_DL_first_ingress and T_AN_DL_first_egress (timestamp that the AN sends out the first packet of the XR media object (or XR PDU set) to the UE) , in one or more of packet headers of the first packet of the XR media object (or XR PDU set) , e.g. according to the configured information received from the SMF.

[0203] 6. The AN may insert one or more timestamps, e.g. T_AN_DL_last_ingress, and T_AN_DL_last_egress (timestamp that the AN sends out the last packet of the XR media object (or XR PDU set) to the UE) , in one or more of packet headers of the last packet of the XR media object (or XR PDU set) , e.g. according to the configured information received from the SMF.

[0204] 7. The AN may insert one or more timestamps, e.g. T_AN_DL_first_ingress, T_AN_DL_first_egress, T_AN_DL_last_ingress, T_AN_DL_last_egress, in one or more of packet headers of the last packet of the XR media object (or XR PDU set) , e.g. according to the configured information received from the SMF.

[0205] 8. The AN may record the one or more of timestamps added by the UE in the UL packets (e.g. T_UE_UL_first_egress, T_UE_UL_last_egress) , timestamps added by the AN in the UL packets (e.g. T_AN_UL_first_ingress, T_AN_UL_first_egress, T_AN_UL_last_ingress, T_AN_UL_last_egress) , timestamps added by the DPF in the UL packets (e.g. T_DPF_UL_first_ingress, T_DPF_UL_first_egress, T_DPF_UL_last_ingress, T_DPF_UL_last_egress) , timestamps added by the DWDPF in the DL packets (e.g. T_DWDPF_UL_first_ingress, T_DWDPF_DL_first_egress, T_DWDPF_UL_last_ingress, T_DWDPF_DL_last_egress, and T_Object_Processing_Time) , timestamps added by the DPF in the DL packets (e.g. T_DPF_DL_first_ingress, T_DPF_DL_first_egress, T_DPF_DL_last_ingress, and T_DPF_DL_last_egress) , and timestamps added by the AN in the DL packets (e.g. T_AN_DL_first_ingress, T_AN_DL_first_egress, T_AN_DL_last_ingress, T_AN_DL_last_egress) .

[0206] 9. The AN may send the packets of the XR media object (or XR PDU set) with timestamp information to the next UE in the DL air interface.

[0207] When the UE receives the packets from the AN in the DL, the UE may perform one or more of the following actions:

[0208] 1. The UE may check the packet header sent from the AN according to the packet filter information, including detection of QMI field in the packet header, e.g. according to the configured information received from the SMF.

[0209] 2.If QMI is present, the UE may store one or more of timestamps that have been added to the packet header by the UE in the UL packets, AN in the UL packets, DPF in the UL packets, DWDPF in the DL packets, DPF in the DL packets, and the AN in the DL packets, e.g. according to the configured information received from the SMF.

[0210] 3. The UE may store the timestamp that the first packet of the XR media object (or XR PDU set) , T_UE_DL_first_ingress, received by the UE in the DL packet, and store the timestamp that the last packet of the XR media object (or XR PDU set) , T_UE_DL_last_ingress, received by the UE in the DL packets.

[0211] 4. The UE may recover the XR media data from the received packets. The UE may consume the XR media data at time T_consume. The UE may store the time T_consume.

[0212] The list of timestamps the UE may store include one or more of timestamps: T_create , T_consume, timestamps added by the UE in the UL packets (e.g. T_UE_UL_first_egress, T_UE_UL_last_egress) , timestamps added by the AN in the UL packets (e.g. T_AN_UL_first_ingress, T_AN_UL_first_egress, T_AN_UL_last_ingress, T_AN_UL_last_egress) , timestamps added by the DPF in the UL packets (e.g. T_DPF_UL_first_ingress, T_DPF_UL_first_egress, T_DPF_UL_last_ingress, T_DPF_UL_last_egress) , timestamps added by the DWDPF in the DL packets (e.g. T_DWDPF_UL_first_ingress, T_DWDPF_DL_first_egress, T_DWDPF_UL_last_ingress, T_DWDPF_DL_last_egress, and T_Object_Processing_Time) , timestamps added by the DPF in the DL packets (e.g. T_DPF_DL_first_ingress, T_DPF_DL_first_egress, T_DPF_DL_last_ingress, and T_DPF_DL_last_egress) , and timestamps added by the AN in the DL packets (e.g. T_AN_DL_first_ingress, T_AN_DL_first_egress, T_AN_DL_last_ingress, T_AN_DL_last_egress) , T_UE_DL_first_ingress, and T_UE_DL_last_ingress.

[0213] The UE 902 may then determine the MTP delay. In some cases, the UE determines the overall MTP delay based on its T_create and T_consume. It may also determined MTP delay attributable to certain network segments based on the differences between various timestamps received in the XR media packets. In some examples, the UE 902 may determine:

[0214] 1. End-to-end MTP delay: T_E2E_MTP_delay = T_consume –T_create

[0215] 2. MTP delay caused by UL data transmission between the UE and DWDPF, data processing in the DWDPF, and DL data transmission delay between the DWDPF and the UE: MTP_Delay_Tr_Pr = T_UE_DL_last_ingress -T_UE_UL_first_egress

[0216] 3. MTP delay caused by UL data transmission between the UE and DWDPF:

[0217] MTP_Delay_Tr_UL = T_DWDPF_DL_last_ingress -T_UE_UL_first_egress

[0218] 4. MTP caused by DL data transmission between the DWDPF and UE:

[0219] MTP_Delay_Tr_DL = T_DWDPF_DL_first_egress -T_UE_DL_last_ingress

[0220] 5. MTP delay caused by processing in DWDPF:

[0221] MTP_Delay_Pr = T_Object_Processing_Time

[0222] 6. MTP delay caused by UL data transmission between the UE and AN due to the air interface transmission and AN packet processing:

[0223] MTP_Delay_Tr_UL_air = T_UE_UL_first_egress -T_AN_UL_last_ingress

[0224] 7. MTP delay caused by DL data transmission between the AN and UE due to the air interface transmission and AN packet processing:

[0225] MTP_Delay_Tr_DL_air = T_AN_DL_first_ingress -T_UE_DL_last_ingress

[0226] 8. MTP delay caused by UL data transmission between the AN and DWDPF in the CN:

[0227] MTP_Delay_Tr_UL_CN = T_AN_UL_first_egress -T_DWDPF_UL_last_ingress

[0228] 9. MTP delay caused by DL data transmission between the DWDPF and AN in the CN:

[0229] MTP_Delay_Tr_DL_CN = T_DWDPF_DL_first_egress -T_AN_DL_last_ingress

[0230] The UE 902 may include one or more of above calculated MTP delay parameters in the QoS report in accordance with the MTP reporting configuration. In some scenarios, the UE 902 may include in the QoS report one or more of received timestamps to the report receiving NF. The QoS report may include one or more of following parameters:

[0231] -Service ID, and / or Application ID

[0232] -UE ID

[0233] -Session ID

[0234] -QoS monitoring report

[0235] -QoS parameters to be reported: e.g. MTP delay measurement

[0236] -QoS report ID: to identify the QoS report, e.g. the numbering of the QoS report

[0237] -QoS report timestamp: to indicate the time the QoS report is generated

[0238] -Track Alias ID

[0239] -Group ID

[0240] -Object ID

[0241] -Object Send Order ID

[0242] -QoS measurement role

[0243] -List of measured QoS parameter and value, which may contain one or more parameters, e.g. 5 parameters, such as T_E2E_MTP_delay <20 ms>, MTP_Delay_Tr_Pr <5 ms>, MTP_Delay_Tr_UL<5 ms>, MTP_Delay_Tr_DL<5 ms>, and MTP_Delay Pr<5 ms>

[0244] -QoS processing function information: for example, the ID of the DWCF, the IP address and port number of the DWCF, the URL of the DWCF.

[0245] The list of measured QoS parameters may include one or more timestamps the UE stores. The QoS processing function may use the reported timestamps to calculate end to end MTP delay, or MTP delay caused by certain network segments or data processing functions.

[0246] The QoS report could be sent from the UE 902 to the DWCF 914 or any other network entity engaged in QoS in a number of ways. For example, in method 1, the QoS report may be sent from the UE 902 to DWCF 914 via the AN 904, CMF 906, SMF 912, and PF 913 (FIG. 9) . In method 2, the QoS report may be sent from the UE 902 to DWCF 914 via the AN 904, CMF 906, and SMF 912. In method 3, the QoS report may be sent from the UE 902 to DWCF 914 via the AN 904 and CMF 906. In method 4, the QoS report may be sent from the UE 902 to DWCF 914 via the AN 904. In method 5, the QoS report may be sent from the UE 902 to DWCF 914 via the AN 904 and DWDPF 910. In method 6, the QoS report may be sent from the UE 902 to DWCF 914 via the AN 904, DWDPF 910, and SMF 912.

[0247] Example routing of QoS reports and corresponding acknowledgements in various implementations are illustrated by the diagram 1100 shown in FIG. 9. The diagram 11 illustrates at least six different methods, as indicated by the numbering of methods given above.

[0248] Step 1a (common for all methods) : The UE may send the QoS report in a UE QoS report message towards the DWCF via the AN.

[0249] Step 1b (of methods 1, 2, and 3) : The AN may forward the QoS Report in an AN UE QoS report message to the CMF.

[0250] Step 2 (of methods 1 and 2) : The CMF may forward the QoS Report in a CMF UE QoS report message to the SMF.

[0251] The SMF may collect one or more QoS Reports from one or multiple UEs to calculate average MTP delay, e.g. single object MTP delay, single UE MTP average delay, multiple UE MTP average delay.

[0252] Step 3 (of method 1) : The SMF may send the QoS Report with calculated MTP delay to the PF.

[0253] The PF may collect one or more QoS Reports from one or more SMFs to calculate average MTP delay, e.g. single media object MTP delay (reported by the UE) , single UE MTP average delay, multiple UE MTP average delay.

[0254] Step 4a (of method 1) : The PF may send the QoS Report with calculated MTP delay in a PF QoS report message to the DWCF (or to the AF / AS directly or via CP GW indirectly) .

[0255] Step 4b (of method 1) : The DWCF may send a PF QoS report acknowledgment (Ack) message to the PF to acknowledge the receipt of the message in step 4a.

[0256] Step 5 (of method 1) : The PF may send a SMF QoS report Ack to the SMF to acknowledge the receipt of the message in step 3.

[0257] Step 6a (for method 2) : The SMF may send the QoS Report with calculated MTP delay in a SMF QoS report message to the DWCF (or to the AF / AS directly or via CP GW indirectly) .

[0258] Step 6b (of method 2) : The DWCF may send a SMF QoS report acknowledgment (Ack) message to the SMF to acknowledge the receipt of the message in step 6a.

[0259] Step 7 (of methods 1 and 2) : The SMF may send a CMF UE QoS report Ack message to the CMF to acknowledge the receipt of the message in step 2.

[0260] Step 8a (of method 3) : The CMF may forward the QoS Report in a CMF UE QoS report message to the DWCF.

[0261] Step 8b (of method 3) : The DWCF may send a CMF QoS report Ack to the CMF to acknowledge the receipt of the message in step 8a.

[0262] Step 9 (of methods 1, 2, and 3) : The CMF may send an AN UE QoS report Ack message to the AN to acknowledge the receipt of the message in step 1b.

[0263] Step 10a (of method 4) : The AN may use the QoS processing function information parameter receives from the UE to determine which NF to forward the UE QoS Report to. For example, the AN may forward the QoS Report in an AN UE QoS report message to the DWCF.

[0264] Step 10b (of method 4) : The DWCF may send an AN UE QoS report Ack message to the AN to acknowledge the receipt of the message in step 10a.

[0265] Step 11 (of methods 5 and 6) : The AN may use the QoS processing function information parameter receives from the UE to determine which NF to forward the UE QoS Report to. For example, the AN may forward the QoS Report in an AN UE QoS report message to the DWDPF. The message may be sent in a CP message, or UP message. The UP massage may be carried in packet header of the tunnel protocol.

[0266] The DWDPF may collect one or more QoS Reports from one or more UEs to calculate average MTP delay, e.g. single media object MTP delay (reported by the UE) , single UE MTP average delay, multiple UE MTP average delay.

[0267] Step 12a (of method 5) : The DWDPF may send the QoS Report with calculated MTP delay in a DWDPF QoS report message to the DWCF (or to the AF / AS directly or via CP GW indirectly) .

[0268] Step 12b (of method 5) : The DWCF may send a DWDPF QoS report Ack to the DWDPF to acknowledge the receipt of the message in step 12b.

[0269] Step 13 (of method 6) : The DWDPF may send the QoS Report with calculated MTP delay in a DWDPF QoS report message to the SMF.

[0270] The SMF may collect one or more QoS Reports from one or more UEs to calculate average MTP delay, e.g. single media object MTP delay (reported by the UE) , single UE MTP average delay, multiple UE MTP average delay.

[0271] Step 14a (of method 6) : The SMF may send the QoS Report with calculated MTP delay in a SMF QoS report message to the DWCF (or to the AF / AS directly or via CP GW indirectly) .

[0272] Step 14b (of method 6) : The DWCF may send a SMF QoS report Ack to the SMF to acknowledge the receipt of the message in step 14b.

[0273] Step 15 (of methods 5 and 6) : The DWDPF may send an AN UE QoS report Ack to the AN to acknowledge the receipt of the message in step 11.

[0274] Step 16 (of method 6) : The SMF may send a DWDPF QoS report Ack to the DWDPF to acknowledge the receipt of the message in step 13. The message may be sent in a CP message, or UP message. The UP massage may be carried in packet header of the tunnel protocol.

[0275] Step 17 (of all methods) : The CN may send a UE QoS report Ack to the UE to acknowledge the receipt of the message in step 1.

[0276] In some implementations, during the QoS measurement process, the AN may store timestamps in the packet header. These timestamps may not include the timestamps that the UE receives the first and the last packets of media object (or PDU set) and timestamp T_consume that the UE consumes the media object. The AN may request the UE to report one or more of following QoS parameters:

[0277] -timestamps related to media object creation and consumption (e.g. T_create, T_consume)

[0278] -timestamps related to packet transmission (e.g. T_UE_UL_first_egress, T_UE_UL_last_egress, T_UE_DL_first_ingress, and T_UE_DL_last_ingress) ,

[0279] -MTP delay caused by DL data transmission MTP_Delay_Tr_DL_air

[0280] -end-to-end MTP delay

[0281] By using the UE reported QoS parameters, and timestamps that the AN collected from the packet headers, the AN may calculate one or more QoS parameters that may be used by different NFs.

[0282] For example, the DWCF may be interested in end-to-end MTP delay T_E2E_MTP_delay, and MTP delay MTP_Delay_Pr caused by data processing in the DWDPF.

[0283] The SMF may be interested in the

[0284] -MTP delay caused by UL data transmission MTP_Delay_Tr_UL between the UE and DWDPF,

[0285] -MTP delay caused by DL data transmission MTP_Delay_Tr_DL between the DWDPF and UE,

[0286] -MTP delay caused by UL data transmission between the UE and AN due to the air interface transmission and AN packet processing MTP_Delay_Tr_UL_air,

[0287] -MTP delay caused by DL data transmission between the AN and UE due to the air interface transmission and AN packet processing MTP_Delay_Tr_DL_air,

[0288] -MTP delay caused by UL data transmission between the AN and DWDPF in the CN MTP_Delay_Tr_UL_CN

[0289] -MTP delay caused by DL data transmission between the DWDPF and AN in the CN MTP_Delay_Tr_DL_CN

[0290] The PF may be interested in the average MTP delay caused by UL data transmission MTP_Delay_Tr_UL and DL data transmission MTP_Delay_Tr_DL, and average MTP delay caused by data processing in the DWDPF MTP_Delay_Pr.

[0291] The SMF, PF, DWCF may request to report other MTP delays caused by transmissions in the UL and DL between the AN and DPF, between the DPF and DWDPF, which can be calculated similarly.

[0292] The AN may include in the QoS report one or more of above calculated MTP delay parameters according to the MTP reporting configuration. In some scenarios, the AN may include in the QoS report one or more of received timestamps to the report receiving NF. The AN QoS report may include one or more of following parameters:

[0293] -Service ID and / or Application ID

[0294] -UE ID

[0295] -AN ID

[0296] -Session ID

[0297] -QoS monitoring report

[0298] -QoS parameters to be reported: e.g. MTP delay measurements

[0299] -QoS report ID

[0300] -QoS report timestamp

[0301] -Track Alias ID

[0302] -Group ID

[0303] -Object ID

[0304] -Object Send Order ID

[0305] -QoS measurement role.

[0306] -List of measured QoS parameters: e.g. the list may contain one or more of parameters, e.g. 5 parameters, but not limited to T_E2E_MTP_delay, MTP_Delay_Tr_Pr, MTP_Delay_Tr_UL, MTP_Delay_Tr_DL, and MTP_Delay_Pr.

[0307] -List of measured QoS value of QoS parameter: e.g. 5 measurement values of 20 ms, 15 ms, 5 ms, 5 ms, 5 ms.

[0308] -QoS processing function information: for example, the ID of the DWCF, the IP address and port number of the DWCF, the URL of the DWCF.

[0309] The list of measured QoS parameters may include one or more timestamps the UE stores. The QoS processing function may use the reported timestamps to calculate end to end MTP delay, or MTP delay caused by certain network segments or data processing functions.

[0310] In some cases, the QoS report is initially generated by a network entity other than the UE 902. For example, in one implementation, the AN 904 may be configured to generate the QoS report. It may generate and send a QoS report request to the UE 902, which may respond with a UE QoS report message providing timestamp (s) and / or calculated MTP delay measurements to the AN 904. The request may list the QoS parameters to be reported. The AN 904 may then use the received measurements to generate an AN QoS report for transmission to one or more NF, such as DWCF 914. In one embodiment, the AN 904 sends the  AN QoS report directly to the DWCF 914. The AN 904 may have service-based interface (SBI) to communicate with the DWDPF 914 over the control plane.

[0311] In another embodiment, the AN 904 may send the AN QoS report to the DWCF 914 via the DWDPF 910. In this embodiment, the AN 904 may use a CP interface, e.g. SBI, or an UP interface, e.g. using a tunnel header, to communicate with the DWDPF 910. The DWDPF 910 may use a CP interface, such as SBI, to communicate with the DWCF 914.

[0312] In a third embodiment, the AN 904 may send the AN QoS report to the DWCF 914 via the CMF 906, SMF 912. The CMF 906 may be the interface in the CP between the AN 904 and CN. The AN 904 may send the AN QoS report to the CMF 906, then the CMF 906 may forward the AN QoS report message to the destination. An AN QoS report message from the AN 904 may include the AN QoS report and other parameters such as SMF information or addressing and session ID or other such data. The CMF 906 may use this data to identify the SMF 912 to which to send the report.

[0313] These three embodiments are illustrated in the signal diagram 1200 of FIG. 10.

[0314] Step 1a: The AN may send a UE QoS report request message to the UE. The message may include one or more of following parameters:

[0315] -Service ID and / or Application ID

[0316] -Session ID: the ID of session, e.g. a XR session between the UE and DWDPF.

[0317] -QoS monitoring report

[0318] -QoS parameters to be reported: e.g. MTP delay measurements.

[0319] -Track Alias ID: to indicate which Track Alias of MoQ Object Stream the QoS may be monitored. If the Track Alias ID is set to a special value, e.g. “ALL” , QoS of all Tracks of the Object may be monitored.

[0320] -Group ID: to indicate ID of Group of MoQ Object Stream the QoS may be monitored. If the Group ID is set to a special value, e.g. “ALL” , the QoS of all Groups of the Object may be monitored.

[0321] -Object ID: to indicate ID of Object of MoQ Object Stream the QoS may be monitored. If the Object ID is set to a special value, e.g. “ALL” , the QoS of all Groups of the Object may be monitored.

[0322] -Object Send Order ID: to indicate which Object Send Order of MoQ Object Stream the QoS parameters may be monitored.

[0323] -List of QoS parameter to be reported: e.g. the list may contain one or more of parameters, e.g. 6 parameters, but not limited to, T_create, T_consume, T_UE_UL_first_egress, T_UE_UL_last_egress, T_UE_DL_first_ingress, and T_UE_DL_last_ingress.

[0324] Step 1b: The UE may send a UE QoS report response message to the AN. The message may include one or more of following parameters:

[0325] -Service ID and / or Application ID

[0326] -UE ID: The ID of UE or user that is used to identified the UE by the DWCF, e.g. a temporary UE ID, SUPI, GUTI, subscriber ID in the MoQ metadata.

[0327] -Session ID: the ID of session, e.g. a XR session between the UE and DWDPF.

[0328] -QoS monitoring report

[0329] -QoS parameters to be reported: e.g. MTP delay measurements.

[0330] -QoS report ID: To identify the QoS report, e.g. the numbering of the QoS report.

[0331] -QoS report timestamp: To indicate the time the QoS report is generated.

[0332] -Track Alias ID: to indicate which Track Alias of MoQ Object Stream the QoS may be monitored. If the Track Alias ID is set to a special value, e.g. “ALL” , QoS of all Tracks of the Object may be monitored.

[0333] -Group ID: to indicate ID of Group of MoQ Object Stream the QoS may be monitored. If the Group ID is set to a special value, e.g. “ALL” , the QoS of all Groups of the Object may be monitored.

[0334] -Object ID: to indicate ID of Object of MoQ Object Stream the QoS may be monitored. If the Object ID is set to a special value, e.g. “ALL” , the QoS of all Groups of the Object may be monitored.

[0335] -Object Send Order ID: to indicate which Object Send Order of MoQ Object Stream the QoS parameters may be monitored.

[0336] -QoS measurement role: e.g. Leader or Follower.

[0337] -List of measured QoS parameter: e.g. the list may contain one or more of parameters, e.g. 6 parameters, but not limited to, T_create, T_consume, T_UE_UL_first_egress, T_UE_UL_last_egress, T_UE_DL_first_ingress, and T_UE_DL_last_ingress.

[0338] -List of measured QoS value of QoS parameter: e.g. 6 timestamps of T_create, T_consume, T_UE_UL_first_egress, T_UE_UL_last_egress, T_UE_DL_first_ingress, and T_UE_DL_last_ingress.

[0339] Step 2: From the QoS report parameters received in step 1b, the AN may create AN QoS report according to the QoS report configuration for the AN. The AN QoS may include one or more of following described earlier.

[0340] There may be three methods that the AN may use to send the AN QoS report to the CP NFs, such as DWCF. Other methods may be developed based on these three methods 1, 2 and 3.

[0341] QoS report method 1: The AN sends AN QoS report to the DWCF (or AF, or AS) directly. This method may be implemented as shown in steps 3a and 3b. In this method, the AN may have SBI to communicate with DWCF in the CP.

[0342] Step 3a: The AN may send an AN QoS report message to the DWCF. The message may include one or more of parameters: AN QoS report, DWCF information (e.g. one or more of DWCF ID, DWCF address (DWCF IP address, port number) .

[0343] Step 3b: The DWCF may send an AN QoS report Ack to the AN to confirm the receipt of the message in step 3a.

[0344] QoS report method 2: The AN sends AN QoS report to the DWCF (or AF, or AS) via DWDPF. In this method, the AN may use a CP interface, e.g. SBI, or UP interface (e.g. send AN QoS report in a tunnel header) to communicate with the DWDPF. The DWDPF may use a CP interface, e.g. SBI, to forward the QoS report to the DWCF. This method may be implemented as shown in steps 4 to 6.

[0345] Step 4: The AN may send an AN QoS report message to the DWDPF. The message may include one or more of parameters: AN QoS report, DWCF information (e.g. one or more of DWCF ID, DWCF address (DWCF IP address, port number) , Session ID.

[0346] The DWDPF may use one or multiple AN QoS reports to calculated single object MTP delay, single UE average MTP delay, or multiple UE average MTP delay for end-to-end MTP delay, or MTP delay caused by UL or DL transmissions, or data processing in the DWDPF.

[0347] Step 5a: The DWDPF may use the information received from the AN QoS report message, such as DWCF information and Session ID to identify which DWCF to send the QoS report to. The DWDPF may send a DWDPF QoS report to the DWCF. The message may include one or more of following parameters: AN QoS report received from the AN, calculated QoS parameters (e.g. one or more of single object MTP delay, single UE average MTP delay, and multiple UE average MTP delay for end-to-end MTP delay, or MTP delay caused by UL or DL transmissions, or data processing in the DWDPF) .

[0348] Step 5b: The DWCF may send a DWDPF QoS report Ack to the DWDPF to confirm the receipt of the message in step 5a.

[0349] Step 6: The DWDPF may send an AN QoS report Ack to the DWDPF to confirm the receipt of the message in step 4.

[0350] QoS report method 3: The AN may send the AN QoS report to the DWCF (or AF, or AS) via the CMF, SMF. This method may be implemented as shown in steps 7a to 12b. The CMF may be the interface in the CP between the AN and CN. The AN may send the QoS report to the CMF, then the CMF may forward the QoS report message to the destination.

[0351] Step 7a: The AN may send an AN QoS report message to the CMF. The message may include one or more of parameters: AN QoS report, SMF information (e.g. one or more of SMF ID, SMF address (SMF IP address, port number) , Session ID, UE ID.

[0352] Step 7b: The CMF receives the AN QoS report message from the AN. The CMF may use the received information, e.g. UE ID and session ID, or SMF information, to identify the SMF that has established the UP (or DP) connection for this UE. The CMF may send a CMF QoS report to the SMF. The message may include one or more of following parameters: AN QoS report received from the AN in step 7a, AN ID, UE ID, Session ID.

[0353] Step 8a: The SMF may use the received information such as UE ID, Session ID to identify the DWCF that has served the Session ID of the UE. The SMF may send an SMF QoS report message to the DWCF. The message may include one or more of following parameters: AN QoS report received from the AN in step 7a, AN ID, UE ID, Session ID.

[0354] Step 8b: The DWCF may send an SMF QoS report Ack to the SMF to confirm the receipt of the message in step 8a.

[0355] Step 9: Alternative to step 8a, the SMF may send an SMF QoS report message to the PF. The message may include one or more of following parameters: AN QoS report received from the AN in step 7a, AN ID, UE ID, Session ID.

[0356] Step 10a: The PF may use the information received from the SMF to identify a DWCF. The PF may forward the message received from the SMF to the DWCF.

[0357] Step 10b: The DWCF may send a PF QoS report Ack message to the PF to confirm the receipt of the message in step 10a.

[0358] Step 11: The PF may send an SMF QoS report Ack message to the SMF to confirm the receipt of the message in step 9.

[0359] Step 12a: The SMF may send a CMF QoS report Ack message to the CMF to confirm the receipt of the message in step 7b.

[0360] Step 12b: The CMF may send an AN QoS report Ack message to the AN to confirm the receipt of the message in step 7a.

[0361] In a similar manner, the DWDPF 910 may be instructed by the DWCF 914, or the XR application server AS or other QoS monitoring entity, to generate a QoS report. The DWDPF 910 may store timestamps extracted from received packets, as described above.

[0362] The DWDPF 910 may report one or more of the stored timestamps to the DWCF 914 as configured, for example: T_create, T_UE_UL_first_egress, T_AN_UL_last_ingress, T_DWDPF_UL_first_ingress, T_DWDPF_UL_last_ingress, T_DWDPF_DL_last_egress, and T_Object_Processing_Time. The DWCF 914 may use the received timestamps to calculate one or more of the following MTP delays in the UL and DWDPF 910:

[0363] 1. MTP delay caused by UL data transmission between the UE and DWDPF:

[0364] MTP_Delay_Tr_UL = T_DWDPF_DL_last_ingress -T_UE_UL_first_egress

[0365] 2. MTP delay caused by processing in DWDPF:

[0366] MTP_Delay_Pr = T_Object_Processing_Time

[0367] 3. Total MTP delay in the DWDPF:

[0368] MTP_Delay_DWDPF = T_DWDPF_DL_last_egress -T_DWDPF_UL_first_ingress

[0369] The DWDPF may generate a DWDPF QoS report. The DWDPF QoS report may include one or more parameters similar to the AN QoS report. The DWDPF QoS report may be sent directly to the DWCF 914, sent to the DWCF 914 via the SMF 912, or sent to the DWCF 914 via SMF 912 and PF 913. Other QoS reporting methods by the DWDPF can be implemented based on these three exemplary methods. MTP parameters and / or average MTP delay parameters may be calculated by the SMF 912 and / or PF in some implementations.

[0370] FIG. 11 shows an example signal diagram 1300 illustrating three illustrative methods of obtaining a QoS report from the DWDPF.

[0371] Method 1: The DWDPF may send a DWDPF QoS report message to the report receiving function DWCF directly.

[0372] Step 1a: The DWDPF may send a DWDPF QoS report message to the report receiving function, e.g. DWCF, or AF directly or via CP GW, or AS directly or via UP GW. The message may include one or more of QoS reports.

[0373] Step 1b: The report receiving function, e.g. DWCF, may send a DWDPF QoS report Ack message to the DWDPF to confirm the receipt of message in step 1a.

[0374] Method 2: The DWDPF may send a DWDPF QoS report message to the SMF. The SMF may then send to the DWCF QoS report that include timestamps received from the DWDPF or calculated MTP delay parameters.

[0375] Method 2 includes steps 2 to 4.

[0376] Step 2: The DWDPF may send a DWDPF QoS report message to the SMF. The message may include one or more of QoS reports.

[0377] -MTP delay parameters of individual media object sent from a specific UE via an AN node to a DWDPF,

[0378] -average MTP delay parameters of multiple media objects sent from a specific UE via an AN node to a DWDPF,

[0379] -average MTP delay parameters of individual media objects sent from multiple UEs of a UE group (or all UEs) via an AN node to a DWDPF.

[0380] -average MTP delay parameters of multiple media objects sent from multiple UEs of a UE group (or all UEs) via an AN node to a DWDPF.

[0381] Step 3a: The SMF may send SMF QoS report message to the DWCF. The message may include one or more QoS reports. Each QoS report may include timestamps received from the DWDPF or calculated MTP delay parameters.

[0382] Step 3b: The DWCF may send a SMF QoS report Ack message to the SMF to confirm the receipt of message in step 3a.

[0383] Step 4: The SMF may send a DWDPF QoS report Ack message to the DWDPF to confirm the receipt of message in step 2.

[0384] Method 3: The DWDPF may send a DWDPF QoS report message to the SMF. The SMF may forward the received QoS report to the PF. The PF may process the QoS reports and calculate MTP delay parameters. The PF may send to the DWCF QoS report that include timestamps received from the DWDPF or calculated MTP delay parameters.

[0385] Method 3 includes steps 5 to 9.

[0386] Step 5: The DWDPF may send a DWDPF QoS report message to the SMF. The message may include one or more of QoS reports.

[0387] The SMF may calculate MTP delay parameters for following scenarios, but not limited to:

[0388] -MTP delay parameters of individual media object sent from a specific UE via an AN node to a DWDPF,

[0389] -average MTP delay parameters of multiple media objects sent from a specific UE via an AN node to a DWDPF,

[0390] -average MTP delay parameters of individual media objects sent from multiple UEs of a UE group (or all UEs) via an AN node to a DWDPF.

[0391] -average MTP delay parameters of multiple media objects sent from multiple UEs of a UE group (or all UEs) via an AN node to a DWDPF.

[0392] Step 6: The SMF may send SMF QoS report message to the PF. The message may include one or more QoS reports. Each QoS report may include timestamps received from the DWDPF or calculated MTP delay parameters.

[0393] The PF may calculate MTP delay parameters for following scenarios, but not limited to:

[0394] -MTP delay parameters of individual media object sent from a specific UE via an AN node to a DWDPF,

[0395] -average MTP delay parameters of multiple media objects sent from a specific UE via an AN node to a DWDPF,

[0396] -average MTP delay parameters of individual media objects sent from multiple UEs of a UE group (or all UEs) via an AN node to a DWDPF.

[0397] -average MTP delay parameters of multiple media objects sent from multiple UEs of a UE group (or all UEs) via an AN node to a DWDPF.

[0398] Step 7a: The PF may send PF QoS report message to the DWDPF. The message may include one or more QoS reports. Each QoS report may include timestamps received from the DWDPF or calculated MTP delay parameters.

[0399] Step 7b: The DWDPF may send a PF QoS report Ack message to the PF to confirm the receipt of message in step 7a.

[0400] Step 8: The PF may send an SMF QoS report Ack message to the SMF to confirm the receipt of message in step 6.

[0401] Step 9: The SMF may send a DWDPF QoS report Ack message to the DWDPF to confirm the receipt of message in step 5.

[0402] In some examples, the DWDPF 910 may further request additional timestamp data from the UE 902 or other NF relating to downlink packets in order to determine additional MTP delays and include them in the QoS report.

[0403] The MTP delays determined by the UE, the AN, the DWDPF or other network entities may be compared with maximum threshold values to identify an MTP delay that exceeds a maximum threshold. In some cases, the specific segment of the network that caused the excessive delay may be identified based on the MTP delays and / or timestamp data. Remedial actions may be taken by one or more network elements to address the delay and, in particular, the excessive delay attributable to an identified network segment. The remedial action may include adding resources, changing network routing, reducing media resolution, restarting one or more services, and / or other such actions.

[0404] In the present disclosure, the terms “a” , “an” and “one” are defined to mean “at least one” , that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0405] In the present disclosure, terms such as “substantially” , “generally” and “about” , which modify a value, condition or characteristic of a feature of an embodiment, should be understood to mean that the value, condition or characteristic is defined within tolerances that are acceptable for the proper operation of this embodiment for its intended application.

[0406] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled” , and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements.  For example, the connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0407] In the present disclosure, expressions such as “match” , “matching” and “matched” , including variants and derivatives thereof, are intended to refer herein to a condition in which two or more elements are either the same or within some predetermined tolerance of each other. That is, these terms are meant to encompass not only “exactly” or “identically” matching the two elements but also “substantially” , “approximately” or “subjectively” matching the two or more elements, as well as providing a higher or best match among a plurality of matching possibilities.

[0408] In the present disclosure, the expression “based on” is intended to mean “based at least partly on” , that is, this expression can mean “based solely on” or “based partially on” , and so should not be interpreted in a limited manner. More particularly, the expression “based on” could also be understood as meaning “depending on” , “representative of” , “indicative of” , “associated with” or similar expressions.

[0409] In the present disclosure, the terms "system" and "network" may be used interchangeably in embodiments of this application. "At least one" means one or more, and "a plurality of" means two or more. The term "and / or" describes an association relationship of associated objects and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character " / " usually indicates an "or" relationship between associated objects. "At least one of the following items (pieces) " or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, "at least one of A, B, or C" includes A, B, C, A and B, A and C, B and C, or A, B, and C, and "at least one of A, B, and C" may also be understood as including A, B, C, A and B, A and C, B and C, or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as "first" and "second" in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0410] In the present application, the phrase “at least one of…or…” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements. The term “and / or” is intended to indicate that either of the two elements may be included or both of the elements may be included.

[0411] A person skilled in the art will understand that embodiments of this application may be provided as a method, an apparatus (or system) , a computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

[0412] This application is described with reference to the flowcharts and / or block diagrams of the method, the device (system) , and the computer program product according to this application. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device to generate a machine, so that the instructions executed by the computer or the processor of the another programmable data processing device generate an apparatus for implementing a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0413] The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0414] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or the another  programmable device provide steps for implementing a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0415] It will be understood that a person skilled in the art may make various modifications and variations to this application without departing from the scope of this application. This application is intended to cover these modifications and variations of this application provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

[0416] Throughout the present disclosure, a processor, a processor system, an application processor, a baseband processor, a processor circuit, or a processor core may be collectively referred to as a processor. A processor may include one or more of a central processing unit (CPU) , a digital signal processor (DSP) , a microprocessor unit (MPU) , a microcontroller unit, (MCU) , a graphics processing unit (GPU) , a field programmable gate array (FPGA) , an artificial intelligence (AI) processor, or a neural network processing unit (NPU) , or a combination of at least two of these integrated circuit forms.

[0417] Throughout the present disclosure, a memory may include one or more of the following storage media: a RAM, a static random access memory (SRAM) , a dynamic random access memory (DRAM) , a phase-change memory (PCM) , a resistive random access memory (ReRAM) , a magnetoresistive random access memory (MRAM) , a ferroelectric random access memory (FRAM) , a cache, a register, a read-only memory (ROM) , a flash memory, an erasable programmable read-only memory (EPROM) , a hard disk, and / or the like. In an example, the computer program instructions used to execute embodiments contained herein may be stored in a non-volatile memory. When a terminal runs, part or all of corresponding computer program instructions may be loaded into a memory that has a higher transmission speed with a corresponding processor, for example, the instructions may be loaded into at least a part of a memory such that the processor executes the computer program instructions to perform the steps in of embodiments described herein.

[0418] The various embodiments presented above are merely examples and are in no way meant to limit the scope of this application. Variations of the innovations described herein will be apparent to persons of ordinary skill in the art, such variations being within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments including a sub-combination of features which may not be explicitly described above. In addition, features from one or more of the above-described example embodiments may be selected and combined to create alternative example embodiments including a combination of features which may not be explicitly described above. Features suitable for such combinations and sub-combinations would be readily apparent to persons skilled in the art upon review of the present application as a whole. The subject matter described herein and in the recited claims intends to cover and embrace all suitable changes in technology.

Claims

1.A method of determining quality of service for Extended Reality (XR) media, comprising:at a user device, obtaining data via a sensor;in response to obtaining the data, generating and transmitting a media object having a media payload and media metadata, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp;receiving, at the user device via a network connection, an XR media object associated with the media object;displaying, at a display time, on an output display of the user device, an image based on the XR media object;determining a motion-to-photon (MTP) delay based on a difference between the display time and the first timestamp; andtransmitting a report regarding the MTP delay to a remote server.2.The method of claim 1, wherein determining the MTP delay includes detecting an association between the XR media object and the media object.3.The method of claim 2, wherein detecting the association includes matching a unique identifier in the media metadata with a corresponding unique identifier in metadata attached to the XR media object.4.The method of claim 1, wherein the media payload includes at least data regarding the data from the sensor.5.The method of claim 4, wherein the sensor includes an imaging device and wherein the data includes capture of image data by the imaging device, and wherein the media payload includes the image data.6.The method of claim 1, wherein the XR media object includes media data, and wherein displaying includes rendering the image on the output display based on the media data.7.The method of claim 1, wherein the XR media object includes metadata that includes the quality of service monitoring indicator and a server timestamp.8.The method of claim 7, wherein the XR media object includes a plurality of timestamps including the first timestamp, the server timestamp and a plurality of timestamps associated with one or more access network or core network functions.9.A method of determining quality of service for Extended Reality (XR) media, comprising:receiving, at a XR application server, a media object from a user device having a media payload and media metadata, the media payload being associated with data obtained via a sensor within the user device, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp;processing the media object to generate XR media data and creating an XR media object associated with the media object;adding a server timestamp to the XR media object and transmitting the XR media object to the user device; andreceiving a communication from the user device containing a report of a motion-to-photon (MTP) delay based on a difference between a display time of an image based on the XR media object on an output display of the user device and the first timestamp.10.A user device configured to determine quality of service for Extended Reality (XR) media, comprising:at least one processor;a sensor configured to obtain data and send the data to the at least one processor;an output display coupled to the at least one processor;memory coupled to the at least one processor and storing processor executable instructions that, when executed by the at least one processor, are to cause the at least one processor to:generate and transmit, in response to obtaining the data, a media object having a media payload and media metadata, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp;receive, via a network connection, an XR media object associated with the media object;display, at a display time, on the output display, an image based on the XR media object;determine a motion-to-photon (MTP) delay based on a difference between the display time and the first timestamp; andtransmit a report regarding the MTP delay to a remote server.11.The user device of claim 10, wherein the instructions, when executed, are to cause the at least one processor to determine the MTP delay by detecting an association between the XR media object and the media object.12.The user device of claim 11, wherein detecting the association includes matching a unique identifier in the media metadata with a corresponding unique identifier in metadata attached to the XR media object.13.The user device of claim 10, wherein the media payload includes the data from the sensor.14.The user device of claim 13, wherein the sensor includes an imaging device and wherein the data includes capture of image data by the imaging device, and wherein the media payload includes the image data.15.The user device of claim 10, wherein the XR media object includes media data, and wherein the instructions, when executed, are to cause the at least one processor to display by rendering the image on the output display based on the media data.16.The user device of claim 10, wherein the XR media object includes metadata that includes the quality of service indicator and a server timestamp.17.The user device of claim 16, wherein the XR media object includes a plurality of timestamps including the first timestamp, the server timestamp and a plurality of timestamps associated with one or more access network or core network functions.18.A non-transitory computer-readable medium containing instructions to determine quality of service for Extended Reality (XR) media, wherein the instructions, when executed by a processor, are to cause the processor to:obtain data via a sensor;generate and transmit, in response obtaining the data, a media object having a media payload and media metadata, the media metadata including a quality of service monitoring indicator (QMI) and a first timestamp;receive, via a network connection, an XR media object associated with the media object;display, at a display time, on an output display, an image based on the XR media object;determine a motion-to-photon (MTP) delay based on a difference between the display time and the first timestamp; andtransmit a report regarding the MTP delay to a remote server.19.A computer-readable medium storing computer-executable instructions that, when executed by one or more processors, are to cause the one or more processors to carry out the method of any one of claims 1 to 11.20.A computer program comprising instructions which, when executed by a computing device, are to cause the computing device to carry out the method of any one of claims 1 to 11.21.A computing device comprising means to perform the method of any one of claims 1 to 11.22.A computing device comprising at least one processor and a memory coupled to the at least one processor, wherein the memory stores instructions that, when executed by the at least one processor, are to cause the at least one processor to perform the method of any one of claims 1 to 11.

Images