3GPP TSG RAN WG1 #120-bis                                                           R1-2501797
Wuhan, China, April 7th – 11th, 2025

Source:	vivo
Title:	Specification support for AI CSI prediction 
Agenda Item:	9.1.3
Document for:	Discussion and Decision

Conclusions
We have the following observations for this meeting:
at least for 60km/h, or when the proportion of high-speed data collected is high, significant performance loss can be caused by the mismatch in terms of TXRU virtualization mapping model between training and the inference data.
When the user distribution ratio is 8:2, the SGCS loss of different TXRU virtualization mappings in the generalization evaluation case2 ranges from -5.6% to -9.4% in generalization performance case2; 
When the user distribution ratio is 100% outdoor, the SGCS loss of different TXRU virtualization mappings in the generalization evaluation case2 ranges from -13.0% to -44.4%.
When the user distribution ratio is 100% outdoor, the SGCS loss of different TXRU virtualization mappings in the generalization evaluation case3 ranges from -3.7% to -14.6%.
At the system-level simulation evaluation level, the generalization of the model for different TXRU virtualisation mappings has a more severe performance degradation at higher speeds, even after using the model with mixed data.
When the user distribution ratio is 100% outdoor, the UE average throughput loss of different TXRU virtualization mappings in the generalization evaluation case3 ranges from -6.3% to -27.3%.
When the user distribution ratio is 100% outdoor, the UE 5% throughput loss of different TXRU virtualization mappings in the generalization evaluation case3 ranges from -15.5% to -38.3%.

We have the following proposals for this meeting:
At least TXRU mapping is identified as one NW-side additional condition which will have significant impact on generalization performance.
Follow the solution based on associated ID as BM use case to address the consistency issue of training and inference for UE-side model.
If data collection is configured using CSI framework, it does not have any report to the NW, and it does not occupy CPU.
Separate processing unit pools for AI based CSI and legacy CSI for quantifying AI-based CSI processing
Define a maximum total number of simultaneous AI and non-AI CSI reports in UE capability report in addition to the legacy CPUs and AI CPUs. All CSI reports can be reported only if all the conditions are met, including not exceeding legacy CPUs, not exceeding AI CPUs and not exceeding such maximum total number of simultaneous AI and non-AI CSI reports.
For CSI priorities, Pnon-AI>PAI≥Pmonitoring
For AIML functionality switching/activation, consider the following steps for defining timeline:
Step 1: loading model to AI engine (e.g., APU/CPU/GPU)
Example 1: Loading model from flash storage to AI engine 
Example 2: Loading model from Global memory to AI engine 
Example 3: model has been loaded in AI engine memory 
Step 2: Initialization and scheduling of AI resources in AI engine
Step 3: running the model based on the input data
Step 4: return output results
Proposal: for AIML functionality switching/activation, consider the following value range for defining timeline in step1/3:
Support SGCS as the performance metric for CSI prediction performance monitoring.
Performance monitoring metric (SGCS) is calculated between the precoding vectors of the predicted channel and real channel. 
For N_M monitored DD units in one inference, where 1<=N_M<=N4, separate N_M metrics are reported in one monitoring report.
Prioritize type3 and type1 over type2
A dedicated CSI report configuration is configured for monitoring which is associated to the inference configuration. Each monitoring RS occasion is linked to an inference occasion. Details follow the mechanism defined for AI beam management Case 2.
How to ensure the inference results used to calculate KPI are ready at UE no later than the CSI reference resource for monitoring needs specification support. One simple solution is to restrict that the start symbol of the inference CSI report appears no later than the CSI reference resource for monitoring.
For CSI prediction inference report based on SP CSI-RS or AP CSI-RS, extend the active resource counting time for the inference report to the end of the associated monitoring report to reflect the extra buffering size.

3GPP TSG-RAN WG1 Meeting #RAN 120b	R1-2501848
Wuhan, China, 07-11 Apr, 2025

Agenda Item:	9.1.3	
Source:	TCL
Title:	Discussion on CSI prediction
Document for:	Discussion and Decision 

 

Conclusions
This contribution presents our views on AI-based CSI prediction. We have the following proposals:

: For data collection for training, aperiodic CSI-RS resource configuration should not be supported. 
: For data collection for training, the model input and the ground-truth CSI can be obtained based on a periodic and semi-persistent CSI-RS resource. 
: For data collection for training,  the NW can configure a CSI-ReportConfig with the reporting quantity set to ‘none’. 
:For CSI prediction using UE-side model, dynamically update the number of predicted CSI should be supported.   
: Whether the CPU should be shared or separately counted between legacy CSI reporting and AI/ML-based CSI reporting depends on the UE capability. 
: The processing unit should be subject to shared counting among AI/ML related features or functionalities.  
: For CSI prediction using UE-side model, CSI processing criteria and timeline should be further discussed for different stages of model operation.
: For performance monitoring, it is proposed to support using SGCS as a performance metric to measure the level of similarity between the predicted CSI and the ground truth.
: For CSI prediction using the UE-side model, Type 3 should be used as a baseline, and the definition and configuration of performance metrics need further discussion.
: For CSI prediction using the UE-side model, the periodic or semi-persistent CSI-RS resource can be used for both model inference and performance monitoring simultaneously. 
: For CSI prediction using the UE-side model, support real-time monitoring of inference result.     
: For CSI prediction using the UE-side model, support periodic, semi-presistent, and aperiodic reporting the performance metric(s), performance monitoring output, or ground truth CSI(s), if supported.  
:For performance monitoring, support UE reporting of performance metric(s) based on event-driven mechanisms.

3GPP TSG RAN WG1 #120bis		R1-2501860
Wuhan, China, 07th – 11th April 2025

Agenda Item:     9.1.3
Source:	Spreadtrum, UNISOC
Title:	             Discussion on AIML for CSI prediction
Document for:	Discussion and decision

Conclusion 
In this contribution, we provide our opinions on standard impacts of CSI prediction.
Proposal 1: For CSI prediction, associated ID can be used to ensure consistency between training and inference.
Proposal 2: For CSI prediction, associated ID can be configured within CSI framework.
Proposal 3 : Regarding the data collection at UE side for CSI prediction with UE-side AI/ML model, study the potential specification impact (if any) to initiate/trigger data collection from RAN1 point of view by considering the following options as a starting point 
Option 1: data collection initiated/triggered by configuration from NW 
Option 2: request from UE for data collection 
FFS: details
Proposal 4: gNB should indicate the association between prediction CSI-RS and the ground-truth CSI-RS for performance monitoring.
Proposal 5: Support the overall CPU separately counted between legacy CSI reporting and AI/ML-based CSI reporting, and counted among AI/ML related features/functionalities.
Proposal 6: Regarding CSI prediction with UE-sided model, support performance monitoring Type 1 and Type 3 with intermediate KPI, e.g., SGCS, as performance metric.
Proposal 7: Regarding CSI prediction with UE-sided model, deprioritize performance monitoring Type 2.
Proposal 8: For performance monitoring, both periodic trigger and event trigger can be considered.

3GPP TSG RAN WG1 #120bis	R1-2501918
Wuhan, China, April 7th–11th, 2025
Title:                   Discussion on specification support for AI CSI prediction
Source:              ZTE Corporation, Sanechips
Agenda item:     9.1.3
Document for:   Discussion/Decision

Conclusion
Overall, we have the following proposals for AI CSI prediction.
For monitoring metric if performance monitoring 1/3 is supported:
Observation 1: The performance metric at least compromises the configuration of the monitoring samples (i.e.,  and ) and the weights (i.e., ).
Proposal 1: For definition of the performance metric for AI/ML based CSI prediction, for configuration of the monitoring samples (i.e.,  and ) used to calculate the performance metric, at least support the following,
Configure the domain on which to collect the samples, including frequency domain, temporal domain or spatial domain. Then configure the sampling method on the domain to collect the samples.
FFS on unified sampling method across temporal/frequency/spatial domain.
Proposal 2: For type 1/3 performance monitoring, down select the configuration of the weights (i.e., ) from one of the following,
Equal to 1/N, where N is the total number of monitoring samples;
Equal to 1/N’ for first N’ monitoring samples, and equal to 0 for the rest, where N’≤N. 
Observation 2: For type 1/3 performance monitoring, the complexity for performance metric is directly influenced by the product of the number of time instances, the number of the frequency domain resources, the number of transmitting ports and the number of receiving ports.
Observation 3: The SGCS-based performance metric and NMSE-based performance metric has similar complexity if the monitoring samples are vectors (or matrices) with the same dimension.
Proposal 3: For type 1/3 performance monitoring, support SGCS-based performance metric.
Proposal 4: For type1/3 performance monitoring, configure the full-port channel matrix on each configured frequency-domain resource as a monitoring sample for both the predicted channel and the ground truth channel, support at least one of the following for complexity reduction,
Reduced resources: configure a full-port/reduced-port channel matrix on each/subset configured frequency-domain resource for each/subset temporal-domain resources as a monitoring sample for both the predicted channel and the ground truth channel.
Reduced dimensions: configure linear/non-linear transform for the full-port channel matrix on each configured frequency-domain resource as a monitoring sample.
do not support SVD based vectors as monitoring samples.
Proposal 5: For type 1/3 performance monitoring, support performance metric feedback in dedicated reporting field configured by CSI report.
Proposal 6: For type 1/3 performance monitoring, support performance metric calculation based on raw received data, such as RSRP.

For CPU/timeline related specification design:
Proposal 7: For CSI prediction, for inference, support separately counted CPU between legacy CSI reporting and AI/ML based CSI reporting.
Proposal 8: For AI/ML based CSI prediction, for dedicated AI/ML PU, support sharing PU as a starting point. 
FFS on the spec impact for separate PU
Proposal 9: For CSI prediction using UE-side model, support reuse the legacy CSI processing timeline for inference as a starting point.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2501923
Wuhan, China, April 7th – April 11st, 2025

Agenda Item:	9.1.3
Source:	Ericsson
Title:	AI/ML for CSI prediction
Document for:	Discussion, Decision
1 

Conclusion
In the previous sections we made the following observations: 
Observation 1	For UE-sided CSI prediction use case, signaling and procedures for functionality-based LCM can largely reuse the framework being discussed and specified for the UE-sided beam management use cases, when applicable.
Observation 2	For UE-sided CSI prediction use case, signaling and procedures for data collection can largely reuse the framework being discussed and specified for the UE-sided beam management use cases, when applicable.
Observation 3	For UE-sided CSI prediction use case, for data collection, there is no need of specifying assistance information for categorizing the data.
Observation 4	Without separate configuration of CSI-RS resources for training data collection for model input and ground-truth CSI, it is not always possible to train a model that corresponds to a supported CSI report configuration for inference, e.g., model inference using aperiodic CSI-RSs for CMR.
Observation 5	Reusing the legacy CSI-RS resource configuration may result in either high triggering overhead (e.g., AP triggering of multiple CSI-RS resource bursts) or waste of resources (e.g., CSI-RS are transmitted but will not be measured or used for creating training data samples) for training data collection for CSI prediction using UE-sided model.
Observation 6	For training a model that is used for model inference with a burst of AP CSI-RS measurements as input, enhancement is needed to reduce CSI-RS signaling overhead.
Observation 7	For Type 1 and Type 3 performance monitoring, which is based on UE reporting performance metrics or performance monitoring output to the NW, the quality of the UE reported performance metrics or monitoring output shall be testable in RAN4.
Observation 8	Type 3 performance monitoring (i.e., UE reporting monitoring output based on performance metrics and ranges according to configured thresholds) can be considered as equivalent to type 1 performance monitoring (i.e., UE reporting quantized performance metrics).
Observation 9	For UE-side ground-truth label based performance monitoring, the CSI-RS configuration designed for data collection for model training can be reused for data collection for intermediate KPI based performance monitoring.
Observation 10	Compared to the CSI-RS configuration for training data collection, for monitoring data collection for UE-side ground-truth label based performance monitoring, the NW may configure the CSI-RS resource set corresponding to the prediction time window with a smaller size to save overhead.
Based on the above observation and the proposal for training data collection, we propose the following:
Observation 11	For UE-side SGCS estimator based performance monitoring, the CSI-RS configuration designed for data collection for model training can be reused for training the SGCS estimator.
Observation 12	The legacy CSI reporting configuration framework can be reused for supporting fallback configuration, by defining the fallback feature as a prerequisite for the AI CSI prediction feature.
Observation 13	It is up to UE implementation on whether to use dedicated AI hardware or reusing the hardware resources for legacy non-AI based CSI reporting to generate an AI based CSI report.
Observation 14	For AI/ML based CSI reporting features, the inference latency for generating CSI report may be shortened compared to legacy CSI reporting due to dedicated hardware and better parallelization for CSI processing, while model loading or model switching at U, when needed, may introduce additional delay for CSI reporting.
Observation 15	The processing timeline and AI-CPU counting for CSI performance monitoring (CSI-PM) report depends on how a performance monitoring report is configured and triggered, as well as how it is calculated.

Based on the discussion in the previous sections we propose the following:
Proposal 1	Support separate configurations of CSI-RS resource(s) for measurements for model input and CSI-RS resource(s) for measurements for ground-truth CSI
Proposal 2	For UE-sided CSI prediction use case, at least for training data collection, support indication of the association between CSI-RS resources used for measurements in an observation window to create a model input and CSI-RS resource(s) used for measurements in a prediction window to create a ground-truth label.
Proposal 3	For UE-sided CSI prediction use case, at least for training data collection, support configuration of a pair of CSI-RS resource sets, where
a.	The first CSI-RS resource set consists of K CSI-RS resources, with K>1, where the measurements on the K CSI-RS resources are used for creating a model input
b.	The second CSI-RS resource set consists of N4 CSI-RS resources, with N4>=1, where the measurements on the N4 CSI-RS resources are used for creating a ground-truth label associated to the model input
c.	The pair of CSI-RS resource sets are configured in a same CSI report configuration, but with different resource configuration IDs.
d.	Reuse the candidate values for K and N4 as specified for Rel-18 “typeII-Doppler-r18” codebook.
Proposal 4	Do not support AP CSI-RS resource for training data collection, due to excessive overhead.
Proposal 5	For CSI prediction using UE-side model, for data collection for training, For CSI-RS resource type for CMR, support periodic/semi-persistent CSI-RS burst configuration
a.	The first periodic/semi-persistent CSI-RS burst is for measurements for model input
b.	The second periodic/semi-persistent CSI-RS burst is for measurements for ground truth CSI
Proposal 6	For performance monitoring for CSI prediction use case with UE side model, Type 2 based monitoring is not supported.
Proposal 7	For performance monitoring for CSI prediction use case with UE side model, support using “typeII-Dopper-r18” as the ground-truth format for calculating the intermediate KPI.
Proposal 8	For CSI prediction use case with UE sided model, only support SGCS as intermediate KPI.
Proposal 9	For a given layer  and prediction instance , and data sample , SGCS can be defined as
Proposal 10	For performance monitoring for CSI prediction use case with UE side model, an intermediate KPI per monitoring data sample is defined as the SGCS per MIMO layer per prediction instance, between the predicted CSI and the ground-truth label, both represented in the format of “typeII-Doppler-r18” codebook.
Proposal 11	For performance monitoring for CSI prediction use case with UE side model, support defining performance metrics as
	Option 1: Intermediate KPI per sample
	Option 2: Statistics of the intermediate KPI over multiple samples in a monitoring window
Proposal 12	For performance monitoring for CSI prediction use case with UE side model, support defining monitoring output as
	Option 1: An intermediate KPI range indicator based on configured threshold(s), indicating a range of the Intermediate KPI of a monitoring data sample.
	Option 2: An intermediate KPI statistics range indicator based on configured threshold(s), indicating a range of the statistics of the intermediate KPI over multiple samples in a monitoring window.
