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

Source:	vivo
Title:	Discussion on functionality management for AIML mobility
Agenda Item:	8.3.2
Document for:	Discussion and Decision

Conclusion
In the contribution, we have the following observations and proposals:
Necessity of associated ID
Associated ID is needed for UE-sided model in AI/ML-based mobility to ensure the consistency of DL Tx beam properties between training and inference. 
Associated ID scheme can be applicable for all sub-use cases (1-6) and scenarios (temporal/ frequency/ spatial domain prediction) of RRM measurement prediction, and can be applicable for measurement event prediction. 
Applicability reporting
Take the agreements on applicability reporting of UE-sided model in AI-based beam management as the baseline, including the following aspects:
Support both Option A and Option B like scheme
Upon receiving a full inference configuration, the UE sends the initial applicability report in RRCReconfigurationComplete. UAI can be sent to update applicability.
Upon receiving one or more full inference configuration(s) via RRCReconfiguration message, UE shall maintain all the full inference configuration(s) no matter the full inference configuration is applicable or inapplicable until the network releases it explicitly.
Support the explicit reporting of applicability/inapplicability in the initial report and subsequent reporting when the applicability changes.
Together with inapplicability reporting, UE further indicates a simple cause value of inapplicability.
No prohibit timer is introduced.
RAN2 assumes UE receives RRCReconfiguration message including one or multiple sets of inference related parameters via OtherConfig for option B.
Inference configuration
For RRM measurement prediction of UE-sided model, the network does not configure the input of inference, and the selection of input is up to UE implementation.
Observation 1: The most power consumption of UE measurement is the RF receiver, not the baseband processing. If there is any one cell of a specific frequency that needs to be measured, no gain of measurement gap reduction can be achieved and the gain of power saving is quite limited. 
To achieve the goal of measurement reduction, the prediction should be per-frequency granularity, i.e., all the cells in a frequency layer should be predicted, either for temporal domain, frequency domain, or spatial domain prediction for measurement reduction.
To achieve the goal of HO performance improvement, the prediction can be per-frequency or per-cell granularity.
For RRM measurement prediction of UE-sided model, the network may configure the following parameters in inference configuration:
Temporal domain case B prediction: information related to MRRT, e.g., explicit MRRT value or skipping pattern;
Temporal domain case A prediction: information related to PW length, e.g., explicit PW length value or predicion instance number& instance time gap;
Spatial domain prediction: information related to MRRS, e.g., explicit MRRS value or input/output beam pattern.
For RRM measurement prediction of UE-sided model, no need to include information related to UE speed in inference configuration.
When to perform inference?
Support event-triggered inference for both RRM measurement prediction and measurement event prediction.
Handover model options
For measurement event prediction based on temporal domain case A, the UE reports the predicted timing of the measurement event to the network.
The selection of handover model (e.g., option 1 or 2) of temporal domain case A is up to network implementation, i.e., the network can make HO decision based on either the predicted measurement event or the legacy measurement event.

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

Agenda item:	8.3.2
Source:	Qualcomm Incorporated
Title:	AI/ML for mobility Configuration and Functionality management
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 proposals and observations below.

Proposal 1: The standard will define the AIML mobility feature input and output and not the model input and output.
Proposal 2: In the discussion for specification impact, the main outputs of the AIML for mobility are L3-Beam, L3-Cell RRM, or event prediction.
Proposal 3: “Intra-frequency prediction” refers to when the frequencies of the measured and predicted cells of the AI/ML for mobility feature are the same. “Across-frequency prediction” refers to the case when they are different.

Proposal 4: “Intra-cell prediction” refers to when the same cell is measured and predicted for the AI/ML for mobility feature. “Across-cell prediction” refers to the case when a group of cells is measured and the RRM of, or an event involving, one or more of these cells is being predicted.

Proposal 5: For specification work in AI/ML for mobility, study the following configurations: 

Table 5: Configurations to study

Proposal 6: For configurations #6, #7, RAN2 considers for specification the scenario where the predicted cell is collocated with the cells that are measured. The evaluation of scenarios where the predicted cell is not collocated with the cells that are measured, can be left to the WI phase.     

Proposal 7: For UE-side model for AI/ML for mobility, associated IDs can be introduced for consistency between the inference and data collection/training configurations provided by the network.
Proposal 8: Configuration for #1 – Intra-frequency, intra-cell RRM prediction for a serving cell:
Serving cell frequency, Serving cell ID,
Set B of serving cell beams to measure.
Prediction Window (PW) length, for the case of temporal prediction.
Proposal 9: Prediction reporting configuration for #1 – Intra-frequency, intra-cell RRM prediction for a serving cell:
Periodicity in case of periodic reporting,
Temporal prediction report case:
The period and number of instances within the PW length that the UE can report. 
Proposal 10: The RRM prediction report for #1 – Intra-frequency, intra-cell RRM prediction for a serving cell contains:
Temporal prediction report case:
Predicted cell measurements at future periodic time instances, and the number of such time instances. 
Spatial prediction report case:
Predicted cell measurement at the current time.
Proposal 11: Configuration for #3 – Intra-frequency, across-cell RRM prediction for a serving cell:
For each cell of input cluster:
Cell frequency, Cell ID,
Set B of beams to measure,
Serving cell frequency, Serving cell ID,
For beam prediction:
Set A of serving cell beams.
Proposal 12: The prediction reporting configuration for #3 is similar as that for #1.
Proposal 13: The RRM prediction report for #3 – Intra-frequency, across-cell RRM prediction for a serving cell, contains:
Temporal prediction report case:
Predicted beam and/or cell measurements at future periodic time instances, and the number of such time instances, 
Spatial prediction report case:
Predicted beam and/or cell measurements at the current time.
Proposal 14: The configuration for inference and reporting, and contents of the prediction reports, for configurations #2 and #4 for a neighbor cell is similar as that for a serving cell. 
Proposal 15: Configuration for #7– Across-frequency, across-cell RRM prediction for a neighbor cell:
Neighbor cell frequency, Neighbor cell ID,
Set A of neighbor cell beams,
For each cell of input cluster:
Measured cell frequency, Measured cell ID,
Set B of measured cell beams.
The configuration for reporting and contents of the prediction reports for configuration  #7 is similar as that for a serving cell.
Proposal 16: For Event prediction, besides the configuration for RRM measurement, the gNB provides the UE with a list of events to predict.
Proposal 17: For Event A3 or A5, the gNB can configure the UE for event prediction reporting when the entering condition is met by actual measurements, and the entering condition is satisfied for TTT duration by predicted measurements.
Proposal 18: An Event prediction report includes the expected time of occurrence of event and probability of event occurrence within an indicated time window around the expected time.      

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

