Patent Description:
Minimization of drive tests (MDT) is a standardized mechanism introduced in third generation partnership project (3GPP) Release <NUM> to provide operators with network performance optimization tools in a cost-efficient manner. The main characteristics of MDT can be summarized below:.

AI/ML (Artificial Intelligence / Machine Learning) is currently being studied in 3GPP RAN WG3 (see the Study Item Description (SID) in RP-<NUM>; see CMCC, "<NPL>). According to the SID, Artificial Intelligence (AI) including machine learning (ML) algorithms are considered to provide a powerful tool to help operators to improve the network management and the user experience by providing insights based on autonomous analysis and processing of collected data.

There is an effort to combine AI/ML techniques with MDT, although AI/ML has broader applicability than just MDT in wireless networks.

<CIT> discloses that in the new air interface (Next Radio, referred to as NR), a flexible CSI configuration framework is defined. When used for CSI measurement, the base station will configure a measurement setting (measurement setting), one or more reporting sets (reporting setting), One or more resource sets (Resource setting). Each measurement setting includes one or more links (Link), and each Link is used to connect a reporting setting and a resource setting and indicates whether it is used for channel measurement or interference measurement. Each reporting setting includes the content of the CSI report and the occupied time-frequency domain resource position, and each resource setting includes the time-frequency domain resource position occupied by the reference signal (Reference Signal, referred to as RS) resource used for CSI measurement. The terminal device sends CSI reporting capability information of the terminal device to the network device, wherein the capability information is related to the number of ports (ports) of the pilot (such as RS) used for CSI measurement supported by at least one time domain unit (unit) of the UE. The capability information may be different codebook types, different precoding matrix indication PMI types, different bandwidth part BWP sizes, and the like. 3GPP TSG RAN Rel-<NUM> workshop Electronic Meeting, June <NUM> - July,<NUM>,<NUM>, RWS-<NUM> discloses on questions on RWS-<NUM>, "On Machine Learning over the NR Air Interface" for example the following: [Question <NUM>]: How to do the UE selection? [Answer <NUM>]: The details could be studied by RAN2/RAN3. gNB selects UE taking UE capability and context into consideration [Question <NUM>]: Is the CSF ML model learned for each UE, or for all UEs in a cell or even the whole network? [Answer <NUM>]: We envision an approach based on model ID. UEs differing in their AI/ML capability may announce support for different sets of model IDs. Therefore, it is possible that different CSF ML model may be used for different UEs. It is up to the network decision, within the boundary of UE capability, whether and which CSF ML model to configure to each UE.

<CIT> discloses a mobile radio communications network device (<NUM>) operative to collect network perfomance measurements and to select at least one mobile radio communications device (<NUM>) from which network performance measurements are to be collected if at least one parameter of the at least one mobile radio communication device (<NUM>) corresponds to at least one specified selection parameter. The at least one specified selection parameter is data identifying at least one mobile radio communication device characteristic. There are also provided a signal to be employed by such a network device, a mobile radio communications device operative for configuration by such a network device, related methods of such devices, and a related mobile radio communications system.

Further embodiments of the invention are defined in the dependent claims.

In the following description, the invention is described with particular reference to <FIG>, while the description of the remaining figures is provided for illustrative purposes for a better understanding of the invention.

Abbreviations that may be found in the specification and/or the drawing figures are defined below, at the end of the detailed description section.

When more than one drawing reference numeral, word, or acronym is used within this description with "/", and in general as used within this description, the "/" may be interpreted as "or", "and", or "both".

The exemplary embodiments herein describe techniques for MDT extensions for AI/ML data collection. Additional description of these techniques is presented after a system into which the exemplary embodiments may be used is described.

Turning to <FIG>, this figure shows a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced. A user equipment (UE) <NUM>, radio access network (RAN) node <NUM>, and network element(s) <NUM> are illustrated, where this example has multiple network elements <NUM>, <NUM>-<NUM>, and possibly more elements.

In <FIG>, a user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless, typically mobile device that can access a wireless network. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a control module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The control module <NUM> may be implemented in hardware as control module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The control module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module <NUM> may be implemented as control module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with RAN node <NUM> via a wireless link <NUM>.

The RAN node <NUM> is a base station that provides access by wireless devices such as the UE <NUM> to the wireless network <NUM>, and therefore is an access node to the network <NUM>. As described below, the RAN node <NUM> may include multiple physical devices. The RAN node <NUM> is considered to be a gNB herein, though this is only one example. The RAN node <NUM> may be, for instance, a base station for <NUM>, also called New Radio (NR). In <NUM>, the RAN node <NUM> may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to a 5GC (e.g., the network element(s) <NUM>). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC. The NG-RAN may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) <NUM> and distributed unit(s) (DUs) (gNB-DUs), of which DU <NUM> is shown. Note that the DU may include or be coupled to and control a radio unit (RU). The gNB-CU is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected with the gNB-DU. The F1 interface is illustrated as reference <NUM>, although reference <NUM> also illustrates a link between remote elements of the RAN node <NUM> and centralized elements of the RAN node <NUM>, such as between the gNB-CU <NUM> and the gNB-DU <NUM>. The gNB-DU is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-DU supports one or multiple cells. One cell is supported by one gNB-DU. The gNB-DU terminates the F1 interface <NUM> connected with the gNB-CU. Note that the DU <NUM> is considered to include the transceiver <NUM>, e.g., as part of an RU, but some examples of this may have the transceiver <NUM> as part of a separate RU, e.g., under control of and connected to the DU <NUM>. The RAN node <NUM> may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station.

The RAN node <NUM> includes a control module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The control module <NUM> may be implemented in hardware as control module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The control module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module <NUM> may be implemented as control module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the RAN node <NUM> to perform one or more of the operations as described herein. Note that the functionality of the control module <NUM> may be distributed, such as being distributed between the DU <NUM> and the CU <NUM>, or be implemented solely in the DU <NUM>.

