Apparatus and method for managing joint learning

Abstract

Apparatus and methods for managing federated learning are provided herein. The present disclosure provides an apparatus comprising: an interface circuit; and a processor circuit coupled with the interface circuit. The processor circuit is to generate a first Managed Object Instance (MOI) representing a Machine Learning (ML) training function, where the first MOI includes a first attribute indicating a Joint Learning (FL) role undertaken by the ML training function in a Joint Learning (FL) training; and providing the first MOI to a service consumer via an interface circuit to inform the FL role undertaken by the ML training function in the FL training. Other embodiments may be described and / or claimed.

Description

[0001] Priority Statement

[0002] This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 648,553, filed May 16, 2024, which is incorporated herein by reference in its entirety. Technical Field

[0003] The embodiments of this disclosure generally relate to wireless communication, and more specifically, to apparatus and methods for managing federated learning (FL). Background Technology

[0004] FLAG (Flexible Training) is a distributed machine learning approach that allows multiple ML training functions to collaboratively train an ML model on their respective local datasets without explicitly exchanging data samples. The performance of FLAG can be evaluated to manage it. Research has been conducted on the management of FLAG. Summary of the Invention

[0005] One aspect of this disclosure provides an apparatus comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: generate a first managed object instance (MOI) representing a machine learning (ML) training function, wherein the first MOI includes a first attribute indicating the FL role assumed by the ML training function in federated learning (FL) training; and provide the first MOI to a service consumer via the interface circuit to inform the ML training function of its FL role in FL training.

[0006] One aspect of this disclosure provides an apparatus comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: receive, via the interface circuit, a first managed object instance (MOI) representing a machine learning (ML) training function from a service producer, wherein the first MOI includes a first attribute indicating that the federated learning (FL) role undertaken by the ML training function is an FL server or an FL client; and manage FL training based on the first MOI. Attached Figure Description

[0007] In the accompanying drawings, embodiments of the present disclosure will be illustrated by way of example rather than limitation, wherein like reference numerals refer to similar elements.

[0008] Figure 1 Examples of decentralized ML training functions for federated learning according to some embodiments of this disclosure are shown.

[0009] Figure 2 An example of an FL management service framework according to some embodiments of this disclosure is shown.

[0010] Figure 3 Examples of NRMs for ML training management according to some embodiments of this disclosure are shown.

[0011] Figure 4 A flowchart example of a method for managing FL according to some embodiments of this disclosure is shown.

[0012] Figure 5 A flowchart example of a method for managing FL according to some embodiments of this disclosure is shown.

[0013] Figure 6 A flowchart example of a method for managing FL according to some embodiments of this disclosure is shown.

[0014] Figure 7 A flowchart example of a method for managing FL according to some embodiments of this disclosure is shown.

[0015] Figure 8 Examples of NRM fragments for FL requirements according to some embodiments of this disclosure are shown.

[0016] Figure 9 A flowchart example of a method for managing FL according to some embodiments of this disclosure is shown.

[0017] Figure 10 A flowchart example of a method for managing FL according to some embodiments of this disclosure is shown.

[0018] Figure 11 Networks according to various embodiments are shown.

[0019] Figure 12 The illustrations depict wireless networks according to various embodiments.

[0020] Figure 13 The block diagram illustrates components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein, according to some example embodiments.

[0021] Figure 14 Networks according to various embodiments are shown.

[0022] Figure 15 An example functional framework for ML and / or RAN intelligence is described.

[0023] Figure 16An example AI / ML-assisted communication network is depicted, including communication between two MLFs. Detailed Implementation

[0024] Various aspects of the illustrative embodiments will be described using terminology commonly employed by those skilled in the art to convey the essence of this disclosure to others skilled in the art. However, it will be readily understood by those skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. Specific figures, materials, and configurations are set forth for illustrative purposes to provide a thorough understanding of the illustrative embodiments. However, it will be readily understood by those skilled in the art that alternative embodiments can be practiced without these specific details. In other instances, well-known features may be omitted or simplified to avoid obscuring the illustrative embodiments.

[0025] Furthermore, the various operations will be described as multiple discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations do not need to be performed in the order presented.

[0026] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly throughout this document. These phrases do not typically refer to the same embodiment; however, they may refer to the same embodiment. Unless the context otherwise specifies, the terms “comprising,” “having,” and “including” are synonyms. The phrases “A, B, or C” and “A / B / C” mean “(A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).”

[0027] This disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, data centers, network topology, communication system implementation, network convergence, artificial intelligence (AI) / machine learning (ML) technologies, and more specifically to technologies for managing federated learning (FL).

[0028] FL is a distributed machine learning approach that allows multiple ML training functions to collaboratively train ML models on local datasets contained in their respective ML training functions without explicitly exchanging data samples.

[0029] In some embodiments, FL is supported by a set of ML training functions, including an ML training function acting as an FL server and multiple ML training functions acting as FL clients. FL clients maintain data locality and privacy, and train the ML model directly on the local node (client) where the data is generated or stored.

[0030] In some embodiments, joint learning can be categorized into two main types based on the characteristics of the data distribution and how model training is coordinated among the participants: horizontal joint learning (HFL) and vertical joint learning (VFL). These categories reflect different data scenarios and use cases.

[0031] In some embodiments, horizontal joint learning is used when datasets from different participants share the same feature space but the samples differ. Simply put, it is suitable for scenarios where different entities collect data on the same feature set for different sets of individuals.

[0032] In some embodiments, vertical joint learning is used when datasets from different participants have the same sample space but different feature spaces. This is common in scenarios where different entities collect different types of information about the same individual.

[0033] In some embodiments, for horizontal joint learning, the FL process is as follows:

[0034] Client discovery and selection: The FL server discovers and selects FL clients to participate in the FL process;

[0035] FL Initialization: The FL server starts the joint learning process and distributes the initial global model to FL clients for local training.

[0036] ML Model Distribution and Aggregation: FL clients train ML models locally and send interim local ML models to the FL server. The FL server receives the interim ML models from the FL clients, aggregates these interim models to update the global ML model, and then distributes the updated global ML model back to the FL clients. This step needs to be repeated iteratively multiple times until the global ML model meets the training requirements.

[0037] Stop: The FL server coordinates with the FL client to stop the FL process.

[0038] Figure 1 Examples of decentralized ML training functionality for federated learning according to some embodiments of this disclosure are shown. As illustrated, the FL client trains an ML model locally and sends the provisional local ML model to the FL server. The FL server receives the provisional ML models from the FL client, aggregates these provisional ML models to update the provisional global ML model, and then distributes the updated provisional global ML model back to the FL client. Figure 1 The examples in the examples can be applied to any decentralized ML training function for federated learning (including horizontal federated learning, vertical federated learning, etc.).

[0039] In some embodiments, in the fifth-generation system (5GS), one example of FL is to perform ML training in a set of network data analysis functions (NWDAF), where one NWDAF acts as the FL server and the others act as FL clients.

[0040] In some embodiments, use cases for managing federated learning include managing different roles within federated learning.

[0041] For FL (Fluid Training), the ML model is collaboratively trained by a set of ML training functions (e.g., the Model Training Logic Function (MTLF) in NWDAF). This set of ML training functions includes one ML training function acting as an FL server, and the remaining ML training functions acting as FL clients. In some embodiments, to manage FL, a service consumer (e.g., an ML Training Management Service (MnS) consumer) needs to know the ML training functions participating in FL and the role of each ML training function (FL server, FL client) so that the consumer understands the impact of the ML training functions and manages them accordingly. When an ML training request is received, the service producer (e.g., an ML Training MnS producer) will evaluate whether to initiate the FL process based on the training requirements provided by the ML Training consumer. Based on the received requirements, the ML training function can select a suitable FL server, and that FL server can then select a suitable FL client.

[0042] To evaluate FL's performance, consumers need to know the performance of the final global ML model on the participating FL clients. For example, if the FL server cannot generate a global ML model with satisfactory performance for FL clients, consumers may interact with the MnS ML training producer to optimize FL for future training, such as updating the criteria for selecting FL clients.

[0043] The following describes embodiments related to ML-trained MnS producers and ML-trained MnS consumers. However, the embodiments of this disclosure can also be applied to other service producers and service consumers, which is not a limitation of this disclosure.

[0044] In some embodiments, potential requirements are provided, such as REQ-FL_MGMT-1, REQ-FL_MGMT-2, REQ-FL_MGMT-3, REQ-FL_MGMT-4, REQ-FL_MGMT-5, etc. Specifically, for REQ-FL_MGMT-1, the ML training MnS producer should have the ability to allow authorized consumers to acquire the FL role (FL server or FL client) of the ML training function in federated learning. For REQ-FL_MGMT-2, the ML training MnS producer should have the ability to allow authorized consumers to provide requirements for selecting the FL server in federated learning. For REQ-FL_MGMT-3, the ML training MnS producer should have the ability to allow authorized consumers to provide FL training requirements to the ML training function acting as the FL server. For REQ-FL_MGMT-4, the ML training MnS producer should have the ability to allow authorized consumers to provide requirements to the ML training function acting as the FL server for selecting the FL client in federated learning. For REQ-FL_MGMT-5, the ML training MnS producer should have the ability to allow authorized consumers to obtain information about the performance of the final global ML model on each participating FL client.

[0045] In some embodiments, FL is managed by training MnS producers to provide MnS to consumers via ML. Figure 2 Examples of an FL management service framework according to some embodiments of this disclosure are shown. Figure 2 In the example, the MnS producer is located within the ML training function. However, in another embodiment, the MnS producer is located within a management function that manages the ML training function. This disclosure is not limiting in this respect.

