WO2024088587A1

WO2024088587A1 - Providing performance analytics of a tethered connection in a wireless communication network

Info

Publication number: WO2024088587A1
Application number: PCT/EP2023/060181
Authority: WO
Inventors: Dimitrios Karampatsis; Razvan-Andrei Stoica; Emmanouil Pateromichelakis
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2023-03-03
Filing date: 2023-04-19
Publication date: 2024-05-02
Anticipated expiration: 2025-09-03

Abstract

There is provided a method performed by a first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network. The method comprises: receiving a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determining to collect data for the tethered connection from a data collection application function based on the first indication; sending a second request to the data collection application function to retrieve measurements for the tethered connection; deriving performance analytics for the tethered connection; and sending the derived performance analytics in response to the first request.

Description

PROVIDING PERFORMANCE ANALYTICS OF A

TETHERED CONNECTION IN A WIRELESS

COMMUNICATION NETWORK

Field

[0001] The subject matter disclosed herein relates generally to the field of providing performance analytics of a tethered connection in a wireless communication network. This document defines a first network node, and a method performed by a first network node.

Introduction

[0002] In many interactive and immersive applications with challenging requirements on latency, rate and reliability, the application experience is served over a tethered connection whereby an endpoint Personal loT Network Element (PINE) device is connected to a gateway device which in turn is connected to a 3GPP access network (e.g., 4G, 5G or alike) for Internet connectivity. Examples of such application experience delivery include, for instance, AR/VR experiences where the PINE is a headmounted device (HMD) in the form of AR/VR glasses and the gateway is a mobile phone, or alternatively, 3GPP user equipment (UE). The end-to end connectivity between a client device and an application server relies therefore on at least three heterogeneous network segments, i.e., the tethered link, the 3GPP connectivity, and the data network (DN) link. The tethered and DN links are out of scope of 3GPP. The tethered link between the PINE and the gateway relies usually on Wi-Fi, Bluetooth, or unlicensed spectrum radio access technologies. Such a connection affects the end-to-end quality of service (QoS) and in effect both the tethered link and the DN link contribute in such a way as to reduce the effectiveness of QoS rules and policies employed within the 3GPP network.

Summary

[0003] There is a need for a solution that facilitates efficient monitoring at the 5G system (including the enablement layer) of the delay components for the end to end application service, assuming that the end UE device is decoupled from the application running (which can be deployed at a tethered UE), and how to guarantee that the service KPI is met, considering different technologies and connective links used along the end- to-end service (which are not under the control of the 5G system). Each connective link generates a component of the total end-to-end delay.

[0004] Disclosed herein are procedures for providing performance analytics of a tethered connection in a wireless communication network. Said procedures may be implemented by a first network node, and a method performed by a first network node. [0005] Accordingly, there is provided a first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network. The first network node comprises a processor; and a memory coupled with the processor. The processor is configured to cause the first network node to: receive a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determine to collect data for the tethered connection from a data collection application function based on the first indication; send a second request to the data collection application function to retrieve measurements for the tethered connection; derive performance analytics for the tethered connection; and send the derived performance analytics in response to the first request.

[0006] The first request may additionally include a second indication to provide performance analytics for a connection between the application server and a user plane function of the wireless communication network. Then the processor may be further configured to cause the first network node first network node to: collect data from one or more network functions based on the second indication; determine an application function arranged to provide measurements for performance analytics between the user plane function and the application server; send a third request to an application function to retrieve measurements for the performance analytics; wherein the performance analytics are derived for both the tethered connection and the connection between the application server and the user plane function of the wireless communication network. [0007] There is further provided a method performed by a first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network. The method comprises: receiving a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determining to collect data for the tethered connection from a data collection application function based on the first indication; sending a second request to the data collection application function to retrieve measurements for the tethered connection; deriving performance analytics for the tethered connection; and sending the derived performance analytics in response to the first request.

[0008] The first request may additionally include a second indication to provide performance analytics for a connection between the application server and a user plane function of the wireless communication network. Then the method may further comprise collecting data from one or more network functions based on the second indication; determining an application function arranged to provide measurements for performance analytics between the user plane function and the application server; sending a third request to an application function to retrieve measurements for the performance analytics; wherein the performance analytics are derived for both the tethered connection and the connection between the application server and the user plane function of the wireless communication network.

Brief description of the drawings

[0009] In order to describe the manner in which advantages and features of the disclosure can be obtained, a description of the disclosure is rendered by reference to certain apparatus and methods which are illustrated in the appended drawings. Each of these drawings depict only certain aspects of the disclosure and are not therefore to be considered to be limiting of its scope. The drawings may have been simplified for clarity and are not necessarily drawn to scale.

[0010] Methods and apparatus for providing performance analytics of a tethered connection in a wireless communication network will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 depicts an embodiment of a wireless communication system for providing performance analytics of a tethered connection in a wireless communication network;

Figure 2 depicts a user equipment apparatus that may be used for implementing the methods described herein;

Figure 3 depicts further details of the network node that may be used for implementing the methods described herein;

Figure 4 which illustrates an overview of a core network XRM architecture handling data packets;

Figure 5 depicts an implementation of a first tethering approach as tethered standalone glasses;

Figure 6 illustrates an implementation of AR glasses whereby an XR tethered link exposes an XR runtime to 5G or alike Device as an XR runtime API;

Figure 7 illustrates an implementation of AR glasses whereby exposure of the XR runtime via the tethering link as media buffer source and sink is supported by a virtualized edge network XR runtime instance;

Figure 8 illustrates an E2E path and subsequent path delays;

Figure 9 illustrates an example wireless communication system;

Figure 10 illustrates a generic DCAF architecture depicted in simplified format;

Figure 11 illustrates a system in which a UE reports a tethered delay;

Figure 12 illustrates a method whereby an analytics consumer requests an Analytics ID “DN Performance” procedure;

Figure 13 illustrates a method performed by a first network node of a wireless communication network for enabling performance analytics of a tethered connection; and

Figure 14 illustrates a method that may be performed in addition to the method of figure 13.

Detailed description

[0011] As will be appreciated by one skilled in the art, aspects of this disclosure may be embodied as a system, apparatus, method, or program product. Accordingly, arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, micro-code, etc.) or a form combining software and hardware aspects. [0012] For example, the disclosed methods and apparatus may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

[0013] 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, referred hereafter as code. The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In certain arrangements, the storage devices only employ signals for accessing code.

[0014] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The 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.

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

[0016] Reference throughout this specification to an example of a particular method or apparatus, or similar language, means 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. Thus, reference to features of an example of a particular method or apparatus, or similar language, may, but do not necessarily, all refer to the same example, but mean “one or more but not all examples” unless expressly specified otherwise. The terms “including”, “comprising”, “having”, and variations thereof, mean “including but not limited to”, unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an”, and “the” also refer to “one or more”, unless expressly specified otherwise.

[0017] As used herein, a list with a conjunction of “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 terminology “one or more of’ 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 terminology “one of’ includes one, and only one, of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes 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, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ 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.

[0018] Furthermore, the described features, structures, or characteristics described herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed methods and apparatus may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

[0019] Aspects of the disclosed method and apparatus are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions /acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0020] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/ act specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0021] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which executes on the computer or other programmable apparatus provides processes for implementing the functions /acts specified in the schematic flowchart diagrams and/or schematic block diagram.

[0022] The schematic flowchart diagrams and/ or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products. In this regard, each block in the schematic flowchart diagrams and/ or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s). [0023] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0024] The description of elements in each figure may refer to elements of proceeding Figures. Like numbers refer to like elements in all Figures. [0025] Figure 1 depicts an embodiment of a wireless communication system 100 for providing performance analytics of a tethered connection in a wireless communication network. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Even though a specific number of remote units 102 and network units 104 are depicted in Figure 1, one of skill in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The wireless communication system may comprise a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP User Equipment (UE). The wireless communication network may comprise at least one network node. The network node may be a network unit.

[0026] In one embodiment, the remote units 102 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle onboard computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like. In some embodiments, the remote units 102 include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units 102 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL communication signals. In certain embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communication.

