LoRaWAN Relay-Funktionalität: TS011-1.0.1, Wake-on-Radio und RXR

Ein Sensor im Keller erreicht das Gateway nicht, wenige Meter weiter wäre jedoch eine stabile Verbindung möglich. Für solche lokalen Funklöcher definiert LoRaWAN eine standardisierte Relay-Funktion. Ein batteriebetriebenes Zwischengerät kann Uplinks und Downlinks zwischen Endgerät und Gateway beziehungsweise Network Server weiterleiten, ohne selbst zu einem vollwertigen Gateway zu werden.

Relay ist dabei weder ein analoger Funkverstärker noch ein allgemeines Mesh. Endgerät, Relay und Network Server folgen einem zusätzlichen, koordinierten Protokoll. Wake-on-Radio weckt das Relay für den Uplink; eine besondere RXR-Empfangsphase bringt den Downlink zurück. Diese Architektur kann einzelne schwierige Standorte erschließen, verbraucht aber zusätzliche Airtime und Energie.

Kurz zusammengefasst: Die aktuelle LoRaWAN-Relay-Spezifikation ist TS011-1.0.1. Sie arbeitet als Zusatz zu bestehenden LoRaWAN-L2-Versionen. Das Relay besitzt eine eigene LoRaWAN-Verbindung, hört energiesparend auf Wake-on-Radio-Signale und leitet ausgewählte Frames weiter. Es ersetzt weder eine flächige Gatewayplanung noch ein sicherheitskritisches Echtzeitnetz.

Versionshinweis: TS011-1.0.1 statt LoRaWAN 1.1.1+

Relay wurde nicht mit einer veröffentlichten LoRaWAN-Link-Layer-Version 1.1.1 eingeführt. Stand Juli 2026 führt die LoRa Alliance die separate Relay-Spezifikation TS011-1.0.1 als aktuellen Stand. Die im September 2024 veröffentlichte Revision behebt kleinere Probleme bei MAC-Kommandos und präzisiert insbesondere Backoff- und Benachrichtigungsverhalten.

TS011 liegt auf dem bestehenden LoRaWAN Link Layer auf, wie ihn beispielsweise die L2-Spezifikation TS001-1.0.4 beschreibt, und ist laut Relay-Spezifikation mit den zum Veröffentlichungsstand vorhandenen LoRaWAN-Versionen nutzbar. Bei einer Beschaffung sollten daher zwei Angaben getrennt abgefragt werden: die unterstützte TS001-L2-Version und die implementierte TS011-Relay-Version. Eine Marketingangabe wie ‚LoRaWAN 1.1.1+‘ beschreibt diese Kombination nicht korrekt.

Welche Rolle das Relay im Netz übernimmt

Komponente	Funkrolle	Backendrolle	Stromprofil
normales Endgerät	sendet direkt zum Gateway	eigene LoRaWAN-Sitzung	meist lange Schlafphasen
Relay-fähiges Endgerät	sendet nach Wake-on-Radio über Relay	bleibt eigenes Endgerät	zusätzliche WOR-Sendeenergie
Relay	empfängt lokal und funkt weiter	besitzt eine eigene LoRaWAN-Sitzung	periodische Scans plus Forwarding
Gateway	empfängt Relay-Uplink und sendet Downlink	leitet Pakete zum Network Server	typisch dauerhaft versorgt
Network Server	keine direkte Funkhardware	plant und verarbeitet Relay-Verkehr	serverseitiger Dienst

Das Relay meldet sich selbst wie ein LoRaWAN-Endgerät im Netz an. Für weitergeleitete Daten nutzt es seine eigene Funkverbindung zum Gateway. Das entfernte Endgerät behält zugleich seine Identität und seinen Sicherheitskontext. Der Network Server muss beide Zusammenhänge verstehen, damit er den inneren Frame korrekt dem ursprünglichen Gerät zuordnet.

