TDoc file reading error

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

Source:	vivo
Title:	Discussion on NW side data collection
Agenda Item:	8.1.3
Document for:	Discussion and Decision

Conclusion
In this contribution, some remaining issues on NW-side data collection for model training for beam management and we have the following obsetvations and proposals:
UE keeps power consumption down if NW cannot stop UE from logging data after indication of UE low power state and has no enough power for other services with higher priority.
And
Data collection configuration
Introduce an area (e.g., NCGI, cell PCI) configuration to restrict the area in which the UE performs training data logging. And each cell within the area should be associated with an associated ID.
Dynamic activation/deactivation is NOT supported for data collection measurement configurations.
Data logging
For gNB centric data collection, gNB ID is included in the logged data reporting.
Along with logged data, UE also logs the area where the data are logged (e.g., NCGI, PCI-ARFCN).
Retaining logged data a HO
The source gNB sends the 1-bit indication to the UE before HO, when configuring with the data collection configuration.
Open issue RRC-8: Reporting assist. info related to logged meas
With regard to data collection related availability indications from UE to gNB, full buffer and buffer threshold being reached, and low power state indications are also applicable to other use cases , i.e, AI mobility.
UE sends a UAI containing data available indication and reason for full buffer, buffer threshold reached, or low power state as follows:
1-bit for buffer threshold being reached or full buffer being reached;
1-bit for low power state.
Open issue RRC-28: Data availability and low power state during RRCReestablishment, RRC_INACTIVE 
The UE is allowed to report low power state during RRCReestablishment.
UE, configured to perform data collection, can indicate available data, if available data has reached the configured buffer threshold to the network, before the UE transitions to RRC_INACTIVE. 
Open issue RRC-29: Whether data availability indication when data below the threshold and low power state
When the UE is reporting a low power state, the UE just report low power state and the UE is not required to report available data, if the data has not reached the configured buffer threshold.
Open issue RRC-9: Further procedures for UE assist, info related
The network can configure UE with a timer, which is started when UE indicates the logged data availability due to low power state; and is stopped when UE receives de-configuration of data collection. At the timer expiry, UE can stop logging the data.
New SRB usage 
Legacy logged data and AIML logged data are not multiplexed in new SRB.

3GPP TSG-RAN WG2 Meeting #130													     R2-2503526
St Julian’s, Malta, 19-23 May 2025									  									  
Agenda item:	8.1.3
Source:	NTT DOCOMO, Apple, vivo, Xiaomi
Title:	User consent for NW-side data collection
Document for:	Discussion and Decision

1	

Proposals
Proposal 1: NW-sided data collection for AI/ML model training requires user consent. 
Proposal 2: re-use the existing user consent framework (defined for MDT) for NW-side data collection.
5	

3GPP TSG-RAN WG2 Meeting #129bis	R2-2503538
St.Julians, Malta, May. 19th – 23rd, 2025	
Agenda item:	8.1.3
Source:	Samsung
Title:	Discussion on NW side data collection
Document for:	Discussion & Decision

Conclusion
RAN2 is requested to discuss and agree the following proposals:
Proposal 1. (Open issue RRC-38) UE mandatorily supports the fixed size of minimum AS layer memory without UE capability signalling, and optionally reports via UE capability a larger minimum AS layer memory size. FFS for the exact numbers.
Proposal 2. (Open issue RRC-29) UE autonomously resumes measurement/logging paused due to full buffer, when memory becomes available (i.e., after logged data report is sent to NW).
Proposal 3. (Open issue RRC-29) When UE is no longer in low-power state, UE triggers UAI transmission and indicates it to NW.
Proposal 4. Buffer threshold is configured as the size of logged data (e.g., kilobytes). The exact numbers could be discussed after the decision on minimum memory requirement/capability.
Proposal 5. (Open issue RRC-29) When UE's buffer level becomes less than the configured threshold, UE triggers UAI transmission and indicates it to NW.  Prohibit timer is introduced for buffer threshold based UAI transmission. 
Proposal 6. When NW-side data collection is configured, UAI configuration (i.e., at least buffer-threshold) should be always configured together.
Proposal 7.  (Open issue RRC-6) UE releases both NW-side data collection configuration and the corresponding UAI configuration in case of transition to RRC_IDLE and RRC_INACTIVE, and RRC Reestablishment.
Proposal 8. (Open issue RRC-18) During handover, source gNB provides target gNB with the 1-bit indication on whether to release or retain un-retrieved data in HandoverPreparationInformation message. Then, target gNB includes the indication in RRCReconfiguration message within HandoverCommand message.
Proposal 9. During handover, the target node can keep or release the configuration for NW-side data collection configured by the source node.
Proposal 10. (Open issue RRC-21) No explicit timestamp is needed for logged data to indicate time gap between two consecutive samples. Instead, the following implicit way is introduced:
When UE performs measurement periodically, UE contains the data sequentially in a common data list.
Whenever UE suspends and resumes measurement (depending on whether event is fulfilled and whether the buffer is full), UE starts logging the subsequent data using a separate data list. 
Proposal 11. When UE is configured to log L1-RSRP, UE includes L1-RSRPs sequentially in each data list for each beam, where the n-th entry of the data list is set as follows:
If n=1, absolute L1-RSRP is set
Otherwise (i.e., n>1), differential L1-RSRP is set compared to L1-RSRP of (n-1)th entry
Proposal 12. (Open issue RRC-26) UEInformationResponse message can include both types of data. 1) AI/ML data (i.e., for NW-side data collection) and 2) the other existing data (i.e., for SON/MDT). When UEInformationResponse message includes at least AI/ML data, the new SRB (e.g., SRBx) is used.

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

Agenda Item:	8.1.3
Source: 	Fujitsu
Title: 	Discussion on NW side Data Collection
WID/SID:	NR_AIML_air
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss the potential solutions for the NW-side data collection for model training in beam management and positioning. The following observations and proposals are considered:
Beam Management:
Proposal 1 Additional dynamic activation/deactivation may not be necessary since events/conditions can be designed to dynamically control the data collection procedure.
Proposal 2 Similar to inference configuration, the timing gap should be configured in the CSI-ReportConfig for data collection as well.
Proposal 3 In order to support the reporting of multiple configurations, functionality related index may be reported so that NW can distinguish the samples per functionality/model/feature/FG.
Positioning:
Observation 1 There may not be RAN2 impact for Part A data collection of case 3a.
Observation 2 There may not be RAN2 impact for Part B data collection of case 3a.
Observation 3 RAN2 may not be able to figure out the impact on association between Part A/B data collection for case 3a, until there is more input from other WGs.
Proposal 4 RAN2 suspends the discussion on training data collection for case 3a and wait for other WGs.
Proposal 5 To support part A data collection of case 3b, existing NRPPa procedure (e.g., Measurement information transfer) can be re-used.
Proposal 6 For the existing NRPPa procedure of part A data collection of case 3b, it is up to RAN3 on the potential enhancements of signalling and procedure, whilst it is up to RAN1 on the potential enhancements of collected data contents.
Proposal 7 LMF can choose the appropriate ways to collect part B data for case 3b. One feasible way to collect estimated location of non-PRU UE is via LPP procedures such as location information transfer, details pending for further RAN1 conclusions.
Proposal 8 LMF may associate part A and part B data from the same PRU/UE for case 3b by at least the following ways:
LMF configures UE/PRU to report part A/B together in the same LPP reporting.
LMF configures UE/PRU to report part A/B separately, but with assistance information to combine two reports. The assistance information may be either from UE reporting, or from LMF locally.
The details are left for further RAN1 input.
Proposal 9 LMF may associate part A for a same location associated with Part B for case 3b by its definition on “same location”. There may be potential assistance information from the UE to help LMF make decisions, but the details are left for further RAN1 input.

3GPP RAN WG2 Meeting #130	R2-2503562
Malta, Malta May 19th – 23rd, 2025             
Agenda item:	8.1.3	
Source:	LG Electronics Inc.
Title:	Remaining issue on NW side Data Collection
Document for:	Discussion and Decision
1. 

Conclusion
Remaining open issues (First priority)
Open issue RRC-18: NW control on retaining logged data at HO 
Observation 1. [Open Issue RRC-18] In cases where the source gNB sends the 1-bit indication to the UE before HO, it can lead to handover delay since the 1-bit indication must be sent before the handover command, potentially delaying handover execution.
Proposal 1. [Open Issue RRC-18] 1-bit indication is sent during HO, i.e., 1-bit indication is included in the RRCReconfiguration message provided by target gNB
Observation 2. [Open Issue RRC-18] For the cases where the target gNB includes the 1-bit indication in the RRCReconfiguration message during HO, there are three approaches:
Option 1: Network implementation: This option has constraints, such as requiring that the target gNB and source gNB be from the same vendor
Option 2:3 A blind request from the target gNB, if data collection is supported by the target gNB: This option has the disadvantages that the 1-bit indication may be unnecessarily set for UEs that do not have logging configuration/logged data
Option 3: Including the indication within the HandoverPreparationInformation: Since the source gNB can inform the target gNB of the logging-related information, the source gNB can set 1-bit indication for the relevant UEs without RAN3 impact
Proposal 2: [Open Issue RRC-18] The target gNB sets a 1-bit indication for the relevant UEs based on the HandoverPreparationInformation received from the source gNB (Option 3). This HandoverPreparationInformation includes an indication whether the source gNB has set a logging configuration, thereby maintaining awareness of potential logged data availability
Open issue RRC-19: Reporting assistance information related to logged measurements 
Proposal 3. [Open issue RRC-19] The otherConfig configures separate bits for low power, buffer full, and buffer threshold reached indications
Open issue RRC-20: Further procedures for UE assistance information related to logging
Proposal 4. [Open issue RRC-20] UAI related to buffer status or low power state is triggered only once when specific conditions are met (e.g., buffer full/threshold, and low power state). A prohibit timer is not necessary for UAI related to buffer status or low power state
Proposal 5. [Open issue RRC-20] No additional signaling from the UE is required when the low power issue is resolved
Proposal 6. [Open issue RRC-20] No additional signaling from the UE is required when the buffer full issue is resolved
Proposal 7. [Open issue RRC-20] When the buffer limit issue is resolved, UE resumes logging at least for periodic CSI-RS according to the retained logging configuration, if any
Open issue RRC-22: RAN1 involvement for logged data for NW-side and UE-side data collection
Observation 3. [Open issue RRC-22] Logging is not limited to periodic physical layer measurements but may also include event-based triggers, such as those based on higher-layer metrics (e.g., L3 cell quality). These conditions are better suited for control and specification at the RRC layer, where network configuration and signaling are managed. 
Proposal 8. [Open issue RRC-22] Logging conditions and control procedures, particularly those related to when and how logging is triggered, should be specified in the RRC layer
Open issue RRC-23: Cell ID stored with logged data for NW-side data collection
Proposal 9. [Open issue RRC-23] Logged data includes the CGI along with the measurement results 
Open issue RRC-24: Where to include the logging configuration from NW to UE
Observation 4. [Open issue RRC-24] If NW-side and UE-side data collection were to rely on separate CSI resource configurations, it would significantly increase both implementation complexity and configuration management overhead. This is especially true as CSI-related use cases expand, leading to scalability challenges. 
Proposal 10. [Open issue RRC-24] Logging configuration is implemented within the CSI framework
Proposal 11. [Open issue RRC-24] To set CSI-ReportConfigId associated with logging operation to the CSI logging config (i.e., CSI-LoggedMeasurementConfig) 
Proposal 12. [Open issue RRC-24] To introduce new reportConfigType-r19 with “none” in the CSI-ReportConfig to prevent CSI reporting 
Observation 4. [Open issue RRC-24] When considering future extensions for mobility-related use cases, introducing a new event for event-based logging may be a suitable approach
Proposal 13. [Open issue RRC-24] For event-based logging, MeasID is linked to event related configuration (i.e., eventTriggeredConfig) 
Proposal 14. [Open issue RRC-24] If P18 is agreeable, new reportType is introduced for logging purpose 
Open issue RRC-25: Dynamic activation/deactivation of data collection configurations for logging
Open issue RRC-30: Semi-persistent resources for data collection
Observation 5. [Open issue RRC-25/30] In general, periodic CSI-RS may be cell-specific, while UE-dedicated CSI-RS, particularly in scenarios requiring beam refinement or per-UE adaptation, may rely on semi-persistent configurations. In such cases, supporting logging on semi-persistent CSI-RS may be necessary to enable data collection for training purposes
Proposal 15. [Open issue RRC-25/30] For measurement/logging for semi-persistent CSI-RS, dynamic activation/deactivation mechanism is supported 
Open issue RRC-27: How to set logging periodicity
Proposal 16. [Open issue RRC-27] The UE performs logging at the logging interval defined in the logging configuration. If no logging interval is configured, the UE shall perform logging based on the RS resource transmission periodicity.
Open issue RRC-29: Whether data availability indication should be sent when the UE has data below the threshold and low power state is sent, and what cause should be included then
Proposal 17. [Open issue RRC-29] No separate data availability indication is included in UE assistance information related to logged data  
Remaining Open issues (Second priority)
Open issue RRC-31: The release of logged AIML data in UE’s buffer 
Proposal 18. [Open issue RRC-31] UE releases logged data under the following conditions:
upon power off
upon deregistration
upon a certain time later, FFS length of timer (like 48-hour timer in logged MDT)
upon successful delivery of the UEInformationResponse message (w/ logged data) 
Observation 6. [Open issue RRC-31] If the logging configuration is set with list-based structure (i.e., ToAddModList and ToReleaseList, delta configuration is possible. A differentiated approach can be applied to ensure efficient data retention and avoid unnecessary loss of valid training data.
Proposal 19. [Open issue RRC-31] Upon receiving a new configuration, the UE discards only the logged data that corresponds to the configuration IDs included in the ToAddModList or ToReleaseList
e.g., If a configuration ID in the ToAddModList matches an existing logged data entry, the UE discards the corresponding logged data
e.g., If a configuration ID in the ToReleaseList matches an existing logged data entry, the UE discards the associated logged data
e.g., The UE retains any logged data that is not associated with configuration IDs in either the ToAddModList or the ToReleaseList
Open issue RRC-35: Release/retain un-retrieved data upon inter-RAT handover
Proposal 20. [Open issue RRC-35] UE releases the logged data before inter-RAT HO by NW implementation, i.e., the gNB releases logging configuration before inter-RAT HO
Open issue RRC-33: Whether separate user consent for gNB centric training is needed
Open issue RRC-36: How data is forwarded to OAM or source gNB after HO
Proposal 21. [Open issue RRC-33/36] Send LS to RAN3 and SA5 to inform them of the agreements made regarding NW-sided logged data collection for AI/ML training

4. 

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

Agenda Item:	8.1.3
Source: 	NEC
Title:  	Discussion on NW-side data collection
Document for:	Discussion and Decision
1 

Conclusions
Proposal-1(RRC-31): maximum logging duration or maximum data size can be considered to release data collection configuration, i.e., when the UE has already logged data up to max duration/size, the UE releases the configuration.
Proposal-2(RRC-31): the following events could trigger UE to clear its buffer:
1. Data collection configuration is released;
2. The UE has already reported the logged data.
Proposal-3 (RRC-21): for data collection temporal domain case, absolute/relative time stamp mechanism should be introduced.
Proposal-4: buffer threshold to trigger data availability indication should be set based on specific size, e.g., KB, MB instead of percentage.
Proposal-5: the UE can send multiple UEInformationResponse messages to respond the same one UEInformationRequest message when large amount of training data need to be reported and UEInformationResponse could include the data availability indication and/or the remaining data size.
4 

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

Source:	CATT
Title:	Consideration on NW side data collection
Agenda Item:	8.1.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the training data collection for NW side model, and the observation and proposals are summarized as follows:
- Mechanism related to NW side data collection
Observation 1: For future AI mobility use cases consideration, the legacy RRM framework should be used as baseline for specification enhancement.
Proposal 1: (RRC-13) Use RRM framework for AI/ML NW side training data collection. The network configures data logging trigger conditions and availability indication reporting trigger conditions related information in the ReportConfigNR IE, and configures the reference signal related information in the MeasObjectNR IE.
Proposal 2: Parameters of l3-Threshold, hysteresis and timeToTrigger can be configured for event-triggered training data logging, similar as eventL1 in logged MDT configuration.
Proposal 3: (RRC-8) Network configures multiple percentages for buffer threshold and configures separate indications for buffer full and low power. 
Proposal 4: Support event-triggered periodic data logging to make a trade-off between the one-shot event based logging and the pure periodic logging.
Observation 2: The method for entries recorded for logged MDT could be reused for the timestamp of training data collection.
Proposal 5: The report of collected training data includes:
For training data collection time marker, the absoluteTimeStamp could be the absolute time when the training data configuration is received by the UE. And the time of each measurement can be represented as a relative time from the absoluteTimeStamp;
For training data marker, the associated ID received in the training data configuration may be used;
For training data collection node, collection node index similar as TCE ID for MDT could be used;
The main content of training data collection could be a list similar as logMeasInfoList, and the detailed content can be revised according to further RAN1 input.
Proposal 6: (RRC-12) Use CGI to identify the cell ID in each entry of training data collection.
- Memory
Proposal 7: Set the minimum memory size of AI/ML training data logging to be 64KB.
- Priority
Proposal 8: SRB6 is configured with lower priority than SRB1 for AI/ML NW side data collection reporting for Beam Management use case.
Observation 3: Network to control not to configure logged MDT measurement and the logged AI/ML training data in the same UE at the same time period.
Proposal 9: (RRC-14) If the UEInformationResponse message includes the logged AI/ML training data, SRB6 will be used irrespective whether other information (e.g. SON/MDT report) is included in the same message.

3GPP TSG-RAN WG2 Meeting #130	R2-2503637
Malta, 19 - 23 May, 2025
Agenda Item:	8.1.3
Source:	Xiaomi
Title:	Discussion on NW-side data collection
Document for:	Discussion

Conclusion
Based on the discussion in section 2, we have following proposals:
Observation 1: Option 2, i.e. target generates the logged data release indication, may introduce impact to RAN3 and LTE spec.
Proposal 1: (RRC-18) Source gNB sends retain/release logged data indication to UE before HO.
Proposal 2: (RRC-19) Full buffer and low power indication can be provided without network configuration (i.e., network does not need to enable UE reporting full buffer/low power in otherConfig).
Proposal 3: (RRC-19) Buffer threshold triggered report requires explicit configuration in otherConfig.
Proposal 4: (RRC-19) Buffer threshold triggered report is optionally supported by UE indicated by capability.
Proposal 5: (RRC-20) No need to introduce ‘buffer not full’ and ‘power state not low’ indication.
Proposal 6: (RRC-20) Prohibit timer for UE assistance information report related to logging (i.e., power state low and buffer full indication) is not needed.
Proposal 7: (RRC-21) UE explicit indicates the absolute time along with first logged data after logging gap is detected. Additionally, for consecutive logged data, UE also indicates the corresponding CSI resource measurement periodicity along with the logged data.
Proposal 8: (RRC-23) UE stores CGI of serving cell along with the logged data.
Proposal 9: (RRC-25) Multiple NW-side training data collection configurations can be configured to UE.
Proposal 10: (RRC-25) Multiple NW-side training data collection configurations can be optionally supported by UE indicated by capability.
Proposal 11: (RRC-25) L1/L2 signalling based dynamic activation/deactivation of NW-side training data collection is not supported.
Proposal 12: (RRC-26) New SRB is only used to report logged data.
Proposal 13: (RRC-27) Logging periodicity is aligned with RS transmission periodicity. No need to introduce separate logging interval setting.
Proposal 14: (RRC-28) Follow legacy RRC handling. UE keeps data collection configuration during RRCReestablishment or transition to RRC_INACTIVE. After RRC reestablishment or resume, serving cell can decide to do delta or full reconfiguration.
Proposal 15: (RRC-29) UE reports data availability if there is any logged data and low power state is detected. The cause value of data availability report can be set to low power.
Proposal 16: (RRC-33) User consent regarding NW side data collection is separate from legacy MDT user consent.
Proposal 17: (RRC-33) Sent LS to ask SA5 to introduce NW side data collection specific user consent.
Observation 2: If NW modifies training data collection configuration, it’s not clear whether UE shall release or keep the logged data.
Proposal 18: If NW releases the data collection configuration, UE releases the logged data. Otherwise, UE keeps the logged data.
Proposal 19: UE can support different data logging AS buffer size across all use cases, which can be indicated by UE capability. FFS on the size of reported AS buffer size.
Proposal 20: NW shall not page UE for NW-side data collection purpose only.

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

Agenda item:	8.1.3
Source:	China Telecom
Title:	Discussion on NW side data collection
WID/SID:	NR_AIML_Air-Core– Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we further discuss the remaining issues related to data availability for NW-side data collection. We have the following proposals:
Data availability indication and cause value
Proposal 1: The cause value for triggering the data availability, including low power, buffer full being reached and buffer threshold being reached, can be encoded as separate bits. 
Proposal 2: Support updating the low power indication and buffer full being reached indication after UE exiting the low power or full buffer state.
Proposal 3: If data logging is stopped due to lower power state or full buffer, support restarting data logging after UE exiting the low power or full buffer state.

UE retains logged data during handover (HO)
Proposal 4: The source gNB sends the 1-bit indication on whether to release or retain un-retrieved data in RRCReconfiguration to UE before HO. 
Proposal 5: If the source gNB sends the 1-bit indication on whether to release or retain un-retrieved data in RRCReconfiguration to UE before HO, the details are as follow:
The source gNB receives the data availability indication, and indicates the UE to release or retain data before sending the handover command. If there is sufficient time, the source gNB may still try to fetch the data.
If the source gNB indicates UE to retain data, the UE might send the data availability indication included in the RRCReconfigurationComplete to target gNB.
After receiving the data availability indication from the UE, the target gNB might fetch the data from the UE. 
After fetching the data from the UE, the target gNB might forward it to the source gNB or OAM.

Proposal 6: The source gNB sends the 1-bit indication on whether to release or retain un-retrieved data to the target gNB during. The target gNB includes the indication in the RRCReconfiguration and send it to the UE during HO.
Proposal 7: If the source gNB decides and sends the 1-bit indication on whether to release or retain un-retrieved data to the target gNB, which includes it in the RRCReconfiguration sent to the UE during HO, the details are as follows:
When the source gNB decides that the 1-bit indication is needed, it can send the indication to the target gNB. 
Then, the target gNB can include the indication in the RRCReconfiguration sent to the UE during HO to indicate the UE to release or retain data.
If the UE is indicated to retain the data, the target gNB might fetch the data from the UE.  
After fetching the data from the UE, the target gNB might forward it to the source gNB or OAM.

3GPP TSG-RAN WG2 Meeting #130	R2-2503691
Malta, May 19th – 23rd, 2025
Agenda Item:	8.1.3
Source:	InterDigital Inc.
Title:	NW side data collection
Document for:	Discussion
1. 

Conclusion
In this contribution, we discussed some of the open issues regarding logging and reporting of data for the training of a network-sided model for the beam management use case, and the following proposals were made:

Proposal 1: If the UE is configured to perform different data collections simultaneously, it will include, in the availability indication, information about the corresponding data collection configuration or/and use case. 
Proposal 2: A new IE/field is introduced to the UEInformationRequest message to indicate the network is requesting the UE to send logged data for network sided model training. The IE may optionally include information about the corresponding data collection configuration or/and use case (if the UE is configured with multiple configurations).
Proposal 3: A new IE/field is introduced to the UEInformationResponse message that will be used to contain the logged data. 
Proposal 4: Time information for the collected data is kept in the same way as logged MDT: 
an absolute time corresponding to the time the data collection configuration was received, and 
for each collected sample, a relative time from the absolute time 
Proposal 5: If data collection continuation after a handover is supported (i.e., collected data contains measurements logged in a source cell and a target cell), the UE will include the following information in the collected data:
serving cell ID (FFS if PCI is sufficient or CGI is required)
(optionally) network side additional condition for the serving cell (e.g., associated ID)
Proposal 6: The collected data from multiple cells is partitioned by the serving cell (i.e., no need to repeat cell ID/associated ID information with each sample).
Proposal 7: The network side data collection configuration will be based on L3 measurement framework. RAN2 to discuss if the data collection configuration will be part of the MeasConfig or separate configuration directly under RRCReconfiguration.
5. 

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

Agenda item:	8.1.3
Source:	Apple
Title:	Remaining issues on NW-sided data collection 
WID/SID:	NR_AIML_Air-Core– Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss remaining issues of NW-sided data collection. Our Observation are: 
Observation 1: When the target cell is legacy cell (e.g. pre-Rel19 NR cell or LTE cell), the UE should discard the logged measurements because target cell doesn’t support NW-side data collection. 
Observation 2: RAN1 didn’t agree to reuse logged data for UE-side data collection. Furthermore, SA2/SA5 are evaluating UP solution of UE-side data collection option 2 and option 3 which is a different direction from NW-side data collection specified in Rel-19 (i.e. CP solution).
Observation 3: As the intention to include Cell ID is to support CA, it is sufficient to use ServCellIndex. Please note that the mapping from ARFCN and PCI to ServCellIndex is configured in ServingCellConfigCommon.
Observation 4: If NW needs the UE to perform data collection only for one particular time duration, it can just reconfigure / de-configurate the data collection via RRC rather than via SP CSI resources. 
Observation 5: In legacy NR, logged MDT, QoE measurements in IDLE/INACTIVE state and QoE paused measurements had specified the minimum AS layer memory size, which are all 64KB according to TS 38.306. 
Observation 6: In existing TS 38.321, L1 CSI reporting is stopped in the following cases because the UE can’t perform L1 CSI measurement on resource configured in deactivated SCell/BWP/SCG:
The SCell is deactivated (in Section 5.9)
BWP is deactivated (in Section 5.15.1)
BWP is dormant BWP (in Section 5.15.1)
SCG is deactivated (in Section 5.15.1)
Observation 7: In TS 38.306, no dedicated UE capability is defined for immediate MDT, which instead includes one basic L3 measurement capability (intraAndInterF-MeasAndReport) and several separate UE capabilities on specific measurement metrics for immediate MDT (e.g. WLAN, BT, barometer, etc.).
Observation 8: As the UE-side model is deployed at UE side, UE-side model is trained by UE side, and thus the required data type corresponding to AI/ML model input is naturally known at UE side. 3GPP should not restrict the data type used for input of AI/ML model training. 

Based on observations, our proposals can be found below:
Remaining RRC open issues on NW-side data collection
Proposal 1: RAN2 confirm the following understanding on NW control on retaining logged data at HO: 
It is up to source cell implementation to determine whether to send the indication retainLoggedMeasurements-r19 to the UE without spec change on inter-node message. 
It is up to source cell implementation whether to send the indication retainLoggedMeasurements-r19 “before HO” or “during HO” (i.e. in same RRC message to carry ReconfigurationWithSync). 
Proposal 2: To cover the legacy target cell case (e.g. pre-Rel19 NR cell or LTE cell), specify the UE shall discard the logged measurement upon HO if absent. The field description can be updated as follows: 
If present, it indicates that the UE shall retain the logged measurements available in VarCSI-LogMeasReport upon completing the handover execution. If absent, it indicates that the UE shall discard the logged measurements available in VarCSI-LogMeasReport (if any) upon completing the handover execution.
Proposal 3: On UAI reporting related to NW-side data collection, keep the 3 separate indications on buffer threshold, full buffer and low power state (i.e. no need of optimization to introduce joint indication like when the UE has data and low power state).  
Proposal 4: The buffer threshold is specified as absolute data amount in the logging buffer (e.g. X KB).
Proposal 5: RAN2 not pursue further optimization on UAI reporting related to NW-side data collection (e.g. prohibit timers, indication that battery state is not low any longer, indication that the memory is not full any longer).
Proposal 6: Logging interval is mandatory configuration for NW-side data collection.
Proposal 7: Legacy timestamp mechanism of logged MDT is reused as baseline of NW-side data collection:
After reception of logging configuration, the UE adds one absolute timestamp. FFS detailed format.  
For each logged sample, add relative timestamp compared with the absolute timestamp. FFS whether some of relative timestamps can be skipped to reduce signaling overhead.
Proposal 8a: As NW-side data collection is RAN2-led objective, no need of RAN1 involvement on logged measurement. 
Proposal 8b: To avoid potential misalignment with UP solution of UE-side data collection being studied in SA2/SA5, RAN2 do not extend logged measurement framework to UE-side data collection.
Proposal 9: As the intention is to support CA, ServCellIndex is logged together with the logged measurements.
Proposal 10: As target for offline training without latency requirement, no need to support dynamic activation/deactivation of logged L1 measurements on SP CSI resources (i.e. it is sufficient to rely on RRC reconfiguration / de-configuration of periodic CSI resources).
Proposal 11: No need to support multiplexing legacy logged data (i.e. data of logged MDT) and AI/ML logged data in the new SRB.
Proposal 12: When L3 measurement event trigger condition is met, the UE periodically performs L1 measurement logging until the trigger condition is no longer met.
Proposal 13: The minimum AS layer memory size for L1 measurement logging is same as existing logged MDT and QoE (i.e. 64KB). 
Remaining MAC open issues on NW-side data collection
Proposal 14: The UE stops L1 measurement logging in the following cases:
The SCell is deactivated
BWP is deactivated
BWP is dormant BWP
SCG is deactivated
UE capability on NW-side data collection 
Proposal 15: Define the following UE capability of NW side model data collection, which is independent of UE capability of immediate MDT:
Introduce a general NW-side data collection capability with forward compatibility (e.g. loggedMeasurements-dataCollection-r19) under UE-BasedPerfMeas-Parameters. For example:
The specific measurement quantities to log are separate UE capability (e.g., L1 RSRP for Set A/B are defined for Rel-19 AI based beam management). 
Collected data type of NW-sided data collection
Proposal 16: On required data type for NW-sided data collection (including AI/ML based beam management and AI/ML based positioning case 3a/3b), RAN2 wait RAN1 L1 parameter excel. 
Collected data type of UE-sided data collection
Proposal 17: On UE-side data collection, RAN2 assume that 3GPP only specify model output, reference signal (RS) used for model input measurement and its configuration. The specific data used for model input and their intermediate processing is up to UE implementation. Send LS to RAN1 to check any issue.

4 

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

Agenda Item:	8.1.3
Source:	MediaTek Inc.
Title:	Further Discussion on Network-Side Data Collection 
Document for:	Discussion, Decision

Conclusion
Open issue RRC-7: NW control on retaining logged data at HO
Proposal 1: RAN2 assumes that the source gNB and the target gNB will coordinate on whether to release or retain the unretrieved data for the UE during the HO preparation phase. 
Proposal 2: The source gNB decides whether to release or retain the unretrieved data based on the coordination with the target gNB. The target gNB then sends the indication to the UE in the RRCReconfiguration message. 

Open issue RRC-8: Reporting assistance information related to logged measurements
Proposal 3: Use a single SetupRelease flag to enable the UE to report assistance information related to logged measurements.

Open issue RRC-9: Further procedures for UE assistance information related to logging
Proposal 4: Buffer status (full buffer or buffer threshold being reached) and power status (low power) are two separate triggers for UAI.
When the UAI is triggered by a low power state, the UE can indicate the availability of data explicitly if configured by the network.
When the UAI is triggered by buffer status, the UE can indicate whether it is a full buffer or buffer threshold being reached.
Proposal 5: There is no need for a prohibit timer or additional indications for UAI triggered by buffer status and UE power state. 

Open issue RRC-10: Time related content of logged data
Proposal 6: The UE provides an absolute timestamp on the first data sample when it starts or resumes data logging.
Proposal 7: RAN2 discuss whether the same timestamping mechanism is applied to both UE-side data collection and network-side data collection.

Open issue RRC-12: Cell ID stored with logged data for NW-side data collection 
Proposal 8: The UE should log the CGI of the serving cell whenever feasible. If CGI is unavailable, the UE shall log PCI-ARFCN as a fallback.
Other Issue
Proposal 9: Only A1 (Serving becomes better than threshold) and A2 (Serving becomes worse than threshold) events can be configured optionally to the UE for data logging.
Proposal 10: If the L3 measurement event (A1, A2) is configured by the network, the UE starts data logging when the entering condition is fulfilled and stops data logging when the leaving condition is fulfilled.

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

Agenda item:		8.1.3
Source:			Sharp
Title:		Discussion on NW-side Data Collection
Document for:	 	Discussion

Conclusion
Based on the above, we have the following observations and proposals.
Observation 1: LMF should be capable of flexibly switching between different NW-side models leveraging different positioning methods, so it may need to collect data with different measurement quantities in different additional conditions.
Observation 2: For Pos use cases, the UE may obtain the ground truth label by itself.
Proposal 1: For BM use cases, the UECapabilityEnquiry and UECapabilityInformation messages are used to request and provide the UE capabilities for data collection for NW-side model.
Proposal 2: For Pos use cases, new IEs AIML-RequestCapabilities and AIML-ProvideCapabilities are used to request and provide the UE capabilities for data collection for NW-side model.
Proposal 3: The UE can include the AS layer memory size information in the RRC/LPP message providing the UE capability information. 
Proposal 4: For Positioning use cases, a new type of ProvideAssistanceData message (e.g., AIML-ProvideAssistanceData) is used for the LMF to configure the measurements, where the configuration can include the required measurement quantity, the PRS resource set, and the associated ID (or area ID or Cell Global Identity).
Proposal 5: For Pos use cases, RAN2 to support on-demand reporting. Additionally, RAN2 to support the indication of data availability.
Proposal 6: For Pos use cases, use a new type of RequestLocationInformation message (e.g., an AIML-RequestLocationInformation message) as the report configuration.
Proposal 7: For Pos use cases, the report configuration further contains: 1) a counter limiting the number of logged instances, 2) a condition that triggers the UE to start logging, 3) an indication whether to report the ground truth label, and 4) the measurement quantities to be reported.
Proposal 8: For Pos use cases, the LMF provides a validity period for the UE to associate the measurement result and the ground truth label.
Proposal 9: For Pos use cases, the following procedure can be considered for on-demand reporting:
Step1: UE indicates the availability of data to the LMF via ProvideLocationInformation.
Step2: LMF requests the logged data via RequestLocationInformation
Step3: UE transfers the logged data to the LMF via ProvideLocationInformation

