R1-2409585
discussion
Views on additional study for other aspects of AI/ML model and data
From Samsung
Summary
Samsung analyzes model identification and data handling for AI/ML in NR, presenting 13 proposals and 5 observations across model-level management, two-sided model consistency, and data privacy. The document argues that explicit model identification is unnecessary for ensuring training-inference consistency, proposing instead the use of associated IDs for network-side additional conditions, while deprioritizing external data delivery and non-transparent model transfers due to proprietary and cross-vendor collaboration complexities.
Position
Samsung argues that explicit model identification is not required to ensure consistency between model training and inference, proposing instead that the indication of associated IDs for network-side additional conditions is sufficient. They propose studying MI-Option1 for model-level LCM management, including timeline control and processing unit occupancy awareness, while supporting Type B1 identification procedures where the network indicates NW-side additional conditions and the UE identifies compatible models. For functionality-based LCM, Samsung proposes using boundary conditions in UE capability reports to limit complexity without exposing proprietary model details. Regarding data and model transfer, Samsung deprioritizes data delivery to external OTT servers or non-gNB/LMF entities due to privacy and proprietary implementation risks, and deprioritizes non-transparent model transfer Case z1 due to cross-vendor collaboration burdens. Finally, they propose studying Case z4 (parameter transfer for known model structures) and starting model identification studies from MI-Option4 for standardized reference models.
Key proposals
- Proposal 1 (Sec 2.1): Study the necessity of MI-Option1 for model-level management of AI/ML operations at the UE, including timeline management for LCM operations and network awareness of UE processing unit occupancy.
- Proposal 2 (Sec 2.1): Conclude that ensuring consistency on network-side additional conditions between model training and inference does not necessitate model identification; indication of associated IDs is sufficient.
- Proposal 3 (Sec 2.1): Support the indication associated with NW-side additional conditions when datasets are transferred from the network to the UE for AI-Example2-1 of MI-Option2.
- Proposal 4 (Sec 2.1): Consider an additional procedure for model-ID-based LCM with Type B1 identification, where the network provides indicators for NW-side additional conditions and the UE identifies models based on supported configurations.
- Proposal 5 (Sec 2.1): For functionality-based LCM, allow the UE to report the maximum number of simultaneously active functionalities it supports to maintain UE complexity.
- Proposal 6 (Sec 2.1): Use UE capability reports to indicate the number of models run for functionalities within a boundary condition, counting all functionalities within one boundary as 1 or a fixed number.
- Proposal 7 (Sec 2.1): For model-ID based LCM, allow the UE to report the maximum number of simultaneously active models it supports.
- Proposal 8 (Sec 2.1): For MI-Option 4, consider Type A (fully standardized reference model) and Type B1 (UE model compatible with standardized reference model) for model identification via standardization.
- Proposal 9 (Sec 2.1): Allow the UE to indicate supported AI/ML model IDs for a given feature in a UE capability report for MI-Option 4.
- Proposal 10 (Sec 2.1): Deprioritize data collection/delivery from the UE to entities outside the 3GPP network (e.g., OTT servers) or to entities other than gNB and LMF.
- Proposal 11 (Sec 2.1): Deprioritize the study of Case z1 of 3GPP non-transparent model transfer cases as it requires offline cross-vendor collaboration.
- Proposal 12 (Sec 2.1): Study the feasibility and benefits of model parameter transfer for specified model structures from gNB to UE (Case z4).
- Proposal 13 (Sec 2.1): For Case z4 with specified model structure, further study the necessity of model identification starting from MI-Option4.