Ein LoRa-Gateway demoduliert viele Gerätekanäle und reicht Funkpakete über IP an den Network Server weiter. Ein Relay arbeitet wesentlich enger: Es ist selbst Teilnehmer im Funknetz, hat begrenzte Filter- und Weiterleitungskapazität und führt keinen allgemeinen Packet Forwarder aus. Diese Rollen sind nicht austauschbar.

Wake-on-Radio spart Dauerempfang

Ein batteriebetriebenes Relay kann nicht permanent auf jedes mögliche Endgerät hören. Stattdessen führt es periodisch kurze Channel-Activity-Detection-Scans aus. Ein entferntes Endgerät beginnt seine Übertragung mit einer Wake-on-Radio-Sequenz, kurz WOR. Die Sequenz ist so ausgelegt, dass das Relay während eines seiner Scanzeitpunkte Aktivität erkennt und für den folgenden Austausch vollständig aufwacht.

Nach einer gültigen WOR-Erkennung kann das Relay mit einem WOR ACK antworten. Das Endgerät sendet anschließend seinen normalen LoRaWAN-Uplink, den das Relay empfängt und über seine eigene Verbindung weiterleitet. Die Zeitplanung muss Scanintervall, WOR-Dauer und Uhrabweichung zusammenbringen. Eine längere Wecksequenz erhöht die Erkennungswahrscheinlichkeit, kostet dem Endgerät aber mehr Sendeenergie und Airtime.

Ein Uplink läuft in zwei Funkabschnitten

Das Endgerät wählt einen konfigurierten Relay-Kanal und sendet die Wake-on-Radio-Sequenz
das Relay erkennt die Aktivität in einem periodischen Scan und prüft die WOR-Nachricht
das Relay bestätigt die Bereitschaft mit WOR ACK, sofern der Austausch zulässig ist
das Endgerät überträgt seinen regulären LoRaWAN-Uplink an das Relay
das Relay kapselt die Weiterleitung in seiner eigenen LoRaWAN-Verbindung zum Gateway
der Network Server verarbeitet Relay-Hülle und ursprünglichen Endgeräteframe getrennt

Dieser doppelte Funkweg kostet mehr Zeit als ein direkter Uplink. Außerdem können beide Abschnitte unabhängig scheitern: Das Relay hört den WOR nicht, das Endgerät empfängt kein ACK, der lokale Uplink geht verloren oder der Relay-Uplink erreicht kein Gateway. Telemetrie sollte deshalb die Stufe des Fehlers erkennen lassen, statt nur einen fehlenden Messwert zu melden.

RXR bringt den Downlink zum Endgerät zurück

Ein weitergeleiteter Uplink erzeugt einen anderen Zeitablauf als der direkte Class-A-Weg. Das Relay muss zunächst selbst zum Gateway senden und einen möglichen Downlink des Network Servers empfangen. Für die Zustellung an das ursprüngliche Endgerät definiert TS011 deshalb ein zusätzliches RXR-Fenster. Das Endgerät hört zu dem vereinbarten Zeitpunkt auf die Rückübertragung des Relays.

RXR ist kein dauerhaft offener Empfangsmodus und macht aus Klasse A keine Klasse C. Es ist eine relaybezogene Empfangsgelegenheit, deren Timing zwischen den Beteiligten stimmen muss. Der Network Server muss den Downlink rechtzeitig über das Relay planen; das Relay braucht Funkzeit und Energie für die zweite Übertragung. Der Überblick zu LoRaWAN-Geräteklassen hilft bei der Abgrenzung zu RX1, RX2, Ping Slots und RXC.

Ein Relay-Weg fügt hinzu

Wake-on-Radio-Sendezeit am entfernten Endgerät

periodische Empfangsscans und Weiterleitungsenergie am Relay

einen zweiten LoRaWAN-Uplink vom Relay zum Gateway

zusätzliche Latenz und Zustandsverwaltung im Network Server

