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

3GPP Technical Document Summary: FS_AMD_Ph2 WT#5 - 5G System-independent Media Streaming

Document Information

• Document Number: S4-260048 (CR 0028 rev 4 to TS 26.804 v19.1.0)
• Meeting: SA4#135, India, February 9-13, 2026
• Work Item: FS_AMD_Ph2 (5G Advanced Media Distribution Phase 2)
• Category: B (addition of feature)
• Release: Rel-20

Main Objective

This CR addresses Work Topic #5 of the study item, which recognizes that many 5G Media Streaming (5GMS) features are largely independent of 5G System functionalities and could benefit service providers and network operators outside of 5G deployments. The study examines opportunities and technical aspects for using 5GMS features in non-5G environments.

Technical Contributions

1. Feature Dependency Analysis (Clause 5.27.2)

The document provides a comprehensive analysis of 5GMS features and their dependencies on 5G System functionalities:

1.1 Feature Classification Table

A detailed table (Table 5.27.2-1) maps each 5GMS feature to: - Feature description clauses in TS 26.501 - Procedure definition clauses - Dependencies on 5G System features (PCF, RAN, etc.)

Key findings on feature independence:

• No 5G dependency: Content hosting, content publishing, content preparation, remote control, consumption reporting, eMBMS delivery, MBS delivery
• 5G-dependent: Network assistance (PCF, RAN), dynamic policies (PCF), QoE metrics reporting (RAN for RAN-based reporting)
• Conditional dependency: Edge processing (depends on MnS), data collection (depends on Data Collection AF)
• Client-side handling: Service URL handling (no dependency if client can handle intents)

2. Detailed Feature Analysis

2.1 Content Hosting (Clause 5.27.2.4)

Services provided: - Ingest: Pull-based or push-based content retrieval - Caching: Multi-location content caching with configurable TTL - Content Preparation: Content manipulation via provisioned templates - Security: Server certificate-based content security - Logging: CDN-equivalent access logs - Client data reporting: In-band media-related information reporting

Conclusion: No dependency on 5G core or radio functionality identified. Equivalent to CDN services.

2.2 Content Preparation (Clause 5.27.2.6)

Enables content manipulation including: - Encoding/transcoding - Packaging - Encryption and DRM protection

Applicability: Both downlink and uplink media streaming

Conclusion: No dependency on 5G core or radio functionality.

2.3 Network Assistance (Clause 5.27.2.7)

Two mechanisms defined: - AF-based network assistance - ANBR-based network assistance

Sub-features: 1. Bit rate recommendation: Network provides throughput estimation 2. Delivery boost: Temporary bit rate increase for buffer replenishment

AF-based Network Assistance Analysis:

The AF can gather network information using: - CAPWAP (RFC 5415): For WiFi networks - WLC to AP management - NETCONF (RFC 6241): For fiber/DSL/cable operators - network device configuration - PCEF/PCRF model (TS 23.203, TS 29.212): 4G EPC Gx interface - TR-369 (USP): Broadband Forum standard for device management

Key findings: - AF-based procedures between AF and Media Session Handler are 5G System-independent - Bit rate recommendations can be obtained via existing protocols (CAPWAP, NETCONF, PCC) - Delivery boost functionality limited - most protocols are static, not dynamic online bandwidth-request protocols (except 4G PCRF/PCEF) - RAN-based network assistance has no known API or functionality in non-5G networks

Conclusion: 1. AF-based network assistance may be independent of 5G System, particularly for bitrate recommendations 2. Delivery boosts not universally available due to dynamic nature 3. RAN-based network assistance not applicable outside 5G

3. Media Application Service Model (Clause 5.27.2.3)

3.1 Generalized Model

Defines media delivery session characteristics: - One or more Service Data Flows (IP 5-tuples) - Multiple service location endpoints - Dynamic behavior including service location switching - ANDSP-based routing (URSP for 5G, HLOS for other interfaces) - Mobility support

3.2 5GMSd Application Service Model

Conceptual model includes: - 5GMSd AS instance - Content Hosting Configuration (per Provisioning Session) - Distribution Configuration (service location) - Downlink media streaming session - Service Data Flow (HTTP connection at M4d) - Application Data Flow (media segment downloads)

3.3 5GMSu Application Service Model

Similar structure for uplink: - 5GMSu AS instance - Content Publishing Configuration - Contribution Configuration - Uplink media streaming session - Service Data Flow and Application Data Flow at M4u

Key concept: Media delivery session identifier enables association of Service Data Flows with sessions via HTTP headers.

4. Additional Features Marked for Further Study

The following features are identified but marked "For further study": - Content publishing (Clause 5.27.2.5) - Dynamic policies (Clause 5.27.2.8) - Remote control (Clause 5.27.2.9) - Consumption reporting (Clause 5.27.2.10) - QoE metrics reporting (Clause 5.27.2.11) - Edge processing (Clause 5.27.2.12) - eMBMS delivery (Clause 5.27.2.13) - Data collection, reporting and exposure (Clause 5.27.2.14) - Service URL handling (Clause 5.27.2.15) - MBS delivery (Clause 5.27.2.16)

5. Document Structure

The CR adds: - New references for non-5G protocols (RFC 5415, RFC 6241, TS 23.203, TS 29.212, TR-369) - New Clause 5.27: "5G System-independent media streaming" - New Clause 6.27: Placeholder for solutions - Comprehensive reference material retained for feature analysis

Key Conclusions

1. Significant 5G-independence: Many 5GMS features (content hosting, preparation, consumption reporting) have no 5G System dependencies

2. Network assistance viability: AF-based network assistance can leverage existing protocols (CAPWAP, NETCONF, PCC) for non-5G deployments, though with limitations on dynamic features

3. Protocol mapping identified: Clear mapping between 5GMS requirements and existing industry protocols for various access networks

4. Further work needed: Multiple features require additional study to determine applicability and implementation approaches for non-5G scenarios

Revision History

• Original: S4-251708
• Discussion raised questions about 5G System dependencies, AF/AS dependencies, and consumption reporting applicability
• Revised to S4-252043 and endorsed

3GPP Technical Document Summary: FS_AMD_Ph2 WT#1 - Common Client Metadata Phase 2

Document Information

• Document Number: 26.804 CR 0030 rev 2
• Release: Rel-20
• Category: C (functional modification of feature)
• Work Item: FS_AMD_Ph2 (5G Media Streaming Architecture - Phase 2)

Main Technical Contributions

1. Introduction and Scope Extension

This CR extends the study of Common Media Client Data (CMCD) in 5G Media Streaming (5GMS) to include CMCDv2 (version 2), which was published in December 2025 by CTA WAVE (CTA-5004-A specification). The document analyzes the integration of CMCDv2 into 5GMS workflows, focusing on: - New metrics and reporting methods introduced in v2 - Multiple reporting modes (request mode and event mode) - Enhanced operational optimizations for 5GMSd AS and AF

2. CMCDv2 Key Enhancements

2.1 New Key-Value Pairs

CMCDv2 introduces numerous new keys including: - Live latency (ltc): Time delta between origin availability and player rendering - Target buffer length (tbl): Target buffer at request time - Media start delay (msd): Initial delay from play instruction to playback start - Aggregate bitrate (ab): Bitrate across playable track combinations - CDN ID (cdn): CDN identifier - Response code (rc): HTTP response code received - Time to first/last byte (ttfb, ttlb): Network timing metrics - Player state (sta): Enhanced state reporting (starting, playing, seeking, rebuffering, paused, ended, fatal error, quit, preloading) - Playhead time (pt): Current playhead position (VOD offset or live epoch time) - Buffer starvation metrics (bsa, bsd, bsda): Absolute counts and durations - Dropped frames (dfa): Absolute count since session start

2.2 Enhanced Reporting Modes

Event Mode (new in v2): - Allows reports at arbitrary times, not just with content requests - Event types include: - Play state changes (ps) - Errors (e) - Time intervals (t) - Content changes (c) - Backgrounding (b) - Muting/unmuting (m, um) - Interstitial content (ad) tracking (abs, abe, as, ae) - User actions like seeking (sk) - Response received (rr)

Multiple Destinations: - Event reports can be sent to different endpoints (CDN, player monitoring, ad reporting, content steering) - Enables concurrent reporting to different 5GMS functions without constraining third-party reporting

3. Use Cases for 5GMS

The document identifies seven key use cases:

1. Operational optimization of 5GMSd AS: Using CMCD for pre-fetching content based on nor (next object request) key
2. Operational optimization of 5GMSd AF and 5G Media Streaming: Using CMCD to configure 5G System (e.g., delivery boost on buffer starvation)
3. UE data collection and event exposure: Providing CMCD information to 5G System or external Application Providers
4. Event-based reporting (v2): Tracking events and user behaviors, including ad information
5. Advanced AS optimization (v2): Multiple object prefetching (v1 only allowed single object)
6. Multiple destinations for event reports (v2): Separate concurrent reporting to different 5GMS functions
7. Session handling reporting (v2): Media Session Handler sending event reports out-of-band to 5GMSd AF via M5

4. Architecture Mappings

Three architectural options are defined:

4.1 Option 1: In-band via M4d and M3d (Preferred)

• Media Player reports CMCD in-band with media requests at M4d (as HTTP headers or query parameters)
• 5GMSd AS collects and reformats CMCD, reports to 5GMSd AF via M3d
• Enables AS operational optimizations (pre-fetching)
• Enables AF operational optimizations (network assistance, policy updates)

4.2 Option 2: In-band via M4d and R4

• Similar to Option 1 but 5GMSd AS reports to Data Collection AF via R4
• Uses data reporting session mechanism from TS 26.531/26.532
• CMCD information not directly visible to 5GMSd AF (only to Data Collection AF)

4.3 Option 3: Out-of-band via M11d and M5d

• Media Player reports CMCD to Media Session Handler via M11d
• Media Session Handler reports to 5GMSd AF via M5d
• Does NOT support AS pre-fetching optimizations
• Not preferred solution

5. Gap Analysis and Requirements

