Method and apparatus for application data analysis enabled artificial intelligence / machine learning enabled functionality

Abstract

Methods, apparatus, and systems are described for managing artificial intelligence (AI) / machine learning (ML) resources and capabilities available to application and service enabled layers, and coordinating AI / ML enabled analytics services. According to some aspects, an application data analysis enabling (ADAE) service may be enhanced to support an AI / ML enabled analysis service.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 518,905, filed August 11, 2023, which is incorporated herein by reference in its entirety. Background Technology

[0002] Machine learning (ML) is a branch of artificial intelligence (AI) that aims to build methods to improve performance on a set of tasks using data. For example, one or more ML algorithms can be used to build a model based on sample data (e.g., training data) to make predictions or decisions without explicit programming. The process of training an ML model can include data collection, data preparation / processing, model building / training, model evaluation, model deployment, monitoring, and updates. Once trained, the ML model can be deployed and used for its intended purpose, such as performing inference tasks and generating inference results. Supporting the deployed model and inference tasks may require access to hardware resources (e.g., computing power, communication bandwidth, etc.) and inference data.

[0003] 3GPP defines Network Data Analytics Function (NWDAF) and Application Data Analytics Enablement (ADAE) services to provide analytics services to various types of consumers in the network.

[0004] The analytics services provided by NWDAF (e.g., TS 23.288) are designed to support network data analytics services in the 5G core network. This analytics can collect data from other NFs, AFs, or OAMs and can be made available to third-party AFs to provide statistics and predictions related to various types of analytics, such as slice load levels, observed service experience, NF load, network performance, UE-related analytics (mobility, communications), user data congestion, QoS sustainability, DN performance, etc. For example, 3GPP TS23.288 outlines architectural enhancements for 5G systems (5GS) to support network data analytics services.

[0005] ADAE services (e.g., TS 23.436) provide functionality to support the unified delivery of data analytics services from different 3GPP domains to vertical ASPs. For example, 3GPP TS 23.436 outlines the functional architecture and information flow for application data analytics enabling services. ADAE services define value-added application data analytics services at a general level, encompassing statistics and forecasting for end-to-end application services. Key consumers of ADAE services can include vertically specific applications and edge applications. Summary of the Invention

[0006] This paper describes methods, apparatuses, and systems for managing the AI / ML resources and capabilities available in the application and service enablement layer, as well as for coordinating AI / ML-enabled analytics services. Based on some examples, ADAE services can be enhanced to support AI / ML-enabled analytics services.

[0007] Based on some examples, AI / ML resource and capability management is provided, where the ADAE service maintains profiles of AI / ML resources and capabilities and supports the registration and discovery process of AI / ML resources and capabilities.

[0008] Based on some examples, coordination of AI / ML enabled analytics services is provided, in which the ADAE service maintains and monitors the status of AI / ML service instances, coordinates AI / ML service requests received from different consumers, and dynamically determines service actions based on information about service instances and AI / ML resources / capabilities.

[0009] Based on some examples, enhancements to ADAE services can support AI / ML-enabled analytics services at the 3GPP Applications and Services Enablement Layer. Enhanced ADAE services can support the management of AI / ML resources and capabilities, as well as the coordination of AI / ML-enabled analytics services.

[0010] Based on some examples, messages can be received from AI / ML resource / capability providers. These messages may include descriptions of resources or capabilities that can be provided by the provider to support AI / ML-enabled analytics services. The message may be a registration request or a response to a query / request from ADAE. AI / ML resources or capabilities may include AI / ML data, AI / ML models, training capabilities, inference capabilities, etc. AI / ML resource / capability providers may be ADAE services, VAL entities (VAL servers, VAL clients), application / service enablement layer entities (e.g., SEAL, EES, etc.), or core network functions (e.g., NWDAF, DCCF, ADRF). Descriptions of AI / ML resources or capabilities may include: (1) AI / ML data descriptions, data formats, data uses, data characteristics, data locations, data sources, access policies, etc.; (2) AI / ML model descriptions, model requirements, model locations, associated training entities and training data, access policies, etc.; or (3) AI / ML training / inference capability descriptions, supported features, supporting resources, capability scheduling, access policies, service KPIs, etc.

[0011] Based on some examples, AI / ML resource and capability profiles can be generated based on received messages. Profiles can be created by the ADAE service or by the A-DCCF or A-ADRF function upon request from the ADAE service. In addition to a description of the resource or capability, the profile may further include the identifier of the corresponding resource / capability provider, and information about the associated service instances that are using or will use the resource / capability.

[0012] Based on some examples, messages can be received from AI / ML resource / capability consumers. These messages can include filtering criteria for AI / ML resources or capabilities that the consumer is interested in. The message can be a discovery request or a query / subscription request. AI / ML resource / capability consumers can be ADAE services, VAL entities (VAL servers, VAL clients), or application / service enablement layer entities (e.g., SEAL, EES, EEC, etc.). Filtering criteria can include information from the AI / ML resource / capability profile.

[0013] Based on some examples, a response can be sent to AI / ML resource / capability consumers. This response may include information about AI / ML resources or capabilities that the consumer is interested in. The response may include a profile of one or more AI / ML resources / capabilities.

[0014] Based on some examples, requests can be received from AI / ML service consumers. These requests may include the consumer's identifier and contextual information, notification conditions and objectives, the type of analysis required, service objectives (e.g., training or inference, or both), service requirements, etc. The request may further include information about any one of the following: training data, model, training entity, or inference entity, specified by the consumer.

[0015] Based on some examples, an AI / ML service instance profile can be generated based on a received request. In addition to the information from the request, the profile may further include the instance state, consumer context information (e.g., if the consumer is not provided), training data, model, training entity, and inference entity information (if the consumer is not specified).

[0016] Based on some examples, service actions can be determined based on information examined about AI / ML resources / capabilities (e.g., profiles) and existing AI / ML service instances. Service actions can include: selecting a data provider for training and inference data, selecting a training entity, selecting an inference entity, selecting existing data as training data, selecting an existing model, updating an existing training process, or updating an existing inference process. The service action of selecting a training entity can include sending a training request with training data information to the selected training entity. The service action of selecting an inference entity can include sending an inference request with trained model information to the selected inference entity. The service action of selecting training / inference entities can further include selecting and configuring multiple entities to jointly perform the training / inference process. The service action of updating an existing training process can include reselecting training entities, or combining training processes associated with multiple service instances and reconfiguring training entities / data. The service action of updating an existing inference process can include reselecting inference entities, or combining a list of notification targets associated with multiple service instances at the inference entity.

[0017] In addition, the enhanced ADAE service can have alternative implementations, including but not limited to standalone services independent of ADAE, AI / ML coordination services, AI / ML enabling services, etc.

[0018] This synopsis aims to present a selected set of concepts in a simplified form, which will be further described in the detailed embodiments below. This synopsis is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that address any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0019] A more detailed understanding can be obtained through the following description, which is given by way of example in conjunction with the accompanying drawings.

[0020] Figure 1 An example architecture for ADAE is shown; Figure 2 An example of the internal functional architecture of ADAE is shown; Figure 3 An example of the overall ADAE architecture is shown; Figure 4 An example of ADAE internal architecture is shown; Figure 5 An overview of example AI / ML-enabled ADAE services associated with native AI / ML capabilities is shown; Figure 6 An overview of example AI / ML-enabled ADAE services associated with external AI / ML capabilities is shown; Figure 7 An example AI / ML data registration process is shown; Figure 8 An example AI / ML model registration process is shown; Figure 9 An example AI / ML training / inference capability registration process is shown; Figure 10 An example AI / ML data discovery process is shown; Figure 11 An example AI / ML model discovery process is shown; Figure 12 An example AI / ML capability discovery process is shown; Figure 13 An example AI / ML service coordination process is shown; Figure 14 An example AI / ML service process associated with training is shown; Figure 15 An example AI / ML service process associated with reasoning is shown; Figure 16 This demonstrates an example of AI / ML-enabled ADAE supporting application performance analysis; Figure 17 This demonstrates an example of AI / ML-enabled ADAE supporting edge analytics; Figure 18 A sample GUI is shown; Figure 19A An example communication system is shown; Figure 19B A system diagram of an example RAN and core network is shown; Figure 19C A system diagram of an example RAN and core network is shown; Figure 19D A system diagram of an example RAN and core network is shown; Figure 19E Another example communication system is illustrated; Figure 19F It is a block diagram of an example device or apparatus (such as a WTRU); and Figure 19G This is a block diagram of an exemplary computing system. Detailed Implementation

[0021] Table 0.1 in the appendix contains explanations of the selected abbreviations used herein.

[0022] Figure 1 Example architecture 50 of ADAE is shown.

[0023] Figure 2 Example ADAE internal functional architecture 200 is shown.

[0024] Both NWDAF and ADAES support the Data Collection Coordination Function (DCCF) and the Analytical Data Repository Function (ADRF).

[0025] DCCF coordinates the collection and distribution of data requested by consumers or analytics services. It prevents data sources from having to handle multiple subscriptions for the same data and send multiple notifications containing the same information due to inconsistent requests from data consumers. Analytics services can send data requests to the corresponding DCCF function instead of directly to the data source. DCCF can also perform data processing and preparation based on service requirements.

[0026] The ADRF stores historical data and / or analytics, such as data and / or analytics obtained by consumers or analytics services that are relevant to past time periods. Once data and / or analytics information is obtained, it can be stored in the ADRF directly or via the DCCF.

[0027] In addition, NWDAF defines the following features that support AI / ML-enabled analytics services.

[0028] An NWDAF instance can contain an Analysis Logic Function (AnLF) that performs inference, derives analytics information based on consumer requests, and exposes analytics services.

[0029] An NWDAF instance can contain a Model Training Logic Function (MTLF) that trains an ML model and exposes new training services (e.g., providing a trained ML model). The trained model can be stored in an ADRF.

[0030] Discovery and Selection: The capabilities of an NWDAF instance are described in the NWDAF profile stored in the NRF. The NWDAF profile may include information such as supported analytics IDs / types, service regions, capabilities (analysis aggregation, accuracy checks, federated learning, roaming, etc.), supported data source types, or identifiers. NWDAF service consumers can use the NWDAF discovery process to select NWDAFs that support the requested analytics information and capabilities and / or ML model information. Discovery filters may include information from the NWDAF profile, model information, etc.

[0031] Accuracy Monitoring: NWDAF has the capability to check the accuracy of analytical and / or ML models, whereby NWDAF can provide accuracy information to consumers upon request or use that information in its internal processes. Analytical / ML model accuracy monitoring is achieved by comparing predictions made using the currently trained ML model with corresponding ground truth data (e.g., corresponding real-world observed events).