[0027] The network units 104 may be distributed over a geographic region. In certain embodiments, a network unit 104 may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a core network, an aerial server, a radio access node, an AP, NR, a network entity, an Access and Mobility Management Function (“AMF”), a Unified Data Management Function (“UDM”), a Unified Data Repository (“UDR”), a UDM/UDR, a Policy Control Function (“PCF”), a Radio Access Network (“RAN”), an Network Slice Selection Function (“NSSF”), an operations, administration, and management (“OAM”), a session management function (“SMF”), a user plane function (“UPF”), an application function, an authentication server function (“AUSF”), security anchor functionality (“SEAF”), trusted non-3GPP gateway function (“TNGF”), an application function, a service enabler architecture layer (“SEAL”) function, a vertical application enabler server, an edge enabler server, an edge configuration server, a mobile edge computing platform function, a mobile edge computing application, an application data analytics enabler server, a SEAL data delivery server, a middleware entity, a network slice capability management server, or by any other terminology used in the art. The network units 104 are generally part of a radio access network that includes one or more controllers communicab ly coupled to one or more corresponding network units 104. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, like the Internet and public switched telephone networks, among other networks. These and other elements of radio access and core networks are not illustrated but are well known generally by those having ordinary skill in the art.

[0028] In one implementation, the wireless communication system 100 is compliant with New Radio (NR) protocols standardized in 3GPP, wherein the network unit 104 transmits using an Orthogonal Frequency Division Multiplexing (“OFDM”) modulation scheme on the downlink (DL) and the remote units 102 transmit on the uplink (UL) using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an OFDM scheme. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication protocol, for example, WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, LoraWAN, among other protocols. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0029] The network units 104 may serve a number of remote units 102 within a serving area, for example, a cell or a cell sector via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and/ or spatial domain.

[0030] Figure 2 depicts a user equipment apparatus 200 that may be used for implementing the methods described herein. The user equipment apparatus 200 is used to implement one or more of the solutions described herein. The user equipment apparatus 200 is in accordance with one or more of the user equipment apparatuses described in embodiments herein. In particular, the user equipment apparatus 200 may comprise a remote unit 102, a UE 435, 904, a 5G device 530, 630, 730, a UE 1135, or a tethered UE 1131, as described herein. The user equipment apparatus 200 may include a data collection client as defined herein. The user equipment apparatus 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

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

[0032] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 may communicate with one or more cells (or wireless coverage areas) supported by one or more base units. The transceiver 225 may be operable on unlicensed spectrum. Moreover, the transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, the 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, Nl, PC5, etc. Other network interfaces 240 may be supported, as understood by one of ordinary skill in the art.

[0033] The processor 205 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. The processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225. [0034] The processor 205 may control the user equipment apparatus 200 to implement the user equipment apparatus behaviors described herein. The processor 205 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions.

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

[0036] The memory 210 may store data related to implement a traffic category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the apparatus 200. [0037] The input device 215 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display. The input device 215 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touch panel.

[0038] The output device 220 may be designed to output visual, audible, and/ or haptic signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a Liquid Crystal Display (“LCD”), a Light- Emitting Diode (“LED”) display, an Organic LED (“OLED”) display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 220 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 200, such as a smartwatch, smart glasses, a heads-up display, or the like. Further, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0039] The output device 220 may include one or more speakers for producing sound. For example, the output device 220 may produce an audible alert or notification (e.g., a beep or chime). The output device 220 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 220 may be integrated with the input device 215. For example, the input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. The output device 220 may be located near the input device 215. [0040] The transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or portions thereof) at particular times in order to send and receive messages.

[0041] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The one or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, the one or more receivers 235 may be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are illustrated, the user equipment apparatus 200 may have any suitable number of transmitters 230 and receivers 235. Further, the transmitter(s) 230 and the receiver(s) 235 may be any suitable type of transmitters and receivers. The transceiver 225 may include a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

[0042] The first transmitter/ receiver pair may be used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example 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 may share one or more hardware components. For example, certain transceivers 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access a shared hardware resource and/or software resource, such as for example, the network interface 240.

[0043] One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a single hardware component, such as a multitransceiver chip, a system-on-a-chip, an Application-Specific Integrated Circuit (“ASIC”), or other type of hardware component. One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a multi-chip module. Other components such as the network interface 240 or other hardware components/ circuits may be integrated with any number of transmitters 230 and/ or receivers 235 into a single chip. The transmiters 230 and receivers 235 may be logically configured as a transceiver 225 that uses one more common control signals or as modular transmiters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module.

[0044] Figure 3 depicts further details of the network node 300 that may be used for implementing the methods described herein. The network node 300 may be one implementation of an entity in the wireless communication network, e.g. in one or more of the wireless communication networks described herein. The network node 300 may comprise a first network node as described herein. The network node 300 may include a Network Data Analytics Function (NWDAF) 910, 912, 1032, 1232 as described herein. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325.

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

[0046] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. Additionally, the transceiver 325 may support at least one network interface 340 and/or application interface 345. The application interface(s) 345 may support one or more APIs. The network interface(s) 340 may support 3GPP reference points, such as Uu, Nl, N2 and N3. Other network interfaces 340 may be supported, as understood by one of ordinary skill in the art.

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

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

[0049] The memory 310 may store data related to establishing a multipath unicast link and/ or mobile operation. For example, the memory 310 may store parameters, configurations, resource assignments, policies, and the like, as described herein. The memory 310 may also store program code and related data, such as an operating system or other controller algorithms operating on the network node 300.

[0050] The input device 315 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display. The input device 315 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touch panel.

[0051] The output device 320 may be designed to output visual, audible, and/ or haptic signals. The output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 320 may include a wearable display separate from, but communicatively coupled to, the rest of the network node 300, such as a smartwatch, smart glasses, a heads-up display, or the like. Further, the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0052] The output device 320 may include one or more speakers for producing sound. For example, the output device 320 may produce an audible alert or notification (e.g., a beep or chime). The output device 320 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 320 may be integrated with the input device 315. For example, the input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. The output device 320 may be located near the input device 315. [0053] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. The one or more transmitters 330 may be used to communicate with the UE, as described herein. Similarly, the one or more receivers 335 may be used to communicate with network functions in the PLMN and/ or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 may have any suitable number of transmitters 330 and receivers 335. Further, the transmitter(s) 330 and the receiver(s) 335 may be any suitable type of transmitters and receivers.

[0054] In many interactive and immersive applications with challenging requirements on latency, rate and reliability, the application experience is served over a tethered connection whereby an endpoint Personal loT Network Element (PINE) device is connected to a gateway device which in turn is connected to a 3GPP access network (e.g., 4G, 5G or alike) for Internet connectivity. Examples of such application experience delivery include, for instance, AR/VR experiences where the PINE is a headmounted device (HMD) in the form of AR/VR glasses and the gateway is a mobile phone, or alternatively, 3GPP user equipment (UE). The end-to-end (E2E) connectivity between a client and an application server relies therefore on at least three heterogeneous network segments, i.e., the tethered link, the 3GPP connectivity, and the data network (DN) link. The tethered and DN links are out of scope of 3GPP. The tethering connection between the PINE and the gateway relies usually on Wi-Fi, Bluetooth, or unlicensed spectrum radio access technologies. Such a connection affects the E2E QoS and in effect both the tethered link and the DN link contribute in such a way as to reduce the effectiveness of QoS rules and policies employed within the 3GPP network. [0055] As such, it is of high importance for 3GPP networks to monitor and ingest link metrics regarding the performance of out-of-scope network segments (e.g., tether link, DN link) across a heterogeneous E2E network path. A 3GPP network may also perform analytics of such link metrics and derive statistical characterizations of the expected performance. Further such a 3GPP network may adapt the 3GPP QoS rules and policies and compensate for out-of-scope network segments degrading effects (e.g., additional latency etc.) and seamlessly satisfy E2E applications requirements for an enhanced user experience.

[0056] There is a need for a solution that facilitates efficient monitoring at the 5G system (including the enablement layer) of the delay components for the end to end application service, assuming that the end UE device is decoupled from the application running (which can be deployed at a tethered UE), and how to guarantee that the service KPI is met, considering different technologies and connective links used along the E2E service (which is not under the control of the 5G system). Each connective link generates a component of the total E2E delay.