3GPP TSG RAN2 Meeging #130  	                                                                     R2-2503849                                                                                                                                               
Malta, Malta, 19th – 23rd May , 2025
Agenda item:	8.1.3
Title:	Discussion On the NW Side Data Collection RRC Framework 
Source:	ZTE Corporation, Apple, MediaTek, Samsung, OPPO, Lenovo, Xiaomi, CMCC, China Telecom, vivo, NTT DOCOMO, Sanechips
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on RRC framework for NW side data collection . We have the following observations and proposals:
Observation 1: According to RAN2#129b agreements in both AI PHY and AI mobility, a unified RRC framework for NW side data collection, which is forward compatible to accommodate future use cases (e.g. AI Mobility), is preferred in RAN2.  
Observation 2: Option 2 (i.e. extending L1 CSI framework) requires non-trivial spec changes on RAN1 (TS 38.214). However, RAN1 Rel-19 AI PHY will be closed in May meeting. Thus, option 2 will put a risk on successful completion of RAN2 Rel-19 AI PHY.

Proposal 1: The RRC framework with a same level of MeasConfig is adopt for the NW side data collection.

Proposal 2: Introduce the following new RRC configurations for NW side data collection configuration for AI/ML based Beam management:
- Embed loggedDataCollectionConfig in RRCReconfiguration
- Include bm-DataMeasResourceConfig (measurement resources referring to legacy L1 resource CSI-ResourceConfigId), bm-DataLoggingConfig (logging parameters), and loggedDataCollectionLinkage (resource-logging mapping).