Proposal 13	For performance monitoring for CSI prediction use case with UE side model, support UE reporting monitoring output as
	Option 1: An intermediate KPI range indicator based on configured threshold(s), indicating a range of the Intermediate KPI of a monitoring data sample.
	Option 2: An intermediate KPI statistics range indicator based on configured threshold(s), indicating a range of the statistics of the intermediate KPI over multiple samples in a monitoring window.
Proposal 14	For the CSI prediction use case, for UE-side ground-truth label based performance monitoring, support configuration of a pair of CSI-RS resource sets, where
a.	The first resource set consists of K CSI-RS resources, with K>1, where the measurements on the K CSI-RS resources are used for creating a model input
b.	The second CSI-RS resource set consists of n CSI-RS resources, with 1<=n<=N4, where the measurements on the n CSI-RS resources are used for creating a ground-truth label associated to the model input
c.	The pair of CSI-RS resource sets are configured in a same CSI report configuration, but with different resource configuration IDs.
d.	Reuse the candidate values for K and N4 as specified for Rel-18 “typeII-Doppler-r18” codebook.
Proposal 15	For UE-side SGCS estimator based performance monitoring, reuse the CMR configuration for model inference for UE reporting performance monitoring output.
Proposal 16	Reuse legacy CSI reporting framework for performance monitoring output reporting, by introducing new values for parameter reportQuantity in the CSI-ReportConfig IE.
Proposal 17	For UE-side SGCS estimator based performance monitoring, support configuring UE reporting the estimated monitoring output and predicted CSI in the same CSI report.
Proposal 18	RAN1 discuss and align on the assumptions of UE implementation for AI based CSI reporting first, before discussing the detailed solutions for the CSI processing criteria and timeline issues.
Proposal 19	If dedicated AI hardware will be used at least for some AI-based CSI reporting, then, support separate processing unit pools (i.e., legacy CPU pool and AI-CPU pool) between CSI reporting generated using legacy CPU and CSI reporting generated using AI-CPU.
Proposal 20	If a UE can use different types of process unit pools for different AI based CSI reporting features, then, support UE indicating the type of process unit pool (i.e., legacy CPU pool and AI-CPU pool) for CSI processing for an AI-based CSI reporting feature.
Proposal 21	If dedicated AI hardware will be used at least for some AI-based CSI reporting, specify a new type of CSI processing unit, AI-CPU, whose design principle follows that of the legacy CPU, including
a.	The AI-CPU resource pool is shared among AI based CSI reporting features
b.	UE indicates the number of supported simultaneous AI-based CSI calculations via UE capability reporting
c.	Define the number of occupied AI-CPU and the occupation time for an AI based CSI report based on the report configuration (e.g., reportQuantity, CSI report time domain behavior, measurement resource configuration, etc.)
d.	Priority based CSI report dropping due to lack of sufficient un-occupied AI-CPUs
Proposal 22	If dedicated AI hardware will be used at least for some AI-based CSI reporting, or for defining the CSI processing timeline of an AI-based CSI reporting feature, support the following
	A shortened processing timeline for the CSI report (except for the initial CSI reporting occasion) of an AI-based CSI reporting feature, comparing to the corresponding legacy non-AI based CSI report feature.
	An additional delay, , can be introduced in the CSI processing timeline for the initial CSI reporting occasion of an AI-based CSI reporting feature to account for latency introduced by model switching.
o	FFS: Definition of the initial CSI report of an AI-based CSI reporting feature.
Proposal 23	Reuse the legacy framework regarding active CSI-RS resource and port counting for AI CSI prediction use case.

4 

3GPP TSG RAN WG1 Meeting #120-bis	R1-2501931
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.1.3	
Source:	Futurewei
Title:	Discussion on CSI Processing Unit
Document for:	Discussion and decision 

Conclusions
In this contribution, we present our views on specification support for AI/ML-based CSI prediction, focusing on the discussion of CSI processing unit. Based on the discussions in the previous sections we propose the following: 

Observation 1: AI/ML-based CSI reporting needs both legacy CSI processing resources and AI/ML-specific processing resources.
Observation 2: For AI/ML-based CSI reporting, the needed legacy CSI processing part can share CPU with legacy CSI reporting.
Observation 3: The AI/ML engines / hardware on the UE are likely shared among different AI/ML-based features on the UE.
Observation 4: Separating the CPU counting for legacy and AI/ML-based CSI reporting provides a more accurate, flexible, and manageable approach to handling the computational demands of this new technology. It aligns with the potential for dedicated AI/ML processing hardware, facilitates better resource management and prioritization, enables more informative UE capability reporting, and supports efficient sharing of AI/ML resources within the UE. 
Observation 5:  Supporting the sharing of AI/ML-based computing resources among different AI/ML features and functionalities is a more efficient, flexible, and scalable approach. It optimizes resource utilization, potentially reduces power consumption, simplifies UE capability reporting, and aligns with industry trends in AI hardware design. Counting the resources of this shared pool separately from legacy CPU usage provides a clearer understanding of the processing demands of AI/ML-based operations, facilitating better network management and configuration.
Proposal 1: Support to separate CPU Counting for Legacy and AI/ML-based CSI Reporting, i.e., legacy CPU and AI/ML-based CPU are from different resource pools.
FFS: How the basic unit of AI/ML-based CSI Reporting is defined.
Proposal 2: Support the sharing of AI/ML-based computing resources among different AI/ML features and functionalities.
Proposal 3: Adopt a new/updated timeline for model inference for the AI/ML-based counting approach of CPU and model inference processing resource.

3GPP TSG-RAN WG1 Meeting #120-bis	R1- 2501939
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.3
Source:	NVIDIA
Title:	Specification support for AI-enabled CSI prediction
Document for:	Discussion
1	

Conclusion
In the previous sections, we discuss general aspects of specification support for AI-enabled CSI prediction and make the following observations:
Observation 1: Inconsistency of training/inference arises when using data generated from stochastic channel models for training an AI/ML based CSI prediction model, while deploying this trained AI/ML model for inference in the field.
Observation 2: Network digital twin with ray tracing can be used to generate data for the training of the AI/ML model for CSI prediction to ensure consistency across training and inference.
Based on the discussion in the previous sections we propose the following:
Proposal 1: The inference of one-sided AI/ML model for CSI prediction can be performed at either gNB or UE. Besides studying CSI prediction at UE side, companies are encouraged to study CSI prediction at gNB side to understand the potential gains of performing CSI prediction at gNB side vs. UE side.
Proposal 2: Conclude that there is a need for consistency of training/inference in AI/ML-based CSI prediction.
Proposal 3: Specify solutions to ensure consistency of training/inference for AI/ML-based CSI prediction.
Proposal 4: RAN1 to study post-deployment performance monitoring mechanisms to detect performance degradation and non-compliance to guarantee satisfactory performance of AI/ML-based CSI prediction in the field.

3GPP TSG-RAN WG1 Meeting #120-bis	R1-2501945
Wuhan, China, April 07-11, 2025

Agenda Item:	9.1.3
Source:	KT Corp
Title:	Discussions on AI/ML for CSI prediction
Document for:	Discussion and Decision 
1	

Conclusion
The proposals made in this contribution are summarized below: 

For Type 1 and Type 3 performance monitoring, support the use of SGCS and define SGCS at least on a per-slot basis to capture performance trends over  slots.
For Type 1 and Type 3 performance monitoring, support configurable time-domain granularity to balance overhead and accuracy of CSI predictions over  slots.
For Type 1 performance monitoring, support the configuration of a threshold to quantify the accuracy of AI-based CSI prediction, enabling simplified reporting.
For Type 3 performance monitoring, support reporting mechanisms that effectively capture variations and patterns in performance metric values across  slots, with minimal overhead and without compromising accuracy.
For Type 1 and Type 3 performance monitoring, support UE-initiated reporting to enable proactive notifications while minimizing signaling overhead.

3GPP TSG RAN WG1 #120bis		R1-2501948
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.3.2
Source:	Google
Title:	ML based CSI prediction
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided discussion on AI/ML based CSI prediction. Based on the discussion, the following proposals are provided.
Proposal 1: Support to reuse the inference configuration procedure for AI/ML based BM for AI/ML based CSI prediction to maintain the consistency of training and inference with regard to the supported/applicable functionalities for AI/ML based CSI prediction.
Proposal 2: Support Type 1 performance monitoring for CSI prediction based on a unified framework as AI/ML based beam prediction
The performance monitoring is an optional UE feature
Proposal 3: Support to reuse the framework for performance monitoring configuration for AI/ML based BM for AI/ML based CSI prediction, i.e.,
Support the NW configures one CSI report configuration for the inference of the AI/ML based CSI prediction, and configure another CSI report configuration for the monitoring of the AI/ML based CSI prediction which is linked to the CSI report configuration for the inference
The UE calculates the performance monitoring metric based on the inference results from the CSI report configuration for the inference and the ground-truth results from the CSI report configuration for the monitoring
Proposal 4: Support SGCS as the metric for performance monitoring. 
Proposal 5: Support the NW configures separate CSI-RS resource sets for inference and monitoring
The CSI-RS can be periodic, semi-persistent or aperiodic
Proposal 6: Support the NW-triggered performance monitoring results report
Event-triggered performance results report should be deprioritized
Proposal 7: Support to report the performance monitoring results by UCI
Proposal 8: Support to configure aperiodic CSI-RS for data collection
Proposal 9: Do not support to configure separate CSI-RS for model input and model output for data collection
Proposal 10: Support the UE to report the UE capability for the preferred number of consecutive transmission occasions and intervals for the CSI-RS resources for data collection
Proposal 11: Support to configure the data collection window
CSI-RS for data collection is transmitted in the data collection window
CSI-RS for data collection is not transmitted outside the data collection window
Proposal 12: Support a CSI prediction taking 1 processing unit for AI/ML (e.g., eCPU) and 1 CPU
Proposal 13: For multiple AI/ML functionalities, support the UE to report which of the following options the UE supports
Option 1: Separate models for different AI/ML functionalities
The processing units are not shared for different AI/ML functionalities
Option 2: Common model for one inference for some AI/ML functionalities, e.g., CSI prediction, CSI compression or positioning
The processing units are shared for different AI/ML functionalities
N processing units are required for the inference for N AI/ML functionalities
Option 3: Common model for simultaneous inference for some AI/ML functionalities, e.g., one model can be used to generate the inference results for both CSI prediction and CSI compression, or for both CSI prediction and positioning
The processing units are shared for different AI/ML functionalities
1 processing unit is required for the inference for N AI/ML functionalities

3GPP TSG RAN WG1 #120bis                                          R1-2501970
Wuhan, China, April 7th – 11th, 2025

