Exposure of shared connection link delay performance events in wireless communication network

Abstract

There is provided herein a method performed by a data collection application function for exposure of a link delay performance event of an application experienced via a shared connection between a first device and a second device, the method comprising: receiving a configuration of a data access profile for data collection, the data relates to a link delay in the shared connection; and applying the data access profile to the at least one data collection client. The method further includes receiving collected link delay measurements from at least one data collection client; processing the link delay measurements based in part on the data access profile to generate one or more link delay performance events; and exposing one or more link delay performance events corresponding to the application experienced via the shared connection.

Description

Technical Field

[0001] The topics disclosed in this document generally relate to the area of ​​exposing link latency performance events of tethered connections in wireless communication networks. This document defines a data collection application function, a method performed by the data collection application function, a data collection client, and a method performed by the data collection client. Background Technology

[0002] In many interactive and immersive applications with challenging requirements for latency, speed, and reliability, the application experience is delivered via a tethered connection, where an endpoint Personal IoT Network Element (PINE) device is connected to a gateway device, which in turn connects to a 3GPP access network (e.g., 4G, 5G, etc.) for internet connectivity. Examples of this application experience delivery include AR / VR experiences, where the PINE is a head-mounted display (HMD) in the form of AR / VR glasses, and the gateway is a mobile phone, or alternatively, a 3GPP User Equipment (UE). Therefore, the E2E connection between the client and the application server relies on at least three heterogeneous network segments: the tethered link, the 3GPP connectivity, and the data network (DN) link. The tethered link and the DN link are not within the 3GPP scope. The tethering connection between the PINE and the gateway typically relies on Wi-Fi, Bluetooth, or unlicensed spectrum radio access technologies. This connection impacts E2E QoS, and in fact, both the tethered link and the DN link reduce the effectiveness of QoS rules and policies employed within the 3GPP network. Summary of the Invention

[0003] 3GPP networks need to monitor and extract link metrics regarding the performance of out-of-range segments (e.g., tethered links, DN links) across heterogeneous E2E network paths. 3GPP networks can also perform analysis of these link metrics and derive statistical characteristics of expected performance. Furthermore, such 3GPP networks can adapt to 3GPP QoS rules and policies, compensate for the degraded effects of out-of-range segments (e.g., additional latency), and seamlessly meet the enhanced user experience requirements of E2E applications.

[0004] This document discloses a process for exposing link latency performance events of shared connections in a wireless communication network. This process can be implemented through a data collection application function, a method performed by the data collection application function, a data collection client, and a method performed by the data collection client.

[0005] Therefore, a data collection application function is provided for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The data collection application function includes: a processor; and memory coupled to the processor. The processor is configured such that the data collection application function: receives a configuration of a data access profile for data collection, the data relating to link latency in the shared connection; applies the data access profile to at least one data collection client; receives collected link latency measurements from the at least one data collection client; processes the link latency measurements in part based on the data access profile to generate one or more link latency performance events; and exposes one or more application-related link latency performance events experienced via the shared connection.

[0006] A method executed by a data collection application function is also provided for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The method includes: receiving a configuration of a data access profile for data collection, the data relating to link latency in the shared connection; and applying the data access profile to at least one data collection client. The method further includes: receiving collected link latency measurements from at least one data collection client; processing the link latency measurements, in part based on the data access profile, to generate one or more link latency performance events; and exposing one or more application-related link latency performance events experienced via the shared connection.

[0007] A data collection client is also provided for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The data collection client includes a processor and memory coupled to the processor. The processor is configured to cause the device to: receive a data access profile from a data collection application function; collect link latency measurements based on the received data access profile; and send the collected link latency measurements to the data collection application function.

[0008] A method executed by a data collection client is also provided for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The method includes: receiving a data access profile from a data collection application function; collecting link latency measurements based on the received data access profile; and sending the collected link latency measurements to the data collection application function. Attached Figure Description

[0009] To illustrate the advantages and features of this disclosure as they may be obtained, the disclosure is described with reference to certain apparatuses and methods shown in the accompanying drawings. Each of these drawings depicts only certain aspects of the disclosure and should therefore not be considered as a limitation on its scope. For clarity, the drawings may have been simplified and are not necessarily drawn to scale.

[0010] A method and apparatus for exposing link delay performance events of shared connections in a wireless communication network will now be described by way of example only with reference to the accompanying drawings, in which:

[0011] Figure 1 An embodiment of a wireless communication system for exposing link delay performance events of shared connections in a wireless communication network is described;

[0012] Figure 2 A user equipment apparatus that can be used to implement the methods described herein is described;

[0013] Figure 3 Further details are provided about the network nodes that can be used to implement the methods described in this paper;

[0014] Figure 4 An overview of the core network XRM architecture for processing data packets is shown;

[0015] Figure 5 The implementation of the first sharing method as a shared independent glasses is described;

[0016] Figure 6 An implementation of AR glasses is shown, in which XR is shared with a link that exposes XR runtime as an XR runtime API to 5G or similar devices.

[0017] Figure 7 An implementation of AR glasses is shown, in which the exposure of XR runtime is supported via a shared link as a media buffer source and sink through virtualized edge network XR runtime instances;

[0018] Figure 8 The E2E path and subsequent path delays are shown;

[0019] Figure 9 An example wireless communication system is shown;

[0020] Figure 10 A general DCAF architecture is shown in a simplified format;

[0021] Figure 11 A method for shared application DCAF for data collection and reporting of non-3GPP link delays is shown;

[0022] Figure 12 The method executed by the data collection application function is shown; and

[0023] Figure 13 The method performed by the data collection client is shown. Detailed Implementation

[0024] Those skilled in the art will understand that various aspects of this disclosure can be embodied as a system, apparatus, method, or program product. Therefore, the arrangements described herein can be implemented in a completely hardware form, a completely software form (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects.

[0025] For example, the disclosed methods and apparatus can be implemented as hardware circuits, including custom-designed very large-scale integrated circuits (VLSI) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus can also be implemented in programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, processes, or functions.

[0026] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transitive. The storage device may not embody signals. In some arrangements, the storage device uses only signals for accessing the code.

[0027] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0028] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store programs for use by or in connection with an instruction execution system, apparatus, or device.

[0029] Throughout this specification, references to examples or similar language of a particular method or apparatus mean that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the method and apparatus described herein. Therefore, unless expressly stated otherwise, references to examples or similar language of a particular method or apparatus may, but not necessarily all refer to the same example, but rather mean “one or more, but not all, examples.” Unless expressly stated otherwise, the terms “including,” “comprising,” “having,” and variations thereof mean “including, but not limited to.” Unless expressly stated otherwise, the list of items does not imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms “a,” “an,” and “the” also mean “one or more.”

[0030] As used herein, a list with the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of the following” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of the following” includes one and only one single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C, excluding combinations of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C, excluding combinations of A, B, and C. As used herein, “members selected from groups consisting of A, B, and C and combinations thereof” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0031] Furthermore, the features, structures, or characteristics described herein can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a comprehensive understanding of this disclosure. However, those skilled in the art will recognize that the disclosed methods and apparatus can be practiced without one or more specific details, or by other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of this disclosure.

[0032] The aspects of the disclosed methods and apparatus are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine that, via instructions executable by the computer or other programmable data processing apparatus processor, creates components for implementing the functions / actions specified in the schematic flowcharts and / or schematic block diagrams.

[0033] The code may also be stored in a storage device that can instruct a computer, other programmable data processing apparatus or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art, which includes instructions that implement the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0034] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the function / action specified in the schematic flowchart and / or schematic block diagram.

[0035] The schematic flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products. In this regard, each block in the schematic flowcharts and / or block diagrams may represent a portion of a module, segment, or code, which includes one or more executable instructions for implementing the specified logical function(s).

[0036] It should also be noted that in some alternative implementations, the functions shown in the blocks may not appear in the order shown in the figures. For example, in fact, two blocks shown consecutively may be executed substantially concurrently, or these blocks may sometimes be executed in reverse order, depending on the functions involved. Other steps and methods may be conceived as functionally, logically, or effectively equivalent to one or more blocks or portions thereof in the figures shown.

[0037] The descriptions of the elements in each figure can be found in the elements of the subsequent figures. In all the figures, the same numbers represent the same elements.

[0038] Figure 1 An embodiment of a wireless communication system 100 for exposing link latency performance events of shared connections in a wireless communication network is described. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although Figure 1 A specific number of remote units 102 and network units 104 are depicted, but those skilled in the art will recognize that any number of remote units 102 and network units 104 can be included in the wireless communication system 100.

[0039] In one embodiment, remote unit 102 may include computing devices such as desktop computers, laptops, personal digital assistants (PDAs), tablets, smartphones, smart TVs (e.g., internet-connected TVs), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), aircraft, drones, etc. In some embodiments, remote unit 102 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 102 may be referred to as subscriber unit, mobile, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terms used in the art. Remote unit 102 may communicate directly with one or more network units in network unit 104 via UL communication signals. In some embodiments, remote unit 102 may communicate directly with other remote units 102 via sidelink communication.

[0040] Network unit 104 may be distributed across a geographical area. In some embodiments, network unit 104 may also be referred to as an access point, access terminal, base station, Node B, eNB, gNB, home Node B, relay node, device, core network, air server, radio access node, AP, NR, network entity, access and mobility management function (“AMF”), unified data management function (UDM), unified data repository (UDR), UDM / UDR, policy control function (PCF), radio access network (RAN), network slice selection function (NSSF), operation, maintenance and management (OAM), session management function (SMF), user plane function (UPF), application function, authentication server function (AUSF), security anchor function (SEAF), trusted non-3GPP gateway function (TNGF), application function, service enabler architecture layer (SEAL) function, vertical application enabler server, edge enabler server, edge configuration server, mobile edge computing platform function, mobile edge computing application, application data analytics enabler server, SEAL data delivery server, middleware entity, network slice capability management server, or any other term used in the art. Network unit 104 is typically part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network units 104. The radio access network is typically communicatively coupled to one or more core networks that may be coupled to other networks, such as the Internet and the public switched telephone network, and other networks. These and other components of the radio access network and core network are not shown, but are generally well known to those skilled in the art.

[0041] In one implementation, the wireless communication system 100 conforms to the New Radio (NR) protocol standardized in 3GPP, wherein network element 104 transmits on the downlink (DL) using an orthogonal frequency division multiple access (OFDM) modulation scheme, and remote element 102 transmits on the uplink (UL) using either a single-carrier frequency division multiple access (SC-FDMA) scheme or an OFDM scheme. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication protocol, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, etc. Protocols such as ZigBee, Sigfox, and LoraWAN are used. This disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0042] Network unit 104 can serve a number of remote units 102 within a service area (e.g., a cell or cell sector) via a wireless communication link. Network unit 104 transmits DL communication signals in the time domain, frequency domain, and / or spatial domain to serve the remote units 102.

[0043] Figure 2 User equipment device 200, which can be used to implement the methods described herein, is depicted. User equipment device 200 is used to implement one or more of the solutions described herein. User equipment device 200 conforms to one or more user equipment devices described in the embodiments herein. Specifically, user equipment device 200 may include remote unit 102, UE 435, 904, 5G device 530, 630, 730, or shared UE 1110 as described herein. User equipment device 200 may include a data collection client as defined herein. User equipment device 200 includes processor 205, memory 210, input device 215, output device 220, and transceiver 225.

