Planung eines LoRaWAN-Netzes: vom Pilotprojekt bis zur Skalierung auf Stadtniveau

Der Pilot beginnt mit Datenanforderungen und SLA

Bevor die Platzierung von Gateways geplant wird, ist es wichtig, im Voraus festzulegen, welche Daten das Netz übertragen soll und in welchem Modus. Selbst in Messprojekten können sich die Übertragungsprofile deutlich unterscheiden: In einigen Fällen reichen 1–2 Nachrichten pro 24 Stunden aus, in anderen ist eine ereignisbasierte Übertragung erforderlich (zum Beispiel bei Eingriffen oder Störungen), und in wieder anderen Fällen ist ein regelmäßiger Downlink für die Fernkonfiguration oder Bestätigungen notwendig. Wenn diese Parameter nicht festgelegt werden, ist der Pilot in der Regel zu allgemein ausgelegt und lässt sich später nur schwer auf Stadtniveau skalieren.

In dieser Phase ist es sinnvoll, die Anforderungen in drei Ebenen zu unterteilen:

Datenanforderungen: Übertragungsfrequenz, zulässige Latenz, Verlustanteil, Verhalten bei vorübergehendem Verbindungsverlust (Pufferung/Wiederholung).

Betriebsanforderungen: Reaktionszeit auf Degradation, Wartungsfenster, angestrebte Verfügbarkeit nach Gebieten.

Sicherheitsanforderungen: Schlüsselmanagement, Zugriffskontrolle, Auditierung, Segmentierung.

Aus diesen Anforderungen ergeben sich später die ADR-Regeln, die Bestätigungspolitik und die Prinzipien für die Platzierung der Infrastruktur.

Der Pilot als technische Validierung der Funkumgebung, nicht als Demonstration der Konnektivität

Piloten werden häufig in „bequemen“ Gebieten durchgeführt, in denen alles im Voraus vorhersehbar ist. Ein solcher Pilot zeigt, dass die Technologie grundsätzlich funktioniert, zeigt jedoch nicht, wie sich das Netz in problematischen Bereichen verhält. Für ein Projekt, das auf Stadtniveau skaliert werden soll, muss der Pilot unterschiedliche Funkumgebungen umfassen: dichte Bebauung, unterirdische Bereiche, Abschirmung durch Metall sowie verteilte Standorte.

Im Pilotprojekt ist es wichtig, diagnostische Metriken zu erfassen und in einem Monitoringsystem zu speichern, da die Skalierung sonst zum Ratespiel wird. Neben der reinen Paketübertragung werden in der Regel RSSI/SNR, die Verteilung von Data Rate (DR) und Spreading Factor (SF), der Anteil von Verlusten und die Ursachen für Wiederholungen sowie die tatsächliche Airtime analysiert.

Ein gesondertes Thema ist ADR (Adaptive Data Rate). Dabei handelt es sich um einen Mechanismus zur Optimierung von Datenrate, Sendezeit im Funkkanal und Energieverbrauch, der die Übertragungsparameter (Spreading Factor, Bandbreite, Sendeleistung) steuert. Im Pilot sollte ADR bewusst eingesetzt werden: Es ist besonders für stationäre Geräte nützlich und hilft, die Funklast zu reduzieren, ohne die Zuverlässigkeit zu beeinträchtigen. Wird ADR im Pilot nicht getestet, kann das Netz mit zunehmender Geräteanzahl aufgrund ineffizienter Nutzung des Funkkanals degradieren.

Platzierung der ersten Gateways: Abdeckung, Kapazität und Reproduzierbarkeit

In städtischen Projekten zeigen sich Fehler bei der Gateway-Platzierung oft erst später. Im Pilot „funktioniert alles“, doch nach der Erweiterung entstehen Bereiche mit instabiler Verbindung, die Anzahl der Wiederholungen steigt und die Last konzentriert sich auf einzelne Gateways. Um dies zu vermeiden, werden bei der Platzierung der ersten Gateways in der Regel zwei Aspekte gleichzeitig berücksichtigt:

Abdeckung: Zunächst wird eine Grundschicht des Netzes durch Gateways aufgebaut, die an Standorten mit guten Funkbedingungen installiert sind: ausreichende Höhe, freie Sicht und minimale Abschirmung. Anschließend werden auf Basis von Messungen und Qualitätsmetriken gezielt Lösungen für Bereiche mit dauerhaften Abdeckungslücken ergänzt.

Kapazität: Selbst bei scheinbar ausreichender Abdeckung ist es wichtig zu bewerten, ob das Netz die zukünftige Verkehrslast bewältigen kann. In der Praxis bedeutet dies die Kontrolle der Airtime, eine sorgfältige Bestätigungspolitik zur Vermeidung unnötigen Downlinks sowie eine korrekt konfigurierte ADR, die hilft, die Netzlast zu reduzieren, ohne die Zuverlässigkeit zu beeinträchtigen.

Auf Stadtniveau kommt zusätzlich die Anforderung der Reproduzierbarkeit hinzu: Wenn ein Pilot-Gateway „einzigartig“ ist (besondere Installations-, Verbindungs- oder Stromversorgungsbedingungen), wird es schwierig und teuer, ein solches Setup mehrfach zu reproduzieren. Daher ist es sinnvoll, bereits im Pilot standardisierte Installationsvarianten festzulegen.

Konnektivität und Verfügbarkeit: Das Netz beginnt jenseits des Funkkanals

Die LoRaWAN-Konnektivität endet nicht am Gateway. Für einen stabilen Betrieb sind drei Dinge entscheidend: die Internetanbindung der Gateways, deren Zuverlässigkeit und klare Wiederherstellungsprozesse im Fehlerfall. Zusätzlich sind grundlegende Sicherheitsmaßnahmen erforderlich: Netzsegmentierung, gesicherte Kommunikationskanäle und Zugriffskontrolle für die Gateway-Administration.

Internetanbindung der Gateways. Das Gateway muss empfangene Funkpakete zuverlässig an die Serverkomponenten weiterleiten. Daher ist es wichtig, im Voraus festzulegen, welche Art der Anbindung verwendet wird (kabelgebunden, LTE usw.), welches Verfügbarkeitsniveau erforderlich ist und wie die Diagnose organisiert wird: Was gilt als Vorfall, wer reagiert darauf und wie viel Zeit für die Wiederherstellung vorgesehen ist.

Situationen, in denen das Problem nicht im Funk, sondern in fehlender Internetanbindung liegt. Manchmal entstehen Schwierigkeiten nicht durch die Funkabdeckung, sondern dadurch, dass es an bestimmten Standorten unmöglich oder zu teuer ist, eine direkte Internetverbindung bereitzustellen. In solchen Fällen werden Architekturen betrachtet, bei denen nicht jedes Gateway direkt mit dem Internet verbunden ist.

Eine Möglichkeit ist eine Gateway-Mesh-Architektur:

• ein Border-Gateway verfügt über eine Internetverbindung und ist mit dem Netzwerkserver verbunden
• Relay-Gateways leiten den Datenverkehr über ein lokales Mesh-Netzwerk an das Border Gateway weiter

Eine Mesh-Architektur ersetzt die Internetanbindung nicht als solche. Sie hilft in komplexen Umgebungen, in denen es einfacher ist, Daten zu einem Punkt mit Internetzugang zu transportieren, als an jedem Standort eine eigene Verbindung bereitzustellen.

Core und Observability: Was erforderlich ist, damit das Netz kein „Black Box“ wird

Der Übergang vom Pilot zur Einführung auf Bezirksebene zeigt in der Regel das Hauptproblem: Das Netz wird komplexer, und ohne Observability (ein System, das es ermöglicht, anhand von Metriken und Ereignissen den Zustand des Netzes und die Ursachen von Abweichungen zu verstehen) ist es schwierig, lokale Vorfälle von systemischer Degradation zu unterscheiden. Daher ist es sinnvoll, bereits im Pilot eine grundlegende Observability-Schicht aufzubauen: Metriken für Gateways und Geräte, konfigurierte Alarme, sowie verständliche Berichte zur Abdeckungsqualität.

