Con la versione 5.1.3 del SW Sarimesh Core viene supportata la funzionalità “MagicTag” : questa funzione consente di contrassegnare tutti pacchetti generati da un dispositivo LoRa ( sia che stia operando come Tracker o che stia operando come iGate) con una breve stringa di caratteri alfanumerici che consente di guidare il tracciamento dettagliato di ogni pacchetto e l’accesso diretto ad un sito web dove poter agevolmente visualizzare una serie di dettagli relative al traffico LoRa associato a questa etichetta.

Il formato dell’etichetta “MaicTag”  consiste in una strina che si presenta come un URL ( ovvero come un indirizzo di un sito web) ; la parte “host” dell’URL è proprio l’indirizzo di un sito web che fa da interfaccia utente verso una serie di pagine che consentono di visualizzare i dettagli voluti, mentre la prte successiva rappresenta un “percorso” atto a guidare il visitatore alle pagne specifiche associate al dispositivo tracker o iGate che ha generato questoo valore del MagicTag.

Il “percorso” è strutturato per essere estremamente compatto evitando inutili ridondanze che avrebbero solo l’effetto di allungare il tempo di trasmissione…  allo scopo ogni “pezzo” del “percorso” è ridotto ad uno o più caratteri ascii che codificano una serie di informazioni secondo delle opportune tabelle di corrispondenza; l’interpretazione di un path quindi è lasciata al SW del sito web indicato nella parte “host” dell’etichetta ed a priori è coordinata con l’impostazione della funzione MagicTag che va effettuata sul dispositivo tracker o iGate.

Quindi affinchè un dispositivo possa utilizzare questa funzione, vanno settati opportunamente alcuni parametri sul dispositivo stesso, come vdremo a seguire in questo articolo.

Il meccanismo MagicTag  può essere impostato sia a livello di un tracker, sia a livello di un iGate: i due usi hanno effetti diversi che ora descriviamo:

• Se impostato a livello di tracker l’effetto è quello di far si che tutti i pacchetti prodotti da quel tracker vengano propagati in maniera completamente trasparente sulla rete sia LoRa a radio frequenza che APRS-IS quando un tale pacchetto venga instradato verso tale rete; il pacchetto in condizioni di default NON verrà assolutamente modificato dagli iGate eventualmente attraversati, a meno che non sia espressamente richiesto dal valore della parte “percorso” del tag o dagli iGates attraversati.
• Se impostato a livello di iGate l’effetto è istruire l’iGate ad operare nel modo seguente:
  • se un generico pacchetto ricevuto lato LoRa e/o lato APRS-IS NON contiene un MagicTag, l’iGate provvede ad inserire il proprio MagicTag in modo che i pacchetti eventualmente immessi in rete LoRa dall’iGate appaiano etichettati con il MagicTag dell’iGate che ha accetto e inserito in rete LoRa quel pacchetto.
  • se un generico pacchetto ricevuto lato LoRa e/o lato APRS-IS GIA’ contiene un MagicTag, l’iGate opera normalmente lasciando tale ethichetta inalterata salvo il caso in cui il valore della parte “percorso” del  MagicTag o l’impostazione del iGate non richieda di operare diversamente.

 

In questo modo diventa possibile estendere la funzionalità di MagicTag automaticamente anche al traffico generato, in una certa area geografica, da dispositivi che non includono tale funzione, se a raccogliere e instradare i pacchetti di tali dispositivi è un iGate che abbia impostata la funzione MagicTag;  ovviamente questa funzione in questo caso andrà a modificare il campo “commento” del payload dei pacchetti generati da  dispositivi che non supportano la funzionalità MagicTag, e questo di fatto indurrà la generazione di “duplicati” verso APRS-IS qualora nella stessa zona ci siano dispositivi iGate attivi che non supportino la funzione MagicTag. Allo scopo di evitare  questo effetto di duplicazione è possibile impostare un opportuno valore della etichetta a livello di iGate che disabiliti questa funzione .

Il meccanismo di MagicTag oltre a svolgere le funzioni di “etichettatura” dei pachetti LoRa per consentirne l’analisi dettagliata senza impatti sui server APRS-IS, è pensato per consentire anche la creazione e la gestione di un collegamento bidirezionale tra gli elementi, siano essi trackers o iGate, di una rete LoRa, LIMITATAMENTE ed ESCLUSIVAMENTE a livello della rete LoRa ovvero coinvolgendo solo i dispositivi che siano visibili direttamente via collegamento a radio frequenza e quindi escludendo esplicitamente ogni interazione con la rete APRS-IS.

Questa utilizzazione della funzionalità MagicTag è ancora oggetto di studio e allo stato non è resa operativa nel nostro SW ver. 5.1.3.

Il meccanismo “Magic Tag” è pensato come un sistema completamente decentralizzato di monitoraggio del trafico LoRa: il modello di riferimento di una rete “Magic Tag ” è costituito da due livelli concettualmente distinti:

• un primo livello costituito da “Nodi Monitor” ovvero da dispositivi ( in genere iGates )  in grado di riconoscere e gestire i MagicTag presenti nei pacchetti producendo in genere un riporto , anche per ogni pacchetto , di una serie di informazioni relative al pacchetto verso uno o più servers del secondo livello della rete… come esempio un Nodo Monitor potrà generare dei contenuti aggiuntivi che potranno essere aggiunti eventualmente anche ai pacchetti ritrasmessi da quel nodo qualora ciò sia voluto ma sempre ed esclusivamente verso la rete LoRa… MAI verso APRS-IS; queste stesse informazioni o anche altre aggiuntive potranno essere riportate verso uno o più server di aggregazione utilizzando in genere la connettività TCP/IP ( se disponibile) o anche, in maniera appropriata, sfruttando direttamente la connettività LoRa se il server di aggregazione è raggiungibile esclusivamente tramite la rete LoRa.
• un secondo livello costituito da Servers di aggregazione: questi dispositi saranno dotati di una opportuna capacità di calcolo ed archiviazione in modo da poter conservare e storicizzare gli spots ricevuti dai “Nodi Monitor” implementando opportune funzioni di display via web che consentano di analizzare e mostrare i dati ricevuti applicando opportune ed eventuali azioni di filtraggio, aggregazione e postelaborazione dei dati ricevuti. Il modo di collegamento di un nodo aggregatore ai suoi nodi monitor potrà essere di qualsiasi tipo… ovviamente se il collegamento sarà solo via LoRa un tale nodo dovrà essere necessariamente colocato con un nodo monitor o con un nodo altrimenti raggiungibile via LoRa… in questo caso è possibile realizzare una sottorete MagicTag completamente OFF-GRID  molto utile per situazioni di tipo emergenziale o in cui non sia presente nessuna connettività alternativa a quella LoRa. Analogamente un nodo aggregatore potrà essere raggiungibile esclusivamente tramite per esempio TCT/IP… in questo caso la connessione del server ai suoi nodi monitor dovrà avvenire usando la connettività TCP/IP per esempio sfruttando degli iGate connessi ad ad internet.

 

Il formato secondo cui i nodi monitor possano trasmettere i propri dati ai server di aggregazione è ancora oggetto di studio; ad oggi sono implementate due soluzioni:

• per il riporto via rete LoRa si sfrutta semplicemente l’aggiunta di un addon al campo commento del pacchetto da riportare, ovviamente esclusivamente lato LoRa ( radio frequenza) usando allo scopo un Modo LoRa ad esempio con SF=7 in modo da non caricare il canale da trackers ad iGates…
• per il riporto via TCP/IP si utilizza un formato di pacchetto derivato direttamente dal formato di logging dettagliato del SW Direwolf, aggiungendo al campo commento un opportuno addons esattamente corrispondente a quello eventualmente aggiunto via LoRa..
• un generico nodo monitor potrà implementare il riporto simultaneamente sia verso il lato LoRa che verso il lato TCP/IP al momento limitatamente ad un singolo server aggregatore ( lato TCP/IP).

 

Ovviamente si pone il problema di avere una “situazione” della rete MagicTag…  allo stato il come fare è ancora oggetto di studio … l’idea sarebbe quella di avere un sito web master a cui affidare la funzione di “inventario” dei server della rete in modo da consentire di conoscere e scegliere opportunamente un nod monitor a cui un generico elemento di rete LoRa possa far riferimento come pure un opportuno server di aggregazione a cui affidare il display dei dati fatti pervenire tramite il nodo Monitor scelto.

 

Come impostare la funzione di “Magic Tag”

La funzione di MagicTag può essere impostata singolarmente per ogni dispositivo LoRa e richiede lil settaggio di pochi parametri come di eseguito andiamo ad illustrare. Allo stato attuale essendo il tutto estremmamente sperimentale la scelta del nodo monitor e del server di aggregazione è “cablato nel SW” nel senso che non è ancora presente nulla di diverso per selezionare in maniera più articolata tali elementi. in futuro questa funzione verrà espansa come sopra descritto appoggiandosi per es. ad u n opportuno sito web master.

Innanzitutto bisogna impostare nella pagina di “APRS CONFIGURATION”  il parametro “Node Monitor” selezionandolo da una lista di valori proposti e il server di aggregazione impostando attualmente i valori  APRS Logger Host  “http://mrtg3.eu”  e APRS Logger Port  44445 ; quindi salvare la nuova impostazione della pagina.

 

Successivamente per attivare la funzionalità di Magic Tag andare nella pagina “APRS FEATURES” e selezionare nel campo  “RX Reports”  il valore MagicTag; quindi salvare la pagina.

 

 

Infine andare nella pagina “OPERATION MODE SETTINGS” e effettuare il commit della nuova configurazione e successivamente effettuando il reboot del dispositivo per rendere attiva la nuova configurazione.