S4-260187

[FS_3DGS_MED] On Mapping to 3GPP services

Source: Nokia
Meeting: TSGS4_135_India
Agenda Item: 9.6

All Metadata

Agenda item description	FS_3DGS_MED (Study on 3D Gaussian splats)
Doc type	discussion
For action	Discussion
download_url	Download Original
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

Review Comments

manager - 2026-02-09 04:40

[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.

<ol>
<li>
[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. 
</li>
<li>
[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). 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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. 
</li>
<li>
[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.
</li>
</ol>