3GPP TR 26.836 V0.0.1 - Study on QUIC-based Media Delivery Solutions for Real-Time Communication (Release 20)

Document Overview

This is an initial skeleton document for a Technical Report studying the application of QUIC-based media delivery protocols to 3GPP Real-Time Communication (RTC) systems. The document is in its early draft stage (V0.0.1) and contains primarily editor's notes outlining the intended structure and scope of the study.

Main Technical Scope

The study aims to evaluate QUIC-based media delivery protocols for integration into the 3GPP RTC system, examining their applicability, benefits, limitations, and potential architectural impacts.

Technical Content Structure

1. QUIC-based Media Delivery Protocols (Clause 4)

Objective: Survey and document existing and emerging QUIC-based media delivery protocols.

Planned Content: - Individual protocol descriptions including: - Introduction and features - Benefits and limitations from RTC perspective - Current applications - Summary and comparison of surveyed protocols

Note: Comparison with existing RTC system will be addressed in the evaluation clause rather than here.

2. Evaluation of QUIC-based Protocols for RTC (Clause 5)

This clause forms the core technical contribution, structured into three main evaluation dimensions:

2.1 Application Scenarios (Clause 5.2)

• Definition of potential RTC service scenarios where QUIC-based media delivery could be applied
• Individual scenario descriptions to be provided in subsequent subclauses

2.2 Architectural and Functional Evaluation (Clause 5.3)

Scope of Analysis: - Impacts on RTC media delivery architecture (TS 26.506) - Impacts on 5G Core Network architecture (TS 23.501) - Impacts on UE implementations

Per-Protocol Analysis: - Applicability to defined application scenarios - Potential architectural enhancements required for integration - Advantages and disadvantages for each scenario - Summary of findings

2.3 Performance Evaluation (Clause 5.4)

Methodology: - Utilizes test framework from TR 26.934 ("Test platform for media delivery technologies")

Content: - Definition of appropriate performance metrics for QUIC-based protocols - Per-protocol evaluation including: - Evaluation conditions - Results obtained using TR 26.934 framework

2.4 Evaluation Summary (Clause 5.5)

• Overall assessment including:
• Advantages and disadvantages for RTC system
• Benefits for application scenarios
• Performance evaluation results

3. Integration into RTC System (Clause 6)

Conditional Scope: This clause will only be populated if QUIC-based protocols are found beneficial based on Clause 5 evaluation.

Planned Content: - Potential integration scenarios - Candidate solutions for integration - Summary of solutions including: - Evaluation/comparison of solutions - Potential normative work requirements

4. Conclusions and Recommendations (Clause 7)

Final conclusions and recommendations based on the study findings.

Key Dependencies and References

• TR 26.934: Test platform for media delivery technologies (used for performance evaluation framework)
• TS 26.506: RTC media delivery architecture (baseline for architectural evaluation)
• TS 23.501: 5G Core Network architecture (for network-level impact analysis)

Study Approach

The document follows a systematic evaluation methodology:

1. Survey Phase: Identify and characterize QUIC-based protocols
2. Scenario Definition: Define relevant RTC application scenarios
3. Multi-dimensional Evaluation: Assess protocols from architectural, functional, and performance perspectives
4. Integration Analysis: Develop potential integration solutions (if justified)
5. Recommendations: Provide conclusions and guidance for potential normative work

Current Status

This is a skeleton document (V0.0.1) from SA4#135 (February 2026) containing only structural placeholders and editor's notes. No technical content, evaluation results, or specific protocols have been documented yet. The structure indicates a comprehensive study approach covering protocol analysis, scenario-based evaluation, and potential standardization pathways.

Summary of S4-260101: pCR on QUIC-based media delivery protocols

Document Overview

