# 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**:
   - Processes ingested media
   - Processes energy information (production)
   - Sends encoded media to Packager
   - Shares accumulated energy info with Packager

2. **Packager**:
   - Receives encoded media
   - Packages media
   - Sends packaged media to Manifest Generator
   - Shares accumulated energy info with Manifest Generator

3. **Manifest Generator**:
   - Receives packaged media
   - Uploads media and manifest to CDN1 and CDN2
   - Adds energy info for each media component (Adaptation Set, Representation, etc.)
   - Adds energy information for each service location/CDN

4. **Delivery**:
   - Delivers manifest to Media Client
   - Media Client requests media based on energy information from CDN1/CDN2

5. **Reporting**:
   - 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)