[0046] In some embodiments, solutions based on Network Resource Models (NRM) are proposed to manage Federation Learning (FL). These solutions use instances of Information Object Classes (IOCs) to interact between ML Training MnS producers and ML Training MnS consumers to support the management of federated learning.

[0047] Figure 3 Examples of NRMs for ML training management according to some embodiments of this disclosure are shown. Figure 3The diagram illustrates the NRM used for ML training management and their relationships. As shown, the IOC MLTrainingFunction (see 3GPP TS 28.105 V18.3.0 (2024-03) (Generation 3 Partner Program; Technical Specification Group Services and Systems Aspects; Management and Orchestration; Artificial Intelligence / Machine Learning (AI / ML) Management (Version 18))) is associated with IOC MLTrainingRequest, IOC MLTrainingProcess, IOC MLTrainingReport, IOC MLTrainingRepository, IOCThresholdMonitor, or the proxy class ManagedEntity, which represents IOCSubNetwork, IOC ManagedFunction, or IOC ManagedElement. IOC MLTrainingFunction represents the entity responsible for ML training. Furthermore, as shown, IOC MLTrainingRequest is associated with IOC MLTrainingFunction, IOC MLModel, IOC MLModelCoordinationGroup, or IOC MLTrainingProcess. IOCMLTrainingProcess is associated with IOC MLTrainingFunction, IOC MLTrainingRequest, IOCLTrainingReport, IOC MLModel, or IOC MLModelCoordinationGroup. IOCMLTrainingReport is associated with IOC MLTrainingFunction, IOC MLTrainingProcess, IOC MLModel, or IOC MLModelCoordinationGroup. As shown in the figure, "0", "1", and "*" can represent no instance ("0"), one instance ("1"), and multiple instances (""), respectively.

[0048] In some embodiments, the IOC can be a template provided by the service producer to the consumer, for the consumer to fill in the corresponding values. In some embodiments, the IOC can also be a template created by the consumer. In some embodiments, the corresponding Managed Object Instance (MOI) is an instance generated based on the corresponding IOC.

[0049] It should be noted that the various names / labels for IOC, MOI and / or other classes, parameters, variables, attributes, elements, entities, etc., provided in this document are exemplary and other names / labels may be used to represent these aspects.

[0050] Figure 4 A flowchart example of a method 400 for managing FL according to some embodiments of the present disclosure is shown. Method 400 can be performed by a service producer (e.g., an MnS producer). As shown, method 400 may include operations 410 and 420.

[0051] At 410, a first MOI representing the ML training function is generated. The first MOI includes a first attribute indicating the FL role that the ML training function assumes in FL training. At 420, the first MOI is provided to the service consumer to inform it of the FL role that the ML training function assumes in FL training.

[0052] Figure 5 A flowchart example of a method 500 for managing a service flow according to some embodiments of the present disclosure is shown. Method 500 may be performed by a service consumer (e.g., an MnS consumer). As shown, method 500 may include operations 510 and 520.

[0053] At 510, a first MOI representing the ML training function is received from the service producer. The first MOI includes a first attribute indicating whether the ML training function assumes the FL role of an FL server or an FL client. At 520, FL training is managed based on the first MOI.

[0054] Method 400 or method 500 may include more or fewer operations, which is not limited in this disclosure.

[0055] In some embodiments, the FL role includes an FL server or an FL client.

[0056] In some embodiments, the first attribute indicates the FL role for each type of ML model.

[0057] In some embodiments, a service producer may generate a first IOC representing an ML training function. The first IOC includes a first attribute indicating the FL role undertaken by the ML training function. The service producer may provide the first IOC to a service consumer to inform the service consumer of a template for a first MOI, enabling the service consumer to understand the first MOI. The service producer may generate a first MOI based on the first IOC and provide it to the service consumer to inform the service consumer of the FL role undertaken by the ML training function in FL training. The first IOC provides a template, while the first MOI is a specific instance generated based on that template.

[0058] In some embodiments, the IOC MLTrainingFunction can be extended with the following attribute (see TS28.105): FL role, indicating the FL role (FL server or FL client) for each type of ML model (identified by the ML model ID) that participates in ML training for the ML training function.

[0059] Figure 6 A flowchart example of a method 600 for managing FL according to some embodiments of the present disclosure is shown. Method 600 can be performed by a service producer (e.g., an MnS producer). As shown, method 600 may include operations 610 and 620.

[0060] At 610, information about a second MOI representing the characteristics of FL is received from the service consumer. The second MOI includes a second attribute indicating the FL client selection requirement. At 620, an FL client is selected based on the FL client selection requirement.

[0061] Figure 7 A flowchart example of a method 700 for managing a service flow according to some embodiments of the present disclosure is shown. Method 700 can be performed by a service consumer (e.g., an MnS consumer). As shown, method 700 may include operations 710 and 720.

[0062] At 710, a second MOI representing the FL characteristics is generated. The second MOI includes a second attribute indicating the FL client selection requirements. At 720, the information of the second MOI is provided to the service producer so that an FL client is selected according to the FL client selection requirements.

[0063] Method 600 or method 700 may include more or fewer operations, which is not limited in this disclosure.

[0064] In some embodiments, the second attribute indicates the FL client selection requirements for each type of ML model.

[0065] In some embodiments, the FL client selection requirements include the minimum amount of data samples available to the FL client or the minimum training performance score for the FL client running the ML model.

[0066] In some embodiments, the service producer may generate a second IOC representing FL characteristics. The second IOC includes a second attribute indicating the FL client selection requirement when the ML training function acts as an FL server. The service producer may then provide the second IOC to the service consumer, informing it of a template for a second MOI. The service consumer can use this template to populate values ​​to generate the second MOI and provide it to the service producer, allowing the producer to select one or more FL clients based on the FL client selection requirement therein. In some embodiments, the IOC representing FL characteristics (including the FL client selection requirement) may be created by the consumer. This disclosure is not limiting in this respect.

[0067] In some embodiments, a new IOC (e.g., named FLRequirements) may be defined to represent FL requirements. This IOC may be associated with an IOC MLTrainingFunction (see TS28.105) (e.g., contained within an IOC MLTrainingFunction, or otherwise associated). In some embodiments, this IOC may include the following attributes: FL client selection requirements for each type of ML model (identified by the ML model ID) when the ML training function acts as an FL server. These requirements may be a minimum amount of data samples available to the FL client, or a minimum training performance score of a provisional local ML model run on local training data samples on the FL client.

[0068] Figure 8 Examples of NRM fragments for FL requirements according to some embodiments of this disclosure are shown. As shown, IOC FLRequirements is associated with one or more instances of IOC MLTrainingFunction.

[0069] Figure 9 A flowchart example of a method 900 for managing FL according to some embodiments of the present disclosure is shown. Method 900 can be performed by a service producer (e.g., an MnS producer). As shown, method 900 may include operations 910 and 920.

[0070] At 910, a third MOI representing the ML training report is generated. The third MOI includes a third attribute indicating the FL result. At 920, the third MOI is provided to the service consumer to inform it of the FL result.

[0071] Figure 10A flowchart example of a method 1000 for managing a service flow (FL) according to some embodiments of the present disclosure is shown. Method 1000 can be performed by a service consumer (e.g., an MnS consumer). As shown, method 1000 may include operations 1010 and 1020.

[0072] At 1010, a third MOI representing the ML training report is received from the service producer. The third MOI includes a third attribute indicating the FL results. At 1020, FL training is managed based on the FL results.

[0073] Method 900 or method 1000 may include more or fewer operations, which is not limited in this disclosure.

[0074] In some embodiments, FL results include performance scores of participating FL clients and the corresponding FL clients running the final global ML model.

[0075] In some embodiments, the third MOI includes a fourth attribute modelPerformanceTraining, a fifth attribute modelPerformanceValidation, or a sixth attribute dataRatioTrainingAndValidation, which are related to the performance values ​​of the FL server running the final global ML model.

[0076] In some embodiments, the service producer can generate a third IOC representing the ML training report. The third IOC includes a third attribute indicating the FL results. The service producer can then provide the third IOC to the service consumer, informing it of a template for the third MOI so that the service consumer can understand the third MOI. The service producer can then generate the third MOI and provide it to the service consumer. The service consumer can then know the FL results and manage FL training based on them, such as updating selection requirements for the FL client or FL server.

[0077] In some embodiments, the IOC MLTrainingReport (see TS28.105) represents a training report of the ML model provided by the training MnS producer. The IOC MLTrainingReport can be extended with the following attributes: FL results, including the participating FL clients and the performance score of the final global ML model running on the local training dataset of each FL client.

[0078] In some embodiments, in the IOC MLTrainingReport (see TS28.105), the attributes modelPerformanceTraining, modelPerformanceValidation, and dataRatioTrainingAndValidation are explicitly defined as representing only the values ​​of the final global ML model run on the local training dataset on the ML training function that acts as an FL server.

[0079] One or more features in the embodiments described for methods 400, 500, 600, 700, 900, and 1000 may be combined in other embodiments. The embodiments in this disclosure may be performed individually or in combination. For example, extensions to the IOC MLTrainingFunction, new IOC FLRequirements, and extensions to the IOC MLTrainingReport may be used simultaneously. This disclosure is not limiting in this respect.

[0080] The NRM-based scheme for managing federated learning proposed in this disclosure can improve the management of federated learning, thereby ensuring the ML training performance of 5G systems.

