# 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**:
   - Via M4d to Media Player
   - Via M3d and M1d to 5GMSd Application Provider

2. **Producer Reference Time handling**:
   - Addition to media segments and manifests
   - Time synchronization between 5GMSd Client and reference time adder

3. **Client-side implementation**:
   - Latency measurement in 5GMSd Client

4. **Reporting mechanisms**:
   - Via M4d, M13d, and possibly M5d

5. **Latency control**:
   - Controlling presentation latency for clients

6. **Exposure mechanisms**:
   - 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