Extending tracking records to gather machine learning data in wireless communication network

Abstract

The present disclosure relates to a mechanism for collecting machine learning (ML) data by using trace records from one or more network entities of a wireless communication network. To this end, an operation management and maintenance (OAM) entity is used that creates and sends a tracking configuration to a network entity (s). The trace configuration instructs each network entity to activate a trace session during the trace session and stores inference output data of the one or more ML models in one or more trace records. The tracking configuration also indicates whether and when the network entity (s) should report the tracking record (s) to a tracking collection entity (TCE) during the tracking session. By doing so, a generic framework may be provided for exploiting ML capabilities of different network entities throughout a wireless communication network. Specifically, inference data obtained by one network entity may be forwarded by the TCE to one or more other (e.g., even without ML capability) network entities for purposes of improving overall network performance.

Description

Technical Field

[0001] The present disclosure relates generally to the field of wireless communications, and more particularly to techniques for using extended trace records to collect machine learning (ML) data from network entities of a wireless communication network. Background Art

[0002] There are many ways to collect data for training artificial intelligence (AI) / ML algorithms, which are used to improve the operational efficiency of wireless communication networks and reduce the overall operating costs of wireless communication networks. For example, in the Third Generation Partnership Project (3GPP), the Network Data Analysis Function (NWDAF) is standardized, which is responsible for collecting data from other core network (CN) functions or entities and from the Operation Management and Maintenance (OAM) entity. In the OAM entity, data can be collected based on performance measurement (PM), key performance indicators (KPI), trace records (or traceable data), and minimized drive test (MDT) operations. These mechanisms are used to collect data for the purpose of training AI / ML algorithms. Typically, AI / ML algorithms are first trained, for example, using a simulator that generates synthetic data and models the actual behavior of the wireless communication network; subsequently, the AI / ML algorithm is fine-tuned on the real-time environment of the wireless communication network. This is a very time-consuming process, which also requires manual supervision.

[0003] Furthermore, different radio access networks (RAN) and CN network entities may have different ML capabilities. Currently, there is no common framework for leveraging such ML capabilities in the rest of the network entities of the wireless communication network. In other words, there is no means for exposing the data inferred by the AI / ML algorithms executed at the network entities in a cross-domain and cross-vendor manner, so that the rest of the network entities are aware of the inference output data regardless of their domain or vendor. Therefore, such inference output data of the AI / ML algorithms executed at a certain network entity cannot be used by other network entities to improve the overall performance of the wireless communication network. Summary of the invention

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features of the disclosure, nor is it intended to be used to limit the scope of the disclosure.

[0005] The object of the present disclosure is to provide a technical solution that allows collecting ML data (eg, inference output data) from network entities of a wireless communication network by using extended trace records.

[0006] The above objects are achieved by the features of the independent claims in the attached claims. Further embodiments and examples are apparent from the dependent claims, the detailed description and the drawings.

[0007] According to a first aspect, an OAM entity in a wireless communication network is provided. The OAM entity includes at least one processor and at least one memory. The at least one memory includes computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, cause the OAM entity to operate at least as follows. First, the OAM entity is caused to create a trace configuration for at least one network entity in the wireless communication network. The trace configuration includes: a first instruction to activate a trace session and store the inference output data of at least one ML model in at least one trace record during the trace session. The trace configuration also includes: a second instruction on whether and when to report at least one trace record to a trace collection entity (TCE) during the trace session. Then the OAM entity is caused to send the trace configuration to at least one network entity. By using such a trace configuration, a general framework / method for utilizing the ML capabilities of different network entities (e.g., RAN and / or CN entities) in a wireless communication network can be provided. Specifically, the inference output data provided in the (multiple) trace records from one network entity to the TCE can then be forwarded by the TCE to one or more other network entities for the purpose of improving the overall performance of the wireless communication system. Additionally, even forwarding the inference output data (collected by using trace records) to a network entity that does not itself support any ML model (i.e., a network entity that does not have ML capabilities) can enable so-called transparent support for ML and provide a means for a smooth transition towards a fully ML (native) wireless communication network.

[0008] In an exemplary embodiment of the first aspect, the tracing configuration further comprises a start triggering event and a stop triggering event. In this embodiment, the second instruction causes at least one network entity to report at least one tracing record to the TCE during the tracing session between the start triggering event and the stop triggering event. By using the start and stop triggering events, the tracing record(s) may be reported to the TCE more efficiently (e.g., in terms of time, availability, and confidence of the inference output data, etc.).

[0009] In an exemplary embodiment of the first aspect, the trace configuration further comprises a reporting rate. In this embodiment, the second instruction further causes the at least one network entity to report at least one trace record to the TCE at the reporting rate between the start trigger event and the stop trigger event. By indicating the reporting rate, the signaling load in the wireless communication network can be controlled.

[0010] In an exemplary embodiment of the first aspect, the tracing configuration further comprises at least one triggering event. In this embodiment, the second instruction causes the at least one network entity to report at least one tracing record to the TCE whenever the at least one triggering event occurs during the tracing session. By using (multiple) triggering events, (multiple) tracing records can be reported to the TCE more efficiently (e.g., in terms of time, availability, and confidence of reasoning output data, etc.).

[0011] In an exemplary embodiment of the first aspect, the trace configuration further comprises an indication of a target ML model in the at least one ML model. In this embodiment, the second instructions further cause the at least one network entity to: (i) select at least one target trace record associated with the target ML model in the at least one trace record; and (ii) report the at least one target trace record to the TCE during the trace session. By doing so, the network entity (entities) may be requested to report the trace record (s) of interest (e.g., those trace records required to improve the overall performance of the wireless communication network).

[0012] In an exemplary embodiment of the first aspect, if the at least one ML model is associated with at least one optimization problem, the trace configuration further includes an indication of a target optimization problem among the at least one optimization problem. In this embodiment, the second instructions further cause at least one network entity to: (i) select at least one target trace record associated with the target optimization problem among the at least one trace record; and (ii) report the at least one target trace record to the TCE during the trace session. By doing so, the network entity (entities) may be requested to report the trace record (s) of interest (e.g., those trace records required to improve the overall performance of the wireless communication network).

[0013] In an example embodiment of the first aspect, the first instructions further cause at least one network entity to store at least one of the following in at least one trace record: non-ML communication data; information about inference confidence of at least one ML model; training accuracy of at least one ML model; and at least one optimization problem to be solved by at least one ML model. This additional information contained in the trace record(s) can help optimize the wireless communication network (e.g., improve its overall performance).

[0014] In an exemplary embodiment of the first aspect, if at least one network entity includes a network entity that does not support at least one ML model, the at least one memory and the computer program code are further configured to, with the at least one processor, cause the OAM entity to receive an indication from the network entity that the network entity does not support at least one ML model. By using such an indication, the OAM entity can be informed of the network entities of the wireless communication network that do not have ML capabilities.

