Patent Description:
In a communication network such as a <NUM> mobile communication network it is important to ensure that a certain service quality can be maintained. For this, network statistical analysis and prediction information which may be generated from information like load, resource usage, available components, state of components etc. may be monitored to be able to take measures, e.g. when overload is imminent, to avoid a drop of service quality, etc. Prediction information may be provided using a machine learning model trained for this purpose. Accordingly, efficiently training a machine learning model in a communication system context, in particular for providing network analytics (including predictions) are desirable. Document <CIT> represents a relevant piece of prior art.

According to one embodiment, a method for training a machine learning model is provided according to claim <NUM>.

The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure can be combined with one or more other aspects of this disclosure to form new aspects.

In the following, various examples will be described in more detail.

<FIG> shows a mobile radio communication system <NUM>, for example configured according to <NUM> (Fifth Generation) as specified by 3GPP (Third Generation Partnership Project).

The mobile radio communication system <NUM> includes a mobile radio terminal device <NUM> such as a UE (user equipment), a nano equipment (NE), and the like. The mobile radio terminal device <NUM>, also referred to as subscriber terminal, forms the terminal side while the other components of the mobile radio communication system <NUM> described in the following are part of the mobile communication network side, i.e. part of a mobile communication network (e.g. a Public Land Mobile Network PLMN).

Furthermore, the mobile radio communication system <NUM> includes a Radio Access Network (RAN) <NUM>, which may include a plurality of radio access network nodes, i.e. base stations configured to provide radio access in accordance with a <NUM> (Fifth Generation) radio access technology (<NUM> New Radio). It should be noted that the mobile radio communication system <NUM> may also be configured in accordance with LTE (Long Term Evolution) or another mobile radio communication standard (e.g. non-3GPP accesses like WiFi) but <NUM> is herein used as an example. Each radio access network node may provide a radio communication with the mobile radio terminal device <NUM> over an air interface. It should be noted that the radio access network <NUM> may include any number of radio access network nodes.

The mobile radio communication system <NUM> further includes a core network (5GC) <NUM> including an Access and Mobility Management Function (AMF) <NUM> connected to the RAN <NUM>, a Unified Data Management (UDM) <NUM> and a Network Slice Selection Function (NSSF) <NUM>. Here and in the following examples, the UDM may further consist of the actual UE's subscription database, which is known as, for example, the UDR (Unified Data Repository). The core network <NUM> further includes an AUSF (Authentication Server Function) <NUM> and a PCF (Policy Control Function) <NUM>.

The core network <NUM> may have multiple core network slices <NUM>, <NUM> and for each core network slice <NUM>, <NUM>, the operator (also referred to MNO for Mobile Network Operator) may create multiple core network slice instances <NUM>, <NUM>. For example, the core network <NUM> includes a first core network slice <NUM> with three core network slice instances (CNIs) <NUM> for providing Enhanced Mobile Broadband (eMBB) and a second core network slice <NUM> with three core network slice instances (CNIs) <NUM> for providing Vehicle-to-Everything (V2X).

Typically, when a core network slice is deployed (i.e. created), network functions (NFs) are instantiated, or (if already instantiated) referenced to form a core network slice instance and network functions that belong to a core network slice instance are configured with a core network slice instance identification.

Specifically, in the shown example, each instance <NUM> of the first core network slice <NUM> includes a first Session Management Function (SMF) <NUM> and a first User Plane Function (UPF) <NUM> and each instance <NUM> of the second core network slice <NUM> includes a second Session Management Function (SMF) <NUM> and a second User Plane Function (UPF) <NUM>. The SMFs <NUM>, <NUM> are for handling PDU (Protocol Data Unit) sessions, i.e. for creating, updating and removing PDU sessions and managing session context with the User Plane Function (UPF).

The RAN <NUM> and the core network <NUM> form the network side of the mobile radio communication system, or, in other words, form the mobile radio communication network. The mobile radio communication network and the mobile terminals accessing the mobile radio communication network form, together, the mobile radio communication system.

