Architektur

Inhalt

Überblick

Firefly setzt den LoRaWAN-Netzwerkstack als zusammenhängende Plattform um. niotix bindet Firefly als verbundenes System an: die Produktintegration erfolgt über den Konnektor firefly (REST für Verwaltung und Steuerung, MQTT für Uplink-Daten über organisationsspezifische Subscriptions).

Zum Einordnen der folgenden Abschnitte sind u. a. die Begriffe Konto (niotix), Organisation und API-Schlüssel (Firefly), MQTT-Subscription, LoRaWAN-Gerät, Gateway und Downlink hilfreich; vertieft werden sie auf den verlinkten LoRaWAN- und IoT-Data-Hub-Seiten.

Einordnung in der niotix-Oberfläche

  • Verbundene Systeme → LoRaWAN System: Einstieg in die Firefly-Oberfläche (ohne automatisch eine vollständige niotix-Anbindung zu ersetzen).
  • Integrationen → Konnektoren: Anlage und Pflege des Konnektors firefly (baseUrl, API-Schlüssel, MQTT).
  • IoT Data Hub → Gatewayverwaltung: Gateway-Lebenszyklus im Konto; bei konfigurierter Anbindung u. a. Nutzung von Elasticsearch-Metriken (siehe unten).

LoRaWAN-Serverrollen in Firefly

LoRaWAN trennt Netz-, Anwendungs- und Join-Logik. In Firefly wirken Network Server, Join Server und Application Server zusammen; niotix spricht überwiegend die nach außen geführten APIs und Datenkanäle des Application Server an, während Join- und Netzwerkfunktionen im Hintergrund für Funk und Sicherheit zuständig bleiben.

Network Server

Der Network Server ist die netznahe Instanz im LoRaWAN-Stack. Typische Aufgaben:

  • PHY/MAC-Seite: Verarbeitung der von Gateways eingespielten LoRaWAN-Rahmen, Auflösung des Funkpfads bis zum Gerät.
  • Integrität und Sicherheit auf MAC-Ebene: Prüfung von MIC und Frame-Counter, Schutz vor Wiedereinspielung (Replay), Einhaltung der für die Region geltenden Regeln (z. B. Duty Cycle, Subbänder).
  • Mehrfachempfang: Zusammenführung bzw. Auswahl bei denselben Uplinks über mehrere Gateways (Deduplizierung / „best gateway“-Logik je nach Implementierung).
  • ADR und Datenrate: optional adaptive Datenrate und Spreading Factor, soweit durch Gerät und Netz unterstützt.
  • Downlink: Terminierung von Downlink-Fenstern (Klassen A/B/C), Auswahl geeigneter Gateways, Berücksichtigung von Sendeplan, Leistungsgrenzen und Geräteklasse.
  • Weiterleitung: Übergabe entschlüsselter oder aufbereiteter Netzwerkinformationen an den Application Server; Join-bezogene Kryptografie wird in der Regel mit dem Join Server koordiniert.

Kurz: Der Network Server entscheidet, ob und wie ein Uplink netzseitig gültig ist und wann und über welches Gateway ein Downlink gesendet wird.

Join Server

Der Join Server kapselt die Aktivierung über die Luft (typischerweise OTAA). Typische Aufgaben:

  • Schlüsselmaterial: sichere Verwaltung der Root-Keys (z. B. AppKey) und der damit verbundenen Join-Identitäten (JoinEUI / AppEUI, DevEUI).
  • Join-Request: Prüfung eingehender Join-Requests (u. a. DevNonce / Wiederholungslogik), Abgleich mit der Geräteregistrierung.
  • Sitzungsableitung: Erzeugung der Sitzungsschlüssel für Netz und Anwendung nach erfolgreicher Autorisierung.
  • Join-Accept: Erstellung und kryptografische Absicherung der Join-Accept-Nachricht; Zusammenarbeit mit dem Network Server für die Auslieferung an das Gerät.

Ohne funktionierenden Join Server (bzw. ohne gültige Schlüssel- und Identitätskonfiguration) können sich Geräte per OTAA nicht aktivieren, selbst wenn Gateways und der Network Server erreichbar sind.

Application Server

Der Application Server bündelt den anwendungsnahen Teil: Geräte- und Gatewayverwaltung in der Organisation, REST-APIs, Payload-Verarbeitung auf Anwendungsebene sowie die Mechanismen, über die niotix den Konnektor firefly an Organisation, Geräte, Gateways und Subscriptions (inkl. MQTT-Queue) koppelt.

Endgeräte, Gateways und Transport

Firefly bindet LoRaWAN-Geräte über den üblichen Transportpfad Endgerät ↔ Funk ↔ mindestens ein Gateway ↔ IP-Netzwerk (Backhaul) ↔ Firefly (Logik von Network-, Application- und Join-Server). Die folgenden Unterabschnitte trennen Luftstrecke und IP-Transport; konkrete Ports, Protokolle und Zeitthemen zur Gateway-Anbindung behandelt die Seite Anbindung von LoRaWAN-Gateways.