[0032] Federated learning: Federated learning can be supported by multiple NWDAFs containing MTLF, where one NWDAF containing MTLF acts as the FL server and the multiple NWDAFs containing MTLF act as FL clients.

[0033] 3GPP SA6 has defined the Application Data Analytics Enablement (ADAE) service to provide analytics services at the Application and Service Enablement layer. Although NWDAF has defined several functions in the core network to support AI / ML-enabled analytics services, these functions are not yet available at the Application and Service Enablement layer or in the ADAE service. Further functions to support AI / ML-enabled analytics services have not yet been defined. In particular, a method is lacking for the ADAE service to manage AI / ML resources and capabilities, or to coordinate training and inference processes from multiple AI / ML service requests.

[0034] ADAE services need to be enhanced to support AI / ML-enabled analytics services, particularly training and inference capabilities. However, several challenges exist when integrating AI / ML enabling capabilities into the application and service enabling layer.

[0035] This paper describes UE / edge-based training and inference. For AI / ML services, it is generally advantageous to execute the training and inference processes (e.g., or parts thereof) closer to the data source to minimize data transfer overhead and response time. Many analytics services supported by ADAE rely on data collected from UEs and / or edge data networks (EDNs), such as application performance analytics, UE-to-UE application performance analytics, edge load analytics, etc. Therefore, it is desirable for AI / ML-enabled analytics services (especially training and inference processes) to be supported on UE-based (e.g., ADAE clients) or edge-based ADAE services (e.g., ADAE servers implemented in EDNs).

[0036] Unlike analytics services provided by servers in the core network or cloud, UE-based or edge-based ADAE services may have limited access to the computing resources required to perform ML training or inference processes. For example, a UE-based ADAE service (e.g., an ADAE client) may not have continuous access to computing resources due to competing tasks running on the UE being given higher priority or low available battery levels. The availability or capability of edge-based ADAE services may depend on the state of the EDN or the corresponding edge enabler server (EES). Due to the dynamic nature of resources and capabilities, the optimal configuration of the training / inference process may need to be adaptively changed, such as determining which entity should be selected for training / inference and whether / when to switch to another entity so that the training / inference process can be executed successfully and efficiently.

[0037] Currently, there is a lack of a method that enables ADAE services to manage dynamic information about resources and capabilities and adaptively configure training / inference processes to support AI / ML-enabled analytics services in the application and service enablement layer.

[0038] This article describes the coordination of AI / ML processes. Requests for analytics services from different consumers may be for similar analytical results or services. In such cases, coordination may be necessary to avoid unnecessary processing or messaging, especially when resources and capabilities to support the analytics services are limited.

[0039] Currently, coordination functions (e.g., DCCF) have been defined for the data collection process, which can support coordination for analysis requests focused solely on the data being analyzed. However, AI / ML-enabled analytics services can further extend to the training and inference phases. Therefore, coordination functions are further required for the training and inference processes.

[0040] For example, the ADAE service can receive edge load prediction requests from different consumers for different sub-regions of the edge data network. The ADAE service can first train an ML model using historical measurement data collected from the EDN. The trained model can then be used to generate edge load predictions based on current measurement data from the EDN. Although the prediction results may differ across different sub-regions, the ML model used to generate the predictions can be the same.

[0041] Without coordination, ADAE services may process each request independently and configure the training process for each sub-region, resulting in repetitive training processes that essentially train the same model. In existing 3GPP-defined analytics services (e.g., NWDAF and ADAE), only data collection coordination functions are supported; coordination functions beyond data collection (e.g., for training and inference processes) have not yet been defined.

[0042] This document describes the resources and capabilities of the application enabler layer (non-ADAE). Entities in the application and service enabler layer (e.g., consumers of analytics services) may be able to provide native resources and capabilities to support a portion of the AI / ML process, such as entities from EEL, SEAL, SEALDD, CAPIF, etc. For example, a SEAL server or EES may be able to perform the inference process after a model has been trained by an ADAE service. Consumers can initiate AI / ML processes locally and then request ADAE services to complete them. For example, a VAL server can train an ML model and request ADAE services to assist in deploying the model to the UE, instructing the UE to perform the inference process using data collected from the application and service enabler layer. Currently, there is a lack of support and integration of non-ADAE AI / ML resources and capabilities to implement analytics service functionality within the application and service enabler layer.

[0043] Based on some examples, AI / ML enabling capabilities can enhance or interact with ADAE services to support AI / ML-enabled analytics services in the application and service enabling layer.

[0044] Figure 3 An example ADAE general architecture 300 is shown, which enhances the ADAE service and can interact with vertical application layers and other application / service enablement layer services.

[0045] Figure 4 An example ADAE internal architecture 400 for enhanced ADAE services is shown. According to some examples, AI / ML enabling functions can be implemented as internal functions within the ADAE service, or as external services (similar to A-DCCF or A-ADRF) that can interact with the ADAE service. Furthermore, the applications described herein can include all types of vertical industries, such as V2X, UAS, etc.

[0046] AI / ML service consumers can request AI / ML-enabled analytics services from ADAE services, or they can request specific AI / ML resources or capabilities managed by ADAE services. Consumers can be entities from the vertical application layer (e.g., VAL servers, VAL clients), entities from the application and service enablement layer (e.g., SEAL servers, EES, ADAE clients / servers, A-DCCF, A-ADRF), or entities from the core network (e.g., NWDAF instances).

[0047] AI / ML resource / capability providers can provide the essential resources and / or capabilities needed to support AI / ML-enabled analytics services. AI / ML consumers can also be resource / capability providers. A typical AI / ML process can consist of steps such as: collecting training and inference data, training an AI / ML model using the training data, performing inference using the trained model, performance monitoring, and model updates. Throughout this process, AI / ML data, AI / ML models, training, and inference entities can be managed by ADAE services.

[0048] AI / ML data can be data used in the training and / or inference processes during AI / ML operations. AI / ML data can be managed directly by the ADAE service or via the A-DCCF / A-ADRF function. Data can be provided by entities in the application and service enablement layer (e.g., SEAL, EEL, ADAE), VAL entities (VAL clients or VAL servers), or from the core network (e.g., NWDAF, OAM).

[0049] AI / ML models can be models trained using AI / ML algorithms, which can be used by analytics services in the inference process to generate inference / analysis results. AI / ML models can be managed directly by the ADAE service or via the A-ADRF function. The model can be provided by an entity with training capabilities, such as analytics service entities (ADAE, NWDAF) or VAL entities (VAL clients or VAL servers).

[0050] A training entity can be an entity with training capabilities that can perform training tasks and generate or update AI / ML models for AI / ML-enabled analytics services. A training entity can take training data as input and generate one or more trained / updated models as output. Entities capable of aggregating multiple partially trained models can also be considered training entities, such as FL servers.

[0051] An inference entity can be an entity with inference capabilities, capable of performing inference tasks and generating analytical results for AI / ML-enabled analytics services. An inference entity can take one or more trained models and inference data (if any) as input and generate inference / analysis results (e.g., predictions) as output.

[0052] Training and inference capabilities can be provided by native ADAE entities or by other entities from the application and service enablement layer, vertical application layer, or core network. An ADAE server can act as a training entity, an inference entity, or both. Specifically, if the ADAE server is deployed to the EDN (e.g., as an EAS or edge-based ADAE service), the availability of capabilities may be constrained due to factors such as EDN scheduling, EDN load, and service area / coverage limitations. ADAE clients at the UE (or UE-based ADAE services) can act as training or inference entities. For example, a trained model can be deployed to the UE, and the UE-based ADAE service can perform inference tasks locally to reduce the waiting time for generating analysis results for the UE. The availability of capabilities may be constrained due to factors such as the UE's capabilities, UE load, and user authorization / consent for its resource usage. Application and service enablement layer entities (e.g., SEAL servers, EES) can provide training or inference entities to support ADAE services. For example, an EES can act as an inference entity to support edge-related analysis. VAL servers can provide training or inference capabilities to support ADAE services. For example, AI / ML applications can provide trained models or training capabilities to ADAE services. NWDAFs can provide AI / ML resources and capabilities to ADAE services, such as contributing training data (using DCCF or ADRF features) or training capabilities (using NWDAF instances containing MTLF).

[0053] Based on some examples, AI / ML enabling capabilities can enhance ADAE services to support AI / ML-enabled analytics services. Enhanced ADAE services can provide management services for AI / ML resources and capabilities within the application and service enabling layer. Furthermore, enhanced ADAE services can provide coordination services for AI / ML processes, coordinating requests from different AI / ML service consumers, enabling AI / ML resources / capabilities or training / inference processes to be shared or reused across different service instances. Figure 5 and Figure 6 Overviews of AI / ML enabled ADAE services with and without external AI / ML capability providers are shown respectively.

[0054] Figure 5 An overview of example AI / ML-enabled ADAE services associated with native AI / ML capabilities is shown 500. As shown in step 1, the ADAE service can provide consumers with information on available AI / ML resources and capabilities (e.g., AI / ML data and models at A-ADRF, training and inference capabilities supported by the ADAE server / client) via discovery or open services. As shown in step 2, the ADAE service can provide consumers with data collection services (e.g., utilizing A-DCCF and / or A-ADRF) to generate training datasets that will be used to train models. As shown in step 3, the ADAE service can provide consumers with AI / ML training services using training capabilities available at the ADAE server / client to generate trained models that will be used for inference and to generate inference results. As shown in step 4, the ADAE service can provide consumers with AI / ML inference services using inference capabilities available at the ADAE server / client to generate analytics results for consumers. As shown in step 5, the ADAE service can provide coordination services to monitor and manage the AI / ML process and coordinate requests from multiple consumers.

[0055] Figure 6 An overview of example AI / ML-enabled ADAE services associated with external AI / ML capabilities is shown 600. ADAE services can further provide management services for external / non-ADAE AI / ML resources and capabilities. As shown in step 1, ADAE services can obtain and maintain information about AI / ML resources and capabilities from external providers via a registration service, and can share / open this information to consumers (step 2). ADAE services can support data collection (step 3), training (step 4), and inference (step 5) processes performed by ADAE or non-ADAE entities. As shown in step 6, coordination services can be provided.

[0056] This document describes AI / ML resource and capability management. AI / ML resources can include AI / ML data and AI / ML models. AI / ML capabilities can include AI / ML inference and training capabilities. These resources and capabilities can be used by AI / ML-enabled analytics services to generate analytics results. Resources and capabilities can be provided by resource / capability providers (e.g., SEAL entities, EEL entities, ADAE entities, VAL entities, NWDAF) and consumed by resource / capability consumers (e.g., ADAE entities, VAL entities, NWDAF). The management services and processes described below are not limited to AI / ML-enabled analytics services. They can also be applied to managing other types of analytics resources and capabilities.

