3GPP TSG RAN WG2 Meeting #130	R2-2503380
St. Julian’s, Malta 19-23 May 2025	(resubmission of R2-2502443)  

Agenda Item:	8.1.2.3 LCM for Positioning use case
Source:	Fraunhofer IIS, Fraunhofer HHI
Title:	Association of measurements and ground truth labels for positioning use-cases
Document for:	Discussion & Decision

Conclusions
In this contribution, we have made the following observations:
Observation 1: Legacy 3GPP positioning methods provide inaccurate labels in training data, particularly in the NLOS-heavy and multipath-dominated scenarios where AI/ML is expected to outperform traditional methods. 

Observation 2: Use of PRU type UEs limit the data collected to static UEs and spatially limited to where the PRUs are provisioned. 

Observation 3: In indoor scenarios, landmarks can be the only mechanism to obtain labeled data, enabling the Network/UE to identify and trigger the need for labels in specific areas.

Observation 4: UEs may be equipped with additional sensors (such as camera and radars) and may have applications that are able to detect and provide or enhance ground truth labels. 

Observation 5: Training data and labels are generated by different entities for Case 3b, thereby requiring alignment between training data and the label.

Observation 6: The LMF may need to time-synchronize the input and ground truth label for training and monitoring purposes.

Proposal 1: UE location for the purpose of ground truth shall be determined using secondary sources (e.g. camera-based), which different from GNSS or RAT dependent methods for UEs that are not provisioned as PRUs (“non-PRU UEs”). 

Proposal 2: RAN2 shall discuss association between channel measurement and ground truth for each of the positioning use case, including indication of the method used to obtain the ground truth label. 

Proposal 3: RAN2 shall discuss what additional information from the UE can be provided to the LMF or OTT server which trains the UE-sided model to ascertain the ground truth. The following information could be transferred from the UE to obtain ground truth labels:  
Information obtained from on-board sensors, such as camera and radars 
Information obtained from processing tags, such as QR codes, NFC tags
Information obtained from other positioning systems deployed in parallel to 3GPP system. 

Proposal 4: Based on UE capabilities, the network may provide assistance data to the UE to help determine GTL using alternative means or the network may provide ground truth labels to the UE if it has accurate GTL available at NW side. 

Proposal 5: If the UE needs assistance from NW to perform monitoring, then the UE shall send a request to NW, indicating the type of assistance data needed.

Proposal 6: UE shall report its capability to provide ground truth labels or its ability to provide additional information to improve the ground truth labels to the NW for LCM of NW-based AI/ML models. 

Proposal 7:  The UE shall provide ground truth labels or additional information to improve the ground truth labels, when configured by the network. 

Observation 7: The LMF may need to time-synchronize the input and ground truth label for training and monitoring purposes.

Proposal 8: The UE shall provide a timestamp synchronized with the network time to ensure proper alignment between ground truth labels and network measurements.

Proposal 9: The UE shall, subject to its capabilities and privacy, be configured to report its ground truth (i.e., UE position at one or more point in time), together with uncertainties to the LMF for assisting training for Case 3a. 

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

Agenda Item:	8.1.2.3
Source:	NEC
Title:	LCM for Positioning use case 
Document for:	Discussion, Decision

Conclusion
For channel measurement type (A) (i.e., path-based measurement), it is not necessary to introduce enhancements on the number of reported paths in Rel-19.

Agreement
For model performance monitoring of AI/ML positioning Case 1, “FFS: content of monitoring outcome” in RAN1#119 agreement is resolved by:
the content of monitoring outcome includes at least an indication that the target UE cannot perform the Case 1 positioning method.

Agreement
For training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes timing information, support the following for providing label and quality indicator of label, 
The corresponding label is provided by LMF to gNB in the format of timing information. “Timing Measurement Quality” in 38.455 can serve as quality indicator of the label.
Note: It is assumed that user data privacy of non-PRU UE is preserved.

TDoc file reading error

3GPP TSG-RAN WG2 Meeting#130	R2-2503400
St Julian’s, Malta, 19th – 23rd, May 2025
                         
Source:	vivo
Title:	Discussion on open issues of AI/ML enhanced positioning Case 1
Agenda Item:	8.1.2.3
Document for:	Discussion and Decision

