Characterizing AI Service Traffic for 6G: An Open Testbed and Initial Results from 3GPP SA4

Characterizing AI Service Traffic for 6G: An Open Testbed and Initial Results from 3GPP SA4

arXiv:2611.07250v1 [cs.NI] 4 Nov 2026

Imed Bouazizi Qualcomm Technologies, Inc. bouazizi@qti.qualcomm.com October 2026 Abstract The design of sixth generation (6G) mobile systems requires measurements of artificial intelligence (AI) service traffic under controlled network conditions. The 3rd Generation Partnership Project (3GPP) Service and System Aspects Working Group 4 (SA4) documents such measurements in draft Technical Report 26.870. In this paper, we describe the open testbed used for the study and analyze the results recorded in version 0.6.2 and its companion workbook. The testbed combines network emulation, packet capture, application measurements, and scenario execution against hosted and self-hosted models. The reported uplink to downlink volume ratios span more than six orders of magnitude. A personal assistant agent has a ratio of 0.007 at its local control interface and 0.50 on its wide-area egress. Deterministic agent signaling follows the configured round-trip delay. In a tokenized video experiment with 125 questions per profile, the number of correct answers changes by at most three through 10% independent uplink loss. Larger losses reduce accuracy, but the available repetitions do not establish a tolerance threshold. We also analyze emulator behavior that affects the interpretation of the study. Per-packet jitter introduces reordering, correlated random-loss settings suppress rare loss events, and a Gilbert-Elliott parameter mapping changes the stationary loss rate. The results support characterization by scenario, measurement layer, and versioned network configuration.

1

Introduction

The 3rd Generation Partnership Project (3GPP) is studying artificial intelligence (AI) services as part of its sixth generation (6G) work. Technical Report (TR) 22.870 [1] identifies use cases that include conversational assistants, agents, and media inference. Radio Access Network Working Group 2 (RAN2) has asked Service and System Aspects Working Group 4 (SA4) to characterize their directionality, burstiness, delay sensitivity, variability, and token transport. These questions require measurements that participating companies can reproduce. In this paper, we describe the open testbed used for the SA4 study and analyze the results recorded in draft TR 26.870 V0.6.2 [2]. Commercial services expose only part of the system. Their traffic is encrypted, their inference configuration may change, and the measurement client does not control the external network. A trace from one deployment cannot isolate these effects. The testbed runs a declared interaction pattern against a declared model and network profile. Application records and packet captures describe the same experiment. Hosted execution measures the service as deployed. Local execution provides more control over the inference engine and the emulated path. The contributions of this paper are the following: • We describe a testbed architecture that separates network emulation and packet analysis from AI scenario execution. A dataset component consumes the resulting captures and session records. 1

• We describe the measurement methodology used in the SA4 study, including scenarios, network profiles, execution modes, and the association of application records with packet evidence. • We analyze the results recorded in the draft report and workbook for the five RAN2 question families. We distinguish reported measurements from derived ratios and their interpretation. • We analyze emulator behavior that changes the conditions produced by a profile. We identify the resulting limits on comparisons across campaigns. The remainder of the paper is organized as follows. Section 2 reviews related work. Section 3 describes the design principles and the architecture of the testbed. Section 4 describes scenarios, network profiles and metrics. Section 5 summarizes the results of TR 26.870. Section 6 discusses emulator fidelity and other threats to validity. Section 7 describes the use of the testbed in standardization, and Section 8 summarizes the results and further work.

2

Related Work

Traffic models in 3GPP. 3GPP has developed traffic models for extended reality (XR). TR 38.838 [3] defines frame-size, periodicity, and jitter models for XR evaluations in New Radio (NR). The 5G system architecture in TS 23.501 [4] includes protocol data unit (PDU) set handling for XR services. AI applications add interaction patterns governed by model execution, tool calls, and context transfer. The measurement methodology described here provides data for evaluating these patterns. Workload characterization of LLM serving. Several studies characterize large language model (LLM) and agentic workloads from the serving side. Yuan et al. [5] show that effective context caching allows agents to reuse input tokens across turns. Chang et al. [6] show that tools, execution environments, and state management dominate latency in several evaluated applications. These studies explain serving costs and application execution. Access-path measurements address an additional part of the interaction. Network-level traffic of generative AI. Nguyen et al. [7] collect client-side traces from three LLM providers across four modalities and develop burst models for ns-3 simulation. Lamagna et al. [8] show that agent coordination topology changes the arrival process of LLM requests. Their study includes inference and network measurements. Kundu et al. [9] use the 5G-MAG testbed to characterize AI traffic for 6G awareness mechanisms. Our work describes the testbed itself, its use in the SA4 methodology, and the interpretation of measurements collected under declared impairment profiles. Traffic analysis and privacy. Encrypted AI traffic can expose information through packet size, direction, and timing. Weiss et al. [10] study response reconstruction from assistant traffic. Pouryousef et al. [11] evaluate model and prompt-category identification from encrypted metadata. Li et al. [12] provide a traffic dataset for agent behavior auditing. These studies show that packet features retain application structure. Replacing provider and model names with neutral labels does not remove the information that traffic analysis may recover. Sharing captures requires a separate review of payloads, addresses, identifiers, and metadata. Network emulation. NetEm [13] is the de facto standard for emulating delay, jitter, loss and rate on Linux. Its accuracy and limitations have been studied by Nussbaum and Richard [14] and by Jurgelionis et al. [15]. We revisit two of its behaviors, reordering under per-packet jitter and the semantics of correlated loss, because they directly affect the profiles used in the 3GPP study.

2

3

Testbed Design

3.1

Design Principles

The testbed was built to serve a standards study rather than a single experiment. That purpose leads to the following design principles: • Conditional reporting. A metric is associated with a scenario and a network profile. An aggregate across profiles states its population and weighting. • Reproducibility. Configuration files identify scenarios, models, and profiles. Session identifiers associate the configuration with the application record and packet capture. • Measurement layers. Application records and packet captures describe the same session. Their byte counts retain the accounting rules of their respective layers. • Separation of layers. Network shaping, capture and packet analysis are independent of the AI experiments, so that other studies can reuse the network layer without the AI scenarios. • Result sharing. Provider and model identifiers can be replaced with neutral labels in exported results. Capture sharing requires additional data review.

3.2

Architecture

The testbed consists of three components. The netemu package provides network emulation, capture, and analysis of packet capture (PCAP) files. The aitestbed component drives experiments and depends on netemu. The training component reads capture files and session records without importing the experiment code. The following figure depicts the architecture. aitestbed

Orchestrator

