Work Plan for Evaluation of QUIC-based Protocols for On-Demand and Live Video Services

Introduction

This contribution proposes a work plan for the Rel-20 study item FS_QStream_MED (Evaluation of QUIC-based protocols for on-demand and live video services), hosted by the MBS SWG.

Study Objectives

The study encompasses six main objectives:

Objective 1: Application Scenarios

Identify application scenarios and their uplink/downlink delivery characteristics for segmented media delivery services, including: - Low latency video streaming - Live streaming - On-demand video platforms - Short-form video platforms

Objective 2: Streaming Technologies

Identify existing and emerging segmented media streaming technologies, specifically QUIC-based technologies from TR 26.804: - DASH over HTTP/3 - MoQ - MPEG-DASH over WebTransport - MPEG-DASH Part 6 over QUIC

Objective 3: Evaluation Framework

Define an evaluation framework for media delivery protocols in the context of 5G Media Streaming (TS 26.501 and TS 26.512):

Objective 3A: Metrics Definition

Determine existing metrics reflecting QoE from relevant specifications (TS 26.247, TR 26.944, ITU-T P.1203, CTA-2066): - Playback time from live edge - Start-up time - Rebuffering events and duration - Streaming quality - Associated QoS metrics

Objective 3B: Impact Assessment

Document potential impacts on: - Media delivery architecture (TS 26.501) - Delivery protocols (TS 26.512) - Codecs and formats (TS 26.511)

Considering factors such as: - Current CDN architectures - 3GPP core network architecture (TS 23.501) - UE implementation - Encrypted content - Caching efficiency - Scalability - Distributed deployment capability - General-purpose implementation readiness

Objective 3C: Test Framework Design

Design a test framework for collecting selected metrics to evaluate baseline (DASH over HTTP 1.1) against identified technologies.

Objective 4: Technology Evaluation

Evaluate selected technologies by collecting QoE metrics under 3GPP network conditions using mobile network traces. This includes: - Developing network simulation setup - Selecting network traces for relevant application scenarios

Note: Objective 4 is split into three phases: - Phase 1: Develop network simulation setup - Phase 2: Select network scenarios - Phase 3: Run experiments and evaluations

Objective 5: Integration Study (Conditional)

If sufficient evidence of benefits is identified:

Objective 5A: Gap Analysis

Study integration of beneficial emerging technologies into 5G Media streaming and identify gaps in: - Architecture (TS 26.501) - Protocols (TS 26.512) - Codecs and formats (TS 26.511) - Relevant video coding tools (e.g., layered video coding, temporal subsequences)

Objective 5B: Normative Work Identification

Identify potential normative work requirements for architecture, protocols, and codecs/formats.

Objective 6: External Coordination

Communicate progress to relevant SDOs (IETF MoQ Working Groups) and solicit collaboration with organizations conducting similar work (e.g., SVTA).

Detailed Work Plan Timeline

SA4#134 (November 2025, Dallas)

• Agree study item description

SA#110 (December 2025, Baltimore)

• Approve new study item

Post SA4#134 MBS SWG Calls (January 2026)

• Discuss work plan

SA4#135 (February 2026, Goa)

• Finalize work plan
• Agree specification skeleton for TR 26.934 (Test platform for media delivery technologies) ‡
• Agree specification skeleton for TR 26.835 (Evaluation of QUIC-based streaming protocols)
• Initiate Objective 1 (services and application use cases)
• Initiate Objective 3c (test framework design) ‡
• Initiate Objective 3b (study impact on architectures) ‡

Post SA4#135 MBS SWG Calls (TBD)

• Progress Objectives 1, 3b, 3c
• Initiate Objective 3a (determine relevant metrics)
• Initiate Objective 2 (identify media streaming technologies)

SA4#135-bis-e (April 2026)

• Complete Objectives 1 and 2
• Complete Objective 3b ‡
• Progress Objective 3c ‡
• Progress Objective 3a
• Initiate Objective 4, Phase 1 (develop network simulation setup)
• Communicate with other 3GPP WGs and external organizations (Objective 6)

Post SA4#135-bis-e MBS SWG Calls (TBD)

• Progress Objective 3c ‡
• Progress Objective 4
• Complete Objective 3a

SA4#136 (May 2026, Montreal)

• Complete Objective 3 (finalize TR 26.934) ‡
• Complete Objective 4, Phase 1
• Initiate Objective 4, Phase 2 (select network scenarios)
• Continue external coordination (Objective 6)

