Enabling performance analysis of tethering connections within wireless communication networks.

Abstract

A method is provided, executed by a first network node, for enabling performance analysis of a tethered connection, wherein the application session comprises an end-to-end communication session, and the end-to-end communication session comprises a tethered connection. The method comprises receiving a requirement for performance analysis for the application session, identifying at least one device to act as a data collection entity for collecting data required for the performance analysis, and sending the data collection requirement to the identified data collection entity, wherein the data collection requirement includes a request for performance data relating to at least one tethered connection within the application session. The method further comprises receiving performance data measured in accordance with the data collection requirement from the data collection entity, deriving a performance analysis based on the performance data and the data collection requirement, and sending the derived performance analysis.

Description

[Technical Field]

[0001] The subject matter disclosed herein generally relates to the field of enabling performance analysis of tethering connections in wireless communication networks. This specification defines a first network node, a method in the first network node, a second network node, a method in the second network node, a third network node, and a method in the third network node. [Background technology]

[0002] In many interactive and immersive applications with demanding requirements for latency, rate, and reliability, the application experience is served via a tethered connection, thereby connecting a destination Personal IoT Network Element (PINE) device to a gateway device, which in turn connects to a 3GPP access network ("3GPP" is a registered trademark) (e.g., 4G, 5G, or similar) for internet connectivity. An example of such application experience delivery includes, for instance, an AR / VR experience, where the PINE is a head-mounted device (HMD) in the form of AR / VR glasses, and the gateway is a mobile phone or, alternatively, a 3GPP user device (UE). Thus, end-to-end connectivity between the client and the application server relies on at least three heterogeneous network segments: a tethered link, 3GPP connectivity, and a data network (DN) link. The tethered link and DN link are outside the scope of 3GPP. Tethering connections between PINE and gateways typically rely on Wi-Fi, Bluetooth, or unlicensed spectral radio access technologies. Such connections impact E2E QoS, and in effect, both tethering links and DN links contribute to reducing the effectiveness of QoS rules and policies adopted within 3GPP networks. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] TR26.926(v1.1.0), “Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems” [Non-Patent Document 2] TS26.531 v17.0.0, “Data Collection and Reporting; General Description and Architecture” [Non-Patent Document 3] 3GPP TS26.532 v17.1.0, “Data Collection and Reporting.Protocols and Formats” [Non-Patent Document 4] 3GPP TS23.436 v0.3.0, “Procedures for Application Data Analytics Enablement Service” [Overview of the project] [Problems that the invention aims to solve]

[0004] Therefore, it is beneficial for 3GPP networks to monitor and incorporate link metrics regarding the performance of out-of-range network segments (e.g., tether links, DN links) traversing heterogeneous E2E network paths. 3GPP networks can also perform analyses of such link metrics and derive statistical characteristics of expected performance. Furthermore, such 3GPP networks can adapt 3GPP QoS rules and policies, compensate for the degradation effects of out-of-range network segments (e.g., additional latency), and seamlessly meet E2E application requirements for an enhanced user experience. [Means for solving the problem]

[0005] A procedure for enabling performance analysis of tethering connections within a wireless communication network is disclosed herein. The procedure may be performed by a first network node, a method at the first network node, a second network node, a method at the second network node, a third network node, and a method at the third network node.

[0006] Therefore, a first network node is provided for enabling performance analysis of tethered connections, and the application session comprises an end-to-end communication session, the end-to-end communication session includes a tethered connection. The first network node comprises a processor and memory coupled to the processor, and the processor is configured to cause the first network node to receive requirements for performance analysis of the application session, identify at least one device to act as a data collection entity for collecting data required for performance analysis, and send the data collection requirements to the identified data collection entity, wherein the data collection requirements include a request for performance data relating to at least one tethered connection within the application session. The processor is further configured to cause the first network node to receive performance data measured in accordance with the data collection requirements from the data collection entity, derive a performance analysis based on the performance data and the data collection requirements, and send the derived performance analysis.

[0007] A method is further provided, performed by a first network node, for enabling performance analysis of a tethered connection, wherein the application session comprises an end-to-end communication session, and the end-to-end communication session comprises a tethered connection. The method comprises receiving a requirement for performance analysis for the application session, identifying at least one device to act as a data collection entity for collecting data required for the performance analysis, and sending the data collection requirement to the identified data collection entity, wherein the data collection requirement includes a request for performance data relating to at least one tethered connection within the application session. The method further comprises receiving performance data measured in accordance with the data collection requirement from the data collection entity, deriving a performance analysis based on the performance data and the data collection requirement, and sending the derived performance analysis.

[0008] A second network node is further provided to enable performance analysis of tethered connections, and the application session includes an end-to-end communication session, the end-to-end communication session including a tethered connection. The second network node comprises a processor and memory coupled to the processor. The processor is configured to cause the second network node to receive data collection requirements from the first network node, determine at least one data source based on the data collection requirements, collect performance data from at least one data source based on the data collection requirements, and send the collected performance data to the first network node.

[0009] A method is further provided, executed by a second network node, for enabling performance analysis of a tethered connection, wherein the application session comprises an end-to-end communication session, and the end-to-end communication session includes a tethered connection. The method comprises receiving a data collection requirement from a first network node, determining at least one data source based on the data collection requirement, collecting performance data from at least one data source based on the data collection requirement, and sending the collected performance data to the first network node.

[0010] A third network node is further provided for enabling performance analysis of tethered connections within an application session, the application session including communication via at least one tethered connection. The third network node comprises a processor and memory coupled to the processor. The processor is configured to cause the third network node to send requirements for performance analysis of the application session to the first network node, the requirements for performance analysis including a request for performance data relating to at least one tethered connection within the application session, and to receive the performance analysis from the first network node.

[0011] A method is also provided for enabling performance analysis of tethered connections within an application session, which is performed by a third network node, wherein the application session includes communication over at least one tethered connection. The method comprises sending a requirement for performance analysis for the application session to a first network node, wherein the requirement for performance analysis includes a request for performance data relating to at least one tethered connection within the application session, and receiving the performance analysis from the first network node.

[0012] To describe the manner in which the advantages and features of the present disclosure can be obtained, the description of the present disclosure is presented by reference to several apparatuses and methods shown in the accompanying drawings. Each of these drawings merely shows some aspects of the present disclosure and should not be regarded as a limitation of its scope. The drawings may be simplified for clarity and are not necessarily drawn to scale.

[0013] A method and apparatus for enabling a performance analysis of a tethering-type connection in a wireless communication network are hereinafter described merely as an example while referring to the accompanying drawings.

Brief Description of the Drawings

[0014] [Figure 1] FIG. is a diagram showing a wireless communication system for enabling a performance analysis of a tethering-type connection in a wireless communication network. [Figure 2] FIG. is a diagram showing a user equipment apparatus that can be used to implement the method described herein. [Figure 3] FIG. is a diagram showing further details of a network node that can be used to implement the method described herein. [Figure 4] FIG. is a diagram showing an overview of a core network XRM architecture for processing data packets. [Figure 5] FIG. is a diagram showing an implementation form of a first tethering technique as a tethering-type stand-alone glass. [Figure 6] FIG. is a diagram showing an implementation form of an AR glass in which an XR tethering-type link exposes an XR runtime as an XR runtime API to a 5G device. [Figure 7] FIG. is a diagram showing an implementation form of an AR glass in which the exposure of an XR runtime via a tethering link as a media buffer source and sink is supported by a virtualized edge network XR runtime instance. [Figure 8] FIG. is a diagram showing an E2E path delay and subsequent path delays. [Figure 9] This is a diagram illustrating an exemplary wireless communication system. [Figure 10] This figure shows a comprehensive DCAF architecture in a simplified format. [Figure 11] This diagram shows the architecture for enabling application data analysis in cases where roaming is not performed. [Figure 12] This figure shows a comprehensive functional model for ADAE when reusing 3GPP network data analysis models. [Figure 13] This diagram shows an architecture where VAL clients exist in different, non-networked UEs that require analysis for the ADAE-C interface. [Figure 14] This diagram shows the tethering-type VAL connectivity performance analysis procedure. [Figure 15] This figure shows how a first network node can perform performance analysis on a tethered connection where the application session has an end-to-end communication session. [Figure 16] This diagram shows how a second network node can perform performance analysis on a tethered connection where the application session has an end-to-end communication session. [Figure 17] This diagram shows how a third network node can perform performance analysis of tethered connections within an application session. [Modes for carrying out the invention]

[0015] As will be understood by those skilled in the art, aspects of this disclosure may be embodied as systems, apparatus, methods, or program products. Accordingly, the configurations described herein may be implemented entirely in hardware form, entirely in software form (including firmware, resident software, microcode, etc.), or in a combination of software and hardware forms.

[0016] For example, the disclosed methods and apparatus may be implemented as hardware circuits comprising custom very large-scale integrated circuits ("VLSI") or commercially available semiconductors such as gate arrays, logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented as programmable hardware devices such as field-programmable gate arrays, programmable array logic, or programmable logic devices. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code, which may be organized as objects, procedures, or functions, for example.

[0017] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-temporary, and / or non-transmitting. The storage devices may not embody signals. In some configurations, the storage devices merely employ signals for accessing the code.

[0018] Any combination of one or more computer-readable media may be used. The computer-readable media may be computer-readable storage media. The computer-readable storage media may be a storage device that stores code. The storage device may be, for example, but not limited to, a system, apparatus, or device of electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor, or any suitable combination thereof.

[0019] More specific examples (a non-exclusive list) of storage devices include, namely, electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM") or flash memory, portable compact disk read-only memory ("CD-ROM"), optical storage devices, magnetic storage devices, or any preferred combination of the foregoing. In the context of this specification, a computer-readable storage medium may be any tangible medium capable of storing or storing programs for use by or related to an instruction execution system, apparatus, or device.

[0020] Any reference throughout this Specimen to an example of a particular method or apparatus, or similar language, means that the particular feature, structure, or characteristic described in relation to that example is included in at least one implementation of the methods and apparatus described herein. Thus, all references to an example of a particular method or apparatus, or similar language, mean "one or more, but not all, examples," unless otherwise specified, although they may refer to the same example, not necessarily. The terms "including," "comprising," and "having," and their variations, mean "including, but not limited to," unless otherwise specified. The enumerated listing of items does not imply that any or all of the items are mutually exclusive unless otherwise specified. The terms "a," "an," and "the" also mean "one or more," unless otherwise specified.

[0021] As used herein, a list containing the conjunction "and / or" includes any single item in the list or any combination of items in the list. For example, the list A, B, and / or C includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of" includes any single item in the list or any combination of items in the list. For example, one or more of A, B, and C includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of" includes one unique single item from any single item in the list. For example, "one of A, B, and C" includes A only, B only, or C only, excluding the combination of A, B, and C. When used herein, “members selected from the group consisting of A, B, and C” includes one unique individual of A, B, or C, and excludes any combination of A, B, and C. When used herein, “members selected from the group consisting of A, B, and C, and any combination thereof” includes A only, B only, C only, 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.

[0022] Furthermore, the features, structures, or properties described herein may be combined in any preferred manner. The following description provides numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, and hardware chips, in order to provide a full understanding of the disclosure. However, those skilled in the art will recognize that the disclosed methods and apparatus may be practiced without one or more of the specific details, or in conjunction with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not illustrated or described in detail, in order to avoid obscuring aspects of the disclosure.