Conclusion
In this contribution, we have the following proposals,
Proposal 1
Step 1~5 of the LCM procedure for the UE-sided model for beam management can be reused after the following revisions, 
In Step 1~2,
Under the enquiry, the UE reports capabilities corresponding to the RRM measurement or measurement event prediction.
In Step 3,
For Option A, RRM measurement configurations can be used for the inference configurations.
For Option B, OtherConfig can be used for the inference-related parameter configurations.
In Step 4, UE reports the applicability/inapplicability of the inference or inference-related parameter configurations.
In Step 5, RRM measurement configurations can be used for the inference configurations for Option B.
RAN2 study the detailed contents of the signalings in each step.
Proposal 2
Input/output of the inference
For report quantity, RSRQ should also be considered for inter-frequency mobility.
For inference, the measurements that a UE needs to actually measure and to infer should be configured for the UE.
Proposal 3
Inference result report
For the inference report of RRM measurement prediction and indirect measurement event prediction, how UE processes the measured and predicted values for Layer 3 filtering should be studied and specified.
For RRM measurement prediction and measurement event prediction, enhancements on measurement events are necessary to support UE reporting predicted measurement events. The following two options can be studied,
Option 1: Reuse the current events and allow UE to report the predictions. FFS how to indicate the event is a prediction.
Option 2: Define new events to accommodate the UE predictions.

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

Agenda Item:	8.3.2
Source:	OPPO
Title:	Discussion on functionality management of UE sided model 
Document for:	Discussion, Decision

Conclusion
Here are our observations and proposals:
Observation 1: The key inference parameter for UE to judge applicability is limited for AI mobility use case/scenarios
Observation 2: there is either no generalization issue or there is with easy solution for AI mobility so far based on simulation result
Observation 3: For RRM measurement prediction, Reporting L1 beam level measurement is not necessary
Observation 4: After receiving a future measurement event with timing information of measurement event, network can know when entering condition could be met.
Observation 5: Whether handover command is transmitted upon entering condition could be left for network’s implementation

Proposal 1: To agree following general terms for AI mobility SI:
Supported functionalities: refer to functionalities that UE can indicate by using UE capability information via RRC signalling
Applicable functionalities: refer to functionalities that the UE is ready to apply for inference
Activated functionalities refers to functionalities already enabled for performing inference
Proposal 2: Partial configuration in step 3 is supported for AI mobility use cases/scenarios
Proposal 3: UE responses applicable key inference parameter(s) in step 4 if they are configured in step 3
Proposal 4: In step 3, a RRM measurement configuration with key inference parameters can be configured via RRCReconfiguration message to UE
Proposal 5: in step 4, UE report applicability information via RRCReconfigurationComplete message back to gNB
Proposal 6: 2	Upon receiving one or more RRM measurement configuration via RRCReconfiguration message, UE shall maintain all the RRM measurement configuration(s) regardless of applicability until released by network explicitly
Proposal 7: If full RRM measurement configuration together with key inference parameters is configured in step 3 and it is applicable, UE need feedback measId directly
Proposal 8: If full RRM measurement configuration together with key inference parameters is configured in step 3 and it is not applicable, UE could feedback inapplicable key inference parameters
Proposal 9: When a functionality becomes non-applicable the UE doesn’t autonomously deactivate. NW is expected to deactivate active functionality when it receives report from UE that it is non-applicable
Proposal 10: During mobility, target gNB can check applicability via handover command message i.e. RRCReconfiguration and UE can response with RRCReconfigurationComplete.
Proposal 11: No associated Id is needed for AI mobility
Proposal 12: For RRM measurement prediction, only L3 cell/beam level measurement results are reported 
Proposal 13: legacy principle i.e. L3 beam measurement is always reported together with L3 cell measurement result should be still valid i.e. it is not necessary to introduce procedure to report L3 beam level measurement result alone
Proposal 14: For temporal domain case A, one or more instances of predicted measurement results in PW per one cell or beam are reported in one measurementReport message
Proposal 15: For temporal domain case A, one or more instances of measurement results in OW per one cell or beam are reported in one measurementReport message
Proposal 16: For temporal domain case B, one measurement result per one cell or beam is reported in one measurementReport message. 
Proposal 17: For temporal domain case B, one indication marking actual or predicted measurement result should be also reported along with the measurement result
Proposal 18: For frequency domain prediction and spatial domain prediction, one predicted measurement result per one cell or per beam is reported in one measurementReport message.
Proposal 19: For L3 beam prediction, predicted measurement result(s) should be distinguished from actual measurement result(s).
Proposal 20: For measurement event prediction based on temporal domain case B, spatial domain and frequency domain prediction, UE need report predicted measurement event by following legacy procedure i.e. no spec impact is foreseen.
Proposal 21: For measurement event prediction based on temporal domain case A, apart from measurement event and relevant measurement result, UE should also provide the timing information when corresponding TTT timer expires in future.
Proposal 22: UE reports measurementReport message containing a future measurement event when UE predicted it for measurement event prediction based on temporal domain case A.

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

Agenda Item:	8.3.2
Source: 	NEC
Title:  	Discussion on AIML mobility functionality management
Document for:	Discussion and Decision
1 

Conclusions
Proposal-1: enhance measurement report to include the following information:
- predicted time information of event fulfilment  
- predicted time information of future measurement results
Proposal-2: The UE can be configured to perform inference only when it is in high mobility and/or at the cell edge. 
Proposal-3: The UE can stop the AI/ML based inference based on the low battery state with the help of thresholds set in the inference configuration.
4 

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

