3GPP TSG-RAN WG1 Meeting #121	R1- 2503238
St Julian’s, Malta, May 19th – 23rd, 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	NRPPa supports reporting for up to 64K TRPs under one gNB.
Observation 2	Bitmap reporting overhead reduction can be up to 80%, even without considering bitmap compression techniques.
Observation 3	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 4	The definition for reporting UL SRS power allows reporting total power summed over all receiver branch(es).
Observation 5	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 6	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 7	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 8	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 9	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 10	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 11	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 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. Multi-port CIR samples can achieve higher positioning accuracy only with very large signaling requirments.
Observation 13	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 14	For most given 90%tile 2D UE positioning error requirements, the DP samples requires the smallest signaling sizes.
Observation 15	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 16	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 17	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 cosidered dimension reduction techniques.
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	Time stamp for Part B may span a period of time for which the location of the UE is consistent.
Observation 22	Part A-B pairing is an issue across Case 1, 3a and 3b.
Observation 23	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 24	Knowing the model range of applicability in terms of tolerable errors in model input can save considerable signalling during the model monitoring phase.
Observation 25	Collecting sufficient data in terms of training dataset size, UE distribution, diversity of UE sources, etc, is up to implementation.
Observation 26	Label-free model performance monitoring is up to implementation of model inference entity. The only specification impact is to notify other entities of the model monitoring decision, if necessary.
Observation 27	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 specificatio impact is to notify other entities of the model monitoring decision, if necessary.
Observation 28	For Case 1, the SI only considered time-based fingerprinting approaches.
Observation 29	For Case 1, operators should have the possibility to support Case 1 without disclosing TRP location.

Based on the discussion in the previous sections we propose the following:
Proposal 1	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.
Proposal 2	For channel measurement type B, RAN1 support the following two measurement report formats for the timing information of the Nt' values:
	Method 1 (with bitmap): Use bitmap format for the list of Nt' timing values.
	Method 2 (without bitmap). Report the timing information for each of the Nt' samples (similar to reporting path timing of measurement type A).
Proposal 3	For AI/ML positioning Case 3b, regarding the power information for determining the model input, reuse the existing measurement report mapping table for SRS-RSRPP in 38.133.
Proposal 4	Do not support phase information for determining model input, including CIR and single phase value for first path/sample.
Proposal 5	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 6	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 trining and inference.
Proposal 7	If phase information is supported to enable CIR as model input, the phase values are reported in the format of relative phase.
Proposal 8	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 9	Endorse the proposed definitions for “UL time domain channel timing (UL TDCT)” and “UL time domain channel timing-power (UL TDCTP)” in editor CR for 38.215.
Proposal 10	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 LO link if carried in a legacy measurement report (Rel-18 or prior).
Proposal 11	For the new Rel-19 measurement report, the LOS/NLOS indicator (for physical LOS link) is decoupled from the timing information reporting (for virtual LOS link).
Proposal 12	For Case 3a, the “FFS: LOS/NLOS indicator” in RAN1#118bis agreement is resolved by updating the agreement by adding: “(Optional) LOS/NLOS indicator. The LOS/NLOS indicator reuses the legacy meaning and format.”
Proposal 13	The LOS/NLOS indicator in the measurement report may be generated by AI or non-AI, and there is no need to distinguish. Do not preclude the reporting of LOS/NLOS indicator when the timing information in the same measurement report is generated by AI.
Proposal 14	For AI/ML based positioning Case 3b, IE “Timing Measurement Quality” in 38.455 is reused to provide quality indicator for the entire measurement report.
	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.
	There is no need of a separate quality indicator for power information if the channel measurement includes power information in addition to timing information.
Proposal 15	For AI/ML based positioning in Case 1, if Part B is sent via LPP from LMF to UE, both IEs as described in TS 37.355 are included in the time stamp of Part B: NR-TimeStamp; UTCTime.
	From RAN1 perspective, UTCTime can be an optional field. Note: UTCTime is provided to resolve ambiguity in time stamp. For example, UTCTime is present at least when SFN wraps around.
Proposal 16	For AI/ML based positioning Case 3a, when Part B is provided to the gNB from LMF, regarding the time stamp of Part B:
	Existing IE “Time Stamp” in TS 38.455 can be reused from RAN1 perspective.
Proposal 17	For AI/ML based positioning in Case 3b, if Part B is sent via LPP from UE to LMF, both IEs as described in TS 37.355 are included in the time stamp of Part B: NR-TimeStamp; UTCTime.
	From RAN1 perspective, UTCTime can be an optional field. Note: UTCTime is provided to resolve ambiguity in time stamp. For example, UTCTime is present at least when SFN wraps around.
Proposal 18	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 19	(for conclusion) The legacy SRS configuration can be reused for Case 3b in all LCM phases, e.g. training data collection, monitoring, or inference procedures.
Proposal 20	(for conclusion) The legacy PRS configuration can be reused for Case 1 in all LCM phases, e.g. training data collection, monitoring, or inference procedures.
Proposal 21	Resolving the FFS by supporting: 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 22	(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 23	Model capability should provide the 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 Tx/Rx timing error
	FFS: additional network conditions
Proposal 24	To report the supported SNR range, the gNB / UE may report the RSRQ range over which its model is able to operate.
Proposal 25	To report the supported timing error range,
	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 supported timing error range at the TRP:
i.	gNB may report the UE timing error range over which the model can operate to the LMF.
ii.	UE may report the timing error range directly to the gNB.
Proposal 26	For AI/ML positioning Cases, label-free monitoring methods are supported, where the model inference entity performs self-monitoring without external information on the ground truth label. LMF provides functionality management.
Proposal 27	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) or gNB (Case 3a), the LMF can provide assistance information to support the calculation of model monitoring metrics.
Proposal 28	For model performance monitoring of AI/ML positioning Case 1, do not support Option B (including B-1 and B-2).
Proposal 29	For model performance monitoring of AI/ML positioning Case 1, support reporting the monitoring outcome from UE to LMF:
	(Reporting upon request) The target UE receives a LMF request on monitoring outcome; Or
	(Autonomous reporting) The target UE has detected that its model is inappropriate for performing inference.