5.1 Common Gaps (All Options)

1. Lack of provisioning information at M1d for CMCD reporting configuration
2. Lack of CMCD client reporting configuration in Service Access Information at M5d
3. Lack of Media Player configuration API at M11d for CMCD collection/reporting
4. Missing Media Player functionalities to report CMCD at M4d
5. Missing Media Session Handler functionalities to configure Media Player

5.2 Option-Specific Gaps

Option 1 (M4d/M3d): - Lack of configuration signaling at M3d for 5GMSd AS - Missing 5GMSd AS functionalities to extract/process CMCD and report to AF via M3d - Missing 5GMSd AF functionalities to process CMCD from AS

Option 2 (M4d/R4): - Lack of configuration signaling at R4 for data reporting sessions - Missing 5GMSd AS functionalities to report to Data Collection AF via R4 - New data domain and record data types needed in TS 26.532/26.512

Option 3 (M11d/M5d): - Missing Media Session Handler functionalities to report CMCD to AF via M5d - Missing 5GMSd AF functionalities to process CMCD from Media Session Handler

6. Candidate Solutions

6.1 Provisioning and Configuration

• M1d provisioning: Reuse metrics reporting provisioning procedures from TS 26.510 with new CMCD metrics reporting scheme in TS 26.512
• Event exposure: New AfEvent enumeration value for CMCD events, new collection/record data types in TS 26.512, new DataDomain value in TS 26.532
• M3d/M5d configuration: Extend Service Access Information with CMCD reporting configuration using new metrics reporting scheme for CMCD JSON format

6.2 Data Reporting Formats

• In-band at M4d: CMCD query parameter or CMCD request headers per CTA-5004
• At M3d: CMCD JSON format per CTA-5004
• At R4: New record data type based on CMCD JSON format
• At M5d: CMCD JSON format using QoE metrics reporting mechanism

6.3 Event Exposure

• Reuse event exposure mechanism from TS 26.501 clause 4.7.4 and TS 26.512 clause 18
• New collection and record data types for CMCD information
• Extension to TS 29.517 clause 5.6.2.6 for AfEventNotification

7. CMCD Key Relevancy Analysis (Annex)

The document includes a comprehensive table (Table 5.16.6A) analyzing each CMCDv2 key for relevance to 5GMS deployment. This table is marked as "work in progress" and requires further analysis.

8. Comparison with Existing 5GMS Mechanisms

Minimal Overlap Identified: - CMCD has minimal overlap with existing QoE metrics reporting (TS 26.247 clause 10) and consumption reporting (TS 26.512 clause 11.3.3) - Some common elements: session ID, content URI, timestamps, buffer levels, throughput - CMCD provides complementary client-side operational data not covered by existing mechanisms

9. Conclusions and Recommendations

Preferred Solution: Option 1 (In-band via M4d and M3d)

Rationale: - In-band reporting at M4d is broadly implemented in common media clients - Permits operational optimizations by both 5GMSd AS (pre-fetching) and 5GMSd AF (network assistance) - All envisaged use cases can be supported - Passing CMCD to AF at M3d enables operational optimizations not possible with Option 2

Key Recommendations: 1. Implement Option 1 solution in relevant 3GPP specifications 2. Provide deployment choices for CMCD query parameter vs. request headers 3. Consider CMCD as supplementary to (not replacement for) existing QoE and consumption reporting 4. Support both CMCDv1 and CMCDv2 features, particularly event mode and multiple destinations

10. Specification Impacts

Normative References: - Update reference to CTA-5004-A (December 2025 version) - Add reference to IETF RFC 8941 (Structured Field Values for HTTP)

Specification Changes Required: - TS 26.510: Provisioning procedures, configuration APIs, data reporting operations - TS 26.512: New metrics reporting schemes, data types, event exposure formats - TS 26.532: New data domain enumeration - TS 29.517: New AfEvent enumeration value (CT3 coordination required)

Change Request Summary: WT2c Updates to Secure Communication of Network Properties (SCONE-PRO)

Document Information

• CR Number: 0032 (Rev 1)
• Specification: TS 26.804 v19.1.0
• Category: C (functional modification)
• Release: Rel-20
• Work Item: FS_AMD_Ph2 (Advanced Media Delivery Phase 2 Study)

Purpose and Scope

This CR addresses Work Topic #2 (Server and Network-assisted media streaming) by documenting the impact of IETF's Standard Communication with Network Elements (SCONE) protocol on 5G Media Streaming. The CR updates the technical report to reflect the evolution from the initial SCONE-PRO BoF discussions to the established SCONE Working Group and its protocol development.

Main Technical Contributions

1. References Update (Clause 2)

New References Added: - [X1]: IETF draft-ietf-scone-protocol-04 - "Standard Communication with Network Elements (SCONE) Protocol" - [X2]: IETF draft-eddy-tcpm-scone-01 - "SCONE TCP Option" (extends SCONE beyond QUIC to TCP)

2. Clause Title and Scope Changes (Clause 5.25.1.2 and 5.25.1.3)

Structural Reorganization: - Clause 5.25.1.2: Changed from "void" to "Secure Communication of Network Properties (SCONE-PRO)" - now contains historical context and motivation - Clause 5.25.1.3: Retitled from generic content to "Standard Communication with Network Elements (SCONE)" - focuses on current WG status and objectives

Content Migration: - Historical SCONE-PRO BoF material moved to Clause 5.25.1.2 - Current SCONE WG charter and objectives documented in Clause 5.25.1.3 - Detailed technical protocol specification moved to new Annex C.3

3. New Annex C.3: Detailed SCONE Protocol Specification

This new annex provides comprehensive technical documentation of the SCONE protocol.

C.3.1 Introduction

Historical Context: - Documents the evolution from SCONE-PRO BoF sessions (September 2024) to SCONE WG establishment (November 2024 at IETF 121) - Preserves motivation material including: - ABR Video Shaping challenges - YouTube™ coordination examples with MNOs - Traffic shaping issues and their impact on user experience

Problem Statement Summary: - Video traffic represents 70% of Internet traffic (projected 80% by 2028) - 50-80% of mobile network traffic volume - Network capacity augmentation not keeping pace with demand - Traffic shaping negatively affects video quality without measurable QoE feedback - ABR schemes struggle to converge with traffic shapers, causing "ping-pong" effects

Core Solution Characteristics: - Flow associativity (per-QUIC connection) - Single communication channel for client initiation and network properties - Network-originated property signaling - On-path establishment (no off-path elements required) - Optional implementation - Advisory properties (not mandatory directives)

SCONE WG Objectives: 1. Mechanism for rate-limiting network elements to communicate throughput advice 2. Application notification for both upstream/downstream traffic 3. Throughput advice as guideline (not congestion signal) 4. Dynamic updates capability 5. Endpoint signaling and acknowledgment requirements determination

Implementation Progress: - Protocol draft adopted May 2025 - WG Last Call: December 19, 2025 - January 20, 2026 - Successful interoperability testing at IETF#123 hackathon (July 2025) with running code from Ericsson, Nokia, Meta, YouTube, Cloudflare - Live demos at IETF#124 (November 2025) by Ericsson and Meta showing improved UX - TCP extension draft available (SCONE-TCP)

C.3.2 SCONE Protocol Technical Details

Protocol Principles: - Encoding: Throughput advice encoded in 6 LSBs of first octet - Logarithmic distribution: Enables wide range representation - Packet insertion: Sender occasionally inserts SCONE packet at UDP datagram beginning - No acknowledgment required: Receiver doesn't need to ACK throughput advice - Advisory nature: No enforcement mechanism

Packet Format: - Illustrated in Figure C.3.2-1 (SCONE packet structure)

Key Characteristics:

1. Independent of congestion signals: Complements but doesn't replace traditional congestion control
2. Unspecified scope: Flexibility for network operators (single hop or multi-element)
3. Per-flow signal: Applies to specific QUIC flow (UDP 4-tuple)
4. Unidirectional: Direction-specific advice (upstream/downstream independent)
5. Advisory only: Optional, non-binding guidance
6. Dynamic updates: Continuous or periodic updates as conditions change

Bitrate Calculation: - Value 127: Sent by QUIC endpoint or indicates unknown throughput advice - Values 0-126: Represent rate ceiling from network elements - Logarithmic scale formula: - Base rate (b_min) = 100 Kbps - Bitrate at value n = b_min × 10^(n/20)

Packet Transmission: - Unencrypted transmission - Typically standalone UDP packet - Distinct SCONE packet format visible to network

Network Element Behavior (Figure C.3.2-2): - Any on-path NE capable of rate-limiting may send throughput advice - Multiple NEs can inject SCONE packets for same flow - Each NE reports its own maximum allowable rate view - No protocol-defined aggregation or coordination between NEs

Early SCONE Notification: - Proactive client signaling mechanism - Clients indicate SCONE capability before QUIC connection fully established - Helps NEs detect SCONE-capable flows without DPI or QUIC Initial decryption - "SCONE Indication" appended to QUIC Initial packet

Monitoring Period: - Standard period: 67 seconds - Defines time window over which throughput advice applies - Flexible implementation: - Senders can limit rate over any period up to 67 seconds - NEs monitor/apply limits using minimum 67-second period

Relationship to 5G Media Streaming

The CR maintains the investigation scope for: - How 5G Media Streaming requirements align with SCONE-PRO/SCONE objectives - Potential combination scenarios between SCONE and 5G Media Streaming - Required extensions to 5G Media Streaming for SCONE integration

Impact Assessment

Benefits: - Comprehensive documentation of IETF SCONE protocol evolution - Clear technical specification for 3GPP-IETF coordination - Foundation for potential normative work in 5G Media Streaming specifications - Addresses operator traffic management challenges while improving user QoE

Coordination Requirements: - Ongoing liaison with IETF SCONE WG - Potential impacts on SA2 (architecture), SA3 (security), SA5 (management) - External coordination with SVTA, CTA WAVE, ISO/IEC JTC29 WG3, 5G-MAG, DVB

