Privates LoRaWAN-Netzwerk aufbauen: Komponenten, Hardware und Schritte mit ChirpStack

WZ-IT führt chirphost weiter. Aktuelles Hosting ab 129,90 € netto/Monat; Einrichtung und Service Level gemäß Angebot. Frühere Paketpreise, Standortlisten und Kostenvergleiche in diesem datierten Artikel beschreiben das damalige Angebot, nicht die aktuellen WZ-IT-Konditionen. Aktuellen Leistungsumfang ansehen.

Wer Sensordaten über große Distanzen und mit minimalem Stromverbrauch sammeln will, kommt an LoRaWAN kaum vorbei. Das Funkprotokoll überbrückt im freien Gelände mehrere Kilometer, lässt Batteriesensoren jahrelang laufen und eignet sich für alles von der Bodenfeuchtemessung über Asset Tracking bis zur Füllstandüberwachung in der Industrie. Die zentrale Frage beim Aufbau lautet aber nicht nur „welche Sensoren", sondern: öffentliches oder privates Netz?

Öffentliche Netze wie The Things Network sind ideal für erste Experimente. Sobald jedoch proprietäre oder personenbeziehbare Daten im Spiel sind oder eine größere Sensorflotte betrieben wird, sprechen Datenhoheit, Kostenstruktur und Unabhängigkeit klar für ein eigenes, privates Netz. Genau hier kommt ChirpStack ins Spiel – der weltweit verbreitetste quelloffene LoRaWAN-Network-Server, der die Funktionen eines Telekommunikationsbetreibers auf dem eigenen Server bereitstellt, ohne Lizenzkosten pro Gerät. Dieser Beitrag erklärt die Komponenten eines privaten LoRaWAN-Netzes, hilft bei der Hardware-Auswahl und führt durch die Schritte des ChirpStack-Setups – inklusive der ehrlichen Stolpersteine im Praxisbetrieb.

Auch interessant: ChirpStack vs. The Things Stack · ChirpStack Hosting: Managed vs. Self-Hosted

Was LoRaWAN ist und wofür es sich eignet

LoRaWAN steht für Long Range Wide Area Network und ist ein Funkprotokoll für das Internet der Dinge. Es ist darauf optimiert, kleine Datenmengen über große Distanzen bei sehr geringem Energieverbrauch zu übertragen. Ein typischer LoRaWAN-Sensor sendet alle paar Minuten ein paar Bytes – einen Messwert, einen Zählerstand, eine Statusmeldung – und läuft dabei jahrelang auf einer einzigen Batterie.

Diese Eigenschaften machen LoRaWAN zur ersten Wahl für Anwendungen, bei denen Mobilfunk zu teuer oder zu stromhungrig und WLAN zu kurzreichweitig wäre: Smart Metering bei Wasser- und Wärmeversorgern, Umwelt- und Maschinensensorik in der Industrie, Bodenfeuchte- und Wetterstationen in der Landwirtschaft, Belegungs- und Luftqualitätssensoren im Smart Building, Pegel- und Parkraummessung in Kommunen.

LoRaWAN kennt drei Geräteklassen. Class A ist der stromsparende Standard: Auf jeden Uplink folgen zwei kurze Empfangsfenster, sonst schläft das Gerät. Class B ergänzt geplante Downlink-Fenster zu festen Zeiten, Class C hält den Empfänger kontinuierlich offen – schneller erreichbar, aber energiehungriger. In Europa und damit im DACH-Raum arbeitet LoRaWAN im lizenzfreien Frequenzband EU868. Lizenzfrei bedeutet: Es ist kein Frequenzantrag nötig. Allerdings gilt eine Sendezeit-Beschränkung (Duty Cycle), die die maximale Nachrichtenfrequenz pro Gerät begrenzt – ein Punkt, der bei dichten Netzen relevant wird.

Privat oder öffentlich? Wann sich ein eigenes Netz lohnt

Öffentliche LoRaWAN-Netze wie The Things Network sind kostenlos, schnell verfügbar und hervorragend zum Testen. Für den produktiven Unternehmenseinsatz sprechen jedoch drei Gründe für ein privates Netz:

• Data Sovereignty: In einem privaten Netz spricht das Gateway ausschließlich mit dem eigenen Server. Die Daten verlassen nie die eigene Infrastruktur – relevant für DSGVO, Sicherheitsregularien und Geschäftsgeheimnisse.
• Kostenstruktur: Kommerzielle LoRaWAN-Plattformen rechnen häufig pro Gerät und Monat ab. Bei tausenden Sensoren skaliert dieses Abo-Modell unangenehm. Ein eigenes Netz hat nach der einmaligen Gateway-Investition bei Self-Hosting keine Per-Device-Software-Kosten.
• Kontrolle und Unabhängigkeit: Keine Abhängigkeit von Verfügbarkeit oder Geschäftsentscheidungen eines Drittanbieters.

Ehrlich bleibt: Für Experimente, Prototypen oder Projekte mit wenigen Sensoren in einer Region mit guter TTN-Abdeckung ist ein öffentliches Netz völlig ausreichend – und der schnellste Start. Die Verschiebung zum privaten Netz lohnt sich bei produktiven, datensensiblen oder großen Deployments. Wer bereits Geräte im öffentlichen Netz betreibt, muss dafür nicht bei null anfangen: Wie sich eine bestehende Flotte von TTN zu ChirpStack migrieren lässt, zeigt der zugehörige Guide. Den direkten Architektur-Vergleich liefert ChirpStack vs. The Things Stack.

Die Komponenten eines privaten LoRaWAN-Netzes

Ein privates LoRaWAN-Netz besteht aus wenigen, klar abgegrenzten Bausteinen:

Der Datenfluss in einem Satz: Sensor sendet verschlüsseltes Funkpaket → Gateway empfängt und leitet als UDP weiter → Gateway Bridge wandelt in MQTT → ChirpStack authentifiziert, dedupliziert und dekodiert → Integration leitet die Nutzdaten an die Zielanwendung.

ChirpStack hat sich für den Network-Server-Layer als De-facto-Standard etabliert, weil es Open Source ist, ein Web-Interface zur Verwaltung von Gateways, Geräten und Mandanten mitbringt und sich über eine gRPC-API erweitern lässt. Seit ChirpStack v4 sind Network Server und Application Server zu einem einzigen Dienst zusammengefasst, konfiguriert über eine zentrale chirpstack.toml plus region-spezifische region_*.toml – das vereinfacht den Betrieb gegenüber der getrennten v3-Architektur deutlich.

Hardware auswählen

Gateways

Das Gateway ist die wichtigste Hardware-Entscheidung. Für Indoor-Anwendungen oder kleine Pilotprojekte reicht ein 8-Kanal-Gateway von Herstellern wie RAK Wireless (z. B. RAK7268) oder Dragino. Für Outdoor-Abdeckung, industrielle Umgebungen oder größere Flächen sind robustere Geräte von Kerlink, Multitech oder Robustel sinnvoll – oft mit LTE-Backhaul für Standorte ohne Festnetzanschluss. Entscheidend ist das korrekte Frequenzband (in DACH EU868) und die Antennenposition: Sie beeinflusst die Reichweite stärker als die Gateway-Marke.

Sensoren

Die Sensoren richten sich nach dem Use Case – Temperatur, Luftqualität, Füllstand, Bodenfeuchte, Tracking, Zählerstände. Verbreitete EU868-Hersteller sind Dragino, Milesight und Elsys. Wichtig ist, dass die Sensoren LoRaWAN-zertifiziert sind und einen passenden Payload-Codec mitbringen oder dokumentieren, damit ChirpStack die Rohdaten dekodieren kann.

Server-Anforderungen

ChirpStack selbst ist genügsam. Der Stack läuft als Docker-Compose-Setup aus ChirpStack, PostgreSQL, Redis und einem MQTT-Broker (z. B. Mosquitto). Für ein Pilot- oder kleines Produktivnetz reicht ein kleiner Server. Mit wachsender Geräteflotte werden Datenbank-Dimensionierung und MQTT-Broker-Tuning relevant.

ChirpStack einrichten – die Schritte im Überblick