scenario × profile × run

Loopback services

Scenarios

Clients

MCP servers, A2A agents, OpenClaw gateway, vLLM

chat, agents, real-time, multimodal, video, A2A

hosted, vLLM, Realtime, MCP, A2A, OpenClaw

Remote AI services providers A, B, C training

SQLite log, app. capture, application and RAN2 metrics

sessions

Dataset builder, Markov generators

apply profile, start capture

Emulator

Capture

PCAP analysis

HTB, netem, IFB

tcpdump, sidecar

flows, RTT, bursts

pcaps

netemu

Figure 1: Architecture of the testbed. Solid boxes are testbed components. Dashed boxes are services that the scenarios reach over the loopback interface or over the wide-area network.

3

3.3

Network Emulator

The network emulator wraps Linux traffic control (tc). On the main interface, a hierarchical token bucket (HTB) class limits rate and a netem queue applies delay, jitter, loss, reordering, duplication, and corruption. An intermediate functional block (IFB) device provides ingress shaping. A profile can override egress parameters for asymmetric links. Loopback uses a separate queue and netem’s native rate option. These paths can produce different delay and ordering behavior under the same nominal profile. Local peers include Model Context Protocol (MCP) [16] servers, Agent2Agent (A2A) [17] agents, an agent gateway, and selfhosted inference. Packet capture runs tcpdump and records a metadata sidecar containing the scenario, profile, and run identifiers. The configured filter covers Hypertext Transfer Protocol (HTTP), HTTP over Transport Layer Security (HTTPS), and selected Web Real-Time Communication (WebRTC) service ports. The latter include ports used for connectivity checks, relays, and media in the evaluated deployments. A service-port filter does not cover every dynamically negotiated media port. Each new deployment needs a capture-coverage check. The analysis module parses libpcap and pcapng captures containing Internet Protocol version 4 (IPv4) and version 6 (IPv6) traffic. Transmission Control Protocol (TCP) handshakes determine client and server roles when available. This avoids relying on the ordering of port numbers for loopback services. The module derives handshake round-trip time (RTT), Transport Layer Security (TLS) setup duration, retransmission indicators, directional byte volumes, throughput, and burst statistics.

3.4

Experiment Orchestration

The orchestrator iterates over a test matrix of scenarios and profiles. For each pair, it applies the profile, starts the captures, executes the configured number of runs and stores one record per request in an SQLite database. A record carries request and response sizes, token counts, the request start time and the arrival times of the first and last token, inter-chunk gaps for streamed responses, tool call statistics, HTTP status and error type. Scenarios share a common base class and are registered by type. Clients adapt them to model providers. The inspected configuration contains more than 60 scenario definitions. They cover hosted providers, a selfhosted vLLM server [18], real-time conversation, MCP tools, A2A agents, and the OpenClaw runtime [19]. An optional application-layer capture through mitmproxy [20] records decrypted HTTP exchanges with configured redaction. Definitions in the catalog are distinct from the subset executed in each reported campaign. The orchestrator supports resuming an interrupted campaign. A session counts toward completion when all its records succeed or when it is recorded as a timeout. Other failed sessions may be retried. A timeout is retained as an outcome, although its cause may include provider or host behavior as well as the network. Analysis needs to retain attempts and retries separately. A completed-run count alone is not a denominator for service reliability.

3.5

Synthetic Traffic Generation

The dataset component associates flows with transport surfaces and session windows. Traffic between loopback endpoints is kept separate from wide-area egress. A persistent connection that spans sessions is segmented at their recorded boundaries. Flows receive one of nine traffic-category labels. Training, validation, and test partitions are assigned by capture group, including paired interface captures. This prevents packets from one capture group from appearing in several partitions. It does not establish independence across campaigns, providers, or repeated prompts.

4

4

Measurement Methodology

4.1

Scenarios

A scenario defines an interaction pattern through its input and output modalities, interaction style, protocol, and model configuration. Annex D of draft TR 26.870 maps the evaluated scenarios to use cases in TR 22.870 [2]. Server-sent events (SSE), Real-time Transport Protocol (RTP), and JavaScript Object Notation remote procedure calls (JSON-RPC) identify specific protocol forms used by these scenarios. The following table shows the scenario families. Table 1: Scenario families of the testbed and their dominant traffic pattern. Family

Interaction

Transport

Chat

Single and multi-turn chat, streaming and non-streaming, coding, reasoning, token identifiers Iterative LLM and tool rounds for shopping, research, market data, music Screenshot-driven control and Playwright automation Text prompt, generated image Image and text upload, streamed or single response Base64 video upload, or tokenized video over WebRTC with data channel response Text and voice assistants Multi-threaded search with LLM synthesis Local agent runtime driving a hosted model and tools Single task, streaming task, multi-agent delegation

HTTPS, SSE

Agent with MCP tools Browser and computer use Image generation Multimodal analysis Video understanding Real-time conversation Direct web search Personal assistant agent Agent-to-agent

HTTPS, MCP over HTTP HTTPS HTTPS HTTPS, SSE HTTPS, RTP WebSocket, WebRTC HTTPS Loopback, HTTPS JSON-RPC, SSE

Two execution modes identify where inference runs. In remote execution, the client reaches a hosted model through the main interface. Emulation adds impairment to an external path that the testbed does not control. In local execution, the client reaches a self-hosted model through loopback, where a separate queue applies impairment. Local execution reduces provider-side variation. It still includes inference variability, host scheduling, and the semantics of a queue shared by both directions. It does not emulate a radio protocol stack.

4.2

Network Profiles

The profile catalog combines deployment reference points and stress cases. SA4 agreed profile inputs in S4260848 [21]. The 6g_itu_hrllc profile uses a reference point motivated by the hyper reliable and lowlatency communication (HRLLC) objectives in ITU-R M.2160 [22]. It does not implement or validate an IMT-2030 radio system. The 5G quality of service (QoS) identifier (5QI) anchors use d = PDB−2.054 σ for selected normal-delay inputs, where PDB denotes the packet delay budget. The coefficient is the standardnormal 98th percentile. This construction does not guarantee the observed path percentile after shaping and queueing. The following table shows the nominal inputs used to identify the study profiles.

5

Table 2: Nominal profile inputs. Delay and jitter are netem location and scale parameters in each direction. Asymmetric entries show downlink / uplink. Realized conditions depend on the shaping path and workload. Profile no_emulation 6g_itu_hrllc 5g_urban wifi_good cell_edge satellite_leo satellite_geo congested 5qi_7 5qi_80 lossy

Delay (ms)

Jitter (ms)

Loss model

Loss (%)