Proposal 3: Send an LS to inform RAN3 of RAN2 agreements regarding RRC framework of NW side data collection for AI/ML based beam management. 

TDoc file reading error

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

Agenda item:	   8.1.3
Source:		Lenovo
Title:	NW side data collection for AI based BM
Document for:		Discussion and Decision

Conclusion

Based on the discussion above, we observe:
Observation 1	The consumer of the logged data can be old serving gNB (for gNB-centric data collection) or OAM (for OAM-centric data collection).


Based on the discussion above, we propose:

Open issue RRC-18:NW control on retaining logged data at HO

Proposal 1	The source gNB sends the 1-bit indication of “retain logged data during HO” to the UE before HO.

Open issue RRC-36: How data is forwarded to OAM or source gNB after HO

Proposal 2	When configuring UE to retain the logged data during HO, the serving gNB should also provide information related to the consumer of the logged data (e.g., cell ID for gNB-centric data collection, or trace reference for OAM-centric data collection).
Proposal 3	When transferring the logged data to the new serving cell after HO, UE also includes the information related to the consumer of the logged data (e.g., cell ID for gNB-centric data collection, or trace reference for OAM-centric data collection).
Proposal 4	Send an LS to RAN3 informing the progress related to the retrieve of logged training data in handover scenario. A draft is provided in Annex.