[0057] The core network handles packets, which may be Protocol Data Units (PDUs), and which may be grouped into PDU-sets, as shown in Figure 4, which illustrates an overview of a core network (CN) XRM architecture handling data packets. Figure 4 shows a system 400 comprising an Extended Reality Media Application Function (XRM AF) 410, a Policy and Control Function (PCF) 415, a Session Management Function (SMF) 420, an Access and Mobility Function (AMF) 425, a Radio Access Network (RAN 430, a User Equipment (UE) 435, a User Plane Function (UPF) 440, and an Application Service Provider 410. The Application Service Provider 410 comprises an Application Function (AF) 412 and an Application Server 414. The UE 435 may comprise a remote unit 102 or a user equipment apparatus 200 as described herein. The RAN 430 may comprise a base unit 104, a network node 300 as described herein. The operation of system 400 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic.

[0058] At 480, the AF 412 determines PDU requirements.

[0059] At 481, the Application Function 412 provides QoS requirements for packets to the PCF 415 and information to identify the application (i.e. 5-tuple or application id). The QoS requirements may be expressed in terms of 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).

[0060] At 482, the PCF 415 determines QoS rules for the application and specific QoS requirements for the PDU. The QoS rules may use a 5G QoS identifier (5QI) for application traffic. The PCF 415 makes such a determination by determining a 5QI for the application PDU traffic. The PCF 415 sends the QoS rules to the SMF 420 as a 5- tuple PDU QoS Requirement. The PCF 415 may include in the communication to the SMF 420 Policy and Charging Control (PCC) rules per importance of a PDU set. The PCC rules may be derived according to information received from the AF 412 or based on an operator configuration.

[0061] At 483, the SMF 420 establishes a QoS flow according to the QoS rules by the PCF 415 and configures the UPF to route packets of the application to a QoS flow. The SMF 420 also provides the QoS profile containing PDU set QoS requirements to the RAN 430 via the AMF 425. The AMF 425 may provide the QoS profile containing PDU set QoS requirements to the RAN 430 in an N2 Session Management (SM) container. Further, the AMF 425 may provide the QoS rules to the UE 435 in an N1 SM container.

[0062] At 484, the UPF 440 determines and routes the PDUs of the application (i.e., a 5 tuple) to a corresponding QoS flow, according to the N4 rules received from the SMF 420.

[0063] At 485, the RAN 430 receives QFIs, QoS profile of QoS flows from the SMF 420 via the AMF 425 during PDU session establishment/ modification, identifies packets belonging to a PDU session of an application over a QoS flow and handles the packets over RBs according to the QoS requirements provided by the SMF 420. The RAN 430 inspects GTP-U headers and ensures PDUs are handled according to the determined QoS profile according to SM container. This may include transmitting some packets in a radio bearer carrying QoS flow 1. This may also include sending other packets in a different radio bearer carrying QoS flow 2.

[0064] The general steps described above regarding the QoS flow handling, RB to QoS flow to application flow mapping and PDU session handling are applicable for both UL and DL directions. That is, while the above example relates to downlink (DL) traffic, reciprocal processing is applicable to uplink (UL) traffic wherein the role of UPF 440 packet inspection is taken by the UE 435. The low-level signaling mechanism associated with the UL UE-to-RAN information passing are up to the specification and implementations of RAN signaling procedures.

[0065] Herein, extended Reality (XR) is used as an umbrella term for different types of realities, of which Virtual Reality, Augmented Reality, and Mixed Reality are examples. [0066] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is in this case designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually also necessary to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. In some implementations additional means to interact with the virtual reality simulation may be provided but are not strictly necessary. [0067] Augmented Reality (AR) is when a user is provided with additional information or artificially generated items, or content overlaid upon their current environment. Such additional information or content will usually be visual and/ or audible and their observation of their current environment may be direct, with no intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed.

[0068] Mixed Reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

[0069] XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. In some circles, a key aspect of XR is considered to be the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0070] In 3GPP Release 17, 3GPP SA4 Working Group analyzed the Media transport Protocol and XR traffic model in the Technical Report TR 26.926 (vl.1.0) titled “Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems”, and decided the QoS requirements in terms of delay budget, data rate and error rate necessary for a satisfactory experience at the application level. These led to 4 additional 5G QoS Identifiers (5QIs) for the 5G System (5GS) XR QoS flows. These 5QIs are defined in 3GPP TS 23.501 (vl7.5.0), Table 5.7.4-1, presented there as delay-critical GBR 5QIs valued 87-90. The latter are applicable to XR video streams and control metadata necessary to provide the immersive and interactive XR experiences.

[0071] The XR video traffic is mainly composed of multiple DL/UL video streams of high resolution (e.g., at least 1080p dual-eye buffer usually), frames-per-second (e.g., 60+ fps) and high bandwidth (e.g., usually at least 20-30 Mbps) which needs to be transmitted across a network with minimal delay (typically upper bounded by 15-20 ms) to maintain a reduced end-to-end application round-trip interaction delay. The latter requirements are of critical importance given the XR application dependency on cloud/ edge processing (e.g., content downloading, viewport generation and configuration, viewport update, viewport rendering, media encoding/ transcoding etc.). [0072] Tethered and Heterogeneous Links may be used for Media Applications. In Release 17, 3GPP studied the support of 5G and beyond XR glasses based on a common client architecture, relying on three major components: an XR runtime, a Scene Manager, and a Media Access Function (MAF). Out of the three of general relevance for communications aspects is the MAF.

[0073] 3GPP Technical Report TR 26.998 (vl8.0.0 — Dec 2022) describes Support of 5G Glass-type AR/MR devices, and defines the Media Access Function (MAF) as supporting the AR UE to access and stream media. For this purpose, a MAF includes:

• Codecs: used to compress and decompress the media. In several cases, not only a single instance of a codec per media type is needed, but multiple ones.

• Content Delivery Protocols: Container format and protocol to deliver media content between the UE and the network according to the requirements of an application. This includes timing, synchronization, reliability, protocol-level reporting (e.g., RTP reporting) and other features.

• 5G connectivity: a modem and 5G System functionalities that allow the UE to connect to a 5G network and get access to the features and service offered by the 5G System.

• Media Session Handler: A generic function on the device to setup 5G System capabilities and support 5GS integration. This may setup edge functionalities, provide QoS support, support reporting functionalities, etc.

• Content protection and decryption: This function handles protection of content from being played on unauthorized devices.

[0074] Some example implementations of MAF are:

• 5GMSd client that includes a Media Session Handler and a Media Player as defined in TS 26.501 and TS 26.512.

• 5GMSu client that includes a Media Session Handler and a Media Streamer as defined in TS 26.501 and TS 26.512.

• A real-time communication client that includes either uplink or downlink, or both to support more latency critical communication services, such as for XR applications.

[0075] In Release 18, 3GPP is studying further the tethering aspects for XR glass type devices whereby two different tethering approaches are established as:

• Tethered standalone glasses: In this case, the glasses run an XR application that uses the capabilities of the glasses to create a service. The glasses are tethered to a 5G device or alike mobile access technology (e.g., a mobile phone) and potentially use the capabilities of the phone (e.g., Media Session Handler) to support the application.

• Tethered display glasses: In this case, the glasses are tethered to a 5G device or alike mobile access technology (e.g., a mobile phone) that includes the application and the XR functions, i.e., at least the MAF and/ or a lightweight scene manager instance. The 5G device runs the application that uses the capabilities of the 5G device to run an XR experience. The glasses are connected to the 5G device and embed at least a lightweight XR runtime which is exposed to the 5G device either via an XR runtime-specific API over an XR tethered link or via a wireless link exposing media buffers.

[0076] An implementation depicting the first tethering approach as tethered standalone glasses is depicted in Figure 5. An AR glasses device 510 is tethered to a 5G Device 530. The AR glasses device 510 comprises an XR runtime 512, an XR runtime API 514, an AR/MR application 516, a wireless connection module 518, and a 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 the XR runtime 512, which comprises visual composition, haptics and audio composition. The XR runtime API 514 provides an interface between the XR runtime 512 and each of an uplink media management module 520, and a presentation engine 526. The presentation engine 526 comprises a visual renderer and an audio Tenderer and interfaces with a scene manager 527. The media access function 552 comprises metadata codecs, video codecs and audio codecs and a MAF API 554. The AR/MR application 516 interfaces with each of the XR runtime API 514, the scene manager 527, and the MAF API 554.