Two or more RAN nodes <NUM> communicate using, e.g., link <NUM>. The link <NUM> may be wired or wireless or both and may implement, e.g., an Xn interface for <NUM>, an X2 interface for LTE, or other suitable interface for other standards.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM> for LTE or a distributed unit (DU) <NUM> for gNB implementation for <NUM>, with the other elements of the RAN node <NUM> possibly being physically in a different location from the RRH/DU, and the one or more buses <NUM> could be implemented in part as, e.g., fiber optic cable or other suitable network connection to connect the other elements (e.g., a central unit (CU), gNB-CU) of the RAN node <NUM> to the RRH/DU <NUM>. Reference <NUM> also indicates those suitable network link(s).

It is noted that description herein indicates that "cells" perform functions, but it should be clear that the base station that forms the cell will perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For instance, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a <NUM>-degree area so that the single base station's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So, if there are three <NUM>-degree cells per carrier and two carriers, then the base station has a total of six cells.

The wireless network <NUM> may include a network element or elements <NUM> that may include core network functionality, and which provides connectivity via a link or links <NUM> with a data network <NUM>, such as a telephone network and/or a data communications network (e.g., the Internet). Multiple network elements <NUM>, <NUM>-<NUM>,. , may be part of a core network <NUM>, which may be a 5GC. The link(s) <NUM> may connect the network elements <NUM> and the data network <NUM>, or there may be additional link(s) (not shown) to connect the network elements <NUM> and the link(s) <NUM> to connect the data network <NUM> to the core network <NUM> and/or the network elements <NUM>. Core network functionality for <NUM> may include access and mobility management function(s) (AMF(s)) and/or user plane functions (UPF(s)) and/or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (Mobility Management Entity) functionality and/or SGW (Serving Gateway) functionality. These are merely exemplary functions that may be supported by the network element(s) <NUM>, and note that both <NUM> and LTE functions might be supported. The RAN node <NUM> is coupled via a link <NUM> to a network element <NUM>. The link <NUM> may be implemented as, e.g., an NG interface for <NUM>, or an S1 interface for LTE, or other suitable interface for other standards.

All of the various network elements <NUM>, <NUM>-<NUM>, and the like, are assumed to be similar, so only exemplary circuitry of a single network element <NUM> is described herein. This network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The network element <NUM> includes a control module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The control module <NUM> may be implemented in hardware as control module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The control module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module <NUM> may be implemented as control module (CM) <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the network element <NUM> to perform one or more of the operations as described herein.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, firmware, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the UE <NUM>, RAN node <NUM>, network node(s) <NUM>, and other functions as described herein.

In general, the various embodiments of the user equipment <NUM> can include, but are not limited to, cellular telephones (such as smart phones, mobile phones, cellular phones, voice over Internet Protocol (IP) (VoIP) phones, and/or wireless local loop phones), tablets, portable computers, vehicles or vehicle-mounted devices for, e.g., wireless V2X (vehicle-to-everything) communication, image capture devices such as digital cameras, gaming devices, music storage and playback appliances, Internet appliances (including Internet of Things, IoT, devices), IoT devices with sensors and/or actuators for, e.g., automation applications, as well as portable units or terminals that incorporate combinations of such functions, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), Universal Serial Bus (USB) dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. That is, the UE <NUM> could be any end device that may be capable of wireless communication. By way of example rather than limitation, the UE may also be referred to as a communication device, terminal device (MT), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT).

Having thus introduced one suitable but non-limiting technical context for the practice of the exemplary embodiments, the exemplary embodiments will now be described with greater specificity.

As stated previously, AI/ML (Artificial Intelligence / Machine Learning) is currently being studied in 3GPP RAN WG3. The study focuses on the AI/ML functionality and tries to identify the corresponding types of inputs/outputs needed for the introduction of intelligence in the RAN. In addition, it focuses on the changes and enhancements of network interfaces to support AI-enabled RAN intelligence for a number of agreed use cases, e.g., energy saving, load balancing, mobility enhancements. The study is further based on the current architecture and interfaces. The study aims to reuse the existing SON/MDT procedures by using them as the baseline and by introducing new signaling when needed. Specifically, MDT has been a mechanism that was introduced to enhance data collection for SON-related use cases.

Recently, numerous 3GPP RAN contributions on AI/ML enabled features for 3GPP air interface have been submitted. Hence, AI/ML for air interface as well as NG-RAN enablers for AI/ML are likely to be part of a Rel-<NUM> study item in 3GPP. There has been some discussion of shaping the content of such study items, and further on providing feature-independent enablers which allow for supporting/enabling AI/ML in a more general way. Examples of important workflow enablers were identified as shown in <FIG>, which is an AI/ML workflow example. See also 3GPP TR <NUM> for similar examples.

This example involves the following entities: a data collection function <NUM>; a model training function <NUM>; an actor <NUM>; a model inference function <NUM>; and an actor <NUM>. The data collection function <NUM> is performed in the environment, e.g., a wireless/cellular environment, and produces training data <NUM> (namely data that after proper treatment, e.g., after passing through pre-processing can be used for training) and inference data <NUM> (namely data that after proper treatment, e.g., after passing through pre-processing can be used for inference). The model training module <NUM> uses the training data <NUM> for training, and can deploy the trained ML model where the inference is hosted for execution. Similarly, an ML model may be re-trained at the model training and the updated retrained model be sent where the inference is hosted for execution. This is indicated through the deployment or update arrow <NUM>, which is currently FFS, for future study in TR <NUM>. The model inference function <NUM> uses the inference data <NUM> for inferencing and creates an output <NUM>. The model inference function <NUM> may also output model performance feedback <NUM> (which is currently FFS, for future study in TR <NUM>) to the model training module <NUM> to provide feedback on the performance of the particular model in execution. The actor <NUM> uses the output <NUM> and may provide feedback <NUM> to the data collection module <NUM>. This feedback can be the normal procedures that take place for counter, performance measurements (PM) and other measurement retrieval by the network.

