3GPP TSG RAN WG1 Meeting #121	R1-2503232
St. Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	9.1.3	
Source:	Futurewei
Title:	Discussion on CSI Processing Unit for AI/ML-based CSI prediction 
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: Supporting the sharing of AI/ML-based computing resources among different AI/ML features and use cases 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. 

Proposal 1: Support the sharing of AI/ML-based computing resources (i.e., AI/ML Processing Units) among different AI/ML features and use cases, including AI/ML-based beam management, CSI compression/prediction, and positioning, for R19.

Proposal 2: Define a new timeline for APU calculation and reporting.

Proposal 3: UE considers model (un)loading, (de)activation, switching, and inference time when calculating the time needed for AI/ML-based processing, but only reports the total time needed as UE capability for APU-based timeline reporting.

Observation 2: The time required for model inference, (de)activation, and (un)loading can vary significantly over time due to many reasons. Therefore, the time it takes for a UE to calculate and report the number of APUs may vary by the different types of UEs, and it could vary from time to time even for the same UE. The new timeline framework should allow the UE to report updates of its APU timeline, enabling the network to configure/control CSI reporting parameters more accurately.

Proposal 4: For CSI prediction using UE-sided model, regarding whether OAPU and OCPU are based on defined rules and/or reported by UE for inference:
For Option 1 and Option 3, OAPU  is  reported by the UE, while OCPU  can be based on defined rules.
For Option 2, OCPU  is reported by the UE.

3GPP TSG-RAN WG1 Meeting #121	R1-2503246
St Julian’s, Malta, May 19th – 23rd, 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	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 6	For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, Alt 2 is not supported, since
a.	Alt2 causes high computational complexity at UE
b.	NW has other low complexity methods to compare the AI CSI prediction performance with nearest historic CSI baseline approach
c.	even if SGCS comparation between AI CSI prediction and nearest historic CSI baseline is needed, it can be supported via Alt1 by NW implementation.
Observation 7	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 8	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.
Observation 9	There is no need of specification enhancement to ensure consistency between model training and model inference for CSI prediction use case (UE-sided model) regarding at least the following aspects: UE speed, deployment scenario, carrier frequency, and UEdistribution.
Observation 10	A localized model gives in most cases only minor gain compared to a model trained on general data.
Observation 11	The inconsistency issue identified for the UE-sided spatial beam prediction use case (impact on UE assumptions on beams of Set A/Set B) is not appliable for the UE-side CSI prediction use case, which is for temporal CSI prediction.
Observation 12	Compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to a certain NW antenna down tilt value #B applied for inference with the same NW antenna tilt value #B
	For generalization Case 2, generalized performance can be achieved for NW antenna tilt value #A
o	0-4% degradation when the aspects #A is (NW antenna tilt = 0 degree) and the aspects #B is (NW antenna tilt is 10 degrees).
o	0-1% degradation when the aspects #A is (NW antenna tilt = 10 degree) and the aspects #B is (NW antenna tilt is 0 degrees).
Observation 13	The NW antenna down tilt value has negligible impact on the UE-side CSI prediction model design and performance.
Observation 14	When all cells use the same TXRU mapping, compared to the generalization Case 1 where the AI/ML model is trained with dataset subject to a certain NW TXRU mapping #B applied for inference with the same NW TXRU mapping #B
	For generalization case 2, generalized performance can be achieved for NW TXRU mapping #A
o	-1~1% degradation when the aspects #A is (subarray size is 4x1) and the aspects #B is (subarray size is 1x1).
o	-3~0% degradation when the aspects #A is (subarray size is 6x1) and the aspects #B is (subarray size is 1x1).
o	0~3% degradation when the aspects #A is (subarray size is 1x1) and the aspects #B is (subarray size is 4x1).
o	-1~0% degradation when the aspects #A is (subarray size is 6x1) and the aspects #B is (subarray size is 4x1).
o	0~3% degradation when the aspects #A is (subarray size is 1x1) and the aspects #B is (subarray size is 6x1).
o	0~3% degradation when the aspects #A is (subarray size is 4x1) and the aspects #B is (subarray size is 6x1).
Observation 15	When cells use different TXRU mapping (the first group of cells use 1x1 subarray, the second group of cells uses 4x1 subarray), compared to the generalization Case 1, the generalization Case 2-a/b/c introduces -1~4% degradation.
Observation 16	The NW TXRU mapping has negligible impact on the UE-side CSI prediction model design and performance, no matter different cells use the same TXRU mapping or different TXRU mappings.

Based on the discussion in the previous sections we propose the following:
Proposal 1	For UE-sided CSI prediction use case, at least for training data collection, 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	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 5	For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, support only Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI, where
	A SGCS value of an inference reporting is averaged over all configured sub-bands
	For rank>1 or , the SGCS value is reported per MIMO layer per prediction instance.
	Report quantized SGCS in the range of 0.3 to 1 with 0.1 granularity.
Proposal 6	For CSI prediction using UE-side model, support a dedicated CSI report configuration for performance monitoring reporting in L1 signaling, which includes at least
a.	an inference report configuration ID, or a CSI-RS resource set for obtaining model input
b.	a CSI-RS resource set for obtaining ground truth CSI.
Proposal 7	For CSI prediction using UE-side model, for the aspect of CSI processing criteria for model inference, down-select to support a single option, preferably option 1, where the number of occupied APU, OAPU, and the total number of APUs are reported as part of the UE capability.
Proposal 8	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.
Proposal 9	Reuse the legacy framework regarding active CSI-RS resource and port counting for AI CSI prediction use case.
Proposal 10	Conclude that there is no need of specification enhancement to ensure consistency between model training and model inference for CSI prediction use case (UE-sided model).

4 

3GPP TSG-RAN WG1 Meeting #121	R1-2503253
St Julian’s, Malta, May 19 – 23, 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: 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 2: 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: For training data collection of UE-side model, one CSI-ResourceConfig can be configured for UE measurement to obtain both model input and label.
Note: label corresponding to the time slots without CSI-RS of CSI-ResourceConfig can be obtained by UE side implementation with extrapolation or interpolation.
Proposal 2: For training data collection of UE-side model, the ReportQuantity can be set to ‘none’ to indicate without CSI report in CSI-ReportConfig.
Proposal 3: For training data collection, gNB indicates the preferred inference related information as guidance to facilitate UE side training, e.g.,
Prediction window related information, including the candidate time gap between the earliest of N4 predicted instances and the reference time (e.g., CSI-RS occasion), the time unit of predicted instance (i.e., d), and number of predicted time instances (i.e., N4).
Observation window related information, including the number of A-CSI-RS for channel measurement (i.e., K) at the inference phase.
Proposal 4: For Type 2 monitoring, to enable the UE to avoid the disordered layers between the inference CSI and the measured CSI subject to the monitoring CSI report, the linkage between the inference CSI report and the monitoring CSI report should be indicated to UE.
Note: The format of the ground-truth CSI can be the same as a legacy CSI codebook.
Proposal 5: For the report of monitoring results for Type 3 monitoring, consider L1 signaling considering:
More stringent latency requirements for monitoring report.
Ensuring a unified signaling framework with UE assisted monitoring beam management which has already agreed to adopt L1 signaling.
Proposal 6: For Type 3 monitoring, support Alt.1 (one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI).
The SGCS can be calculated individually for each layer (l=1,…,v) and each prediction instance (n4=1,…,N4), and averaged over subbands (n3=1,…,N3).
Proposal 7: For the CSI report configuration of monitoring Type 3:
Reuse the agreed mechanism for the beam management case, i.e., a dedicated CSI report for performance monitoring is configured for monitoring the inference results of the inference CSI report.
To indicate the linkage between the monitoring CSI report and the inference CSI report, the associated CSI-ReportConfigId of the inference CSI report configuration is 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 corresponding predicted result.
The SGCS values for all the N4 prediction instances of the associated inference CSI report are included in the monitoring CSI report.
Proposal 8: Regarding the occupancy of AI/ML PU and legacy CPU for AI/ML-based CSI report, for inference, support both Option 2 and Option 3 with UE capability to report the selected option.
Option 2: only legacy CPU is occupied.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied.
Equal occupancy duration can be assumed for AI/ML PU and legacy CPU.
Proposal 9: Regarding the AI/ML PU pool over use cases, at least support the total number of dedicated AI/ML PU is shared among CSI report related use cases, e.g., AI/ML-based BM and AI/ML-based CSI prediction.
Proposal 10: For PU occupancy Option 3 (both dedicated AI/ML PU and legacy CPU are occupied), the PU occupancy order for two pools can be updated as: among the simultaneous CSI reports ordered from high priority to low priority,
For a specific CSI report subject to Option 3:
if both the unoccupied AI/ML PU and the unoccupied legacy CPU can satisfy the required AI/ML PU and required legacy CPU of the CSI report, respectively, the CSI report is required to update, and both PUs are occupied;
otherwise, if any of the unoccupied PU cannot satisfy the corresponding required PU by the CSI report, the CSI report is not required to update, and neither of the PUs is occupied.
If the AI/ML PU pool is fully occupied, the CPU pool, if not fully occupied, can still serve the CSI reports that only require the legacy CPU.
Proposal 11: Regarding the CPU occupancy rule for LCM procedures:
For inference: reuse the occupancy duration of Rel-18 CSI prediction, i.e.,
from DCI till the scheduled PUSCH for A-CSI inference report.
from the Kp-th latest consecutive P/SP-CSI-RS occasion till the corresponding PUSCH for SP-CSI inference report.
For training data collection, reuse the legacy CPU occupancy rule subject to report quantity of ‘none’, i.e., from the first symbol of each P/SP-CSI-RS occasion, till Z3’ symbols after the P/SP-CSI-RS occasion.
AI/ML PU is not occupied.
For monitoring Type 3, if a dedicated CSI report is configured to the monitoring CSI, the CPU for a monitoring CSI report is occupied:
from DCI till the scheduled PUSCH for A-CSI monitoring report.
from the N4-th latest consecutive P/SP-CSI-RS occasion till the corresponding PUSCH for SP-CSI monitoring report.
AI/ML PU is not occupied.
Proposal 12: 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 13: 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 (Zref).
If the functionality is subject to “inactive state”, the CSI processing is subject to a longer timeline (Zref+ΔT) as it additionally includes the activation delay of ΔT.
Proposal 14: 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 15: 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 16: 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 17: For AI/ML model at the UE-side, differentiate the priority of AI/ML-based CSI reporting types over LCM procedures.
E.g., update the CSI priority formula as , where m=0 for monitoring CSI, m=1 for inference CSI or legacy CSI, and m=2 for training data collection CSI.
Proposal 18: For functionality alignment, the general signalling procedure agreed by RAN2 (Step 1~Step 5) and the Option A and Option B agreed by RAN1 (except for the associated ID part) for the beam management case can be reused for CSI prediction.
Proposal 19: For functionality alignment, regarding the set of inference related parameters provided by NW in Step 3 subject to Option B, consider CSI prediction 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.

