Report from Audio SWG AH on FS_ULBC (Jan 15 & 19, 2026)
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:
No proposals were agreed for inclusion in the TR at this stage. Several contributions require additional offline work and clarification.
Status: Agreed
This document reported on the offline meeting held December 10, 2025, covering:
Discussion: No comments raised.
Decision: Document agreed without modifications.
Status: Noted (not agreed)
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.
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
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.
Status: Noted (requires pCR before TR inclusion)
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)
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
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
Status: Noted (requires coordination with RAN groups)
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
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
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
Status: Noted (requires further discussion)
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.
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
S4aA260007 noted - Further discussion needed on wording and assumptions. Group to proceed with email discussion and potential offline work before reconsidering.
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.