This contribution addresses one of the key objectives of the FS_Q4RTC_MED study item (approved in SA#110) by identifying and documenting existing and emerging QUIC-based media delivery protocols suitable for real-time communication. The document provides a comprehensive technical analysis of three IETF-developed protocols: MOQT, RTP over QUIC (ROQ), and WebTransport.

Background on QUIC

The document establishes the foundation by describing QUIC as a user-space UDP-based transport protocol with: - Built-in TLS 1.3 encryption - Connection migration support - Stream multiplexing - Pluggable congestion control - Optional unreliable datagrams (RFC 9221)

Key motivations for using QUIC for media transport include: - Lower latency: 1-RTT handshake with optional 0-RTT resumption - Independent stream processing: Eliminates head-of-line blocking across streams - Selective reliability and prioritization: Mix of reliable streams and unreliable datagrams - Always-on security: Built-in TLS 1.3 - Better mobility: Connection migration without call drops

Media over QUIC Transport (MOQT)

Protocol Overview

• Binary data transport protocol under development by IETF MOQ WG since 2023
• Runs directly over QUIC or via WebTransport
• Companion specifications include Low Overhead Media Container (LOC) and MOQT Streaming Format (MSF)

Key Technical Features

Object-based Data Model

• Content organized as Objects within named Tracks
• Objects grouped into Groups and Subgroups
• Tracks referenced by numeric Track Alias
• Groups typically aligned with codec synchronization points (e.g., GOP boundaries)
• Group boundaries serve as random access points

Publish/Subscribe Architecture

• Publishers: Handle subscriptions and send requested Objects
• Subscribers: Subscribe to and receive tracks
• Relays: Cache and route content, acting as intermediaries for scalable distribution

Key control messages: - SUBSCRIBE: Requests newly published Objects - FETCH: Retrieves Objects from the past - SUBSCRIBE_NAMESPACE: Discovers publishers for a given namespace - PUBLISH and PUBLISH_NAMESPACE: Advertise available tracks

Data Transport Mechanisms

• Objects transmitted via QUIC streams (reliable, ordered) or DATAGRAM frames (unreliable, unordered)
• Forwarding Preference per Object specifies delivery method
• Subgroups enable grouping of mutually dependent Objects on single QUIC stream
• Stream types: SUBGROUP_HEADER, FETCH_HEADER, control stream with CLIENT_SETUP
• OBJECT_DATAGRAM message for datagram-based delivery

Relay Behavior

• Support both fan-in (multiple publishers) and fan-out (many subscribers)
• Function as policy enforcement points
• Can cache recent Objects for reduced load and quicker late joins
• Terminate QUIC sessions with visibility into Object metadata via Extension Headers
• Object payload treated as opaque (no modification allowed)

Benefits

• Leverages QUIC features (independent streams, prioritization, security, mobility)
• Convergence to single protocol simplifies workflows and infrastructure
• Scalable publish-subscribe architecture
• Potentially reduced session setup delay vs. WebRTC
• MOQT relays can integrate with 5G UPF for network optimizations (e.g., PDU Set information parsing per TS 23.501)

Limitations

• Still evolving (IETF draft not finalized)
• Limited production implementations and operational experience
• Initial deployment costs
• Additional testing needed for scalability validation

Current Applications

Multiple open-source implementations identified: - Google's production-ready implementation (quiche) - Meta's experimental relay and encoder/player - Ozyegin University's MOQT library (moqtail.dev) - Cloudflare's implementation and relay network deployment - Commercial integrations: Bitmovin web player, Vindral live streaming, Red5 (upcoming support)

RTP over QUIC (ROQ)

Protocol Overview

• Under development by IETF AVTCORE WG since 2022
• Minimal mapping for encapsulating RTP and RTCP packets within QUIC
• Uses flow identifiers for multiplexing multiple RTP/RTCP streams

Key Technical Features

Packet Mapping Options

Three approaches specified: 1. One RTP packet per QUIC stream (not recommended due to excessive overhead) 2. Multiple RTP packets per stream with in-stream framing (length-prefixed) 3. QUIC datagrams: One RTP/RTCP packet per DATAGRAM frame (only flow ID needed)

Selection depends on application needs and HoL blocking tolerance: - Datagrams: Unordered, unreliable delivery, no HoL blocking - Streams: Reliable, ordered delivery with explicit prioritization

RTCP Optimization

• Aims to minimize RTCP traffic by utilizing QUIC data
• QUIC acknowledgments can compute lost packet statistics

Signaling

• SDP Offer/Answer can be used for connection setup and media negotiation

Benefits

• Reuses established RTP payload formats, media semantics, timing, and A/V lip-sync
• Built-in authentication and encryption via QUIC/TLS 1.3 (no separate DTLS-SRTP)

Limitations

• Flow identifier overhead: 1-8 bytes per packet (typically 1 byte for ≤63 flows)
• Coordination needed between application-layer rate control (GCC, SCReAM) and QUIC transport-level congestion control
• No defined API for communication between rate control layers
• Not suitable for point-to-multipoint topologies (QUIC multicast not yet standardized)
• Limited ecosystem and industry adoption

Current Applications

Open-source implementations exist: - TUM Go implementation - BBC Gstreamer plugin - Meetecho C library (imquic) supporting both ROQ and MOQT

No commercial deployments identified; further exploration FFS.

WebTransport

Protocol Overview

• Modern web API and protocol framework for secure, low-latency bidirectional communication
• IETF defines protocol framework with HTTP/2 and HTTP/3 mappings
• W3C specifies web API for browser-server data exchange
• Designed for Web security model (origin verification, TLS)

Key Technical Features

Transport Capabilities

• Utilizes QUIC for unidirectional and bidirectional streams (reliable, ordered)
• Supports unreliable delivery via QUIC datagrams
• API exposes readable/writable streams and datagrams

Session Establishment

• Over HTTP/3: Uses HTTP/3 CONNECT with :protocol=webtransport
• All data flows over QUIC streams/datagrams after session setup

Congestion Control

• API preference hints: "throughput" or "low-latency"
• Actual algorithms determined by user agent (not directly configurable)

Benefits

• Leverages QUIC benefits within standard web security model with browser support
• Simpler deployment vs. WebRTC DataChannels (no ICE/STUN/TURN)
• Minimal overhead: One-time HTTP/3 CONNECT for setup, typically 1-byte session ID per stream

Limitations

• Evolving browser support (no Safari support as of early 2026)
• Requires application-layer protocol for media delivery (custom format or MOQT)
• Exposes only high-level subset of QUIC features (intentional security model constraint)
• No full control over QUIC configuration

Current Applications

• MOQT can be layered on top of WebTransport
• Multiple open-source implementations: Google QUICHE, Rust WebTransport library

References Added

The document adds 18 new normative/informative references covering: - IETF drafts for MOQT, ROQ, WebTransport, LOC, MSF, SDP for ROQ - IETF RFCs for QUIC, RTP, SDP, HTTP/2, HTTP/3, QUIC datagrams - W3C WebTransport specification - Congestion control algorithms (GCC, SCReAM) - 3GPP TS 23.501 for 5G system architecture

Summary of S4-260102: Introduction to TR 26.836 on QUIC-based Media Delivery

Document Overview

This contribution provides the foundational introduction for TR 26.836, which addresses the study item FS_Q4RTC_MED approved in SA#110. The objective is to identify and document existing and emerging QUIC-based media delivery protocols suitable for real-time communication.

Main Technical Contributions

1. QUIC Protocol Foundation

The document establishes the baseline understanding of QUIC by referencing the core IETF specifications:

• RFC 9000: Core QUIC transport mechanisms (UDP-based, multiplexed, secure)
• RFC 9001: TLS 1.3 integration for security
• RFC 9002: Loss detection and congestion control
• RFC 8999: Version-independent properties

Additional extensions and operational specifications are referenced: - RFC 9114: HTTP/3 - RFC 9221: Unreliable datagram extension - RFC 9309: Applicability guidance - RFC 9312: Manageability aspects

2. Key Motivations for QUIC in Media Transport

The contribution identifies several technical advantages of QUIC for media delivery:

Lower Latency and Faster Start-up

• 1-RTT handshake with optional 0-RTT resumption reduces join time
• User-space pacing algorithms minimize burstiness and reduce jitter

Independent Stream Processing and Prioritization

• Eliminates head-of-line (HoL) blocking across different streams
• Prevents one stalled media flow from blocking others (e.g., video frame not blocking audio)
• Stream prioritization enables resource allocation based on application-signaled importance

Selective Reliability

• Datagrams (RFC 9221): Best-effort delivery for latency-critical applications requiring unordered, unreliable packet delivery
• Streams: Reliable, ordered delivery with explicit prioritization
• Applications can mix both approaches based on data criticality and delay sensitivity

Always-on Security

• Built-in TLS 1.3 encryption and authentication eliminates need for separate DTLS layer
• Connection IDs (CIDs) and encrypted headers improve privacy
• Resilience to middlebox ossification

Better Mobility and Robustness

• Connection migration enables seamless IP/port changes (e.g., Wi-Fi to cellular transitions)
• Avoids call drops and renegotiations that disrupt audio/video continuity

3. IETF QUIC-based Application Protocols

The document identifies three QUIC-based application protocols under IETF standardization for real-time and interactive communication:

• MOQT (Media over QUIC Transport): draft-ietf-moq-transport-16
• ROQ (RTP over QUIC): draft-ietf-avtcore-rtp-over-quic-14
• WebTransport: draft-ietf-webtrans-overview-11

4. Normative References

The contribution adds comprehensive normative references covering: - Core QUIC specifications (RFCs 8999, 9000, 9001, 9002) - QUIC extensions (RFCs 9114, 9221) - QUIC operational guidance (RFCs 9309, 9312) - Security foundation (RFC 8446 - TLS 1.3) - IETF work-in-progress drafts for MOQT, ROQ, and WebTransport

Document Structure

The changes propose additions to: - Clause 1 (Introduction): Complete technical introduction to QUIC and its benefits for media transport - Clause 2 (References): Addition of 12 new normative references ([y1] through [y12])

Summary of S4-260103: Considerations on Application Scenarios for FS_Q4RTC_MED

1. Introduction and Context

This contribution from Nokia (as rapporteur) addresses the definition of application scenarios for the study on QUIC-based media delivery protocols in the context of the RTC System (FS_Q4RTC_MED). The scenarios will serve as the basis for evaluating QUIC-based media delivery protocols against existing WebRTC and (S)RTP-based frameworks as defined in TS 26.506 and TS 26.113.

2. Evaluation Plan Framework

The document references Objective 2 of the SID, which establishes three main evaluation components:

a) Evaluation Framework Definition