[0077] A tethering connection is provided between the AR glasses device 510 and the 5G device 530 by respective wireless connectivity modules 518, 538. The MAF 552 passes compressed media to and from the tethered connection via the wireless connectivity module 518. 5G device 530 likely comprises a smartphone and includes a 5G system module 535. Phone based processing functions are performed by a processor 531. The phone-based processing functions comprise an API 533 which is able to pass configuration information to the AR/MR application 516 via the tethering connection. [0078] Figure 6 illustrates an implementation of AR glasses whereby an XR tethered link exposes an XR runtime to 5G Device as an XR runtime API. An AR glasses device 610 is tethered to a 5G Device 630. The AR glasses device 610 comprises an XR runtime core functions 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 functions 612, which comprises visual composition, haptics and audio composition. An XR link function glasses 611 operates as an interface between the XR runtime core functions 612 and a wireless connection module 618 of the AR glasses device 610.

[0079] A tethering connection is provided between the AR glasses device 610 and the 5G device 630 by respective wireless connectivity modules 618, 638. The 5G device 630 comprises an XR link functions device 613 that provides an interface between the wireless connectivity module 638 and the XR runtime API 614. The 5G device 630 further comprises an AR/MR application 616, and a Media Access Function 652. The XR runtime API 614 provides an interface between the XR link functions device 613 and each of an uplink media management module 620, and a presentation engine 626. The presentation engine 626 comprises a visual Tenderer and an audio tenderer and interfaces with a scene manager 627. The media access function 652 comprises metadata codecs, video codecs and audio codecs and 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. 5G device 630 likely comprises a smartphone and includes a 5G system module 635. The MAF 652 passes compressed media to and from 5G system module 635.

[0080] Figure 7 illustrates an implementation of AR glasses whereby exposure of the XR runtime via the tethering link as media buffer source and sink is supported by a virtualized edge network XR runtime instance. An AR glasses device 710 is tethered to a 5G Device 730; the 5G device 730 is connected to an edge network 750 via a 5G connection. The AR glasses device 710 comprises an XR runtime core functions 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 functions 712. An XR runtime API 714 provides an interface to a basic AR/MR application 716.

[0081] A tethering connection is provided between the AR glasses device 710 and the 5G device 730 by respective wireless connectivity modules 718, 738. The XR runtime core functions 712 of the AR glasses device 510 exchanges data with the 5G device 730 via the tethering connection. 5G device 730 likely comprises a smartphone and includes a 5G system module 735. The 5G device 730 comprises a Media Access Function 732. The MAF 752 passes compressed media to and from 5G system module 735. [0082] The edge network 750 comprises a media access functions 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 functions 752 via a MAF API 754, and with the XR scene manager 758 via a XR scene API 759. An XR runtime API 757 provides an interface between the XR runtime 756 and the XR scene manager 758.

[0083] All three tethering architectures of figures 5, 6 and 7 can be supported by edge split-rendering to reduce the complexity, processing requirements, power consumption, and heat dissipation on the XR glasses. To this end, some key issues identified in the Release 18 3GPP tethering study relate to the monitoring and reporting of tethering link and DN link latencies, and respectively, to the management of E2E QoS delay budget. [0084] The latency monitoring and reporting solution presented herein is thus of relevance because in an E2E connection including a tethering link (e.g., Wi-Fi link, or a Bluetooth link), a 5G network and the Internet, the Wi-Fi segment and the Internet segment typically cannot guarantee latency. A low E2E latency is required by the XR applications to provide a good quality of experience (QoE) to the end user. Such a QoE may lead to the experience feeling more immersive to the user and also make the experience feel more interactive. To achieve the requisite low E2E latency of XR applications, one approach is to make the latency in the 5G network very conservative such that the end-to-end latency is below a target value. This, however, comes at a cost, because only a finite bandwidth is available in the wireless communication system and provisioning an unnecessarily low latency in the 5G network requires excessive radio resource allocation. Such excessive radio resource allocation might support a more robust modulation-and-coding scheme (MCS), but would require many other traffic flows to be deprived of bandwidth resources.

[0085] Accordingly, the solution presented here is to dynamically adjust the delay in the 5G network in accordance with the total delay incurred elsewhere on the E2E path. This requires a measure of the non 5G delay in the total E2E connection between the tethered headset and the application server. The delay on a Wi-Fi link may change over time depending on the interference generated by other nearby Wi-Fi networks operating within the same frequency band. Similarly, the delay between the UPF and the application server (AS) depends on the location of the selected UPF, the selected edge/AS and on the network congestion level. Therefore, measurements may be used to estimate these time-varying delays on the non-5G segments. [0086] There is thus provided an efficient implementation the determination of delays across the non-5G segments of the E2E path between a glasses endpoint and an AS, or alternatively, an edge AS (EAS) for split-rendering.

[0087] Figure 8 illustrates an E2E path and subsequent path delays. In this example, the E2E path comprises AR glasses 805, a phone 835, a gNB 830, a UPF 840, and an Edge Application server 814. The delay notation illustrated in figure 8 is defined as follows.

• D_e2e: denotes the E2E delay in one direction, i.e., either UL or DL.

• D_5G : denotes the 5GS delay from the PSA UPF to the UE, which is measurable by means of core network QoS monitoring procedures described in 3GPP TS 23.501 and RAN Layer 2 measuring procedures described in TS 38.314; this can be measured both based on average performance of DRBs and QoS flows, but also per QoS flow and per DRB per UE. For the latter, per QoS flow per UE QoS monitoring procedure is applied leveraging the GTP-U headers to carry the timestamps necessary for PSA UPF to NG-RAN measurements, whereas the delay between NG-RAN to UE is measured on average per DRB per UE conform RAN Layer 2 procedures at PDCP layer.

• D_{n l}: denotes the tether link (e.g., Wi-Fi, Bluetooth) delay.

• D_{n 2}: denotes the DN link (e.g., connection between PSA UPF and AS, or alternatively, EAS) latency.

• D_n: denotes the total non-5G/non-3GPP E2E delay accumulated over the tethered link and the DN link segments as D_n = D_{n l} + D_{n 2}.

[0088] It is therefore useful to determine D_n so as to allow fine control of D_5GS by means of QoS rules such that the delay budget and requirements of an application, i.e., ^e2e,max met, i.e., D_e2e D$_G + D_n < D_{e2e max}.

[0089] The delay measurement can thus be either performed on a segment-by-segment basis, whereby the delays detailed above are determined individually and because of interest is the determination of D_{n l} and D_{n 2} delays.

[0090] For delay measurement, the measured delay may be representative of the delay to be experienced by data packets passing between the AR glasses 805 and the edge application server 814. Delay measurements based on out-of-band delay measurement messages such as the ping message (ICMP Echo and Echo Reply, according to RFC 792) may be easy to collect yet may not accurately reflect the delay experienced by the data packets. The latter is a consequence of two facts: i) the delay measurement ICMP message uses a protocol number (e.g., 1 for ping) that is different from the protocol number of an XR traffic data packet (e.g., 17 in case data packets are sent with RTP/UDP), and this results in different 5-tuples (src addr, dst addr, src port, dst port, protocol id), and consequently different QoS treatment in the 5GS communications links; ii) the packet size of a ICMP delay measurement typically is much smaller than that of a data packet (couple of tens of bytes), resulting in different transmission delays. [0091] An alternative approach to delay measurement is represented by in-band delay measurements performed on top of the RTP/UDP stack, WebRTC stack, RTP/QUIC stack, WebRTC/ QUIC stack or alike real-time communications protocols. This utilizes in some implementations RTP header extensions, e.g., 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 delay at the receiver, or alternatively, at a network node along a network path, from the absolute sent time of an RTP packet, or alternatively, RTP packets enclosing an ADU. In another implementation, piggybacking on top of RTCP sender/receiver reports may be utilized together with RTP/RTCP multiplexing as per RFC 5761 for unicast sessions. In this case the RTP timestamps together with the RTCP sender/ report in ter- times tamps and receive times can be used to calculate an average round-trip time (RTT) and provide an estimate for the latter, for the UL, or alternatively, for the DL direction.

