3GPP TSG-RAN WG2 Meeting #130	R2-2503385
St Julian’s, Malta, 19-23 May 2025
Agenda Item:	8.1.4
Source:	NEC
Title:	Analysis of solutions for UE side model data collection
Document for:	Discussion, Decision

Conclusion and Proposal
We have the following observations and proposals:
Proposal-1: Data transfer over RRC for UE side model data collection is not pursued.
Proposal-1a: Study a new protocol layer above RRC layer to handle the data segmentation if CP based approach is pursed for Data report for UE side model data collection.
Proposal-2: Data transfer over UP for UE side model data collection is prioritized for Option-2.
Proposal-2a: The existing NWDAF (Network Data Analytics Function) entity in the current 5G CN domain may be used for Data Collection Function purpose for AIML model training for Option-2.
Proposal-2b: To support Data transfer over UP for UE side model data collection, NAS layer may be employed to configure the data collection configuration and data report criteria to the UE for Option-2.
Proposal-3: RAN2 to discuss if it is UE initiated procedure or network initiated procedure to trigger the data report from the UE to the network.
Proposal-3a: NG-RAN may be involved in the paging procedure to page the UE to trigger the report for its collected data in case of network initiated procedure.    

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130		R2-2503402
St Julian’s, Malta 19th – 23rd, May 2025
                         
Source:	vivo
Title:	Discussion on UE side data collection
Agenda Item:	8.1.4
Document for:	Discussion and Decision

Conclusion
This contribution concludes with the following:
RAN aspects related to data transfer over UP
With existing PDU session establishment procedure to setup UP tunnel, NG-RAN node is only involved in resource allocation and configuration of the DRBs to UE for the PDU session. NG-RAN node is not aware whether the PDU session is used for training data transfer purpose.
For UE data transfer over UP, RAN2 assumes that the existing PDU session management procedure can be reused and the NG-RAN node is not aware that the PDU session is utilized for training data transfer. RAN2 will revisit this assumption after receiving SA2/SA5 feedback on the UP-based data transfer solutions.
NG-RAN involvement in UE side data collection
The following three levels of NG-RAN involvement in the control and configuration of UE side data collection can be considered:
- Level 0: Not involved. Level 0 is applicable for positioning use case.
- Level 1: Control the RS configuration provision. Level 1 is applicable for Option 1a of beam management use case.
- Level 2: Control the RS configuration provision and data logging configuration. Level 2 is applicable for Options 2/3 of beam management use case.
LS to RAN1 to ask which parameters can be provided to UE as candidate data collection configuration for UE to request.
NG-RAN involvement in UE side data transfer
For CP-based UE side data collection Option 2, NG-RAN is only involved in NAS information transfer from UE to CN. The data content is specified and can be visible to CN while is not visible to NG-RAN.
For CP-based UE side data collection Option 3, NG-RAN can control the reporting configuration for data collection and the data content is specified and is visible to NG-RAN. After acquiring the data from UE, NG-RAN will further transfer the data to OAM, which is in the scope of SA5.
Scalability Aspects of CP
The main difference between CP-based solutions of UE side data collection and NW side data collection is only whether the NW will further transfer the training data to the server for data collection for UE-side model training/OTT server.
The framework/agreement of NW side data collection is reused for CP-based UE side data collection.
No scalability issue for CP-based UE data collection and data transfer.

3GPP TSG RAN WG2 Meeting #130         	                          R2-2503451
St. Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.1.4
Source:	Xiaomi
Title:	Discussion on RAN impact of UE-side data collection
Document for:	Discussion and Decision

Conclusion
In this contribution, we discussed remaining RAN impact of UE-side data collection and provide the following observations and proposals:
Visibility/Controllability
Proposal 1: NG-RAN has full visibility on UE-side data collection configuration (i.e., what data UE collects) and full visibility/controllability on whether UE starts/stops UE-side data collection.
RAN impact
Proposal 2: For UP data transfer via CN, RAN2 wait for SA2 conclusion on data transfer via UP, including initiation, termination, management of data transfer (PDU session establishment); differentiation between UE-side data collection and regular UE traffic (QoS); full visibility of standardized data (mapping between configuration and data content),etc.
Proposal 3: UP data transfer via OAM (i.e., Solution 3 via UP tunnel) is not considered as a candidate solution in 5GA Rel-19/20.
Observation 1: Restriction using CP for massive data size transfer is the same for UL and DL is the same as OTA solutions for two-sided model NW dataset/model parameter transfer.
Proposal 4: RAN2 deprioritize UE-side data transfer Solution 2 and Solution 3 via CP, as it’s not scalable and no feasibility consensus in RAN2.
Observation 2: Data collection is use case specific, standardized data collected by UE for NW-side model and UE-side model can be the same.
Reuse of NW-side data collection
Proposal 5: For standardized data, data collection reported by UE for NW-side data collection can be transferred to UE-side OTT server for UE-side model training. Non-OTA solution for NW-side dataset and model parameter transfer for two-sided model can be reused. 

