1
Vor kurzem begann ich mit der Arbeit an LoRa-fähigen Geräten und bemerkte, dass einige von ihnen Fall nicht behandeln, wenn sie nicht vom Netzwerkserver bereitgestellt werden. Dies passiert sehr oft während der Entwicklung (besonders wenn NS gerade in Entwicklung ist).LoRaWAN unbestätigten Downlink und Re-JOIN-Prozedur
Hier ist, was passiert:
- LoRa Gerät auf Netzwerk/App Server bereitgestellt.
- LoRa Gerät sendet JOIN und erfolgreich.
- Ich löschte die Einheitenentität auf dem Netzwerkserver und fügt sie erneut hinzu. Dies führt zum Löschen der Sitzungsschlüssel, die während OTAA und Bereinigung des LoRa-Geräts erstellt werden, und sendet die Daten weiter, und es wird auf dem Server zurückgewiesen.
- Das LoRa-Gerät kann damit nichts anfangen und sendet Daten weiter.
Einige Geräte senden wieder JOIN, wenn der Strom wieder eingeschaltet. Aber nicht alle Geräte können überhaupt mit Strom versorgt werden! Einige Meter, die ich gesehen habe, wurden abgelehnt, um nach ihrer festverdrahteten Batterie zu arbeiten, wenn sie wieder angebracht wurde!
Gibt es einen "gemeinsamen" Ansatz, wie Gerät solche Art von "Trennung" von NS erkennen/behandeln sollte?
Sobald der Server eine JOIN ACCEPT-Nachricht zurücksendet, hat er einen Vertrag mit dem Gerät geschlossen. Wenn Sie die Einheit des Geräts auf dem Server löschen, wird dieser Vertrag einfach aufgehoben. – tofro
"Vertragsverletzung" kann aus vielen Gründen, absichtlich oder nicht auftreten. Egal was, ein Gerät sollte in Betrieb bleiben, oder? Ich kann nicht (bis jetzt) sehen, dass LoRaWAN irgendetwas definiert, das helfen kann, diese "Verletzung" zu entdecken –
Das Gerät ** bleibt ** funktionsfähig. Du hast dem Server gerade gesagt, dass er es nicht mehr hören soll. Das Gerät selbst kann nicht viel dagegen tun. Wenn der Server es nicht einfach ignorieren würde, wären DOS-Angriffe wahrscheinlich viel zu einfach. – tofro