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.