R1-2409399
discussion
Discussion on other aspects of the additional study for AI/ML
From Huawei
Huawei's prior position on
9.1.4.2
at
RAN1#118bis
· AI-synthesized, paraphrased
verify sources →
Proposes focusing model identification discussions exclusively on two-sided models while eliminating MI-Option 1, and advocates for Case y as baseline for UE-side training while opposing Case z1 due to cross-vendor collaboration issues.
Summary
Huawei analyzes model identification options for two-sided AI/ML models in NR, proposing to exclude MI-Option 1 as it applies only to one-sided cases. The document details information elements for dataset and model transfers (MI-Options 2 and 3), argues for Case y as the baseline for UE-trained models to avoid cross-vendor burdens, and suggests lowering the priority of UE-side data collection discussions in RAN1.
Position
Huawei argues that MI-Option 1 is inapplicable to the revised WID scope for two-sided models and proposes excluding it from further discussion. For MI-Option 2 and 3, Huawei specifies that model identification relies on the delivery of Dataset IDs or Model IDs alongside their respective data or parameters, with detailed meta-information requirements for quantization and structure. Regarding model transfer Case z4, Huawei presents a technical case against immediate standardization of model structures due to proprietary concerns and performance limits, proposing that partial parameter transfer and Model ID composition be deferred to RAN2. For UE-trained models (Class 2), Huawei opposes the necessity of Case z1, proposing Case y as the baseline to avoid offline cross-vendor collaboration burdens. Finally, Huawei argues that UE-side data collection mechanisms are out of RAN1 scope and proposes lowering the priority of this study item.
Key proposals
- Proposal 1 (Sec 2.1): Proposes excluding further discussion of MI-Option 1 in 9.1.4.2 because it is applicable only to one-sided model cases, whereas the revised WID scope for model identification is limited to two-sided cases.
- Proposal 2 (Sec 2.2): Proposes that for MI-Option 2 (dataset transfer), transmitted information should include model input/label content and meta-information such as dataset ID, size, format, scalability, quantization method, and target performance.
- Proposal 3 (Sec 2.2): Proposes that for MI-Option 2, model identification is achieved when the dataset ID (ID-X) is delivered with the dataset, and the UE reports supported dataset IDs to the gNB for pairing during inference.
- Proposal 4 (Sec 2.3): Proposes that for MI-Option 3 (model transfer), transmitted information should include model parameters and meta-information such as model ID, parameter format, model structure information, and quantization method.
- Proposal 5 (Sec 2.3): Proposes that for MI-Option 3, model identification is achieved when the model ID is delivered together with the model.
- Proposal 6 (Sec 3.1): Proposes that partial parameter transfer for Case z4 be discussed only after progress on standardized model structure, and that Model ID related discussions be handled by RAN2.
- Proposal 7 (Sec 3.2): Proposes assuming Case y as the baseline for model transfer/delivery where the model is trained at the UE side or neutral site, arguing that Case z1 incurs unnecessary cross-vendor collaboration burdens.
- Proposal 8 (Sec 4): Proposes lowering the priority of UE-side training data collection discussions in RAN1, citing that requirements were already provided in Rel-18 LS replies and that mechanisms are out of RAN1 scope.
- Observation 1 (Sec 2.4): Observes that if MI-Option 4 (standardization of reference models) is classified as model identification, the definition of model identification may need to be revisited.
- Observation 2 (Sec 3.1): Observes that aligning model structure for Case z4 requires further study, contrasting offline alignment (cross-vendor burden) with 3GPP specified structure (potential performance limits).