Wie funktioniert ein LoRaWAN Gateway? Aufgaben, Netzwerkserver und Anbindung

Das Gateway steht im Büro, die LED leuchtet, die Weboberfläche meldet „verbunden“ – und trotzdem taucht in deiner Anwendung kein einziger Messwert auf. Genau an dieser Stelle merken viele, dass ein LoRaWAN Gateway weniger tut, als der Name vermuten lässt. Die kurze Antwort: Ein LoRaWAN Gateway ist ein Funkempfänger mit Internetanschluss. Es hört alle LoRaWAN-Pakete in seiner Reichweite, hängt Empfangsdaten wie Zeitstempel und Signalstärke an und reicht alles an einen Netzwerkserver weiter. Entschlüsseln, Geräte verwalten und doppelte Pakete aussortieren erledigt der Server.

Wer diese Arbeitsteilung kennt, wählt Hardware schneller aus und findet Fehler gezielter. Denn fast jede Frage rund um Gateways – eingebauter Server oder nicht, LAN oder Mobilfunk, 8 oder 16 Kanäle – lässt sich auf eine einzige zurückführen: Welcher Teil des Datenwegs liegt im Gateway, und welcher liegt woanders?

Was macht ein LoRaWAN Gateway genau?

Ein Sensor sendet seine Messung per LoRa-Funk, ohne zu wissen, welches Gateway sie empfängt. Anders als ein Smartphone im WLAN ist er mit keinem Gateway gekoppelt. Jedes Gateway in Reichweite, das auf der passenden Frequenz lauscht, nimmt das Paket auf. Den Inhalt kann es dabei nicht lesen: Die Nutzdaten sind mit AES-128 verschlüsselt, und die Schlüssel liegen beim Netzwerk- und Anwendungsserver, nicht im Gateway.

Was das Gateway hinzufügt, sind Metadaten: den genauen Empfangszeitpunkt, die Frequenz, den Spreading Factor, die Signalstärke (RSSI) und den Signal-Rausch-Abstand (SNR). Zusammen mit der Rohnachricht schickt es diese Daten über seine Internetverbindung, den sogenannten Backhaul, an den Netzwerkserver. Der Backhaul kann Ethernet, WLAN oder Mobilfunk sein; der Sensor merkt davon nichts.

In der Gegenrichtung arbeitet das Gateway als Sender. Plant der Netzwerkserver einen Downlink, etwa eine Bestätigung, eine Join-Antwort oder einen Konfigurationsbefehl, schickt er dem Gateway das fertige Paket samt exaktem Sendezeitpunkt. Das Gateway strahlt es dann genau im Empfangsfenster des Sensors aus. Ein Sensor der Klasse A öffnet diese Fenster nur kurz nach seinem eigenen Uplink; wird es verpasst, muss der Befehl bis zur nächsten Meldung warten.

Technisch steckt im Gateway ein Konzentrator-Chip, der viele Frequenzen gleichzeitig abhört. Im RAK7268V2 ist das ein Semtech SX1302 auf einer Mini-PCIe-Karte mit acht Kanälen. Er dekodiert Pakete mit unterschiedlichen Spreading Factors auf derselben Frequenz parallel. Genau das unterscheidet es von einfachen Einkanal-Empfängern aus Bastelprojekten, die nur eine Frequenz mit einem Spreading Factor hören.

LoRaWAN Gateway und Netzwerkserver: Wer übernimmt welche Aufgabe?

Der Netzwerkserver ist das eigentliche Gehirn eines LoRaWAN-Netzes. Er prüft, ob ein Paket von einem registrierten Gerät stammt, kontrolliert den Nachrichtenzähler gegen wiederholt eingespielte Pakete, steuert über Adaptive Data Rate (ADR) Sendeleistung und Spreading Factor der Sensoren und entscheidet, über welches Gateway ein Downlink gehen soll. Dazu kommen ein Join-Server für die Aktivierung neuer Geräte und ein Anwendungsserver, der die Nutzdaten entschlüsselt und an deine Software weitergibt.