TDoc file reading error

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

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

Conclusion
In this contribution, we provide our views on the UE side data collection, and the observation and proposals are summarized as follows:
For solution2 over UP:
Observation 1: SA2 lists UE side data collection over UP as one WT in Rel-20 study.
Proposal 1: Data visibility to gNB is not required, and fulfillment of visibility and controllability for data transfer over UP for Solution 2 could wait for the study by SA2 in Rel-20.
For solution3 over UP:
Observation 2: Data transfer over UP for Solution 3 also needs SA2 impact, e.g. authorization, session establishment.
Observation 3: Data transfer over UP for Solution 3 may need to design bran-new protocol stack for UP tunnel which has great RAN and SA impact.
Proposal 2: RAN2 to deprioritized or postpone the Data transfer over UP for Solution 3 to Rel-20 to align with SA2 timeline.
For solution2 over CP:
Observation 4: The 9000 bytes PDCP SDU size limit is also applicable for NAS message transmission in the air-interface.
Observation 5: RAN is hard to control the transmission priority for large scale of UE side AI training data transmission, if the solution2 over CP is adopted.
Proposal 3: The applicability of solution2 over CP to transfer large scale of UE side AI training data should be studied by SA2.
For solution3 over CP:
Observation 6: At least for BM use case, the AI training data is collected from the PHY layer periodically and is visible to RRC layer which can be transmitted on the air-interface in cleartext.
Observation 7: To use a “soft” split RRC segmentation method similar as logged MDT report, the AI training data transmission does not need to consider the scalability.
Proposal 4: To use a “soft” split RRC segmentation method similar as logged MDT report  for solution3 over CP to avoid the scalability problem.
Proposal 5: The low transmission priority for NW side data collection is also used for UE side data collection, if the solution3 over CP is adopted.

3GPP TSG-RAN WG2 Meeting #130	R2-2503692
Malta, May 19th – 23rd, 2025
Agenda Item:	8.1.4
Source:	InterDigital Inc.
Title:	Data Collection for UE sided Model Training
Document for:	Discussion
1. 

Conclusion
In this contribution, we discussed the open issues regarding data collection for UE sided model training and transfer of the collected data over the UP, and the following observations and proposals were made:

Observation 1: CP based solutions are not scalable for use cases that require collection of large data and may complicate deployments by requiring RAN updates even for use cases where RAN is not directly involved.

Proposal 1: The format of the data/measurement to be collected will be specified per use case basis. UE vendor-specific/proprietary data can be included in a transparent container along with the standardized data. 
Proposal 2: When the UE reaches its buffer limitation, it stops the logging of the measurements (as in the case of network side data collection).
Proposal 3: For data transfer solutions 2 and 3, CP based options will not be further considered. 
Proposal 4: For the transfer of collected data via user plane, the UE can be configured with a dedicated bearer. 
Proposal 5: RAN2 to discuss the following aspects in relation to the dedicated bearer for the transfer of collected data for UE side model training:
QoS requirements/profile of the bearer
if one bearer can be used for all data collection transfer or if there is a need for a dedicated bearer for each data collection configuration/use case
impacts on user plane procedures such as buffer status reporting and scheduling
Proposal 6: Aspects such as the end-to-end PDU session and (dedicated)bearer setup for the transfer of collected data over UP and the routing of the collected data from UE/gNB to the data collection server at CN/OAM should be discussed first in SA groups.
4. 

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

