GB2627328A - Latency analysis - Google Patents

Abstract

A first network entity, e.g. a Network Data Analytics Function (NWDAF), receives from a second network entity a request or subscription for analytics relating to transmission delay associated with one or more UEs; obtains input data from a third network entity, the input data including information relating to the transmission delay; and outputs information relating to the NWDAF-based analytics based on the obtained input data, wherein the information comprises at least one output for the NWDAF-based analytics, and wherein the transmission delay corresponds to traffic to/from the one or more UEs or corresponds to a data volume sent by/to one of the one or more UEs. The transmission delay may relate to traffic associated with AI/ML-based services including AI/ML modelling or training, AI/ML inference, or transfer of AI/ML models, or extended reality and media (XRM). The at least one output may assist with a federated learning operation or another AI/ML operation. The transmission delay-related information may be latency, packet delay distribution, jitter, periodicity, or end-to-end volume transfer time.

Description

Latency Analysis

BACKGROUND

Field

[0001] Certain examples of the present disclosure relate to methods, apparatus and/or systems for providing analytics information to a consumer. In particular, certain examples of the present disclosure consider methods and/or apparatus for providing UE latency performance related analytics, for example for a UE or a group of UEs. Further, certain examples consider methods and/or apparatus relating to NWDAF-based latency performance analytics for artificial intelligence / machine learning (Al/ML)-based services and extended reality and media (XRM)-based services.

Description of Related Art

[0002] The content of the following documents is referred to below and/or their content provides background information that the following disclosure should be considered in the context of: [1] 3GPP TS 22.261 -Service requirements for the 5G system, SA1, Release 18 (e.g., V18.7.0); [2] 3GPP TS 23.288 -Architecture enhancements for 5G System (5GS) to support network data analytics services, Release 18 (e.g., V18.0.0); [3] 3GPP TS 23.502 -Procedures for the 5G System (5GS), Release 18 (e.g., V.18.0.0); [4] 3GPP TS 28.552 -Management and orchestration; 5G performance measurements, Release 18 (e.g., V.18.0.0).

Note: the indicated version numbers are provided for illustrative purposes, other (including future) versions of these documents may be considered also.

[0003] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3d Generation Partnership Project (3GPP) design, specify and standardise technologies for mobile wireless communication networks. Fourth Generation (4G) and Fifth Generation (5G) systems are now widely deployed.

[0004] 3GPP standards for 4G systems include an Evolved Packet Core (EPC) and an Enhanced-UTRAN (E-UTRAN: an Enhanced Universal Terrestrial Radio Access Network). The E-UTRAN uses Long Term Evolution (LTE) radio technology. LTE is commonly used to refer to the whole system including both the EPC and the EUTRAN, and LTE is used in this sense in the remainder of this document. LTE should also be taken to include LTE enhancements such as LTE Advanced and LTE Pro, which offer enhanced data rates compared to LTE.

[0005] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies.

[0006] There is an increasing desire to improve network automation for 5G telecommunication networks, known as enabling Network Automation (eNA). As a part of this, Network Data Analytics Function (NWDAF) as defined in 3GPP Technical Specification, TS, 23.288 [2] is defined as part of a Service Based Architecture (SBA) using mechanisms and interfaces specified for 5G Core and Operations Administration and Maintenance (OAM).

[0007] In a SBA, each 5G Core (5GC) network function (NF) comprises a set of services that interfaces it (as the producer of such services) to other NFs (as the consumer of those services) over a common bus known as service-based interface (SBI).

[0008] NWDAF is a 5GC NF that provides different sets of output analytics, statistics and predictions based on input data that it collects from, for example, other 5GC NFs, Application Function(s) (AF(s)) or OAM.

[0009] Various analytics focusing on service experience and network performance are described in TS 23.288 [2]. Among those existing analytics, few of them consider delay information as an input data and some of them consider delay as part of their output statistics and predictions.

SUMMARY

[0010] It is an aim of certain examples of the present disclosure to address, solve and/or mitigate, at least partly, at least one of the problems and/or disadvantages associated with the related art, for example at least one of the problems and/or disadvantages described herein. It is an aim of certain examples of the present

I

disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0011] According to a first example of the present disclosure, therein is provided a first network entity comprising a transmitter, a receiver and a controller configured to: receive, from a second network entity, a request or a subscription for Network Data Analytics Function (NWDAF)-based analytics relating to transmission delay associated with one or more UEs; obtain, based on the request or subscription, input data from at least one third network entity, the input data including information relating to the transmission delay; and output information relating to the NWDAF-based analytics based on the obtained input data, wherein the information comprises at least one output for the NWDAF-based analytics; wherein the transmission delay corresponds to traffic to or from the one or more UEs or corresponds to a data volume sent by or sent to one of the one or more UEs.

[0012] According to a second example, there is provided the first network entity of the first example, wherein the transmission delay relates to traffic associated with Al/ML-based service(s) including one of: Al/ML modelling or training, Al/ML inference, or transfer of Al/ML models.

[0013] According to a third example, there is provided the first network entity of the first example or the second example, wherein the at least one output is for assisting with a federated learning operation or another Al/ML operation.

[0014] According to a fourth example, there is provided the first network entity of any of the first example to the third example, wherein the input data comprises one or more of: a timestamp associated with the obtained input data; one or more first UE location(s); one or a list of first UE ID(s); or quality of service (QoS) flow packet delay.

[0015] According to a fifth example, there is provided the first network entity of the fourth example, wherein one or more of: the one or more first UE location(s) include a location of each of the one or more UEs; the one or the list of first UE ID(s) includes one or a list of subscription permanent identifiers (SUPIs) corresponding to the one or more UEs; or the QoS flow packet delay indicates observed packet delay for uplink (UL) direction, observed packet delay from downlink (DL) direction or observed packet delay measurements between the UE and a protocol data unit (PDU) session anchor (PSA) user plane function (UPF).

[0016] According to a sixth example, there is provided the first network entity of the fifth example, wherein one or more of: the timestamp is obtained from a 5G core (5GC) network function (N F); the one or more first UE location(s) are obtained from an access and mobility management function (AM F) or, if the required area of interest (Aol) has a granularity area below that of cell level, from a gateway mobile location centre (GMLC); or the QoS flow packet delay is obtained from a UPF or a session management function (SMF).

[0017] According to a seventh example, there is provided the first network entity of any of the first example to the third example, wherein the input data comprises one or more of: a timestamp associated with the obtained input data; a first application ID; one or a list of first UE ID(s); traffic volume; a start time; or an end time.

[0018] According to an eighth example, there is provided the first network entity of the seventh example, wherein one or more of: the first application ID includes an identifier of an application at the third network entity providing the input data; the one or the list of first UE ID(s) includes, for each of the one or more UEs, a subscription permanent identifiers (SUPIs) or a Generic Public Subscription Identifiers (GPSIs); the traffic volume is traffic volume to or from the one or more UEs or traffic volume of Al/ML related data associated with the one or more UEs; the start time indicates a start time of an Al/ML operation; or the end time indicates an end time of an Al/ML operation.

[0019] According to a ninth example, there is provided the first network entity of the eighth example, wherein the timestamp, the first application ID, the one or the list of first UE ID(s), the traffic volume, the start time and/or the end time are obtained from the same or a different application function (AF).

[0020] According to a tenth example, there is provided the first network entity of any of the first example to the ninth example, wherein the at least one output comprises: one or a list of second UE ID(s) corresponding to the one or more UEs, and for each second UE ID, delay performance information.

[0021] According to an eleventh example, there is provided the first network entity of the tenth example, wherein the delay performance information for each second UE ID comprises one or more of: a second application ID; Data Network Access Identifier (DNA°, a UE location; DNN; S-NSSAI; validity period; spatial validity; UE uplink (UL) delay performance information; UE downlink (DL) delay performance information; or UE round trip delay performance information.

[0022] According to a twelfth example, there is provided the first network entity of the eleventh example, wherein, in relation to the delay performance information for each second UE ID, one or more of: the second application ID indicates an application in use at that UE; the DNN indicates the DNN for a PDU session which contains a QoS flow of traffic from that UE; the S-NSSAI indicates a network slice used to access the application in use at that UE; the validity period indicates a validity period for the UE delay performance for that UE; or the spatial validity indicates an area where the UE delay performance for that UE applies.

[0023] According to a thirteenth example, there is provided the first network entity of any of the tenth example to the twelfth example, wherein the delay performance information for each second UE ID comprises one or more of: UL delay performance information over a time period for providing the analytics; an indication of a UL traffic volume corresponding to the UL delay performance information; DL delay performance information over the time period for providing the analytics; or an indication of a DL traffic volume corresponding to the DL delay performance information.

[0024] According to a fourteenth example, there is provided the first network entity of any of the first example to the ninth example, wherein the transmission delay is associated with a plurality of UEs; and wherein the at least one output comprises: a list of second UE IDs corresponding to the plurality of UEs, and in relation to the list of second UE IDs, delay performance information for the plurality of UEs.

[0025] According to a fifteenth example, there is provided the first network entity of the fourteenth example, wherein the delay performance information for the plurality of UEs comprises aggregate delay performance information.

[0026] According to a sixteenth example, there is provided the first network entity of the fifteenth example, wherein the aggregate delay performance information comprises one or more of: a list of one or more group of UE(s), from among the plurality of UEs, classified by ranges of delay performance, each group corresponding to a different class of delay performance; for each of the one or more group of UE(s), ID(s) of UE(s) in that class; for the one or more group of UE(s), an indication of a ratio of the UE(s) between each class; a validity period for the delay performance information for the plurality of UEs; or a spatial validity indicating an area where the delay performance information for the plurality of UEs applies.

[0027] According to a seventeenth example, there is provided the first network entity of the sixteenth example, wherein the number of the classes of delay performance or the number of the ranges of delay performance are predefined by an operator or provided by the second network entity.

[0028] According to an eighteenth example, there is provided the first network entity of the sixteenth example or the seventeenth example, wherein the delay performance information is classified according to one or more threshold.

[0029] According to a nineteenth example, there is provided the first network entity of the sixteenth example to the eighteenth example, wherein the one or more group of UE(s) comprises one or more of a list of low delay UE(s) corresponding to a first class, a list of medium delay UE(s) corresponding to a second class, or a list of high delay UE(s) corresponding to a third class.

[0030] According to a twentieth example, there is provided the first network entity of any of the first example to the nineteenth example, wherein each of the at least one output is a statistic or a prediction.

[0031] According to a twenty-first example, there is provided the first network entity of the twentieth example, wherein, if the at least one output comprises a prediction, the at least one output further comprises a confidence for the prediction.

[0032] According to a twenty-second example, there is provided the first network entity of the first example, wherein: the first network entity is a NWDAF, the second network entity is a service consumer including an application function (AF) or a 5G core (5GC) network function (NF), and the at least one third network entity includes one or more of another AF, a session management function (SMF), access and mobility management function (AMF), user plane function (UPF), a policy control function (PCF) or operations administration and maintenance (OAM).

[0033] According to a twenty-third example of the present disclosure, there is provided a method of a first network entity, the method comprising: receiving, from a second network entity, a request or subscription for Network Data Analytics Function (NWDAF)-based analytics relating to transmission delay associated with one or more UEs; obtaining, based on the request or subscription, input data from at least one third network entity, the input data including information relating to the transmission delay; and outputting information relating to the NWDAF-based analytics based on the obtained input data, wherein the information comprises at least one output for the NWDAF-based analytics; wherein the transmission delay corresponds to traffic to or from the one or more UEs or corresponds to a data volume sent by or sent to one of the one or more UEs, [0034] According to a twenty-fourth example of the present disclosure, there is provided a network comprising a first network entity according to any of the first example to the twenty-second example.

[0035] According to a twenty-fifth example, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method according to the twenty-third example.

[0036] [0037] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Embodiments/examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which: Figure 1 shows a representation of a procedure for deriving latency performance related analytics according to an embodiment of the present disclosure.

Figure 2 shows a representation of a method flow for an NWDAF to derive latency performance related analytics according to an embodiment of the present disclosure.

Figure 3 is a block diagram illustrating an example structure of a network entity in accordance with certain examples of the present disclosure.

DETAILED DESCRIPTION

[0039] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention or disclosure.

[0040] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0041] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

[0042] The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the disclosure.

[0043] Throughout the description of this specification, the words "comprise", "include" and "contain" and variations of the words, for example "comprising" and "comprises", means "including but not limited to", and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and/or groups thereof [0044] Throughout the description of this specification, the singular form, for example "a", "an" and "the", encompasses the plural unless the context otherwise requires. For example, reference to "an object" includes reference to one or more of such objects.

[0045] Throughout the description, the expression "at least one of A, B and/or C" (or the like), the expression "and/or", and the expression "one or more of A, B and/or C" (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C. [0046] Throughout the description of this specification, language in the general form of "X for Y" (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y. [0047] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and/or groups thereof described or disclosed in conjunction with a particular aspect, embodiment or example are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith.

[0048] Certain examples of the present disclosure provide methods, apparatus and/or systems for at least one of: providing UE latency performance related analytics using new analytics or by modifying existing analytics to include new parameters (e.g., new input data and/or new output data (e.g., new statistics and/or predictions)), providing latency performance related analytics specifically relating to Al/ML-based services or XRM services, providing latency performance related analytics for a UE or a group of UEs, providing methods for triggering reporting of input data to an NWDAF at another network entity such as AF, AMF, SMF or UPF. Note, however, that the present disclosure is not limited to these examples, and includes other examples.

[0049] Certain embodiments of the present disclosure therefore provide advantages relating to obtaining and deriving latency performance related analytics such as for XRM-based services or Al/ML-based services, thereby supporting more efficient provision, controlling and management of such services.

[0050] The following examples are applicable to, and use terminology associated with, 3GPP 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and/or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G NR or any other relevant standard. For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network.

[0051] A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and/or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0052] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example: * The techniques disclosed herein are not limited to 3GPP 5G.

* One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations.

* One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information.

* One or more further elements, entities and/or messages may be added to the examples disclosed herein.

* One or more non-essential elements, entities and/or messages may be omitted

in certain examples.

* The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example.

* The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example.

* Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.

* Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.

* The order in which operations are performed may be modified, if possible, in alternative examples.

* The transmission of information between network entities is not limited to the specific form, type and/or order of messages described in relation to the examples disclosed herein.

[0053] Certain examples of the present disclosure may be provided in the form of an apparatus/device/network entity configured to perform one or more defined network functions and/or a method therefor. Such an apparatus/device/network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and/or method steps for implementing the techniques described herein. For example, an operation/function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses/devices/network entities, and/or a method therefor.

[0054] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and/or apparatus in accordance with any aspect, example and/or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[0055] A network according to one or more of the examples disclosed herein may include one or more of a Network Data Analytics Function (NWDAF) entity, an Access and Mobility Management Function (AMF) entity, a Session Management Function (SMF) entity, a Network Slice Selection Function (NSSF) entity, a Network Repository Function (NRF) entity, Application Function (AF) entity, and an Operation and Maintenance (OAM) entity. The network may include one or more Service Consumers (including one or more of the entities mentioned above and/or one or more other entities) that receive analytics from NWDAF. The skilled person will appreciate that a network may omit one or more of the entities mentioned above and/or may comprise one or more additional entities [0056] New frameworks and architectures are being developed as part of 5G networks in order to increase the range of functionality and use cases available through 5G networks. One such new framework is the use of artificial intelligence / machine learning (Al/ML), which may be used for the optimisation of the operation of 5G networks.

[0057] In Al/ML operation, AI/ML models and/or data might be transferred across the AI/ML applications (e.g., application functions (AFs)), 5GC (5G core), UEs (user equipments) etc.). Without limitation, the AI/ML works could be divided into two main phases: model training and inference. During model training and inference, multiple rounds of interaction may be required.

