R1-2602135
discussion
Draft reply LS on capability reporting for PRS Processing Window
From Spreadtrum
Spreadtrum's prior position on
5
at
RAN1#118bis
· AI-synthesized, paraphrased
verify sources →
Advocates for mandatory network-side additional conditions and structured configuration frameworks with sub-use case level granularity, opposing optional network-side conditions and functionality-specific approaches.
Summary
Spreadtrum argues that for AI/ML-based positioning Case 1, capability 58-2-11 (maximum number of activated PRS Processing Windows) should be signaled only to the gNB, not the LMF, because the gNB solely handles PPW configuration and activation. The document presents two main technical observations: one regarding the exclusive gNB knowledge of capability 58-2-11, and another requiring the 'Need for the gNB to know' field for capabilities 58-2-9 and 58-2-10 to be changed from 'N/A' to 'Yes'.
Position
Spreadtrum proposes that capability 58-2-11 (maximum number of activated PRS Processing Windows) be signaled exclusively to the gNB, arguing that the gNB is the sole entity responsible for mapping PPW requests into actual configurations via RRC signaling and MAC CE activation. They present a technical case against LMF involvement in PPW scheduling, stating the LMF only requests positioning services and receives final location results without intervening in activation. Furthermore, they require the table entry for capabilities 58-2-9 and 58-2-10 to change the 'Need for the gNB to know' field from 'N/A' to 'Yes', asserting that the gNB must know PRS processing type, priority handling options, and buffering capability to configure PPW parameters correctly. This position aligns with legacy positioning capability 27-23, which is also known only to the gNB.
Key proposals
- Proposal 1 (Sec 1): Capability 58-2-11 should be signaled only to the gNB, as the gNB is the sole entity mapping PPW requests into configurations and must know the UE's maximum activated PPW limit.
- Proposal 2 (Sec 1): The LMF does not intervene in the scheduling or activation of PPWs, only requesting positioning services and receiving final location results, thus it does not need capability 58-2-11.
- Proposal 3 (Sec 1): Capabilities 58-2-9 and 58-2-10 should have their 'Need for the gNB to know if the feature is supported' field changed from 'N/A' to 'Yes'.
- Proposal 4 (Sec 1): The gNB requires knowledge of PRS processing type, priority handling options, and buffering capability (covered by 58-2-9/10) to configure PPW parameters matching UE supported processing features.
- Proposal 5 (Sec 1): The stance on capability 58-2-11 is consistent with legacy (non-AIML) positioning capability 27-23, which is also sent only to the gNB.