Torna a reti di sensori

Caso d’uso rete wiFi Mesh

Una rete Wi-Fi mesh è un sistema di rete wireless progettato per fornire una copertura Wi-Fi estesa che consiste di più AP che però non sono connessi all’infrastruttura di una LAN cablata tranne uno detto gateway. Una rete Wi-Fi mesh è una soluzione avanzata per estendere la copertura Wi-Fi e migliorare l’affidabilità della connessione in ambienti complessi nei quali risulta essere problematica la realizzazione di dorsali cablate verso gli AP. Con la capacità di auto-configurarsi, gestire il roaming continuo e fornire una copertura scalabile, le reti mesh rappresentano una scelta preferibile per chi necessita di una connettività robusta e senza interruzioni su aree estese.

Per il resto, ha le stesse caratteristiche di una rete WiFi di tipo infrastruttura, tranne che per la presenza di un gateway con mera funzione di inoltro dei pacchetti tra la rete mesh wireless e l’infrastruttura cablata.

Componenti di una Rete Wi-Fi Mesh sono:

A parità di architettura, le reti WiFi mesh si differenziano per il tipo di inoltro dei dati tra i vari nodi: Bridge mesh e Mesh ad hoc routed.

alt text

Aspetti critici

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

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.

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.

Rete di reti wifi

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 installato in cloud, in una Virtual Private network, oppure On Premise direttamente nel centro di gestione e controllo.

Il gateway All-In-One potrebbe essere un dispositivo con doppia interfaccia, modem UMTS per l’accesso alla rete di distribuzione su Internet, WiFi verso la rete di sensori. Può essere utile per realizzare un gateway WiFi da campo da adoperare:

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, nelle reti WiFi, 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 in modo infrastruttura

Una architettura di rete wireless WiFi è può essere realizzata in tre modalità:

Le architetture più diffuse in ambito aziendale ed outdoor sono di tipo Modalità wifi mesh e sono composte di una rete magliata di dispositivi (router o bridge wifi) collegati attraverso un nodo gateway ad un rete cablata o wireless che fornisce l’accesso ad Internet.

Gli elementi di una rete in modo infrastruttura sono:

Sistemi multicanale (multiradio)

alt text

Architettura del sistema di rete Wireless Mesh multicanale. Il numero minimo di canali necessario è 2. Un sistema a 3 canali offre maggiore flessibilità a prezzo di un maggiore costo.

Ogni collegamento tra due nodi rappresenta una comunicazione radio diretta e dedicata sul canale numerato con l’etichetta sul link. In questa esempio, ogni nodo è dotato di 2 NIC wireless. Pertanto il numero di canali utilizzati da ciascun nodo contemporaneamente non può essere superiore a 2; la rete nel suo complesso utilizza 5 canali distinti.

I router e i nodi mesh Wi-Fi 6 (802.11ax) spesso supportano più bande radio, tipicamente a 2.4 GHz, 5 GHz, e in alcuni casi 6 GHz (Wi-Fi 6E). Queste bande possono essere utilizzate in modo diverso per ottimizzare la rete:

  1. Banda 2.4 GHz: Ha una portata più lunga ma velocità inferiore, utile per dispositivi lontani o per attraversare ostacoli come muri.
  2. Banda 5 GHz Band: Ha una portata più corta ma velocità più alta, ideale per connessioni ad alta velocità a distanze moderate.
  3. Banda 6 GHz (Wi-Fi 6E): Offre molte più canali e minore congestione, con velocità elevate e latenza ridotta, ma con una portata limitata.

Il backhaul Wi-Fi è il collegamento wireless tra i nodi che partecipano ad una dorsale principale ad alto traffico di una rete mesh e il gateway.

Tipi di Backhaul

Il backhaul Wi-Fi è il collegamento wireless tra i nodi che partecipano ad una dorsale principale ad alto traffico di una rete mesh e il gateway. Il gateway è l’unico dispositivo della rete mesh che è cablato su una rete LAN, generalmente per ottenere l’accesso a Internet. In una rete mesh, i nodi (che possono essere router o access point) comunicano tra loro per estendere la copertura Wi-Fi, e il backhaul è essenziale per mantenere questa comunicazione fluida e efficiente. Le Tipologie di Backhaul sono:

alt text

Applicazione del CFP in Reti Mesh

In una rete mesh, il controllo del tempo di trasmissione attraverso CFP o tecniche simili può essere implementato per migliorare l’efficienza del backhaul e delle comunicazioni client. Ecco come potrebbe funzionare:

Funzionalità Chiave di una implementazione multiradio

Quando si vuole selezionare un AP Wi-Fi per una rete mesh ad alte prestazioni, potrebbe esse utile tenere in considerazione le seguenti funzionalità:

Bridge mesh network

Nelle reti Wifi Bridge mesh, si sfrutta la proprietà (comune a tutti i dispositivi WiFi) di possedere un bridge interno, realizato in SW, che collega i link wireless appartenenti ad interfacce radio diverse (per esempio, una a 2.4 GHz ed una a 5 GHz). Quindi, un nodo WiFi è, a tutti gli effetti, un dispositivo IS di livello 2 della pila ISO/OSI.

I bridge, in una rete dati, posseggono funzioni analoghe a quelle di uno switch HW (inoltro trame) e tecnologie analoghe a quelle degli switch HW (VLAN). La disponibilità delle VLAN permette di portare a soluzione una esigenza tipica anche nelle reti wired da ufficio: la separazione logica degli utenti in gruppi isolati in base al tipo di servizio piuttosto che in base alla vicinanza fisica nello spazio dei loro utenti. Le VLAN permettono agevolmente la gestione di gruppi di utenti sparsi a macchia di leopardo su tutta l’infrastruttura, wired o wireless che sia.

alt text

Vantaggi

In definitiva, i bridge inoltrano direttamente trame MAC, e la rete complessiva è una LAN gestita dal protocollo STP che evita i loop a livello data link (L2) pur mantenenedo la ridondanza al livello fisico (L1). I vantaggi di questa configurazione sono gli stessi di quella di una rete wireless infrastruttura composta da SW:

Esempio

Si vogliono separare i servizi di produzione agricola con i suoi sensori sparsi su tutto l’agro, dai servizi di mobilità ai tecnici agronomi dotati di tablet sui loro mezzi con i quali eseguono il controllo giornaliero degli impianti di competenza, consentendo anche di dedicare una gestione separata al traffico dei servizi di videosorveglianza.