• Define application scenarios for QUIC-based media delivery protocol evaluation
• Include existing 3GPP services or service enablers (e.g., split rendering)

b) Performance Evaluation

• Define appropriate performance metrics and requirements for identified scenarios
• Evaluate QUIC-based protocols against existing architectures under realistic 3GPP network conditions
• Consider existing performance evaluations from academia and other SDOs
• SA4 may analytically verify results without conducting new simulations

c) Deployment Impact Assessment

• Document potential impact on delivery architecture (TS 26.506)
• Consider current architectures, 3GPP core network (TS 23.501), and UE implementations
• Identify advantages and disadvantages regarding efficiency, scalability, distributed deployment, radio optimizations, flow control, security/privacy vs. traffic management, and implementation readiness

Notes: - Evaluation framework may be based on open-source network simulators (e.g., ns3) - Scenarios involve real-time audio/video communication using EVS, IVAS, H.264/AVC, and H.265/HEVC codecs

3. Key Aspects for Application Scenario Definition

The document identifies critical aspects that must be considered when defining application scenarios:

Relevance to 3GPP Ecosystem

• Scenarios must reflect actual or anticipated 3GPP services and use cases
• Should describe how QUIC-based media delivery protocols (identified in TR 26.836 clause 4) will be applied
• Should detail how specific QUIC features (e.g., stream prioritization) may be leveraged
• Should identify relevant media streams and control signaling (uplink/downlink) and their mapping to QUIC and QUIC-based protocols

Performance Characteristics

• Latency: Define target latencies for considered media types and interactions
• Jitter tolerance: Define acceptable jitter ranges for packet arrival time variability
• Packet loss resilience: Document acceptable packet loss levels balancing reliability vs. latency
• Throughput and bitrate adaptability: Specify necessary bitrates and adaptive streaming requirements
• Security and privacy: Consider implications of QUIC's built-in encryption

Evaluation Approach

The document acknowledges that not all scenarios will undergo network simulation using TR 26.934 test framework due to time and resource limitations. When simulation is not possible, analytical assessment of architectural and deployment impact should still be conducted.

4. Proposed Scenario Template

A standardized template is proposed for scenario definition with the following structure:

1. Scenario Name

Descriptive name (e.g., "Interactive XR Split Rendering")

2. Description

Brief narrative explaining use cases, user interaction, and overall goal (example provided: XR headset user in collaborative design review with cloud rendering and 5G handovers)

3. Relevance to 3GPP Ecosystem

Explanation of relationship to actual or anticipated 3GPP services and service enablers

4. Application of QUIC

• Description of how QUIC-based media delivery protocols (from TR 26.836 clause 4) apply to the scenario
• Details on leveraging specific QUIC features (reliable/unreliable streams, stream prioritization, connection migration)
• Discussion of security and privacy aspects impacted by QUIC usage

5. Media Stream and Control Signaling Characteristics

• Media type
• Bitrate requirements
• Latency/jitter sensitivity
• Loss tolerance
• Communication pattern (e.g., point-to-point, multi-party)
• Directionality (e.g., unidirectional media streams, bidirectional control streams)

5. Proposals

The document proposes two actions:

1. Consider the aspects outlined in clause 3 when proposing new application scenarios
2. Provide scenario definitions based on the template given in clause 4

Technical Contributions Summary

This contribution establishes a structured methodology for defining and evaluating application scenarios in the QUIC-based RTC media delivery study. The main technical contributions are:

• Comprehensive evaluation criteria covering latency, jitter, packet loss, throughput, and security considerations specific to RTC applications
• Standardized scenario template ensuring consistent and complete scenario descriptions across contributions
• Clear mapping requirements between application needs and QUIC protocol features
• Flexible evaluation approach allowing both simulation-based and analytical assessments
• Focus on 3GPP ecosystem relevance ensuring scenarios address actual or anticipated service requirements

Considerations on Test Framework Design for QUIC-Related Study Items

1. Introduction

This contribution addresses the coordination of test framework development for two QUIC-related study items: FS_Q4RTC_MED (QUIC for Real-Time Communications) and FS_QStream_MED (QUIC for Streaming). The document proposes a coordinated approach to avoid duplication of effort.

2. Evaluation Plan for FS_Q4RTC_MED

The evaluation framework for QUIC-based RTC is defined in objectives 2a and 2b of the SID:

Objective 2a - Evaluation Framework Definition

• Define evaluation framework for QUIC-based media delivery protocols in the context of RTC System (TS 26.506 and TS 26.113)
• Define application scenarios for evaluation, including existing 3GPP services and service enablers such as split rendering

Objective 2b - Performance Evaluation

• Define appropriate performance metrics and requirements for identified application scenarios
• Evaluate QUIC-based protocols against existing architectures (WebRTC and (S)RTP-based frameworks) under realistic 3GPP network conditions
• Consider existing performance evaluations from academia and other SDOs, with independent SA4 verification (analytical verification without necessarily conducting new simulations)

Objective 2c - Deployment Impact Assessment