[0057] This document describes AI / ML resource and capability profiles. The ADAE service can maintain AI / ML data profiles of data resources available for AI / ML services. The ADAE service can use AI / ML data profiles to determine which data can be used in the training process, instruct inference entities to obtain inference data, or record inference / analysis results for performance monitoring. AI / ML data profiles may include information as shown in Table 1.

[0058] Table 1. AI / ML Data Profile .

[0059] The ADAE service can maintain AI / ML model profiles of trained models that can be used for AI / ML services. The ADAE service can use AI / ML model profiles to determine whether an existing model can be used for AI / ML service requests, whether the model can be deployed to an inference entity (e.g., whether the inference entity can support the inference process using the model), or to track model performance to trigger updates. AI / ML model profiles can include information as shown in Table 2.

[0060] Table 2. AI / ML Model Profiles .

[0061] The ADAE service can maintain AI / ML training / inference capability profiles for entities that can be used for training / inference services. The ADAE service can use these profiles to determine which entity can perform the training / inference process, monitor the training / inference process being executed on the training / inference entity, and determine whether the training / inference process can be shared or reused by different AI / ML service requests. AI / ML training or inference profiles can include information as shown in Tables 3 and 4, respectively. For ADAE servers / clients containing AI / ML training and / or inference capabilities, an ADAE profile can be defined, containing information from the corresponding training and inference capability profiles.

[0062] Table 3. Brief Profile of AI / ML Training Capabilities (for training entities) .

[0063] Table 4. Brief Profile of AI / ML Inference Capabilities (for Inference Entities) .

[0064] This document describes the registration of AI / ML resources and capabilities. AI / ML resource or capability providers can provide information about their resources / capabilities to ADAE through a registration process. The registration process allows AI / ML resource or capability providers to provide information about the resources / capabilities they are willing to contribute to the ADAE service, enabling the discovery of these resources / capabilities. The registration process also allows the ADAE service to become aware of AI / ML data, even if the ADAE service itself does not own the data. If the information about a resource or capability changes, the provider can use the registration update process to update the ADAE service. Providers can use the deregistration process to remove information from the ADAE service.

[0065] Alternatively, the ADAE service can send a query / request to the provider to obtain information about its resources / capabilities, and then create / update the corresponding resource / capability profile. For example, the ADAE service can request information from a UE or EES that can act as a training or inference entity, and create / update a training / inference capability profile to include that information.

[0066] If the provider is an ADAE service, the ADAE service can create corresponding profiles to maintain information about resources / capabilities and enable the discovery of resources / capabilities.

[0067] Figure 7 An example AI / ML data registration process 700 is illustrated, in which an AI / ML data provider registers its data with an ADAE service. In this scenario, the ADAE service can be implemented as an ADAE server (as shown in the figure), an ADAE client, an A-DCCF, or an A-ADRF.

[0068] In step 1, the AI / ML data provider can send an AI / ML data registration request to the ADAE server. This request may include information about the data, such as the AI / ML data profile or the information in Table 1. Note that the registration request can be an initial registration, or an update or deletion of an existing registration.

[0069] In step 2, the ADAE server can perform an authorization check to verify whether the provider is authorized to register its data. Upon successful authorization, the ADAE server can create / update / delete an AI / ML data profile based on the information provided in the registration request, or send a request to the A-DCCF or A-ADRF to create / update / delete the AI / ML data profile.

[0070] In step 3, if the ADAE server requests the A-DCCF or A-ADRF to create / update the AI / ML data profile, the ADAE server may receive a response from the A-DCCF or A-ADRF. This response may include an identifier for the AI / ML data profile. For deletion requests, the A-DCCF or A-ADRF may only confirm the deletion of the AI / ML data profile.

[0071] At step 4, the ADAE server may send a registration response to the AI / ML data provider. If an AI / ML data profile was created in step 2, the response may include an identifier for the AI / ML data profile; alternatively, the response may include confirmation of an update or deletion of the AI / ML data profile.

[0072] At step 5, AI / ML data can be transferred from the provider to the A-ADRF. The ADAE service can initiate data transfer by sending a request to the provider and updating the "Data Location" in the AI / ML data profile to the address associated with the A-ADRF.

[0073] Providers can register multiple data instances with the ADAE service through a single registration or through separate registrations.