Conclusion
In summary, we make the following proposals on functionality-based LCM for AI/ML enhanced positioning:
Issue LPP-13
For error causes provided by the location server to the UE via LPP Provide Assistance Data, no need to introduce any new casue value in addition to the legacy reasons that the current running CR captures.
Issue LPP-14
For error causes provided by the UE to the location server via LPP Provide Location Information, introduce a new cause value as “AI/ML positioning method becomes nonapplicable”.
Issue LPP-15
Positioning integrity evaluation is not applicable for AI/ML-based positioning at least for R19. If not, send LS to RAN1 ask whether there are other error sources specific for AI/ML-based positioning methods.
Issue LPP-16
RAN2 to confirm that it is UE that performs monitoring metric calculation.
To enable performance monitoring metric calculation at target UE, LMF may provide some assistance information to UE, e.g., ground truth label of target UE, position calculation assistance data, PRU measurement, or PRU location.
To enable performance monitoring at target UE, the target UE obtains assistance data, and PRU measurement/location from LMF via LPP Request/Provide Assistance Data.
To enable performance monitoring at target UE, the target UE obtains its current location with legacy positioning methods from LMF via MO-LR procedure.
RAN2 to confirm that, if the AI positioning performance does not satisfy the positioning KPI, UE would report an error cause about not being capable of AI positioning via LPP Provide Location Information.
If P7 is agreed, RAN2 to discuss the error cause related to performance monitoring, i.e., whether introducing a dedicated cause value (e.g., ‘performance requirement not satisfied’) or reusing the error cause introduced for non-applicable indication.

3GPP TSG-RAN WG2 Meeting#130	R2-2503403
St. Julian’s, Malta, 19th – 23rd May, 2025
                         
Source:	vivo, Qualcomm Incorporated, ZTE Corporation, Sanechips, Lenovo, Ericsson, CATT, OPPO, Fraunhofer IIS, Fraunhofer HHI, CEWiT 
Title:	Discussion on consistency between training and inference for AI POS
Agenda Item:	8.2.2
Document for:	Discussion and Decision

Conclusion
On a basis of the above analysis, we make the following proposals regarding how to ensure the consistency of AI enhanced positioning between training and inference:
RAN1 ensures consistency between training and inference of a specific TRP based on assistance data from LMF to UE in the two phases.
TR 38.843 captures that involved TRPs have a strong impact on AI positioning accuracy, i.e., the change of TRP location/identification between training and inference would cause the performance degradation of AI model.
RAN2 to discuss how to ensure the consistency of involved TRPs between training and inference, as it strongly impacts the performance of AI positioning accuracy.
To ensure the consistency between training and inference, the UE should be able to explicitly request assistance data associated with a specific group of TRPs, e.g., include a list of NCGI in on-demand PRS request.

3GPP TSG RAN WG2 #130	R2-2503450
St. Julians, Malta, May 19th–23rd, 2025
 		 		
Agenda Item:	8.1.2.3
Source: 	Xiaomi 
Title:  	Discussion on AI positioning case 1
Document for:	Discussion and Decision

Conclusions 
In this contribution, we discussed LCM for AI positioning case 1 and provide the following observations and proposals:
Error Cause
Proposal 1: (LPP-13) NR-DL-AI-ML-LocationServerErrorCauses uses error causes of NR-DL-TDOA-LocationServerErrorCauses as baseline. No new location server error cause is introduced for AI/ML positioning case 1.
Proposal 2: (LPP-14) Introduce ‘DL AIML positioning not applicable’ as new target device error cause for AI/ML positioning case 1.
Proposal 3: (LPP-16) ProvideAssistanceData is used to provide assistance data for UE to calculate performance monitoring metrics.
Performance Monitoring 
Proposal 4: (LPP-16) Monitoring outcome ‘target UE cannot perform case 1 positioning method’ is implicitly reported via UE reporting its target device error cause ‘DL AIML positioning not applicable’.
Proposal 5: (LPP-17) For AI/ML positioning case 1, UE can use its own GNSS location as ground truth label. Requesting its own location information from LMF as label data is not mandatory.
Proposal 6: (LPP-17) Existing NAS signalling (i.e., MO-LR Request/Response message in UL/DL NAS TRANSPORT) is reused to request/provide ground truth label to the target UE, i.e., no further enhancement is needed from RAN2 point of view.

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

