Meeting: TSGS4_135_India | Agenda Item: 9.6
18 documents found
[FS_3DGS_MED] pCR on 3D tiles, LOD and 3DGS delivery format requirements
This change request proposes comprehensive updates to TR 26.958 to address 3D Gaussian Splatting (3DGS) encapsulation and delivery format requirements, with particular focus on spatial random access and level of detail (LOD) mechanisms. The document introduces three main changes to improve clarity and technical accuracy.
3DGS tile (new definition): A spatial volume of the scene represented by a specific bounding volume, containing a set of 3D Gaussians for a given level of detail (LOD)
Levels of detail (new definition): Multiple representations of a scene, each with a different set of data which represents different qualities of the scene for a compromise between visual detail and data size
3D tile (modified/removed): The previous generic definition ("discrete spatial partition of a massive geospatial dataset") is replaced with the more specific "3DGS tile" definition to better align with 3DGS-specific requirements
Rationale: The original TR lacked an LOD definition and used a non-3DGS-specific definition for 3D tiles. The new terminology better reflects the technical requirements for 3DGS delivery.
Terminology Harmonization: - Replaces generic "3D tiles" references with "3D Gaussians" in use case descriptions - Updates "3D tiles" to "3DGS tiles" in working assumptions with reference to new technical clause - Maintains LOD terminology as it is widely understood in 3D graphics
Key Technical Aspects: - Adaptive delivery of 3D Gaussians at various LODs based on user pose and device capabilities - Selection process maintains constant number of displayed splats for quality consistency - Interactive delivery mechanism for 3D Gaussian sets at various detail levels - Constrained navigation within captured regions
Compression and Packaging: - 3DGS tiles with different LODs serialized into delivery format - Signaling for spatial and LOD indices and dependencies - Editor's notes identify need for: - Workflow documentation for different uplink/downlink traffic profiles - Characterization of Gaussian parameters requiring signaling - Evaluation of existing 3GPP media delivery frameworks
Transport and Delivery: - Interactive delivery with predictive prefetch - Edge-assisted content hosting for latency control - Buffering strategies to minimize latencies and visual artifacts
Decoding and Rendering: - UE parses 3DGS tile indices and manages GPU residency - Real-time splat-based rendering with tile/LOD switching - Navigation constraints based on capture information and collision detection - Editor's note on expressing "allowed navigation volume"
This represents the major technical contribution, introducing a comprehensive new clause (Clause X) covering:
Core Concepts: - 3DGS scalability requires support for: 1. Position-based random access of 3D Gaussians 2. Delivery/rendering of different LODs
Technical Relationship: - Spatial random access and LOD are non-orthogonal (same spatial volume can have different Gaussian sets for different LODs) - Viewing frustum (derived from user pose) determines required spatial volumes and LODs - Frustum includes: position, orientation, horizontal/vertical FoV, viewing distance - Mechanisms relevant to both rendering efficiency and delivery optimization
Two Primary Requirements Identified:
3D Gaussian Set Identification: Method to identify 3DGS data into sets enabling association of 3D Gaussians at different LODs with spatial volumes
Frustum-Based Access: Method to identify and access required 3D Gaussians at different LODs using user's frustum for efficient delivery, access, and rendering
Technical Definition: - Method to associate spatial volumes with 3D Gaussians through 3DGS tiles - 3DGS tile = spatial volume with specific bounding volume + set of 3D Gaussians for given LOD
Editor's Note: Indicates need for additional technical details
Compression Technology Requirements:
LOD and Partial Delivery Support: Ability to support LOD and partial spatial data delivery without compression optimization dependency
Optimized Compression: Real-time compression of 3DGS data optimized for LOD support and partial spatial delivery
The changes establish a structured framework for: - Standardized terminology for 3DGS spatial organization - Clear requirements for encapsulation and delivery formats - Foundation for future work on compression, signaling, and delivery protocols - Alignment with interactive 6DoF streaming requirements from TR 26.928
The proposal moves from use-case-embedded technical concepts to a dedicated technical clause, providing clearer separation of concerns and enabling more detailed specification development.
[FS_3DGS_MED] pCR on editorial changes
This is an editorial change request for the 3D Gaussian Splatting for Media study item Technical Report. The document proposes non-technical corrections and clean-up modifications to improve the clarity and consistency of TR 26.958.
The document identifies the need for editorial corrections and clean-up in the current version (v0.1.1) of TR 26.958. These changes are purely editorial in nature and do not affect the technical content or agreements previously made in the study.
The contribution proposes to incorporate editorial modifications to TR 26.958 v0.1.1. The specific editorial changes are contained in an attached document (not visible in the provided content).
This is a maintenance-type contribution focused on: - Editorial corrections - Document clean-up - Improving readability and consistency
Note: The actual detailed editorial changes are not visible in the provided HTML document as they would be in the attachment referenced by the contribution.
[FS_3DGS_MED] glTF-based Representation Formats for 3D Gaussian Splats
This contribution addresses Objective 2c of the FS_3DGS_MED Study Item ("Determine relevant formats") by providing a comprehensive analysis of glTF-based representation formats for 3D Gaussian Splatting. The document identifies a gap in TR 26.958 V0.1.1, which currently only mentions PLY as a storage format without comparative analysis of the emerging glTF-based format ecosystem from Khronos and MPEG.
The contribution proposes a two-layer architecture combining: - KHR_gaussian_splatting (Khronos) for canonical splat semantics - MPEG_gaussian_splatting_transport (MPEG-I Scene Description) for distribution and streaming capabilities
The Khronos extension (review draft published August 2025) defines Gaussian splats as POINTS primitives within standard glTF 2.0 with the following attributes:
Key design features: - Nested extensions mechanism inside the KHR_gaussian_splatting object allows other extensions to add compression, alternative encodings, or processing without duplicating semantics - Graceful degradation: Clients not recognizing the extension can still render as standard point cloud using POSITION and COLOR_0 - Provides strong anchor for MPEG and 3GPP work targeting interoperable distribution and streaming
The MPEG extension is carried as a nested extension inside KHR_gaussian_splatting.extensions, avoiding semantic duplication and adding only transport-level features.
Two MPEG-specific SH coefficient storage modes alongside Khronos default:
DC (degree 0) term reconstructed from COLOR_0.rgb or carried via KHR SH_DEGREE_0_COEF_0
mpegPerChannel layout:
progressive.stagesMPEG_accessor_timed extensionAlignment with existing 3GPP specifications: glTF already adopted by TS 26.118 (Immersive teleconferencing) and TS 26.119 (MeCAR)
5GMS adaptive delivery mapping: Progressive download and timed delivery map naturally to 5G Media Streaming
Bandwidth-adaptive quality: Progressive SH degree layout enables network/receiver control of SH levels to fetch, analogous to spatial/temporal layer selection in scalable video codecs
Future-proof extensibility: Clear path for future compression extensions (e.g., from ongoing MPEG Gaussian Splat Coding exploration) and tiled spatial delivery without breaking backward compatibility
The contribution proposes to include the following in TR 26.958 Section 4 and new subsection under Section 11:
Extensibility mechanism
Document MPEG_gaussian_splatting_transport being developed within MPEG-I Scene Description, including:
Alternative SH coefficient layouts (mpegProgressive and mpegPerChannel)
Document two-layer architecture (Khronos semantics + MPEG transport) and its suitability for 3GPP service integration, noting alignment with glTF-based approach in TS 26.118 and TS 26.119
[FS_3DGS_MED] Pseudo-CR on Sport Example for Dynamic 3DGS Content Use Case
This change request proposes adding a sports scenario example to TR 26.958 to illustrate the Dynamic 3DGS (3D Gaussian Splatting) content use case. The contribution is from Pengcheng Laboratory and China Mobile, targeting the FS_3DGS_MED study item.
The document enhances the existing Dynamic 3DGS content use case description with the following key characteristics:
The CR introduces a basketball game segment as an illustrative example (Figure 5.1):
Continuous rendering to preserve temporal progression
Spatial Navigation:
This contribution provides a concrete, large-scale example for Dynamic 3DGS content use cases, specifically addressing:
The sports scenario serves as a representative example for understanding delivery, rendering, and interaction requirements for dynamic 3DGS content in challenging real-world conditions.
Pseudo-CR on Dancer Example for Dynamic 3DGS Content Use Case
This contribution proposes adding a detailed dancer scenario example to TR 26.958 as an illustrative use case for Dynamic 3D Gaussian Splatting (3DGS) content. The document is submitted by Pengcheng Laboratory and China Mobile Com. Corporation for SA4 Meeting #135.
The contribution expands the existing Dynamic 3DGS content use case description with the following key characteristics:
The contribution introduces a comprehensive dancer performance example with the following technical specifications:
Scene Representation: - Dynamic 3DGS sequence representing dance performance captured over short temporal interval - Time-indexed sequence of 3D Gaussian splats encoding: - Continuous body motion - Pose transitions - Expressive gestures of one or multiple dancers - Relevant stage elements
Playback Characteristics: - UE receives successive temporal segments - Real-time rendering preserving temporal continuity and rhythm - Motion evolution according to encoded timeline - Spatial structure coherence maintained across frames
User Interaction Model: - Viewpoint Adjustment: Interactive control within constrained navigation volume derived from original capture setup - Permitted Operations: Limited rotation, translation, or zoom - Benefits: Enhanced perception of choreography, spatial relationships between performers, and fine-grained motion details - Constraints: Visual consistency ensured while avoiding out-of-distribution views
Navigation Paradigm: - Temporal Navigation: Driven by playback timeline (time-continuous) - Spatial Navigation: User-controlled within permitted range - Combined Experience: Time-continuous playback with interactive viewpoint exploration
The contribution explicitly defines the following scope boundaries:
In Scope: - Delivery of pre-recorded sequences - Decoding of dynamic 3DGS content - Real-time rendering on mobile devices - On-demand streaming or file download
Out of Scope: - Live dynamic 3DGS capturing and delivery (may be considered later depending on feasibility) - Capture processes - Real-time communication
The use case specifically targets: - Human-centric 3D Gaussian scene reconstruction - Capturing intricate details of human motion and dynamic appearance changes within confined volume - Reference implementation for evaluating 3DGS rendering performance on mobile devices - High-fidelity character rendering
The contribution includes Figure 5.x illustrating the dancer scenario, showing time-indexed dynamic 3DGS sequence playback with temporal progression preservation and user viewpoint adjustment capabilities within the allowed navigation volume.
[FS_3DGS_MED] Pseudo-CR on Enhanced Scenario for Avatar Communication Use Case
This contribution proposes an enhanced scenario for avatar-based communication that combines parametric human models with 3D Gaussian Splatting (3DGS) technology. The proposal aims to enable efficient real-time interactive communication by transmitting compact motion parameters to drive a deformable mesh while using 3DGS for high-fidelity appearance rendering.
The proposal introduces a hybrid representation approach consisting of:
The proposal defines several key working assumptions:
Capture and Animation Extraction: - Real-time capture using one or more cameras - Real-time derivation of animation parameters from captured signals
Representation: - Deformable mesh with associated rig - Associated 3DGS for appearance rendering - Static or low-frequency updated 3DGS representation
Transmission: - One-time or occasional base avatar transmission - Continuous time-varying animation parameter transmission - Low-latency requirement for interactive communication
Decoding and Rendering: - Animation parameter application at receiver - Combined mesh and 3DGS rendering - Constrained viewpoint adaptation support
The main technical innovation is the separation of geometric animation (transmitted as compact parametric data) from appearance representation (using 3DGS), enabling photorealistic real-time avatar communication with efficient bandwidth utilization suitable for bidirectional interactive applications.
[FS_3DGS_MED] Pseudo-CR on objective metrics for 3DGS
This change request proposes the adoption of a standardized objective quality evaluation methodology for 3D Gaussian Splatting (3DGS) content. The contribution addresses the current gap in TR 26.958, which contains only placeholders for metrics and reference implementations. The proposal leverages the mpeg-gsc-metrics software tool recently developed by MPEG for computing objective quality metrics.
The CR identifies three key requirements for the study:
The proposed software is a fork of MPEG metrics software intended for storage in the 3GPP git repository to facilitate updates and future experiments.
The CR introduces a comprehensive objective metrics section defining:
Supported Metrics: - PSNR and MSE: Computed in both RGB and YUV color spaces with weighted averages - Object Masked (OM) Metrics: PSNR and SSIM variants computed only on valid pixels defined by union of object masks - Perceptual Metrics: SSIM and IVSSIM - Geometric Statistics: Occupancy rate measuring valid pixel coverage percentage
Dual-Mode Rasterizer: - CPU rasterizer: Software-based implementation ensuring bit-exact rendering regardless of hardware/OS (recommended for normative results) - GPU rasterizer: OpenGL-based accelerated rendering for visual inspection and rapid experiments
Evaluation Process: 1. Viewpoint generation from original PLY file or explicit definition 2. Rendering using standardized rasterizer (CPU or GPU) 3. Metric computation on rendered pairs
The CR adds detailed usage documentation for the 3DGS-Metrics command-line tool:
12.4.1 Basic Metric Computation: - Simple command-line interface for comparing source and decoded PLY files
12.4.2 Evaluation Using Embedded Camera Parameters:
- --useCameraPosition option enables rendering using camera parameters stored in PLY header comments
- Parameters typically inserted by content preparation tools using COLMAP photogrammetry data
- Ensures exact camera intrinsics and extrinsics without external configuration
12.4.3 Evaluation with Loaded Viewpoints: - Support for external viewpoint files specifying camera poses - CPU rendering option for bit-exact results
12.4.4 Video Generation:
- -s flag enables generation of rendered video sequences (Source, Decode, Butterfly comparison)
- Facilitates visual inspection alongside metric computation
12.4.5 Output Results Format: - Detailed per-frame and global average statistics - Comprehensive reporting of MSE, PSNR, and SSIM in RGB and YUV color spaces - Example output provided for Bartender sequence at 1920x1080 resolution showing: - RGB PSNR (avg): 49.79 dB - YUV PSNR (avg): 53.96 dB - SSIM (avg): 0.998386 - 100% occupancy
The CR proposes adopting the 3DGS metrics software as the reference tool for objective quality evaluation to ensure all contributions are measured against the same baseline. This standardization will facilitate technical work by providing consistent, comparable, and reproducible results across different proponents within the study.
[FS_3DGS_MED] Pseudo-CR on 3DGS renderer and performance benchmarking
This change request proposes adding technical content to TR 26.958 regarding a reference implementation of a 3DGS player for mobile platforms, including mobile renderer features and preliminary experimental benchmark results obtained on commercial mobile devices.
The document proposes a hybrid architecture for the 3DGS mobile player:
Vertex and Fragment shaders for rendering
Application Layer (Java/Kotlin):
Resource management
Capabilities:
Key technical aspects of the mobile rendering pipeline:
Proposed benchmarking approach:
Key findings from Table 1 and Figure 2:
Conclusion: GPU saturation occurs at ~150k points (87% load) and full saturation at 200k points. Beyond saturation, frame rate decreases linearly with point count.
Key findings from Table 2 and Figure 3:
Conclusion: Moderate frame rate impact when increasing SH degree from 0 to 3.
Key conclusions:
Editor's note: Additional benchmarks planned to evaluate impact of other improvements (memory optimization, quantization, sorting algorithms, etc.)
[FS_3DGS_MED] Pseudo-CR on 3DGS delivery workflows based on capability negotiation
This contribution from Tencent proposes updates to TR 26.958 v0.1.1 to define adaptive delivery workflows for 3D Gaussian Splats (3DGS) content in mobile environments. The document addresses the heterogeneity in both 3DGS scene complexity and UE capabilities through capability negotiation mechanisms.
The contribution identifies a critical gap in the current study: static delivery workflows for 3DGS content pose significant risks including: - Poor Quality of Experience (QoE) when content complexity exceeds UE rendering capabilities - Device overheating and thermal throttling - Inefficient resource utilization across diverse mobile devices
The heterogeneity exists on two dimensions: - Content complexity: Ranging from simple objects (thousands of primitives) to massive scenes (millions of primitives) - Device capabilities: Significant variation in GPU power, thermal limits, memory, and battery constraints
The contribution proposes updating clause 9.2 with a comprehensive adaptive workflow that introduces:
Dynamic state: Current thermal status (throttling level), battery level, available GPU/CPU compute headroom, real-time battery charge
Rendering Budget Concept: A negotiated constraint that ensures target frame rates and maximizes session duration based on device capabilities
The contribution defines two distinct approaches aligned with TR 26.928 principles:
In this approach, the UE acts as a data provider while the server makes adaptation decisions:
Workflow Steps: 1. Hardware assessment: UE evaluates capabilities via system checks (potentially using OpenXR APIs) 2. Capability reporting: UE transmits comprehensive capability report (CPU, GPU, Memory constraints) 3. Server decision: Server analyzes report and determines optimal delivery strategy 4. Content adaptation: Server processes 3DGS model through: - Pruning low-opacity or spatially insignificant splats - LOD selection from pre-generated levels - SH degree reduction (stripping high-order coefficients, transmitting only Direct Color components) - Quantization adjustments 5. Data delivery: Server streams optimized 3DGS payload 6. Local adaptation: UE performs final on-device optimizations (further pruning/merging) to fit runtime constraints 7. Rendering: UE executes rendering pipeline
Key characteristics: - Server employs internal logic or lookup tables to map raw metrics to rendering budget - Server determines primitive count limits (e.g., N primitives for specific GPU under thermal stress) - Reduces both network bandwidth and client rendering load
In this approach, the UE determines its own requirements and explicitly requests specific content characteristics:
Workflow Steps: 1. Hardware analysis: UE performs internal audit of hardware resources and API support 2. Format determination: UE calculates optimal 3DGS representation format (point budget, SH degree) based on continuous self-assessment of frame time, thermal headroom, and hardware capabilities 3. Content request: UE explicitly specifies required format parameters (quantization levels, SH orders, point budget) 4. Server-side adaptation: Server processes source content to match UE-specified constraints 5. Data delivery: Server streams optimized payload 6. Local refinement: UE applies final local adaptations 7. Rendering: UE executes rendering pipeline
Key characteristics: - Decision-making responsibility delegated to UE - UE continuously monitors performance metrics - Server acts as content filter/selector fulfilling explicit UE requests
The proposed workflows address requirements from: - Clause 5.2: Static 3DGS scene delivery - Clause 5.4: Dynamic 3DGS content delivery
The contribution ensures: - Frame rate stability through capability-aware content delivery - Thermal management by preventing device overheating - Prevention of application crashes and frame drops - Optimized battery consumption - Maximized session duration - Content complexity aligned with hardware processing limits
The document proposes modifications to Clause 9.2 of TR 26.958, specifically: - Adding new clause 9.2.1 (Overview) - Adding new clause 9.2.2 (Workflow with capability negotiation) - Adding new clause 9.2.2.1 (Objectives) - Adding new clause 9.2.2.2 (Server-centric 3DGS adaptation) with Figure 2 - Adding new clause 9.2.2.3 (Client-centric 3DGS adaptation) with Figure 3
[FS_3DGS_MED] On Software and Services
This contribution from Nokia provides an overview of consumer-facing 3D Gaussian Splatting (3DGS) software and services for inclusion in the draft TR for the study on 3DGS for Media (FS_3DGS-MED). The document proposes two main changes: addition of normative references and a new clause describing available 3DGS software products.
The contribution proposes adding multiple new references to support the technical content:
Foundational 3DGS References: - Kerbl et al. foundational 3DGS paper (ACM TOG 2023) - Existing 3GPP references (TR 21.905, TR 26.928)
Image Processing and Rendering References: - SSIM (Structural Similarity Index) - Wang et al. 2004 - GPU sorting algorithms - Satish et al. - Alpha compositing - Porter et al. (SIGGRAPH '84)
Recent 3DGS Research (2024-2025): - VGGT: Visual Geometry Grounded Transformer - DepthSplat: Connecting Gaussian Splatting and Depth - AnySplat: Feed-forward 3DGS from unconstrained views - GS-LRM: Large Reconstruction Model for 3D Gaussian Splatting - iLRM: Iterative Large 3D Reconstruction Model - MetaSapiens: Real-time neural rendering with efficiency-aware pruning - Hybrid Transparency Gaussian Splatting (HTGS) - Sort-free Gaussian Splatting via Weighted Sum Rendering
Software and Service References: - KIRI Engine, Niantic Scaniverse, Polycam, Luma AI, Jawset Potshot, LichtFeld Studio, SuperSplat, Gauzilla
The contribution proposes adding a comprehensive overview of consumer 3DGS software categorized by platform and capabilities:
KIRI Engine: - Platform: iOS and Android - Processing: Cloud-based - Capabilities: Photogrammetry or LiDAR capture with 3DGS generation - Export: .ply and other formats - Limitations: Limited control over splat parameters, quality depends on capture device
Niantic Scaniverse: - Platform: Smartphone (iOS/Android) - Processing: Local on-device - Pipeline: SfM for camera pose estimation + Gaussian optimization - Export: .ply, .spz formats - Limitations: Mobile GPU/thermal constraints limit scene size and density, no manual SH order adjustment or splat pruning
Polycam: - Platform: Web, iOS, Android - Processing: Cloud-based - Capabilities: Photos/videos to Gaussian splats, also supports mesh/point cloud - Export: .ply for splats, standard formats for meshes - Limitations: No control over splat parameters, non-deterministic cloud processing results
Jawset Potshot: - Platform: Windows desktop - Processing: Local GPU-based - Workflow: Alignment, optimization, and visualization - Export: .ply format - Limitations: Limited parameter tuning compared to research tools, no low-level SH coefficient control
LichtFeld Studio: - Platform: Linux and Windows desktop - Type: Open source - Processing: Local GPU-based - Input Requirements: Pre-computed SfM data (images, point clouds, camera locations) - Features: - 3D Unscented (3DGUT) transform for rendering - Background Modulation for black segments - Timelapse for intermittent quality checks - Masking support - Export: .ply format
SuperSplat and Gauzilla: - Platform: Browser-based - Rendering: Client-side via WebGL or WebGPU - Capabilities: Rendering, sharing, transformations, cropping, basic filtering - Limitations: No training or reconstruction support, lower rendering fidelity vs desktop GPU pipelines - Use Case: Post-processing and quick visualization
Luma AI: - Platform: iOS and Web - Processing: Cloud-based - Input: Short handheld videos or image sets - Technology: Neural scene representations rendered as Gaussian splats or hybrid neural radiance fields - Pipeline: Pose estimation and scene normalization before splat optimization - Limitations: No raw Gaussian parameters or SH coefficients exposed, no export capability (as of February 2026), oriented toward visualization rather than pipeline integration
The contribution includes a comparative table summarizing: - Product name - Application type (Mobile/Desktop/Web) - Processing location (Cloud/Local) - Export format options
This table provides a quick reference for understanding the landscape of available 3DGS tools and their capabilities.
The contribution demonstrates the rapid proliferation of 3DGS tools across different platforms and use cases, from mobile capture applications to desktop processing tools and web-based viewers. The tools vary significantly in: - Processing location (cloud vs. local) - User control over parameters - Export capabilities - Target use cases (capture, processing, viewing, sharing)
This overview provides important context for standardization work by documenting the current state of consumer 3DGS software ecosystem.
[FS_3DGS_MED] On Mapping to 3GPP services
This contribution from Nokia addresses objectives 3 and 5 of the FS_3DGS_MED study (approved in SP-251190 at SA#109). The objectives include:
The document notes that static 3DGS content generation workflow (documented in draft TR 26.958v0.1.0) consists of: - Capture - Structure from Motion (SfM) estimation for sparse point cloud reconstruction - Gaussian initialization - Training and optimization
The contribution emphasizes that SfM and training are compute-heavy operations requiring architectural consideration. The document reviews two SA4 media service architectures as potential frameworks: the 5G Media Delivery architecture (TS 26.501, TS 26.510) and IMS (TS 23.228, TS 26.114), noting precedents from R18/R19 services like split rendering, avatar communications, media messaging, and spatial computing.
The contribution proposes leveraging the MSE framework (TR 26.857) which provides Application Providers with well-defined client and network-side functions. The reference architecture includes:
Defined Functions: - Application: UE-resident function leveraging MSE - MSE Client: Logical internal UE function for specific MSE - MSE Application Function (AF): Dedicated application function for an MSE - MSE Application Server (AS): Dedicated application server for an MSE
Defined Interfaces/APIs: - MSE-1: Provisioning API for Application Providers - MSE-2: Optional ingest/egest API for content processing - MSE-3: Inter MSE AF-MSE AS communication - MSE-4: User plane interface between MSE Client and Server - MSE-5: Control API for configuration and management - MSE-6: Client APIs for internal application communication - MSE-7: External device APIs for accessing device functions - MSE-8: Application APIs for information exchange between Application and Provider
The proposed mapping for 3DGS content generation and sharing: - AP provisions service through MSE-1 - Session handling control plane information exchanged between MSE AF and MSE client over MSE-5 - Media communication over MSE-4 - Application uses device functions (cameras) via MSE-7 to capture images/video - Captured media transmitted over MSE-4 to MSE AS for SfM and training - Generated 3DGS or rendered views shared back to UE over MSE-4
The contribution proposes IMS DC (TS 23.228 Annex AC) as an alternative architecture, noting IMS as the backbone for conversational media in 3GPP networks.
New Functional Entities: - Data Channel Signalling Function (DCSF): Manages data channel control logic, determines service availability, manages bootstrap and application data channel resources at MF via IMS AS, handles interworking between application data channel media and audio/video media - Media Function (MF): Provides media resource management and forwarding of data channel media traffic, manages bootstrap and application data channel resources, anchors application data channels in P2P scenarios, relays traffic between UEs and DC-AS, handles transcoding. SA2 specifies MF supports rendering (S4-251420) but not AIML functionality (S4-260022) - DC Application Repository (DC-AR): Stores verified data channel applications for retrieval by DCSF and download to UE - DC Application Server (DC-AS): Interacts with DCSF for resource control and traffic forwarding, serves as endpoint for application data channels, communicates with UE through MF. DC-AS functionalities are not 3GPP-specified
DC-Relevant Reference Points: - DC1: Between DCSF and IMS AS - DC2: Between IMS AS and MF - DC3: Between DCSF and NEF - DC4: Between DCSF and DC Application Server - DC5: Between DCSF and DCAR - N70/Cx/Dx: Between CSCF and HSS (updated for DC signalling) - N71/Sh: Between IMS AS and HSS (updated for DC signalling)
Data Channel Media Handling Reference Points: - MDC1: Between MF and DCSF - MDC2: Between MF and DC-AS, between BAR and DC-AS, between MF and BAR - MDC3: Between DCSF and DC-AS
The proposed mapping for 3DGS generation over IMS DC: - Service provider provides IMS DC application to DCAR - Provisions and configures resources via NEF and DC4 - UE downloads IMS DC app - IMS DC app sets up application data channel with DC-AS for service configuration - Uses device camera(s) to capture images/video - Transmits captured media to DC-AS for SfM and 3DGS training - Generated 3DGS shared back to UE or sent to MF for view-based rendering
The contribution proposes to develop mappings for 3DGS content generation and sharing workflows to both an MSE framework and to IMS DC architecture, considering both frameworks appropriate for 3DGS service deployment.
Dynamic 3DGS complexity
This contribution from InterDigital addresses an open editor's note in TR 26.958 regarding scene complexity impacts on Dynamic 3D Gaussian Splatting (3DGS) feasibility for mobile platforms. The document proposes text for Clause 6.3 (Complexity) which is currently empty.
The contribution identifies that dynamic scene complexity significantly affects the feasibility of dynamic 3DGS content on mobile devices. Key complexity drivers include:
These parameters directly constrain: - Achievable frame rate - Session duration - Visual quality
FFS: Determining maximum scene complexity that representative UE categories can sustain.
The document highlights that highly dynamic content (multi-person scenes, self-occlusions, cloth/hair motion) presents specific compression challenges:
The contribution proposes categorizing dynamic 3DGS representations based on temporal association of Gaussian primitives:
These categories differ in: - Efficiency for temporal prediction - Robustness to motion/topology changes
FFS: Comparison of these formats regarding bitrate efficiency, latency, UE processing, and visual quality.
The document notes that the original INRIA 3DGS representation has inherent limitations for dynamic content:
Recent academic developments (references [1]-[4]) explore alternatives addressing these limitations.
FFS: Whether multiple dynamic-oriented 3DGS formats may coexist.
The contribution proposes adding the provided text to Section 6.3.X or another suitable section of TR 26.958 to address the open editor's note on complexity considerations for Dynamic 3DGS content.
[FS_3DGS_MED] Pseudo-CR on 3DGS delivery workflows for large 3DGS scenes
This is a pseudo-CR to TR 26.958 v0.1.1 addressing viewport-adaptive delivery workflows for large-scale 3D Gaussian Splatting (3DGS) scenes in the context of FS_3DGS_MED study. The contribution focuses on enabling delivery of massive 3DGS environments (e.g., city-scale digital twins) to mobile devices with constrained resources.
Large-scale 3DGS scenes (as defined in clause 5.4) cannot be fully loaded into mobile device memory due to: - Bandwidth limitations - Memory constraints - Rendering capacity restrictions
Static delivery workflows would result in: - Excessive latency - Immediate resource saturation - Inability to deliver complete scenes
Simple capability negotiation alone is insufficient for these use cases.
The document proposes a new clause 9.2.3 introducing a viewport-adaptive workflow that extends existing capability negotiation mechanisms by incorporating continuous spatial feedback.
Two approaches are defined:
Two-Phase Approach:
Key Characteristic: Server maintains control over rendering budget throughout session based on initial capability assessment.
UE-Driven Approach:
Key Characteristic: UE explicitly requests specific representation format during initialization; server's role restricted to spatial operations while adhering to UE-imposed format constraints.
The document proposes to agree the changes introducing clause 9.2.3 and its subclauses (9.2.3.1-9.2.3.4) to TR 26.958, including two workflow diagrams (Figures 5 and 6) and one illustration of tile/LOD selection (Figure 4).
[FS_3DGS_MED] High level media data workflows for All-in-client configuration
This CR adds high level media data workflows for the All-in-client configuration to the 3D Gaussian Splatting (3DGS) media study. The workflows describe how different 3DGS service use cases can be realized when processing steps primarily run on the UE.
Defines the All-in-client configuration as workflows where functionality primarily runs on the UE for the use cases described in clause 5 of the technical report.
The CR identifies the following key workflow steps that can be executed on the UE:
Collects auxiliary signals (references clause 5.2)
3DGS Model Generation
Referenced to clause 5.2
Animation Stream Generation
Referenced to clause 5.5
Packaging and Distribution
Referenced to clauses 5.2 and 5.5
Asset Reception and Storage
Supports dynamic 3DGS scene content via file delivery (clause 5.4)
Rendering
The CR defines three key characteristics for the All-in-client configuration:
Dependent on UE device capabilities for capture, generation, and rendering operations
Scalability
Limited by UE device capabilities:
Network Usage
The CR states that if not approved, the study would be incomplete, indicating this is a foundational contribution to the 3DGS media workflows study.
[FS_3DGS_MED] High level media data workflows for Client-Server configuration
This CR introduces high level media data workflows for Client-Server configuration in the context of 3D Gaussian Splatting (3DGS) service delivery. This complements the existing all-in-client configuration by defining workflows where functionality is split between the UE client and the network server.
The CR identifies the following workflow steps that execute in the Client-Server configuration:
Server-Side Operations: - 3DGS Content Generation: Generation of 3DGS content from 2D captures of scenes (references clause 5.2) - Dynamic Content Generation: Creation of dynamic 3DGS content and region-based parts of 3DGS scenes based on the 3DGS model for adaptive delivery - Adaptive Selection: Selection of 3D tiles and their Level of Detail (LOD) based on: - User movement - UE device capabilities - Packaging and Distribution: 3DGS assets packaged in the network and delivered via: - MMS - OTT messaging - Download services
Client-Side Operations: - Content Reception: UE receives one or more of: - 3DGS assets (clause 5.2) - 3D tiled LODs (clause 5.3) - Dynamic 3DGS scene content via file delivery, partial-delivery, or on-demand streaming (clause 5.4) - Storage: Content stored in local memory or GPU memory - Rendering: UE renders: - 3DGS assets by selecting Gaussians based on LODs dependent on: - User preferences - UE device capabilities and characteristics (camera pose, display resolution, etc.) - 3D tiled LODs fetched using adaptive delivery (clause 5.3) - 3D Avatars using time-aligned animation streams (clause 5.5)
The CR defines key characteristics of the client-server configuration:
Latency/Performance: - Dependent on network and application latency - Influenced by: - Capabilities of the network server generating 3DGS content - UE device rendering capabilities
Scalability: - Enhanced scalability compared to all-in-client configuration - Leverages theoretically infinite network resources - Enables more use cases
Network Usage: - Content generation - Rendering (full or partial) - Distribution
Network Interaction During Playback: - Selection of 3D tiles and LODs - Sending user pose information - Temporal updates - Optional partial or full rendering support
This CR builds upon: - Clause 5 use cases (referenced throughout) - Clause 9.1 All-in-client configuration (complementary approach) - Various delivery mechanisms already defined in the study (MMS, OTT messaging, file delivery, streaming)
[FS_3DGS_MED] Mapping 3DGS to 3GPP services with All in UE configuration
This CR addresses the mapping of 3D Gaussian Splatting (3DGS) services to 3GPP services and specifications, specifically for the "All in UE" configuration.
This CR introduces a new clause (Clause 10) that maps high-level media data workflows for 3DGS to different 3GPP services. The mapping covers two configurations, with this CR specifically detailing the "All in UE" configuration.
In this configuration, 3DGS content is treated as downloadable or message-based assets. The CR provides a comprehensive mapping table that covers the following functional areas:
NOTE 1 - File-based Delivery Requirements: - 5G latency or jitter requirements do not apply (strict 5G QoS is not necessary) - Low Packet Error Rate and reliable delivery required - Standard 5G bearers specified in TS 23.501 are adequate to carry 3DGS content
NOTE 2 - Storage: No 3GPP-specific mapping required
The CR establishes that for the All in UE configuration: 1. 3DGS content follows a file-based delivery model rather than streaming 2. Existing 3GPP services (MMS, RCS, HTTP) are sufficient for content delivery 3. Standard 5G bearers are adequate without requiring enhanced QoS 4. The architecture aligns with the existing Media Delivery framework in TS 26.501
[FS_3DGS_MED] Mapping 3DGS to 3GPP services with Client-Server configuration
This CR addresses the mapping of 3D Gaussian Splatting (3DGS) services to 3GPP services and specifications for the Client-Server configuration. This complements the existing All-in-UE configuration mapping.
The CR introduces a comprehensive mapping table that defines how different 3DGS workflow functions map to existing 3GPP services when operating in a Client-Server configuration. In this configuration, 3DGS is delivered as either an interactive XR service or 6DoF media streaming.
The CR identifies key 5G QoS requirements for 3DGS service delivery (marked as FFS for final determination):
For Avatar-related 3DGS services, TS 26.264 may be applicable.
This CR completes the study on mapping 3DGS to 3GPP services by addressing the Client-Server configuration, which is essential for network-assisted 3DGS delivery scenarios including edge rendering and adaptive streaming use cases.
[FS_3DGS_MED] Mapping 3DGS to 5QI
This CR proposes to add a new clause (6.X) to TR 26.958 addressing the mapping of 3D Gaussian Splatting (3DGS) services to 3GPP 5G QoS Identifier (5QI) parameters as specified in TS 23.501.
The CR provides a comprehensive table of relevant pre-defined 5QI values from TS 23.501 that have similar QoS characteristics to 3DGS services, including:
5QI 80: Low latency eMBB/AR applications (PDB: 10ms, PER: 10⁻⁶)
Delay-Critical GBR:
5QI 89-90: Visual content for cloud/edge/split rendering (PDB: 15-20ms, PER: 10⁻⁴)
Non-GBR Resources:
The CR identifies distinct application flows requiring QoS treatment:
The CR establishes the following recommendations for the study outcome:
The CR addresses a gap in the FS_3DGS_MED study by providing guidance on how 3DGS services should be treated within the 5G System QoS framework, ensuring proper traffic handling behavior through appropriate QoS Flow configuration.