Thread: rete IPv6 mesh, Border Router e ruolo negli edifici connessi

Torna a Riferimenti tecnici

Riferimento tecnico

Revisione tecnica

Mirko Martino

Scope revisione

Architettura IPv6 e 6LoWPAN, ruoli Thread e relativa terminologia, Leader e partizioni, Thread Border Router, commissioning e credenziali, TCAT, Thread over Infrastructure, relazione con Matter, confronto con Wi-Fi, Zigbee, KNX IoT, BACnet e DALI+, resilienza, diagnostica, lifecycle e baseline Thread 1.4.1.

Ultima revisione

10 ottobre 2026

Livello tecnico · Intermedio

1. Thread in breve

Thread è una tecnologia di rete mesh a basso consumo basata su IPv6. È progettata per collegare dispositivi connessi che devono scambiare quantità contenute di dati, operare con consumi ridotti e comunicare attraverso una rete capace di usare più percorsi radio.

Thread definisce il livello di rete. Non definisce da solo il significato applicativo di una luce, di un sensore, di una serratura o di un regolatore. Questa distinzione è essenziale: Matter può usare Thread come rete operativa, ma Matter e Thread non sono la stessa tecnologia.

Thread non è neppure una piattaforma cloud, un Controller Matter o un sistema completo di automazione dell’edificio. Il suo compito principale è fornire connettività IP tra i nodi della rete e verso altre reti IP attraverso uno o più Thread Border Router.

La baseline tecnica verificata per questa pagina è Thread 1.4.1. La presenza di una versione corrente della specifica non implica che ogni prodotto installato la implementi integralmente: versione, certificazione, firmware e funzioni effettive devono essere controllati sul singolo dispositivo.

2. Dove si colloca nello stack

Per capire Thread è utile separare almeno tre livelli.

Il livello applicativo definisce il significato delle funzioni e dei messaggi. Matter, KNX IoT o altre applicazioni possono operare a questo livello.

Il livello di rete permette ai dati di raggiungere altri nodi. Thread usa IPv6 e adatta i pacchetti alla rete radio IEEE 802.15.4 mediante tecniche 6LoWPAN, comprese compressione degli header e frammentazione quando necessaria.

Il livello radio e di accesso al mezzo è fornito da IEEE 802.15.4, nella baseline attuale principalmente nella banda a 2,4 GHz.

Questa struttura consente a Thread di trasportare traffico IP senza imporre un unico modello applicativo. Il fatto che due dispositivi siano connessi alla stessa rete Thread non significa tuttavia che comprendano gli stessi comandi o che possano interagire senza un’applicazione comune.

Thread supporta protocolli di trasporto IP come UDP. Applicazioni e versioni superiori dello stack possono usare altri trasporti quando previsti, ma il trasporto non va confuso con il mezzo radio o con il modello applicativo.

3. IPv6 e rete mesh

Ogni dispositivo Thread partecipa a una rete IPv6. I nodi possono comunicare localmente e, attraverso un Border Router, raggiungere reti IP adiacenti.

La rete è mesh perché i dispositivi con capacità di inoltro possono formare più percorsi. Quando cambia la qualità dei collegamenti, la topologia può adattarsi e il traffico può seguire una rotta diversa.

Questa capacità non rende automaticamente affidabile l’intero servizio. Un percorso radio alternativo non compensa necessariamente:

• la perdita dell’alimentazione comune;
• il guasto del Border Router;
• l’indisponibilità della LAN;
• il blocco del Controller o dell’applicazione;
• la perdita di un account o di un servizio cloud necessario all’implementazione.

La mesh offre quindi una base per la resilienza di rete, non una garanzia di continuità dell’automazione.

Thread usa indirizzamento e routing IPv6, ma i dispositivi a basso consumo non devono necessariamente mantenere una connessione radio continuamente attiva. Alcuni nodi possono dormire per lunghi periodi e affidarsi a un nodo padre per la ricezione differita dei messaggi.

4. Ruoli nella rete Thread

