Meeting: TSGS4_135_India | Agenda Item: 9.6
[FS_3DGS_MED] Mapping 3DGS to 3GPP services with Client-Server configuration
Samsung Research America
pCR
Agreement
| TDoc | S4-260250 |
| Title | [FS_3DGS_MED] Mapping 3DGS to 3GPP services with Client-Server configuration |
| Source | Samsung Research America |
| Agenda item | 9.6 |
| Agenda item description | FS_3DGS_MED (Study on 3D Gaussian splats) |
| Doc type | pCR |
| For action | Agreement |
| Release | Rel-20 |
| Specification | 26.958 |
| Version | 0.1.1 |
| Related WIs | FS_3DGS_MED |
| download_url | https://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_135_India/Docs/S4-260250.zip |
| For | Agreement |
| Spec | 26.958 |
| Type | pCR |
| Contact | Prakash Kolan |
| Uploaded | 2026-02-03T21:40:00.147000 |
| Contact ID | 84349 |
| Revised to | S4-260393 |
| TDoc Status | revised |
| Reservation date | 03/02/2026 21:14:43 |
| Agenda item sort order | 41 |
[Technical] The CR is internally inconsistent on the target spec: it is titled “TR 26.501 Change Request Summary” but states “Pseudo CR for TR 26.958 v0.1.1”; the exact target document, version, and clause numbering (e.g., “Clause 10.2”) must be aligned or the change cannot be applied.
[Technical] The mapping heavily relies on TS 26.565 “Split Rendering Client/Server” without justifying applicability to 3DGS streaming/generation; split rendering is defined for specific XR rendering splits, so the CR should state which split(s) are assumed and what interfaces carry 3DGS-specific data.
[Technical] “Network-side 3DGS generation from 2D capture” is mapped to “(Edge) Media AS” in TS 26.501, but TS 26.501 Media AS is primarily for media processing/delivery functions; the CR should clarify whether 3DGS reconstruction is in scope for Media AS or requires an application server outside the media architecture.
[Technical] The delivery section lists “DASH, HLS, RTP, QUIC” as protocols, but TS 26.501/26.501-based architectures typically reference specific 3GPP media profiles (e.g., DASH in TS 26.247/26.244, RTP/RTCP in TS 26.114/26.237); “HLS” and generic “QUIC” are not clearly anchored to 3GPP normative specs here.
[Technical] “Tiled LOD streaming” and “region-based parts of 3DGS scenes” are introduced without mapping to an existing 3GPP tiling/ROI mechanism (e.g., MCTS/viewport-dependent streaming concepts); the CR should specify how tiles/LOD are addressed, signaled, and synchronized with pose.
[Technical] Pose/LOD reporting is mapped to “real-time/conversational service interfaces (TS 26.506)”, but TS 26.506 is not the typical anchor for XR pose transport; the CR needs to identify the exact service/API (and directionality, timing constraints) and how it interworks with media delivery (e.g., RTP header extensions, SEI, timed metadata).
[Technical] QoS claims are problematic: “utilizing 5G URLLC” for 3DGS delivery is likely unrealistic for high-throughput media and conflicts with typical XR QoS handling (e.g., XR 5QI work); the CR should avoid implying URLLC unless it specifies which flows (pose vs media) and how they map to standardized QoS flows.
[Technical] “New 5QI for XR services” and “PDU Set based QoS” are presented as if available, but in a TR mapping clause they should be referenced to the exact 3GPP stage-2/stage-3 specs and current Rel-20 status; otherwise this reads as speculative and may contradict agreed QoS frameworks.
[Technical] “3DGS Model and Tile Caching: Utilizes 5G Edge CDN infrastructure” is vague and not mapped to a 3GPP-defined function (e.g., M4E/Edge enablers, 5GMS AF/AS roles); the CR should state whether caching is in 5GMSd, 5GMSu, or generic edge CDN outside 3GPP scope.
[Technical] The CR mixes “interactive XR service” and “6DoF media streaming” but does not state which 3GPP service category (e.g., 5GMS, MTSI, XR conversational) is assumed per workflow; this ambiguity undermines the mapping table’s usefulness and may lead to contradictory function assignments.
[Technical] Multicast/broadcast mapping to TS 26.502 is questionable: TS 26.502 is 5GMS architecture, but multicast/broadcast for media is typically tied to 5MBS/MBMS-related specs; the CR should reference the correct multicast/broadcast specifications and indicate whether 5GMS supports the intended distribution mode.
[Editorial] The contribution claims to “introduce a comprehensive mapping table” in Clause 10.2, but no actual table content (rows/columns, exact mappings) is included in the CR summary; reviewers cannot verify completeness, consistency, or whether mappings duplicate/contradict existing clauses.
[Editorial] Several references are imprecise or potentially wrong (e.g., “TS 26.501 Media-Aware Application” vs the actual 5GMS entities, “Edge Media AS” terminology); the CR should use exact entity names as defined in the target TR/TS to avoid misinterpretation.
[Editorial] “NOTE 1/NOTE 2” content is largely FFS and reads like requirements rather than mapping; if kept, it should be clearly scoped as informative text and separated from normative mapping statements to avoid overstating conclusions in a TR.