eine RXR-Übertragung für mögliche Downlinks zum Endgerät

Relay ist kein transparenter Repeater

Ein klassischer Repeater nimmt ein Funksignal auf und sendet es verstärkt oder zeitversetzt erneut. Das LoRaWAN Relay versteht dagegen definierte Protokollnachrichten, prüft Wake-on-Radio-Schutzinformationen, filtert Geräte und kapselt die Weiterleitung in eigenen LoRaWAN-Frames. Es arbeitet damit selektiv und zustandsbehaftet.

Diese Eigenschaft begrenzt unerwünschtes Weiterleiten und erlaubt einen batteriebetriebenen Betrieb. Sie bedeutet zugleich, dass vorhandene Endgeräte nicht allein durch Aufstellen eines Relays profitieren. Endgeräte-Firmware, Relay und Network Server müssen TS011 gemeinsam unterstützen und passend provisioniert sein.

Relay bildet kein beliebig tiefes Mesh

Die standardisierte Architektur behandelt einen Relay-Schritt zwischen Endgerät und Gateway beziehungsweise Network Server. Sie baut kein selbstorganisierendes Netz aus vielen hintereinander geschalteten Routern auf. Routenberechnung, beliebige Mehrfachsprünge und flächige Mesh-Heilung gehören nicht zum beschriebenen Modell.

Das ist für LoRaWAN sinnvoll, weil jeder zusätzliche Hop Airtime, Energie, Latenz und Fehlerzustände multipliziert. Benötigt ein Gelände mehrere gestaffelte Funkstationen, sind zusätzliche Gateways, eine andere Backhaul-Architektur oder eine speziell dafür entworfene Mesh-Technik meist besser planbar.

Wake-on-Radio hat einen eigenen Sicherheitskontext

Das Relay darf nicht auf jede beliebige Wecksequenz reagieren und damit seine Batterie entladen. TS011 definiert deshalb einen RootWorSKey und daraus abgeleitete Schlüssel für Integrität und Verschlüsselung der WOR-Kommunikation, darunter WorSIntKey und WorSEncKey. Diese Schlüssel ergänzen die normalen LoRaWAN-Sitzungsschlüssel; sie ersetzen sie nicht.

Provisionierung und Schlüsselwechsel müssen Endgerät, Relay-Konfiguration und Network Server konsistent halten. Werden dieselben WOR-Schlüssel unnötig breit geteilt, vergrößert sich die Auswirkung eines kompromittierten Geräts. Werden sie falsch zugeordnet, bleibt das Relay trotz guter Funkverbindung stumm. Schlüsselidentität und Gerätezulassung gehören deshalb in den Abnahmetest.

Filter und Backoff schützen die Relay-Ressourcen

Ein Relay besitzt begrenzte Zeit für Scans und Weiterleitungen. Die Spezifikation sieht Filter- beziehungsweise Forwarding-Regeln vor, damit nur vorgesehene Geräte bedient werden. Zusätzlich braucht das System Backoff und Grenzwerte, wenn zu viele Anfragen eintreffen oder der Funkweg zum Gateway belastet ist. Sonst kann eine kleine Zahl fehlerhafter Geräte das Relay dauerhaft wach halten.

Diese Steuerung ist ein Kapazitätsinstrument und eine Schutzmaßnahme. Sie sollte im Monitoring sichtbar sein: abgewiesene WOR-Anfragen, volle Listen, Backoff-Zustände, erfolgreiche Forwardings und Energiezustand des Relays. Ein fehlender Endgeräte-Uplink kann absichtlich gefiltert worden sein und muss dann anders behandelt werden als ein Funkverlust.

Zeitsynchronisation reduziert Weckenergie

Relay und Endgerät müssen ihre Hör- und Sendezeitpunkte hinreichend genau aufeinander beziehen. Je größer die Unsicherheit, desto länger muss die WOR-Sequenz sein oder desto häufiger muss das Relay scannen. Die LoRaWAN-Zeitsynchronisation erklärt, wie RTC-Drift, Netzwerkzeit und Synchronisationsintervalle zusammenwirken.

