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

Source:	vivo
Title:	Discussion on data collection
Agenda Item:	8.3.4
Document for:	Discussion and Decision

Conclusion
In the contribution, we have the following observations and proposals:
RS type
For the reference signal type in AI/ML-based mobility, SSB is supported as the baseline. RAN2 to discuss whether CSI-RS is also considered.
UE-side data collection
The data collection configuration schemes for AI/ML-based beam management can be the baseline for UE-sided model training of AI/ML-based mobility, including:
- The network configures whether UE is allowed to initiate the request for data collection configuration, which may include a list of candidate configurations.
- The UE sends a request for data collection configuration via UAI (e.g. start/stop, preferred configuration from the list of candidate configurations), if configured.
- RS configuration(s) and associated ID(s) (if needed) can be included in the data collection configuration.
- The network decides when to start/stop the data collection by provision of configuration.
The UE can request the data collection configuration for both serving and neighbor cells.
Framework of NW-side data collection
The NW-side data collection schemes for AI/ML-based beam management can be reused as the baseline for AI/ML-based mobility, including:
- Data collection can be initiated by OAM (via immediate MDT) or by gNB.
- The gNB configures UE to log multiple instances of RRM measurement results.
- Both periodic and event-triggered data logging are supported.
- UE stores the logged training data at AS layer with a minimum AS layer memory size supported by the UE.
- UE may indicate the data collection status to gNB, e.g., the buffer becomes full or buffer reaches a threshold if configured.
- When low power state is detected, the UE can indicate the low power state to the gNB, if configured. Upon reception of the low power status indication, the network should de-configure UE to release the data collection configuration.
- During handover the UE can retain the logged data and the UE can indicate the availability of logged data to the network and the network decides whether the logged data should be kept or not. 
- Upon UE transitioning to RRC_IDLE/INACTIVE or UE experiencing RLF, UE discards any stored data.
In the NW-side data collection for AI/ML-based mobility, the following events (similar to events A1-A6) should be supported for event-triggered data logging, including:
- Serving becomes better than a threshold for TTT
- Serving becomes worse than a threshold for TTT
- Neighbour becomes offset better than Serving for TTT
- Neighbour becomes better than a threshold for TTT
- Serving becomes worse than threshold1 and neighbour becomes better than threshold2 for TTT
- Neighbour becomes offset better than SCell for TTT
The AS layer memory and the associated buffer threshold are shared for all AI-related use cases (including AI/ML-based beam management and mobility).
The logged data availability and low-power state indications are per UE, i.e., not per use case. Upon reception of the low power status indication, the network should release all the data collection configurations for training purposes (including AI/ML-based beam management and mobility).
Contents of NW-side data collection
For NW-side data collection, introduce a unified solution for all sub-use cases and scenarios, i.e., the sub-use case and scenarios can be agnostic in the specification.
As to the contents of NW-side data collection:
- To support temporal domain prediction, the UE can be configured to report a list of time-aligned L1-filtered beam-level RSRP, L3 beam-level RSRP, and/or L3 cell-level RSRP of the same cell at multiple time instances.
- To support spatial domain prediction, the UE can be configured to report a list of time-aligned L1-filtered beam-level RSRP, L3 beam-level RSRP, and/or L3 cell-level RSRP of the same cell.
- To support frequency domain prediction, the UE can be configured to report a list of time-aligned L1-filtered beam-level RSRP, L3 beam-level RSRP, and/or L3 cell-level RSRP of two or more cells on different frequencies.
- How to ensure the alignment of L1-filtered beam-level RSRP, L3 beam-level RSRP, and/or L3 cell-level RSRP can be discussed during the WI phase.

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