[0092] In case of in-band delay measurement the measurement framework requires an E2E measurement approach coupled with 5GS measurement procedure for the determination of D_e2e, D_5GS, and ultimately of the measurement of interest, i.e., D_n. This fact is due to the piggybacking strategy on top of RTP traffic originating from the application source.

[0093] 3GPP has also defined in TS 23.288 vl7.2.0 an architecture to support providing network analytics. In the architecture, the Network Data Analytics Function (NWDAF) provides analytics outputs to one or more Analytics Consumer NFs based on Data Collected from one or more Data Producer NFs. The Analytics Consumer NF may be one or more of an AF, OAM and 5G Core NFs (e.g., SMF, AMF, PCF).

[0094] Figure 9 illustrates an example wireless communication system 900. The system 900 comprises a UE 904 an NWDAF Analytics Logical Functions (ANLF) 910, a an NWDAF Model Training Logical Function (MTLF) 912, a plurality of Data Producer Network Functions, in this example am Application Function (AF) 920, a 9G Network Function 922, and an Operations, Administration and Maintenance (OAM) 924. The wireless communication system 900 further comprises a plurality of Analytics Consumer Network Functions which in this example include an Application Function 930, a 9G Network Function 932, and an OAM 934. In the current 3GPP architecture, the NWDAFs 910, 912 (defined in 3GPP Technical Specification 23.288 vl7.2.0) provide analytic output to one or more of the Analytics Consumer NFs 930, 932, and 934 based on data collected from one or more Data Producer NFs 920, 922 and 924. The analytic output may be derived by the NWDAFs 910, 912 using Analytics sharing and/or Federated Learning. The UE 904 may be embodied as a remote unit 102, a user equipment apparatus 200, or alternatively a tethered UE 1110 as described herein. The NWDAF 1 910 and NWDAF 2 912, may be embodied as a network unit 104, and a network node 300 as described herein.

[0095] A list of potential Analytics Consumer NF for each Analytics output the NWDAF provides is described in table 1 below.

Table 1: Example Analytics Consumer NFs

[0096] To support XR services and applications, the following analytics are relevant to this disclosure. Such analytics can be beneficial for mobile XR users, or for the XR service providers who need to deploy the XR service in a target area and time (e.g., for an event) and requires the statistics /predictions on the QoS/ network performance and availability.

• QoS Sustainability Analytics: Provides information regarding the QoS change statistics for an Analytics target period in the past in a certain area or the likelihood of a QoS change for an Analytics target period in the future in a certain area. • Network Performance Analytics: Provides either statistics or predictions on the gNB status information, gNB resource usage, communication performance and mobility performance in an Area of Interest.

• User Data Congestion Analytics: User Data Congestion related analytics can relate to congestion experienced while transferring user data over the control plane or user plane or both.

• DN Performance Analytics: Provides statistics or predictions on the DN performance indicators for a specific edge computing application for a UE, group of UEs over a specific serving PSA UPF, DN application identifier or EAS.

[0097] In Release 17 the framework for UE data collection and reporting framework for event exposure (EVEX) has been completed. This provides the architecture and protocols for enabling the collection of UE and AS data and exposure of associated events to NF consumers through the generic architecture and procedures described by NWDAF.

[0098] To this end, the high-level procedures by which data is collected by a NWDAF from UE application (s) via an intermediary AF as data provider are exploited. This is achieved by a Data Collection AF (DCAF) which is registered with the NRF and connected as an event provider to the NWDAF. The DCAF relies on three possible Data Collection Clients:

• a Direct Data Collection Client that operates directly on the UE endpoint and collects data relevant to the application operation and logic directly communicating with an instance of the DCAF;

• an Indirect Data Collection Client that operates within an ASP backend with whom the UE application instance communicates collected data; the Indirect Data Collection Client collects the UE application data and relays it further to a DCAF instance; and/ or

• an AS/EAS which communicates with the DCAF as part of an ASP infrastructure, or via the NEF interfaces in distributed/ separate domains deployments.

[0099] The DCAF and subsequently the Data Collection Clients may thus be provisioned by the Application Service Provider via a provisioning AF with a configuration meant to perform data collection directly from one UE or a group of UEs serving the application, or alternatively, from the AS/EAS serving application content to the one UE or the group of UEs. The configuration further comprises a Data Access Profile provisioned by the application provider. The Data Access Profile contains information about the data parameters to be collected (e.g., an Event ID), filtering metadata to apply to the collected data (e.g., location filters, time sampling restrictions, UE/application identifier filters etc.), and the reporting procedures. The Data Access profile may also define the processing to be performed by the DCAF of the collected data for generation and exposure of events to further NF, or alternatively, AF.

[0100] The DCAF is thus connected as a NF data producer, or alternatively event producer, with an NWDAF instance which is an event consumer. Further event consumers can be attached by means of the NWDAF service-based architecture. For instance, other event consumers may be other NFs, such as PCF, SMF, UPF or alike, or other AFs, like the application provider AF.

[0101] Figure 10 illustrates a generic DCAF architecture depicted in simplified format. The NRF registration and provisioning AF connections of the DCAF are left out for brevity. A wireless communication device 1035 comprises a Direct Data Collection Client (DDCC) 1036 which reports to a Data Collection Application Function (DCAF) 1022. DCAF 1022 receives UE reporting data also from an Application Server 1024 and exposes an event to both an NWDAF 1032 and an Event consumer application function 1016 in an ASP 1010. NWDAF 1032 exposes network data analytics to any network function 1042 that wishes to consume data analytics. As such, the DCAF 1022 collects data over a configured data collection session (i.e., by means of a Data Access Profile acquiring data over a RESTful APIs served over HTTPS authenticated connections) with the Direct Data Collection Client 1036 and the AS 1024, which may be an Edge AS. The collected data is processed at the DCAF 1022 to generate and expose an event which is further consumed by the NWDAF 1032 for analytics. The NWDAF 1032 in turn performs analytics on the collected events and outputs the results to other NF/AF consumers 1042.

[0102] The Direct Data Collection Client (DDCC) 1036 of figure 10 is illustrated as being located in the UE 1035. The DDCC 1036 may be located in the tethering device, or in the tethered device as described herein. Indeed, a plurality of DDCC’s 1036 may be provided. There may be a DDCC 1036 located in each of the tethering device and the tethered device as described herein.

[0103] The Data Access Profile is defined in TS 26.531 vl7.0.0 “Data Collection and Reporting; General Description and Architecture”. Various restrictions along the time, user, and location dimensions, are available. • Restrictions along time: determine granularity of access to UE data along the time axis. The finest granularity allows access to events as they take place in time (no restriction). The coarsest level of access aggregates all event data along the time axis to produce a single aggregated value given an aggregation window.

• Restrictions along users', allow the provisioning AF to restrict access to UE data related events based on groups. The finest granularity allows the event consumer to access events related to single users, or alternatively, UEs. Coarse granularity access exposes aggregated collected event data based on user groups, as defined by an application (e.g., UEs that run a certain application version). The coarsest granularity access exposes the data being aggregated for all users.

• Restrictions along location', allow the Provisioning AF to restrict access to UE data related events based on geographical location of the data collection client during the event. The finest granularity allows the event consumer to access events individually, irrespective of the location. Coarse granularity access exposes aggregated collected event data based on a geographical area. The coarsest level of access aggregates all event data along locations to produce a single aggregated value for all locations.

[0104] The baseline set of aggregation filters for the DCAF is defined currently in 3GPP TS 26.532 vl7.1.0 “Data Collection and Reporting. Protocols and Formats”, in particular at Table 4.5.2-1. The baseline DCAF aggregation filters based on reporting period is thus as follows:

• None: no aggregation applied, all reported data records are exposed as individual events.

• Count, number of reported data records is exposed to event consumers

• Mean: mean average of the values in reported data records is exposed to event consumers.

• Maximum: maximal observed value in reported data records is exposed to event consumers.

• Minimum: minimal observed value in reported data records is exposed to event consumers.

• Sum: sum of the values in reported data records is exposed to event consumers. [0105] There is presented herein a solution whereby the NWDAF uses data collected by an AF in respect of a tethered link delay (illustrated as D_{n l} in Figure 8) and UPF to Application Server delay (illustrated as D_{n 2} in Figure 8) for enhancing the DN Performance Analytics. To determine the non-3GPP delay and characterize the performance of application serviced delivered (at least in part) via tethered UE links, a calculation of D_n may be required.

