3GPP TSG RAN WG1 #120bis                                                             R1-2501796 
Wuhan, China, April 7th – 11th, 2025

Source:	vivo
Title:	Specification support for positioning accuracy enhancement
Agenda Item:	9.1.2
Document for:	Discussion and Decision

Conclusions
We have the following observations:
For AI/ML based positioning Case 1, the ambiguity of time stamp caused by SFN wrapping can be avoided by LMF’s implementation, considering the following cases.
Case 1: When the interval between the time when LMF obtains the location and the time when the location is reported is within a few frames, which will hardly cause any ambiguity. 
Case 2: When the interval between the time when LMF obtains the location and the time when the location is reported is relatively long, LMF can choose UTC time as timestamp rather than SFN.
As for how to associate Part A with Part B for one training data sample, the following methods can be considered: 
Method 1: Associating Part A with Part B according to their attached time stamps at model training entities.
Method 2: Reporting paired Part A with Part B in one data sample if both come from the same data generation entity. In other words, if the data generation entity reports a Part A and a Part B in one data sample, the model training entity can assume they are associated with the same physical location.
For the time stamp, the existing mechanism can be reused for data collection. 
For data collection of case 1, do not support always mandatorily reporting UTC time together with SFN.
For the cases where Part A and Part B are generated by different entities, time stamp is sufficient for pairing Part A and Part B, and other information, e.g., the duration for which Part B is valid, is not necessary. 
Reuse the existing IE, i.e., the combination of confidence and uncertainty, as the quality indicator of label for AI/ML based positioning.
Reuse the existing IEs, i.e., NR-TimingQuality in 37.355 and “Timing Measurement Quality” in 38.455, as the quality indicator of channel measurement.
A channel measurement as a whole should be associated with one quality indicator.
Support to establish rules to prevent the invalid reporting of labels for data collection of Case 3b.
Reporting Nt from gNB to LMF does not yield any additional performance benefits for Case 3b.
Do not support reporting Nt from gNB to LMF for sample-based reporting of Case 3b
First-path phase, when combined with multi-model/view processing, can additionally offer at least 20% gain of positioning accuracy over PDP with negligible extra reporting overhead.
There are at least three methods which can be utilized to eliminate the impact of random initial phases of transceiver:
PRU-assisted phase calibration
Relative phase with reference to a reference path/sample
Initial phase measurement and reporting
In additional to directly improving positioning accuracy, phase information can also be utilized as assistance information to assist model monitoring, e.g., by cross-checking the positioning results from different views.
In addition to delay and power, at least RSCP and RSCPD should be supported for AI/ML based positioning.
Raw CIR reporting can be supported, and LMF can eliminate the impact of random initial phases of transceiver by implementation.
Support A-1, A-2 and A-3 for model performance monitoring of AI/ML based positioning Case 1.
If Option A-3 is specified, the UE could request PRU measurement with following information 
Cell or area information
The type of PRU channel measurement (e.g., request sample-based channel measurement, preferred k , Nt’ and Nt).
 If the monitoring outcome is associated with an AI/ML functionality, the content of monitoring outcome includes 
An indicator (e.g., 0 or 1) that informs LMF whether the current AI/ML functionality is valid, or
An indicator that informs LMF whether the current AI/ML functionality is deactivated. If the UE thinks that the current AI/ML functionality is invalid, it can immediately deactivate the functionality and then inform LMF.
To align with RAN2’s procedure, RAN1 prioritizes the discussion of functionality for AI/ML based positioning Case 1, at least including the concept/terminology of supported functionality and applicable functionality.
As for how to provide info#7 from LMF to UE for Case 1, Alternative 3 is not preferred, and all other 3 alternatives are feasible. 
 Associated ID related mechanism, if supported, can be further reused for info# 6 and info# 16. AI Processing Unit is not considered for AI/ML based positioning Case 1 in Rel-19.
AI Processing Unit is not considered for AI/ML based positioning Case 1 in Rel-19.

3GPP TSG RAN WG1 #120bis		R1-2501859
Wuhan, China, April 7th – 11th, 2025

Conclusion
In this contribution, we have the following proposals with regard to AI/ML positioning.
Proposal 1: Confirm the following working assumption for measurement generation entity for Case 1:
Working Assumption 
For training data generation of AI/ML based positioning Case 1, the measurement and its related data (e.g., timestamp) are generated by PRU and/or Non-PRU UE.
Proposal 2: Confirm the following working assumption for label generation entity for Case 1:
Working Assumption 
For training data generation of AI/ML based positioning Case 1, the label and its related data (e.g., time stamp) can be generated by: 
PRU
Non-PRU UE with estimated location
LMF 
Note: transfer of the label and its related data is out of RAN1 scope.
Proposal 3: Confirm the following working assumption for label generation entity for Case 3b:
Working Assumption 
For training data generation of AI/ML based positioning Case 3b, the label and its related data (e.g., time stamp) can be generated by:
PRU
Non-PRU UE with estimated location
LMF
Note: transfer of label and its related data is out of RAN1 scope.
Note: It is assumed that user data privacy of non-PRU UE is preserved.
Note: Previous related working assumption made in RAN1#116bis for training data generation of AI/ML based positioning Case 3b will not need to be confirmed.

Proposal 4: For training data collection of AI/ML based positioning Case 1, for time stamp of label,
When the label is provided by LMF, the existing IE in TS 37.355 can be reused from RAN1 perspective

Proposal 5：For training data collection of AI/ML based positioning case 1, if part A and part B are generated by different entities, the time stamp of part A and the time stamp of part B are used for pairing them.

Proposal 6：For AI/ML based positioning Case 1, assistance information, support Alternative 4. info #7 is provided explicitly from LMF to UE.

Proposal 7: For model performance monitoring of AI/ML positioning Case 1, at least Option A-1 and A-2 are supported.

Proposal 8: For model performance monitoring of AI/ML positioning Case 1, the target UE can automatically report monitoring outcome without LMF request.

3GPP TSG RAN WG1 #120bis	R1-2501917
Wuhan, China, April 7th–11th, 2025
Title:                   Discussion on AI/ML-based positioning enhancement
Source:              ZTE Corporation, Pengcheng Laboratory
Agenda item:     9.1.2
Document for:   Discussion/Decision

Conclusion
In this contribution, we have the following observations and proposals with regard to AI/ML positioning.
Model input
Proposal 1: For AI/ML based positioning Case 3b, the measurement parameter Nt is not included together with the channel measurement values for Rel-19 enhanced measurement.
Proposal 2: For Rel-19 AI/ML based positioning, for Case 3b, “FFS: whether transmit offset from gNB to LMF” in RAN1#119 agreement is resolved by:
•	No offset is transmitted from gNB to LMF
Proposal 3: There’s no need to introduce power quality for channel measurement.
Proposal 4: For training data collection of AI/ML based positioning, the quality indicator of timing information in Part A is associated with the whole channel measurement.
Observation 1: Compared with PDP, CIR provides better positioning performance with acceptable overhead increment.
Proposal 5: In AI/ML based positioning, phase information is used  for determining model input.
Observation 2: For power measurement, the positioning performance of Simulation 2 is slightly better than Simulation 1 (6.67% performance gain), while the signalling overhead of Simulation 2 is twice that of Simulation 1.
Proposal 6: The mapping table of RSRPP in TS 38.133 can be reused for AI/ML positioning.
Model output
Proposal 7: For AI/ML-assisted positioning Case 3a, when the LOS/NLOS indicator is reported together with the legacy timing measurement result, from RAN1 perspective,
The LOS/NLOS indicator provides the likelihood of a line-of-sight physical propagation path for the channel measured over the resources for which the measurement is reported;
One LOS/NLOS indicator value is optionally reported from the source to the receiver as in the existing specification.
The LOS/NLOS indicator can reuse the existing IE LoS/NLoS Information in 38.455.
Proposal 8: For AI/ML-assisted positioning Case 3a, when the LOS/NLOS indicator is reported with the AI/ML model output, from RAN1 perspective,
The LOS/NLOS indicator provides the likelihood of a line-of-sight virtual path for the model output over the resource for which the measurement is reported.
The LOS/NLOS indicator can reuse the same format as the existing IE LoS/NLoS Information in 38.455.
Proposal 9: For reporting model output of AI/ML assisted positioning, an indicator identifying whether the measurement is based on AI/ML model is not needed.
Proposal 10: The model output of AI/ML assisted positioning can be angle information.
Model training and model inference
Proposal 11: For AI/ML positioning case 1, for the time stamp of location information reported by UE,
Existing IE “measurementReferenceTime” in TS 37.355 can be reused from RAN1 perspective.
Proposal 12: For AI/ML positioning case 1, for the time stamp of location information sent by LMF, from RAN1 perspective,
Existing IE “measurementReferenceTime” in TS 37.355 can be reused.
A valid duration is associated with the “measurementReferenceTime”.
Proposal 13: For AI/ML based positioning Case 1, from RAN1 perspective, when the label data of location is generated by UE/PRU, label and quality indicator of label can be provided by reusing existing IEs, the following alternatives are considered:
the existing IE can use one of the geographic shapes defined in TS 23.032. The location estimate uncertainty and confidence (if included with the geographic shapes) can serve as quality indicator of the label
the existing IE horizontalUncertainty can serve as quality indicator of the label
Proposal 14: For AI/ML based positioning Case 3a, from RAN1 perspective, when the label data of timing information is reported/provided, the quality indicator of label can be provided by reusing existing IE:
the existing IE NR-TimingQuality can serve as quality indicator of the label.
FFS: other quality indicators if other intermediate features are supported. 
Proposal 15: From RAN1 perspective, for Case 3b measurements,
The existing procedures can be reused in terms of SRS configuration.
These measurements can be used for multiple aspects related to case 3b, e.g. training data collection, monitoring, or inference procedures. 
Note: Purpose, such as the training data collection, monitoring, or inference procedures mentioned above, will not necessarily be specified in RAN 1 specifications
Proposal 16: For option A (UE initialed DL PRS configuration), the following enhancement can be supported:
On-demand PRS request includes the suggested number of activated TRPs that transmit DL PRS. 
Proposal 17: For AI/ML positioning, different data collection requirements can be configured by the data collection node, where the configuration includes at least:
Quality requirement of the channel measurement, report periodicity.
Note: The data collection node can be different among different use cases.
Proposal 18: For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, a valid duration is associated with Part B.
Consistency between training and inference
Proposal 19: For AI/ML based positioning Case 1, all assistance information from legacy UE-based DL-TDOA can be provided from LMF to UE explicitly.
There is no need to introduce associated ID for AI/ML positioning.
Proposal 20: For AI/ML based positioning Case 1, all assistance information from legacy UE-based DL-AOD can be provided from LMF to UE.
Model monitoring
Proposal 21: Label-free monitoring can be realized by implementation in a manner transparent to specification. No further discussion on label-free monitoring.
Proposal 22: For model performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring, support option B-1 and option B-2:
Option B-1. at least inference result (i.e., the model output corresponding to target UE’s channel measurement) of the target UE is sent by the target UE to LMF. 
Option B-2. PRU’s channel measurement is sent via LMF to the target UE, and the inference result (i.e., the model output corresponding to PRU’s channel measurement) is sent by the target UE to LMF.
Proposal 23: For model performance monitoring of AI/ML positioning Case 1, support UE report suggested monitoring behavior and/or positioning accuracy as monitoring outcome to LMF.
Proposal 24: For model performance monitoring of AI/ML positioning Case 1, choose one or more options from the following for the time when UE reports monitoring outcome to LMF:
Option 1: Up to UE’s implementation, i.e., UE reports the monitoring outcome whenever UE wants.
Option 2: UE reports the monitoring outcome when there’s a need to change the current behavior.
Option 3: LMF pre-configures criterion on when UE should report monitoring outcome.
Option 4: LMF sends request to trigger UE’s monitoring outcome report.
Option 5: LMF configures the reporting amount and reporting interval to UE for monitoring outcome report.
Proposal 25: For case 3a, LMF provides assistance data on the ground truth label to TRP. FFS: the detailed IE.
Proposal 26: For LMF-side model, whether assistance information is required for model monitoring depends on whether LMF has prior information on UE/PRU’s location:
If LMF has prior information on UE/PRU’s location, there’s no need to let UE/PRU/gNB send any assistance information.
If LMF doesn’t have prior information on UE/PRU’s location, LMF can request UE to report legacy positioning result as ground truth label for model monitoring. 
Proposal 27: For UE side model and NG-RAN side model, model monitoring metric calculation function and model monitoring function can be located in the same or different entities.

3GPP TSG RAN WG1 #120bis 		                                    		   R1-2501925
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.2
Source:	InterDigital, Inc.
Title:	Discussion on support for AIML positioning
Document for:	Discussion and Decision

Conclusion
In this contribution, the following proposals and observations are made.
Prioritization of discussion topics
Proposal 1: Prioritize discussion on the following items
Signalling details to indicate network side conditions to the UE from the LMF to assist the UE determine consistency between training phase and inference phase
For Case 1, assistance data that shall be provided to the UE from LMF
LCM details such as entities which performs performance monitoring, required signalling
Determination of consistency between training and inference phase
Observation 1: For the trained AIML model to be applicable, consistency between training and inference should be maintained.
Proposal 2: For Case 1, enhance assistance data used for the existing UE-based DL-TDOA positioning method to support the AIML-based positioning 
Proposal 3: For Case 1, support to combine assistance data used for UE-based DL-TDOA and UE-based DL-AoD to allow the UE to check NW side additional conditions
Proposal 4: Adopt Alternative 4, “Info #7 is provided explicitly from LMF to UE”
Proposal 5: For Case 1, in the provided PRS configurations, at least frequency layer IDs, cell IDs and TRP IDs should be the same between training and inference phase to maintain consistency 
Proposal 6: Tolerance for difference in assistance information (e.g., network synchronization error, difference in boresight angles) should be specified
“Inference configuration”
Observation 2: RequestLocationInformation is for inference configuration
Validity condition of AIML models
Proposal 7: Time validity for an AIML model(s) should be specified
UE-side condition
Proposal 8: For Case 3b, if Part B is generated by the UE or PRU, validity conditions for the ground truth (e.g., validity duration) should be included in Part B
Proposal 9: For Case 3b, change in UE side conditions (e.g., whether it has changed since the last occasion due to rotation) shall also be reported in Part B
Provision of ground truth for Case 1
Proposal 10: In Case 1, Support the UE to request for a ground truth from the LMF 
Proposal 11: In Case 1, support the UE to request to the LMF a specific level (e.g., above a threshold) of a ground truth label quality for LMF measurement forwarding
Performance monitoring for LCM for Case 1
Observation 3: It is not clear, for performance monitoring Option A for Case 1, how the ground truth derived based on SRS measurements can be associated with inputs to the UE side model where the inputs are derived based on PRS measurements
Proposal 12: For performance monitoring Support Option A-1 for Case 1, the UE shall report legacy measurements, e.g., path-based measurements.
Observation 4: For performance monitoring Option A-1 for Case 1, as quality of the ground truth depends on LMF implementation, there can be a mismatch between the expected quality of the ground truth by the UE and quality of the ground truth provided by the LMF. 
Proposal 13: For performance monitoring Support Option A-1 for Case 1 the UE shall be able to request the following;
Quality of the ground truth
Positioning method the LMF shall use to derive the ground truth
Amount of measurements the LMF shall use to derive the ground truth
Observation 5: Assistance data provided under Option A-2 should be aligned with assistance data provided for AIML-based positioning
Observation 6: Option A-3 offers more diversity in terms of locations of the ground truth, compared to Option A-1 and Option A-2
Observation 7: Option A-1, A-2 and A-3 can consider existing frameworks in NR positioning as the starting point
Observation 8: The content of transferred assistance data may need enhancement for AIML based positioning for Option A-3
Proposal 14: For performance monitoring of AI/ML positioning Case 1, support Option A-2.
Proposal 15: For performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring, support A-3.
Performance monitoring outcome
Proposal 16: For performance monitoring option A, the monitoring outcome includes whether the UE side model is usable for AIML based positioning.
Proposal 17: The UE shall indicate the cause of changes in applicability via unsolicited UE capability message  
Proposal 18: For LCM Option A, as the monitoring outcome, the UE can report the difference between the ground truth and AIML output to the LMF
Need for phase measurements
Observation 9: The AIML model which accepts phase measurement for the selected samples in addition to PDP measurements yields approximately 1 cm improvement in accuracy compared to the AIML model which accepts only PDP measurements
Proposal 19: Support to report phase measurement for the sample-based measurements (type-B measurement)
Proposal 20: Support first-path phase measurement, namely RSCP and RSCPD, for AIML based positioning for type-A measurement
AIML-assisted positioning
Proposal 21: For AIML assisted positioning, support an indication in the measurement report to indicate the reported timing measurement is inferred by an AIML model(s).
Proposal 22: For Case 3a, keep the current definition of the LOS indicator shown in TS 37.355,  “the likelihood of a Line-of-Sight propagation path from the source to the receiver”
Support for new AIML based RTT positioning methods
Observation 10: For Case 3b, the existing RTT positioning method can be used without any specification impact and coexist with AIML based positioning
Observation 11: For Case 3a, the LMF can request the gNB to report inferred gNB Rx-Tx time while the UE can report UE Rx-Tx time to the LMF under the RTT positioning method.
Proposal 23: Support multi-RTT positioning method under Case 3b without any specification enhancement
Proposal 24: Support multi-RTT positioning method under Case 3a with a request from the LMF to the gNB to use an AIML model for generating gNB Rx-Tx time

