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