[0044] Input device 215 and output device 220 can be combined into a single device, such as a touchscreen. In some implementations, user equipment device 200 does not include any input device 215 and / or output device 220. User equipment device 200 may include one or more of the following: processor 205, memory 210, and transceiver 225, and may not include input device 215 and / or output device 220.

[0045] As shown in the figure, transceiver 225 includes at least one transmitter 230 and at least one receiver 235. Transceiver 225 can communicate with one or more cells (or radio coverage areas) supported by one or more base units. Transceiver 225 can operate on unlicensed spectrum. Furthermore, transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, transceiver 225 may support at least one network interface 240 and / or application interface 245. The application interface(s) 245 may support one or more APIs. The network interface(s) 240 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 240 may be supported, as will be understood by those skilled in the art.

[0046] Processor 205 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 205 may be a microcontroller, microprocessor, central processing unit (CPU), graphics processing unit (GPU), auxiliary processing unit, field-programmable gate array (FPGA), or similar programmable controller. Processor 205 may execute instructions stored in memory 210 to perform the methods and routines described herein. Processor 205 is communicatively coupled to memory 210, input device 215, output device 220, and transceiver 225.

[0047] Processor 205 can control user equipment device 200 to implement the user equipment device behavior described herein. Processor 205 may include an application processor (also referred to as a main processor) that manages application domain and operating system (OS) functions, and a baseband processor (also referred to as a baseband radio processor) that manages radio functions.

[0048] Memory 210 may be a computer-readable storage medium. Memory 210 may include volatile computer storage media. For example, memory 210 may include RAM, including dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), and / or static RAM (SRAM). Memory 210 may include non-volatile computer storage media. For example, memory 210 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. Memory 210 may include both volatile and non-volatile computer storage media.

[0049] Memory 210 may store data related to the implementation of business category fields as described herein. Memory 210 may also store program code and related data, such as the operating system or other controller algorithms operating on device 200.

[0050] Input device 215 may include any known computer input device, including touchpad, buttons, keyboard, stylus, microphone, etc. Input device 215 may be integrated with output device 220, for example, as a touchscreen or similar touch-sensitive display. Input device 215 may include a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or via handwriting on the touchscreen. Input device 215 may include two or more different devices, such as a keyboard and a touchpad.

[0051] Output device 220 may be designed to output visual, auditory, and / or tactile signals. Output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 220 may include, but is not limited to, liquid crystal displays (LCDs), light-emitting diode (LED) displays, organic LED (OLED) displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 220 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., that is separate from but communicatively coupled to the rest of the user equipment device 200. Furthermore, output device 220 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0052] Output device 220 may include one or more speakers for generating sound. For example, output device 220 may generate an audible alarm or notification (e.g., a beep or buzzer). Output device 220 may include one or more haptic devices for generating vibration, motion, or other haptic feedback. All or part of output device 220 may be integrated with input device 215. For example, input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. Output device 220 may be located near input device 215.

[0053] Transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 225 operates under the control of processor 205 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, processor 205 may selectively activate transceiver 225 (or a portion thereof) at specific times to send and receive messages.

[0054] Transceiver 225 includes at least one transmitter 230 and at least one receiver 235. One or more transmitters 230 can be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, one or more receivers 235 can be used to receive downlink communication signals from a base unit. Although only one transmitter 230 and one receiver 235 are shown, user equipment device 200 can have any suitable number of transmitters 230 and receivers 235. Furthermore, the transmitter(s)230 and receiver(s)235 can be of any suitable type. Transceiver 225 can include a first transmitter / receiver pair for communicating with a mobile communication network via licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via unlicensed radio spectrum.

[0055] A first transmitter / receiver pair that can be used to communicate with a mobile communication network via licensed radio spectrum, and a second transmitter / receiver pair that can be used to communicate with a mobile communication network via unlicensed radio spectrum, can be combined into a single transceiver unit, such as a single chip performing functions for use with both licensed and unlicensed radio spectrum. The first transmitter / receiver pair and the second transmitter / receiver pair can share one or more hardware components. For example, some transceivers 225, transmitters 230, and receivers 235 can be implemented as physically independent components that access shared hardware and / or software resources, such as network interface 240.

[0056] One or more transmitters 230 and / or one or more receivers 235 can be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit (ASIC), or other types of hardware components. One or more transmitters 230 and / or one or more receivers 235 can be implemented and / or integrated into a multi-chip module. Other components, such as a network interface 240 or other hardware components / circuits, can be integrated with any number of transmitters 230 and / or receivers 235 into a single chip. Transmitters 230 and receivers 235 can be logically configured as transceivers 225 using one or more common control signals, or configured as modular transmitters 230 and receivers 235 implemented in the same hardware chip or multi-chip module.

[0057] Figure 3 Further details are depicted of network node 300, which can be used to implement the methods described herein. Network node 300 can be an implementation of an entity in a wireless communication network, such as one or more wireless communication networks described herein. Network node 300 may include network element 104, RAN 430, or 5G core 1120 as described herein. Network node 300 may include data collection application functions as described herein. Network node 300 includes processor 305, memory 310, input device 315, output device 320, and transceiver 325.

[0058] Input device 315 and output device 320 can be combined into a single device, such as a touchscreen. In some implementations, network node 300 does not include any input device 315 and / or output device 320. Network node 300 may include one or more of the following: processor 305, memory 310, and transceiver, and may not include input device 315 and / or output device 320.

[0059] As shown in the figure, transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, transceiver 325 communicates with one or more remote units 200. Additionally, transceiver 325 may support at least one network interface 340 and / or application interface 345. The application interfaces 345 may support one or more APIs. The network interfaces 340 may support 3GPP reference points such as Uu, N1, N2, and N3. Other network interfaces 340 may be supported, as will be understood by those skilled in the art.

[0060] Processor 305 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 305 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. Processor 305 may execute instructions stored in memory 310 to perform the methods and routines described herein. Processor 305 is communicatively coupled to memory 310, input device 315, output device 320, and transceiver 325.

[0061] Memory 310 may be a computer-readable storage medium. Memory 310 may include volatile computer storage media. For example, memory 310 may include RAM, including dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), and / or static RAM (SRAM). Memory 310 may include non-volatile computer storage media. For example, memory 310 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. Memory 310 may include both volatile and non-volatile computer storage media.

[0062] Memory 310 may store data related to establishing multipath unicast links and / or mobility operations. For example, as described herein, memory 310 may store parameters, configurations, resource allocations, policies, etc. Memory 310 may also store program code and related data, such as operating systems or other controller algorithms operating on network node 300.

[0063] Input device 315 may include any known computer input device, including touchpads, buttons, keyboards, styluses, microphones, etc. Input device 315 may be integrated with output device 320, for example, as a touchscreen or similar touch-sensitive display. Input device 315 may include a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or via handwriting on the touchscreen. Input device 315 may include two or more different devices, such as a keyboard and a touchpad.

[0064] Output device 320 may be designed to output visual, auditory, and / or tactile signals. Output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 320 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 320 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., separate from but communicatively coupled to the rest of network node 300. Furthermore, output device 320 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0065] Output device 320 may include one or more speakers for generating sound. For example, output device 320 may generate an audible alarm or notification (e.g., a beep or buzzer). Output device 320 may include one or more haptic devices for generating vibration, motion, or other haptic feedback. All or part of output device 320 may be integrated with input device 315. For example, input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. Output device 320 may be located near input device 315.

[0066] Transceiver 325 includes at least one transmitter 330 and at least one receiver 335. One or more transmitters 330 can be used to communicate with a UE, as described herein. Similarly, one or more receivers 335 can be used to communicate with network functions in a PLMN and / or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are shown, network node 300 can have any suitable number of transmitters 330 and receivers 335. Furthermore, the transmitter(s)330(s) and receiver(s)335(s) can be of any suitable type of transmitter and receiver.

[0067] In many interactive and immersive applications with challenging requirements for latency, speed, and reliability, the application experience is delivered via a shared connection, where the endpoint Personal IoT Network Element (PINE) device connects to a gateway device, which in turn connects to a 3GPP access network (e.g., 4G, 5G, etc.) for internet connectivity. Examples of this application experience delivery include AR / VR experiences, where the PINE is a head-mounted display (HMD) in the form of AR / VR glasses, and the gateway is a mobile phone, or alternatively, a 3GPP User Equipment (UE). Therefore, the E2E connection between the client and the application server relies on at least three heterogeneous network segments: the shared link, the 3GPP connectivity, and the data network (DN) link. The shared link and the DN link are not within the 3GPP scope. The shared connection between the PINE and the gateway typically relies on Wi-Fi, Bluetooth, or unlicensed spectrum radio access technologies. This connection impacts E2E QoS, and in fact, both the shared link and the DN link reduce the effectiveness of QoS rules and policies employed within the 3GPP network.

[0068] Therefore, it is crucial that 3GPP networks monitor and extract link metrics regarding the performance of out-of-range segments (e.g., shared links, DN links) across heterogeneous E2E network paths. 3GPP networks can also perform analysis of these link metrics and derive statistical characteristics of expected performance. Furthermore, such 3GPP networks can adapt to 3GPP QoS rules and policies, compensate for the degraded effects of out-of-range segments (e.g., additional latency), and seamlessly meet the enhanced user experience requirements of E2E applications.

[0069] This article presents example solutions for latency in AR / VR applications (or collectively XR applications). However, the mechanisms and processes described herein extend beyond XR applications and are equally applicable to other applications served via shared links.

[0070] The core network processes packets, which can be Protocol Data Units (PDUs) and can be grouped into PDU sets, such as... Figure 4 As shown, Figure 4 An overview of the core network (CN) XRM architecture for processing data packets is shown. Figure 4System 400 is illustrated, which includes Extended Reality Media Application Function (XRM AF) 410, Policy and Control Function (PCF) 415, Session Management Function (SMF) 420, Access and Mobility Function (AMF) 425, Radio Access Network (RAN) 430, User Equipment (UE) 435, User Plane Function (UPF) 440, and Application Service Provider 410. Application Service Provider 410 includes Application Function (AF) 412 and Application Server 414. UE 435 may include Remote Unit 102 or User Equipment Unit 200 as described herein. RAN 430 may include Base Unit 104 and Network Node 300 as described herein. The operation of System 400 will now be described in an example of downlink service; similar procedures can be used for uplink service.

[0071] At 480, AF 412 determines the PDU requirement.

[0072] At 481, application function 412 provides PCF 415 with packet QoS requirements and information for identifying the application (i.e., a 5-tuple or application ID). QoS requirements can be expressed as delay budget, packet delay budget (PDF), or alternatively PDU set delay budget (PSDB), error rate, packet error rate (PER), or alternatively PDU set error rate (PSER).

[0073] At 482, PCF 415 determines the QoS rules for the application and the specific QoS requirements for the PDU. The QoS rules can use 5G QoS identifiers (5QIs) for the application services. PCF 415 makes this determination by identifying the 5QI of the application PDU services. PCF 415 sends the QoS rules as a 5-tuple PDU QoS requirement to SMF 420. PCF 415 can include Policy and Charging Control (PCC) rules for each importance of the PDU in the communication to SMF 420. PCC rules can be derived from information received from AF 412 or based on operator configuration.