[0023] The methods and apparatuses disclosed are described below with reference to schematic flowcharts and / or schematic block diagrams of the methods, apparatuses, systems, and program products. It will be understood that each block in the schematic flowcharts and / or schematic block diagrams, as well as combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to produce a machine such that instructions executed via the processor of the computer or other programmable data processing device create means for performing the functions / actions specified in the schematic flowcharts and / or schematic block diagrams.

[0024] The code may also be stored in a memory device that can guide a computer, other programmable data processing device, or other device to function in a particular way, such that the instructions stored in the memory device produce a product containing instructions that perform functions / actions specified in a schematic flowchart and / or schematic block diagram.

[0025] Code may also be loaded onto a computer, other programmable data processing device, or other device to produce a process executed by a computer, other programmable device, or other device, by having the computer perform a series of operational steps such that the code to be executed on the computer or other programmable device provides a process for performing a function / action specified in a schematic flowchart and / or schematic block diagram.

[0026] The schematic flowcharts and / or schematic block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of the device, system, method, and program product. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or portion of code containing one or more executable instructions of code for performing a specified logical function.

[0027] It should also be noted that in some alternative implementations, the functions mentioned within a block may be performed in a different order than those mentioned in the drawing. For example, two blocks shown consecutively may actually be executed substantially in parallel, or blocks may sometimes be executed in reverse order depending on the functionality involved. Other steps and methods that are equivalent in function, logic, or effect to one or more blocks or parts thereof in the illustrated drawing may be devised.

[0028] The descriptions of elements in each drawing may refer to elements in preceding drawings. Similar numbers refer to the same elements in all drawings.

[0029] Figure 1 shows one embodiment of a wireless communication system 100 for enabling performance analysis of tethering connections in a wireless communication network. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although a specific number of remote units 102 and network units 104 are shown in Figure 1, those skilled 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.

[0030] In one embodiment, the remote unit 102 may include computing devices such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smartphones, smart televisions (e.g., internet-connected televisions), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), aerial vehicles, and drones. In some embodiments, the remote unit 102 includes wearable devices such as smartwatches, fitness bands, and optical head-mounted displays. Furthermore, the remote unit 102 may be referred to as a subscriber unit, mobile, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or by other terms used in the art. The remote unit 102 may communicate directly with one or more of the network units 104 via UL communication signals. In some embodiments, the remote unit 102 may communicate directly with other remote units 102 via side-link communication.

[0031] The network unit 104 may be distributed across geographical areas. In some embodiments, the network unit 104 may also include access points, access terminals, bases, base stations, node B, eNB, gNB, home node B, relay nodes, devices, core network, airborne servers, radio access nodes, APs, NRs, network entities, access and mobility management functions ("AMF"), integrated data management functions ("UDM"), integrated data repository ("UDR"), UDM / UDR, policy control functions ("PCF"), radio access network ("RAN"), network slice selection functions ("NSSF"), operation, administration, and management ("OAM"), session management functions ("SMF"), user plane functions ("UPF"), and The network unit 104 is generally part of a radio access network that includes one or more controllers commutably coupled to one or more corresponding network units 104. The radio access network is generally commutably coupled to one or more core networks, which may be coupled to other networks such as the Internet and public switched telephone networks. These and other elements of the radio access and core networks are not illustrated but are generally well known to those skilled in the art.

[0032] In one implementation, the wireless communication system 100 conforms to the New Radio (NR) protocol standardized by 3GPP, with the network unit 104 transmitting on the downlink (DL) using orthogonal frequency division multiplexing ("OFDM") modulation, and the remote unit 102 transmitting on the uplink (UL) using single-carrier frequency division multiple access ("SC-FDMA") or OFDM. However, more generally, the wireless communication system 100 may implement several other open or proprietary communication protocols, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, and LoraWAN. This disclosure is not intended to limit to any particular wireless communication system architecture or protocol implementation.

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

[0034] Figure 2 shows a user device 200 that may be used to implement the method described herein. The user device 200 is used to implement one or more of the solutions described herein. The user device 200 follows one or more of the user devices described herein. In detail, the user device 200 may comprise a remote unit 102, UE435, 904, 5G devices 530, 630, 730, or VAL UE1110, 1310, as described herein. The user device 200 may comprise a second network node, as described herein. The user device 200 may include application data analytics enablement clients (ADAEC) 1114, 1314, 1414, as described herein. The user device 200 includes a processor 205, memory 210, input device 215, output device 220, and transceiver 225.

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

[0036] As shown in the figure, 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 capable of operating on unlicensed spectrum. Furthermore, the transceiver 225 may include multiple UE panels supporting one or more beams. In addition, the transceiver 225 may support at least one network interface 240 and / or application interface 245. The application interface 245 may support one or more APIs. The network interface 240 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 240 may be supported as will be understood by those skilled in the art.

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

[0038] The processor 205 may control the user device 200 to perform the user device behavior described herein. The processor 205 may include an application processor (also called the "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also called the "baseband radio processor") that manages radio functions.

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

[0040] Memory 210 may store relevant data for implementing traffic category fields as described herein. Memory 210 may also store program code and related data, such as an operating system or other controller algorithms running on device 200.

[0041] The input device 215 may include any known computer input device, including touch panels, buttons, keyboards, styluses, microphones, etc. 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 on which text can be entered using a virtual keyboard displayed on the touchscreen and / or by writing on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touchscreen.

[0042] The output device 220 may be designed to output visual signals, acoustic signals, and / or tactile signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to the 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 a similar display device capable of outputting images, text, etc., to the user. As another non-limiting example, the output device 220 may include a wearable display, such as a smartwatch, smart glasses, or a head-up display, that is separate from the rest of the user equipment device 200 but communicatively coupled to them. Furthermore, the output device 220 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, vehicle dashboard, etc.

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

[0044] 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 to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or a portion thereof) at certain times to send and receive messages.

[0045] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. One or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, 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 200 may have any preferred number of transmitters 230 and receivers 235. Furthermore, the transmitters 230 and receivers 235 may be any preferred type of transmitter and receiver. The transceiver 225 may include a first transmitter / receiver pair used to communicate with a mobile communication network over a licensed radio spectrum, and a second transmitter / receiver pair used to communicate with a mobile communication network over an unlicensed radio spectrum.

[0046] A first transmitter / receiver pair may be used to communicate with a mobile communications network over licensed radio spectrum, and a second transmitter / receiver pair may be used to communicate with a mobile communications network over unlicensed radio spectrum. These may be combined into a single transceiver unit, for example, a single chip that performs functions for use with both licensed and unlicensed radio spectrum. The first and second transmitter / receiver pairs may share one or more hardware components. For example, several transceivers 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access shared hardware and / or software resources, such as a network interface 240.

[0047] One or more transmitters 230 and / or one or more receivers 235 may be implemented and / or integrated within a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit ("ASIC"), or other types of hardware components. One or more transmitters 230 and / or one or more receivers 235 may be implemented and / or integrated within a multi-chip module. Other components, such as a network interface 240 or other hardware components / circuits, may be integrated within a single chip together with any number of transmitters 230 and / or receivers 235. The transmitters 230 and receivers 235 may be logically configured as a transceiver 225 using another common control signal, or as modular transmitters 230 and receivers 235 implemented within the same hardware chip or multi-chip module.

[0048] Figure 3 shows further details of a network node 300 that may be used to implement the method described herein. The network node 300 may be one implementation of an entity in a wireless communication network, for example, in one or more of the wireless communication networks described herein. The network node 300 may comprise a network unit 104, a RAN 430, and a 5G core 1120. The network node 300 may comprise a first network node as described herein. The network node 300 may include application data analytics enablement servers (ADAES) 1164, 1264, 1364, and 1464 as described herein. The network node 300 may comprise a third network node as described herein. The network node 300 may include an Application layer - Analytics and Data Repository Function (A-ADRF) 1224 as described herein. The network node 300 includes a processor 305, memory 310, input device 315, output device 320, and transceiver 325.

[0049] The input device 315 and 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, memory 310, and transceiver 325, and may not include the input device 315 and / or output device 320.

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

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

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

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

[0054] The input device 315 may include any known computer input device, including touch panels, buttons, keyboards, styluses, microphones, etc. 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 on which text can be entered using a virtual keyboard displayed on the touchscreen and / or by writing on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touchscreen.

[0055] The output device 320 may be designed to output visual signals, acoustic signals, and / or tactile 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 a similar display device capable of outputting images, text, etc., to a user. As another non-limiting example, the output device 320 may include a wearable display, such as a smartwatch, smart glasses, or a head-up display, that is separate from the rest of the network node 300 but communicatively coupled to them. Furthermore, the output device 320 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, vehicle dashboard, etc.

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

[0057] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. One or more transmitters 330 may be used to communicate with a UE as described herein. Similarly, 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, a network node 300 may have any preferred number of transmitters 330 and receivers 335. Furthermore, the transmitters 330 and receivers 335 may be any preferred type of transmitter and receiver.

[0058] In many interactive and immersive applications with demanding requirements for latency, rate, and reliability, the application experience is served via a tethered connection, thereby connecting a endpoint Personal IoT Network Element (PINE) device to a gateway device, which in turn connects to a 3GPP access network (e.g., 4G, 5G, or similar) for internet connectivity. An example of such application experience delivery includes, for instance, an AR / VR experience, where the PINE is a head-mounted device (HMD) in the form of AR / VR glasses, and the gateway is a mobile phone or, alternatively, a 3GPP user device (UE). Thus, end-to-end connectivity between the client and the application server relies on at least three heterogeneous network segments: a tethered link, 3GPP connectivity, and a data network (DN) link. The tethered link and DN link are outside the scope of 3GPP. The tethered connection between the PINE and the gateway typically relies on Wi-Fi, Bluetooth, or unlicensed spectral radio access technology. Such connections impact E2E QoS, and in effect, both tethering links and DN links contribute to reducing the effectiveness of QoS rules and policies adopted within 3GPP networks.

[0059] Therefore, it is of great importance for 3GPP networks to monitor and incorporate link metrics regarding the performance of out-of-range network segments (e.g., tether links, DN links) traversing heterogeneous E2E network paths. 3GPP networks may also perform analyses of such link metrics and derive statistical characteristics of expected performance. Furthermore, such 3GPP networks may adapt 3GPP QoS rules and policies, compensate for the degradation effects of out-of-range network segments (e.g., additional latency), and seamlessly meet E2E application requirements for an enhanced user experience.

[0060] Assuming that an end-UE device may be disconnected from a running application (which can be deployed in a tethered UE), a solution is needed to facilitate efficient monitoring of the latency component of end-to-end application services in a 5G system (including the enablement layer), as well as how to ensure that service KPIs are met, taking into account the different technologies and connectivity links used according to e2e services (which are not under the control of the 5G system). Each connectivity link generates a component of the overall E2E latency.

[0061] The core network processes packets, which may be protocol data units (PDUs) and may be grouped into sets of PDUs as shown in Figure 4, which provides an overview of the core network (CN) XRM architecture for processing data packets. Figure 4 shows a system 400 comprising an Augmented 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 device 200 as described herein. The RAN 430 may comprise a base unit 104 and network nodes 300 as described herein. The operation of system 400 in the example of downlink traffic is described below, and a similar process may operate for uplink traffic.

[0062] In 480, AF412 determines the PDU requirements.