Document potential deployment impacts on TS 26.506 delivery architecture, considering: - Current architectures - 3GPP core network architecture (TS 23.501) - UE implementations - Advantages/disadvantages including: efficiency, scalability, distributed deployment capability, impact on radio optimizations, flow control and management, security/privacy vs. traffic management, and implementation readiness

Notes: - Evaluation framework may be based on open-source network simulator (e.g., ns3) - Evaluation scenarios involve real-time audio and video communication using EVS/IVAS codecs for audio and H.264/AVC, H.265/HEVC for video (per TS 26.114)

3. Evaluation Plan for FS_QStream_MED

The evaluation framework for QUIC-based streaming is defined in objectives 1-4, with 3b and 3c being most relevant:

Objective 1 - Application Scenarios

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

Objective 2 - Technology Identification

Identify existing and emerging segmented media streaming technologies, particularly 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 Definition

Objective 3a - Metrics Definition

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

Objective 3b - Deployment Impact Assessment

Document potential impact of deploying QUIC-based streaming technologies on: - Media delivery architecture (TS 26.501) - Delivery protocols (TS 26.512) - Codecs and formats (TS 26.511)

Consider: current CDN architectures, 3GPP core network architecture (TS 23.501), UE implementation, encrypted content. Identify advantages/disadvantages including caching efficiency, scalability, distributed deployment capability, and implementation readiness.

Objective 3c - Test Framework Design

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

Objective 4 - Technology Evaluation

Evaluate selected technologies by collecting QoE metrics using the framework from objective #3 for use cases from objective #1, under 3GPP network conditions using mobile network traces. Develop network simulation setup and select network traces for relevant application scenarios.

4. Potential for Coordination

Joint coordination on certain topics could streamline test framework development and ensure effective evaluation:

QUIC Protocol Aspects

• Considerations on applicability of different QUIC features
• Choice of QUIC stack for the test framework

Common Protocols

• MOQT is expected to be the only protocol applicable to both streaming and RTC scenarios
• Joint discussions on MOQT protocol features and related IETF MOQ WG specifications would be beneficial

Evaluation Methodology

• Whether evaluation is conducted via network simulation or emulation
• In case of network simulation: model-based vs. real network traces

5. Proposals

The following agreements are proposed:

1. Joint Initial Sessions: In the initial phases of both studies, address test framework-related contributions together during joint sessions. This will help clarify coordination opportunities until specific methodologies for each study are established.

2. Contribution Labeling: Proponents of relevant contributions should indicate when their contributions target the test framework to facilitate session scheduling.

3. Common Base Framework: Strive to create a common base framework on which both frameworks can build and branch out, reducing redundant implementation work.

4. Separate Application Scenario Evaluation: Contributions targeting evaluation of specific RTC or streaming-related application scenarios can be handled separately at the respective SWGs.

Draft Work Plan for FS_Q4RTC_MED

Introduction

This document presents a draft work plan for the Rel-20 Study on QUIC-based media delivery for real-time communication (FS_Q4RTC_MED), which was agreed at SA4#134 and approved at SA#110 [SP-251661].

Study Objectives

The study encompasses the following key objectives:

Objective 1: Protocol Identification and Documentation

Identify existing and emerging QUIC-based media delivery protocols suitable for real-time communication and document their features, benefits, limitations and current applications.

Objective 2: Evaluation Framework Definition

Define an evaluation framework for QUIC-based media delivery protocols in the context of the RTC System as defined in TS 26.506 and TS 26.113, including:

• Application scenarios: Define scenarios for evaluation, particularly including existing 3GPP services or service enablers such as split rendering
• Performance evaluation: Define appropriate performance metrics and requirements, and evaluate the performance of QUIC-based media delivery protocols against existing architectures and protocols (WebRTC and (S)RTP-based frameworks) under realistic 3GPP network conditions
• Existing evaluation consideration: Consider existing performance evaluation from academia and other SDOs, which SA4 may verify analytically without conducting new simulations

NOTE 1: The evaluation framework may be based on an open-source network simulator such as ns3.

NOTE 2: Evaluation scenarios may involve real-time communication of audio (EVS and IVAS) and video (H.264/AVC and H.265/HEVC) as specified in TS 26.114.

Objective 3: Deployment Impact Assessment

Document potential impact of deploying QUIC-based technologies on the delivery architecture defined in TS 26.506, considering: - Current architectures - 3GPP core network architecture (TS 23.501) - UE implementations - Advantages and disadvantages including efficiency, scalability, distributed deployment capability, impact on radio optimizations, flow control and management, security/privacy versus traffic management, and readiness of general-purpose implementations

Objective 4: Integration Study (Conditional)

If sufficient evidence of benefits for selected QUIC-based media delivery protocols in the RTC context are identified:

• Integration with MRI solutions: Study integration of beneficial QUIC-based media delivery protocols with SA2 MRI solutions (TS 23.501, clause 5.37.9) into the RTC System, including consideration of potential architectural enhancements, signaling and collaboration scenarios
• Gap identification: Identify gaps and potential normative work on architecture and procedures (TS 26.506) as well as protocols and APIs (TS 26.113 and TS 26.510)

NOTE 4: The study will take into account potential changes in the media delivery architecture as identified in other ongoing 3GPP studies.

Objective 5: Coordination

Coordinate work with other 3GPP groups and the IETF as needed.

Proposed Work Plan Timeline

SA4#134 (17–21 November 2025, Dallas, US)

• Agree study item description
• Discuss potential work plan

SA#110 (9–12 December 2025, Baltimore, US)

• Approve new study item

SA4#134 RTC SWG call (Dec 17, 2025, 14:00-16:00 CET, Host Nokia)

• Discuss work plan

SA4#134 RTC SWG call (Jan 28, 2026, 15:00-17:00 CET, Host Nokia)

• Discuss specification skeleton for TR 26.8xx
• Initiate work on: Identification of QUIC-based media delivery protocols suitable for RTC and documentation of their features, benefits, limitations and current applications

SA4#135 (9–13 February 2026, Goa, India)

• Agree work plan
• Agree specification skeleton for TR 26.836
• Progress work on: Identification of QUIC-based media delivery protocols
• Initiate work on:
• Definition of application scenarios for evaluation
• Definition of performance metrics and requirements
• Performance evaluation of QUIC-based media delivery protocols
• Documentation of existing evaluation from academia and other SDOs
• Document potential impact of deploying QUIC-based technologies
• Communicate with other 3GPP WG and external organizations if necessary

NOTE: Coordinate with FS_QStream_MED on the evaluation framework.

Post SA4#135 RTC SWG calls (date/time TBD, Host Nokia)