Source:	CATT, Turkcell
Title:	Functionality management of AIML mobility
Agenda Item:	8.3.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the specification impact for AIML mobility, and the observations and proposals are summarized as follows:
RRM measurement prediction
Applicability report
Proposal 1: RAN2 discusses which option is adopted for network additional condition for RRM measurement prediction:
Option 1: Network additional condition is not needed, considering the good performance of model generalization;
Option 2: Network additional condition is needed, which can be configured to the UE using associated ID or specific cell configuration.
Inference configuration and report
Proposal 2: For UE-sided model inference of RRM measurement prediction, the MO need to be configured as inference inputs for RRM framework.
Proposal 3: For measurement results prediction, the inference configuration for intra-frequency temporal domain case A can include the timing information, e.g., the minimum duration when the predicted measurement results should be obtained.
Proposal 4: For intra-frequency temporal domain case A, RAN2 to discuss which option is included in the measurement report of RRM measurement prediction:
Option 1: The last predicted measurement result in PW;
Option 2: The average measurement result in PW；
Option 3: The sample measurement result in PW.
Proposal 5: For intra-frequency temporal domain case B, RAN2 to discuss what is configured for the inference of RRM measurement prediction:
Option 1: the network configures the MRRT and the UE derives the timing configuration according to MRRT which may include the skipping pattern;
Option 2: the network configures the periodicity and the timing offset of the predicted measurement.
Proposal 6: For inter-frequency prediction, the frequency information of the predicted measurement needs to be configured for the UE for the inference of RRM measurement prediction.
Measurement event prediction
Applicability report
Proposal 7: For indirect measurement event prediction, the applicability reporting is the same as that for RRM measurement prediction.
Proposal 8: For direct measurement event prediction, for applicability reporting,
new UE capability is needed, e.g., whether the UE supports direct measurement event predication.
Inference configuration and report
Proposal 9: For indirect measurement event prediction, the model inference configuration e.g., input and output configuration of model inference is the same as that for RRM measurement prediction.
Proposal 10: For indirect measurement event predication, event triggered reporting should be supported.
Proposal 11: For temporal domain case B, frequency domain, and spatial domain prediction, the legacy RRM measurement reporting can be reused for indirect measurement event predication.
Proposal 12: For temporal domain case A, the UE can report the predicted occurrence time for the indirect predicted measurement event. 
Proposal 13: For direct measurement event prediction, the input/output configuration of model can be configured from network to UE:
Input configuration: measurement resources of serving/neighbouring cells, event configuration parameters (e.g., TTT), other configuration information is FFS;
Output configuration: the probability of event occurrence within a time window.
Proposal 14: For direct measurement event prediction, enhanced RRM measurement reporting mechanism is needed for the inference result reporting, e.g. reporting the probability of event occurrence within a time window.
When to perform inference
Proposal 15: For Intra-frequency temporal domain case A, the inference is performed periodically for RRM measurement predication.

3GPP TSG-RAN WG2 Meeting #130	                                          R2-2503638
Malta, 19 – 23, May, 2025  							    

Source: 	Xiaomi
Title:  	Discussion on inference solution and functionality management for UE sided model
Agenda Item:	8.3.2
Document for:	Discussion and Decision

Conclusions
According to the analysis given above, we have the following observations and proposals:
Temporal domain case B
Observation 1: NW-side model in temporal domain case B can neither reduce measurement nor reduce RS signaling.
Proposal 1: Only UE sided model is supported in temporal domain case B. 
Proposal 2: In temporal domain case B, UE can use predicted L3 cell level measurement result on skipped instances instead of measured results in legacy procedures (e.g. measurement event evaluation, S criteria evaluation, measurement report, etc).
Frequency domain prediction
Proposal 3: In frequency domain prediction, UE can report following predicted results to NW. It’s up to NW to decide how to use the predicted results.
the predicted L3 cell level measurement results, which includes predicted measurement results, cell ID and frequency
the fulfilled event which is evaluated based on predicted L3 cell level measurement results on frequency domain
Temporal domain case A
Proposal 4: UE can report the predicted L3 cell level measurement results, which includes predicted measurement results, cell ID and timing. It’s up to NW to decide how to use the predicted results in Temporal domain case A.
Proposal 5: RAN2 discuss the which inference result is reported to NW within PW in temporal domain case A:
predicted measurement result on each timing instance
average measurement results over PW
measurement result on last timing instance
measurement result fulfilling certain condition, e.g. higher/lower than certain threshold, and corresponding timing instance
Measurement event prediction
Proposal 6: UE reports the predicted measurement event when it’s predicted to be fulfilled. It’s up to NW implementation when to transmit the handover command.
Proposal 7: UE reports the timing (window), meas ID and triggered cell ID of predicted measurement event in both indirect and direct event prediction. Furthermore, UE can also report the predicted measurement results if indirect prediction is used and the probability if direct prediction is used.
Spatial domain prediction
Observation 2: Only intra-cell spatial domain prediction feasibility has been evaluated by RAN1 for AI air BM. There’s no consensus on whether inter-cell spatial domain prediction is feasible without simulation evaluation.
Proposal 8: Spatial domain prediction is considered as a low priority use case.
L3 beam prediction
Proposal 9: For L3 beam level measurement prediction, all the following sub cases can be considered,
Sub-use case 1: L1 beam-level measurement result(s) is predicted based on actual L1 beam-level measurement result(s) and then L3 beam-level measurement result(s) is generated 
Sub-use case 2: L3 beam-level measurement result(s) is predicted based on actual L3 beam-level measurement result(s)
Sub-use case 3: L3 beam-level measurement result(s) is predicted based on actual L1 beam-level measurement result(s)
Proposal 10: The temporal domain L3 beam-level measurement prediction can be considered, where future or latest L3 beam-level measurement result(s) can be predicted.
Proposal 11: The frequency domain L3 beam-level measurement prediction is not considered in Rel-19 SI.
Proposal 12: The spatial domain L3 beam-level measurement prediction is low priority.
Functionality applicability management
Observation 3: Larger MRRT results in larger performance degradation compared with baseline for both GC#1 and GC#2 on FR1 case B.
Proposal 13: Associated ID is needed to determine the functionality applicability in AI mobility. 
Proposal 14: Neighbour cell associated ID can be provided to UE. The associated ID can be applicable per frequency.
Proposal 15: RAN2 study option A and B for the applicability report,
Option A: explicit inference configuration
Option B: inference related parameters for applicability report only
Proposal 16: In option A, MeasId can be use as baseline to identify a functionality. In option B, the inference related parameters can include following,
Input cell/frequency/beam
Output cell/frequency/beam
L3 filter parameter
Measurement event parameter, e.g. offset, threshold, TTT
Report content
Proposal 17: In addition, AI specific parameters shall also be provided in both option A and B, including following information, 
MRRT for temporal domain case B
PW for temporal domain case B and event
Inference control
Proposal 18: The UE can perform the inference of applicable functionality if event (A2, A3, A5 alike event) fulfilled, which is configured by NW

3GPP TSG-RAN WG2 Meeting #130											R2-2503656
Saint Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	8.3.2
Source: 	Sharp
Title:  	Discussion on Inference Reporting for AI/ML-based Mobility
Document for: 	Discussion

