Carrying ALVC over LPWAN using SCHC Fragmentation and Priorities

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.¶

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

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].¶

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.¶

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.¶

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.¶

Authors' Addresses