Torna all’indice generale

Reti ethernet da ufficio

Le reti di ufficio sono realizzate con tecnologie ethernet a topologia fisica a stella o a stella gerarchica (albero). Lo switch ha la funzione di:

Più switch collegati insieme realizzano una rete LAN che si estende fino al primo router che essi incontrano. I router sono i dispositivi che, di fatto, delimitano una LAN Ethernet.

Lo switch è generalmente regolato dal protocollo STP che, secondo lo standard, limita i collegamenti a cascata a poche unità (profondità nominale di 3 dispositivi secondo standard EIA/TIA).

Il cablaggio può risultare oneroso in presenza di un elevato numero di dispositivi poichè richiederebbe l’impiego di un cavo a parte per ogni sensore. Per questo motivo dispositivi di commutazione e architettura tradizionali sono generalmente ritenuti poco adatti per la realizzazione delle ampie reti di sensori diffuse in ambito industriale.

Cablaggio rete LAN di ufficio

core-access-dist-banner_1

Reti ethernet industriali

Le reti industriali o ferrotramviarie sono anch’esse a tecnologia ethernet ma, oltre la tradizionale topologia a stella, per connettere tra loro i dispositivi terminali e per collegare tra loto più switch spesso utilizzano topologia fisica a BUS o ad anello. Un anello è composto da lunghe cascate di switch collegati in serie ed equipaggiati con protocollo STP modificato o con altri protocolli proprietari. Il cablaggio, in presenza di un cluster numeroso di dispositivi risulta più economico dato che con un unico cavo si possono collegare più switch. Possibilità di topologie ridondate a doppio anello (treni, industria)

industrialnet

Reti di sensori e attuatori

Spesso sono reti miste cioè composte da sottoreti eterogenee:

alt text

Tra le due tipologie di reti ci sono dei nodi di confine aventi una interfaccia nella rete di sensori ed un’altra nella rete principale IP. Questi nodi cerniera sono detti gateway e devono trovare un modo di rendere compatibili i messaggi che circolano nelle due tipologie di reti, spesso realizzate con tecnologie completamente diverse.

Rete di distribuzione

La rete principale, è di tipo ethernet con dorsali fisiche a stella cablate e collegamenti periferici cablati o wireless WiFi. Ha principalmente la funzione di distribuzione dei dati dai nodi gateway con le reti secondarie fino al server di gestione dei dati. Va attentamente progettata perchè sia in grado di smaltire il traffico complessivo di tutti i sensori. Può diventare critica se, oltre ai sensori, sono presenti sorgenti multimediali quali microfoni o telecamere di videosorveglianza.

Cablaggio rete LAN di ufficio

Rete di accesso ai sensori

Le reti di sensori sono molto eterogenee. Tutte hanno un loro modo di accedere al mezzo trasmissivo stabilito dai rispettivi protocolli di livello fisico. Allo stesso modo, tutte hanno un loro modo di fornire un servizio all’utente in maniera più o meno astratta, più o meno espressiva, più o meno varia dal punto di vista della QoS cioè della qualità del servizio, stabilito dal protocollo di livello applicativo.

Il gap, cioè il dislivello funzionale, tra il livello fisico e quello applicativo in genere è colmato da tutta una serie di protocolli il cui scopo è essenzialmente: risolvere determinati problemi di rete (indirizzamento, controllo di errore, routing, cifratura, ecc.), ottenere la QoS richiesta dall’applicazione (velocità, BER, tipo di interazione, ecc…). Entrambi gli obiettivi precedenti devono essere raggiunti organizzando, tra livello fisico e livello applicativo, una pila (stack) di protocolli che permette di raggiungerli rispettando i vincoli posti dall’ambito di utilizzo pratico della rete (consumi, dimensioni, distanze, facilità d’uso, ecc…).

Dettaglio ES/IS

Dettaglio protocolli

Dettaglio ISO/OSI

Reti di sensori non IP

Lo stack di protocolli OSI è un modello architetturale di riferimento. Per ogni strato sono stati studiati nel tempo un gran numero di protocolli, ciascuno con i propri pregi e difetti. Un’architettura reale, quella che poi verrà standardizzata ed implementata in un dispositivo commerciale, per ogni strato della propria pila, sceglierà, tra i tanti disponibili in letteratura tecnica, un certo tipo di protocollo del quale realizzerà e standardizzerà la propria particolare versione. Attualmente, per accedere ad Internet e all’interno della maggior parte delle reti locali LAN, si adopera la cosiddetta suite TCP/IP. Ma molte reti di sensori, per funzionare localmente al loro ambiente di lavoro, non sempre usano la suite TCP/IP. Inoltre, anche le reti di sensori che eventualmente lo adoperano, ai livelli inferiori come i livelli data link e il livello fisico, spesso utilizzano protocolli diversi da quelli che sono stati standardizzati per le LAN.

