# 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.