3GPP TSG RAN WG1 #121                                                           R1-2503349
St Julian’s, Malta, May 19th – 23th, 2025

Source:	vivo
Title:	Remaining issues on specification support for 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.
For CSI prediction, when a UE requests training data collection, it needs to report the UE's preferred CSI-RS configuration and parameters related to prediction window.
For UE-side model, for AI/ML based CSI prediction, for processing of a CSI report for inference, support the following options:
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE capability
Option 2: only legacy CPU is occupied,   it is reported by UE capability, where M is a multiple of the number of CPUs occupied by legacy non-AI CSI prediction report with the same configuration.
Note: The supported option by UE is reported by UE capability.
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
Step 5: release model/AI resource in AI engine

Proposal: for AIML functionality switching/activation, consider the following value range for defining timeline in step1/3:
For the monitoring of N4>1 inference, only one (the f-th) from the N4 DD units is monitored, where f is configured in CSI report config for monitoring.
SGCS is only defined as wideband.
SGCS is defined per layer.
Support the SGCS report method Alt 1.
Supports reuse of existing CSI reporting framework for performance monitoring report.
Add SGCS as a new report quantity and report SGCS in L1 signaling
Quantize the SGCS in linear domain or dB domain, and form a sequence of maximum 4 layers in order, with each layer occupying 4bits, and  the total bit width is 16 bits
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 as following.
Support that the codebook configuration for ground truth CSI is an eType 2 codebook configured in the monitoring report config.
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 121	R1-2503448
Malta, Malta, May 17 – 21, 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 training data collection, a new RRC parameter is introduced to distinguish between CSI reporting configurations for data collection and inference.
 : For CSI prediction, when a UE requests data collection for training, the reuse of the SR mechanism should be supported, such as using a specific SR. 
:For CSI prediction using UE-side model, dynamically update the number of predicted CSI should be supported.   
 : For inference, we prefer option 1 and/or option 2. If multiple options are supported, the applied option will depends on the UE’s capability. 
: For CSI prediction using a UE-side model, the CSI processing criteria and timeline should be further discussed for different stages of model operation.
: For AI-based CSI prediction, the priority value calculation for inference CSI reporting can reuse the legacy formula Prii,CSI(y,k,c,s). 
: For the same functionality, AI-based CSI reporting has a higher priority than legacy CSI reporting regardless of the value of Prii,CSI(y,k,c,s). 
: For CSI prediction using the UE-side model, the periodic or semi-persistent CSI-RS resource can be utilized for both model inference and performance monitoring simultaneously. 
:For aperiodic CSI measurement and reporting, additional aperiodic CSI-RS resources should be configured to enable performance monitoring.  
: For the reporting contents of the UE-assisted performance monitoring, Alternative 1 is sufficient. 
: For reporting contents of UE-assisted performance monitoring, support reporting per prediction instance.  
: For the reporting contents of UE-assisted performance monitoring, support calculating the SGCS value based on the averaged over subbands.
: For reporting contents of UE-assisted performance monitoring, at least per-layer reporting should be supported. 
: For performance monitoring metric reporting,  equal interval quantization is sufficient.
:For performance monitoring metric reporting, only the legacy CPU is utilized, and .
:For the priority of performance monitoring metric reporting, both AI-based beam management and AI-based CSI prediction should be discussed together. The priority determination should take into account whether the associated CSI reporting carrier includes L1-RSRP or L1-SINR. 
: No specification enhancements are needed to ensure consistency between model training and model inference.
 

3GPP TSG RAN WG1 #121		R1-2503507
St Julian's, Malta, 19th – 23rd May 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 data collection for training, for resource configuration, whether to separately configure CSI-RS resource(s) for model input and for ground-truth CSI depends on whether measurement interval and prediction interval are required to be the same.
Proposal 2: For data collection for performance monitoring, dedicated resource set(s) for monitoring and report configuration for monitoring can be configured in a dedicated CSI report configuration
•	The ID of an inference report configuration is configured in the configuration for monitoring to link the inference report configuration and monitoring report configuration.
Proposal 3: For processing of a CSI report for inference, support Option 2: only legacy CPU is occupied.
Proposal 4: Regarding CSI prediction with UE-sided model, deprioritize performance monitoring type 2.
Proposal 5: For the reporting contents of UE assisted performance monitoring, support Alt 3: statistic of reporting contents of inference reporting instances within configured monitoring window.

3GPP TSG RAN WG1 #121		                         R1-2503552 St. Julian’s, Malta, May 19th–24th, 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. 

 
Observation#3: For the AI/ML based CSI prediction using UE-side model, for CSI report configuration for training data collection purpose, 
1)       The UE is not expected to report CSI for data collection purpose, i.e., the higher layer parameter for reportQuantity can be set to ‘none’. Moreover, such configuration does not require parameter for codebookType. 
2)       RAN1 need to address how to manage the processing unit and their occupancy for CSI report configuration for data collection purpose. 
3)       RAN1 need to address how to determine the active CSI-RS resources and the active CSI-RS ports when the resources are referred by a report configuration for data collection. Whether the same scaling factor  is applied as in the case wherein the CSI-ReportConfig configured with the higher layer parameter codebookType set to 'typeII-Doppler-r18'. 

Observation#4: 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#2: For the AI/ML based CSI prediction using UE-side model, for CSI report configuration for training data collection purpose, 
The UE is not expected to report CSI for data collection purpose, i.e., the higher layer parameter reportQuantity is set to ‘none’, Codebook (‘codebookType’) is not configured. 
To differentiate the report configuration from other report configurations with reportQuantity set to ‘none’, consider explicit indication of resources (CMRs) for data collection purpose, e.g., higher layer parameter resourcesForDataCollection    ‘CSI-ResourceConfigId’. 

Proposal#3: For the AI/ML based CSI prediction using UE-side model, for CSI report configuration for training data collection
-         processing units are counted toward the legacy CSI processing unit (CPU), where  is the number of CSI-RS resource(s) in the CSI-RS resource set for channel measurement.  
-        For each of P/SP CSI-RS transmission occasions, the CPU is occupied from the first symbol of the earliest CSI-RS resource until  after the last symbol of the latest CSI-RS resource for data collection. 
o      FFS: whether new value for 
-        For the active CSI-RS resources and active CSI-RS ports counting, a scaling factor is not applied, i.e., . 

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

Observation#5: For the AI/ML based CSI prediction using UE-side model, among the alternatives of the reporting contents of UE assisted performance monitoring, 
Alt2, as compared to Alt1, provides more information for the network to preform LCM decision, e.g., fall-back to non-predicted CSI. 
Alt2, if no restriction is applied, requires a large specification effort, e.g., codebook and CSI timeline for non-predicted CSI
Alt2, if no restriction is applied, may increase UE complexity, UE requires to compute three PMIs for each of monitoring instances. 

Observation#6: For the AI/ML based CSI prediction using UE-side model, for Alt2 of the reporting contents of UE assisted performance monitoring, when the latest CMR for inference report and the earliest MMR for the corresponding monitoring report are located in the reference slot of the inference reporting instance, i.e., by configuring higher layer parameter predictionDelay as , 
-        The baseline CSI (non-predicted precoder) is the same as the precoder corresponding to  of predicted PMI  in the inference report. 
-        For , the UE may calculate the second SGCS values based on the predicted PMI in the inference report, i.e., precoders corresponding to   and the ground-truth precoding vectors corresponding to .
Note: The second SGCS in Alt2 is based on the ground truth CSI and the non-predicted CSI corresponding to the latest CSI-RS transmission occasion not later than the CSI reference resource of the inference-reporting instance.

Proposal#5: Considering RAN1#121 is the last meeting of Rel-19 normative work and to address UE complexity, for the reporting contents alternatives of UE assisted performance monitoring, support Alt 2, only if 
-        prediction delay is configured as   
-        the latest CMR for inference report instance and the earliest MMR for the corresponding monitoring are in the reference slot of the inference reporting instance.  

Proposal#6: For the AI/ML based CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, support 
-        Performance monitoring KPI reporting per MIMO layer,  where  is the reported rank for the corresponding inference reporting instance. 
-        Performance  monitoring KPI reporting per prediction instance, 
o        The UE determines the value  for monitoring report based on the higher layer parameter vectorLengthDD  in the CSI report configuration for inference.  
-        Performance monitoring KPI reporting per wideband frequency granularity by averaging across the subband level SGCS values calculated per PMI reporting subbands indexed by 
o        The UE determines the value  for monitoring report based on the higher layer parameter reportFreqConfiguration  and  numberOfPMI-SubbandsPerCQI-Subband  in the CSI report configuration for inference.  

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, for the quantization of the reported SGCS values, support linear quantization of the SGCS values as monitoring KPIs
-        The network configures the UE to report SGCS with a certain range [] with quantization level  and reporting bitwidth . The range [] is configured per layer per prediction instance. 
-          The UE may determines the quantization level  . 
-          The reported bits  wherein and reperenst the MSB and LSB bits, respectively, correspond to a value, . 
-          For the calculated value, , the UE determines and report the   corresponding to the value .