Livello applicativo standard

In ogni caso, un qualsiasi ente di telecomunicazioni internazionale (IEE, IETF, ITUT, ecc.) o alleanza di case produttrici di dispositivi di rete (Zigbee, Bluetooth) o anche singole aziende (LoraWan e Sigfox), per realizzare reti di dispositivi utilizzabili direttamente dall’utente, devono progettare una propria versione dello stack ISO/OSI che includa anche i livelli superiori. Talvolta ci si ferma al tradizionale livello 6 di presentazione (LoraWan e Sigfox), altre volte si arriva persino a dettagliare il livello di applicazione (zigbee, BLE) attraverso la definizione sia del significato che del formato delle misure e dei comandi che queste reti trasportano (semantica).

Interoperabilità tra reti di sensori

Riguardo all’interoperabilità tra reti diverse, questa è evidentemente impossibile a livello fisico e di accesso, cioè ai primi due livelli della pila OSI (L1 e L2) dato che si tratta di tecnologie molto diverse tra loro. Ma potrebbe essere realizzata a livello di routing, come già accade nelle LAN e in Internet col protocollo IP e, in questo caso, potrebbero essere smistati gli stessi messaggi lungo reti eterogenee a livello fisico. Oppure, potrebbe essere realizzata solo a livello applicativo definendo per tutte le reti una semantica uniforme per misure e comandi (lo stesso oggetto tapparella con gli stessi comandi per tutte le reti, lo stesso oggetto lampada che si comanda con on e off ovunque, ecc…).

Alla luce di quanto detto, l’interoperabilità tra reti diverse si può ottenere:

alt text

Formato dei messaggi

Misure e comandi sono attualmente definiti sotto forma di oggetti JSON in formato ASCII. Questo dovrebbe garantire da un lato l’interoperabilità tra reti di sensori diverse, dall’altro l’interoperabilità con sistemi terzi che si occupano della pubblicazione dei dati o della loro eleborazione statistica. Il fatto che il formato scelto sia chiaro, testuale ed autoesplicativo è sicuramente un vantaggio nella rete di distribuzione, diventa poco pratico, o del tutto inutilizzabile, in reti di accesso ai sensori che possono trasmettere soltanto messaggi radi e molto brevi, quali quelle che operano in banda ISM. Gli oggetti JSON scambiati nella rete di distribuzione vanno progettati in modo tale da includere la semantica di tutti i dispositivi IoT coinvolti nelle reti di sensori collegate, che di volta in volta, poi andrà tradotta:

Gateway applicativo

E’ il dispositivo posto a cavallo tra la rete di accesso ai sensori e la rete di distribuzione.

Il gateway ha tante schede di interfaccia quanti sono i tipi diversi di BUS a cui si collega. Inoltre il gateway deve possedere almeno una interfaccia capace di traffico ethernet (cablata o wifi) che lo colleghi alla rete di distribuzione.

Gateway come router L7

Avendo più interfacce su reti di tipo diverso sia in L1 che in L2, ha anche le funzioni di router. Se la rete di distribuzione è pubblica come Internet dovrebbe possedere pure le funzioni di firewall. Al limite potrebbe anche smistare messaggi in una WAN privata realizzata con VPN di tipo trusted (MPLS) o secure (OpenVPN, IPSec).

Il gateway ha anche la funzione di adattare il formato dei servizi offerti dalle varie sottoreti di sensori nel formato di servizio unificato (ad esempio un particolare messaggio JSON) con cui i sensori sono interrogati nella rete di distribuzione IP. I protocolli di livello applicativo utilizzati a questo scopo in genere sono HTTPS o COAP per il paradigma di interazione Request/response oppure MQTT o Telegram per il paradigma di interazione Publish/Subscribe, oppure Websocket, Webhooks e WebRTC per richieste asincrone, l’ultimo anche per quelle multimediali.

Gateway chiusi

