Recentemente la nostra attività di sperimentazione si è arricchita di una significativa nuova collaborazione con il gruppo “Radio Emergency Terra delle Sirene” che nella nostra zona (Campania) si occupa del supporto radio in caso di emergenze, coordinandosi, nell’ambito di una più ampia organizzazione di nome R.N.R.E. con gli organismi della Protezione Civile Nazionale.

Da questa collaborazione sono emerse una serie di nuove interessanti evidenze in tema di “servizi” che tali organizzazioni si aspettano da una rete quale la nostra SARIMESH, in una situazione di tipo emergenziale.

Un fatto estremamente significativo, e che forse parecchi non si aspetterebbero, è che i servizi richiesti in questi tipi di contesti NON sono affatto quelli che i radioamatori sono abituati a considerare tradizionalmente come i servizi emergenziali per eccellenza, ma bensì una serie di altri servizi che oggi tutte le organizzazioni che operano sul territorio sono abituate ad usare e che in una situazione di emergenza vorrebbero continuare ad usare….

Un banale esempio per tutti è la disponibilità della connettività di rete TCP/IP che oggi la stragrande maggioranza dei servizi utilizza associata a diversi valori di banda richiesta, e che sfortunatamente tutti i classici sistemi radioamatoriali stentano a fornire per banali limiti di banda disponibile sulle frequenze normalmente utilizzate per le comunicazioni radioamatoriali  ( es. HF, VHF ).

Ovviamente questo non si applica alla nostra rete SARIMESH che si differenzia come sapete dalle tradizionali reti per essere una rete a larga banda e soprattutto per essere una rete nativamente TCP/IP.

Questo particolare attibuto rende la nostra soluzione particolarmente interessante per un uso in connessione a situazioni emergenziali  ovviamente in primis in un ambito locale o sub-regionale.

Assodato quindi che la rete SARIMESH è una rete nativamente TCP/IP e quindi in grado di supportare tutti i servizi normalmente utilizzati su internet, sembrerebbe che tutto si risolva nel rendere disponibile dei nodi di accesso a questa rete da parte di soggetti e terminali riconducibili ad attori operanti nel contesto emergenziale….

In effetti nella nostra variante SARIMESH della tecnologia originaria AREDN, ci siamo premurati di definire una struttura standard dei nostri nodi che fosse in grado di offire ai suoi potenziali utilizzatori una modalità di accesso del tutto “standard”, ovvero esattamente allineata ai modi normalmente utulizzati per i normali utenti della rete internet per collegarsi ad internet: tipicamente tramite connessione di rete LAN in standard IEEE 802.3 o in modalità wireless a standard IEEE802.11 nelle sue varie varianti.

Purtroppo però quello della connettività TCP/IP di tipo standard è una condizione necessaria ma non sufficiente affinchè un utente generico ( quale ad es. un operatore in condizioni di emergenza) possa svolgere i servizi che vorrebbe svolgere….

Il motivo purtroppo è da ricercare nel fatto che con il moderno paradigma di rete internet o TCP/IP in particolare, un generico servizio viene strutturato con una serie di entità che si attaccano alla rete di trasporto IP come dei terminali o delle entità di servizio dalla cui inter-operazione scaturiscono le caratteristiche del servizio stesso……

Se è vero che esistono servizi che richiedono per il loro svolgimento solo la presenza di due o più terminali, purtroppo molti servizi sfruttano un paradigma di tipo client-server nel quale per es. due terminali per riuscire a comunicare hanno bisogno del contributo attivo di una entità terza la cui presenza ed attività è essenziale allo svolgimento del servizio….

Un esempio è il servizio di comunicazione vocale a livello di rete pubblica o (quasi) tutti i servizi di chat o di videoconferenza attualmente esistenti…  Tutti questi servizi richiedono per poter funzionare la presenza ovvero la raggiungibilità di un “Server” in genere presente su internet.

Il risultato netto di questo paradigma è che la quasi totalità dei servizi di comunicazione audio/video pubblici in condizioni di emergenza ed in particolare in assenza di connettività internet diventano indisponibili.

Orbene se è ancora accettabile che tali servizi in ambito pubblico possano essere temporaneamente indisponibili, non è assolutamente accettabile che tali servizi siano indisponibili anche all’interno della zona servita direttamente dai servizi di comunicazione emergenziali.