Agenda item:	8.1.4
Source:	Apple
Title:	Further discussion on UE-side data collection 
WID/SID:	NR_AIML_Air-Core– Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we further study UE-side data collection. Our observations are:
Observation 1: As option 1b was precluded in RANP#106, the data transfer to CN domain is mapped to option 2 and the data transfer to OAM domain is mapped to option 3. 
Observation 2: On UP traffic, existing NG-RAN only has the controllability and visibility on configuration of PDU session and QoS Flow. Whether NG-RAN can be aware of UE-side data transfer depends on SA2 design (e.g. whether to introduce AI/ML specific PDU session or AI/ML specific QoS flow). 
Observation 3: Supporting UL RRC message with larger than 16 segments put extra memory requirement for both UE and gNB. Thus, whether it works needs to be decided based on dataset payload size.     

Based on observations, our proposals can be found below:
Configuration of UE side data collection
Proposal 1: As the UE may send data collection request via UAI based on its implementation, no need to introduce a separate indication signaling when UE can’t perform data collection based on received configuration. 
Proposal 2: On data collection configuration without UE request, RAN2 leaves the detailed solution discussion to other WG. 
RAN aspects to enable the data transfer to CN domain or OAM domain
Proposal 3: Before SA2/SA5 provide feedback, RAN2 only discuss potential RAN impacts common to option 2 and option 3. 
Proposal 4: Before RANP provide guidance, RAN2 don’t compare between option 2 (i.e. transfer to CN domain) and option 3 (i.e. transfer to OAM domain) and discuss their down-selection. 
NG-RAN involvement in the data transfer
Proposal 5: RAN2 conclude that NG-RAN have the full control for dataset transfer over CP solution.
Proposal 6: RAN2 conclude that NG-RAN have full visibility for standardized dataset transfer over CP solution. 
Proposal 7: RAN2 wait SA2 feedback before discussion on level of NG-RAN involvement on dataset transfer over UP solution, including its controllability and visibility.  
RAN aspects related to data transfer over UP
Proposal 8: On data transfer solution over UP, RAN2 wait SA2 conclusion on whether/how NG-RAN can be aware of AI/ML dataset transfer (e.g. via AI/ML specific QoS flow, or AI/ML specific PDU session, or AI/ML specific protocol stack, etc.) to configure DRB accordingly.
Scalability aspects of CP
Proposal 9: On scalability of CP solution, RAN2 conclude that it may not work if data size is too large (e.g., 225MB in CSI compression). RAN2 send LS to request RAN1 to provide data size of other AI/ML use cases, including beam management, positioning and CSI prediction.

4 

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

Agenda Item	: 8.1.4 
Source	: LG Electronics Inc.
Title	: Discussion on UE-side data collection
Document for	: Discussion and Decision

Conclusion
Based on the above discussion, we made the following observations and proposals:
Configuration of UE side data collection 
Proposal 1. The RS configuration for UE-side data collection must be consistent across both CP and UP solutions.
Proposal 2. RS configuration framework for NW-side data collection can be reused for RS configuration framework for UE-side data collection.
Observation 1. For requesting the UE preferred RS configuration, a similar discussion is ongoing in the context of the applicability report.
Observation 2. In Option A, the UE informs the network of applicable configurations among already configured CSI report configurations. The same mechanism could serve as a simple approach to indicate a preferred RS configuration for the UE request.
Observation 3. For training data collection, collecting measurement results for both Set A and Set B is essential to gather input and ground-truth data. Option B could be a feasible candidate to support UE-initiated requests for preferred CSI-related configurations, including RS resources for data collection.
Proposal 3. For the UE request configuration, the RS configuration for the applicability report can be re-used.
Option A-like mechanism: The network provides a full RS configuration for data collection via CSI-ReportConfig. The UE indicates its preferred RS configuration(s) from among the already configured CSI report configurations.
Option B-like mechanism: The network provides data collection-related parameters via OtherConfig. The UE explicitly indicates a preferred RS configuration. Further RAN1 input is needed to support Option B.
Data transfer over UP 
Proposal 4. From the RAN2 perspective, UP solution can be classified into two : i) data transfer through UP tunnel via UPF (i.e., Option1a, Option1b, Option2), ii) data transfer through UP tunnel via OAM (i.e., Option3).
Discussion on the controllability aspects of CP&UP solutions
Proposal 5. MNO can have full controllability over the data collection procedure through both CP solution and UP solution.
Discussion on the visibility aspects of CP&UP solutions
Proposal 6. For both CP solution and UP solution, MNO can have full visibility over standardized data.
Proposal 7. For the discussion of transferring partial/non-standardized data of UE side data collection, RAN2 should first clarify which specific data needed as partial/non-standardized data.
Proposal 8. For Rel-19, RAN2 only focuses on standardized data, disregarding partial/non-standardized data.
Discussion on the scalability aspects of CP solution
Proposal 9. The UP solution addresses the signaling overhead and scalability issues associated with the CP solution, allowing for the transmission of large volumes of AIML data using legacy methods without any spec impact.

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