Talvolta il livello applicativo dello stesso stack di protocolli, pur a parità di tecnologia, non è compatibile tra dispositivi di diversi fabbricanti (marca diversa). In più i gateway verso la rete di sensori IP, nonostante abbiano nella rete di distribuzione una interfaccia MAC/IP tradizionale, sono scatolotti proprietari chiusi che nascondono la traduzione delle API di servizio HTTP o COAP con i messaggi verso la rete di sensori che gestiscono.

I fabbricanti spesso tendono a renderli non bypassabili perchè non rilasciano di pubblico dominio le API a basso livello per comunicare direttamente con i sensori. Questo significa che potrebbe essere necessario per loro un ulteriore livello di traduzione, cioè un altro gateway, per convertire il formato delle API e dei protocolli che espongono nella rete IP (ad es COAP) con quelle in uso nella rete di distribuzione comune per tutti i sensori (ad es. MQTT).

Gateway aperti

Questa situazione, per i protocolli più diffusi come Zibgee e Bluetooth, tende a scomparire perchè quasi tutti i produttori si sono ormai accordati e adottano per le API dei servizi uno standard comune e pubblico, per cui non è insolito riuscire a comandare dispositivi di una marca X col gateway della marca Y. Inoltre, molti stack hanno reso pubblico il formato del payload applicativo dei loro sensori, oppure esistono bridge che eseguono la conversione di questo in corrispondenti messaggi MQTT in formato JSON.

Sintesi delle funzioni

Riassumendo, alla rete di distribuzione IP si collegano, quindi, una o più reti secondarie che servono da rete di accesso per i dispositivi sensori o attuatori con interfacce spesso di tipo non ethernet che necessitano di un gateway di confine con possibili funzioni di:

Server applicativo

In genere è localizzato all’interno della rete principale con una collocazione on-premise all’interno del sistema.

Tendenze sempre più diffuse portano al trasferimento crescente di funzioni anche sul cloud. Una soluzione estrema è quella di spostare tutte le funzioni sul cloud tenendo ben presente che un guasto della connessione ad internet causerebbe una cessazione delle funzioni di regolazione e controllo che sono state progettate per essere eseguite centralizzate sul server. Le funzioni gestite in maniera autonoma e peer to peer completamente a bordo dei dispositivi non dovrebbero risentire di particolari problemi.

alt text

In ogni caso è necessario un server di gestione con funzioni di:

Queste prese in considerazione sono generalmente tutte funzioni di livello applicativo in quanto si limitano a gestire servizi.

Server di rete

Il network server è comune in alcune tipologie di reti wireless LPWA ed è una componente di back-end responsabile dello smistamento verso gli utenti (routing applicativo) dei dati provenienti dai vari gateway configurandosi, quindi, come il centro stella logico di una stella di gateway. Lo schema logico di una rete di sensori LPWA basata su network server quindi appare:

alt text

Funzioni essenziali

Il network server è anche responsabile dello svolgimento di alcuni processi di controllo e gestione della rete:

Hub di gateway

Il server di rete è collegato ai gateway dei sensori mediante una normale rete IP mediante protocollo di livello applicativo. E’ un nodo di smistamento finale e, in questo senso, può essere considerati come dei router di livello applicativo. In pratica è il centro stella di una stella di gateway (o base station) che a loro volta sono il centro stella di una stella di sensori. I gateway sono tutti dello stesso tipo e si collegano, tramite lo stesso protocollo, al network server realizzando, con questo, un collegamento virtuale diretto.

I dati ricevuti possono essere inviati agli application server per le elaborazioni successive oppure è possibile inviare eventuali notifiche agli end device per far attuare un’azione. Non ci sono interfacce standard di trasmissione dei dati tra network server ed application server (webservice, websocket, webhook, MQTT sono variamente implementati).

Quindi sono macchine che partecipano attivamente alle funzioni di rete e pertanto fanno esse stesse parte della infrastruttura di rete. Spesso sono virtualizzate e le loro funzioni sono offerte come servizio su abbonamento. Sono presenti in quasi tutte le infrastrutture LPWA a lungo raggio come LoraWan, Sigfox e NB-IoT.

Dispositivi terminali (sensori/attuatori)

Nelle reti industriali sono molto comuni topologie complesse a molti livelli. Per le applicazioni di nostro interesse le topologie più adoperate sono:

Chiaramente, se la rete di sensori coincide con la rete di distribuzione IP (LAN o WiFi o Internet), allora il dispositivo con la MCU potrebbe anche concettualmente essere inteso come un gateway tra la rete di sensori a BUS di campo e la rete di distribuzione. Vedi Cablaggio rete LAN di ufficio per dettagli.