[0074] At position 483, SMF 420 establishes QoS flows based on the QoS rules of PCF 415 and configures the UPF to route applied packets to the QoS flows. SMF 420 also provides a QoS profile containing PDU QoS requirements to RAN 430 via AMF 425. AMF 425 can provide a QoS profile containing PDU QoS requirements to RAN 430 within the N2 Session Management (SM) container. Furthermore, AMF 425 can provide QoS rules to UE 435 within the N1 SM container.

[0075] At 484, based on the N4 rule received from SMF 420, UPF 440 determines the application's PDU (i.e., 5-tuple) and routes it to the corresponding QoS flow.

[0076] At 485, during PDU session establishment / modification, RAN 430 receives the QFI and QoS profile of the QoS flow from SMF 420 via AMF 425, identifies packets belonging to the PDU session applied on the QoS flow, and processes packets on the RB according to the QoS requirements provided by SMF 420. RAN 430 checks the GTP-U header and ensures that the PDU is processed according to the QoS profile determined based on the SM container. This may include transmitting some packets in a radio bearer carrying QoS flow 1. This may also include transmitting other packets in different radio bearers carrying QoS flow 2.

[0077] The general steps described above regarding QoS flow processing, RB-to-QoS flow-to-application flow mapping, and PDU session processing apply to both UL and DL directions. That is, while the above example pertains to downlink (DL) traffic, reciprocal processing applies to uplink (UL) traffic, where the UPF 440 packet inspection role is assumed by the UE 435. The low-level signaling mechanisms associated with UL UE-RAN information transfer depend on the specifications and implementation of the RAN signaling procedures.

[0078] In this article, extended reality (XR) is used as a general term for different types of reality (virtual reality, augmented reality, and mixed reality are examples of this).

[0079] Virtual reality (VR) is a rendered version of a delivered visual and audio scene. In this context, the rendering is designed to mimic real-world visual and auditory stimuli as naturally as possible as an observer or user moves within an area defined by the application. Virtual reality typically, but does not necessarily, require the user to wear a head-mounted display (HMD) that completely replaces the user's field of view with simulated visual components, and headphones to provide accompanying audio. In VR, some form of head and motion tracking for the user is usually also required to allow the simulated visual and audio components to be updated to ensure that objects and sound sources remain consistent with the user's movement from their perspective. In some implementations, additional components for interacting with the virtual reality simulation may be provided, but are not strictly necessary.

[0080] Augmented reality (AR) refers to the presentation of additional information or artificially generated items, or content overlaid on a user's current environment. Such additional information or content is typically visual and / or auditory, and the user's observation of their current environment can be direct without intermediate sensing, processing, and rendering, or indirect, where the user's perception of their environment is relayed via sensors and can be augmented or processed.

[0081] Mixed Reality (MR) is an advanced form of AR in which some virtual elements are inserted into the physical scene to give the illusion that these elements are part of the real scene.

[0082] XR refers to all combinations of real and virtual environments and human-computer interactions generated by computer technology and wearable devices. It includes representative forms such as AR, MR, and VR, as well as interpolation areas in between. Levels of virtuality range from partial sensory input to fully immersive VR. In some circles, a key aspect of XR is considered an extension of the human experience, particularly concerning presence (represented by VR) and cognitive acquisition (represented by AR).

[0083] In 3GPP Release 17, the 3GPP SA4 working group analyzed the media transport protocols and XR service models in Technical Report TR 26.926 (v1.1.0), entitled "Service Models and Quality Assessment Methodologies for Media and XR Services in 5G Systems," and determined the QoS requirements at the application level for satisfactory experience in terms of latency budget, data rate, and error rate. These resulted in four additional 5G QoS Identifiers (5QIs) for the XR QoS stream band of 5G systems (5GS). These 5QIs are defined in Table 5.7.4-1 of 3GPP TS 23.501 (v17.5.0) as latency-critical GBR 5QIs with values ​​ranging from 87 to 90. The latter applies to the XR video stream and control metadata required to provide immersive and interactive XR experiences.

[0084] XR video services primarily consist of multiple high-resolution (e.g., typically at least 1080p dual-eye buffers), frame-per-second (e.g., 60+ fps), and high-bandwidth (e.g., typically at least 20-30 Mbps) DL / UL video streams. These streams need to be transmitted across the network with minimal latency (typically up to 15-20 ms) to maintain reduced end-to-end application round-trip latency. Given the reliance of XR applications on cloud / edge processing (e.g., content downloading, viewport generation and configuration, viewport updates, viewport rendering, media encoding / transcoding, etc.), this latter requirement is crucial.

[0085] Shared and heterogeneous links can be used for media applications. In Release 17, 3GPP studied support for 5G and XR glasses based on a common client architecture that relies on three main components: XR runtime, scene manager, and media access function (MAF). Among these three main components, the MAF is the most relevant to communications.

[0086] 3GPP Technical Report TR 26.998 (v18.0.0, December 2022) describes support for 5G glasses-type AR / MR devices and defines Media Access Function (MAF) as supporting AR UE access and streaming. For this purpose, MAF includes:

[0087] • Codecs: Used to compress and decompress media. In some cases, each media type requires not only a single codec instance, but also multiple codec instances.

[0088] • Content delivery protocol: A container format and protocol used to deliver media content between the UE and the network according to application requirements. This includes timing, synchronization, reliability, protocol level reporting (e.g., RTP reporting), and other features.

[0089] • 5G connectivity: Modem and 5G system functionality that allows the UE to connect to the 5G network and access the features and services provided by the 5G system.

[0090] • Media Session Processor: A general-purpose function on the device used to establish 5G system capabilities and support 5GS integration. This can establish edge functions, provide QoS support, support reporting functions, etc.

[0091] • Content protection and decryption: This feature handles content protection to prevent playback on unauthorized devices.

[0092] Some example implementations of MAF are:

[0093] • 5GMSd client, which includes a media session processor and media player as defined in TS26.501 and TS26.512.

[0094] • The 5GMSu client includes a media session processor and a media streaming player as defined in TS26.501 and TS26.512.

[0095] • Real-time communication clients, which include uplink or downlink or both, to support more latency-critical communication services, such as those used in XR applications.

[0096] In version 18, 3GPP is further investigating sharing aspects for XR glasses-type devices, with two different sharing methods established:

[0097] • Shared standalone glasses: In this case, the glasses run an XR application that uses the glasses' capabilities to create services. The glasses are shared with 5G devices or similar mobile access technologies (e.g., mobile phones) and potentially use the phone's features (e.g., media session processors) to support the application.

[0098] • Shared Display Glasses: In this case, the glasses are shared with a 5G device or a similar mobile access technology (e.g., a mobile phone), which includes applications and XR functionality, i.e., at least a MAF and / or a lightweight scene manager instance. Applications running on the 5G device utilize the capabilities of the 5G device to run the XR experience. The glasses are connected to the 5G device and embedded with at least a lightweight XR runtime, which is exposed to the 5G device via an XR runtime-specific API on an XR-shared link or via a wireless link that exposes a media buffer.

[0099] Figure 5 An implementation is described, which depicts a first sharing method as standalone glasses. AR glasses device 510 is shared with 5G device 530. AR glasses device 510 includes XR runtime 512, XR runtime API 514, AR / MR application 516, wireless connectivity module 518, and media access function 552. A pair of speakers 521, an eye display buffer 522, sensors 523, and at least one camera 524 provide input to XR runtime 512, including visual synthesis, haptic feedback, and audio synthesis. XR runtime API 514 provides an interface between XR runtime 512 and each of uplink media management module 520 and rendering engine 526. Rendering engine 526 includes a visual renderer and an audio renderer and interfaces with scene manager 527. Media access function 552 includes metadata codec, video codec, and audio codec, as well as MAF API 554. AR / MR Applications 516 with each of the interfaces in XR Runtime API 514, Scene Manager 527, and MAF API 554.

[0100] A shared connection is provided between the AR glasses device 510 and the 5G device 530 via corresponding wireless connectivity modules 518 and 538. The MAF 552 transmits compressed media to and from the shared connection via the wireless connectivity module 518. The 5G device 530 may include a smartphone and includes a 5G system module 535. Telephony-based processing functions are executed by the processor 531. These telephony-based processing functions include an API 533 capable of transmitting configuration information to the AR / MR application 516 via the shared connection.

[0101] Figure 6An implementation of AR glasses is illustrated, in which an XR shared link exposes XR runtime as an XR runtime API to a 5G device. AR glasses device 610 is shared with a 5G device 630. AR glasses device 610 includes an XR runtime core function 612. A pair of speakers 621, an eye display buffer 622, sensors 623, and at least one camera 624 provide input to the XR runtime core function 612, including visual synthesis, haptic feedback, and audio synthesis. An XR link-enabled glasses 611 serves as an interface between the XR runtime core function 612 and a wireless connectivity module 618 of the AR glasses device 610.

[0102] A shared connection is provided between the AR glasses device 610 and the 5G device 630 via corresponding wireless connectivity modules 618 and 638. The 5G device 630 includes an XR link function device 613 that provides an interface between the wireless connectivity module 638 and the XR runtime API 614. The 5G device 630 also includes an AR / MR application 616 and a media access function 652. The XR runtime API 614 provides an interface between the XR link function device 613 and each of the uplink media management module 620 and the rendering engine 626. The rendering engine 626 includes a visual renderer and an audio renderer, and interfaces with a scene manager 627. The media access function 652 includes a metadata codec, a video codec, and an audio codec, as well as a MAF API 654. The AR / MR application 616 interfaces with each of the XR runtime API 614, the scene manager 627, and the MAF API 654. The 5G device 630 may include a smartphone and includes a 5G system module 635. MAF 652 transmits compressed media to and from 5G system module 635.

[0103] Figure 7 An implementation of AR glasses is illustrated, wherein XR runtime exposure is supported via a virtualized edge network XR runtime instance, acting as a media buffer source and sink via a shared link. AR glasses device 710 is shared with a 5G device 730; the 5G device 730 is connected to an edge network 750 via a 5G connection. AR glasses device 710 includes XR runtime core functionality 712. A pair of speakers 721, an eye display buffer 722, sensors 723, and at least one camera 724 provide input to the XR runtime core functionality 712. An XR runtime API 714 provides an interface to basic AR / MR applications 716.

[0104] A shared connection is provided between the AR glasses device 710 and the 5G device 730 via corresponding wireless connectivity modules 718 and 738. The XR runtime core function 712 of the AR glasses device 710 exchanges data with the 5G device 730 via the shared connection. The 5G device 730 may include a smartphone and includes a 5G system module 735. The 5G device 730 includes a media access function 732. A MAF 752 transmits compressed media to and from the 5G system module 735.

[0105] The edge network 750 includes a media access function 754, an XR runtime 756, an XR scene manager 758, and an AR / MR application 760. The AR / MR application 760 interfaces with the media access function 752 via the MAF API 754 and with the XR scene manager 758 via the XR scene API 759. The XR runtime API 757 provides the interface between the XR runtime 756 and the XR scene manager 758.

[0106] Figure 5 , Figure 6 and Figure 7 All three shared architectures can be supported by edge-split rendering to reduce complexity, processing requirements, power consumption, and heat dissipation on XR glasses. To this end, some key issues identified in the 3GPP version 18 shared study relate to the monitoring and reporting of shared link and DN link latency, as well as the management of E2E QoS latency budgets.