The mobile radio communication system <NUM> may further include an OAM (Operation, Administration and Maintenance) function (or entity) <NUM>, e.g. implemented by one or more OAM servers which is connected to the RAN <NUM> and the core network <NUM> (connections are not shown for simplicity). The OAM <NUM> may include an MDAS (Management Data Analytics Service). The MDAS may for example provide an analytics report regarding network slice instance load. Various factors may impact the network slice instance load, e.g. number of UEs accessing the network, number of QoS flows, the resource utilizations of different NFs which are related with the network slice instance.

Further, the core network <NUM> comprises an NRF (Network Repository Function).

The core network <NUM> may further include a Network Data Analytics Function (NWDAF) <NUM>. The NWDAF is responsible for providing network analysis and/or prediction information upon request from network functions. For example, a network function may request specific analysis information on the load level of a particular network slice instance. Alternatively, the network function can use the subscribe service to ensure that it is notified by the NWDAF if the load level of a network slice instance changes or reaches a specific threshold. The NWDAF <NUM> may have an interface to various network functions on the mobile communication network side, e.g. to the AMF <NUM>, the SMFs <NUM>, <NUM> and the PCF <NUM>. For simplicity, only the interface between the NWDAF <NUM> and the AMF <NUM> is depicted.

For example, NWDAF analytics should allow monitoring the number of UEs registered in a network slice instance and their Observed Service Experience. In addition to OAM performing SLA (service level agreement) assurance, 5GC NFs may take actions based on NWDAF slice QoE analytics to prevent further service experience degradation in the network slice instance.

The NSSF <NUM> or AMF <NUM> may for example determine when a load distribution decision is required to address an issue identified by processing the analytics result (i.e. network analysis and/or prediction information) provided by the NWDAF <NUM>. For example, when a network slice instance is detected or forecast to experience service experience degradation, new UE registrations or PDU sessions may not be assigned to that network slice instance anymore by triggering a network slice load distribution mechanism. The NSSF <NUM>, AMF <NUM> and/or OAM <NUM>, for example, may also simultaneously subscribe to both slice service experience and slice load analytics from the NWDAF <NUM>. One or multiple subscriptions to one or multiple S-NSSAI(s) and NSI(s) are possible.

To generate the network analysis and/or prediction information, NWDAF <NUM> collects input data required (e.g. to derive slice service experience analytics), i.e. information for analysis of the state of the network slice instance. The NWDAF <NUM> may obtain such kind of information by subscribing to network functions to be informed accordingly.

According to 3GPP Release <NUM> (Rel-<NUM>) the NWDAF <NUM> is decomposed into two functions.

<FIG> shows an NWDAF AnLF (Analytics Logical Function) <NUM> and an NWDAF MTLF (Model Training Logical Function) <NUM>, e.g. connected via an Nnwdaf interface.

An NWDAF <NUM> containing the Analytics logical function is denoted as NWDAF(AnLF) or NWDAF-AnLF or simply AnLF and can perform inference, derive analytics information and expose analytics service i.e. Nnwdaf_AnalyticsSubscription or Nnwdaf_AnalyticsInfo.

An NWDAF <NUM> containing the Model Training logical function is denoted as NWDAF(MTLF) or NWDAF-MTLF or simply MTLF, trains machine learning (ML) models and exposes new training services (e.g. providing trained model).

The NWDAF(AnLF) <NUM> provides an analytics service. It may be contacted by any NF (acting as service consumer) <NUM> (e.g. an AMF or SMF) to be provided with analytics information (e.g. via an Nnf interface).

Input request parameters to the NWDAF(AnLF) <NUM> by the NF <NUM> are, e.g. an Analytic ID and an S-NSSAI. The output from the NWDAF(AnLF) <NUM> are for example statistics and/or prediction (referred to as network analytics information herein) for an Analytic ID.

Examples of Analytics IDs are UE communication, UE mobility, UE behaviour, User data congestion and Network performance, etc..

<FIG> shows a flow diagram <NUM> illustrating a flow for an NWDAF service consumer <NUM> (e.g. corresponding to the NF <NUM>) to obtain analytics information from an NWDAF(AnLF) <NUM> (e.g. corresponding to NWDAF(AnLF) <NUM>).

In <NUM>, the NWDAF service consumer <NUM> subscribes to the analytics service (it may later similarly unsubscribe). The NWDAF(AnLF) <NUM> acknowledges in <NUM>.