alt text Dalla seconda figura, si vede chiaramente come, anche i dispositivi All In One, già equipaggiati con i sensori, adoperano internamente gli stessi collegamenti a BUS che adopererebbero i dispositivi senza sensore che, semplicemente, espongono il connettore del BUS all’esterno (vedi i connettori verdi delle prime due figure o il connettore ACME sensor dell’ultima figura).

Nella figura sotto, si vedono tre esempi di prodotti commerciali per sensore All In One (a sinistra), HUB di sensori (al centro), BUS di sensori (a destra):

alt text

Il numero dei dispositivi collegabili dipende dal più critico di molti fattori che potrebbero essere: il numero di porte/indirizzi disponibili, la lunghezza dei collegamenti ammissibile, la lunghezza dei messaggi trasmessi, il duty cycle disponibile in trasmissione, la banda disponibile in trasmissione.

Consumo dei nodi terminali

Un’altra funzione potenzialmente energivora, dopo il routing, è il polling dei sensori ovvero la loro lettura periodica con annessa trasmissione in remoto dei dati. In questo caso se il primo nodo di smistamento della catena è parecchio distante (è il caso di tecnologie outdoor come LoraWan o Sigfox) o sebbene indoor si adopera una trasmissione in una tecnologia energivora (come è in modalità standard il WiFi) allora sono possibili almeno due soluzioni operative per abbattere i consumi:

Quasi tutte le tecnologie wireless poi permettono di mettere, nell’intervallo di tempo tra una misura e l’altra, il dispositivo in modalità di sleep o standby profondo che rallenta di molto il clock della CPU permettendo un grande risparmio di energia.

Il consumo di energia è generalmente proporzionale alla velocità di trasmissione e alla lunghezza dei messaggi. Tecnologie general purpose che sono ottimizzate per la trasmissione di file o stream più che di brevi messaggi in genere sono più complesse e esibiscono consumi più elevati.

Topologia delle reti di sensori wireless

Le reti di sensori wireless hanno una estensione nello spazio variabile e la loro topologia preferita è a stella o a maglia.

hops

La rete principale ethernet può estendersi nello spazio secondo un’architettura (ad albero o ad anello) che può comprendere molti switch. Lo smistamento completo di una trama dati lungo la rete può prevedere una catena di smistamenti successivi lungo gli switch (hops) più o meno lunga. Nel caso di una rete ethernet questo non è generalmente un problema eccessivo nè dal punto di vista dei ritardi né rispetto a quello dei consumi (gli switch sono alimentati attraverso la rete elettrica).

La situazione potrebbe essere molto diversa nel caso delle reti di sensori. Queste sono spesso wireless e realizzate con dispositivi alimentati a batteria che si vorrebbe fosse sostituita idealmente non prima di un paio di anni.

A seconda dello schema adoperato, dal punto di vista energetico non è indifferente considerare se un comando o l’accesso in lettura ad un sensore avvengono connettendosi direttamente all’unico dispositivo hub centrale (magari distante) o se avvengono connettendosi al più vicino di una cascata di nodi:

Le reti di sensori wireless (WSN) ad hop multiplo in realtà sono di due tipi di base più una loro ibridazione:

cluster-flat

Classificazione delle tecnologie WSN in base a velocità e copertura

Il grafico sotto mostra il posizionamento delle varie tecnologie wireless che lavorano in banda ISM in base alla bitrate e alla distanza e potrebbe essere usato come tassonomia di riferimento (classificazione) delle varie teconologie proprio in base a queste proprieta. Al netto di qualche sovrapposizione, sono abbastanza distinguibili tre zone:

alt text

Interfaccia radio

Il mezzo trasmissivo radio è partizionabile in frequenza, tempo, spazio e potenza. Delle grandezze precedenti quella in assoluto più limitata è la frequenza essendo proprietà dello Stato e ceduta in concessione sotto ben precise condizioni (licenze). Questo è il motivo per cui, nel realizzare qualsiasi tipo di comunicazione radio, per prima cosa, bisogna cominciare col riservare una porzione del campo delle frequenze radio (spettro) allocando degli intervalli di frequenze detti canali.

