Expertise

6 Min. Lesezeit

22. Mai 2026

22. Mai 2026

LoRaWAN-Netzwerkserver erklärt: Architektur, Funktionen und wie man den besten auswählt

TEKTELIC_Logo
By Zuletzt aktualisiert: Mai 22, 2026
LoRaWAN-Netzwerkserver erklärt: Architektur, Funktionen und wie man den besten auswählt
LoRaWAN-Netzwerkserver erklärt: Architektur, Funktionen und wie man den besten auswählt
Zusammenfassung

Bei TEKTELIC entwickeln und implementieren wir seit über zehn Jahren LoRaWAN-Infrastruktur. In dieser Zeit haben wir mit Netzbetreibern, Unternehmen, Energieversorgern und Systemintegratoren an Netzwerken unterschiedlichster Größenordnungen gearbeitet – von kleinen Gebäudeinstallationen bis hin zu großen nationalen Netzwerken mit Hunderttausenden von Geräten.

Ein Thema gewinnt oft an Bedeutung, als man erwartet: die Wahl von LoRaWAN Netzwerkserver (LNS).

Man könnte den LNS leicht als bloße Softwareschicht betrachten. Tatsächlich ist er jedoch eine der wichtigsten Entscheidungen bei der Implementierung von LoRaWAN. Er beeinflusst die Netzwerkleistung, die Datenübertragung, die Gerätesicherheit, die Skalierbarkeit und den Aufwand, den Ihr Team für den langfristigen Betrieb des Netzwerks betreiben muss.

Mit diesem Artikel möchten wir Ihnen die Entscheidung erleichtern. Wir erklären Ihnen die Funktionsweise eines LoRaWAN-Netzwerkservers, die Unterschiede zwischen einer leistungsfähigen und einer Carrier-Grade-Plattform und worauf Sie beim Vergleich der verschiedenen Optionen achten sollten.

Der LNS ist nicht nur eine im Hintergrund laufende Software. Er ist das Gehirn Ihres gesamten LoRaWAN-Netzwerks.

Was ein LoRaWAN-Netzwerkserver leistet

Die vereinfachte Erklärung lautet: Sensoren senden Daten, Gateways empfangen sie, der Netzwerkserver verarbeitet sie und Anwendungen nutzen sie. Diese Erklärung ist zwar richtig, lässt aber vieles von dem, was im Hintergrund passiert, außer Acht.

Wenn ein Sensor ein Datenpaket sendet, können mehrere Gateways in Reichweite dieses gleichzeitig empfangen. Der LNS erfasst alle Kopien, wählt die beste aus und entfernt die Duplikate, bevor die Daten die Anwendung erreichen.

Das ist wichtiger, als es zunächst scheinen mag. Ohne diesen Schritt könnte die Anwendung zweimal denselben Zählerstand, denselben Alarm oder denselben Belegungsstatus empfangen.

Netzwerk-Server-Architektur

Das LNS prüft jede Nachricht, bevor es sie weiterleitet. Es bestätigt, dass das Paket von einem registrierten Gerät stammt, dass es nicht bereits im Rahmen eines Replay-Angriffs gesendet wurde und dass die Gerätesitzung gültig ist. Ohne diese Prüfungen könnte das Netzwerk gefälschte, duplizierte oder beschädigte Daten genauso leicht verarbeiten wie gültige Daten.

Dann gibt es Adaptive Datenrate, oder ADR. Es ist eine der wichtigsten Funktionen eines gut konstruierten LNS und oft eine der am wenigsten diskutierten.

ADR ermöglicht es dem Netzwerk, jedem Gerät die optimale Datenrate und Sendeleistung basierend auf der tatsächlich empfangenen Signalqualität mitzuteilen. Ein Gerät in der Nähe eines Gateways kann schneller und mit geringerer Leistung senden. Ein Gerät am Rande der Versorgungszone kann die Übertragungsgeschwindigkeit reduzieren, um die Paketübermittlung zu verbessern.