[0058] In Section 6.40 CAW L model transfer in 5GS') in TS 22.261 [1], three types of AI/ML operations to be supported in Release 18 are described as follows: a) Al/ML operation splitting between A//ML endpoints The AI/ML operation/model is split into multiple parts according to the current task and environment. The intention is to offload the computation-intensive, energy-intensive parts to network endpoints, whereas leave the privacy-sensitive and delay-sensitive parts at the end device. The device executes the operation/model up to a specific part/layer and then sends the intermediate data to the network endpoint. The network endpoint executes the remaining parts/layers and feeds the inference results back to the device.

b) Al/ML model/data distribution and sharing over 5G system Multi-functional mobile terminals might need to switch the AI/ML model in response to task and environment variations. The condition of adaptive model selection is that the models to be selected are available for the mobile device.

However, given the fact that the AI/ML models are becoming increasingly diverse, and with the limited storage resource in a UE, it can be determined to not pre-load all candidate Al/ML models on-board. Online model distribution (i.e. new model downloading) is needed, in which an Al/ML model can be distributed from a NW (network) endpoint to the devices when they need it to adapt to the changed AI/ML tasks and environments. For this purpose, the model performance at the UE needs to be monitored constantly. c)

Distributed/Federated Learning over 5G system The cloud server trains a global model by aggregating local models partially-trained by each end devices. Within each training iteration, a UE performs the training based on the model downloaded from the Al server using the local training data. Then the UE reports the interim training results to the cloud server via 5G UL channels. The server aggregates the interim training results from the UEs and updates the global model. The updated global model is then distributed back to the UEs and the UEs can perform the training for the next iteration.

[0059] In general, the Al/ML works can be divided into three main phases: model training, model transfer and inference. More specifically, with the introduction of federated learning, model transfer has become a crucial phase to successfully perform some Al/ML operations. Time spent for model training, inference and transmission of the Al/ML models and for output of the inference depend on computation and/or communication capabilities of participating nodes/components; hence, the time varies among different nodes/components.

[0060] In order to assist the AF and any other NFs to organize and schedule the Al/ML operation (including any types of the Al/ML operation, e.g., federated learning etc.), a corresponding application server may need to request or collect information (e.g., assistance information) from the 5GC NFs, user equipments (UEs), OAMs etc. Particularly, for the Al/ML operations involving a list/number of UEs (e.g., federated learning operations), the application server may need to determine the candidate UE(s) and schedule the ALJML operation based on the information (i.e., the assistance information) from the 5GC. The information may include one or more of: the latencies including computation and/or transmission delay, the service quality of the UEs, the load and performance of the network, etc. The combination of the information on both the UE and the network (including RAN nodes, 5GC NFs, OAM5 etc.) may significantly impact the AF decision on organising and scheduling the Al/ML-based services.

[0061] Services are also being developed as part of 5G networks. Augmented reality (AR), virtual reality (VR) and mixed reality (MR) services (which may be referred to generally using the umbrella term for these services -extended reality (XR) services) are expected to be attractive use cases that will impose a set of challenges for 5G and beyond networks to provide stringent service requirements, as indicated in TS 22.261 [1]. Nevertheless, XR services have a set of traffic characteristics such as traffic periodicity, data burst arrival time, jitter, etc. that may be useful to improve network efficiency by means of resource utilization and/or power consumption.

[0062] 5G NR evaluations for XR and media (XRM) traffic characteristics have been studied in 3GPP Release 17 as RANI study item, and further enhancements on Radio Access Network, RAN, (e.g., working group RAN2) and Systems Aspects, SA, (e.g., SA2 (system architecture and services) -FS_XRM) are currently being studied in 3GPP Release 18. The noted studies have one objective that is to study XR-specific power saving/management techniques to accommodate XRM service/traffic characteristics including periodicity/pattern, jitter, latency, reliability, etc. [0063] In the present disclosure, the term "latency" is used to represent conventional packet delay as well as any delay that occurs due to service operation/computation, e.g., AI/ML training and inference. Therefore, in the present disclosure, the term latency is used interchangeably with delay, packet delay, service operation delay, computing delay, processing delay etc. In various examples, transmission delay or transmission latency may be termed end-to-end volume transfer time. The end-to-end volume transfer time may refer to a time delay for completing the transmission of a specific data volume from UE to AF, or from AF to UE; i.e., more generally, to transmission delay. Further, end-to-end volume transfer time analytics may be regarded as latency performance analytics, statistics and predictions relating to latency performance, including transmission/packet delay and/or processing delay related analysis etc. [0064] Above, it is noted that few NWDAF-based analytics consider delay information as an input data and that few analytics consider delay as part of their output statistics.

For example:

- In Data Network Performance Analytics, end-to-end (E2E) delay between an application server and UE is noted as part of input and output information where the E2E delay information is provided by an application function (AF) as average and maximum packet delay values, and the statistics are provided separately for average packet delay and maximum packet delay; - In Observed Service Experience Analytics, QoS flow Packet Delay (uplink (UL) and downlink (DL)) provided by user plane function (UPF) and E2E delay provided by an AF are noted as input data; - In Redundant Transmission Experience Analytics, UL/DL packet delay measurement round trip on GRPS tunnelling protocol (GTP) path on N3 is considered as an input as well as output data where, for the output data, predicted UL/DL packet delay round trip on GTP-U path on N3 interface is provided as average and variance.

[0065] In addition to the above analytics, there are other NWDAF-based analytics that focus on service experience and/or performance, such as UE Communication Analytics and QoS Sustainability Analytics. However, these two analytics do not specifically consider delay performance.

- In QoS Sustainability Analytics, the average UE bitrate and number of abnormally released Quality of Service (QoS) flows per timeslot, per cell, per 5G QoS Identifier (5QI) and per Single Network Slice Selection Assistance Information (S-NSSAI) are considered as input information to obtain QoS sustainability statistics.

- In UE Communication Analytics, service data from various 5GC network functions such as SMF, AF, UPF and AMF on UL/DL data rate, communication start/stop time, UE location Protocol Data Unit (PDU) session status, etc. are considered as input information to obtain UE communication statistics including interval time of periodic communication (average and variance), start time, duration, traffic volume and/or application details. The obtained UE communication statistics may then be used to optimize mobility management, traffic routing handling, QoS improvement or inactivity timer optimization.

[0066] Some of the aforementioned NWDAF-based analytics may provide some assistance information to an AI/ML application and/or XRM services. However, a number of issues exist for the current framework/methods.

[0067] For example, for AI/ML operation(s), the latency performance of model training, inference and model transfer cannot be provided to the AF from 5GC currently. For example, for federated learning, the application server may need to train the AI/ML model based on the models trained and sent by multiple UEs. If the variance of the model training and transfer latency among those UEs is relatively high, the AI/ML application may need to either wait for the further training and inference process, which may result in postponing the model update, or generate the aggregated model with lower input parameters than initially planned, which may lower the service quality (e.g., the accuracy of the Al/ML-based services) significantly. Without knowing the processing and transmission latency performance of the network and the UE(s), it will be difficult for the AF to provide the Al/ML-based service efficiently.

[0068] As another example, for the XRM services, the traffic characteristics of XRM services (for example, or more specifically, packet delay distribution or jitter information, and periodicity) cannot be provided to the AF from 5GC currently. For example, connected mode Discontinuous Reception (CDRX) procedure has been used to send packets to UE in a pre-configured time duration ("ON" time) and let UE to get into sleep mode ("OFF" time) for a certain period of time to reduce power consumption at the UE. Otherwise, UE has to be in listening mode even if there is no active transmission to the UE. With the introduction of XRM services, the traffic pattern/periodicity and the jitter statistics of the XRM services can be used to improve CDRX configuration. As jitter and periodicity would have an impact on RAN power saving configurations (e.g., CDRX, PDCCH monitoring, etc.), the jitter/periodicity statistics could help RAN to optimize the existing configurations to improve power saving.

[0069] Accordingly, it is an aim of certain embodiments of the present disclosure to provide methods, apparatus and systems for addressing the above-identified and related issues. For example, certain embodiments of the present disclosure aim to provide information on the processing and transmission latency performance of the network and/or UE(s) to a service consumer to allow or facilitate the service consumer providing an AI/ML based service more efficiently. For example, certain embodiments define a new NWDAF-based analytics to provide an AF, which is providing an Al/ML-based service with such information. As another example, certain embodiments of the present disclosure aim to provide a service consumer with information on jitter and/or periodicity statistics to allow or facilitate optimization of configurations to improve power saving. For example, a new NWDAF may be provided to help RAN optimize existing configurations used for an XRM service to improve power saving.

[0070] In general, in order to assist the application servers, RAN and 5GC N Fs to organise and schedule the services operation and to decide on specific configurations such as CDRX, and/or in order to improve the service quality, customer experiences and/or network performance, certain embodiments of the present disclosure introduce new NWDAF-based statistics and predictions relating to latency performance, including transmission/packet delay and/or processing delay related analysis. In particular, certain examples herein provide new NWDAF-based analytics, including latency performance related analytics. The new analytics are fully specified by detailing the function of the analytics, the corresponding request information from the (service) consumer, the filter information, the input data, the output analytics and/or the procedures. For example: - UE delay/latency performance analytics are described, to optimize the performance of both Al/ML-based and XRM services.

- Options to collect latency related data using QoS monitoring feature and/or timestamp information are described, such as: * UPF to derive packet delay distribution/jitter information (and to provide the derived information to the NWDAF (e.g., directly or via SMF)); * The NWDAF triggering SMF or UPF to monitor and report data for analytics; and * The NWDAF subscribing to a new SMF or UPF event to collect the data.

Thresholds and/or range and/or distribution of latency can be provided as part of Analytics Filter Information to request latency performance if there are UEs that meet certain criteria. Thresholds may indicate conditions on the level of each requested analytics that, when reached, shall be notified by the NWDAF; e.g. NWDAF may provide the percentage of UEs that have reached certain Reporting Threshold(s).Thresholds may also be used to determine latency classes (see below).

- Latency class (e.g., low, medium, high) may be provided; for example, latency class may be pre-configured or thresholds provided, e.g., from the AF, may be used by NWDAF to provide UEs in each latency class.

- Output analytics may provide processed data for UEs in each latency class in the form of statistics and/or predictions.

[0071] More detailed explanation and examples of the above are now presented.

[0072] The following generally considers that a NWDAF is provided to derive the UE latency performance related analytics, and so uses the example of an NWDAF. However, it will be appreciated that other network entities (e.g., NFs, AFs etc.) may be configured to derive requested latency performance related analytics, and so the concepts disclosed herein in relation to an NWDAF may apply to said other network entities also.

[0073] Certain examples of the present disclosure introduce new NWDAF analytics to provide the statistics and predictions of latency performance of a single UE and/or a number/list of U Es. More specifically, various examples cover NWDAF-based latency analytics for AI/ML and XRM services.

[0074] Considering the nature of AI/ML operation, 1) modelling training, 2) inference, 3) transfer of the AI/ML models and output of inference will each create latency for the Al/ML-based services. In certain embodiments of this disclosure, the latency performance analytics may refer to the latency performance statistics and/or predictions of any combination of 1), 2) and 3) (together or in isolation; e.g., 1) alone, 3) alone, or a combination of 1) and 3)), or to the latency created by other (Al/ML related) procedures.

[0075] Considering XRM traffic characteristics, packet delay distribution/jitter will be affected from delays occurring on the i) access network (RAN/Uu interface), h) core network (N3/N9 interface) and iii) transport network (N6 interface). In certain embodiments of this disclosure, the latency performance analytics may refer to the latency performance statistics and predictions of any combination of 1), 2) and 3) (together or in isolation; e.g., 1) alone, 3) alone, or a combination of 1) and 3)) or the latency created by other procedures such as media codec generation at a XRM server.

[0076] In general, the NWDAF may not be required to be aware of the AI/ML operation, XRM service or traffic type. Of course, in certain examples, the NWDAF may be aware of the AI/ML operation, XRM service or traffic type.

[0077] In certain embodiments, in relation to data collection by the NWDAF for latency performance statistics and/or predictions, the NWDAF may collect service data from one or more of AF, SMF, UPF, AMF, PCF, and OAM etc. [0078] In certain embodiments herein, a service consumer (as may be referred to) may be an AF, any 5GC NF (e.g. NEF, the NF for Al/ML operation, SMF, PCF), the OAM, or any other network entity (e.g., network entity suitable to be a service consumer).

[0079] According to certain examples, the NWDAF may provide the latency performance related data of a single UE or a plurality/list of UEs based on information provided by the AFs, NFs and/or OAM, such as (but not limited to): the size of the AI/ML model to be trained or transferred, periodicity and/or data burst volume of XRM traffic, QoS related information (e.g., 5Q1 or the unspecified/ pre-defined values, QoS Flow Identifier (ID) (QFI) etc.), and/or the existing measurements (e.g., the latency performance related data including packet delay, UE behaviours related to model training and transfer, UE locations, data rate, inactivity time, etc.).

[0080] In certain embodiments, the NWDAF may be requested to provide one or more of the analytics by a service consumer. For example, the service consumer may send a request, to the NWDAF, which includes, indicates or specifies one or more of the following information or data: - Analytics ID, e.g., "UE Latency Performance" or other names.

Target of Analytics Reporting: e.g., a single UE (SUP!), or a group of UEs (e.g., an Internal/ External Group ID), or any UE, or application, or Data Network Name (DNN).

- An Analytics target period: e.g., the time period over which the statistics of the past or predictions of the future are requested.

- Analytics Filter Information including (the following information could be either mandatory or optional): * application ID, e.g., the application providing the AI/ML-based and/or XRM services and the related analytics filter information. Additionally/optionally, any other IDs related to the service, e.g., session ID, UE Group ID, DNN, etc. * Latency/jitter threshold, e.g., the latency of model training, model transfer, inference and/or results transfer; or packet delay distribution/jitter; or change value of latency/delay distribution/jitter. The Latency/jitter threshold could be for any combination of the above procedures and also other unlisted procedures. In some examples: * If the expected latency or packet delay distribution/jitter is below or above (or according to the matching direction configured) the threshold, notification is triggered (e.g., at the NWDAF) and a notification is sent to the service consumer; and/or * If the analytics is for a group of UEs, the threshold might refer to the average and/or the variance of the latency of a group of UEs.

* Latency and/or jitter classes: more than one latency/jitter classes; e.g., the latency/jitter classes might be categorised, for example into low-/ medium-/ high-latency/jitter. In some examples: * The thresholds of the latency/jitter classes might be pre-configured, e.g., by the operators, the application server of the service or analytics consumers. The 5GC NFs, AFs, UEs etc. may or may not have prior knowledge of the thresholds of each latency/jitter classes. The pre-configured values may be updated, e.g., by the operators or analytics consumers; and/or * The thresholds of the latency/jitter classes might be provided/ defined by the consumers, e.g., AFs or any other 5GC NFs (e.g. NEF, SMF, UPF, PCF), together with the definition latency/jitter classes.

