IoT-architecten binnen bedrijven besteden veel tijd aan het evalueren van hardware en connectiviteitstechnologie, en minder tijd aan het in kaart brengen van de protocolstack die bepaalt hoe apparaten, netwerken en platforms met elkaar communiceren. Die onevenwichtigheid komt vaak tot uiting in integratieproblemen na de implementatie: apparaten die zich niet bij het platform kunnen authenticeren, gegevens die binnenkomen in formaten die de head-end niet kan parseren, firmware-updates die mislukken omdat het OTA-transportprotocol niet is gevalideerd ten opzichte van het beschikbare geheugen van het apparaat, en beveiligingskwetsbaarheden die voortkomen uit protocolconflicten tussen lagen.
De IoT-protocolstack bestaat uit een gelaagde reeks standaarden, die elk een ander aspect regelen van de manier waarop gegevens van een fysieke sensor naar een toepassing worden verzonden. Keuzes op elke laag beperken of maken keuzes op aangrenzende lagen mogelijk, en de interacties tussen die keuzes bepalen of de volledige stack functioneert als een samenhangend systeem of als een verzameling afzonderlijk gevalideerde componenten die wrijving veroorzaken op de raakvlakken.
In dit artikel wordt de IoT-protocolstack behandeld, vanaf de fysieke verbindingslaag tot en met de applicatielaag. Daarbij wordt ingegaan op de standaarden die relevant zijn voor implementaties binnen ondernemingen, de afwegingen op elke laag en de integratieaspecten die bepalen of de stack op grote schaal goed functioneert.
Fysieke laag en toegangslaag: mobiele communicatiestandaarden
De fysieke laag en de toegangslaag bepalen hoe een apparaat een radioverbinding met een netwerk tot stand brengt. Voor IoT in bedrijfsomgevingen is het de moeite waard om de relevante mobiele communicatiestandaarden en hun onderlinge verhouding in kaart te brengen, omdat de marketingtaal rond deze technologieën soms onnauwkeurig kan zijn, wat van invloed kan zijn op beslissingen over de implementatie.
NB-IoT (Narrowband IoT, 3GPP Release 13 en later) werkt in een kanaal van 180 kHz binnen het gelicentieerde spectrum, hetzij in-band binnen een ' LTE '-draaggolf, in de ' LTE '-waakband, of in een standalone-implementatie op heringedeeld ' GSM '-spectrum. Belangrijkste kenmerken van de fysieke laag:
- Maximale downlink-doorvoersnelheid: ongeveer 250 kbps in single-tone-modus
- Maximale uplink-doorvoersnelheid: ongeveer 250 kbps
- Linkbudget: maximaal koppelingsverlies van 164 dBm, een verbetering van ongeveer 20 dB ten opzichte van GPRS
- Vertraging: 1,6 tot 10 seconden voor een standaard gegevensoverdracht, inclusief het opzetten ervan, waardoor het ongeschikt is voor toepassingen die een reactietijd van minder dan een seconde vereisen
- Duplexmodus: alleen half-duplex
LTE-M (LTE-MTC, Cat-M1, 3GPP Release 13) werkt in een kanaal van 1,4 MHz binnen het LTE -spectrum met ondersteuning voor full-duplex. Belangrijkste kenmerken van de fysieke laag:
- Maximale downlink-doorvoersnelheid: ongeveer 1 Mbps
- Maximale uplink-doorvoersnelheid: ongeveer 1 Mbps
- Linkbudget: maximaal koppelingsverlies van 155,7 dBm, een verbetering van ongeveer 15 dB ten opzichte van GPRS
- Vertraging: 10 tot 15 ms voor gegevensoverdracht nadat de verbinding tot stand is gebracht
- Duplexmodus: ondersteuning voor full-duplex, waardoor spraak en bidirectionele realtime gegevensoverdracht mogelijk zijn
5G NR voor IoT introduceert twee relevante apparaatcategorieën: RedCap (Reduced Capability, 3GPP Release 17), gericht op middenklasse IoT-apparaten die een hogere doorvoersnelheid vereisen dan LTE-M, maar een lager stroomverbruik dan full- 5G -NR-UE, en standaard 5G -NR voor IoT-toepassingen met hoge bandbreedte. RedCap streeft naar een doorvoersnelheid van 5 tot 25 Mbps met een lager stroomverbruik en minder complexiteit in vergelijking met full- 5G -NR, en vult daarmee de leemte tussen LTE-M en full- 5G , die in het verleden werd ingenomen door 4G Cat-4-apparaten.
De keuze van de fysieke laag bepaalt de boven- en ondergrens voor elke laag daarboven. Een protocolstack die is ontworpen voor bidirectionele communicatie binnen een fractie van een seconde en is gebaseerd op NB-IoT , zal op de fysieke laag falen nog voordat het applicatieprotocol de kans krijgt om te functioneren.
Netwerklaag: IP-adressering en routing voor het IoT
De meeste IoT-apparaten in bedrijfsomgevingen communiceren via IPv4 of IPv6, maar de configuratie van de netwerklaag – die bepaalt hoe die adressen worden toegewezen en beheerd – heeft operationele gevolgen die niet naar voren komen in de specificaties van de fysieke laag.
Architectuur van een privé APN is de standaardconfiguratie op netwerklaag voor IoT-implementaties binnen ondernemingen waar gegevensbeveiliging of wettelijke vereisten van toepassing zijn. In plaats van het verkeer van apparaten via de gedeelde openbare APN van de provider naar het openbare internet te routeren, creëert een private APN een speciaal netwerkpad van het apparaat naar de backend-infrastructuur van de onderneming. Verkeer op een private APN gaat niet via het openbare internet, wat van belang is voor:
- Naleving van regelgeving in sectoren waar gegevens de grenzen van het bedrijfsnetwerk niet mogen verlaten
- Kleiner aanvalsoppervlak, aangezien apparaten niet rechtstreeks bereikbaar zijn via het openbare internet
- Deterministische routing, aangezien het verkeer via het private APN vaste netwerkpaden volgt in plaats van de routing via het openbare internet
IPv6 voor het IoT is relevant omdat het opraken van IPv4-adressen het moeilijk maakt om grootschalige IoT-implementaties individueel te adresseren. Bij een implementatie van een miljoen slimme meters, die elk een routeerbaar IP-adres nodig hebben voor communicatie vanuit de head-end, stuit men op praktische beperkingen bij de toewijzing van IPv4-adressen, die met IPv6 worden weggenomen. IPv6 vereenvoudigt ook de end-to-end-adresseerbaarheid in architecturen waarin apparaten individueel bereikbaar moeten zijn zonder NAT-traversal.
Overwegingen met betrekking tot CGNAT hebben invloed op implementaties waarbij carrier-grade NAT zich tussen het apparaat en de backend van de onderneming bevindt, wat de standaardconfiguratie is voor de meeste tariefplannen voor consumenten en standaard IoT-abonnementen. CGNAT verhindert inkomende verbindingen naar apparaten, wat betekent dat elke architectuur die communicatie vereist die vanuit de head-end naar individuele apparaten wordt geïnitieerd, ofwel een privé- APN, een altijd actieve, door het apparaat geïnitieerde verbinding, of een apparaat vereist dat een permanente sessie met het backend-platform in stand houdt. Architecten die tijdens het ontwerp geen rekening houden met CGNAT, komen er pas achter tijdens de integratietests, waarna de oplossingen duurder uitvallen.
Transportlaag: protocolkeuze voor de overdracht van IoT-gegevens
De transportlaag bepaalt hoe gegevens worden verpakt en op betrouwbare (of juist opzettelijk onbetrouwbare) wijze worden verzonden tussen het apparaat en het platform. De gangbare transportprotocollen in bedrijfs-IoT maken elk verschillende afwegingen die aansluiten bij verschillende toepassingsprofielen.
MQTT (Message Queuing Telemetry Transport) is het meest gebruikte IoT-transportprotocol voor apparaten met een mobiele verbinding. Dankzij de publish-subscribe-architectuur, de geringe overhead (minimaal 2 bytes vaste header) en de ondersteuning voor drie QoS-niveaus is het bij uitstek geschikt voor apparaten met beperkte middelen die regelmatig kleine gegevenspakketten verzenden via mogelijk onbetrouwbare verbindingen:
- QoS 0 (hooguit één keer): ‘fire and forget’, geen bevestiging, minimale overhead
- QoS 1 (minstens één keer): gegarandeerde bezorging met ontvangstbevestiging, mogelijke duplicaten
- QoS 2 (precies één keer): gegarandeerde eenmalige bezorging, hoogste overhead
Dankzij de functie voor permanente sessies van MQTT kunnen apparaten na een onderbreking in de verbinding opnieuw verbinding maken en berichten ontvangen die tijdens de offlineperiode door de broker in de wachtrij zijn geplaatst. Dit is belangrijk voor apparaten met een „ NB-IoT ” in PSM die periodiek onbereikbaar zijn.
CoAP (Constrained Application Protocol) is ontworpen voor apparaten met de meest beperkte systeembronnen, waarbij de TCP-vereiste van MQTT onaanvaardbare overhead veroorzaakt. CoAP draait v UDP, maakt gebruik van een request-response-model dat vergelijkbaar is met HTTP, maar met een binaire header die is geoptimaliseerd voor omgevingen met beperkte systeembronnen, en ondersteunt observe-functionaliteit voor publish-subscribe-achtig gedrag. Het is de juiste transportkeuze voor NB-IoT -apparaten waarbij de overhead van TCP-verbindingsbeheer het stroomverbruik aanzienlijk zou beïnvloeden.
AMQP (Advanced Message Queuing Protocol) is vooral relevant op het niveau van de backend-integratielaag en niet zozeer op het niveau van de verbinding tussen apparaten en de cloud. Dankzij de uitgebreidere mogelijkheden voor het routeren van berichten, de ondersteuning voor transacties en de compatibiliteit met enterprise-messagebrokers is het de standaardtransportprotocol voor het koppelen van IoT-platforms aan backend-systemen van ondernemingen: ERP-, assetmanagement- en operationele technologieplatforms die AMQP-compatibele messagebrokers vereisen.
HTTPS/REST blijft relevant voor IoT-apparaten met voldoende rekenkracht en waarbij het gebruiksgemak van REST API -integratie opweegt tegen de overhead van HTTP. Hoogwaardige IoT-gateways, edge-rekenknooppunten en apparaten met 4G- of 5G -connectiviteit maken doorgaans gebruik van REST voor platformintegratie, met name in implementaties waarbij het operationele team dat de backend-integratie beheert, meer vertrouwd is met web API -patronen dan met de configuratie van MQTT-brokers.
Beveiligingslaag: normen voor authenticatie en Encryption
De keuze van beveiligingsprotocollen in het IoT wordt bemoeilijkt door de beperkingen op het gebied van rekenkracht en geheugen van edge-apparaten, waardoor de beveiligingsprotocollen die in IT-omgevingen van bedrijven de norm zijn, op dergelijke apparaten met beperkte hardware onpraktisch of onmogelijk te implementeren zijn.
TLS 1.2 en TLS 1.3 zijn de standaardversleutelingsprotocollen voor IoT-apparaten met voldoende rekenkracht. TLS 1.3 vermindert de handshake-latentie ten opzichte van TLS 1.2 door één round-trip uit de handshake-reeks te elimineren, wat van belang is voor apparaten met NB-IoT en LTE-M, waarbij elke radiotransmissie meetbare energiekosten met zich meebrengt. De keuze van de cipher suite binnen TLS is van belang voor IoT: ECDHE-sleuteluitwisseling en AES-128-GCM zijn de aanbevolen combinatie voor IoT-implementaties waarbij een evenwicht wordt gezocht tussen beveiligingssterkte en rekenkracht.
DTLS (Datagram TLS) is het geschikte beveiligingsprotocol voor CoAP-implementaties en biedt dezelfde beveiligingsgaranties als TLS voor vervoer op basis v UDP.
Wederzijdse authenticatie op basis van X.509-certificaten is het aanbevolen authenticatiemechanisme voor apparaten bij grootschalige IoT-implementaties binnen ondernemingen. Vooraf gedeelde sleutels zijn eenvoudiger te implementeren, maar leiden bij grote aantallen apparaten tot problemen met het sleutelbeheer: het rouleren van een gecompromitteerde vooraf gedeelde sleutel over miljoenen geïmplementeerde apparaten is operationeel zeer intensief. X.509-certificaten met individuele apparaatidentiteiten maken het mogelijk om certificaten per apparaat te rouleren en in te trekken zonder dat dit gevolgen heeft voor andere apparaten in het netwerk.
Hardwarebeveiligingsmodules (HSM) en Trusted Execution Environments (TEE) worden steeds relevanter voor IoT-apparaten in bedrijfsomgevingen die gevoelige gegevens verwerken of worden gebruikt in omgevingen waar het risico bestaat dat onbevoegden fysieke toegang tot het apparaat krijgen. Door privésleutels op te slaan in een door hardware beveiligd onderdeel in plaats van in het firmwaregeheugen, wordt het onmogelijk gemaakt om de sleutels te extraheren, zelfs als de firmware van het apparaat wordt gecompromitteerd.
De beveiligingsprotocolstack moet vóór de implementatie van begin tot eind worden gevalideerd. Een apparaat dat TLS correct implementeert, maar verbinding maakt met een platform-eindpunt dat geen wederzijdse authenticatie afdwingt, beschikt slechts over een halve beveiligingsarchitectuur. Beveiligingsvalidatie in het IoT moet het volledige handshake-traject van apparaat naar platform omvatten, inclusief de netwerklaag (private APN), de transportlaag (TLS-configuratie) en de applicatielaag (verwerking van authenticatietokens en sessiebeheer).
Gegevensformaten en protocollen voor de uitwisseling van gegevens ( Device Management )
Op de applicatielaag hebben beslissingen over protocollen de meest directe invloed op de complexiteit van de platformintegratie.
LwM2M (Lightweight M2M, OMA SpecWorks) is het apparaatbeheerprotocol dat is ontworpen voor het IoT en dat apparaatregistratie, het leveren van OTA-firmware-updates, configuratie op afstand en telemetrierapportage in één enkel protocolraamwerk omvat. Het datamodel maakt gebruik van een gestandaardiseerde object- en bronhiërarchie, waardoor apparaatbeheerplatforms kunnen communiceren met elk LwM2M-conform apparaat zonder dat er apparaatspecifieke integratiewerkzaamheden nodig zijn. Voor bedrijfsimplementaties waarbij grote, heterogene apparaatpopulaties worden beheerd, vermindert het gestandaardiseerde beheermodel van LwM2M de integratie-overhead bij het toevoegen van nieuwe apparaattypen aan het apparaatpark aanzienlijk.
Overwegingen met betrekking tot het FOTA-protocol (Firmware Over The Air) op de applicatielaag worden vaak onvoldoende gespecificeerd tijdens het ontwerp van de implementatie. Firmware-updatepakketten voor IoT-apparaten kunnen variëren van tientallen kilobytes tot enkele megabytes. Het FOTA-protocol moet rekening houden met:
- Herstel van een onderbroken overdracht, aangezien een apparaat met NB-IoT of LTE-M halverwege het downloaden van firmware de verbinding kan verliezen
- Ondersteuning voor Delta-updates, waarbij alleen gewijzigde firmware-segmenten worden verzonden in plaats van het volledige beeld, waardoor de overdrachtsgrootte en het stroomverbruik worden verminderd
- Mogelijkheid om terug te zetten als de nieuwe firmware de validatie op het apparaat niet doorstaat
Formaat voor gegevensserialisatie Keuzes op de applicatielaag beïnvloeden de transmissie-efficiëntie en de complexiteit van de platformintegratie. JSON wordt breed ondersteund en is leesbaar voor mensen, maar brengt aanzienlijke overhead met zich mee in vergelijking met binaire formaten voor apparaten met beperkte middelen. CBOR (Concise Binary Object Representation) biedt een uitdrukkingskracht die gelijkwaardig is aan die van JSON in een binaire codering die de payloadgrootte doorgaans met 50 tot 70 procent vermindert. Voor NB-IoT -apparaten die met hoge frequentie gegevens verzenden of te maken hebben met krappe energiebudgetten, vertaalt de vermindering van de payload door CBOR ten opzichte van JSON zich direct in een langere levensduur van de batterij en lagere datakosten.
Coherentie van de protocolstack op bedrijfsniveau
De hierboven beschreven keuzes met betrekking tot de protocolstack werken niet onafhankelijk van elkaar. Een implementatie waarbij op de fysieke laag voor ‘ NB-IoT ’ wordt gekozen, op de transportlaag voor MQTT over TCP en op de beveiligingslaag voor TLS 1.2 met volledige handshake, resulteert in een stack waarbij de overhead van de transport- en beveiligingslaag het stroomverbruik van het apparaat zodanig kan domineren dat dit de energie-efficiëntie ondermijnt – de reden waarom in eerste instantie voor ‘ NB-IoT ’ is gekozen. CoAP via UDP met DTLS zou de logische stack zijn voor een apparaat met beperkte stroomvoorziening ( NB-IoT ), terwijl MQTT via TCP met TLS de geschikte stack is voor een apparaat met een ruimere stroomvoorziening ( LTE-M).
De samenhang van de protocolstack is ook van belang voor de connectiviteitsinfrastructuur. Een implementatie waarbij apparaten verbinding maken via een privé APN met statische IP-adressen, via MQTT communiceren met een cloudbroker en gebruikmaken van wederzijdse X.509-authenticatie, stelt specifieke eisen aan het platform voor connectiviteitsbeheer: het inrichten van privé APN , het toewijzen van statische IP-adressen en het beheer van de levenscyclus van certificaten dat is geïntegreerd met de identiteitsinfrastructuur van de apparaten.
De connectiviteitsinfrastructuur van KORE vormt de basis van de netwerklaag waarop de protocolstacks van ondernemingen steunen, met inbegrip van de configuratie van private APN , de toewijzing van statische IP-adressen en connectiviteit via meerdere providers via meer dan 40 partnerschappen met providers en in meer dan 200 landen. Het ‘ ConnectivityPro ’-platform biedt beheer van de SIM-levenscyclus en netwerkbeleidsregels die de connectiviteitslaag regelen, ongeacht de applicatieprotocolstack waarop de implementatie draait. Met meer dan 21 miljoen actieve SIM-kaarten die zijn ingezet in sectoren waar de samenhang van de protocolstack rechtstreeks van invloed is op de operationele resultaten, is de infrastructuur gebouwd om het volledige scala aan zakelijke IoT-connectiviteitsconfiguraties te ondersteunen die productie-implementaties vereisen.
Om de protocolstack correct op te zetten, moet elke laag worden beoordeeld in de context van de aangrenzende lagen, en moet de volledige stack van begin tot eind worden getest voordat deze op grote schaal in de hardware wordt geïmplementeerd. De integratieproblemen die voortvloeien uit protocolconflicten zijn oplosbaar, maar het is goedkoper om deze op een testbank op te lossen dan in de praktijk.
Neem contact op met een KORE-connectiviteitsingenieur om de infrastructuurvereisten op netwerkniveau voor uw IoT-protocolstack te bespreken.
Gepubliceerd op 29 mei 2026.