La documentazione corrente usa soprattutto i termini Mesh Extender ed End Device. Per mantenere leggibili anche specifiche e documentazione precedenti, in questa pagina vengono indicati anche i termini classici Router e Router Eligible End Device (REED).

Leader

Ogni partizione Thread ha un Leader. Il Leader mantiene e distribuisce le informazioni di configurazione della partizione e gestisce l’insieme dei Mesh Extender, comprese le assegnazioni dei Router ID.

Non è un Controller applicativo e il traffico non deve passare tutto attraverso di esso. Il ruolo viene eletto dinamicamente: se il Leader non è più disponibile, un altro Mesh Extender (Router) può assumere il ruolo.

Mesh Extender (Router)

Un Mesh Extender (Router) inoltra pacchetti per altri nodi e contribuisce alla struttura della mesh. Nella terminologia classica questa funzione corrisponde al ruolo di Router.

Non tutti i dispositivi dovrebbero diventare Mesh Extender (Router). Thread limita e gestisce il numero dei Mesh Extender (Router) per mantenere una topologia efficiente.

Extender-Capable Device — ECD (in precedenza Router Eligible End Device — REED)

Un Extender-Capable Device (ECD; in precedenza Router Eligible End Device, REED) opera normalmente come End Device ma possiede le capacità per diventare Mesh Extender (Router) quando la rete ne ha bisogno.

La capacità non implica che il dispositivo stia effettivamente inoltrando traffico in ogni momento.

End Device

Un End Device comunica attraverso un nodo padre e non inoltra normalmente traffico per altri dispositivi.

Sleepy End Device

Uno Sleepy End Device può spegnere la radio per ridurre il consumo. Il nodo padre conserva temporaneamente i messaggi destinati al dispositivo finché questo non si riattiva.

La latenza e il comportamento temporale dipendono quindi anche dagli intervalli di polling e dall’implementazione applicativa.

Partizioni

Quando gruppi di nodi non riescono più a comunicare tra loro, una rete Thread può dividersi in partizioni, ciascuna con il proprio Leader e la propria topologia. Se la connettività torna disponibile, le partizioni possono essere ricongiunte secondo le regole della rete.

La gestione delle partizioni è importante nella valutazione della resilienza: una radio mesh può continuare a funzionare localmente pur avendo perso una parte della connettività o dei servizi esterni.

5. Thread Border Router

Il Thread Border Router collega la rete Thread a una rete IP adiacente, normalmente Ethernet o Wi-Fi.

La sua funzione principale è instradare traffico IPv6 fra i due domini. Non è, per definizione, un gateway che traduce il modello applicativo: quando l’applicazione usa protocolli IP compatibili, i pacchetti possono essere instradati senza una conversione semantica equivalente a quella richiesta fra protocolli applicativi differenti.

Un Border Router può inoltre supportare:

• propagazione o registrazione della scoperta dei servizi;
• connettività verso reti esterne;
• funzioni di commissioning dall’infrastruttura adiacente;
• collegamenti fra parti della rete Thread attraverso l’infrastruttura;
• eventuali funzioni come NAT64 e DNS64 per l’accesso a servizi IPv4.

Queste capacità devono essere verificate nell’implementazione effettiva. Il ruolo Border Router non dimostra che ogni funzione sia presente, configurata o autorizzata.

Una rete Thread può avere più Border Router. Con Thread 1.4, meccanismi di condivisione delle credenziali facilitano l’aggiunta di Border Router appartenenti a ecosistemi diversi alla stessa rete Thread, quando prodotti e piattaforme implementano correttamente la funzione.

Più Border Router possono fornire percorsi alternativi verso l’infrastruttura IP e ridurre alcuni single points of failure. La ridondanza apparente deve però essere valutata rispetto ai failure domain reali: due Border Router alimentati dallo stesso circuito, collegati allo stesso switch o dipendenti dallo stesso Controller non costituiscono necessariamente due percorsi di servizio indipendenti.