3GPP TR 26.804 CR 0037: Rate Limits in 5G Media Streaming

Change Request Overview

• CR Number: 0037
• Release: Rel-20
• Category: B (addition of feature)
• Work Item: FS_AMD_Ph2 (Work Topic 2: Server and Network-assisted media streaming)
• Related CRs: TR 26.804 CR 0031, CR 0032 (proposed to merge)

Background and Motivation

Problem Statement

Video traffic represents 70% of overall Internet traffic volume, expected to grow to 80% by 2028. Network operators increasingly employ traffic shaping/throttling on a per-flow basis to manage capacity constraints, but this creates challenges:

• Network operators cannot explicitly measure degradation to end-user QoE caused by traffic shaping (open-loop approach)
• ABR schemes struggle to converge on the shaping rate while maintaining good user experience
• Application providers develop complex algorithms to detect and estimate shaping rates, which are often inaccurate

Proposed Solution

Enable in-band signaling of network attributes (specifically rate limits) to applications/media players, allowing them to self-adapt with QoE feedback. This creates a closed-loop system where: - Network rate limits are explicitly communicated - Media players can adapt ABR logic accordingly - Application providers can measure and optimize based on actual QoE

Collaboration Scenarios (Section 5.25.2)

Network Architecture Context

Based on 5G Media Streaming architecture (TS 26.501):

• Rate Enforcement Entity: UPF (User Plane Function) in 5G networks
• Rate Decision Source: SMF provides subscriber-specific rules and policies via N4 interface
• Enforcement Mechanism: QoS Enforcement Rules (QERs) specifying MBR_UL/MBR_DL (Maximum Bit Rate)

Three Solution Options

The CR proposes three non-mutually-exclusive approaches:

1. UPF/SCONE: UPF sets rate limits using SCONE packets
2. AS/SCONE: 5GMSd Application Server sets rate limits using SCONE packets
3. AS/CMSD: 5GMSd Application Server sets rate limits using CMSD headers

Architecture Mappings (Section 5.25.3)

Option 1: UPF/SCONE

• UPF adds MBR_DL information to SCONE packets
• 5GMS client extracts information and provides to Media Player
• Media Player uses information and reports back to 5GMSd AS/AF
• No additional functional components or reference points required

Option 2: AS/SCONE

• Rate limits provided to AS via SMF interaction (trusted domain) or NEF interaction (external AS)
• AS adds information to SCONE packets
• Same client-side processing as Option 1
• No additional functional components or reference points required

Option 3: AS/CMSD

• Rate limits provided to AS via SMF/NEF
• AS adds information using CMSD headers
• Client extracts and processes CMSD information
• No additional functional components or reference points required

High-Level Call Flows (Section 5.25.4)

UPF/SCONE Call Flow Extensions

Key additions to baseline DASH workflow (TS 26.501, clause 5.2.3):

• Step 5a: Media Player configured via API to use SCONE (optional)
• Step 13a: UPF receives rate limit information when transport session established
• Step 17: Media Player adds SCONE client notification to QUIC initial packet or TCP
• Step 17a: AS identifies Media Player SCONE capability
• Step 18a-18h: SCONE packet processing chain:
• UPF identifies SCONE capability
• UPF applies rate throttling
• UPF sets SCONE packets with rate advice
• Protocol endpoint extracts SCONE information
• Media Player uses information for media selection
• Media Player reports rate limits via CMCD/DASH Metrics
• AS/AF uses information for optimization

AS/SCONE and AS/CMSD Generalized Call Flow

Similar workflow with key difference: - Step 13b: NEF/PCF/SMF exposes rate limit to AS - AS handles rate limit signaling instead of UPF

Gap Analysis and Requirements (Section 5.25.5)

Common Gaps (All Solutions)

1. Media Player functional updates to use rate advice in content selection
2. Media Player reporting of received/applied rate limits to AS
3. AS functional extensions to process rate limit reporting

UPF/SCONE Specific Gaps

1. Configuration API to enable SCONE in client
2. Media Player extension to add SCONE client notification to QUIC/TCP
3. AS extension to identify SCONE capability and add SCONE packets
4. 5GMS Client to extract SCONE information and provide to Media Player

AS/SCONE Specific Gaps

1. Configuration API to enable SCONE in client
2. Media Player extension for SCONE client notification
3. AS extension to identify SCONE capability
4. AS capability to obtain rate limits via NEF/SMF/PCF
5. AS capability to add SCONE packet with rate advice
6. 5GMS Client SCONE extraction capability

AS/CMSD Specific Gaps

1. Configuration API to enable CMSD with maximum bitrate
2. Media Player extension for CMSD client notification
3. AS extension to identify CMSD capability and add CMSD header with maximum bitrate
4. AS capability to obtain rate limits via NEF/SMF/PCF
5. 5GMS Client CMSD extraction capability

Candidate Solutions (Section 5.25.6)

Media Player Updates (5.25.6.1)

Proposed approach based on existing dash.js implementation: - Configure ABR to use CMSD "mb" value as hard upper bound - Restrict highest selectable representation to mb - Immediate switch-down if current representation exceeds mb

RATE_LIMITS from SCONE/CMSD used to: - Select Representations/Tracks with aggregate bitrate ≤ RATE_LIMITS - Guide bitrate selection at startup - Adjust player logic for trickplay operations

Media Player Reporting (5.25.6.2)

Proposed CMCD/DASH Metrics extension:

| Parameter | Key | Header | Encoding | Definition | |-----------|-----|--------|----------|------------| | Network rate limit | nrl | CMCD-Status | bit(7) | Rate limit from network element (e.g., SCONE packet) |

AS Processing (5.25.6.3)

AS can use rate limit information to: - Provide content fitting within rate limits - Optimize content for rate limits

SCONE Enablement API (5.25.6.4)

Configuration API Extension (TS 26.512, clause 13.2.4): - Add enableSCONE (Boolean) parameter to desiredContentDeliveryConfiguration

Transport Connection Status API Extension (TS 26.512, clause 13.2.6): - Add networkRateLimit (Integer) parameter to TransportConnectionStatus

SCONE Signaling in 5GMS Client (5.25.6.5)

5GMS client adds SCONE client notification to QUIC initial packet or TCP if capable

AS SCONE Extensions (5.25.6.6, 5.25.6.9)

• Identify Media Player SCONE capability
• Add SCONE packet (initially without rate advice)
• Later add SCONE packet with rate advice from NEF/SMF/PCF

5GMS Client SCONE Extraction (5.25.6.7)

Two options for exposing SCONE information to Media Player: - API from protocol stack to Media Player - TCP/QUIC endpoint provides SCONE information via CMSD header within 5GMS client

AS Rate Limit Reception (5.25.6.8)

• NEF exposes network information via northbound APIs (TS 29.522)
• Procedures related to rate and QoS management exist
• Editor's Note: Need to verify if rate limits can be exposed via TS 29.522

CMSD Enablement API (5.25.6.10)

Configuration API Extension (TS 26.512, clause 13.2.4): - Add enableCMSD-RL (Boolean) parameter to desiredContentDeliveryConfiguration

CMSD Signaling and Processing (5.25.6.11-5.25.6.12)

• 5GMS client signals CMSD rate limit capability (e.g., via CMCD)
• AS identifies capability and adds CMSD mb header with rate advice from NEF/SMF/PCF
• Client processes CMSD information via API or internal header processing

Summary and Conclusions (Section 5.25.7)

Key Findings

Rate limit signaling in media streaming is beneficial for improved 5G operation. Three technology options identified with different characteristics.

Option 1 (UPF/SCONE) Assessment

Advantages: Direct implementation at enforcement point

Disadvantages: - Not all UPFs may support SCONE signaling - Solution very specific to QUIC; TCP/IP option work in progress - No defined API in 5GMS client to expose information to Media Player

Option 3 (AS/CMSD) Assessment

Complementary solution addressing UPF/SCONE limitations: - Works regardless of UPF capabilities - Protocol-agnostic (HTTP-based) - Requires rate limit exposure to AS via NEF

Recommendation

Address necessary extensions for both UPF/SCONE and AS/CMSD options to provide comprehensive solution coverage.

Note: Support for SCONE, SCONE-PRO, and CMSD in context of in-band QoS signaling marked for further study.

3GPP Technical Document Summary: TS 26.802 CR 0009 rev 3

Document Information

• Change Request for: TS 26.802 v19.2.0
• Work Item: FS_AMD_Ph2 (Advanced Media Delivery Phase 2)
• Category: C (functional modification of feature)
• Release: Rel-19
• Source: Qualcomm Germany
• Status: Endorsed at SA4#134

Main Objective

This CR addresses Work Topic #4: Combined Unicast-Multicast-Broadcast, extending the combination of unicast with broadcast/multicast services as introduced in TR 26.804 clause 5.12. The work includes progressing candidate solutions, studying combination with deployed media players, and defining a RESTful API between MBSF and MBS AS (reference point MBS-9) for configuring unicast repair.

Key Technical Contributions

1. Background and Problem Statement (Clause 5.12.1)

Deployment Scenarios Addressed: - 5GMS via eMBMS and MBS - DVB ABR Multicast (ETSI TS 103 769) - ATSC 3.0 (A/331) - 5G Broadcast (ETSI TS 103 720) - DVB-I over 5G (ETSI TR 103 972)

Use Cases for Hybrid Services: - In-session unicast repair - Application services including hybrid services - Reporting and metrics - DRM support - Common Media Client Data (CMCD) - Targeted Ad Insertion (ISO/IEC 23009-1 6th edition) - Fast Start-up using unicast (Segment Sequences) - A/B Watermarking (DASH-IF ETSI TS 104 002)

Personalization Requirements: - Requests may include personalized information (user IDs, tokens, device IDs, tracking data, CMCD) - Responses may be customized by CDN/edge servers - Examples: Ad tracking/beaconing, DRM license requests, targeted dynamic ads, A/B watermarking variants

2. High-Level Solutions (Clause 5.12.1.2)