* To give a non-limiting example of pre-configured or defined classes, it may be defined that, for medium-latency/jitter class, the latency/jitter is between 10 -20 ms, for the low-latency/jitter class, the latency/jitter is lower than 10 ms; and for the high-latency/jitter class, the latency/jitter is above 20 ms.

* It is noted that, in some examples, thresholds of the latency or jitter classes could be provided within Nnwdaf_AnalyticsSubscription_Subscribe or Nnwdaf_AnalyticsInfo_Reguest. The thresholds of the latency/jitter classes may be provided as a part of Analytics Filter Information or separately.

* Ratio or percentage of latency/jitter classes: e.g., this may be provided for a single UE or a group of UEs, or application, or DNN. In some examples: + This information (i.e., the ratio or percentage) could work in conjunction with the 'Latency/jitter classes'; * For a single UE, the thresholds of percentage (statistics in the past) / probability (predictions in the future) in the different latency/jitter class may be included. E.g., the latency/jitter classes may be categorised into low-/ medium-/ high-latency/jitter; and if the percentage/probability of the UE in a certain class is below or above (or according to the matching direction configured, e.g., the matching direction may be below, above or crossed; in certain examples, if no matching direction is provided or configured, the default matching direction is crossed) a/the threshold, notification is triggered and sent to the consumer; * For a group of UEs, the thresholds ratio/percentage of UEs in different latency/jitter classes are included. E.g., the latency/jitter classes are categorised into low-/ medium-/ high-latency/jitter; and if the ratio/percentage of the UEs in a certain class is below or above (or according to the matching direction configured) a/the threshold, notification is triggered and sent to the consumer; * For an application, the thresholds of percentage (statistics in the past)/probability (predictions in the future) in the different latency/jitter class are included. E.g., the latency/jitter classes are categorised into low-/ medium-/ high-latency/jitter; and if the percentage/ probability of the application in a certain class is below or above (or according to the matching direction configured) the threshold, notification is triggered and sent to the consumer; and/or * For a DNN, the thresholds of percentage (statistics in the past)/ probability (predictions in the future) in the different latency/jitter class. E.g., the latency/jitter classes are categorised into low-/ medium-/ high-latency/jitter; and if the percentage/ probability of the DNN in a certain class is below or above (or according to the matching direction configured) the threshold, notification is triggered and sent to the consumer.

* Location information / Area of Interest: e.g., an area or a path of interest focused on by this analytics. The Area of Interest might be list of tracking area (TA). cells, beam coverage area etc. * DNN, S-NSSAI, etc. - Reporting Threshold(s): e.g., the level to be reached for reporting the analytics. In some examples: * A matching direction may be provided, such as the threshold being crossed (e.g., a default value), or such as being below or above threshold.

* Latency/jitter threshold (details of these/corresponding thresholds are given above).

* Ratio/percentage threshold (details of these/corresponding thresholds are given above) - Preferred order of statistics or predictions of the latency performance related analytics. In some examples: * Ordering criterion may be included/specified: e.g., "latency" or "model size", or "traffic volume", or "number of iteration", or "jitter" or "traffic periodicity" * Order may be included/specified: ascending or descending order.

[0081] It will be appreciated that the present disclosure includes each and every combination of the above list of features that the consumer may include or otherwise indicate in the request for analytics.

[0082] Input Data [0083] The NWDAF may collect data from the NFs (and/or other sources, as described above) as the input data for latency performance related statistics and/or predictions. For example, this may be triggered by receiving a request for analytics from a consumer (such as detailed above), or the NWDAF may be configured to periodically collect the data (other causes of data collection are also considered herein -these examples are not intended to be limiting).

[0084] There now follows a list of data/information, one or more of which may be collected or obtained, by the NWDAF, from the NFs and AFs (or other sources -note that the indication of a source for each information should be considered non-limiting, it may be possible for the information to be collected from other sources to those listed): - UE identifier (ID) or a list of UE IDs -this may be collected from SMF and/or AF. This information may identify a UE. This information may, in some examples, be a (a list of) subscription permanent identifier(s) (e.g., SUPI(s)) in the case of SMF), or (a list of) external UE ID(s) (e.g., generic public subscription identifier (GPSI)) in the case of AF.

-Group ID -this may be collected from SMF and/or AF. This information may be for identifying a/the UE group, if available. For example, this information may be an Internal Group ID in the case of SMF, or an External Group ID in the case of AF. Also, the Group ID may be related to AI/ML session ID that indicates a list of UEs for the Al/ML operation/Al/ML-based services.

Application ID -this may be collected from SMF and/or AF. This information may identify the application providing the information (e.g., the application providing all information obtained from the SMF or AF, or the application providing the other information collected by the NWDAF).

S-NSSAI -this may be collected from SMF. This information may identify a network slice (NS).

DNN -this may be collected from SMF. This information may indicate the data network name where PDU connectivity service is provided.

Area of Interest (A01) / Location information -this may be collected from AF and/or AMF. This information may be the A01 of the location of the UE(s) focused on (i.e., relating to, or the subject of) this analytics.

Model size -this may be collected from AF. This information may indicate the size of the model to be trained and/or transferred.

Traffic volume -this may be collected from AF. This information may indicate the traffic volume of the service (e.g., the Al/ML service, or a service provided by the consumer). For example, the information may include one or more of the following: transfer of AI/ML model, inference results, and any other related traffic or signalling.

Number of iterations -this may be collected from AF. This information may indicate a number of iterations for AI/ML model training.

Training time -this may be collected from AF. This information may indicate the time spent Al/ML operation (see also Table 2 below for additional examples) -this may be collected from AF, UPF and/or SMF. This may correspond to AI/ML service-specific data. This information may, for example, indicate time stamps of the corresponding AI/ML operation procedures, e.g., model training start/stop, model transfer start/stop etc. For example, AI/ML operation information may include or indicate one or more of the following: * model training start -an example of this is the time stamp that the model training starts; * model transfer start -an example of this is the time stamp that the model transfer starts; * inference start -an example of this is the time stamp that the model inference starts; * model training stop -an example of this is the time stamp that the model training stops; * model transfer stop -an example of this is the time stamp that the model transfer stops; * inference stop -an example of this is the time stamp that the model inference stops.

Traffic rate related service data (see also Table 3 below for additional examples) -this may be collected from SMF, UPF or AF (optionally depending on specific information being collected). This information may indicate or include measurements related to data rate of the Al/ML operation, e.g., the measurements for QoS monitoring etc. For example, this information may generally be the traffic rate related service data collected from AFs or 5GC NF(s) such as the SMF or UPF. For example, the traffic rate related service data may include one of more of: * QFI (may be collected from SMF or AF), e.g., the QFI corresponds to the QoS flow of Al/ML traffic or Al/ML-based service related data.

* Bit rate (may be collected from SMF, UPF or AF), e.g., the observed bit rate for UL, DL and/or round trip direction. For example, the Bit rate may include or indicate: * UL bit rate, such as the UL bit rate for a QoS Flow PDU session, * DL bit rate, such as the DL bit rate for a QoS Flow PDU session, and/or * round trip bit rate, such as the bit rate of the UL and DL direction for a QoS Flow PDU session.

* Packet delay (may be collected by SMF, UPF or AF), e.g., the observed packet delay for UL, DL and/or round trip direction. For example, the Packet delay may include or indicate: * UP packet delay, such as End to end UL packet delay measurement between UE and PSA UPF for a QoS Flow PDU session.

* DL packet delay, such as end to end DL packet delay measurement between UE and PSA UPF for a QoS Flow or a PDU session * round trip packet delay, such as round trip packet delay measurement between UE and PSA UPF for a QoS Flow or a PDU session.

* Packet transmission (may be collected from SMF or UPF), such as the observed number of packet transmission.

* Packet retransmission (may be collected from SMF or UPF), such as the observed number of packet retransmission.

* Timestamp (may be collected from SMF or UPF), such as a time stamp associated with the collected information (e.g., any of the collected traffic related service data).

* UL data rate (may be collected by SMF, UPF or AF), such as UL data rate of the communication (e.g., Al/ML model transfer).

* DL data rate (may be collected by SMF, UPF or AF), such as DL data rate of the communication (e.g., the Al/ML model transfer).

* Communication start (may be collected by SMF, UPF or AF), such as the time stamp that the communication (e.g., the Al/ML model transfer) starts.

* Communication stop (may be collected by SMF, UPF or AF), such as the time stamp that the communication (e.g., the Al/ML model transfer) stops.

XR and Media service-specific data -this may be collected from SMF, UPF, AR or other NF (see also Table 4 below for additional examples). This information/data may be for latency performance related statistics and predictions specific to XRM service. In some examples, this information may include one or more of: * OH (may be collected from SMF), the QoS Flow Identifier.

* QoS flow Bit Rate (may be collected from UPF), such as the observed bit rate for UL direction and the observed bit rate for DL direction.

* QoS flow Packet Delay (may be collected from UPF), such as the observed Packet delay for UL direction and the observed Packet delay for the DL direction. The observed Packet delay measurements may include N3 delay, N6 delay and E2E delay.

* N6 delay (may be collected from UPF), such as observed Packet delay at N6 interface between UPF and AF/DNN/AS.

* Performance data (may be collected from AF), such as the performance associated with the communication session of the UE with an Application Server that includes: Average Packet Delay, Average Loss Rate and/or Throughput.

* QoS flow Packet Delay Distribution (may be collected from UPF), such as the observed Packet delay distribution (mean, minimum, maximum and/or variance) over a time window for UL direction, and the observed Packet delay distribution (mean, minimum, maximum and/or variance) over a time window for DL direction. The observed Packet delay distribution includes N3 delay for UL/DL and E2E delay (between UPF and UE).

* ULJDL Data Burst Volume (may be collected from UPF or AF), such as ULJDL data traffic volume measurement per application/per PDU set.

* UL/DL Burst Arrival Time Periodicity (may be collected from UPF or AF), such as ULJDL burst data arrival time periodicity measurement per application/per PDU set.

* ULJDL packet delay GTP (may be collected from OAM -see TS 28.552 [4], Note 1 below), such as UL/DL packet delay measurement round trip on GTP path on N3.

* Distribution of UL/DL GTP packet delay between PSA UPF and NG-RAN (may be collected from OAM -see TS 28.552 [4], Note 1 below), such as the distribution of UL/DL GTP packet delay between PSA UPF and NG-RAN.

* Distribution of UL/DL packet delay between PSA UPF and UE (may be collected from OAM -see TS 28.552 [4], Note 1 below), such as the distribution of UL/DL packet delay between PSA UPF and UE.

* Distribution of round-trip N3 delay on UPF (may be collected from OAM -see TS 28.552 [4], Note 1 below), such as the distribution of round-trip delay on a N3 interface on PSA UPF.

* Distribution of round-trip packet between UPF and NG-IRAN (may be collected from OAM -see TS 28.552 [4], Note 1 below), such as the distribution of round-trip GTP packet delay between PSA UPF and NG-RAN.

* Note 1: The data collected from OAM can be represented as a single entry, e.g., "Delay Measurements", and the noted OAM measurement can be collected all together as part of this single input entry.

- UE locations -this may be collected from AMF and/or AF. This information may include UE locations for (1,...,max) number of UEs. This information may indicate UE positions. For example, the NWDAF may use the UE locations to derive A01, and the information may be associated with QoS. In some examples, this information may include: * UE location, e.g.,, tracking area (TA), cells, beam areas and/or A01 that the UE enters or is in; and * Timestamp, e.g., a time stamp when the UE location was measured.

[0085] Note that for all of the above examples of information, the source from which the data/information is collected or obtained is not limited to the indicated sources. That is, where a source (such as UPF, SMF or AF) is indicated, this is intended to provide an illustrative example but not to limit the information to being provided by this source. It will be appreciated that the information may be collected from other sources or a combination of sources.

[0086] Additionally, for cases of a group of UEs, it will be appreciated that information relating to measurements, as indicated in the examples above, may be provided as an average and/or variance of the measurements of the UEs in the group (or a subset of the UEs in the group).

[0087] As a general comment, it will be appreciated that certain input data (and output data, as evident from the below) may be used for either or both Al/ML-based services and XRM-based services.

[0088] Table 1 illustrates an example of service data/information collected from 5GC NFs and AFs according to the present disclosure:

[0089] Table 1

Information Source(s) Description

UE ID or list of UE IDs SMF, AF (a list of) SUPT(s) in the case of SMF, (a list of) external UE 1D(s) (i.e. GPSI) in the case of AF Group ID SMF, AF To identify UE group if available Internal Group ID in the case of SMF, External Group ID in the case of AF The Group ID might be related to AIML session ID that indicates a list of UEs for the AIML operation/ AIMLbased services.

Application ID SMF, AF Identifying the application providing this information S-NSSAI SMF Information to identify a Network Slice DNN SMF Data Network Name where PDU connectivity service is provided Area of Interest / Location information AF, Min. The AOI or the location of the UE(s) focused on by this analy tics model size AF The size of the model to be trained or transferred Traffic volume AF Traffic volume of the service, i.e. including one or more of the following: transfer of AIML model, inference results, and any other related traffic/ signalling.

number of iterations AF number of iterations for AIML model training Training time AF The time spent for training, the model associated to the model size and [optionally] the number of iterations.

AIML operation (details in Error! Reference source not found. ) AF Time stamps of the corresponding A1ML operation procedures, i.e. model training start/stop, model transfer start/stop etc. Traffic rate related service data AF Measurements related to data rate of the AIML operation, i.e. the measurements for QoS monitoring etc. (details in Error! Reference source not found. ) UE locations (1..max) AMA, AF UE positions. NWDAF can use the UE locations to derive the Area of Interest, associated with QoS?? >UE location TA, cells, beam areas or area of interest that the UE enters >Timestamp A time stamp when UE location was measured [0090] Table 2, showing examples of Al/ML Service-specific Data, is as follows: [0091] Table 2

Information Source(s) Description

AI/ML operation AF May also be UPF, SMF > model training start The time stamp that the model training starts > model transfer start The time stamp Lhal the model transfer starts > inference start The time stamp that the model inference starts > model training stop The time stamp that the model training stops > model transfer stop The time stamp that the model transfer stops > inference stop The time stamp that the model inference stops [0092] Table 3, showing examples of traffic rate related service data, is as follows:

[0093] Table 3

Information Source(s) Description

Traffic rate related service data The traffic rate related service data collected from AFs or 5GC NF(s), i.e. SMF or UPF.

> QF1 SMF or AF QoS Flow Identifier.

The QFI corresponds to the QoS flow of AI/ML traffic or AI/ML-based service related data > Bit Rate SMF or UPF or AF The observed hit rate for UL, DL and round trip direction. direction >> UL Bit Rate UL Bit Rate for a QoS Flow or a PDU session.

» DL Bit Rate DL Bit Rate for a QoS Flow or a PDU session.

>> round trip Bit Rate Bit Rate of the UL and DL direction for a QoS Flow or a PDU session.

> Packet Delay SMF or UPF or AF The observed Packet delay for UL, DL and round trip direction.