Proposal#9: For the AI/ML based CSI prediction using UE-side model, for monitoring report configuration, RAN1 to support L1 reporting and address the following issues 
Processing unit and occupancy 
UCI construction and reporting priority for monitoring quantities.  

Observation#7: The UE may execute the configurations for AI/ML related features/functionalities partly or fully on a different hardware unit (processing resource) than legacy CSI.


Proposal#10: For CSI prediction using UE side model, for inference,
Support Option 3: both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied
Follow the legacy rule for OCPU as defined for the case when the UE is configured with CSI report configuration with codebookType set to ‘typeII-Doppler-r18’
The UE reports OAPU from a specified candidate values. 

3GPP TSG RAN WG1 #121	R1-2503650
St Julian’s, Malta, May 19th–23rd, 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 AI/ML based CSI prediction, for NW side additional condition:
Proposal 1: Considering RAN1#121 is the last RAN1 meeting of Rel-19, RAN1 prioritizes other essential issues in AI CSI prediction agenda instead of spending time on this controversial additional condition issue.

For reporting content for AI/ML based CSI prediction, for performance monitoring:
Observation 1. For performance monitoring Alt. 2 for AI/ML based CSI prediction, the SGCS determined by two CSI measured at different CSI-RS transmission occasion does not have prior information about the UE side model.
Observation 2. For performance monitoring Alt. 3 for AI/ML based CSI prediction, more open issues need to be clarified compared with Alt.1 and Alt.2
How to indicate the time/frequency/spatial domain samples;
How to determine the averaged SGCS, e.g., apply equal weight to time/frequency/spatial domain, or apply different weight to time/frequency/spatial domain, but apply equal weight within time/frequency/spatial domain;
Proposal 2. For performance monitoring for AI/ML based CSI prediction, support alt 1 as the baseline for reporting content discussion.
Proposal 3. For reporting contents for performance monitoring, in addition to the wideband SGCS as default configuration, UE can further support SGCS reporting on the first/last time instance, the layer with the largest singular value.
Proposal 4. For reporting contents for performance monitoring, for quantization, support at most a 4-bit quantization for SGCS reporting.
Proposal 5. For AI/ML based CSI prediction, for performance monitoring, support L1 signaling for monitoring report.
For priority rule of monitoring report, reuse other quality metric reporting rule such as CQI as a starting point.
Proposal 6. For data collection for performance monitoring, support P/SP/AP CSI-RS configuration.

For AI/ML based CSI prediction, for PU occupation for inference:
Observation 3: For AI/ML based CSI prediction, the complexity for SGCS determination scales with , which should be considered for PU occupation discussion.
Observation 4: For CSI prediction using UE side model, for inference, whether the UE supports option 1, option 2 and/or option 3 is up to UE capability.
Observation 5: For CSI prediction using UE side model, for inference, option 1 and option 2 have smaller specification impact than option 3.
Proposal 7: For CSI prediction using UE side model, for inference, support option 1 and option 2 for UE side AI/ML PU management. 
Proposal 8: For CSI processing timeline for CSI prediction using UE side model, reuse the legacy CSI processing timeline as a starting point for both option 1 and option 2.

For RS configuration for training data collection:
Observation 6: For UE side training data collection, separate configuration of CSI-RS would cause twice as much CSI resource configuration overhead.
Proposal 9: For UE side training data collection, support single configuration for model input and ground truth CSI.

3GPP TSG-RAN WG1 Meeting #121	R1-2503749
St Julian's, Malta, 19 - 23 May, 2025

Agenda Item:	9.1.3
Source: 	Quectel
Title: 	Specification Support for CSI Prediction
Document for:   Discussion and decision

Conclusion
In this contribution, we discussed the topics on CSI prediction with AI/ML models, and our proposal is summarized as below: 

Proposal 1：
For AI-based CSI prediction systems, preserving the layer-distinctive characteristics becomes critical for maintaining spatial multiplexing gains and beamforming accuracy, while proper SGCS calculation methodologies must account for per-layer performance variations to ensure meaningful monitoring metrics. SGCS can be calculated separately for each layer.

Proposal 2：
Massive MIMO systems with high layer counts can employ layer-averaged SGCS reporting to significantly reduce uplink signalling overhead while maintaining system-level accuracy assessment, since the spatial-domain averaging method preserves macroscopic performance trends through strong correlation with end-to-end throughput. 

Proposal 3：
In MIMO systems, specifically configuring SGCS reporting solely for the first layer is neither necessary nor recommended since the training and inference behaviors in the first layer don't generalize to other layers and the layer-wise SGCS reporting approach inherently includes first-layer data.

Proposal 4：
From a temporal domain perspective, CSI prediction accuracy naturally degrades for farther prediction instances due to channel aging effects, per-instance SGCS calculation is essential for meaningful performance evaluation.

Proposal 5：
The frequency granularity for SGCS reporting can be configured through per wideband, per subband, averaged over subband or selected subband, each offering distinct suitability to scenarios and tradeoffs between accuracy and signaling overhead.

Proposal 6：
When considering AI/ML-based data collection scenarios, using ReportQuantity = "none" may serve as a valid configuration to indicate that no CSI feedback is required, since the primary objective shifts to raw channel data acquisition for model training rather than traditional link adaptation.

Proposal 7：
The system requires explicit RRC layer reconfiguration to reactivate CSI reporting including PMI/RI/CQI after completing the AI/ML training phase.

3GPP TSG RAN WG1 #121                                              R1-2503772
St Julian’s, Malta, May 19th – 23rd, 2025

Source: 	CATT
Title:	Discussion on 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: The dedicated AI/ML PU should be shared among CSI related AI/ML features/functionalities.
Proposal 2: For CSI prediction, for inference, all three options for processing unit are supported. UE should report supported option(s) subject to UE capability.
If UE supports multiple options, NW can configure one of the UE supported options to determine the kind of occupied processing units.
Proposal 3: For UE side AI/ML-based CSI processing, UE should report the model complexity or UE capability related information to determine the occupied AI/ML PU or legacy CPU.
Proposal 4: To determine the occupation duration of AI/ML PU and legacy CPU, reuse the legacy occupation time of non-AI CSI prediction.
Proposal 5: For determination of OCPU for performance monitoring of CSI prediction, consider:
the value of N4;
the configuration for calculating performance metric, e.g., how many layers and how many samples are used.
Proposal 6: For data collection of AI/ML based CSI prediction, OCPU=0.
Proposal 7: For AI/ML based CSI reporting, whether a different timeline is needed when functionality switches/activates is based on UE capability.
Proposal 8: 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 9: The parameter k in legacy priority rule can be extended according to reportQuantity and other information in CSI-ReportConfig to distinguish the AI CSI report and legacy CSI report, or to distinguish the inference or monitoring report.
Proposal 10: 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 11: For CSI prediction using UE-sided model, support to reuse CSI framework for the configuration for monitoring result report in L1 signaling.
Configure a dedicated CSI report for performance monitoring, and the ID of an inference report is configured in the monitoring report.
Proposal 12: For 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 13: For report content of Type 3 performance monitoring of CSI prediction, support Alt 1, where the reported SGCS can be averaged over multiple samples.
Proposal 14: For report content of Type 3 performance monitoring of CSI prediction, the SGCS is reported with the following granularities:
report SGCS of selected instance(s) from N4 prediction instances, where the specific instance(s) can be configured by the network;
report SGCS averaged over subband(s);
report SGCS of per layer or only the first layer.
Proposal 15: For performance monitoring of AI/ML based CSI prediction, 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 16: For performance monitoring of CSI prediction, the performance metric of the f-th time instance is calculated based on N latest transmission occasion(s) of monitoring resource with linked time instance, no later than CSI reference resource corresponding to the CSI report for monitoring
measurement result of a transmission occasion of the CSI-RS resources for monitoring is linked with the f-th time instance for prediction, where the f-th time instance has the minimal slot offset to the transmission occasion of the CSI-RS resources for monitoring
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring.
Proposal 17: 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 18: 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, in case the intervals between instances within the measurement window are identical to those in the prediction window;
Option 2: Configure two separate resources in the CSI report configuration, in case the intervals between instances within the measurement window are different to those in the prediction window.
Proposal 19：For CSI prediction using UE-sided model, for data collection for training, UE can request the specific RS configuration for data collection.
Proposal 20: 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 #121			R1-2503822
St Julian’s, Malta, May 19th – 23rd, 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 observations are made:
Observation 1: If consider statistic of reporting contents of inference reporting instances within configured monitoring window as reporting contents of UE assisted performance monitoring, it only can be used for semi-persistent CSI report for inference associated with a semi-persistent CSI report for monitoring with periodic or semi-persistent CSI-RS resources for monitoring.
Observation 2: If consider statistic of reporting contents of inference reporting instances within configured monitoring window as reporting contents of UE assisted performance monitoring, then we should study whether multiple CSI-RS resources for monitoring are needed to associate with multiple CSI report occasions for inference in one CSI report. 