Conclusion
In this contribution, we have the following observations,
Proposal 1
The contents of logged data include the following,
For RRM measurement prediction and measurement event prediction,
UE should log the measurement results and related information (e.g., time stamp).
For measurement event prediction, UE can further log the following,
Entering, leaving, and/or triggering of the measurement events.
Proposal 2
UE should retain unretrieved data during/before HO, or RLF.
FFS: whether UE should retain unretrieved data upon going to RRC_IDLE/INACTIVE.
Proposal 3
RAN2 reuses the principle that the NW controls both the UE data collection and the UE/UE-side request for the data collection.
The NW can configure the UE data collection with or without UE/UE-side request.
The NW configures whether the data collection request from the UE is allowed. 
Study how to configure UE to collect measurements for RRM measurement or event predictions.

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

Agenda Item:	8.3.4
Source:	OPPO
Title:	Discussion on data collection 
Document for:	Discussion, Decision

Conclusion
We have following observations and proposals:
Common part: data collection configuration
Observation 1: NR measurement configuration includes measurement objects, report configuration, measurement identities, quantity configurations, and measurement gaps.
Observation 2: NR measurement report includes L3 cell and L3 beam measurement results.
Observation 3: Measurement period for data collection tasks can vary.
Observation 4: Inter-frequency prediction performance will be impacted by the logging time of measurements of different frequencies.
Proposal 1: Measurement configuration and report framework is taken as baseline for data collection.
Proposal 2: Additionally, data collection configuration includes at least the following components:
Measurement result type indication: Specify the type of measurement results, such as L1 beam results, L3 beam-level results and L3 cell-level results.
Logging time interval: Set the time interval for measurement logging, e.g., 200ms.
Proposal 3: The logging timing for different frequencies in inter-frequency prediction should be aligned.

NW-side mode general
Observation 5: NW-side model data collection is for RRM prediction only.
NW-side model: Data collection initiation
Proposal 4: RAN2 confirms the following BM agreements can be used for AI mobility:
For NW-side model, model training, data collection can be initiated by OAM (via immediate MDT) or by gNB. The same measurement framework is applied to both gNB-centric and OAM-centric data collection.
NW-side model: Data logging
Proposal 5: Reuse the wording of data logging in BM for AI mobility NW-side model, i.e., both periodic and radio condition-based event-triggered data logging are supported. UE can use L3 measurement event-triggered to determine whether to perform data logging.
Proposal 6: Reuse the wording of data logging in BM for AI mobility NW-side model, i.e., periodic reporting of logged data is not supported and on-demand reporting of the logged measurements will be specified
NW-side model: Availability of logged data
Proposal 7: RAN2 to confirm the agreements from AI PHY on availability of logged data that:
The UE can indicate the availability of logged data to the network. Upon reception of the availability indication, the network can trigger the UE information procedure. 
During handover the UE can retain the logged data and the UE can indicate the availability of logged data to network.
Availability indication can be triggered by full buffer being reached (if configured), buffer threshold being reached (if configured), or low power (if configured)
UAI is used to indicate the availability of logged data, reason (full buffer, exceed threshold) to trigger, and low power state. 
Proposal 8: UE should be allowed to retain logged data when transitioning to RRC_IDLE, RLF, or RRC_INACTIVE, and report those data to the NW upon returning to RRC_CONNECTED, for purpose of NW-side model training.
NW-side model: Low power state 
Proposal 9: RAN2 confirms the following contents from AI PHY also apply to AI mobility:
To reduce UE power consumption, when low power state is detected, the UE can indicate the low power state to the network. Upon reception of the low power status indication, the network should de-configure UE to release the data collection configuration. How the UE determines low power state is up to UE implementation.
NW-side model: Buffer limitation
Proposal 10: RAN2 to confirm the agreements from AI PHY on buffer limitation of logged data that:
UE stores the logged training data at AS layer with a minimum AS layer memory size supported by the UE.
When UE reaches its buffer limitation the UE stops measurement for data collection purposes and logging.

