[FS_Energy_Ph2_MED] Energy-aware Streaming
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.
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
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
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
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
The solution defines a generic streaming workflow (Figure 7.X.2.1-1):
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
Multiple mechanisms proposed for carrying energy metrics:
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)
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
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
Call flow steps:
Shares accumulated energy info with Packager
Packager:
Shares accumulated energy info with Manifest Generator
Manifest Generator:
Adds energy information for each service location/CDN
Delivery:
Media Client requests media based on energy information from CDN1/CDN2
Reporting:
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
This CR is related to:
- TR 26.952 CR 0003
- TR 26.952 CR 0004
- TR 26.952 CR 0005