IoT-Architekten in Unternehmen verbringen viel Zeit damit, Hardware und Konnektivitätstechnologien zu bewerten, und weniger Zeit damit, den Protokollstapel zu definieren, der die Kommunikation zwischen Geräten, Netzwerken und Plattformen regelt. Dieses Ungleichgewicht führt nach der Bereitstellung häufig zu Integrationsproblemen: Geräte, die sich nicht bei der Plattform authentifizieren können; Daten, die in Formaten eingehen, die die Kopfstelle nicht verarbeiten kann; Firmware-Updates, die fehlschlagen, weil das OTA-Übertragungsprotokoll nicht auf den verfügbaren Speicherplatz des Geräts abgestimmt wurde; sowie Sicherheitslücken, die durch Protokollinkongruenzen zwischen den Schichten entstehen.
Der IoT-Protokollstapel ist ein mehrschichtiger Satz von Standards, von denen jeder einen anderen Aspekt des Datenflusses vom physischen Sensor zur Anwendung regelt. Die Entscheidungen auf jeder Schicht schränken die Auswahlmöglichkeiten auf benachbarten Schichten ein oder ermöglichen sie, und die Wechselwirkungen zwischen diesen Entscheidungen bestimmen, ob der gesamte Stapel als kohärentes System oder als Sammlung einzeln validierter Komponenten fungiert, die an den Schnittstellen Reibungsverluste verursachen.
Dieser Beitrag behandelt den IoT-Protokollstapel von der physikalischen Verbindungsebene bis hin zur Anwendungsschicht und befasst sich dabei mit den für Unternehmensimplementierungen relevanten Standards, den Kompromissen auf den einzelnen Ebenen sowie den Integrationsaspekten, die darüber entscheiden, ob der Stapel auch im großen Maßstab zusammenhält.
Physikalische Schicht und Zugriffsschicht: Mobilfunkstandards
Die physikalische Schicht und die Zugriffsschicht legen fest, wie ein Gerät eine Funkverbindung zu einem Netzwerk herstellt. Im Bereich des Unternehmens-IoT lohnt es sich, die relevanten Mobilfunkstandards und deren Positionierung zueinander zu klären, da die Marketingaussagen zu diesen Technologien unter Umständen ungenau sind und dies Auswirkungen auf Entscheidungen zur Einführung haben kann.
NB-IoT (Schmalband-IoT, 3GPP Release 13 und höher) arbeitet in einem 180-kHz-Kanal innerhalb des lizenzierten Frequenzspektrums, entweder in-band innerhalb eines „ LTE “-Trägers, im „ LTE “-Schutzband oder im Standalone-Betrieb auf umgenutztem „ GSM “-Spektrum. Wesentliche Merkmale der physikalischen Schicht:
- Maximaler Downlink-Durchsatz: ca. 250 kbit/s im Ein-Ton-Betrieb
- Maximaler Uplink-Durchsatz: ca. 250 kbit/s
- Link-Budget: 164 dBm maximaler Kopplungsverlust, eine Verbesserung um ca. 20 dB gegenüber GPRS
- Latenz: 1,6 bis 10 Sekunden für eine typische Datenübertragung einschließlich Einrichtungszeit, wodurch sich die Lösung nicht für Anwendungen eignet, die eine Reaktionszeit von weniger als einer Sekunde erfordern
- Duplex-Modus: nur Halbduplex
LTE-M (LTE-MTC, Cat-M1, 3GPP Release 13) arbeitet in einem 1,4-MHz-Kanal innerhalb des LTE -Frequenzspektrums und unterstützt Vollduplex. Wesentliche Merkmale der physikalischen Schicht:
- Maximaler Downlink-Durchsatz: ca. 1 Mbit/s
- Maximaler Uplink-Durchsatz: ca. 1 Mbit/s
- Link-Budget: 155,7 dBm maximaler Kopplungsverlust, eine Verbesserung um ca. 15 dB gegenüber GPRS
- Latenz: 10 bis 15 ms für die Datenübertragung nach dem Verbindungsaufbau
- Duplex-Modus: Vollduplex wird unterstützt, wodurch Sprachübertragung und bidirektionale Echtzeitdatenübertragung möglich sind
5G NR für das IoT führt zwei relevante Gerätekategorien ein: RedCap (Reduced Capability, 3GPP Release 17), das auf IoT-Geräte der mittleren Leistungsklasse abzielt, die einen höheren Durchsatz als „ LTE-M“, aber einen geringeren Stromverbrauch als „full- 5G -NR-UE“ erfordern, sowie „ 5G -NR“ für IoT-Anwendungen mit hoher Bandbreite. RedCap zielt auf einen Durchsatz von 5 bis 25 Mbit/s ab und bietet im Vergleich zu „full- 5G “ NR eine Reduzierung des Stromverbrauchs und der Komplexität. Damit schließt es die Lücke zwischen „ LTE-M“ und „full- 5G “, die bisher von 4G-Cat-4-Geräten besetzt war.
Die Wahl der physikalischen Schicht legt die Ober- und Untergrenze für jede darüberliegende Schicht fest. Ein Protokollstapel, der für bidirektionale Kommunikation im Subsekundenbereich konzipiert ist und auf „ NB-IoT “ basiert, wird bereits auf der physikalischen Ebene versagen, noch bevor das Anwendungsprotokoll überhaupt zum Einsatz kommen kann.
Netzwerkschicht: IP-Adressierung und Routing für das IoT
Die meisten IoT-Geräte in Unternehmen kommunizieren über IPv4 oder IPv6, doch die Konfiguration der Netzwerkschicht, die die Vergabe und Verwaltung dieser Adressen regelt, hat betriebliche Auswirkungen, die sich aus den Spezifikationen der physikalischen Schicht nicht ableiten lassen.
Architektur mit privatem „ APN “ ist die Standardkonfiguration der Netzwerkschicht für IoT-Implementierungen in Unternehmen, die Anforderungen an die Datensicherheit oder gesetzliche Vorschriften erfüllen müssen. Anstatt den Datenverkehr der Geräte über das gemeinsam genutzte öffentliche APN des Netzbetreibers ins öffentliche Internet weiterzuleiten, schafft ein privates APN einen dedizierten Netzwerkpfad vom Gerät zur Backend-Infrastruktur des Unternehmens. Der Datenverkehr auf einem privaten APN durchläuft nicht das öffentliche Internet, was für folgende Aspekte von Bedeutung ist:
- Einhaltung gesetzlicher Vorschriften in Branchen, in denen Daten den Perimeter des Unternehmensnetzwerks nicht verlassen dürfen
- Geringere Angriffsfläche, da die Geräte nicht direkt über das öffentliche Internet erreichbar sind
- Deterministisches Routing, da der Datenverkehr im privaten APN festgelegten Netzwerkpfaden folgt und nicht dem Routing im öffentlichen Internet unterliegt
IPv6 für das IoT ist relevant, da die Erschöpfung der IPv4-Adressen eine individuelle Adressierung bei groß angelegten IoT-Implementierungen erschwert. Bei der Implementierung von einer Million intelligenter Stromzähler, von denen jeder eine routbare IP-Adresse für die vom Kopfende initiierte Kommunikation benötigt, stößt man auf praktische Einschränkungen bei der IPv4-Zuweisung, die durch IPv6 beseitigt werden. IPv6 vereinfacht zudem die End-to-End-Adressierbarkeit in Architekturen, in denen Geräte ohne NAT-Traversal individuell erreichbar sein müssen.
Überlegungen zu CGNAT betreffen Bereitstellungen, bei denen sich Carrier-Grade-NAT zwischen dem Gerät und dem Backend des Unternehmens befindet – dies ist die Standardkonfiguration für die meisten Verbraucher- und Standard-IoT-Tarife. CGNAT verhindert eingehende Verbindungen zu Geräten, was bedeutet, dass jede Architektur, die eine vom Headend initiierte Kommunikation mit einzelnen Geräten erfordert, entweder eine private „ APN “, eine ständig aktive, vom Gerät initiierte Verbindung oder ein Gerät benötigt, das eine dauerhafte Sitzung mit der Backend-Plattform aufrechterhält. Architekten, die CGNAT bei der Konzeption nicht berücksichtigen, stellen dies erst bei den Integrationstests fest – zu diesem Zeitpunkt sind die Abhilfemaßnahmen bereits mit höheren Kosten verbunden.
Transportschicht: Protokollauswahl für die Übertragung von IoT-Daten
Die Transportschicht regelt, wie Daten verpackt und zuverlässig (oder bewusst unzuverlässig) zwischen dem Gerät und der Plattform übertragen werden. Die vorherrschenden Transportprotokolle im Unternehmens-IoT gehen jeweils unterschiedliche Kompromisse ein, die für verschiedene Anwendungsprofile geeignet sind.
MQTT (Message Queuing Telemetry Transport) ist das am weitesten verbreitete IoT-Transportprotokoll für Geräte mit Mobilfunkverbindung. Dank seiner Publish-Subscribe-Architektur, dem geringen Overhead (fester Header von mindestens 2 Byte) und der Unterstützung von drei QoS-Stufen eignet es sich besonders gut für Geräte mit begrenzten Ressourcen, die häufig kleine Nutzdatenmengen über potenziell unzuverlässige Verbindungen übertragen:
- QoS 0 (höchstens einmal): „Fire-and-Forget“, keine Bestätigung, geringster Overhead
- QoS 1 (mindestens einmal): garantierte Zustellung mit Empfangsbestätigung, mögliche Duplikate
- QoS 2 (genau einmal): garantierte einmalige Zustellung, höchster Overhead
Dank der Funktion für dauerhafte Sitzungen von MQTT können Geräte nach einer Verbindungsunterbrechung die Verbindung wiederherstellen und die Nachrichten empfangen, die der Broker während der Offline-Zeit in die Warteschlange gestellt hat. Dies ist wichtig für Geräte im PSM-Modus ( NB-IoT ), die zeitweise nicht erreichbar sind.
CoAP (Constrained Application Protocol) wurde für Geräte mit äußerst begrenzten Ressourcen entwickelt, bei denen die TCP-Anforderungen von MQTT einen inakzeptablen Overhead verursachen. CoAP läuft über UDP, nutzt ein HTTP-ähnliches Anfrage-Antwort-Modell, jedoch mit einem für ressourcenbeschränkte Umgebungen optimierten binären Header, und unterstützt eine Beobachtungsfunktion für ein Publish-Subscribe-ähnliches Verhalten. Es ist die richtige Transportwahl für Geräte mit „ NB-IoT “, bei denen der Overhead durch die TCP-Verbindungsverwaltung das Strombudget erheblich beeinträchtigen würde.
AMQP (Advanced Message Queuing Protocol) spielt eher auf der Backend-Integrationsschicht als auf der Gerät-zu-Cloud-Ebene eine Rolle. Dank seiner umfangreichen Funktionen für das Nachrichten-Routing, der Transaktionsunterstützung und der Kompatibilität mit Unternehmens-Message-Brokern ist es der Standardtransport für die Anbindung von IoT-Plattformen an Unternehmens-Backend-Systeme: ERP-, Asset-Management- und Betriebstechnik-Plattformen, die AMQP-kompatible Message-Broker erwarten.
HTTPS/REST bleibt für IoT-Geräte relevant, die über ausreichende Rechenressourcen verfügen und bei denen die Einfachheit der Integration von REST API den Mehraufwand von HTTP überwiegt. Hochwertige IoT-Gateways, Edge-Computing-Knoten und Geräte mit 4G- oder 5G -Konnektivität nutzen üblicherweise REST für die Plattformintegration, insbesondere in Bereitstellungen, in denen das Betriebsteam, das die Backend-Integration verwaltet, besser mit Web- API -Mustern vertraut ist als mit der Konfiguration von MQTT-Brokern.
Sicherheitsschicht: Standards für Authentifizierung und Encryption
Die Auswahl von Sicherheitsprotokollen im IoT wird durch die Rechen- und Speicherbeschränkungen von Edge-Geräten erschwert, wodurch sich die in Unternehmens-IT-Umgebungen üblichen Sicherheitsprotokolle auf dieser Hardware mit begrenzten Ressourcen nur schwer oder gar nicht umsetzen lassen.
TLS 1.2 und TLS 1.3 sind die Standard-Verschlüsselungsprotokolle für IoT-Geräte mit ausreichenden Rechenressourcen. TLS 1.3 reduziert die Latenz beim Handshake im Vergleich zu TLS 1.2, indem es einen Hin- und Rücklauf aus der Handshake-Sequenz eliminiert. Dies ist besonders wichtig für Geräte mit den Modulen „ NB-IoT “ und „ LTE-M“, bei denen jede Funkübertragung messbare Energieverluste verursacht. Die Auswahl der Verschlüsselungssuite innerhalb von TLS ist für das IoT von Bedeutung: Der ECDHE-Schlüsselaustausch und AES-128-GCM sind die empfohlene Kombination für IoT-Implementierungen, die ein Gleichgewicht zwischen Sicherheitsstärke und Rechenleistung herstellen.
DTLS (Datagram TLS) ist das geeignete Sicherheitsprotokoll für CoAP-Implementierungen und bietet für den Transport auf Basis von „ UDP “ die gleichen Sicherheitsgarantien wie TLS.
Gegenseitige Authentifizierung auf Basis von X.509-Zertifikaten ist der empfohlene Mechanismus zur Geräteauthentifizierung für groß angelegte IoT-Implementierungen in Unternehmen. Vorab geteilte Schlüssel sind einfacher zu implementieren, verursachen jedoch bei großen Gerätebeständen Probleme bei der Schlüsselverwaltung: Die Rotation eines kompromittierten vorab geteilten Schlüssels über Millionen von eingesetzten Geräten hinweg ist mit hohem betrieblichen Aufwand verbunden. X.509-Zertifikate mit individuellen Geräteidentitäten ermöglichen die Rotation und Sperrung von Zertifikaten auf Geräteebene, ohne andere Geräte im Bestand zu beeinträchtigen.
Hardware-Sicherheitsmodule (HSM) und vertrauenswürdige Ausführungsumgebungen (TEE) gewinnen zunehmend an Bedeutung für IoT-Geräte in Unternehmen, die sensible Daten verarbeiten oder in Umgebungen eingesetzt werden, in denen das Risiko eines physischen Zugriffs auf das Gerät durch Unbefugte besteht. Die Speicherung privater Schlüssel in einem hardwaregeschützten Element anstelle des Firmware-Speichers verhindert die Extraktion der Schlüssel, selbst wenn die Geräte-Firmware kompromittiert wird.
Der Sicherheitsprotokollstapel muss vor der Bereitstellung durchgängig validiert werden. Ein Gerät, das TLS korrekt implementiert, sich jedoch mit einem Plattform-Endpunkt verbindet, der keine gegenseitige Authentifizierung durchsetzt, verfügt nur über eine unvollständige Sicherheitsarchitektur. Die Sicherheitsvalidierung im IoT muss den gesamten Handshake-Pfad vom Gerät zur Plattform abdecken, einschließlich der Netzwerkschicht (private APN), der Transportschicht (TLS-Konfiguration) und der Anwendungsschicht (Verarbeitung von Authentifizierungstoken und Sitzungsverwaltung).
Datenformate und Protokolle zur „ Device Management “
Auf der Anwendungsebene wirken sich Protokollentscheidungen am unmittelbarsten auf die Komplexität der Plattformintegration aus.
LwM2M (Lightweight M2M, OMA SpecWorks) ist das für das Internet der Dinge (IoT) entwickelte Gerätemanagementprotokoll, das Geräteregistrierung, die Bereitstellung von Firmware-Updates per OTA, Fernkonfiguration und Telemetrieberichterstattung in einem einzigen Protokollrahmen vereint. Sein Datenmodell nutzt eine standardisierte Objekt- und Ressourcenhierarchie, die es Gerätemanagementplattformen ermöglicht, mit jedem LwM2M-konformen Gerät zu interagieren, ohne dass gerätespezifische Integrationsarbeiten erforderlich sind. Bei Unternehmensimplementierungen, bei denen große, heterogene Gerätebestände verwaltet werden, reduziert das standardisierte Verwaltungsmodell von LwM2M den Integrationsaufwand für die Aufnahme neuer Gerätetypen in den Gerätebestand erheblich.
Überlegungen zum FOTA-Protokoll (Firmware Over The Air) auf der Anwendungsebene werden bei der Planung der Bereitstellung oft nicht ausreichend berücksichtigt. Firmware-Update-Pakete für IoT-Geräte können eine Größe von einigen zehn Kilobyte bis zu mehreren Megabyte haben. Das FOTA-Protokoll muss Folgendes berücksichtigen:
- Wiederherstellung nach einer unterbrochenen Übertragung, da bei einem Gerät vom Typ „ NB-IoT “ oder „ LTE-M“ die Verbindung während eines Firmware-Downloads unterbrochen werden kann
- Delta-Update-Unterstützung, bei der statt des vollständigen Images nur geänderte Firmware-Segmente übertragen werden, wodurch sich die Übertragungsgröße und der Stromverbrauch verringern
- Möglichkeit zum Rollback, falls die neue Firmware die Validierung auf dem Gerät nicht besteht
Format zur Datenserialisierung Die Wahl des Formats auf der Anwendungsebene beeinflusst die Übertragungseffizienz und die Komplexität der Plattformintegration. JSON wird weitgehend unterstützt und ist für Menschen lesbar, verursacht jedoch im Vergleich zu Binärformaten bei Geräten mit begrenzten Ressourcen einen erheblichen Mehraufwand. CBOR (Concise Binary Object Representation) bietet eine mit JSON vergleichbare Ausdruckskraft in einer binären Kodierung, die die Nutzdatengröße in der Regel um 50 bis 70 Prozent reduziert. Für Geräte mit „ NB-IoT “, die mit hoher Frequenz senden oder unter engen Leistungsbeschränkungen arbeiten, führt die Reduzierung der Nutzdatenmenge durch CBOR im Vergleich zu JSON direkt zu einer längeren Akkulaufzeit und geringeren Datenkosten.
Kohärenz des Protokollstacks im Unternehmensmaßstab
Die oben beschriebenen Entscheidungen bezüglich des Protokollstacks wirken nicht isoliert. Eine Implementierung, bei der auf der physikalischen Schicht „ NB-IoT “, auf der Transportschicht „MQTT über TCP“ und auf der Sicherheitsschicht „TLS 1.2 mit vollständigem Handshake“ gewählt wird, führt zu einem Stack, bei dem der Overhead der Transport- und Sicherheitsschicht das Strombudget des Geräts derart dominieren kann, dass die Energieeffizienz – die ursprüngliche Begründung für die Wahl von „ NB-IoT “ – untergraben wird. CoAP über UDP mit DTLS wäre der geeignete Stack für ein NB-IoT -Gerät mit begrenzter Leistungsaufnahme, während MQTT über TCP mit TLS der geeignete Stack für ein LTE-M-Gerät mit einem großzügigeren Leistungsbudget ist.
Die Kohärenz des Protokollstacks ist auch für die Konnektivitätsinfrastruktur von Bedeutung. Eine Bereitstellung, bei der Geräte über ein privates APN mit statischer IP-Adressierung verbunden sind, über MQTT mit einem Cloud-Broker kommunizieren und die gegenseitige X.509-Authentifizierung nutzen, stellt spezifische Anforderungen an die Konnektivitätsmanagement-Plattform: die Bereitstellung privater APN , die Zuweisung statischer IP-Adressen sowie das Zertifikatslebenszyklusmanagement, das in die Geräteidentitätsinfrastruktur integriert ist.
Die Konnektivitätsinfrastruktur von KORE bildet die Grundlage auf Netzwerkebene, auf die sich die Protokollstacks von Unternehmen stützen, einschließlich der Konfiguration privater „ APN “, der Bereitstellung statischer IP-Adressen und der Konnektivität über mehrere Netzbetreiber hinweg – dank Partnerschaften mit mehr als 40 Netzbetreibern und einer Präsenz in über 200 Ländern. Die „ ConnectivityPro “-Plattform bietet das SIM-Lebenszyklusmanagement und die Netzwerkrichtlinienkontrollen, die die Konnektivitätsschicht steuern, unabhängig davon, welcher Anwendungsprotokollstapel in der jeweiligen Bereitstellung zum Einsatz kommt. Mit über 21 Millionen aktiven SIM-Karten, die in verschiedenen Branchen eingesetzt werden, in denen die Kohärenz des Protokollstapels direkten Einfluss auf die betrieblichen Ergebnisse hat, ist die Infrastruktur darauf ausgelegt, die gesamte Bandbreite an IoT-Konnektivitätskonfigurationen für Unternehmen zu unterstützen, die für Produktionsumgebungen erforderlich sind.
Um den Protokollstapel korrekt zu gestalten, muss jede Schicht im Zusammenhang mit den angrenzenden Schichten bewertet und der gesamte Stapel von Ende zu Ende validiert werden, bevor die Bereitstellung in großem Maßstab auf der Hardware erfolgt. Die Integrationsprobleme, die sich aus Protokollinkongruenzen ergeben, sind lösbar, doch ist ihre Behebung im Labor kostengünstiger als im Praxiseinsatz.
Sprechen Sie mit einem KORE-Netzwerkingenieur über die Anforderungen an die Infrastruktur auf Netzwerkebene für Ihren IoT-Protokollstapel.
Veröffentlicht am 29. Mai 2026.