R1-2410326
discussion
Discussion on the LS reply to RAN2 on functionality in AI/ML
From Huawei
Summary
This Huawei document discusses the framework for functionality-based Life Cycle Management (LCM) for AI/ML in NR air interface, specifically addressing RAN2 questions on beam management UE-side model functionality reporting. The document contains 16 proposals and 3 observations covering functionality granularity, representation, signaling procedures, and detailed replies to RAN2 questions.
Position
Huawei advocates FOR finer granularity of applicable functionalities (Option 2) rather than coarse use case/sub-use case granularity, enabling better network control and more efficient UE memory usage. They push FOR reusing legacy CSI framework signaling rather than introducing new dedicated signaling, and advocate AGAINST Option 1's 'virtual' CSI report configuration in Step 3 which causes waste of CSI report resources. They strongly support making NW-side additional conditions optional rather than mandatory, allowing UE flexibility in model training approaches.
Key proposals
- Proposal 1 (Sec 2.1): The granularity of the applicable functionality should be a group/combination of conditions/configurations, and multiple applicable functionalities can be activated so that the corresponding CSI processing can run simultaneously
- Proposal 2 (Sec 2.2): An applicable functionality should include three parts - inference configurations (input/output parameters), performance/requirements (target performance, inference timeline, CPU, memory), and applicable associated IDs
- Proposal 3 (Sec 2.3): Deprioritize Option 1 for inference configuration procedure and consider Option 2 and Option 3, where CSI report for inference is only configured by NW in Step 5, consistent with legacy CSI framework
- Proposal 4 (Sec 2.3): NW indicates the functionality along with the inference configuration for the corresponding CSI report in Step 5
- Proposal 5 (Sec 2.3): Signaling to activate a functionality can be achieved by reusing legacy CSI framework signaling to configure/activate/trigger corresponding P-CSI/SP-CSI/A-CSI report
- Proposal 6 (Sec 3.1): For finer granularity functionalities, NW indication of NW-side additional condition is NW implementation irrespective of functionality, while UE can report associated IDs in functionality-specific manner
- Proposal 7 (Sec 3.2): Provision of NW side additional condition is optional, and UE can decide applicable functionalities without NW-side additional condition
- Proposal 8 (Sec 3.2): RAN1 is discussing whether inference related parameters are configured in Step 3 or reported in Step 4, but NW configures CSI report configurations in Step 5 after functionality reporting
- Proposal 11 (Sec 3.3): UE can report functionality content including inference configurations, performance/requirements, and applicable associated IDs in Step 4
- Proposal 12 (Sec 3.4): Inference configuration in Step 5 includes Set B configurations, Set A configurations, type of prediction output, max number of predicted beams, and prediction window configurations
- Proposal 13 (Sec 3.5): Functionality is not activated immediately upon receiving Step 3, regardless of whether inference parameters are configured in Step 3 or reported in Step 4
- Proposal 15 (Sec 3.7): Multiple applicable functionalities can be activated as separate CSI reports so corresponding CSI processing can run simultaneously
- Proposal 16 (Sec 3.8): Functionality activation signaling reuses legacy CSI framework - RRC for P-CSI, MAC CE or DCI for SP-CSI, and DCI for A-CSI