LoRaWAN ADR-Algorithmus: Mechanismus, LinkADRReq und Reichweiten-Backoff

Adaptive Data Rate, kurz ADR, soll LoRaWAN-Geräte mit einer möglichst passenden Datenrate, Sendeleistung und Wiederholungszahl betreiben. Ein guter Funkpfad erlaubt kürzere Airtime und häufig weniger Sendeenergie; ein schwächerer Pfad braucht mehr Link Budget. Der Begriff ADR-Algorithmus klingt allerdings eindeutiger, als der Standard tatsächlich ist.

Die LoRaWAN-Spezifikation definiert Signalisierung, MAC-Kommandos, Bestätigungen und den Sicherheits-Backoff des Endgeräts. Wie ein Network Server aus empfangenen Paketen die optimale Zielkonfiguration berechnet, bleibt dem Hersteller überlassen. Zwei Server können daher mit denselben Messdaten zu unterschiedlichen, dennoch standardkonformen Entscheidungen kommen.

Technischer Kern: Der Network Server beobachtet Uplinks und sendet bei Bedarf LinkADRReq. Das Endgerät bestätigt mit LinkADRAns. Bleiben Downlinks über längere Zeit aus, setzt das Gerät ADRACKReq und baut seine Funkkonfiguration schrittweise in Richtung höherer Reichweite zurück. Netzwerkoptimierung und Geräte-Backoff sind zwei Seiten desselben Regelkreises.

Was der Standard festlegt und was nicht

Die LoRaWAN-L2-Spezifikation 1.0.4 beschreibt ADR als Möglichkeit, Datenrate, maximale TX-Leistung, Kanalmaske und NbTrans gerätespezifisch zu steuern. Sie legt aber keinen verbindlichen Network-Server-Algorithmus mit festem SNR-Fenster oder einer bestimmten Mittelwertbildung fest. Solche Details gehören zur jeweiligen Implementierung.

Normativ ist dagegen, welche Felder LinkADRReq enthält, wie das Gerät antwortet und wie es bei ausbleibenden Downlinks reagiert. Diese Trennung ist sinnvoll: Der Standard sichert Interoperabilität, während Betreiber Algorithmen an Netzgröße, Region, Mobilität und gewünschte Reserve anpassen können. Sie erschwert aber pauschale Aussagen wie ADR braucht genau zwanzig Pakete.

Ebene	Standardisiert	Implementierungsspezifisch
Endgerät	ADR-Bit, ADRACKReq, LinkADRAns, Backoff	wann die Anwendung ADR aktiviert
Network Server	LinkADRReq-Format und zulässige Werte	Messfenster, SNR-Auswahl, Sicherheitsmarge
Region	Datenraten, TXPower-Indizes, Kanalregeln	betriebliche Zielreserve
Betrieb	Protokollzustände	Alarmierung, Dashboards und Änderungsfreigabe

Warum höhere Datenrate oft besser für das Netz ist

Eine höhere LoRaWAN-Datenrate bedeutet in LoRa-basierten Regionen häufig einen niedrigeren Spreading Factor und damit kürzere Sendezeit. Das Endgerät benötigt weniger Energie pro Uplink, und der Funkkanal wird kürzer belegt. Gleichzeitig sinkt das Link Budget. ADR versucht deshalb, genügend Reserve zu behalten, ohne jedes Gerät vorsorglich mit der langsamsten Datenrate senden zu lassen.

Datenraten sind regionale Indizes, keine weltweit identischen Spreading-Factor-Bezeichnungen. RP002 kann einem DR-Wert je nach Region LoRa, FSK oder LR-FHSS und unterschiedliche Bandbreiten zuordnen. Die Regional Parameters RP002-1.0.5 müssen daher zum L2-Stack und zum Einsatzland passen.

Welche Beobachtungen der Network Server nutzen kann

Gateways melden zu einem Uplink unter anderem RSSI, SNR, Kanal, Datenrate und Empfangszeit. Weil mehrere Gateways dasselbe Paket empfangen können, erhält der Server zusätzlich Informationen über räumliche Empfangsvielfalt. Ein ADR-Algorithmus kann daraus eine Link-Margin gegenüber der für die aktuelle Datenrate nötigen Demodulationsgrenze schätzen.