Agenda Item:	8.1.4
Source:	KT Corporation
Title:	Discussion on LCM for UE-sided model
WID/SID:	NR_AIML_air-Core (Release-19)
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following proposals for data collection configuration for UE-side model:
Proposal 1: AI/ML data collection configuration procedure and information should be optimized and refined for perfect interoperability, reliable AI/ML performance
Proposal 2: UECapabilityInformation can include additional information for appropriate data collection configuration at the network.
Proposal 3: Additional information for data collection configuration preference can be requested by UE.
Proposal 4: Data collection feasibility indication and inability cause should be reported to network.

3GPP RAN WG2 Meeting #130	R2-2503777
St.Julians, Malta,  May 19th – 23rd, 2025    
                                 
	
Agenda Item:	8.1.4
Source:	Mediatek Inc.,Nokia,Qualcomm Incorporated,Xiaomi,InterDigital Inc.
Title:	Discussion on the Necessity of Non-Standardized Data
Document for:	Discussion, Decision

Conclusion
Standardized vs. Non-Standardized Data Trade-offs
Observation 1: Full visibility of standardized data content means that all attributes, including the information conveyed, the values held, the data types used, and the data formats structured, are specified. Conversely, no standardized visibility indicates that none of these attributes are defined. Partial visibility for partially standardized data content means only certain attributes are specified.
Proposal 1: Support non-standardized and partially standardized data contents in Solution 2 and/or Solution 3. The choice of solution will depend on the outcome of the data transfer study.
Addressing Privacy and MNO Concerns
Proposal 2: Adopt the following principles to mitigate privacy risks and other principles are not excluded:
User consent enforcement: Reuse the existing 3GPP User consent mechanism for UE sided data collection.
Data scope limitation: Restrict collection to non user identifiable information, such as radio/sensor-generated metrics.
MNO governance: Allow operators to enable/disable non-standardized data collection.

TDoc file reading error

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

Conclusions
In this contribution, we continued to present our observations and views on data collection for UE-side model training. Based on the discussions in the previous sections, our proposals are as follows.  
Observation 1: Current 3GPP architecture does not support AI/ML data collection for UE-side model training in the UP. Resolving these issues involves SA investigations and revisions to the current standards.

Proposal 1: The first termination entity refers to the first network element/function that receives and stores data transmitted from the UE. 
A first termination entity possesses the authority to oversee the subsequent handling of this data, such as data cleaning, forwarding, sharing, and analysis, among others, in compliance with privacy policies, security protocols, and any regulatory compliance requirements. I
A first termination entity may not be the place where UE-side model is trained, in which case the entity is a final termination entity.
Proposal 2: The (final) termination entity refers to the place where the UE-side model training is done. 
Depending on the data collection procedure, a final termination can also be the first termination entity and vice versa.
Proposal 3: RAN2 request SA to study the mechanism for the CN/OAM to interact with the server for data collection for UE-side model training in order to understand the request for data collection and transfer.
Proposal 4: It is not necessary to introduce a new protocol layer for collected data transfer.
Proposal 5: Support periodic, event-triggered, and on-demand data logging for data collection for UE-side model training.
Proposal 6: Support periodic, immediate, event-triggered, and on-demand data transfer/reporting for data collection for UE-side model training.
Proposal 7: Priority is given to Option 2 over Option 3 if only one of these two options can be standardized.
Proposal 8: RAN2 to request SA to study the interaction between CN/OAM and the server for data collection for UE-side model training to support the configuration for data collection and transfer.
Proposal 9: When collecting data for UE-side model training, data needs to be pre-processed to remove sensitive and privacy information associated with the UE.
References Intelligence
RP-234039, New WID on Artificial (AI)/Machine Learning (ML) for NR Air Interface, RAN meeting #102, Qualcomm (moderator)
RP-233946, 3GPP TR 38.843, Technical Specification Group Radio Access Network; Study on Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface (Release 18) v2.0.1 (2023-12)
Chair’s notes, R2_125bis_ChairNotes_24-04-19_final, RAN2 meeting #125bis, Changsha, April 2024
Chair’s notes, R2_126_ChairNotes_24-05-24_final, RAN2 meeting #126, Fukuoka, May 2024
Chair’s notes, R2_127_ChairNotes_24-08-23_17-00_eom, RAN2 meeting #127, Maastricht, Aug 2024
Chair’s notes, R2_128_ChairNotes_24-11-22_17-00_eom, RAN2 meeting #128, Orlando, Nov 2024
R2-2407807, RAN2 inputs to TR38.843, Maastricht, Aug 2024
Chair’s notes, R2_129_ChairNotes_25-02-21_final.docx, RAN2 meeting #129, Athens, Feb 2025
Chair’s notes, R2_129b_ChairNotes_25-04-11_16-45 final, RAN2 meeting #129bis, Wuhan, Apr 2025

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