alt text

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

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 bridge wireless. La loro separazione avviene dopo, su un router di confine collegato con un backaul capace di creare il trunking dei flussi sul router (inter vlan 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.

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 192.168.0.0/16 e dividerlo come segue:

Subnetting

Subnet per la dorsale dei router mesh (VLAN amministrativa):

Subnet per i sensori collegati a R2.

Subnet per i sensori collegati a R3.

Routing statico

R1 possiede 3 indirizzi su ciascuna subnet:

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

Svantaggi

Però, nonostante la sua semplicità, questa non è la configurazione preferita. Infatti, pesano negativamente:

Routed ad hoc mesh network

Nelle reti Wifi Routed mesh, si sfrutta la proprietà (comune a tutti i dispositivi WiFi) di possedere un router interno, realizato in SW, che collega i link wireless appartenenti ad interfacce radio diverse (per esempio, una a 2.4 GHz ed una a 5 GHz). Quindi, un nodo WiFi è, a tutti gli effetti, un dispositivo IS di livello 3 della pila ISO/OSI.

alt text

Il routing è basato su indirizzi IP che, essendo gerarchici , permettono di partizionare la rete in subnet con gruppi di dispositivi dislocati in aree delimitate e presidiate da router, cioè da dispositivi in grado filtrare gli accessi con regole basate sull’indirizzo di sorgente. Questo è un vantaggio di sicurezza perchè delle ACL sui router potrebbero abilitare l’accesso a certe aree fisiche (corrispondenti a certe subnet di destinazione) semplicemente controllando la subnet di appartenenza della sorgente.

Esempio

Se si volessero separare un’area di produzione agricola con accesso riservato solamente ai sensori/attuatori, da un’area dedicata all’accesso degli impiegati amministrativi e da un altra ancora dedicata all’accesso degli ospiti esterni per le conferenze, allora la separazione dei gruppi di utenti in base alla dislocazione fisica potrebbe essere una soluzione efficace.

Definizione dei gruppi mediante router

La definizione dei gruppi si può fare con una dislocazione fisicamente contigua degli host, cioè gli host di un certo gruppo sono vincolati ad effettuare l’accesso solo presso un certo router. La separazione avviene subito, sul router wireless di accesso, grazie all’assegnazione di indirizzi appartenenti a subnet diverse.

La separazione degli utenti nella soluzione routed può essere realizzata solamente se i gruppi di host da dividere sono racchiusi in subnet IP che fanno capo ad un certo gruppo di router di aggregazione (al limite uno solo) che coprono un’area delimitata della rete. A queste subnet si accede con ssid dedicati a ciascun gruppo e protetti da password per autenticare gli utenti del gruppo. Gli host della subnet hanno però il vincolo di dover essere spazialmente prossimi ai router di aggregazione loro assegnati per potere accedere alla rete mesh.

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 192.168.0.0/16 e dividerlo come segue:

Subnetting

Subnet per la dorsale dei router mesh:

Subnet per i sensori collegati a R2.

Subnet per i sensori collegati a R3.

Routing statico

Su R1 configurare:

Su R2 configurare:

Su R3 configurare:

Vantaggi

Una caratteristica delle reti ad hoc è di non essere statiche ma completamente autoconfiguranti nel senso che:

Queste soluzioni per la gestione degli indirizzi non rendono necessario impostare esplicitamente un subnetting statico per ogni dorsale, anche se è possibile, in qualche misura, introdurlo.

Inoltre, nelle reti mesh WiFi ad hoc, il routing è generalmente automatico, utilizzando protocolli di routing dinamico, che consentono ai nodi di scoprire e mantenere le rotte in modo dinamico, cioè adattandosi nel tempo ai cambiamenti nella topologia della rete, in modo da garantire resilienza (in caso di guasti o interferenze) e scalabilità (in caso dell’aggiunta di nuovi nodi). Sono in genere di due tipi differenti:

Bridge group

All’interno di ogni AP, in realtà, sono sempre presenti uno o più bridge realizzati in SW (creati mediante il comando bridge-group x) che hanno il compito di associare il traffico delle interfacce wireless con le interfacce Ethernet della reta cablata.

Le interfacce wireless fisiche sono divise in più sotto interfacce logiche, ciascuna con il proprio SSID (veri e propri Hub wireless separati da un ssid).

Anche le interfacce ethernet fisiche sono divise in più sotto interfacce logiche, ciascuna con il proprio vlan id.

alt text

Partendo dall’alto verso il basso, possiamo vedere che:

Esempio di configurazione di due radio (a 2.4 GHz e 5 GHz) per gestire due SSID ciascuna associati a due VLAN diverse:

Configurazione globale

dot11 ssid Corporate
   vlan 10
!
dot11 ssid Guest
   vlan 20
!
bridge irb

Un BVI (Bridge Virtual Interface) in un Access Point WiFi è un’interfaccia logica del bridge utilizzata per ottenere un unico punto di gestione per l’indirizzamento IP e altre configurazioni di rete. Con 2 bridge accade che il bridge group 1 avrà il suo BVI1, mentre il bridge group 2 avrà il suo BVI2.

Due funzioni rilevanti vengono eseguite nello snippet sopra. Innanzitutto, i nostri due SSID (Corporate e Guest) vengono definiti e associati alle VLAN. In secondo luogo, il routing e il bridging integrati (IRB) vengono abilitati con il comando bridge irb. Ciò consente di definire gruppi di bridge e un BVI.

Configurazione radio 0

interface Dot11Radio0
 no ip address
 !
 ssid Corporate
 !
 ssid Guest
 !
 mbssid
!
interface Dot11Radio0.10
 encapsulation dot1Q 10
 bridge-group 1
!
interface Dot11Radio0.20
 encapsulation dot1Q 20
 bridge-group 2

Configurazione radio 1

 interface Dot11Radio1
 no ip address
 !
 ssid Corporate
 !
 ssid Guest
 !
 mbssid
!
interface Dot11Radio1.10
 encapsulation dot1Q 10
 bridge-group 1
!
interface Dot11Radio1.20
 encapsulation dot1Q 20
 bridge-group 2

Configurazione IP

 interface BVI1
 ip address 192.168.10.123 255.255.255.0
 no ip route-cache

Questa configurazione mantiene il traffico wireless appartenente a un SSID isolato dal traffico appartenente all’altro mentre transita l’access point dall’interfaccia cablata all’interfaccia wireless e viceversa. Nota che poiché non c’è un’interfaccia BVI2, l’access point non ha alcun indirizzo IP raggiungibile direttamente dall’SSID Guest.

Tra un nodo e l’altro, soprattutto per grandi distanze (superiori al KM) potrebbe essere utile valutare il cosidetto link budget, overossia la somma dei guadagni e delle attenuazioni lungo il percorso fino al ricevitore. L’obiettivo è valutare il rispetto del vincolo finale sul ricevitore, cioè che la potenza ricevuta sia maggiore della sensibilità minima del ricevitore più un certo margine di sicurezza per tenere conto del fading ambientale (multipath oppure attenuazione atmosferica) che è una quantità che varia, più o meno rapidamente, col tempo. Per dettagli sul calcolo vedere https://www.vincenzov.net/tutorial/elettronica-di-base/Trasmissioni/link.htm. Oppure si possono usare dei calcolatori online di link budget LOS radio quali https://www.daycounter.com/Calculators/Friis-Calculator.phtml, oppure https://www.pasternack.com/t-calculator-friis.aspx. Rimane assodato che si tratta soltanto di un calcolo di massima che fornisce indicazioni sulla fattibilità teorica di un collegamento che, se positiva, richiede attente e ripetute verifiche sul campo nelle condizioni di esercizio previste per l’impianto.

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:

Banda ISM

Le bande libere sono le frequenze di uso libero, non tutelate, che non richiedono concessioni per il loro impiego. Sono spesso indicate come ISM (Industrial, Scientific and Medical)[Nota 1].

In realtà ISM è un sottogruppo di tutte le frequenze disponibili. La situazione è analoga a quella delle spiaggie. In tutto il territorio nazionale molti litorali sono stati dati in concessione a privati che possono consentirne l’accesso a chi vogliono purchè paghi. Solo alcune sono libere, cioè aperte a tutti senza pagare ma, in questo caso, è necessario tutelare il bene pubblico condiviso affinchè nessuno ne monopolizzi l’uso appropriandosene la maggiorparte per la maggiorparte del tempo.

L’uso di tali bande è regolamentato in modo da consentirne l’impiego condiviso ed evitare che un utente o un servizio possa monopolizzare la risorsa.

In tabella un elenco parziale con le principali limitazioni che riguardano principalmente potenza, duty cycle, EIRP, ERP e il tipo di accesso (ALOHA, LBT o AFA). Vedi Banda ISM 800 MHz per dettagli.

alt text

Per le reti Wi-Fi che operano nella banda 2.4 GHz, i limiti di EIRP possono variare a seconda del canale utilizzato e sono generalmente compresi tra 20 dBm (100 mW) e 24 dBm (250 mW). Per la banda 5 GHz, i limiti possono essere più elevati e variano in base al canale e alla larghezza di banda utilizzati. Vedi Gestione equa della banda WiFi per le definizioni e i dettagli.

Ogni access point utilizza un singolo canale (largo 22 MHz), che viene condiviso in TDMA-TDD (CSMA/CA) da tutti gli utenti.

La trasmissione avviene a pacchetti con conferma di ricezione.

Conclusioni

Le reti mesh Wi-Fi 6 sfruttano la capacità multi-radio per ottimizzare le prestazioni e la copertura, utilizzando bande diverse per i link tra nodi e per le connessioni dei dispositivi. Questa tecnologia permette di ridurre la congestione e migliorare l’efficienza della rete, offrendo una connessione più stabile e veloce per tutti i dispositivi collegati.

Esempi di Sistemi Wi-Fi Mesh sono:

Pagine correlate:

Sitografia:

Torna a reti di sensori