LoRaWAN-Zeitsynchronisation und Beacon-Protokoll: DeviceTime, Class B und AppTime

Zeit wirkt in einem Sensornetz zunächst simpel: Ein Messwert erhält einen Zeitstempel, also braucht das Gerät eine Uhr. In LoRaWAN erfüllt Zeit jedoch mehrere getrennte Aufgaben. Class-B-Geräte orientieren ihre Ping Slots an Netzbeacons, ein Network Server kann die Gerätezeit per DeviceTimeReq korrigieren, und das Application-Layer-Paket TS003 stellt eine weitere Synchronisationsmethode bereit. Wer diese Verfahren gleichsetzt, baut leicht unnötige Abhängigkeiten oder erwartet eine Genauigkeit, die das gewählte Verfahren nicht liefern kann.

Der richtige Ansatz beginnt deshalb mit der Frage, wofür Zeit benötigt wird: für die Reihenfolge von Messungen, einen koordinierten Neustart, ein Abrechnungsintervall, ein Class-B-Empfangsfenster oder eine zeitkritische Regelung. Erst danach lässt sich entscheiden, ob eine lokale Echtzeituhr, LoRaWAN-Netzzeit, ein Application Package oder eine externe GNSS-Quelle passt.

Kurz zusammengefasst: Class-B-Beacons synchronisieren den Class-B-Zeitplan. DeviceTimeReq und DeviceTimeAns liefern Netzwerkzeit über ein MAC-Kommando. TS003 gleicht eine Anwendungsuhr mit annähernder Sekundengenauigkeit ab. Keines dieser Verfahren macht LoRaWAN zu einem harten Echtzeitsystem, und synchronisierte Geräte sollten ihre Uplinks weiterhin zeitlich entzerren.

Drei LoRaWAN-Verfahren, drei Rollen

Verfahren	Ebene	Hauptzweck	Wichtige Grenze
Class-B-Beacon	MAC und Geräteklasse	Netzzeit und Zeitbasis für Ping Slots	setzt Class-B-Infrastruktur und Beacon-Empfang voraus
DeviceTimeReq/Ans	MAC-Kommando	Gerät fragt aktuelle Netzwerkzeit ab	Antwort braucht ein passendes Downlinkfenster
TS003 AppTime	Application Layer	Anwendungsuhr auf Netzwerkzeit korrigieren	annähernde Sekundengenauigkeit, eigener Paketstatus
externe Zeitquelle	Geräte- oder Anlagenebene	höhere Genauigkeit oder autonome Referenz	zusätzliche Hardware, Energie und Empfangsbedingungen

Die Verfahren können nebeneinander existieren. Ein Class-A-Gerät kann DeviceTime nutzen, ohne je einen Beacon zu empfangen. Ein Class-B-Gerät kann seine Ping Slots aus Beacons ableiten und trotzdem eine Anwendungssynchronisation für Messzeitstempel ausführen. Entscheidend ist, dass Firmware und Backend klar festlegen, welche Uhr für welchen Zweck maßgeblich ist.

Warum Zeit in LoRaWAN-Anwendungen gebraucht wird

• Messwerte aus verschiedenen Sensoren in eine gemeinsame Reihenfolge bringen
• Verbrauchs-, Produktions- oder Wartungsintervalle sauber abgrenzen
• Class-B-Ping-Slots und geplante Multicast-Fenster erreichen
• Firmware oder Konfiguration zu einem freigegebenen Zeitpunkt aktivieren
• lokale Ereignisse nach einem Netzausfall mit plausiblen Zeitstempeln nachliefern
• Uhrdrift, Neustarts und verlorene Zeitquellen als Gerätezustand erkennen

Nicht jeder Anwendungsfall braucht eine absolute Uhr. Für die Laufzeit eines Motors kann ein monotoner Zähler genügen; für einen Monatsverbrauch ist Kalenderzeit erforderlich. Diese Trennung ist nützlich, weil eine korrigierte Echtzeituhr springen kann, während ein monotoner Timer nicht rückwärts laufen sollte. Gute Firmware speichert daher Messzeit, Laufzeit und Synchronisationsqualität als unterschiedliche Größen.