Das folgende ist eine Architektur-Roadmap, kein vollständiges Tutorial – sie zeigt die Reihenfolge der Schritte vom leeren Server zum ersten empfangenen Sensorwert:

1. ChirpStack deployen – Docker-Compose-Stack aus ChirpStack, PostgreSQL, Redis und Mosquitto starten. In chirpstack.toml die Region EU868 aktivieren und in der zugehörigen region_eu868.toml die Parameter inklusive net_id hinterlegen.
2. Gateway konfigurieren – Packet Forwarder oder ChirpStack Gateway Bridge auf dem Gateway einrichten, Ziel ist der MQTT-Broker des Servers. Optional Mutual TLS mit per-Gateway-Client-Zertifikaten.
3. Gateway registrieren – die Gateway-EUI im ChirpStack-Web-Interface anlegen.
4. Device Profile erstellen – LoRaWAN-Version, Regional Parameters und Geräteklasse (A/B/C) festlegen.
5. Sensoren hinzufügen – DevEUI und AppKey eintragen, Payload-Codec hinterlegen.
6. Join-Procedure – der Sensor führt den OTAA-Join durch und erscheint im Live-Frame-Log.
7. Integration einrichten – PostgreSQL, MQTT, Grafana oder ThingsBoard für die Datenweiterleitung anbinden.

Spätestens beim Live-Frame-Log zeigt sich, ob Gateway, Bridge, Broker und Server korrekt zusammenspielen – der häufigste Punkt, an dem in der Praxis Fehler sichtbar werden.

Die Caveats im Praxisbetrieb

Ein privates Netz ist kein „Set and forget". Diese Punkte gehören realistisch eingeplant:

• Duty Cycle: EU868 ist lizenzfrei, unterliegt aber einer Sendezeit-Beschränkung (typisch 1 % pro Sub-Band). Das limitiert die Nachrichtenfrequenz pro Gerät – relevant bei dichten Deployments.
• Gateway-Platzierung: Die Reichweite hängt massiv von Antennenposition und Umgebung ab. Ein Indoor-Gateway deckt nicht das ab, was ein Outdoor-Gateway mit hoher Antenne leistet.
• Konfigurations-Komplexität: Das Zusammenspiel von Packet Forwarder, Gateway Bridge, MQTT-Broker und Network Server ist fehleranfällig und teils schlecht dokumentiert. Hier geht in der Praxis die meiste Zeit verloren.
• Skalierung: Bei wachsender Flotte werden Datenbank-Tuning, MQTT-Broker-Dimensionierung und Backup-Strategie zur Daueraufgabe.
• Monitoring: Gateway-Erreichbarkeit, Paketverlust und Batteriestände der Sensoren wollen überwacht werden, sonst fällt ein Ausfall erst auf, wenn Daten fehlen.

Self-Hosted oder Managed?

Self-Hosting von ChirpStack gibt volle Kontrolle und verursacht keine laufenden Lizenzkosten – ist aber genau der Betriebsaufwand aus dem vorigen Abschnitt: Server, MQTT-Broker, Datenbank, Backups, Updates, Monitoring und Skalierung. Für ein kleines Pilotprojekt mit technischem Team ist das völlig legitim.

Eine Managed-Lösung nimmt diese Betriebslast ab und liefert einen einsatzbereiten Network Server. Sie kümmern sich dann nur noch um Gateways und Sensoren. Sinnvoll ist das, wenn kein dediziertes Team für den Dauerbetrieb da ist oder das Netz produktiv und geschäftskritisch läuft. Die ehrliche Abwägung mit konkreten Kriterien liefert ChirpStack Hosting: Managed vs. Self-Hosted; wie sich ChirpStack gegenüber einer kommerziellen Enterprise-Plattform schlägt, zeigt ChirpStack vs. Actility ThingPark.

Wie der Managed-Weg konkret aussieht, zeigt Managed ChirpStack Hosting in deutschen Rechenzentren: dedizierte Instanz, MQTT-Broker, Backups und Updates inklusive.

Data Sovereignty und Compliance