[0107] Therefore, the latency monitoring and reporting solution proposed in this paper is relevant because in E2E connections involving shared links (e.g., Wi-Fi or Bluetooth links), 5G networks, and the Internet, latency is often not guaranteed for Wi-Fi and Internet segments. XR applications require low E2E latency to provide end-users with a good Quality of Experience (QoE). Such QoE can make users feel more immersive and the experience more interactive. To achieve the low E2E latency required for XR applications, one approach is to make the latency in 5G networks very conservative, resulting in end-to-end latency below the target value. However, this comes at a cost, as only limited bandwidth is available in wireless communication systems, and specifying unnecessary low latency in 5G networks requires excessive radio resource allocation. This excessive allocation of radio resources can support more robust modulation and coding schemes (MCS), but will require many other traffic flows to be deprived of bandwidth resources.

[0108] Therefore, the proposed solution is to dynamically adjust latency in the 5G network based on the total latency generated elsewhere along the E2E path. This requires a metric for non-5G latency in the total E2E connection between the shared headset and the application server. Latency on Wi-Fi links can vary over time, depending on interference generated by other nearby Wi-Fi networks operating in the same frequency band. Similarly, latency between the UPF and the application server (AS) depends on the selected UPF, the location of the selected edge / AS, and the level of network congestion. Therefore, this measurement can be used to estimate these time-varying latency on non-5G segments.

[0109] Therefore, an efficient implementation is provided for determining the delay of the non-5G segment across the E2E path between the eyepiece endpoint and the AS, or alternatively, for segmenting the rendered edge AS (EAS).

[0110] Figure 8 The E2E path and subsequent path delays are shown. In this example, the E2E path includes AR glasses 805, phone 835, gNB 830, UPF 840, and edge application server 814. Figure 8 The delay symbol shown is defined as follows.

[0111] ·D e2e : Indicates the E2E delay in one direction (i.e., UL or DL).

[0112] ·D 5G This represents the 5GS delay from PSA UPF to UE, which can be measured through the core network QoS monitoring procedure described in TS23.501 and the RAN Layer 2 measurement procedure described in TS 38.314. This can be measured either based on the average performance of DRBs and QoS flows, or for each UE, each QoS flow, and each DRB. For the latter, the timestamp required for the PSA UPF to NG-RAN measurement is carried in the GTP-U header, and each QoS flow of the QoS monitoring procedure for each UE is applied. The delay between NG-RAN and UE is averaged at the PDCP layer for each UE conforming to the RAN Layer 2 procedure for each DRB.

[0113] ·D n,1 : Indicates the latency of a shared link (e.g., Wi-Fi, Bluetooth).

[0114] ·D n,2 : Indicates the delay of the DN link (e.g., the connection between PSA UPF and AS, or alternatively, EAS).

[0115] ·D n: Represents the total non-5G / non-3GPP E2E latency accumulated on the shared link and DN link segments, such as: D n =D n,1 +D n,2 .

[0116] Therefore, it is useful to determine D. n In order to enable D to be processed through QoS rules 5GS To achieve fine-grained control, the application's latency budget and requirements (i.e., D) are minimized. e2e,max ) is satisfied, that is, D e2e =D 5GS +D n ≤D e2e,max .

[0117] Therefore, delay measurements can be performed segment by segment, where the aforementioned delays are determined individually, and since what is of interest is D... n,1 and D n,2 Determining the delay.

[0118] For latency measurements, the measured latency can represent the delay experienced by data packets during transmission between the AR glasses 805 and the edge application server 814. Latency measurements based on out-of-band latency measurement messages (such as ping messages (ICMP echo and echo reply according to RFC 792)) can be easily collected, but may not accurately reflect the latency experienced by the data packets. The latter is a consequence of two facts: i) the protocol number used by the latency measurement ICMP message (e.g., 1 for ping) is different from the protocol number of the XR service data packets (e.g., 17 if the data packets are sent using RTP / UDP), which results in different 5-tuples (src addr, dst addr, src port, dst port, protocol id), thus producing different QoS treatment in the 5GS communication link; ii) the packet size for ICMP latency measurements is typically much smaller than the data packet size (tens of bytes), resulting in different transmission delays.

[0119] Alternative methods for latency measurement include in-band latency measurement performed on top of RTP / UDP stacks, WebRTC stacks, RTP / QUIC stacks, WebRTC / QUIC stacks, or similar real-time communication protocols. In some implementations, this utilizes RTP header extensions, such as the WebRTC / RTP abs-send-time header extension (http: / / www.webrtc.org / experiments / rtp-hdrext / abs-send-time), and time synchronization relative to an NTP server to measure the latency at the receiver (or alternatively) along the network path at network nodes, derived from the absolute transmission time of RTP packets (or alternatively, RTP packets including ADUs). In another implementation, according to RFC 5761, overlays on top of RTCP sender / receiver reports can be used in conjunction with RTP / RTCP multiplexing for unicast sessions. In this context, the RTP timestamp, together with the RTCP sender / report timestamp and the receive time, can be used to calculate the average round-trip time (RTT) and provide an estimate for the latter, the UL direction, or alternatively the DL direction.

[0120] In the case of in-band delay measurement, the measurement framework requires a combination of E2E measurement methods and 5GS measurement procedures to determine D. e2e D 5GS And finally determine the measurement of interest, namely D. n This fact is due to the deployment strategy on top of RTP services originating from the application source.

[0121] 3GPP also defines an architecture in TS23.288v17.2.0 to support the provision of network analytics. In this architecture, the NWDAF provides analytics output to one or more analytics consumer NFs based on data collected from one or more data producer NFs. The analytics consumer NF can be one or more of the following: AF, OAM, and 5G core NFs (e.g., SMF, AMF, PCF).

[0122] Figure 9An example wireless communication system 900 is illustrated. System 900 includes a UE 904, an NWDAF analysis logic function (ANLF) 910, an NWDAF model training logic function (MTLF) 912, multiple data producer network functions (application functions (AF) in this example) 920, a 5G network function 922, and an operation, management, and maintenance (OAM) 924. Wireless communication system 900 also includes multiple analysis consumer network functions, which in this example include application function 930, 5G network function 932, and OAM 934. In the current 3GPP architecture, NWDAFs 910 and 912 (defined in 3GPP technical specification 23.288v17.2.0) provide analysis outputs to one or more analysis consumers NFs 930, 932, and 934 based on data collected from one or more data producer NFs 920, 922, and 924. The analysis outputs can be derived by NWDAFs 910 and 912 using analysis sharing and / or joint learning. UE 904 may be represented as remote unit 102, user equipment device 200, or alternatively, as shared UE 1110 as described herein. NWDAF 1 910 and NWDAF 2 912 may be represented as network unit 104 and network node 300 as described herein.

[0123] The list of potential analytical consumer NFs for each analytical output provided by NWDAF is shown in Table 1 below.

[0124]

[0125]

[0126] Table 1: Example Analysis of Consumer NF

[0127] To support XR services and applications, the following analysis is relevant to this disclosure. This analysis is beneficial for mobile XR users or XR service providers who need to deploy XR services in a target area and time (e.g., for an event) and require statistics / predictions on QoS / network performance and availability.

[0128] • QoS Sustainability Analysis: Provides statistical information on QoS changes in a region during the target analysis period in the past, or information on the likelihood of QoS changes in a region during the target analysis period in the future.

[0129] • Network performance analysis: Provides statistics or predictions on gNB status information, gNB resource usage, communication performance, and mobility performance in the area of ​​interest.

[0130] • User data congestion analysis: User data congestion analysis can involve congestion experienced when transmitting user data on the control plane, user plane, or both.

[0131] • DN Performance Analysis: Statistical information or predictions of DN performance metrics for specific edge computing applications for UEs based on UE groups, DN application identifiers, or EAS on a specific service PSA UPF.

[0132] In version 17, the framework for UE data collection and the event exposure (EVEX) reporting framework have been completed. This provides the architecture and protocols for enabling the collection of UE and AS data and exposing associated events to NF consumers through a common architecture and processes described by NWDAF.

[0133] To this end, an advanced process for NWDAF to collect data from (multiple) UE applications via an intermediate AF acting as a data provider is utilized. This is achieved by a data collection AF (DCAF) that registers with the NRF and connects to the NWDAF as an event provider. The DCAF relies on three possible data collection clients:

[0134] • Direct data collection client, which operates directly on the UE endpoint and collects data related to application operations and logic that communicate directly with the DCAF instance;

[0135] • Indirect data collection client, which operates within the ASP backend of data collected by the UE application instance in communication with the client; the indirect data collection client collects UE application data and further relays it to the DCAF instance; and / or

[0136] • AS / EAS, which communicates with DCAF as part of the ASP infrastructure or via the NEF interface in a distributed / independent domain deployment.

[0137] Therefore, the DCAF and subsequent data collection client can be provided by the application service provider via a configuration for the AF, designed to perform data collection directly from a UE or group of UEs serving the application, or alternatively, from an AS / EAS serving the application content to that UE or group of UEs. This configuration also includes a data access profile provided by the application provider. The data access profile contains information about the data parameters to be collected (e.g., event ID), filtering metadata to be applied to the collected data (e.g., location filter, time sampling limit, UE / application identifier filter, etc.), and reporting procedures. The data access profile can also define the processing to be performed by the DCAF on the collected data to generate events and expose them to other NFs or AFs.

[0138] Therefore, the DCAF, acting as an NF data producer or event producer, connects to the NWDAF instance, which acts as an event consumer. Through an architecture based on NWDAF services, more event consumers can be attached. For example, other event consumers could be other NFs, such as PCF, SMF, UPF, etc., or other AFs, such as application provider AFs.

[0139] Figure 10 A general DCAF architecture is illustrated in a simplified format. For brevity, NRF registration and provisioning AF connections for the DCAF are omitted. The wireless communication device 1035 includes a Direct Data Collection Client (DDCC) 1036 that reports to a Data Collection Application Function (DCAF) 1022. The DCAF 1022 also receives UE report data from an application server 1024 and exposes events to both the NWDAF 1032 in the ASP 1010 and the Event Consumer Application Function 1016. The NWDAF 1032 exposes network data analytics to any network function 1042 that wishes to consume data analytics. Therefore, the DCAF 1022 collects data through a configured data collection session with the Direct Data Collection Client 1036 and the AS 1024 (which may be an edge AS) (i.e., retrieving data via a RESTful API over an HTTPS-authenticated connection using a data access profile). The collected data is processed at the DCAF 1022 to generate and expose events, which are further consumed by the NWDAF 1032 for analysis. The NWDAF 1032 then performs analysis on the collected events and outputs the results to other NF / AF consumers 1042.

[0140] The data access profile is defined in TS26.531v17.0.0, "Data Collection and Reporting; General Description and Architecture". Various restrictions are available along the time, user, and location dimensions.

[0141] • Time-based constraints: Determines the granularity of accessing UE data along the time axis. The finest granularity allows access to events that occur in a timely manner (without restriction). Given an aggregation window, the coarsest level of access aggregates all event data along the time axis to produce a single aggregated value.

[0142] • User-based restrictions: Allows event consumers to restrict access to UE-related events based on groups. The finest granularity allows event consumers to access events related to a single user or UE. Coarse-grained access exposes aggregated event data based on user groups defined by the application (e.g., UEs running a specific application version). The coarsest granularity exposes data aggregated for all users.