Class-B-Beacons bilden den Zeitrahmen

Die LoRaWAN-L2-Spezifikation 1.0.4 beschreibt für Klasse B periodische Beacons im Abstand von 128 Sekunden. Ein Class-B-fähiges Gerät sucht den Beacon, übernimmt die Zeitbasis und berechnet daraus seine Ping Slots. Der Network Server kennt denselben Plan und kann einen Downlink in einem dieser zusätzlichen Empfangsfenster ansetzen, ohne unmittelbar zuvor einen Geräte-Uplink abzuwarten.

Ein Beacon ist damit kein allgemeiner Broadcastkanal für Sensordaten. Er transportiert protokollspezifische Zeit- und Netzangaben und wird von geeigneten Gateways zeitgenau ausgestrahlt. Die Nutzdaten der Anwendung bleiben in normalen LoRaWAN-Frames. Auch die Ping Slots sind Empfangsgelegenheiten, keine reservierte Ende-zu-Ende-Bandbreite. Gateway-Sendegrenzen und konkurrierende Downlinks gelten weiterhin.

Beacon-Erfassung ist ein eigener Betriebszustand

Bevor ein Gerät Klasse B aktiviert, muss es Zeit ermitteln, einen Beacon finden und seine Empfangsparameter aufbauen. Dieser Vorgang kostet Energie. Nach erfolgreicher Synchronisation signalisiert das Gerät seinen Class-B-Zustand im Uplink, damit der Network Server Ping-Slot-Downlinks planen kann. Ein statisch gesetztes Profil im Backend beweist also nicht, dass das Gerät tatsächlich synchronisiert ist.

Verliert das Gerät einzelne Beacons, kann es die nächsten Zeitpunkte aus seiner lokalen Uhr abschätzen und das Empfangsfenster entsprechend der Unsicherheit vergrößern. Mit wachsender Drift steigt der Energiebedarf, bis eine erneute Erfassung nötig wird. Ein stabiler Betrieb misst deshalb Beacon-Lock, verlorene Beacons, Suchdauer und die durch Drift erweiterte Empfangszeit. Die Grundlagen der Betriebsarten erklärt die Analyse der LoRaWAN-Geräteklassen.

Class-B-Zeit ist geeignet, wenn

• geplante Downlinks wichtiger sind als eine frei abrufbare Präzisionszeit
• Gateways Beacons für die verwendete Region zuverlässig senden
• das Gerät Beacon-Suche und Drift energetisch tragen kann
• der Network Server den tatsächlichen Class-B-Zustand verfolgt
• Ausfall und Wiedererfassung der Beacon-Zeit getestet sind

DeviceTimeReq fragt die Netzwerkzeit per MAC-Kommando ab

Seit LoRaWAN 1.0.3 kann ein Endgerät DeviceTimeReq senden. Der Network Server antwortet mit DeviceTimeAns und liefert Sekunden seit der GPS-Epoche sowie einen Sekundenbruchteil in Schritten von 1/256 Sekunde. Die Auflösung des Feldes ist jedoch nicht automatisch die erreichbare Ende-zu-Ende-Genauigkeit. Funklaufzeit, Verarbeitung, Zeitpunkt der Zeitnahme und lokale Software müssen ebenfalls berücksichtigt werden.

DeviceTimeReq passt gut, wenn ein Gerät gelegentlich seine RTC korrigieren oder nach einem Neustart eine Zeitbasis aufbauen soll. Das Kommando folgt den normalen LoRaWAN-Regeln: Ein Class-A-Gerät empfängt die Antwort in RX1 oder RX2 nach seinem Uplink. Fällt der Downlink aus, braucht die Firmware eine begrenzte Wiederholstrategie. Dauerndes Nachfragen verschwendet Energie und Downlinkkapazität.