[0081] Figure 11 A network 1100 according to various embodiments is illustrated. Network 1100 can operate in a manner conforming to the 3GPP technical specifications of LTE or 5G / NR systems. However, the exemplary embodiments are not limited thereto, and the described embodiments are applicable to other networks that benefit from the principles described herein, such as future 3GPP systems, etc.

[0082] Network 1100 may include UE 1102, which may include any mobile or non-mobile computing device designed to communicate with RAN 1104 via an over-the-air connection. UE 1102 may be communicatively coupled to RAN 1104 via a Uu interface. UE 1102 may be, but is not limited to, a smartphone, tablet computer, wearable computing device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, dashboard, head-up display device, in-vehicle diagnostic device, dashboard mobile device, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked device, machine-type communication device, M2M or D2D device, IoT device, etc.

[0083] In some embodiments, network 1100 may include multiple UEs that are directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices that communicate using physical sidelink channels, such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.

[0084] In some embodiments, UE 1102 can also communicate with AP 1106 via an over-the-air connection. AP 1106 can manage a WLAN connection that can be used to offload some / all network traffic from RAN 1104. The connection between UE 1102 and AP 1106 can conform to any IEEE 802.11 protocol, where AP 1106 can be Wireless Fibre. Router. In some embodiments, UE 1102, RAN 1104, and AP 1106 may utilize cellular-WLAN aggregation (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve UE 1102 being configured by RAN 1104 to utilize both cellular radio resources and WLAN resources.

[0085] RAN 1104 may include one or more access nodes, such as AN 1108. AN 1108 can terminate the air interface protocol for UE 1102 by providing access layer protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this way, AN 1108 can enable data / voice connectivity between CN 1120 and UE 1102. In some embodiments, AN 1108 may be implemented in a separate device or as one or more software entities running on a server computer as part of, for example, a virtual network, which may be referred to as CRAN or a virtual baseband unit pool. AN 1108 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN 1108 may be a macrocell base station or a low-power base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell.

[0086] In embodiments where RAN 1104 includes multiple ANs, they may be coupled to each other via an X2 interface (if RAN 1104 is an LTE RAN) or an Xn interface (if RAN 1104 is a 5G RAN). The X2 / Xn interface (which may be separated into a control / user plane interface in some embodiments) allows the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, and so on.

[0087] Each AN of RAN 1104 can manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to UE 1102. UE 1102 can simultaneously connect to multiple cells provided by the same or different ANs of RAN 1104. For example, UE 1102 and RAN 1104 can use carrier aggregation to allow UE 1102 to connect to multiple component carriers, each component carrier corresponding to a Pcell or Scell. In dual connectivity scenarios, the first AN can be the primary node providing the MCG, and the second AN can be the secondary node providing the SCG. The first / second AN can be any combination of eNB, gNB, ng-eNB, etc.

[0088] RAN 1104 provides an air interface via licensed or unlicensed spectrum. To operate in unlicensed spectrum, nodes can use LAA, eLAA, and / or feLAA mechanisms based on CA technology and PCell / Scell. Before accessing unlicensed spectrum, nodes can perform medium / carrier sensing operations based on, for example, a listen-before-talk (LBT) protocol.

[0089] In a V2X scenario, UE 1102 or AN 1108 can be or may act as an RSU, which can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU"; and so on. In one example, the RSU is a computing device coupled to roadside radio frequency circuitry that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic flow statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic flow. The RSU can provide extremely low-latency communication required for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. RSU components may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic flow signal controllers or backhaul networks.

[0090] In some embodiments, RAN 1104 may be an LTE RAN 1110 with an eNB, such as eNB 1112. LTE RAN 1110 provides an LTE air interface with the following characteristics: 15 kHz SCS; CP-OFDM waveforms for DL ​​and SC-FDMA waveforms for UL; turbo coding for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; rely on PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and rely on CRS for cell search and initial acquisition, channel quality measurement, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface may operate in frequency bands below 6 GHz.

[0091] In some embodiments, RAN 1104 can be an NG-RAN 1114 with a gNB, such as gNB 1116, or an NG-RAN 1114 with an ng-eNB, such as ng-eNB 1118. gNB 1116 can connect to a 5G-enabled UE using a 5G NR interface. gNB 1116 can connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 1118 can also connect to the 5G core via an NG interface, but can connect to the UE via an LTE air interface. gNB 1116 and ng-eNB 1118 can connect to each other via an Xn interface.

[0092] In some embodiments, the NG interface can be divided into two parts: an NG user plane (NG-U) interface, which carries traffic data between the nodes of NG-RAN 1114 and UPF 1148 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is the signaling interface between the nodes of NG-RAN 1114 and AMF 1144 (e.g., N2 interface).

[0093] NG-RAN 1114 provides a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simple codes and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface can rely on CSI-RS, PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for PDSCH phase tracking; and a tracking reference signal for time tracking. The 5G-NR air interface can operate on the FR1 band, including sub-6 GHz, or the FR2 band, including bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB, which is an area of ​​the downlink resource grid including PSS / SSS / PBCH.

[0094] In some embodiments, the 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adaptation of SCS. For instance, UE 1102 can be configured with multiple BWPs, each configured with a different SCS. When a BWP change is indicated to UE 1102, the transmitted SCS is also changed. Another example of a use case for BWPs relates to power saving. Specifically, multiple BWPs with different amounts of frequency resources (e.g., PRBs) can be configured for UE 1102 to support data transmission under different traffic load scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with low traffic loads, while allowing power savings at UE 1102 and, in some cases, at gNB 1116. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic loads.

[0095] RAN 1104 is communicatively coupled to CN 1120, which includes network elements to provide various functions to support data and telecommunications services to customers / subscribers (e.g., users of UE 1102). Components of CN 1120 may be implemented in a single physical node or in separate physical nodes. In some embodiments, any or all of the functions provided by the network elements of CN 1120 may be virtualized onto physical compute / storage resources in servers, switches, etc., using NFV. A logical instantiation of CN 1120 may be referred to as a network slice, and a logical instantiation of a portion of CN 1120 may be referred to as a network subslice.

[0096] In some embodiments, CN 1120 may be LTE CN 1122, which may also be referred to as EPC. LTE CN 1122 may include MME 1124, SGW 1126, SGSN 1128, HSS 1130, PGW 1132, and PCRF 1134, which are coupled to each other via interfaces (or "reference points"), as shown in the figure. The functionality of the components of LTE CN 1122 can be briefly described below.

[0097] The MME 1124 enables mobility management functions to track the current location of the UE 1102, facilitating paging, bearer activation / deactivation, handover, gateway selection, authentication, and more.

[0098] The SGW 1126 can terminate the S1 interface facing the RAN and route data packets between the RAN and the LTE CN 1122. The SGW 1126 can serve as a local mobility anchor point for handovers between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0099] The SGSN 1128 can track the location of UE 1102 and perform security functions and access control. Furthermore, the SGSN 1128 can perform EPC inter-node signaling for mobility between different RAT networks; select the PDN and S-GW according to MME 1124; select the MME for handover; and so on. The S3 reference point between MME 1124 and SGSN 1128 can enable user and bearer information exchange for mobility between 3GPP access networks in idle / active states.

[0100] The HSS1130 may include a database for network users, including reservation-related information to support network entities in managing communication sessions. The HSS1130 provides support for routing / roaming, authentication, authorization, naming / addressing resolution, location compliance, and more. An S6a reference point between the HSS1130 and the MME 1124 enables the transmission of reservation and authentication data to authenticate / authorize user access to the LTE CN 1120.

[0101] PGW 1132 may terminate an SGi interface toward a data network (DN) 1136, which may include an application / content server 1138. PGW 1132 may route data packets between the LTE CN 1122 and the data network 1136. PGW 1132 may be coupled to SGW 1126 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 1132 may also include nodes for policy enforcement and charging data collection (e.g., PCEF). Furthermore, the SGi reference point between PGW 1132 and the data network 1136 may be an external public or private PDN or an internal packet data network, such as a configuration for IMS services. PGW 1132 may be coupled to PCRF 1134 via a Gx reference point.

[0102] PCRF 1134 is the policy and charging control element of LTE CN 1122. PCRF 1134 can be communicatively coupled with application / content server 1138 to determine appropriate QoS and charging parameters for service flows. PCRF 1132 can configure associated rules into PCEF (via Gx reference point) with appropriate TFT and QCI.

[0103] In some embodiments, CN 1120 may be 5GC 1140. 5GC 1140 may include AUSF 1142, AMF1144, SMF 1146, UPF 1148, NSSF 1150, NEF 1152, NRF 1154, PCF 1156, UDM 1158, and AF1160, which are coupled to each other via interfaces (or “reference points”), as shown in the figure. The functionality of the components of 5GC 1140 can be briefly described below.

[0104] The AUSF 1142 stores data for UE 1102 authentication and handles authentication-related functions. The AUSF 1142 facilitates a common authentication framework for various access types. In addition to communicating with other components of the 5GC 1140 via a reference point, as shown in the figure, the AUSF 1142 also presents a Nausf service-based interface.