Conclusions
In this contribution, we have the following observations:
Observation 1: AI/ML mobility functionalities can be activated using the LCM framework developed for beam management as the framework.
Observation 2: The measurement events A1 to A6 can be considered as the candidate mobility events for AI/ML-based mobility functionality.
Observation 3: Measurement result predictions and measurement event predictions are inherently different from the corresponding legacy (or actual) measurement results, even though the two entities might represent the same quantities, e.g. RSRP and predicted RSRP or legacy A3 event and predicted A3 event.
Observation 4: RRM measurement predictions for SpCell and neighboring cells may be utilized by the UE to evaluate predicted measurement events. 
Observation 5: Considering prediction results for UE mobility along with legacy measurement results requires clear definitions for the prediction-based measurement reporting criteria.
Based on the observations, the following proposals are made.
Proposal 1: RAN2 to discuss the relationship between legacy measurement results and events, and the corresponding predicted measurements and events.
Proposal 2: Predicted measurement events and respective conditions for measurement report triggering are defined in relation to legacy measurement events (e.g. A3 event and predicted A3 event).
Proposal 3: The legacy measurement report events and the corresponding triggering criteria configurable to UEs can be extended to also consider prediction-based information when available, with similar parameters (TTT, hysteresis, offsets) as the legacy measurement events.

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

Agenda item:	   8.3.2
Source:		Lenovo
Title:                             Functionality Management for AI/ML Mobility
Document for:		Discussion and Decision

Conclusion

Based on the discussion above, we request RAN2 to discuss and agree on the following proposals:

Proposal 1: UE can report explicit applicability/inapplicability in the initial applicability report via RRCReconfigurationComplete and subsequently only report the change in applicability via UAI.
Proposal 2: Associated ID(s) (if available) are provided to UE for applicability determination. RAN2 should discuss the scope of associated ID(s) based on the following options:
Per cell associated ID(s)
Per area/group of cells associated ID(s)
RRM Measurement prediction
Proposal 3: Temporal, spatial, and frequency domain predictions can be configured simultaneously.
Proposal 4: After receiving the inference configuration for RRM measurement prediction and reporting the applicable AI/ML functionalities, the inference can be triggered by UE immediately or upon a certain event.
Proposal 5: RAN2 clarifies if multiple periodic RRM measurement predictions (e.g., temporal/spatial predictions) can be activated at the same time.
Proposal 6: For RRM measurement prediction, one set of inference configuration can be identified with a measId. 
Proposal 7: UE may perform measurement prediction for non-serving cells if the channel quality of the serving cell is worse than a configured threshold. FFS, if the threshold is from legacy s-measureconfig IE or a separate threshold.
Measurement event prediction
Proposal 8: After receiving the inference configuration for RRM event prediction, the inference can be triggered by UE immediately or upon a certain event.
Proposal 9: Network can configure UE to predict whether the entering condition or the leaving condition of a concerned RRM event will be met.
Proposal 10: The prediction window is configured for UE. If a prediction window is provided, UE is expected to predict whether an event occurs within the prediction window.
Proposal 11: UE may perform measurement event prediction based on a trigger condition, e.g., the channel quality of the serving cell becomes bad.

3GPP TSG-RAN WG2 Meeting #130	R2-2503693
Malta, May 19th – 23rd, 2025
Agenda Item:	8.3.2
Source:	InterDigital Inc.
Title:	Functionality management for UE sided model for RRM measurement prediction
Document for:	Discussion
1. 

Conclusion
In this contribution, we discussed LCM and specification impact of the RRM measurement prediction functionality and the following observations and proposals were made:
Observation 1: For temporal and frequency domain predictions, it is not necessary for the UE to be configured for set A/B configurations, even for the RRM sub-use cases where the input to the AI/ML model is L1 beam measurements. 
Observation 2: For temporal domain case A, observation window duration is up to UE implementation. 
Observation 3: For temporal domain case B, UE may use different skipping patterns to achieve the same level of MRRT. The network may not need to know the skipping patterns being used but knowing it will enable further UE/network energy saving.
Observation 4: Though initial model generalization results across different network configurations have shown good results, only a handful of configuration parameters and parameter values were considered.
Observation 5: Performing RRM measurement predictions all the time is highly inefficient (e.g., when the UE is under excellent serving cell coverage).

Proposal 1: For the temporal and frequency domain RRM measurement prediction, the inference input is provided at cell level for all sub-use cases (i.e., if the input to the model is beam measurements, it can be left to UE implementation to decide which beams of the cells to be used for the prediction.). FFS on how to configure inference input for the spatial domain.
Proposal 2: For temporal case A, the UE is configured with the prediction window length.
Proposal 3: For temporal case B, the UE is configured with the MRRT to use and may optionally be configured with a skipping pattern to apply to achieve the MRRT (e.g., among the skipping patterns supported by the UE).
Proposal 4: For temporal domain case B and frequency domain RRM measurement prediction, legacy RRM measurement reporting configuration can be reused.
Proposal 5: For temporal domain case A RRM measurement prediction, enhancements are needed regarding the predicted measurements to be included in the measurement report. The details are FFS (e.g., number of samples or which samples within the prediction window to be reported).
Proposal 6: The UE may be configured with one or more associated IDs (corresponding to the serving and neighbor cells) along with the inference configuration for the RRM measurement prediction. The details of the associated ID configuration are FFS.
Proposal 7: The UE determines that an RRM measurement prediction configuration is applicable if the UE has at least one model that satisfies all the following:
The model was trained under the indicated network side additional conditions (e.g., if associated IDs are provided).
The model was trained under the current UE side additional conditions.
The model can perform the predictions under the indicated inference configuration.
Proposal 8: The UE can be configured to start performing the RRM measurement predictions in one of the following ways:
automatically upon the reception of the inference configuration and determining that it has an applicable model
upon the fulfillment of further conditions. The details of the conditions are FFS (E.g., configuration like the s-measure for starting inference). 
4. 

3GPP TSG-RAN WG2 Meeting #130													     R2-2503705
St. Julians, Malta, May 19th – 23rd, 2025									  
Agenda item:	8.3.2
Source:	Apple
Title:	On functionality of UE-sided AI/ML mobility
Document for:	Discussion and Decision

1	