Funktioniert ADR einwandfrei, verbessert sich die Akkulaufzeit, die Sendezeit verkürzt sich und ein Gateway kann mehr Geräte unterstützen. Funktioniert es nicht einwandfrei oder ist es gar nicht verfügbar, verbraucht das Netzwerk mehr Strom und Kapazität als nötig, und die Akkus können sich schneller als erwartet entladen.

WARUM ADR IN DER PRAXIS WICHTIG IST

In einem optimal konfigurierten LoRaWAN-Netzwerk kann ADR die Akkulaufzeit von Geräten um Jahre verlängern und die Anzahl der von einem Gateway verarbeitbaren Geräte etwa verdoppeln. Der LNS (LoRaWAN Network Switch) macht dies möglich – oder eben nicht.

Nachdem wir nun die Vorgänge im Inneren des LNS betrachtet haben, wollen wir uns ansehen, was eine Plattform im großen Maßstab zuverlässiger macht als eine andere.

Wie oft können Geräte Daten senden?

Carrier-Grade: Was es bedeutet und warum es wichtig ist

Es besteht ein deutlicher Unterschied zwischen einem LoRaWAN-Netzwerkserver, der in Tests gut funktioniert, und einem, der im Produktivbetrieb – in großem Umfang, über Jahre hinweg und unter Bedingungen, die nicht immer wie geplant verlaufen – zuverlässig arbeitet.

Der Unterschied liegt in der Art und Weise, wie die Plattform aufgebaut ist.

A Trägerqualität LNS hat keinen Single Point of Failure. Fällt eine Komponente aus, funktioniert das restliche System weiterhin. Es skaliert horizontal, d. h. die Kapazität kann bei Bedarf erweitert werden, ohne das Netzwerk neu aufbauen zu müssen. Zudem arbeitet es mit N+1-Redundanz, sodass der Ausfall eines Knotens nicht zum Ausfall des gesamten Systems führt.

Für ein kleines Pilotprojekt mag dies nicht notwendig erscheinen. Für ein Versorgungsunternehmen mit hunderttausend Zählern, einen Krankenhauskomplex, ein Portfolio intelligenter Gebäude oder ein öffentliches Netzwerk mit mehreren Nutzern wird es jedoch zur Mindestanforderung.

Diese Netzwerke dürfen nicht jedes Mal offline gehen, wenn Wartungsarbeiten erforderlich sind. Sie dürfen sich auch nicht auf eine Architektur verlassen, die nie für eine reibungslose Wiederherstellung nach einem Ausfall konzipiert wurde.

Das ist der Unterschied zwischen einem LoRaWAN-Netzwerkserver und einem LoRaWAN-Netzwerkserver in Carrier-Qualität. Ersterer leitet Pakete weiter, wenn alles funktioniert. Letzterer ist so konzipiert, dass er auch bei Störungen weiterläuft.

Die Art und Weise, wie eine Plattform aufgebaut ist, entscheidet über ihre Funktionsfähigkeit. Was sie mit den Daten macht, entscheidet darüber, ob diese Daten tatsächlich nützlich sind.

Tektelic Gateway

Daten aus Ihrem Netzwerk für Ihr Unternehmen

LoRaWAN-Sensoren senden üblicherweise keine direkt nutzbaren Messwerte. Sie senden kompakte, kodierte Bytefolgen, die für eine Geschäftsanwendung erst dann aussagekräftig sind, wenn sie übersetzt werden. Diese Übersetzung ist eine der wichtigsten Aufgaben des LoRaWAN Networks (LNS).

Die Unterstützung von Payload-Codecs wandelt eine rohe Hexadezimalzeichenkette in nutzbare Daten um – beispielsweise eine Temperaturmessung, einen Belegungsstatus, einen Messwert oder einen Akkustand in Prozent. Ohne diese Integration in die Plattform benötigt jede Anwendungsverbindung möglicherweise eine eigene Dekodierungslogik, die von jemandem geschrieben, getestet und gewartet werden muss.