And we have the following proposals:
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 CSI prediction using UE-side model, support Alt 1 as reporting contents of UE assisted performance monitoring. 
-	Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI
Proposal 3: Support SGCS is reported per prediction instance or selected prediction instance(s) for AI/ML based CSI prediction.
Proposal 4: Support SGCS is reported per layer, for AI/ML based CSI prediction.
Proposal 5: Support SGCS can be averaged across subband or per wideband, for AI/ML based CSI prediction.
Proposal 6: The reported SGCS is a uniformly quantized value between the NW configured or fixed range, and the resolution of reported SGCS can be NW configured or fixed.
Proposal 7: For AI based CSI prediction, for Type 3 monitoring, support the following combination for inference report type and monitoring report type: 
Proposal 8: For CSI prediction using UE side model, for inference, support Option 1 and Option 2:
Option 1: only dedicated AI/ML PU (OAPU) is occupied
Option 2: only legacy CPU (OCPU) is occupied
Note: The supported option by UE is reported by UE capability and UE can only support either of them, not both
The total number of dedicated AI/ML PU for AI/ML is reported by UE capability. 
Proposal 9: For CSI prediction using UE side model, for inference, the number of occupied OAPU and OCPU in Option 1 and Option 2 are reported by UE capability.
Proposal 10: 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 11: For CSI prediction using UE-side model, Not support to introduce a different timeline when functionality switches/activates.
Proposal 12: 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 13: For CSI prediction using UE-side model, for training data collection, the RRC configuration reportQuantity of CSI-ReportConfig is set to ‘none’.

3GPP TSG RAN WG1 #121                                                                                                  R1-2503874
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:	9.1.3
Source:	            		Xiaomi
Title:	Further discussion on remained issues for 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: SGCS is quite diverged between the first and last predicted instances for N4>1. 
Observation 2: SGCSs of different layers for some users are similar, while SGCSs of different layers for some users are quite diverged.

Proposal 1: For model inference, CSI-RS resource configuration for Rel-18 eType II Doppler codebook could be reused.
Proposal 2: The following three options on CSI processing criteria for AI-based CSI prediction could be supported according to UE capability
Option 1: only dedicated AI/ML PU (OAPU) is occupied
Option 2: only legacy CPU (OCPU) is occupied
Option 3: both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied
Proposal 3: The following three options on number of APU/CPU for AI-based CSI prediction could be supported according to UE capability
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE
Option 2: only legacy CPU is occupied,  is reported by UE.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE
And ,  reported by UE.
Proposal 4: For Option 1(only dedicated AI/ML PU is occupied) and Option 2(only legacy CPU is occupied),  CPU/APU occupation time for Rel-18 eType II Doppler codebook based CSI reporting could be reused.
Proposal 5: For Option 3(both dedicated AI/ML PU and legacy CPU are occupied), both CPU and APU occupation time could be defined as follows:
For aperiodic CSI reporting, APU occupation time is from the first symbol after the PDCCH triggering the CSI report until the end of the referent time, while CPU occupation time is from the first symbol after referent time until the last symbol of the scheduled PUSCH carrying the report. 
For semi-persistent CSI reporting, APU occupation time is from the first time of KP-th latest consecutive periodic/semi-persistent CSI-RS occasions no later than CSI reference resource until the end of the referent time, while CPU occupation time is from the first symbol after referent time until the last symbol of the PUSCH carrying the report, where the value of  is indicated by UE capability.
Note: The reference time could be FFS.
Proposal 6: Legacy active CSI-RS resource counting for Rel-18 eType II Doppler codebook could be reused for AI-based CSI prediction.
Proposal 7: Support to reuse existing parameter, i.e., reportQuantity set to ‘none’ for indication of without CSI report for training data collection, or leave it to RAN2 design.
Proposal 8: Support to configure one CSI-RS resource for data collection for model training. Otherwise, multiple CSI-RS resources could be configured to obtain model input and ground truth CSI.  
Proposal 9: For obtaining ground truth CSI for performance monitoring, support CSI-RS resource configuration on partial subband or partial instance to save CSI-RS overhead.
Proposal 10: If the SGCS is calculated per N4 prediction instances, Rel-18 eType II Doppler codebook could be used to represent PMI used for ground truth CSI. Otherwise, Rel-16 eType II codebook is applied. The largest value of parameter combination for Rel-18 eType II Doppler codebook or Rel-16 eType II codebook is configured according to the rank.
Proposal 11: Support to report SGCS calculated by using Alt 1, i.e., one SGCS is calculated based on predicted CSI for one inference reporting and ground truth CSI.
Proposal 12: Support to report SGCS per wideband.
Proposal 13: Support to report SGCS for the selected prediction instance(s) or per prediction instance. 
Proposal 14: Support to report SGCS per layer.
Proposal 15:  Support to L1 signalling for reporting SGCS, and aperiodic, periodic, semi-persistent or UE-event reporting for monitoring performance could be considered.
Proposal 16: The number of occupied CPU for monitoring performance metric reporting could be equal to number of predicted instances or selected predicted instances in the prediction window. 
Proposal 17: The time delay for SGCS reporting is defined as  +14(-1)d if SGCS is calculated for each predicted instance, where  is delay of PMI of ground truth CSI and SGCS calculation delay,  and d respectively denote the number of predicted instance and the interval of adjacent predicted instance.

3GPP TSG RAN WG1 #121	R1-2503922
St Julian’s, Malta, May 19th – 23th, 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 specification support 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:
Proposal 1: For data collection for training, support to 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 of CSI-ReportConfig 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 a CSI measurement configuration.
Proposal 5: Support multiple CSI periodicities in a CSI report configuration.
Proposal 6: For P/SP CSI report for inference, support to configure observation window and prediction window to avoid unnecessary signaling overhead.
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: If there is a mismatch between the CSI-RS configuration parameters and the model input requirements then support to UE can either fall back to legacy mode or request the gNB to reconfigure the parameters.
Proposal 9: Support to report the calculated SGCS per time instance.
Proposal 10: Support to report the calculated SGCS per layer.
Proposal 11: For reporting contents of UE assisted monitoring, support the following alternatives:
Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI
Alt 3: statistic of reporting contents (e.g., mean, x% CDF of SGCS values) of inference reporting instances within configured monitoring window
Proposal 12: For reporting contents of UE assisted monitoring, the following options can be considered:
If Alt 1 is supported:
Option 1: indication of range of the calculated SGCS.
Option 2: indication of comparison result between the calculated SGCS and a threshold configured by NW.
If Alt 3 is supported:
Option 1: indication of range of the statistical (e.g., mean) value of the calculated SGCSs.
Option 2: indication of comparison result between the statistical (e.g., mean) value of the calculated SGCSs and a threshold configured by NW.
Option 3: indication of the number (or proportion) of ‘correct samples’ within the monitoring window, wherein the ‘correct sample’ can be defined as one whose corresponding SGCS is higher than a threshold.
Proposal 13: Support to configure the same (or single) P/SP CSI-RS resource for monitoring (i.e., measurement) and inference.
Observation 1: 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 14: Calculation and reporting of SGCS should be based on valid monitoring instance, rather than invalid monitoring instance.
FFS: how to define ‘valid monitoring instance’.
Proposal 15: Multiple reportConfigIDs of model inference reports can be associated with a single reportConfigID of performance monitoring.
Proposal 16: 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 17: 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 18: AI/ML based CSI reporting occupies one set of CPUs and the other set of APUs, i.e., support Option 3: both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied. And UE only updates an AI/ML CSI report if both conditions on CPU and APU 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 occupation timing for the observation window.
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 Meeting #121 	R1-2503952
St Julian’s, Malta, May 19th – 23th, 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 reporting contents of UE assisted performance monitoring, support Alt 1.
Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI.
Report averaged over predication instances, subband and layer.
Proposal 2: For CSI prediction using UE side model, for inference, consider the following two options for potential down selection
Option 1: only dedicated AI/ML PU (OAPU) is occupied
Option 3: both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied
FFS whether OAPU and OCPU are based on defined rule and/or reported by UE
Note: The supported option(s) by UE is reported by UE capability, if multiple options are supported. 
The total number of dedicated AI/ML PU for AI/ML is reported by UE capability. 
Note: The total number of Use case specific dedicated AI/ML PU could be discussed separately. 

3GPP TSG-RAN WG1 #121	R1-2503976
St Julian's, Malta, 19 - 23 May 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 SGCS may be beneficial for UE-side model monitoring. 
Observation 3: One SGCS based reporting content for UE assisted performance monitoring (Alt 1) may not lead to desirable decisions at the NW.
Observation 4: Alt 2 of UE assisted performance monitoring enables better complexity-performance trade-off decisions at the NW-side. 
Observation 5: Reporting SGCS values on a per-layer basis would improve decisions at the NW.
Observation 6: Option 2 (only legacy CPU (OCPU) is occupied) may lead to inaccurate counting of the AI/ML PU resources.

Proposal 1:	For performance monitoring, out-of-distribution metrics should be used in conjunction with SGCS.
Proposal 2: Down-select Alt-2 for reporting contents of UE assisted performance monitoring. 
Proposal 3: Support reporting SGCS on a per-layer basis.  
Proposal 4: Support separate configuration for CSI-RS for monitoring, especially when aperiodic CSI-RS is used for CSI prediction.
Proposal 5: For AI/ML CSI prediction using UE side model, for inference, Option 2 (only legacy CPU (OCPU) is occupied) should not be considered.
Proposal 6: For AI/ML CSI prediction using UE-side model, for inference, down-select Option 3 (both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied.)
Proposal 7: Support separate PU occupancy counting between legacy (non-AI/ML) CSI reporting and AI/ML-based CSI.
Proposal 8: Support CPU pool sharing between legacy CSI reporting and AI/ML-based CSI.

