RAN1 / #124bis / NR_AIML_air / Verify

Spreadtrum · 5

Incoming Liaison Statements · RAN1#124bis · Source verification
Every position summary on this site is generated by an AI from the actual Tdoc contributions. This page shows you the exact source documents the AI read to produce the summary above, so you can verify it yourself. Click any Tdoc ID to view its detail page, or click "3gpp.org ↗" to read the original on the official 3GPP server.

Contributions at RAN1#124bis · 1 doc

R1-2602135 discussion not treated 3gpp.org ↗
Draft reply LS on capability reporting for PRS Processing Window
Position extracted by AI
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.
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'.

Prior contributions at RAN1#118bis · 1 doc · Oct 14, 2024

R1-2407692 discussion not treated 3gpp.org ↗
Discussion on LS on applicable functionality reporting for beam management UE-sided model
Position extracted by AI
Spreadtrum advocates FOR mandatory network-side additional conditions and structured configuration frameworks, pushing for sub-use case level granularity and comprehensive inference configuration requirements. They are positioned AGAINST optional network-side conditions and functionality-specific additional conditions, emphasizing the need for UE guidance through proper network configuration rather than autonomous UE decision-making.
Summary
Spreadtrum provides RAN1's response to RAN2's liaison statement on applicable functionality reporting for beam management UE-sided AI/ML models, presenting 8 comprehensive proposals addressing granularity, network-side conditions, configuration content, and activation mechanisms.
How this was derived
The AI extracted the "position extracted" field above directly from each Tdoc during summarization. Always verify critical claims against the original Tdocs linked above.