3GPP TR 26.942 CR 0021 rev 2 - Media Application Service Model

Overview

This Change Request introduces a comprehensive Media Application Service model to TR 26.942 for the FS_Energy_Ph2_MED study item. The CR establishes a common baseline understanding of how Application Services interact with the 5G System to exchange media over the User Plane, providing conceptual models for different media service types.

Main Technical Contributions

1. Generalised Media Application Service Model (Clause 4.2.2.6.2)

The CR defines a foundational model describing media delivery sessions over the 5G System User Plane:

Key Characteristics:

• Service Data Flows: Media delivery sessions comprise one or more Service Data Flows traversing the User Plane between Media Client and Media AS at reference point M4
• Directionality: Media content may flow in downlink and/or uplink directions
• Flow Multiplexing: Multiple Application Data Flows may be multiplexed onto a single Service Data Flow (IP 5-tuple) or mapped to unique Service Data Flows

Examples Provided:

• MPEG-DASH: Independent HTTP/1.1 sessions per Adaptation Set to avoid head-of-line blocking, each on separate TCP connections (distinct Service Data Flows)
• CMMF-based DASH: Coded object requests raced over independent HTTP connections to multiple diverse service locations
• Split-rendered RTC: Multiple SRTP sessions for different media types, with Application Data Flows potentially multiplexed or separated

Complex Session Scenarios:

• Multiparty RTC sessions via RTC AS or peer-to-peer (when 5G System policy allows)
• Multiple Media Clients communicating as peers or via intermediate Media AS
• Note: Peer-to-peer Service Data Flow energy consumption not visible in Media AS application logs

Dynamic Behavior Characteristics:

1. Service Location Diversity: Different Service Data Flows may target different service location endpoints during a session
2. Concurrent Service Locations: Multiple service locations may be used in parallel (e.g., CMMF)
3. Server Deployment Variability: Each service location endpoint may be provided by different deployed servers with different energy consumption profiles
4. PDU Session Mapping: Service Data Flows may map to one or several parallel PDU Sessions depending on active service locations and UE Route Selection Policy (URSP)
5. Network Slice Diversity: PDU Sessions may traverse different logical network slices and/or Data Networks based on URSP
6. Multi-Access Support: PDU Sessions may be Multi-Access PDU Sessions, transparently traversing different Access Networks
7. Flow Migration: Service Data Flows may migrate between PDU Sessions due to UE mobility and/or gNodeB mobility (e.g., NTN)

Energy Consumption Implications:

• Dynamic Nature: Energy consumption may change dynamically during media delivery sessions, especially with edge computing, UE mobility, and service location switching
• Incomplete EIF Picture: User Plane network energy information from EIF (clause 4.2.2.3) doesn't account for:
• Energy consumed north of UPF (especially Media Application Server)
• Energy consumed south of gNodeB (especially UE)

2. 5GMS Application Service Model (Clause 4.2.2.6.3)

Based on TS 26.501 reference architecture, the CR defines separate conceptual models for downlink and uplink media streaming.

5GMSd (Downlink) Conceptual Model:

| Concept | Description | |---------|-------------| | 5GMSd AS instance | (Edge) 5GMSd AS instance in deployment | | Content Hosting Configuration | Corresponds to single Provisioning Session in 5GMSd AF; may be present in multiple (Edge) 5GMSd AS instances | | Distribution Configuration | Models a service location exposed by (Edge) 5GMSd AS instance | | Downlink media streaming session | Models session spanning one or more content items | | Service Data Flow | HTTP connection at reference point M4d described by IP 5-tuple | | Application Data Flow | Series of media segment download requests at M4d; multiple HTTP requests may be multiplexed onto same HTTP connection (serial or parallel) |

5GMSu (Uplink) Conceptual Model:

| Concept | Description | |---------|-------------| | 5GMSu AS instance | (Edge) 5GMSu AS instance in deployment | | Content Publishing Configuration | Corresponds to single Provisioning Session in 5GMSu AF; may be present in multiple (Edge) 5GMSu AS instances | | Contribution Configuration | Models a service location exposed by (Edge) 5GMSu AS instance | | Uplink media streaming session | Models session spanning one or more content items | | Service Data Flow | HTTP connection at reference point M4u described by IP 5-tuple | | Application Data Flow | Series of media segment upload requests at M4u; multiple HTTP requests may be multiplexed onto same HTTP connection |

Visibility and Association:

• Finest Granularity: Service Data Flow (HTTP connection at M4) is finest level visible to 5GMS AS
• Individual Application Data Flows: Not easily distinguishable when multiplexed on same Service Data Flow using HTTP
• Session Association: Service Data Flows associated with media streaming session via media delivery session identifier conveyed as HTTP request header (per TS 26.512 clause 6.2.3.6)
• Configuration Association: Service location (HTTP authority and leading URL path elements) enables HTTP request association with Distribution Configuration

3. RTC Application Service Model (Clause 4.2.2.6.4)

Based on TS 26.506 reference architecture, the RTC model has a simpler structure than 5GMS.

RTC Conceptual Model:

| Concept | Description | |---------|-------------| | RTC AS instance | (Edge) RTC AS instance in deployment | | Media Function Configuration | Corresponds to single Provisioning Session in RTC AF; may be present in multiple (Edge) RTC AS instances | | RTC session | Models set of RTP sessions comprising a WebRTC session | | Service Data Flow | UDP association at reference point RTC-4 described by IP 5-tuple; one or more Application Data Flows may be multiplexed | | Application Data Flow | SRTP packets sharing same Synchronisation Source (SSRC) value in packet headers |

Visibility and Association:

• Finest Granularity: Application Data Flow is finest level visible to RTC AS
• SSRC Visibility: When multiple SRTP streams are multiplexed on same Service Data Flow, SSRC field remains visible in unencrypted RTP header
• Session Association Limitation: In Release 19, no media delivery session identifier conveyed in RTP header, so individual Service Data Flows cannot be associated with an RTC session by RTC AS
• Configuration Association: Service Data Flows could be associated with Media Function Configuration if different service location (IP 3-tuple) is exposed per configuration
• Note: Different service location endpoints may be desirable to avoid service level pollution between RTC sessions from different RTC AF Provisioning Sessions

References Added

• [26512]: 3GPP TS 26.512: "5G Media Streaming (5GMS); Protocols"

Scope and Application

The introduction (clause 4.2.2.6.1) clarifies that these models establish a common baseline understanding for how Application Services interact with the 5G System. Candidate Solutions in the Technical Report may reference one or more of these models as applicable.

3GPP TR 26.942 CR0022r2: Application Server Energy Information

Change Request Overview

Type: Category B (Addition of Feature)
Release: Rel-20
Work Item: FS_Energy_Ph2_MED
Source: BBC, Orange

This CR introduces a new Candidate Solution for reporting energy consumption of Application Servers in the Data Network as part of end-to-end service chain energy monitoring.

Key Issue Mapping

This Candidate Solution addresses:

• Key Issue #2: Energy-related monitoring and measurement, specifically for Application Servers instantiated in the Data Network
• Key Issue #1: Energy-related information exposure to Media Session Handler for energy-efficient optimization

Main Technical Contributions

Functional Description

The solution recognizes that total energy consumption for application services must account for: - 5G System energy (5G Core and RAN) via Energy Information Function - Application Server energy in the Data Network (focus of this solution) - UE energy consumption

Key principle: Application Servers exist in the Data Network and are not Network Functions, therefore outside the scope of the Energy Information Function and must be accounted for separately.

Energy Reporting Granularities

The solution identifies critical granularities for energy optimization:

1. Per Service Location:
2. Enables steering application sessions to different service locations based on energy costs

3. Supports aggregated view across multiple (Edge) Application Server instances hosting the same service location

4. Per Service Data Flow:

5. Application Server has visibility of Application Data Unit bytes transferred (uplink/downlink)
6. Service Data Flows identified by 3-tuples or 5-tuples
7. Can also be identified by DNS host name (e.g., TLS client "hello" message)

Important Limitation: Application Servers cannot report energy consumption per UE (no visibility of UE identities), but the Energy Information AF can perform reverse IP address lookup in 5G Core for per-UE routing.

AS Energy Report Structure

The solution proposes a comprehensive AS Energy Report with the following baseline parameters:

Core Parameters

• AS instance identifier: Unique identifier across all Data Networks
• Timestamp: Start of energy consumption sampling period
• Sample period: Duration of the sample
• Energy consumed: Total energy during sampling period
• Environmental cost of energy supply: (Optional) CO₂ equivalent emission per unit energy, with breakdown by source if multiple sources

Application Data Flow Parameters

For each active Application Data Flow: - Service Data Flow description: IP 5-tuple identifying client and Application Server endpoints - Uplink data volume: Total Application Data Units delivered to AS instance - Downlink data volume: Total Application Data Units delivered from AS instance - AS host name: (Optional) Application Server host name for UE connection - Application session identifier: (Optional) Unique identifier for application session - Configuration identifier: Unique identifier for configuration in logical Application Server - Service location identifier: (Optional) Identifier for service location exposed by AS instance

Energy Attribution Model

The solution proposes a proportional attribution model: - Total energy consumption measured over sampling period - Bytes transferred per Service Data Flow metered during same period - Average energy attributed to Service Data Flows proportionally to data volume

Supported Aggregations

The raw information enables multiple aggregation views:

1. Per Service Data Flow: Combine with network energy information from EIF
2. Per UE: Via reverse IP lookup by authorized recipients (e.g., Energy Information AF)
3. Per Data Network/Network Slice: Via client IP address analysis
4. Per Media Streaming Session: Using media delivery session identifier
5. Per Virtual Host: Using configuration identifier and canonical domain name
6. Per Service Location: Using service location identifier
7. Per Content Hosting Configuration/Provisioning Session: Aggregate across all Edge AS instances

Architecture Integration

The solution integrates with the Energy Information AF architecture (from Clause 7.6) via reference point E3, enabling: - Periodic AS Energy Reports from Application Server to Energy Information AF - Generic procedure realization (step 13 in generic procedure, step 19 in 5GMS procedure)

System-Specific Mappings

5GMS System

• Content Hosting Configuration identifier maps to Provisioning Session
• Distribution Session identifier maps to canonical host name
• Media delivery session identifier for longitudinal analysis
• Correlation with QoE metrics reports (TS 26.512)

RTC System

• RTC AS Media Function configuration identifier maps to Provisioning Session
• Support for in-band energy-related information extraction from media

Gap Analysis

• AS Energy Report is entirely new for Release 19
• No service-based interface currently defined at reference point E3
• Energy Information AF is also new, requiring new interface specifications

Proposed Normative Work

Stage 2 Requirements

1. Generic AS Energy Report specification:
2. New stage 2 Technical Specification
3. Service operations for subscription and notification via E3

4. Based on generic architecture from Clause 7.6.2.2

5. 5GMS instantiation (TS 26.501):

6. Map generic properties to 5GMS concepts

7. Extensions for in-band energy information from M2d (downlink) and M4u (uplink)

8. RTC instantiation (TS 26.506):

9. Map generic properties to RTC concepts
10. Extensions for in-band energy information from RTC AS Media Function

Stage 3 Requirements

1. Generic data structures:
2. New stage 3 Technical Specification

3. Service-based interface definitions for E3

4. 5GMS extensions (TS 26.512):

5. 5GMS AS Energy Report data structures

6. RTC extensions (TS 26.113):

7. RTC AS Energy Report data structures

Additional References

• TS 26.512: 5G Media Streaming (5GMS); Protocols
• TS 26.113: Real-Time Media Communication; Protocols and APIs

Design Principles

• Raw information provision: No preconceived usage patterns, enabling flexible downstream processing
• Privacy considerations: Care required to avoid exposing identifiable data (client IP, GPSI, SUPI) to unauthorized consumers
• Equal attribution assumption: Energy per byte during sampling period for simplified calculation
• Correlation support: Common filters (Service Data Flow, application session identifier) enable correlation across EIF, AS, and UE data sets

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)

Summary of 3GPP Technical Document S4-260053

Document Overview

This is a Category C (functional modification) Change Request (CR 0031, revision 1) to TR 26.804 version 19.1.0, addressing Work Topic #2a on Common server- and network-assisted streaming under the FS_AMD_Ph2 study item. The CR proposes to merge with CRs 0032 and 0037.

Main Technical Contributions

1. References Update (Clause 2)

Addition of new normative reference: - [X3] SVTA1108: "CMSD to Enhance Media Streaming: A White Paper" from SVTA organization - Provides industry perspective on CMSD usage and benefits

2. Common Media Server Data (CMSD) Overview (Clause 5.25.1.4)

Core CMSD Functionality

• CMSD provides key-value pairs for information flow about origin and intermediary client states
• Clients can be intermediary servers or players
• Specific focus on the mb parameter (maximum suggested bitrate):
• Sent by server via CMSD response headers
• Provides server-recommended upper bound for player's video bitrate selection

Application to In-Band QoS Signaling

The CR identifies CMSD as a candidate technology for in-band QoS signaling at application layer, with relevant parameters from CMSD-Dynamic header: - currentBitrate - bufferLevel - playbackPosition - throughputEstimate

Identified Limitations

Protocol Stack Constraints: - CMSD operates at HTTP layer - Network elements at lower protocol stack levels (e.g., routers with rate limiting) cannot interpret HTTP-level CMSD - More suitable for application servers than network infrastructure elements - Cannot be applied generically to non-streaming traffic types

Content-Specific Nature: - CMSD data tightly coupled to media content and server-client connection - Parameters like throughputEstimate and bufferLevel are client-specific and presentation-specific - Not applicable to generic network link characterization - Study will investigate whether more generic network connection information is needed for in-band QoS signaling

3. Detailed CMSD Specification (Annex C.2)

CMSD Headers and Keys (Table C.2-1)

Comprehensive mapping of CMSD headers with their associated keys and descriptions:

| Header | Keys | Purpose | |--------|------|---------| | CMSD-Static | codec, resolution, duration, encodedBitrate | Static media object information | | CMSD-Dynamic | currentBitrate, bufferLevel, playbackPosition, throughputEstimate | Session-variable information | | CMSD-Cache | cacheStatus, cacheHitRatio, cacheExpiration | Cache status information | | CMSD-Error | errorCode, errorDescription | Error reporting | | CMSD-Quality | videoQuality, audioQuality, qualityAdjustments | Quality metrics | | CMSD-User | userID, sessionID, userPreferences | User-specific data | | CMSD-Session | sessionStartTime, sessionDuration, sessionID | Session information | | CMSD-Event | playbackStart, pause, resume, stop | Session events | | CMSD-Performance | serverResponseTime, networkLatency, throughput | Performance metrics | | CMSD-Content | contentID, contentType, contentDuration | Content metadata |

SVTA White Paper Findings

Reference to SVTA white paper [X3] demonstrating: - Experimental validation of CMSD benefits across delivery chain (origin servers to players) - Improvements in: - Latency reduction - Startup time - Quality of Experience (QoE)

4. dash.js Reference Implementation

Implemented CMSD Parameters

The dash.js reference client implements a subset of CMSD parameters:

1. CMSD mb (Maximum Suggested Bitrate) - Server Behavior: Sends mb in CMSD response headers as recommended upper bound - Client Implementation: - Treats mb as hard ceiling for ABR bitrate selection - When enabled (abr.applyMb = true): - Avoids selecting bitrates higher than mb - Immediately throttles down if currently playing above mb - Maintains upper bound until new mb received or playback ends - Benefits: - Prevents over-aggressive ABR decisions - Reduces oscillations from bandwidth overestimation - Leverages server's global visibility for client guidance

