Torna a reti di sensori

Servizi:

Date le particolarità della tecnologia, i casi d’uso per la rete di sensori Ethernet sono quelli tipici per applicazioni IoT indoor a medio raggio, dove concorre con altre tecnologie di rete: Zigbee, BLE e, sotto certe condizioni, LoRaWAN. Caratteristiche della rete Ethernet di tipo ufficio sono essenzialmente:

Aspetti critici

Elementi critici su cui bilanciare convenienze e saper fare delle scelte argomentate sono:

Per maggiori dettagli vedi Punti critici cablaggio strutturato.

Per una disamina degli errori più comuni nello sviluppo di una documentazione sul cablaggio strutturato vedi Errori comuni cablaggio

Architettura di una rete di reti

Di seguito è riportata l’architettura generale di una rete di reti di sensori. Essa è composta, a livello fisico, essenzialmente di una rete di accesso ai sensori e da una rete di distribuzione che fa da collante di ciascuna rete di sensori.

alt text

Rete di distribuzione

La rete di distribuzione, in questo caso, coincide con una rete di reti IP, in definitiva direttamente con Internet se le reti wifi sono federate e remote, cioè in luoghi sparsi in Internet.

In questo caso non è necessario avere dei gateway con funzione di traduzione dalla rete di ditribuzione IP a quella dei sensori, dato che questa è anch’essa una rete IP.

Schema logico

L’albero degli apparati attivi di una rete di sensori + rete di distribuzione + server di gestione e controllo potrebbe apparire:

alt text

Il broker MQTT può essere pubblico installato in cloud, in una Virtual Private network, oppure On Premise direttamente nel centro di gestione e controllo.

Una rete di reti di sensori sparsi nel mondo può essere tenuta insieme tramite Internet utilizzando un broker pubblico MQTT. In alternativa è possibile, nel caso di reti di sensori Ethernet, emulare una stessa LAN che le unisce mediante la tecnologia delle VPN site-to-site. I vantaggi sono:

Per il dettaglio sulle VPN pratiche vedi VPN di reti Ethernet.

Per il dettaglio sulle impostazioni di un firewall Firewall.

Per il dettaglio sulla realizzazione dei backup vedi Backup.

Canali di comunicazione principali in una rete di sensori

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

Broker MQTT

Il broker MQTT è solo una delle tante soluzioni possibili per realizzare un canale multicast di livello applicativo tramite cui un utente col ruolo di publisher è in grado di notificare una replica dello stesso messaggio a più subscribers. E’ utile per:

Il canale applicativo su cui vengono inviati i messaggi sono quindi i topic. Su un certo topic il dispositivo con il ruolo di output agisce come un publisher, mentre quello con il ruolo di input agisce come un subscriber.

Gli utenti, in ogni caso, si comportano tutti come client poiché sono loro che iniziano la connessione con il broker e non il viceversa.

alt text

Fasi del protocollo:

  1. Il Subscriber dichiara presso il broker il proprio interesse a ricevere notifiche riguardo ad un certo argomento (topic) effettuando una chiamata subscribe()
  2. il publisher pubblica un messaggio che riguarda un certo topic effettuando una chiamata publish()
  3. Il broker inoltra il messaggio a tutti i subscriber interessati a quel topic

L’ID MQTT è un identificativo che permette di individuare un dispositivo ma non è un indirizzo di livello 3, non individua la macchina host in base al suo IP, piuttosto è un indirizzo di livello applicativo noto solo ad un server centrale, cioè il broker. Un dispositivo IoT non è tenuto a conoscere l’IP di tutti gli altri dispositivi ma solamente quello del broker. Il broker soltanto sa gli indirizzi di tutti i dispositivi, conoscenza che acquisisce durante la fase di connessione di un client al broker, momento in cui avviene anche il recupero del’socket remoto del client.

Il broker, dal canto suo, associa ogni topic con tutti gli ID che sono registrati presso di esso come subscriber. Questa associazione è utilizzata per smistare tutti i messaggi che arrivano con un certo topic verso tutti gli ID che ad esso sono associati. Il topic diventa così un indirizzo di gruppo. La particolarità di questo indirizzo è che è gerarchico secondo una struttura ad albero, cioè gruppi di dispositivi possono essere suddivisi in sottogruppi più piccoli estendendo il nome del path con un ulteriore prefisso, diverso per ciascun sottogruppo. L’operazione può essere ripetuta ulteriormente in maniera ricorsiva.

Ad esempio, posso individuare le lampade della casa con il path luci e accenderle e spegnerle tutte insieme, ma posso sezionarle ulteriormente con il path luci/soggiorno con il quale accendere o spegnere solo quelle del soggiorno oppure con il path luci/soggiorno/piantane con il quale fare la stessa cosa ma solo con le piantane del soggiorno.