Rate (Mbit/s)

Role

0 1 20 30 120 22 340 200 80 8 0

0 0.2 5 10 30 7/8 15 / 18 50 10 1 0

none correlated correlated correlated Gilbert-Elliott correlated correlated Gilbert-Elliott correlated correlated independent

0 0.001 0.1 0.1 1 0.5 / 0.8 0.1 / 0.2 3 0.1 0.0001 1 to 30

– 300 100 50 5 100 / 15 50 / 3 1 – – –

Baseline IMT-2030 HRLLC Urban cellular Non-3GPP access Weak coverage LEO satellite GEO satellite Bufferbloat 5QI 7 anchor 5QI 80 anchor Loss tolerance

The lossy profile applies independent loss without added delay. The sweep from 1% to 30% evaluates failure behavior rather than expected deployment conditions. Annex D excludes this profile from aggregates intended to describe deployment conditions. The report and workbook retain some other aggregates that include it. Each result below identifies the population it uses.

4.3

Metrics

The metrics fall into four categories: traffic characteristics, response time, service metrics and task-related quality of experience (QoE). The time to first token (TTFT) and the time to last token (TTLT) are computed from the per-request record as TTFT = tfirst − tstart ,

TTLT = tlast − tstart ,

(1)

where tstart is the request issue time and tfirst and tlast are the first and last recorded response-chunk arrival times. For a non-streamed response, the two arrival times coincide. A response chunk may contain several model tokens. Burst structure is computed from the packet capture. Packets of one direction are walked in time order, and a burst is closed when the inter-arrival time exceeds a gap threshold g, set to 10 ms or 100 ms. The burstiness index at window w is maxk Sk βw = 1 K , (2) K ∑k=1 Sk where Sk is the number of bytes in the k-th window of length w and K the number of windows. The index is evaluated for w from 1 ms to 10 s. Windows below 10 ms are affected by scheduling jitter of the host operating system and are treated as indicative. The methodology to answer RAN2 was agreed in S4-260859 [23]. It organizes the network-layer metrics into five question families, one per assumption: uplink-heavy traffic, bursts and delay bounds, round-trip delay, intra-application variability and tokenized traffic. Several of these metrics join the application-layer records to the packet captures of the same session. For example, the relation between tokens and bytes is estimated per scenario by least squares, bUL ≈ α nin + β ,

bDL ≈ γ nout + δ ,

where b denotes the payload bytes of a turn and n its token count.

6

(3)

For scenarios whose output is consumed by a machine rather than a person, delivery metrics are not enough. A video understanding service may deliver every packet in time and still answer the question wrongly. The task-related QoE metric for closed-form video understanding is the accuracy Avu =

Ncorrect , Nquestions

(4)

over a fixed question set. The denominator includes the questions in the evaluation. Format-invalid responses are also recorded as a separate diagnostic. Their treatment needs to remain fixed when accuracy is compared across profiles.

5

Results from TR 26.870

This section analyzes measurements recorded in draft TR 26.870 V0.6.2 and the workbook distributed with S4aP260148 [2]. Providers retain the workbook labels A, B, and C. The commercial-service summary contains 14,355 request records across ten profiles, including the unshaped reference. The associated flow summary reports 104,664 TCP flows from 1,320 captures. Local execution covers chat, reasoning, multimodal analysis, and video understanding. The agentic worksheets report 200 personal-assistant turns and 198, 99, and 100 turns for the three A2A variants across ten profiles [24]. These populations are separate campaigns. The values below are reported measurements or calculations from the workbook, rather than a new measurement campaign.

5.1

Directionality

The first RAN2 question concerns uplink-heavy traffic. We derive the directional ratio as mean request bytes divided by mean response bytes. This ratio of means differs from a mean of per-turn ratios. Agent network-layer measurements are reported separately below. The following figure depicts application-layer ratios from the workbook summary. The ratios span more than six orders of magnitude. Image generation has a ratio of 7.5 × 10−5 . Nonreal-time video understanding has a ratio of about 300 in the main local campaign and about 915 in the additional run included in the summary. Input modality and interaction pattern determine directionality. Media uploads can be uplink-heavy. Streamed text and generated images can be downlink-heavy. Basic chat and computer control are closer to balanced. These application ratios describe the recorded serialization. Radio dimensioning also requires protocol overhead and the correct network surface. The following table shows the per-turn volumes of the personal assistant agent and the agent-to-agent scenarios at the application and network layers. Table 3: Per-turn traffic volume of the agentic scenarios at the application layer (driver view) and at the network layer (IP payload in the packet capture). Scenario

Surface and layer

UL (B)

DL (B)

UL/DL

Personal assistant agent

Control channel, application Control channel, network Wide-area egress, network

144 3,817 175,649

20,230 49,981 353,972

0.007 0.076 0.496

Agent-to-agent, all variants

Loopback, network

1,931

4,084

0.473

The personal-assistant driver sends a small task to a local runtime and receives a metadata-rich result. This interface has a ratio of 0.007. The runtime’s wide-area egress has a ratio of 0.50 and carries about 7

Video understanding, local, additional run MCP market data agent (A) MCP browser agent (A) Multimodal analysis (B) Computer control (A) Chat basic (A) Chat basic (C) Realtime audio, WebRTC (A) Realtime audio, WebSocket (A) Realtime text, WebRTC (A) Direct web search (A) Chat streaming (B) Chat, local inference Chat streaming (A) Chat streaming (C) Chat reasoning (C) Chat coding (C) Realtime interactive (A) Realtime technical (A) Realtime text (A) Realtime multilingual (A) Image generation (A)

10−5

915 24 3.5 1.8 0.99 0.78 0.64 0.57 0.13 0.038 0.036 0.029 0.012 0.011 0.010 0.0090 0.0068 6.2e-4 2.8e-4 2.4e-4 2.1e-4 7.5e-5

10−4

10−3

10−2

10−1

100

101

102

103

104

Uplink to downlink volume ratio (log scale)

Figure 2: Application-layer ratio of mean request bytes to mean response bytes, calculated from worksheet 3.22 of the companion workbook [2]. Values aggregate ten profiles. Provider letters follow the source. The worksheet also contains local-inference runs, labeled separately. Its WebRTC ratios differ from some per-cell ranges in clause C.4.6 of the draft report. The dashed line marks a symmetric exchange.