Ob er den besten SNR-Wert, einen Mittelwert, ein Perzentil oder eine zeitlich gewichtete Historie verwendet, ist nicht vorgegeben. Ein Maximum reagiert schnell auf gute Bedingungen, kann aber eine zufällige Spitze überbewerten. Ein konservativeres Fenster reagiert langsamer, schützt dafür besser gegen Fading und saisonale Änderungen. Die gewählte Strategie gehört in die Betriebsdokumentation.

Das ADR-Bit im Uplink

Setzt das Endgerät das ADR-Bit im FCtrl, erlaubt es dem Network Server, Datenrate, TXPower und NbTrans über geeignete MAC-Kommandos zu steuern. In 1.0.4 informiert das ADR-Bit im Downlink umgekehrt darüber, ob der Server derzeit ADR-Kommandos liefern kann. Das Gerät darf seine Uplink-Entscheidung davon abhängig machen.

Bei schnell und dauerhaft wechselnder Dämpfung kann eine zentrale Optimierung zu spät reagieren. Die Spezifikation nennt das Abschalten des Uplink-ADR-Bits als typische Strategie für mobile Geräte. Stationäre Geräte können es gesetzt lassen und bei fehlenden Downlinks den standardisierten Backoff verwenden. Mobil ist aber kein dauerhafter Gerätezustand: Ein Tracker kann lange stehen und nur phasenweise fahren.

LinkADRReq: vier Stellgrößen in einem Kommando

Ein LinkADRReq enthält DataRate, TXPower, ChMask und das Redundancy-Feld mit ChMaskCntl und NbTrans. DataRate und TXPower sind codierte, regional interpretierte Werte. Die Kanalmaske schaltet zulässige Uplink-Kanäle ein oder aus; ChMaskCntl bestimmt, auf welchen Kanalblock oder welche besondere regionale Regel sie sich bezieht. NbTrans steuert, wie oft ein Uplink-Frame übertragen wird.

Der Network Server kann mehrere zusammenhängende LinkADRReq in einem Downlink senden, etwa um große Kanalpläne zu konfigurieren. Das Gerät verarbeitet die Kanalmasken als atomaren Block und verwendet DataRate, TXPower und NbTrans aus dem letzten Kommando. Teilweise übernommene Kanalblöcke würden sonst einen schwer nachvollziehbaren Zwischenzustand erzeugen.

LinkADRReq verändert

DataRate: regional definierter Modus für den nächsten Uplink

TXPower: maximal erlaubte, codierte Sendeleistung

ChMask und ChMaskCntl: nutzbare Uplink-Kanäle

NbTrans: Anzahl der Übertragungen desselben Uplink-Frames

LinkADRAns: drei Prüfbits statt eines pauschalen OK

Das Gerät antwortet mit LinkADRAns. Die Statusbits PowerACK, DataRateACK und ChannelMaskACK zeigen, ob Leistung, Datenrate und Kanalmaske akzeptiert wurden. Bei gesetztem ADR-Bit gilt die Konfiguration als zusammenhängende Entscheidung. Ein abgelehnter Teil ist deshalb kein harmloser Detailfehler; Server und Gerät dürfen nicht mit unterschiedlichen Annahmen weiterarbeiten.

In der Flottenansicht sollten ausstehende oder negative LinkADRAns sichtbar sein. Wiederholt dasselbe Kommando zu senden, ohne die Ursache zu untersuchen, verbraucht Downlinks. Häufige Gründe sind ein falsches Regionalprofil, nicht unterstützte Datenraten, unzulässige Leistung oder eine Kanalmaske, die keinen gültigen Kanal übrig lässt.

ADRACKReq prüft die Rückrichtung

Ein Gerät kann Uplinks erfolgreich senden, obwohl es lange keinen Downlink mehr empfängt. Hat das Netzwerk zuvor eine schnellere Datenrate, niedrigere Leistung oder eingeschränkte Kanalmaske gesetzt, muss das Gerät deshalb regelmäßig prüfen, ob die Rückrichtung noch funktioniert. Dazu zählt es neue Uplink-Frames im ADRACKCnt. Wiederholungen desselben Frames erhöhen diesen Zähler nicht.

Nach ADR_ACK_LIMIT Uplinks ohne Class-A-Downlink setzt das Gerät ADRACKReq. Der Network Server muss innerhalb der folgenden ADR_ACK_DELAY Uplinks mit einem Class-A-Downlink reagieren. Es ist kein besonderes ACK-Bit nötig: Jeder gültige Class-A-Downlink nach einem Uplink beweist, dass die bidirektionale Verbindung besteht und setzt den Zähler zurück.