Osservando l’albero degli apparati attivi, si vede bene che, in una rete IP, il client MQTT (con il ruolo di publisher o di subscriber) è sempre il dispositivo IoT.

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Il vantaggio del broker MQTT è quello di poter gestire in modo semplice e standardizzato lo smistamento (inoltro) delle misure e dei comandi tra i vari portatori di interesse (stakeholder) di un cluster di reti di sensori, siano essi utenti umani, interfacce grafiche, server applicativi diversi o altri dispositivi IoT.

Alternative ad MQTT

Esistono molte altre soluzioni che magari sono più semplici e graficamente accattivanti ma che passano per portali proprietari o per servizi cloud a pagamento e nulla aggiungono di didatticamente rilevante ai nostri discorsi. Normalmente sono basate su webservices realizzati con protocolli Request/Response quali HTTPS e COAP.

Server di gestione

E’ un client del broker MQTT con funzioni sia di publisher che di subscriber per:

Rete Ethernet (LAN)

Gli elementi di base di una rete LAN sono:

Gli AP (Access Point), sono dei dispositivi di aggregazione dei client della rete LAN (PC, dispositivi IoT, smartphone, tablet, ecc.) che, attraverso gli AP, ottengono un accesso alla rete LAN aziendale. In modo infrastruttura, gli AP sono in realtà assimilabili a 2 dispositivi distinti:

Architettura cablaggio

Il cablaggio è articolato, come prevedono gli standard TIA/EIA 568B ed ISO/IEC11801, in:

alt text

Tendenzialmente, per risparmiare filo, vale la regola che gli armadi devono essere tutti in posizione baricentrica (non sempre rispettata nel disegno come nei progetti):

Documentazione

Consiste in:

  1. Planimetria senza cablaggio
  2. Planimetria con cablaggio
  3. Albero degli apparati passivi
  4. Tabella delle dorsali
  5. Albero degli apparati attivi
  6. Schema degli armadi

Lo scopo è realizzare un guida univoca (priva di ambiguità) per il personale installatore per definire:

Per il personale che si occupa della ordinaria manutenzione della rete è una guida per:

Planimetria

Planimetria senza cablaggi

Serve a dare una indicazione sulla destinazione d’uso degli ambienti, ovvero, le funzioni aziendali che li si svolgono da cui si potrebbero dedurre le esigenze degli utenti coinvolti (stakeholders). Le esigenze dell’utente diventano i requisiti del sistema HW e SW che deve essere realizzato.

alt text

I requisiti del sistema si dividono in funzionali e non funzionali:

alt text

La maggior parte dei sistemi HW e SW è composta da moduli distribuiti, cioè delocalizzati, che collaborano comunicando in rete. Per cui, i requisiti non funzionali, oltre che sul SW, impattano molto proprio sui requisiti dell’infrastruttura di rete.

Planimetria con cablaggio

Nella planimetria vanno riportate con precisione:

Vincoli del cablaggio

Nella definizione quantitativa dei componenti si deve tenere conto dei seguenti vincoli obbligatori previsti dallo standard:

Linee guida del cablaggio in planimetria

Nella progettazione è raccomandabile seguire alcune linee guida:

Disposizione degli armadi

Non sempre esiste un unico armadio BD (di secondo livello) per edificio, come non sempre esiste un unico armadio FD di terzo livello per ciascun piano:

Il CD può avere tre ruoli perché da esso si possono diramare dorsali di campus (verso altri BD), di edificio (verso altri FD) e di piano (verso prese TO). Un BD può avere due ruoli perché da esso possono diramarsi dorsali di edificio (verso altri FD) e di piano (verso prese TO).

alt text

Nell’esempio:

Topologia cavi vs topologia canalizzazioni

Albero degli apparati attivi

Albero degli apparati attivi e armadi

Gli apparati attivi non fanno tecnicamente parte della definizione delle norme del cablaggio strutturato perché quella riguarda solo i componenti passivi (non alimentati) dello stesso. In ogni caso, i dispositivi attivi sono progettati per essere interfacciati con gli elementi del cablaggio strutturato e in più i loro fattori di forma (combinazioni delle loro tre dimensioni) sono fatti per essere alloggiati nel rack di un armadio:

Normalmente (ma potrebbero esserci eccezioni) un armadio contiene uno o più SW così distribuiti:

Gli AS sono diventati i concentratori dei dispositivi client fissi per cui posseggono un numero elevato di porte (24 - 72).

I DS di base destinati a commutare dorsali e potrebbero essere realizzati:

I CS sono i concentratori dei dispositivi server (sistema e business) e delle dorsali principali di campus e potrebbero essere realizzati:

Configurazioni switch tipiche

Switch di core CS:

Switch di distribuzione DS:

Albero degli apparati attivi e subnetting

Per realizzarlo è opportuno eseguire un subnetting della rete tenendo conto:

La realizzazione di un inter VLAN routing obbliga a far corrispondere (mappare) ogni VLAN ad una dorsale verso il router (virtuale o fisica) e quindi ad una corrispondente subnet.

Un subnetting definisce sei proprietà di una subnet:

Indirizzi IP di client e server

L’albero degli apparati attivi contiene dispositivi alimentati e dotati di indirizzo IP, indicati genericamente come host, sono:

Normalmente i dispositivi client ottengono automaticamente l’indirizzo IP tramite il servizio DHCP. Al limite, gli indirizzi dei dispositivi fissi possono essere assegnati staticamente per ragioni di troubleshooting.

I dispositivi server posseggono indirizzi statici per poter essere associati più facilmente all’url di dominio presso cui i client possono connettersi per raggiungere i servizi che essi pubblicano. I loro indirizzi vanno sempre segnati sull’albero.

Divisione in gruppi di utenti o servizi

alt text

Modalità di segmentazione

La segmentazione di una rete LAN parte sempre da un router che, essendo un dispositivo L3, è in grado di bloccare le trame MAC provenienti da dispositivi di livello inferiore come gli SW e i Bridge ad L2 oppure gli Hub ad L1.

Un router reimbusta le trame MAC su nuovi pacchetti IP ogni volta che effettua un inoltro su una porta di uscita. L’operazione di inoltro è vincolata ad alcune limitazioni che possono essere utili per la sicurezza:

alt text

Segmentazione fisica

alt text

Esigenza di filtraggio: negare ad un PC della subnet officina di entrare nella subnet ufficio

Router: soluzione senza le VLAN Router: soluzione con le VLAN
```C++ !Definizione lista di regole (blacklist) (config)# access-list 101 deny 10.0.2.0 0.0.0.255 (config)# access-list 101 permit any ! Selezione interfaccia eth2 (config)# interface eth2 !Applicazione in ingress su eth2 (config-if)# ip access-group 101 in (config-if)# exit ``` ```C++ ! Definizione lista di regole (blacklist) (config)# access-list 101 deny 10.0.2.0 0.0.0.255 (config)# access-list 101 permit any ! Selezione interfaccia vlan 20 (config)# GigabitEthernet0/0.20 ! Applicazione in ingress su vlan 20 (config-if)# ip access-group 101 in (config-if)# exit ```

Segmentazione logica

alt text

Esigenza di filtraggio:

Soluzione

Router: Marketing --> Produzione
```C++ ! Definizione lista di regole (config)# access-list 102 permit tcp any any gt 1023 established ! Selezione interfaccia vlan20 (config)# GigabitEthernet0/0.20 ! Applicazione in ingress su vlan20 (config-if)# ip access-group 102 in ```

Segmentazione fisica + logica

Esigenza di filtraggio:

alt text

Router: negare il traffico reciproco tra ufficio produzione e ufficio marketing
```C++ ! Creare l'ACL per bloccare il traffico tra VLAN 30 e VLAN 10 ip access-list extended BLOCK_VLAN_10_20_30 deny ip 10.0.10.0 0.0.0.255 10.0.30.0 0.0.0.255 deny ip 10.0.20.0 0.0.0.255 10.0.30.0 0.0.0.255 deny ip 10.0.30.0 0.0.0.255 10.0.10.0 0.0.0.255 deny ip 10.0.30.0 0.0.0.255 10.0.20.0 0.0.0.255 permit ip any any ! Applicare le ACL alle interfacce VLAN interface GigabitEthernet0/0.10 ip access-group BLOCK_VLAN_10_20_30 in exit interface GigabitEthernet0/0.20 ip access-group BLOCK_VLAN_10_20_30 in exit interface GigabitEthernet0/0.30 ip access-group BLOCK_VLAN_10_20_30 in exit ```

Esempio

Nel contesto di un istituto scolastico che si vuole servire con una rete WiFi, si vogliono separare i servizi di segreteria scolastica con i suoi server e i suoi impiegati localizzati in una subnet fisicamente dislocata in una certa area, dai servizi di mobilità, dispersi a macchia di leopardo in tutto il comprensorio, ai docenti dotati di supporti di loro proprietà (politica Byod) con i quali eseguono le loro attività giornaliere sul registro scolastico. Si vuole consentire anche una gestione separata al traffico dei servizi di videosorveglianza con propri server, a disposizione all’interno di una subnet separata.

alt text

La separazione dei gruppi di utenti solamente in base alla dislocazione fisica sarebbe evidentemente impossibile, mentre sarebbe effettiva la separazione mediante VLAN dislocate su una infrastruttura switched.

Definizione dei gruppi mediante VLAN

