System and method for enabling federated learning based on network function in core network

Abstract

According to an implementation, a federated learning (FL) server network entity receives information about a local machine learning (ML) model from an FL client network entity, and the MLN network entity receives the information about the MLN model from the FL client network entity. And each local ML model in the local ML models is trained according to corresponding local training data. The respective local training data is available at a respective FL client network entity of the FL client network entities before the respective FL client network entity receives a respective FL training request. The FL server network entity aggregates the local ML model to generate an updated global ML model.

Description

[0001] Cross-reference to related applications

[0002] This patent application claims priority to U.S. Provisional Application No. 63 / 519,476, filed on August 14, 2023, entitled "System and Method to Enable NF-Based Federated Learning in 5G Core", the entire contents of which are incorporated herein by reference as if fully set forth herein. Technical Field

[0003] This disclosure generally relates to network communications, and in certain embodiments, to techniques and mechanisms for enabling network function (NF)-based federated learning in the core network. Background Technology

[0004] The Network Data Analytics Function (NWDAF) is part of the 5th-generation (5G) core network, using the mechanisms and interfaces specified for the 5G core (5GC) in TS 23.501 and TS 23.288. The NWDAF is a 5G network analytics producer that can interact with several entities to achieve different purposes. The NWDAF can perform data collection from other 5G network functions (NFs), application functions (AFs), and operations, administration, and management (OAM). The NWDAF can also retrieve information from the data and supply on-demand analytics to network analytics consumers such as other network functions (NFs), OAM, user equipment (UE), and AFs. 3GPP specifies functions for performing model training and inference analytics on the NWDAF. Each NWDAF can contain two logical functions: a model training logical function (MTLF) and / or an analytics logical function (AnLF). Figure 1This is an exemplary network diagram showing the NWDAF within the 5G core network and the interfaces (N2, N3, N4, N6) between the NWDAF and other network entities that can consume analytics from the NWDAF or provide data to the NWDAF.

[0005] MTLF trains machine learning (ML) models and exposes the trained models through existing services such as Nnwdaf_MLModelProvision and / or Nnwdaf_MLModelInfo.

[0006] AnLF performs inference based on an ML model trained with MTLF, derives analytical information (e.g., derives statistics and / or predictions based on analytical consumer requests), and exposes the analysis through services such as Nnwdaf_AnalyticsSubscription and / or Nnwdaf_AnalyticsInfo. The following table shows examples of analytical parameters (e.g., predictions generated by NWDAF AnLF) and their corresponding training data. In Table 1, M represents the name of the ML model. In Table 2, “A,” “P,” and “U” are exemplary names of data features. Examples of features may include data rate, latency, etc.

[0007] Table 1: Examples of data analysis generated by NWDAF

[0008]

[0009] Table 2: Examples of training data features required to train the ML model M in Table 1

[0010]

[0011] There is interaction between MTLF and AnLF. To retrieve an ML model from an NWDAF containing MTLF, the NWDAF containing AnLF can be locally configured with a set of IDs for the NWDAF containing MTLF and their corresponding supported analytics IDs, and / or can use the NWDAF discovery process to discover the NWDAF containing MTLF. The NWDAF containing AnLF can subscribe to / unsubscribe from the NWDAF containing MTLF that provides input parameters, including a list of analytics IDs, for which the requested ML model is used. When a subscription to a trained ML model associated with an analytics ID is received, the NWDAF containing MTLF can determine whether the existing trained ML model can be used or whether further training of the existing trained ML model is required. In the case of further training, the NWDAF containing MTLF can initiate input data collection from NF, UE, AF, and / or OAM. For each analysis ID requested by an NWDAF containing AnLF, an NWDAF containing MTLF can provide a unique pair of ML model identifiers and ML model information, which includes the ML model file address (e.g., a uniform resource locator (URL) or a fully qualified domain name (FQDN)).

[0012] Federated learning (FL) across multiple NWDAFs (e.g., Clause 5.3 of TS 23.288) is a machine learning technique in the 5G core network that trains ML models across multiple distributed NWDAFs, including one FL server NWDAF (an NWDAF containing an MTLF with server capabilities) and multiple FL client NWDAFs (NWDAFs containing an MTLF with client capabilities). When performing FL across NWDAFs, FL client NWDAFs can train ML models based on their local datasets without exchanging / sharing local datasets with the FL server NWDAF or other FL client NWDAFs. In Release 18, horizontal FL between NWDAFs is supported, where the local datasets in different FL client NWDAFs have the same feature space but different samples. Each NWDAF containing an MTLF can register its FL capability type in the network repository function (NRF) using its NF profile (i.e., if the NWDAF supports FL, the FL capability type is FL server and / or FL client).

[0013] FL server NWDAF function

[0014] The main functions of the FL server NWDAF with FL enabled include discovering and selecting FL client NWDAFs to participate in the FL process, sending requests to FL client NWDAFs to perform local model training and report local model information, generating a global ML model by aggregating local model information from FL client NWDAFs, sending the global ML model back to the FL client NWDAFs, and repeating training iterations as needed. The FL server NWDAF also needs to provide an initial model to each FL client NWDAF when the FL process is started.

[0015] FL client NWDAF function

[0016] The main functions of the FL client NWDAF with FL enabled include training the ML model requested by the FL server NWDAF locally using the local dataset available to the FL client NWDAF, reporting the trained local ML model information to the FL server NWDAF, receiving global ML model feedback from the FL server NWDAF, and repeating training iterations as needed.

[0017] Figure 2 This example illustrates the interactions between the analysis consumer, NWDAF, and data producer NF when FL is not executed to generate the requested analysis. Suppose that the predicted parameters X and Y in Table 1 need to be generated; for this, the ML model M must first be trained using the training data features in Table 2.

[0018] Figure 3 This illustrates an example of analyzing the interactions between the consumer, NWDAF server 204, NWDAF client, and data producer NF when executing the Rel-18 FL method across NWDAF. Figure 3 As shown, the NWDAF client still needs to collect input data from the data producer NF (e.g., data features A, P, U from data producers NF 201, NF 202, and NF 203, respectively, required for local training). However, NWDAF 222 and NWDAF 224 may not have access to the input data. Summary of the Invention

[0019] The methods and apparatus described in this disclosure offer overall technical advantages.

[0020] Depending on the implementation, a federated learning (FL) server network entity receives information about local machine learning (ML) models from FL client network entities. Each local ML model is trained based on its corresponding local training data. The corresponding local training data is available to the respective FL client network entity before it receives a corresponding FL training request. The FL server network entity aggregates the local ML models to generate an updated global ML model.

[0021] In some implementations, the FL client network entity may include one or more of the following: at least one core domain network entity, at least one radio access network (RAN) network entity, at least one application function (AF) entity, or at least one user equipment (UE). At least one RAN network entity may include at least one base station. At least one core domain network entity may include an access and mobility management function (AMF) entity, a policy control function (PCF) entity, a session management function (SMF) entity, a user plane function (UPF) entity, a network exposure function (NEF) entity, or a network repository function (NRF) entity.

[0022] In some implementations, the FL server network entity can determine whether a network function (NF)-based FL is needed based on the analysis identifier (ID) and the corresponding data collection requirements. The FL server network entity can then determine the mechanism used for NF-based FLs.

