[FS_6G_MED] Discussion on AI traffic trends
Source: Nokia
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 |
| download_url | Download Original |
| For | Agreement |
| Type | discussion |
| Contact | Saba Ahsan |
| Uploaded | 2026-02-03T19:37:43.990000 |
| Contact ID | 81411 |
| TDoc Status | noted |
| Reservation date | 02/02/2026 17:44:23 |
| Agenda item sort order | 60 |
Review Comments
[Technical] The proposal to “Add Clause 2 content to TR 26.870 clause 6.2” is not actionable because the contribution does not map its material to the existing clause structure/terminology of TR 26.870 (e.g., what subclauses, tables, KPIs, or definitions are to be inserted), risking inconsistency with the TR’s established traffic-characterization framework.
[Technical] Several key assertions are presented without sufficient methodological detail (e.g., “AI traffic constitutes 0.06%… 74% DL/26% UL”, latency non-linearity at 0.5 s/1.5 s, “bursts in uplink traffic”), but no information is given on measurement point (RAN/UPF/PGW), sampling period, app identification method, device mix, or confidence—making the results hard to validate or reuse in a 3GPP TR.
[Technical] The statement “Text and images are base-64 encoded and encapsulated in JSON (OpenAI API, Gemini API)” is over-generalized and may be misleading for traffic characterization, since many deployments use multipart/form-data, binary uploads, HTTP/2/3, gRPC, or streaming APIs; the TR should describe variability and typical patterns rather than a single encoding approach.
[Technical] The claim that AI apps “use existing web-based protocols (e.g., WebRTC for live audio/video)” is not representative for most conversational AI services today (often HTTPS-based streaming, WebSockets, or proprietary transports), and the document does not distinguish between real-time interactive media sessions vs request/response inference sessions.
[Technical] The codec statement “Existing codecs (AVC, HEVC) used for encoding before transport” is incomplete and potentially incorrect for many AI interactions (e.g., Opus for voice, AAC, AV1, JPEG/PNG/HEIF for images, and pre-encoded camera captures), and it conflates user media capture formats with network transport payload formats.
[Technical] The UL/DL trend discussion (“uplink data growing faster… driven by conditioning inputs”) lacks quantification by use case (chat vs image/video conditioning vs agentic workflows) and does not address compression/resolution effects, caching, or on-device pre-processing—key to credible UL/DL ratio conclusions for 6G planning.
[Technical] The latency sensitivity section cites “inserted latency” effects but does not specify whether this is RTT, one-way delay, added at IP layer vs application layer, nor whether server processing time is separated from network delay; without this, the “non-linear” behavior cannot be translated into 3GPP QoS/QoE requirements.
[Technical] The “Agentic AI opportunities” claim that agents can shift traffic off-peak is speculative and not tied to concrete traffic models (background scheduling constraints, user tolerance, deadlines, notification patterns), and it ignores that many agentic tasks are user-triggered and time-sensitive, limiting applicability as a general traffic assumption.
[Technical] The agentic protocol discussion (MCP, A2A) is not clearly relevant to 3GPP traffic characterization unless it is tied to observable network behaviors (session duration, concurrency, message sizes, polling vs push, keep-alives); currently it reads as architecture background rather than traffic-impact analysis.
[Technical] The contribution does not address encryption and traffic classification implications (most AI traffic over TLS/QUIC), which is central to any realistic operator-side characterization and to how TR 26.870 can describe identification/measurement approaches.
[Editorial] References to “Figure 1” and “Figure 2” are included but the figures are missing, leaving key quantitative claims unsupported and making the text unsuitable for direct insertion into a TR clause.
[Editorial] Terminology is inconsistent and sometimes non-3GPP (e.g., “AI inference factories”, “AIML traffic”, “agentic apps”), and should be aligned with agreed study terminology and defined once (including what is meant by “AI media traffic” vs general AI application traffic).
[Editorial] The proposal items are phrased as meeting agreements (“Agree to prioritize… by June 2026”) rather than concrete spec text or study deliverables, and they do not identify responsible rapporteurs, target clauses, or expected outputs, reducing usefulness as a formal 3GPP contribution.