3GPP TSG RAN WG1 #121  	                              R1-2503982
St.Julians, Malta, May 19th – 23rd, 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: Regarding gNB antenna tilt angles, for generalization Case 2, generalization performance is achieved. 
Observation #2: Regarding TXRU mapping, for generalization Case 2, marginal loss is observed. 
Proposal #1: Conclude that separate configuration of CSI-RS resources for model input and ground truth CSI 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: Support Option 1, where only dedicated AI/ML PU(OAPU) is occupied for CSI prediction inference operations.
Proposal #4: For performance monitoring, OCPU=K where K is the number of monitoring RS occasions.
Proposal #5: For CQI calculation in inference report, reuse the mechanism of Rel-18 tdCQI.
Proposal #6: For report contents of UE-assisted performance monitoring, support Alt 1 where a single SGCS value is calculated based on predicted CSI and ground-truth CSI.
Proposal #7: For SGCS reporting, the reported value range is X to 1 with Y step size.
FFS on X, Y values
Proposal #8: Consider following SGCS calculation 
per prediction instance with NW configured prediction instance(s),
averaged over subband,
the first layer only. 
Proposal #9: For monitoring reporting, 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 ID of an inference report configuration is configured in the configuration for monitoring to link the inference report configuration and monitoring report configuration
Proposal #10: For monitoring resource type, periodic CSI-RS, semi-persistent CSI-RS, and aperiodic CSI-RS are supported.
Proposal #11: For monitoring resource type, following combination of inference report and monitoring report are supported.
Proposal #12: 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 #121		R1-2503988
St Julian’s, Malta, May 19th – 23rd, 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: For processing unit for AI/ML features for UE, all options are supported in the specification. The supported option(s) by UE and the number of occupied PUs are reported by UE capability.
Proposal 2: In addition to UE capability, the AI/ML PU () and legacy CPU () can be adjusted by functionality applicability reporting over UE Assistance Information of RRC.
Proposal 3: Before proceeding a discussion of CSI processing unit, a relationship between model mapping and 3GPP-specified procedure relation should be concluded.
Proposal 4: 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 5: 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 6: At least observation window, prediction window, and processing unit related information should be included for inference related parameters.
Proposal 7: 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.
Proposal 8: For reporting contents of UE assisted performance monitoring, either Alt.1 or Alt.2 is supported.
Proposal 9: For performance monitoring of CSI prediction, UE needs to be indicated / configured with the configuration for ground-truth measurement.
Proposal 10: For performance monitoring of CSI prediction, performance monitoring metric for the previous predicted CSI can be piggybacked in the predicted CSI report.
Proposal 11: 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 12: For ensuring the consistency between training and inference of CSI prediction, the discussion / conclusion in beam prediction can be reused.
Proposal 13: For UE-side data collection, in order to identify the scenario / configuration, how to share the NW-side additional condition should be studied. 
Proposal 14: Instead of informing actual configuration, some kind of configuration ID corresponding to associated ID is necessary.
Proposal 15: Data-transfer-based method as not to inform NW-side additional condition at the time of the training should be studied.
Proposal 16: RAN1 is not required to discuss how UE collected data is transferred to UE side (server). 

3GPP TSG-RAN WG1 Meeting #121	R1- 2503998
St Julian’s, Malta, May 19th – 23rd, 2025

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

Conclusion
For CSI prediction using UE-side model, for data collection for training, aperiodic CSI-RS resource for CMR is not supported.
Agreement
For CSI prediction using UE-side model, for training data collection, support 
CSI-ReportConfig can be used for configuring the resources for data collection purpose without CSI report
FFS on how to indicate without CSI report in CSI-ReportConfig

Agreement
For CSI prediction using UE-side model, for performance monitoring, support UE assisted performance monitoring subject to an additional UE capability, and UE assisted performance monitoring is based on Type 3 performance monitoring 
Agreement
For CSI prediction using UE-side model, for performance monitoring type 3, support SGCS as a performance metric. 
Agreement
For the definition of SGCS,

Note: How to handle layer mapping mismatch, if any, is up to UE implementation.
Agreement
For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, down-select one alternative by RAN1#121. 
Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI
Alt 2: one SGCS is calculated based on predicted CSI for one inference reporting, and ground truth CSI, another SGCS is based on ground truth CSI and CSI (non-predicted) corresponding to the latest CSI-RS transmission occasion not later than CSI reference resource of the inference reporting instance.
Alt 3: statistic of reporting contents (e.g., mean, x% CDF of SGCS values) of inference reporting instances within configured monitoring window 
Monitoring window can be configured by NW 
FFS on signalling details
FFS on whether to report per prediction instance, selected prediction instance(s), averaged over prediction instances
FFS on report frequency granularity (e.g., per wideband or per subband or averaged over subband or selected subband)
FFS on whether to report per layer, the first layer, averaged over layer
FFS on how to quantize and report mechanism

Agreement
For CSI prediction using UE side model, for inference, consider following options for potential down selection
Option 1: only dedicated AI/ML PU (OAPU) is occupied
Option 2: only legacy CPU (OCPU) is occupied
Option 3: both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied
FFS whether OAPU and OCPU are based on defined rule and/or reported by UE
Note: The supported option(s) by UE is reported by UE capability, if multiple options are supported. 
The total number of dedicated AI/ML PU for AI/ML is reported by UE capability. 
Note: The total number of Use case specific dedicated AI/ML PU could be discussed separately. 

Agreement
For CSI prediction using UE-side model, at least for inference, introduce new RRC parameter for CSI report configuration to distinguish CSI report of AI-CSI prediction and non-AI CSI prediction.
Note: terminology of “AI-CSI prediction” and “non-AI CSI prediction” is separate discussion
Detailed parameter name is up to RAN2

3GPP TSG RAN WG1 #121		R1-2504026
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item:	9.1.3
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 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 3: Support UE to report the SGCS based on predicted CSI for one inference reporting and ground truth CSI
UE reports the SGCS for the layer with strongest channel energy
UE reports the SGCS for the subbands configured by the network
The maximum number of subbands is a UE capability
UE reports the SGCS for one instance configured by the network
Proposal 4: Support to report the SGCS by UCI
Proposal 5: UE does not need to receive the CSI-RS for SGCS report during the cell DTX inactive period, since the CSI-RS is also a type of CSI-RS for CSI acquisition.
Proposal 6: Do not support to configure separate CSI-RS for model input and model output for data collection
Proposal 7: 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 8: 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 9: Support a CSI prediction taking 1 processing unit for AI/ML PU (e.g., APU) and 1 CPU
Proposal 10: 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 #121	R1-2504041
Malta, May 19th – 23rd, 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:
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.
The SGCS value corresponding to the monitoring process is expected to drop significantly over the reporting window period.
Based on UE implementation, the CSI measurement corresponding to a time window up to the latest slot carrying the CSI-RSs may or may be pursued before the input to the AI/ML model, or as part of the AI/ML model for CSI prediction.
Based on the observations above, we have the following proposals:
The higher-layer parameter introduced to differentiate the Rel-19 AI/ML-based CSI prediction from the legacy Rel-18 CSI prediction is not part of the codebook configuration.
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.
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 SGCS reporting for monitoring purposes, the SGCS metric is averaged over SBs, layers, but not over reporting instances corresponding to the prediction window.
For performance monitoring under UE-based CSI prediction, three reference time instants are considered: (i) the first slot of the prediction window, (ii) the median slot of the prediction window, and (iii) the last slot of the prediction window.
For SGCS reporting, support a single reference for performance monitoring corresponding to realistic CSI according to the latest measurement occasion
SGCS is reported over a region of valid values, e.g., [0.75,0.95], with an additional codepoint corresponding to values lower than the smallest value in the region.
FFS: whether the values are quantized uniformly in linear or log domain.
For PU calculation for AI/ML-based CSI prediction, support Option 3: Both dedicated APU(s) and legacy CPU(s) can be occupied for AI/ML-based CSI prediction.
Note: the value of either the occupied APU(s) or CPU(s) can be zero.
For the active CSI-RS resource counting (ARC) for AI/ML-based CSI prediction, legacy procedure is supported.
Appendix: Simulation Assumptions

3GPP TSG RAN WG1 #121							R1-2504060
St Julian’s, Malta, May 19th – 23th, 2025

Agenda Item 	:	9.1.3
Source 	:	Sony 
Title 	: 	Specification support for UE-side AI/ML CSI prediction model monitoring
Document for 	:	Discussion and decision