[0074] Figure 8 The example AI / ML model registration process 800 is illustrated, in which an AI / ML model provider registers its model with an ADAE service. In this scenario, the ADAE service can be implemented as an ADAE server (e.g., Figure 8 (as shown) or ADAE client, or A-ADRF.

[0075] In step 1, the AI / ML model provider can send an AI / ML model registration request to the ADAE server. This request may include model information, such as the AI / ML model profile or the information in Table 2. Note that the registration request can be an initial registration, or an update or deletion of an existing registration.

[0076] In step 2, the ADAE server can perform an authorization check to verify whether the provider is authorized to register its model. Upon successful authorization, the ADAE server can create / update / delete the AI / ML model profile based on the information provided in the registration request, or send a request to A-ADRF to create / update / delete the AI / ML model profile.

[0077] In step 3, if the ADAE server requests A-ADRF to create / update the AI / ML model profile, the ADAE server can receive a response from A-ADRF. This response may include an identifier for the AI / ML model profile. For deletion requests, A-DCCF or A-ADRF may only confirm the deletion of the AI / ML model profile.

[0078] At step 4, the ADAE server may send a registration response to the AI / ML model provider. If an AI / ML model profile was created in step 2, the response may include an identifier for the AI / ML model profile; or the response may include confirmation of an update or deletion of the AI / ML model profile.

[0079] At step 5, the AI / ML model can be transferred from the provider to the A-ADRF. The ADAE service can initiate model transfer by sending a request to the provider and updating the "Model Location" in the AI / ML data profile to the address associated with the A-ADRF.

[0080] Providers can register multiple models with the ADAE service through a single registration or through separate registrations.

[0081] Figure 9 The example AI / ML training / inference capability registration process 900 is illustrated, in which an AI / ML training / inference capability provider registers its capabilities with an ADAE service. In this scenario, the ADAE service can be implemented as an ADAE server (e.g., Figure 9 (as shown) or the ADAE client.

[0082] In step 1, the AI / ML capability provider can send an AI / ML capability registration request to the ADAE server. This request may include capability information, such as an AI / ML training / inference capability profile or the information in Tables 4 and / or 3. Note that the registration request can be an initial registration, or an update or deletion of an existing registration.

[0083] In step 2, the ADAE server can perform an authorization check to verify whether the provider is authorized to register its capabilities. Upon successful authorization, the ADAE server can create / update / delete AI / ML training / inference capability profiles.

[0084] At step 3, the ADAE server may send a registration response to the AI / ML capability provider. If an AI / ML training / inference capability profile was created in step 2, the response may include an identifier for the AI / ML training / inference capability profile; alternatively, the response may include confirmation of an update or deletion of the AI / ML model profile.

[0085] This article describes AI / ML resource and capability discovery. AI / ML resource and / or capability consumers can utilize the discovery process to discover information about needed / desired AI / ML resources / capabilities from ADAE services. The discovery process enables AI / ML service consumers to obtain information about AI / ML resources or capabilities. This discovery is based on matching against discovery filters provided in the discovery request.

[0086] Alternatively, consumers can subscribe to information about AI / ML resources / capabilities of interest through the ADAE service, which can then send notifications to consumers when the required resources / capabilities become available or when changes to the resources / capabilities are detected.

[0087] Figure 10 Example AI / ML data discovery process 1000 is illustrated, in which a consumer discovers AI / ML data from an ADAE service. In this scenario, the ADAE service can be implemented as an ADAE server (e.g., Figure 10 (as shown) or ADAE client, A-DCCF or A-ADRF.

[0088] In step 1, the AI / ML data consumer can send an AI / ML data discovery request to the ADAE server. The discovery request may include the requester (consumer) identifier and security credentials, and may include AI / ML data discovery filters such as data identifier, data description, data purpose, data characteristics, data source, etc.

[0089] In step 2, upon receiving a discovery request from a consumer, the ADAE server can check whether the consumer is authorized to discover the requested AI / ML data. If an AI / ML data profile is maintained at the ADAE server, the ADAE server can process the discovery request and apply discovery filters to identify the required AI / ML data. If an AI / ML data profile is maintained at the A-DCCF or A-ADRF function, the ADAE server can send a request to the A-DCCF or A-ADRF to retrieve the profile (by including discovery filters in the request to retrieve the profile of the AI / ML data that the consumer is interested in).

[0090] In step 3, if the ADAE server requests an AI / ML data profile from the A-DCCF or A-ADRF, the ADAE server may receive a response from the A-DCCF or A-ADRF containing the requested AI / ML data profile.

[0091] In step 4, if the request is successfully processed, the ADAE server can send an AI / ML data discovery response to the consumer, which may include information about the discovered AI / ML data, such as a data profile.

[0092] In step 5, the discovered AI / ML data can be transmitted from the A-ADRF to the consumer. The ADAE service can initiate data transmission by sending a request to the A-ADRF and adding the address information associated with the consumer to the "Data Location" in the AI / ML data profile.

[0093] Figure 11 An example AI / ML model discovery process 1100 is illustrated, in which a consumer discovers an AI / ML model from an ADAE service. In this scenario, the ADAE service can be implemented as an ADAE server (e.g., Figure 11 (as shown) or ADAE client, or A-ADRF.

[0094] In step 1, the AI / ML model consumer can send an AI / ML model discovery request to the ADAE server. The discovery request may include the requester (consumer) identifier and security credentials, and may include AI / ML model discovery filters, such as model identifier, model description, model requirements, training performance, etc.

[0095] In step 2, upon receiving a discovery request from a consumer, the ADAE server can check whether the consumer is authorized to discover the requested AI / ML model. If the ADAE server maintains AI / ML model profiles, it can process the discovery request and apply discovery filters to identify the desired AI / ML model(s). If the AI / ML model profiles are maintained at the A-ADRF function, the ADAE server can send a request to the A-ADRF to retrieve the profiles (by including discovery filters in the request to retrieve the profiles of the AI / ML models the consumer is interested in).

[0096] In step 3, if the ADAE server can request an AI / ML model profile from the A-ADRF, the ADAE server can receive a response from the A-ADRF containing the requested AI / ML model profile.

[0097] At step 4, if the request is successfully processed, the ADAE server can send an AI / ML model discovery response to the consumer, which may include information about the discovered AI / ML model(s), such as a profile of the model(s).

[0098] At step 5, the discovered AI / ML model(s) can be transferred from the A-ADRF to the consumer. The ADAE service can initiate model transfer by sending a request to the A-ADRF and adding the address information associated with the consumer to the "Model Location" in the AI / ML model profile.

[0099] Figure 12 An example AI / ML capability discovery process 1200 is illustrated, in which a consumer utilizes an ADAE service to discover AI / ML training / inference capabilities. In this scenario, the ADAE service can be implemented as an ADAE server (e.g., Figure 12 (as shown) or the ADAE client.

[0100] At step 1, the AI / ML capability consumer can send an AI / ML capability discovery request to the ADAE server. The discovery request may include a requester (e.g., consumer) identifier and security credentials, and may include AI / ML capability discovery filters such as capability type (e.g., training or inference or both), entity type, capability description, capability scheduling, service KPIs, etc.

[0101] In step 2, upon receiving a discovery request from a consumer, the ADAE server can check whether the consumer is authorized to discover the requested AI / ML capability. The ADAE server can process the discovery request and apply discovery filters to identify the required AI / ML capability (e.g., training entity or inference entity).

[0102] In step 3, if the request is successfully processed, the ADAE server can send an AI / ML capability discovery response to the consumer. This response may include information about the discovered AI / ML capability, such as a capability profile or information about the training / inference entity.

[0103] This document describes the coordination of AI / ML-enabled analytics services. Upon receiving a request for an AI / ML-enabled analytics service, ADAE can create an AI / ML service instance to maintain information about the request, monitor AI / ML processes (e.g., training and inference), and coordinate different instances or requests. Profile information can be provided by the consumer or configured by the ADAE service.

[0104] Information about AI / ML service instances can be described in the AI / ML service instance profile shown in Table 5.

[0105] Table 5. Brief Description of AI / ML Service Examples .

[0106] Figure 13 Example AI / ML service coordination process 1300 is shown, illustrating the coordination process performed by the ADAE service when a new AI / ML service request is received.

[0107] Figure 13 Start: Upon receiving an AI / ML service request, the ADAE service can create a service instance for the request and begin the coordination process. The ADAE service can check existing AI / ML resources / capabilities and service instances by examining the corresponding profile maintained at the ADAE service.

[0108] Figure 13 Decision 1: The ADAE service can first determine whether any existing inference process exists that can satisfy the request (e.g., the inference process could be associated with a service instance that served a previously received request). This can be done by examining the profiles of existing service instances in the "Performing Inference" state and comparing the service goals and service requirements. Depending on the result, the ADAE service may take the following actions: If an existing inference process can be found, the ADAE service can associate the existing process with the new service instance by adding the new service instance to the inference entity's capability profile and updating the corresponding notification target. Information about the inference process, such as inference entity information and model information, can be added to the new service instance's profile. If inference data is required, the ADAE service can instruct the inference entity to obtain the inference data by specifying it in the service instance profile or inference capability profile. The ADAE service can then update the new service instance's status to "Performing Inference".

[0109] If an existing inference process can be found, but it cannot support new service instances (e.g., due to insufficient computing power, it cannot access inference data, etc.) or the ADAE service can determine that the current inference entity is not the best choice, the ADAE service can select a new inference entity or reselect an inference entity for the inference process.

[0110] For example, a UE can request analytics information related to its current EDN. An inference entity (e.g., an edge-based ADAE server) is already generating analytics information for the UE's current EDN, but the UE is about to leave the current EDN and move to another EDN. In this case, the ADAE service can determine whether to select an inference entity located in the new EDN or select a UE-based inference entity for the inference process.

[0111] In another example, a UE can request analytics information related to its EDN, and the inference process is performed locally on the UE (e.g., using a UE-based inference entity). A second UE then requests the same analytics information but cannot obtain the analytics results generated at the first UE. In this case, the ADAE service can reselect an edge-based ADAE server as the inference entity to serve both UEs.

[0112] If no existing reasoning process exists that can provide the required service, the ADAE service can proceed to the next coordination action.

[0113] Figure 13 Decision 2: If no existing inference process can be found, the ADAE service can determine whether any existing AI / ML model(s) that have been trained and can be used to generate the required analysis results for the new service instance by checking the AI / ML model profile or querying the A-ADRF. Alternatively, the consumer can specify the model(s) to use in the service request. Depending on the result, the ADAE service may take the following actions: If an existing model(s) can be found, the ADAE service can associate that model(s) with a new service instance by updating the instance profile using the information from the found model(s). The ADAE service can then proceed to identify the reasoning entity used to perform the reasoning process using that model.

[0114] If no existing model is available for inference, the ADAE service can proceed to the next coordination action.

[0115] Figure 13 Decision 3: If a trained model cannot be found or used to generate the required analysis results for the new service instance, the ADAE service may determine whether there is any ongoing training process capable of generating the required model and fulfilling the request (e.g., a training process that can be associated with a service instance serving a previously received request). This can be done by examining the profiles of existing service instances in the "Training Model" state and comparing the service objectives and service requirements. Depending on the results, the ADAE service may take the following actions: If an existing training process can be found, the ADAE service can associate the existing process with the new service instance by adding the new service instance to the capability profile of the training entity and updating the corresponding notification target. Information about the training process, such as training entity information and training data information, can be added to the profile of the new service instance. The ADAE service can then update the status of the new service instance to "training model".

[0116] If an existing training process can be found but needs to be updated (e.g., due to new training data introduced by a new service instance), the ADAE service can update the configuration of the training process.

[0117] For example, a UE requests analytics information related to its local EDN, and an edge-based ADAE server in the same EDN is training a model for that request using training data originating from its local EDN. A second UE then requests analytics information related to its second EDN, where the model can be trained using data originating from the second EDN. The ADAE service can coordinate these two requests and reconfigure the training process so that a common training entity performs the training using aggregated training data from both EDNs. The trained model can then be deployed to both EDNs for inference.

[0118] In the same example, the ADAE service can determine how to train a model using federated learning so that training data from two EDNs can contribute to the model without needing to be relocated (e.g., transferred to a common training entity). If the training entity supports federated learning, ADAE can configure the training entity as an FL server and configure the local training entity in each EDN (e.g., an edge-based ADAE server) as an FL client.

[0119] If there is no existing training process that can provide the required services, the ADAE service can proceed to the next coordination action.

[0120] Figure 13 Decision 4: If neither a trained model nor an ongoing training process can be found, the ADAE service can determine whether any existing AI / ML data exists that can be used to train a model for a new service instance by checking the AI / ML data profile or querying the A-ADRF. Alternatively, the consumer can specify the training data to use in the service request. Depending on the outcome, the ADAE service may take the following actions: If existing training data can be found, the ADAE service can associate the data with a new service instance by updating the instance profile using the information from the found data. The ADAE service can then proceed to identify the training entities used to perform the training process using that data.

[0121] If there is no existing data available for training, the ADAE service can identify where / how to collect training data and initiate a data collection process to generate the required training data.

[0122] In the example, a system, apparatus, or method for providing AI / ML enabling services may be provided. For instance, the system may receive one or more provider messages from one or more AI / ML resource / capability providers, the provider messages including one or more descriptions of one or more AI / ML resources or capabilities from the one or more AI / ML resource / capability providers. The system may enable the AI / ML service and store one or more descriptions of one or more AI / ML resources or capabilities based on the provider messages. The system may receive consumer requests from AI / ML service consumers, the consumer requests including an identifier of the AI / ML service consumer, one or more notification conditions and objectives, a desired analysis type, or one or more service requirements. The system may determine a service action based on processing information associated with one or more descriptions of one or more AI / ML resources or capabilities and the consumer request, the service action including selecting an AI / ML resource / capability provider from the one or more AI / ML resource / capability providers to perform an AI / ML operation. The system may send a request to the selected AI / ML resource / capability provider to perform one or more AI / ML operations. The system may receive a response message from the selected AI / ML resource / capability provider indicating that one or more AI / ML operations have been performed and including one or more results of the performed AI / ML operations. The system can send notification messages to AI / ML service consumers that include one or more results of the AI / ML operations performed.

[0123] Based on some examples, in Figure 14 and Figure 15 The document details the service process. Figure 14 Example AI / ML service process 1400 associated with training is shown, and Figure 15 An example AI / ML service process 1500 associated with inference is illustrated, in which a consumer requests an AI / ML-enabled analytics service, including data collection, training, and inference processes. Based on the service coordination results (e.g., Figure 14 and Figure 15 Step 2 in both cases can skip some steps (e.g., in...). Figure 13 The detailed decision-making process for skipping is described in the document. Specifically, if the consumer only requests the training service (e.g., the service target is one or more trained models), then skipping is possible. Figure 15 The process in the middle. If the consumer only requests inference services (e.g., the trained model is already available), it can be skipped. Figure 14The process in question. Note that AI / ML service consumers can also be providers of some of the AI / ML resources and capabilities used for the requested service.

[0124] refer to Figure 14 In step 1, the ADAE service receives an AI / ML service request from the consumer. In the request, the consumer can specify the analysis type, service objective, service requirements, notification settings, etc. The consumer can also specify the resources / capabilities used for the request, such as training data, trained models, trained entities, and inference entities. The ADAE service can create a service instance for this request and record information associated with the instance in an AI / ML service instance profile (e.g., as shown in Table 5). This request can be sent as a single message or multiple messages.

[0125] In step 2, the ADAE service can perform the following: Figure 13 The service coordination process described herein. Based on the results of service coordination, the ADAE service can determine to jump to one or more of the following steps.

[0126] In step 3, if the ADAE service determines in step 2 that training data has not yet been collected or needs to be updated / expanded, the ADAE service can identify a data provider and initiate a training data collection process. The ADAE service can send a data collection request to the A-DCCF function to collect training data, where the A-DCCF can determine whether to use historical data (e.g., if available) or collect new training data. Alternatively, the data collection process can be performed by the ADAE service, which can then create an AI / ML data profile for the collected data.

[0127] At step 4, the A-DCCF can first check whether the A-ADRF has historical training data that meets the training request requirements. If historical data is unavailable, the A-DCCF performs a data collection process to collect the required training data (e.g., the interaction between the A-DCCF and the data source is not in progress). Figure 14 (As shown in the diagram). Once data collection is complete, the A-DCCF can register the collected data with the A-ADRF and create an AI / ML data profile. The A-DCCF can then perform data processing as needed, such as data preparation, data cleaning, data transformation, and data aggregation.

[0128] At step 5, A-DCCF may send a response to the ADAE service. This response may include an AI / ML data profile associated with the training data (e.g., an identifier for the AI / ML data profile).

[0129] In step 6, upon receiving a response regarding the data collection process, the ADAE service can update the status of the service instance to "Training data collection complete" and send a notification to the service consumer or notification target according to the notification settings specified in the service request. This notification may include an AI / ML data profile associated with the training data (e.g., an identifier for the AI / ML data profile).

[0130] In step 7, the ADAE service can determine the training entity and its corresponding configuration based on the service requirements in the request and the AI / ML training capability profile. The ADAE service can select more than one training entity to perform the training process, such as in distributed training, federated learning, model partitioning scenarios, or due to the scheduling / availability of training entities. The ADAE service can update its selection of training entities when it detects a change in the training entity (e.g., when the capability profile is updated). If more than one model is to be trained, the ADAE service can determine a training entity for each model, or determine a common training entity for all models. Alternatively, the training entity can be determined by the consumer (e.g., via the AI / ML training capability discovery process) and specified in the AI / ML service request.

[0131] At step 8, the ADAE service may send a model training request to the selected training entity and update the service instance's status to "Training Model". In this request, the ADAE service may include information about the training data (e.g., the identifier of the AI / ML data profile, data location), information about the model to be trained (e.g., the identifier of the AI / ML model profile, model location), and the configuration of the training entity as determined in step 7. The ADAE service may also request the training entity to register the trained model with the ADAE service or the A-ADRF function. Alternatively, the ADAE service may send a request to the determined training entity to update the model or update the model's training process. In this case, the ADAE service may include information about the model to be updated (e.g., the identifier of the AI / ML model profile, model location) in the request. For example, the ADAE service may request the training entity to update the trained model using newly collected training data obtained in step 5, or request the training entity to continue the training process migrated from another training entity.

[0132] At step 9, the training entity can retrieve training data and the AI / ML model from the A-ADRF by providing the identifiers of the AI / ML data profile and AI / ML model profile provided by the ADAE service in step 8. Alternatively, the training entity can retrieve the training data / model based on the data / model location information provided by the ADAE service in step 8.

[0133] At step 10, after retrieving training data and / or the AI / ML model, one or more selected training entities can perform a training process to train or update the AI / ML model.

[0134] In step 11, after the model is trained, the training entity can register the trained model with the ADAE service or the A-ADRF function and create an AI / ML model profile. If the model is updated, the training entity can update the AI / ML model profile through the ADAE service or the A-ADRF function.

[0135] At step 12, one or more selected training entities that trained the model can send a response to the ADAE service. This response may include an identifier of the created / updated AI / ML model profile.

[0136] In step 13, upon receiving a response regarding the training process, the ADAE service can update the status of the service instance to "Model training complete" and send a notification to the service consumer or notification target according to the notification settings specified in the service request. This notification may include an AI / ML model profile associated with the trained model (e.g., an identifier for the AI / ML model profile) and the status of AI / ML training completion.

[0137] If multiple models need to be trained for a service request, the ADAE service can create a separate service instance for the training process of each model (e.g., each model requires different training data or training entities), or jointly manage the training process of all models (e.g., if the training processes share the same training data or training entities).

[0138] Figure 15 An example inference process 1500 for an AI / ML service request is shown (e.g., steps 1 and 2 can be skipped). Alternatively, the consumer can request the inference service only from the ADAE service (e.g., steps 1 and 2 can be performed).

[0139] Figure 15 Prerequisites: It can be assumed that the AI / ML model(s) required by the service request are already available (e.g., provided by the consumer, available and stored in A-ADRF, or provided by the ADAE service via...). Figure 14 (obtained during the training process).

[0140] refer to Figure 15 In step 1, the ADAE service receives an AI / ML service request from the consumer that is only for inference services. The ADAE service can create a service instance for the request and record the information associated with the instance in the AI / ML service instance profile (e.g., as shown in Table 5).

[0141] In step 2, the ADAE service can perform the following: Figure 13 The service coordination process described herein. Based on the results of service coordination, the ADAE service can determine to jump to one of the following steps.

[0142] At step 3, the ADAE service determines whether inference data is needed. If so, the ADAE service can initiate an inference data collection process. The ADAE service can send a data collection request to the A-DCCF function to collect inference data (the interaction between A-DCCF and the data source is not shown in the figure). Alternatively, the data collection process can be performed by the ADAE service. AI / ML data profiles can be created for the inference data. The inference data collection process can be performed before the inference process (e.g., offline / batch inference) or concurrently with the inference process (e.g., online inference).

[0143] In step 4, the ADAE service can determine the inference entity and its corresponding configuration based on the service requirements in the request and the AI / ML inference capability profile. The ADAE service can select more than one inference entity to perform the inference process, such as in collaborative inference, model partitioning scenarios, or due to inference entity scheduling / availability. The ADAE service can select and configure multiple inference entities to perform the inference process sequentially. The ADAE service can update its selection of inference entities when it detects a change in the inference entity (e.g., when the capability profile is updated). If more than one model will be used for inference, the ADAE service can determine the configuration for model deployment. Alternatively, the inference entity can be determined by the consumer (e.g., via the AI / ML inference capability discovery process) and specified in the AI / ML service request.

[0144] In step 5, after identifying the inference entity, the ADAE service can send a notification to the service consumer or notification target based on the notification settings specified in the service request. This notification may include an AI / ML capability profile associated with the inference entity (e.g., an identifier for the AI / ML capability profile). If the consumer participates in the inference process as the inference entity, the ADAE service may include configuration information in the notification. For example, the consumer may perform initial inference locally and request the ADAE service to perform the remaining process. In this case, the ADAE service may instruct the consumer to retrieve the AI / ML model, perform inference, and send the intermediate results to A-ADRF. The remaining part of the inference process can then be performed on another inference entity identified by the ADAE service.

[0145] At step 6, the ADAE service may send an inference request to the identified inference entity and update the service instance's status to "Performing Inference". This request may include information about the trained model (e.g., an identifier for the AI / ML model profile, model location), information about the inference data (if any), and the configuration of the inference entity as determined in step 4. The ADAE service may also request the inference entity to register inference / analysis results with the ADAE service or the A-ADRF function. Optionally, if supported by the inference entity, the ADAE service may request the inference entity to perform performance monitoring.

[0146] At step 7, the inference entity can perform a discovery process by retrieving the trained model (and inference data) from the A-ADRF using the identifier of the AI / ML model profile provided by the ADAE service in step 6. Alternatively, the inference entity can retrieve the trained model (e.g., and inference data) based on the model / data location information provided by the ADAE service in step 6.

[0147] In step 8, after retrieving (one or more) trained models, the selected one or more inference entities can perform the inference process and generate analysis results.

[0148] In step 9, the ADAE service can be configured to store the generated inference or analysis results at the A-ADRF for performance evaluation or monitoring purposes. AI / ML data profiles can be created for the stored inference / analysis results.

[0149] At step 10, the selected one or more inference entities may send a response to the ADAE service. This response may include an identifier of an AI / ML data profile associated with the inference result.

[0150] At step 11, during the inference process, a model update can be triggered by the inference entity or by the ADAE service (e.g., due to detected performance drift). The ADAE service can perform actions such as... Figure 14 The training service process is shown, and then the inference entity is notified about the updated model.

[0151] In step 12, after receiving a response regarding the inference process, the ADAE service can send a notification to the service consumer or notification target according to the notification settings specified in the service request. This notification may include an AI / ML data profile associated with the inference / analysis result (e.g., an identifier for the AI / ML data profile). Alternatively, the ADAE service can send information about the inference entity to the consumer, allowing the consumer to directly request the inference / analysis result from the inference entity.

[0152] Leveraging the proposed features, the enhanced ADAE service can support AI / ML-enabled application performance analysis, such as VAL server performance analysis, VAL session performance analysis, and UE-to-UE application performance analysis. Consumers (e.g., VAL servers) can request AI / ML-enabled analysis results from the ADAE service, which can be generated based on QoS / performance data measured by the UE.

[0153] Figure 16 This diagram illustrates an example process 1600 for AI / ML-enabled ADAE-supported application performance analysis. Not all entities or steps involved in this process are shown in the diagram.

[0154] At step 0, the ADAE server can expose information about its services and capabilities to consumers (e.g., the VAL server), such as training and inference capabilities available at the ADAE server and ADAE client (e.g., via the AI / ML resource and capability discovery process). For example, inference capabilities at the ADAE client can indicate that AI / ML analysis results can be generated locally at the UE without uploading real-time measurement data.

[0155] At step 1, the consumer can send an analytics (e.g., subscription) request to the ADAE server. In this request, the consumer can specify the analytics results that require AI / ML enabling, which can be achieved by using a specific analytics ID (e.g., "AI / ML enabled VAL session performance analytics") or by including an indicator for AI / ML enabling in the request. Additionally, as... Figure 14 As described in step 1 (and Table 5), consumers can specify additional requirements for the analytics service (e.g., data source, model, training, or inference entity). Consumers can further specify that analytics results should be generated locally on the UE, if supported, by specifying the ADAE client as the inference entity in the request. If the consumer does not specify where the analytics results should be generated, the ADAE server can adaptively determine the inference entity based on the state of the AI / ML process.

[0156] In step 2, the ADAE server can perform the following: Figure 13 The aforementioned service coordination, and identification of data providers and training entities (e.g., Figure 14 Step 7) and reasoning entities (e.g., Figure 15 Step 4). For example, the ADAE server can evaluate the AI / ML capability profile of the ADAE client to determine whether it is capable of performing the training and / or inference process.

[0157] In step 3, the ADAE server can send analysis requests to the ADAE client to collect training data, such as... Figure 14As described in step 3. If the ADAE client wants to perform training, the ADAE server can provide the ADAE client with information about the model to be trained (e.g., the URI of the ML model) and the corresponding configuration information (e.g., ...). Figure 14 (as described in step 8).

[0158] In step 4, the VAL client can establish a connection with a VAL server for VAL server / session performance analysis. This VAL server may be different from the VAL server that issued the request in step 1, or it may establish a connection with another UE's VAL client for UE-to-UE VAL session performance analysis. Application QoS measurements regarding the connection can be collected for use as training data.

[0159] In step 5, if the model is to be trained on the ADAE server, the ADAE client can send the collected training data to the ADAE server (e.g., directly or via A-DCCF / A-ADRF). If the model is to be trained locally on the ADAE client, the ADAE client can send a notification to the ADAE server indicating that training data collection is complete and the training process has begun.

[0160] In step 6, the AI / ML model can be trained by the ADAE server (or ADAE client) using the training data. If training is performed on the ADAE client, the ADAE client can send a notification to the ADAE server when training is complete.

[0161] In step 7, the ADAE server can send an analysis request to the ADAE client for the inference process. This request may include information about the trained model, information about the inference data (e.g., data to be collected), and other relevant information. Figure 15 The corresponding configuration information described in step 6.

[0162] At step 8, real-time QoS measurements about the connection can be collected, which can be used as inference data.

[0163] In step 9, the ADAE client can derive analysis results using the trained model and the collected inference data. The ADAE server can adaptively change the inference entity. For example, if the ADAE client's computing power is unavailable for a period of time, the ADAE server can temporarily take over the inference process while requesting inference data from the ADAE client.

[0164] In step 10, the ADAE client can send an analysis notification, including the analysis results, to the ADAE server. This notification may also include analysis performance monitoring results that could trigger model updates.

[0165] In step 11, the ADAE server can send an analysis notification to the consumer containing the generated analysis results.

[0166] Figure 16 The process described can also be applied to other analysis IDs that require analysis results to be generated locally on the UE.

[0167] Leveraging the proposed functionalities, the enhanced ADAE service can support AI / ML-enabled edge-related analytics, such as EDN load analysis, edge server load analysis, and edge service / application performance analysis. Consumers (e.g., ECS, EES, EAS, VAL servers) can request AI / ML-enabled analytics results from the ADAE service, which can be generated based on data collected from one or more EDNs.

[0168] Figure 17 Example process 1700 for AI / ML enabled ADAE-supported edge analysis is shown. Figure 17 Not all entities or steps involved in the process are shown in the text.

[0169] At step 0, the ADAE server can expose information about its services and capabilities to consumers (e.g., EEL entities or VAL servers), such as the training and inference capabilities available at the ADAE server deployed to the EDN (e.g., via the AI / ML resource and capability discovery process). For example, training capabilities at the edge-based ADAE server can indicate that AI / ML models can be trained / updated locally on the EDN using data collected from the EDN without uploading the data.

[0170] At step 1, the consumer can send an analytics (e.g., subscription) request to the ADAE server. In this request, the consumer can specify the edge analytics results required for AI / ML enabled for EDN-1, which can be achieved by using a specific analytics ID (e.g., "AI / ML enabled edge load analytics") or by including an indicator for AI / ML enabling in the request. Additionally, as... Figure 14 As described in step 1 (and Table 5), consumers can specify additional requirements for the analytics service (e.g., data source, model, training or inference entity). Consumers can further specify that the AI / ML model should be trained locally on EDN-1, if supported, by specifying the ADAE server in EDN-1 as the training entity in the request.

[0171] In step 2, the ADAE server can perform the following: Figure 13The aforementioned service coordination, for example, allows the ADAE server to use the training information and model description IE of the AI / ML model profile described in Table 2 to identify an AI / ML model that is already available with the same analytics ID, but which was trained for EDN-2 (e.g., using training data collected from EDN-2), and may or may not be applicable to EDN-1.

[0172] In step 3, the ADAE server can send an analysis request to the edge-based ADAE server in EDN-1 for the inference process. This request may include the URI of a model trained for EDN-2 or a trained model that the ADAE server can download.

[0173] In step 4, real-time edge-related data of EDN-1 is collected, which can be used as inference data.

[0174] In step 5, the ADAE server in EDN-1 can use the model from EDN-2 and the inference data collected from EDN-1 to derive the analysis results. The ADAE server in EDN-1 can also monitor the performance (e.g., accuracy) of the inference process and log information.

[0175] At step 6, the ADAE server in EDN-1 can send an analytics notification, including the analytics results, to the ADAE server that received the analytics request from it, or to the consumer if the consumer is also in EDN-1 (e.g., an EES in EDN-1). This notification can also include analytics performance monitoring results that can trigger model updates. For example, performance monitoring results might indicate that a model for EDN-2 is not suitable for EDN-1, which could trigger an update or retraining of the model to better suit EDN-1.

[0176] In step 7, based on the received analytics performance information, the ADAE server can determine that the AI / ML model of EDN-2 needs to be updated / retrained for EDN-1. The ADAE server can check the AI / ML capability profiles of the edge-based ADAE servers in EDN-1 to determine their configuration (e.g., training scheduling, support for FL). The ADAE server can send analytics requests with the determined configuration information to the edge-based ADAE servers in EDN-1 to update / retrain the model using data collected from EDN-1. The ADAE server can determine whether to apply distributed learning or federated learning to train the model. For example, an ADAE server in the core network (e.g., acting as a FL server) can send model update requests to ADAE servers at different EDNs (e.g., acting as FL clients) and aggregate the updated models.

[0177] At step 8, the ADAE server in EDN-1 can use the data collected from EDN-1 to update the model in EDN-2 or retrain the model. Previously collected inference and performance monitoring data can be used as training data for updating / retraining the model. The "Data Usage" section in the AI / ML data profile can be updated accordingly. If needed, the ADAE server in EDN-1 can initiate additional data collection processes to gather more training data.

[0178] In step 9, the ADAE server in EDN-1 derives the analysis results using the updated / retrained model. The ADAE server in EDN-1 can send analysis notifications containing information about the updated / retrained model to the ADAE servers in the core network.

[0179] In step 10, the ADAE server in EDN-1 sends an analytics notification to the ADAE server and / or consumer. This notification may include analytics results generated using the updated / retrained model.

[0180] Figure 17 The process described can also be applied to other analytics IDs that require training / updating AI / ML models locally on the EDN.

[0181] Figure 18 An example graphical user interface (GUI) 1800 is shown, in which consumers can request services from AI / ML-enabled analytics services. Consumers can discover any available existing AI / ML resources or capabilities, or request the creation of new AI / ML service instances capable of performing training and / or inference tasks.

[0182] The 3rd Generation Partnership Project (3GPP) sets the technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities—including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), Advanced Long Term Evolution (ALE), and New Radio (NR), also known as “5G.” 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technologies (new RATs), which are expected to include new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new, non-backward-compatible radio access in the new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with differentiated needs. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which can provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz and have design optimizations for centimeter-wave and millimeter-wave.

[0183] 3GPP has identified a variety of use cases that NR is expected to support, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communication (URLLC), massive machine-type communication (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communication, which can include any of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-other-entities communication. Specific services and applications within these categories include, for example, monitoring and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases, as well as others, are envisioned in this document.

[0184] Figure 19AAn example communication system 100 is illustrated, in which the systems, methods, and apparatus described and claimed herein may be used. Communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which are generally or collectively referred to as one or more WTRUs 102. Communication system 100 may include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. Network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, Internet of Things services, video streaming, and / or edge computing.

[0185] It should be understood that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 19A In the example, each of WTRU 102 is in Figure 8 The device is described as a handheld wireless communication device in A-8E. It should be understood that each WTRU may include or be included in any type of device or equipment configured to transmit and / or receive wireless signals for the wide variety of use cases envisioned for wireless communication, including, by way of example only, user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, tablet, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, buses or trucks, trains or airplanes, etc.

[0186] The communication system 100 may also include base station 114a and base station 114b. Figure 19AIn the example, each base station 114a and 114b is depicted as a single element. In practice, base stations 114a and 114b may include any number of interconnected base stations and / or network elements. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. Similarly, base station 114b can be any type of device configured to interface, via wired and / or wireless, with at least one of the Remote Radio Headers (RRHs) 118a, 118b, Transmit and Receive Points (TRPs) 119a, 119b, and / or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. RRHs 118a, 118b can be any type of device configured to interface, via wirelessly, with at least one of the WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112.

[0187] TRPs 119a and 119b can be any type of device configured to wirelessly interface with at least one WTRU 102d to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, network services 113, and / or other networks 112). RSUs 120a and 120b can be any type of device configured to wirelessly interface with at least one of WTRUs 102e or 102f to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, other networks 112, and / or network services 113). For example, base stations 114a and 114b can be base transceiver stations (BTS), node Bs, eNode Bs, home node Bs, home eNode Bs, next-generation node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, etc.

[0188] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as BSCs, RNCs, relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographical area (which may be referred to as a cell (not shown)). Similarly, base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical area (which may be referred to as a cell (not shown)). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, for example, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. Base station 114a may employ multiple-input multiple-output (MIMO) technology, and thus, for example, multiple transceivers may be used for each sector of the cell.

[0189] Base station 114a can communicate with one or more of WTRUs 102a, 102b, 102c, and 102g via air interfaces 115 / 116 / 117. The air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0190] Base station 114b can communicate with one or more of RRH 118a and 118b, TRP 119a and 119b, and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b. The wired or air interface can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115b / 116b / 117b can be established using any suitable RAT.

[0191] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c. The air interface can be any suitable wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interface 115c / 116c / 117c can be established using any suitable RAT.

[0192] WTRU 102 can communicate with each other via direct air interfaces 115d / 116d / 117d, such as sidelink communication. The direct air interface can be any suitable wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115d / 116d / 117d can be established using any suitable RAT.

[0193] Communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 103 / 104 / 105, or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b, and WTRUs 102c, 102d, 102e, and 102f in RAN 103b / 104b / 105b, can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can respectively use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0194] Base stations 114a and WTRUs 102a, 102b, 102c, and 102g in RAN 103 / 104 / 105, or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b, and WTRUs 102c and 102d in RAN 103b / 104b / 105b, can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can, for example, use Long Term Evolution (LTE) and / or LTE-A Advanced to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively. Air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communication). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communication).