UE-side model: Data collection procedure
Proposal 11: RAN2 confirms the agreement in BM applies for AI mobility:
For UE-side model, the network can configure whether UE is allowed to initiate a request about data collection configuration. The network can also provide UE with data collection configuration or release the data collection configuration (at any point in time), with or without UE request.
UE-side model: Data collection configuration
Observation 6: Data collection configuration for RRM prediction and measurement event prediction for UE-side model training are distinct, e.g., they may involve measurement on different cells/frequencies, and may or may not include measurement event type.
Proposal 12: Data collection configuration for training of measurement event prediction and RRM prediction should be treated as two separate configurations, enabling the simultaneous execution of different data collection tasks. 
Proposal 13: For UE-side model, the logged data report includes related data collection configuration(s), such as measurement configurations.

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

Source:	CATT, Turkcell
Title:	Discussion on data collection for AIML mobility
Agenda Item:	8.3.4
Document for:	Discussion and Decision

Conclusion
According to the discussion in section 2, we propose:
RRM measurement prediction
NW-side data collection
Proposal 1: For RRM measurement prediction, legacy L3 RRM measurement framework is used to provide NW-side data collection configuration from network to UE.
Proposal 2: The following agreements on logging conditions/events for NW-side data collection in AI/ML PHY are also applied to RRM measurement prediction.
Periodic logging is supported;
Event-triggered logging is supported. Support the use of L3 measurement event trigged (i.e. L3 serving cell measurements becoming worse/better than a threshold for TTT) to determine whether the UE perform logging or not.
Proposal 3: For RRM measurement prediction, for NW-side data collection, at least cell/beam level measurement result(s) and/or cell/beam-IDs needed to be collected by UE, the detailed contents are up to the specific sub-use case.
Proposal 4: The following agreements on starting/stopping of logging for NW-side data collection in AI/ML PHY are also applied to RRM measurement prediction.
Data collection is controlled by the network. The UE will not autonomously stop when low power state is detected.
When UE reaches its buffer limitation the UE stops measurement for data collection purposes and logging.
Proposal 5: The following agreements on availability indication for NW-side data collection in AI/ML PHY are also applied to RRM measurement prediction. FFS whether extra indication information is needed separate from AI/ML PHY.
Availability indication can be triggered due to:
Full buffer being reached (if configured)
Buffer threshold being reached (if configured). 
Low power (if configured)
The UE send a UAI that indicates:
Data is available
Reason for trigger (full buffer, threshold)
Low power indication 
Proposal 6: The following agreements on sending of the collected data for NW-side data collection in AI/ML PHY are also applied to RRM measurement prediction.
UEInformationRequest/UEInformationResponse is used for on-demand reporting of AI/ML training data collection.
As baseline, the UEInformationResponse contains one or more logged measurement entries in chronological order (i.e. starting from the oldest measurement entries stored in the UE memory), and an availability indication if there are further data available for transmission. Same principles as for logged MDT.
New SRB can be configured for NW-side data collection (with lower priority)
Proposal 7: The following agreements on configuration/data handling during mobility/state transition for NW-side data collection in AI/ML PHY are also applied to RRM measurement prediction.
UE indicates availability of logged data during handover (i.e., within the RRCReconfigurationComplete message) (if data is retained in the UE).
Introduce 1-bit indication on whether to release or retain un-retrieved data in RRCReconfiguration during/before HO.  Source gNB decides whether the data should be kept.  The indication is provided in RRCReconfiguration (i.e. not in RRC Reconfiguration from target cell).   
Upon going to RRC_IDLE, RLF, or RRC_INACTIVE, UE discards any logged data.
UE-side data collection
Proposal 8: The following agreements on UE requests data collection for UE-side data collection in AI/ML PHY are also applied to RRM measurement prediction.
The UE can request measurement configuration for data collection. The request can contain one or more of the following:
An indication on start/stop of data collection
Preferred configuration from a list of candidate configurations provided by NW. It is up to network what it configures at the end.
Introduce UAI message for UE request of data collection measurement configuration. And it is up to UE implementation when to send the request.
Proposal 9: The following agreements on data collection configuration for UE-side data collection in AI/ML PHY are also applied to RRM measurement prediction.
The network can provide or release the data collection configuration (at any point in time), with or without UE request.
The following methods for network control of the initiation and configuration for data collection:
The network can decide when to start/stop the data collection and send configuration.
The network can configure whether UE is allowed to initiate request for data collection (e.g. start/stop indication).
Data collection related configuration(s) and associated ID(s)(if needed) can be included in training data collection configuration.
Proposal 10: For RRM measurement prediction, legacy L3 RRM measurement framework is used to provide UE-side data collection configuration from network to UE.