2. CMSD etp (Estimated Throughput) - Server Behavior: Provides server-side throughput estimate (typically measured at response start) - Client Implementation: - Integrates into ABR logic via weighting mechanism - abr.etpWeightRatio defines server vs. client estimate influence - Example: 0.5 = 50% server estimate + 50% client estimate - Can influence initial bitrate selection during manifest load - Benefits: - Server-side estimates more accurate (especially for low-latency/chunked-transfer scenarios) - Reduces ABR oscillation/"ping-pong" from noisy client measurements - Produces smoother bitrate choices and fewer stalls - Validated by CMSD studies

Technical Implications

The CR establishes CMSD as a viable application-layer mechanism for server-assisted streaming optimization while clearly identifying its architectural constraints for network-layer QoS signaling. The inclusion of dash.js implementation details provides concrete validation of CMSD's practical benefits in production environments.

3GPP TR 26.942 CR 0024 Rev 5 - Solution 5 Update for Energy Information Exposure

General Information

Title: [FS_Energy_Ph2_MED] Solution 5 update
Work Item: FS_Energy_Ph2_MED
Release: Rel-20
Category: F (Correction)
CR Revision: 5

Purpose of Change

This CR provides corrections and updates to Candidate Solution 5 in TR 26.942, focusing on: - Correcting procedures in clauses 7.6.3.1 and 7.6.3.2 to align with TS 23.501 and TS 29.566 - Reformatting according to new principles for documenting Candidate Solutions - Adding missing normative references

Main Technical Contributions

1. References Update (Clause 2)

Added three new normative references: - TS 26.510: Media delivery; interactions and APIs for provisioning and media session handling - TS 26.512: 5G Media Streaming (5GMS); Protocols - TS 26.113: Real-Time Media Communication; Protocols and APIs

2. Functional Description Enhancements (Clause 7.6.1A)

Clarified scope and objectives: - Solution addresses exposure of energy-related information from Media AS to UE or Media AF - Demonstrates integration into 5GMS architecture - Enables UE or 5GMS AF to optimize environmental impact - Explicitly states this is a generic architecture for reuse, not specific optimization strategies - Energy information exposure controlled by Application Service Provider using Energy Information Exposure Specification

3. New Collaboration Scenarios Section (Clause 7.6.1B)

Added explicit statement that solution applies to all collaboration scenarios requiring access to energy-related information from: - UE - Application Server - EIF (Energy Information Function)

4. Generic High-Level Procedures Update (Clause 7.6.3.1)

Major restructuring of procedure flow:

Provisioning Phase (Steps 1-4)

1. Application Service Provider provisions Energy Information AF with Energy Information Exposure Specification
2. Energy Information AF subscribes to NF Energy Information from EIF (E12 reference point)
3. EIF responds with NF Energy Information report
4. Energy Information AF configures and subscribes to AS Energy Information from AS (E3 reference point)
5. AS responds with most recent AS Energy Information report

UE-Initiated Phase (Steps 5-11)

1. UE Application creates energy information collection context with Energy Information Collector (E6 reference point)
2. Energy Information Collector requests UE Energy Information collection configuration from Energy Information AF (E5 reference point), including Application Identifier
3. Energy Information Collector subscribes to Network Energy Information from Energy Information AF with Service Data Flow descriptions and Session Identifier
4. Energy Information AF processes NF and AS Energy Information reports
5. Energy Information AF exposes processed Network Energy Information to Energy Information Collector
6. Energy Information Collector collects additional UE Energy Information from UE functions
7. Energy Information Collector processes UE-related Energy Information

Repetitive Reporting Phase (Steps 12-18)

1. EIF exposes NF Energy Information report to Energy Information AF
2. AS exposes AS Energy Information report to Energy Information AF
3. Energy Information AF processes received reports
4. Energy Information AF exposes processed Network Energy Information to Energy Information Collector
5. Energy Information Collector receives additional UE Energy Information
6. Energy Information Collector processes UE-related Energy Information
7. Energy Information Collector exposes energy-related information to UE Application

Context Modification Phase (Steps 20-23)

1. UE Application informs Energy Information Collector of context modification with new Service Data Flow filters
2. Energy Information Collector updates subscription with Energy Information AF
3. Energy Information AF updates subscription with EIF
4. Energy Information AF updates subscription with AS

5. 5GMS-Specific Procedures Update (Clause 7.6.3.2)

Comprehensive restructuring aligned with 5GMS architecture:

Provisioning Phase (Steps 1-4)

1. 5GMS Application Provider provisions 5GMS AF via M1, including Energy Information exposure configuration
2. Energy Information AF subscribes to NF Energy Information from EIF with Application Identifier, requesting immediate report
3. EIF responds with NF Energy Information report
4. Energy Information AF subscribes to AS Energy Information from 5GMS AS with Application Identifier
5. 5GMS AS responds with most recent AS Energy Information report

Media Session Initiation Phase (Steps 5-15)

1. 5GMS-Aware Application initiates media delivery session with flag enabling energy information collection
2. Media Session Handler obtains Service Access Information including Energy Information AF details
3. Media Session Handler creates energy information collection context in Energy Information Collector
4. Energy Information Collector requests UE Energy Information collection configuration from Energy Information AF
5. Response includes UE Energy Information collection configuration and subscription endpoint
6. Energy Information AF processes NF and AS Energy Information reports
7. Energy Information AF exposes processed Network Energy Information report to Energy Information Collector

NOTE 1 added: Explains that initial reports are not UE-specific but describe total energy consumed by all consumers (Application Identifier-based or AS service location-based)

1. Energy Information Collector subscribes to UE Network Energy Information from Media Stream Handler (M11)
2. Media Stream Handler responds with UE Network Energy Information report
3. Energy Information Collector processes Network and UE Energy Information
4. Energy Information Collector exposes aggregated Energy Information to Media Session Handler and Media Stream Handler
5. Media Session Handler provides available Media Entry Points to 5GMS-Aware Application, including Energy Information

Media Entry Point Selection (Steps 16-17)

1. 5GMS-Aware Application selects Media Entry Point
2. 5GMS-Aware Application invokes Media Stream Handler with selected Media Entry Point

Parallel Energy Information Reporting (Steps 18-26)

1. EIF exposes NF Energy Information report to Energy Information AF
2. 5GMS AS exposes AS Energy Information report to Energy Information AF
3. Energy Information AF processes network energy information reports
4. Energy Information AF exposes processed Network Energy Information to Energy Information Collector
5. Media Stream Handler exposes UE Energy Information report to Energy Information Collector
6. Energy Information Collector processes received Energy Information reports
7. Energy Information Collector shares processed report with Media Session Handler
8. Media Session Handler may expose energy-related information
9. 5GMS-Aware Application may expose received information to Application Service Provider via M8

Media Streaming with Context Modification (Steps 27-37)

1. Media Stream Handler establishes transport session at M4
2. Media Stream Handler requests Media Entry Point from 5GMS AS
3. Media Stream Handler selects Service Operation Point based on configuration and Energy Information
4. Media Stream Handler establishes new transport session with 5GMS AS service location
5. If Service Operation Point changed, Media Stream Handler notifies Media Session Handler with Service Data Flow identification information
6. Media Session Handler modifies energy information collection context in Energy Information Collector

NOTE 2 added: Explains that Service Data Flow description is now explicit based on known IP 5-tuples

1. Similar to step 9, subscribing with explicit Service Data Flow filters based on M4 transport sessions
2. Similar to step 2, subscribing to NF Energy Reports with explicit Service Data Flow filters
3. Similar to step 4, subscribing to AS Energy Reports with explicit Service Data Flow filters
4. Similar to step 24
5. Media streaming occurs between Media Stream Handler and 5GMS AS

6. Gap Analysis (Clause 7.6.4)

Identified architectural gaps:

• Defines two new entities:
• Energy Information AF: Subscribes to NF Energy Information from EIF, receives AS Energy Information from AS, collates and exposes Network Energy Information to Energy Information Collector
• Energy Information Collector (UE function): Acquires configuration from Energy Information AF, subscribes to Network Energy Information, collects UE Energy Information, exposes collected information to UE Application

Specification gap identified: - TS 23.502 and TS 29.566 lack explicit provision for immediate reporting of energy consumption information as side effect of Neif_EventExposure_Subscribe operation - Mitigation: Positioning of step 2 in provisioning phase means Energy Information AF likely receives initial NF Energy Report before application session initiation

7. Proposed Normative Changes (New Clause 7.6.5)

Comprehensive normative work proposal:

1. New Stage 2 TS: Generic architecture and procedures for Energy Information AF and Energy Information Collector, defining operations for:
2. Provisioning Energy Information AF (E1)
3. AS Energy Report subscription/exposure (E3)
4. Aggregated network energy information subscription/exposure (E5)

5. Energy information exposure to UE Application (E6)

6. New Stage 3 TS: Network APIs for Energy Information AF and Energy Information Collector at E1, E3, E5, and client API at E6

7. TS 26.501 updates:

8. Instantiation of generic architecture in 5GMS System

9. Collaboration scenarios for 5GMS Use Cases

10. TS 26.506 updates:

11. Instantiation of generic architecture in RTC System

12. Collaboration scenarios for RTC Use Cases

13. TS 26.510 updates:

14. Extensions to M5 procedures and interfaces for energy-related information in Service Access Information

15. TS 26.512 updates:

16. Extensions to E1, E3, E5 procedures for 5GMS System

17. Extensions to client API at M6 for 5GMS-Aware Application

18. TS 26.113 updates:

19. Extensions to E1, E3, E5 procedures for RTC System
20. Extensions to client API at RTC-6 for RTC-Aware Application

8. Summary Update (Clause 7.6.6)

Revised summary emphasizing: - Generic approach for exposing energy-related information from device, network, and Application Server - Integration into 5GMS and generalized Media Delivery architecture - Introduction of two new components: Energy Information Collector (UE) and Energy Information Application Function (Media AF) - Goal is generic architecture for reuse, not specific optimization strategies

Key Technical Improvements

1. Alignment with existing 3GPP specifications (TS 23.501, TS 29.566)
2. Clear separation of procedure phases (provisioning, initiation, reporting, modification)
3. Explicit Service Data Flow handling (implicit during provisioning, explicit after transport session establishment)
4. Session correlation using Session Identifier throughout procedures
5. Comprehensive reference point definitions (E1, E3, E5, E6, E12, M1, M4, M6, M8, M11)
6. Detailed normative work roadmap across multiple specifications

3GPP TR 26.510 Change Request - Summary

Document Information

