Proposal: The source would like to propose to document clause 2 and clause 3 in clause 6.2 of the pdoc.

Proposal The source would like to propose to document clause 2 and clause 3 into TR 26.940 clause 7.6 as a new clause 7.6.5

Proposals

Proposal

We propose to document the consideration of optional objective test method for ultra-low bit rate codecs provided above in a pCR to TR 26.940 or PD file as shown below.

Extracted Proposals

This document does not contain any explicit proposals. The document presents simulation results and technical analysis for ULBC (Ultra-Low Bitrate Codec) in NTN (Non-Terrestrial Networks) scenarios, but does not include any sections explicitly marked as "Proposal", "Proposal:", "Proposal X:", etc.

The conclusion section states "It is recommended to consider the above simulation results for determining the design constraints for ULBC" but this is presented as a recommendation rather than a formal proposal.

Proposals from the Document

Proposal: The source proposes to add a new clause 4.5 eCall Communication in TR 26.940 for documenting the eCall scenario, and change the clause 6.2 Design Constraint Parameter in TR 26.940 to have separate design constraints for eCall and regular call as follows:

[Note: The proposal includes the detailed text changes shown in the "First Change" and "Second Change" sections of the document, which add clause 4.5 and modify Table 6.2-1 to include separate design constraints for regular call and eCall scenarios.]

Extracted Proposals

Proposal: It is proposed to agree the following changes to the TR 26.940.

Proposal

We propose to use both the MACS and Codec/Model Size to characterize ULBC complexity and set complexity, RAM and ROM respectively for ULBC as below:

Complexity: single Model Size < 3M parameters and < 600MMACS.

RAM: < 3M parameters.

ROM: < 15M parameters.

And it is proposed to agree the following changes to the TR 26.940.

Extracted Proposals

This document does not contain any explicit proposals marked with "Proposal X:", "Proposal X.", "Proposal:", "Proposal.", or "Proposal " formatting.

The document is a Technical Report (TR 26.940) that is still under development (Version 0.5.1) and contains study items, observations, editor's notes, and conclusions, but no formally marked proposals in the standard 3GPP proposal format.

Extracted Proposals

Based on my review of the document, there are no formal proposals explicitly marked with the word "Proposal" followed by a colon, period, number, or other punctuation in this 3GPP document.

The document is a Permanent Document (p-doc) for the FS_ULBC study item that contains: - Technical assumptions - Open issues - Editor's notes - Tables with simulation parameters - References to other documents

However, it does not contain any sections explicitly labeled as "Proposal", "Proposal:", "Proposal X:", etc. The document appears to be a working document that tracks the status of study objectives, technical parameters, and open issues rather than containing formal proposals for agreement.

Extracted Proposals

This document does not contain any explicit proposals. The document is a timeplan for the FS_ULBC (Feasibility Study on Ultra Low Bitrate Speech Codec) Study Item, outlining objectives, current progress, and meeting schedules, but does not include any sections explicitly marked as "Proposal", "Proposal X:", "Proposal X.", etc.

Proposal

It is proposed update the P-doc based on the content in Clause 2 of this document and to continue tracking the status of these issues.

Extracted Proposals

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

The document is a contribution to update the permanent document (PD) based on TR 23.700-19, and it contains: - Reasons for change - Proposed changes to the PD (editorial updates to align with agreements already reached) - Technical assumptions and open issues

However, there are no sections explicitly marked as "Proposal", "Proposal X:", "Proposal X.", etc. The document presents updates and changes to an existing document rather than new proposals for consideration.

Proposals

This document does not contain any proposals. The document appears to be a presentation about ULBC Codec Selection Process and JPEG AI, but no sections are explicitly marked as "Proposal" in any of the standard formats.

Proposals

It is proposed to include the relevant content from Sections 3, 4, and 5 of this document into TR 26.940. This includes the methodology, experimental setup, and the analysis of results concerning the impact of audio bandwidth on semantic intelligibility, to capture the findings of this study.

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