[0143] • Location-based restrictions: Allows the provisioning agent (AF) to restrict access to UE data-related events based on the geographic location of the data collection client during the event. The finest granularity allows event consumers to access events individually, regardless of their location. Coarse-grained access exposes aggregated collected event data based on geographic region. The coarsest level of access aggregates all event data along the location, producing a single aggregated value for all locations.

[0144] The baseline set of aggregation filters for DCAF is currently defined in 3GPP TS26.532v17.1.0 "Data Collection and Reporting. Protocols and Formats", specifically in Table 4.5.2-1. Therefore, the baseline DCAF aggregation filters based on the reporting period are as follows:

[0145] •None: No aggregation is applied; all reported data records are exposed as a single event.

[0146] • Count: The number of reported data records exposed to event consumers.

[0147] •Mean: The average value of the reported data records is exposed to event consumers.

[0148] • Maximum: The largest observation in the reported data record that was exposed to the event consumer.

[0149] •Minimum: The smallest observation in the reported data record that is exposed to the event consumer.

[0150] • Sum: The sum of values ​​in the reported data records is exposed to the event consumer.

[0151] This document presents a solution involving data collection, reporting, analysis, and the use of the output for 5GS, QoS rule adaptation regarding latency, or alternatively, latency budget control for latency-sensitive immersive, interactive, and / or critical applications such as shared link UEs. The solution includes data collection to support the determination and reporting of non-3GPP-based link segments based on UE and AS latency / delay metrics. It should be noted that while the following examples are presented in the context of XR applications, those skilled in the art can broadly apply the general methods and apparatus to any latency-sensitive application. For example, the arrangements described herein can be applied to the remote operation control of machines or other devices.

[0152] The shared UE serving XR applications can be formed by a combination of XR glasses shared with a 5G device for internet connectivity, or alternatively, for DN connectivity to the AS / EAS of the ASP. In this embodiment, the 5G device (regardless of the shared architecture, i.e., sharing a standalone XR glasses, or alternatively, sharing a display XR glasses) and the 5G device (e.g., a mobile phone, mobile tablet, XR access point, or gateway) provide the basic functionality and implementation of a Media Session Processor (MSH). The MSH operates as a general function on the 5G device, establishing 5GS capabilities and supporting 5GS integration. Such functionality may include at least one of the following: QoS support, metric collection and reporting, and the establishment of edge functions for XR applications.

[0153] The shared UE's MSH can be co-located with the MAF, allowing both to reside on a 5G device (e.g., a mobile UE). An example in this sense is the implementation of a shared XR display UE, where the MAF and embedded MSH reside at least partially on the 5G device, as the 5G device performs media processing, such as encoding / decoding, media source synchronization, media content distribution, spatial scene description, and associated metadata processing. Therefore, in this example, the 5G device's processing power is utilized to access the original media format via the MAF, handle scene management, and access the XR runtime API for rendering on the shared XR glasses, which is an implementation of the shared display XR category. Furthermore, by split rendering on the EAS or an equivalent AS, the 5G device can receive additional support in media processing, where spatial processing and pre-rendering are performed based on the available pose information of the scene, such as... Figure 7 As shown.

[0154] The shared UE's MSH (Mean Self-Host) may reside at least partially on the 5G device. In this arrangement, the lightweight MSH on the 5G device provides at least the basic functionality of exposing 5GS connectivity capabilities and integrating 5GS elements that partially support at least one of QoS support, metric collection and reporting, and edge function setup. The lightweight MSH on the 5G device may have a corresponding and associated MSH deployed and hosted on the shared XR glasses as part of the MAF (Multi-Activity Function), wherein the two MSH instances communicate with each other via a shared link for at least one of the purposes of QoS support, metric collection and reporting, and edge function setup. Figure 5The diagram illustrates an example where shared standalone XR glasses are used to access and process media streams and associated streams based on the glasses' MAF (Multi-Functional Context), and where 5G devices provide 5GS connectivity and basic session control functions through a lightweight MSH instance. The latter can interact in the implementation via API with both: the XR application, which can perform configuration regarding QoS support, metric data collection and reporting, and edge application support; and the peer MSH on the XR glasses for the integration of 5GS capabilities.

[0155] Furthermore, 5G devices can simply act as IP layer relays to 5GS for use with shared XR glasses. Therefore, the shared XR glasses are independent and aware of 5GS, as their implementation provides full MAF functionality and MSH. On the other hand, no MSH instance is running on the 5G device, and the shared XR glasses operate independently to establish 5G system capabilities and support 5GS integration. Thus, the MAF in the shared XR glasses independently manages the establishment of edge functions, providing QoS support, data collection, and reporting capabilities available based on 5GS connectivity provided via the IP relay 5G device.

[0156] The shared UE can measure D based on a segmented measurement process. n,1 The ICMP echo acknowledgment or ICMP timestamp procedure according to RFC 792 is used to determine the out-of-band delay to the shared link at Layer 3. In one implementation, the MSH on the 5G device side is responsible for triggering the measurement process and recording the D. n,1 The RTT measurement of the segment represents the latency estimate of twice the UL / DL latency due to the shared link between the XR glasses and the 5G device.

[0157] In one implementation, these measurements are performed when a PDU session is established or modified, during which QoS rules are updated.

[0158] In another implementation, these measurements are grouped and performed periodically, for example, at a frequency of 1 second for a maximum duration of, for example, 60 seconds, to limit the overhead of monitoring shared links. However, in yet another implementation, these measurements can be started and stopped based on application-configured control events (e.g., QoE degradation due to exceeding certain application buffer thresholds) or timers (e.g., a 60-second timer that performs measurements every second when determined by the application). Time and sample collection limits can be configured in various implementations to reduce monitoring overhead on XR glasses, 5G devices, and MSH instances.

[0159] In another implementation, multiple measurements are aggregated to determine the average delay duration. In this case, the aggregation filter can be applied via MSH based on the cumulative number of sample measurements or based on the aggregation window duration.

[0160] • In one example of aggregation by cumulative sample measurement count, average every 30 measurements and determine the average RTT latency, or alternatively, RTT / 2 latency.

[0161] In another example of aggregation for each window duration, samples accumulated over 60 seconds are aggregated together, and their average RTT latency or RTT / 2 latency is determined.

[0162] • In the third example, a combination of the two aggregation methods is performed to determine the average RTT latency or RTT / 2 latency based on the granularity of both the number of samples and / or the acquisition window.

[0163] The shared UE can measure D based on the E2E (i.e., between the UE and the AS / EAS) measurement process. e2e .

[0164] This process can be based on out-of-band measurements, at least in part, based on ICMP echo response or ICMP timestamp procedures according to RFC 792, which can determine the E2E RTT and thus determine D. e2e Delay parameter.

[0165] Alternatively, the process can be based on in-band over RTP or RTCP packets, where the timestamps required for E2E measurements are partly based on RTP timestamps, the RTP header extension abs-send-time, or RTCP timestamps and RTCP receive timestamps. These processes effectively allow D based on RTP / RTCP timestamps. e2e This is determined to be similar to an ICMP echo reply, or alternatively, an ICMP timestamp process, as detailed in RFC 792. However, this would benefit from in-band processing and less utilization of communication, processing, and bandwidth resources, providing more accurate D. e2e Estimate. Furthermore, the same QoS flow via CN is used for actual application services by being carried over RTP and / or RTCP. On the other hand, this is not the case in the case of ICMP latency E2E monitoring, because the protocol is being mapped to different QoS flows with different latency budgets and error rate parameters. In some implementations, the latter is actually a worse QoS flow than one application in the application, and therefore ICMP-based measurements represent the upper limit of E2E latency. Therefore, the choice between ICMP-based and RTP-based measurements is an implementation detail that requires a trade-off between portability or versatility and performance.

[0166] Similar measurements to those performed on the UE can be performed by the AS on the user plane path. This measurement can be performed by the AS relative to the PSA UPF based on an out-of-band ICMP echo response / ICMP timestamp procedure. This determines the RTT between the AS or EAS and the PSA UPF, which in turn can provide the D (delay) due to the DN link segment. n,2 Network segment estimation. Alternatively, the measurement can be carried by a UPF, in which case the collected metrics and data already exist within the 5GS CN.

[0167] The AS or EAS can perform E2E (i.e., between the UE and the AS / EAS) latency measurement and data collection. As mentioned above, similar latency measurements can be performed on the UE side, either based on ICMP-available procedures (e.g., echo replies and timestamps according to RFC 792) or on top of RTP / RTCP services.

[0168] To determine the total non-3GPP link segment delay, D n =D n,1 +D n,2 It can centralize the collected delay parameters, regardless of whether the measurement is performed in a segmented, E2E, in-band, or out-of-band manner.

[0169] This centralization can be implemented based on the data collection and reporting framework available in TS26.531v17.0.0 and 5GS, where both the UE and AS / EAS are enabled to perform data collection and report it to the DCAF. The DCAF (which has already registered a set of event IDs with the NRF based on Nnrf_NFManagement_NFRegister{EventIDs}) is provided by the ASP via the provisioning AF to create a data collection session related to the latency experienced on non-3GPP link segments. Therefore, the DCAF is established by the Ndcaf_DataReportingProvisioning_CreateSession and Ndcaf_DataReportingProvisioning_CreateConfiguration procedures to create a session and configuration for the event IDs registered with the DCAF, where a data access profile is given, instructing the DCAF which data parameters to collect and report, and how to process these parameters. Thus, this operation can be configured to generate the following event identifiers based on the latency experienced on at least one of three possible network segments:

[0170] • E2eDelayExperience: This is an event ID that characterizes the data events collected and processed on the experienced E2E (i.e., UE to AS / EAS) delay based on available E2E measurements (i.e., carried by the UE device and / or AS device).

[0171] • TetheredLinkDelayExperience: This is an event ID that determines the latency of data events collected and processed on the shared link (i.e., XR glasses or similar devices shared / indirectly connected to 5GS, 5G devices) based on segment-by-segment measurements performed by MSH on the 5G device.

[0172] • DnDelayExperience: This is an event ID that determines the delay of data events collected and processed on the DN link (i.e., AS / EAS to UPF link) based on segmented measurements performed by EAS / AS.

[0173] After the ASP provides a DCAF instance for the application (e.g., an XR application), the NWDAF subscribes to the event exposure, where the DCAF acts as the event producer and the NWDAF is the event consumer and producer of the analytical output of the aforementioned DCAF events.

[0174] Following this step, the data collection client can then create its session, for example via `Ndcaf_DataReporting_CreateSession`, for reporting, and perform data collection and reporting based on the DCAF configuration. The latter indicates to the client the data to be collected and reported, which is associated with the DCAF's EventID already configured for the current session. Given this information, the data collection client performs the reporting to the DCAF via the `Ndcaf_DataReporting_Report` procedure.

[0175] The direct data collection client based on the shared UE can be embedded and instantiated by an MSH residing in the 5G device, where the MSH can collect (depending on the measurement process configured by the DCAF) D n,1 (Shared XR glasses to UE link) or D e2e The data required for estimating the delay parameters.