[0023] In some implementations, the FL server network entity can perform NF-based FL registration and discovery processes based on this mechanism.

[0024] In some implementations, the FL server network entity can send a server registration profile to the network repository function (NRF) entity. The server registration profile can indicate FL server capability information. The FL server network entity can send discovery requests to the NRF entity. The FL server network entity can receive discovery responses from the NRF entity. The discovery responses can indicate a set of candidate FL client network entities. The FL server network entity can send FL learning preparation requests to the set of candidate FL client network entities. Each FL learning preparation request in the FL learning preparation request can indicate ML model information, analysis ID, and corresponding data collection requirements. The FL server network entity can receive FL learning preparation responses from the set of candidate FL client network entities. The FL server network entity can select FL client network entities from the set of candidate FL client network entities based on the FL learning preparation responses.

[0025] In some implementations, the FL server network entity can perform an NF-based FL training process according to this mechanism. The FL server network entity can perform the NF-based FL training process through at least one of the enhanced ML model provisioning or ML model training service operations.

[0026] In some implementations, the FL server network entity can receive subscription requests from ML model consumers. The FL server network entity can send FL training requests to the FL client network entity. The FL server network entity can receive FL training responses from the FL client network entity. These FL training responses may include information about the local ML model.

[0027] In some implementations, FL client network entities can include NF entities of the same NF type.

[0028] In some implementations, FL client network entities can include NF entities of different NF types.

[0029] In some implementations, the FL server network entity can be the FL server network data analytics function (NWDAF) entity.

[0030] In some implementations, the mechanism can be a horizontal mechanism, a vertical mechanism, or a combination of both.

[0031] In some implementations, at least a portion of the local training data available at the corresponding FL client network entity can be generated by the corresponding FL client network entity.

[0032] Depending on the implementation, the FL client network entity generates or collects training data locally. After local generation or collection, the FL client network entity receives an FL training request from the FL server network entity. The FL client network entity trains a local machine learning (ML) model based on the FL training request and the training data. The FL client network entity then sends information about the local ML model to the FL server network entity.

[0033] In some implementations, the FL client network entity may include one or more of the following: at least one core domain network entity, at least one radio access network (RAN) network entity, at least one application function (AF) entity, or at least one user equipment (UE). At least one RAN network entity may include at least one base station. At least one core domain network entity may include an access and mobility management function (AMF) entity, a policy control function (PCF) entity, a session management function (SMF) entity, a user plane function (UPF) entity, a network exposure function (NEF) entity, or a network repository function (NRF) entity.

[0034] In some implementations, the FL client network entity can send a network entity registration profile to the network repository function (NRF) entity. The network entity registration profile can indicate FL client capability information. The FL client network entity can receive FL learning readiness requests from the FL server network entity. FL learning readiness requests can indicate ML model information, an analysis identifier (ID), and corresponding data collection requirements. Based on the FL learning readiness request, the FL client network entity can determine which network function (NF)-based FL corresponding to the local ML model to join with the FL server network entity. The FL client network entity can send an FL learning readiness response to the FL server network entity.

[0035] In some implementations, the FL client network entity can receive information about the updated global ML model from the FL server network entity. The FL client network entity can then update its local ML model based on the updated global ML model.

[0036] In some implementations, at least a portion of the training data available at the FL client network entity can be generated by the FL client network entity. Attached Figure Description

[0037] To gain a more complete understanding of this disclosure and its advantages, the following description is made in conjunction with the accompanying drawings, in which:

[0038] Figure 1 This is an exemplary network diagram illustrating the NWDAF within the 5G core network and the interfaces of the NWDAF to other network entities.

[0039] Figure 2 This example illustrates the interaction between the analytics consumer, NWDAF, and data producer NF when FL is not executed;

[0040] Figure 3 An example of analyzing the interactions between consumers, NWDAF servers, NWDAF clients, and data producers (NF) is shown;

[0041] Figure 4 Examples of cross-server NWDAF and data producer NF with enhanced model training capabilities are shown;

[0042] Figure 5 Examples of vertical and / or horizontal FLs between an NWDAF server and an NF enhanced with MTLF functionality, according to some implementations, are shown.

[0043] Figure 6 An example of the horizontal FL between an NWDAF FL server and an NF of the same NF type enhanced with MTLF, according to some implementations, is shown.

[0044] Figure 7 Examples of vertical FLs between NWDAF FL servers and NFs enhanced with MTLF of different NF types, based on some implementations, are shown.

[0045] Figure 8 Examples of vertical FLs between FL servers and network entities from different domains enhanced with MTLF, based on some implementations, are shown.

[0046] Figure 9A flowchart is shown of an exemplary method for an NWDAF containing MTLF, depending on some implementation, to determine whether a mechanism is needed for FL and / or which mechanism is needed for FL;

[0047] Figure 10 A diagram illustrating an exemplary process for FL registration and discovery according to some implementations is shown;

[0048] Figure 11 A diagram illustrating an exemplary process for FL registration and discovery according to some implementations is shown;

[0049] Figure 12 This is a diagram illustrating an exemplary process of interaction between an FL server (NWDAF), an FL client (NF), and an ML model consumer, according to some implementations, to perform FL.

[0050] Figure 13A A flowchart is shown illustrating the methods executed by a network of federated learning (FL) server entities according to some implementations;

[0051] Figure 13B A flowchart is shown illustrating the methods executed by federated learning (FL) client network entities according to some implementations;

[0052] Figure 14 An exemplary communication system according to some implementation methods is shown;

[0053] Figure 15 An exemplary communication system according to some implementation methods is shown;

[0054] Figure 16A and 16B Exemplary devices that can implement the methods and guidance according to this disclosure are shown according to some implementation methods;

[0055] Figure 17 It is a block diagram of a computing system that can be used to implement the devices and methods disclosed herein, based on some implementation methods.

[0056] Unless otherwise stated, corresponding numbers and symbols in different figures generally refer to corresponding parts. The figures are drawn to clearly illustrate relevant aspects of the embodiments and are not necessarily drawn to scale. Detailed Implementation

[0057] The manufacture and use of embodiments of this disclosure will be discussed in detail below. However, it should be understood that the concepts disclosed herein can be embodied in a wide variety of specific contexts, and the specific embodiments discussed herein are merely illustrative and not intended to limit the scope of the claims. Furthermore, it should be understood that various changes, substitutions, and modifications may be made to this document without departing from the spirit and scope of this disclosure as defined by the appended claims.

[0058] As specified in version 18, when a request to train an ML model is received from an NWDAF containing an AnLF, the NWDAF containing an MTLF can determine the need for FL technology based on various factors including the analysis ID (e.g., parameters used for statistical / predictive output data), the service area, or when input data cannot be directly obtained from the data producer NF due to reasons such as data security or data privacy. If the NWDAF containing an MTLF cannot act as the FL server NWDAF for the requested ML model, it first discovers and selects the FL server NWDAF from the NRF using filtering criteria (e.g., the analysis ID of the required ML model, the FL capability type (e.g., FL server)) (e.g., via the Nnrf_NFDiscovery_Request service operation), and checks whether the selected server NWDAF is currently performing a federated learning (FL) process for the analysis ID and / or the time period and service area of ​​interest.