Un singolo prodotto può integrare Border Router, Matter Controller, Matter Commissioner, punto di accesso Wi-Fi o servizi cloud. Questa concentrazione di ruoli può semplificare l’installazione, ma non deve nascondere le dipendenze.

6. Thread e commissioning

Per entrare in una rete Thread, un nuovo dispositivo deve ricevere i parametri e le credenziali necessari.

Nel modello Thread classico:

• il Joiner è il dispositivo che chiede di entrare;
• il Commissioner autorizza il dispositivo;
• il Joiner Router inoltra il traffico di commissioning quando necessario;
• il Border Agent espone il servizio di commissioning all’infrastruttura esterna.

Il commissioning Thread riguarda l’accesso alla rete Thread. Non coincide con il commissioning dell’applicazione che userà quella rete.

Un dispositivo Matter su Thread, per esempio, può ricevere durante un flusso coordinato sia la configurazione di rete Thread sia le credenziali operative Matter. I due risultati restano distinti:

• la rete Thread stabilisce la connettività IP;
• la Fabric Matter stabilisce identità, sicurezza e interazione applicativa Matter.

Le credenziali della rete sono un bene operativo. Occorre definire chi può:

• aggiungere un dispositivo;
• aggiungere un Border Router;
• esportare o condividere le credenziali;
• resettare la rete;
• sostituire un componente;
• conservare le informazioni necessarie al ripristino.

Thread 1.4 ha ampliato gli strumenti di commissioning, includendo Thread Commissioning over Authenticated TLS (TCAT), una capacità opzionale basata su autenticazione a certificati. Nella baseline 1.4 la sessione TCAT opera tramite Bluetooth Low Energy.

La disponibilità di TCAT non deve essere presunta per ogni prodotto. Supporto, certificati, strumenti e procedure operative vanno verificati.

7. Thread e Matter

Matter e Thread svolgono funzioni differenti.

Matter definisce un modello applicativo e di interazione: Device Type, endpoint, cluster, attributi, comandi, eventi, sicurezza applicativa e appartenenza a una Fabric.

Thread fornisce una rete IPv6 attraverso cui un dispositivo Matter può comunicare.

Un dispositivo Matter può usare Thread, Wi-Fi o Ethernet secondo la propria categoria e implementazione. Thread non è quindi un requisito universale per Matter.

Una rete Thread non coincide con una Fabric Matter. Le credenziali Thread permettono l’accesso alla rete; le credenziali Matter permettono l’appartenenza e l’interazione nella Fabric.

Più Fabric Matter possono usare la stessa infrastruttura Thread, se i nodi, i controller e la gestione delle credenziali coinvolti lo consentono. Viceversa, un ecosistema può creare una rete Thread separata se non riesce a condividere o riutilizzare quella esistente. La presenza di più reti radio sovrapposte può aumentare complessità, interferenza e dipendenze operative.

Il Thread Border Router non è automaticamente:

• un Matter Controller;
• un Matter Commissioner;
• un amministratore della Fabric;
• un servizio di automazione.

Un prodotto può combinare questi ruoli, ma la documentazione di progetto deve mantenerli distinti.

8. Thread rispetto a Wi-Fi

Thread e Wi-Fi sono entrambe tecnologie capaci di trasportare IPv6, ma hanno caratteristiche differenti.

Wi-Fi è normalmente progettato per capacità di trasmissione più elevate e usa un’infrastruttura basata su access point. Thread privilegia traffico contenuto, dispositivi a basso consumo e una topologia mesh IEEE 802.15.4.

La scelta non è necessariamente alternativa. In uno stesso progetto:

• Thread può collegare sensori, attuatori e dispositivi a basso consumo;
• Ethernet o Wi-Fi possono collegare Controller, server, interfacce e Border Router;
• le reti possono cooperare a livello IP.

Entrambe possono usare la banda a 2,4 GHz. La coesistenza non elimina la necessità di pianificare canali, interferenze, posizionamento e densità dei dispositivi.

Il fatto che Thread usi IPv6 non significa che possa essere gestito come una normale rete Wi-Fi. Strumenti diagnostici, ruoli, credenziali e condizioni radio restano differenti.

