Support for longitudinal federated learning
By introducing a vertical federated learning architecture and utilizing SA6 functionality to manage FL clients across different domains, the problem of data and feature alignment in vertical federated learning is solved, improving the training and analysis efficiency of machine learning models and meeting the needs of vertical industries and application services.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- LENOVO (SINGAPORE) PTE LTD
- Filing Date
- 2023-10-20
- Publication Date
- 2026-04-28
AI Technical Summary
Existing technologies struggle to effectively support entity registration, discovery, and notification processing in vertical federated learning, particularly due to the complexity of data and feature alignment across different domains, which impacts the training and analysis efficiency of machine learning models.
By introducing a vertical federated learning architecture, SA6 features (such as ADAES and AI enablers) are used to manage and coordinate FL clients across different domains. Candidate clients are discovered through network repository features and registry, enabling the alignment of datasets and features, and the training and aggregation of models.
It achieves data and feature alignment between different domains, supports cross-domain vertical federated learning, improves the training efficiency and analysis accuracy of machine learning models, and meets the needs of vertical industries and application services.
Smart Images

Figure CN121941998A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to wireless communications, and more specifically, to network architectures and methods that support longitudinal federated learning. Background Technology
[0002] A wireless communication system may include one or more network communication devices, such as base stations, that support wireless communication for one or more user communication devices, which may also be referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers, etc.)). Furthermore, the wireless communication system can support wireless communication across a variety of radio access technologies, including third-generation (3G), fourth-generation (4G), fifth-generation (5G), and other suitable radio access technologies above 5G (e.g., sixth-generation (6G)). Summary of the Invention
[0003] The article “a” preceding an element is unrestricted and should be understood to refer to “at least one” or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. As used herein, the word “or,” as used in a list of items (e.g., a list of items beginning with phrases such as “at least one,” “one or more,” or “one or two”) indicates an inclusive list, such that a list of at least one of, for example, A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase “based on” should not be construed as referring to a closed set of conditions. For example, without departing from the scope of this disclosure, an example step described as “based on condition A” may be based on both condition A and condition B. In other words, as used herein, the phrase “based on” should be interpreted in the same manner as the phrase “at least partially based on.” Furthermore, as used herein, the word “group” may comprise one or more elements.
[0004] Some embodiments of the methods and apparatus described herein may include a network entity of a wireless communication system, the network entity comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the network entity: receives from a consumer entity an application-layer request for a machine learning-enabled application service, wherein the application-layer request includes a machine learning model identifier and / or an analytics event identifier; and determines, based on the application-layer request, a first requirement for providing longitudinal federated learning training for the machine learning-enabled application service. Based on the first requirement, a second requirement is determined, wherein the second requirement includes a dataset requirement for the machine learning-enabled service.
[0005] The processor can be configured to enable the network entity to discover multiple entities that can act as candidate federated learning clients based on the first and / or second requirements, wherein the discovery includes the ability to obtain the multiple entities.
[0006] The processor can be configured to allow the network entity to configure at least one alignment parameter based on the second requirement and the capabilities of the discovered entity to act as a candidate federated learning client.
[0007] The processor can be configured to allow the network entity to select at least one entity from the plurality of candidate federated learning clients to act as the federated learning client for the machine learning enabled application service.
[0008] The processor can be configured to cause the network entity to transmit the at least one alignment parameter to the entity or each entity acting as a federated learning client.
[0009] The dataset may include one or more of the following:
[0010] A set of identifiers corresponding to events or analysis events related to machine learning models;
[0011] Sample range requirements, such as identifying multiple data sources, such as UE, geographical range, and / or time range; and
[0012] Identifier of one or more statistical data.
[0013] The network entity can be configured to function as an application data analytics enabler server (ADAES) or other artificial intelligence enabler in the application layer of the wireless communication system.
[0014] The consumer entity can be an entity of the vertical application layer (VAL) or an entity of the wireless core network.
[0015] The processor may be configured to identify at least one entity that acts as a candidate federated learning client by performing a federated learning client discovery procedure using network repository functionality or other registry entries.
[0016] The processor and / or one or more other processors may be configured to receive federated learning training responses from the or each federated learning client and perform global model aggregation to obtain machine learning model parameters consistent with the request. The or each processor may be configured to:
[0017] Send the obtained machine learning model parameters to the consumer entity; or
[0018] The obtained machine learning model parameters are used to obtain analytical data, and the obtained analytical data is sent to the consumer entity.
[0019] The federated machine learning client may be located in one or more of the following:
[0020] The application enabler layer of the wireless communication system;
[0021] Core network;
[0022] Edge data networks; regional data networks; user equipment; vertical applications; enterprise networks; and
[0023] External cloud.
[0024] Dataset requirements can be used to facilitate consistent data collection across the client(s) or each candidate federated learning client. The dataset requirement may be a data sample requirement. The dataset requirement may be a feature selection requirement. The data sample requirement may include information about the data required to train the first model. The data sample requirement may include an indication of the data to be collected to train the first model. The data sample requirement may include statistics corresponding to the data to be collected to train the first model. The data sample requirement may include features corresponding to the data to be collected to train the first model. The data sample requirement may include one or more sample range requirements. The one or more sample range requirements may be identified by one or more of the following: one or more user equipment identifiers; one or more location regions; one or more time ranges. The one or more user equipment identifiers may include one or more of the following: Subscription Permanent Identifier (SUPI), Global Public Subscriber Identity (GPSI), or User Application Identifier. The data sample requirement may include one or more event identifiers.
[0025] Some embodiments of the methods and apparatus described herein may include a method performed by a network entity of a wireless communication system. The method includes: receiving from a consumer entity an application-layer request for a machine learning-enabled application service, wherein the application-layer request includes a machine learning model identifier and / or an analytics event identifier; and determining, based on the application-layer request, a first requirement for providing longitudinal federated learning training for the machine learning-enabled application service. The method further includes determining a second requirement based on the first requirement, wherein the second requirement includes a dataset and / or feature selection requirement for the machine learning-enabled service.
[0026] The method may include discovering a plurality of entities that can act as candidate federated learning clients based on the first and / or second requirements, wherein the discovery includes the ability to obtain the plurality of said entities.
[0027] The method may include selecting at least one entity from the plurality of candidate federated learning clients to act as the federated learning client for the machine learning enabled application service.
[0028] The method may include receiving a federated learning training response from the or each federated learning client and performing global model aggregation to obtain machine learning model parameters consistent with the request.
[0029] The method may include sending the obtained machine learning model parameters to the consumer entity or using the obtained machine learning model parameters to obtain analytical data and sending the obtained analytical data to the consumer entity. Attached Figure Description
[0030] Figure 1 This describes the current architecture and methods used to export and provide analytics to the consumer NF.
[0031] Figure 2 This describes the NWDAF architecture used for analysis generated based on the trained model.
[0032] Figure 3A Explain the horizontal federated learning architecture.
[0033] Figure 3B Explain the vertical federated learning architecture.
[0034] Figure 4 This describes the affected entities for vertical federated learning and data alignment between ADAES and the 5G core network according to the embodiment.
[0035] Figure 5 This describes the procedure for cross-domain vertical federated learning according to an embodiment.
[0036] Figure 6This describes the procedure for application-layer vertical federated learning according to an embodiment.
[0037] Figure 7 This describes the procedure for cross-domain vertical federated learning according to an embodiment.
[0038] Figure 8 Examples of wireless communication systems according to aspects of this disclosure are described.
[0039] Figure 9 An example of a network equipment (NE) 200 according to aspects of this disclosure is described.
[0040] Figure 10 A flowchart illustrating the method performed by NE according to aspects of this disclosure. Detailed Implementation
[0041] The 3rd Generation Partnership Project (3GPP) is a collective term for multiple standards organizations that develop protocols for mobile communication technologies, encompassing radio access, core network, and service capabilities, providing a complete system description of mobile communications. 3GPP TSG SA WG6 (SA6) is an application enablement and critical communications application group for vertical markets. SA6's primary goal is to provide application-layer architecture specifications for vertical industries, including architectural requirements and functional architectures to support integration between vertical industries and 3GPP systems. In this context, SA6 functions act as middleware, providing a Platform as a Service (PaaS) capability toolkit to simplify interaction between application providers and the network layer, while also providing application-layer support.
[0042] Specifically, 3GPP SA6 provides the following key enablers:
[0043] The Common API Framework [TS 23.222] provides a unified and coordinated API framework across several 3GPP API specifications. Some key features include: API caller login, service API publication and discovery, and API security.
[0044] The Service Enabler Architecture Layer (SEAL) [TS 23.434] is a middleware layer with core capabilities required by multiple industry vertical applications, including group management, configuration management, location management, key management, network resource management, slice enablement, analytics enablement, and data delivery.
[0045] The application architecture for edge applications [TS 23.558] enables applications to be hosted at the edge of 3GPP networks. Some of the key requirements considered are: minimal impact on the use of applications on the UE at the edge, service differentiation (enabling / disabling edge computing capabilities), flexible deployment, and service continuity.
[0046] Network Data Analytics Function (NWDAF) is a 5G 3GPP standard approach for collecting data from 5G core (5GC), cloud, and edge networks, including user equipment (UE), network functions (NF), and operations, management, and maintenance (OAM) systems, for analysis purposes. NWDAF is positioned within the 5G core network domain. NWDAF provides data analytics that allows communication service providers to improve customer experience, increase network efficiency, and generate new revenue streams. Through open APIs, NWDAF can also be exposed to external users, such as streaming services and financial institutions including banks.
[0047] Typically, NWDAF utilizes one or more machine learning (ML) models, whose construction is an iterative process. ML models can be identified by their IDs and can be provided by network or operator, telecom provider, edge provider, or application provider, and can be applied to mobile devices in 5G systems, such as for image recognition, localization, execution, speech recognition, and video processing, as well as for optimizing the performance of network components / communications. ML models can be trained, for example, to derive UE localization patterns for a given time and region, the performance of a given cell / network access, or the load on a UE or network entity. ML models on the network side are stored using ML model IDs at the network function that acts as the ML model repository. For external ML models, no information is provided on how the IDs are configured or where the ML models are stored.
[0048] In the current 3GPP architecture (as of version 18), NWDAF provides analytics output to one or more analytics consumer NFs based on data collected from one or more data producer NFs, such as... Figure 1 The analysis shows that consumers subscribe to NWDAF to receive analytics data from them.
[0049] In version 17, NWDAF was split into the Analysis Logic Function (AnLF) and the Model Training Function (MTLF), such as Figure 2 The diagram illustrates this. AnLF is responsible for receiving analytics requests from consumers and returning responses. MTLF is responsible for training the ML model based on data received from the data producer NF (or DCCF). According to this architecture, a single AnLF can act as an "aggregator," computing an aggregated model (where the model can be defined by a set of model parameters) from model data received from multiple MTLFs. The model aggregator provides updated model parameters to each MTLF, and each MTLF uses these parameters to retrain its own model, thus allowing each local model training function to obtain a trained model using data from multiple sources.
[0050] This type of shared ML model training is called "Federated Learning" or FL. Version 18 defines two types of federated learning: lateral and longitudinal federated learning. Lateral federated learning (HFL), or sample-based federated learning, is introduced where datasets share the same feature space but have different samples. This is in... Figure 3A This is illustrated in the text, and may occur in situations where different MTLFs create models for the same feature set but for different groups of users (e.g., UE). Longitudinal Federated Learning (VFL) is... Figure 3B This is explained in the text, and it may occur when different UEs are creating models based on different feature sets for the same or different groups of users.
[0051] Two types of VFLs, namely non-split and split VFLs, are available. In a non-split VFL, each participant owns the complete model, while in a split VFL, each participant owns a portion of the model. Depending on whether a non-split or split VFL is used, there are different approaches to training the model with a VFL. In a non-split VFL, the VFL is supported by using a coordinator VFL (where each party exchanges intermediate results and computes gradients of the model, which are sent to the coordinator, and the coordinator updates each model) and scenarios where no coordinator is used and each party autonomously trains its model based on exchanging intermediate results and gradients. In a split VFL, the model is split among multiple parties. One party owns the top model (the global model), and the other parties own one or more bottom models (which are used to train the top model). The most likely scenario for supporting VFLs within a 5G system is the non-split VFL.
[0052] Examples of how model aggregators can generate aggregated models for two types of federated learning are presented below:
[0053] 1. Concepts and Applications, ACM Intelligent Systems and Technologies Conference (TIST), Vol. 10, No. 2, Article 12, January 2019; and
[0054] 2. Enabler for 5GPPP, AI and ML-5G and above networks.
[0055] 3GPP SA6 has also specified an application layer architecture in 3GPP TS 23.436 to enable data analytics as a new Service Enabler Architecture Layer (SEAL) service, also known as Application Data Analytics Enabled Service (ADAES). This architecture provides an application layer analytics framework that offers common analytics exposure and value-added services to vertical industries and application service providers (ASPs). It also includes application layer analytics related to end-to-end application performance, edge load, service API availability, location accuracy, and slice-related performance and fault analysis. In Release 19, enhancements to the ADAES functional architecture are expected to be studied to further improve and enhance functionality within 3GPP, and specifically, to improve support for analytics using AI / ML methodologies.
[0056] The analysis event corresponds to the ADAE layer analysis event specified in 3GPP TS 23.436. In some embodiments, this event may be provided as an analysis event / ID for NWDAF, as specified in 3GPP TS 23.288.
[0057] A current open question is how best to support the registration, discovery, and notification processing / subscription of entities (FL clients, FL servers, FL server / aggregators, data collection coordinators) expected to act as FL members in the AI / ML model pipeline. Here, the AI / ML model pipeline is considered a method for standardizing and automating the workflow used to generate machine learning models. An AI / ML learning pipeline can consist of multiple sequential steps that perform all operations from data extraction and preprocessing to model training and deployment.
[0058] AI / ML pipelines consist of building blocks that can be distributed across different entities in the application layer and the 5G network, such as ML model training, inference, data preparation, and collection. In the case of FL (Flexible Interpreter), the ML model pipeline comprises multiple entities that perform parallel operations on some of these blocks (e.g., training, inference). This introduces additional complexity in allowing different entities to be registered and discovered as FL members, as it includes entities from different domains and potentially from different stakeholders.
[0059] Currently, research is underway to develop solutions supporting longitudinal federated learning for version 19, enabling 5G systems (5GS) to assist collaborative AI / ML operations involving the ADAE layer and potentially the core network and AF. A typical use case is a scenario where a third-party application provider wants to combine data available from its application with data available from network operators and edge / cloud providers to train an ML model. Further considering this example, a third-party application / service provider (e.g., a banking application) might need a model that maps user purchasing behavior to user mobility trends. Users can be identified by application ID or through a 3GPP subscription. However, the data (features) available for the same user will differ across the third-party and operator networks because the third party will have the user's transaction details, while the core network will have the same user's network information, such as mobility / location information. Longitudinal federated learning can support model training when different domains, for example, have the same sample data for the same user but different feature spaces.
[0060] The following issues will be further considered to support cross-domain vertical federated learning:
[0061] • How can the enabler / AF ensure that cross-domain FL clients (which can be on the server and UE side) have aligned their sample ranges, such as the same users, to support longitudinal federated learning (data alignment between NWDAF and AF)?
[0062] • How can the enabler / AF discover what features are available in different domains (for the same sample range) to support longitudinal federated learning (feature alignment between ADAES, vertical application layer (VAL), and 5GC)?
[0063] In the context of this discussion, an ML-enabled application service can be an application-layer analytics service (e.g., VAL performance analysis) as defined in the ADAES specification, which is expected to use ML technologies to derive analytics output. In some embodiments, such an ML-enabled analytics service can also be a service provided by an AI / ML application (e.g., a VAL server), such as an automation service in a vertical / ASP setting, or an application service using ML technologies (e.g., a gaming service, an XR service), which requires assistance from a network entity to act as an FL client.
[0064] Example 1 SA6 features (ADAES, AI enabler) perform alignment and trigger 5GC to act as an FL client.
[0065] Figure 4The architecture used to support Vertical FL (Vertical FL) is described. This architecture includes a related analytics entity (NWDAFMTLF) within the 5G core, an NRF (Non-Wide-Data-Data-Initialization), a data production entity, and an enabler layer (specifically, a SEAL ADAE layer or AI enabler) located on the 5G core as AF. In this embodiment, the VFL process is initiated from an SA6 function (which may be ADAES or another AI enabler). Initiation is triggered by a VAL server for ADAE layer analysis (e.g., the VAL server may be external to the 5G system, such as a bank server). However, it is also possible for this to be triggered by the VAL server (to ADAES or another AI enabler) for training the ML model. Specifically, the VFL process involves, as... Figure 5 The following steps are described in the text:
[0066] 1. The VAL server sends a subscription analytics or subscription request from a 3GPP system (including the enabler layer / AF) to the ADAES (or an equivalent enabler server, such as an AI enabler) to request assistance in training an ML model. The request includes the analytics and / or ML model ID.
[0067] 2. ADAES agrees to support FL for the specified model and identifies dataset requirements based on VAL server requests. ADAES may also determine at least some (if known) of the FL clients to be used at both 5GC and the enabling layer (ADAEC, edge ADAES).
[0068] 3. ADAES instantiates the FL server capability (if it has not already been instantiated) and discovers (potentially additional) entities that can be used to act as FL clients from both 5GC and the enabling layer. This can be done via the 5GC FL client's Network Repository Function (NRF) and other registries of external FL clients (e.g., CAPIF core functionality).
[0069] 4. The ADAES FL server determines which candidate FL clients can be part of the FL process based on the service area and time interval used to support FL and dataset requirements and characteristics.
[0070] 5. The ADAES FL server sends a FL preparation request to each of the candidate FL clients both within and outside the 5GC.
[0071] 6. Candidate FL clients check the model ID, analysis ID (or equivalent), model interoperability and data availability, and timeline, and confirm or reject their participation.
[0072] 7. The candidate FL client (who confirms participation) sends an FL ready response to the ADAES FL server, with a positive confirmation and a statistical description of the available dataset and supported features.
[0073] 8. The ADAES FL server starts the FL process.
[0074] 9. The ADAES FL server sends ML model training requests to all selected FL clients.
[0075] 10. The FL client may optionally perform data collection and train the ML model locally, and then provide the output to the FL server, for example, as a set of model parameters.
[0076] 11. The ADAES FL server performs aggregation of locally trained ML models, and optionally, if the task provides FL-enabled analytics at ADAES, then the analytics are derived based on the aggregated trained models.
[0077] 12. The ADAES FL server sends a response to the VAL server, providing the aggregated ML-trained model or analytics output (in the case of analytics at ADAES).
[0078] Example 2 SA6 features (ADAES, AI enabler) trigger other applications (edge, cloud, UE) to act as FL clients.
[0079] In this embodiment, the VFL process is initiated from an SA6 function (which can be ADAES or another AI enabler), and the FL operation only involves entities on the application side (edge / cloud platform or AI application on the UE side). This is triggered by the VAL server for ADAE layer analysis. However, it is also possible for this to be triggered by the VAL server (to ADAES or another AI enabler) for training the ML model. One of the new features for SA6 (enabler / AF) in this embodiment is how the AF determines its available sample range for the FL process.
[0080] The embodiments have as follows Figure 6 The following advanced steps are described in the text:
[0081] 1. The VAL server sends a subscription analytics or subscription request from a 3GPP system (including the enabler layer / AF) to ADAES (or an equivalent enabler server, such as an AI enabler) for help in training an ML model. The request includes the analytics and / or ML model ID.
[0082] 2. ADAES identifies the FL that supports the identifiable model and identifies the dataset requirements based on VAL server requests. ADAES can also identify the FL client to be used at the enable tier (SEAL, EEL) or VAL tier / EAS (if known).
[0083] 3. ADAES instantiates the FL server capability (if it has not yet been instantiated) and discovers entities that can act as FL clients from the enablement layer and / or VAL layer / EAS or external systems (e.g., MEC services, O-RAN RIC). This can be done via NRF (if supported in 5GC) or other registries, such as the CAPIF core functionality or other service registry for external FL clients (where "external" here means outside the PLMN trusted domain).
[0084] 4. ADAES determines which candidate FL clients can be part of the FL process based on the service area and time interval used to support FL and dataset requirements and characteristics.
[0085] 5. ADAES sends FL preparation requests to each of the candidate FL clients located at both the AF / Enablement Layer and externally (e.g., a third-party server, EAS / VAL), as well as the FL client on the UE side. The format of these requests and the parameters they contain may vary depending on the interface and type of the FL client. For example:
[0086] ○ For FL clients at the enabler layer, VAL layer, or edge: FL preparation requests may include ML model information, dataset requirements, feature requirements or feature selection methods (supervised, semi-supervised, embedded), FL operation configuration and reporting to the FL server, validity period and service area, and possible tools / libraries to assume new capabilities as FL clients.
[0087] ○ For the FL client on the VAL / UE side: The FL preparation request may additionally include a status report request to capture possible changes in the availability / capability and conditions of the corresponding VAL / UE, as well as an indication of anticipated unavailability or communication restrictions, and optionally performance measurement / statistics and mobility information.
[0088] 6. Candidate FL clients check the model ID and / or analysis ID (or equivalent), model interoperability and data availability, timeline, and confirm or reject their participation.
[0089] 7. Confirmed candidate FL clients send an FL ready response to ADAES, which includes a positive confirmation and a statistical description of the available dataset and supported features.
[0090] 8. ADAES initiates the FL process.
[0091] 9. ADAES sends ML model training requests to all selected FL clients.
[0092] 10. The FL client can optionally perform data collection and train the ML model locally, and then provide the output to ADAES.
[0093] 11. ADAES performs aggregation of locally trained ML models, and optionally, if the task provides FL-enabled analysis at ADAES, it also derives analysis based on the aggregated trained model.
[0094] 12. ADAES sends a response to the VAL server, providing the aggregated ML-trained model or analytics output (in the case of analytics at ADAES).
[0095] Example 3 :5GC triggers the ADAES / SA6 function to act as an FL client.
[0096] In this embodiment, the VFL process is initiated from 5GC to ADAES and also includes a VAL layer FL client (e.g., an external and untrusted AF). This embodiment is used when 5GC requires an external entity to perform FL client operations, but such FL clients are not yet registered with the NRF and there is no direct agreement between the mobile network operator (MNO) and the third-party FL client. This scenario is, for example, when ADAES / Enabler / AF is provided as a PaaS at an edge platform provider (e.g., Lenovo) and the third-party FL client resides in a vertical or enterprise / IT domain (e.g., AWS). In this case, the edge platform provider has a communication agreement with the MNO and a service agreement with the vertical / enterprise application provider. The embodiment has as follows Figure 7 The following advanced steps are described in the text:
[0097] 0. 5GC triggers FL preparation, which includes identifying the FL client as outside the core network entity (AF / ADAES). 5GC discovers ADAES (assuming ADAES is registered with the NRF as an FL client AF).
[0098] 1. The Network Exposure Function (NEF) sends an ML model training request to ADAES: This may also include permission to delegate some ML model training to other application entities (who have agreements with the ADAES provider, such as an edge provider). This request includes dataset requirements and feature requirements / feature selection methods to be used.
[0099] 2. Due to various reasons, such as energy or load constraints or data limitations / unavailability, ADAES determines to delegate / offload some training to external applications. It then identifies VAL server entities that can act as candidate FL clients for a given ML model. This can be done via CAPIF or other service registries at the edge platform.
[0100] 3. ADAES sends an ML model training request, including dataset requirements, to the discovered VAL server that acts as an FL client.
[0101] 4. After the VAL server confirms and retrieves the ML model (e.g., from an external ML model repository or from ADRF), it sends a response to ADAES containing the trained ML model.
[0102] 5. ADAES can perform local ML model aggregation for multiple FL clients in a third-party domain. Based on step 2, local training within ADAES itself is also possible.
[0103] 6. ADAES sends the ML model training response to NWDAF via NEF, which includes the trained ML model that can also be aggregated locally.
[0104] The aspects of this disclosure are described in the context of a wireless communication system that includes a core network (e.g., 5DC or equivalent).
[0105] Figure 8 This section describes an example of a wireless communication system 100 according to aspects of this disclosure. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various radio access technologies. In some embodiments, the wireless communication system 100 may be a 4G network, such as an LTE network or an LTE-A network. In some other embodiments, the wireless communication system 100 may be an NR network, such as a 5G network, a 5G-A network, or a 5G Ultra Wideband (5G-UWB) network. In other embodiments, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable radio access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support radio access technologies other than 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), or Code Division Multiple Access (CDMA).
[0106] One or more NEs 102 may be distributed across a geographical area to form a wireless communication system 100. One or more of the NEs 102 described herein may be, include, or be referred to as a network node, base station, network element, network function, network entity, radio access network (RAN), NodeB, eNodeB (eNB), next-generation NodeB (gNB), or other suitable terms. NEs 102 and UEs 104 may communicate via a communication link, which may be a wireless or wired connection. For example, NEs 102 and UEs 104 may perform wireless communication (e.g., receive signaling, transmit signaling) via a Uu interface.
[0107] NE 102 can provide a geographic coverage area that supports services for one or more UEs 104 within that geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals associated with services (e.g., voice, video, packet data, messaging, broadcasting, etc.) based on one or more radio access technologies. In some embodiments, NE 102 can be mobile, for example, a satellite associated with a non-terrestrial network (NTN). In some embodiments, different geographic coverage areas 112 associated with the same or different radio access technologies can overlap, but different geographic coverage areas can be associated with different NEs 102.
[0108] One or more UEs 104 may be distributed across a geographical area of the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some implementations, UE 104 may be referred to as a unit, station, terminal, or client, and other instances thereof. Additionally or alternatively, UE 104 may be referred to as an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a Machine Type Communication (MTC) device, and other instances thereof.
[0109] UE 104 may be able to support direct wireless communication with other UE 104 via a communication link. For example, UE 104 may support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, communication link 114 may be referred to as a side link. For example, UE 104 may support direct wireless communication with another UE 104 via a PC5 interface.
[0110] NE 102 may support communication with CN 106 or with another NE 102 or both. For example, NE 102 may interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N2, or network interfaces). In some embodiments, NE 102 may communicate directly with each other. In some other embodiments, NE 102 may communicate with each other or indirectly (e.g., via CN 106). In some embodiments, one or more NE 102 may include sub-components, such as access network entities, which may be instances of access node controllers (ANCs). The ANC may communicate with one or more UE 104s via one or more other access network transmitting entities (which may be referred to as radio heads, smart radio heads, or transmit-receive points (TRPs)).
[0111] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities that manage access and mobility (e.g., a mobility management entity (MME), access and mobility management functions (AMF)) and user plane entities that route or interconnect packets to external networks (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entities may manage non-access stratum (NAS) functions of one or more UEs 104 served by one or more NEs 102 associated with CN 106, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.).
[0112] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N2, or another network interface). The packet data network may contain an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session (e.g., a Protocol Data Unit (PDU) session, etc.) with CN 106 via NE 102. CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, etc.) between UE 104 and the application server. A PDU session may be an instance of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).
[0113] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some embodiments, NE 102 and UE 104 may support different resource structures. For example, NE 102 and UE 104 may support different frame structures. In some embodiments, such as in 4G, NE 102 and UE 104 may support a single frame structure. In some other embodiments, such as in 5G and other suitable radio access technologies, NE 102 and UE 104 may support various frame structures (i.e., multiple frame structures). NE 102 and UE 104 may support various frame structures based on one or more parameter sets.
[0114] The wireless communication system 100 may support one or more parameter sets, and the parameter sets may include subcarrier spacing and cyclic prefixes. A first parameter set (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a regular cyclic prefix. In some embodiments, the first parameter set (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one time slot per subframe. A second parameter set (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a regular cyclic prefix. A third parameter set (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a regular cyclic prefix or an extended cyclic prefix. A fourth parameter set (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a regular cyclic prefix. A fifth parameter set (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a regular cyclic prefix.
[0115] Time intervals for resources (e.g., communication resources) can be organized according to frames (also known as radio frames). Each frame may have a duration, for example, 10 milliseconds (ms). In some embodiments, each frame may contain multiple subframes. For example, each frame may contain 10 subframes, and each subframe may have a duration, for example, 1 ms. In some embodiments, each frame may have the same duration. In some embodiments, each subframe of a frame may have the same duration.
[0116] Alternatively, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may contain a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more parameter sets supported in the wireless communication system 100. For example, the first, second, third, fourth, and fifth parameter sets (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with corresponding subcarrier intervals of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single time slot per subframe, two time slots per subframe, four time slots per subframe, eight time slots per subframe, and 16 time slots per subframe, respectively. Each time slot may contain a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some embodiments, the number (e.g., quantity) of time slots in a subframe may depend on the parameter set. For a conventional cyclic prefix, a time slot may contain 14 symbols. For an extended cyclic prefix (e.g., applicable to a 60 kHz subcarrier spacing), a time slot may contain 12 symbols. The relationship between the number of symbols per time slot for the regular cyclic prefix and the extended cyclic prefix, the number of time slots per subframe, and the number of time slots per frame may depend on the parameter set. It should be understood that references to the first parameter set (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and time slots.
[0117] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 may support one or more operating frequency bands, such as frequency range names FR1 (410 MHz to 7.125 GHz), FR2 (24.25 GHz to 52.6 GHz), FR3 (7.125 GHz to 24.25 GHz), FR4 (52.6 GHz to 114.25 GHz), FR4a or FR4-1 (52.6 GHz to 71 GHz), and FR5 (114.25 GHz to 300 GHz). In some embodiments, NE 102 and UE 104 may perform wireless communication on one or more of the operating frequency bands. In some embodiments, FR1 may be used by NE 102 and UE 104, as well as other equipment or devices, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by NE 102 and UE 104, as well as other equipment or devices, for short-range, high data rate capabilities.
[0118] FR1 may be associated with one or more parameter sets (e.g., at least three parameter sets). For example, FR1 may be associated with a first parameter set containing a 15 kHz subcarrier spacing (e.g., μ=0); a second parameter set containing a 30 kHz subcarrier spacing (e.g., μ=1); and a third parameter set containing a 60 kHz subcarrier spacing (e.g., μ=2). FR2 may be associated with one or more parameter sets (e.g., at least two parameter sets). For example, FR2 may be associated with a third parameter set containing a 60 kHz subcarrier spacing (e.g., μ=2); and a fourth parameter set containing a 120 kHz subcarrier spacing (e.g., μ=3).
[0119] Figure 9 An example of NE 200 according to aspects of this disclosure is described. NE 200 includes a processor 202, a memory 204, a controller 206, and a transceiver 208. The processor 202, memory 204, controller 206, or transceiver 208, or various combinations thereof, or various components thereof, may be examples of components for performing the various aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operatively, communicatively, functionally, electronically, electrically).
[0120] Processor 202, memory 204, controller 206, or transceiver 208, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may be a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured or otherwise supporting components for performing the functions described in this disclosure.
[0121] Processor 202 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some embodiments, processor 202 may be configured to operate memory 204. In some other embodiments, memory 204 may be integrated into processor 202. Processor 202 may be configured to execute computer-readable instructions stored in memory 204 to cause NE 200 to perform various functions of this disclosure.
[0122] Memory 204 may comprise volatile or non-volatile memory. Memory 204 may store computer-readable, computer-executable code containing instructions that, when executed by processor 202, cause NE 200 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 204 or another type of memory. Computer-readable medium includes both non-transitory computer storage media and communication media, wherein the communication media includes any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media may be any available media accessible by a general-purpose or special-purpose computer.
[0123] In some implementations, processor 202 and memory 204 coupled to processor 202 may be configured to cause NE 200 to perform one or more of the functions described herein (e.g., processor 202 executes instructions stored in memory 204). For example, processor 202 may support wireless communication at NE 200 according to examples disclosed herein.
[0124] The NE 200 can be configured to support components for: receiving an application layer request from a consumer entity for a machine learning-enabled application service, wherein the application layer request includes a machine learning model identifier and / or an analytics event identifier; determining a first requirement for providing longitudinal federated learning training for the machine learning-enabled application service based on the application layer request; and determining a second requirement based on the first requirement, wherein the second requirement includes a dataset requirement for the machine learning-enabled service.
[0125] Controller 206 manages the input and output signals of NE 200. Controller 206 can also manage peripheral devices not integrated into NE 200. In some embodiments, controller 206 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some embodiments, controller 206 may be implemented as part of processor 202.
[0126] In some embodiments, NE 200 may include at least one transceiver 208. In other embodiments, NE 200 may have more than one transceiver 208. Transceiver 208 may represent a wireless transceiver. Transceiver 208 may include one or more receiver chains 210, one or more transmitter chains 212, or a combination thereof.
[0127] Receiver chain 210 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, receiver chain 210 may include one or more antennas for receiving signals over the air or over a wireless medium. Receiver chain 210 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 210 may include at least one demodulator configured to demodulate the received signal and obtain transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 210 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.
[0128] Transmitter chain 212 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 212 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 212 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
[0129] Figure 10 A flowchart illustrating a method according to an aspect of this disclosure is provided. The operation of the method can be implemented by an NE as described herein. In some embodiments, the NE can execute a set of instructions to control the functional elements of the NE to perform the described functions.
[0130] At 302, the method may include receiving an application-layer request from a consumer entity for an application service that enables machine learning, wherein the application-layer request includes a machine learning model identifier and / or an analytics event identifier. The operation of 302 may be performed according to the examples described herein. In some implementations, aspects of the operation of 302 may be as described regarding... Figure 9 The NE described is used to execute.
[0131] In 304, the method may include determining, based on the application layer request, the first requirement for providing longitudinal federated learning training for enabling application services for machine learning. The operation of 304 may be performed according to instances as described herein. In some implementations, aspects of the operation of 304 may be as described regarding... Figure 9 The NE described is used to execute.
[0132] In 306, the method may include determining a second requirement based on a first requirement, wherein the second requirement includes requirements for the dataset and / or feature selection for machine learning-enabled services. The operation of 306 may be performed according to instances as described herein. In some implementations, aspects of the operation of 306 may be as described regarding... Figure 9 The NE described is used to execute.
[0133] It should be noted that the methods described herein describe possible implementations, and the operations and steps may be rearranged or otherwise modified, and other implementations are possible.
[0134] The description herein is provided to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be given the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A network entity for a wireless communication system, the network entity comprising: At least one memory; and At least one processor, coupled to the at least one memory and configured to enable the network entity to: Receive an application layer request from a consumer entity for an application service that enables machine learning, wherein the application layer request includes a machine learning model identifier and / or an analytics event identifier. Based on the application layer request, determine the first requirement for providing longitudinal federated learning training to enable application services for the machine learning; and The second requirement is determined based on the first requirement, wherein the second requirement includes a dataset requirement for the machine learning enabled service.
2. The network entity of claim 1, wherein the processor is configured to enable the network entity to discover a plurality of entities acting as candidate federated learning clients based on the first and / or second requirement, wherein the discovery includes the ability to obtain the plurality of entities.
3. The network entity of claim 2, wherein the processor is configured to configure at least one alignment parameter based on the second requirement and the capabilities of the discovered entity acting as a candidate federated learning client.
4. The network entity of claim 3, wherein the processor is configured to enable the network entity to select at least one entity from the plurality of candidate federated learning clients to act as the federated learning client for the machine learning enabled application service.
5. The network entity of claim 4, wherein the processor is configured to cause the network entity to transmit the at least one alignment parameter to the entity or each entity acting as a federated learning client.
6. The network entity according to any of the preceding claims, wherein the dataset is required to include one or more of the following: A set of identifiers corresponding to events or analysis events related to machine learning models; Sample range requirements, such as identifying multiple data sources, such as UE, geographical range, and / or time range; and Identifier of one or more statistical data.
7. A network entity according to any of the preceding claims, configured to function as an application data analytics enabler (ADAES) or other artificial intelligence enabler in the application layer of the wireless communication system.
8. The network entity according to any of the preceding claims, wherein the consumer entity is an entity of the vertical application layer (VAL) or an entity of the wireless core network.
9. The network entity according to any of the preceding claims, wherein the processor is configured to identify at least one entity acting as a candidate federated learning client by performing a federated learning client discovery procedure using network repository functionality or another registry.
10. The network entity according to any of the preceding claims, wherein the processor and / or one or more other processors are configured to receive a federated learning training response from the or each federated learning client and perform global model aggregation to obtain machine learning model parameters consistent with the request.
11. The network entity of claim 10, wherein the processor or each processor is configured to: Send the obtained machine learning model parameters to the consumer entity; or The obtained machine learning model parameters are used to obtain analytical data, and the obtained analytical data is sent to the consumer entity.
12. The network entity according to any of the preceding claims, wherein the federated machine learning client is located within one or more of the following: The application enabler layer of the wireless communication system; Core network; Edge data networks; regional data networks; user equipment; vertical applications; enterprise networks; and External cloud.
13. A method performed by a network entity of a wireless communication system, the method comprising: Receive an application layer request from a consumer entity for an application service that enables machine learning, wherein the application layer request includes a machine learning model identifier and / or an analytics event identifier. Based on the application layer request, determine the first requirement for providing longitudinal federated learning training to enable application services for the machine learning; and The second requirement is determined based on the first requirement, wherein the second requirement includes requirements for the dataset and / or feature selection of the machine learning enabled service.
14. The method of claim 13, further comprising: To discover multiple entities that can act as candidate federated learning clients based on the first and / or second requirements, wherein the discovery includes the ability to obtain the multiple entities.
15. The method of claim 14, further comprising: Configure at least one alignment parameter based on the second requirement and the capabilities of the discovered entity to act as a candidate federated learning client.
16. The method of claim 15, further comprising: At least one entity is selected from the plurality of candidate federated learning clients to act as the federated learning client for the machine learning enabled application service.
17. The method of any one of claims 13 to 16, further comprising receiving a federated learning training response from the or each federated learning client and performing global model aggregation to obtain machine learning model parameters consistent with the request.
18. The method of claim 17, further comprising: Send the obtained machine learning model parameters to the consumer entity; or The obtained machine learning model parameters are used to obtain analytical data, and the obtained analytical data is sent to the consumer entity.