Fatta questa rapida premessa nel seguito andiamo ad analizzare in dettaglio gli aspetti salienti del discorso servizi come emerge oggi da una analisi , aggiornata agli anni 2000, del tema supporto emergenziale.

 

Servizi di Supporto emergenziali

Dalla analisi dei protocolli operativi nell’ambito della strategia di supporto delle comunicazioni in caso di emergenze attualmente in uso in Italia emergono una serie di scenari di servizio che di seguito vengono illustrati.

Uno scenario emergenziale di tipo nazionale assume che siano inutilizzabili tutti i tradizionali sistemi di comunicazione civile utilizzati normalmente: ad es. sono considerati non operative le reti fisse di tipo sia voce che dati internet, le reti mobili e le altre reti di uso pubblico, escluse le sole reti che utilizzano connessioni satellitari.

La situazione di cui al punto precedente può coinvolgere ovviamente zone più o meno estese eventualmente dislocate in distretti geograficamente distribuiti.

L’obiettivo principale in una tale situazione è essere in grado di ristabilire, anche se in maniera degradata e limitata, la maggior parte dei servizi normalmente utilizzati in condizioni di tipo non emergenziali, utilizzando possibilmente gli stessi terminali o terminali ad hoc da fornire a soggetti/uffici individuati nel piano emergenziale.

In dettaglio sono considerati i seguenti servizi:

1. Connessione alla rete telefonica pubblica facendo uso di modalità di connessione VoIP e appoggiandosi a server telefonici pubblici, utilizzando numerazioni di rete pubblica predefinite a livello di piano emergenziale.
2. Connessione ai servizi di e-mail pubblici con modalità standard ed utilizzando server di posta pubblici; la connessione si assume debba poter avvenire sia da dispositivi fissi che mobili ( PC, smartphones) utilizzando connettività IP standard.
3.  Connettività IP per uso generico allo scopo di consentire servizi quali trasferimento di files, accesso a server sia all’interno della rete emergenziale che all’esterno della stessa, per realizzare servizi di WEB browsing o di accesso a portali assimilabili.
4.  Supporto di traffico IP di tipo streaming per realizzare servizi di tipo multimediale ( audio/video) anche se con limitate caratteristiche di performance.

 

Ai servizi elencati vanno aggiunti tutti gli eventuali servizi di tipo intranet che si possa rendere necessario fornire e supportare tra i terminali al servizio dell’emergenza.

Esempi di servizi di tipo intranet che possano rendersi necessari o utili si elencano senza un particolare ordine i seguenti:

• Servizi di streaming audio/video per scopi di monitoraggio , supervisione , videosorveglianza, etc.
• Servizi di audio/video multiparty conference
• Servizi di condivisione di dati tramite metodiche di file sharing o accesso a servers locali
• Servizi di posta elettronica intranet
• Servizi di posta elettronica extranet tramite protocollo Winlink 2000
• Servizi di localizzazione di terminali mobili tramite protocolli di tipo APRS o similari
• Servizi di accesso a sensori distribuiti sul territorio .
• Accesso ad internet da parte di terminali di servizio emergenziale.
• Accesso ad internet da parte di terminali NON al servizio dell’emergenza.

 

Tutti i servizi elencati richiedono per poter essere espletati la disponibilià dei seguenti elementi:

• Disponibilità di connettività internet garantita tramite connessione satellitare o, in caso di disponibilità, anche della tradizionale connessione internet di tipo fisso/mobile.
• Disponibilià di una rete di accesso di tipo radio in grado di fornire connettività IP con sufficienti caratteristiche di performance per supportare i servizi indicati.

 

In particolare si evidenziano i seguenti elementi di performance che sia la connessione internet, che la rete di accesso devono poter garantire:

• Disponibilità di connettività IPV4
• Caratteristiche di latenza adeguate al supporto dei servizi VoIP ( tipicamente entro valori appropriati di jitter, latenza e packet loss )
• Caratteristiche di banda disponibile in accordo ai volumi di traffico non-real-time previsti
• Caratteristiche di banda disponibile in accordo ai volumi di traffico real-time previsti

 

I parametri di cui sopra dipenderanno dalla dimensione e dalla consistenza dell’area da servire in regime emergenziale.