Der stärkste Grund für ein privates Netz im DACH-Markt ist die Datenhoheit. LoRaWAN verschlüsselt die Funkübertragung standardmäßig mit AES-128 auf Netzwerk- und Anwendungsschicht – die Übertragung ist also abgesichert. Die eigentliche Compliance-Frage ist, wohin die Daten danach fließen:

• DSGVO: Erfassen Sensoren personenbeziehbare Daten (z. B. Belegungs- oder Tracking-Sensoren), greift die DSGVO. Ein privates Netz hält die Daten in der eigenen Infrastruktur – sauberer für die Datenschutz-Dokumentation als ein US-Cloud-LNS.
• EU Data Act: Wem die Sensordaten eines vernetzten Produkts gehören und in welchem Format sie zugänglich sein müssen, regelt der EU Data Act für LoRaWAN-Sensordaten – mit der Designpflicht ab dem 12. September 2026 für neu in Verkehr gebrachte Produkte.
• Bundesnetzagentur: Die EU868-Duty-Cycle-Regeln sind einzuhalten.
• NIS2: In KRITIS-relevanten Sektoren (Energie, Wasser) fallen IoT-Netze unter die Sicherheitsanforderungen – Verschlüsselung und Zugriffskontrolle sind dokumentationspflichtig.

Bei einem deutschen Managed-Anbieter bleibt zusätzlich der Network Server selbst in EU-souveräner Infrastruktur – die gesamte Kette vom Sensor über das Gateway bis zum Server liegt damit im eigenen Verantwortungsbereich.

Hinweis: Kein Rechtsrat. Bei konkreten Compliance-Fragen sollten Datenschutz- und Rechtsberatung hinzugezogen werden.

Neuer Beitrag: Für Gebäudeeigentümer läuft am 31.12.2026 eine Frist ab: fernablesbare Zähler nach der Heizkostenverordnung und wo LoRaWAN dabei trägt.

Fazit

Ein privates LoRaWAN-Netz ist kein Hexenwerk, aber auch kein Plug-and-Play: Mit Sensoren, Gateway, Gateway Bridge, ChirpStack als Network Server und einer Integration steht die Architektur – die Stolpersteine liegen in der Konfiguration der Komponenten, der Gateway-Platzierung und dem laufenden Betrieb. Wer Datenhoheit, planbare Kosten ohne Per-Device-Abo und volle Kontrolle will, ist mit einem eigenen Netz auf ChirpStack-Basis goldrichtig.

Managed ChirpStack von chirphost nimmt Ihnen den anspruchsvollsten Teil ab – den Betrieb des Network-Server-Layers:

• ✓ ChirpStack v4 betriebsbereit, ohne Konfigurations-Stolpersteine
• ✓ PostgreSQL, MQTT-Broker, Backups, Updates und Monitoring inklusive
• ✓ Network Server in deutscher Infrastruktur (Data Sovereignty)
• ✓ Keine Per-Device-Software-Kosten Leistungsumfang und Bereitstellung mit WZ-IT abstimmen. Bereitstellung und Vertragsbedingungen werden mit WZ-IT im Angebot vereinbart. Es gibt kein Self-Service-Portal und kein automatisches Testabonnement.

Was die Pläne kosten und ab welcher Flottengröße welcher Plan passt, steht bei den Preisen für Managed ChirpStack.

Leistungsumfang und Bereitstellung mit WZ-IT abstimmen. Bereitstellung und Vertragsbedingungen werden mit WZ-IT im Angebot vereinbart. Es gibt kein Self-Service-Portal und kein automatisches Testabonnement.

Wer die Netzebene nicht selbst betreiben will, findet Leistungsumfang, SLA und die acht Regionen auf der Seite LoRaWAN Network Server mieten.

Lesetipp: ChirpStack vs. The Things Stack und ChirpStack Hosting: Managed vs. Self-Hosted.

Quellen

• ChirpStack – offizielle Website
• ChirpStack – Architecture-Dokumentation
• ChirpStack – Gateway Configuration
• ChirpStack GitHub Repository
• Robustel – Build a Private LoRaWAN Network with ChirpStack
• prbs23 – Getting Started With a Private LoRaWAN Network Using ChirpStack v4
• LoRa Alliance – Regional Parameters (RP002, EU868)