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

Agenda Item:8.3.5
Source: NEC
Title: Discussion on AIML mobility Performance monitoring
Document for: Discussion and Decision
1 

Conclusions
We have the following proposals for performance monitoring of UE and network sided model.
Proposal 1: Network may configure the UE with metric calculation configuration with ETDmax and ETW in the RRC configuration message for performance monitoring.
Proposal 2: Network may configure the reporting type (periodic or event based reporting) of the performance metric for performance monitoring.	
Proposal 3: The network may configure some model switching rules (condition for model change) to improve the overall handover performance for AI/ML based mobility management.

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

Agenda item:	8.3.5
Source:	Qualcomm Incorporated
Title:	Performance monitoring of AI/ML for mobility
WID/SID:	FS_NR_AIML_Mob – Release 19
Document for:	Discussion and Decision

Conclusions
Based on the discussion above, we recommend RAN2 to discuss the observations and proposals below.
Network-side performance monitoring of UE-side model for RRM prediction
Proposal 1: Network side monitoring for RRM prediction of an AI/ML mobility feature can be done by comparing legacy measurement reports with the UE provided predictions.

Proposal 2: If the computed KPIs are not satisfactory, the gNB can disable, deconfigure, or use a different configuration of the AI/ML for mobility feature in the associated location. 
UE-side performance monitoring of UE-side model for RRM prediction
Proposal 3: UE-side monitoring for RRM prediction should be supported. For UE-side monitoring, the gNB provides the UE with the performance monitoring configuration to use which includes the KPIs to compute.
Proposal 4: UE computes the performance KPIs and decides on the continued applicability of a configuration associated with a model.    
Network-side performance monitoring of UE-side model for Event prediction
Proposal 5: For network-side monitoring, the gNB uses the legacy UE event-triggered measurement reports for ground truth information. The network can compare those with the event prediction reports that will be defined as part of this feature which may include the expected time of occurrence of event and probability of occurrence within an indicated time window around the expected time.
Proposal 6: The gNB can then decide on the subsequent action, based on computed KPIs: transmit an LCM request for deactivating the UE-side model or reconfigure the UE.
UE-side performance monitoring of UE-side model for Event prediction
The proposals for UE-side monitoring for Event prediction are similar as those for RRM prediction. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503536
St. Julians, Malta, May 19th – 23rd, 2025
Source:	NTT DOCOMO, INC.
Title:	Discussions on performance monitoring
Agenda Item:	8.3.5
Document for:	Discussion and Decisions

Conclusion
In this contribution, we have the following observations,
Proposal 1
Support only Type 1 Option 1 (NW-side performance monitoring)  and/or Type 1 Option 2 (UE-assisted performance monitoring), i.e.,  decisions of LCM operations are made by the NW, and Type 2 (UE-side monitoring) is not supported.
Type 1-Option 1 (NW-side performance monitoring)
UE sends a report to NW (for the calculation of the performance metric at NW).
The report is at least configured/triggered by the NW.
Type 1-Option 2 (UE-assisted performance monitoring)
UE calculates the performance metrics.
UE either reports the metrics or sends an event based on the metrics.
Proposal 2
RAN2 needs to study specification impacts in detail for each scenario and/or sub-use cases:
For RRM measurement prediction and indirect measurement event prediction,
Intermediate KPIs about the prediction error (e.g., average RSRP differences) can be used as the performance metric for monitoring.
For direct and indirect measurement event prediction, study the following options,
Option 1: Use intermediate KPIs related to the event detection, such as F1-score, miss/false prediction rate, for monitoring.
Option 2: Use the HO KPIs such as HoF rate, Short-ToS rate, PingPong rate, etc.
Proposal 3
RAN2 concludes that there is no specification impact for performance monitoring of the NW-sided model.

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

Agenda Item:	8.3.5
Source:	OPPO
Title:	Discussion on performance monitoring 
Document for:	Discussion, Decision