[0015] According to a second aspect, a network entity in a wireless communication network is provided. The network entity comprises: at least one processor and at least one memory. The at least one memory comprises computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, enable the network entity to operate at least as follows. First, the network entity is enabled to: receive a trace configuration from an OAM entity in the wireless communication network. The trace configuration comprises: a first instruction to activate a trace session and store the inference output data of at least one ML model in at least one trace record during the trace session. The trace configuration also comprises: a second instruction on whether and when to report at least one trace record to a TCE during the trace session. Then, if the network entity supports at least one ML model, the network entity is enabled to decide to perform the trace configuration. The thus configured network entity can provide the inference output data in its trace record to the TCE, which can then forward them to one or more other (e.g., even non-ML capable) network entities. Therefore, a general framework / means for utilizing the ML capabilities of network entities (e.g., configured as RAN or CN entities) in a wireless communication network can be provided. The inference output data collected by using the trace record can be used to improve the overall performance of the wireless communication system.

[0016] In an exemplary embodiment of the second aspect, the tracing configuration further includes a start triggering event and a stop triggering event. In this embodiment, the second instruction causes the network entity to report at least one tracing record to the TCE during the tracing session between the start triggering event and the stop triggering event. By using the start and stop triggering events, the network entity can report (multiple) tracing records to the TCE more efficiently (e.g., in terms of time, availability, and confidence of reasoning output data, etc.).

[0017] In an exemplary embodiment of the second aspect, the trace configuration further comprises a reporting rate. In this embodiment, the second instruction further causes the network entity to report at least one trace record to the TCE at the reporting rate between the start trigger event and the stop trigger event. By using the reporting rate, a signaling load provided by the network entity in the wireless communication network can be controlled.

[0018] In an exemplary embodiment of the second aspect, the tracing configuration further comprises at least one triggering event. In this embodiment, the second instruction further causes the network entity to report at least one tracing record to the TCE whenever the at least one triggering event occurs during the tracing session. By using (multiple) triggering events, the network entity can report (multiple) tracing records to the TCE more efficiently (e.g., in terms of time, availability, and confidence of reasoning output data, etc.).

[0019] In an exemplary embodiment of the second aspect, the trace configuration further includes an indication of a target ML model in the at least one ML model. In this embodiment, the second instructions further cause the network entity to: (i) select at least one target trace record associated with the target ML model in the at least one trace record; and (ii) report the at least one target trace record to the TCE during the trace session. By doing so, the network entity can report the trace record(s) of interest (e.g., those trace records required to improve the overall performance of the wireless communication network).

[0020] In an example embodiment of the second aspect, if the at least one ML model is associated with at least one optimization problem, the trace configuration further includes an indication of a target optimization problem in the at least one optimization problem. In this embodiment, the second instructions further cause the network entity to: (i) select at least one target trace record associated with the target optimization problem in the at least one trace record; and (ii) report the at least one target trace record to the TCE during the trace session. By doing so, the network entity can report the trace record(s) of interest (e.g., those trace records needed to improve the overall performance of the wireless communication network).

[0021] In an example embodiment of the second aspect, the first instructions further cause the network entity to store at least one of the following in at least one trace record: non-ML communication data; information about inference confidence of at least one ML model; training accuracy of at least one ML model; and at least one optimization problem to be solved by at least one ML model. This additional information contained in the trace record(s) can help optimize the wireless communication network (e.g., improve its overall performance).

[0022] In an exemplary embodiment of the second aspect, the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network entity to: (i) decide not to perform trace configuration if the network entity does not support at least one ML model; and (ii) provide an indication to the OAM entity that the network entity does not support at least one ML model. By doing so, the network entity may inform the OAM entity that it does not have ML capabilities (i.e., the network entity may indicate that it cannot provide any inference output data to the TCE, not because of unavailability of data, but because the network entity does not have ML capabilities).

[0023] According to a third aspect, a method for operating an OAM entity in a wireless communication network is provided. The method starts with a step of creating a trace configuration for at least one network entity in the wireless communication network. The trace configuration includes: a first instruction to activate a trace session and store inference output data of at least one ML model in at least one trace record during the trace session. The trace configuration also includes: a second instruction on whether and when to report at least one trace record to a TCE during the trace session. Then, the method continues with the step of sending the trace configuration to at least one network entity. By using such a trace configuration, a general framework / means for utilizing the ML capabilities of different network entities (e.g., RAN and / or CN entities) in a wireless communication network can be provided. In particular, the inference output data provided in the trace record from one network entity to the TCE can then be forwarded by the TCE to one or more other network entities for the purpose of improving the overall performance of the wireless communication system. Additionally, forwarding the inference output data (collected by using the trace record) to a network entity that does not itself support any ML model (i.e., a network entity that is not ML-capable) can achieve so-called transparent support for ML and provide a means for a smooth transition towards a fully ML (native) wireless communication network.

[0024] According to a fourth aspect, a method for operating a network entity in a wireless communication network is provided. The method starts with a step of receiving a trace configuration from an OAM entity in the wireless communication network. The trace configuration includes: a first instruction to activate a trace session and store the inference output data of at least one ML model in at least one trace record during the trace session. The trace configuration also includes: a second instruction on whether and when to report at least one trace record to a TCE during the trace session. The method then proceeds with the following steps: if the network entity supports at least one ML model, a decision is made to perform the trace configuration. By doing so, the network entity can provide its inference output data in the trace record to the TCE, which can then forward them to one or more other (e.g., even non-ML capable) network entities. Therefore, a general framework / means for utilizing the ML capabilities of network entities (e.g., configured as RAN or CN entities) in a wireless communication network can be provided. By using the inference output data collected by the trace record, the inference output data can be used to improve the overall performance of the wireless communication system.

[0025] According to a fifth aspect, a computer program product is provided. The computer program product comprises a computer-readable storage medium storing computer code. When the computer code is executed by at least one processor, the at least one processor performs the method according to the third aspect. By using such a computer program product, the implementation of the method according to the third aspect in any network entity (such as the OAM entity according to the first aspect) can be simplified.

[0026] According to a sixth aspect, a computer program product is provided. The computer program product comprises a computer-readable storage medium storing computer code. When the computer code is executed by at least one processor, the at least one processor performs the method according to the fourth aspect. By using such a computer program product, the implementation of the method according to the fourth aspect in any network entity (such as the network entity according to the second aspect) can be simplified.

