Content for TS 23.482 Word version: 19.3.0
8.11 ML model management
8.11.1 General
8.11.2 ML model information storage
8.11.3 ML model information discovery
8.11.4 Information flows
8.12 HFL training
8.12.1 General
8.12.2 Procedure
8.12.3 Information flows
...
...
8.11 ML model management p. 59
8.11.1 General p. 59
In this functionality, two prodedures are described in more detail in clause 8.11.2 and clause 8.11.3 accordingly:
- Clause 8.11.2 for ML model information storage;
- Clause 8.11.3 for ML model information discovery.
8.11.2 ML model information storage p. 60
8.11.2.1 AIMLE server-initiated ML model information storage p. 60
Figure 8.11.2.1-1 illustrates the procedure of the AIMLE server-initiated ML model information storage.
Pre-condition:
- The AIMLE server has either received application specific model details from AIML consumer or produced analytics model.
Figure 8.11.2.1-1: AIMLE server-initiated ML model information storage
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The AIMLE server sends a ML model information storage request to the ML repository to store an ML model. The ML model included in the request is one trained by the ML repository consumer or its information is provisioned to the ML repository consumer. The request contains information elements as described in Table 8.11.4.1-1. The request message may contain Indication of continuous training and continuous training model parameter.
Step 2.
Upon receiving the ML model information storage request, the ML repository verifies if the AIMLE server is authorized to store the ML model identified by ADAE Analytics ID and/or list of the allowed vendors provided within the ML model information attribute. If the AIMLE server is authorized, the ML repository processes the request and records information of the ML model (e.g., by creating a ML model profile). The ML repository sends an ML model information storage response to the AIMLE server with an identifier of the created ML model profile.
8.11.2.2 AIMLE consumer-initiated ML model information storage p. 60
Figure 8.11.2.2-1 illustrates the procedure of AIMLE consumer-initiated ML model information storage.
Pre-condition:
- AIMLE consumer such as AIMLE client or VAL server has ML model or address to ML model.
Figure 8.11.2.2-1: AIMLE consumer-initiated ML model information storage
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
An AIMLE client or a VAL server sends an ML model information storage request to an AIMLE server to store an ML model in the ML repository. The request includes the information elements as described in Table 8.11.4.1-1.
Step 2.
The AIMLE server sends an ML model information storage request as described in clause 8.11.2.1 to store the ML model in the ML repository.
Step 3.
The AIMLE server sends an ML model information storage response to the AIMLE client or VAL server with the information elements as described in Table 8.11.4.2-1.
8.11.3 ML model information discovery p. 61
Figure 8.11.3-1 illustrates the procedure of ML model information discovery.
Pre-condition:
- Either AIMLE consumer has requested to discover ML model or AIMLE server decides to discover model for training.
Step 1.
The AIMLE server sends an ML model information discovery request to the ML repository. The request contains information elements as described in Table 8.11.4.3-1.
Step 2.
Upon receiving the ML model information discovery request, the ML repository verifies if the requestor is authorized to discover the ML model(s) identified by the ML model ID. Further, it verifies whether the requestor is present in the list of allowed vendors or not. If the ML repository consumer is authorized, the ML repository processes the request and discovers the model based on ML model ID, ADAE Analytics ID, Base Model ID, and/or ML model interoperability information.
If the discovery request is for transfer of learning, the ML repository identifies all candidate models matching the domain and required accuracy level.
The ML repository sends the response message to the ML repository consumer. The response includes information of the discovered ML model.
After the AIMLE server receives the response from the ML repository, the AIMLE server determines whether the received ML model satisfy the ML model requirement of the AIMLE server. If not, the AIMLE server needs to continuously train the model to satisfy the ML model requirement based on the AIMLE server capability of supporting continuous training and ML model profile (Indication of continuous model training, continuous training model parameter).
8.11.4 Information flows p. 62
8.11.4.1 ML model information storage request p. 62
Table 8.11.4.1-1 describes the information flow from the AIMLE server to the ML repository or from the AIMLE client/VAL server to the AIMLE server as a request for the ML model information storage.
| Information element | Status | Description |
|---|---|---|
| Requestor Identity | M | The identity of the requestor performing the request. |
| Security Credentials | O
(NOTE 1) | Security credentials of the requestor performing the request. |
| ML model | O
(NOTE 2) | The ML model to be stored in the ML repository. |
| ML model address | O
(NOTE 2) | The address (e.g., a URL or an FQDN) of the ML model file. |
| ML model information | M | Provides information of the ML model, as described in Table 8.11.4.1-2. |
|
NOTE 1:
This information is needed if the requestor is at the VAL service provider domain.
NOTE 2:
At least one of these information elements shall be provided.
|
||
| Information element | Status | Description |
|---|---|---|
| ML model identifier | M | An identifier for the ML model. |
| ADAE Analytics ID | O | Represents ADAE analytics ID for which the model can be used. |
| ML model size | O | Indicates the size of the ML model. |
| ML model source identifier | O | The identifier of ML model source (e.g., VAL server ID, VAL client ID) that stored the model in the ML repository. |
| VAL service ID(s) | O | Identify the VAL service ID(s). |
| Domain | O | Specifies domain for which the model can be used (e.g., for speech recognition, image recognition, video processing, location prediction, etc.). |
| List of allowed vendors | O
(NOTE 1) | Indicates which vendors that are allowed to use the ML model and thereby also are interoperable to the model. |
| ML model interoperability information | O
(NOTE 1) | Represents the vendor-specific information that conveys, e.g., requested model file format, model execution environment, input/output parameters of the ML model, etc. The encoding, format, and value of ML Model Interoperable Information is not specified since it is vendor specific information, and is agreed between vendors, if necessary for sharing purposes. |
| ML Model phase | O
(NOTE 1) | Represents the ML model phase, e.g., in training, trained, re-training, deployed. |
| > Observed performance | O
(NOTE 2) | Provides information on the performance of the model e.g. accuracy, or application-specific performance metrics (if ML model is in trained or deployment phase). |
| > Training information | O
(NOTE 2) | If the ML model is in trained or deployed phase: Information on the data that has been used to train the model (e.g. data sources, volume, freshness), and the base model ID in case of Transfer Learning. |
| > Indication of continuous model training | O | Indicates whether the model can be continuously trained or not. |
| > Continuous model training parameter | O | Parameters required for continuous model training. |
| ML model storage and discovery requirements | O
(NOTE 1) | Represents the requirements for the ML repository for the ML model storage and discovery. |
| > Storage duration | O | Represents the ML model storage duration time. When the storage duration time is expired, the stored ML model and the related information shall be deleted. |
| > Security and access requirements | O | Represents the information on security requirements for storing the ML model information and the ML model access requirements (e.g., publicly available, private use only, or available for the list of VAL server IDs or VAL client IDs, time period and location access). If the access requirement is private use only, then the model is not discoverable by other consumers. |
| ML model usage requirements | O | Represents the requirements for using the ML model (e.g. for inference or for training). The requirements are used by the AIMLE server to determine whether an AIMLE client is capable of using the model based on comparing the requirements with information in the AIMLE client profile in Table 8.7.3.2-2. |
|
NOTE 1:
At least one of these information elements shall be provided.
NOTE 2:
This IE is included only if trained ML model is available.
|
||
8.11.4.2 ML model information storage response p. 65
Table 8.11.4.2-1 describes the information flow from the ML repository to the AIMLE server or from the AIMLE server to the AIMLE client/VAL server as a response for the ML model information storage request.
| Information element | Status | Description |
|---|---|---|
| Result | M | Indicates success or failure of the request. |
| ML model profile identifier | O | The identifier of the ML model profile created as a result of a successful ML model storage request. |
| Information element | Status | Description |
|---|---|---|
| ML model profile identifier | M | The identifier of the ML model profile. |
| AIMLE server identifier | M | The identifier of the AIMLE server that stored the ML model. |
| ML repository identifier | M | The identifier of the ML repository where the ML model is stored. |
| ML model information | M | The information about the ML model, as described in Table 8.11.4.1-2. |
| ML model retrieval endpoint | O | Represents the ML model retrieval endpoint (e.g., URL, URI, IP address and Port) that can be used to download the ML model. |
8.11.4.3 ML model information discovery request p. 65
Table 8.11.4.3-1 describes the information flow from the AIMLE server to the ML repository as a request for the ML model information discovery.
| Information element | Status | Description |
|---|---|---|
| Requester Identity | M | The identity of the ML repository consumer performing the request. |
| Filtering criteria | M | Represents the filtering criteria, which can be any of the ML model information as in Table 8.11.4.1-2. |
8.11.4.4 ML model information discovery response p. 65
Table 8.11.4.4-1 describes the information flow from the model repository to the AIMLE server as a response for the ML model information discovery request.
| Information element | Status | Description |
|---|---|---|
| Successful response | O
(NOTE 1) | Indicates that the request was successful. |
| > ML model profile list | O
(NOTE 2) | Represents the ML model profile(s) of the discovered list of ML models, as described in Table 8.11.4.2-2. |
| >> ML model profile ID | M | Represents the ML model profile ID of the ML model profile. |
| > ML model list | O
(NOTE 2) | Represents the ML model(s) of the discovered list of ML models. |
| >> ML model ID | M | Represents the ML model ID of the ML model. |
| > Indication of continuous model training | O | Indicate whether the model needs to be continuously trained or not. |
| Failure response | O
(NOTE 1) | Indicates that the request failed. |
| > Cause | O | Indicates the failure cause. |
|
NOTE 1:
Only one of these information elements shall be provided.
NOTE 2:
Only one of these information elements shall be provided.
|
||
8.12 HFL training p. 66
8.12.1 General p. 66
AI/ML training is a highly iterative process and is performed over many training rounds. In the case of federated and distributed learning, the training is performed with many AIMLE clients. Due to the repetitive nature of AI/ML training, the AIMLE server can be configured to manage the training process over multiple training rounds for VAL servers. Note that the HFL training procedure supports horizontal federated learning, distributed learning, transfer learning, and split AI/ML.
The following clauses specify procedures, information flows, and APIs to support HFL training.
8.12.2 Procedure p. 66
Pre-conditions:
- AIMLE client discovery and selection have been performed.
- Datasets are available and prepared for AI/ML training at the AIMLE clients. The datasets are assigned identifiers for use in HFL training.
Step 1.
An AIMLE server receives an ML model training request from a VAL server as described in clause 8.3.2. If the AIMLE server determines to use HFL training, the procedure continues to step 2.
Step 2.
The AIMLE server retrieves the indicated ML model using the ML model retrieval procedure as described in clause 8.1.
Step 3.
For the HFL training, the AIMLE server performs AIMLE client selection using the AIMLE client selection criteria or a list of AIMLE clients provided in step 1. If AIMLE client selection criteria are provided in step 1, then the AIMLE server continuously monitors and selects AIMLE clients for the HFL training. If a list of AIMLE clients is provided in step 1, the AIMLE server selects the provided AIMLE clients for the HFL training.
Step 4.
Based on the AIMLE client set determined in step 3, the AIMLE server checks with the selected AIMLE clients for their capability and participation in the HFL training as described in the clause 8.10.
Step 5.
The AIMLE server configures training schedule for each of the AIMLE client and sends a HFL training subscription request with information as described in Table 8.12.3.1-1.
Step 6.
Each AIMLE client sends a HFL training subscription response with information as described in Table 8.12.3.2-1. If the AIMLE client is not able to grant the subscription (e.g., is not able to perform the training), the AIMLE client sends a response with a failure status and the procedure skips to step 8.
Step 7.
Each AIMLE client performs local training using the configured AI/ML model, model parameters, and the prepared local data associated with the dataset identifier for the specified number of samples according to the operational schedule.
Step 8.
Upon completion or due to errors in the training, each AIMLE client sends a HFL training notification to the AIMLE server. The notification includes information as described in Table 8.12.3.3-1. The AIMLE client provides an VAL service ID for the HFL training operation.
Step 9.
If errors were encountered, the procedure skips to step 10.
If training was successful, the AIMLE server aggregates (e.g. averages) the model parameters received from the AIMLE clients.
If the training schedule is not complete (e.g., there are remaining training rounds), the AIMLE server configures the next set of training schedules and steps 3 to 8 are repeated for the next training round.
When the training schedule has been exhausted (e.g. there are no remaining training round) and if configured, the AIMLE server makes a ML model information storage request as described in clause 8.11.2 to store the AI/ML model in the ML repository.
Step 10.
The AIMLE server sends a ML model training notification to the VAL server as described in clause 8.3.2.
8.12.3 Information flows p. 68
8.12.3.1 HFL training subscription request p. 68
Table 8.12.3.1-1 shows the request sent by the AIMLE server to AIMLE clients for the HFL training subscription procedure.
| Information element | Status | Description |
|---|---|---|
| Requestor identifier | M | The identifier of the requestor. |
| AI/ML model and model parameters | M | Information about the AI/ML model and model parameters for use in HFL training. |
| Dataset identifier | M | The dataset identifier associated with the dataset used for HFL training. |
| Number of data samples | M | The number of data samples required for a round of HFL training. |
| Operational schedule | O | A schedule for when training is to occur. |
| Notification settings | O | Settings for how often to send notifications providing status of HFL training. For example, periodic, event- triggered (e.g. based on percentage completion), upon completion of each training round. |
8.12.3.2 HFL training subscription response p. 68
Table 8.12.3.2-1 shows the response sent by AIMLE clients to the AIMLE server for the HFL training subscription procedure.
| Information element | Status | Description |
|---|---|---|
| Status | M | The status for the subscription request: success, fail. |
| Subscription ID | O | An identifier for the subscription only if the status is success. |
| VAL service ID | M | The VAL service identifier for the AIMLE HFL training operation. |
8.12.3.3 HFL training subscription notification p. 68
Table 8.12.3.3-1 shows the notification sent by AIMLE clients to the AIMLE server for the HFL training subscription procedure.
| Information element | Status | Description |
|---|---|---|
| Status | M | Status for the request: success, fail. |
| VAL service ID | M | The VAL service identifier for the AIMLE HFL training operation. |
| HFL training output | M | ML model parameters from HFL training. |
| Errors list | O | A list of errors encountered during a HFL training round. |
| Timestamp | O | A timestamp for the notification. |