[0195] Base stations 114a and WTRUs 102a, 102b, 102c and 102g in RAN 103 / 104 / 105, or RRH 118a and 118b, TRP 119a and 119b, and / or RSU 120a and 120b and WTRUs 102c, 102d, 102e and 102f in RAN 103b / 104b / 105b, can implement standards such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), and GSM... Radio technologies such as EDGE (GERAN).

[0196] Figure 19ABase station 114c can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, trains, aircraft, satellites, manufacturing plants, campuses, etc. Base station 114c and WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, base station 114c and WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). Base station 114c and WTRU 102 (e.g., WTRU 102e) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. Figure 19A As shown, base station 114c can connect directly to the Internet 110. Therefore, base station 114c may not need to access the Internet 110 via core network 106 / 107 / 109.

[0197] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, messaging, authorization and authentication, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, and / or perform advanced security functions such as user authentication.

[0198] Despite Figure 19A Although not shown, it should be understood that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM or NR radio technology.

[0199] Core networks 106 / 107 / 109 can also serve as gateways for WTRU 102 to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Other networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs using the same RAT as or a different RAT than RAN103 / 104 / 105 and / or RAN 103b / 104b / 105b.

[0200] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 19A The WTRU 102g shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114b that can employ IEEE 802 radio technology.