[0027] According to a seventh aspect, an OAM entity in a wireless communication network is provided. The OAM entity includes: a component for creating a trace configuration for at least one network entity in the wireless communication network. The trace configuration includes: a first instruction to activate a trace session and store inference output data of at least one ML model in at least one trace record during the trace session. The trace configuration also includes: a second instruction on whether and when to report at least one trace record to a TCE during the trace session. The OAM entity also includes: a component for sending the trace configuration to at least one network entity. By using such a trace configuration, a general framework / means for utilizing the ML capabilities of different network entities (e.g., RAN and / or CN entities) in a wireless communication network can be provided. Specifically, the inference output data provided in the trace record from one network entity to the TCE can then be forwarded by the TCE to one or more other network entities for the purpose of improving the overall performance of the wireless communication system. Additionally, even if the inference output data (collected by using the trace record) is forwarded to a network entity that does not itself support any ML model (i.e., a network entity that does not have ML capabilities), so-called transparent support for ML can be achieved and a means for a smooth transition towards a fully ML (native) wireless communication network can be provided.

[0028] According to an eighth aspect, a network entity in a wireless communication network is provided. The network entity includes: a component for receiving a trace configuration from an OAM entity in the wireless communication network. The trace configuration includes: a first instruction to activate a trace session and store the inference output data of at least one ML model in at least one trace record during the trace session. The trace configuration also includes: a second instruction on whether and when to report at least one trace record to the TCE during the trace session. The network entity also includes: a component for deciding to execute the trace configuration if the network entity supports at least one ML model. The thus configured network entity can provide its inference output data in the trace record to the TCE, which can then forward them to one or more other (e.g., even those without ML capabilities) network entities. Therefore, a general framework / means for utilizing the ML capabilities of network entities (e.g., configured as RAN or CN entities) in a wireless communication network can be provided. The inference output data collected by using the trace record can be used to improve the overall performance of the wireless communication system.

[0029] Other features and advantages of the present disclosure will become apparent upon reading the following detailed description and examining the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The present disclosure is explained below with reference to the accompanying drawings, in which:

[0031] Figure 1 A block diagram of an operations administration and maintenance (OAM) entity is shown according to an example embodiment;

[0032] Figure 2 A method for operating according to an example embodiment is shown. Figure 1 A flowchart of a method of an OAM entity shown in;

[0033] Figure 3 A block diagram of a network entity according to an example embodiment is shown;

[0034] Figure 4 A method for operating according to an example embodiment is shown. Figure 3 A flowchart of a method of a network entity shown in;

[0035] Figure 5 An interaction diagram illustrating how to activate a trace session at different network entities during a protocol data unit (PDU) session establishment procedure according to an exemplary embodiment is shown; and

[0036] Figure 6 An interaction diagram is shown explaining a process for reporting trace records from a network entity to a trace collection entity (TCE) according to an exemplary embodiment. DETAILED DESCRIPTION

[0037] Various embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. However, the present disclosure may be embodied in many other forms and should not be construed as being limited to any specific structure or function discussed in the following description. On the contrary, these embodiments are provided to make the description of the present disclosure detailed and complete.

[0038] According to the specific implementation, it will be apparent to those skilled in the art that the scope of the present disclosure covers any embodiment thereof disclosed herein, whether the embodiment is implemented independently or in conjunction with any other embodiment of the present disclosure. For example, the apparatus and method disclosed herein can be implemented in practice by using any number of embodiments provided herein. In addition, it should be understood that any embodiment of the present disclosure can be implemented using one or more elements presented in the attached claims.

[0039] Any embodiment described herein as an "example embodiment" should not be construed as preferred or advantageous over other embodiments unless otherwise stated.

[0040] In addition, although numerical terms such as "first", "second", "third" and the like may be used herein to describe various elements or features, these elements or features should not be limited by the numerical terms. The numerical terms are only used herein to distinguish one element or feature from another element or feature. For example, the first instruction discussed below may be referred to as the second instruction, and vice versa, without departing from the teachings of the present disclosure.

[0041] According to the example embodiments disclosed herein, a user equipment (UE) may refer to an electronic computing device configured to perform wireless communication. UE may be implemented as a mobile station, a mobile terminal, a mobile subscriber unit, a mobile phone, a cellular phone, a smart phone, a cordless phone, a personal digital assistant (PDA), a wireless communication device, a desktop computer, a laptop computer, a tablet computer, a gaming device, a notebook, a smart book, an ultrabook, a medical mobile device or instrument, a biometric sensor, a wearable device (e.g., a smart watch, smart glasses, a smart wristband, etc.), an entertainment device (e.g., an audio player, a video player, etc.), a vehicle component or sensor (e.g., a driving assistance system), a smart meter / sensor, an unmanned vehicle (e.g., an industrial robot, a quadcopter, etc.) and its components (e.g., an autonomous vehicle computer), an industrial manufacturing device, a global positioning system (GPS) device, an Internet of Things (IoT) device, an industrial Internet of Things (IIoT) device, a machine type communication (MTC) device, a group of large-scale IoT (MIoT) or large-scale MTC (mMTC) devices / sensors, or any other suitable mobile device configured to support wireless communication. In some embodiments, a UE may refer to at least two co-located and interconnected UEs defined thereby.

[0042] As used in the example embodiments disclosed herein, a network entity may refer to an entity or node in any one of a radio access network (RAN) and a core network (CN). It should be noted that a CN may refer to a network intended for connecting different RAN entities or nodes by providing appropriate interfaces between them. A CN may also provide a gateway to other networks, such as a data network (DN). A network entity may also be a UE that indirectly receives and executes a trace configuration after being forwarded by a receiving RAN node. In addition, a network entity may also be a newly defined entity in the network architecture that is configured to receive and execute a trace configuration.

[0043] As part of the RAN, the network entity may be implemented as a fixed communication point / communication node for a UE in a specific wireless communication network. More specifically, the RAN network entity may be used to connect the UE to the DN via the CN, and may be referred to as a base transceiver station (BTS) in 2G communication technology, as a NodeB in 3G communication technology, as an evolved NodeB (eNodeB or eNB) in 4G communication technology, and as a gNB in ​​5G new radio (NR) communication technology. In the case of a separate architecture, the network entity may be, for example, a gNB central unit control plane (gNB-CU-CP) node, a gNB CU user plane (gNB-CU-UP) node, or a gNB distributed unit (gNB-DU). The RAN network entity may serve different cells, such as macro cells, micro cells, pico cells, femto cells, and / or other types of cells. A macro cell may cover a relatively large geographic area (e.g., a radius of at least several kilometers). A micro cell may cover a geographic area with a radius of less than two kilometers. A pico cell may cover a relatively small geographic area, such as an office, a shopping mall, a train station, a stock exchange, etc. A pico cell may cover an even smaller geographic area (eg, a home).

