R1-2500089
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-2500089) addresses open issues for AI/ML-based beam management in NR, presenting 40 proposals and 8 observations across data collection, inference, and performance monitoring. The document argues for expanding CSI-RS resource set sizes beyond the legacy limit of 64 to support larger beam sets (up to 256) and defines specific mechanisms for NW-side and UE-side model training, inference, and monitoring. It also details requirements for associated ID applicability, TCI state handling, and UE processing capabilities.
Position
Huawei proposes expanding CSI-RS resource set sizes to up to 256 beams to support AI/ML training and inference, rejecting legacy limits of 64. They require the associated ID for UE-side models to be strictly limited within a single cell to prevent proprietary disclosure and reduce NW management burden. Huawei opposes extending Rel-17 TCI state signaling for BM-Case 2 future time instances, arguing the overhead savings are insignificant compared to the implementation complexity. They define a specific Beam Accuracy Indicator (BAI) metric based on a 'Top-M/K' accuracy state and propose discontinuous CPU occupation rules to handle long observation windows in BM-Case 2. Additionally, they propose separate CPU counting for AI/ML versus legacy CSI reporting and introduce a memory occupancy alignment mechanism to manage UE storage constraints.
Key proposals
- Proposal 1 (Sec 2.1.1): Proposes enabling UE to perform CSI measurements on larger beam sets (up to 256 resources) via multiple legacy-sized resource sets or a single increased-size resource set.
- Proposal 4 (Sec 2.2.2): Proposes two higher-layer data formats for NW-side model data collection: Type A (all L1-RSRPs) and Type B (beam info + L1-RSRPs), allowing NW to pair input/label by implementation.
- Proposal 11 (Sec 2.3.3): Requires the associated ID for UE-side models to be limited to applicability within a single cell to avoid NW burden and proprietary disclosure risks.
- Proposal 13 (Sec 2.3.3): Proposes providing the associated ID in CSI-ReportConfig applicable to a pair of Set A and Set B, configured in the CSI-reportConfig of Set B for inference/training.
- Proposal 16 (Sec 3.1.2): Proposes reusing existing TCI state definitions/timelines for UE-side models, arguing it does not cause ambiguity for gNB scheduling of predicted beams.
- Proposal 17 (Sec 3.1.3): Opposes extending Rel-17 TCI state activation to indicate N future time instances for BM-Case 2, citing insignificant overhead savings and high implementation complexity.
- Proposal 20 (Sec 3.3.3): Supports reporting predicted Top-K beam information along with prediction probability, using differential reporting for probability across K>1 beams.
- Proposal 22 (Sec 3.3.4): Proposes enhancing CPU rules for BM-Case 2 to allow discontinuous CPU occupation over long observation windows to avoid overcalculation.
- Proposal 26 (Sec 4.2.2): Defines the Beam Accuracy Indicator (BAI) accurate state as 'Top-M/K': all Top M measured beams are among the Top-K predicted beams.
- Proposal 32 (Sec 4.3.3): Proposes a procedure to pair prediction instances with monitoring resources by finding the latest inference report no later than the monitoring report and selecting the 'closest' monitoring resource.
- Proposal 34 (Sec 5.1.1): Proposes that overall CPU be separately counted between legacy CSI reporting and AI/ML-based CSI reporting, but shared among AI/ML functionalities.
- Proposal 38 (Sec 5.1.2): Proposes a memory occupancy alignment mechanism where UE does not update an AI/ML CSI report if unoccupied memory cannot support the required storage.
- Proposal 40 (Sec 5.2.2): Proposes that UE report performance/requirement info in Step 4, including target performance/robustness, required timeline, CPU, and memory storage.