Content for TS 23.482 Word version: 19.3.0
8.3 ML model training
8.3.1 General
8.3.2 Procedure for ML model training
8.3.3 Information flows
8.4 Support for FL member registration
8.4.1 General
8.4.2 Procedure on FL member registration
8.4.3 Procedure on FL member registration update
8.4.3a Procedure on FL member deregistration
8.4.4 Information flows
8.5 Support for FL events subscription and notification
8.5.1 General
8.5.2 Procedure on subscription for FL related events
8.5.3 Procedure on FL related event notification
8.5.4 Definition of FL-related Events
8.5.5 Information flows
...
...
8.3 ML model training p. 30
8.3.1 General p. 30
This clause describes the procedure for supporting the ML model training by the AIMLE server. The VAL server requests the AIMLE server for the ML model training. VAL server requests the AIMLE server to train a ML model by specifying the type of learning, details about the ML model to be trained or requirements to select a ML model for training and criteria for selecting the members who can participate in the ML model training.
8.3.2 Procedure for ML model training p. 30
Figure 8.3.2-1 illustrates the procedure for AIMLE server to support ML model training based on the request from the VAL server.
Step 1.
The VAL server sends an ML model training request to AIMLE server, requesting to assist in its ML model training. This request consists of ML model information or ML model requirement information, etc.
Step 2.
The AIMLE server checks whether the VAL server is authorized to perform the ML model training request. If no model information is provided but only the model requirement information is provided in step 1, the AIMLE server identifies and selects the appropriate ML model for training based on the ML model requirement information using the procedure as specified in clause 8.11.3.
Step 3.
If the VAL server is authorized, AIMLE server returns the success response, otherwise a failure response indication the reason for failure.
Step 4.
The AIMLE server notifies the VAL server to update the list FL/ML clients selected or de-selected for the ML model training or to share the training output or any errors during the training process.
8.3.3 Information flows p. 31
8.3.3.1 ML model training request p. 31
Table 8.3.3.1-1 describes the information flow from the VAL server to the AIMLE server for requesting the ML model training.
| Information element | Status | Description |
|---|---|---|
| Requestor identity | M | Identity of the VAL server performing the request. |
| Training type | M | Identifies whether the VFL or HFL training to be performed. |
| List of member clients | O
(NOTE 1) | List of member clients or AIMLE client set identifier to be utilized for training the ML model. |
| Member selection criteria | O
(NOTE 1) | Identifies the criteria that needs to be continuously monitored for selecting the member clients (e.g., AIMLE clients in a particular location, member availability duration, new member clients registering with the required capabilities). |
| Number of required AIML clients | O | Indicates the requested number of AIML clients to be selected based on member selection criteria. |
| ML model information | O
(NOTE 2) | Identifies the ML model that has to be distributed to the selected member clients for training. This information consists of the model identifier, address (e.g., a URL or an FQDN) of the ML model file or address of the model repository where the ML model resides. |
| ML model requirement information | O
(NOTE 2) | Identifies the requirement for selecting a model to be trained and this information contains the filtering criteria for selecting the model as specified in Table 8.11.4.1-2. |
| Dataset identifiers | M | Identifier of dataset used to HFL or VFL training. For VFL training, multiple dataset identifiers is specified for different data domains. |
| Number of data samples | O | The number of data samples required for a round of HFL or VFL training. |
| Operational schedule | O | A schedule for when training is to occur. |
| VFL specific parameters | O
(NOTE 3) | Parameters specific to VFL training. |
| > Dataset common features | O
(NOTE 3) | A list of one or more common features is specify for VFL training. Common features can be UE identifiers, AIMLE client identifiers, group identifier, VAL service identifier, area of interest, and VAL service area. |
| > Data domain feature ID lists | O
(NOTE 3) | List of features for each data domain(s) of the datasets at the UE for VFL training. |
| > Feature alignment information | O | Information provided to align features from dataset of different domains for VFL training. Alignment information is also provided for data domain features with ground truth data. |
| > Data labels | O | Ground truth data provided for VFL training. |
| Training objective | O | Identifies the termination condition for the ML model training. Table 8.3.3.1-2 describes the information related to training objective. |
| Members update notification | O | Indicates whether requestor needs to be notified whenever there is update related to new member clients selected or de-selected. |
| Notification Target Address | O | Notification target address (e.g. URL) where the notifications should be sent. |
|
NOTE 1:
At least one of these IE shall be present.
NOTE 2:
At least one of these IE shall be present.
NOTE 3:
These IE shall be present for VFL training.
|
||
| Information element | Status | Description |
|---|---|---|
| Objective Type | M | Identifies the metric to be optimized by the ML model (e.g. accuracy). |
| Target Value | O | Identifies the threshold to be reached for the objective type. |
| Early stopping Criteria | O | Identifies the metric to be used for early stopping. |
| Maximum number of Epochs | O | Identifies the maximum number of training epochs. |
| Acceptable training errors | O | Maximum error acceptable with training. |
| Inference Latency | O | Inference latency requirements for the trained model. |
8.3.3.2 ML model training response p. 33
Table 8.3.3.2-1 describes the information flow of ML model training response from the AIMLE server to the VAL server.
| Information element | Status | Description |
|---|---|---|
| Success response | O
(NOTE) | Indicates that the ML model training request was successful. |
| > ML model training identifier | M | An identifier for the ML model training request. |
| > ML model identifier | O | Identifies the ML model selected by AIMLE server for training. |
| Failure response | O
(NOTE) | Indicates that the ML model training request was failure. |
| > Cause | M | Reason for the failure. |
|
NOTE:
Only one of these information elements shall be present.
|
||
8.3.3.3 ML model training notification p. 33
Table 8.3.3.3-1 describes the information flow of ML model training notification from the AIMLE server to the VAL server.
| Information element | Status | Description |
|---|---|---|
| > ML model training identifier | M | An identifier for the ML model training request the notification is for. |
| List of AIMLE clients | O
(NOTE) | Indicates the list of AIMLE clients selected or de-selected for the ML model training. |
| Training output | O
(NOTE) | Output of training, e.g., ML model parameters for the training. |
| Percentage completion | O | Indicates a completion percentage for the training. |
| Errors list | O
(NOTE) | A list of errors, if any, encountered during training process. |
|
NOTE:
At least one of these IEs shall be present.
|
||
8.4 Support for FL member registration p. 33
8.4.1 General p. 33
This clause provides the procedures for the registration, registration update, and deregistration of candidate FL members in the ML repository which serves as service registry for the FL members undertaking a task related to the ML model lifecycle, such as ML model local training. Candidate FL members can be application layer entities at the server side (e.g., VAL server, AIMLE server), which can potentially be selected as FL clients or FL server for a particular ASP /vertical requirement, or at the client side (e.g. AIMLE client), which can potentially be selected as FL clients. If VAL server or the AIMLE client is the candidate FL member, it registers indirectly via AIMLE server to the ML repository.
8.4.2 Procedure on FL member registration p. 34
Figure 8.4.2-1 illustrates the procedure where the registration of a candidate FL member happens via the ML repository, serving as AIML service registry.
Step 1.
The procedure for AIMLE client to register to ML repository as FL member is introduced in clause 8.7.2.2.
The candidate FL member (e.g., VAL server via AIMLE server or AIMLE server) sends an FL member registration request to the ML repository for registering to the ML repository which acts as the AIML service registry.
Step 2.
The ML repository validates the received request and generates the identity and other security related information for all the FL members listed in the registration request.
Step 3.
The ML repository sends the generated information in the FL member registration response message to the candidate FL member.
8.4.3 Procedure on FL member registration update p. 34
Figure 8.4.3-1 illustrates the procedure where the registration update of a candidate FL member happens via the ML repository.
Step 1.
The procedure for AIMLE client to update its registration to ML repository as FL member is introduced in clause 8.7.2.3.
The candidate FL member (VAL server via AIMLE server or AIMLE Server) sends an FL member registration update request to the ML repository acting as AIML service registry for updating the registration of the FL member.
Step 2.
The ML repository validates the received update request and generates the identity and other security related information for the FL member.
Step 3.
The ML repository sends the generated information in the FL member registration update response message to the candidate FL member.
8.4.3a Procedure on FL member deregistration p. 35
Figure 8.4.3a-1 illustrates the procedure where the deregistration of a candidate registered FL member happens via the ML repository, serving as AIML service registry.
The deregistration may be triggered by the VAL server or AIMLE server in case of an expected or predicted unavailability of the candidate FL member e.g. due to load / energy, access limitation in different VAL service area based on the vertical/ASP requirement.
Such deregistration may be provided by the AIMLE server on behalf of a VAL server e.g. after offboarding of the VAL server from the SEAL platform, or upon termination of the AIMLE/VAL service (FL task).
Step 1.
The procedure for AIMLE client to deregister to ML repository as FL member is introduced in clause 8.7.2.4.
The candidate registered FL member (e.g., VAL server via AIMLE server or AIMLE server) sends an FL member deregistration request to the ML repository for registering to the ML repository which acts as the AIML service registry.
Step 2.
The ML repository validates the received request for all the registered FL members listed in the deregistration request.
Step 3.
The ML repository sends the generated information in the FL member deregistration response message to the candidate registered FL member.
8.4.4 Information flows p. 35
8.4.4.1 General p. 35
The following information flows are specified for supporting the FL member registration and registration update based on clause 8.4.2 and clause 8.4.3.
8.4.4.2 FL member registration request p. 36
Table 8.4.4.2-1 describes information elements for the FL member registration request from the candidate FL member (VAL server, AIMLE server) to the ML repository/registry.
| Information element | Status | Description |
|---|---|---|
| Security information | M | Information for ML repository to validate the registration request. |
| FL member ID | M | The identifier of the candidate FL member. This can be the VAL server ID, the EAS ID, the AIMLE server ID based on which entity is the candidate FL member. |
| FL member supported AI/ML role | M | The supported AI/ML role of FL member which can be used as FL server or FL client. |
| FL member capabilities | O
(see NOTE) | FL member capability information (e.g. ML application type, allowed resource usage level). |
| FL member velocity | O | Indicates the FL member velocity (e.g., mobile or static). |
| FL member Location information | O | Indicates the location information of the UE (e.g., Cell Identity, Tracking Area Identity, GPS Coordinates or civic addresses). |
| FL member Availability schedule | O
(see NOTE) | Availability schedule of the FL member for a certain FL member. |
| Supported ML model ID list | O | The list of ML model IDs for which the FL member can be used. |
| Area of Interest | O | The area of interest (i.e. location co-ordinates) for which the registration applies. |
| Time validity | O | The time validity for the registration of the FL member. |
|
NOTE:
At least one of these shall be present.
|
||
8.4.4.3 FL member registration response p. 36
Table 8.4.4.3-1 describes information elements for the FL member registration response to the candidate FL member (VAL server, AIMLE server) from the ML repository/registry.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result of the registration request (positive or negative acknowledgement). |
| Registration ID | M | The generated ID for the registration. |
8.4.4.4 FL member registration update request p. 36
Table 8.4.4.4-1 describes information elements for the FL member registration update request from the candidate FL member (VAL server, AIMLE server) to the ML repository/registry.
| Information element | Status | Description |
|---|---|---|
| Registration ID | M | Identifier of the existing registration for which the update request applies. |
| Security information | M | Information for ML repository to validate the registration update request. |
| FL member ID | M | The identifier of the candidate FL member for which the update applies. This can be the VAL server ID, the EAS ID, the AIMLE server ID based on which entity is the candidate FL member. |
| Updated registration parameters | M | The updates of the registration parameters. |
| > FL member supported AI/ML role | O
(see NOTE) | The updated supported AI/ML role of FL member which can be FL server, FL client. |
| > FL member Availability schedule | O
(see NOTE) | Updated Availability schedule of the FL member. |
| > supported ML model ID list | O
(see NOTE) | The updated list of ML model IDs for which the FL member can be used. |
| > area of interest | O
(see NOTE) | The updated area of interest for the registration update. |
| > time validity | O
(see NOTE) | The update time validity for the FL member registration update. |
|
NOTE:
At least one of these information elements shall be present.
|
||
8.4.4.5 FL member registration update response p. 37
Table 8.4.4.5-1 describes information elements for the FL member registration update response to the candidate FL member (VAL server, AIMLE server) from the ML repository/registry.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result of the registration update request (positive or negative acknowledgement). |
| Registration ID | O | The generated ID for the new registration based on the update (if needed). |
8.4.4.6 FL member deregistration request p. 37
Table 8.4.4.6-1 describes information elements for the FL member deregistration request from the candidate FL member (VAL server, AIMLE server) to the ML repository/registry.
| Information element | Status | Description |
|---|---|---|
| Registration ID | M | The identity of the registered FL member. |
8.4.4.7 FL member deregistration response p. 37
Table 8.4.4.7-1 describes information elements for the FL member deregistration response to the candidate registered FL member (VAL server, AIMLE server) from the ML repository/registry.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result of the deregistration request (positive or negative acknowledgement). |
8.5 Support for FL events subscription and notification p. 38
8.5.1 General p. 38
This clause consists of the following procedures 1) the subscription for the FL related events in clause 8.5.2 and 2) the event notification procedure in clause 8.5.3.
This capability targets the enhancements to a global ML repository acting as AIML service registry which monitors the status and changes to the availability and capabilities of the FL members. The subscriber can be the AIMLE server or VAL server which requires to get notified on the FL member availability, since this information is vital for enabling the subscriber to perform the FL-related AIML operations (e.g. AIMLE server selecting FL members for a certain FL task). If VAL server is the subscriber, it registers indirectly via AIMLE server for FL-related events.
8.5.2 Procedure on subscription for FL related events p. 38
This procedure, as illustrated in Figure 8.5.2-1, describes the subscription for events related to FL member availability.
Pre-conditions:
- The AIMLE server has the authorization to subscribe for the FL-related events (events described in clause 8.5.4).
Step 1.
The subscriber (AIMLE server or VAL server (via AIMLE server)) sends an FL-related event subscription request to the ML repository to receive notification of FL related events and in particular the availability of FL member for a target area and time.
Step 2.
Upon receiving the event subscription request from the AIMLE server, the ML repository checks for the relevant authorization for the event subscription. If the authorization is successful, the ML repository stores the subscription information.
Step 3.
The ML repository sends an FL-related event subscription response to the subscriber indicating successful operation.
8.5.3 Procedure on FL related event notification p. 38
This procedure describes the event notification procedure for the FL member availability. This can be triggered based on a change at the availability or capabilities of the candidate or selected FL members.
Pre-conditions:
- The subscription procedure in clause 8.5.2 was performed by the AIMLE server or VAL server (via AIMLE server).
- The FL member has registered its capabilities or availability to the ML repository based on the support for FL registration capability.
Step 1.
The ML repository detects a change related to the availability of an FL member and generates events to be consumed by the AIMLE server, based on the notification, or based on a received updated registration from FL member, who has already registered at the ML repository.
Step 2.
For the generated event, the ML repository retrieves the list of corresponding subscriptions.
Step 3.
The ML repository sends FL-related event notification to all entities (e.g., AIMLE servers) that have subscribed for the FL-related event matching the criteria. If a notification reception information is available as part of the FL-related event subscription, then the notification reception information is used by the ML repository to send event notifications to the corresponding AIMLE servers.
Step 4.
The notified subscriber (s) sends an event notification acknowledgement to the ML repository.
8.5.4 Definition of FL-related Events p. 39
The definition of the FL related events is provided in Table 8.5.4-1.
| Events | Events Description |
|---|---|
| Availability changes of FL member | The event type relates to the availability change of a FL member. Such availability change can be an indication of availability or unavailability for a given service area, or for a given ML model ID/profile. |
| FL model information | Information such as accuracy, time schedule and latency for the FL training. Latency is considering the target latency, i.e., when the FL model training shall be completed. |
| FL member load information | The event type relates to the monitoring of the computational load for the requested FL member. Such load can be the estimated (based on measurements) or expected/predicted based on the tasks that the FL member undertakes. This event may be triggered on-demand or can be monitored periodically. |
8.5.5 Information flows p. 40
8.5.5.1 General p. 40
The following information flows are specified for supporting the FL events subscription and events notification based on clause 8.5.2 and clause 8.5.3.
8.5.5.2 FL-related event subscription request p. 40
Table 8.5.5.2-1 describes information elements for FL-related event subscription request from the subscriber (AIMLE server, or VAL server (via AIMLE server)) to the ML repository.
| Information element | Status | Description |
|---|---|---|
| Requestor Identifier | M | The identifier to determine the identity of the requestor entity. This can be either the AIMLE server ID, or AIMLE server ID and VAL server ID. |
| Security Credentials | M | The security credentials of the requestor. |
| Time of validity | M | The time validity for the subscription. |
| ML model information | M | Information of the ML model for, specified in Table 8.11.4.1-2, which the subscription is needed. |
| FL member information | M | Information on the FL member (candidate or selected). |
| >FL member type | O
(NOTE) | The type of FL member which can be an FL server or FL client. |
| >FL member ID | O
(NOTE) | The ID of the entity serving as FL member. This can be used for events where the FL member is known and possibly selected, and the availability needs to be checked. |
| Event Information | M | Information on the FL-related event. |
| > Event ID | O | The identity of the FL-related event (if known by the requestor). |
| > Event type | M | The event type requested, based on the Definition of FL related events (shown in Table 8.5.4-1). |
| Notification endpoint | M | The information of the endpoint for receiving the notifications for the event. |
|
NOTE:
At least one of these shall be present.
|
||
8.5.5.3 FL-related event subscription response p. 40
Table 8.5.5.3-1 describes information elements for the FL-related event subscription response to the subscriber (e.g. AIMLE server or VAL server (via AIMLE server)) from the ML repository.
| Information element | Status | Description |
|---|---|---|
| Result | M | Indicates the success or failure of the event subscription operation. |
| Subscription Identifier | M | The unique identifier for the event subscription. |
8.5.5.4 FL related event notification p. 40
Table 8.5.5.4-1 describes information elements for the FL-related event notification from the ML repository to the requestor (e.g., AIMLE server).
| Information element | Status | Description |
|---|---|---|
| Subscription identifier | M | The unique identifier of the event subscription. |
| Event identifier | M | The unique identifier for the event. For the definition of events, refer to the Table 8.5.4-1 with the list of FL related events. |
| Event related information | M | The event related information (e.g., time at which the event originated or is planned to be executed, location of event). |
| Event content | M | The content of the event information. |
| > List of FL member ID /address | O | The list of the FL members and their addresses. |
| >> FL member enter / leave | O | The indication of an FL member entering or leaving the available list. |
| >> FL member updated capability | O | The update of capabilities for the FL members. |
| >> Time availability of FL member | O | The time period for which the FL member is available. |
| >> Area of interest | O | The area of interest or exact or predicted location for which the event applies. |
8.5.5.5 FL-related event notification acknowledgement p. 41
Table 8.5.5.5-1 describes information elements for the FL-related event notification acknowledgement from the AIMLE server to the ML repository.
| Information element | Status | Description |
|---|---|---|
| Result | M | The positive or negative acknowledgement of the notification reception. |
