3GPP TSG RAN WG1 Meeting #121	R1-2503230
St. Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	9.1.1	
Source:	Futurewei
Title:	Discussion on specification support for AI/ML-based beam management
Document for:	Discussion and decision 

Conclusions
In this contribution, we present our views on specification support for AI/ML-based beam management.  Based on the discussions in the previous sections we propose the following: 
Proposal 1: For Rel-19 AI/ML-based BM, for BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring), there is no need to support other alternatives in addition to the already agreed Alt 1: Top 1 or Top K beam prediction accuracy (with or without margin).
Proposal 2: For Rel-19 AI/ML-based BM, for BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring), support introducing a new quantity (i.e., beam accuracy indicator, BAI) for beam prediction accuracy in the CSI report for monitoring, where BAI is (0 ≤≤ N) and the corresponding beam prediction accuracy is, 0≤≤ 1).
The size of CSI field associated with the BAI is .  
 is the number of linked transmission occasions for monitoring that meet the metric among N linked pair(s). 
Proposal 3: For Rel-19 AI/ML-based BM, at least for inference for network-sided AI/ML model of BM-Case1, for the content in a beam report in L1 signaling, 
Support L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP, X and M are configured by gNB, and the number of reported beams is indicated in the beam report.  
The beam information is CRI/SSBRI. 
The maximum value M can be up to “16”, subject to UE capability.
Proposal 4: For Rel-19 AI/ML-based BM, for UE-sided model, at least for BM-Case1, for content in the report of inference results, do NOT support Opt 4.
Opt 4: Beam information on predicted Top K beam(s) among a set of beams, RSRP of predicted Top K beam(s) among a set of beams, and confidence information of the RSRP
Proposal 5: For Rel-19 AI/ML-based BM, for data collection for UE-sided AI/ML model of BM-Case1 and BM-Case2, support that NW provides/signals multiple possible configurations of DL RS transmission to the UE and the UE reports its supported/preferred one(s) out of the multiple configurations.
Proposal 6: For Rel-19 AI/ML-based BM, for data collection for AI/ML model of BM-Case1 and BM-Case2, support using RS ID as implicit indication of beam ID and reusing legacy L1-RSRP reporting as much as possible.
Proposal 7: For both UE/NW sided models, for enabling a P2 sweeping based on predicted Top-K beams, support that NW configures K CSI-RS resources, and dynamically indicates the QCL information to the K CSI-RS resources through MAC CE, at least for AP CSI-RS for AP CSI report.
Proposal 8: For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, support all the following three options: 
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE.
And 
Option 2: only legacy CPU is occupied,  it is reported by UE.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
And  
Note: The supported option by UE is reported by UE capability.
Proposal 9: 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.

3GPP TSG-RAN WG1 Meeting #121	R1-2503251
St Julian’s, Malta, May 19 – 23, 2025
 
Agenda Item:	9.1.1
Source:	Huawei, HiSilicon
Title:	Discussion on AI/ML for beam management
Document for:	Discussion and Decision

Conclusions
In this paper we make the following observations and proposals:
Observation 1: The legacy configuration for the total number of CSI-RS resources (up to 64) and the legacy configuration for number of CSI-RS resources per resource set (up to 64) do not seem sufficient to support a reasonable size of AI/ML-based beam measurement including Set A, which may exceed 64.
Observation 2: Activation delay is needed for deploying the model to the AI/ML processing memory before performing inference.
Activation of an AI/ML model for beam management could be achieved in TTI level delay.
To achieve efficient usage of AI/ML processing memory, the model should be flushed from the AI/ML processing memory after inference is completed.
Observation 3: UE may need to deploy multiple functionalities in the AI/ML processing memory, each of which may correspond to an individual required memory storage.

Proposal 1: For data collection for both NW-side model and UE-side model, support to extend the maxNrofNZP-CSI-RS-ResourcesPerSet (i.e., Maximum number of NZP CSI-RS resources per resource set) to 256, subject to UE capability.
Note: UE support of maxNumberCSI-RS-Resource (max number of configured CSI-RS resources) needs to be enhanced to 256 accordingly.
Proposal 2: For report of data collection in higher layer for NW-side model for BM-Case 1 and BM-Case 2, the data format can be summarized as the following two types:
Type A: All L1-RSRPs of measured beams subject to a configured resource set are reported by UE. 
Type B: Beam information and corresponding L1-RSRPs of beams subject to a configured resource set are reported by UE.
Note 1: NW can obtain the model input (Set B) and label (Set A) from two separate CSI report configurations, and pair them by implementation.
Note 2: Purpose, such as above “For NW-side model for BM-Case 1 and BM-Case 2”, will not be specified from RAN1 perspective.
Proposal 3: For the report of beam information for the NW-side model:
When, beam information is reported with CRI-based format, where M1 is the number of reported beams, and M2 is the size of measurement beam set.
Otherwise, beam information is reported with bitmap-based format.
Note: Purpose of beam information report will not be specified.
Proposal 4: For the NW-side model, regarding the maximum value of M (number of reported beams in one report), the value set can be set as 4, 8, 16, 32, 64.
Proposal 5: For the configuration for training data collection of UE-side model, gNB indicates the preferred predicted time instance information as guidance to facilitate UE side training, including:
The predicted time instance for BM-Case 1 (e.g., in forms of the time gap between a Set B and its associated Set A).
The time gap between two consecutive predicted time instances (and between the reference time and the earliest predicted time instance) for BM-Case 2.
Number of predicted time instances for BM-Case 2.
Proposal 6: For UE assumption of associated ID, if the associated ID for Set B/Set A is absent, UE may assume similar properties over the collected Set B/Set A with absent associated ID in the same cell, respectively.
Proposal 7:  For UE assumption of associated ID, the property for a resource set of Set A/Set B is interpreted with the ascending order of the entries of the corresponding resource set.
Proposal 8: For UE assumption of associated ID, regarding A-CSI report with multiple resource sets in one CSI report configuration, UE assumes the associated ID is applicable to the actually transmitted Set A/Set B.
From NW implementation perspective, it can simply configure all resource sets with the similar property into the corresponding resource set list.
Proposal 9: For indicating the second round measurement of the predicted Top-K beams which may vary over time, to enable a unified framework for both UE-side model and NW-side model, prioritize Option A with changes:
Option A: NW configures K fixed CSI-RS IDs for transmitting the predicted Top-K beams, and dynamically indicate the QCL information (e.g., QCLed SSB ID) to the K CSI-RS IDs as part of the MAC CE/DCIbeam IDs or TCI states.
Proposal 10:  For NW-sided model, do not support a CSI report with the measurement results for each of the N>1 temporal domain transmission occasions, considering the larger latency it would inflict.
Proposal 11: For the inference of UE-side model, for the content in the report of inference results, support Opt 3: Beam information on predicted Top K beam(s) and the corresponding prediction probability information of the predicted Top K beam(s).
The ranking information of the predicted Top K beams for K > 1 is conveyed by the order of the beam information based on the prediction probability.
Support differential quantization for the prediction probability information across K>1 beams with 4 bits for the beam with highest probability and 2 bits for other beams.
Proposal 12: For BM-Case 2 with UE-side model, UE should drop the predicted instances located before the UL slot of CSI report and only report the predicted instances after the CSI report.
Proposal 13: For the inference of UE-side model, some of the UE assumptions on the resource configuration in legacy spec needs to be revisited for the resource setting of Set A, including at least:
UE does not need to perform rate matching around the RS configured in Set A in the inference CSI report.
The resource type of Set A in the inference CSI report should be ignored, so that:
When a RS ID in Set A is configured in another resource configuration which is actually transmitted, it does not need to keep the same time domain behavior to Set A.
Set B does not need to keep the same time domain behavior to Set A configured in the same CSI report configuration.
Proposal 14: For monitoring Type 1 Option 2 of UE-side model, regarding additional rules for counting N linked pairs, only valid N’ pairs are considered for BAI calculation among N linked pairs, where a linked pair is identified as invalid under the following cases:
Case 1: Failed generation of measurement on monitoring RS due to unsatisfied CPU occupancy condition for the monitoring CSI processing.
Case 2: Failed generation of the linked inference result due to unsatisfied PU occupancy condition or timeline condition for the inference CSI processing.
Proposal 15: For monitoring Type 1 Option 2 of UE-side model, support the format of the BAI in forms of the number of Np, where Np is the number of linked pair(s) that meet the metric among N’ valid linked pair(s).
Proposal 16: For monitoring Type 1 Option 2 of UE-side model, no need to introduce a threshold X for restricting the minimal slot offset.
Proposal 17: For monitoring Type 1 Option 2 of UE-side model, duplicated mapping from more than one monitoring RS to one prediction result should be precluded when determining the N linked pairs.
Proposal 18: 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,  it is reported by UE.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
Equal occupancy duration can be assumed for AI/ML PU and legacy CPU.
Proposal 19: 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 20: 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 21: For inference with UE-side model for BM-Case 2, regarding the PU occupancy duration rule, support Alt.1 with editorial changes:
For P/SP-CSI report:
For the last CSI-RS/SSB transmission occasion no later than CSI reference resource, from the 1st symbol of the earliest latest P/SP CSI-RS/SSB resource occasions no later than CSI reference resource, until the last symbol of the PUCCH/PUSCH carrying the report.
For Kp-th till second last consecutive CSI-RS/SSB transmission latest consecutive P/SP CSI-RS occasions no later than CSI reference resource, from the first symbol of earliest one of each transmission occasion of periodic or semi-persistent P/SP CSI-RS/SSB resource for channel measurement for L1-RSRP computation, until   symbols after the last symbol of the latest one of the CSI-RS/SSB resource for channel measurement for L1-RSRP computation in each transmission occasion.
For A-CSI report with P/SP CSI-RS/SSB:
From the first symbol of earliest one of each CSI-RS/SSB transmission occasion of P/SP CSI-RS/SSB resource until  symbols after the last symbol of the latest one of the CSI-RS/SSB resource in each transmission occasion, and from the first symbol after the PDCCH triggering the CSI report until the last symbol of the scheduled PUSCH carrying the report.
Proposal 22: For training data collection of UE-side model, regarding the CPU occupancy rule of Set A and Set B:
Reuse the legacy CPU mechanism for P/SP-CSI-RS/SSB subject to ‘none’ separately for Set A and Set B, i.e., for each of Set A occasion and Set B occasion, the CPU occupancy starts from the first symbol of the earliest one of each CSI-RS/SSB transmission occasion, till  symbols after the last symbol of the latest one of each CSI-RS/SSB transmission occasion.
 is considered as the CPU value.
AI/ML PU is not occupied.
Proposal 23: For monitoring of UE-side model, regarding the CPU occupancy rule, apply the similar principle with inference for BM-Case 2 with multiple observation instances to the PU occupancy over N latest transmission occasions of monitoring resources:
For P/SP-CSI report:
For the last monitoring RS occasion, CPU is occupied from the first symbol of the earliest RS to  symbols after the last symbol of the latest RS.
For the N-th till second last monitoring RS occasion, CPU is occupied from the first symbol of the earliest of each monitoring RS occasion to  symbols after the last symbol of the latest monitoring RS in each occasion.
For A-CSI report: CPU is occupied from the first symbol of the earliest of each RS occasion to  symbols after the last symbol of the latest RS of each RS occasion, and from after PDCCH to the PUSCH.
AI/ML PU is not occupied.
Proposal 24: 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 25: 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 P-CSI/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 P-CSI/SP-CSI report, and is subject to inactive state otherwise.
Proposal 26: 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 in Step 4. 
Proposal 27: 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 occupancy lasts from DCI to the CSI report.
For P-CSI/SP-CSI report, the occupancy lasts for a certain time duration before the uplink symbol of per P-CSI/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 28: 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 29: For functionality alignment, regarding the set(s) of inference related parameters in Step 3 subject to Option B, consider BM specific parameters, including:
Set B and Set A resource information represented by IE resourcesForChannelMeasurement and resourcesForSetA-r19, respectively.
Resource for Set A and resource for Set B are not expected to be measured.
Associated ID(s) for Set A and Set B, if any, represented by IEs associatedIDforSetA and associatedIDforSetB, respectively.
Report type information, e.g., predicted beam ID or predicted RSRP, and whether the predicted beam ID is in forms of CRI or SSBRI, which can be represented by IE reportQuantity.
Prediction window for BM-Case 2, including number of predicted instances which can be represented by IE nroftimeinstance-r19, and time gap between reference time and earliest predicted instances as well as between consecutive predicted instances which can be represented by IE TimeGap-r19.
Proposal 30: For functionality alignment, regarding Option A Step 4, some sub-IEs under CSI-reportConfig may configure multiple candidate values, so it needs to clarify the applicable value(s) reported by the applicability report.
E.g., for A-CSI-RS, a maximum of 16 NZP CSI-RS resource sets can be configured in one nzp-CSI-RS-ResourceSetList referred by CSI-reportConfig.

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

Source:	Kyocera
Title:	Specification Support for AI/ML for Beam Management
Agenda item:	9.1.1
Document for:	Discussion and Decision

Conclusion
In the previous sections we made the following observations:
For a NW side AI/ML model, for BM Case1 and Case 2, regarding the reporting of Set B measurements for inference purpose, when (M) is equal to the size of the measurement resource set, and Set B is defined solely by the resources of this resource set, it may not be necessary to report the beam index of the largest L1-RSRP value. The measured absolute/differential L1-RSRPs alone may be sufficient for the AI/ML model to operate effectively.

Based on the discussion in the previous sections we propose the following:
 For a NW-sided AI/ML model for BM-Case1 and BM-Case2, for the configuration of inference results, RAN1 should consider the following options:
When Set B is different from Set A, no configuration for Set A is required for the UE, as the inference process is conducted transparently from the UE.
When Set B is a subset of Set A, it might be sufficient for the gNB to only configure Set A. 
FFS: Determination of Set B out of Set A.
When Set B is equal to Set A, there is no need to configure Set B and it is sufficient to only configure Set A.
The gNB should configure reporting-related parameters, including then number of beams that the UE should report.
For a UE-side AI/ML model, support configuring Sets A and B for inference results reporting, where:
When Set B is different from Set A, 
Set B is explicitly configured for measurements for the UE. It enables the UE to perform measurements that derive the UE’s AI/ML model.  
Set A can be optionally virtually configured. It is not intended to provide measurements to the UE. Instead, it serves as a reference to map the UE-side AI/ML model output, in the case of classification models, to the corresponding CRIs that the gNB can interpret.
When Set B is a subset of or equal to Set A, it may be sufficient for the gNB to only configure Set A. 
FFS: Determination of Set B out of Set A.
When Set B is equal to Set A, there is no need to configure Set B and it is sufficient to only configure Set A.
For NW-sided model, for inference report, at least for BM-Case 1, the content in a beam report in L1 signaling, support 
L1-RSRPs and corresponding beam information of Top M beam(s) with largest M measured value(s) of L1-RSRP(s) of a measurement resource set, where M is configured by gNB
M can be [4,6,8,12,16]
If M = the size of the measurement resource set, the content is all L1-RSRPs and one beam index (i.e., CRI/SSBRI) for the largest measured value of L1-RSRP of a measurement resource set.
The Following options can be considered for beam information:
Option 1: CRI/SSBRI of a measurement resource set
Option 2: A bitmap to indicate the reported beams of a measurement resource set. The bitmap consists of K bits, where K is the size of the measurement resource set,
The k-th MSB of the bitmap corresponds to the k-th resource in the resource set by the increasing order of resource ID, and the m-th nonzero bit of the bitmap corresponds to the m-th reported resources, 1≤m≤M.
For a NW-side AI/ML model, extend maxNrofNZP-CSI-RS-ResourcesPerSet (i.e., Maximum number of NZP CSI-RS resources per resource set) to 256.
For the UE-side AI/ML model, regarding the content of the report inference results, support using Options 1 through 4. Further study the benefits and gains of adopting Options 3 and 4, considering the effects of quantization methods on system throughput and considering the additional overhead incurred.
Regarding the definition of the confidence information, for option 4 of a UE side AI/ML model report content for inference, consider the following definition:
 The confidence information represents a range within which the predicted RSRP of a beam in Set A is expected to fall a certain percentage of the time if the same input sample is reused to derive the AI/ML model.
FFS on the details of the calculation of the confidence interval
For a UE side AI/ML model probability information reporting, support:
Option 1: one decimal precision probabilities where only 4 bits (bit width) are required to represent the probability information per beam.
Option 2: The probability information is represented in predefined ranges that can be of different sizes. Consider 2 bits to represent the probability information of the ranges where the ranges are:

For a UE-side AI/ML model inference report on beam ranking, where the UE is required to report the Top-K beams out of N beams in Set A, consider:
CRI-based Reporting: The UE should report the beam information in a ranked manner using a CRI vector. This involves reporting a K-dimensional vector of CRIs, where the  entry corresponds to the  strongest beam. The strongest beam can be determined by the beam information.
The strongest beams are determined by:
Probability information in case of classification models
Predicted RSRP in case of regression models.
Further study whether to support the following cases for configuration of the associated ID:
Case 1: The associated ID is configured for data collection. 
Case 1-0: The associated ID is configured for inference/step 3
UE may assume the similar properties of a DL Tx beam or beam set/list associated with the same associated ID.
Case 1-1: The associated ID is not configured for inference/step 3.
UE may report it is not applicable
AI/ML model selection is left up to the UE’s implementation.
Case 2: The associated ID is not configured for data collection. Either it is configured or not for inference:
Alt 1: The UE cannot assume anything and only uses its trained AI/ML model.
Alt 2: Depending on the UE’s capability, the UE may report that the associated ID is applicable or not.
For a UE-side AI/ML model in BM-Case 1 that predicts K beams, utilizing Option 2 (UE-assisted) performance monitoring,
Introduce the Beam Accuracy Indicator BAI in the CSI report for monitoring, where BAI is (0 ≤≤ N), and the corresponding beam prediction accuracy is, (0≤≤ 1).
The size of CSI field associated with the BAI is 
N is implicitly or explicitly configured by NW, as the number of the reported inference result(s) linked with performance monitoring instance(s).
 as the number of the reported inference result(s) linked with performance monitoring instance(s), for which:
The largest measured value(s) of L1-RSRP(s) of the resource set(s) for monitoring is Top-1 predicted beam
The largest measured value(s) of L1-RSRP(s) of the resource set(s) for monitoring is among the Top- predicted beams 
At least one of the Top M beam(s) of the resource set(s) for monitoring is among the Top-K predicted beam(s)
Where K is the number of predicted beam(s) in the corresponding inference report  
Where Top M beam(s) is the beam(s) with largest measured value(s) of L1-RSRP(s) of the resource set(s) for monitoring
M is configured by NW in CSI report configuration for monitoring, M= 1, and M is up to 4 
For BM-Case 2, at least support to report one BAI for one time instance, ,
Only one resource set is configured in the CSI-ReportConfig
The f-th time instance of the time instance in one inference report for metric calculation can either be:
Configured in the CSI-ReportConfig for monitoring
Configuration of more than one instance is not precluded 
The minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring
The performance metric of the f-th time instance is calculated based on at most 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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
Measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring.
wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring
introduce a threshold X that is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance
For UE-sided AI/ML model for beam management, for Option 2 (UE-assisted performance monitoring), the performance metric of Top 1 or Top K beam prediction accuracy is defined as:
Support the size of the set for monitoring is smaller than the size of Set A,
The mapping of the resource in the set for monitoring  more than one resource in Set A is configured via RRC and conclude that it can be done by either,
Option 1: Reuse TCI-stateID depending on the UE’s capability messaging
Other limitations are not precluded
Option 2: new RRC parameter that establishes a mapping relationship between each of the monitoring resources and multiple resources in Set A.
 At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, for BM-Case 1, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring
Introduce a threshold X for the minimal slot offset, that is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.
For BM-Case 1, the beam prediction accuracy is calculated based on at least N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
wherein N (N>=1) is configured in CSI-ReportConfig
Further consider the following options for the calculation of BAI when the threshold X is configured for the minimal slot offset:
Option 1: BAI is calculated based on only the linked monitoring instances between the two reference resources for monitoring.
The UE reports BAI and the number of linked monitoring instances.
Option 2: If at least one monitoring instance in not linked to an inference report, the UE drops the whole BAI calculation. 
FFS on additional rule for counting N linked pair
For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring
For a UE-side AI/ML model Type 1, option 2 (UE-assisted) performance monitoring, when the performance monitoring set is configured in a dedicated report separate from the inference report configuration, consider introducing a new IE “BeamCorrespondence” within “NZP-CSI-RS-Resource.” This IE should link a performance monitoring resource to a beam index. 
FFS: Other alternatives
For UE-side AI/ML performance monitoring, RAN1 should further study the following:
An event is defined as the scenario when the performance metric falls above (or below) a certain threshold.
The concept of triggering a report based on specific events is not applicable to Option 1. It is, however, relevant to Option 2, where the UE calculates performance metrics and can detect events.
At least for the AI/ML based beam management use case, reuse the same definitions for CPU occupation duration in legacy. Furthermore, RAN1 should discuss whether to keep the same values for ,  and  as legacy or further discussion for new values is needed when AI/ML is present.

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

Source:	vivo
Title:	Remaining issues on specification support for beam management
Agenda Item:	9.1.1
Document for:	Discussion and Decision

Conclusions
In this contribution, we discuss some issues on AI/ML for beam management and have the following proposals:
For inference, for UE-side model, the associated ID can be configured in inference parameter set prior to CSI-reportConfig to address the consistency issue.
For inference, for UE-side model, associated ID should be mandatory configured within both inference parameter set and CSI framework.
For inference, for UE-side model, similar properties of a list can be assumed that same resource IDs or through other rules (e.g. same ordering in a list) in Set A/Set B is consistent from training to inference if UE receives the same associated ID.
For inference, for UE-side model, an indicator should be configured within the CSI-ReportConfig to clearly specify whether following processing follows option A or option B.
For inference, for UE-side model, the set of inference related parameter in Step 3 at least includes,
Associated ID
Pattern ID
Size of Set B
Size of Set A
If 	Case 2,
Periodicity of Set B
Time gap(s) for prediction
The number of top K beam for each time instance
The number of prediction time instance
For inference, for UE-side model, along the line of the agreed working assumption on the consistency issue in AI 9.1.3.3, support to prioritize discussion on how UE-side AI model can work with local associated ID and study how to reduce UE side complexity on managing local associated IDs. 
For inference, for UE-side model, introduce a cell indicator along with the configuration of associated ID to indicate how to interpret the associated ID for further address consistency issue.
For performance monitoring, for BM-Case 1, confirm the following working assumption,
Working Assumption
At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, 
for BM-Case 1, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X for the minimal slot offset, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.
For performance monitoring, for BM-Case 1, confirm the following working assumption,
Working Assumption
For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
wherein N (N>=1) is configured in CSI-ReportConfig
FFS on additional rule for counting N linked pair
For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.
For performance monitoring, for BM-Case 1, we slightly prefer pairing link based on predefined linkage rules with an initial target of N pairs and successful linked pairs for metric counting can be smaller than N.
For performance monitoring, for BM-Case 2, confirm the following working assumption with small modification,
Working Assumption
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring. 
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance

For performance monitoring, the mapping between the resources in the set for monitoring and resources in Set A can be configured via RRC if the size of monitoring set if smaller than the size of Set A.
Each resource in the set for monitoring is configured to be mapped with one resource in Set A
Resources within Set A that are not included in the monitoring Set shall be exempt from rate matching.
For the monitoring Type 1 Option 2 of UE-side model monitoring, for BM-Case1, support to report the number of correct predictions as BAI result. 
X (X≥1) monitoring occasions of a given CSI-ReportConfig with monitoring usage are configured to UE
UE reports Y (0≤Y≤X) correct predictions from X associated monitoring occasions
BAI field size in monitoring report is equal to 
For the monitoring Type 1 Option 2 of UE-side model monitoring, for BM-Case2, support to report the number of correct predictions as BAI result for each monitoring occasion within a monitoring occasion set. 
X (X≥1) monitoring occasion of a given CSI-ReportConfig with monitoring usage are configured to UE
UE reports Y (0≤Y≤X) correct predictions from X associated monitoring occasions
Each BAI field size in the monitoring report is equal to 
The number of BAI field is equal to the number of monitoring occasions within a monitoring occasion set
For performance monitoring, for UE-side model, support to report both the number of accurate predictions and accurate ratio in the monitoring report to address initial monitoring report issue, which accurate ratio can be defined as the number of accurate predictions divided by actual monitoring instances.
For inference, for UE-side model, Set A or resources in Set A should be indicated as virtual Set or virtual resource, which does not require measurement on these resources for the report.
For inference, for UE-side model, support to report predicted L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest predicted value of L1-RSRP, as well as the number of reported beams.
For inference, for UE-side model, support time stamp information as beam content for BM-Case2.
For inference, for UE-side model, support time domain compression of beam resource indication to further reduce report overhead with a report including results of multiple occasions.
For inference, for UE-side model, support beam information on predicted Top K beam(s) among a set of beams and RSRP of predicted Top K beam(s) among a set of beams per predicted instance for content in the report for BM-Case 2.
For data collection, for NW-side model, support to report UE measurement results via L1-layer signaling and higher-layer signaling.
For data collection, for NW-side model, confirming the agreement from SI phase that more than 4 beams can be reported in a beam report. 
The maximum number of reported beam related information in one report is related to UE’s capability.
For data collection, for NW-side model, it is crucial to investigate approaches to minimize the overhead of the report transmitted through L1-layer or higher-layer signaling.
For data collection, for NW-side model, report content supported in current specification can be re-used for BM-Case 1 and BM-Case 2, i.e. L1-RSRPs and corresponding beam information.
For data collection, for NW-side model, enhancement on overhead reduction should be supported for BM-Case 1.
For data collection and inference, for NW-side model, enhancement on overhead reduction should be supported for BM-Case 2, e.g. consider to use time domain data compression to reduce overhead.
For inference, for NW-side model, support to report L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP, as well as the number of reported beams.
Confirm the following FL’s proposal for beam information,
For NW-sided model, for inference report, at least for BM-Case 1, 
when M4, a bitmap and a resource indicator can be configured to be reported by RRC, 
The bitmap consists of K bits, where K is the size of the measurement resource set,
The k-th MSB of the bitmap corresponds to the k-th resource in the resource set by the increasing order of resource ID, and the m-th nonzero bit of the bitmap corresponds to the m-th reported resources, 1≤m≤M
The resource indicator indicates the resource with the largest measured value of L1-RSRP from the M reported resources in the resource set, 
The size of the CSI field for the resource indicator is 
Note: no separate UE feature is introduced for the bitmap-based method.  
Note: Purpose, such as above “For NW-sided model, for inference report, at least for BM-Case 1”, will not be specified in RAN 1 specification
For UE-sided model, regarding a CSI-ReportConfig for data collection, =0.
For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, 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
Option 2: only legacy CPU is occupied,   it is reported by UE.
Note: The supported option by UE is reported by UE capability
For UE-side model, for AI/ML based beam management, support the following options for occupation duration for inference:
For BM-Case 1, legacy CPU occupation duration for P/SP/AP CSI report is reused
For BM-Case 2, legacy CPU occupation duration for Rel-18 CSI prediction based on P/SP CSI-RS is reused

3GPP TSG-RAN WG1 Meeting #121	R1- 2503432
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	9.1.1
Source:	Ericsson
Title:	AI/ML for beam management
Document for:	Discussion

Conclusions

In the previous sections we made the following observations: 
Observation 1	TCI states for semi-persistent resources can already be supported via deactivation/activation MAC CE messages. Similar update should be supported for AP CSI-RS ResourceSet.
Based on the discussion in the previous sections we propose the following:
Proposal 1	For UE-sided model, in CSI-ReportConfig, the resourceConfig for set A can only include a single resource set.
Proposal 2	For UE-sided model, for aPeriodic CSI inference report configuration, AssociatedReportConfigInfo comprises the UE assumptions regarding set B.
Proposal 3	For UE-sided model, for aPeriodic CSI inference report configuration, when set B is NOT a subset of set A, the resourceConfig for set B can only include a single resourceSet.
Proposal 4	For the UE-sided model, RAN1 should clarify what the UE assumes for the applicability reporting of the NW configured predicted resources (i.e. the NZP-CSI-ResourceIDs in set A), and select one of the following options:
a)	UE does not consider any of the NW configured time-frequency occupation of the predicted resources
b)	UE considers the NW configured frequency occupation of the predicted resources
c)	UE considers both the NW configured time and frequency occupation of the predicted resources
Proposal 5	For both NW-side model and UE-side model, extend the maxNrofNZP-CSI-RS-ResourcesPerSet (i.e., Maximum number of NZP CSI-RS resources per resource set) to 256, subject to UE capability.
Proposal 6	For the UE-sided inference result report, support UE indicating in UCI if the inference result report is inaccurate/invalid (e.g. setting the CRI or SSB-RI to a certain “dummy” value)
Proposal 7	For UE-sided performance monitoring, for semi-persistent CSI report configuration, support joint activation of the monitoring and linked inference CSI report configuration.
Proposal 8	For P2 sweep based on UE/NW beam prediction, for AP CSI-RS for AP CSI report, support that NW configures K CSI-RS resources and dynamically indicate the QCL information (TCI-stateID) as part of the MAC CE to the K CSI-RS resources. The TCI states are updated for a CSI-RS Set ID that is part of the CSI-AssociatedReportConfigInfo.
Proposal 9	For P2 sweep based on UE beam prediction, support that NW can configure an AP CSI-RS and AP CSI report that indicates that NW follows the UE Top-K prediction, and UE assumes that NW transmits the AP CSI-RS in the order of the TCI-StateID corresponding to the latest Top-K predictions.
Proposal 10	For NW-sided model, regarding max number of reported beam related information in one report, support UE reporting of all measured beams in a resourceSet (i.e. support up to 64 reported beams subject to UE capability).
Proposal 11	For AI/ML PUs, downselect to support a single option, preferably option 1 where N1 and the total number of AI/ML PUs is reported as part of the UE capability.
Proposal 12	For BM-Case 1, legacy CPU occupation duration for P/SP/AP CSI report is reused in principle.
Proposal 13	For BM-Case 2, legacy CPU occupation duration for P/SP CSI (excluding R18 typeII-Doppler PMI associated SP CSI reports) report is reused in principle (i.e. alternative 1).
Proposal 14	Regarding active CSI-RS resources for AI/ML inference. Predicted CSI-Resources that are part of set A for inference is not considered as active. The number of simultaneously active associated IDs might need to be restricted, but not the number of configured predicted CSI-Resources.
 

3GPP TSG RAN WG1 #121		R1-2503505
St Julian’s, Malta, 19th – 23rd May 2025
Agenda Item:     9.1.1
Source:	Spreadtrum, UNISOC
Title:	             Discussion on AIML for beam management
Document for:	Discussion and decision

Conclusion 
In this contribution, we provide our opinions on standard impacts of sub use case – BM:
Observation 1: For Alt.1(Beam prediction accuracy related KPIs), UE can not calculate the metric based on one time prediction results.
Observation 2: For Alt.1(Beam prediction accuracy related KPIs), the monitoring set should be full set of Set A.
Observation 3: For Alt.2 (L1-RSRP difference information based on actual measurement), the monitoring set should be full set of Set A.
Observation 4: Alt.3 (RSRP difference information between the predicted RSRP and measured L1-RSRP of corresponding beam(s)) will limit the use to regression models only.
Observation 5: Alt.4 (The probability information of the predicted beam(s) to be the Top 1 or Top K beam) will limit the use to classification models only.
Observation 6: The reliability of Alt.4 (The probability information of the predicted beam(s) to be the Top 1 or Top K beam) is questionable.

Proposal 1: For both NW-side model and UE-side model, support Alt 1 (extend the maxNrofNZP-CSI-RS-ResourcesPerSet to 256).
Proposal 2: For the configuration of inference results reporting for UE-side model, not support only resource set for Set B is configured.
Proposal 3: For NW-side model, for reported beam information, only support CRI/SSBRI of a measurement resource set.
Proposal 4: For NW-side model, only support to report L1-RSRPs and corresponding beam information of Top M beam(s) with largest M measured value(s) of L1-RSRP(s)
Not support to report L1-RSRPs and corresponding beam information of up to M beams within X dB gap.
Proposal 5: For NW-sided model, for inference, in a beam report initiated by network, based on one measurement resource set, the value of M of reported beam in one report is configurable, and up to 32.
Proposal 6：For NW-sided model, both L1 and high-layer signaling can be used for data collection for training.
Proposal 7：For the content for data collection for training for NW-sided model via higher layer signaling, all three types of contents for each instance should be supported.
Proposal 8: For BM-Case2, TCI indication framework should be reused by gNB, e.g., beams from multiple time instance can be indicated to UE by multiple beam indications respectively.
Proposal 9: Reporting multiple past time instances in one reporting instance for BM-Case2 is not needed.
Proposal 10: For content in the report of inference results, only support option 1 and option 2.
Proposal 11: For UE-sided model, at least for BM-Case1, for content in the report of inference results, for Opt 1 (only beam information of predicted Top K beam(s)), the ranking information of the predicted Top K beams for K > 1 is conveyed by the order of the beam information. 
•	How to obtain the ranking information belongs to UE implementation.
Proposal 12: Not support Alt.4 for Option 2 (UE-assisted performance monitoring).
Proposal 13: For inference for UE-side models, to ensure consistency between training and inference, option 1 should be considered.
Proposal 14: The configuration of associated ID should be mandatory.
Proposal 15: 	For UE-side model, for processing of a CSI report for inference, support Option 2: only legacy CPU is occupied.
Proposal 16: 	For UE-side model, use the following occupation duration in principle, 
from the 1st symbol of K_p-th latest consecutive P/SP CSI-RS occasions no later than CSI reference resource, until the last symbol of the PUSCH carrying the report

3GPP TSG RAN WG1 #121			R1-2503550
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda item:	9.1.1
Source:	Samsung
Title:	Discussion for supporting AI/ML based beam management
Document for:	Discussion and Decision

Conclusion
The observations and proposals made in this contribution are summarized below.
Proposal 1. From RAN 1 perspective, for the content of data collection for training for NW-sided model via higher layer signaling (i.e., MDT in RRC), support the following three types of content for each transmission occasion of configured RS resources
Type 1: L1-RSRP of each of the configured RS resources
The resource index corresponding to the L1-RSRP is derived implicitly by the order of configured resources
Type 2: L1-RSRP of each of configured RS resources in a first set and K1 resource indexes with K1 highest L1-RSRP for configured RS resources in a second set 
The resource index corresponding to the L1-RSRP for the first set is derived implicitly by the order of configured resources
K1 is configured by RRC
Type 3: L1-RSRP of each of configured RS resources in a first set and K2 resource indexes with K1 highest L1-RSRP and the corresponding L1-RSRPs for configured RS resources in a second set 
The resource index corresponding to the L1-RSRP for the first set is derived implicitly by the order of configured resources
K2 is configured by RRC
Note: “for content for data collection for training for NW-sided model via higher layer signaling (i.e., MDT in RRC)” is only for discission purpose.

Proposal 2. For the measurement of more than 64 beams, support the following:
Introduce extend the existing UE capability (i.e., maxNumberCSI-RS-Resource) to indicate the maximum total number of configured NZP-CSI-RS resources that are supported by the UE to measure L1-RSRP to [256]
For the configuration of measurement set, down-select one of the following
Alt-1. extend the maxNrofNZP-CSI-RS-ResourcesPerSet (i.e., maximum number of NZP CSI-RS resources per resource set) to [256].
Alt-2. Up to [4] resource sets can be configured for Set A in a CSI-ReportConfig, where a reported beam index is corresponding to a resource from one of the [4] resource sets.

Proposal 3. For NW-side AI/ML model inference, at least for BM-Case 1, regarding the content in a beam report in L1 signalling, if M < the size of the measurement resource set, support the configurability between the following options:
Option 1. M CRI/SSBRI and M corresponding L1-RSRP are reported
Option 2. K-bit bitmap, a resource indicator and M corresponding L1-RSRP are reported, where 
The number of nonzero bits in the bitmap is M, and K is the size of the measurement resource set 
The k-th MSB of the bitmap corresponds to the k-th resource in the resource set by the increasing order of resource ID, and the m-th nonzero bit of the bitmap corresponds to the m-th reported resources, 1≤m≤M
The resource indicator indicates the resource with the largest measured value of L1-RSRP from the M reported resources in the resource set, and the size of the corresponding CSI field is .

Proposal 4. For NW-side AI/ML model inference, support a CSI report with the measurement results for each of the P (P>1) latest transmission occasions no later than CSI reference resource corresponding to the CSI report
P is configured in the corresponding CSI-ReportConfig via RRC subject to UE capability 
Reuse the same report format (i.e., CSI field mapping order) as for BM-Case2 for UE-sided model inference in case of Opt 2 by replacing “time instance” to “transmission occasion”

Proposal 5. Agree the following as conclusion:
For UE/NW-sided model, P2 beam sweeping based on predicted beams is supported by existing specification.

Proposal 6. For UE-sided model, regarding the SP CSI-RS resource for data collection purpose, support joint activation/deactivation of Set A and Set B using the existing MAC-CE.
If Set A is activated by a MAC-CE, UE perform measurement on both Set A and Set B
If Set B is a subset of Set A, TCI state for a resource in Set B is the same as the TCI state of same resource in Set A indicated by the MAC-CE
If Set A is deactivated by a MAC-CE, UE stop perform measurement on both Set A and Set B

Proposal 7. For UE-sided model, at least for BM-Case1, for content in the report of inference results, support:
Opt 3: Beam information on predicted Top K beam(s) among a set of beams and probability information of predicted Top K beam(s) among a set of beams
Probability information is the probability of the beam to be the Top 1 or Top K beam

Proposal 8. For UE-sided model, at least for BM-Case1, for beam information on predicted Top K beam(s) among a set of beams, if K>1, the reported CRI or SSBRI #k corresponding to the k-th strongest resource.

Proposal 9. For UE-sided model inference for BM-Case1, support the following report format (i.e., CSI field mapping order) for BM-Case1, for beam information on only predicted Top K beam(s) among a set of beams.
CRI or SSBRI #k corresponding to the k-th strongest predicted resource, where k = 1, 2…, K
Note: existing payload sizes for CRI/SSBRI is reused.

Proposal 10. For BM-Case 2 of UE-side model, future time instance is defined as a single slot.

Proposal 11. For UE-sided model inference for BM-Case2, support the following report format (i.e., CSI field mapping order) for beam information on only predicted Top K beam(s) among a set of beams:
Time instance #1~#N are mapped to the N time instance(s) based on the time domain order of the time instances
where time instance #1 is mapped to the earliest time instance from the N time instance(s)
CRI or SSBRI #k corresponding to the k-th strongest predicted resource with the same time instance, where k = 1, 2…, K
Note: existing payload sizes for CRI/SSBRI is reused.

Proposal 12. For UE-sided model, in CSI-ReportConfig for inference, support to configure Set B with aperiodic CSI-RS resources.
Proposal 13. At least for the monitoring Type 1 Option 2 of UE-side model monitoring (when applicable), for the calculation of the performance metric for beam prediction accuracy, if the size of Set A is the lager than the size of resource set for monitoring down-select from one of the following:
Alt-1. The i-th resource within Set A is linked to the -th resource in the resource set for monitoring, where D is configured by RRC
D = [1, 2, 4, 8]
Alt-2. Each resource within the resource set for monitoring is linked to one or more resources within Set A based on dedicated RRC signaling
A list with Y entries is configured by the RRC, where Y is the size of the set for monitoring
The y-th entry in the list corresponds to the y-th resources in the set for monitoring by increasing order of resource ID, 1≤y≤Y
Each entry in the list indicates one or more resources in Set A
Alt-3. Each resource within the resource set for monitoring is linked to one resource within Set A based on dedicated RRC signaling
X-bit bitmap with Y non-zero bits is configured by the RRC, where X is the size of Set A and Y is the size of the set for monitoring
The x-th MSB of the bitmap corresponds to x-th resource in Set A by increasing order of resource ID 
The y-th nonzero bit of the bitmap corresponds to the y-th resources in the set for monitoring by increasing order of resource ID, 1≤y≤Y

Proposal 14. Confirm the working assumption in RAN1#120bis with the following update

Proposal 15. Confirm the working assumption in RAN1#120bis with the following update

Proposal 16. Confirm the working assumption in RAN1#120bis with the following update

Proposal 17. Introduce a new quantity (i.e., beam accuracy indicator, BAI) for beam prediction accuracy in the CSI report for monitoring, where BAI is (0 ≤≤ N) and the corresponding beam prediction accuracy is, (0≤≤ 1)
The size of CSI field associated with the BAI is 
Where  is the number of transmission occasion for monitoring that meet the metric within the N transmission occasion(s)

Proposal 18. For UE-sided model, regarding a CSI-ReportConfig for data collection, .

Proposal 19. For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, regarding the processing of a CSI report corresponding to a CSI-ReportConfig for inference, support the following
The number of occupied dedicated AI/ML PU is subject to UE capability
The number of occupied CPU is either 0 or 1 subject to UE capability

Proposal 20. For UE-side model, for processing of a CSI report corresponding to a CSI-ReportConfig for inference, legacy definition of CPU occupation time is reused for the occupation time for both CPU and AI/ML PU for the CSI report
For BM-Case1, the legacy definition of Rel-15 P/SP/AP CSI is reused
For BM-Case2, the legacy definition of CSI for Rel-18 doppler domain CSI prediction is reused

Proposal 21. For UE-side model, for processing of a CSI report corresponding to a CSI-ReportConfig for inference, the principle of CSI for Rel-18 doppler domain CSI prediction is reused:
For AP CSI report, the legacy definition of CPU occupation time for existing AP CSI report is reused
For P/SP CSI report, CPU occupies from the first symbol of the N-th latest transmission occasion(s) of monitoring resources no later than CSI reference resource, until the last symbol of the PUSCH/PUCCH carrying the report

Proposal 22. For the determination of CSI report associated with AI/ML, the existing  is reused
k =0 when the CSI report is with inference result for BM-Case1 and BM-Case2 for UE-sided model

Proposal 23. Support UE only updates a subset of requested CSI reports based on AI/ML PU occupation and priority rules for CSI reports
Follow the legacy principle for updating a subset of requested CSI reports based on CPU occupation and priority rules for CSI reports

Proposal 24. For the determination of updated CSI reports based on CPU occupation and priority rules for CSI reports subject to a given OFDM symbol, a CSI report is not considered if the following conditions are met:
the CSI report occupies one CPU and at least one AI/ML PU
the CSI report is not required to be updated subject to the same OFDM symbol based on AI/ML PU occupation and priority rules for CSI reports

Proposal 25. For the CSI report for inference for UE-side model, support the scaling of legacy Z timeline (i.e., Z3/Z3’) for beam management with a scaling factor
The scaling factor is subject to UE capability

Proposal 26. For Option B of applicability report, consider the following as part of the contents
One or two associated ID(s)
The size of Set A
The size of Set B
Mapping between Set A and Set B (if one single associated ID is provided)
Report quantity
Time gap information (for BM-Case2)
The number of predicted time instance(s) (for BM-Case2)

3GPP TSG RAN WG1 Meeting #121                                                                             R1-2503627
Malta, Malta, May 19th – 23rd, 2025
Source:	TCL
Title:	Discussion on AI/ML beam management	
Agenda Item:	9.1.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we make the following observations.
Observation 1: The Top-K beam sweeping introduces extra measurement overhead especially for BM-Case2. 
Observation 2: It is straightforward to consider merging of the measurement of Top-K beam sweeping and model monitoring for overhead/complexity reduction purposes.
Observation 3: The beam shape information is more stationary comparing to the beam index information during data collection.
Observation 4: Introducing he AI/ML based beam prediction into the BFD and BFR procedure is potentially reduce the overhead of reference signals and improve the efficiency of BFR, that is beneficial to the system performance.
Observation 5: In the AI-aided BFR procedure, the candidate beams can be predict based on the measurement results from both BFD and BFR procedure, which enables a common RS configuration for both BFD and BFR.
Observation 6: The legacy BFD is potentially to be replaced by AI/ML based BF event prediction, or at least being simplified by only measuring a few beam samples.
Observation 7: The prediction on both BF event and candidate beams for BFR will fully utilize the capability of AI/ML model.
In this contribution, we have the following proposals.
Proposal 1: Conventional P1/P2/P3 approach to beam pairing/refinement can be simplified by AI/ML beam prediction to two phases.
FFS: If the AI/ML model in P1 is able to predict the DL-Tx-Rx beam pairs, only one phase is required for beam pairing as the Rx beam selection is also acquired in P1.
Proposal 2: Measurement patterns for AI/ML beam management should be designed for spatial domain beam prediction, and should consider both the fixed regular and random patterns.
Proposal 3: The measurement results collected during Top-K beam sweeping could be used in the performance monitoring. 
Option 1: The results obtained from Top-K beam sweeping could be used to trigger the performance monitoring. 
Option 2: The results obtained from Top-K beam sweeping could be used to calculate the metrics of the performance monitoring. 
Proposal 4: Both dedicated AI/ML PU and legacy CPU are occupied for AI-related CSI report for inference.
FFS if the CPU occupied by the AI-related CSI report and the legacy CSI report share the same amount of CPU. 
FFS if data collection for usage of AI/ML model is counted by AI/ML PU or legacy CPU.
Proposal 5: Study the selection rule if the AI-related CSI report to be reported is jointly determined by the legacy CPU and AI/ML PU. 
Option 1: Selection of CSI report prioritizes the AI/ML PU constraint. 
Option 2: Selection of CSI report prioritizes the legacy CPU constraint. 
Option 3: Selection of CSI report jointly considers the legacy CPU and AI/ML PU constraint. 
Proposal 6: The occupation time of CPU and A/ML PU should be considered separately. The duration of the PU occupation time could be configured by the NW.
Proposal 7: For BM-Case2,  we need to define he valid duration of the prediction result to determine if a prediction result is valid or not. 
The invalid prediction could be omitted in the CSI report for overhead reduction purpose.
Proposal 8: If the associated ID is globally or cross-cell defined, an explicit mapping between the associated ID and the NW additional conditions should be defined.
Proposal 9: The associated ID in AI/ML beam management at least ensures the beam consistency.
FFS: the details of the beam consistency.
Option 1: The beam consistency means same beam index or beam order in both training and inference.
Option 2: The beam consistency means same beam shape or beam codebook in both training and inference.
Proposal 10: The associated ID may contain the time information about the data collection if no explicit time stamps come with the collected data.
Proposal 11: The associated ID could be indicated using the TCI framework FFS the details of corresponding TCI enhancement. 
Proposal 12: Study to use AI/ML based beam prediction to maintain the candidate beam list for BFR.
Proposal 13: Study to integrate the RS configuration and measurement configuration of BFD and BFR under a unified AI/ML based framework.
Proposal 14: Study to evolve the BFD to BF event prediction while using temporal beam prediction to find the candidate beams for BFR.
Proposal 15: The following enhancement on the TCI framework should be considered to support the AI/ML BM.
Additional TCI state ID dedicated for AI/ML BP should be introduced.
New QCL types is indicated in TCI state to associate the RS sets corresponding to Set A and Set B beams. 
At least for BM-Case2, timing information related to different predicted beams should be configured to the UE using RRC signaling, e.g., included in the TCI state information.
Proposal 16: The following enhancement on the beam management report should be considered.
Alt. 1 Indicating the model type and/or a bitmap to indicate the selected report quantities.
Alt. 2 Indicating the model type and/or the report type to indicate the selected report quantities.
Proposal 17: RAN1 should consider the following enhancement on the report of AI/ML beam management.
For overhead reduction purpose, study the quantization of report quantities, starting from the enhancement on the RSRP quantization.
Study the two-stage report mechanism using both PUCCH and PUSCH. 
Proposal 18: For BM-Case2, the following overhead reduction approach can be considered.
 The report may be split into multiple groups for latency and overhead reduction, FFS the splitting rule and collision control mechanism.
The selection of predicted beams in the report can be indicated by a reference beam plus a bitmap indicating the appearance of predicted beams within the neighbourhood.

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

Agenda item:	9.1.1
Title:	Discussion on AI/ML-based beam management
Source:	ZTE Corporation, Sanechips
Document for:	Discussion and Decision

Conclusions
In this contribution, we discuss the specification enhancements for AI/ML based beam management. We have the following proposals.
Data collection
For applicable functionality reporting for beam management UE-sided model, Option B inference related parameters includes the followings: 
Associated ID for Set A and Set B
Size of Set A and Set B
Set B pattern information if only one associated ID is provided
Number of prediction time instances for BM-Case2
Time gap for prediction for BM-Case2
Set B periodicity for BM-Case2
For content for data collection for training for NW-sided model via higher layer signaling, for BM-Case1, both three types of contents can be considered to serve for different training strategies at the NW side.
Prioritize Alt 1 among the two alternatives on how to support increased number of resources for Set A.
For NW-sided model, for inference report, at least for BM-Case 1, the content in a beam report in L1 signaling, support L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP, X and M are configured by gNB.
For the reporting of L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP, the legacy two parts encoding method for CSI reports should be reused as much as possible.
For overhead reduction, support to specify threshold based beam reporting method with configurable minimum and maximum number of reported beam related information in a single report.
For overhead reduction, support specification enhancements for data omission among samples (e.g., according to data quality).
Observation 1: Compared with the legacy CRI/SSBRI based method for reporting beam information, the bitmap based method can reduce the reporting overhead by 8.3%, 37.5%, 53.8%, and 63.5% when half of measurements are reported and the number of beams in the measurement resource set is 8, 16, 32, and 64, respectively.
Support to specify the bitmap based method for the reporting of beam information given the fact that it can greatly reduce the reporting overhead in typical settings without compromising any beam prediction performance.
At least support L1 signaling for NW-side data collection irrespective of the purpose of data collection (e.g., model training, model inference, and performance monitoring).