Solution 1: Media Player Handles Unicast Requests - Manifest discriminates between local media server (broadcast/multicast) and unicast requests via different URLs - Media Player directly handles unicast requests - Limitations: Request data terminates at local Media Server, obfuscation issues, scalability concerns

Solution 2: MBS/MBMS/5G Broadcast Client Handles Unicast Requests - Media Player sends conditioned requests to local/gateway server - Local/gateway server processes additional information and may issue unicast requests - Resources may be served from broadcast, unicast, or combination - This CR focuses on Solution 2

3. MBMS Generic Application Service (Clause 5.12.1.3)

Key Specifications from TS 26.346: - User service announcement contains explicit Application Service Description (DASH MPD or HLS M3U8) - Resources referenced in Application Service Entry Point document delivered as MBMS User Service - Supports both broadcast and unicast delivery

Two Main Use Cases: 1. Unicast fallback reception: When UE moves outside MBMS coverage 2. Unicast-supplemented service offerings: Certain resources only available via unicast for enhanced user experience

Service Location Switching Techniques:

3.1 SAND4M (Clause 5.12.2.2.2)

• Uses SAND messages to signal availability of MBMS User Service
• Example: In coverage - broadcast available, supplementary unicast available
• Out of coverage - broadcast unavailable, fallback unicast available

3.2 DASH-IF Content Steering (Clause 5.12.2.2.3)

• Broader client support
• Uses Content Steering documents with pathway priorities
• TTL and reload URI for dynamic updates

3.3 Presentation Manifest Rewriting (Clause 5.12.2.2.4)

• MBMS Client understands streaming manifest (e.g., DASH MPD)
• Rewrites document based on resource availability
• Prunes unavailable Representations based on service location

4. Collaboration Scenarios (Clause 5.12.2)

Generic Application Service Architecture: - New function in Multicast/Broadcast client for policy-based service location steering - Application service document requested through Media Service (service location 1) - Policy enforcement via SAND4M, manifest rewriting, or content steering

Personalized Request Handling: - New function collects information and communicates with unicast Application Provider - Application provider configures Multicast/Broadcast Network Function - Configuration instruction provided to Multicast/Broadcast Clients via service announcement - Client manages personalized requests/responses, adapts responses, selectively requests from unicast server

5. Architecture Mappings (Clause 5.12.3)

5.1 MBS AS-Based Solution (Clause 5.12.3.2)

Architecture Extensions: - MBS AS extended beyond object repair to host content for generic application services - May be co-located with unicast server - MBSTF Client includes steering policy for service locations - Media Server provides configuration API

New/Modified Reference Points: - MBS-6': MBSF Client configures content steering policy in MBSTF Client - MBS-7: MBS-Aware Application requests to Media Server (may include different service locations) - MBS-9: MBSF provisions application unicast ingest in MBS AS - MBS-12: Unicast ingest session from MBSTF to MBS AS

Extended Procedures: 1. User service provisioning includes application unicast provisioning 2. Distribution session provisioning includes content availability on application unicast 2a. MBSF provisions application unicast ingest in MBS AS via MBS-9 3. User service announcement includes instructions for application unicast 5a. MBS AS ingests application unicast content from MBSTF 8. MBSTF Client configuration extended for content steering policy 9. Distribution Session activation includes content steering policy activation 11. Distribution Session uses MBS AS selectively for unicast requests 11a. Content steering policy changes toggle between multicast (MBS-4-MC) and unicast (MBS-4-UC) 12. Requests from MBS-Aware Application may include different service locations

5.2 External Unicast Server Solution (Clause 5.12.3.3)

Architecture Extensions: - External unicast server instead of MBS AS - New Reference Point MBS-13: Connects MBSTF Client to MBS Application Provider - Unicast traffic retrieved directly from MBS Application Provider (not via MBS AS) - MBS Application Provider may be 5GMSd AS

Modified Procedures: - Similar to MBS AS solution but uses MBS-13 for external server access - Content steering toggles between MBS-13 and MBS-4-UC

5.3 Selective Unicast Requests (Clause 5.12.3.4)

Architecture Extensions: - Request filter function added to MBSTF Client - Filters based on request types (DRM license, Ad beacons, A/B watermarking) - Requests may go to MBS AS or external application server

Modified Procedures: 1. User service provisioning includes request filters 2. Distribution session may provision content on MBS AS 3. User service announcement includes request filter instructions 8. MBSTF Client configuration includes request filter policy 9. Distribution Session activation includes request filter policy 11. Distribution Session uses MBS AS and/or external server based on request filters 12. Requests handled by multicast, unicast to MBS AS, or unicast to external server

6. Gap Analysis (Clause 5.12.4)

6.1 MBS AS-Based Solution Gaps:

1. ~~Void~~ Formal definition of named reference point between MBSTF and MBS AS
2. MBS User Service provisioning parameters at Nmb10 for content steering policy
3. MBS AS provisioning at MBS-9 for application unicast requests
4. MBS User Service Announcement parameters for application unicast
5. Unicast ingest session at MBS-12
6. MBSTF Client functional extension for service location switching
7. Support for differentiated requests from MBS-Aware Application to Media Server
8. Support for application unicast requests from MBSTF Client to MBS AS via MBS-4-UC

6.2 External Unicast Server Additional Gaps:

1. Reference point connecting MBSTF Client to MBS Application Provider
2. MBS AS provisioning at MBS-9 for external application server
3. Support for application unicast requests via MBS-13

6.3 Selective Unicast Requests Additional Gaps:

1. User service provisioning for request filters
2. MBSTF extension for selective unicast requests based on filters
3. Parallel distribution sessions at MBS-4-MC, MBS-4-UC, and/or MBS-13
4. Support for appropriate error codes

7. Candidate Solutions (Clause 5.12.5)

7.1 MBS AS-Based Solutions:

1. Use same reference point as object repair (clause 5.9)
2. URL mapping templates aligned with Content Hosting Configuration in 5GMS AS
3. Generalization of object repair provisioning
4. Include URL mapping template in MBS User Service Announcement
5. Options: SAND4M, manifest rewrite, DASH-IF Content Steering (per TS 26.501, TS 26.512)
6. No specific client extensions needed for typical clients
7. Support for HTTP request headers, URL query parameters processing

7.2 External Unicast Server and Selective Requests:

• Marked as "for further study"

8. Recommendations (Clause 8.5)

Stage 2 Normative Work (TS 26.502):

• Add functional extensions and call flows for combined MBS multicast and unicast

Stage 3 Normative Work (TS 26.517):

• Extend MBS User service protocols and formats based on stage-2 extensions

Coordination:

• Validate approaches by implementation (e.g., 5G-MAG Reference Tools)

Document Updates

New References Added: - [42] ETSI TS 103 998: "Content Steering for DASH" - [43] 3GPP TR 26.247: "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)"

New Abbreviations: - CMAF: Common Media Application Format - MABR: Multicast ABR - MBSF: Multicast/Broadcast Service Function - MBSTF: Multicast/Broadcast Service Transport Function - NEF: Network Exposure Function - PCF: Policy and Charging Function

Summary

This CR provides comprehensive architectural and procedural extensions to support hybrid unicast-multicast/broadcast services in MBS User Services. It addresses multiple deployment scenarios with three main architectural approaches (MBS AS-based, external server, selective requests), identifies gaps, and proposes candidate solutions. The work enables advanced use cases like targeted advertising, A/B watermarking, DRM, and personalized content delivery while maintaining efficient broadcast distribution for common content.

Summary of 3GPP Technical Document S4-260206

Document Information

• Specification: TS 26.804 (Release 20)
• CR Number: 0033 (Revision 02)
• Category: B (Addition of feature)
• Work Item: FS_AMD_Ph2 (Study on Advanced Media Delivery Phase 2)

Main Technical Contribution

This Change Request proposes baseline procedures for establishing multi-access uplink media streaming sessions using ATSSS (Access Traffic Steering, Switching, and Splitting) in 5G Media Streaming (5GMS) systems. The contribution addresses Work Task #8 on multi-access media delivery phase 2, specifically focusing on the impact of multi-access media delivery for uplink streaming.

Technical Content

Background on ATSSS Architecture (Clause 5.18.1.3.1)

The document provides comprehensive background on ATSSS architecture as specified in TS 23.501:

Key ATSSS Principles

1. Multi-Access PDU Connectivity Service: Enables simultaneous use of one 3GPP access network and one non-3GPP access network via independent N3/N9 tunnels between PSA UPF and RAN/AN

2. MA PDU Session Application:

3. M5 reference point (Media Session Handler to Media AF) may use two different access networks

4. M4 reference point (Media Access Client to Media AS) may use two different access networks

5. Policy Rules Distribution:

6. UE receives ATSSS rules for uplink traffic distribution
7. UPF receives N4 rules for downlink traffic distribution

8. SMF configures both rule sets, mapping from PCF PCC rules

9. UE ATSSS Capability Indication: UE indicates ATSSS support (steering functionalities and modes) in PDU Session Establishment Request

10. Network Slicing: Same S-NSSAI allowed to span both access networks

11. QoS Support:

12. Same 5G QoS model applies to MA PDU Sessions
13. QoS Flow is access-agnostic with same network QoS across different access networks

14. Application flows at M5/M4 maintain similar network QoS as 3GPP-only access

15. Measurement Assistance: Network provides measurement assistance information to UE/UPF for packet round-trip time and packet loss rate measurements

Traffic Steering Mechanisms

Three steering mechanisms are supported:

1. MPTCP (Multipath TCP): UPF provides MPTCP proxy functionality
2. MPQUIC (Multipath-enabled QUIC): UPF provides MPQUIC proxy functionality
3. ATSSS-LL (ATSSS Low-Layer): Steering, switching, and splitting based on IP layer and below

Steering Modes

Five steering modes are defined:

• Active-Standby: Primary access with fallback to standby
• Smallest Delay: Route to access with smallest round-trip time
• Load-Balancing: Split traffic between both accesses
• Priority-based: Route to higher priority access
• Redundant: Duplicate packets on both accesses

IP Address Allocation