176 kB of uplink per turn. Its model requests include accumulated context, the system prompt, and tool definitions. The A2A exchanges also carry more bytes at the network layer than their driver payloads suggest. The network counts include transport headers, acknowledgments, and retransmissions. Neither aggregate in the table is uplink-heavy. Capacity estimates need to identify which surface crosses the access network. The draft report records an initial finding of uplink-heavy agent traffic and notes that repeated context transfer requires further study. Its agentic network measurements give ratios near 0.5. The procedural finding and the measured directionality need to be read with this distinction. Context caching at the inference server can reduce computation [5] while the client still sends context bytes. A protocol that retains context on the server may also reduce transmission. The reported volumes characterize the evaluated runtime and client behavior.

5.2

Burstiness and Delay Sensitivity

The second assumption states that AI traffic is bursty and that its delay requirement varies within one application. The following table shows the burst descriptors of clause D.4.3.4 of TR 26.870 for the local inference scenarios. Each value is the mean over the eight profiles of the local campaign, which include the lossy profile at 10% loss, with the observed range in parentheses.

8

Table 4: Burst descriptors of the local inference scenarios, mean over the eight profiles of the local campaign with minimum and maximum in parentheses. The profiles include lossy at 10% loss. Scenario Video understanding, real-time Video understanding, non-real-time Chat, tokens Chat, streaming Chat, non-streaming Chat, reasoning Multimodal analysis, non-streaming

Peak-to-mean ratio Coefficient of variation Active duration (ms) 14.35 (13.91 – 14.82) 29.85 (6.6 – 82.9) 11.16 (7.06 – 17.61) 21.18 (9.7 – 36.7) 38.06 (31 – 79.4) 24.96 (7.2 – 73.2) 13.91 (3.1 – 79.7)

1.62 (1.60 – 1.64) 2.04 (1.5 – 2.9) 1.27 (1.11 – 1.57) 1.18 (1.0 – 1.4) 1.75 (1.4 – 3.5) 1.14 (1.0 – 1.4) 1.61 (1.3 – 3.5)

36.1 (34.6 – 39.7) 8.5 (1 – 14) 65.0 (60.6 – 70.3) 10.9 (8 – 25) 9.5 (9 – 10) 12.0 (8 – 33) 18.6 (3 – 29)

The reported peak-to-mean ratios exceed one on each profile. Several scenarios show substantial variation across profiles, with some maxima under lossy. These ranges measure variation across conditions. They are not confidence intervals or estimates of variation between repeated runs. Real-time video understanding has a smaller relative spread, consistent with a paced uplink. The workbook specifies 1 ms buckets for these descriptors. The active duration is the mean duration of an active burst period. This bucket analysis differs from the gap-based segmentation in Section 4. Packet selection also varies by scenario, with token chat excluding small acknowledgment packets. Host scheduling and capture offloads may affect the resulting short-window statistics. The following table shows how response latency and TTFT change under the cell_edge and congested profiles relative to the baseline without emulation, for the local inference scenarios. Table 5: Change in response latency under impaired profiles relative to the baseline without emulation, local inference scenarios. Scenario Video understanding, non-real-time Chat, tokens Chat, streaming Chat, non-streaming Chat, reasoning Multimodal analysis, streaming Multimodal analysis, non-streaming

Baseline (s) Cell edge Congested TTFT base (s) TTFT congested (s) 5.02 6.11 6.94 4.94 15.02 2.38 9.38

+295% +1.5% +15.3% +6.9% +16.1% +103.8% +17.8%

+889% +13.7% +46.4% +24.3% +31.3% +216.8% +17.3%

– – 0.35 – 6.45 0.23 –

– – 1.84 – 8.74 5.32 –

Non-real-time video understanding uploads about 1.3 MB per request. Its response latency rises from 5.02 s to about 49.6 s under congested, whose configured rate is 1 Mbit/s. This profile also changes delay, jitter, and loss. The result does not isolate a bandwidth effect. Smaller requests show different penalties. For streaming multimodal analysis, TTFT grows from 0.23 s to 5.32 s, while total response latency grows from 2.38 s to about 7.54 s. First-output and completion latency respond differently. These measurements motivate reporting both. They do not by themselves define a user delay requirement.

5.3

Round-Trip Delay and Connection Setup

The third assumption states that round-trip delay is important. The following table shows the components of round-trip delay aggregated across the remote campaign.

9

Table 6: Round-trip delay components aggregated across the remote measurement dataset. Component TCP handshake RTT TLS handshake HTTP setup RTT

Observations

p50 (ms)

p95 (ms)

p99 (ms)

Mean (ms)

33,292 18,604 32,981

63.21 107.68 0.23

701.17 758.21 38.25

1,386.49 1,947.50 313.26

234.45 272.74 24.81

TCP and TLS handshake durations have medians of 63.21 ms and 107.68 ms. Their observation counts differ. Adding their medians or percentiles does not yield the corresponding statistic of end-to-end connection setup. The workbook reports reuse for 4.58% of TCP flows. This is a flow-level fraction and does not specify the fraction of application requests that required a fresh connection. For the personal assistant, the separate egress summary reports 2.46 flows per turn and 28 distinct destinations across the campaign. Its TLS handshake median is 1.33 s and its 95th percentile is 3.64 s. These observations motivate evaluating persistent connections and TLS resumption. The available aggregates do not quantify their contribution to the critical path of a task. The clients create fresh sessions between runs. The results emphasize connection establishment and do not represent a continuously reused HTTP/2 or QUIC connection [25]. The workbook also reports a median inter-chunk gap of 0.116 ms. Chunk arrival includes server buffering, transport delivery, and client reads. Several events may arrive in one read. Comparing this median with the RTT median cannot isolate model generation time or establish that the network has no effect on token delivery.

5.4

Variability and Agentic Workloads

The fourth RAN2 question concerns variability within an application. The workbook reports variation in burst structure, volume, delay, inter-arrival time, reliability, and connection duration. Remote TCP flow duration has a median of 0.71 s and a 95th percentile of 61.5 s. The distinct-destination count per capture has a 95th percentile of 20 and a maximum of 180. These are pooled descriptions across scenarios and profiles. They do not isolate within-application variation at fixed conditions. The deterministic A2A agents execute without an LLM. Their latency includes protocol handling, transport, configured chunk pacing, and orchestration. The local delegation variant shapes the client-toorchestrator hop and dispatches downstream tasks sequentially. The following figure depicts mean per-turn latency against twice the nominal one-way delay. Single-task latency follows the nominal round-trip delay over much of the profile range. It reaches 687 ms on satellite_geo, compared with a nominal 680 ms. Streaming adds chunk spacing. Delegation has a baseline of 277 ms that includes orchestration. The largest upward deviations occur on cell_edge and congested. These profiles combine several impairments, and the experiment does not separate their causes. Failures occur only on these two profiles. This result motivates further study of delay and reliability for agent signaling. It does not establish a packet-error-rate target or a common QoS requirement for agent systems. The personal assistant has a mean task latency of 11.4 s without added impairment and 9.7 s on 6g_itu_hrllc. The unshaped tasks range from 5.4 s to 31.2 s. This spread prevents attributing the lower mean to the latter profile. Mean latency rises to 24.4 s on satellite_geo and 26.6 s on congested. All 200 reported turns complete successfully. Long timeouts and reliable transport are consistent with completion despite impairment. The observed success rate does not establish a general reliability guarantee.