TS003 synchronisiert die Anwendungsuhr

Das Paket TS003-2.0.0 Application Layer Clock Synchronization richtet sich an Geräte ohne hinreichend genaue externe Zeitquelle. Es definiert Nachrichten, mit denen die Anwendung ihre Echtzeituhr auf die GPS-basierte Netzwerkzeit mit annähernder Sekundengenauigkeit abgleichen kann. Der empfohlene FPort ist 202. Package Identifier und Package Version erlauben dem Server, die unterstützte Variante zu erkennen.

AppTimeReq enthält unter anderem einen Token und die vom Gerät angenommene Zeitkorrektur. AppTimeAns bestätigt den Token und liefert die notwendige Korrektur. Version 2 ergänzt Kommandos für die gewünschte Synchronisationsperiodizität und eine erzwungene Neusynchronisation. Sie ist nicht einfach wire-kompatibel mit Version 1; Paketversionen müssen daher in Geräteprofil und Serverlogik übereinstimmen.

AppTime und DeviceTime sind Alternativen, keine Duplikate

Frage	DeviceTime	TS003 AppTime
Transport	MAC-Kommando	verschlüsselte Anwendungsnutzlast
Verfügbarkeit	LoRaWAN 1.0.3 und neuer	Gerät und Anwendung müssen Package unterstützen
Antwortverhalten	Network Server antwortet auf Anfrage	Server kann anhand Toleranz und Paketlogik reagieren
Konfiguration	keine eigene Package-Periodizität	Periodizität und erzwungene Resynchronisation definiert
Typischer Einsatz	allgemeine Gerätezeit	anwendungsgesteuerter Zeitdienst

Für ein neues Gerät genügt häufig DeviceTime, wenn der Stack es zuverlässig unterstützt und keine besonderen Application-Package-Funktionen benötigt werden. TS003 ist sinnvoll, wenn eine bestehende FUOTA- oder Gerätemanagementarchitektur auf den standardisierten Anwendungspaketen aufbaut. Zwei parallele Zeitdienste ohne klare Priorität erhöhen dagegen das Risiko widersprüchlicher Korrekturen.

GPS-Epoche ist nicht dasselbe wie eine formatierte Ortszeit

LoRaWAN überträgt keine Zeichenkette wie ‚21.07.2026 14:30 Uhr Berlin‘. Die Protokolle arbeiten mit einer Sekundenzahl bezogen auf die GPS-Epoche vom 6. Januar 1980 und gegebenenfalls einem Bruchteil. Zeitzone, Sommerzeit und ein lesbares Kalenderformat sind Aufgaben der Anwendung oder des Backends. Sensoren sollten Messwerte möglichst in einer eindeutigen, zeitzonenunabhängigen Form speichern.

Auch Sprünge der Echtzeituhr brauchen Regeln. Wird eine vorgehende Uhr zurückgestellt, dürfen Ereignisnummern, Frame Counter oder Sicherheitszustände nicht rückwärts laufen. Diese Größen besitzen eigene Semantik. Insbesondere die LoRaWAN Frame Counter sind keine Uhr und dürfen durch eine Zeitkorrektur niemals verändert werden. Wie sie im Funkframe verwendet werden, zeigt der LoRaWAN MAC Layer.

Uhrdrift bestimmt das Synchronisationsintervall

Ein Quarz mit 20 ppm kann unter idealisierter Annahme in 24 Stunden rund 1,7 Sekunden abweichen. Temperatur, Alterung, Versorgung und Sleep-Modus verändern den realen Wert. Statt pauschal stündlich zu synchronisieren, sollte der Betreiber die maximal zulässige Zeitabweichung festlegen und aus gemessener Drift ein Intervall ableiten. Geräte können die Unsicherheit seit dem letzten erfolgreichen Abgleich mitführen.