Source:	Continental Automotive
Title:                       Discussion on Applicability Reporting
Agenda Item:         8.1.2.3
Document for:	Discussion and Decision

Conclusions
In this document, we propose a hierarchical bitmap representation for applicability reporting and the use of a lightweight ML model for pre-empting model applicability. This method ensures efficient communication between the UE and the network regarding model inapplicability causes and pre-emptive inference. Additionally, we request RAN2 to discuss the following proposals:

Proposal 1: The network may configure a hierarchical bitmap representation for the UE to indicate model inapplicability causes. This bitmap will include:

Scope: 1-bit (temporary or permanent inapplicability)
Entity Side: 2-bits (UE-side, NW-side, metadata/config issue, reserved)
Detailed Cause: 4-bits (low battery, buffer status full, compute core unavailable, etc.)

Proposal 2: The UE should signal the bitmap using L1/L2/L3 whenever it determines the model is inapplicable. Upon receiving the indication, the network will disable or reconfigure the UE side model parameters.

Proposal 3: A lightweight ML model standardized on the UE should be used to pre-empt the applicability of a model before it is configured by the network. This model should consider the UE context, network state, and model metadata. The UE may report the inference proactively or reactively and signal the pre-empted inference to the network via L1/L2/L3 signalling.

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

Agenda Item:	8.1.2.3
Source: 	Fujitsu
Title: 	Discussion on LCM for Positioning Use Case
WID/SID:	NR_AIML_air
Document for:	Discussion and Decision

Conclusion
Proposal 1 NW may signal the inference configuration in step 5 or step 3. 
Proposal 2 For detailed design of functionality management, RAN2 wait for RAN1 progress on UE/LMF monitoring options of positioning case 1.
Proposal 3 For positioning case 1, even if UE can calculate the monitoring metrics and make preliminary decisions of the monitoring results, final confirmation from LMF is preferred.
Proposal 4 Both gNB and LMF can make monitoring decision for case 3a. The details depend on further RAN1 progress.
Proposal 5 LMF can make monitoring decision for case 3b. RAN2 wait for further RAN1 progress on potential assistance information/data for metrics deriving and decision making of case 3b.

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

Source:	CATT
Title:	Issues to address for AI/ML Positioning stage-2
Agenda Item:	8.1.2.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on the open issues for AI/ML positioning Case 1, and the corresponding observations are as below:
Observation 1: only the spec impact for AI/ML positioning Case 1 has been captured in 38.305 running CR.
Observation 2: Except for info #7 TRP locations, all other information captured in table 8.12.2.1.0-1 for DL-TDOA has been agreed by RAN1 as assistance data provided from LMF to UE for AI/ML positioning Case 1.
And we propose:
Proposal 1: the following agreements made for BM applicability reporting is also applicable to positioning case 1:
UE decides the applicable functionalities based on NW-side additional conditions (if provided), UE-side additional conditions (internally known by UE) and model availability in device.
Support the explicit reporting of applicability/inapplicability in initial report and subsequent reporting it reports only applicability it changed.
Proposal 2: Considering RAN1 agreed “For AI/ML based positioning Case 1, all assistance information from legacy UE-based DL-TDOA, other than info #7, can be provided from LMF to UE”, the existing assistance Data Transfer Procedure for DL-TDOA between LMF and UE should be reused for AI/ML positioning Case 1.
Proposal 3: regarding Information that may be transferred from the UE to LMF, at least UE location and time stamp are included as below:
Proposal 4: (LPP-15) positioning Integrity is supported for AI/ML positioning Case 1.
Proposal 5: send a LS to RAN3 to trigger the discussion on “Information that may be transferred from the gNB to LMF” and “Procedures between LMF and gNB” for AI/ML positioning Case 1.

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

Agenda item:	8.1.2.3
Source:	China Telecom
Title:	Discussion on performance monitoring for positioning case 1
Document for:	Discussion

Conclusions
Based on the discussion above, we have the following proposals.
Proposal 1: For case 1, UE can be configured with trigger condition or requested by LMF to report monitoring result.
Proposal 2: Target UE is configured with the required prediction accuracy for case 1 by LMF, to determine whether target UE can perform the Case 1 positioning method or not.
Proposal 3: For case 1, for Option B (i.e. the LMF performs monitoring metric calculation), UE need to be notified if LMF determine that the monitoring performance metric does not meet the requirement.

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