Der Geräte-Backoff bei ausbleibendem Downlink

Bleibt die Antwort aus, geht das Endgerät schrittweise zu einer robusteren Konfiguration zurück. LoRaWAN 1.0.4 setzt zunächst die TX-Leistung auf den regional und geräteseitig zulässigen Default, senkt anschließend in Abständen von ADR_ACK_DELAY die Datenrate und aktiviert am Ende wieder die Default-Kanäle. NbTrans wird dabei auf eins zurückgesetzt.

Das Beispiel in der 1.0.4-Spezifikation verwendet ADR_ACK_LIMIT 64 und ADR_ACK_DELAY 32. Das sind Uplink-Zählwerte, keine Sekunden. Bei einem Uplink pro Minute beginnt die Reaktion viel früher als bei einem täglichen Uplink. Die LoRaWAN-Spezifikation 1.1 ergänzt ADRParamSetupReq, mit dem der Server beide Parameter als Zweierpotenzen konfigurieren kann. Der Versionsvergleich 1.0.x und 1.1 ordnet diese Unterschiede ein.

ADRACKReq ist kein LinkCheckReq

ADRACKReq ist ein Bit im normalen Uplink und Teil des automatischen Rückfallmechanismus. LinkCheckReq ist dagegen ein eigenes MAC-Kommando, auf das der Server mit LinkCheckAns und einer geschätzten Link Margin sowie Gateway-Anzahl antwortet. Beide betreffen Konnektivität, dienen aber unterschiedlichen Zustandsmaschinen.

Ein Gerät sollte nicht ständig LinkCheckReq senden, um ein Dashboard mit Funkwerten zu füllen. Das erzeugt Downlinkbedarf und kann ADR stören. Für die laufende Netzbeobachtung sind serverseitig gemessene RSSI-, SNR-, Gateway- und Erfolgsdaten meist geeigneter.

NbTrans ist kein kostenloser Zuverlässigkeitsregler

NbTrans kann unbestätigte und bestätigte Uplinks mehrfach übertragen. Das erhöht die Chance, dass mindestens eine Kopie ankommt, belegt aber entsprechend mehr Airtime und Energie. Der Network Server dedupliziert die Kopien und darf sie nicht mehrfach an die Anwendung ausliefern.

Viele Wiederholungen können eine überlastete Zelle weiter belasten. ADR muss daher Link Margin, Datenrate und Redundanz gemeinsam betrachten. Ein zusätzlicher Gateway-Empfangspfad oder eine bessere Antennenposition ist oft wirksamer als ein dauerhaft erhöhtes NbTrans.

Warum bestätigte Uplinks ADR nicht ersetzen

Confirmed Uplinks fordern eine Bestätigung für einen konkreten Frame. ADRACKReq prüft dagegen nach längerer Zeit, ob die Rückrichtung einer optimierten Verbindung noch besteht. Jeden Messwert bestätigt zu senden, um ADR zu unterstützen, ist unnötig und belastet das Downlinkbudget.

Bestätigungen sollten für fachlich wichtige Einzelereignisse oder kontrollierte Stichproben reserviert bleiben. Der Geräteklasse kommt dabei eine eigene Rolle zu: In Klasse A, B und C unterscheiden sich die möglichen Downlinkzeitpunkte, nicht jedoch die grundsätzliche Notwendigkeit eines sparsamen Downlinkplans.

Ein nachvollziehbares ADR-Beispiel

Ein stationärer Sensor sendet zunächst mit regionalem Default und gesetztem ADR-Bit.
Mehrere Gateways empfangen seine Uplinks mit stabiler Reserve.
Der Network Server wählt eine höhere Datenrate und gegebenenfalls geringere TXPower.
Er sendet LinkADRReq; das Gerät prüft alle Felder und antwortet mit LinkADRAns.
Nach erfolgreicher Bestätigung sendet das Gerät mit kürzerer Airtime.
Verschlechtert sich der Pfad und bleiben Downlinks aus, setzt es ADRACKReq.
Ohne Antwort baut es Leistung, Datenrate, Kanalmaske und NbTrans nach Spezifikation zurück.