Source: 	CATT
Title:	Specification support for AI/ML-based CSI prediction
Agenda Item:	9.1.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss the specification support for AI/ML-based CSI prediction. The observations and proposals are summarized as follows.
Observation 1: For CSI prediction use case, the configuration of various tilt angles at network side has negligible impact on the performance.
Observation 2: For CSI prediction use case, the configuration of various TXRU mapping at network side has negligible impact on the performance.
Proposal 1: AI/ML-based CSI reporting occupies both legacy CPU and new types of processing unit. The CPU counting for legacy CSI reporting and AI/ML-based CSI reporting shares the same CPU pool.
Proposal 2: Support to introduce new Processing Unit type(s) dedicated to AI/ML-based CSI processing, which is separately counted from legacy CPU pool. The new Processing Unit type(s) should be shared among CSI related AI/ML features/functionalities.
Proposal 3: For AI/ML based CSI reporting, timeline should be updated considering at least model inference delay.
Proposal 4: For AI/ML based CSI reporting, whether a different timeline is needed when functionality switches/activates is based on UE capability.
Proposal 5: For CSI report of AI/ML-based CSI prediction, reuse legacy framework for active CSI-RS resource and port counting.
UE reports the {Max # of Tx ports in one resource, Max # of resources, total # of Tx ports} for AI/ML-based CSI report
 UE reports the scaling factor for active resource counting of AI/ML-based CSI report
Proposal 6: For UE side AI/ML-based CSI processing, UE should report the model complexity or UE capability related information for determining the occupied new type(s) of Processing Units.
Proposal 7: Study how to extend the priority rule to determine the priority between AI based CSI report and non-AI CSI report, or different AI based CSI reports. 
Proposal 8: For CSI prediction using UE-sided model, the procedure of applicable functionality reporting for AI/ML-based beam management excluding associated ID can be reused.
Proposal 9: For inference report of UE-sided CSI prediction, support to distinguish AI/ML-based CSI report from legacy CSI report with the following options:
Option 1: introduce a new report quantity;
Option 2: introduce an identifier in the CSI report configuration.
Proposal 10: On UE side CSI prediction, support SGCS as the performance metric.
Proposal 11: For performance monitoring of CSI prediction, when calculating the SGCS at UE side, for the format of predicted CSI and ground-truth CSI, support the following:
For predicted CSI, using 'typeII-Doppler-r18' as the format;
For ground-truth CSI, using ground-truth eigenvector or 'typeII-Doppler-r18' as the format.
Proposal 12: For Type 3 performance monitoring of CSI prediction, discuss the reported content with the following options:
Option 1: Performance metric for each layer/slot interval;
Option 2: Performance metric for specific layer(s)/slot interval(s);
Option 3: The average performance metric over multiple layers/slot intervals.
Proposal 13: For performance monitoring of CSI prediction using UE-sided model, support Type 3 performance monitoring, with Type 1 performance monitoring considered as a special case of Type 3.
Proposal 14: On Type 1 and Type 3 performance monitoring of AI/ML-based UE side CSI prediction, both network configured reporting and event-triggered reporting can be considered.
For network configured reporting: periodic, semi-periodic, or aperiodic reporting can be configured;
For event-triggered reporting: the specific event can be defined by reference to beam failure event.
Proposal 15: On performance monitoring of UE side CSI prediction, Type 2 performance monitoring is deprioritized.
Proposal 16: For Type 1 and Type 3 performance monitoring of UE side CSI prediction, support to reuse CSI framework for configuration for monitoring report:
Configure a dedicated CSI report for performance monitoring, and the ID an inference report is configured in the monitoring report.
Proposal 17: For Type 1 and Type 3 performance monitoring, support the following options for configuration of monitoring resource:
Option 1: Reuse the resource configured in inference report;
Option 2: Configure dedicated resource(s) for monitoring in the monitoring report.
Proposal 18: For CSI prediction using UE-sided model, for data collection for training, only support periodic and semi-persistent CSI-RS.
Proposal 19: For CSI prediction using UE-sided model, for data collection for training, support the following options for RS configuration:
Option 1: Configure a single resource in the CSI report configuration;
Option 2: Configure two separate resources in the CSI report configuration.
Proposal 20：For CSI prediction using UE-sided model, for data collection for training, UE can request the specific RS configuration for data collection.
Proposal 21: For CSI prediction using UE-sided model, for data collection for training, an indication can be configured in the CSI report with report quantity set to “none”.
Proposal 22: For CSI prediction use case, conclude that there is no need to ensure consistency between training and inference regarding antenna down tilt and TXRU mapping configuration at network side.

3GPP TSG RAN WG1 #120bis	R1-2502072
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.1.3
Source:	NEC
Title:              	Discussion on specification support for CSI prediction
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on consistency between training and inference for CSI prediction with UE-sided model. Moreover, we provide our views on the upcoming normative works. Specifically, we have the following observations and proposals:
Observation 1: While AP CSI-RS resource can work, it would introduce additional unnecessary signaling overhead compared to P/SP CSI-RS resource.
Proposal 1: For resource configuration for data collection for training, at least support the following:
Configure single P/SP CSI-RS resource(s) used for measurements for model input and measurements for ground-truth CSI.
Proposal 2: For CSI report configured for data collection for training, reportQuantity can be configured as ‘none’.
Proposal 3: Support enhanced CSI-RS configurations based on the CSI variation point.
Proposal 4: Support multiple CSI configuration timing sets in CSI measurement configuration.
Proposal 5: Support multiple CSI periodicities in CSI report configuration.
Proposal 6: For P/SP CSI report for inference, support to configure observation window and prediction window.
Proposal 7: For CSI prediction, the CSI reporting periodicity may be updated autonomously upon reaching a significant point of variation (determined by time, location or distance).
Proposal 8: Performance monitoring Type 1 and 3 should be supported.
Proposal 9: SGCS/NMSE per layer (or rank) should be considered to guide NW in configuration of allowed RI(s) for inference report.
Proposal 10: For reporting of monitoring metric, the following manners should be supported:
Reporting per sample.
Reporting per set of samples (or samples within a monitoring window).
Proposal 11: For calculation of (reported) monitoring metric, the following options can be considered:
For reporting per sample, the (reported) monitoring metric may be:
Option 1-1: range of calculated SGCS/NMSE.
Option 1-2: indication reflecting the comparison result between the calculated SGCS/NMSE and a threshold.
For reporting per set of samples, the (reported) monitoring metric may be:
Option 2-1: information about statistical (e.g., mean) value of SGCSs/NMSEs corresponding to the set of samples.
Option 2-2: information about the number (or proportion) of ‘correct samples’ in the set of samples, wherein the ‘correct sample’ can be defined as one whose corresponding SGCS is higher than a threshold (or NMSE is lower than a threshold).
Observation 2: If the inference results derives from an inference report linked with the monitoring report, the inference results may encounter the issue of being unavailable.
Proposal 12: Calculation and reporting of the performance metric (e.g., SGCS/NMSE) and the monitoring metric should be based on valid monitoring instance, rather than invalid monitoring instance.
FFS: how to define ‘valid monitoring instance’.
Proposal 13: Multiple reportConfigIDs of model inference reports can be associated with a single reportConfigID of performance monitoring.
Proposal 14: Support using the same CSI-RS resource for monitoring and inference if monitoring resource is P CSI-RS resource or SP CSI-RS resource.
Proposal 15: Study how to refine the performance monitoring procedure when the target timing of predicted CSI is not aligned with the timing of corresponding ground-truth CSI.
Proposal 16: Support common and shared AI/ML processing units among AI/ML related features/functionalities to reflect general UE capability of AI/ML operations, at least for AI/ML use cases in physical layer.
Proposal 17: Support CPUs separately counted between legacy CSI reporting and AI/ML-based CSI reporting. The CPUs used for inference can be named as ACPUs. 
Proposal 18: AI/ML based CSI reporting occupies one set of CPUs and the other set of ACPUs. And UE only updates an AI/ML CSI report if both conditions on CPU and ACPU are satisfied.
Proposal 19: Counting of processing units should be discussed separately for CSI report for inference and CSI report for monitoring.
Proposal 20: For CSI prediction, study CPU occupy timing for the observation window or measurement time instances.
Proposal 21: CSI computation time for the predicted CSI should consider inference delay.
Proposal 22: For model switching, model selection and model update, if the input or/and output (e.g., observation window length, the number of measurement time instance, prediction window length, the number of future time instances) of the new AI/ML model change, UE is necessary to report the change(s) to NW.

3GPP TSG RAN WG1 #120bis   	                              R1-2502100
Wuhan, China, April 7th – 11st, 2025
Agenda item:		9.1.3
Source:		LG Electronics
Title:			Discussions on CSI prediction
Document for:	Discussion and Decision

Conclusion
In this contribution, it is discussed on issues related to functionality-based LCM and consistency between training and inference for AI/ML based CSI prediction. Based on the discussion, we propose followings. 
Observation #1: For AI/ML based CSI prediction, further enhancement on both CSI processing criteria () and timeline (Z/Z’) needs to be considered.
The required  and (Z/Z’) is determined based on the UE capability.
Observation #2: Type 2 monitoring via legacy CSI reporting may be supported by spec transparently.
Observation#3: Regarding gNB antenna tilt angles, for generalization Case 2, generalization performance is achieved. 
Observation#4: Regarding TXRU mapping, for generalization Case 2, marginal loss is observed. 
Proposal #1: For training data collection purpose, aperiodic CSI-RS resource is not supported.
Proposal #2: For configuring the resource for training data collection, CSI-ReportConfig can used for configuring the resources for data collection purpose without CSI report.
Introduce new reportConfigType-r19 with “none” 
Proposal #3: CPU should be separately counted between AI/ML-based CSI reporting and legacy CSI reporting.
 per model can be reported via applicable report.
Reuse Rel-18 framework for active CSI-RS resource and port counting.
Proposal #4: In Rel-19, only BM and CSI use cases are considered to share the same CPU pool.
Proposal #5: If performance monitoring type 1 or 3 is supported, support SGCS as the monitoring metric over NMSE for CSI prediction monitoring.
The reported value range is X to 1 with Y step size.
FFS on X, Y values
Proposal #6: For performance monitoring type 1 and 3, support the definition of SGCS as

where  is for prediction instance index, s is subband index,  is layer index,  and  is eigenvector of predicted CSI and ground truth CSI of n-th prediction instance s-th SB l-th layer, respectively.
N4, S and R can be controlled by NW 
Proposal #7: Support performance monitoring type3.
Proposal #8: For CSI prediction using UE-sided model, conclude that specification support is not needed to ensure consistency between training and inference with respect to gNB antenna tilt angles.

3GPP TSG RAN WG1 Meeting #120bis	R1-2502117
Wuhan, China, April 7th – 11th, 2025

Source:	Fujitsu
Title:	Discussion on specification support for CSI prediction
Agenda item:	9.1.3
Document for:	Discussion and Decision

Conclusion

In conclusion, we have the following observation and proposals on CSI prediction.
Proposal 1:
Regarding LCM for AI/ML based CSI prediction with UE side model, the LCM design for BM Case-2 with UE side model should be reused as much as possible.
Proposal 2:
For AI/ML based CSI prediction with UE side model, the TDCP reporting could be used to facilitate the determination of applicable functionalities.
Proposal 3:
For CSI prediction using UE-side model, for CSI processing criteria and timeline, at least for inference,
The CPU should be separately counted between legacy CSI reporting and AI/ML-based CSI reporting
The CPU pool should be shared among AI/ML related features/functionalities
The UE could report the number of occupied CPUs for each AI/ML functionality
The memory limitation should be considered when updating the AI/ML-based CSI reports, and additional processing time for loading an AI/ML functionality into memory needs to be considered when switching/activating AI/ML functionalities
Observation 1:
For CSI prediction using UE-side model, performance monitoring Type 2 can’t be spec transparent. The following issues should be addressed with spec change.
The same rank value should be guaranteed between the predicted CSI and the ground truth CSI.
The same layer ordering should be guaranteed between the predicted CSI and the ground truth CSI. Or the UE should report the layer ordering information of the predicted CSI and the layer ordering information of the ground truth CSI.
Higher resolution codebook is required for SGCS calculation at the NW side. And the same codebook resolution should be guaranteed between the predicted CSI and the ground truth CSI.
Proposal 4:
For AI/ML based CSI prediction with UE-side model, performance monitoring Type 1 and Type 3 should be prioritized.
Proposal 5:
For CSI prediction using UE-side model, regarding the performance metric for performance monitoring Type 1 and Type 3,
NMSE is preferred for performance monitoring Type 1
SGCS is preferred for performance monitoring Type 3
Proposal 6:
For performance monitoring Type 1 and Type 3, the performance metric calculation should be averaged over multiple measurements during a time window.
Proposal 7:
Regarding performance monitoring for CSI prediction,
Periodic/semi-persistent CSI-RS should be supported, and aperiodic CSI-RS is not needed.
Dedicated resource configuration is not needed. The periodic/semi-persistent CSI-RS resource for inference could also be used for performance monitoring.
Dedicated CSI report could be configured to report the performance metric if performance monitoring Type 3 is supported.
Proposal 8:
Regarding training data collection for AI/ML based CSI prediction with UE side model, aperiodic CSI-RS is not needed.
Proposal 9:
Regarding training data collection for AI/ML based CSI prediction with UE side model, RAN1 to further discuss whether the reporting is via Layer-1 signaling or higher layer signaling.

3GPP TSG RAN WG1 #120bis			R1-2502151
Wuhan, China, April 7th – 11th, 2025

Source: 	CMCC
Title:	Discussion on AI/ML for CSI prediction
Agenda item:	9.1.3
Document for:	Discussion & Decision

Conclusions
In this contribution, we discussed AI/ML based CSI prediction, and the following proposal are made.
Proposal 1: For CSI prediction using UE-side model, the general signalling procedure of applicable functionality reporting agreed for the BM use case excluding associated id part can be reused. 
Option A) in step 3 as a baseline
FFS: option B) in step 3
Proposal 2: For the definition of performance metric in Type 1 performance monitoring, there might be two alternatives to further study:
Alt1: Calculation or comparison outcome based on the performance metric
Alt2: Recommended LCM decision to NW
Proposal 3: Support Type 3 performance monitoring for AI/ML based CSI prediction.
Proposal 4: Support SGCS as the intermediate KPI for AI/ML based CSI prediction.
Proposal 5: Support SGCS is separately calculated for each layer (e.g., for K layers, K SGCS values are derived respectively, and comparison is performed per layer) for AI/ML based CSI prediction.
Proposal 6: Support SGCS can be averaged across multiple RE/subbands for AI/ML based CSI prediction.
Proposal 7: Support SGCS is reported for each time instance for AI/ML based CSI prediction.
Proposal 8: Suggest taking the following definition of SGCS for AI/ML based CSI prediction:
The definition of SGCS for layer k for prediction instance l can be expressed below: 

where  is the jth eigenvector of the target CSI at resource unit i. k is the layer and l is the prediction instance.  is the jth output vector of the output CSI of resource unit i. N is the total number of resource units.   denotes the average operation over multiple samples.
Proposal 9: For CSI prediction, the CSI related parameters in Rel-18 can be reused with modification to adapt AI/ML-enabled CSI prediction, e.g. the parameters about measurement window, reporting window. 
Proposal 10: For CSI prediction using UE-side model, support the CPU is separately counted between legacy CSI reporting and AI/ML-based CSI reporting.
Proposal 11: For CSI prediction using UE-side model, support the Processing Unit is shared counted among AI/ML based beam prediction and AI/ML based CSI prediction.
Proposal 12: For CSI prediction using UE-side model, support to adjust the timeline for inference, i.e. the value of Z and Z’ can be modified.
Proposal 13: For CSI prediction using UE-side model, Not support to introduce a different timeline when functionality switches/activates.
Proposal 14: For CSI prediction using UE-side model, the legacy framework for active CSI-RS resource and port counting in Rel-18 CSI prediction can be reused.
Proposal 15: For CSI prediction using UE-side model, for data collection for training, separate CSI-RS resource(s) used for measurements for model input and CSI-RS resource(s) used for measurements for ground-truth CSI can be configured separately.
Proposal 16: For CSI prediction using UE-side model, for data collection for training, CSI report configuration is not needed.

3GPP TSG RAN WG1 #120bis	R1-2502195
Wuhan, China, Apr. 7th – 11th, 2025

Source:	Lenovo
Title:	Specification support for CSI prediction
Agenda Item:	9.1.3
Document for:	Discussion and Decision

Conclusion
This contribution addressed the scope of AI/ML-based specification support, as well as some aspects on training and inference consistency for UE-sided AI/ML-based CSI prediction for Rel-19 WI. We have the following observations:
From an implementation perspective (with respect to input/output format), the Rel-16 eType-II CB at  and the Rel-18 eType-II CB are identical, with the discrepancy being the underlying algorithm for CSI computation, in addition to the corresponding CMR and CSI reference resource.
In order to enable the support of CSI prediction via Rel-16 eType-II CB, enhancements similar to those made for Rel-18 eType-II CB at  would be needed, causing redundancy in the specification.
Type 3 monitoring implies that the processing of the performance metric for a model adaptation decision is pursued at the network side, whereas for Type 1 monitoring the UE computes an auxiliary recommendation based on the measured performance metric to assist the network with the model adaptation decision.
For UE-based CSI prediction, both the observation window and the prediction window are network configured.
Evaluation is needed of training/inference consistency under UE-sided CSI prediction due to variations in NW-side additional conditions, e.g., TXRU virtualization and gNB antenna tilt/panning, in addition to environment conditions, e.g., scenario and UE speed.
For UE-sided AI/ML-based CSI prediction, training the model with various UE speed values that are equal to or exceed the UE speed values associated with inference process leads to negligible performance degradation compared with a scenario in which the UE speed for inference matches that of the training dataset points.
Maintaining training/inference consistency via model training at the network side and transferring the model to the UE side incurs significant challenges in model transfer.
Maintaining training/inference consistency via signaling information corresponding to NW-side additional conditions may be challenging in case of a large number of additional condition parameters/values and combinations, and in case of generalized models that are trained with dataset points corresponding to a mixture of different additional conditions.
Model identification is simple to implement but requires implicit/implementation-based approaches to match the training and inference processes.
For CSI prediction Type 1 monitoring, output may include: (i) No model change, (ii) CSI parameter(s) update, (iii) Model switching, and (iv) Fallback to non-AI/ML scheme.
For CSI prediction Type 2 monitoring, the NW side can evaluate the training/inference consistency based on comparison of the ground truth CSI with the training data characteristics and/or the reported predicted CSI.
For CSI prediction Type 3 monitoring, output is in a form of performance metric(s) that correspond to a measure of a correlation of the training and inference information.
Monitoring-based approach for training/inference consistency is motivated for scenarios with lack of knowledge on the additional conditions.
Based on the observations above, we have the following proposals:
Reuse the AI/ML framework for BM whenever applicable as a first step, with respect to RAN2 defined procedures/steps, as well as the definition of AI/ML functionalities, e.g., supported functionality, applicable functionality and activated functionality.
An urgent decision on whether network-side additional conditions are required for AI/ML for CSI prediction is needed to facilitate the path toward specification support of this feature. 
Rel-16 eType-II CB is not supported for the purpose of AI/ML-based CSI prediction.
In case AI/ML processing unit (APU) is introduced, either the APU or the legacy CPU are used for a give CSI measurement/reporting occasion, but not both simultaneously.
For the active CSI-RS resource counting (ARC) for AI/ML-based CSI prediction, legacy procedure is supported.
For data collection under AI/ML-based CSI prediction, the UE is configured with a CSI report configuration corresponding to channel measurement via CMR(s) over a time window, where no report quantity is associated with this CSI report configuration.
For Rel-18 eType-II CB configured with K AP CSI-RS resources spaced by m slots, the corresponding CSI report configuration for data collection comprises at least K P/SP CSI-RS resources with the offset between two consecutive CSI-RS transmissions from two CSI-RS resources is m slots.
Evaluate the specification impact corresponding to AI/ML model monitoring, considering the following monitoring decisions: (i) No model change, (ii) CSI parameters update, (iii) Model switching, and (iv) Fallback to non-AI/ML scheme.
For CSI prediction using a UE side model, adopt the following definition for ‘performance metric’: a parameter computed at the UE based on channel measurements at the UE side, where the performance metric is implicit, i.e., not reported, for Type 1 monitoring, and is explicit, i.e., reported by the UE, for Type 3 monitoring.
For CSI prediction using a UE side model, adopt the following definition for ‘monitoring output’: a parameter comprising a feedback of a recommended decision (generated at the UE side), based on performance metric(s) computed at the UE side or a decision (generated at the NW side).
Support SGCS as intermediate KPI for Type 1 and/or Type 3 performance monitoring.
FFS: whether SGCS averaged over SBs and/or layers with equal/unequal weights.
FFS: whether SGCS averaged over SBs and/or layers with equal/unequal weights.
FFS: whether the values are quantized uniformly in linear or log domain.
For performance monitoring under UE-based CSI prediction, three reference time instants are considered: (i) at the first slot of the prediction window, (ii) at the median slot of the prediction window, and (iii) at the last slot of the prediction window.
For performance monitoring under UE-based CSI prediction, study and evaluate the pros and cons of the following alternatives:
Implicit performance monitoring: the UE feeds back CSI measurements based on CSI report quantities or intermediate KPIs that enable the network to derive performance monitoring decisions.
Explicit performance monitoring: the monitoring feedback includes performance monitoring recommendation based on a set of network-configured performance monitoring metrics.
Evaluate potential configurations of the observation window and the prediction window for UE-based CSI prediction.
Electrical tilt/panning are not considered as network side additional conditions for AI/ML-based CSI prediction.
Maintaining consistency of training/inference via model training at the NW side followed by model transfer to UE side is not considered for the study of training/inference consistency under UE-sided CSI prediction.
Further study maintaining consistency of training/inference via indication of NW-side additional conditions, with focus on scenarios with a few number/values of NW-side additional conditions, as well as scenarios with localized/cell-specific/site-specific models.
Deprioritize model identification-based techniques for training/inference consistency for UE-sided CSI prediction.
Further study Type 1 and Type 3 performance monitoring techniques for CSI prediction for the purpose of training/inference consistency.
For training/inference consistency issues for UE-sided CSI prediction, if specified, scope is limited to additional condition associated ID techniques and monitoring-based techniques.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502212
Wuhan, China, April 7 – 11, 2025
 
