Meeting: TSGS4_135_India | Agenda Item: 9.6
[FS_3DGS_MED] On Mapping to 3GPP services
Nokia
discussion
Discussion
| TDoc | S4-260187 |
| Title | [FS_3DGS_MED] On Mapping to 3GPP services |
| Source | Nokia |
| Agenda item | 9.6 |
| Agenda item description | FS_3DGS_MED (Study on 3D Gaussian splats) |
| Doc type | discussion |
| For action | Discussion |
| download_url | https://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_135_India/Docs/S4-260187.zip |
| For | Discussion |
| Type | discussion |
| Contact | Gazi Karam Illahi |
| Uploaded | 2026-02-03T18:09:48.220000 |
| Contact ID | 101579 |
| TDoc Status | noted |
| Reservation date | 03/02/2026 16:37:53 |
| Agenda item sort order | 41 |
[Technical] The mapping assumes raw captured images/video are sent over MSE-4 / IMS DC data channels for SfM and training, but it does not address feasibility (uplink bitrate, latency tolerance, session duration) nor identify any 3GPP mechanisms for large-volume bulk upload vs conversational transport.
[Technical] The proposal treats “SfM and 3DGS training in MSE AS / DC-AS” as straightforward, but it does not specify where compute is anchored (edge vs central), how UE selects/steers to the compute instance, or how continuity is handled if the UE moves—key for Objective 3 (edge/cloud operations).
[Technical] For IMS DC, the contribution relies on DC-AS “not 3GPP-specified” while also placing core 3DGS processing there; this weakens the mapping because no normative service capabilities, QoS, security, or interop behavior can be referenced for the essential function.
[Technical] The IMS DC description mixes roles: MF is said to support rendering (per S4-251420) and also “handles transcoding,” but it is unclear how 3DGS-specific rendering (view synthesis) maps onto MF capabilities without defining media formats, processing primitives, or whether rendering is in MF vs DC-AS.
[Technical] The MSE mapping uses MSE-7 for camera access, but it does not clarify whether MSE-7 is intended to expose such device sensor/camera control for high-rate capture workflows, nor how capture synchronization/metadata (intrinsics/extrinsics, timestamps) needed for SfM is conveyed.
[Technical] Neither mapping identifies the 3DGS representation formats and transport encapsulation (e.g., how a trained 3DGS model or progressive updates are packaged, versioned, and delivered), making it hard to assess consistency with TS 26.501/26.510 media delivery assumptions.
[Technical] Security/privacy aspects are missing despite uploading potentially sensitive raw imagery to network compute; the contribution does not map authentication/authorization, consent, data retention, or encryption to MSE/IMS DC procedures and interfaces.
[Technical] The workflows omit any control-plane procedures for job orchestration (start/stop, progress, retries, partial results, failure handling) and do not state whether these are carried on MSE-5 / IMS DC application channel, which is essential for long-running training tasks.
[Technical] The IMS DC provisioning text (“Provisions and configures resources via NEF and DC4”) is unclear/possibly incorrect: NEF exposure is typically for northbound API exposure, but the specific API set and how it relates to DC4/DCSF control is not described, risking architectural inconsistency.
[Editorial] Several interface names appear with typos or inconsistent terminology (e.g., “ingest/egest” likely “ingest/egress”), which reduces clarity when referencing TR 26.857 interface definitions.
[Editorial] The contribution cites “draft TR 26.958v0.1.0” and multiple S4 references, but it does not pinpoint the exact clauses being mapped; adding clause-level references would make the mapping verifiable and align with study objective tracking.
[Editorial] The conclusion proposes to “develop mappings” but does not provide concrete proposed TR text, work item impact, or specific deliverable updates (e.g., which sections of TR 26.958/26.857/IMS DC annexes would be amended), limiting usefulness as a contribution beyond high-level discussion.