[0063] In 481, the application function 412 provides the PCF 415 with QoS requirements for the packet and information to identify the application (i.e., a 5-tuple or application ID). The QoS requirements may be expressed in terms of delay budget, i.e., packet delay budget (PDF) or alternatively, PDU set delay budget (PSDB), and error rate, i.e., packet error rate (PER) or alternatively, PDU set error rate (PSER).

[0064] In 482, PCF415 determines QoS rules for the application and specific QoS requirements for PDUs. The QoS rules may use 5G QoS identifiers (5QIs) for application traffic. PCF415 makes such a determination by determining 5QIs for application PDU traffic. PCF415 sends the QoS rules to SMF420 as 5-tuple PDU QoS requirements. PCF415 may include policy and billing control (PCC) rules in its communication to SMF420 for each severity level of the PDU set. PCC rules may be derived according to information received from AF412 or based on the operator configuration.

[0065] In 483, SMF420 establishes a QoS flow according to the QoS rules provided by PCF415 and configures UPF to route application packets into the QoS flow. SMF420 also provides a QoS profile, including PDU set QoS requirements, to RAN430 via AMF425. AMF425 may provide the QoS profile, including PDU set QoS requirements, to RAN430 within the N2 session management (SM) container. Furthermore, AMF425 may provide the QoS rules to UE435 within the N1 SM container.

[0066] In 484, the UPF440 determines the application's PDU (i.e., a 5-tuple) according to the N4 rule received from the SMF420 and routes it to the corresponding QoS flow.

[0067] In step 485, during PDU session establishment / modification, RAN430 receives the QFI and QoS flow QoS profile from SMF420 via AMF425, identifies packets belonging to the application's PDU session via the QoS flow, and processes the packets via RB according to the QoS requirements provided by SMF420. RAN430 inspects the GTP-U header to ensure that the PDU is processed according to the QoS profile determined by the SM container. This may include sending some packets within a radio bearer carrying QoS flow 1. This may also include sending other packets within a different radio bearer carrying QoS flow 2.

[0068] The general steps described above regarding QoS flow processing, i.e., mapping from RB QoS flows to application flows, and PDU session processing, are applicable to both UL and DL directions. That is, although the above example relates to downlink (DL) traffic, the reciprocal process is applicable to uplink (UL) traffic, and the role of UPF440 packet inspection is performed by UE435. The low-level signaling mechanism related to information passage from UL UE to RAN is the responsibility of the specification and implementation of the RAN signaling procedure.

[0069] In this specification, Augmented Reality (XR) is used as a comprehensive term for different types of reality, including virtual reality, augmented reality, and mixed reality.

[0070] Virtual reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual and auditory perceptual stimuli of the real world as naturally as possible as the observer or user moves within an area defined by the application. Virtual reality typically requires the user to wear a head-mounted display (HMD) to completely replace the user's field of view with simulated visual components, and headphones to provide the user with accompanying audio. Some forms of head and motion tracking in VR are also usually necessary to ensure that objects and sound sources remain synchronized with the user's movements from the user's perspective, allowing the simulated visual and audio components to be updated. Some implementations may provide additional means of interacting with the virtual reality simulation, but these are not strictly required.

[0071] Augmented reality (AR) is when additional information or artificially generated objects or content overlaid on their current environment are provided to the user. Such additional information or content is typically visual and / or acoustic, and the user's observation of their current environment may be direct, without intermediate sensing, processing, and rendering, or indirect, where the user's perception of their environment may be relayed, augmented, or processed via sensors.

[0072] Mixed reality (MR) is an advanced form of augmented reality (AR) in which several virtual elements are inserted into a physical scene with the intention of creating the illusion that these elements are part of a real-world scene.

[0073] XR refers to all combined real and virtual environments and human-machine interactions generated by computer technology and wearables. XR includes representative forms such as AR, MR, and VR, as well as areas that interpolate between them. The level of virtuality ranges from partially perceptual input to fully immersive VR. Within some areas, the primary aspect of XR is considered to be an extension of human experience, particularly related to the perception of presence (represented by VR) and the capture of cognition (represented by AR).

[0074] In 3GPP Release 17, the 3GPP SA4 Working Group analyzed media transport protocols and XR traffic models in technical report TR26.926 (v1.1.0) entitled "Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems," determining QoS requirements in terms of latency budget, data rate, and error rate necessary for the desired experience at the application level. These led to four additional 5G QoS identifiers (5QIs) for 5G systems (5GS) XR QoS flows. These 5QIs are defined in 3GPP TS23.501 (v17.5.0), Table 5.7.4-1, where they are presented as latency-critical GBR 5QIs with values ​​between 87 and 90. The latter are applicable to XR video streams and control the metadata necessary to deliver immersive and interactive XR experiences.

[0075] XR video traffic primarily consists of multiple DL / UL video streams with high resolution (e.g., typically at least 1080p dual-eye buffer), frames per second (e.g., 60+ fps), and high bandwidth (e.g., typically at least 20-30 Mbps), requiring transmission across the network with minimal latency (usually capped at 15-20 ms) to maintain reduced end-to-end application round-trip interaction latency. The latter requirement is critically important given the XR application's dependency on cloud / edge processing (e.g., content download, viewport generation and configuration, viewport updates, viewport rendering, media encoding / transcoding, etc.).

[0076] Tethered and heterogeneous links may be used for media applications. In Release 17, 3GPP considered support for 5G and later XR glasses based on a common client architecture that relies on three main components: the XR runtime, the scene manager, and the Media Access Function (MAF). Of the three, the MAF is generally relevant to the mode of communication.

[0077] 3GPP Technical Report TR26.998 (v18.0.0, December 2022) describes support for 5G glasses-type AR / MR devices and defines a Media Access Function (MAF) that supports AR UE for accessing and streaming media. For this purpose, the MAF includes the following: • Codecs: Used to compress and decompress media. In some cases, multiple instances of a codec are required, rather than just a single instance per media type. • Content Delivery Protocol: A container format and protocol for delivering media content between the UE and the network according to application requirements. This includes timing, synchronization, reliability, protocol-level reporting (e.g., RTP reporting), and other features. • 5G connectivity: Modem and 5G system functionality that enables the UE to connect to a 5G network and gain access to the functions and services provided by the 5G system. • Media Session Handler: A comprehensive function on the device to set up 5G system capabilities and support 5GS integration. This may include setting up edge functionality, providing QoS support, and supporting reporting functionality. • Content protection and decryption: This feature handles protecting content from being played on unauthorized devices.

[0078] Some example implementations of MAF are as follows: A 5GMSd client including a media session handler and media player as defined in TS26.501 and TS26.512. • A 5GMSu client including media session handlers and media streamers as defined in TS26.501 and TS26.512. A real-time communication client, including either uplink, downlink, or both, to support more latency-critical communication services, such as those for XR applications.

[0079] In Release 18, 3GPP is further exploring tethering methods for XR glasses-type devices, which will establish two different tethering methods as follows: • Tethered Standalone Glasses: In this example, the glasses run an XR application that uses the glasses' capabilities to create services. The glasses are tethered to a 5G device or similar mobile access technology (e.g., a mobile phone) and potentially use the phone's capabilities (e.g., a media session handler) to support the application. • Tethering Display Glasses: In this example, the glasses are tethered to a 5G device or similar mobile access technology (e.g., a mobile phone) that includes an application and XR functionality, i.e., at least a MAF and / or lightweight scene manager instance. The 5G device runs an application that uses the capabilities of the 5G device to run the XR experience. The glasses are connected to the 5G device and incorporate at least a lightweight XR runtime that is exposed to the 5G device either via an XR tethering link through XR runtime-specific APIs or via a wireless link that exposes a media buffer.

[0080] Figure 5 shows an implementation illustrating a first tethering method as a tethering-type standalone glasses. The AR glasses device 510 is tethered to the 5G device 530. The AR glasses device 510 includes an XR runtime 512, an XR runtime API 514, an AR / MR application 516, a wireless connectivity module 518, and a media access function 552. A pair of speakers 521, an eye display buffer 522, a sensor 523, and at least one camera 524 provide input to the XR runtime 512, which includes visual synthesis, haptics, and audio synthesis. The XR runtime API 514 provides interfaces between the XR runtime 512 and the uplink media management module 520 and the presentation engine 526, respectively. The presentation engine 526 includes interfaces with a visual renderer and an audio renderer, as well as a scene manager 527. The media access function 552 includes a metadata codec, a video codec, and an audio codec, as well as the MAF API 554. The AR / MR application 516 interfaces with the XR runtime API 514, the scene manager 527, and the MAF API 554, respectively.

[0081] The respective wireless connection modules 518 and 538 provide a tethering connection between the AR glasses device 510 and the 5G device 530. The MAF 552 passes compressed media to and from the tethering connection via the wireless connection module 518. The 5G device 530 is thought to include a smartphone and a 5G system module 535. A processor 531 performs phone-based processing functions. The phone-based processing functions include an API 533 that can pass configuration information to the AR / MR application 516 via the tethering connection.

[0082] Figure 6 shows an implementation of AR glasses in which the XR tethering link exposes the XR runtime as an XR runtime API to a 5G device. The AR glasses device 610 is tethered to the 5G device 630. The AR glasses device 610 includes an XR runtime core function 612. A pair of speakers 621, an eye display buffer 622, a sensor 623, and at least one camera 624 provide input to the XR runtime core function 612, which includes visual synthesis, haptics, and audio synthesis. The XR link function glasses 611 act as an interface between the XR runtime core function 612 of the AR glasses device 610 and the wireless connectivity module 618.

[0083] The respective wireless connection modules 618 and 638 provide a tethering connection between the AR glasses device 610 and the 5G device 630. The 5G device 630 includes an XR link function device 613 that provides an interface between the wireless connection module 638 and the XR runtime API 614. The 5G device 630 further includes an AR / MR application 616 and a media access function 652. The XR runtime API 614 provides an interface between the XR link function device 613 and the uplink media management module 620 and the presentation engine 626. The presentation engine 626 interfaces with the visual renderer and audio renderer, as well as the scene manager 627. The media access function 652 includes a metadata codec, a video codec, and an audio codec, as well as the MAF API 654. The AR / MR application 616 interfaces with the XR runtime API 614, the scene manager 627, and the MAF API 654. The 5G device 630 is thought to include a smartphone and a 5G system module 635. The MAF 652 passes compressed media to and from the 5G system module 635.

[0084] Figure 7 shows an implementation of AR glasses in which the exposure of the XR runtime via a tethering link, thereby acting as a media buffer source and sink, is supported by a virtualized edge network XR runtime instance. The AR glasses device 710 is tethered to a 5G device 730, which connects to the edge network 750 via a 5G connection. The AR glasses device 710 includes an XR runtime core function 712. A pair of speakers 721, an eye display buffer 722, a sensor 723, and at least one camera 724 provide input to the XR runtime core function 712. The XR runtime API 714 provides an interface to a basic AR / MR application 716.

[0085] The respective wireless connectivity modules 718 and 738 provide a tethering connection between the AR glasses device 710 and the 5G device 730. The XR runtime core function 712 of the AR glasses device 510 exchanges data with the 5G device 730 via the tethering connection. The 5G device 730 is thought to include a smartphone and a 5G system module 735. The 5G device 730 also includes a media access function 732. The MAF 752 passes compressed media to and from the 5G system module 735.

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

[0087] To reduce complexity, processing requirements, power consumption, and heat dissipation in XR glasses, all three tethering architectures in Figures 5, 6, and 7 can be supported by edge-splitting rendering. For this purpose, several key issues identified in the Release 18 3GPP tethering study relate to monitoring and reporting tethering link and DN link latency, and managing E2E QoS latency budgets, respectively.