In response to the subscription, the NWDAF(AnLF) <NUM> sends analytics information to the NWDAF service consumer <NUM> using one or more notification messages in <NUM>.

Analytics information, such as the analytics information provided by the NWDAF(AnLF) <NUM> may be determined using a machine learning model, which may for example be trained to predict need for communication resources. Such a machine learning model may be trained using federated learning.

Federated learning (FL) is a decentralized machine learning (ML) technique that trains a ML model across multiple (FL) clients using local training dataset under the control of a central server (denoted as FL server).

It typically includes multiple training iterations, wherein in each training iteration,.

The resulting version (i.e. new version of the last iteration) may then be used by a model consumer such as the NWDAF(AnLF) <NUM> which may use it to make predictions from data obtained from an environment (such as communication resource need).

In a <NUM> communication system, federated learning may for example be realized inside the 5GC for providing NWDAF analytics where an NWDAF(MTLF) is a FL server, some NWDAF(MTLF)s are the FL clients and an NWDAF(AnLF) is the consumer of the trained ML model (as in the example above) but also on top of the 5GC, in application layer, for verticals where an application in an application function (AF) is the FL server and applications in UEs are the FL clients.

Live data in the communication network may be used by the FL clients for training a machine learning (ML) model.

<FIG> shows a flow diagram <NUM> illustrating federated learning in a <NUM> system where, for example, the FL server is a first NWDAF <NUM> and the clients are second NWDAFs <NUM>.

In <NUM>, a service consumer <NUM> (e.g. an NWDAF(AnLF)) initiates training of the ML model by sending a subscription request to the FL server <NUM>.

In <NUM>, the FL server <NUM> provides FL parameters to the FL clients <NUM> (such as parameters allowing the clients <NUM> to know what kind of training data they need and an initial version of the model).

In <NUM>, each FL client <NUM> gathers training data, e.g. from an NRF <NUM> or any kind of NF <NUM> providing relevant data.

Then, multiple iterations <NUM> are performed. Each iteration includes.

