S4-260043 - AI Summary

[FS_Energy_Ph2_MED] Energy-aware Streaming

Back to Agenda Download Summary
AI-Generated Summary AI

3GPP Technical Document Summary: Energy-aware Streaming (TR 26.942 CR 0010 rev 2)

Document Overview

This Change Request introduces energy-aware streaming capabilities to TR 26.942 as part of the FS_Energy_Ph2_MED work item. It is a Category B (feature addition) CR for Release 20 that addresses limitations in the current energy-aware streaming approach by making it access-independent while maintaining integration with 3GPP architecture.

Main Technical Contributions

Key Issue #7: In-band Signalling of Energy Consumed in Upstream Content Preparation and Distribution

Scope Definition

The contribution addresses two critical aspects of energy accounting:
- Scope: Defines boundaries of what energy consumption to measure in the media delivery chain
- Attribution: Determines how to assign energy costs across different stages and users

Energy Accounting Chain

The document proposes limiting scope to content distribution aspects, starting from:
1. Content encoding - Different codecs and encoder implementations have varying energy costs
2. Content packaging - Different packaging technologies have different energy costs
3. Origin hosting - Energy costs for keeping media segments available and serving them

Attribution Model for Multi-tier CDN

The contribution proposes a sophisticated attribution model:
- For every fan-out in multi-tier CDN, energy cost is divided among next tier destinations
- Maintains rolling average based on destinations served
- First requester bears full acquisition cost at a CDN node
- Subsequent requesters share acquisition cost fairly
- Time-dependent caching factor creates "opportunity cost" for cache availability
- Attribution divisor increments monotonically, decreasing per-requester cost until cache expiry

Integration Points

  • 5GMS AS: Included as final point in distribution chain where in-band energy costs can be inserted
  • 5G RAN/Core: Acknowledged as too complex for in-band embedding, but leverages SA2's Energy Information Function
  • Energy Information AF: Proposed to combine generic distribution energy information with 5G System-specific information, providing "value add" by sharing combined cost to Application Provider via M8 or R6

Solution #X: Energy-aware Streaming

Addressed Key Issues

The solution addresses:
- Key Issue #2: Energy-related monitoring and measurement
- Key Issue #4: Energy-related configuration by Application Service Provider
- Key Issue #5: Media Application Server Energy management
- Key Issue #6: Client-driven management of media delivery service energy optimization
- Key Issue #7: In-band signalling of upstream energy consumption

High-level Design Principles

  1. Access-agnostic approach: Integrate energy information into general media streaming services, not just 3GPP-specific
  2. Extensible framework: Create framework usable by different environments
  3. 3GPP integration: Combine general framework with 3GPP services
  4. Cross-organization collaboration: Encourage collaboration with other organizations

Functional Architecture

The solution defines a generic streaming workflow (Figure 7.X.2.1-1):

  1. Content Production: Produced content with associated static/dynamic energy information
  2. Encoding: Encoder aggregates upstream energy info plus encoding energy (per variant, bitrate, etc.)
  3. Distribution Chain: Aggregated energy information propagated through distribution, accumulating at each stage
  4. Metadata Integration: Energy information included as metadata in media streaming data
  5. Client Access: Media client receives energy information regardless of delivery network (3GPP or other)

Core Functional Aspects

  • Propagate energy-related information downstream within media streaming workflow
  • Make energy information accessible at individual media stream level
  • Allow aggregation/accumulation at specific nodes in delivery path
  • Enable operational decision-making based on energy information
  • Support reporting to servers (with or without client consumption data)
  • Enable content selection based on energy metrics

Assignment and Aggregation of Energy Usage

  • Media resources include record of consumed energy up to current point in delivery chain
  • Information scaled to number of users assigned to resource
  • Scaling based on predictions (e.g., extrapolating from previous segment requests)
  • Energy metrics assignable to entire asset or subsets (variant, segment, time range)

Common Repository of Energy-related Metrics

Proposes creating a registry/repository/catalogue for energy-related metrics:
- Similar to MP4RA or DASH-IF identifiers
- Each metric assigned a key (4CC code or URN)
- Well-defined metrics with specification references
- Allows evolution without framework changes

Hypothetical Examples:
- Greening of Streaming: urn:org:gos:energyindex:2025 or 4CC 'eeix' for average aggregated energy per second
- French AFNOR: urn:org:afnor:carbonindex:2025 or 4CC 'eecx' for average aggregated carbon per second

In-band Carriage Mechanisms

Multiple mechanisms proposed for carrying energy metrics:

  1. Metadata tracks: For dynamic information, including Addressable Resource Index (ARI) tracks (ISO/IEC 23009-1)
  2. CMCD (Common Media Client Data): Custom energy metric keys in reporting mechanism
  3. CMSD (Common Media Server Data): Custom energy metric keys assigned to each resource/segment
  4. SAND information: CMCD/CMSD-equivalent via SAND messages (ISO/IEC 23009-5)
  5. DASH metrics: Similar to CMCD for reporting
  6. Events and Event Streams: Carrying energy information (ISO/IEC 23009-?)
  7. Streaming presentation manifest: Energy information in DASH MPD or HLS playlists
  8. Service Information and API calls: Operational information via MPEG DASH APIs