UE may receive up to five IP addresses: - One for MA PDU session (always allocated) - Two MPTCP link-specific multipath addresses (one per access) - Two MPQUIC link-specific multipath addresses (one per access)

Multi-Access Uplink Media Delivery Procedures (Clause 5.18.4.3)

Architecture Overview

The document describes the control plane architecture: - PCF generates PCC rules for each Service Data Flow (SDF) - SMF translates PCC rules into N4 rules for UPF (FARs, PDRs, MARs, ATSSS rules) - SMF delivers ATSSS rules and URSP rules to UE via AMF over N1 interface - UE ATSSS functions manage uplink traffic - UPF ATSSS functions manage downlink traffic

MA PDU Session Setup Options

Three methods for establishing multi-access PDU sessions:

1. Set up single-access PDU Session first, then register over another access and request MA PDU Session
2. Indicate ATSSS capability and request MA PDU Session from the start
3. Request single-access PDU Session but network transparently sets up MA PDU Session

Detailed Call Flow

The document provides a comprehensive baseline procedure (Figure 5.18.4.3-1) with the following phases:

Phase 1: Single Access Initial State (Steps 1-10) - Media-Aware Application starts uplink streaming - Media Access Function requests streaming session establishment with Media Session Handler - Media Session Handler coordinates with Media AF - Media AF → PCF → SMF establishes transport session using single access - SMF retrieves ATSSS policy from PCF - Uplink transport and media streaming sessions established with Media AS

Phase 2: Access Availability Detection (Steps 11-14) - UE modem detects presence of multiple access networks - Physical layer performs radio access-specific functions (cell/AP detection, quality measurement) - UE OS informed of new access availability - Media Access Function receives notification about multiple access networks including access ID and type (per TS 23.503) - Media Access Function evaluates eligibility of new access for uplink media streaming - Media Access Function sends MultiAccessDetected notification to Media Session Handler with: - Access ID and type - QoS capability/path metrics (latency, throughput, loss rate) - Possible IP endpoints

Phase 3: Multi-Access Activation Trigger (Steps 15-16) - Media Session Handler analyzes event and decides on MA activation - Media Session Handler notifies Media-Aware Application about multi-access availability - Media Session Handler sends "Activate MA" request to Media AF via M5u API - Media AF consults PCF for ATSSS policy rules, delivery boosts, or QoS changes

Phase 4: Network Provisioning (Steps 17-20) - Media AF contacts PCF/SMF to: - Authorize dual access usage (PCC policy) - Allocate new QoS flows for added access path - Return updated transport/steering instructions - PCF requests SMF to allocate new QoS flows - SMF confirms upon acceptable conditions - Confirmation forwarded through PCF → Media AF → Media Session Handler

Phase 5: Transport Subflow Establishment (Steps 21-23) - Media Session Handler instructs Media Streamer to open transport subflow on new access (MP-TCP add_addr or MP-QUIC create PATH) - Media Streamer establishes new subflow based on confirmation - Media Streamer requests modem to open socket to newly detected access - Upon confirmation, Media Streamer notifies Media Session Handler that multi-access is active

Phase 6: Media Delivery Status Notification (Steps 24-25) - Media Access Function decides to switch to media delivery over multiple access networks - Decision shared with Media Session Handler - Media Access Function notifies Media Session Handler about multi-access delivery status at M11 reference point - For downlink streaming, uses Dynamic Status Information per TS 26.512 clause 13.2.6

Phase 7: Multi-Access Session Establishment (Steps 26-32) - Media Session Handler requests streaming session establishment with Media AF using multiple access - Media AF → PCF → SMF establishes transport session using multiple access networks - SMF retrieves policy from PCF and confirms - Confirmation forwarded through PCF → Media AF → Media Session Handler - Media Access Function establishes transport sessions with Media AS over multiple access networks at M4 - Media streaming session established between Media Access Function and Media AS over multiple access networks

Phase 8: Final Configuration (Steps 33-34) - Media Session Handler decides split ratios/steering policy - Media Session Handler updates Media Streamer and/or transport with scheduling/path selection rules (e.g., round-robin, split, weighted load) - Media-Aware Application informed that multi-access is active - Application can adjust encoder settings (e.g., send enhancement layers over Wi-Fi)

Key Assumptions

• 5GMS Client is unaware of UE ATSSS steering functionality
• Uplink 5G Media Streaming session set up over 3GPP access first before switching to MA PDU Session
• Applications typically unaware of multiple access networks unless explicitly informed via OS notification mechanisms
• Physical layer has no awareness of applications and does not provide direct signaling to application entities

Important Notes

• Support for QoS when PDUs conveyed over PDU Session belonging to network slice spanning non-3GPP access is unknown
• Support for PDU Session QoS when PDUs conveyed over non-3GPP access network is unknown
• MPTCP and MPQUIC link-specific multipath addresses may not be routable via N6
• MPTCP and MPQUIC link-specific multipath addresses can be the same
• No equivalent client API notification mechanism exists at M7 reference point for uplink media streaming or RTC as of Release 19

Technical Summary of S4-260255: Application-Layer Approaches for Multi-Access Media Delivery

Document Overview

This document is a partial Change Request (pCR) for 3GPP TR 26.804 that proposes updates to enable multi-access media delivery using application-layer approaches, specifically focusing on Common Media Client Framework (CMMF). It is intended to be merged with CR 0036 as part of the FS_AMD_Ph2 feasibility study.

Main Technical Contributions

1. Application-Layer Multi-Access Using CMMF (Clause 5.18.1.2)

1.1 Introduction to Upper Layer Approaches

The document introduces two application-layer methods for multi-access media delivery without requiring lower-layer support like ATSSS:

• Multipath transport protocols (MPTCP, MPQUIC) - requires implementation on both UE and Application Server
• CMMF-based approach - allows transport layer, network layer, and Application Server to remain agnostic of multi-access usage

Both approaches use multiple TCP/QUIC connections bound to different UE network interfaces, with traffic steering performed using existing UE and network functionality.

1.2 CMMF-Specific Implementation

Key characteristics: - Media encoded within CMMF bitstreams/transport objects made available at one or more service locations - No changes required to CMMF bitstream/transport object creation or network provisioning - No network/transport layer support (multipath protocols, ATSSS) required - Clients only need capability to communicate over multiple access networks and steer traffic - Operation over one access network largely independent of others

Deployment scenarios: - Scenario 1: Multiple service locations, each serving requests over specific access network - Scenario 2: Single service location delivering CMMF-encoded media across both access networks

In both scenarios, different CMMF-encoded representations (e.g., CMMF-A and CMMF-B) are requested over different access networks.

Traffic steering mechanism: - Multiple HTTP clients (one per access network) bound to different network interfaces - HTTP requests/responses automatically routed over bound interface/access network

1.3 Performance Results

The document includes experimental results showing: - Stable playback bitrate maintained despite WLAN degradation - Healthy playback buffer maintained throughout session - Seamless transition from WLAN to 5G cellular as WLAN quality degraded - Dynamic adaptation of download distribution across access networks based on connection quality

2. Architecture Mapping (Clause 5.18.3.1)

Updates to architecture mapping: - Expands upon architecture mappings from clause 5.19.3 - Media Access Client has capability to steer network traffic to different UE network interfaces/access networks - Can switch between access networks or use both simultaneously - When using CMMF, different CMMF representation/variation retrieved over each access network - CMMF decoder (sub-component of Media Access Client) recovers requested media resource

Key architectural point: - Reference point M4d defined over both 3GPP and non-3GPP access networks - Media Access Client architecture not normatively specified in 5GMS System - No changes to 5GMS architecture anticipated

3. High-Level Call Flow (Clause 5.18.4.1)

Procedure assumptions: - Media Player has functionality to stream from multiple service locations and/or across multiple access networks - Capabilities include: switching between service locations, concurrent use of multiple service locations, steering network traffic, concurrent use of multiple access networks - Configuration information available via Media Player Entry document or referenced documents - Content may be hosted at multiple service locations (inside or outside 5GMS System) - Content may be streamed over two or more access networks

Key procedure updates: - Step 1: Content available from two or more service locations - Step 11: Media Player determines multiple service location configuration and method of access - Step 15: Transport sessions established over different access networks based on UE connection and Media Player capabilities - Steps 17-18: Initialization information and media segments may be obtained over one or more access networks

4. Gap Analysis (Clause 5.18.5.1)

Identified open issues:

1. Existing downlink media streaming procedures in TS 26.501 don't address multi-access downlink media streaming using application-layer approaches
2. Media Access Client capability to use multiple access networks without lower-layer multipath support not addressed in 5GMS stage-3 specifications
3. CMMF procedures, protocols, and formats not defined for downlink media streaming over multiple access networks in TS 26.512

5. Candidate Solutions (Clause 5.18.6.1)

5.1 General Use Cases

Application-layer approaches may be used when: - 5GMSd Application Provider wants to influence how connections to multiple access networks are used - Using multiple access networks to access media hosted at different service locations - Transport/network-layer multi-access protocols (MPTCP, ATSSS, etc.) not supported by 5GMSd Client or AS

5.2 CMMF-Based Solution

Approach: - 5GMSd Client accesses/downloads CMMF-encoded media objects over multiple access networks simultaneously from single 5GMSd AS - Multiple different CMMF-encoded bitstreams/objects (representations/stripes) stored/cached within single logical 5GMSd AS - Different CMMF-encoded representation downloaded over each available access network - CMMF decoder yields original source content once enough information received

Key differentiator from other multi-access technologies: - Responsibility for setup, request, and steering rests with application layer (Media Player) - Multiple HTTP connections in parallel, each bound to different network interface - HTTP responses routed appropriately following standard network-layer/IP routing

Traffic steering policies: - Best-effort policy: Download as much CMMF-encoded content from each access network until decoder can successfully decode - Preference policy: Scheduler throttles requests over one access network to preference another

Proposed changes:

1. Define mapping of application-layer approaches into 5GMS procedures in TS 26.501 for multi-access network delivery using CMMF
2. Define procedures, protocols, and formats in Annex H of TS 26.512:
3. Specify media player requirements/recommendations for multi-access delivery using CMMF (including capability to select and steer network traffic)
4. Specify use of CMMF delivery conformance profile
5. Provide recommendations for constructing CMMF Media Player Entries for multiple access networks

6. Summary and Conclusions (Clause 5.18.7)

Recommendations:

1. For TS 26.501 - Add informative annex documenting:
2. Brief description of multi-access media delivery
3. Mapping of ATSSS architecture into 5GMS architecture

4. Mapping of application-layer approaches into 5GMS procedures for CMMF-based multi-access delivery

5. For TS 26.510 - Implement changes to Configuration Settings API and Dynamic Status Information API for application configuration and status information exchange

6. Future study should examine:

7. Whether future ATSSS work supports traffic splitting for GBR QoS Flows
8. Impact on splitting M4 media flows if transported as GBR QoS Flows
9. Impact on UE multi-path management, Dynamic Policy, Network Assistance, and network slicing procedures

10. Closer alignment with study on media delivery from multiple service endpoints/locations

11. For TS 26.512 - Update Annex H procedures, protocols, and formats to enable application-layer multi-access media delivery using CMMF

7. Overall Conclusions (Clause 6.18)

Stage-2 recommendations: - Add informative annex to TS 26.501 with multi-access media delivery description, ATSSS architecture mapping, and application-layer approaches mapping

Stage-3 recommendations: - Implement API changes in TS 26.510 - Update Annex H of TS 26.512 for CMMF-based multi-access delivery

Future work: - Monitor ATSSS specification work in TS 23.501 and TS 23.502 - Study impact on UE multi-access path management, Dynamic Policies, Network Assistance, and network slicing procedures

3GPP TR 26.804 Change Request - Network Assistance for Multi-Access Media Delivery

CR Details

• CR Number: 0036 rev 4
• Current Version: 19.1.0
• Category: B (addition of feature)
• Release: Rel-20
• Work Item: FS_AMD_Ph2

Summary

This CR addresses gaps in network assistance for multi-access media delivery scenarios, particularly for uplink streaming use cases when using ATSSS (Access Traffic Steering, Switching and Splitting). It extends the Rel-19 TR 26.804 by adding key issue descriptions, candidate solutions, and addressing identified gaps.

Main Technical Contributions

1. References and Abbreviations Updates

New References Added: - TS 26.512: 5G Media Streaming (5GMS) Protocols - TS 28.405: Quality of Experience (QoE) measurement collection - TS 24.193: ATSSS specifications

New Abbreviations: - PMF: Performance Measurement Functionality - RTT: Round-Trip Time

2. ATSSS Architecture Background (Clause 5.18.1.3.1)

Provides comprehensive summary of ATSSS architecture from TS 23.501, including:

Key Principles: - Multi-Access PDU Connectivity Service enabling simultaneous use of 3GPP and non-3GPP access networks - MA PDU Session with independent N3/N9 tunnels between PSA UPF and RAN/AN - Application flows at M4 and M5 reference points can utilize two different access networks

Policy and Rules: - UE receives ATSSS rules for uplink traffic distribution - UPF receives N4 rules for downlink traffic distribution - SMF configures both rule sets, potentially mapping from PCF PCC rules

QoS Support: - Same 5G QoS model applies to MA PDU Sessions - QoS Flow is access-agnostic with same network QoS across different access networks - QoS rules provided via one access apply to both 3GPP and non-3GPP access

Traffic Steering Mechanisms: - MPTCP (Multipath TCP): UPF provides MPTCP proxy functionality - MPQUIC (Multipath QUIC): UPF provides MPQUIC proxy functionality
- ATSSS-LL (Low-Layer): Steering based on IP layer and below

Steering Modes: - Active-Standby: Primary/backup access selection - Smallest Delay: Route based on lowest RTT - Load-Balancing: Split traffic across both accesses - Priority-based: Route to higher priority access - Redundant: Duplicate packets on both accesses

IP Address Allocation: - One IP address for MA PDU Session - Two MPTCP link-specific multipath addresses (one per access) - Two MPQUIC link-specific multipath addresses (one per access)

3. Performance Measurement Functionality (PMF) - New Clause 5.18.1.3.1A

Detailed description of PMF protocol from TS 24.193 for measurement assistance:

Measurement Assistance Information Includes: - IP address for PMF functionality in UPF - UDP ports for 3GPP and non-3GPP access measurements - List of QoS Flows for per-flow measurements

PMF Protocol Messages:

RTT Measurements: - PMF-Echo Request/Response messages exchanged between UE and UPF - Independent RTT measurements at both UE and UPF - Average RTT calculation per access type and QoS Flow

Packet Loss Rate (PLR) Measurements: - Downlink PLR: UPF sends PMF-PLR Count Request, counts transmitted packets, UE counts received packets, UPF calculates loss ratio - Uplink PLR: Reverse procedure initiated by UE - Average PLR calculation per QoS Flow and access type

Access Network Availability Reporting: - UE detects and reports access network availability/unavailability to UPF

UE Assistance Data: - Upon PCF authorization, UE can override ATSSS rule split percentages - PMF-UAD message informs UPF of UE-chosen uplink split - UPF may align downlink traffic distribution accordingly - PMF-UAT message terminates UE assistance operation

Traffic Duplication Control: - PMF-Suspend Duplication: UPF requests UE to stop redundant transmission (e.g., during congestion) - PMF-Resume Duplication: UPF requests UE to restart duplication

4. Key Issue Description - Network Assistance with Multi-Access (New Clause 5.18.1.4A)

Current Network Assistance Methods: - AF-based Network Assistance: Media Client requests assistance from Media AF, which interacts with PCF - ANBR-based Network Assistance: Based on UE modem and RAN signaling

Available Facilities: - Bit rate recommendation: Media Client requests estimated achievable bit rate from Media AF - Delivery boost: Media Client requests temporary bit rate increase

Identified Issues for Multi-Access: - Current procedures assume single access network - Unclear if assistance information is useful/sufficient for MA PDU Sessions - Lack of per-access detailed metrics in all cases - Configuration-dependent measurement/reporting coverage

5. Key Issue Objectives (Clause 5.18.1.5.2)

Dynamic Policy Questions: - Meaning of "activate dynamic policy with QoS requirements" for multi-access M4 flows - Feasibility of requesting QoS for specific access path subsets - Need for ApplicationFlowDescription enhancements to identify M4 flows over multiple accesses

Network Assistance Questions: - Sufficiency of current bit rate recommendation and delivery boost for multi-access - How Media Client uses bit rate recommendations to distribute M4 flows - Ability to request/receive assistance for specific access networks - Need for enhanced assistance information including: - Split recommendations across access networks (e.g., 30%/70%) - Split recommendations by media type (audio/video on different accesses) - Split recommendations by stream priority - Initial throughput with latency per access - Upcoming network conditions and handover information

6. Collaboration Scenario (New Clause 5.18.2.3)

Describes how UE determines use of MA PDU Sessions during media delivery through AF-based Network Assistance to improve QoS and QoE while leveraging multiple access paths.

7. High-Level Call Flow - Access-Specific Network Assistance (New Clause 5.18.4.3)

Comprehensive call flow with following phases:

Phase 1: Initial Media Delivery Over Single Access 1. Provisioning of 5G Media Streaming Session 2. Media-aware Application selects Media Player Entry 3. Acquire Service Access Information 4. Media Streaming over single access 5. QoE metrics collection and reporting

Phase 2: Multi-Access Activation 6. Media-aware Application subscribes to OS events for multiple access availability 7. UE OS/modem detects multiple access networks (using access availability reports per TS 23.501) 8. UE OS informs Media-aware Application 9. Media-aware Application expresses preference for multi-access at M4 (via Client API in TS 26.512 for downlink; no equivalent for uplink/RTC in Rel-19) 10-11. Media Access Function checks OS for multiple access availability 12. Media Access Function activates multi-access mode 13. Media Access Function notifies Media-aware Application of multi-access status (using Dynamic Status Information per TS 26.512 for downlink; no equivalent for uplink/RTC) 14. (Optional) Media Access Function notifies Media Session Handler

Phase 3: AF-Based Network Assistance Activation 15. Media-aware Application requests network assistance for initial bit rate recommendation, may include access type identification 16. Media Session Handler creates Network Assistance session with Media AF (M5) 17-18. Media Session Handler requests bit rate recommendation, includes access type information; Media AF calculates per-access recommendations 19. Media Access Function receives bit rate recommendations per access (e.g., 5 Mbps LTE, 8 Mbps Wi-Fi) 20. Media Access Function chooses optimal bit rate 21-22. Media delivery starts using multi-access with network assistance 23. MA PDU Session with AF-based Network Assistance established

Phase 4: Subscription to Bit Rate Recommendations 24. Media Session Handler subscribes for ongoing bit rate recommendations from Media AF (M5), may be access-specific 25. Media AF sends updated recommendations via MQTT notification (per TS 26.510) 26. Media AF notifies Media Access Function with BIT_RATE_RECOMMENDATION, embellished with access-specific information 27. Media Access Function adapts media delivery according to new bit rate 28. Media streaming continues with adapted bit rate

Phase 5: Delivery Boost Request 29. Media-aware Application detects degraded QoE (comparing with historic metrics using QMC framework per TS 28.405) 30. Media-aware Application requests delivery boost 31. Media Access Function sends boost request to Media Session Handler (using requestDeliveryBoost() per TS 26.510 for downlink; no equivalent for uplink/RTC) 32. Media Session Handler determines which access network needs boost 33-34. Media Session Handler requests Media AF for boost over specific access; Media AF invokes requestDeliveryBoost() API 35. Media Access Function receives boost confirmation (Boolean success/failure) 36. Media Access Function adjusts bit rate temporarily

Phase 6: Session Termination 37. Media Access Function ends Network Assistance Session 38. Media Session Handler destroys session (destroyNetworkAssistanceSession() operation) 39. Session continues without Network Assistance or ends

