Supporto alla comunicazione di gruppo context aware per membri disconnessi.

Bruno Docimo, Andrea Toppan, Giannicola Spezzigu

1. Introduzione

La crescente disponibilità di dispositivi portabili che possono fruire di connettività wireless unita alla emergenza degli ambienti MANET apre un nuovo scenario in cui gli utenti richiedono di beneficiare di servizi collaborativi in ogni momento ed ovunque essi si trovino. Scenari di emergency response, condivisione di file, coordinamento fra veicoli sono esempi di applicazioni abilitate dalle nuove tecnologie. A dispetto della eterogeneità dei domini applicativi tutti gli scenari introdotti richiedono servizi di gestione di gruppo e di comunicazione di gruppo al fine di abilitare la collaborazione fra le entità interagenti. AGAPE è un middleware per la gestione dei gruppi e per la comunicazione di gruppo in scenari MANET che promuove e supporta la collaborazione fra utenti dotati di terminali eterogenei e tipicamente limitati nella capacità computazionale. Il middleware AGAPE assume di lavorare in reti costituite da diverse decine di nodi in cui gli utenti si muovono come preferiscono entrando/uscendo da diverse località di rete ed interagendo in modo opportunistico con i partner disponibili per la collaborazione. Il modello di gestione dei gruppi AGAPE consente agli utenti di creare, unirsi o lasciare gruppi composti da utenti che condividono comuni interessi, attività ed obiettivi. In particolare AGAPE fornisce ad ogni membro dei gruppi la visibilità a livello applicativo della lista dei membri colocati insieme ai loro attributi e caratteristiche (context-dependent view). L’insieme dei membri di un gruppo di AGAPE non è noto a priori ma varia dinamicamente a causa della mobilità degli utenti e dell’ingresso/uscita dal gruppo di membri. Si noti che quando un membro esce dal gruppo o si disconnette da una località di rete, AGAPE fornisce ai restanti membri co-locati l’update della context-dependent view. Inoltre, quando un membro si muove da una località di rete ad un’altra AGAPE fornisce al membro l’attuale context-dependent view della nuova località. Il modello di comunicazione di AGAPE consente di individuare i partner per la collaborazione sulla base dei loro attributi/caratteristiche piuttosto che sulla base del nome. Questo è particolarmente importante in uno scenario in cui non è possibile effettuare assunzioni a priori su identità, caratteristiche e capacità dei terminali dei membri del gruppo. Inoltre il modello di comunicazione di AGAPE consente di pianificare l’ordine di presentazione dei messaggi e di adattarne il formato sulla base delle caratteristiche dei dispositivi di accesso e delle preferenze utente.

2. Strato di supporto ad Agape per la comunicazione interlocalità

Allo stato attuale il middleware AGAPE fornisce un supporto message-oriented alla comunicazione di gruppo che richiede la simultanea presenza on-line dei partner della collaborazione. Questo approccio ben si adatta a supportare domini applicativi in cui i partner della collaborazione tendono ad apparire/sparire in modo arbitrario e ad istanti di tempo non predicibili. Tuttavia esistono scenari in cui possiamo assumere che un utente che si è disconnesso sia comunque raggiungibile in un tempo futuro. Questo è verificato in contesti in cui gli utenti tendono a collaborare in spazi limitati, come ad esempio gli studenti in una facoltà oppure operai e macchine all’interno di un’azienda. L’obiettivo di questo lavoro è quello di estendere il modello di comunicazione di AGAPE al fine di supportare la comunicazione verso utenti disconnessi. In particolare viene trattata la disconnessione tra utenti appartenenti allo stesso gruppo che si trovano in località costituenti Manet diverse e quindi fisicamente isolate. Tale comunicazione interlocalità avviene sfruttando il movimento dei vari utenti che vengono visti come potenziali veicoli per il trasporto di messaggi tra le varie aree.

Il supporto alla gestione della disconnessione supporta due distinte modalità di consegna:

• Modalità context-aware: la consegna dei messaggi verso membri del gruppo che si sono disconnessi è delegata a membri che tendono a frequentare le stesse località del destinatario del messaggio. Si noti che il membro delegato alla consegna del messaggio può a sua volta delegare altri membri del gruppo qualora sia necessario.

• Modalità re-connect: i messaggi verso membri del gruppo che si sono disconnessi vengono mantenuti all’interno della località e consegnati non appena si riconnettono.

E’ stato perciò realizzato uno strato di supporto che implementa tali funzionalità. Costruito direttamente sopra il middleware, offre quindi in modo trasparente al livello applicativo l’infrastruttura e le strategie di routing per gestire questa tipologia di disconnessione tra utenti. Alla base del nostro layer c’è l’idea di creare per ogni utente un profilo dei suoi spostamenti, in modo da poter predire con una certa probabilità la sua destinazione futura. Ciò prevede che la posizione relativa delle località non cambi, infatti un utente, nel muoversi tra due località effettua un percorso che difficilmente è sempre diverso, ed è probabile che lasciando una località ne attraversi una vicina prima di raggiungere la destinazione. Perciò analizzando la storia pregressa, ed in particolare la probabile destinazione futura di un utente partendo dalla località attuale siamo in grado di scegliere se utilizzarlo o meno come corriere per consegnare il messaggio. Ogni località, come nella classica implementazione di AGAPE, è gestita da un LME, che si preoccupa anche di gestire la comunicazione interlocalità. Tale gestore sulla base di una propria politica sceglie di consegnare il messaggio ad uno degli ME presenti nella località ipotizzando che si muova verso la destinazione.

L’ME scelto diventa un corriere e quando si disconnette per riconnettersi in un’altra località consegna il messaggio ricevuto al nuovo gestore. Quest’ultimo nel caso la previsione non sia stata corretta si occuperà di ridirigerlo verso la direzione corretta. Questo sistema consente di gestire la comunicazione verso utenti temporaneamente disconnessi, conoscendone la futura locazione di riconnessione. Si suppone un certo flusso di utenti fra una località ed un’altra che garantisca un’ alta probabilità di consegna dei messaggi. Affinché il sistema di previsione degli spostamenti non commetta errori è previsto un transitorio di training nel quale la consegna di messaggi seguirà dei cammini non ottimali. Quindi in pratica mentre si sa a priori la locazione di un determinato utente destinatario di un messaggio, ricavandola dal profilo o da informazioni che già si possiedono, si fa invece una previsione su quella che sarà la futura destinazione dell’utente candidato alla consegna del messaggio indirizzato al primo utente.

3. Architettura Si è scelto di estendere AGAPE in modo da poter offrire il servizio ad applicazioni differenti. Lo strato di comunicazione è formato dai seguenti componenti: Context Manager (CM), Interlocality Routing Service (IRS), Message Repository (MR).

Figura 1 Architettura

Context Manager (CM) E’ il componente che determina la politica di consegna dei messaggi interlocalità. Si occupa di fornire una decisione all’IRS, sulla base di informazioni che raccoglie durante il funzionamento del sistema che vengono depositate in un History Register. In tale registro vengono annotate le ultime transizioni tra località che un utente ha compiuto in modo da poter individuare una certa familiarità nell’effettuare un determinato percorso. Quando il CM è invocato dall’IRS tramite la funzione makeDecision() vengono calcolate