LoRaWAN-Funkpfad zwischen Gerät und Gateway

  • Uplinks und Join-Requests: das Endgerät sendet im konfigurierten Frequenzplan; eines oder mehrere Gateways empfangen den LoRaWAN-Rahmen und geben ihn über den Backhaul an Firefly weiter.
  • Downlinks: Firefly plant den Downlink (u. a. Gatewaywahl, Sendezeitpunkt, Leistungsgrenzen); das ausgewählte Gateway sendet den Rahmen im passenden Empfangsfenster des Geräts (Geräteklasse A/B/C).
  • Anforderungen auf der Luftstrecke: passender Frequenzplan und konsistente Geräteparameter (u. a. OTAA-Schlüssel, Region); Reichweite, Spreading Factor und regionale Vorgaben (z. B. Duty Cycle) bestimmen Zuverlässigkeit und Latenz auf dem Funkmedium; Firewall- und Routing-Regeln im Firmen-LAN wirken erst ab dem IP-Backhaul hinter dem Gateway.

IP-Backhaul zwischen Gateway und Firefly

Gateways verbinden sich mit dem Netzwerkserver von Firefly typischerweise über einen der beiden gängigen Pfade:

  • Semtech UDP Packet Forwarder: verbindungslos UDP zum Netzwerkserver, in typischen Setups oft Ziel-UDP-Port 1700 (siehe dort). Bei Verwendung dieses Forwarders muss in Firefly kein Gateway angelegt werden.
  • Basic Station: WebSocket-Verbindung, üblicherweise wss://…, typischer Ziel-Port 4020 oder 443 (TLS), mit Gateway-EUI und Auth-Token in Firefly.

Aus Sicht des Betriebsnetzes müssen die vom Betreiber der Firefly-Instanz vorgegebenen Zieladressen und Ports vom Gateway aus erreichbar sein (Richtung Internet/SaaS oder zum selbst gehosteten LNS). Eingehende Dauer-Verbindungen von Firefly in private Heimnetze der Gateways sind für diesen Standardpfad nicht typisch; Gateways initiieren in der Regel ausgehende Verbindungen (UDP-Pakete bzw. WebSocket-Session). Hinter NAT funktioniert das üblicherweise, solange ausgehende Verbindungen erlaubt sind; bei Basic Station bleibt eine stabile, dauerhafte Ausgangsverbindung wichtiger als bei sporadischem UDP.

Zeit und Backhaul-Qualität: Präzise UTC am Gateway (NTP und ggf. GPS) ist zentral für Downlink-Timing, Join-Verarbeitung und Diagnose — siehe Anbindung von LoRaWAN-Gateways (Abschnitt Zeit, NTP und Receive Time). Geringe Latenz und wenig Jitter auf dem IP-Pfad zum Netzwerkserver unterstützen pünktliche Downlinks und MAC-Befehle; sehr hohe Verzögerungen oder Paketverlust wirken sich je nach Region, Datenrate und Geräteklasse spürbar aus.

Systemüberblick