Considerando la disponibilità di mercato di servizi di connettività IP satellitare bidirezionale è possibile affermare che la banda disponibile sul tale connessione non superi tipicamente i valori di 8 Mbit/sec in downstream/upstream.

Sulla base di tale elemento di dimensionamento è possbile affermare che ha senso assumere per la rete di accesso radio che si attesta su una singola connessione satellitare dei valori di banda da rendere disponibile a livello IP dell’ordine di 1-2 volte il traffico esterno, assumendo un mix di servizi di tipo intranet aggiuntivo pari al 100% del traffico esterno.

 

Come si posiziona SARIMESH rispetto a queste richieste di servizio…

Per come è stata concepita ed mplementata la rete SARIMESH e la rete AREDN su cui essa si basa, sono delle reti full-IP in grado di garantire supporto di connettività TCP/IP di tipo IPv4  in modalità full-routed a tutti i dispositivi attestati ai nodi della rete, con delle caratteristiche di performance in termini di latenza e banda disponibile che consentono di definire la rete come una “rete a banda larga”, ovvero di tipo “multi-megabit”.

Quindi la rete si presenta come perfettamente in grado di fornire il grosso delle carateristiche funzionali che sono richieste dai servizi indicati al punto precedente.

Ovviamente si rendono necessarie una serie di aggiunte funzionali allo scopo di poter supportare nello specifico alcuni servizi che per loro natura oltre a richiedere la semplice connettivià TCP/IP, richiedono la presenza di entità di supporto funzionale allo scopo di fornire la necessaria funzionalità in particolare in ambito “rete isolata” ovvero in caso di mancanza assoluta di connessione internet.

I servizi a cui si applica questa considerazione sono tutti i servizi di tipo client-server che per loro natura richiedono la presenza di un “server” per poter operare: normalmente tale server è dislocato su internet, per cui in caso di assenza di internet tale server dovrà essere sostituito da un equivalente entità dislocata localmente ed in grado di fornire una funzionalità equivalente e sostitutiva per gli utenti interessati.

Una ulteriore richiesta funzionale riguarda la modalità di connessione ad internet della rete mesh tramite connessione internet satellitare: trattasi di una modalità del tutto equivalente dal punto di visto funzionale ad una normale connessione internet di tipo in ADSL o in fibra, a parte alcune piccole peculiarità operative.

Nel seguito si affrontano in particolare alcuni casi significativi di servizi client-server da rendere disponibili sulla rete SARIMESH allo scopo di rendere la soluzione pienamente utilizzabile per gli scopi emergenziali sopra tratteggiati.

 

Gateway satellitare per la rete SARIMESH

Per una rete che si prefigge di operare in condizioni di emergenza assume molta importanza la possibilità di accedere ad internet anche in condizioni estreme di disponibilità di infrastrutture di telecomunicazione.

La rete mesh, ad es. SARIMESH, consente di dispiegare rapidamente un insieme di nodi mobili in grado di operare anche in assenza completa di infrastrutture, a meno della disponibilità di un accesso internet.

Assume quindi importanza la possibilità di realizzare un punto di accesso internet che utilizzi la tecnologia di accesso internet satellitare bididirezionale, l’unica in grado di operare realisticamente in una situazione di tipo catastrofico, con livelli di performance accettabili, ovvero fuori dalle aree di congestione che una situazione di tale tipo necessariamente induce.

Esistono soluzioni di connettività satellitare bidirezionale di diversi tipi, ma tutte hanno proprie peculiarità per cui si rende necessario predisporsi ad utilizzare una certa soluzione, da adattare e soprattutto validare come interoperabilità con l’ambiente operativo da dispiegare in caso di catastrofe.

Vale la pena di puntualizzare che non è sufficiente predisporre semplicemente una connessione satellitare, ma è necessario che tale soluzione sia dimostrata e verificata interoperabile con l’ambiente terrestre da utilizzare per poi distribuire tale connetività sull’area di crisi.

L’utilizzo di una rete mesh tipo quella implementata da SARIMESH consente di rendere disponibile un ambiente standard di distrinbuzione della connettività su una area di crisi, per cui è sufficiente dimostrare la fattibilità di un nodo di accesso satellitare per la rete sarimesh per assicurare una soluzione ragionevolmente sicura per l’accesso internet.