Conclusion
In this contribution, we discussed the proposed alternatives for reporting UE-aided monitoring results and also configuration of resources for AI/ML CSI prediction model monitoring ground-truths. that need to be covered in the specification of AI/ML temporal CSI prediction. We observed and proposed as follows:
Observation 1: The gNB can use monitoring reports from all prediction instances within the prediction window to select an appropriate time resource allocation for transmissions to the UE or to generate statistics on the monitoring metric.
Proposal 1: RAN1 to allow raw monitoring reports per prediction instance. What to do with these should be up to the network.
Observation 2: Alt1 as described does not preclude one SGCS for each CSI prediction instance.
Observation 3: The ground truth at a given prediction instance will always provide the best possible CSI for that instance
Proposal 2: RAN1 selects Alt1 with an SGCS report per prediction instance in the monitoring period and leave the statistical computation in Alt3 to network implementation. 
Observation 4: When P-CSI-RS or SP-CSI-RS are configured with a periodicity that matches the time between desired CSI prediction slots, both the CSI-RS resource(s) used for measurements for model input and for measurements for ground-truth can be provided by one configuration.
Proposal 3: RAN1 to conclude that at least for data collection for training, a single CSI configuration of periodic or semi-persistent CSI-RS of adequate periodicity can be sufficient to provide the CSI-RS measurements resources for both model input and 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 Meeting #121	R1-2504082
St Julian’s, Malta, May 19th – 23rd, 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 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 AI/ML based CSI prediction with UE-side model, regarding the reporting content for performance monitoring, Alt 1 is preferred, i.e.,
Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI
Proposal 4:
For AI/ML based CSI prediction with UE-side model, regarding the reporting content for performance monitoring, the SGCS could be averaged over prediction instances or the SGCS could be reported for one selected prediction instance.
Proposal 5:
For AI/ML based CSI prediction with UE-side model, regarding the frequency granularity of the reporting content for performance monitoring, the SGCS could be averaged over sub-bands, or the SGCS could be averaged over selected sub-bands.
Proposal 6:
For AI/ML based CSI prediction with UE-side model, regarding the reporting content for performance monitoring, the SGCS could be averaged over layers or the SGCS could be reported for the first layer.
Proposal 7:
For AI/ML based CSI prediction with UE-side model, periodic CSI-RS and semi-persistent CSI-RS could be supported for performance monitoring. There is no need to introduce dedicated resource configuration for performance monitoring, i.e., the resource configuration for inference could be re-used.
Proposal 8:
For AI/ML based CSI prediction with UE-side model, CSI-ReportConfig could be used to configure the reporting for performance monitoring. New report quantity could be introduced for performance metric reporting.
Proposal 9:
Regarding training data collection for AI/ML based CSI prediction with UE side model, new report quantity could be introduced to indicate “without CSI report” in CSI-ReportConfig.
Proposal 10:
Regarding training data collection for AI/ML based CSI prediction with UE side model, it should be discussed whether periodic CSI-RS and semi-persistent CSI-RS should be enhanced to support inference with aperiodic CSI-RS resource.
Proposal 11:
Regarding training data collection for AI/ML based CSI prediction with UE side model, the CSI-RS periodicity should be collected and included in the dataset.
Proposal 12:
For CSI prediction with UE-side model, regarding CSI processing criteria for inference, all the three options could be supported subject to UE capability and RAN1 could further discuss the occupation time for CPU and APU.
Proposal 13:
For CSI prediction with UE-side model, regarding CSI processing criteria for performance monitoring and training data collection, it’s not necessary to occupy APU.

3GPP TSG-RAN WG1 Meeting #121	R1-2504094
St Julian's, Malta, May 19th – 23rd, 2025

Agenda Item:  9.1.3
Source:	HONOR
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: Reporting per subband will significantly increase signalling overhead and computational complexity.
Observation 2: Discarding or not updating an inference report will affect performance monitoring.
Proposal 1: Reuse the existing parameter (i.e., reportQuantity set to 'none') to enable UE-side data collection.
Proposal 2: Use the Rel-16 eType II codebook to represent PMI of ground-truth CSI for performance monitoring.
Proposal 3: To mitigate the impact of quantization loss, PMI of the ground-truth CSI should have a higher quantization resolution (e.g., using default parameter combination). 
Proposal 4: Codebook parameters should be aligned between monitoring report and inference report (e.g., subband number, antenna port number, layer number).
Proposal 5: For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, support Alt1 while deprioritizing Alt2 and Alt3.
Proposal 6: At least support reporting one prediction instance averaging over subbands and layers, wherein the prediction instance can be configured by network or determined by UE by default.
Proposal 7: Support reporting per layer averaging over subbands which can be configured by the network subject to additional UE capability.
Proposal 8: The monitoring window can be configured by network to increase the reliability of monitoring report.
Proposal 9: Support L1 signalling for reporting monitoring results.
Proposal 10: Introduce time restriction for triggering monitoring reports. e.g., when an inference report is triggered, and if the report is linked to a monitoring report, the monitoring report should be triggered before the inference report is transmitted.
Proposal 11: For UE-side model, for AI/ML based CSI prediction, for processing of a CSI report for inference, support option3: both dedicated AI/ML PU () and legacy CPU () are occupied.
Proposal 12: For the inference of CSI prediction, regarding the CPU occupancy for Option3, reuse the CPU occupancy rules of the R18 Doppler codebook.
Proposal 13: For the inference of CSI prediction, regarding the APU occupancy for Option3, the APU occupancy time is the same as the CPU occupancy time.
Proposal 14:  The CPU is shared between legacy CSI and AI/ML-based CSI reporting, and AI/ML PU is shared among different AI/ML functionalities/use cases.
Proposal 15: Regarding CPU occupancy for training data collection, support = 1.
Proposal 16: For CPU occupancy time of monitoring report, introduce an additional time or scaling factor on top of legacy codebook (e.g., Rel-16 eType II codebook).
Proposal 17: If the inference report requiring performance monitoring is discarded or not updated, the corresponding monitoring report should also be discarded or not updated.

3GPP TSG RAN WG1 #121																 		R1-2504114
Malta, MT, May 19th – 23rd, 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: Alt 2) seems to be significantly better suited to evaluate the monitoring performance then Alt 1) which suffers from the strong variation of median  values ranging from 0.1 to 0.9 for different UEs like cell center and cell edge UEs. This makes it difficult to define a suitable single threshold value to decide the AI/ML model performance as needed for Alt 1).  Contrary, for Alt 2) the strong correlation of the  statistics for non-predicted CSI and AI/ML predicted CSI allows to differentiate effects of the radio channel conditions versus failures of the AI/ML model itself.     
Observation 2: Alt 2) can be realized by reporting of delta  values so that the UE reports the difference of the  values of the non-predicted and the AI/ML predictor. This combines the benefits of reporting relative to a reference predictor while the reporting overhead is the same as for Alt 1). 

Observation 3: For Alt 2) due to the lower value range of delta  values, the number of bits per report might be reduced compared to Alt 1) for a given quantization error. 
Observation 4: For performance monitoring schemes leading to few number of bits per inference report instance one should consider L1 reporting in combination with a low priority. In case of more complex schemes leading to a significantly higher number of bits per report one should consider L2 reporting. 
Observation 5: Requirements for performance monitoring might vary depending on channel conditions, ML model types, energy efficiency requirements, etc. so that the gNB should be able to configure the performance monitoring reporting scheme. It might combine different modes like event driven, gNB triggered and/or periodic reporting with varying periodicities. 
Observation 6: For data collection it might be beneficial if the UE estimates and reports the best fitting CSI RS configuration of one, two or even more parallel SP CSI-RSs and/or P CSI-RSs. The UE might use TRS to analyze the current time domain channel variance as basis for the proposed CSI RS configuration.
Observation 7: Defining data content as explicit CSI and considering uncompressed explicit CSI (in the data collection framework) can minimize specification effort. 
Observation 8: 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:  Define a new RRC parameter for the CSI report configuration like vectorLengthDD_ML, which configures the value of , to indicate AI/ML based UE-sided channel prediction. 
Proposal  2: For reporting of performance monitoring content we propose Alt 2),  i.e., reporting of  values for predicted CSI as well as non-predicted CSI, preferably as delta values between the predicted and non-predicted  values.     
Proposal  3: Consider a non-linear quantization of  values within a limited reporting window, e.g. ranging from 0.5 to 0.9 and including an ‘out-of-range’ indication.  
Proposal  4: UE should report median SGCS values in combination with the related reliability, where the reliability might be, for example, estimated from the variance of the SGCS values as well as other means like the SINR.     
Proposal  5: If the UE calculates the  value of one inference reporting instance over multiple layers  and multiple prediction time instances  then it should report the weighted sum over all layers and prediction time instances.     
Proposal  6: As advanced and low overhead mode consider reporting  values over multiple reporting instances  with inherent error correction  so that one can achieve simultaneously a low bit quantization in combination with a very low estimation error       
Proposal  7: Consider as another optimization a codebook approach for reporting of relative domain specific  reliabilities.  
Proposal  8: 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). 
Proposal  9: For the performance monitoring configure the CSI-ReportConfig with the higher layer parameter reportQuantity set to 'SGCS-r19' to generate the related pre-defined monitoring reports.
Proposal  10: Consider the option to configure for high speed UEs two or more SP CSI-RS and/or P CSI-RS resources with a relative delay of, e.g. 2.5 ms to fulfill the Nyquist criterion for high speed UEs.
Proposal  11: For data collection configure the CSI-ReportConfig with the higher layer parameter reportQuantity set to 'none-CSI-r19', with the effect that then the UE shall not report any quantity for the CSI-ReportConfig.
Proposal  12: The configuration of P and one or more SP CSI-RS resources should support the data collection over multiple time instances to form tracks of, e.g., 100 successive channel observations. 
Proposal  13: For the collected data content, RAN1 to consider explicit CSI as one option. 
Proposal  14: For CSI prediction using UE side model support Option 3) where both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied. 
Proposal  15: For AI/ML-based channel prediction use case,  
OAPU  and OCPU may be occupied for the same time duration, where OCPU occupying time durations is already defined in Rel-18. 
Rel-18 CSI processing timeline for CSI prediction shall be applicable for Rel-19 AI/ML based channel prediction. 

3GPP TSG RAN WG1 #121			R1-2504131
Saint Julian’s, Malta, May 19th – 23rd, 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 UE sided model in 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: 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.
Proposal 4: For CSI prediction using UE-sided model, for reporting contents of UE assisted performance monitoring, support Alt 1, that UE only reports one SGCS calculated based on predicted CSI for one inference reporting, ground truth CSI.
Proposal 5: For reporting contents of UE assisted performance monitoring, UE reports the SGCS value averaged across all layers, prediction instances, and subbands, in order to reduce uplink reporting overhead.
Proposal 6: For the quantization of the reported SGCS, the network can configure the number of uniformly divided range intervals over [0, 1] – ‘’.
Proposal 7: For the reporting contents of UE assisted performance monitoring, UE reports the index of the configured interval that corresponds to the calculated SGCS value.
Proposal 8: Introduce a new quantity for SGCS in the CSI report to support performance monitoring of CSI prediction.
Proposal 9: For the reporting contents of UE assisted performance monitoring, the size of the CSI field associated with SGCS reporting is , where  is the number of uniformly divided range intervals over [0, 1], as configured in ‘CSI-ReportConfig’
Proposal 10: For CSI prediction using UE side model, for inference, support Option 3, that both dedicated AI/ML PU and legacy CPU are occupied.
Proposal 11: To indicate no CSI report in ‘CSI-ReportConfig’, reuse the existing parameter by setting the ‘reportQuantity’ field to ‘none’
Proposal 12: Support the single configuration of model input and ground truth CSI.

