Het Internet Protocol, of IP, is een van de succesvolste technologieën in de computerwereld. Bijna vijftig jaar na de uitvinding vormt het ook de basis van meer en meer domotica- en iot-protocollen, zoals Thread, Matter (voorheen Connected Home over IP), NB-IoT en LTE-M. In dit artikel gaan we nader in op deze op het Internet Protocol gebaseerde technieken en het gebruik voor smarthometoepassingen en internet of things. Wat is Thread nu precies bijvoorbeeld? Ook staan we aan het slot even stil bij de beveiliging.
Vint Cerf
In 1974 publiceerden computerpioniers Vint Cerf en Bob Kahn hun paper A Protocol for Packet Network Intercommunication in IEEE Transactions on Communications, het wetenschappelijke tijdschrift van het Institute of Electrical and Electronics Engineers. Ze beschreven daarin een model om netwerken aan elkaar te koppelen, dat bekend werd als TCP/IP, naar de twee centrale componenten: Transmission Control Protocol en Internet Protocol.
In de jaren erna volgden enkele nieuwe versies. Zo werden TCP en IP van elkaar gescheiden, en in 1981 werd IPv4 gestandaardiseerd in RFC 791. Later volgde nog IPv6. In plaats van de 32bit-adressen van IPv4 gebruikt dit protocol 128bit-adressen. Dat verhoogt het aantal beschikbare adressen van 4,3 miljard naar 3,4 maal 10 tot de 38e macht. IPv6 is gestandaardiseerd als RFC 8200.
IP is een essentiële component in de internetprotocolsuite die beschrijft hoe communicatie tussen twee toepassingen op verschillende apparaten verloopt. De internetprotocolsuite, TCP/IP, is een vereenvoudigde versie van het OSI-model en bestaat uit vier lagen, van onder naar boven:
Verbindingslaag
Deze laag definieert de verbinding die het apparaat heeft met het lokale netwerk. Protocollen als ethernet en wifi werken in deze laag.
Netwerklaag
De netwerklaag maakt communicatie over netwerkgrenzen heen mogelijk, wat routing wordt genoemd. Het Internet Protocol werkt in deze laag en definieert IP-adressen.
Transportlaag
Deze laag maakt communicatie tussen twee apparaten mogelijk, hetzij op hetzelfde netwerk, hetzij op verschillende netwerken met routers ertussen. De transportlaag definieert ook het concept van een poort. Het UDP en TCP werken in deze laag.
Applicatielaag
De applicatielaag verzorgt de communicatie tussen applicaties op dezelfde of verschillende apparaten. Protocollen als HTTP(S), DNS, SMTP en MQTT werken in deze laag.
De overgedragen data wordt in de internetprotocolsuite ingekapseld in vier lagen. Bron: Colin Burnett, CC BY-SA 3.0
Protocollen voor domotica en iot
Veel domoticaprotocollen gebruiken een alternatief voor de internetprotocolsuite. Zo hebben Z-Wave en Zigbee hun eigen protocolstapel gedefinieerd die niet met IP-adressen werkt. Als je dan toestellen van deze technologie met je op IP gebaseerde thuisnetwerk wilt laten communiceren, heb je een gateway nodig die de data van het domoticaprotocol omzet in IP-pakketten en andersom. Dat is de bestaansreden van projecten als Zwavejs2Mqtt en Zigbee2MQTT.
Ook in het internet of things spelen niet-IP-netwerken nog een grote rol. Denk maar aan LoRaWAN, een technologie voor low-power wide-area networking, of lpwan, dat door The Things Network populair is gemaakt. Ook hier zijn gateways nodig die de LoRa-signalen omzetten in IP-pakketten voor de netwerkserver en andersom. Daardoor kun je metingen van LoRaWAN-sensors via het applicatieprotocol MQTT uitlezen. Het IP-gedeelte begint echter pas vanaf de communicatie tussen gateway en netwerkserver; de enddevices spreken geen IP.
Hoewel de technologie achter de internetprotocolsuite al bijna vijftig jaar oud is, zien we dat IP ondertussen ook in protocollen voor domotica en iot wordt gebruikt.
Foto: metamorworks / Getty Images.
802.15.4 voor draadloze meshnetwerken
Een van die op IP gebaseerde protocollen voor domoticanetwerken is Thread, ontwikkeld door de Thread Group. Het is een low-powerprotocol voor draadloze meshnetwerken. Thread werkt in de netwerklaag en transportlaag.
Voor de verbindingslaag bouwt Thread voort op IEEE 802.15.4, waarop ook Zigbee is gebaseerd. Deze radiostandaard werkt in de licentievrije frequentieband van 2,4GHz met gegevenssnelheden tot 250kbit/s, en in Europa en Noord-Amerika ook met kanalen op 868MHz respectievelijk 920MHz. De focus ligt op een laag energiegebruik, zodat apparaten zolang mogelijk op een batterijlading kunnen communiceren. Het bereik is rechtstreeks zo’n tien meter, maar de meshfunctionaliteit breidt dat uit. 802.15.4 heeft encryptie en authenticatie ingebouwd.
Elke 802.15.4-node heeft een EUI-64-adres dat als MAC-adres wordt gebruikt. Als een node tot een netwerk toetreedt, krijgt die ook een 16bit-verkort adres toegekend, waardoor de verzonden pakketjes korter kunnen zijn.
6LoWPAN: IPv6 voor alle apparaten
De netwerklaag van Thread bestaat uit 6LoWPAN. Het is een IETF-specificatie die wordt beschreven in RFC 4944. De bedoeling van 6LoWPAN is om zelfs de kleinste apparaten met beperkte processorkracht en lage energievereisten deel te laten uitmaken van het internet of things.
6LoWPAN zorgt er in essentie voor dat je een IPv6-netwerk over de verbindingslaag 802.15.4 kunt draaien. Het is een 'aanpassingslaag' tussen IPv6 en 802.15.4, en wordt daarom ook weleens als deel van de verbindingslaag beschouwd. Voor die 'aanpassing' moeten enkele uitdagingen worden opgelost. Zo kan de mtu in IPv6 1280 bytes groot zijn, terwijl de lengte van een frame in 802.15.4 beperkt is tot 127 bytes. 6LoWPAN lost dat op door informatie die al uit de 802.15.4-frames af te leiden is, niet in de 6LoWPAN-header op te nemen en door gebruik te maken van lokale, verkorte adressen. Is de payload dan nog te groot, dan wordt die in fragmenten onderverdeeld.
De link-local IPv6-adressen van 6LoWPAN-apparaten zijn afgeleid van de IEEE 802.15.4 EUI-64-adressen en hun verkorte 16bit-adressen. De apparaten in een 6LoWPAN-netwerk kunnen via hun IPv6-adres rechtstreeks communiceren met ‘normale’ IPv6-apparaten in een netwerk als dit verbonden is via een edgerouter. Er is dus geen vertaalslag met een gateway nodig zoals bij Zigbee of Z-Wave, maar het gaat puur om het doorsturen van datapakketten in de netwerklaag.
Thread voegt 6LoWPAN en UDP toe boven de IEE 802.15.4-radio. Bron: Thread Group
Thread en Matter
Thread voegt nu 6LoWPAN en IP-routing (in de netwerklaag) en UDP (in de transportlaag) samen en voegt daar een manier aan toe om op een veilige en gebruiksvriendelijke manier apparaten aan het netwerk toe te voegen (secure commissioning).
Thread kent twee types apparaten: routers en enddevices. Een router heeft zijn 802.15.4-radio continu ingeschakeld en stuurt pakketten van andere Thread-apparaten door. Omdat dit meer energie gebruikt, zijn routers vaak op het lichtnet aangesloten. De Eve Energy-stopcontacten zijn voorbeelden van Thread-routers.
Een enddevice daarentegen stuurt geen pakketten door. Elk enddevice heeft een router nodig om te communiceren met de rest van het netwerk. Enddevices werken meestal op batterijen en besteden het grootste deel van hun tijd in slaapmodus. Zodra ze iets te zeggen hebben, ontwaken ze, sturen hun data - bijvoorbeeld die van een temperatuursensor - naar de router en gaan weer slapen.
Betrouwbaar meshnetwerk voor iot
De routers vormen de backbone van het Thread-netwerk. Ze sturen pakketten van hun enddevices naar elkaar door en zoeken zelf de efficiëntste route uit. Thread is een zelfhelend systeem; bij verbindingsproblemen zoeken de routers onmiddellijk een andere route. Enddevices die routermogelijkheden hebben, maar die momenteel niet gebruiken omdat er voldoende routers zijn (router eligible enddevices), kunnen zich ook tijdelijk upgraden tot router als dat nodig is. Bovendien heeft elk Thread-netwerk een leider die de routers beheert en die dynamisch uit de routers wordt gekozen.
De edgerouters van een Thread-netwerk worden borderrouters genoemd. Zo werkt de HomePod mini van Apple als Thread-borderrouter, maar je kunt ook zelf een OpenThread Border Router maken met een Raspberry Pi en een nRF52840-dongel van Nordic Semiconductor. En ook hier is weer redundantie mogelijk. Als je je Thread-netwerk via verschillende borderrouters met je thuisnetwerk hebt verbonden, blijven je Thread-apparaten via hun IPv6-adres bereikbaar als er een borderrouter uitvalt.
De backbone van een Thread-netwerk bestaat uit routers, terwijl de borderrouter het netwerk met internet verbindt. Bron: Thread Group
Applicatielagen boven Thread
In tegenstelling tot Zigbee en Z-Wave definieert Thread geen applicatielaag. Thread vormt met UDP/6LoWPAN de basis voor allerlei applicatieprotocols daarboven, net zoals TCP/IP dat voor klassieke applicatieprotocols zoals HTTP doet. Zo zijn er al HomeKit-apparaten die van Thread gebruikmaken, zoals de al vermelde HomePod mini en ook de nieuwe versie van de Apple TV 4K, maar ook heel wat apparaten van Eve en verlichting van Nanoleaf.
Een andere applicatielaag die op Thread voortbouwt, is Matter, in zijn prototypefase bekend als Connected Home over IP. Matter werd verrassend genoeg ontwikkeld door de Zigbee Alliance, die sinds de introductie van de definitieve naam van Matter haar naam ook heeft veranderd in Connectivity Standards Alliance. Amazon, Apple en Google zijn actieve leden van de CSA, evenals Tuya, Signify, IKEA, Samsung (SmartThings), en ook chipmakers zoals NXP, STMicroelectronics en Texas Instruments. De eerste gecertificeerde Matter-apparaten worden tegen het einde van het jaar verwacht.
Matter: gemeenschappelijke applicatielaag voor domotica
Zoals de vorige naam van Matter al aangeeft, staat IP centraal in deze iot-standaard. Matter werkt nu al boven Thread, wifi en ethernet. Andere technologieën voor connectiviteit via IP, zoals het mobiele netwerk, worden in de toekomst toegevoegd. De applicatielaag van Matter is overigens sterk geïnspireerd door die van Zigbee, ZCL.
Matter werkt volledig lokaal; je hebt dus geen clouddiensten nodig. Doordat de apparaten die Matter ondersteunen, op IP gebaseerd zijn, kunnen ze echter nog altijd verbinding maken met clouddiensten. Dat is bijvoorbeeld nodig om met de stemassistenten van Apple, Google en Amazon samen te werken. Die communicatie verloopt dan niet via het applicatieprotocol Matter, maar via de api’s van de clouddiensten. Wil je ook apparaten met een niet op IP gebaseerd protocol met je Matter-apparaten laten samenwerken, dan heb je nog altijd een gateway nodig, bijvoorbeeld voor Zigbee of Z-Wave.
Matter (voorheen Connected Home over IP) is een gestandaardiseerde applicatielaag voor domotica. Bron: Connectivity Standards Alliance
Iot-netwerk van de mobiele operators
Voor communicatie met iot-apparaten op grotere afstanden heb je een lpwan, nodig. LoRaWAN en Sigfox doen dat buiten het bestaande mobiele netwerk. De mobiele operators hebben uiteraard ook niet stilgezeten, want zij hebben al een hele infrastructuur. De traditionele 2G-, 3G- en 4G-netwerken zijn echter te energieverslindend voor veel door batterijen gevoede iot-toepassingen.
Daarom heeft de 3GPP, de organisatie die de gsm-communicatiestandaarden ontwikkelt, enkele jaren geleden ook lpwan-standaarden voor mobiele netwerken ontwikkeld. De belangrijkste zijn LTE-M en NB-IoT, die beide op IP gebaseerd zijn en werden geïntroduceerd in 3GPP Release 13. 5G biedt overigens ook op IP gebaseerde connectiviteit voor iot.
Voordelen van mobiele iot-netwerken
Het voordeel van LTE-M en NB-IoT ten opzichte van LoRaWAN en Sigfox is dat deze mobiele iot-netwerken op IP gebaseerd zijn en er dus geen gateway nodig is om ermee te communiceren. Een apparaat verbinden met het netwerk is ook vrij eenvoudig; je steekt er gewoon een geactiveerde simkaart in en je bent vertrokken. Doordat bestaande infrastructuur wordt gebruikt, is het bereik ook vrij goed.
LTE-M en NB-IoT gebruiken gereguleerde frequentiebanden, dus je kunt niet zomaar zelf een privénetwerk opzetten zoals bij LoRaWAN. Iot-apparaten kunnen op deze netwerken wel tot 23dBm verzenden en zoveel airtime innemen als ze willen. Vergelijk dat met LoRaWAN, waarmee in de Europese, licentievrije band rond 868MHz het maximumzendvermogen van apparaat naar gateway is beperkt tot 25mW, of 14dBm, en er maar tot één procent van de tijd mag worden verzonden.
LTE-M
Het grote voordeel van LTE-M is dat het compatibel is met het bestaande LTE-netwerk. Met een softwarepatch in hun infrastructuur kunnen mobiele operators het activeren. LTE-M kan hogere bandbreedten aan dan NB-IoT. Voor ontwikkelaars van iot-apparaten lijkt werken met LTE-M dan ook nog het meest op werken met een klassiek IP-netwerk, zonder al te drastische beperkingen. Je kunt eenvoudigweg gebruikmaken van applicatieprotocols als MQTT.
Een ideale toepassing voor deze technologie is een assettracker die bijvoorbeeld in een koelwagen continu de temperatuur meet en doorstuurt via het mobiele netwerk. Dat kan zelfs over de landsgrenzen heen dankzij roaming. Andere toepassingen zijn zelfrijdende auto’s en toestellen die in real time een waarschuwing moeten kunnen versturen.
NB-IoT: tien jaar op een batterijlading
NB-IoT werkt niet in de LTE-frequentieband. Het uitrollen van een NB-IoT-netwerk vereist dan ook meer dan een softwarepatch. Het toepassingsgebied van NB-IoT is te vergelijken met dat van LoRaWAN en Sigfox: apparaten die niet zo vaak kleine hoeveelheden data doorsturen en zo lang mogelijk op een batterijlading moeten meegaan. Denk daarbij aan temperatuursensors in een wijngaard of slimme meters in huizen. Een NB-IoT-apparaat kan op die manier jaren doen met een batterijlading.
NB-IoT heeft twee modi om te werken: met IP en zonder IP. Om kleine hoeveelheden data door te sturen, zoals bij sensors, is de laatste manier optimaal: NIDD. Apparaten communiceren dan en zijn bereikbaar via een SCEF, die de data van de apparaten via op IP gebaseerde api’s beschikbaar stelt. Het apparaat zelf heeft dan geen IP-stack nodig.
Een NB-IoT-apparaat dat wel met een IP-stack werkt, gebruikt doorgaans UDP, DTLS voor encryptie en daarboven geoptimaliseerde applicatieprotocols zoals CoAP. Die laatste is een soort lichtgewichtimplementatie van REST. CoAP kan ook in NIDD-modus werken. Een protocol als MQTT is niet aan te raden boven NB-IoT door de grote overhead. LTE-M is voor MQTT-toepassingen doorgaans een geschiktere netwerktechnologie.
Vaak draait een NB-IoT-apparaat boven CoAP het protocol LwM2M, een fabrikantonafhankelijke standaard van de Open Mobile Alliance voor het beheer van en de communicatie met iot-apparaten. Op die manier kunnen ontwikkelaars een abstractie maken van de onderliggende netwerklagen, zelfs met of zonder IP-stack. LwM2M werkt immers zelfs over sms of LoRaWAN.
LwM2M staat ontwikkelaars toe om een abstractie te maken van de onderliggende netwerklagen. Bron: Open Mobile Alliance
Beveiliging en conclusie
Er zit heel wat waarheid in de uitspraak 'There is no S for security in iot'. Vaak gaat het dan over fabrikanten die hun firmware niet patchen of onveilige standaardwachtwoorden gebruiken, maar ook de beveiliging van het netwerk mag niet vergeten worden. Als alle iot- of domotica-apparaten een IP-adres hebben, zijn ze namelijk ook gemakkelijker te bereiken door malware of mensen met kwade bedoelingen.
Bij een niet op IP gebaseerd systeem met gateway, zoals Z-Wave of LoRaWAN, is de gateway al een drempel voor toegang tot de apparaten. Rechtstreekse toegang tot het apparaat vanaf internet of zelfs het lokale netwerk is niet mogelijk, omdat het nu eenmaal geen IP spreekt. De gateway, en in het geval van LoRaWAN ook de netwerkserver en applicatieserver, filtert verzoeken op basis van de ingestelde authenticatie. En bij LoRaWAN heeft alleen de applicatieserver die bij het apparaat hoort, toegang tot de data van het apparaat, omdat die data met een applicatiespecifieke sleutel is vercijferd.
Bij een op IP gebaseerd domotica- of iot-netwerk is het daarom belangrijk dat de toegang voldoende wordt afgeschermd. Dat kan lokaal op het apparaat zelf en ook met een firewall in huis, als het om domotica gaat, of bij de telecomprovider. Alle voordelen van IP ten spijt beklemtonen heel wat spelers in de iot-wereld dat apparaten zonder IP-stack veiliger zijn. Uiteraard is het niet zo zwart-wit; in beide architecturen is voldoende aandacht voor beveiliging nodig, alleen verschilt de focus enigszins.
Conclusie
Al met al is het indrukwekkend dat een bijna vijftig jaar oude technologie zoals IP zelfs in de nieuwste technologieën rond domotica en iot nog een belangrijke rol speelt en zelfs aan belang lijkt te winnen. Dat low-costmicrocontrollers steeds krachtiger worden en een IP-stack daardoor binnen het bereik van steeds meer apparaten komt, is uiteraard een reden daarvoor. Het is echter ook te danken aan de gelaagde architectuur van de internetprotocolstack, waaruit relatief eenvoudig onderdelen zijn te vervangen door andere, die geoptimaliseerd zijn voor laag verbruik en minimale dataoverdracht.
Doordat de apparaten die Matter ondersteunen, op IP gebaseerd zijn, kunnen ze echter nog altijd verbinding maken met clouddiensten.
Als privacy designer die veel met IoT doet (Candle) vind ik ik Matter rampzalig. De hele reden dat Zigbee zo fijn is, is dat het NIET op IP gebaseerd is. Ik gok dat 99% van de IoT hacks plaats vindt over het IP protocol. Voor mijn eigen IoT gebruik ik bewust zo veel mogelijk Zigbee, want ik wil niet dat mijn apparaten zelfstandig data kunnen versturen naar een cloud server. Maar nu wordt deze feature van Zigbee in mijn beleving kapot gemaakt door haar afgeschermde aard als bug te framen. Het is weer eens een aanval op privacy door Google en co, terwijl de wereld (en Tweakers) niet door de mooie verhalen heen prikt.
Zigbee is geen standaard, zoals wifi een standaard is. In een Wifi netwerk hoef je je niet af te vragen of een apparaat van een andere fabrikant dat wifi ondersteund wel kan werken. De meeste Zigbee implementaties komen met hun eigen Hub (hey Hue) en weigeren met andere Zigbee apparaten te werken. Die hub stuurt alles naar een cloud van een bedenkelijke configuratie en komt altijd met Google, Alexa en Apple connecties. Dat betekent dat je als consument te maken hebt met heel veel lock-in, een stapel hubs die met elkaar samenwerken en dan daar overeen in Nederland Google als partij die alles aan elkaar vastknoopt. Alexa, Homekit etc zijn in Nederland niet bestaand en daar hoef je dus ook niet naar te kijken.
Als privacy designer ben je nu boos dat apparatuur die Zigbee spreekt nu beter gaat samenwerken met andere apparaten van andere fabrikanten. Je argument is dat Google en Co een aanval op de privacy doen. Een aanval die er al lang geweest is en door de Zigbee puinhoop er voor zorgde dat in Nederland alles al bij Google terecht kwam.
Je ziet dus niet dat door een protocol als Matter alternatieve aanbieders van hubs etc ook toegang kunnen krijgen tot de gegevens van deze devices. Je ziet niet dat de gebruikers niet meer voor elke fabrikant een eigen hub hoeven kopen, die voor ieder apparaat naar een cloud data stuurt en waar je in Nederland bijna verplicht bent om Google te gebruiken om ze aan elkaar vast te knopen. Dat data lokaal kan blijven en niet naar de cloud hoeft.
Matter heeft in ieder geval de potentie om verschillende apparaten van verschillende fabrikanten in een zelfde netwerk met elkaar te laten samenwerken. De mensen van Home Assistant willen er graag gebruik van maken. Dat zou in principe betekenen dat de data niet meer naar de cloud hoeft en dat deze lokaal aan elkaar gekoppeld kan worden. Daarmee is Matter juist een protocol dat privacy beter zou kunnen beschermen.
> Die hub stuurt alles naar een cloud van een bedenkelijke configuratie en komt altijd met Google, Alexa en Apple connecties.
Er zijn ongetwijfeld Zigbee hubs die data doorsturen naar die partijen, maar ze doen dat zeker niet allemaal. IKEA's hub heeft dat niet. Als je op de link naar Candle geklikt had, dan had je daar een smart home controller gevonden die dat niet doet. Alle data blijft volledig lokaal, en een verbinding met het internet is niet nodig om Candle te gebruiken. (Sterker nog, ik heb bijgedragen aan de Zigbee2MQTT software zodat zelfs update requests vanuit Zigbee apparaten zelf kunnen worden geblokkeerd, en bijvoorbeeld slechts 1x per week worden doorgelaten. IKEA Zigbee apparaten vragen elk kwartier aan de controller of die wil checken of er een update is).
Zigbee heeft op dit moment een aantal voordelen:
- VEILIG. Ik prefereer Zigbee lampen en stekkerdozen omdat ik niet wil dat een kwaadwillende er bij kan via het internet.
- COMPARTMENTALISERING. Ik prefereer Zigbee omdat ik "compartmentalisering" als security feature zie. Zelfs als een IP apparaat is gehackt (een slimme deurbel oid), dan kan een aanvaller niet via dat apparaat mijn Zigbee apparaten bereiken. Straks wel. Straks kan je Google home direct met al je andere apparaten kletsen. Ook achter je rug om, en buiten je centrale controller om. Dan hoeft maar één apparaat gehackt te zijn (of gewoon brutaal ontworpen - "we verzamelen meta-data over hoe u uw huis gebruikt om ons product te kunnen verbeteren"), en de data uit je smart home netwerk ligt bij een databroker.
- PRIVACY. Ik prefereer Zigbee apparaten omdat ik geen "phone home" situatie wil, waarbij een cloud bijhoudt wanneer ik mijn lampen aan en uit doe ( = wanneer ik naar bed ga -> of ik wel regelmatig slaap -> of ik verhoogde kans op Alzheimer heb).
> Dat zou in principe betekenen dat de data niet meer naar de cloud hoeft en dat deze lokaal aan elkaar gekoppeld kan worden.
Klopt. Maar "in principe" kan dat nu al bij WiFi apparaten. Toch zie je in de praktijk dat bijna alles zo wordt ontworpen dat bediening via de cloud gaat. Ik zie deze ontwikkeling dan ook vooral als "meer aan de cloud koppelen", en niet als "meer lokaal doen". Dit initiatief komt o.a. van Google, en Google heeft baat bij toegang tot gebruiksdata.
Het is niet dat interoperabiliteit geen voordeel biedt, of dat alles wat Google doet meteen "evil" is ofzo. Het probleem is dat ik niemand hoor over de potentiële nadelen en risicos.
Zigbee was enorm privacyvriendelijk "by design", het zat in het protocol ingebakken. Dat wordt nu weggehaald, en privacybescherming gaat nu van de individuele implementatie afhangen. Vanuit mijn perspectief is Matter dan ook een achteruitgang.
[Reactie gewijzigd door unfold op 24 juli 2024 00:56]
Zigbee is geen standaard, zoals wifi een standaard is. In een Wifi netwerk hoef je je niet af te vragen of een apparaat van een andere fabrikant dat wifi ondersteund wel kan werken. De meeste Zigbee implementaties komen met hun eigen Hub (hey Hue) en weigeren met andere Zigbee apparaten te werken.
Dit is niet helemaal juist, Zigbee is wel degelijk gestandaardiseerd, en apparaten die zich aan het protocol houden, werken wel degelijk goed samen (b.v. ikea remote met hue lamp).
Wat niet gestandaardiseerd is, is de vertaling IP<-->Zigbee, m.a.w. de bridge tussen het Zigbee netwerk en de rest van de wereld. Hier zie je dus manufacturer specific oplossingen ontstaan, die niet met elkaar samen werken (een hue lamp kan geen software upgrade krijgen via een ikea hub en vice versa).
Matter heeft in ieder geval de potentie om verschillende apparaten van verschillende fabrikanten in een zelfde netwerk met elkaar te laten samenwerken. De mensen van Home Assistant willen er graag gebruik van maken. Dat zou in principe betekenen dat de data niet meer naar de cloud hoeft en dat deze lokaal aan elkaar gekoppeld kan worden. Daarmee is Matter juist een protocol dat privacy beter zou kunnen beschermen.
Wat matter vooral doet is een applicatie laag over IP heen leggen, waardoor bridges tussen b.v. thread en ethernet alleen low level bridging hoeven te doen, en geen (proprietary) vertaalslag op applicatielevel zoals de meeste huidige Zigbee hubs/bridges doen.
Een enorm voordeel dat hieruit volgt is dat je IoT netwerk heel erg schaalbaar wordt, omdat je verschillende IP implementaties gemakkelijk kunt combineren. Een (wellicht wel te mitigeren) nadeel is dat op deze manier ook willekeurige devices gemakkelijk direct verbinding kunnen maken met een cloud. M.a.w. controle houden over welk apparaat toegang heeft naar buiten wordt een stuk lastiger.
Zolang fabrikanten van devices het mogelijk maken (/houden) dat je een device kunt gebruiken zonder toegang tot de (hun) cloud, is het mijns inziens een goed systeem. Zodra fabrikanten allemaal gaan eisen dat hun devices vrij toegang krijgen tot hun specifieke cloud, wordt het een security nachtmerrie.
Daar ging het artikel snel overheen maar ik wil er ook wel wat meer over weten. Als je een IP stack toevoegt aan IoT, is dat dan enkel voor het versturen (met eventuele sessieafhandeling) van data om daarna weer in een sleep modus te vallen? Dan heeft zo'n apparaat dus geen enkele reden om incoming verkeer te accepteren? Of gebeurt dat in de praktijk niet zo?
Op het ogenblik ben je afhankelijk van de implementatie van je zigbee bridge. Theoretisch zou je je eigen zigbee netwerk op kunnen zetten, maar in de praktijk heeft zo goed als iedereen de Hue of Ikea bridge. Je moet redelijk technisch zijn om een andere bridge te kunnen gebruiken.
Met Matter wordt dat anders. Je hebt ineens keuze in welke bridge je wilt. Alles wat IP praat zou out of the box moeten werken. We krijgen ineens keus in welke fabrikant we vertrouwen met al onze apparaten.
Natuurlijk zijn er bedrijven die manieren blijven bedenken om controle te houden over de producten in je huis zoals Hue die Matter gaat implementeren op de bridge en niet op de lampen.
Recent was er een EuroDIG bijeenkomst, waar ik gevraagd werd in 5 minuten een reactie te geven op een presentatie van de Internet Society over IoT
Dit waren mijn punten
Why is IoT standardisation hard?
1. It's not about standardisation, but implementation and adoption ;-)
2. IoT doesn't allow separation of layers. Hardware determines protocol and use
3. IoT has multiple owners: Your car or Elon's car? Your home or your children's home?
4. IoT has multiple manufacturers: Hue or Tradfri Does it Matter?
5. IoT needs to speak multiple languages: Only Google speaks Dutch
6. IoT needs to work across networks: There is no low power IoT roaming in Europe
7. IoT needs competition: Not even a car company has enough buying power
8. IoT needs reliability: Lora, NB-IoT, LTE-M offer no failover
9. IoT needs to be public and private: Private LTE popular in NL, but hard to go public
10.IoT needs less BS → We will get self-driving cars, but they won't get certified if they need 1ms latency for braking.
Meestal als je een NB-IOT of een LTE-M oplossing gebruik van een mobiele aanbieder zeg Koninklijke DeutscheFoon, dan heb je een SIM/oplossing er in zitten die alleen werkt voor die aanbieder. Bij uitval kan er niet gebruik gemaakt kan worden van het NB-IOT of LTE-M netwerk van een andere aanbieder in hetzelfde land bv VodaMobileNederland.
Daar komt nog bij dat de meeste netwerken geen roaming aanbieden op NB-IoT en LTE-M. Dus je kunt ook niet de standaard LTE M2M truc gebruiken door een roaming SIM te gebruiken van Telenor Connexion, Orange Luxemburg, Vodafone Malta etc.
De enige optie die je soms wel kunt toepassen is terugvallen op standaard LTE, maar dat is niet heel handig voor low-power situaties en heeft veel minder dekking in moeilijke omstandigheden.
Maar goed welke fail-over modussen ken jij bij LTE-M en NB-IoT?
Het compleet uitvallen van een compleet LTE netwerk is zeer zeldzaam. Als een basisstation uitvalt zal de LTE module automatisch overschakelen naar een naburige cel (mits er dekking is natuurlijk). Inmiddels zijn er meerdere virtuele SIM aanbieders die non-steered roaming aanbieden op zowel LTE-M als NB-IoT. Bijvoorbeeld ibasis: https://ibasis.com/soluti...ctivity/network-coverage/ welke ik professioneel veel gebruik. Een sim voor EU en US en in ieder land zijn meerdere netwerken beschikbaar, ideaal voor IoT.
Netwerk uitval zal zeldzaam zijn maar dat er bij de data outbreak punten wel eens wat misgaat is mij wel bekend met storingen van een paar uur tot gevolg.
[Reactie gewijzigd door FlyEragon op 24 juli 2024 00:56]
Leuk verhaal.
Apart dat over een veel gebruikte decentrale netwerktechniek die informatie overdraagt vaak en positief geschreven wordt.
Echter dat ik dat toch mis over die andere veel gebruikte decentrale netwerktechniek die waarde overdraagt.......
Ik bedoel, alle informatie is steeds meer digitaal en via IP technieken toegankelijk/beschikbaar.
Alles wat we kopen/bezitten/gebruiken is in geld uit te drukken en dus ook steeds meer toegankelijk/beschikbaar in Bitcoin. En in laatste rubriek komt bij Tweakers 95-100% slechts het misbruik van randfiguren in beeld.....
Het lijkt net of jullie geen geld/middelen/resources over deze nieuwe technieken alloceren.
[Reactie gewijzigd door gepebril op 24 juli 2024 00:56]
NB-IoT werkt wel degelijk in dezelfde frequentiebanden die oa voor LTE gebruikt worden. Voor Europa zijn dit de banden B3 (1800), B8 (900) en B20 (800) waardoor de bestaande apparatuur hergebruikt kan worden. Een ander groot voordeel van NB-IoT is dat dit signaal dieper de gebouwen kan binnendringen dan LTE-M. Dat is een van de redenen waarom Fluvius, de Vlaamse netwerkbeheerder voor Elektriciteit en gas, dit gebruikt ten voordele van LTE-M. Er is misschien verwarring met LoRaWAN die aangeboden wordt door sommige operatoren en speciale apparatuur vereist?
/i/2004494254.png?f=imagenormal)
/i/2004494256.png?f=imagenormal)
/i/2004494258.png?f=imagenormal)
Thread voegt nu 6LoWPAN en IP-routing (in de netwerklaag) en UDP (in de transportlaag) samen en voegt daar een manier aan toe om op een veilige en gebruiksvriendelijke manier apparaten aan het netwerk toe te voegen (secure commissioning).:strip_exif()/i/2004494260.jpeg?f=imagenormal)
:strip_exif()/i/2004353914.png?f=thumblarge)
Zoals de vorige naam van Matter al aangeeft, staat IP centraal in deze iot-standaard. Matter werkt nu al boven Thread, wifi en ethernet. Andere technologieën voor connectiviteit via IP, zoals het mobiele netwerk, worden in de toekomst toegevoegd. De applicatielaag van Matter is overigens sterk geïnspireerd door die van Zigbee, ZCL./i/2004494262.png?f=imagenormal)
/i/2004494264.png?f=imagenormal)
:strip_icc():strip_exif()/i/2004584384.jpeg?f=fpa_thumb)
/i/2004215924.png?f=fpa_thumb)
:strip_exif()/i/2005651692.jpeg?f=fpa)
/i/2004091124.png?f=fpa)
:strip_icc():strip_exif()/u/172905/crop59a5561d63c7d.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/144558/hammertime.jpg?f=community){kind=small}
/u/484268/crop61e4788571a3c_cropped.png?f=community){kind=small}
/u/581347/crop64beea7e7f624_cropped.png?f=community){kind=small}
/u/41514/crop5c3b77c8badbf_cropped.png?f=community){kind=small}