Un nodo di accesso internet per la rete SARIMESH può essere considerato una variante di un nodo mobile, descritto in precedenza, nel quali siano implementate un limitato numero di funzioni aggiuntive strettamente collegate all’utilizzo del nodo come nodo di accesso internet satellitare bidirezionale.

Le funzionalità da aggiungere sono sostanzialmente le seguenti:

• interfaccia verso la linea ADSL satellitare
• funzionalità di controllo e gestione dell’accesso internet (firewall e controllo perimetrale)
• funzionalità di accesso remoto dall’esterno della rete sarimesh, tramite la linea satellitare.

 

Una importante nota riguarda la tipologia di accesso satellitare da predisporre; date le peculiarità dell’utilizzo è essenziale che sia una connessione senza limiti di volume sulla connessione e con possibilità di avere una banda disponibile in upstrean/downstream assimlabile ad una linea ADSL di buona qualità, anche se non necessariamente con valori di banda minima garantita, che farebbe lievitare in maniera spropositata i costi di gestione.

Dall’analisi di mercato ad oggi risulta che la soluzione che meglio si confà alla fatispecie indicata è quella offerta dal provider tedesco SKYADSL che presenta livelli di costo e performances adeguati; la soluzione suggerita è SKYDSL2+ Premium L.

L’apparecchiatura HW necessaria è utilizzabile con un contratto di tipo leasing per un limitato costo mensile; è inoltre possibile dismettere il contratto entro un mese solare senza penali.

La soluzione è ampiamente collaudata e agevolmente re-installabile anche in ambiente abbastanza critico dal punto di vista logistico, non richiedendo particolari predisposizioni.

Il nodo viene configurato con una antenna verticale a 5Ghz MIMO 13db e alimentata da una radio MIMO Ubiquiti Rocket M5.

Per implementare le funzionalità di firewall si utilizza un dispositivo MikroTik RB962U

Per implementare le funzioni ausiliarie si utilizza un controllore Raspberry PI 4

La seguente è la part list dettagliata per un tale nodo:

• N. 1 antenne Ubiquiti airMAX 5 GHz 2×2 Omni Antenna (AMO-5G13) es. https://www.interprojekt.it/ubiquiti/AMO-5G13 costo unitario € 121
• N. 1 radio Ubiquiti rocket M5 (ROCKETM5) es https://www.interprojekt.it/ubiquiti/RocketM5 costo unitario € 66
• N. 1 AP Mikrotik hAP ac (RB962U) es. https://www.ip-sa.com.pl/mikrotik/RB962UiGS-5HacT2HnT € 80
• N. 1 controllore raspberry PI 4 es https://www.amazon.it/Raspberry-Pi-Computer-8GB-RAM/dp/B0899VXM8F € 73
• Kit di connessione satellitare SKYDSL2+ costituito da Antenna parabolica con illuminatore RTX, supporto per l’installazione e con dispositivo di accesso internet di fornitura skyDSL in leasing

 

Costo totale materiali per la costruzione del nodo: circa 340 € + IVA + costi mensili leasing kit sat e costi running per il contratto di connettività sat .

 

Supporto servizi VoIP in ambiente SARIMESH

Con il termine “servizi VoIP” intendiamo un unsieme di servizi che tipicamente vengono implementato con una stessa piattaforma HW/SW e che fornisce in modalità client/server una serie di diversi servizi come di seguito elencati:

• servizio di comunicazione vocale tipo la classica connessione telefonica
• servizio di videochiamata
• servizio di audio/video conferenza con una molteplicità di partecipanti
• servizio di instant messaging
• servizi di presenza
• interconnessione con le reti pubbliche relative agli stessi servizi

 

Tutti questi servizi richiedono la presenza attiva di un “server” che svolge sostanzialmente funzioni di mediazione nelle fasi di call-setup consentendo di fornire ai due o più partner di una conversazione gli esatti indirizzi di rete per potersi collegare e facendo da tramite per la coordinazione e l’adattamento del tipo di protocolli media ( codec) da utilizzare per la connessione…

Un punto essenziale è il tipo di terminale utilizzabile per lo svolgimento del servizio: l’approccio che riteniamo più appropriato ad un contesto emergenziale è quello di propendere decisamente per terminali mobili di tipo smart-phone in quanto è ben difficile immaginare che in un ambiente emergenziale sia pensabile di usare terminali fissi tradizionali.  Questa scelta consente di generalizzare e semplificare il problema del terminale riducendolo ad un problema di opportune “apps” da attivare su un generico smartphone o computer.