[0044] As part of the CN, the network entity may also refer to any CN network function, such as access and mobility management function (AMF), session management function (SMF), unified data management (UDM), user plane function (UPF), policy control function (PCF), etc. AMF supports termination of non-access stratum (NAS) signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. SMF supports session management (session establishment, modification, release), UE IP address allocation and management, dynamic host configuration protocol (DHCP) function, termination of NAS signaling related to session management, downlink (DL) data notification, and traffic steering configuration of UPF for appropriate traffic routing. UDM supports authentication and key agreement (AKA) credential generation, user identity processing, access authorization, and subscription management. UPF supports packet routing and forwarding, packet inspection, quality of service (QoS) processing, acts as an external protocol data unit (PDU) session point interconnected with DN, and is the anchor point for intra-radio access technology (RAT) and inter-RAT mobility. PCF supports the unified policy framework, providing policy rules to the control plane (CP) functions and accessing subscription information for policy decisions in the unified data repository (UDR).

[0045] According to example embodiments disclosed herein, an OAM entity may refer to an entity configured to use different data as a basis for optimizing network management, customer experience analysis, service assurance, incident management, etc. As such data, the OAM entity may use ML data (e.g., reasoning output data) from different network entities, etc., which may be collected by using trace records at a trace collection entity (TCE). The TCE may be an entity residing in the OAM itself, or may be a network entity or node external to the OAM control. In the latter case, the TCE is defined by the IP address of the node responsible for performing the trace record collection.

[0046] As used in the example embodiments disclosed herein, the wireless communication network in which the OAM entity and one or more network entities communicate with each other may refer to a cellular or mobile network, a wireless local area network (WLAN), a wireless personal area network (WPAN), a wireless wide area network (WWAN), a satellite communication (SATCOM) system, or any other type of wireless communication network. Each of these types of wireless communication networks supports wireless communication according to one or more communication protocol standards. For example, a cellular network may operate according to a global system for mobile communications (GSM) standard, a code division multiple access (CDMA) standard, a wideband code division multiple access (WCDM) standard, a time division multiple access (TDMA) standard, or any other communication protocol standard, a WLAN may operate according to one or more versions of the IEEE 802.11 standard, a WPAN may operate according to an infrared data association (IrDA), wireless USB, Bluetooth or, ZigBee standard, and a WWAN may operate according to a global interoperability for microwave access (WiMAX) standard.

[0047] According to example embodiments disclosed herein, trace records or simply traces may refer to subscriber, device, and service traces. The general concept of trace definition and management is given in 3GPP. More specifically, a trace record at a network entity may be a collection of traceable data collected based on trace control and configuration parameters. A trace record may have two dimensions, namely, scope and depth. The trace scope may identify the network entity and the interface to be traced, while the trace depth may define the level of detail of the traceable data to be retrieved. The trace depth is specified during activation of a trace session.

[0048] According to 3GPP, the trace depth can have the following levels: Maximum, Minimum, Medium, MaximumWithoutVendorSpecificExtension, MinimumWithoutVendorSpecificExtension, and MediumWithoutVendorSpecificExtension. The Maximum, Minimum, and Medium levels allow tracing of vendor-specific data. The Maximum (or MaximumWithoutVendorSpecificExtension) level allows logging of all traceable data in an encoded format. The Minimum (or MinimumWithoutVendorSpecificExtension) level allows retrieval of a decoded subset of traceable data contained in a signaling interface message.

[0049] There are two ways to configure and activate a trace session, management-based and signaling-based activation methods.

[0050] In the management-based activation method, the management system (e.g., OAM entity) provides the trace configuration directly to the network entity, which should not propagate it further to other network entities. In contrast, in the signaling-based activation method, depending on the received trace control and configuration parameters, the configured network entity should propagate the activation to the selected network entities in the entire network, namely, the RAN and CN entities. After receiving the trace control and configuration parameters, the network entity should activate the trace session. The collected trace records are reported to the TCE. The trace reporting method can be file-based or stream-based. By using the collected trace records and additional information (e.g., performance management (PM) data, configuration management (CM) data, different alarms and notifications, etc.), the ML model can be trained by the OAM entity, and then the trained ML model can be used on the UE side or the network side. As an example, the trained ML model can be configured to predict when to prepare for switching and towards which cell to switch.

[0051] As pointed out before, different RAN and / or CN network entities in a wireless communication network may have different ML capabilities. The prior art does not disclose a general framework for utilizing such ML capabilities of these RAN and / or CN network entities in the rest of the wireless communication network. Therefore, ML data (also referred to as inference output data) inferred by a certain ML model at a certain network entity cannot be used by other network entities to improve the overall network performance.

[0052] The need for such a common (standardized) framework / means for leveraging the ML capabilities of the RAN and / or CN entity(ies) may also be driven by the following facts:

[0053] -ML is a fast-paced technology, and specifying its usage many years before it is actually used in a product will be nearly impossible.

[0054] - ML inference performed at different CN and / or RAN network entities may take into account many different characteristics, which should not be specified separately and should not utilize separate channels / interfaces to distribute the inference output data;

[0055] - ML inference performed at certain CN and / or RAN network entities can be efficiently utilized by other CN and / or RAN network entities;

[0056] - Extensive dedicated ML capability signaling should be avoided, e.g., telling which network entities have ML capabilities and which other network entities will be able to leverage their reasoning output data;

[0057] - Network function vendors most likely do not want to expose their ML models and the data used for the ML models; however, ML inference performed at certain network entities can improve overall network performance, for example, by providing supplementary information about the predicted state;

[0058] -Even at network entities that do not natively support any ML models (i.e., network entities that do not have ML capabilities), leveraging the inference output data available in the wireless communication network can enable so-called transparent support for ML and provide a means for a smooth transition towards fully ML (native) wireless communication networks.

[0059] The example embodiments disclosed herein provide a technical solution that allows the above-mentioned disadvantages specific to the prior art to be mitigated or even eliminated. Specifically, the technical solution disclosed herein relates to a mechanism for collecting ML data by using extended trace records from one or more network entities (e.g., RAN and / or CN entities) of a wireless communication network. To this end, an OAM entity is used, which creates and sends a trace configuration to a network entity (multiple entities) in the wireless communication network. The trace configuration instructs each network entity to activate a trace session during the trace session and store the inference output data of one or more available ML models in one or more trace records. The trace configuration also instructs the network entity (multiple entities) when to report (multiple) trace records to the TCE during the trace session. By doing so, a general framework for utilizing the ML capabilities of different network entities throughout the wireless communication network can be provided. Specifically, the inference output data obtained by one network entity can be forwarded by the TCE to one or more other (e.g., even those without ML capabilities) network entities for the purpose of improving overall network performance.