[0201] Despite Figure 19A Although not shown, it should be understood that user equipment can establish a wired connection to a gateway. The gateway can be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It should be understood that many of the concepts contained herein are equally applicable to UEs acting as WTRUs and UEs connecting to the network using wired connections. For example, concepts applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c are equally applicable to wired connections.

[0202] Figure 19B This is a system diagram of example RAN 103 and core network 106. As described above, RAN 103 can employ UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 19BAs shown, RAN 103 may include nodes B 140a, 140b, and 140c, each node B may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of node Bs and radio network controllers (RNCs).

[0203] like Figure 19B As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control its connected corresponding node B 140a, 140b, and 140c. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0204] Figure 19B The core network 106 shown may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0205] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b and 102c and legacy landline communication equipment.

[0206] The RNC 142a in RAN 103 can also be connected to the SGSN 148 in core network 106 via the IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and GGSN 150 can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0207] The core network 106 can also connect to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0208] Figure 19C This is a system diagram of example RAN 104 and core network 107. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with core network 107.

[0209] RAN 104 may include eNode-B 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs. eNode-B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via air interface 116. For example, eNode-B 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit and receive radio signals from WTRU 102a.

[0210] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 19C As shown, eNode-B 160a, 160b and 160c can communicate with each other via the X2 interface.