[0106] Figure 11 illustrates a system 1100 in which a UE 1135 reports a tethered delay. The system 1100 comprises a UE 1135, which operates as a tethering UE and which is tethered to a tethered UE 1131, and an XR application 1132 running on at least one of the UE 1135 and the tethered UE 1131. The system 1100 further comprises an application server 1114, an application function 1112, a user plane function (UPF) 1140, and a radio access network (RAN) 1130. The UE 1135 includes a 3GPP modem for communicating with the RAN 1130.

[0107] A client in the UE 1135 is able to measure the tethered link delay when a tethered device 1131 is using an XR application 1132 and establishes a connection to an Application server 1114 via the 3GPP network 1130, 1140. In an alternative arrangement, the Tethered UE device 1131 measures the tethered link delay and a client in the tethered UE 1131 reports the tethered link delay.

[0108] The UPF 1140 or AF 1112 measure the delay between the UPF 1140 and AF 1112, which may be termed the N6 link delay. The AF 1112 is able to collect measurements of the “N6 link delay”. In an alternative arrangement the UPF is able to report N6 link delays directly to a data collection function in the 3GPP network (either a DCCF or an NWDAF). For both scenarios a client in the UPF 1140 or AF 1112 is arranged to measure the DN link delay. The DN link delay may be measured in a number of ways, two example methods are as follows.

[0109] In a first example of measuring the DN link delay, a segment-by-segment link delay measurement is used, wherein D_n = D_{n l} + D_{n 2}. Yet in this case D_{n l} (latency between tethered device and 5G device) and D_{n 2} (latency between EAS/AS and PSA UPF) is measured by different network nodes, the former at the tethered UE endpoint, and the latter at the EAS/AS endpoint, or alternatively, in some implementations by the UPF itself.

[0110] In a second example of measuring the DN link delay, an end-to-end (E2E) measurement is used, whereby D_n = D_e2e — D_c. In this case the measurement of D_e2e can be one sided, i.e., at the tethered UE only, at the AS/EAS only, or at dual-sided, i.e., at both tethered UE and AS/EAS. On the other hand, D_c measurement is intrinsic to the core network and can be determined on a per QoS flow per UE QoS monitoring or a per user plane QoS monitoring on top of GTP-U Echo protocol.

[0111] Per QoS flow per UE QoS monitoring is described in the QoS monitoring clause of TS 23.501 (vl7.5.0), and operates by piggybacking timestamps for measurement within GTP-U headers, whereby the SMF, or alternatively, an AF (e.g., in one example the DCAF) can request the PSA UPF to perform QoS monitoring, i.e., the UE to PSA UPF delay, for a specific QoS flow.

[0112] According to per user plane QoS monitoring on top of GTP-U Echo protocol, the UPF determines at the request of SMF, or alternatively, an AF (e.g., in one example the DCAF) the expected UE to UPF delay.

[0113] The NWDAF is triggered to provide analytics for the tethered link and/ or the DN delay based on a trigger from analytics consumer. In the analytics request a consumer can include additionally within analytic filter information to provide analytics for tethered link latency and/ or DN link latency.

[0114] In one example, the consumer includes in the analytics request the application ID of the XR application with the knowledge that this XR application is also used by the tethered device. An analytics consumer can be an AF.

[0115] When an analytics consumer requests DN Performance Analytics including analytics for tethered link delay and/ or DN link delay, the consumer may include as analytics filters in the analytics request analytics subset that can be used in “list of analytics subsets that are requested”. The list includes tethered link delay and/ or DN link delay as analytics subsets.

[0116] Based on the analytics request the NWDAF determines to collect data from the DCAF to obtain measurements (statistics or data) of tethered link/DN link delay.

[0117] The NWDAF may be a consumer of the DCAF (i.e., an instantiation of an AF) for tethered applications such that experienced latency events exposed. The experienced latency events exposed may comprise the tethered link latency (e.g., tethering link of an XR tethered UE, i.e., between XR glasses to a 5G device) and the DN link latency for an application, or alternatively, an edge computing application. In such an arrangement, the application specific non-3GPP latency is generated by means of the DCAF either for a UE, or a group of UEs (e.g., UEs that have the same application version) or all UEs.

[0118] The NWDAF may consume at least one of the DCAF exposed tethered applications experienced latency Event IDs, i.e., E2eDelayExperience, TetheredLinkDelayExperience, DnDelayExperience. As a result, the NWDAF may have access to the following novel inputs based on the event containers exposed by the

DCAF:

• the D_e2e given the E2eDelayExperience,

• the D_{n l} given the TetheredLinkDelayExperience, and respectively, • the D_n 2 given the DnDelayExperience.

[0119] The above information of the EventIDs may represent application characteristic delay metrics and parameters associated with representative network segments serving the respective application, i.e., the tethered link (as fronthaul link), the 5GS link (as the backhaul) and the DN link to the application specific AS and/ or EAS. This information may be associated with additional information received from the DCAF (i.e., an instantiation of an AF) and may be associated with the NWDAF analytics ID “DN Performance” representing additional inputs available for the 5GS DN performance analytics for UL/DL Performance Data, as illustrated in Table 2 below.

Table 2: Inputs available for the 5GS DN performance analytics

[0120] In the offered example the UL/DL Performance Data novel metrics map as follow to the DCAF exposed events: • Average /Maximum Packet Delay is mapped to the DCAF EventID E2eDelayExperience exposure with average or maximum Data Access Profile event aggregation filters. The E2E measurement strategy is left to the ASP provisioning AF decision and as such can be based on the delay upper bound given by out-of-band ICMP procedures or on the more accurate RTP/RTCP piggybacking approaches, or equivalently, other similar transport application layer protocols where applicable.

• Average/Maximum Tethered UE Link Delay is mapped to the DCAF EventID TetheredLinkDelayExperience exposure with average or maximum Data Access Profile event aggregation filters.

• Average/Maximum DN Link Delay is mapped to the DCAF EventID DnDelayExperience exposure with average or maximum Data Access Profile event aggregation filters.

[0121] The DN Performance Analytics may provide at least one or more of the following pieces of information: user plane performance analytics for a specific application/ edge computing application for a tethering UE/tethered UE, group of tethering UEs /group of tethered UEs, or any tethering UE/ any tethered UE over a specific serving anchor UPF; user plane performance analytics for a specific application/ edge computing application for a tethering UE/tethered UE, group of tethering UEs /group of tethered UEs, or any tethering UE/ any tethered UE over a specific DN Access Identifier (DNAI); user plane performance analytics for a specific application/ edge computing application for a tethering UE/tethered UE, group of tethering UEs /group of tethered UEs, or any tethering UE/ any tethered UE over a specific AS/EAS instance; and/ or user plane performance analytics for an XR application when the XR application is run from a tethered device for a tethering UE, group of tethering UEs or any UE over a specific DNAI or AS/EAS instance.

[0122] The service consumer of the DN Performance Analytics may be a NF (e.g., a PCF). Alternatively, the service consumer of the DN Performance Analytics may be an AF (e.g., an XR ASP AF, an XRM AF, or equivalent). [0123] For example, table 3 illustrates some examples of the output analytics that a 5GS consumer of NWDAF DN Performance Analytics may subscribe to. The output analytics (i.e., NWDAF statistics, or alternatively, NWDAF predictions) may be based on subscription preferences of the 5GS consumer indicated as per Hnwdarf_yInayl ticsSubscnption_Subscribe(Anayl tics ID — DN Performance).

Table 3: Output analytics available for subscription [0124] Figure 12 illustrates a method 1200 whereby an analytics consumer (i.e., a NF, or alternatively, a AF) requests Analytics ID “DN Performance” procedure, subscribing for the DN Performance data analytics of a specific tethered application, e.g., an XR application, or alike. The consumer indicates the target of Analytics Reporting and may include as an Analytic Filter Information based on one of an UPF anchor ID, a DNAI, or AS/EAS instance that DN performance analytics are requested for. The analytics consumer may identify the UEs that offer tethering connection and include in the request as target of event reporting the UE identifiers offering a tethering connection. The method 1200 is performed by an analytics consumer 1242, an NWDAF 1232, a Network Exposure Function (NEF) 1252 a DCAF 1222 (which may comprise a function within a tethered UE) and a network function (NF) 1256.