10

Mean per-turn latency (ms)

1,500 Single task Streaming Multi-agent delegation 1,000

congested

cell_edge

satellite_geo T T R y= atenc

l

500

0 0

100

200

300

400

500

700

600

800

Configured round-trip delay, 2× one-way delay (ms)

Figure 3: Mean per-turn latency of the agent-to-agent scenarios versus the configured round-trip delay of each network profile. The deterministic agents execute without model inference. Streaming includes configured chunk spacing. Delegation shapes only the client-to-orchestrator hop. Data from draft TR 26.870 [2].

5.5

Tokenized Traffic

The fifth question concerns tokenized traffic. A model token is a unit of the model representation. An application chunk is a unit delivered by an interface and may contain several tokens. A network packet is a transport unit and may contain all or part of a chunk. Streamed text exposes incremental output at the application interface. The evaluated video client instead tokenizes sampled frames and sends discrete identifiers over RTP. Responses return through a WebRTC data channel. The following table shows token metrics for the initial video campaign and the token-identifier chat scenario without added impairment. Table 7: Token-related metrics for the scenarios with tokenized traffic, profile without emulation. Metric

Video understanding, real-time

Chat, tokens

Uplink token rate (token/s) Downlink output token rate (token/s) Uplink encapsulation Downlink encapsulation Uplink volume per token (B) Burst peak-to-mean ratio Active / idle duration (ms)

2,051 24.1 RTP packets Streamed chunks about 2.5 13.91 36.7 / 2,578

Not resolved in source 214 HTTP token array HTTP response body about 6.0 16.11 70.3 / 1,258

The combined workbook summary labels about 200 token/s as the chat uplink rate, but the scenario sheet identifies 200 to 218 token/s as output rates. We leave the uplink rate unreported. The two video campaigns report about 2.2 to 2.5 B per generated uplink token without added impairment. The accounting includes packetization overhead and is consistent with compact token identifiers. A two-byte identifier can address 65,536 vocabulary entries. An embedding instead carries a vector whose byte count depends on dimension and precision. The term tokenized traffic needs to identify the representation. The chat fits report 4.4 to 5.4 request bytes per input token with r2 ≥ 0.996. Streamed response fits report 398 to 440 B per output token, including event framing and metadata in these implementations. These slopes do not define the storage size of a model token. 11

0.6 Video understanding accuracy Avu

Delivered uplink volume reduction (%)

Huawei contributed an extended campaign [26] using Liquid [27] and VILA-U [28] on 25 StreamingBench clips [29], with five questions per clip. The workbook reports 125 questions per profile and model. This campaign uses different model and response configurations from the initial campaign. The following figure depicts its delivered uplink volume and task accuracy under independent uplink loss. Reduction = loss Measured

60

40

20

0.4

0.2 Liquid VILA-U 0

0 0

5

10

15

20

25

0

30

5

10

15

20

25

30

Configured uplink loss (%)

Configured uplink loss (%)

Figure 4: Real-time video understanding under independent uplink packet loss. Left: reduction of delivered uplink volume relative to the baseline. Right: correct answers divided by 125 questions per model and profile. Lines connect the reported observations and do not represent a fitted model. Repeated-run uncertainty is unavailable. Data from Annex D of TR 26.870 [2], contributed in [26].

Through 10% configured loss, uplink volume reduction is close to the configured fraction. It reaches 32.27% at 20% loss and 65.28% at 30% loss. The generated token count also falls at the two highest settings. The volume reduction includes session behavior in addition to packet dropping. Through 10% loss, each model changes by at most three correct answers relative to baseline. At 20%, Liquid falls from 63 to 54 correct answers, or from 50.4% to 43.2%. VILA-U falls from 58 to 52, or from 46.4% to 41.6%. These are declines of 7.2 and 4.8 percentage points. At 30%, accuracy is 27.2% and 20.0%, near the 25% chance reference for four choices. The workbook does not provide repeated-run dispersion or paired question outcomes. Questions from the same clip may also be dependent. The observations do not establish equivalence at 20% or a precise loss-tolerance boundary. The workbook reports about 3.27 output tokens per application chunk across the tested profiles. This relation may help estimate token counts at an instrumented application interface. Encrypted network packets do not expose these chunk boundaries directly. The relation also depends on the response implementation. Correlated-loss tolerance remains unmeasured. Its effect can depend on packetization, temporal dependencies, recovery, and task sampling, so independent loss does not provide a general bound.

5.6

Synthetic Traffic Generation

The retained dataset snapshot contains 56,297 attributed flows in 927 capture groups, derived from 1,960 captures and 8,022 labeled sessions [30]. It includes 19,729 loopback flows and 164 User Datagram Protocol (UDP) flows. Streaming contributes 16,259 flows, while the real-time WebRTC category contains nine. These counts describe the dataset snapshot, rather than the remote campaign alone. Two categoryconditioned Markov baselines use the clean-profile training partition. Order 0 samples channel marginals independently. Order 1 adds transitions within the size, inter-arrival, and direction channels, while retaining independence between them. Both decode bins by sampling the empirical training values within each bin. The following table shows the two-sample Kolmogorov-Smirnov (KS) statistic [31] against 931 held-out 12

clean-profile flows in seven categories, as reported with the modeling study [32]. Table 8: Held-out KS statistic of the Markov baselines, unweighted mean over seven traffic categories. Lower is better. Generator Markov order 0 Markov order 1

Packet size

Inter-arrival

Sequence length

Uplink fraction

Total bytes

Duration

0.134 0.131

0.142 0.136

0.331 0.331

0.286 0.284

0.513 0.477

0.387 0.373

Packet-size and inter-arrival KS distances are about 0.13 to 0.14. Flow-level distances are larger, reaching 0.51 for total bytes. Separate channel chains do not capture the joint relationship between timing, size, and direction. Sequence length is sampled from the empirical training distribution. Its held-out discrepancy can include partition differences, finite sampling, and the sequence-length cap. These distances compare empirical distributions. They are not significance tests over independent packets. Capture-group separation reduces direct leakage but leaves temporal and provider generalization for further evaluation. A learned generator needs comparison against these baselines on the same partitions and accounting rules.