Dieses Beispiel erklärt den Regelkreis, nicht den internen Serveralgorithmus. Wie viele Uplinks der Server abwartet und welche Reserve er ansetzt, bleibt produktspezifisch. Gerade deshalb sollten Betreiber Algorithmusversion und Parameteränderungen protokollieren.

ADR für mobile und wechselnde Umgebungen

Bei Fahrzeugen, Containern oder Personen-Trackern kann die Funklage zwischen zwei Uplinks stark wechseln. Ein Wert aus dem Hafenkran ist keine zuverlässige Basis für den nächsten Uplink im Schiffsrumpf. Dauerhaft aggressives ADR kann dann zu kurzen, aber verlorenen Frames führen.

Mögliche Strategien sind ein ausgeschaltetes ADR während Bewegung, konservative Serverreserven, eine langsamere Anpassung oder ein anwendungsgesteuerter Wechsel nach erkanntem Stillstand. Das Gerät muss seine Datenrate trotzdem regional zulässig wählen und die Airtime minimieren. Eine pauschale Regel ADR bei Mobilität immer aus greift zu kurz.

Kennzahlen für den ADR-Betrieb

Im Dashboard gehören zusammen

aktuelle Datenrate, TXPower-Index, NbTrans und Kanalmaske

SNR- und RSSI-Verteilung je Gateway statt nur letzter Einzelwert

Anteil erfolgreicher LinkADRReq und Gründe negativer LinkADRAns

ADRACKReq-Häufigkeit und ausgelöste Backoff-Stufen

Airtime pro Gerät und Datenrate sowie Uplink-Verluste

Algorithmus- und Gerätefirmwareversion für reproduzierbare Änderungen

Änderungen am ADR-Algorithmus sollten wie eine Netzkonfiguration behandelt werden. Vor und nach dem Rollout werden Datenratenverteilung, Paketverluste, Airtime und Batterieverbrauch verglichen. Eine vermeintliche Optimierung, die nur mehr Geräte auf eine schnelle Datenrate setzt, aber die Zahl verlorener Ereignisse erhöht, hat ihr Ziel verfehlt.

ADR sauber testen

Ein Labortest dämpft den Funkpfad kontrolliert, prüft jede LinkADRReq-Kombination und verifiziert LinkADRAns. Danach folgen längere Feldphasen mit wechselnden Wetter-, Montage- und Lastzuständen. Downlink-Ausfall, Gateway-Ausfall, Neustart und Counter-Persistenz gehören ebenso dazu wie der ideale gute Funkpfad.

Die Frameanalyse aus dem Beitrag zum LoRaWAN MAC Layer hilft dabei, ADR-Bit, ADRACKReq, FOpts und MAC-Kommandos im Mitschnitt auseinanderzuhalten. Erst wenn Protokollzustand, Funkmessung und Serverentscheidung zusammenpassen, lässt sich ein vermeintlicher ADR-Fehler belastbar erklären.

Häufige Fragen

Ist der LoRaWAN-ADR-Algorithmus vollständig standardisiert?

Nein. Der Standard definiert die MAC-Kommandos, Antworten und den Geräte-Backoff. Wie der Network Server aus Messwerten eine Zielkonfiguration berechnet, ist implementierungsspezifisch.

Was verändert LinkADRReq?

Das Kommando kann Datenrate, maximal verwendete Sendeleistung, Kanalmaske und NbTrans einstellen. Die Codierung muss nach dem jeweiligen Regional-Parameters-Profil interpretiert werden.

Was bedeutet ADRACKReq?

Das Bit signalisiert nach längerer Zeit ohne Class-A-Downlink, dass das Gerät eine Rückmeldung zur Konnektivität benötigt. Bleibt sie aus, geht das Gerät schrittweise zu einer robusteren Funkkonfiguration zurück.

Sollte ADR bei mobilen Geräten deaktiviert werden?

Oft ist eine vorsichtige oder phasenweise Strategie sinnvoll, weil sich die Funklage schnell ändert. Eine pauschale Entscheidung ist jedoch nicht nötig; Bewegung, Uplinkintervall und Serveralgorithmus müssen gemeinsam betrachtet werden.

Verbessert ein höheres NbTrans immer die Zuverlässigkeit?

Nein. Wiederholungen können die Empfangschance erhöhen, verbrauchen aber mehr Energie und Airtime. In belasteten Netzen können sie zusätzliche Kollisionen verursachen.