[0088] In end-to-end (E2E) connectivity, including tethering links (e.g., Wi-Fi or Bluetooth links), 5G networks, and the internet, the latency monitoring and reporting solutions presented herein are relevant because the Wi-Fi and internet segments typically cannot guarantee latency. Low E2E latency is required by XR applications to deliver a good quality of experience (QoE) to end users. Such QoE can lead to a more immersive experience for the user and also make the experience feel more interactive. One approach to achieving the essential low E2E latency for XR applications is to keep latency on the 5G network extremely low so that the end-to-end latency is below the target value. However, this is costly because wireless communication systems have only finite bandwidth available, and provisioning unnecessarily low latency on a 5G network requires excessive allocation of radio resources. Such excessive wireless resource allocation may support more robust modulation and coding schemes (MCS), but this would require many other traffic flows to be diverted from bandwidth resources.

[0089] Therefore, the solution presented here is to dynamically adjust the latency in the 5G network according to the overall latency imposed elsewhere along the E2E path. This requires a measure of the non-5G latency in the overall E2E connection between the tethered headset and the application server. Latency on a Wi-Fi link can vary over time depending on interference generated by other nearby Wi-Fi networks operating within the same frequency band. Similarly, latency between the UPF and the application server (AS) depends on the selected UPF location, the selected edge / AS location, and the level of network congestion. Therefore, measurements may be used to estimate these time-varying latency on the non-5G segment.

[0090] An efficient implementation form is thus provided for determining latency across non-5G segments of E2E paths between glass endpoints and ASs or alternatively edge ASs (EAS) for segmented rendering.

[0091] Figure 8 shows the E2E path delay and subsequent path delay. In this example, the E2E path includes AR glasses 805, telephone 835, gNB 830, UPF 840, and edge application server 814. The delay notation shown in Figure 8 is defined as follows: ·D e2e : Indicates an E2E delay in one direction, i.e., either UL or DL. ·D 5GS: It shows the 5GS latency from the PSA UPF to the UE, which can be measured using the core network QoS monitoring procedure described in 3GPP TS23.501 and the RAN layer 2 measurement procedure described in TS38.314. This is based on the average performance of both the DRB and the QoS flow, provided that it can also be measured for each QoS flow per UE and per DRB. In the latter case, the GTP-U header is utilized to convey the necessary timestamps for the PSA UPF to the NG-RAN measurements, and the QoS monitoring procedure is applied for each QoS flow per UE. However, the latency between the NG-RAN and the UE is measured for each DRB per UE based on compliance with the RAN layer 2 procedure in the PDCP layer, with respect to the average value. ·D n,1 : It shows the tethering link (e.g., Wi-Fi, Bluetooth) latency. ·D n,2 : It shows the DN link (e.g., the connection between the PSA UPF and the AS or alternatively the EAS) latency. ·D n : D n =D n,1 +D n,2 shows the overall non-5G / non-3GPP E2E latency accumulated over the tethering type link and the DN link segments.

[0092] Therefore, it is useful to determine D e2e,max such that the delay budget and requirements of the application, i.e., D e2e =D 5GS +D n ≦D e2e,max enabling fine control of D 5GS using QoS rules. n It is useful to determine D

[0093] The latencies detailed above are thereby determined individually, and due to the interest being in the determination of D n,1 and D n,2 the delay measurements can be performed in segment units as such.

[0094] For delay measurements, the measured delay may represent the delay that data packets should encounter as they pass between the AR glasses 805 and the edge application server 814. While delay measurements based on out-of-band delay measurement messages, such as ping messages (ICMP echoes and echo responses according to RFC792), can be effective at capturing the delays encountered by data packets, they may not accurately reflect those delays. The latter is a consequence of two facts: i) delay measurement ICMP messages use a different protocol number (e.g., 1 for ping) than the protocol number of XR traffic data packets (e.g., 17 in cases where data packets are sent using RTP / UDP), which results in different 5-tuples (src addr, dst addr, src port, dst port, protocol id), and therefore different QoS treatments on the 5GS communication link; and ii) the packet size of ICMP delay measurements is typically much smaller than the packet size of data packets (tens of bytes), resulting in different transmission delays.

[0095] Alternative methods for latency measurement are represented by in-band latency measurement performed on top of the RTP / UDP stack, WebRTC stack, RTP / QUIC stack, or similar real-time communication protocol. In some implementations, this utilizes RTP header extensions, such as the WebRTC / RTP abs-send-time header extension (http: / / www.webrtc.org / experiments / rtp-hdrext / abs-send-time), and time synchronization with an NTP server to measure latency at the receiver or network node along the network path from the absolute transmission time of the RTP packet or, alternatively, the ADU encapsulating the RTP packet. In other implementations, piggybacking on top of RTCP sender / receiver reporting may be used in conjunction with RTP / RTCP multiplexing, such as RFC5761 for unicast sessions. In this case, for the latter, for UL, or alternatively for DL ​​direction, RTP timestamps may be used together with RTCP sender / report timestamps and receive time to calculate and estimate the mean round-trip time (RTT).

[0096] In the case of in-band delay measurement, the measurement framework is D e2e , D 5GS , and ultimately the measured value in question, namely, D n Determining this requires an E2E measurement technique coupled with a 5GS measurement procedure. This fact stems from a strategy of piggybacking on the RTP traffic originating from the application source.

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

[0098] Figure 9 shows an exemplary wireless communication system 900. System 900 comprises a UE 904, an NWDAF analysis logic function (ANLF) 910, an NWDAF model training logic function (MTLF) 912, multiple data producer network functions, in this example, an application function (AF) 920, a 5G network function 922, and an operation, administration, and maintenance (OAM) 924. Wireless communication system 900 further comprises multiple analysis consumer network functions, in this example, an application function 930, a 5G network function 932, and an OAM 934. In the current 3GPP architecture, the NWDAF 910, 912 (as defined in 3GPP Technical Specification 23.288 v17.2.0) provides analysis output to one or more of the analysis consumers NF930, 932, and 934 based on data collected from one or more data producers NF920, 922, and 924. The analysis output may be derived by NWDAF910, 912 using analysis sharing and / or federated learning. UE904 may be embodied as a remote unit 102, user equipment device 200, or alternatively as a tethering type UE1110, as described herein. NWDAF1 910 and NWDAF2 912 may be embodied as a network unit 104 and network node 300, as described herein.

[0099] A list of possible analytical consumers (NFs) for each analytical output provided by NWDAF is shown in Table 1 below.

[0100] [Table 1]

[0101] The following analyses are relevant to this disclosure in order to support XR services and applications. Such analyses may be useful for mobile XR users or for XR service providers who need to deploy XR services within a target area and within a target time (for example, for an event), and require statistics / forecasts on QoS / network performance and availability. • QoS Sustainability Analysis: Provides information on QoS change statistics over a historical analysis target period in several areas, or on projected QoS changes over a future analysis target period in several areas. • Network performance analysis: Provides either statistics or forecasts for gNB status information, gNB resource usage, communication performance, and mobility performance in the area in question. • User data congestion analysis: User data congestion-related analysis can relate to congestion encountered while transferring user data through the control plane, the user plane, or both. • DN Performance Analysis: Provides statistics or forecasts for DN performance indicators for specific edge computing applications for UEs, groups of UEs via specific Serving PSA UPFs, DN application identifiers, or EAS.

[0102] Release 17 completes the framework for UE data collection and the reporting framework for event exposure (EVEX). This provides an architecture and protocol that enables the collection of UE and AS data and the exposure of relevant events to NF consumers through a comprehensive architecture and procedure represented by NWDAF.

[0103] For this purpose, a high-level procedure is utilized in which data is collected by the NWDAF from the UE application via an intermediary AF acting as a data provider. This is accomplished by a Data Collection AF (DCAF) that is registered with the NRF and connected to the NWDAF as an event provider. The DCAF relies on three possible data collection clients. A direct data collection client that communicates directly with DCAF instances, operates just above the UE endpoint, and collects data related to application behavior and logic. • The UE application instance communicates with the collected data to an indirect data collection client operating within the ASP backend (the indirect data collection client collects the UE application data and relays it further to the DCAF instance), and / or AS / EAS communicating with DCAF as part of the ASP infrastructure or via NEF interfaces in distributed / separate domain deployments.

[0104] DCAF, and subsequently the data collection client, may be provisioned by the application service provider via provisioning AF with a configuration intended to perform data collection directly from one UE or group of UEs serving the application, or alternatively from an AS / EAS serving the application content to one UE or group of UEs. The configuration further comprises a data access profile provisioned by the application provider. The data access profile includes information about the data parameters to be collected (e.g., event ID), filtering metadata to be applied to the collected data (e.g., location filter, time sampling constraint, UE / application identifier filter, etc.), and reporting procedures. The data access profile may also specify the processing of the collected data to be performed by DCAF for event generation and further NF or alternatively, publication to AF.

[0105] DCAF connects to NWDAF instances, which are event consumers, as an NF data producer or, alternatively, an event producer. The NWDAF service-based architecture allows for the connection of further event consumers. For example, other event consumers may be other NFs such as PCF, SMF, UPF, or similar, or other AFs such as application provider AFs.

[0106] Figure 10 shows a comprehensive DCAF architecture in a simplified format. NRF registration and provisioning of AF connections for DCAF are omitted for brevity. Wireless communication device 1035 includes a Direct Data Collection Client (DDCC) 1036 that reports to a Data Collection Application Function (DCAF) 1022. DCAF 1022 receives data reported by the UE from the same application server 1024 and publishes events to both NWDAF 1032 and an event consumer application function 1016 in ASP 1010. NWDAF 1032 publishes network data analysis to any network function 1042 that wishes to consume the data analysis. Thus, DCAF 1022, together with the Direct Data Collection Client 1036 and AS 1024, which may be an edge AS, collects data via a configured data collection session (i.e., using a data access profile that captures data via a RESTful API served over an HTTPS authenticated connection). The collected data is processed in DCAF1022 to generate and publish events, which are then consumed by NWDAF1032 for analysis. NWDAF1032 then performs analysis on the collected events and outputs the results to other NF / AF consumers 1042.

[0107] Data access profiles are defined in TS26.531 v17.0.0 "Data Collection and Reporting; General Description and Architecture". Various constraints are available based on time, user, and location dimensions. • Time-based constraints: Determines the granularity of access to UE data along the time axis. The finest granularity allows access to events as they occur in a timely (unconstrained) manner. The coarsest level of access assumes an aggregation window, aggregating all event data along the time axis to produce a single aggregated value. • User-aligned constraints: Allows provisioning AF to restrict access to UE data-related events based on groups. The finest granularity allows event consumers to access UE-related events as a single user or on their behalf. Coarse-grained access exposes aggregated, collected event data based on user groups defined by the application (e.g., UEs running several application versions). The coarsest granular access exposes the data being aggregated to all users. • Location-based constraints: Allows provisioning AF to restrict access to UE data-related events based on the geographical location of data collection clients during an event. The finest granularity allows event consumers to access events individually regardless of location. Coarse-grained access exposes aggregated collected event data based on geographical area. The coarsest level of access aggregates all event data along location to produce a single aggregated value for all locations.

[0108] The baseline set of aggregation filters for DCAF is currently specified in 3GPP TS26.532 v17.1.0 "Data Collection and Reporting.Protocols and Formats," specifically in Table 4.5.2-1. The baseline DCAF aggregation filters based on the reporting period are as follows: • None: Aggregation is not applied, and all reported data records are published as individual events. • Count: The number of data records reported is made public to event consumers. • Average: The average representative value of the values ​​in the reported data records is exposed to the event consumer. • Maximum: The maximum observed value among the reported data records is exposed to the event consumer. • Minimum: The minimum observed value among the reported data records is exposed to the event consumer. • Total: The sum of the values ​​in the reported data records is exposed to the event consumer.

[0109] In 3GPP, a framework for Service Enablement Application Layers (SEALs) in supporting Vertical Application Layers (VALs) has been developed over several past releases. Therefore, SEALs are organized as a comprehensive SEAL service function model, instantiated by specific SEAL service function models such as the following: • Location management, Group management, ·Configuration management, • Identification information management, ·Key management, • Network resource management, • Data distribution, and • Enable Application Data Analytics (ADAE).

[0110] The comprehensive functional model for SEAL is based on a client-server architecture and is organized into comprehensive functional entities to represent a functional architecture that addresses application layer support modes for vertical applications for both on-network (based on Uu connectivity) and off-network (based on PC5 connectivity).

[0111] The ADAE layer is a new SEAL service specified in 3GPP TS23.436 v0.3.0 “Procedures for Application Data Analytics Enablement Service”. Figure 11 is a reproduction of Figure 5.2.2-1 from TS23.436, showing the Application Data Analytics Enablement Architecture 1100 in a non-roaming scenario, using reference point notation to show how various entities interact with each other.

[0112] Architecture 1100 includes a VAL UE 1110 that communicates with a VAL server 1162 and an Application Data Analysis Activation Server (ADAES) 1164 via a 3GPP network system 1150. The VAL UE 1110 includes a VAL client 1112 and an Application Data Analysis Activation Client (ADAEC) 1114. The communication protocol between the components of Architecture 1100 is shown in the figure. Architecture 1100 can be considered to include a VAL side and a SEAL side. The VAL side is shown as the upper part of Figure 11, and the SEAL side is shown as the lower part of Figure 11.

[0113] In operation, the application data analysis enablement client communicates with the application data analysis enablement server via the ADAE-UU reference point. The application data analysis enablement client provides support for the application data analysis enablement function to the VAL client via the ADAE-C reference point. The VAL server communicates with the application data analysis enablement server via the ADAE-S reference point. The application data analysis enablement server acting as an AF may communicate with the 5G core network function (via the N33 reference point to the NEF and the N6 reference point to the UPF) and with the OAM (via the ADAE-OAM interface).

[0114] In the ADAE framework, A-DCCF and A-ADRF can be defined as functionalities within the ADAE architecture, and can provide the following functionalities: The Application Layer - Data Collection and Coordination Function (A-DCCF) coordinates the collection and distribution of data requested by consumers (ADAE servers). Data collection coordination is supported by the A-DCCF. ADAE servers can send data requests to the A-DCCF instead of directly to the data source. The A-DCCF may also perform data processing / abstraction and data preparation based on VAL server requirements. The A-DCCF can be within the ADAE framework or, in some implementation forms, as an external data coordination function (e.g., SEAL entities, core entities). The Application Layer - Analysis and Data Repository (A-ADRF) stores historical data and / or analysis, i.e., data and / or analysis related to past time periods acquired by the consumer (e.g., ADAE server). After the consumer acquires the data and / or analysis, the consumer may store the historical data and / or analysis in the A-ADRF. Whether the consumer accesses the A-ADRF directly or proceeds via the A-DCCF depends on the configuration.

[0115] Figure 12 shows a comprehensive functional model 1200 for ADAE when reusing the 3GPP network data analysis model. The Application Layer - Analysis and Data Repository Function (A-ADRF) 1224 stores the analyzed and collected data in its associated storage components. The architecture 1200 further comprises at least one data source 1230, an Application Layer - Data Acquisition and Coordination Function (A-DCCF) 1240, an ADAE server 1264, and an analysis consumer 1262. The data network 1240 (which may be an edge data network) comprises the A-ADRF 1224, at least one data source 1230, the A-DCCF 1240, and the ADAE server 1264.

[0116] In this model, A-DCCF1240 is used to fetch data or to place data into application-level entities (e.g., A-ADRF1224, data source 1230). Such an A-DCCF1240 coordinates the collection and distribution of data requested by ADAE server 1264 (via ADCCF-1, ADAE-X). ADAE server 1264 can also interact directly with the data source via ADAE-Y.

[0117] Furthermore, the Application Layer-Analysis and Data Repository Function (A-ADRF) 1224 may be used to store historical data and / or analysis, i.e., data and / or analysis relating to past time periods, which are acquired (via AADRF-1) by the ADAE server 1264 or other NF / NWDAF. The ADAE server 1264 can also fetch historical data from the ADRF 1224. Whether the ADAE server 1264 accesses the ADRF directly or via the A-DCCF 1240 depends on the configuration.

[0118] Data source 1230 can be a 5GS data source (5GC, OAM), an enablement layer data source (SEAL, EEL), or an external data source on the DN side (VAL server / EAS) and VAL UE. A-DCCF1240 and A-ADRF1224 can be used only to interact with some data sources (e.g., 5GC, OAM) depending on the configuration and can be hidden from the VAL layer.

[0119] A mechanism for analyzing latency in application layer segments within end-to-end application service (e.g., XR services) segments, and particularly in tethered devices, for the link between application clients and 3GPP UEs (especially 5G UEs), is presented herein. Based on this analysis, the mechanism includes deriving application layer statistics or forecasts for the segment in question, and optional recommendations for actions directed toward consumers (e.g., VAL servers or VAL clients, NFs such as NWDAFs and DCAFs). The steps of this solution are defined in the following numbered paragraphs.

[0120] 1. Consumers subscribe to an Application Services Enabler (ADAES, or commonly SEAL Server / EES) for monitoring or analysis events related to the segment in question (e.g., Link X: Tethering Devices ~ 5G Devices).

[0121] 2. The Application Service Enabler sends requirements to 5G devices, specifically to client applications on 5G devices (i.e., Service Enabler clients, or ADAEC, or SEAL clients), and configures the devices to collect or calculate data and reports and certain criteria (for example, by providing default thresholds to trigger actions).

[0122] 3. A 5G device begins collecting data from one or more application clients (via request / response or join / notification) on one or more tethering devices. Such collection may include at least one of the following options: Alt1: Requests end-to-end latency historical measurements from the application client. The enabler client can identify the segment between the 5G device and the application service enabler, and thus calculate the remaining latency contribution. Alt2: By knowing the relative location of the tethered UE and the technology used, the enabler client can estimate the maximum and minimum latency based on NLOS and LOS. Alt3: When one or more applications of a tethered UE interact with a 5G device, the 5G device can determine when and for how long the latency to the link exceeds the packet latency budget (for example, for link X, the PDB may be 5ms, and the XR message arrives at the 5G device within 7ms). Alt4: (Using an analysis enabler) 5G devices perform localized analysis based on the location and technology of the tethered UE, as well as the environment and time of day. Such analysis may be AI / ML based.

[0123] 4. A 5G device sends collected data (measurements or analyses) in the form of reports to an application service enabler for one or more tethered devices. Such reports may be provided once, periodically, or based on an event (e.g., delay deviation).

[0124] 5. The application service enabler derives analysis based on its data. Such analysis can take the following forms: Statistics or forecasts for latency for a given time horizon, per link, per tethered UE, or per 5G device. Statistics or predictions for end-to-end delay, taking into account inputs from both 3GPP and non-3GPP links. • Whether the delay for the segment in question can be sustained over a given session or time period.

[0125] 6. Based on the analysis, the service enabler may also recommend proactive actions toward VAL customers or 5G networks. Such actions may be based on several policies (trigger event-action pairs), or the service enabler may have logic for translating predictive events into actions for VAL services. Regarding the VAL server, the action could be a modification of the service mode / level (e.g., video resolution, level of automation) to allow the application to handle potentially large latency. This could also include additional modifications such as changing the traffic schedule (from the application layer) or different retransmission policies. Regarding 5GC, such actions could include updating per-network session QoS requirements / profiles to offset large potential delays caused by high latency in the segment (from tethered UE to 5G devices). Additional actions may include requests to update UP routes (to perform traffic steering) or possible slice modifications (which can provide lower latency).

[0126] 7. The service enabler sends analytical output based on consumer subscriptions.

[0127] Figure 13 shows Architecture 1300, which provides a mechanism for cases where VAL clients exist in different, non-networked UEs where analysis of the ADAE-C interface is required. Such cases may occur in the following situations: Tethering in XR scenarios. • Industrial scenarios where a VAL client resides in a local cloud and the UE is a low-capacity node (e.g., a field device or slave). In such scenarios, the interaction between the slave / field device and the local cloud can be via other wireless technologies (e.g., Wi-Fi). • Constrained devices (e.g., sensors) may not run the application on a different entity (e.g., a UE GW for a group of devices) rather than the same entity. Interaction between the GW and the VALUE can be via non-3GPP wireless means.

[0128] Architecture 1300 includes a VAL UE 1310 that communicates with a VAL server 1362 and an Application Data Analysis Activation Server (ADAES) 1364 via a 3GPP network system 1350. The VAL UE 1310 includes a VAL client 1312 and an Application Data Analysis Activation Client (ADAEC) 1314. The VAL UE 1310 is tethered to a tethering device 1320 via a non-3GPP access link. The non-3GPP access link may include Bluetooth or Wi-Fi. The tethering device 1320 includes a VAL client 1322. The communication protocols between the components of Architecture 1300 are shown in the figure. Architecture 1300 can be considered to include a VAL side and a SEAL side. The VAL side is shown as the upper part of Figure 13, and the SEAL side is shown as the lower part of Figure 13.

[0129] The connection of ADAEC1314 to ADAES1364 is a prerequisite for the operation of architecture 1300. The steps for this solution are defined in the following numbered paragraphs.

[0130] Step 1: VAL server 1362 sends a join request to ADAES1364 for ADAE-C / VAL-X1314 performance analysis. In this request, VAL server 1362 indicates the service ID / application ID, VAL UE ID and address, tethering device identification information (or information), connectivity type to ADAE-C1314 and VAL-X (e.g., Wifi), optionally the location of the tethering device (if it is assumed to be fixed), analysis type (e.g., latency persistence, or predicted latency, or latency statistics), service area, validity time, and, if applicable, preferred reliability level (in the case of prediction).

[0131] It may be possible for the UE not to be specified, and for the subscription to be for all UEs within a given service area (e.g., XR users).

[0132] Step 2: ADAES1364 authorizes the request and sends an enrollment response as a positive or negative result.

[0133] Step 3: ADAES1364 identifies the VALUEs that require reporting and the data sources required for data collection. The data sources may include: A-ADRF may retain historical data / analysis related to ADAE-C / VAL-X interface latency for a given UE or given service and area / time. A VAL client 1322 of a tethering device 1320 capable of providing QoS data (latency) to the link or end-to-end. • VAL client 1312 for VAL UE1310, supporting connectivity.

[0134] Step 4: ADAES1364 sends a request to ADAEC1314 requesting performance data for ADAE-C and / or VAL-X, specifying the reporting configuration parameters (frequency, interval, etc.), trigger criteria for reporting (e.g., threshold for higher acceptable delays), required processing (abstraction, analysis / statistics), and the data sources required to provide data and time effectiveness for the request.

