Ein OTAA-Gerät muss sich per Join anmelden, bevor der Network Server seine Daten annimmt. Diese Seite verfolgt einen Join-Request durch alle Prüfungen, damit Sie anhand des Join-Status oder des Frames-Logs erkennen können, an welcher Stelle ein fehlgeschlagener Join abbricht.
Die Schritte
- Das Gerät sendet einen Join-Request. Er enthält die JoinEUI, die DevEUI, eine DevNonce (eine Zahl, die das Gerät selbst wählt) und einen Integritätscode (MIC), der mit dem AppKey berechnet wird.
- Gateways leiten ihn weiter. Kopien von mehreren Gateways werden wie bei jedem Uplink zusammengeführt.
- Die DevEUI wird nachgeschlagen. Der Network Server sucht die DevEUI im plattformweiten Verzeichnis.
- Nirgends registriert: Wenn eines Ihrer Profile im Pairing-Modus ist und der Request zu dessen gemeinsamem AppKey passt, übernimmt das Pairing (siehe Pairing-Modus). Andernfalls wird der Request als Unbekannte DevEUI verworfen.
- In einer anderen Organisation registriert: wird als Ein Gerät eines anderen Netzwerks verworfen. Weitere Informationen dazu erhalten Sie nicht.
- Der Gerätedatensatz wird geprüft.
- Ein ABP-Gerät, das einen Join-Request sendet, wird abgelehnt (ABP-Gerät hat einen Join-Request gesendet).
- Ein Gerät, das vom Pairing-Modus zurückgehalten wird, wird abgelehnt (Wartet auf Freigabe).
- Ein Gerät ohne Schlüssel wird abgelehnt (Kein AppKey gespeichert).
- Die JoinEUI wird verglichen mit der gespeicherten, sofern das Gerät nicht jede JoinEUI akzeptiert. Eine abweichende wird abgelehnt (Join abgelehnt: andere JoinEUI).
- Der Integritätscode wird geprüft mit dem AppKey (dem eigenen des Geräts oder dem gemeinsamen Schlüssel des Profils bei per Pairing hinzugefügten Geräten). Eine Abweichung wird abgelehnt (Join abgelehnt: falscher AppKey?).
- Die DevNonce wird geprüft (siehe unten). Eine wiederverwendete wird abgelehnt (Join abgelehnt: DevNonce wurde schon verwendet).
- Eine Session wird angelegt. Der Network Server wählt in seinem Netzwerk eine freie Geräteadresse (DevAddr), leitet die beiden Session-Schlüssel ab und speichert sie verschlüsselt. Die neue Session bleibt ausstehend, bis der erste Uplink des Geräts eintrifft.
- Der Join-Accept wird gesendet. Er läuft über das beste Gateway, das das Gerät noch erreichen kann: 5 Sekunden nach dem Request (RX1, gleicher Kanal) oder 6 Sekunden danach (RX2, 869,525 MHz, DR0). Der Accept teilt dem Gerät seine Adresse, die RX1-Verzögerung seines Profils (standardmäßig 5 s), den RX1-Datenraten-Offset, die RX2-Datenrate und fünf zusätzliche EU868-Kanäle mit.
- Das Gerät sendet seinen ersten Uplink mit der neuen Session. Ab diesem Zeitpunkt werden seine Frames akzeptiert.
Wenn alle Prüfungen bestanden sind, zeigt das Join-Badge des Geräts Joined an, und das Gerät erhält die Attribute lora.devAddr und lora.joinedAt.
Wenn keines der beiden Empfangsfenster bedient werden kann (alle Gateways offline, deaktiviert oder das Duty-Cycle-Budget erschöpft), wird die Session angelegt, der Accept aber nicht gesendet. Das Join-Badge zeigt dann Join-Antwort nicht gesendet (kein Gateway rechtzeitig), und das Gerät versucht es erneut.
Ein abgelehntes Gerät erhält nie eine Antwort. LoRaWAN kennt keine Nachricht „join rejected“, daher wiederholt das Gerät den Versuch einfach später.
DevNonce-Regeln
Die DevNonce verhindert, dass jemand einen alten Join-Request erneut einspielt.
| LoRaWAN-Version | Regel |
|---|---|
| 1.0.4 | Jede DevNonce muss größer sein als die zuletzt akzeptierte. |
| 1.0.2 und 1.0.3 | Eine DevNonce darf nicht schon einmal verwendet worden sein. Die letzten 256 Werte werden gespeichert. |
Ein Gerät, das neu startet und seine DevNonce wieder bei 0 beginnen lässt (1.0.4), oder einen Wert wählt, den es schon verwendet hat (1.0.2, 1.0.3), wird abgelehnt, bis es eine neue verwendet. Das Setzen eines neuen AppKeys für das Gerät löscht seinen DevNonce-Verlauf.
Join-Status
Der Tab LoRaWAN des Geräts zeigt ein Join-Badge:
| Badge | Bedeutung |
|---|---|
| Noch nicht gejoined | Kein Join erfasst und keine Session vorhanden. |
| Joined | Der letzte Join wurde akzeptiert, oder das Gerät hat eine aktive Session. |
| Join abgelehnt: falscher AppKey? | Die Integritätsprüfung ist fehlgeschlagen. |
| Join abgelehnt: DevNonce wurde schon verwendet | Der Replay-Schutz hat die DevNonce abgelehnt. |
| Join abgelehnt: andere JoinEUI | Die JoinEUI weicht von der gespeicherten ab. |
| Join-Antwort nicht gesendet (kein Gateway rechtzeitig) | Alle Prüfungen waren erfolgreich, aber kein Gateway konnte den Accept senden. |
| Kein AppKey gespeichert | Das Gerät hat keinen Schlüssel, mit dem geprüft werden könnte. |
| Wartet auf Freigabe | Durch den Pairing-Modus hinzugefügt, noch nicht freigegeben. |
| ABP-Gerät: tritt nicht bei | Ein ABP-Gerät hat einen Join-Request gesendet. |
| Join abgelehnt (Grund) | Jede andere Ablehnung, mit ihrem Code. |
Über die API nimmt die Geräteliste den Filter joinState mit joined, refused oder never entgegen.
Sitzung zurücksetzen
Sitzung zurücksetzen im Tab LoRaWAN des Geräts beendet die aktuelle Session des Geräts. Seine Uplinks werden abgelehnt, bis es sich erneut anmeldet.
Verwenden Sie dies, nachdem das Gerät auf Werkseinstellungen zurückgesetzt wurde oder Sie seine Schlüssel geändert haben, damit keine alte Session bestehen bleibt. Bestätigen Sie Sitzung zurücksetzen: „Das Gerät muss sich erneut anmelden, bevor seine Uplinks akzeptiert werden. Verwenden Sie dies, nachdem ein Gerät zurückgesetzt oder seine Schlüssel geändert wurden.“
Das Zurücksetzen der Sitzung bringt das Gerät nicht zum Join: Das Gerät muss selbst einen Join starten (Stromzufuhr aus- und wieder einschalten oder seine Join-Taste verwenden). Für ABP-Geräte ist es nicht verfügbar. Jedes Zurücksetzen wird als iot_lorawan.device.session_reset protokolliert.