[0059] Once the FL server NWDAF is identified, the FL server NWDAF is used to discover and select FL client NWDAFs from the NRF using filtering criteria (e.g., via the Nnrf_NFDiscovery_Request service operation). These filtering criteria include, for example, the analysis ID of the desired ML model, the FL capability type (e.g., FL client), the service area, the data availability of the client NWDAF, and / or the time period of interest.

[0060] Version 18's method has technical limitations. Due to reasons such as the data producer NF originating from a different vendor than the FL server NWDAF or the data producer NF being located in a different service area than the FL server NWDAF, the FL server NWDAF cannot directly collect data. For this FL server NWDAF to utilize FL client NWDAFs from the same vendor or located in the same service area, the FL between NWDAFs can resolve security / privacy issues. However, in order to train the desired ML model locally, each FL client NWDAF needs to collect local data from its local data producer NF (e.g., an NF within its service area) or utilize available local datasets from previously collected data (see example...). Figure 2Therefore, due to data security / privacy / access issues, a technical problem may occur where the client NWDAF is unable to collect data from the data producer NF. An Artificial Intelligence Machine Learning (AIML) work task (WT) version 19 (SP-230759) has been selected to address this deficiency.

[0061] The current FL solution version 18 does not address the data security / privacy / access issues arising when the FL client / server NWDAF cannot obtain local data from the data producer NF. In the example, the ML model that needs to be trained based on user plane function (UPF) data resides on a private network (i.e., the data producer NF of this ML model). However, due to data security / privacy concerns, the UPF cannot share / exchange its local data with the FL server / client NWDAF on a commercial network. Therefore, a new FL-based technical solution is needed to address the data collection limitations present in data producer NFs with data security / privacy issues.

[0062] This disclosure describes a technique for enabling FL (Flexible Interaction) between a data producer NF (or other network entity) and multiple NFs acting as FL clients by enhancing the MTLF functionality of the data producer NF. In doing so, data collection from the data producer NF, where data security / privacy / access issues exist, can be avoided. In other words, the data producer NF itself can participate in FL by locally training an ML model using its available local data, while the FL server capabilities are still implemented on the NWDAF (see, for example...). Figures 4 to 8 ). Figure 8 It is shown that the NF is not limited to the 5GC NF, and the disclosed technology can be extended to other network entities, such as UEs and gNBs from different domains (e.g., radio access network (RAN) domain, core network domain). Therefore, the described FL architecture can be a technical solution for Work Task 3 of AIML Enhancement Research / Work Item Version 19 (i.e., 'Investigate the following potential enhancements to enable 5G systems to assist in cross-domain (e.g., UE, 5G core network, application, OAM) application of AI training and inference (so-called "Vertical Federated Learning (VFL)")'). In other words, by enhancing network entities from different domains with MTLF functionality, the FL technology, currently only implemented between NWDAFs in the core network domain, can be extended across different domains.

