Introduzione
Sono sempre più numerose le richieste di chiarimento che riceviamo, sia attraverso il gruppo Telegram di MeshCore Italia sia privatamente, riguardo al funzionamento e soprattutto alla corretta configurazione del Regional Scope. Molti utenti ne hanno sentito parlare, altri hanno notato questa funzione nelle impostazioni dell’applicazione o nei comandi CLI dei ripetitori, ma non sempre è chiaro a cosa serva, dove inserire i parametri e quali vantaggi possa offrire. Abbiamo quindi deciso di dedicare questo articolo all’argomento, cercando di spiegare in maniera semplice, con esempi concreti, il funzionamento di questa importante caratteristica di MeshCore. Il Regional Scope non è soltanto una funzione tecnica: è uno strumento che, se utilizzato correttamente, può contribuire a rendere la nostra rete nazionale più ordinata, efficiente e sostenibile, soprattutto considerando il numero crescente di nodi e ripetitori presenti sul territorio.
Che cos’è il Regional Scope?
Immaginiamo di inviare un messaggio da Roma per chiedere se qualcuno è disponibile a effettuare una prova radio nella zona dei Castelli Romani. È davvero necessario che questo messaggio venga ritrasmesso anche dai ripetitori della Lombardia, della Puglia o della Sicilia? Naturalmente no, almeno nella maggior parte dei casi. Il Regional Scope permette di associare ai messaggi un identificativo territoriale, consentendo ai ripetitori opportunamente configurati di decidere se inoltrarli oppure no.
Per esempio:
itidentifica l’ambito nazionale.it-lazidentifica il Lazio.it-pugidentifica la Puglia.it-lomidentifica la Lombardia.it-laz-rmidentifica un possibile ambito provinciale di Roma.
Questi identificativi non sono coordinate geografiche e non vengono interpretati automaticamente in base alla posizione dei dispositivi. Sono nomi convenzionali che devono essere riconosciuti e gestiti dai ripetitori della rete. In altre parole, è come indicare su una busta la zona alla quale è destinata una comunicazione: i ripetitori, attraverso le proprie regole, stabiliscono se contribuire alla sua distribuzione.
Capitolo 1 — Come configurare il Regional Scope su un Companion
Partiamo dal dispositivo più utilizzato dagli utenti: il Companion, normalmente collegato allo smartphone tramite Bluetooth. La configurazione avviene direttamente dall’interfaccia grafica dell’app MeshCore, senza dover utilizzare comandi CLI. È importante distinguere due modalità: lo scope predefinito del dispositivo e quello specifico di un singolo canale.
1.1 Impostare lo scope predefinito
Nelle versioni recenti dell’app MeshCore che supportano questa funzione:
- Aprire l’app MeshCore e collegarsi al proprio Companion.
- Toccare la ruota dentata, che identifica il menu delle impostazioni (Settings).
- Individuare nelle impostazioni la voce Default Region Scope, quando presente; la sua posizione dipende dalla versione dell’app.
- Selezionare o aggiungere il codice territoriale desiderato.
- Confermare e salvare le modifiche, utilizzando il segno di spunta dove previsto.
Per esempio, un utente residente nel Lazio potrebbe scegliere:
it-laz
Questo codice diventa lo scope predefinito delle comunicazioni flood del dispositivo, salvo eventuali impostazioni specifiche dei singoli canali. Attenzione: uno scope predefinito non riguarda soltanto la conversazione che si ha aperta in quel momento. Può interessare anche altre comunicazioni flood generate dal Companion. Per questo motivo va scelto consapevolmente. Se non si desidera applicare uno scope generale, è possibile lasciarlo vuoto e configurare soltanto i canali per i quali serve.
1.2 Configurare lo scope di un singolo canale
Questa possibilità è particolarmente interessante perché permette di scegliere ambiti differenti in funzione della conversazione. Per esempio, potremmo voler utilizzare il canale Public per comunicazioni generiche e un altro canale per i messaggi destinati principalmente al Lazio.
Procedura nell’app MeshCore:
- Aprire l’elenco dei canali.
- Entrare nel canale che si desidera configurare, per esempio Public oppure un canale regionale.
- Aprire il menu del canale, generalmente identificato dai tre puntini.
- Selezionare Set Region Scope.
- Scegliere un codice già presente nell’elenco oppure aggiungerne uno nuovo, ad esempio
it-laz. - Confermare la selezione.
Da questo momento i messaggi trasmessi su quel canale utilizzeranno lo scope specificato, che ha precedenza sull’eventuale impostazione predefinita. Per eliminare uno scope configurato direttamente sul canale, utilizzare l’opzione Clear Scope, quando disponibile. Il nome delle voci e la loro posizione possono variare leggermente in base alla versione dell’app o al sistema operativo utilizzato.
1.3 Esempio pratico
Supponiamo di avere un Companion a Roma e di partecipare a due conversazioni differenti.
Prima situazione: vogliamo chiedere agli utenti del Lazio se sono disponibili a effettuare una prova di copertura radio. Sul canale interessato impostiamo it-laz.
Seconda situazione: desideriamo partecipare a una discussione tecnica di interesse nazionale. Sul relativo canale possiamo utilizzare it, purché la rete sia configurata per gestire tale ambito.
In questo modo possiamo differenziare le comunicazioni senza dover modificare ogni volta la configurazione generale del dispositivo. Ricordiamo che lo scope riguarda soprattutto la propagazione dei messaggi inviati: non impedisce al Companion di ricevere comunicazioni provenienti da altri ambiti quando queste raggiungono il dispositivo.
1.4 Dove trovare i codici da utilizzare?
Per facilitare l’utilizzo di questa funzione, MeshCore Italia mette a disposizione una pagina dedicata con i codici territoriali, gli esempi di utilizzo e le indicazioni per una configurazione coerente. Consultare la guida: https://www.meshcoreitalia.it/regional-scope/
Il nostro suggerimento è di utilizzare principalmente il livello nazionale it oppure quello regionale it-xxx. Gli scope provinciali, come it-laz-rm, dovrebbero essere introdotti soltanto nelle aree dove la rete è già organizzata per gestirli correttamente.
Capitolo 2 — Come configurare il Regional Scope sui Repeater
Passiamo ora ai ripetitori MeshCore, che svolgono un ruolo fondamentale nella distribuzione dei messaggi. A differenza del Companion, sul quale l’utente sceglie lo scope da associare alle proprie comunicazioni, sul Repeater vengono definite le regioni e le regole che determinano quali messaggi possono essere ritrasmessi. La configurazione può essere effettuata attraverso la CLI (Command Line Interface), utilizzando una connessione locale oppure l’accesso remoto autorizzato al ripetitore.
2.1 Un esempio pratico: configurare un Repeater nel Lazio
Supponiamo di gestire un ripetitore che opera principalmente nella regione Lazio. Vogliamo predisporlo per gestire sia lo scope nazionale it sia quello regionale it-laz. Accediamo alla CLI del ripetitore e inseriamo i seguenti comandi, uno alla volta.
Creazione della regione nazionale:
region put it
Creazione della regione Lazio, collegata gerarchicamente all’Italia:
region put it-laz it
Abbiamo così definito una struttura semplice:
it
└── it-laz
Per permettere la ritrasmissione dei messaggi relativi agli ambiti configurati, impostiamo le autorizzazioni di flooding:
region allowf it
region allowf it-laz
Infine salviamo la configurazione:
region save
Il salvataggio è importante per conservare le modifiche effettuate. I comandi illustrati sono un esempio di configurazione di base: prima di applicarli a un ripetitore già operativo è opportuno verificare le regioni e le politiche esistenti, evitando di modificarle senza conoscere il ruolo del nodo nella rete.
2.2 Come verificare la configurazione?
Possiamo interrogare le regioni configurate con:
region get it
region get it-laz
Per visualizzare la configurazione complessiva delle regioni, nelle versioni che lo supportano, si possono utilizzare anche i comandi di elenco e visualizzazione previsti dalla CLI. È sempre consigliabile verificare sia la gerarchia sia i permessi effettivi di flooding.
2.3 E se un Repeater copre due regioni?
Immaginiamo un ripetitore installato in posizione elevata, capace di servire stabilmente sia il Lazio sia l’Umbria. In questo caso potrebbe essere opportuno prevedere entrambi gli scope regionali.
Un esempio:
region put it
region put it-laz it
region put it-umb it
region allowf it
region allowf it-laz
region allowf it-umb
region save
La struttura diventa:
it
├── it-laz
└── it-umb
Questo esempio dimostra che non è obbligatorio associare un ripetitore a una sola regione. La scelta deve però essere giustificata dalla copertura radio effettiva e dal ruolo del nodo. Aggiungere indiscriminatamente regioni non migliora la rete e rischia, al contrario, di aumentarne inutilmente il traffico.
2.4 La gerarchia non è automatica
Un punto particolarmente importante riguarda la relazione tra le regioni. Se definiamo it-laz-rm come ambito provinciale, non è sufficiente che il suo nome contenga it-laz perché venga automaticamente riconosciuto come figlio del Lazio.
La gerarchia deve essere dichiarata esplicitamente.
Per esempio:
region put it
region put it-laz it
region put it-laz-rm it-laz
Questa configurazione definisce tre livelli:
Italia: it
└── Lazio: it-laz
└── Roma: it-laz-rm
La gestione del flooding deve poi essere verificata in base ai permessi configurati. È importante ricordare che la presenza di una gerarchia non significa che tutti i ripetitori della rete siano automaticamente configurati nello stesso modo. Se un altro ripetitore riconosce lo stesso scope, potrà gestirlo secondo le proprie regole anche quando la sua gerarchia locale è diversa. Una configurazione omogenea rimane comunque preferibile per ottenere comportamenti prevedibili.
2.5 Attenzione ai messaggi senza scope
Un’altra impostazione da conoscere riguarda i messaggi privi di Regional Scope, detti anche unscoped. Questi pacchetti possono continuare a essere inoltrati dai ripetitori che ne consentono il flooding. Il parametro CLI flood.max.unscoped, disponibile nei firmware che lo supportano, permette di limitarne il numero massimo di hop. È una possibilità interessante per contenere la propagazione dei messaggi non regionalizzati, senza necessariamente bloccarli completamente.
Occorre invece prestare particolare attenzione al comando:
region denyf *
Questo comando può impedire la ritrasmissione dei pacchetti flood privi di scope. Non dovrebbe essere applicato indiscriminatamente, perché potrebbe interrompere comunicazioni provenienti da Companion o applicazioni che non utilizzano ancora il Regional Scope. Prima di adottare politiche restrittive, è indispensabile valutare il comportamento dei ripetitori vicini e dei dispositivi presenti nella rete.
2.6 Riferimenti per la configurazione
Per conoscere tutti i codici regionali suggeriti, gli scenari di utilizzo e le indicazioni per i gestori dei ripetitori, consigliamo di consultare: MeshCore Italia — Regional Scope: https://www.meshcoreitalia.it/regional-scope/ Per i dettagli sui comandi CLI è disponibile anche la documentazione tecnica ufficiale: https://docs.meshcore.io/cli_commands/
Capitolo 3 — Quali sono i benefici per la rete MeshCore?
Il vantaggio principale del Regional Scope è la possibilità di ridurre le ritrasmissioni radio che non sono necessarie. In una rete mesh, infatti, ogni messaggio inoltrato da un ripetitore occupa il canale radio per un certo intervallo di tempo. Quando molti ripetitori ritrasmettono messaggi che non riguardano realmente le loro aree, il traffico complessivo può aumentare considerevolmente.
Un impiego corretto del Regional Scope contribuisce a:
- Ridurre il traffico superfluo, evitando propagazioni non necessarie.
- Ottimizzare l’utilizzo del canale radio, lasciando maggiori opportunità di trasmissione agli altri nodi.
- Limitare il rischio di congestione, soprattutto nelle aree con molti ripetitori.
- Organizzare le comunicazioni territoriali, distinguendo gli interessi locali da quelli nazionali.
- Favorire la crescita della rete, rendendo più sostenibile la gestione del traffico all’aumentare dei dispositivi.
Naturalmente non si tratta di una soluzione miracolosa: le prestazioni dipendono anche dalla qualità dei collegamenti radio, dalla configurazione dei nodi e dalla topologia della rete.
Capitolo 4 — Cosa succede se non utilizziamo il Regional Scope?
Non utilizzare questa funzione non significa che MeshCore smetta di funzionare. I messaggi senza scope possono continuare a propagarsi attraverso i ripetitori che ne consentono la ritrasmissione. Il problema può presentarsi quando una rete diventa molto estesa. Immaginiamo che una semplice conversazione tra due utenti del Lazio venga ripetuta da decine di nodi distribuiti in altre regioni. Ogni ripetitore coinvolto impiega una parte del tempo radio disponibile, anche quando quella conversazione non interessa gli utenti della sua zona. Un singolo messaggio potrebbe avere un impatto trascurabile, ma il problema diventa più significativo quando lo stesso comportamento si ripete continuamente e contemporaneamente da parte di molti dispositivi. È proprio per evitare queste situazioni che una gestione più consapevole degli scope può diventare particolarmente utile.
Capitolo 5 — Cosa succede se il Regional Scope viene configurato male?
Una configurazione errata può essere persino più problematica della mancata configurazione.
Facciamo alcuni esempi.
Primo caso: codice errato.
Un utente configura il proprio Companion con uno scope scritto in maniera differente rispetto a quello previsto dalla rete. I ripetitori che non riconoscono tale identificativo potrebbero non inoltrare il messaggio.
Secondo caso: Repeater non configurato.
Un Companion trasmette un messaggio con scope it-laz, ma lungo il percorso si trova un ripetitore che non ammette tale ambito. Il pacchetto potrebbe non proseguire oltre quel punto, impedendo di raggiungere altri utenti.
Terzo caso: scope troppo esteso.
Un utente utilizza sistematicamente it anche per comunicazioni strettamente locali. La rete continuerà a funzionare, ma verranno ridotti i benefici derivanti dalla suddivisione territoriale del traffico.
Quarto caso: limitazioni eccessive.
Un amministratore blocca i messaggi senza scope senza aver verificato la presenza di dispositivi che ancora li utilizzano. Alcune comunicazioni potrebbero interrompersi inaspettatamente. Per questo motivo la configurazione dovrebbe sempre essere accompagnata da prove reali di trasmissione e ricezione.
Capitolo 6 — Alcuni consigli pratici
Per chi utilizza un Companion, il suggerimento è di iniziare con configurazioni semplici, scegliendo lo scope più appropriato per le proprie comunicazioni e verificando che sia supportato dalla rete circostante. Per chi amministra un Repeater, invece, è importante concordare una nomenclatura comune, conoscere la copertura effettiva del nodo e verificare le configurazioni dei ripetitori confinanti. Non bisogna necessariamente configurare fin da subito tutti i livelli provinciali. Il livello regionale rappresenta già un buon punto di partenza, mentre quello provinciale può essere introdotto dove la densità della rete e il volume del traffico lo rendano realmente utile. Un’ultima raccomandazione: non confondiamo il Regional Scope con i canali MeshCore. Il canale identifica l’ambiente di conversazione e la relativa chiave di accesso, mentre lo scope definisce l’ambito di propagazione del messaggio. Sono due elementi distinti che possono lavorare insieme.
Capitolo 7 — Nodi Osservatori: perché non bisogna configurare il Regional Scope
Una precisazione importante riguarda i Nodi Osservatori della rete MeshCore Italia. A differenza di un Companion, utilizzato per inviare e ricevere comunicazioni, o di un Repeater, incaricato anche di ritrasmetterle, il compito principale di un Nodo Osservatore è ascoltare e raccogliere informazioni sui pacchetti radio ricevuti, così da contribuire ai sistemi di monitoraggio e analisi della rete. Per questo motivo, sui Nodi Osservatori non è necessario configurare un Regional Scope per limitare l’ascolto: l’obiettivo è osservare il traffico flood che arriva via radio, indipendentemente dal fatto che sia associato a it, it-laz, it-pug o che sia privo di scope.
Un esempio pratico
Immaginiamo un Nodo Osservatore installato nel Lazio che riceva direttamente i pacchetti di diversi ripetitori. Durante il monitoraggio potrebbe rilevare comunicazioni contrassegnate con it-laz, altre con it e anche pacchetti senza Regional Scope. Non avrebbe senso restringere l’osservazione al solo codice it-laz: si perderebbe una parte delle informazioni utili a comprendere il traffico effettivamente presente in quella zona.
Attenzione: ascoltare non significa ritrasmettere
Il Nodo Osservatore non deve comportarsi come un Repeater: il suo ruolo è ricevere, registrare e, se previsto, inoltrare i dati al sistema di monitoraggio, non propagare nuovamente via radio i messaggi ricevuti. Occorre inoltre ricordare che nessun osservatore può ascoltare magicamente tutta la rete nazionale. Può rilevare soltanto i pacchetti che raggiungono realmente la sua antenna, direttamente o attraverso le ritrasmissioni degli altri nodi. Se un Repeater blocca un messaggio prima che questo raggiunga l’area osservata, quel messaggio non sarà visibile all’Osservatore. In sintesi: il Regional Scope è uno strumento per organizzare la propagazione del traffico, mentre il Nodo Osservatore deve mantenere un ascolto il più possibile completo del traffico radio effettivamente ricevibile.
Conclusioni — Una rete più efficiente dipende anche da noi
Il Regional Scope rappresenta un’opportunità concreta per migliorare il funzionamento della rete MeshCore, soprattutto in un contesto nazionale in continua crescita come quello italiano. Non dobbiamo considerarlo un ostacolo alla comunicazione o un sistema per isolare territori, ma piuttosto uno strumento per utilizzare in maniera più intelligente le risorse radio disponibili. La vera forza di MeshCore non risiede soltanto nel numero di ripetitori installati, ma anche nella capacità di farli collaborare in maniera coordinata ed efficiente. Per questo motivo invitiamo tutti, sia gli utilizzatori dei Companion sia gli amministratori dei Repeater, ad approfondire questa funzione e ad adottarla gradualmente, seguendo criteri condivisi e verificando il comportamento della rete.
Ridurre il traffico inutile significa lasciare più spazio alle comunicazioni realmente necessarie.
Ed è anche attraverso queste piccole attenzioni che, grazie all’impegno e alla collaborazione di tutti, possiamo continuare a costruire una rete MeshCore italiana sempre più efficiente, affidabile e sostenibile.
MeshCore Italia — Una rete che cresce grazie al contributo di tutti.