%%{ init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#FFFFFF', 'primaryTextColor': '#031403', 'primaryBorderColor': '#606060', 'lineColor': '#606060', 'secondaryColor': '#2fcbff', 'tertiaryColor': '#E7E6E6', 'primary_font' : 'Poppins:wght@300;400;500;600;700;800', 'primary_font_type' : 'sans-serif' } } }%% flowchart LR subgraph fireflySys["`**Firefly**`"] direction LR organization[" Organisation"] as[" Application Server"] ns[" Network Server"] js[" Join Server"] devices[" Geräte"] gateways[" Gateways"] end organization --> as as --> ns js --> ns devices --> ns gateways --> ns ns --> as as --> organization

Die Kanten verdeutlichen die typische Daten- und Verwaltungsrichtung: Gateways speisen den Network Server, der mit Join Server und Application Server zusammenarbeitet; Organisation und Geräte werden über den Application Server geführt.

Datenfluss zwischen niotix und Firefly

Für niotix ist insbesondere der Konnektor firefly relevant:

%%{ init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#FFFFFF', 'primaryTextColor': '#031403', 'primaryBorderColor': '#606060', 'lineColor': '#606060', 'secondaryColor': '#2fcbff', 'tertiaryColor': '#E7E6E6', 'primary_font' : 'Poppins:wght@300;400;500;600;700;800', 'primary_font_type' : 'sans-serif' } } }%% flowchart LR subgraph niotixSys["`**niotix**`"] direction LR connector[" Konnektor firefly"] processing[" Verarbeitung / Gatewayverwaltung"] end subgraph fireflyInt["`**Firefly**`"] direction LR organizationInt[" Organisation"] devicesInt[" Geräte und Gateways"] end connector -->|"REST mit API-Schlüssel"| organizationInt organizationInt -->|"Verwaltung"| devicesInt devicesInt -->|"MQTT-Uplinks"| connector connector -->|"Rohpakete, Downlinks, Monitoring"| processing
  1. niotix verbindet sich mit Firefly über baseUrl und API-Schlüssel.
  2. Der Konnektor liest über den API-Schlüssel die zugehörige Firefly-Organisation.
  3. Für diese Organisation wird eine Firefly-Subscription angelegt oder aktualisiert.
  4. Über die Subscription erhält niotix MQTT-Uplinks.
  5. niotix verarbeitet die Rohdaten weiter und ordnet sie der weiteren Paketverarbeitung zu.
  6. Verwaltungsaktionen wie Geräteanlage, Geräteänderung oder Downlinks laufen per REST zurück nach Firefly.

Die wichtigsten Konnektorfelder in niotix (u. a. baseUrl, apiKey, MQTT-URL für Uplinks) sind in der Doku Konnektor Firefly beschrieben. Zur Verarbeitung eingehender Daten, zur Konfiguration in Virtuellen Geräten und zu Downlinks aus Regeln siehe Virtuelle Geräte und Regeln.

Die Subscription ist an die Organisation gebunden und wird über die Firefly-API im Umfeld des Application Server verwaltet. Dafür wird ein Binding vom Typ organization_up_packets mit einer MQTT-Queue angelegt.

Für niotix ist Firefly kein allgemeines Ziel für Webhooks, sondern ein LoRaWAN-System mit eigener Subscription-Logik. Deshalb werden in niotix typischerweise REST-Aufrufe und Firefly-MQTT genutzt.

Anforderungen an die niotix-Anbindung

  • Vom niotix-Betriebsnetz aus müssen ausgehende HTTPS-Zugriffe auf die Firefly-REST-API sowie MQTT zum Firefly-Broker (gemäß Konnektorkonfiguration) möglich sein; Proxy- und Firewall-Regeln richten sich nach den üblichen Unternehmensvorgaben für TLS/TCP.
  • Die Firefly-Bridge im niotix-Backend nutzt typische Timeouts von etwa zwei Sekunden für REST-Aufrufe und den MQTT-Verbindungsaufbau (api.timeout / mqtt.timeout in der Dienstkonfiguration); abweichende Werte sind je nach Installation möglich.

Elasticsearch und Paketmetriken

Neben den Kanälen REST und MQTT spielt für den Betrieb oft Elasticsearch eine Rolle: LoRaWAN-Paketmetadaten (z. B. empfangene Pakete je Gateway, RSSI, LSNR, Spreading Factor, Zeitstempel) werden in typischen Setups in einem Network-Server-nahen Index gesammelt. niotix wertet dazu im Backend das Indexmuster metrics-networkserver_packets-* aus, sofern an der Datenquelle des Gateways eine Elasticsearch-Adresse hinterlegt ist (elasticsearchAddress an der Datenquelle; Auswertung u. a. für Gatewayverwaltung und Performance-Ansichten).

Wichtig für die Interpretation:

  • Die Metriken beziehen sich auf den gesamten LoRaWAN-Verkehr am Gateway, nicht nur auf in Firefly registrierte Geräte; der Index kann damit auch unbekannte Geräte abbilden und dient der Beurteilung der Funkstrecke und der Empfangsqualität.
  • niotix schreibt diese Indizes nicht selbst; Voraussetzung ist ein betriebsbereites Elasticsearch mit dem erwarteten Schema bzw. kompatiblen Feldnamen (u. a. gw_eui, rssi, lsnr, spreading_factor, received_at_server).

Ausführlicher zur Darstellung in der Oberfläche: IoT Data Hub – Gatewayverwaltung (Abschnitt Gatewayverwaltung).

Konto- und Organisationsmodell

Zwischen niotix und Firefly werden unterschiedliche Begriffe verwendet:

  • In niotix ist das zentrale Mandantenobjekt das Konto.
  • In Firefly werden Geräte, Gateways, Benutzer und API-Schlüssel an Organisationen und Unterorganisationen gebunden.

Für die technische Zuordnung ist wichtig:

  • niotix verarbeitet Daten im Kontext eines Kontos
  • Firefly ordnet den verwendeten API-Schlüssel genau einer Organisation zu
  • der Firefly-Konnektor erzeugt Subscription und Gerätesynchronisation immer auf Basis dieser Organisation

Häufige Fragen

Warum ist Firefly in niotix sichtbar, obwohl die Integration noch nicht funktioniert?

Der Menüpunkt LoRaWAN System öffnet nur die Firefly-Oberfläche. Für die technische Anbindung an niotix ist zusätzlich ein Firefly-Konnektor erforderlich.

Warum wird eine MQTT-URL benötigt?

Die MQTT-URL wird genutzt, damit niotix Uplink-Daten aus Firefly empfangen kann. Ohne diesen Pfad bleibt die Geräteverwaltung per REST möglich, eingehende Messdaten werden jedoch nicht auf demselben Weg übertragen. Das ist eine typische Ursache, wenn Pakete in Firefly sichtbar sind, in niotix aber nicht ankommen, insbesondere nach der Neuanlage eines Konnektors.

Ist Firefly oder niotix das führende System?

Für LoRaWAN-Rohdaten und netznahe LoRaWAN-Funktionen ist Firefly das führende System. In niotix-basierten Setups werden Geräte jedoch in niotix angelegt und verwaltet; die zugehörigen Änderungen werden an Firefly übertragen.

Verwandte Seiten