[0105] AMF 1144 allows other functions of 5GC 1140 to communicate with UE 1102 and RAN 1104, and to subscribe to notifications regarding mobility events for UE 1102. AMF 1144 can handle registration management (e.g., for registering UE 1102), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 1144 can provide transport for SM messages between UE 1102 and SMF 1146 and acts as a transparent broker for routing SM messages. AMF 1144 can also provide transport for SMS messages between UE 1102 and SMSF 1146. AMF 1144 can interact with AMFF 1142 and UE 1102 to perform various security anchoring and context management functions. Furthermore, AMF 1144 can be a termination point for the RAN CP interface, which may include or be the N2 reference point between RAN 1104 and AMF 1144; and AMF 1144 can be a termination point for NAS (N1) signaling, and perform NAS encryption and integrity protection. AMF 1144 can also support NAS signaling with UE 1102 via the N3 IWF interface.

[0106] SMF 1146 may be responsible for SM (e.g., session establishment, tunnel management between UPF 1148 and AN 1108); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuration of traffic manipulation at UPF 1148 to route traffic to appropriate destinations; termination of interfaces for policy control functions; control portions for policy enforcement, charging, and QoS; lawful interception (for SM events and interfaces to the LI system); termination of the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent to AN 1108 via N2 through AMF 1144; and determining the SSC mode of the session. SM may refer to the management of PDU sessions, while a PDU session or “session” may refer to the PDU connectivity service that provides or enables the exchange of PDUs between UE 1102 and data network 1136.

[0107] The UPF 1148 can serve as an anchor point for mobility within and between RATs, an external PDU session point for interconnection to the data network 1136, and a branch point supporting multi-homed PDU sessions. The UPF 1148 can also perform packet routing and forwarding, packet inspection, enforce policy rules in the user plane portion, legally intercept packets (UP collection), perform traffic usage reporting, perform QoS actions for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic authentication (e.g., SDF-to-QoS flow mapping), transport-level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 1148 may include an uplink classifier to support traffic flow routing to the data network.

[0108] The NSSF 1150 can select a set of network slice instances to serve UE 1102. If needed, the NSSF 1150 can also determine the allowed NSSAIs and the mapping to the pre-booked S-NSSAIs. The NSSF 1150 can also determine, based on appropriate configuration and possibly by querying the NRF 1154, the set of AMFs to be used for serving UE 1102, or a list of candidate AMFs. The selection of a set of network slice instances for UE 1102 can be triggered by the AMF 1144 to which UE 1102 has registered, through interaction with the NSSF 1150, which can result in a change of AMF. The NSSF 1150 can interact with AMF 1144 via reference point N22; and can communicate with another NSSF in the visited network via reference point N31 (not shown). Furthermore, the NSSF 1150 can present a service-based interface for NNSSF.

[0109] The NEF 1152 can securely expose services and capabilities provided by 3GPP network functions, internal exposure / re-exposure, AFs (e.g., AF 1160), edge computing, or fog computing systems, etc., to third parties. In this embodiment, the NEF 1152 can authenticate, authorize, or suppress AFs. The NEF 1152 can also translate information exchanged with AF 1160 and information exchanged with internal network functions. For example, the NEF 1152 can translate between AF service identifiers and internal 5GC information. The NEF 1152 can also receive information from other NFs based on their exposure capabilities. This information can be stored as structured data at the NEF 1152 or stored at a data storage NF using a standardized interface. The stored information can then be re-exposed by the NEF 1152 to other NFs and AFs, or used for other purposes, such as parsing. Furthermore, the NEF 1152 can expose the Nnef's service-based interface.

[0110] NRF 1154 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to those instances. NRF 1154 also maintains information about available NF instances and the services they support. As used herein, terms like "instantiation" can refer to the creation of an instance, while "instance" can refer to the actual occurrence of an object, which can happen, for example, during the execution of program code. Furthermore, NRF 1154 can present a service-based interface for NnRF.

[0111] The PCF 1156 can provide policy rules to control plane functions to enable their enforcement and also supports a unified policy framework to constrain network behavior. The PCF 1156 can also enable front-ends to access reservation information related to policy decisions in the UDR of the UDM 1158. In addition to communicating with functions via reference points as shown in the figure, the PCF 1156 can also present an NPCF service-based interface.

[0112] UDM 1158 can handle reservation-related information to support network entities in managing communication sessions and can store reservation data for UE 1102. For example, reservation data can be communicated via the N8 reference point between UDM 1158 and AMF 1144. UDM 1158 may include two parts: an application front-end and a UDR. The UDR can store reservation data and policy data for UDM 1158 and PCF 1156, and / or store structured data and application data (including PFDs for application detection and application request information for multiple UEs 1102) for NEF 1152. The Nudr's service-based interface can be presented by the UDR to allow UDM 1158, PCF 1156, and NEF 1152 to access a specific set of stored data, as well as to read, update (e.g., add, modify), delete, and notify of relevant data changes in the reservation UDR. UDM may include UDM-FE, which is responsible for handling credentials, location management, reservation management, etc. Several different front-ends can serve the same user in different transactions. The UDM-FE accesses reservation information stored in the UDR and performs authentication credential processing, user identity disposal, access authorization, registration / mobility management, and reservation management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 1158 also presents a Nudm service-based interface.

[0113] The AF 1160 can provide application impact on traffic routing, provide access to NEF, and enable interaction with policy frameworks for policy control.

[0114] In some embodiments, 5GC 1140 can enable edge computing by selecting an operator / third-party service to be geographically close to the point where UE 1102 is attached to the network. This can reduce latency and load on the network. To provide edge computing implementation, 5GC 1140 can select a UPF 1148 close to UE 1102 and perform traffic manipulation from UPF 1148 to data network 1136 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 1160. Thus, AF 1160 can influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 1160 is considered a trusted entity, the network operator can allow AF 1160 to interact directly with the relevant NF. Furthermore, AF 1160 can expose a service-based interface of Naf.

[0115] Data network 1136 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, such as application / content server 1138.

[0116] Figure 12 A wireless network 1200 according to various embodiments is schematically illustrated. The wireless network 1200 may include a UE 1202 that communicates wirelessly with an AN 1204. The UE 1202 and the AN 1204 may be components with similar names as described elsewhere herein and are substantially interchangeable with these components.

[0117] UE 1202 can be communicatively coupled to AN 1204 via connection 1206. Connection 1206 is illustrated as an air interface for communication coupling and can conform to cellular communication protocols, such as LTE or 5G NR protocols operating at mmWave or sub-6 GHz frequencies.

[0118] UE 1202 may include a host platform 1208 coupled to a modem platform 1210. Host platform 1208 may include application processing circuitry 1212, which may be coupled to protocol processing circuitry 1214 of modem platform 1210. Application processing circuitry 1212 may run various applications for UE 1202 to source / pool application data. Application processing circuitry 1212 may further implement one or more layer operations to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0119] Protocol processing circuitry 1214 can implement one or more layer operations to facilitate the transmission or reception of data via connection 1206. Layer operations implemented by protocol processing circuitry 1214 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0120] The modem platform 1210 may also include digital baseband circuitry 1216, which implements one or more layer operations in the network protocol stack that are "below" the layer operations performed by the protocol processing circuitry 1214. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functionality, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding (which may include one or more of space-time, space-frequency, or spatial coding), reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, blind decoding of control channel signals, and other related functions.

[0121] The modem platform 1210 may also include transmitting circuitry 1218, receiving circuitry 1220, RF circuitry 1222, and an RF front end (RFFE) 1224, which may include or be connected to one or more antenna panels 1226. In short, transmitting circuitry 1218 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; receiving circuitry 1220 may include an analog-to-digital converter, a mixer, an IF component, etc.; RF circuitry 1222 may include a low-noise amplifier, a power amplifier, a power tracking component, etc.; and RFFE 1224 may include filters (e.g., surface acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of components such as the transmitting circuit 1218, receiving circuit 1220, RF circuit 1222, RFFE 1224, and antenna panel 1226 (generally referred to as the "transmit / receive assembly") can depend on the details of the specific implementation, such as whether the communication is TDM or FDM, at mmWave or below 6 GHz, etc. In some embodiments, the transmit / receive assembly may be arranged in multiple parallel transmit / receive chains, may be arranged in the same or different chips / modules, etc.

[0122] In some embodiments, the protocol processing circuitry 1214 may include one or more instances of control circuitry (not shown) to provide control functions for the transmitting / receiving components.

[0123] UE reception can be established and established via antenna panel 1226, RFFE 1224, RF circuit 1222, receiving circuit 1220, digital baseband circuit 1216, and protocol processing circuit 1214. In some embodiments, antenna panel 1226 can receive transmissions from AN 1204 via receive beamforming signals received by a plurality of antennas / antenna elements of one or more antenna panels 1226.

[0124] UE transmission can be established and established via the protocol processing circuit 1214, digital baseband circuit 1216, transmission circuit 1218, RF circuit 1222, RFFE 1224, and antenna panel 1226. In some embodiments, the transmission components of UE 1204 can apply a spatial filter to the data to be transmitted to form a transmission beam emitted by the antenna elements of antenna panel 1226.

[0125] Similar to UE 1202, AN 1204 may include a host platform 1228 coupled to modem platform 1230. Host platform 1228 may include application processing circuitry 1232 coupled to protocol processing circuitry 1234 of modem platform 1230. The modem platform may also include digital baseband circuitry 1236, transmitting circuitry 1238, receiving circuitry 1240, RF circuitry 1242, RFFE circuitry 1244, and antenna panel 1246. Components of AN 1204 may be similar to those of similarly named components in UE 1202 and are substantially interchangeable. In addition to performing data transmission / reception as described above, components of AN 1208 may perform various logical functions, including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0126] Figure 13 The block diagram illustrates components, according to some example embodiments, capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein. Specifically, Figure 13 A schematic representation of hardware resources 1300 is shown, including one or more processors (or processor cores) 1310, one or more memory / storage devices 1320, and one or more communication resources 1330, each of which may be communicatively coupled via bus 1340 or other interface circuitry. In embodiments utilizing node virtualization (e.g., NFV), a hypervisor 1302 may be executed to provide an execution environment for one or more network slices / subslices utilizing hardware resources 1300.