utilizzando le informazioni dei singoli HR, le probabilità che i vari utenti presenti si possano muovere verso la destinazione target di un determinato messaggio; quando tali probabilità superano una certa soglia il CM inserisce in un vettore il loro identificativo in modo che l’IRS li possa delegare alla consegna del messaggio. Interlocation Routing Service (IRS) E’ il servizio che si occupa del routing vero e proprio, grazie alle predizione comunicatagli di volta in volta dal CM effettua la memorizzazione del messaggio nel MR oppure la sua consegna agli utenti corrieri (forwarding). Questo Servizio, attivo solamente negli LME coordinatori di località, viene invocato dai membri del gruppo ogni qualvolta vi sia la necessità di comunicare nei modi precedentemente descritti. Si interfaccia direttamente al NMS e al MR per il delivery dei messaggi. Ad intervalli regolari controlla il V.M.S. per rilevare la presenza di nuovi utenti, in modo da poter riprocessare eventuali messaggi presenti nel MR. Ad ogni messaggio è associato un header, che contiene informazioni sul destinatario e il timestamp che consente di limitare la crescita incontrollata della coda, eliminando i messaggi più vecchi e non ancora consegnati. Message Repository (MR) E’ un componente passivo che offre i servizi di memorizzazione dei messaggi all’IRS. Vengono memorizzati i messaggi che non sono ancora stati mandati in consegna, ossia quelli per i quali il CM non ha trovato un possibile utente mobile che possa veicolarli verso la giusta destinazione. Verranno poi estratti al sopraggiungere all’interno della località di un utente idoneo alla consegna.

Figura 2 Classi dello strato di supporto

4. Caso di studio 4.1 Scenario applicativo Dopo aver spiegato e ragionato su tutte le parti costituenti la nostra infrastruttura di comunicazione, si passa ora a descrivere la realizzazione di un primo prototipo della stessa e di una piccola applicazione grafica che ne fa uso. La ricerca e il soccorso delle vittime di gravi disastri non costituisce solo un grave problema sociale, ma rappresenta anche una sfida difficile dal punto di vista scientifico. Al fine di mostrare l’utilizzo dell’estensione di Agape per il supporto alla disconnessione è stata realizzata un’applicazione che utilizzando tali servizi assista gli operatori in uno scenario di disastro ambientale. Tali disastri possono essere provocati sia da fenomeni naturali quali terremoti, eruzioni vulcaniche, inondazioni ecc, sia causati dall’uomo quali attacchi militari o esplosioni radioattive. La costante di questi scenari è il totale o parziale danneggiamento di ogni tipo di infrastruttura per la trasmissione dati, sia mobile che fissa, nonché una grave situazione di disagio per la popolazione coinvolta ed una forte esigenza di coordinamento da parte delle entità preposte allo svolgimento delle operazioni di primo soccorso, come protezione civile, vigili del fuoco, ambulanze e forze dell’ordine. Si profila quindi un contesto di emergenza nel quale non essendoci possibilità di comunicare tra località diverse, ogni possibile mezzo di scambio di informazione potrebbe essere di aiuto; come la segnalazioni di particolari critici o la distribuzione di liste per il ritrovamento di vittime e familiari. Topologia:

Figura 3 Topologia Emergency response

Ipotizziamo che nel luogo del disastro siano sopraggiunte diverse squadre di soccorso che prestano la loro opera in località diverse. Alcuni operatori si occuperanno del ritrovamento dei superstiti di trasportarli nei vari centri di accoglienza. Grazie all’utilizzo

di Agape verrà formato un gruppo sia nelle aree colpite dal disastro dove operano le squadre di soccorso, sia nei vari centri di accoglienza. Si vengono perciò a formare diverse reti ad hoc disconnesse tra loro, che vengono periodicamente attraversate dalle squadre che si muovono dai centri alle zone calde. Le varie informazioni raccolte nelle varie località devono essere in ogni caso portate in un centro di coordinamento denominato sala crisi, nella quale tutto viene raccolto e analizzato per fornire una visione di insieme del disastro. 4.2 Survivors Communication Assistant (SCA) In questo contesto si inserisce la nostra applicazione SCA. L’obiettivo è quello di creare una lista, il più possibile aggiornata e gestita dalla sala crisi, dei nominativi delle persone che sono state messe in salvo nei vari centri. Grazie a queste liste ogni superstite può richiedere nel proprio centro di accoglienza informazioni relative ai propri familiari. L’idea di base è quella che in ogni centro di accoglienza venga compilata una lista dei superstiti che man mano vengono portati in salvo. Queste liste vengono inviate dai vari centri alla sala crisi grazie all’utilizzo del nostro strato di supporto alla comunicazione per membri disconnessi. Qui viene fatto il merge e gestita la memorizzazione. Da tale centro viene inoltre predisposta la diffusione della lista globale così ottenuta verso i vari centri di accoglienza, in modo che possa essere consultata. Data la natura probabilistica del sistema di routing sottostante, è comunque prevista una fase di sincronizzazione manuale delle informazioni sensibili, non appena se ne ha la possibilità. Le funzionalità offerte da SCA possono essere sintetizzate quindi come segue:

- gestione lista locale al centro di accoglienza e invio alla sala crisi - merging delle varie liste giunte alla sala crisi e invio a tutti i centri.

Figura 4 Casi d'uso

Come risulta dalla figura 4, l’operatore ha la possibilità di aggiungere un superstite alla lista locale dei sopravissuti. Questo comporta anche l’aggiornamento della lista globale. Viene inoltre fornita la possibilità di visualizzare entrambe le liste. L’applicazione grazie ai livelli sottostanti si occupa della diffusione delle liste locali dai centri di accoglienza alla sala di crisi e della lista locale dalla sala di crisi ai centri. Il concetto fondamentale che si trova dietro all’idea di coordinamento è quello di una lista condivisa e sincronizzata. Ovviamente il principio di sincronismo non è citato nel modo classico, ma inteso di tipo più lasco, nel quale non sempre è tutto perfettamente consistente. 4.3 Struttura dell’applicazione L’applicazione è divisa in due parti, il Server centrale, che si troverà nel centro di crisi e una serie di Client, uno per ogni località in cui vengono ricevuti i superstiti. Entrambe le parti sono modellate sulla struttura di un ME. Questa scelta è stata effettuata per separare la logica di Controllo di una località, da quella di gestione dell’infrastruttura SCA, affinché sia possibile un rapido spostamento del centro di crisi senza dover riconfigurare l’intero sistema. Entrambe le versioni concretizzano la struttura qui esposta.

SCAPresentation

Input Command Output Command

Services

Supporto alla disconnessione

AGAPE

Entities

Figura 5 Schema generale dell'architettura di SCA

L’architettura dell’applicazione è stata pensata per renderla il più possibile flessibile e riutilizzabile. In quest’ottica è stato realizzato un insieme di servizi indipendenti che astraggono ulteriormente il middleware realizzando le funzionalità fondamentali dell’applicazione. Le azioni che l’utente esegue su tale layer, nonchè le azioni che il layer esegue verso “l’esterno”, sono modellate come un insieme di comandi che separano completamente la logica dell’applicazione dalla sua presentazione. Di seguito analizzeremo nel dettaglio i livelli che costituiscono l’applicazione. Presentation layer Il layer di presentazione gestisce tutte le interazioni con l’utente. Abbiamo deciso di realizzare l’interfaccia utente con una semplice GUI, in cui sono presenti diversi pulsanti che realizzano le funzionalità specificate dai casi d’uso: inserisci superstite, visualizza lista locale e visualizza lista globale, come si può vedere negli screenshot di figura 6. Quando viene premuto inserisci viene visualizzato un apposito modulo per l’inserimento dei dati del nuovo superstite. La visualizzazione delle liste avviene sotto forma di tabella dove sono riportati per ogni persona nome, cognome e identificatore della località del loro centro di accoglienza. L’interfaccia Server differisce da quella Client per la mancanza della funzionalità di visualizzazione della lista locale, in quanto non sono previste liste locali per la sala crisi.

Figura 6 Screenshot interfaccia grafica