Proposal: It is proposed to include the findings of this RTF analysis in TR 26.940 to inform the selection of complexity constraint for the ULBC candidate.

Extracted Proposals

Based on my analysis of the document, here are the proposals found in the "Proposal" section (Section 5):

Proposal 1: The codec shall be able to operate with an 8 kHz sampling rate, supporting an audio bandwidth of 50 – 4000 Hz.

Proposal 2: The codec shall be able to operate with a 16 kHz sampling rate (50 – 8000 Hz audio bandwidth) to offer enhanced quality where channel conditions and device capabilities permit. For example, WB support can be limited to higher bitrates than NB operation.

Proposal 3: The necessity and feasibility of including Super-Wideband (SWB) and Full-band (FB) support remains for further study.

Proposal

It is proposed to capture the above analysis into 3GPP TR 26.940.

Extracted Proposals

Proposal 1: Agree that the codec bitrate should be bound to be less than 3kbps.

Proposal 2: Agree the following changes to 3GPP TR 26.940 [2].

Proposals

Proposal

The source proposes to document clause 2 and clause 3 in clause 6.2.1 of 3GPP TR 26.940 as shown in the pCR below.

Extracted Proposals

Proposal: Multi-point Fine-grained Trace Generation

The MFTG methodology aims to decouple physical layer simulation assumptions from application-layer codec design. By providing a high-resolution library of error traces rather than a single static operating point, it enables a fair and flexible evaluation of various codec strategies (e.g., different bitrate/BLER trade-offs) while bypassing the current standardization deadlock.

Step 1: Resource Baseline Normalization (TBS Definition)

• Define a set of Reference Transport Block Sizes (TBS) based on a unified packect overhead.
• These TBS values must be kept consistent across all candidate codec bitrates to ensure a fair comparison of resource efficiency.

Step 2: Link Budget Mapping and Granularity Setup

• Identify the target range of Link Budgets (SNR/CNR) based on realistic NTN deployment scenarios (e.g., LEO/GEO, UE power classes).
• Establish a fine-grained sampling interval (e.g., 1% BLER to 10% BLER in step of 1% or 2% from BLER perspective or -5dB to 10dB in step of 1dB from SNR perspective) along the SNR-BLER curve to ensure high resolution for subsequent selection.

Step 3: Large-scale Link-Level Simulation (LLS)

• Execute Monte Carlo simulations for each defined TBS at every fine-grained sampling interval.

Step 4: Flexible Trace Selection for Verification

• For Performance Comparison: Proponents selecting a specific source bitrate can identify and utilize the trace from the library whose SNR/BLER most closely matches their design's intended link budget.
• For Robustness Testing: Proponents can select "stress-test" traces (e.g., those with higher BLER or specific jitter profiles) from the same library to verify PLC and JBM algorithms.

This document does not contain any proposals in the standard 3GPP format. The document is a "living document" that attempts to capture and consolidate design constraints for FS_ULBC, but it does not include any sections explicitly marked as "Proposal", "Proposal X:", "Proposal X.", etc.

The document contains design constraints presented in a table format and various editor's notes, but these are not formatted as formal proposals.

Proposal

We propose to include the analysis presented in this contribution into 3GPP TR 26.940. Specifically, the text should capture the findings that Model Size is not a consistent proxy for complexity across varying architectures (e.g., high-stride vs. low-stride), and that GMACS/GFLOPs demonstrates a strong linear correlation with real-time performance on mobile devices. Documenting this analysis will provide a solid basis for defining the complexity constraints for the ULBC candidate.

Proposal: The proposed change includes the following:

Add TBS 936 and TBS 680 and an additional value between 680 and the current maximum TBS value (424) to the TBS table for the 80ms bundling period in the permanent document v.0.4.0.

Add new TBS values to the TBS tables for 160ms and 320 ms bundling periods accordingly.

Change the "codec bitrate" to "net bitrate" to indicate that the "net bitrate" is the bitrate available for the codec and does not require a codec to operate at the bitrate.

