TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130		R2-2503399
St Julian’s, Malta, 19th – 23rd, May 2025

Source:	vivo
Title:		Discussion on LCM for UE-sided model for Beam Management
Agenda Item:	8.1.2.2
Document for:	Discussion and Decision

Conclusion
In the contribution, we have the following observations and proposals:
Open issue RRC-9: Definition of ‘applicable AI/ML functionality’
Adopt the following definition of “AI/ML functionality” in RAN2 specifications: 
AI/ML functionality: Inference configuration or a set of inference related parameters.
Open issue RRC-8: Coexistence between option A and option B 
An indicator associated with configured full inference configuration is introduced to indicate whether to feedback the applicability report for the full inference configuration.
For option B, introduce the set ID for a set of inference related parameters, which is separate from CSI-ReportConfigId. The following ASN.1 is considered as the baseline:
ApplicabilityReportConfigId	::=    CHOICE {
	csi-ReportConfigId 	CSI-ReportConfigId,			-- for option A
	setId 				InferenceParameterSetId		-- for option B
}
InferenceParameterSetId ::=          INTEGER (0..maxNrofInferenceParameterSet-1)
maxNrofInferenceParameterSet-1       INTEGER ::= FFS      -- Maximum number of inference parameter sets minus 1
Option A and option B can be configured simultaneously in a single RRCReconfiguration message.
Open issue RRC-16: UE behaviour when the associated ID is not provided by the network
Wait for RAN1’s conclusion about whether associated ID in Step 3 is mandatory or optional.
Open issue RRC-4: Activation of a periodic CSI report configuration upon change from inapplicable to applicable
In case that configured full inference configuration with periodic CSI-report is non-applicable, it is up to network implementation whether to immediately release it or keep monitoring the applicability of the periodic CSI-report.
When configured full inference configuration with periodic CSI-report becomes applicable from non-applicable, the UE sends the updated applicability reporting to the network.
When configured full inference configuration with periodic CSI-report becomes applicable from non-applicable, RAN2 to discuss the following three potential alternatives:
Alt 1: The UE autonomously activates the periodic CSI-report when becoming applicable from non-applicable;
Alt 2: The network activates the periodic CSI-report via an MAC CE;
Alt 3: The network activates the periodic CSI-report by reconfiguring the periodic CSI-report with the same CSI-report ID.
Open Issue RRC-5: Reporting behaviour of inapplicable periodic beam prediction configuration
When activated full inference configuration with periodic CSI-report becomes non-applicable, the UE sends the updated applicability reporting to the network. The UE continues to perform the inference and reporting until receiving the release of inference configuration.
Open issue RRC-6: Handling of inference, applicability reporting and UE data collection preference configurations
During RRC state transition, handover and RRCReestablishment,  the handling of inference configurations, applicability configurations and UE data collection preference configuration follows the legacy handling for CSI-MeasConfig and otherConfig.
Open issue RRC-7: Applicability reporting for option B in RRCReconfigurationComplete
For option B, with the assumption that UE receives RRCReconfiguration message including one set or multiple sets of inference related parameters via OtherConfig, the UE feedbacks the applicability reporting via a UAI message upon receiving one set or multiple sets of inference related parameters.
Open issue RRC-2: Content of otherConfig for enabling applicability reports in UAI
The allowance of applicability reporting for applicability status change of inference configuration is configured per UE, i.e., 1 bit is sufficient.
Open issue RRC-1: Cause of inapplicability
The simple cause value of inapplicability is 1 bit, which is used to indicate whether there is an available model.
Open issue RRC-3: UE data collection request
The candidate measurement configurations, if provided by the network, are associated with configuration indexes, and the UE can indicate the index of preferred configuration or the detailed measurement configuration in the data collection configuration request.
LS to RAN1 to inform the RAN2’s agreements about candidate measurement configurations, and ask RAN1 to provide the detailed parameters for candidate measurement configuration.
Open issue RRC-13: CSI prediction LCM framework
Observation: In the existing specification, beam management and CSI report uses the same configuration framework, i.e., CSI-MeasConfig.
RAN2 assumes that all the LCM related RAN2 agreements for UE-sided model of beam management use case are applied to the CSI prediction use case. The exceptions, if identified, can be further discussed.

3GPP TSG RAN WG2 Meeting #130         	                          R2-2503449
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.1.2.2
Source:	Xiaomi
Title:	Discussion on open issues of AI/ML air LCM
Document for:	Discussion and Decision

Conclusion
In this contribution, we further discuss the remaining open issues of AI air LCM, with following proposals and observations:
Applicability Configuration/Reporting/Cause Value
Proposal 1: (RRC-7) Upon receiving configurations from Option B, same as Option A, UE sends the initial applicability report in RRCReconfigurationComplete. UAI is used to send updated functionality applicability.
Proposal 2: (RRC-1) UE reports non-applicability cause as ‘model is not available’, optionally with when (how long) model will be available.
Co-existence/Association between Option A and Option B (RRC-8)
Proposal 3: (RRC-8) Applicability determination procedure includes both Option A and Option B. Network can provide applicabilityReportConfig for Option A and/or Option B. Co-existence of Option A (via CSI-ReportConfig) and Option B (via OtherConfig) in same RRCReconfiguration message is supported. 
Observation 1: If UE only reports initial applicability reporting via RRCReconfigurationComplete but not allowed to report updates via UAI, network may wrongly activates non-applicable functionalities (initailly applicable becomes non-applicable) at UE-side.
Proposal 4: UE is allowed to report initial and updated applicability reporting consistently, that is:
if applicabilityReportConfig is set to setup, UE considers itself to be configured to report applicability information of configurations subject to the applicability determination procedure via RRCReconfigurationComplete and UAI;
else, UE considers itself not to be configured to report applicability information of configurations subject to the applicability determination procedure via either RRCReconfigurationComplete or UAI;
Proposal 5: Introduce applicability report configuration ID inside ApplicabilityReportConfig.
Proposal 6: (RRC-8) To support coexistence between Option A and Option B:
During configuration, under applicableReportConfigId, network includes CSI-ReportConfigId(s) of Option A for that applicableReportConfigId, and/or inference related parameters of Option B that are associated with applicability report configuration ID. 
During reporting, UE reports the applicable/non-applicable report configuration ID in applicability reporting (via RRCReconfigurationComplete or UAI). UE further includes the applicable/non-applicable CSI-ReportConfigId(s) of Option A and/or whether Option B is applicable or not under each reported configuration ID.
Other open issues
Proposal 7: (RRC-4) If a non-applicable functionality becomes applicable and reported by UE via UAI, network activates periodic CSI reporting via a new MAC CE explicitly. FFS on the detail design of new MAC CE.
Observation 2: (RRC-5) UE can report inapplicability of its functionality immediately, since there’s no prohibit timer for UAI reporting.
Proposal 8: (RRC-5) Upon receiving UAI reporting containing inapplicable functionality, network shall release configuration of the corresponding inapplicable functionality immediately. Network receiving periodic beam prediction after inapplicability reporting will not happen.
Proposal 9: (RRC-6) Same as other RRC configuration, UE keeps all applicability configurations during RRCReesblishment and when UE goes to RRC_INATIVE state. UE releases all applicability configurations when UE goes to RRC_IDLE state.
Proposal 10: (RRC-6) Applicability reporting via RRCReestablishmentComplete and RRCResumeComplete is not supported.
UE data collection request
Proposal 11: (RRC-3) DataCollectionPreferenceConfig (i.e., list of candidate data collection configurations) and UAI reporting of UE data collection request includes:
CSI-ResourceConfigId of Set A
CSI-ResourceConfigId of Set B
One/two associated IDs (up to whether Set B is equal/subset of Set A or not)

3GPP TSG-RAN WG2 #130 meeting																		R2-2503537
St Julian's, Malta, 19th May – 23rd May, 2025

Agenda Item:	8.1.2.2 LCM for UE-sided model for Beam Management use case
Source:	NEC
Title:	Discussion on remaining issue of LCM for UE-sided model
Document for:	Discussion, Decision

Conclusion
In this contribution, we have discussed the remaining issues of LCM for UE-sided model, a brunch of observations and proposals have been listed:
Observation 1	The applicability reported by the UE in Step 4 may be distributed among all provided semi-persistent CSI reports.
Observation 2	The model monitoring accuracy can be improved by repeating multiple times of model monitoring procedure.
-	Dynamic reporting: for each monitoring cycle, as long as UE get the monitoring performance, it should feedback towards network immediately
-	One time reporting: after the model monitoring is accomplished, UE will collect the monitoring result for all monitoring cycles as an ouput set and report towards network.
Observation 3	The pros and cons of dynamic reporting and one time reporting are listed in the below table:

Proposal 1	RAN2 to decide whether an activation / deactivation MAC CE of semi-persistent CSI reporting configuration address to a UE group containing applicable UEs is supported.
Proposal 2	RAN2 to decide whether an activation / deactivation of periodic CSI reporting configuration by MAC CE is supported.
Proposal 3	If model monitor is performed at UE side, RAN2 should define model monitoring cycle with regard to each model inference output.
Proposal 4	If model monitor is performed at UE side, UE should report the performance result towards network for each model monitoring cycle.
Proposal 5	If model monitor is performed at UE side, RAN2 should consider two reporting principles for performance reporting:
Proposal 6	RAN2 should determine which reporting principle should be adopted.

3GPP TSG-RAN WG2 Meeting #130			           		R2-2503539
St.Julians, Malta, May 19th – 23rd, 2025

Agenda item:	8.1.2.2
Source:	Samsung
Title:	Discussion on LCM for UE-sided model for beam management
Document for:	Discussion and Decision

