Independent

joe.tansey@gmail.com

Cisco

joetanse@cisco.com

General Independent Submission This document specifies how to carry the Adaptive Layered Voice Container (ALVC) over Low-Power Wide-Area Networks (LPWAN) using Static Context Header Compression (SCHC). ALVC is codec-agnostic and progressive: a sub-kilobit Base stream provides immediate intelligibility while optional Enhancement streams improve quality when bandwidth allows. This document defines SCHC rules, fragmentation parameters, and unequal error protection (UEP) so that Base traffic is delivered promptly and reliably, while Enhancements are sent opportunistically. The specification targets constrained networks with small payloads, duty-cycle limits, and loss, and does not define a new speech coding bitstream. A companion Internet-Draft describes the codec-agnostic ALVC container, and SCHC is specified in RFC 8724.

LPWAN links have small maximum payloads, non-negligible loss, and duty or dwell-time limits that make continuous voice streaming impractical. ALVC addresses this by splitting audio into a small Base layer (intelligible at sub-kilobit rates) and optional Enhancement layers that improve quality later without blocking Base playback. This document defines a SCHC mapping for ALVC so that Base traffic receives stronger protection and more timely delivery than Enhancements. SCHC is specified in . The ALVC container is described in a companion draft .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (, ) when, and only when, they appear in all capitals, as shown here.

This document specifies SCHC Rules, fragmentation sizing, and sender scheduling for ALVC traffic classes. It is codec-agnostic and does not define a new speech bitstream. Example Base profiles include Codec2; example Enhancement profiles include LPCNet or Opus, but the mapping applies generically.

ALVC-Frame: an application-layer unit covering a time window (e.g., 20 ms) with fields: timestamp (ts), layer_id (0=Base, >0=Enh), codec_id, frag_seq/frag_total, flags, and payload. Base: ALVC frames with layer_id=0; MUST be playable alone. Enhancement (Enh): ALVC frames with layer_id>0; MAY be ignored. UEP: unequal error protection favoring Base over Enh.

Receivers MUST render Base frames without blocking on Enhancements. When a complete Enhancement span for a time window arrives, the receiver MUST render that span using the highest available layer (splice/replace). Missing or invalid Enhancements MUST NOT interrupt Base playback. Implementations SHOULD expose application progress events indicating the best layer available per time window.

Separate SCHC Rules SHALL be provisioned for Base and Enhancement traffic so that they can be scheduled and protected differently. A single Flow Identifier (e.g., CoAP/UDP tuple) may carry both classes if contexts are distinguished by RuleID.

At minimum two RuleIDs are required: RuleID-Base: for ALVC frames with layer_id=0. RuleID-Enh: for ALVC frames with layer_id>0. Implementations MAY further subdivide Enh into multiple RuleIDs by layer priority.

Fragment sizing SHOULD follow regional constraints to respect dwell or duty-limits and maximize goodput. The following recommendations are provided: US915 DR3/DR4 (LoRaWAN-like 125/500 kHz): application payload of approximately 200-222 bytes per SCHC fragment is RECOMMENDED. Multiple ALVC frames may be aggregated per fragment. Raw LoRa SF10 / 125 kHz: to maintain per-channel time-on-air less than or equal to 0.4 s, application payload SHOULD be less than or equal to approximately 29 bytes. Typically this carries one Base frame per fragment; channel hopping MUST be used between fragments.

Base fragments SHALL receive stronger protection than Enhancements: Base: systematic transmission plus 10-20% parity (e.g., small block FEC) and limited ARQ/retry under policy. Enh: best-effort delivery; parity OPTIONAL; no blocking semantics. Loss of Enh MUST NOT stall Base.

Senders SHOULD use a sliding-window scheduler:

Example A (US915 DR3/DR4): An 8 s clip with Base (approximately 0.5-0.6 kb/s) may fit in about 3-4 SCHC fragments of 200-222 bytes, while an Enhancement at about 1.6 kb/s may require about 8 additional fragments. Base is sent first, Enh later as capacity allows. Example B (SF10/125 kHz): The same 8 s Base requires about 16 fragments of <= 29 bytes (one Base frame each), respecting <= 0.4 s per-channel dwell and hopping each packet. Enhancements are deferred or omitted.

ALVC frames SHOULD be protected end-to-end using an AEAD scheme (for example, ChaCha20-Poly1305 or AES-CCM) prior to SCHC fragmentation. Integrity failures in Enhancement fragments MUST NOT impact Base playback; such fragments are discarded. Metadata should be minimized to avoid exposing speaker identity or detailed timing beyond what is required for rendering.

This document does not create new IANA registries. If a common set of ALVC RuleIDs or CoAP/SCHC identifiers is later standardized, those will be registered in a future document.

Clarified scope as codec-agnostic transport mapping for ALVC; added explicit Base/Enh RuleIDs, fragmentation sizing guidance per data rate, unequal error protection, and sender scheduling. Added security and examples.