6

Emulator Fidelity and Threats to Validity

A profile identifies emulator inputs. The resulting path statistics depend on the queueing arrangement, workload, and implementation revision. ATEME examined the common platform described in TR 26.934 [33] during QUIC media-delivery tests [34]. We compare that analysis with the study configuration and the retained emulator sources. The ATEME snapshot differs in distribution, explicit reordering, and some loss parameters. The results below identify these differences rather than treating the catalog as one invariant configuration.

6.1

Reordering under Per-Packet Jitter

Netem assigns per-packet delivery times from a delay distribution. Packets can overtake one another when their spacing is smaller than the delay variation. A delay-correlation setting does not provide an in-order service guarantee. For the table-based distributions in the checked Linux 6.1 and 6.17 kernels, reduction of the random value to a distribution-table index can attenuate the requested correlation. The retained probes report lag-1 delay autocorrelation within ±0.03 for settings of 0%, 50%, and 99%. This result is specific to those versions and probes. The following table shows ATEME’s reordering measurements for bursts of eight 1,200-byte packets every 40 ms, equivalent to 1.92 Mbit/s of packet data. Table 9: Reordering through the emulator with HTB rate limiting and per-packet netem jitter, measured in [34] on the earlier profile snapshot. Delay and jitter magnitudes match Table 2, but the earlier cell-edge distribution was Pareto rather than Paretonormal and its explicit reordering setting differed. Profile cell_edge wifi_good 5g_urban 5qi_80

Median one-way delay (ms)

Arrived out of order

Overtaken by a packet ≥ 3 later

110.5 30.0 20.1 8.0

52.7% 65.7% 64.7% 64.5%

33.9% 44.3% 42.7% 42.1%

The Packet Data Convergence Protocol (PDCP) supports in-sequence delivery, subject to configuration and reordering-timer behavior [35]. An emulator needs to state whether it represents an ordered service.

13

RFC 9002 [36] recommends an initial QUIC packet threshold of three and permits adaptation. Receiver arrival order alone does not determine sender loss declarations. ATEME’s tested QUIC relay retransmitted 22% to 26% of packets on its cell_edge configuration, with 77% to 84% of those retransmissions classified as spurious. This result concerns that implementation and configuration. TCP implementations using Recent ACKnowledgment and Tail Loss Probe (RACK-TLP) [37] can adapt to reordering, but the resulting effect on the AI campaigns was not measured. Netem’s native rate scheduling can serialize queued packets and reduce reordering. It also changes delay. ATEME reports a cell-edge median rising from about 110 ms to 167 ms. The loopback path already uses native rate scheduling when a rate is configured, so the main-interface reordering percentages do not transfer directly to local experiments.

6.2

Suppression of Correlated Loss

Netem’s correlated random-loss generator mixes a fresh random value with its previous state. For small nominal loss probabilities, the resulting distribution can produce far fewer threshold crossings. We evaluate the integer recurrence offline using 107 draws per setting from a deterministic SplitMix64 input stream. The ancillary files provide the implementation, its fixed seeds, and the resulting event counts. This is an algorithm check and does not transmit packets through the kernel. The following table shows selected results. Table 10: Loss events of the netem correlated loss generator in 107 draws, offline evaluation of the kernel recurrence. Setting Loss 0.1%, correlation 25% (5g_urban) Loss 0.1%, correlation 30% (wifi_good) Loss 0.1%, correlation 0% (reference) Loss 5%, correlation 15%

Loss events

Effective rate

0 0 10,074 71,012

0 observed 0 observed 0.10074% 0.71012%

The checked correlated-loss inputs produce no loss events in 107 draws for 6g_itu_hrllc, 5g_urban, wifi_good, both satellite directions, 5qi_7, and 5qi_80. ATEME also reports no loss in 50,000 packets at 0.1% nominal loss and 15% correlation. With zero correlation, it reports 51 losses in 49,950 packets [34]. These observations do not establish zero loss probability. Queue overflow and the external path can add loss. They show that a configured nominal rate is not a measured path rate. Independent loss can be requested by setting correlation to zero in the correlated-random-loss syntax. This change must not be applied to Gilbert-Elliott syntax, where the second parameter has a different meaning.

6.3

Gilbert-Elliott Parameter Mapping

The cell_edge and congested profiles use a Gilbert-Elliott model [38, 39]. With loss probability 1 in the bad state and 0 in the good state, the model is defined by the transition probability p from the good to the bad state and r from the bad to the good state. The stationary loss rate L and the mean loss burst length B are p 1 L= , B= . (5) p+r r The inspected emulator revision maps the configured loss rate to p and the field named loss correlation to r. For cell_edge, p = 1% and r = 35% imply a stationary loss rate of 2.78%. For congested, p = 3% and r = 40% imply 6.98%. These are model expectations, not measured path losses. Earlier snapshots supplied only the first parameter, resulting in an independent-loss configuration. ATEME reports 0.8% to 1.2% on that earlier cell-edge case. The available campaign provenance does not identify the mapping used

14

by every workbook result. Setting the second parameter to zero would make the bad state absorbing and is not a correction. For a target stationary loss rate L and mean burst length B, the parameters are r=

1 , B

p=

Lr . 1−L

(6)

Preserving the burst lengths implied by the current settings, this gives p = 0.3535% for cell_edge and p = 1.2371% for congested.

6.4

Consequences for the Published Results

The independent-loss sweep does not use the correlated-random-loss or Gilbert-Elliott mappings. This removes those two specific ambiguities, but it does not verify receiver loss or eliminate queue effects. Deployment-profile results require the executed configuration and queueing path for interpretation. Crossscenario volume asymmetry remains an observation of the recorded campaigns. Its magnitude under corrected profiles requires new measurements. A global severity ordering cannot be inferred when profiles change delay, rate, ordering, and loss together. Quantitative claims about configured loss need repetition with measured loss and declared byte accounting.

6.5

Other Threats to Validity