>> UL packet delay End to end UL packer delay measurement between UE and PSA UPF for a QoS Flow or a PDL session.

» DL packet delay End to end DL packet delay measurement between UE and PSA UPF for a QoS Flow or a PDU session.

>> round trip packet delay Round trip packet delay measurement between UE and PSA UPF for a QoS Flow or a PDU session.

>Packet transmission SMF or UPF The observed number of packet transmission.

>Packet SMF or UPF The observed number of packet retransmission.

retransmission >Timestamp SMF or UPF A time stamp associated with the collected information.

>UL data rate SMF, UPF, AF UL data rate of this (AI/ML model transfer) communication >DL data rale SMF, UPF, AF DL data rale of this (AT/ML model transfer) co mmun ica lion >Conununicaticm start SMF, UPF, AF The lime stamp that this communication starts >Communication slop SMF, UPF, AF The lime stamp that this communication stops [0094] Table 4, showing examples of service data related to XRM service, is as follows: [0095] Table 4

Information Source(s) Description

XRM Service > QF1 SMF QoS Flow Identifier.

> QoS flow Bit Rate UPF The observed bit rate for UL direction; and The observed bit rate for DL direction.

> QoS flow Packet Delay UPF The observed Packet delay for UL direction; and The observed Packet delay for the DL direction. The observed Packet delay measurements include N3 delay, N6 delay and E2E delay.

> N6 delay UPF The observed Packet delay at N6 interface between UPF and AF/DNN/AS.

> Performance Data AF The performance associated with the communication session of the UE wilh an Application Server that includes: Average Packet Delay, Average Loss Rate and Throughput.

> QoS flow Packet Delay Distribution UPF The observed Packet delay distribution (mean, minimum, maximum and variance) over a lime window for UL direction; and The observed Packet delay distribution (mean, minimum, maximum and variance) over a lime window for DL direction. The observed Packet delay distribution includes N3 delay for UL/DL and E2E delay (between UPF and UE).

> UL/DL Data Burst Volume UPF/AF UL/DL data traffic volume measurement per application/per PDU set.

> UL/DL Burst Arrival Time Periodicity UPF/AF UL/DL burst data arrival Lime periodicity measurement per application/per PDU set.

> UL/DL packet. delay GTP OAM UL/DL packet delay measurement round trip on GTP path on N3.

TS 28.552 (NOTE 1) > Distribution of UL/DL GTP packet delay between PSA UPF and NG-RAN OAM The distribution of UL/DL GTP packet delay between PSA UPF and NC-RAN.

TS 28.552 (NOTE 1) > Distribution of UL/DL packet delay between PSA UPF and UE OM The distribution of UL/DL packet delay between PSA UPF and UE.

TS 2A8 55 2 (NOTE 1) > Distribution of round-trip N3 delay on UPF OAM The distribution of round-hip delay on a N3 interface on PSA UPF.

TS 28.552 (NOTE 1) > Distribution of round-trip packet between UPF and NG-RAN OAM The distribution of round-trip GTP packet delay between PSA UPF and NG-RAN.

TS 28552 (NOTE 1) NOTE 1: The data collected from OAM can be represented as a single entry, e.g., "Delay Measurements" and the noted OAM measurement can be collected all together as part of this single input entry.

[0096] It will be appreciated that the input data may include any combination of one or more of the parameters/data/information/attributes shown in Tables 1, 2, 3 and 4 [0097] In certain embodiments, the NWDAF may collect or obtain the service data related to the data rate for latency performance related analytics corresponding to the Al/ML operation indicated above (that is, the information that may indicate time stamps of the corresponding Al/ML operation procedures). For example, the NWDAF may use the ULJDL data rate, the ULJDL/RTT (round trip) delay or the QoS flow bit rate and the QoS flow packet delay to determine or predict the transmission latency of the Al/ML model(s).

[0098] In certain embodiments, to collect or obtain the service data related to the data rate for latency performance related analytics corresponding to the Al/ML operation indicated above, the NWDAF may be configured to subscribe to the UPF to collect the data. If the NWDAF cannot subscribe to the UPF directly, some of the data may be collected from the SMF; for example, the UPF may report/notify the measurements (e.g., the data) to the SMF via N4 session, and the NWDAF may collect the data from the SMF.

[0099] It will be appreciated that the input information/data may be any combination of the examples given above. That is, the present disclosure should be seen to include each and every combination of the input data examples/types indicated above.

[00100] It will be appreciated that further examples of input information may be in accordance with any one or more (e.g. any combination of) the following: * a timestamp associated with part or all of the collected input information (e.g., any one or combination of the following examples of input information), where the timestamp may be obtained from a 5GC NF * UE location, which may be obtained from AMF or GMLC, where the location of the UE(s) may need to be selected via AMF if the application needs to be started at the same time. If the UE location (e.g., an area of interest, Aol) indicated by the AF is a finer granularity area than the Cell level, the current location of the UE(s) needs to be selected via GMLC instead.

* UE ID(s), which may be a SUPI or a list of SUPIs, and which may be obtained from AMF.

* QoS flow packet delay, which may be the observed packet delay for UL/DL/round trip directions, and which may be obtained from SMF or UPF.

* a timestamp, which may be the timestamp of the collected input information, or a part thereof, and which may be obtained from an AF.

* an application ID, which may be an identifier of the application at an AF, and which may be obtained from an/the same AF.

* UE ID(s), which may be internal ID(s) (e.g. SUP!) or external ID(s) (e.g. GPSI), and which may be obtained from an AF.

* transmitted data volume, which may be the volume of the transmitted data (e.g., the data for which the analytics are requested), and which may be obtained from an AF.

* transmitted time duration, which may be the time duration (start and end time) needed for sending a volume of data (e.g., the transmitted data), and which may be obtained from an AF * In the above, each AF may be the same as any one or more of the other AFs or may be different to the other AFs.

[00101] Output Analytics [00102] Considering now the output analytics (e.g., the output of the NWDAF based on the input data), according to certain embodiments of the present disclosure the NWDAF supporting UE latency performance related analytics provides the analytics results to one or more consumers (e.g., one or more consumer NFs). The latency performance related statistics and prediction may be for a single UE or a group of UEs, or for another network entity/entities.

[00103] It will be appreciated that the statistics and/or predictions of the latency may be any combination of that caused by AI/ML model training, inference, model transfer or any other AI/ML related procedures.

[00104] Statistics [00105] Herein is described potential/example outputs of the statistics (i.e., statistic outputs) of the latency performance related analytics. It will be appreciated that the statistics may be for the performance in the past. Additionally, the statistics may relate to (i.e., be over, or reflective of) an analytics target period, if configured.

[00106] The NWDAF may output one or more of the following statistics or information relating thereto: -UE ID or list of UE IDs. For example, this may include or indicate (a list of) SUPI(s) in the case of SMF, or (a list of) external UE ID(s) (i.e. GPSI) in the case of AF.

Group ID. This information may be for identifying a/the UE group, if available. For example, this information may be an Internal Group ID in the case of SMF, or an External Group ID in the case of AF. Also, the Group ID may be related to AI/ML session ID that indicates a list of UEs for the AI/ML operation/Al/ML-based services.

-Latency. This may include or indicate statistics of the latency performance in the past, and may be provided as Latency (1,...,max) where "max" corresponds to the number of UEs in the list or group (i.e., for the case of a group of UEs). If the latency is for a single UE, (1,...,max) may be omitted. In certain examples, Latency (1,...,max) or Latency may include one or more of: * UE location, e.g., a list or number of UE locations in which the AI/ML operation/ Al/ML-based service provided.

* traffic volume and/or model size, e.g., may indicate the traffic volume of the service (e.g., the AI/ML service, or a service provided by the consumer) and/or the size of the model to be trained and/or transferred.

* application ID, e.g., identification of the application.

* DNN, e.g., data network name associated for Al/ML-based service.

* S-NSSAI, e.g., identification of the network slice used to access the application.

* UE latency performance (see Table 5 below for further detail/examples), e.g., statistics of the latency performance of a single UE or a list of UEs in the past. For example, this might be a list of latencies corresponding to different model size, iterations, UE locations, 501s, DNN, S-NSSAI, etc. which may also be included as part of output analytics. For example: * UE UL latency, e.g., the statistics of UE latency performance of UL direction.

* UE DL latency, e.g., the statistics of UE latency performance of DL direction.

* UE round trip latency, e.g., the statistics of UE latency performance of UL and DL direction.

* Delay distribution/jitter performance, e.g., the distribution of observed delay measurements including jitter performance.

[00107] For the "UE Latency performance" data mentioned above, the statistics of the latency performance could be one or more of the following (applying to UL, DL, and round trip performance): Certain value(s) of the corresponding measurements used for latency performance statistics. The measurements may be one or more of the parameters/data/information given above in relation to the input data, i.e. the bit rate, packet delay, data rate etc.. For example, the statistic might be the average value of the latency.

- Latency classes (as described in relation to the information/data indicated in the request from the consumer above): the statistics of the latency performance might be the latency class, e.g., low-/ medium-/ high-latency.

Ratio/percentage of latency classes (as described in relation to the information/data indicated in the request from the consumer above), where this may be implemented in conjunction with Latency classes. For example, * If for a single UE, the percentage of different latency classes; * If for a group UEs, the ratio of the UEs in different latency classes.

- The statistics of the Latency classes and ratio/percentage of latency classes might be categories to UL, DL, and round direction.

[00108] Further examples of "UE Latency performance" are given in Table 5 below: [00109] Table 5

Information Description

Aggregate latency performance > Aggregate UL/DL/round trip packet delay Aggregated statistical value of the corresponding UE latency statistics (e.g. average, variance).

> Latency classes The statistics of the latency performance for a single UE of a group of the UEs.

latency performance in the UL, DL and round trip direction.

If Latency classes is used separately (without the Ratio/ percentage of latency classes): the statistics could he one of the latency class, i.e. low-/ medium-/ high-latency based on definition. The outcome could be the latency class with highest ratio/ percentage.

i.e., the output of the statistics is low-latency > Ratio/ percentage of latency classes in the UL, DL and round trip direction.

>> low-latency Aggregate statistics for low-latency UEs (e.g. average, variance) >> medium-latency Aggregate statistics for medium-latency UEs (e.g. average, variance) >> high-latency Aggregate statistics for high-latency UEs (e.g. average, variance) [00110] Referring to Table 5, it will be appreciated that the "Aggregate latency performance" information may include one or more of "Aggregate UL/DL/round trip packet delay", "Latency classes", "Ratio/percentage of latency classes", "low-latency", "medium-latency", and "high-latency".

[00111] Additional examples of statistics of the latency performance related analytics for a group of UEs are given in Table 6 below:

[00112] Table 6

Information Description

Latency performance One, or more than one, of the following lists (SUPI and GPSI could be used to identify the UEs).

A list of UEs experience different latencies in the past / over the Analylics target period if configured.

> List of low-latency UES A list of UEs whose experience low latency for specific DNN, SNSSAI, or Application ID.

> LisL of medium-la tency UEs A list of UEs whose experience medium latency for specific DNN, 5-NSSAI, or Application ID.

> List of high-latency UES A list of UEs whose experience high latency for specific DNN, SNSSAI, or Application ID.

> latency of the group of UEs average and variance values of the latency > maximum latency of the UEs The maximum latency of the UEs in this group/list >> UE ID » latency > minimum latency of the UEs The minimum latency of the UEs in this group/list >> UE ID >> latency > Validity period Validity period for the latency performance related analytics [00113] It will be appreciated that "UE Latency performance" information may include one or more of the more specific information types or attributes listed in Table 6.

[00114] In case of XRM-specific service, the statistics given in the example shown in Table 7 below can be considered:

[00115] Table 7

Information Description

UE group ID or UE ID Identifies a UE or a group of UEs, e.g. internal group ID defined in TS 23.501 clause 5.9.7 or SUPT.

Application ID Identifies the application for which analytics information is provided.

DNN Identifies the data network name (e.g. "internet") for which analytics information is provided.

Serving anchor UPF info The UPF 1D/address/FQDN information for ale involved anchor UPF/PSA UPF.

XR and media traffic characteristics > Data Burst Periodicity Periodicity of the PDU set > Data Burst volume Sum of the traffic volume of PDUs in a PDU set > Average PDU set size The average PDU set size in bits/number of PDUs in a PDU set > Jitter range The maximum and minimum value of jiller/delay distribution > Jitter information Mean and variance of delay distribution > Maximum Packet Delay The maximum packet delay predicted among PDUs in a PDU set > Spatial validity A list of Cell IDs that the analylics are valid > Validity period The lime period that the analylics are valid > Average PDU set error rate The average PDU set error rate > Average PDU set delay The average PDU set delay [00116] It will be appreciated that XRM-specific service information/statistics may include one or more of the more specific information types or attributes listed in Table 7.

[00117] Note that, in these tables (and other tables in the present disclosure), the notation 5' and 5>' is used to indicate that the corresponding entry in the table relates to a previous entry in the table, e.g., a subset/attribute of that previous entry. For instance, referring to Table 6, the 'Jitter range" may be regarded as an attribute of "XR and media traffic characteristics" data; and, referring to Table 4, "low-latency", "medium-latency" and "high-latency" may be regarded as examples of "Latency classes" or types of data related to "Ratio/ percentage of latency classes".

[00118] In another embodiment, the following UE latency performance statistics can be provided as in Table 8 below:

[00119] Table 8

Information Description

UE ID or list of UE IDs or Group ID Identifies a UE or a group of UEs.

UE latency performance (1... max) List of observed UE latencies.

Max. is the number of UEs, if applicable.

> Application ID Identification of the Application.

> UE location Indicating the UE location information when the UE service is delivered.

> DNAI Indicating which DNAI the UE service uses/camps on.

> DNN DNN for the PDU Session which contains the QoS flow.

> S-NSSAI Identifies the Network Slice used to access the Application.

> Model size The average size of the application A/ML model(s) to be trained or transferred.

> Number of iterations The number of iterations for application AI/ML model training.

> Validity period The validity period for the UE latency performance statistics as defined in clause 6.1.3 of TS 23.288 [2].

> Spatial validity Area where the UE latency performance statistics applies > UE Latency (NOTE 1) Statistics of UE latency performance over the Analytics target period (e.g. average, variance) for a single UE or a group of UEs.

» UE UL packet delay The UL packet delay for the UE >> UE DL packet delay The DL packet delay for the UE » UE round trip packet delay The round trip packet delay for the UE Aggregate latency performances (NOTE 1) Aggregated latency performance statistics for multiple UEs > Latency classes (1 max) (NOTE 2) List with group of UEs classified by ranges of latency performance » Ratio/percentage of UEs per latency class Percentage or ratio of UEs » Aggregate UL/DL/round trip packet delay per latency class Aggregated statistical values of the corresponding UE latency statistics in the latency class (e.g. average, variance).

> Validity period The validity period for the UE latency performance statistics as defined in clause 6.1.3 of TS 23.288 [2].

> Spatial validity Area where the UE latency performance statistics applies.

NOTE 1: This information element is an Analytics subset that can be used in "list of analytics subsets that are requested".

NOTE 2: The number of latency classes may be pre-configured by the operator or provided by the service consumer via reporting thresholds.

[00120] It will be appreciated that the UE latency performance statistics may include one or more of the specific information types or attributes listed in Table 8.