[0063] Version 18 does not support using NF as an FL client. Figure 4 As shown, future versions may support NF as an FL client. Figure 4 Examples of performing FL are shown, based on some implementations of cross-server NWDAF 404 and data producer NFs enhanced with model training capabilities (e.g., NF 401 to 403, etc.). Although Figure 4 Not shown, but can support NWDAF servers connecting to one or more NFs as clients and one or more NDWAF clients. Points 1 through 10 of the following examples describe existing FL methods (e.g., Figure 3 (Points 1 through 7), problem description (point 8), and the described FL technique (e.g., Figures 4 to 8 A comparison between (points 9 and 10). For example... Figure 7 As shown, the described FL technology can also address the technical problems of WT 3.1 (e.g., "how to support cross-domain feature determination and alignment when applying VFL operations") and WT 3.2 (e.g., "how to identify / select the required NFs corresponding to local features within the 5G core network domain for collaborative VFL operations (i.e., training or inference)"). That is, as... Figure 7 As shown, the characteristics of applying vertical federated learning (VFL) operations can be determined based on the NF type. For Figure 7 In the example above, the FL operation requires training based on AMF, UPF, and PCF data, where these NF types can be mapped to the aforementioned data features A, U, and P.

[0064] Regarding point 1, there are data analysis consumers located inside the network (e.g., 5GC network functions) / outside the network (e.g., application functions (AF)), such as NF 206, AF 208, UE 210, and management function 212. For example, NF 206 could be an access and mobility management function (AMF) inside the network that requires UE mobility analysis (UE location prediction, etc.) generated by server NWDAF 204.

[0065] Regarding point 2, the analytics consumer can send an analytics request to NWDAF (e.g., NWDAF 204).

[0066] Regarding point 3, NWDAF 204 may require training the corresponding ML model for the requested analysis before NWDAF 204 performs inference (generative analysis).

[0067] Regarding point 4, training ML models may require training data.

[0068] Regarding point 5, in the existing solution, federated learning is triggered when NWDAF 204 does not have the right to collect training data from the source data producer (the data producer is another NF in 5GC (e.g., NF 201 to 203)). For example, NWDAF 204 (FL server) connects to NWDAF 222 and NWDAF 224 (FL client), and the connected client has access to the training data.

[0069] Regarding point 6, NWDAF 222 and NWDAF 224 collect training data from data producers NF (e.g., NF 201 to 203) and each train their ML models locally based on the collected training data. Then, FL clients (e.g., NWDAF 222 and NWDAF 224) share the locally trained models with NWDAF 204 (FL server).

[0070] Regarding point 7, in existing solutions, NWDAF 222 and 224 still require training data to be collected from data producers NF (e.g., NF 201 to 203).

[0071] However, regarding point 8, due to privacy or security limitations, NWDAF 222 or 224 may not be able to collect training data from data producers NF (e.g., NF 201 to 203).

[0072] In some implementations, the server can execute an NWDAF 404 error. Figure 2 All operations can be performed by NWDAF 204 in the middle, and data producers can perform operations by NF 401 to 403. Figure 2 All operations that data producers NF 201 to 203 can perform. Additionally, regarding point 9, this disclosure describes a technique for enhancing NFs with model training capabilities, enabling the enhanced NFs (e.g., NF 401 to 403) to act as FL clients and train local ML models based on their own data. Therefore, instead of sharing raw training data with NWDAFs (e.g., NWDAF 202, 222, and 224), data producer NFs (e.g., NF 401 to 403) can share locally trained data (e.g., a local model without privacy / security concerns) with NWDAFs (e.g., server NWDAF 404).

[0073] In other words, regarding point 10, depending on some implementations, the FL between NWDAF 204 (FL server) and NWDAF 222 and 224 (FL clients) can be changed to the FL between server NWDAF 404 and data producer NF (e.g., NF 401 to 403).

[0074] Figure 5 An example of a vertical and / or horizontal FL (Flexible Interchange) between an FL server NWDAF (e.g., server NWDAF 404) and an NF 501 (which could be NF 401 to 403) enhanced with MTLF functionality, acting as an FL client, is illustrated. Server NWDAF 404 can send its current global model to NF 501 as an initial model for training a local model of NF 501. Each NF in NF 501 generates training data and trains its local model using its MTLF functionality based on the initial model received from server NWDAF 404 and the training data generated by the NF. NF 501 can then send its respective trained local model to server NWDAF 404. Server NWDAF 404 aggregates the received local models using aggregation techniques known in the art, thereby generating an updated global model. The above process can be repeated multiple times for multiple iterations.

[0075] Figure 6 Examples of horizontal FLs are shown between an FL server NWDAF (e.g., server NWDAF 404) and an NF (e.g., AMF 601) that acts as an FL client, belongs to the same NF type with the same data characteristics, and is enhanced with MTLF. (Regarding...) Figure 5The described NF 501 can include NFs of the same NF type (e.g., AMF 601a to 601c). Furthermore, with respect to the horizontal FL, the local datasets (e.g., training data) in different NFs have the same feature space (e.g., data feature A) but different samples (e.g., for different users, each user corresponds to different samples, such as samples 1 to n1 generated and / or collected by AMF 601a, samples n1+1 to n2 generated and / or collected by AMF 601b, and samples n2+1 to n3 generated and / or collected by AMF 601c). For example, the common feature shared by NFs for the horizontal FL could be a latency data feature, while different samples could be different latency statistics for different users generated by different NFs (e.g., AMF 601a to 601c). In another example, the characteristic shared by NFs for the horizontal FL could be a quality of service (QoS) data feature, while different samples could be different QoS statistics for different users generated by different NFs (e.g., AMF 601a to 601c).

[0076] Figure 7 An example of a vertical FL is shown between an FL server NWDAF (e.g., server NWDAF 404) and an NF (e.g., AMF 701, UPF 702, and policy control function (PCF) 703) that acts as an FL client, belongs to different NF types with different data characteristics, and is enhanced with MTLF. (About) Figure 5 The described NF 501 can include NFs of different NF types (e.g., AMF 701, UPF 702, and PCF 703). Furthermore, with respect to vertical FLs, the local datasets in different NFs have different feature spaces (e.g., data feature A for AMF 701, data feature U for UPF 702, and data feature P for PCF 703), but have the same samples (samples 1 to n1 for users 1 to n1, respectively).

[0077] Figure 8 An example of a vertical FL (FL) is shown between a network entity enhanced with MTLF, which acts as an FL client and comes from different domains (e.g., RAN domain, core network domain, and UE domain) with different implementations, and is based on some method of implementation. (About...) Figure 5 The described NF 501 may include NF (e.g., AMF) 801 in the core network domain, gNB 802 in the RAN domain, and UE 803 in the user domain.

[0078] Figure 9This is a flowchart illustrating an exemplary method by which an NWDAF (e.g., NF 501) containing an MTLF, according to some implementation, is used to determine whether a mechanism for FL is needed and / or which mechanism for FL is needed. Figure 9 As shown, at operation 901, a request for FL ML model training is received at the NWDAF containing the MTLF (e.g., a request from an NWDAF containing the AnLF, such as server NWDAF404). At operation 902, the NWDAF containing the MTLF can determine the FL that requires the participation of the FL client NF because input data cannot be collected from the data producer NF, and no FL client NWDAF matching the screening criteria has been found through the existing FL client NWDAF discovery process. This determination can be performed based on the analysis ID in the request. For example, the requested analysis ID requires ML training based on data feature A of NF type AMF. However, due to data access constraints, data feature A cannot be collected from the AMF through any NWDAF client. Therefore, the FL that requires AMF participation and enhancement with the MTLF functionality is determined. At operation 903, the NWDAF containing the MTLF can further determine whether a horizontal FL is needed (e.g., based on the analysis ID, required input data, data privacy / security / access permission reasons, NFs involved in ML model training, etc.). In the case of horizontal FL, the corresponding FL client NF discovery process is performed in operation 904 according to each NF type. Therefore, in operation 905, the process of performing FL training between the FL server NWDAF (e.g., server NWDAF 404) and the FL client NF of the same NF type (e.g., NF 501) is followed. If it is determined at operation 906 that vertical FL is required, then the FL client NF discovery and FL training processes for the different NF types involved in the FL are performed in operations 907 and 908 respectively.

[0079] Figure 10This diagram illustrates an exemplary process of interaction between an FL server NWDAF (server NWDAF 404), an FL client NF (NF 501), and an NRF, according to some implementations, to perform FL registration and discovery. 3GPP standardized subscription interfaces, notification interfaces, and / or modified versions thereof (e.g., Nnwdaf_MLModelProvision and / or Nnwdaf_MLModelInfo) can be used in each interaction between the FL server NWDAF, the FL client NF, and the NRF. The following Nnwdaf_MLModelProvision service operations can be enhanced and implemented based on all NFs that support MTLF functionality. Currently, only NWDAF supports these service operations. The service name can be changed according to the NF type, but the same input and output data parameters specified in TS 23.288 can be utilized, as the input / output parameters are ML model information related to NF type information rather than NF type-specific information.

[0080] - Service operation name: N{NFtype}_MLModelProvision_Subscribe (e.g., Namf_MLModelProvision_Subscribe)

[0081] Description: Subscribe to the FL client NF ML model feed.

[0082] - Service operation name: N{NFtype}_MLModelProvision_Unsubscribe

[0083] (For example, Namf_MLModelProvision_Unsubscribe)

[0084] Description: Unsubscribe from FL client NF ML model supply.

[0085] - Service operation name: N{NFtype}_MLModelProvision_Notify

[0086] (For example, Namf_MLModelProvision_Notify)

[0087] Description: The FL client NF notifies the NWDAF server that has subscribed to the FL client NF service of ML model information.

[0088] The following Nnwdaf_MLModelInfo service operation also provides enhancements and support for all NFs that support MTLF functionality. Currently, only NWDAF supports this service operation. The service name can be changed according to the NF type, but the same input and output data parameters as specified in TS 23.288 can be used because the input / output parameters are related to the NF type information rather than NF type-specific ML model information.

[0089] - Service operation name: N{NFtype}_MLModelInfo_Request

[0090] (For example, Namf_MLModelInfo_Request)

[0091] Description: The FL server NWDAF requests NF ML model information from the FL client.

[0092] like Figure 10 As shown, in operation 1001, FL server NWDAF 404 registers its NWDAF profile containing FL server capability information in NRF 1050. An example of an NF profile (e.g., Clause A.2 TS 29.510) has been enhanced with new parameters as shown below.

[0093] NFProfile:

[0094] Description: Information about NF instances registered in NRF.

[0095] Type: object

[0096] Required:

[0097] - nfInstanceId

[0098] - nfType

[0099] - nfStatus

[0100] Satisfy any of the following:

[0101] -Required: [fqdn]

[0102] -Required: [ipv4Addresses]

[0103] -Required: [ipv6Addresses]

[0104] property:

[0105] nfInstanceId:

[0106] $ref:'TS29571_CommonData.yaml# / components / schemas / NfInstanceId'

[0107] nfInstanceName:

[0108] Type: String

[0109] nfType:

[0110] $ref:'# / components / schemas / NFType'

[0111] nfStatus:

[0112] $ref:'# / components / schemas / NFStatus'

[0113] FLCapabilityType: Client-side or None

[0114] Type: Array

[0115] In operations 1002 through 1004, each FL client NF 501 registers its NF profile (e.g., the NFProfile mentioned above) information enhanced with FL client capability information in NRF 1050. In operations 1005 through 1008, NRF sends an NF registration response. In operation 1009, FL server NWDAF 404 discovers and selects NFs with FL client capabilities from NRF. For this operation, FL server NWDAF 404 may send a discovery request to NRF 1050 (e.g., invoking the 3GPP standardized Nnrf_NFDiscovery_Request service operation, using standards including the analytics ID of the required ML model, FL capability type (i.e., FL client), service area, vendor, security domain, interoperability information, and data availability of the FL client NF). It can be assumed that prior to step 1009 of this process, the NWDAF containing MTLF, which has already received the analysis request from the analysis consumer, has determined that the ML model requires vertical / horizontal FL and cannot directly obtain the corresponding training data from the data producer NF. The NWDAF containing MTLF has already discovered and selected an NWDAF with server capabilities through existing processes. At operation 1010, a discovery response to the discovery request at operation 1009 is received. In operations 1011 to 1013, the FL server NWDAF 404 sends an FL learning preparation request to the discovered FL client NF 501. The FL preparation request may include information such as the required ML model, analysis ID, and data requirements. In operation 1014, the FL client NF 501 checks whether this information meets the ML model training requirements and determines accordingly whether to join the FL process. In operations 1015 to 1017, the response from FL client NF 501 is sent back to FL server NWDAF 404, and in operation 1018, FL server NWDAF 404 selects FL client NF 501 based on the received response (from FL client NF 501, which has been determined to join).

[0116] Figure 11 It is a diagram of an exemplary FL registration and discovery process and an exemplary NF type, based on some implementation methods. Figure 11 Operations 1101 to 1118 are similar to operations 1001 to 1018, the difference being... Figure 10 Examples of NF 501 can include AMF 701, UPF 702, and session management function (SMF) 704. NF 501 is not limited to... Figure 11The NF shown is shown. NF 501 can also include any NF that generates training data for its local model. NF 501 can also be extended to other network entities, such as those related to... Figure 8 The gNB 802 and UE 803 are described.

[0117] Figure 12 This diagram illustrates an exemplary process of interaction between an FL server NWDAF (e.g., server NWDAF 404), an FL client NF (e.g., NF 501), and an ML model consumer 1250, according to some implementations, to perform FL between the FL server NWDAF and the FL client NF. At each interaction between any two entities, 3GPP-standardized subscription and notification interfaces can be used. For example, the Nnwdaf_MLModelTraining service, which enables the FL server / client to subscribe / unsubscribe / notify / modify ML model training, can be used on an NF enhanced with MTLF capabilities. This service enables the FL server NWDAF 404 to enable federated learning (FL) while providing global ML model information to the FL client NWDAF and obtaining local ML model information and FL training status reports. The service operation Nnwdaf_MLModelTraining can be enhanced and implemented based on all NFs that support MTLF functionality. The service name can be changed based on the NF type, but the same input and output data parameters as specified in TS 23.288 can be used because the input / output parameters are related to the NF type information rather than NF type-specific ML model information. Note that the current Nnwdaf_MLModelTraining service is used by NWDAF to request an NWDAF containing MTLF to prepare for training an ML model or modify an existing ML model training subscription.

[0118] - Service operation name: N{NFtype}_MLModelTraining_Notify

[0119] (For example, Namf_MLModelTraining_Notify)

[0120] Description: The FL client NF notifies consumer instances that the trained ML model has subscribed to a specific NWDAF service (i.e., the FL server NWDAF). The FL client NF can also use this service to instruct the FL server NWDAF that it will terminate ML model training.

[0121] like Figure 12As shown, in operation 1201, ML consumer 1250 (note that ML consumer may differ from analysis consumer, which is an NWDAF containing AnLF or an NWDAF containing MTLF) sends a subscription request (e.g., N{NFtype}_MLModelProvision_Subscribe) to FL server NWDAF 404 to train an ML model via horizontal / vertical NF-based FL. In operation 1202, FL server NWDAF 404 selects an FL client NF (e.g., via about Figure 10 The discovery process is described below. In operations 1203 to 1205, the FL server NWDAF 404 sends an FL training request (e.g., N{NFtype}_MLModelInfo_Request) to the selected FL client NF. The FL server NWDAF 404 may include FL information such as ML model accuracy in its training request. In operations 1206 to 1208, the FL client NF 501 performs the FL training process using locally generated training data to produce its own local model and sends its own local ML model information (e.g., N{NFtype}_MLModelProvision_Notify) back to the FL server NWDAF 404. In operation 1209, the FL server NWDAF 404 aggregates the local ML information and updates the global ML model. In operation 1210, the FL server NWDAF 404 sends a notification update of the updated global ML model to the ML consumer 1250. Based on the updated global model received from the FL server NWDAF 404, the ML consumer 1250 determines in operation 1211 whether to continue or stop the FL process and sends a corresponding request to the FL server NWDAF. In operation 1212, the FL server NWDAF 404 updates or terminates the FL process. If the FL process continues, in operations 1213 to 1215, the FL server NWDAF 404 sends the global FL model information to the FL client NF. In operation 1216, the FL client NF 501 updates its local FL model based on the received aggregate (i.e., global) model. Operations 1206 to 1219 can be repeated until the FL training termination condition is met based on feedback from the ML consumer, or the maximum number of iterations is reached.

[0122] Figure 13AA flowchart illustrating method 1300 performed by a federated learning (FL) server network entity according to some implementations is shown. The FL server network entity may include computer-readable code or instructions executable on one or more processors of the FL server network entity. In this disclosure, the encoding of the software used to perform or execute method 1300 is within the knowledge of those skilled in the art. Method 1300 may include more or fewer operations than those shown and described, and may be performed or executed in different orders. The computer-readable code or instructions of the one or more processor-executable software may be stored on a non-transitory computer-readable medium, such as the memory of the FL server network entity. In some embodiments, method 1300 may be executed by one or more units or modules (e.g., integrated circuits) of the FL server network entity, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0123] Method 1300 begins with operation 1302, where the federated learning (FL) server network entity receives information about local machine learning (ML) models from the FL client network entity. Each local ML model is trained based on its corresponding local training data. The corresponding local training data is available at the corresponding FL client network entity before the corresponding FL client network entity receives the corresponding FL training request. At operation 1304, the FL server network entity aggregates the local ML models to generate an updated global ML model.

[0124] In some implementations, the FL client network entity may include one or more of the following: at least one core domain network entity, at least one radio access network (RAN) network entity, at least one application function (AF) entity, or at least one user equipment (UE). At least one RAN network entity may include at least one base station. At least one core domain network entity may include an access and mobility management function (AMF) entity, a policy control function (PCF) entity, a session management function (SMF) entity, a user plane function (UPF) entity, a network exposure function (NEF) entity, or a network repository function (NRF) entity.

[0125] In some implementations, the FL server network entity can determine whether a network function (NF)-based FL is needed based on the analysis identifier (ID) and the corresponding data collection requirements. The FL server network entity can then determine the mechanism used for NF-based FLs.

[0126] In some implementations, the FL server network entity can perform NF-based FL registration and discovery processes based on this mechanism.

[0127] In some implementations, the FL server network entity can send a server registration profile to the network repository function (NRF) entity. The server registration profile can indicate FL server capability information. The FL server network entity can send discovery requests to the NRF entity. The FL server network entity can receive discovery responses from the NRF entity. The discovery responses can indicate a set of candidate FL client network entities. The FL server network entity can send FL learning preparation requests to the set of candidate FL client network entities. Each FL learning preparation request in the FL learning preparation request can indicate ML model information, analysis ID, and corresponding data collection requirements. The FL server network entity can receive FL learning preparation responses from the set of candidate FL client network entities. The FL server network entity can select FL client network entities from the set of candidate FL client network entities based on the FL learning preparation responses.

[0128] In some implementations, the FL server network entity can perform an NF-based FL training process according to this mechanism. The FL server network entity can perform the NF-based FL training process through at least one of the enhanced ML model provisioning or ML model training service operations.

[0129] In some implementations, the FL server network entity can receive subscription requests from ML model consumers. The FL server network entity can send FL training requests to the FL client network entity. The FL server network entity can receive FL training responses from the FL client network entity. These FL training responses may include information about the local ML model.

[0130] In some implementations, FL client network entities can include NF entities of the same NF type.

[0131] In some implementations, FL client network entities can include NF entities of different NF types.

[0132] In some implementations, the FL server network entity can be the FL server network data analytics function (NWDAF) entity.

[0133] In some implementations, the mechanism can be a horizontal mechanism, a vertical mechanism, or a combination of both.

[0134] In some implementations, at least a portion of the local training data available at the corresponding FL client network entity can be generated by the corresponding FL client network entity.

[0135] Figure 13BA flowchart illustrating method 1350 performed by a federated learning (FL) client network entity according to some implementations is shown. The FL client network entity may include computer-readable code or instructions that execute on one or more processors of the FL client network entity. In this disclosure, the encoding of the software used to perform or execute method 1350 is within the knowledge of those skilled in the art. Method 1350 may include more or fewer operations than those shown and described, and may be performed or executed in different orders. The computer-readable code or instructions of the one or more processor-executable software may be stored on a non-transitory computer-readable medium, such as the memory of the FL client network entity. In some embodiments, method 1350 may be executed by one or more units or modules (e.g., integrated circuits) of the FL client network entity, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0136] Method 1350 begins with operation 1352, where the FL client network entity locally generates or collects training data. At operation 1354, following this local generation or collection, the FL client network entity receives an FL training request from the FL server network entity. At operation 1356, the FL client network entity trains a local machine learning (ML) model based on the FL training request and the training data. At operation 1358, the FL client network entity sends information about the local ML model to the FL server network entity.

[0137] In some implementations, the FL client network entity may include one or more of the following: at least one core domain network entity, at least one radio access network (RAN) network entity, at least one application function (AF) entity, or at least one user equipment (UE). At least one RAN network entity may include at least one base station. At least one core domain network entity may include an access and mobility management function (AMF) entity, a policy control function (PCF) entity, a session management function (SMF) entity, a user plane function (UPF) entity, a network exposure function (NEF) entity, or a network repository function (NRF) entity.

[0138] In some implementations, the FL client network entity can send a network entity registration profile to the network repository function (NRF) entity. The network entity registration profile can indicate FL client capability information. The FL client network entity can receive FL learning readiness requests from the FL server network entity. FL learning readiness requests can indicate ML model information, an analysis identifier (ID), and corresponding data collection requirements. Based on the FL learning readiness request, the FL client network entity can determine which network function (NF)-based FL corresponding to the local ML model to join with the FL server network entity. The FL client network entity can send an FL learning readiness response to the FL server network entity.

[0139] In some implementations, the FL client network entity can receive information about the updated global ML model from the FL server network entity. The FL client network entity can then update its local ML model based on the updated global ML model. In some implementations, at least a portion of the training data available at the FL client network entity can be generated by the FL client network entity itself.

[0140] The following references are incorporated herein by way of citation.

[0141] - TS23.288: https: / / www.3gpp.org / ftp / Specs / archive / 23_series / 23.288 / 23288-i20.zip

[0142] Figure 14 An exemplary communication system 1400 is illustrated. The communication system 1400 includes an access node 1410 that provides services to user equipment (UE) (e.g., UE 1420) within a coverage area 1401. In a first operating mode, communication to and from the UE passes through the access node 1410 within the coverage area 1401. The access node 1410 is connected to a backhaul network 1415 for connecting to the Internet, operations, and administration. In a second operating mode, communication to and from the UE does not pass through the access node 1410; however, the access node 1410 typically allocates resources for communication by the UE when certain conditions are met. Communication between a pair of UEs 1420 can use a sidelink connection (shown as two separate unidirectional connections 1425). Figure 14 In this context, lateral link communication occurs between two UEs operating within coverage area 1401. However, lateral link communication can also typically occur when both UEs 1420 are outside coverage area 1401; both are within coverage area 1401; or one is within coverage area 1401 and the other is outside. Communication between the UE and the access node pair is conducted via a unidirectional communication link, where the communication link between the UE and the access node is referred to as uplink 1430, and the communication link between the access node and the UE is referred to as downlink 1435.

[0143] Access nodes are also commonly referred to as base stations (Node B), evolved base stations (eNB), next-generation (NG) base stations (NG Node B, gNB), master eNB (MeNB), secondary eNB (SeNB), master gNB (MgNB), secondary gNB (SgNB), network controllers, control nodes, base stations, access points, transmission points (TP), transmission-reception points (TRP), cells, carriers, macro cells, femtocells, picocells, etc., while UEs are also commonly referred to as mobile stations, handsets, terminals, users, subscribers, sites, etc. Access nodes can provide wireless access according to one or more wireless communication protocols, such as 3GPP Long Term Evolution (LTE), LTE Advanced (LTE-A), 5G, 5G LTE, 5G NR, Sixth Generation (6G), High Speed ​​Packet Access (HSPA), and IEEE 802.11 series standards, such as 802.11a / b / g / n / ac / ad / ax / ay / be, etc. While it is understood that a communication system could employ multiple access nodes capable of communicating with several UEs, for simplicity, only one access node and two UEs are shown.

[0144] Figure 15 An exemplary communication system 1500 is illustrated. Generally, system 1500 enables multiple wireless or wired users to send and receive data and other content. System 1500 may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

[0145] In this example, the communication system 1500 includes electronic devices (EDs) 1510a to 1510c, radio access networks (RANs) 1520a and 1520b, a core network 1530, a public switched telephone network (PSTN) 1540, the Internet 1550, and other networks 1560. Although Figure 15 A certain number of these components or elements are shown, but the system 1500 may include any reasonable number of these components or elements.

[0146] EDs 1510a to 1510c are used for operation or communication within system 1500. For example, EDs 1510a to 1510c are used for transmitting or receiving via wireless or wired communication channels. Each ED 1510a to 1510c represents any suitable end-user equipment, which may include (or may be referred to as): user equipment / device (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, personal digital assistant (PDA), smartphone, laptop computer, computer, touchpad, wireless sensor, or consumer electronic device.

[0147] Here, RAN 1520a and 1520b include base stations 1570a and 1570b, respectively. Each base station 1570a and 1570b is used for radio connection with one or more of ED 1510a to 1510c to enable access to the core network 1530, PSTN 1540, Internet 1550, or other network 1560. For example, base stations 1570a and 1570b may include (or may be) one or more of the following well-known devices: base transceiver station (BTS), base station (NodeB), evolved NodeB (eNB), Next Generation (NG) base station (gNB), gNB centralized unit (gNB-CU), gNB distributed unit (gNB-DU), home NodeB, home eNodeB, site controller, access point (AP), or wireless router. ED 1510a to 1510c are used for connection and communication with the Internet 1550 and can access the core network 1530, PSTN 1540 or other networks 1560.

[0148] exist Figure 15 In the illustrated embodiment, base station 1570a forms part of RAN 1520a, which may include other base stations, components, or devices. Similarly, base station 1570b forms part of RAN 1520b, which may include other base stations, components, or devices. Each base station 1570a and 1570b is used to transmit or receive radio signals within a specific geographical area or region (sometimes referred to as a "cell"). In some embodiments, multiple-input multiple-output (MIMO) technology may be employed, which equips each cell with multiple transceivers.

[0149] Base stations 1570a and 1570b communicate with one or more of ED 1510a to 1510c via one or more air interfaces 1590 using a wireless communication link. Air interface 1590 can utilize any suitable wireless access technology.

[0150] System 1500 is envisioned to utilize multi-channel access capabilities, including the schemes described above. In specific embodiments, the base station and ED implement 5G New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and radio protocols can also be utilized.

[0151] RANs 1520a and 1520b communicate with core network 1530 to provide voice, data, application, Voice over Internet Protocol (VoIP), or other services to EDs 1510a through 1510c. It should be understood that RANs 1520a and 1520b or core network 1530 can communicate directly or indirectly with one or more other RANs (not shown). Core network 1530 can also serve as a gateway access for other networks (e.g., PSTN 1540, Internet 1550, and other networks 1560). Additionally, some or all of EDs 1510a through 1510c may include the ability to communicate with different wireless networks via different wireless links using different wireless technologies or protocols. EDs may communicate with service providers or switches (not shown) and Internet 1550 via wired communication channels, rather than wirelessly (or as a supplement to wireless communication).

[0152] Although Figure 15 An example of a communication system is shown, but it is possible to... Figure 15 Various modifications can be made. For example, the communication system 1500 can include any number of EDs, base stations, networks, or other components under any suitable configuration.

[0153] Figure 16A and 16B Exemplary devices are shown that can implement the methods and teachings of this disclosure. Specifically, Figure 16A An exemplary ED 1610 is shown. Figure 16B An exemplary base station 1670 is shown. These components can be used in system 1500 or any other suitable system.

[0154] like Figure 16A As shown, ED 1610 includes at least one processing unit 1600. The processing unit 1600 implements various processing operations of ED 1610. For example, the processing unit 1600 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables ED 1610 to operate in system 1500. The processing unit 1600 also supports the methods and teachings described in detail above. Each processing unit 1600 includes any suitable processing or computing device for performing one or more operations. Each processing unit 1600 may, for example, include a microprocessor, microcontroller, digital signal processor, field-programmable gate array, or application-specific integrated circuit.

[0155] ED 1610 also includes at least one transceiver 1602. Transceiver 1602 is used to modulate data or other content for transmission via at least one antenna or Network Interface Controller (NIC) 1604. Transceiver 1602 is also used to demodulate data or other content received by at least one antenna 1604. Each transceiver 1602 includes any suitable structure for generating signals for wireless or wired transmission or processing signals received wirelessly or wiredly. Each antenna 1604 includes any suitable structure for transmitting or receiving wireless or wired signals. One or more transceivers 1602 and one or more antennas 1604 may be used in ED 1610. Although transceiver 1602 is shown as a single functional unit, it can also be implemented using at least one transmitter and at least one separate receiver.

[0156] ED 1610 also includes one or more input / output devices 1606 or interfaces (such as a wired interface to the Internet 1550). Input / output devices 1606 facilitate interaction with users or other devices on the network (network communication). Each input / output device 1606 includes any suitable structure for providing or receiving information from a user (including network interface communication), such as a speaker, microphone, numeric keypad, keyboard, display, or touchscreen.

[0157] Additionally, ED 1610 includes at least one memory 1608. Memory 1608 stores instructions and data used, generated, or collected by ED 1610. For example, memory 1608 may store software or firmware instructions executed by processing unit 1600, as well as data used to reduce or eliminate interference in incoming signals. Each memory 1608 includes any suitable volatile or non-volatile storage and retrieval device. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, etc.

[0158] like Figure 16BAs shown, base station 1670 includes at least one processing unit 1650, at least one transceiver 1652 (which includes functions for transmitting and receiving), one or more antennas 1656, at least one memory 1658, and one or more input / output devices or interfaces 1666. A scheduler, as will be understood by those skilled in the art, is coupled to processing unit 1650. The scheduler may be included within base station 1670 or may operate separately from base station 1670. Processing unit 1650 implements various processing operations of base station 1670, such as signal encoding, data processing, power control, input / output processing, or any other functions. Processing unit 1650 may also support the methods and teachings described in detail above. Each processing unit 1650 includes any suitable processing or computing device for performing one or more operations. Each processing unit 1650 may, for example, include a microprocessor, microcontroller, digital signal processor, field-programmable gate array, or application-specific integrated circuit.

[0159] Each transceiver 1652 includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver 1652 also includes any suitable structure for processing signals received wirelessly or wiredly from one or more EDs or other devices. Although the transmitter and receiver are shown combined as transceiver 1652, they can be separate components. Each antenna 1656 includes any suitable structure for transmitting or receiving wireless or wired signals. Although a general-purpose antenna 1656 is shown herein coupled to transceiver 1652, one or more antennas 1656 can be coupled to transceiver 1652, thus allowing individual antennas 1656 to be coupled to both the transmitter and receiver (when configured as separate components). Each memory 1658 includes any suitable volatile or non-volatile storage and retrieval device. Each input / output device 1666 facilitates interaction with users or other devices in the network (network communication). Each input / output device 1666 includes any suitable structure for providing or receiving information from users (including network interface communication).

[0160] Figure 17This is a block diagram of a computing system 1700 that can be used to implement the devices and methods disclosed herein. For example, the computing system can be any entity in a UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). A particular device may utilize all or only a subset of the components shown, and the level of integration may vary from device to device. Furthermore, a device may include multiple instances of components, such as multiple processing units, multiple processors, multiple memories, multiple transmitters, multiple receivers, etc. The computing system 1700 includes a processing unit 1702. The processing unit includes a central processing unit (CPU) 1714, memory 1708, and may also include a mass storage device 1704 connected to a bus 1720, a video adapter 1710, and an I / O interface 1712.

[0161] Bus 1720 can be one or more of any type of bus architecture, including a memory bus or memory controller, peripheral bus, or video bus. CPU 1714 can include any type of electronic data processor. Memory 1708 can include any type of non-transitory system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or combinations thereof. In embodiments, memory 1708 may include ROM for use at boot time and DRAM for storing programs and data for use during program execution.

[0162] Mass storage device 1704 may include any type of non-transitory storage device for storing data, programs, and other information, and making such data, programs, and other information accessible via bus 1720. Mass storage device 1704 may include one or more of, for example, solid-state drives, hard disk drives, disk drives, or optical disk drives.

[0163] Video adapter 1710 and I / O interface 1712 provide interfaces for coupling external input and output devices to processing unit 1702. Examples of input and output devices, as shown, include a display 1718 coupled to video adapter 1710 and a mouse, keyboard, or printer 1716 coupled to I / O interface 1712. Other devices may be coupled to processing unit 1702, and more or fewer interface cards may be used. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide interfaces for external devices.

[0164] Processing unit 1702 also includes one or more network interfaces 1706, which may include wired links such as Ethernet cables or wireless links for accessing nodes or different networks. Network interface 1706 enables processing unit 1702 to communicate with remote units via a network. For example, network interface 1706 may provide wireless communication via one or more transmitter / transmit antennas and one or more receiver / receive antennas. In embodiments, processing unit 1702 is coupled to a local area network 1722 or a wide area network for processing data and communicating with other processing units, the Internet, or remote devices such as remote storage facilities.

[0165] It should be understood that one or more steps of the methods in the embodiments provided herein can be performed by corresponding units or modules. For example, a signal can be sent by a sending unit or sending module. A signal can be received by a receiving unit or receiving module. A signal can be processed by a processing unit or processing module. Other steps can be performed by: an execution unit or module, a generation unit or module, an acquisition unit or module, a setting unit or module, an adjustment unit or module, an addition unit or module, a reduction unit or module, a determination unit or module, a modification unit or module, a reduction unit or module, a deletion unit or module, or a selection unit or module. The corresponding units / modules can be hardware, software, or a combination thereof. For example, one or more of these units or modules can be integrated circuits, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0166] While this specification has been described in detail, it should be understood that various changes, substitutions, and alterations can be made without departing from the spirit and scope of this disclosure as defined by the appended claims. Furthermore, the scope of this disclosure is not intended to be limited to the specific embodiments described herein, as those skilled in the art will readily recognize from this disclosure that existing or later-developed processes, machines, articles of manufacture, material components, elements, methods, or steps can perform substantially the same functions or achieve substantially the same results as the corresponding embodiments described herein. Accordingly, the scope of the appended claims is intended to include such processes, machines, articles of manufacture, material components, methods, or steps.