Title: 	Discussion on UE-sided data collection for training
Source: 	Huawei, HiSilicon, OPPO, ZTE, NTT DoCoMo, China Unicom, CMCC, China Telecom, Apple, vivo
Agenda item:	8.1.4
Document for:	Discussion/Decision

Conclusion
Based on our analysis in section 2, we have the following observation and proposal:
Observation 1: For non-standardized data, there are the following issues:
1) they are unacceptable from MNO point of view, as they are untrustworthy and they may lead to user privacy leakage
2) it is quite challenging for MNO to verify/match non-standardized data
3) it is quite challenging for MNO to have full control over non-standardized data

Proposal 1: For option 2 and option 3, RAN2 to only adopt standardized data to implement full visibility, and exclude non-standardized data, i.e. partial/no visibility.

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

Source:	Qualcomm Incorporated 
Title:	On UE Side Data Collection 
Agenda Item:	8.1.4 UE side data collection 
Document for:	Discussion and Decision
Introduction & 

Conclusion
UE-side data collection for RAN-centric use cases

Observation 1:  Based on a way forward for UE-side data collection endorsed in RP-243307 [1], RAN2 should further study 
How UP-based solution 2 and UP-based solution 3 would work (e.g., with or without NG-RAN involvement), 
Issues associated with transferring collected data using the user plane and control plane in Solution 2 and Solution 3.

Observation 2: RAN2 is not expected to prioritize or deprioritize a solution in its further study. 

Proposal 1: Following the legacy procedures, the NG-RAN is responsible for admission control of the PDU based on information/parameters provided by the 5GC.

Proposal 2: The below is under SA2 study. No further study is needed in RAN2 on NG-RAN involvement for data transfer.  
Can the data collection report share the PDU session with other traffic?
What information/parameters are used by the NG-RAN for the admission control of PDUs corresponding to the UE-side data collection report?

Proposal 3: For user plane-based data transfer, the NG-RAN may perform PDU admission control based on information/parameters configured by 5GC to the NG-RAN to achieve controllability requirements for data transfer, as in legacy PDU admission control. 

Proposal 4: The legacy RRC and NAS-based procedure can be reused by NG-RAN to achieve controllability requirements for data transfer in the control-plane-based data transfer. 

Proposal 5: The first terminating entity (5GC in solution 2 and OAM in solution 3) can achieve visibility requirements (in the user plane-based data transfer) before the training data is transferred/delivered to the server for the UE side training data collection / OTT server. NG-RAN involvement for visibility is not required. 

Proposal 6: SA WGs (e.g., SA2, SA5) can discuss the required procedures for user-plane solutions in the CN domain and OAM domain may, for example,
Procedure to enable the UE to establish a PDU session with the network entity in the CN or OAM domain, and 
Configuring or providing information/parameters for PDU admission control to NG-RAN. 

Proposal 7: At least the following enhcancements are required to enable control plane-based data transfer. 
UE memory requirements, 
Segmentation for UE side data collection, 
Continuity of the training data reporting, and 
Risk of leakage of proprietary information to other vendors.

Observation 3: Throughout Rel-18 [4][5] and Rel-19 [6], the 3GPP has introduced new use cases for study. 

Observation 4: One of the requirements for the UE side data collection is 
The design is future-proof and extendable. 

Proposal 8: With more AI/ML-enabled use cases anticipated to be introduced in the future, the control plane-based data collection will not remain future-proof or extendable.  



Data Collection for UE-side Model for Positioning Enhancements

Observation 5: For UE-side data collection in Positioning Enhancements Case 1, existing LCS and UE positioning procedures (e.g., (deferred) MT-LR, MO-LR) can be used to obtain the desired training data by a "server for data collection" from a UE. 