Conclusion
In this document, we discussed some of RRC open issues from RAN2 post email discussion and propose the following points. 
Proposal 1: [Open issue RRC-1] one bit to indicate two values (long term and short term) is introduced for cause of inapplicability. 
Proposal 2: [Open issue RRC-2] for option B, RAN2 wait for RAN1 input on the detailed parameters. 
Proposal 3: [Open issue RRC-2] for option A, one-bit simple indicator to enable applicability reporting is enough. 
Proposal 4: [Open issue RRC-3] UE refers the preferred candidate ID with CSI-ReportConfigId which is included in data collection configuration. 
Proposal 5: [Open issue RRC-4] A new indicator is defined to reactivate periodic CSI report.   
Proposal 6: [Open issue RRC-6] UE releases inference configuration upon transitioning to RRC_IDLE (no specification impact).
Proposal 7: [Open issue RRC-6] UE releases the applicability configurations and UE data collection preference configuration in the following cases: 
Initiation of RRC Resume Procedure.
When RRC Reestablishment is transmitted.
Proposal 8: [Open issue RRC-8] either option A or option B is configured for one UE i.e either option for all configured functionalities. 
Proposal 9: [Open issue RRC-8] option A or option B is implicitly indicated with the presence of a set of inference related parameters in otherConfig. 
Proposal 10: [Open issue RRC-8] in option B, the UE doesn’t send applicability indication for a configured CSI-ReportConfig (i.e. UE sends applicability reporting only for a set of inference related parameters if configured). 
Proposal 11: [Open issue RRC-16] RAN2 agree to support both cell specific ID and multiple cell-specific IDs for associated ID.
Proposal 12: [Open issue RRC-16] RAN2 discuss two options (area specific associated ID and globally unique associated IDs within PLMN) for associated IDs.  

3GPP TSG-RAN WG2 Meeting #130	R2-2503546
St. Julians, Malta,  May 19th – 23rd , 2025

Agenda Item:	8.1.2.2
Source: 	Fujitsu
Title: 	Discussion on LCM for UE-sided Model for Beam Management Use Case
Document for:	Discussion

Conclusion
Proposal 1 For option B configuration, OtherConfig should be used rather than CSI-ReportConfig.
Proposal 2 The simple cause of inapplicability should carry at least the following information: the current functionality needs to be deactivated and replaced immediately.
Observation 1 The details of UE-side BM performance monitoring are still pending further RAN1 conclusions.
Proposal 3 RAN2 starts at least the following discussions while waiting for further RAN1 input.
Mechanism to trigger the performance monitoring procedure.
Potential signaling to complete the performance monitoring procedure.
Proposal 4 The performance monitoring procedure can be triggered either periodically or event based.

3GPP RAN WG2 Meeting #130	R2-2503561
Malta, Malta May 19th – 23rd, 2025             
Agenda item:	8.1.2.2	
Source:	LG Electronics Inc.
Title:	Remaining issues on Functionality based LCM for BM 
Document for:	Discussion and Decision
1. 

Conclusion
Remaining Open issues 
Open issue RRC-1: Cause of inapplicability 
Observation 1. [Open issue RRC-1] It is important to distiguish between cases where the cause information is truly helpful.
Case 1: Temporary inapplicable functionality : since the network is expected to maintain the configuration regardless of the temporary inapplicability, including a cause value provides limited benefit
Case 2: Model is not available: A simple and clear cause value (e.g., release) can assist the network in deciding whether to release the associated configuration.
Proposal 1. [Open issue RRC-1] UE includes a cause value (e.g., release) only when requesting configuration release, e.g., due to model unavailability
Observation 2. [Open issue RRC-1] When there is no reason for inapplicability, reporting both applicable and non-applicable functionalities may be redundant and introduce signalling overhead.
Proposal 2. [Open issue RRC-1] Inapplicable functionalities should only be reported only when specific cause (e.g., release) exist
Open issue RRC-2: Content of otherConfig for enabling applicability reports in UAI 
Proposal 3. [Open issue RRC-2] A simple indication in otherConfig is sufficient to enable applicability reporting via UAI; no additional configuration content is needed
Open issue RRC-3: UE data collection request 
Observation 3. [Open issue RRC-3] To request the UE preferred RS configuration, a similar discussion is ongoing in the context of the applicability report.
Observation 4. [Open issue RRC-3] In Option A, the UE informs the network of applicable configurations among already configured CSI report configurations. The same mechanism could serve as a simple approach to indicate a preferred RS configuration.
Observation 5. [Open issue RRC-3] For training data collection, collecting measurement results for both Set A and Set B is essential to gather input and ground-truth data. In Option B could be a feasible candidate to support UE-initiated requests for preferred CSI-related configurations, including RS resources for data collection
Proposal 4. [Open issue RRC-3] For the UE request configuration, the applicability report mechanism can be re-used
Option A-like mechanism: The network provides a full RS configuration for data collection via CSI-ReportConfig. The UE indicates its preferred RS configuration(s) from among the already configured CSI report configurations.
Option B-like mechanism: The network provides data collection-related parameters via OtherConfig. The UE explicitly indicates a preferred RS configuration. Further RAN1 input is needed to support Option B.
Open issue RRC-4: Activation of a periodic CSI report configuration upon change from inapplicable to applicable
Observation 6. [Open issue RRC-4] If the network de-configures a periodic CSI report configuration after the UE initially reports it as inapplicable, this can prevent future activation of that functionality when it later becomes applicable. Therefore, the network may choose to retain configurations related to inapplicable functionalities, so that the functionality can be re-activated when the UE later reports it as applicable
Proposal 5. [Open issue RRC-4] UE activates a functionality updated as applicable via UAI after confirming that the UAI was successfully transmitted, i.e., upon receiving an acknowledgment from the network
Open Issue RRC-5: Reporting behaviour of inapplicable periodic beam prediction configuration
Proposal 6. [Open issue RRC-5] When a functionality becomes inapplicable, the UE reports measurements based on the actual RS resources in Resource Set A, rather than using inference results derived from Resource Set B
Open issue RRC-7: Applicability reporting for option B in RRCReconfigurationComplete
Proposal: [Open issue RRC-7] For Option B, use RRCReconfigurationComplete for initial reporting and UAI for updates, as in Option A.
Open issue RRC-8: Coexistence between option A and option B
Proposal. [Open issue RRC-8] For at least one (sub) use case, only a single option, i.e., option A or option B, is used
Open issues requiring RAN1 inputs
Open issue RRC-9: Definition of ‘applicable AI/ML functionality’
Proposal. [Open issue RRC-9] Remove the definition of ‘applicable AI/ML functionality’ from clause 3.1, as the term is not used in a meaningful or consistent way and is not aligned with RAN1 specifications. 
Open issue RRC-11: How to configure RS configuration for UE sided data collection within CSI-ReportConfig
Proposal 17. [Open issue RRC-11] To introduce new reportConfigType-r19 with “none” in the CSI-ReportConfig to prevent CSI reporting 

4. 

3GPP TSG RAN WG2 #130                                                                                  R2-2503588
St. Julian’s, Malta, May 19th – 23rd, 2025

Source:	CATT
Title:	Discussion on LCM for UE-sided model for BM use case
Agenda Item:	8.1.2.2
Document for:	Discussion and Decision

Conclusion
According to the discussion in section 2, we propose:
Applicability reporting
Observation 1: RAN1 agreed to support associated ID and it can be used to ensure the consistency of NW-side additional condition across training and inference for UE-sided model for BM-Case 1 and BM Case 2. UE may assume the similar properties of a DL Tx beam or beam set/list associated with the same associated ID.
Proposal 1: RAN2 assumes NW-side additional condition as associated ID in RAN2’s discussion, more details can wait for RAN1.
Proposal 2: (RRC-2) Introduce only a flag in otherConfig to indicate the applicability reporting in UAI. 
Proposal 3: For the same sub use case, Option A and Option B are not configured simultaneously.
Proposal 4: (RRC-5) For option B, UE reports the initial applicability via RRCReconfigurationComplete when receive the inference related parameters in RRCReconfiguration, and UAI can be sent to update applicability.
Proposal 5: (RRC-1) A simple cause value of inapplicability that whether the model is available or not is indicated to network together with inapplicability reporting, no further information is needed.
Proposal 6: For option B, NW needs to configure CSI-ReportConfig for inference configuration in Step5. The contents of inference configuration in Step5 are up to RAN1.
Proposal 7: For option B, UE does not need to report the applicability after receiving the inference configuration in Step 5.
Proposal 8: For option B, the UE activates the applicable functionalities as follow:
Periodic CSI report is activated when receiving the full inference configuration of the applicable functionality in Step5;
Semi-persistent and aperiodic CSI report are activated follow legacy CSI framework:
Semi-persistent reporting, activated by MAC CE/DCI
Aperiodic CSI reporting, activated by DCI
Proposal 9: If more than one functionality is configured in Step 3 or Step 5, multiple/all applicable functionalities can be activated.
UE side data collection
Proposal 10: (RRC-3) RAN2 to discuss the following two options for the candidate configuration provided from network to UE:
Option 1: a list of candidate configuration is provided in otherConfig together with the indication of allowing UE requests;
Option 2: UE requests and reports preferred configuration based on the current CSI measurement configuration.
Proposal 11: (RRC-3) The index of the preferred configuration from a list of candidate configuration provided by NW is included in the request message.
Proposal 12: No indication information from UE to network is needed when UE can’t perform data collection based on received configuration.

3GPP TSG-RAN WG2 Meeting #130	           R2-2503666
St.Julians, Malta, May 19th – May 23rd, 2025	

Agenda item:	8.1.2.2
Source:	China Telecom
Title:	LCM for UE-sided model for BM
Document for:	Discussion

Conclusions
Based on the discussion above, we have the following proposals.
Proposal 1: If UE receives the inapplicable full inference configuration in step 3, UE can indicate its preferred inference configuration in step 4.
Proposal 2: The simple cause related to model availability can at least include no trained model, no updated model, or no downloaded model.
Proposal 3-1: If a prohibit timer for initiating a data collection request is supported, it is recommended to allow UE to send a received configuration unavailable indication to NW when the prohibit timer is running.
Proposal 3-2: If a prohibit timer for initiating a data collection request is supported and if it is not running, UE can request a new data collection configuration.
Proposal 4: It is proposed that UE can send a data availability indication to NW and request resources when it needs to report the collected data.
Proposal 5: As for when to report the collected data, the following condition can be considered:
	- out of power;
	- memory has reached a threshold or full;
	- overheat.