Open issue RRC-20: Further procedures for UE assistance information related to logging
Proposal 5	RAN2 supports prohibit timer to avoid too frequent data availability indication.

Proposal 6	UE can trigger the data availability report when the event-triggered data logging starts or finishes.

Open issue RRC-31:The release of logged AIML data in UE’s buffer
Proposal 7	The logged data in UE’s buffer will be released upon
a.	Power off or deregistration
b.	48 hrs after the release of logged measurement configuration
c.	Explicit indication from the serving gNB

Proposal 8	If one UEInformationResponse is not enough to convey all logged data, UE should be able to generate and transmit multiple UEInformationResponse messages consecutively without waiting for another UEInformationRequest message.



4	Draft LS to RAN3

Title:	LS on NW side model training data collection for AI based beam management and CSI prediction
Response to:	
Release:	Rel-19
Work Item:	NR_AIML_Air

Source:	RAN2
To:	RAN3
Cc:	

Contact Person:	
Name: 
E-mail Address:	

Send any reply LS to:	3GPP Liaisons Coordinator, mailto:3GPPLiaison@etsi.org 	


1. Overall Description:

For the use case of AI based beam management or AI based CSI prediction, an AI model could be deployed at gNB side. 
In order to collect required data for the training of such gNB-sided model, RAN2 agreed to support gNB-centric and OAM-centric data collection. In case of handover, UE can be configured by the source gNB to retain the logged L1 measurements that has not been reported to network yet during handover. After the handover, UE can indicate the data availability to the target gNB, and the target gNB can later retrieve the logged L1 measurements from UE via the UE information procedure.

2. Actions:
To WG RAN3
ACTION: 	 
RAN2 kindly asks RAN3 to take the above progress into account in their future work and provide further feedback if any.

3. Date of Next RAN2 Meetings:
RAN2#131		25th – 29st Aug 2025	TBC, IN
RAN2#131bis		13th – 17th Oct 2025	Malta, MT

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

Agenda item:	   8.1.3
Source:		Lenovo
Title:	NW side data collection for AI based positioning
Document for:		Discussion and Decision

Conclusion

Based on the discussion above, we observe:
No table of figures entries found.

Based on the discussion above, we propose:

Proposal 1	For (case 3a) NG-RAN node assisted positioning with gNB-side model, RAN2 assumes LMF collecting training data from PRU or non-PRU UE via existing LPP procedures (e.g., RequestLocationInformation and ProvideLocationInformation) without specification impact.
Proposal 2	For (case 3b) NG-RAN node assisted positioning with LMF-side model, RAN2 assumes LMF collecting training data from PRU or non-PRU UE via existing LPP procedures (e.g., RequestLocationInformation and ProvideLocationInformation) without specification impact..

 

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

Title:	Discussion on NW-side Data Collection for BM
Agenda item:	8.1.3
Source:	Google
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discussed the potential solutions for the remaining issues on NW-side data collection for BM. The related observations and proposals are summarized below:
Observation 1: When the triggering condition (buffer full, buffer threshold or low power) is met, there may be no required logged data in the UE buffer.
Observation 2:  The source NW cannot determine the time information of periodical logged data when receiving logged data from the other node after handover.
Observation 3: The logged data for source cell may not be retrieved by the target cell before a subsequent handover command. 
Proposal 1: (RRC-7) The 1-bit indication on whether to release or retain un-retrieved data is sent in RRCReconfiguration before the HO.
Proposal 2a: (RRC-8) The NW configures:
low power as the triggering of low power state reporting in UAI
Buffer full or buffer threshold as the triggering of buffer state reporting in UAI
Proposal 2b: (RRC-8) The UE includes the following information in the UAI:
Low power state
buffer state set to full buffer or buffer threshold triggered
availability indication if there is logged data for the gNB
Proposal 3: (RRC-9) If configured, the UE reports the exit of low power state, or full buffer state.
Proposal 4: (RRC-10) Time information is included for both periodical and event-based logged data.
Proposal 5: (RRC-10) The UE includes absolute and relative timestamps for the logged data.
Proposal 6: (RRC-13) A unified framework is for both NW-side and UE-side data collection.
Proposal 7: (RRC-13) The data collection configuration is included directly under the CSI-MeasConfig in the CSI framework.
Proposal 8: Define an explicit logging interval for periodic data logging.
Proposal 9: Define a list of data logging configurations including logging parameters for both periodic and event-triggered logging. Each data logging configuration is associated with a unique ID, e.g., CSI-LoggingConfigId.
Proposal 10: For data collection configuration, one CSI-LoggedMeaurementConfigId links one CSI-ResourceConfigId and one CSI-LoggingConfigId.
Proposal 11: The minimum memory size is 64 KB.
Proposal 12: The UE memory is shared for data collections for both NW-side model training (e.g., initiated by OAM, gNB or LMF) and UE-side model training.
Proposal 13: When reporting the logged data content, the UE includes a cause indication (e.g., event not triggered/event triggered infrequently, others) for the CSI-LoggedMeasurementConfigId with no or insufficient logged data.
Proposal 14: Upon reception of a subsequent handover in the target cell, the UE manages the logged data for the source cell in the following options:
Opt 1: Discard the logged data for the source cell upon receiving the subsequent HO CMD from the target cell
Opt 2: 
If the new target cell is the source one, the UE retains the logged data for source cell
Otherwise, the UE discards the logged data for the source cell

TDoc file reading error

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

