Independent Submission J. Tansey Internet-Draft Independent Intended status: Informational J. Tansey Expires: 16 April 2026 Cisco 13 October 2025 Carrying ALVC over LPWAN using SCHC Fragmentation and Priorities draft-joetansey-alvc-schc-lpwan-01 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Tansey & Tansey Expires 16 April 2026 [Page 1] Internet-Draft ALVC over SCHC for LPWAN October 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Receiver Behavior (Summary) . . . . . . . . . . . . . . . . . 3 6. SCHC Mapping for ALVC . . . . . . . . . . . . . . . . . . . . 3 6.1. Contexts and RuleIDs . . . . . . . . . . . . . . . . . . 3 6.2. Fragmentation Parameters . . . . . . . . . . . . . . . . 4 6.3. Reliability and UEP . . . . . . . . . . . . . . . . . . . 4 6.4. Sender Scheduling . . . . . . . . . . . . . . . . . . . . 4 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. Changes since -00 . . . . . . . . . . . . . . . . . . . . . . 5 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 11.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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 [RFC8724]. The ALVC container is described in a companion draft [ALVC-Container]. Tansey & Tansey Expires 16 April 2026 [Page 2] Internet-Draft ALVC over SCHC for LPWAN October 2025 2. Requirements Language 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 ([RFC2119], [RFC8174]) when, and only when, they appear in all capitals, as shown here. 3. Scope 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. 4. Terminology 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. 5. Receiver Behavior (Summary) 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. 6. SCHC Mapping for ALVC 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. 6.1. Contexts and RuleIDs At minimum two RuleIDs are required: Tansey & Tansey Expires 16 April 2026 [Page 3] Internet-Draft ALVC over SCHC for LPWAN October 2025 * 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. 6.2. Fragmentation Parameters 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. 6.3. Reliability and UEP 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. 6.4. Sender Scheduling Senders SHOULD use a sliding-window scheduler: repeat: 1) transmit upcoming Base windows to sustain continuous playback 2) transmit the earliest-missing Enhancement window(s) (oldest-first) 3) advance window; respect dwell/duty and hop between channels 7. Examples *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. Tansey & Tansey Expires 16 April 2026 [Page 4] Internet-Draft ALVC over SCHC for LPWAN October 2025 *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. 8. Security Considerations 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. 9. IANA Considerations 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. 10. Changes since -00 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. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017, . [RFC8724] Toutain, A., Pelov, L., and R. Townsend, "SCHC: Static Context Header Compression and Fragmentation for LPWAN", 2020, . 11.2. Informative References Tansey & Tansey Expires 16 April 2026 [Page 5] Internet-Draft ALVC over SCHC for LPWAN October 2025 [ALVC-Container] Tansey, J., "Adaptive Layered Voice Container (ALVC) for Constrained Networks", 2025, . Authors' Addresses Joe Tansey Independent Email: joe.tansey@gmail.com Joe Tansey Cisco Email: joetanse@cisco.com Tansey & Tansey Expires 16 April 2026 [Page 6]