Proposal 6: It is recommended that RAN2 discuss the applicable functionality reporting in other handover types, such as CHO, LTM, etc.
Proposal 7: Taking Handover as the baseline, discuss whether the applicable functionality reporting in CHO is still supported by the same RRC procedure.
Proposal 8: For UE-assisted performance monitoring, UE report monitoring result when trigger conditions are fulfilled, such as performance metric calculated by UE is lower than a configured threshold.
Proposal 9: For NW-side performance monitoring, the network determines whether the monitoring performance metric meets the requirement or not.
Proposal 10: For UE-assisted performance monitoring, UE or the network can determine whether the monitoring performance metric meets the requirement or not.
Proposal 11: UE need to be notified when the network determines that the monitoring performance metric does not meet the requirement.

3GPP TSG RAN WG2 Meeting #130      	                           R2-2503714
St Julian’s, Malta, May 19th – 23rd, 2025                                          

Agenda item:	8.1.2.2
Source:	Apple
Title:	Remaining issues on LCM procedure of UE-sided model for AI/ML based beam management
WID/SID:	NR_AIML_Air-Core– Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss key remaining issues on LCM procedure of UE-sided model for AI/ML based beam management. Our observations are:
Observation 1: In legacy RRC, the UE reports UAI only if the NW required information are configured in OtherConfig of RRCReconfiguraiton. However, as Option A is configured in CSI-ReportConfig which is outside of OtherConfig, it is not clear how to specify the new UAI reporting behavior for applicability update.
Observation 2: Because applicability reporting is per inference configuration (CSI-ReportConfig) in Option A but the UE may train multiple models for one inference configuration based on its implementation, absence of associated ID may cause model ambiguity between UE and NW.
Observation 3: Option B is configured in OtherConfig of RRCReconfiguration, but RRCReconfigurationComplete is used for its initial applicability reporting. As RRCReconfigurationComplete is not used to report the feedback for configuration in OtherConfig in legacy RRC. Thus, it is not clear how to fill this gap in RRC spec.
Observation 4: The NW needs to differentiate whether the reported applicability/non-applicability is for full inference configuration (Option A) or for set of inference related parameter (Option B). Thus. non-overlapping ID space is required to identify Option A and Option B. 
Observation 5: If we introduce a new set index (e.g. InferenceSetIndex) to identify the set of inference related parameters, a separate IE from ApplicabilityReport-r19 is needed to report the list of applicable / inapplicable InferenceSetIndex for Option B due to possible ambiguity between InferenceSetIndex and CSI-ReportConfigId.
Observation 6: The cause value to the NW is intended to indicate whether NW can expect that the inapplicable CSI-ReportConfig will become applicable after some time duration, so that NW can just wait the model to be available in local device for inference (without need of reconfiguration of inference).
Observation 7: Between the time that model is available in server and the time before the model is available in its on-chip memory for inference, the NW can expect that the inapplicable CSI-ReportConfig will become applicable shortly. While it is difficult for the UE to estimate when the model training is complete (i.e. available in server).
Observation 8: The CSI-ReportConfig of Rel-19 AI/ML based CSI prediction is same as the CSI-ReportConfig of Rel-18 “non-AI CSI prediction” (i.e. CSI prediction with typeII-Doppler-r18). Thus, the UE needs to differentiate whether one CSI-ReportConfig is for Rel-18 or Rel-19 CSI prediction.

Based on observations, our proposals can be found below:
Remaining issue of data collection configuration
Proposal 1: To support UE request on data collection via UAI, include the following two configurations in OtherConfig of RRCReconfiguration:
Indicaiton on whether to allow send start/stop request 
A list of candidate CSI-ReportConfig(s) without CSI report which at least includes two CSI-ResourceConfigId for Set A/Set B and one or two associated IDs according to RAN1#120 agreement.
Proposal 2: The detailed reporting format of UE preferred data collection configuration includes ServCellIndex and a list of CSI-ReportConfigId(s) among the candidate CSI-ReportConfig(s) configured in OtherConfig.
Proposal 3: As the UE may send data collection request via UAI based on its implementation, no need to introduce a separate indication signaling when UE can’t perform data collection based on received configuration. 
Remaining issues on Option A
Proposal 4: As Rel-19 is the first release to introduce AI/ML, relaxed RRC processing timing requirement is applied for reporting applicability in RRCReconfigurationComplete (i.e. within 16ms after reception of Step 3).
Proposal 5: To avoid misleading NW, the UE stops periodic beam prediction reporting after successfully transmitting UAI on its inapplicability. 
Proposal 6: For the non-applicable CSI-ReportConfig, when it becomes applicable: 
The UE autonomously activates periodic CSI reporting upon reporting it becoming applicable via UAI.
The UE waits legacy DCI / MAC-CE to activate SP/AP CSI reporting upon reporting it becoming applicable via UAI.
Proposal 7: For all the CSI-ReportConfig(s) with beam prediction configuration (e.g. Set A/B configuration) in RRCReconfiguration, the UE implicitly associates them with UAI for applicability update reporting.   
Proposal 8: RAN2 assume that associated ID is mandatory provided in Step 3. Otherwise, it may cause model ambiguity issue between UE and NW. 
Remaining issues on Option B
Proposal 9: For all the sets of inference related parameters configured in OtherConfig of RRCReconfiguration, the UE implicitly associates them with RRCReconfigurationComplete for initial applicability reporting.   
Proposal 10: To allow the common IE ApplicabilityReport-r19 to report applicability of both Option A and B, introduce CSI-ReportConfigId under the set of inference related parameters as the set identifier of Option B.
Proposal 11: For Option B, after reporting applicability, the UE waits NW to send RRCReconfiguration message with full inference configuration in CSI-ReportConfig before starting inference.
Proposal 12: RAN2 confirm that option A and option B can be configured in the same RRCReconfiguration message with the unified applicability report procedure. And a separate UE capability is introduced for option B to allow more flexibility. 
Simple cause value of non-applicability
Proposal 13: Together with non-applicability, the UE can report the following 1-bit simple cause value:
“1” indicate that model training is complete but requires additional time before ready for inference in local device. NW can expect the UE will update its applicability in UAI. 
“0” indicate that model training is not complete. NW may not expect the UE will update its applicability in UAI.
How to handle configuration in IDLE/INACTIVE/RLF
Proposal 14: On how to handle RRC configuration in IDLE/INACTIVE/RLF, follow the legacy UE behaviour in TS 38.331 on whether to release or keep the RRC configuration in CSI-MeasConfig (for inference configuration) and OtherConfig (for applicability reporting and UE data collection preference configurations). 
LCM of CSI prediction
Proposal 15: Introduce one indication under CSI-ReportConfig for the UE to differentiate whether it is for Rel-19 AI/ML based CSI prediction or Rel-18 “non-AI CSI prediction” (i.e. CSI prediction with typeII-Doppler-r18). In details, it is for Rel-19 CSI prediction when this indication is present. Otherwise, it is for Rel-18 CSI prediction.  
Proposal 16: Reuse applicability reporting of AI/ML based management as baseline of CSI prediction. On the configuration of applicability reporting, only support Option A without associated ID (i.e. one or more CSI-ReportConfig on CSI prediction can be configured for UE to report applicability via RRCReconfigurationComplete / UAI).

4 

3GPP TSG-RAN WG2 Meeting #130	R2-2503734
St. Julians, Malta, May 19th– 23rd, 2025

Agenda Item:	8.1.2.2
Source:	KT Corporation
Title:	Discussion on applicability reporting
WID/SID:	NR_AIML_air-Core (Release-19)
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following proposals for applicability reporting with cause for UE-side model:
Proposal 1: The applicability reporting with its explicit cause should be sent to network.
Proposal 2: An applicability change cause information should be introduced and sent to the network.
Proposal 3: The applicability and cause reporting should be supported by UE, feature (FG), model as well as functionality units.
Proposal 4: The inapplicability causes can be grouped into categories for simplicity, such as those related with model/functionality, UE (UE-side server) system and power, radio conditions, etc.

3GPP TSG-RAN WG2 Meeting #130	 R2-2503775
St. Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	8.1.2.2
Source:	MediaTek Inc.
Title:	Further Discussion on LCM of UE-sided Model for AI BM 
Document for:	Discussion, Decision

Conclusion
Open issue RRC-1: Cause of inapplicability
Observation 1: If the UE-side model resides on a UE-side server, the AI/ML model is not available at the UE device and the UE should report inapplicability for the corresponding inference configuration.
Observation 2: The UE implementation may have various type of memories to balance the cost and performance. Various memory types and constraints on the UE device can affect the access speed of stored models.
Observation 3: Due to memory constraints and the UE's lack of prior knowledge about the inference configuration to be used, it is unreasonable to rely on the presence of a model in memory as the sole basis for determining its applicability.
Proposal 1: The UE should indicate the time to model availability when reporting applicability to the network. This time duration specifies how long it takes for the UE to load the model for inference, starting from the transmission of the RRCReconfigurationComplete message in response to the RRCReconfiguration message containing the full inference configuration.
Proposal 2: The time to model availability can be an IE of ENUMERATED type [0ms, other values, infinite]. The value of infinite means that the AI/ML model for the full inference configuration or set of inference related parameters is not available.
Proposal 3: The time to model availability should be optionally indicated in each applicability/inapplicability report for the full inference configuration or set of inference related parameters. The absence of the IE for applicability/inapplicability would imply the inapplicability of the corresponding full inference configuration or set of inference related parameters due to reasons other than the unavailability of the AI/ML model.
Proposal 4: The network is not expected to active the inference configuration until the time to model availability has elapsed after receiving the RRCReconfigurationComplete message in response to the RRCReconfiguration message containing the full inference configuration. 