Measurement event prediction
Indirect measurement event prediction
Proposal 11: For indirect measurement event prediction, UE-side data collection, which including e.g., UE requests data collection and data collection configuration etc. is the same as that for RRM measurement prediction.
Direct measurement event prediction
Proposal 12: The UE requests data collection and data collection configuration mechanism were agreed in AI/ML PHY are also applied to direct measurement event prediction.
Proposal 13: Legacy L3 RRM measurement framework can be used for UE-side data collection configuration for direct measurement event prediction.
Proposal 14: For UE-side data collection on direct measurement event prediction, at least the cell/beam measurement results and event configuration parameters (e.g., TTT) can be logged, other information is FFS.

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

Source: 	Xiaomi
Title:  	Discussion on data collection
Agenda Item:	8.3.4
Document for:	Discussion and Decision

Conclusions
According to the analysis given above, we have the following observations and proposals:
NW side data collection
Proposal 1: Data logging is supported for NW side data collection in AI mobility.
Proposal 2: New radio event, e.g. A3, A5 alike event, can be introduced to control data logging in AI mobility.
Proposal 3: For RRM and L3 beam temporal domain prediction, the data content may include,
Cell level measurement results
L3 beam level measurement results
Timing information
Proposal 3: For RRM frequency domain prediction, the data content may include,
Cell level measurement results on one or multiple frequencies
Timing information, if needed
Proposal 4: UE stores logged data in AS layer memory, which is shared across all AI use cases, including AI mobility, AI air and future AI use cases.
Proposal 5: UE can indicate the supported AS layer memory size for data logging.
Proposal 6: Confirm following agreements are applied in AI mobility for logged data handling,
NW indicate whether logged data is retained after HO
UE discards logged data upon RLF or leaving RRC_CONNECTED
Proposal 7: Confirm following agreements are applied in AI mobility for data availability report,
Availability indication can be triggered due to:Full buffer being reached (if configured), Buffer threshold being reached (if configured), Low power (if configured)
UE side data collection
Proposal 7: Confirm following agreements are applied in AI mobility for UE request data collection configuration,
The UE can request measurement configuration for data collection of AI/ML based beam management.   The request can contain one or more of the following: 
• An indication on start/stop of data collection
• Preferred configuration from a list of candidate configurations provided by NW. It is up to network what it configures at the end.
Proposal 8: UE doesn’t request RRM RS configuration in data collection configuration.
Proposal 9: RAN2 discuss UE can request following in data collection configuration,
measurement gap configuration to collect data on inter frequency cell
Cell/frequency to be measured

3GPP TSG-RAN WG2 Meeting #130	R2-2503694
Malta, May 19th – 23rd, 2025
Agenda Item:	8.3.4
Source:	InterDigital Inc.
Title:	Data collection for RRM measurement prediction
Document for:	Discussion
1. 

Conclusion
In this contribution, we discussed data collection for Network and UE sided models for RRM measurement prediction, and the following were proposed:

Proposal. 1: For the collection of data for the training of a network-sided model for RRM measurement prediction:
UE can be configured to log, at a certain logging periodicity, one or more of the following:
L3 cell level measurements, 
L3 beam level measurements,
L1 beam level measurements
The UE configuration is provided via the RRM measurement framework. Required enhancements are FFS.
The UE can be configured with a L3 event for determining when logging is to be performed. When the event conditions are fulfilled, it performs the logging with the logging periodicity.   
The UE sends availability indication of collected data via UAI or RRCReconfigurationComplete message.
The availability indication can be triggered due to:
full buffer being reached (if configured), 
buffer threshold being reached (if configured), or
low power (if configured)
Upon sending the availability indication, UE indicates:
Data is available
Reason for the triggering of the availability indication (full buffer. Threshold)
Low power indication
The UE sends the collected data upon explicit/on-demand request from the network (using UEInformationRequest/Response signaling)
The UE keeps the collected data upon HO, unless explicitly indicated to release it by the network (e.g., before/during HO).
The UE releases the collected data upon transitioning to IDLE/INACTIVE.