[0060] Figure 1 1 shows a block diagram of an OAM entity 100 according to an example embodiment. The OAM entity 100 is intended to communicate with one or more network entities (e.g., RAN and / or CN entities) in any of the wireless communication networks described above. Figure 1 As shown in FIG. 1 , OAM entity 100 includes processor 102, memory 104, and transceiver 106. Memory 104 stores processor executable instructions 108, which, when executed by processor 102, cause processor 102 to perform aspects of the present disclosure, as will be described in more detail below. It should be noted that Figure 1The number, arrangement, and interconnection of the constituent elements constituting the OAM entity 100 shown in are not intended to be any limitation of the present disclosure, but are merely intended to provide a general idea of ​​how the constituent elements are implemented within the OAM entity 100. For example, the processor 102 may be replaced with several processors, and the memory 104 may be replaced with several removable and / or fixed storage devices, depending on the specific application. In addition, in some embodiments, the transceiver 106 may be implemented as two separate devices, one of which is used for receiving operations and the other is used for sending operations. Regardless of its implementation, the transceiver 106 is intended to be able to perform the different operations required to perform data reception and transmission, such as, for example, signal modulation / demodulation, encoding / decoding, etc. In other embodiments, the transceiver 106 may be part of the processor 102 itself.

[0061] The processor 102 may be implemented as a CPU, a general-purpose processor, a special-purpose processor, a microcontroller, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a complex programmable logic device, etc. It should also be noted that the processor 102 may be implemented as any combination of one or more of the above. As an example, the processor 102 may be a combination of two or more microprocessors.

[0062] The memory 104 may be implemented as a classic non-volatile or volatile memory used in modern electronic computers. As examples, non-volatile memory may include read-only memory (ROM), ferroelectric random access memory (RAM), programmable ROM (PROM), electrically erasable PROM (EEPROM), solid-state drive (SSD), flash memory, magnetic disk storage devices (such as hard disk drives and tapes), optical disk storage devices (such as CDs, DVDs, and Blu-ray discs), etc. As for volatile memory, examples thereof include dynamic RAM, synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), static RAM, etc.

[0063] The processor-executable instructions 108 stored in the memory 104 may be configured as a computer-executable program code that causes the processor 102 to perform aspects of the present disclosure. The computer-executable program code for performing the operations or steps of aspects of the present disclosure may be written in any combination of one or more programming languages, such as Java, C++, etc. In some examples, the computer-executable program code may be in the form of a high-level language or in a pre-compiled form and dynamically generated by an interpreter (also pre-stored in the memory 104).

[0064] Figure 2A flow chart of a method 200 for operating an OAM entity 100 according to an example embodiment is shown. The method 200 starts with step S202, where the processor 102 creates a trace configuration for one or more network entities in a wireless communication network. The trace configuration includes: a first instruction to activate a trace session and store the inference output data of one or more ML models in one or more trace records during the trace session. The term "inference" is used herein in its ordinary meaning accepted in the ML field, that is, to refer to the process of making predictions using a trained ML algorithm. Correspondingly, the inference output data used in the embodiments disclosed herein are those data obtained as a result of the inference process. For example, each inference result of each ML model can be stored in a separate trace record. The OAM 100 itself can download or configure (multiple) ML models at each network entity, so that the OAM 100 can request the corresponding inference output data for a specific one or more ML models. As an alternative, the OAM 100 can request the inference output data of (multiple) ML models described in a general manner (for example, it can refer to a general problem under consideration, such as "ML energy saving", "ML load balancing", "ML mobility enhancement", etc.). The trace configuration also includes: a second instruction on whether and when to report at least one trace record to the TCE during the trace session. For example, the second instruction may be an instruction to cause each configured network entity to report inference output data whenever inference output data is generated by the (multiple) ML models. It is also assumed that the trace configuration also includes all parameters required for trace session activation; these parameters may be, for example, the same as defined in 3GPP. Then, the method 200 proceeds to step S204, where the processor 102 (e.g., by means of the transceiver 106) sends the trace configuration to each of the network entities.

[0065] If the second instruction is an instruction not to report trace record(s) to the TCE during the trace session, each configured network entity may also not report the trace record(s) but instead log them for future reporting (eg, after the trace session is deactivated).

[0066] In some example embodiments, the tracing configuration may include additional information, and the second instruction may be an instruction to cause each configured network entity to report (multiple) tracing records according to the additional information. For example, the tracing configuration may additionally indicate at least one of the following items:

[0067] - when the reporting should start and when it should stop (e.g., a trace configuration may include start and stop trigger events between which trace record(s) should be reported to the TCE; such start and stop trigger events may be associated with the presence / availability of inference output data at the configured network entity, confidence values ​​of the inference output data, etc.),

[0068] - which communication interface(s) should be used to report the trace record(s) to the TCE; - the reporting rate at which the reporting should be done (e.g., every certain number of milliseconds, or every time a new inference result is available / obtained); and

[0069] - One or more individual triggering events that, when occurring, may cause each configured network entity to report (multiple) trace records to the TCE during the trace session (again, such individual triggering events may be associated with the presence / availability of inference output data at each configured network entity, confidence values ​​of the inference output data, etc.).

[0070] In an example embodiment, the trace configuration may also include an indication of a target ML model among the (multiple) ML models available at the configured network entity. In other words, the trace configuration may indicate from which ML model available at each configured network entity to request the inference output data. This may be implicitly indicated by using any of the existing trace parameters (e.g., trace reference values) or by adding new trace parameters to the existing trace configuration defined in 3GPP. For example, the inference output data may be requested from the ML model x1, version 3. To this end, the OAM entity 100 may store (e.g., in the memory 104) a directory of all ML models available in the RAN and / or CN. In this embodiment, each configured network entity may select one or more target trace records associated with the target ML model in the trace record and report the (multiple) target trace records to the TCE during the trace session. Since the ML model may be retrained or updated over time, the OAM entity 100 may also receive information about the update or retraining of the (multiple) ML model from each configured network entity, and in response, update its directory of all ML models accordingly. In this case, the target ML model may, for example, correspond to a new version of one of the past ML models. When OAM becomes aware of the retraining of a certain ML model, this may trigger the initiation of further collection of inference output data.

[0071] In another example embodiment, instead of requesting inference output data from a certain ML model, inference output data may be requested alternately with respect to its quantity / type (e.g., inference output data related to load prediction; in this case, load predictions from any ML model available at the configuring network entity(ies) may be provided to the TCE).

[0072] In yet another example embodiment, instead of requesting inference output data from a certain ML model, the inference output data may be alternately requested based on the optimization problem they are related to. For example, the optimization problem may be related to mobility optimization, energy saving, etc. Likewise, the optimization problem may be implicitly indicated by tracing reference values ​​or by new tracing parameters added to an existing tracing configuration defined in 3GPP. In this embodiment, each configured network entity may also select one or more target tracing records associated with the indicated optimization problem in the tracing record and report the target tracing record(s) to the TCE during the tracing session.

