Summary of S4-260197: NNC Web Decoder Demo

1. Introduction

This contribution presents a live demonstration of a web-based Neural Network Codec (NNC) decoder, following up on previous telco discussions where decoding times and end-to-end latency were reported. The demonstration shows substantial latency reductions under realistic download conditions. The document also addresses security concerns regarding WebAssembly (Wasm) that were raised in the previous telco.

2. Decoder Implementation

Technical Architecture

• Base Implementation: Built on NNCodec and MPEG's reference software NCTM
• Language: Reuses existing C++ entropy coding (CABAC) components with additional functionality ported from Python to C++
• Web Deployment: Compiled into WebAssembly (Wasm) library using Emscripten

Supported Features

• Supports NNC edition 2
• Limitation: Does not support tools using temporal prediction

Performance Optimizations

• Parallelization: CABAC decoding parallelized across NNR data units
• Scheduling Strategy: Prioritizes largest available NNR data unit first to reduce tail latency when multiple units are pending

3. Web Application

Integration

• Wasm decoder library embedded into JavaScript web application
• Executable in standard browsers
• JavaScript application invokes Wasm decoder and provides user interface for timing measurements

User Interface Features

• Configuration Options:
• Simulated download rate selection
• Number of decoding threads selection
• Execution Modes:
• Decoding after complete model download
• Simultaneous download and decoding (progressive decoding of fully received NNR data units)

Measurement Capabilities

• Download Simulation: Delays availability of each tensor/NNR data unit according to selected throughput
• Metrics Captured:
• Decoding time
• Total end-to-end latency (from download start to complete model decoding)

4. Test Conditions

Model and Configuration

• Model: Wav2Vec for automatic speech recognition (evaluated in 3GPP TR 26.847)
• Encoder Settings:
• Dependent scalar quantization (use_dq)
• Parameter optimization for DeepCABAC (param_opt)
• Unary binarization length 11 (cabac_unary_length_minus1)
• QP −27
• No data-driven tools

Compression Performance

• Original Model: ~377 MB (94.4M float32 parameters)
• Compressed Size: ~49 MB
• Compression Ratio: ~13%

ASR Performance (LibriSpeech test-clean)

• Original WER: 3.4%
• Compressed WER: 3.6%

Test Environment

• Browser: Brave 1.86.142 (64-bit), Chromium 144.0.7559.97
• Hardware: Dell Precision 7680 Laptop, Intel Core i9-13950HX, 64 GB RAM
• OS: Windows 10 Enterprise

5. WebAssembly Security Analysis

The contribution addresses security concerns raised in the previous telco with four key arguments:

5.1 Expert Development and Maintenance

• Developed within W3C by WebAssembly Working Group
• Participation from major browser vendors and technology companies (Mozilla, Microsoft, Google, Apple, Intel, ByteDance, Red Hat)
• Browser support since 2017
• Actively maintained (latest core draft: 16 June 2025)

5.2 Security Model and Mechanisms

• Operates under web security model in browsers
• Key Security Features:
• Sandboxed execution
• No implicit privileges
• Module validation before execution
• Memory isolation
• Enforcement of standard browser security policies

5.3 Broad Industry Deployment

Examples of widely deployed Wasm applications:
- Adobe Photoshop on the web
- Google Earth on the web
- TensorFlow.js (WebAssembly backend)
- ONNX Runtime Web (Microsoft)
- AutoCAD Web
- ffmpeg.wasm project

This broad deployment indicates strong industry confidence in WebAssembly's security model.

5.4 3GPP-Specific Considerations

• IMS DC applications have different threat model than open web
• Applications come from trusted sources
• Authentication and authorization required before execution on UE
• Applications authorized by DCSF/DC-AR before download/execution
• Precedent: SA4 already considers WebAssembly in TR 26.858 (Study on APIs for 3GPP Speech and Audio Codecs) in clauses 5.3.3 and 6

6. Conclusion

The contribution proposes scheduling a time slot for live demonstration (e.g., during a meeting break) and concludes that WebAssembly is secure for running NNC decoder in web environments based on:
1. Expert-driven standardization and ongoing maintenance
2. Sandboxed execution model and security mechanisms
3. Broad deployment across major browsers and applications
4. Security considerations specific to IMS DC applications