RAN1 / #120 / NR_AIML_air / Verify

Google · 9.1.1

Specification support for beam management · RAN1#120 · Source verification
Claude's delta refined vs RAN1#119
Google refined their reference signal proposal to explicitly support AP-CSI-RS and SSB as Set B reference signals for both BM-Case 1 and BM-Case 2. They added a specific CPU requirement: an inference report for BM-Case 1 must consume 1 eCPU and 1 legacy CPU. They introduced a new definition for predicted RSRP based on a reference transmission power. Their support for separate TCI state pools is preserved, but they added a proposal to trigger aperiodic CSI-RS to reduce latency for unknown TCI states. New work appears on reusing the SCell BFR mechanism for event-triggered performance monitoring reports.
AI-synthesized from contributions · all text is paraphrased
Every position summary on this site is generated by an AI from the actual Tdoc contributions. This page shows you the exact source documents Claude read to produce the summary above, so you can verify it yourself. Click any Tdoc ID to view its detail page, or click "3gpp.org ↗" to read the original on the official 3GPP server.

Contributions at RAN1#120 · 1 doc

R1-2500545 discussion not treated 3gpp.org ↗
AI/ML based Beam Management
Position extracted by Claude
Google proposes supporting AP-CSI-RS and SSB (including Rel-19 on-demand SSB) as Set B reference signals for both BM-Case 1 and BM-Case 2 to align with current deployments. They require an inference report for BM-Case 1 to consume 1 eCPU and 1 legacy CPU, and propose defining predicted RSRP based on a reference transmission power. For TCI activation, Google supports configuring separate TCI state pools for legacy and predicted beams, and triggering aperiodic CSI-RS to reduce latency for unknown TCI states. They propose reusing the SCell BFR mechanism (SR+MAC CE) for event-triggered performance monitoring reports and support performance monitoring relaxation for low-mobility UEs. Finally, they propose configuring the associated ID per CSI report configuration to ensure consistency between training and inference.
Summary
Google presents 26 proposals for ML-based Beam Management in NR, covering beam measurement, reporting, indication, failure recovery, and performance monitoring. The document addresses open issues for both NW-side and UE-side models, specifically focusing on Set A/B reference signal configurations, TCI state handling for predicted beams, and CPU resource allocation for inference.

Prior contributions at RAN1#119 · 1 doc · Nov 18, 2024

R1-2410149 discussion not treated 3gpp.org ↗
AI/ML based Beam Management
Position extracted by Claude
Google advocates FOR comprehensive AI/ML beam management support including both network-side and UE-side models, pushing for flexible reference signal configurations (AP-CSI-RS, SSB), enhanced reporting mechanisms with confidence indicators, separate TCI state pools for AI/ML predictions, and practical implementation considerations like CPU resource management and performance monitoring relaxation. They strongly support Option 1 for inference configuration management to avoid multi-stage RRC configuration latency issues.
Summary
This 3GPP RAN1 technical document from Google presents 27 proposals for AI/ML-based beam management enhancements in 5G NR, covering beam measurement, reporting, indication, failure recovery, and performance monitoring across both network-side and UE-side AI/ML models.
How this was derived
Claude extracted the "position extracted" field above directly from each Tdoc during summarization. For the delta summary at the top, Claude compared Google's consolidated stance at RAN1#120 against their stance at RAN1#119 and classified the change as refined. Always verify critical claims against the original Tdocs linked above.