Eine der wichtigsten Serveraufgaben ist die Deduplizierung. Hören drei Gateways dieselbe Aussendung, kommen beim Server drei identische Pakete an, jedes mit eigenen Empfangswerten. Der Server behält eine Kopie, verwirft die anderen und merkt sich, welches Gateway das beste Signal hatte. Über dieses Gateway schickt er eine eventuelle Antwort zurück.

Die folgende Übersicht zeigt, wo welche Aufgabe liegt. Sie hilft beim Prüfen von Angeboten und beim Eingrenzen von Fehlern:

Daraus folgt eine einfache Regel für den Einkauf: Ein Gateway allein liefert weder ein Dashboard noch Payload-Decoder für deine Sensoren. Diese Teile kommen vom Netzwerk- und Anwendungsserver – ob als Community-Netz wie The Things Network, als selbst betriebener ChirpStack, als kommerzieller Cloud-Dienst oder direkt im Gateway.

LoRaWAN Gateway mit integriertem Netzwerkserver: Wann ist das sinnvoll?

Viele aktuelle LoRaWAN Gateways bringen einen eigenen Netzwerkserver mit. Das RAK7268V2 kennt dafür den Betriebsmodus „Built-in Network Server“: Du legst im Webinterface eine Anwendung an, registrierst deine Sensoren und gibst die Daten per MQTT oder HTTP an deine Software weiter. Ein externer Server ist dann nicht nötig.

Sinnvoll ist das bei überschaubaren, abgeschlossenen Projekten: ein Gebäude, ein Gelände, einige Dutzend Sensoren, Daten, die ohnehin in ein lokales System fließen. Auch ohne dauerhafte Internetverbindung funktioniert das. RAK erlaubt zudem, weitere Gateways als Extender per MQTT an ein zentrales Gateway mit eingebautem Netzwerkserver anzubinden.

Die Grenzen zeigen sich beim Wachstum. Mehrere Standorte, Hunderte Sensoren, Benutzerverwaltung und eine zentrale Geräteverwaltung lassen sich mit einem externen Netzwerkserver deutlich einfacher abbilden. Ein typischer Fehler bei der Einrichtung: Die Sensoren werden im eingebauten Server angelegt, das Gateway läuft aber im Weiterleitungsmodus – oder umgekehrt. Beide Seiten sehen für sich korrekt aus, ergeben zusammen aber keinen Datenweg. Entscheide dich deshalb vor der Einrichtung für einen Modus und notiere ihn.

Packet Forwarder oder Basics Station: Wie spricht das Gateway mit dem Server?

Läuft der Netzwerkserver extern, braucht das Gateway ein Protokoll für den Weg dorthin. Zwei Varianten sind verbreitet, und das RAK7268V2 beherrscht beide.

Der Semtech UDP Packet Forwarder ist der ältere Weg. Das Gateway schickt Pakete per UDP an den Server, typischerweise auf Port 1700, und meldet sich in den Beispielkonfigurationen alle 10 Sekunden mit einem kurzen Lebenszeichen, um Downlinks abzuholen. Das Protokoll ist schlank und wird von nahezu jedem Netzwerkserver verstanden. Es verschlüsselt die Verbindung aber nicht, erkennt das Gateway nur an seiner EUI, und den Frequenzplan musst du im Gateway von Hand passend zum Server einstellen.

LoRa Basics Station ist der modernere Nachfolger. Das Gateway baut eine verschlüsselte WebSocket-Verbindung (WSS) zum Server auf, bei The Things Stack auf Port 8887, und weist sich mit einem Schlüssel oder Zertifikat aus. Den Frequenzplan liefert der Server automatisch. Über den optionalen CUPS-Dienst lassen sich Zugangsdaten und Konfiguration zentral aktualisieren.