Agenda item:	8.1.3
Source:	Nokia
Title:	Data Collection for Training of network-side ML models
WID/SID:	NR_AIML_air-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: 
Observation 1: UE can send a UAI message without a low power state indication if UE’s power state is no longer low.
Observation 2: After handover, the target cell should have sufficient time to retrieve and transfer the logged data for network-side data collection from a UE to the source cell.
Observation 3: While waiting for the target cell to transfer logged data for network-side data collection from a UE, the source cell must retain the context of the UE which was handed over, and it should not have to do so indefinitely.
Observation 4: The UE will already store the serving cell index with its data samples to differentiate data collected for different serving cells, e.g., in the case of carrier aggregation.
Observation 5: Since the target cell knows the identity of the source cell, a cell ID is not required to be stored with logged data for network-side data collection.
Observation 6: It is unlikely that both logged data for SON/MDT and logged data for network-side data collection would become available at the same time.
Observation 7: The gNB may lose the context of measurements logged and reported by the UE if it releases the measurement logging configuration from the UE.
And proposed the following:
Proposal 1: Allow reporting of all assistance information (low power state, buffer full, buffer threshold reached indicators) related to logged measurements to be configured with a single bit.
Proposal 2: To avoid too frequent sending of UE assistance information related to logging, adapt one of the following options:
a) UE can only notify the network once per indication and wait until network takes an action.
b) UE can itself decide when to send the next indication.
c) Introduce a prohibit timer. 
Proposal 3: No additional indication needed to indicate that the buffer is not full.
Proposal 4: Only the immediate target cell can retrieve logged data for network-side data collection from a UE after handover.
Proposal 5: The cell ID is not included in the logged data for network-side data collection. 
Proposal 6: To harmonize different CSI use cases, use CSI-ReportConfig for network-side data collection within CSI-MeasConfig.
Proposal 7: Include logging configurations for network-side DC inside of CSI-ReportConfig, using new reportQuantity related to logging or using a new type of quantity, e.g., loggingQuantity, either of which would differentiate data collection between UE-side models and network-side models. 
Proposal 8: Disallow the simultaneous request for logged data for SON/MDT and logged data for network-side data collection.
Proposal 9: No logging periodicity to be introduced in Release 19. The UE should assume the same logging periodicity as the reference signal transmission periodicity received in the measurement configuration.
Proposal 10: If the UE is in a low power state AND it has data in its buffer, even below the threshold, UE can still indicate both low power state and buffer threshold met indications. That is, no additional cause or flag is required.
Proposal 11: Send an LS to RAN3/SA5 providing the background information and the RAN2 agreements of retaining logged data at handover and asking RAN3/SA5 to introduce the necessary enhancements in their specifications in Rel-19 that enable the support of the RAN2 agreements. (See draft LS in Annex.)
Proposal 12: If a new logged measurement configuration is configured in the UE with the same ID as an existing logged measurement configuration, the UE shall discard samples belonging to the old configuration.
Annex: Draft LS to RAN3/SA5
3GPP TSG-RAN WG2 Meeting #130	R2-250xxxx
St. Julians, Malta, 19 – 23 May 2025

Title:	[DRAFT] Logged Data Handling During Handover       
Response to:	-
Release:	Release 19
Work Item:	NR_AIML_air-Core

Source:	Nokia [TSG RAN WG2]
To:	RAN3, SA5
Cc:	

Contact Person:
Name:	First Last
E-mail Address:	first.last@nokia.com

Send any reply LS to:	3GPP Liaisons Coordinator, mailto:3GPPLiaison@etsi.org 	

Attachments:	-


1. Overall Description:
Regarding the handling of logged data collected for NW-side data collection at handover RAN2 has made the following agreements: 
At RAN2#129:
- UE retains logged data during handover (HO).  FFS if there is scenarios where the UE needs to release the data and how does the UE know and if control from network is needed
- UE indicates availability of logged data during handover (i.e., within the RRCReconfigurationComplete message) (if data is retained in the UE).
At RAN2#129b: 
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).   FFS signaling details.
RAN2 has also agreed that a UE does not retain logged data for a source cell when a subsequent handover occurs; e.g., the UE collects data for gNB1, hands over to gNB2, and then to gNB3. gNB3 is not expected to forward logged data to gNB1.
RAN2 would like to clarify that the data collection configuration could originate in the source gNB or from OAM. When the configuration originates in the gNB, the final destination of the collected data is the source gNB. When the configuration originates in OAM, the final destination of the collected data is the Trace Collection Entity (TCE). Note that this data collection only happens when the UE is in RRC_CONNECTED state and this data collection is unrelated to legacy logged MDT.
RAN2 respectfully asks RAN3 and SA5 to introduce the necessary enhancements in their specifications in Rel-19 that enable the support of the above RAN2 agreements, if feasible. More specifically RAN2 would like to request RAN3 and SA5 to specify that after a handover the target gNB retrieves the logged data collected by a UE configured to log data in RRC_CONNECTED state at the source gNB and then the target gNB forwards the logged data towards its final destination.

2. Actions:
To RAN3, SA5
ACTION: 	RAN2 respectfully asks RAN3 and SA5 to introduce the necessary enhancements in their specifications in Rel-19 that enable the support of the above RAN2 agreements if feasible.

3. Date of Next TSG-RAN WG2 Meetings:
RAN2#131	from 2025-08-25	to 2025-08-29		Bengaluru, IN
RAN2#131bis	from 2025-10-13	to 2025-10-17		Prague, CZ

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

Title: 	Discussion on NW-sided data collection for training
Source: 	Huawei, HiSilicon
Agenda item:	8.1.3
Document for:	Discussion/Decision

Conclusion
Based on the discussion in the Tdoc the following, we provided the following observations and proposals:
Event-triggered logging details [RRC-21]
Proposal 1: For the event-triggered logging, RAN2 confirms that the definitions of events A1 and A2 will be reused. 
Proposal 2: (RRC-21) When the gap occurs in the logged measurements, the length of the gap should be indicated to the network either via:
Explicitly reporting gap length in the first sample of each “block” of samples; or
Adding a time stamp to a first sample of each “block” of samples. 

Data Availability Indication [RRC-19, RRC-20]
Proposal 3: (RRC-19) Data availability triggering threshold should be configurable per data collection configuration.
Proposal 4: (RRC-20) The UE should include the corresponding configuration identifier in the data available indication to support NW to request a certain data collected by the UE.
Proposal 5: (RRC-20) The network should be able to request the UE to send collected data for a specific data collection configuration.
Proposal 6: (RRC-19) The indications reported by the UE as part of UAI for data collection purpose are controlled by the network in the following way: 
Full buffer indication is enabled by default when the UE is configured with data collection
Data threshold is enabled by including data threshold in the configuration
Low power state reporting is enabled by including a corresponding prohibit timer in the configuration

Low power state indication [RRC-19, RRC-20, RRC-29]
Proposal 7: (RRC-20) When the NW receives the low power state indication from a UE, the NW may use RRC Reconfiguration to either release the data collection or suspend it without removing it from UE’s RRC configuration.
Proposal 8: (RRC-20) When the UE exits low power state, it indicates it to the network and the network may either configure a new data collection configuration or resume a suspended configuration.
Proposal 9: (RRC-19) Prohibit timer for low power state indications is introduced.
Proposal 10: (RRC-29) When the UE sends low power state indication to the network and it has already collected some data, it should also include data availability indication, e.g. with ‘low power’ cause.

Configuration details [RRC-23, RRC-25, RRC-27, RRC-30]
Proposal 11: (RRC-25) (RRC-30) Only periodic CSI resources are used for NW sided data collection, i.e. neither aperiodic nor semi-persistent CSI resources are supported for this purpose.
Proposal 12: (RRC-27) There is no need to configure logging periodicity separately, i.e. the measurements are logged according to the periodicity of the CSI resource used for data collection. 
Proposal 13: (RRC-23) Cell ID stored with logged data for NW-side data collection should be a CGI. 

SRB for data reporting [RRC-26]
Proposal 14: (RRC-26) If both the legacy SON/MDT report and AIML logged data are included in a single UEInformationResponse, the UE should select a new SRB to transmit such message. 

Collected data handling during HO/CHO/LTM [RRC-18, RRC-36, RRC-37]
Proposal 15: (RRC-36) After receiving the data available indication from the UE, the target gNB should fetch the data from the UE and forward it to the source gNB or OAM. RAN3 should discuss and specify the details.
Proposal 16: (RRC-18) The source gNB sends the 1-bit data discard/retain indication to the UE in a separate RRCReconfiguration message sent before HO command.
Proposal 17: (RRC-37) The UE should include the logged data availability indication in the L3 measurement report. 
Proposal 18: (RRC-18) For CHO/LTM, a collected data retain/discard indication can be pre-configured by the gNB for each CHO/LTM candidate cell. 

3GPP TSG RAN WG2 Meeting #130	 R2-2504219
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.1.3
Source:	Futurewei
Title:	Discussion on Data Collection for NW-side Model Training
Document for:	Discussion

Conclusions
In this contribution, we continued to present our observations and views on topics related to NW-side data collection. Based on the discussions in the previous sections, our proposals are as follows.  
Proposal 1: Support on-demand data logging and enhancement to logged MDT for data collection for NW-side models.
Proposal 2: Periodic measurement logging after a one-time triggering event should have a predetermined stopping trigger.
Proposal 3: Support event/trigger-based reporting mechanisms in addition to on-demand request reporting for NW-side data collection.
Proposal 4: Design a mechanism for a UE to report its capability and/or capacity to the NW, such as computational power, available memory and storage space. NW decides on whether immediate MDT or logged MDT to be used based on the UE’s capability and capacity.  
Proposal 5: Use percentage of the buffer size as the indication of buffer availability for NW-side data collection.  

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

