3GPP Technical Document Summary: TR 26.804 CR-0029 Rev 4

Document Information

• Meeting: SA4#135, India, 9-13 Feb 2026
• CR Number: 0029, Revision 4
• Specification: 26.804 v19.1.0
• Category: B (Addition of feature)
• Release: Rel-20
• Work Item: FS_AMD_Ph2 (Advanced Media Delivery Phase 2)
• Source: Qualcomm Germany

Purpose

This CR addresses Work Topic #6 (WT#6) on Latency Measurement and Control for 5G Media Streaming services. The objective is to enable service and network providers to measure and control media service latency as a key quality indicator.

Main Technical Contributions

1. Problem Statement and Architecture (Clause 5.X.1-5.X.2)

Service Context

• Latency is identified as a critical QoE measure for streaming services
• References industry work from DVB, DASH-IF, and BBC Project Timbre
• Focus on segmented media streaming (CMAF objects with DASH MPD or HLS playlists)
• Latency measurement spans "glass-to-glass" (camera to screen) or encoder to screen

Key Latency Information Requirements

• Actual latency value
• Target latency achievement status
• Deviation from target latency
• Reasons for latency (late arrival, network issues, user-controlled)

Use Cases for Network/Service Providers

• QoE measurement per client based on latency
• Network improvements (Content Steering, QoS adjustments)
• Cross-user aggregated analytics

2. Collaboration Scenarios and Deployment Options (Clause 5.X.2)

Basic Architecture Components

1. Content Capture/Encoder: Embeds timing information using Time Synchronisation Server
2. Packaging/Manifest Generation: Distributes via CDN
3. Media Client: Measures latency by syncing to Time Synchronisation Server
4. Reporting Server: Exposes information for operations and QoE measurements

Producer Reference Time Mechanism

Based on DASH-IF Low-Latency modes:
- Supplies timestamps for production/encoding time
- Enables rate matching between production and consumption
- Supports latency measurement and control
- Can be provided in-band (prft box in ISO/IEC 14496-12) and/or in manifest
- Supports End-to-End Latency (EEL) and Encoding+Distribution Latency (EDL) measurement

Five Deployment Options Identified

Option 1: 5GMSd Application Provider runs encoding/packaging; 5GMSd AS provides CDN only (out of scope)

Option 2: 5GMSd System operates Time Synchronisation Server (in AF or AS) accessible to both Application Provider and Media Player; reporting to Application Provider via M13d

Option 3: 5GMSd AS performs manifest generation with in-band to manifest timing conversion (considered subset of Option 4)

Option 4: 5GMSd System handles encoding/packaging, controls latency end-to-end; reporting between Media Player-AS or Media Session Handler-AF

Option 5: 5GMSd System responsible only for reporting (considered subset of Option 4)

Focus: Options 2, 4, and 5 are prioritized for detailed analysis

3. Architecture Mappings (Clause 5.X.3)

Option 2 Architecture

• Time Sync Server operated by 5GMS system (AF or AS)
• Both 5GMSd Application Service Provider and client access timing information
• Reporting via M13d to Application Service Provider

Option 4 Architecture

• Encoder and packager in 5GMS AS
• Reporting via M4d to 5GMSd AS
• Time Sync Server co-located with encoder/packager
• Contribution link may access timing information for camera-to-glass latency

4. High-Level Call Flows (Clause 5.X.4)

Comprehensive 18-step call flow covering:

Content Preparation Phase (Steps 1-4)

• Camera requests wall-clock time via M1d/M2d
• Camera captures and annotates content with Producer Time
• Content Provider forwards to Encoder with Producer Reference Time via M2d
• Encoding instructions including target live latency sent via M1d/M3d

Manifest and Segment Generation Phase (Steps 5-9)

• Packager retrieves wall-clock time from Time Sync Server
• Encoder/Packager generate low-latency segments with embedded Producer Reference Time
• Segments uploaded to Content Hosting
• Manifest Creator generates presentation manifest with:
• Segment availability times
• Target Latency
• Producer Reference Time with Time Sync Server reference
• Manifest uploaded to Content Hosting

Client Request Phase (Steps 10-11)

• Media Access Client acquires manifest via M4d (learns target latency and time references)
• Client obtains current time from Time Sync Server via M4d/M5d

Content Delivery Phase (Steps 12-13)

• Client requests low-latency segments via M4d
• Content Hosting delivers segments

Content Playback Phase (Steps 14-17)

• Segments forwarded to Media Platform for decoding
• Playback initiated according to target latency
• Media Platform reports local playback time
• Client calculates end-to-end playback latency using Producer Reference Time, synchronized current time, and rendering time

Reporting Phase (Step 18)

• Measured playback latency reported to Reporting Server via M4d/M5d using DASH metrics or in-band reporting

5. Gap Analysis and Requirements (Clause 5.X.5)

Identified gaps requiring normative work:

1. Time Synchronisation Service provisioning:
2. Via M4d to Media Player

3. Via M3d and M1d to 5GMSd Application Provider

4. Producer Reference Time handling:

5. Addition to media segments and manifests

6. Time synchronization between 5GMSd Client and reference time adder

7. Client-side implementation:

8. Latency measurement in 5GMSd Client

9. Reporting mechanisms:

10. Via M4d, M13d, and possibly M5d

11. Latency control:

12. Controlling presentation latency for clients

13. Exposure mechanisms:

14. Exposing latency measurements

6. Candidate Solutions (Clause 5.X.6)

Key technical elements (Editor's Notes):

• Producer Reference Time options:
• Capture time of media sample
• Encoding time of media sample

• Other network provider-relevant times

• Time Synchronization: UTC Time Sync in DASH

• Producer Reference Time carriage: In Segments, Manifest, or implicit

• Reporting mechanisms: DASH metrics or CMCD (Common Media Client Data per CTA-5004-A)

• Latency metrics: Measured latency, deviation from target, reasons for latency

• API exposure: NWDAF or other defined APIs

References Added

• [9] DASH-IF/DVB Report on Low-Latency Live Service with DASH (July 2017)
• [10] DASH-IF IOP Guidelines v5, Low-latency Modes for DASH
• [90] DASH-IF WebRTC-based Streaming
• [105] CTA-5004-A: Web Application Video Ecosystem – Common Media Client Data (December 2025)
• [DIF-WEBRTC] DASH-IF Report: DASH and WebRTC-Based Streaming (March 2022)
• [TIMBRE] BBC Project Timbre on mobile coverage for live radio streaming (March 2024)
• [14496-12] ISO/IEC 14496-12: ISO base media file format

Coordination Requirements

• Internal 3GPP: SA2, SA3, SA5, SA6
• External: SVTA, CTA WAVE, ISO/IEC JTC29 WG3 (MPEG Systems), 5G-MAG, DVB, IETF

Status

• Previous revision S4-251709 was revised to S4-252044 and endorsed
• Current revision addresses detailed architecture, call flows, and gap analysis for latency measurement and control in 5G Media Streaming