It would be useful to enable this workflow in the most generic way possible such that the majority of AI/ML supported features may be implemented without having feature-specific AI/ML support. Accordingly, the exemplary embodiments described below enable this workflow to support AI/ML supported features.

In a <NUM> system, there are multiple ways to collect data for training AI/ML algorithms for mobile networks optimization. In 3GPP SA2, the NWDAF function is standardized. NWDAF is the function responsible to collect data from other 5GC Network Functions (NFs) as well as from OAM; in OAM, data can be collected by means of Performance Measurements (PMs), KPIs, Trace and MDT Jobs, for instance. Those mechanisms are utilized to collect data for off-line training (for example, in case of supervised/unsupervised learning). However, lately there have been discussions about running ML at the UE side. This can reduce the amount of data that needs to be communicated before the network can train a specific function. Currently, there are no mechanisms instructing a UE to start calculating predictions internally and reporting those to the network.

The 3GPP [cf. 3GPP TS <NUM>] specifies the concept of radio measurement collection for Minimization of Drive Tests (MDT). There are two modes for the MDT measurements: Logged MDT and Immediate MDT. Immediate MDT allows the network to collect RT measurements reported per UE or per group of UEs immediately after a UE is performing those measurements. In Logged MDT reporting, the configuration is done when UE is in connected mode and the MDT data collection is done at the UE when it enters idle or inactive mode. Deferred reports in a form of logs are then sent when entering connected mode. MDT measurement results are put into MDT Trace Records and signalled onwards to operators' OAM entity for further post-processing.

There are two ways of configuring MDT, i.e., management and signaling activation approaches. In the management-based MDT data collection, the UE selection can be performed at the gNB <NUM> based on the area information received from the OAM. In signaling activation, MDT activation is carried out from the core network EM and targets a specific UE, for example based on its IMSI. The activation of MDT extends the 5GC trace activation procedure [cf. 3GPP TS <NUM>]. Configuration parameters of MDT are added into the message of the activated trace session. UE performance measurements activation request is propagated to the selected UE based on the UE identification information (e.g., IMSI/IMEI(SV)/IMEI-TAC/SUPI). This information may be also combined with geographical area information of the UE.

After the attachment to the network by the selected UE, the AMF forwards the MDT configurations to the corresponding gNB that serves the selected UE. If the MDT request contains the information on the area which is not satisfied via an area criterion, the AMF keeps the MDT configuration, and forwards this information towards the gNB only when the area criterion is satisfied. The MDT configuration contains all of the necessary information to perform measurements at the UE, such as the parameters identifying the list of measurements to be performed, reporting trigger, amount and interval, information on the threshold for events to be reported, information on Trace Collection Entity (TCE), and the like. The measurement parameter list for Immediate MDT defines the measurements that may be collected by a UE and utilized for RRM and can have different value e.g., in NR, as follows.

M1: DL signal quantities measurement results for the serving cell and for intra-frequency/Inter-frequency/inter-RAT neighbor cells, including cell/beam level measurement.

M2: Power headroom (PH) measurement by UE.

M4: PDCP SDU Data volume measurement separately for DL and UL, per DRB per UE.

M5: Average UE throughput measurement separately for DL and UL, per DRB per UE and per UE for the DL, per DRB per UE and per UE for the UL.

M6: Packet delay measurement, separately for DL and UL, per DRB per UE.

M7: Packet loss rate measurement, separately for DL and UL, per DRB per UE.

M8: RSSI measurement by UE for WLAN and Bluetooth.

When network has ML capability, a trained ML model may be executed either at the network side, e.g., at the gNB, gNB-CU, gNB-DU, etc. or at the UE side. The outcome of ML model execution is called ML Inference and generally comprises predictions. Consider, as an example, the use case of mobility and handover preparation to a cell. ML Training could take place at the network side, where also the ML Model can be executed. In this case, ML Model Inference is available at the network side. To enable the training for HO, a UE would need to report RSRP information to the network and the network, using this information, can train an ML model that predicts when to prepare a HO and towards which cell. To enable good training at the gNB side, the amount and frequency of RSRP measurements would need to be very high, which would significantly increase the overhead of communicating them from the UE to the network side. On the other hand, a UE may have downloaded an ML model internally that is trained by the UE itself using its own measurements. In this case, the UE could use the RSRP measurements, without the need to report them to the network, and could determine for example a predicted time (and possibly a cell) when the handover needs to be prepared. Having ML Model Inference (e.g., HO predictions) available at the UE side could reduce the amount of information sent to the network as the UE could send predictions to the network instead of raw measurements. Those prediction could help the network determine the actual time and cell to which the HO should be prepared. In some cases, it is preferrable to perform ML inference at the UE since this could reduce the amount of measurements sent to the network. In general, one could think of many examples when UE could perform ML model execution and the network could take actions based on the ML predictions from the UE.

Different UEs may have different ML capabilities and might (or might not) be able to train locally an ML Model, e.g., using RL techniques. Furthermore, they might or might not be able to perform ML Inference in case they have been provided (e.g., through a download) with an already trained ML Model. For those UEs capable to perform ML inference by executing locally available ML Models, there are currently no mechanisms to allow them to report this inference information to the network, namely there are no means to expose ML inference performed locally at UE and make the rest of the network aware of such information. Therefore, such local ML inference information cannot be used by other network entities in order to improve overall network performance. Furthermore, currently there are no mechanisms that allow the network to trigger the starting and ending of ML Inference measurements by one or more UEs in the network.