[0073] In an example embodiment, the first instruction may also cause each configured network entity to store at least one of the following items in the (multiple) tracking records: regular data; information about the inference confidence of the (multiple) ML model; the training accuracy of the (multiple) ML model; and at least one optimization problem to be solved by the (multiple) ML model (e.g., mobility optimization, energy saving, etc.). Regular data may refer to any data that is not inferred with the help of (multiple) ML models. In other words, regular data is non-ML communication data. For example, regular data may include data exchanged over a certain communication interface between different network entities without any involvement of ML. Some other examples of regular data are given in TS 32.423 (see Table 4.18.1).

[0074] Conventional data may also be reported in the same trace(s) as the inference output data or in one or more separate traces.

[0075] It should be noted that dedicated ML-related functional exposure of CN and / or RAN network entities is not required. ML-capable network entities that are "willing" to share the inference output data of their ML models may also provide such data in trace records to the TCE for further use. Alternatively, one or more non-ML-capable network entities (if present in those trace configurations provided with trace configurations according to method 200) may:

[0076] - simply ignore the ML reasoning related parameters in the trace configuration; or - respond to the trace configuration with an indication (in its reports / logs) that ML capabilities are not available (in this case, the network entity without ML capabilities may further signal to the OAM entity that the unreported reasoning output data is not because they do not exist (e.g. any of the trigger events mentioned above have not been met), but because the network entity does not have ML capabilities).

[0077] Figure 31 shows a block diagram of a network entity 300 according to an example embodiment. The network entity 300 may be implemented as any RAN (e.g., gNB) or CN entity (e.g., AMF) and is intended to communicate with the OAM entity 100 and any other network entity of the wireless communication network in any of the above wireless communication networks. Figure 3 As shown in FIG. 3 , the network entity 300 includes a processor 302, a memory 304, and a transceiver 306. The memory 304 stores processor executable instructions 308, which, when executed by the processor 302, cause the processor 302 to implement aspects of the present disclosure, as will be described in more detail below. It should be noted again that Figure 3 The number, arrangement, and interconnection of the constituent elements constituting the network entity 300 shown in the figure are not intended to limit the present disclosure, but are only used to provide a general idea about how the constituent elements are implemented within the network entity 300. Generally, the processor 302, the memory 304, the transceiver 306, and the processor-executable instructions 308 can be implemented in the same or similar manner as the processor 102, the memory 104, the transceiver 106, and the processor-executable instructions 108, respectively.

[0078] Figure 4 A flow chart of a method 400 for operating a network entity 300 according to an example embodiment is shown. The method 400 starts with step S402, where the processor 302 receives a trace configuration from the OAM entity 100 (i.e., the processor 102). The trace configuration may include the first instruction and the second instruction described above. In addition, the trace configuration may, for example, include any of the additional information described above (e.g., start and stop trigger events, one or more separate trigger events, a reporting rate for reporting (multiple) trace records to the TCE, etc.). The method 400 then proceeds to step S404, where the processor 302 decides to execute or implement the trace configuration if the network entity 300 supports (any of) the ML models indicated in the trace configuration. Likewise, it should be noted that if the network entity 300 does not have ML capabilities, the processor 302 may (e.g., by means of the transceiver 306) send a corresponding indication that it does not have ML capabilities to the OAM entity 100 (i.e., the processor 102). For example, not having ML capabilities may also mean that the network entity has ML capabilities, but the (multiple) ML models for which reasoning output data is requested have not yet been fully trained. If a trained and executing ML model needs to be retrained, it may also be determined that there is no ML capability, making it impossible to generate any inference output data at the current moment. If the ML function at the network entity is turned off (e.g., for energy saving purposes, etc.), it may also be indicated that there is no ML capability.

[0079] In an example embodiment, if the network entity 300 receives a tracing configuration requesting inference output data of ML model(s) that have been trained but not in execution, this may trigger the network entity 300 to put the ML model(s) into execution to produce inference output data.

[0080] Figure 5 An interaction diagram 500 is shown explaining how to activate a trace session at different network entities during a PDU session establishment procedure according to an example embodiment. In the diagram 500, it is assumed that the UE has registered in the wireless communication network, the OAM entity is configured as the OAM entity 100, and each of the AMF, UPF, SMF, PCF, and gNB is configured as the network entity 300. It is also assumed that a signaling-based trace activation method is performed in the diagram 500. Similar concepts apply to management-based trace activation methods. In addition, the diagram 500 is valid for both file-based and streaming trace reports.

[0081] The interaction diagram 500 starts with step S502, where the OAM entity sends a trace session activation indication to the UDM. The trace session activation indication implicitly includes the above-mentioned trace configuration, which indicates whether and how to report trace records, etc. The following trace control and configuration parameters may be included in the trace session activation indication sent by the OAM entity:

[0082] - Subscription Permanent Identifier (SUPI) or International Mobile Equipment Identity Software Version (IMEISV);

[0083] - Tracking references;

[0084] - Trigger events, e.g., for AMF, SMF, UPF, and PCF, including the above-mentioned trigger events related to reasoning output data reporting (e.g., the availability of reasoning output data, its certain confidence level or value, and / or validity period, etc.). For example, Table 1 below gives a non-exhaustive list of such trigger events for AMF.

[0085] Table 1

[0086]

[0087]

[0088] The triggering events for AMF may be related to existing standardized events for collecting general data (e.g., "predicted / inferred N2 or Xn handover"), but they are not limited to mere extensions of existing events. For example, if there is inference output data related to any event / state in the wireless communication network, trace logging and / or reporting can be activated.

[0089] To indicate whether regular and / or inferential output data is to be recorded, one option may be to reuse free bits from the standardized bitmap (which is shown in Table 2 below) and indicate that inferential output data is to be reported in addition to regular data (for certain standardized and non-standardized trigger events) (bit is set to 1) or that only regular data (or measurements) is to be performed (bit is set to 0).

[0090] Table 2

[0091]

[0092] Table 3 below gives a non-exhaustive list of triggering events for SMF.

[0093] Table 3

[0094]

[0095]

[0096] The bitmap extension for SMF may be performed similarly to AMF, where two spare bits may be used to encode whether the reported data should be regular data, inference output data, or both types of data should be included (see Table 4 below).

[0097] Table 4

[0098]

[0099]

[0100] The trace session activation indication sent by the OAM entity in step S502 may also include at least one of the following additional parameters:

[0101] - trace depth, including an indication of to what level of detail the inference output data should be logged in the network entity of interest (some non-limiting examples of trace depth are given in Table 5 below);

[0102] Table 5

[0103]