Claims

1. A method comprising: The Federated Learning FL Server Network Entity receives information about local machine learning (ML) models from the FL Client Network Entity. Each local ML model in the local ML model is trained based on corresponding local training data. The corresponding local training data is available at the corresponding FL Client Network Entity before the corresponding FL Client Network Entity in the FL Client Network Entity receives the corresponding FL training request. The FL server network entity aggregates the local ML model to generate an updated global ML model.

2. The method according to claim 1, wherein, The FL client network entity includes one or more of the following: at least one core domain network entity, at least one radio access network (RAN) network entity, at least one application function (AF) entity, or at least one user equipment (UE). The at least one RAN network entity includes at least one base station. The at least one core domain network entity includes an access and mobility management function (AMF) entity, a policy control function (PCF) entity, a session management function (SMF) entity, a user plane function (UPF) entity, a network public function (NEF) entity, or a network repository function (NRF) entity.

3. The method according to any one of claims 1 to 2, further comprising: The FL server network entity determines whether a network function (NF) is needed based on the analysis identifier ID and the corresponding data collection requirements. The FL server network entity determines the mechanism used for the NF-based FL.

4. The method according to claim 3, further comprising: The FL server network entity performs the NF-based FL registration and discovery process according to the mechanism.

5. The method according to claim 4, wherein performing the NF-based FL registration and discovery process comprises: The FL server network entity sends a server registration profile to the Network Repository Function (NRF) entity, the server registration profile indicating FL server capability information; The FL server network entity sends a discovery request to the NRF entity; The FL server network entity receives a discovery response from the NRF entity indicating a set of candidate FL client network entities; The FL server network entity sends an FL learning preparation request to the candidate FL client network entity set. Each FL learning preparation request in the FL learning preparation request indicates ML model information, the analysis ID and the corresponding data collection requirements. The FL server network entity receives the FL learning preparation response from the set of candidate FL client network entities; The FL server network entity selects the FL client network entity from the set of candidate FL client network entities based on the FL learning prepare response.