For UE-assisted ML, consider the following issues that need to be addressed. Inference at the UE may regard many different features that should not be individually specified and should not utilize separate channels/interfaces for distribution of inference. Meanwhile, AI/ML is a quickly changing field, and at the time of specification it may not be clear which AI runs on which UE. Additionally, different network entities may utilize UE inference, and it is desirable to avoid extensive capability signaling to inform a UE which network entity would be able to utilize inference data. Moreover, it is very likely that UE vendors do not want to expose the models and data used for the models; however, inference on the UE-side may improve network performance, e.g., by providing supplementary information on predicted states.

To address these and other issues, the following are possible examples of improvements for exemplary embodiments herein to enable MDT to trigger one or more UEs to provide the network with ML-related measurements by further controlling the amount, frequency and the stopping conditions for the mentioned ML information. These provide an overview, and additional detailed information is provided below.

In one example, the UE <NUM> may indicate to the network <NUM> a capability to provide prediction data/quantities. This capability may depend on the ML algorithms that UE has access to and is able to execute. As an example, the UE may indicate to the network that it is capable to provide predictions for ML Algorithm A but not for ML Algorithm B if the latter involves more complex calculations. Knowing the UE ML capability for a specific algorithm the network can configure accordingly ML Inference measurements at the UE. UE can indicate its ML capability to the network by sending a message to the gNB to which it is connected. In case of split architectures, the UE indicates its ML capability to the gNB-CU. This information may subsequently be propagated to the management plane or to the core network by the gNB (gNB-CU) so that the management plane/core can configure ML Inference measurements from different UEs according to their ML capability. ML capability of a UE may be changing over time depending for example on the UEs' residual memory or battery power. Therefore, ML Capability needs to be indicated by the UE to the network every time this Capability changes and different inference information is possible. As another option, a UE does not indicate its ML Capability to network. As a further possible option, even though a UE indicates to its gNB or gNB-CU its ML capability, the latter do not propagate this information to the management plane or to the core network. In a such a case, if a UE is not ML Capable, the UE may ignore the ML configuration. As a further possibility, it may send an indication to the network to inform inability to perform ML Inference. As a further possibility, it may send a message to the network to inform it in case it is capable to perform ML Inference over other, less complex algorithms.

In terms of the capability of the UE, this can include multiple criteria, which can change over time. For example, UE capability may be time-varying, depending on such criteria as the UE's remaining memory, whether the UE is connected to power, processing power able to devote to ML, and the like. The term "capability" therefore may cover ML capabilities and also the UE's internal state such as hardware or software restrictions for the UE, or even a combination of these (e.g., an ML algorithm may need a certain amount of processing power/memory, which the UE may or may not have at a given instant in time). That is, a capability may not be an existing UE capability in the sense that the capability is fixed per UE, but may instead be a time-varying capability that depends on the current internal state of the UE and its ability to perform inference.

In a further example, configuring may be performed towards a UE by a management plane (e.g., OAM) or by one or more network elements <NUM> in the core network <NUM> via a configuration instructing the UE <NUM> to report its ML actions/inference when the UE performs local ML. The network <NUM> can configure predictions to UE taking into account the UE ML capabilities to provide predictions. To convey this information, area-based or signaling-based Immediate and Logged MDT configuration can be extended.

For instance, to report ML inference, the MDT framework may be used. In this case, model inference may be reported as part of MDT measurements in similar ways as in Immediate MDT, when real-time measurements are reported from a UE in an RRC Connected state. In this case, instead of real-time measurements UE will need to report ML Inference as soon as the latter is being calculated by for instance RL methods. In certain cases, UE may need to also store ML inference information internally before it is able to calculate the final result to be reported to the network. This for example can be the case if the prediction to be reported depends on intermediate prediction steps.

ML inference may also be reported for non-real-time measurements. In this case, ML inference may additionally be logged as part of Logged MDT. This can be the case if inference happens when the UE is in RRC Idle or RRC Inactive states (e.g., when UE identifies it is out of coverage). UE will need to have an internal variable to log ML inference similarly to logging normal MDT measurements in Logged MDT.

An indicator in the measurement configuration (e.g., in MDT configuration) can signal to the UE whether the UE should report or log a) only normal measurements, b) only inferred data/predictions or c) both normal measurements and inferred data. The MDT configuration to report ML Inference can be included inside Trace Session Activation message and ML Inference can be reported as part of Trace Record, using either file-based or streaming-based methods. Consider the following examples.

Reported inferred data by a UE can be any of the existing data types, e.g., they may be predictions of existing measurements (e.g., of M1-M9). Predictions may alternatively be predictions of other measurements as long as a UE has indicated capability to provide those. Additionally, inferred data may be part of or contain the following:.

Besides management-based MDT for the UE selection, where a UE is selected based on an area related to the cells it is connected to, or other signaling-based MDT activation, where a UE is identified based on its e.g., IMSI or IMEI unique identifiers, MDT configuration could also be sent to UEs with specific ML capabilities when ML predictions are to be requested. Therefore, ML-relevant UE capabilities may be introduced, for instance, in the MDT configuration, to limit inference reporting only to selected UEs with one or more capability bits set. Besides ML, UE capabilities configuration could also include types of ML models from which predictions much be reported, e.g., "send predictions only from UEs running Reinforcement Learning", "send predictions only from UEs running Supervised Learning". As another alternative, the configuration may limit ML predictions only from UEs whose predictions meet certain accuracy requirements, such as the metrics of accuracy, precision, recall, mean squared error, to name a few. The above are additional exemplary criteria to filter out the UEs from which predictions are requested.

Now that an overview has been provided, additional detailed information is provided.

Turning to <FIG>, this figure is a signaling diagram of an example of Immediate MDT activation procedure in 5GC and NG-RAN, including the information regarding the inferred measurements, in accordance with an exemplary embodiment. <FIG> illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiment. Each of the UE <NUM>, gNB <NUM>, and network element <NUM> are assumed to perform their operations under control of their respective control modules <NUM>, <NUM>, and <NUM>.