SA#112 (June 2026, Singapore)

• Approval of TR 26.934

Post SA4#136 MBS SWG Calls (TBD)

• Progress Objective 4, Phase 2

SA4#137-e (August 2026, online)

• Complete Objective 4, Phase 2
• Initiate Objective 4, Phase 3 (run experiments and evaluations)

Post SA4#137-e MBS SWG Calls (TBD)

• Progress Objective 4, Phase 3

SA4#138 (November 2026, Calgary)

• Complete Objective 4
• Initiate Objective 5 (result analysis)
• Continue external coordination (Objective 6)
• Send TR 26.835 for information to SA

SA#114 (December 2026, US)

• Presentation of TR 26.835 to SA

Post SA4#138 MBS SWG Calls (TBD)

• Progress Objective 5
• Start working on conclusions and recommendations

SA4#139 (February 2027, South Korea)

• Complete all objectives
• Finalize conclusions and recommendations
• Send TR 26.835 for approval to SA

SA#115 (March 2027, TBD)

• Approval of TR 26.835

Key Deliverables

• TR 26.934: Test platform for media delivery technologies (approved SA#112, June 2026)
• TR 26.835: Evaluation of QUIC-based streaming protocols for on-demand and live video services (approved SA#115, March 2027)

Note: ‡ indicates work related to the test platform (TR 26.934)

Proposal

Agreement is requested on the work plan detailed above.

3GPP TR 26.934 V0.0.1 - Test Platform for Media Delivery Technologies

Document Overview

This is a Release 20 Technical Report (TR) from SA4 (Services and System Aspects) that defines a test platform for evaluating media delivery technologies. The document is in its initial draft stage (V0.0.1) and contains primarily editor's notes outlining the planned structure and content.

Main Technical Contributions

1. Test Platform Description (Clause 4)

4.1 General

• Provides an introduction to the test platform and overview of its functionalities

4.2 Architecture

• Details the tools and building blocks comprising the platform
• Specifies the structural components of the test environment

4.3 Features

• Documents the capabilities of the test platform
• Outlines what testing and evaluation functions are supported

4.4 Limitations and Assumptions

• Identifies aspects that are out of scope for the test platform
• Documents design assumptions made during platform development

2. Test Platform Setup (Clause 5)

5.1 General

• Lists possible configurations and applications of the test platform
• Provides overview of setup procedures

5.2 Network Simulation Setup

• Contains details on configuring network setups for testing
• Specifies how to establish the network environment for simulations

5.3 Protocol Stack Configuration

• Provides instructions for setting up specific protocols on top of the network layer
• Details protocol configuration procedures

5.4 Media Application Setup

• Gives instructions on integrating the application under test
• Specifies how to plug in media applications to the test platform

3. Obtaining Measurements (Clause 6)

6.1 General

• Overviews the monitoring system
• Lists metrics obtainable from simulations

6.2 Available Metrics

• Documents the specific metrics that can be collected during testing
• Defines measurement parameters for media delivery evaluation

6.3 Logging System

• Details the tools available for metrics logging
• Specifies data collection and storage mechanisms

4. Annexes

Annex A (Informative): Possible Extensions

• Includes external tools/configurations that can be used with the test platform
• Provides information on platform extensibility

Annex B (Informative): Bibliography

• Supporting references (not yet populated)

Annex C (Informative): Change History

• Document revision tracking

Document Status

This TR is in its earliest draft stage with all technical clauses containing only editor's notes. The structure has been defined but actual technical content, specifications, and details are yet to be populated. The document establishes the framework for a comprehensive test platform that will enable evaluation of media delivery technologies in 3GPP systems.

Technical Report Summary: TR 26.835 - Evaluation of QUIC-based Streaming Protocols

Document Overview

This is a draft Release 20 Technical Report (TR 26.835 v0.0.1) from SA4 that aims to evaluate QUIC-based streaming protocols for on-demand and live video services. The document is in early template stage with structural placeholders but minimal technical content filled in.

Main Technical Scope

The TR focuses on evaluating QUIC-based streaming protocols as alternatives or enhancements to traditional HTTP/1.1-based DASH streaming for media delivery applications.

Document Structure and Planned Content

Clause 4: QUIC-based Streaming Protocols

Planned Coverage: - Protocols for media streaming (4.2): Will detail specific QUIC-based protocols being evaluated - Multiple protocol subclauses planned covering: - Introduction to each protocol - Technical design - Features - Targeted applications - Baseline protocol: DASH over HTTP/1.1 will be included as the comparison baseline - Other protocols (4.3): QUIC-based protocols not included in the evaluation (may be removed if empty) - Summary (4.4): Comparative overview of protocols

Clause 5: Evaluation Setup

Planned Coverage: - Considered applications (5.2): Media streaming application scenarios to be evaluated - Each scenario will include: - Description - Requirements - Analysis - Metrics selection (5.3): KPIs and performance metrics relevant to the evaluation - Other considerations (5.4): Additional evaluation parameters (may be removed if empty)

Clause 6: Performance Evaluation Tests

Planned Coverage: - Evaluation testbed setup (6.2): Application of TR 26.934 test framework - Test scenarios (6.3): Specific tests to be executed - Each test scenario will include: - Description - Simulation results - Analysis - Test results analysis (6.4): Cross-test comparative analysis - Evaluation summary (6.4 - duplicate numbering in template): Performance comparison against baseline

Clause 7: Conclusions and Recommendations

Planned Coverage: - Study conclusions - Potential recommendations for 3GPP specifications

Annex A: Integration Considerations

Planned Coverage: - Information on integrating examined protocols into current media delivery ecosystem - Independent of test results

Key Technical Approach

The TR will: 1. Survey and document relevant QUIC-based streaming protocols 2. Define application scenarios for on-demand and live video services 3. Establish evaluation metrics appropriate for media streaming 4. Leverage TR 26.934 test framework for performance evaluation 5. Compare QUIC-based protocols against HTTP/1.1-based DASH baseline 6. Provide recommendations for potential standardization or adoption

Current Status

This is a skeleton document (v0.0.1) with only structural placeholders and editor's notes. No technical content, protocol details, evaluation results, or conclusions have been populated yet. The document establishes the framework for a comprehensive evaluation study to be conducted during Release 20 development.

Summary of S4-260212: Pseudo-CR on Design Principles for the QUIC Test Platform

Document Overview

This is a pseudo-CR contribution from Xiaomi to TR 26.934 v0.0.1 "Test platform for media delivery technologies". The document proposes initial design principles for a test platform that will be used to study QUIC-based protocols for media delivery in both segmented media (FS_QStream_MED) and Real-time Communication (FS_Q4RTC_MED) scenarios.

Main Technical Contributions

Structure and Organization of TR 26.934

The contribution proposes formatting and structuring Clause 4 of TR 26.934, establishing the foundational organization for documenting the test platform.

Test Platform Architecture (Clause 4.2)

The main technical contribution is the definition of a three-block architecture for the test platform:

1. Network Block

• Responsible for underlying network simulation
• Details to be documented in Clause 4.2.1

2. Transport Protocol Block

• Manages the transport layer protocol (e.g., QUIC)
• Handles transmissions over the simulated network
• Details to be documented in Clause 4.2.2

3. Application Block

• Implements the media technology being tested
• Details to be documented in Clause 4.2.1 (note: appears to be a numbering error in the source document)

Additional Structural Elements

The contribution establishes placeholders for:

• Clause 4.1 (General): Introduction and overview of platform functionalities
• Clause 4.3 (Features): Detailed capabilities of the test platform
• Clause 4.4 (Limitations and assumptions): Out-of-scope aspects and design assumptions

Status

All technical content sections are marked with Editor's Notes, indicating this is an initial structural proposal with detailed content to be added in future contributions.

Summary of S4-260213: Template for Targeted Application and Services

Document Overview

This contribution from Xiaomi proposes a standardized template for documenting media streaming application scenarios within the FS_QStream_MED study. The document aims to provide structure and consistency when contributors propose new application scenarios for evaluation.

Main Technical Contributions

1. Study Objectives Context

The document references the relevant objectives from FS_QStream_MED that pertain to application scenarios, specifically:

• Objective #1: Identification of application scenarios and their delivery characteristics (uplink/downlink) for segmented media delivery services including:
• Low latency video streaming
• Live streaming
• On-demand platforms

• Short-form video platforms

• Objective #2: Identification of QUIC-based streaming technologies (DASH over HTTP/3, MoQ, MPEG-DASH over WebTransport, MPEG-DASH Part 6 over QUIC)

The document notes that each service/application may have different metric requirements, necessitating per-service/application analysis.

2. Proposed Application Scenario Template

The main technical contribution is a structured template with four mandatory sections:

2.1 Scenario Name

• Descriptive title for the application scenario
• References Clause 5.2.1 of TR 26.835 v0.0.1

2.2 Description

Comprehensive details including: - Freeform text describing the use case - Streaming-specific aspects: - Delivery delay characteristics (Live, On-demand) - Content source (Studio, User-Generated) - Content characteristics (Low Bitrate, 4K) - Justification for assumptions - Underlying technologies overview - QUIC relevance: - How the scenario benefits from specific QUIC features - Which QUIC-based protocol from Clause 4.2 of TR 26.835 applies - Rationale for protocol selection - Note: If protocol not listed in 4.2, contributors should first add it there

References Clause 5.2.1.1 of TR 26.835 v0.0.1

2.3 Application Scenario Requirements

Specific technical requirements including: - Media formats - Bitrate allocation - Latency requirements - Startup delay - Other relevant parameters

References Clause 5.2.1.2 of TR 26.835 v0.0.1

2.4 Scenario Analysis

Testing and evaluation details: - Test conditions preparation - Proposed relevant metrics (cross-referenced to Clause 5.3 of TR 26.835 v0.0.1) - Evaluation considerations - Additional testing-related information

References Clause 5.2.1.3 of TR 26.835 v0.0.1

3. Integration Proposal

The document proposes incorporating Clause 4 (the template) as a new subclause in the FS_QStream_MED Work Plan, providing a standardized approach for all future application scenario contributions.

Document Purpose

This is a procedural contribution establishing a framework for future technical contributions rather than proposing specific technical solutions. It aims to ensure consistency and completeness when application scenarios are proposed for the QUIC-based streaming technologies study.

Summary of S4-260274: Application Scenarios for FS_QStream_MED

Introduction

This contribution addresses the FS_QStream_MED Rel-20 study item, which evaluates whether current and future media services could benefit from QUIC-based streaming technologies compared to TCP-based streaming (HTTP 1.1 and HTTP/2). The document proposes five application scenarios with their delivery characteristics to be considered in the study.

Proposed Application Scenarios

2.1 On-demand Long-form Streaming

Description: Traditional segmented on-demand streaming where UX is driven by TTFF, rebuffering avoidance, and steady-state quality. Serves as a baseline to evaluate whether HTTP/3 improves startup robustness, reduces rebuffering under loss, and stabilizes bitrate selection without changing application semantics or CDN caching.

Delivery Characteristics: - Latency target: Not live-edge constrained (focus on startup delay and seek response) - Segment/chunking: Typically 2–6s segments, usually no chunking - Session duration: Long (tens of minutes to hours) - Churn: Low (few items per session, seeking within session) - Cacheability: Very high (content reused across many viewers and time) - Traffic pattern: Downlink-dominant

2.2 Live Streaming at Scale

Description: One-to-many distribution with very high fanout where edge replication and caching efficiency are critical. Downlink includes synchronized consumption of common live timeline, significant join/rejoin activity, and sensitivity to end-to-end latency drift. Central for comparing DASH over HTTP/3 versus other QUIC-based options in terms of join time, live latency distribution, stability under congestion/loss, and operational scalability.

Delivery Characteristics: - Latency target: ~15–45+ seconds (service dependent) - Segment/chunking: Typically 6–10s segments, usually no chunking (or chunking not required) - Session duration: Long (tens of minutes to hours) - Churn: Low (infrequent zaps vs. short-form) - Cacheability: High (segments cache-friendly, many viewers request same objects) - Traffic pattern: Downlink-dominant (uplink mostly control/telemetry)

2.3 Low-latency Live Streaming

Description: Live services with tight latency budgets (e.g., interactive sports, live commerce, auctions) where tail latency and timeliness are as important as average latency. Uses very small chunks/parts and constrained playback buffers. Primary service risk is not only rebuffering but also late delivery causing latency drift or missed deadlines. Main stress test for QUIC-based approaches, highlighting where HTTP/3's transport properties may improve QoE and where alternatives like WebTransport or MoQ-style object delivery might reduce overhead and improve timeliness under loss and mobility.

Delivery Characteristics: - Latency target: ~2–8s (sometimes ~1–2s in aggressive "ultra-low" configurations) - Segment/chunking: Often ~1–2s segments plus CMAF chunks/partial segments of ~0.4–1.0s - Session duration: Medium to long (minutes to hours, event-driven) - Churn: Medium (more joins/leaves than linear, less than short-form) - Cacheability: Moderate to high (finer chunking increases request/object rate, may reduce cache hit efficiency) - Traffic pattern: Downlink-dominant (uplink mainly interaction/chat signals)

2.4 Short-form Video Platforms

Description: Characterized by extremely high churn with short sessions and frequent abandonment within seconds. Platform relies heavily on prefetch and fast startup. Downlink traffic is bursty with many small or partial transfers, frequent representation switches, and strong dependence on connection reuse and efficient request scheduling. Dominant QoE driver is TTFF rather than steady-state quality. Relevant to quantify QUIC's potential benefits in setup/handshake amortization, reduced head-of-line effects, improved performance under lossy access networks, and reduced per-request overhead.

Delivery Characteristics: - Latency target: Primarily instant start (TTFF is critical "latency" KPI) - Segment/chunking: Very small initial fetches (tiny first segment/chunk/GOP-aligned unit) followed by progressive fetch; segment durations ~1–2s with emphasis on early playable data - Session duration: Variable (often minutes, composed of many short items) - Churn: Very high (many joins/exits per minute) - Cacheability: Mixed (popular clips cache well, but personalization and huge catalog reduce cache hit ratios) - Traffic pattern: Downlink-dominant (plus uplink for telemetry, recommendation signals, occasional UGC upload)

2.5 Uplink Contribution for Live Services

Description: Couples challenging uplink contribution path with large-scale downlink distribution, reflecting modern "creator live" streaming services. Uplink is often mobile and highly variable with fluctuations in available bitrate, RTT, loss, and NAT rebinding. Downlink requires scalable fanout to heterogeneous receivers with frequent joins/rejoins and sensitivity to stalls and latency drift. End-to-end performance frequently dominated by recovery behavior when uplink path changes. Particularly relevant to assess QUIC features supporting robustness and continuity across path changes and to evaluate system-level KPIs such as recovery time after impairment, join/rejoin success rate, and end-to-end latency distributions under mobility.

Delivery Characteristics: - Latency target: Often sub-second to a few seconds contribution delay (compounds into end-to-end latency) - Segment/chunking: Can be chunked (frame/GOP/fragment level) or message/object oriented; if segmented ingest, segments tend to be small and/or chunked to reduce contribution delay - Session duration: Medium to long (minutes to hours) - Churn: Medium (streams start/stop; less rapid than short-form) - Cacheability: Low in uplink leg (ingest traffic unique per stream), though downstream distribution may be cacheable - Traffic pattern: Uplink-dominant on contribution leg (downlink for monitoring/return video is secondary)

Proposal

The contribution proposes to document all five application scenarios described in section 2 in the new TR for FS_QStream_MED.

Summary of S4-260276: Media over QUIC

1. Introduction and Context

This contribution addresses the FS_QStream_MED Rel-20 study (SP-251659), which evaluates whether current and future media services could benefit from QUIC-based streaming technologies compared to TCP-based technologies (HTTP 1.1 and HTTP/2). The document provides information on Media-over-QUIC (MoQ) as one of the emerging QUIC-based streaming technologies identified in TR 26.804.

2. Media over QUIC (MoQ) Overview

MoQ is an IETF working group effort standardizing a publish/subscribe media delivery system over QUIC and WebTransport-over-HTTP/3, designed for high-scale, low-latency delivery with explicit support for intermediaries (relays, caches, replication points).

2.1 Core MoQ Working Group Drafts

As of February 2, 2026, the MoQ WG has four core drafts:

• Media over QUIC Transport (MoQT): Main wire protocol defining publisher/subscriber operations over QUIC/WebTransport
• MOQT Streaming Format (MSF): Streaming format specifying media structure for MOQT delivery
• CMSF (CMAF-compliant MSF): Extension defining optional feature to carry CMAF-packaged media within MSF over MOQT
• Authentication scheme for MOQT using Common Access Tokens: Authentication scheme enabling client authentication to relays/servers

2.2 Media over QUIC Transport (MoQT) Technical Details

2.2.1 Protocol Foundation

MoQT builds upon: - QUIC or WebTransport as underlying transport - HTTP/3 as application-layer substrate - Publisher-subscriber communication model - Optional relay-based distribution mechanisms

2.2.2 Content Organization and Object Model

Content is organized hierarchically as Track → Group → Object:

• Track: Subscribable unit representing logical timeline for one stream of related content (e.g., video encoding, audio language, captions). Publishers advertise/publish Tracks; subscribers subscribe to Tracks.

• Group: Ordered collection of Objects within a Track, serving as join point. Subscribers can start at Group beginning and decode without prior Group information. Groups align with random-access boundaries (e.g., GOP/IDR boundaries for video).

• Object: Smallest named/addressable payload unit delivered. Contains bytes plus identifiers (Track + Group + Object IDs) and optional metadata. Objects are what relays forward and potentially cache, and the unit MoQT schedules over QUIC streams/datagrams.

2.2.3 Mapping MoQ Object Model to MPEG-DASH

The contribution provides detailed mapping between MoQ and DASH concepts:

• MoQ Track ↔ DASH Representation (one encoded bitstream at given quality)
• Set of related Tracks ↔ DASH AdaptationSet (multiple bitrates or alternate languages)
• MoQ Group boundary ↔ DASH segment boundaries (switching/random-access points aligned with RAP/IDR)
• MoQ Objects ↔ Within-segment granularity (CMAF movie fragments/moof-mdat pairs for latency and scheduling)

2.3 MoQ Streaming Format (MSF)

MSF is the standardized media packaging and signaling layer on top of MOQT, defining how to package and map streaming media onto MoQT's Track/Group/Object abstractions.

2.3.1 Key MSF Features

• Catalog concept: Published over MOQT, describes existing Tracks and relationships (render groups, packaging used)
• Timeline information: Defines how publishers convey timeline information and updates using MOQT Objects within Groups (independent event timeline in first Object of each Group, with optional incremental updates)
• Time-alignment requirements: Tracks in common render group must be time-aligned with corresponding Groups overlapping in presentation time after decoding
• ABR support: Provides format-level conventions for receivers to understand alternative encodings, time alignment, and safe switching for continuous playback

2.3.2 CMAF Integration

CMSF (CMAF-compliant MSF) extends MSF by defining optional feature specifying syntax and semantics for carrying CMAF-packaged media within MSF framework while retaining MSF's catalog/timeline/switching concepts.

3. Implementations and Deployments

3.1 Implementations/Players

• MoQtail: Libraries for publisher, subscriber, and relay components with media application demos using LOC and CMSF formats
• Shaka Player: Experimental support for MoQT draft-14 and MSF draft-1
• Meta's MoQ-Encoder-Player: Minimal in-browser live video/audio encoder and player based on MOQT draft
• Meta's moxygen: Experimental media MOQ relay for use with moq-encoder-player
• moq-dev: Rust and TypeScript MoQ libraries with similar APIs but language-specific optimizations

3.2 Deployments

• Cloudflare MoQ relay network: Technical preview running MoQ relay network across global edge footprint (every Cloudflare server across hundreds of cities) with public documentation
• WINK: Open-source MoQ implementation integrated with MediaMTX, production-tested for live/surveillance streaming with sub-second latency

4. Proposal

The contribution proposes to include the contents of section 2 in the new TR 26.835.

Summary of S4-260278: Performance and Metrics Evaluation for FS_QStream_MED

Document Overview

This change request proposes a framework for performance and metrics evaluation as part of the FS_QStream_MED study item, which is commencing at SA4 Meeting #135.

Background and Context

Existing 3GPP Metrics Infrastructure

• 3GPP has defined metrics collection mechanisms for 5G Media Streaming through:
• DASH metrics
• CMCD (Common Media Client Data) client data
• These metrics are currently being extended within the 3GPP framework

Current Implementation Status

• DASH Players: dash.js and Exo-Player have implemented these metrics
• 5G-MAG Reference Tools: Include CMCD and DASH metrics collection implementations
• Visualization: DASHboards and other tools exist for metrics analysis
• Data Correlation: Metrics can be logged and correlated with emulator information

Technical Proposal

Proposed Metrics Collection Framework

The document proposes leveraging the existing metrics collection infrastructure with the following approach:

1. Utilize Existing Metrics: Use established metrics collection mechanisms already defined for 5G Media Streaming
2. Event Framework Integration: Log data in an event framework that maintains compatibility with existing 5G Media Streaming specifications
3. Dual Purpose Approach:
4. Evaluate streaming session performance
5. Implement and validate the metrics themselves

Key Principles

• Consistency with 3GPP Standards: Rely on QoE metrics as defined in 3GPP specifications
• Standardized Reporting: Use existing reporting frameworks for information collection
• Meaningful Performance Data: Create data suitable for comprehensive performance evaluation

Benefits

• Avoids duplication of effort by reusing existing metrics infrastructure
• Ensures compatibility with established 5G Media Streaming frameworks
• Enables both performance evaluation and metrics validation in a unified approach