Proposals
Proposal 1: event prediction, temporal domain prediction case A, temporal domain prediction case B, frequency domain prediction, spatial domain prediction (if specified), and beam level prediction should have separate capability and applicability signalling for each feature.
Proposal 2: postpone the discussion about accuracy (in the context of potential signalling enhancements) till there is enough progress in RAN4.
Observation 1: prediction window length depends on AI/ML model complexity and factors such as UE speed.
Proposal 3: define a UE capability (and the corresponding applicability signalling) for each model/feature of how far into the future (defined by times t1 and t2) the model can make a prediction with a required accuracy.
Observation 2: it is likely that UE implementation would use different AI/ML models to predict different A1-6 events.
Proposal 4: AI/ML measurement event prediction UE capability and applicability is per A1-6 event. Alternatively, we can consider separate capability for:
A1 and A2 (for serving cell event prediction)
A3 and A4 (for neighbour cell event prediction, where UE may have a dedicated model, e.g. for inter-frequency inter-cell measurements)
A5 and A6 (both serving and neighbour cell predictions)
Observation 3: a model may become “momentarily inapplicable” (e.g. when UE momentarily changes speed); notifying the network for such momentary inapplicability would be a waste of UE, network and air interrace resources.
Proposal 5: when the UE is configured to perform inference, it is allowed to use AI/ML or not, as long as it satisfies the performance requirements.
Proposal 6: for RSRP prediction and reporting, it is expected that the configured measurement gap may be reduced, in accordance with UE capabilities.
Observation 4: HO preparation optimization works and provides gains, as has been established in the evaluation.
Observation 5: HO preparation often takes longer than 50ms.
Observation 6: 50ms wait in suboptimal radio conditions rarely results in HO failure but does affect performance.
Proposal 7: to define “predicted A1-A6 events”, i.e. new events modelled similarly (but not identically) to A1-A6 which are triggered based on both real and predicted measurements.
Observation 7: one example of “network additional conditions” very relevant to mobility is active antenna systems capable of changing antenna tilt to trade-off coverage for capacity; this has significant impacts on mobility.
Proposal 8: association id reflecting changes in network configuration is beneficial.

5	

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

Agenda Item:	8.3.2    
Source:	Mediatek Inc.
Title:	Discussion on Functionality Management for AI Mobility 
Document for:	Discussion, Decision

Conclusion
Applicability Report Procedure:
Proposal 1: The general applicability report procedures agreed upon in RAN2 AI-PHY can be applied as the baseline for AI mobility use cases. RAN2 needs to discuss the necessary information required in the full inference configuration and the inference parameters corresponding to Option A and Option B for AI mobility.
Inference Configuration:
Full inference configuration:
Observation 1: For UE-sided model AI mobility, NW needs to configure information about the predicted target to UE. This may include the timing and frequency location of the predicted target and the related information to perform inference such as PW length, skipping pattern, MRRT, etc.   
Observation 2: Based on the measurement object, predicted object, and report configuration, UE can realize the task of AI inference (the sub-use case of AI mobility) without explicit description.

Proposal 2: RAN2 consider the inference configuration which contains
Measurement object: Describes the information of measurement/observed target.
Predicted object: Describes the information of inference/predicted target.
Report configuration: Describes the triggering condition and report quantity for the measurement report.
Inference identity: Provides the mapping of a measurement object, a predicted object, and a report configuration.
Proposal 3: The predicted object contains 
Timing and frequency information, e.g., smtc, ssbfrequency, subcarrier, etc. 
PW length (for temporal case A)
Skipping pattern, MRRT (for temporal case B)
Measured and predicted beam/cell pattern, MRRS (for spatial domain prediction)
The details of the content can be FFS. 
Inference parameters:
Proposal 4: RAN2 consider “inference parameters” in measurement configuration, which provides the necessary information for UE to examine the applicability, it may contain
PW length (for temporal case A)
Skipping pattern, MRRT (for temporal case B)
Measured and predicted beam/cell pattern, MRRS (for spatial domain prediction)
Measured and predicted frequency (For inter-freq domain prediction)
The detailed configuration is FFS.
Associated ID:
Observation 3: NW antenna downtilt angle may impact the coverage of cells and thus affect the mobility behavior. It may be one of the possible factors that will affect the AI mobility performance and be covered by the associated ID implicitly. 
Proposal 5: RAN2 identifies the NW-sided assistance information required for each use case, for example, the NW antenna downtilt angle. Others can be FFS. FFS those NW-sided assistance information should be provided explicitly or covered implicitly by an associated ID. 

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130                                  R2-2503983
St.Julians, Malta, May 19th – 23rd, 2025                                                                                                              
Agenda item:		8.3.2 
Source:				Samsung
Title:					Discussion on functionality management for UE-side model
Document for:		Discussion & Decision
1	

Conclusion
Based on the above, RAN2 is requested to discuss and agree on the following proposals:
Capability/Applicability reporting:
Proposal. 1: To facilitate discussion in AI/ML for mobility SI/WI, RAN2 adopt the definition of supported/applicable/activated functionalities agreed in Rel-19 AI/ML for air WI.
Proposal. 2: For AI/ML for mobility, UE can report the supported AI/ML-enabled Features/FGs and supported functionalities to NW via UECapabilityInformation message.
Observation. 1: For BM use case, the associated ID is introduced to allow NW to implicitly indicate the consistency of NW’s beam configuration (e.g., antenna pattern, tilting, codebook configuration that can have impact on analog beam pattern of a certain CSI-RS/SSB index).
Observation. 2: For AI mobility, the following use cases utilize the beam-level measurement/prediction, which requires the consistency of NW’s beam configuration across training and inference.
- Temporal domain prediction Case A&B with sub-use cases 1/3.
- Frequency domain prediction with sub-use cases 1/3.
- Measurement event prediction with indirect approach reusing RRM measurement prediction with sub-use case 1/3.
- L3 beam level measurement prediction
Proposal. 3: For AI/ML for mobility, associated ID can be required for the use cases utilizing beam-level measurement/prediction to guarantee the consistency of NW’s beam configuration across training and inference.
Inference configuration:
Common part:
Proposal. 4: For all the use cases agreed in AI for mobility, NW can indicate the target MO (Measurement object) for which the UE performs the prediction (e.g., RRM measurement/event prediction) as part of inference configuration.
Proposal. 5: For all the use cases agreed in AI for mobility, NW can indicate the list of target cells for which the UE performs the prediction as part of inference configuration.
Proposal. 6: For all the use cases agreed in AI for mobility, NW can indicate NW-side additional condition (e.g., associated ID) for the applicability check as part of inference configuration if needed.
Temporal domain Case A:
Proposal. 7: For temporal domain Case A, NW can indicate the prediction window length (i.e., how far the UE should predict the measurement results in time domain) as part of inference configuration.
Temporal domain Case B:
Proposal. 8: For temporal domain Case B, NW can indicate either the MRRT value to use or the accuracy requirement (e.g., tolerable RSRP difference) to meet as part of inference configuration.
Proposal. 9: For temporal domain Case B, NW can configure UE to report its measurement skipping pattern as an assistance data for NW. 
Measurement event prediction:
Proposal. 10: For measurement event prediction, NW can include the indication to configure UE to initiate the measurement reporting procedure when it predicts the target event within PW as part of inference configuration.
Proposal. 11: For measurement event prediction, NW can indicate the prediction window length (i.e., how far the UE should predict the measurement event in time domain) as part of inference configuration.
Proposal. 12: For measurement event prediction, NW can indicate the target event (e.g., eventId for eventAx) for which the UE performs the measurement event prediction as part of inference configuration.
Frequency domain prediction:
Proposal. 13: For frequency domain prediction, NW can indicate both the target MO/cell for which the UE perform the prediction and the input MO/cell for which the UE perform the measurement for input data as part of inference configuration.
L3 beam-level prediction:
Proposal. 14: For L3 beam-level prediction, NW can indicate the prediction window length (i.e., how far the UE should predict the measurement results in time domain) as part of inference configuration.
Proposal. 15: For L3 beam-level prediction, NW can indicate the maximum number of beams to report (i.e., K) as part of inference configuration (to configure UE to report Top-K beam indexes).