<FIG> illustrates an exemplary procedure for activation of an MDT task, including the information on inferred measurements for the scenario where a UE attaches to the network in 5GC and NG-RAN. The illustrated scenario is an extension of the scenario in 3GPP TS <NUM>, Section <NUM>. <NUM>, and certain differences are pointed out below. In this example, it is assumed that signaling type of MDT activation is performed. Similar procedures are applicable to a management activation approach. Furthermore, the illustrated procedures are valid for both logged and immediate MDT.

Step <NUM> is a new step. The UE's ML related capabilities are known to the gNB <NUM>. The UE's ML capabilities are signaled by the UE <NUM> to the gNB <NUM>, e.g., as part UE MDT capabilities (which is a component of radio access UE capabilities). Consequently, the gNB <NUM> is made aware of a "generic" capability of the UE to perform ML operations.

However, utilization of such a "generic" ML capability at the UE may be dependent on various factors and may vary in time, e.g., if the UE has sufficient energy to perform the ML inference (e.g., if the UE is connected to power), if the UE has sufficient memory remaining (because the UE may be running other processes or ML models in parallel), and the like. Such AI/ML capability at the UE is referred to herein as "conditional" ML capability.

The selection of UEs to perform the MDT measurements including inferred measurements will be performed at the gNB <NUM>, based on the input information received from management system and the "generic" user ML capabilities information stored in the gNB. The UE may perform additional "conditional" ML capability checking prior to performing the MDT measurements according to the received configuration.

In step <NUM>, the management system (OAM <NUM>-<NUM> in this example) configures the 5GC NE (the UDM <NUM>-<NUM> in this example) with trace control and configuration parameters, including (incl. ) the MDT configuration with ML extensions. This may be via a trace session activation message with MDT configuration including (incl. ) inferred measurements information (info). In this message, the management system can indicate whether the MDT configuration is only for normal measurements, only for inferred measurements or for both. In <FIG>, many more examples for the MDT configuration are illustrated. These are described below.

For step <NUM>, the UDM <NUM>-<NUM> stores the received trace control and configuration parameters including the MDT configuration with ML extensions.

In step <NUM>, the UE <NUM> attaches to the network via at least the gNB <NUM> and the AMF <NUM>-<NUM>.

For step <NUM>, the AMF <NUM>-<NUM> sends the update location request to the UDM <NUM>-<NUM>.

In step <NUM>, the UDM <NUM>-<NUM> sends, in the response to the AMF <NUM>-<NUM>, the trace/MDT configuration parameters including, e.g., the following parameters as part of the inferred measurements information (info):.

In order to indicate the type of measurements that are to be performed, the standardized (currently-existing) bitmap can be extended in different ways. One option is to re-use the spare bit from standardized bitmap (as illustrated in <FIG>, see bit <NUM>, from 3GPP TS <NUM>) and indicate that the alternatively inferred measurements will be performed as opposed to regular measurements (e.g., the bit set to <NUM>, indicating the reporting/logging of predictions is activated) or only regular measurements will be performed (e.g., the bit set to <NUM>, indicating that the reporting/logging of predictions is not activated). Thus, spare bit (bit <NUM>) can be used to indicate that instead of providing the normal measurements M1, M4, M5, M6, the UE needs to provide a prediction of those. As another option, the spare bit <NUM> can be interpreted as "additionally" so if the bit is set to <NUM> (one) then UE provides both normal measurements M1, M4, M5, M6 as well as predictions of those. Note however, that using the spare bit is more limiting in what can be signaled since for example either all M1, M4, M5, M6 need to be reported as normal measurements or as inference with a binary indication. To make the configuration more general the spare bit (bit <NUM>) may only be used to indicate that MDT configuration is extended to also include ML predictions. In this case, another bit string can be used to indicate which are the measurements to be predicted. These measurements can be different from M1, M4, M5, M6. They could be given in the trace and/or MDT configuration from the management plane or core network. Using a single MDT configuration for normal measurements and predictions assumes that the measurements to be reported as well as the triggering/stopping conditions and the amount of measurements are the same.

If bit <NUM> is set in the bit map of <FIG>, then the UE may report predications based on AI/ML. <FIG> is an example of additional octet(s) that may be used, e.g., as part of MDT reporting, in order to report predictions. In this example, there is a second octet with entries "prediction <NUM>" and "prediction <NUM>", each of which is allotted four bits. Additional octets may be used, and different numbers of bits per prediction may be used.

The reporting trigger can be either periodical or event-based, e.g., an A2 event. In addition, the reporting may be triggered once the ML-inferred measurements with certain confidence are available at the UE. Note that the inferred measurements may not have the same semantics as the regular measurements. That is, the value of inferred measurements may indicate the probability that a measurement will be within a certain confidence interval. Therefore, separate MDT configurations may be needed in order to capture such differences between regular and inferred measurements and to allow for specifying different parameter sets, e.g., triggers, reporting intervals relevant for inference versus regular measurements. Such separation of configuration information may be particularly relevant for event-based MDT reporting. This is due to the fact that the trigger for reporting the inferred measurements may be different to regular triggers. For instance, the inferred measurements related to an A2 event may be performed even if the trigger for performing regular A2 measurements is not yet met. Different reporting triggers are illustrated in <FIG>. This figure is taken from 3GPP TS <NUM>, Section <NUM>. <NUM>, Reporting Trigger. This table illustrates the values of the "reporting trigger" parameter. The parameter is a one-octet-long bitmap and can have the values indicated in the table. The parameter shall not have the combination of periodical, event based and event based periodic reporting at the same time. Note that only one of the bits <NUM>, <NUM> and <NUM> can be set at any given time so that event-based and periodical reporting are not in conflict. <FIG> can be extended by setting the reserved bit <NUM> to <NUM> and by introducing one more bit string. This extra bit string can be used to indicate other reporting triggers as mentioned above, namely "report/log a prediction if it is within a certain confidence interval", "report/log a prediction if it is less than a distance close to a given value", and the like.