Model inference
For NW-sided model inference, the report content for beam related information comprises beam ID information and L1-RSRP, where the beam ID information can be reported by new beam indexing formats (e.g., bitmap) to reduce the reporting overhead.
For NW-sided model inference, the maximum number of reported beam related information in one report can be configured by the NW based on UE capability indication.
For the determination of maximum value of M of reported beam in one report, first clarify whether L1 signaling is supported for data collection and monitoring of NW-sided model and the maximum number of beams for Set B/Set A.
For NW-sided model, in a beam report initiated by network, based on one measurement resource set, maximum value of M of reported beam in one report is configurable and can be 4, 6, 8, 12, 16, 32, 64, 128, 256.
Support enhancements to report information about measurements of multiple past time instances in one reporting instance for BM-Case2, at least from the following aspects.
Indication of the timestamp information
Indication of the reference beam
Indication of the common beam information, e.g., a common/super set of beam IDs to be reported
Support a common framework design for the measurement reporting of multiple past time instances for NW-sided model and prediction reporting of multiple future time instances for UE-sided model.
If Set A and Set B are different, resources for Set A and resources for Set B are configured as separate resource sets, and the association between Set A and Set B can be established based on the same CSI report setting.
If Set B is a subset of Set A, only resources for Set A is configured, and resources for Set B is indicated as a subset of Set A based on assistance information provided by the NW, such as the mapping between Set A and Set B in the form of bitmap.
For UE-sided model, at least for BM-Case1, for content in the report of inference results, support the reporting of RSRP in Option 2 and probability information in Option 3 for beam selection at the NW side. 
The predicted Top-K beams are the K beams with the highest predicted RSRP (or probability information)
The beam information is CRI or SSBRI
For content in the report of inference results, at least for Opt 1: Beam information on predicted Top K beam(s) among a set of beams, the ranking information of Top K beams can be conveyed by reporting Top-K beam IDs in a descending order according to the predicted RSRP (or probability information) values.
For temporal beam prediction at the NW/UE side, study enhanced resource indication method to enable efficient resource activation in the measurement window and deactivation in the prediction window.
For BM-Case2 (both UE-sided and NW-sided model), support to extend the Rel-17 TCI state activation/indication signalling methods to activate/indicate N TCI states which are corresponding to N future time instances.
For enabling a P2 sweep based on predicted Top-K beams for UE-sided model, Option 1 can be considered to reduce the signaling overhead for the indication of TCI states associated with the predicted Top-K beams.
For enabling a P2 sweep based on predicted Top-K beams for both NW-sided and UE-sided model, NW indicates dynamically as part of the triggering DCI the QCL information associated with the predicted Top-K beams (e.g., in the form of an ID representing a combination of K TCI states).
Observation 2: The resource occupation for AI/ML-based CSI processing is impacted not only by the report content, but also by the implementation algorithms at the UE side.
For forward compatibility, support UE to report the number of processing units consumed for each AI/ML-based functionality or CSI report.
The overall CPU can be separately counted between legacy CSI reporting and AI/ML-based CSI reporting, which provide flexibility to accommodate the adoption of hardware other than CPUs for AI/ML processing.
Among the different options for CPU occupation for a AL/ML based CSI report, support Option 2 Alt 1 due to its lower spec impacts and better forward compatibility.
Consider the incorporation of functionality activation latency or inference latency in the CSI processing timeline.

Performance monitoring
Considering the limited payload size and near-real-time latency requirement, support L1 measurement (CSI reporting) for collecting data to enable Type 1 performance monitoring Option 1 (i.e., NW-side performance monitoring).
For Option 2 (UE-assisted performance monitoring), further consider monitoring report initiated by NW and monitoring report initiated by UE.
 For monitoring report initiated by NW, the report content can be a calculated performance metric or an indication about whether the calculated performance metric is larger than or equal to a configurable threshold.
Consider UE-initiated monitoring report on the basis of the beam failure recovery mechanisms specified in current specifications.
For BM-Case1, the time duration between a monitoring resource occasion and the CSI reference resource corresponding to the linked inference report should be not larger than a threshold X. Otherwise, the monitoring resource occasion has no linked inference report.
For BM-Case2, the time duration between a monitoring resource occasion and the linked prediction time instance in the inference report should be not larger than a threshold X. Otherwise, the monitoring resource occasion has no linked prediction time instance.
For beam prediction accuracy in the CSI report for monitoring, the beam accuracy indicator is defined as  (0 ≤≤ N), where N is configured by the base station referring to the number of monitoring resource occasions.
Type 2 performance monitoring (i.e., UE-side performance monitoring) can only be supported if the UE is authorized by the NW for functionality or model operations.
For the case that a subset of Set A is configured as the monitoring resource set, further evaluation validation is required before down-selecting the different alternatives given that none of the alternatives have been evaluated before.
If the resource set for monitoring cannot cover the full resources of Set A, consider QCL relationship based mapping between the resources for Set A and resources for monitoring for performance metric calculation.
Model/functionality failure detection should be based on monitoring results of several consecutive times within a predefined monitoring window.
UE reporting based on measurement of Set B can serve as an always-on fallback method to guarantee continuous services quality.

NW-side additional conditions
Observation 3: Associated ID based approach to align NW-side additional conditions across training and inference can be challenging due to the following concerns.
Matching ID granularity and model capability
Signaling overhead for ID exchange
Proprietary information disclosure risks
For UE sided model in beam management, UE may assume the similar properties of a DL Tx beam set/list associated with the same associated ID.
There is no necessity to further define similar properties of a DL Tx beam or beam set/list regarding UE assumption upon repeatedly receiving the same associated ID.
The configuration of associated ID is optional and can be configured by the NW if necessary.
If multiple aperiodic CSI-RS resource sets are configured within one single CSI resource setting, the configured one associated ID shall be applicable to all aperiodic CSI-RS resource sets.
For UE-sided model, the number of CPU corresponding to a CSI report for data collection is 1 as legacy.

3GPP TSG RAN WG1 #121			R1-2503709
Malta, MT, May 19th – 25th, 2025
Agenda item:	9.1.1
Source:	Tejas Networks Ltd.
Title:	Specification support for Beam management 
Document for:	Discussion and Decision

Conclusions
Proposal 1: For UE sided model in beam management,
Associated ID should be configured as part of the CSI-Report Config and mapped to the resources in Set A (predicted beams) and Set B (measured beams).
Proposal 2: For UE sided model in beam management, for configuring Associated support higher layer signaling such as RRC or MAC-CE or QUI other than CSI configuration
FFS: Whether additional enhancements are required for signaling mechanisms beyond the CSI framework to support Associated ID transmission. 
Proposal 3: For UE sided model in beam management, to ensure consistency between model training and inference, consider the Associated ID as
                     Associated ID =  
Proposal 4: For UE sided model in beam management, The DL Tx beam or beam set/list associated with the same associated ID should be consistent in terms of transmission properties (e.g., spatial domain characteristics such as beam shape).
Proposal 5: For BM-Case1 and BM-Case2 with a UE-side AI/ML model, for Type 1 performance monitoring Option 1 (NW-side performance monitoring), L1 signaling can be used to send the measurement results to NW for the calculation of performance metrics at NW.
Note: this does not preclude to use higher layer signaling for Type 1 performance monitoring Option 1.
Note: measurement results refer to “measurement results from resource set for monitoring, e.g., L1-RSRP and/or RS index is supported as the content of the report in previous agreement”.
Proposal 6: For BAI calculation, considering the following option,
Option 3c: 
Where:
 is the weight given to   predicted beam.
   is the indicator determines the accuracy of prediction.
1 for if the   predicted beam is among the Top-M beams with the highest measured L1-RSRP values.
 for if the predicted beam is among the Top-M beams with the highest measured L1-RSRP values.
Proposal 7: For UE-side model monitoring, to trigger the report based on an event, consider Event 1 (predicted beam accuracy of the set of predicted beams being below a threshold accuracy) with statistical results in a given window.
Observation 1: The UE is in a high-mobility environment, the prediction window should be shorter to maintain accuracy, while a more stable environment may allow for a longer window.
Proposal 8: For NW-sided model, for BM-Case 2, support to report of measurement results of multiple past time instances in one report.
Observation 2: Instead of reporting the absolute L1-RSRP values for each time instance, differential values can be reported. This reduces the reporting overhead since only the relative change in RSRP from one time instance to the next needs to be communicated.
Proposal 9: For NW-sided model, for BM-case 2, at least for model inference support dynamic configuration approach that should be developed to allow the gNB to request data from specific time instances that are most relevant for beam prediction.
Observation 3: When low-latency is critical, immediate reporting should be prioritized. For cases involving large sets of data (such as multiple time instances), higher-layer signaling (RRC or MAC layer) should be used to handle the report, as this avoids the scheduling delays associated with lower layers (e.g., PUSCH).

Proposal 10: For inference report at NW sided model at least for BM-case 1, consider L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP.
Proposal 11: For inference report at NW sided model at least for BM-case 1, maximum value of M and X dB gap to the largest measured value of L1-RSRP is configured by gNB.
Proposal 12: Consider M = 256 as the starting point which is agreed in study item for NW-sided model inference.
Proposal 13: For NW-sided model inference, for content of beam related information, consider CRI along with L1-RSRP as a starting point.
Proposal 14: At least for NW-sided model, for differential L1-RSRP reporting, support for introducing a larger quantization step size for differential L1-RSRP reporting. 
Proposal 15: For data collection for training for NW-sided model, from RAN 1 perspective, 
L1 signaling can be used
It is up to RAN2 on whether to use RRC/MDT procedures 

Proposal 16: For NW-sided model, at least for training data collection, at least for BM-Case 1, For L1 signaling, the content of a beam report should:
Support L1-RSRPs and corresponding beam information for up to M beams within an X dB gap to the highest measured L1-RSRP value, where X and M are configurable by the gNB.
FFS: whether and how to report the number of reported beams.
Proposal 17: For NW-Sided Model, Inference Report (BM-Case 1)
Options for Beam Reporting When M < N
Option 1: Report the CRI/SSBRI (Cell Reference Index/SS Block Reference Index) for each beam in the measurement resource set.
Option 2: Utilize a bit map to indicate the reported beams from the measurement resource set and include one beam index (i.e., CRI/SSBRI) for the beam with the largest measured L1-RSRP within the set.

Proposal 18: For BM-Case 2 of UE-side model, for the reference time of the earliest time instance, consider option 2: Based on the CSI reference resource corresponding to the report.
Proposal 19: For BM-Case1 and BM-Case2 with a UE-side AI/ML model, consider Top-K beam prediction accuracy report for UE-assisted performance monitoring.
Proposal 20: For BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring), configure the resource set(s) for monitoring within the existing CSI report configuration used for inference.
Proposal 21: For BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option2 (UE-assisted performance monitoring), for metric calculation use either a fixed window size (e.g., 10 ms, 100 ms) or dynamic adjustment based on network conditions.
Proposal 22: For BM-Case 2, to extend the Rel-17 TCI state activation/indication signaling methods:
Maximum number (N) of joint TCI states: N can vary based on system capability, but initial studies suggest values between 2 and 4 are reasonable, considering complexity and signaling overhead.
Depending on traffic patterns and mobility scenarios, a higher N could be explored, but efficiency may degrade due to larger signaling loads and interference management.
Proposal 23: For BM-Case 2, to extend the Rel-17 TCI state activation/indication signaling methods:
Time periods should align with UE mobility and channel coherence time. Proposals suggest dynamically adapting this based on real-time radio conditions using AI models to predict optimal timing windows, e.g., based on Doppler shifts, historical data, or network feedback.
Proposal 24: For TCI state configuration in BM-Case 2, for Training and inference:
Use historic TCI state for predicting N future TCI states, along with Set B historic measurements.
TCI state are configured along with Set A, Set B and Associated ID.
Proposal 25: For the beam indication, to ensure valid TCI states for Top-K 
To ensure valid TCI states for Top-K measurements during inference, prioritize the Top-K measurements based on historical data and real-time conditions. A dynamic ranking of TCI states can be done, ensuring the highest probability of correct beam activation. 

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

Source:	Ofinno
Title:	Discussion on AI/ML for beam management
Agenda Item:	9.1.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we make the following proposals and observations. 
For the case that the network configures that the UE is allowed to initiate request for data collection (e.g. start/stop indication):
RAN1 to discuss event(s) or condition(s) to trigger UE requests to initiate/stop data collection, e.g., based on the inference performance of a deployed model to collect training data for a second model.
RAN1 to discuss signal container to trigger/send UE request to initiate/stop data collection, e.g., use UEIBR first PUCCH to send the request.
Regarding timing of inference result report for BM-Case2, support one of the following options
Option 1: Inference result report timing should occur before the earliest time instance of N predicted time instances. gNB ensures to configure the time gap such that the report can occur before the first time instance.  
Option 2: No restriction on inference result report timing for N predicted time instances
Drop predicted results corresponding to outdated time instance, and utilize bit fields to include either RSRP difference between predicted RSRP and measured RSRP or performance indicator. 
Specify UE-initiated inference results report mechanism, to override previously reported inference results. 
For contents in the report of inference results, consider improving Opt.1 and Opt. 2 to allow informing prediction quality (e.g., probability information, confidence information). 
Specify RRC configuration of a threshold for prediction quality and discuss report options based on the threshold. 
In terms of reporting, consider options (1) to include predicted beams, satisfying the threshold, from top K predicted beams; (2) to indicate whether each predicted beam satisfies the threshold. 
Support using a subset of Set A beams for performance monitoring. Regarding how to use the subset, at least further consider Alt 3 (e.g., use Top K’ predicted beams among the subset) and Alt 2 (e.g., with predefined mapping between the full resources for Set A to the subset of set A) for calculation of the performance metric.
In the performance monitoring framework, consider monitoring on multiple models associated with one AI/ML functionality.
Support Option 3 for the processing of a CSI report for inference.
Consider to configure a shared Set B for multiple Set A. 
When triggering two CSI reports configured with shared Set B and different Set A, enhancement on CPU occupancy can be considered (e.g., shared counting across multiple reports).

Define priority rules between AI/ML-based report and non-AI/ML-based report, and among multiple types of AI/ML-based reports, considering:
Different use cases (or sub use cases) such as BM Case-1, BM Case-2, or CSI compression.
Different LCM purposes (e.g., reporting inference results, reporting performance monitoring results, and so on) of an AI/ML model.
Different report quantity types (e.g., predicted CRI/SSBRI, predicted RSRP, beam prediction accuracy, one-shot performance indicator, and so on).
Enhance CPU and CPU occupancy considering a long observation window for performance monitoring and inference.
To enable P2 sweep based on predicted Top-K beams, consider another option for integrating Option 1 and Option 4:
The gNB configures a legacy aPeriodicTriggerState associated with a P2 resource set comprising K1 TCI states or beams, where K1>K. K TCI states or beams must follow UE predicted Top-K beams
The remaining K1-K TCI states or beams follow the aPeriodicTriggerState
Overlapped TCI states or beams are excluded from the sweep
Consider an approach where gNB indicates spatially correlated Tx beams from Set B for each Tx beam of Set A:
UE may synthesize QCL properties of an unmeasured beam from the QCL properties of its spatially correlated measured beams.
FFS how to indicate the spatially correlated measured beams of an unmeasured beam.
Support to extend unified TCI framework to allow single beam indication with a respective beam for each of N future time instance. 

3GPP TSG RAN WG1 #121		R1-2503757
Malta, May 19th – May 23rd, 2024

Agenda Item:	9.1.1
Source:	Indian Institute of Technology Madras (IITM), IIT Kanpur
Title:	Discussion on Specification Support of AI/ML for Beam Management
Document for:	Discussion

Conclusion
Observation 1: For Performance monitoring of AI/ML based beam management, the monitoring metric is defined for a single instance of monitoring, i.e., one monitoring resource set.
Observation 2: For UE-assisted performance monitoring of a UE-sided AI/ML model, the Top 1/K beam prediction accuracy is defined as the percentage of actual Top M beams (based on the L1-RSRP measurements) being predicted as the Top 1/K beams.
Proposal 1: At least for the monitoring Type 1 Option 2 of UE-side model monitoring, if M is configured to be 1, the value of K for top predicted beams should be less than or equal to 2. If M is configured to 1,2 the value of K for top predicted beams could be less than or equal to 4. 
Proposal 2: Model management procedures  of AI/ML LCM, such as model update, model switch and fall back of AI/ML model for beam management should consider the performance of the model (Beam Prediction accuracy) for multiple monitoring instances (at least N=5).
Proposal 3: For BM-Case 1 and BM-Case 2, introduce a threshold for minimum time offset between transmission of CSI-RS/SSB resources for monitoring and the CSI reference resource signal transmission for Inference in order to link the CSI resources for monitoring and an inference report.
Proposal 4: We recommend the threshold value for minimum time offset for linking monitoring CSI-RS/SSB resources and inference report to be in the order of a few milli-seconds say 1ms, 2ms, 3ms, 5ms.
Proposal 5: For BM-Case 2, which is beam prediction for future time instances, the beam prediction accuracy should be configured for each future prediction time instance.
Proposal 6: For UE-sided AI/ML model for beam management, for Option 2 (UE-assisted performance monitoring), support the size of the set for monitoring to be integer multiple of  K (Top K predicted beams of the linked inference report). 
Proposal 7: For NW-sided model, for inference, in a beam report initiated by network based on one measurement resource set, the number of reported beams in one report, M, is suggested to be greater than 4.  

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

Source: 	CATT
Title:	Discussion on AI/ML-based beam management
Agenda Item:	9.1.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss the specification support for AI/ML-based beam management. The proposals are summarized as follows.
Proposal 1: For performance monitoring of BM-Case 1 and BM-Case 2 with a UE-sided AI/ML model, the report content of the CSI report for monitoring is a quantized value of . 
Proposal 2: For the case that the resource set(s) for monitoring is configured for a resource set different from Set A, support configuring the spatial domain mapping between the full resources for Set A and the monitoring resources via RRC：
Each resource in the set for monitoring is configured to be mapped with at least one resource in Set A.
Proposal 3: For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring
wherein N (N>=1) is configured in CSI-ReportConfig
the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring
Wherein, the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report. The value of X is configured by RRC
one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.
Proposal 4: For BM-Case 2, support to report F beam prediction accuracy for F configured time instance, configured by one CSI-ReportConfig for monitoring,
F resource sets are configured in the CSI-ReportConfig
the configured time instance(s) (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
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
N (N>=1) is configured in the CSI-ReportConfig
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, are no later than the CSI reference resource corresponding to the CSI report for monitoring
Wherein, the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report. The value of X is configured by RRC.
Proposal 5：For UE-sided mode, at least for BM-Case 1, for content in the report of inference results, for Opt 1(only beam information of predicted Top K beam(s)), the ranking information of the predicted Top K beams for K>1 can be conveyed by the order of the beam information based on the predicted probability information or the predicted L1-RSRP.
Proposal 6: For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, 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
And 
Option 2: only legacy CPU is occupied,  it is reported by UE
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE
And 1.
Proposal 7: For UE-side model, for inference report of BM-Case 1, legacy CPU occupation duration for P/SP/AP beam report can be reused, and the occupation duration is only related to the resources of Set B.
Proposal 8: For UE-side model, for inference report of BM-Case 2, the occupation duration is determined as:
For the last transmission occasion
from the 1st symbol of latest occasions of Set B resource no later than CSI reference resource, until the last symbol of the PUSCH/PUCCH carrying the report
For the -th till second latest consecutive P/SP CSI-RS occasions no later than CSI reference resource
from the first symbol of each transmission occasion of Set B resource, until symbols after the last symbol of the latest one of the CSI-RS/SSB resource for channel measurement for L1-RSRP computation in each transmission occasion.
where the value of  for BM-Case 2 is indicated by a new UE capability.
Proposal 9: For UE-side model, for a CSI-ReportConfig for data collection, .
Proposal 10: Determine the priority of CSI report for different functionalities, as well as for data collection, model inference, and performance monitoring.
At least define the priority according to the report quantity.
Proposal 11: For configuring the associated ID within CSI framework, support to configure associated ID at CSI-ResourceConfig level. 
Proposal 12：For UE-sided model, for data collection for training, an indication can be configured in the CSI report with report quantity set to “none”.
Proposal 13: The RRC parameters of Option B can involve the following parameters:
Set A related information:
Associated ID for Set A(associatedIDforSetA-r19) and/or size of Set A(new RRC parameter)
Note: At least associated ID or size of Set A is needed.
Set B related information:
Associated ID for Set B (associatedIDforSetB-r19) and/or size of Set B(new RRC parameter)
periodicity of RS Set B(new RRC parameter)for BM-Case 2)    
Output related: 
time gap(s) for prediction (TimeGap-r19 for BM-Case 2)
represent the number of predicted time instances (nroftimeinstance-r19 for BM-Case 2)
report type (reportQuantity-r19)
Proposal 14: For NW-sided model, for inference report, the maximum value of M can be 6, 8, 16.
Proposal 15: For NW-sided model, the following options can be considered for the reported beam information: 
Opt 1: Legacy CRI/SSBRI of a resource set, and resource set id if multiple resource sets consists set B
Opt 2：The indicator for largest measured value of L1-RSRP and a bitmap indicating RS index within a resource set, and resource set id if multiple resource sets consists set B.
Proposal 16: For NW-sided model for BM-Case 2, for inference, support to report largest L1-RSRP from N time instances and other differential L1-RSRP of N time instances within the measurement window in a pre-defined order in a beam report. 
Proposal 17： For content for data collection for training for NW-sided model via higher layer signaling, for both BM-Case 1 and BM-Case 2, for each per instance, support the following options:
Opt 1: L1-RSRPs measured based on resource set(s) (for Set A and Set B) configured to UE
Opt 2: L1-RSRPs measured based on resource set (s) (for Set B) configured to UE, and beam information of Top K measured based on resource set(s) (for Set A) configured to UE
Differential L1-RSRP reporting is supported with legacy quantization steps and ranges.
Proposal 18: For performance monitoring of NW-sided model, the content in a beam report includes the beam information of Top M beam(s) with largest M measured L1-RSRP(s).
Proposal 19：For Top-K beam measurements (P2 procedure) of NW-sided and UE-sided model, the following options can be considered:
Option 1: NW can dynamically indicate the active resources for measurement among the pre-configured RS resources associated with the CSI report via MAC-CE signaling
Option 2: NW can dynamically indicate the QCL relationship for the pre-configured RS resources associated with the CSI report via MAC-CE signaling.

3GPP TSG RAN WG1 #121																	  R1-2503820
Malta, MT, May 19th–May 23th, 2025
Source: 	CMCC
Title:	Discussion on specification support for beam management
Agenda item:	9.1.1
Document for:	Discussion & Decision

Conclusion
In this contribution, we focus on the discussion on the the procedure and the potential specification impact of AI based beam management during different LCM operation. The observations and proposals are listed below.

Observation 1: With the UE capability reporting, gNB can provide a proper inference configuration for UE to work even without the configuration of associated id. The inference performance of the model can be monitored based on the model monitoring procedure.

Observation 2: According to the definition from RAN2, whether the functionalities are applicable or not is not related to the associated id.

Proposal 1: From RAN 1 perspective, for content for data collection for training for NW-sided model via higher layer signaling, for BM-Case1, type 1 and type 3 for each instance can be supported: 
Type 1: All L1-RSRPs of measured based the resources (for Set A/B) configured to UE
Type 3: All L1-RSRPs measured based on resources (for Set B) configured to UE, and beam information and L1-RSRPs of K beams based on some resources (for Set A) configured to UE

Proposal 2: Regarding data collection for NW-side model, following option is supported for the configuration of Set A:
Option 2: The configuration of set A can contain multiple resource sets in one CSI-ResourceConfig

Proposal 3: Top K beam sweeping procedure can be supported to obtain Top 1 beam. 

Proposal 4: The indication of Top K beam (resource) set with low signaling overhead can be considered.

Proposal 5: For Top-K beam sweeping, NW indicates the beam IDs or TCI states that are part of the Top-K beams by MAC CE.

Proposal 6: For NW-sided model inference reporting, at least for BM-Case 1, when the value of M (Top-M beams) is smaller than the size of measurement resource set, CRI/SSBRI is supported as reporting quantity. 

Proposal 7: For NW-sided model inference reporting, at least for BM-Case 1, L1-RSRPs and corresponding beam information of beams within X dB gap to the largest measured value of L1-RSRP can be supported.
The X dB gap can be configured by gNB
UL resource allocation for variable number of reported beams can be further discussed.

Proposal 8: The RS associated with TCI state indication should be measured at least once before TCI state indication or application. 

Proposal 9: It should be clarified in CR that the report quantity of UE side inference corresponds to predicted “Top” K beams.

Proposal 10: For inference results reporting of UE side model, predicted Top K beams are the K beams with largest predicted RSRP values or the K beams with the largest probability to be the Top-1 beam in Set A. 

Proposal 11: Regarding Type 1 performance monitoring Option 1 of UE-side AI/ML model, new reporting quantity such as L1-RSRP and/or RS ID of Top M beams with largest measured RSRP is needed.

Proposal 12: Regarding Type 1 performance monitoring Option 2 of UE-side AI/ML model, Option 2 with new quantity of beam prediction accuracy is preferred. 
Option 2: 
Where N (N≥1) prediction instance results of inference linked with performance monitoring instance are used for the calculation of accuracy
 is the number of the prediction instance results out of 

