Meshtastic o MeshCore? Una rete stabile ha bisogno di ruoli, non di improvvisazione
Meshtastic e MeshCore vengono spesso presentati come due sistemi sostanzialmente equivalenti perché entrambi utilizzano dispositivi LoRa per inviare messaggi senza dipendere dalla rete cellulare o da una connessione Internet.
Questa descrizione, però è estremamente superficiale.
Condividere la stessa tecnologia radio non significa condividere la stessa architettura, lo stesso metodo di instradamento o la stessa capacità di sostenere una rete territoriale destinata a crescere.
La vera differenza tra Meshtastic e MeshCore non si trova nella grafica delle applicazioni, nel numero delle funzioni disponibili o nella distanza raggiunta durante una singola prova radio.
La differenza fondamentale è nel modo in cui viene concepita la rete:
Meshtastic lascia un’ampia libertà di configurazione al singolo utilizzatore. MeshCore assegna invece a ogni dispositivo un ruolo operativo preciso.
Quando i nodi sono pochi, entrambe le soluzioni possono sembrare valide.
Quando la rete cresce, aumenta il traffico e vengono installati nodi da persone diverse, la presenza o l’assenza di un’architettura condivisa diventa determinante.
Una prova di distanza non dimostra l’efficienza della rete
Nel mondo LoRa si tende spesso a giudicare un sistema in base alla distanza raggiunta.
Ricevere un messaggio a decine di chilometri è certamente interessante, ma non dimostra che una rete sia stabile, efficiente o correttamente organizzata.
Una rete radio deve essere valutata considerando anche:
- il numero delle ritrasmissioni generate;
- il tempo di occupazione del canale radio;
- il rischio di collisione tra i pacchetti;
- la quantità di traffico automatico prodotto dai nodi;
- la prevedibilità dei percorsi;
- la possibilità di amministrare l’infrastruttura;
- il comportamento della rete con decine o centinaia di dispositivi;
- la capacità di rimanere operativa nel tempo.
È proprio analizzando questi elementi che emergono le differenze più significative tra Meshtastic e MeshCore.
Meshtastic: una rete fortemente dipendente dalle scelte individuali
Meshtastic è un progetto ricco di funzioni e caratterizzato da un’elevata possibilità di personalizzazione.
L’utilizzatore può scegliere tra numerosi ruoli, tra cui CLIENT, CLIENT_MUTE, CLIENT_HIDDEN, CLIENT_BASE, TRACKER, SENSOR, ROUTER, ROUTER_LATE, REPEATER, TAK e altri ancora.
Può inoltre modificare il comportamento di ritrasmissione, il limite degli hop, il preset radio, gli intervalli della telemetria, la trasmissione della posizione, le informazioni del nodo, i moduli attivi e numerosi altri parametri.
La documentazione ufficiale prevede anche diverse modalità di rebroadcast, come ALL, LOCAL_ONLY, KNOWN_ONLY, NONE e CORE_PORTNUMS_ONLY.
Questa libertà può essere utile in un laboratorio o per chi desidera sperimentare continuamente.
In una rete pubblica e condivisa, però, rischia di diventare un problema. Ogni utilizzatore può decidere autonomamente:
- quale ruolo assegnare al dispositivo;
- quali pacchetti ritrasmettere;
- quanti hop consentire;
- quanto frequentemente trasmettere posizione e telemetria;
- quale preset radio utilizzare;
- se trasformare un normale dispositivo in un nodo infrastrutturale;
- quali moduli attivare;
- quali impostazioni modificare rispetto a quelle adottate dagli altri utenti.
Il risultato può essere una rete composta da apparati configurati secondo interpretazioni, necessità e convinzioni personali differenti. Meshtastic possiede quindi dei ruoli, ma la loro presenza non garantisce automaticamente un’architettura ordinata.
Senza un coordinamento rigido e costante, la libertà di configurazione rischia di trasformarsi in una forma di anarchia operativa, nella quale ogni nodo si comporta secondo le decisioni del proprio proprietario e non necessariamente secondo le necessità complessive della rete.
Il Managed Flooding di Meshtastic
Il funzionamento tradizionale di Meshtastic si basa principalmente sul cosiddetto Managed Flooding.
Quando un nodo riceve un pacchetto con un limite di hop superiore a zero, può ritrasmetterlo dopo aver ridotto tale limite. Prima di farlo, ascolta brevemente il canale per verificare se un altro nodo abbia già effettuato la ritrasmissione.
Se rileva che un altro dispositivo ha già ripetuto il pacchetto, può rinunciare alla propria trasmissione.
I nodi configurati come ROUTER o REPEATER hanno invece una priorità maggiore e possono ritrasmettere anche quando rilevano che il pacchetto è già stato inoltrato da altri dispositivi. È quindi importante precisare che Meshtastic non utilizza un flooding completamente indiscriminato. Il sistema applica meccanismi di ascolto, deduplicazione e gestione delle priorità. Rimane però il fatto che, nella configurazione ordinaria, anche un dispositivo con ruolo CLIENT può contribuire alla ritrasmissione dei pacchetti.
Il comportamento della rete dipende quindi non soltanto dai nodi infrastrutturali, ma anche da numerosi apparati personali, mobili, alimentati a batteria e configurati autonomamente.
Meshtastic ha introdotto il Next-Hop, ma il problema strutturale rimane
Dalla versione 2.6, Meshtastic utilizza anche un sistema di Next-Hop Routing per i messaggi diretti.
Dopo una prima consegna effettuata attraverso il Managed Flooding, il sistema può memorizzare il nodo successivo utilizzato per raggiungere la destinazione. Le comunicazioni dirette successive possono quindi essere inoltrate attraverso tale next hop, riducendo il numero dei nodi coinvolti. Quando il percorso non risulta più valido, il sistema torna al Managed Flooding. Si tratta certamente di un miglioramento importante.
Non elimina, però, il problema principale: Meshtastic continua a essere un ambiente nel quale ruoli, rebroadcast, telemetria, posizione, hop e numerosi altri parametri possono essere modificati individualmente.
L’efficienza generale dipende quindi dalla competenza e dalla disciplina di tutti coloro che partecipano alla rete.
Cosa accade quando una rete Meshtastic cresce
Una rete composta da pochi dispositivi può funzionare apparentemente senza particolari difficoltà.
Quando aumentano i nodi, crescono però anche:
- i pacchetti di posizione;
- i dati di telemetria;
- le informazioni automatiche sui dispositivi;
- i messaggi sui canali;
- le ritrasmissioni;
- le conferme di ricezione;
- la probabilità che più nodi tentino di utilizzare contemporaneamente il canale radio.
La stessa documentazione Meshtastic riconosce che le reti più grandi richiedono una riduzione del traffico automatico. Il firmware aumenta infatti gli intervalli di trasmissione di telemetria, posizione e altri dati accessori quando rileva più di 40 nodi attivi. La documentazione consiglia inoltre preset più veloci quando sono presenti molti dispositivi o vengono inviati messaggi frequentemente, proprio per contenere la congestione.
Questo dimostra un principio inevitabile:
Più una rete basata sulla propagazione condivisa cresce, più deve limitare ciò che i singoli nodi trasmettono e ritrasmettono.
Non significa che Meshtastic smetta improvvisamente di funzionare.
Significa che, con l’aumentare dei dispositivi, il sistema deve progressivamente ridurre il traffico e compensare gli effetti di una rete nella quale molti nodi partecipano alla propagazione.
Il rischio è quello di assistere a un degrado graduale delle prestazioni:
- messaggi più lenti;
- pacchetti non ricevuti;
- aumento delle collisioni;
- maggiore occupazione del canale;
- percorsi instabili;
- difficoltà nel comprendere quale configurazione stia causando il problema;
- comportamenti differenti tra aree geografiche e gruppi di utilizzatori.
MeshCore: prima l’architettura, poi le funzioni
MeshCore parte da un principio completamente diverso.
Il sistema separa chiaramente le funzioni della rete attraverso firmware e ruoli dedicati.
I tre componenti principali sono:
- Companion
- Repeater
- Room Server
Non si tratta soltanto di nomi assegnati attraverso un menu. Si tratta di firmware progettati per compiti differenti.
La documentazione ufficiale identifica espressamente firmware Companion, Repeater e Room Server e precisa che i nodi Companion, nella loro funzione ordinaria, non ritrasmettono i messaggi. Questa scelta riduce la possibilità che ogni utilizzatore trasformi il proprio terminale in un elemento infrastrutturale senza considerare le conseguenze sulla rete.
Il Companion: il terminale dell’utilizzatore
Il Companion è il dispositivo utilizzato per collegarsi all’applicazione MeshCore tramite Bluetooth, USB o Wi-Fi, secondo l’hardware e il firmware adottati.
Il suo compito principale è consentire all’utente di:
- inviare e ricevere messaggi;
- gestire contatti e canali;
- visualizzare i nodi ricevuti;
- consultare i percorsi;
- amministrare da remoto Repeater e Room Server, quando autorizzato;
- utilizzare le funzioni messe a disposizione dall’applicazione.
Il Companion non nasce per diventare automaticamente un ripetitore.
Questa separazione è essenziale perché evita che centinaia di dispositivi personali, accesi e spenti casualmente, spostati continuamente o installati in condizioni radio inadeguate, diventino parte incontrollata dell’infrastruttura.
In MeshCore l’utente utilizza la rete, mentre la copertura viene affidata principalmente a nodi dedicati.
Il Repeater: l’infrastruttura radio
Il Repeater ha il compito specifico di estendere la copertura della rete e inoltrare i pacchetti verso la destinazione.
Viene normalmente installato:
- in una posizione elevata;
- con un’antenna adeguata;
- con alimentazione stabile;
- con parametri radio condivisi;
- con una configurazione coerente con il territorio;
- sotto la responsabilità di un amministratore identificabile.
Il firmware Repeater dispone delle funzioni necessarie per l’instradamento e l’amministrazione remota.
Secondo la documentazione MeshCore, il Repeater non inoltra automaticamente ogni pacchetto ricevuto, ma valuta i pacchetti e i percorsi secondo il funzionamento previsto dal protocollo.
Questo rende l’infrastruttura più prevedibile.
La rete non dipende dalla casuale disponibilità dei terminali degli utenti, ma da apparati installati espressamente per garantire copertura e continuità.
Il Room Server: conservare i messaggi nel tempo
Il Room Server svolge una funzione differente.
È un server di messaggistica di tipo BBS che conserva la cronologia e permette agli utenti di recuperare successivamente le comunicazioni non ancora visualizzate. Un utente temporaneamente fuori copertura può quindi collegarsi in seguito e ricevere i messaggi memorizzati. La documentazione MeshCore paragona questo comportamento, concettualmente, a quello di un server di posta: il messaggio non deve necessariamente essere ricevuto nell’esatto momento in cui viene trasmesso. Il Room Server può tecnicamente essere abilitato anche alla ripetizione, ma la documentazione sconsiglia questa configurazione e raccomanda di mantenere Repeater e Room Server su dispositivi separati.
Questo dettaglio dimostra chiaramente la filosofia di MeshCore:
Ogni funzione deve essere affidata al componente più adatto, evitando di concentrare ruoli differenti sullo stesso dispositivo.
Flood iniziale e percorsi diretti in MeshCore
MeshCore utilizza un sistema di instradamento ibrido.
Quando il percorso verso un destinatario non è ancora conosciuto, il primo messaggio può essere inviato attraverso il flood routing.
Quando il destinatario riceve il messaggio, restituisce una conferma contenente le informazioni relative ai Repeater attraversati.
Il mittente può quindi memorizzare il percorso.
Nei messaggi successivi, il percorso viene inserito direttamente nel pacchetto e soltanto i Repeater che ne fanno parte partecipano all’inoltro.
Qualora il percorso non sia più disponibile, il sistema può tentare nuovamente il flooding per individuare una strada alternativa.
Il principio operativo può essere riassunto così:
Percorso diretto quando conosciuto, flooding quando necessario.
Questo permette di evitare che ogni messaggio diretto continui a coinvolgere inutilmente tutti i nodi raggiungibili.
La differenza decisiva: chi è responsabile della rete?
In Meshtastic, una parte importante del comportamento dipende dalle configurazioni dei singoli dispositivi.
In MeshCore, la responsabilità è maggiormente separata:
- il Companion appartiene all’utilizzatore;
- il Repeater garantisce la copertura;
- il Room Server conserva i messaggi;
- l’amministratore gestisce l’infrastruttura;
- il protocollo individua e memorizza i percorsi;
- i client ordinari non devono congestionare la rete ritrasmettendo il traffico altrui.
Questa impostazione è particolarmente importante nelle reti territoriali.
Una rete nazionale o regionale non può essere affidata all’idea che ogni persona configuri correttamente decine di opzioni, comprenda il comportamento del protocollo e valuti autonomamente l’impatto delle proprie modifiche.
Servono regole comuni, responsabilità precise e ruoli chiaramente identificati.
L’unico vero vantaggio operativo di Meshtastic
Esiste uno scenario nel quale Meshtastic può risultare più immediato: le attività temporanee in luoghi privi di qualsiasi infrastruttura.
Durante una scampagnata, un’escursione, un campeggio o un’attività tra poche persone, i dispositivi configurati come normali client possono contribuire alla ritrasmissione dei messaggi.
In assenza di un Repeater installato preventivamente, questa caratteristica può facilitare la comunicazione tra i partecipanti.
Si tratta, però, di uno scenario:
- temporaneo;
- circoscritto;
- caratterizzato da pochi dispositivi;
- limitato a un gruppo conosciuto;
- privo di una vera infrastruttura territoriale.
In questo contesto la partecipazione dei client alla ritrasmissione può essere utile.
Ciò che rappresenta un vantaggio in una piccola rete occasionale può però trasformarsi in un limite quando i nodi diventano decine o centinaia.
Una rete pubblica non può essere gestita come una scampagnata permanente.
MeshCore non è immune dai limiti della radio
È necessario essere chiari anche su un altro punto.
MeshCore non può eliminare i limiti fisici della tecnologia LoRa.
Anche una rete MeshCore può risentire di:
- congestione;
- interferenze;
- collisioni;
- installazioni errate;
- antenne inadeguate;
- eccessivo traffico flood;
- configurazioni radio incompatibili;
- un numero insufficiente o eccessivo di Repeater;
- mancato coordinamento territoriale.
Nessun protocollo può garantire una crescita infinita senza alcun degrado.
Il vantaggio di MeshCore consiste nell’offrire un’architettura più adatta a controllare questi problemi.
Ruoli distinti, percorsi memorizzati, amministrazione dei Repeater, Room Server separati e Companion che normalmente non ripetono costituiscono una base più solida sulla quale progettare una rete destinata a durare.
Meshtastic è sperimentazione, MeshCore è progettazione di rete
Meshtastic può essere interessante per chi desidera:
- sperimentare;
- modificare continuamente la configurazione;
- utilizzare sensori e moduli differenti;
- creare piccoli gruppi temporanei;
- effettuare tracking;
- provare collegamenti occasionali;
- utilizzare i client come parte della propagazione.
MeshCore è invece più indicato quando l’obiettivo è costruire:
- una rete cittadina;
- una rete provinciale o regionale;
- un’infrastruttura nazionale;
- una rete amministrata;
- un sistema di comunicazione stabile;
- una struttura radio destinata a rimanere operativa nel tempo;
- un servizio con copertura, responsabilità e ruoli chiaramente definiti.
La quantità delle opzioni disponibili non determina automaticamente la qualità di una rete.
In molti casi, un numero eccessivo di configurazioni lasciate alla discrezione individuale rende il sistema meno uniforme, più difficile da amministrare e maggiormente esposto a errori.
MeshCore sceglie invece una strada più precisa: ridurre l’improvvisazione e definire chi deve fare cosa.
Conclusioni
Meshtastic e MeshCore non sono semplicemente due applicazioni concorrenti installabili sugli stessi dispositivi. Rappresentano due concezioni differenti della rete.
Meshtastic privilegia la libertà del singolo nodo.
MeshCore privilegia l’organizzazione dell’intera infrastruttura.
Meshtastic può funzionare bene in piccoli gruppi, durante attività temporanee o in ambienti nei quali ogni dispositivo deve contribuire alla propagazione perché non esistono Repeater dedicati.
Quando però l’obiettivo è realizzare una rete territoriale ampia, stabile e duratura, la libertà di configurazione individuale può diventare un elemento di debolezza.
Una rete che cresce non può dipendere dall’improvvisazione, dalle interpretazioni personali o dalla possibilità che ogni utente modifichi autonomamente ruoli, hop, rebroadcast e traffico automatico.
Ha bisogno di un progetto.
Ha bisogno di terminali che svolgano la funzione di terminali, Repeater che garantiscano la copertura e Room Server che conservino i messaggi.
Ha bisogno di amministratori, responsabilità e regole condivise.
Per questo motivo, nella realizzazione di una vera infrastruttura radio territoriale, MeshCore rappresenta una scelta più razionale, stabile, performante e orientata al futuro.
Meshtastic può essere uno strumento per sperimentare o comunicare occasionalmente.
MeshCore è un’architettura sulla quale costruire una rete.