Concerning steps <NUM>-<NUM>, according to a signaling activation approach, the configured 5GC NE shall propagate the activation to selected NE's in the entire network - RAN (gNB <NUM> in this example) and core network <NUM>. For this example, in step <NUM>, the AMF <NUM>-<NUM> stores received configuration parameters, starting a trace recording session. The AMF <NUM>-<NUM> signals (step <NUM>) a create session request message to the SMF <NUM>-<NUM>, which also stores (step <NUM>) received configuration parameters, starting a trace recording session. The SMF <NUM>-<NUM> signals (step <NUM>) a create session request message to the PCF <NUM>, which also stores (step <NUM>) received configuration parameters, starting a trace recording session. The PCF <NUM> sends a create session response message to the SMF <NUM>-<NUM> and the AMF <NUM>-<NUM> in step <NUM>.

In step <NUM>, the AMF <NUM> sends the MDT configuration parameters to the gNB <NUM> via an initial context setup request message. The MDT configuration parameters may include one or more of the following.

In step <NUM>, after the gNB receives the MDT configuration, the MDT criteria will be checked. It is noted that the MDT criteria checking at the gNB is typically only relevant for immediate MDT. For logged MDT, the criteria checking is performed at the UE. The following procedures are envisaged at the gNB <NUM>.

For the gNB check in (<NUM>), the gNB is responsible for "generic" ML-capability checking, i.e., if the UE can perform ML operations or not. The actual ML operation execution at UE according to the configuration information will be dependent on the current conditions at the UE ("conditional" ML capabilities), e.g., memory or power availability, as previously described.

Steps <NUM>-<NUM> include storing the MDT configuration parameters (step <NUM>) by the gNB and the gNB signaling some or all of the parameters to the UE <NUM>. The signaling includes the gNB using an RRC connection reconfiguration message (step <NUM>) with MDT configuration including (incl. ) inferred measurements information (info), and a response by the UE in step <NUM> using an RRC connection reconfiguration complete message.

a) For logged MDT, the criteria checking is performed at the UE. Furthermore, the "conditional" criteria checking is performed at the UE. That is, the UE checks its current ML capability, e.g., with respect to available memory or available power level and matches this against the configuration information received. That is, the UE may ensure that all capabilities that are indicated as being required are supported by the UE. For instance, such information may contain the indication/rules when the inference may be performed at the UE, e.g., if the UE's memory is less than <NUM>% (fifty percent) full, and if the UE's battery is more than <NUM>% full, the UE is to perform ML (e.g., using a particular algorithm) as one possible example.

There were examples of MDT configuration that were provided beginning in step <NUM> of <FIG>, and further described above. <FIG> also illustrates a number of configuration examples for MDT configuration, in accordance with exemplary embodiments. These examples of possible configuration include the following:.

As a further example, the measurement parameters for normal measurements may include taking RSRP every <NUM> from zero to <NUM>. The measurement parameters for the inferred measurements may include predicted RSRQ after a time period, such as <NUM> minutes or five hours. An additional example concerns prediction of handover success, e.g., should the UE be handed over to another cell at a current time or a future time.

<FIG> is a signaling diagram of an exemplary immediate MDT reporting procedure, in accordance with an exemplary embodiment. <FIG> illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiment. Each of the UE <NUM>, gNB <NUM>, and network element <NUM> are assumed to perform their operations under control of their respective control modules <NUM>, <NUM>, and <NUM>. In this case the network elements <NUM> are the EM <NUM> and the TCE <NUM>-<NUM>.

<FIG> illustrates the immediate MDT reporting procedure including the reporting of inferred measurements. The message sequence chart in <FIG> is adapted based on 3GPP TS <NUM>,. Similar extensions related to inferred measurements areFigure <NUM> applicable also to logged MDT reporting (3GPP TS <NUM>, Figure <NUM>). In the figure, file-based reporting has been assumed through streaming-based reporting is also applicable.

In step <NUM>, the MDT configuration has been carried out, between the UE <NUM> and the gNB <NUM>, as illustrated in <FIG> and accompanied text.

In step <NUM>, in case of immediate MDT, the MDT-related measurements are sent in RRC as part of the existing RRC measurements. Such measurements include the measurement values inferred at UE, illustrated in <FIG> as being included in the inferred measurements reporting.

In step <NUM>, in response to the gNB receiving the MDT measurements, including the inferred measurement, the gNB <NUM> saves these to a trace record.

Steps <NUM>. a and <NUM>. a show that multiple reporting and storing may occur before the trace records are sent. That is, there could be steps <NUM>. a to <NUM>. x, and <NUM>. a to <NUM>. x, where "x" is some configured amount of reporting occasions.

For step <NUM>, the trace records are sent to the TCE <NUM>-<NUM> either directly or via the EM <NUM> (but note the EM can instead reside in the gNB, as illustrated by reference number <NUM>).

<FIG> illustrates an option where multiple reports are stored according to file-based methods. <FIG> is a signaling diagram of an exemplary immediate MDT reporting procedure, in accordance with an exemplary embodiment, and illustrates another option where reports are sent after reception. This corresponds to streaming-based methods. In this example, there is a step <NUM> after step <NUM> and a step <NUM>. a after step <NUM>. a, where the MDT measurements are stored only briefly prior to being sent.

Turning to <FIG>, split into <FIG> and <FIG>, this figure is a logic flow diagram performed by a UE for AI/ML data collection and usage. Blocks <NUM>, <NUM>, <NUM>, and <NUM> are in <FIG>, and blocks <NUM>-<NUM> are in <FIG>. This figure also illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiment. In this example, the UE <NUM> performs the operations in the blocks, e.g., under control of the control module <NUM>.