Agenda Item:	9.1.3
Source:	Huawei, HiSilicon
Title:	Discussion on AI/ML for CSI prediction
Document for:	Discussion and Decision

Conclusion
In this paper we make the following observations and proposals:
Observation 1: Generalized performance of the AI/ML models may be achieved in CSI prediction with a mixed data set (i.e., generalization Case 3).
For the evaluation of generalization performance over tilt angles, generalization Case 3 trained with mixed {102 degrees and 110 degrees} and tested on 102 degrees/110 degrees has minor SGCS loss of 3%/1%, respectively, compared with the corresponding generalization Case 1 performance.
For the evaluation of generalization performance over antenna layouts, generalization Case 3 trained with mixed {[2, 8, 2] and [4, 4, 2]} and tested on [2, 8, 2]/ [4, 4, 2] has minor SGCS loss of 1%/0%, respectively, compared with the corresponding generalization Case 1 performance.
For the evaluation of generalization performance over TXRU virtualization subject to [2, 8, 2], generalization Case 3 trained with mixed {2x8x2, 8x8x2 and 12x8x2} and tested on 2x8x2/8x8x2 has minor SGCS gain of -1%/1%, respectively, compared with the corresponding generalization Case 1 performance.
Observation 2: Activation delay is needed for deploying the model to the AI/ML processing memory before performing inference.
Activation of an AI/ML model for CSI prediction could be achieved in TTI level delay.
To achieve efficient usage of AI/ML processing memory, the model should be flushed from the AI/ML processing memory after inference is completed.
Observation 3: UE may need to deploy multiple functionalities in the AI/ML processing memory, each of which may correspond to an individual required memory storage.

Proposal 1: No need to introduce indications from NW (e.g., explicit indication or associated ID) for ensuring consistency between training/inference for CSI prediction.
Proposal 2: For training data collection of UE-side model, A-CSI-RS resource type is not supported.
Smaller values of m={1, 2} slots can be introduced as CSI-RS periodicity/gap for training data collection to enable the training for A-CSI-RS based CSI prediction.
Proposal 3: For training data collection of UE-side model, CSI-ReportConfig is used for configuring the training data collection procedure without CSI report.
P/SP-CSI report type(s) may be further considered. A-CSI report type is not supported.
Proposal 4: For training data collection of UE-side model, one CSI-ResourceConfig can be configured for UE measurement to obtain both model input and label.
Proposal 5: For training data collection, gNB indicates the preferred prediction time instance information as guidance to facilitate UE side training, including:
Candidate slot offset value(s) between earliest of N4 predicted instances and the reference time.
The reference time for training data collection phase should be the measurement CSI-RS occasion instead of the UL slot of the CSI report.
Candidate time unit value(s) of predicted instance (i.e., d).
Candidate number(s) of predicted time instances (i.e., N4).
Proposal 6: For AI/ML model under CSI prediction, RAN1 to investigate the priority rule considering the introduction of AI/ML-based CSI reporting types.
E.g., differentiate the CSI report priority over the CSI types subject to different LCM procedures (e.g., inference, monitoring, training data collection).
Proposal 7: For monitoring Type 1, consider event or recommended monitoring decision (fallback).
For the definition of event, event is triggered when the prediction accuracy metric is lower than the threshold and satisfies a timer/counter.
For the definition of threshold criterion, consider both per sample based value and statistic value of samples (e.g., mean, x% CDF of SGCS values).
Proposal 8: For monitoring Type 2, consider the report of per monitoring sample with legacy codebook/PMI as the ground-truth CSI.
Note: The format of the ground-truth CSI can be the same as a legacy CSI codebook.
Proposal 9: For monitoring Type 3, consider the report of per monitoring sample, report for a set of monitoring samples, or report of statistical value over a number of monitoring samples.
Proposal 10: For performance monitoring Type 1/3, spatial-frequency domain precoding matrix can be adopted as the type of predicted CSI/ground-truth label for calculating the monitoring metric.
Proposal 11: For performance monitoring Type 1/3, support SGCS as the intermediate KPI for calculation of monitoring metric.
The SGCS can be calculated individually for each layer and each prediction instance, and averaged over subbands.
Proposal 12: For the report of monitoring results, consider L1 signaling with higher priority due to more stringent requirements on latency.
Proposal 13: For the CSI report configuration of monitoring Type 1/3, adopt the agreed option of the beam management case, i.e., two separate CSI reports are configured to handle the inference process and monitoring process, respectively.
To indicate the linkage between the monitoring CSI report and the inference CSI report, the associated CSI-ReportConfigId of the inference CSI report configuration can be configured in the monitoring CSI reporting configuration.
For each of N4 predicted instances subject to the associated inference CSI report, the monitoring RS falling into its prediction time unit can be used for comparing with the predicted result.
Proposal 14: Regarding the processing unit sharing rule for AI/ML-based CSI processing for inference, a dedicated AI/ML-based CSI processing unit pool (namely XPU) is introduced for AI/ML-based CSI reporting.
The XPU pool is shared among CSI report related AI/ML functionalities, e.g., AI/ML-based BM and AI/ML-based CSI prediction.
No need to introduce XPU for AI/ML-based positioning.
Proposal 15: If a dedicated AI/ML-based XPU pool is introduced for AI/ML-based CSI reporting for inference, processing of AI/ML-based CSI report occupies both XPU and legacy CPU. 
Equal occupancy duration can be assumed for XPU and legacy CPU.
Proposal 16: For training data collection and monitoring of UE-side model, reuse the legacy CPU occupancy in principle and no need to involve XPU.
For training data collection, reuse the legacy CPU occupancy rule subject to report quantity of ‘none’.
For monitoring Type 1/3, if a dedicated CSI report is configured to the monitoring CSI, the CPU occupancy for a monitoring CSI report starts from:
DCI for A-CSI report.
N4-th latest consecutive RS occasion for SP-CSI report.
Proposal 17: Regarding the active resource/port counting, legacy rule can be reused, i.e., no need to introduce AI/ML-specific active resource/port capability.
For training data collection and monitoring, the active resource/port is counted multiple times based on N4, considering separate measurements are needed to generate labels for monitoring N4 predicted instances.
Proposal 18: For A-CSI report subject to a functionality, the CSI processing timeline is impacted by the active/inactive state of the functionality. When the A-CSI report is triggered:
If the functionality is subject to “active state”, the CSI processing is subject to a shorter timeline.
If the functionality is subject to “inactive state”, the CSI processing is subject to a longer timeline as it additionally includes the activation delay. 
Proposal 19: For determining the active/inactive state of a functionality, consider following cases: 
Case 1: An activation window is configured/activated by the NW for the functionality. The functionality is subject to active state in the activation window, and is subject to inactive state otherwise. 
Case 2: Active/inactive state is determined by another SP-CSI report subject to the same functionality. The functionality is subject to active state for a certain time duration before the uplink symbol of per SP-CSI report, and is subject to inactive state otherwise.
Proposal 20: The association of multiple CSI report configurations and/or multiple sets of inference related parameters corresponding to a same functionality should be reported by UE during the functionality report procedure.
Proposal 21: Discuss the memory occupancy alignment mechanism to align the availability of memory storage for updating the AI/ML-based CSI report.
The memory is occupied when it requires computation and is flushed when the CSI report is transmitted.
For A-CSI report, the occupation lasts from DCI to the CSI report.
For SP-CSI report, the occupation lasts for a certain time duration before the uplink symbol of per SP-CSI report.
The UE does not need to update an AI/ML-based CSI report if the unoccupied memory cannot support its required memory.
Proposal 22: For functionality alignment, the general signalling procedure agreed by RAN2 (Step 1~Step 5) and the Direction A) and Direction B) agreed by RAN1 (except for the associated ID part) for the beam management case can be reused for CSI prediction.
Proposal 23: For functionality alignment, regarding the set of inference related parameters provided by NW in Step 3 subject to Direction B), consider CSI specific parameters, including:
Measurement related information, e.g., CSI-ResourceConfig.
Report related information, e.g., CodebookConfig-r18, reportConfigType.
Other information that may impact CSI distribution or model scalability, e.g., carrier, csi-ReportingBand, etc.
Note: Strive to reuse the CSI prediction specific IEs subject to CSI-ReportConfig or referred by CSI-ReportConfig.
Proposal 24: The performance and requirement related information should be reported by UE along with the applicable functionality in Step 4, including:
Target performance/robustness of the functionality.
Required CSI processing timeline of the functionality.
Required XPU value of the functionality.
Required memory storage of the functionality.

3GPP TSG RAN WG1 #120bis		R1-2502290
Wuhan, China, April 7th-11th, 2025

Source: 	OPPO
Title:	On specification for AI/ML-based CSI prediction
Agenda Item:	9.1.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on consistency of training/inference and some spec impacts issues for UE-sided CSI prediction. Observations and proposals are listed as following:
Observation 1: CSI-prediction model trained at UE-side is UE/UE-vendor/chipset-vendor specific.
Observation 2: No additional downlink signaling is required when one CSI-RS resource is configured for both of model input and ground-truth CSI measurements 
Observation 3: Additional downlink signaling is required to associated two CSI-RS resources which are separately configured for model input and ground-truth CSI measurements.
Observation 4: The CSI report quantity can be configured as ‘none’ to support the data collection and model training at UE-side without any reporting.
Proposal 1: Regarding the CSI-RS resource configuration, no support of aperiodic CSI-RS resource.
Proposal 2: Support configure one CSI-RS resource for both of model input and ground-truth CSI measurements.
Proposal 3: Reuse current CSI-RS resource configuration, no enhancement is supported in Rel-19 WI phase.
Proposal 4: Regarding type 1 and 3 performance monitoring metric, suggest to use NMSE as the intermediate KPI. 
Proposal 5: use average NMSE between  predicted raw channels and  ground-truth as the performance metric.
Proposal 6: For type 1 and type 3 performance monitoring, the monitoring output or performance metric can be reported based on one time of monitoring or K times of monitoring
K>1 can be configured by NW in the CSI reporting resource configurations.
Proposal 7: The CPU should be separately counted between legacy CSI reporting and AI/ML-based CSI reporting.
Proposal 8: For UE-side model, name the AI/ML processing unit as APU in specification, along with legacy CPU.
Proposal 9: Processing unit should be shared between CSI-related AI/ML features/functionalities. Other non-CSI related features/functionalities can be separately counted in a different processing pool.
Proposal 10: For UE-side model, allow UE to report the number of APU(s) that one particular use case (e.g. CSI prediction) would occupy.

3GPP TSG RAN WG1 #120bis						R1-2502311
Wuhan, China, April 7th – 11th, 2025

Agenda Item 	:	9.1.3
Source 	:	Sony 
Title 	: 	Specification support for AI/ML CSI prediction
Document for 	:	Discussion and decision

Conclusion
In this contribution, we discussed some areas that need to be covered in the specification of AI/ML temporal CSI prediction. We observed and proposed as follows:
Proposal 1: RAN1 should specify the form of measurement data for data collection, model training, model input for inference and monitoring of the CSI prediction AI/ML model.
Observation 1: For training data collection using CSI-RS value or channel transfer as the AI/ML CSI prediction model input and output, only one complex value per CSI-RS needs to be stored/transferred 
Observation 2: For model monitoring using CSI-RS value or channel transfer as the AI/ML CSI prediction model input and output, a relatively low complexity Type 1 and Type 3 UE-based performance monitoring using the CSI-RS value or its channel transfer can be done using a metric such as NMSE.
Observation 3: With channel matrix or precoder matrix as the AI/ML CSI prediction model input and output, for model monitoring, type 1 and type 3 UE-based performance monitoring using the predicted channel or precoder matrix can be quite complex as a simple comparison metric such as NMSE may not be enough. 
Proposal 2: RAN1 should consider the form of model input and output in choosing the intermediate KPI for use in UE-side model performance monitoring. RAN1 can choose from the following options:
Input/Output: raw CSI-RS value or its transfer function with NMSE for monitoring metric
Input/Output: Channel matrix or precoding matrix with SGCS for monitoring metric
Observation 4: When configured with a periodicity that matches the slot spacing between desired CSI prediction intervals, both the CSI-RS resource(s) used for measurements for model input and CSI-RS resource(s) used for measurements for ground-truth. can be available in one configuration.
Proposal 3: RAN1 concludes that for periodic and semi-persistent CSI-RS, a single CSI configuration is sufficient for both the CSI-RS resource(s) used for measurements for model input and CSI-RS resource(s) used for measurements for ground-truth.
Observation 5: Measurements of ground-truth for performance monitoring are likely less frequently needed than measurements for model input in inference.
Proposal 4: RAN1 should allow separate configuration of CSI-RS resources for model input at inference and model monitoring ground-truths.
Proposal 5: RAN1 should allow the use of aperiodic CSI-RS for use in performance monitoring of CSI prediction using UE-side model.

3GPP TSG-RAN WG1 #120bis	R1-2502337
Wuhan, China, April 7th – 11th, 2025
Agenda Item:	9.1.3
Source:	InterDigital, Inc.
Title:	On AI/ML-based CSI prediction
Document for:	Discussion and Decision

Conclusion 
In this contribution, we discussed aspects of CSI prediction accuracy, model complexity, and LCM aspects related to model monitoring, and provided a revised set of evaluation results for CSI prediction.
We provide the following observations and proposals.
Observation 1: 	Metrics for monitoring the UE-side CSI prediction model that are more indicative of end-to-end performance should be used to reduce the model switching, activation/deactivation overhead.
Observation 2:	Using out-of-distribution metrics in conjunction with intermediate KPIs may be beneficial for UE-side model monitoring. 
Observation 3: It may be beneficial to use AI/ML Processing Units (APU) to indicate the number of supported simultaneous AI/ML functionalities.