9. Thread rispetto a Zigbee

Thread e Zigbee usano comunemente IEEE 802.15.4 e possono utilizzare hardware radio simile. La somiglianza termina però prima del livello applicativo.

Thread costruisce una rete IPv6 ed è indipendente dal modello applicativo.

Zigbee definisce uno stack proprio, comprendente rete, sicurezza e un modello applicativo con profili, cluster e dispositivi.

Un dispositivo Zigbee non diventa Thread mediante la sola condivisione della radio. Occorrono firmware, stack e certificazione appropriati; in molti casi occorre sostituire il dispositivo o usare un bridge.

Thread non costituisce quindi una migrazione automatica da Zigbee. Un prodotto multiprotocollo può supportare entrambi, contemporaneamente o alternativamente, ma devono essere verificate le condizioni reali dell’implementazione.

10. Thread rispetto a KNX, BACnet e DALI

Thread non sostituisce i modelli applicativi dei sistemi di automazione professionale.

KNX

KNX definisce un sistema di automazione con modello applicativo, datapoint, configurazione e responsabilità di engineering. KNX IoT può usare reti IPv6, compreso Thread in specifiche architetture, ma questa possibilità non rende Thread equivalente all’intero sistema KNX.

Thread può fornire connettività. KNX continua a definire significato, comportamento e configurazione delle funzioni KNX.

BACnet

Thread può fornire una rete IP a implementazioni applicative compatibili; BACnet definisce oggetti, servizi e messaggi per il controllo e la supervisione degli edifici.

L’eventuale integrazione deve dichiarare come dati, comandi e responsabilità vengono rappresentati fra i domini.

DALI

DALI definisce comunicazione, dispositivi e funzioni per l’illuminazione. DALI+ estende l’uso del protocollo su mezzi IP, fra cui implementazioni basate su Thread.

Anche in questo caso Thread fornisce il livello di rete; DALI conserva il modello applicativo e le procedure proprie del sistema di illuminazione. La specifica DALI+ supporta Thread come carrier IP; disponibilità e stato di certificazione dei prodotti devono essere verificati per la soluzione considerata.

11. Cosa Thread non significa

Thread non significa Matter

Matter può usare Thread, ma Matter definisce funzioni applicative e Thread fornisce rete IPv6.

Thread non significa Zigbee

Le due tecnologie possono condividere IEEE 802.15.4, ma usano stack di rete e modelli applicativi differenti.

Thread non significa Wi-Fi

Entrambe trasportano IP, ma usano tecnologie radio, topologie e modelli energetici differenti.

Border Router non significa Matter Controller

Il Border Router instrada traffico fra Thread e reti IP adiacenti. Il Controller gestisce dispositivi e funzioni applicative.

Mesh non significa affidabilità garantita

La mesh può fornire percorsi radio alternativi. Non elimina guasti di alimentazione, infrastruttura, Controller o applicazione.

Thread non significa assenza di cloud

Il protocollo consente comunicazione IP locale. Un prodotto può comunque dipendere da account, cloud o servizi remoti.

Thread non significa interoperabilità automatica

L’interoperabilità applicativa dipende dall’applicazione comune, dalle versioni, dalle funzioni implementate e dai Controller.

Più Border Router non significano automaticamente una rete migliore

Numero, posizione, alimentazione, infrastruttura e coordinamento determinano l’effetto reale.

IPv6 non elimina il progetto di rete

Occorrono ancora pianificazione radio, segmentazione, sicurezza, diagnostica, responsabilità e lifecycle.

12. Progettazione della rete

La progettazione di una rete Thread non consiste nel verificare soltanto che un dispositivo riceva il segnale.

Occorre conoscere:

• planimetria e materiali;
• distribuzione dei dispositivi alimentati e a batteria;
• nodi capaci di inoltrare traffico;
• posizione dei Border Router;
• infrastruttura Ethernet e Wi-Fi adiacente;
• canali radio e interferenze;
• compartimentazioni e vincoli di sicurezza;
• percorsi di commissioning e manutenzione.