Unterstützt dein Server Basics Station, ist sie meist die bessere Wahl, vor allem über Mobilfunk. Den Packet Forwarder brauchst du, wenn der Server nur UDP spricht. Entscheidend ist, dass Modus im Gateway und Einstellung im Server zusammenpassen.

LoRaWAN Gateway mit LTE: Wann brauchst du Mobilfunk statt LAN?

Der beste Empfangsort für deine Sensoren liegt nicht immer neben einer Netzwerkdose. Ein Nebengebäude ohne Datenkabel, eine Baustelle oder ein Technikraum, in den die IT kein Netz legen will: Hier kann ein LoRaWAN Gateway mit SIM-Karte die Lücke schließen. Das Gateway empfängt weiterhin per LoRaWAN, nur der Backhaul zum Server läuft über das Mobilfunknetz. Deine Sensoren bleiben LoRaWAN-Geräte und brauchen selbst keine SIM-Karte.

Im Shop gibt es dafür das Indoor-Modell RAK7268CV2 und die Outdoor-Varianten RAK7289CV2. Beide nutzen ein LTE-Cat-4-Modul; für Europa ist das Quectel EG95-E mit den LTE-Bändern 1, 3, 7, 8, 20 und 28A vorgesehen, die SIM-Karte kommt im Nano-Format. Das äußerlich nahezu identische RAK7268V2 ohne „C“ hat zwar einen SIM-Schacht, aber kein Modem. Achte deshalb auf die vollständige Modellbezeichnung.

Drei Situationen sprechen für LTE: kein geeigneter Festnetzanschluss am Standort, ein zeitlich begrenzter Messaufbau, der nicht auf Netzwerkarbeiten warten soll, und eine Reserveverbindung. Die RAK-Gateways können mehrere WAN-Verbindungen priorisieren und per Ping- oder HTTP-Prüfung auf LTE umschalten, wenn Ethernet ausfällt. Zusätzlich puffern sie Uplinks auf der eingebauten microSD-Karte, wenn die Verbindung abreißt. Wie gut das greift, hängt vom Betriebsmodus ab, und verspätet nachgereichte Werte nützen einem Alarm wenig.

Rechne beim Tarif nicht nur mit den Sensordaten. Schon das Lebenszeichen des Packet Forwarders ergibt bei einem Intervall von 10 Sekunden 8.640 Nachrichten am Tag, dazu kommen Statistikmeldungen, Fernwartung und Firmware-Updates. Miss den Verbrauch deshalb einige Tage im Probebetrieb und plane Reserve ein. Prüfe den Mobilfunkempfang am tatsächlichen Montageort, nicht mit dem Handy vor der Tür. Gibt es dagegen eine stabile LAN-Verbindung, ist Ethernet mit PoE fast immer einfacher und günstiger.

LoRaWAN Gateway mit 8 oder 16 Kanälen: Wie viele Sensoren schafft ein Gateway?

Die Kanalzahl beschreibt, auf wie vielen Frequenzen das Gateway gleichzeitig hört, nicht, wie viele Sensoren es verwalten kann. Ein 8-Kanal-Gateway wie das RAK7268V2 deckt den gängigen EU868-Kanalplan vollständig ab: The Things Network nutzt in Europa genau acht Uplink-Frequenzen zwischen 867,1 und 868,5 MHz. Auf jedem dieser Kanäle empfängt der Konzentrator Pakete mit verschiedenen Spreading Factors parallel.

Wie viele Sensoren das sind, entscheidet vor allem die Funkzeit. Ein Paket mit 12 Byte Nutzdaten ist bei SF7 rund 62 Millisekunden in der Luft, bei SF12 knapp 1,5 Sekunden. 500 Sensoren, die alle 15 Minuten senden, erzeugen 2.000 Pakete pro Stunde. Bei SF7 sind das zusammen gut zwei Minuten Funkzeit pro Stunde, verteilt auf acht Kanäle – völlig entspannt. Senden dieselben Sensoren alle mit SF12, kommen rund 49 Minuten zusammen, und das Risiko von Kollisionen steigt deutlich. Ein 8-Kanal-Gateway verkraftet also mehrere Hundert Sensoren, solange die meisten nah genug für niedrige Spreading Factors sind.