Das Application-Layer-Paket TS003-2.0.0 ist eine mögliche Quelle für eine anwendungsnahe Gerätezeit, aber die konkrete Relay-Synchronisierung folgt TS011. In der Firmware sollte eine gemeinsame RTC die Protokolle versorgen, während jede Funktion ihre eigene zulässige Abweichung und ihren letzten erfolgreichen Abgleich führt.

Die Position des Relays ist eine doppelte Funkplanung

Ein guter Standort muss zwei Links gleichzeitig tragen: kurze, zuverlässige WOR- und Endgerätekommunikation auf der einen Seite sowie ausreichende LoRaWAN-Verbindung zu mindestens einem Gateway auf der anderen. Der geometrische Mittelpunkt ist nicht automatisch optimal. Wände, Metall, Kellerdecken, Antennenhöhe und Versorgung verändern beide Linkbudgets unterschiedlich.

Der Standort sollte außerdem zugänglich genug für Batteriewechsel und Diagnose sein. Wird ein Relay zur einzigen Brücke für viele schwer erreichbare Sensoren, entsteht ein gemeinsamer Ausfallpunkt. Je kritischer die Daten, desto eher sind ein zweites Relay, zusätzliche Gatewayabdeckung oder ein lokaler Datenspeicher am Endgerät sinnvoll.

Problem	Relay	zusätzliches Gateway	anderer Ansatz
einzelner abgeschirmter Raum	oft passend	möglicherweise überdimensioniert	Antenne oder Standort prüfen
großes Gelände mit vielen Funklöchern	mehrere Relays erhöhen Komplexität	häufig besser skalierbar	private Netzverdichtung
kein IP-Backhaul am Zwischenpunkt	kann vorteilhaft sein	Backhaul muss geschaffen werden	Mobilfunk- oder Richtfunk-Backhaul
harte Echtzeit oder Schutzfunktion	nicht geeignet	LoRaWAN bleibt ohne harte Garantie	lokale sicherheitsgerichtete Technik
vorhandene Altgeräte ohne TS011	nicht direkt nutzbar	Geräte bleiben unverändert	Gateway oder Geräteaustausch

Airtime und Batterie werden an zwei Stellen verbraucht

Jeder weitergeleitete Uplink erzeugt zunächst WOR-Verkehr und anschließend einen Relay-Uplink. Ein Downlink erzeugt weitere Empfangs- und Sendephasen. Bei häufig meldenden Geräten kann das Relay dadurch wesentlich schneller altern als die Endgeräte. Seine Batteriekalkulation muss alle zugeordneten Geräte, Wiederholungen, Scanintervalle und den eigenen Statusverkehr enthalten.

Frequenzen, Datenraten, Sendeleistung und regulatorische Grenzen richten sich auf beiden Funkabschnitten nach der eingesetzten Region. Die aktuelle Regional-Parameters-Spezifikation RP002-1.0.5 ist deshalb Teil der Planung. Ein Relay kann die zulässige Funkzeit weder vervielfachen noch regionale Kanalregeln umgehen.

Eine langsame Datenrate zum Gateway verlängert die Sendezeit des Relays. ADR kann den äußeren LoRaWAN-Link optimieren, ändert aber nicht die lokale WOR-Last. Auch LR-FHSS ist kein allgemeiner Relay-Turbo; Unterstützung, Richtung und regionales Profil müssen für jeden Abschnitt getrennt betrachtet werden.

Monitoring muss beide Geräteidentitäten zeigen

letzter direkter und letzter weitergeleiteter Uplink des Endgeräts
erkanntes WOR, gesendetes WOR ACK und empfangener Endgeräteframe
erfolgreicher Relay-Uplink sowie beteiligte Gateways
RXR-Downlinks, Zustellversuche und Antwort des Endgeräts
Filter-, Kapazitäts- und Backoff-Ereignisse
Batterie, Temperatur, Neustarts und Zeitsynchronisationsqualität des Relays

