R1-2410714
discussion
Summary #1 of specification support for positioning accuracy enhancement
From Ericsson
Ericsson's prior position on
9.1.2
at
RAN1#118bis
· AI-synthesized, paraphrased
verify sources →
Advocates for sample-based measurements over legacy path-based measurements for superior performance and lower complexity, while strongly opposing phase information inclusion in model inputs due to deployment costs and minimal accuracy gains.
Summary
This 3GPP RAN1 meeting summary document (R1-2410714) from Ericsson covers AI/ML for NR Air Interface positioning accuracy enhancement, containing over 90 proposals and conclusions across 8 major sections covering model input, output, training data collection, inference, and monitoring.
Position
Ericsson advocates FOR: (1) Supporting both sample-based and path-based measurements as compromise solution to enable progress, (2) Reusing existing legacy IEs and frameworks wherever possible to minimize specification impact, (3) LMF-centric functionality management with distributed model-level monitoring, (4) Label-free monitoring methods for practical deployment. Ericsson pushes AGAINST: (1) Supporting CIR/phase information due to transmitter/receiver implementation complexity, (2) Overly complex new signaling when legacy mechanisms suffice, (3) UE-autonomous functionality management without network oversight.
Key proposals
- Proposal 2.1.1.2-1 (Sec 2.1): For sample-based measurement definition, the starting time of Nt consecutive samples is the timing of the first detected sample within a search window determined by configured offset relative to reference time, reusing existing Search Window Information IE in 38.455
- Proposal 2.1.3.2-1 (Sec 2.1): Support both sample-based and path-based measurement reports for Case 3b, with LMF signaling to gNB which type is expected to be reported
- Conclusion 2.4.2-1 (Sec 2.4): No consensus in RAN1 to support CIR (Channel Impulse Response) for determining model input in Rel-19 AI/ML based positioning for all use cases
- Proposal 3.1.2-1A (Sec 3.1): For Case 3a LOS/NLOS indicator reporting with legacy timing measurements, reuse meaning and format of existing LoS/NLoS Information IE in 38.455 as soft or hard indicator
- Proposal 4.1.2-2 (Sec 4.1): For Case 1 training data timestamps, include both NR-TimeStamp and UTCTime in TS 37.355, with UTCTime as optional field when SFN wraps around
- Proposal 4.4.2-1 (Sec 4.4): For training data collection when Part A and Part B generated by same entity, provide paired data in one report with shared timestamp
- Proposal 5.1.2-1A (Sec 5.1): For Case 1 consistency between training and inference, provide assistance information explicitly from LMF to UE as optional fields per existing specification
- Proposal 6.1.2-1 (Sec 6.1): Support label-free monitoring methods where model inference entity performs self-monitoring, with UE/gNB sending monitoring decisions to LMF when model becomes inappropriate
- Proposal 6.2.2-1B (Sec 6.2): For Case 1 label-based monitoring metric calculation, support Options A-1, A-2, A-3 with legacy framework and signaling reuse, with monitoring metric definition up to UE implementation
- Proposal 3.1.2-2A (Sec 3.1): When no associated measurement is reported, LOS/NLOS indicator is not reported for Rel-19 Case 3a
- Proposal 4.1.2-3 (Sec 4.1): For label quality indicator when generated by UE, reuse existing IE LocationUncertainty-r16 from TS37.355
- Proposal 6.2.2-2 (Sec 6.2): For Case 1 monitoring, target UE performs monitoring metric calculation and signals monitoring decision to LMF when model becomes inappropriate, with LMF making functionality-level management decisions
- Proposal 2.1.1.2-2 (Sec 2.1): For sample-based measurement parameters, candidate values for Nt include at least 16,32,64,128; Nt' include at least 9,16,32; k include at least 0-5
- Proposal 5.1.2-4 (Sec 5.1): For Case 1, specific assistance information not needed from LMF to UE neither explicitly nor implicitly
- Proposal 6.1.2-3 (Sec 6.1): LMF responsible for functionality-level performance monitoring and management decision making including functionality selection, activation, deactivation, fallback to legacy methods