



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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8724]  Toutain, A., Pelov, L., and R. Townsend, "SCHC: Static
              Context Header Compression and Fragmentation for LPWAN",
              2020, <https://www.rfc-editor.org/rfc/rfc8724>.

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,
              <https://datatracker.ietf.org/doc/draft-joetansey-alvc-
              codec/>.

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]