Questa assunzione consente di semplificare notevolmente il tema della interazione con gli ambiti pubblico e di rete mesh, potendo semplicemente assumere di usare apps diverse per i due tipi di interazioni: questo consente di lasciare del tutto inalterate le modalità di connessione con la rete pubblica da parte dei terminali dei soccorritori, semplicemente sfruttando il livello di connettività TCP/IP offerto dalla rete mesh e la connettività internet qualora disponibile verso la rete internet, ed una diversa app ( o anche la stessa app con un diverso server ) per la connettività intra-mesh in caso di indisponibilità della connessione internet.

Sulla scorta della decisione di cui al punto precedente appare possibile scegliere una soluzione di server VoIP ( ovvero di soft-switch ) che sia sufficientemente flessibile e semplice da implementare e gestire e che soprattutto consenta di implementare una configurazione di tipo “HA  cioe ad alta disponibilità”  che sfruttando una molteplicità di servers equipaggiati sulla rete mesh, consenta di evitare il singolo punto di rottura classico delle applicazioni client-server e che sarebbe un grosso vulnus in una situazione di emergenza.

La soluzione VoIP scelta si basa sull’utilizzo del SW soft-switch denominato “flexisip” e della app denominata “linphone”; trattasi di applicazioni opensource e quindi prive di costi di qualunque sorta, previsti per l’utilizzo su diverse piattaforme , preferibilmente di tipo linux per la parte flexisip,  e con apps disponibile per tutte le più diffuse piattaforme di smatphone ( IoS, Android, windows, PC, MAC).

La soluzione soft-switch flexisip è dotata di significative funzionalità e consente di implementare soluzioni multiserver con possibilità di sincronizzazione e operation sia in modalità active-active che active-standby.

La figura seguente fornisce un quadro di unione della soluzione linphone/flexisip

La figura seguente invece riporta un descrizione visuale dei meccanismi di alta disponibilità insiti nel soft-switch flexisip

La figura seguente rappresenta la app presente in ambiente Android Store:

La app linphone può essere utilizzata con una molteplicità di server voip sia di tipo “privato” che di tipo rete pubblica, per cui con una unica app sarà possibile comunicare sia in ambito mesh , anche in condizioni di isolamento da internet, che in ambito di rete pubblica, appoggiandosi ad un proprio VoIP service providers ( es. Eutelia, Mesagenet, o altri).

 

Servizi di videostreamig

Sono dei servizi che sfruttano la connettività TCP/IP per consolidare tramite degli opportuni server un insieme di sorgenti audio/video per scopi di video sorveglianza o di monitoraggio. Per loro natura non richiedono particolari requisiti a livello di rete per cui esiste una ampia possibilità di scelta per i SW relativi da utilizzare.

La rete SARIMESH nella sua implementazione di default fornisce la possibilità di integrare in una rete mesh dei server ad hoc per queste funzioni, che tipicamente saranno caratterizzati dall’avere una memoria di massa di dimensione sufficiente per le esigenze dei casi specifici.

 

Supporto di sensoristica ambientale

E’ un tema abbastanza particolare che va diffondendosi negli ultimi tempi con l’affermarsi delle tecnologie di tipo IoT ( Internet of Things).

La rete SARIMESh sta attualmente sperimentando l’integrazione nella rete, della tecnologia LoRa per la realizzazione di una rete di raccolta dati da sensori remoti sfruttando un protocollo radio ( LoRa appunto) che consente di realizzare sensori a bassissimo consumo e costo, dispiegabili quindi per varie finalità in una certa zona per acquisire opportuni dati di tipo anbientali o di presenza.

Un uso iniziale della tecnologia LoRa in ambito MESH è quello di essere utilizzata per la geo-localizzazione di entità mobili quali ad es. mezzi o operatori in un ambito territoriale anche molto esteso grazie alle caratteristiche di copertura radio particolarmente favorevoli che la tecnologia consente.

Il sistema utilizzato allo scopo è denominato LoRa/APRS e consente di veicolare i dati di posizionamento su uno o più portali di sintesi delle posizoni, ovvero a delle app presenti su smartphone in grado di riportare le posizioni geolocalizzate dei target di interesse.