6. The method according to claim 3, further comprising: The FL server network entity performs an NF-based FL training process through at least one of an enhanced ML model provisioning or ML model training service operation, according to the mechanism.

7. The method according to claim 6, wherein performing the NF-based FL training process comprises: The FL server network entity receives subscription requests from ML model consumers; The FL server network entity sends an FL training request to the FL client network entity. The receipt of the information regarding the local ML model includes: The FL server network entity receives an FL training response from the FL client network entity, which includes the information about the local ML model.

8. The method according to any one of claims 1 to 7, wherein, The FL client network entities include NF entities of the same NF type.

9. The method according to any one of claims 1 to 8, wherein, The FL client network entities include NF entities of different NF types.

10. The method according to any one of claims 1 to 9, wherein, The FL server network entity is the FL server network data analysis function NWDAF entity.

11. The method according to claim 3, wherein the mechanism is a horizontal mechanism, a vertical mechanism, or a combination of horizontal and vertical mechanisms.

12. The method according to any one of claims 1 to 11, wherein, At least a portion of the corresponding local training data available at the corresponding FL client network entity is generated by the corresponding FL client network entity.

13. A method comprising: Federated learning FL client network entities locally generate or collect training data; After the local generation or collection, the FL client network entity receives the FL training request from the FL server network entity; The FL client network entity trains a local machine learning (ML) model based on the FL training request and the training data. The FL client network entity sends information about the local ML model to the FL server network entity.