Ein 16-Kanal-Gateway wie das RAK7289V2 oder RAK7289CV2 in der 16-Kanal-Ausführung bringt zwei SX1303-Konzentratoren und zwei LoRa-Antennenanschlüsse mit. Davon profitierst du nur, wenn Netzwerkserver und Sensoren tatsächlich 16 Frequenzen nutzen. Im Standard-EU868-Plan bleiben die zusätzlichen Kanäle ungenutzt. The Things Stack kann bei passenden Gateways zwei Frequenzpläne mit nicht überlappenden Kanälen kombinieren, das muss aber bewusst eingerichtet werden. Mehr Kanäle erhöhen außerdem weder die Reichweite noch die Downlink-Kapazität: Ein Gateway sendet immer nur ein Paket gleichzeitig, und in Europa begrenzt der Duty Cycle die Sendezeit zusätzlich.

Wann lohnen sich 16 Kanäle also? In dichten privaten Netzen mit sehr vielen Sensoren an einem Ort, wenn der Betreiber einen erweiterten Kanalplan fährt. Hast du dagegen Funklöcher in entfernten Gebäudeteilen, hilft ein zweites 8-Kanal-Gateway an anderer Stelle mehr als doppelte Kanäle am alten Standort.

Braucht jeder Sensor ein eigenes LoRaWAN Gateway?

Nein, und das ist einer der großen Vorteile von LoRaWAN. Ein Gateway ist gemeinsame Infrastruktur: Jeder registrierte Sensor in Reichweite kann es nutzen, egal ob Temperaturfühler, Türkontakt oder Zähler. Es gibt keine feste Zuordnung zwischen einem bestimmten Sensor und einem bestimmten Gateway. Ein gut platziertes Gateway versorgt oft ein ganzes Gebäude.

Mehrere Gateways schaden nicht, im Gegenteil. Hören zwei oder drei Gateways denselben Sensor, sorgt die Deduplizierung im Netzwerkserver dafür, dass der Messwert nur einmal ankommt. Fällt ein Gateway aus, übernimmt ein anderes – vorausgesetzt, beide sind im selben Netzwerk registriert und hängen nicht am selben Stromkreis und Internetanschluss.

Die Planung beginnt deshalb bei den Messstellen, nicht bei den Gateways. Wo sitzen die schwierigsten Sensoren, etwa im Keller oder hinter Stahlbeton? Teste von dort aus mit einem echten Gerät über einige Tage und schau dir RSSI und SNR im Netzwerkserver an. Arbeitet ein Sensor dauerhaft mit SF12, ist das ein deutliches Zeichen, dass er am Rand der Abdeckung liegt. Dann ist ein zusätzliches Gateway näher an dieser Stelle meist die bessere Lösung als eine stärkere Antenne.

LoRaWAN Gateway empfängt keine Daten: Woran liegt es?

„Gateway online, aber keine Daten“ ist der häufigste Fehler bei neuen Installationen. Der Online-Status sagt nur, dass das Gateway seinen Server erreicht. Ob Sensorpakete ankommen und weiterverarbeitet werden, sind getrennte Fragen. Geh den Datenweg deshalb in vier Schritten durch.

Erstens der Funk: Zeigt das Live-Log des Gateways überhaupt Pakete des Sensors? Wenn nicht, stimmen eventuell Frequenzband (EU868 statt US915), Aktivierung des Sensors oder Abstand nicht. Ein Sensor direkt neben dem Gateway kann den Empfänger übersteuern; halte ein paar Meter Abstand, am besten mit einer Wand dazwischen.