[0104] - A list of network entity types to be traced (it should be noted that although the example embodiments disclosed herein are related to certain network entities (such as AMF, SMF, etc.), this should not be considered as any limitation of the present disclosure; in other words, the example embodiments disclosed herein may also be applicable to other network entity types that can activate a trace session, such as, for example, a gNB Central Unit Control Plane (gNB-CU-CP) node, a gNB CU

[0105] User plane (gNB-CU-UP) nodes, gNB distributed unit (gNB-DU), etc.); - List of communication interfaces for AMF, SMF, UPF, PCF and gNB;

[0106] - The IP address of the TCE for file-based trace reporting, or the Uniform Resource Identifier (URI) of the trace reporting MnS consumer for flow-based trace reporting;

[0107] - Track report format / job type (tracked only if value "2" is specified - this parameter can be extended with additional values ​​to indicate the inference output data that should be collected);

[0108] - Additional information, such as tracking session references, etc.;

[0109] - a new parameter indicating the target ML model (and its version) from which inference output data is requested, or the amount / type of inference output data (the parameter may refer to an ML model address, such as, for example, a uniform resource locator (URL) or a fully qualified domain name (FQDN) of the ML model file); and

[0110] - an indicator that associates the inference output data to be collected with the optimization problem (e.g.,

[0111] Standardized tracking reference fields may be reused for this purpose, or new indicators may be introduced).

[0112] After step S502, the interaction diagram 500 proceeds to step S504, where the UDM stores the trace control and configuration parameters (hereinafter referred to as trace parameters) retrieved from the OAM entity, including instructions on which reasoning output data should be recorded / reported and how to record / report. Next, the interaction diagram 500 proceeds to step S506, where the UDM sends a Nudm_SDM_Notification message together with the trace parameters to the AMF. In addition, step S508 is initiated, where the AMF stores the trace parameters received from the UDM, including instructions on which reasoning output data should be recorded / reported and how to record / report. Subsequently, the interaction diagram 500 proceeds to step S510, where the AMF starts or activates the trace session according to the received trace parameters (or in other words, the received trace configuration). In the next step S512, the UE sends a PDU session establishment request to the AMF. In the next step S514, the AMF sends a "start trace" message via the NG interface (e.g., the N2 interface from the 5GC perspective).

[0113] Thereafter, the interaction diagram 500 proceeds to step S516, where the gNB stores the trace parameters received from the AMF, including indications on which reasoning output data should be logged / reported and how. The gNB starts the trace session according to the received trace configuration. The trace session shall be activated in the gNB when the gNB receives a TRACE START, INITIALCONTEXT SETUP REQUEST or HANDOVER REQUEST message with IE "Trace Activation" from the AMF and if some activities are started on the interface for which tracing has been requested, including the case where reasoning output data with a certain confidence level is available and / or when its validity time has not expired.

[0114] Next, the AMF selects an appropriate SMF and sends a Nsmf_PDUSession_CreateSMContext request to the selected SMF in steps S518 and S520, respectively. The SMF performs the NuDM_UECM_Registration procedure with the UDM and receives tracking parameters from the UDM in the next step S522. Thereafter, in the next step S524, the SMF stores the tracking parameters received from the UDM, including instructions on which reasoning output data should be recorded / reported and how to record / report, and starts a tracking session according to the received tracking configuration. The SMF selects an appropriate PCF, establishes a session management policy association with the PCF, and provides tracking parameter information to the PCF in steps S526 and S528, respectively.

[0115] In addition, the interaction diagram 500 continues to step S530, where the PCF stores the trace parameters received from the SMF, including instructions on which reasoning output data should be recorded / reported and how to record / report. Specifically, the trace parameters are stored as part of the policy association. Once the trace parameters are stored, the PCF starts a trace session according to the received trace configuration.

[0116] Subsequently, the interaction diagram 500 proceeds to steps S532 and S534, where the SMF selects an appropriate UPF and performs N4 session establishment with the UPF and provides tracking parameter information to the UPF.

[0117] Interaction diagram 500 ends with step S536, where the UPF stores the trace parameters received from the SMF, including instructions on which reasoning output data should be recorded / reported and how to record / report. The trace parameters are stored as part of the N4 session establishment, and the UPF then starts the trace session according to the received trace configuration.

[0118] Figure 6An interaction diagram 600 is shown explaining a process for reporting trace records from a network entity to a TCE according to an exemplary embodiment. In interaction diagram 600, the network entity (NE) can be any network entity (e.g., AMF or SMF) shown in interaction diagram 500. Interaction diagram 600 begins with step S602, in which the network entity performs trace configuration (i.e., activates a trace session) according to the obtained trace parameters, for example, as discussed above with reference to interaction diagram 500. Thereafter, the network entity begins recording or storing traceable data (i.e., inference output data of its (multiple) ML models) in the trace records. Once the network entity collects the requested inference output data according to the trace parameters, the network entity sends the trace records (via a file or stream) directly or via the management system of the network entity (i.e., an entity manager (EM)) to the TCE. The first option (i.e., sending the trace records directly to the TCE) can be used when the first option is supported by the network configuration and when the operator has no problem establishing and maintaining a direct connection between the network entity and the TCE. The second option (i.e., sending the trace records to the TCE via the management system) can be used when the second option is supported by the network configuration and the operator wants to reuse the already established and maintained connection between the network entity and the management system to transfer the trace records to the TCE. Similarly, if the network entity does not have ML capabilities, it can ignore the reasoning-related parameters in the trace configuration, or issue an indication to the trace configuration that ML is not supported (in its report / log). The trace records may include only conventional or only reasoning output data, as well as both conventional data and reasoning output data. For example, the content of each trace record can be extended by adding reasoning IEs, for specific interfaces, based on the trace configuration, or by using trace record extensions, as shown in Tables 6 and 7 below (it should be noted that Tables 6 and 7 are extensions of Tables 4.18.1 and 4.30.1 from 3GPP TS 32.423, respectively; in addition, the "encoding*" in Tables 6 and 7 indicates that the messages remain encoded in the format in which they were received).

[0119] Table 6 AMF trace record content extension for N1 and N8.

[0120]

[0121]

[0122]

[0123] Table 7: gNB-CU-CP trace record content extension for Uu.

[0124]

[0125]

[0126]

[0127] It should be noted that each step or operation of methods 200 and 400 and interaction diagrams 500 and 600, or any combination of steps or operations, can be implemented by various means, such as hardware, firmware and / or software. As an example, one or more of the above steps or operations can be embodied by processor executable instructions, data structures, program modules and other suitable data representations. In addition, the processor executable instructions embodying the above steps or operations can be stored on corresponding data carriers and executed by processors 102 or 302, respectively. The data carrier can be implemented as any computer-readable storage medium configured to be read by the at least one processor to execute processor executable instructions. Such computer-readable storage media may include both volatile and non-volatile media, removable and non-removable media. As an example and not a limitation, computer-readable media include media implemented in any method or technology suitable for storing information. In more detail, practical examples of computer-readable media include, but are not limited to, information delivery media, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disc (DVD), holographic media or other optical disk storage, tape, cassette, disk storage device, and other magnetic storage devices.

