Überblick

Diese Seite beschreibt, wie LoRaWAN-Gateways an den Netzwerkserver Firefly angebunden werden. Unterstützt werden der Semtech UDP Packet Forwarder und der Basic Station Packet Forwarder (WebSocket).

Hinweise zur Hardware-Inbetriebnahme (Antennen, Stromversorgung, SIM/APN) gibt die Seite Inbetriebnahme-Hinweise.

Verbindungsdaten auf einen Blick

• Für andere Regionen und selbst gehostete Firefly-Installationen gelten abweichende Hosts und ggf. Ports – siehe Frequenzpläne und Netzwerkserver-Adressen.
• Bei privatem APN oder restriktiver Firewall: Firewall-Whitelist.
• Quelle der Endpunkte und Frequenzpläne: Firefly-Handbuch (Abschnitte „Frequency plans" und „Network server addresses").

Anbindungsarten

Semtech UDP Packet Forwarder

Der klassische Semtech-UDP-Forwarder sendet verbindungslos per UDP an den Netzwerkserver, ohne Transportverschlüsselung. Eine Registrierung in Firefly ist nicht erforderlich – Firefly verarbeitet eingehende Pakete direkt über den UDP-Einstiegspunkt. Das Downlink-Timing orientiert sich an der JIT- bzw. RX-Fenster-Logik.

Am Gateway einzustellen:

• Serveradresse und Port gemäß Tabelle oben
• Frequenzplan passend zur Region

Basic Station

Basic Station verbindet sich über eine TLS-verschlüsselte WebSocket-Verbindung und wird in Firefly als eigener Verbindungstyp behandelt: Das Gateway muss in Firefly angelegt werden (Name, EUI, Auth-Token). Die Authentifizierung erfolgt per TLS Server Authentication and Client Token.

Am Gateway einzustellen:

• WebSocket-URL des Netzwerkservers (tc.uri) gemäß Tabelle oben
• Gateway-EUI (64 Bit / 16 Hex-Zeichen): muss exakt dem Eintrag in Firefly entsprechen (Details: Station Identity)
• Auth-Token aus der Gateway-Anlage in Firefly
• CA-Zertifikat / Vertrauenskette: nur nötig, wenn das Gateway die Serveridentität des LNS prüft – für die öffentliche SaaS (Let’s Encrypt) z. B. ISRG Root X1 (cross-signed, PEM), bei On-Prem-Firefly die zugehörige Ausstellerkette (Details: LoRa Basics™ Station Konfiguration)

Ein vollständiges Praxisbeispiel zeigt Kerlink iStation mit Basic Station.

Checkliste Firewall und Ports

Diese Liste fasst die IP-seitigen Voraussetzungen am Gateway zusammen (Backhaul zum Netzwerkserver). Zum Gesamtbild Endgerät ↔ Funk ↔ Gateway ↔ Firefly siehe Architektur. Eine zentrale Übersicht der freizugebenden Endpunkte aller Anbindungsarten (z. B. bei Mobilfunktarifen mit privatem APN) bietet die Seite Firewall-Whitelist.

Semtech UDP Packet Forwarder

• Ausgehendes UDP vom Gateway zum konfigurierten LNS-Host erlauben; Zielport wie in der Umgebung vorgegeben (häufig 1700, siehe oben).
• DNS oder feste Ziel-IP muss vom Gateway aus erreichbar sein.
• NAT / Stateful Firewall: typischerweise ausreichend, wenn das Gateway die UDP-Sitzung beginnt. Da UDP verbindungslos ist, hält die Firewall den Rückweg nur für eine begrenzte Zeit offen (UDP-Timeout). Der UDP-Timeout muss länger sein als das Keepalive-Intervall des Packet Forwarders (PULL_DATA) – sonst gehen Downlinks (z. B. Join Accepts) sporadisch verloren, obwohl Uplinks ankommen.
• Stateless Paketfilter: Rückverkehr von Firefly mit Quellport 1700 zum Gateway explizit erlauben (siehe Firewall-Whitelist).
• Latenz/Jitter: möglichst niedrig halten; extreme Verzögerungen oder Paketverlust wirken sich auf Downlinks und Joins aus (siehe auch Architektur).

Basic Station

• Ausgehendes TCP/TLS zum wss://-Endpunkt erlauben; Zielport wie in der LNS-URL bzw. Umgebung vorgegeben (häufig 4020 oder 443).
• TLS-Inspection durch Firewalls/Proxies nur aktivieren, wenn die vollständige WebSocket- und Zertifikatsweiterleitung sichergestellt ist.
• Langlebige WebSocket-Session: Verbindungsabbrüche durch aggressive Timeouts oder „rote" WLAN-/LTE-Wege vermeiden.
• Zertifikate: CA-/Serverprüfung am Gateway nur mit passender Trust-Chain konfigurieren.

Zeit, NTP und Receive Time