Proposal 13: Pre-defined quantification range of beam prediction accuracy needs further discussion.

Proposal 14: Regarding Type 1 performance monitoring Option 2 of UE-side AI/ML model, Alt3 can be supported with following modification.
Alt 3: The RSRP difference information between the predicted RSRP and measured L1-RSRP of corresponding beam(s) of a resource set/resources for monitoring Top K predicted beams within monitoring resource set 
Note: resources for Set B for monitoring are not precluded. 

Proposal 15: When the size of a set for monitoring is smaller than the size of Set A, beams in monitoring set can be uniformly down-sampling of set A beams. 

Proposal 16: When the size of a set for monitoring is smaller than the size of Set A, a RS in Set A can be linked with a RS in monitor set through QCL relationship.

Proposal 17: Confirm the WA about linkage between inference result and monitoring occasion with following modification:
Working Assumption
At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, 
for BM-Case 1, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X for the minimal slot offset can be optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.

Proposal 18: Confirm the WA about linkage between inference result and monitoring occasion with following modification:
Working Assumption
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one or multiple configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring. 
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance

Proposal 19: For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
Wherein N is determined by gNB configuration
For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.

Proposal 20: Type 2 monitoring of UE-side AI/ML model, indication/requesting from UE but with gNB’s decision can be supported. 

Proposal 21: Regarding Type 2 monitoring of UE-side AI/ML model, NW can configure a threshold criterion to facilitate UE to make decisions of the model selection / activation/ deactivation / switching/ fallback.

Proposal 22: For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, option 1 is supported: 
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE. 
And 

Proposal 23: There is no need to define the content of the similar properties behind the associated id. 

Proposal 24: The associated ID can be optionally configured for data collection and inference.

Proposal 25: When the associated ID is configured for data collection/inference, the determination of applicable functionality can be based on the configuration or the related information but without associated id. Namely, the associated id will not be used for the determination of the applicable functionality.

Proposal 26: When the associated ID is configured for data collection but not configured for inference (Case 1-1), the UE can report it is either applicable or not applicable.

Proposal 27: When the associated ID is configured for data collection but not configured for inference (Case 1-1), the UE can report it is applicable and have the same assumption of gNB’s additional conditions as that for data collections.

Proposal 28: When the associated ID is not configured for data collection and not configured for inference (Case 2-1), the UE can report it is either applicable or not applicable.

Proposal 29: When the associated ID is not configured for data collection and not configured for inference (Case 2-1), the UE can report it is applicable and have the same assumption of gNB’s additional conditions as that for data collections.

Proposal 30: For applicable functionality reporting option B, the content of inference related parameters can include:
Set A related information:
Associated ID for Set A(associatedIDforSetA-r19), optional 
size of Set A
RS type of Set A
Set B related information:
when Set B is equal or a subset of set A,  
parameter to indicate the pattern of Set B 
Note. The associated ID (associatedIDforSetA-r19), if configured, is applicable for both Set A and Set B  
Otherwise
associated ID for Set B (associatedIDforSetB-r19), optional 
size of Set B
RS type of Set B
periodicity of Set B for BM-Case 2  
Output related:
time gap(s) for prediction (TimeGap-r19 for BM-Case 2)
the number of predicted time instances (nroftimeinstance-r19 for BM-Case 2)
report type (reportQuantity-r19)

The TP suggestion for TS 38.214 section 5.2.1.4.1 is as the following:


The TP suggestion for TS 38.214 section 5.2.1.4.2 is as the following:


The TP suggestion for TS 38.214 section 5.2.1.4.2 is as the following:

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

Agenda Item:	9.1.1
Source:	Xiaomi 
Title:                     Discussion on AI/ML for beam management 
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss about specification impacts of AI/ML for beam management. Based on above discusses, we provide the following proposals.
Consistency 
Proposal 2-1: Support cell group specific associated ID.

Inference results report for UE-sided model
Proposal 3-1: UE to report whether the best Rx beam is known or not for the reported Tx beam to gNB. And for the beam without information of the best Rx beam, legacy procedure for Rx beam sweeping can be used to find the best Rx beam first and no new spec impact.  
Proposal 3-2: Support to configure legacy semi-persistent/aperiodic CSI report and AI based semi-persistent/aperiodic CSI report in different report list or trigger state list.
Proposal 3-3: The predicted Top K beam(s) are the best K beam(s) based on the predicted RSRP values, or the probability of each beam in Set A to be the Top-1 beam. 
Proposal 3-4: For UE-sided model, at least for BM-Case1, for content in the report of inference results, for Opt 1 (only beam information of predicted Top K beam(s)), the ranking information of the predicted Top K beams for K > 1 is conveyed by the order of the beam information.

Measurement report for NW-sided model
Proposal 4-1: For NW-sided model, for inference report, at least for BM-Case 1,
when M4, a bitmap and a resource indicator can be configured to be reported by RRC, 
The bitmap consists of K bits, where K is the size of the measurement resource set,
The resource indicator indicates the resource with the largest measured value of L1-RSRP from the M reported resources in the resource set, 
The size of the CSI field for the resource indicator is .
Proposal 4-2: For NW-sided model inference in BM-Case 2, support to report the measurement results of each time instance separately.
Proposal 4-3: Both two separate CSI-ReportConfigs and one CSI-ReportConfig can be supported for set B and set A configuration for data collection for NW-side AI/ML model training.
Proposal 4-4: If one CSI-ReportConfig is used for set B and set A configuration for data collection for NW-side AI/ML model training, consider to support more than one reportquantity in one CSI-ReportConfig.

Signaling/mechanism for AI/ML model performance monitoring
Proposal 5-1: Both of the following two Benchmark/reference for performance comparison should be supported.
Alt.1: The best beam(s) obtained by measuring beams of a set indicated by gNB (e.g., Beams from Set A)
Alt.4: Measurements of the predicted best beam(s) corresponding to model output (e.g., Comparison between actual L1-RSRP and predicted RSRP of predicted Top-1/K Beams)
Proposal 5-2: Confirm the following working assumption:
Working Assumption
At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, 
for BM-Case 1, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X for the minimal slot offset, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.
Proposal 5-3: Not introduce the threshold X for the minimal slot offset.
Proposal 5-4: Confirm the following working assumption:
Working Assumption
For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
wherein N (N>=1) is configured in CSI-ReportConfig
FFS on additional rule for counting N linked pair
For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.
Proposal 5-5: Not introduce additional rule for counting N linked pair.
Proposal 5-6: Confirm the following working assumption:
Working Assumption
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring. 
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance
Proposal 5-7: Support to configure more than one time instance in the CSI-ReportConfig for performance monitoring and the performance metric for each time instance is calculated independently.
Proposal 5-8: For Option 2 performance monitoring (UE-assisted performance monitoring), support to report the number of accurate inference report with the number of monitoring transmission occasion N no larger than 16.
Proposal 5-9: For Option 2 performance monitoring (UE-assisted performance monitoring), one resource in monitoring set can map to one or more resources in set A if the size of monitoring set is smaller than the size of Set A.
Proposal 5-10: In addition to beam prediction accuracy, Support the L1-RSRP difference information between the measured RSRP and predicted RSRP as performance metric for performance monitoring.
Proposal 5-11: For Type 1 performance monitoring of UE-side AI/ML model, both NW-side initiated and UE-side initiated performance monitoring can be supported. NW-side initiated can be based on measurement/report configuration via RRC and UE-side initiated can be based on SR and UL MAC CE with the preferred resource configuration of set B and set A.
Proposal 5-12: For UE-side AI/ML model, support Type 2 performance monitoring and it can be initiated by UE.
Proposal 5-13: For UE-side AI/ML model with Type 2 performance monitoring, it is better to indicate UE’s decision to NW for consistency of the NW-side additional condition for the new applied UE-side model.
Proposal 5-14: For UE-side AI/ML model with Type 2 performance monitoring, configure an event with a threshold to assist UE to make the decision.
Proposal 5-15: For performance monitoring of network-side AI/ML model, support to report measurement results of set B and set A separately. Set B can be reported based on beam report, and set A can be reported by MAC CE or RRC with multiple samples. 
Proposal 5-16: For performance monitoring for network-side AI/ML model, support an event-triggered report if the indicated TCI state is different from the best beams obtained by measurements. 
Proposal 5-17: Confirm the necessity of assessment/monitoring of inactive models / functionalities, with the following assumptions as the starting point:
One way to monitor inactive models/functionalities is by activating them and reusing mechanisms defined for monitoring of active models/functionalities.
The following aspects may be considered for further study or in WI to assess the applicability and expected performance of an inactive model/functionality:
Configuring an AI/ML model for monitoring without activation (e.g., monitoring-only mode without reporting predicted beams in BM Case 1 and 2)
Dataset delivery from the network to the UE for assessment/monitoring of the applicability and expected performance of the model/functionality.
NW may provide performance criteria/preference for UE’s model selection.
Other aspects are not precluded for further study or specification.

Beam indication
Proposal 6-1: For TCI state indication of more than one predicted time instance, support to reuse legacy TCI state indication with multiple MAC CE or DCI and each MAC CE or DCI indicates TCI state of one time instance.

CPU and timeline
Proposal 7-1: For processing a CSI report for inference, support Option 1: only dedicated AI/ML PU is occupied,  is reported by UE.
Proposal 7-2: Reuse the definition of CPU occupation time of legacy CSI report for both BM Case 1 and BM Case 2 (as Rel-18 CSI prediction).
Proposal 7-3: the number of occupied PU for each CSI report for inference can be reported by UE capability per FG or reported by UE assistance information together with corresponding applicable functionality.
Proposal 7-4: For the determination of CSI report priority value of an inference report, the existing  is reused with the following exception:
k = 0 when the report content of inference results is Option 1 (beam information on predicted Top K beam(s) among a set of beams)
Proposal 7-5: For the determination of CSI report priority value of a performance monitoring report including performance metric, new value 2 for k can be introduced for BM.

RRC parameters for Option B
Proposal 8-1: Support the following RRC parameters for Option B.
Set A related information: 
Associated ID for Set A and size of Set A 
Set B related information: 
Size if set B
Separate Associated ID for set B if used.
Output related: 
time gap(s) for prediction 
The number of predicted time instances
ReportQuantity-r19: with or without predicted L1-RSRP.

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

Agenda item:	9.1.1
Source:	NEC
Title: 	Discussion on specification support for beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we provided our views on Rel-19 AI/ML for air-interface work on beam management enhancement use case, and we have the following observations and proposals:
Observation 1:	P/SP NZP-CSI-RS resources for Set A are configured and active for model inference, it might impact the overall system throughput, since in the legacy PDSCH rate matching, UE assumes that the corresponding resource elements (REs) for P/SP NZP-CSI-RS are not used for PDSCH.
Observation 2:	Based on both M (the number of configured measurement resources) and K (the number of reported beams), it can be determined whether CRI/SSBRI corresponds to less reporting overhead or bitmap corresponds to less reporting overhead.
Observation 3:	The model performance degradation may be caused by a few partial inaccurate predicted beams (in Set A), which may be blocked due to unexpected or unpredictable obstacle in reality. However, for the majority of other beams (in Set A), the corresponding predicted results can still be considered accurate.
Observation 4:	Performance monitoring based on Alt 3 is an effective solution for identifying the partial inaccurate predicted beams (in Set A).
Observation 5:	Legacy TCI framework needs to be enhanced to indicate the predicted beam(s) since there may be no actually measured QCL reference signals.
Observation 6:	Either spatial-domain beam prediction or time-domain beam prediction can improve BFD and BFR.

Proposal 1:	For data collection for NW-sided model, also support L1 report leveraging the existing CSI report framework.
Proposal 2:	The configured P/SP NZP-CSI-RS resources for Set A should be available for other channel/signal (e.g., PDSCH) at least during model inference.
Proposal 3:	The resourceType configurations of the two resource settings for Set B and Set A should be the same in model inference configuration.
Proposal 4:	The predicted Top K beam(s) reported by UE should be based on the predicted RSRP values, or the probability of each beam in Set A to be the Top-1/K beam.
Proposal 5:	Support UE to report the probability related information of the predicted beam(s) among a set of beams, wherein the probability can be quantized and reported based on some pre-defined ranges or intervals.
Proposal 6:	For BM-Case 2, support to configure K (i.e., the number of predicted beams to report) per prediction time instance.
Proposal 7:	For predicted RSRP, the Tx power is assumed based on the configured powerControlOffsetSS of the resource corresponding to the predicted beam if Set A resources are configured and the Tx power is assumed based on setting powerControlOffsetSS to 0 if Set A resources are not configured.
Proposal 8:	For BM-Case 2 of UE-side model, if DRX is configured, the inference report only includes predicted results for a subset of future time instances in the nearest DRX ON duration or in the nearest DRX cycle.
Proposal 9:	For BM-Case2, at least for P/SP beam report, to avoid unnecessary signaling overhead, in addition to prediction window, observation window should also be configured.
Proposal 10:	For inference report for NW-sided model, support both CRI/SSBRI and bitmap as beam information. And the selection between CRI/SSBRI and bitmap can be based on the following options:
−	Option 1: Comparison between reporting overheads corresponding to CRI/SSBRI and bitmap calculated based on M and K.
−	Option 2: Mapping relationship between beam information (i.e., CRI/SSBRI, bitmap), M and K.
Proposal 11:	For inference report for NW-sided model, support L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP, where X and M are configured by gNB.
−	Minimum number of reported beams needs to be configured to ensure normal model inference.
−	The number of reported beams can be reported in two part.
Proposal 12:	Support variable Set B for model inference. Specifically, for a variable Set B selected from a set of pre-configured Set B patterns, multiple Set Bs should be configured; for a variable Set B that is a subset of measured beams Set C, criterions/thresholds for determining the Set B should be defined.
Proposal 13:	Clarify that multiple reportConfigIDs of model inference reports can be associated with a single reportConfigID of performance monitoring.
Proposal 14:	If inference report associated with monitoring report is stopped during monitoring, the following monitoring behaviors needs to be considered for the monitoring report:
−	The monitoring report is stopped.
−	UE calculate (and report) performance metric based on the monitoring instances already collected.
Proposal 15:	For BM-Case2, support to report performance metric of the first time instance by default if f-th time instance is not configured. And support to report per each of F future time instances.
Proposal 16:	The same Rx beam(s) for Top K predicted beams and Top M measured beams need to be assured.
Proposal 17:	At least for regression-based model (or the model can predict RSRP), support Alt 3: The RSRP difference information between the predicted RSRP and measured L1-RSRP of corresponding beam(s) of a resource set/resources for monitoring.
Proposal 18:	For Alt 1 and Alt 3, the performance metric can be calculated either per sample or per set of samples (or monitoring window).
Proposal 19:	To support performance monitoring based on a set of samples, NW may need to inform UE of the specific samples included in the metric calculation.
Proposal 20:	Study to address the issue about the performance metric calculated based on all samples within the monitoring window may not be sufficient to reflect the (future) performance of the model.
Proposal 21:	The performance metric for a set of samples ( monitoring instances) can be , where  is the prediction accuracy at the  sample ( monitoring instance);  is the total number of monitoring instances. And  can be can be the number of beams of the Top K predicted beams are among the Top M measured beams/ Top M measured beams are among the Top K predicted beams.
Proposal 22:	Calculation and reporting of the performance metric should be based on valid monitoring instance which can be defined based on certain criterions, or based on NW’s indication.
Proposal 23:	Study the calculation of performance metric when a subset of Set A is configured as monitoring RS, if different performance matrices will be supported for full Set A as monitoring RS and a subset of Set A as monitoring RS.
Proposal 24:	UE can measure a subset of monitoring resource set which consists resources configured with the same qcl-info (or TCI states, or associated SSB) as the predicted Top K beams/Set A beams.
Proposal 25:	For performance monitoring of UE-side model, support to assess performances for multiple Set Bs to balance beam measurement overhead and performance.
Proposal 26:	Study simultaneous performance monitoring for multiple candidate models, including how to inform the NW the inactive candidate models and how to request resources and configurations for performance monitoring of the inactive candidate models.
Proposal 27:	AI/ML based CSI reporting occupies one set of CPUs and the other set of APUs. And UE only updates an AI/ML CSI report if both conditions on CPU and APU are satisfied.
Proposal 28:	Support to specify the following CSI priority for AI/ML based CSI report:
−	Non-AI/ML based CSI report should be priority over AI/ML based CSI report.
−	Define new k or priority rule for AI/ML based CSI reports configured for different LCMs (e.g., inference, monitoring).
Proposal 29:	Support to configure Set A RS as the QCL reference signal in the TCI state.
Proposal 30:	For BM-Case 2, support to use one MAC CE or DCI to activate/indicate multiple (future) TCI states, and corresponding time period.
Proposal 31:	To enable dynamic further measurement and reporting among (predicted) Top-K beams, the NW can active beam IDs or TCI states from a dedicated TCI state pool, which is specifically used for beam prediction.
Proposal 32:	For enabling a P2 sweep based on predicted Top-K beams, NW can configure all Set A as measurement resources, and UE is expected to measure only predicted top-K beams after each inference result.
Proposal 33:	At least for BM-Case 2, support beam failure detection based on time-domain prediction.
Proposal 34:	Support new beam identification based on at least BM-Case1.

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

Source:	   RUijie networks
Title:	   Discussion on specification support for beam management
Agenda Item: 	   9.1.1
Document for: 	Discussion and decision 

Conclusions
In this contribution, we have presented our views on specification support for beam management. Based on the discussions in the previous sections we propose the following: 
Proposal 1: Confirm the following Working Assumption for BM-Case 1
Proposal 2: Confirm the following Working Assumption for BM-Case 2
Proposal 3: Propose to introduce a threshold X for the minimal slot offset for BM-Case 1 and BM-Case 2.
Proposal 4: Confirm the following Working Assumption
Proposal 5: Define the following report quantity for metric
Introduce a new quantity (i.e., beam accuracy indicator, BAI) for beam prediction accuracy in the CSI report for monitoring, where BAI is (0 ≤≤ N) and the corresponding beam prediction accuracy is, 0≤≤ 1). 
the size of CSI field associated with the BAI is , 
Where  is the number of linked transmission occasion for monitoring that meet the metric among N linked pair(s). 
Proposal 6: For UE-sided AI/ML model for beam management, for Option 2 (UE-assisted performance monitoring), the performance metric of Top 1 or Top K beam prediction accuracy is defined as:
Support the size of the set for monitoring is smaller than the size of Set A,
The mapping of the resource in the set for monitoring to one or more resource in Set A is configured via RRC, and support Option 1
Option 1: Reuse TCI-StateId
Proposal 7: For UE-sided model, at least for BM-Case 1, in CSI-ReportConfig for aperiodic inference report, 
when set B is a subset of Set A, one associated ID for Set B is applied for all the set B configured in ResourceConfig
when set B is NOT a subset of set A, 
Support: the ResourceConfig for set B only include a single ResourceSet.
Proposal 8: For UE-sided model, at least for BM-Case1, for content in the report of inference results, do not support Opt 3
Opt 3: Beam information on predicted Top K beam(s) among a set of beams, and the probability related information of predicted Top K beam(s) among a set of beams
Where the probability information is the probability of the beam to be the Top 1 beam, 
Note： SUM of all probabilities of Set A is expected to be 1
Beam information refers to CRIs corresponding to Set A
K is configured in inference report configuration to the UE. And Candidate values of K= 1, 2, 4
[2 bits] are used for reporting the probability information
Proposal 9: For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, support Option 1 and Option 3 for potential down selection:
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE.
And 
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
And  
Note: The supported option 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. 
Proposal 10: For BM-Case 1, legacy CPU occupation duration for P/SP/AP CSI report is reused in principle. For BM-Case 2, support Alt 2
Alt 2: use the following occupation duration in principle, 
from the 1st symbol of -th latest consecutive P/SP CSI-RS occasions no later than CSI reference resource, until the last symbol of the PUSCH carrying the report, As Rel-18 CSI prediction
where the value of  is indicated by a new UE capability.
where is based on a new UE capability

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

Agenda Item:	9.1.1
Source:	InterDigital, Inc.
Title:	Discussion on AI/ML for beam management
Document for:	Discussion and Decision

Summary
In this contribution, we discuss potential issues and associated standard impacts to support AI/ML for beam management. From the discussions, we made the following observations and proposals: 
Observation 1: When PDCCH/PDSCH are to be transmitted via a predicted best beam which is not measured, the UE cannot acquire QCL-related parameters, therefore a procedure to obtain QCL-related parameters for the unmeasured beam is needed. 
Observation 2: Estimation of QCL-related parameters via neighbouring beams achieves Doppler shift estimation with error below 10 Hz for 90% of the time and RMS delay spread below 15 ns for 90% of the time.
Observation 3: Enhanced beam indication mechanism is needed to enable future beam indication based on prediction of AI/ML model in BM-Case 2. 

Proposal 1: For configuration of each set of inference related parameters for applicability report, support introduction of the following new RRC parameters as a baseline:
Number of beams in Set A and Set B.
TCI states indicating QCL relations between Set A and Set B and beam pattern of Set B.
Number of future time instances to predict for BM-Case2
Proposal 2: For applicability of aperiodic CSI, support activation of aperiodic CSI RS resource sets based on an active TCI state.
Proposal 3: For the configuration of Set A and Set B, no configuration method is supported other than configuration of two CSI-ResourceConfig Ids for Set A and Set B separately.
Proposal 4: Support Set A for both no transmission and transmission with longer periodicity
Proposal 5: Support CSI-RS resource with/without physical RS transmission related parameters (e.g., resourceMapping, scramblingID, periodicityAndOffset and etc.).
Proposal 6: Support configuration of RS resources for measurement to estimate QCL-parameters of a RS resource without transmission in Set A.  
Proposal 7: Support a beam indication mechanism with a beam pattern and corresponding TCI states required for the indicated beam pattern.
Proposal 8: For processing of CSI report for inference, support Option 3: “both dedicated AI/ML PU and legacy CPU are occupied, OAPU = N2 is reported by UE. And OCPU = 1.”  
Proposal 9: For processing of CSI-report for inference for BM-Case1, support the legacy occupation timings of CRI/SSBRI reporting for both legacy CPU and AI/ML PU.
Proposal 10: For processing of CSI-report for inference for BM-Case2, support different occupation timings for legacy CPU and AI/ML PU.
For legacy CPU, support occupation duration TCPU from the following starting points: 
CSI-RS measurement for periodic CSI and semi-persistent CSI with PUCCH.
Triggering/activation DCI for aperiodic CSI and semi-persistent CSI with PUSCH.
For AI/ML PU, support TAI/ML PU occupation duration until the corresponding reporting instance.
Proposal 11: Support a priority based mechanism to handle duplicated activated periodic CSI report configs.
Proposal 12: Support “predicted Top K beam(s) are the K beam(s) with largest predicted RSRP values” when predicted RSRP values are available.
Proposal 13: Support indication of the ranking information of the predicted Top K beams for K > 1 by the order of the beam information.
No additional information (e.g., probability information) other than predicted RSRP values is supported.
Proposal 14: For network side model, support dynamic selection of reporting procedure (i.e., either Option 1 or Option 2) based on the number of measurements, M, or payload size associated with each procedure.
Option 1: CRI/SSBRI of a measurement resource.
Option 2: a bit map to indicate the reported beams of a measurement resource set and one beam index (i.e., CRI/SSBRI) for the largest measured value of L1-RSRP of a measurement resource set.
Proposal 15: For UE assisted performance monitoring, support Option 1: “Reuse TCIStateID” to configure mapping of a monitoring resource to a resource in Set A.
Proposal 16: For UE-assisted performance monitoring, Support TCI state based activation of RS resource sets for performance monitoring.
Proposal 17: For UE-assisted performance monitoring, do not support the introduction of a new threshold parameter for minimal slot offset for either BM-Case1 or BM-Case2.
Proposal 18: For UE-assisted performance monitoring, for the case when Top-K beams are included in the monitoring resource set, down select from one of the following performance metrics:
Option 2 (1/Top-K): The Top-1 beam with largest measured value of L1-RSRP of the resource set(s) for monitoring is one of the Top-K predicted beams
Option 3 (Top-K/M): The Top-K predicted beams are among Top M beam(s) with largest M measured value(s) of L1-RSRP(s) of the resource set(s) for monitoring.
Option 4 (best of Top-K/1 with margin): The beam with largest measured value of L1-RSRP of Top-K predicted beams is within a margin X dB of largest measured value of L1-RSRP of the resource set(s) for monitoring

Proposal 19: For UE-assisted performance monitoring, for the case when Top-K beams are not included in the monitoring resource set, support a performance metric based on difference between measured RSRPs and predicted RSRPs.
Proposal 20: For UE-assisted performance monitoring support per instance calculation of performance metric for BM-Case 2.
Proposal 21: For UE-assisted performance monitoring, support the following options for activation of performance monitoring at UE:
Based on the reception of RSs associated to Set A beams.
Based on a periodic timer which starts/stops performance monitoring procedure based on gNB signaling or model performance.  