The following threats apply in addition to the emulator effects: • Provider-side variance. For remote execution, the variance of the provider can exceed the effect of the network. For chat with provider A, the mean latency without emulation is 19.5 s and on 5g_urban 9.8 s. The orchestrator runs all runs of one profile before the next, so a drift in provider load over the hours of a campaign is confounded with the profile. Interleaving profiles in randomized order would separate the two. • Application-layer volumes. Request and response sizes in the session records are estimated from the serialized payloads. They exclude transport and TLS overhead and, for agents, the traffic of the runtime itself. Statements on directionality for radio dimensioning need the network-layer volumes. • Transport coverage. Most hosted requests use TCP. WebRTC media use UDP. The campaign does not provide a matched comparison with QUIC or persistent connections. Filters and host segmentation or aggregation offloads can also change the packet units visible in a capture. • Evaluation support. Tokenized video uses one transport implementation with two models and 125 questions per profile. Repeated-run dispersion and paired outcomes are unavailable. The agentic measurements cover one runtime and deterministic A2A agents. • Aggregation across profiles. Some local aggregates include the lossy stress case. Cross-profile ranges do not estimate uncertainty at a fixed condition. Retry and resume rules can also change the population of completed records. Reliability estimates require all attempts and declared exclusion rules. The profile contract needs to distinguish intrinsic generator parameters from observed path statistics. It also needs to state the queueing path, ordering behavior, loss process, byte accounting, and workload. Qualification should report delay distributions, loss and burst lengths, rate, reordering, and overflow under declared packet sizes and pacing. Corrected campaigns need a new catalog version. Earlier labels and raw records need to remain associated with the configuration that produced them. 15

7

Use in Standardization

The testbed was introduced to SA4 in February 2026 [40]. It is documented as Annex B of TR 26.870 as the testbed used to obtain the measurements of the study, with the network emulator documented in Annex E. The network profiles were agreed in S4-260848 [21], and the methodology for the RAN2 questions in S4-260859 [23]. The hosting of the software as a 5G-MAG reference tool was addressed in S4-261323 [41]. The source code is available under the 5G-MAG public license [30]. Participating companies extended scenarios and reviewed changes through the public repository. Huawei contributed real-time video understanding and token-identifier scenarios. The draft report records five initial findings in clause 7.1 with references to Annex C. These findings remain part of an evolving study. Our analysis identifies where pooled measurements, observation points, and emulator revisions limit their interpretation. Qualcomm also contributed high-level observations on scenario dependence and token representation [42]. Kundu et al. [9] use the testbed in a separate discussion of AI traffic awareness.

7.1

Software and Data Availability

The testbed source is available from 5G-MAG [30]. The implementation review uses the refactor revision d055fa68ef4d. The report and workbook snapshot is S4aP260148, distributed on October 23, 2026 [2]. The figures in this paper use values from that workbook. The source code and nominal profiles alone do not reproduce historical hosted-service behavior. Reproduction of a campaign also requires its model configuration, prompts, executed commands, software versions, captures, and session records. This paper does not distribute the raw hosted-service captures. The dataset counts and generator statistics describe a retained study snapshot and do not constitute a released benchmark.

8

Summary

We described an open testbed for measuring AI service traffic and analyzed the results recorded in draft TR 26.870 V0.6.2. The testbed separates network emulation from scenario execution and associates application records with packet captures. The reported traffic has different directional ratios, burst structures, and delay behavior across scenarios. Agent measurements show that local driver traffic and wide-area runtime traffic can have different volumes. The deterministic A2A experiments show the effect of path delay without model inference. The tokenized-video sweep shows accuracy degradation at high independent loss, with limited support for estimating a tolerance boundary. The emulator analysis identifies three interpretation issues: reordering under per-packet jitter, suppression of rare correlated-random-loss events, and a Gilbert-Elliott parameter mapping that changes stationary loss. Main-interface and loopback shaping also differ. A nominal profile does not establish the conditions experienced by an application. Campaigns need versioned configurations and workload-specific path measurements. Further work includes repeated campaigns with corrected profiles and randomized profile order, matched evaluation of persistent TCP and QUIC connections, and experiments with correlated or trace-driven loss. Task-quality evaluation needs repeated runs and per-question outcomes. Synthetic traffic generation needs comparison on joint flow statistics and held-out campaigns. These steps would allow the measurements to support more precise traffic models and network requirements.

16

Acknowledgments The author thanks the 5G-MAG reference tools team for hosting, project management and code review of the testbed, Huawei for the real-time video understanding scenario and its loss sweep, ATEME for the analysis of the netem configuration, and the delegates of 3GPP SA4 who contributed, reproduced and reviewed the results collected in TR 26.870.

References [1] 3GPP. Study on 6G use cases and service requirements. Technical Report TR 22.870 V20.0.0, 3rd Generation Partnership Project, 2026. [2] 3GPP. Study on media aspects for 6G system (release 20). Technical Report TR 26.870 V0.6.2, 3rd Generation Partnership Project, October 2026. Draft snapshot S4aP260148, October 23, 2026, with companion workbook. https://www.3gpp.org/ftp/TSG_SA/WG4_CODEC/3GPP_SA4_AHOC_ MTGs/SA4_Plenary/Docs/S4aP260148.zip. [3] 3GPP. Study on XR (extended reality) evaluations for NR. Technical Report TR 38.838, 3rd Generation Partnership Project, 2021. [4] 3GPP. System architecture for the 5G system (5GS). Technical Specification TS 23.501, 3rd Generation Partnership Project, 2026. [5] Yichao Yuan, Ankita Nayak, Souvik Kundu, and Nishil Talati. Agentic AI workload characteristics. arXiv preprint arXiv:2605.26297, 2026. [6] Chaokun Chang, Yukun Zhou, Kaihua Fu, Dakai An, Tianyu Feng, Hanfeng Lu, Sheng Yao, Pu Guo, Yinghao Yu, Yizhou Shan, Bo Li, Binhang Yuan, and Wei Wang. From LLM inference to agentic workloads: Characterization and implications for serving systems. arXiv preprint arXiv:2608.15127, 2026. [7] Andrew Nguyen, Samson Kempiak, Agrim Gupta, Koushik Kar, and Ish Kumar Jain. MINT: Modeling GenAI impact on network traffic. arXiv preprint arXiv:2609.35742, 2026. [8] Davide Lamagna, Albert Cabellos, Alberto Rodriguez-Natal, Gábor Rétvári, and Berta Serracanta. Towards traffic modelling of multi-agent systems: The role of coordination topology. arXiv preprint arXiv:2608.20494, 2026. [9] Lopamudra Kundu, Xingqin Lin, Shuvo Chowdhury, and Sree Sankar. AI-native 6G for distributed intelligence: Traffic characteristics, awareness, and AI grid. arXiv preprint arXiv:2608.14627, 2026. [10] Roy Weiss, Daniel Ayzenshteyn, Guy Amit, and Yisroel Mirsky. What was your prompt? A remote keylogging attack on AI assistants. In Proceedings of the 33rd USENIX Security Symposium, 2024. [11] Shahrooz Pouryousef, Jesus Lopez, Saeefa Rubaiyat Nowmi, Md Mahmuduzzaman Kamol, Moinul Hossain, Muoi Tran, and Mohammad Saidur Rahman. A large-scale benchmark and risk assessment of traffic analysis attacks on cloud LLM services. arXiv preprint arXiv:2609.31877, 2026. [12] Fan Li, Xiangyu Gao, Zixuan Liu, Tong Li, Chuanpu Fu, Ziqiang Wang, and Ke Xu. ANT: A multi-granularity network traffic dataset and benchmark for agents behavior auditing. arXiv preprint arXiv:2610.06514, 2026. 17