I dispositivi a batteria non devono essere considerati automaticamente elementi utili all’estensione della mesh. Molti operano come Sleepy End Device e non inoltrano il traffico.

La copertura deve essere verificata in condizioni realistiche, comprese porte chiuse, arredi, quadri, locali tecnici e possibili modifiche future.

La segmentazione IP richiede attenzione. Thread usa IPv6 e multicast, scoperta dei servizi e routing attraverso Border Router. VLAN, firewall e politiche IT possono influire sulla raggiungibilità e sul commissioning.

La responsabilità deve essere definita fra:

• progettista;
• integratore;
• responsabile IT;
• fornitore della piattaforma;
• manutentore;
• proprietario dell’edificio.

13. Continuità, ridondanza e lifecycle

Una rete mesh può ricalcolare i percorsi quando un nodo non è più disponibile. Questo è utile, ma rappresenta soltanto una parte della continuità operativa.

Per valutare la resilienza occorre verificare:

• numero e posizione dei Mesh Extender;
• numero e indipendenza dei Border Router;
• alimentazioni;
• switch e access point condivisi;
• disponibilità dei Controller;
• servizi locali e remoti;
• procedure di sostituzione;
• conservazione delle credenziali;
• supporto firmware.

Più Border Router sono utili solo se possono realmente fornire percorsi alternativi. Due dispositivi sullo stesso switch, sulla stessa alimentazione e sotto lo stesso account possono conservare un unico failure domain.

La perdita di un Border Router non dovrebbe essere valutata soltanto con un ping. Occorre provare:

• controllo locale;
• automazioni;
• commissioning;
• scoperta dei servizi;
• accesso remoto quando previsto;
• diagnostica;
• recupero dopo il ripristino.

Credenziali e ownership devono sopravvivere al cambio di personale o fornitore. Se nessuno sa chi controlla la rete o come aggiungere un nuovo Border Router, la continuità tecnica è già compromessa.

Il lifecycle comprende anche la compatibilità fra versioni. Un aggiornamento può migliorare sicurezza e funzioni, ma deve essere verificato rispetto a tutti i nodi, Border Router, Controller e applicazioni coinvolti.

14. Dove può essere utile negli edifici

Le valutazioni seguenti sono Building Reference professional assessments e non requisiti o dichiarazioni di idoneità della specifica Thread.

Residenziale

Thread è particolarmente coerente con dispositivi a basso consumo e funzioni distribuite in ambienti residenziali. La presenza di Matter può facilitare l’uso dello stesso dispositivo in ecosistemi differenti, ma il risultato dipende da device type, feature, Controller e versione.

Hospitality

In camere e piccoli ambienti ripetitivi, Thread può risultare utile per sensori e dispositivi con traffico contenuto. Prima di un impiego esteso occorre verificare commissioning su larga scala, segmentazione, sostituzione, diagnostica e ownership delle credenziali.

La ripetitività delle camere non elimina la necessità di documentare dipendenze da Controller, Border Router, account e piattaforme.

Piccolo commerciale

Uffici, negozi e piccoli edifici possono usare Thread per funzioni locali o per componenti integrati in una piattaforma più ampia. Il valore dipende dalla capacità di attribuire responsabilità e mantenere la rete nel tempo.

Edifici professionali e di grandi dimensioni

La disponibilità di Thread in prodotti residenziali non dimostra automaticamente idoneità per edifici estesi.

Nei progetti professionali devono essere valutati almeno:

• densità e copertura;
• numero di reti e partizioni;
• più Border Router;
• infrastruttura IP;
• segregazione;
• strumenti diagnostici;
• procedure di commissioning massivo;
• sostituzione e reset;
• gestione delle credenziali;
• supporto pluriennale;
• responsabilità di manutenzione.

Thread può costituire un livello di connettività all’interno di un’architettura più ampia. Non dovrebbe essere presentato come un sistema completo di building automation.