[0135] Step 5: ADAEC1314 identifies whether it is possible to collect the requested data and, if so, responds to ADAES1364 with an affirmative or negative recognition response.

[0136] Step 6: ADAEC1314 begins collecting data from the data source. In the case of A-ADRF, ADAEC joins A-ADRF either directly or via ADAES.

[0137] Step 7: Based on the reporting configuration and data requirements, ADAEC provides ADAES with data / analysis relating to the performance of ADAE-C and / or VAL-X. Such data may be expected / actual / predicted / statistical delays or deviations / deltas from the upper limit for the link / segment in question.

[0138] Step 8: Upon receiving data, ADAES1364 derives an analysis of the VAL-X / ADAE-C predictive performance. To do this, ADAES1364 may optionally acquire auxiliary data at the locations of the VAL UE1310 and tethering device 1320 to help predict latency more accurately.

[0139] Step 9: ADAES1364 may also provide recommendations for proactive actions based on the analysis. This requires ADAES1364 to have logic for such transformations, or ADAES1364 may utilize another SEAL service (or input from a VAL server) to identify what the best action is based on predictive triggers.

[0140] Step 10. ADAES1364 sends analytical notifications and, optionally, proactive adaptations to network entities and / or application entities.

[0141] It may be desirable to integrate analysis of the data network performance of applications within the SEAL plane. Such integration may support implementations of extremely vertical, immersive, and / or interactive media applications encountered by end users through tethered UEs, such as XR applications, in combination with HMDs and 5G devices or similar.

[0142] Therefore, in order to provide support and a reliable experience for extremely vertical, immersive, and interactive media applications encountered via tethered UEs, QoS latency characteristics at the application layer, i.e., E2E across all network segments, may be monitored and controlled. In such a configuration, the SEAL ADAE service, • Via the DN link segment, i.e., from the VAL server to the 5GS PSA UPF, · Via the 5GS link segment, i.e., from the 5GS PSA UPF to the tethering UE (i.e., the 5G device), and / or • Via the UE tethering link segment, i.e., from the 5G device providing 5G DN connectivity to the tethered end-user device where the VAL application experience is consumed. You may monitor the connectivity of VAL across all network segments.

[0143] ADAE may require new extensions to its support for application performance analysis, thereby enabling simultaneous monitoring, analysis, and forecasting of the data connectivity pipeline from both a tethered UE or alternative VAL client perspective and an AS / EAS or alternative VAL server perspective.

[0144] A tethered UE DCAF implementation may be provisioned to expose at least one event of type E2eDelayExperience, TetheredLinkDelayExperience, and DnDelayExperience, and may be linked as a data source to the SEAL ADAE functional architecture. New events exposed to ADAE are collected by a tethered UE direct data collection client or alternatively by a VAL client, and by the AS / EAS or alternatively by a VAL server. e2e , D n,1 , D n,2It is based on delay measurements in this manner. Therefore, ADAES acts as a consumer AF exposed to the DCAF event output. This tethered UE-specific ADAE data source thus augments other ADAE data sources, namely the VAL server, the 5GS data source, and the enablement layer data source (e.g., SEAL, Edge Enablement Layer (EEL)).

[0145] A tethered UE direct data acquisition client may be instantiated and implemented by an ADAE client (ADAEC) placed within the tethered UE device together with MAF or, alternatively, MSH.

[0146] ADAEs connected to a tethered UE DCAF can extend their support for application performance analysis to include additional tethered UE analysis as a tethered VAL client. These analyses may be extended to include online analysis for real-time analysis and prediction to be consumed by the VAL server. Such ADAE functionality may be identified by the analysis ID "Tethered VAL Connectivity Performance".

[0147] A VAL server consuming ADAE tethering-type VAL connectivity performance analysis may adapt its behavior (e.g., application layer configuration adaptation, source coding rate reduction, video coding configuration changes related to FPS, Q parameters, number of slices, number of layers, number of eye buffers, or similarly, audio coding configuration changes to lower coding quality, AS / EAS load balancing, etc.), or may request network resource management from a SEAL NRM instance for the adaptation of QoS measures based on ASP application requirements.

[0148] In the former case, one example is that when ADAES predicts an increase in latency E2E by monitoring any of the events exposed by the tethered UE via the corresponding ADAEC, the VAL server may reduce the FPS of video traffic related to the XR application from 120 FPS to 60 FPS.

[0149] In the latter case, one implementation form adapts the 5GS QoS delay budget and also D c,1 From the previous PDB settings, D c,2 Rather, it should be lowered to a lower PDB setting, which may include the VAL server determining the 5GS network provider, and as a result, D c,2 +D n,1 +D n,2 ≤D e2e,max And so, however, D e2e,max This is the maximum threshold of end-to-end latency acceptable by the ASP application and the VAL server. In such cases, a VAL server request to the SEAL layer seeking to adapt the QoS latency budget parameter over 5GS is based on the VAL server's interaction with the NRM server, thereby causing the VAL server to execute a network resource adaptation request to the NRM server to reduce the QoS latency budget within the limits permitted by the SLA between the ASP and the mobile network operator or 5GS service provider. In one example, such a request may include VAL server requester identification information, a list of one or more tethered VAL UE IDs, and resource adaptation requirements indicating the VAL service requirement for a new QoS latency budget (e.g., 10ms as either PDB or PSDB as an alternative) for the QoS flow related to the VAL service flow in question. Assuming the VAL server is authorized to request such changes and reports back the status of the update (i.e., whether it was successful or failed, including the changed parameters, and the appropriate failure code), the NRM executes the adaptation procedure.

[0150] The procedure for ADAE analysis of tethered UE and application connectivity performance, which establishes a connection between ADAEC and ADAES, is described below as shown in Figure 14.

[0151] Figure 14 shows the tethering-type VAL connectivity performance analysis procedure 1400. Procedure 1400 is performed by a tethering-type VAL UE 1410, a 5G system 1450, an ADAES 1464, and a VAL server 1462. The tethering-type VAL UE 1410 includes a VAL client 1412 and an ADAEC 1414.

[0152] Procedure 1400 is initiated in 1471 when a consumer of the ADAES analysis service, for example, VAL server 1462, sends a subscription request to ADAES 1464, providing an analysis event ID, e.g., "Tethered VAL Connectivity Performance", a target tethered VAL UE ID or group of tethered UE IDs, a VAL session / service ID associated with the tethered VAL UE ID, the time validity and area of ​​the request, any required confidence level for prediction, and the exposure level for the UEs provided for UE analysis. Such a request may also include whether the analysis notification should be periodic or based on expected application ASP QoS performance, thereby performance thresholds (e.g., maximum tetherlink delay = 15ms) may be provided in the request as an addition.

[0153] At 1472, ADAES1464 sends a join response as an ACK to the consumer (VAL server 1462).

[0154] In 1473, ADAES1464 maps analysis IDs (i.e., tethering VAL connectivity performance) to a list of data collection event identifiers and optionally to a list of data producer IDs. Such mappings may be pre-configured by ADAES1464 itself based on the ASP preferred event type or VAL type, or alternatively, pre-configured by the MNO using OAM. In addition, ADAES1646 determines which instances of ADAES1414 are authorized to perform tethering link-related data collection and reporting based on the configured tethering VAL UE ID and VAL session / service ID. Tethering link-related data collection and reporting are based on the EVEX procedure with the tethering UE DCAF reporting mechanism.

[0155] In 1474, ADAES1464 sends a tethered VAL connectivity performance analysis request to the determined tethered VAL ADAEC1414, along with the analysis event ID and the required reporting configuration (e.g., periodic, based on maximum delay threshold). Such a request also includes additional application QoS attributes to be analyzed as additional based on other metrics (e.g., tethered link delay, E2E delay, 5GS PER, 5GS PDB / PSDB). An application session is then initiated between the tethered VAL UE1410 and the VAL server 1462.

[0156] The next steps may occur asynchronously and in parallel, assuming a 5GC service-based architecture and the reporting of events for configured data collection. Therefore, the order of events given below is merely one example implementation.

[0157] In 1475a, ADAEC1414 begins collecting data from the tethered VAL UE1410 upon request. Collection and reporting are based on the EVEX UE data collection procedure, which is associated with the mapped event ID of the tethered UE link performance. For events that may collect various events related to tethered link delay, for example, the event ID would be TetheredLinkDelayExperience. Thus, this data may be about delay measurements, throughput (e.g., maximum WiFi capacity), QoE measurements, etc. The data may be partially collected by ADAEC1414 from the VAL client application 1412 and (for example, with respect to TetheredLinkDelayExperience) based on the EVEX data collection and reporting procedure.

[0158] In 1475b, ADAES1464 can optionally collect further data, including DN performance analysis via NWDAF event consumption, service experience analysis, and QoS monitoring analysis via 5GS, including metrics for average / maximum packet delay between the VAL server and the serving PSA UPF.

[0159] In addition, in 1475c, ADAES1464 may optionally collect data on DN performance analysis by NWDAF event consumption, including metrics for average / maximum packet delay E2E between the VAL server and the tethered VAL UE1410, and other E2E metrics related to QoS monitoring analysis (e.g., aggregated E2E PER).

[0160] In 1476a, ADAEC1414 detects changes in application QoS. Such changes may be changes in QoS attribute requirements, for example, by detecting events that exceed the maximum latency threshold acceptable by the ASP (e.g., via a tethered link or E2E), but where a detection mechanism is performed over a given time horizon based on an analysis join request.

[0161] In 1476b, ADAES1464 either detects or predicts application QoS changes. Such changes could be changes in QoS attribute requirements, for example, by detecting or predicting (based on collected metrics) events, where the maximum latency threshold acceptable by the ASP (e.g., over a tethered link, over a DN link, or over E2E connectivity) is exceeded, but the detection mechanism is performed over a given time horizon based on the analysis join request.

[0162] In 1477, ADAEC1414 sends the analysis to ADAES1464 in the tethering-type VAL connectivity performance analysis response message.

[0163] In step 1478, ADAES1464 sends the derived analysis notification to the consumer (e.g., VAL server 1462, or any other authorized NF / AF consumer).

[0164] Therefore, a first network node is provided for enabling performance analysis of tethered connections, and the application session comprises an end-to-end communication session, the end-to-end communication session includes a tethered connection. The first network node comprises a processor and memory coupled to the processor, and the processor is configured to cause the first network node to receive requirements for performance analysis of the application session, identify at least one device to act as a data collection entity for collecting data required for performance analysis, and send the data collection requirements to the identified data collection entity, wherein the data collection requirements include a request for performance data relating to at least one tethered connection within the application session. The processor is further configured to cause the first network node to receive performance data measured in accordance with the data collection requirements from the data collection entity, derive a performance analysis based on the performance data and the data collection requirements, and send the derived performance analysis.

[0165] The first network node may thus derive a performance analysis that includes the performance of the tethering connection. Such a performance analysis is necessary to properly understand the end-to-end quality of service. One measure of end-to-end quality of service may include end-to-end latency. An end-to-end communication session may include the connection between user equipment and the application server.

[0166] A tethering connection is thus a component of an end-to-end communication session. An end-to-end communication session is contained within an application session.

[0167] The first network node may be an Application Data Analysis Activation Server (ADAES).

