Basic Station Protokoll

Bisher

Es gibt kein einheitliches Update- und Konfigurationsmanagement. Anbieter von IoT-Plattformen und LNS Servern nutzen jeweils ihre eigens entwickelten Schnittstellen. So werden immer Experten benötigt, um Gateways in ein Netzwerk zu integrieren.



Aktuell mit Basic Station

Mit einem CUPS-Server und dem CUPS-Protokoll ist das Update- und Konfigurationsmanagement schon deutlich vereinfacht. Auf dem Gateway ist die Basic Station implementiert, die das CUPS Protokoll und das LNS-Protokoll beeinhaltet. Das Gateway mit Basic Station stellt eine Verbindung zum CUPS Server her und konfiguriert sich mittels des CUPS Protokoll. Anschließend fragt das Protokoll regelmäßig Updates an und führt diese durch. Auf dem LNS-Server oder einem extra Server ist beispielsweise das station2pkfwd Paket integriert, welches als Schnittstelle zwischen dem Basic Station LNS-Protokoll und dem LNS-Server fungiert.


station2pkfwd Paket auf einem Zwischenserver integriert:

Zukünftig möglich mit Basic Station

Wenn das Basic Station LNS-Protokoll auf dem LNS-Server als Schnittstelle implementiert ist, können so auch Datenpakete ohne den Umweg über den station2pkfwd Konverter transportiert werden und machen so den Weg frei für ein zukünftiges Plug´n & Play von LoRaWAN!


Warum gibt es die Basic Station und welche Vorteile bringt sie?

Die Basic Sation ist eine Implementierung für LoRaWAN Gateways mit einem zentralisierten Update- und Konfigurationsmanagement. Ohne dieses müssen Gateways aufwendig “per Fuss” installiert werden und es braucht meist einen Experten, der dies übernimmt. Mit der Basic Station ist nun ein großer Schritt in Richtung Plug´n & Play Lösungen für LoRaWAN getan. Der nächste Schritt ist die Implementierung des Basic Station LNS-Protokoll mittels Connector auf den LNS-Servern.

Vorteile:

  • Die Inbetriebnahme von Gateways wird deutlich einfacher
  • Portabler C-Code, der nur von der GNU libc abhängig ist
  • Bringt mit dem LNS-Protokoll und dem CUPS-Protokoll zwei leistungsstarke Backend-Protokolle mit.
  • Unterstützung der LoRaWAN Klassen A, B und C
  • Authentifizierung per Client-Zertifikat oder Authentifizierungstoken möglich
  • Einfache Handhabung mit Linux-basierten Gateways und Embedded Systemen

Zur Dokumentation

FAQ`s

Die Unterschiede liegen in der Datenübertragung, die wird zum Teil begrenzt um Energie (sehr oft langlebige Batterie) zu sparen.

Klasse A funktioniert nach ALOHA-Verfahren, der Sensor sendet die Datenpakete an das Gateway, anschließend folgen zwei Empfangsfenster. Während dieser Empfangsfenster kann der Sensor Daten empfangen. Außerhalb dieser Empfangsfenster gehen die Daten ins Leere.

Klasse B öffnet Empfangsfenster zu festgelegten Zeiten, dafür müssen der Sensor und das Gateway zeitlich synchronisiert werden.

Klasse C ist permanent offen und empfängt Daten. Sensoren der Klasse C brauchen oft mehr Energie als die Geräte der anderen zwei Klassen. 

Unter dem 1,00% duty cycle wird verstanden dass nur 1,00% der vergangenen Stunde für das Zeitfenster der Datenübertragung genutzt werden kann.

In einer Join Accept Message steckt die AppNonce, die NetID, der DevAddr, die DLSettings und das RxDelay.

OTAA (Over The Air Activation) und ABP (Activation By Personalisation), mehr dazu: Join Verfahren per OTAA oder ABP

Mit einem Packet-Multiplexer kann man LoRaWAN-Pakete eines Gateways auf mehrere Netzwerkserver verteilen. Empfohlen ist dies allerdings nur für nicht kritische Anwendungen.

Ein selbstbetriebenes Gateway kann auch auf ein eigenes LNS/Backend gerichtet werden, welches z.B. auf einem Raspberry PI oder sogar auf dem Gateway selber läuft. Dieses muss dann einfach die Messwerte per MQTT oder Ähnlichem weitergeben.  Für die Verarbeitung der Daten über Gateways dritter benötigen Sie einen LoRaWAN Netzwerkserver (LNS). Hier empfehlen wir thethingsnetwork.org. Dieser LNS ist für Privatanwendungen völlig ausreichend und empfehlenswert, da keine Gebühren anfallen und ein kostenloses Konto eröffnet werden kann.

Nein, das lässt sich nicht vermeiden. Da Ihre Datenpakete jedoch verschlüsselt sind und Ihr Sensor dem fremden LNS nicht bekannt ist, ist das Risiko überschaubar. Sollten Sie kritische Daten per LoRaWAN übermittelt, können wir Sie gerne zu weiteren Datenschutzmaßnahmen beraten.

Sie können den Support unserer IoT-Experten hier anfragen.

Sie haben weitere Fragen? Dann kontaktieren Sie uns!