Agenda item:	8.1.2.3
Source:	Apple
Title:	Remaining issues on LCM procedure of AI/ML based positioning
WID/SID:	NR_AIML_Air-Core– Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss remaining issues on LCM procedure of AI/ML based positioning. Our observations are:
Observation 1: On-demand request for DL-PRS assistance data is already supported from Rel-17. 
Observation 2: RAN1 agreed all assistance data of legacy UE-based DL-TDOA (other than info 7) are reused.
Observation 3: In AI/ML based beam management, the applicability reporting already takes UE-side additional condition into consideration, and UE-side additional condition is not explicitly reported to the NW because it includes UE’s internal information (e.g. battery and memory), which can’t be exposed to the NW. 

Based on observations, our proposals can be found below:
Proposal 1: Support the legacy on-demand request for DL-PRS assistance data. Whether to allow the UE to on-demand request for TRP-specific assistance data depends on RAN1. 
Proposal 2: Same as AI/ML based BM, the UE decides the applicable functionalities based on NW-side additional conditions, UE-side additional conditions and model availability in device. UE-side additional condition is not explicitly reported to the NW.
Proposal 3: Following existing principle on sequence order of LPP procedures, no need to specify fixed step order between inference configuration and applicable functionality reporting. 
Proposal 4: NR-SelectedDL-PRS-IndexList is applicable to AI/ML positioning Case 1.
Proposal 5: As “batch reporting” was introduced in RAN1 in Rel-17, it is up to RAN1 to decide whether it is applicable to AI/ML positioning Case 1.
Proposal 6: For NR-DL-AI-ML-LocationServerErrorCauses, no need to introduce other error cause beyond the existing list in running CR.
Proposal 7: For NR-DL-AI-ML-TargetDeviceErrorCauses, introduce the following new error causes:
A new cause “AIML method NonApplicable”.
Split “thereWereNotEnoughSignalsReceived” into “Not Enough Training Signals Received”, “Not Enough Inference Signals Received” and “Not Enough Monitoring Signals Received”.
A new cause “Performance monitoring Assistance Data Missing”.
Proposal 8: Positioning integrity is applicable to AI/ML positioning Case 1.
Proposal 9a: On signaling of monitoring outcome, RAN2 discuss whether to introduce a new LPP message or reuse existing LPP message (e.g. LPP ProvideLocationInformation) after RAN1 down select sub-option of Option A.
Proposal 9b: On signaling of monitoring outcome, reuse LPP ProvideAssistanceData to provide performance monitoring configuration from LMF to the target UE.
Proposal 10: LPP ProvideAssistanceData is reused to send the "ground-truth label" information from LMF to the target UE.

4 

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

Title		Discussion on error causes for AI/ML positioning
Source	LG Electronics
Document for	Discussion and Decision
Agenda Item	8.1.2.3 LCM for Positioning use case
WID/SID	NR_AIML_air-Core
1		

Conclusion
The following observations are based on the current specification.

Observation 1.	Legacy (non-AI/ML) positioning error causes can provide useful guidance regarding appropriate next actions. 

Based on previous meeting agreements, we observe the following.

Observation 2.	AI/ML positioning error causes should enable fallback to a legacy (non-AI/ML) positioning method when AI/ML positioning is not applicable. 

We propose adding two error causes to existing NR-DL-TDOA-TargetDeviceErrorCauses-r16 structures.

Proposal 1.	Use of abstracted error cause “AI/ML functionality not applicable” for UE-side limitations in AI/ML positioning.

Proposal 2.	Use of dedicated error cause “Assistance data incompatible with model” for externally resolvable issues, i.e., incorrect or mismatched assistance data.

Proposal 3.	Do not introduce a new error cause for conditions already covered by existing DL-TDOA error causes since current AI/ML positioning (Case 1) operates based on DL-TDOA measurements.

Proposal 4.	Add “AI/ML functionality not applicable (aimlFunctionalityNotApplicable)” and “Assistance data incompatible with model (assistanceDataIncompatibleWithModel)” to existing NR-DL-TDOA-TargetDeviceErrorCauses-r16 structure.

We do not propose adding any error causes to NR-DL-AI-ML-LocationServerErrorCauses.

Proposal 5.	Reuse the existing NR-DL-TDOA-LocationServerErrorCauses structure for AI/ML positioning Case 1, and do not introduce additional error causes in NR-DL-AI-ML-LocationServerErrorCauses.
4		

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

