VIDEO SWG Ad-Hoc Report (Post SA4#134)

Meeting Overview

This report covers two VIDEO SWG ad-hoc sessions held between SA4#134 and SA4#135: - Session 1: December 16, 2025 (15:00-18:00 CET) - Session 2: January 27, 2026 (15:00-18:00 CET)

The sessions were conducted online with 22 and 18 participants respectively.

1. Maintenance Work - VOPS

S4aV250070: Annotation Schema for VOPS and FS_AVFOPS_MED

Status: Agreed

Key Contributions: - Proposed annotation schema (JSON format) and animation example for video signals used in conformance testing - Addresses the intersection of VOPS and Advanced Video Formats (AV) conformance activities - Proposes moving conformance activities into the study phase to align completion with normative work

Technical Details: - Introduced annotation schema for documenting test bitstreams - Covers requirements for bitstream generation and references to existing testing specifications - Reference encoders are informative only, not normative - Big Buck Bunny identified as initial test sequence candidate - JSON files to be added to 3GPP Forge as baseline

Discussion Points: - Clarified that encoder specifications remain outside normative scope - Focus on providing conformant bitstreams with documentation of generation methods - Encoder references needed for reproducibility but not as normative elements

2. FS_AVFOPS_MED (Study on Advanced Video Formats and Operation Points)

2.1 S4aV250069: Video with Changeable Background

Status: Endorsed

Scenario Description: - Enables users to change recorded video backgrounds using auxiliary alpha channel - Uses MV-HEVC for alpha channel signaling

Technical Aspects: - Reviews previous 3GPP work (none found in existing specs) - References external developments: - MV-HEVC for multi-view video coding - CICP draft for alpha channel signaling - ISO base format amendment for alpha maps

Open Issues: - Alpha signal definition: Lack of clear, codec-independent specification for alpha channels - Alpha channel represents transparency levels, but conventions vary by system - CICP work ongoing but not yet providing complete definition - Action identified: Need precise, codec-agnostic definition of alpha signals and interpretation

2.2 S4aV250071: Refocusable Video

Status: Endorsed

Scenario Description: - Recording video with ability to change focus plane after capture - Uses three tracks: blurred video, sharp video, and depth map

Technical Aspects: - References Android and Apple ecosystem implementations - Ongoing work in CICP for depth map code points - ISO file format amendments in progress

Open Issues: - Signal mapping: Need clarity on mapping between signals in specifications and Android/Apple APIs - Depth interpretation: Complexity of depth normalization and application across scenarios - Interoperability: Need for clear definitions of how depth maps are defined and used - More documentation required on APIs and signal mapping

2.3 S4aV250072: Video with Semantic Segmentation Map

Status: Endorsed

Scenario Description: - Combines video signal with semantic segmentation map - Segmentation map assigns class identifiers (e.g., face, hair, clothes) to pixel values - Applications: AR filtering, video indexing

Technical Aspects: - JVET work extending MV-HEVC auxiliary layers to support segmentation planes - Codec-agnostic approach for broader applicability - Each segmentation model has its own category set - Application must know which model was used to interpret IDs correctly

Key Technical Challenges: - Semantic vocabulary: Need defined vocabulary or model reference for segmentation map values - Coding artifacts: Robustness achieved by mapping value ranges to class IDs (number of classes typically much lower than possible sample values) - Model reference: Essential to specify which segmentation model was used for interoperability - Signal definition: Need to define signals and semantics independently of coding solutions, not relying on SEI messages or codec-specific mechanisms

Discussion Outcomes: - Focus on defining signals independently of coding solutions - Further work needed on requirements, model references, and semantic definitions - Use case valuable despite implementation concerns

3. Avatar Phase 2 Work (Avatar_Ph2_MED)

3.1 S4aV260005: Corrective CR for TS 26.813

Status: Endorsed

Details: - Content agreeable but needs revision for SA4#135 in Goa - Template from portal to be used - Corrections and clarifications to existing Avatar specification

3.2 S4aV260004: Work Plan for Avatar_Ph2_MED

Status: Agreed

Work Plan Structure: - Objectives organized by dependencies and complexity - Some evaluations can only be done after earlier steps complete - Prioritization based on interest and technical dependencies

Process Agreements: - CR submission approach: Flexibility maintained for early CRs if solutions complete and group agrees - Parallel work: Normative work should not run in parallel with study (discouraged practice) - Early implementation: CRs can be issued early if consistent, but doesn't automatically start normative work - FFS items: Can be addressed early with intermediate CRs if appropriate - Corrections vs. features: Clarifications/corrections can be made anytime if justified; new features should wait for study completion

Key Issues Clarification: - Listed "key issues" are actually objectives from the work item, not newly identified problems - Study planned to run until September 2026 - Possibility of starting normative work earlier if editors' notes addressed

3.3 S4aV260006: Consolidated CR for FS_avatar_ph2_MED

Status: Endorsed as basis for further work

Approach: - Base CR to track changes across study - Contributions as candidate text against new or existing sections - Consolidation at each meeting - CRs sent for approval when ready

Editorial Requirements: - Cannot attach full draft TRs to CRs - Must use correct 3GPP styles - References must be up-to-date - Only modified clauses included in final CR - TR version not referenced in document - "Avatar Phase 1" terminology not used in TR - Change history of TR not used to integrate co-CRs

Open Question: - Security and SA3 objective (possibly objective 7) listed in time plan but corresponding section not visible in CR document

4. Process and Administrative Matters

Document Handling Decisions

• Terminology: Use "inputs" and "discussion papers" rather than "pCR" (pseudo-CR)
• Structure: Discussion papers with candidate text preferred over single large CRs
• Consolidation: Multiple contributors can submit text against base CR, consolidated at meetings
• Tracking: Changes tracked in document and through section changes

IPR and Antitrust

Standard IPR and antitrust clauses read at opening of each session, with reminders about: - Obligation to inform Organizational Partners of Essential IPRs - Compliance with competition laws - Consensus-based decision making

Summary of Agreed/Endorsed Documents

| Document | Title | Status | Target | |----------|-------|--------|--------| | S4aV250070 | Annotation schema for VOPS/FS_AVFOPS_MED | Agreed | Baseline for conformance work | | S4aV250069 | Video with changeable background | Endorsed | CR to TR 26.966 | | S4aV250071 | Refocusable video | Endorsed | CR to TR 26.966 | | S4aV250072 | Video with semantic segmentation map | Endorsed | CR to TR 26.966 | | S4aV260004 | Avatar Phase 2 work plan | Agreed | Study organization | | S4aV260005 | Corrective CR for 26.813 | Endorsed | Revision for Goa | | S4aV260006 | Consolidated CR for Avatar Phase 2 | Endorsed | Basis for further work |

Key Technical Gaps Identified

1. Alpha channel definition: Need codec-independent specification for alpha signal interpretation
2. Depth map interoperability: Mapping between specifications and platform APIs unclear
3. Semantic segmentation: Model reference and vocabulary definition required for interoperability
4. Signal definitions: Need codec-agnostic definitions independent of SEI or codec-specific mechanisms

SA4 AHG Call on FS_6G_MED - January 15th 2026

Meeting Overview

This report documents the SA4 Ad Hoc Group (AHG) call held on January 15, 2026 (16:00-17:30 CET) to discuss the newly approved FS_6G_MED study (Study on Media aspects for 6G system), which was approved at the December 2025 SA plenary in Baltimore. The call was chaired by Gilles Teniou (Tencent, SA4 Chair) with 51 participants attending.

Study Leadership: - Prime Reporter: Thomas Stockhammer (Qualcomm) - coordination - Secondary Reporter: Elmira Ramazanirend (Vodafone) - draft TR production

Work Plan (S4aP260002/S4aP260005)

Key Discussions

Meeting Schedule: - Initial dates proposed for AHG calls were adjusted based on participant availability - Changed to March 16th and 23rd (avoiding conflicts with DVB meeting on 18th and other constraints) - Discussion on establishing regular timeslots for 6G_MED calls in weeks without other SWG telcos - Suggestion for physical meeting in Amsterdam was noted, though online format preferred due to travel approval concerns - Proposal for half-day workshop potentially at IBC or MHV events

Use Case Handling: - Question raised about use case templates and organization - Use cases primarily sourced from SA1 - Discussion on whether SA4 is limited to SA1-defined use cases or can expand - Consensus that inputs are welcome with discussion on integration approach - Suggestion to summarize SA1 use cases and extract SA4-specific requirements rather than exact wording

Deadlines: - Request to set appropriate deadlines for contributions - Concern raised about bringing use cases and work tasks to Goa meeting

Decision: Revised to S4aP260005 and agreed as basis for further work

TR Skeleton (S4aP260004)

Structure Discussions

Key Issues vs. Key Questions: - Clarification requested on difference between "key issue" and "key questions" (confirmed as same) - Discussion on "context and external factors" (similar to SA2 aspects/challenges)

Clause 6 Structure: - Preference expressed not to populate Clause 6 in first meeting - Proposal to aggregate discussions in annex with moderators determining structure under each work topic - Question on whether same structure applies to all work topics (confirmed yes) - Concern about consistency of structure across work topics - Recognition that content may vary depending on topic complexity

Clause 4.2 - Use Cases: - Suggestion to rename for clarity or postpone structure agreement - "Requirements" terminology unclear - Discussion on whether SA1 use cases are sufficient or need expansion with examples - Debate on whether expanded use cases belong in Clause 4 or under work topics

Clause 7: - Note should reference "considerations in clause 6"

Annex Usage: - Unclear purpose of annex - Explained as replacement for PD (permanent document) for consolidating information - Decision on annex content migration to other clauses deferred

Proposed Way Forward

• Add editor's notes under clauses to indicate expected content
• Add editor's notes on use of annex as permanent document for consolidating information
• Finalize structure based on inputs
• Submit as new document to Goa meeting (SA4#135)

Decision: Noted (to be revised and submitted to SA4#135 with comments incorporated)

Ways of Working (S4aP260003/S4aP260006)

Key Discussions

Starting Point Assumptions: - Debate on whether assumptions about reusing existing 5G components vs. starting fresh are necessary at this stage - Concern that assumptions may be premature and should be decided over time - Question on whether 6G may have entirely new service requirements - Agreement that starting point is needed - Concern that text is unclear and difficult to understand what is being agreed

Decision: Revised into S4aP260006 and noted. Thomas Stockhammer to start email thread for iterating over the text.

Administrative Matters

IPR and Antitrust

Standard IPR and antitrust clauses were read at session opening, reminding delegates of: - Obligations to inform Organizational Partners of Essential IPRs - Compliance with antitrust and competition laws - Consensus-based decision making approach

Other Business

• Guidance provided on visa applications for Goa meeting
• Information on Montreal visa applications (contact Gaelle)

Minute Taking

• Thomas Stockhammer activated Copilot for assistance
• Saba Ahsan (Nokia) volunteered as scribe

Document Status Summary

| Document | Title | Status | |----------|-------|--------| | S4aP260001 | Proposed agenda | Approved | | S4aP260002 | Work Plan (Draft) | Revised to S4aP260005 | | S4aP260003 | Ways of working considerations | Revised to S4aP260006 | | S4aP260004 | TR skeleton | Noted | | S4aP260005 | Work Plan (Revised) | Agreed | | S4aP260006 | Ways of working (Revised) | Noted | | S4aP260007 | Meeting report | Noted |

Report from Audio SWG AH on FS_ULBC (December 2, 2025)

Executive Summary

The Audio SWG met on December 2, 2025, with 35 participants to address FS_ULBC matters, prioritizing non-treated documents from SA4#134. Key discussions covered:

• Codec Selection Process: Different approaches outlined (traditional 3GPP, collaborative, MPEG-style, combined). Concerns raised about timeline feasibility and deviation from established 3GPP processes. Offline discussions invited.

• Bundling Periods: Impact on user experience discussed for conversational vs push-to-talk scenarios, particularly regarding 320ms bundling period relevance.

• Design Constraints: Agreement to collect all design constraint proposals into the PD with references and brackets for collective editing. Stephane R. volunteered to draft.

• Codec Bitrate and Capacity: Analysis presented with differing views on realism. Offline meeting to be arranged by simulation coordinator.

• Transport Path: Editor's note agreed for PD reflecting SA2 decision on user plane, with IP vs non-IP kept open.

• Tandem Conditions: Proposal for separate transcoding function noted, with discussion on design flexibility.

• Performance Requirements: Quality targets and reference codecs discussed. Revision suggested based on feedback.

• Packet Loss Concealment: DAC experiment results agreed for inclusion in TR. Existing statement on design freedom for bitrate/BLER retained.

• RAN1 LS Interpretation: Ongoing disagreement on interpretation. Offline discussions to continue.

• Simulation Assumptions: Update agreed for PD referencing simulation process and link budget analysis.

Opening and Administrative Matters

The Audio SWG Chairman, Tomas Toftgård (Ericsson), opened the call at 22:00 CET on December 2, 2025. Standard IPR, antitrust, and consensus principles reminders were provided. Notes were taken by Thomas Stockhammer with co-pilot assistance.

FS_ULBC Technical Discussions

Codec Selection Process (S4aA250128)

Presenter: Jiayi Xu (China Mobile)

Content: - Four selection approaches outlined: - Traditional "winner takes all" (3GPP style) - Open collaborative (outside 3GPP, e.g., IETF) - MPEG-style process (call for proposals with collaborative refinement) - Combined approach (selecting baseline(s) for optimization within 3GPP) - MPEG/JPEG AI processes described as potential models - Proposal for call for proposals after TR phase - Open questions: dataset definition/sharing, Release 20 timeline feasibility, existing vs new codec, backward compatibility

Discussion: - Stefan B: Questioned motivation for deviating from typical 3GPP work item approach - Jiayi: Clarified intent to initiate discussion, not push specific direction; open to traditional 3GPP mechanism - Thomas: Emphasized timeline focus; noted MPEG process typically takes 3-4 years, incompatible with Release 20 - Zhe: Expressed support for collaborative approach - Lasse: Concerned about proper motivation needed before changing established 3GPP approach; cited successful EVS/IVAS collaborations

Decision: S4aA250128 noted. Offline discussions encouraged.

Bundling Periods and User Experience (S4aA250129)

Presenter: Lasse Laaksonen (Nokia, Dolby)

Content: - Impact of bundling periods (80, 160, 320ms) on user experience examined - Longer periods (320ms) significantly affect delay and packet loss - Clarification needed on target use cases (conversational vs push-to-talk) - No specific proposal; open for discussion

Discussion: - Markus: Supported reconsidering 320ms period if 160ms works well for transport; concerns about laggy experience - Zhe Wang: Agreed on reconsidering 320ms relevance unless required by transport constraints

Decision: S4aA250129 noted.

Design Constraints (S4aA250130)

Presenter: Stephane Ragot (Orange)

Content: - Proposal to consolidate all design constraint proposals into single document - Reference EVS approach for handling multiple inputs - Starting point: EVS codec supporting multiple bandwidths - 8 kHz likely too low for quality; 48 kHz may be unnecessarily high - Possibility of single bandwidth to reduce deployment complexity - Support key sampling rates for interworking

Discussion: - Huan-yu: Supported collecting proposals; suggested parallel development with radio simulations - Atti: Supported single sample rate to simplify SDP negotiations and remove bandwidth negotiation complications - Juan: Suggested separating sample rate and audio bandwidth discussions - Milan: Clarified unique sampling rate discussion essentially about maximum bandwidth - Jiayi: Asked about comparing codecs with different sample rates - Stephane: Referenced extensive EVS testing experience with multi-bandwidth comparisons

Agreement: - Collect all design constraint proposals into PD with references and brackets - Collective editing at later stage for fairness and efficiency - Stephane volunteered to draft initial collection

Decision: S4aA250130 noted.

Codec Bitrate and Capacity (S4aA250131)

Presenter: Huan-yu Su (vivo, Samsung, Spreadtrum, MediaTek)

Content: - Analysis of codec bit rate impact on radio resources and user capacity - Higher bit rates significantly reduce supported users - Proposal: limit codec bit rate to maximum 3 kbps for network efficiency

Discussion: - Liangping: - Analysis overly pessimistic; referenced Qualcomm contribution showing support for all bit rates with 80ms bundling - Simulation flawed: only one tone used for 15 kHz subcarrier spacing; more tones should be used for higher TBS - Using more tones would lower coding rate and improve performance - Table 5 shows high coding rate (.46) with one tone; three tones would bring below 1/3 - Even current simulation shows multiple users supported at 31 dBm - Resource allocation decisions should be left to network operators, not fixed by codec specification - Huan-yu: - Disagreed; 23 dBm devices are low-end with limitations - Designing for ideal scenarios inappropriate - Leaving decisions entirely to operators not advisable; should provide range but not extremes - Stefan Bruhn: - Scheduling in figure one not optimized; other schemes could allow better capacity - Questions on transport block size gaps and uplink/downlink resource balancing - Dong: Requested Liangping organize offline meeting as simulation coordinator

Decision: S4aA250131 noted. Offline meeting to be organized by Liangping.

Transport Path Updates (S4aA250132)

Presenter: Huan-yu Su (vivo)

Content: - Updates based on 3GPP TR 23.700-19 V1.1.0 - Recommendation: use user plane instead of control plane for GEO satellite communication - Proposed additions: editor's note, updated references, table entry changes

Discussion: - Jiayi: Asked whether editor's note for Pdoc or TR; concerns about referencing SA1/SA2 Tdocs in TR - Tomas: Clarified proposal for Pdoc, not TR; referencing acceptable in Pdoc - Markus: Asked about other interim solutions besides user plane - Dong: Explained control plane/user plane decision finalized; only IP vs non-IP remains open - Atti: SA2 agreed IP-based user plane mandatory, non-IP optional

Agreement: - Add editor's note regarding user plane solution for GEO satellite communication - Update table as needed - Keep IP vs non-IP open for future updates

Decision: S4aA250132 noted.

Tandem Conditions and Transcoding (S4aA250133)

Presenter: Noboru Harada (NTT)

Content: - Example scenarios for ULBC interworking: native ULBC and tandem with legacy systems - Table 1: target codecs for tandem conditions (updated) - Assumption: ULBC operates on single bandwidth; transcoder adjusts for legacy codecs - Transcoder modifies sampling rates using bandwidth extension - Proposal: design constraints for transcoding function separate from ULBC end-user terminals - Transcoder runs on more capable devices (e.g., PC)

Proposals: 1. Reflect tandem condition scenarios in Pdoc 2. Maintain/update target codec list for future VR reference 3. Set specific design constraints for tandem conditions and transcoding

Discussion: - Noboru: Clarified transcoder operates in separate node, not ULBC device; different complexity/memory constraints applicable - Tomas: Supported clarification - Zhe Wang: Asked if proposal requires two sets of technical solutions - Noboru: - Not requiring two solutions - Goal: ensure good quality after transcoding - Bandwidth extension/conversion not required in ULBC device; can be handled by transcoder - Provides design flexibility - Atti: Asked about expected transcoder performance - Noboru: Not yet at stage of specifying performance requirements; focus on scenarios and constraints - Stephane: Suggested including EVS Wideband 13.2 channel aware mode in target codec list

Decision: S4aA250133 noted.

Performance Requirements (S4aA250135)

Presenter: Atti Venkatraman (Apple)

Content: - Minimum performance requirements for TR 26.940 - At lowest operating bit rate (1 kbps): speech quality at least as good as ("NWT") AMR-WB at 12.65 kbps - At higher operating range (~3 kbps): match or exceed EVS super wideband at 13.2 kbps - Benchmarks using widely deployed codecs - Starting list of minimum reference codecs/operating points, expandable

Discussion: - Huan-yu: Concerned about overspecifying bandwidth; setting targets too high (e.g., 24.4 kbps) unrealistic for GEO satellite - Atti: Clarified not setting 24.4 kbps as target - Milan: Suggested EVS at lowest bit rate (7.2/8 kbps) as state-of-the-art wideband reference instead of AMR-WB 8.85 kbps; questioned relevance of higher bit rates (23.85, 24.4 kbps) - Atti: Reference codec list not meant to exclude others; focus on minimum performance requirements similar to current IMS voice services - Stefan: Asked about feasibility at 3 kbps, especially with packet loss; questioned comparison conditions - Atti: - Broad framework similar to EVS SA1 approach - Detailed tables to be developed for operating points - Comparison at 3 kbps as general minimum requirement - Further granularity for clean speech, noisy speech, packet loss conditions - Minimum quality benchmarks reflecting current IMS experience - Erik: Questioned if "better than AMR-WB 12.65 kbps" at 1 kbps too challenging for emergency situations - Atti: Clarified proposal is "NWT" (not worse than), not "better than" - Lasse: Suggested including bit rates in brackets for flexibility

Agreement: - Atti to revise proposal incorporating comments (brackets for bit rates, clarified references) - Updated version for next meeting

Decision: S4aA250135 noted.

Packet Loss Concealment with AI Codecs (S4aA250136)

Presenter: Markus Schnell (Fraunhofer IIS)

Content: - Experiment based on DAC codec - DAC IBM condition at 1.5 kbps with low packet loss rate - Other configurations from existing TR experiment - Results: higher bit rates with higher packet loss can outperform lower bit rates with lower packet loss for DAC - DAC IBM model (trained for low bit rates) outperformed all other conditions - Conclusions: - Optimal performance under error-prone conditions achieved by models trained for specific bit rates and block error rates - Bit rate scalability (as in DAC) comes with significant performance cost at lower bit rates - Specifically trained models for certain operation modes may be more efficient

Agreement: - Add new experiment and two proposed observations/conclusions to TR - Keep existing statement about allowing design freedom regarding bit rate scalability

Decision: S4aA250136 agreed.

Updates Based on RAN1 LS (S4aA250137)

Presenter: Liangping Ma (Qualcomm)

Content: - Updates to PD incorporating round one LS revisions - Key changes: references, uplink/downlink parameter corrections, modulation types, number of tones for subcarrier spacing, bundling period support, revised notes reflecting LS - Text added to figures and notes aligning with LS exceptions and conditions

Discussion: - Tomas: Pointed out uplink/downlink parameter mix-up; questioned correct number of tones and noise figures - Stefan: Noted downlink section incorrectly referenced UE maximum TX power - Erik: Disagreed with updating based on specific LS interpretation; meaning not clear; premature before further clarification through offline coordination - Liangping: - Clarified two separate issues: RAN1 LS interpretation vs decision on supporting special exception case - RAN1 LS clearly defines single exception case with three components - Intent to accurately interpret RAN1 LS - Supporting special case is separate discussion - Stefan: Emphasized need for stable assumptions all companies can agree on for consistent simulations; referenced Dallas disagreements; supported continued offline coordination

Conclusions: - Concerns from Ericsson regarding agreement on proposed changes - Topic debated in several meetings with different views - Continue offline discussions between Ericsson, Qualcomm, and interested parties - Expand discussions beyond bilateral to include all relevant stakeholders - Thomas noted discussions are very RAN-centric

Decision: S4aA250137 noted.

Simulation Assumptions and Process (S4aA250138)

Presenter: Liangping Ma (Qualcomm)

Content: - pCR to PD adding two previously agreed Tdocs: 1. Simulation contribution process (detailing assumptions for alignment) 2. Link budget analysis (verified numbers from RAN1 specifications, real-world deployment scenarios) - Help companies understand possible deployment deviations (e.g., scenarios where certain losses negligible)

Discussion: - Stefan: Concerned about need for stable simulation assumptions; referenced Dallas disagreements; questioned if addition helps achieve consensus - Liangping: Document agreed upon; provides details on possible deviations from 3GPP assumptions; helps justify simulation choices; conclusions confirmed by RAN1

Agreement: - Add proposed text and references to PD - Include note clarifying document provides analysis of possible deviations from 3GPP assumptions

Decision: S4aA250138 agreed.

LS Handling (S4aA250139)

Presenter: Liangping Ma (Qualcomm)

Content: Analysis and recommended handling of reply liaisons from other working groups to SA4 on ULBC

Decision: S4aA250139 noted without presentation (priority given to non-treated SA4#134 documents; no time for further consideration). Revision provided as new document.

Complexity Evaluation (S4aA250127)

Presenter: Xuzhou Ye (Bytedance, vivo)

Content: Complexity evaluation of ULBC audio codec

Decision: S4aA250127 noted without presentation (already treated at SA4#134; no time for further consideration).

Withdrawn Documents

• S4aA250134: [FS_ULBC] ULBC Performance Requirements (Apple Inc.) - withdrawn

Closing

The chair thanked delegates for their contributions and discussions. The call closed at 23:29 CET.

Annex A: Meeting Agenda

Meeting focused on FS_ULBC (item 1.7) with documents prioritized from SA4#134.

Annex B: Participants

35 participants from organizations including: Apple, Bytedance, CMCC, Dolby, Ericsson, Fraunhofer IIS, Huawei, Lenovo, MediaTek, Motorola, Nokia, NTT, Orange, Panasonic, Philips, Qualcomm, Samsung, Spreadtrum, Vivo, VoiceAge, Vodafone, Xiaomi, and others.

Report from Audio SWG AH on FS_ULBC (Jan 15 & 19, 2026)

Executive Summary

The Audio SWG held two meetings dedicated to FS_ULBC (Study on Ultra Low Bitrate Speech Codec) on January 15 (38 participants) and January 19, 2026 (35 participants). Key discussions covered:

• RAN simulation offline meeting report (S4aA260004) - agreed
• New 10-degree channel model and higher TBS values (S4aA260003) - noted with significant concerns
• Real-Time Factor (RTF) complexity analysis (S4aA260005) - noted, requires further work as pCR
• Device capability diversity (S4aA260006) - noted, needs coordination with RAN groups
• Timing diagram clarification (S4aA260007) - noted, requires further discussion

No proposals were agreed for inclusion in the TR at this stage. Several contributions require additional offline work and clarification.

S4aA260004: RAN Simulation Offline Meeting Report

Status: Agreed

This document reported on the offline meeting held December 10, 2025, covering:

• Discussion on optimal configurations for different TBS values
• Use of DMRS bundling
• TBS values for 80 ms bundling period, with largest value of 424 bits
• Qualcomm's study suggesting increase to 440 bits, resulting in lower BLER and allowing larger target in risk allocation

Discussion: No comments raised.

Decision: Document agreed without modifications.

S4aA260003: Feasible Bitrates for 10-Degree Elevation Angle Channel Model

Status: Noted (not agreed)

Technical Content

Qualcomm and Xiaomi proposed new TBS values based on a 10-degree elevation angle NTN-TDL-C channel model, arguing it is more realistic than the initial 50-degree model from TR 38.811.

Key differences from initial channel model: - Lower elevation angle (10 degrees vs. 50 degrees) - Higher K-factor (25 dB vs. 0 dB) - Claimed to be closer to field measurement data

Proposed TBS values: - Without DMRS bundling: up to 932 bits feasible - With 10 ms scheduling/timing penalty (worst case): up to 680 bits feasible - Highest net bit rate: ~11 kbps (at 31 dBm transmit power) - BLER remains below 2% target for both uplink and downlink

Proposal: Amend TBS value tables for different bundling periods (80ms, 160ms, 320ms) to include higher values, with last row changed to "net bit rate" to clarify these are thresholds, not operational rates.

Discussion Points

Concerns about channel model applicability (Ruonan): - Questioned whether new TBS values apply only to 10-degree elevation or all angles - Noted simulation calibration was done for 50-degree elevation, not 10-degree - Lack of link budget details in the paper - Calculated different link budget with little difference in simulated TBS performance - Major concern: System capacity supports only one UE uplink and three UE downlink per beam - considered insufficient

Liangping's responses: - New TBS values only for new channel model (stated in paper) - Field data shows 10-degree model closer to reality due to higher K-factor - Downlink can support more than one UE within 80 ms period - Uplink can use multiple tones - Total supported UEs per satellite much higher due to multiple beams - System capacity should be determined by network operator

Timing and feature dependencies (Erik): - Questioned impact of DMRS bundling wording - Sought clarification on "no uncertainty" scenario regarding UE-specific Koffset and TA report - Questioned whether TA reports and UE-specific Koffset fully accounted for in link-level simulations - Expressed hesitation about the approach

Liangping's clarifications: - TA report impact minimal for GEO satellites (only during connection setup) - Both scenarios (with and without these features) considered in analysis - Worst-case scenario (without features) still supports 680 bits TBS

Power consumption concerns (Stefan B): - High transmit power (31 dBm) impact on overall power consumption and battery drain - Whether all UEs required to support high power classes - Whether 31 dBm is mandatory in Release 19

Liangping's responses: - Higher transmit power increases power consumption (radio efficiency ~50%) - For automotive use cases, power less of an issue - 31 dBm supported for handheld devices per specifications - 26 dBm and 31 dBm will be supported in Release 19 - Average power for handhelds (considering silence periods and half-duplex) comparable to 2G SAR situations

Field measurements and codec relevance (WangDong): - Questioned whether 10-degree model and high bit rates (11 kbps) supported by field tests - Concern about necessity when existing codecs (EVS at 9.6 kbps) provide sufficient quality - Why new TBS values needed if existing codecs already effective at lower rates

Liangping's responses: - New values consistent with new channel model based on field measurements - Field tests not conducted at 31 dBm due to lack of available devices - 11 kbps is theoretical maximum under specific conditions (31 dBm) - Lower transmit power results in lower bit rates - Radio perspective requires reporting maximum feasible bit rate, not prescribing codec operation

Codec design perspective (Markus Schnell): - Questioned usefulness of very high bit rates (11 kbps) when EVS at 9.6 kbps already provides high quality - Some lower bit rates (e.g., 6.6 kbps) may lack suitable 3GPP codecs - Suggested focusing on identifying gaps in 3GPP codec coverage - Could help with system capacity concerns

Liangping's response: - Simulation results provide upper limit and intermediate values - Designers don't have to use highest bit rates - Lower bit rates allow more simultaneous users - ML-based codecs could potentially offer better quality at same bit rate vs. EVS

Multiple TBS values interpretation (Stefan, Thomas): - Question about intention behind listing many TBS values - Thomas clarified: table provides factual information from simulation studies, not codec design mandates - Not about standardizing codec for all bit rates - Provides net bit rate data for reference

High bit rate concerns (Ryan Lee - Samsung): - Reluctance about including higher bit rates - Focus should remain on ultra low bit rate codecs - If higher bit rates included, should clearly state only applicable for 31 dBm scenarios - Should be deprioritized as only relevant for limited high-power cases

Process concerns (Jiayi): - Field measurements should be verified/cross-checked by multiple companies - Multiple companies have proposed TBS values (documented as open issues) - Recommended reviewing all proposals together - Suggested separating topics of elevation angle and TBS value

WangDong's process concern: - Not the right time to add new TBS value proposal to open issues list - Introduces dependencies and complexities related to elevation angles - Should be considered separately

Decision

S4aA260003 noted - No consensus to adopt new TBS values or add to open issues table. Several participants indicated the proposal introduces new dependencies (elevation angle) and should not be added to open issues at this time. Tomas recommended further offline discussion with topic to be revisited in future meetings.

S4aA260005: ULBC Complexity and RTF Analysis

Status: Noted (requires pCR before TR inclusion)

Technical Content

Dolby, Nokia, and Novamint presented updated RTF (Real-Time Factor) analysis for DAC algorithm, resubmitting previous contribution (SA4134) with updates based on Vivo suggestions.

Updates included: - More detailed information on models - Addition of graphs illustrating RTF numbers - Focus on RTF metrics for different model sizes

Key findings: - RTF measurements for models ranging from 20 million to 70 million parameters - Performance tested on multiple devices with different thread configurations (1 thread vs. 4 threads) - Some anomalies observed (e.g., worse RTF with 4 threads vs. 1 thread on certain devices)

Discussion Points

RTF anomalies (Jiayi): - Why RTF with 4 threads worse than 1 thread for certain devices - Whether issue occurs only with DAC or other algorithms - Requested clarification on RTF definition (RTF > 1 indicates real-time processing)

Rishabh's responses: - No clear explanation for worse 4-thread performance (possibly model size limitations or noise) - Document presents observed numbers without drawing conclusions - Agreed to add clarifying sentence about RTF definition

Processor details (Markus S): - Which processor/core type used in one-thread mode (high-performance vs. low-power) - What happens during first frame (cache loading vs. initialization/memory allocation) - Whether software optimized for this case

Rishabh's responses: - Specific processor/core type currently unknown, will investigate - First frame performance mostly affected by cache loading - Cache flushing can cause steady-state numbers to resemble first-frame numbers

Model size and quality (Huan-yu): - Whether optimization maintaining same subjective quality - Concern about comparing models of different sizes - Even 20 million parameters considered large - Asked if smaller models (e.g., 10 million parameters) tested

Rishabh's responses: - Subjective quality not focus of document - Goal: assess real-time performance for different model sizes - Only models down to 20 million parameters tested so far - Hope to include smaller models (10 million) in future meetings

Runtime environment details (WangDong): - Which dedicated core used for ONNX runtime execution - Speed (1 GHz or max GHz) - CPU capacity and memory usage during inference - Frame-by-frame simulation setup with non-causal model

Rishabh's responses: - Only overall maximum CPU descriptions currently available - Need to gather detailed runtime information - Frame-by-frame setup presents 80 ms data at a time - Goal: measure real-time performance under constraints, not quality

TR inclusion discussion: - Zhe questioned whether clause 6.4 appropriate place (not just "additional design considerations" if only observations) - Huan-yu concerned about including incomplete data, preferred waiting for complete information - Thomas suggested creating pCR to clarify where and how text should be included - pCR should be agreed before content added to TR

Decision

S4aA260005 noted - Group agreed to proceed by: 1. Gathering more information (especially core usage details) 2. Preparing pCR for the contribution 3. Ensuring proper formatting and references before TR inclusion 4. Improving figure clarity for better readability

S4aA260006: Device Capability Diversity

Status: Noted (requires coordination with RAN groups)

Technical Content

Dolby and Nokia presented discussion on diversity of UE capabilities and impact on system performance and scheduling.

Key points: - Devices have varying transmit power classes and receive antenna configurations - Significant impact on link-level performance - Relying on single baseline capability limits system performance, especially for lower-capability devices - Allowing diverse UE capabilities enables better system capacity and performance

Proposed strategies: - Dynamic scheduling: shorter periods for higher-capability devices, longer for lower-capability devices - Enable multi-tone transmission for higher transmit power devices - Service differentiation: baseline, intermediate, and enhanced services based on device capabilities or subscription levels

Proposal: - Add new clause on UE capabilities in TR 26.940 - Update multi-user considerations - Remove assumption that all devices use same configuration - Start with three target bit rates for codec selection reflecting device capability range

Example UE types discussed: - Type A (enhanced): higher transmit power (31 dBm), two receive antennas - Type C (baseline): lower transmit power (class 3), single receive antenna

Discussion Points

Applicability concerns (Ruonan): - Whether enhanced UE types (e.g., Type A) exclusively for shorter bundling times (80 ms) - Would this exclude baseline UE types like Type C

Stefan's response: - Example illustrative but based on analysis - Baseline UEs with limited transmit power struggle at short bundling times - Operators may need longer periods (160 ms) for such devices - Main point: allow diverse UE capabilities, not forbid them

Coordination with RAN groups (Erik): - Supported idea of different UE capabilities - UE features typically specified by RAN1, handed to RAN2 for defining capabilities - Suggested coordination between groups on this matter - Need awareness and coordination regarding specification and definition

SA4 remit concerns (Andrei): - Defining UE capabilities not within SA4's remit - Topic relevant for service and bit rate discussions - Asked how Stefan intends to continue given NB-IoT defines categories and 5G NR defines capabilities - Need to relate proposal to these frameworks and coordinate with RAN groups

Stefan's response: - Contribution aims to open discussion and highlight various UE capability assumptions - Expertise on UE capabilities lies outside SA4 - Open to input from responsible working groups - Ensure clear language in TR without pushing/mandating specific features

SPS scheduling concerns (WangDong): - UE capabilities should not be defined within SA4 - SPS scheduling mechanisms being studied in RAN2, should not be defined in SA4

Stefan's response: - SPS scheduling idea not new to this contribution - Previously discussed in group and TR - Need to be careful about what will be specified - Assuming SPS usage not unique to this contribution

Technical details (Liangping): - Concerns about UE power references - suggested using text from NB-IoT NTN LS instead of NB-IoT reference - Gain from two receive antennas could vary (more or less than 3 dB) depending on orientation - MIMO as future consideration - Overall concepts good but need accurate details and terminology

Interoperability (Markus Schnell): - Asked about interoperability between different device classes - Whether enhanced classes can always communicate with basic classes - Maximum transmit power for NB-IoT devices (referenced 20 dBm value) - Whether new power class considered in channel simulations

Stefan's response: - Some form of capability exchange or system awareness assumed for interoperability - 20 dBm (Class 5) power class believed to be defined - No new requirements proposed

20 dBm power class discussion: - Tomas noted 20 dBm class not previously considered - Liangping: 20 dBm included due to specification copy-paste, but 23 dBm more common for smartphones - Stefan: 20 dBm listed to keep options open for wearables, could be removed if unnecessary

Process suggestion (Andrei): - First collect assumptions from link-level simulations - Categorize achievable rates into three device capability categories - Share assumptions and results with RAN groups for feedback - Get confirmation on existing capabilities matching these categories

Stefan's agreement: - Various companies perform simulations based on different UE capability assumptions - Support documenting assumptions transparently - Clarify these are current working assumptions needing confirmation from responsible groups

Decision

S4aA260006 noted - Several comments and concerns raised, particularly about: - SA4's remit in defining UE capabilities and SPS scheduling - Need for coordination with RAN1 and RAN2 - Proposal not agreeable at this point - Participants encouraged to consider potential updates offline

S4aA260007: Scheduling Timing Uncertainty

Status: Noted (requires further discussion)

Technical Content

Qualcomm and Ericsson presented collaborative analysis addressing interpretation of RAN1 LS 1654 regarding uplink timing uncertainty between UE and base station.

Key points: - Timing uncertainty affects UE scheduling capacity - Analysis clarifies when two timing diagrams (Figures 3-2 and 3-3) are equivalent for UE scheduling capacity

For 80 ms bundling period: - Equivalence achieved when maximum differential delay is 10 ms - Corresponds to cell size of 1500 km - Timing constraint: X+Y ≤ 68 ms

For 160 ms bundling period: - Similar analysis with corresponding conditions

Proposal: Remove previous text in permanent document and replace with clarified conditions.

Discussion Points

Wording and calculation concerns (Ruonan): - Confusion about maximum differential delay (10 ms) calculation - Questioned applicability to GEO satellite coverage - Whether restriction on X+Y necessary for different cell sizes and bundling times - Concern about taking assumption as baseline - Value may need evaluation by other groups (e.g., RAN1)

Liangping's responses: - 10 ms refers to roundtrip maximum differential delay, not baseline - Calculation based on cell size and elevation angle - Document doesn't define maximum differential delay, provides equivalence conditions - Cell size for 10 ms roundtrip delay is 1500 km (calculated using speed of light and worst-case elevation angle) - Open to removing baseline assumption if problematic - Need baseline when running simulations

Practical impact (Stefan): - Asked about practical impact of changing from 10.3 ms to 10 ms - Difference seemed minor regarding cell size and coverage - Wanted to understand point of contribution

Liangping's response: - Difference in cell size very small (proportional to differential delay) - Main purpose: identify condition where two timing diagrams are equivalent - Affects available resource for uplink scheduling

Further concerns (Ruonan): - Continued questioning necessity and clarity of wording - Possible misunderstanding - Offered to provide revised version based on their understanding

Process discussion: - Tomas: group would wait for proposals and updates - Liangping: suggested starting with email discussion to resolve issues - Offline meeting only if necessary to avoid inconvenience

Decision

S4aA260007 noted - Further discussion needed on wording and assumptions. Group to proceed with email discussion and potential offline work before reconsidering.

Meeting Administration

Meetings held: - January 15, 2026, 14:00-15:09 CET (38 participants) - January 19, 2026, 14:00-14:53 CET (35 participants)

Chair: Tomas Toftgård (Ericsson)

Notes: Thomas Stockhammer (with assistance of co-pilot)

Acknowledgment: Thomas Stockhammer thanked for assistance with meeting notes.

All participants reminded of IPR policies, antitrust/competition law compliance, and consensus principles.

RTC SWG Report Post SA4#134

Executive Summary

The RTC SWG held two adhoc calls post SA4#134 with 15 input contributions and 24 participants in the first adhoc, and 10 input contributions and 30 attendees in the second adhoc. Two tdocs were agreed.

Key Outcomes by Work Item:

• AIML_IMS_MED: Agreed to create one CR to TS 26.114 as output. Based on SA2 LS response, agreed to complete work with local/split/remote on DC AS (instead of MF) and document limitations. Agreed on device-inference call flow as basis for further work.
• FS_DCTC_eQOS_MED: Discussion on test platform continued.
• FS_Q4RTC_MED: Agreed on work plan and discussed TR skeleton and basic QUIC protocol.

AIML_IMS_MED (Media Aspects for AI/ML in IMS Services)

Scope Definition and Architecture

S4aR250216 - Scope in Light of SA2 LS

The group discussed the scope following the SA2 liaison response. Key decisions:

• Agreed to complete work with local/split/remote inferencing on the DC AS (Data Channel Application Server) rather than the MF (Media Function)
• Document limitations (e.g., DC AS not present for P2P case, so only UE inferencing may be possible for P2P)
• Send LS to SA2 with more details on SA4's needs and scope
• Take approach similar to Annex AC P2P and P2A2P: MF as relay, same approach for remote/split (P2A2P) and local (P2P)

Call Flows

S4aR260004/S4aR260014 - Call Flow for Device Inferencing

Joint contribution from Samsung and InterDigital. After extensive discussion:

• Agreed as basis for further work with modifications:
• Steps 8-9 (model fetching by MF before application data channel establishment) removed
• Editor's notes added regarding:
  • How to handle large models
  • Network capability considerations
  • Model selection mechanisms
  • Caching requirements in UE

Key discussion points: - Model sizes can be significant (e.g., 80 MB), requiring consideration of download time and network impact - Application metadata would indicate supported tasks; JavaScript in application can check UE capabilities - MF acts as HTTP proxy and can cache - Need for both UE-side and network-side caching solutions - Partial model updates and model compression need to be addressed

S4aR250205 - Call Flow for Device Inferencing (Samsung)

Initial proposal that was merged into S4aR260004. Noted for further work.

S4aR260007 - Call Flow for Device Inferencing Update (InterDigital)

Discussion focused on: - Clarification needed on whether this replaces normal BDC bootstrap procedures - Terminology should be moderated to clarify high-level stage 2 description - Protocol details need refinement

S4aR250206 - Call Flow for Network Inferencing

Noted. Needs update to reflect inferencing on DC AS instead of MF. Questions raised about model download source (DCAR vs DC AS).

S4aR250207/S4aR260008 - Call Flow for Split Inferencing

Noted. Similar to network inferencing but for split scenarios. Needs update to have split inferencing on DC AS rather than MF. Parameters in request/response messages need synchronization with other proposals.

S4aR250218 - Update Call Flow for Local/Remote/Split AIML Inferencing (InterDigital)

Noted. Needs update due to MF/DC AS changes. Proposed two data channels: one for configuration and one for data exchange. Terminology modifications needed for steps 1 and 3.

Task and Model Management

S4aR250208 - On AI Application Tasks and Subtasks

Noted. Discussion on whether to use subtask concept or stay with application/task/model terminology. Clarity needed on subtask definition before adoption.

S4aR250209/S4aR260006 - AI/ML Media Processing and Task Updating (Nokia)

Noted. Addresses task reselection and task update scenarios: - Task update vs. new task may require different procedures - Distinction between updating a model vs. adding new capabilities (e.g., translation language) - In P2P case, may need application data channel - Clarification needed on whether "network functions" refers to MF or other entities

S4aR250211 - Adaptive Model Delivery (Nokia)

Noted. Proposes two cases: 1. Standard model delivery 2. Adaptive delivery with MF as proxy

Discussion points: - Need clarification on model selection process (UE, user, or other entity) - Low precision and incremental model updates need more description - Make model update optional in second case

Application Manifest and Negotiation

S4aR250213/S4aR260011 - On Application Manifest for AIML Applications (Nokia)

Noted. Proposes JSON format for application manifest with metadata. Needs alignment with other contributions. Email discussion to be triggered on this topic.

S4aR260009/S4aR260012 - Negotiation Messages (InterDigital)

Noted. Proposes metadata for negotiation messages. Questions raised: - Where will application info format be used? - Are we defining a new DC protocol? - Motivation is to identify what metadata needs to be considered

S4aR260010 - Negotiation Messages for Split Inferencing

Noted. Needs revision to sync with basic call flows.

Codec and Compression

S4aR260005 - On NNC Decoding in Web Environment (Fraunhofer HHI, Nokia)

Noted. Discussion on Neural Network Coding (NNC) decoder in web environment. No alternative decoder currently available. Comparison document to be shared on differences.

Specification Strategy

S4aR250215 - Discussion on TS

Agreed to add an annex to TS 26.114 and prepare CR accordingly. Consensus for smaller scope with annex in 26.114 rather than separate specification.

S4aR250217/S4aR250220 - Draft CR on AIML Processing in IMS Calls

Noted. Will be developed as CR to TS 26.114 based on agreed scope.

FS_DCTC_eQOS_MED (Study on Usage of Dynamically Changing Traffic Characteristics and Enhanced QoS Support)

Technical Report

S4aR250212 - Draft TR 26.823

Noted. Presented for information. Issues identified: - No revision marks and incorrect version number - Missing agreed document numbers in change history - Style conformance issues - Skeleton was only agreed in closing plenary

Expected revision for next adhoc with: - Change marks - ETSI style compliance - Agreed documents listed in annex - Correct version number

Evaluation Strategy

S4aR250219 - Evaluation Testing Strategy Proposal (InterDigital)

Noted. Discussion points: - Network impairment testing vs. in-the-field testing needs more work - No need to limit to one evaluation platform - RTT measurement possible also for QUIC - Need details on "specific" platform and parameter sources - Which specific application for AI testing - Hard to set up OPs for OTT; need reference platform with control - Joint meeting with other evaluation/studies to develop common evaluation framework - Reference to 26.955 for joint discussion - QoE metrics handling needs resolution

FS_Q4RTC_MED (Study on QUIC for RTC Media)

Work Plan

S4aR250210/S4aR250221 - Draft Work Plan for FS_Q4RTC_MED

Agreed (S4aR250221). Discussion points: - Note on normative work to be triggered before end of study - Evaluation work needs alignment with other studies - Need clear item in timeplan on common evaluation framework - Coordination with QStream starting from Goa meeting - Careful on "common" aspects as different tools may be needed

Protocol Overview

S4aR260001/S4aR260013 - Overview of QUIC-based Media Delivery Protocols (Nokia)

Noted (S4aR260013). Good base document. Comments to be provided by email on requirements and other aspects.

Technical Report Skeleton

S4aR260003 - Draft TR 26.836 v0.0.1 (Skeleton) (NTT, Nokia)

Noted. Issues identified: - Clause 4.2.3 number missing - Some existing content can be moved to annex - Pros and cons need clarification (for RTC or general?) - Introduction/title of 5.3: F→Functional - Consider including evaluation under each application scenario - Version number needs offline check with Andrijana

Meeting Details

First Adhoc Call: - Date: December 17, 2025, 14:00-16:21 CET - Host: Nokia - 15 input contributions, 24 participants

Second Adhoc Call: - Date: January 28, 2026, 15:00-17:15 CET
- Host: Nokia - 10 input contributions, 30 attendees

Minutes taken by Gaëlle Martin-Cocher (first adhoc) and Bo Burman/Shane He (second adhoc).

3GPP SA4 MBS SWG Post-134 Ad Hoc Meeting Report

Meeting Overview

Two ad hoc sessions were held: - Session 1: December 18, 2025, 15:30-17:38 CET (28 participants) - Session 2: January 29, 2026, 15:30-17:35 CET (29 participants)

The meetings focused primarily on the FS_Energy_Ph2_MED study (Media Energy Consumption Exposure and Evaluation Framework Phase 2), with additional discussions on Release 19 corrections, Advanced Media Delivery Phase 2, and a new QUIC-based streaming study.

Release 19 and Earlier Matters

MBSF Notification Event Corrections (S4aI260006)

Contribution: BBC (Richard Bradbury)

Technical Content: - Corrects discrepancies between SA4 stage 2 specification (TS 26.502) and CT3 stage 3 specification found during reference implementation - Adds two missing events to align with CT3: - "User data ingest session starting" (indicates start of active period) - "User data delivery has started" (confirms broadcast MBS session start) - Simplifies table by factoring out repetitive information - Corrects sequence diagram to ensure correct identifier is passed back - Editorial fixes for clarity

Impact: Corrective changes only; aligns SA4 spec with CT3 with no impact on CT3 work. Similar corrections planned for Releases 18 and 19.

Decision: Agreed

FS_Energy_Ph2_MED (Study on Media Energy Consumption Exposure and Evaluation Framework Phase 2)

Energy-Related Information for Media Application Services (S4aI250198)

Contribution: BBC (Richard Bradbury)

Technical Content:

Key Gaps Identified: - Current EIF (Energy Information Function) from Release 19 only covers user plane network functions (gNB, UPF) - Does not cover energy consumed by Application Servers (AS) or User Equipment (UE) - AS are not network functions and do not provide energy information to EIF

Proposed Abstract Data Model: - Hierarchical model for 5G media streaming allowing energy apportionment at multiple levels: - Application server instance - Content hosting configuration - Distribution configuration - Streaming session - Service data flow - Generic energy report structure with baseline parameters: - Timestamps - Energy consumed (joules) - CO2 emissions per joule - Data volumes (uplink/downlink) - Session IDs - Endpoints - Extensible for specific use cases

Recommendations: 1. Update TR to clarify EIF scope (Proposal 1 & 2: Agreed) 2. Require candidate solutions to include procedures and parameters for collecting/aggregating energy data from AS, NFs, and UEs (Proposals 3, 4, 5: Endorsed in principle) - Not gating for existing solutions - Template/examples to be developed with Julien - CRs to be prepared for next meeting

Discussion Highlights: - Franck questioned use of data volume vs. direct energy reporting; Richard explained flexibility for different architectural solutions - Prakash questioned value of AS energy exposure; Richard affirmed importance given gap in Release 19 - Rufael emphasized factual accuracy when referencing TS 23.501 and avoiding overlap with other groups - Thomas noted TR should not self-reference; context to be clarified in CR

Decision: Agreed (with follow-up CRs expected)

Solution for KI5: Media Application Server Energy Management (S4aI250199)

Contribution: Orange, BBC (Julien Lemotheux, Richard Bradbury)

Technical Content: - Candidate solution for 5GMS focusing on selection of media streaming service location driven by content steering server based on energy characteristics - Added new procedures for solution #5 in clause 7.6 - Missing steps for streaming session management now included and renumbered - Improved text and procedures based on feedback

Minor Corrections Identified: - Remove "downlink" from Step 5 in diagram 7.6.3.2 to make procedure generic - Typo in 7.12.2 to be addressed

Decision: Revised to S4aI250208; Endorsed (with minor corrections to be incorporated before merging into Mega CR)

Solution for KI6: Client-Driven Management (S4aI250200)

Contribution: Orange (Julien Lemotheux)

Technical Content: - Candidate solution for Key Issue 6: client-driven management of media delivery service energy optimization - Title updated to "Client Driven Selection of Media Entry Point in the Generalized Media Delivery System Based on Energy Characteristics" - Replaced terms like "SIM variant" and "delivery pass" with "media entry point" - Allows client to reconfigure media handler during session to select different entry point based on energy characteristics - Playback resumes from previous position (similar to Netflix/Amazon session resumption)

Discussion Highlights: - Richard noted switching entry points mid-session is disruptive (black screen/spinner) and needs better description - Shilin questioned step numbering discontinuity and why media entry points passed to media-aware application rather than directly to media stream handler - Julien explained application needs entry point information to make selection

Decision: Revised to S4aI250210; Noted (further clarification needed)

Updating Key Issue Description on Application Service Provider Provisioning (S4aI250202)

Contribution: Samsung (Prakash Kolan)

Technical Content: - Addresses three SA1 use cases related to energy provisioning: 1. Dynamic service adjustment based on network energy information 2. Service adjustments based on energy configuration 3. Tolerance to QoS degradation - Proposes adding table summarizing different way forward options for these use cases into TR - Provides reference points for candidate solutions to map to specific options

Discussion Highlights: - Richard noted contradiction in requirement 5.3 "tolerance to QoS degradation" - content suggests optimizing without degrading QoS - Julien suggested simplifying/merging options (e.g., option 2 with option 1; options 3 and 4) - Prakash agreed to work on simplification

Decision: Endorsed as basis for future work (with simplification to be addressed in revision)

Greening of Streaming Collaboration (S4aI250203)

Contribution: Qualcomm (Thomas Stockhammer)

Technical Content: - Update on interactions with Green Streaming (GSS) organization - GSS focus: streaming app energy measurement and CDN (complementary to 3GPP telco aspects) - GSS ongoing projects: - Remote energy measurement platform - Yang data model for energy - White papers - Proposal: Joint online webinar (90-120 minutes) on energy awareness in mobile streaming - Involve 3GPP, GSS, and other organizations - Schedule before next 3GPP meeting - Goal: information exchange and awareness raising

Discussion Highlights: - Julien noted timing challenge as study aims to finish in Goa - Rufael welcomed industry input for documentation in TR - Richard interested in Yang data model - Gaëlle noted first meeting useful for mutual understanding even if not immediately impacting TR

Decision: Noted; Thomas to discuss with 5G-MAG and sync with rapporteur

Solution for KI1 and KI4: Energy-Related Information Collection (S4aI250204, S4aI250207)

Contribution: InterDigital (Franck Aumont)

Status: Not presented due to time constraints

Decision: Noted without presentation; to be resubmitted

Solution for KI5: Media Application Server Energy Management (S4aI250206)

Contribution: Nokia (Daniel Venmani)

Technical Content: - Candidate solution for relocating media application servers based on energy consumption at different service locations - Procedure: 1. Launch media session 2. Collect QoE measurements from UE 3. Energy Information AF requests energy consumption reports from media AS for each service location 4. AF ranks service locations by energy consumption 5. AF informs UE to enable selection of most energy-efficient location - Main technical focus: enabling AS to report energy consumption per service location (current gap in SA4)

Discussion Highlights: - Richard questioned necessity of steps 9, 18, and 23 in call flow; suggested removal - Richard noted expanding EIF to include AS information is outside SA4 remit (SA2 responsibility) - Rufael emphasized AS energy reporting should be handled by EIAF within SA4, not by expanding EIF scope - Prakash and Julien noted similarity to Julien's solution; suggested merging and highlighting differences - Main difference: use of QMC and source of information

Decision: Revised to S4aI250209; Noted (not endorsed due to outstanding comments; further work needed)

Update Summary of Energy Information Function (S4aI260009)

Contribution: BBC, Orange (Richard Bradbury)

Technical Content: - Expanded summary of EIF based on latest Release 19 developments from SA2 - Incorporated corrections from Rufael (Huawei): - Terminology aligned with TS 23.501 ("energy consumption information" not "energy related information") - EIF obtains energy data from OM and computes values per PDU session using SMS information - Describes what SA2 studied and specified in TS 23.501: - EIF role in collecting, calculating, and exposing energy consumption data at various granularities - Added stage 3 specification details (TS 29.566, TS 29.122): - Structure of energy notifications and reports - Timestamps and optional energy info data (joules consumed during reporting period)

Discussion Highlights: - Rufael emphasized importance of consistency with SA2 outcomes - Franck raised concern about information granularity difference: - 5GC NF can request per QoS flow data - Media AF cannot get per QoS flow data (potential loss of granularity at data flow level) - Richard clarified text comes from baseline TR 26.942 Release 19; if discrepancy exists, separate CR needed

Decision: Agreed (to be added to merged common CR)

Principles for Documenting Candidate Solutions (S4aI260010)

Contribution: BBC, Orange (Richard Bradbury, Julien Lemotheux - Rapporteur)

Technical Content: - Guidelines for documenting candidate solutions as annex to TR - Standardizes structure inspired by previous studies (e.g., TR 26.804 for AMD) - Proposed skeleton includes: - Mapping to key issues - Functional description - Collaboration scenarios (referencing annexes in TS 26.501/26.506) - Architecture mapping - Energy-related information (baseline parameters) - Procedures (including sequence diagrams) - Gap analysis (deltas from current specs) - Proposed normative changes - Summary

Clarifications: - Template applies to new candidate solutions added during phase 2, not existing solutions from phase 1 - Goal: help extract normative work and analysis for conclusion section - Not intended to modify existing solutions already in TR

Discussion Highlights: - Thomas questioned purpose if not applied to existing solutions; concerned about methodology for evaluation - Julien explained template facilitates aggregation and analysis for new contributions - Richard noted both key issue-centric and solution-centric approaches valid; selection for normative work addressed later

Decision: Agreed

Media Application Service Model (S4aI260012)

Contribution: BBC (Richard Bradbury)

Technical Content: - Conceptual model to clarify what constitutes media application service - Hierarchical structure: - Media delivery session consists of service data flows - Service data flows consist of application data flows - Examples: segmented media delivery, RTC sessions - Accounts for deployment dynamics: - Peer-to-peer sessions - Multiple service location endpoints - Endpoints on different physical/virtual servers (including edge) - Network considerations: - Traffic routing depends on UE route selection policy - Multiple PDU sessions, network slices, access networks - UE mobility and edge computing - Energy implications: - Energy consumption changes dynamically due to these factors - EIF does not provide complete picture (lacks AS and UE energy visibility) - Mapping to 5GMS and RTC models detailed

Discussion Highlights: - Thomas concerned about introducing many new capitalized terms and abstract definitions - Potential complexity and divergence from existing 5GMS architecture - Questioned if new concepts require updates to TS 26.501/26.506 - Nervous about implications for future normative work - Richard clarified: - Conceptual framework for informational purposes only - Not new data model or intended for normative work - Most terms already in existing specifications - Generic model, not specific to 5GMS or RTC - Iraj questioned if model covers entire 5GMS operation or just energy consumption - Richard: conceptual overview for user plane operations, arranging existing concepts - Prakash supported inclusion; most terminology already referenced in SA2/SA4 specs - Julien: model important for structuring report and clarifying granularity levels

Resolution: - Thomas requested clear scoping to TR only, not basis for normative changes in existing specs - Introductory text explaining rationale and scope to be added - Richard agreed to add clarifying text

Decision: Endorsed (with clarifications to be added in revision)

Solution 5 Update (S4aI260016)

Contribution: Orange, BBC (Julien Lemotheux, Richard Bradbury)

Technical Content: - Updates to candidate solution 5 defining Energy Information Collector and Energy Information Application Function - Goal: establish baseline procedures for energy information reporting reusable by other candidate solutions - Key changes: - Clarified subscription and reporting process with EIF - Information requests now require subscription detailing needed data (service data notification, application ID) - Standardized process: after subscription, EIF exposes energy report to requesting component - Same principle applies to reports from Energy Information AF and Energy Information Collector - Initial reporting step introduced: - Configure and receive first report before media session starts - Ongoing reporting during media streaming session - Updates as more detailed information (e.g., IP 5-tuple) becomes available - Aligned with new template for candidate solutions: - Includes gap analysis section - Includes proposed normative changes section - Special numbering to avoid disrupting references in other TR parts

Discussion Highlights: - Richard: Steps 18 and 19 should be inside loop - Richard: Step 7 should happen as result of media session, not provision (steps 7-9 need to move up) - Daniel questioned motivation for EIAF to choose client and for client to move between AS - Julien acknowledged missing information

Decision: Revised to S4aI260027, then S4aI260028; Noted (further revision needed)

Other Energy Phase 2 Solutions

Multiple additional candidate solutions were submitted but noted without presentation due to time constraints:

• S4aI260013: Candidate Solution on Application Server Energy Information (BBC, Orange)
• S4aI260014: Solution for KI5 Media Application Server Energy management (Orange)
• S4aI260015: Solution for KI6 Client-driven management (Orange)
• S4aI260017: Solution for KI5 Client-based Media Application Server selection (Nokia)
• S4aI260018, S4aI260019: Solution for KI1 and KI4 (InterDigital)
• S4aI260021: Solution for KI6 on Client-driven switching between multipath and single path (Samsung, Nokia)
• S4aI260022: Solution for KI6 Client-driven management (Nokia)
• S4aI260023: Solution for KI4 and KI6 on Energy driven media service degradation (Samsung)

All to be resubmitted for SA4#135 in Goa.

FS_AMD_Ph2 (Study on Advanced Media Delivery Phase 2)

Network Assistance for Multi-Access Media Delivery (S4aI250201)

Contribution: Samsung, Nokia (Prakash Kolan)

Decision: Noted without presentation; to be resubmitted

5G System-Independent Media Streaming (S4aI250205)

Contribution: Qualcomm (Thomas Stockhammer)

Decision: Noted without presentation; to be resubmitted

CMMF for Media Delivery over Multiple Access Networks (S4aI260020)

Contribution: Dolby (Jason Cloud)

Technical Content: - Discussion paper on using CMMF (Common Media Format) for multi-access media delivery within 5G system - Application-layer based approach - Implementation: - Multi-access capability in media player's access client - Multiple HTTP clients initialized, each bound to different network interface - Enables concurrent downloads from various access networks - Example: client connected to both Wi-Fi and 5G can toggle interfaces or handle network degradation - Integration with 5G system: - Mirrors multi-service location use case - Minimal architecture changes required - Mainly notes in call flows and potential client setup details in stage 3

Discussion Highlights: - Richard questioned feasibility on 3GPP UE (application awareness of ATSSS, interface abstraction) - Prakash clarified: - For ATSSS transparent mode, Richard's concern valid - Non-transparent mode: application aware of delivery - Application multipath supported in spec - Jason confirmed Android clients expose interfaces to application, allowing binding - Thomas expressed confusion: - Application would not see two HTTP clients or access networks as described - Functionality handled under the hood, outside 5G media streaming scope - Changes should be addressed in IETF protocols - Does not align with Release 20 multi-access discussions - Very different from ATSSS - Richard suggested issue might be implementation detail rather than specification concern

Decision: Noted for now

Other Release 20 Matters

Work Plan for QUIC-Based Protocols Study (S4aI260024)

Contribution: Xiaomi (Emmanouil Potetsianakis)

Technical Content: - Work plan for FS_QStream_MED study - Focus: segmented media delivery for on-demand and live video services - Objectives: 1. Identify relevant applications, protocols, and technologies 2. Develop evaluation framework 3. Conduct evaluations 4. Integrate findings 5. Coordinate with other groups - Output documents: - TR 26.934: Test platform for media delivery technologies (joint with QUIC study of RTC) - TR 26.835: Evaluation of QUIC-based streaming protocols - Timeline: - Goa meeting: Finalize work plan and specification skeletons - Early phase: Application selection, metrics definition - Subsequent meetings: Test framework design, technology definition - Later stages: Simulation setup, platform development, communication with external groups, result analysis

Discussion Highlights: - Thomas requested descriptions for each objective for easier reading - Thomas questioned why simulation setup/platform development not starting earlier (Goa) - Core issue should be coordinated with other study items - Should begin sooner than April - Emmanouil clarified: - Test platform TR and theoretical study of framework start in Goa - Actual implementations begin after Goa, aiming for tangible results by April - Coordination with RTC group expected for relevant objectives - Gaëlle asked for clarification on phases of objective 4 - Emmanouil explained: - Phase 1: Framework setup for segmented media - Phase 2: Define relevant network scenarios - Phase 3: Run experiments and evaluations - Split due to joint framework with RTC for different applications

Decision: Agreed as baseline (comments to be incorporated for SA4#135 submission)

Administrative Matters

Liaison Statement Response

Special powers granted to MBS SWG to send reply LS to S4-251660 were not exercised.

Document System

• Several documents not covered due to time constraints
• Papers not presented need resubmission for Goa meeting with new TDoc numbers
• Discussion on extending document submission system deadline

Timeline Concerns

Valerie (InterDigital) raised concerns about timeline for energy feasibility study: - Importance of structuring candidate solutions - Ensuring all proponents have fair chance for adoption in TR - Suggested further discussion with Julien offline

Future Sessions

Julien suggested organizing offline meeting approximately one week before next scheduled meeting to process and discuss contributions, given large number of documents.

Meeting Statistics

Session 1 (Dec 18, 2025): - Duration: 2h 21m 45s - Participants: 28 - Average attendance: 1h 49m 9s

Session 2 (Jan 29, 2026): - Duration: 2h 53m 54s - Participants: 29 - Average attendance: 1h 40m 14s

Summary of Decisions

Agreed:

• S4aI260006 (MBSF notification corrections)
• S4aI250198 (Energy-related information principles)
• S4aI260009 (EIF summary update)
• S4aI260010 (Candidate solution documentation principles)
• S4aI260024 (QUIC study work plan)

Endorsed:

• S4aI250208 (Solution KI5 - revision of S4aI250199)
• S4aI250202 (Key issue description update)
• S4aI260012 (Media application service model)

Noted (requiring further work):

• S4aI250210 (Solution KI6 - revision of S4aI250200)
• S4aI250203 (Greening of Streaming collaboration)
• S4aI250209 (Solution KI5 - revision of S4aI250206)
• S4aI260028 (Solution 5 update - revision of S4aI260016)
• S4aI260020 (CMMF for multi-access)
• Multiple energy phase 2 solutions (to be resubmitted)

Noted without presentation:

• S4aI250204, S4aI250207 (InterDigital energy solutions)
• S4aI250201, S4aI250205 (AMD Phase 2 contributions)
• S4aI260007, S4aI260013-S4aI260015, S4aI260017-S4aI260019, S4aI260021-S4aI260023 (Various energy solutions)

Report from Audio SWG Teleconference on DaCAS (9 December 2025)

Meeting Overview

The Audio SWG held a teleconference on DaCAS (Diverse audio CApturing system for Smartphone devices) with 19 participants for 1 hour. Three input documents were discussed, all focused on defining the evaluation approach, specification methodology, and deliverables for DaCAS example solutions.

Main Technical Contributions

S4aA250140: Evaluation Approach for DaCAS Example Solutions (Nokia, Fraunhofer IIS)

Key Proposals: - Self-evaluation approach for example solutions rather than cross-evaluation - High-level documentation guidelines for proponents - Informal assessment against requirements in TS 26.261 - Updated work plan with two timeline options depending on evaluation procedure chosen

Timeline Proposals: - Table 1: Faster timeline with self-evaluation only - Table 2: Extended timeline including cross-evaluation - Key milestones: submission of example solutions in Montreal, specification work following

Discussion Points: - Mixed support: some agreement on self-evaluation concept, but reservations about completely skipping cross-evaluation - Questions on deliverable package definition (executable vs source code) - Concerns about timeline dependencies on deliverable agreements - Clarification needed on what "informal evaluation" means in practice - Need to distinguish between demonstrating feasibility vs determining suitability of solutions

Outcome: Document noted; offline discussions encouraged to provide potential revision

S4aA250141: Specification of Suitable DaCAS Example Solutions (Nokia)

Key Proposals: - Two-tier approach for example solutions: - All evaluations and documentation included in informative Annex of TS 26.533 - Example solutions additionally meeting requirements from TS 26.261 specified in TS 26.533 (status TBD)

Documentation Requirements: - Algorithmic description with sufficient detail for implementation - Optional elements: - Adaptation considerations for commercial devices - Support for IVAS PI (Parametric Information) data - Integration with commercial processing pipelines - Device limitations and generalization capabilities

Discussion Points: - Questions on required detail level: pseudocode vs source code - Clarification that last three bullets are optional/invitational - Relationship to ATIAS Phase 3 work - Distinction between two categories: 1. Feasible example solutions (demonstration via self-evaluation) 2. Endorsed solutions meeting TS 26.261 requirements (requiring testing) - Suggestion to share draft updates via SA4 reflector for broader input

Outcome: Document noted; revision expected with broader consultation

S4aA250142: Example Solution Deliverables (Bytedance, Xiaomi)

Key Proposals for Deliverable Package:

For Neural Network-based Solutions: - Code package including: - Training code - Inference code - Model checkpoints - Rationale: enable retraining for different devices beyond target device

For DSP-based Solutions: - Algorithmic description allowing reimplementation

General Requirements: - Legal framework submission (depending on solution specifics) - Sufficient details to convert raw microphone recordings to IVAS formats

Discussion Points: - Strong concerns about mandating training code and checkpoints: - Risk of providing false impression of quality transferability - Training typically tailored to specific devices - Cannot guarantee similar quality on different devices - May be unnecessary if solution generalizes without retraining - Distinction between providing model (equivalent to DSP description) vs full training pipeline - Legal framework requirements too general and need clarification - Fundamental difference in reproducibility between DSP descriptions (anyone can reimplement) and NN solutions

Outcome: Document noted; significant concerns raised about mandatory training code requirements

Cross-Cutting Issues and Open Questions

Evaluation Methodology

• Self-evaluation vs cross-evaluation trade-off: timeline efficiency vs validation robustness
• Need to define "informal assessment" against TS 26.261 requirements
• Distinction between feasibility demonstration and suitability determination

Deliverables Definition

• Critical dependency: timeline cannot be finalized without agreed deliverable package
• Balance between sufficient detail for reproducibility and practical constraints
• Different requirements for NN-based vs DSP-based solutions

Specification Approach

• Two-tier system emerging: informative documentation for all vs normative specification for qualified solutions
• No selection procedure planned, but potential endorsement mechanism discussed
• Relationship to requirements verification unclear

Timeline Dependencies

• Agreement on deliverables needed at SA4#135 (India, February 2026) to maintain schedule
• Submission of example solutions potentially at SA4#136 (Montreal)
• Specification work to follow based on submitted packages and evaluation reports

Next Steps

• Offline discussions encouraged on evaluation approach (S4aA250140)
• Revision expected for specification approach with broader consultation via reflector (S4aA250141)
• Further clarification needed on deliverable requirements, particularly for NN-based solutions (S4aA250142)
• Next DaCAS telco scheduled for January 13, 2026, 15:00-16:00 CET
• Repository discussion for material exchange (forge) to be continued offline

Report from Audio SWG Teleconference on DaCAS (13 January 2026)

Meeting Overview

The Audio SWG teleconference on DaCAS (Diverse audio CApturing system for Smartphone devices) was held on 13 January 2026 with 20 participants for 1 hour. The meeting processed two input documents and produced two agreed output documents with revisions to be implemented in DaCAS-2 and DaCAS-3.

DaCAS Example Solution Evaluation Procedures (S4aA260001 → S4aA260008)

Contributors: Nokia, Fraunhofer IIS, Dolby Laboratories

Main Technical Contributions

This contribution established the framework for evaluating DaCAS example solutions through a combined approach:

Evaluation Methodology

• Combined evaluation approach comprising both self-evaluation and cross-evaluation
• Cross-evaluation as optional task depending on available effort from cross-evaluation laboratories
• Three-tiered cross-evaluation approach (hierarchical structure):
• Minimum requirement: Cross-evaluation based on output signals provided by solution proponents
• Cross-evaluation using input signals and upmix methods
• Running executables to generate outputs for evaluation

Key Discussion Points and Resolutions

Cross-Evaluation Flexibility: - Cross-evaluation labs have freedom to conduct evaluation based on already provided signals or process evaluation signals with submitted solutions - The approach depends on available effort and resources at the cross-evaluation laboratory

Dataset Requirements: - Mandatory minimum evaluation dataset to be defined - Cross-evaluation limited to datasets that solution proponents have provided - Proponents must process recordings from the evaluation database - Cross-evaluation labs may use mandatory dataset and potentially additional signals

Clarifications Added: - Editor's note added to Clause 2.1 regarding cross-evaluation procedures - Clarification that recordings shared in the database should be used for processing with example solutions - Any company (proponent) can conduct cross-evaluation if desired

Agreement Status

The revised document (S4aA260008) was agreed with changes in brackets to be implemented in DaCAS-2.

DaCAS Example Solution Deliverables (S4aA260002 → S4aA260009)

Contributors: Bytedance, Beijing Xiaomi Mobile Software

Main Technical Contributions

This contribution defined the package and deliverables required for DaCAS example solutions.

Deliverable Components

1. Target Device Information: - List of supported target devices (revised from "target device to provide") - Device specifications and characteristics

2. Dataset Description: - Clarification that this refers to recordings used to develop example solutions - Discussion on whether to include external data used for development - Distinction between: - Common database for algorithmic development (transparent, shared data) - External data (e.g., for neural network training) - Geometric/analytical data (part of algorithmic description)

3. Algorithmic Description: - High-level description of solution development approach - Differentiation between signal processing and neural network solutions - For signal processing: description of methods (e.g., FEM method, upmix matrices) - For neural networks: indication of training data usage

Key Discussion Points and Resolutions

External Data Usage: - Proponents allowed to use external data (e.g., for neural network development) - Current common database amount may be insufficient for neural network training - No prohibition on external data, but transparency required - Common database serves as baseline, not as closed/exclusive dataset

Unified Deliverables: - Suggestion to combine deliverables for signal processing and neural network solutions - Recognition that solutions may combine both approaches - Need for unified set of deliverables across solution types

Documentation Requirements: - Code package contents to be specified - Similar to table format used for dataset descriptions - High-level description of how solution was developed - Reference to potential datasets used

Outstanding Items: - Bullet 2 (dataset description) placed in brackets for further discussion - Need to combine and unify deliverable descriptions - Editor notes inserted for future clarification

Agreement Status

The revised document (S4aA260009) was agreed with changes in brackets to be implemented in DaCAS-3.

Administrative Matters

IPR and Compliance

Standard 3GPP reminders provided regarding: - IPR disclosure obligations - Antitrust and competition law compliance - Consensus-based decision making

Next Steps

• DaCAS meeting scheduled at SA4#135
• Submission deadline: February 3, 2026
• DaCAS-2 Editor to implement S4aA260008 revisions
• DaCAS-3 Editor to implement S4aA260009 revisions

Participation

20 participants from organizations including: Bytedance, Dolby, Ericsson, Fraunhofer IIS, Nokia, NTT, Orange, Panasonic, Qualcomm, Philips, and Xiaomi.