Der andere Aspekt ist das Routing. Ein leistungsstarkes LNS unterstützt Standardprotokolle wie MQTT, HTTP und REST. Es kann außerdem Verbindungen zu den Plattformen und Systemen herstellen, an die die Daten gesendet werden sollen, darunter Azure IoT Central, AWS IoT Core, ThingsBoard, Gebäudeleittechnik, SCADA-Systeme und interne Anwendungen.

An diesem Punkt hören Sensordaten auf, Funkverkehr zu sein, und werden zu nützlichen Geschäftsinformationen.

Die Frage ist nicht, ob Ihr LNS Pakete zustellen kann. Sondern ob es die richtigen Daten im richtigen Format an das richtige System übermitteln kann, ohne Fehler zu verursachen.

Zu wissen, was das LNS mit den Daten macht, ist die eine Seite der Medaille. Die andere Seite ist zu wissen, wohin es führt – eine Entscheidung, die sich in der Regel als nachhaltiger erweist, als die meisten Teams bei ihrer ersten Entscheidung erwarten.

Wo Ihr LNS läuft – und wie Sie es auswählen

Es gibt kein allgemeingültiges Bereitstellungsmodell für einen LoRaWAN-Netzwerkserver. Die beste Option hängt von Ihren Sicherheitsanforderungen, Ihrer IT-Umgebung, der Sensibilität Ihrer Daten und dem gewünschten Umfang der direkten Verwaltung durch Ihr Team ab.

Hier sind die vier Hauptoptionen.

Cloud LNS

Es läuft in der Cloud und verbindet alle Gateways mit einem zentralen System. Die Einrichtung ist schnell, die Skalierung über mehrere Standorte hinweg problemlos und der IT-Aufwand für den Betrieb minimal.

Bestens geeignet für: Schnelle Bereitstellung und Skalierung auf mehrere Standorte, ohne dass Sie Ihre eigene Infrastruktur verwalten müssen.

Cloud-LoRawan-Netzwerkserverarchitektur

Private Cloud LNS

Läuft in einer dedizierten Cloud-Umgebung, die Sie kontrollieren. Sie profitieren von den Vorteilen der Cloud und haben gleichzeitig mehr Kontrolle über Sicherheit, Datenspeicherort und Konfiguration.

Bestens geeignet für: Teams, die die Einfachheit der Cloud nutzen möchten, aber eine isolierte Umgebung oder spezifische Compliance-Kontrollen benötigen.

private_cloud_lorawan_network_server_architecture

Vor-Ort-LNS

Läuft innerhalb Ihrer eigenen Infrastruktur. Sie haben die volle Kontrolle über Ihre Daten, Ihre Sicherheitseinstellungen und die Art und Weise, wie das System Verbindungen zu internen Anwendungen herstellt.

Bestens geeignet für: Organisationen, bei denen Datenkontrolle, interne Sicherheitsrichtlinien oder die Integration in bestehende IT-Systeme eine zwingende Voraussetzung sind.

lokale LoRaWAN-Netzwerkserverarchitektur

Eingebettetes LNS

Läuft direkt innerhalb des Gateways. Es wird kein separater Server benötigt, da das Gateway die Netzwerkserverfunktionen selbst übernimmt.

Bestens geeignet für: Für kleine oder abgelegene Standorte, wo eine einfache, in sich geschlossene Lösung ohne externe Abhängigkeiten die richtige Wahl ist.

Nachdem wir nun ein klares Bild davon haben, worauf es bei einem LNS ankommt, wollen wir uns ansehen, wie KONA Core so konstruiert ist, dass es diese Anforderungen erfüllt.

eingebettete Zeilenumbrüche

TEKTELIC KONA Core: Was es leistet

KONA COREKONA Core ist der Carrier-Grade LoRaWAN-Netzwerkserver von TEKTELIC. Er ist keine Zusatzfunktion einer größeren Plattform, sondern das Herzstück des LoRaWAN-Ökosystems von TEKTELIC und wird von demselben Team entwickelt und gewartet, das auch unsere Gateways, Geräte und Netzwerktools entwirft.

So sieht das in der Praxis aus:

Vollständiger LoRaWAN-Stack