Le valutazioni settoriali richiedono quindi conferma nel contesto reale e non derivano automaticamente dalla specifica.

15. Checklist professionale

Prima di affidare una funzione di progetto a Thread, verificare:

• versione Thread dichiarata dal prodotto;
• certificazione applicabile;
• firmware installato;
• ruolo che il dispositivo può assumere;
• comportamento effettivo come Mesh Extender (Router), End Device o Sleepy End Device;
• disponibilità e collocazione dei Border Router;
• indipendenza dei failure domain;
• supporto alla condivisione delle credenziali;
• compatibilità fra Border Router di ecosistemi differenti;
• infrastruttura IPv6 adiacente;
• eventuale supporto NAT64 e DNS64;
• multicast e scoperta dei servizi;
• copertura e margine radio;
• interferenza e piano canali;
• commissioning;
• ownership delle credenziali;
• reset e sostituzione;
• segregazione e access control;
• dipendenze dal Controller;
• dipendenze da account o cloud;
• aggiornamenti e supporto futuro;
• strumenti diagnostici;
• procedure di backup e ripristino;
• documentazione consegnata al proprietario;
• responsabilità durante esercizio e manutenzione.

Una funzione può essere considerata verificata nel progetto solo dopo una prova nella combinazione reale di dispositivi, firmware, rete Thread, Border Router, infrastruttura IP, Controller, applicazione e configurazione.

16. Resilience by Design

Per Building Reference, Resilience by Design significa identificare i failure domain e progettare il comportamento del sistema quando una parte viene meno.

La mesh Thread può offrire percorsi radio alternativi. Più Border Router possono offrire più uscite verso l’infrastruttura IP. Queste capacità sono componenti della resilienza, non una dimostrazione della resilienza complessiva.

La continuità deve essere verificata dal dispositivo fino alla funzione:

• collegamento radio;
• mesh;
• Border Router;
• rete IP;
• Controller;
• applicazione;
• account o servizio remoto quando necessario.

La perdita di uno di questi elementi può avere effetti differenti. Il progetto deve documentare quali funzioni devono continuare, quali possono degradare e quali procedure consentono il ripristino.

17. Versioni ed evoluzione

Thread 1.4 ha introdotto o consolidato capacità rilevanti per l’impiego professionale, tra cui:

• condivisione delle credenziali di rete fra ecosistemi;
• Thread over Infrastructure;
• miglioramenti alla connettività Internet;
• diagnostica di rete;
• TCAT;
• miglioramenti per robustezza e scalabilità.

Thread over Infrastructure consente a Border Router compatibili di utilizzare una rete IPv6 infrastrutturale, come Ethernet o Wi-Fi, come percorso aggiuntivo tra porzioni della rete Thread. Non trasforma però Ethernet o Wi-Fi nella mesh IEEE 802.15.4.

La baseline pubblica verificata per questo riferimento è Thread 1.4.1.

Thread 1.5 è stato indicato dal Thread Group come sviluppo successivo, ma non ha sostituito la 1.4.1 nel registro pubblico verificato alla data della ricerca. Le eventuali capacità future non devono essere attribuite ai prodotti correnti prima della pubblicazione della specifica e della verifica dell’implementazione.

Un prodotto indicato genericamente come “Thread” può implementare una versione precedente e non supportare le capacità della baseline più recente.

Fonti primarie e baseline tecnica

Le fonti tecniche principali per questo riferimento sono:

• Thread Group, Thread 1.4.1 Specification;
• Thread Group, Thread 1.4 Features White Paper;
• Thread Group, documentazione sui Border Router e sulle reti multiple;
• OpenThread, documentazione su ruoli, routing e Border Router;
• IETF, RFC 4944, RFC 6282 e RFC 9453;
• Connectivity Standards Alliance, specifiche Matter per la relazione applicativa;
• KNX Association per KNX IoT;
• ASHRAE per BACnet;
• DALI Alliance per DALI+.

Baseline tecnica verificata: Thread 1.4.1 Verifica fonti: 10 ottobre 2026 Version-sensitive: Sì