Source				: CEWiT
Agenda item		: 8.1.2.3
Title	: Discussion on Functionality-based LCM for Positioning Use Case
Document for		: Discussion and Decision

Conclusion
This contribution provides the following proposals for functionality-based LCM of the UE-sided model for the positioning use case. 

Proposal 1: For the UE-sided inference model, RAN2 shall consider two approaches for the model training:
     		      Option 1: UE-side model training
     		      Option 2: LMF-side model training
Proposal 2: The UE shall request the ground truth label information from the LMF by invoking the MO-LR request.

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

Source:        ZTE Corporation
Title:           Discussion on LCM for positioning use case
Agenda item:   8.1.2.3
Document for:  Discussion and Decision

Conclusion
In this contribution, we propose the following observation and proposals:

Training data collection request
Proposal 1: For usecase 1, UE can request assistance data for AI/ML training using RequestAssistanceData message, and LMF can provide assistance data for AI/ML training using ProvideAssistanceData message.
Proposal 2: For case 1, UE can request some specific assistance data for training:
UE requests the number of TRPs that the UE wants to receive DL-PRS from;
UE requests the area of TRPs that the UE wants to receive DL-PRS from;
UE requests the number of PRUs that the UE wants to receive the corresponding measurement and labels from.

Consistency between training and inference
Observation 1: For AI/ML positioning, the NW additional conditions (e.g., TRP location, TRP synchronization error, TRP number, PRS configuration) can already be provided to the UE in current LPP spec.
Observation 2: When providing inference configuration to UE, LMF may not know which kind of inference configuration best suits the training configuration that UE used to train an AI model.
Proposal 3: For AI/ML positioning usecase 1, ensuring the consistency between training and inference does not need an associated ID.
Proposal 4: In order to ensure consistency between training and inference, UE should be able to request some specific assistance data for inference which suits the UE’s current trained AI model:
UE can request the wanted number of TRPs/cells for inference; 
UE can request the wanted area of TRPs/cells for inference;
UE can request the wanted synchronization error range between TRPs for inference.

PRU info transfer
Proposal 5: Create a list in ProvideAssistanceData containing a list of PRU’s part A/part B information for AI/ML.

Open issues
Observation 3: Current content of performance monitoring outcome does not require a new LPP signaling. It can be covered by the error message.

Proposal 6: Support to include NR-SelectedDL-PRS-IndexList in the new AI/ML positioning method.
Proposal 7: Do not support batch reporting in AI/ML positioning method.
Proposal 8: The target device error cause is indicated per LCM procedure (i.e.  training/inference/monitoring), E.g.:
Error cause during training:
UE does not get enough training data to train a AI/ML model;
UE cannot download or acquire or train a AI/ML model;
Error cause during inference:
UE cannot generate an estimate location using a AI/ML model;
Error cause during performance monitoring:
UE cannot generate a performance monitoring metric.
Proposal 9: Support LMF to provide integrity related assistance data to UE in AI/ML positioning method. The integrity related assistance data for AI/ML should take the integrity related assistance data for DL-TDOA as baseline.
Proposal 10: For performance monitoring signaling, wait for RAN1 to see if there is any other monitoring outcome, before RAN2 decides to create a new signaling or to reuse the legacy signaling.
Proposal 11: The signalling from LMF to UE to transfer the UE’s label and quality indicator is added in the NR-PositionCalculationAssistance message.

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

Agenda item:	   8.1.2.3
Source:		Lenovo
Title:	LCM for AIML based positioning with UE-sided model
Document for:		Discussion and Decision

Conclusion

Based on the discussion above, we observe:
Observation 1	One set of NR-DL-PRS-AssistanceData is provided in LPP provide assistance information message in legacy.
Observation 2	Legacy on-demand PRS transmission procedure supports transfer of applicable PRS configuration from multiple sets, however the PRS configuration parameter is only part of the parameters (e.g., element within NR-DL-PRS-AssistanceData) for UE to determine the applicability.


Based on the discussion above, we propose:

Proposal 1	RAN2 is suggested to distinguish Case 1 and Case3b (FFS 3a) as two different AIML based positioning methods, namely DL-AIML Positioning and UL-AIML Positioning methods.
Proposal 2	RAN2 is suggested to confirm that only one set of inference configuration is configured to UE for AIML based positioning.
Proposal 3	RAN2 is suggested to clarify if multiple sets of NR-DL-PRS-AssistanceData can be provided in the LPP provide assistance information message, such that UE can report the (in)applicability information in the LPP provide capabilities message or request the applicable ones via the LPP request assistance data message.
Proposal 4	For location server error (NR-DL-AI-ML-LocationServerErrorCauses), a new cause value “labelNotAvailable” can be added for the scenario that UE requests ground truth from LMF for training while LMF cannot provide.
Proposal 5	For target device error (NR-DL-AI-ML-TargetDeviceErrorCauses), the following new cause values can be added:
a.	aIMLModelNotAvailable
b.	methodTemporarilyNotApplicable
c.	unabletoPerformAIMLPositioning
d.	aIMLPerformanceMonitoringOutcomeNotAvailable
Proposal 6	(Monitoring Option A initiated by UE) LPP RequestAssistanceData and ProvideAssistanceData messages are used for UE to request LMF to provide relevant configuration/data for monitoring metric calculation at UE without sending the outcome to LMF.
Proposal 7	(Monitoring Option A initiated by LMF) LPP RequestLocationInformation and ProvideLocationInformation messages are used for LMF to configure the UE to calculate monitoring metric and send the outcome to LMF.
Proposal 8	The legacy LPP Assistance Data Transfer procedure (via RequestAssistanceData/ ProvideAssistanceData messages) is taken as the baseline for UE to request NR-DL-PRS-AssistanceData from LMF for training data collection.
Proposal 9	The legacy LPP Assistance Data Delivery procedure (via ProvideAssistanceData messages) is taken as the baseline for LMF to proactively provide NR-DL-PRS-AssistanceData to UE for training data collection.
Proposal 10	RAN2 discusses if LMF can transfer the label data of location to UE via existing LPP message (e.g., ProvideAssistanceData) or a new LPP message proactively/reactively.

3GPP TSG-RAN WG2 Meeting #130                                  R2-2503985
St.Julians, Malta, May 19th – 23rd, 2025                                                                                                              
Agenda item:		8.1.2.3 
Source:				Samsung
Title:					Discussion on LCM for POS use case
Document for:		Discussion & Decision
1	

Conclusion
Based on the above, RAN2 is requested to discuss and agree on the following proposals:
Baseline LCM procedure for Case 1:
Proposal. 1: RAN2 can wait for RAN1’s conclusion on NW-side additional condition.
Consistency between training and inference:
Proposal. 2: The legacy On-demand DL-PRS request can be reused for UE to request the assistance data for inference that is consistent with the one in training phase.
Proposal. 3: For the consistency between training and inference, RAN2 discuss any potential enhancement on the legacy on-demand DL-PRS request after RAN1 make conclusion on whether/how to provide NW-side additional condition (e.g., associated ID) in step 3. 
Performance monitoring:
Proposal. 4: For POS Case 1, LMF can provide UE with the assistance data for performance monitoring metric calculation via LPP ProvideAssistanceData message. 
Proposal. 5: [LPP-17] For performance monitoring option A-1, LMF can provide the ground-truth label of the target UE via LPP ProvideAssistanceData message. A new field can be introduced to include the ground-truth label of the target UE if RAN1 decide to support the option A-1.
Proposal. 6: [LPP-16] For POS Case 1, UE can provide LMF with the outcome of performance monitoring via LPP ProvideLocationInformation message. 
Proposal. 7: For performance monitoring in POS Case 1, the content of assistance data for monitoring metric calculation and the content of monitoring outcome can be determined/implemented later based on RAN1 parameter list.
4	

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