Conclusion
Here are our observations and proposals:
For UE sided model:
Observation 1: For inter-frequency prediction, a temporal measurement task for predicted frequency layer should be configured temporarily for monitoring purpose
Observation 2: For measurement event prediction, it is possible that ground truth measurement event will never happen during monitoring.
Proposal 1: UE based performance monitoring is excluded for AI mobility use cases
Proposal 2: Both network sided performance monitoring and UE assisted performance monitoring are supported 
Proposal 3: The performance monitoring duration for UE sided model should be limited and configurable
Proposal 4: For UE sided model L3 cell level prediction, the metric to be monitored is L3 RSRP difference as defined in TR 38.744
Proposal 5: For UE side model, the metric is calculated per frequency for L3 cell level prediction i.e. intra-frequency cells should be calculated together.
Proposal 6: For L3 beam level prediction, L3 RSRP difference should be further averaged among beams.
Proposal 7: For temporal domain case A and case B, average L3 RSRP difference within PW is monitoring metric
Proposal 8: L3 RSRP difference should be further averaged within configured monitoring duration 
Proposal 9: For measurement event monitoring, RAN2 need discuss whether intermediate metric e.g. F1 score or system level KPI e.g. HO failure rate should be monitored
Proposal 10: If system level KPI is monitored, monitoring KPI across serving cells need be studied

For network sided model:
Observation 3: For temporal domain case A and inter-frequency prediction, no spec impact is foreseen to monitor performance for network sided model
Proposal 11: RAN2 confirms that UE will not be informed about any network-sided functionality management decision (e.g., selection, (de)activation, switching, fallback, etc.) for AI mobility use case except being configured to provide the required ground truth measurement result(s)
Proposal 12: The gNB is responsible for monitoring its own performance
Proposal 13: UE could be configured to report actual L3 filtered cell or L3 beam level measurement result as ground truth measurement result in order to monitor performance for temporal domain case B and spatial domain prediction in network side.

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

Source:	CATT, Turkcell
Title:	Discussion on performance monitoring
Agenda Item:	8.3.5
Document for:	Discussion and Decision

Conclusion
According to the analysis in Section 2, our observations and proposals are summarized as follows:
General
NW sided AI model
Proposal 1: For NW sided AI model, the performance monitoring should be implemented at NW without any spec impact.
Proposal 2: For calculating the performance metric for network sided model, UE needs to report benchmark/reference to network.
UE sided AI model
Observation 1: For BM with a UE-side AI/ML model, the following performance monitoring operations have been agreed:
Option 1 (NW-side performance monitoring): UE sends reporting to NW (e.g., for the calculation of performance metric at NW) 
Option 2 (UE-assisted performance monitoring): UE calculates performance metric(s), either reports it to NW or reports an event to NW based on the performance metric(s) 
Proposal 3: RAN2 starts the study of performance monitoring for AI mobility of UE-sided model including the following options:
Performance monitoring is triggered by the network:
Option 1 (NW-side performance monitoring): UE sends reporting to NW (e.g., for the calculation of performance metric at NW) 
Option 2 (UE-assisted performance monitoring): UE calculates performance metric(s), either reports it to NW or reports an event to NW based on the performance metric(s) 
Performance monitoring is indicated/requested/reported by the UE

Metrics of UE-side AI/ML model
Proposal 4: For RRM measurement prediction, RAN2 to study the following options which can be used for performance monitoring metric:
Option 1: average of actual RSRP, RSRQ, and SINR over PW window and average of predicted RSRP, RSRQ, and SINR over PW window;
Option 2: average RSRP, RSRQ and SINR difference over PW window
Proposal 5: For measurement event prediction, F1 score can be used for performance monitoring metric.
Observation 2: Maximum EDT plays important role of value of F1 score calculation of AIML model.
Proposal 6: For performance monitoring of indirect measurement event prediction, RAN2 discuss whether maximum ETD is a fixed value or a variable value controlled by NW for F1 score calculation.

Monitoring report
Proposal 7: For UE-sided model monitoring with UE assistance, regarding the monitoring object, it can follow the inference configuration.
Proposal 8: For monitoring report, RAN2 can study the following options:
Option A: Periodical reporting;
Option B: Reporting triggered by NW.
Proposal 9: For direct measurement event prediction, support at least NW triggered reporting .

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

Agenda item:	   8.3.5
Source:		Lenovo
Title:	 Support of model monitoring in AI/ML for mobility
Document for:		Discussion and Decision

Conclusion

Based on the discussion above, we observe:
Observation 1	For direct RRM event prediction, gNB centric performance monitoring may not be practical considering:
a.	The RRM event will not occur or be predicted to occur very frequently when UE is under a cell coverage. There may not be enough samples for gNB to calculate the monitoring metric.
b.	The UE may be handed over to another cell after reporting a predicted RRM event. There may not be enough time for gNB to determine and make use of the monitoring metric before handover.


Based on the discussion above, we propose:

Proposal 1	For RRM measurement prediction with NW-sided model, the performance monitoring is performed at gNB based on UE’s measurement report according to gNB’s configuration.
Proposal 2	For NW-sided model performance monitoring, there is no additional impacts on the UE.
Proposal 3	For RRM measurement prediction and indirect RRM event prediction with UE-sided model, RAN2 considers the following options:
a.	gNB centric performance monitoring: 1) gNB monitors based on measurement report from UE 2) gNB configures UE to calculate and report the performance metric.
b.	UE centric performance monitoring: based on gNB’s configuration , UE measures interested beams/cells without reporting the performance metric to gNB.
Proposal 4	For direct RRM event prediction with UE-sided model, UE centric performance monitoring is supported.
Proposal 5	For direct RRM event prediction with UE-sided model, RAN2 considers gNB centric performance monitoring is not practical.
Proposal 6	To monitor RRM event prediction with UE-sided model, RAN2 studies the scenario wherein a handover is triggered before the time point a RRM event is predicted to occur.

3GPP TSG-RAN WG2 Meeting #130	R2-2503695
Malta, May 19th – 23rd, 2025
Agenda Item:	8.3.5
Source:	InterDigital Inc.
Title:	Performance Monitoring for AI/ML Mobility
Document for:	Discussion
1. 

Conclusion
In this contribution, we discussed performance monitoring and management of NW and UE sided models for AI/ML mobility and the following observations and proposals were made:

Observation 1: An autonomous management decision by the UE may significantly impact the network’s/UEs’ performance. 

Proposal 1: For AI/ML mobility, performance monitoring for NW-side models is up to gNB’s implementation. Assistance information from the UE for enabling the performance monitoring at the gNB (in addition to legacy measurement reports) is FFS. 
Proposal 2: For the performance monitoring of a UE sided model for AI/ML mobility, autonomous management decisions by the UE (with or without decision reporting to the network) are not considered. 
Proposal 3: Consider the NW-decision/NW-initiated management case (framework 1) as the baseline.
Proposal 4: Further consider the NW-decision/UE-initiated (framework 2) and UE-decision/event-triggered as configured by the network (framework 3) management cases.
Proposal 5: For performance monitoring of UE sided model for RRM measurement prediction and indirect measurement event prediction, the UE can be configured to provide RSRP difference between predicted and measured values.
4. 

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

Agenda Item:	8.3.5    
Source:	Mediatek Inc.
Title:	Discussion on Performance Monitoring for AI Mobility   
Document for:	Discussion, Decision

Conclusion
Performance Monitoring Procedure:
NW-sided Model
Proposal 1: For NW-sided model, the performance monitoring and management decisions are made on the NW side and can be fully NW-implemented. UE is only involved in providing the measurement for monitoring based on the configuration provided by NW. 
UE-sided Model
Observation 1: For UE-sided model, it is more efficient to perform monitoring on the UE side, as it does not require sending the inference output and monitoring data to the NW side.
Proposal 2: For UE-sided model, NW-sided monitoring, the performance monitor procedure contains
NW sends monitoring configuration and inference configuration to UE. 
UE reports the monitoring data and inference output based on the corresponding configurations to NW.
NW performs monitoring and makes decisions, which can be fully NW-implemented.
Proposal 3: For UE-sided model, UE-sided monitoring, the performance monitor procedure contains
NW sends monitoring configuration to UE 
UE measures monitoring data and generates monitoring results by comparing inference output and monitoring data. 
(NW-decision): UE reports the monitoring result to NW, and NW makes the management decision. 
(UE-decision): UE makes the management decision and sends the decision to NW.
Inference and Monitoring Configuration:
Proposal 4: The monitoring configuration contains
Measurement object: Describes the information about the measurement target
Monitor report configuration: Describes the report triggering condition, report quantity, and monitoring criteria
Monitoring identity: Provides the mapping of a measurement object, a monitoring report configuration, and an inference identity  
Proposal 5: For UE-sided monitoring, UE compares the monitoring data and inference output based on the monitoring criteria in the monitoring configuration. RAN4 needs to be informed and involved to define the corresponding requirement to determine whether the AI prediction is accurate or not. 
Proposal 6: If the timing and/or period of inference output and monitoring data are not the same,
For NW-sided monitoring, which inference output and monitoring data are used for comparison is up to NW implementation.
For UE-sided monitoring, the monitor result is generated by comparing the closest inference output with the monitoring data. 

TDoc file reading error

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

Agenda Item:		8.3.5
Source:			Huawei, HiSilicon
Title:			Discussion on performance monitoring
Document for:		Discussion and Decision

1   

Summary
In the paper, the performance monitoring on AIML aided mobility are discussed, and the following observations and proposals are provided:
Performance monitoring procedure
Observation 1: In case of temporal domain case B or spatial domain prediction, some RS(es) may be turned off at NW side in case the UE performs prediction for certain RS(es) or time instances.
Observation 2: In case of frequency domain prediction, the UE is not using measurement gaps to predict another frequency RSRP.
Observation 3: For temporal domain Case A prediction, it is feasible for the UE to autonomously switch from predicted measurements to regular measurements as all required RS(es) are continuously provided by the network. 
Observation 4: The HO performance may deteriorate if the UE waits for the NW to switch from predicted measurements to regular measurements.
Proposal 1: As a baseline, functionality management decisions based on performance monitoring are made at the network side. Metrics calculation at both network side and UE side should be supported (as for BM use case).
Proposal 2: RAN2 to discuss whether for temporal domain Case A prediction, UE can autonomously switch from predicted to regular measurements in case of prediction performance deterioration.
Performance metrics
Observation 5: It is not feasible for the UE to measure F1 score and system level KPIs. 
Observation 6: As today, such metrics should be monitored by the network on a long-term basis, but are not suitable for AIML functionality management.
Proposal 3: For RRM measurement prediction and indirect event prediction, RSRP difference or similar metric (e.g. RMSE) should be used as the metric for performance monitoring for both cell-level and beam level measurement predictions. The details of the metric should be defined by RAN4.
Proposal 4: F1 score and system level KPIs are not used for instantaneous AIML model performance monitoring. 
Proposal 5: Unless a way to monitor the performance of direct AIML prediction is identified, direct event prediction should be excluded from further work.

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

Agenda item:	8.3.5
Source:	Nokia
Title:	Discussion on performance monitoring
WID/SID:	FS_NR_AIML_Mob - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: To enable performance monitoring, performance metrics need to be collected by the UE and/or the network.
Observation 2: Additional specification effort may be needed for establishing the ground truth in UE-side monitoring also when monitoring metrics are not reported. 
Observation 3: In measurement reduction use cases, acquiring the ground truth can incur a cost, e.g., reduced measurement reduction ratio, and the measurements required for monitoring can require coordination between the network and the UE. 
Observation 4: In time domain case A and measurement event prediction, in most scenarios the ground truth can be acquired with lower cost and without coordination between the network and the UE.
Observation 5: Online performance monitoring requires calculating metrics over a time window of recent predictions or data instances. The length of this window is a key design choice that presents a tradeoff between robustness and responsiveness.
Observation 6: Short windows are sensitive to changes and allow for a timely detection of model drift, but they are also prone to noise and variance. Long windows provide a more stable estimate of the model’s performance, but they delay the detection of model drift.
Observation 7: AIML configuration support faces challenges such as managing data drift, ensuring timely model updates, and maintaining continuous inference as UE transitions between coverage areas.
Considering legacy systems, examples of detection that the given configuration is no longer applicable are RLF and HOF detection. In case of the former, the UE’s physical layer monitors the DL quality of the primary cell for indicating sync status (i.e., in/out of sync). Upon receiving N310 consecutive out of sync indications, UE starts the T310 timer and upon expiry of timer, UE declares RLF and triggers the subsequent procedures (e.g., re-establishment or any recovery procedure such LTM or CHO recovery). In a similar manner, in case of handover UE monitors for T304 expiry to declare HOF and trigger the subsequent procedures. 
Observation 8: Legacy systems utilize RLF and HOF detection mechanisms to identify when a configuration is no longer applicable, triggering procedures like re-establishment or recovery based on specific timer expirations.
Observation 9: To minimize the number of reconfigurations, UEs need a mechanism to detect and report performance drift or inapplicability of functionalities to the network, while avoiding too early or too late signaling.
Observation 10: In case of periodic predictions, as in RRM measurement prediction, the RLF detection method can serve as an example of how drift may be detected.
And proposed the following:
Proposal 1: Capture the definitions for data, concept, and model drift in the TR.
Proposal 2: As baseline, discussions on monitoring consider UE-sided models. 
Proposal 3: Identify signaling impacts for supporting the reporting of UE-sided model metrics.
Proposal 4: In case of detected performance degradation, fallback to a NW-configured functionality is supported. 
Proposal 5: Study the configuration aspects needed so that the network and the UE can coordinate for establishing the ground truth in case of ML monitoring.
Proposal 6: Discuss the tradeoff between robustness and responsiveness in performance monitoring and consider whether the length of the monitoring window needs to be coordinated between the network and the UE. 
Proposal 7: Study the detection and reporting of inapplicability from UE to NW for AI Mobility use-cases. In the case of periodic predictions, the legacy RLF detection mechanism can be considered as starting point. 