Proposal 1: Support specification transparent gNB-side model performance monitoring and allow gNB to disable UE-side monitoring (Type 1 or Type 3).
Proposal 2: Support Type 3 for UE-side model performance monitoring.
Proposal 3:	For UE-side model monitoring, out-of-distribution metrics should be used in conjunction with intermediate KPIs.
Proposal 4: Support intermediate KPI based on the SGCS metric. 
Proposal 5: Monitoring metric should further be based on relative intermediate KPI.
Proposal 6: Support separate configuration for CSI-RS for monitoring, especially when aperiodic CSI-RS is used for CSI prediction.
Proposal 7: Support separate PU occupancy counting between legacy (non-AI/ML) CSI reporting and AI/ML-based CSI prediction.
Proposal 8: Support CPU pool sharing between legacy CSI reporting and AI/ML-based CSI prediction.

3GPP TSG RAN WG1 #120bis		                         R1-2502354 Wuhan, China, April. 7th–11th, 2025

Agenda item:	9.1.3
Source:	Samsung
Title:	Views on AI/ML based CSI prediction 
Document for:	Discussion and Decision

Conclusion
In this contribution, the following observations and proposals are made:

Observation#1: Site-specific AI/ML prediction model trained based on dataset collected from a single drop on a single sector with spatial consistency turned on and a large number of UE per drop shows better performance (SGCS) as compared to generic model.  

Observation#2: For performance evaluation of UE-side CSI prediction with respect to data distribution mismatch that may arise from NW-side additional conditions, considering TRP antenna settings with different TXRU mapping, e.g., Setting#1: [N1, N2, P] = [2, 8, 2] with virtualization (2x8x2) antenna elements and Setting#2: [N1, N2, P] = [2, 8, 2] with virtualization (12x8x2) antenna elements
Case1: When an AI/ML model is trained and tested on dataset from a single TRP antenna setting, a similar level of performance gain (5%-22%) over Baseline#1 (sample-and-hold) is observed irrespective of the antenna settings.
Case 2: When an AI/ML model is trained on dataset from one TRP antenna setting and tested on dataset from a different TRP antenna setting, a lower performance gain over Baseline#1 (sample-and-hold) is observed and a significant performance loss of up to (13.4%) is observed as compared to a model trained on a single antenna setting. 

Proposal#1: In CSI prediction use case using UE-sided model, consider implicit indication of TRP related aspects for network-side additional condition indication. 

Proposal#2: For the AI/ML based CSI prediction sub-use case, consider the following aspects for data collection
CSI measurement and reporting framework.
Data collection procedure and priority. 

Observation#3: For the AI/ML based CSI prediction using UE-side model, the CSI report configuration for training data collection purpose needs to be differentiated from other report configurations with reportQuantity set to ‘none’. 

Proposal#3: For the AI/ML based CSI prediction using UE-side model, for CSI report configuration for training data collection purpose, to differentiate the configuration from other report configurations with reportQuantity set to ‘none’, support
Explicit indication of resources for data collection purpose, e.g., higher layer parameter ‘resourcesForDataCollection    CSI-ResourceConfigId’


Proposal#4: For the AI/ML based CSI prediction using UE-side model, support to reuse CSI framework for the configuration for monitoring result report in L1 signaling
Dedicated resource set(s) for monitoring and report configuration for monitoring are configured in a dedicated CSI report configuration used for monitoring
The CSI report Configuration ID of an inference report configuration is configured in the configuration for monitoring to link the inference report configuration and monitoring report configuration

Proposal#5: For the AI/ML based CSI prediction using UE-side model, for the calculation of performance monitoring metric, adopt SGCS calculated on two vectors, one from inference () and one from the ground truth (), as 
where,   for vector . 


Proposal#6: For the AI/ML based CSI prediction using UE-side model, for the calculation of SGCS as a performance monitoring metric, 
Support at least SGCS calculated over eigenvectors from a time-frequency unit for monitoring KPI calculation 
Define the time-frequency unit for monitoring KPI calculation with respect to the time-frequency unit for PMI determination, e.g., DD time unit and PMI subband. 
FFS: whether time-frequency unit for monitoring is the same as time-frequency unit for PMI determination or up scaling is considered to relax buffering requirements 

Proposal#7: For the AI/ML based CSI prediction using UE-side model, for performance monitoring, the network configures at least one monitoring measurement resource (MMR) in the prediction window defined as the slots between the earliest slot to the last slot, in time domain, for the linked predicted PMIs.  
The UE measures up to  MMRs in the prediction window.
The UE is not expected to measure MMR outside the prediction window. 
 
Proposal#8: For the AI/ML based CSI prediction using UE-side model, support at least Type 1 monitoring, consider 
Configuration of a threshold on monitoring KPI (SGCS)
 FFS: whether the threshold is configured per/across MIMO layers, per/across monitoring time and frequency units.  
Configuration of event for monitoring report outcome 
A single bit monitoring outcome per configured threshold, for comparison to the configured threshold, study further 
 Alt1: monitoring KPI is compared per an inference report occasion 
 Alt2: statistics of the monitoring KPI across multiple inference occasions, e.g., mean, count, etc. 


Proposal#9: For the AI/ML based CSI prediction sub-use case, for Type 2 monitoring, consider
Configuration and potential enhancement on Type II CSI for ground truth CSI reporting corresponding to multiple time instances. 
Priority and CSI processing timeline 
Restriction between the CSI for the linked CSI report configurations, e.g., rank


Observation#4: When the eigenvalues of the channel matrices are close to each other, the order of eigenvector directions may change, resulting in a vanishing SGCS which may lead to a false-alarm in monitoring. 



Proposal#10: For the AI/ML based CSI prediction using UE-side model, for Type 1 and Type 3 monitoring, to address potential false alarm event, 
 UE determines the SGCS values on the vector  from inference corresponding to layer index  and for the ground truth vectors from the same monitoring time-frequency unit denoted by  , the UE determines the SGCS value as  for  . 
FFS on 


Proposal#11: For the AI/ML based CSI prediction using UE-side model, for Type 2, when a UE reports ground truth precoders (PMIs)
Alt1: the UE may report the ground truth vectors for monitoring by (re)ordering the ground truth vectors in such a way that the reported vector maximizes the SGCS value. 
Alt2: the UE reports potential false-alarm indicator in the CSI report for monitoring 
Alt3: the UE reports all the relevant eigenvectors 
FFS: on 


Proposal#12: For CSI processing criteria and timeline of AI/ML related CSI reports, consider a separate AI/ML processing resource pool than the legacy CPU, UE reports the number of simultaneously executed AI/ML processes it supports as 
FFS: how to address memory constraints, e.g., the number of simultaneously activated models/functionalities, buffering requirement for channel samples. 
FFS: whether the PU for AI/ML related CSI report are counted towards    only. 

3GPP TSG RAN WG1 Meeting #120-bis 	R1-2502413
Wuhan, China, April 7th – 11th, 2025

Source:	   RUijie networks
Title:	   Discussions on specification support for CSI prediction
Agenda Item: 	   9.1.3
Document for: 	Discussion and decision 

Conclusions
In this contribution, we have presented our views on specification support for CSI prediction. Based on the discussions in the previous sections we propose the following: 
Proposal 1: For CSI prediction using UE-side model, for CSI processing criteria and timeline, at least for inference,
The CPU should be separately counted between legacy (non-AI/ML) CSI reporting and AI/ML-based CSI reporting.
The processing unit should be shared among AI/ML related features/functionalities.
New timeline is needed/updated for inference, and a different timeline is needed when functionality switches/activates.
Legacy framework for active CSI-RS resource and port counting can be reused.
Proposal 2: For CSI prediction using UE-side model, if performance monitoring type 1 or 3 is supported, for calculation of monitoring metric, SGCS should be used as the intermediate KPI.
Proposal 3: For CSI prediction using UE-side model, for data collection for training, For CSI-RS resource type for CMR, all CSI-RS resource type for CMR (i.e., periodic, semi-persistent, and aperiodic CSI-RS) are supported. 

3GPP TSG RAN WG1 #120bis                                                                                             R1-2502432
Wuhan, China, April 7th – 11th, 2025

Agenda item:	9.1.3
Source:	            		Xiaomi
Title:	Further discussion on AI/ML model based CSI prediction
Document for:	Discussion and Decision

Conclusions
In this contribution, the proposals and observation on UE side AI/ML model based CSI prediction are summarised as follows:
Observation 1: If legacy CSI reporting and AI/ML-based CSI reporting adopts the same hardware, CPU could be shared for them, otherwise, CPU is separately counted.  
Observation 2: 4 RBs CSI-RS resource bandwidth configuration leads to about 2% SCGS gain loss with 92.3% CSI-RS resource overhead reduction compared to 52 RBs CSI-RS resource bandwidth configuration.

Proposal 1: For model inference, CSI-RS resource configuration for Rel-18 Type II Doppler codebook based CSI feedback could be as a starting point.
Proposal 2: Whether the CPU shared or separately counted between legacy CSI reporting and AI/ML-based CSI reporting depends on the same hardware used or not for them.
Proposal 3: For AI/ML based CSI prediction, the following CSI processing criteria could be considered if legacy CPU and AI/ML-based CPU are respectively occupied for one CSI reporting: 
The number of legacy CPU and AI/ML-based CPU are respectively counted. 
The occupation time of legacy CPU and AI/ML-based CPU are respectively defined.
Legacy active CSI-RS resource counting is reused.
Proposal 4: At least requested from UE for training data collection model should be supported.
Proposal 5: For training dataset collection, CSI-RS resource configuration with lower frequency density, less bandwidth or less antenna ports could be supported to reduce CSI-RS signalling overhead.
Proposal 6: SGCS is defined as the performance metric for monitoring CSI prediction model.
Proposal 7: For each prediction occasion, SGCS is calculated as , while the average or statistic of performance metric for multiple occasions as the final monitoring result is reported by UE.
 is the number of subbands.
 is the number of layers
 is ground truth eigenvector of the n-th subband for the l-th layer.
 is predicted channel eigenvector of the n-th subband for the l-th layer.
Proposal 8: For predicted multiple occasions, i.e., 1

3GPP TSG RAN WG1 #120-bis			R1-2502472
Wuhan, China, April 7th – 11th, 2025
Agenda item  :	     9.1.3.1
Source           :	Tejas Networks
Title                :	Discussion on AI/ML for CSI prediction
Document for: Discussion 

Conclusion
According to the discussion, following proposals are provided:
Observation 1: Variations in interference distributions during training and inference can lead to significant reductions in CSI prediction accuracy.
Observation 2: Differences in network-side additional conditions, such as TxRU mappings, may degrade AI model performance, even if antenna configurations are consistent.
Proposal 1: Use of Associated ID for Consistency
Consider an associated ID-based solution to ensure consistency between training and inference. This method is already explored in AI-based beam management scenarios and could be extended to CSI prediction.
Step 1: Network signals associated ID during training data collection.
Step 2: AI/ML models are trained using data corresponding to the associated ID.
Step 3: The associated ID is used during inference to align the conditions between training and inference phases.

Proposal 2: For CSI Prediction, Tilt angle and/or TXRU mapping will cause the performance degradation.
Proposal 3: Consider CSI frame work for Resources and reports of AI/ML-based CSI prediction.
Proposal 4: For LCM we support AI/ML model identification  
Models are identified by model ID by the Network. 
UE indicates supported AI/ML models.
Proposal 5: Consider the following options to initiate CSIRS transmission for prediction
NW trigger CSI RS transmission for prediction
UE initiate the CSI RS transmission for prediction

Observation 3: Prediction accuracy depends on number of instances of CSIRS within the observation window.
Proposal 6: Consider that UE should report minimum number of CSIRS instances required for CSI prediction to the NW.
Proposal 7: Consider the maximum time gap that allowed between prediction and observation window for better prediction accuracy. 
Proposal 8: For data collection of CSI prediction, Consider existing CSI framework.
CSI resources for inference and training/monitoring.

Proposal 9: Consider the following as a potential specification impact for performance monitoring:
Configuration of CSI-RS for performance monitoring
Configuring threshold criterion 
Measurement of monitoring output
Reporting of monitoring output (if monitoring output is below the threshold)
Model switching or Model parameter update
 Functionality fallback operation

Proposal 10: Consider the NW to assign the threshold criterion for UE.

Proposal 11: Consider that UE only reports performance monitoring output only when monitoring output is below the threshold.

Proposal 12: Consider the following as a potential specification impact for Type 3:
Configuration of CSI-RS for performance monitoring
Measurement of metric and reporting it to UE
Model switching or Model parameter update
Functionality fallback operation

Proposal 13: For Type 1 and 3 performance monitoring the performance metric per sample should be intermediate KPI (e.g., SGCS, NMSE), or statistical value within the within the window (e.g., mean value SGCS, NMMSE).

Proposal 14: Type 1 performance should be prioritized.

3GPP TSG RAN WG1 #120bis		R1-2502491
Wuhan, China, April 7th – 11th, 2025

Source:	Panasonic
Title: 	Discussion on AI/ML-based CSI prediction
Agenda Item:		9.1.3
Document for:	Discussion

Conclusion
In this contribution, we provide our view on the consistency of training / inference for AI/ML-based CSI prediction. We made following proposals and observation.
Proposal 1: Both “joint processing unit pool for AI/ML-based CSI and legacy CSI” and “separate processing unit pools for AI/ML-based CSI and legacy CSI” are required.
Proposal 2: Before proceeding a discussion of CSI processing unit, a relationship between model mapping and 3GPP-specified procedure relation should be concluded.
Proposal 3: When a UE reports capability of UE-side AI/ML model in UECapabilityInformation message, it means that the UE-side AI/ML model is ready to be used, i.e., it is not required to download from UE side server.
Proposal 4: Functionality-based LCM from time-domain beam prediction (BM-Case 2) with UE-sided model can be leveraged for CSI prediction with UE-sided model.
Proposal 5: At least observation window, prediction window, and processing unit related information should be included for inference related parameters.
Proposal 6: The necessity of UE preference reporting on the appropriate CSI measurement configuration to the network other than UE’s capability / functionality report should be discussed.
Observation 1: More evaluation would be required to see the necessity or the usefulness of the potential enhancement to support aperiodic CSI-RS resource.
Proposal 7: SGCS should be used for Type 1 and Type 3 performance monitoring.
Proposal 8: For performance monitoring of CSI prediction, UE needs to be indicated / configured with the configuration for ground-truth measurement.
Proposal 9: For performance monitoring of CSI prediction, performance monitoring output (Type 1), corresponding ground-truth CSI (Type 2) or performance monitoring metric (Type 3) for the previous predicted CSI can be piggybacked in the predicted CSI report.
Proposal 10: RAN1 should conclude whether NW-side additional condition is necessary or not for ensuring the consistency between training and inference based on the observations and/or evaluation results considering the aspects agreed in RAN1#118bis.
Proposal 11: For ensuring the consistency between training and inference of CSI prediction, the discussion / conclusion in beam prediction can be reused.
Proposal 12: For UE-side data collection, in order to identify the scenario / configuration, how to share the NW-side additional condition should be studied. 
Proposal 13: Instead of informing actual configuration, some kind of configuration ID corresponding to associated ID is necessary.
Proposal 14: Data-transfer-based method as not to inform NW-side additional condition at the time of the training should be studied.
Proposal 15: RAN1 is not required to discuss how UE collected data is transferred to UE side (server). 

3GPP TSG RAN WG1 #120-bis			R1-2502503
Wuhan, China, April 7th – 11th, 2025

Source:	ETRI
Title:	Discussion on specification support for CSI prediction
Agenda item:	9.1.3
Document for:	Discussion 