[0127] Processor 1310 may include, for example, processor 1312 and processor 1314. Processor 1310 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination of these.

[0128] Memory / storage device 1320 may include main memory, disk storage devices, or any suitable combination thereof. Memory / storage device 1320 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage devices, and so on.

[0129] Communication resource 1330 may include an interconnect or network interface controller, component, or other suitable device for communicating via network 1308 with one or more peripheral devices 1304 or one or more databases 1306 or other network elements. For example, communication resource 1330 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, etc. (or low energy consumption) ) components, Components, and other communication components.

[0130] Instructions 1350 may include software, programs, applications, applets, or other executable code for causing at least any one of the processors 1310 to perform any one or more of the methods discussed herein. Instructions 1350 may reside wholly or partially within at least one of the processors 1310 (e.g., within the processor's cache memory), within memory / storage device 1320, or any suitable combination thereof. Furthermore, any portion of instructions 1350 may be transferred from any combination of peripheral device 1304 or database 1306 to hardware resource 1300. Therefore, the memory of processor 1310, memory / storage device 1320, peripheral device 1304, and database 1306 are examples of computer-readable and machine-readable media.

[0131] Figure 14 Network 1400 is illustrated according to various embodiments. Network 1400 can operate in a manner conforming to 3GPP technical specifications or technical reports for 6G systems. In some embodiments, network 1400 can operate simultaneously with network 1100. For example, in some embodiments, network 1400 can share one or more frequency or bandwidth resources with network 1100. As a specific example, a UE (e.g., UE 1402) can be configured to operate in both network 1400 and network 1100. This configuration may be based on the UE including circuitry configured to communicate with the frequency and bandwidth resources of both network 1100 and network 1400. Generally, several elements of network 1400 may share one or more characteristics with elements of network 1100. For the sake of brevity and clarity, these elements may not be repeated in the description of network 1400.

[0132] Network 1400 may include UE 1402, which may include any mobile or non-mobile computing device designed to communicate with RAN 1408 via an over-the-air connection. UE 1402 may be similar to, for example, UE 1102. UE 1402 may be, but is not limited to, a smartphone, tablet computer, wearable computing device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, dashboard, head-up display device, in-vehicle diagnostic device, dashboard mobile device, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked device, machine-type communication device, M2M or D2D device, IoT device, etc.

[0133] Although Figure 14Not specifically shown, but in some embodiments, network 1400 may include multiple UEs that are directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices that communicate using physical sidelink channels, such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. Similarly, although in Figure 14 Not specifically shown, but UE 1402 can be used with AP (e.g., reference). Figure 11 The AP 1106 described is communicatively coupled. Furthermore, although in Figure 14 Not specifically shown, but in some embodiments, RAN 1408 may include one or more ANs, for example, as referenced. Figure 11 The AN1108 described. RAN 1408 and / or the AN of RAN 1408 may be referred to as a base station (BS), RAN node, or some other term or name.

[0134] UE 1402 and RAN 1408 can be configured to communicate via an air interface that may be referred to as a sixth-generation (6G) air interface. The 6G air interface may include one or more features, such as communication in the terahertz (THz) or sub-THz bandwidth, or combined communication and sensing. As used herein, the term "combined communication and sensing" can refer to a system that implements wireless communication and radar-based sensing via various types of multiplexing. As used herein, THz or sub-THz bandwidth can refer to communication in the frequency range of 80 GHz and above. This frequency range may additionally or alternatively be referred to as the "millimeter wave" or "mmWave" frequency range.

[0135] RAN 1408 enables communication between UE 1402 and the 6G core network (CN) 1410. Specifically, RAN 1408 facilitates the transmission and reception of data between UE 1402 and the 6G CN 1410. The 6G CN 1410 may include various functions such as NSSF 1150, NEF 1152, NRF 1154, PCF 1156, UDM 1158, AF 1160, SMF 1146, and AUSF 1142. Figure 14 As shown, 6G CN 1410 may also include UPF 1148 and DN 1136.

[0136] In addition, RAN 1408 may include various additional functions that are additions to or replacements for functions of traditional cellular networks (such as 4G or 5G networks). Two such functions may include Compute Control Function (Comp CF) 1424 and Compute Service Function (Comp SF) 1436. Comp CF 1424 and Comp SF 1436 may be parts or functions of the Compute Service Plane. CompCF 1424 may be a control plane function that provides functions such as: management of Comp SF 1436, generation and management of compute task contexts (e.g., creation, reading, modification, deletion), interaction with the underlying compute infrastructure for compute resource management, etc. Comp SF 1436 may be a user plane function that acts as an interface gateway between compute service users (e.g., UE 1402) and the compute nodes behind the CompSF instance. Some functions of Comp SF 1436 may include: parsing compute service data received from users to compute tasks that can be performed by compute nodes; maintaining the service mesh ingress gateway or service API gateway; enforcing service and charging policies; performance monitoring and telemetry collection, etc. In some embodiments, a Comp SF 1436 instance can serve as a user plane gateway for a cluster of compute nodes. A Comp CF 1424 instance can control one or more Comp SF 1436 instances.

[0137] Two other such functions may include a communication control function (Comm CF) 1428 and a communication service function (CommSF) 1438, which may be part of the communication service plane. Comm CF 1428 may be a control plane function for managing Comm SF 1438, communication session creation / configuration / release, and managing communication session contexts. CommSF 1438 may be a user plane function for data transfer. CommCF 1428 and Comm SF 1438 can be considered upgrades to SMF 1146 and UPF 1148, for which reference has been made. Figure 11 The 5G system described in the document. Upgrades provided by Comm CF 1428 and Comm SF1438 enable service-aware transport. For legacy (e.g., 4G or 5G) data transmission, SMF1146 and UPF 1148 can still be used.

[0138] Two other such functions may include a data control function (Data CF) 1422 and a data service function (Data SF) 1432, which may be part of the data service plane. Data CF 1422 may be a control plane function and provide functions such as data SF 1432 management, data service creation / configuration / release, data service context management, etc. Data SF 1432 may be a user plane function and act as a gateway between data service users (e.g., various functions of UE 1402 and 6G CN 1410) and the data service endpoints behind the gateway. Specific functions may include: parsing data service user data and forwarding it to the appropriate data service endpoint, generating billing data, and reporting data service status.

[0139] Another such function is the Service Orchestration and Chaining (SOCF) function 1420, which can discover, orchestrate, and chain communication / computing / data services provided by functions in the network. Upon receiving a service request from a user, SOCF 1420 can interact with one or more of Comp CF 1424, Comm CF 1428, and Data CF 1422 to identify Comp SF 1436, Comm SF 1438, and Data SF 1432 instances, configure service resources, and generate a service chain, which may contain multiple Comp SF 1436, Comm SF 1438, and Data SF 1432 instances and their associated compute endpoints. Workload processing and data movement can then be performed within the generated service chain. SOCF 1420 can also be responsible for maintaining, updating, and releasing the created service chains.

[0140] Another such function could be a service registration function (SRF) 1414, which can act as a registry center for system services provided in the user plane, such as services provided by service endpoints behind the Comp SF 1436 and Data SF 1432 gateways, as well as services provided by UE 1402. SRF 1414 can be considered a counterpart to NRF 1154, which can act as a registry center for network functions.

[0141] Other such capabilities may include an evolved service communication proxy (eSCP) and a service infrastructure control function (SICF) 1426, which provide service communication infrastructure for control plane services and user plane services. The eSCP may be related to the 5G service communication proxy (SCP) and adds user plane service communication proxy capabilities. The eSCP is therefore expressed as two parts: eCSP-C 1412 and eSCP-U 1434, used for the control plane service communication proxy and the user plane service communication proxy, respectively. SICF 1426 can control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configuration, performance monitoring, and more.

[0142] Another such feature is AMF 1444. AMF 1444 is similar to 1144 but has additional functionality. Specifically, AMF 1444 may include potential functional refactoring, such as moving message forwarding functionality from AMF 1444 to RAN 1408.

[0143] Another such feature is the service orchestration exposure function (SOEF) 1418. SOEF can be configured to expose service orchestration and chaining services to external users (such as applications).

[0144] UE 1402 may include additional functionality called Computational Client Service Function (comp CSF) 1404. comp CSF 1404 may have both control plane and user plane functions and can interact with corresponding network-side functions (e.g., SOCF 1420, Comp CF 1424, Comp SF 1436, Data CF 1422, and / or Data SF 1432) to perform service discovery, request / response, compute task workload exchange, and so on. Comp CSF 1404 may also cooperate with network-side functions to determine whether compute tasks should run on elements of UE 1402, RAN 1408, and / or 6G CN 1410.

[0145] UE 1402 and / or Comp CSF 1404 may include a service mesh agent 1406. The service mesh agent 1406 may act as a proxy for service-to-service communication in the user plane. The functions of the service mesh agent 1406 may include one or more of addressing, security, load balancing, etc.

[0146] Figure 15 An example functional framework 1500 for ML and / or RAN intelligence is depicted. Functional framework 1500 includes a data collection function 1505 that provides input data to model training function 1510 and model inference function 1515. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting and transformation) may or may not be performed in data collection function 1505. Examples of input data may include: measurements from UEs, RAN nodes, and / or attached or alternative network entities; feedback from actor 1520; and / or outputs from one or more ML models. The input data fed to model training function 1510 is training data, and the input data fed to model inference function 1515 is inference data.