Source:	Qualcomm Incorporated 
Title:	Open Issues on Network Side Data Collection 
Agenda Item:	8.1.3 NW Side Data Collection 
Document for:	Discussion and Decision
Introduction & 

Conclusion
Data collection and reporting for the beam management use case

Proposal 1: If the UE supports the training data collection and logging for the network side model training, the network should continue to ensure that the maximum number of SSB/CSI-RS configured/activated for measurements lies within the maximum number of SSB/CSI-RS measurements supported at the UE per slot and per FR. That includes SSB/CSI-RS used for 
Different non-AI/ML-related tasks (i.e., legacy CSI reporting for different purposes), and
Different AI/ML-related tasks (e.g., training data collection configuration, inference, and monitoring).

Proposal 2: Introduce a one-bit indication for low power indication.

Proposal 3: For the data availability, a one-bit indication is used to indicate the reason for the trigger (full buffer, threshold). Data availability is implicitly indicated by the reason for the trigger (full buffer, threshold). 

Proposal 4: If the UE cannot detect the configured/activated CSI Resource (CSI-RSs or SSBs) for the network side data collection, the UE indicates to the network that the configured/activated CSI-ResourceConfig is not suitable.

Proposal 5: The CSI-LoggedMeasurementConfig for logging L1 measurements should be provided per serving cell to collect measurements on PCell and its SCell, or PSCell and its SCells.    

Proposal 6: The CSI-LoggedMeasurementConfig should contain the serving cell index.    

Observation 1: The CSI-logMeasInfo (containing L1 measurement for network-side model training) is primarily retrieved by the configuration node. Therefore, based on the reported CSI-LoggedMeasurementConfigID in the CSI-logMeasInfo, the network should be able to determine the CellID unambiguously.  

Proposal 7: No need to report cellID additionally in the CSI-logMeasInfo. The network determines the CellID unambiguously based on the reported CSI-LoggedMeasurementConfigID in the CSI-logMeasInfo.

Proposal 8: Additional reporting of cellID together with CSI-LoggedMeasurementConfigID may be needed only when the CSI-logMeasInfo is retrieved by the target cell after the handover. 

Proposal 9: The UE may report the CGI of the cell if available; otherwise reports the PCI and ARFCN.  

Proposal 10: The new SRB introduced to report data collection for network side model training can be used to report the existing SON and logged MDT report.

Observation 2: The purpose of indicating a 1-bit indication on whether to release or retain unretrieved data in RRCReconfiguration is to avoid inter-vendor information leakage. 

Observation 3: The serving cell may not even know the suitable target cell beforehand, therefore, it may not know whether the target cell belongs to the same vendor or a different one. 

Proposal 11: The serving cell cannot preconfigure the UE with a 1-bit indication on whether to release or retain unretrieved data, as it cannot know the target cell beforehand. 

Proposal 12: Receiving the 1-bit indication from the target gNB is not a suitable solution, as a rogue target cell may send the 1-bit indication irrespective of whether it is configured to do so or not by the serving cell.  

Proposal 13: To avoid inter-vendor information leakage, the serving cell can configure the UE with cell IDs (among the neighbor cell list), where the UE can send availability indications and data collection reports, is more suitable. 

Observation 4: Since the scope is only for the handover, the cell ID list can be significantly smaller, resulting in less overhead. 

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

Agenda item:	8.1.3
Source:	CMCC
Title:	Discussion on time info for NW side data collection
WID/SID:	NR_AIML_air-Core
Document for:	Discussion
 

Conclusion
Here are the proposals for NW side data collection.
Observation 1: The time info is necessary for model training considering the following aspects:
- For event-triggered data collection, the network cannot be aware of when the event is satisfied
- For periodic data collection, the periodicity can be changed, or the target gNB cannot be aware of the periodicity configuration within source gNB during handover
- For model training at OAM using datasets from multiple gNBs, OAM cannot be aware of the specific the time information
- For the scenario that UE reports the data collected within serving gNB to target gNB, the target gNB does not have the data collection configuration and cannot be aware of the time info
Proposal 1: The time info of logging measurement results should be included for NW side data collection.
Proposal 2: RAN2 to discuss the following options to indicate the gap between the two consecutive samples:
- Option 1: Similar mechanism as logged MDT, i.e. the absolute time stamp which indicates when the logged measurement is provided, and the relative time stamp which indicates the time of logging measurement results
- Option 2: The absolute time stamp which indicates when the logged measurement is provided, the relative time stamp which indicates the start time of logging measurement results, and periodicity info which indicates the period of logging measurement results

4	

3GPP TSG-RAN WG2#130	     					       R2-2504416
Malta, May 19 – 23, 2025
Agenda item:	8.1.3 
Source: 	Kyocera 
Title: 	Remaining Issues on NW side data collection
Document for:	Discussion 

Conclusion 
This contribution discusses the issues in terms of NW side data collection. RAN2 is kindly asked to take into account the proposals below:
Proposal 1	RAN2 should agree to handle all logs collectively without distinguishing them based on use cases or configurations.
Proposal 2	RAN2 should agree that both “data is available” and “low power” shall be treated as semantically independent information elements in the availability indication.
Proposal 3	RAN2 should agree to introduce an absolute timestamp only for the Enter time of event-based logging.

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

Agenda Item:	8.1.3
Source:	HONOR
Title:	Discussion on NW side data collection
Document for:	Discussion and Decision
1. 

Conclusions
In this contribution, we discussed the issues related to NW side data collection. Based on the discussion, the following proposals are concluded:
Proposal 1: (issue RRC-18) It is suggested to indicate release or retain un-retrieved data per functionality/ use case/ measurement configuration.
Proposal 2: (issue RRC-18) While accessing to the target gNB, the UE indicates the availability of collected data in RRCReconfigurationComplete message.
Proposal 3: (issue RRC-21) A timestamp should be reported for logged data.
Proposal 4: (issue RRC-21) The absolute timestamp of the first sample should be indicated and the relative timestamp of the subsequent samples can be deduced based on the configured data logging interval or the configured CSI-RS resource periodicity.
Proposal 5: (issue RRC-25) Dynamic activation/deactivation for data logging via L1/L2 signalling is not supported.
Proposal 6: (issue RRC-27) The data logging interval can be configured for both periodic data logging and event triggered data logging.
Proposal 7: The associated ID configured in training data configuration can be reported together with the logged data.
Proposal 8: For logged data report, the UE side additional condition can be reported separately.
4. 

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

Agenda Item:	8.1.3
Source:	ASUSTeK 
Title:	Discussion on Remaining RRC open issues for NW-sided data collection
Document for:	Discussion and Decision

Conclusion
Proposal 1: The logging configuration only includes logging related parameters (i.e., excluding the measurement targets).
Proposal 2: The logging configuration can be placed in a new IE or CSI-MeasConfig.

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

Agenda Item:	8.1.3
Source:	Ericsson
Title:	NW-side data collection for beam management and positioning
Document for:	Discussion
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	(RRC-21) Multiple logging configurations result in the UE logging interleaved measurement entries from different logging configurations, where subsequent entries are not equally separated in time according to known periodicities.
Observation 2	(RRC-21) Including relative time stamps for each logged entry is not expected to introduce major overhead issues, given the UEInformationRequest/ UEInformationResponse framework agreed for fetching logged data.
Observation 3	(RRC-24) Reusing CSI-ReportConfig to configure the UE with NW-side data collection configuration leads to impact on legacy beam management procedure and creates additional constraints on the data collection procedure.
Observation 4	Case 3a/3b NW side data collection should be driven by RAN3 as it has primarily NRPPa impact.