OTAA- und ABP-Aktivierung, Unterstützung von Geräten der Klassen A/B/C, ADR, Downlink-Scheduling, MAC-Befehlsverarbeitung, Multicast und FUOTA – das vollständige Protokoll, nicht nur eine Teilimplementierung.

Architektur in Carrier-Qualität

Keine Single Point of Failure, horizontale Skalierbarkeit, N+1-Redundanz und Fehlertoleranz wurden in Live-Netzwerken mit Hunderttausenden von Geräten getestet.

Datenübertragung und Codecs

Leitet Nutzdaten über MQTT(S), HTTP(S), REST, Azure IoT Central, ThingsBoard und AWS IoT Core weiter. Dekodiert Rohdaten in sauberes JSON, sodass Ihre Anwendungen die Daten sofort verwenden können.

Operative Transparenz

Echtzeit-Paketanzeige, Geräte- und Gateway-Überwachung, Ereignis-Streaming, Protokollaggregation und E-Mail-Benachrichtigungen. Probleme werden frühzeitig erkannt, bevor sie Ihr Netzwerk beeinträchtigen.

Sicherheit

TLS-Verschlüsselung, SSO, Unterstützung für x.509-Zertifikate, rollenbasierte Zugriffskontrolle, jährliche Penetrationstests und Sicherheitsaudits. Entwickelt, um die Anforderungen von Energieversorgern, dem Gesundheitswesen und Betreibern öffentlicher Netze zu erfüllen.

Automatisierung und APIs

Vollständige REST-API für die Massenbereitstellung von Geräten, Konfiguration, Ereignisabonnements und Abrechnungsintegration. Weniger manueller Aufwand bei wachsendem Netzwerk.

Mandantenfähigkeit

Rollenbasierter Zugriff, separate Kundenumgebungen, Abonnementlimits und Unterkundenverwaltung – entwickelt für Managed Service Provider und öffentliche Betreiber.

Global und offen

Regionale Frequenzpläne für Nordamerika, Europa, Asien und darüber hinaus. Kompatibel mit TEKTELIC und Geräten und Gateways von Drittanbietern, einschließlich des Semtech UDP-Paketweiterleiters. 

Jetzt herunterladen

Diejenige Entscheidung, die am schwersten rückgängig zu machen ist.

Jedes LoRaWAN-Netzwerk stößt irgendwann an die Grenzen der zu Beginn getroffenen Entscheidungen.

Gateways und Sensoren lassen sich austauschen. Anders verhält es sich mit dem LNS. Es ist die Schicht, von der alles andere abhängt, und daher am schwierigsten zu ändern, sobald das Netzwerk in Betrieb ist.

Es hat außerdem einen der größten langfristigen Auswirkungen auf Leistung, Sicherheit, Skalierbarkeit und Betriebskosten.

Es ist viel einfacher, Fehler frühzeitig zu beheben, als sie später zu korrigieren. So gehen wir bei der Entwicklung von LNS-Systemen mit unseren Kunden vor, und das ist einer der Gründe, warum KONA Core so konstruiert wurde, wie es ist.

TEIL EINES KOMPLETTEN ÖKOSYSTEMS

KONA Core arbeitet mit TEKTELIC zusammen Carrier-Grade-Gateways, KONA Element für Gateway-Flottenmanagement KONA Radiant für die HF-Planung ATLAS zur Gerätekonfiguration ORT für Standortdienste und das gesamte Produktangebot von TEKTELIC Sensoren, Tracker und medizinische IoT-GeräteAlle Komponenten sind so konzipiert, dass sie miteinander funktionieren – vom ersten Pilotprojekt bis hin zur landesweiten Umsetzung.

Möchten Sie Ihre Implementierung besprechen?

Ob Sie ein neues Netzwerk aufbauen, ein bestehendes erweitern oder von einer nicht mehr unterstützten Plattform wechseln – wir beraten Sie gerne unverbindlich darüber, wie KONA Core Ihre Situation optimal unterstützen kann. Kontaktieren Sie unser Team: info@tektelic.com

Um über unsere Neuigkeiten abonnieren sie unseren newsletter