[0125] At 1271, the analytics consumer 1242 (e.g., the PCF as an NF, or alternatively an XRM AF) sends an analytics request /subscribe (Analytics ID = DN Performance Target of Analytics Reporting, Analytics Filter Information = (Application ID, S-NSSAI, DNN, Area of Interest, UPF anchor ID, DNAI, Application Server Address (es)), Target of Event Reporting = Any UE, Group UE identifier or specific UE identifier fiaxAfazs Reporting Information = Analytics target period) to NWDAF by invoking a Anwdaf_Anayl ticsInfo_Request or an Anwdaf_Anayl ticsSubscription_Subscribe service. The analytics request may include analytics subset requesting analytics for tethered link and/ or DN link delay.

[0126] At 1272a, the NWDAF 1232 subscribes to the performance data from DCAF 1222 serving the tethered application by invoking Naf_EventExposure_Subscribe (or alternatively, if the DCAF 1222 is not in a trusted domain, the Nnef_EventExposure_Subscribe via the NEF 1252) service as (Event ID = Performance Data, Application ID , Event Titter information), Target of Event Reporting — Any UE, Group UE identifier or specific UE identifier) to subscribe to Performance Data events from tethering UEs. The DCAF 1222 may discover at least one data collection client located in the tethering UE or tethered UE using at least one UE identifier provided in the analytics request.

[0127] At 1272b, the NWDAF 1232 subscribes to the network data (i.e., that may be additionally collected from the SMF, OAM, or UPF) by invoking Nnf_EventExposure_Subscribe service.

[0128] At 1272c, with the collected data, the NWDAF 1232 processes the DN Performance analytics for the application. [0129] At 1273, the NWDAF 1232 provides the data analytics, to the analytics consumer 1242 by means of either ddnwdaf_Anayl ticsInfo_^equest response or l^nwdaf_Anayl ticsSubsmptionJNotify, depending on the service used in step 1271.

[0130] Accordingly, there is provided a first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network. The first network node comprises a processor; and a memory coupled with the processor. The processor is configured to cause the first network node to: receive a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determine to collect data for the tethered connection from a data collection application function based on the first indication; send a second request to the data collection application function to retrieve measurements for the tethered connection; derive performance analytics for the tethered connection; and send the derived performance analytics in response to the first request.

[0131] A first network node may thus derive performance analytics that include the performance of a tethered connection. Such performance analytics are required to properly understand the end-to-end quality of service. One measure of the end-to-end quality of service may comprise an end-to-end latency.

[0132] The first network node may comprise a network analytics function. The first network node may be an NWDAF. The data collection application function may be included in a wireless communication device that operates as a tethering device for the tethered connection. The wireless communication network may comprise a 3GPP network. The wireless communication device ay be a 3GPP device. The measurements for the tethered connection may be retrieved from the wireless communication device that operates as a tethering device for the tethered connection.

[0133] The first indication to provide analytics for a tethered connection may include an indication to provide analytics in respect of a link delay. The tethered connection for the application may comprise a tethered link delay or DN link delay. The performance analytics for the tethered link connection may comprise a delay or DN link delay. The performance analytics of a delay may comprise either an average delay or a maximum delay.

[0134] The application session may include communication between a wireless communication device and an application server. The application session may comprise a plurality of links which are communicated by a plurality of access technologies. The wireless communication device may comprise a tethered device and a tethering device. The tethering device may be arranged to communicate with the tethered device via the at least one tethered connection. The tethered connection may comprise a connection using Wi-Fi or Bluetooth, for example. The tethering device may comprise a modem for connecting to the wireless communication network.

[0135] The first indication may be included as an analytic subset in the first request. The performance analytics for the tethered connection may include a link delay. The data collection application function obtains measurements from a data collection client in the tethered device.

[0136] The data collection application function may obtain measurements from a data collection client in the tethering device. The link delay may comprise an average link delay and/ or a maximum link delay.

[0137] The analytics request may comprise at least one of: an analytics identity; at least one target UE identity; at least one application identity; a period of time for which measurements should be collected; a definition of an area for which measurements should be collected; the required confidence level of any derived performance analytics; and an exposure level for providing analytics related to the tethered connection. The target UE identity may include the identity of a tethered device and/ or a tethering device. The derived performance analytics may comprise at least one prediction.

[0138] The measurements may be performed by a data collection application client located at the tethering device, and wherein the target UE identity identifies the tethering device. Alternatively, the measurements may be performed by a data collection client in the tethered device, and the target UE identity identifies the tethering device, and wherein the data collection application function uses the target UE identity of the tethering device to discover the data collection client in the tethered device.

[0139] The performance analytics for the tethered connection may comprise at least one of: an average Tethered UE Link Delay; and/ or a maximum Tethered UE Link Delay.

[0140] The first request may additionally include a second indication to provide performance analytics for a connection between the application server and a user plane function of the wireless communication network. Then the processor may be further configured to cause the first network node first network node to: collect data from one or more network functions based on the second indication; determine an application function arranged to provide measurements for performance analytics between the user plane function and the application server; send a third request to an application function to retrieve measurements for the performance analytics; wherein the performance analytics are derived for both the tethered connection and the connection between the application server and the user plane function of the wireless communication network. [0141] The data network connection may comprise an N6 connection. The performance analytics for the connection between the application server and the UPF may comprise a measure of packet delay. The application function arranged to provide measurements for performance analytics between the user plane function and the application server may be the user plane function.

[0142] Measurements of performance analytics may be collected by a user plane function. The performance analytics for the data network connection may comprise at least one of: an average data network Link Delay; and/ or a maximum data network Link Delay.

[0143] Figure 13 illustrates a method 1300 performed by a first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network. The method 1300 comprises: receiving 1310 a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determining 1320 to collect data for the tethered connection from a data collection application function based on the first indication; sending 1330 a second request to the data collection application function to retrieve measurements for the tethered connection; deriving 1340 performance analytics for the tethered connection; and sending 1350 the derived performance analytics in response to the first request.

[0144] In certain embodiments, the method 1300 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like. [0145] A first network node may thus derive performance analytics that include the performance of a tethered connection. Such performance analytics are required to properly understand the end-to-end quality of service. One measure of the end-to-end quality of service may comprise an end-to-end latency.

[0146] The first network node may comprise a network analytics function. The first network node may be an NWDAF. The data collection application function may be included in a wireless communication device that operates as a tethering device for the tethered connection. The wireless communication network may comprise a 3GPP network. The wireless communication device ay be a 3GPP device. The measurements for the tethered connection may be retrieved from the wireless communication device that operates as a tethering device for the tethered connection.

[0147] The first indication to provide analytics for a tethered connection may include an indication to provide analytics in respect of a link delay. The tethered connection for the application may comprise a tethered link delay or DN link delay. The performance analytics for the tethered link connection may comprise a delay or DN link delay. The performance analytics of a delay may comprise either an average delay or a maximum delay.

[0148] The application session may include communication between a wireless communication device and an application server. The application session may comprise a plurality of links which are communicated by a plurality of access technologies. The wireless communication device may comprise a tethered device and a tethering device. The tethering device may be arranged to communicate with the tethered device via the at least one tethered connection. The tethered connection may comprise a connection using Wi-Fi or Bluetooth, for example. The tethering device may comprise a modem for connecting to the wireless communication network.

[0149] The first indication may be included as an analytic subset in the first request. The performance analytics for the tethered connection may include a link delay. The data collection application function obtains measurements from a data collection client in the tethered device. The data collection application function may obtain measurements from a data collection client in the tethering device. The link delay may comprise an average link delay and/ or a maximum link delay.

[0150] The analytics request may comprise at least one of: an analytics identity; at least one target UE identity; at least one application identity; a period of time for which measurements should be collected; a definition of an area for which measurements should be collected; the required confidence level of any derived performance analytics; and an exposure level for providing analytics related to the tethered connection. The target UE identity may include the identity of a tethered device and/ or a tethering device. The derived performance analytics may comprise at least one prediction.

[0151] The measurements may be performed by a data collection application client located at the tethering device, and wherein the target UE identity identifies the tethering device. Alternatively, the measurements may be performed by a data collection client in the tethered device, and the target UE identity identifies the tethering device, and wherein the data collection application function uses the target UE identity of the tethering device to discover the data collection client in the tethered device.