[0168] An application session may include communication between a wireless communication device and an application server. An application session may comprise multiple links communicated by multiple access technologies. The wireless communication device may comprise a tethering device and a tethering device. A tethering device may be configured to communicate with a tethering device via at least one tethering connection. The tethering connection may comprise, for example, a connection using Wi-Fi or Bluetooth.

[0169] Receiving requirements for performance analysis includes receiving subscription requests from analysis consumers.

[0170] The derived performance analysis may be sent to the analysis consumer in response to the requirements for performance analysis.

[0171] The requirements for performance analysis may include at least one of the following: analysis event identifiers, at least one target VALUE identifier, a group identifier consisting of one or more tethering device identifiers and one or more tethering-type device identifiers, information about the capability and / or access technology for the tethering connection, positioning information related to the target VALUE identifier, VAL session identifier related to the target VALUE identifier, VAL service identifier related to the target VALUE identifier, a time period over which measurements should be collected, a definition of the area over which measurements should be collected, the required confidence level for any derived performance analysis, and the level of disclosure for providing analysis related to tethering-type connections. The target VALUE identifier may include identifiers for tethering-type devices and / or tethering devices. The derived performance analysis may include at least one prediction.

[0172] The processor may be further configured to cause the first network node to select at least one data source for data collection by the data collection entity.

[0173] Performance data may include historical data and / or real-time data. Real-time data refers to measurement data that is reported as it is collected.

[0174] The data collection requirement may include subscription to at least one data source.

[0175] An application session may comprise at least one of the following: an augmented reality session, a mobile metaverse session, and / or an artificial intelligence application session.

[0176] The performance analysis may include at least one of the following: statistics or predictions for communication latency of a tethered connection; statistics or predictions for end-to-end latency, taking into account the tethered connection and other segments within the end-to-end communication session; and / or identifying whether the quality of service for the tethered connection is sustainable over a given session or time period. The performance analysis may relate to a specific time period. The specific time period may be defined. For example, the specific time period may be defined by the consumer. The consumer may include an application server or a network unit.

[0177] Performance analysis results may be sent to the application server or network unit.

[0178] Figure 15 shows a method 1500 performed by a first network node to enable performance analysis of a tethered connection, wherein the application session comprises an end-to-end communication session, and the end-to-end communication session includes a tethered connection. Method 1500 comprises receiving a requirement for performance analysis for the application session (1510), identifying at least one device to act as a data collection entity to collect data required for the performance analysis (1520), and sending the data collection requirement to the identified data collection entity (1530), wherein the data collection requirement includes a request for performance data relating to at least one tethered connection within the application session. Method 1500 further comprises receiving performance data measured in accordance with the data collection requirement from the data collection entity (1540), deriving a performance analysis based on the performance data and the data collection requirement (1550), and sending the derived performance analysis (1560).

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

[0180] The first network node may thus derive a performance analysis that includes the performance of the tethering connection. Such a performance analysis is necessary to properly understand the end-to-end quality of service. One measure of end-to-end quality of service may include end-to-end latency. An end-to-end communication session may include the connection between user equipment and the application server.

[0181] The first network node may be an Application Data Analysis Activation Server (ADAES).

[0182] An application session may include communication between a wireless communication device and an application server. An application session may comprise multiple links communicated by multiple access technologies. The wireless communication device may comprise a tethering device and a tethering device. A tethering device may be configured to communicate with a tethering device via at least one tethering connection. The tethering connection may comprise, for example, a connection using Wi-Fi or Bluetooth.

[0183] Receiving requirements for performance analysis includes receiving subscription requests from analysis consumers.

[0184] The derived performance analysis may be sent to the analysis consumer in response to the requirements for performance analysis.

[0185] The requirements for performance analysis may include at least one of the following: analysis event identifiers, at least one target VALUE identifier, a group identifier consisting of one or more tethering device identifiers and one or more tethering-type device identifiers, information about the capability and / or access technology for the tethering connection, positioning information related to the target VALUE identifier, VAL session identifier related to the target VALUE identifier, VAL service identifier related to the target VALUE identifier, a time period over which measurements should be collected, a definition of the area over which measurements should be collected, the required confidence level for any derived performance analysis, and the level of disclosure for providing analysis related to tethering-type connections. The target VALUE identifier may include identifiers for tethering-type devices and / or tethering devices. The derived performance analysis may include at least one prediction.

[0186] The method may further include selecting at least one data source for data collection by the data collection entity.

[0187] Performance data may include historical data and / or real-time data. Real-time data refers to measurement data that is reported as it is collected.

[0188] The data collection requirement may include subscription to at least one data source.

[0189] An application session may comprise at least one of the following: an augmented reality session, a mobile metaverse session, and / or an artificial intelligence application session.

[0190] The performance analysis may include at least one of the following: statistics or predictions for communication latency of a tethered connection; statistics or predictions for end-to-end latency, taking into account the tethered connection and other segments within the end-to-end communication session; and / or identifying whether the quality of service for the tethered connection is sustainable over a given session or time period. The performance analysis may relate to a specific time period. The specific time period may be defined. For example, the specific time period may be defined by the consumer. The consumer may include an application server or a network unit.

[0191] Performance analysis results may be sent to the application server or network unit.

[0192] A second network node is further provided to enable performance analysis of tethered connections, and the application session includes an end-to-end communication session, the end-to-end communication session including a tethered connection. The second network node comprises a processor and memory coupled to the processor. The processor is configured to cause the second network node to receive data collection requirements from the first network node, determine at least one data source based on the data collection requirements, collect performance data from at least one data source based on the data collection requirements, and send the collected performance data to the first network node.

[0193] The second network node may thus derive a performance analysis that includes the performance of the tethered connection. Such a performance analysis is necessary to properly understand the end-to-end quality of service. One measure of end-to-end quality of service may include end-to-end latency.

[0194] The second network node may include an Application Data Analysis Activation Client (ADAEC). The first network node may include an Application Data Analysis Activation Server (ADAES).

[0195] The processor may be further configured to cause a second network node to process the collected performance data before sending it to the first network node. The second network node may include collecting performance data from at least one data source, processing the collected performance data, and then sending the processed collected performance data to the first network node.

[0196] The processor may be further configured to cause a second network node to determine whether the collected performance data is sufficient to meet the data collection requirements, and, if the collected performance data is not sufficient to meet the data collection requirements, to request auxiliary data. The auxiliary data may be collected from at least one data source, or may form further data sources.

[0197] Performance data may include an indication of communication delay in tethering connections.

[0198] Collecting performance data may involve at least one of the following: requesting historical end-to-end latency measurements from application clients; estimating maximum and minimum latency based on non-line-of-sight and line-of-sight conditions and using the relative location of the tethered connection endpoint; determining when the latency for the tethered connection exceeds the packet latency budget; and / or performing local analysis based on the location of the tethered device, the communication technology used for the tethered connection, and the local environment and time.

[0199] If collecting performance data involves requesting end-to-end latency historical measurements from the application client, the second network node may identify segments within the application session and calculate the remaining latency contribution.

[0200] Estimating maximum and minimum latency, assuming non-line-of-sight and line-of-sight connections and using the relative location of the tethered connection endpoint, may be based on the communication technology used for the tethered connection.

[0201] Understanding when the latency for a tethered connection exceeds the packet latency budget means that the tethering device determines how long the tethered connection will exceed the packet latency budget (PDB) when one or more applications use the tethered connection.

[0202] Localized analysis can be AI / ML-based.

[0203] Figure 16 shows a method 1600 performed by a second network node to enable performance analysis of a tethered connection, wherein the application session comprises an end-to-end communication session, and the end-to-end communication session includes a tethered connection. Method 1600 comprises receiving data collection requirements from a first network node (1610), determining at least one data source based on the data collection requirements (1620), collecting performance data from at least one data source based on the data collection requirements (1630), and sending the collected performance data to the first network node (1640).

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

[0205] The second network node may thus derive a performance analysis that includes the performance of the tethered connection. Such a performance analysis is necessary to properly understand the end-to-end quality of service. One measure of end-to-end quality of service may include end-to-end latency.

[0206] The second network node may include an Application Data Analysis Activation Client (ADAEC). The first network node may include an Application Data Analysis Activation Server (ADAES).

[0207] The method may further include processing the collected performance data before sending it to the first network node. The method may include collecting performance data from at least one data source, processing the collected performance data, and then sending the processed collected performance data to the first network node.

[0208] The method may further include determining whether the collected performance data is sufficient to meet the data collection requirements, and, if the collected performance data is insufficient to meet the data collection requirements, requesting supplementary data. The supplementary data may be collected from at least one data source, or may form additional data sources.

[0209] Performance data may include an indication of communication delay in tethering connections.

[0210] Collecting performance data may involve at least one of the following: requesting historical end-to-end latency measurements from application clients; estimating maximum and minimum latency based on non-line-of-sight and line-of-sight conditions and using the relative location of the tethered connection endpoint; determining when the latency for the tethered connection exceeds the packet latency budget; and / or performing local analysis based on the location of the tethered device, the communication technology used for the tethered connection, and the local environment and time.

[0211] If collecting performance data involves requesting end-to-end latency historical measurements from the application client, the second network node may identify segments within the application session and calculate the remaining latency contribution.

[0212] Estimating maximum and minimum latency, assuming non-line-of-sight and line-of-sight connections and using the relative location of the tethered connection endpoint, may be based on the communication technology used for the tethered connection.

[0213] Understanding when the latency for a tethered connection exceeds the packet latency budget means that the tethering device determines how long the tethered connection will exceed the packet latency budget (PDB) when one or more applications use the tethered connection.

[0214] Localized analysis can be AI / ML-based.

[0215] A third network node is further provided for enabling performance analysis of tethered connections within an application session, the application session including communication via at least one tethered connection. The third network node comprises a processor and memory coupled to the processor. The processor is configured to cause the third network node to send requirements for performance analysis of the application session to the first network node, the requirements for performance analysis including a request for performance data relating to at least one tethered connection within the application session, and to receive the performance analysis from the first network node.

[0216] Figure 17 shows a method 1700 performed by a third network node for enabling performance analysis of tethered connections within an application session, the application session including communication over at least one tethered connection. Method 1700 comprises sending a requirement for performance analysis for the application session to a first network node (1710), wherein the requirement for performance analysis includes a request for performance data relating to at least one tethered connection within the application session, and receiving the performance analysis from the first network node (1720).

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

[0218] The third network node may thus derive a performance analysis that includes the performance of the tethered connection. Such a performance analysis is necessary to properly understand the end-to-end quality of service. One measure of end-to-end quality of service may include end-to-end latency.

[0219] The third network node may have Application Layer Analysis and Data Repository (A-ADRF) functionality. The first network node may be an Application Data Analysis Enablement Server (ADAES).

[0220] An application session may include communication between a wireless communication device and an application server. An application session may comprise multiple links communicated by multiple access technologies. The wireless communication device may comprise a tethering device and a tethering device. A tethering device may be configured to communicate with a tethering device via at least one tethering connection. The tethering connection may, for example, include a connection using Wi-Fi or Bluetooth.

[0221] This disclosure set presents the following novel elements: a method for providing performance monitoring and performance analysis in a 5GS entity for interfaces supported by non-3GPP connectivity; and a method for introducing ADAE service functionality to VAL tethered connectivity performance analysis, which exposes analysis related to the performance of a tethered VAL UE to a VAL server and allows applications to adapt their behavior with respect to source encoding configuration, QoS, and EAS / AS load balancing.