Ein besserer Quarz oder eine temperaturkompensierte RTC kann mehr Energie sparen als häufige Funkkorrekturen. Umgekehrt lohnt zusätzliche Hardware nicht, wenn Zeit nur für tägliche Messblöcke benötigt wird. Die Entscheidung umfasst Stückkosten, Ruhestrom, gewünschte Genauigkeit, Wartungsdauer und die Wahrscheinlichkeit längerer Funkunterbrechungen.

Synchronisierte Messung heißt nicht synchronisierte Übertragung

TS003 weist ausdrücklich darauf hin, dass Geräte mit gleichzeitig geplanten Messungen ihre Meldungen nicht alle im selben Augenblick funken sollen. Tausende Uplinks direkt an einer vollen Minute erhöhen Kollisionen und Gatewaylast. Der Messzeitpunkt kann gemeinsam sein, während die Übertragung durch einen reproduzierbaren oder zufälligen Versatz über ein größeres Fenster verteilt wird.

Das Backend ordnet den verspätet übertragenen Wert über seinen Messzeitstempel korrekt ein. So bleiben Zeitreihen vergleichbar, ohne die Funkschnittstelle zu überlasten. Für Alarmdaten kann ein separater, engerer Übertragungsweg gelten; selbst dann braucht ein Massenereignis wie Stromwiederkehr eine Entzerrungsstrategie.

Praxisregel: Zeitgleich erfassen, zeitlich verteilt senden. Die gemeinsame Uhr verbessert die Datenqualität; ein gestaffelter Uplink schützt die Funkkapazität.

FUOTA und Multicast benötigen verlässliche Zeit

Bei LoRaWAN FUOTA wechseln Gerätegruppen für ein geplantes Verteilfenster zeitweilig in Klasse B oder C. TS005-2.0.0 Remote Multicast Setup beschreibt diese Fenster einschließlich der Rückkehr in die ursprüngliche Betriebsart. Eine falsche Gerätezeit kann dazu führen, dass das Gerät schläft, während das Gateway Fragmente sendet.

Der Rollout sollte deshalb vor dem großen Downlink prüfen, wann jedes Gerät zuletzt synchronisiert wurde und welche Unsicherheit gemeldet oder abgeleitet wird. Unsichere Geräte können zuerst einen Zeitabgleich erhalten oder in eine spätere Gruppe verschoben werden. Ein gemeinsamer Startzeitpunkt ohne Zustandsprüfung ist keine Synchronisationsstrategie.

Relay verwendet Zeit für Wake-on-Radio

Auch die LoRaWAN-Relay-Funktionalität benötigt eine abgestimmte Zeitbasis. Ein Relay schläft zwischen kurzen Channel-Activity-Detection-Phasen; das Endgerät sendet vor seinem eigentlichen Uplink eine Wake-on-Radio-Sequenz. Je besser beide Seiten zeitlich zueinander passen, desto kürzer kann die Wecksequenz ausfallen und desto weniger Energie verbrauchen sie.

Das macht Relay-Zeit nicht zu einem Ersatz für Class-B-Beacons oder AppTime. Sie dient einer anderen Protokollfunktion und wird innerhalb der Relay-Spezifikation behandelt. In einer kombinierten Implementierung sollten die Zeitquellen trotzdem auf eine gemeinsame RTC und klar definierte Qualitätswerte abgebildet werden.

Sicherheit und Plausibilitätsprüfung

Zeit kann Sicherheitsentscheidungen beeinflussen: Zertifikatsgültigkeit, Anti-Rollback, Protokollierung oder ein geplanter Firmwarestart hängen davon ab. Eine empfangene Zeit sollte daher nicht ungeprüft jeden lokalen Zustand überschreiben. Die Firmware kann maximale Sprünge begrenzen, große Abweichungen melden und zwischen erster Initialisierung und laufender Korrektur unterscheiden.