Open issue RRC-2: Content of OtherConfig for Enabling Applicability Reports in UAI 
Proposal 5: A SetupRelease flag within OtherConfig is used to configure the UE to update applicability of the full inference configuration or set of inference related parameters via UAI. 

Open issue RRC-3: UE data collection request
Proposal 6: The list of candidate configurations can be sent via OtherConfig in RRCReconfiguration message. RAN2 discuss the feasibility to send the list of candidate configurations in system information.
Proposal 7: Each candidate configuration provided by the network to the UE should contain at least the radio resource configuration for Set A and Set B, as well as one or two associated IDs. Each candidate configuration should be identified by an ID. The UE should indicate the IDs of the preferred candidate configuration in its request via UAI.
Proposal 8: The absence of the list of candidate configurations implies that the UE request for the measurement configuration for UE-side data collection is not allowed. 
Proposal 9: The UE indicates to the network to stop data collection when the UE can’t perform data collection based on the received configuration. 

Other details for Option B
Proposal 10: Extend the following agreements made for Option A) to support Option B):
Upon receiving a full inference configuration or a set of inference related parameters, the UE sends the initial applicability report in the RRCReconfigurationComplete message. UAI can be sent to update applicability.
Upon receiving one or more full inference configurations or sets of inference related parameters via the RRCReconfiguration message, the UE shall maintain all the full inference configurations or sets of inference related parameters, regardless of whether they are applicable or inapplicable, until the network explicitly releases them.
Proposal 11: Each set of inference related parameters is identified by an ID. 
Proposal 12: The network should not provide Option A (full inference configuration) and Option B (inference-related parameters) in the same RRCReconfiguration message. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503848
Malta, May, 19th- 23rd 2025
Agenda item:	8.1.2.2
Title:	Continuous Discussion on LCM for UE side Model 
Source:	ZTE Corporation
Document for:	Discussion and Decision

Conclusion
Observation 1: Both approaches of highly abstracted cause value and more specific cause values can indicate whether the functionality is inapplicable temporarily, which is useful for network to determine following behavior. The difference between the two approaches is the information provided by the cause value.
Observation 2: It was agreed UE is allowed to do UAI reporting via otherConfig and UAI can be sent to update applicability. However, it is no crystal clear whether the information of a specific functionality must be configured in otherConfig to enable applicability reporting via UAI for that functionality.
Observation 3: It is unnecessary to include applicability report of all configured inference configuration in every RRCReconfigurationComplete message. 
Observation 4: A configured inference configuration is stored as part of Inactive AS context when UE is released to RRC_INACTVIE state, and is restored upon UE receives RRCResume message.
Observation 5: At least before receiving RRCResumeComplete message, the network cannot get aware of the applicability of restored inference configuration. 
Observation 6: How UE treat restored inference configuration during RRC resume procedure has impact on whether network needs to prepare network resources for the restored inference configuration before transmitting RRCResume message.
Observation 7: The UAI framework is agreeable to be used for UE to request the measurement configuration of the UE side data collection.

Proposal 1: Following causes can be defined as inapplicability cause:
NW side additional condition not applicable 
UE side additional condition not applicable 
Lack of hardware capability 
Applicable model is not available locally
Proposal 2: RAN2 to decide one of following options on how to enable applicability reporting via UAI for a functionality.
Option 1:Applicability reporting via UAI is enabled for a functionality as long as the full inference configuration is configured for the functionality.
Option 2: Applicability reporting via UAI is enabled for a functionality only if it is also configured in otherConfig, e.g. to include the associated CSI-ReportConfigId in otherConfig.
Proposal 3: RAN2 to decide one of following options regarding the applicability reporting in RRCReconfiguration message for applicability reporting option A.
Option 1: To only include applicability report of the inference configuration that are configured/reconfigured in this RRCReconfiguration message, if any.
Option 2: To include applicability report of the inference configuration that are configured/reconfigured in this RRCReconfiguration message, if any. In addition, to include the change of applicability of the inference configuration that are configured in previous RRCReconfiguration message, if any. 
Proposal 4: RAN2 to agree that new inference configuration can be configured in RRCResume message and initial applicability report can be included in RRCResumeComplete message.
Proposal 5: RAN2 to decide one of following options regarding how to treat the restored inference configuration during RRC resume procedure:
Option 1: UE autonomously releases the restored inference configuration, or network is expected to deconfigure the restored inference configuration via RRCResume message.
Option 2: UE reports applicability of the restored inference configuration in RRCResumeComplete message, and keeps the restored inference configuration as deactivated no matter it is applicable or inapplicable. Network is expected to release or reconfigure the inference configuration based on the applicability report.
Option 3: UE reports applicability of the restored inference configuration in RRCResumeComplete message. If the inference configuration is periodic CSI report configuration and is applicable, the UE activates it automatically after transmitting RRCResumeComplete message. Otherwise, UE keeps the inference configuration in deactivated.
Proposal 6: The candidate configuration list is contained in the OtherConfig of the RRCReconfiguration to trigger UE to report the UAI for requesting the measurement configuration.
Proposal 7: RAN2 is asked to decide which of the following candidate configuration list can be contained in the otherConfig for triggering UAI
UE side data collection configuration list where each configuration contains CSI-ResourceConfig for both Set A and Set B, and corresponding associated Id(s)
Inference configuration list where each inference configuration can be a CSI-ReportConfig or a CSI-ReportConfigId.
Proposal 8: The start/stop indication on UE side data collection in the UAI is not needed.
Proposal 9: One or more configuration indexes are contained in the UAI to indicate the UE preferred configuration for UE side data collection.

3GPP TSG-RAN WG2 #130	R2-2503918
St Julian, Malta, May 19th – 23rd, 2025

Agenda item:	   8.1.2.2
Source:		Lenovo
Title:	Left issues related to applicability report for AIML based BM
Document for:		Discussion and Decision

Conclusion

Based on the discussion above, we observe:
Observation 1	Comparing Option A) and Option B), the fundamental difference seems to be in Option B) gNB will receive the applicable parameters (in Option B step 3-4) before providing the inference configuration to UE.
Observation 2	The steps from CSI-ReportConfig provision until CSI-ReportConfig activation can be regarded as identical in Option A) and B).
Observation 3	For applicability report, Option A and B are not mutual exclusive. Option B can be regarded as a superset of Option A.
Observation 4	Beam prediction with Set A and Set B beams of the same frequency is supported.
Observation 5	For a inference configuration/parameter-set that is reported to be inapplicable, it is beneficial for gNB to distinguish if 1) gNB should remove the relevant configuration/parameter-set or 2) keep the relevant configuration/parameter-set and wait for further update.
Observation 6	Indication of “model unavailability” along does not really help gNB’s further decision.


Based on the discussion above, we propose:


Open issue RRC-8: Coexistence between option A and option B

Proposal 1	RAN2 is suggested to clarify that in Option B, after UE receives the full inference configuration, UE will indicate/update the applicability/inapplicability of configured inference configuration as in Option A (i.e., in RRCReconfigurationComplete and UAI).
Proposal 2	If Proposal 1 is agreed, for applicability report, RAN2 is suggested to support a unified solution with Option B as superset of Option A:
a.	Step 3: (Optional) gNB configures the UE via OtherConfig with sets of parameters for inference configuration
b.	Step 4: (Optional) UE reports in RRCReconfigurationComplete/UAI the applicability of the sets of parameters for inference configuration
c.	Step 5: gNB generates and provides inference configuration (CSI-ReportConfig) to UE in RRCReconfiguration
d.	Step 6: UE implies the applicability of CSI-ReportConfig in RRCReconfigurationComplete. The periodic CSI report, if configured, will be activated if reported to be applicable.
e.	Step 7: For aperiodic/semi-persistent CSI report, gNB may further activate via DCI/MAC CE.
f.	Step 8: For the subsequent change of applicability related to either inference configuration or parameters for inference configuration, UE will indicate to gNB in UAI.

Open issue RRC-1: Cause related to inapplicability
Proposal 3	RAN2 confirms that the cause value associated with the inapplicability reporting can be added in both Option A (for a full inference configuration) and Option B (for a set of inference parameters) cases.
Proposal 4	When UE indicates the inapplicability of (Option A) a full inference configuration or (Option B) a set of inference parameters, UE can further indicate a cause value if the inapplicability is temporary.

TDoc file reading error

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130		R2-2504051
St Julian’s, Malta, May 19th – 23rd 2025


Agenda Item: 		8.1.2.2
Source:			Sony
Title:	Discussion on LCM for UE side model for Beam Management
Document for:		Discussion & Decision

Summary
In this contribution, we have the following proposal for RAN2 to agree:

Proposal 1: 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.
Proposal 2: For BM-Case2, reusing part of the input data from the previous inference instance for each new inference instance to reduce measurement overhead based on the RS resource set configured by NW in model monitoring. 
Proposal 3: For the UE-side models, UE can report the following types of model difference to the NW when requesting assistance in model updates:  difference between the required value and the monitored value of model performance metrics, or difference between the predicted results and the traditional beam measurement-based results.

3GPP TSG-RAN WG2 Meeting #130						       	   		R2-254114
St Julian’s, Malta, 19th – 23nd May, 2025
Title: 	Applicability report and Inference for UE-sided model for Beam Management and CSI prediction
Source: 	Huawei, HiSilicon
Agenda item:	8.1.2.2
Document for:	Discussion/Decision

Conclusion
For CSI prediction using UE-side model, for data collection for training, aperiodic CSI-RS resource for CMR is not supported.
Agreement
For CSI prediction using UE-side model, for training data collection, support 
CSI-ReportConfig can used for configuring the resources for data collection purpose without CSI report
FFS on how to indicate without CSI report in CSI-ReportConfig
Agreement
For CSI prediction using UE-side model, for performance monitoring, support UE assisted performance monitoring subject to an additional UE capability, and UE assisted performance monitoring is based on Type 3 performance monitoring 
Agreement
For CSI prediction using UE-side model, for performance monitoring type 3, support SGCS as a performance metric. 
Agreement
For the definition of SGCS,