Zweitens die Weiterleitung: Sendet das Gateway an den richtigen Server, mit korrekter Adresse, korrektem Port und passendem Frequenzplan? Bei UDP muss die Gateway-EUI im Netzwerkserver exakt so registriert sein wie im Gateway eingestellt. Bei Basics Station scheitert die Verbindung häufig an einem fehlenden oder falschen API-Schlüssel.

Drittens der Join: Taucht im Netzwerkserver eine Join-Anfrage auf, aber der Sensor tritt nie bei, stimmen meist DevEUI, JoinEUI oder AppKey nicht. Möglich ist auch, dass die Join-Antwort den Sensor nicht erreicht, weil der Downlink zu schwach ist.

Viertens die Anwendung: Kommen Uplinks im Netzwerkserver an, während dein Dashboard leer bleibt, fehlt häufig der Payload-Decoder, die Integration zeigt auf das falsche Ziel oder die Geräte-ID passt nicht. Verfolge immer ein bekanntes Testgerät mit festem Sendeintervall durch alle vier Stufen.

LoRaWAN Gateway kaufen: Worauf solltest du achten?

Wenn du die Aufgaben des Gateways kennst, schrumpft die Auswahl auf wenige Fragen. Zuerst die Frequenz: In Europa brauchst du ein Gerät für EU868. Dann der Montageort: Indoor-Gateways wie das RAK7268V2 haben Schutzart IP30 und gehören in trockene Räume, für Mast oder Fassade brauchst du ein Outdoor-Gehäuse wie beim RAK7289V2 mit IP67. Danach der Backhaul: Ethernet mit PoE, wo ein Kabel liegt, LTE dort, wo keins liegt oder eine Reserve gebraucht wird. Kläre außerdem, wo dein Netzwerkserver laufen soll – im Gateway, selbst betrieben oder in der Cloud – und ob das Gateway das passende Protokoll beherrscht. Die Kanalzahl ist meist die letzte Frage: Acht Kanäle reichen für den Standard-EU868-Plan, 16 lohnen sich nur mit erweitertem Kanalplan und hoher Gerätedichte.

Wenn du ein passendes LoRaWAN Gateway suchst, findest du unsere Modelle in der Kategorie LoRaWAN Gateways.

FAQ zu LoRaWAN Gateways

Wie weit reicht ein LoRaWAN Gateway?

Das hängt stärker von Montagehöhe und Umgebung ab als vom Gerät. In bebautem Gebiet sind mit einem gut platzierten Gateway einige Kilometer üblich, auf freiem Land mit erhöhter Antenne auch deutlich mehr. Ein Indoor-Gateway im Erdgeschoss versorgt dagegen oft nur das eigene Gebäude und die nähere Umgebung. Ein Test mit echten Sensoren am geplanten Standort ersetzt jede Faustformel.

Brauche ich ein Outdoor LoRaWAN Gateway?

Nur wenn das Gateway draußen hängen soll, etwa an einem Mast oder einer Fassade, um ein Gelände oder mehrere Gebäude abzudecken. Dafür brauchst du ein wetterfestes Gehäuse wie das IP67-Gehäuse des RAK7289V2, das außerdem Überspannungsschutz am PoE-Eingang und einen Erdungspunkt mitbringt. Für die Versorgung eines Gebäudes von innen reicht ein Indoor-Gateway; es wird aber nicht wetterfest, nur weil sein Funksignal bis nach draußen reicht.

Kann ein LoRaWAN Gateway per WLAN angebunden werden?

Ja, viele Modelle verbinden sich als WLAN-Client mit deinem Netz, darunter das RAK7268V2 mit 2,4-GHz-WLAN. Für den Dauerbetrieb ist Ethernet meist zuverlässiger, weil WLAN-Verbindungen bei Router-Neustarts oder Passwortwechseln abreißen können. Praktisch ist das WLAN bei der Ersteinrichtung: Im Auslieferungszustand öffnet das Gateway einen eigenen Access Point für die Konfiguration.