3GPP TSG RAN WG1 Meeting #121		R1-2504225
St Julian’s, Malta, May 19th-23rd, 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 some spec impacts issues for UE-sided CSI prediction. Observations and proposals are listed as following:
Observation 1: No additional downlink signaling is required when one CSI-RS resource is configured for both of model input and ground-truth CSI measurements 
Observation 2: Additional downlink signaling is required to associate two CSI-RS resources which are separately configured for model input and ground-truth CSI measurements.
Observation 3: Different AI/ML models for the same AI/ML functionality/feature may occupy different APUs
Proposal 1: Support configure the reportQuantity as ‘none’ to indicate without CSI report in CSI-ReportConfig.
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 the reporting content of UE assisted performance monitoring, only support Alt 1.
Proposal 5: Regarding the reporting content, support one SGCS reporting calculated by the average over all sub-bands, the first R layers and N4 prediction instances, where R is the rank indicator within the inference reporting, N4 is configured by RRC.
Proposal 6: Support dedicated CSI report configuration for monitoring, with association of CSI report configuration of inference.
Proposal 7: Regarding the monitoring CSI-RS type,
P/SP/AP CSI-RS type are supported for P CSI-RS type for inference
SP/AP CSI-RS type are supported for SP CSI-RS type for inference
AP CSI-RS type is supported for AP CSI-RS type for inference
Proposal 8: Support Option 3, wherein both dedicated APU and legacy CPU are occupied for inference.
 and  are reported by UE
Proposal 9: Support Option 2 with only legacy CPU occupation for Type 3 monitoring.

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, propose the use of the associated ID as the baseline.
Leverage and 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.
Model Monitoring
Following the RAN1#120bis meeting [3], it was agreed that the report content for performance monitoring Type 1 and 3 is as follows:

For Alt 1, we think it is meaningless because reporting only one SGCS value cannot accurately reflect the AI/ML module's performance. For example, if the UE is moving at a lower speed, the SGCS value is naturally high; in contrast, if the UE is moving at a higher speed, the SGCS value is naturally low. However, this does not directly mean the UE needs to switch to another model or fallback if the speed does not increase significantly. However, this variation does not necessarily imply the need for model switching or fallback unless there is a significant speed change. Additionally, SGCS value alone does not accurately represent the UE's speed, as other factors such as channel environment and antenna configuration also influence this value. So we think Alt 1 can be de-prioritized.
Regarding Alt 2, it provides two separate SGCS values based on different CSI conditions—one for predicted CSI and the other for non-predicted CSI. This may provide more accurate insights into the UE's capability and prediction accuracy. For this alternative, it is crucial to carefully indicate which value is based on predicted CSI and which is not when reporting by the UE, which might require additional bits to distinguish between them.
On the other hand, Alt 3 focuses on statistical reporting within a configurable monitoring window, allowing for a broader overview of performance trends over time, which is more robust. However, Alt 3 may require a longer time to accurately reflect the model status. Therefore, deciding on the monitoring window becomes crucial, but given the limited meeting in the Rel-19 discussion, we suggest deprioritizing Alt 3 to avoid complicated configurations and potential divergence in the discussion. In conclusion, we propose using Alt 2 for report content in performance monitoring.
Deprioritize Alt 1 for the monitoring report content since a single SGCS value is meaningless. 
Deprioritize Alt 3 for the monitoring report content to avoid complicated configurations and potential divergence in the limited discussion time.
Propose only Alt 2 for the monitoring report content.
For Alt 2, an extra bit is needed to differentiate between the SGCS values corresponding to predicted or non-predicted CSI values.
For the FFS item 1, we provide SGCS values with different predicted instances in Figure 2-1. The figure shows the SGCS has significant variation between different time instances, and this observation is based on a 5ms CSI-RS periodicity. If the periodicity become longer, the difference could be even larger. Therefore, separate feedback of the SGCS value is needed to determinate if the model can predict accurately over extended periods.
For the FFS item 2, can refer to our work in [4]. The results indicate that the AI/ML CSI prediction model trained on single/joint RB(s) can be generalized and applied to other single/joint RB(s). This means the model is not sensitive to frequency granularity, thus we believe reporting based on frequency granularity is not necessary for AI/ML-based CSI prediction.
For the FFS item 3, can refer to our work in RAN4 [5]. For higher Doppler scenario (100Hz), the Rank2 SGCS for layer 1 is 0.8636 and for layer 2 is 0.7611, indicating a difference in values. However, our model is designed as a layer-common model, which tends to learn overall performance instead of specific layers. In this case, we think reporting SGCS averaged over layer is sufficient. Nonetheless, if the model is layer-specific, reporting per layer results would be more reliable. Based on the above discussion, to simplify the discussion, feedback per layer is suggested. 


Figure 2-1: SGCS values with different predicted instances

Report per prediction instance if the N4>1, to ensure accurate monitoring across predicted instances.
Reporting frequency granularity is unnecessary due to effective generalization over single/joint RB(s).
For layer-common models, report SGCS averaged over layers; for layer-specific models, report SGCS per layer. To simplify, reporting SGCS per layer for all cases is recommended.
Data Collection
Data Collection for training 
Following the RAN1#120bis meeting [3], it was agreed that CSI-ReportConfig can used for configuring the resources for data collection purpose without CSI report:


The above IE table is from [6]. The current specification already supports setting ReportQuantity to 'none' in the CSI-ReportConfig, which effectively fulfills the requirement to configure resources without producing a CSI report and has no specification impact by not introducing a new parameter. Therefore, we propose to directly use this method to address the issue.
Propose using the existing parameter by setting ReportQuantity to 'none' in CSI-ReportConfig for configuring resources for data collection without requiring a CSI report, thus avoiding the need to introduce an additional parameter.
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 Inference
Following the RAN1#120bis meeting [3], it was agreed to consider some options for the inference report:
For CSI prediction, we propose follow the straightforward Option 1, where only dedicated AI/ML PU (OAPU) is occupied. Separating the processing pools for AI CSI and legacy CSI can avoid interference between them. In addition, the required computation complexity and processing time may be significantly different for AI CSI and legacy CSI. UE may also have separate designs for hardware and software modules for AI and legacy CSI, thus creating separate pools will simplify UE design.
Moreover, each use case (CSI, BM, POS, etc.) should be discussed individually to ensure that the specific requirements of each are adequately addressed. Mixing them together makes it difficult to quantify processing capability on the same level, as different applications have varying algorithm designs and hardware impacts. Their complexities vary significantly. In addition, the report contents may differ greatly; for example, BM has 1 port WB L1-RSRP only, whereas CSI has 32 ports with WB/SB CRI/RI/PMI/CQI/LI. Therefore, it is recommended to separate application into single UE capabilities from UE-side perspective. This separation will also provide the NW with a clear and consistent understanding of the reports.
For AI/ML-based CSI prediction inference, support Option 1 only to avoid interference between AI CSI and legacy CSI.
Support separate discussions of PU for different use cases (CSI/BM/POS) to adequately address their distinct requirements.
Conclusion
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, propose the use of the associated ID as the baseline.
Leverage and 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.
Deprioritize Alt 1 for the monitoring report content since a single SGCS value is meaningless. 
Deprioritize Alt 3 for the monitoring report content to avoid complicated configurations and potential divergence in the limited discussion time.
Propose only Alt 2 for the monitoring report content.
For Alt 2, an extra bit is needed to differentiate between the SGCS values corresponding to predicted or non-predicted CSI values.
Report per prediction instance if the N4>1, to ensure accurate monitoring across predicted instances.
Reporting frequency granularity is unnecessary due to effective generalization over single/joint RB(s).
For layer-common models, report SGCS averaged over layers; for layer-specific models, report SGCS per layer. To simplify, reporting SGCS per layer for all cases is recommended.
Propose using the existing parameter by setting ReportQuantity to 'none' in CSI-ReportConfig for configuring resources for data collection without requiring a CSI report, thus avoiding the need to introduce an additional parameter.
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 AI/ML-based CSI prediction inference, support Option 1 only to avoid interference between AI CSI and legacy CSI.
Support separate discussions of PU for different use cases (CSI/BM/POS) to adequately address their distinct requirements.
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#120bis, Wuhan, China, April 7th-11nd, 2025.
R1-2308053 Evaluation on AI/ML for CSI feedback enhancement (MediaTek)
R4-2505153 Collection of simulation result for AIML CSI prediction (OPPO)
TR 38.331

TDoc file conclusion not found

3GPP TSG RAN WG1 #121                                                             R1- 2504310	
St Julian’s, Malta, May 19th – 23th, 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/ML processing criteria and timeline discussion with UE side model, to enable flexible mapping of various AI use cases and hardware resources, define maximum simultaneous AI processing per CC and all CC for AI based CSI prediction.  

Proposal 2: For AI based CSI prediction, both dedicated AI/ML PU and CPU are occupied. AI/ML processing unit is occupied for active CSI-RS resource and port counting, similar to legacy framework. 

Proposal 3: Define UE capability report on the number of AI processing units used for AI based CSI prediction inference.  

Proposal 4: Additional processing time should be added for AI based CSI prediction report.   