[0211] Figure 19C The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0212] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0213] Serving Gateway 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving Gateway 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, and 102c. Serving Gateway 164 can also perform other functions, such as anchoring the user plane during handover between eNode-Bs, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0214] Service gateway 164 can also connect to PDN gateway 166, which can provide WTRU 102a, 102b and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b and 102c and IP-enabled devices.

[0215] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between core network 107 and PSTN 108. Additionally, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0216] Figure 19DThis is a system diagram of example RAN 105 and core network 109. RAN 105 can use NR radio technology to communicate with WTRU 102a and 102b via air interface 117. RAN 105 can also communicate with core network 109. Non-3GPP Interoperability Function (N3IWF) 199 can use non-3GPP radio technology to communicate with WTRU 102c via air interface 198. N3IWF 199 can also communicate with core network 109.

[0217] RAN 105 may include gNode-B 180a and 180b. It should be understood that RAN 105 may include any number of gNode-Bs. gNode-B 180a and 180b may each include one or more transceivers for communicating with WTRU 102a and 102b via air interface 117. When using integrated access and backhaul connections, the same air interface may be used between the WTRU and the gNode-B, which may be via the core network 109 of one or more gNBs. gNode-B 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming technologies. Therefore, gNode-B 180a may, for example, use multiple antennas to transmit and receive radio signals from WTRU 102a. It should be understood that RAN 105 may employ other types of base stations, such as eNode-B. It should also be understood that RAN 105 may employ more than one type of base station. For example, RAN may employ both eNode-B and gNode-B.

[0218] The N3IWF 199 may include a non-3GPP access point 180c. It should be understood that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c via air interface 198. The non-3GPP access point 180c may use the 802.11 protocol to communicate with the WTRU 102c via air interface 198.

[0219] Each of the gNode-B 180a and 180b can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 19D As shown, gNode-B 180a and 180b can communicate with each other, for example, via the Xn interface.

[0220] Figure 19DThe core network 109 shown may be a 5G core network (5GC). The core network 109 can provide various communication services to customers interconnected via a radio access network. The core network 109 includes multiple entities that perform core network functions. As used herein, the terms "core network entity" or "network function" refer to any entity that performs one or more functions of the core network. It should be understood that such a core network entity may be a logical entity implemented in the form of computer-executable instructions (software) stored in a device or computer system (such as...) configured for wireless and / or network communication. Figure 19G The system 90 shown is stored in its memory and executed on its processor.

[0221] exist Figure 19D In the example, the 5G core network 109 may include Access and Mobility Management Functions (AMF) 172, Session Management Functions (SMF) 174, User Plane Functions (UPF) 176a and 176b, User Data Management Functions (UDM) 197, Authentication Server Functions (AUSF) 190, Network Opening Functions (NEF) 196, Policy Control Functions (PCF) 184, Non-3GPP Interoperability Functions (N3IWF) 199, and User Data Repository (UDR) 178. While each of the foregoing elements is depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Figure 19D The network functions are shown to be directly connected to each other; however, it should be understood that these network functions may communicate via routing agents such as Diameter routing agent or message bus.

[0222] exist Figure 19D In the example, connectivity between network functions is achieved through a set of interfaces or reference points. It should be understood that a network function can be modeled, described, or implemented as a set of services invoked by other network functions or services. Invocation of network function services can be achieved through direct connections between network functions, exchanging messages on a message bus, invoking software functions, etc.

[0223] The AMF 172 can connect to RAN 105 via the N2 interface and can be used as a control node. For example, the AMF 172 can be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF can forward user plane tunnel configuration information to RAN 105 via the N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 can generally route and forward NAS packets to / from WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not... Figure 19D As shown in the image.

[0224] SMF 174 can connect to AMF 172 via interface N11. Similarly, SMF 174 can connect to PCF184 via interface N7 and to UPF 176a and 176b via interface N4. SMF 174 can be used as a control node. For example, SMF 174 can be responsible for session management, IP address allocation for WTRU 102a, 102b and 102c, management and configuration of service-oriented rules in UPF 176a and UPF 176b, and generating downlink data notifications to AMF 172.

[0225] UPF 176a and UPF 176b can provide WTRU 102a, 102b, and 102c with access to packet data networks (PDNs) (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and other devices. UPF 176a and UPF 176b can also provide WTRU 102a, 102b, and 102c with access to other types of packet data networks. For example, other networks 112 can be any type of network, such as Ethernet or switched data packets. UPF 176a and UPF 176b can receive service orientation rules from SMF 174 via the N4 interface. UPF 176a and UPF 176b can provide access to packet data networks by connecting to the packet data network via the N6 interface, or by connecting to each other and other UPFs via the N9 interface. In addition to providing access to packet data networks, UPF 176 can also be responsible for packet routing and forwarding, policy and rule enforcement, quality of service processing for user plane services, and downlink packet buffering.

[0226] The AMF 172 can also connect to the N3IWF 199, for example, via the N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via non-3GPP defined radio interface technologies. The AMF can interact with the N3IWF 199 in the same or similar manner as the AMF and RAN 105.

[0227] PCF 184 can be connected to SMF 174 via N7 interface, to AMF 172 via N15 interface, and to Application Function (AF) 188 via N5 interface. N15 and N5 interfaces are not... Figure 19D As shown in the diagram, PCF 184 can provide policy rules to control plane nodes (such as AMF 172 and SMF 174), allowing the control plane nodes to enforce these rules. PCF 184 can send policies for WTRUs 102a, 102b, and 102c to AMF 172, enabling AMF to deliver the policies to WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at WTRUs 102a, 102b, and 102c.

[0228] The UDR 178 can act as a repository for authentication credentials and subscription information. The UDR can connect to network functions, allowing these functions to add, read, and modify data in the repository. For example, the UDR 178 can connect to the PCF 184 via the N36 interface. Similarly, the UDR 178 can connect to the NEF 196 via the N37 interface, and the UDR 178 can connect to the UDM 197 via the N35 interface.

[0229] The UDM 197 can be used as an interface between the UDR 178 and other network functions. The UDM 197 can authorize network functions to access the UDR 178. For example, the UDM 197 can be connected to the AMF 172 via the N8 interface, and to the SMF 174 via the N10 interface. Similarly, the UDM 197 can be connected to the AUSF 190 via the N13 interface. The UDR 178 and UDM 197 can be tightly integrated.

[0230] The AUSF 190 performs authentication-related operations and is connected to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0231] The NEF 196 exposes the capabilities and services of the 5G core network 109 to the Application Function (AF) 188. This exposure can occur on the N33 API interface. The NEF can connect to the AF 188 via the N33 interface, and it can connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0232] Application function 188 can interact with network functions in the 5G core network 109. The interaction between application function 188 and network functions can occur via a direct interface or via NEF 196. Application function 188 can be considered part of the 5G core network 109, or it can be deployed outside the 5G core network 109 by an enterprise with business relationships with the mobile network operator.

[0233] Network slicing is a mechanism that mobile network operators can use to support one or more “virtual” core networks behind the operator’s air interface. This involves “slicing” the core network into one or more virtual networks to support different RANs or different service types running on a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements, such as functionality, performance, and isolation.

[0234] 3GPP has designed the 5G core network to support network slicing. Network slicing is a valuable tool for network operators to support a diverse set of 5G use cases, such as massive IoT, critical communications, V2X, and enhanced mobile broadband, which present extremely diverse and sometimes demanding requirements. Without network slicing, network architectures may lack sufficient flexibility and scalability to efficiently support a wider range of use cases with their own specific performance, scalability, and availability requirements. Furthermore, the introduction of new network services should be made more efficient.

[0235] Refer again Figure 19D In a network slicing scenario, WTRU 102a, 102b, or 102c can connect to AMF 172 via the N1 interface. AMF can logically be part of one or more slices. AMF can coordinate connections or communication between WTRU 102a, 102b, or 102c and one or more UPF 176a and 176b, SMF 174, and other network functions. Each of UPF 176a and 176b, SMF 174, and other network functions can be part of the same slice or different slices. When they belong to different slices, they can be isolated from each other in the sense that they can utilize different computing resources, security credentials, etc.

[0236] Core network 109 can facilitate communication with other networks. For example, core network 109 may include, or communicate with, an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between 5G core network 109 and PSTN 108. For example, core network 109 may include or communicate with a Short Message Service (SMS) service center that facilitates communication via SMS. For example, 5G core network 109 can facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and a server or application function 188. Additionally, core network 170 can provide access to network 112 for WTRUs 102a, 102b, and 102c, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0237] The content described in this article and in Figure 8 The core network entities shown in A, 8C, 8D, and 8E are identified by the names given to these entities in certain existing 3GPP specifications. However, it should be understood that these entities and functions may be identified by other names in the future, and some entities or functions may be merged into future 3GPP specifications (including future 3GPP NR specifications). Therefore, Figure 8 The specific network entities and functions described and illustrated in A, 8B, 8C, 8D and 8E are provided as examples only, and it should be understood that the subject matter disclosed and claimed herein can be embodied or implemented in any similar communication system, whether currently defined or future.

[0238] Figure 19E An example communication system 111 is illustrated, in which the systems, methods, and apparatus described herein can be used. Communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base station gNBs, V2X networks, and / or other network elements. One, several, or all of WTRUs A, B, C, D, E, and F may be outside the coverage area of ​​the access network 131. WTRUs A, B, and C form a V2X group, with WTRU A as the group leader and WTRUs B and C as group members.

[0239] If WTRUs A, B, C, D, E, and F are within the coverage area 131 of the access network, they can communicate with each other via gNB 121 through Uu interface 129. Figure 19EIn the example, WTRUs B and F are shown to be within access network coverage 131. Regardless of whether WTRUs A, B, C, D, E, and F are within or outside access network coverage 131, they can communicate directly with each other via sidelink interfaces such as interfaces 125a, 125b, or 128 (e.g., PC5 or NR PC5). For example, in Figure 19E In the example, WTRU D, which is outside the access network coverage 131, communicates with WTRU F, which is inside the access network coverage 131.