In block <NUM>, the UE <NUM> communicates it ML capability to network. See also block <NUM>. As an example, the capability message may indicate capability for the machine learning of the user equipment at a current time instance. For instance, whether or not the UE <NUM> has any ML capability to perform predictions or not and, if the UE has ML capability, what that capability is (e.g., in terms of MDT). For instance, ML capability can define which types of algorithms can be used by the UE (e.g., whether UE can use Reinforcement Learning, Supervised or Unsupervised Learning methods), with which accuracy the UE can provide measurements, with which frequency these predictions can be provided to network in terms of the amount of predictions that a UE is willing to provide, how many layers of a Neural Network the UE can support, and the like. The UE-related capability may additionally or alternatively include criteria related to internal state of the UE such as processing power, memory availability, battery/other power (e.g., whether connected to a plug-in power source), and the like. That is, the ML capability indication may also be dependent on the UE's internal state, e.g., residual battery, memory, and the like.

In further detail, management(area)-based MDT or other network function using ML may instruct UEs in a certain area to provide measurements (in an example predictions or other inferencing) but this instruction does not mean that all those UEs within some area will have the necessary capability. So, the network may request measurements for UEs having a certain capability that are in a given area. The rest of the UEs in the area for which the capability is not matched, these UEs do not report. Thus, ML capability is another filtering technique to down-select UEs which will be selected to provide AI/ML measurements (e.g., predictions) to the network. In order to achieve this, one option that may be performed is illustrated by block <NUM>, where the UE receives a message having a configured capability (e.g., the capability the network requests) from the access node. The UE matches the configured capability requested by the network with the capability transmitted by the user equipment. As indicated by block <NUM>, the capability may be only an ML capability, a UE-related capability, or some combination of these. For instance, "perform ML Algorithm A to determine Inference B, but only when connected to plug-in power or batter level is above <NUM> percent".

The UE uses the configured capability to conduct the measuring and the predicting. For instance, assume the ML capability of the UE includes multiple algorithms such as Reinforcement Learning, Supervised or Unsupervised Learning methods. This capability is communicated in block <NUM>, and the network selects Reinforcement Learning (as one example), and sends this as the configured capability in step <NUM> to the UE. The UE then uses the Reinforcement Learning method.

Similar to this, and as another example, block <NUM> indicates that the UE can communicate (block <NUM>) a prediction algorithm as an ML algorithm that was used or may be used. In block <NUM>, the network could indicate (as a configured capability) that particular prediction should be used, and the UE then matches the configured capability with the capability the UE sent in block <NUM>.

In block <NUM>, the UE <NUM> receives configuration instructing the UE to report (e.g., as part of MDT) its ML actions/inference in response to the UE performing local ML. Note that block <NUM> may be performed with block(s) <NUM> or <NUM>. Additionally, blocks <NUM> and <NUM> may be reversed or combined. As indicated by block <NUM>, the configuration for the UE may be received from an OAM element or another network element, e.g., via the gNB <NUM>.

In a further example, the ML configuration by the network towards the UE may also trigger the creation of additional variables to store the prediction information. See block <NUM>. For example, even though for immediate MDT, the UE does not store internally the measurements but reports them (real-time) to the network, in case of immediate ML inference reporting, the UE may need to store internally inference information if the latter is needed as an intermediate step to calculate the measurement for reporting.

In block <NUM>, the local ML may include predictions or other inferences. A prediction is one type of inference, where a value for a wireless network parameter is inferred in a temporal manner, e.g., at some point after the inference is made. Inferencing is not restricted to predictions, however. For example, real-time wireless network parameters may be inferred. The UE might infer, based on information available to it, parameter(s) the network should measure. The network can then compare the parameter(s) from the UE with the parameter(s) the network actually measures.

The type of predictions or other inferences may depend on the RRC state of the UE, namely whether the UE is in RRC Connected state or whether the UE is in RRC Idle or Inactive states. For example, a UE in RRC Connected state may provide predictions of RSRP/RSRQ/SINR signal strength, of location information, Handover Success Rate over a cell boundary, which may be utilized by the network in real-time. On the other hand, a UE in RRC Idle or Inactive states may estimate additional measurements, for instance insufficient coverage and related information such as how long a UE might have been in a coverage hole, the size of the coverage hole, and the like, which may be reported to the network when the UE is connected again. Such additional information derived using ML may support the network in non-real-time optimization. As a further example, in the case of coverage holes, an idle-mode UE would not "detect" coverage holes because the UE is not connected to the network (i.e., is not in a connected state) but the UE may infer via ML the conclusion that the UE is in a coverage hole or information about the coverage hole, such as the size of the hole, or the area the hole spans, and provide this inference a-posteriori to the network.

Also, predicted values versus actual values may be reported by using the accuracy metrics described earlier. As an example, a UE <NUM> may have predicted several minutes in a coverage hole, but the actual time may have been longer (or shorter), and the predicted and actual values can be reported. This deviation from the actual values could be also provided to the network through the accuracy metrics, in this case through a mean square error metric for example.

In block <NUM>, the UE determines whether the UE is ML capable. If not (block <NUM> = No), then normal logged and immediate MDT is performed by the UE according to the MDT Configuration. If it is ML Capable (block <NUM> = Yes), the rest of the flowchart is performed, starting with block <NUM>.

In block <NUM>, the UE determines whether there has been a trigger for ML actions/inference. For instance, the trigger may be periodic (e.g., perform MDT once every time period), or based on other criteria such as a handover or radio link failure. The trigger may also be a sudden decrease in UE's performance which can trigger ML at the UE. As indicated by block <NUM>, however, the trigger could be based on factors such as energy availability and/or memory availability at the UE. In other words, if the UE has less than a threshold battery level and/or a threshold of memory, ML actions/inferencing may not be performed if the received MDT Configuration by the UE requires higher battery and memory performance. This is because the MDT Configuration at the UE targeted UEs with a certain ML Capability, that is not met by the current ML Capability at the UE side. There are three possibilities for block <NUM>: No, where the trigger has not occurred (or because of block <NUM>, the trigger has occurred but will not be performed); logged MDT (which may occur for UEs not in connected state); or immediate MDT (which may occur for UEs in connected state). If block <NUM> = No, the flow proceeds back to block <NUM>.