Proposal 5: Apply CPU occupancy counting rule for data collection for training without CSI report, for AI based CSI prediction.  
Ocpu = 1
The CPU is occupied from the first symbol of the earliest one of each transmission occasion of periodic or semi-persistent CSI-RS resource for channel measurement, until Z3’ symbols after the last symbol of the latest one of the CSI-RS/SSB resource for channel measurement in each transmission occasion. Z3’ value can be further discussed. 

Proposal 6: For AI based CSI prediction, for data collection for training, support CSI-RS resource set burst with long periodicity to enable efficient data collection.  Separate CSI-RS resource set for measurement window and prediction window can be configured. 


Proposal 7: 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 8: 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 9: For performance metric, support Alt 3: statistics of SGCS within a configured window. 

Proposal 10: For performance metric reporting, support L3 based reporting using UAI, as it is a simple and low overhead approach. 

Proposal 11: For performance metric reporting, do not support L1 based reporting due to
Performance monitoring is not delay sensitive.  
L1-based report introduces additional UE complexity 
L1-based reporting requires additional specification work for report configuration, CPU occupancy, processing timelines, and prioritization between performance monitoring report and inference report/non-AI based CSI reports.  

Proposal 12: For SGCS quantization, use uniform quantization between [x 1] with step size of 0.01, where x is specified (e.g., 0.5). 

Proposal 13: 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 14: Define assisted information/identifier to abstract the antenna virtualization/mTRP to ensure consistency of training and inference. 

3GPP TSG RAN WG1 #121                                                                                                    R1-2504386 Malta, MT, May 19th – 23rd, 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: Setting reportQuantity to be “none” is normally used for Rx beam sweeping or TRS. UE behaviours need to be clarified if use reportQuantity to be “none” for UE side data collection.
Observation 2: In the inference configuration, the gap between last symbol of measurement occasion to the first symbol of the prediction instance is not the same as the measurement resource periodicity.
Observation 3: 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 4: 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 5: 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 6: CPU and AI/ML processing units occupation duration should consider the additional buffering time of the measurement results and computation results.
Observation 7: The timeline for each individual case depends on the specific model choice and hardware architecture.
Observation 8: A common offset relative to legacy (Z, Z’) values can be reported by UE as the only difference is AIML-based CSI predication and it applies to both time requirement for the measurement resource and CSI request.
Observation 9: 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 10: Defining rule for model switching and loading time requires much higher specification impact and is complicated for UE and NW implementation.
Observation 11: Model switching and loading time may be always needed if switching between proprietary AIML feature and standardized feature.
Observation 12: The objective of performance monitoring is to identify data drift, it will be hard to make any monitoring decision unless prediction accuracy is observed over enough number of samples to get a reliable statistic. Monitoring latency could be tens or even hundreds of milliseconds.
Observation 13: Single SGCS value averaged across subbands, layers, prediction instances is sufficient as the PMI representation of precoders will spread out the prediction error in frequency, spatial and temporal domain.
Observation 14: UE assisted monitoring is not a self-contained CSI process, it requires the UE to buffer previous inference results. The buffering cost may scale with the number of CCs.
Observation 15: The buffering burden can be relaxed if L3 signaling and mechanism is used for performance monitoring.
Observation 16: L3 signaling and mechanism is sufficient for detecting performance drift as the detection needs reliable measurement across multiple occasions.
Observation 17: L3 signaling and mechanism has much less specification effort than L1 as there is no need to define L1 timeline, CPU counting, or active resource / port counting rule for performance monitoring.
Observation 18: UE assisted monitoring can reuse the NW side data collection framework being discussed in RAN2.
Observation 19: Reporting SGCS statistics and separate configuration / activation of monitoring resource for target CSI and the monitoring report may be helpful in addressing the buffering issue as it allows more flexible UE implementation using L1-related hardware when capable or even using low-cost hardware.
Observation 20: L1-signalling for report SGCS statistics based on target CSI measured using periodic or semi-persistent CSI-RS can be considered to address the buffering issue.
Observation 21: If L1 report is supported, especially for aperiodic report based on aperiodic CSI-RS, specification enhancements are needed to either eliminate the buffering, or allowing UE to know whether buffering is needed as early as possible.
Based on the observations, we propose:
Proposal 1: For UE side data collection, consider either setting reportQuantity to be “none” or setting reportQuantity to be a new value. If reportQuantity set to “none” is used, it is needed to distinguish UE behaviour of data collection from Rx beam sweeping or TRS.
Proposal 2: For UE side data collection, configure two separate resources or resource sets for model input measurement and ground-truth measurement separately. 
Proposal 3: For processing units counting of AI/ML-based CSI prediction using UE side model, support option 2 and option 3 upto UE capability. 
Proposal 4: For processing units counting of AI/ML-based CSI prediction using UE side model, O_APU and O_CPU should be reported by UE.
Proposal 5: For the duration of the CPU and AIML processing units, support the following:
Reuse the starting time of the legacy CPU for both the CPU and AIML processing unit duration of the AIML-based CSI prediction.
Extend the ending time of both the CPU and AIML processing units to the last symbol of monitoring report.
Proposal 6: 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 7: For the active duration of the aperiodic CSI-RS, extend the ending time to the last symbol of the monitoring report.
Proposal 8: Support UE capability reporting for the timeline of each individual use case.
Proposal 9: For CSI prediction, UE may report an offset value to the existing (Z,Z’) values. For N4=1, the timeline is ; for N4=1, the timeline is  or  upto UE capability where  and ,  if measurement resource is aperiodic or  if measurement resource is periodic or semi-persistent.
Proposal 10: Consider the additional latency of model switching time being absorbed into the nominal timeline for each individual case as benchmark. 
Proposal 11: Support reporting SGCS averaged within a configured monitoring window (Alt3).
Proposal 12: Support L3 signalling or mechanism for performance monitoring report, e.g., via NW side data collection procedure being defined in RAN2.
Proposal 13: If L1 report is supported for monitoring, support one of the following to address the buffering issue:
Option 0: separate configuration / activation of measurement resource for target CSI (e.g., aperiodic CSI-RS) and monitoring report.
Option 1: Configure paired resources in monitoring report, one is for model input measurement and another is for ground-truth (target CSI) measurement
Option 2.1: Configure one measurement resource for target CSI only, but the triggering of monitoring report should be close to the inference report triggering
e.g., next available downlink slot, or no later than the measurement resource of the model input
Option 2.2: define a timeline between monitoring trigger and SGCS report to include both the measurement resource for ground-truth and the measurement resource for model input
Proposal 14: 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.

3GPP TSG RAN WG1 #121			R1-2504466
St Julian’s, Malta, May 19th – 23rd, 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. 

Proposal 2: For CSI prediction using the UE-side model, for performance monitoring, measured precoding matrix is represented based on the TypeII-Doppler-r18 codebook.

Proposal 3: For CSI prediction using the UE-side model, for reporting contents of UE assisted performance monitoring, support Alt 1 and report per prediction instance.

Proposal 4: For CSI prediction using UE-side model, 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.

3GPP TSG RAN WG1 #121			R1-2504493
St Julian’s, Malta, May 19th – 23rd, 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.
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
Down-select the x-PU occupation to Option 3, i.e., both PUs are occupied.
A common timeline should be adopted for the occupation of both PUs.
Proposal 3
The value of OCPU  is based on defined rules, and the value of OAPU can be based on defined rules together with a UE-reported scaling factor.
The number of candidate scaling factors should be limited to reduce the network burden when managing UE with different scaling factors.
For defined rules, reuse the existing counting rules for CPU as a baseline.
A common timeline should be specified for all UEs, regardless of which options are used for the UE.
Proposal 4
Support a dedicated CSI report for performance monitoring.
Proposal 5
Support the reporting content Alt. 3 (Statistics of reporting contents of inference reporting instances within the configured monitoring window).
The Monitoring window is configured in the dedicated CSI report.
Mean SGCS is supported.
Proposal 6
Support the reporting per selected (first) layers and/or subbands.
The reported layers/subbands can be specified (e.g., the first one) or configured in the dedicated CSI report.
Proposal 7
If a few bits (e.g., 1-2 bits) are reported for each SGCS value, support the quantization levels configured from the NW to report the performance monitoring results.

3GPP TSG RAN WG1 #120bis		                                       R1-2504597
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda item:        9.1.3
Source        :	CEWiT
Title             :	Discussion on specification support for CSI prediction
Document for:      Discussion 
__________________________________________________________________

Conclusion
In this contribution, the following proposals are made: 
Proposal-1: For CSI prediction using UE sided model, for reporting contents of UE assisted performance monitoring, support option Alt-1. 
Proposal-2: For CSI prediction using UE sided model, for reporting contents of UE assisted performance monitoring, deprioritize Alt-2. 
Proposal-3: For CSI prediction using UE-side model, for training data collection, support, reportQuantity set to ‘none’.
5.

3GPP TSG-RAN WG1 Meeting #121				                           R1-2504649
Malta, May 19th – 23rd, 2025

Source:	Continental Automotive
Title:                       Discussion on AI/ML 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: Support configuration of processing unit to support common and dedicated AI/ML operations to optimize computing resource efficiency.
Proposal 3: Support Option 1 with priority.

3GPP TSG RAN WG1 #121			R1- 2504774 
St.Julians, Malta, May 19th – 23rd, 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 #121			R1- 2504775 
St.Julians, Malta, May 19th – 23rd, 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 #121			R1- 2504776 
St.Julians, Malta, May 19th – 23rd, 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 #121			R1- 2504777 
St.Julians, Malta, May 19th – 23rd, 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 #121			R1- 2504778 
St.Julians, Malta, May 19th – 23rd, 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.

3GPP TSG RAN WG1 #121			R1- 2504939 
St.Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	9.1.3
Source: 	Moderator (LG Electronics)
Title: 	Summary #6 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.