[00121] Predictions [00122] Herein is described potential/example outputs of predications (i.e., prediction outputs) of the latency performance related analytics. It will be appreciated that predictions may relate to predictions of performance. In some examples, such predications may relate to a target period (e.g., a specified period in the future), if configured.

[00123] The NWDAF may output predictions relating to one or more of the following information or types of data: UE ID or list of UE IDs. For example, this may include or indicate (a list of) SUPI(s) in the case of SMF, or (a list of) external UE ID(s) GPSI) in the case of AF.

- Group ID. This information may be for identifying a/the UE group, if available. For example, this information may be an Internal Group ID in the case of SMF, or an External Group ID in the case of AF. Also, the Group ID may be related to AI/ML session ID that indicates a list of UEs for the Al/ML operation/Al/ML-based services.

Latency. This may include or indicate estimated or predicted latency performance, and may be provided as Latency (1,...,max) where "max" corresponds to the number of UEs in the list or group (i.e., for the case of a group of UEs). If the latency is for a single UE, (1,...,max) may be omitted. In certain examples, Latency (1,...,max) or Latency may include one or more of: * UE location, e.g., a list of number of UE locations in which the AI/ML operation/ Al/ML-based service provided.

* traffic volume and/or model size, e.g., may indicate the traffic volume of the service (e.g., the Al/ML service, or a service provided by the consumer) and/or the size of the model to be trained and/or transferred.

* application ID, e.g., identification of the application.

* DNN, e.g., data network name associated for Al/ML-based service.

* S-NSSAI, e.g., identification of the network slice used to access the application.

* UE latency performance (see Table 9 below for further detail), e.g., estimated/predicated latency performance of a single UE or a list of UEs. For example, this might be a list of latencies corresponding to different model size, iterations, UE locations, 501s, DNN, S-NSSAI, etc. which may also be included as part of output analytics. For

example:

* UE UL latency, e.g., estimated/predicted UE latency performance of UL direction.

* UE DL latency, e.g., estimated/predicted UE latency performance of DL direction.

* UE round trip latency, e.g., estimated/predicted UE latency performance of UL and DL direction.

* Confidence, e.g., confidence of this prediction.

[00124] Table 9, providing further details and examples on "UE latency performance" (such as examples of prediction elements which may be included in the UE latency performance) is as follows:

[00125] Table 9

Information Description

Aggregate latency performance > Aggregate UL/DL/round trip packet dela v Aggregated value of the corresponding latency predictions (e.g. average, variance).

> Latency classes The statistics of the latency performance for a single UE of a group of the UEs.

latency performance in the UL, DL and round trip direction.

If Latency classes is used separately (without the Ratio/ percentage of latency classes): the statistics could be one of the latency class, i.e. low-/ mediu m-/ high-latency based on definition. The outcome could he Lhe latency class with highest ratio/ percentage.

i.e., the output of the statistics is low-latency > Ratio/ percentage of latency classes in the UL, DL and round trip direction.

>> low-latency Aggregate prediction for low-latency UEs (e.g. average, variance) » medium-latency Aggregate prediction for medium-latency UEs (e.g. average, variance) >> high-latency Aggregate prediction for high-latency UEs (e.g. average, variance) [00126] It will be appreciated that "Aggregate latency performance" information may include one or more of the more specific information types or attributes listed in

Table 9.

[00127] Additional examples of prediction elements or information of the latency performance related analytics for a group of UEs are given in Table 10 below:

[00128] Table 10

Information

Description

Latency performance Prediction of Lhe latency of a list of UEs.

One, or more than one, of the following lists (SUPT and GPSI could he used to identify the UEs).

> List of low-latency UEs A list of UEs.

Prediction of the UEs who experience low latency for specific DNN, SNSSAL or Application ID.

> List of medium-latency UEs A list of UEs.

Prediction of the UEs who experience medium latency for specific DNN, S-NSSAL or Application ID..

> List of high-latency UEs A list of UEs.

Prediction of the UEs who experience high latency for specific DNN, S-NSSAI, or Application ID.

> latency of the group of UEs average and variance values of the latency > maximum latency of the UEs The maximum latency of the UEs in this group/list >> UE ID >> latency > minimum latency of the UEs The minimum latency of the UEs in this group/list >> UE ID >> latency > Validity period Validity period for the latency performance related analytics [00129] It will be appreciated that "Latency performance" information may include one or more of the more specific information types, attributes or prediction elements listed in Table 10.

[00130] In another embodiment, the following UE latency performance predictions can be provided as in Table 11 below:

[00131] Table 11

Information Description

UE ID or list of UE IDs or Group ID Identifies a UE or a group of UEs.

UE latency performance (1... max) List of observed UE latencies.

Max. is the number of UEs, if applicable.

> Application ID Identification of the Application.

> UE location Indicating the UE location information when the UE service is delivered.

> DNAI Indicating which DNAI the UE service uses/camps on.

> DNN DNN for the PDU Session which contains the QoS flow.

> S-NSSAI Identifies the Network Slice used to access the Application.

> Model size The average size of the application A/ML model(s) to be trained or transferred.

> Number of iterations The number of iterations for application Al/ML model training.

> Validity period The validity period for the UE latency performance statistics as defined in clause 6.1.3 of TS 23.288 [2].

> Spatial validity Area where the UE latency performance statistics applies > UE Latency (NOTE 1) Predictions of UE latency performance over the Analytics target period (e.g. average, variance) for a single UE or a group of UEs.

>> UE UL packet delay The UL packet delay for the UE » UE DL packet delay The DL packet delay for the UE » UE round trip packet delay The round trip packet delay for the UE > Confidence Confidence of the prediction.

Aggregate latency performances (NOTE 1) Aggregated latency performance predictions for multiple UEs > Latency classes (1...max) (NOTE 2) List with group of UEs classified by ranges of latency performance » Ratio/percentage of UEs per latency class Percentage or ratio of UEs >> Aggregate UL/DL/round trip packet delay per latency class Aggregated statistical values of the corresponding UE latency statistics in the latency class (e.g. average, variance).

> Validity period The validity period for the UE latency performance statistics as defined in clause 6.1.3 of TS 23.288 [2].

> Spatial validity Area where the UE latency performance statistics applies.

> Confidence Confidence of the prediction.

NOTE 1: This information element is an Analytics subset that can be used in "list of analytics subsets that are requested".

NOTE 2: The number of latency classes may be pre-defined by the operator or provided by the service consumer via reporting thresholds.

[00132] It will be appreciated that the UE latency performance statistics may include one or more of the specific information types of attributes listed in Table 11.

[00133] It will also be appreciated that output analytics, e.g. statistics, may be in accordance with any one or more (e.g. any combination of) the following: * Time slot entry (1,...,max), which may be a list of time slots during the analytics target period, and which may include or relate to: o time slot start, which may be a time slot start within the analytics target period.

o duration, which may be the duration of the time slot.

* UE ID or a list of UE IDs (1,..., SUPImax), which may identify a UE or a group of UEs, e.g., a list of UEs for which the statistic applies.

* E2E data volume transfer times (1,...,max), which may be related to the UE ID(s), and which may be a list of E2E data volume transfer time (e.g., delay performance information) per UE (where "max" is the number of UEs, if applicable). E2E data volume transfer time may include or relate to one or more of: o E2E data volume transfer time UL, which may indicate statistics of E2E data volume transfer time for uplink over the analytics target period (e.g. average, variance).

o Data volume UL, which may indicate the uplink data volume used to derive the E2E data volume transfer time UL.

o E2E data volume transfer time DL, which may indicate statistics of E2E data volume transfer time for downlink over the analytics target period (e.g., average, variance).

o Data volume DL, which may indicate the downlink data volume used to derive the E2E data volume transfer time DL.

* Application ID, which may identify the application in use during the time slot.

* DNAI, which may be an identifier of a user plane access to one or more DN(s) where applications are deployed as defined in TS 23.501, and which may relate to the UE IDs or any of the above.

* UE location, which may be the UE location information when the UE service is delivered, and which may relate to the UE ID(s) or any of the above.

* DNN, which may be for the PDU session which contains the QoS flow, and which may relate to the UE ID(s) or any of the above.

* S-NSSAI, which may identify the network slice used to access the application, and which may relate to the UE ID(s) or any of the above.

* Validity period, which may be for the E2E data volume transfer time statistics.

* Spatial validity, which may be an area where the E2E data volume transfer time statistics applies.

* Classified E2E data volume transfer times (e.g., delay performance information) for a list of UEs, where this may be classified E2E data volume transfer time statistics for multiple UEs with respect to one or more reporting thresholds (e.g., NWDAF may provide the ratio of UEs that have reached certain reporting threshold(s)), where the list of UEs may be indicated in the request of the service consumer, and where classified E2E data volume transfer times for a list of UEs may be an analytics subset that can be used in "list of analytics subsets that are requested", "Preferred level of accuracy per analytics subset" and 'Reporting Thresholds". The Classified E2E data volume transfer times may include or relate to one or more of: o E2E data volume transfer time classes (1,...,max), which may be a list with group(s) of UE(s) classified by ranges of E2E data volume transfer time, and where the number of transfer time classes may be pre-configured by the operator or provided by the service consumer via reporting thresholds. The E2E data volume transfer time classes may include or relate to: * UE ID(s), which identify the UE(s) in the transfer time class with respect to the threshold of the corresponding transfer time class.

* Ration of UEs per E2E data volume transfer time class, which may be the ratio of UEs.

o Validity period, which may be the validity period for the E2E data volume transfer time statistics (e.g., the classified E2E data volume transfer times).

o Spatial validity condition, which may be an area where the E2E data volume transfer time analytics applies.

[00134] It will also be appreciated that output analytics, e.g. predictions, may be in accordance with any one or more (e.g. any combination of) the following: * Time slot entry (1,...,max), which may be a list of time slots during the analytics target period, and which may include or relate to: o time slot start, which may be a time slot start within the analytics target period.

o duration, which may be the duration of the time slot.

* UE ID or a list of UE IDs (1,..., SUPImax), which may identify a UE or a group of UEs, e.g., a list of UEs for which the statistic or prediction applies.

* E2E data volume transfer times (1,...,max), which may be related to the UE ID(s), and which may be a list of E2E data volume transfer time (e.g., delay performance information) per UE (where "max" is the number of UEs, if applicable). E2E data volume transfer time may include or relate to one or more of: o E2E data volume transfer time UL, which may indicate statistics of E2E data volume transfer time for uplink over the analytics target period (e.g. average, variance).

o Data volume UL, which may indicate the uplink data volume used to derive the E2E data volume transfer time UL.

o E2E data volume transfer time DL, which may indicate statistics of E2E data volume transfer time for downlink over the analytics target period (e.g., average, variance).

o Data volume DL, which may indicate the downlink data volume used to derive the E2E data volume transfer time DL.

* Application ID, which may identify the application in use during the time slot.

* DNAI, which may be an identifier of a user plane access to one or more DN(s) where applications are deployed as defined in TS 23.501, and which may relate to the UE IDs or any of the above.

* UE location, which may be the UE location information when the UE service is delivered, and which may relate to the UE ID(s) or any of the above.

* DNN, which may be for the PDU session which contains the QoS flow, and which may relate to the UE ID(s) or any of the above.

* S-NSSAI, which may identify the network slice used to access the application, and which may relate to the UE ID(s) or any of the above.

* Validity period, which may be for the E2E data volume transfer time predictions.

* Spatial validity, which may be an area where the E2E data volume transfer time predictions applies.

* Classified E2E data volume transfer times (e.g., delay performance information) for a list of UEs, where this may be classified E2E data volume transfer time statistics for multiple UEs with respect to one or more reporting thresholds (e.g., NWDAF may provide the ratio of UEs that have reached certain reporting threshold(s)), where the list of UEs may be indicated in the request of the service consumer, and where classified E2E data volume transfer times for a list of UEs may be an analytics subset that can be used in "list of analytics subsets that are requested", "Preferred level of accuracy per analytics subset" and "Reporting Thresholds". The Classified E2E data volume transfer times may include or relate to one or more of: o E2E data volume transfer time classes (1,...,max), which may be a list with group(s) of UE(s) classified by ranges of E2E data volume transfer time, and where the number of transfer time classes may be pre-configured by the operator or provided by the service consumer via reporting thresholds. The E2E data volume transfer time classes may include or relate to: * UE ID(s), which identify the UE(s) in the transfer time class with respect to the threshold of the corresponding transfer time class.

* Ration of UEs per E2E data volume transfer time class, which may be the ratio of UEs.

o Validity period, which may be the validity period for the E2E data volume transfer time prediction (e.g., the classified E2E data volume transfer times).

o Spatial validity condition, which may be an area where the E2E data volume transfer time analytics applies.

* Confidence, which may be a confidence, or indication thereof, of the prediction (e.g. any of the above example prediction(s)).

[00135] Utilizing Existing Analytics [00136] Part of the latency performance analytics described herein may be obtained as part of the existing analytics. Embodiments disclosed in this section describe modifications to the existing analytics input/output data specific to XR and media services. The same principle can also be used to expand the existing input/output data to incorporate Al/ML operation-specific parameters described in the previous sections.

[00137] There now follows a description of various embodiments of the present disclosure in which novel updates to existing analytics are indicated or disclosed. These embodiments make reference to various Tables found in TS 23.288 [2] and indicate updates to one or more of these Tables; it will be appreciated that only part of the referenced Table(s) may be shown, for brevity (i.e., a/the part of the referenced Table(s) which is not to be updated is omitted, but may easily be found in the referenced document TS 23.288 [2]).

[00138] Additionally, these embodiments may describe updates to the existing analytics in relation to new input data and corresponding new output data. It will be understood that certain input data is related to certain output data, such that it may not be necessary to make all of the modifications to the input data so as to collect a specific piece of output data. For example, if desired output data is QoS performance, it may not be necessary to modify the input data to include UL/DL packet delay GTP -the person skilled in the art will appreciate relationships between the disclosed input data and the disposed output data. As such, for each of the embodiments described below, it will be understood that further embodiments exist in which only a subset of the disclosed/shown modifications are made to the existing analytics. Various examples should therefore be considered in which each modification is made in isolation of any other modification, and also where each and every combination of any two or more modifications are made.

The person skilled in the art would understand that the combination of modifications will depend on what information is to be available to the NWDAF.

[00139] It will be appreciated that two or more of the following embodiments may be combined, for example so as to make use of the corresponding two or more of the existing analytics by updating these existing analytics as described.

[00140] As part of Observed Service Experience Analytics [00141] According to certain embodiments of the present disclosure, for the Observed Service Experience analytics, one or more of the following may be applied: -TS 23.288 [2], Table 6.4.2-2: QoS flow level Network Data from 5GC NF related to the QoS profile assigned for a particular service (identified by an Application Id or IP filter information), can be updated partly with the following (new) input data: QoS flow Packet Delay Distribution UPF The observed Packet delay distribution (mean, minimum, maximum and variance) over a Lime window for UL direction; and The observed Packet delay distribution (mean, minimum, maximum and variance) over a time window for DL direction. The observed Packet delay distribution includes N3 delay for UL/DL and E2E delay (between UPF and UE).

QoS flow UL/DL Data Burst Volume UPF UL/DL data traffic volume per PDU set.

