TDoc: S4-260239

[Technical] The proposed clause 9.2.3 introduces continuous UE pose/FoV reporting but does not specify the transport/protocol binding (e.g., which 3GPP interface, message type, timing model), making the workflow non-actionable and potentially inconsistent with TR 26.958’s assumed delivery architecture.

[Technical] Referencing “metadata format adheres to TR 26.928” is too vague: TR 26.928 contains multiple XR metadata constructs, and the contribution does not identify the exact fields (pose, projection, frustum, timestamps) nor how they map to 3DGS delivery, risking incompatible implementations.

[Technical] The server-centric workflow claims the server “maintains control over rendering budget throughout session,” but it doesn’t define how budget enforcement is verified/updated when UE conditions change (thermal throttling, background load, network degradation), which is critical for mobile feasibility.

[Technical] Both workflows omit latency/jitter handling for 6DoF feedback (prediction, time synchronization, stale pose handling); without this, viewport-adaptive selection can cause visible popping and incorrect tile selection, especially over cellular RTT.

[Technical] The “tiled environments with LOD” approach does not define tile addressing, coordinate reference system, tile boundary handling, or LOD switching rules (hysteresis), which are necessary to avoid oscillation and seams when the user moves/rotates.

[Technical] The “unstructured scenes” approach lists pruning/merging but does not define objective metrics (error bounds, screen-space density targets) or constraints to preserve visual fidelity; this reads as an algorithm sketch rather than spec-quality workflow guidance.

[Technical] The contribution introduces parameters like “max point count” and “SH degree” but does not align them with any existing 3DGS representation constraints in TR 26.958 clause 5.4/9.2.2 (e.g., whether SH degree is mandatory/optional, per-point vs per-tile), risking internal inconsistency.

[Technical] The client-centric workflow lets the UE request “quantization” and other format parameters, but there is no negotiation/error handling if the server cannot satisfy the request (fallback modes, rejection, partial compliance), which is essential for interoperability.

[Technical] Step 8 “Local Adaptation” is underspecified and potentially contradicts the earlier “budget control” premise: if UE can further adapt, the spec should clarify what is allowed (dropping points, reducing SH) and how that interacts with negotiated constraints.

[Technical] The workflows do not address caching/prefetching strategies (e.g., near-future tiles along motion vector) or continuity requirements; for large-scale scenes, purely reactive frustum streaming will likely fail bandwidth/latency targets.

[Technical] Security/privacy implications of continuous pose streaming (user location/behavior leakage) are not mentioned; at minimum, the clause should note privacy considerations or reference relevant 3GPP security guidance.

[Editorial] The document is described as a “pseudo-CR” but the proposed changes are not presented with explicit CR-style change markup, making it hard to review exact normative text deltas and to ensure clause numbering (9.2.3.1–9.2.3.4, Figures 4–6) is consistent with the current TR 26.958 v0.1.1 structure.

[Editorial] Terminology is inconsistent: “UE,” “client,” and “mobile device” are used interchangeably, and “server” is not clearly distinguished from “application server/content server,” which can confuse the architecture assumed in clause 9.2.x.

[Editorial] Several claims are absolute without qualification (e.g., “simple capability negotiation alone is insufficient”); the text should either provide supporting rationale/conditions (e.g., scene scale thresholds) or soften to “may be insufficient” to match TR study-item style.