If block <NUM> = Logged MDT, in block <NUM> the UE <NUM> takes (e.g., normal and) ML measurement(s), and performs ML. Block <NUM> indicates that the performance of ML may produce future values, such as value(s) of expected coverage holes, or values of how long the user equipment might be in a coverage hole. The term "future" means, in this context, relative to when the ML is performed. Anything after performance of the ML is in the future. In block <NUM>, the UE logs measurement(s) for MDT. In block <NUM>, the UE <NUM> determines whether an exiting condition is met. If not (block <NUM> = No), the flow proceeds back to block <NUM>. If the exiting condition is met (block <NUM> = Yes), then the UE stops the measurements in block <NUM>. If the UE is not or has not transitioned into the RRC connected mode while taking ML measurements and performing ML (step <NUM> = No), the flow proceeds back to block <NUM>. If the UE is in or has transitioned into the RRC connected mode while taking ML measurements and performing ML (step <NUM> = Yes), the UE indicates (block <NUM>) availability of predictions (and/or normal measurements and/or estimated quality of predictions) to the network. When the network receives the prediction availability indication by the UE, it will send a message to the UE <NUM> to request those measurements and UE will send the logged predictions to the network as in block <NUM>. For retrieval of the logged predictions by the network the network can send a UEInformationRequest to the UE indicating request for predictions by setting to <NUM> a new field that corresponds to the predictions log (e.g., a logPredReportReq field). The UE receiving this indication, can respond to the network and send the predictions report in a variable, e.g., in a newly defined logPredReport variable, sent inside a UEInformationResponse message. The retrieval process is just an example and other procedures can be used so that the network retrieves logs of predictions stored at a UE.

If block <NUM> = Immediate MDT, in block <NUM>, the UE takes (e.g., normal and) ML measurement(s), and performs ML. Block <NUM> indicates that the performance of ML may produce future values, as previously described. The UE reports measurement(s) and//or predictions via MDT reporting/RRC Signaling in block <NUM>. The UE <NUM> determines in block <NUM> whether an exiting condition is met. If not (block <NUM> = No), the flow proceeds to block <NUM>. If an exiting condition is met (block <NUM> = Yes), the flow proceeds to block <NUM>, where the measurements are stopped.

Referring to <FIG>, this figure is a logic flow diagram performed by an access node for AI/ML data collection and usage. This figure also illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiment. The operations in <FIG> are assumed to be performed by a gNB <NUM> or other access node, e.g., under control of the control module <NUM>.

For <FIG>, some of the blocks have already been described above, such as blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. For these examples, the access node interacts with the UE as previously described. Many of the blocks in <FIG> also mirror similar blocks in <FIG>, and as such the description above applies here too. For example, both blocks <NUM> and <NUM> are related to the UE communicating capability to the access node, and the description above has most or all of the information for these blocks.

In block <NUM>, the access node receives UE communicating capability from the UE, as previously described. In block <NUM>, the access node determines and sends the configured capability to the UE. The UE would perform matching, as described above, based on the configured capability. In block <NUM>, the access node sends configuration instructing the UE to report (e.g., as part of MDT) its ML actions/inference in response to the UE performing local ML. This has already been described above. Blocks <NUM> and <NUM> have also been described above.

In block <NUM>, there could be a trigger to ML actions/inferencing. It is noted that the access node may, in certain cases, send such a trigger to the UE to cause ML actions/inferencing and/or corresponding reporting. A typical case, however, will be that the access node is reactive to the UE's logged and immediate MDT (or other inference reporting). If there is no trigger (block <NUM> = No), the access node waits. If there is a trigger relating to immediate MDT (block <NUM> = immediate MDT), the access node in block <NUM> receives report of measurement(s)/predictions/inferences via, e.g., MDT reporting.

If there is a trigger relating logged MDT (block <NUM> = logged MDT), in block <NUM>, the access node in block <NUM> receives indication of availability of predictions/inferences (and/or normal measurements and/or estimated quality of predictions/inferences). In block <NUM>, the access node requests reporting, and receives report(s) of measurement(s)/predictions/inferences via MDT reporting.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect and advantage of one or more of the example embodiments disclosed herein enables triggering of a new type of measurements corresponding to predictions and ML inference from UE to the network. Another technical effect or advantage of one or more of the example embodiments disclosed herein is providing the means to report those measurements (either in real time or through logging) to the network.

Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in <FIG>. A computer-readable medium may comprise a computer-readable storage medium (e.g., memories <NUM>, <NUM>, <NUM> or other device) that may be any media or means that can contain, store, and/or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable storage medium does not comprise propagating signals.

It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claim 1:
A method, characterized in that the method comprises:
transmitting (<NUM>), by a user equipment, a capability message to an access node in a wireless network, wherein the capability message indicates capability corresponding to machine learning of the user equipment at a current time instance;
receiving (<NUM>), by the user equipment from the access node, a configuration message for radio measurements indicating one or more sets of parameters to be measured;
receiving (<NUM>), by the user equipment, a configured capability in a message from the access node and matching by the user equipment the configured capability with the capability of the user equipment at the current time instance for ensuring that all capabilities that are indicated in the received message as being required to use machine learning are supported by the user equipment;
measuring (<NUM>, <NUM>), by the user equipment, the one or more sets of parameters;
using (<NUM>, <NUM>), by the user equipment, machine learning to infer one or more values for at least one of the parameters in the one or more sets of parameters based on the measured one or more sets of parameters and based on the received configured capability; and
reporting (<NUM>, <NUM>), from the user equipment to the access node, the inferred one or more values for the at least one parameter.