3GPP TSG RAN WG1 #121	   	 	  	                	      R1-2503981
St Julian’s, Malta, May 19th – 23th, 2025
Agenda item:	9.1.1
Source:	LG Electronics
Title:	Discussions on AI/ML for beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed enhancements on AI/ML for beam management, and provided the following proposals.

Observation #1: In case of ‘beam indication of beams in Set A not in Set B’, it is practically not possible for UE to measure and maintain its Rx beam for all the Set A beams. So, for beam indication, TCI/QCL RS should be based on Set B beams of which UE can measure and maintain its Rx beam.
Observation #2: For Option 1 (NW-side performance monitoring) of Type 1 performance monitoring, there may be no specification impact, e.g., NW can exploit report of more than 4 beam related information in L1 signaling for performance monitoring purpose.
Observation #3: Once a UE starts the CSI measurement/report for inference, the UE has to buffer the inference results until NW activates/triggers associated CSI measurement/report for monitoring.
Observation #4: The definition of ‘similar properties of a DL Tx beam or beam set/list’ should be clearly defined, otherwise different NW vendors may have different understanding on the definition which may affect performance of UE-sided AI/ML model inference due to inconsistency between training and inference.
Observation #5: In the current specification, there is clear description of UE assumption that the same downlink spatial domain transmission filter is maintained by NW for different CSI-RS resources.
Proposal #1: For NW-sided AI/ML in temporal DL Tx beam prediction, support the following UE reporting enhancements for data collection:
Past/present best N beam(s) per time stamp
Tendency/variance of best N beam(s)
Proposal #2: Support reporting of UE assistance information for determining Set A, e.g., UE to report preferred Set A among candidate beams of Set A.
Proposal #3: Consider extending sub-configuration based Rel-18 NES mechanism for Set B beam measurement and reporting.
Different Set A and/or Set B may be associated with each sub-configuration
Different Set B patterns for a specific Set B may be associated with each sub-configuration
Proposal #4: Introduce new reportConfigType-r19 with “none” in the CSI-ReportConfig for data collection to prevent CSI report.
Proposal #5. Regarding the report of more than 4 beam related information in L1 signaling for NW-sided model, support CRI/SSBRI for beam information as legacy, e.g., CRI/SSBRI(s) of Top M beam(s) and the corresponding M L1-RSRP(s) are reported.
Proposal #6: In order to indicate one beam in Set A not in Set B, support indicating multiple neighboring beams from Set B for helping UE to find its Rx beam for the Set A beam.
Proposal #7: For UE-sided model, support to configure only resource set for Set B for CSI-ResourceConfig which is used for the configuration of inference results reporting (i.e., Alt 1), considering huge resource overhead reduction obtained from not configuring Set A.
Proposal #8: In order to support only resource set for Set B for CSI-ResourceConfig (Alt 1) for Set A and Set B configuration, assistance information on relation/association between Set A beams and Set B beams should be provided to UE for the UE-side AI/ML model training and inference. To represent beams in Set A and/or Set B while preserving sensitive proprietary information, consider following exemplary methods:
Set A beams are represented by linear combining coefficients of Set B beams
Tx beam directions are represented as ordered numbers on a 2D or 3D coordinate
Proposal #9: For supported Option 1 and Option 2, support K=4 for the max value.
Proposal #10: For predicted RSRP report, confidence/probability information may be helpful for NW to decide whether/how to use the reported RSRP. Further study whether the information is per model/functionality, per report, per time instance, or per report parameter.
Proposal #11: Support Option 1, only APU is occupied for all AI/ML inference operations at UE-side, and separately managed from CPU.
Further study on APU capability, e.g., supported maximum APUs per UE, required APU(s) per functionality/sub-use-case
Proposal #12: Support aperiodic CSI-RS for the type of resource for performance monitoring.
Proposal #13: The mapping between the resources in the resource set for monitoring and resources in Set A can be configured via new RRC parameter, when the size of a resource set for monitoring is smaller than the size of Set A.
Proposal #14: Support to introduce a threshold X between inference instance and monitoring instance, where the X value is based on UE capability report.
Proposal #15: Support event-triggered UE reporting for UE-sided AI/ML performance monitoring.
Further consider UE report via UCI or SR to request change of Set A configuration, fallback to legacy beam report, holding the report for a while, etc.
Proposal #16: Define similar properties of a DL Tx beam set (for Set A and/or Set B) that at least the same downlink spatial domain transmission filters are maintained for each beam in different transmission instances.
Proposal #17: For Option B, at least include the following parameters for inference related parameter set.
Table 1. The detailed parameters for Option B

3GPP TSG-RAN WG1 #121	R1-2503987
St Julian’s, Malta, May 19th – 23rd, 2025
	
Agenda Item:	9.1.1
Source:	Panasonic
Title:	Discussion on specification support for beam management
Document for:	Discussion

Conclusion
In this document, we have discussed some details on AI/ML for beam management. We have the following proposals:
Proposal 1: For content of data collection for NW-sided model training via higher layer signaling, for both BM-Case 1 and BM-Case2, for each per instance, support L1-RSRPs measured based on one resource set (for Set A and Set B) configured to UE
Differential L1-RSRP reporting is supported with legacy quantization steps and range
FFS: Details on reporting configuration
Proposal 2: NW-sided model inference, support to that a measurement window can be configured with the measurement resource set.
Proposal 3: Group-based beam reporting can be enhanced to support to report more than 4 beams in one report for NW-sided model.
Proposal 4: For NW-sided model, support to extend Rel. 17 TCI state activation signaling methods to activate TCI states of K predicted beams for N future time instances in BM-Case 2. The following 2 options can be considered:
Option 1: The TCI states of K predicted beams for N future time instances are included in a combined set of TCI states together with that of legacy BM.
Option 2: The TCI states of K predicted beams for N future time instances are included in a separate set of TCI states, compared to that of legacy BM. 
Proposal 5: For UE-sided model inference, support that a measurement window can be configured with the measurement resource set.
Proposal 6: Support mapping/association of beams within Set A and beams within Set B based on QCL relationship.
Proposal 7: For both NW-side model and UE-side model, support a maximum number of NZP CSI-RS resources per resource set to 256 per CC, subject to UE capability.
Proposal 8: For BM-Case 1 and BM-Case 2, 
Support 3 options for a processing of a CSI report for UE-side model inference as follows:
Option 1: A dedicated AI/ML PU is occupied only
Option 2: Legacy CPU is occupied only
Option 3: Both dedicated AI/ML PU and legacy CPU are occupied
Support UE to report its capability, including supported option(s) and number of occupied PU, to gNB
Proposal 9: Before proceeding a detailed discussion of CSI processing timeline, a relationship between model mapping and 3GPP-specified procedure relation should be concluded.
Proposal 10: 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 11: Support to apply concept of “associated IDs” for multiple cells for ensuring consistency of NW-side additional condition across training and inference for UE-sided model for BM-Case 1 and BM Case 2.
Proposal 12: Support to determine “associated IDs” within a NW operator (or an MNO) to preserve proprietary information.
Proposal 13: For BM-Case1 and BM-Case2 with a UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring), support to define a beam accuracy indicator (BAI) as.
Proposal 14: Support to define that the predicted Top K beam(s) are the best K beam(s) based on the predicted RSRP.
Proposal 15: Group-based beam reporting can be enhanced to support performance monitoring for NW-sided model.

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

Agenda Item:	9.1.1
Source:	NVIDIA
Title:	Specification support for AI-enabled beam management
Document for:	Discussion
1	

Conclusion
For UE-sided model, for BM-Case 2, for inference, AP CSI-RS for Set B is not supported. 
Agreement
For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, considering the following options for potential down selection: 
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE.
And 
Option 2: only legacy CPU is occupied,  it is reported by UE.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
And  
Note: The supported option 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. 

Working Assumption
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring. 
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance

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

Agenda Item:	9.1.1
Source:	Google
Title:	ML based Beam Management
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided discussion on AI/ML based BM. Based on the discussion, the following proposals are provided.
Proposal 1: Support to configure always-on SSB as the CMR for BM-Case 2 to maintain the same interval between two SSB transmission occasions
Do not support to configure on-demand SSB or SSB with time-domain adaptation as the CMR for BM-Case 2

Proposal 2: Support one of the following options to maintain the consistency of the associated ID and TCI configuration for Set A/B RS
Option 1: UE ignores the configured TCI state for the Set A/B RS
Option 2: Introduce the MAC-CE or DCI to update the associated ID

Proposal 3: Support to report a confidence level indicator for L1-RSRP report to indicate the maximum L1-RSRP measurement error for each beam. 
Proposal 4: Reuse the CRI subset configuration in MIMO to indicate a subset of beams that the UE should always report in an L1-RSRP report
Proposal 5: Support L1-RSRP report retransmission to facilitate the NW-side beam prediction for BM case 2
Proposal 6: For beam report based on UE model inference for SD beam prediction, support the followings on the remaining open issues:
The reported RSRP should be defined as the predicted RSRP based on a reference transmission power
Support both option 3 (probability information report) and option 4 (confidence information report)

Proposal 7: An inference report for BM-Case 1 should take 1 APU and 1 legacy CPU
APU is occupied for inference and legacy CPU is occupied for Set B RS measurement
Support the UE to report whether BM-Case 1 and BM-Case 2 can share common APU or not

Proposal 8: Reuse the legacy UCI multiplexing/dropping rule of L1-RSRP report for the predicted CRI/SSBRI/RSRP report
Proposal 9: Support the network to configure the associated Set A RS index(es) for the DL-RS for monitoring
Proposal 10: With regard to dynamic activate/deactivate an inference configuration, support to dynamically activate/deactivate the performance monitoring configuration(s).
Proposal 11: The working assumptions should be modified as follows:

Proposal 12: Reuse the legacy UCI multiplexing/dropping rule of L1-RSRP report for the BAI report
Proposal 13: Support the UE to drop the inference results report if one of the followings happens:
UE has not measured K consecutive transmission occasions for each of the set B beam within the same DRX active time
For BM-Case 1, K=1 
For BM-Case 2, K is reported by the UE capability
The K transmission occasions includes the last transmission occasion before the CSI reference resource
The offset between every two consecutive transmissions is consistent
The measured L1-RSRP for each of the set B beams is above a threshold
Send an LS to RAN4 to check the value for the threshold

Proposal 14: Support the UE to drop the monitoring results report if one of the followings happens:
UE has not measured K consecutive transmission occasions for each of the set B beam within the same DRX active time
For BM-Case 1, K=1 
For BM-Case 2, K is reported by the UE capability
The K transmission occasions includes the last transmission occasion before the CSI reference resource
The offset between every two consecutive transmissions is consistent
The measured L1-RSRP for each of the set B beams is above a threshold
Send an LS to RAN4 to check the value for the threshold
UE has not measured K transmission occasions for each of the DL-RS for monitoring within the same DRX active time
For BM-Case 1, K=1 
For BM-Case 2, the K transmission occasions are based on the prediction window configuration
The measured L1-RSRP for each of the DL-RS for monitoring is above a threshold
Send an LS to RAN4 to check the value for the threshold

Proposal 15: Defer the discussion on Option B based inference configuration procedure until all the parameters for CSI report configuration for beam prediction are finalized.
Proposal 16: Endorse the following TP for 38.214 to clarify the P-CRI is reported regardless of the value of repetition.
--------------- start of TP for 5.2.1.4 ---------------------------

When the UE is configured with higher layer parameter NZP-CSI-RS-ResourceSet and when the higher layer parameter repetition is set to 'off', the UE shall determine a CRI from the supported set of CRI values [or a P-CRI from the supported set of P-CRI values] as defined in Clause 6.3.1.1.2 of [5, TS 38.212] and report the number in each CRI [or P-CRI ]report. When the higher layer parameter repetition for a CSI-RS Resource Set for channel measurement is set to 'on', CRI for the CSI-RS Resource Set for channel measurement is not reported. CRI reporting is not supported when the higher layer parameter codebookType is set to 'typeII', 'typeII-PortSelection', 'typeII-r16', 'typeII-PortSelection-r16', 'typeII-PortSelection-r17', 'typeII-CJT-r18', 'typeII-CJT-PortSelection-r18', 'typeII-Doppler-r18' or 'typeII-Doppler-PortSelection-r18'. When the UE is configured with higher layer parameter NZP-CSI-RS-ResourceSet in resourcesForSetA, the UE shall determine a P-CRI from the supported set of P-CRI values as defined in Clause 6.3.1.1.2 of [5, TS 38.212] and report the number in each P-CRI report.
--------------- end of TP for 5.2.1.4 ---------------------------

Proposal 17: Endorse the following TP for 38.214 to fix the incorrect UE behavior when report quantity is set as ‘none-r19’.
--------------- start of TP for 5.2.1.4 ---------------------------
A CSI Reporting Setting is said to have a wideband frequency-granularity if 
-	reportQuantity is set to 'cri-RI-PMI-CQI', or 'cri-RI-LI-PMI-CQI', cqi-FormatIndicator is set to 'widebandCQI' and pmi-FormatIndicator is set to 'widebandPMI', or
-	reportQuantity is set to 'cri-RI-PMI-CQI', codebookType is set to 'typeII-PortSelection-r17', 'typeII-CJT-PortSelection-r18' or 'typeII-Doppler-PortSelection-r18' with  and cqi-FormatIndicator is set to 'widebandCQI', or
-	reportQuantity is set to 'cri-RI-i1' or
-	reportQuantity is set to 'cri-RI-CQI' or 'cri-RI-i1-CQI' and cqi-FormatIndicator is set to 'widebandCQI', or
-	reportQuantity is set to 'cri-RSRP' or 'ssb-Index-RSRP' or 'cri-SINR', or 'ssb-Index-SINR' or 'cri-RSRP-Index' or 'ssb-Index-RSRP-Index' or 'cri-SINR-Index', or 'ssb-Index-SINR-Index', or 'p-cri-r19' or 'p-cri-RSRP-r19' or 'p-ssb-index-r19' or 'p-ssb-index-RSRP-r19' or 'rspai-r19' or 'none-r19', or
-	reportQuantity is set to 'tdcp'
--------------- end of TP for 5.2.1.4 ---------------------------

Proposal 18: Endorse the following TP for 38.214 to capture the agreement that only always-on SSB is allowed for data collection
--------------- start of TP for 5.2.1.4.1 ---------------------------
For a UE configured with a CSI-ReportConfig with the higher layer parameter reportQuantity-r19 set to 'none-r19', the CSI-ReportConfig is linked to two periodic or two semi-persistent Resource Settings, and both the first Resource Setting (given by higher layer parameter resourcesForChannelMeasurement) and the second Resource Setting (given by higher layer parameter resourcesForSetA-r19) are for channel measurement. When the periodic resource setting is configured as SS/PBCH blocks, UE performs the channel measurement on the SS/PBCH blocks with center frequency provided by absoluteFrequencySSB.
--------------- end of TP for 5.2.1.4.1 ---------------------------

Proposal 19: Endorse the following TP for 38.214 to clarify the similar property is for DL Tx beam not all the properties
--------------- start of TP for 5.2.1.4.1 ---------------------------
For a UE configured with a CSI-ReportConfig with the higher layer parameter reportQuantity-r19 is set to 'none-r19', 'p-cri-r19', 'p-cri-RSRP-r19', 'p-ssb-index-r19', or 'p-ssb-index-RSRP-r19', if the same Associated ID is configured to be associated with different resource sets, the UE may assume similar properties of the spatial-domain transmission filter for the CSI-RS resources and/or SS/PBCH block resources among those different resource sets, irrespective of when the corresponding Resource Setting(s) is configured by higher layer signalling or released.
--------------- end of TP for 5.2.1.4.1 ---------------------------

Proposal 20: Endorse the following TP for 38.214 to clarify the condition for top M beam
--------------- start of TP for 5.2.1.4.3b ---------------------------
-	determine the best nrofBestBeamforMonitoring-r19 CSI-RS resources, or SS/PBCH Block resources based on [that provides nrofBestBeamforMonitoring-r19 largest L1-RSRP(s) among the measured from CSI-RS resources, or SS/PBCH Block resources of the corresponding Resource Set;]
-	check a condition : whether at least one of the nrofBestBeamforMonitoring-r19 identified CSI-RS resources, or SS/PBCH Block resources is linked to at least one of [is included among] the nrofreportedpredictedrs-r19 reported P-CRI(s) or P-SSBRI(s), of the linked report of the first CSI Reporting Setting, [where the linked report is ….]
--------------- end of TP for 5.2.1.4.3b ---------------------------

Proposal 21: Support dynamic activation/deactivation of periodic TRS with regard to TCI activation/indication based on the predicted beam.
Proposal 22: Since the activated/indicated TCI based on SD beam prediction is usually an unknown TCI state, to reduce the latency for TCI activation/indication based on SD beam prediction, support the NW to trigger aperiodic CSI-RS resources QCLed with the SSB/CSI-RS configured as the QCL source in the TCI state.
UE measures time/frequency offset and Rx beam based on the aperiodic CSI-RS resources
UE can also measure the pathloss based on the aperiodic CSI-RS resources
Proposal 23: To differentiate the TCI state for legacy beam indication and TCI state for beam prediction, support to configure separate TCI state pools for legacy beam indication and TCI state for beam prediction.
Proposal 24: Support to configure the action delay for the TCI state for beam prediction.
Proposal 25: For temporal beam prediction, the beam quality for current beam from an indicated TCI can be used for performance validation, and if none of the predicted beam(s) can provide better beam quality than current beam, the predicted beam(s) are assumed to fall to pass the performance validation.
Proposal 26:  Support UE feedback before the beam action time for performance validation for predicted beam in addition to the ACK/NACK for the TCI update signaling for temporal beam prediction.
Proposal 27: For BFR based on NW side model for SD beam prediction, after UE declares beam failure, if the UE cannot identify a candidate beam, it can trigger a UE initiated beam report
UE reports L1-RSRP for a set of SSBs/CSI-RSs configured by the NW in the UE initiated beam report
NW performs beam prediction based on the received L1-RSRP
Proposal 28: For BFR based on UE side model for SD beam prediction, after UE declares beam failure, if the UE cannot identify a candidate beam, it can report N predicted beam index(es) based on a beam codebook by the BFRQ.
Proposal 29: For BFR based on NW side model for temporal beam prediction, after UE declares beam failure, if the UE cannot identify a candidate beam, it can trigger a UE initiated beam report
UE reports L1-RSRP for a set of SSBs/CSI-RSs configured by the NW for multiple measured slots in the UE initiated beam report
NW performs beam prediction based on the received L1-RSRP
Proposal 30: For BFR based on UE side model for SD beam prediction, after UE declares beam failure, if the UE cannot identify a candidate beam, it can report predicted beam index(es) in one or multiple future slots by the BFRQ.
Proposal 31: Support the ML based beam prediction to facilitate the event triggered beam report.

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

Agenda Item:	9.1.1
Source:	Lenovo
Title:	AI/ML specification support for beam management
Document for:	Discussion

Conclusion
In this contribution, we provide the following proposals to discuss.
Proposal 1: 	Dynamic switching between AI/ML based beam prediction and non-AI/ML based beam report schemes as well as dynamic switching between different AI/ML models/functionalities for a CSI report configuration with AI inference should be supported.
Proposal 2: 	For aperiodic CSI report for beam inference, the associated ID should be configured for the CSI-AperiodicTriggerState.
Proposal 3: 	Support different AI/ML PU pools for different use cases.
Proposal 4: 	The UE reports the number of supported simultaneous AI/ML operations, e.g.,  in a component carrier and the number of simultaneous AI/ML operations across all component carriers
Proposal 5: 	Support UE reporting the number of AI/ML PUs for a certain CSI report with AI inference .
Proposal 6: 	Support UE reporting whether additional CPUs are needed for a CSI report with AI inference.
Proposal 7: 	If there is no available AI/ML PUs for a CSI report with AI inference, considering the following options:
Option 1: the corresponding CSI report is not updated.
Option 2: the UE report a non-AI based CSI report subject to UE capability.

Proposal 8: 	For a beam report associated with AI inference, the UE indicates that the reported beams are predicted beams or measured beams in the beam report.
Proposal 9: 	Refine the UE CSI computation time for aperiodic CSI report with AI inference by considering the AI process time.
Proposal 10: 	For NW-side AI/ML model performance monitoring, support Tx beam repetition for the UE to report the best L1-RSRP of a Tx beam among all its Rx beams.
Proposal 11: 	For UE-side AI/ML inference, support aperiodic beam measurement for performance monitoring and dynamic beam updating within the beam set associated with the aperiodic trigger state for beam measurement.
Proposal 12: 	Additional support Alt 2 and Alt 3 as the performance metric(s) of AI/ML model monitoring.
Alt 2: The L1-RSRP difference information based on actual measurement of the L1-RSRP of one or more of Top K predicted beam, and L1-RSRP measurements from a resource set/resources for monitoring
Alt 3: The RSRP difference information between the predicted RSRP and measured L1-RSRP of corresponding beam(s) of a resource set/resources for monitoring.
Proposal 13: 	When the size of a set for monitoring is smaller than the size of Set A, each beam in the set for monitoring may mapped to one or more beams in Set A and the mapping relation is configured by RRC signaling.
Proposal 14: 	Confirm the working assumption with the following update for the performance monitoring for BM-Case 1
Working Assumption
At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, 
for BM-Case 1, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an actual inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are no later than the CSI reference resource corresponding to the CSI report for monitoring. 
FFS: whether to i Introduce a threshold X for the minimal slot offset, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.
For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with actual linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
wherein N (N>=1) is configured in CSI-ReportConfig for monitoring
FFS on additional rule for counting N linked pair
For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.
Proposal 15: 	Confirm the working assumption with the following update for the performance monitoring for BM-Case 2
Working Assumption
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring.
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring.
The f-th time instance may be no later than or later than then CSI reference resource corresponding to the CSI report for monitoring.
FFS: whether to I Introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance.
Proposal 16: 	Regarding the report quantity and metric
Introduce a new quantity (i.e., beam accuracy indicator, BAI) for beam prediction accuracy in the CSI report for monitoring, where BAI is  (0 ≤≤ N), and the corresponding beam prediction accuracy is, (0≤≤ 1).
the size of CSI field associated with the BAI is  
Where N is implicitly or explicitly configured by NW, as the number of the reported inference result(s) linked with performance monitoring instance(s)
Where  as the number of the reported inference result(s) linked with performance monitoring instance(s), for which, 
at least one of the Top M beam(s) of the resource set(s) for monitoring is among Top-K predicted beam(s)
Where K is the number of predicted beam(s) in the corresponding inference report  
Where Top M beam(s) is the beam(s) with largest measured value(s) of L1-RSRP(s) of the resource set(s) for monitoring
M is configured by NW in CSI report configuration for monitoring
M= 1, and M is up to 4
Proposal 17: 	Support event triggered beam report for hybrid performance monitoring for UE-side AI/ML model.

3GPP TSG RAN WG1 #121			R1-2504043
St Julian’s, Malta, May 19th – 23th, 2025
Agenda item:		9.1.1
Source:	China Telecom
Title:	Discussion on specification support for AI/ML based beam management
Document for:		Discussion

Conclusions
In this contribution, we discuss AI/ML for beam management and have following proposals:
Observation 1: For NW-sided model, for inference report, the payload of legacy CRI/SSBRI reporting is smaller than or at same level as bitmap based reporting when M is not larger than 8.
Proposal 1: For NW sided model, for the quantization of a reported L1-RSRP value, not support to optimize quantization step or range(s) for differential L1-RSRP.
Proposal 2: For NW-sided model, for inference report, at least for BM-Case 1, if the maximum value of M is no larger than 8, M CRI/SSBRI of a measurement resource set is reported as beam information in a beam report in L1 signaling.
Proposal 3: For NW-sided model, for inference report, at least for BM-Case 1, if the maximum value of M is larger than 8,
When M<=8, M CRI/SSBRI of a measurement resource set is reported as beam information in a beam report in L1 signaling.
When M>8, a bitmap and a resource indicator can be configured to be reported by RRC
The bitmap consists of K bits, where K is the size of the measurement resource set,
The k-th MSB of the bitmap corresponds to the k-th resource in the resource set by the increasing order of resource ID, and the m-th nonzero bit of the bitmap corresponds to the m-th reported resources, 1≤m≤M
The resource indicator indicates the resource with the largest measured value of L1-RSRP from the M reported resources in the resource set, 
The size of the resource indicator is 
Note: no separate UE feature is introduced for the bitmap based method.  
Note: Purpose, such as above “For NW-sided model, for inference report, at least for BM-Case 1”, will not be specified in RAN 1 specifications.
Proposal 4: The predicted Top K beam(s) are the K beam(s) with largest predicted RSRP values.
Proposal 5: For NW-sided model, for inference, the report content for beam related information can be L1-RSRP or L1-RSRP and beam ID.
Proposal 6: For NW-sided model, for inference, the max number of reported beam related information in one report can be configured by the network based on UE capability.
Proposal 7: For NW-sided model, for BM-Case 2, support to report timestamp information for measurements on set B.
Proposal 8: For UE-sided model at least for BM Case-1, for inference results report, not support to configure only one resource set for Set B.
Proposal 9: Clarification on how to calculate beam prediction accuracy is needed, current agreement is not clear.
Proposal 10: For calculation the performance metric of Type 1 Option 2 performance monitoring for UE-sided model, when the size of the set for monitoring is smaller than the size of Set A, NW indicates the UE about the mapping between the resources in the set for monitoring and resources in Set A, e.g, based on the NZP-CSI-RS-ResourceId/SSB-Index or explicitly configured by RRC.
Proposal 11: Support to introduce a threshold for the minimal slot offset between the CSI reference resource of inference report and the transmission occasion of the CSI-RS/SSB resources for monitoring.
Proposal 12: If the number of AI/ML model failure reaches a predefined threshold, consider performing model switch or fallback to non-AI/ML method.
Proposal 13: Associated ID is not mandatorily configured. If the associated ID is absent, UE may assume similar properties of all the related beams in the same cell.