14. The method according to claim 13, wherein, The FL client network entity includes one or more of the following: at least one core domain network entity, at least one radio access network (RAN) network entity, at least one application function (AF) entity, or at least one user equipment (UE). The at least one RAN network entity includes at least one base station. The at least one core domain network entity includes an access and mobility management function (AMF) entity, a policy control function (PCF) entity, a session management function (SMF) entity, a user plane function (UPF) entity, a network public function (NEF) entity, or a network repository function (NRF) entity.

15. The method according to any one of claims 13 to 14, further comprising: The FL client network entity sends a network entity registration profile to the Network Repository Function (NRF) entity, the network entity registration profile indicating FL client capability information; The FL client network entity receives an FL learning preparation request from the FL server network entity. The FL learning preparation request indicates ML model information, analysis identifier ID, and corresponding data collection requirements. The FL client network entity determines, based on the FL learning preparation request, to join the FL server network entity in the FL-based network function NF corresponding to the local ML model. The FL client network entity sends an FL learning readiness response to the FL server network entity.

16. The method according to any one of claims 13 to 15, further comprising: The FL client network entity receives information about the updated global ML model from the FL server network entity; The FL client network entity updates the local ML model based on the updated global ML model.

17. The method according to any one of claims 13 to 16, wherein, At least a portion of the training data available at the FL client network entity is generated by the FL client network entity.

18. A federated learning FL server network entity, comprising: At least one processor; A non-transitory computer-readable storage medium storing a program, the program comprising instructions that, when executed by the at least one processor, cause the FL server network entity to perform the method according to any one of claims 1 to 12.

19. A federated learning (FL) client network entity, comprising: At least one processor; A non-transitory computer-readable storage medium storing a program, the program comprising instructions that, when executed by the at least one processor, cause the FL client network entity to perform the method according to any one of claims 13 to 17.

20. A non-transitory computer-readable medium storing instructions that, when executed by a federated learning FL server network entity, cause the FL server network entity to perform the method according to any one of claims 1 to 12.

21. A non-transitory computer-readable medium storing instructions that, when executed by a federated learning FL client network entity, cause the FL client network entity to perform the method according to any one of claims 13 to 17.

Images