Extracted Proposals

Based on my review of the document, there are no proposals explicitly marked as "Proposal" (with any of the variations mentioned) in this 3GPP document.

The document contains proposed changes to a PD (Permanent Document) version 0.4.0, specifically modifications to section 5.2.2.3 on Frame structure, but these are presented as "Proposed change" rather than formatted as numbered or unnumbered proposals in the standard proposal format.

Proposal 1: Consider the 280ms as the max. transmission propagation delay and consequently 248ms (280ms – 32ms) as the minimal transmission propagation delay.

Proposal 2: The transmission delay for a transport block size should be based on the RAN simulation results.

Proposal 1: Make DTMF support part of the IMS voice service over NB-IoT NTN.

Proposal 2: Design DTMF support under the following assumptions

The DTMF packet size is at most as large as the voice packet size

Delay requirement of DTMF is not as stringent as voice service

DTMF takes priority over voice

Proposal 3: SA4 designs the mechanisms needed to support voice and DTMF multiplexing for SPS and works with RAN1 and RAN2.

Proposals

The source proposes to update Table 6.2-1 in draft TR 26.940 as follows:

[The proposal consists of updating Table 6.2-1 with the following design constraint parameters:]

Parameter: Potential use of noise suppression as part of the codec

Design Constraint: If noise suppression is supported as part of the candidate codec, it can be disabled to preserve background signals

Editor's note 1: Requirement to disable noise suppression may be considered in connection with specific operating bit rate(s)

Editor's note 2: Solution behaviour w.r.t. potential noise suppression is primarily enforced via performance requirements. The default operation for tests is with noise suppression disabled.

Parameter: Discontinuous transmission including voice activity detection and comfort noise

Design Constraint: The candidate codec shall provide a framework for voice activity detection (VAD) and discontinuous transmission (DTX) with comfort noise generation (CNG). It shall be possible to operate the codec with DTX on or DTX off.

Editor's note: Operation relating to DTX on and disabling/enabling potential noise suppressor may need to be clarified

Parameter: Robustness to non-speech input

Design Constraint: The candidate codec shall be robust to noisy speech (stationary noise 5-15 dB, non-stationary noise 10-25 dB), background signals during and between speech segments, and other non-speech input signals

Editor's note 1: May need to be in performance requirements

Editor's note 2: Relevant background signals, etc. to be further defined as part of performance requirements, these include both stationary and non-stationary background signal types

Proposal 1: For the support of voice-over-GEO in NB-IoT NTN, align the assumption on the "UE_Antenna_Gain (a.k.a. G_Tx)", corresponding to G in the FS_ULBC Pdoc, with the one of 5G NR-NTN (i.e., UE_Antenna_Gain (a.k.a. G_Tx): -5.5 dBi).

Proposals

The sources invite discussions regarding the selection of one or more model formats which can be used for a reference implementation in support of the standardization of ULBC. Furthermore, the principle using a model format as part of the ULBC standardization reference model should be agreed and documented

It is proposed to document the findings on reference model formats into TR 26.940 under a new clause 6.4.2.

Proposals

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

The document contains sections labeled "Proposal" (on page 1) and "Proposed revisions" (also on page 1), but these are section headers describing the general approach of the document rather than formal numbered or formatted proposals as typically found in 3GPP contributions.

The document primarily consists of: - An introduction - References - An Annex containing proposed changes to TR 26.940 (marked as "pCR to TR 26.940") - Technical content about test methodologies and objective metrics

While the Annex contains technical content that could be considered as proposed text for inclusion in TR 26.940, it is not formatted as explicit "Proposal X:" or "Proposal:" statements as specified in the extraction criteria.

Proposals

Proposal

The source proposes to define a computational complexity metric by counting

• WMOPS for the DSP‑based components,
• MAC for the ML‑based components, and
• combine those to a common value according to WMOPS + w · MACs, where w is a ML weighting factor