LoRaWAN schützt die jeweilige MAC- oder Anwendungsnachricht nach ihrem Sicherheitsmodell. Das garantiert aber nicht, dass die lokale Verarbeitung fehlerfrei ist. Ein falscher Datentyp, Überlauf der 32-Bit-Zeit oder eine unklare Umrechnung kann ebenso schaden wie ein Funkangriff. Langzeittests müssen deshalb auch Grenzwerte, Neustarts und den Übergang über große Zeitkorrekturen abdecken.

Abnahme unter realen Störungen

1. Zeitbedarf, zulässige Abweichung und maßgebliche Uhr je Funktion festlegen
2. DeviceTime, AppTime oder Class-B-Beacon bewusst auswählen und Versionen dokumentieren
3. Drift bei Temperaturgrenzen und typischen Sleep-Zyklen messen
4. verlorene Antworten, mehrere verlorene Beacons und Gatewaywechsel simulieren
5. Massen-Neustart und gleichzeitige Messung mit entzerrten Uplinks testen
6. Zeitkorrektur vor FUOTA-, Multicast- und Relay-Sitzungen verifizieren
7. Monitoring für letzte Synchronisation, Abweichung und Zeitquelle einrichten

Ein guter Test vergleicht Gerätezeit, Serverzeit und tatsächlichen Funkzeitpunkt, statt nur den Zeitstempel in einer Datenbank anzusehen. Er prüft außerdem, wie sich die Anwendung verhält, wenn mehrere Tage keine Korrektur möglich ist. So wird sichtbar, ob Zeit nur unter Laborbedingungen stimmt oder im normalen Geräteleben belastbar bleibt.

Welche Genauigkeit realistisch ist

TS003 zielt auf annähernde Sekundengenauigkeit. Für viele Zähler, Umweltmessungen und Wartungsdaten ist das ausreichend. Anwendungen, die Millisekunden genau auslösen, Phasen vergleichen oder Schutzfunktionen koordinieren, brauchen eine andere Zeitarchitektur, etwa GNSS, PTP in einem lokalen Netz oder direkt verdrahtete Signale. LoRaWAN kann dann Messwerte und Zustände übertragen, sollte aber nicht als präziser Trigger missverstanden werden.

Die passende Zeitsynchronisation ist deshalb selten die technisch maximal genaue. Sie ist die einfachste Methode, die die fachliche Toleranz über Temperatur, Schlafdauer, Funkverlust und Gerätelebenszeit nachweislich einhält. Wird diese Toleranz messbar gemacht, lassen sich Protokolloption, RTC und Synchronisationsintervall nüchtern auswählen.

Häufige Fragen

Wie oft sendet LoRaWAN einen Class-B-Beacon?

Der Class-B-Beacon-Zeitraum beträgt 128 Sekunden. Ob ein Gerät den Beacon zuverlässig empfängt und wie oft es suchen muss, hängt von Netz, Region, Funkabdeckung und Uhrdrift ab.

Was ist der Unterschied zwischen DeviceTime und AppTime?

DeviceTime ist ein MAC-Kommando ab LoRaWAN 1.0.3. AppTime gehört zum Application-Layer-Paket TS003 und bietet zusätzliche Paketfunktionen wie eine konfigurierbare Synchronisationsperiodizität.

Braucht ein Class-A-Gerät einen Beacon für die Uhrzeit?

Nein. Ein Class-A-Gerät kann DeviceTime oder TS003 verwenden und seine lokale Uhr in den normalen RX1- oder RX2-Fenstern abgleichen.

Erreicht LoRaWAN-Zeitsynchronisation Millisekundengenauigkeit?

TS003 zielt auf annähernde Sekundengenauigkeit. Für harte Millisekundenanforderungen ist eine dafür ausgelegte externe oder lokale Zeitquelle erforderlich.

Sollten synchronisierte Geräte gleichzeitig senden?

Nein. Gemeinsame Messzeitpunkte sind möglich, aber Uplinks sollten über ein Zeitfenster verteilt werden, damit nicht viele Geräte gleichzeitig um dieselbe Funkkapazität konkurrieren.