Extracted Proposals

This document does not contain any proposals. The document is a work plan for the Study on Media Aspects for 6G System (FS_6G_MED) and includes objectives, timelines, work topics, and meeting schedules, but no formal proposals are presented.

This document does not contain any technical proposals. The document is a skeleton/template for 3GPP TR 26.870 V0.0.1 "Study on Media Aspects for 6G System" and consists only of structural elements (table of contents, editor's notes, and empty sections) without any actual proposals.

Extracted Proposals

Proposal 1: Agree on basic assumptions in clause 2 and invite for documenting those in TR 26.870.

Proposal 2: Use the SA4 TOR as guidance for the work in the FS_6G_MED study, and continue to collect inputs to improve media specifications taking into account the aspects in clause 3.

Proposal 3: Agree on the organization of the work based on clause 4. Parts of this is covered by the work plan in S4aP26002.

Proposal 4: Agree on the skeleton of TR 26.870 based on the rationales in clause 5. A separate contribution is submitted in S4aP26004.

Proposal 5: Agree on the main work topics and the priorities provided in clause 6.

Proposal 6: Agree on the handling of AI traffic characteristics based on clause 7.

Proposal 7: Invite for contributions on for larger themes for 6G that SA4 is expected to contribute technologies and use those provided in clause 8 as starting point.

Based on my analysis of the document, there are no proposals in the traditional format that you've described.

The document contains: - A "Conclusions" section (Section 3) that states "This serves as starting point" but contains no formal proposals - A "Proposal" section (Section 4) that states "It is proposed to agree the following changes to 3GPP TR 26.870v0.0.1" followed by technical content changes

However, Section 4 is describing a change request proposal for the document itself (proposing to add/modify content), rather than containing numbered or formatted proposals within the technical content.

The technical content that follows (the changes between "First Change" markers) consists of references, definitions, assumptions, and requirements, but does not contain any statements formatted as "Proposal X:", "Proposal X.", "Proposal:", etc.

Therefore, this document does not contain any proposals in the specified formats.

Proposal 1: It is proposed to agree the following changes to 3GPP TR 26.870v0.0.1.

Extracted Proposals

This document does not contain any proposals. The document is a 3GPP Change Request that proposes draft content for TR 26.870, but it does not include any sections explicitly marked as "Proposal" with the formatting patterns specified (e.g., "Proposal X:", "Proposal:", etc.).

The document contains a section titled "3. Proposal" which states "It is proposed to agree the following changes to the 3GPP Draft TR 26.870," but this is followed by technical content and requirements rather than formatted proposals. The content consists of potential requirements identified from TR 22.870, formatted as "[PR X.X.X-X]" (Potential Requirements), not as "Proposals."

Extracted Proposals

Based on my review of the document, there are no explicit proposals in this 3GPP contribution.

The document is a starting point contribution for the FS_6G_MED study (Work Topic 1: Media Delivery Architecture) and contains: - Introduction and background - Reason for Change - A Conclusions section that states "This serves as starting point" - Proposed changes to TR 26.870 (technical content additions)

However, there are no sections explicitly marked as "Proposal", "Proposal X:", "Proposal X.", etc. The section titled "4. Proposal" only contains the text "It is proposed to agree the following changes to 3GPP TR 26.870v0.0.1" followed by the actual change request content, which is standard CR formatting rather than a formal proposal in the sense typically used in 3GPP contributions.

Proposal: It is proposed to agree the following changes to 3GPP TR 26.870

Proposal

It is proposed to agree the following changes to 3GPP TR on 6G_MED.

Proposal 1. Document the features of neural network codecs and their application to error resilient AI traffic in 6G MED TR under 6G Media based on the text in clause 2 and 3.

Proposal 2. Take the use case of NNC with channel aware source coding training into account for AI traffic characteristics.

Extracted Proposals

Proposal a) Take this information into account when developing an overview of AI traffic characteristics with native AI format or codec besides options for traditional codec.

Proposal b) Consider for 6G split inferencing that the split operation may include such AI processing/formatting in addition to the more traditional and direct model splitting considered in 5G.

Proposal c) Add text and diagram based on clause 2 to TR for FS_6G_MED (see PcR below).

Proposal 1: Take the requirements for embodied AI into account in FS_6G_MED, in particular the real-time AI inference requirement.