Conclusion
In this contribution, we have discussed issues on specification support for CSI prediction. As a conclusion, we summarize our views as follows:
Observation 1: Ensuring the consistency between training and inference of UE-sided AI/ML model is essential for preventing non-negligible performance degradation.
Proposal 1: For consistency of training/inference of CSI prediction, support associated ID.
Proposal 2: In CSI prediction, UE may assume the same NW-side additional conditions of DL RS associated with the same associated ID.
Proposal 3: For consistency of UE sided model in CSI prediction, RAN1 to study the method for configuration of associated ID.
The associated ID can be configured through the CSI report configuration or CSI resource configuration from a higher layer, with the UE assuming that the configured CSI-RS within the configuration shares the same associated ID.
Observation 2: Type 1 performance monitoring is more efficient than Type 2 / Type 3 performance monitoring in terms of uplink resource utilization.
Proposal 4: Support Type 1 performance monitoring for CSI prediction.
Proposal 5: Support Type 3 performance monitoring for CSI prediction based on UE capability.
Proposal 6: The network can configure RS for ground-truth data collection and model input, as well as uplink resources for reporting the performance metric or performance metric output in a single configuration.
Proposal 7: For performance monitoring, the UE reports only the performance metric or performance metric output, rather than CSI, for the configured RS.
Proposal 8: Support SGCS as a performance metric for Type 1 and Type 3 performance monitoring.
Proposal 9: For Type 3 performance monitoring, allow the network to configure a threshold such that the UE reports the performance metric only when the SGCS exceeds the configured threshold.
Proposal 10: Specify the configuration of threshold criteria to facilitate UE-side performance monitoring for Type 1 performance monitoring.
Observation 3: For Type 1 performance monitoring, configuring two or more threshold provides greater flexibility in UE and model implementation.
Proposal 11: For Type 1 performance monitoring, consider the configuration of two or more threshold values.
Proposal 12: For type 1 performance monitoring, the performance metric output can represent a set of UE behaviors for the UE-side model, consisting of three states: 1. Maintain the current model, 2. Switch to another model, 3. Deactivate the model and fall back to legacy CSI framework.

3GPP TSG RAN WG1 #120bis																 		R1- 2502530
Wuhan, China, April 7th – 11th, 2025 

Agenda item:			9.1.3
Source:	Nokia
Title:	AI/ML for CSI Prediction
Document for:		Discussion and Decision

Conclusion
In this contribution, we have addressed the issues related to specifying CSI prediction use case. Our observations and proposals are:
Observation 1: The impact of tilting as well as antenna configurations on the generalization performance on our AI/ML channel predictor is small.
Observation 2: The CSI configuration framework for the non-AI/ML based channel prediction is already quite flexible. As the basic parameter setting for non-AI/ML and ML based channel prediction is very similar, the current CSI reporting framework is a good basis for AI/ML channel prediction.  
Observation 3: Some optimizations for the CSI configuration framework for the non-AI/ML based channel prediction could be considered especially with respect to performance monitoring. Nonetheless, the possible benefits have to be clarified to justify the effort for the specification of an enhanced overall CSI RS configuration framework.
Observation 4: An enhanced CSI reporting framework might benefit from first CSI reports with or without prediction during the observation window to support low latency applications. 
Observation 5: Defining a threshold for the intermediate KPI value like a SGCS for a single performance monitoring instance is not sufficient to assess the ML model performance.    

Observation 6: For performance monitoring collect monitoring distributions of the intermediate KPI over multiple frequency subbands, multiple time instances as well as multiple APs.

Observation 7: in case of >1 a prediction time specific evaluation of the monitoring performance might provide a more accurate evaluation.
Observation 8: Requirements for performance monitoring might vary depending on channel conditions, ML model types, energy efficiency requirements, etc. so that a gNB configurable performance monitoring reporting seems to be preferable. It might combine different modes like event driven, gNB triggered and/or periodic reporting with varying periodicities. 
Observation 9: Defining data content as explicit CSI and considering uncompressed explicit CSI (in the data collection framework) can minimize specification effort.
Observation 10: Compressed data format (e.g., with an enhanced TypeII format) can be considered as well even so this will require a more detailed further analysis.


Proposal 1: The complexity of specifying additional conditions is high, while the performance gains are low. Therefore, there seems to be no good reason for the specification of additional conditions.
Proposal 2: Consider the SGCS as the monitoring metric (basic KPI) for the UE sided Type 1 performance monitoring method.
Proposal 3: For performance monitoring, consider configuration of monitoring CSI-RS resources independent from configuration of inference CSI-RS resources (e.g., configured for the observation window). 
A separate CSI report configuration may be used for monitoring, as agreed for the BM sub use case.