Based on the discussion in the previous sections we propose the following:
Proposal 1	(RRC-18) The 1-bit indication signals to the UE to retain unretrieved logged data upon HO completion. In absence of this indication, the UE releases unretrieved logged data upon HO completion.
Proposal 2	(RRC-18) The 1-bit indication (decided by the source gNB) is sent to the UE in the HO command from the target gNB, i.e. in RRCReconfiguration containing reconfigurationWithSync.
Proposal 3	(RRC-19) The “buffer threshold reached” indication is configured with a dedicated field in otherConfig, which gives the value of the threshold. The “full buffer being reached” and “low power” indications are configured jointly in otherConfig.
Proposal 4	(RRC-19) The buffer threshold value is specified as a percentage of the UE buffer size.
Proposal 5	(RRC-20) The UE indicates “full buffer reached”, “buffer threshold reached” and “low power” only upon entering these states and not while continuing to stay in these states.
Proposal 6	(RRC-20) If configured to report assistance information related to data logging, the UE indicates when it is no longer in low power state and when its buffer is no longer full.
Proposal 7	(RRC-21) The UE includes in the logged measurement report an absolute time stamp (provided by the network at the time of configuring the UE with the NW-side data collection configuration), and for each measurement entry, a relative time stamp related to the point in time in which the measurement was taken.
Proposal 8	(RRC-22) L1 procedures to perform radio measurements and logging for the NW-side data collection purpose are not captured in RAN2 specification. RAN1 to evaluate impact in TS 38.214.
Proposal 9	(RRC-22) RAN2 to inform RAN1 about any agreements related to UE configuration for NW-side data collection, contents of the report with logged data and needed procedural text for NW-side data collection.
Proposal 10	(RRC-23) When the UE reports logged data, it does not repeat the cell ID for every measured logged entry performed on the same serving cell.
Proposal 11	(RRC-23) Within logged data for NW-side data collection, UE includes CGI of the serving cell in which it performs the logged measurements, if available.
Proposal 12	(RRC-23) If CGI of the measured cell for logging is not available, UE logs the PCI-ARFCN of the measured serving cell and the CGI of the PCell or PSCell to which the UE is connected while performing the logging of the measured data.
Proposal 13	(RRC-24) The L1 CSI measurement configurations for the NW-side data collection consist of a list of logging configurations within the legacy CSI-MeasConfig.
Proposal 14	(RRC-24) Each logging configuration contains a reference CSI resource configuration (i.e. a reference to a CSI-ResourceConfig IE) on which the UE shall perform radio measurements and the related logging, and if configured, the L3 events (A1/A2 thresholds, TTT).
Proposal 15	(RRC-25) Dynamic activation/deactivation of logging configurations for NW-side data collection is supported. FFS whether to introduce a new MAC CE or to enhance a legacy MAC CE, based on the outcome of open issue RRC-24.
Proposal 16	(RRC-26) The UEInformationResponse is transmitted via SRB2 when containing logged data for NW-side data collection.
Proposal 17	(RRC-27) The logging periodicity/interval for both periodic and event-triggered data collection is configured in the L1 CSI measurement configurations for data collection.
Proposal 18	(RRC-28) UE releases the configuration for data availability and low power state indications upon transition to RRC_INACTIVE/IDLE and upon initiating the RRCReestablishment procedure.
Proposal 19	(RRC-29) UE does not send data availability indication when it sends low power indication, if the amount of data is below the configured buffer threshold.
Proposal 20	RAN2 to wait for RAN3 before checking/working on if there is any impact for RAN2 for case 3a/3b data collection.

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

Agenda Item:	8.1.3
Source:	Ericsson, Nokia, Huawei, T-Mobile USA, BT Plc.
Title:	Discussion on NW-side data collection framework
Document for:	Discussion
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	Including the L1 CSI resource configuration into the L3 MeasObjectNR IE for the NW side data collection raises the following concerns:
a.	Unclear benefits, given the current mechanisms for the gNB-DU and gNB-CU to configure the L1 CSI measurements, and the L3 measurements respectively, for a serving cell
b.	Added complexity to the gNB-CU, to change the handling of L1 measurements configurations received from the gNB-DU
c.	Added complexity to the UE, given the reception of L1 measurement configurations outside the legacy CSI-MeasConfig.
d.	Added complexity if dynamic activation/deactivation of NW-side data collection configurations is supported
Observation 2	Based on legacy RRC and F1AP specifications, the UE is already aware of the serving cell MO to use for L3 measurements (in case the network wants to configure the UE with L3 event based L1 data collection), as well as the gNB-DU.

Based on the discussion in the previous sections we propose the following:
Proposal 1	The L1 CSI measurement configurations related to NW-side data collection are included within the CSI-MeasConfig. FFS which exact IE/parameter to use.
Proposal 2	For the L3-event triggered L1 data collection, RAN2 to discuss the following alternatives:
a.	The L3 event configuration (A1/A2 thresholds, and the TTT) are included in the L1 CSI measurement configurations. FFS how to ensure that the NW is transmitting the L1 CSI-RS corresponding to the logging configuration when an L3 event for L1 CSI measurement logging triggers.
b.	Upon receiving an ordinary L3 measurement report, the gNB activates/deactivates the L1 data collection. No need to include L3 events (e.g. A1/A2 thresholds, and the TTT) in the CSI measurement configuration.
4	

3GPP TSG-RAN WG2 Meeting #130	R2-2504651

St. Julians, Malta, May 19th – 23rd, 2025
Agenda item:	8.1.3	
Source:	Rakuten Mobile
Title:	Further Discussion on NW-Side AI/ML Data Logging Framework
Document for:	 Discussion and Decision
1. 

Conclusion 
In this contribution, we provide our views for Rel-19 NW-side AI/ML Data Logging Framework, and the observations and proposal are summarized as follows:
Logging Configuration & Triggering 
Observation 1
No single IE configures an A1/A2-based trigger together with an optional logging interval.
Proposal 1
Introduce LoggingTriggerConfig under AIML-LoggingConfig in TS 38.331

Data-Availability & Constraint Reporting 
Observation 2-1
The draft offers only one flag; the gNB cannot prioritise urgent low-power cases over routine buffer-threshold events.
Proposal 2-1
Add structured element in UEAssistanceInformation / UAI:
DataAvailabilityIndication ::= SEQUENCE {
   cause ENUMERATED {
       bufferThresholdReached (0),
       bufferFull            (1),
       lowPower              (2)
   },
   remainingBytes INTEGER (0..262143) OPTIONAL
}
Observation 2-2
No IE allows the network to select between nw-controlled and UE-autonomous availability-trigger logic.
Proposal 2-2
Add field availabilityTriggerMode to AIML-LoggingConfig in TS 38.331:

Observation 2-3
The spec provides only an on/off availability flag; it cannot convey why logging paused.
Proposal 2-3
Extend UEAssistanceInformation and UAI with:


Retention & State / Mobility Handling
Observation 3
Without a deterministic location and expiry timer, vendors differ on when logs are purged.
Proposal 3
3-1 Add Boolean retainLoggedData in source-cell RRCReconfiguration sent before HO execution. Include retentionTimer (24–168 h, default 48 h) inside AIML-LoggingConfig. UE discards retained logs when the timer expires or after HO/RRC_IDLE/RLF.
Observation 3-a
logMeasEntry and aiLogMeasEntry lack a session tag.
Proposal 3-a
Prepend 5-bit logConfigID to both entry structures:
aiLogMeasEntry-v19a0 ::= SEQUENCE {
    logConfigID   INTEGER (0..31),
    ...           -- existing fields
}

Data Format & Metadata 
Observation 4
Message-level context alone cannot reassemble interleaved segments.
Proposal 4
Add fixed header to every UEInformationResponse segment:
AIMLLogHeader ::= SEQUENCE {
   logConfigID  INTEGER (0..15),
   segmentNo    INTEGER (0..255),
   lastSegment  BOOLEAN,
   logPriority  ENUM {normal, high},
   moreSegmentsPending BOOLEAN
}
Add cellId, gapInd, and optional entryPriority to each LoggedMeasurementEntry.

Transport Bearer & SRB Use
Observation 5
Single LCG on SRB-4 can create head-of-line blocking.
Proposal 5
Map AI/ML log PDUs on SRB-4 to new logicalChannelGroup, (aiModelData); MDT remains on its existing LCG. Scheduler may throttle using moreSegmentsPending.
When moreSegmentsPending=1 UE continues using SRB-4 / aiModelData-LCG until all segments sent

Cross-layer RS Referencing
Observation 6
Spec provides no mechanism to reference or inherit RS sets.
Proposal 6
Add optional linkedCSI-ReportConfigId (INTEGER(0..255)) inside AIML-LoggingConfig. If present, UE inherits RS definitions from that CSI-ReportConfig; else it uses explicit RS IDs. 
Proposal 6-a
Liaison RAN-1 request: expose stable rsSetId in CSI-ReportConfig ASN.1.

Memory / Buffer Limits
Observation 7
A method needed to Distinguish, low-cap UEs over-trigger and high-cap UEs under-trigger.
Proposal 7
7-1- Require ≥ 32 kB dedicated AS-layer memory for AI logs; UE declares bufferSizeCap in UECapabilityInformation-AI.
7-2 Signal bufferThreshold in absolute bytes; UE clamps to 50–90 % of declared capacity.

Combined Trigger-Mask Field
Observation 8
No unified mask lets the network enable/disable multiple triggers per session.
Proposal 8
Inside LoggingTriggerConfig, add triggerMask BIT STRING (SIZE (4)) — bits {periodic, X1, X2, lowPower}.
UE logs when any enabled bit condition is satisfied.

4