Agenda item:	8.1.2.3
Source:	Nokia
Title:	Reporting of applicability and inference configurations
WID/SID:	NR_AIML_air-Core - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has proposed the following:
Proposal 1: LMF may provide UE with candidate inference configuration(s), optionally with preference order, in Step 3 (ProvideAssistanceData) of the LCM procedure, based on which UE determines and reports applicable functionalities along with applicable inference configurations. LMF could then request inference in Step 5 (RequestLocationInformation) using one or more of the applicable inference configurations received in Step 4 (ProvideCapabilities). 
FFS: the content of a candidate inference configuration, which would depend on RAN1 (e.g., requested location information with QoS requirements (e.g., accuracy, response time, etc.), requested measurements (if any), reporting configuration (e.g., reporting periodicity), in addition to the assistance data such as containing the DL PRS configuration or any NW-side additional conditions). 
Proposal 2: UE may proactively inform LMF with potential inference configuration(s) it may apply, in Step 2 (ProvideCapabilities) of the LCM procedure, before receiving any assistance data or inference configuration from LMF.
Proposal 3: In the LCM procedure, when reporting applicability, UE may provide additional information such as the expected validity of the report, and expected QoS or monitoring requirements of the functionality, to assist LMF for making LCM decisions.

3GPP TSG-RAN WG2 Meeting #130	R2-2504158
St Julian’s, Malta, May 19 - 23, 2025
															
Agenda item:	8.1.2.3
Source: 	Qualcomm Incorporated
Title: 	Discussion on remaining issues for "AI/ML Positioning Case 1"
Document for:		Discussion and Decision

1.	

Summary
In this contribution we discussed some remaining issues for the specification support of "AI/ML Positioning Case 1". The following Observations and Proposals were made.
Observation 1:	Given that RAN2 agreed to introduce "AI/ML Positioning Case 1" as a separate/new LPP positioning method, the RAN1 Features 58-2-1/58-2-2 are already supported per existing LPP principles.
Observation 2:	A decision on whether the existing LPP DL-PRS Resource Capabilities can be reused for "AI/ML Positioning Case 1" or whether a new IE specific to "AI/ML Positioning Case 1" is needed depends on further progress of the RAN1 UE features.

Proposal 1 (LPP-10a):	"Batch reporting", i.e., reporting of up to 32 location results in a single report, is also applicable to "NR AI/ML Positioning Case 1". 
Proposal 2 (LPP-15):	Positioning Integrity is also applicable to NR AI/ML Positioning Case 1. The existing NR integrity related assistance data can also be provided for NR AI/ML Positioning Case 1. 
Proposal 3 (LPP-16):	In the case the target UE cannot perform the requested Case 1 positioning method (e.g., due to change of "applicable functionality", due to model performance monitoring issues, etc.), the target UE returns the IE NR-DL-AIML-Positioning-Error, e.g., with error cause ''AI/ML positioning not possible''.
Proposal 4 (LPP-17):	A target UE can obtain the "ground-truth label" information via existing MO-LR procedures. No additional RAN2 specification impacts are foreseen.

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

Agenda Item:	8.1.2.3
Source:	Huawei, HiSilicon
Title:	Discussion on LPP open issues for Case 1
Document for:	Discussion and decision

Conclusions
In this paper, we are addressing the remaining open issues for LPP. Here are our observations and proposals:
Observation 1: Open issue LPP-7 is up to RAN1.
Observation 2: For Open issue LPP-13, the existing IE NR-DL-TDOA-LocationServerErrorCauses-r16 can be used as the baseline.
Observation 3: For Open issue LPP-14, the existing IE NR-DL-TDOA-TargetDeviceErrorCauses-r16 can be used as the baseline.
Observation 4: Open issue LPP-16 is up to RAN1.

Proposal 1: For Open issue LPP-10a, "batch reporting" for AI/ML positioning can be discussed once the main functionalities are completed.
Proposal 2: For Open issue LPP-15, the positioning integrity for AI/ML positioning can be discussed once the main functionalities are completed.
Proposal 3: For Open issue LPP-17, the existing IE LocationCoordinateTypes can be used as a starting point for indicating ground truth label. The new IE NR-AI-ML-PositioningProvideAssistanceData can be used to carry new IEs.

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

Agenda Item:	 8.1.2.3
Source:	Ericsson
Title:	Remaining issue for LCM For Positioning 
Document for:	Discussion

1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	For data collection for AI/ML models on the UE side, the UE may request assistance data to LMF using UE-initiated assistance data request procedure as specified in clause 8.12.3.1.2.2 of TS 38.305 or UE-initiated on-demand PRS procedure as specified in clause 7.6.2 of TS 38.305 without the need to include the purpose of request.
Observation 2	Similar to legacy expectedRSTD where LMF provides the expected RSTD value so that the UE can filter any outliers, the LMF for the case of AI/ML training can provide maximum uncertainty/error so that the UE can judge if the obtained positioning can be considered as ground truth or should be discarded.