3GPP TSG RAN WG1 #121                                                               R1-2504058
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:					    9.1.1
Source:	Sony
Title:	Discussion on specification support for beam management
Document for:	Discussion/ Decision 

Conclusions
Finally, allow us to repeat our proposals to draw attention.
: For the UE-side model, regarding the reporting of inference content, support beam information for the predicted Top K beams among a set of beams, along with probability-related information for these beams.
: For model monitoring, If the beam ID of one of the Top M beams is included in the Top K predicted beams, and the corresponding RSRP difference between the measured and predicted values should fall within a predefined acceptable threshold, then the prediction can be considered correct.
: Support defining the mapping of the resource in the set for monitoring to resource in Set A is configured via RRC.
: When the monitoring resource set does not include the predicted Top 1 or Top-K beams, and if the highest RSRP in the measured set is greater than the highest RSRP in the predicted set, this can be considered a model prediction failure.
: Support for defining event(s) to trigger reporting for monitoring, 
when the measured RSRP differs from the predicted RSRP for the same beam in BM-Case 1. 
when the multiple prediction results for the same future time instance vary significantly in BM-Case2.
: Model failure is determined by the performance metrics that are calculated multiple times over a specific time period.

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

Source:	Fujitsu
Title:	Discussion on specification support on AI/ML for beam management
Agenda item:	9.1.1
Document for:	Discussion and Decision

Conclusion

In conclusion, we have the following proposals on specification support on AI/ML for beam management in Rel-19.

Training data collection

Proposal 1:
Regarding training data collection, RAN1 to further discuss the reference signal configuration details for BM Case-2, i.e., how to configure the prediction window with Set A and how to configure the measurement window with Set B.
Proposal 2:
For training data collection, at least the following information should be included:
Reference signal ID
Beam quality, e.g., L1-RSRP
Proposal 3:
For training data collection, the model input data and the ground truth data should be included. Whether and how to map/associate the model input data with the ground truth data could be further discussed per sub-use case for beam management.
Proposal 4:
For training data collection with UE side model, when one associated ID is configured, the associated ID should be collected into the dataset. When two associated IDs are configured, both associated IDs should be collected into the dataset.
Proposal 5:
For training data collection, RAN1 to further discuss the quantization for the model input data and ground truth data. High-resolution quantization and non-differential RSRP could be considered.
Proposal 6:
Regarding training data collection, the same UE Rx beam should be applied to the measurements on the reference signals for model input data (Set B) and the measurements on the reference signals for ground truth data (Set A).
Proposal 7:
Regarding training data collection, repetition of the reference signals could be considered to improve the measurement accuracy, and the same UE Rx beam should be maintained during the measurement.

UE side model: inference

Proposal 8:
For BM Case-2 with UE side model, RAN1 to discuss beam indication enhancement, for example, TCI states of multiple time instances could be indicated via one DCI.

UE side model: performance monitoring

Proposal 9:
Regarding UE-assisted performance monitoring for UE side model, when the size of the resource set for monitoring is smaller than the size of Set A, explicit mapping between the RS in the resource set for monitoring and Set A beams should be configured to the UE.
Proposal 10:
Regarding UE-assisted performance monitoring for UE side model, when the size of the resource set for monitoring is smaller than the size of Set A, i.e., a subset of Set A is configured as the resource set for monitoring, the performance metric, e.g., beam prediction accuracy could be determined based on the subset of Set A.
Proposal 11:
Regarding UE-assisted performance monitoring for BM Case-1 with UE side model, the time interval between the Set B transmission and the transmission of the resource set for monitoring should be within certain threshold, e.g., X symbols/slots, to guarantee the accuracy of performance metric calculation. For BM Case-2 with UE side model, the time interval between the transmission of the resource set for monitoring and the corresponding prediction instance should be within certain threshold, e.g., X symbols/slots.

UE side model: processing unit

Proposal 12:
For BM Case-1 and BM Case-2 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 BM Case-1 and BM Case-2 with UE-side model, it’s not necessary to occupy APU for performance monitoring and training data collection.

NW-side model: inference

Proposal 14:
For BM Case-1 with NW-side model, regarding the reporting content for Set B measurement results for inference operation, the beam related information could include CRI/SSBRI.
Proposal 15:
For BM Case-2 with NW-side model, regarding the reporting content for Set B measurement results, the beam related information could include CRI/SSBRI and corresponding L1-RSRP.
Proposal 16:
For BM Case-2 with NW-side model, similar beam indication enhancement as BM Case-2 with UE side model could be considered.

NW-side model: performance monitoring

Proposal 17:
Regarding NW-side monitoring for NW-side model, RAN1 to further discuss the performance metric, and the following alternative is preferred.
The L1-RSRP difference evaluated by comparing measured RSRP and predicted RSRP.
Proposal 18:
Regarding NW-side monitoring for NW-side model, RAN1 to further discuss the reference signal configuration and possible reporting enhancement, e.g., quantization of L1-RSRP. The high-resolution quantization and non-differential RSRP could be considered for ground truth data for performance monitoring.

LCM and consistency

Proposal 19:
RAN1 to further discuss whether/how to apply associated ID across different cells.

3GPP TSG-RAN WG1 Meeting #121	R1-2504093
St Julian's, Malta, May 19th – 23rd, 2025
Agenda Item:	9.1.1
Source:	HONOR
Title:	Discussion on AI/ML for beam management
Document for:	Discussion

Conclusions
Based on the discussion in the previous sections we propose the following:
Regarding Type 1 Option 2 of the UE-side model monitoring, to calculate the performance monitoring metric over  monitoring samples, at least three types of transmission occasions of monitoring resources that cannot be linked to the inference report should be considered.
Case 1: The transmission occasions of monitoring resources have a slot offset larger than the minimum slot offset relative to the CSI reference resource of the inference report (for BM Case 1) or the corresponding predicted time instance (for BM Case 2), which prevents these transmission occasions from being linked to that inference report.
Case 2: The transmission occasions of monitoring resources or the inference reports are too close to the latest monitoring report, failing to meet the CPU timeline requirement.
Case 3: The monitoring report is transmitted earlier than the inference report.
For UE-sided AI/ML model for beam management, for Option 2 (UE-assisted performance monitoring), support the size of the set for monitoring is smaller than the size of Set A,
The mapping of the resource in the set for monitoring to resource in Set Ais determined as following: 
for the resource set for monitoring is an SSB set, support to reuse TCI-stateID to implicitly indicate the mapping rule
for the resource set for monitoring is a CSI-RS set, support to configure the new RRC parameter to explicitly indicate the mapping rule.
For the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, UE reports , the maximum value of the threshold X, in capability reporting, and the threshold  can be optionally configured by RRC.
Revert the previous Working Assumption with the following modification:
For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
wherein N (N>=1) is configured in CSI-ReportConfig
FFS on additional rule for counting N linked pair
For UE-sided AI/ML model, for Option 2 (UE-assisted performance monitoring), UE reports both  and  to NW.
Where  is the number of transmission occasion(s) of monitoring resources with linked inference report. 
Where  is the beam accuracy indicator (BAI), i.e., the number of linked pairs that satisfy the performance metric.
For NW-sided model, for inference report, at least for BM-Case 1, the content in a beam report in L1 signalling, support: 
L1-RSRPs and corresponding beam information up to M beams within X dB gap to the largest measured value of L1-RSRP if the number of beams within X dB gap to the largest measured value of L1-RSRP is larger than N. Otherwise, the beam report includes L1-RSRPs and corresponding beam information of Top N beam(s) with largest N measured value(s) of L1-RSRP(s) of a measurement resource set.
M, N and X can be configured by gNB, with N

3GPP TSG-RAN WG1 Meeting #121	R1-2504112
Malta, MT, May 19th – 23rd , 2025
Agenda item:		9.1.1
Source:	Nokia
Title:	AI/ML for Beam Management
Document for:		Discussion and Decision

Conclusion
In this contribution, we discuss details of ML for beam management use case and have the following proposals, 
UE-sided model
Proposal 1: For BM-Case1, when predicted Top K beam(s) is reported as inference report, the UE may order/rank the predicted beams in the report based on the probability information of the beam to be the best beam or based on the values of the predicted RSRPs, if available. 

Proposal 2: For UE-sided BM Case-2, CSI report configuration shall indicate the number of measurements (N) for Set B.

Proposal 3: For UE-sided BM-Case 2, at least for AP CSI reporting for inference, 
Support repetition of CSI-RS measurements (for Set B) with a dedicated Trigger State (DCI carrying this only triggers the Set B measurements for a corresponding AP-CSI Report) and the AP-CSI report may be triggered separately (second DCI to get the AP-CSI-Report in PUSCH).
FFS: further details on triggering CSI-RS measurements for Set B and linking to the corresponding report.

Proposal 4: For UE-sided BM Case-1 and 2, for AP CSI reporting for inference, 
The associated CSI-ReportConfig corresponding to a trigger state in CSI-AperiodicTriggerStateList shall indicate, in addition to the Resource Set ID for channel measurement, a second Resource Set ID for RS prediction.

Proposal 5: For BM-Case1 and BM-Case2, considering NW-sided performance monitoring for beam prediction related CSI reporting, conclude the following,  
A different CSI report can be used to support NW-sided performance monitoring. 
The NW can use a different CSI report to get beam measurements/reporting for a monitoring RS resource set (as preferred by the NW) within the legacy CSI reporting framework.  