[0147] Model training function 1510 is a function that performs ML model training, validation, and testing. As part of the model testing and / or model validation process, model training function 1510 can generate model performance metrics. Examples of model performance metrics are discussed below. If needed, model training function 1510 can also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the training data provided by data collection function 1505.

[0148] Model training function 1510 performs model deployment / update, wherein model training function 1510 initially deploys a trained, validated, and tested ML model to model inference function 1515, and / or delivers one or more updated models to model inference function 1515. Examples of model deployment and update are discussed below.

[0149] Model inference function 1515 provides ML model inference outputs (e.g., statistical inference, prediction, decision-making, probability and / or probability distributions, actions, configurations, strategies, data analysis, results, optimizations, etc.). Model inference function 1515 can provide model performance feedback to model training function 1510 when applicable. Model performance feedback may include various performance metrics related to the generation of inference (e.g., any metrics discussed herein). Model performance feedback can be used to monitor the performance of the ML model when applicable. If necessary, model inference function 1515 can also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the inference data provided by data collection function 1505.

[0150] Model inference function 1515 produces inference output, which is the inference generated by model inference function 1515 when it manipulates the ML model using inference data, or otherwise. Model inference function 1515 provides the inference output to actor 1520. The details of the inference output are related to the specific use case and may be based on the specific type of ML model being used.

[0151] Actor 1520 is a function that receives inference output from model inference function 1515 and triggers or otherwise performs corresponding operations based on the inference output. Actor 1520 can trigger operations against other entities and / or itself. In some examples, actor 1520 is an NES function, a mobility optimization function, and / or a load balancing function. Additionally or alternatively, the inference output is associated with NES, mobility optimization, and / or load balancing, and actor 1520 is one or more RAN nodes that perform various NES operations, mobility optimization operations, and / or load balancing operations based on the inference.

[0152] The actor 1520 can also provide feedback to the data collection function 1505 for storage. The feedback includes information related to the actions performed by the actor 1520. The feedback may include any information that might be needed to acquire training data (and / or test data and / or validation data), inference data, and / or data for monitoring the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0153] Figure 16 An example AI / ML-assisted communication network including communication between ML Function (MLF) 1602 and MLF 1604 is described. In some implementations, ML models / entities may be used or utilized to facilitate wired and / or over-the-air communication between MLF 1602 and MLF 1604. In this embodiment, the operation of MLF 1602 and MLF 1604 conforms to 3GPP technical specifications and / or technical reports for 5G and / or 6G systems, such as any technical reports discussed herein. In some examples, the communication mechanism between MLF 1602 and MLF 1604 includes any suitable access technology and / or RAT, such as any technology and / or RAT discussed herein. Furthermore, Figure 16 The communication mechanism in can be Figure 1-13 and / or other components, devices, systems, networks and / or deployments described herein, or operating concurrently with them.

[0154] MLF 1602 and 1604 may correspond to any entity / component discussed herein. In one example, MLF 1602 corresponds to MnF and / or MnS-P, and MLF 1604 corresponds to Consumer, MnS-C, and vice versa. In this example, the groups of MLFs may be mutually exclusive, or some or all of the MLFs in the groups may overlap or be shared. In another example, MLF 1602 and / or MLF 1604 are implemented by the corresponding UE (e.g., UE 1102, UE 1202, UE 1402). Additionally or alternatively, MLF 1602 and / or MLF 1604 may be implemented by the same UE or different UEs. In yet another example, MLF 1602 and / or MLF 1604 may be implemented by the corresponding RAN or the corresponding NAN. Additionally or alternatively, some or all of the components / entities in individual MLF 1602 and 1604 may be implemented or operated by separate entities / components.

[0155] like Figure 16 As shown, MLF 1602 and MLF 1604 include various AI / ML-related components, functions, elements, or entities that can be implemented as hardware, software, firmware, and / or some combination thereof. In some examples, one or more AI / ML-related elements are implemented as part of the same hardware (e.g., integrated circuit, chip, or multiprocessor chip), software (e.g., program, process, engine, etc.), or firmware as at least one other element, function, element, or entity. AI / ML-related elements of MLF 1602 may be the same as or similar to AI / ML-related elements of MLF 1604. For brevity, the various elements will be described from the perspective of MLF 1602, but it is understood that, unless explicitly stated otherwise, such description applies to similar named / numbered elements of MLF 1604.

[0156] Data repository 1615 is responsible for data collection and storage. As an example, data repository 1615 may collect and store RAN configuration parameters, NF configuration parameters, measurement data, RLM data, key performance indicators (KPIs), SLAs, model performance indicators, knowledge base data, ground fact data, ML model parameters, hyperparameters, and / or other data used for model training, updates, and inference. In some examples, a data collection function (not shown) is part of or connected to data repository 1615. The data collection function is a function that provides input data to MLTF 1625 and model inference function 1645. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) may or may not be performed in the data collection function. Examples of input data may include measurements from UEs, RAN nodes, and / or attached or alternative network entities; feedback from actors; and / or outputs from one or more ML models. The input data fed to MLTF 1625 is training data, and the input data fed to model inference function 1645 is inference data.

[0157] The collected data is stored in / via repository 1615, and the stored data can be discovered and retrieved from data repository 1615 by other components. For example, inference data selector / filter 1650 can retrieve data from data repository 1615 and provide that data to inference engine 1645 to generate / determine inference. In various examples, MLF 1602 is configured to discover and request data from data repository 1615 in MLF 1604, and / or vice versa. In these examples, data repository 1615 of MLF 1602 may be communicatively coupled to data repository 1615 of MLF 1604, so that the respective data repositories 1615 can share collected data with each other. Additionally or alternatively, MLF 1602 and / or MLF 1604 are configured to discover and request data from one or more external sources and / or data storage systems / devices.

[0158] Training data selection / filter 1620 is configured to generate training, validation, and test datasets for ML training (MLT) (or ML model training). One or more of these datasets can be extracted from data repository 1615 or otherwise obtained. Data can be selected / filtered based on the specific ML model to be trained. The data can optionally be transformed, augmented, and / or preprocessed (e.g., normalized) before being loaded into the dataset. Training data selection / filter 1620 can label the data in the dataset for supervised learning or leave the data unlabeled for unsupervised learning. The resulting dataset can then be fed into MLT function (MLTF) 1625.

[0159] The MLTF 1625 is responsible for training and updating (e.g., tuning and / or retraining) ML models. Selected models (or sets of models) can be trained using datasets (including training, validation, and testing data) fed in from the training data selector / filter 1620. The MLTF 1625 generates trained and tested ML models that are ready for deployment. The generated trained and tested models can be stored in the model library 1635. Additionally or alternatively, the MLTF 1625 performs ML model training, validation, and testing. As part of the model testing and / or model validation process, the MLTF 1625 can generate model performance metrics. Examples of model performance metrics are discussed below. If needed, the MLTF 1625 can also handle data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the data collection capabilities and / or the training data provided by the training data selector / filter 1620. MLTF 1625 performs model deployment / updates, whereby MLTF 1625 initially deploys a trained, validated, and tested ML model to Model Inference Function 1645, and / or delivers one or more updated models to Model Inference Function 1645. Examples of model deployment and updates are discussed below.

[0160] Model library 1635 is responsible for the storage and exposure of ML models (trained and untrained). Various types of model data can be stored in model library 1635. For example, model data may include (one or more) trained / updated models, model parameters, hyperparameters, and / or model metadata such as model performance metrics, hardware platform / configuration data, model execution parameters / conditions, etc. In some examples, model data may also include inferences made while running the ML model. Model data can be discovered and requested by other MLF components (e.g., training data selector / filter 1620 and / or MLTF 1625). In some examples, MLF 1602 can discover and request model data from model library 1635 of MLF 1604. Additionally or alternatively, MLF 1604 can discover and / or request model data from model library 1635 of MLF 1602. In some examples, MLF 1604 can configure models, model parameters, hyperparameters, model execution parameters / conditions, and / or other aspects of ML models within the MLF 1602 model library 1635. For manageability purposes, this paper also refers to ML models as ML entities; that is, the terms ML model and ML entity are used interchangeably in this paper.

[0161] Model management function 1640 is responsible for managing the ML models generated by MLTF 1625. Such management functions may include: deploying trained models, monitoring ML entity performance, reporting ML entity validation and / or performance data, etc. When deploying a model, model management function 1640 can allocate and schedule hardware and / or software resources for inference based on the received trained and tested model. For the purposes of this disclosure, the term "inference" refers to the process of generating statistical inference, predictions, decisions, probabilities and / or probability distributions, actions, configurations, policies, data analysis, results, optimizations, etc., using one or more trained ML models based on new, unseen data (e.g., "input inference data"). In some examples, the inference process may include: feeding input inference data to an ML model (e.g., inference engine 1645), forwarding input inference data through the architecture / topology of the ML model, wherein the ML model performs computations on the data using its learned parameters (e.g., weights and biases), and predicting outputs. In some examples, the inference process may include data transformation prior to the forward pass, where the input inference data is preprocessed or transformed to match the format required by the ML model. In performance monitoring, based on model performance KPIs and / or metrics, model management function 1640 can decide to terminate a running model, begin model retraining and / or tuning, select another model, etc. In the examples, model management function 1640 of MLF 1604 can configure model management policies as in MLF 1602, and vice versa.