Note: How to handle layer mapping mismatch, if any, is up to UE implementation.
Agreement
For CSI prediction using UE-side model, for reporting contents of UE assisted performance monitoring, down-select one alternative by RAN1#121. 
Alt 1: one SGCS is calculated based on predicted CSI for one inference reporting, ground truth CSI
Alt 2: one SGCS is calculated based on predicted CSI for one inference reporting, and ground truth CSI, another SGCS is based on ground truth CSI and CSI (non-predicted) corresponding to the latest CSI-RS transmission occasion not later than CSI reference resource of the inference reporting instance.
Alt 3: statistic of reporting contents (e.g., mean, x% CDF of SGCS values) of inference reporting instances within configured monitoring window 
Monitoring window can be configured by NW 
FFS on signalling details
FFS on whether to report per prediction instance, selected prediction instance(s), averaged over prediction instances
FFS on report frequency granularity (e.g., per wideband or per subband or averaged over subband or selected subband)
FFS on whether to report per layer, the first layer, averaged over layer
FFS on how to quantize and report mechanism
Agreement
For CSI prediction using UE side model, for inference, consider following options for potential down selection
Option 1: only dedicated AI/ML PU (OAPU) is occupied
Option 2: only legacy CPU (OCPU) is occupied
Option 3: both dedicated AI/ML PU (OAPU) and legacy CPU (OCPU) are occupied
FFS whether OAPU and OCPU are based on defined rule and/or reported by UE
Note: The supported option(s) by UE is reported by UE capability, if multiple options are supported. 
The total number of dedicated AI/ML PU for AI/ML is reported by UE capability. 
Note: The total number of Use case specific dedicated AI/ML PU could be discussed separately. 
Agreement
For CSI prediction using UE-side model, at least for inference, introduce new RRC parameter for CSI report configuration to distinguish CSI report of AI-CSI prediction and non-AI CSI prediction.
Note: terminology of “AI-CSI prediction” and “non-AI CSI prediction” is separate discussion
Detailed parameter name is upto RAN2

RAN1#120 agreements
R1-2501528	Summary #1 of CSI prediction	Moderator (LG Electronics)
From Wednesday session
Agreement
For CSI prediction using UE-side model, at least for inference, Rel-18 CSI framework is reused.
For CSI-RS resource type for CMR, periodic, semi-persistent, and aperiodic CSI-RS are supported. 
For inference report, 
for N4>=1, support Rel-18 codebook ('typeII-Doppler-r18') 
R1-2501529	Summary #2 of CSI prediction	Moderator (LG Electronics)
R1-2501530	Summary #3 of CSI prediction	Moderator (LG Electronics)
From Thursday session
Agreement
For CSI prediction using UE-side model, if performance monitoring type 1 or 3 is supported, for calculation of monitoring metric, support 
Based on intermediate KPI 
Down select between SGCS and NMSE by RAN1#120bis
FFS on the definition of SGCS/NMSE and how to calculate monitoring metric
Agreement
For CSI prediction using UE-side model, for CSI processing criteria and timeline, at least for inference further study on
Whether the CPU should be shared or separately counted between legacy CSI reporting and AI/ML-based CSI reporting
Whether the Processing Unit should be shared or separately counted among AI/ML related features/functionalities.
Whether new timeline is needed/updated for inference, and whether a different timeline is needed when functionality switches/activates.
Whether legacy framework for active CSI-RS resource and port counting can be reused
Note: Strive to study CSI processing criteria considering both BM and CSI case, and take the existing solutions as starting point.
R1-2501610	Summary #4 of CSI prediction	Moderator (LG Electronics)
Presented in Friday session
Agreement
For CSI prediction using UE-side model, for data collection for training, 
For resource configuration, 
For CSI-RS resource type for CMR, periodic and semi-persistent are supported. 
FFS on support of aperiodic CSI-RS resource
FFS on whether to separately configure CSI-RS resource(s) used for measurements for model input and CSI-RS resource(s) used for measurements for ground-truth CSI
FFS whether/how to enhance CSI-RS resource configuration to reduce CSI-RS signalling overhead.
FFS on CSI report configuration 
Final summary in R1-2501626.

3GPP TSG-RAN-WG2 Meeting #130	                                   R2- 2504156
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item: 8.1.2.2
Source: Sharp
Title: On Explicit Reporting of Functionality Inapplicability
Document for: Discussion and Decision

Conclusions
Based on the discussion above, we have the following observations and proposals:
Observation 1: Indicating a functionality to be temporarily unavailable may be too broad and not serve the purpose of inapplicability cause indication.
Observation 2: Lack of feedback regarding the cause of inapplicability from the UE can lead to significant inefficiencies in signalling, resource usage and allocation, increased latency, and higher power consumption at the UE-side.
Observation 3: Knowing the cause of a functionality's inapplicability offers advantages to the network by enabling it to:
Decide whether the current inference configuration needs to be changed or if any further reconfigurations are needed.
Initiate a new model transfer or update, potentially including dataset and model parameters.

Proposal 1: RAN2 to agree that cause for inapplicability can be reported by the UE.
Proposal 2: A set of cause values needs to be defined to reflect a broader range for inapplicability causes for e.g., Outdated or invalid AI/ML model, Unavailable AI/ML model, Insufficient UE processing capability/UE side issues.
Proposal 3: The UE shall indicate to the network that the applicability of the requested functionality is subject to model download (e.g. via cause value) and associated estimated delay.
Proposal 4: UE may indicate model/parameter download progress to the network.
Proposal 5: The network may request the cause for inapplicability from the UE when needed.
Proposal 6: If an Option A configuration (e.g., Full CSI-ReportConfig.) provided in Step 3 that is temporarily inapplicable and later becomes applicable after the cause for inapplicability is resolved: 
UE must report its renewed applicability via UAI 
UE shall not autonomously activate the periodic CSI-ReportConfig.
Proposal 7: The UE shall wait for the network to activate the periodic CSI-ReportConfig. for example, via MAC CE.

3GPP TSG-RAN-WG2 Meeting #130	                                   R2-2504157 
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item: 8.1.2.2
Source: Sharp
Title: Considerations for Functionality Activation and Reporting 
Document for: Discussion and Decision

Conclusions
Based on the discussion above, we have the following observations and proposals:
Observation 1: If the UE reports a periodic CSI report configuration (i.e., a full inference configuration provided in CSI-ReportConfig.) as non-applicable, the UE is still required to retain all received full inference configurations—regardless of their applicability status—until they are explicitly released by the network via RRC signalling.
Observation 2: Applicable functionalities are dynamic in nature and may fluctuate due to variations in the UE's environment, network-side additional conditions, UE-side additional conditions, or the availability of the AI/ML model.
Observation 3: Frequent functionality applicability changes or updates could negatively affect signalling overhead, system performance, and the network’s ability to manage AIML functionality effectively.

Proposal 1: When an applicable periodic configuration/functionality (CSI-ReportConfig.) becomes inapplicable in the UE may autonomously de-activate it and report it to the network.
Proposal 2: The network may provide a default or preferred configuration in functionality configuration for e.g., a default or preferred CSI-ReportConfig. either in step 3 or 5 respectively.
Proposal 3: The UE may indicate preferred configuration (s) to the network (e.g., preferred CSI-ReportConfig.) in step 4.
Proposal 4: RAN2 should explore methods to minimize the necessity for frequent applicability status updates facilitating the stability of inference operation once activated. 
Proposal 5: The UE could provide a “StabilityIndex” metric or indication for each applicable functionality, for e.g., in UAI or RRC message, to enhance operational consistency and reduce signalling overhead.

3GPP TSG RAN WG2 Meeting #130	 R2-2504214
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.1.2.2
Source:	Futurewei
Title:	Discussion on LCM for UE-Side Model for Beam Management Use Case
Document for:	Discussion

Conclusions
In this contribution, we discussed our views on LCM for UE-side models for the beam management use cases. Based on the discussions in the previous sections, our proposals are as follows.  
Observation 1: The exact definition and usage of Associated ID was not clear and needs to be clarified.

Proposal 1: Revised “Step 3” as below.
“Step 3”: Following configurations are provided from NW to UE:
1) UE is allowed to do UAI reporting via OtherConfig.
2) Network shall may provide NW-side additional condition if applicable.  FFS on the RRC signalling. and whether it is mandatory or optional. 
3) FFS on The configuration (e.g. inference configuration) of supported functionalities.

Proposal 2: Define an identifier or an index for identifying inference parameters.

Proposal 3: Revise the procedures for UE-side LCM as below.
UE decides the applicable functionalities based on NW-side additional conditions (if provided), UE-side additional conditions (internally known by UE) and model availability in device. 
UE-side additional conditions can include UE’s capabilities and capacities that are related to AI/ML functionality operations, such as CPU for AI/ML-based features, memory, storage, model inference time, battery level and etc.
FFS whether other configuration can be considered by UE (e.g. inference configuration).  
FFS how the applicable functionality is decided if NW-side additional condition is not provided in step 3.
“Step 4”: UE reports applicable functionality and its internal capabilities/capacities in the following scenarios: 
Upon being configured to provide applicable functionality and upon change of applicable functionality via UAI
As response to NW-side additional condition requesting applicable functionality reporting in step 3, FFS other network configuration (e.g. inference configuration).
FFS via UAI or RRCReconfigurationComplete, etc 

Proposal 4: Revise the procedures for UE-side LCM as below.
The applicable functionality may be activated by receiving its inference configuration when it is provided in Step 5.  
FFS the initial activation state.  
FFS on initial state of applicable functionality if inference configuration of supported functionality is provided in Step 3. 
FFS on additional L1/L2 signalling for activation/deactivation.  
FFS if multiple applicable functionalities for the same use case/sub use case can be activated at the same time.   
FFS what is the granularity of functionality

3GPP TSG-RAN WG2 Meeting #130						   R2-2504239
St Julian's, Malta, 19 - 23 May, 2025
Title: 		Discussion on training data collection for UE-sided model for BM and CSI prediction
Source: 	Huawei, HiSilicon
Agenda item:	8.1.2.2
Document for:	Discussion/Decision

Conclusion
For CSI prediction using UE-side model, for data collection for training, aperiodic CSI-RS resource for CMR is not supported.

Agreement
For CSI prediction using UE-side model, for training data collection, support 
CSI-ReportConfig can used for configuring the resources for data collection purpose without CSI report
FFS on how to indicate without CSI report in CSI-ReportConfig

Agreement
For CSI prediction using UE-side model, for performance monitoring, support UE assisted performance monitoring subject to an additional UE capability, and UE assisted performance monitoring is based on Type 3 performance monitoring 

Agreement
For CSI prediction using UE-side model, for performance monitoring type 3, support SGCS as a performance metric. 
Agreement
For the definition of SGCS,

Note: How to handle layer mapping mismatch, if any, is up to UE implementation.

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

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

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

RAN1#120 agreements

R1-2501528	Summary #1 of CSI prediction	Moderator (LG Electronics)
From Wednesday session
Agreement
For CSI prediction using UE-side model, at least for inference, Rel-18 CSI framework is reused.
For CSI-RS resource type for CMR, periodic, semi-persistent, and aperiodic CSI-RS are supported. 
For inference report, 
for N4>=1, support Rel-18 codebook ('typeII-Doppler-r18') 


R1-2501529	Summary #2 of CSI prediction	Moderator (LG Electronics)
R1-2501530	Summary #3 of CSI prediction	Moderator (LG Electronics)
From Thursday session
Agreement
For CSI prediction using UE-side model, if performance monitoring type 1 or 3 is supported, for calculation of monitoring metric, support 
Based on intermediate KPI 
Down select between SGCS and NMSE by RAN1#120bis
FFS on the definition of SGCS/NMSE and how to calculate monitoring metric

Agreement
For CSI prediction using UE-side model, for CSI processing criteria and timeline, at least for inference further study on
Whether the CPU should be shared or separately counted between legacy CSI reporting and AI/ML-based CSI reporting
Whether the Processing Unit should be shared or separately counted among AI/ML related features/functionalities.
Whether new timeline is needed/updated for inference, and whether a different timeline is needed when functionality switches/activates.
Whether legacy framework for active CSI-RS resource and port counting can be reused
Note: Strive to study CSI processing criteria considering both BM and CSI case, and take the existing solutions as starting point.


R1-2501610	Summary #4 of CSI prediction	Moderator (LG Electronics)
Presented in Friday session
Agreement
For CSI prediction using UE-side model, for data collection for training, 
For resource configuration, 
For CSI-RS resource type for CMR, periodic and semi-persistent are supported. 
FFS on support of aperiodic CSI-RS resource
FFS on whether to separately configure CSI-RS resource(s) used for measurements for model input and CSI-RS resource(s) used for measurements for ground-truth CSI
FFS whether/how to enhance CSI-RS resource configuration to reduce CSI-RS signalling overhead.
FFS on CSI report configuration 

Final summary in R1-2501626.

3GPP RAN WG2 Meeting #130	R2-2504309
Malta, Malta, May 19th – 23rd 2025
Agenda Item:	8.1.2.2
Source:	InterDigital
Title:	Remaining open issues: LCM for UE-sided model for BM use case
Document for:	Discussion, Decision

Conclusion
In this contribution the following proposals are made regarding remaining open issues for LCM for beam management use case:
Proposal 1:	[RRC-1] Support at least the following inapplicability cause values: 1) Model not available; 2) UE-side conditions not suitable; and 3) NW-side conditions not suitable.
Proposal 2:	[RRC-2] ApplicabilityReportConfig includes a flag indicating whether applicability reporting via UAI is enabled or disabled. RAN2 assumes a single flag applies for both Option A and B.
Proposal 3:	[RRC-3] UE indicates preferred data collection configuration via an index/ID associated with a configuration in the candidate list.
Proposal 4:	[RRC-3] dataCollectionPreferenceConfig includes at least a flag indicating whether UE data collection request is enabled or disabled.
Proposal 5:	[RRC-4] NW implementation can deconfigure a periodic CSI report configuration after UE initially reports it as inapplicable (i.e., no specification impact).
Proposal 6:	[RRC-5] UE continues to report periodic beam predictions until the associated periodic CSI report configuration is deconfigured by the network.
Proposal 7:	[RRC-6] UE releases inference-related configuration(s) (full inference configuration(s) and set(s) of inference related parameters) upon release to RRC IDLE/INACTIVE.
Proposal 8:	[RRC-7] RAN2 assumes applicability report for Option B (sets of inference related parameters) can be included in both RRCReconfigurationComplete and UAI (i.e., same as Option A). This can be revisited based on RAN1 conclusions/final signaling design.
Proposal 9:	[RRC-8] RAN2 assumes Option A and Option B can be simultaneously configured. This can be revisited based on RAN1 conclusions/final signaling design.

3GPP TSG-RAN WG2 Meeting #130		     R2-2504353
Malta, MT: 19th May – 23rd May 2025

Source:	Qualcomm Incorporated 
Title:	Open Issues on LCM for UE-sided Models for Beam Management and CSI Prediction 
Agenda Item:	8.1.2.2 LCM for UE-sided model for Beam Management use case
Document for:	Discussion and Decision
Introduction & 

Conclusion
LCM for Beam Management 

Proposal 1: RAN2 is requested to consider Fig. 2.1-1 as signaling for UE side data collection configuration.  

Proposal 2: In STEP 2, the UE provides the UE capability information containing its capabilities for UE-side data collection.

Proposal 3: In STEP 3, the otherConfig (in the RRC Reconfiguration) may contain the following
A Flag indicating whether UE is allowed to send UAI for requesting data collection configuration, and/or
A List of candidate configurations for data collection for UE-side training (e.g., one or more CSI-ReportConfigs for UE-side data collection). 

Proposal 4: In STEP 4, the UE Assistance information may contain
An indication that UE is interested in training data collection, if otherConfig in STEP 3 does not contain the list of candidate configurations for UE-side data collection, or 
Preferred data collection configuration (e.g., identifiers of data collection configuration signaled in STEP 3). 

Proposal 5: [OPTIONAL] In STEP 5, the otherConfig (in the RRC Reconfiguration) may contain
A List of candidate configurations for data collection for UE-side training (e.g., one or more CSI-ReportConfigs for UE-side data collection), if not provided in STEP 3. 

Proposal 6: [OPTIONAL] In STEP 6, the UE indicates one or more selected configurations for UE-side data collection (e.g., CSI-ReportConfig IDs). 

Proposal 7: After the data collection configuration for UE-side model training, the activation/deactivation of the data collection can be performed by 
The network based on network decisions (network wants to STOP transmitting RS, or if the network determines that configured resources/resource sets are not suitable), or
UE request (if the UE wants to STOP collecting the training data or if the UE determines that configured resources/resource sets are not suitable). 

Proposal 8: RAN2 should wait RRC parameter list from RAN1 before further discussing signaling or procedure for option B. 

Observation 1: The UE may not have a model available for inference configuration provided to the UE due to
The trained model (for the inference configuration) is not available at the UE, i.e., the UE-side has trained a model for the inference configuration, but it is not available at the UE/ device, or
UE does not have a trained model (for the inference configuration), i.e., UE-side has not trained a model for the inference configuration.

Proposal 9: The UE indicates to the network the cause of inapplicability as either:
Trained model not available: For the case when the UE side has a trained model for the inference configuration, but the model is not available at the UE/device.
No trained model: For the case when the UE side does not have a trained model for the inference configuration.

Observation 2:  UE behavior for non-applicable periodic CSI-ReportConfig is not clear, i.e., what is the UE's expected behavior if periodic CSI-ReportConfig becomes applicable after earlier signaled as inapplicable in RRCReconfigurationComplete/UAI? 

Proposal 10: The UE autonomously activates applicable periodic CSI-ReportConfig (full inference configuration) upon sending the UE Assistance Information (when a periodic CSI-ReportConfig for inference becomes applicable after earlier signaled as inapplicable in RRCReconfigurationComplete / UAI). 

Observation 3: In the current implementation of the applicability reporting [7]
The UE is expected to send full applicability/inapplicability information of the inference configuration configured by the previous RRCReconfiguration message (note that the UE has already provided the complete applicability/inapplicability information when configured by previous RRCReconfiguration(s) messages).

Proposal 11: The following applicability/inapplicability information is provided in the RRCReconfigurationComplete message
Full applicability/inapplicability information for the inference configuration provided by the latest RRCReconfiguration message, and
Change in applicability/inapplicability information for the inference configuration provided by the previous RRCReconfiguration message.

Observation 4: The legacy CSI-ReportConfig can be differentiated from the CSI-ReportConfig for AI/ML-based beam management based on Information Elements (IEs) in the CSI-ReportConfig.

Proposal 12: OtherConfig for enabling report in the UAI is a setup message (i.e., a FLAG), configuring the UE to report changes in applicability/inapplicability information.  

Proposal 13: CA and NR-DC are considered for the specification work.
Observation 5: CSI-ReportConfig includes the serving cell index. The gNB-CU assigns a unique CSI-ReportConfigID to each cell or beam it wants to monitor for CSI reports. 

Proposal 14: Additional reporting of the serving cell index is not required, as the UE reports the CSI-ReportConfigID in the applicability report. 

Proposal 15: For the NR-DC, if the applicability report is sent over SRB1, the UE will send the applicability report for the SCG using UL Information Transfer MRDC (similar to the legacy measurement reporting for SCG). 

Proposal 16: The SN can determine the cells based on the reported CSI-ReportConfigID in the applicability report for SCG. 


LCM for CSI Prediciton 