Proposal 6: For BM-Case1 and BM-Case2, RS-PAI reporting metric shall be determined as the total count of accurate beam prediction instances (Np). 
Size of the bit field metric reporting can be Ceil(log2(N)),  given via nroftimeinstance-r19.  
The condition, “at least one of the Top M beam(s) of the resource set(s) for monitoring is among Top-K predicted beam(s) of Set A”, is only applicable for valid monitoring instances within N, where a monitoring instance is valid only when, 
There is a linked inference report 
Top K predicted beams in the linked inference report are available to measure within the monitoring RS resource set. 
Proposal 7: Confirm the following working assumption (with changes)
Working Assumption (RAN 1 #120b)
For BM-Case 1, the beam prediction accuracy is calculated based on N latest transmission occasion(s) of monitoring resources with linked inference report no later than CSI reference resource corresponding to the CSI report for monitoring 
wherein N (N>=1) is configured in CSI-ReportConfig
FFS on additional rule for counting N linked pair
CSI reference resource corresponding to the CSI report for monitoring is determined based on legacy for all types (P/SP/AP) of monitoring reporting
For BM-Case 1, one resource set for monitoring is configured in one CSI-ReportConfig for monitoring.

Proposal 8: Confirm the following working assumption (with changes)
Working Assumption (RAN 1 #120b)
At least for the monitoring Type 1 Option 2 of UE-side model monitoring, for calculation of metric for monitoring, 
for BM-Case 1, measurement result of a nth (n = 1,..,N) latest transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the nth latest transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding inference report, and the transmission occasion of the CSI-RS/SSB resources for monitoring are is no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X for the minimal slot offset, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked inference report.
Support X values below min RS transmissions periodicity. 
Proposal 9: Confirm the following working assumption (with changes)
Working Assumption (RAN 1 #120b)
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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. 
CSI reference resource corresponding to the CSI report for monitoring is determined based on legacy for all types (P/SP/AP) of monitoring reporting
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a nth (n = 1,..,N) latest transmission occasion of the CSI-RS/SSB resources for monitoring is linked with the f-th time instance for prediction of an inference report, where the f-th time instance for prediction of the inference report has the minimal slot offset to the nth latest transmission occasion of the CSI-RS/SSB resources for monitoring. 
Wherein, the corresponding f-th time instance for prediction of the inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are is no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance 

Proposal 10: For BM-Case2, for clarifying the RS-PAI reporting metric calculation for more than one time instance (corresponding to the f-th time instance for prediction),
Configure separate monitoring reports for each of the time instance.

Proposal 11: For BM-Case1 and BM-Case2, for clarifying the RS-PAI reporting metric calculation with AP CSI reporting,
Indicate a first trigger (of AP-CSI-reporting for monitoring) only to start measurements on monitoring RS resources (without CSI reporting) and a second trigger to report the CSI report for monitoring. 
The UE is not expected to determine beam prediction accuracy prior to receiving the first trigger PDCCH for AP-CSI-Report for monitoring.  

Proposal 12: For beam prediction use cases, considering the configuration of associated ID,
Assigning identifiers (associated ID) shall be left to NW-implementations. 
At least for inference, clarify the applicability for 'aperiodic' CSI RS for the case of AP CSI report with AP CSI-RS, 
Option 1: limit the AP CSI-RS to a single Resource Set and configure one or two associate IDs for that Resource Set. 
Option 2: define multiple associated IDs each corresponding to a resource set in CSI-ResourceConfig.  

Proposal 13: For AI/ML-enabled CSI reporting, considering the CPUs/APUs used for beam prediction reporting, the following are supported, 
Support Option 1 for BM-Case1.
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE capability.
And 
Support Option 3 for BM-Case2.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE capability.
And  
For CPU duration, Support legacy CPU durations:
An aperiodic CSI report occupies CPU(s) from the first symbol after the PDCCH triggering the CSI report until the last symbol of the scheduled PUSCH carrying the report.
A periodic or semi-persistent CSI report occupies CPU(s) from the first symbol of the earliest one of each CSI-RS/SSB resource, respective latest CSI-RS/SSB occasion no later than the corresponding CSI reference resource, until the last symbol of the configured PUSCH/PUCCH carrying the report. 
For APU duration, Support legacy-like CPU durations (with the change in red):
An aperiodic CSI report occupies APU(s) from the first symbol after the PDCCH triggering the CSI report until the last symbol of the scheduled PUSCH carrying the report.
A periodic or semi-persistent CSI report occupies APU(s) from the last first symbol of the earliest one of each CSI-RS/SSB resource, respective latest CSI-RS/SSB occasion no later than the corresponding CSI reference resource, until the last symbol of the configured PUSCH/PUCCH carrying the report. 

Proposal 14: For beam prediction use cases, considering CPU occupation time for performance monitoring reporting, the following are considered, 
A periodic or semi-persistent CSI report (for monitoring) occupies CPU(s) per each monitoring transmission instance, where occupation starts from the first symbol of the earliest one periodic or semi-persistent CSI-RS/SSB resource of monitoring transmission instance, until 𝑍3′symbols after the last symbol of the latest one of the CSI-RS/SSB resource of monitoring transmission instance. 
When the UE does not have CPUs to occupy in one monitoring transmission instance, the UE does not have to consider that as a valid monitoring instance. 
For AP-CSI-Report, as two triggers are proposed (in earlier proposal). After the first trigger, CPUs are occupied same as in the case of P/SP reporting. After the second trigger, CSI report occupies CPU(s) from the first symbol after the PDCCH triggering the CSI report until the last symbol of the scheduled PUSCH carrying the report.

Proposal 15: For beam prediction use cases, considering CPU occupation time and number of CPUs for data collection (at least for UE side DC), the following enhancements and clarifications are considered, 
	can be assumed for data collection duration.  
CPU occupation duration can be the active durations of data collection. 
Proposal 16: For beam prediction use cases, to clarify the active NZP-CSI-RS resources and active CSI-RS ports, 
The UE is not expected to assume CSI-RS resources of Set A (configured in inference report) as active CSI-RS resources. 
FFS: on the active time durations of CSI-RS resources associated to data collection (at least for UE side DC). 

Proposal 17: For the priority value calculation, , RAN1 to clarify the following,  
k = 0 when the report content is inference results.
k = 1 when the report content is RS-PAI.

Proposal 18: Add a flag to CSI-ReportConfig to indicate that a configuration contains one or multiple sets of inference-related parameters instead of a full configuration. This flag could also be used as an indication that the configuration is subject to the applicability determination procedure.
NW-sided model
Proposal 19: Consider the following for a CSI report that enables beam prediction at the NW,
For BM-Case1 and BM-Case2, consider enhancements for L1-RSRP quantization, increasing the differential L1-RSRPs in the report to X dB quantization step.
FFS: To reduce UCI reporting overhead, discuss value(s) of X (e.g. X=3 and X=4 larger than legacy X>2dB) configurable to the UE.

Proposal 20: For NW-sided model, for inference report, for the content in a beam report in L1 signaling when M

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

Agenda item:	9.1.1
Source: 	Hyundai Motor Company
Title:	Discussion on AI/ML based beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, the following conclusions were made:

Proposal #1 
Discuss how to link resources of the set for monitoring to resource in Set A, when the size of a set for monitoring is small than the size of Set A.

Proposal #2 
Discuss whether to exclude the case where the set for monitoring is not a subset of Set A or not in case where the size of a set for monitoring is small than the size of Set A.

Proposal #3 
Introduce a new indicator for Top-K beam information to support UE-assisted performance monitoring for NW sided model

Proposal #4
Discuss performance metric for performance monitoring with multiple monitoring instance per beams for monitoring.

3GPP TSG RAN WG1 #121	R1-2504129
St Julian’s, Malta, May 19th – 23th, 2025
Agenda item:	9.1.1
Source: 	ETRI
Title:	Discussion on specification support for beam management
Document for:	Discussion

Conclusion
In this contribution, views on specification support for AI/ML beam management were shown and the following proposals were made:

Proposal 1: For performance monitoring, the UE can provide information to assist in selecting the subset of Set A for monitoring.

Proposal 2: If a subset of Set A is used for performance monitoring, it is necessary to consider a method for determining the success of beam predictions when the predicted Top-K beams are not included in the monitoring set.

Proposal 3: For UE-assisted performance monitoring, the beam prediction accuracy can be expressed as Ns/N, where Ns represents the number of successful predictions.

Proposal 4: For BM-Case 2, support the configuration of multiple time instances for calculating the performance metric.

Proposal 5: For performance monitoring, the UE needs to report the updated actual number of linked pairs to NW when the UE fails to obtain N linked pairs required for metric calculation.

Proposal 6: For UE-assisted performance monitoring, support the inclusion of a linkage ID within the CSI-ReportConfig IE.

Proposal 7: For UE-assisted performance monitoring, support reporting linkage ID within the CSI report to distinguish performance metrics.

Proposal 8: For performance monitoring, the UE can identify the connection between resources in monitoring set and Set A by using QCL information.

Proposal 9: For UE-assisted performance monitoring, the monitoring event can be triggered when the counter reaches a specific number
The counter is incremented if the calculated performance metrics fail to meet predefined performance criteria

Proposal 10: For the UE-sided model, the UE assumes that the same TCI-StateId represents a beam with the same direction if the Associated ID is identical.

Proposal 11: For the UE-sided model, the UE can identify the connection between resources in Set A and Set B by using QCL information.
Proposal 12: For UE-sided model, the definition of predicted Top-K beams represents the beams with the highest predicted RSRP values or the beams with the highest probability of being the best beam.

Proposal 13: For the UE-side model, support the CSI report format for temporal domain beam prediction, including the optimal K beam information along with RSRP information from multiple time instances.

Proposal 14: For AI/ML-based beam management, during processing of a CSI report for inference, both dedicated AI/ML PU and legacy CPU are occupied.

Proposal 15: For UE-sided model, regarding a CSI-ReportConfig for data collection, .

Proposal 16: For UE-sided model, the UE can report the minimum inference time to NW for calculating the occupation time of AI/ML PU.

Proposal 17: For CSI priority rules in AI/ML-based CSI reporting, set k=0 when the CSI report contains an inference report.

Proposal 18: For CSI priority rules in AI/ML-based CSI reporting, set k=1 when the CSI report contains content for performance monitoring.

Proposal 19: For BM-Case2, support the configuration of multiple Resource Sets for Set A.

Proposal 20: For both NW-side model and UE-side model, support the configuration of multiple Resource Sets for Set A within one CSI report configuration.

Proposal 21: For the NW-side model, support the method of omitting RSRP values based on differences in RSRP values for measurement report.

Proposal 22: For the NW-side model, support the use of a bitmap to indicate the beams included in the CSI report for measurement report.

Proposal 23: Support methods for reducing UE reporting overhead during data collection for training when the AI/ML model is located on the NW-side.
The NW limits the maximum number of L1-RSRP values that the UE can transmit through CSI reporting.
The NW specifies an L1-RSRP threshold, requiring the UE to report the L1-RSRP values of Tx beams that exceed this threshold.

Observation 1: The NW can determine a subset of Set A as the monitoring set according to needs without explicit rules.

Observation 2: For the NW-sided model, reducing measurement overhead is necessary, especially in the case of temporal domain prediction.

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

Agenda Item:	9.1.1
Source:	Transsion Holdings
Title:	Discussion on specification support for AI/ML beam management
Document for:	Discussion and decision

Conclusion
In this contribution, we discuss potential enhancements on AI/ML beam management. Based on the discussion above, we provide the following proposals:
Proposal 1: Regarding the signaling for training data collection, support higher-layer signaling to report the contents of training data.
Proposal 2: For BM-Case 2 of NW-side model, the time stamp information of multiple past time instances can be implicitly reported.
Proposal 3: Regarding the trigger/initiating data collection for UE-side model, support Option 2:
Option 2: request from UE for data collection.
Proposal 4: Regarding the quantization of a reported L1-RSRP value, support larger quantization step(s) than the legacy quantization step for differential L1-RSRP and/or for absolute L1-RSRP.
Proposal 5: For BM-Case 2 of UE-side AI/ML model, support to configure a observation/measurement window.
Proposal 6: For beam indication of BM-Case 2 of UE-side AI/ML model, support to extend the Rel-17 unified TCI state framework to activate/indicate N TCI states which are corresponding to N future time instances.
Proposal 7: For performance monitoring of NW-side model, configuration of Set B and/or Set A and the reporting of measurement results of Set B and/or Set A need to be specified.
Proposal 8: Regarding Option 2 of UE-side AI/ML model, support to configure a window for calculating the metric and the following alternatives can be considered to define a window:
Alt-1: The window for calculating the metric is defined based on the uplink slot for the report.
Alt-2: The window for calculating the metric is defined based on the CSI reference resource corresponding to the report.
Proposal 9: For Option 2 of Type 1 performance monitoring, the following alternatives can be considered to report the metric:
Alt-1: Quantization of performance metric.
Alt-2: The statistic values of the performance metric.
Alt-3: A specific event.
Proposal 10: The distance between transmission occasion of the CSI-RS/SSB resource of the monitoring resource set and time instance of prediction is no larger than a certain distance.
Proposal 11: Regarding the consistency of NW-side additional condition across training and inference for UE-side model, support to confirm the working assumption:
[Working Assumption]
The associated ID at least can be configured within CSI framework 
FFS on details
FFS on whether/how to configure/indicate the associated ID via other signal(s) and/or in other procedure(s)/framework(s)
Proposal 12: For UE side model in beam management, UE may assume the similar properties(e.g., the same downlink spatial domain transmission filters) of a DL Tx beam or beam set/list with the same associated ID.
Proposal 13: Regarding processing unit(s) of a CSI report for inference, support Option 3:
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
And  
5 

TDoc file reading error

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

Source:	OPPO
Title:	On specification for AI/ML-based beam management
Agenda Item:	9.1.1
Document for:	Discussion

Conclusion
In this section, allow us to repeat our response to RAN2 LS, proposals for both NW-side and UE-side models and observations.
For NW-side model
Inference
For NW-side model, the beam information should be clarified as beam reporting index (i.e. CRI/SSBRI in CSI reporting).
For BM-Case2 with NW-side model, support that UE reports multiple measurement instances of Set B in a single beam reporting instance.
For BM-Case2 with NW-side model, support that UE can be indicated with multiple TCI states (more than 1 joint TCI state or a pair of DL and UL TCI states) for multiple future instances. 

Data collection for training
For NW-side data collection for training, it is up to RAN1 to decide the reporting content for MDT-based data collection, and the following contents should be supported
L1-RSRPs measurements of fixed Set B as model input
Top-K L1-RSRP(s) and Top-1 CRI/SSBRI as labels
For BM-Case2 with NW-side model, the temporal domain information of the collected data for training could be reported in an implicit manner, i.e. no explicit time stamps needed.
Continue to discuss and achieve consensus in RAN1 on the content of data collection for NW-side data collection for training.

Consistency on UE-side additional condition
For BM-Case1 and BM-Case2 with NW-side model, it is NOT necessary to specify UE-side additional condition on UE Rx beamforming.

Observations
For BM-Case1 and BM-Case2 with NW-side AI/ML model training
It seems necessary to enhance beam reporting for Set B as model inputs
It seems sufficient to reuse beam reporting for Top-1/Top-K beams as labels
The consistency issue on UE Rx beam assumption is not strongly related to DL Tx beam prediction and can be alleviated via mixed dataset (different Rx beam assumptions) during training.

For UE-side model
Inference
For inference with UE-side model, support UE to report (Opt 3) beam information on predicted Top K beam(s) and probability information of predicted Top K beam(s). 
For inference of BM-Case2 with UE-side model, support to indicate multiple TCI states for up to N future time instances with one-shot beam indication. 

Monitoring
For Type 1 Option 2 of UE-side performance monitoring, support to introduce the beam prediction accuracy indicator (i.e. number of correct beam prediction) as new report quantity in CSI report.
For Type 1 Option 2 of UE-side performance monitoring, confirm those working assumptions for both BM-Case1 and BM-Case2. 
For the cases when the size of monitoring resource set is smaller than that of Set A, support to reuse the QCL rule (i.e. via TCI state ID) to map RS in monitoring set to RS in Set A.
For Type 1 Option 2 performance monitoring, support the probability of model output (Alt.4) as one performance metric.
For Type 1 Option 1 and Type 2 performance monitoring, discuss and specify (if necessary) the LCM events. 
For performance monitoring, study the event-based LCM with performance metric of beam prediction accuracy (Alt.1) and probability (Alt.4). 
For performance monitoring with UE-side model, support Type 2 (indication/request/report from UE to gNB) performance monitoring. 

Consistency on NW-side additional condition
To ensure consistency between Set A and Set B across training and inference, confirm the working assumption that the associated ID can be configured within CSI framework.
For inference with UE-side model, support that each associated ID corresponds to a Set B and a Set A as a triple of {associated ID, Set B, Set A} configured within CSI framework.
To ensure the flexibility on NW-side additional condition, support to configure multiple sets of {associated ID, Set B, Set A}.

Observations
For BM-Case2 with UE-side model, the timestamp of future time instance(s) could be implicitly reported to NW.
For the metrics of performance monitoring, both L1-RSRP differences (Alt.2 and Alt.3) could be insignificant, i.e. from 0.5dB to 2dB which is comparable to L1-RSRP quantization errors.
Once the output probability of multi-classification model is lower than certain threshold, UE can tell whether it performs good or not on beam prediction error rate.
For probability-based monitoring, there is no need to additionally configure measurement resource(s) for UE to collect the ground truth. 
Performance monitoring cannot directly ensure the consistency but may only send a warning to NW via LCM procedure. 

Other aspects
For the occupied number APU(s) and CPU(s) for BM-Case1 and BM-Case2, at least support (Option 3) UE to report that N2 APU(s) and 1 CPU are occupied simultaneously.
For applicability reporting for Option B, at least support UE to report the following content in OtherConfig
For Set A: the size of Set A and the associated ID
For Set B: the size of Set B and the associated ID (if Set B is different from Set A)
Other related parameters: both the number and time gap of prediction instances for BM-Case2

3GPP TSG RAN WG1 #121		R1-2504258
St Julian, Malta, May 19th – 23rd, 2025
Agenda Item: 9.1.1
Source: MediaTek Inc.
Title:	Discussion on specification support for AIML-based beam management
Document for: Discussion & Decision
 

Conclusion
In summary, based on the above discussion we have the following observations and proposals:
Proposal 1: For UE-sided model, for the content in the report of inference results, current agreed options are sufficient. 

Proposal 2: For BM Case1, when the report is a DCI triggered PUSCH reports, the Z/Z' report timeline requirement should be determined by UE capability.
Proposal 3: For BM Case2, when the report is a DCI triggered PUSCH reports, the Z/Z' report timeline requirement should be determined by UE capability.
Proposal 4: For each BM Cases, UE reports its corresponding capability on model inference timing. The timing capability is added to the current value of Z and Z’ in the report timeline requirement.
Proposal 5: the CSI reference resource definition should consider model inference delay, which is expected to be higher than the legacy beam management operations, especially for BM Case2.
Proposal 6: For each BM Cases, UE reports its corresponding capability on model inference timing. The timing capability is added to the n_CSI_ref variable in the definition of CSI reference resource.
Proposal 7: For the processing unit of a CSI report for AI BM, support Option1: only dedicated AI/ML PU is occupied, O_APU=N1 is reported by UE.
Proposal 8: For the processing unit of a CSI report for AI BM, do not support Option2: only legacy CPU is occupied, O_CPU=M it is reported by UE.
Proposal 9: The total number of dedicated AI/ML PU for AI/ML-based beam management will not be shared with other use cases. 
Proposal 10:  When the size of a set for monitoring is smaller than the size of Set A. The mapping between the resources for Set A and resources for monitoring can be configured in RRC. 

Proposal 11:  For option1 type2, to map RS resources in Set A and monitoring set, NW configures an additional bitmap or a set of ID (CRI or SSBRI of a resource in Set A) in the monitoring report configuration.

Proposal 12: For option1 type2, the performance metric of Top 1 or Top K beam prediction accuracy, Top-K predicted beam(s) should also be selected from the resource set(s) for monitoring, by filtering out the beams not included in the monitoring resource sets. K is the number of predicted beam(s) in the corresponding inference report.

Proposal 13: RAN1 does not consider a one-to-one mapping between the associated ID and inference configurations.
Proposal 14: RAN1 makes a working assumption that each NW vendor has its own exclusive set of associated IDs, which can be managed by PLMN. 

Proposal 15: For associated ID, considering 
First part is a PLMN-specific ID, different NW vendors may not use the same ID under one PLMN
Second part is a cell/gNB-determined ID

Proposal 16: Set A should always be configured with physical resources (i.e., have corresponding resource ID/resource set ID, ResourceConfig ID), for the following reasons:
Set A is required for monitoring/data collection, and can be configured with longer periodicity 
Set A is required for legacy UE
Proposal 17: For the design of csi-ReportConfig for UE-sided model, Set A can be configured by the existing IE resourcesForChannelMeasurement in csi-ReportConfig. Set B can be configured by a new IE which has csi-ResourceConfigId as its value.

Proposal 18: For both NW-side model and UE-side model, for monitoring and data collection (when applicable), to support number of Set A beams > 64, up to 4 resource sets can be configured for Set A in one CSI report configuration.

Proposal 19: For AI/ML-based BM, at this stage, there is no further enhancement needed for TCI and beam indication based on unified TCI state framework.
Proposal 20:  For Rel-19 AI BM features, introduce a specific beamReportTiming UE capability to distinguish between the legacy beamReportTiming UE capability.

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

Agenda Item:	9.1.1
Source:	Apple Inc.
Title:	Enhancements for AI/ML enabled beam management
Document for:	Discussion/Decision

Conclusion
In this contribution, we provide our views regarding AI/ML BM. We have 
Proposal 2-1: besides associated ID, the consistency in resource configuration between training and inference is verified for applicability reporting for the case where set B is a subset of set A. 
For Option-A in applicability report, the consistency checking for the case set B is a subset of set A is 
Step 1: UE verify there is no duplicate reference to NZP-CSI-RS-ResourceId in a NZP-CSI-RS-ResourceSet configuration for set A and that for set B;
Step 2: If NZP-CSI-RS-ResourceId-1 and NZP-CSI-RS-ResourceId-2 are both referred in a NZP-CSI-RS-ResourceSet configuration for set A and a NZP-CSI-RS-ResourceSet configuration for set B, if NZP-CSI-RS-ResourceId-1 comes before NZP-CSI-RS-ResourceId-2 in the SEQUENCE definition for set A, then NZP-CSI-RS-ResourceId-1 also comes before NZP-CSI-RS-ResourceId-2 in the SEQUENCE definition for set B.  
For Option-B in applicability report, a bitmap for selecting sub B beams out of set A beams is used in consistency checking.

Proposal 3-1: aperiodic CSI-RS resources can be enabled for AI/ML inference. 

Proposal 4-1: to control feedback overhead, beam reporting for BM Case-1 consists of 
Indication of the strongest beam index
The strongest beam’s RSRP
Bitmap to indicate un-omitted beams
Differential RSRPs for uno-omitted beams except the strongest beam
Indication of the number of un-omitted beams


Proposal 4-2: to control feedback overhead and quantization error for NW-side model, set B beam reporting for BM Case-2 consists of 
Indication of the strongest beam index among all measurement occasions
Bitmap to indicate un-omitted/omitted beams
Alt. 1: bitmap size equals to the number of set B beams across measurement  occasions
Alt. 2: bitmap size equals to the number of set B beams at a single measurement occasion
The strongest beam’s RSRP
Differential RSRPs for un-omitted beams except the strongest beam
Indication of the number of un-omitted beams



Proposal 4-3: timeRestrictionForChannelMeasurements or a new IE (timeRestrictionForHistoricChannelMeasurements for example) can be set to a numerical value to ensure NW and UE have the same understanding regarding Tx beam and Rx beam usage.

Proposal 5-1: for Option B, the predicted beams in a CSI report is referred by NW through CSI report configuration ID.

Proposal 6-1: take the following procedure for performance monitoring for AI/ML BM:
NW configures/signals the UE with  and 
Identify the CSI reference resource timing for performance monitoring

For 
Identify up to  measurement instances with the performance monitoring no later than 
Identify up to  prediction instances with the BM inference CSI report
Populate the beam prediction accuracy matrix  according to agreed rule. 
Accumulate beam prediction accuracy: .
Proposal 6-2: semi-static TDD DL/UL patterns are considered in determining the minimal slot offset.

Proposal 7-1: For AI processing criteria and timeline discussion with UE side model, define separate AI processing unit pool(s) dedicated to AI-based processing.  

Proposal 7-2: For AI 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 each use case, and maximum simultaneous AI processing per CC and all CC for all use cases. 

Proposal 7-3: For AI inferencing operation with UE side model, the NW should configure the AI- related use cases within the constraint of total AI processing units and the constraint of each AI use case processing units.

Proposal 7-4: Define different states for AI model based on the required time to start inference. 
De-activated state: This is the state where more than 10ms is required to begin inference. 
Activated state: This state corresponds to the scenario where inference can start within ms level delay. 
Inference state: In this state, the UE is actively performing inference. 

Proposal 7-5: Reuse the applicability report procedure for transitioning from the de-activated state to the activated state.  

Proposal 7-6: Define UE capability for additional processing delays when AI functionalities switch between the activated state and the inference state. 

Proposal 7-7: Additional processing time X1 between transition from “activated state” to “inference state” can be added to Z1/Z2/Z3 and Z1’/Z2’/Z3’ during AI functionalities switch/different CSI reports.

Proposal 7-8: Depending on the AI based use case, AI processing criterion and CPU criterion can be applied together or separately. 


Proposal 7-9: A UE is not expected to be configured with an aperiodic CSI trigger state containing more than min(   Reporting Settings for AI/ML BM; where  is reported by UE with capability signaling for example for  AI/ML BM, a UE is not expected to be configured with an aperiodic CSI trigger state containing more than min(   Reporting Settings for AI/ML CSI prediction;   is reported by UE with capability signaling for example for  AI/ML CSI prediction,   is reported by UE with capability signaling for all AI/ML functionalities.
Proposal 7-10: When the required number of APUs to update CSI reports for AI/ML beam prediction exceeds the number of APUs a UE reported for AI/ML beam prediction, only the high priority AI/ML beam prediction reports are updated. 

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

Agenda item:	9.1.1
Source: 	Qualcomm Incorporated
Title: 	Specification support for AI-ML-based beam management
Document for:	Discussion and Decision

Conclusions
In this paper, we discussed signalling aspects related to beam prediction use case and made the following proposals and observation:

Proposal 1: For beam prediction for UE-side AI/ML models, consider the following aspects to ensure consistency between training and inference regarding NW-side additional conditions (with regards to Set A, Set B consistency) for inference at UE 
Order/indexing consistency: consistency in ordering of resources (e.g., resource index consistency) for Set B beams and Set A beams, across training and inference.
Beam shape consistency: For each Set A resource, the difference between pointing direction and beamwidth of the physical beam associated with that Set A resource during training compared to pointing direction and beamwidth of the physical beam associated with that same Set A resource during inference should be under predefined tolerances. Similarly, for each Set B resource, the difference between pointing direction and beamwidth of the physical beam associated with that Set B resource during training compared to pointing direction and beamwidth of the physical beam associated with that same Set B resource during inference should be under predefined tolerances.  

Proposal 2: For UE-side beam prediction, for the consistency of NW-side additional conditions across training and inference, with regards to FFS on how to define similar properties of a DL Tx beam or beam set/list for the same associated ID:
Based on spatial Tx filter: For the same associated ID across training and inference, for each Set A resource, UE can assume that the same spatial TX filter has been utilized by gNB, across training and inference. Similarly, for each Set B resource, UE can assume that the same spatial TX filter has been utilized by gNB, across training and inference.
Note: a certain tolerance level can be considered for the spatial TX filter used in inference versus training.
Based on QCL relationship: For the same associated ID across training and inference, for each Set A resource, UE can assume that the gNB Tx beams used across training and inference have a certain QCL relationship. Similarly, for each Set B resource, UE can assume that the gNB Tx beams used across training and inference have a certain QCL relationship.
FFS: definition of such QCL relationships.

Observation 1: For UE-side beam prediction, for the consistency of NW-side additional condition across training and inference, ensuring consistency based on performance monitoring is not feasible, because of the following reasons:
Extra burden at the UE for monitoring before the functionality is activated for inference
Note that UE has to monitor the performance of a significantly large number of models to determine the best model for current network-side additional conditions.
Monitoring-based model selection needs to be performed every time network side additional condition changes. Furthermore, the network may be required to signal to the UE when network-side additional conditions change.  
Will always be a hit/fail method
UE cannot determine with certainty the consistency, as without the information about the network-side additional condition, the UE may not be able to download the relevant models
Note that UE may only have limited memory to store the models. It may require frequent download/discard of the model to support monitoring-based consistency.
UE may need to monitor the performance for a significantly large amount of time before UE can determine a suitable model. This will result in a significant delay in determining applicable functionality at the UE.  

Proposal 3: For UE-side beam prediction, for the consistency of NW-side additional condition across training and inference, deprioritize Opt2: Performance monitoring based.

Proposal 4: For UE-side beam prediction, for the consistency of NW-side additional condition across training and inference, the NW-side additional conditions with the same associated ID should be consistent within a PLMN.

Proposal 5: For UE-side beam prediction, for content in the report of inference results, support UE indication of invalid/inaccurate prediction results as part of the inference report. This invalid/inaccurate indication is applicable to the whole content of the inference report.

Proposal 6: For UE-assisted performance monitoring, when the size of the set for monitoring is smaller than the size of Set A, indicate the spatial domain mapping of each resource in the set for monitoring to one resource in Set A in the following manner:
Each resource with a given entry-ID in the resource set for monitoring is further signalled with an identifier, in which the identifier is the entry-ID of the corresponding resource in Set A.
Different such mappings can be signalled for different subsets of Set A for monitoring.
Such mapping can be signalled via RRC.

Proposal 7: For the following working assumption:


Support introducing a threshold X = {4,8} for the minimal slot offset, which should be configured by RRC. UE does not expect the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the CSI reference resource of the corresponding inference report to be larger than X.
If the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the CSI reference resource of the corresponding inference report is smaller than X, then UE should incorporate the computed value for that occasion in the computation of the overall performance monitoring metric.
If the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the CSI reference resource of the corresponding inference report is larger than X, then UE should NOT incorporate the computed value for that occasion in the computation of the overall performance monitoring metric.

Proposal 8: For the following working assumption:


Regarding the FFS, support introducing a threshold X = {4,8} for the minimal slot offset, which should be configured by RRC. UE does not expect the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the f-th time instance for prediction to be larger than X.
If the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the f-th time instance for prediction is smaller than X, then UE should incorporate the computed value for that occasion in the computation of the overall performance monitoring metric.
If the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the f-th time instance for prediction is larger than X, then UE should NOT incorporate the computed value for that occasion in the computation of the overall performance monitoring metric.

Proposal 9: Define performance monitoring metric as , in which
 is configured in the CSI-ReportConfig as the number of linked monitoring instances. For linked monitoring instances, the time offset between the transmission occasion of the CSI-RS/SSB resources for monitoring and the CSI reference resource of the corresponding inference report for spatial beam prediction (or the f-th time instance for prediction for temporal beam prediction) or is smaller than X number of slots, where X is configured by RRC.
 is the number of linked monitoring instances that meet the agreed monitoring criterion among N linked pair(s). 
The size of the CSI field is  for , and is 4 for .

Proposal 10: For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, support
Option 2: only legacy CPU is occupied,  it is reported by UE.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
And  
Note: The supported option by UE is reported by UE capability

Proposal 11: To address whether the total number of use case specific dedicated AI/ML PU should be reported by UE, support the following:
The total number of AI/ML PU () must be shared among AI/ML-based CSI processing use cases, and therefore, there should not be separate AI/ML PU pools per AI/ML use case.

Proposal 12: Regarding UE reporting of  and  for processing of AI/ML-enabled CSI reports, support the reporting of  and  values via UE capability. The  and  values should be indicated per use case (per FG for spatial and temporal beam prediction FGs).

Proposal 13: For BM-Case1, regarding CPU occupation duration for AI/ML-enabled CSI reports for the case in which only legacy CPU is occupied, reuse the occupation duration for legacy P/SP/AP reports, when reportQuantity is not set to ‘none’.

Proposal 14: For BM-Case2, regarding CPU occupation duration for AI/ML-enabled CSI reports for the case in which only legacy CPU is occupied, the CPUs are occupied as follows
Set B measurement occasions except for the latest one (no later than CSI reference resource for the inference report): CPUs are occupied from the first symbol of the earliest one of each transmission occasion of Set B RSs (CSI-RS/SSB resource for channel measurement) until  symbols after the last symbol of the latest Set B RSs (CSI-RS /SSB resource for channel measurement) for L1-RSRP computation, for each of the  transmission occasions before the latest transmission occasion no later than the CSI reference resource for inference report (similar to legacy behavior when reportQuantity is set to none and trs-info not configured for the CMR set) 
Latest Set B measurement occasion (no later than CSI reference resource for the inference report), and inference report: CPUs are occupied from 1st symbol of the earliest one of each Set B (CSI-RS/SSB) resource associated with a CSI-ReportConfig, on the latest Set B occasion no later than the corresponding CSI reference resource, until the last symbol of the configured PUSCH/PUCCH carrying the inference report.
and  is reported via UE capability.

Proposal 15: For BM-Case1, regarding CPU and APU occupation duration for AI/ML-enabled CSI reports for the case in which both legacy CPU and APU are occupied, reuse the occupation duration for legacy P/SP/AP reports when reportQuantity is not set to ‘none’, for both CPU and APU occupation duration.

Proposal 16: For BM-Case2, regarding CPU occupation duration for AI/ML-enabled CSI reports for the case in which both legacy CPU and APU are occupied, the CPUs are occupied as follows (same as CPU occupation duration for Proposal 14)
Set B measurement occasions except for the latest one (no later than CSI reference resource for the inference report): CPUs are occupied from the first symbol of the earliest one of each transmission occasion of Set B RSs (CSI-RS/SSB resource for channel measurement) until  symbols after the last symbol of the latest Set B RSs (CSI-RS /SSB resource for channel measurement) for L1-RSRP computation, for each of the  transmission occasions before the latest transmission occasion no later than the CSI reference resource for inference report (similar to legacy behavior when reportQuantity is set to none and trs-info not configured for the CMR set) 
Latest Set B measurement occasion (no later than CSI reference resource for the inference report), and inference report: CPUs are occupied from 1st symbol of the earliest one of each Set B (CSI-RS/SSB) resource associated with a CSI-ReportConfig, on the latest Set B occasion no later than the corresponding CSI reference resource, until the last symbol of the configured PUSCH/PUCCH carrying the inference report.
and  is reported via UE capability.

Proposal 17: For BM-Case2, regarding APU occupation duration for AI/ML-enabled CSI reports for the case in which both legacy CPU and APU are occupied, the APUs are occupied as follows
Latest Set B measurement occasion (no later than CSI reference resource for the inference report), and inference report: APUs are occupied from 1st symbol of the earliest one of each Set B (CSI-RS/SSB) resource associated with a CSI-ReportConfig, on the latest Set B occasion no later than the corresponding CSI reference resource, until the last symbol of the configured PUSCH/PUCCH carrying the inference report.

Proposal 18: For BM-Case1 and BM-Case2, with regards to CPU occupation duration for monitoring RS measurement occasions and AI/ML-based CSI reports for monitoring
Monitoring RS measurement occasions except for the latest one (no later than CSI reference resource for the monitoring report): CPUs are occupied from the first symbol of the earliest one of each transmission occasion of monitoring RSs (CSI-RS/SSB resource for channel measurement) until  symbols after the last symbol of the latest monitoring RSs (CSI-RS /SSB resource for channel measurement) for L1-RSRP computation, for each of the  transmission occasions before the latest transmission occasion no later than the CSI reference resource for monitoring report  (similar to legacy behavior when reportQuantity is set to none and trs-info not configured for the CMR set).
Latest monitoring RS measurement occasion (no later than CSI reference resource for monitoring report), and monitoring report: CPUs are occupied from 1st symbol of the earliest one of each monitoring RS (CSI-RS/SSB) resource associated with a CSI-ReportConfig, on the latest monitoring RS occasion no later than the corresponding CSI reference resource, until the last symbol of the configured PUSCH/PUCCH carrying the monitoring report.
Where  is configured in the CSI report for monitoring.

Proposal 19: For BM-Case1 and BM-Case2, with regards to determining the priority rules for AI/ML-enabled CSI reports, use the equation for priority value  (as defined in TS38.214-Sec.5.2.5) and
k = 0 for inference report for spatial and temporal beam prediction.
k = 0 for performance monitoring reports.

Proposal 20: For BM-Case1 and BM-Case2, with regards to timeline requirements for AI/ML-enabled CSI reports, extend the values for  and  to  and , by adding offset values (larger than zero), as follows:



In which {} > 0 are reported via UE capability, and different values for {} > 0 can be reported for spatial and temporal beam prediction feature groups.

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

Source:	Sharp
Title:	Discussions on specification support for beam management
Agenda Item:	9.1.1
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed our views on specification support for beam management and have the following observations and proposals.
Observation 1:	In legacy procedure for TCI state provision, TCI-StateID is provided to a resource set for channel measurement based on the time behaviour of that resource set.
Observation 2:	For set A, which is not actually transmitted by gNB, time behaviour of Set A has neither been discussed nor defined. Providing TCI-stateID for set A would be overly complex and require extensive standardization efforts.
Proposal 1: For the case that the size of a set for monitoring is smaller than the size of Set A, the mapping of the resource in the set for monitoring to one or more resources in Set A is configured via new RRC parameters.
The new RRC parameters as below are introduced to configure which NZP-CSI-RS-ResourceId/SSB-Index of Set A is mapped to each resource in the resource set for monitoring.

Proposal 2: For BM-Case 1 and BM-Case 2 with a UE-sided AI/ML model, for option 2 (UE-assisted performance monitoring), a new report quantity (i.e., prediction accuracy indictor, PAI) for beam prediction accuracy is introduced in the CSI report configuration for monitoring, where , where
 represents a number of linked transmission occasions among the N configured transmission occasions, that meets the performance metric agreed in RAN1#120bis. 
Proposal 3: For BM case 1 with a UE-sided AI/ML model, for option 2 (UE-assisted performance monitoring), in a case that there are two inference reports whose corresponding CSI reference resources have identical minimal slot offset to the CSI-RS/SSB resources for monitoring, the UE determines one of the inference report (either the corresponding CSI reference resource prior to the monitoring occasion or the corresponding CSI reference resource after the monitoring occasion) as the linkage.
Proposal 4: For BM case 1 with a UE-sided AI/ML model, for calculation of metric for monitoring for option 2, measurement result of a transmission occasion of the CSI-RS/SSB resources for monitoring is linked with an inference report, where the CSI reference resource of the corresponding inference report has the minimal slot offset to the transmission occasion of the CSI-RS/SSB resources for monitoring, 
A threshold X for the minimal slot offset is configured in the CSI-report config for monitoring, where the minimal slot offset is larger than X, the transmission occasion for monitoring has no linked inference report.
Proposal 5: For BM case 2 with a UE-sided AI/ML model, for option 2 (UE-assisted performance monitoring), support to configure threshold X by RRC,
when the f-th time instance has the minimal slot offset k to the transmission occasion of the CSI-RS/SSB resources for monitoring, if the minimal slot offset k is no larger than X, the transmission occasion for monitoring is linked with the f-th time instance; otherwise, the transmission occasion for monitoring has no linked time instance.
Proposal 6: For BM case 2 with a UE-sided AI/ML model, for option 2 (UE-assisted performance monitoring), in a case that two f-th time instances for prediction have identical time offset to the transmission occasion of CSI-RS/SSB resource, the UE determines one of the inference report (either the corresponding f-th time instance prior to the monitoring occasion or the corresponding f-th time instance after the monitoring occasion) as the linkage.

Proposal 7: For both UE/NW sided model, for enabling a P2 sweep based on predicted Top-K beams, support
for an AP CSI-RS resource set for channel measurement for AP CSI reporting, NW can, via a MAC CE, dynamically configures K CSI-RS resources out of the AP CSI-RS resource set and indicate the QCL information (TCI-stateID) to the K CSI-RS resources. 
UE shall omit TCI states provided by RRC parameter/DCI for AP CSI-RS resource set.
Notify RAN2 of the new MAC CE that is used to indicate K CSI-RS resources and corresponding TCI state IDs for AP CSI-RS resources.
Proposal 8: For UE-side model, at least for BM-Case 1, for content in the report of inference results, support 
Opt 3: beam information on predicted Top K beams among a set of beams and probability related information of predicted Top K beam(s) among a set of beams.
The probability information is the probability of the predicted beam to be the Top 1 beam
The quantization step size and corresponding values for the probability information can be configurable by the gNB.

Proposal 9: For NW-side model, for inference report, at least for BM-Case 1, support configuring more than 4 measurement results (e.g., L1-RSRP) in one CSI report as a UE capability.
Observation 3: For NW-side model, for inference report, when the size of the measurement resource set is configured for reporting, except for the largest measured value of L1-RSRP, it is not clear how to identify other differential L1-RSRP values in the report.  
Proposal 10: For NW-side model, for inference report, at least for BM-Case 1, when the size of the measurement resource set is configured for reporting, except for the largest measured value of L1-RSRP, the order of differential L1-RSRP values in the report can be based on the ascending order of beam index.
Proposal 11: For NW-side model, for inference report, at least for BM-Case 1, beam information of Top M beam(s) in a beam report support: 
Option 1: legacy M CRI/SSBRI fields where the M CRI/SSBRI fields indicate Top M beams. 
Option 2: a legacy CRI/SSBRI field and a bitmap where one CRI/SSBRI filed indicates a beam index with largest measured L1-RSRP value and the bitmap indicates remaining M-1 beams. 
The choice between option 1 and option 2 can be configured by gNB.
Proposal 12: For NW-side model, for BM-Case 2, support to report measurement results from multiple past time instances in a single CSI report configuration. 
Differential L1-RSRP reporting over multiple time instances is used.
The number of multiple past time instances can be configured by the network. 
The number of Top M beam to be reported per time instances is configured by network.
L1-RSRPs and corresponding beam information of up to M beams within X dB gap to the largest measured value of L1-RSRP is considered.

Proposal 13: For UE-side model for BM Case 2, the CPU(s) are occupied from the first symbol of the earliest CSI-RS/SSB occasion within the measurement window until the last symbol of PUCCH/PUSCH carrying the report.
Proposal 14: The existing CSI priority rule is updated with k=1 or k=2 for AI/ML based CSI report.
Proposal 15: For BM Case 2, support indication of multiple TCI states to corresponding to multiple future time instances.
Proposal 16: For model inference, only CSI-RS resources in Set B are active resources.
Proposal 17: Clarify in Table 5.2.1.4-1 of TS 38.214 for Periodic CSI Reporting that, the UE activates a periodic CSI reporting with reportQuantity-r19 if the periodic CSI reporting is reported as applicable in RRCReconfigurationComplete, otherwise, the periodic CSI reporting with reportQuantity-r19 is not activated.

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

Source:	NTT DOCOMO, INC.
Title:	Discussion on AI/ML for beam management
Agenda Item:	9.1.1
Document for: 	Discussion and Decision

Conclusion
In this contribution, the following observations and proposals are made, 
Observation 1: No spec impact should be expected regarding NW operation restriction due to non-applicability reported in Step 5. 
Observation 2: Enhancements on data collection for NW side beam prediction can be reused for NW-side performance monitoring of UE side beam prediction. 
Proposal 1: For only certain UE with the capability, consider performance monitoring based approach for consistency alignment across training and inference due to the UE burden brought by performance monitoring. 
Proposal 2: Occupied CPU for UE side data collection should be 0. 
Proposal 3: Support only one option for processing unit calculation of inference in AI-based CSI reporting.
Proposal 4: Support Option 3 (both dedicated AI/ML PU and legacy CPU are occupied) for processing of CSI reporting for inference. 
Proposal 5: Reuse the legacy CPU occupation duration for CPU and AI/ML PU occupation time for P/SP/AP inference reporting in BM-Case1.
Proposal 6: Support the following CPU and AI/ML PU occupation time for BM-Case2.
For AP inference reporting, the same occupation time as legacy CPU.
For P/SP inference reporting, CPU and AI/ML PU occupies the following duration 
for the last transmission occasion no later than CSI reference resource, the occupied duration is from the first symbol of P/SP CSI-RS to the last symbol of CSI reporting
for the remaining -th transmission occasion no later than CSI reference resource, the occupied duration is from the first symbol of P/SP CSI-RS until  symbols after the last symbol of transmission occasion
Proposal 7: Up to only one resource set can be configured in resourceConfig for Set B, when Set B is not a subset of Set A.
Proposal 8: Not support type 2 performance monitoring.
Proposal 9: Introduce a new RRC parameter representing the paired Set A resource for each monitoring resource.
Proposal 10: Support Alt 3 as the performance metrics to check the accuracy of predicted RSRP value in the actual field.
Proposal 11: No need to support Alt 2 as the performance metrics, as Alt 1 is already supported for the same purpose.
Proposal 12: Bit field for the performance accuracy indicator should be ⌈⌉.
Proposal 13: Introduce a threshold X for the minimal slot offset between CSI reference resource of inference report and transmission occasion of paired monitoring resource, where X is determined based on UE capability. 
Proposal 14: Support the following triggering mechanism of UE-assisted performance monitoring. 
Based on NW configuration/indication
When performance metric satisfies some conditions, such as larger/lower than thresholds
Proposal 15: Support the following solution to enable P2 beam sweeping of predicted top-K beam
・NW configures all Set A measurement resources, and UE is expected to measure only predicted top-K beams after each inference result.
Proposal 16: Consider overhead reduction for more than 4 beam related information in L1 signaling. 
Large quantization step size for Set B measurement reporting
Reporting measurements from multiple time instances in one reporting instance. 
Proposal 17: Do not include the NW operation purpose in RRC parameter name/description. 

TDoc file reading error

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

Agenda Item:	9.1.1
Source:	Fraunhofer HHI, Fraunhofer IIS 
Title:	Specification support for beam management
Document for:	Discussion & Decision

Conclusion
In this contribution, we have the following proposals:
Proposal 1: For monitoring UE-sided models, support 2-phase monitoring with varying frequencies and reporting detail.
Proposal 2: Consider indication-based and event-based switching into a validation phase. Events may be defined based on agreed performance metrics.
Proposal 3: For the activation of monitoring, support Event-1, Event-4 and Event-5.
Proposal 4: For the configuration of set A and set B of beams for UE-side BM-Case1, the relationship in use-cases where set B of beams is a subset of set A of beams shall be exploited for overhead reduction of CSI resource and/or report configuration. 
Proposal 5: Explore the possibility of using the resources configured for radio link monitoring for model monitoring purposes with respect to CSI beam reporting. 
Proposal 6: Support a model monitoring configuration that allows for collecting data for model training and monitoring of inactive models.
Proposal 7: Study the support for radio link monitoring and link recovery procedures considering spatial and temporal beam prediction at the UE-side. 
Proposal 8: At least for BM-Case 1, for UE-side models, adopt a ranking of beam information in the inference report based on the Top-K outputs from the AI/ML model.
Proposal 9: For BM-Case2, for UE-sided models, introduce a configuration that allows the exclusion of certain past measurements for the inference.
Proposal 10: For UE-sided models, consider a shared CPU pool or a dedicated ACPU pool with a constant occupation for each CSI reporting instance.
Proposal 11: For UE-sided models, for CPU occupation Option 3, support only a total number of APUs that are shared by all AI/ML use cases.
Proposal 12: For UE-sided models, for inference, support the UE reporting its inference time to the gNB.
Proposal 13: The use of a predicted beam that is not measured/received by the UE for beam indication is supported. 
Proposal 14: Beam indication for one or more future time instances is not supported. 

3GPP TSG RAN WG1 #121	R1-2504571
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:	9.1.1
Source: 	ASUSTeK
Title:  	Discussion on AIML based beam management
Document for:	Discussion and Decision

Conclusion
In this contribution, we have following proposals:
Observation 1: Due to linkage between monitoring and inference, if there is problem when generating an inference report resulting in no inference report, how UE generates a linked monitoring report needs to be specified. 
Proposal 1: RAN1 discuss the issue that when there is no inference report transmitted before the CSI reference timing associated with a monitoring report, how UE generates the monitoring report.
Proposal 2: Based on a determined BAI, RAN1 decides whether/how to report information of the determined BAI in a monitoring report based on index of quantization range.
Proposal 3: For BM case-2, when reporting one beam prediction accuracy, NOT support to configure more than one time instances via a bit-map.
Proposal 4: For BM case-2, UE counts a pair of one configured time instance (i.e., f-th in one inference report) and transmission occasion of monitoring resource as one latest N if the one inference report is transmitted and performing reception on the one the transmission occasion of monitoring resource.
Proposal 5: For BM case-2, when reporting more than one beam prediction accuracy, support to configure more than one time instances via a bit-map.
Proposal 6: For BM case-2, when reporting more than one beam prediction accuracy, a resource set configured in CSI-ReportConfig for performance monitoring is enhanced such that each of more than one time instances maps to one occasion of the resource set
Observation 2: In TS 38.331, CSI-ResourceConfig comprises a BWP ID to indicate RS set configured by CSI-ResourceConfig belongs to which BWP, however, it’s not clear whether to support set A and set B configured in different BWP.
Proposal 7: Set A and set B configured in CSI-ReportConfig for inference should be configured in same BWP
Observation 3: For an AI/ML model, for BM-case2 (i.e., temporal prediction), insufficient time instance of set B will result in low confidence when generating an inference report.
Proposal 8: When generating an inference report with low confidence, RAN1 discuss how/whether UE inform gNB or drop the inference report
Observation 4: One benefit of AI/ML based beam management is to have lower signalling overhead in temporal domain. How to skip a subset of time instance of set B to achieve signalling overhead reduction needs further design. 
Proposal 9: RAN1 confirms that signalling overhead for CSI-RS (i.e., set B) reduction in temporal domain is needed for BM case-2.
Proposal 10: RAN1 study whether/how to leverage monitoring pattern of set B or monitoring window to skip a subset of time instances of set B. 

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

Agenda item:	9.1.1
Source: 	National Taiwan University
Title: 	On Performance Monitoring for Beam Management Use Case
Document for:	Approval

Conclusion
Proposal 1: Add signaling for the network to request measurement report from (a subset of) beams in Set B as the additional information to decide the monitoring resources.

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

Agenda Item:	9.1.1
Source: 	ITL
Title: 	Specification support for AI/ML beam management
Document for:	Discussion and decision

Conclusion
In this section, we summarize our proposals and observation on support for AI/ML beam management as follows:
Proposal 1: For NW-side AI/ML model inference, it can be additionally supported to configure reporting of up to M beams within X dB gap of the strongest beam, where X and M are configured by gNB.
Proposal 2: For NW-side model inference, the maximum number of NZP CSI-RS resources per resource set (maxNrofNZP-CSI-RS-ResourcesPerSet) may be configured up to 256. In addition, the value of M of reported beam (e.g., up to 64) included in a single report may be configured by the network based on UE capability signaling. 
Proposal 3: For network-side AI/ML model inference, when beam reporting involves more than four beams, it is preferred that the report includes M CRI/SSBRI values from a measurement resource set without additional optimization (e.g. overhead reduction).
Proposal 4: It is recommended to increase the quantization step size beyond what is currently supported in legacy L1-RSRP quantization.
Proposal 5: For beam/TCI indication, consider using Set B beams of which UE can measure and maintain it Rx beam for P-3, if the gNB directs a beam within Set A that is unknown to the UE as the TCI state.
Proposal 6: For beam/TCI indication of BM-Case2(NW side model), consider extending the existing TCI direction method to multiple beams with the associated timestamp information for future time N instances.
Proposal 7: For the network-side model, support a CSI report that includes measurement results for each of the N > 1 most recent transmission occasions, each occurring no later than the CSI reference resource corresponding to the report.
N is configured in the associated CSI-ReportConfig via RRC, subject to UE capability.
Reuse the same report format (i.e., CSI field mapping order) as in BM-Case 2 for UE-side model inference, in the case of Option 2, by replacing “time instance” with “transmission occasion.”
Proposal 8: For data collection purpose without CSI report, it can be optionally configured a CSI-ReportConfig with reportQuantity set to ‘none’.
Proposal 9: It can be considered the reporting the preferred DL RS configurations for the data collection for UE side when requesting training via UE signalling.
Proposal 10: For UE-sided model, at least for BM-Case 1, in CSI-ReportConfig for aperiodic inference report, 
when set B is a subset of Set A, one associated ID for Set B is applied for all the set B configured in resourceConfig
when set B is NOT a subset of set A, 
Support: the resourceConfig for set B only include a single resourceSet.
Proposal 11: It is not necessary to further enhance AP CSI reporting with AP CSI-RS for inference of BM Case 2 in UE sided model.
Proposal 12: For report content of inference results for UE-sided model for BM-Case 1, it can be supported that beam information on predicted Top K beam(s) among a set of beams and probability related information of predicted Top K beam(s) among a set of beams.
FFS on overhead reduction on the probability information
Proposal 13: It is proposed to support that the predicted Top-K beam(s) refer to either (i) the K beams with the highest predicted RSRP values, or (ii) the K beams with the highest probabilities of being the Top-1 beam among those in Set A.
Proposal 14: It is proposed that the ranking information of the predicted Top K beams for K > 1 is conveyed by the order of the beam information for UE sided model at least for BM Case 1.
Proposal 15: For BM-Case 2, it is beneficial to extend the legacy TCI state indication signaling scheme to indicate multiple TCI states which are corresponding to N future time instances.
Proposal 16: There is no strong necessity to further define similar properties of a DL Tx beam or beam set/list regarding UE assumption on NW-side additional conditions for inference at UE.
Proposal 17: For BM-Case1 and BM-Case2 with a UE-side AI/ML model, for Type 1 performance monitoring Option 1 (NW-side performance monitoring), L1 signalling can be used to send the measurement results to NW for the calculation of performance metrics at NW.
Proposal 18: It is supportive to introduce the new quantity (BAI) for beam prediction accuracy in CSI report for monitoring in above proposal.
Proposal 19: It is proposed to support event-triggered UE reporting for UE-sided Type 1 performance monitoring.
Proposal 20: It seems there is no clear motivation to support Type 2 performance monitoring.

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

Agenda item:	9.1.1
Source:	Samsung (Moderator)
Title:	FL summary #0 for AI/ML in beam management
Document for:	Discussion and Decision

Conclusion
For UE-sided model, for BM-Case 2, for inference, AP CSI-RS for Set B is not supported. 

Agreement
For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, considering the following options for potential down selection: 
Option 1: only dedicated AI/ML PU is occupied,  is reported by UE.
And 
Option 2: only legacy CPU is occupied,  it is reported by UE.
Option 3: both dedicated AI/ML PU and legacy CPU are occupied,  is reported by UE.
And  
Note: The supported option 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. 

Working Assumption
For BM-Case 2, at least support to report one beam prediction accuracy for one configured time instance, configured by one CSI-ReportConfig for monitoring, 
only one resource set is configured in the CSI-ReportConfig
the one configured time instance (i.e. f-th time instance of the time instance in one inference report) for metric calculation is configured in the CSI-ReportConfig for monitoring 
FFS on whether to configure more than one time instance
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
N (N>=1) is configured in the CSI-ReportConfig
FFS on additional rule for counting N linked pair
measurement result of a transmission occasion of the CSI-RS/SSB 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/SSB resources for monitoring. 
Wherein, the corresponding inference reports, and the transmission occasions of the CSI-RS/SSB resources for monitoring, [FFS on the f-th time instances] are no later than the CSI reference resource corresponding to the CSI report for monitoring
FFS: whether to introduce a threshold X, and whether it is optionally configured by RRC, where the minimal slot offset k is no larger than X; otherwise, the transmission occasion for monitoring has no linked time instance 

12 Previous agreements ordered in topic

12.1 UE-sided model
12.1.0 Consistency and applicability
12.1.1 Data collection
12.1.1.1 Configuration

 12.1.2 Model inference
12.1.2.1 Configuration
BM-Case 2 specific
12.1.2.2 Inference report
BM Case 2 specific
12.1.3 Performance monitoring
12.1.3.1 Configuration
12.1.3.2 Monitoring report
12.1.4 Others
12.1.4.1 CPU counting
12.1.4.2 others
12.2 NW-sided model 
12.2.1 Data collection
12.2.1.1 Configuration
12.2.1.2 Content
12.2.2 Model inference
12.2.2.1 Configuration
12.2.2.2 Inference report
 
 
 12.2.3 Performance monitoring
 12.2.3.1 Configuration
12.2.3.2 Monitoring report
12.2.4 Others
12.2.4.1 beam indication

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

Agenda item:	9.1.1
Source:	Samsung (Moderator)
Title:	FL summary #0 for AI/ML in beam management
Document for:	Discussion and Decision

Conclusion
For NW sided model for L1-RSRP report in L1 signaling, legacy quantization steps and range are reused. 
Agreement 
For the determination of CSI report priority value of a CSI report for inference, the existing  is reused
k = 0 for the CSI report for inference
For the determination of CSI report priority value of a CSI report for monitoring, the existing  is reused
k = 0 for the CSI report for monitoring

12 Previous agreements ordered in topic

12.1 UE-sided model
12.1.0 Consistency and applicability
12.1.1 Data collection
12.1.1.1 Configuration

 12.1.2 Model inference
12.1.2.1 Configuration
BM-Case 2 specific
12.1.2.2 Inference report
BM Case 2 specific
12.1.3 Performance monitoring
12.1.3.1 Configuration
12.1.3.2 Monitoring report
12.1.4 Others
12.1.4.1 CPU counting
12.1.4.2 others
12.2 NW-sided model 
12.2.1 Data collection
12.2.1.1 Configuration
12.2.1.2 Content
12.2.2 Model inference
12.2.2.1 Configuration
12.2.2.2 Inference report
 
 
 12.2.3 Performance monitoring
 12.2.3.1 Configuration
12.2.3.2 Monitoring report
12.2.4 Others
12.2.4.1 beam indication

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

Agenda item:	9.1.1
Source:	Samsung (Moderator)
Title:	FL summary #2 for AI/ML in beam management
Document for:	Discussion and Decision

Conclusion
For NW sided model for L1-RSRP report in L1 signaling, legacy quantization steps and range are reused. 
Agreement 
For the determination of CSI report priority value of a CSI report for inference, the existing  is reused
k = 0 for the CSI report for inference
For the determination of CSI report priority value of a CSI report for monitoring, the existing  is reused
k = 0 for the CSI report for monitoring

Agreement
For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, 
For PU occupancy, for the number of AI/ML PU (OAPU) and/or legacy CPU (OCPU) are occupied, 
OAPU= 0 or X1/X2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively
OCPU=0 or Y1/Y2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively
Note: Detailed values of X1/X2 and Y1/Y2 can be further discussed in UE feature.
Note: Combination of OAPU= 0 and OCPU=0 is not allowed
Note: if any of the unoccupied PU cannot satisfy the corresponding required PU by the CSI report, the CSI report will follow the legacy behavior of exceeding the CPU limit, neither of the PUs are occupied

Agreement
For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case1 and BM-Case 2, when applicable, extend legacy Z3/Z3’ to Z3+d / Z3’+d’, where d and d’ are reported by UE per SCS for BM-Case 1 and BM-Case 2 respectively
Detailed values of d and d’ can be further discussed in UE feature.
Agreement
For UE-sided model, regarding a CSI-ReportConfig for data collection, 
Reuse the existing CPU occupation time for a CSI report with CSI-ReportConfig with reportQuantity set to 'none' and TRS-info not configured

Agreement
For NW-sided model, for inference, when M

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

Agenda item:	9.1.1
Source:	Samsung (Moderator)
Title:	FL summary #3 for AI/ML in beam management	
Document for:	Discussion and Decision

Conclusion
For NW sided model for L1-RSRP report in L1 signaling, legacy quantization steps and range are reused. 
Agreement 
For the determination of CSI report priority value of a CSI report for inference, the existing  is reused
k = 0 for the CSI report for inference
For the determination of CSI report priority value of a CSI report for monitoring, the existing  is reused
k = 0 for the CSI report for monitoring

Agreement
For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, 
For PU occupancy, for the number of AI/ML PU (OAPU) and/or legacy CPU (OCPU) are occupied, 
OAPU= 0 or X1/X2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively
OCPU=0 or Y1/Y2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively
Note: Detailed values of X1/X2 and Y1/Y2 can be further discussed in UE feature.
Note: Combination of OAPU= 0 and OCPU=0 is not allowed
Note: if any of the unoccupied PU cannot satisfy the corresponding required PU by the CSI report, the CSI report will follow the legacy behavior of exceeding the CPU limit, neither of the PUs are occupied

Agreement
For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case1 and BM-Case 2, when applicable, extend legacy Z3/Z3’ to Z3+d / Z3’+d’, where d and d’ are reported by UE per SCS for BM-Case 1 and BM-Case 2 respectively
Detailed values of d and d’ can be further discussed in UE feature.
Agreement
For UE-sided model, regarding a CSI-ReportConfig for data collection, 
Reuse the existing CPU occupation time for a CSI report with CSI-ReportConfig with reportQuantity set to 'none' and TRS-info not configured

Agreement
For NW-sided model, for inference, when M

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

Agenda item:	9.1.1
Source:	Samsung (Moderator)
Title:	FL summary #4 for AI/ML in beam management	
Document for:	Discussion and Decision

Conclusion
For NW sided model for L1-RSRP report in L1 signaling, legacy quantization steps and range are reused. 
Agreement 
For the determination of CSI report priority value of a CSI report for inference, the existing  is reused
k = 0 for the CSI report for inference
For the determination of CSI report priority value of a CSI report for monitoring, the existing  is reused
k = 0 for the CSI report for monitoring

Agreement
For UE-side model, for AI/ML based beam management for BM-Case 1 and BM-Case 2, for processing of a CSI report for inference, 
For PU occupancy, for the number of AI/ML PU (OAPU) and/or legacy CPU (OCPU) are occupied, 
OAPU= 0 or X1/X2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively
OCPU=0 or Y1/Y2 is reported by UE in UE capability report for BM-Case 1 and BM-Case 2 respectively
Note: Detailed values of X1/X2 and Y1/Y2 can be further discussed in UE feature.
Note: Combination of OAPU= 0 and OCPU=0 is not allowed
Note: if any of the unoccupied PU cannot satisfy the corresponding required PU by the CSI report, the CSI report will follow the legacy behavior of exceeding the CPU limit, neither of the PUs are occupied

Agreement
For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case1 and BM-Case 2, when applicable, extend legacy Z3/Z3’ to Z3+d / Z3’+d’, where d and d’ are reported by UE per SCS for BM-Case 1 and BM-Case 2 respectively
Detailed values of d and d’ can be further discussed in UE feature.
Agreement
For UE-sided model, regarding a CSI-ReportConfig for data collection, 
Reuse the existing CPU occupation time for a CSI report with CSI-ReportConfig with reportQuantity set to 'none' and TRS-info not configured

Agreement
For NW-sided model, for inference, when M 1 is conveyed by the order of the beam information. 

Agreement
For UE-sided model, regarding a CSI report with CSI-ReportConfig for inference for BM-Case2, for occupancy duration of CPU and APU, same occupation time for AI/ML PU and legacy CPU.
If the CSI report is aperiodic, for AI/ML PU, and for CPU, Rel-15 CPU occupation time for AP CSI report is reused 
If the CSI report is semi-persistent or periodic,
From the 1st symbol of the latest CSI-RS/SSB transmission occasion no later than CSI reference resource, until the last symbol of the PUCCH/PUSCH carrying the report.

Agreement
For option B of applicability check, RAN 1 assumes that at least the following RRC parameters are to be reused: 
For both BM-Case 1 and BM-Case 2: 
associatedIDforSetA-r19, resourcesForSetA-r19, resourcesForChannelMeasurement, associatedIDforSetB-r19, reportQuantity-r19, reportConfigType, nrofreportedpredictedrs-r19
For BM-Case 2: 
TimeGap-r19, nroftimeinstance-r19,
  Note: this doesn’t imply the associated ID is always present

12 Previous agreements ordered in topic
12.1 UE-sided model
12.1.0 Consistency and applicability
12.1.1 Data collection
12.1.1.1 Configuration

 12.1.2 Model inference
12.1.2.1 Configuration
BM-Case 2 specific
12.1.2.2 Inference report
BM Case 2 specific
12.1.3 Performance monitoring
12.1.3.1 Configuration
12.1.3.2 Monitoring report
12.1.4 Others
12.1.4.1 CPU counting
12.1.4.2 others
12.2 NW-sided model 
12.2.1 Data collection
12.2.1.1 Configuration
12.2.1.2 Content
12.2.2 Model inference
12.2.2.1 Configuration
12.2.2.2 Inference report
 
 
12.2.3 Others
12.2.3.1 beam indication