[0240] WTRUs A, B, C, D, E, and F can communicate with RSUs 123a or 123b via Vehicle-to-Network (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F can communicate with V2X server 124 via Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via Vehicle-to-Person (V2P) interface 128.

[0241] Figure 19F This is a block diagram of an example apparatus or device WTRU 102 that can be configured for wireless communication and operation according to the systems, methods, and apparatuses described herein, such as... Figure 19A , 8 WTRU 102 of type B, 8C, 8D, or 8E. For example... Figure 19F As shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that WTRU 102 may include any sub-combination of the aforementioned elements. Furthermore, base stations 114a and 114b and / or the nodes represented by base stations 114a and 114b, such as but not limited to transceiver stations (BTS), Node Bs, site controllers, access points (APs), home Node Bs, evolved home Node Bs (eNodeBs), evolved home Node Bs (HeNBs), evolved home Node B gateways, next-generation Node Bs (gNode-Bs), and proxy nodes, may include... Figure 19F Some or all of the elements described herein.

[0242] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 19F The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0243] The UE's transmit / receive element 122 can be configured to transmit data to a base station (e.g., via air interface 115 / 116 / 117). Figure 19A The base station 114a) transmits or receives signals from it, or transmits or receives signals to or from another UE via air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive signals such as IR, UV, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0244] Additionally, although the transmitting / receiving element 122 is in Figure 19F While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0245] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, or NR and E-UTRA, or to communicate with different RRHs, TRPs, RSUs, or nodes using the same RAT via multiple beams.

[0246] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad / indicator 128. Additionally, the processor 118 can access and store information from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital storage (SD) card, etc. The processor 118 can access information and store data from memory that is not physically located on the WTRU 102, such as on a server hosted in the cloud, on an edge computing platform, or on a home computer (not shown).

[0247] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control that power to other components in the WTRU 102. The power supply 134 may be any suitable device that supplies power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0248] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or as a substitute for information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method.

[0249] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0250] WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or electronic health devices, robots, industrial equipment, drones, and vehicles such as cars, trucks, trains, or airplanes. WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as interconnect interfaces that may include one of the peripheral devices 138.

[0251] Figure 19G This is a block diagram of an exemplary computing system 90. Figure 8 One or more devices from the communication networks shown in A, 8C, 8D, and 8E may be embodied in the computing system 90. These devices include certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other networks 112, or network services 113. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. These computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to perform operations. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 91 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor, distinct from main processor 91, and can perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 can receive, generate, and process data related to the methods and apparatus disclosed herein.

[0252] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path—system bus 80. This system bus connects components within the computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and operating system buses. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0253] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This memory includes circuitry that allows information to be stored and retrieved. ROM 93 generally contains stored data that is unlikely to be modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide address translation functionality, which translates virtual addresses into physical addresses when instructions are executed. The memory controller 92 can also provide memory protection functionality, which isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped by its own process's virtual address space; unless memory sharing is established between processes, the program cannot access memory in another process's virtual address space.

[0254] Additionally, the computing system 90 may include a peripheral device controller 83, which is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0255] Display 86, controlled by display controller 96, is used to display visual output generated by computing system 90. This visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 can be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. Display controller 96 includes the electronic components required to generate the video signals sent to display 86.

[0256] Furthermore, the computing system 90 may include communication circuitry, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to an external communication network or device, such as... Figure 8RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other networks 112 of A, 8B, 8C, 8D, and 8E, to enable computing system 90 to communicate with other nodes or functional entities in those networks. Communication circuitry, alone or in combination with processor 91, can be used to perform the transmit and receive steps of certain means, nodes, or functional entities described herein.

[0257] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions, which execute on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and is accessible by a computing system.

[0258] appendix Table 0.1 – Abbreviations 3GPP Third Generation Partnership Project AI / ML Artificial Intelligence / Machine Learning ACR Application Context Relocation ADAE Application Data Analytics Enablement (A-) ADRF (Application Layer) Analytics Data Repository Functionality AF Application Functions CAPIF General API Framework (A-) DCCF (Application Layer) Data Collection Coordination Function EAS Edge Application Server ECS Edge Configuration Server EDN Edge Data Network EEC Edge Enabler Client EEL Edge Enabler Layer EES Edge Enabler Server FL Federal Learning NRF Network Repository Functionality NWDAF Network Data Analysis Function OAM Operation, Management and Maintenance QoS (Quality of Service) SEAL Service Enabler Architecture Layer SEALDD Service Enabler Architecture Layer Data Delivery UAS Unmanned Aerial Vehicle System UE User Equipment URI (Uniform Resource Identifier) VAL Vertical Application Layer V2X vehicle-to-everything (V2X)

Claims

1. A method for providing artificial intelligence / machine learning (AI / ML) enabling services, the method comprising: Receive one or more provider messages from one or more AI / ML resource / capability providers, the one or more provider messages including one or more descriptions of one or more AI / ML resources or capabilities of the one or more AI / ML resource / capability providers; The AI / ML enabling service stores one or more descriptions of the one or more AI / ML resources or capabilities based on the one or more provider messages; Receive consumer requests from AI / ML service consumers, the consumer requests including the identifier of the AI / ML service consumer, one or more notification conditions and objectives, the required analysis type or one or more service requirements; Based on information associated with the one or more descriptions of the one or more AI / ML resources or capabilities and the consumer request, a service action is determined, the service action including selecting an AI / ML resource / capability provider from the one or more AI / ML resource / capability providers to perform an AI / ML operation; Send a request to the selected AI / ML resource / capability provider to perform one or more AI / ML operations; Receive a response message from the selected AI / ML resource / capability provider, the response message indicating that the one or more AI / ML operations have been performed and including one or more results of the performed AI / ML operations; as well as Send a notification message to the AI / ML service consumer, including the results of one or more AI / ML operations performed.

2. The method of claim 1, wherein the provider message is a registration request or a message in response to a query / request from the AI / ML enabling service.

3. The method of claim 1, wherein the one or more AI / ML resource / capability providers include at least one of AI / ML enabling services, vertical application layer (VAL) entities, application / service enabling layer entities, or core network functions.

4. The method of claim 1, wherein the one or more descriptions of the one or more AI / ML resources or capabilities include at least one of AI / ML data description, AI / ML model description, or AI / ML training / inference capability description.

5. The method of claim 1, further comprising: Receive consumer messages from AI / ML service consumers, the consumer messages including filtering criteria for AI / ML resources or capabilities that the AI / ML service consumers are interested in, wherein the consumer messages are discovery requests or query / subscription requests; A response is sent to the AI / ML service consumer, the response including information associated with AI / ML resources or capabilities of interest to the AI / ML service consumer, wherein the response includes one or more descriptions of one or more AI / ML resources or capabilities of the one or more AI / ML resource / capability providers.

6. The method of claim 1, wherein the AI / ML service consumer is an AI / ML enabling service, a vertical application layer (VAL) entity, or an application / service enabling layer entity.

7. The method of claim 1, wherein the service action includes reselecting a training entity or combining training processes associated with multiple service instances, and reconfiguring the training entity or training data.

8. The method of claim 1, wherein the service action includes reselecting the inference entity or combining a list of notification targets associated with multiple service instances at the inference entity.

9. The method of claim 1, wherein the one or more AI / ML operations include one or more of collecting AI / ML data, training an AI / ML model, updating an AI / ML model, or using an AI / ML model for inference.

10. The method of claim 1, wherein the storage further comprises storing information associated with service instances that are using or will use the one or more AI / ML resources or capabilities of the one or more AI / ML resource / capability providers.

11. The method of claim 1, wherein the consumer request further includes information associated with training data, a model, or one or more AI / ML resource / capability providers specified by the AI / ML service consumer.

12. The method of claim 1, further comprising: Based on the consumer request, an AI / ML service instance profile is generated. The AI / ML service instance profile includes information associated with the consumer request, instance status, context information of the AI / ML service consumer, or information associated with training data, AI / ML models, or AI / ML resource / capability providers among the one or more AI / ML resource / capability providers.

13. An apparatus for providing artificial intelligence / machine learning (AI / ML) enabling services, the apparatus comprising one or more processors and a memory storing instructions, the instructions, when executed by the one or more processors, causing the apparatus to perform the following operations: Receive one or more provider messages from one or more AI / ML resource / capability providers, the one or more provider messages including one or more descriptions of one or more AI / ML resources or capabilities of the one or more AI / ML resource / capability providers; The AI / ML enabling service stores one or more descriptions of the one or more AI / ML resources or capabilities based on the one or more provider messages; Receive consumer requests from AI / ML service consumers, the consumer requests including the identifier of the AI / ML service consumer, one or more notification conditions and objectives, the required analysis type or one or more service requirements; Based on information associated with the one or more descriptions of the one or more AI / ML resources or capabilities and the consumer request, a service action is determined, the service action including selecting an AI / ML resource / capability provider from the one or more AI / ML resource / capability providers to perform an AI / ML operation; Send a request to the selected AI / ML resource / capability provider to perform one or more AI / ML operations; Receive a response message from the selected AI / ML resource / capability provider, the response message indicating that one or more AI / ML operations have been performed and including one or more results of the performed AI / ML operations; and Send a notification message to the AI / ML service consumer, including the results of one or more AI / ML operations performed.

14. The apparatus of claim 13, wherein the provider message is a registration request or a message in response to a query / request from the AI / ML enabling service.

15. The apparatus of claim 13, wherein the one or more AI / ML resource / capability providers include at least one of an AI / ML enabling service, a vertical application layer (VAL) entity, an application / service enabling layer entity, or a core network function.

16. The apparatus of claim 13, wherein the one or more descriptions of the one or more AI / ML resources or capabilities include at least one of an AI / ML data description, an AI / ML model description, or an AI / ML training / inference capability description.

17. The apparatus of claim 13, wherein the AI / ML service consumer is an AI / ML enabling service, a vertical application layer (VAL) entity, or an application / service enabling layer entity.

18. The apparatus of claim 13, wherein the service action includes reselection: The training process that associates a training entity or combination with multiple service instances, and reconfigures the training entity or training data, or Reselect the inference entity or combine a list of notification targets associated with multiple service instances at the inference entity.

19. The apparatus of claim 13, wherein the one or more AI / ML operations include one or more of collecting AI / ML data, training an AI / ML model, updating an AI / ML model, or performing inference using an AI / ML model.

20. The apparatus of claim 13, wherein the storage further comprises storing information associated with service instances that are using or will use the one or more AI / ML resources or capabilities of the one or more AI / ML resource / capability providers.

Images