Unknown
S4-260234 / TSGS4_135_India / 11.1 / InterDigital New York / 6GMedia - work topic 2- Characteristics of...
Previous Next Edit
S4-260234

6GMedia - work topic 2- Characteristics of AI-enabled applications

Source: InterDigital New York
Meeting: TSGS4_135_India
Agenda Item: 11.1

All Metadata
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
manager - 2026-02-09 04:30


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




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




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




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




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




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




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




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




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




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




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




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




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



Sign in to add comments.