An important assumption for FL is that all the clients are training the same model using similar data. For example, in speech recognition all the clients are training a model for the English language or in UE mobility analytics all MTLFs are training a model for the UEs in an urban area. Accordingly, training performance suffers in case of data heterogeneity, i.e. if a local training dataset of a FL client is quite different from the local training data of other clients. For example, e.g., in speech recognition a client may be getting data from German speaking people as local training data or, in UE mobility analytics an MTLF may be getting data for UEs in a rural area (instead of urban area) as local training data. This typically leads to a decrease of the accuracy of the global model due to the detrimental updates from such a client (having "ill-fitting" local training data". Data heterogeneity may for example occur due to temporal difference between clients' local data sets, geographical difference between clients, faulty behaviour, malware, data poisoning attacks, etc..

It should be noted that it may even be the FL server which has such as king of "ill-fitting" data which it uses as test data and so the FL server may not be able to properly judge whether a client has ill-fitting data (i.e. has provided a detrimental update) by testing. Furthermore, determining whether a client has ill-fitting local training data based on the accuracy of the client's local model in comparison to the other client's models may not properly work since, because of the partially trained model during the training, the difference between accuracies of local models can be high even if there are small difference in the local training data between clients.

<FIG> illustrates an approach to address data heterogeneity in federated learning according to an embodiment.

According to the approach illustrated in <FIG>,.

In the following, a detailed example of the approach of <FIG> is described with reference to <FIG> and <FIG>.

<FIG> shows a flow diagram <NUM> illustrating an initialization and data gathering phase of federated learning according to an embodiment.

The flow takes place between an FL server <NUM>, FL clients, wherein only the ith FL client <NUM> is depicted and considered in the following, a global data store <NUM> that contains the global test data (i.e., an ADRF (Analytical Data Repository Function) which contains data of the respective communication system) and a local data store of each FL client, wherein only the local data store <NUM> of the ith-FL client <NUM> is depicted and considered in the following.

The operations performed for (or by) the ith FL client <NUM> and the local data store <NUM> of the ith-FL client <NUM> may be performed for (or by) each of multiple FL clients.

In an initialization step <NUM>, the FL server <NUM> initializes the FL client <NUM> (e.g. by an initialization message from the FL sever <NUM> acknowledged by an acknowledgement message by the FL client <NUM>).

In a data gathering step <NUM>, the FL server <NUM> gets the global test data from the global data store <NUM> and the client <NUM> gets the local training data from the local data store <NUM> (by corresponding request and response messages).

<FIG> shows a flow diagram <NUM> illustrating a training phase of federated learning according to an embodiment.

Similarly to the flow of <FIG>, which may be followed by the flow of <FIG>, the flow of <FIG> takes place between an FL server <NUM>, FL clients, wherein only the ith FL client <NUM> is depicted and considered in the following, a global data store <NUM> that contains the global test data and a local data store of each FL client, wherein only the local data store <NUM> of the ith-FL client <NUM> is depicted and considered in the following.

The following abbreviations are used in the following:.

Again, as in the flow of <FIG>, the operations performed for (or by) the ith FL client <NUM> and the local data store <NUM> of the ith-FL client <NUM> may be performed for (or by) each of multiple FL clients.

In <NUM>, the FL server <NUM> sends, in addition to the G-Model,.

In <NUM>, the FL Client <NUM> trains the local model using L-Data and computes the accuracy of the local model on the local test data.

Now, the FL client <NUM> compares statistics of its local training data with statistics of the global data and the L-Accuracy with the G-Accuracy and one of the following is performed.

In <NUM> the FL server <NUM> aggregates the local models, i.e. determines a new version of the global model according to the received updates (if any).

<FIG> illustrates an implementation where the FL server <NUM> is implemented by an MTLF, the global data store <NUM> is implemented by any NF or AF providing global test data, the FL clients <NUM> are implemented by MTLFs and the local data stores <NUM> are implemented by any NF or AF providing local training data and local test data.

<FIG> illustrates an implementation where the FL server <NUM> is implemented by an MTLF, the global data store <NUM> is implemented by an ADRF providing global test data, the FL clients <NUM> are implemented by MTLFs and the local data stores <NUM> are implemented by ADRFs providing local training data and local test data.

<FIG> illustrates an implementation where the FL server <NUM> is implemented by an application in an AF, the global data store <NUM> is implemented by any data source providing global test data, each FL client <NUM> is implemented by an applications running on a respective UE and the local data stores <NUM> are implemented by any data source providing local training data and local test data.

<FIG> illustrates a variant of the approach to address data heterogeneity in federated learning of <FIG> according to an embodiment.

The approach of <FIG> differs from the approach of <FIG> in that the data heterogeneity detection is performed by the FL server <NUM> rather than by the FL clients <NUM>.

For this, each FL client <NUM> sends, in addition to the model update it has determined, an indication of the L-Data statistics and the L-Accuracy to the FL server <NUM>.

The FL server <NUM> may then in particular determine for each FL client <NUM> whether it should participate in the training or not (analogously to <NUM> of <FIG>) and may inform the FL client <NUM> accordingly.

So, the data heterogeneity detection logic may be in the FL clients <NUM>, <NUM>, in the FL server <NUM>, <NUM> or even both.

In summary, according to various embodiments, a method is provided as illustrated in <FIG>.

<FIG> shows a flow diagram <NUM> illustrating a method for training a machine learning model.

In <NUM>, for each of one or more federated learning clients, it is determined whether the test data of a federated learning server and the data of the federated learning clients fulfil a predetermined similarity criterion.

In <NUM>, for each of the one or more clients, if the test data of the federated learning server and the training data of the federated learning client fulfil a predetermined similarity criterion, updating a first version of the machine learning model running on the federated learning server to a second version of the machine learning model using an update which is generated, using the training data, by the federated learning client.

In <NUM>, if the test data of the federated learning server and the training data of the federated learning client fulfil do not fulfil the predetermined similarity criterion, for example, the training data (and the associated test data) of the federated learning client or the test data of the federated learning server is updated depending on whether the accuracy of an updated version of the machine learning model (according to the update generated by the federated client) on test data of the federated learning client is higher than the accuracy of the first version of the machine learning model on the test data of the federated learning server or not.

According to various embodiments, in other words, a model is updated using an update from an FL client in case the test data used by the FL server and the training data used by the FL client are sufficiently similar, e.g. in case statistics of test data used by the FL server matches statistics of training data used by the FL client. Depending on whether the FL server or the FL client performs the checking (i.e. whether the the similarity criterion is fulfilled), there is a corresponding feedback mechanism between the FL client and the FL server, e.g. a notification that the update determined by the FL client is not used (or is not to be used) for updating the model running on the FL server. Further, information for performing the checking (and possibly further checks like the accuracy check described above) is exchanged between the FL client(s) and the FL server. In particular, according to various embodiments, as described above, G-Accuracy, G-Data Statistics and the information that an FL client does not participate are communicated. Further, training and/or test data may be updated (or refreshed), in particular depending on the result of the checking.

It should be noted that updating the first version of the machine learning model to the second version of the machine learning model, may, from the point of view of the federated learning client, mean that the federated learning client transmits the update it has generated to the federated learning server. From the point of view of the federated learning server, updating the first version of the machine learning model to the second version of the machine learning model may include the aggregation of the updates generated by the federated learning clients.

The test data of the federated learning server and the training data of the federated learning client may for example fulfil the predetermined similarity criterion if and only if their statistics fulfil a predetermined similarity criterion (with regard to statistics).

It should further be noted that a new "version" (and its alternative synonyms like "release") of the machine learning model to which an existing machine learning model is updated corresponds to a new modified model obtained via local updates by one or more federated learning clients, aggregation by federated learning server or any alternation of the existing model, i.e. an update includes a modification of parameters such as (neural network) weights.

The similarity between the training data set of the one or more FL clients and the test data set of the FL server may be measured without sharing the actual data sets among the federated learning server and the one or more FL clients; rather it may be accomplished via sending some characteristics of test data, like statistics, distribution, data sparsity or other data similarity measures, from the federated learning server to each of the one or more federated learning clients or sending some characteristics of training data, like statistics, distribution, data sparsity, or other data similarity measures, from federated learning client to the federated learning server.

As in the examples described above, multiple iterations of the process described with reference to <FIG> may be performed to train the machine learning model.

The approach of <FIG> allows achieving a high accuracy of the trained model such that, in particular, the trained model works well in practical application.

ML models trained by FL according to the approach of <FIG> may be used for decision making in various contexts, e.g. an PCF, UPF, SMF, AMF, and other NFs and also AFs can use NWDAF Analytics provided by such a model for resource planning.

Inaccuracy of an ML model leads to wrong predictions, thus to wrong decisions and eventually to performance loss. For example, an inaccurate model for estimating UE mobility leads to a wrong prediction of the number of UEs thus to wrong resource planning and eventually UE performance degradation. Since the approach of <FIG> allows improving accuracy models trained by FL, more ore accurate prediction, thus better decision making and thus improved performance are achieved.

The method of <FIG> is for example carried out by a data processing system as illustrated in <FIG>.

<FIG> shows a data processing system according to an embodiment.

The data processing system comprises one or more data processing devices <NUM> (e.g. mobile terminals (UE) and/or server computers), each comprising a communication interface <NUM> (e.g. for FL client - FL server communication), a memory <NUM> (e.g. for storing a local model, global model or model update and program code) and a processing unit <NUM> (e.g. a CPU) for carrying out the various functions of the method.

The components of the a data processing device are implemented by one or more circuits. A "circuit" may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus a "circuit" may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor. A "circuit" may also be a processor executing software, e.g. any kind of computer program. Any other kind of implementation of the respective functions described above may also be understood as a "circuit".

Claim 1:
A method (<NUM>, <NUM>) for training a machine learning model characterised by comprising: Determining (<NUM>), for each of one or more federated learning clients (<NUM>, <NUM>, <NUM>, <NUM>), whether a training data of the respective federated learning client fulfils a predetermined similarity criterion to a test data of a federated learning server (<NUM>, <NUM>, <NUM>, <NUM>), and for each of the federated learning clients, if (<NUM>)the training data of the respective federated learning client fulfils the predetermined similarity criterion, updating a first version of the machine learning model running on the federated learning server to a second version of the machine learning model using an update which is generated, using the training data of the respective federated learning client, by the respective federated learning client.