Der Netzwerkserver verwaltet die Funkeinstellungen jedes Geräts mit MAC-Befehlen: kurzen Anweisungen, die in Downlinks mitfahren, und Antworten, die in Uplinks mitfahren. Der wichtigste ist die adaptive Datenrate (ADR). Diese Seite erklärt, was der Netzwerkserver von sich aus tut und wie Sie ihn über das Profil beeinflussen können.
Adaptive Datenrate (ADR)
Ein Gerät in der Nähe eines Gateways braucht nicht die langsamste Datenrate mit der größten Reichweite. ADR setzt es auf eine schnellere Datenrate und eine geringere Sendeleistung, was Batterie und Sendezeit spart und Platz für andere Geräte lässt.
ADR läuft, wenn beide Bedingungen erfüllt sind:
- Adaptive Datenrate (ADR) ist im Profil des Geräts eingeschaltet (standardmäßig eingeschaltet).
- Das Gerät selbst fordert ADR in seinen Uplinks an (die meisten Geräte tun das).
So wird eine Änderung entschieden
- Für jeden Uplink merkt sich der Netzwerkserver den besten SNR unter allen Gateways, die ihn empfangen haben.
- Sobald er 20 Uplinks hat, nimmt er den besten SNR dieser 20.
- Marge = dieser SNR − der SNR, den die aktuelle Datenrate benötigt − die Installationsmarge (standardmäßig 10 dB, API-Einstellung
installationMarginDb, 0–30). - Jede volle 3 dB Marge ergibt einen Schritt. Schritte erhöhen zuerst die Datenrate bis zur höchsten Datenrate (DR) des Profils; verbleibende Schritte senken die Sendeleistung um je 2 dB.
- Der Netzwerkserver erhöht nie die Leistung eines Geräts und senkt seine Datenrate nie unter den bisherigen Wert.
- Die Änderung wird als LinkADRReq gesendet. Akzeptiert das Gerät sie, beginnt der Verlauf von vorn, und für die nächsten 20 Uplinks wird keine neue Änderung vorgenommen.
Wird eine Änderung akzeptiert, werden die Attribute des Geräts lora.dr und lora.txPower aktualisiert.
Profileinstellungen
| Feld | Standard | Wirkung |
|---|---|---|
| Adaptive Datenrate (ADR) | Ein | Aus: Der Netzwerkserver sendet nie ADR-Änderungen. |
| Niedrigste Datenrate (DR) | DR0 | Die Untergrenze, die ADR einhält. |
| Höchste Datenrate (DR) | DR5 | Die Obergrenze, auf die ADR Geräte setzt. |
Schalten Sie ADR für Geräte aus, die sich bewegen (Tracker): Ihr Signal ändert sich schneller als 20 Uplinks.
Weitere Aufgaben, die der Netzwerkserver von sich aus übernimmt
| Aktion | Wann |
|---|---|
| Setzt die RX1-Verzögerung (RXTimingSetupReq) | Wenn die RX1-Verzögerung des Geräts von der des Profils abweicht, zum Beispiel bei einem ABP-Gerät, das mit 1 s startet. Wird wiederholt, bis das Gerät bestätigt. |
| Setzt RX1-Offset und RX2 (RXParamSetupReq) | Wenn die Werte des Geräts von denen des Profils abweichen. |
| Fragt Batterie und Link-Marge ab (DevStatusReq) | Nach jedem Join und danach alle 24 Stunden (API-Einstellung devStatusIntervalH, 0 = nie). |
| Setzt eine aggregierte Duty-Cycle-Grenze (DutyCycleReq) | Nur wenn die API-Einstellung maxDutyCycle größer als 0 ist. |
| Beantwortet Link-Prüfungen (LinkCheckAns) | Wenn das Gerät fragt; teilt ihm die Marge und die Anzahl der empfangenden Gateways mit. |
| Beantwortet Zeitanfragen (DeviceTimeAns) | Wenn das Gerät die Netzwerkzeit anfordert. |
Batterie und Marge des Geräts kommen als Telemetrie mit der nächsten Nachricht an, wenn Funkwerte hinzufügen eingeschaltet ist: lora.battery_level (0–100 %, fehlt bei extern versorgten Geräten oder wenn unbekannt) und lora.margin_db (die vom Gerät gemessene Link-Marge, −32 bis 31 dB).
So werden MAC-Befehle zugestellt
- Antworten kommen zuerst, dann wartende Anfragen, im Header des Downlinks (bis zu 15 Byte). Wenn mehr wartet, als hineinpasst, gehen die Befehle stattdessen auf FPort 0, und Ihr Anwendungs-Downlink wartet auf das nächste Fenster.
- Eine wartende Anfrage wird bei jedem Downlink erneut gesendet, bis das Gerät antwortet, höchstens 3-mal, danach verworfen.
- Der Netzwerkserver beantwortet einen Uplink auch ohne Anwendungsdaten, wenn eine MAC-Antwort fällig ist oder das Gerät eine Bestätigung seiner ADR-Anforderung (ADRACKReq) verlangt.
- MAC-Befehle blockieren einen Anwendungs-Downlink nie lange: Passen beide hinein, gehen beide raus.
Unterstützte MAC-Befehle (LoRaWAN 1.0.x)
| Befehl | Richtung | Unterstützt |
|---|---|---|
| LinkCheckReq / LinkCheckAns | Gerät fragt, Netzwerk antwortet | Ja |
| LinkADRReq / LinkADRAns | Netzwerk fragt, Gerät antwortet | Ja |
| DutyCycleReq / DutyCycleAns | Netzwerk fragt | Ja (nur wenn maxDutyCycle > 0) |
| RXParamSetupReq / RXParamSetupAns | Netzwerk fragt | Ja |
| DevStatusReq / DevStatusAns | Netzwerk fragt | Ja |
| NewChannelReq / NewChannelAns | Netzwerk fragt | Antworten werden verstanden |
| RXTimingSetupReq / RXTimingSetupAns | Netzwerk fragt | Ja |
| DlChannelReq / DlChannelAns | Netzwerk fragt | Antworten werden verstanden |
| DeviceTimeReq / DeviceTimeAns | Gerät fragt, Netzwerk antwortet | Ja |
| TxParamSetupReq | Netzwerk fragt | In EU868 nicht verwendet |
| Klasse-B-Befehle (PingSlot, Beacon) | — | Nicht unterstützt |
| LoRaWAN-1.1-Befehle (Rekey, Rejoin, ResetInd) | — | Nicht unterstützt |
Ein unbekannter Befehl in einem Uplink stoppt das Lesen der übrigen MAC-Befehle dieses Uplinks, wie es die LoRaWAN-Spezifikation vorschreibt.