Inference report:
Temporal domain Case A:
Proposal. 16: For temporal domain Case A, UE can report the predicted results for the multiple time instances within PW for the target cells. The target cells can be determined based on the inference configuration from NW.
Temporal domain Case B:
Observation. 3: For temporal domain Case B, UE can trigger the measurement reporting and report the latest (predicted) measurement results as in the legacy. The only difference compared to the legacy is that some of the measurement results used for measurement reporting are not the actual measurement results but the predicted ones. 
Proposal. 17: For temporal domain Case B, UE can trigger the measurement reporting and report the latest (real/predicted) measurement results as in the legacy. No further enhancement is needed for measurement (inference) reporting.
Measurement event prediction:
Proposal. 18: For measurement event prediction, the UE can report the latest measurement result and/or the predicted results for the multiple time instances for the applicable cells. The applicable cells can be the cells for which the event is predicted.
Proposal. 19: For measurement event prediction, the UE can report some additional information for the predicted event. The additional information can be the expected occurrence time (for indirect method) or the probability of event occurrence within PW (for direct method).
Proposal. 20: For measurement event prediction, UE can continue the measurement event prediction after sending the first event prediction report. If the event prediction result is updated compared to the last report, the UE can report the updated result to NW.
Frequency domain prediction:
Proposal. 21: For frequency domain prediction, UE can report the latest predicted measurement result for the target cells. The target cells can be determined based on the inference configuration from NW.
L3 beam-level prediction:
Proposal. 22: For L3 beam-level prediction, UE can report the beam-level prediction results for the best neighbor cell. The best neighbor cell can be determined based on the actual or predicted measurement results. 
Proposal. 23: For L3 beam-level prediction, the beam-level prediction results for the best neighbor cell can include the predicted Top-K beam indexes and/or the predicted beam-level measurement results for the multiple time instances within PW for the Top-K beams.

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

Agenda Item:		8.3.2
Source:			Huawei, HiSilicon
Title:			Discussion on functionality management for UE sided model
Document for:		Discussion and Decision

1   

Summary
In the paper, the functionality management for UE-sided model is discussed, and the following observations and proposals are provided:
Configuration of different use cases and sub-use cases
Observation 1: RAN4 has not studied other quantities besides RSRP so far.
Observation 2: From RAN2 point of view, there is no additional work needed to support prediction for quantities other than RSRP.
Proposal 1: Whether to include SINR or RSRQ in normative phase should be decided by RAN4, from RAN2 signalling point of view, all quantities can be supported with no additional work.
Proposal 2: Model related choices (i.e., cluster-based vs. cell-based, L1 filtering, RRM sub-use cases, OW length, direct vs. indirect) can be up to UE implementation unless a requirement is identified to specify them.
Proposal 3: The following items should be configurable by the gNB for prediction:
Measurement framework parameters: measurement object, measurement report, measurement ID
Prediction related parameters: PW length, MRRT, MRRS; FFS how exactly these are configured, e.g. explicitly or via other parameters (e.g. using SMTC for MRRT or set A/B beams for MRRS)
Reporting aspects for different use cases and sub-use cases
Observation 3: For RRM measurement prediction, whether an indication about the reported result being either an actual measurement or predicted measurement depends on whether UE can be configured with AI and non-AI RRM measurement configurations at the same time and also whether UE autonomous fallback is allowed. 
Observation 4: For the event prediction, HO Option 1 requires the UE to report the predicted event to allow the network to prepare the HO in advance to ensure timely HO when the actual event occurs. In this case, it will require the UE to inform the NW that the earlier event is predicted while the latter is actual event.
Observation 5: The exact time when the UE needs to perform inference depends on certain use case and reporting types.
Observation 6: UE vendors may have different strategies on when to perform inference.
Proposal 4: RAN2 to discuss whether the indication for whether the reported result (i.e. measurement or event) is a predicted or an actual measurement should be supported for different use cases.
Proposal 5: For both event triggered reporting of predicted RRM measurements and measurement reporting during predicted event reporting, it should be possible for the UE to report predicted measurement results corresponding to multiple time instances, e.g. on top of the result corresponding to TTT expiry time, the one related to PW end. 
Proposal 6:  The exact time of triggering inference can be up to UE implementation as long as the UE follows the inference configuration provided from the network, e.g. PW length, time instances to be reported etc. 

Associated ID
Observation 7: Associated ID is needed for some scenarios, e.g., when the NW may turn some cell(s) off for NW energy saving.
Observation 8: The model prediction accuracy was very good in the studied generalization scenarios.
Proposal 7: Associated ID should be optionally configurable for training and/or inference (i.e. it is not mandatorily required for all training/inference configurations). 
Proposal 8: As a baseline, associated ID is cell-specific, similarly as for AIML for BM use case. 

Applicability reporting
Proposal 9: Both option A and option B type of applicability reporting should be supported for mobility prediction configurations.
Proposal 10: For option B, at least the following parameters are needed for applicability determination (depending on the use case): PW length, MRRT, MRRS, and optionally associated ID. 
Proposal 11: As a baseline, functionality management decisions are made at the network side based on the applicability reports received from the UE.
Proposal 12: RAN2 to discuss whether for temporal domain Case A prediction, UE can autonomously switch from predicted to regular measurements in case a certain functionality becomes inapplicable.

4   

3GPP TSG-RAN WG2 #130	R2-2504131
St. Julian’s, Malta, May 19th – 23rd, 2025	
Agenda Item:	8.3.2 Functionality management
Source:	Ericsson
Title:	Inference and report configuration of UE sided model
Document for:	Discussion
1	

Conclusion
Based on the discussion in the previous sections we propose the following:

Proposal 1	MeasConfig IE, including the triplet MeasId, MeasObjectNR and ReportConfigNR IEs, is used for the inference configuration.
Proposal 2	The Set A and Set B is configured within the MeasObjectNR.
Proposal 3	For temporal and spatial domain predictions, the same MeasObjectNR is used to configure both Set A and Set B. For frequency prediction, Set A and Set B are configured using two (or more) different MeasObjectNR IEs, one per each frequency.
Proposal 4	The inference configuration for temporal domain prediction (Case A) includes at least: prediction window and prediction samples interval.
Proposal 5	The inference configuration for temporal domain prediction (Case B) includes at least: MRRT and measurement instances skip pattern.
Proposal 6	No additional configuration is needed for spatial and frequency domain prediction, besides Set A and Set B definition.
Proposal 7	The ReportConfigNR IE is used to configure the inference reporting.
Proposal 8	Both periodical and event triggered reporting are supported.
Proposal 9	The reporting for temporal domain prediction Case A includes: number of predictions, list of predictions for each prediction sample.
Proposal 10	The reporting for temporal domain prediction Case B includes: list of predictions (besides the RRM measurements).
Proposal 11	The reporting for spatial domain prediction includes: cell ID, list of predictions.
Proposal 12	The reporting for frequency domain prediction includes: frequency, cell ID, list of predictions.
Proposal 13	The predicted events (e.g., pA1, pA2,…pA6) are configured in the ReportConfigNR IE in separate fields specific to event predictions.
Proposal 14	ReportConfigNR containing the predicted event configuration is associated with the MeasObjectNR including the prediction configuration, via the triplet: measId, measObjectId, reportConfigId.
Proposal 15	RSRQ and SINR can be considered as baseline quantities in the event configuration, besides RSRP.
Proposal 16	For the initial inference configuration, if the inference configuration is applicable: the UE considers the configuration to be “activated” and starts performing inference.
Proposal 17	For the initial inference configuration, if the inference configuration is not applicable: the UE considers the configuration to be “deactivated” but it does not autonomously release the configuration.
Proposal 18	The UE autonomously activates a configured inference configuration if it becomes applicable. The UE notifies the network of the activation using an RRC message
Proposal 19	The UE autonomously deactivates a configured inference configuration if it becomes inapplicable. The UE notifies the network of the deactivation using an RRC message

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

Agenda item:	8.3.2
Source:	Nokia, Nokia Shanghai Bell
Title:	Functionality management for AI mobility
WID/SID:	FS_NR_AIML_Mob - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: In time domain Case B measurement reduction all L1 samples within a non-sliding L1 filter window may either be measured or all of them are skipped.
Observation 2: Due to filtering, the measurement skipping pattern can be different for unfiltered L1 samples and filtered L1 and L3 measurements.
Observation 3: In some scenarios, the used measurement skipping pattern may need to be coordinated between NW and the UE, for example to align the configured measurement gap pattern.
Observation 4: The L1 sample skipping pattern can depend on the UE proprietary L1 filter implementation.
Observation 5: To establish ground truth for the monitoring, the UE may need to measure selected otherwise skipped measurement periods.
Observation 6: Considering the SID, what mobility decisions network makes based on predicted or legacy reported event or measurements is a matter of NW implementation.
Observation 7: The UE needs indicate its capabilities to do measurement or measurement event prediction.
Observation 8: The network can configure, what the UE predicts, and reports based on the predictions.
Observation 9: The predicted inter-frequency measurements can be used for inter-frequency measurement event prediction
Observation 10: The predicted inter-frequency measurement events can be used to reduce the inter-frequency measurements.
Observation 11: The inter-frequency measurement prediction may be configured to predict the measurements a specific cell or the strongest cell in the target frequency.
Observation 12: Changes in the radio environment and UE trajectories, if necessary, must be detected, e.g., by model monitoring.
Observation 13: The relevant features to be considered in the applicability framework depend on the generalization level and design of the ML functionality.
Observation 14: If additional information is required to be provided by the network to the UE to assess the UE-side ML functionality applicability, the relevant information should be studied per use case and the ML functionality generalization level agreed.
Observation 15: The previous observation applies also if an associated ID is used, because the same considerations are required to provide associated ID values, which are meaningful for the UE-side ML functionality generalization level.
And proposed the following:
Proposal 1: Discuss on how the UE and NW can align on the measurement skipping patterns.
Proposal 2: Study how the NW can configure the measurement reduction feature, potentially including also the selected measurement skipping pattern.
Proposal 3: If coordinated between the UE and the NW, the MSP should also support configuring additional monitoring frames, which are both predicted and measured.
Proposal 4: Consider the sequence diagram in Figure 2.2-1 as baseline for the measurement event prediction use case.
Proposal 5: RAN2 to consider predicting measurement events in the frequency domain for measurement reduction goal. 
Proposal 6: Study configuration and reporting of predicted measurement events in the frequency domain for a specific cell or for any cell in the target frequency. 
Proposal 7: For NW-side ML, no applicability framework is expected.
Proposal 8: RAN2 to consider applicability-related additional configuration only if the required configuration has been studied and the ML generalization level agreed.
4	

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

Agenda Item:	8.3.2
Source:	CMCC
Title:	Discussion on functionality management for UE sided model
WID/SID:				FS_NR_AIML_Mob
Document for:	Discussion
1 

Conclusion
In this paper, we provide our consideration on applicability procedure, inference configuration and reporting and functionality management for RRM measurement prediction with UE-sided model and for measurement event prediction with UE-sided model. We have the following observation and proposals:
General applicability procedure for UE sided model
Proposal 1: The UE capability and applicable functionality reporting defined for AI/ML based beam management could be reused as the baseline for AI/ML based RRM measurement prediction and AI/ML based measurement event prediction with UE-sided model. RAN2 to capture Fig 1 the signalling procedure in TR 38.744.
Proposal 2: UE capability framework (i.e. UECapabilityEnquiry/UECapabilityInformation) could be used to report UE’s supported AI/ML-enabled Feature and/or supported functionalities for RRM measurement prediction and measurement event prediction with UE-sided model.
Proposal 3: The further discussions on UE capability details (e.g., functionality granularity, content, structure of the related UE capabilities, etc.) could be carried during the WI phase.
Proposal 4: For AI for Mobility, RRCReconfiguration message could be used to carry the full inference configuration (Option A) and/or inference related info (Option B) of AI/ML based RRM measurement prediction and AI/ML based measurement event prediction with UE-sided model.
Proposal 5: In applicability procedure of AI/ML for mobility, RRCReconfigurationComplete message could be used to carry the initial applicability/inapplicability reporting of the functionality.
Proposal 6: In applicability procedure of AI/ML for mobility, UAI could be used to carry the subsequent applicability/inapplicability reporting.