Proposal 17: The UE can request measurement configuration for data collection of AI/ML based CSI Prediction (similar to the beam management use case). The request can contain one or more of the following:	
An indication on start/stop of data collection 
Preferred configuration from a list of candidate configurations provided by NW.  Details of signaling are FFS.  It is up to network what it configures at the end.

Proposal 18: The UAI message is used by the UE to request data collection measurement configuration for CSI prediction (similar to the beam management use case). It is up to UE implementation when to send the request.

Observation 6: Objective of performance monitoring is to identify data drift, it will be hard to make any monitoring decision unless prediction accuracy is observed over enough number of samples to get a reliable statistic. Monitoring latency could be tens or even hundreds of milliseconds.

Observation 7: The buffering burden can be relaxed if L3 signalling or mechanism is used for performance monitoring.

Proposal 19: Support RRC based mechanism for UE assisted monitoring report for CSI Prediction. 

3GPP TSG-RAN WG2 Meeting #130       	                      R2-2504376
Malta, MT, 19th-23rd May 2025

Agenda item:	8.1.2.2
Source:	CMCC
Title:	Discussion on LCM for UE-sided model for BM
WID/SID:	NR_AIML_air-Core
Document for:	Discussion
 

Conclusion
Here are the observations and proposals for LCM for UE-sided model for beam management.
Open issue RRC-1: Cause of inapplicability
Proposal 1: Introduce a simple cause indicating whether model is available or not.
Open issue RRC-4: Activation of a periodic CSI report configuration upon change from inapplicable to applicable
Proposal 2: If option A is configured in Step 3, when the non-applicable functionality becomes applicable, the UE cannot autonomously activate the applicable functionalities for periodic CSI reporting upon reporting functionality applicability update via UAI. 
Open issue RRC-3: UE data collection request
Proposal 3: The candidate configuration can be provided via RRCReconfiguration message based on UE capability, and may include such as RS type and resource for set A/set B.
FFS whether an indication from UE to network is needed when UE can’t perform data collection based on received configuration
Proposal 4: When the UE can’t perform data collection for model training based on received configuration, other UE behaviors in connected mode should not be affected.
Proposal 5: An indication is introduced in RRCReconfigurationComplete message when UE can’t perform data collection based on received configuration.
Performance monitoring
Observation 1: There is no time to address Type 2 in RAN1 considering only one WG meeting left to conclude this WI, so RAN2 should focus on Type 1 and discuss whether there is any impact on RAN2. 
Observation 2: For performance monitoring Type 1 Option 1 and Option 2, the legacy CSI framework is reused for monitoring configuration and reporting.
Proposal 6: For performance monitoring Type 1 Option 1 and Option 2, there is no additional RAN2 impact apart from ASN.1 impact, based on the current progress in RAN1.

4	

3GPP TSG-RAN WG2 Meeting #130	R2-2504413
St. Julian’s, Malta,19th  – 23rd  May,  2025	

Agenda item:	8.1.2.2
Source:	Nokia
Title:	LCM for UE-side Beam Management
WID/SID:	NR_AIML_air-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: An AI/ML-enabled configuration could be considered permanently inapplicable, in the context of an RRC session, if an applicable model neither exists in the UE nor in a model store available to the UE.
Observation 2: An AI/ML-enabled configuration could be considered temporarily inapplicable in two cases: if the UE has access to a model store with an applicable model or if the reason for inapplicability is related to UE performance constraints such as processing capacity or battery capacity.
Observation 3: An active beam prediction configuration may become inapplicable after it is activated. During this time, the outputs of the model enabling the configuration could be unreliable or ambiguous.
Observation 4: (RRC-7) The same structure, i.e., ApplicablityReportList, can be used for reporting applicability in RRCReconfigurationComplete and in UEAssistanceInformation. By using the same structure, the applicability of  sets of inference related parameters, or Option B, can be reported the same way as full inference configurations.
Observation 5: (RRC-8) Full inference configurations and sets of inference-related parameters would be configured separately and have their own IDs. Therefore, they can be reported simultaneously using the same ApplicabilityReport.
Observation 6: In our latest agreements, we have been able to describe AI/ML-related behaviours without using the term functionality, and in previous meetings, we have agreed to avoid the use of new AI/ML-specific terminology when legacy terminology is sufficient.
Observation 7: Some fields in CSI-ReportConfig will only be present in AI/ML-enabled configurations, such as typeOfBMCase1andBMCase2. These fields can be used to uniquely identify beam prediction AI/ML-enabled configurations based on CSI-ReportConfig.
Observation 8: Stage 2 can describe the nature of an AI/ML or prediction-based configuration. In Stage 3, the field names can describe the purpose of a configuration without the supporting text redescribing what is clear from the field names.
Observation 9: A poorly performing inference configuration could consistently perform poorly because the applicability determination procedure is unable to account for unforeseen factors which could impact model performance.
Observation 10: An indication of poor performance when reconfiguring a UE configured with an inference configuration could be used by the UE to help determine applicability of a configuration.
Observation 11: Other UEs may have already requested the same preference for a UE data collection configuration as another UE and the configuration may already be active.

And the following proposals:
Proposal 1: Support two cause values for inapplicability: permanent inapplicability and temporary inapplicability. Setting the appropriate value is up to UE implementation.
Proposal 2: Support only a flag to enable or disable the reporting of updates to applicability of AI/ML configurations. The absence of the configuration implies that reporting of updates to applicability is disabled.
Proposal 3: When an active periodic beam prediction configuration becomes inapplicable, the UE shall suspend the transmission of Set A beam predictions and reporting of Set B measurements corresponding to the inapplicable configuration until the UE is reconfigured by the NW.
Proposal 4: RAN2 to endorse the text proposal within Applicability Reporting Clause for Stage 2 running CR (changes are highlighted in orange in Section 7).
Proposal 5: To allow future-proof extensibility, adopt the structure of Figure 3.1-1of the ApplicabilityReport-r19 and its inclusion in UEAssistanceInformation-v1900-IEs and RRCReconfigurationComplete-v1900-IEs, including the reporting for a combination of full inference configurations and sets of inference-related parameters with the ability to indicate the configuration ID type (e.g., CSI-ReportConfigId, InferenceRelatedParametersId) and the configuration ID for which applicability is being reported.
Proposal 6: Do not use the term “functionality” in 38.331 and 38.300.
Proposal 7: Use a field or list of fields only available in AI/ML-enabled configurations, e.g., typeOfBMCase1andBMCase2, to identify configurations which are subject to the applicability determination procedure.
Proposal 8: Outside of field names, there is no need in 38.331 to explicitly specify whether a configuration is for prediction or whether reported measurements are predictions.
Proposal 9: The NW can provide a cause with reconfiguration, e.g., modifying or releasing an inference configuration, indicating that the configuration performed poorly.
Proposal 10: Include in the configuration for data collection configuration candidates, e.g., UE-DataCollectionPrefConfig, an indication whether a data collection configuration candidate is already active, e.g., for other UEs which already indicated the same preference.
Proposal 11: A UE can immediately begin performing measurements on a data collection configuration candidate which is already active and can indicate its preference for an active data collection configuration candidate.
Proposal 12: For beam prediction-Case1 and beam prediction-Case2, Type 1 Option 2 performance monitoring for beam prediction related CSI reporting
Configure each UE with dedicated reference signals from Set A beams for early feedback of a failure event
Trigger beam failure event reporting via performance monitoring KPI evaluation 


7	Text Proposal for 38.300 Applicability Reporting Procedure
Note: The changes in the section below are on top of the latest available version of the running CR [3].
X.Y.2.3	Applicability Reporting
For UE side model, the Network provide inference configuration based on UE supported functionalities. The UE can report its applicable functionalities, non-applicable functionalities with relevant cause and their subsequent change to Network. The basic procedure of applicability reporting is described as in Figure X.Y.2.3-1.

Figure X.Y.2.3-1: Initial applicability and applicability status change reporting for Option A
1. The network inquiries about the UE capability information.
2. UE indicates its supported functionalities to the network via UE capability information.
3. The network may provide inference configuration with NW-side additional conditions to UE via CSI report configuration or via otherconfig.
Editor's note: Whether to specify anything for NW-side additional conditions should be up to RAN1.
4. UE determines the applicable AI/ML functionalities based on NW-side additional conditions (if provided), UE-side additional conditions (internally known by UE) and model availability in the UE. 
5. The UE reports its initial functionality applicability in RRCReconfigurationComplete message.
6.  When provided with periodic CSI configuration consistent with reported UE capabilities in CSI report configuration, upon reporting the applicable functionalities, the UE autonomously activates the applicable AI/ML functionalities. When provided with semi-persistent CSI and/or aperiodic CSI configuration, upon reporting the applicable AI/ML functionalities, applicable AI/ML functionality activation follows the CSI measurement and reporting, i.e., semi-persistent reporting can be activated by MAC CE/DCI and aperiodic CSI reporting can be activated by DCI.
NOTE 1:  The network may transmit an RRCReconfiguration message to the UE including the inference configuration in case inference configuration is not provided in step 3. Upon receiving one or more inference configuration(s), UE shall maintain all the inference configuration(s) no matter the inference configuration is applicable or non-applicable until the network releases it explicitly.
7. When the network has configured applicability reporting via otherconfig, and applicability of the functionality changes, the UE can report updated functionality applicability and non-applicability with relevant cause in UEAssistanceInformation message. When an activated AI/ML functionality becomes non-applicable, the UE does not autonomously deactivate it, but the UE indicates to the network the change in the applicability. Upon reception of UE indication of the functionality becoming non-applicable, the network should deactivate or release this activated functionality. When an activated applicable AI/ML configuration with periodic CSI configuration becomes inapplicable, the UE reports only the measured beams configured in the inapplicable configuration until the network deactivates or release this activated configuration.
Editor's note: FFS signaling details for option B (e.g., whether it is signaling in CSI-Report Config or otherconfig) and activation.
8	

3GPP TSG-RAN WG2 Meeting #130	R2-2504414
St. Julian’s, Malta, 19 – 23 May 2025		