I canali sono allocabili all’interno di intervalli di frequenze dette bande. Le bande si dividono in licenziate cioè quelle per le quali bisogna acquistare dallo stato la concessione per trasmetterci e in quelle non licenziate per le quali, sotto ben precise condizioni tecniche (modulazione, potenza, duty cicle, ecc.), o vincoli burocratici (possesso di autorizzazioni o patenti presso autorità regolatorie) la trasmissione è libera. Una di queste ultime è la banda ISM (Industrial Scientific Medical). L’ampiezza del canale dipende dalla tecnologia adoperata. Nelle bande ISM è inoltre possibile trasmettere senza particolari restrizioni burocratiche (acquisto di licenze o patentini), in particolare, senza avvisare nessuna autorità ma semplicemente utilizzando dispositivi certificati cioè che rispondono ai regolamenti tecnici in vigore nella nazione in cui sono adoperati. La libertà di accesso alla banda ISM è il motivo per cui essa è mediamente affollata e le sue trasmissioni soggette ad interferenze più o meno intense. Le interferenze sono gestite utilizzando modulazioni robuste alle interferenze e adoperando segnali a bassa densità spettrale, basso duty cicle e, soprattutto, potenza limitata.

Le bande ISM interessanti in Italia per l’IoT sono quelle centrate a 433MHz (Lora e Sigfox), 868MHz (Lower EU band a 867-869 MHz per Lora e Sigfox), 915MHz (Upper EU band a 867-869 MHz per Lora e Sigfox), 2,4GHz (WiFi, Zigbee), 5GHz (WiFi), 6GHz (WiFi6, NB-IoT, 5G).

alt text alt text

Recentemente alla banda ISM si è aggiunta un’altra banda non licenziata, la NR-U centrata all’incirca intorno ai 6GHz che è stata assegnata al WIFI 6 (IEE 802.11ax) e alle RAN (Radio Access Network) della telefonia cellulare che possono essere o gestite dall’operatore di telefonia o di proprietà dell’utente che così realizza una rete 5G privata. La potenza di un AP in banda NR-U non può eccedere i 30dBm per cui una BS 5G crea un’interferenza analoga a quella di un AP wifi. A parità di area, densità di distribuzione degli AP 5G dovrebbe essere circa la metà del WIFi ma con costi per dispositivo molto maggiori.

Dettaglio mezzo radio

Dettaglio banda ISM

Servizi di accesso radio per WSN

Abbiamo visto che l’interfaccia radio si accede allocando per primo un unico canale radio di una multiplazione FDM. L’allocazione può essere sia statica (eseguita dal sistemista) che dinamica cioè variabile nel tempo ed automatica.

Successivamente il canale FDM potrebbe essere ulteriormente partizionato in gruppi di utenti tutti collegati ad uno stesso dispositivo. I dispositivi (ad es. gli AP wifi di uno stesso palazzo) interferiscono tra loro ma le comunicazioni sono rese distinguibili e private mediante multiplazione a spettro espanso CDM (Code Division Multiplexing) che associa un SSID diverso ad ogni dispositivo. Ciò è dovuto al fatto che usiamo uno dei canali della banda ISM su cui non esistono coordinamento e controllo alcuno. Anche se questa tecnica è adesso usata solo in dispositivi LPWA mentre WiFi 6 e telefonia mobile 5G preferiscono ad essa la tecnica OFDM.

Dettaglio multiplazioni statiche

Dettaglio TDM statico

Dettaglio TDM statistico su mezzi punto-punto

Dettaglio TDM statistico su mezzi broadcast (BUS e radio)

Dettaglio tecnologie di accesso al mezzo radio

Classificazione dei servizi radio

Qualunque sia la modalità di accesso, alla fine, su questo canale risultante, privato ed eventualmente associato ad un certo SSID, a seconda del servizio richiesto, possono parlare:

In entrambi i casi sono possibili due tipi di servizio di accesso radio:

Ulteriori differenziazioni del servizio distinguono tra:

La conferma dei messaggi è prevista per sia per messaggi in uplink che in downlink+funzioni di comando o configurazione, ad esempio pulsanti, rilevatori di transito, allarmi in cui l’invio del messaggiò avviene una tantum in maniera del tutto asincrona (cioè non prevedibile dal ricevitore) potrebbe essere auspicabile, invece, un feedback del protocollo mediante un meccanismo di conferma basato sui messaggi di ack.

La conferma potrebbe pure essere gestita soltanto dal livello applicativo (non dal protocollo Zigbee). Sovente, nella rete di distribuzione IP è presente un server col ruolo di broker MQTT a cui sono associati:

Molti sistemi (wifi, zigbee, bluetooth BLE, LoRaWan, Sigfox) permettono di impostare contemporaneamente, sulla stessa interfaccia radio, un servizio sincrono mediante TDMA per le sorgenti che eseguono il polling di sensori e un servizio asincrono con ALOHA o CSMA/CA per le sorgenti che devono inoltrare il comando di un pulsante di accensione di un attuatore. Ciò è ottenuto attivando sul canale la funzionalità beacon con le cosiddette superframe.

Un beacon contiene informazioni che identificano la rete e i suoi servizi nonché una sequenza di bit di sincronizzazione. Vengono trasmessi periodicamente, servono ad annunciare la presenza di una LAN wireless e a sincronizzare i membri sui suoi servizi (sincroni e asincroni).

alt text

In una supertrama due beacon fungono da limiti (iniziale e finale) e forniscono la sincronizzazione con altri dispositivi e informazioni di configurazione. Un superframe è costituito da un certo numero di slot temporali divisi in due gruppi. Il primo è riservato per le sorgenti asincrone che accedono in modalità a contesa con i protocolli di arbitraggio ALOHA o CSMA, il secondo è dedicato alle sorgenti sincrone che, in quella porzione della trama, hanno uno slot esclusivamente dedicato a loro per tutto il tempo in cui esse risultano attive.

Dettaglio classi di servizio LoraWAN

Stack wireless specifici per IOT

alt text

Ci si potrebbe chiedere se è proprio necessario sapere i dettagli sui protocolli adoperati da questo o quel dispositivo. La risposta è legata al livello di astrazione con cui la nostra applicazione vede la risorsa rete.

Con alcuni protocolli l’applicazione ha della rete e dei suoi protocolli una visione che si può ridurre all’elenco di servizi di livello applicativo che lo stack espone, per cui, quando l’applicazione utilizza un servizio, sullo stack viene scelto, strato per strato, il protocollo più adatto per realizzarlo. Addirittura in Blutooth BLE e in Zigbee i servizi applicativi, cioè la definizione dei casi d’uso come accendere una lampadina o aprire una tapparella, sono dettagliatamente catalogati e definiti nello stack in strutture dati dette profili.

Normalmente solo la parte fisica dello stack è implementata in HW mentre tutto il resto dello stack è realizzato in SW. Molte volte, per progettare una rete industriale di sensori, si mantiene solo il chip con il suo livello fisico, mentre per i livelli superiori si preferisce utilizzare uno stack di protocollo alternativo, diverso da quello originale, realizzando, in pratica, una vera e propria ibridazione. In questo caso si possono ancora utilizzare stack standardizzati da organizzazioni transnazionali come IETF o IEEE ma questi possono essere molto articolati per cui, all’interno dello stack, un sistemista sceglie la classe di protocolli che ritiene più adatta alle proprie esigenze. Una proprietà, spesso non garantita dalle grandi suite come Zigbee o LoraWan, potrebbe essere l’utilizzo del livello di rete IPV6, proprietà che potrebbe permettere la connessione diretta del dispositivo in Internet trasmettendo, senza modifiche, i suoi messaggi su reti LAN o WiFi. Un’altra motivazione potrebbe essere l’interesse a non adoperare la parte, di per se complessa, dello stack che gestisce la rete di molti dispositivi ma soltanto realizzare una connessione punto punto, cioè un ponte radio numerico tra due dispositivi e per far ciò un semplice supporto di rete IPV6 (senza funzioni di routing) potrebbe essere sufficiente.

La parte logica dei due stack sotto (LoraWan a sinistra e Zigbee a destra) potrebbe essere sostituita con IPV6 inserendo il protocollo 6LowPAN. La parte fisica di entrambi verrebbe mantenuta perché realizzata in HW. Nel caso di LoraWan l’implementazione HW è proprietaria è costruita da una sola azienda (Semtech) e non è standardizzata industrialmente. Nel caso dello Zigbee la parte fisica è standardizzata con le sigla 802.15.4.

alt text

Molti framework per IoT come TinyOS, Contiki e RIOT posseggono una struttura modulare che permette loro di includere, senza particolare sforzo, stack personalizzati di protocolli in maniera tale da adattarli alle esigenze più particolari svincolandosi dagli stack protocollari completi certificati dall’industria (Zigbee, LoraWan).

Dettagli su stack wireless specifici

Dettagli su reti cellullari private

Canali di comunicazione principali in una rete di sensori

Riassumendo, sono necessari almeno due canali di comunicazione che, insieme, complessivamente, realizzano la comunicazione tra sensori e gestore delle informazioni:

Sitografia:

Torna all’indice generale