6GMedia - work topic 2- Characteristics of AI-enabled applications
Source: InterDigital New York
Meeting:
TSGS4_135_India
Agenda Item:
11.1
| Agenda item description | FS_6G_MED (Study on Media aspects for 6G System) |
|---|---|
| Doc type | discussion |
| For action | Agreement |
| Release | Rel-20 |
| Specification | 26.87 |
| download_url | Download Original |
| For | Agreement |
| Spec | 26.87 |
| Type | discussion |
| Contact | Gaelle Martin-Cocher |
| Uploaded | 2026-02-03T20:59:09.397000 |
| Contact ID | 91571 |
| TDoc Status | noted |
| Reservation date | 03/02/2026 20:49:14 |
| Agenda item sort order | 60 |
Review Comments
[Technical] Several proposals (e.g., “SA4 should develop generic QoS and QoE mechanisms”, “enhance QoS framework granularity/context awareness”, “procedures for real-time QoE-based adaptation”) are largely SA2/SA5 scope and risk duplicating 5GS QoS work; the contribution should clearly delimit SA4’s role (media adaptation signaling, codecs, application-layer metrics) vs system QoS control.
[Technical] The document treats “AI/ML data” (tokens, embeddings, latent, intent, prompts, model parameters) as if SA4 should standardize representation formats/codecs, but it does not justify why this belongs in 3GPP SA4 rather than external SDOs (IETF/W3C/ISO/IEC JTC1/SC29) or 3GPP SA6; without a concrete interoperability gap and target interface, the proposal is not actionable.
[Technical] Table 1 claims/assumptions around specific formats (ONNX, GGUF, MPEG NNC, MPEG-7, W3C Media Annotations, “MPEG FCM”, “upcoming MPEG avatar”) are problematic: some are not stable standards, not widely interoperable, or not clearly relevant to 3GPP media specs, and the document does not state selection criteria or normative references.
[Technical] The “spatial computing off-device processing” propositions are underspecified: no functional split options, latency budgets, synchronization requirements, or mapping to 3GPP enablers (e.g., edge computing, uplink media formats, timing) are provided, making it hard to translate into TR text beyond generic statements.
[Technical] The QoS characterization in Table 2 (“mid reliability”, “real-time latency”, “high need for QoE-based adaptation”) is qualitative and inconsistent with 3GPP practice; it should be tied to measurable KPIs (e.g., packet delay budget, loss rate, jitter, sync error) and to existing 5QI/GBR/non-GBR concepts if it is to influence SA4 study conclusions.
[Technical] The contribution asserts “current QoS frameworks lack application/context awareness, granularity, and adaptability” without citing specific limitations in existing 3GPP mechanisms (e.g., QoS flows, reflective QoS, NWDAF, TS 26.114/26.501/26.522 mechanisms); this weakens the rationale for new work and risks overstating gaps.
[Technical] The QUIC/MRI discussion mixes layers and responsibilities: SA4’s RTP header extension MRI solution (TS 26.522) is not directly comparable to SA2 N6 relaying of MRI for encrypted QUIC traffic, and the document does not explain what “integration” would concretely mean (new application-layer metadata objects, gateways, or mapping rules).
[Technical] The statement that “Rel-19 SA2 specified techniques for delivering MRI when XRM traffic is end-to-end encrypted (QUIC)” needs precision (exact WI/spec references and what was standardized vs studied); otherwise it risks being factually incorrect or misleading.
[Technical] Multi-device/tethering observations are valid but the proposal again drifts into system-level territory (“UE-centric assumptions”, “traffic correlation across UEs”) without identifying SA4-specific deliverables (e.g., cross-device media synchronization signaling, multi-stream adaptation coordination, per-device capture/render timing).
[Editorial] Numbering is inconsistent and duplicated (e.g., “Observation 8/9” and “Proposal 8” appear in multiple sections with different meanings), which will cause confusion when transcribing into TR clauses.
[Editorial] Terminology is not controlled: “XR”, “XRM”, “AI-enabled”, “spatial computing”, “MRI”, “AI data”, “intermediate data (embeddings)” are used without definitions or alignment to existing 3GPP terms, undermining Proposition 2’s stated goal.
[Editorial] Several codec/format mentions are vague or potentially incorrect (“dynamic mesh/gaussian splat codecs”, “MPEG haptics”, “MPEG FCM”) and should be replaced with precise standard names, part numbers, and maturity status, or moved to informative examples.
[Editorial] The conclusion proposes adding content to “a new section 6.X of the TR” but does not specify which TR (presumably the 6GMedia TR) nor the intended clause structure and exact text changes, making it hard for the group to adopt as-is.