Based on the discussion in the previous sections we propose the following:
Proposal 1	Legacy procedure is reused for data collection for Case 1 without any enhancements.
Proposal 2	LMF provides the guidance for trustworthy label based upon Positioning Integrity (maximum allowed Positioning error or uncertainty for a trustworthy label)
 

3GPP RAN WG2 Meeting #130	R2-2504310
St Julian’s, Malta, May 19th – 23rd 2025
Agenda Item:	8.1.2.3
Source:	InterDigital
Title:	Remaining open issues: LCM for Positioning use case
Document for:	Discussion, Decision

Conclusion
In this contribution the following observations and proposals are made regarding open issues for LCM for Positioning use case:
Observation:	Being configured with a DL-AoD positioning method is not a prerequisite to receive AoD measurements via NR-PRU-DL-Info
Proposal 1:	[LPP-16] The UE can indicate that the target UE cannot perform the Case 1 positioning method in an unsolicited capability report
Proposal 2:	[LPP-16] Specify triggers to initiate performance monitoring. FFS details.
Proposal 3:	[LPP-17] From the RAN2 perspective, for Case 1, the MO-LR procedure specified in TS 23.273 can be used to collect the ground truth from the LMF by the UE
Proposal 4:	[LPP-15] Wait for RAN1 discussion to determine whether integrity information should be included or not as part of integrity information contain uncertainty related to TRP locations.
Proposal 5:	[LPP-6] The IE NR-PRU-DL-Info is also applicable to NR AI/ML positioning Case 1. The corresponding Editor's Notes in clause 6.4.3 can be removed

3GPP TSG-WG2 Meeting #130                                            R2-2504440
St.Julians, Malta, May 19th – 23rd, 2025
Source: 			CMCC
Title:  		    Discussion on LCM for positioning
Agenda item:	8.1.2.3
Document for: 	Discussion

Conclusion 
According to the above discussion, the following observations and proposals are given:
Performance monitoring
Proposal 1: RAN2 is suggested to support the UE side performs monitoring for AI/ML positioning Case 1.
Proposal 2: The label data (e.g., label and quality indicator of label) of location generated by LMF can be transmitted by the LPP ProvideAssistanceData message.
Proposal 3: The monitoring outcome can be transmitted by the UE via LPP ProvideLocationInformation message, including at least an indication that the target UE cannot perform the Case 1 positioning method.
Proposal 4: For data collection for UE sided POS model training, at least DL PRS configuration, existing assistance data IE of UE-based DL-TDOA and/or UE-based DL-AoD need to be provided by LMF to UE. 

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

Agenda Item:	8.1.2.3
Source:	HONOR
Title:	Discussion on LCM for Positioning Use Case
Document for:	Discussion and Decision
1. 

Conclusions
In this contribution, we discussed the issues related to LCM for Positioning Use Case. Based on the discussion, the following proposals are concluded:
Proposal 1: (issue LPP-16) For Option A (the target UE side performs monitoring metric calculation), the UE can request assistance information (e.g., ground truth label of the target UE, positioning assistance information) for monitoring metric calculation via RequestAssistanceData message.
Proposal 2: (issue LPP-16) For functionality management by LMF, if UE side performs monitoring metric calculation, the monitoring metric should be sent by UE to LMF via ProvideLocationInformation message.
Proposal 3: (issue LPP-16) The UE reports the monitoring metric periodically or triggered by the configured condition.
Proposal 4: (issue LPP-16) If LMF performs monitoring metric calculation, the LMF requests inference results for monitoring metric calculation via RequestLocationInformation message.
Proposal 5: If multiple positioning methods are included in an LPP RequestLocationInformation message, AI/ML positioning methods are recommended to have higher priority than non-AI/ML methods.
Proposal 6: LMF can deactivate an AI/ML positioning functionality explicitly if the performance reduction is detected.
Proposal 7: After receiving non-applicability report of one certain functionality, LMF can deactivate it explicitly or deactivate it implicitly by providing inference configuration corresponding to other applicable functionality in RequestLocationInformation message.
Proposal 8: For periodical location reporting, if the error indication is included in ProvideLocationInformation, LMF can deactivate it explicitly or deactivate it implicitly by providing inference configuration corresponding to other functionality in RequestLocationInformation message.
4.