[0176] EAS / AS can act as a data collection client, initiating data collection first by accessing the API of Ndcaf_DataReporting_*Session for data reporting session management, and then reporting the collected data via the API of the Ndcaf_DataReporting_Report procedure. Depending on the ASP deployment and trusted / untrusted domain configuration, interaction with the procedure is performed directly based on communication with DCAF, or alternatively, indirectly based on communication with NEF that exposes DCAF functionality. Therefore, in some embodiments, AS / EAS can collect and report data for D... n,2 (The link between PSA UPF and AS / EAS) or D e2e The data for estimating the delay parameters.

[0177] The DCAF data access profile configures an aggregation filter that further processes the collected data events and exposes the output events to other subscribed NF and AF event consumers through a 5GS service-based architecture.

[0178] Consumers can be represented by ASP's AF, which uses DCAF events to trigger actions on the application logic plane.

[0179] Alternatively, the consumer can be represented by another NF, such as NWDAF, PCF, UPF, etc., where events are used to generate analytics, configurations, or updates to CN and 5GS behaviors.

[0180] Figure 11 A method 1100 for shared application DCAF for data collection and reporting of non-3GPP link delays is shown. Figure 11 The system shown includes a shared UE 1110, a 5G core (5GC) 1120, and an application service provider (ASP) 1130. The shared UE 1110 includes a sharing device 1114, such as a smartphone, and a shared device 1112, such as a VR headset or AR glasses. The shared devices 1112 and 1114 are shared via a Wi-Fi link through corresponding Wi-Fi modules 1113 and 1115. The sharing device 1114 also includes a Media Session Processor (MSH) 1116, which includes a Direct Data Collection Client (DDCC) 1117.

[0181] 5GC 1120 includes a Data Collection AF (DCAF) 1122, a Network Data Analysis AF (NWDAF) 1124, and a User Plane Function (UPF) 1126. Application Service Provider 1130 includes an Application Function Provisioning 1132, an Application Function Consumer 1134, and an Edge Application Server (EAS) 1136.

[0182] Method 1100 begins at 1171, where ASP 1130 supplies DCAF 1122 for UE and AS data collection and reports for two events, namely TetheredLinkDelayExperience and DnDelayExperience. Given a 2-second data collection frequency, these events are exposed by DCAF 1122 within a 30-second aggregation window via an out-of-band ICMP echo playback process, at both user-level and coarse-grained location levels. The aggregation filter to be applied by DCAF on the aggregation window is the maximum aggregation event filter.

[0183] • Supply AF 1132 execution

[0184] Ndcaf_DataReportingProvisioning_CreateSession is used to create a session for exposing the desired event ID.

[0185] The supply of AF 1132 is also configured based on the data to be collected, collection, and reporting, via...

[0186] The Ndcaf_DataReportingProvisioning_CreateConfiguration is used to configure the desired data access profile, and also includes DCAF event aggregation to output the maximum latency event for each event ID every 30 seconds.

[0187] At 1172, the ASP event consumer (AF consumer 1134 in this case) subscribes to two event IDs (TetheredLinkDelayExperience and DnDelayExperience) via Naf_EventExposure_Subscribe.

[0188] At 1173, NWDAF 1124 subscribes to two event IDs (TetheredLinkDelayExperience and DnDelayExperience) via Naf_EventExposure_Subscribe.

[0189] At 1174a, the direct data collection client 1117, instantiated by the MSH 1116 at the shared UE 1110, obtains configuration from the DCAF 1122 to create a reporting session for TetheredLinkDelayExperience via Ndcaf_DataReporting_CreateSession, and obtains information about the data to be collected and instructions on how to perform the reporting.

[0190] At 1174b, ASP AS / EAS1136 also obtains configuration from DCAF 1122 to create a reporting session for TetheredLinkDelayExperience via Ndcaf_DataReporting_CreateSession, and obtains information about the data to be collected and instructions on how to execute the report.

[0191] At 1175a, the direct data collection client 1117 reports a data event to DCAF 1122, where the Ndcaf_DataReporting_Report{TetheredLinkDelayExperience} instruction includes D n,1 An event container with a delay parameter.

[0192] At 1175b, ASP 1130's AS / EAS 1136 also reports data events to DCAF 1122, where Ndcaf_DataReporting_Report{DnDelayExperience} indicates that D n,2 An event container with a delay parameter.

[0193] At 1176, DCAF 1122 processes ingress data report events according to the data processing rules in the configuration data access profile for each corresponding session, and further exposes the maximum latency D every 30 seconds to its event consumers. n,1 and D n,2 Based on Naf_EventExposure_Notify{TetheredLinkDelayExperience,DnDelayExperience}, events are exposed one at a time according to the event ID at the granularity of the configuration data access configuration file.

[0194] At point 1177, the consumer receives the event asynchronously and can begin further processing based on its needs.

[0195] It should be noted that the configuration for data collection and reporting from the shared UE or AS / EAS procedure to the DCAF may be subject to limitations imposed by the ASP-defined AF, namely, that experienced and recorded delay values ​​are only reported if they exceed a delay threshold determined by the ASP / application. In this arrangement, the threshold is determined by the ASP, where the application requirements for E2E delay budget or segmented delay budget are given.

[0196] In one example, an ASP can require an E2E latency budget of no more than 50ms, i.e., D e2e,max =50ms, and therefore, if D e2e >De2e,max , or if D e2e ≥D e2e,max Then any shared UE (i.e., MSH / direct data collection client) and AS / EAS data collection client should report the measured E2E delay D to DCAF. e2e .

[0197] In another example, the ASP can require the shared link between the UE and the shared link to last no more than 10ms, i.e., D. n,1,max =10ms, and therefore, if D n,1 ≥D n,1,max , or if D n,1 ≥D n,1,max Then the shared UE data collection client (i.e., the MAF or MSH direct data collection client instance) should report the measured shared link delay D to the DCAF. n,1 .

[0198] In the third example, the ASP can require the DN link (from PSA UPF / UPF to AS / EAS) to last no more than 10ms, i.e., D... n,2,max =10ms, and therefore, if D n,2 >D n,2,max , or if D n,2 ≥D n,2,max Then AS / EAS data collection should report the measured DN link delay D to DCAF. n,2 .

[0199] When conditional threshold-based or event-based reporting is performed by the data collection client and / or EAS / AS, DCAF may apply additional aggregation filtering to count the number of delayed reports occurring within a specified aggregation window duration, as specified and configured by the ASP's specification AF. Conversely, when interval-based reporting is performed by the data collection client and / or EAS / AS, DCAF may apply additional aggregation filtering to calculate an average, or alternatively, determine the maximum number of delayed reports within the specified aggregation window duration.

[0200] The rules governing data collection and reporting to the DCAF via the shared UE or AS / EAS procedure can be regulated by the ASP-defined AF, meaning that experienced and recorded latency values ​​are reported only when an event is detected by application logic or other implementation-specific means. In this arrangement, the data collection client collects latency measurements only when a configured event is triggered. In one example, the specified event could be the application logic's determination of network connectivity when initiating a media session via a shared link.

[0201] Therefore, a data collection application function is provided for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The data collection application function includes: a processor; and a memory coupled to the processor. The processor is configured such that the data collection application function: receives a configuration of a data access profile for data collection, the data relating to link latency in the shared connection; applies the data access profile to at least one data collection client; receives collected link latency measurements from the at least one data collection client; processes the link latency measurements in part based on the data access profile to generate one or more link latency performance events; and exposes one or more application-related link latency performance events experienced via the shared connection.

[0202] Therefore, data collection applications can expose link latency performance events, which facilitates the collection of measurements related to the performance of shared connections. Such measurements are needed to provide performance analysis for a proper understanding of end-to-end quality of service. One metric for end-to-end quality of service may include end-to-end latency.

[0203] Data collection application functionality may include a Data Collection Application Function (DCAF). The DCAF can expose one or more link latency performance events to a first network node. The first network node may include network analysis functionality. The first network node may be an NWDAF.

[0204] The configuration of the data access profile used for data collection may include: indications for providing analysis of link latency. The shared connection of the application may include shared link latency or DN link latency. Performance analysis of the shared link connection may include latency or DN link latency. Performance analysis of latency may include average latency or maximum latency.

[0205] Applications experienced via a shared connection between the first and second devices can be performed through application sessions. An application session can include communication between a wireless communication device and an application server. An application session can include multiple links communicating through various access technologies.

[0206] The first device can be a sharing device, and the second device can be the device being shared. The first device can be a wireless communication device. By way of example, the second device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0207] The first device can be the device being shared, and the second device can be the sharing device. The second device can be a wireless communication device. By way of example, the first device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0208] The first and second devices can be configured to provide connectivity access to the data network of at least one of the application server hosting the application and the edge application server.

[0209] At least one data collection client may include at least one of the following: a direct data collection client, as a logical component of at least one of the first device and the second device; a data collection client, as a logical component at an application server corresponding to the application; and / or a data collection client, located at a logical component at an edge application server corresponding to the application.

[0210] Link latency measurements can be obtained through at least one of the following: in-band latency measurement procedures, out-of-band latency measurement procedures, end-to-end latency measurement procedures, and segment-by-segment latency measurement procedures. The latency measurement procedures can be performed relative to application services.

[0211] Link delay measurement can be obtained through a measurement process that includes at least one of the following: an Internet Control Message Protocol (ICMP) echo reply process; an ICMP timestamp request and ICMP timestamp response process; delay reported by RTCP sender and receiver with a last sender report mark process; and an RTP PDU timestamp loading process by at least one of RTP header extension and RTP payload.

[0212] Data collection clients may include: Media Session Processor (MSH).

[0213] Link latency measurements can be based on at least one of the following: interval-based collection, where measurements are collected at a configured sampling frequency; threshold-based collection, where measurements are collected if they exceed a configured threshold; and / or event-based collection, where measurements are collected if a configured event is triggered. As an example, interval-based data collection can use a link latency measurement sampling frequency of 500 milliseconds. As another example, threshold-based data collection can use a link latency threshold of 20 milliseconds, for which any link latency exceeding the threshold generates a set of link latency measurement data. In yet another example, event-based data collection can use shared session establishment or update events, such that link latency measurement data is collected when triggered by the event.

[0214] Link latency performance events may include indications of at least one of the following: link latency performance of a shared connection; link latency performance of an end-to-end link; and / or link latency performance of a data network link. An end-to-end link may include a link between one of the first and second devices and one of the application server and the edge application server. A data network link may include a link between a PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

[0215] The instruction may include: an aggregation filter applied on a configured aggregation window, wherein the aggregation filter is based on at least one of the following: an averaging operation on the collected link delay performance measurements collected during the duration of the aggregation window; a maximizing operation on the collected link delay performance measurements collected during the duration of the aggregation window; and / or a counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

[0216] Figure 12 A method 1200, performed by a data collection application function, is illustrated for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The method 1200 includes: receiving 1210 a configuration of a data access profile for data collection, the data relating to link latency in the shared connection; and applying the data access profile to 1220 at least one data collection client. The method 1200 further includes: receiving 1230 collected link latency measurements from at least one data collection client; processing 1240 the link latency measurements, in part based on the data access profile, to generate one or more link latency performance events; and exposing 1250 one or more application-related link latency performance events experienced via the shared connection.