Finally, a maximum value needs to be defined as computational complexity limit in design constraints. Based on this principle, a similar metric can be defined for memory counting.

Proposals

Proposal: To facilitate the timely delivery of a practical ULBC solution for IMS Voice over GEO within the Rel‑20 timeline, initial standardization efforts should be confined to a baseline configuration that is strictly anchored in stable Rel‑19 service requirements and guaranteed Rel‑19 radio features (with SPS as the sole exception). It is also recommended to maintain a targeted approach regarding design constraints, performance requirements, and testing methodologies. Defining this focused scope is critical to ensure the successful completion of the anticipated Rel‑20 Work Item following the FS_ULBC Study Item, as prompt SI finalization is required before commencing any ensuing WI activities.

Concurrently, advanced features and expanded application scenarios dependent on evolving 6G Media requirements have been recognized. As these requirements are still under development and not yet established as normative, they are unsuitable for inclusion in the Rel‑20 baseline. These elements should instead be systematically addressed in a structured second phase during Rel‑21, subsequent to the stabilization of pertinent 6G requirements.

It is therefore proposed to standardize ULBC in two phases:

• Rel‑20 ULBC Baseline — GEO‑focused functionality based solely on Rel‑19 service requirements and mandatory Rel‑19 features (except SPS), enabling completion of a viable ULBC baseline standard within the Rel‑20 schedule.

• Rel‑21 ULBC Advanced — Extended ULBC functionality aligned with finalized 6G Media requirements and supporting application scenarios beyond Rel‑20 IMS Voice Call over GEO. Possibly also leveraging advanced UE capabilities.

This two‑phase approach ensures a deliverable ULBC baseline in Rel‑20 while providing a clear and orderly path toward an enhanced ULBC design in Rel‑21. To ensure full alignment of the ULBC systems designed in the two phases, Rel-21 ULBC Advanced should be a backward compatible extension of the Rel‑20 ULBC Baseline.

The source suggests that SA4 adopts this phased approach for ULBC standardization as working assumption.

Extracted Proposals

Proposal: include clauses 2 through 5 above to the PD or TR.

Proposal

It is proposed to update Clause 8 in TR 26.940 to reflect the changes below.

Based on my analysis of the document, there are no explicit proposals in the standard 3GPP proposal format.

The document contains a section titled "4. Proposal" which states "It is proposed to update Clause 9 in TR 26.940 to reflect the changes below." However, this is followed by proposed text changes to be inserted into the technical report, rather than standalone numbered or formatted proposals in the typical 3GPP style (e.g., "Proposal 1:", "Proposal:", etc.).

The document is structured as a discussion paper with a proposed update to TR 26.940, but does not contain explicitly formatted proposals as typically found in 3GPP contributions.

Extracted Proposals

Based on my analysis of the document, I could not find any explicitly marked proposals using the standard formats: - "Proposal X: " - "Proposal X. " - "Proposal: " - "Proposal. " - "Proposal "

The document contains technical discussions, a pCR (proposed Change Request) to TR 26.940, and recommendations in the Conclusion section, but none of these are explicitly labeled as "Proposal" in the standardized format typically used in 3GPP contributions.

The Conclusion section mentions suggestions and recommendations (e.g., "it is suggested to agree on a minimum set of 3 ULBC target bitrates" and "it is proposed to document the ULBC target bit rates in the Pdoc"), but these are not formatted as formal proposals with the "Proposal" keyword.

Proposals

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

The document contains sections labeled "Proposal" (on page 1) and "Conclusion" (in sections 9.1.3.4 and 9.1.4.3), but these are section headers rather than formal numbered or formatted proposals following the standard 3GPP proposal format (e.g., "Proposal 1:", "Proposal:", etc.).

The "Proposal" section on page 1 contains descriptive text about objective quality models and proposed revisions to TR 26.940, but does not contain any formally stated proposals. The "Conclusion" sections contain observations and recommendations but are not formatted as formal proposals.