• CR Number: 0006, Revision 6
• Release: Rel-20
• Category: B (addition of feature)
• Work Item: FS_Energy_Ph2_MED / AMD_PRO-MED
• Source: Orange
• Meeting: S4-260064 (S4#135, February 2026)

Main Purpose

This CR proposes a solution for Key Issue #6 (Client-driven management of media delivery service energy optimisation) by adding a new clause 7.11 to TR 26.942. The solution enables Media Clients to select Media Entry Points based on energy characteristics using Common Media Server Data (CMSD).

Key Technical Contributions

1. Solution Overview (Clause 7.11)

The CR introduces Solution #10: "Client-driven selection of Media Entry Point in the generalised Media Delivery System based on energy characteristics"

Key Issue Mapping: - Addresses KI#1 (Energy-related Information exposure) - Addresses KI#6 (Client-driven management of media delivery service energy optimisation)

2. Functional Description (7.11.2)

Core Concept: - Leverages existing CMSD [CTA-5006] mechanisms to communicate energy consumption and CO₂ equivalent information from media servers to media players - Enables media players to select distribution paths/modes with least environmental impact - Integrates an Energy Information Manager in media content servers to collect energy data across the distribution chain - Media players supplement server data with local UE energy consumption data

User Modes: Three energy preference modes are defined: - Eco mode: Prioritizes energy efficiency over QoE - Standard mode: Balances energy efficiency and QoE - Performance mode: Prioritizes QoE over energy consumption

Reporting Mechanisms: - Uses CMSD for downlink energy information (server to client) - Uses CMCD [CTA-5004] for uplink reporting (client to server/ASP) - Custom key names employed for energy-specific parameters (not yet standardized in CMCD/CMSD)

Scope Limitation: - Applicable only to downlink 5G Media Streaming (5GMS) context - UE energy collection methods are out of 3GPP scope

3. Architecture Mapping (7.11.4)

Reference Architecture: - Based on 5GMSd architecture (TS 26.501, TS 26.506) - Reuses Solution #5 architecture for collecting/exposing energy characteristics - Key difference: No Energy Information Collector in UE; Media Player receives energy data directly from 5GMSd AS via CMSD

Key Components: - Energy Information AF (instantiated in 5GMSd AF): - Subscribes to NF Energy Information from EIF (per TS 23.501 clause 5.51) - Subscribes to AS Energy Information from 5GMSd AS - Exposes aggregated Network Energy Information to 5GMSd AS

• Media Stream Handler: Decision-making function that selects appropriate service location based on energy characteristics

Reference Points Reused: M1d, M2d, M3d, E3, M4d, M5d, E5, M6d, M8, M11d, E12

4. Energy-Related Information (7.11.5)

Relevant Granularities: - Per media delivery session: Aggregating energy from Application Data Flows with same IP 5-tuple or session identifier - Per service location: Aggregating Media AS Energy Reports from all (Edge) Media AS instances exposing that service location

Energy Information Types: - Energy consumed (in Joules per TS 29.122) - Environmental cost of energy supply

NF Energy Report (7.11.4.3): - Reported by EIF per TS 29.566 clause 6.1 - Uses Application ID initially; refined using Service Data Flow Descriptions during session - Granularity as requested in subscription

Media AS Energy Report (7.11.4.4): - Uses Application ID and Service Location identifier initially - Fine-tuned using Service Data Flow Description during session - Reports from multiple Service Locations provided to enable comparison

CMSD Information (7.11.4.5): - Parameters defined for reporting energy information about service locations - Transmitted at reference point M4d from 5GMSd AS to Media Player

5. Procedures (7.11.6)

Key Procedure Steps (differences from baseline):

Step 2: Media-aware Application indicates selected end-user energy mode when initiating media delivery session

Step 4a: 5GMSd AS subscribes to Network Energy Information from Energy Information AF (including Application ID and Service Location notification URLs)

Step 6: Media Session Handler obtains Service Access Information including Energy Information AF access details and CMCD configuration

Step 10a/20a: Energy Information AF exposes processed Network Energy Information about provisioned service locations to 5GMSd AS

Step 15: Media Session Handler provides Media Entry Points to Media-aware Application including energy-related information for each

Step 16: Media-aware Application selects Media Entry Point with energy characteristics matching configured energy mode

Steps 16-19: Integrated into media delivery session loop to enable dynamic reselection of Media Entry Point if characteristics change

Note: Modifying Media Entry Point during session may cause playback discontinuity

Step 28a/28a bis: 5GMSd AS includes Network Energy Information in HTTP headers of Media Entry Point response using CMSD

Step 29/29bis: Media Stream Handler selects Service Operation Point based on Network Energy Information received via CMSD

6. Gap Analysis (7.11.7)

Identified Gaps in Rel-19 Specifications:

1. Ability to provision use of CMSD by AS to report network energy information to UE (reference point E1/M1)
2. Ability for AS to subscribe to Network Energy Information from Energy Information AF via E3 (citing Application ID or Service Data Flows)
3. Ability for 5GMSd AF to provide CMCD configuration in Service Access Information via M5d
4. Ability for Media Session Handler to provide CMCD configuration to Media Stream Handler via M11d
5. Ability for Energy Information AF to expose Network Energy Report about service locations to AS
6. Ability for Media Stream Handler to process energy information from AS via M4
7. Ability for Media Stream Handler to expose Energy Information to 5GMSd-Aware Application via M7d
8. Ability for Media Stream Handler to send energy information to ASP via M8d using CMCD event mode with HTTP POST
9. Support for CMSD in 5GMS (under study outside this work scope)
10. Ability for Media Entry response to include Network Energy Information in CMSD HTTP headers
11. Ability for Media Stream Handler to extract CMSD energy information and use for Service Operation Point selection

7. Proposed Normative Changes

Stage 2 Changes (7.11.8.1)

New Stage 2 Specification Scope: - Provisioning Energy Information AF via M1d - Reporting energy information by 5GMSd AS via E3 with aggregations per: - Network slice - Data Network - Distribution Configuration (service location) - Application ID - Media streaming session - Subscription/exposure of aggregated network energy information from Energy Information AF to 5GMSd AS

TS 26.501 Changes: - Include Energy Management service subfunction in 5GMSd AS - Document AS service location selection based on energy information transmitted via CMSD

Stage 3 Changes (7.11.8.2)

New Stage 3 Specification Scope: - Provisioning Energy Information AF via M1d - Reporting energy information by 5GMSd AS with specified aggregations - Subscription/exposure APIs at E3

TS 26.510 Changes: - Extend Content Hosting Configuration (clauses 5.2.8, 8.8.3.1) with Boolean flag in DistributionConfiguration indicating CMSD reporting eligibility

TS 26.512 Changes: - Extensions to procedures/interfaces at M1d, E3, M4d, M6d, M8d for energy-related information - Extensions to support energy information exposure using CMSD - Extensions to support CMCD version 2 information

8. Summary and Benefits (7.11.9)

Solution Advantages:

1. Reduced environmental impact: CO₂ emissions consideration in Media Entry Point selection
2. User transparency: Environmental impact visibility without privacy concerns
3. Flexibility: Compatible with existing 5G System optimizations
4. Customization: User choice via energy optimization modes
5. Global optimization: Entire delivery chain considered (production, encoding, delivery, consumption)
6. Minimal UE impact: Leverages existing CMSD/CMCD mechanisms in streaming ecosystem
7. No User Plane impact: Energy reporting handled in control/management plane

Applicability: - Any 5GMSd Application Provider delivering via 5GMSd System - Natural integration with MPEG-DASH and HLS adaptive streaming architectures - Supports French regulator (Arcom/Arcep) recommendations on environmental impact of audiovisual services

References Added

• [26512]: TS 26.512 "5G Media Streaming (5GMS); Protocols"

3GPP TR 26.942 Change Request - Solution for Media Application Server Energy Management

Change Request Overview

CR Number: 0007 rev 6
Specification: 3GPP TR 26.942 v19.0.0
Work Item: FS_Energy_Ph2_MED
Category: B (Addition of feature)
Release: Rel-20

This CR proposes Solution #11 addressing Key Issue #5 (Media Application Server Energy management) by introducing a content steering mechanism based on energy characteristics for downlink media streaming service location selection.

References Added

• [88] 3GPP TS 26.512: "5G Media Streaming (5GMS); Protocols"
• [89] ETSI TS 103 998: "Content Steering for DASH"

Solution #11: Selection of Downlink Media Streaming Service Locations Driven by Content Steering Server Based on Energy Characteristics

Key Issue Mapping (Clause 7.12.1)

Addresses KI#5 specifically: - Exposing energy-related information from the network (via EIF) to media delivery systems - Enabling 5GMS AS to modify ongoing media delivery sessions based on energy-related characteristics shared by the network via Energy Information AF instantiated in the 5GMSAF

Functional Description (Clause 7.12.2)

Core Concept: - Leverages existing content steering capabilities in MPEG-DASH and HLS (already supported in 5GMS from Rel-19 per TS 26.512 clause 10.3A.4) - Extends steering server decision-making to include environmental impact considerations alongside traditional QoS criteria - Utilizes network energy characteristics from EIF (Energy Information Function) to select delivery paths with lowest environmental impact

Key Differentiator: - Compared to Solution #5, this approach adapts streaming sessions based on network environmental impact without affecting the UE or impacting the data plane - Decision-making is implementation-dependent but could use metrics like kgCO₂e per Joule of energy supplying the AS - Example use case: Content available on 2 Media 5GMSd AS service locations with different energy supply mixes; MNO adapts steering to maximize use of location with lower kgCO₂e per Joule

Applicability: - Exclusively for downlink media streaming (as per TS 26.512 clause 10.3A.4)

Collaboration Scenario (Clause 7.12.3)

Requirements: - Energy information reporting from EIF and/or 5GMSd AS - No energy information from UE required - Downlink media streaming only

Reference Architecture Mapping (Clause 7.12.4)

Architecture Components:

Based on TS 26.501 and TS 26.506, instantiating Solution #5 architecture with modifications:

1. Energy Information AF (instantiated within 5GMSd AF):
2. Subscribes to and consumes NF Energy Information from EIF (per TS 23.501 clause 5.51) with required granularities (e.g., per UE)
3. Subscribes to and consumes AS Energy Information from 5GMSd AS

4. Operates according to Energy Information Processing Configuration provisioned by 5GMSd Application Provider

5. Key Architectural Differences from Other Solutions:

6. Energy Information Collector NOT instantiated in 5GMSd Client (UE)
7. 5GMSd AF is the decision-making function for service location selection
8. Uses reference point M4d for communicating service modification recommendations via steering information

9. Energy characteristics assumed unchanged on UE side; selection relies solely on network-provided energy information

10. Reference Points:

11. E5 and Energy Information Collector not instantiated (not required)
12. M4d used for steering information communication

Advantages: - No impact on UE - Compatible with legacy devices - Less efficient than solutions incorporating UE energy data, but broader applicability

Energy-Related Information (Clause 7.12.5)

Overview (7.12.5.1)

Objective: Dynamically select 5GMSd AS service location with energy information aligned with 5GMSd Application Provider configuration

Information Required: - Energy consumed from EIF and various 5GMSd AS instances - Environmental cost of energy supply - Network energy consumption related to specific 5GMSd AS service locations (since AS typically only report direct consumption)

Relevant Granularities:

1. Per network slice and/or Data Network: Aggregating energy consumed by all NFs and AS instances active in particular slice/DN
2. Per service: Aggregating energy consumed by all Application Data Flows sharing same Application ID, service characteristics in IP 5-tuple, or served from all 5GMSd AS service locations sharing same AS host name
3. Per service location: Aggregating Media AS Energy Reports from all (Edge) Media AS instances to which service location has been deployed
4. Per media streaming session: Aggregating energy consumed by all Application Data Flows associated with same media delivery session identifier

Energy Configuration (7.12.5.2)

Editor's Note: Energy Information Configuration will be detailed in separate solution

High-level baseline parameters describing 5GMSd Application Provider's operational constraints regarding collection, reporting, and exposure of energy-related information.

NF Energy Report (7.12.5.3)

Source: TS 29.566 clause 6.1

Subscription Parameters: - Initial: Application ID only - During session: Refined using Service Data Flow Description per Service Location

Report Content: - Total energy consumption in joules (per TS 29.122 clause 5.3.2.3.20) - Provided at requested granularity - For specific timestamp

5GMSd AS Energy Report (7.12.5.4)

Subscription Parameters: - Initial: Application ID and Service Location Identifier - During session: Fine-tuned using Service Data Flow Description (exchange between all UEs and particular Service Location)

Report Content: - Energy consumed in joules at specified granularity - Reports from currently used Service Location AND other available Service Locations - Allows UE to be informed of Service Locations with better performance characteristics aligned with user mode requirements - Uplink data volume not used in this solution

Procedures (Clause 7.12.6)

Procedure Overview: Combines content steering procedure (TS 26.512 clause 10.3A.4) with baseline energy information sharing procedure (clause 7.6.3.2 Solution #5), omitting Energy Information Collector interactions.

Key Procedure Steps:

Step 0: Provisioning - 5GMSd Application Provider creates Provisioning Session and Content Hosting Configuration in 5GMSd AF - Content Hosting Configuration declares multiple service locations in different Distribution Configurations eligible for content steering - 5GMSd AF provides: - Endpoint of content steering service at M4d - Base URLs of provisioned 5GMSd AS service locations at M4d - Information included in Service Access Information advertised via M8d

Step 1: Energy Information Configuration - 5GMS Application Provider provisions 5GMS AF via M1d - Includes Provisioning Session resource and Energy Information exposure configuration for Energy Information AF - Contains Application Identifier for filtering Energy information reports - Flag indicating Energy Information Collector NOT instantiated in UE

Steps 4a-4c: Initial Content Steering Configuration - 4a: Energy Information AF processes NF and AS Energy Information reports (moved from step 10 in baseline; no UE interaction expected) - 4b: 5GMS AF makes content steering prioritization decision considering: - Load on available service locations - Energy-related information from step 4a - Configures selected service location with higher priority in steering instructions - 4c: 5GMSd AF provides content steering configuration via M3d to 5GMSd AS content steering service

Steps 15-17: Network Energy Reporting - 15: EIF submits Network Energy Information report to Energy Information AF via E12 - 16: 5GMSd AS submits AS Energy Information report to Energy Information AF via E3 - 17: Energy Information AF processes reports and provides to 5GMSd AF

Steps 17a-17b: Content Steering Update (replaces baseline steps 18-25) - 17a: 5GMSd AF makes content steering prioritization decision based on energy-related information - 17b: 5GMSd AF provides updated content steering configuration via M3d

Steps 20, 20a, 20b: Session-based Updates - Similar to steps 4a-4c, repeated during media streaming session

Steps 28a/28a bis: Media Player Entry Conditioning - 5GMSd AS conditions Media Player Entry to add content steering service endpoint (if not already added by Application Provider)

Step 28b: Steering Instruction Request - Media Player requests steering instruction from content steering service - No specific energy information in steering instructions themselves

Step 29: Service Operation Point Selection - Media Stream Handler selects based on steering instruction

Step 30/30bis: Transport Session Establishment - Media Player establishes new transport session at M4d for acquiring media from selected Service Location (per content steering instruction)

Step 37/37bis: Media Content Request - Media Player requests media content from selected 5GMSd AS service location

Gap Analysis (Clause 7.12.7)

Identified Gaps in Rel-19 Specifications:

1. Step 0: Ability for 5GMSd Application Provider to declare in Content Hosting Configuration that service locations are eligible for content steering

2. Step 0: Ability for 5GMSd AF to nominate endpoint address of content steering service instantiated in 5GMSd AS

3. Step 1: Ability to indicate Energy Information Collector NOT instantiated in UE

4. Steps 4b, 20a: Functionality for 5GMSd AF to make content steering decision incorporating energy-related information from Energy Information AF

5. Steps 4c, 20b: Ability for 5GMSd AF to provide content steering configuration to 5GMSd AS content steering service via M3d

6. Steps 28a, 28a bis: Functionality for 5GMSd AS to condition Media Player Entry to add content steering service endpoint address

Editor's Note: Additional gap regarding "steering request" to be explained

Proposed Normative Changes (Clause 7.12.8)

Stage 2 Changes (7.12.8.1)

New Stage 2 Specification for Energy Information AF:

1. Provisioning capability via M1d based on energy-related information requirements (clause 7.12.5), with option to not instantiate Energy Information Collector

2. Editor's Note: Specific provisioning requirements TBD

3. Energy-related information reporting by 5GMSd AS via E3 supporting aggregations:

4. Per network slice (for 5GMSd Client access to 5GMSd AS at M4d)
5. Per Data Network (for 5GMSd Client access to 5GMSd AS at M4d)
6. Per 5GMSd AS Distribution Configuration (service location)
7. Per Application ID
8. Per media streaming session

Changes to TS 26.501:

1. Inclusion of content steering service in 5GMSd AS as part of Energy Information AF instantiation

2. Documentation of content steering based on energy-related information in Energy Information AF procedures (per clause 7.12.6), either:

3. Included in baseline procedural definition, OR
4. Documented in separate procedure in Annex A of TS 26.501, motivated by collaboration scenario (clause 7.12.3)

Changes to TS 26.506:

Editor's Note: To be determined

Stage 3 Changes (7.12.8.2)

New Stage 3 Specification for Energy Information AF:

1. Provisioning capability via M1d based on energy-related information requirements (clause 7.12.5), with option to not instantiate Energy Information Collector

2. Editor's Note: Specific provisioning requirements TBD

3. Energy-related information reporting by 5GMSd AS supporting same aggregations as Stage 2

Changes to TS 26.510:

1. New clauses specifying extensions to procedures and service-based interfaces at E1, E3, and E12 reference points pertaining to 5GMS, regarding additional energy-related information from 5GMS AS and EIF for media streaming sessions enabling steering servers to select AS based on environmental impact

2. Step 1 (clause 7.12.6): New Energy Information Exposure Configuration resource (clauses 5.2 and 8) identifying which applications fall within scope

3. Content Hosting Configuration extensions (clauses 5.2.8 and 8.8.3.1):

4. Gap 1: Boolean flag in DistributionConfiguration indicating eligibility for content steering participation
5. Gap 2: URL of content steering service endpoint at M4d nominated by 5GMSd AF and passed to 5GMSd Application Provider

Changes to TS 26.512:

Extensions (as needed) to procedures and service-based interfaces at M1d, E3, and M5d reference points, particularly regarding additional energy-related information from 5GMS AS for media streaming sessions

Editor's Note: Specifics TBD

Changes to TS 26.113:

Editor's Note: To be determined

Summary (Clause 7.12.9)

Candidate Solution Proposal:

New mechanism enabling 5GMSd Application Providers to steer 5GMSd Client towards service location with lowest environmental impact based on:

1. Collection of network energy-related characteristics by MNO:

2. Information provided by EIF and 5GMSd AS to Energy Information AF (included in 5GMSd AF)

3. Standardized interfaces between 5GMSd AF and 5GMSd Application Provider:

4. Allows Application Provider to provision content steering mechanism with goal of reducing environmental impact of downlink media streaming

5. Dynamic steering by 5GMSd AS (acting as content steering server):

6. Uses energy information to steer 5GMSd Clients toward service locations with desired energy characteristics

Benefits: - Optimizes energy efficiency of multimedia content delivery - Contributes to reducing environmental footprint of media streaming services - Applies to any 5GMSd Application Provider delivering content via 5GMSd System - Integrates naturally into existing adaptive streaming architectures (MPEG-DASH, HLS)

Implementation Characteristics: - No impact on UE (leverages existing adaptive streaming protocol mechanisms) - No impact on data plane - Service location selection achieved by prioritizing desired location in steering instructions - Compatible with legacy devices

Additional Changes

Clause 7.1: Mapping of Solutions to Key Issues

Solution #11 added to table mapping, addressing KI#5 (Media Application Server Energy management).

Clause 7.6.3.2: Baseline Procedures

Steps 10a to 10d added to baseline procedures (specific details not provided in change markings).

3GPP TR 26.510 Change Request - Energy Efficiency Phase 2 for Media Services

Document Information

• CR Number: 0009 rev 2
• Specification: TR 26.942 v19.0.0
• Work Item: FS_Energy_Ph2_MED
• Category: B (addition of feature)
• Release: Rel-20

Purpose and Scope

This CR merges multiple contributions agreed by the MBS SWG before SA4#135, addressing energy efficiency aspects for media delivery services in Release 20. The CR builds upon Release 19 work on energy-related information exposure and extends it to media-specific scenarios.

Main Technical Contributions

1. References and Terminology Updates (Clauses 2, 3.1)

New References Added: - TS 29.566: Energy Information Function Services (Stage 3) - TS 29.122: T8 reference point for Northbound APIs

New/Updated Terms: - AS Energy Information: Energy-related information collected and exposed by Application Servers - NF Energy Information: Energy-related information collected from Network Functions and exposed by the EIF - UE Energy Information: Energy-related information collected by the UE - Network Energy Information: Combination of NF and AS Energy Information - Energy availability: Remaining amount of energy locally available for consumption - Energy capacity: Maximum amount of energy that can be locally available - Energy supply mix: Combination of various energy sources (renewable and non-renewable)

2. Energy Information Function (EIF) Summary Update (Clause 4.2.2.3)

Enhanced EIF Responsibilities: - Collection of "UE-related Energy Consumption information" from OAM and 5GC NFs comprising: - Node-level energy consumption and data volume from OAM (gNodeB and UPF instances) - Data transfer volumes from UPF via SMF with various filtering criteria - Calculation of energy-related consumption information at multiple granularities - Exposure via Neif_EventExposure service to authorized consumers

Subscription Filters Supported: - Per UE - Per slice and/or DNN - Per PDU Session - Per Service Data Flow

Stage 3 Information: - Energy consumption expressed in Joules using floating-point representation - EnergyEeNotif object contains array of EnergyEeReport data structures - Each report includes timestamp, optional EnergyInfo, and granularity indication

3. Use Cases from SA1 (Clause 5.1)

Release 19 Use Cases (TR 22.882): - Use case 5.5: Service energy monitoring by Application Server - Use case 5.6: Service-level energy efficiency analysis for verticals - Use case 5.8: Application service Energy Efficiency monitoring - Use case 5.9: Renewable energy consumption information exposure - Use case 5.10: Carbon-aware communication service - Use case 5.14: Reducing GHG footprint of Application Services

New Release 20 Use Cases (TR 22.883): - Use case 5.1: Energy saving service for UE (AR/XR applications) - Use case 5.2: Dynamic service adjustment based on energy information - Use case 5.7: Tolerance to QoS degradation due to network energy saving - Use case 5.8: Green social media & email content download - Use case 5.9: Notifying UEs about network energy-related characteristics

4. Key Issue #1 Updates: Energy-related Information Exposure (Clause 6.1)

Key Questions: 1. How should UE energy-related information be reported to the 5G System? 2. Which reference points should be used for reporting? 3. How to expose network energy information to Media Session Handler? 4. How to allow UE reporting without exposing energy consumption rate?

Requirements from TR 22.882 and TR 22.883: - [22.882-CPR 6.1-7]: Application server selection based on energy consumption - [22.882-CPR 6.3-2/4]: Energy consumption monitoring for 3rd parties - [22.882-CPR 6.4-1 to 6.4-5]: Energy consumption exposure to authorized parties - [22.883-CPR 6.1.1-1 to 6.1.1-4]: Carbon emissions exposure and energy-related characteristics

Additional Potential Requirements: - [PR 1-1]: Reuse existing mechanisms (e.g., UE data collection architecture per TS 26.531) - [PR 1-2]: Reuse common client data reporting formats - [PR 1-3]: Enable 5GMS Client to obtain energy information from UE

5. Key Issue #2 Updates: Energy-related Monitoring and Measurement (Clause 6.2)

Scope Extension: - Beyond 5G network monitoring to include complete end-to-end media delivery chain - Focus on UE-related energy information measurement and monitoring - Applicable to 5GMS, 5MBS, RTC, and Split Rendering systems

Key Questions: 1. Which UE energy-related information should be collected? 2. Can existing methods be leveraged for measurement/monitoring? 3. Which UE entity is appropriate for measurement?

Requirements: - [22.882-CPR 6.3-1 to 6.3-3]: Energy consumption monitoring at various granularities - [22.883-CPR 6.1.4-1]: Assist 3rd party to identify target UEs for service adjustment

Additional Potential Requirements: - [PR 2-1]: Reuse existing mechanisms where possible - [PR 2-2]: Reuse common client data metrics - [PR 2-3]: Enable ASP to adapt service parameters based on 5GS feedback

6. New Key Issue #4: Energy-related Configuration by ASP (Clause 6.4)

Description: Addresses how Application Service Providers can configure energy-related information collection and exposure for media delivery services.

Key Questions: 1. How can ASP specify to network the possibility to use 5G capabilities for energy optimization? 2. How can ASP specify acceptable service degradation levels?

Requirements from TR 22.882 and TR 22.883: - [22.882-CPR 6.1-1/2/4]: Subscription policies for energy credit limits and consumption - [22.882-CPR 6.1-8/9]: Service modification based on energy criteria - [22.883-CPR 6.1.2-2 to 6.1.2-4]: Alternative service performance and energy saving actions - [22.883-CPR 6.1.3-1]: Charging events for degraded performance

7. New Key Issue #5: Media Application Server Energy Management (Clause 6.5)

Description: Studies how media Application Servers (5GMS AS, RTC AS) should react to energy-related information shared by the network via Energy Information AF and/or Energy Information Collector.

Key Questions: 1. Should network energy information from EIF be exposed to media delivery systems? 2. How might 5GMS AS and RTC AS modify ongoing sessions based on energy-related characteristics?

Requirements: - [22.882-CPR 6.1-7/8/9]: Application server selection and service modification - [22.883-CPR 6.1.2-1 to 6.1.2-5]: Service degradation, targeted actions, and access control - [22.883-CPR 6.1.4-1]: Assistance to identify target UEs

8. New Key Issue #6: Client-driven Energy Optimization (Clause 6.6)

Description: Addresses how 5GMS Client and RTC Client should react to energy-related information shared by the network.

Key Question: How might clients modify media delivery sessions in response to network energy-related characteristics?

Requirements: - [22.882-CPR 6.1-7]: Application server selection based on energy information - [22.883-CPR 6.1.4-1]: Assistance to identify target UEs for service adjustment

9. New Annex A: Guidelines for Candidate Solutions

Recommended Content for Candidate Solutions: 1. Tables of high-level baseline parameters for UE-related Energy Consumption information 2. Formulae for aggregating energy information from multiple sources (EIF, AS, UE) 3. Procedures to collect AS energy information at various granularities: - Per AS Service Data Flow - Per AS service location - Per AS host name - Per application session identifier

Clause Skeleton Structure: - Key Issue mapping - Functional description - Collaboration scenarios - Architecture mapping - Energy-related information - Procedures - Gap analysis - Proposed normative changes - Summary

Impact and Dependencies

Affected Systems: - 5G Media Streaming (TS 26.501) - 5G Multicast-Broadcast User Services (TS 26.502) - Real-time Media Communication (TS 26.506) - Split Rendering Media Session Enabler (TS 26.565)

Dependencies: - Release 19 Energy Information Function (TS 23.501, TS 23.502, TS 29.566) - SA1 requirements (TS 22.261, TR 22.882, TR 22.883) - SA2 study (TR 23.700-66)

3GPP TR 26.942 Change Request Summary

Document Information

• CR Number: 0023 rev 1
• Version: 19.0.0 → 20.0.0
• Category: B (addition of feature)
• Release: Rel-20
• Work Item: FS_Energy_Ph2_MED
• Source: BBC, Orange

Purpose

This CR proposes normative work and potential further study following the Feasibility Study on energy-related enhancements for media services (5GMS and RTC systems).

Main Technical Contributions

1. General Structure Changes

• Added new normative references:
• TS 26.512: 5G Media Streaming Protocols
• TS 26.113: Real-Time Media Communication Protocols and APIs
• Restructured Clause 9 from "Proposed next steps" to "Recommendations" with multiple subclauses

2. Recommendations from Version 19 (Clause 9.2)

Key Findings

The study identified that normative work on Key Issue #1 (Energy-related information exposure) is premature because: - The Energy Information Function (EIF) defined in TS 23.501 is not yet fully specified - Capabilities and interfaces of EIF need complete definition first

Outstanding Questions Identified

1. Provisioning mechanisms: How Application Service Providers provision Information Exposure Specifications in the Energy Information AF (may require PCF/EIF interaction)
2. Energy Policy concept: Whether an Energy Policy is needed for ASPs to specify 5GMS System reactions to energy-related information
3. System reactions: How 5GMS AS/Client and RTC System functions should react to energy-related information, including:
4. Notification/renegotiation with PCF
5. Modifications to 5GMS AS and Media Stream Handler behavior
6. Dynamic Policy re-instantiation

Recommended Approach

A phased approach is recommended: 1. Wait for complete EIF definition and TR 22.883 completion 2. Update the TR with: - Detailed EIF interaction specifications - New Key Issues for unaddressed questions - New Key Issues from TR 22.883 use cases 3. Then initiate normative work

TR 22.883 Integration

The study will address new use cases on: - Information exposure of network energy characteristics (consumption, supply mix, carbon footprint, capacity, availability) - Dynamic service adjustments based on energy characteristics - Security, charging, and privacy aspects

3. Recommendations from Version 20 (Clause 9.3)

Core Recommendation

Normative definition and specification of an energy architecture based on Solution #5, instantiated in both 5GMS and RTC Systems.

Detailed Normative Work Specifications

3.1 New Stage 2 Technical Specification

Define generic architecture and procedures for Energy Information AF and Energy Information Collector, covering: - E1 reference point: Provisioning the Energy Information AF - E3 reference point: AS Energy Reports subscription/exposure from Application Servers to Energy Information AF (with baseline parameters) - E5 reference point: Aggregated network energy information exposure from Energy Information AF to Energy Information Collector in UE (with baseline parameters) - E6 reference point: Aggregated energy information exposure from Energy Information Collector to UE Application (with baseline parameters)

3.2 New Stage 3 Technical Specification

Specify network APIs for: - Energy Information AF and Energy Information Collector at E1, E3, E5 - Client API exposed by Energy Information Collector to Application at E6

3.3 TS 26.501 Enhancements (5GMS)

New clauses defining: - Architecture instantiation in 5G Media Streaming System - Collaboration scenarios extending generic procedures for 5GMS-specific Use Cases

3.4 TS 26.506 Enhancements (RTC)

New clauses defining: - Architecture instantiation in RTC System - Collaboration scenarios for RTC-specific Use Cases - Note: Generic scenarios from TS 26.501 may be referenced

3.5 TS 26.512 Extensions (5GMS Protocols)

Specify: - Procedure and interface extensions at E1, E3, E5 for 5GMS System - Example: 5GMS AS extracting/exposing energy information from DASH media segments - Client API extensions at M6 reference point (Energy Information Collector in Media Session Handler to 5GMS-Aware Application)

3.6 TS 26.113 Extensions (RTC Protocols)

Specify: - Procedure and interface extensions at E1, E3, E5 for RTC System - Example: RTC AS extracting/exposing energy information from RTP header extensions - Client API extensions at RTC-6 reference point (Energy Information Collector in Media Session Handler to RTC-Aware Application)

Key Architectural Elements

New Entities

• Energy Information AF: Network function for aggregating and exposing energy information
• Energy Information Collector: UE-side function for collecting and exposing energy information to applications

Reference Points

• E1: Provisioning interface to Energy Information AF
• E3: AS to Energy Information AF interface
• E5: Energy Information AF to Energy Information Collector interface
• E6: Energy Information Collector to Application interface
• M6: 5GMS-specific interface (Media Session Handler to Application)
• RTC-6: RTC-specific interface (Media Session Handler to Application)

Work Item Scope

The CR establishes a comprehensive framework for energy-aware media services spanning: - Generic architecture applicable to multiple systems - System-specific instantiations (5GMS and RTC) - Protocol-level specifications - Client-side API definitions

Discussion Paper on FS_Energy_Ph2_MED Next Steps

1. Background and Issue

The Study on Media Energy Consumption Exposure and Evaluation Framework Phase 2 (FS_Energy_Ph2_MED) is facing schedule challenges. The study was originally planned for completion at SA4#135, but significant work remains outstanding.

Current Status

• Only 4 out of 14 Tdocs submitted to the SA4-e (AH) MBS SWG post 134-2 have been reviewed
• Only 2 Tdocs reached consensus
• A significant number of new candidate solutions are expected at SA4#135
• Consensus is still required on:
• Conclusions, including selection of candidate solutions for key issues
• Recommendations listing proposed normative changes
• Stage 2 Work Item Description (WID)

Original Planning Constraint

The original plan required Stage 2 WID agreement at SA4#135 to allow: - Two SA meetings (SA#112 June 2026, SA#113 September 2026) for Stage 2 completion - Two additional meetings (SA#114 December 2026, SA#115 March 2027) for Stage 3 finalization - Meeting the Release 20 Stage 3 freeze deadline (SA#115 March 2027)

2. Remaining Work for Meaningful Stage 2

Phase 1 Context

Phase 1 of TR 26.942 recommended normative work for Key Issue #1 (Energy-Related Information Exposure) based on: - Energy Information Function (EIF) within 5G System (TS 23.501) - Two new entities: Energy Information Application Function (EIAF) and Energy Information Collector (EIC)

Phase 2 Progress

• EIF capabilities and interfaces are now clearly defined
• Architecture and procedures related to energy information management have been validated through discussions
• However, agreed Change Requests are insufficient to fully identify necessary Stage 2 actions

Critical Outstanding Items

To enable meaningful Stage 2 work, the following key points must be addressed:

1. Baseline Procedures Update: Incorporate new EIF capabilities and interfaces information; confirm whether Energy Information Collector will be used
2. Energy-Related Information Exposure Provisioning: Clarify what Step 1 of baseline procedures entails
3. AS Energy Information Report: Clarify report contents
4. Network Energy Information Delivery: Clarify different options for sending Network Energy Information to UE

3. Feasibility Assessment for SA4#135

The following tasks appear very challenging to complete during SA4#135: - Agree on candidate solutions addressing the key points listed in Section 2 - Reach consensus on conclusions, including candidate solution selection - Reach consensus on recommendations listing proposed normative changes - Agree on Stage 2 WID

Conclusion: The work plan requires adaptation.

4. Proposed Solution and Revised Planning

Proposal

Postpone FS_Energy_Ph2_MED completion from SA4#135 to SA4#136, providing two additional SA4 meetings to finalize the study. This approach would: - Complete the study at SA4#136 - Address Stage 2 in a single meeting (SA#136) - Complete Stage 3 in two meetings - Still meet Rel-20 Stage 2 freeze and address Release 20 SA1 requirements

Enabling Measures

To make this feasible:

1. Freeze New Candidate Solutions: Prevent submission of candidate solutions that have not already been discussed after SA4#135
2. Early WID Consensus: Reach consensus on Stage 2 draft WID during SA4#135-bis e-meeting
3. Early Stage 2 Work: Begin work on new Stage 2 Technical Specification prior to WID approval at SA#112 by:
4. Submitting discussion papers to SA4#135-bis e-meeting and/or SA4#136
5. Including early drafts of TS 26.nnn V0.0.1/V0.0.2 based on agreed baseline of Solution 5

Next Steps

Once consensus is reached on this proposal, the related workplan will be updated accordingly.

Change Request Summary: TR 26.942 Conclusions Update for Energy Phase 2

Document Information

• CR Number: 0025
• Current Version: 19.0.0
• Category: B (addition of feature)
• Release: Rel-20
• Work Item: FS_Energy_Ph2_MED
• Source: Orange Belgium

Purpose of Change Request

This CR updates the conclusions section (Clause 8) of TR 26.942 to incorporate Phase 2 additions and modifications related to energy consumption in media delivery systems. Specifically, it adds conclusion sections for Key Issues 4, 5, and 6 which were previously incomplete.

Technical Changes

Affected Clause

• Clause 8: Conclusions

Modifications

The CR adds three new conclusion subclauses with placeholder content:

8.5 Conclusion for Key Issue #4

Topic: Energy-related configuration by the Application Service Provider for media delivery services

• Currently contains Editor's Note indicating the clause will be updated once candidate solutions are agreed
• Placeholder structure includes:
• Documentation of X alternative Candidate Solutions
• Concluded aspects section

8.6 Conclusion for Key Issue #5

Topic: Media Application Server Energy management

• Currently contains Editor's Note indicating the clause will be updated once candidate solutions are agreed
• Placeholder structure includes:
• Documentation of X alternative Candidate Solutions
• Concluded aspects section

8.7 Conclusion for Key Issue #6

Topic: Client-driven management of media delivery service energy optimisation

• Currently contains Editor's Note indicating the clause will be updated once candidate solutions are agreed
• Placeholder structure includes:
• Documentation of X alternative Candidate Solutions
• Concluded aspects section

Context

Existing Conclusions (Not Modified)

The CR does not modify existing conclusion sections for: - Key Issue #1: Energy-related information exposure (Clause 8.2) - Key Issue #2: Energy-related monitoring and measurement (Clause 8.3) - Key Issue #3: Evaluation framework (Clause 8.4)

Impact

The CR ensures structural completeness of the conclusions section by adding placeholders for Phase 2 Key Issues. These sections will be populated as candidate solutions for Key Issues 4, 5, and 6 are developed and agreed upon during the study.

Consequences if Not Approved

Phase 2 work on Key Issues 4, 5, and 6 would not be properly reflected in the TR's conclusions structure, potentially causing organizational issues as solutions are developed.

Summary of 3GPP Technical Document S4-260074

Document Overview

This document presents revision 0.4 of the Work Plan for the Study Item "Study on Media Energy Consumption Exposure and Evaluation Framework phase 2" (FS_Energy_ph2_MED). The study was approved at SA4#132 (S4-251182) and SA#108 (SP-250636).

Background and Motivation

The study addresses incomplete work from TR 26.942 v2.0.0 due to dependencies on other 3GPP groups. The phase 2 study aims to: - Incorporate new information from completed 3GPP work - Address key issues identified but not resolved in phase 1 - Propose new potential solutions

Study Objectives

1. Release 20 Requirements from TS 22.261

The study addresses new Rel-20 requirements in the media delivery context:

Clause 6.15a.2 - Energy-related information as service criterion: - Media delivery performance degradation (QoS adjustment, bit rate modification, deferring Background Data Transfers) in response to network energy supply mix changes or energy rationing - Per-UE energy saving actions based on subscription policies, including blocking media delivery - Mechanisms to assist Media Application Providers in identifying UEs for performance degradation and energy saving actions - All subject to operator policy, regulatory requirements, and user consent

Clause 6.15a.5 - Energy-related information exposure: - Exposure to UEs and authorized third parties over specific time periods - Network energy consumption and equivalent CO2e emissions for overall media delivery service and individual application data flows - Subject to operator policy, regulatory requirements, and user consent

2. Update Existing Solutions

Update or develop existing potential solutions incorporating new elements from TS 23.501, TS 23.502, and TS 23.503, including: - Energy Information Function (EIF) - Efficient energy use mechanisms - Energy saving items

3. New Potential Solutions

Propose solutions for key issues on: - Energy-related monitoring and measurement during media consumption - Evaluation frameworks without identified normative work

4. New Key Issues from Phase 1

a. Energy-related configuration by Media Application Service Provider: - How ASPs can configure energy-related information collection and exposure

b. AS Energy Management: - How 5GMS AS (and RTC System equivalent functions) react to energy-related information from the network via Energy Information AF instantiated in 5GMS AF and/or Energy Information Collector

c. Client Energy Management: - How 5GMS Client (and RTC System equivalent functions) react to network-shared energy-related information - Leverage existing QoS optimization mechanisms in RTC/5GMS for energy efficiency optimization

Timeline Adjustments

Original Plan: Completion by March 2026 (SA#111)

Revised Plan: Completion postponed to June 2026 (SA#112)

Rationale: - Original timeline too ambitious for two SA4 meetings - Additional two SA4 meetings provided - Addresses Rel-20 SA1 requirements while respecting Rel-20 Stage 2 freeze - Stage 2 addressed in single meeting, Stage 3 in two meetings

Key Decisions to Enable Revised Timeline: - No new candidate solutions accepted after SA4#135 - Consensus on Stage 2 draft WID during SA4#135-bis e-meeting - Begin Stage 2 Technical Specification work before WID approval at SA#112 by submitting discussion papers to SA4#135-bis and/or SA4#136 - Early drafts of TS 26.nnn V0.0.1/V0.0.2 based on agreed baseline of Solution 5

Detailed Work Plan

SA4#132 (May 2025, Fukuoka, JP)

• Agreed New Study Item FS_Energy_ph2_MED (S4-251182)

SA#108 (June 2025, Prague, CZ)

• Approved New Study Item FS_Energy_ph2_MED (SP-250636)

SA4#133-e (July 2025, online)

• No actions

SA4 MBS SWG AHG Meeting (Sep 2025, Paris, FR)

• Address Rel-20 TS 22.261 requirements in media context (existing/new key issues)
• Describe new key issues: ASP configuration, AS energy management, client energy management

SA#109 (Sep 2025, China)

• No actions

SA4 MBS SWG AHG Telco (Oct 2025)

• Progress work on key issues
• Update/develop potential solutions on existing key issues
• Initiate work on new potential solutions for new key issues

SA4#134 (Nov 2025, Dallas, US)

• Finalize work on key issues
• Update/develop potential solutions on existing key issues
• Progress work on new potential solutions
• Communicate with other 3GPP WGs and external organizations

SA#110 (Dec 2025, Baltimore, US)

• No actions

SA4 MBS SWG AHG Telcos (Dec 2025, Jan 2026)

• Update/develop potential solutions on existing key issues
• Progress work on new potential solutions

SA4#135 (Feb 2026, Goa, IN)

• Finalize work on potential solutions
• Describe/improve potential normative work
• Agree CRs to TR 26.942
• Communicate with other 3GPP WGs and external organizations

SA#111 (Mar 2026, Fukuoka, JP)

• ~~Approve CRs to TR 26.942~~ (changed to "No actions")

SA4 MBS SWG AHG Telcos (Mar 2026)

• Finalize work on potential solutions submitted before SA4#135
• Progress on phase 2 modifications in conclusions
• Progress on/describe or improve potential normative work and further study

SA4#135-bis e-meeting (Apr 2026, online)

• Add potential solutions agreed in merged CR
• Progress on/finalize conclusions and recommendations including potential normative work and further study
• Finalize related Stage 2 draft WID
• Initiate early draft of TS 26.nnn
• Communicate with other 3GPP WGs and external organizations

SA4#136 (May 2026, Montreal, CA)

• Add conclusions and recommendations including potential normative work and further study in merged CR
• Finalize recommendations and conclusions
• Agree on merged CRs to TR 26.942
• Agree Stage 2 WID
• Progress on early drafts of TS 26.nnn
• Communicate with other 3GPP WGs and external organizations

SA#112 (June 2026, Singapore, SG)

• Approve merged CRs to TR 26.942

Proposal

The document proposes the above Work Plan for SA4 team consideration.

Summary of S4-260090: Greening of Streaming Collaboration and Media Energy Workshop

1. Introduction and Background

This contribution documents the outreach and collaboration established between 3GPP SA4 and the Greening of Streaming (GoS) organization regarding energy efficiency in media streaming. The source contacted GoS to create awareness of the ongoing "energy for media" work in 3GPP, particularly in the context of 6G where sustainability is a core KPI.

A call was held on December 9 between the source, the study rapporteur, and Benjamin Schwarz (GoS President) to exchange information about respective activities.

2. Greening of Streaming Organization Overview

Mission and Structure

• GoS is a global, member-driven organization focused on making streaming more sustainable and energy efficient
• Emphasizes transparency and evidence-based practices backed by verifiable data
• Operates through multiple working groups:
• Language Lab: Terminology and research papers
• Marketing Lab: Industry presence and education
• Policy & Guidelines Lab: Energy efficiency guidelines
• Watt Lab: Engineering projects including real-time energy measurement

Key Projects (2025)

REM (Remote Energy Measurement Platform)

• Measures actual (not estimated) energy consumption across streaming devices
• Provides data from encoders to home devices
• Key findings include:
• Home gateways use ~10W
• P2P delivery adds minimal overhead
• TV upscaling from HD to 4K can use up to 4W extra
• Network equipment baseline power measurements

EYANG (Energy YANG Data Model)

• Standardized protocol for real-time, component-level energy measurement
• Enables accurate empirical data collection for optimization and compliance

Industry Impact

• White papers on power factor and user-level energy reduction
• Leading measurement efforts for Media Climate Accord (40% emissions reduction by 2030, net zero by 2040)

3. Complementarity Between GoS and 3GPP Work

The discussion identified that: - GoS focuses on streaming applications - 3GPP focuses on telco aspects not covered by GoS - Overlap exists in CDN and streaming delivery areas - Work is complementary rather than duplicative

Key 3GPP Focus Areas Identified

• Exploring which energy-related data could be meaningfully exposed to users
• Operators seeking regulatory clarity on energy attribution
• Using energy and QoE data for network optimization (OpEx and CO₂ savings)
• 6G emphasis on sustainability and operational efficiency
• 3GPP's role: build the framework for energy-based decision-making (not prescribe specific policies)

4. Leadership Support

Quick consultation with SA4 and MBS leadership confirmed support: - MBS chair endorsed the workshop concept - SA4 chair agreed, noting no need to escalate to SA plenary - MBS chair indicated GoS may become a formal liaison to 3GPP - 5G-MAG offered to organize the event

5. Webinar Organization

Event Details

• Date: 19th March 2026 at 15:00 CET
• Format: Online via Zoom
• Co-organizers: 3GPP SA4, Greening of Streaming, and 5G-MAG
• Registration: Free attendance via https://eveeno.com/media-energy-workshop

Confirmed Presenters

1. 3GPP SA4: Related to ongoing Work Item "Study on Media Energy Consumption Exposure and Evaluation Framework phase 2" (WI #1080050), led by Julien Lemotheux (Orange)
2. Greening of Streaming: Hands-on experimentation with live, end-to-end energy measurement
3. 5G-MAG: Reference implementations of media delivery architectures, UE data collection and reporting, APIs
4. MPEG: Topic to be confirmed

Workshop Objectives

• Open technical exchange among experts
• Clarify what is technically feasible today
• Identify requirements for new interfaces or standards support
• Explore collaborative experiments or reference platforms
• Transform energy-aware streaming from conceptual frameworks into deployable systems

Target Audience

Engineers, architects, researchers, and standards contributors working on sustainable media delivery implementation

6. Proposal

The document proposes to: - Take this information into account - Inform other 3GPP Working Groups about the event - Encourage participation and presentation proposals from interested organizations

3GPP TR 26.510 Change Request - Solution for KI1 and KI4

Document Information

• Meeting: 3GPP TSG-SA4 Meeting #135
• CR Number: 0008 rev 6
• Specification: 26.942
• Release: Rel-20
• Category: B (addition of feature)
• Work Item: FS_Energy_Ph2_MED

Change Request Summary

This CR proposes solutions for Key Issue #1 (Energy-related Information exposure) and Key Issue #4 (Energy-related configuration by the Application Service Provider for media delivery services) by introducing a Media Application Service Energy Metrics Reporting Configuration.

Main Technical Contributions

1. Solution #10: Media Application Service Energy Metrics Reporting Configuration

1.1 Overview and Approach

The solution extends the existing Metrics Reporting Configuration framework (defined in TS 26.501 clause 4.0.9) to support Energy-of-media-Service (EoS) metrics in addition to QoE metrics. This reuses the established M1 reference point provisioning mechanism.

The configuration determines: - What energy-related information is collected and reported - Which entities report (UE, Application Server, RAN, User Plane Function) - Reporting frequency and intervals

1.2 Supported Energy Metrics

Four distinct energy exposing modes are defined, each with a dedicated metrics scheme:

1. Carbon intensity - reported in g CO₂-e/Wh
2. Energy consumption - reported in Wh
3. Energy renewable source ratio - reported as ratio
4. Energy contribution ratio - reported as ratio

All four schemes share an identical controlled vocabulary of metrics. Multiple schemes can be provisioned simultaneously under the same Provisioning Session.

2. Media Application Service Energy Metrics Reporting Configuration Parameters

2.1 Configuration Hierarchy

The solution defines a hierarchical configuration structure (Figure 7.11.2.2-1) that: - Derives from the baseline Metrics Reporting Configuration - Shares common parameters with existing QoE reporting - Extends with energy-specific parameters - Is conveyed via Service Access Information to Media Client

2.2 Key Configuration Parameters (Table 7.11.2.2-1)

Metrics Scheme: - Specifies which of the four energy metrics schemes to use - Determines format of aggregated energy-related metrics reports - Multiple schemes can be provisioned

Delivery Session Sample: - Sample mode (0 = all sessions, 1 = percentage-based, 2 = filtered by content type) - Sample percentage - Component content types filter (MIME-based filtering)

Reporting Parameters: - Reporting start offset - Reporting duration - Reporting interval

Metrics to be Reported: - Non-empty list from controlled vocabulary - Uses fully-qualified term identifiers (URIs) - All schemes share same vocabulary

Reporting Scope: - Defines aggregation level for metrics - Four options: 1. Per slice (identified by NSSAI) - aggregated over all sessions in slice 2. Per media delivery session - aggregated over all components in session 3. Across multiple media delivery sessions - aggregated according to sample mode 4. Per media delivery session with component filtering - filtered by MIME content type

Additional Flags: - Contribution ratio flag - includes UE/RAN/CN breakdown when true

3. Controlled Vocabulary for Energy Metrics

Table 7.11.2.2-2 defines standardized metric identifiers:

| Metric Name | URI Identifier | Unit | |-------------|----------------|------| | Carbon intensity | urn:3gpp:media:application:service:energy:metric:carbonIntensity | g CO₂-e/Wh | | Energy consumption | urn:3gpp:media:application:service:energy:metric:energyConsumption | Wh | | Energy renewable source ratio | urn:3gpp:media:application:service:energy:metric:renewableSourceRatio | Ratio | | Energy contribution ratio | urn:3gpp:media:application:service:energy:metric:energyContributionRatio | Ratio |

4. Architecture Mapping

The solution: - Maps onto existing reference architecture from Solution #5 - Does not introduce new functional entities or reference points - Configures reporting by UE, Application Server, and network entities - Procedures detailed in clauses 7.12.3 and 7.13.3

5. Gap Analysis

5.1 Current Limitations (Release 19)

• Metrics Reporting Configuration primarily targets QoE metrics
• Framework assumes UE as sole reporting entity
• No standardized, entity-aware provisioning for energy metrics

5.2 Proposed Extensions

1. Media Application Service Energy Metrics Reporting Configuration inheriting from base Metrics Reporting Configuration
2. Controlled vocabulary for energy metrics (carbon intensity, energy consumption, renewable source ratio, contribution ratio)
3. Energy-specific reporting scopes including:
4. Per slice (NSSAI-based)
5. Per media delivery session
6. Aggregated across sessions
7. Component-level filtering by MIME type

6. Proposed Normative Changes

6.1 TS 26.501 (5G Media Streaming Architecture)

• Extend Metrics Reporting Configuration for energy metrics schemes
• Define hierarchy within Provisioning Session
• Specify conveyance over M1 to Energy Information AF and via Service Access Information

6.2 TS 26.510 (Metrics Reporting Configuration and Procedures)

• Extend data model with:
• Energy metrics schemes
• Reporting scope (including per-slice)
• Controlled vocabulary identifiers

6.3 TS 26.512 (Media Streaming APIs - M1)

• Support creation/management of Energy Metrics Reporting Configuration resources
• Support new configuration attributes
• Carry controlled vocabulary identifiers in configuration payload

7. Collaboration Scenarios

The solution is applicable to all collaboration scenarios requiring access to Media Application Service EoS metrics.

Summary

This candidate solution enables energy-related information collection and exposure by:

1. Extending metrics scheme to include carbon intensity, energy consumption, renewable source ratios, and contribution ratios
2. Refining reporting scope with per-session, per-component, and aggregated options including per-slice reporting
3. Reusing existing provisioning framework with configuration-driven reporting, cadence control, and controlled exposure mechanisms

The approach leverages the mature Metrics Reporting Configuration framework while adding energy-specific capabilities needed for network optimization, energy-aware service adaptation, user empowerment, and carbon emission attribution.

3GPP TR 26.510 Change Request - Solution #12: Media Application Service Energy Metrics Collection and Reporting

Change Request Overview

CR Number: 0018 rev 2
Version: 19.0.0
Work Item: FS_Energy_Ph2_MED
Category: B (addition of feature)
Release: Rel-20

This CR proposes Solution #12 for Key Issue #1 (energy-related collection) and Key Issue #4 (exposure to authorized 3rd parties) for Media Application Service Energy Metrics.

Main Technical Contributions

Solution Positioning and Architecture Approach

This Candidate Solution builds upon Solution #5 (clause 7.6.2.4) for the architecture of energy-related information collection and exposure. Key differentiators:

• Extends existing Metrics Reporting mechanisms from Media AS (reference point E3) and EIF (reference point E12)
• Enables collection and reporting of Media Application Service Energy Metrics
• Supports conveying information to:
• Media Application Provider (via M1)
• UE (via E5)
• Data Collection AF for exposure to authorized event consumers (optional)

Architecture Mapping (Clause 7.13.2.2)

The solution instantiates the reference architecture with the following key functions:

Energy Information AF (instantiated in Media AF)

• Receives and validates Media Application Service Energy Metrics Reporting Configurations from Media AF
• Subscribes to and consumes NF Energy Information from EIF with required granularities (UE, PDU session, QoS flow)
• Subscribes to and consumes AS Energy Information from Application Server
• Collects energy-related information from Media AS and EIF
• Processes information and creates Media Application Service Energy metrics reports
• Publishes reports to Media Application Provider after privacy-preserving post-processing
• Exposes reports to Energy Information Collector in UE

Data Collection AF (instantiated in Media AF)

• Receives Media Application Service Energy metrics reports from Energy Information AF
• Publishes energy-related information to Event Consumer AF subscribers as exposed events

Energy Information Collector (instantiated in Media Session Handler)

• Acquires Energy Information collection configuration from Energy Information AF via E5
• Subscribes to and consumes Network Energy Information metrics reports from Energy Information AF
• Collects UE Energy Information from Media Access Function via Media Session Handler at M11

Reference Points

The solution defines/utilizes the following reference points:

• M1: Media Application Provider provisions Media Application Service Energy Metrics Reporting Configuration to Media AF
• E12: EIF provides energy-related information reports to Energy Information AF
• E3: Media AS transmits Media Application Service Energy metrics reports to Energy Information AF (after obtaining configuration)
• E5: UE Energy Information Collector obtains configuration and transmits/receives reports to/from Energy Information AF
• E4: Data Collection AF subscribes to and receives Network Energy Information from Energy Information AF
• M3: Media AS retrieves Service Access Information including Energy Information AF endpoint address
• M5: Media Session Handler retrieves Service Access Information including Energy Information Collector endpoint address
• M6: Media-aware Application receives Media Application Service Energy Metrics notifications from Energy Information Collector
• M8: Media Application Provider receives energy-related information from Media-aware Application (beyond 3GPP scope)
• R6: Data Collection AF exposes Media Application Service Energy Metrics events to Event Consumer AF

Energy-Related Information Reports (Clause 7.13.2.4)

Media AS Energy Report (7.13.2.4.1)

Generated periodically by Application Server at E3, includes: - Sample timestamp and duration - Application Server instance identification - Metrics reporting configuration ID - Application Service location objects with contribution/renewable ratios - Media delivery session identifier - Session energy consumption and carbon emission - Downlink/uplink data volumes (per session and global) - Global energy consumption (uplink/downlink) - Media component energy objects (per MIME type with energy, carbon, data volumes)

Processed EIF Energy Report (7.13.2.4.2)

Generated by Energy Information AF describing Mobile Network energy consumption: - Sample timestamp and duration - Metrics reporting configuration ID - Media delivery session identifier - Session slice energy and carbon emission - Session energy and carbon emission - Media component energy objects - RAN energy and carbon emission - Core Network (UPF) energy and carbon emission - RAN and Core Network renewable ratios

Aggregated Mobile Network and Media AS Energy Report (7.13.2.4.3)

Generated by Energy Information AF, aggregates information from mobile network and Media AS: - Report timestamp - Aggregated information based on metrics reporting scheme, sample mode, and reporting scope

Aggregated UE and Energy Information AF Energy Report (7.13.2.4.4)

Generated by Energy Information Collector describing UE, Mobile network, and AS energy consumption: - Report timestamp - Aggregated Mobile Network and Media AS Energy Report - Sample timestamp and duration - Media delivery session identifier - Session energy and carbon emission - Network access energy ratio - Non-display and display playback energy ratios - Media component energy objects with UE-specific metrics

Media Application Service Energy Metrics Event (7.13.2.4.5)

Collection of metrics reports exposed by Data Collection AF to subscribing event consumers on per-UE basis (details FFS)

Media Application Provider Energy Metrics Report (7.13.2.4.6)

Generated by Energy Information AF on per-UE basis for Media Application Provider (details FFS)

Procedures (Clause 7.13.3)

The solution defines comprehensive procedures including:

1. Provisioning Phase:
2. Media AF provisioned with Energy Metrics Reporting configurations

3. Energy Information AF subscribes to EIF for Core Network energy information

4. Session Establishment:

5. Service Announcement and Content Discovery
6. Media delivery session initiation
7. Media processing pipeline setup

8. Configuration retrieval by Media AS and Energy Information Collector

9. Metrics Collection Loop:

10. Periodic metrics collection from Media AS, EIF, and Media Access Function
11. Report generation aligned with configured schemes
12. Information processing and aggregation by Energy Information AF

13. Exposure to UE, Media Application Provider, and optionally Data Collection AF

14. Optional Exposure:

15. To Media-aware Application via M6
16. To Media Application Provider via M8
17. To Event Consumer AF via R6 (through Data Collection AF)

Solution #5 Based Procedures (New Section 7.13.3)

Additional detailed procedures mapping this solution on top of Solution #5: - Energy Information Collection provisioning - Media delivery session initiation with energy collection - Periodic energy information reporting during media streaming - Service Operation Point selection based on energy information - Dynamic subscription updates based on Service Data Flow changes

Gap Analysis (Clause 7.13.4)

Identifies that Release-19 Metrics Reporting Configuration: - Provides generic metrics reporting framework - Does not enable standardized, entity-aware provisioning of energy metrics reporting

Proposes requirements for: - Media AF to support Media Application Service Energy Metrics Reporting Configuration - Energy Information AF to collect, process, and report energy information from multiple sources - Energy Information Collector to fetch, process, and propagate energy metrics - Defining energy metrics reports and events at new reference points

Proposed Normative Changes (Clause 7.13.5)

Scope for stage 3 specifications:

• TS 26.501: Addition as profiling/extension of Solution #5, including procedures and report semantics
• TS 26.510: Extension of Metrics Reporting Configuration and procedures for energy metrics schemes
• TS 26.512: Extension of M1 and Service Access Information APIs for energy metrics configurations
• TS 26.531: Extend Data Collection AF to support Media Application Service Energy Metrics as subscribable data set; define events at R6

Solution Summary (Clause 7.13.6)

The Candidate Solution: - Describes how energy-related information is collected, estimated, and exposed by 5G System - Supports network optimization, energy-aware service adaptation, user empowerment, and energy/carbon-emission attribution - Reuses and extends existing 5G Metrics Reporting mechanism with energy-related metrics - Enables collection and exposure of carbon intensity, energy consumption, renewable source ratio, and contribution ratio for Media Application Services - Builds on Solution #5 while keeping M1 provisioning mechanism and adapting procedures for energy information collection from AS and Network

Key Technical Decisions

• Maintains backward compatibility by using M1 for provisioning (use of E1 is FFS)
• Leverages existing Metrics Reporting framework from Release-19
• Introduces new energy-specific report types with detailed parameter definitions
• Supports multiple granularities (UE, PDU session, QoS flow, media component)
• Includes privacy-preserving post-processing before exposure
• Enables both push and pull models for energy information delivery
• Supports optional exposure to third-party event consumers via Data Collection AF

3GPP TR 26.942 Change Request - Solution for Key Issues #5 and #6

General Information

• CR Number: 0014 rev 5
• Current Version: 19.0.0
• Release: Rel-20
• Category: B (addition of feature)
• Work Item: FS_Energy_Ph2_MED
• Source: Nokia

Purpose

This CR proposes Solution #11(b) addressing: - Key Issue #5: Media Application Server Energy management - Key Issue #6: Client-driven management of media delivery service energy optimisation

References Added

New normative references added: - [36300]: TS 36.300 - E-UTRA and E-UTRAN Overall description - [28558]: TS 28.558 - UE level measurements for 5G system - [23288]: TS 23.288 - Architecture enhancements for network data analytics services

Solution Overview (Clause 7.13)

Key Concept

The solution enables Media AS service endpoint reselection during an active media delivery session based on: - UE application QoE requirements (resolution, bit rate, etc.) - Energy-related characteristics of individual Media AS service locations (load, energy consumption, QoE metrics)

Framework Basis

• Leverages QMC-based QoE reporting framework (Clause 4.2.2.2)
• Based on Option 1 from Solution #6 (Clause 7.7.3.1.2)
• Uses existing OAM capabilities for exposing KPIs, performance metrics, and energy data via SBMA framework (TS 28.533, TS 28.532)
• Extends edge processing interfaces from TS 26.501 (5GMS) and TS 26.506 (RTC)

Architecture Components

Energy Information AF (EIAF): - Instantiated in Media AF - Evaluates energy consumption and efficiency for ongoing media services - Uses energy-related parameters provisioned via M1 - Provides energy-related indications/recommendations to Media AF when thresholds are crossed - Correlates QoE information with service-level and media-level energy information

Energy Information Collector (EIC): - Instantiated in Media Session Handler of UE Media Client - Receives information via E5 for correlation with QoS/service information - Provides feedback to Media Application Provider via M8 - Does not directly influence media adaptation decisions (controlled by Media AF)

AS Energy Report Reuse

The solution reuses the Application Server (AS) Energy Report for consistent reporting:

Reused elements: - Energy consumption and efficiency indicators → mapped to EnergyConsumptionValue and EnergyEfficiencyMetric - Reporting scope and aggregation level → determines EnergyMeasurementScope - Reporting triggers and reasons → reflected in EnergyReportingReason - Reporting timing and validity → reused for EnergyMeasurementTime, EnergyInformationTimestamp, EnergyReportValidityTime

The Energy Information AF combines AS Energy Report information with additional context (QoS degradation, QoE metrics from OAM, policy constraints from M1) to derive consolidated energy-related information conveyed via E5.

Energy-Related Information Parameters

7.13.5.1 Energy-Related Provisioning Information (via M1)

Parameters provisioned to Energy Information AF:

| Parameter | Description | |-----------|-------------| | Energy Policy identifier | Identifies the energy policy instance | | Energy monitoring Configuration scope | Scope and granularity (per service/session/component) | | Energy reporting configuration | Reporting conditions (frequency, threshold triggers) | | Energy thresholds | Threshold values for consumption/efficiency | | Energy adaptation guidance | Recommended energy-aware adaptation actions (codec selection, rate reduction, etc.) | | Energy suspension policy | Conditions for suspending media components/sessions | | Energy recovery policy | Conditions permitting increased energy consumption | | Energy reporting recipient | Entities receiving energy reports/notifications | | Service energy profile | Energy efficiency profile for service/application | | Energy Measurement Time | Time/interval for measurements | | Energy Report Validity Time | Validity period for reported information |

7.13.5.2 Client Energy Reporting Information (via E5)

Parameters conveyed from Energy Information AF to Energy Information Collector:

| Parameter | Description | |-----------|-------------| | Energy Policy identifier | Identifies applicable energy policy | | Application Identifier | Service/application/media session group | | Energy measurement scope | Scope of reported information | | Energy measurement time | Time/interval of measurement | | Energy threshold status | Whether thresholds crossed | | Energy budget status | Current budget status | | Energy adaptation status | Whether adaptation actions applied | | Energy reporting reason | Reason for reporting | | EnergyReportValidity time | Validity period | | EnergyInformationTimestamp | Generation timestamp | | Energy Adaptation Recommendation | Recommended energy-related actions | | EnergyConsumptionValue | Measured/estimated consumption |

Procedures (Clause 7.13.6)

Energy Information Collection Provisioning (Steps 1-8)

1. Media Application Provider provisions Media AF via M1, including Energy Information exposure configuration and Energy Policy
2. (Omitted - NF Energy Reports not required)
3. Energy Information AF configures AS Energy Information reporting in Media AS via E3
4. Media AS submits AS Energy Information report to Energy Information AF via E3
5. Media-aware Application initiates media delivery session with Media Session Handler via M6
6. Media Session Handler obtains Service Access Information from Media AF
7. Media Session Handler creates energy-related information collection context with Energy Information Collector
8. Energy Information Collector subscribes to Network Energy Information reporting from Energy Information AF via E5

Application Layer QoE Measurement Configuration (Steps 10a-10g)

Follows TS 38.300 Clause 21.2.1 (management-based QMC activation):

• 10a: OAM sends QoE configuration request to RAN/gNodeB
• 10b: gNodeB forwards application layer measurement configuration to UEs in RRCReconfiguration message
• 10c: Media Session Handler subscribes to QoE metrics from Media Access Function at M11
• 10d: UE sends application layer measurement reports to gNodeB in MeasurementReportAppLayer message
• 10e: gNodeB forwards to OAM
• 10f: OAM forwards UE Application Layer QoE measurement to Media AF (if subscribed)
• 10g: Energy Information AF and Media AF map UEs with Media AS service locations based on BaseURL and reported metrics

Initial Configuration (Steps 11-19)

1. Energy Information AF sends initial configuration to UE Media Client with list of available Media AS service location endpoints via M5
2. Media Entry Points returned to Media-aware Application
3. Media-aware Application selects Media Entry Point based on available service locations 17-19. Media delivery started, Media Entry Point retrieved from selected service location (e.g., "SL1")

Reporting Application Server Metrics (Steps 30-31d)

• 30: Media AS exposes AS Energy Information Report to Energy Information AF via E3
• 1319: Energy Information AF processes received energy-related information about service locations
• 31a-31d: Ongoing application layer measurement reporting (UE → gNodeB → OAM → Media AF), mapping UEs to service locations

Media Session Adaptation (Steps 2132-35g)

• 2132: Energy Information AF sends new configuration to UE Media Client with updated service location endpoints
• 35: Media Session Handler selects service endpoints based on E5 information
• 2235a: Media Session Handler selects new Media AS service location without modifying ongoing session
• 2435b: Media Session Handler requests Media Access Function to switch to new service location
• 2535c: New media delivery transport session established with new service location (e.g., "SL2")
• 2635d: Media Access Function notifies Media Session Handler of successful establishment
• 35e: Media Session Handler relays notification to Energy Information Collector
• 35f: Energy Information Collector notifies Energy Information AF about service location modification
• 2735g: Media delivery continues via new service location

Gap Analysis (Clause 7.13.7)

Identified gaps in Release 19 specifications (in addition to Solution #5 gaps):

1. Step 10c: Ability for Media Access Function to report initial QoE metrics to Media Session Handler for ongoing sessions
2. Step 10/10g: Ability for Energy Information AF and Media AF to map UEs with Media AS service locations based on base URL and reported metrics
3. Steps 11-12: Ability for Energy Information AF to send initial configuration to UE Media Client with available service location endpoints
4. Step 15: Ability for Media Session Handler to provide Energy Information for each Media Entry Point to Media-aware Application at M6
5. Step 16: Ability for Media-aware Application to select Media Entry Point according to energy-related characteristics
6. Step 35: Ability for Media Stream Handler to select Service Operation Point based on configuration from Media Session Handler

Proposed Normative Changes (Clause 7.13.8)

Beyond Solution #5 normative work, additional changes to TS 26.512:

New Clauses Required

a) Extensions to M11 procedures and service-based interfaces for: - Media Access Function reporting initial QoE metrics to Media Session Handler for ongoing sessions

b) Extensions to M11 procedures and service-based interfaces for: - Energy Information AF and Media AF mapping UEs to Media AS service locations based on base URL, UE-related metrics, and AS Energy Report information

Summary (Clause 7.13.9)

The solution describes: - Exposure of energy-related information about different service locations from Media AS to Media AF - Exposure of this information to UE application during media delivery session - Dynamic reselection of Media AS service locations during ongoing M4 sessions based on: - UE application QoE requirements - Energy-related characteristics from Media AS service locations - Mechanism enabling Media Client to dynamically select most energy-efficient service location - Interaction between Energy Information AF and Media Client for joint selection based on network and UE energy information

Applicability: Downlink media sessions, uplink media sessions, and RTC communication sessions

Key Factors: 1. Energy efficiency metrics from Network Operator (power consumption profiles, energy performance indicators from Media AS service locations)

Approach: Optimizes energy consumption of multimedia content delivery while maintaining service quality, operating entirely within network layer using standard adaptive streaming frameworks for compatibility with existing ecosystems.

3GPP TR 26.510 Change Request - Summary

Document Information

• CR Number: 0015, Revision 03
• Specification: TR 26.942 (Release 20)
• Work Item: FS_Energy_Ph2_MED (Energy Efficiency Phase 2 for Media)
• Category: B (Addition of feature)
• Source: Nokia

Main Purpose

This CR adds Solution #12 addressing Key Issue #6: "Client-driven management of media delivery service energy optimisation". The solution enables the Media AF to manage energy-saving operations that may cause QoS and QoE degradation through coordination between the 5GC, Media Application Providers, and UE.

Technical Contributions

1. NWDAF Interactions for QoE Insights (Clause 4.2.2.6 - New)

Overview

• Enables Media AF to request Observed Service Experience analytics from NWDAF
• Provides predictive insights on service performance and network conditions affecting QoE
• Allows proactive decisions on media profiles, buffering, and delivery modes before quality deteriorates

Interaction Patterns

The solution defines three interaction models between AF and NWDAF:

1. Via NEF (N33 reference point):
2. Most common approach for external AF
3. AF accesses NEF using Nnef_* APIs (TS 29.522)

4. NEF interacts with NWDAF on AF's behalf

5. Via PCF (N5 reference point):

6. AF influences policy decisions using Npcf_PolicyAuthorization (TS 29.514)
7. PCF obtains analytics from NWDAF via N23

8. PCF passes results back to AF

9. Direct service-based interaction:

10. For trusted AFs within operator domain
11. Direct consumption via Nnwdaf services
12. Not a numbered reference point

Data Flow

1. AF determines need for network analytics
2. Intermediate NF (PCF/NEF) handles AF request
3. Intermediate NF requests analytics from NWDAF via Nnwdaf_AnalyticsInfo_Request/Subscribe
4. NWDAF collects data from SMF using Smf_EventExposure service
5. NWDAF provides QoE insights to consuming NF
6. Consuming NF makes policy decisions and instructs SMF
7. Results shared with AF for application-level adaptation

Note: No direct AF-SMF interface exists in 3GPP specifications.

2. Solution #12 Architecture and Functional Description (Clause 7.14 - New)

Key Issues Addressed

1. How to determine user tolerance for reduced QoS/QoE
2. How Media AF proposes strategies to minimize QoE impact when QoS is restricted
3. How Media Client prioritizes strategies to minimize QoE impact

Core Principles

Energy Policy Provisioning: - Media Application Provider provisions energy policies in advance - Policies aligned with contracts (e.g., green streaming agreements) - Define acceptable QoS/QoE ranges for media delivery

Energy Saving Triggers: - 5G Core triggers: Network decides to reduce QoS (e.g., bandwidth allocation) - Media Application Provider triggers: Based on cloud provider contracts or resource status - Mix of real-time triggering and pre-provisioned policies

User Tolerance Assessment: - Energy Information AF assesses QoE impact when triggered - Compares requested QoE with predefined thresholds - May query SMF for user subscription QoE levels (from UDM) - If within agreed levels → proceed without approval (collect feedback) - If exceeds levels → request user approval via notification

UE QoE Control: - Energy Information Client in Media Session Handler assesses status - Determines if Media-aware Application can tolerate degradation - Manages QoE to stay above pre-defined thresholds

Architecture Mapping

Energy Information AF Responsibilities: - Validates Energy Information Exposure Specifications - Subscribes to NF Energy Information from EIF (E12) - Subscribes to AS Energy Information from Application Server (E3) - Collates and exposes Network Energy Information to Energy Information Collector (E5) - Interacts with NWDAF via NEF (N33), PCF (N5), or direct service-based interface

Energy Information Collector Responsibilities: - Acquires collection configuration from Energy Information AF - Collects energy information at different granularities (UE, PDU Session, QoS flow) - Per TS 23.501 clause 5.51.2.3

3. Energy-Related Information Elements

Energy Policy Parameters (Table 7.14.5.2-1)

Provisioned by Media Application Provider to guide Media AF behavior:

• Energy efficiency policy: Overall policy for energy consideration during QoS degradation
• Energy vs. media quality preference: Trade-off preference
• Energy consumption budget: Abstract budget for session/service
• Energy-aware adaptation priority: Prioritized list of adaptation actions
• Maximum allowed processing complexity: Upper bounds on encoding complexity
• Energy-based suspension policy: Conditions for component/session suspension
• Energy recovery policy: Conditions for increased consumption when QoS improves
• Service energy differentiation indicator: Energy efficiency category
• Validity time: Applicable time period for policy information

QoE Reduction Notification Parameters (Table 7.14.5.3-1)

Conveyed by Media AF to Media Session Handler upon QoS degradation:

• QoS degradation indication: Detection/notification of degradation
• QoS degradation severity: Classified severity (minor/moderate/severe)
• Affected media components: Impacted components identification
• Recommended media adaptation actions: Mitigation actions
• Media parameter adjustment constraints: Min/max values for bitrate, resolution, frame rate
• Media component priority information: Relative priority for selective adaptation
• Session continuity indication: Continuity vs. quality preference
• Adaptation urgency indication: Immediate or gradual timing
• Media suspension/termination indication: Recommendation for component/session handling
• Media quality recovery indication: Conditions for quality recovery
• Reporting trigger indication: Conditions for reporting back to AF
• Validity time: Applicable time period

4. Detailed Procedures (Clause 7.14.6)

Initial Setup (Steps 1-8)

• Standard downlink media delivery session establishment
• Media-aware Application requests session
• Media delivered between UE Media Client and Media AS
• Based on TS 26.501 clause 5.5.3 steps 4-6

Energy Information Subscription (Steps 9-12)

1. Energy Information AF subscribes to NF Energy Information from EIF (E12), requests immediate report
2. EIF responds with NF Energy Information report
3. Energy Information AF subscribes to AS Energy Information from 5GMS AS (E3)
4. 5GMS AS responds with AS Energy Information report

QoE Reporting via QMC Framework (Steps 13-18)

Based on TS 38.300 clause 21.2.1:

1. OAM sends QoE configuration to RAN/gNodeB
2. gNodeB forwards measConfigAppLayerContainer in RRCReconfiguration to UE
3. UE sends application layer reports in MeasurementReportAppLayer to gNodeB
4. gNodeB forwards to OAM 17-18. OAM forwards to MnS Consumer (e.g., AF) upon subscription

Energy Saving Trigger and QoE Management (Steps 9/10a/10b-31)

5GC-Initiated Trigger Process (Step 21 details): 1. UDM provisions "QoE reduction authorization" in user subscription (TS 23.502 clause 5.2.3.1) 2. SMF selects specific UE/application for QoS reduction 3. SMF subscribes to Observed Service Experience analytics from NWDAF with candidate QoS parameter sets 4. NWDAF provides predicted QoE to SMF 5. SMF optionally queries UDM for "QoE reduction authorization" 6. SMF sends energy saving trigger to AF with QoE ranges

Media Application Provider Trigger (Step 10a): - Provider decides to reduce AS energy consumption (e.g., during peak hours 12:00-14:00) - Can be pre-provisioned schedule or real-time trigger - Trigger contains possible QoE ranges

EIF to EIAF Request (Step 10b/9): - EIF informs EIAF via E12 to request UE Media Client QoE degradation - Due to network and/or UE energy saving

EIAF Activation (Step 10/20): - EIAF receives request and activates energy saving mode - Determines which UEs under control to activate

QoE Reduction Request (Steps 18/22): - EIAF requests subset of Media Clients to reduce QoE via E5 - Based on comparison with pre-defined ASP standards

Current QoE Reporting (Steps 13/22a): - Media Session Handler requests current QoE metrics from Media Access Function (M11)

UE Decision Point (Step 14/23):

If UE does not agree: - Does not activate buffer control - Session continues unmodified - Optional notification to Media AF of preference

If UE agrees (Steps 25-31): 25. Media Session Handler instructs Media Access Function to activate buffer control 26. Media Access Function activates buffer control 27. Ongoing session requires modification 28. Media Session Handler requests Media AF to modify session (new dynamic QoS policy at M5) 29/24. Media AF modifies session and acknowledges 30. Media Session Handler establishes session with new QoE 31. Media continues with possibly reduced QoE

5. Gap Analysis (Clause 7.13.7)

Identified gaps requiring specification:

1. Steps 17-18: Media AF subscribing as MnS consumer with OAM for immediate QoE reports
2. Step 19: EIF requesting EIAF to activate energy saving mode
3. Step 20: EIAF activating energy-saving mode
4. Step 21: EIAF providing energy-related indications/recommendations to Media AF
5. Step 22: EIAF requesting Media Clients to reduce QoE via E5
6. Steps 25-29: Media Session Handler instructing buffer control and requesting dynamic QoS policy modification at M5

6. Potential Normative Requirements (Clause 7.13.8)

Proposed normative work in TS 26.512:

1. Reference Point E5 Extensions:
2. Procedures and service-based interfaces for EIAF requesting EIC to activate energy saving mode

3. Specific to 5G Media Streaming System sessions

4. Reference Point M5 Extensions:

5. Procedures and service-based interfaces for MSH requesting AF to modify dynamic QoS policy
6. Specific to media streaming sessions

7. Key Differentiators

Contrast with Alternate QoS Profile Feature: - This solution differs from TS 23.501 clause 5.7.1.2a Alternate QoS Profile feature - Alternate QoS Profile: Network (NG-RAN) dynamically adapts QoS for network energy saving - Solution #12: Client-driven approach with user consent and application-level adaptation

Solution Benefits: - Dynamic coordination between Media AF, 5GC, Media Application Provider, and UE - User-aware energy-saving decisions based on QoE tolerance - Joint network-UE optimization of energy while maintaining service continuity - Proactive QoE management before quality deteriorates

References Added

• TS 23.503: Policy and charging control framework for 5GS
• TS 29.522: Network Exposure Function Northbound APIs
• TS 29.514: Policy Authorization Service

Affected Clauses

• Clause 2: References (additions)
• Clause 4.2.2.6: New clause on NWDAF QoE insights
• Clause 7.1: Solution mapping table updated
• Clause 7.14: New complete solution description

Change Request Summary: TR 26.942 CR 0013 rev 2

Document Information

• CR Number: 0013 rev 2
• Release: Rel-20
• Category: B (addition of feature)
• Work Item: AMD_PRO-MED (previously FS_Energy_Ph2_MED)
• Source: Nokia
• Meeting: S4-260221 (SA4 WG4 meeting #135, February 2026)

Overview

This CR proposes a solution for optimizing media sessions based on UE energy consumption during mobility scenarios. The solution addresses Key Issue #6 (previously #5) by leveraging energy-related information from the network's Energy Information Function (EIF) to help Application Servers optimize media delivery in an energy-efficient manner.

Main Technical Contributions

1. Solution Mapping Update

• Added Solution #13 to the mapping table (Table 7.1-1)
• Solution #13 addresses Key Issue #6: Optimization of media sessions based on UE energy consumption

2. New Solution #13: Optimization of Media Sessions Based on UE Energy Consumption (Clause 7.15)

2.1 Use Case Scenario

The solution targets scenarios where a user wishes to consume media content (e.g., watching a 90-minute football match) during mobility with limited battery capacity. The system optimizes media delivery QoE based on energy consumption predictions to enable completion of the media session while conserving both UE and network energy.

2.2 Architecture and 5GC Role

The solution defines an architecture where the 5G Core (5GC) plays a central role by providing:

• Mobility Event Reporting and Forecasting: AMF notifies registered AFs about UE mobility events (handovers, access type changes, network area transitions)
• UE and Radio Capability Information: AMF/SMF provides Media AF with UE capabilities, supported RATs, and PDU Session characteristics
• Policy Control and QoS Adaptation: PCF interacts with Media AF and SMF to manage QoS policy changes affecting energy consumption
• Network Data Analytics: NWDAF/PCF shares traffic patterns, load predictions, and network conditions with Media AF
• Network Energy-Related Information Exposure: Energy Information AF obtains cell-specific energy constraints and power saving mode states via NEF

2.3 Functional Process

The solution defines a three-phase process:

Phase 1: UE Energy Information Collection - Media-aware Application initiates media delivery session during mobility - Energy Information Collector (EIC) instantiated in Media Session Handler gathers energy consumption data - Context created including energy consumption prediction related to UE mobility (considering cell edge vs. center positioning)

Phase 2: Codec Adaptation Based on Energy Consumption and Mobility - Media Session Handler requests predicted energy consumption from Energy Information AF - Energy Information AF subscribes to EIF for energy consumption data from 5GC (per TS 23.501 clause 5.51) - NWDAF analytics engine analyzes UE mobility pattern to predict energy consumption - Media Session Handler selects energy-efficient media rendition/encoding parameters considering: - Battery level - Mobility pattern - Media content type and duration - Adaptation options include: - Downlink: Selection between Adaptation Sets (MPEG-DASH) at different bitrates/resolutions - Uplink: Adjustment of encoding bitrate - RTC: Request to RTC AS for transcoding

Phase 3: Media Session Update and Delivery - Media Session Handler informs Media Access Function of selected media encoding - Media delivered using optimal parameters balancing energy efficiency and QoE

2.4 Detailed Procedures (Figure 7.15.3-2)

The call flow includes 22 steps:

Initial Setup (Steps 1-9): - Media-aware Application requests media delivery session - Media Session Handler coordinates with Media Access Function - Transport connection established with Media AS - Baseline energy-related information collection procedures

Energy Management Initialization (Steps 10-13): - Media-aware Application initiates energy information collection considering mobility - Energy Information Collector registers/subscribes with Energy Information AF - Energy Information AF subscribes to UE mobility events from AMF

Parallel Media Delivery and Adaptation (Steps 14-22): - Media delivery starts - AMF notifies Energy Information AF of mobility events (handovers, access changes) - EIF returns network-level energy information to Energy Information AF - Energy Information AF reports network energy exposure and mobility-driven estimates to Energy Information Collector - Media Session Handler processes inputs and decides on adaptation - Media Session Handler selects appropriate media parameters - Media Access Function informed of new parameters - Adapted media delivery continues

3. Gap Analysis

Five key gaps identified requiring normative work:

1. Energy Information Collector subscription mechanism with Energy Information AF for mobility-tied energy estimations
2. Energy Information AF subscription to UE mobility events from AMF
3. Energy Information AF reporting of network energy exposure and mobility-driven estimates
4. Media Session Handler processing logic for adaptation decisions
5. Media Session Handler selection of media parameters based on energy info and mobility prediction

4. Potential Normative Requirements

Proposed normative work in TS 26.512:

New clauses specifying: - Extensions to procedures and service-based interfaces at reference point E5 for Energy Information Collector subscription with Energy Information AF regarding mobility-tied energy estimations - Extensions to procedures and service-based interfaces at reference point M5 for Energy Information AF reporting of network energy exposure and mobility-driven estimates to Energy Information Collector

5. Summary

The solution enables UE optimization of media delivery session energy consumption during mobility by: - Leveraging Energy Information AF and EIF collaboration with 5G Core and Media Application Provider - Utilizing 5GC service-based interfaces for exchanging energy-related information, mobility events, and session parameters - Enabling Media Delivery System to react dynamically to UE mobility context and network energy state - Maintaining high-quality media experience while minimizing energy consumption during transitions across cells, RATs, or network conditions

Summary of 3GPP TR 26.501 Change Request

Document Information

• CR Number: 0016 rev 3
• Specification: 26.942 v19.0.0
• Work Item: FS_Energy_Ph2_MED
• Category: B (addition of feature)
• Release: Rel-20

Change Request Overview

This CR proposes a solution for Key Issue #6 addressing client-driven management of media delivery service energy optimization, specifically focusing on switching between multipath and single-path media delivery based on energy information from the network.

Main Technical Contributions

1. Solution Scope and Mapping

The candidate solution addresses Key Issue #6 on client-driven switching between multipath and single-path transport sessions based on network energy consumption information. The solution is mapped in Table 7.1-1 showing the relationship between solutions and key issues.

2. Functional Description

2.1 Multipath Transport Context

• Leverages existing multi-access media delivery features from TR 26.804 clause 5.18
• Utilizes multipath transport protocols (MPTCP/MPQUIC) for transparent use of multiple access networks
• References Configuration and Settings API from TS 26.512 clause 13.2.4 for multipath operation configuration
• Multipath sessions can span multiple access networks to improve resilience and throughput

2.2 Core Mechanism

The solution introduces switching between: - Multipath transport session: potentially over multiple access networks - Single-path session: based on energy consumption information from network to UE

Two operational modes are supported: - Transparent to application layer (hidden behind virtual tunnel interface per TS 23.501 clause 5.32.2) - Explicitly indicated to Media Access Function by Media Session Handler or Media-Aware Application (per TS 23.512 clause 13.2.4)

3. Reference Architecture

3.1 Architecture Components

Figure 7.X.2.13-1 depicts the reference architecture based on the generalized Media Delivery architecture (TS 26.501 clause 4.1.2):

Network Side: - Energy Information Function (EIF): Collects energy consumption information per TS 23.501 clause 5.51.2.2 - Energy Information AF: Instantiated in Media AF, receives information from EIF

UE Side: - Energy Information Collector: Instantiated in Media Session Handler of Media Client - Media-Aware Application: Makes switching decisions - Media Access Function: Implements transport session changes

Key Reference Points: - E5: Energy information delivery from Energy Information AF to Energy Information Collector - M4: Media flow exchange and switching decision interface

No new reference points are defined; existing architecture is reused.

4. Energy-Related Information

4.1 Access Network Energy Cost Information

Table 7.X.25.21-1 defines the baseline information structure: - Access network energy cost information: Array of descriptors providing network energy cost for delivering application flows over specific access networks for the current Media Delivery session

This enables UE to determine relative cost of establishing transport connections over different available access networks.

5. Procedures

Figure 7.X.36-1 details the complete procedure with the following key steps:

5.1 Session Establishment and Subscription (Steps 1-4)

1. Media delivery session established, energy information subscription performed, EIF sends energy information to UE via EIAF (references baseline procedure clause 7.6.6 steps 1-14)
2. NOTE 1: AS configuration and AS Energy Information reports are not mandatory for this solution

3. NOTE 2: Network Energy Information includes access network energy cost information per clause 7.X.5.1

4. Media delivery session established between UE and network entities, potentially using multipath transport (TR 26.804 clause 5.18.4)

5. Media Session Handler configures Energy Information Collector to subscribe to energy events via internal client API

6. Energy Information Collector subscribes to receive energy events from Energy Information AF over E5

5.2 Media Delivery and Energy Monitoring (Steps 5-8)

1. M4 media flows exchanged between Media Access Function and Media AS

2. EIF provides NF energy information to Energy Information AF per TS 23.501 clause 5.51.2.2

3. Includes per-UE granularity
4. For Multi-Access PDU Sessions: includes UE-specific energy consumption estimates per access network

5. May be relayed via NEF if Media AF is untrusted

6. Energy Information AF forwards energy consumption information to Energy Information Collector over E5

7. Energy Information Collector forwards energy information to Media Session Handler via internal client API

5.3 Decision and Switching (Steps 9-12)

1. Media Session Handler and Media-Aware Application decide on switching between multipath and single-path based on:
2. Access network energy cost information from network

3. UE internal energy consumption to support multipath over multiple access networks

4. Media Session Handler updates transport session parameters per TS 26.512 clause 13.2.4 (if needed)

5. Media Access Function applies updated configuration to media delivery transport session

6. Media Access Function and Media AS switch to new transport session for M4 application flows

6. Gap Analysis

The solution identifies gaps beyond the baseline procedure (clause 7.6.4):

Additional Gaps for This Solution: - Energy Information AF must acquire per-access network energy cost information (clause 7.X.5.1) - Energy Information AF must include per-access network energy cost in Network Energy Information report to UE - Media Aware Application and Media Session Handler must implement decision logic for switching between single-path and multi-path based on received Network Energy Information

7. Proposed Normative Work

Beyond baseline normative changes in clause 7.6.5, the following additional normative work is proposed:

7.1 New Stage 2 Specification

• Define generic architecture and procedures for Energy Information AF and Energy Information Collector
• Include parameters for exposure of network energy cost information per access via E5

7.2 TS 26.501 [23] Updates

• Design principles and procedures for exposure of network energy information per access to Energy Information Collector
• Procedures for Media Aware Application to switch between single-path and multi-path based on clause 7.X.6

7.3 TS 26.506 [59] Updates (RTC System)

• Design principles and procedures for exposure of network energy information per access
• Procedures for RTC Application to switch between single-path and multi-path

7.4 TS 26.512 [26512] Updates (5GMS System)

• Extensions to procedures and service-based interfaces at E5 for additional per-access energy-related information for media streaming sessions
• Extensions to client API at M6, M7, and M11 reference points

7.5 TS 26.113 [26113] Updates (RTC System)

• Extensions to procedures and service-based interfaces at E5 for additional per-access energy-related information for RTC sessions
• Extensions to client API at RTC-6, RTC-7, and RTC-11 reference points

Revision History

• S4-251924: Initial contribution
• S4-252096: Updated with SA4#134 comments
• S4aI260021: Updated with SA4#134 comments and aligned with baseline procedure S4aI260016
• S4-260243: Resubmission (noted without presentation due to time) with alignment to baseline procedure on energy consumption and exposure

Change Request Summary: Media Service Level Degradation Based on Accumulated Energy Consumption

Document Information

• CR Number: 0012 rev 4
• Specification: TS 26.942 v19.0.0
• Work Item: FS_Energy_Ph2_MED
• Category: B (addition of feature)
• Release: Rel-20

Purpose

This CR proposes a solution for Key Issue 4 (Energy-related configuration by ASP) and Key Issue 6 (Client-driven management of media delivery service energy optimization) by introducing energy event-driven media service level degradation based on accumulated energy consumption.

Main Technical Contributions

1. Energy Policy Framework

1.1 Core Concept

• Introduces Energy Policies - UE-specific energy-related policies provisioned by the Media Application Provider in the Energy Information AF
• Each Energy Policy defines:
• Energy accounting period: Duration over which network energy consumption is monitored and accumulated
• Energy Segments: Ordered list of quotas representing contiguous intervals of cumulative energy consumption
• Each segment defined by lower/upper energy thresholds
• Each segment mapped to specific service performance levels (QoS parameters or Service Operating Points)

1.2 Energy Policy Parameters

Key information elements include: - External reference: Unique identifier for UE Media Client selection - Names/Descriptions: Multilingual human-readable information - Granularity: Scope of energy measurement (per-UE, per-PDU session, per-QoS flow, per-slice, or AS) - Accounting period: Time period for continuous energy monitoring (e.g., session, hour, day) - Client subscription permissions: Flag for Energy-driven Service Level Change Event notifications - Energy segments: List of segments with: - Segment range (lower/upper thresholds) - Applicable QoS parameters (e.g., degraded bit rate) - Applicable Policy Template identifier (optional) - AS Energy Policy parameters (optional, for AS granularity)

1.3 Multiple Policy Support

• Multiple Energy Policies can be provisioned with the same accounting period
• Allows ASP to offer UEs choice between different service performance constraints
• All policies reflect same current/predicted energy-related characteristics of serving network

2. Service Level Change Notification Mechanism

2.1 Energy Segment Transitions

• Energy Information AF continuously monitors and tracks cumulative energy consumed by UE
• When accumulated energy crosses Energy Segment boundaries, service performance level changes
• Energy Information AF triggers degradation/improvement based on segment mapping

2.2 Energy-driven Service Level Change Events

New event type containing: - Current Energy Segment status: Details of currently applied segment (unit, current usage, range) - Undegraded Policy Template/bit rate: Performance achievable if energy situation improves - Energy-degraded Policy Template/bit rate: Current degraded performance due to energy impacts - Predicted duration/end time: Optional timing information for degradation - Scope of degradation: Indicates whether degradation applies to UE/user, cells, service location, or network - Degradation cause: Network-to-device transmission or server processing

2.3 Notification Flow

• Energy Information AF notifies Media AF of service level changes
• May trigger Dynamic Policy changes for the media delivery session
• Events delivered to Energy Information Collector in UE Media Client
• Media Client receives actionable information for adaptation decisions

3. Client Adaptation Mechanisms

3.1 UE Response Options

Upon receiving Energy-driven Service Level Change Event, Media Client can: 1. Continue with degradation: Adapt media delivery to stay within degraded service level 2. Upgrade service level: Spend energy credits or purchase mechanism 3. Re-select Energy Policy: Change to different policy (e.g., from "green" to "less green") 4. Other actions: Including session termination

3.2 Informed Decision Making

• UE can distinguish energy-driven degradation from congestion or connection issues
• Additional context (scope, cause, duration) enables intelligent adaptation
• Autonomy preserved for client-side decision making

4. Architecture and Reference Points

4.1 Key Components

• Energy Information AF: Instantiated in Media AF
• Provisions and manages Energy Policies
• Monitors accumulated energy consumption
• Generates Service Level Change Events
• Interfaces with EIF and Media AS
• Energy Information Collector: Instantiated in Media Session Handler
• Receives Energy Policies from Energy Information AF
• Subscribes to Service Level Change Events
• Exposes information to Media Client

4.2 Reference Points

• M1: Energy Policy provisioning by ASP to Media AF
• E5: Energy Policy configuration, instantiation, and event delivery between Energy Information AF and Collector
• E12: NF Energy Information reporting from EIF to Energy Information AF
• E3: AS Energy Information reporting from Media AS to Energy Information AF
• M6: Energy Policy Status and Service Level Change Event exposure to Media-Aware Application
• M5: Dynamic Policy change notifications (optional)
• N5: PCF policy control for QoS modification (optional)

5. Detailed Procedures

5.1 Provisioning Phase (Steps 1-4)

1. ASP provisions Media AF with Energy Policy provisioning resource and Energy Information exposure configuration
2. Energy Information AF subscribes to NF Energy Information from EIF
3. Energy Information AF configures Media AS
4. Energy Information AF subscribes to AS Energy Information from Media AS

5.2 Session Initiation Phase (Steps 5-15)

1. Media-Aware Application initiates session with energy collection and Energy Policy features enabled
2. Media Session Handler obtains Service Access Information including Energy Policy configuration
3. Media Session Handler creates energy collection context in Energy Information Collector
4. Energy Information Collector requests UE Energy Information collection configuration including Energy Policies
5. Energy Information Collector subscribes to Service Level Change Events
6. Energy Information AF processes energy reports and identifies initial energy segment
7. Initial Energy Policy Status report delivered to Energy Information Collector 12-15. Energy Policy Status information propagated to Media-Aware Application

5.3 Media Delivery Phase (Steps 16-21)

16-17. Media-Aware Application selects Media Entry Point based on Energy Policy Status 18-19. Media Stream Handler establishes transport and requests Media Entry Point 20-24. Optional Service Operation Point selection and Service Data Flow updates 25. Media delivered between Media Stream Handler and Media AS

5.4 Runtime Monitoring Phase (Steps 29-37)

29-30. EIF and Media AS expose energy information reports to Energy Information AF 31. Energy Information AF processes reports, checks Energy Policy, detects segment changes 31a-d. Optional Dynamic Policy change triggered and Service Level Change Event generated 32. Network Energy Information report with Energy Policy status exposed to Energy Information Collector 35-36. Service Level Change Events shared with Media Session Handler and Media-Aware Application 37a-d. UE decides on energy-degradation response, results reported back through chain

6. Gap Analysis

6.1 Dependencies

• Based on Network Energy Information from EIF
• Builds on baseline Solution #5 (Energy Information AF and Collector entities)

6.2 New Capabilities Required

• Energy Policy provisioning via M1
• Energy Policy delivery and configuration via E5
• Energy Policy selection and instantiation by Media Session Handler
• Energy-driven Service Level Change Event subscription and delivery
• Energy Policy Status exposure to Media Client
• Dynamic Policy triggering based on segment changes
• Energy-degradation response handling

7. Normative Requirements

7.1 Stage 2 Specifications

• Generic architecture and procedures for Energy Information AF/Collector
• Energy Policy provisioning, exposure, configuration, and instantiation operations
• Service Level Change Event subscription and exposure mechanisms

7.2 Stage 3 Specifications

• Network APIs for reference points E1, E3, E5
• Energy Policy provisioning API and resources
• Energy Policy configuration in UE Energy Information Collection
• Resource update notification channel for events

7.3 5GMS-Specific Extensions (TS 26.501, TS 26.510, TS 26.512)

• Energy Policy provisioning by 5GMS Application Provider
• Energy Policy usage for monitoring and triggering events
• Dynamic Policy change triggering
• Service Level Change Event creation and exposure
• M1 extensions for Energy Policy provisioning API
• M5 extensions for Energy Policy in Service Access Information
• M6 extensions for Energy Policy Status and event exposure
• MQTT notification channel extensions

7.4 RTC-Specific Extensions (TS 26.506, TS 26.113)

• Equivalent procedures for RTC functions
• RTC AF instantiation of Energy Information AF
• RTC-specific collaboration scenarios

Key Changes from Previous Revisions

• Terminology refinement: "Energy subscription period" → "Energy accounting period"
• Enhanced Energy Policy Status reporting in procedures
• Clarified Energy Segment transition detection logic
• Expanded energy-degradation response reporting flow (steps 37a-d)
• Refined normative requirements structure