[0217] In some embodiments, method 1200 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0218] Therefore, data collection applications can expose link latency performance events, which facilitates the collection of measurements related to the performance of the shared connection. Such measurements are needed to provide performance analysis for a proper understanding of end-to-end quality of service. One metric for end-to-end quality of service may include end-to-end latency.

[0219] Data collection application functionality may include a Data Collection Application Function (DCAF). The DCAF can expose one or more link latency performance events to a first network node. The first network node may include network analysis functionality. The first network node may be an NWDAF.

[0220] The configuration of the data access profile used for data collection can include instructions for providing analysis of link latency. The shared connection of the application can include shared link latency or DN link latency. Performance analysis of the shared link connection can include latency or DN link latency. Performance analysis of latency can include average latency or maximum latency.

[0221] Applications experienced via a shared connection between the first and second devices can be performed through application sessions. An application session can include communication between a wireless communication device and an application server. An application session can include multiple links communicating through various access technologies.

[0222] The first device can be a sharing device, and the second device can be the device being shared. The first device can be a wireless communication device. For example, the second device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0223] The first device can be the device being shared, and the second device can be the device sharing. The second device can be a wireless communication device. For example, the first device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0224] The first and second devices can be configured to provide connectivity to the data network of at least one of the application server and the edge application server that host the application.

[0225] At least one data collection client may include at least one of the following: a direct data collection client, as a logical component of at least one of the first device and the second device; a data collection client, as a logical component at an application server corresponding to the application; and / or a data collection client, located at a logical component at an edge application server corresponding to the application.

[0226] Link latency measurements can be obtained through at least one of the following: in-band latency measurement procedures, out-of-band latency measurement procedures, end-to-end latency measurement procedures, and segment-by-segment latency measurement procedures. The latency measurement procedures can be performed relative to application services.

[0227] Link delay measurement can be obtained through a measurement process that includes at least one of the following: an Internet Control Message Protocol (ICMP) echo reply process; an ICMP timestamp request and ICMP timestamp response process; delay reported by RTCP sender and receiver with a last sender report mark process; and an RTP PDU timestamp loading process by at least one of RTP header extension and RTP payload.

[0228] Data collection clients may include Media Session Processors (MSH).

[0229] Link latency measurements can be based on at least one of the following: interval-based collection, where measurements are collected at a configured sampling frequency; threshold-based collection, where measurements are collected if they exceed a configured threshold; and / or event-based collection, where measurements are collected if a configured event is triggered. As an example, interval-based data collection can use a link latency measurement sampling frequency of 500 milliseconds. As an example, threshold-based data collection can use a link latency threshold of 20 milliseconds, for which any link latency exceeding the threshold generates a set of link latency measurement data. In another example, event-based data collection can use shared session establishment or update events, such that link latency measurement data is collected when triggered by the event.

[0230] Link latency performance events may include indications of at least one of the following: link latency performance of a shared connection; link latency performance of an end-to-end link; and / or link latency performance of a data network link. An end-to-end link may include a link between one of the first and second devices and one of the application server and the edge application server. A data network link may include a link between a PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

[0231] The instruction may include: an aggregation filter applied on a configured aggregation window, wherein the aggregation filter is based on at least one of the following: an averaging operation on the collected link delay performance measurements collected during the duration of the aggregation window; a maximizing operation on the collected link delay performance measurements collected during the duration of the aggregation window; and / or a counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

[0232] A data collection client is also provided for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. The data collection client includes a processor and memory coupled to the processor. The processor is configured to cause the device to: receive a data access profile from a data collection application function; collect link latency measurements according to the received data access profile; and send the collected link latency measurements to the data collection application function.

[0233] Therefore, data collection applications can expose link latency performance events, which facilitates the collection of measurements related to the performance of the shared connection. Such measurements are needed to provide performance analysis for a proper understanding of end-to-end quality of service. One metric for end-to-end quality of service may include end-to-end latency.

[0234] Data collection application functionality may include a Data Collection Application Function (DCAF). The DCAF can expose one or more link latency performance events to a first network node. The first network node may include network analysis functionality. The first network node may be an NWDAF.

[0235] The configuration of the data access profile used for data collection can include instructions for providing analysis of link latency. The shared connection of the application can include shared link latency or DN link latency. Performance analysis of the shared link connection can include latency or DN link latency. Performance analysis of latency can include average latency or maximum latency.

[0236] Applications experienced via a shared connection between the first and second devices can be performed through application sessions. An application session can include communication between a wireless communication device and an application server. An application session can include multiple links communicating through various access technologies.

[0237] The first device can be a sharing device, and the second device can be the device being shared. The first device can be a wireless communication device. For example, the second device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0238] The first device can be the device being shared, and the second device can be the device sharing. The second device can be a wireless communication device. For example, the first device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0239] The data collection client may include at least one of the following: a first device; a second device; and / or an application service provider device. The application service provider device may include an application server or an edge application server.

[0240] The first and second devices can be configured to provide connectivity to the data network of at least one of the application server and the edge application server that host the application.

[0241] The data collection client may include at least one of the following: a direct data collection client, as a logical component of at least one of the first device and the second device; a data collection client, as a logical component at an application server corresponding to the application; and / or a data collection client, located at a logical component at an edge application server corresponding to the application.

[0242] Link latency measurements can be obtained through at least one of the following: in-band latency measurement procedures, out-of-band latency measurement procedures, end-to-end latency measurement procedures, and segment-by-segment latency measurement procedures. The latency measurement procedures can be performed relative to application services.

[0243] Link delay measurement can be obtained through a measurement process that includes at least one of the following: an Internet Control Message Protocol (ICMP) echo reply process; an ICMP timestamp request and ICMP timestamp response process; delay reported by RTCP sender and receiver with a last sender report mark process; and / or an RTP PDU timestamp loading process via at least one of RTP header extension and RTP payload.

[0244] Data collection clients may include Media Session Processors (MSH).

[0245] Link latency measurements can be based on at least one of the following: interval-based collection, where measurements are collected at a configured sampling frequency; threshold-based collection, where measurements are collected if they exceed a configured threshold; and / or event-based collection, where measurements are collected if a configured event is triggered. As an example, interval-based data collection can use a link latency measurement sampling frequency of 500 milliseconds. As an example, threshold-based data collection can use a link latency threshold of 20 milliseconds, for which any link latency exceeding the threshold generates a set of link latency measurement data. In another example, event-based data collection can use shared session establishment or update events, such that link latency measurement data is collected when triggered by the event.

[0246] The link latency performance events of this method may include indications of at least one of the following: link latency performance of the shared connection; link latency performance of the end-to-end link; and link latency performance of the data network link. The end-to-end link is the link between one of the first and second devices and one of the application server and the edge application server. The data network link is the link between the PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

[0247] The instruction may include: an aggregation filter applied on a configured aggregation window, wherein the aggregation filter is based on at least one of the following: an averaging operation on the collected link delay performance measurements collected during the duration of the aggregation window; a maximizing operation on the collected link delay performance measurements collected during the duration of the aggregation window; and / or a counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

[0248] Figure 13 A method 1300, executed by a data collection client, is illustrated for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device. Method 1300 includes: receiving a data access profile from a data collection application function 1310; collecting link latency measurements based on the received data access profile 1320; and sending the collected link latency measurements to the data collection application function 1330.

[0249] In some embodiments, method 1300 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0250] Therefore, data collection applications can expose link latency performance events, which facilitates the collection of measurements related to the performance of the shared connection. Such measurements are needed to provide performance analysis for a proper understanding of end-to-end quality of service. One metric for end-to-end quality of service may include end-to-end latency.

[0251] Data collection application functionality may include a Data Collection Application Function (DCAF). The DCAF can expose one or more link latency performance events to a first network node. The first network node may include network analysis functionality. The first network node may be an NWDAF.

[0252] The configuration of the data access profile used for data collection can include instructions for providing analysis of link latency. The shared connection of the application can include shared link latency or DN link latency. Performance analysis of the shared link connection can include latency or DN link latency. Performance analysis of latency can include average latency or maximum latency.

[0253] Applications experienced via a shared connection between the first and second devices can be performed through application sessions. An application session can include communication between a wireless communication device and an application server. An application session can include multiple links communicating through various access technologies.

[0254] The first device can be a sharing device, and the second device can be the device being shared. The first device can be a wireless communication device. For example, the second device can include virtual reality headsets that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0255] The first device in this method can be the device being shared, and the second device can be the sharing device. The second device can be a wireless communication device. For example, the first device can include virtual reality headphones that connect to the wireless communication device via Bluetooth or Wi-Fi.

[0256] The data collection client may be included in at least one of the following: a first device; a second device; and / or an application service provider device. The application service provider device may include an application server or an edge application server.

[0257] The first and second devices can be configured to provide connectivity to the data network of at least one of the application server and the edge application server that host the application.

[0258] The data collection client may include at least one of the following: a direct data collection client, as a logical component of at least one of the first device and the second device; a data collection client, as a logical component at an application server corresponding to the application; and / or a data collection client, located at a logical component at an edge application server corresponding to the application.

[0259] Link latency measurements can be obtained through at least one of the following: in-band latency measurement procedures, out-of-band latency measurement procedures, end-to-end latency measurement procedures, and segment-by-segment latency measurement procedures. The latency measurement procedures can be performed relative to application services.

[0260] Link delay measurement can be obtained through a measurement process that includes at least one of the following: an Internet Control Message Protocol (ICMP) echo reply process; an ICMP timestamp request and ICMP timestamp response process; delay reported by RTCP sender and receiver with a last sender report mark process; and / or an RTP PDU timestamp loading process via at least one of RTP header extension and RTP payload.

[0261] Data collection clients may include Media Session Processors (MSH).

[0262] Link latency measurements can be based on at least one of the following: interval-based collection, where measurements are collected at a configured sampling frequency; threshold-based collection, where measurements are collected if they exceed a configured threshold; and / or event-based collection, where measurements are collected if a configured event is triggered. As an example, interval-based data collection can use a link latency measurement sampling frequency of 500 milliseconds. As an example, threshold-based data collection can use a link latency threshold of 20 milliseconds, for which any link latency exceeding the threshold generates a set of link latency measurement data. In another example, event-based data collection can use shared session establishment or update events, such that link latency measurement data is collected when triggered by the event.

[0263] The link latency performance events of this method may include indications of at least one of the following: link latency performance of the shared connection; link latency performance of the end-to-end link; and link latency performance of the data network link. The end-to-end link is the link between one of the first and second devices and one of the application server and the edge application server. The data network link is the link between the PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

[0264] The instruction may include: an aggregation filter applied on a configured aggregation window, wherein the aggregation filter is based on at least one of the following: an averaging operation on the collected link delay performance measurements collected during the duration of the aggregation window; a maximizing operation on the collected link delay performance measurements collected during the duration of the aggregation window; and / or a counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

[0265] Therefore, a method is provided for collecting, reporting, and exposing latency metrics as new event IDs in the context of a 5GS service-based architecture (SBA) for link performance analysis of immersive and interactive applications (e.g., XR applications) experienced by end users on shared UEs under challenging E2E latency budget requirements. The new event IDs are mapped to shared link latency performance, DN link latency performance, and E2E link latency performance, and can be accessed upon ASP AF request.