Inference configuration and reporting
Observation 1: There are two study goals in AI for Mobility, including measurement overhead reduction and HO performance improvement, the content of inference configuration and reporting of these two study goals maybe different.
Proposal 7: For Temporal domain case A in RRM measurement prediction with UE sided model, the content of inference related info from NW to UE could be considered:
The length of Prediction Window
Inference output related info: e.g., predicted L3 cell level results or predicted L3 filtered beam level results;
Inference input related info: e.g., L1 beam level measurement results or L3 cell level measurement results;
L1 sampling period: e.g., sampling period is 40ms@FR1, sampling period is 80ms@FR2, which could be used to specify the sampling period of actual RRM measurements and the measurement period of predicted RRM measurements for periodic reporting;
The threshold of RRM measurement results, which is used for event triggered inference and/or reporting;
Associated ID (FFS), which is introduced in AI/ML for Air Interface, and indicates the network-side additional condition
Proposal 8: For Temporal domain case B in RRM measurement prediction with UE sided model, the content of inference related info from NW to UE could be considered:
Inference output related info: e.g., predicted L3 cell level results or predicted L3 filtered beam level results;
Inference input related info: e.g., L1 beam level measurement results or L3 cell level measurement results;
MRRT related info: e.g., a threshold of MRRT, the MRRT actually used by UE could not exceed the threshold;
L1 sampling period
Associated ID (FFS)
Proposal 9: For Frequency domain in RRM measurement prediction with UE sided model, the content of inference related info from NW to UE could be considered:
Inference output related info: e.g., predicted L3 cell level results or predicted L3 filtered beam level results;
Inference input related info: e.g., L1 beam level measurement results or L3 cell level measurement results;
Frequency related info: e.g., the measured frequency and the predicted frequency;
L1 sampling period
Associated ID (FFS)
Proposal 10: The length of Observation Window is not needed in inference related info from NW to UE, which can be up to UE implementation. 
Proposal 11: L1 sampling period needs to be considered in inference related info from NW to UE, which could be used to specify the sampling period of actual RRM measurements and the measurement period of predicted RRM measurements for periodic reporting.
Proposal 12: The threshold of RRM measurement results needs to be considered in inference related info from NW to UE, which is used for event triggered inference and/or reporting.
Proposal 13: For indirect prediction in measurement event prediction, the content of inference related info from NW to UE could be considered: 
The length of Prediction Window
L1 sampling period 
Inference output related info, e.g., predicted A1-A6 events;
Associated ID (FFS)
Proposal 14: For direct prediction in measurement event prediction, the content of inference related info from NW to UE could be considered:
The length of Prediction Window
Probability threshold related info, e.g., the minimum value of the threshold which is used to determine the event prediction;
Inference output related info, e.g., predicted A1-A6 events;
Associated ID (FFS)

Functionality management
Observation 2: There are two options for functionality/model management in AI/ML for NR air interface. According to the progress AI/ML for NR air interface WI, Option 1a is taken as baseline, Option 1b and 2b would be further discussed, and Option 2c is not considered in Rel-19.
Proposal 15: Option 1a (Network decision, network-initiated AI/ML management) could be considered as the starting point for the study of functionality management for AI/ML based RRM measurement prediction and AI/ML based measurement event prediction with UE-sided model.

3GPP TSG-RAN2 Meeting #130	R2-2504459
St.Julians, Malta,  May 19th – 23rd , 2025
Source: 			ZTE Corporation
Title: 	Discussion on functionality management for AI mobility
Agenda item:	8.3.2
Document for: 	Discussion and Decision

Conclusion and proposals
Proposal 1: The associated id is needed for at least spatial domain measurement prediction.
Proposal 2: For AI-mobility, the network can indicate the frequency that the UE shall perform inference on and the minimum number of cell(s) on one frequency that the UE shall perform inference.
Proposal 3: For temporal domain case A, the network can configure the UE the time gap between two consecutive future time instance and the number of future time instance.
Proposal 4: For temporal domain case A, the network can configure the UE a condition to determine when to perform inference. FFS the pre-configured condition.
Proposal 5: For temporal domain case B, the network can configure the UE the skipping pattern, which is defined as the number of continuous time instance for actual measurement and the number of continuous time instance that actual measurement is skipped (i.e. for prediction).
Proposal 6: Regarding frequency domain prediction, for frequency to be predicted, the network can indicate the measurement results of which frequency can be used for the input of frequency domain prediction AI model.
Proposal 7: Regarding measurement event prediction with temporal domain prediction case A, the network can configure the UE when to report the predicted results.
Proposal 8: For temporal domain prediction case A, the periodical measurement report includes the latest actual measurement results and predicted results of future time instance. 
Proposal 9: For temporal domain prediction case B, the periodical measurement report includes the latest actual results and predicted results of future time instances (if available).
Proposal 10: For frequency domain prediction, the measurement report include the latest actual results, as legacy.
Proposal 11: For measurement event prediction with temporal domain prediction case A, the measurement report includes predicted event-triggered time, the latest actual measurement results and predicted results.
Proposal 12: For measurement event prediction with temporal domain prediction case B, the measurement report include:
Event-triggered time if measurement report is initiated earlier than event-triggered time;
The latest historical measurement results;
Measurement result of future time instance (if available)
Proposal 13: For measurement event prediction with temporal domain prediction case B, the measurement report is initiated when the measurement event is predicted to be triggered.
Proposal 14: For measurement event prediction with frequency domain prediction, the measurement report includes the latest historical results, as legacy.

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

Agenda Item:	8.3.2
Source:	ASUSTeK 
Title:	Discussion on functionality management for AIML Mobility
Document for:	Discussion and Decision

Conclusion
Proposal 1: Reuse the concept of BM-Case 2 in AI/ML PHY for inference configuration for RRM prediction.
Proposal 2: MeasObjectNR is used for configuring the measurement targets and prediction targets.
Proposal 3: ReportConfigNR is used for configuring report content related information. FFS on details.
Proposal 4: For UE-side model, agree that subcase 1/2/3 has minimal difference in specification impact.
Proposal 5: For AI/ML mobility, applicability reporting based on inference configuration can be the baseline to study.

3GPP TSG RAN WG2 #130       	                            R2-2504522
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	8.3.2 
Source:	KDDI Corporation
Title:	Discussion on measurement report and configuration for UE sided model
SID:	FS_NR_AIML_Mob – Release 19
Document for: 	Discussion and Decision

Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1 RAN2 should consider possibility of new measurement report for prediction-based measurement.
Proposal 2 RAN2 should consider how to indicate time of the prediction object in a report. BM-Case2 of the AI/ML for beam management can be reference.
Proposal 3 RAN2 should consider the impact of predicted-based new event for measurement.
Proposal 4 In inter-frequency prediction, RAN2 should check that whether the current spec can support measurement skip configuration for neighbour cell prediction.
Proposal 5 In temporal domain case B, RAN2 should consider the necessity of the complex measurement reduction pattern and its configuration.