Proposal 2: For the collection of data for the training of a UE-sided model for RRM measurement prediction:
the UE can request the network for a data collection configuration (e.g., via UAI)
The network can provide data collection configuration to the UE with or without UE request.
The details of the data collection configuration (e.g., any enhancements to MeasConfig) are FFS.
4. 

3GPP TSG-RAN WG2 Meeting #130													     R2-2503707
St. Julians, Malta, May 19th – 23rd, 2025									  
Agenda item:	8.3.4
Source:	Apple
Title:	On data collection for AI/ML mobility
Document for:	Discussion and Decision

1	

Proposals
Proposal 1: to enhance the MeasConfig IE to support NW-sided data collection configuration.
Observation 1: UE should know which measurements to log (for NW-sided data collection) and which to report in the usual/legacy manner.
Proposal 2: to extend MeasObjectNR with an indication whether the UE should log the configured measurements for NW-sided data collection .
Proposal 3: network shouldn’t “abuse” legacy measurements for NW-sided data collection.
Observation 2: NW-sided data collection is a significant burden on UEs – much more than let’s say MDT (due to likely much larger data volumes).
Proposal 4: UE support for network-sided data collection is an optional feature (i.e. it should be a “dedicated feature” separate from AI/ML mobility) – in other words, a UE can be AI/ML mobility capable but not support NW-sided data collection.
Observation 4: the issue of user privacy in the context of NW-sided data collection is discussed in [7] R2-2503526.
Observation 5: there are ongoing discussions in SA2 on UE-sided data collection that would only conclude in Rel-20.
Observation 6: it is very likely that most if not all the decisions we may take now on UE-sided data collection will need to be revisited when SA2 concludes
Observation 7: if companies’ urge to discuss UE-sided data collection cannot be resisted, the discussion should be limited to configuration only (and not cover data transfer).
Proposal 5: UE can use the measurement configuration it received for mobility for data collection as well ; this requires no enhancements, adds no overhead and no additional burden on network.
Observation 8: the fact that cluster approach outperforms single cell approach in the evaluation indicates that at least in some cases it is beneficial for the UE to collect measurements for cells/ frequencies it is not configured for otherwise.
Proposal 6: dataCollectionStart (true/false) and dataCollectionPreferredConfiguration defined for AI/ML PHY can be re-used for AI/ML mobility UE-sided data collection .
Proposal 7: dataCollectionPreferredConfiguration IE may need to be enhanced to allow a UE to request measurement configuration for the purpose of UE-sided data collection at least for additional cells and frequencies.
Proposal 8: associated id is beneficial for UE-sided data collection.
5	

3GPP TSG-RAN WG2 #130	R2-2504132
St. Julian’s, Malta, May 19th – 23rd, 2025	
Agenda Item:	8.3.4 Data collection
Source:	Ericsson
Title:	Data collection for network sided and UE sided models
Document for:	Discussion
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Observation 1	UEs can perform intra-frequency measurement collection for UE side models without any configuration update from the network.

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

