# Candidate Convenor for 3GPP Systems Aspects TSG - ULBC Design Constraints Living Document ## 1. Scope This living document consolidates design constraints being considered within SA4 for FS_ULBC (Feasibility Study on Ultra-Low Bitrate Codec). Due to the working procedure requiring consensus agreements for design constraints to be integrated into ULBC PD or TR 26.940, and the lack of such consensus so far, this document captures the current status of design constraints even though some items are not fully agreed. ## 2. ULBC Design Constraints ### 2.1 Sampling Frequency and Audio Bandwidth **Design Constraint:** Support of [8, 16, 32] kHz / [NB, WB, SWB] required [1], [2] **Editor's Notes and Open Issues:** - Support of 8 kHz justified for interoperability; clarification needed on whether NB would be tested/supported "externally" based on external resampling - Support of 48 kHz may be considered at higher bitrate operation - Consideration of at least a single model (e.g., SWB) - Many neural codecs operate at 24 kHz; this specific sampling rate should be discussed - Complexity considerations associated with this parameter; joint decisions may be needed **Reference:** NB audio typically sampled at 8 kHz (100-3500 Hz), WB at 16 kHz (50-7000 Hz), SWB at 32 kHz (50-14000 Hz), FB up to 20000 Hz ### 2.2 Number of Audio Channels **Design Constraint:** ULBC candidate codecs shall support mono coding with one channel input and one channel output ### 2.3 Bit Rates **Design Constraint:** ULBC candidate codecs shall operate at bitrates lower than [3.00] kb/s [3] ### 2.4 Frame Length **Design Constraint:** Candidate codecs shall operate with a coding frame size of multiple of 20 ms **Note:** Since larger than 20ms bundling time periods will be used, codec proponents should be allowed to consider solutions with larger than 20ms frame sizes ### 2.5 Algorithmic Delay **Design Constraint:** Algorithmic delay shall be less than [coding frame size + x] ms ### 2.6 Complexity **Design Constraint:** Complexity limits applied according to categories. Computational complexity and program ROM (PROM) of candidate codecs for each category shall be measured with ITU-T STL2009 [1] as observed worst-case encoder + observed worst-case decoder complexity within the same category [5], [6] **Categories:** - **Computational:** wMOPS: Less than [x] wMOPS - **Memory:** RAM, ROM, Program ROM (values TBD) **Editor's Notes:** - Model size per operation mode is less than [5-10] million parameters - Total number of parameters is less than [Z] million - ULBC Codec should be implementable on mobile device using today's technology - Increased computational complexity and memory usage should be commensurate with gain in quality of user experience (e.g., higher audio bandwidth such as SWB or stereo) or increased efficiency (e.g., lower bit rate for same quality compared to reference codec) ### 2.7 Potential Use of Noise Suppression as Part of the Codec **Design Constraint:** If noise suppression is supported inside ULBC, there should be a mechanism to disable noise suppression in the codec [7], [8] **Editor's Notes - Clarifications Needed:** - Need to support noise suppression in ULBC? (typically vendor specific, defined outside the codec) - Impacts on test methodology, DTX operation/performance **Motivations:** - Disabling noise suppression required to test feature separately - Avoid tandeming in real operation - IMS voice communication defined in TS 22.228; GEO satellite access has no specific requirement on noise handling ### 2.8 Jitter Buffer Management (JBM) **Design Constraint:** A JBM solution conforming to requirements in TS 26.114, except for the functional requirement in sub-clause 8.2.2 of TS 26.114: "Speech JBM used in MTSI shall support all the codecs as defined in clause 5.2.1", shall be provided with candidate codecs ### 2.9 Rate Switching **Design Constraint:** Candidate codecs shall perform rate switching upon command to the encoder throughout the entire bit rate range at arbitrary frame boundaries. Rate switching may imply switching between different bandwidths **Note:** Due to the Bundling period and associated TBS, switching might have to happen at the boundary of bundling period ### 2.10 Packet Loss Concealment (PLC) **Design Constraint:** A PLC solution shall be provided by ULBC candidate codecs [9] **Editor's Notes:** - Typical loss profiles/characteristics to be clarified - Support of redundancy to be clarified - Need to be able to handle BLER up to [x%] ### 2.11 RTP Payload Format **Design Constraint:** Candidate codecs shall provide an RTP payload format specification supporting the full set of features and functionality of the ULBC candidate codecs ### 2.12 DTX **Design Constraint:** Candidate codecs shall provide a complete VAD/DTX/CNG framework. It shall be possible to operate the codec with DTX on or DTX off **Editor's Note:** Typical radio characteristics and optimizations (SPS, DRX, bitrate) to be clarified ### 2.13 Output Gain Limitation **Design Constraint:** ULBC candidate codecs shall not amplify the output signal relative to the input signal beyond limits **Editor's Note:** Similar limits and methodology to measure the amplification are described in the EVS-7a,b processing plan permanent document ## 3. References [1] S4-251794 - Discussion on Audio Bandwidth for ULBC (vivo, Samsung, MediaTek Inc., Bytedance, Nokia, Xiaomi, Spreadtrum) [2] S4-251808 - Pseudo-CR on Design Constraints of ULBC: Audio bandwidth (Fraunhofer IIS) [3] S4-251792 - On codec bitrate and capacity discussion for ULBC (vivo, Samsung, Spreadtrum, MediaTek Inc.) [4] ITU-T G.191 - Software tools for speech and audio coding standardization (March 2010) [5] S4-251747 - On complexity constraints for ULBC (Huawei Technologies Co., Ltd.) [6] S4-251807 - On complexity design constraints for ULBC (Fraunhofer IIS) [7] S4-251395 - Pseudo-CR on Design Constraints of ULBC: Noise suppression (Fraunhofer IIS) [8] S4-251748 - On noise suppression for ULBC (Huawei Technologies Co., Ltd.) [9] S4aA250268 - Packet Loss Concealment with existing AI based codec DAC (Dolby Laboratories Inc., Ericsson LM, Nokia, Novamint) --- **Note:** Items in light blue are candidates for agreement at SA4#135.