3GPP TSG-RAN WG1 Meeting #120-bis	R1- 2501940
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	NVIDIA
Title:	Specification support for AI-enabled positioning
Document for:	Discussion
1	

Conclusion
For Rel-19 AI/ML based positioning Case 3b, 
If the gNB cannot report measurements according to measurement type (A) or measurement type (B) requested by LMF, the gNB responds to LMF that: the gNB cannot provide measurement with the requested measurement type. 
The gNB does not respond to LMF with a measurement report where the measurement type is different from requested.
It is up to RAN3 to decide the signalling details.
Note: It is RAN1 understanding that this is the same behavior as in legacy when the NG-RAN node cannot support the requested measurement.
Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.

3GPP TSG RAN WG1 #120bis		R1-2501947
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.2
Source:	Google
Title:	ML based Positioning
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided discussion on AI/ML based positioning. Based on the discussion, the following proposals are provided.
Proposal 1: Support to extend the enhanced path-based measurement to UE-side measurement
Proposal 2: Support to report the L1-SINR in addition to the path-based measurement with regard to potential measurement error for the path-based measurement.
Proposal 3: For Option A based model performance monitoring for Case 1, support a 1-bit indication on whether a performance failure is detected or not as the report content
UE identifies the performance failure based on the calculated metric and threshold configured by the NW
Proposal 4: Do not support Option B based model performance monitoring for Case 1
Proposal 5: Support Alt4 where Info #7 is provided explicitly from LMF to UE.

3GPP TSG RAN WG1 #120bis	                                                                            R1- 2501969
Wuhan, China, April 7th – 11th, 2025

Source:	CATT, CICTCI
Title:	Specification support for AI/ML-based positioning
Agenda Item:	9.1.2
Document for:	Discussion and Decision

Conclusions
In this contribution, we provide our views on AI/ML-based positioning. The observation and the proposals are summarized as follows: 
Observation: For case 3b, if the whole channel measurement and ground truth label with respective quality indicator are always reported to LMF side for selecting the high quality training samples, the transmission of discarded samples with low quality increases unnecessary resource overhead.
Proposal 1: For training data collection of AI/ML based positioning, timing information of a channel measurement is only associated with one quality indicator.
Proposal 2: For AI/ML based positioning Case 3b, from RAN1 perspective, when the label data of location is generated by UE and transferred from UE to LMF, label and quality indicator of label can be provided by reusing existing IEs. 
From RAN1 perspective, the existing IE can use one of the geographic shapes defined in TS 23.032. The location estimate uncertainty and confidence (if included with the geographic shapes) can serve as quality indicator of the label.
Proposal 3: For AI/ML based positioning case 3a, the label data of LOS-NLOS-Indicator and/or timing information is generated by LMF and transferred from LMF to gNB, the quality indicators corresponding to timing information and LOS-NLOS indicator are provided as follows.
For timing information, the IE NR-TimingQuality in 37.355 can be served as the quality indicator of label. 
For LOS-NLOS-Indicator, two potential options are provided for further down-selection: 
Option 1: The LOS-NLOS-Indicator with soft value in existing specifications can serve as the quality indicator of label.
Option 2: The UE’s location estimate uncertainty and/or confidence defined in existing specifications can serve as the quality indicator of label. 
Proposal 4: For case 3a, LMF can provide ground truth labels for gNB/TRP, and one candidate label is the timing information (e.g., ideal UL RTOA).
Proposal 5: For case 3a, the following methods of generating the ground truth label can be considered:
Method 1: UE/PRU provides the location related information to LMF for generating the ground truth label.
Method 2: Multiple gNBs/TRPs provide the SRS-pos measurements (e.g. UL RTOA) to LMF for estimating UE’s location coordinate and the UE’s location coordinate is used to generate the ground truth label.
Proposal 6: For training data collection in case 3a, consider the following options:
Option A. (gNB initiated) gNB/TRP makes a request to LMF on the preferred UL SRS-pos configuration for training data collection. LMF makes the decision on determining the UL SRS configuration for training data collection and provides the assistance data to the gNB/TRP. 
Option B. (LMF initiated) LMF determines the UL SRS configuration for training data collection and provides the assistance data to the gNB/TRP.
Proposal 7: For case 3b, when LMF side collects training data, LMF side can use a quality indicator condition or criteria to indicate the required quality of the collected data. 
Proposal 8: A quality threshold can be provided from LMF to channel measurement/label generation entity:
If provided, channel measurements/labels reported by the generation entity are expected to have a quality better than the quality threshold.
If not provided, channel measurement/label generation entity provides all channel measurement/label generation entity to the LMF, regardless the quality.
Proposal 9: For all AI positioning cases, the associated measuring time difference between Part A and Part B should be restricted to ensure the validity of a training data sample, e.g., the measuring time differences between TRPs and UEs are not too large.
Proposal 10: For training data collection of case 1, further study how to match the measurements from multiple TRPs with one label by related time stamps. 
Proposal 11: For case 3b, gNB/TRP can report Nt along with the channel measurements to LMF.
Proposal 12: For case 3b, the following one or two options of timing information reporting of sample-based measurements are considered:
Option 1: Sample-based reporting
Time offset: the time offset is the difference between the timing of first sample and UL RTOA reference time.
Bitmap: the bitmap is used to represent the timing information of Nt' samples and the first bit is corresponding to the first sample of Nt' samples.
Option 2: Path-based reporting
Resolution step of the timing information of path should be an integer multiple of sampling periods.
Path-based reporting may be enhanced to support reporting more samples.
Proposal 13: For case 3b, if both sample-based reporting and path-based reporting are supported, the choice of sample-based reporting and path-based reporting is up to gNB/TRP selection, or up to LMF indication.
Proposal 14: Phase measurement and reporting is supported for case 3b.
Proposal 15: For case 3b, reuse the existing definitions of UL SRS-RSRPP to represent the power information by replacing ‘path’ to ‘sample’, and reuse the existing report mapping table of UL SRS-RSRPP to report the power information.
Proposal 16: For case 3b, a whole quality indicator of the channel measurement is supported and there is no separate quality indicator for timing information, power information or phase information.
Proposal 17: For case 1, when UE sends a data collection request to LMF, the data collection request contains some assistance information related to the PRS/TRP set expected by UE.
Proposal 18: For case 1, for model performance monitoring metric calculation in label-based model monitoring, Option A-1, A-2 and B-1 are supported.
Option A-1. At least information on ground truth label of the target UE is generated by LMF and provided to the target UE.
Option A-2. At least position calculation assistance data (e.g., existing information for UE-based positioning method) is provided from LMF to the target UE.
Option B-1. At least inference result (i.e., the model output corresponding to target UE’s channel measurement) of the target UE is sent by the target UE to LMF. 
Proposal 19: For case 3b, for model performance monitoring metric calculation in label-based model monitoring, LMF generates UE’s location as ground truth label and performs monitoring metric calculation.
Proposal 20: For AI/ML positioning Case 1 with label-based model monitoring, when the ground truth label (i.e. the UE’s location) is generated by LMF, UE should send the channel measurements to LMF, and LMF can generate the ground truth label by LMF-sided AI/ML model inference outcomes based on the channel measurements.
Proposal 21: For model performance monitoring of AI/ML positioning case 1, UE reports monitoring outcome when:
UE receives LMF request.
The reporting conditions configured by LMF satisfy.
Proposal 22: For model performance monitoring of AI/ML positioning case 1 (including label-free monitoring), when UE reports monitoring outcome to LMF, the report can include:
Monitoring metrics
Confidence-level of monitoring metrics
UE-side LCM decisions
Confidence-level of UE-side LCM decisions
Requested PRS configuration
Preferred TRP set
Proposal 23: For model performance monitoring of AI/ML positioning case 1 (including label-free monitoring), some monitoring-related information should be transferred between UE and LMF to facilitate the monitoring process.
Proposal 24: For model performance monitoring of AI/ML positioning case 1 (including label-free monitoring), the monitoring-related information may include:
UE Monitoring capability
Capability of calculating monitoring metrics
Capability of making LCM decisions
Support of different monitoring methods
Descriptions of the UE-side monitoring metrics
Descriptions of the LMF-side monitoring metrics
Descriptions of the UE-side LCM decisions
Proposal 25: For model performance monitoring of AI/ML positioning case 3a, some monitoring-related information should be transferred between gNB/TRP and LMF to facilitate the monitoring process.
Proposal 26: For AI/ML-based positioning, both the following concepts of validity area for training data collection can be considered:
Concept 1: Assistance data or measurement validity area configured by LMF, i.e. AreaID-CellList introduced in Rel-17. 
Concept 2: Validity area composed of TRP(s) corresponding to channel measurement, keeping the AI/ML model valid.
Proposal 27: Regarding the alternative ways of providing info #7 (i.e., Geographical coordinates of the TRPs served by the gNB):
Support Alternative 1. Info #7 is provided implicitly via associated ID.
Associated ID is signalled by LMF to indicate whether info #7 is consistent between training and inference.
Proposal 28: For AI/ML based positioning, geographical coordinates of the TRPs should be implicitly included in the assistance information due to privacy issues, e.g., via associated ID. The granularity of an associated ID can be TRP-level, cell-level or area-level.
Proposal 29: Info #16-18 (i.e., some assistance info related to legacy AoD method) are not necessarily included in the assistance information for AI/ML positioning. 
Proposal 30: On AI/ML functionality management for Case 1, wait for more progress of applicable functionality reporting in RAN2.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502064
Wuhan, China, April 7th – 11th, 2025

Source:	TCL
Title:	Discussion on specification support for positioning accuracy enhancement
Agenda item:	9.1.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we have the following observations and proposals:
Observation 1: The conventional reference signal configurations could be enhanced to accommodate AI-specific requirements.
Observation 2: There should be no specification impact with regard to the additional conditions for Case 3a.
Proposal 1: For model performance monitoring metric calculation in label-based model monitoring for AI/ML positioning Case 1, Option A-2 is preferred.
Proposal 2: The monitoring outcome sent from the target UE to LMF can be a Boolean value or a value between 0 and 1.
Proposal 3: The monitoring outcome can be signaled by UE when the model performance deteriorates.
Proposal 4: It is recommended to perform the monitoring metric calculation at the model inference entity for label-free model monitoring.
Proposal 5: LMF is responsible for functionality management decision making.
Proposal 6: Further discuss whether the monitoring decision making is performed at LMF or the entity for monitoring metric calculation (i.e., UE side or NG-RAN node) for Case 1 and Case 3a.
Proposal 7: The side information should be transmitted and the following two options can be considered:
a. the record time of the time stamp of Part B and the validity duration of Part B are transmitted.
b. the starting time and the end time associated with Part B are transmitted.
Proposal 8: AI-specific or AI model-specific reference signal configurations, including PRS and SRS for positioning, could be introduced and indicated to UE, enabling it to implement the specified model or distinguish the transmitting method of the configured reference signal.
Proposal 9: For the indication of info #7 from legacy UE-based DL-TDOA, Alternative 1 is preferred.
Proposal 10: Down-select the format of associated ID for consistency between training and inference:
a. one associated ID corresponds to a set of geographical coordinates of the TRPs served by the gNB.
b. one associated ID corresponds to the geographical coordinate of one of the TRP served by the gNB.

3GPP TSG RAN WG1 #120b                                         R1- 2502071
Wuhan, China, April 7th – 11th, 2025

Source:	NEC
Title:	Discussion on specification support for AI/ML based positioning accuracy enhancement
Agenda Item:	9.1.2
Document for: 	Discussion and Decision

Conclusion
In this contribution, we discussed the issues of AI/ML for positioning accuracy enhancement. Observations and proposals are summarized as following:
Observation 1:	The definition of the “offset” existing in the agreement of definition of Rel-19 enhanced measurement is unclear.
Observation 2:	According to the definition of enhanced measurement, the first detected path will not be reported, since only the samples in the grid time will have the chance to be reported.
Observation 3:	The inconsistent values of Nt between gNB used and LMF signalled will cause the inconsistent list of consecutive channel response values that used to select the reported sample in Rel-19 enhanced measurement, and thus may result in the inconsistent reported measurement between gNB determined and LMF expected.
Observation 4:	The timing/angle information derived from deployed AI/ML model is based on the assumption that this information is obtained in a ‘virtual’ LOS propagation ray.
Observation 5:	it is almost impossible that time stamp of Part A and Part B are same totally if they are generated by different entities, thus it is stiff to pair Part A and Part B with the same time stamp.
Observation 6:	The main different between Option A and Option B for model performance monitoring of AI/ML positioning Case 1 is whether the LMF provide ground truth label or assistance data for calculating label to UE.
Proposal 1:	The offset existing in the definition of Rel-19 enhanced measurement can be defined as:
•	Definition-1: this offset is the timing difference between the start time (i.e., the first detected path rounded down with timing granularity T) and the reference time (i.e., UL RTOA reference time T0+tSRS as defined in TS 38.215).
•	Definition-2: this offset is the timing difference between the first detected path and the reference time (i.e., UL RTOA reference time T0+tSRS as defined in TS 38.215).
•	Definition-3: this offset is the timing difference between the start time (i.e., the first detected path rounded down with timing granularity T) and the first detected path.
Proposal 2:	If the offset is the timing difference between the start time (i.e., the first detected path rounded down with timing granularity T) and the reference time (i.e., UL RTOA reference time T0+tSRS as defined in TS 38.215), there is no need to transmit this offset from gNB to LMF.
Proposal 3:	If the offset is the timing difference between the first detected path and the reference time (i.e., UL RTOA reference time T0+tSRS as defined in TS 38.215), there is no need to transmit this offset from gNB to LMF.
Proposal 4:	If the offset is the timing difference between the start time (i.e., the first detected path rounded down with timing granularity T) and the first detected path, there is no need to transmit this offset from gNB to LMF, unless the additional evaluations can prove the necessity and benefits of this transmission.
−	At least the variable offsets have no or feeble impact for consistency between training and inference.
Proposal 5:	For Rel-19 enhanced measurement, support one of the following options:
−	Option 1: the gNB always include the value of Nt as its measurement parameters in the descriptive information of channel measurement together with the channel measurement values.
−	Option 2: the gNB include the value of Nt as its measurement parameters in the descriptive information of channel measurement together with the channel measurement values only if the value of Nt used by gNB is less than what LMF signalled.
Proposal 6:	For case 1, it is up to UE implementation to determine whether use phase information as model input.
Proposal 7:	For case 3a, it is up to gNB implementation to determine whether use phase information as model input.
Proposal 8:	For case 3b, support to report phase information from gNB to LMF as model input.
Proposal 9:	For case 3a, there is no need to report LOS/NLOS indicator to LMF if the model output is timing/angle information.
Proposal 10:	For case 3a, support to report LOS/NLOS indicator associated with the timing/angle measurement, if this LOS/NLOS indicator is generated by AI/ML model and the timing/angle measurement is generated by legacy way.
Proposal 11:	Introduce a quality indicator for power information in channel measurement for generating model input.
Proposal 12:	Support reusing dedicated signalling to indicate the quality of timing, power, and phase(if existing) information respectively, when gNB reports its quality of channel measurement for case 3a.
Proposal 13:	For case 3a, support that the gNB reports the quality of LOS/NLOS indicator which is derived from the deployed AI/ML model.
Proposal 14:	A quality indicator should be defined for a data sample.
−	determine this quality indicator based on the quality indicator(s), if available, of associated measurement and ground truth label jointly.
Proposal 15:	Data generation entity can initially report the data fulfilling the quality indicator threshold and then reports supplemental data in case that previously reported quality data is not adequate.
Proposal 16:	Use "UTC time + SFN + slot index" as a baseline, with details FFS
Proposal 17:	Consider following two options as baseline to design the time stamp for channel measurement in case 3b:
Proposal 18:	Pair the Part B with Part A whose time stamp around the time stamp of this Part B.
−	A threshold is needed to indicate whether a Part A and a Part B can be paired. If the timing difference between the time stamp of Part A and the time stamp of Part B exceed this threshold, this Part A and Part B cannot be paired.
Proposal 19:	Specify the pairing quality for measuring the timing difference between the time stamp of Part A and Part B, if pairing operation for this Part A and Part B is required.
Proposal 20:	A valid duration of Part B could be defined as a duration from time instance when obtaining Part B to the time stamp of Part B.
Proposal 21:	The valid duration of Part B could be used to improve the pairing between Part A and Part B.
Proposal 22:	Predefined a time stamp to indicate the case that the Part B is long-term valid.
Proposal 23:	RAN1 decides how to pair Part A and Part B based on the timestamp based on below three preliminary options:
−	Option 1: LMF provides multiple sets of Part B to UE, and UE selects the most associated one to pair with Part A.
−	Option 2: UE transmits a Part B request to LMF with a time stamp of Part A.
−	Option 3: LMF requests DL PRS transmissions at a predefined timing to gNB.
	Support the main bullet of both Option A and Option B for case 1, i.e., both LMF and UE can perform monitoring metric calculation.