Proposal 30	(for conclusion) For AI/ML based positioning Case 3b, 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.
Proposal 31	Do not support provision of assistance data (info #16-18) dedicated to UE-based DL-AoD, but not needed for DL-TDOA.
Proposal 32	For Case 1, regarding info #7 in the assistance data from DL-TDOA, support Alternative 2.
	If info #7 is provided implicitly (Alternative 1 or 2), associated ID is signaled by LMF to indicate whether info #7 is consistent between training and inference.
	If info #7 is not provided (Alternative 3), it is up to UE implementation to determine consistency between training and inference. No specification impact is expected from RAN1 perspective.
Proposal 33	For Case 1, to ensure the consistency of NW-side additional condition across training and inference, support associated ID for indicating NW conditions/configurations.
Proposal 34	For AI/ML based positioning, the consistency between training and inference is checked for each TRP separately.
Proposal 35	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 36	For Case 1, associated ID for consistency checking of TRP location is provided per TRP as follows:
	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.
	The TRP location ID may not be the real TRP location.
 

3GPP TSG-RAN WG1 Meeting #121	  R1-2503252
St Julian’s, Malta, May 19 – 23, 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: 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.
Proposal 3: There is no need to introduce a new reporting format for the timing information of the Rel-19 enhancement of the path-based measurement, as it suffices to use the legacy reporting format.
Proposal 4: There is no need to introduce a new definition in 38.215 to represent the timing information and power information for the Rel-19 enhancement of the path-based measurement, as the legacy UL SRS-RSRPP and UL RTOA definitions are also applicable to per path/value of Rel-19 enhancement.
Note: The rule for the selection of the paths/values can be captured in 38.455.
Model output for assisted positioning
Proposal 5: For Case 3a, LOS/NLOS indicator can reuse the same format and definition as the existing IE “LoS/NLoS Information” in 38.455.
Proposal 6: 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 7: When reporting Rel-19 type timing information, the report of the LOS/NLOS indicator should be “optional”.
Proposal 8: For Case 3a, to distinguish the reported Rel-19 type timing information from the legacy measurement-based timing information, introduce a Rel-19 type indicator to tell that the report is subject to legacy timing information or Rel-19 timing information.
The Rel-19 timing information is based on the assumption that the received SRS is subject to a line-of-sight path from the UE to the Reception Point (RP). 
Model training
Proposal 9: 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 10: For Case 3a, the label for the timing information generated from LMF can correspond to the UL RTOA/ToF between the TRP and the PRU/UE.
Proposal 11: For Case 3a training, LMF indicates to the gNB whether a delivered label for one TRP is applicable to another TRP.
E.g., based on this indication, gNB can decide whether to train TRP specific model or a common model applicable to a group of TRPs.
Proposal 12: 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 13: 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 14: For Case 3a data collection, do not support sending Part A from gNB to LMF, since model input type for Case 3a should be gNB 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 2: 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 15: 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 16: For Case 3a data collection, it is not clear on the motivation to indicate that Part B is valid for a duration.
Observation 3: For Case 3b, the pairing of Part A and Part B can be done by implementation at the LMF.
Proposal 17: 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 4: For Case 1, the actual TRP locations (i.e., Alternative 4) are not explicitly needed for the inference of the UE location.
Observation 5: 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.
After a change of TRP locations, other assistance information may change and hence, the LMF can indicate the change of the NW side additional condition by reusing other IEs, e.g., spatial direction information (Info #6), etc.
UE can obtain the explicit TRP location information by reporting the support of a legacy UE-based positioning method.
Observation 6: 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 7: 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 18: Support Alternative 3. Info #7 is not provided from LMF to UE. 
Proposal 19: 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
Observation 8: 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 9: Label-based model monitoring for Case 1 based on PRU locations can ensure more accurate label.
Proposal 20: 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 21: 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 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 monitoring outcome 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.

3GPP TSG RAN WG1 #121                                                             R1-2503348 
St Julian's, Malta, 19 - 23 May, 2025

Source:	vivo
Title:	Remaining issues on 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.
Reporting Nt from gNB to LMF does not yield any additional performance benefits for Case 3b.
Reporting Nt from gNB to LMF does not yield any additional performance benefits for 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.
It is beneficial to positioning accuracy if LMF can distinguish these two types of timing measurement.

We have the following proposals:
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.
Do not support reporting Nt from gNB to LMF for sample-based reporting of Case 3b.
Support to introduce new definitions for sample-based channel measurement in TS 38.215, instead of patching the existing path-based measurements.
Raw CIR reporting can be supported, and LMF can eliminate the impact of random initial phases of transceiver by implementation.
In addition to delay and power, at least phase information of the first path or the first sample should be supported for AI/ML based positioning Case 3b.
UL RSCP as defined in TS 38.215 can be used for measurement type (A) in Case 3b. UL time domain channel timing-power-phase (UL TDCTPP) can be defined as follows to support first sample phase information reporting for measurement type (B) in Case 3b:
There is no need to distinguish that LOS/NLOS indicator is generated by Rel-19 AI/ML positioning or legacy methods. 
Support to distinguish pre Rel-19 legacy timing measurement or Rel-19 timing measurement.
The following methods can be used to distinguish pre Rel-19 legacy timing measurement or Rel-19 timing measurement:
Legacy timing measurement and Rel-19 timing measurement share the same IE. Define a new indicator to indicate the associated timing measurement is generated by Rel-19 AI/ML positioning or legacy methods.
Define a dedicated IE for the Rel-19 timing measurement to distinguish from legacy timing measurement. 
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. 
Support Area-level associated ID for Rel-19 AI/ML based positioning Case 1. 
The network condition associated with associated ID should consist of info#6, info#7 and info#16 for Rel-19 AI/ML based positioning Case 1. 
AI Processing Unit is not considered for AI/ML based positioning Case 1 in Rel-19.

3GPP TSG RAN WG1 #121		R1-2503506
St Julian’s, Malta, May 19th – 23rd, 2025

Conclusion
In this contribution, we have the following proposals with regard to AI/ML positioning.
Proposal 1: For AI/ML based positioning Case 3b with the channel measurement type (B), the measurement parameter Nt should not be included together with the channel measurement values.

Proposal 2: For measurement report format in channel measurement type (B), reporting the timing information for each of the Nt' samples based on legacy path-based reporting.

Proposal 3: For AI/ML based positioning Case 3a, LMF shall be able to distinguish whether the timing information is pre Rel-19 legacy timing measurement or Rel-19 timing measurement.
It is up to RAN3 to decide how to ensure that LMF can distinguish between the two types of timing measurement.

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 NR-TimeStamp and UTCTime in TS 37.355 can be reused from RAN1 perspective

Proposal 5: For AI/ML based positioning Case 3b, if the label data of location is generated by PRU/non-PRU UE and transferred from the PRU/non-PRU UE to LMF, label and quality indicator of label can be provided by reusing existing IEs.
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 6: For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, Validity information of Part B can be optionally reported, e.g., the mobile status or speed of UE.

Proposal 7：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.
Validity information of Part B can be optionally reported, e.g., the mobile status or speed of UE.

Proposal 8：For AI/ML based positioning Case 1, at least support LMF to explicitly provided info#7 to UE.

Proposal 9: There is no need to introduce info #16-18 for AI/ML positioning Case 1 in Rel-19.

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

Proposal 11: For model performance monitoring of AI/ML positioning Case 1, the target UE reports monitoring outcome at least when the target UE has detected that the target UE cannot perform the Case 1 positioning method.

Proposal 12: For model performance monitoring of AI/ML positioning Case 1, the target UE may use label-based or label-free monitoring method.
The LMF makes functionality-level decision based on the monitoring outcome from the target UE without distinguishing whether the monitoring outcome are generated by label-based or label-free monitoring method.
The details of label-free monitoring method are up to UE implementation

3GPP TSG RAN WG1 #121		 R1-2503551
St Julian's, Malta, 19th – 23rd May, 2025
Agenda Item:		9.1.2
Source:				Samsung
Title:					Discussion for supporting AI/ML based positioning accuracy enhancement
Document for:	     Discussion

Conclusion
For training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG RAN WG1 #121	R1-2503649
St Julian's, Malta, May 19th–23rd, 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: There’s no need to introduce power quality for channel measurement.
Proposal 3: 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 4: In AI/ML based positioning case 3b, phase information is used  for determining model input.
Model output
Proposal 5: For reporting model output of AI/ML assisted positioning, an indicator identifying whether the measurement is based on AI/ML model is not needed, LMF can distinguish the legacy measurement and AI/ML assisted positioning case 3a based on TRP Measurement Type and TRP Measurement Result.
Proposal 6: For AI/ML assisted positioning Case 3a, angle information optionally with LOS/NLOS indicator is  supported for reporting,
If LOS/NLOS indicator is reported, the indicator can be reported as soft indicator or hard indicator as defined in 38.214.
If angle information is reported, the angle information at least can be reported via UL Angle of Arrival as defined in 38.215.
Proposal 7: From RAN1 perspective, when angle information is reported for Rel-19 AI/ML positioning Case 3a, at least the following are mandatorily or optionally supported in a measurement report from gNB to LMF:
(Mandatory) Angle information; 
(Optional) Quality of the angle information;
Existing IE “Angle Measurement Quality” can be reused.
(Mandatory) Time stamp.
Note: The final decision of “mandatory” or “optional” presence of each field is up to RAN3.
Model training and model inference
Proposal 8: For AI/ML based positioning Case 3b, 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.
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 9: For training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes angle information, support the following for providing label and quality indicator of label, 
The corresponding label is provided by LMF to gNB in the format of angle information. “Angle Measurement Quality” in 38.455 can serve as quality indicator of the label.
Note: It is assumed that user data privacy of non-PRU UE is preserved.
Proposal 10: For option A (UE initiated 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 11: For AI/ML positioning, different data collection requirements can be configured by the data collection node, where the configuration includes at least:
For Part A, Timing Measurement Quality is configured for training data collection
For Part B
When part B refers to location information, location estimate uncertainty and confidence (if included with the geographic shapes) is configured for training data collection
When part B refers to timing information, Timing Measurement Quality is configured for training data collection
Note: The data collection node can be different among different use cases.
Proposal 12: For training data collection of AI/ML based positioning, if Part A and Part B are generated by different entities, validity information of part B can be provided.
For case 3a, validity information optionally includes numbers of SFN, slots and symbols.
For case 1 and 3b, validity information optionally includes a number of SFN or utcTime.
Consistency between training and inference
Proposal 13: For AI/ML based positioning Case 1, assistance information, info #7, from legacy UE-based DL-TDOA, at least the following can be supported: 
Info #7 is provided explicitly from LMF to UE (as legacy)
Info #7 is not provided from LMF to UE
Note 1: Info #7 provided implicitly from LMF to UE could be further discussed in Rel-19 maintenance stage.
Note 2: the above info#7 is independent of other assistance information.
Proposal 14: 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 15: Label-free monitoring can be realized by implementation in a manner transparent to specification. No further discussion on label-free monitoring.
Proposal 16: 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 17: For case 3a model monitoring, LMF provides assistance data on the ground truth label to TRP, for the case when the model output includes timing information
The corresponding label is provided by LMF to gNB in the format of timing information.
Note: The corresponding label reuses the signalling for training data collection.
Proposal 18: For case 3a model monitoring, LMF provides assistance data on the ground truth label to TRP, for the case when the model output includes LOS/NLOS indicator
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17.
Note: The corresponding label reuses the signalling for training data collection.
Proposal 19: For case 3a model monitoring, LMF provides assistance data on the ground truth label to TRP, for the case when the model output includes angle information
The corresponding label is provided by LMF to gNB in the format of angle information.
Note: The corresponding label could be reused for training data collection.
Proposal 20: For case 3b model monitoring, PRU/Non-PRU UE provides ground truth label to LMF
The corresponding label is provided by PRU/Non-PRU UE to LMF in the format of location information.
Note: The corresponding label reuses the signalling for training data collection.
Draft CR for case 3b
Proposal 21: RAN1 endorses the draft CR for TS 38.215 if Rel-19 channel measurement cannot be covered by TS 38.455.

3GPP TSG-RAN WG1 Meeting #121	R1-2503719
Malta, MT, May 19th – 23th, 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 the first sample index .
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 propose that either all the timestamps corresponding to Part-A measurements be included as part of Part-B, or alternatively, the timestamp of the earliest Part-A be reported along with the time gap (in slots) between the earliest and the latest Part-A measurements.
Proposal-10: We propose that TRP/gNB location information be reported implicitly using associated IDs.
Observations
All the observations from this document are listed below:
Observation-1: The bitmap-based reporting is more efficient than its counterpart, requiring 22.2% fewer bits, on an average, to report the sample time information.
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: The differential power reporting incurs 8% less overhead compared to the fixed quantization-based mechanism.
Observation-4: 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-5: 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-6: 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-7: 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-8: Moreover, collecting accurate NLoS measurements in practice is extremely challenging. Therefore, the rationale for reporting NLoS measurements remains unclear to us.
Observation-9: 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-10: The descriptive information alone might not be sufficient for site-specific efficient training. 
Observation-11: The receiver should also report information to associate context related to validity area, recency, implementation, link conditions etc.
Observation-12: 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-13: For the AI-ML models to work efficiently, the TRP/W and UE sided conditions should be same during training and inference phase.
Observation-14: The geographical coordinates of the TRPs is sensitive information and must be protected, especially considering that the UE may store it on an OTT server for consistency checks.

3GPP TSG-RAN WG1 Meeting #121	R1-2503750
St Julian’s, Malta, May 19th – 23rd, 2025

Source:	TCL
Title:	Remaining issues 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 proposals:
Proposal 1: For the measurement report format of channel measurement type (B), support both of Method 1 (with bitmap) and Method 2 (without bitmap).
Proposal 2: For training data collection of AI/ML based positioning 3a/3b, if Part A and Part B are generated by different entities, the validity information of Part B should be reported 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 reported.
b. the starting time and the end time associated with Part B are reported.
Proposal 3: For the indication of info #7 from legacy UE-based DL-TDOA, Alternative 1 is preferred.
Proposal 4: For the detailed definition of associated ID, Option 1 is preferred and the time stamp should not be part of associated ID.
Proposal 5: Option B should not be supported for the label-based model monitoring for AI/ML positioning Case 1.
Proposal 6: LMF is responsible for functionality management decision making.
Proposal 7: 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.

3GPP TSG RAN WG1 #121 		                                    		   R1-2503751
St Julian’s, Malta, May 19th – 23rd, 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.
Determination of consistency in NW side conditions
Observation 1: For the trained AIML model to be applicable, consistency between training and inference should be maintained.
Proposal 1: For Case 1, support to combine assistance data used for UE-based DL-TDOA and UE-based DL-AoD to enable the UE to check NW side additional conditions
Observation 2: Assistance data for the Case 1 positioning method can be used for checking consistency in NW side conditions and derivation of UE location during performance monitoring
Observation 3: Including TRP location in assistance data enables the UE to determine its location based on the assistance data for Case 1 positioning method
Observation 4: Excluding TRP location in assistance data may create additional signaling overhead for the UE to request for configuration of other positioning method(s) to determine its location.
Proposal 2: Adopt Alternative 4, “Info #7 is provided explicitly from LMF to UE” to maintain consistency in NW side conditions between training and inference phase
Proposal 3: 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 4: Tolerance for difference in assistance information (e.g., network synchronization error, difference in boresight angles) should be specified
Proposal 5: Time validity for an AIML model(s) should be specified
Determination of consistency in UE side conditions
Proposal 6: 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 7: 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
Performance monitoring
Proposal 8: For LCM Option A, as a performance monitoring outcome, the UE can report the difference between the ground truth and AIML output to the LMF
Phase measurement
Observation 5: 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 9: Support to report phase measurement for the sample-based measurements (type-B measurement)
Proposal 10: Support first-path phase measurement, namely RSCP and RSCPD, for AIML based positioning for type-A measurement
Case 3a : AIML assisted positioning with gNB-side model
Proposal 11: For AIML assisted positioning, support an indication in the measurement report to indicate the reported LOS/NLOS indicator is inferred by an AIML model(s).
Proposal 12: 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”
Proposal 13 : Timing information reported with the inferred LOS indicator follows the definition of RTOA in TS 38.215
Proposal 14: For the definition of inferred UL-RTOA, down-select from the following options;
Option 1 : Inferred UL-RTOA is time of flight for a virtual LOS path between a TRP and UE
Option 2 : Inferred UL-RTOA is actual time of flight for a link between a TRP and UE
Proposal 15 For AIML assisted positioning, support an indication in the measurement report to indicate the reported timing information is inferred by an AIML model(s).

3GPP TSG RAN WG1 #121	                                                                                  R1-2503771
ST Julian’s, Malta, May 19th – 23rd, 2025

Source:	CATT, CICTCI
Title:	Discussion on Al/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 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 4: 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 5: 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 6: 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 7: 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 8: 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 9: For case 3b, gNB/TRP can report Nt along with the channel measurements to LMF.
Proposal 10: 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 selected sample (among all the Nt' selected samples) 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 11: 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 12: Phase measurement and reporting is supported for case 3b.
Proposal 13: 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 14: 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 15: For AI/ML-assisted positioning, when timing measurement is obtained by AI/ML, do not support reporting legacy LOS/NLOS indicator in the associated measurement report.
Proposal 16: 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 17: 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 18: 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 19: For better model performance monitoring of AI/ML positioning case 1 (including label-free monitoring), when UE reports monitoring outcome to LMF, besides an indication that the target UE cannot perform the Case 1 positioning method, the report can also include:
Monitoring metrics
Confidence-level of monitoring metrics
Confidence-level of UE-side LCM decisions
Requested PRS configuration
Preferred TRP set
Proposal 20: 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 21: 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 22: 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 23: 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 24: 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 25: 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 26: 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. 

3GPP TSG RAN WG1 Meeting #121				      R1-2503811
St Julian's, Malta, May 19th – 23rd, 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 long-term model monitoring requested by the UE. This may include an on-demand request for DL-PRS configuration to enable long-term monitoring at the required time intervals.

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
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 #121	  R1-2503821
Malta, MT, May 19th – 23rd, 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 AI/ML based positioning, assistance information, info #7, from legacy UE-based DL-TDOA, can optionally be provided explicitly from LMF to UE(as legacy).
•	If info #7 is not provided, it is up to UE implementation to determine consistency between training and inference.
Proposal 10: 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 11: 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 12: It is necessary to distinguished AI based positioning from legacy UE positioning as a new UE capability.
Proposal 13: For UE-side AI based positioning, a new UE capability for the number of PRS resources should be defined.

3GPP TSG RAN WG1 #121			R1-2503873
St Julian’s, Malta, May 19th – 23rd, 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, Option B (The LMF performs monitoring metric calculation) is not supported 
Proposal 3:  For the report of monitoring outcome, support the proactive report and Reactive report
For the proactive report, it is up to UE implementation when to perform proactive report 

The proposals for Case 3a are summarized as follows:
Proposal 4: 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 5: 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 6: For the indicating of Nt’ samples, reuse the indication principle of the Path-based report 

3GPP TSG RAN WG1 #121                                         R1- 2503921
St Julian’s, Malta, May 19th – 23rd, 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 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 2:	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 3:	It is almost impossible that time stamp of Part A and time stamp of 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 4:	The previous agreement on the definition of timestamp is enough to cover the scenario that the UE is static.
−	If the UE is static, a same UE location can be associated with multiple timestamps with different value (if new positioning procedure is triggered) or same value (if new positioning procedure is not triggered)
Observation 5:	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:	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 when the value of Nt used by gNB is less than what LMF signalled.
Proposal 2:	For Case 3b, support to report phase information from gNB to LMF as model input data.
Proposal 3:	For Case 3a, there is no need to report LOS/NLOS indicator to LMF if the model output is timing/angle information.
Proposal 4:	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 5:	Support to introduce a quality indicator for power information in channel measurement for generating model input.
Proposal 6:	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 7:	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 8:	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 9:	Use "UTC time + SFN + slot index" as a baseline, with details FFS
Proposal 10:	Consider following two options as baseline to design the time stamp for channel measurement in Case 3b:
Proposal 11:	Pair the Part B with Part A whose time stamp around the time stamp of this Part B.
−	A threshold can also be provided to indicate whether a Part A and a Part B can be paired. If the 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 12:	Specify the pairing quality for measuring the timing difference between the time stamp of Part A and time stamp of Part B, if pairing operation for this Part A and Part B is required.
Proposal 13:	Regarding the FFS that “other information is not precluded (e.g., if Part B is valid for a duration)”, it can be resolved by: valid duration of Part B is not needed to be specified.
Proposal 14:	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.
Proposal 15:	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 16:	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 17:	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 18:	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 19:	Support Alternative 1 for ensuring consistency in aspect of TRP location (Info #7).
Proposal 20:	If associated ID is used to ensure the consistency, an associated ID can be related to multiple TRPs that involve in data collection.
Proposal 21:	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 22:	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 #121 	R1-2503951
St Julian’s, Malta, May 19th – 23th, 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 measurement report of AI/ML assisted positioning Case 3a, when timing information is reported from gNB to LMF, support Option 2:
Option 2: LMF shall be able to distinguish whether the timing information is legacy timing measurement or Case 3a timing measurement. 
It is up to RAN3 to decide the potential specification impact on how to ensure that LMF can distinguish between the two types of timing measurement.
Proposal 2: From RAN1 perspective, when timing information is reported for Rel-19 AI/ML positioning Case 3a, at least the following are mandatorily or optionally supported in a measurement report from gNB to LMF:
(Mandatory) timing information; 
(Optional) Quality of the timing information;
Existing IE “Timing Measurement Quality” can be reused.
(Mandatory) Time stamp.
(Optional) LOS/NLOS indicator.
Note: The final decision of “mandatory” or “optional” presence of each field is up to RAN3.
Proposal 3: 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 4: For AI/ML positioning Case 1, for the definition of associated ID, support Option 1:
Option 1. Associated ID for a network condition is provided with the same granularity (e.g., per-TRP, per-ARP) as in the existing specifications. 
It is composed of an ID for the network condition. Note: the ID need not to take the real value of the network condition
FFS: Time stamp on when the network condition is set. The ID is valid from the time of the time stamp.
RAN1 studies the validity condition of the ID value, i.e., the value range of the network condition corresponding to a given ID value.

3GPP TSG-RAN WG1 Meeting #121	R1- 2503997
St Julian’s, Malta, May 19th – 23rd, 2025

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

Conclusion
For training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG RAN WG1 #121		R1-2504025
St Julian’s, Malta, May 19th – 23th, 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#121							    R1-2504040
St Julian’s, Malta, May 19th – 23rd, 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:  Separate definitions for sample-based measurements for (a) timing information and (b) paired timing and power information need more clarity and need to be sufficiently distinguishable from the legacy measurement definitions. Additionally, the use of phrases such as “timing”, “timing information” and “timing instances” cause further ambiguity as there is no mention of “samples” and the definition of   differs from UL TDCT and the UL TDCTP definitions, which should not be the case.

Observation 2: There is an ambiguity in the RAN1#120bis agreement, where there is a dependency that Case 1 positioning method cannot be performed subject to a UE reported performance monitoring outcome/result, which implies other Case 1 LCM-related procedures such as data collection, further training and inference, model update cannot be performed. There is no need to couple the whole Case 1 method behavior with performance monitoring, which is just one of the LCM procedures.
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: 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 3: 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 4: 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 5: 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 6: 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.

Proposal 7: RAN1 to discuss the following options on how to capture sample-based measurements in TS 38.215:
Option 1: Capture sample-based (a) timing information and (b) paired timing information and power information agreements under legacy measurement definition clauses 5.2.2 UL-RTOA, 5.2.3 gNB Rx-Tx time difference measurements and 5.2.6 UL SRS reference signal received path power (UL SRS-RSRPP).
Option 2: Separately capture sample-based (a) timing information and (b) paired timing information and power information agreements only if there is sufficient distinguishability from legacy measurement definitions.
Option 3: Only capture sample-based (a) timing information and (b) paired timing information and power information in the TS 38.455 (RAN3) specification with no TS 38.215 impact.

Paired associated between gNB Rx-Tx time difference and UE Rx-Tx time difference measurements
Proposal 8: 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 9: Channel measurement in Part A of a Training Data samples is to be defined according to a existing DL or UL channel measurements that have been already specified in TS 38.215, including the measurement of the paired timing information and power information.

Proposal 10: 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 11: 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 12: 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 13: 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 14: 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 or other implicit mechanisms may be used to implicitly signal Info#16.

Proposal 15: RAN1 to support the target UE/device to request the validity area for training and/or inference to ensure consistency between training and inference. Requested validity area can reuse legacy AreaID-CellList-r17 information elements such as PCI, NCGI and ARFCN, which in combination are globally unique within a certain deployment.

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 additionally include the horizontal/vertical positioning accuracy indicators or a hard/soft indicator.
Proposal 21: If the target UE can perform AI/ML positioning Case 1, there may be a need to indicate the unavailability of the performance monitoring outcome/result to the LMF.

Proposal 22: 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.

Proposal 23: 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 24: Supported functionalities are essentially UE capabilities, which according to RAN1 may be static and/or dynamic depending on UE conditions and network configuration.

Proposal 25: The inference positioning configuration, e.g. DL-PRS is provided using a combination of the DL-PRS configuration included in the LPP ProvideAssistanceData message, e.g., DL-PRS configuration and the reporting configuration provided in the LPP RequestLocationInformation message.

3GPP TSG-RAN WG1 Meeting #121	    R1-2504059
St Julian's, Malta, 19 - 23 May 2025

Agenda Item: 	9.1.2
Source: 	Sony 
Title: 	On Supporting AI/ML Based 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: 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 3: Support sample-based reporting as the AI/ML model input for Case 2b.
Proposal 4: 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 5: For ensuring consistency between AI/ML model training and inference, support the usage of associated ID that represent the network condition, which may include the time stamp when the network condition is set.
Proposal 6: For AI/ML positioning case 1, the associated ID is provided explicitly from LMF to UE.
Proposal 7: 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 8: 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 9: 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 Meeting #121	R1-2504081
St Julian’s, Malta, May 19th – 23rd, 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: It is not harmful to introduce new measurements for supporting the gNB/TRP which is capable of using different implementation methods to do path detection and to do sample detection, even if some gNBs/TRPs may use the same/similar implementation method to detect path and detect sample.   
Observation-2: 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-3: 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-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: Regarding the three options for the draft CR of 38.215, Option 1 is supportive. 
Proposal-2: The FFS related to Nt for (B) Rel-19 enhanced measurement can be concluded as one of measurement parameters given by higher layers like Nt' or k.
Proposal-3: The measurement report formats for the timing information of the Nt' values for (B) Rel-19 enhanced measurement can be left to RAN3 for further study, including: 
Method 1 (with bitmap): Use bitmap format for the list of Nt' timing values. The measurement report may also include other information, e.g., the starting point of the bitmap, length of bitmap.
Method 2 (without bitmap). Report the timing information for each of the Nt' samples (similar to reporting path timing of measurement type (A)).
Proposal-4: For Rel-19 AI/ML based positioning Case 3b, phase measurement and reporting are not supported.
Proposal-5: For Rel-19 AI/ML based positioning Case 3a, if timing information in the measurement report is generated by Case 3a, two alternatives on the reporting of LOS/NLOS indicator can be considered for down-selection in this meeting:
Alt-1: LOS/NLOS indicator is not sent with the timing information
Alt-2: LOS/NLOS indicator is set to 1 if sent with the timing information
Proposal-6: For AI/ML based positioning Case 1, info #7 cannot be provided from LMF to UE in an explicit way.
Proposal-7: For AI/ML based positioning Case 1, UE can assume the training-inference consistency related to TRP location is kept if the same associated ID is provided from NW-side for both model training and model inference.
4 

3GPP TSG RAN WG1 Meeting #121						          					    R1-2504113
Malta, MT, May 19th – 23th, 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 31: For Case 3b (LMF side model), for inference LMF may request reporting of UL measurements from gNB via legacy mechanisms defined in NRPPa.
Proposal 32: For Case 1, the so-called “inference configuration” indicated to UE corresponds to the  requested location information with any 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 33: For Case 1, no inference reconfiguration is expected based on dynamic applicability report from the UE after UE receives the inference configuration.
Proposal 34: Send an LS to RAN2/RAN3 to indicate the updated set of higher layer parameters for AI/ML positioning after RAN1#121 (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



Agreements reached in 3GPP RAN1#120bis meeting


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


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

3GPP TSG RAN WG1 #121	R1-2504130
St Julian’s, Malta, May 19th – May 23th 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: For reporting channel measurement type (B), adopt the use of an offset and a bitmap.
The offset indicates the duration (in samples) between the reference time and the start time of the list of Nt consecutive values.
The bitmap, with a length of Nt, encodes the presence or absence of the Nt’ reported samples within the measurement window.

Proposal 2: For Case 3a, the LOS/NLOS indication generated by an AI/ML model has the same interpretation as that in legacy positioning methods. Therefore, differentiation between the two is not necessary.

Proposal 3: The LOS/NLOS indicator should be used only in conjunction with legacy timing measurements. 

Proposal 4: Timing measurement reports should clearly distinguish between legacy timing measurements and those generated by AI/ML-based positioning.

Proposal 5: For Case 3a, timing information generated by AI/ML model should be used independently, without incorporating the LOS/NLOS indication.

Proposal 6: For Case 1, introduce the Associated-ID, which includes at least the following fields:
TRP Identification
LAST_UPDATE_TIME

3GPP TSG RAN WG1 #121		R1-2504224
St Julian’s, Malta, May 19th – 23rd, 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 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: For channel measurement type (B), method 2 is used for reporting the timing information of the Nt' values:
Method 2: Report the timing information for each of the Nt' samples (similar to reporting path timing of measurement type (A)).
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 positioning Case 1, the associated ID can be related to info#7, the definition is as follows:
Associated ID for a network condition is provided with same granularity (e.g., per-TRP, per-ARP) as in the existing specifications. Associated ID included an ID for NW-side condition.
Proposal 9: For AI/ML positioning Case 1, it is up to target UE implementation to check at least assistance data provided by LMF to determine consistency between training and inference.
Proposal 10: 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 11: 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 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 12: 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 signaling.
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 13: 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 14: 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 15: 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 16: For training data collection of AI/ML based positioning Case 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 can be optionally reported in addition to the time stamp of Part A and the time stamp of Part B.
The validity duration between time stamp of Part A and time stamp of Part B.
Proposal 17: 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 B.
The validity duration between time stamp of Part A and time stamp of Part B.
Proposal 18: 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 19: 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 20: 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 pre Rel-19 legacy timing measurement or Rel-19 timing measurement. 
It is up to RAN3 to decide how to ensure that LMF can distinguish between the two types of timing measurement.
Proposal 21: The “FFS: LOS/NLOS indicator” in RAN1#118bis agreement is resolved by updating the agreement as follows:

Proposal 22: 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.
Proposal 23: 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 24: 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 25: 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 26: 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 27: 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 28: 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 29: 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 #121		R1-2504285
St Julian, Malta, May 19th – May 23rd, 2025
Agenda Item:	9.1.2
Source:	Indian Institute of Technology Madras (IITM)
Title:	Discussion on Specification Support of AI/ML for Positioning Accuracy Enhancement
Document for: 	Discussion

Proposals:
Based on the above observations we propose the following:
Proposal 1: Nt should be reported as one of the enhanced measurement parameters for Rel-19.
Proposal 2: Reporting Nt along with k will avoid aliasing and increase the reporting efficiency.
Proposal 3: Reporting Nt along with Nt’ will avoid and static thresholds. 

3GPP TSG RAN WG1 #121	R1-2504309
St Julian’s, Malta, May 19th – 23th, 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: For channel measurement type (B):
Increase the number of additional paths supported (the value range of Nt) to 32, 64, 128
For measurement report formats for the timing information of the Nt' values report the timing information for each of the Nt' samples (similar to reporting path timing of measurement type (A)).


Proposal 2: 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 3: 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 4: 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 5: 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 6: 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).

Proposal 7: 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 still indicates the NLOS/LOS characteristics of the channel. 
The report should also include an indicator that the other associated measurement was obtained by AI/ML 

Proposal 8: For timing information obtained by both legacy and AI/ML 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 i.e. legacy meaning
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 9: the working assumption on entities to generate measurements and labels in RAN1 #116bis and RAN1 #117 should be approved

Proposal 10: 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 11: 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
The associated ID may be provided per area, where the area is indicated via a list of cell IDs
The number of bits for the associated ID is [8] bits.


Proposal 12: For AI/ML based positioning Case 1, 
all assistance information from legacy UE-based DL-AoD can be provided from LMF to UE.
the target UE checks at least assistance data provided by LMF to ensure consistency between training and inference.
If there is difference in assistance data between training and inference, it is up to target UE to determine whether the difference is within the tolerance range of the trained model (e.g., considering the training dataset and the generalization capability of the model).

Proposal 13: 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 14: the default option is for the monitoring to occur at the entity with the AI/ML model. 

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


Proposal 16: 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 17: 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 18: RAN1 should support at least Option A-2, and B-1.


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

Case Specific non-GT Monitoring 

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

Proposal 22: 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 23: 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 #121		      R1-2504385
Malta, MT, May 19th – 23rd, 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 #121			R1-2504465
St Julian’s, Malta, May 19th – 23rd, 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.
Observation 1: The Method 1 (Bitmap format) and Method 2-2 (Legacy-like optimized format) have a less overhead compared to the Method 2-1 (Legacy format).
Proposal 1: For AI/ML based positioning, one or two of the following methods are supported for reporting of channel measurement (B):
Method 1: Use bitmap format for the list of  timing values.
Method 2-2: Report the timing information for each of the  samples using the legacy first path report for the first  sample and optimized report for Rel-19 channel measurement type (B), where the value range of each remaining samples is ().
Proposal 2: For measurement report of AI/ML assisted positioning Case 3a, support Option 3: LMF shall be able to distinguish whether the report (timing information and optionally LOS/NLOS indicator) is a legacy report or not.
Proposal 3: For training data collection of AI/ML based positioning, at least Case 3b, validity information is associated and sent together with Part B from UE/PRU.
Observation 2: The valid duration of the label depends on the UE mobility. However, the LMF should determine the appropriate valid duration for each corresponding label since the LMF has an AI/ML model.
Proposal 4: For training data collection of AI/ML based positioning Case 3b, the mobility information is provided along with the Part B.
Proposal 5: For AI/ML based positioning Case 1, assistance information, info #7, from legacy UE-based DL-TDOA, the following can be supported:
Info #7 is provided explicitly from LMF to UE (as legacy)
Info #7 is provided implicitly from LMF to UE
The implicit indication is associated ID
UE assumes the similar properties of info #7 associated with the same associated ID
Info #7 is not provided from LMF to UE
UE assumes info#7 is not associated with the any associated ID or explicit indication of info#7
Note: the above on info#7 is independent of other assistance information
Proposal 6: For AI/ML based positioning Case 1, UE may assume the similar properties of info#7 within the same area associated with the same associated ID.

3GPP TSG RAN WG1 # 121		R1-2504492
St Julian’s, Malta, May 19th – 23rd, 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: For performance monitoring metric calculation of AI/ML based positioning of case 1, each option has different benefits and each option is feasible without any specification impacts by reusing existing procedures and IEs.
Observation 2: 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 3: 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: If part A and part B info are generated by different entities, a duration that part B is valid is considered.
Part A and part B can be paired only when part B is valid.
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, support method 2. 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, support version 1 as a compromise.
Info #7 is provided implicitly via associated ID or explicitly based on the indication by LMF.
If info #7 is not provided, it is up to UE implementation to determine consistency between training and inference. 
Proposal 9: For the details of associated ID, support Option 1.
Real TRP location value is not necessary. ID which shows only if the condition is consistent or not is sufficient.
Time stamp is not a part of additional condition, but some time information which consistency is ensured may be beneficial.
Proposal 10: 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 11: For AI/ML assisted positioning (i.e., Case 3a), support Option 2 that LMF distinguishes whether the timing information is legacy timing measurement or Case 3a timing measurement. 
It is up to RAN3 to decide how to ensure that LMF can distinguish between the two types of timing measurement.
Option 3 can be also agreeable if no LOS/NLOS indicator-specific indicator is introduced.
Proposal 12: When timing information is reported for Rel-19 AI/ML positioning Case 3a, LOS/NLOS indicator is not necessary.
Proposal 13: For performance monitoring metric calculation of AI/ML based positioning of case 1, it is not necessary for RAN1 to discuss/down-select each option.
Proposal 14: For performance monitoring of AI/ML based positioning of case 1, LMF is supported for functionality-level decision making.
Proposal 15: For AI/ML based positioning of case 1/3a, assistance data for label-free monitoring is not necessary.
Proposal 16: 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 17: For model performance monitoring of AI/ML positioning Case 1, UE reports monitoring outcome when the target UE has detected that the target UE cannot perform the Case 1 positioning method. (e.g., when the detection condition configured by LMF is satisfied.)
Proposal 18: 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 19: Regarding the discussion on the applicable functionalities in UE feature for case 1, RAN1 waits for the RAN2 progress.
Proposal 20: For reporting of ground truth label, it is up to RAN2 to decide how to send it. Example of the proposed table is shown below.
Proposal 21: New parameter to request channel measurement type {path-based measurement, Rel-19 enhanced measurement} is necessary. Example of the proposed table is shown below.
Proposal 22: New parameters to request Nt, Nt’, and existing parameter to report k, are necessary. Example of the proposed table is shown below.

3GPP TSG-RAN WG1 #121	R1-2504570
St Julian’s, Malta, 19th May – 23th May, 2025

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

Conclusion
Proposal 2-1: For info#7, consider associated ID with a range of values for an area

Proposal 2-2: For info#7, the integer range of the associated ID could be 2 to power of the TRP number within an area, or has it fixed as 256 (same as range for dl-PRS-ID-r16)

Proposal 2-3: There is no need for LMF to trigger UE for performance monitoring

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

TDoc file reading error

3GPP TSG RAN WG1 #121						                       	 R1-2504596
Malta, MT,  May 19th – May 23rd, 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.

Observation 2:  The reporting of validity information will depend of the prior information exchange of the UEs mobility related information such as velocity of UE  between the UE and the data collecting entity. 

Proposal 6:  The reporting of validity information will depend on the prior information exchange of the UE’s mobility related information  between the UE and the data collecting entity. 

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

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

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

Proposal 10: 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 11: 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 12: Support Alternative 1 to indicate the Geographical coordinates of the TRPs served by the gNB  to UE implicitly.
4. 

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504691
St Julian’s, Malta, May 19th – 23rd, 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 training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504692
St Julian’s, Malta, May 19th – 23rd, 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 training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504693
St Julian’s, Malta, May 19th – 23rd, 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 training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504694
St Julian’s, Malta, May 19th – 23rd, 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 training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504695
St Julian’s, Malta, May 19th – 23rd, 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 training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator. 

3GPP TSG-RAN WG1 Meeting #121	Tdoc R1-2504955
St Julian’s, Malta, May 19th – 23rd, 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 training data collection of Part B in AI/ML based positioning Case 3a, for the case when Part B label includes the LOS/NLOS indicator, 
The corresponding label is provided from LMF to the gNB by using the existing IE LOS-NLOS-Indicator-r17. There is no need of a separate field for quality indicator of LOS/NLOS indicator.