Entities layer Questo layer contiene le entità fondamentali, in particolare i due tipi di liste e i loro singoli elementi. L’elemento base della gerarchia è Survivor, che è una classe che contiene tutti i dati del superstite e i metodi per la loro gestione. Abbiamo poi la ScaList che estende ArrayList, i cui elementi sono appunto Survivor. Infine c’è la GlobalList che estende anche essa ArrayList ed è una lista di ScaList. Ogni lista possiede un identificativo di località, grazie al quale da ogni posizione sarà possibile ritrovare un superstite, e riunire conoscenti nella stessa località. Tutte le classi sono serializzabili sia per consentire la scrittura locale degli oggetti, e quindi garantirne la persistenza, che per poterne effettuare l’invio remoto. Servizi I servizi vanno a formare la parte dell’applicazione che si interfaccia con AGAPE per usufruire delle primitive di comunicazione e dell’astrazione del concetto di gruppo. Infatti l’interfacciamento con i livelli sottostanti è svolto dal ListManagerInterface che è un’ interfaccia che rende trasparenti i servizi di comunicazione e memorizzazione. Essa fa in modo che l’applicazione sia indipendente da Agape e possa quindi essere riutilizzata con diverse infrastrutture di rete semplicemente fornendo una diversa implementazione al ListManager che appunto realizza i vari servizi di rete interfacciandosi col middleware. Inoltre poiché essa si occupa anche delle entità e della loro memorizzazione, rende l’applicazione indipendente dal tipo di sistema informativo per la gestione dei dati. La diversa implementazione di ListManagerInterface consente di differenziare il Server dal Client, in particolare il Client ad ogni modifica delle entità, sfruttando agape e il nostro Routing Layer, invierà un messaggio di UPDATE al server. Una volta ricevuto l’UPDATE il server aggiornerà la lista globale e ad intervalli regolari invierà la lista a tutti i Client. La versione del ListManager per il Client utilizza servizi aggiuntivi per poter sfruttare agape: si interfaccia con un MessageListener al livello IRS in modo da poter ricevere gli UPDATE della lista globale, e per utilizzare i servizi di invio messaggi. La versione del ListManager per il Server è simile a quella utilizzata dal client, con l’aggiunta di funzioni per la memorizzazione della lista globale e della sua sincronizzazione, nonché del supporto per l’invio periodico dei messaggi di UPDATE. Comandi Il layer dei comandi ha il compito di separare la logica dell’applicazione dalla sua interfaccia utente. • input command: comandi che l’interfaccia utente utilizza per scatenare delle azioni nei layer sottostanti (ad esempio: quando un operatore effettua l’inserimento di un nuovo superstite l’interfaccia utente consegna la richiesta al ListManagerI,che richiama i servizi sottostanti per inviare effettivamente la lista modificata);

• output command: comandi che i servizi utilizzano per consegnare delle informazioni all’utente (ad esempio, quando viene ricevuta una nuova lista globale, e l’utente, tramite l’opportuno comando, la vuole scandire e visualizzare a video). 5. Conclusioni Sca è stata implementata utilizzando la tecnologia Java Standard Edition e quindi portabile su qualsiasi piattaforma con hardware di tipo laptop. Risulta però agile la migrazione verso dispositivi portatili come i PDA utilizzando la Java Mobile Edition. Inoltre, come descritto le funzionalità implementate sono esigue poiché lo scopo della realizzazione di tale applicazione è stato quello dell’utilizzo di Agape e del trattamento delle problematiche di rete relative alla disconnessione di cui si è parlato. Tuttavia la lungimiranza con la quale è stata progettata Sca ha portato ad una modularità e indipendenza tra i componenti che lascia pensare a interessanti sviluppi futuri. Eccone alcuni esempi: la gestione delle liste tramite database e quindi la possibilità di effettuare interrogazioni da remoto di diverse tipologie; l’integrazione con di elementi multimediali quali foto e video; scambi di altri tipi di dati specifici di una determinata situazione critica o comunque utili in base allo specifico dominio applicativo. Con gli esigui mezzi avuti a disposizione si è verificato che l’applicazione ben si interfaccia la nostro layer di supporto alla disconnessione e quindi ad Agape stesso. Purtroppo non si può tuttavia garantire che in condizioni critiche di traffico tutti i messaggi vengano consegnati, essendo come più volte ricordato in un sistema di tipo best effort.