[0128] Although example embodiments of the present disclosure are described herein, it should be noted that various changes and modifications may be made in the embodiments of the present disclosure without departing from the scope of legal protection defined by the appended claims. In the appended claims, the word "comprising" does not exclude other elements or operations, and the word "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be advantageously used.

Claims

1. An operation administration and maintenance (OAM) entity in a wireless communication network, comprising: at least one processor; as well as at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the OAM entity to: Creating a trace configuration for at least one network entity in the wireless communication network, the trace configuration comprising: first instructions to activate a tracing session and store inference output data of at least one machine learning (ML) model in at least one tracing record during the tracing session; and second instructions regarding whether and when to report the at least one trace record to a trace collection entity (TCE) during the trace session; and The trace configuration is sent to the at least one network entity.

2. The OAM entity according to claim 1, wherein the trace configuration further comprises a start trigger event and a stop trigger event, and wherein the second instruction causes the at least one network entity to report the at least one trace record to the TCE during the trace session between the start trigger event and the stop trigger event.

3. The OAM entity of claim 2, wherein the trace configuration further comprises a reporting rate, and wherein the second instruction further causes the at least one network entity to report the at least one trace record to the TCE at the reporting rate between the start trigger event and the stop trigger event.

4. The OAM entity of claim 1 , wherein the trace configuration further comprises at least one triggering event, and wherein the second instruction causes the at least one network entity to report the at least one trace record to the TCE whenever the at least one triggering event occurs during the trace session.

5. The OAM entity according to any one of claims 2 to 4, wherein the tracing configuration further comprises an indication of a target ML model in the at least one ML model, and wherein the second instruction further causes the at least one network entity to: Among the at least one tracking record, selecting at least one target tracking record associated with the target ML model; and During the trace session, the at least one target trace record is reported to the TCE.

6. The OAM entity according to any one of claims 2 to 4, wherein: If the at least one ML model is associated with at least one optimization problem, the tracking configuration further includes an indication of a target optimization problem in the at least one optimization problem, and wherein the second instructions further cause the at least one network entity to: Among the at least one tracking record, selecting at least one target tracking record associated with the target optimization problem; as well as During the trace session, the at least one target trace record is reported to the TCE.

7. The OAM entity according to any one of claims 1 to 6, wherein the first instruction further causes the at least one network entity to store at least one of the following items in the at least one trace record: Non-ML communication data; information about inference confidence of the at least one ML model; the training accuracy of the at least one ML model; and At least one optimization problem to be solved by the at least one ML model.

8. The OAM entity according to any one of claims 1 to 7, wherein: If the at least one network entity includes a network entity that does not support the at least one ML model, the at least one memory and the computer program code are further configured to, with the at least one processor, cause the OAM entity to receive, from the network entity, an indication that the network entity does not support the at least one ML model.

9. A network entity in a wireless communication network, comprising: at least one processor; as well as at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the network entity to: Receiving a trace configuration from an operations administration and maintenance (OAM) entity in the wireless communication network, the trace configuration comprising: first instructions to activate a tracing session and store inference output data of at least one machine learning (ML) model in at least one tracing record during the tracing session; and second instructions regarding whether and when to report the at least one trace record to a trace collection entity (TCE) during the trace session; and If the network entity supports the at least one ML model, it is decided to perform the tracking configuration.

10. The network entity of claim 9, wherein the trace configuration further comprises a start triggering event and a stop triggering event, and wherein the second instruction causes the network entity to report the at least one trace record to the TCE during the trace session between the start triggering event and the stop triggering event.

11. The network entity of claim 10, wherein the trace configuration further comprises a reporting rate, and wherein the second instruction further causes the network entity to report the at least one trace record to the TCE at the reporting rate between the start trigger event and the stop trigger event.

12. The network entity of claim 9, wherein the trace configuration further comprises at least one triggering event, and wherein the second instruction causes the network entity to report the at least one trace record to the TCE whenever the at least one triggering event occurs during the trace session.

13. The network entity according to any one of claims 10 to 12, wherein the tracking configuration further comprises an indication of a target ML model in the at least one ML model, and wherein the second instruction further causes the network entity to: Among the at least one tracking record, selecting at least one target tracking record associated with the target ML model; and During the trace session, the at least one target trace record is reported to the TCE.

14. The network entity according to any one of claims 10 to 12, wherein: If the at least one ML model is associated with the at least one optimization problem, the tracking configuration further includes an indication of a target optimization problem in the at least one optimization problem, and wherein the second instructions further cause the network entity to: Among the at least one tracking record, selecting at least one target tracking record associated with the target optimization problem; as well as During the trace session, the at least one target trace record is reported to the TCE.

15. The network entity according to any one of claims 9 to 14, wherein the first instruction further causes the network entity to store at least one of the following items in the at least one tracking record: Non-ML communication data; information about inference confidence of the at least one ML model; the training accuracy of the at least one ML model; and At least one optimization problem to be solved by the at least one ML model.

16. The network entity of claim 9, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the network entity to: If the network entity does not support the at least one ML model, deciding not to perform the tracking configuration; and An indication is provided to the OAM entity that the network entity does not support the at least one ML model.

17. A method for operating an operations administration and maintenance (OAM) entity in a wireless communication network, comprising: Creating a trace configuration for at least one network entity in the wireless communication network, the trace configuration comprising: first instructions to activate a tracing session and store inference output data of at least one machine learning (ML) model in at least one tracing record during the tracing session; and second instructions regarding whether and when to report the at least one trace record to a trace collection entity (TCE) during the trace session; and The trace configuration is sent to the at least one network entity.

18. A method for operating a network entity in a wireless communication network, comprising: Receiving a trace configuration from an operations administration and maintenance (OAM) entity in the wireless communication network, the trace configuration comprising: first instructions to activate a tracing session and store inference output data of at least one machine learning (ML) model in at least one tracing record during the tracing session; and second instructions regarding whether and when to report the at least one trace record to a trace collection entity (TCE) during the trace session; and If the network entity supports the at least one ML model, it is decided to perform the tracking configuration.

19. A computer program product comprising a computer readable storage medium, wherein the computer readable storage medium stores computer code which, when executed by at least one processor, causes the at least one processor to perform the method according to claim 17.

20. A computer program product comprising a computer readable storage medium, wherein the computer readable storage medium stores computer code which, when executed by at least one processor, causes the at least one processor to perform the method according to claim 18.

Images