• TBD

SA4#135-bis-e (13–17 April 2026, online)

• Complete work on: Identification of QUIC-based media delivery protocols
• Progress work on:
• Definition of application scenarios
• Definition of performance metrics and requirements
• Performance evaluation
• Documentation of existing evaluation
• Document potential impact of deploying QUIC-based technologies
• Initiate identification of potential stage-2 normative work for 5GA
• Communicate with other 3GPP WG and external organizations if necessary

Post SA4#135-bis-e AHG calls (date/time TBD, Host Nokia)

• TBD

SA4#136 (11–15 May 2026, Montreal, Canada)

• Progress work on:
• Definition of application scenarios
• Definition of performance metrics and requirements
• Documentation of existing evaluation
• Performance evaluation
• Document potential impact of deploying QUIC-based technologies
• Complete identification of potential stage-2 normative work for 5GA
• Communicate with other 3GPP WG and external organizations if necessary

NOTE: Stage-2 normative work item for 5GA may be proposed here.

Post SA4#136 AHG calls (date/time TBD, Host Nokia)

• TBD

SA4#137-e (24–28 August 2026, online)

• Complete work on:
• Definition of application scenarios
• Definition of performance metrics and requirements
• Documentation of existing evaluation
• Progress work on:
• Performance evaluation
• Document potential impact of deploying QUIC-based technologies
• Initiate identification of potential stage-3 normative work for 5GA
• Communicate with other 3GPP WG and external organizations if necessary

Post SA4#137-e AHG calls (date/time TBD, Host Nokia)

• TBD

SA4#138 (16–20 November 2026, Calgary, Canada)

• Progress work on:
• Performance evaluation
• Document potential impact of deploying QUIC-based technologies
• Complete identification of potential stage-3 normative work for 5GA
• Communicate with other 3GPP WG and external organizations if necessary
• Send TR 26.836 v1.0.0 for information to SA

NOTE: Stage-3 normative work item for 5GA may be proposed here.

SA#114 (8–11 December 2026, US)

• Presentation of TR 26.836 v1.0.0 to SA for information

SA4#139 (22–26 February 2027, South Korea)

• Complete work on:
• Performance evaluation
• Document potential impact of deploying QUIC-based technologies
• Finalize TR conclusions and recommendations for future work
• Send TR 26.836 v2.0.0 for approval to SA

SA#115 (16–19 March 2027, Europe)

• Approval of TR 26.836 v2.0.0 in SA

Summary of S4-260242: RTP over QUIC Media Delivery Protocol for Real-time Communication

Document Overview

This contribution to TR 26.836 v0.0.1 documents RTP over QUIC (RoQ) as a media delivery protocol for real-time communication services. The document is submitted by InterDigital to the Study on QUIC-based media delivery for real-time communication and services.

Main Technical Contributions

References Added

The contribution adds two key normative references: - IETF RFC 9221: "An Unreliable Datagram Extension to QUIC" - IETF Draft draft-ietf-avtcore-rtp-over-quic-14: "RTP over QUIC (RoQ)" (Work in progress)

Introduction to RTP over QUIC (Section 4.2.X.1)

The contribution introduces RoQ as a framework for transporting RTP and RTCP data over QUIC protocol, providing: - A minimal and flexible mapping allowing existing RTP-based applications to operate over QUIC instead of UDP - Leveraging QUIC's built-in features: mandatory encryption, connection migration, multiplexing, and standardized congestion control - Support for both QUIC streams and QUIC datagrams for encapsulation - Transport-level feedback that can complement or replace traditional RTCP features

Features (Section 4.2.X.2)

Security and Encapsulation (4.2.X.2.1)

• Built-in encryption: TLS 1.3 integrated, eliminating need for separate DTLS layer
• Dual encapsulation models:
• QUIC STREAM frames: Reliable, ordered, flow-controlled delivery with potential head-of-line blocking
• QUIC DATAGRAM frames: Unreliable, out-of-order delivery similar to traditional RTP, avoiding head-of-line blocking
• Flexibility: Single QUIC connection can carry both encapsulation types simultaneously
• HoL blocking mitigation: RoQ senders can open new QUIC streams for different RTP packets using the same flow identifier

Multiplexing (4.2.X.2.2)

• Multiple media streams, control streams, and application flows over one QUIC connection
• Application-level flow identifiers for demultiplexing (replacing separate UDP port numbers)
• Simplified NAT/firewall traversal and reduced port usage

RTP Packet Handling (4.2.X.2.3)

• RTP packets carried as QUIC payload in STREAM or DATAGRAM frames
• DATAGRAM considerations: No internal fragmentation; must respect max_datagram_frame_size and Path MTU
• STREAM capabilities: Packet queuing, segmentation, and cancellation mechanisms using STOP_SENDING and RESET_STREAM frames

RTCP Packet Handling (4.2.X.2.4)

• RTCP packets carried via QUIC streams or DATAGRAMs
• Mixed operation possible based on application requirements
• QUIC-to-RTCP mapping:
• QUIC loss/acknowledgment patterns can substitute for RTCP NACKs
• QUIC ECN support can replace RTCP ECN feedback reports
• CONNECTION_CLOSE frame with Reason Phrase can replace RTCP BYE

Benefits (Section 4.2.X.3)

1. Integrated security: Built-in TLS 1.3 encryption without separate DTLS layer
2. Simplified connectivity: Multiplexing over single connection improves NAT/firewall traversal
3. Standardized congestion control: Direct use or adaptation of QUIC mechanisms
4. Reduced RTCP overhead: Leveraging QUIC's internal metrics (RTT, loss, delivery rates)
5. Enhanced mobility: Connection migration support and better NAT traversal for mobile/multi-network clients

Limitations (Section 4.2.X.4)

1. Implementation complexity: More complex than UDP, requiring handling of QUIC connection setup, TLS, and frame semantics
2. Head-of-line blocking risk: When using reliable QUIC STREAMs, requires careful design with DATAGRAMs or stream segmentation
3. Congestion control coordination: Need to avoid conflicts between RTP and QUIC congestion control algorithms
4. Deployment maturity: Limited support in existing media servers, middleboxes, and network devices compared to UDP/DTLS RTP

Current Applications (Section 4.2.X.5)

The contribution lists three open-source implementations: 1. RTP over QUIC implementation in Go (github.com/mengelbart/roq) 2. RTP-over-QUIC elements for GStreamer (github.com/bbc/gst-roq) 3. Meetecho's open source QUIC library for multimedia applications supporting RoQ and MoQ (github.com/meetecho/imquic)