QoS flow UL/DL Burst Arrival Time Periodicity UPF UL/DL burst data arrival time periodicity measurement per PDU set.

-TS 23.288 [2], Table 6.4.2-1a: Performance Data from AF, can be updated partly with the following (new) input data:

Information Source(s) Description

E2E jitter/delay distribution AF The E2E delay distribution/jitter information between Application server and UE.

UL/DL Data Burst Volume AF UL/DL data traffic volume per application.

UL/DL Burst Arrival Time Periodicity AF UL/DL burst data arrival time periodicity measurement per application.

-TS 23.288 [21 Table 64.2-3: UE level Network Data from OAM related to the QoS profile, can be updated partly with the following (new) input data:

Information Source(s) Description

UL/DL packet delay GTP OAM UL/ DL packet delay measurement round trip on GTP path on NI TS 28.552 (NOTE 1) Distribution of UL/DL GTP packet delay between PSA UPF and NG-RAN OAM The distribution of UL/DL GTP packet delay between PSA UPF and NG-RAN.

TS 28.552 (NOTE 1) Distribution of UL/DL packet delay between PSA UPF and UE OAM The distribution of UL/DL packet delay between PSA UPF and UE.

TS 28.552 (NOTE 1) Distribution of round-trip N3 delay on UPF OAM The distribution of round-trip delay on a N3 interface on PSA UPF.

TS 28.532 (NOTE 1) Distribution of round-trip pack et between UPF and NG-RAN OAM The distribution of round-trip GTP packet delay between PSA UPF and NG-RAN.

TS 28.552 (NOTE 1) NOTE 1: The data collected from OAM can he represented as a single entry, e.g., "Delay Measurements" and the noted OAM measurement can be collected all together as part of this single input entry.

TS 23.288 [2], Table 64.3-1: Service Experience statistics and Table 6.4.32: Service Experience predictions, can be updated partly with the following output statistics/predictions (new parts are underlined):

Information Description

> Service Experience Type Type of Service Experience analytics, e.g. on voice, video, combination of voice and video, e.g., XR, other.

> Service Experience Service Experience over the Analytics target period (average, variance).

>> QoE Overall service experience as Mean Opinion Score (MOS) or QoE >> OoS QoS performance >>> Average Throughput The average throughput achieved for PDUs belong Lo OoS flow/application. In case of XR and media traffic, the averaging is performed over PDUs in a PDU set.

>>> Average Packet Delay The average packet delay observed for PDUs belong to QoS llow/applica Lion. In case of XR and media traffic, the averaging is performed over PDUs in a PDU set.

>» Packet Delay The packet delay distribution/jitter obtained among PDU sets.

distribution /Titter >» E2E Delay The E2E delay distribution/jitter obtain between Application server and_UE. distribution/Titter [00142] As part of Data Network Performance Analytics [00143] According to certain embodiments of the present disclosure, for the Data Network Performance analytics, one or more of the following may be applied: TS 23.288 [2] Table 6.14.2-1: Performance Data from AF, can be updated partly with the following input data (new parts are underlined):

Information Source(s) Description

Performance Data AF The performance associated with the communication session of the UE with an Application Server that includes: Average Packet Delay, Packet Delay Distribution/Titter, Average Loss Rate and Throughput.

TS 23.288 [2] Table 6.14.3-1: DN service performance statistics and Table 6.14.3-2: DN service performance predictions, can be updated partly with the following output statistics/predictions (new parts are underlined):

Information Description

> Performance Performance indicators.

>> Average Traffic rate (NOTE 2) Average traffic rate observed for UEs communicaling with Lhe application.

>> Maximum Traffic rate (NOTE 2) Maximum traffic rate observed for UEs communicating with the application.

>> Average Packet Delay (NOTE 2) Average packet delay observed for UEs communicating with the application.

» Maximum Packet Delay (NOTE 2) Maximum packet delay observed for UEs communicating with the application.

» Packet Delay litter/packet delay distribution observed for UEs communicating with Distribution/fitter the application.

>> Average data Average data traffic size/PDU set size observed for UEs burst/volume size communicating with the application.

>> Maximum data Maximum data traffic size/PDU set size observed for UEs burst/volume size communicaling with Lhe application.

>> Data burst Data burst periodicity/PDU set periodicity (mean and variance) periodicity observed for UEs communicating with the application.

>> Average Packet Loss Rate (NOTE 2) Average packet loss observed for UEs communicating with the application.

[00144] As part of Redundant Transmission Experience Analytics [00145] According to certain embodiments of the present disclosure, for the Redundant Transmission Experience analytics, one or more of the following may be applied: TS 23.288 [2] Table 6.13.2-1: Packet drop and/or packet delay measurement per QFI or GTP level, can be updated with the following input data (new parts are underlined):

Information Source (s) Description

UL/DL packet drop rate GTP-U OAM (see UL/ DL packet drop rate measurement on GTP path on N3.

NOTE 2) UL/DL packet delay GTP OAM (see UL/DL packet delay measurement round trip on GTP path on NI NOTE 2) Distribution of UL/DL GTP packet OAM (see The distribution of UL/DL GTP packet delay delay between PSA UPF and NC- between PSA UPF and NC-RAN.

NOTE 2)

RAN

Distribution of UL/DL packet OAM (see The distribution of UL/DL packet delay delay between PSA UPF and UE NOTE 2) between PSA UPF and UE.

Distribution of round-trip N3 delay OAM (see The distribution of round-trip delay on a N3 on UPF NOTE 2) interface on PSA UPF.

Distribution of round-trip packet OAM (see The distribution of round-trip GTP packet delay between UPF and NG-RAN NOTE 2) between PSA UPF and NG-RAN.

NOTE 1: The information in this table is provided both as the base to compare with the redundant transmission performance as well as when redundant transmission is enabled.

NOTE 2: Refer to clause 5.1 of TS 28.552 [8] for the performance measurement in NG-RAN and clause 5.4 1 of TS 28.552 [8] for the performance measurement in UPF. In addition, Annex A of TS 28.552 [8] describes various performance measurements.

-TS 23.288 [2] Table 6.13.3-1: Redundant Transmission Experience, can be updated part y with the following output statistics (new parts are underlined):

Information Description

> Observed Redundant Observed Redundant Transmission Experience related information during the Analytics target period.

Transmission Experience >> UL/DL packet drop rate GTP-U (NOTE 2) Observed UL/DL packet drop rate on GTP-U path on N3 (average, variance).

>> UL/DL packet delay GTP-U (NOTE 2) Observed UL/DL packet delay round trip on GTP-U path on N3 (a vera ge, variance).

>> UL/ DL packet delay Observed UL/ DL packet delay distribution/jitter on GTP-U path on distribution/jitter N3 (mean, variance).

(NOTE 2) >> UL/DL E2E packet Observed UL/DL E2E packet delay distribution/jitter between PSA delay distribution/jitter UPF and UE (mean variance).

(NOTE 2) NOTE 1: The Observed Redundant Transmission Experience can be further derived by SMF from the observed UL/DL packet drop rate GTP-U and UL/DL packet delay GTP-U.

NOTE 2: This information element is an analytics subset that can be used in "list of analytics subsets that are requested" and only applicable when Target of Analytics Reporting is for a single UE.

TS 23.288 [2] Table 6.13.3-2: Redundant Transmission Experience predictions, can be partly updated with the following output predictions (new parts are underlined):

Information Description

> Predicted Redundant Predicted Redundant Transmission Experience related information during the Analytics target period.

Transmission Experience >> UL/DL packet drop rate GTP-U (NOTE 2) Predicted UL/DL packet drop rate on GTP-U path on N3 (average, variance).

>> UL/DL packet delay GTP-U (NOTE 2) Predicted UL/DL packet delay round trip on GTP-U path on N3 (average, variance).

>> UL/DL packet delay Predicted UL/DL packet delay distribution/jitter on GTP-U path on distribution/litter N3 (mean, variance).

(NOTE 2) >> UL/DL E2E packet Predicted UL DL E2E acket dela r distribution itter between PSA delay distribution/jitter UPF and UE (mean variance).

(NOTE 2) NOTE 1: The Predicted Redundant Transmission Experience can he further derived by the SMF from the predicted UL/DL packet drop rate GTP-U and UL/DL packet delay GTP-U and based on which the SMF can decide to start redundant transmission or not.

NOTE 2: This information element is an analytics subset that can he used in "list of analytics subsets that are requested" and only applicable when Target of Analytics Reporting is for a single UE.

[00146] As part of UE Communication Analytics [00147] According to certain embodiments of the present disclosure, for the UE Communication analytics, one or more of the following may be applied: TS 23.288 [2] Table 6.7.3.2-1: Service Data from 5GC related to UE communication, can be updated partly with the following input data (new parts are underlined):

Information Source(s) Description

UE communication (1..max) UPF, AF Communication description per application >Communication start The Lime stamp (ha i this communication starts >Communication stop The time stamp that this communication stops >UL data rate UL data rate of this communication >DL data rate DL data rate of this communication >Traffic volume Traffic volume of this communication >Traffic periodicity UPF, AF The average traffic periodicity of this communication >Average UL packet delay UPF The average observed UL packet delay of this communication between UPF and UE >Average DL packet delay UPF The average observed DL packet delay of this communication between UPF and UE >UL packet delay UPF The UL packet delay distribution/jiver of this distribution/jitter communication between UPF and UE >DL packet delay UPF The DL packet delay distribution/jitter of this distribution/jitter communication between UPF and UE >E2E UL packet delay AF The UL packet delay distribution/jitter of this distribution/litter communication between application server and

UE

>E2E DL packet delay AF The DL packet delay distribution/jitter of this distribution/jitter communication between application server and

UE

TS 23.288[2] Table 6.7.3.3-1: UE Communication Statistics and Table UE Communication Predictions, can be updated partly with the following output statistics/predictions (new parts are underlined):

Information Description

UE communications (1..max) (NOTE 1) List of communication time slots.

> Periodic communication indicator (NOTE 1) Identifies whether the UE communicates periodically or not.

> Periodic time (NOTE 1) Interval Time of periodic communication (average and variance) if periodic.

Example: every hour

> Data burst periodicity Data burst periodicity/PDU set periodicity (mean and variance) for (NOTE 2) UEs communicating with the application.

> Start time (NOTE 1) Start time observed (average and variance) > Duration (NOTE 1) Duration of communication (average and variance).

> Traffic characterization S-NSSAI, DNN, ports, other useful information.

> Traffic volume (NOTE 1) Volume UL/DL (average and variance).

> Ratio Percentage of UEs in the group (in the case of a UE group).

> Packet Delay fitter/packet delay distribution for UEs communicating with the Distribution/fitter applica lion.

> Average data Average data traffic size/PDU set size for UEs communicating with burst/volume size (NOTE the application.

> Maximum data Maximum data traffic size/PDU set size for UEs communicating with burst/volume size (NOTE the application. 2)

NOTE 1: Analytics subset that can be used in "list of anal ylics subsets that are requested" and "Preferred level of accuracy per analytics subset".

NOTE 2: Data burst periodicity is different than the periodic time It represents packet-/PDU-/PDU set-level periodicity. different than the traffic volume. It represents packet-/PDU-/PDU set-NOTE 3: Data burst volume is level burst data volume.

[00148] As part of QoS Sustainability Analytics [00149] According to certain embodiments of the present disclosure, for the QoS Sustainability analytics, one or more of the following may be applied: TS 23.288 [2] Table 6.9.2-1: Data collection for "QoS Sustainability" analytics, can be updated partly with the following input data (new parts are underlined):

Information Source(s) Description

RAN UE Throughput OAM Average UE bitrate in the cell (Payload data volume on RLC level per elapsed time unit on the air interface, for transfers restricted by the air interface), per timeslot, per cell, per 5QI, per TS 28.554 application/DNN and per S-NSSAL RAN UE Packet Delay OAM Average UE packet delay in the cell per timeslot, TS 28.554 per cell, per SQL per 5-NSSAI and per application.

RAN UE Packet Delay OAM UE packet delay distribution/jitter in the cell Distribution/ fitter TS 28.554 per timeslot, per cell, per SQL per S-NSSAI and per application.

QoS flow Retainability OAM Number of abnormally released QoS flows during the time the QoS Flows were used per timeslot, per cell, per 5QI and per S-NSSAI.

TS 28.554 Regarding the output statistics/predictions, there is no need for new information elements as the provided information in this disclosure can be captured as part of QoS KPI.

[00150] As part of User Data Congestion Analytics [00151] According to certain embodiments of the present disclosure, for the User Data Congestion analytics, one or more of the following may be applied: TS 23.288 [2] Table 6.8.2-1: Data Collected from the NF and OAM related to User Data Congestion Analytics, can be updated partly with the following input data (new parts are underlined):

Information Source(s) Description

UE Location AMF UE location information that NWDAF can use Lo derive the Area of Interest.

Measurements OAM Performance Measurements that will be used by the NWDAF to determine congestion levels. Performance Measurements are rela led to information transfer over the user plane and/or the control plane (e.g. UE Throughput Packet Delay Packet Delay Distribution/Jitter DRB Setup Management RRC Connection Number, PDU Session Management and Radio Resource Utilization as defined in TS 28.552). The N WDAF may obtain measurements by invoking management services that are defined in TS 28.532 and TS 28.550.

TS 23.288 [2] Table 6.8.2-2: Data Collected from the UPF or from the AF related to User Data Congestion Analytics, can be updated partly with the following input data (new parts are underlined):

Information Source(s) Description

Application ID UPF or AF Application identifier as defined in T5 23.501 clause 5.8.2 (see NOTE 1).

IP Packet Filler Set UPF or AF IP Packet Filter set as defined in TS 23.501 clause 5.8.2 (see NOTE 1).

Measurement period UPF or AF Measurement period.

Throughput UL/DL UPF or AF Average Throughput UL/DL over the measurement period.

Throughput UL/DL (peak) UPF or AF Peak Throughput UL/DL over the measurement period.

Traffic periodicity UPF or AF The average traffic periodicity over the measurement period.

Packet delay UL/DL UPF Avera Iv acket dela, UL DL between UPF and UE over the measurement period.

Packet delay distribution/jitter UPF UL/DL packet delay distribution/jitter between UL/DL UPF and UE over the measurement period.

E2E Packet delay UL/DL AF Average E2E packet delay UL/DL between the application and UE over the measurement period.

E2E Packet delay distribution/litter AF UL/DL packet delay distribution/jitter between UL/DL the application and UE over the measurement period.

Timestamp UPF or AF Time when measurements are Laken.

Achieved sampling ratio UPF Sampling ratio achieved by UPF (see NOTE 2).

Time window/bin size UPF or AF Time window/bin size used to obtain delay distribution/jitter.

NOTE 1: Application Id and IP Packet Filter Set are mutually exclusive.

NOTE 2: UPF may apply data sampling to reduce the load on the UPF. This parameter is provided when no sampling ratio is configured at the UPF or the UPF could not fulfil the configured sampling ratio.

NOTE 3: Multiple outputs are provided by the UPF when multiple Service Data Flows are running at the UPF for the same UE and measurement period.

NOTE 4: How NVVDAF collects information from UPF is not defined in this Release of the specification.

TS 23.288 [2] Table 6.14.3-1: DN service performance statistics and Table 6.14.3-2: DN service performance predictions, can be updated partly with the following output statistics/predictions (new parts are underlined):

Information Description

> List of top applications in UL (O..NU) (NOTE 1, NOTE 4) The list of applications that contribute the most to the traffic in the UL direction.

>> Application ID Application identifier as defined in TS 23.501 clause 5.8.2 (see NOTE 2).

>> IP Packet Filter Set IP Packet Filter set as defined in TS 23.501 clause 5.8.2 (see NOTE 2).

>> Percentage The application's throughput as a percentage of the total throughput in the Area of Interest.

>> Traffic Periodicity The application's UL traffic periodicity in the Area of Interest.

>> Packet delay The application's UL delay distribution/jitter (mean, variance) distribution/litter between IRE and UE in the Area of Interest.

» E2E packet delay The application's E2E UL delay distribution/jitter (mean, variance) distribution/jitter between the application and UE in the Area of Interest.

> List of top applications in DL (0..ND) (NOTE 1, NOTE 4) The list of applications that contribute the most to the traffic in the DL direction.

» Application ID Application identifier as defined in TS 23.501 clause 5.8.2 (see NOTE 2) >> IP Packet Filter Set IP Packet Filter set as defined in TS 23.501 clause 5.8.2 (see NOTE 2).

>> Percentage The application's throughput as a percentage of the total throughput in the Area of Interest.

» Traffic Periodicity The application's DL traffic periodicity in the Area of Interest.

» Packet delay The application's DL delay distribution/jitter (mean variance) distribution/jitter between UPF and UP in the Area of Interest.

>> E2E packet delay The application's E2E DL delay distribution/jitter (mean, variance) distribution/litter between the application and UE in the Area of Interest.

NOTE 1: This information element is an Analytics subset that can he used in "list of analytics subsets that are requested".

NOTE 2: Application Id and IP Packet Filter Set are mutually exclusive.

NOTE 3: The listed applications are not necessarily ranked by any order of traffic contribution.

NOTE 4: This information element relates to congestion experienced while transferring user data over the user plane.

NOTE 5: The number of user data congestion analytics entries is limited by the maximum number of objects provided as part of Analytics Reporting Information.

[00152] Data Collection and/or Reporting [00153] With regards to the input data of the latency performance related analytics such as described above (e.g., referring to any combination of the input data described in the "Input Data" section of this disclosure above), in certain embodiments of the present disclosure the NWDAF may collect the service data from UPF and/or SMF. In some cases, the NWDAF may be configured to subscribe to the UPF (directly, or via SMF if needed) and collect data directly from UPF. In other cases, if the NWDAF does not subscribe to the UPF, the service data may be collected via the N4 Session related input data from SMF. In those cases, the UPF may report the measurements to the SMF if the N4 session reporting trigger is met. The SMF may then provide the measurements to the NWDAF, such that the NWDAF may collect the corresponding input data.

[00154] For the data related to QoS monitoring described in the "Input Data" section of this disclosure, (e.g., UL, DL and/or round trip packet delay of a QoS flow/a PDU Session/a UE), bitrate, number of packet (re-)transmission), the NWDAF may either subscribe to UPF (for example, if Release 18 UPF enhancement for Exposure and SBA (UPEAS) features are supported by the network) or SMF. In the latter case, the UPF should report the measurement to SMF via N4 session. However, as mentioned in clause 4.4.2.2 of TS 23.502 [3], in current state of the art the UPF only calculates the above listed QoS monitoring related measurement when the QoS monitoring for URLLC is enabled.

[00155] Accordingly, certain embodiments of the present disclosure aim to support the latency performance related analytics discussed above (e.g., for Al/ML-based services or XRM services) by providing methods to trigger the data monitoring and calculation at UPF. For example, the UPF may measure/monitor/calculate the data (e.g., the input data being collected by the NWDAF) if the UPF receives a request or subscription from the NWDAF, or from AF, SMF, PCF etc. [00156] For example, the UPF may receive a request from NWDAF to start QoS monitoring or the measurement of other parameters, and report the results to the NWDAF as configured (e.g., report the results periodically, upon request, or once the thresholds are met).

[00157] In an alternative, the NWDAF may request the SMF to trigger data monitoring and reporting. For example, the NWDAF sends a request or subscribes to the SMF for data collection. If the data is available in the SMF, the SMF reports the required data to the NWDAF, based on a configuration if applicable (e.g., a configuration to report the results periodically, once a threshold(s) is met etc.). If the data is not available at SMF, the SMF may collect the data from UPF. For example, the SMF may trigger the UPF to monitor and report the required data. For example, triggers for event reporting may be configured on the UPF during N4 Session Establishment/Modification procedures by the SMF.

[00158] Certain embodiments of the present disclosure provide new N4 session reporting event(s) for measurement information collection in the UPF and reporting to the SMF. The new reporting event(s) may be for latency performance related analytics or assisting Al/ML-based services purposes. When a new event is configured, for instance, the UPF shall monitor and report the data to the SMF based on the configuration of the new event. For example, if the new event is for latency performance related analytics or if assisting Al/ML-based services is requested by SMF, the UPF monitors the required data (e.g., UL and DL data rate, QoS flow Bit Rate, QoS flow Packet Delay, Packet (re-)transmission etc.) and the UPF reports the results to the SMF. In some examples, the reporting may be based on a configuration, such as when the reporting trigger(s) is satisfied, e.g., the measured bit rate value is lower than the reporting threshold, or when the reporting period expires, or when the PDU Session is released. Another example is to trigger the data monitoring for Al/ML-based services or XRM services according to the information for QoS Monitoring for AI/ML or XRM received in the Policy and Charging Control (PCC) rules. For example, the Policy Control Function (PCF) may derive the authorized QoS Monitoring policy for Al/ML-based services or XRM services included in the corresponding PCC rules. According to the PCC rules of the Al/ML-based service, the UPF will trigger the monitoring and calculation of the service data.

[00159] According to certain embodiments of the present disclosure, to activate the RAN node to monitor the required data for latency performance related analytics or Al/ML-based services or XRM services (e.g., UL/DL data rate), the SMF may be configured to send a request to the NG-RAN via N2 signalling to request the data monitoring between PSA UPF and NG-RAN. The QoS Monitoring request may contain monitoring parameters determined by SMF, e.g., based on the authorized QoS Monitoring policy received from the PCF and/or local configuration.

[00160] In further examples, the SMF may send the request to the NG-RAN upon receiving the request from NWDAF as mentioned above.

[00161] Figure 1 shows a procedure for a NWDAF to derive latency performance related analytics in accordance with an example of the present disclosure. It will be appreciated that embodiments of the present disclosure are not limited to the specific messages shown to be transmitted/received in Fig. 1; these specific messages are to more fully illustrate an embodiment of the disclosure, but are not intended to be limiting.

[00162] In operation 1, the service consumer 10 (for example, a NF, NEF, AF etc.) may subscribe to, or request, latency performance related analytics. For example, to subscribe, the service consumer 10 may transmit a subscription request or a request, or similar, to the NWDAF 20. This request may be made via the Nnwdaf AnalyticsSubscription_Subscribe or Nnwdaf_Analyticslnfo_Request service operations, to give some examples.

[00163] The service consumer 10 may provide, in/with the request, the UE ID or Group ID, for example in the target of analytics reporting. In addition or alternatively, the service consumer may provide Analytics ID = "UE latency performance" and may also, optionally, provide a set of Event Filters. Analytics Filters may include Area of Interest (A01), QoS requirements and/or latency related threshold. Event filters that may optionally be provided include DNN, S-NSSAI and/or application ID. It will be appreciated that any combination of the request information (described previously (or anywhere) in the present disclosure) may be included in the request or omitted from the request, and that other request information may also be included, if desired. For example, the Target of Analytics Reporting, Analytics Filters and Analytics Reporting Information are set according to clause 6.7.x.1 of TS 23.288 [2].

[00164] In an optional operation (not illustrated), the NWDAF 20 may discover (from network repository function (NRF), not shown) one or more of AMF 30, SMF 40, UPF 50 and, optionally, PCF instance(s) relevant to the information in the request from the service consumer 10. For example, the NWDAF 20 may discover the network entities (e.g., AMF 30, SMF 40, UPF 50 and PCF instance(s)) relevant to the Analytics Filters indicated in the analytics subscription from the service consumer 10. In an example, this discovery may be via Nnrf NFDiscovery_Request. In some examples, this operation may be performed if the NWDAF 20 does not already have the information needed for deriving the analytics requested by the service consumer 10. If the NWDAF 20 has this information already, it is not necessary for the NWDAF 20 to discover the other network entities. Also, it will be appreciated that the NWDAF 20 may not need to discover other entities, in some examples.

[00165] In operation 2, in order to provide the requested analytics, the NWDAF 20 may subscribe to events with the AMF 30, SMF 40, UPF 50, and/or AF 60 for data(/information) collection. For example, the NWDAF 20 may transmit a message to one or more of the AMF 30, SMF 40, UPF 50, and AF 60 to collect data, where the message may request the data or subscribe to receive the data. It will be appreciated that the NWDAF 20 may subscribe only to the entities which it needs to collect data/information from, and so one or more of the sub-operations 2a-2h may be omitted accordingly.

[00166] In (sub-)operations 2a and 2b, the NWDAF 20 may subscribe to data/events with the serving AMF(s) 30 of the UE(s). For example, this may be to subscribe for notification of UE location(s) for a UE or a group of UEs, or notification of changes of such location(s). In an example, the subscribing may be made using Namf_EventExposure_Subscribe service. In certain examples, if NWDAF 20 requires UE location information with finer granularity than TA/cell, then NWDAF 20 collects the location data from Gateway Mobile Location Centre (GMLC) instead of AMF 30 (e.g., The NWDAF subscribes the service data from AMF in Table 6.7.x.2- 2 of TS 23.288 [2] using Namf_EventExposure_Subscribe service for collecting UE location(s) for a UE or a group of UEs).

[00167] In (sub-)operation 2c, the NWDAF 20 may subscribe to events/data from SMF 40. For example, NWDAF 20 may subscribe to service data from SMF 40 (such as any one or more of the service data shown in in Table 6.7.x.2-2 of TS 23.288 [2]) by invoking a request, e.g., Nsmf_EventExposure_Subscribe (Event ID, SUPI(s) or group ID, Application ID). In other examples, in addition or alternatively, in order to provide the requested analytics, the NWDAF 20 may subscribe to information of the UE and may subscribe to N4 Session related input data from SMFs 40 as defined in Table 6.7.x.2-2 of TS 23.288 [2].

[00168] In (sub-)operations 2d and 2e, N4 related input data is provided by UPF 50 to SMF 40. That is UPF 50 may collect, acquire or obtain the input data, and may transmits the input data to SMF 40. In certain examples, the SMF 40 may be requested for the input data by the NWDAF 20 and, if the SMF 40 itself cannot collect the input data, the SMF 40 requests the UPF 50 to collect the input data and provide the input data to the SMF 40. In other examples, the NWDAF 20 may request the SMF 40 to collect the input data from the UPF 50, such that the SMF 40, upon receiving the request, requests the input data from the UPF 50, where UPF 50 then collects and provides the requested input data to the SMF 40.

[00169] In (sub-)operation 2f, the SMF 40 may provide the input data to the NWDAF 20.

[00170] In (sub-)operations 2g and 2h, NWDAF 20 may subscribe to service data from AF 60. For example, NWDAF 20 may subscribe the service data from AF 60 in Table 6.7.x.2-1 of TS 23.288 [2] by invoking Nnef_EventExposure_Subscribe or Naf EventExposure_Subscribe service as defined in TS 23.502 [3].

[00171] In operation 3, the NWDAF 20 derives the requested analytics with the collected data. Examples of analytic output parameters/information are given above in the "Output Analytics" section. For example, the NWDAF 20 may derive the requested analytics in the form of latency performance statistics and/or predictions.

[00172] In operation 4, the NWDAF 20 provides the requested analytics, or at least a part thereof, to the service consumer 10. In an example, this may be using either Nnwdaf_Analyticslnfo_Request response or Nnwdaf_AnalyticsSubscription_Notify, depending on the service used in operation 1 (i.e., Nnwdaf AnalyticsSubscription_Subscribe or Nnwdaf_Analyticslnfo_Request service operations).

[00173] Optionally, the method may end after operation 4. Alternatively, referring to operation 5 (including (sub-)operations 5a-5e, one or more of which may be included/performed depending on which entities the NWDAF 20 has subscribed to) and operation 6, the NWDAF 20 may continue to generate new analytics and provide them to the service consumer 10. For example, if the service consumer 10 has subscribed to receive notifications for latency performance related analytics, after receiving event notification from the one or more of the AMF(s) 30, SMF(s) 40, UPF(s) 50, AF(s) 60 subscribed by NWDAF 20 in operation 3, the NWDAF 20 may generate new analytics and provide them to the service consumer 10. In other words, for example, the NWDAF 20 may continue to provide relevant analytics corresponding to the service consumer 10 request following event reporting in the entities to which the NWDAF 20 has subscribed.

[00174] It will be appreciated that, in some examples, any of the steps/operations shown in Fig. 1 may be omitted, the order of the operations may change, any of these operations may be combined with other operations, and/or additional operations may be present. For example, operation 2 (all or any of operations 2a to 2h) may be omitted; for example, if the NWDAF 20 already has all information needed to derive the analytics then operation 2 can be omitted as a whole, or parts of operation 2 may be omitted if the NWDAF does not need information from the corresponding one of the other entities (AMF 30, UPF 50 etc.).

[00175] Figure 2 illustrates a method according to an example of the present disclosure. The method of Fig. 2 may be performed by an NWDAF, such as an NWDAF configured to provide latency performance related analytics as according to any one or more of the examples described herein.

[00176] In operation 210, the NWDAF receives a request for analytics from a consumer, such as an NF or other service consumer. The request may be a subscription request for latency performance related analytics. The request may include or indicate one or more of the information described above, such as (but not limited to) Analytics ID, Target of Analytics Reporting, Analytics target period, Analytics Filter Information, Reporting Threshold(s), and/or Preferred order of statistics or predictions of the latency performance related analytics. The request may be for a single provision of analytics by the NWDAF, or may be a request for being periodically or continually provided with analytics (for example, on a regular basis or whenever specified events occur in the network).

[00177] In operation 220, the NWDAF may optionally request data relating to the requested analytics from one or more network entities (such as AMF, SMF, UPF, PCF, AF etc.). If the NWDAF already has the data, this operation may be omitted. If the NWDAF does not have the data or needs additional data, the NWDAF may transmit, to each network entity from which the NWDAF needs data or may obtain the data from, a request for the data or may subscribe to that network entity, so as to be able to collect/obtain the data.

[00178] In operation 230, assuming operation 220 is performed with the NWDAF requesting data from one or more network entities, the NWDAF may receive (e.g., resulting from collection or obtaining) data from one or more of the network entities from which data was requested. For example, the NWDAF may receive data from all of the one or more network entities, or from only a subset of the one or more network entities. The latter case may apply, for instance, when the NWDAF is unable to directly request data from a particular network entity and so the request fails, but where another network entity may be able to provide the missing data to the NWDAF having obtained the missing data from the particular network entity. It will be understood that the data may be received from the one or more network entities at different times or at the same time.

[00179] In operation 240, the NWDAF generates or derives the requested analytics. This may be based on the request received in operation 210, thereby reflecting instructions that may be included in the request such as instructions relating to ordering of statistics or predictions.

[00180] In operation 250, the NWDAF transmits the analytics to the consumer [00181] It will be appreciated that operations 230, 240 and 250 may repeat over time, so as to provide the consumer with more analytics which may be derived from different (e.g., newer) input data.

[00182] Figure 3 is a block diagram illustrating an exemplary network entity 300 (or electronic device, or network node etc.) that may be used in examples of the present disclosure. For example, a NWDAF, AMF, AF, NF, PCF, UPF, SMF etc. as described in any of the embodiments/examples disclosed above may be implemented by or comprise network entity 300 (or be in combination with network entity 300).

[00183] The network entity 300 comprises a controller 305 (or at least one processor) and at least one of a transmitter 301, a receiver 303, or a transceiver (not shown). It will be appreciated that one or more antennas may also be included.

[00184] To give some separate, non-limiting examples: the controller 305 may be configured to: control the receiver 303 to receive a request for analytics from a service consumer; if the network entity 300 does not know the input data needed to derive the output analytics corresponding to the requested analytics (e.g., the controller 305 may determine or identify whether this is the case), control the transmitter 301 to transmit a request for information to one or more network entities capable of providing the information; control the receiver to receive information from the one or more network entities; derive the analytics based on the received information and the request; and control the transmitter 301 to transmit the derived analytics to the consumer.

[00185] In addition, certain examples, aspects, embodiments etc. of the present disclosure are as follows: [00186] According to a first aspect of the example disclosure, there is provided a method of a first network entity in a wireless communications network, the method comprising: based on a request from a second network entity, deriving analytics including latency performance related analytics based on input data; and transmitting the derived analytics to the second network entity.

[00187] According to a second example, there is provided the method of the first example, wherein the request is a request for latency performance related analytics and the request is received from the second network entity.

[00188] According to a third example, there is provided the method of the first example or the second example, wherein the request includes at least one of, or an indication of at least one of, the following: analytics ID (e.g., an indication that latency performance related analytics are requested), target of analytics reporting (e.g., a single UE, a group of UEs, an application, a DNN), an analytics target period (e.g., a time period over which the statistics of the past or predictions of the future are requested), analytics filter information (e.g., one or more of: application ID, latency/jitter threshold, latency/jitter classes, ratio/percentage of latency/jitter classes, location information, area of interest information, DNN, S-NSSAI etc.), reporting threshold(s) (e.g., level to be reached for reporting the analytics and, optionally, a matching direction relating to crossing the threshold), and preferred order of statistics and/or predictions of the latency performance related analytics.

More details/examples regarding the different options for including in the request are described earlier in this disclosure, and said details are relevant here also.

[00189] According to a fourth example, there is provided the method of any of the first to third examples, wherein the input data comprises at least one of, or an indication of at least one of, the following: UE identifier (ID) or a list of UE IDs, Group ID, Application ID, S-NSSAI, DNN, Area of interest, location information, model size, traffic volume, number of iterations, training time, Al/ML operation, traffic rate related service data, XR and Media service-specific data, UE locations, averages of any of the aforementioned measurements over a group of UEs, and variance information of any of the aforementioned measurements over a group of UEs. More details/examples regarding the different options for including in the input data are described earlier in this disclosure (see "Input Data" section, for example), and said details are relevant here also.

[00190] According to a fifth example, there is provided the method of any of the first to fourth examples, the method further comprising: transmitting, to each of at least one third network entity (e.g., NF, AMF, SMF, UPF, PCF, AF), a request for a part of the input data to be collected from that (i.e., the respective) third network entity. For example, the part of the input data to be collected from, or by, a third network entity may be regarded as a part of the input data associated with that third network entity (e.g., in the sense of said third network entity being an entity capable of providing this specific part of the input data).

[00191] According to a sixth example, there is provided the method of the fifth example, wherein different parts of the input data are requested from each of the at least one third network entity.

[00192] According to a seventh example, there is provided the method of the sixth example wherein the different parts of the input data requested from each of the at least one third network entity and, if present, a part of the input data stored at the first network entity together provide the input data upon which deriving of the analytics is based.

[00193] According to an eighth example, there is provided the method of any of the fifth to seventh examples, further comprising receiving, from each of the at least one third network entity, the part of the input data requested from that (i.e., the respective) one of the at least one third network entity.

[00194] According to a ninth example, there is provided the method of any of the fifth to eighth examples, wherein the request is to subscribe to the at least one third network entity to collect the corresponding part of the input data.

[00195] According to a tenth example, there is provided the method of any of the fifth to eighth examples, wherein the request transmitted to one of the at least one third network entities includes a request to trigger data monitoring and reporting.

[00196] According to an eleventh example, there is provided the method of the tenth example, wherein the request to trigger data monitoring and reporting relates to triggering or performing data monitoring and reporting at a fourth network entity (e.g., UPF).

[00197] According to a twelfth example, there is provided the method of any of the first to eleventh examples, wherein the derived analytics comprise at least one of: UE ID or list of UE IDs statistics and/or predictions, Group ID statistics and/or predictions, Latency statistics and/or predictions, UE latency performance statistics and/or predictions, XRM traffic characteristics statistics and/or predictions, Aggregate Latency performance statistics and/or predictions etc. More details/examples regarding the different options for including in the derived analytics are described earlier in this disclosure (see "Output Analytics", "Statistics" and "Predictions" sections, for example), and said details are relevant here also.

[00198] It will be appreciated that, in each example/embodiment/aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate. Additionally, one or more features or operations from any example/embodiment may be combined with features or operations from any other example/embodiment.

[00199] The techniques described herein may be implemented using any suitably configured apparatus and/or system. Such an apparatus and/or system may be configured to perform a method according to any aspect, embodiment or example disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and/or method steps for implementing the techniques described herein. For example, an operation/function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

[00200] It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

[00201] It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment and/or aspect disclosed herein, and/or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

[00202] While the present disclosure has been shown, illustrated and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure.

[00203] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

Acronyms and Definitions 3GPP 3rd Generation Partnership Project 5G 5th Generation 5GC 5G Core 5QI 5G QoS Identifier 5GS 5G System SGSM 5G System Session Management 5GMM 5G System Mobility Management AF Application Function Al Artificial Intelligence AM Acknowledged Mode AMF Access and Mobility Management Function AS Application Server ASP Application Service Provider AUSF Authentication Server Function CDRX Connected Mode Discontinuous Reception DCAF Data Collection Application Function DNAI Data Network Access Identifier DNN Data Network Name DNS Domain Name Server DRB Data Radio Bearer eNB Evolved Node B FQDN Fully Qualified Domain Name GBR Guaranteed Bit Rate 23 GMLC Gateway Mobile Location Centre gNB Next generation Node B GPSI Generic Public Subscription Identifier IAB Integrated Access and Backhaul ID Identity/Identifier lloT Industrial Internet of Things IMEI International Mobile Equipment Identities IP Internet Protocol I-SMF Intermediate SMF ML Machine Learning MME Mobility Management Entity MN Master Node MNO Mobile Network Operator MT Mobile Termination NAS Non-Access Stratum NEF Network Exposure Function NRF Network Repository Function NG-RAN Next Generation Radio Access Network NG-eNB Next Generation eNB NSA Non-Standalone NSSF Network Slice Selection Function NW Network NWDAF Network Data Analytics Function OS Operating System OSAPP OS Application PCO Protocol Configuration Options PDR Packet Detection Rule PDU Protocol Data Unit PSA PDU session anchor OH QoS Flow Identifier (ID) QoS Quality of Service RACH Random Access Channel RAN Radio Access Network RSD Route Selection Descriptor SA Standalone SDAP Service Data Adaptation Protocol SDU Service Data Unit SIM Subscriber Identity Module SLA Service Level Agreement SM Session Management SMF Session Management Function SN Secondary Node S-NSSAI Single Network Slice Selection Assistance Information SSB Synchronization Signal Block SSC Session and Service Continuity SUPI Subscription Permanent Identifier TAI Tracking Area Identity TE Terminal Equipment TM Transparent Mode

TS Technical Specification

UDM Unified Data Manager UDR Unified Data Repository UE User Equipment UL Uplink UM Unacknowledged Mode UP User Plane UPF User Plane Function URLLC Ultra-Reliable and Low-Latency Communication URSP UE Route Selection Policy XRM Extended Reality and Media

Claims (25)

1. CLAIMS1. A first network entity included in a wireless communications network, the network entity comprising: a transmitter; a receiver; and a controller configured to: receive, from a second network entity, a request or a subscription for Network Data Analytics Function (NWDAF)-based analytics relating to transmission 1() delay associated with one or more UEs; obtain, based on the request or subscription, input data from at least one third network entity, the input data including information relating to the transmission delay; and output information relating to the NWDAF-based analytics based on the obtained input data, wherein the information comprises at least one output for the NWDAF-based analytics; wherein the transmission delay corresponds to traffic to or from the one or more UEs or corresponds to a data volume sent by or sent to one of the one or more UEs.
2. 2. The first network entity of claim 1, wherein the transmission delay relates to traffic associated with Al/ML-based service(s) including one of: Al/ML modelling or training, Al/ML inference, or transfer of Al/ML models.
3. 3. The first network entity of any previous claim, wherein the at least one output is for assisting with a federated learning operation or another Al/ML operation.
4. 4. The first network entity of any previous claim, wherein the input data comprises one or more of: a timestamp associated with the obtained input data; one or more first UE location(s); one or a list of first UE ID(s); or quality of service (QoS) flow packet delay.
5. 5. The first network entity of claim 4, wherein one or more of: the one or more first UE location(s) include a location of each of the one or more UEs; the one or the list of first UE ID(s) includes one or a list of subscription permanent identifiers (SUP Is) corresponding to the one or more UEs; or the QoS flow packet delay indicates observed packet delay for uplink (UL) direction, observed packet delay from downlink (DL) direction or observed packet delay measurements between the UE and a protocol data unit (PDU) session anchor (PSA) user plane function (UPF).
6. 6. The first network entity of claim 5, wherein one or more of: the timestamp is obtained from a 5G core (5GC) network function (NF); the one or more first UE location(s) are obtained from an access and mobility management function (AMF) or, if the required area of interest (Aol) has a granularity area below that of cell level, from a gateway mobile location centre (GMLC); or the QoS flow packet delay is obtained from a UPF or a session management function (SMF).
7. 7. The first network entity of any of claims 1 to 3, wherein the input data comprises one or more of: a timestamp associated with the obtained input data; a first application ID; one or a list of first UE ID(s); traffic volume; a start time; or an end time.
8. 8. The first network entity of claim 7, wherein one or more of: the first application ID includes an identifier of an application at the third network entity providing the input data; the one or the list of first UE ID(s) includes, for each of the one or more UEs, a subscription permanent identifiers (SUPIs) or a Generic Public Subscription Identifiers (GPSIs); the traffic volume is traffic volume to or from the one or more UEs or traffic volume of Al/ML related data associated with the one or more UEs; the start time indicates a start time of an Al/ML operation; or the end time indicates an end time of an Al/ML operation.
9. 9. The first network entity of claim 8, wherein the timestamp, the first application ID, the one or the list of first UE ID(s), the traffic volume, the start time and/or the end time are obtained from the same or a different application function (AF).
10. 10. The first network entity of any previous claim, wherein the at least one output com prises: one or a list of second UE ID(s) corresponding to the one or more UEs, and for each second UE ID, delay performance information.
11. 11. The first network entity of claim 10, wherein the delay performance information for each second UE ID comprises one or more of: a second application ID; Data Network Access Identifier (DNA); a UE location; DNN; S-NSSAI; validity period; spatial validity; UE uplink (UL) delay performance information; UE downlink (DL) delay performance information; or UE round trip delay performance information.
12. 12. The first network entity of claim 11, wherein, in relation to the delay performance information for each second UE ID, one or more of: the second application ID indicates an application in use at that UE; the DNN indicates the DNN for a PDU session which contains a QoS flow of traffic from that UE; the S-NSSAI indicates a network slice used to access the application in use at that UE; the validity period indicates a validity period for the UE delay performance for that UE; or the spatial validity indicates an area where the UE delay performance for that UE applies.
13. 13. The first network entity of any of claims 10 to 12, wherein the delay performance information for each second UE ID comprises one or more of: UL delay performance information over a time period for providing the analytics; an indication of a UL traffic volume corresponding to the UL delay performance information; DL delay performance information over the time period for providing the analytics; or an indication of a DL traffic volume corresponding to the DL delay performance information.
14. 14. The first network entity of any of claims 1 to 9, wherein the transmission delay is associated with a plurality of UEs; and wherein the at least one output comprises: a list of second UE IDs corresponding to the plurality of UEs, and in relation to the list of second UE IDs, delay performance information for the plurality of UEs.
15. 15. The first network entity of claim 14, wherein the delay performance information for the plurality of UEs comprises aggregate delay performance information.
16. 16. The first network entity of claim 15, wherein the aggregate delay performance information comprises one or more of: a list of one or more group of UE(s), from among the plurality of UEs, classified by ranges of delay performance, each group corresponding to a different class of delay performance; for each of the one or more group of UE(s), ID(s) of UE(s) in that class; for the one or more group of UE(s), an indication of a ratio of the UE(s) between each class; a validity period for the delay performance information for the plurality of UEs; or a spatial validity indicating an area where the delay performance information for the plurality of UEs applies.
17. 17. The first network entity of claim 16, wherein the number of the classes of delay performance or the number of the ranges of delay performance are predefined by 10 an operator or provided by the second network entity.
18. 18. The first network entity of claim 16 or claim 17, wherein the delay performance information is classified according to one or more threshold.
19. 19. The first network entity of any of claims 16 to 18, wherein the one or more group of UE(s) comprises one or more of: a list of low delay UE(s) corresponding to a first class; a list of medium delay UE(s) corresponding to a second class; or a list of high delay UE(s) corresponding to a third class.
20. 20. The first network entity of any previous claim, wherein each of the at least one output is a statistic or a prediction.
21. 21. The first network entity of claim 20, wherein, if the at least one output comprises a prediction, the at least one output further comprises a confidence for the prediction.
22. 22. The first network entity of any previous claim, wherein: the first network entity is a NWDAF; the second network entity is a service consumer including an application 30 function (AF) or a 5G core (5GC) network function (NF); and the at least one third network entity includes one or more of another AF, a session management function (SMF), access and mobility management function (AMF), user plane function (UPF), a policy control function (PCF) or operations administration and maintenance (OAM).
23. 23. A method of a first network entity, the method comprising: receiving, from a second network entity, a request or subscription for Network Data Analytics Function (NWDAF)-based analytics relating to transmission delay associated with one or more UEs; obtaining, based on the request or subscription, input data from at least one third network entity, the input data including information relating to the transmission delay; and outputting information relating to the NWDAF-based analytics based on the 1() obtained input data, wherein the information comprises at least one output for the NWDAF-based analytics; wherein the transmission delay corresponds to traffic to or from the one or more UEs or corresponds to a data volume sent by or sent to one of the one or more UEs.
24. 24. A network comprising a first network entity according to any of claims 1 to 22.
25. 25. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method according to claim 23.