[13] Stephen Hemminger. Network emulation with NetEm. In Proceedings of linux.conf.au, 2005. [14] Lucas Nussbaum and Olivier Richard. A comparative study of network link emulators. In Proceedings of the Communications and Networking Simulation Symposium (CNS), 2009. [15] Audrius Jurgelionis, Jukka-Pekka Laulajainen, Matti Hirvonen, and Alf Inge Wang. An empirical study of NetEm network emulation functionalities. In Proceedings of the 20th International Conference on Computer Communications and Networks (ICCCN), 2011. [16] Model Context Protocol. specification, 2025.

Model context protocol specification.

https://modelcontextprotocol.io/

[17] A2A Project. Agent2agent (A2A) protocol specification. https://a2a-protocol.org, 2025. Linux Foundation. [18] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with PagedAttention. In Proceedings of the 29th ACM Symposium on Operating Systems Principles (SOSP), 2023. [19] OpenClaw. OpenClaw: A local-first personal AI agent. https://openclaw.ai, 2026. [20] mitmproxy project. mitmproxy: An interactive HTTPS proxy. https://mitmproxy.org, 2026. [21] Huawei and Qualcomm. [FS_6G_MED] correction on network profiles for evaluation in AI traffic characteristics testbed. 3GPP TSG SA WG4 #135-bis-e, document S4-260848, April 2026. [22] ITU-R. Framework and overall objectives of the future development of IMT for 2030 and beyond. Recommendation ITU-R M.2160-0, International Telecommunication Union, November 2023. [23] Qualcomm and Huawei. [FS_6G_MED] pCR on methodology to answer RAN2 LS. 3GPP TSG SA WG4 #135-bis-e, document S4-260859, April 2026. [24] Qualcomm. [FS_6G_MED] agentic AI test scenarios and results. 3GPP TSG SA WG4 #137-e, document S4-261814 (revision of S4-261446), August 2026. [25] Jana Iyengar and Martin Thomson. QUIC: A UDP-based multiplexed and secure transport. RFC 9000, IETF, 2021. [26] Huawei. [FS_6G_MED] additional evaluation of real-time video understanding under packet loss sweep. 3GPP TSG SA WG4 #137-e, document S4-261818 (revision of S4-261455), August 2026. [27] Junfeng Wu, Yi Jiang, Chuofan Ma, Yuliang Liu, Hengshuang Zhao, Zehuan Yuan, Song Bai, and Xiang Bai. Liquid: Language models are scalable and unified multi-modal generators. arXiv preprint arXiv:2412.04332, 2024. [28] Yecheng Wu, Zhuoyang Zhang, Junyu Chen, Haotian Tang, Dacheng Li, Yunhao Fang, Ligeng Zhu, Enze Xie, Hongxu Yin, Li Yi, Song Han, and Yao Lu. VILA-U: A unified foundation model integrating visual understanding and generation. arXiv preprint arXiv:2409.04429, 2024. [29] Junming Lin, Zheng Fang, Chi Chen, Zihao Wan, Fuwen Luo, Peng Li, Yang Liu, and Maosong Sun. StreamingBench: Assessing the gap for MLLMs to achieve streaming video understanding. arXiv preprint arXiv:2411.03628, 2024. 18

[30] Imed Bouazizi. 6G AI traffic characterization testbed. https://github.com/5G-MAG/6G-Testbed, 2026. 5G-MAG Reference Tools. Implementation review: refactor revision d055fa68ef4d. [31] Frank J. Massey. The Kolmogorov-Smirnov test for goodness of fit. Journal of the American Statistical Association, 46(253):68–78, 1951. [32] Qualcomm. [FS_6G_MED] synthetic traffic generation for AI media services. 3GPP TSG SA WG4 #137-e, document S4-261447, August 2026. [33] 3GPP. Test platform for media delivery technologies. Technical Report TR 26.934, 3rd Generation Partnership Project, 2026. [34] ATEME. [FS_QStream_MED] netem profile emulation issues. 3GPP TSG SA WG4 MBS ad hoc, document S4aI260095, October 2026. [35] 3GPP. NR; packet data convergence protocol (PDCP) specification. Technical Specification TS 38.323, 3rd Generation Partnership Project, 2021. [36] Jana Iyengar and Ian Swett. QUIC loss detection and congestion control. RFC 9002, IETF, 2021. [37] Yuchung Cheng, Neal Cardwell, Nandita Dukkipati, and Priyaranjan Jha. The RACK-TLP loss detection algorithm for TCP. RFC 8985, IETF, 2021. [38] Edgar N. Gilbert. Capacity of a burst-noise channel. Bell System Technical Journal, 39(5):1253–1265, 1960. [39] E. O. Elliott. Estimates of error rates for codes on burst-noise channels. Bell System Technical Journal, 42(5):1977–1997, 1963. [40] Qualcomm. [FS_6G_MED] testbed for AI media services traffic characterization. 3GPP TSG SA WG4 #135, document S4-260114, February 2026. [41] Apple, Xiaomi and Qualcomm. [FS_6G_MED] on the hosting of TR 26.870 AI traffic characterization testbed. 3GPP TSG SA WG4 #136, document S4-261323, May 2026. [42] Qualcomm. [FS_6G_MED] high-level observations on AI traffic characteristics. 3GPP TSG SA WG4 FS_6G_MED ad hoc, document S4aP260111, October 2026.

19

Related documents

• Secure Agentic AI and Multimodal Intelligence in 6G Communication Systems#1423228
• 6G: From Connectivity Infrastructure to Guaranteed Digital Services#1402238
• A Graph-Based Stackelberg Security Game for Trustworthy 6G Disaggregated Architecture#1077428
• Privacy-Preserving Coordinated Operation of Power Grids and AI Data Centers: A Checkpoint-Aware Three-Phase Scheme#1062261
• Large Language Models for Optimization in Next-Generation Wireless Network Management: A Survey#1449247