Proposal 1	The network configures the UE to initiate/terminate data collection procedures.
Proposal 2	Priority between data collection and RRM measurements or user plane data needs to be considered.
Proposal 3	RRM measurement framework is used for configuration of data collection and reporting of the collected data from UE to the NW, for inference purpose.
Proposal 4	Event triggered report and periodical report are used for data collection for inference purposes.
Proposal 5	Data collection for training purpose of network side model should be supported to be done by the UE in RRC_IDLE/INACTIVE state or RRC_CONNECTED state.
Proposal 6	For data collection when the UE is in RRC_IDLE/INACTIVE state, a solution based on logged MDT principles can be reused.
Proposal 7	For data collection when the UE is in RRC_CONNECTED state, the UE logs the data and reports the availability of data to the network.
Proposal 8	The UE Information Request/Response procedure is used to retrieve the logged data from the UE.
Proposal 9	Possible assistance information from the UE to the network can be considered in the work item.
Proposal 10	Data collection for training purposes of UE-side models can be done in either RRC_IDLE/INACTIVE or RRC_CONNECTED state.
Proposal 11	Data collection for UE sided models in RRC_IDLE/INACTIVE state is mainly up to UE implementation.
Proposal 12	The measurement requirements for RRC_IDLE/INACTIVE can be checked for data collection purposes.
Proposal 13	The UE preferably performs data collection in RRC_CONNECTED when there are no ongoing data transmissions/receptions.
Proposal 14	Discuss whether measurement gaps can be configured for the purpose of data collection and/or model training.

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

Agenda item:	8.3.4
Source:	Nokia
Title:	Considerations on data collection
WID/SID:	FS_NR_AIML_Mob - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: Compared to the AI PHY beam management use case, AI mobility emphasizes RRM measurement over CSI measurement. Therefore, MeasConfig appears to be more appropriate for defining the logging configuration.
Observation 2: Initiating data collection at the UE using the s-MeasConfig threshold can ensure that measurements from both serving and neighboring cells are included.
Observation 3: The current agreements lack mechanisms for prioritizing specific types of data to be logged by the UE. 
Observation 4: Triggering the availability indication when a buffer threshold is met is more robust (minimizing loss of data) than waiting for the buffer to be completely full.
Observation 5: SRB3 and SRB5 are configured exclusively for dual connectivity (EN-DC or NR-DC), making them unsuitable for the current use case.
Observation 6: The current agreements for AI Phy use-cases suggest using a binary indication, which prevents selective discarding of low-prioritized data. This can lead to inefficient buffer use and resource handling. 
Observation 7: AI mobility studies and RLF processes that automatically discard data during UE transitions to RLF could result in the loss of critical features necessary for data collection.
Observation 8: RRC connection for data collection should enable measurement and event data collection also when otherwise not connected and without endangering a degradation in the data plane traffic, for example if additional measurement gaps are required.
And proposed the following:
Proposal 1: Extend UE-side logging and related configurations to collect the relevant measurements and labels as configured. Details FFS for each use case.
Proposal 2: For NW-side deployments, RAN2 to consider the data collection configuration within MeasConfig IEs for AI mobility use cases.
Proposal 3: Consider the following mechanism to initiate the data logging for AI mobility use cases:
Periodic logging: logging interval or periodicity can be a new RRC parameter.
Event triggered logging: measurement Event A* or s-MeasureConfig threshold can be reused. 
Network indicated logging: an existing or dedicated DL indication signal can be used. Details FFS.
Proposal 4: For periodic logging, the minimum logging interval should align with the CSI-RS/SSB transmission periodicity.
Proposal 5: RAN2 to study different data prioritization levels for logging at the UE.
Proposal 6: Study the use of different buffer thresholds to enable data availability indication.
Proposal 7: Discuss the need of a common or different SRBs for network sided data collection to facilitate transmission of data with different priorities.
Proposal 8: Study whether the UE can retain a certain level of prioritized data during the handover process.
Proposal 9: For UE-side deployments, enhance the MeasConfig IEs for collecting data for AI mobility use cases. 
Proposal 10: Identify and study potential inter-operability issues that arise when collecting data for UE-side models. 
Proposal 11: RAN2 to consider an RRC connection set up specifically for measurement and event data collection.

4	

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

Agenda item:	8.3.4
Source:	CMCC
Title:	Discussion on data collection for AI Mob
WID/SID:	FS_NR_AIML_Mob
Document for:	Discussion
 

