LoRaWAN Adaptive Data Rate

Adaptive Data Rate (ADR) ist ein Mechanismus zur Optimierung von Datenraten, Sendezeit und Energieverbrauch im Netzwerk. ADR sollte immer dann aktiviert werden, wenn ein Endgerät ausreichend stabile HF-Bedingungen aufweist. Dies bedeutet, dass es generell für statische Geräte aktiviert werden kann. Wenn das statische Endgerät feststellen kann, dass die RF-Bedingungen instabil sind (z. B. wenn ein Auto auf einem Parksensor geparkt ist), sollte die ADR (vorübergehend) deaktiviert werden. Mobile Endgeräte sollten erkennen können, wenn sie längere Zeit stillstehen, und in diesen Zeiten ADR aktivieren. Endgeräte entscheiden, ob ADR verwendet werden soll oder nicht, nicht die Anwendung oder das Netzwerk. Um die optimale Datenrate zu ermitteln, benötigt das Netzwerk einige Messungen (Uplink-Meldungen). Derzeit nimmt TTN die letzten 20 Uplinks in Anspruch, beginnend mit dem Setzen des ADR-Bits. Diese Messungen enthalten den Frame-Zähler, das Signal-Rausch-Verhältnis (SNR) und die Anzahl der Gateways, die jede Aufwärtsverbindung empfangen haben. Wenn ein Gerät das ADR-Bit deaktiviert (weil es weiß, dass es sich bewegt oder dass die HF-Bedingungen instabil sind), werden vorherige Messungen verworfen. Sobald das ADR-Bit wieder gesetzt ist, beginnt das Netzwerk erneut mit der Messung.

Um die optimale Datenrate zu ermitteln, benötigt das Netzwerk einige Messungen (Uplink-Meldungen). Derzeit nimmt TTN die letzten 20 Uplinks in Anspruch, beginnend mit dem Setzen des ADR-Bits. Diese Messungen enthalten den Frame-Zähler, das Signal-Rausch-Verhältnis (SNR) und die Anzahl der Gateways, die jede Aufwärtsverbindung empfangen haben. Wenn ein Gerät das ADR-Bit deaktiviert (weil es weiß, dass es sich bewegt oder dass die HF-Bedingungen instabil sind), werden vorherige Messungen verworfen. Sobald das ADR-Bit wieder gesetzt ist, beginnt das Netzwerk erneut mit der Messung.

Für jede dieser Messungen nehmen wir das SNR des besten Gateways und berechnen die sogenannte "Marge", die das gemessene SNR abzüglich des erforderlichen SNR zum Demodulieren einer Nachricht bei gegebener Datenrate ist. Diese Spanne wird verwendet, um zu bestimmen, um wie viel die Datenrate erhöht oder die Sendeleistung verringert werden kann. Wenn das Netzwerk beispielsweise eine Nachricht mit der Datenrate SF12BW125 und SNR 5.0 empfängt, hat diese Nachricht einen Spielraum von 25 dB. Dies ist eine Verschwendung von wertvoller Sendezeit und Energie. Wenn wir die Datenrate auf SF7BW125 erhöhen würden, hätten wir immer noch einen Spielraum von 12,5 dB, aber das wäre um ein Vielfaches luft- und energieeffizienter. Wir könnten die Sendeleistung sogar senken, um noch mehr Energie zu sparen und weniger Störungen zu verursachen.

Es gibt mehrere Momente, in denen eine ADR-Anfrage geplant oder gesendet wird:

1. Die anfängliche ADR-Anforderung (für US915 und AU915). Diese wird unmittelbar nach dem Beitritt gesendet und dient hauptsächlich zum Einstellen der Kanalmaske des Geräts. Dies ist etwas schwierig, da wir nicht genügend Messungen haben, um eine genaue Datenrate einzustellen. Um zu vermeiden, dass das Gerät stummgeschaltet wird, verwenden wir hier einen zusätzlichen „Puffer“ von einigen dB. Diese Anforderung wird nur mit LoRaWAN 1.1 auf unserem v2-Stack benötigt. Mit LoRaWAN 1.1-Geräten auf unserem v3-Stack können wir die Kanalmaske in der JoinAccept-Nachricht festlegen. ABP-Geräte vor LoRaWAN 1.1 erhalten diese Nachricht nur einmal. Wenn sie danach zurückgesetzt werden, erhalten sie die Nachricht nicht mehr. Dieses Problem wird auch durch LoRaWAN 1.1 behoben.
2. Eine regelmäßige ADR-Anforderung ist geplant, wenn genügend Messungen vorliegen und die aktuelle Datenrate nicht optimal ist. Die Anforderung ist nur geplant und wird an einen vorhandenen Anwendungs-Downlink (z. B. eine ACK- oder Downlink-Payload) angehängt.
3. Eine ADR-Anfrage wird gesendet, wenn genügend Messungen vorliegen und das Gerät DR0 verwendet (SF12BW125 in den meisten Regionen).
4. Eine ADR-Anfrage wird gesendet, wenn das Gerät das ADRAckReq-Bit setzt. Standardmäßig geschieht dies nach dem Senden von 64 Uplinks, ohne dass ein Downlink empfangen wird. Da dies jedoch von der Geräteimplementierung abhängt, können wir Ihnen hier keine genaue Nummer geben.

ADR-Anfragen werden nicht mehr geplant oder gesendet, wenn das Gerät mehrere ADR-Anfragen abgelehnt hat. Dies kann entweder eine fehlerhafte Implementierung des Geräts oder einen Versionskonflikt zwischen dem Gerät und dem Server bedeuten.

Der in The Things Network verwendete Algorithmus basiert auf dem von Semtech empfohlenen Algorithmus zur Ratenanpassung. Das folgende Diagramm zeigt den ADR-Fluss, wie er im NetworkServer von The Things Network implementiert ist: