Sie haben sich für LoRaWAN entschieden, wegen der Reichweite und der Batterielaufzeit. Richtig so. Jetzt steht eine zweite Entscheidung an, die genauso wichtig ist, und die die meisten Teams überstürzen: Wer betreibt das Netzwerk, mit dem Ihre Geräte sprechen?
Es gibt drei Antworten. Sie können einem öffentlichen Community-Netzwerk wie The Things Network beitreten. Sie können ein dezentrales Abdeckungsnetzwerk wie Helium nutzen. Oder Sie betreiben eigene Gateways mit einem Network Server wie The Things Stack oder ChirpStack. Jedes davon transportiert dieselben LoRaWAN-Pakete. Was sich unterscheidet, ist: Wer kontrolliert die Abdeckung, wer garantiert die Verfügbarkeit, wer sieht Ihren Datenverkehr und wer zahlt wofür.
Dieser Leitfaden geht die drei Modelle durch, die Abwägungen zwischen ihnen und wann welches die richtige Wahl ist. Am Ende verknüpft er die Entscheidung über den Network Server mit der Schicht darüber, denn das ist der Teil, den Teams vergessen, bis die Daten fließen und niemand entschieden hat, wohin damit.
Die drei Modelle, klar erklärt
Öffentliches Community-Netzwerk. The Things Network ist das bekannteste Beispiel. Es ist ein gemeinsam genutztes, von der Community betriebenes LoRaWAN-Netzwerk. Jeder kann ein Gateway aufstellen und es zur öffentlichen Abdeckungskarte hinzufügen, und jeder kann Geräte registrieren und das Netzwerk im Rahmen von Fair-Use-Grenzen kostenlos nutzen. Die Infrastruktur gehört demjenigen, der das nächste Gateway aufgestellt hat: vielleicht Sie selbst, vielleicht ein Bastler drei Straßen weiter, vielleicht niemand.
Dezentrales Abdeckungsnetzwerk. Helium ist hier der bekannte Fall. Gateway-Betreiber werden über einen Token-Anreiz dafür bezahlt, Abdeckung bereitzustellen, was die Karte schneller wachsen lassen soll als ein rein ehrenamtliches Modell. Aus Sicht der Geräte verhält es sich weiterhin wie ein öffentliches Netzwerk: Die Gateways gehören Ihnen nicht, und Ihr Datenverkehr hängt von der Abdeckung ab, die andere Leute betreiben wollen.
Privates Netzwerk. Sie kaufen und platzieren Ihre eigenen Gateways und richten sie auf einen Network Server aus, den Sie selbst kontrollieren. Dieser Server ist meist The Things Stack oder ChirpStack. Die Abdeckung gehört Ihnen, die Verfügbarkeit liegt in Ihrer Verantwortung, und die Daten durchlaufen niemals fremde Infrastruktur. Im Gegenzug tragen Sie die Hardwarekosten und den Betriebsaufwand.
Was der Network Server eigentlich tut
Vor den Abwägungen ein Stück Vokabular, über das viele stolpern. Der LoRaWAN Network Server ist das Gehirn zwischen Ihren Gateways und Ihren Daten. Er entfernt doppelte Pakete, die über mehrere Gateways ankamen, prüft die Sicherheitsschlüssel des Geräts, verarbeitet Join-Anfragen, verwaltet die Datenraten und leitet dann die entschlüsselte Nutzlast weiter.
The Things Stack und ChirpStack sind beides Network Server. Der Unterschied zwischen öffentlichem und privatem LoRaWAN läuft oft darauf hinaus, wer diesen Server betreibt. Bei The Things Network betreibt die Community The Things Stack für Sie. In einem privaten Netzwerk betreiben Sie The Things Stack oder ChirpStack selbst, auf Ihrer eigenen Hardware oder in Ihrem eigenen Cloud-Konto.
Das ist wichtig für den nächsten Abschnitt, und es ist sehr wichtig für den späteren Teil über Application-Plattformen.
Die Abwägungen, die entscheiden
Sechs Faktoren trennen die drei Modelle. Kein Modell gewinnt in allen sechs.
Abdeckung. Öffentliche und dezentrale Netzwerke geben Ihnen Abdeckung, die Sie nicht selbst aufgebaut haben, dort wo sie existiert. In einer dichten Stadt erreicht The Things Network oder Helium Ihren Standort vielleicht schon. Auf einem ländlichen Feld, in einem Keller oder auf einem privaten Industriegelände ist diese Abdeckung dünn oder gar nicht vorhanden, und Sie können Community-Gateways nicht durch reines Wünschen herbeizaubern. Ein privates Netzwerk gibt Ihnen Abdeckung genau dort, wo Sie ein Gateway aufstellen, und sonst nirgends.
Kontrolle. In einem privaten Netzwerk legen Sie den Kanalplan fest, die Platzierung der Gateways, die Datenraten-Strategie und den Update-Zeitplan. In einem öffentlichen oder dezentralen Netzwerk nehmen Sie, was da ist. Wenn ein Community-Gateway in Ihrer Nähe ausfällt, ist das nicht Ihr Gateway, das Sie reparieren können.
Zuverlässigkeit. Ein Gateway, das Ihnen gehört und das Sie überwachen, ist ein Gateway, das Sie zur Rechenschaft ziehen können. Community- und dezentrale Gateways können ohne Vorwarnung kommen und gehen, weil die Leute, die sie betreiben, Ihnen nichts schulden. Für ein Hobbyprojekt ist das in Ordnung. Für einen Produktivstandort ist es ein Risiko, das Sie einpreisen müssen.
Sicherheit. LoRaWAN verschlüsselt Nutzlasten Ende zu Ende, unabhängig davon, welches Modell Sie verwenden, die Funkstrecke ist also nicht die Sorge. Der Unterschied ist betrieblicher Natur: In einem privaten Netzwerk bleiben Ihre Join-Server, Ihre Schlüssel und Ihr Datenverkehr innerhalb einer Infrastruktur, die Sie kontrollieren. Bei regulierten Vorhaben ist diese Grenze oft schon allein das ausschlaggebende Argument.
Kosten. Öffentliche Community-Netzwerke kosten im Rahmen des Fair-Use nichts pro Nachricht, was für kleine oder frühe Projekte kaum zu schlagen ist. Dezentrale Netzwerke verursachen meist Kosten pro Paket oder über Datenguthaben. Ein privates Netzwerk hat die umgekehrte Kostenform: echtes Geld im Voraus für Gateways und Einrichtung, danach nahezu keine Kosten pro Nachricht. Bei einem dichten Einsatz mit vielen Geräten an einem Standort gewinnt das private Modell über die Lebensdauer der Geräte oft bei den Gesamtkosten, auch wenn es am ersten Tag teurer aussieht.
SLA. Das ist der kurze Punkt. Community- und dezentrale Netzwerke kommen ohne Service-Level-Agreement. Niemand verspricht Ihnen Verfügbarkeit. Ein privates Netzwerk hat genau die SLA, die Sie aufbauen und betreiben, was bedeutet, dass Sie sowohl das Versprechen als auch die Arbeit besitzen, es zu halten.
Wann welches Modell passt
Gehen Sie von der Aufgabe aus, nicht vom Netzwerk.
Hobby, Prototyping und Proof of Concept. Wenn Sie testen, ob LoRaWAN überhaupt zu Ihrer Idee passt, treten Sie The Things Network bei. Kostenlos, schnell zu starten, keine Hardware-Verpflichtung, wenn die Abdeckung Sie bereits erreicht. Helium passt in eine ähnliche frühe Phase, wenn Sie breitere Abdeckung wollen und geringe Kosten pro Paket akzeptieren. Stellen Sie keinen eigenen Server auf, um hundert Testnachrichten zu senden.
Produktive Einsätze. Sobald Geräte im Feld stehen und sich bezahlt machen, verschiebt sich die Rechnung in Richtung Kontrolle und Zuverlässigkeit. Viele Teams wechseln an diesem Punkt zu einem privaten Netzwerk oder zumindest zu einer bezahlten, betriebenen Instanz von The Things Stack, damit Abdeckung und Verfügbarkeit tatsächlich jemandes Verantwortung sind. Ob Sie selbst hosten oder einen betriebenen Network Server nutzen, das Ziel ist dasselbe: keine bösen Überraschungen durch Lücken.
Regulierte oder abgelegene Standorte. Gesundheitswesen, Versorger, alles mit Vorgaben zur Datenresidenz, oder jeder Standort ganz ohne Community-Abdeckung. Hier ist ein privates Netzwerk meist die einzige ehrliche Antwort. Sie brauchen die Datengrenze, die garantierte Abdeckung oder beides, und eine öffentliche Karte kann Ihnen keines davon geben.
Die Grenze ist nicht starr. Viele reale Einsätze mischen Modelle: ein privates Netzwerk auf dem Hauptgelände, The Things Network für einen Außenstandort, der bereits Abdeckung hat. Das ist in Ordnung, und es führt direkt zum nächsten Punkt.
Der Network Server ist nicht Ihre Anwendung
Welches Modell Sie auch wählen, der Network Server transportiert und entschlüsselt Pakete. Das ist alles, was er tut. Er speichert keine Historie, zeichnet kein Dashboard, alarmiert keinen Bediener, wenn ein Tank leer läuft, und löst keine Pumpe aus. Diese Aufgaben liegen eine Schicht höher, auf der Application-Plattform. Genau hier bleiben Projekte üblicherweise stecken.
Genau dort sitzt TagoIO. TagoIO ist eine verwaltete IoT-Application-Plattform, die oberhalb des Network Servers läuft. Sie nimmt die entschlüsselten Daten auf, die aus Ihrem LoRaWAN-Netzwerk kommen, speichert sie, zeigt sie in Dashboards an, verwaltet Ihre Geräte und lässt Sie darauf Alarme, APIs und automatisierte Actions aufbauen.
Weil TagoIO unterhalb des Network Servers ansetzt, bindet Sie das Modell, das Sie darunter gewählt haben, nicht fest. Sie betreiben The Things Network? TagoIO holt die Daten aus The Things Stack. Sie hosten ChirpStack selbst in einem privaten Netzwerk? TagoIO verbindet sich mit ChirpStack. Sie mischen beides über mehrere Standorte? Die Application-Schicht bleibt gleich, während sich die Netzwerke darunter unterscheiden. Sie können Netzwerkmodelle ändern oder kombinieren, ohne die Dashboards und die Logik neu zu bauen, auf die sich Ihr Team verlässt.
Für Teams, die die Anwendung an ihre eigenen Kunden weiterverkaufen oder als White-Label anbieten müssen, liefert TagoRUN genau das auf derselben Plattform. Für die Verarbeitung am Edge nahe der Gateways ist TagoCore eine Open-Source-Laufzeitumgebung, die die Anwendungslogik vor Ort ausführt. Die Plattform selbst ist nach ISO 27001 zertifiziert und GDPR-konform, was tendenziell genau den regulierten Teams am wichtigsten ist, die auf der Netzwerkseite zum privaten Modell neigen.
Die Kurzfassung
Es gibt kein bestes LoRaWAN-Netzwerkmodell, nur das richtige für die Aufgabe, die vor Ihnen liegt. Entscheiden Sie nach Abdeckung, Kontrolle, Zuverlässigkeit, Sicherheit, Kosten und SLA, gewichtet nach dem, was Ihr Projekt tatsächlich braucht. Nutzen Sie The Things Network für Hobby und Prototyping, Helium wenn Sie dezentrale Abdeckung wollen und deren Kosten akzeptieren, und ein privates Netzwerk auf The Things Stack oder ChirpStack, wenn Sie Kontrolle, garantierte Abdeckung oder eine harte Datengrenze für produktive und regulierte Arbeit brauchen.
Wählen Sie dann die Application-Schicht, die über allem sitzt, damit die Daten, die Sie mühsam gesammelt haben, zu etwas werden, das ein Mensch sehen und auf das er reagieren kann. Treffen Sie die Entscheidung über das Netzwerkmodell früh. Wie schon die Wahl der Funktechnik davor lässt sie sich kaum noch rückgängig machen, sobald die Sensoren im Feld sind.
