IPv6 over LoRaWAN mit SCHC: Header-Kompression, Fragmentierung und Einsatzgrenzen
Ein normaler IPv6-Header umfasst 40 Byte, noch bevor UDP, CoAP oder die eigentlichen Messdaten hinzukommen. Für LoRaWAN ist das beträchtlich: Die verfügbare Nutzlast hängt von Region und Datenrate ab, Downlinks sind knapp und lange Frames verbrauchen viel Airtime. Trotzdem kann IPv6 über LoRaWAN sinnvoll sein, wenn bestehende IP-basierte Anwendungen, Zählerprotokolle oder Gerätemanagementsysteme angebunden werden sollen.
Die dafür standardisierte Adaptionsschicht heißt SCHC, gesprochen etwa wie ‚chic‘. Static Context Header Compression and fragmentation nutzt die hohe Vorhersagbarkeit vieler IoT-Pakete. Statt wiederkehrende IPv6- und UDP-Felder jedes Mal vollständig zu senden, kennen Gerät und Gegenstelle dieselben Regeln. Übertragen werden eine RuleID und nur die Felder, die sich tatsächlich ändern.
Kurz zusammengefasst: IPv6 over LoRaWAN setzt SCHC zwischen IP und LoRaWAN. Ein statischer Regelkontext komprimiert vorhersehbare Header; eine separate SCHC-Funktion kann zu große Datagramme fragmentieren. Das schafft standardisierte IP-Integration, verwandelt LoRaWAN aber weder in Ethernet noch in einen frei erreichbaren Breitbandanschluss. Context, FPorts, Gerätezustand, Downlinkkapazität und Sicherheit müssen Ende zu Ende geplant werden.
Drei Dokumente definieren die Architektur
Die LoRa Alliance beschreibt in TS010-1.0.0 IPv6 Adaptation Layer den effizienten Transport von IPv6-Paketen über LoRaWAN. Das Dokument verweist auf zwei IETF-Spezifikationen: RFC 8724 definiert das allgemeine SCHC-Framework für LPWANs, und RFC 9011 legt das konkrete SCHC-Profil über LoRaWAN fest.
Diese Ebenen sollten nicht vermischt werden. RFC 8724 enthält allgemeine Kompressions- und Fragmentierungsmechanismen, die auch andere LPWAN-Techniken profilieren können. RFC 9011 wählt Parameter, FPorts und Zuordnungen für LoRaWAN. TS010 ordnet dieses Profil in das LoRaWAN-Ökosystem ein. Eine Implementierung mit nur einem beliebigen ‚SCHC‘-Baustein ist daher noch nicht automatisch interoperabel.
Wo SCHC im Protokollstapel sitzt
| Ebene | Beispiel | Aufgabe |
|---|---|---|
| Anwendung | CoAP, DLMS/COSEM oder proprietärer IP-Dienst | fachliche Nachrichten und Gerätemanagement |
| Transport und Netz | UDP und IPv6 | Ports, Adressierung und IP-Weiterleitung |
| SCHC Compression | RuleID plus Residue | vorhersagbare Headerfelder verkürzen |
| SCHC Fragmentation | Tiles, Fenster und ACK-Verfahren | große SCHC-Pakete an LoRaWAN-Nutzlast anpassen |
| LoRaWAN | FPort, FRMPayload und MAC-Schutz | Funktransport zwischen Gerät und Application Server |
Auf der Geräteseite liegen Kompressor, Dekompressor und gegebenenfalls Fragmentierer im Endgerät. Auf der Netzseite übernimmt eine SCHC-Gegenstelle diese Funktionen. RFC 9011 nennt sie SCHC Gateway; sie kann beim Application Server oder in einer erreichbaren Zwischenkomponente liegen. Der gewöhnliche LoRaWAN-Funkgateway bleibt eine andere Rolle und muss nicht selbst IPv6-Header rekonstruieren.
Der Network Server transportiert die geschützten LoRaWAN-Frames und ordnet sie dem Endgerät zu. Erst auf der Anwendungsseite wird daraus wieder ein IP-Paket. Die Grundlagen des LoRaWAN MAC Layers zeigen, welche Funkheader unabhängig vom komprimierten IPv6-Inhalt bestehen bleiben.
Static Context ersetzt wiederkehrende Headerwerte
Viele IoT-Verbindungen sind stark vorhersehbar: Das Gerät spricht meist mit wenigen Servern, IPv6-Präfixe ändern sich selten, UDP-Ports sind fest und Protokollfelder folgen bekannten Mustern. SCHC speichert solche Annahmen als Rules an beiden Enden. Eine Rule beschreibt Felder, Zielwerte, Matching Operators und Compression/Decompression Actions.
Passt ein Paket zu einer Rule, sendet das Gerät die zugehörige RuleID und ein Compression Residue für nicht vorhersagbare Bits. Konstanten können vollständig entfallen, andere Werte werden verkürzt oder berechnet. Die Gegenstelle setzt aus Rule und Residue den ursprünglichen Header wieder zusammen. Der Gewinn entsteht also aus gemeinsamem Vorwissen, nicht aus einer allgemeinen verlustfreien Dateikompression.
Ein SCHC-Context muss festlegen
- welche IPv6-, UDP- und gegebenenfalls Anwendungskopffelder abgedeckt sind
- welche RuleID eine Regel eindeutig bezeichnet
- welche Werte konstant, abgeleitet, gemappt oder als Residue gesendet werden
- für welche Richtung und welches Gerät die Regel gilt
- wie Version, Bereitstellung, Austausch und Rückfall des Contexts erfolgen
RuleID und FPort sind im LoRaWAN-Profil eng verbunden
RFC 9011 verwendet eine 8 Bit breite RuleID und kodiert sie im LoRaWAN FPort. Dadurch bleibt mehr Platz im FRMPayload, aber die Portvergabe wird Teil der SCHC-Konfiguration. Empfohlen sind unter anderem RuleID beziehungsweise FPort 20 für Uplink-Fragmentierung, 21 für Downlink-Fragmentierung und 22 für Fälle ohne passende Kompressionsregel. Andere SCHC-Regeln benötigen ebenfalls abgestimmte FPort-Werte.
Eine Anwendung darf weiterhin nicht-SCHC-Verkehr über andere Ports senden. Sie muss jedoch Kollisionen vermeiden: Derselbe FPort kann nicht gleichzeitig willkürlich einem proprietären Payload-Codec und einer SCHC-Rule zugeordnet sein. Geräteprofil, Application Server und SCHC Gateway benötigen dieselbe Port- und RuleID-Tabelle.
Kompression ist nur so gut wie die Vorhersagbarkeit
| Feldart | Mögliche SCHC-Behandlung | Übertragener Anteil |
|---|---|---|
| konstanter IPv6-Präfix | prüfen und nicht senden | kein Feldwert |
| bekannter UDP-Zielport | prüfen und nicht senden | kein Feldwert |
| Wert aus LoRaWAN-Identität ableitbar | berechnen | gegebenenfalls kein Feldwert |
| kleine Auswahl bekannter Werte | Mapping | kurzer Auswahlindex |
| variabler Sensor- oder Tokenwert | vollständig oder teilweise senden | Residue nach Regel |
| unbekanntes Paketformat | uncompressed Rule | nahezu vollständiger Header |
Wechselt eine Anwendung häufig Serveradressen, Ports oder Erweiterungsheader, sinkt die Kompressionswirkung und der Regelbestand wächst. Für einen festen Zählerdienst kann SCHC sehr kompakt sein; für beliebigen Internetverkehr ist es nicht gedacht. Die Architektur sollte deshalb zuerst die tatsächlich vorkommenden Flows inventarisieren und erst daraus Rules ableiten.
SCHC-Fragmentierung löst ein anderes Problem als Header-Kompression
Nach der Kompression kann ein IP-Datagramm weiterhin größer sein als der aktuelle LoRaWAN FRMPayload. Die optionale SCHC Fragmentation and Reassembly zerlegt das SCHC-Paket dann in Tiles und verteilt sie über mehrere Funkframes. Fenster, Fragment Counter, Bitmaps, Retransmissionen und ein Reassembly Check Sequence unterstützen die Wiederherstellung.
Das allgemeine SCHC-Framework in RFC 8724 bietet mehrere Zuverlässigkeitsmodi. Das LoRaWAN-Profil in RFC 9011 verwendet für Uplink-Fragmentierung ACK-on-Error und für Unicast-Downlinks ACK-Always; Multicast-Downlinks arbeiten ohne SCHC-ACK, sodass eine höhere Ebene die Zuverlässigkeit sicherstellen muss. Diese Asymmetrie berücksichtigt die unterschiedlichen Funk- und Downlinkbedingungen.
SCHC-Fragmente sind nicht FUOTA-Fragmente
LoRaWAN kennt mit TS004 noch einen weiteren Fragmenttransport. Er gehört zu den Application Packages für FUOTA und große Datenblöcke. SCHC F/R transportiert dagegen SCHC-Pakete und dient insbesondere der IP-Anpassung. Beide Verfahren haben eigene Sitzungen, Header, Zustände und Ports.
Ein System sollte nicht nur das Wort ‚Fragmentierung‘ dokumentieren. Es muss angeben, ob RFC 8724/9011 oder TS004 gemeint ist, welche Komponente reassembliert und wie Fehler gemeldet werden. Ein FUOTA-Server kann nicht automatisch SCHC-Datagramme rekonstruieren; ein SCHC Gateway ist nicht automatisch ein Firmwareverteiler.
IPv6-MTU wird ermöglicht, nicht kostenlos übertragen
IPv6 setzt für Links eine MTU von 1280 Byte voraus. SCHC kann größere Datagramme über einen LPWAN-Link abbilden, indem es sie komprimiert und bei Bedarf fragmentiert. Das bedeutet nicht, dass 1280 Byte auf LoRaWAN plötzlich günstig sind. Jedes Fragment verbraucht Airtime, Empfängerzustand und möglicherweise Downlinks für Bestätigungen.
RFC 9011 zeigt Beispiele, in denen die LoRaWAN-Nutzlast je nach Datenrate und FOpts stark schwankt. Ein nach SCHC komprimiertes Paket kann bei einer günstigen Datenrate in einen Frame passen und bei einer kleineren MTU viele Fragmente benötigen. Für Kapazitätsplanung zählt daher die komplette Verteilung der realen Datenraten in der Flotte, nicht nur ein Best-Case-Gerät.
Geräteklassen beeinflussen den Downlinkablauf
Ein Class-A-Gerät kann nur nach einem eigenen Uplink empfangen. Ein SCHC Gateway kann deshalb keine beliebige Downlink-Fragmentierung starten, solange das Gerät kein Empfangsfenster öffnet. RFC 9011 empfiehlt für entsprechende Class-A-Abläufe regelmäßige Uplinks beziehungsweise leere Frames als Downlinkgelegenheit; das genaue Intervall bleibt anwendungsspezifisch.
Klasse B und C bieten zusätzliche Empfangszeit, erhöhen aber Energie- und Netzanforderungen. Die LoRaWAN-Geräteklassen A, B und C sollten daher anhand des IP-Verkehrsprofils gewählt werden. Ein gelegentlicher CoAP-Response braucht nicht automatisch Klasse C; ein serverinitiierter Managementdienst kann mit reiner Klasse A dagegen unpraktisch sein.
IPv6-Adresse und LoRaWAN-Identität bleiben verschieden
Über Funk adressiert LoRaWAN ein aktiviertes Gerät mit DevAddr und ordnet seine kryptografische Sitzung zusätzlich über Backendzustand zu. Auf IP-Ebene besitzt die SCHC-Architektur eine IPv6-Adresse mit Interface Identifier. RFC 9011 beschreibt eine Zuordnung, bei der die Netzwerkseite das Gerät eindeutig über die DevEUI identifizieren muss.
Eine DevAddr ist nicht global eindeutig und kann sich nach einem Join ändern. Sie sollte daher nicht unbesehen als dauerhafte IPv6-Identität verwendet werden. Provisionierung, IID-Bildung, Datenschutz und ein möglicher Rekey müssen gemeinsam geplant werden. Die IPv6-Adresse ersetzt auch keine LoRaWAN-Authentisierung; beide Schichten behalten ihre Aufgabe.
Das SCHC Gateway ist der erste IP-Hop
Auf der Netzseite dekomprimiert das SCHC Gateway den Header und setzt Fragmente wieder zusammen. RFC 9011 beschreibt die Verbindung zwischen Endgerät und Application Server als einen IP-Hop; das SCHC Gateway wirkt als erster IPv6-Router des Geräts. Der eigentliche IP-Zielserver kann hinter dieser Komponente in einem Unternehmensnetz oder im Internet liegen.
Diese Platzierung erlaubt bestehende IP-Anwendungen, verlangt aber klare Routing- und Firewallregeln. Nicht jedes IPv6-System sollte das Gerät initiativ erreichen dürfen. Der Application Server kann Netzgrenzen, Zugriffspolitik, Rate Limits und Beobachtbarkeit bereitstellen. Eine öffentliche IPv6-Adresse ist kein Auftrag, einen Sensor ungeschützt dem Internet auszusetzen.
Context-Verteilung ist eine Betriebsaufgabe
RFC 9011 verlangt übereinstimmende Rules an Gerät und SCHC Gateway, standardisiert aber nicht, wie der Context verteilt wird. Hersteller können ihn bei Produktion provisionieren, über Gerätemanagement einspielen oder mit Firmwareversionen koppeln. Jede Methode braucht eine Version und eine atomare Umschaltung, damit beide Seiten nicht vorübergehend unterschiedliche Regeln verwenden.
Bei einem Context-Mismatch kann die Gegenstelle ein formal gültiges, aber falsches IPv6-Paket rekonstruieren oder die RuleID nicht kennen. Deshalb sollte das System Rule-Version, letzten erfolgreichen Austausch und Dekompressionsfehler protokollieren. Ein Rückfall auf eine unkomprimierte Regel kann Diagnose ermöglichen, kostet jedoch deutlich mehr Funknutzlast.
Für den Context-Lebenszyklus werden benötigt
- eindeutige Regel- und Versionsbezeichnungen
- Zuordnung zu Geräte-, Firmware- und Anwendungsvarianten
- sicherer Bereitstellungsweg und autorisierte Änderung
- gleichzeitige oder rückwärtskompatible Aktivierung beider Endpunkte
- Monitoring für unbekannte RuleIDs und Dekompressionsfehler
- Rückfallplan für nicht aktualisierte oder lange offline gebliebene Geräte
Sicherheit wirkt auf mehreren Schichten
LoRaWAN verschlüsselt den FRMPayload mit dem Application Session Key und schützt Frames mit den vorgesehenen Integritätsmechanismen. RFC 9011 ordnet SCHC-Daten in diese geschützte Anwendungsnutzlast ein. Damit ist der Funkabschnitt abgesichert, solange Schlüssel und Sitzung korrekt betrieben werden.
IP-Anwendungen können zusätzlich Ende-zu-Ende-Schutz einsetzen, etwa OSCORE für CoAP oder andere geeignete Protokolle. Dieser zusätzliche Header muss in den SCHC-Rules berücksichtigt werden und kann die Kompressionswirkung verändern. Sicherheitsfelder dürfen nicht allein zur Platzersparnis entfernt werden; eine Rule rekonstruiert nur Werte, die beide Seiten sicher kennen oder korrekt übertragen.
Auch Fragmentierung erzeugt Angriffsflächen: Reassembly-Puffer können belegt, Fragmente verfälscht oder Sitzungen absichtlich offen gehalten werden. Zeitlimits, Größenbegrenzungen, wenige parallele Sitzungen und Integritätsprüfung schützen knappe Geräte- und Serverressourcen. Die Standardprofile geben Parameter vor, doch Dimensionierung und Alarmierung bleiben Teil des Betriebs.
LR-FHSS kann den Uplink tragen, ändert SCHC aber nicht
Ein SCHC-Paket wird oberhalb der physischen Modulation erzeugt. Ein geeigneter Uplink kann daher grundsätzlich über eine unterstützte LR-FHSS-Datenrate laufen, ohne die IPv6- oder SCHC-Semantik zu verändern. Gateway, Network Server und Regionalprofil müssen diese Modulation jedoch beherrschen.
Für Downlinkfragmente hilft LR-FHSS derzeit nicht, weil die LR-FHSS-Datenraten in LoRaWAN für den Uplink verwendet werden. Eine IPv6-Anwendung mit viel serverinitiiertem Verkehr bleibt deshalb durch normale Downlinkparameter begrenzt. PHY-Auswahl und SCHC-Regeln sind getrennte Stellschrauben.
Wann IPv6 over LoRaWAN einen echten Vorteil bringt
| Anforderung | SCHC-Vorteil | Zu prüfen |
|---|---|---|
| bestehende IPv6/UDP-Anwendung | weniger proprietäre Protokollbrücken | stabile Flows und passende Rules |
| standardisiertes Zählermanagement | einheitliche IP-Integration | Interoperabilität des Anwendungsprofils |
| seltene CoAP-Nachrichten | kleine komprimierte Header | Downlinkmodell und Sicherheitsheader |
| beliebiger Internetzugang | geringer Nutzen | LoRaWAN ist kein Breitbandzugang |
| große oder häufige IP-Pakete | Fragmentierung technisch möglich | Airtime, Energie und Reassembly-Risiko |
Der stärkste Fall ist eine klar begrenzte IP-Anwendung mit wenigen stabilen Kommunikationsbeziehungen. Dann können vorhandene Protokollwerkzeuge, Adressierungsmodelle und Managementsysteme genutzt werden, während SCHC den Funkoverhead klein hält. Bei einem einfachen Temperatursensor mit drei Bytes Nutzlast ist ein kompakter proprietärer Codec möglicherweise leichter zu betreiben.
Abnahme vom IPv6-Paket bis zum Funkframe
- reale IPv6-, UDP- und Anwendungspakete sowie Kommunikationsrichtungen erfassen
- Rules, RuleIDs, FPorts und Context-Versionen für alle Gerätevarianten definieren
- Kompression und Dekompression bitgenau mit Positiv- und Negativfällen testen
- Fragmentierung bei jeder relevanten LoRaWAN-Nutzlast und Geräteklasse prüfen
- Paketverlust, doppelte Fragmente, Zeitablauf und Reassembly-Grenzen simulieren
- LoRaWAN-Schutz, IP-Sicherheit, Routing und Zugriffspolitik gemeinsam abnehmen
- Airtime, Energie, Downlinks und Fehlerraten unter Flottenlast messen
Ein Ende-zu-Ende-Test beginnt mit einem echten IPv6-Paket auf der Geräteseite und endet mit demselben Paket hinter dem SCHC Gateway. Auf dem Rückweg muss die Anwendung einen Response über die vorgesehene Geräteklasse zustellen. Nur ein sichtbarer Messwert in der Cloud beweist weder korrekte Headerrekonstruktion noch robustes Fragmentverhalten.
IPv6 schafft Interoperabilität, keine zusätzliche Funkkapazität
SCHC kann den Protokolloverhead drastisch reduzieren und IPv6-Anwendungen über einen sehr begrenzten Link ermöglichen. Die physikalischen und regulatorischen Grenzen von LoRaWAN bleiben bestehen: kleine Nutzlasten, schlafende Geräte, begrenzte Downlinks und lange Airtime bei niedrigen Datenraten. Eine gute IP-Integration respektiert diese Eigenschaften, statt Desktopverkehr auf einen Sensorsender zu übertragen.
Wer Context und Verkehrsprofil stabil beherrscht, gewinnt eine saubere standardisierte Brücke zwischen LoRaWAN-Gerät und IP-Welt. Wer beliebige Pakete, häufige Contextwechsel oder dauerhaft erreichbare Hosts erwartet, verschiebt nur Komplexität in Fragmentierung und Downlinks. Die fachliche Entscheidung beginnt daher beim Anwendungsmuster und endet erst beim gemessenen Funkbudget.
Häufige Fragen
Was bedeutet SCHC bei LoRaWAN?
SCHC steht für Static Context Header Compression and fragmentation. Es komprimiert vorhersehbare IPv6- und UDP-Header anhand gemeinsamer Regeln und kann große Pakete fragmentieren.
Wird ein LoRaWAN-Gerät durch SCHC direkt zum Internet-Host?
Es erhält eine IP-Einbindung über ein SCHC Gateway als ersten Router. Routing, Firewall, Zugriffsregeln und LoRaWAN-Empfangsfenster bleiben erforderlich.
Ist SCHC-Fragmentierung dasselbe wie FUOTA-Fragmentierung?
Nein. SCHC F/R nach RFC 8724/9011 transportiert SCHC-Pakete. FUOTA verwendet den separaten Fragmented Data Block Transport nach TS004.
Wo wird die SCHC RuleID in LoRaWAN übertragen?
RFC 9011 verwendet eine 8 Bit breite RuleID im LoRaWAN FPort. Deshalb müssen SCHC-Regeln und sonstige Portbelegungen gemeinsam verwaltet werden.
Beseitigt SCHC die LoRaWAN-Nutzlastgrenze?
Nein. Kompression reduziert Header, und Fragmentierung bildet größere Datagramme ab. Jedes Fragment verbraucht weiterhin Airtime, Energie und gegebenenfalls Downlinkkapazität.