[0222] A method (which may be performed in ADAES) for enabling performance analysis for tethered links within an application session is provided herein. The method comprises obtaining requirements for performance analysis for an application session, wherein the application session comprises multiple links communicated by multiple access technologies; identifying at least one device to act as a data collection entity for data required for performance analysis; sending the data collection requirements to the identified data collection entity; receiving performance data based on the data collection requirements, wherein the performance data relates to tethered links within the application session; deriving an analysis based on the requirements; and sending the derived analysis.

[0223] Obtaining requirements may involve receiving subscription requests from consumers and sending subscription responses.

[0224] The method may further include selecting at least one data source for collection.

[0225] Performance data may include historical or real-time data.

[0226] The data collection requirement may include subscription to at least one data source.

[0227] An application session may be at least one of the following: an XR session, a mobile metaverse session, or an AI application session.

[0228] Tethering links may be communicated via technologies including Wi-Fi and Bluetooth.

[0229] Further methods are provided (which may be performed within ADAEC) to support performance analysis activation for tethered links within an application session, the methods comprising: receiving a data collection request from an analysis activation entity; determining at least one data source based on the request; collecting performance data from the determined data source based on the request; sending the collected performance data to the analysis activation entity; processing the data before sending it; requesting / receiving auxiliary data (location, ...) if the data is insufficient, wherein the performance data is the delay of the tethered link; and determining a mechanism for estimating the delay of the tethered link.

[0230] It should be noted that the methods and apparatus described above are illustrative rather than limiting of the present invention, and that many alternative configurations can be designed by those skilled in the art without departing from the scope of the appended claims. The term “comprising” does not preclude the existence of elements or steps other than those enumerated in the claims, and “a” or “an” does not preclude plural, and a single processor or other unit may perform the functions of several units described in the claims. No reference numerals in the claims shall be construed as limiting their scope.

[0231] Furthermore, although examples are given in the context of specific communication standards, these examples are not intended to limit the communication standards to which the disclosed methods and apparatus may be applied. For example, although specific examples are given in the context of 3GPP, the principles disclosed herein may also be applied to other wireless communication systems, and certainly to any communication system that uses routing rules. The methods may also be embodied as a set of instructions stored on a computer-readable medium that, when loaded into a computer processor, a digital signal processor (DSP), or the like, cause the processor to execute the methods described above.

[0232] The methods and apparatus described may be practiced in other specific forms. The methods and apparatus described should be considered illustrative only and not restrictive in all respects. Accordingly, the scope of the invention is indicated not by the above description but by the appended claims. All modifications that fall within the equivalent meaning and scope of the claims should be encompassed within those scopes.

[0233] The following abbreviations are used in the fields covered by this specification: 3GPP: Third 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, ADAES: 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 The following are related terms: 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: Augmented Reality, XR AS: XR Application Server, and XRM: XR Media. [Explanation of Symbols]

[0234] 100 Wireless Communication Systems 102 Remote Unit 104 Network Unit, Base Unit 200 user equipment devices, remote units 205 Processor 210 memory 215 Input Devices 220 Output Devices 225 Transceiver 230 Transmitter 235 Receiver 240 network interfaces 245 Application Interfaces 300 network nodes 305 Processor 310 memory 315 Input Devices 320 Output Devices 325 Transceiver 330 Transmitter 335 Receiver 340 Network Interfaces 345 Application Interfaces 410 Application Service Provider, Augmented Reality Media Application Capabilities (XRM AF) 412 Application Functions (AF) 414 Application Server 415 Policy and Control Function (PCF) 420 Session Management Function (SMF) 425 Access and Mobility Functions (AMF) 430 Wireless Access Network (RAN) 435 User Equipment (UE) 440 User Plane Function (UPF) 510 AR Glasses Device 512 XR runtime 514 XR Runtime APIs 516 AR / MR applications 518 Wireless connectivity module 520 Uplink Media Management Module 521 Speakers 522 eye display buffer 523 Sensor 524 Camera 526 Presentation Engine 527 Scene Manager 530 5G Device 531 Processor 533 API 535 5G System Module 538 Wireless Connection Module 552 Media Access Function 554 MAF API 610 AR Glass Device 611 XR Link Function Glass 612 XR Runtime Core Function 613 XR Link Function Device 614 XR Runtime API 616 AR / MR Application 618 Wireless Connection Module 620 Uplink Media Management Module 621 Speaker[[ID=​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ 732 Media access function 735 5G system module 738 Wireless connection module 750 Edge network 752 Media access function 754 MAF API 756 XR runtime 757 XR runtime API 758 XR scene manager 759 XR scene API 760 AR / MR application 805 AR glasses 814 Edge application server 830 gNB 835 Telephone 840 UPF 900 Wireless communication system<000095​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​1110 VAL UE, Tethering type UE 1112 VAL Client 1114 Application Data Analytics Activation Client (ADAEC) 1150 3GPP Network System 1162 VAL Server 1164 Application Data Analytics Activation Server (ADAES) 1224 Application Layer - Analytics and Data Repository Function (A-ADRF) 1230 Data Sources 1240 Application Layer - Data Acquisition and Coordination Functions (A-DCCF), Data Network 1262 Analysis Consumer 1264 ADAE Server 1310 VALUE 1312 VAL Client 1314 Application Data Analytics Activation Client (ADAEC) 1320 Tethering devices 1322 VAL Client 1350 3GPP Network System 1362 VAL Server 1364 Application Data Analytics Activation Server (ADAES) 1410 Tethering-type VALUE 1412 VAL Client, VAL Client Application 1414 ADAEC 1450 5G system 1462 VAL Server 1464 ADAES

Claims

1. A first network node for enabling performance analysis of a tethering connection, wherein the application session comprises an end-to-end communication session, the end-to-end communication session includes the tethering connection, and the first network node, Processor and The processor comprises a memory coupled to the processor, and the processor is connected to the first network node, To receive requirements for performance analysis of the aforementioned application session, Identifying at least one device to act as a data collection entity for collecting the data required for the aforementioned performance analysis, Sending a data collection request to the identified data collection entity, wherein the data collection request includes a request for performance data relating to the at least one tethered connection within the application session. Receiving performance data measured in accordance with the aforementioned data collection requirements from the data collection entity, To derive a performance analysis based on the aforementioned performance data and the aforementioned data collection requirements, It is configured to send the derived performance analysis, The first network node.

2. Receiving requirements for performance analysis includes receiving subscription requests from analysis consumers, The derived performance analysis may be sent to the analysis consumer in response to the requirements for performance analysis, and the derived performance analysis may be sent to the analysis consumer. The first network node according to claim 1.

3. The above requirements for performance analysis are, Analysis event identification information, At least one target VALUE identifier, A group identifier consisting of one or more tethering device identification information and one or more tethering type device identification information, Information regarding the capabilities and / or access technologies for the aforementioned tethering connection, Positioning information related to target VALUE identification information, VAL session identification information related to target VAL UE identification information, VAL service identification information related to target VAL UE identification information, The time period over which measurements should be collected, Definition of the area where measurements should be collected. The required reliability level for any derived performance analysis, and Public access level to provide analysis related to the aforementioned tethering connection. A first network node according to claim 1 or 2, comprising at least one of the following:

4. The first network node according to any one of claims 1 to 3, wherein the processor is further configured to cause the first network node to select at least one data source for the data collection by the data collection entity.

5. The first network node according to any one of claims 1 to 4, wherein the performance data may include historical data and / or real-time data.

6. A first network node according to any one of claims 1 to 5, wherein the data collection requirement comprises joining at least one data source.

7. The first network node according to any one of claims 1 to 6, wherein the application session comprises at least one of an augmented reality session, a mobile metaverse session, and / or an artificial intelligence application session.

8. The aforementioned performance analysis, Statistics or predictions regarding the communication delay of the aforementioned tethering connection, Statistics or forecasts for end-to-end latency, taking into account the tethering connection and other segments within the end-to-end communication session, and / or To identify whether the quality of service for the tethering connection is sustainable over a given session or time period. A first network node according to any one of claims 1 to 7, comprising at least one of the following:

9. The first network node according to any one of claims 1 to 8, wherein the performance analysis is sent to an application server or network unit.

10. A method performed by a first network node for enabling performance analysis of a tethered connection, wherein an application session comprises an end-to-end communication session, the end-to-end communication session includes the tethered connection, and the method The steps include receiving requirements for performance analysis of the aforementioned application session, The steps include identifying at least one device to act as a data collection entity for collecting data required for the aforementioned performance analysis, A step of sending a data collection request to the identified data collection entity, wherein the data collection request includes a request for performance data relating to the at least one tethered connection within the application session. The steps include receiving performance data measured in accordance with the aforementioned data collection requirements from the data collection entity, A step of deriving a performance analysis based on the performance data and the data collection requirements, The process includes the step of sending the derived performance analysis, method.

11. A second network node for enabling performance analysis of a tethering connection, wherein the application session comprises an end-to-end communication session, the end-to-end communication session includes the tethering connection, and the second network node, Processor and The processor comprises a memory coupled to the processor, and the processor is connected to the second network node, Receiving data collection requirements from the first network node, Determine at least one data source based on the aforementioned data collection requirements, Based on the aforementioned data collection requirements, performance data is collected from at least one of the aforementioned data sources. The system is configured to send the collected performance data to the first network node. The second network node.

12. The second network node according to claim 11, wherein the processor is further configured to cause the second network node to process the collected performance data before sending it to the first network node.

13. The processor provides the second network node with Determine whether the collected performance data is sufficient to satisfy the data collection requirements. If the collected performance data is insufficient to meet the data collection requirements, the system is further configured to request supplementary data. The second network node according to claim 11 or 12.

14. The second network node according to any one of claims 11 to 13, wherein the performance data includes an indication of the communication delay in the tethering connection.

15. Collecting performance data is Requesting end-to-end latency historical measurements from the application client, To estimate maximum and minimum latency based on non-line-of-sight and line-of-sight conditions, and using the relative location of the endpoint of the tethering connection, To determine when the delay for the aforementioned tethering connection will exceed the packet delay budget, and / or Performing local analysis based on the location of the tethering device, the communication technology used for the tethering connection, and the local environment and time. A second network node according to any one of claims 11 to 14, comprising at least one of the following:

16. A method performed by a second network node for enabling performance analysis of a tethered connection, wherein an application session comprises an end-to-end communication session, the end-to-end communication session includes the tethered connection, and the method is The steps include receiving data collection requirements from the first network node, A step of determining at least one data source based on the aforementioned data collection requirements, Based on the aforementioned data collection requirements, the steps include: collecting performance data from at least one data source; The process includes the step of sending the collected performance data to the first network node. method.

17. A third network node for enabling performance analysis of tethered connections within an application session, wherein the application session includes communication via at least one tethered connection, and the third network node Processor and The processor comprises a memory coupled to the processor, and the processor is connected to the third network node, Sending requirements for performance analysis of the application session to a first network node, wherein the requirements for performance analysis include a request for performance data relating to the at least one tethered connection within the application session. The system is configured to receive performance analysis from the first network node. The third network node.

18. A method performed by a third network node for enabling performance analysis of a tethered connection within an application session, wherein the application session includes communication via at least one tethered connection, and the method A step of sending requirements for performance analysis of the application session to a first network node, wherein the requirements for performance analysis include a request for performance data relating to the at least one tethered connection within the application session. The process includes the step of receiving a performance analysis from the first network node, method.

Images