3GPP TSG-RAN WG2 #130	R2-2504297
Malta, Malta, 19th – 23th May, 2025	
Agenda Item:	8.3.5
Source:	Ericsson
Title:	Discussion on Performance Monitoring 
Document for:	Discussion

Conclusion
Based on the discussion in the previous sections we have the following observations:
For the temporal prediction Case A network should configures the UE with performance monitoring configuration associated/linked with the inference configuration.
For temporal prediction case B, network receives prediction of the L3 measurements as part of measurement report, as well as L3 measurements, which act ground truth in the network’s performance monitoring.
For network-side performance monitoring in intra-frequency temporal RRM measurement prediction case B with UE-side model, performance monitoring configuration need to be associated with corresponding inference configuration.
For network-side performance monitoring in inter-frequency RRM measurement prediction with UE-side model, RRM measurement and report of monitoring resources should be associated with corresponding inference configuration, especially when partial monitoring occasion is configured.
For network-side performance monitoring in spatial RRM measurement prediction with cell-level or beam level prediction measurement via UE-side model, the performance monitoring configuration should be associated with corresponding inference configuration.

One solution for simplifying the network side performance monitoring of event prediction is to configure the UE with events with lower thresholds (not triggering HO), and requesting the UE to send a second report if the actual event occurs at the UE. 
Based on the above observations we have the following proposals.

UE conduct performance monitoring according to the performance monitoring configuration configured by the network.
Performance monitoring for RRM measurement (and event) prediction with UE-side model is based on the existing RRM measurement and reporting framework.
Network configures the UE with the performance monitoring window and/or the percentage of the prediction samples for which performance monitoring is needed.
Network configures the UE with the performance monitoring metric/quantity based on which the UE performs monitoring and sends the monitoring report to network.
UE reports performance monitoring outcome in periodic or event triggered basis, according to the performance monitoring report configuration configured by the network. 
For the network side performance monitoring, the UE reports ground truth measurements to enable the network monitoring the performance of the UE AI functionalities.
UE reports L3 measurements as ground truth to the network which are associated to the predictions for the temporal prediction Case B.
Performance monitoring configuration should be associated/linked with the inference configuration for which the performance monitoring is required
Standardisation impact of the network-side performance monitoring of event predictions is FFS. 
For UE-assisted performance monitoring in RRM measurement prediction with UE-side model, UE reports performance metric information to network for performance monitoring at the network side.
For the UE-assisted performance monitoring, study how/when the UE reports the performance monitoring metrics to the network.
Performance metrics for temporal RRM measurement prediction, inter-frequency RRM measurement prediction and spatial RRM measurement prediction with cell-level output via partial beam-level input can be
Alt 1: RSRP difference
Alt 2: statistical information of performance metric (e.g. MSE, mean, [90%] CDF of RSRP difference) 
Performance metrics for spatial RRM measurement prediction with beam-level output via partial beam-level input can be
Beam prediction accuracy
If at least one of Top M beam(s) of resource set(s) for monitoring is among Top K predicted beam(s) of Set A, where M = (1, 2), K = (1, [2]), the prediction is counted as an accurate beam prediction
RSRP prediction accuracy of beams which are within both the Top M beams and the Top K beams (FFS)
Alt 1: RSRP difference
Alt 2: statistical information of performance metric (e.g. MSE, mean, [90%] CDF of RSRP difference) 
Performance metrics for RRM measurement event prediction can be
RSRP prediction accuracy for measurement event prediction
Alt 1: RSRP difference
Alt 2: statistical information of performance metric (e.g. MSE, mean, [90%] CDF of RSRP difference) 
Other performance metrics can be FFS.
For UE-side performance monitoring in RRM measurement/event prediction with UE-side model, UE reports (in)applicability information (based on outcome of performance metric(s)) to network, if configured by the network. 
UE toggles between inference configuration and RRM measurement configuration if inference shows poor performance or if the functionality becomes inapplicable and vice versa. 
UE performs event prediction multiple time before triggering report to the network based on the predicted event, if configured by the network.

