Huawei · 9.1.2

Huawei argues that ambiguity in sample-based measurements for Case 3b can be avoided by implementation rather than strict specification, proposing that gNBs flexibly determine selection window parameters (Nt, Nt', k) while capping Nt' at 16 and Nt at 64 to protect proprietary channel estimation. They support enhancing legacy path-based reporting by increasing the number of reported paths to 16, citing simulation results showing sub-meter accuracy improvements. For Case 3a, they propose reusing the legacy 'LoS/NLoS Information' IE and distinguishing AI/ML timing outputs via timing quality indicators or new Rel-19 indicators. Regarding Case 1, they oppose introducing new positioning methods or implicit signaling, insisting on reusing legacy DL-TDOA assistance data explicitly. For monitoring, they argue that LMF involvement in Case 1 metric calculation is unnecessary and that Case 3a monitoring should rely on measured/non-measured result reporting to imply activation/fallback.

Huawei advocates for pragmatic implementation-based solutions over rigid standardization, arguing that ambiguity issues can be resolved through consistent vendor implementations rather than tight specifications. They strongly oppose complex new signaling mechanisms, pushing instead for reuse of legacy mechanisms (path-based measurements, existing quality indicators, LocationUncertainty for labels). They resist introducing new IDs or complex assistance data, favoring implementation flexibility and proprietary protection (limiting sample count to 16). This positions them against companies likely pushing for more standardized, tightly-specified approaches.