LoRaWAN-Geräteklassen A, B und C im Detail: Empfangsfenster, Latenz und Energie
Die LoRaWAN-Geräteklassen A, B und C beschreiben vor allem, wann ein Endgerät für Downlinks empfangsbereit ist. Sie sind keine Qualitätsstufen und keine Aussage über Reichweite oder Sicherheit. Ein Sensor der Klasse A kann denselben Uplink genauso weit senden wie ein Gerät der Klasse C. Der Unterschied liegt im Empfangsplan, im Energiebedarf und in der erreichbaren Downlink-Latenz.
Jedes standardkonforme LoRaWAN-Endgerät beherrscht Klasse A. Klasse B und Klasse C kommen als zusätzliche Betriebsarten hinzu; die Class-A-Empfangsfenster bleiben auch dann erhalten. Diese gemeinsame Basis ist entscheidend, weil viele Missverständnisse aus der Vorstellung entstehen, ein Gerät wechsle vollständig in ein anderes Protokoll.
Kurz zusammengefasst: Klasse A spart am meisten Energie, kann Downlinks aber erst nach einem eigenen Uplink empfangen. Klasse B ergänzt zeitlich geplante Ping Slots auf Basis synchronisierter Beacons. Klasse C hört nahezu ständig und bietet damit die niedrigste Downlink-Latenz, benötigt jedoch deutlich mehr Energie und verfügbare Downlink-Kapazität im Netz.
| Merkmal | Klasse A | Klasse B | Klasse C |
|---|---|---|---|
| Pflicht | von jedem Endgerät unterstützt | optional | optional |
| Zusätzliche Empfangszeit | RX1 und RX2 nach Uplink | geplante Ping Slots | RXC nahezu ständig offen |
| Downlink-Auslöser | vorheriger Geräte-Uplink | Netzwerkzeit und Ping-Plan | Netzwerk kann kurzfristig senden |
| Energiebedarf | am niedrigsten | zwischen A und C | am höchsten |
| Typische Versorgung | Batterie | Batterie oder Energy Harvesting | meist Netzteil oder große Energiequelle |
| Typischer Einsatz | Messwerte und seltene Konfiguration | geplante Steuer- oder Verteilfenster | Aktoren und zeitnahe Downlinks |
Klasse A: Der Uplink öffnet die Tür
Die LoRaWAN-L2-Spezifikation 1.0.4 verlangt nach einem Uplink ein Empfangsfenster RX1 und, falls dort kein passender Downlink empfangen wurde, ein zweites Fenster RX2. RX1 verwendet eine Frequenz, die von der Uplink-Frequenz abhängt, und eine regional definierte Beziehung zwischen Uplink- und Downlink-Datenrate. RX2 arbeitet mit einer festen, konfigurierbaren Frequenz und Datenrate.
Die Standardverzögerungen und Datenraten hängen von Aktivierung und Region ab. Entscheidend ist das Prinzip: Der Network Server darf einen Class-A-Downlink nur präzise am Beginn von RX1 oder RX2 senden. Danach schließt das Gerät den Empfänger und kann lange schlafen. Für einen Zähler, Bodenfeuchtesensor oder einfachen Zustandsmelder ist das ideal.
Downlink-Latenz in Klasse A
Ein Downlink, der direkt nach dem letzten RX2 entsteht, wartet bis zum nächsten Uplink. Bei einem Sensor mit stündlichem Sendeintervall kann die Wartezeit daher fast eine Stunde betragen. Der Application Server sollte den Downlink rechtzeitig beim Network Server einstellen; der wiederum wählt ein geeignetes Gateway für das nächste Empfangsfenster.
Häufigere Leer-Uplinks nur zum Abholen von Downlinks verkürzen die Latenz, erhöhen aber Airtime und Energieverbrauch. Darum gehört die zulässige Reaktionszeit bereits in die Anforderungsanalyse. Wenn eine Einstellung innerhalb eines Tages ankommen darf, bleibt Klasse A oft die bessere Lösung als ein höherer Empfangsmodus.
RX1 und RX2 sind keine zwei garantierten Zustellungen
Die beiden Fenster bieten zwei mögliche Zeitpunkte, aber der Network Server sendet einen vorgesehenen Downlink nicht einfach automatisch zweimal. Hat das Gerät in RX1 einen passenden Frame empfangen, öffnet es RX2 für diesen Zyklus nicht mehr. Gateway-Verfügbarkeit, Duty Cycle, Frequenzplan und Kollisionslage entscheiden weiterhin darüber, ob ein Downlink tatsächlich gesendet und empfangen werden kann.
Die LoRa-Gateway-Grundlagen erklären die Brückenrolle zwischen Funk und Network Server. Für die Klassenwahl ist wichtig: Ein häufiger hörendes Endgerät vergrößert nicht automatisch die Sendekapazität des Gateways.
Klasse B: Beacons schaffen einen gemeinsamen Zeitplan
Ein Class-B-fähiges Gerät empfängt periodische, zeitgenaue Beacons des Netzes. Auf dieser Zeitbasis öffnet es zusätzliche Ping Slots. Gerät und Network Server kennen den Plan, sodass ein Downlink nicht auf einen unmittelbar vorhergehenden Uplink warten muss. Der Beacon-Zeitraum beträgt in der L2-Spezifikation 128 Sekunden; innerhalb dieses Rahmens kann die Ping-Slot-Periodizität konfiguriert werden.
Das ClassB-Bit im FCtrl eines Uplinks signalisiert dem Network Server, dass das Gerät Klasse B aktiviert hat und geplante Pings empfangen kann. Vorher muss das Gerät Zeit und Beacon gefunden, seine Empfangsparameter eingerichtet und den Zustand stabil erreicht haben. Ein Datenblatt mit dem Wort Class B ersetzt diese Zustandsmaschine nicht.
Was die Class-B-Infrastruktur leisten muss
Gateways müssen Beacons zeitgenau senden können, und der Network Server muss Ping Slots sowie geeignete Downlink-Gateways planen. Bei mobilen Geräten braucht er außerdem aktuelle Information darüber, über welches Gateway das Gerät am besten erreichbar ist. Die Spezifikation empfiehlt deshalb regelmäßige Uplinks oder eine Aktualisierung beim Zellwechsel.
Geht ein Beacon verloren, fällt das Gerät nicht sofort aus. Es kann mit wachsendem Empfangsfenster vorübergehend beaconlos weiterarbeiten, muss aber seine Uhrdrift berücksichtigen. Wiederholter Beacon-Verlust erhöht Energiebedarf und Unsicherheit. Eine Class-B-Abnahme prüft deshalb nicht nur einen erfolgreichen Ping, sondern auch Synchronisation, Drift, Beacon-Ausfall und Wiedererfassung.
Class B passt, wenn
- Downlinks planbarer als in Klasse A sein sollen
- das Gerät weiterhin überwiegend schlafen muss
- Gateways und Network Server zeitgenaue Beacons sicher unterstützen
- eine begrenzte, geplante Downlinkfrequenz genügt
- Beacon-Verlust und erneute Synchronisation betrieblich getestet sind
Klasse C: RXC ist fast immer offen
Ein Class-C-Gerät hört mit den RXC-Parametern, solange es nicht selbst sendet oder die priorisierten Class-A-Fenster RX1 und RX2 bedient. Nach RX2 kehrt es in den kontinuierlichen Empfang zurück. Der Server kann dadurch meist zeitnah einen Downlink anstoßen, ohne auf einen Geräte-Uplink oder einen bestimmten Ping Slot zu warten.
Nahezu kontinuierlicher Empfang bedeutet nicht absolut unterbrechungsfreien Empfang. Während eigener Uplinks kann ein Halbduplexgerät nicht hören. RX1 und RX2 unterbrechen den RXC-Pfad, und auch Frequenzwechsel oder laufende Demodulationen spielen eine Rolle. Klasse C bietet die niedrigste Latenz der drei Klassen, aber keine harte Echtzeitgarantie.
Warum Klasse C meist eine feste Versorgung braucht
Der Radioempfänger bleibt lange aktiv. Sein Strombedarf liegt typischerweise um Größenordnungen über dem Tiefschlaf eines sparsamen Sensors. Eine konkrete Batterielaufzeit lässt sich trotzdem nicht pauschal nennen, weil Funkchip, Empfangsstrom, Spannungswandler, Temperatur, Uplinks und Anwendungselektronik zusammenwirken.
Für netzversorgte Ventilstellungsanzeigen, Beleuchtungsaktoren oder Gebäudecontroller kann Klasse C sinnvoll sein. Batteriebetrieb ist eher für kurze, bewusst aktivierte Class-C-Phasen geeignet. Die Remote Multicast Setup Specification beschreibt beispielsweise temporäre Klasse-B- oder Klasse-C-Fenster für Verteilaufgaben und die Rückkehr in den ursprünglichen Modus.
Klasse B und C laufen nicht gleichzeitig
Ein Endgerät darf Klasse B und Klasse C nicht gleichzeitig aktivieren. Beide bleiben jedoch mit Klasse A kompatibel. Die Class-A-Fenster nach einem Uplink haben Vorrang vor dem geplanten Ping beziehungsweise dem RXC-Empfang. Diese Regel macht das Verhalten für den Network Server eindeutig und erhält die gemeinsame Basis aller Endgeräte.
Der Wechsel zwischen Klassen ist ein Betriebszustand, kein neues Onboarding. Trotzdem müssen Anwendung und Backend wissen, welcher Zustand aktiv ist. Sonst plant der Server einen Class-C-Downlink, obwohl das Gerät wieder in Klasse A schläft. Statusmodell, Timeout und Rückfallverhalten gehören daher zur Anwendungsschnittstelle.
Mehr Empfangsfenster schaffen keine unbegrenzten Downlinks
In lizenzfreien Bändern unterliegen auch Gateways regionalen Sendegrenzen. Ein Gateway kann zudem während eines Downlinks auf dem betroffenen Funkpfad keine Uplinks empfangen. Häufige bestätigte Nachrichten, Class-C-Steuerungen oder große Multicast-Aktionen belasten daher die Zelle. Der aktuelle Regional-Parameters-Stand RP002-1.0.5 legt Frequenzen, Datenraten, Sendeleistung und weitere regionale Rahmenbedingungen fest.
Die Klasse beantwortet nur, wann das Gerät zuhört. Ob das Netzwerk senden darf und eine freie Gateway-Ressource hat, ist eine zweite Frage. Eine belastbare Architektur dimensioniert Uplink und Downlink gemeinsam, statt Klasse C mit unbegrenzter Fernsteuerbarkeit gleichzusetzen.
Reichweite und Datenrate werden separat bestimmt
Klasse A, B oder C legt weder Spreading Factor noch Sendeleistung fest. Diese Parameter werden durch Region, Gerätekonfiguration und gegebenenfalls Adaptive Data Rate beeinflusst. Ein Class-C-Gerät am Rand der Abdeckung kann weiterhin eine langsame Datenrate und lange Airtime benötigen. Umgekehrt kann ein Class-A-Sensor nahe am Gateway mit einer schnellen Datenrate senden.
Auch die Anwendungspayload bleibt klein. Mehr Empfangszeit ändert nicht die maximale Framegröße oder die Eignung für Videodaten, Audio oder kontinuierliche Steuerkurven. Der Beitrag zur MAC- und Frame-Struktur zeigt, welcher Teil eines Funkpakets tatsächlich für Nutzdaten zur Verfügung steht.
Typische Auswahl nach Anwendungsfall
| Anforderung | Sinnvolle Ausgangswahl | Warum | Zu prüfen |
|---|---|---|---|
| seltene Messwerte, kaum Downlinks | Klasse A | minimale Empfangszeit | zulässige Wartezeit auf Konfiguration |
| batteriebetrieben, geplante tägliche Downlinks | Klasse B | planbare Slots ohne Dauerempfang | Beacon-Abdeckung und Drift |
| netzversorgter Aktor, kurze Reaktionszeit | Klasse C | nahezu kontinuierlicher Empfang | Gateway-Downlinkbudget |
| Firmwareverteilung an viele Geräte | temporär B oder C plus Multicast | gebündelte Verteilfenster | Fragmentierung, Energie und Rückfall |
| sicherheitskritische Sofortabschaltung | keine Klasse allein | LoRaWAN liefert keine harte Echtzeit | lokale zugelassene Schutzfunktion |
Die Geräteklasse verändert auch den Arbeitsprozess
Die technische Latenz ist nur ein Teil der Reaktionszeit. Ein Class-C-Aktor kann einen Downlink schnell empfangen, doch der Befehl muss zuvor fachlich freigegeben, im Application Server erzeugt und vom Network Server eingeplant werden. Umgekehrt kann ein Class-A-Sensor mit stündlichem Uplink völlig ausreichen, wenn Konfigurationsänderungen ohnehin nur im Wartungsfenster erfolgen.
Deshalb sollte die Klasse nicht isoliert vom Prozess beschafft werden. Zu dokumentieren sind Ursprung und Gültigkeit eines Downlinks, Wiederholungsverhalten, Quittierung auf MAC- und Anwendungsebene sowie der Zustand nach einem Neustart. Bei Aktoren gehört außerdem festgelegt, was geschieht, wenn ein verspäteter Befehl erst nach einer inzwischen geänderten Betriebssituation eintrifft.
Mobilität verändert die Bewertung
Uplinks können von mehreren Gateways empfangen und im Network Server dedupliziert werden. Für Downlinks muss der Server jedoch ein passendes Gateway auswählen. Bei Klasse A liefert der gerade empfangene Uplink eine aktuelle Route. Bei Klasse B oder C kann die letzte Meldung älter sein, während sich das Gerät bereits bewegt hat.
Mobile Class-B- und Class-C-Anwendungen brauchen daher regelmäßige Uplinks, sinnvoll gesetzte Gültigkeitszeiten und ein Verfahren für Zellwechsel. Das erhöht Funklast und Energiebedarf. Für viele Tracker bleibt Klasse A deshalb trotz höherer Downlink-Latenz die robustere Wahl.
So wird die Klassenwahl getestet
- maximal zulässige Downlink-Latenz und tägliche Downlinkmenge festlegen
- Energieprofil im echten Modus einschließlich Synchronisation messen
- RX1, RX2, Ping Slots und RXC mit Paketverlust gezielt prüfen
- Gateway-Ausfall, Beacon-Verlust und Rückkehr in Klasse A simulieren
- bestätigte Frames und Wiederholungen unter regionalen Sendegrenzen testen
- Backendstatus mit dem tatsächlich aktiven Gerätemodus abgleichen
Die richtige Klasse ist die sparsamste Betriebsart, die die echte Downlink-Anforderung erfüllt. Wer die Latenz nicht benennt, wählt leicht Klasse C aus Bequemlichkeit und bezahlt später mit Energie, Netzlast und komplexerem Betrieb.
Häufige Fragen
Muss jedes LoRaWAN-Gerät Klasse A unterstützen?
Ja. Klasse A ist die gemeinsame Pflichtbasis. Klasse B und Klasse C sind zusätzliche Betriebsarten und behalten die Class-A-Empfangsfenster bei.
Welche Klasse verbraucht am wenigsten Energie?
In der Regel Klasse A, weil der Empfänger nur kurz nach einem eigenen Uplink aktiv ist. Der tatsächliche Verbrauch hängt dennoch von Hardware, Sendeintervall und Anwendung ab.
Ist Klasse C echtzeitfähig?
Klasse C reduziert die Downlink-Latenz stark, garantiert aber keine harte Echtzeit. Eigene Uplinks, Gateway-Sendegrenzen, Funkkollisionen und Netzplanung bleiben wirksam.
Kann ein Gerät gleichzeitig Klasse B und C verwenden?
Nein. Klasse B und Klasse C dürfen nicht gleichzeitig aktiviert sein. Beide Betriebsarten bleiben jedoch mit Klasse A kompatibel.
Erhöht Klasse C die LoRaWAN-Reichweite?
Nein. Die Geräteklasse bestimmt den Empfangszeitplan. Reichweite und Airtime hängen unter anderem von Datenrate, Funkumgebung, Antenne, Sendeleistung und Regional Parameters ab.