Document Type

This is a text proposal contribution adding a new subsection to the technical report, documenting RoQ protocol characteristics for consideration in the QUIC-based media delivery study.

Summary of S4-260246: Media over QUIC for Real-Time Communication

Document Overview

This contribution proposes additions to 3GPP TR 26.836 v0.0.1 (Study on QUIC-based media delivery for real-time communication and services) focusing on the Media over QUIC (MoQ) transport protocol. The document provides a comprehensive technical description of MoQ, its features, benefits, and limitations for real-time communication services.

Main Technical Contributions

Reference Updates

The CR adds three new normative references to IETF drafts: - draft-ietf-moq-transport-16: "Media over QUIC Transport" - defines the core MOQT protocol - draft-ietf-moq-msf-00: "MOQT Streaming Format" - specifies streaming format mappings - draft-ietf-moq-loc-01: "Low Overhead Media Container" - defines container format with minimal overhead

Protocol Introduction and Architecture

Core Protocol Description: - MOQT is defined as a family of protocols for transporting real-time media (audio, video, synchronized data) over QUIC - Uses publisher/subscriber communication model - Supports optional relay-based distribution mechanisms - Can operate over native QUIC or WebTransport over QUIC - Designed for low-latency media delivery and scalable real-time communication

Protocol Stack: - Includes illustration of MOQT protocol stack showing layered architecture

Streaming Formats: - MSF (MOQT Streaming Format): Segment-based format for interoperable low-latency streaming (previously known as WARP) - LOC (Low Overhead Media Container): Aligned with WebCodecs for minimal overhead

Core Features

Transport Layer Features: - Publish/Subscribe Model: Producers publish media data; consumers (clients/relays) subscribe to specific "Tracks" - QUIC Integration: Leverages QUIC streams for reliable, ordered delivery (avoiding head-of-line blocking) and datagrams for loss-tolerant scenarios

MSF Format Features: - Hierarchical Data Model: - Tracks: Sequence of groups - Groups: Temporal sequences acting as independent join points - Objects: Basic addressable units - Subgroups: Manage decoding dependencies on single stream

• Catalogs: Specialized track containing metadata about available tracks, codecs, and initialization data; enables content discovery and selection via Common Catalog Format

• Prioritization and Fetching:

• Fine-grained control over object transmission
• Subscriber and publisher priorities for resource contention management
• Support for reliable bidirectional/unidirectional streams and unreliable datagrams

• Object prioritization and cancellation of obsolete objects (e.g., late video frames)

• Scalability with MoQ Relays:

• CDN-like functionality
• Cache, deduplicate, and route content based on track names
• Media payload remains opaque and potentially encrypted

Benefits for Real-Time Communication

Low Latency and Congestion Control: - Minimal latency delivery leveraging QUIC's rapid congestion detection and response - Reduced connection establishment latency (0-RTT / 1-RTT) - No head-of-line blocking across independent streams - Ability to discard outdated media objects

Scalability: - Massive scaling through relays - Relays aggregate multiple subscriptions for same content into single upstream request - Reduces load on original publisher

Convergence: - Single transport protocol for both media contribution and distribution - Reduces need for protocol conversion or media repackaging at intermediate nodes

Web Compatibility: - Native browser support via WebTransport without custom plugins - Facilitates convergence between real-time media communication and web-based service platforms

Delivery Flexibility: - Choice between reliable stream-based or unreliable datagram-based delivery within same session - Selection based on content nature and latency requirements

QoS Configuration: - Different QoS configurations possible - Example: QUIC stream priorities for I-frames versus B-frames

Built-in Security: - Mandatory encryption based on TLS 1.3 - No support for unsecured modes - Simplified security model compared to RTP/SRTP-based solutions

Limitations

Out-of-Band Discovery: - Initial discovery of servers and specific Track Namespaces handled outside protocol - Mechanisms exist for track discovery once session is established

Congestion Control Complexity: - Latency performance depends on congestion control algorithm used - Certain congestion control behaviors may introduce latency under specific network conditions - Requires careful selection or tuning for real-time services

Current Applications and Implementations

MOQtail: - Implementation in Rust and TypeScript - Provides libraries for publisher, subscriber, and relay components - Features media application demos using LOC and CMSF formats - GitHub: https://github.com/moqtail/moqtail

moq-encoder-player: - Facebook Experimental implementation - GitHub: https://github.com/facebookexperimental/moq-encoder-player

Cloudflare MoQ Service: - Cloudflare's implementation of MoQ protocol - Deployed MoQ Relay Network (MRN) on Cloudflare infrastructure - Provides large-scale media streaming using MoQ - Reference: https://blog.cloudflare.com/moq/

Summary of 3GPP Change Request S4-260257

Document Information

• Source: InterDigital Pennsylvania
• Title: WebTransport protocol for real-time communication
• Specification: 3GPP TR 26.836 v0.0.1
• Study: FS_Q4RTC_MED (Study on QUIC-based media delivery for real-time communication and services)

Purpose

This CR documents the WebTransport media delivery protocol, including its features, benefits, and limitations for use in real-time communication services within the ongoing study on QUIC-based media delivery protocols.

Technical Contributions

Reference Updates

The CR adds six new normative/informative references related to WebTransport: - IETF draft-ietf-webtrans-overview (WebTransport Protocol Framework) - IETF draft-ietf-webtrans-http3 (WebTransport over HTTP/3) - IETF draft-ietf-webtrans-http2 (WebTransport over HTTP/2) - WebTransport API (MDN documentation) - W3C Working Draft for WebTransport - IETF WebTransport Working Group Charter

New Technical Clause: WebTransport (4.2.X)

Introduction (4.2.X.1)

• WebTransport is a framework enabling web clients (browsers) to communicate with servers over secure, multiplexed transport
• Positioned between WebSocket (limited to single ordered reliable TCP stream) and WebRTC DataChannel (P2P-oriented)
• Runs over HTTP/3 at high level
• Dual nature: both transport protocol (IETF) and Web API (W3C)
• Protocol stack includes HTTP3Transport mapping layer for feature negotiation, Extended CONNECT initiation, and datagram/stream mapping
• W3C API published as working draft; IETF standardization expected in 2026

Features (4.2.X.2)

• Session-based communication model under Web security model
• Supports multiple independent bidirectional and unidirectional streams
• Supports datagrams (unreliable, message-oriented delivery)
• All traffic multiplexed within same connection over HTTP/3
• Safely exposed to browser applications
• Dual specification: protocol level (IETF) and API level (W3C)
• HTTP/2 mapping available for environments without UDP/QUIC support