Observation 6: The "training data" can be sent from a UE to the "server for data collection" when a secure user plane connection is established directly from the UE to the "server for data collection" (LCS Client). Corresponding procedures are already specified in TS 23.273, clause 6.16.
Proposal 9: For UE-side data collection in Positioning Enhancements Case 1, the actual data/information requested and provided can be carried in existing LPP and LCS Supplementary Services messages as (at least partly) vendor-specific private OCTET STRINGs by using an LPP EPDU-Sequence.

Observation 7: In order to perform the data collection at the UE/PRU, the UE/PRU would need assistance data from the network (LMF), which, however, are mostly existing assistance data elements (e.g., (on-demand) DL-PRS assistance data, position calculation assistance data, etc.). Any additional assistance data depends on RAN1 conclusions.

Observation 8: To enable data collection for UE-side positioning model training at a "server for data collection" the RAN2 specification impacts seem rather small and are mainly the same as required for the LCM/inference/positioning operation.

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

Agenda item:	8.1.4
Source:	CMCC, China Telecom
Title:	Discussion on UE side data collection
WID/SID:	NR_AIML_air-Core
Document for:	Discussion

Conclusion
Here are the observations and proposals for UE side data collection.
Observations
Observation 1: NG-RAN is involved to provide the data collection configuration for UE-sided model training.
Observation 2: Solution 3 with UP-based is not feasible for now since RAN2 doesn’t confirm SA5’s assumption.
Observation 3: The typical data size for model training per data sample would be about 10s of bits to a few 1000bits even ~150Kbits for CSI compression, beam management and positioning.
Observation 4: The typical data size for model training per data sample would be up to around 1.5Mbits (maybe ~hundreds of Kbits) for CSI prediction.
Observation 5: The existing framework (max payload size <9kbyte for RRC signaling) can support the data size requirements per data sample for model training for CSI compression, BM and positioning. 
Observation 6: If the number of RRC segmentation is extended, the data size requirements on CSI prediction or multiple samples for each use case will be satisfied, and the extended RRC signaling can also be used for dataset or model parameters sharing.
Observation 7: For NW side data collection, the same principles as logged MDT are reused, i.e. an available indication is included to indicate there are logged measurements available and multiple RRC message may be needed to report the collected data.
Proposals
Proposal 1: Solution 3 with CP-based is preferred since OAM can initiate the data collection procedure and send the configuration to RAN.
Proposal 2: RAN2 to discuss the following solutions to support the data collection for model training, dataset and model parameters sharing:
- Option 1: Extend the number of RRC segmentation, which also can be used for model parameters and dataset sharing
- Option 2: Reuse the mechanism of logged MDT, i.e. an available indication is included to indicate there are data available and multiple RRC message may be needed to transfer the data

4	

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

Agenda Item:	8.1.4
Source:	Ericsson
Title:	Remaining issues on UE-side data collection
Document for:	Discussion, Decision
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1	The NG-RAN involvement related to the configuration (via RRC signalling) of the radio resources in which the UE is allowed to perform the UE side data collection is common to all solutions, irrespective of whether the data transfer occurs via UP or CP.
Proposal 2	The NG-RAN involvement in the configuration of the radio measurements to be collected depends on whether the collected data is transmitted via NG-RAN transparently or not, i.e. no NG-RAN involvement is expected for UP-based solutions and option 2 with CP, whereas NG-RAN involvement is expected for option 3 with CP.
Proposal 3	For UP-based solutions, the NG-RAN involvement in the data transfer is expected in the setting of PDU sessions and transport channels, as for any other UP service injected into the 3GPP network from the UE. No NG-RAN specification impact is expected.
Proposal 4	For CP-based solutions (both NAS-/RRC-based), the NG-RAN involvement in the data transfer is expected both in the implementation and in RAN2 specifications, in order to design procedures for fetching the data from the UE (e.g. based on RRC segmentation or request/response procedures) and transmit them to the CN/OAM.
Proposal 5	CP based solutions require a heavier update of the NG-RAN both for the configuration of the data to be collected and for the fetching (via CP) of the collected data. Without a capillary update of the NG-RAN nodes, the ability of the UE to perform an efficient UE-side data collection will be limited, as well as the possibility for the network to balance the radio overhead. NG-RAN nodes compliance with beyond Rel.19 AIML use cases need also to be considered.
Proposal 6	Since the data to be collected/exposed by the UE do not need to be specified/implemented in NG-RAN, and the transfer of collected data can be handled by NG-RAN node as other UP services, no scalability problem are expected for UP-based solutions.
 