Proposal 24:
Proposal 25:	Prioritize Option A-3 if performs monitoring metric calculation at the target UE side. Option A-1 and Option A-2 can also be applied as supplementary methods.
Proposal 26:	Prioritize Option B-2 if performs monitoring metric calculation at the target LMF side. Option B-1 can also be applied as supplementary methods.
Proposal 27:	For label-free methods and self-monitoring, at least the way to align the monitoring result in LMF side, especially when the UE reports inappropriate for the inference, should be specified, if the monitoring decision is determined up to UE implementation fully.
Proposal 28:	Support Alternative 1 and Alternative 2 for ensuring consistency in aspect of TRP location(Info #7).
−	Alternative 3 can also be supported only if it is common understand that TRP location is fixed across training data collection and inference data collection.
Proposal 29:	Support to introduce associated ID as an implicit way to ensure consistency between training and inference for AI/ML based positioning. Further study on:
−	Associated ID related to the additional conditions for one TRP/gNB separately or for multiple TRPs/gNBs jointly.
Proposal 30:	Support to introduce validity area to ensure the consistency between training and inference for UE side model.
−	The legacy AreaID-CellList specified in TS37.355 can be reused as the start point to specify the validity area.
Proposal 31:	For case 1, following three alternatives can be used as starting point to ensure the consistency between training and inference:
−	Alt.1: UE requests the expected metadata from LMF. UE can provide the expected metadata to LMF for UE side inference data collection based on the metadata for training data collection such that consistency between training and inference will be ensured.
−	Alt.2: LMF maintains the association between metadata and UE/model. LMF can ensure consistency between training and inference based on the maintained association.
−	Alt.3: UE maintains the association between metadata and model. UE firstly determine whether consistency is ensured and perform model inference accordingly.

3GPP TSG-RAN WG1 Meeting #120bis	R1-2502098
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.2
Source:	Tejas Networks
Title:	Discussion on AI/ML for positioning accuracy enhancement
Document for:	Discussion and Decision

Proposals
The proposals made in this document are consolidated below:
Proposal-1: The bitmap based approach should be considered for reporting the sample indices along with .
Proposal-2: We support the differential power reporting mechanism due to its flexibility.
Proposal-3: We propose that, for Case-3a, the timing information reported by the gNB should correspond to the time of arrival (ToA) of either the actual or the inferred non-existent LoS path, as determined by the AI-ML model.
Proposal-4: We propose that, for case-3a, a new LoS/NLoS indication should be reported by gNB to LMF that indicates the probability or likelihood that the reported timing information corresponds to the direct/LoS path.
Proposal-5: Inferring the legacy LoS/NLoS indication using AI-ML model and reporting it with legacy timing information should not be reported.
Proposal-6: We do not support the need to report legacy measurements for AI-ML-based positioning use cases. As a result, the need for distinction between legacy and enhanced reporting at LMF is unnecessary.
Proposal-7: The following contextual information should be reported during training data collection by the receiver:
PRS configuration
Validity area
SINR/SNR
PRS Beam related information
Proposal-8: It is important to discuss the association for scenarios where a single Part-B measurement is derived from multiple Part-A measurements.

Proposal-9: We support Alternative-1 indicating implicit reporting of info #7 (geographical coordinates of the TRPs served by the gNB).
Proposal-10: We propose that, for Case-3a, the receiver, during the model inference stage, should report a new LoS/NLoS indication that provides the likelihood that the reported timing information corresponds to the direct/LoS path between the UE and TRP.
Proposal-11: For supporting UE side MPM metric calculation, the assistance data should be provided by the LMF to the UE or TRP for Case-1 and Case-3a respectively.
Proposal-12: The range error or the positioning error should be considered as model performance metric for decision-making.
Proposal-13: Both the MPM metric calculation and the MPM decision should be taken at one entity which can be either LMF or UE/TRP for Case-1 and Case-3a respectively.
Proposal-14: The performance of the AI-ML models should be monitored periodically or aperiodically.

Observations
All the observations from this document are listed below:
Observation-1: The bitmap based approach is simpler and poses, on an average, the lower reporting overhead.
Observation-2: The fixed resolution for reporting the power of all the samples offer simplicity. On the other hand, the differential quantization resolution for reporting the dominant and non-dominant samples provides higher flexibility and may offer better positioning performance.
Observation-3: With AI-ML models, however, it is possible to infer even non-existent LoS ToA measurements through training. Therefore, when a receiver reports such measurements, a need may arise to redefine the measurements themselves.
Observation-4: In legacy systems, the LoS/NLoS indication provided the probability that a link was LoS or not. Applying this same definition in AI-ML scenarios may lead to confusion at the LMF, as the reported measurements might not effectively improve positioning accuracy.
Observation -5: The legacy LoS/NLoS indicator can be estimated with sufficiently good accuracy using traditional signal processing techniques and does not offer significant performance improvements in terrains with NLoS link profiles similar to InF-DH.
Observation-6: The data required to train such models would be collected using legacy methods, which have significant limitations, particularly in highly NLoS-dominated scenarios such as UMi and InF-DH.
Observation-7: Moreover, collecting accurate NLoS measurements in practice is extremely challenging. Therefore, the rationale for reporting NLoS measurements remains unclear to us.
Observation-8: We do not see a scenario where inferring legacy measurements would improve positioning performance, even if the inferred measurements were more accurate than the legacy ones.
Observation-9: The descriptive information alone might not be sufficient for site-specific efficient training. 
Observation-10: The receiver should also report information to associate context related to validity area, recency, implementation, link conditions etc.
Observation-11: UE position is estimated using channel or timing/angle information reported by multiple reference gNBs/TRPs. As a result, multiple Part-A measurements are used to infer or compute one or more Part-B measurements.
Observation-12: For the AI-ML models to work efficiently, the TRP/W and UE sided conditions should be same during training and inference phase.
Observation-13: The geographical coordinates of the TRPs served by the gNB contain sensitive information and should be protected, especially when stored on a third-party OTT server.
Observation-14: In legacy systems, the LoS/NLoS indication provided the probability that a link was LoS or not. Applying this same definition in AI-ML scenarios may lead to confusion at the LMF, as the reported measurements might not effectively improve positioning accuracy.
Observation-15: For both the Option-A and Option-B of case-1 and case-2a, the UE and TRP requires the assistance data for MPM metric calculation.
Observation-16: For supporting both the option-A and option-B, the definition of the model performance metric should be agreed.
Observation-17: Performing MPM at different entities requires significant specification impact.
Observation-18: The performance of AI-ML models may degrade over time due to various factors, such as mobility, environmental changes, or the network’s inability to accurately configure the validity area.

3GPP TSG RAN WG1 Meeting #120b	R1-2502116
Wuhan, China, April 7th – 11th, 2025
                                
Source:	Fujitsu
Title:	Discussion on specification support for AIML-based positioning
                 accuracy enhancement
Agenda item:	9.1.2 
Document for:	Discussion and Decision
1 

Conclusion
Observation-1: AI/ML-based positioning is mainly used in heavy NLOS scenarios and has a significant gain over the conventional methods in these scenarios. Due to the uncertainty of the first detected path matching the LOS path, providing additional information on the first path may not be helpful to the AI/ML positioning accuracy enhancement.
Observation-2: From Rel-18 SI evaluation results, adding phase information to CIR brings only negligible performance gains of AI/ML positioning accuracy but with significant overhead increasing.
Observation-3: Different understandings and considerations on the model output of Case 3a slow down the progress of study on Case 3a:
Multi-TRP construction: TOA, direct path TOA, LOS/NLOS indicator, etc.
Single-TRP construction: TOA, direct path TOA, LOS/NLOS indicator, etc.
Observation-4: For AI/ML based positioning Case 1, Info #7 cannot be provided explicitly from LMF to UE because:
The location information of the TRPs belongs to NW proprietary information and cannot be provided from LMF to UE
The location information of the TRPs is not the must-have information for the AI/ML model training and inference
Proposal-1: For Rel-19 enhanced measurement for Case 3b, RAN1 is suggested to study the measurement report format for the timing information of the Nt' values:
Alt-1: using the bitmap-based method 
Alt-2: reporting the time information for each of the Nt' samples based on legacy path-based reporting
Proposal-2: For Rel-19 enhanced measurement for Case 3b, if the bitmap-based method is supported, the following methods to decide the bitwidth of the bitmap should be decided:
Alt-1. The bitwidth of the bitmap is decided by Nt, where the value of Nt is the actual value used by gNB/TRP. 
Alt-2. The bitwidth of the bitmap is decided by Nt, where the value of Nt is based on LMF configuration. 
Alt-3. The bitwidth of the bitmap is decided by Nt, where the value of Nt is the one greater than and closer to the reporting Nt' in the supporting Nt values {32, 64, 128}.
Proposal-3 For Case 3b, wrt. whether transmit offset from gNB to LMF, it can be concluded as no need to introduce such offset in addition to timing information of the first detected path in the measurement report.
Proposal-4: Study on phase measurement and reporting for the model input of Case 3b is deprioritized in Rel-19 normative work.
Proposal-5: For the progress of the study on AI/ML assisted positioning Case 3a, the timing information in Rel-19 AI/ML measurement report is only for virtual line-of-sight link.
Proposal-6: For AI/ML assisted positioning Case 3a, the study on AI/ML-based LOS/NLOS estimation can be deprioritized in Rel-19 for both legacy measurement and/or Rel-19 measurement.
Proposal-7: For measurement report of AI/ML assisted positioning Case 3a, when timing information is reported from gNB to LMF
LMF shall be able to distinguish whether the timing information is for legacy measurement report or for AI/ML-based measurement report. 
It is up to RAN3 to decide how to ensure that LMF can distinguish between the two types of timing information.
Proposal-8: For AI/ML based positioning Case 1, info #7 cannot be provided from LMF to UE in an explicit way.
Alt-2 and Alt-4 can be excluded
Proposal-9: For AI/ML based positioning Case 1, the feasibility and necessity of using associated ID to indicate info #7 needs to be clarified considering the following aspects:
The feasibility of developing a generalized model based on the associated ID
The feasibility of developing and supporting associated ID specific model at UE/UE-side
Advantages of the associated ID over cell ID/GCI and area ID  
Proposal-10: Regarding UE-side model monitoring options for Case 1:
Option A-1 is supported considering the availability of the high-quality ground truth label at LMF
Option A-2 is not supported, unless the proponent companies can clarify how to generate the ground truth label via assistance information
Option A-3 can be supported, if the proponent companies can clarify how to align the input format between PRU measurement and AI/ML model
Proposal-11: Regarding LMF-side monitoring metrics calculation of Case 1:
Option B is supported to facilitate NW-side LCM including the positioning method selection between the AI/ML-based method and non-AI/ML-based methods  
Proposal-12: Regarding performance monitoring metric calculation in label-based monitoring of Case 3a, model LCM control/decision is suggested to be done by gNB/TRP for both Option A and Option B.
Proposal-13: Performance monitoring for case 3b can be realized by implementation and there is no need for further study
4 

3GPP TSG RAN WG1 #120bis	  R1-2502150
Wuhan, China, April 7th – 11th, 2025
Source: 	CMCC
Title:	Discussion on specification support for positioning accuracy enhancement
Agenda item:	9.1.2
Document for:	Discussion & Decision

Conclusions
In this contribution, we discussed potential spec impact for AI/ML positioning enhancement, and the following proposals are made.
Observation 1: There is no need to carry out duplicated discussions for the cases which may share the same or similar enhancements. 
Observation 2: For AI/ML model training, data collection can be performed offline with marginal specification impact.
Observation 3: Although the existing IE may can be reused, the implication may be different for sample-based measurement.
Observation 4: For performance monitoring without ground-truth label, specify detail method for monitoring metric may be difficult.
Observation 5: To make progress on the discussion, firstly check whether this information must be provided for ensure consistency between training and inference.

Proposal 1: For AI/ML based positioning, it needs more discussion on the feasibility of obtaining the ground-truth label via PRUs, in which case the training dataset size is large. 
Proposal 2: For AI/ML based positioning, more discussion is needed for the comparison between CIR and PDP as model inputs. 
Proposal 3: For AI/ML based positioning, additional configurations or limitations can be supported to improve the efficiency of the measurement data reporting for positioning. 
Proposal 4: For UE generates ground truth label based on non-NR and/or NR RAT-dependent positioning methods, the reliability or the positioning accuracy should also be reported.
Proposal 5: For AI/ML based positioning, whether the reported measurement is AI based could have an indication. 
Proposal 6: For AI/ML assisted positioning, existing IE “Timing Measurement Quality” can be reinterpreted for reporting performance metric for gNB side model.
Proposal 7: For performance monitoring is based on the ground-truth labels, further study method to obtain ground-truth label.
Proposal 8: For AI/ML based positioning, the relationship between model monitoring and positioning integrity can be considered. 
Proposal 9: For the content of monitoring outcome, in addition to above indication, the reason why the AI model fails to work should also be considered for reporting.
Proposal 10: Regarding the timing of the target UE reporting the monitoring outcome, both UE-initiated reporting and LMF-requested reporting can be supported, and LMF configured event-triggered reporting can also be discussed.
Proposal 11: It is necessary to distinguished AI based positioning from legacy UE positioning as a new UE capability.
Proposal 12: For UE-side AI based positioning, a new UE capability for the number of PRS resources should be defined.

3GPP TSG RAN WG1#120bis							    R1-2502194
Wuhan, China, April 07th –11th, 2025

Agenda item:	9.1.2
Source: 	Lenovo
Title: 	Specification impacts for AI/ML Positioning
Document for:	Discussion

Conclusion
The following observations are summarized as follows:
Observation 1: The selection of paths out a total number of received paths for path-based measurements is up to implementation.
The proposals in this contribution are summarized as follows:
Sample-based and Path-based timing information measurements.

Proposal 1: RAN1 to consider extending the agreed definition of sample-based measurements Cases 1 and 2b, in addition to path-based measurements. The following FFS need to be addressed:
Definition of the reference time for UE: The UE reference time of the beginning of the subframe is same as legacy.
Values of {Nt, Nt’, k}
UE capability(ies)

Proposal 2: RAN1 to consider the de-prioritization of the offset transmission from gNB to LMF for Case 3b in Rel-19.

Proposal 3: Nt may be included as part of the measurement parameters in the descriptive information if it is aligned with any of the recommended values requested by the LMF.

Proposal 4: RAN1 to conclude no enhancements for path-based measurements are foreseen in Rel-19.

Proposal 5: RAN1 to support the following additional sample selection rules for sample-based measurement: 
Sample selection between min and max path power.

Model Input Types

Proposal 6: RAN1 to support the following additional model input types for DL-based Direct AI/ML positioning measurements based on DL-PRS:
Support channel observation measurements in the form of DL CIR measurements 

Proposal 7: RAN1 to support the following additional model input types for UL-based Direct AI/ML positioning measurements for case 3b based on SRS for positioning:
Support channel observation measurements in the form of UL CIR measurements 
Support the inclusion of additional channel profiles such as UL-based angle-delay domain (paired angle/phase and timing information).

Proposal 8: Support the re-use of legacy positioning measurements as model input types for the following Direct AI/ML positioning cases to derive a fingerprint:
Case 1, 2b (DL-based): Support DL-RSTD, UE Rx-Tx time difference, DL-PRS RSRP/RSRPP measurements
Case 3b (UL-based): Support UL-RTOA, gNB Rx-Tx time difference, UL-AOA and SRS RSRP/RSRPP measurements
Note: The above legacy measurements may be considered in conjunction with channel observation measurements.

Reference Timing Information
Proposal 9: For Case 3b, support the use of paired gNB Rx-Tx time difference and UE Rx-Tx time difference measurements (Multi-RTT) for the LMF-side model.


AI/ML Data Collection Aspects

Proposal 10: Channel measurement in Part A of a Training Data samples is to be defined according to a new/existing DL or UL channel measurements that are/may be specified in TS 38.215, including the measurement of the paired timing information and power information.

Proposal 11: The content of ground truth label and related data may at least comprise of:
For Cases 1, 2b:
PRU UE location information, PRU UE location uncertainty, PRU UE location timestamp.
For Case 2a:
PRU UE LOS/NLOS indicator associated to the positioning measurement, timestamp associated to LOS/NLOS measurement.
For Case 3a:
PRU UE LOS/NLOS indicator associated to the positioning measurement, PRU UE location of SRS transmission, timestamp associated to LOS/NLOS measurement and PRU UE SRS Tx location, PRU UE location uncertainty
For Case 3b:
TRP Location and PRU UE location of SRS transmission, timestamp associated PRU UE SRS Tx location, PRU UE location uncertainty.
NOTE1: Determination or transfer of the ground truth label and related data may be up to other WGs.

Proposal 12: Depending on the UE mobility, e.g., stationary or mobile, RAN1 to support additional information in the form of a label validity indication, which includes label quality validity indication. 
FFS how to model label validity indication, which includes label quality validity indication, e.g., with label validity time period/duration.

Proposal 13: Support indications to provide only Part A (unlabelled) or Part A and Part B (labelled indication) of the training data sample from the requesting entity, e.g., entity/node training the AI/ML model. Existing LPP/NRPPa signalling may be used to provide labelled/unlabelled data indication to different PRUs/UEs/network entities.

Training and Inference Consistency

Proposal 14: RAN1 to support Alternative 2 for signalling Info #7 – Geographical coordinates from LMF to UE. FFS details related to the associated ID definition e.g., number of IDs and size of the IDs.

Proposal 15: RAN1 to support explicit or implicit signalling of Info#16 on TRP beam/antenna information assistance data elements, where if provided implicitly, an associated ID may be used to implicitly signal Info#16.

Training and Inference Data Transfer

Proposal 16: Consider the specification of data request and data collection for the enhanced positioning accuracy use case by considering outcomes in the ongoing RAN2 study, and taking into account the following scenarios:
Scenario 1 - LMF-side Model Training: Positioning training dataset transfer is performed using existing 3GPP-signaling, e.g., LPP/NRPPa signalling
Scenario 2 - UE-side Model Training: Positioning training dataset transfer is performed without specification impact using non-3GPP technologies, e.g., proprietary signalling/OAM signalling. In this case training may be performed at the UE or on OTT/OAM side.
Scenario 3 - gNB-side Model Training: Positioning training dataset transfer is performed without specification impact using non-3GPP technologies, e.g., proprietary signalling/OAM signalling. In this case training may be performed at the gNB or on OTT/OAM side.

Data Construction/Generation Entity
Proposal 17:  RAN1 to consider the following principles between training entity and training data construction/generation:
Option 1: Training entity is the same entity to generate the training (measurement) data, e.g., may be applicable to Cases 1, 2a, 3a
Option 2: Training entity is not the same entity to generate the training (measurement) data, e.g., may be applicable to Cases 2b, 3b.
Option 3: Both Option 1 and Option 2.

Proposal 18: RAN1 to confirm the following working assumptions on training data generation in relation to measurement and related data:
For training data generation of AI/ML based positioning Case 1, the measurement and its related data (e.g., timestamp) are generated by PRU and/or Non-PRU UE.
For training data generation of AI/ML based positioning Case 2a and 2b, the channel measurement and its related data (e.g., time stamp) are generated by PRU and/or non-PRU UE.

Proposal 19: RAN1 to confirm the following working assumptions on training data generation in relation to label and its related data:
For training data generation of AI/ML based positioning Cases 1, 2a and 2b , the label and its related data (e.g., time stamp) can be generated by: 
PRU
Non-PRU UE with estimated location
LMF 
Note: transfer of the label and its related data is out of RAN1 scope..
For training data generation of AI/ML based positioning Cases 3b , the label and its related data (e.g., time stamp) can be generated by:
PRU
Non-PRU UE with estimated location
LMF
Note: transfer of label and its related data is out of RAN1 scope.
Note: It is assumed that user data privacy of non-PRU UE is preserved.
Note: Previous related working assumption made in RAN1#116bis for training data generation of AI/ML based positioning Case 3b will not need to be confirmed.

AI/ML Model Monitoring

Proposal 20: Content of model monitoring outcome/result is reported per AI/ML model or functionality deployed at the UE-side and can be based on the horizontal/vertical positioning accuracy or a hard/soft indicator.

Proposal 21: RAN1 to support the use of the LPP RequestLocationInformation / ProvideLocationInformation message framework to retrieve the model monitoring outcome/result in a solicited or unsolicited manner.
NOTE: The UE may reply with the unavailabilty of the monitoring outcome/result if the UE does not wish to share the monitoring outcome/result.

Proposal 22: For Option A-1, where information on ground truth label of the target UE is generated by LMF to aid with Case 1 model performance monitoring, RAN1 to introduce support for a signalling mechanism for a UE to request and retrieve ground truth label information generated at an LMF. RAN2 to decide whether new or existing can support the transfer of ground truth information from LMF to UE.

Applicable Functionality Reporting

Proposal 23: Supported functionalities are essentially UE capabilities, which according to RAN1 may be static and/or dynamic depending on UE conditions and network configuration.

Proposal 24: The inference positioning configuration, e.g. DL-PRS is provided using the LPP ProvideAssistanceData message.

3GPP TSG-RAN WG1 Meeting #120bis	  R1-2502211
Wuhan, China, April 7 – 11, 2025

Agenda Item:	9.1.2
Source:	Huawei, HiSilicon
Title:	Discussion on AI/ML for positioning accuracy enhancement
Document for:	Discussion and Decision

Conclusions
In this contribution, we have the following observations and proposals.
Model input
Observation 1: There is no need for the gNB to transmit to the LMF any offset related to the determination of the starting time.
Observation 2: The value of  used by the gNB is not necessary for determining the model input due to the following reasons:
The LMF can have a single model implementation, generalizing over different values of  used by the gNB.
A smart gNB will not artificially select a shorter value of , if there are still strong values outside the selection window.
The operator will deploy gNBs which can appropriately determine  needed for training of LMF side model.
Proposal 1: For the enhancement of path-based measurement for Case 3b, do not support the reporting of the value of used by the gNB.
Proposal 2: For the enhancement of path-based measurement for Case 3b, the gNB can use any value of 24 for the measurement reporting.
Model output for assisted positioning
Proposal 3: For Case 3a, LOS/NLOS indicator can reuse the same format and definition as the existing IE “LoS/NLoS Information” in 38.455.
Proposal 4: When the LOS/NLOS indicator subject to Rel-19 type is reported, the LOS/NLOS indicator may be reported with other accompanied measurement information, e.g., legacy measurement information (e.g., timing information, AOA), or Rel-19 type timing information.
Note 1: Case 3a based LOS/NLOS indicator reuses the legacy meaning, i.e., likelihood of a line-of-sight propagation path for the channel, regardless of the type of other accompanied measurement information.
Note 2: Any combination of legacy/Rel-19 type based LOS/NLOS indicator and other accompanied measurement information (e.g., legacy/Rel-19 type based timing information) do not mutually conflict on their interpretations when jointly reported.
Proposal 5: When reporting Rel-19 type timing information, the report of the LOS/NLOS indicator should be “optional”.
Proposal 6: For Case 3a, to distinguish the reported Rel-19 type timing information from the legacy measurement-based timing information, consider the following alternatives
Alt.1: Reuse the timing quality indicator, where reported timing information of Case 3a can be represented with high timing quality and NLOS.
Alt.2: Introduce a Rel-19 type indicator to tell that the report is subject to measured (legacy) timing information or non-measured (Rel-19) timing information.
Model training
Proposal 7: For data collection of Case 3b, the quality indicator of timing information in Part A when reported is reusing the legacy principle:
One quality indicator of the timing information is associated and optionally reported with the measurements of each reported path.
Proposal 8: For Case 3a, the label of the LOS/NLOS information generated from LMF can be in forms of the expected likelihood of a LOS propagation path from a TRP to the target device.
Proposal 9: For Case 3a, the label of the timing information generated from LMF can be in forms of the ToF/propagation delay between the TRP and the PRU.
Note: The provision of this label may not cause additional user privacy issue on top of legacy positioning.
Proposal 10: For Case 1 data collection, when Part A is generated by the PRU or UE and Part B is generated and delivered by the LMF, to enable the pairing of Part A and Part B at UE side, legacy reporting can be reused for indicating the time stamp of Part B, i.e., it is based on the optional UTCTime.
Proposal 11: For Case 1 data collection, do not support sending Part A from UE to LMF, since model input type for Case 1 should be UE proprietary implementation. 
Otherwise, if model input type is specified, e.g., by adopting enhanced path based measurement similar to Case 3b, it would strongly restrict the UE implementation flexibility of the model input type and consequently harms the performance.
Proposal 12: For Case 3a data collection, do not support sending Part A from gNB to LMF, since model input type for Case 3a should be UE proprietary implementation.
Otherwise, if model input type is specified, e.g., by adopting enhanced path based measurement similar to Case 3b, it would strongly restrict the gNB implementation flexibility of the model input type and consequently harms the performance.
Observation 3: For Case 3a data collection, if the gNB is not aware of the time instance T0 when Part B is expected to be generated at the LMF in advance, it may fail to generate the measurements corresponding to T0 since it receives the Part B from LMF at a later T1.
If gNB is supposed to store all measured Part A during the data collection phase, it will incur higher gNB complexity on storage.
If gNB is supposed to do the measurement for Part A at T2 later than T1, Part A subject to T2 may be mis-aligned with the delivered Part B subject to T0.
Proposal 13: For Case 3a data collection, when Part A is generated by the gNB/TRP and Part B is generated by the LMF, to enable the pairing of Part A and Part B at gNB side, the LMF indicates to the gNB the anticipated time stamp in which Part B is expected to be generated.
The gNB can perform channel measurement to derive and store Part A according to the anticipated time instance for Part B, and pair Part A with Part B after Part B is delivered.
Proposal 14: For Case 3a data collection, it is not clear on the motivation to indicate that Part B is valid for a duration.
Observation 4: For Case 3b, the pairing of Part A and Part B can be done by implementation at the LMF.
Proposal 15: For Case 3b, if Part B is delivered from the UE/PRU to the LMF, support that the time stamp of the label can be based on the legacy reporting, i.e., via IE “MeasurementReferenceTime”.
Consistency between training and inference with NW-side information
Observation 5: For Case 1, the actual TRP locations (i.e., Alternative 4) are not explicitly needed for the inference of the UE location.
Observation 6: The necessity of introducing associated ID (Alternative 1/2) is not clear due to the following reasons:
The change of locations of TRPs are highly infrequent.
Even if the locations of the TRPs change, the UE side can become aware of that based on its own monitoring or via LMF request, and perform the retraining of the model accordingly.
The LMF can indicate the change of the NW side additional condition by reusing other IEs, e.g., validity area (Info #13), spatial direction information (Info #6), etc.
Observation 7: For the definition of the associated ID, it is not clear whether a single associated ID is associated with the location of a single TRP or with the locations of multiple TRPs.
Observation 8: The introduction of an associated ID linked to a single TRP or to multiple TRPs faces several problems:
If one associated ID is linked with a single TRP or multiple TRPs, the training of a large number of models at the UE may be inevitable for combinatorial TRP locations, which inflicts UE side burden.
If one associated ID is linked with multiple TRPs, model retraining at UE side may anyway be inevitable with the change TRP locations since UE cannot identify whether other NW side conditions/additional conditions also change in together.
Proposal 16: Support Alternative 3. Info #7 is not provided from LMF to UE. 
Proposal 17: For Case 1, there is no need to provide the assistance information for UE-based DL-AOD from LMF to UE, since the assistance information provided for UE-based DL-TDOA suffices for ensuring training and inference consistency.
Model monitoring
Proposal 18: Label-free monitoring should be up to implementation.
Observation 9: It has been concluded in RAN1#118 that model monitoring can be realized by implementation (if the PRU sends information to the target UE side in a proprietary method), therefore it is not clear whether further monitoring methods with specification impact need to be agreed. 
Observation 10: Label-based model monitoring for Case 1 based on PRU locations can ensure more accurate label.
Proposal 19: For label-based model monitoring Case 1, there is no need to involve the LMF for metric calculation (i.e., Option B-1 and Option B-2), as the LMF may not have the knowledge to monitor/manage the UE-side models.
Proposal 20: For label-based model monitoring Case 1, deprioritize options which need to restrict the model input which should be up to UE implementation (i.e., Options A-3 and Options B-2).
Proposal 21: For label-based model monitoring Case 1, the UE indicates the monitoring outcome by sending the deactivation request to LMF.
Proposal 22: For performance monitoring of AI/ML positioning Case 3a, the report of a measured or non-measured result can be used to imply the activation/fallback between LMF and gNB.
E.g., for Option A:	NG-RAN node performs monitoring metric calculation, gNB can report LMF with measured result (implying fallback) or non-measured result (implying activation).
Proposal 23: For performance monitoring of AI/ML positioning Case 3a, no need to specify the type of metric, i.e., the monitoring entity can calculate the metric by implementation.
Proposal 24: For model monitoring in Case 3b, no further assistance information or measurement report in addition to what is needed for inference is required to be sent to the LMF.

3GPP TSG RAN WG1 #120bis		R1-2502289
Wuhan, China, April 7th – 11th, 2025

Source:	OPPO
Title:	On specification for AI/ML-based positioning accuracy enhancements
Agenda Item:	9.1.2
Document for:	Discussion and Decision

Conclusions
In this contribution, we discussed the specification impacts and the potential detailed design case by case from the following aspects:  
Consistency between the training and inference
Potential enhancement for measurement
Data collection for AI model training
AI model inference
Functionality/model performance monitoring
Functionality/model management
Functionality/model identification and applicable functionality/model
Based on the above discussion, we have the following observations and proposals for the five AI-based positioning cases (i.e., Case 1, Case 3a and Case 3b): 
Observation 1: For UE-based positioning with UE-side model (Case 1) and NG-RAN node assisted positioning with gNB-side model (Case 3a) 
The AI model may be not workable temporally due to various factors (e.g., power consumptions)
It is beneficial to tell the NW whether the reported result(s) is based on AI method or non-AI method.
Observation 2: For UE-based positioning with UE-side model (Case 1) and NG-RAN node assisted positioning with gNB-side model (Case 3a) 
The measurement/indication of the quality of reported results that are based on AI model may be different compared to the legacy measurement results. 
Observation 3: Regarding the Option A for model performance monitoring of AI/ML positioning Case 1, 
Option A-1, Option A-2 and Option A-3 are feasible in specific scenarios.
Proposal 1: For AI/ML based positioning Case 3b, Nt is included in the measurement parameters of descriptive info for Rel-19 enhanced measurement.
Proposal 2: For Rel-19 AI/ML based positioning, for enhanced measurement of Case 3b,
If the Nt', Nt and/or k values chosen by gNB/TRP are different from the Nt', Nt and/or k values signalled by the LMF:
The Nt', Nt, k values chosen by gNB/TRP are within the values supported by specifications
Proposal 3: Transmit offset from gNB to LMF is not needed for AI/ML positioning Case 3b.
Proposal 4: For R19 AI-based positioning, NOT support the reporting based on phase information (in additional to timing information and power information).
Proposal 5: Regarding the consistency of training and inference for AI/ML based positioning of Case 1, the method(s) only based on “validity area of model training” and “validity area of model inference” is not workable for practical deployment since
It can only differentiate the AI models applicable for different areas
It cannot differentiate the AI models applicable for different times in the same areas (e.g., before and after some NW optimization operations)
Proposal 6: For AI/ML based positioning of Case 1, some indication (e.g., in form of associated ID) is signaled from network to ensure the consistency of AI model training and AI model inference (e.g., consistency on NW-sided conditions / additional conditions)
e.g., the ID can be a special ID for positioning configurations, and can be indicated to differentiate the associated training data
The proprietary information of network should not be disclosed.   
Proposal 7: For AI/ML based positioning Case 1, Geographical coordinates of the TRPs served by the gNB (Info #7) from legacy UE-based DL-TDOA is provided implicitly via associated ID.
Either Alternative 1 or Alternative 2  is supported.
Proposal 8: 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.
For info #7, the consensus reached for legacy UE-based DL-TDOA method can be reused.
Proposal 9: Regarding the training data collection at UE side for Case 1 
Reuse the legacy LPP signaling to configures UE with the corresponding positioning RS for UE-side data collection 
The associated ID is signaled along in order to facilitate the insurance of the consistency between training and inference. 
No additional signaling/triggering is needed from network to start the data collection procedure at UE side.
The format/content of collected data are up to implementation of UE and no specification is needed in 3GPP 
Proposal 10: Regarding the training data collection for NG-RAN node assisted positioning with gNB-side model (Case 3a)
gNB do measurement based on SRS 
The existing procedure/mechanism can be reused for this purpose
gNB can decide itself when/how to start the data collection procedure.
The contents of collected data are up to implementation and no specification is needed in 3GPP
LMF delivers ground-truth label(s) (or the information based on that the label can be derived)  to gNB via NRPPa siganling
gNB needs to send request to LMF on what the groud-truth label (or the information based on that the label can be derived) is 
Proposal 11: For training data collection at NW side for NG-RAN node assisted positioning with LMF-side model (Case 3b), support the following mechanisms 
gNB reports measurement results (corresponding to model input) and the associated timestamps via NRPPa protocol
The corresponding label(s) can be reported optionally or LMF generates the associated labels based on the know location of the corresponding PRU 
NRPPa signaling from LMF to indicate gNB
The type of measurement results
How to report the collected data (e.g., periodic reporting, event-triggered reporting)

Proposal 12: For AI-based positioning (including Case 1, Case 3a, Case 3b), Rel-19 is NOT to specify any mechanism to deliver the collected data from the entity that obtains the training data to the training entity when the training entity is not the same entity to obtain label and/or other training data.  
Proposal 13: For case 1, if Part B is sent from LMF to PRU or non-PRU UE, both IEs as described in TS 37.355 are included in the time stamp:
NR-TimeStamp
UTCTime
From RAN1 perspective, UTCTime can be an optional field
Note: NR-TimeStamp and UTCTime are intended to refer to the same clock time associated with the label in Part B.

Proposal 14: For Case 1, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the followings are needed:
The time stamp of Part A and the time stamp of Part 
Additional information: the valid duration between time stamp of Part A and time stamp of Part B
Proposal 15: For Case 1, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed in addition to the time stamp of Part A and the time stamp of Part B
Additional information: the valid duration between time stamp of Part A and time stamp of Part B
Proposal 16: For the model inference for UE-based positioning with UE-side model (Case 1),
The associated ID is signaled from network to ensure the consistency of AI model training and AI model inference
No need to specify the format/contents of AI model input since they are up to UE implementation and transparent from the perspective of air interface
UE can report the estimated location information via existing LPP signaling
Introduce new information to indicate the reported results are generated by legacy method or AI-based method
FFS: whether the current field about the uncertainty can be reused or some new field/IE should be introduced to report the associated quality/probability/confidence of AI model estimated location
Proposal 17: For the model inference for NG-RAN node assisted positioning with gNB-side model (Case 3a),
No need to specify the format/contents of AI model inputs since they are up to gNB/TRP implementation and transparent from the perspective of air interface
gNB can report the measurement results that are based on AI model output via existing NRPPa signaling
Introduce new information to indicate the reported results are generated by legacy method or AI-based method
Proposal 18: For Case 3a measurement reporting, following combinations are supported:
Timing information is generated by AI/ML;
LOS/NLOS indicator is generated by AI/ML, and timing information is generated by legacy positioning method;
LOS/NLOS indicator is generated by legacy method, and timing information is generated by AI/ML;
LOS/NLOS indicator and timing information are both generated by AI/ML.
Proposal 19: when the LOS/NLOS indicator is reported for Rel-19 Case 3a, and the associated timing information is obtained by legacy positioning methods or by AI/ML,
The LOS/NLOS indicator can reuse the meaning and format of the existing IE “LoS/NloS Information” in 38.455, which can be soft indicator or hard indicator.
Proposal 20: For the model inference for NG-RAN node assisted positioning with LMF-side model (Case 3b)
gNB/TRP can do the measurement and report the results via existing NRPPa signaling
The existing measurement types are reused
FFS: whether or not to introduce new values (N) for the maximal number of additional paths (e.g., N > 8).
Proposal 21: For functionality/model performance monitoring, Rel-19 is NOT to specify dedicated specification enhancement for the mechanism without ground-truth labels
Functionality/model performance monitoring without ground-truth labels can be done by implementation without any specification enhancement
Note: we also categorize some mechanisms based on “the approximate ground-truth label” in to that without ground-truth labels.
Proposal 22: Regarding the options for model performance monitoring of AI/ML positioning Case 1, further study the following options (including the feasibility)
Option A-1 
Option A-3 
If above Options are supported, there should be separate UE capabilities for them 
Proposal 23: Regarding the Option B for model performance monitoring of AI/ML positioning Case 1, 
For Option B-1, there is no additional spec impact and it is not clear how LMF use this information for monitoring metric calculation
The feasibility of Option B-2 is not justified.
Proposal 24: For model performance monitoring of AI/ML positioning Case 1, the content of monitoring outcome includes at least:
Suggested monitoring behavior
FFS: positioning accuracy
Proposal 25: For model performance monitoring of AI/ML positioning Case 1, the target UE reports monitoring outcome at least
When the target UE receives an LMF request and monitoring outcome is provided in UE response; Or
When the target UE performs monitoring metric calculation and detects the target UE cannot perform the AI/ML based positioning method.
Proposal 26: For NG-RAN node assisted positioning with gNB-side model (Case 3a), in order to facilitate ground-truth-label-based functionality/model performance monitoring at gNB, support the enhancement on NRPPa signaling to enable the delivery of the ground-truth label or the information that can derive the ground-truth label from LMF to gNB
Functionality/model performance monitoring can be done by gNB implementation 
Proposal 27: For NG-RAN node assisted positioning with LMF-side model (Case 3b), Rel-19 is NOT to specify dedicated specification enhancement for functionality/model performance monitoring at LMF
Functionality/model performance monitoring can be done by LMF implementation without impact on NRPPa signaling
Proposal 28: For UE-based positioning with UE-side model (Case 1)
The functionality/model can be activated or disactivated by LPP signaling, which is the same as the legacy positioning procedure
UE can autonomously deactivate the AI operations and fall back to the legacy operations
UE reporting includes some field/IE to indicate whether the results are based on legacy operation or AI model output.
Proposal 29: For UE-based positioning with UE-side model (Case 1), specify the UE capability signaling to report the supported configuration(s) associated with given functionality(ies)
E.g., DL-PRS resources capability, DL-PRS Processing capability, measurement capability
Proposal 30: For UE-based positioning with UE-side model (Case 1), UE can report the applicable functionalities by sending a ProvideCapabilities message to the LMF (namely, triggering the capability indication procedure of TS 37.355)
FFS: whether some enhancement is needed to reduce the signaling overhead

3GPP TSG RAN WG1 Meeting #120bis		R1-2502310
Wuhan, China, April 7th – 11st 2025

Agenda Item: 	9.1.2
Source: 	Sony 
Title: 	Support for AI/ML for positioning accuracy enhancement
Document for: 	Discussion & Decision

Conclusion
In this contribution, we provide our views various aspects to support AI/ML for positioning accuracy enhancements. The proposals are listed below.
Proposal 1: For data collection, support radio channel characteristics reporting in a form of channel impulse response (CIR) (e.g., power, time, and phase information) for AI/ML positioning.
Proposal 2: Support configurable CIR measurement report (e.g., report size, measurement window size) in an effort to reduce the signalling overhead.
Proposal 3: if Part A and Part B are generated by different entities, the pairing of part A and part B in the collected data sample  can be based on timing information (e.g., time stamp) or location information.
Proposal 4: Support sample-based measurements as the AI/ML model input for Case 2b.
Proposal 5: For AI/ML assisted positioning case 2a and case 3a, support an indication whether the positioning measurement is based on AI/ML computation or not.
Proposal 6: Define a set of parameters (e.g., part/all of DL-PRS configuration, received signal quality, etc) representing reference signal characteristics to be used for AI/ML positioning.
Proposal 7: For ensuring the AI/ML model consistency between the training and inference operation, support the association of the reference signal (e.g., DL-PRS) characteristics to the trained AI/ML model and AI/ML model inference operation.
Proposal 8: Further study the signalling procedure to ensure the consistency between AI/ML training and AI/ML inference.
Proposal 9: For case 1, support LMF to provide the UE with AD-IE-Group2 (NW-side additional condition).
Proposal 10: For model performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring, Option A-1, A-2, A-3 are supported in Rel-19.
Proposal 11: For case 3a and with option B, support LMF to provide an indication of AI/ML model validity (e.g., based on the monitoring outcome) to NG-RAN node.
Proposal 12: For case 1 and case 3a with option A, UE or gNB to provide an indication of AI/ML model validity (e.g., based on the monitoring outcome)  to the AI/ML server/management (e.g., LMF).

3GPP TSG RAN WG1 #120bis		R1-2502353
Wuhan, Hubei, China, April 7th – 11th, 2025
Agenda Item:		9.1.2
Source:				Samsung
Title:					Discussion for supporting AI/ML based positioning accuracy enhancement
Document for:	     Discussion

Conclusion
For Rel-19 AI/ML based positioning Case 3b, 
If the gNB cannot report measurements according to measurement type (A) or measurement type (B) requested by LMF, the gNB responds to LMF that: the gNB cannot provide measurement with the requested measurement type. 
The gNB does not respond to LMF with a measurement report where the measurement type is different from requested.
It is up to RAN3 to decide the signaling details.
Note: It is RAN1 understanding that this is the same behavior as in legacy when the NG-RAN node cannot support the requested measurement.
Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.
Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25

3GPP TSG RAN WG1 Meeting #120-bis 	R1-2502412
Wuhan, China, April 7th – 11th, 2025

Source:	   RUijie networks
Title:	   Discussion on specification support for positioning accuracy enhancement
Agenda Item: 	   9.1.2
Document for: 	Discussion and decision

Conclusions
In this contribution, we have presented our views on specification support for positioning accuracy enhancement. Based on the discussions in the previous sections we propose the following: 
Proposal 1: For Rel-19 AI/ML based positioning, for Case 3b, no transmit offset is transmitted from gNB to LMF. 
Proposal 2: For measurement report of AI/ML assisted positioning Case 3a, when timing information is reported from gNB to LMF, LMF does not need to distinguish the meaning/content of the reported timing information (i,e,, whether it is legacy timing measurement or Rel-19 enhanced timing measurement).
Proposal 3: For AI/ML based positioning, regarding the time stamp of channel measurement generated by TRP/gNB,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.
Existing IEs as described in TS 37.355 should be included in the time stamp. 
Proposal 4: 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. For info #7, support Alternative 1 or Alternative 2:
Alternative 1. Info #7 is provided implicitly via associated ID.
Associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference.
Alternative 2. Info #7 can be provided either implicitly or explicitly by LMF. Note: no UE capability is introduced on whether info #7 is provided implicitly or explicitly, and the UE can request info #7 to be provided explicitly or implicitly.
If provided implicitly, associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference.
Proposal 5: Regarding label-free methods and self-monitoring, they are up to implementation and out of 3GPP scope.
Proposal 6: For model performance monitoring of AI/ML positioning Case 1, for model performance monitoring metric calculation in label-based model monitoring, support Option A-3 as a baseline to generate information on ground truth label.
Option A-3. Reuse Rel-18 assistance data transfer framework from LMF to the target UE, where the PRU measurement (e.g., legacy measurement) and the corresponding PRU location are sent via LMF to the target UE. 
Proposal 7: For model performance monitoring of AI/ML positioning Case 1, the target UE reports monitoring outcome at least
When the target UE receives a LMF request and monitoring outcome is provided in UE response;
FFS other cases. 

3GPP TSG RAN WG1 #120bis			R1-2502431
Wuhan, China, April 07th – 11th, 2025

Source: 	     Xiaomi
Title:	Discussion on AI/ML-based positioning accuracy enhancement
Agenda item:    9.1.2
Document for:  Discussion

Conclusion
In this contribution, we mainly discussed the remaining issues for Case 1, Case 3a and Case3b. 

The proposals for Case 1 are summarized as follows: 

Proposal 1: For the indication of info#7, consider Alternative 4 or Alternative 1. 
Proposal 2: For the performance monitoring in Case 1
Prioritize Option A-2
Consider Option A-3 as one complementary approach if the PRU is available and the measurement of PRU is the same as input of Case 1
Proposal 3: For the report the performance monitoring outcome 
Consider the applicability report of the functionality as the monitoring outcome 
Support the proactive report manner and Reactive report manner 
Consider the agreed applicable functionality report manners in RAN2 as baseline. RAN2 decide whether additional enhancement is performed or not 
Proposal 4: There is no need to define the occupied number of AI processing units and corresponding occupation time for AI-based positioning 

The proposals for Case 3a are summarized as follows:

Proposal 5: For Case 3a, 
RAN1 confirms that it is beneficial for LMF to know the intermediate parameters are generated by AI/ML
The detailed notification manner is up to RAN3 

The proposals for Case 3b are summarized as follows :

Proposal 6: For the parameter Nt
LMF should know the determined Nt on gNB side 
Only when gNBs use Nt different from LMF configuration, gNBs include it explicitly in the measurement parameters. 
Proposal 7: For the indicating of Nt’ samples, reuse the indication principle of the Path-based report 

3GPP TSG RAN WG1 #120bis	R1-2502502
Wuhan, China, April 7th – Nov 11th 2025
Agenda item:	9.1.2
Source: 	ETRI
Title:	Discussion on specification support for positioning accuracy enhancement
Document for:	Discussion

Conclusion
In this contribution, our views on AI/ML positioning accuracy enhancement were shown and the following observations and proposals were made:

Proposal 1: Adopt an offset in enhanced measurement for Case 3b.
The offset represents the timing relative to the reference time, with a resolution step of T = 2k x Tc 
The gNB delivers the offset to the LMF
The LMF does not need to send the offset to the gNB

Proposal 2: For Case 2a and 3a, the timing information output from the model should be used independently, without incorporating the LOS/NLOS indication.

Proposal 3: For Case 2a and 3a, the LOS/NLOS indicator output from the model should be incorporated with the legacy timing measurement. 

Proposal 4: Reuse existing IEs for the quality indicators of measurements and labels.
Proposal 5: For AI/ML positioning, the quality indicator of channel measurement should reflect the quality of both time and gain.

Proposal 6: For the time stamp of channel measurements and labels, reuse existing IEs such as
NR-TimeStamp-r16 in TS37.355, with the addition of UTCTime
TimeStamp in TS38.455 

Proposal 7: Optionally add the UE(PRU)-ID to both Part A and Part B for pairing purposes.

Proposal 8: Introduce dataset-ID for dataset classification
The dataset-ID may include assistance information and an associated-ID.
The dataset-ID may be part of the model ID. 

Proposal 9: For the AI/ML positioning model, ensure consistency between training and inference by adopting the associated-ID.
FFS: How to configure the associated-ID

Proposal 10: For AI/ML based positioning Case 1, select Alternative 4:
Alternative 4. Info #7 is provided explicitly from LMF to UE
Proposal 11: For label-based model performance monitoring of AI/ML positioning Case 1, support Option A-3.
Option A-3. Reuse Rel-18 assistance data transfer framework from LMF to the target UE, where the PRU measurement (e.g., legacy measurement) and the corresponding PRU location are sent via LMF to the target UE.
 
Proposal 12: For label-based model performance monitoring of AI/ML positioning Case 1, further study how to assess the reliability of approximate ground truth labels.

Proposal 13: For Case 3a, in the absence of a PRU, explore methods to assess the reliability of ground truth labels used in label-based performance monitoring.

Proposal 14: For label-free performance monitoring in direct AI/ML models, consider using legacy measurements and assisted positioning model outputs, in addition to leveraging model input/output statistics.

3GPP TSG RAN WG1 Meeting #120-bis						          					R1-2502529
Wuhan, China, April 7th – 11th, 2025

Agenda item:		9.1.2
Source:	Nokia
Title:	AI/ML for Positioning Accuracy Enhancement
Document for:		Discussion and Decision

Conclusion) For Case 3a, no indication is required for AI/ML output inference to LMF
Proposal 44: For Case 3b (LMF side model), for inference LMF may request reporting of UL measurements from gNB via NRPPa.
Proposal 45: For Case 1, inference configuration indicated to UE consists of 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.
Proposal 46: For Case 1, no inference reconfiguration is expected based on the preferred dynamic/online indications coming from the UE.
Proposal 47: Send an LS to RAN2/RAN3 to indicate a preliminary set of higher layer parameters for AI/ML positioning (check Appendix B).


Appendix A
The agreements reached on the agenda item 9.1.2 related to AI/ML for Positioning Accuracy Enhancement are indicated in each 3GPP RAN1 meeting.
Agreements reached in 3GPP RAN1#116 meeting


Agreements reached in 3GPP RAN1#116-bis meeting


Agreements reached in 3GPP RAN1#117 meeting

Agreements reached in 3GPP RAN1#118 meeting

Agreements reached in 3GPP RAN1#118bis meeting

Agreements reached in 3GPP RAN1#119 meeting


Agreements reached in 3GPP RAN1#120 meeting




Appendix B
Based on the current RAN1 agreements a preliminary list of high-level parameters for AIML positioning are indicated in Table 6.


Table 7 - Higher layer parameters for AIML positioning impacting other WGs.

3GPP TSG RAN WG1 Meeting #120bis				      R1-2502561
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.2
Source:		Fraunhofer IIS, Fraunhofer HHI
Title:		AI/ML positioning accuracy enhancement                                                                 
Document for:	Discussion & Decision

Conclusion 
Based on the discussion in the document, the following proposals are presented:

Proposal 1: 	For Case 1 and Case 3b, when Part A and Part B are generated by different entities, introduce a validity range to specify the confidence interval within which Part A or Part B remains valid for association.

Proposal 2:  	For Case 3b, introduce CIR feedback to inform the LMF about the accuracy of the reported CIR and allow adjustment of {Nt, Nt', k} if needed.

Proposal 3: 	Support a complex valued sample-based reporting offering:
Lossless reporting of the channel impulse response
Supporting future enhancements of the AI/ML model

Proposal 4: 	For Case 1, support the following signaling after a UE-sided model monitoring event, including label-free monitoring:
UE-sided proactive reporting on changes in applicable functionalities.
UE-sided monitoring report (pass/fail indication at minimum) if monitoring was initiated by NW for functionality monitoring.
In case functionality switching or fallback has been pre-configured in the UE by the NW (LMF), notification on functionality switch or fallback mode. 
UE requests support for more enhanced long-term monitoring for a specific model, e.g., configuration of event-based or scheduled monitoring in different time intervals, with the flexibility to adjust the monitoring frequency
        Note: more than one signals can be supported at the same time

Proposal 5: 	For model performance monitoring of AI/ML positioning, support the necessary signaling mechanisms for Options A-1, A-2, A-3, B-1, and B-2, including signaling for ground truth labels, monitoring events, time intervals, and assistance data.

Proposal 6: 	For Case 1/3a, if the UE/gNB model is proprietary to the NW, model management is performed by the UE/gNB. If (part of) the model has been developed (or co-developed) by the NW side, model management can be performed either by the LMF or the UE/gNB.

Proposal 7: 	The possible actions/decisions of the functionality management entity in the NW (LMF) side can be:
Long-term monitoring for a specific functionality. For example, configuration of event-based or scheduled monitoring in different time intervals and different monitoring frequencies
Functionality (de-)activation/switching or fallback (temporary)
Functionality permanent marked as non-applicable in an area, with possible triggering for new data collection
AI/ML feature permanently deactivated in an area

Proposal 8: 	Support validity indication for the AI/ML models associated with specific functionalities. The indication shall include at least information about the existence of ML assisted areas. 

3GPP TSG RAN WG1 #120bis	R1-2502595
Wuhan, China, April 7th – 11th, 2025

Agenda Item:	9.1.2
Source:	Apple Inc.
Title:	Discussion on Specification Support for AI/ML-based positioning
Document for:	Discussion/Decision

Conclusion
In this contribution, we provided our views on use cases and potential specification impacts on the enhancement on AI/ML for positioning accuracy enhancement. Based on the discussion, we have the following proposals:


Proposal 1:  Based on the agreements in RAN #107, there shall be no future agreements/discussions on the second priority cases (Case 2a and Case 2b) for AI/ML positioning. 

Measurements: Sample and Path:
Proposal 2: For sample-based measurement:
Increase the number of additional paths supported (the value range of Nt) to 32, 64, 128

Proposal 3: If the Nt', Nt and/or k values used by gNB/TRP are different from the Nt', Nt and/or k values signaled by the LMF:
The Nt', Nt and/or k values used by gNB/TRP belong to their candidate value set, respectively.

Proposal 4: Support both absolute and differential RSRPP mapping for RSRPP values
The measurement depends on the input type 
Delay profile: timing information with no magnitude 
Power Delay Profile: Timing information and RSPP
CIR: Timing information, RSPP and phase information

Measurements: Types and Timing
Proposal 5: On the reference time for UE channel measurements reported to the LMF, RAN1 to re-use the legacy reference time for UE side channel measurements as follows:
-	Option 1: The reference time is TSubframeRxi, as defined in TS 38.215, clause 5.1.29.
-	Option 2: The reference time is TUE-TX, as defined in TS 38.215, clause 5.1.30.
- 	We prefer at least option 1

Proposal 6: On the use of CIR model input for AI/ML positioning:
The relative performance of CIR and PDP depends on the complexity of the AI/ML model, bandwidth and number of samples. 
With phase mismatch between the transmitter and receiver, the accuracy of AI/ML based positioning degrades.
Option 1: This can be mitigated by training the model with data that suffers a similar mismatch.
Option 2: This can be mitigated by training the model with data that is compensated to remove the effect of the mismatch.

Proposal 7: On other aspects, limit the overhead, a model may be able to support mixed input with CIR input for the TRPs closest and PDP/DP for TRPs further away. 

Proposal 8: RAN1 to support using phase information (in addition to timing information and power information) for determining model input (i.e. support CIR based model input).

Model Inference: Input and Output
Proposal 9: For Rel-19 Case 3a, if the LOS/NLOS indicator is reported with other associated measurement (e.g. timing information) obtained by legacy positioning methods, 
the LOS/NLOS indicator provides the likelihood of a line-of-sight propagation path for the channel measured over the resource for which the measurement is reported
The LOS/NLOS indicator can reuse the existing IE "LoS/NLoS Information" in 38.455/37.355, which can be soft indicator or hard indicator.

Proposal 10: For Rel-19 Case 3a, if  the LOS/NLOS indicator is reported and the other associated measurement (e.g., timing information) is obtained by AI/ML positioning methods, from RAN1 perspective, 
The LOS/NLOS indicator provides the likelihood of a line-of-sight propagation path for the channel measured over the resource for which the measurement is reported;
The LOS/NLOS indicator can reuse the existing IE "LoS/NLoS Information" in 38.455/37.355, which can be soft indicator or hard indicator.
The report should also include an indicator that the other associated measurement was obtained by AI/ML
Data Collection

Proposal 11: the working assumption on entities to generate measurements and labels in RAN1 #116bis and RAN1 #117 should be approved

Proposal 12: For model training, the following elements shall be specified as part of the data collection procedure:
Part A
Channel Measurement (corresponding to model input), 
Quality indicator (for and/or associated with measurement at least for model training) 
Time stamp (for and/or associated with measurement)
Part B
Ground truth label, 
Quality indicator (for and/or associated with ground truth label)
Time stamp (for and/or associated with ground truth label)
Assistance Information

Proposal 13: For model inference, the following elements shall be specified as part of the model inference procedure:
Part A
Measurement (corresponding to model input),
Time stamp,
Assistance Information

Proposal 14: For model monitoring, the following elements shall be specified as part of the monitoring procedure:
Part A:
Measurement (corresponding to model input),
Time stamp, 
 Quality indicator (for and/or associated with ground truth label and/or measurement at least for model monitoring), 
Part B
Ground truth label, 
Quality indicator (for and/or associated with ground truth label and/or measurement at least for model training), 
Time Stamp
Assistance Information

Proposal 15: For data collection, the key specification impacts are in the transfer of the measurement data in case 3b (gNB to LMF) for model inference and model monitoring. 
This requires an update to support CIR, PDP and DP measurement data. 
Additional specification is required to transfer ground truth labels, quality indicators and other necessary information from the measurement entity to the monitoring entity.

Assistance Information 
Proposal 16: For Rel-19 AI/ML positioning, assistance data be signaled as assistance information (Network Assistance Information or UE-Assistance Information) or configured as part of the procedure. 

Proposal 17: The information assistance data may be sent for any one of the LCM stages as
LCM procedure specific e.g. for data collection for training only, monitoring only, inference only
Signalling of assistance data may be Option A (UE initiated) and/or Option B (LMF initiated)
For use across LCM procedures e.g. to ensure consistency between model training and model inference.
The assistance data may be unicast to a single entity or broadcast to multiple entities. 


Proposal 18: To ensure consistency between the LCM procedures, 

Alternative 2. Info #7 can be provided either implicitly or explicitly by LMF. Note: no UE capability is introduced on whether info #7 is provided implicitly or explicitly, and the UE can request info #7 to be provided explicitly or implicitly. 
If provided implicitly, associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference

Proposal 19: For AI/ML based positioning Case 1, all assistance information from legacy UE-based DL-AoD can be provided from LMF to UE.


Proposal 20: the following new conditions may be signaled:
Data Quality Conditions
Measurement data quality range (e.g. SNR/SINR range), (new) 
label data quality range (e.g. mean label positioning error) (new)
Time range when data generated (new)
Hardware Conditions 
Network Synchronization Error (new)
Phase offset error (new)

Proposal 21: support a mechanism for the UE to indicate its preferred network-side conditions or specific UE side by a procedure similar to the “on-demand PRS”.
Model Monitoring
Proposal 22: the default option is for the monitoring to occur at the entity with the AI/ML model. 

Proposal 23: RAN1 should support at least Option A-2, A-3 and B-1.

Proposal 24: To ensure the accuracy of the GT 
Step 1: use a LOS/NLOS identifier to identify >= 3 LOS links. Note that LOS probability may be used to derive the measurement quality.
Step 2: use legacy positioning method to estimate GT position
Step 3 (for case 2a): estimate GT timing for each of the LOS links based on estimated GT position 

Proposal 25: For Case 3a Option A.  NG-RAN node performs monitoring metric calculation for its own model.
Option A-1. At least information on ground truth label of the target UE is generated by LMF and provided to the NG-RAN.
Option A-2. Reuse Rel-18 assistance data transfer framework from LMF to the NG-RAN (based on NRPPa), where the PRU measurement (e.g., legacy measurement) and the corresponding PRU GT are sent via LMF to the NG-RAN. 
Note as this is a PRU, the location is known by the LMF.
NG-RAN node performs monitoring metric calculation for its own model in the LOS/NLOS use case. 
The NG-RAN node is not allowed to know the location of the non-PRU UEs connected to it. This is to maximize privacy for the non-PRU UEs connected to the NG-RAN node
The NG-RAN node is not allowed to perform the monitoring metric calculation for the timing estimation use case. 


Proposal 26: For Case 3a Option B.	LMF performs monitoring metric calculation for the model located at the NG-RAN node
Option B-1: at least inference result (i.e., the model output corresponding to target UE’s channel measurement) of the target UE is sent by the NG-RAN node to LMF. 
In one example, target UE and/or gNB sends measurement (e.g., legacy measurement) to LMF so that LMF can derive the information on ground truth label. {non-PRU with estimated position)

Option B-2:  at least inference result (i.e., the model output corresponding to PRU channel measurement) “close” to the target UE is sent by the NG-RAN node to LMF. 
In one example, PRU and/or gNB sends measurement (e.g., legacy measurement) to LMF so that LMF can derive the information on ground truth label.


Proposal 27: RAN1 should support at least Option A-2, and B-1.


Proposal 28: In the case on non-GT based monitoring, we have the following specification impact: 

Case Specific non-GT Monitoring 

Proposal 29: If the AIML based positioning method becomes non-applicable when LMF requests UE location estimation, and the UE cannot perform the AIML based positioning, RAN2 should allow for fallback to legacy based on UE-capability. 

AI/ML Processing Units
Proposal 30: For AI processing criteria and timeline discussion with UE side model, define separate AI processing unit pool(s) dedicated to AI-based processing.  

Proposal 31: For AI processing criteria for AI based positioning the following options should be considered: 
Option 1: Processing criteria as part of a general AI processing budget (i.e. with BM and/or AI/ML based CSI reporting) 
Option 2: Processing criteria as part of a separate AI processing budget due to the large delay tolerance of the positioning report feedback.

Proposal 32: Reuse the legacy PRS processing capability for AI based positioning case 1, where UE perform PRS measurement and perform inference for direct positioning. The number of AI Processing units occupied could be estimated based on 
Option 1: Duration of DL PRS symbols N in units of ms a UE can process every T ms assuming maximum DL PRS bandwidth in MHz, which is supported and reported by UE
Option 2: Max number of DL PRS resources that UE can process in a slot under it

3GPP TSG-RAN WG1 Meeting #120bis	R1- 2502660
Wuhan, China, April 7th – April 11th, 2025
Agenda Item:	9.1.2
Source:	Ericsson
Title:	AI/ML for Positioning Accuracy Enhancement
Document for:	Discussion, Decision
1	

Conclusions

In the previous sections we made the following observations: 
Observation 1	Using a simple [length + copy of indicated span] approach, the number of signaling bits for the timings of the remaining  nonzero subsamples can be reduced by at least 40% when compared to using the existing additional path timing reporting format. The savings in signaling bits are greater when the number of remaining nonzero subsamples, , are larger.
Observation 2	When compared to the total-power PDP input type, the 2-port PDP input type (1) doubles the signal sizes; (2) requires higher computational complexity; and (3) achieves marginal performance improvements.
Observation 3	When compared to the total-power PDP input type, the 1-port PDP input type (1) discards signal power and radio channel information that is readily available, and (2) achieves lower positioning accuracy.
Observation 4	Rel-18 CPP measurements (DL RSCPD, DL RSCP, UL RSCP) assume LoS environment, which is contradictory with the target use case of Rel-19 AI/ML based positioning.
Observation 5	Single phase value for first path/sample (e.g., DL RSCPD, DL RSCP, UL RSCP) brings no observable performance benefits to PDP, but incurs substantially high deployment cost and signalling overhead.
Observation 6	The initial phase values of measured CIR samples may be random and contains no useful spatial dependent information for an AI/ML model to learn the association between measured CIR samples and the target positions. Without addressing such spurious information during training and inference, fingerprinting ML models using the CIR inputs can produce inaccurate position estimates.
Observation 7	CIR samples containing relative phases can be used as inputs to AI/ML models to circumvent the impact of random initial phase values of measured CIR samples.
Observation 8	For the RSCPD measurement PRU assisted phase error compensation requires PRUs to be used during training and inference, further increasing the deployment cost and signaling overhead.
Observation 9	For inter-path phase measurements, the model input at training and inference must know the UE TX or RX antenna phase contribution, either by reporting the antenna phase contribution to the model, removing it, or assuming the same antenna pattern is used during inference and training.
Observation 10	It is unclear how a mobile UE would know the direction of departure / arrival and associated phase offset for each path toward a given TRP.
Observation 11	For small or moderate signaling sizes, PDP and DP samples can achieve better positioning accuracy than CIR samples at the same or smaller signaling size. Multi-port CIR samples can achieve higher positioning accuracy only with very large signaling requirements.
Observation 12	For small or moderate signaling sizes, PDP and DP samples can achieve better positioning accuracy than CIR samples at the same or smaller signaling size as well as with substantially lower AI/ML model complexity.
Observation 13	For most given 90%tile 2D UE positioning error requirements, the DP samples requires the smallest signaling sizes.
Observation 14	Multi-port complex-valued CIR samples for both Case 3b (1st priority) and Case 2b (2nd priority) require very large signaling sizes, which can cause significantly negative impacts on the radio and core networks.
Observation 15	With small to moderate number of samples available to an ML model, the total-power PDP input type is a very helpful induction bias to impose on the ML model based on human domain knowledge that the sample powers contain more important information about the UE positions. It’s only with very large number of samples that the model can start to tease out how to use the additional information in the sample phases on its own.
Observation 16	Dimension reduction techniques can be used to reduce the signal sizes of multi-port CIR samples. But the achievable positioning accuracy is also compromised. The overall accuracy vs overhead tradeoff situation of CIR samples is not improved by the two considered dimension reduction techniques.
Observation 17	For Case 3a, the location of the AI/ML model (e.g., gNB-DU vs gNB-CU) impacts the need to specify new measurements for model input.
Observation 18	The LOS/NLOS indicator in legacy positioning report is a measure of the reliability of the measurement report.
Observation 19	AI/ML assisted positioning can provide measurement report of the NLOS channel with high confidence.
Observation 20	The interpretation of a LOS indicator as reflecting the physical nature of the channel should be the same in Release 19 and legacy.
Observation 21	If the LMF is not involved in the model monitoring of the model generating the LOS indicator, the need for identifying a LOS indicator as generated by a model output is not clear.
Observation 22	Time stamp for Part B may span a period of time for which the location of the UE is consistent.
Observation 23	Part A-B pairing is an issue across Case 1, 3a and 3b.
Observation 24	The LMF should be aware of the training condition of the model to ensure that network conditions and assistance data can be kept consistent before positioning procedures are started during inference.
Observation 25	Knowing the model range of applicability in terms of tolerable errors in model input can save considerable signalling during the model monitoring phase.
Observation 26	Collecting sufficient data in terms of training dataset size, UE distribution, diversity of UE sources, etc, is up to implementation.
Observation 27	There is as no clear decision in RAN WGs for the label used in case 3a.
Observation 28	At least UE location can be used can be used as a label for case 3a
Observation 29	Label-free model performance monitoring is up to implementation of model inference entity. The only potential specification impact is to notify other entities of the model monitoring decision, if necessary.
Observation 30	If certain information on the ground truth label can be generated by the model inference entity, then such label-based model performance monitoring is also self-contained and up to implementation of model inference entity. The only potential specification impact is to notify other entities of the model monitoring decision, if necessary.
Observation 31	The benefit of associated ID is that the details for the information covered by associated ID do not need to be explicitly signaled, if they are not needed for performing model inference, and only needed for consistency verification.
Observation 32	For Cases with LMF-side model (Case 2b/3b), the measurements reported for model input must be consistent with the ones used with training data.
Observation 33	For Case 1, the SI only considered time-based fingerprinting approaches.
Observation 34	For Case 1, operators should have the possibility to support Case 1 and without disclosing TRP location.

Based on the discussion in the previous sections we propose the following:
Proposal 1	RAN1 assumes Case 1 is supported using UE based DL-TDOA procedures as a foundation. It is up to RAN2 to decide whether a set of new procedure is to be defined for Case 1, or extension to DL-TDOA suffices. RAN1 confirms the understanding with RAN2.
Proposal 2	RAN1 assumes Case 3a is supported using UL-TDOA or multi RTT procedure as a foundation. It is up to RAN3 to decide whether a set of new procedure is to be defined for Case 3a, or extension to existing procedure suffices. RAN1 confirms the understanding with RAN2 and RAN3.
Proposal 3	RAN1 assumes that for Case 3b with sample-based reporting enhancements, measurement report with sample-based reporting can be differentiated by the involved nodes (LMF, gNB) from the legacy UL RTOA measurement requests / reports. RAN1 confirm the understanding with RAN2 and RAN3.
Proposal 4	For Case 3b (and 3a if needed), when enhanced measurement are reported (i.e., sample-based reports) from the gNB to the LMF:
	When the Nt, Nt', k values used to produce the report are different from the ones provided by the LMF in the measurement request, gNB provides in the measurement report to the LMF the Nt value used for the measurement.
	Nt, Nt', k values used to produce the report are values from the possible combination of  {Nt, Nt', k} according to the agreed candidate values for Nt, Nt', k in RAN1#119
	Note: k value is already supported in the measurement report, and Nt’ can be inferred by the report size so that is does not need to be reported explicitly.
Proposal 5	Resolve the remaining FFS in RAN1#119 agreement that there is no need to transmit offset from gNB to LMF.
Proposal 6	Regarding PDP for model input, update the DL PRS-RSRPP and UL SRS-RSPP definitions where the path or sample powers are summed over all receive antenna ports, i.e., using total-power PDP.
Proposal 7	Do not support phase information for determining model input, including CIR and single phase value for first path/sample.
Proposal 8	Before CIR can be adopted as model input, RAN1 need to investigate whether fingerprinting ML models can handle CIR phase measurements, which vary not only with the radio channel environment but also with the transmitter/receiver circuits.
Proposal 9	To decide whether to support phase information to enable CIR as model input, RAN1 should weigh the small positioning accuracy improvement against the standardization effort, the signaling overhead, and the difficulty to align phase information between training and inference.
Proposal 10	If phase information is supported to enable CIR as model input, the phase values are reported in the format of relative phase.
Proposal 11	RAN1 to down-prioritize the signaling approach(es) and/or measurement definitions to support CIR model input types for Case 3b (1st priority) and Case 2b (2nd priority).
Proposal 12	Send an LS to RAN3 to request feedback on whether the input to the AI/ML model for case 3a need to be specified.
Proposal 13	For measurement report of AI/ML assisted positioning Case 3a, when timing information is reported from gNB to LMF, the timing information is for virtual LOS link if carried in a new Rel-19 measurement report, and the timing information is for physical LOS link if carried in a legacy measurement report (Rel-18 or prior).
Proposal 14	For Rel-19 measurement report, the LOS/NLOS indicator (for physical LOS link) is decoupled from the timing information reporting (for virtual LOS link).
Proposal 15	Support reporting (optionally) a LOS/NLOS indicator when timing information is reported for Rel-19 AI/ML positioning Case 3a.
Proposal 16	For AI/ML assisted positioning Case 3a, when the LOS/NLOS indicator is reported, from RAN1 perspective, the LOS/NLOS indicator provides information on the likelihood of a physical Line-of-Sight propagation path from the source to the receiver with a value of 1 corresponding to LOS and a value of 0 corresponding to NLOS; the LOS/NLOS indicator reuse the same format as the existing IE "LOS/NLOS Information" in 38.455.
Proposal 17	(for conclusion) For AI/ML assisted positioning, when the LOS/NLOS indicator is reported for Rel-19 Case 3a, do not support an indication of whether the LOS/NLOS indicator is obtained via a model output or via legacy method.
Proposal 18	From RAN1 perspective, when timing information is reported for Rel-19 AI/ML positioning Case 3a, one LOS/NLOS indicator is optionally reported per TRP in a measurement report from gNB to LMF, as in the existing specification.
Proposal 19	For measurement report of AI/ML assisted positioning Case 3a, when timing information is reported from gNB to LMF, LMF shall be able to distinguish whether the timing information is obtained for Rel-19 measurement report (virtual LOS link) or for legacy measurement report (physical LOS link).
	For timing information obtained for Rel-19 measurement report, If a timing measurement is reported together with the LOS/NLOS indicator, the indicator status (for physical LOS/NLOS) is decoupled from the reported timing measurement (for virtual LOS)
	Note: when the TRP-UE radio link is LOS, the virtual LOS coincides with the physical LOS.
	Details of how to associate the Rel-19 timing information with virtual LOS is up to RAN2/3, e.g. indication in measurement report, or configuration in measurement request.
Proposal 20	Reuse the existing measurement reporting in LPP and NRPPa to report timing information for the model output of AI/ML assisted positioning.
Proposal 21	For AI/ML assisted positioning at gNB (Case 3a), the model output is uplink relative time of arrival (TUL-RTOA).
Proposal 22	For AI/ML assisted positioning at gNB (Case 3a), postprocessing is applied to generate gNB RxTxTimeDiff for measurement reporting of multi-RTT method.
Proposal 23	For AI/ML assisted positioning at gNB (Case 3a) and UE (Case 2a), the measurement report contains an indicator that AI/ML is used to produce the measurements. The signaling details are up to RAN3/RAN2.
Proposal 24	For Rel-19 AI/ML based positioning, support collecting labelled and optionally un-labelled training data samples.
Proposal 25	For AI/ML based positioning Case 3a, when timing information is reported for Rel-19 AI/ML positioning Case 3a, regarding the time stamp of the measurement result item containing the timing information
	Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.
Proposal 26	For AI/ML based positioning Case 3a, when part B is provided to the gNB, regarding the time stamp of the part B:
	Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.
Proposal 27	For training data collection of AI/ML based positioning, for both Part A and Part B, time stamp is mandatorily provided by the training data generation entity.
Proposal 28	For training data collection of AI/ML based positioning, the time stamp should allow unambiguous mapping between Part A and Part B.
	For channel measurement generated by TRP/gNB, at least when measurement periodicity exceeds the SFN/slot wrap around time (10.24 sec), field “Measurement time” is included in the time stamp.
	For channel measurement and label generated by PRU or non-PRU UE, UTC Time (e.g., for utc-time-r16) is included in the time stamp.
	Exactly how to specify time stamp for Part A and Part B is up to RAN2/RAN3.
Proposal 29	From RAN1 perspective, the existing IEs and their associated granularities can be reused for time stamp of Part A and Part B. It is acceptable to have different time stamp granularity for Part A and Part B. There is no need for RAN1 to discuss how to perform the pairing using the time stamps.
Proposal 30	For AI/ML based positioning Case 1, there is no need to discuss further the time stamp of part A for data collection at the UE.
Proposal 31	For AI/ML based positioning in case 3a, 3b, when timing information is generated and reported as a part of channel measurement,
	One quality indicator of timing measurement is generated for the entire channel measurement associated with a TRP, i.e., one quality indicator for the list of path or sample measurement values.
	Note: the current format of measurement items in a measurement report for NRPPa can provide such support.
Proposal 32	A label provided by a LMF, PRU, or non-PRU UE can be attached with one or more time stamp, or a span of time stamps, for which the label is valid.
Proposal 33	(for conclusion)  For training data collection of AI/ML based positioning, the case of Part A and Part B generated by the same entity is beyond the scope for Rel-19.
Proposal 34	Model capability should provide what range of network condition the model can handle, so that the network does not request positioning using the model when the condition are not satisfied.To ensure consistency between training and inference, and applicability of the model during inference, the model host (UE/gNB) provides the following metadata information on the training dataset information including:
	Supported assistance data range for PRS configuration (bandwidth, comb size)
	Supported SNR range
	Supported range of RS Tx timing error
	FFS: additional network conditions
Proposal 35	To report the supported SNR range, The GNB / UE may report the RSRQ range over which its model is able to operate.
Proposal 36	To report the supported RS  timing error,
	For case 1, UE may report the RTD info  range and timing error margin over which its model is able to operate to the LMF.
	For case 3a, to enable comparing the transmit timing error range to the support error range at the TRP:
i.	gNB may report the UE timing error margin range over which the model can operate to the LMF.
ii.	UE may report the timing error range directly to the gNB.
Proposal 37	The training dataset validity area is recorded as a part of metadata of the training dataset. The validity area is defined as a list of TRPs where data is collected.
Proposal 38	Training data provided to UE/gNB is organized with the same hierarchy as for legacy assistance data, i.e. per TRP/frequency layers for the UE, and per TRP for the gNB assistance data.
Proposal 39	For Part A training data collection of Case 1/2a, the assistance data include: training dataset validity area, assistance data necessary for PRS reception, and associated ID for additional network conditions. Corresponding assistance data is sent during model inference as well for consistency checking.
Proposal 40	The assistance data required for PRS/SRS reception is the same across all use cases for both direct and AI/ML assisted positioning.
Proposal 41	For AI/ML based positioning Case 3a, from RAN1 perspective,
	the label data can be the UE  location
	UE location can be requested from the gNB to the LMF and transferred from LMF to gNB, together with time stamp and quality indicator of label can be provided by reusing existing IEs.
Proposal 42	Confirm the existing WAs on label generation for all cases and send the agreements to RAN2.
Proposal 43	For training data collection Part B, support only ground truth labels in the format of UE location coordinates (x, y, z).
Proposal 44	From RAN1 perspective, the same label (UE location) and label quality (UE location uncertainty) are collected, irrespective of the type of model architecture (e.g., assisted or direct positioning) that may be selected by the model training entity.
Proposal 45	The model inference entity is responsible for model-level performance monitoring and management, including calculation of model monitoring metrics. The detailed algorithm and procedure are up to implementation.
Proposal 46	For AI/ML based positioning, LMF is responsible for functionality-level performance monitoring and management.
Proposal 47	For AI/ML based positioning, LMF can decide on a fallback method based on performance monitoring reports from the UE/gNB
	Note: there is no specification impact needed to enable a fallback mechanism.
Proposal 48	For AI/ML positioning Cases, LMF based functionality management using label-free monitoring methods are supported, where the model inference entity performs self-monitoring without external information on the ground truth label.
Proposal 49	For AI/ML positioning Cases, self-monitoring is the baseline,  where the model inference entity performs self-monitoring with or without external information on the ground truth label (i.e., label-free or label-based).
	The detailed self-monitoring method and decision-making are up to the implementation of the model inference entity (gNB or UE or LMF).
	The LMF can request / configure the reporting of monitoring outcome by the model inference entity when it’s gNB or UE.
	For Case 1 and Case 3a, the UE (Case 1) and gNB (Case 3a) sends the monitoring decision to LMF, at least when the monitoring decision indicates that the model becomes inappropriate for inference.
	For model inference at UE (Case 1, 2a) or gNB (Case 3a), the LMF can provide assistance information to support the calculation of model monitoring metrics. FFS: what assistance data may be provided.
Proposal 50	For model performance monitoring of AI/ML positioning Case 1, support Option A-1 and/or A-2 for model performance monitoring metric calculation, if estimated label is considered necessary to be provided by an external entity (which is LMF for Case 1).
Proposal 51	For model performance monitoring of AI/ML positioning Case 1, do not support Option A-3, B-1 or B-2.
Proposal 52	For AI/ML positioning Cases, if label-based monitoring is supported:
	The model inference entity performs self-monitoring.
	The LMF can request / configure the reporting of monitoring outcome by the gNB/UE.
	For Case 1 and Case 3a, the UE (Case 1) and gNB (Case 3a) sends the monitoring decision to LMF, at least when the monitoring decision indicates that the model becomes inappropriate for inference.
Proposal 53	For model performance monitoring of AI/ML positioning Case 1, the monitoring outcome provides an indication whether the model is appropriate for model inference. If the monitoring indicates that the model is no longer appropriate, an error cause can be sent as the monitoring outcome.
Proposal 54	For model performance monitoring of AI/ML positioning Case 1, the target UE reports monitoring outcome at least
	(Reporting upon request) When the target UE receives a LMF request and monitoring outcome is provided in UE response; Or
	(Autonomous reporting) When the target UE has detected that the target UE cannot perform the AI/ML based positioning method.
Proposal 55	The model training entity records the model inference validity area as a part of metadata for the trained model.
Proposal 56	When preparing for model inference, the model inference validity area is checked for compatibility with the deployment area.
Proposal 57	When preparing for model inference, configurations of reference signal transmission and measurement are checked for compatibility between the trained model and the deployment environment.
Proposal 58	For Case 2a/3a, support UE/gNB to send an indication to the LMF when the AI/ML model is ready for reporting measurements based on model inference. It is up to RAN2/3 to decide which procedure to use to convey the information.
Proposal 59	For UE-side model (Case 1), to ensure the consistency of NW-side additional condition across training and inference, support associated ID for indicating NW conditions/configurations.
Proposal 60	For AI/ML based positioning, the consistency between training and inference is checked for each TRP separately.
Proposal 61	For a given TRP j, the UE assumes that the NW-side additional conditions with the same associated ID are consistent within the TRP j.
Proposal 62	For measurements reported to the LMF in case 2b/3b, support the LMF to indicate the PRS/SRS measurement bandwidth.
Proposal 63	Do not support provision of assistance data (info #16-18) dedicated to UE-based DL-AoD, but not needed for DL-TDOA.
Proposal 64	For case 1, regarding info#7 in the assistance data from DL-TDOA, support Alternative 2
	Info #7 can be provided either implicitly or explicitly by LMF. Note: no UE capability is introduced on whether info #7 is provided implicitly or explicitly, and the UE can request info #7 to be provided explicitly or implicitly.
i.	Note: if explicit signaling is not supported by the network, legacy behavior can be used to exclude the TRPs without provided location from provided AD.
	If provided implicitly, associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference.
Proposal 65	For case 1, associated ID for maintaining of consistency of TRP location is provided per TRP as follow:
	Time stamp of the time from which network conditions have been consistent.
	A TRP location ID for the TRP location, valid from the time of the time stamp.
i.	Note: the TRP location ID is not the real TRP location
ii.	FFS: how many location IDs are required. Conclusion
 

3GPP TSG-RAN WG1 #120bis	R1-2502663
Wuhan, China, 7th April – 11th April, 2025

Agenda item:		9.1.2
Source:	MediaTek Inc.
Title:	Design for AI/ML based positioning
Document for:		Discussion

Conclusion
Proposal 2-1: For use case 1, support alternative 2 for providing TRP location info

Proposal 2-2: For use case 1, let RAN2 handle the performance monitoring aspect, since RAN2 can reuse the legacy solution as the baseline

Proposal 3-1: For use case 3b, the reporting of the adopted Nt value is not considered, no matter in implicit or explicit way

Proposal 3-2: For use case 3b, when gNB adopts different Nt’ from the recommended one, consider the maximum value to be 24 for reporting

Proposal 3-3: It is not considered to define valid duration for Part B
 

Reference

3GPP TSG RAN WG1 #120bis			R1-2502684
Wuhan, China, April 7th – 11th, 2025
Source:	Sharp
Title:	Discussion on specification support for AI/ML based positioning accuracy enhancements
Agenda Item:	9.1.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we have discussed our views on specification support for positioning accuracy enhancement and have the following observations and proposals.
Proposal 1: For AI/ML-based positioning Case 1, for UE-side measurement of an estimated channel response between a pair of UE and TRP, the starting time of the list of Nt consecutive samples is determined as follows.
If LMF configures an offset relative to a reference time, and the UE follows the configuration,
starting time = reference time + offset
FFS: value range of the offset 
Otherwise
starting time = first detected sample (i.e., first detected path with timing granularity T).
Proposal 2: For the AI/ML based positioning, starting time of the window is reported from gNB to LMF.
Observation 1: The bitmap format is suitable for the sample-based measurement in many combinations of  and .
Proposal 3: For AI/ML based positioning, Bitmap format should be introduced for reporting Rel-19 enhanced measurement report. 
Proposal 4: For AI/ML based positioning, Legacy-like format and Bitmap format should be supported for reporting Rel-19 enhanced measurement report.
Proposal 5: The measurement parameter  shall be indicated to the LMF implicitly or explicitly.
Proposal 6: For training data collection of AI/ML based positioning, at least Case 3b, Part B should be associated with the validity information.
Observation 2: the valid duration of the label is depending on the UE mobility. However, the LMF should determine the appropriate valid duration for each corresponding label since LMF has an AI/ML model.
Proposal 7: For training data collection of AI/ML based positioning Case 3b, the mobility information is provided along with the Part B.
Proposal 7: For AI/ML based positioning, continuous phase information is supported for model input.
Observation 3: In a case that the associated timing information is not predicted by AI/ML, the meaning of the LOS/NLOS indicator does not need to be changed, regardless of whether the LOS/NLOS indicator is predicted by AI/ML.
Observation 4: In a case that the associated timing information is predicted by AI/ML, current NRPPa specification (TS38.455) can be interpreted in two ways for AI/ML assisted positioning as follows:
Interpretation 1) the LOS/NLOS indicator provides the confidence of virtual LOS propagation path of the associated timing information of the AI/ML model output.
Interpretation 2) the LOS/NLOS indicator provides the likelihood of a physical LOS propagation path of the channel measurement used for input of the AI/ML model.
Proposal 8: For AI/ML assisted positioning in case 3a, study the following options for down-selection: 
Option 1: the LOS/NLOS indicator is provided with definition change in current specification in case that the associated timing information is predicted by AI/ML.
Option 1-1: the LOS/NLOS indicator provides the confidence of a virtual LOS propagation path of the associated timing information of the AI/ML model output.
Option 1-2: the LOS/NLOS indicator provides the likelihood of a physical LOS propagation path of the channel measurement used for input of the AI/ML model.
Option 2: the LOS/NLOS indicator is not provided in case that the associated timing information is predicted by AI/ML.
Proposal 9: For the case that the associated timing information is predicted by AI/ML, the LOS/NLOS indicator provides the confidence of a virtual LOS propagation path of the associated timing information of the AI/ML model output.
Proposal 10: For AI/ML assisted positioning Case 3a, indicator that provides whether the timing information is made by AI/ML is reported.
Observation 5: Explicit or implicit indication of TRP location is beneficial to ensure consistency between training and inference.
Observation 6: Although, the consistency can be ensured by performance monitoring if the ID or info#7 is not provided, positioning accuracy may temporarily decrease in inference phase until performance monitoring.
Proposal 9: For AI/ML based positioning, UE may assume the similar properties (e.g. Geographical coordinates of the TRPs) with the same associated ID
- Note: the how to define the associated ID and the physical properties should be up to network implementation without specifying.
Observation 7: The implicit indication requires that the UE that has highly generalized AI/ML model may unnecessarily consider that the consistency is not ensured.
Proposal 10: UE shall determine that the consistency between training and inference is not ensured when the associated ID is changed from stored associated ID during the training phase.
Observation 8: When the UE is provided explicitly indicated TRP location, the UE can determine whether its own model/functionality is not ensured the consistency according to the generalization performance of its model.
Proposal 11: For AI/ML based positioning Case 1, to ensure consistency between training inference, Alternative 2 is supported:
 •Alternative 2. Info #7 can be provided either implicitly or explicitly by LMF. 
Observation 9: For UE-side performance monitoring, following two options can be considered:
Option 1: UE makes a decision whether its own model is appropriate or not, and UE reports the decision.
Option 2: UE reports performance monitoring metrics to LMF and LMF makes a decision whether UE’s model is appropriate or not.
Proposal 12: UE makes a decision whether its own model is appropriate or not and UE reports the decision that indicates the model is inappropriate. 
Proposal 13: LMF can configure threshold to UE to determine whether its own model is appropriate or not.

3GPP TSG RAN WG1 # 120bis		R1-2502756
Wuhan, CN, Apr. 7th – 11st, 2025
Source:	NTT DOCOMO, INC.
Title:	Discussion on AI/ML for positioning accuracy enhancement 
Agenda Item:	9.1.2
Document for: 	Discussion/Decision

Conclusion
In this contribution, we discussed the potential specification impacts on AI/ML for positioning accuracy enhancement. Based on the discussion we made the following observations and proposals.
Observation 1: If part A and part B information are generated by the same entity, no need to consider how to pair part A and part B information.
Observation 2: For performance monitoring metric calculation of AI/ML based positioning of case 1, each option has different benefits and no or little specification impacts by reusing existing procedures and IEs.
Observation 3: For AI/ML based positioning of case 1/3a, label-free monitoring methods are supported with self-monitoring by the model inference entity with no specification impact.
If the UE (Case 1) and gNB (Case 3a) sends the monitoring decision to LMF, signaling for label-based monitoring can be reused.
Observation 4: In positioning use case, “functionality-based LCM” can be defined as AI/ML operations such as activation, deactivation, switching, and fallback operation of the positioning method, including the switch between AI/ML-based positioning methods and legacy positioning methods according to TR.

Proposal 1: For data collection, for the time stamp of part A/B, existing IEs are reused.
SFN level report, i.e., NR-TimeStamp is applied as baseline. 
When SFN level reporting is not sufficient, UTC time is optionally applied as time stamp. 
For case 1, UTC-time is optionally reported.
For case 3b, Measurement time is optionally reported.
Proposal 2: For pairing part A and part B information, RAN1 does not need to discuss how to pair part A and part B information at least until RAN2 makes the progress on the framework.
Proposal 3: For data collection of 3b, the measurement report and related assistance information for AI/ML based positioning is determined by LMF.
For case 3b, for data collection of training, inference and performance monitoring, LMF initiates corresponding measurement reporting at gNB.
Proposal 4: For data collection of case 1, at least following assistance information is indicated from LMF to UE for consistency between training and inference. Further study the necessity of other information. 
PRS configuration
Training data validity area (e.g., AreaID-CellList), where PRS can be assumed to be consistent within a validity area
Proposal 5: Regarding RS configurations of data collection for each case,
For case3a/3b, NW sends configurations to UE for SRS transmissions.
RS configurations may include/associate with an associated ID to implicitly indicate the NW side additional conditions.
Proposal 6: From RAN1 perspective, for Rel-19 enhanced measurement of Case 3b, regarding the measurement report format for the timing information of the Nt’ values, the existing IE UL RTOA Measurement in TS 38.455 can be a starting point.
Proposal 7: For AI/ML based positioning, in addition to timing information and power information, phase information report is considered for determining model input.
Rel-18 measurements (e.g., DL RSCPD, DL RSCP, UL RSCP) are considered as a baseline for phase information report.
Proposal 8: For assistance information from legacy UE-based DL-TDOA, TRP location is provided implicitly via associated ID for case 1 (Alt. 1).
Associated ID indicates network-side additional condition (e.g., TRP location) is consistent between training and inference.
TRP location is provided implicitly via associated ID or explicitly based on the indication by LMF as compromise (Alt. 2).
Proposal 9: For AI/ML based positioning case 1, assistance information only from legacy UE-based DL-AoD (i.e., not from legacy UE-based DL-TDOA) is not provided explicitly from LMF to UE.
If some of assistance information from legacy DL-AoD (e.g., Info #16) are reported, information is provided implicitly via associated ID.
Proposal 10: For AI/ML assisted positioning (i.e., Case 3a), LMF distinguishes whether the timing information is legacy timing measurement or Rel-19 enhanced timing measurement. 
It is up to RAN3 to decide how to ensure that LMF can distinguish between the two types of timing measurement.
Proposal 11: For performance monitoring metric calculation of AI/ML based positioning of case 1, both Option A and B are considered. Both legacy positioning-based and PRU-based ground truth label generations are considered.
Proposal 12: For model performance monitoring of AI/ML positioning case 1 with option A-3, to align channel measurement format by PRU with the measurement format desired by target UE model, 
The request procedure for channel measurement format between UE/PRU and LMF can be considered.
UE monitors with PRU measurement and PRU location information when PRU measurement format is matched with desired format by UE by implementation.
Proposal 13: For performance monitoring of AI/ML based positioning of case 1, LMF is supported for functionality-level decision making.
Proposal 14: For case 1, when option A is used, UE performs the monitoring metric calculation following NW indication.
The indication includes at least model ID/functionality information, performance metrics/threshold.
Proposal 15: For model performance monitoring of AI/ML positioning Case 1, the contents of providing monitoring outcome includes at least:​
An indication that the AI/ML based positioning method becomes invalid.​
Proposal 16: For model performance monitoring of AI/ML positioning Case 1, UE reports monitoring outcome at least:​
When the target UE has detected that the AI/ML based positioning method becomes invalid. (e.g., when the detection condition configured by LMF is satisfied.)
Proposal 17: For case 1, RAN1 follows the following procedures from step 1 to step 6 for LCM according to RAN2 agreement in RAN2#127bis. RAN1 discusses at least provide capabilities to send supported functionalities to LMF in UE feature discussion.
Proposal 18: Regarding the discussion on the applicable functionalities in UE feature for case 1, RAN1 waits for the RAN2 progress.

3GPP TSG RAN WG1 Meeting #120bis		      R1-2502830
Wuhan, Hubei, China, April 7th – 11th, 2025
	
Agenda item:             9.1.2
Source: 	Qualcomm Incorporated
Title: 	Specification support for AI-ML-based positioning accuracy enhancement
Document for: 	Discussion and Decision

1 

TDoc file conclusion not found

3GPP TSG RAN WG1 #120-bis						                       	 R1-2502911
Wuhan, China, April 7th – April 11st , 2025
Agenda item:      9.1.2
Source:                CEWiT
Title                     Discussion on specification support for AI/ML positioning accuracy  enhancement
Document for:    Discussion and Decision
__________________________________________________________________

Conclusion

Proposal 1: In Rel-19 AI/ML based positioning, regarding the time domain channel measurements, time domain sample-based measurement reporting is preferred.

Proposal 2: Based on the UE capability report and scenario related information, in Case 2b,  the LMF can recommend sample selection criteria,  optimal ranges for Nt' and k to UE.

Proposal 3: Support reusing the existing value range for ‘k’ from {0..5} specified in the specification and provide recommendations  by LMF to  UE/gNB.

Observation 1: The final decision of selection of ‘Nt’ and ‘k’ should be  upto UE’s decision and specific to each UE.

Proposal 4:  Support including IDs of Measurement collecting entities and type of input measurement collected with selected no. of samples (Nt,Nt’)and reporting granularity  (k) to include in the context information related to collected data.

Proposal 5: Support including  information (explicit or implicit) that identifies a same UE (PRU or Non-PRU UE) that both Part A and Part B are associated with along with its respective timestamps.

Proposal 6:  Support reporting UTC time to LMF everytime SFN completes its cycle.

Proposal 7 : For reporting measurement power quality,  SNR relative to a predefined threshold can be specified.

Proposal 8: LMF is preferred to take model management decisions for Case 2b and Case 3b.

Proposal 9: Out of Option A and Option B for model monitoring metric calculation for UE sided models,  Option A is preferred for monitoring metric calculation. 

Proposal 10: The monitoring outcome for Case 1,  label based model monitoring method can be a quantified value such as position error between the AI/ML estimated labels and ground truth (GT) labels or a monitoring decision informing the validity of the AI/ML model during inference.

Proposal 11: Support Alternative 1 to indicate the Geographical coordinates of the TRPs served by the gNB  to UE implicitly.
4. 

TDoc file reading error

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2502987
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	Moderator (Ericsson)
Title:	Summary #1 of specification support for positioning accuracy enhancement
Document for:	Discussion, Decision

Conclusion
For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement
For AI/ML based positioning, 
When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.
When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

Training data collection --- Pairing of Part A and Part B
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.


LS related
Agreement
Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising 
“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”
To
“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Agreement
Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.
Agreement
Final LS R1-2501523 is endorsed.
Final LS R1-2501525 is endorsed.

Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2502988
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	Moderator (Ericsson)
Title:	Summary #2 of specification support for positioning accuracy enhancement
Document for:	Discussion, Decision

Conclusion
For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement
For AI/ML based positioning, 
When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.
When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

Training data collection --- Pairing of Part A and Part B
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.


LS related
Agreement
Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising 
“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”
To
“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Agreement
Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.
Agreement
Final LS R1-2501523 is endorsed.
Final LS R1-2501525 is endorsed.

Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2502989
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	Moderator (Ericsson)
Title:	Summary #3 of specification support for positioning accuracy enhancement
Document for:	Discussion, Decision

Conclusion
For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement
For AI/ML based positioning, 
When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.
When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

Training data collection --- Pairing of Part A and Part B
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.


LS related
Agreement
Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising 
“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”
To
“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Agreement
Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.
Agreement
Final LS R1-2501523 is endorsed.
Final LS R1-2501525 is endorsed.

Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2502990
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	Moderator (Ericsson)
Title:	Summary #4 of specification support for positioning accuracy enhancement
Document for:	Discussion, Decision

Conclusion
For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement
For AI/ML based positioning, 
When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.
When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

Training data collection --- Pairing of Part A and Part B
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.


LS related
Agreement
Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising 
“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”
To
“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Agreement
Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.
Agreement
Final LS R1-2501523 is endorsed.
Final LS R1-2501525 is endorsed.

Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2502991
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	Moderator (Ericsson)
Title:	Summary #5 of specification support for positioning accuracy enhancement
Document for:	Discussion, Decision

Conclusion
For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement
For AI/ML based positioning, 
When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.
When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

Training data collection --- Pairing of Part A and Part B
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.


LS related
Agreement
Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising 
“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”
To
“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Agreement
Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.
Agreement
Final LS R1-2501523 is endorsed.
Final LS R1-2501525 is endorsed.

Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25

3GPP TSG-RAN WG1 Meeting #120bis	Tdoc R1-2503144
Wuhan, China, April 7th – April 11th, 2025

Agenda Item:	9.1.2
Source:	Moderator (Ericsson)
Title:	Final summary of specification support for positioning accuracy enhancement
Document for:	Discussion, Decision

Conclusion
For AI/ML based positioning Case 3a, regarding the time stamp in a measurement report from gNB to LMF,
Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.

Agreement
For AI/ML based positioning, 
When channel measurement is to be reported/sent, time stamp of channel measurement refers to the time instance when the channel measurement is performed.
When label is to be reported/sent, time stamp of label is the time instance for which the label is valid.

Training data collection --- Pairing of Part A and Part B
Agreement
For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, for pairing between a Part A entry and a Part B entry, the following is needed:
The time stamp of Part A (if Part A is transmitted) and the time stamp of Part B (if Part B is transmitted). 
FFS: other information is not precluded (e.g., if Part B is valid for a duration)
Note: Purpose such as “training data collection” will not necessarily be specified in RAN1 specifications.
RAN1 send an LS to RAN3 and RAN2 to inform the above.


LS related
Agreement
Send Reply LS R1-2501522 to SA2 about Case 2b with the content of Section 2 of R1-2501521 by revising 
“RAN1 would continue work and may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”
To
“RAN1 may provide additional input in the future to SA2 for Case 2b if any new agreement reached in RAN1.”

Agreement
Send Reply LS R1-2501524 to SA2 about Case 3b with the content of Section 3 of R1-2501521 by adding all the agreement made in this meeting for Case 3b.
Agreement
Final LS R1-2501523 is endorsed.
Final LS R1-2501525 is endorsed.

Agreement
RAN1 send an LS to RAN3 and RAN2 to inform them above agreements and conclusions.

Agreement
Draft LS R1-2501627 is endorsed in principle.
Agreement
Final R1-2501628 is endorsed.
Email approval by Feb 25