Benefits (4.2.X.3)

• Application-level abstraction: Web-compatible framework and API beyond raw QUIC transport
• Mixed traffic support: Combines reliable and low-latency traffic in single logical connection
• Web security integration: Origin-based access control, secure contexts, safe for untrusted applications
• HTTP integration: Mappings over HTTP/3 and HTTP/2 enable operation where UDP/QUIC unavailable
• Modern browser API: W3C API provides high-level JavaScript interface aligned with Web Streams paradigm
• Alternative to WebSockets: Native multiplexing and unreliable datagram support

Limitations (4.2.X.4)

• Client-server only: Primarily for client-server interactions; no standardized NAT traversal like WebRTC
• Security constraints: Limited to secure contexts (HTTPS); intentionally restricted low-level transport control
• Maturity concerns: W3C API still Working Draft; variable browser support
• HTTP/2 mapping differences: HTTP/2 fallback provides "many capabilities" but not identical transport properties to HTTP/3 version

Current Applications (4.2.X.5)

• Client implementations: Google Chrome and Microsoft Edge browsers support W3C WebTransport API over QUIC
• Server implementations:
• quiche (Rust): https://github.com/cloudflare/quiche
• aioquic (Python): https://github.com/aiortc/aioquic (experimental support)

Overall Assessment

This CR provides comprehensive documentation of WebTransport as a candidate protocol for QUIC-based real-time communication services, covering its technical characteristics, advantages for web-based RTC applications, deployment constraints, and current implementation status.

Summary of S4-260258: Application Scenario for Real-time Peer to Application to Peer Communication

Document Overview

This contribution to TR 26.836 (Study on QUIC-based media delivery for real-time communication and services) proposes the addition of a Peer to Application to Peer (P2A2P) application scenario for evaluating QUIC-based media delivery protocols in real-time communication services. The document references existing 3GPP specifications (TS 23.228 and TS 26.114) as the basis for this scenario.

Main Technical Contributions

1. Reference Updates

The CR adds three new normative references to support the P2A2P scenario:

• TS 26.506: 5G Real-time Media Communication Architecture (Stage 2)
• TR 26.113: Real-Time Media Communication; Protocols and APIs
• TR 22.870: Study on 6G Use Cases and Service Requirements

2. P2A2P Application Scenario Definition (New Clause 5.2.1.1)

2.1 Core Architecture Description

The scenario describes an RTC session where:

• User A establishes a session to an Application Server (AS) rather than directly to User B
• A SWAP server (defined in TS 26.113) terminates the SDP offer from User A and initiates a second SDP offer towards User B
• The AS terminates media from User A and forwards it to User B, acting as an intermediary
• Leverages the GA4RTAR service architecture (TS 26.506) where the AF triggers appropriate AS based on service logic

2.2 Media Handling Characteristics

The AS is characterized as a media-aware entity that actively processes real-time media streams:

• Decodes, analyzes, modifies, or regenerates media before forwarding
• Supports value-added services: call screening, IVR, real-time translation, media mixing, conferencing
• Must maintain conversational latency bounds per TS 26.113
• Ensures synchronization between media components (e.g., voice and RTT)
• Provides graceful adaptation to packet loss or bandwidth variation

3. Real-Time Communication for Conversational XR Services Use Case (New Clause 5.2.1.1.2)

3.1 General XR Communication Framework

Describes RTC augmented by shared XR scenes with:

• User representation via 2D/3D avatars or holograms
• Multi-modal immersive experience through multiple XR devices (glasses/headset, immersive audio, haptics)
• Main XR Scene Manager located in Media Function (MF) of AS, responsible for maintaining synchronized XR scene for all participants
• Interactive virtual objects within the XR scene

3.2 Deployment Configurations

Three participant configurations are defined:

1. Full VR: All participants remote, represented by avatars in common virtual 3D environment
2. Full AR: All participants local, common XR scene inserted into physical conference room using AR technology
3. Hybrid: Mix of local and remote participants; XR scene inserted for local AR viewing, remote participants represented by avatars

3.3 Specific Use Cases from TR 22.870

Three detailed use cases are referenced:

Seamless Immersive Reality in Education (Clause 9.5) - Supports local, hybrid, or fully immersive classroom configurations - Virtual objects for learning enhancement

Seamless Holographic Telepresence in Healthcare (Clause 9.8) - Highly immersive real-time interactions between patients and medical practitioners - Recreates physical co-presence using holograms, avatars, and multi-sensory media - Requires synchronized multi-modal data streams (video, audio, haptics, motion, volumetric data) - Supports six degrees of freedom (6DoF) - Emphasizes security and privacy for sensitive biometric information (facial features, voiceprints, gestures, health signals)

Personalized Interactive Immersive Guided Tour (Clause 9.12) - Combines location-aware MR/XR with avatars and multi-modal interaction - Remote touristic guide represented by personalized avatars - Heterogeneous 5G/6G-connected devices (AR glasses, XR headsets, smartphones, haptic wearables, immersive audio) - Personalized experience: individual choice of immersion level, devices, language, avatar appearance, content type - AI-based analysis of gaze, facial expressions, and behavior for contextual content adaptation - Rich XR features: 2D/3D video, volumetric video, 6DoF movement, immersive audio, tactile feedback - Supports both indoor and outdoor locations

Technical Significance

This CR establishes P2A2P as a relevant application scenario for evaluating QUIC-based media delivery in RTC services, particularly emphasizing:

• Media processing at intermediary AS nodes rather than pure end-to-end delivery
• Complex multi-modal XR communication requirements
• Need for synchronized, low-latency media handling with active processing
• Support for diverse deployment configurations and personalization
• Integration with GA4RTAR architecture and SWAP server functionality

Summary of S4-260259: Application Scenario for Peer to Application (P2A) with Split Rendering

Document Overview

This Change Request introduces a new application scenario for the Study on QUIC-based media delivery for real-time communication (RTC) services. The contribution focuses on defining the Peer to Application (P2A) scenario with split rendering as specified in TS 26.506 and TS 26.565.

Main Technical Contributions

1. References Update

The document adds a new normative reference:

• 3GPP TR 22.870: "Study on 6G Use Cases and Service Requirements" - This reference provides the foundation for the interactive application scenarios described in the contribution.

2. New Application Scenario: Real-time Interactive Applications with Split Rendering

2.1 Architecture and Functional Split

The contribution defines a split rendering architecture where:

• Peer Device Functions:
• User interaction capture
• Local sensing
• Final presentation
• Acquisition of user inputs and contextual information (motion, pose, audio, video, spatial/environmental data, sensor information)

• Transmission of captured data to application server

• Application Server Functions:

• XR/gaming scene updates
• Processing of received inputs
• Application logic execution
• Physics simulations
• AI-based processing
• Scene rendering
• Transmission of rendered frames (2D video) and additional media (audio, haptics) to peer device

2.2 Communication Characteristics

The scenario requires:

• Bidirectional communication path maintained throughout the session
• Critical performance requirements: End-to-end latency, jitter, and reliability
• Security requirements: Secure connections and encryption for privacy of sensitive data
• Multi-modal stream support: Audio, video, 2D/3D graphics, haptic feedback

2.3 Deployment Scenarios

Two operational modes are defined:

• Single-user scenario: Application server receives pose, sensor updates, and video from device camera, updates scene in real-time, and sends rendered media back
• Multi-user scenario: Shared application state (virtual scene, digital objects, avatars) maintained at application server and consistently synchronized between server and all peers in real-time

2.4 Network and Resource Requirements

The contribution identifies specific network support needs:

• Differentiated connectivity for interactive services
• Low-latency and high-reliability communication for multi-modal streams
• Coordination between communication, computing, and rendering resources
• Support for dynamic offloading of compute-intensive and rendering functions due to device constraints (form factor, energy consumption, rendering capabilities)

2.5 Applicable Use Cases from TR 22.870

The contribution maps the P2A split rendering scenario to three specific use cases from TR 22.870:

1. Immersive gaming (clause 9.2): Real-time immersive gaming and XR with multi-modal inputs, remote compute-intensive rendering and AI processing, requiring secured low-latency bidirectional media delivery

2. XR rendering offload support (clause 9.4): Lightweight XR devices offloading rendering and processing to edge/cloud servers, requiring real-time exchange of user inputs and rendered media with tight latency constraints and network-assisted optimization

3. Mixed reality gaming (clause 9.9): Multiplayer MR gaming with synchronized virtual scene based on common spatial map, continuous upload of environmental data to cloud server, real-time scene updates distribution to all participants under varying mobility and network conditions

Technical Significance

This contribution establishes a foundational application scenario for evaluating QUIC-based media delivery protocols in the context of split rendering services. It clearly defines the functional split, communication requirements, and maps to existing 6G use case requirements, providing a concrete basis for protocol evaluation and optimization work in the study item.

Summary of S4-260261: Conference Application Scenario for QUIC-based RTC

Document Information

• Source: InterDigital
• Title: Application scenario: Conference using QUIC-based media protocols for RTC
• Specification: 3GPP TR 26.836 v0.0.1
• Purpose: Discussion and Agreement

Introduction and Objective

This contribution addresses the Study on QUIC-based media delivery for real-time communication and services (FS_Q4RTC_MED). The focus is on identifying and documenting relevant application scenarios for evaluating QUIC-based media delivery protocols, specifically for conference applications in real-time communication services.

Main Technical Contributions

Reference Updates

Addition of normative reference: - [X.1] 3GPP TR 22.870: "Study on 6G Use Cases and Service Requirements"

Conference Application Scenario (Section 5.2.1.X)

General Description

The contribution defines a conference application scenario enabling multiple UEs (smartphones, tablets, smart glasses) to participate in real-time interactive sessions from web-based or native clients. Key characteristics include: - Support for audio, video, haptic media and data sharing (chat, presence, screen-sharing metadata) - Reliable control signaling and non-media data - Low latency and continuity prioritization for media delivery - Support for different browsers and dedicated applications

Architecture 1: Single Output Scenario with Centralized Mixing (Section 5.2.1.X.2)

Architecture characteristics: - Media streams (audio/video/haptic) from all participants sent to central conferencing server - Server includes composition function/media mixer - Mixer combines different input streams into single composite output stream per session - All UEs receive identical combined/mixed streams - Control and signaling messages exchanged between UEs and conferencing server

Functional aspects: - Capability and state exchange between all parties - Dynamic adaptation by media mixer to changes (resolution, video source) - Server manages admission of new participants

Architecture 2: Multi-Stream Scenario (Section 5.2.1.X.3)

Architecture characteristics: - Participants subscribe to audio/video streams published by remote participants - Central conferencing server manages subscription and publish mechanisms - Dynamic subscription model: UEs can subscribe to one or more streams, changeable over time - Composition performed on UE side

Example scenarios: - UE1 subscribes to all audio and video streams from other UEs - UE2 subscribes selectively (e.g., video from UE1, audio from UE1/UE3/UE4) - Dynamic changes supported (e.g., UE2 later subscribes to UE4 video)

Mapping to TR 22.870 Use Cases (Section 5.2.1.X.4)

The contribution maps the two conference architectures to specific use cases from TR 22.870:

Multi-Stream Scenario Mapping:

• Holographic telepresence in healthcare (clause 9.8): Separate streams for audio, hologram (avatar), and haptics with tight inter-stream synchronization

Single Output Scenario Mapping:

• Multi-site immersive communication (clause 9.6): Multi-camera capture with central rendering of global scene, distributed to on-site audiences and remote viewers

Additional Relevant Use Cases:

1. Immersive gaming (clause 9.2): Conversational media, interactive XR, haptics, synchronized shared state
2. Seamless immersive reality in education (clause 9.5): Real-time immersive telepresence with conversational latency and tight media synchronization
3. Collaborative service in multi-site involved immersive communication (clause 9.6): Multi-site immersive communication with stringent latency, synchronization, and uplink requirements
4. Multiple application media synchronisation (clause 9.7): Ultra-tight real-time, multi-modal communication with millisecond-level cross-flow and cross-device synchronization
5. Mixed reality gaming (clause 9.9): Interactive real-time mixed reality with low latency and bidirectional data exchange
6. Personalised interactive immersive guided tour (clause 9.12): Interactive, multi-user real-time immersive communication with personalized content and tight multi-modal synchronization

QUIC Protocol Suitability Justification

The contribution provides rationale for QUIC-based transport for immersive use cases based on alignment with TR 22.870 requirements:

Key requirements addressed: - Low latency - Bidirectional communication - High reliability - Multi-modal traffic support - Strong security

QUIC protocol advantages: - Encrypted-by-default communication - Stream multiplexing without head-of-line blocking - Robustness to packet loss and network variability - Built-in standardized congestion control and loss recovery mechanisms

These characteristics make QUIC suitable for interactive and immersive communication application scenarios.