Proposal 4: Consider a reference predictor-based performance monitoring method, where the distributions of the intermediate KPI of the AI/ML predictor and a reference predictor like ZOH are compared to each other.
Proposal 5: For Type 1 monitoring the UE should collect statistics over multiple time instances before doing a performance evaluation of the AI/ML predictor relative to the reference predictor. 
Proposal 6: For Type 3 monitoring, the UE should report the partial statistics per time instance to the gNB so that the gNB can generate the combined and meaningful statistics of the AI/ML as well as the reference predictor. 
Proposal 7: Define suitable functions like weighted sums to generate single performance monitoring values per monitoring instance, which can be combined for Type 1 at UE side and for Type 3 at gNB side to achieve a meaningful performance metric of the AI/ML predictor relative to the reference predictor. 
Proposal 8: The gNB should configure the size of SGCS estimates used for generating the statistic of the intermediate KPI distributions of the AI/ML as well as the ZOH predictor. For example, the gNB might configure the number of time instances  needed for the generation of a single performance monitoring report. 
Proposal 9: In case of >1 report prediction time specific evolution of CQI allowing the gNB to adapt to varying channel prediction performance. Effective reporting might be a index into a CQI codebook.
Proposal 10: RAN1 to consider sequence of CSI-RS transmission for training so that one might avoid the need for separately configured CSI-RS for the observation window and the prediction window. Also, enable higher accuracy ground truth measurements of CSI-RSs, especially for cell edge UEs.
Proposal 11: P and SP CSI-RS are baseline, but for high speed UEs the configuration of AP CSI-RS might be needed or useful to align with the Nyquist criterion. 
Proposal 12: For the collected data content, RAN1 to consider explicit CSI as the main option.
Proposal 13: For AI/ML-enabled CSI reporting (including Rel-19 channel prediction use cases), considering the CPUs used for inference reporting, the following enhancements and clarifications are supported, 
Consider a separate limit () for simultaneous CSI calculations for AI/ML-enabled CSI reports. 
Similar to legacy limit on , define  may be defined per component carrier or across all component carriers
Both legacy limit (and AI/ML-specific limit ( shall be considered when clarifying the spec (TS 38.214 Section 5.2.1.6) for CPU occupancy for AI/ML-enabled CSI reports
value(s) (number of CPUs) for a AI/ML-enabled CSI report (at least for channel prediction use cases) shall be clarified. 

Proposal 14: For channel prediction use cases, to clarify the active NZP-CSI-RS resources and active CSI-RS ports, RAN1 shall discuss the active time durations of CSI-RS resources. 

Proposal 15: For channel prediction use cases, to ensure that priority rules do provide the necessary policies for the UE to handle channel prediction reports, RAN1 to clarify the following,  
How to determine a priority value for a AI/ML-enabled CSI report (related to reporting of inference results)
Whether there are any changes to the priority values for CSI reports that carrying measurements for performance monitoring or data collection. 

3GPP TSG-RAN WG1 Meeting #120-bis				                R1-2502567
Wuhan, China, April 7th – 11th, 2025

Source:	Continental Automotive
Title:                       Specification support for CSI prediction
Agenda Item:         9.1.3
Document for:	Discussion and Decision

Conclusions
In this contribution, we discussed open issues related to the addressed scope with previous agreements on CSI prediction as well as the related aspects. Additionally, we ask RAN1 to discuss the following proposals: 
Proposal 1: Specify the unified measurement of AI/ML processing capability (e.g., CSI compression, CSI prediction, etc.) and its reporting.
Proposal 2: Specify configuration of a set of timeline types to support changing model operation behaviors, operation transitions across LCM stages, and multi-model operation scenarios.
Proposal 3: Define a separate processing unit to support AI/ML operation.
Proposal 4: Support configuration of processing unit to support common and dedicated AI/ML operations to optimize computing resource efficiency.
Proposal 5: Introduce a new parameter of reliability indication to be included in monitoring report.

3GPP TSG RAN WG1 #120bis                                                             R1- 2502596	
Wuhan, China, April 7th – 11nd, 2025

Agenda Item:	9.1.3 
Source:	Apple Inc.
Title:	Discussion on AI based CSI prediction   
Document for:	Discussion/Decision

Conclusion
In this contribution, we discussed the potential specification impact of AI based CSI prediction use case. Based on the discussion, the following proposals have been proposed.

Proposal 1: For AI based CSI prediction, for data collection for training, when m (separation between two consecutive CSI-RS in the measurement window) and d (distance between two consecutive predicted CSI in the prediction window) does not equal to the periodic CSI-RS periodicity (5ms, 10ms, 20ms), CSI-RS resource set with long periodicity can be configured to enable efficient data collection. 
One CSI-RS resource set include CSI-RS resources for measurement window and prediction window. 

Proposal 2: For AI based CSI prediction, for data collection for performance monitoring, a separate CSI-RS resource set is configured for CMR in the prediction window, to facilitate ground truth measurement.  
CSI-RS resource set for prediction window is explicitly linked to CSI-RS resource set for the measurement used for inference. 



Proposal 3: For CSI-RS prediction, when a UE requests data collection procedure for training, the UE can recommend a CSI-RS related configuration including: time domain information, frequency domain information, density, and association ID if specified.

Proposal 4: No further specification enhancement for type 2 performance monitoring in R19.  

Proposal 5: For type 1 performance monitoring, performance output is defined as the averaged SGCS per prediction sample over an evaluation window. NW may configure the evaluation window size and SGCS threshold. Type 3 performance monitoring is a special case when the configured evaluation window is 1.   

Proposal 6: Define event driven report considering RLM/BFD like mechanism.

Proposal 7: For AI based CSI prediction, define separate AI processing unit counting for CSI prediction. 

Proposal 8: For AI based CSI prediction, AI processing criterion and CPU criterion are applied together. AI processing unit is occupied for active CSI-RS resource and port counting, similar to legacy framework. 

Proposal 9: Define UE capability report on the number of AI processing units used for AI based CSI prediction.  
 
Proposal 10: To identify the NW-side additional conditions, generalization case 2 can be evaluated. If performance degradation is observed in generalization case 2, consistency signaling is needed. 

Observation 1: When spatial domain correlation is used in UE side model, prediction performance is sensitive to antenna virtualization. 

Proposal 11: Define assisted information/identifier to abstract the antenna virtualization/mTRP to ensure consistency of training and inference. 

3GPP TSG RAN WG1 #120bis			R1-2502685
Wuhan, China, April 7th – 11th, 2025
Source:	Sharp
Title:	Discussion on specification support for AI/ML based CSI prediction
Agenda Item:	9.1.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed our views on specification support for AI/ML-based CSI prediction and have the following observations and proposals.
Proposal 1: For Rel-19 AI/ML CSI prediction, the parameters  for CSI prediction window are configured by gNB via RRC signaling from candidate values reported by UE depending on UE capability where 
slot () is location of the first slot of first time interval,
 is the time duration of time interval,
N is the number of time intervals for CSI prediction. 
Observation 1: For AI/ML CSI prediction performance monitoring type 1, signaling overhead is minimum among three types of performance monitoring.
Observation 2: The performance monitoring type 2 have no specification impact.
Observation 3: For performance monitoring type 2, gNB can make a decision taking into account other UEs or traffic requirements.
Observation 4: The performance monitoring type 3 may require a moderate signaling overhead and moderate specification workload compared to Type 1 and Type 2 performance monitoring.
Proposal 2: For Rel-19 AI/ML CSI prediction, performance monitoring type 1 and type 2 can be further considered.
Proposal 3: For AI/ML based CSI prediction performance monitoring type 1/3, SGCS is preferred for intermediate KPI.
Proposal 4: For AI/ML based CSI prediction performance monitoring type 1/3, precoding matrix represented by the codebook is used for SGCS calculation.
Proposal 5: For CSI prediction using UE-side model, if performance monitoring type 1 or 3 is supported, support to reuse CSI framework for the configuration for monitoring result report in L1 signalling:
Dedicated resource set(s) for monitoring and report configuration for monitoring are configured in a dedicated CSI report configuration used for monitoring
The ID of an inference report configuration is configured in the configuration for monitoring to link the inference report configuration and monitoring report configuration
UE measures the dedicated resource set(s) for monitoring.
Proposal 6: For AI/ML based CSI prediction, the overall CPU should be separately counted between legacy CSI reporting and AI/ML based CSI reporting.
Proposal 7: The dedicated CPU for AI/ML can be shared with the other AI/ML use cases (e.g. Beam Management).

Agenda Item: 9.1.3
Source: MediaTek Inc.
Title:	Specification support for CSI prediction
Document for: Discussion & Decision
Consistency between Training and Inference
Following the RAN1#118bis meeting [1], it was agreed that we need to identify which potential NW-side additional conditions, if any, may impact on the UE assumption for CSI prediction using a UE-sided model. 
Associated ID and Performance Monitoring for Consistency
According to the Moderator's summary of the RAN1#118bis meeting [2], there is a proposal aimed at ensuring consistency between training and inference for CSI prediction that has not been fully discussed:

Since AI/ML-based CSI prediction targets UE-sided model, focusing on UE-sided data collection would be more effective. For UE-sided data collection, it is crucial to consider the impact of specific conditions under different configurations and scenarios of the data. Following downlink measurements by the UE (e.g., CSI-RS) and subsequent data collection, this information is processed and transmitted to a dedicated training entity or cloud server for model training. Due to various NW-side additional condition such as gNB-implemented antenna layout, antenna elements to TxRU mapping, and digital/analog beamforming, identical CSI-RS ports may exhibit different channel distributions observed at the UE under different settings. 
To significantly improve the accuracy of CSI prediction models, it is necessary to categorize the collected data according to specific scenarios and configurations, enabling the development of targeted AI/ML models for these situations. To ensure consistency between training and inference processes, introducing an associated ID to identify these specific conditions is a straightforward solution. Ongoing discussions in the beam management agenda like existing framework and procedures can be reused. The associated ID based approach avoids revealing too much proprietary information, safeguarding the privacy of NW deployments, while allowing the UE to accurately select the appropriate AI/ML model in different situations. 
However, in section 1.1 and section 1.2, we concluded that the AI/ML-based CSI prediction model can generalized well over tilt angle and TXRU mapping, which are part of the NW-side additional conditions. Therefore, it is necessary to study and further analyze which other NW-side additional conditions may impact the generalization of AI/ML-based CSI prediction models. If most of the common NW-side additional conditions do not impact the AI/ML-based CSI prediction model, then we need to further confirm whether using an associated ID for consistency between training and inference in CSI prediction is necessary. In this case, we recommend considering an alternative approach: performance monitoring-based methods. This allows UE to randomly execute their available models based on monitoring resources. Therefore, the NW does not have to manage numerous associated IDs, thus avoiding excessive transmission overhead from sending large volumes of data for various associated IDs. However, in a performance monitoring-based method, the UE must run multiple models or switch between various options to identify the best model until satisfactory performance is achieved. This process can be time-consuming and may increase complexity for the UE. If all models perform poorly during the monitoring check, it may indicate an inconsistency issue between training and inference. Consequently, it will take a considerable amount of time to fallback to the original non-AI method, making this approach less efficient compared to associated ID-based methods.
In conclusion, we propose that in the initial stage, we should confirm which kinds of NW-side additional conditions will impact the generalization of AI/ML-based CSI prediction models. Keeping the associated ID-based approach for consistency between training and inference for CSI prediction as the baseline is recommended since it can leverage the discussions from the beam management agenda. Nevertheless, performance monitoring-based approaches should also be considered as an alternative.
For consistency between training and inference for CSI prediction using UE-sided model, consider the use of the associated ID as the baseline.
Reuse the existing discussion and agreements on the beam management agenda for the associated ID framework and procedures as much as possible to reduce the discussion required for CSI prediction.
Consider performance monitoring-based methods as an alternative approach, allowing the UE to dynamically select and switch between multiple models based on real-time performance monitoring to identify the best model for CSI prediction.
Data Collection
Data Collection for training
Following the RAN1#120 meeting [3], it was agreed that for CSI prediction using a UE-side model, data collection for training should also follow the agreement.

To minimize signaling overhead effectively, it is recommended to reuse the same CSI-RS resources whenever possible. We propose to categorize the discussion into different types:
Periodic and Semi-Persistent: For periodic and semi-persistent CSI-RS, it is proposed to use the same CSI-RS resource(s) for both the model input measurements and the ground-truth CSI measurements. Since the interval of the observation window matches the interval of the prediction window, both being equal to the CSI-RS periodicity, this simplifies the configuration process and significantly reduces the signaling overhead.
Aperiodic CSI-RS: For aperiodic CSI-RS, the UE should measure the dedicated CSI-RS resource(s) specifically allocated for both measurement and ground-truth CSI. This implies that supporting aperiodic CSI-RS resources for data collection will cause substantial DCI signaling overhead. We suggest deprioritizing this approach.
For periodic and semi-persistent CSI-RS, use the same CSI-RS resource(s) for both model input measurements and the ground-truth CSI measurements.
Deprioritize aperiodic CSI-RS resource(s) due to the high DCI signalling overhead.
Data Collection mechanism
Regarding data collection for the UE-sided CSI prediction model, it is more convenient to collect the data on the UE-side for training, inference, and monitoring. Ensuring consistency between training and inference is crucial. Once this consistency is established, the next step is to design the triggering and requesting mechanism for UE-side data collection. Since the beam management case also involves a single-sided model, the corresponding configuration and mechanism can be reused.
For CSI prediction using UE-sided model, the data collection mechanism can leverage the Rel-19 AI/ML-based beam management cases as much as possible.
Capability Report
In addition to aligning the associated IDs, ensuring the CSI prediction capability is necessary for effective data collection, particularly regarding the observation window and the prediction window. This aspect can refer to the Rel-18 MIMO discussion. However, there may be different capability values for AI and non-AI methods. For example, in Rel-18 MIMO, the UE reports a value called , which represents the number of DD units and indicates how far it can predict. In case of AI-based CSI prediction, the UE can also report a similar format as  but with a different value compared to non-AI based CSI prediction. To differentiate between AI and non-AI cases, we could add an extra bit to the existing  value to indicate whether it represents AI or non-AI capability. The other potential capabilities of the UE that may need to be provided to the NW are: one bit to indicate whether it supports model fine-tuning, one bit to indicate whether it supports non-AI based CSI prediction (to determinate whether the model fallback process can be performed), and any other relevant information used for model monitoring.
For AI/ML-based CSI prediction, UE needs to report the prediction capability to NW. The prediction capability can be the same format as the  value defined in the Rel-18 MIMO. To distinguish between AI and non-AI capabilities, an extra bit can be added to the existing  value.
For AI/ML-based CSI prediction, UE needs to report the model monitoring related capabilities to NW. For example, one bit to indicate whether it supports model fine-tuning, one bit to indicate whether it supports non-AI based CSI prediction.
Model Monitoring
Monitoring Type
In the RAN1#117 meeting [4], the performance monitoring types have been analyzed: 

The monitoring metric will be discussed in section 3.2. Now we will focus on the need for further down selection. The following section will discuss the advantages and disadvantages of different types:
Type 1:
Based on our understanding, this type is most suitable for a UE-side model. The UE has the most autonomous control over its deployed UE-side model and can directly access the predicted CSI as well as the associated ground truth labels if periodic and semi-persistent CSI-RS resources are configured. These data can be directly utilized by the UE to calculate CSI prediction performance monitoring metrics and make informed decisions regarding functionality, which could be event-triggered. For instance, after the UE calculates the performance metrics, if it notices that the metrics have significantly deteriorated compared to the last monitoring period, the UE can send this feedback signal to the NW. This has specification impacts but allows, for example, the transmission of a 1-bit signal to indicate if the model is suitable or not. Moreover, if the UE has information on the time domain channel property (TDCP) or GNSS, it can even suggest switching functionalities or fallback options to the NW in cases where the UE lacks a model to support the current conditions. Conversely, if the performance metrics have not significantly changed, no action is necessary for both the UE and NW in terms of model adjustment. This event-triggered approach can significantly reduce reporting overhead while easing the NW's burden of monitoring numerous UEs within its service area.
The performance monitoring output from the UE could be used as a reference for adjusting the functionality control of the model, such as model deactivation, switching, fallback, etc. Subsequently, once the NW receives this performance monitoring output, it can make the final decision based on the returned value.
Type 2:
For Type 2, the only action required from the UE is to perform the AI/ML-based CSI prediction process. The monitoring processes are handled by the NW, including the calculation of performance metrics and decisions regarding model adjustments. To compute the performance metrics on the NW side, the UE needs to provide feedback on both the AI/ML model output and the ground truth. Although Type 2 can be supported by default because it does not need specification impact when considering the ground truth CSI as legacy codebook/PM rather than the overall channel information, this could lead to significant transmission overhead because feedback is required for both the output PMI and the ground truth PMI. This still results in significant overhead compared to providing a simple value such as monitoring output and metrics. If quantization is employed to reduce the overhead, the quantization error must also be taken into account. Furthermore, the NW needs to monitor a considerable number of serving UEs, receive a vast amount of data from them, and manage the associated processes. This will inevitably increase the NW’s load. Therefore, we suggest avoiding this approach since it is impractical and challenging to implement.
The only advantage of Type 2 is that the existing CSI reporting mechanism can be reused to transmit both the observed and predicted CSI, thus minimizing the impact on additional specifications.
Type 3:
Type 3 is a compromise version between Type 1 and Type 2. The UE calculates the performance metrics and provides feedback on them to the NW. Subsequently, based on this feedback, decisions regarding model switching, fallback, deactivation, etc., can be made by the NW. Furthermore, in this scenario, the UE could provide the additional information to assist the NW in determining whether to adjust the model. For example, it could offer feedback on assisting elements, such as TDCP specified in Rel-18 MIMO or UE speed from GNSS data. The NW can then decide whether to deactivate, switch, fallback, etc., based on these metrics and assistance information. In addition, the assistance information fed back from the UE can help determine which model should be switched to.
The overheads of Type 3 and Type 1 are difficult to compare because the UE needs to perform periodic monitoring and provide simple performance metrics to the NW in Type 3. On the other hand, Type 1 is event-triggered, and the performance monitoring output is also straightforward if it indicates the model adjustment decision. Therefore, strictly speaking, Type 1 may be the scenario that minimizes the overall reporting overhead. The overhead for Type 3 will be slightly higher than that for Type 1.
The UE reporting overhead is minimized when the event-triggered reporting is done in Type 1.
For the monitoring of CSI prediction, the following is the pros and cons, as well as the potential specification impacts of different types.

For type 1, the performance monitoring output from the UE could be used as a reference for adjusting the functionality control of model, such as model deactivation, switching, fallback, etc.
Monitoring Metric
Following the RAN1#120 meeting [3], it was agreed that performance monitoring types 1 and 3 are supported and that further discussion is needed to select the appropriate intermediate KPI.

Before discussing which intermediate KPI to use, we need to address the ground truth label format. If the ground truth label is the raw channel, then using NMSE as a performance metric is more reasonable since it directly reflects the predicted channel quality. Additionally, since NMSE does not have a close range, it is necessary to compare it with the previous results to ensure that the channel does not change significantly. For example, if the difference between the current NMSE and the NMSE calculated from the previous monitoring event exceeds a predefined threshold (i.e., ), it means the model may not be suitable, and a model switching process needs to be triggered. Conversely, if this criterion is met (i.e., ), it indicates that the model can continue to be used during inference. It is also important to note that if multiple feedback units are predicted, we need to check each time sample individually.
However, if the ground truth label format is based on the legacy codebook or PMI, then SGCS is more suitable as a performance metric. The SGCS value between the predicted and real codebooks can indicate the degree of similarity of their subspaces. Another advantage of SGCS is that the value ranges between [0,1], making it easier to specify. For considering SGCS for rank>1 and >1 cases, we can refer to the CSI compression use cases calculated from different options:
Option 1: Calculate the average SGCS over all multiple layers and all time samples
Option 2: Calculate the SGCS separately for each layer and each time sample 
Option 3: Calculate the SGCS for each time sample but average over multiples layers
Option 4: Calculate the SGCS for each layer but average over time samples
We tend to support Method 2 or Method 3 since long-term future predictions are less accurate. Therefore, it is important to consider predictions separately to avoid focusing only on the average and overlooking extreme values.
For the ground-truth format as raw channel type, use NMSE as the performance metrics for performance monitoring purpose.
For NMSE-based performance monitoring, calculate the difference between the NMSE values from the previous time and the current time as a monitoring metric. 
For the ground-truth format as codebook/PMI based, use SGCS as the performance metrics for performance monitoring purpose.
For SGCS calculation in rank>1 and >1 cases, consider the following options: 
Option 1: Calculate the average SGCS over all layers and all time samples
Option 2: Calculate the SGCS separately for each layer and each time sample 
Option 3: Calculate the SGCS for each time sample but average over multiples layers
Option 4: Calculate the SGCS for each layer but average over time samples
Conclusion
In summary, based on the above discussions, we have the following observations:
 The UE reporting overhead is minimized when the event-triggered reporting is done in Type 1.
For the monitoring of CSI prediction, the following is the pros and cons, as well as the potential specification impacts of different types.

In summary, based on the observations and further analysis, we have the following proposals:
For consistency between training and inference for CSI prediction using UE-sided model, consider the use of the associated ID as the baseline.
Reuse the existing discussion and agreements on the beam management agenda for the associated ID framework and procedures as much as possible to reduce the discussion required for CSI prediction.
Consider performance monitoring-based methods as an alternative approach, allowing the UE to dynamically select and switch between multiple models based on real-time performance monitoring to identify the best model for CSI prediction.
For periodic and semi-persistent CSI-RS, use the same CSI-RS resource(s) for both model input measurements and the ground-truth CSI measurements.
Deprioritize the support for aperiodic CSI-RS resource(s) due to the high DCI signalling overhead.
For CSI prediction using UE-sided model, the data collection mechanism can leverage the Rel-19 AI/ML-based beam management cases as much as possible.
For AI/ML-based CSI prediction, UE needs to report the prediction capability to NW. The prediction capability can be the same format as the  value defined in the Rel-18 MIMO. To distinguish between AI and non-AI capabilities, an extra bit can be added to the existing  value.
For AI/ML-based CSI prediction, UE needs to report the model monitoring related capabilities to NW. For example, one bit to indicate whether it supports model fine-tuning, one bit to indicate whether it supports non-AI based CSI prediction.
For type 1, the performance monitoring output from the UE could be used as a reference for adjusting the functionality control of model, such as model deactivation, switching, fallback, etc.
For the ground-truth format as raw channel type, use NMSE as the performance metrics for performance monitoring purpose.
For NMSE-based performance monitoring, calculate the difference between the NMSE values from the previous time and the current time as a monitoring metric. 
For the ground-truth format as codebook/PMI based, use SGCS as the performance metrics for performance monitoring purpose.
For SGCS calculation in rank>1 and >1 cases, consider the following options: 
Option 1: Calculate the average SGCS over all layers and all time samples
Option 2: Calculate the SGCS separately for each layer and each time sample 
Option 3: Calculate the SGCS for each time sample but average over multiples layers
Option 4: Calculate the SGCS for each layer but average over time samples
References
Chairman's Notes RAN1#118bis, Hefei, China, October 14th-18th, 2024.
R1-2409145	Summary #2 of CSI prediction	Moderator (LG Electronics)
Chairman's Notes RAN1#120, Athens, Greece, February 17th-21st, 2025. 
Chairman's Notes RAN1#117, Fukuoka City, Fukuoka, Japan, May 20th-24th, 2024.
Chairman's Notes RAN1#119, Orlando, US, November 18th-22nd, 2024

TDoc file conclusion not found

3GPP TSG RAN WG1 #120-bis								R1-2502735
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.3
Source:	AT&T
Title:	Discussion on AI/ML for CSI prediction
Document for:	Discussion/Approval

Conclusion
In this contribution, we discussed a sub-use case on CSI feedback enhancements related to time domain CSI prediction using UE sided model. We made the following proposals.

Observation 1: Site/cell specific models are able to outperform generalized AI/ML models for CSI prediction use case.

Proposal 1: NW can provide NW side additional conditions to assist the UE to categorize the data set for different cell/site/scenario/configuration.

Observation 2: NW side additional conditions can be used to train cell/site/scenario/configuration specific models for CSI prediction.

Proposal 2: NW side additional conditions can be used to ensure consistency between the training and inference of the UE sided AI/ML model for CSI prediction.

Observation 3: We can reuse similar framework and procedures as Beam Management use case for associated ID to ensure consistency between training and inference. 

Proposal 3: For consistency between training and inference for CSI prediction using UE-sided model, we propose the following:
Specify NW side additional conditions, which is to be indicated based on associated ID
UE may assume the same spatial relationship at gNB (e.g., antenna configuration, TXRU mapping) associated with the same associated ID.

Proposal 4: For CSI prediction using UE-side model, for performance monitoring, type 1 and type 3 performance monitoring are supported

3GPP TSG RAN WG1 #120bis			R1-2502757
Wuhan, China, April 7th – 11th, 2025
Source:	NTT DOCOMO, INC.
Title:	Discussion on AI/ML for CSI prediction
Agenda Item:	9.1.3
Document for: 	Discussion and Decision

Conclusion
In this contribution, we have the following observations and proposals,
Observation 1
The AI/ML-based BM session is working on the procedures for the UE capability report, model applicability report, and corresponding configurations for the UE.
The same procedures can be reused since both BM and CSI prediction are under the CSI framework.
There is no benefit from introducing differential signaling designs to the CSM framework for BM and CSI predictions.
Observation 2
Additional CSI resource configurations are needed for training or monitoring data collections.
For training or monitoring, additional CSI resources can be transmitted at/around times when CSI are predicted.
The CSI-RS resources for the three purposes can have different periodicity configurations, depending on the requirements of the inference, training, and monitoring.
Observation 3
For Type 1/3 monitoring, the dimension reduction methods can dramatically reduce the size of the CSI that the UE needs to buffer.
For Type 2 monitoring, the UE should report the ground truth to the NW after taking measurements on the predicted time instances, which causes overhead, latency, and performance loss due to CSI quantization/compression.
Proposal 1
Reuse the same LCM framework for the applicability report, CSI report configurations, and report activation specified for the AI/ML-based BM.
Do not introduce different signaling designs to the CSI framework for BM and CSI predictions, i.e., the associated ID is also supported for CSI prediction use cases naturally. 
Proposal 2
Configure separate CSI resources and reports for inference, monitoring, and training, respectively.
For monitoring, the dedicated CSI resource set(s) and the report configuration for monitoring are configured in a dedicated CSI report configuration used for monitoring (i.e., Option 2 discussed in BM session). 
For training data collection, the dedicated CSI resource set(s) are configured in a dedicated CSI report configuration, which is used for data collection. The report quantity can be set to null.
Proposal 3
Specify the performance monitoring for AI/ML-based CSI prediction, considering further down-selection between Type 1 and Type 3 monitoring.
Consider dimension reduction to reduce the requirements of the UE buffer size for Type 1/3 performance monitoring, e.g., configure the UE to report KPIs regarding only one or several subbands, time instances, and/or a subset of Tx ports.
Proposal 4
Support dedicated CPU pool for AI/ML-based CSI processing unit (ACPU) 
Proposal 5
If the additional processing time is introduced for AI-based CSI reporting, the additional processing time should not be dependent on UE capability.

3GPP TSG RAN WG1 #120-bis                                                                                                    R1-2502831 Wuhan, China, April 7th – 11th , 2025

Agenda item:		9.1.3
Source: 		Qualcomm Incorporated
Title: 			Specification support for CSI prediction
Document for:		Discussion and Decision

Conclusions
In this document, we have discussed aspects related to consistency between training and inference for AI/ML prediction use case. We have the following observations:
Observation 1: Configuration of AIML-based prediction may be needed to facilitate performance monitoring and apply proper CSI processing timeline, criteria and capabilities.
Observation 2: There are spec-transparent performance monitoring mechanisms for legacy non-AI features. The same logic can be applied to AIML-based CSI prediction.
Observation 3: Rank consistency between inference report and monitoring report may not be needed because different rank reporting on ground-truth and predicted CSI means already corresponds to bad prediction accuracy.
Observation 4: For Type 2 monitoring, rank consistency between inference report and monitoring report can be achieved with following options:
Existing specification of rank-restriction can be used to achieve dynamic rank consistency by configuring multiple A-CSI report configurations. 
Dynamic rank consistency can be achieved by either linking to the inference report or configuring rank restriction in DCI.
Observation 5: Align the measurement resource of the monitoring report on the predicted slot of the inference report can be achieved by configuring a respective starting location of the monitoring report.
For N4 = 1, it can be supported by existing spec with  
For N4 > 1, enhancement is needed by adding  , where  is the number of predicted slots in the inference report,  is the gap between the predicted slots in the inference report.
Observation 6: Type 1 / Type 3 monitoring is not a self-contained CSI process, it requires the UE to buffer previous inference results. The buffering cost may scale with number of subbands, number of prediction samples in temporal domain, and number of CCs. 
Observation 7: The buffering burden can be relaxed if L3 signalling or mechanism is used for performance monitoring.
Observation 8: L3 signalling and mechanism is sufficient for detecting performance drift.
Observation 9: Type 1 / 3 monitoring has higher specification effort than Type 2 monitoring.
Observation 10: AIML inference may be performed at a dedicated AI engine(e.g., AI/ML accelerator) different from where non-AIML functionalities are executed.
Observation 11: Different AM/ML functions may share a common AI engine. Timeline and processing criteria may be different for different use cases.
Observation 12: The timeline for each individual case depends on the specific model choice and hardware architecture.
Observation 13: The timeline requirement between measurement resource and report is related to AIML processing, but the additional offset between A-CSI trigger and the measurement resource may be less related to AIML processing.
Observation 14: Absorbing the model switching and loading time into nominal timeline of each individual use case would result in conservative timeline which reduces the benefits of CSI prediction.
Observation 15: Defining rule for model switching and loading time requires much higher specification impact and is complicated for UE and NW implementation.
Observation 16: Model switching and loading time may be always needed if switching between proprietary AIML feature and standardized feature.
Observation 17: There may be high-end UEs which have independent hardware for AIML than legacy algorithms, and also low-end UEs which may use common hardware for AIML and legacy algorithms.
Observation 18: CSI processing units depends on the model complexity, which may vary significantly across different use cases such as beam management, CSI prediction and CSI compression.
Observation 19: For UEs using independent hardware for AIML operation, the pre-processing and postprocessing may still run in the hardware used for non-AI features.
Observation 20: To enable implementation flexibility, the number of APUs for each AI/ML enabled CSI processing feature can be indicated via UE capability.
Observation 21: Rel-19 AIML-based CSI prediction is a separate CSI codebook / reporting compared to legacy R18 AIML doppler codebook though same codebook is used.
Observation 22: Rel-19 AIML-based CSI prediction should NOT have Rel-18 predicted CSI as prerequisite feature group.
Based on the observations, we propose:
Proposal 1: Reuse existing CSI report configuration with additional indication of AIML-based prediction, such as a 1-bit indication in the CSI report configuration or a new CSI report configuration for AIML prediction.
Proposal 2: Deprioritize specification of performance monitoring as it is not the necessary part of the feature considering spec-transparent mechanism is able to achieve the same functionality.
Proposal 3: Any standardized monitoring approach should require additional UE capability.
Proposal 4: If Type 2 monitoring is supported, consider following specification impact
Adding new starting location to the monitoring report being  , where  is the number of predicted slots in the inference report,  is the gap between the predicted slots in the inference report
Proposal 5: Do not support Type 1 or Type 3 monitoring considering the buffering effort at least for L1 signalling. If Type 1 / Type 3 monitoring is supported, consider using L3 signaling and mechanism.
Proposal 6: If Type 1 / 3 monitoring is supported, consider following specification impacts
Whether using CSI configuration framework or a new dedicated configuration especially for L3 approach.
New report quantity or metric, and its definition. Whether subband / wideband granularity is supported, whether the metric is average across samples in temporal domain.
Signalling design and the format of the content, e.g., new UCI  payload
UE-initiated reporting procedures including event definition, configured UL resource, etc.
Extension of CPU and active resource / port counting of the inference report to the monitoring report.
Proposal 7: Support UE capability reporting for the timeline of each individual use case. Further discuss whether the relaxed timeline with UE capability in R18 non-AIML based CSI prediction can be reused for AIML-based CSI prediction.
Proposal 8: Consider the additional latency of model switching time being absorbed into the nominal timeline for each individual case as benchmark.
Study the necessity of defining rule for defining additional latency of model switching considering whether the latency is negligible compared to nominal inference timeline.
Proposal 9: Study the latency requirements concurrent and non-concurrent AIML processing.
Proposal 10: With regards to the CPU pool for AI/ML-based CSI processing, support both of the following, as separate UE capabilities:
AI/ML shares the same CPU pool as legacy: the CPU pool for AI/ML-based CSI processing is shared with the legacy CPU pool.
Dedicated AI/ML CPU pool separate from legacy: there’s a dedicated CPU pool for AI/ML-based CSI processing (namely AI/ML processing unit-APU), which is separate from legacy CPU pool.
The dedicated CPU pool for AI/ML-based use cases is shared among AI/ML-based CSI processing use cases.
Proposal 12: For dedicated AI/ML PU pool, to run an AI/ML-enabled CSI processing task, the #CPUs required for that task should be counted towards both legacy CPU pool and AI/ML PU pool to account for the pre- and post-processing and memory needed to run the task, which would consume resources towards legacy CPU.
Proposal 13: Reuse the rule and framework for active CSI-RS resource and port counting. For AIML-based CSI prediction, UE report CSI-RS triplets for both AIML processing alone and concurrency processing with non-AIML CSI codebooks.
Proposal 14: For R19 AIML-based CSI prediction UE feature, copy FG 40-3-2-1 family (R16 eType II based prediction N4=1), FG 40-3-2-1a family (R16 eType II based prediction N4>1), FG 40-3-2-1b (max number of A-CSI-RS resource), FG 40-3-2-2 family (R16 eType II based prediction R=2), FG 40-3-2-3 family (CQI), FG 40-3-2-7 (starting location), FG 40-3-2-8, FG 40-3-2-9 and FG 40-3-2-10 by changing the feature group name to AIML-based CSI prediction.
Proposal 15: Support UE capability signalling for CSI-RS triplets concurrent processing of AIML-based CSI predication and other legacy CSI reports. The signalling granularity should be per-band and also per band-combination.
Proposal 16: Support UE capability signaling of processing units and timeline.
Proposal 17: Additional UE capability signalling is needed for standardized performance monitoring. If UE does not signal this capability, it means that performance monitoring is performed in spec-transparent manner.

3GPP TSG RAN WG1 #120bis			R1-2503056
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.1.3
Source: 	Moderator (LG Electronics)
Title: 	Summary #1 of CSI prediction
Document for:	Discussion and decision

Conclusion
For Rel-19 study on CSI prediction only, consider UE-sided model only.

Agreement
For CSI prediction evaluations, to verify the generalization/scalability performance of an AI/ML model over various configurations, to evaluate one or more of the following aspects:
Various UE speeds (e.g., 10km/h, 30km/h, 60km/h, 120km/h)
Various deployment scenarios
Various carrier frequencies (e.g., 2GHz, 3.5GHz)
Various frequency granularity assumptions
Various antenna port numbers (e.g., 32 ports, 16 ports)
To report the selected configurations for generalization verification
To report the method to achieve generalization over various configurations and/or to achieve scalability of the AI/ML input/output, including pre-processing, post-processing, etc.
To report generalization cases where multiple aspects (e.g., combination of above) are involved in one dataset, if adopted. 
To report the performance and requirement (e.g., updating filter parameters, convergence of filter) for non-AI/ML-based CSI prediction to handle the various scenarios/configurations.


Agreement
For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:
Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901. 
E.g., Dropped in a specific cell or within a specific boundary.
Option 2: By using a scenario/configuration specific to the local region. 
E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.
Note: While modelling the spatial correlation, strive to ensure that the dataset distribution also correctly captures the decorrelation due to temporal variations in the channel. To report methods to generate training and testing dataset.

3GPP TSG RAN WG1 #120bis			R1- 2503057 
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.1.3
Source: 	Moderator (LG Electronics)
Title: 	Summary #2 of CSI prediction
Document for:	Discussion and decision

Conclusion
For Rel-19 study on CSI prediction only, consider UE-sided model only.

Agreement
For CSI prediction evaluations, to verify the generalization/scalability performance of an AI/ML model over various configurations, to evaluate one or more of the following aspects:
Various UE speeds (e.g., 10km/h, 30km/h, 60km/h, 120km/h)
Various deployment scenarios
Various carrier frequencies (e.g., 2GHz, 3.5GHz)
Various frequency granularity assumptions
Various antenna port numbers (e.g., 32 ports, 16 ports)
To report the selected configurations for generalization verification
To report the method to achieve generalization over various configurations and/or to achieve scalability of the AI/ML input/output, including pre-processing, post-processing, etc.
To report generalization cases where multiple aspects (e.g., combination of above) are involved in one dataset, if adopted. 
To report the performance and requirement (e.g., updating filter parameters, convergence of filter) for non-AI/ML-based CSI prediction to handle the various scenarios/configurations.


Agreement
For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:
Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901. 
E.g., Dropped in a specific cell or within a specific boundary.
Option 2: By using a scenario/configuration specific to the local region. 
E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.
Note: While modelling the spatial correlation, strive to ensure that the dataset distribution also correctly captures the decorrelation due to temporal variations in the channel. To report methods to generate training and testing dataset.

3GPP TSG RAN WG1 #120bis			R1- 2503058 
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.1.3
Source: 	Moderator (LG Electronics)
Title: 	Summary #3 of CSI prediction
Document for:	Discussion and decision

Conclusion
For Rel-19 study on CSI prediction only, consider UE-sided model only.

Agreement
For CSI prediction evaluations, to verify the generalization/scalability performance of an AI/ML model over various configurations, to evaluate one or more of the following aspects:
Various UE speeds (e.g., 10km/h, 30km/h, 60km/h, 120km/h)
Various deployment scenarios
Various carrier frequencies (e.g., 2GHz, 3.5GHz)
Various frequency granularity assumptions
Various antenna port numbers (e.g., 32 ports, 16 ports)
To report the selected configurations for generalization verification
To report the method to achieve generalization over various configurations and/or to achieve scalability of the AI/ML input/output, including pre-processing, post-processing, etc.
To report generalization cases where multiple aspects (e.g., combination of above) are involved in one dataset, if adopted. 
To report the performance and requirement (e.g., updating filter parameters, convergence of filter) for non-AI/ML-based CSI prediction to handle the various scenarios/configurations.


Agreement
For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:
Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901. 
E.g., Dropped in a specific cell or within a specific boundary.
Option 2: By using a scenario/configuration specific to the local region. 
E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.
Note: While modelling the spatial correlation, strive to ensure that the dataset distribution also correctly captures the decorrelation due to temporal variations in the channel. To report methods to generate training and testing dataset.

3GPP TSG RAN WG1 #120bis			R1- 2503059 
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.1.3
Source: 	Moderator (LG Electronics)
Title: 	Summary #4 of CSI prediction
Document for:	Discussion and decision

Conclusion
For Rel-19 study on CSI prediction only, consider UE-sided model only.

Agreement
For CSI prediction evaluations, to verify the generalization/scalability performance of an AI/ML model over various configurations, to evaluate one or more of the following aspects:
Various UE speeds (e.g., 10km/h, 30km/h, 60km/h, 120km/h)
Various deployment scenarios
Various carrier frequencies (e.g., 2GHz, 3.5GHz)
Various frequency granularity assumptions
Various antenna port numbers (e.g., 32 ports, 16 ports)
To report the selected configurations for generalization verification
To report the method to achieve generalization over various configurations and/or to achieve scalability of the AI/ML input/output, including pre-processing, post-processing, etc.
To report generalization cases where multiple aspects (e.g., combination of above) are involved in one dataset, if adopted. 
To report the performance and requirement (e.g., updating filter parameters, convergence of filter) for non-AI/ML-based CSI prediction to handle the various scenarios/configurations.


Agreement
For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:
Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901. 
E.g., Dropped in a specific cell or within a specific boundary.
Option 2: By using a scenario/configuration specific to the local region. 
E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.
Note: While modelling the spatial correlation, strive to ensure that the dataset distribution also correctly captures the decorrelation due to temporal variations in the channel. To report methods to generate training and testing dataset.

3GPP TSG RAN WG1 #120bis			R1- 2503139 
Wuhan, China, April 7th – 11st, 2025

Agenda Item:	9.1.3
Source: 	Moderator (LG Electronics)
Title: 	Summary #5 of CSI prediction
Document for:	Discussion and decision

Conclusion
For Rel-19 study on CSI prediction only, consider UE-sided model only.

Agreement
For CSI prediction evaluations, to verify the generalization/scalability performance of an AI/ML model over various configurations, to evaluate one or more of the following aspects:
Various UE speeds (e.g., 10km/h, 30km/h, 60km/h, 120km/h)
Various deployment scenarios
Various carrier frequencies (e.g., 2GHz, 3.5GHz)
Various frequency granularity assumptions
Various antenna port numbers (e.g., 32 ports, 16 ports)
To report the selected configurations for generalization verification
To report the method to achieve generalization over various configurations and/or to achieve scalability of the AI/ML input/output, including pre-processing, post-processing, etc.
To report generalization cases where multiple aspects (e.g., combination of above) are involved in one dataset, if adopted. 
To report the performance and requirement (e.g., updating filter parameters, convergence of filter) for non-AI/ML-based CSI prediction to handle the various scenarios/configurations.


Agreement
For the evaluation of AI/ML-based CSI prediction using localized models in Release 19, consider the following options as a starting point to model the spatial correlation in the dataset for a local region:
Option 1: The dataset is derived from UEs dropped within the local region, with spatial consistency modelling as per TR 38.901. 
E.g., Dropped in a specific cell or within a specific boundary.
Option 2: By using a scenario/configuration specific to the local region. 
E.g., Indoor-outdoor ratio, LOS-NLOS ratio, TXRU mapping, etc.
Note: While modelling the spatial correlation, strive to ensure that the dataset distribution also correctly captures the decorrelation due to temporal variations in the channel. To report methods to generate training and testing dataset.