R1-2409395
discussion
Discussion on AI/ML for beam management
From Huawei
Huawei's prior position on
9.1.1
at
RAN1#118bis
· AI-synthesized, paraphrased
verify sources →
Advocates for pragmatic reuse of existing CSI framework and signaling mechanisms while opposing overly complex new procedures, and strongly supports expanding beam measurement capabilities up to 256 beams with unified solutions across BM-Case 1/2.
Summary
This Huawei Tdoc (R1-2409395) addresses AI/ML for NR Air Interface beam management, presenting 40 proposals and 9 observations across data collection, NW-side and UE-side models, inference, monitoring, and LCM. Key technical stances include supporting larger beam sets (up to 256), reusing legacy TCI timelines for predicted beams, limiting associated IDs to cell-specific scopes, and defining specific CPU/memory handling for UE-side AI/ML functionalities.
Position
Huawei proposes studying mechanisms to support beam sets exceeding 64 resources, either through multiple legacy sets or a single set up to 256 resources. They require the associated ID for UE-side models to be limited to a cell-specific manner to avoid proprietary disclosure and NW burden, and propose applying the ID to a pair of Set A and Set B. Huawei opposes extending Rel-17 TCI state activation for BM-Case 2 future time instances, citing insignificant overhead savings and substantial implementation complexity. They propose reusing existing TCI state timelines for predicted beams and support reporting more than 4 predicted beams (K>4) for UE-side inference. For monitoring, they prefer dedicated CSI report configurations (Option 2) to separate inference and monitoring processes, and propose defining CPU/memory requirements per AI/ML functionality.
Key proposals
- Proposal 1 (Sec 2.1.1): Proposes discussing mechanisms for UE to perform CSI measurements on larger beam sets, either via multiple legacy-sized resource sets or a single resource set with increased size (e.g., up to 256).
- Proposal 3 (Sec 2.2.1): Concludes that L1 signaling can be used for NW-side model monitoring and/or training, extending the inference agreement.
- Proposal 5 (Sec 2.3.1): Supports an adaptive number of reported beams based on a threshold (up to M beams within X dB gap to the largest L1-RSRP), with M>4.
- Proposal 8 (Sec 3.1): Requires indicating the purpose (training, inference, monitoring, non-AI/ML) in CSI-reportConfig for UE-side models to define implied UE behavior.
- Proposal 11 (Sec 3.2.1): Proposes studying the associated ID for UE-side models subject to a cell-specific manner, rather than across a group of cells.
- Proposal 15 (Sec 3.3.1): Proposes reusing existing TCI state definitions/timelines for UE-side models, arguing it does not cause ambiguity for scheduling predicted beams.
- Proposal 16 (Sec 3.3.3): Opposes extending Rel-17 TCI state activation to indicate N TCI states for N future time instances in BM-Case 2 due to insignificant overhead savings and high complexity.
- Proposal 19 (Sec 3.3.4): Supports reporting predicted beam IDs/RSRPs for more than 4 beams (Max K > 4) in one instance to improve accuracy and generalization.
- Proposal 23 (Sec 3.3.5): Proposes enhancing CPU rules for BM-Case 2 to handle long observation windows, suggesting A-CSI-RS may not be applicable due to scheduling delays.
- Proposal 26 (Sec 4.2.1): Defines monitoring types for UE-side models, including event-based reporting for Type 1 Option 2 and fallback decisions for Type 2.
- Proposal 29 (Sec 4.2.3): Proposes using dedicated CSI report configurations for monitoring (Option 2) as a unified solution, separating inference and monitoring processes.
- Proposal 34 (Sec 5.1): Proposes reporting AI/ML-based UE processing requirements per functionality, including CSI processing unit, timeline, and memory storage.
- Proposal 37 (Sec 5.3): Proposes activating AI/ML-based functionalities by reusing signaling to configure/activate/trigger corresponding P-CSI/SP-CSI/A-CSI reports.
- Proposal 40 (Sec 5.4): Proposes reporting supported conditions for UE-side models, including data sample needs, input/output parameters, and target performance/robustness.