In der Praxis bedeutet dies, dass die Plattform dem Betriebsteam Antworten liefern sollte, ohne dass eine langwierige manuelle Analyse von Logs und Daten erforderlich ist. Sie sollte beispielsweise anzeigen, in welchen Gebieten sich die Funkqualität verschlechtert hat, also wo sich typische Empfangswerte (SNR/RSSI) verschlechtert haben, wo der Anteil von Verlusten oder Wiederholungen gestiegen ist und wo sich dadurch Verzögerungen oder Nachrichtenverluste erhöht haben. Darüber hinaus sollte die Plattform helfen, instabile Gateways schnell zu identifizieren (in Bezug auf Verfügbarkeit und Verbindungsqualität zur Serverinfrastruktur) sowie Gerätegruppen, die häufiger als andere die Verbindung verlieren oder in weniger effiziente Übertragungsmodi wechseln. Auf Stadtniveau ermöglicht genau eine solche Monitoring- und Reporting-Schicht die Steuerung des Netzes anhand klarer Metriken und die Sicherstellung einer stabilen Servicequalität.

Skalierung: Bezirksmodell und Kapazitätsmanagement

Die Skalierung erfolgt in der Regel in Wellen: Pilot – erster Bezirk – mehrere Bezirke – Stadt. In jeder Phase ist es wichtig, einheitliche Standards beizubehalten, da ansonsten Infrastruktur und Geräte nach unterschiedlichen Regeln betrieben werden, was den Betrieb erheblich erschwert.

Aus technischer Sicht wird das Netz auf Stadtniveau meist durch die Kapazität des Funkkanals und durch das Übertragungsverhalten der Geräte begrenzt. Daher muss das Projektteam im Voraus das Datenübertragungsprofil definieren: die Sendehäufigkeit festlegen, die Datenmenge pro Nachricht bestimmen, Fälle für Bestätigungen definieren und den zusätzlichen Downlink-Verkehr bewerten.

Zudem ist eine korrekte Konfiguration von ADR entscheidend, da sie hilft, die Airtime zu reduzieren und gleichzeitig die Zuverlässigkeit zu erhalten.

Jooby-Produkte: Lösungen für jede Skalierungsstufe

Bei der Skalierung eines LoRaWAN-Projekts ist es vorteilhaft, wenn Hardware und Software den gesamten Lebenszyklus unterstützen — vom Pilot bis zum Stadtniveau. Typischerweise werden Lösungen auf mehreren Ebenen benötigt:

Geräteebene (Endgeräte): Funkmodule, Sensoren und Messlösungen, die hinsichtlich Installation und Datenprofil standardisiert werden können. Dies gewährleistet Reproduzierbarkeit bei wachsender Geräteanzahl.

Infrastrukturebene: Basisstationen/Gateways für den Aufbau des Netzes auf Standort-, Bezirks- und Stadtebene, mit der Möglichkeit zur Vereinheitlichung von Konfigurationen und Betriebsprozessen.

Plattformebene: Zentrales Monitoring von Netz und Geräten, Kontrolle der Verbindungsqualität, Datenerfassung sowie Integration in Billing-/SCADA-/IoT-Plattformen.

Das Portfolio von Jooby umfasst Geräte für die Feldebene, Infrastrukturkomponenten für den Aufbau eines LoRaWAN-Netzes sowie Software. Dadurch kann das Projekt schrittweise umgesetzt werden, ohne die Architektur bei jeder Erweiterung ändern zu müssen.

Ein LoRaWAN-Netz auf Stadtniveau unterscheidet sich vom Pilot dadurch, dass Standards, Observability und Kapazitätsmanagement entscheidend sind. Der Pilot muss eine technische Validierung der realen Funkumgebung sein und keine Demonstration unter idealen Bedingungen. Die Skalierung erfordert einen stabilen Backhaul sowie ein Betriebsmodell, das eine qualitätsbasierte Steuerung nach Bezirken ermöglicht. ADR und Verkehrspolitik werden zu zentralen Instrumenten zur Sicherung der Kapazität und der Batterielaufzeit der Geräte. Für komplexe Standorte mit eingeschränktem Internetzugang können Relay-/Mesh-Architekturen als eigenständiges Instrument zur Netzwerterweiterung eingesetzt werden.