Agenda item:	8.1.2.2
Source:	Nokia, T-Mobile USA Inc., Ericsson, BT plc, Verizon, Deutsche Telekom AG
Title:	On Enhancements for NW Involvement in UE-side DC for BM
WID/SID:	NR_AIML_Air-core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: Using CSI-ReportConfig for data collection configuration candidates also provides the UE-side with information sufficient to determine applicability of a model resulting from the data collection based on the data collection configuration.
Observation 2: RAN1 agreed CSI-ReportConfig can be used to configure resources for UE-side data collection.
Observation 3: Message volume related to providing measurement configuration preferences can be reduced by enabling the UE to provide its preference(s) in RRCReconfigurationComplete after receiving data collection configuration candidates. 
Observation 4: A UE providing its measurement configuration preference prior to needing to make measurements does not result in wasted resources since some UEs with the same preference may be collecting measurements on the same preferred measurement configuration.
Observation : UE-side measurement configuration overhead could be further reduced by introducing a MAC CE to enable and disable UE-side L1 CSI-RS measurement in a UE-side data collection configuration.
And proposed the following:
Proposal 1: Candidate UE-side data collection configuration candidates are provided by the gNB as CSI-ReportConfigs under CSI-MeasConfig and are referred to by CSI-ReportConfigIds. FFS if these are measurement data collection configurations or also inference configurations.
Proposal 2: In otherConfig, UE-side data collection configuration candidates are provided as a list of pairs of CSI-ReportConfigId and a serving cell index, i.e., PCell or SCell index. 
Proposal 3: Preferred UE-side measurement configurations are indicated to the gNB as CSI-ReportConfigIds.
Proposal 4: UE-side measurement configurations are applied without resulting in CSI measurement reports.
Proposal 5: In addition to being able to provide its measurement configuration preference in UEAssistanceInformation, the UE can provide data collection preference in RRCReconfigurationComplete.
Proposal 6: The gNB can enable and disable UE-side L1 CSI-RS measurements in a UE-side data collection configuration with a MAC-CE. FFS whether a new MAC CE is needed or whether a legacy MAC CE can be reused.

3GPP RAN WG2 Meeting #130                                                                                     R2-2504462
St.Julians, Malta, May 19th – 23rd, 2025
	      
Agenda Item:	8.1.2.2
Source:	HONOR
Title:	LCM for UE-side models for beam management
Document for:	Discussion and Decision

Conclusions
In this contribution, we discussed several remaining issues on LCM procedure of UE-sided model for AI/ML based beam management and made the following proposals:
Proposal 1: (Open issue RRC-7) Considering the potential differences between initial and subsequent reports, RAN2 to further discuss the three possible procedures of Option B. It’s suggested that initial report for the applicability/inapplicability of inference related parameters and subsequent report for that of full inference configuration (Alt 3 of Option B) can be considered as a starting point.  
Proposal 2: (Open issue RRC-8) For Option B, after receiving full inference configurations via CSI-ReportConfig in RRCReconfiguration message, UE sends RRCReconfigurationComplete message including applicability and/or inapplicability report of CSI-ReportConfig.
Proposal 3: (Open issue RRC-1) When an inapplicability reporting indicates several inference configurations become inapplicable, they can share a common cause of inapplicability (e.g., low power or UE moving to a new cell), or UE can specify different causes for each configuration.
Proposal 4: For applicability reporting under Option B, an index or ID is introduced to distinguish each set of inference related parameters provided in Step 3.

3GPP TSG-RAN WG2 Meeting #130		       R2-2504487
Malta, Malta: 19th May – 23rd May 2025

Agenda Item:	8.1.2.2
Source:	ASUSTeK 
Title:	Discussion on Remaining RRC open issues on LCM for UE-side models
Document for:	Discussion and Decision

Conclusion
Proposal 1: The cause of inapplicability can be based on how urgent the UE is (e.g., in urgency levels).
Proposal 2: The list of candidate configurations provided by NW can reuse the list of inference configurations (e.g., option A) and the list of inference related parameters (e.g., option B).
Proposal 3: When the UE reports applicability, the UE can start the inference after the UE receives ACK from the NW.
Proposal 4: The UE drops the report when its periodic beam prediction configuration becomes inapplicable.
Proposal 5: Either option A or option B is configured in a RRC message.
Proposal 6: For UE that consistently perform poorly, functionality level handling is not pursued.
Proposal 7: Time information can be included in the applicability/inapplicability report.

3GPP TSG-RAN WG2 Meeting #130	R2-2504554
St.Julians, Malta,  May 19th – 23rd , 2025
Source:	NTT DOCOMO, INC.
Title:	Discussion on LCM for UE-sided model  for Beam Management
Agenda Item:	8.1.2.2
Document for: 	Discussion and Decisions

Conclusion
In this contribution, the applicability determination and reporting, functionality activation/deactivation were discussed. The observations and proposals are summarized as follows:
For determination and reporting without NW-side additional condition in Step 3:
Proposal 1: If the associated ID is unavailable in Step 3, the UE report all the candidate associated IDs associated with each of the applicable or non-applicable inference configurations/inference related parameters in Step 4.
For UE behavior on determination and reporting for Option A and Option B:
Proposal 2: The identical UE behavior on applicability determination and reporting is preferred for both Option A and Option B.
For functionality activation/deactivation:
Observation 1: The UE behaviors on activation/deactivation for applicable functionalities configured in Step 3 for Option A and in Step 5 for Option B are the same.
Observation 2: The UE behaviors on activation/deactivation for non-applicable functionalities configured in Step 3 for Option A need to be clarified.
Observation 3: Both Option 1(UE-based) and Option 2(NW-based) have their own pros and cons considering the NW freedom on CSI resources maintenance, signaling overhead and activation latency.
Proposal 2 A timer(e.g. Holding Timer) is introduced in RRCReconfiguration in Step 3 for Option A, and UE may decide the behavior based on the expiry status of Holding Timer for each of the inference configurations.
-	If the Holding Timer(s) do not expire, UE may follow the behaviors in Option 1(UE-based).
UE shall maintain all the full inference configuration(s) no matter the full inference configuration is applicable or non-applicable until the network releases it explicitly.
For periodic CSI reporting, the UE autonomously activate the applicable functionalities. 
For semi-persistent and aperiodic CSI reporting,
UAI can be sent to update applicability.
UE activates the applicable functionalities by legacy CSI framework.
-	If the Holding Timer(s) expire, UE may follow the behaviors in Option 2(NW-based).
UE shall maintain all the full inference configuration(s) no matter the full inference configuration is applicable or non-applicable until the network releases it explicitly.
UAI can be sent to update applicability.
UE may receive the confirmation/(re-)configuration corresponding to the updated functionality.
Upon receiving the confirmation/(re-)configuration,
For periodic CSI reporting, the UE autonomously activate the applicable functionalities. 
For semi-persistent and aperiodic CSI reporting, UE activates the applicable functionalities by legacy CSI framework.

3GPP TSG-RAN WG2 #130	R2-2504636
St. Julian’s, Malta, 19th – 23rd May, 2025

Agenda Item:	8.1.2.2
Source:	Ericsson
Title:	LCM for UE-side models for beam management
Document for:	Discussion
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1	(RRC-1) In the applicability report (including inapplicability indication for a certain inference configuration), the UE may include the following values related to the unavailability of the AIML model: “preparationOngoing” (if the AIML model is available at the storing entity, and the UE is downloading or about to download it) or “prolongedInapplicability” (if no AIML model is available for downloading).
Proposal 2	(RRC-2) The UE is explicitly configured in otherConfig to send applicability reports in UAI, including applicability reports for updates. Sending inference configurations in CSI-ReportConfig does not implicitly configure the UE to send applicability reports in UAI.
Proposal 3	(RRC-3) The candidate UE data collection configurations from the NW can be the inference configurations.
Proposal 4	(RRC-3) The UE can indicate a preferred candidate UE data collection configuration by including a reference to the inference configuration(s) in the request for data collection.
Proposal 5	(RRC-3) The NW controls via configuration in otherConfig whether the UE is allowed to include preferred candidate configurations in UE data collection request.
Proposal 6	(RRC-4) Related to the handling of the periodic CSI report configuration, RAN2 to discussion the following options:
a.	Upon applicability status change from inapplicable to applicable, the UE continues to operate according to the inapplicable status (no specification impact expected)
b.	If a standardized solution is needed, upon applicability status change from inapplicable to applicable, the UE does not autonomously activate a periodic CSI report configuration, i.e. the NW can activate a periodic CSI report configuration that changed from inapplicable to applicable via the MAC CE used for activating semi-persistent CSI report configuration. If the MAC CE is used for activating a periodic CSI report configuration, it should also be supported that the MAC CE is used for de-activating a periodic CSI report configuration that changed from applicable to inapplicable.
Proposal 7	(RRC-5) It is up to RAN1 whether the UE stops reporting any values or whether it reports other values instead of predictions, when a CSI report configuration changes from applicable to inapplicable.
Proposal 8	(RRC-6) UE configurations related to inference, applicability reporting, performance monitoring and UE data collection (for measurements and for providing assistance information) are released upon entering RRC_IDLE/INACTIVE and upon initiating the RRCReestablishment procedure.
Proposal 9	(RRC-7) Applicability reports for option B (initial applicability and applicability changes) are sent in UAI, assuming that option B parameters are send in otherConfig. This assumption can be confirmed after receiving option B inference related parameters from RAN1.
Proposal 10	(RRC-8) Both option A can option B can be configured at the same time. This assumption can be confirmed after receiving option B inference related parameters from RAN1. FFS further details on the interaction between option A and option B.
Proposal 11	The RRCReconfiguration with inference configuration is sent by the NW after security activation, so the applicability report is sent by the UE also after security activation.
Proposal 12	Revise agreement 3 from RAN2#127bis as: “UE shall report to the network when an applicable AI functionality becomes non-applicable.”