3GPP TSG-RAN WG2 Meeting #130	R2-2504628
St Julian’s, Malta, 19 – 23 May 2025	revision of R2-2502961
Agenda item:	8.1.4
Source:	Samsung
Title:	UE side data collection
Document for:	Discussion & Decision

Conclusion
RAN2 is kindly asked to discuss and agree the following proposals:

Proposal 1. RAN2 to focus on Opt A (Full visibility for standardized data contents).

Proposal 2. RAN2 to focus on studying Option 3 for data transfer.

Proposal 3. RAN2 to agree that gNB should be provided/triggered by CN (in Option 2) and by OAM (in Option3) if gNB is to provide data collection configuration without UE request.

Proposal 4. If Proposal 3 is agreeable, RAN2 to send an LS to SA2/SA5 asking them to take into account the need for data collection configuration support.

3GPP TSG RAN WG2 Meeting #130   
St Julian's, Malta, 19 - 23 May, 2025
	                	                                                                                                R2-2504663
Agenda Item:	8.1.4
Source:	Rakuten Mobile
Title:	Discussion on UE Side Data collection
Document for:	Discussion and Decision

Conclusion 
This contribution discusses the issues in terms of UE Side Data collection for AIML training  RAN2 is kindly asked to take into account the proposals below:

Observation 1: it is still FFS in RAN2 whether the UE should report explicit causes for inapplicability also UE activation is not related to network receipt of UAI.
Proposal 1:
Add optional inappCause ENUM { modelNotFound, envMismatch, resourceConflict, UEpolicy } in applicability report.
Introduce T_wait-UAI (FFS, e.g., 20 ms). UE activates inference only after:
Receiving ACK for UAI; or
T_wait-UAI expires.

Observation 2: The UE cannot indicate a preferred configuration index, intent or collection window when sending a data-collection start/stop request.
Proposal 2:
Extend AIDataCollectionRequest to include
preferredConfigIndex (INTEGER 0..15)
collectionIntent (ENUM {training, monitoring})
startStopFlag (BOOLEAN) OPTIONAL
preferredWindow { startOffset, duration } OPTIONAL

Observation 3: No standard low-power trigger or clearance mechanism exists. 
Proposal 3:
RAN2 introduce optional lowPowerThreshold (percentage) in TrainingDataCollectionConfiguration after confirmation with RAN1.
The UE shall raise lowPower = TRUE when SOC ≤ threshold and clear it only after SOC ≥ threshold + 5 pp.

Observation 4: Applicability is not re-established after mobility events.
Proposal 4:UE includes per-logConfigID applicability in UAI after Resume/Re-establishment,
When sending UAI after RRC ResumeComplete or RRC Re-establishmentComplete, the UE shall include one ApplicabilityReportConfig per active logConfigID.

Observation 5: Log-retention expiry is independent of delivery success.
Proposal 5:
Add field logDeliveryStatus (ENUM {success, failed, notAttempted}) to UEInformationResponse.
Logged data will be kept until both retentionTimer has expired and/or logDeliveryStatus = success.

Observation 6: Following RLF or power-cycle the gNB is unaware of any retained data unless it re-configures the UE.
Proposal 6:
Introduce UL RRC message AIDataCollectionStatusReport carrying logConfigID, bufferSizeBytes, lastSampleTime, optional inappCause.
The UE may transmit this message autonomously immediately after RRC ResumeComplete or HO Complete when no context for the active log exists in the serving gNB.

Observation 7: LoggedMeasurementReport provides no mechanism to indicate discontinuity in the measurement sequence.
Proposal 7:
Add optional fields gapMarkerPresent (BOOLEAN) and maxGapDuration (INTEGER in ms) to aiLogMeasEntry
When the UE resumes logging after any pause ≥ maxGapDuration, it sets gapMarkerPresent = TRUE in the first sample after the gap.

Observation 8: Current framing conveys one measurement per PDCP SDU, producing excessive header overhead; no aggregation container is defined for AI/ML logs.

Proposal 8:
RAN2 to introduce AI-Log Aggregation Container (ALAC) in TS 38.323.

Header elements: sampleCount (4 bits, value 1-16) and deltaEncoding (1 bit). 
UEs advertise capability pdcp-AIlog-aggregation; NG-RAN enables the mode via ALAC-Allowed in DRB-Config. Aggregation is transparent to RLC/MAC.