[0266] A method is also provided for exposing link latency performance events experienced on a shared user equipment (UE) of an application, the method comprising: configuring a data access profile for data collection for the shared UE and a data collection application function (DCAF); configuring the data access profile to apply to one or more data collection clients for link latency measurement data collection; collecting one or more link latency measurements, including the application of the shared UE, at one or more data collection clients, in part based on the data access profile; reporting the collected link latency measurements to the DCAF; processing the link latency measurements at the DCAF in part based on the data access profile to generate one or more link latency performance events; and exposing the application-related link latency performance events experienced on the shared UE from the DACF.

[0267] The shared UE can be formed by at least one shared device and a sharing device that provides connection access to a data network, which hosts at least one of an application server and an edge application server corresponding to the application.

[0268] One or more data collection clients may be represented by at least one of the following: a direct data collection client (DDCC) as a logical component of the shared UE; a data collection client as a logical component at the application server; and a data collection client at a logical component at the edge application server.

[0269] The method may also include determining latency measurement relative to the application service by at least one of the following: in-band latency measurement procedure, out-of-band latency measurement procedure, end-to-end latency measurement procedure, and segmented latency measurement procedure.

[0270] The delay measurement process may include at least one of the following: Internet Control Message Protocol (ICMP) echo response process; ICMP timestamp request and ICMP timestamp response process; delay reported by RTCP sender and receiver with a last sender report mark process; and RTPPDU timestamp loading process via at least one of RTP header extension and RTP payload.

[0271] DDCC can be part of the Media Session Processor (MSH).

[0272] The data collection client configuration may include collecting link latency measurements based on at least one of the following: interval-based collection, where measurements are collected at a configured sampling frequency; threshold-based collection, where measurements are collected if they exceed a configured threshold; and event-based collection, where measurements are collected if a configured event is triggered.

[0273] Each of one or more link latency performance events may include an indication of at least one of the following: link latency performance of a shared link, wherein the shared link is located between the shared device and the sharing device of the shared UE; link latency performance of an end-to-end link, wherein the end-to-end link is a link between the shared device and one of the application server and the edge application server; and link latency performance of a data network link, wherein the data network link is a link between the PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

[0274] The instruction may include: an aggregation filter applied on a configured aggregation window, wherein the aggregation filter is based on at least one of the following: an averaging operation on the collected link delay performance measurements collected during the duration of the aggregation window; a maximizing operation on the collected link delay performance measurements collected during the duration of the aggregation window; and a counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

[0275] It should be noted that the above-described methods and apparatus are illustrated but not intended to limit the invention, and those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of other elements or steps besides those listed in the claims, "a" or "an" does not exclude multiple, and a single processor or other unit may perform the functions of several units described in the claims. Any reference numerals in the claims should not be construed as limiting their scope.

[0276] Furthermore, while examples are given in the context of specific communication standards, these examples are not intended to limit the communication standards to which the disclosed methods and apparatus can be applied. For example, although specific examples are given in the context of 3GPP, the principles disclosed herein can also be applied to other wireless communication systems, and indeed to any communication system that uses routing rules.

[0277] This method can also be embodied in an instruction set stored on a computer-readable medium, which, when loaded into a computer processor, digital signal processor (DSP), etc., causes the processor to execute the above method.

[0278] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are to be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the meaning and equivalence of the claims should be included within their scope.

[0279] The following abbreviations are relevant to the areas covered in this document: 3GPP, 3rd Generation Partnership Project; 5G, 5th Generation; 5GS, 5G System; 5QI, 5G QoS Identifier; A-ADRF, Application Layer Analytics Data Repository Function; ADAEC, Application Data Analytics Enabled Client; ADAES, Application Data Analytics Enabled Server; A-DCCF, Application Layer Data Collection and Coordination Function; AF, Application Function; AMF, Access and Mobility Function; AR, Augmented Reality; AS, Application Server; ASP, Application Service Provider; DCAF, Data Collection AF; DL, Downlink; EAS, Edge Application Server; NAL, Network Abstraction Layer; NRM, Network Resource Management; PCF, Policy Control Function; PDU, Packet Data Unit; PPS, Picture Parameter Set; PSA UPF, PDU Session Anchor; PSB, PDU Set Boundary; PSI, PDU Set Importance; QoE, Quality of Experience; QoS, Quality of Service; RAN, Radio Access Network; RTCP, Real-Time Control Protocol; RTP, Real-Time Protocol; SDAP, Service Data Adaptation Protocol; SEAL, Service Enablement Application Layer; SMF, Session Management Function; SRTCP, Secure Real-Time Control Protocol; SRTP, Secure Real-Time Protocol; UE, User Equipment; UL, Uplink; UPF, User Plane Function; VAL, Vertical Application Layer; VCL, Video Coding Layer; VMAF, Video Multi-Method Evaluation Function; VPS, Video Parameter Set; VR, Virtual Reality; XR, Extended Reality; XR AS, XR Application Server; and XRM, XR Media.

Claims

1. A data collection application function for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device, the data collection application function comprising: processor; as well as A memory coupled to the processor, the processor being configured to enable the data collection application functions: Receive configuration of a data access profile for data collection, the data relating to link latency in the shared connection; Apply the data access configuration file to at least one data collection client; Receive the collected link latency measurements from the at least one data collection client; The link latency measurement is processed in part based on the data access profile to generate one or more link latency performance events; as well as Expose one or more link latency performance events experienced via the shared connection that correspond to the application.

2. The data collection application function according to claim 1, wherein the first device is a sharing device and the second device is a shared device.

3. The data collection application function according to claim 1, wherein the first device is a shared device and the second device is a sharing device.

4. The data collection application function according to any one of the preceding claims, wherein the first device and the second device are arranged to provide connectivity access to a data network, the data network hosting at least one of the following corresponding to the application: an application server and an edge application server.

5. The data collection application function according to any one of the preceding claims, wherein the at least one data collection client includes at least one of the following: A direct data collection client, serving as a logical component of at least one of the first device and the second device; The data collection client is a logical component of the application server corresponding to the application. and / or The data collection client is located at a logical component on the edge application server corresponding to the application.

6. The data collection application function according to any one of the preceding claims, wherein the link delay measurement is obtained by at least one of the following: in-band delay measurement process, out-of-band delay measurement process, end-to-end delay measurement process, and segment-by-segment delay measurement process.

7. The data collection application function according to any one of the preceding claims, wherein the link latency measurement is acquired through a measurement process, the measurement process comprising at least one of the following: Internet Control Message Protocol (ICMP) echo reply process; The ICMP timestamp request and ICMP timestamp response process; RTCP sender and receiver reports, with a delay in the last sender report marking process; as well as The process of loading an RTP PDU timestamp via at least one of RTP header extension and RTP payload.

8. The data collection application function according to any one of the preceding claims, wherein the data collection client comprises: Media Session Processor (MSH).

9. The data collection application function according to any one of the preceding claims, wherein the link latency measurement is based on at least one of the following: Interval-based collection, where measurements are collected at a configured sampling frequency; Threshold-based collection, wherein a measurement is collected if it exceeds a configured threshold; and / or Event-based collection, where measurements are collected if a configured event is triggered.

10. The data collection application function according to any one of the preceding claims, wherein the link latency performance event includes an indication of at least one of the following: Link latency performance of the shared connection; Link latency performance of the end-to-end link, wherein the end-to-end link is the link between one of the first device and the second device and one of the application server and the edge application server; and / or Link latency performance of the data network link, wherein the data network link is the link between the PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

11. The data collection application function of claim 10, wherein the indication includes: An aggregation filter applied to a configured aggregation window, wherein the aggregation filter is based on at least one of the following: The average operation of the collected link delay performance measurements collected during the duration of the aggregation window; The maximum operation of the collected link latency performance measurements collected within the duration of the aggregation window; and / or A counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

12. A method performed by a data collection application function, the method being used to expose application link latency performance events experienced via a shared connection between a first device and a second device, the method comprising: Receive configuration of a data access profile for data collection, the data relating to link latency in the shared connection; Apply the data access configuration file to at least one data collection client; Receive the collected link latency measurements from the at least one data collection client; The link latency measurement is processed in part based on the data access profile to generate one or more link latency performance events; as well as Expose one or more link latency performance events experienced via the shared connection that correspond to the application.

13. A data collection client for exposing link latency performance events of an application experienced via a shared connection between a first device and a second device, the data collection client comprising: processor; as well as A memory coupled to the processor, the processor being configured such that the device: Receive data access configuration files from data collection application functions; Based on the received data, access the configuration file to collect link latency measurements; Send the collected link delay measurements to the data collection application function.

14. The data collection client of claim 13, wherein the first device is a sharing device and the second device is a shared device.

15. The data collection client of claim 13, wherein the first device is a shared device and the second device is a sharing device.

16. The data collection client according to any one of claims 13, 14, and 15, wherein the data collection client is included in at least one of: The first device; The second device, and / or Application service provider equipment.

17. The data collection client according to any one of claims 13 to 16, wherein the first device and the second device are arranged to provide connectivity access to a data network, the data network hosting at least one of the following corresponding to the application: an application server and an edge application server.

18. The data collection client according to any one of claims 13 to 17, wherein the data collection client comprises at least one of the following: A direct data collection client, serving as a logical component of at least one of the first device and the second device; The data collection client is a logical component of the application server corresponding to the application. and / or The data collection client is located at a logical component on the edge application server corresponding to the application.

19. The data collection client according to any one of claims 13 to 18, wherein the link delay measurement is obtained by at least one of: in-band delay measurement process, out-of-band delay measurement process, end-to-end delay measurement process, and segment-by-segment delay measurement process.

20. The data collection client according to any one of claims 13 to 19, wherein the link latency measurement is acquired through a measurement process comprising at least one of the following: Internet Control Message Protocol (ICMP) echo reply process; The ICMP timestamp request and ICMP timestamp response process; RTCP sender and receiver reports, with a delay in the last sender report marking process; as well as The process of loading an RTP PDU timestamp via at least one of RTP header extension and RTP payload.

21. The data collection client according to any one of claims 13 to 20, wherein the data collection client comprises: Media Session Processor (MSH).

22. The data collection client according to any one of claims 13 to 21, wherein the link latency measurement is based on at least one of: Interval-based collection, where measurements are collected at a configured sampling frequency; Threshold-based collection, wherein a measurement is collected if it exceeds a configured threshold; and / or Event-based collection, where measurements are collected if a configured event is triggered.

23. The data collection client according to any one of claims 13 to 22, wherein the link latency performance event includes an indication of at least one of the following: Link latency performance of the shared connection; The link latency performance of the end-to-end link, wherein the end-to-end link is the link between one of the first device and the second device and one of the application server and the edge application server; and Link latency performance of the data network link, wherein the data network link is the link between the PDU Session Anchor User Plane Function (PSA UPF) and one of the application server and the edge application server.

24. The data collection client of claim 23, wherein the instruction includes an aggregation filter applied on a configured aggregation window, wherein the aggregation filter is based on at least one of: The average operation of the collected link delay performance measurements collected during the duration of the aggregation window; The maximum operation of the collected link latency performance measurements collected within the duration of the aggregation window; and / or A counting operation on the collected link delay performance measurements collected during the duration of the aggregation window.

25. A method performed by a data collection client for exposing application link latency performance events experienced via a shared connection between a first device and a second device, the method comprising: Receive data access configuration files from data collection application functions; Collect link latency measurements based on the received data access profile; Send the collected link delay measurements to the data collection application function.

Images