Ein Sensor im Keller, ein Tracker auf einem Frachtschiff oder eine Kamera an einem abgelegenen Standort brauchen nicht dieselbe Netzwerkverbindung. Unter dem Fachbegriff iot connectivity geht es deshalb nicht um eine einzelne Technologie, sondern um die passende Verbindung zwischen Gerät, Gateway, Mobilfunknetz und Cloud. Ich zeige, welche Optionen sich für IoT-Systeme eignen, wo ihre Grenzen liegen und worauf man bei Projekten in Deutschland sowie in Regionen mit lückenhafter Infrastruktur achten sollte.
Die passende Verbindung richtet sich nach Datenmenge, Energie und Standort
- LoRaWAN und NB-IoT eignen sich für kleine Datenmengen und lange Batterielaufzeiten.
- LTE-M und 4G sind sinnvoll, wenn Geräte mobil sind oder häufiger kommunizieren müssen.
- Wi-Fi, Ethernet und 5G bieten mehr Bandbreite, benötigen aber meist mehr Energie und Infrastruktur.
- Bluetooth LE, Zigbee und Thread verbinden Geräte auf kurze Distanz, oft über ein Gateway.
- Sicherheit, Roaming und Netzlebensdauer sind genauso wichtig wie Reichweite und Geschwindigkeit.
Was bei IoT-Konnektivität tatsächlich verbunden wird
Ein IoT-System besteht selten nur aus einem Sensor und einer Internetverbindung. Typischerweise misst ein Gerät Temperatur, Standort, Füllstand oder Energieverbrauch, überträgt die Daten an ein Gateway oder Funknetz und sendet sie anschließend an eine Plattform. Dort werden Messwerte gespeichert, ausgewertet und in einer Anwendung sichtbar gemacht.
Diese Kette wird oft unterschätzt. Ein Sensor kann technisch hervorragende Funkwerte liefern und trotzdem unbrauchbar sein, wenn die Cloud-Anbindung ausfällt, das Gateway keine Updates erhält oder die SIM-Karte nur in einem einzigen Land funktioniert. Ich betrachte deshalb immer die gesamte Strecke vom Gerät bis zur Anwendung, nicht nur das Funkmodul.
Funkstandard und Anwendungsprotokoll sind nicht dasselbe
Wi-Fi, LoRaWAN, LTE-M oder Bluetooth LE beschreiben vor allem die Übertragungsebene. Protokolle wie MQTT oder CoAP regeln dagegen, wie Messwerte ausgetauscht werden. MQTT ist ein leichtgewichtiges Nachrichtenprotokoll, das sich besonders für zuverlässige Verbindungen zwischen Geräten und Cloud-Diensten eignet.
Auch ein Gerät mit IPv6-Adresse ist noch keine fertige IoT-Lösung. Es braucht Authentifizierung, Gerätemanagement, Zeitstempel, Fehlerbehandlung und eine Strategie für Firmware-Updates. Genau hier entscheidet sich in der Praxis, ob ein Pilot mit 50 Sensoren später auch mit 50.000 Geräten stabil läuft.
Welche Technologien welche Aufgabe übernehmen
Die Auswahl ist groß, aber die Unterschiede lassen sich gut auf wenige Fragen reduzieren. Wie weit muss das Signal reichen, wie oft sendet das Gerät, wie viel Energie steht zur Verfügung und braucht es eine direkte Internetverbindung?
| Technologie | Typischer Einsatz | Stärken | Grenzen |
|---|---|---|---|
| Ethernet | Maschinen, Gebäudeautomation, Gateways | Stabil, planbare Latenz, hohe Sicherheit im lokalen Netz | Kabel und feste Stromversorgung erforderlich |
| Wi-Fi | Kameras, Haushaltsgeräte, Anlagen mit hoher Datenrate | Hohe Bandbreite, weit verbreitet, einfache IP-Anbindung | Höherer Energieverbrauch, Reichweite und Gebäudedämpfung |
| Bluetooth LE | Wearables, Beacons, Wartungssensoren | Sehr geringer Verbrauch, günstige Hardware, gute Smartphone-Anbindung | Kurze Reichweite, meist Gateway für den Internetzugang nötig |
| Thread und Zigbee | Smart Home, Beleuchtung, Gebäudesensorik | Mesh-Netzwerke, niedriger Verbrauch, viele Geräte im lokalen Bereich | Abhängigkeit von Border Router oder Gateway, begrenzte Datenrate |
| LoRaWAN | Smart Metering, Landwirtschaft, Parkplätze, Umweltmessung | Große Reichweite, kleine Datenmengen, lange Batterielaufzeit | Niedrige Datenrate, Downlink begrenzt, Gateway-Abdeckung erforderlich |
| NB-IoT | Zähler, stationäre Sensoren, Keller und Schächte | Mobilfunkabdeckung, geringer Energiebedarf, gute Gebäudedurchdringung | Für kleine Nachrichten gedacht, Mobilität und Echtzeit nur eingeschränkt |
| LTE-M | Tracker, Logistik, mobile Medizingeräte | Mehr Datenrate, geringere Latenz, Mobilität und Sprachoptionen möglich | Höherer Verbrauch und meist höhere laufende Kosten als bei LPWAN |
| 4G und 5G | Video, Robotik, Fahrzeuge, industrielle Anwendungen | Hohe Bandbreite, niedrige Latenz, öffentliche und private Netze | Mehr Energiebedarf, höhere Hardwarekosten, nicht für jeden Sensor sinnvoll |
| Satellit und NTN | Schiffe, abgelegene Anlagen, Notfall- und Umweltmonitoring | Erreichbarkeit ohne terrestrischen Mobilfunk | Höhere Kosten, Antennenanforderungen, Latenz und Energiebedarf |
LoRaWAN ist besonders interessant, wenn wenige Bytes in großen Zeitabständen übertragen werden. Ein Bodenfeuchtesensor, der alle 15 Minuten einen Messwert sendet, benötigt keine 5G-Verbindung. Entscheidend ist vielmehr, dass das Signal die Entfernung überwindet und die Batterie mehrere Jahre hält.
NB-IoT nutzt dagegen das Mobilfunkökosystem und eignet sich gut für stationäre Sensoren, etwa Wasserzähler in Kellerräumen. LTE-M ist die bessere Wahl, wenn sich das Gerät bewegt oder häufiger kommuniziert, beispielsweise bei einem Container-Tracker.
Wi-Fi und 5G werden oft reflexartig als modernste Lösung genannt. Für eine Kamera, ein fahrerloses Transportsystem oder eine industrielle Steuerung kann das richtig sein. Für einen Temperatursensor mit wenigen Messwerten pro Stunde ist es meistens unnötig teuer und belastet die Batterie stärker.
Wie ich die passende Verbindung auswähle
Ich beginne nicht mit der Frage, welches Funkmodul gerade beliebt ist. Zuerst schreibe ich das Kommunikationsprofil des Geräts auf. Dazu gehören Nachrichtenhäufigkeit, Nutzdaten, Reaktionszeit, Beweglichkeit und Stromquelle.
- Messintervall und maximale Nachrichtengröße festlegen.
- Erforderliche Reaktionszeit bestimmen, etwa Sekunden, Minuten oder Stunden.
- Standort, Gebäude, Gelände und erwartete Funkhindernisse prüfen.
- Verfügbarkeit von Mobilfunk, Gateways, Strom und Backhaul testen.
- Roaming, SIM-Management, Updatefähigkeit und Vertragslaufzeit klären.
- Mit realen Geräten einen Feldtest über mehrere Tage durchführen.
Ein Sensor, der nur alle 30 Minuten einen Zustand überträgt, hat andere Anforderungen als ein Alarmgeber. Bei einem Alarm kann eine Übertragung innerhalb weniger Sekunden wichtig sein, während bei einer Füllstandsmessung ein Zeitfenster von mehreren Minuten ausreicht. Diese Unterscheidung spart oft mehr Geld als die Wahl zwischen zwei ähnlichen Modulen.
Die Datenmenge realistisch berechnen
Ein einzelner Messwert ist klein, doch Protokoll-Overhead, TLS-Verschlüsselung, Bestätigungen und Firmware-Updates kommen hinzu. Bei 10.000 Geräten mit jeweils 20 Übertragungen pro Tag entstehen bereits 200.000 Nachrichten täglich. Für die Planung zählt deshalb nicht nur die Nutzlast, sondern auch die Zahl der Verbindungsaufbauten und Wiederholungen.
Für Firmware-Updates sollte ich eine separate Rechnung anstellen. Ein Sensor, der im Normalbetrieb nur wenige Kilobyte im Monat benötigt, kann bei einem Update plötzlich mehrere Megabyte übertragen. Ein System ohne Updatepfad wirkt zunächst günstig, wird aber später teuer und sicherheitskritisch.
Wann eine Hybridlösung sinnvoll ist
Viele robuste IoT-Systeme kombinieren mehrere Ebenen. Ein Bluetooth- oder Thread-Sensor kommuniziert lokal mit einem Gateway, während das Gateway über Ethernet, Wi-Fi oder Mobilfunk die Verbindung zur Cloud herstellt. So bleiben die Endgeräte sparsam, und die teurere Weitverkehrsverbindung wird nur an wenigen Punkten benötigt.
Bei mobilen oder kritischen Anwendungen kann ein Gerät zusätzlich zwei Netze unterstützen, etwa LTE-M und 4G. Das erhöht die Hardware- und Testkosten, reduziert aber das Risiko eines Totalausfalls. Ich halte Fallback-Kommunikation besonders dann für sinnvoll, wenn ein Sensorausfall hohe Folgekosten verursacht.
Warum Standort und Infrastruktur die Entscheidung bestimmen
Ein Datenblatt ersetzt keine Messung vor Ort. Beton, Metall, Kellerdecken, Container und dicht bewachsene Flächen verändern die Funkbedingungen erheblich. Selbst eine nominell gute Abdeckung kann an einem konkreten Standort unzuverlässig sein, weil das Gerät ungünstig montiert ist oder die Antenne zu klein dimensioniert wurde.
In Deutschland stehen meist mehrere Optionen zur Verfügung, darunter öffentliche Mobilfunknetze, Wi-Fi, Ethernet und regionale LoRaWAN-Angebote. Trotzdem sollte ich Abdeckung, Gebäudedämpfung und Netzbetreiber am geplanten Einsatzort prüfen. Besonders bei einer Laufzeit von fünf bis zehn Jahren gehört auch die Netzstrategie des Betreibers in die Entscheidung.
Für Timor-Leste und andere Insel- oder Bergregionen verschiebt sich die Gewichtung. Außerhalb urbaner Zentren können Stromversorgung, Backhaul und Wartungszugang wichtiger sein als die maximale Datenrate. Ein lokales LoRaWAN-Gateway mit Solarversorgung, Mobilfunk-Backhaul oder Satellitenanbindung kann dort sinnvoller sein als viele einzelne Mobilfunkgeräte.
Reichweite ist keine feste Zahl
Angaben wie „mehrere Kilometer“ oder „bis zu 100 Meter“ sind Labor- oder Idealwerte. In Gebäuden fällt die Reichweite oft deutlich geringer aus, während eine freie Sichtverbindung im Außenbereich bessere Ergebnisse ermöglicht. Ich plane deshalb mit einer Reserve von mindestens einem Netzwerkknoten oder Gateway, wenn der Ausfall einzelner Komponenten nicht sofort zum Stillstand führen darf.
Bei Mesh-Netzwerken wie Thread oder Zigbee kann zusätzliche Infrastruktur die Abdeckung verbessern. Das funktioniert allerdings nur, wenn genügend dauerhaft versorgte Router vorhanden sind. Reine Batteriegeräte können in solchen Netzen meist nicht als stabile Weiterleiter dienen.
Sicherheit, Betrieb und Zukunftsfähigkeit gehören zur Verbindung
Ein verschlüsselter Funkweg allein macht ein IoT-System nicht sicher. Jedes Gerät braucht eine eindeutige Identität, sichere Schlüsselverwaltung und einen kontrollierten Prozess für Inbetriebnahme und Deaktivierung. Standardpasswörter, offene Debug-Schnittstellen und unverschlüsselte MQTT-Verbindungen gehören zu den Fehlern, die ich besonders häufig sehe.
Für Verbrauchergeräte bietet ETSI EN 303 645 eine hilfreiche Orientierung mit Anforderungen wie sicheren Standardpasswörtern, Schwachstellenmanagement und sicherer Update-Funktion. Für industrielle Anlagen kommen zusätzliche Vorgaben aus der jeweiligen Branche hinzu. Die technische Verbindung sollte immer so geplant werden, dass Updates ohne Vor-Ort-Einsatz möglich sind.
Die wichtigsten Betriebskosten liegen nicht immer im Datenvolumen
Bei vielen Sensoren sind die übertragenen Daten mengenmäßig klein. Kosten entstehen trotzdem durch SIM-Karten, Plattformgebühren, Roaming, Gateways, Wartung und Batteriewechsel. Ein günstiger Tarif kann unattraktiv werden, wenn jedes Land eine eigene Konfiguration oder ein separates Portal verlangt.
Für internationale Projekte prüfe ich deshalb eSIM- oder eUICC-Unterstützung, Multi-IMSI-Optionen und zentrale Geräteverwaltung. Das ist besonders bei Logistik und maritimen Anwendungen relevant. Eine technisch passende Funkverbindung nützt wenig, wenn die Geräte beim Grenzübertritt offline gehen.
Lesen Sie auch: MQTT 5 im IoT - Mehr als nur ein Update?
Lebensdauer und Abschaltung alter Netze einplanen
IoT-Geräte bleiben häufig länger im Einsatz als Smartphones. Wer heute ein Modul auswählt, sollte deshalb prüfen, welche Netze in fünf oder zehn Jahren noch unterstützt werden. Ein Design, das nur auf eine einzelne Generation oder einen einzelnen Anbieter setzt, kann bei einer Netzabschaltung einen kompletten Austausch der Geräte erzwingen.
Ich bevorzuge modulare Hardware, standardisierte Protokolle und eine Firmware, die mehrere Verbindungswege verwalten kann. Das kostet am Anfang etwas mehr, schafft aber technische Beweglichkeit, wenn sich Abdeckung, Tarife oder regionale Vorschriften ändern.
Eine robuste IoT-Entscheidung beginnt mit dem Rückkanal
Die beste Verbindung ist nicht automatisch die schnellste. Für kleine, seltene Nachrichten sind LoRaWAN oder NB-IoT oft die vernünftigere Wahl, während mobile Geräte von LTE-M profitieren und datenintensive Anwendungen 4G, 5G oder Ethernet benötigen. In abgelegenen Gebieten können Gateways, Solarversorgung und Satelliten-Backhaul wichtiger sein als der Funkstandard des Sensors.
Meine wichtigste Prüffrage lautet deshalb: Was passiert, wenn die Verbindung für eine Stunde, einen Tag oder eine ganze Woche ausfällt? Wer lokale Zwischenspeicherung, Wiederholungslogik, Alarmwege und sichere Updates von Anfang an einplant, baut kein hübsches Pilotprojekt, sondern ein belastbares IoT-System, das auch unter realen Bedingungen funktioniert.