Carriage in Streaming Presentation Manifest

Specific proposals for DASH MPD:
- Energy information assigned to each resource
- Assignment to individual components:
- Content (aggregate consumption)
- Adaptation Set
- Representation
- Segment
- Service Locations (normalized to bitrate)
- Labels: Describe energy information for user-based selection
- Dedicated Energy descriptor: Similar to Accessibility descriptor for regulatory requirements
- Combination rules: When information available at multiple levels, combine appropriately (e.g., CDN efficiency + encoding energy)

Usage of Energy Information

In Media Client:
- Expose energy information to user and/or application
- Enable content selection based on energy metrics
- Select service locations based on energy information
- Report aggregated metrics to reporting server (DASH Metrics or CMCD)
- Optionally add client energy consumption to aggregated metrics

In Other Delivery Chain Functions:
- Use in-band information for operational and reporting purposes

Integration into 5G System

Specific integration points:
- CDN mapping: CDN may be Media AS
- Service locations: CDN1/CDN2 mapped to different service locations for energy optimization
- Content Steering: Steer clients to energy-efficient delivery
- Reporting options: Include or exclude UE consumption
- Media AS/EIF integration: Media AS collects information from Media AF/EIF to insert energy metrics into streaming metadata

Procedures

General Procedures (Figure 7.X.3.1-1)

Call flow steps:

  1. Encoder:
  2. Processes ingested media
  3. Processes energy information (production)
  4. Sends encoded media to Packager
  5. Shares accumulated energy info with Packager

  6. Packager:

  7. Receives encoded media
  8. Packages media
  9. Sends packaged media to Manifest Generator
  10. Shares accumulated energy info with Manifest Generator

  11. Manifest Generator:

  12. Receives packaged media
  13. Uploads media and manifest to CDN1 and CDN2
  14. Adds energy info for each media component (Adaptation Set, Representation, etc.)
  15. Adds energy information for each service location/CDN

  16. Delivery:

  17. Delivers manifest to Media Client
  18. Media Client requests media based on energy information from CDN1/CDN2

  19. Reporting:

  20. Media client reports aggregated energy information to Reporting Server

Integration with 5G Media Streaming

Based on 5GMSd architecture (TS 26.501):
- References Solution #5 architecture (clause 7.6.3.2)
- Media Stream Handler (in UE) is decision-making function
- Receives energy information directly from 5GMSd AS via in-band information (manifest and/or CMSD)
- Manifest differentiates energy information by service location and other parameters
- Note: Does not use Energy Information Collector from Solution #5

Status: Detailed steps marked as "To be completed" - FFS

Implementation Roadmap

Short-term Proposals

  1. Support addition of Energy-related information in manifest as static information
  2. Define aggregation rules for client
  3. Support reporting through 5GMS mechanisms (DASH metrics, in-band client reporting)
  4. Engage stakeholders to define proper metrics
  5. Extend standards (MPEG-DASH, SVTA, CTA WAVE) and reference implementations (dash.js)

Mid-term Proposals

  1. Study dynamic energy-related information distribution (downlink via in-band data/metadata tracks, uplink)
  2. Continue stakeholder engagement for metrics definition
  3. Continue standards extensions and reference implementation updates

Related Specifications

This CR is related to:
- TR 26.952 CR 0003
- TR 26.952 CR 0004
- TR 26.952 CR 0005

Key Open Issues

  • Detailed 5G System integration procedures (marked FFS)
  • Dynamic energy information collection mechanisms (mid-term study)
  • Specific metric definitions (requires stakeholder engagement)
  • Client implementation considerations (no known implementations yet)
Document Information
Source:
Qualcomm Germany
Type:
CR
For:
Endorsement
Original Document:
View on 3GPP
Title: [FS_Energy_Ph2_MED] Energy-aware Streaming
Agenda item: 8.5
Agenda item description: FS_Energy_Ph2_MED (Study on Media energy consumption exposure and evaluation framework Phase 2)
Doc type: CR
For action: Endorsement
Release: Rel-20
Specification: 26.942
Version: 19.0.0
Related WIs: FS_Energy_Ph2_MED
CR number: 10.0
CR revision: 2.0
CR category: B
CR: 10.0
Spec: 26.942
Contact: Thomas Stockhammer
Uploaded: 2026-02-03T16:05:48.237000
Contact ID: 60397
Revised to: S4-260342
TDoc Status: revised
Is revision of: S4-252095
Reservation date: 30/01/2026 10:17:36
Agenda item sort order: 29