8. PMF-Based Network Assistance Call Flow (New Clause 5.18.4.4)

Alternative approach using PMF for network assistance:

Key Facilities: - Measurement of RTT and PLR per QoS Flow per access network - Configuration of uplink/downlink traffic distribution using PMF UE Assistance Data

Call Flow Steps:

Initial Setup: 1. 5G Media Delivery session established over MA PDU Session 2. Media-Aware Application requests PMF-based network assistance 3. Media Access Function forwards request to Media Session Handler 4. Media Session Handler requests UE OS to activate PMF 5. UE OS activates PMF Functionality

PMF Measurements: 6. PMF Functionality in UE and UPF perform calculations (RTT, PLR) 7-9. Calculated measurements reported through UE OS to Media Session Handler 10. Media Session Handler forwards to Media Access Function 11. Media Access Function forwards to Media-aware Application

Traffic Split Configuration: 12. Media-aware Application configures traffic split (percentage across 3GPP/non-3GPP for UL/DL) 13. Media Access Function requests UL traffic split at UE ATSSS Steering Functionality 14. UE ATSSS confirms successful configuration 15. Media Access Function requests DL traffic split via UE PMF Functionality using PMF UE Assistance 16. UE PMF requests DL distribution from UPF PMF 17. UPF PMF configures UPF ATSSS Steering Functionality 18. UPF ATSSS confirms to UPF PMF 19. UPF PMF confirms to UE PMF

Media Delivery with Configured Split: 20. Media Access Function forwards UL M4 content to UE ATSSS 21. UE ATSSS applies configured UL split 22. UE ATSSS delivers split content to UPF ATSSS across both accesses; UPF combines and forwards to Media AS 23. Media AS sends DL M4 content to UPF ATSSS 24. UPF ATSSS applies configured DL split 25. UPF ATSSS delivers split content to UE ATSSS 26. UE ATSSS combines DL content and forwards to Media Access Function

9. Gap Analysis (Clause 5.18.5.2.5)

Identified Gaps in AF-Based Network Assistance:

When using multi-access PDU sessions with ATSSS, current specifications (TS 26.501, TS 26.512, TS 26.510) do not clarify:

1. Access-Specific Assistance: Whether Media Client can request/receive Network Assistance specific to a given access network (e.g., 3GPP NR vs. Wi-Fi)

2. Per-Access Bit Rate Recommendations: How bit rate recommendations are obtained or boosts applied for different access networks when session spans multiple links

3. ATSSS Policy Interaction: How Network Assistance interacts with ATSSS steering/switching rules managed by PCF

Resulting Issues: - Media Client receives only session-level (aggregate) bit rate recommendation, not per-access insight - Delivery boosts applied at PDU Session level, not selectively to one access leg - Uplink media delivery cannot dynamically exploit multiple paths - No standardized signaling linkage between AF-based Network Assistance (M5) and ATSSS policy control (Npcf → Nsmf) - Full path-level detailed per-access metrics not provided in all cases

10. Candidate Solutions

10.1 AF-Based Network Assistance Solution (Clause 5.18.6.3)

Proposed Enhancements:

1. Media-Aware Application Level:
2. Subscribe to OS events for multiple access network availability
3. Receive information from UE OS about available access networks

4. Include access identification and type when requesting initial bit rate recommendation (M6)

5. Media Session Handler Level:

6. Include access identification and type in bit rate recommendation requests to Media AF (M5)
7. Subscribe to access-specific bit rate recommendations from Media AF (M5)
8. Determine which access network needs delivery boost upon request from Media-Aware Application (M6)

9. Request Media AF for network boost over specific access network (M5)

10. Media AF Level:

11. Report recommended bit rate parameters for each access network type to Media Session Handler (M5)
12. Provide notifications about bit rate recommendations over specific access networks (M5)

13. Notify Media Session Handler of network boost result for specific access network (M5)

14. Media Access Function Level:

15. Receive bit rate recommendations for different access networks (M11)
16. Choose optimum bit rate and operation point based on per-access recommendations

10.2 PMF-Based Network Assistance Solution (Clause 5.18.6.4)

Proposed Enhancements:

1. Request and Measurement Flow:
2. Media-Aware Application requests PMF-based network assistance via Media Access Function (M6/M7)
3. Media Session Handler receives PMF measurements from UE ATSSS Steering Functionality

4. Media Session Handler shares PMF measurements to Media-Aware Application via Media Access Function

5. Traffic Split Configuration:

6. Media-Aware Application configures traffic split (UL/DL) over different access networks at Media Access Function (M6)
7. Media Access Function configures UL traffic split at UE ATSSS Steering Functionality
8. Media Access Function requests DL traffic split configuration to UE PMF Functionality

11. Summary and Conclusions (Clause 5.18.7)

Key Findings: - Multi-access media delivery enables efficient content access over multiple access networks - ATSSS architecture impact on 5GMS examined, including application awareness and dynamic policy enhancements - MPTCP and MPQUIC link-specific multipath IP addresses not routable via N6 in current release - Traffic splitting for GBR QoS Flows not supported; if M4 flows use GBR QoS, ATSSS splitting not supported

Release 19 Recommendations (Already Adopted): 1. Informative annex added to TS 26.501 documenting multi-access media delivery and ATSSS-to-5GMS architecture mapping 2. Changes to Configuration Settings API and Dynamic Status Information API in TS 26.510 for multi-access configuration and status exchange

Release 20 Recommendations (From This CR): 3. Modifications to 3GPP specifications based on candidate solutions in clause 5.18.6.3 (AF-based) and 5.18.6.4 (PMF-based)

Affected Clauses

• Clause 2 (References)
• Clause 3.3 (Abbreviations)
• Clause 5.18.1.3.1 (ATSSS Architecture Background)
• Clause 5.18.1.3.1A (NEW - PMF Measurement Assistance)
• Clause 5.18.1.4A (NEW - Network Assistance Key Issue)
• Clause 5.18.1.5.2 (Key Issue Objectives)
• Clause 5.18.2.3 (NEW - Collaboration Scenario)
• Clause 5.18.4.3 (NEW - AF-based Call Flow)
• Clause 5.18.4.4 (NEW - PMF-based Call Flow)
• Clause 5.18.5.2.5 (NEW - Gap Analysis)
• Clause 5.18.6.3 (NEW - AF-based Candidate Solution)
• Clause 5.18.6.4 (NEW - PMF-based Candidate Solution)
• Clause 5.18.7 (Summary and Conclusions)

3GPP TR 26.501 Change Request - AF Requested Modification of Network Slices for UE

Administrative Information

• CR Number: 0003 rev 2
• Version: 19.0.1 → Rel-20
• Category: B (addition of feature)
• Work Item: FS_AMD_Ph2
• Source: Samsung Electronics Co. Ltd.

Reason for Change

TS 23.501 (Rel-19) introduced a new procedure for AF-influenced slice change for a UE. Document S4aI250082 addressed this topic in Rel-19, but SA4 MBS group decided to pursue this study topic in Rel-20 to complete network slicing features for 5G Media Streaming.

Summary of Changes

This CR proposes: 1. A brief description of the new procedure for AF-requested modification of Network Slice(s) for a UE as specified in TS 23.501 2. A key issue description related to media delivery for study in Rel-20

Technical Contributions

CHANGE-1: Updates to Clause 4.2.2 - Network Slicing for Specific Applications

4.2.2.1 Introduction

Minor editorial updates to existing text on network slicing procedures.

4.2.2.2 Network Slice Replacement Without Application Influence

Editorial title change from previous version.

4.2.2.3 AF-Requested Modification of Set of Network Slice(s) for a UE (NEW)

This new clause describes the procedure specified in TS 23.501 clause 5.15.5.2.2A:

Key Procedure Elements: - An authorized AF (directly or via NEF) may request the PCF to replace a certain S-NSSAI (Replaced S-NSSAI) with another S-NSSAI (Alternative S-NSSAI) from the UE subscription - The AF subscribes to notifications from PCF about the outcome of slice replacement - PCF sends slice replacement management information to AMF in access and mobility management policies - The slice replacement management policy includes: - Replaced S-NSSAI - Alternative S-NSSAI - Network Slice Replacement Type (indicating AF-requested replacement) - AMF performs slice management operations: - Removes Replaced S-NSSAI from Allowed S-NSSAI - Adds Replaced S-NSSAI to Rejected S-NSSAI via UE Configuration Update - Releases PDU sessions using Replaced S-NSSAI - Reports outcome to PCF, which notifies AF - Operator policies in PCF ensure UE is configured with URSP rule containing Alternative S-NSSAI - AF/NEF may later request termination of slice replacement to switch back to original slice - PDU Sessions are transferred as described in clause 4.2.2.1 during both forward and reverse transitions

CHANGE-2: New Clause 6.X - Key Issue on AF-Requested Slice Change for UE

6.X.1 Description

6.X.1.1 Identification and Usage of Alternate S-NSSAI

Context: - Describes procedure for AF-requested modification of Network Slice(s) for a UE - AF interacts with PCF to modify current network slice (Replaced S-NSSAI) with Alternate S-NSSAI - PCF interacts with AMF to facilitate slice modification and PDU session migration

Use Case Applicability: - Provides dynamic update of network slice used by UE - Preferable to 5GC-facilitated slice replacement (clause 4.2.2.2) for use cases requiring dynamic QoS treatment modification - Supports premium gaming QoS use case (clause 5.3.2) where application traffic migrates to appropriate slice under Media AF direction

Current Provisioning: - 5GMS Application Provider configures network slice information at 5GMS AF via M1 reference point using Provisioning API - TS 23.501 clause 5.15.5.2.2A states that how AF obtains Alternate S-NSSAI information is out of scope

Open Issues: 1. When and how does 5GMS AF decide to trigger the AF-requested modification procedure? 2. How does 5GMS AF obtain information about S-NSSAI to be replaced and Alternate S-NSSAI?

6.X.2 Candidate Solution

Overview: Describes procedure for temporary upsell treatment of M4 application flows to be carried over premium network slice.

