Überblick

Frequenzplan und Netzwerkserver-Adresse müssen zur realen Betriebsumgebung passen. Der Netzwerkserver arbeitet pro Instanz mit einem fest konfigurierten Frequenzplan; in der öffentlichen Firefly-Cloud ist deshalb jeder SaaS-Host einem Plan zugeordnet (siehe Zuordnung in der öffentlichen Firefly-Cloud). Fehler in diesem Bereich führen oft dazu, dass Gateways zwar erreichbar scheinen, aber keine verwertbaren Pakete oder keine zuverlässigen Downlinks liefern.

Dieser Abschnitt ist insbesondere relevant, wenn eine neue Region eingerichtet wird, ein Gateway mit zum Einsatzumfeld nicht passendem Frequenzplan betrieben wird, Adresse oder Erreichbarkeit des Netzwerkservers nicht dem Erwartungsbild entspricht oder öffentliche Firefly-SaaS und selbst gehostete Installation sachlich voneinander abzugrenzen sind. Für die Planung sind Zielregion (Gerät oder Gateway), verwendeter Gateway-Typ sowie das vorgesehene Bereitstellungsmodell (öffentliche Firefly-SaaS bzw. eigene Installation) vorab festzulegen.

In niotix müssen Region und Endpunkt-URLs zum selben Firefly-Kontext passen. Konfiguration im Virtuellen Gerät und im Konnektor firefly sollte mit den Angaben in dieser Dokumentation übereinstimmen.

Frequenzpläne

Firefly unterstützt die folgenden Frequenzpläne.

Übersicht

Kanalfrequenzen

Angaben in MHz; bei EU868, AS923, IN865 und KR920 sind die aufgeführten Uplink-Frequenzen für RX1-Fenster 1 dieselben wie die Downlink-Kanäle (siehe get_rx1_freq in den jeweiligen Band-Modulen).

EU868

US915

AU915

AS923

IN865

KR920

Hinweis: RX2 (921,9 MHz) ist die feste zweite Empfangsfrequenz laut LoRaWAN bzw. Firefly (921900000 Hz im KR920 Bandmodul); sie entspricht keiner der sieben Uplink-/RX1-Mitten.

CN470 (im Server aktiv: Uplink-Indizes 80–87 des 470-MHz-Rasters, Downlink die ersten acht Kanäle des 500-MHz-Rasters)

RX2-Frequenzen je Plan siehe Tabelle Übersicht.

Öffentliche SaaS-Adressen

Für die öffentliche SaaS werden mehrere Netzwerkserver-Hostnamen für UDP-basierte Packet-Forwarder verwendet. Der dokumentierte Standardport ist 1700. Die folgenden Abschnitte stellen dar, wie Frequenzplan und Hostname zusammenhängen.

Diese Adressen sind nur dann korrekt, wenn tatsächlich die öffentliche Firefly-SaaS genutzt wird.

Technik: ein Netzwerkserver, ein Frequenzplan

Für jede angebundene Firefly-Umgebung arbeitet der LoRaWAN-Netzwerkdienst mit genau einem Frequenzplan (regionaler LoRa-Channel-Plan).

Drei Stellen müssen auf dieselbe Zielregion bzw. den gleichen regionalen Plan abgestimmt sein: der erreichbare Netzwerkdienst bzw. die Zieladresse (einschließlich Host/Port), die Einstellungen im Endgerät und am Gateway. In der öffentlichen SaaS wählt man den dort dokumentierten Hostnamen passend zur Zielregion, in einer eigenen Installation den in der Doku vorgesehenen Zugang. Im Endgerät sind passende Region- bzw. Frequenzeinstellungen bzw. Profil-Parameter einzustellen, am Gateway die dazu passende Frequenz- bzw. Plankonfiguration.

Stimmt die Abstimmung nicht durchgängig, sind typischerweise Verbindungs- und Join-Auffälligkeiten oder leere Nutzlasten die Folge — auch wenn Zieladresse und Port formal erreichbar sind.

Zuordnung in der öffentlichen Firefly-Cloud

In der öffentlichen Firefly-SaaS lautet die Europa- bzw. EU868-Instanz fireflyiot.com.

Jeder in der Tabelle unten bzw. im Anwendungshandbuch dokumentierte Netzwerkserver-Host ist einer Zielregion bzw. einer Frequenzplan-Vorgabe zugeordnet. Siehe Firefly-Anwendungshandbuch, Kapitel zu Regionen und Serveradressen.

Praktisch müssen sich Gateway und Geräteprofil auf den vorgesehenen Frequenzplan dieses Hosts beziehen: für US915 typischerweise us1.ns.fireflyiot.com, für EU868 fireflyiot.com. Allein der Hostname garantiert die Planausrichtung nicht; wichtig ist, dass Ziel, Gateway und Endgerät dem für diese Zielregion vorgesehenen Plan folgen.

Auswirkungen auf Betrieb und Troubleshooting

Wenn Frequenzplan oder Adresse nicht passen, zeigen sich oft folgende Symptome:

• keine oder zu wenige Uplinks
• inkonsistente Downlinks
• scheinbar korrekt angebundene, aber fachlich stumme Gateways
• Join-Probleme

Bei der Prüfung sollten immer gemeinsam bewertet werden:

• Firefly-Region
• Gateway-Konfiguration
• Geräteprofil
• Zieladresse und Port
• SaaS oder selbst gehostete Umgebung

Häufige Fragen

Ist US915 immer an us1.ns.fireflyiot.com gebunden?

In der öffentlichen Firefly-Cloud ist diese Kombination die vorgesehene und dokumentierte **US915-**Zuordnung für diesen Host. Technisch erzwingt der DNS-Name den Plan nicht — entscheidend ist die Konfiguration des erreichbaren Netzwerkservers und dass Ziel, Gateway und Endgeräte zum vorgesehenen Plan passen. In selbst gehosteten Umgebungen können andere Hostnamen dieselbe Rolle haben; dort entscheidet die Deployment-Konfiguration, nicht der feste SaaS-Name.

Datenblätter nennen oft mehrere LoRa-Regionen — woran orientiert man sich im konkreten Einsatz?

Maßgeblich ist, welcher Channel Plan bzw. welche Region Sie tatsächlich konfiguriert und im laufenden Betrieb nutzen — nicht die Liste aller Regionen, die ein Gerät laut Hersteller grundsätzlich abdecken könnte. Wichtig ist der Abgleich: Geräteprofil, Gateway-Einstellungen und zugehörige Firefly-Seite (Ziel- und Frequenzkontext) müssen dieselbe reale Einstellung widerspiegeln.

Warum empfängt ein Gateway Pakete, aber das Verhalten bleibt instabil?

Häufig passt der Frequenzplan nicht vollständig zur Firefly-Region oder das Gateway sendet an die falsche Adresse bzw. in die falsche Umgebung (SaaS vs. selbst gehostet). Siehe Auswirkungen auf Betrieb und Troubleshooting.