Der LoRaWAN MAC Layer und Frame-Aufbau bleibt für den ursprünglichen Geräteframe relevant. Zusätzlich muss das Backend die Relay-Kapselung und deren Zustände darstellen. Eine Oberfläche, die nur den inneren Messwert zeigt, verbirgt genau die Information, die bei einem gestörten Relay-Pfad gebraucht wird.

Abnahmetest vom WOR bis zum RXR

TS001-, TS011- und Regional-Parameter-Versionen aller Komponenten dokumentieren
direkten und weitergeleiteten Funkweg am Zielstandort getrennt vermessen
WOR-Erkennung, WOR ACK und Uplink mit Uhrdrift sowie Paketverlust testen
RXR-Downlinks bei verschiedenen Datenraten und Gatewaylatenzen prüfen
unzulässige Geräte, volle Filter und Backoff absichtlich auslösen
Relay-Ausfall, Batteriewarnung und Rückkehr auf direkten Empfang simulieren
Energieverbrauch mit der maximal geplanten Geräte- und Nachrichtenlast messen

Der Test sollte außerdem prüfen, ob ein Endgerät einen direkten Gatewaypfad bevorzugen oder nach Ausfall des Relays wiederfinden kann, sofern die Implementierung dies vorsieht. Ein Standortwechsel des Relays, ein Network-Server-Neustart und verlorene Schlüsselzustände gehören ebenfalls in den Lebenszyklus.

Wann Relay die richtige Wahl ist

Relay ist überzeugend, wenn wenige klar abgegrenzte Funklöcher bestehen, am Zwischenpunkt kein IP-Backhaul verfügbar ist und Endgeräte, Relay sowie Server TS011 gemeinsam unterstützen. Es kann dann mit geringem Infrastrukturaufwand eine Verbindung herstellen, die durch eine Wand, einen Schacht oder eine ungünstige Geländekante unterbrochen wird.

Bei großen Flächen, vielen kritischen Geräten oder hohem Datenverkehr ist ein zusätzliches Gateway oft transparenter und leistungsfähiger. Die Entscheidung sollte daher nicht aus einer Reichweitenzahl entstehen, sondern aus zwei vermessenen Funklinks, einer Lastrechnung und einem Ausfallkonzept. Dann wird Relay zu einem präzisen Werkzeug statt zu einer unsichtbaren Zusatzabhängigkeit.

Häufige Fragen

Gehört Relay zu LoRaWAN 1.1.1?

Nein. Stand Juli 2026 ist TS011-1.0.1 die separate aktuelle Relay-Spezifikation. Sie baut als Zusatz auf bestehenden LoRaWAN-L2-Versionen auf.

Ist ein LoRaWAN Relay dasselbe wie ein Funkrepeater?

Nein. Das Relay verarbeitet definierte Wake-on-Radio- und Weiterleitungsabläufe, besitzt eine eigene LoRaWAN-Sitzung und filtert zugelassene Endgeräte.

Können vorhandene LoRaWAN-Sensoren automatisch ein Relay nutzen?

Nur wenn Endgeräte-Firmware, Relay und Network Server TS011 unterstützen und passend provisioniert sind. Das Aufstellen eines Relays allein genügt nicht.

Was bedeutet RXR bei LoRaWAN Relay?

RXR ist ein zusätzliches, relaybezogenes Empfangsfenster, in dem das Endgerät einen vom Relay zurückgesendeten Downlink empfangen kann.

Ersetzt ein Relay ein LoRaWAN-Gateway?

Nein. Ein Relay leitet begrenzten Geräteverkehr über seine eigene Funkverbindung weiter. Ein Gateway empfängt viele Kanäle und verbindet das Funknetz über einen Backhaul mit dem Network Server.