Proposal 2: Document the simplified embodied AI use case and related requirements based on this paper (based on clause 8)

Proposal 1: Take this approach into account as it shows real-time AI codec based traffic over WebRTC

Proposal 2: Consider the feasibility of such an approach for generating traces for real-time AI traffic.

Extracted Proposals

Proposal 1: Add Clause 2 above to TR 26.870 clause 6.2 as a basis for further work.

Proposal 2: Take into account that current AIML traffic reuses the existing protocols and formats (i.e., audio, video, text over HTTP, RTP, etc.).

Proposal 3: Agree to prioritize characterization of existing popular AI apps and provide initial analysis to SA by June 2026.

Extracted Proposals

Proposal: The proposal is to discuss clause 3 and agree a generic architecture and definitions for LLM based AI applications as basis for further work.

Proposals

Proposal

We propose that SA4 agrees the proposed testbed for AI traffic characterization as the baseline for the evaluation and document it in TR 26.870 (Study on Media Aspects for 6G System).

Extracted Proposals

Proposal: We propose that the group adopts the identified test scenarios as described in this contribution and implemented in the AI testbed. We also propose to document the relevant AI use cases from TR 22.870 in an Annex in the TR 26.870.

Proposal: It is proposed to agree the following changes to 3GPP TR 26.870

Proposals

Proposal 1: It is proposed to agree the following changes to clause 6 of 3GPP TR 26.870.

Proposal: It is proposed to agree the following changes to 3GPP TR 26.823 v0.2.0.

Proposals from Document S4-260234

Proposition 1: SA4 should study the support of additional media modality and codecs or their enhancements for 6G, building upon 5G and 5GA studies.

Proposition 2: SA4 should define terminology applicable for AI/ML data (feature, token, embeddings, latent, intent, etc.), study the relevant AI representation formats to ensure a common understanding across WGs and study which interchangeable format/codecs are applicable.

Proposition 3: SA4 should identify and study a set of spatial compute functions that may benefit from off-device processing for mobile AI-enabled applications and services

Proposition 4: When studying traffic characteristics for AI-enabled applications and services, SA4 should aim at developing generic QoS and QoE mechanisms suitable across the diversity of traffic patterns.

Proposition 5: SA4 should study the necessary enhancement to QoS framework enabling finer granularity and context awareness.

Proposal 6: SA4 should specify the procedures for real-time QoE-based adaptation of multimodal media and define QoE metrics for real-time and delay-bound AI inference.

Proposal 7: SA4 should characterize the impact of QUIC-based protocols on the delivery of AI data and on the traffic characteristics of AI applications and services over QUIC-based protocols especially for real-time or delay-bound applications.

Proposal 8: SA4 should study the potential integration of the extensions SA2 has defined for QUIC-based transport solutions into the media delivery architecture. For the RTC architecture, this would be done by leveraging the FS_Q4RTC-MED study and applied to these AI-enabled applications.

Proposal 8: SA4 should study the impact of multi-devices on the QoS and QoE framework.

Proposition 9: SA4 should consider heterogenous multi-devices associated with the same user for the definition of QoE metrics and for the study of potential enhancement to QoS for real-time and delay-bound AI inference.

Proposal 1: Agree that any assumptions made regarding AI formats for the purpose of traffic modeling are for guidance of related development of AI traffic models. They should not be treated as rigid, normative standardization targets. Correspondingly, SA4 should avoid normative work on AI formats (the actual structure of the data packets) at this stage. Doing so risks locking the 3GPP specifications into constraints that do not suit the technology as it evolves over the next few years.

Proposal 2: Work should focus on the traffic characteristics (latency, throughput, periodicity, burstiness characteristics), rather than the specific coding or file formats used to generate that traffic.

Proposal 3: SA4 should review this as the landscape on AI traffic and its formats continue to evolve rapidly.

Extracted Proposals

Proposal

It is proposed to include sections 1 to 3 in a relevant section of the TR 26.870

Proposal 1: Take this approach into account as 6G Media Delivery Architecture.

Proposal 2. Add the following change to the TR for FS_6G_MED.

Extracted Proposals

Proposal

Take this information into account in FS 6G MED, mainly focus on traffic characteristics of interest to RAN-2 that have explicitly been targeted for coordination with SA4 at the ongoing RAN-2 meeting.