[0152] The performance analytics for the tethered connection may comprise at least one of: an average Tethered UE Link Delay; and/ or a maximum Tethered UE Link Delay.

[0153] Figure 14 illustrates a method 1400 that may be performed in addition to method 1300 of figure 13. In the method 1400 of figure 14, the first request additionally includes a second indication to provide performance analytics for a connection between the application server and a user plane function of the wireless communication network. Then the method 1400 comprises collecting 1410 data from one or more network functions based on the second indication; determining 1420 an application function arranged to provide measurements for performance analytics between the user plane function and the application server; sending 1430 a third request to an application function to retrieve measurements for the performance analytics; wherein the performance analytics are derived for both the tethered connection and the connection between the application server and the user plane function of the wireless communication network.

[0154] In certain embodiments, the method 1400 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0155] The data network connection may comprise an N6 connection. The performance analytics for the connection between the application server and the UPF may comprise a measure of packet delay. The application function arranged to provide measurements for performance analytics between the user plane function and the application server may be the user plane function.

[0156] Measurements of performance analytics may be collected by a user plane function. The performance analytics for the data network connection may comprise at least one of: an average data network Link Delay; and/ or a maximum data network Link Delay.

[0157] There is provided herein a method for the consumption of collected delay metrics events of applications experienced over tethered UEs, whereby the events are consumed by the NWDAF for the DN performance analytics output of new information parameters. These new parameters may include the average/max delay of tethered link (between 5G device and tethered device, e.g., XR glasses), average/max delay of DN link (between PSA UPF and AS/EAS), or average/max delay of E2E link available, and can be consumed by any NF/AF consumer.

[0158] There is further provided a method at a network analytics function, the method comprising: receiving a request to provide performance analytics identified by an analytic identifier for an application in a 3GPP device that has established a connection to an application server via a 3GPP user plane connection wherein the first request include a first indication to provide analytics for tethered link or DN link delay; collecting data from one or more network functions based on the analytic identifier; determining to collect data from the DCAF based on the first indication; sending a second request to an Application Function to retrieve measurements of tethered link delay or DN link delay for an application; deriving additional analytics for tethered link delay or DN link delay (average or max delay); and responding with performance analytics.

[0159] The first indication may be included as an analytic subset in the request. The additional analytics for the tethered link delay may include average link delay and maximum link delay. The analytics request may include a target UE, a group of UEs, or indicate any UE. The analytics request may target a specific area of interest.

[0160] It should be noted that the above-mentioned methods and apparatus illustrate rather than limit the invention, and that 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 elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

[0161] Further, while examples have been given in the context of particular communication standards, these examples are not intended to be the limit of the communication standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of 3GPP, the principles disclosed herein can also be applied to another wireless communication system, and indeed any communication system which uses routing rules.

[0162] The method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods.

[0163] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0164] The following abbreviations are relevant in the field addressed by this document: 3GPP, 3rd generation partnership project; 5G, fifth generation; 5GS, 5G System; 5QI, 5G QoS Identifier; A-ADRF, application layer analytics data repository function;

ADAEC, application data analytics enablement client; AD AES, application data analytics enablement 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 UPF; 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 assessment function; VPS, video parameter set; VR , virtual reality; XR, extended reality; XR AS, XR application server; and XRM, XR media.

Claims

1. A first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network, the first network node comprising: a processor; and a memory coupled with the processor, the processor configured to cause the first network node to: receive a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determine to collect data for the tethered connection from a data collection application function based on the first indication; send a second request to the data collection application function to retrieve measurements for the tethered connection; derive performance analytics for the tethered connection; and send the derived performance analytics in response to the first request.

2. The first network node of claim 1, wherein the first indication is included as an analytic subset in the first request.

3. The first network node of claim 1 or 2, wherein the performance analytics for the tethered connection include a link delay.

4. The first network node of any preceding claim, wherein the data collection application function obtains measurements from a data collection client in the tethered device.

5. The first network node of any preceding claim, wherein the data collection application function obtain measurement from a data collection client in the tethering device.

6. The first network node of any preceding claim, wherein the analytics request comprises at least one of: an analytics identity; at least one target UE identity; at least one application identity; a period of time for which measurements should be collected; a definition of an area for which measurements should be collected; the required confidence level of any derived performance analytics; and an exposure level for providing analytics related to the tethered connection.

7. The first network node of claim 6, wherein the measurements are performed by a data collection application client located at the tethering device, and wherein the target UE identity identifies the tethering device.

8. The first network node of claim 6, wherein the measurements are performed by a data collection client in the tethered device, and the target UE identity identifies the tethering device, and wherein the data collection application function uses the target UE identity of the tethering device to discover the data collection client in the tethered device.

9. The first network node of any preceding claim, wherein the performance analytics for the tethered connection comprise at least one of: an average Tethered UE Link Delay; and/ or a maximum Tethered UE Link Delay.

10. The first network node of any preceding claim, wherein the first request additionally includes a second indication to provide performance analytics for a connection between the application server and a user plane function of the wireless communication network, the processor further configured to cause the first network node first network node to: collect data from one or more network functions based on the second indication; determine an application function arranged to provide measurements for performance analytics between the user plane function and the application server; send a third request to an application function to retrieve measurements for the performance analytics; wherein the performance analytics are derived for both the tethered connection and the connection between the application server and the user plane function of the wireless communication network.

11. The first network node of any preceding claim, where measurements of performance analytics are collected by a user plane function.

12. The first network node of claim 10, wherein the performance analytics for the data network connection comprise at least one of: an average data network Link Delay; and/ or a maximum data network Link Delay.

13. A method performed by a first network node of a wireless communication network for enabling performance analytics of a tethered connection between a tethered device and a tethering device, wherein an application session comprises an end-to-end communication session between the tethered device and an application server, and wherein the end-to-end communication session includes the tethered connection and a connection via the wireless communication network, the method comprising: receiving a first request to provide performance analytics identified by an analytic identifier for the application session wherein the first request includes a first indication to provide analytics for the tethered connection; determining to collect data for the tethered connection from a data collection application function based on the first indication; sending a second request to the data collection application function to retrieve measurements for the tethered connection; deriving performance analytics for the tethered connection; and sending the derived performance analytics in response to the first request.

14. The method of claim 13, wherein the first indication is included as an analytic subset in the first request.

15. The method of claim 13 or 14, wherein the performance analytics for the tethered connection include a link delay.

16. The method of any of claims 13, 14 or 15, wherein the data collection application function obtains measurements from a data collection client in the tethered device.

17. The method of any of claims 13 to 16, wherein the data collection application function obtain measurement from a data collection client in the tethering device.

18. The method of any of claims 13 to 17, wherein the analytics request comprises at least one of: an analytics identity; at least one target UE identity; at least one application identity; a period of time for which measurements should be collected; a definition of an area for which measurements should be collected; the required confidence level of any derived performance analytics; and an exposure level for providing analytics related to the tethered connection.

19. The method of claim 18, wherein the measurements are performed by a data collection application client located at the tethering device, and wherein the target UE identity identifies the tethering device.

20. The method of claim 18, wherein the measurements are performed by a data collection client in the tethered device, and the target UE identity identifies the tethering device, and wherein the data collection application function uses the target UE identity of the tethering device to discover the data collection client in the tethered device.

21. The method of any of claims 13 to 20, wherein the performance analytics for the tethered connection comprise at least one of: an average Tethered UE Link Delay; and/ or a maximum Tethered UE Link Delay.

11. The method of any of claims 13 to 21, wherein the first request additionally includes a second indication to provide performance analytics for a connection between the application server and a user plane function of the wireless communication network, the method further comprising: collecting data from one or more network functions based on the second indication; determining an application function arranged to provide measurements for performance analytics between the user plane function and the application server; sending a third request to an application function to retrieve measurements for the performance analytics; wherein the performance analytics are derived for both the tethered connection and the connection between the application server and the user plane function of the wireless communication network.

23. The method of any of claims 13 to 22, where measurements of performance analytics are collected by a user plane function.

24. The method of claim 22, wherein the performance analytics for the data network connection comprise at least one of: an average data network Link Delay; and/ or a maximum data network Link Delay.