3GPP TSG-RAN WG2 Meeting #130                                    R2-2504361
St.Julians, Malta, May 19th – 23rd, 2025
Agenda item:		8.3.5
Source:				Samsung
Title:					Discussion on Performance Monitoring for AI/ML Mobility
Document for:		Discussion & Decision
1	

Conclusion
Proposal 1: For AI/ML for mobility, for NW-side model, the model/functionality management decision can be up to NW implementation and transparent to UE.
Proposal 2: For AI/ML for mobility, for UE-side model, the model management decision can be up to UE implementation and transparent to NW.  
Proposal 3: For AI/ML for mobility, for UE-side model, the functionality management decision can be made by NW as a baseline. FFS. Whether to support UE-side decision.
Proposal 4: For performance monitoring of NW-side model, UE can provide the label data (i.e., actual measurement results) for gNB. The existing measurement/report configuration can be reused to configure UE to report the actual measurement.
Proposal 5: For AI/ML for mobility, for UE-side model, UE can perform the performance monitoring (e.g., performance metric calculation) and report the monitoring results to NW as baseline. 
Proposal 6: For temporal and frequency domain prediction, “L3 RSRP difference” can be used for performance monitoring metric.
Proposal 7: For measurement event prediction, “F1 score” can be used for performance monitoring metric.
FFS. “L3 RSRP difference” can be also used for the indirect prediction.
Proposal 8: For temporal domain prediction cases A and B, the definition of L3 RSRP difference should take into account the temporal gap between the measurement time of the input used for RSRP prediction and that of the real RSRP value.
Proposal 9: For frequency domain prediction, RAN2 can study how to calculate L3 RSRP difference when UE is not able to measure signals on multiple frequency bands simultaneously. 
Proposal 10: For monitoring report from UE to NW in UE-side performance monitoring, RAN2 can study the following two options.
Proposal 11: For UE-side performance monitoring for UE-side model, RAN2 can study the following spec. impact.
4	Reference

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

Agenda item:	8.3.5
Source:	CMCC
Title:	Discussion on performance monitoring for AI Mob
WID/SID:	FS_NR_AIML_Mob
Document for:	Discussion
 

Conclusion
Here are the proposals on performance monitoring for AI Mob.
NW-side performance monitoring for UE-sided model
Proposal 1: For NW-side performance monitoring, the specific KPI to be used is up to NW implementation, and assistance information (e.g. actual measurement results) from the UE is needed for NW to calculate the performance metrics.
Proposal 2: For RRM measurement prediction, the following assistance information can be provided to the network for NW-side performance monitoring:
- For case 1: predicted and actual L1 beam RSRP(s)
- For case 2 and case 3: predicted and actual L3 cell or beam RSRP(s)
Proposal 3: For measurement event prediction, the UE can report the true event occurrence time and predicted event time to the network for NW-side performance monitoring.
UE-side performance monitoring for UE-sided model
Proposal 4: For RRM measurement prediction, L1 RSRP difference and/or L3 RSRP difference calculated by UE can be reported to the network as performance metrics for UE-side performance monitoring.
Proposal 5: For measurement event prediction, the UE can report the following information to the network:
- The true event occurrence time 
- Time difference between true event occurrence time and predicted event time
Performance monitoring for NW-sided model
Proposal 6: For NW-sided model, the network is responsible for monitoring its own performance, and assistance information (e.g. actual measurement results) from the UE can be provided to the network.

4	

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

Agenda Item:	8.3.5
Source:	Turkcell
Title:	Performance monitoring
Document for:	Discussion, Decision
1	

Conclusion

In this contribution, we made the following observations in the previous section for the AI/ML mobility, which are summarized:

Two options, the NW-side and UE-assisted performance monitoring, are chosen for the BM use case. Both options can be reused for AI/ML-aided mobility.

We propose the following based on the discussion in the previous section:

The reported measurement result for NW-side monitoring can be an L3 cell or a beam-level measurement result: actual RSRP and predicted RSRP, missed event detection, false event detection, true event prediction, true time event reporting triggered, and predicted time event reporting triggered.
For UE-assisted monitoring, RAN2 requires the performance metrics calculated on the UE side, including the F1 score, RSRP difference, and the time difference between the true time event reporting triggered and the predicted time event reporting triggered.
NW-side monitoring includes missed event detection, false event detection, and true event prediction.
UE-assisted monitoring can utilize the F1 score.

4