Observation 9: Logging periodicity is implicitly locked to RS transmission periodicity, there is no parameter exists to change that.
Proposal 9:
Add in  TrainingDataCollectionConfiguration loggingInterval element.
Value 1 → UE logs every RS occasion (legacy behaviour).
Value N → UE logs every N-th RS occasion,


Observation 10: UAI reporting behavior doesn’t have semantic clarity, making it difficult for NG-RAN to distinguish between cases when buffer is exhausted or configured buffer thresholds, and power-based issues. Standardized cause coding ensures interoperable handling and supports policy based scheduling of AIML data.
Proposal 10:
UAI triggering based on buffer thresholds and cause reporting
Extend TrainingDataCollectionConfiguration with the following optional parameters:
bufferThresholdBytes INTEGER OPTIONAL
— Defines the logging buffer level (in bytes) at which the UE shall consider availability reporting.
availabilityCauseCoding ENUM { fullBuffer, thresholdReached, lowPower } OPTIONAL
— Indicates the condition under which the UE triggered availabilityIndication = TRUE.
Capture behaviour in Specifications:
The UE shall trigger UEAssistanceInformation with availabilityIndication = TRUE when any of the following apply:
The configured bufferThresholdBytes is reached or exceeded;
The logging buffer is full (if no threshold is configured);
The UE enters a defined low-power state.
The availabilityCauseCoding field in the report shall reflect the reason for triggering the indication. This enables the network to differentiate between resource-based and energy-based constraints and respond appropriately.

Observation 11 There is signalling element for MNO to mandate “standard-only” versus “mixed/opaque” dataset content.
Proposal 11 
Introduce visibilityLevel (2 bits) in DRB-Config:
00 standard-only; 01 mixed; 10 opaque-permitted; 11 reserved.
UE behaviour shall comply with the configured level; NG-RAN may reject establishment if the requested level conflicts with local policy.

Observation 12 There is no AI/ML-specific admission criteria for PDU-admission procedure; training bursts may be admitted regardless of cell load which is unacceptable for operators.
Proposal 12
When AIML-TrafficPurpose = training, the gNB shall apply PDU-admission parameters conveyed by 5GC (AIML-AdmissionPolicy). 
If cell capacity for AI traffic is exceeded, the gNB rejects the DRB with cause cellCapacityAIexceeded (new cause value, TS 38.331).

Observation 13 Control-plane carrying of large AI/ML datasets risks saturating SRB1/2; Rel-19 scope for CP payload still not defined.
Proposal 13 
Add normative Note in 38.331 that 
“UE-side data-collection payload exceeding 2048 octets shall be transferred by user-plane options (1a / 2 / 3). Control-plane carriage is restricted to supervision or status messages only; no new SRB type for bulk AI/ML data is introduced in Rel-19.”

Observation 14 NG-RAN has no explicit mechanism to request that the UE suspend or throttle an ongoing training upload during transient congestion.
Proposal 14 
Define AIUploadThrottlingIndicator (MAC CE or RRC IE, FFS) with values {pauseImmediately, reduceRate, resume}. NG-RAN may signal this indicator to UEs that have an active AIML-TrafficPurpose = training DRB. 
Proposal 14-b UEs need to comply within one HARQ RTT for MAC-level signalling or one RRC RTT for RRC-level signalling.


Observation 15 HO Preparation signalling contains no indication that UE-side logging is active.
Proposal 15
Introduce BOOLEAN field AIML-LoggingContextActive in HandoverPreparationInformation (TS 38.331).
If TRUE, the target gNB shall expect that UE-side data logging is ongoing.

Observation 16 The target gNB cannot obtain the current logging configuration, applicability status, or buffer state following handover.
Proposal 16 
Define DL RRC message AIMLDataCollectionStatusRequest and UL AIMLDataCollectionStatus.
The UE shall respond with:
logConfigID
applicability (BOOLEAN)
bufferSizeBytes
lastSampleTime
inappCause (if applicable)
This procedure is initiated by the target gNB after HO execution and may be used upon RRC ResumeComplete as well.

Observation 17 No per-session identifier exists for distinguishing which of several logConfigIDs is active or applicable after mobility.
Proposal 17 
In UAI triggered after HO or Resume, the UE shall include logConfigID and applicability, for clarity during multiple sessions.