[0162] As described below, the inference data selection / filter 1650 is responsible for generating the dataset for model inference at inference 1645. For example, inference data can be extracted from the data repository 1615. The inference data selection / filter 1650 can select and / or filter data based on the deployed ML model. The data can be transformed, enhanced, and / or preprocessed in the same or similar manner as the training data selection / filtering (e.g., as described for training data selection filter 1620). The generated inference dataset can be fed into the inference engine 1645.

[0163] The inference engine 1645 (also referred to as "model inference function 1645", etc.) is responsible for performing / generating the inference described herein. The inference engine 1645 consumes the inference dataset provided by the inference data selection / filter 1650 and generates ML model inference output, which includes one or more inferences. For example, inference can be or include statistical inference, prediction, decision-making, probability and / or probability distribution, action, configuration, strategy, data analysis, results, optimization, etc. One or more inferences / one or more results may be provided to the performance measurement function 1630. Where applicable, the model inference function 1645 may provide model performance feedback to the MLTF 1625 and / or the performance measurement function 1630. Model performance feedback may include various performance metrics related to the generation of inference (e.g., any metrics discussed herein). Model performance feedback may be used, where applicable, to monitor the performance of the ML model. If necessary, the model inference function 1645 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the inference data provided by the data collection function and / or the inference data selection / filter 1650. Model inference function 1645 generates inference output, which is the inference generated by model inference function 1645 when running an ML model using inference data (set), or otherwise generated. The details of the inference output are related to the specific use case and can be based on the specific type of ML model being used.

[0164] In some examples, model inference function 1645 provides inference output to an actor (not shown). An actor is a function, engine, component, device, system, network, and / or other entity that receives inference output from model inference function 1645 and triggers or otherwise performs corresponding actions(s) based on the inference output. An actor may trigger actions against other entities and / or itself. In some examples, an actor is a Network Energy Saving (NES) function, a Mobility Robustness Optimization (MRO) function, a Load Balancing Optimization (LBO) function, and / or other Ad Hoc Networking (SON) function, including any functions mentioned herein. Additionally or alternatively, the inference output is related to NES, MRO, and / or LBO, and the actor is one or more RAN nodes that perform various NES, MRO, and / or LBO operations based on inference. The actor may also provide feedback to performance measurement function 1630 and / or data collection function / data repository 1615 for storage. The actor feedback includes information related to the actions performed by the actor. For example, feedback includes any information that may be needed to obtain training data, test data and / or validation data; inference data; and / or data to monitor the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0165] Performance measurement function 1630 is configured to measure model performance metrics (e.g., accuracy, momentum, precision, magnitude, recall / sensitivity, model bias, runtime latency, resource consumption, and / or other suitable metrics / measures, such as any of those discussed herein) of deployed and executing models based on one or more inference methods for monitoring purposes. Model performance data may be stored in data repository 1615 and / or reported according to the validation reporting mechanism discussed herein.

[0166] The performance measurement function 1630 can measure and / or predict performance metrics based on specific AI / ML tasks and other inputs / parameters of ML entities. Performance metrics can include model-based metrics and platform-based metrics. Model-based metrics are metrics related to the performance of the model itself and / or do not consider the underlying hardware platform. Platform-based metrics are related to the performance of the underlying hardware platform when running the ML model.

[0167] Model-based metrics can be based on specific types of ML models and / or AI / ML domains. For example, regression-related metrics can be used to predict regression-based ML models. Examples of regression-related metrics include error values, mean error, mean absolute error (MAE), mean reciprocal rank (MRR), mean squared error (MSE), root MSE (RMSE), correlation coefficient (R), coefficient of determination (R²), Golbraikh and Tropsha criteria, and / or other similar regression-related metrics, such as those discussed in the paper Naser et al. (Insights into Performance Fitness and Error Metrics for Machine Learning, arXiv:2006.00887v1(17May 2020)(“[Naser]”)).

[0168] In another example, correlation metrics can be used to predict correlation-related models. Examples of correlation metrics include accuracy, precision (also known as positive predictive value (PPV)), mean precision (mAP), negative predictive value (NPV), recall (also known as true positive rate (TPR) or sensitivity), specificity (also known as true negative rate (TNR) or selectivity), false positive rate, false negative rate, F-score (e.g., F1 score, F2 score, Fβ score, etc.), Matthews correlation coefficient (MCC), significance, receiver operating characteristic (ROC), area under the ROC curve (AUC), distance score, and / or other similar correlation metrics, such as those discussed in [Naser].

[0169] It is also possible to predict other or alternative model-based metrics, such as cumulative gain (CG), discounted CG (DCG), normalized DCG (NDCG), signal-to-noise ratio (SNR), peak signal-to-noise ratio (PSNR), structural similarity (SSIM), joint crossover (IoU), perplexity, bilingual evaluation surrogate study (BLEU) score, initial score, Wasserstein metric, Fréchet inception distance (FID), string metric, edit distance, Levenshtein distance, Damerau–Levenshtein distance, number of evaluation instances (e.g., iterations, duration, or events), learning rate (e.g., how quickly the algorithm reaches (converges to) the optimal weights), learning rate decay (or weight decay), number and / or type of computations, number and / or type of multiply and accumulates (MAC), number and / or type of multiply adds (MAdds) operations, and / or other similar performance metrics related to ML model performance.

[0170] Platform-based metrics include latency, response time, throughput (e.g., the rate at which a processor or platform / system processes jobs), availability and / or reliability, power consumption (e.g., performance per watt and / or similar metrics), number of transistors, execution time (e.g., the amount of time to obtain inference and / or similar metrics), memory footprint, memory utilization, processor utilization, processor time, computations, instructions per second (IPS), floating-point operations per second (FLOPS), and / or other similar performance metrics related to the performance of the ML model and / or the underlying hardware platform used to run the ML model.

[0171] Additionally or alternatively, surrogate metrics (e.g., metrics or attributes used as substitutes or substitutes for another metric or attribute) may be used to predict the performance of the ML model. For any of the performance metrics described above, any suitable data collection and / or measurement mechanism may be used to predict and / or measure the total, mean, and / or other distributions of such metrics.

[0172] The following paragraphs describe examples of various embodiments.

[0173] Example 1 includes an apparatus comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: generate a first managed object instance (MOI) representing a machine learning (ML) training function, wherein the first MOI includes a first attribute indicating the FL role assumed by the ML training function in federated learning (FL) training; and provide the first MOI to a service consumer via the interface circuit to inform the ML training function of its FL role in FL training.

[0174] Example 2 includes the apparatus described in Example 1 or any other example herein, wherein the FL role includes an FL server or an FL client.

[0175] Example 3 includes the apparatus described in Example 1 or any other example herein, wherein the first attribute indicates an FL role for each type of ML model.

[0176] Example 4 includes the apparatus described in Example 1 or any other example herein, wherein the processor circuitry is further configured to: receive information of a second MOI from the service consumer via the interface circuitry, the second MOI representing a characteristic of FL, wherein the second MOI includes a second attribute indicating an FL client selection requirement; and select an FL client based on the FL client selection requirement.

[0177] Example 5 includes the apparatus described in Example 4 or any other example herein, wherein the second attribute indicates the FL client selection requirement for each type of ML model.

[0178] Example 6 includes the apparatus described in Example 4 or any other example herein, wherein the FL client selection requirement includes a minimum amount of data samples available to the FL client or a minimum training performance score for the FL client running the ML model.

[0179] Example 7 includes the apparatus described in Example 1 or any other example herein, wherein the processor circuitry is further configured to: generate a third MOI representing an ML training report, wherein the third MOI includes a third attribute indicating the FL result; and provide the third MOI to the service consumer via the interface circuitry to inform of the FL result.

[0180] Example 8 includes the apparatus described in Example 7 or any other example herein, wherein the FL results include performance scores of the participating FL clients and the respective FL clients running the final global ML model.

[0181] Example 9 includes the apparatus described in Example 7 or any other example herein, wherein the third MOI includes a fourth attribute modelPerformanceTraining, a fifth attribute modelPerformanceValidation, and a sixth attribute dataRatioTrainingAndValidation related to the performance values ​​of the FL server running the final global ML model.

[0182] Example 10 includes the apparatus described in any one of Examples 1 to 9 or any other example herein, wherein the service consumer includes a management service consumer.

[0183] Example 11 includes the apparatus described in any one of Examples 1 to 9 or any other example herein, wherein the apparatus is suitable for a service producer.

[0184] Example 12 includes the apparatus described in Example 11 or any other example herein, wherein the service producer includes a management service producer.

[0185] Example 13 includes the apparatus described in Example 11 or any other example herein, wherein the service producer is located in an ML training function or in a management function that manages the ML training function.

[0186] Example 14 includes an apparatus comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: receive, via the interface circuit, a first managed object instance (MOI) representing a machine learning (ML) training function from a service producer, wherein the first MOI includes a first attribute indicating that the federated learning (FL) role undertaken by the ML training function is an FL server or an FL client; and manage FL training based on the first MOI.

[0187] Example 15 includes the apparatus described in Example 14 or any other example herein, wherein the processor circuitry is further configured to: generate a second MOI representing characteristics of FL, wherein the second MOI includes a second attribute indicating FL client selection requirements; and provide information of the second MOI to the service producer for selecting an FL client based on the FL client selection requirements.