Addresses Open Issues: 1. UE application makes upsell treatment request; network API request sent at M5 (e.g., user purchases gaming slice treatment for desired duration) 2. Media Delivery AF obtains Alternate S-NSSAI information from Media Application Service Provider

Assumptions: - Media Application Service Provider negotiates with MNO for both default/primary network slice and Alternate network slice

Procedure Steps:

Initial Setup (Steps 1-3): 1. Application Service Provider provisions Media Delivery session at Media AF via M1 using baseline downlink media delivery procedure (TS 26.501 clause 5.1), including Alternate S-NSSAI information 2. Media Delivery session setup with UE and 5G System components (TS 26.501 clause 5.1) 3. Media Access Function and Media AS perform media delivery at M4 using default/primary network slice

Upsell Treatment Activation (Steps 4-7): 4. User decides for temporary upsell treatment requiring dynamic QoS modification of M4 application flows 5. UE Application requests Media Session Handler for temporary upsell treatment at M6, including duration 6. Media Session Handler forwards request to Media AF at M5, including duration 7. Media AF requests PCF (directly if trusted AF, via NEF if untrusted) for Network Slice modification, replacing primary S-NSSAI with Alternate S-NSSAI per TS 23.501 clause 5.15.5.2.2a, including duration 8. PCF interacts with AMF to facilitate Network Slice modification per TS 23.501 clause 5.15.5.2.2a and TS 23.503 clauses 6.1.2.1 and 6.1.2.6; PCF ensures UE configured with URSP rule containing Alternate S-NSSAI; UE OS ensures use of Alternate S-NSSAI 9. Media Access Function and Media AS perform media delivery at M4 using Alternate S-NSSAI

Upsell Treatment Termination (Steps 10-14): 10. User decides to end upsell treatment 11. UE Application requests Media Session Handler to end upsell treatment at M6 12. Media Session Handler forwards request to Media AF at M5 13. Media AF requests PCF for Network Slice modification, replacing Alternate S-NSSAI with original primary S-NSSAI per TS 23.501 clause 5.15.5.2.2a 14. PCF interacts with AMF to revert to original Network Slice; PCF ensures UE configured with URSP rule containing primary S-NSSAI; UE OS ensures use of primary S-NSSAI 15. Media Access Function and Media AS perform media delivery at M4 using primary S-NSSAI

6.X.3 Conclusions

Identified Gaps: - Media Application Service Provider must provision Alternate S-NSSAI information required by 5G System Components - Media Aware Application must request Media Session Handler over M6 for initiating/terminating temporary upsell treatment - Media Session Handler must send request to Media AF over M5 for initiating/terminating upsell treatment

Proposed Normative Changes:

1. TS 26.501 (Stage-2) Modifications: - a. Modify domain model for dynamic policies (figure 4.0.6-2) to add Alternate S-NSSAI identifier property in Policy Template entity - b. Update clause 5.8.1 (Dynamic Policy based on Network Slicing for downlink): Update figure 5.8.1-1 call flow and add text describing design principles and procedure for AF-requested Network Slice replacement - c. Update clause 6.9.6 (Dynamic Policy based on Network Slicing for uplink): Update figure 6.9.6-1 call flow and add text describing design principles and procedure for AF-requested Network Slice replacement

2. TS 26.512 (Stage-3) Modifications: - a. Clause 4.8 (M6d UE Media Session Handling interface): Add procedure description for 5GMSd Aware Application requesting Media Session Handler for change of traffic treatment - b. Clause 5.8 (M6u UE Media Session Handling interface): Add procedure description for 5GMSu Aware Application requesting Media Session Handler for change of traffic treatment

3. TS 26.510 (Stage-3) Modifications: - a. Clause 8.7.3: Update PolicyTemplate resource data model to include Alternate S-NSSAI property - c. Clauses 5.2.7 and 5.3.3: Update Dynamic Policy provisioning and invocation interactions to describe interactions between Media Application Provider and Media AF, and Media Session Handler and Media AF - d. Clause 9.3.3: Update DynamicPolicy resource data model with additional property representing request from Media Session Handler to Media AF for different traffic treatment via AF-requested Network Slice modification

Updated Conclusions and Recommendations (Clause 8)

New Recommendation 4: To support the procedure for AF-requested modification of Network Slice(s) for a UE, adopt the following into media delivery specifications as described in clause 6.X.3: - a. TS 26.501: Update domain model for dynamic policies and procedures for Dynamic Policy based on Network Slicing (downlink and uplink) - b. TS 26.512: Add procedure descriptions for M6d and M6u for 5GMSd/5GMSu Aware Application requesting Media Session Handler for traffic treatment change - c. TS 26.510: Update PolicyTemplate and DynamicPolicy resource data models, and Dynamic Policy provisioning/invocation interactions

Change Request Summary: Multi-access Media Delivery - Additional Requirement

CR Metadata

• CR Number: 0033 rev 0
• Specification: TS 26.804 v19.1.0
• Category: C (functional modification of feature)
• Release: Rel-19
• Work Item: FS_AMD_Ph2 (Feasibility Study on Advanced Media Distribution Phase 2)
• Source: LG Electronics Inc.

Purpose and Rationale

This CR addresses a gap in multi-access media delivery when M4 media flows are transported using GBR QoS flows. The main issue is that the current 5G Media Streaming architecture (TS 26.501) lacks mechanisms to convey QoS-related information from non-3GPP access networks to 5GMS control plane entities. This prevents consistent QoS treatment across heterogeneous access networks (3GPP and non-3GPP) in multi-access scenarios.

Technical Contributions

1. Gap Analysis Enhancement (Clause 5.18.5.2.2)

Identified Gaps

Path Identification Limitations: - Current Dynamic Policy procedures cannot request policy treatment over specific access networks when M4 flows use multiple access networks - The IPPacketFilterSet parameters (sourceAddress and destinationAddress) in ApplicationFlowDescription only support IP addresses of the Multi-Access PDU Session - MPTCP and MPQUIC link-specific multipath addresses are not routable via N6, making them unsuitable for Dynamic Policy instantiation requests to 5GMS AF

GBR QoS Flow Constraints: - According to TS 23.501 clause 5.32.4, traffic splitting for GBR QoS Flows is not supported in Rel-18 ATSSS - If M4 media flows are transported as GBR QoS Flows, traffic splitting using ATSSS is not supported in this release - Future ATSSS specification updates need to be monitored

QoS Mapping Gap: - The 5G Media Streaming architecture (TS 26.501 Figure 4.1.1) lacks mechanisms or reference points to convey QoS information from non-3GPP accesses to 5GMS control plane/entities - No capability to compare whether QoS requirements for media streaming can be supported across 3GPP and non-3GPP accesses - Current TS 23.501 requires non-3GPP access to include Additional QoS Information, but this is outside ATSSS scope

NOTE: QoS mapping from non-3GPP access to 3GPP-based QoS profiles can facilitate GBR QoS flow support in multi-access scenarios

2. New Procedure: Multi-access Dynamic Policy with Non-3GPP QoS Mapping (Clause 5.18.X.X)

This CR introduces a new informative procedure for handling QoS mapping between non-3GPP and 3GPP access networks.

Procedure Steps

Initial Setup (Steps 1-4): 1. 5G Media Streaming session established over Multi-Access PDU Session with M4 flows over 3GPP access 2. Media Session Handler instantiates Dynamic Policy in 5GMS AF (per TS 26.501 clause 5.7.4), potentially including QoS specifications 3. 5GMS AF interacts with PCF (directly in Trusted DN or via NEF in external DN) to apply requested Dynamic Policy 4. M4 media flows transferred over 3GPP access with requested dynamic policy

Multi-access Setup (Step 5): - Multi-access media delivery session established using both 3GPP and non-3GPP access networks - 5GMS-Aware Application may or may not be aware of multi-access delivery

Non-3GPP QoS Mapping Procedure (Step 6): - 6a: UE collects QoS information from 3GPP access (e.g., QoS profile, GBR capability) - 6b: UE ATSSS steering functionality forwards 3GPP QoS information to Media Session Handler - 6c: Non-3GPP access node provides QoS-related information (e.g., DSCP) - 6d: UE ATSSS steering functionality forwards non-3GPP QoS information to Media Session Handler - 6e: Media Session Handler performs QoS mapping based on association between non-3GPP and 3GPP QoS characteristics (e.g., DSCP-QCI, DSCP-5QI mapping) - 6f: Media Session Handler updates mapped non-3GPP QoS parameters to 5GMS-Aware Application

Media Delivery over Non-3GPP Access (Step 7): - 7a: 5GMS-Aware Application determines media content for non-3GPP access delivery - 7b: Media playback initiated over non-3GPP access with requested QoS applied - 7c: M4 media streaming performed over non-3GPP access - 7d: M4 media flows delivered over non-3GPP access based on requested Dynamic Policy and mapped parameters

Continuation (Steps 8-9): 8. M4 media flows continue over 3GPP access 9. Media Session Handler modifies Dynamic Policy via 5GMS AF to apply to multi-access session

Key Technical Innovations

1. QoS Mapping Framework: Introduces UE-based QoS mapping between non-3GPP access characteristics (e.g., DSCP) and 3GPP QoS profiles (e.g., QCI, 5QI)

2. ATSSS Integration: Leverages UE ATSSS steering functionality as intermediary for QoS information exchange between access networks and Media Session Handler

3. Application-Level Awareness: Enables 5GMS-Aware Application to make informed decisions about media delivery over non-3GPP access based on mapped QoS parameters

4. Dynamic Policy Adaptation: Supports modification of Dynamic Policies to accommodate multi-access scenarios with heterogeneous QoS capabilities

Impact and Consequences

If Approved: Enables consistent QoS support for M4 media flows in multi-access media delivery scenarios, facilitating better steering/switching decisions and GBR QoS flow support across heterogeneous access networks.

If Not Approved: Consistent QoS support for M4 media flows cannot be achieved in multi-access media delivery, limiting the effectiveness of multi-access scenarios with GBR QoS flows.