Conclusion
Here are the proposals on data collection for AI Mob.
NW-side data collection procedure
General
Proposal 1: RAN2 to consider gNB-centric and OAM-centric approaches for NW-sided model training data collection for AI Mob, and aims to apply the same measurement framework for them. For OAM-centric approach, RAN2 takes immediate MDT as baseline. 
Logging
Proposal 2: Logging in RRC_CONNECTED mode is optionally supported for model training data collection for AI Mob.
Proposal 3: Periodical and L3 measurement event triggered logging are supported for NW-side data collection for AI Mob.
Data collection configuration
Proposal 4: For AI Mob, the data collection configuration can include the configurations for RRM measurement and/or measurement event.
Proposal 5: The data collection configuration can include the measurement resources and logging information, e.g. periodicity, triggered event and RS type.
Availability indication
Proposal 6: When availability indication is triggered due to full buffer being reached, buffer threshold being reached or low power, the UE sends the UAI including data availability indication and/or cause value (reason for trigger, low power indication) to the network. 
Proposal 7: When the buffer is full, the UE can stop data collection.
Proposal 8: the UE will not autonomously stop when low power state is detected until the network releases the configuration.
Data retrieval
Proposal 9: UEInformationRequest and UEInformationResponse are used for on-demand reporting of AI/ML training data collection. 
Proposal 10: UEInformationResponse contains one or more logged measurement entries in chronological order (i.e. starting from the oldest measurement entries stored in the UE memory), and an availability indication if there are further data available for transmission.
Proposal 11: A new SRB with lower priority introduced in AI/ML PHY is also used for NW-side data collection in AI Mob.
Basic flow
Proposal 12: RAN2 takes the Figure.1 as baseline for NW-side data collection procedure.

UE-side data collection procedure
Proposal 13: The network can provide or release the data collection configuration with or without UE request for UE-side data collection. 
Proposal 14: The UE can send UAI message to the network for request of data collection measurement configuration, including an indication on start/stop of data collection, preferred configuration from a list of candidate configurations provided by NW.

Data content for RRM measurement prediction
Observation 1: For temporal domain prediction, L1 beam level, L3 beam/cell level results, and time info are needed for model training, while the details can be different per sub-use case.
Observation 2: OW length, PW length and MRRT are not necessary for model training data collection, which can be up to implementation.
Observation 3: For frequency domain prediction, in addition to beam/cell level results, frequency info is needed.
Observation 4: UE speed is needed for intra-frequency temporal domain prediction, while it is not necessary for inter-frequency prediction.
Proposal 15: RAN2 takes Table 1 as starting point for model training data collection for RRM measurement prediction.
Table 1. Data content for model training for RRM measurement prediction

Data content for measurement event prediction
Proposal 16: RAN2 takes Table 2 as starting point for model training data collection for measurement event prediction.
Table 2. Data content for model training for measurement event prediction

4	

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

Conclusion and proposals
Observation 1: For UE side data collection in AI-PHY, the network can configure a list of candidate configurations to the UE, and the UE can indicate the preferred configuration from the list of candidate configuration provided by the NW, this mechanism can be applied to AI-Mobility.
Proposal 1: For UE side data collection in AI mobility, the network can provide a list of candidate data training configuration to the UE, and the UE reports its preferred candidate configuration from the indicated list to the network (same as in AI-phy).
Proposal 2: Each candidate data training configuration provided by the network can include:
The frequency used for the input of the UE side AI model;
The frequency used for the output of the UE side AI model;
For each frequency, the measurement resource configuration, including the cell/beam information that the UE can collect the data on and the measurement timing configuration.
Proposal 3: In AI mobility, it is up to network to decide the final configuration for data collection for UE sided model (same as in AI-Phy).
Proposal 4: For the network side model, the training data collection configuration can include:
The frequency whose measurement results needs to be logged;
The type of logged measurement results (e,g, L1 filtered beam results, L3 filtered cell results)
The expected L1/L3 measurement interval;