[0188] Example 16 includes the apparatus described in Example 15 or any other example herein, wherein the FL client selection requirement includes a minimum amount of data samples available to the FL client or a minimum training performance score for the FL client running the ML model.

[0189] Example 17 includes the apparatus described in Example 14 or any other example herein, wherein the processor circuitry is further configured to: receive a third MOI representing an ML training report from the service producer via the interface circuitry, wherein the third MOI includes a third attribute indicating the FL result; and manage the FL training based on the FL result.

[0190] Example 18 includes the apparatus described in Example 17 or any other example herein, wherein the FL results include performance scores of the participating FL clients and the respective FL clients running the final global ML model.

[0191] Example 19 includes the apparatus described in Example 17 or any other example herein, wherein the third MOI includes a fourth attribute modelPerformanceTraining, a fifth attribute modelPerformanceValidation, and a sixth attribute dataRatioTrainingAndValidation related to the performance values ​​of the FL server running the final global ML model.

[0192] Example 20 includes the apparatus described in any of Examples 14 to 19 or any other example herein, wherein the apparatus is suitable for serving consumers.

[0193] Example 21 includes a method comprising: generating a first managed object instance (MOI) representing a machine learning (ML) training function, wherein the first MOI includes a first attribute indicating the FL role assumed by the ML training function in federated learning (FL) training; and providing the first MOI to a service consumer to inform the ML training function of the FL role assumed in FL training.

[0194] Example 22 includes the methods described in Example 21 or any other example herein, wherein the FL role includes an FL server or an FL client.

[0195] Example 23 includes the method described in Example 21 or any other example in this document, wherein the first attribute indicates an FL role for each type of ML model.

[0196] Example 24 includes the method described in Example 21 or any other example herein, further comprising: receiving information from the service consumer about a second MOI, the second MOI representing a characteristic of FL, wherein the second MOI includes a second attribute indicating an FL client selection requirement; and selecting an FL client based on the FL client selection requirement.

[0197] Example 25 includes the method described in Example 24 or any other example in this document, wherein the second attribute indicates the FL client selection requirement for each type of ML model.

[0198] Example 26 includes the method described in Example 24 or any other example herein, wherein the FL client selection requirement includes a minimum amount of data samples available to the FL client or a minimum training performance score for the FL client running the ML model.

[0199] Example 27 includes the method described in Example 21 or any other example herein, further comprising: generating a third MOI representing an ML training report, wherein the third MOI includes a third attribute indicating the FL result; and providing the third MOI to the service consumer to inform of the FL result.

[0200] Example 28 includes the method described in Example 27 or any other example in this document, wherein the FL results include performance scores of the participating FL clients and the corresponding FL clients running the final global ML model.

[0201] Example 29 includes the method described in Example 27 or any other example herein, wherein the third MOI includes a fourth property modelPerformanceTraining, a fifth property modelPerformanceValidation, and a sixth property dataRatioTrainingAndValidation related to the performance values ​​of the FL server running the final global ML model.

[0202] Example 30 includes the method described in any of Examples 21 to 29 or any other example herein, wherein the service consumer includes a management service consumer.

[0203] Example 31 includes the method described in any of Examples 21 to 29 or any other example herein, wherein the method is applicable to service producers.

[0204] Example 32 includes the method described in Example 31 or any other example herein, wherein the service producer includes a management service producer.

[0205] Example 33 includes the method described in Example 31 or any other example herein, wherein the service producer is located in an ML training function or in a management function that manages the ML training function.

[0206] Example 34 includes a method comprising: receiving from a service producer a first managed object instance (MOI) representing a machine learning (ML) training function, wherein the first MOI includes a first attribute indicating that the federated learning (FL) role undertaken by the ML training function is an FL server or an FL client; and managing FL training based on the first MOI.

[0207] Example 35, which includes the method described in Example 34 or any other example herein, further includes: generating a second MOI representing characteristics of FL, wherein the second MOI includes a second attribute indicating FL client selection requirements; and providing information of the second MOI to the service producer for selecting an FL client based on the FL client selection requirements.

[0208] Example 36 includes the method described in Example 35 or any other example herein, wherein the FL client selection requirement includes a minimum amount of data samples available to the FL client or a minimum training performance score for the FL client running the ML model.

[0209] Example 37 includes the method described in Example 34 or any other example herein, further comprising: receiving a third MOI representing an ML training report from the service producer, wherein the third MOI includes a third attribute indicating the FL result; and managing the FL training based on the FL result.

[0210] Example 38 includes the method described in Example 37 or any other example in this document, wherein the FL results include performance scores of the participating FL clients and the respective FL clients running the final global ML model.

[0211] Example 39 includes the method described in Example 37 or any other example herein, wherein the third MOI includes a fourth property modelPerformanceTraining, a fifth property modelPerformanceValidation, and a sixth property dataRatioTrainingAndValidation related to the performance values ​​of the FL server running the final global ML model.

[0212] Example 40 includes the method described in any of Examples 34 to 39 or any other example herein, wherein the method is applicable to service consumers.

[0213] Example 41 includes an apparatus comprising components for performing the method of any one of Examples 21 to 33.

[0214] Example 42 includes an apparatus comprising components for performing the method of any one of Examples 34 to 40.

[0215] Example 43 includes a computer-readable medium storing instructions that, when executed by processing circuitry, cause the processing circuitry to perform the method of any one of Examples 21 to 33.

[0216] Example 44 includes a computer-readable medium storing instructions that, when executed by processing circuitry, cause the processing circuitry to perform the method of any one of Examples 34 to 40.

[0217] While some embodiments have been illustrated and described herein for purposes of description, various alternative and / or equivalent embodiments or implementations devised to achieve the same purpose may replace the illustrated and described embodiments without departing from the scope of this disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is readily understood that the embodiments described herein are limited only by the appended claims and their equivalents.

Claims

1. An apparatus comprising: Interface circuit; as well as The processor circuit is coupled to the interface circuit. The processor circuit is used for: Generate a first managed object instance (MOI) representing a machine learning (ML) training function, wherein the first MOI includes a first attribute indicating the FL role assumed by the ML training function in federated learning (FL) training; and The first MOI is provided to the service consumer via the interface circuit to inform the ML training function of its FL role in FL training.

2. The apparatus according to claim 1, wherein, The FL role includes either an FL server or an FL client.

3. The apparatus according to claim 1, wherein, The first attribute indicates the FL role for each type of ML model.

4. The apparatus according to claim 1, wherein, The processor circuit is also used for: The interface circuit receives information about a second MOI from the service consumer, the second MOI representing characteristics of the FL, wherein the second MOI includes a second attribute indicating the FL client's selection requirements; and The FL client is selected based on the aforementioned FL client selection requirements.

5. The apparatus according to claim 4, wherein, The second attribute indicates the FL client's selection requirements for each type of ML model.

6. The apparatus according to claim 4, wherein, The FL client selection requirements include the minimum amount of data samples available to the FL client or the minimum training performance score of the FL client running the ML model.

7. The apparatus according to claim 1, wherein, The processor circuit is also used for: Generate a third MOI representing the ML training report, wherein the third MOI includes a third attribute indicating the FL result; and The third MOI is provided to the service consumer via the interface circuit to inform the FL result.

8. The apparatus according to claim 7, wherein, The FL results include the performance scores of the participating FL clients and the corresponding FL clients running the final global ML model.

9. The apparatus according to claim 7, wherein, The third MOI includes a fourth attribute, modelPerformanceTraining, a fifth attribute, modelPerformanceValidation, or a sixth attribute, dataRatioTrainingAndValidation, which are related to the performance values ​​of the FL server running the final global ML model.

10. The apparatus according to any one of claims 1 to 9, wherein, The service consumers include management service consumers.

11. The apparatus according to any one of claims 1 to 9, wherein, The device is suitable for service producers.

12. The apparatus according to claim 11, wherein, The service producers include management service producers.

13. The apparatus according to claim 11, wherein, The service producer is located in the ML training function or in the management function that manages the ML training function.

14. An apparatus comprising: Interface circuit; as well as The processor circuit is coupled to the interface circuit. The processor circuit is used for: The interface circuit receives a first managed object instance (MOI) representing a machine learning (ML) training function from a service producer, wherein the first MOI includes a first attribute indicating whether the federated learning (FL) role undertaken by the ML training function is an FL server or an FL client; and FL training is managed based on the first MOI.

15. The apparatus according to claim 14, wherein, The processor circuit is also used for: Generate a second MOI representing the characteristics of FL, wherein the second MOI includes a second attribute indicating the FL client's selection requirements; and The service producer is provided with information about the second MOI for selecting an FL client based on the FL client selection requirements.

16. The apparatus according to claim 15, wherein, The FL client selection requirements include the minimum amount of data samples available to the FL client or the minimum training performance score of the FL client running the ML model.

17. The apparatus according to claim 14, wherein, The processor circuit is also used for: Receive a third MOI representing an ML training report from the service producer via the interface circuitry, wherein the third MOI includes a third attribute indicating the FL result; and The FL training is managed based on the FL results.

18. The apparatus according to claim 17, wherein, The FL results include the performance scores of the participating FL clients and the corresponding FL clients running the final global ML model.

19. The apparatus according to claim 17, wherein, The third MOI includes a fourth attribute, modelPerformanceTraining, a fifth attribute, modelPerformanceValidation, or a sixth attribute, dataRatioTrainingAndValidation, which are related to the performance values ​​of the FL server running the final global ML model.

20. The apparatus according to any one of claims 14 to 19, wherein, The device is suitable for serving consumers.

Images