Eine stabile UTC-Zeitbasis am Gateway ist – unabhängig von der Anbindungsart – für Downlinks, Join-Verarbeitung und Diagnose kritisch:

• NTP und, falls vorhanden, GPS sauber einrichten
• Basic Station nutzt primär rxtime; UDP-Pfade bevorzugen tmms, danach time
• ohne belastbare Gateway-Zeit schätzt Firefly die Receive Time (mit unterschiedlichen Offsets, z. B. für normale Pakete und Join-Anfragen)
• auffällige Zeitversätze führen zu Downlink-Problemen und sollten vor weiterer Fehlersuche ausgeschlossen werden

Frequenzpläne und regionale Auswirkungen

Firefly unterstützt mehrere Regionen (u. a. EU868, US915, AU915, AS923, IN865, KR920, CN470); Standardregion ist EU868.

• Kanalplan am Gateway und Firefly-Region müssen zusammenpassen
• eine falsche Region führt zu fehlenden Uplinks oder scheinbar instabilen Downlinks
• Adressen und Kanalfrequenzen je Region: Frequenzpläne und Netzwerkserver-Adressen

Gateway-Verwaltung

Verwaltet werden Gateways in Firefly unter Organization → Gateways; in niotix ergänzt der Bereich IoT Data Hub – Gatewayverwaltung (Gateway Mgmt) Monitoring- und Verwaltungsfunktionen. Auch UDP-Gateways, die für die reine Anbindung nicht angelegt werden müssten, können in niotix hinzugefügt werden – damit steht das Paket-Monitoring für den gesamten Bestand zur Verfügung.

Typische Aufgaben in niotix:

• Gateways listen und filtern
• aggregierte Metriken und letzte Paketaktivität auswerten
• Firefly-bezogene Gateway-IDs und Organisationsbezüge sichtbar machen
• Schwellenwerte und Zustandsbewertung für Betriebsüberwachung nutzen

Fehlerbehebung

Wenn ein Gateway keine oder nur sehr wenige Nutzdaten liefert, liegt die Ursache meist in Verbindungsmodell, Authentifizierung, Zeitbasis oder Frequenz-/Regionsparametern.

Checkliste (empfohlene Reihenfolge)

• Protokoll und Modell: Semtech UDP Packet Forwarder oder Basic Station ist konsistent mit Gateway-Firmware, Firewall/Ports und der Firefly-Einrichtung gewählt (siehe Anbindungsarten und Checkliste Firewall und Ports).
• Basic Station: Gateway ist in Firefly angelegt; EUI und Auth-Token stimmen mit den Gerätewerten überein.
• Zeitbasis: NTP/GPS und empfangene Zeitstempel sind plausibel, ohne starke Drift oder Sprünge (siehe Zeit, NTP und Receive Time).
• Region und Kanalplan: Einstellungen am Gateway passen zu Firefly-Region und Organisation (siehe Frequenzpläne und regionale Auswirkungen).
• Firefly: Uplinks bzw. Gateway-Aktivität sind dort sichtbar und lassen sich den erwarteten Endgeräten zuordnen.
• niotix: Unter Gateway Mgmt Metriken, letzte Paketaktivität und Zuordnung zur Organisation prüfen; Abweichungen zwischen niotix und Firefly gezielt nach den vorherigen Punkten abarbeiten.

Häufige Fragen

Warum muss ein Basic-Station-Gateway in Firefly angelegt werden, ein UDP-Gateway aber nicht?

Basic Station verwendet eine authentifizierte WebSocket-Verbindung mit organisationsbezogenem Gateway-Eintrag. Der klassische Semtech-UDP-Forwarder arbeitet ohne diesen Verwaltungsweg.

Was ist der häufigste Grund für scheinbar hängende Downlinks?

Häufig fehlen belastbare Uplink-Daten oder korrekte Gateway-Zeitinformationen. Dann kann Firefly kein geeignetes Gateway oder kein plausibles Sendefenster ableiten.

Warum zeigt niotix ein Gateway, aber Firefly empfängt keine sinnvollen Pakete?

In diesem Fall sollte zuerst geprüft werden, ob Region, Kanalplan, Gateway-Konfiguration und Firefly-Organisation zusammenpassen. Die reine Sichtbarkeit in niotix ersetzt keine gültige Firefly-Funkanbindung.

Warum erscheinen in Gateway Mgmt nicht alle Gateways oder die Ansicht lädt auffällig langsam?

Das ist ein typisches Supportthema in gatewaynahen Oberflächen. Zuerst Filter, Seitengröße, Sortierung, Datenaktualität und die Firefly-bezogene Gateway-Zuordnung prüfen.

Warum funktioniert ein Basic-Station-Gateway nicht, obwohl die URL stimmt?

Neben der URL müssen bei Basic Station auch EUI, Auth-Token, Zertifikatskette und Zeitbasis stimmen. Anders als beim klassischen UDP-Forwarder ist die Gateway-Anlage in Firefly hier verpflichtend. Siehe Basic Station.