La definizione dei gruppi si può fare con una dislocazione a macchia di leopardo delle interfacce di accesso alla diverse VLAN, aventi ssid statici diversi o uno unico ma dinamico (autenticazione 802.1X). Gli host possono collegarsi all’ssid di una certa VLAN su ogni AP. La loro separazione avviene dopo, su un router di confine collegato al core switch con un link capace di creare il trunking dei flussi (intervlan routing in modo router on a stick). Le dorsali tra i vari bridge devono essere configurate come dorsali di trunk (802.1Q) in modo tale che portino il traffico aggregato di tutte le VLAN.

Si sarebbe potuto isolare in maniera ancora più affidabile la rete della segreteria servendola con uno SW dedicato collegato direttamente ad una porta del router, realizzando così una separazione fisica piuttosto che una logica, sfruttando il fatto che la dislocazione fisica dei suoi utenti è confinata in un’area esclusiva. Però, poichè il controller degli AP deve risiedere nella stessa subnet degli AP da controllare, sarebbe poi nata l’esigenza di doverne installare due, uno per la segreteria ed uno per la scuola.

L’inconveniente viene superato adoperando le VLAN e la sicurezza viene mantenuta ugualmente alta (like wire in pratica) grazie ai comandi: allowed vlan 1, 20, 30 e allowed vlan 1, 10 che confinano il traffico delle trame MAC relative alla LAN della segreteria sul solo SW dove sono collegati i suoi dispositivi. Tutte le altre dorsali non possono essere interessate da questo traffico, mentre sono tutte interessate dal traffico della subnet amministrativa degli AP che possono così essere gestiti da un unico controller.

Esempio di Configurazione

Per configurare una rete con 3 router WiFi mesh, in cui ogni router ha una dorsale (backhaul) con canale di comunicazione dedicato e due router aggregano sensori su due subnet diverse, possiamo seguire questo schema:

I Router per aggregazione dei sensori sono R2 e R3. Per le subnet possiamo usare un blocco di indirizzi privati come 10.0.0.0/8 e dividerlo, con un subnetting FLSM classful, come segue:

Subnetting

Subnet per la dorsale degli AP (VLAN amministrativa no ssid):

Subnet per la segreteria.

Subnet per i docenti.

Subnet per la videosorveglienza.

Routing statico

R1 possiede 3 indirizzi su ciascuna subnet:

Non è necessario impostare le tabelle di routing in quanto le subnet S0, S1, S2, S3 sono, su R1, direttamente connesse.

Messaggi MQTT

Messaggi confermati

La conferma dei messaggi inviati da parte del ricevente normalmente non è necessaria nel caso dei sensori. Infatti, se un invio da parte di un sensore non andasse a buon fine, è inutile richiedere la ritrasmissione di un dato che comunque a breve arriva con una misura più aggiornata.

La conferma, invece, è prevista per funzioni di comando o configurazione. Ad esempio nel caso di pulsanti, rilevatori di transito o allarmi in cui l’invio del messaggiò avviene sporadicamente e in maniera del tutto asincrona (cioè non prevedibile dal ricevitore), potrebbe essere auspicabile avere un feedback da parte del protocollo mediante un meccanismo di conferma basato su ack. Ma non sempre ciò è possibile.

La conferma, però, potrebbe pure essere gestita soltanto dal livello applicativo (non dal protocollo) utilizzando un topic di feeedback (o stato) per inviare il valore dello stato corrente subito dopo che questo viene interessato da un comando in ingresso sul dispositivo.

Definizione di topic e payload

Sovente, nella rete di distribuzione IP è presente un server col ruolo di broker MQTT a cui sono associati:

In realtà, il topic di configurazione, pur essendo teoricamente appropriato, potrebbe anche essere incorporato nel topic di comando, magari prevedendo un livello più alto di autorizzazione rispetto ai comandi relativi alle funzioni ordinarie.

Gestione dei topic di comando

Potremmo a questo punto inserire il comando delle luci nel topic più generale delle misure ed attuazioni che chiameremo comandi e registrare i pulsanti del soggiorno al topic luci/soggiorno/comandi come pubblisher, mentre potremmo registrare le attuazioni delle lampade allo stesso topic come subscriber. Il comando potrebbe essere il JSON {"toggle":"true"}, per cui alla fine tutto intero il path diventerebbe luci/soggiorno/comandi/{"toggle":"true"}. Se volessimo selezionare un solo dispositivo sono possibili due strade alternative:

Gestione dei topic di stato

Questo canale viene utilizzato per inviare lo stato di un dispositivo a tutti coloro che ne sono interessati. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di stato potrebbe essere:

Gestione dei topic di configurazione

Questo canale viene utilizzato per inviare comandi di configurazione al dispositivo da parte del server di processo. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di configurazione per, ad esempio, impostare il periodo di pubblicazione automatica dello stato potrebbe essere:

Pagine correlate:

Sitografia:

Torna a reti di sensori