relazione

Supporto al routing inter-MANET in ambiente impromptu
basato su AGAPE
- Giacomo Tartari –
1. Scenario applicativo
1.1 Reti ad hoc
La grande diffusione delle reti radiomobili cellulari per fornire connettività a livello geografico e
la crescente diffusione delle reti basate sullo standard Wi-Fi per fornire connettività a livello
locale stanno rendendo sempre più indispensabile, e in qualche modo scontata, la percezione
degli utenti di poter essere sempre collegati a sorgenti di informazioni, o a servizi disponibili
all'interno di uffici o di aree pubbliche. Le infrastrutture di comunicazione usate per questi
scopi si fondano su uno schema gerarchico, in cui sono presenti punti d'accesso centralizzati
che fanno da “collettore” per l'accesso degli utenti. La comunità scientifica sta però studiando
soluzioni che vadano oltre la necessità di una infrastruttura fissa e predeterminata: si tratta
delle cosiddette reti ad hoc, e in particolare delle reti mobili ad hoc (MANET - Mobile Ad hoc
NETworks). Una rete ad-hoc mobile (Mobile Ad-hoc NETwork) è definita come un sistema
autonomo di router (detti anche nodi) mobili connessi mediante collegamenti wireless. Tutti i
nodi del sistema collaborano al fine di instradare i pacchetti nel modo corretto. A causa della
mobilità impredicibile dei nodi, la topologia di rete può cambiare costantemente. Le reti AdHoc vengono costruite all'occorrenza ed utilizzate in ambienti estremamente dinamici, non
necessariamente con l'aiuto di una infrastuttura già esistente.
Questo modo destrutturato di interconnettere sistemi può permettere di utilizzare servizi
distribuiti anche quando le infrastrutture fisse siano danneggiate (pensiamo ad applicazioni
per la protezione civile), inaccessibili, sovraccariche, inesistenti (in questo caso, potrebbero
essere interessanti ambiti applicativi quali il monitoraggio del territorio o la classificazione di
beni culturali) o semplicemente costose. Le reti ad hoc hanno una loro naturale applicazione
in contesti di comunicazione “spontanea”, quando gruppi di persone, dotate di terminali come
PC portatili, PDA, smartphone, si trovano fisicamente nello stesso luogo e hanno l'esigenza di
comunicare tra loro, senza doversi necessariamente appoggiare su un'infrastruttura di rete
esistente fornita da terzi.
Lo scenario si complica nel caso in cui la comunicazione debba avvenire tra le diverse
MANET o nel caso in cui una MANET venga scissa in più parti, generando cosi altre reti
(context awareness).
Un problema tuttora in discussione è infatti quello del routing di messaggi tra MANET
separate non essendoci la possibilità di collegare fisicamente gli endpoint. Per esempio in un
ambito metropolitano e in assenza di infrastrutture fisse di accesso alla Rete che
permetterebbero la comunicazione.
A questi problemi si aggiunge la possibilità di una non contemporanea connessione degli
utenti che desiderano comunicare data da possibili interferenze o da disconnessione
volontaria degli stessi, queste disconnessioni possono essere di breve durata (qualche
minuto) o prolungate (giorni o settimane). In entrambi i casi è auspicabile che l’utente alla
riconnessione possa ricevere i messaggi pendenti.
In questo scenario si inserisce il nostro progetto il quale si prefigge come obbiettivo il routing
dei messaggi tra MANET separate sfruttando la mobilità e le abitudini degli utenti, e la
gestione delle disconnessioni degli stessi.
2. Modello
Le persone frequentano abitualmente diversi punti di aggregazione (quali bar, palestre,
università...) e spesso ad orari e giorni fissi per diverse settimane (lezioni universitarie,
abbonamenti in palestra,...).
Nell’ipotesi di una diffusione capillare di dispositivi portatili dotati di connessioni senza fili, in
questi luoghi di aggregazione è possibile e auspicabile che si possano formare delle MANET.
In questo scenario si deve inserire un middleware il quale fornirà il supporto alle funzionalità
di base per la realizzazione di applicativi operanti in tali reti.
Tenendo traccia delle abitudini degli utenti è possibile costruire un modello predittivo in grado
di localizzare con una certa approssimazione gli utenti in modo tale da collegare le diverse
MANET sfruttando la mobilità degli utenti stessi.
C’è la necessità quindi di individuare utenti con una particolare mobilità attraverso le diverse
reti, che facciano da canale di comunicazione mobile e da supporto alla memorizzazione
favorendo la persistenza dei dati.
Sfruttando questo modello è possibile progettare un protocollo di routing basato sugli
spostamenti e sulle presenze contemporanee degli utenti nelle MANET.
Con questo protocollo è quindi possibile risolvere sia il problema della comunicazione tra
MANET sconnesse, in quanto utenti che frequentano reti diverse possono scambiarsi
messaggi trasportati da altri utenti che frequentano entrambe, sia il problema delle
disconnessioni degli utenti, potendo i messaggi diretti a utenti offline essere recapitati in
differita in altre località.
Per rendere l’idea si può pensare a e ad un sistema di flotte in movimento (Figura 1.
Le flotte rappresentano le singole MANET e le navi rappresentano gli utenti che vogliono
comunicare.
All’interno della stessa flotta le navi posso comunicare tra loro ma le comunicazioni tra flotte
devono avvalersi della mobilità delle singole navi che si spostano tra una flotta e l’altra.
Figura 1.
Ipotizziamo che l’utente A voglia comunicare con l’utente B e che i due utenti si trovino in
flotte diverse (Figura 2.).
Figura 2.
Al momento dell’invio verrà eletto un utente C che fungerà da corriere con il compito di
trasportare il messaggio alla destinazione (Figura 3).
Figura 3.
L’utente C una vota arrivato nella nuova MANET recapitera il messaggio all’utente B (Figura
4).
Figura 4.
Utilizzando quindi questo nuovo paradigma di comunicazione è possibile creare un canale di
comunicazione dinamico che connette diverse reti, inoltre il messaggio può essere trasferito
da corriere a corriere, in una sorta di passa-mano, inseguendo letteralmente il destinatario di
MANET in MANET.
3. Soluzione del problema e prima progettazione
3.1
Scelta del middleware: AGAPE
Le problematiche derivanti dalla dinamicità del contesto di una MANET sono numerose e
complesse. Basti citare il problema del routing in reti di questo tipo, nelle quali spesso
avvengono partizioni, connessioni e disconnessioni dei nodi. Per poter lavorare ad un livello
più elevato risulta molto utile l’utilizzo di un middleware che fornisca una serie di funzionalità
sulle quali ci si possa appoggiare per la realizzazione dei propri obiettivi. Sono disponibili
numerosi sistemi che lavorano su reti ad hoc, ciascuno dei quali è caratterizzato da alcune
caratteristice peculiari. È responsabilità del progettista scegliere quello più adatto e che
meglio corrisponda ai propri bisogni. Tra le varie opportunità disponibili la nostra scelta è
caduta su AGAPE (Allocation and Group Aware Pervasive Environment), un sistema
sviluppato presso il DEIS, che sebbene non sia ancora in versione definitiva fornisce un
insieme di servizi fondamentali necessari per lo sviluppo di applicazioni in ambienti MANET.
AGAPE è infatti un middleware nato per supportare lo sviluppo di applicazioni
collaborative in ambienti MANET. La collaborazione in AGAPE è basata sulla metafora del
gruppo; ogni gruppo è rappresentato mediate un Group Identifier (GID) e un profilo che ne
specifica interessi e obiettivi che si assume siano condivisi dagli utenti che ne fanno parte. I
membri di un gruppo sono caratterizzati da un Personal Identifier (PID) e da un profilo che
rappresenta le caratteristiche dell’utente e del dispositivo che esso utilizza. I membri che
faranno parte del gruppo non possono essere determinati a priori in quanto essi posso unirsi
o lasciare il gruppo dinamicamente in base alle esigenze specifiche dell’applicazione. La
mobilità degli utenti potrebbe creare partizioni e fusioni dei gruppi stessi e della rete, che
causano fasi transitorie nella collaborazione fra utenti nuovi e precedentemente sconosciuti.
Un’altra caratteristica molto importante e cruciale è che il middleware permette ad ogni
utente di poter consultare una vista dei membri co-locati, cioè una sorta di tabella riassuntiva
di coloro che sono nella sua prossimità, che viene inviata a tutti i coloro che sono stati
riconosciuti come membri della rete con attiva una istanza di AGAPE. Il processo di creazione
e distribuzione delle liste è gestita da entità centrali definite come LME (Località Manager
Entity), che consistono semplicemente in nodi della rete ad hoc con capacità computazionali
maggiori che, oltre a collaborare, metto a disposizione servizi per il supporto alle operazioni
necessarie per la gestione del gruppo stesso. Gli ME, Managed Entity, rappresentano invece
quei membri del gruppo che utilizzano i servizi messi a disposizione dal supporto per
collaborare.
Quindi utilizzando questo middleware abbiamo già a disposizione uno strumento per la
creazione e la gestione di gruppi a cui tutti coloro che appartengono alla MANET possono
effettuare operazioni di join/leave. Inoltre essendo gli LME nodi con capacità computazionali
maggiori, questi sembrano particolarmente adatti a ricoprire il ruolo di gestore della MANET.
Per quanto riguarda poi la comunicazione AGAPE, oltre a risolvere il problema del
routing in reti ad elevata dinamicità, mette a disposizione delle entità differenti pattern di
comunicazione tra cui quello context-based any-cast. Tale pattern permette la comunicazione
asincrona inaffidabile point-to-point tra due utenti: quando un membro del gruppo ha bisogno
di comunicare, uno e un solo membro della località viene selezionato in base al profilo di
ricerca richiesto.
3.2 MSA
In questo modello di interazione si inserisce quindi un servizio di messaggistica che consenta
la comunicazione tra utenti disconnessi.
L’idea principale su cui si basa l’applicativo è quella di utilizzare particolari utenti, scelti in
base alla disponibilità di memoria o mobilità, che si occupino di trasportare, come corrieri, i
messaggi tra le varie località.
Utilizzando i protocolli di comunicazione di AGAPE possiamo creare, grazie alle entità LME,
delle piccole reti ad-hoc. Si è deciso, per facilitare la localizzazione degli utenti, di utilizzare
un’AGENDA personale in cui registrare informazioni relative all’accesso alla località ogni volta
che un ME entri in una certa località. In questo modo possiamo sapere nell’arco di una
giornata o di una settimana (a seconda della necessità) quali località abbia visitato un utente.
Risolto il primo problema di tracciamento degli utenti veniamo ora alla scelta del
destinatario del messaggio. Tenendo conto degli utenti precedentemente incontrati, verrà
creata una lista (Buddylist) di contatti contenente, oltre ai relativi profili, anche le rispettive
agende.
Dovendo instradare i messaggi attraverso il middleware AGAPE si è reso necessario
implementare un servizio adeguato che si occupi di invio, ricezione e gestione dei messaggi
da e verso AGAPE.
Ogni messaggio sarà corredato di informazioni racchiuse in un header il quale conterrà
oltre alla data di invio i profili e le agende dei due interlocutori.
La presenza delle agende nell’header del messaggio è fondamentale : l’agenda del
destinatario, contenendo le informazioni utili per rintracciarlo nelle varie località, servirà per
l’instradamento del messaggio, mentre quella del mittente sarà utile per avere dati aggiornati
e quindi per una maggiore probabilità che un eventuale messaggio di risposta arrivi a
destinazione.
L’ultimo problema che ci troviamo ad affrontare è quello dell’instradamento dei
messaggi creati precedentemente. In questo ci aiuta l’algoritmo NHC (Next Hop Choice) che
si occupa del routing e della ricerca del miglior corriere a cui recapitare il messaggio. L’idea di
base di questo algoritmo è quella di cercare il match migliore tra l’agenda del destinatario e
l’agenda dei corrieri disponibili che si trovano nella località del mittente al momento dell’invio.
Basandosi quindi sulla localizzazione e sull’orario di invio è possibile trovare i corrieri con la
più alta probabilità di incontrare il destinatario del messaggio o di trovarsi nella stessa località
prima dell’ arrivo del destinatario e poter consegnare il messaggio all’LME che, in un secondo
momento, si occuperà di recapitarlo non appena il ricevente entra nella località. Con questo
particolare algoritmo è inoltre possibile ‘inseguire’ il destinatario tramite il passaggio del
messaggio tra corrieri, di volta in volta scelti come più adatti alla consegna dato che
l’ambiente è mobile.
Alla luce di quanto spiegato precedentemente possiamo quindi suddividere in tre categorie gli
utenti che interagiscono nel nostro ambiente:
-utente normale: tiene traccia delle località da lui più frequentate, assieme ad una fascia
oraria in cui è più probabile che si trovi in quella zona(->AGENDA), ed una lista di utenti
(Buddylist) co relative agende.
Possiede le funzionalità di base per l’invio e la ricezione dei messaggi.
-corrieri: oltre alle funzionalità dell’utente normale possiede particolari caratteristiche
hardware che gli permettono di memorizzare i messaggi da consegnare ad altri utenti.
-gestore di località: si occupa di consegnare i messaggi al corriere che ha la più alta
probabilità di incontrare il destinatario e, essendo anch’esso corriere, di memorizzare
temporaneamente in alcuni casi i messaggi in attesa del destinatario.
3.3 Descrizione dell’architettura
Vediamo nella figura com’è strutturate l’applicazione. La parte applicativa (MSA) si occupa di
fornire un interfaccia grafica (GUI) per la comunicazione e gestire l’avvio dei vari servizi.
La parte centrale “services” si occupa della comunicazione con il middleware AGAPE,
fornisce le funzioni per poter interagire col repository e si occupa della creazione dell’invio e
dell’instradamento dei messaggi.
3.4 Servizi
Analizziamo ora più dettagliatamente la struttura dei servizi e la loro interazione:
-Agenda Service(AS) : Si occupa della creazione dell'agenda di un utente.
Ogni volta che un utente passa per una località, l’Agenda Service si occuperà di salvare il
nome della località, la data, il giorno della settimana, e la fascia oraria (esempio:15-16).
Il servizio di agenda si occuperà inoltre dell'aggiornamento delle statistiche relative alla
frequenza di passaggio nelle località.
-Buddy List Service (BLS) : Si occupa del salvataggio dei profili degli utenti a cui si ipotizza di
voler mandare messaggi (all’interno del profilo utente è racchiusa anche l’agenda).
-Repository Service (RS) : Servizio di interfaccia per la memorizzazione dei messaggi.
-Next Hop Choice Service (NHCS) : Si occupa della scelta del percorso di routing dei
messaggi.
Incapsula l’algoritmo NHC per la ricerca del prossimo hop.
-Message Service (MS) : Provvede all'invio/ricezione dei messaggi. In fase di creazione
comunica con il BLS per la creazione del messaggio.
Se in fase di invio l’utente non è presente in località, comunica con l'NHCS per la ricerca del
miglior corriere.
Nella figura seguente vediamo quali sono i servizi creati che si occupano dell’interazione col
middleware AGAPE
4. Messaging
Il Messaging di MSA prevede di poter instradare messaggi tra località di AGAPE diverse
sfruttando la mobilità e le abitudini degli utenti, questa modalità di invio viene sfruttata solo
per utenti non presenti nella stessa località, altrimenti i messaggi vengono semplicemente
inviati attraverso il middleware AGAPE.
Il Message Service è il servizio che si occupa della gestione dei messaggi intesa come la
ricezione e l’invio di messaggi da e verso il middleware AGAPE e della loro interpretazione.
Data la presenza all’interno di MSA di messaggi non solo di contenuti per gli utenti1 ma anche
di protocollo (per coordinazione, routing, e scambio di profili) per garantire semplicità di
gestione ed estendibilità futura il servizio implementa il pattern visitor, risulta quindi semplice
aggiungere nuovi messaggi per scambio di contenuti differenti o nuovi protocolli.
Il MS inoltre comunica con altri servizi di MSA per ottenere la persistenza dei messaggi
pendenti, ottenere profili e destinatari. In particolar modo si occupa di inserire i messaggi nel
1
All’attuale stato del prototipo sono previsti solo messaggi di testo.
repository qualora questi siano da trasportare attraverso diverse località secondo le politiche
di routing precedentemente esplicitate. Non ha invece un ruolo attivo nella scelta dei corrieri,
scelta che è appannaggio del NHCS ed è effettuata con l’algoritmo NHC, al termine della
scelta il MS invia il messaggio al corriere scelto.
Passiamo ora a elencare i messaggi fino ad ora riconosciuti dal MS seguiti da una breve
descrizione.
Message: il messaggio vuoto, contiene solamente mittente e destinatario, con relativi profilo
e agenda, e data di invio. Questo messaggio è la “superclasse” concettuale e reale per gli
altri messaggi.
Non ha un reale utilizzo nell’applicazione.
Agendarequestmessage: questo messaggio viene inviato a qualcuno in località per ottenere
a sua agenda aggiornata, e in caso non sia ancora presente, il suo profilo verrà aggiunto alla
buddylist. Il MS invia questo messaggio su richiesta dell’utente, in ricezione invece il MS crea
un Agendaresponsemessage e lo invia immediatamente al mittente del primo messaggio.
Agendaresponsemessage: con questo messaggio
il MS
risponde
a un
Agendarequestmessage, quando viene ricevuto il MS passa i dati del mittente, profilo e
agenda, al Repository Service per gli eventuali aggiornamenti. Agende aggiornate portano a
maggiori probabilità di successo nelle consegna di messaggi da parte di corrieri.
Courierrequestmessage: con questo messaggio il Next Hop Choice Service richiede la lista
dei corrieri presenti in località all’LME che dispone delle viste di AGAPE più aggiornate e
affidabili. Alla rica
Ezione di questo messaggio segua l’invio del relativo Courierresponsemessage.
Courierresponsemessage: questo messaggio è parte del protocollo di routing context aware
tra località, e contiene la lista dei possibili corrieri presenti nella località stessa. Alla ricezione
questa lista viene estratta e consegnata al Next Hop Choice Service, sua priorità sarà trovare
un corriere adeguato per la consegna del messaggio.
Containermessage: quando un utente invia un messaggio a un altro utente disconnesso il
messaggio viene incapsulato in un Containermessage e consegnato al corriere, in ricezione
quindi il messaggio viene consegnato al Repository Service che provvedera alla persistenza
dello stesso fino al momento della consegna.
Textmessage: il primo messaggio per lo scambio di contenuti tra utenti, in questo caso solo
testo, alla ricezione il MS estrae il testo e lo visualizza nella console.
Allo stato attuale del prototipo solo messaggi di testo sono utilizzabili, ma nelle future versioni
saranno resi disponibili altri tipi di messaggi.
Da questa breve descrizione dei messaggi si evince come i protocolli di MSA prevedono
l’instradamento attraverso diverse località. Perché questo sia possibile è necessario che il
mittente si coordini, in maniera del tutto trasparente all’utente, con i corrieri presenti in località
e che consegni a uno di loro il messaggio da recapitare. Quale corriere sarà eletto per la
consegna del messaggio è deciso dal Next Hop Choice Service.
5. Prototipo
All’avvio l’LME attiva i servizi di AGAPE e i servizi descritti nei capitoli precedenti.
Successivamente viene creato il gruppo a cui gli ME si collegheranno.
Si notano, a lato, le due liste rappresentanti una gli utenti ondine e l’altra gli utenti in buddylist.
Dal canto suo l’ME, dopo aver attivato i servizi ed effettuato il discovery del gruppo in località,
effettuerà una join presso l’LME locale.
Se l’utente che si collega è un corriere, la sua agenda verrà inviata automaticamente all’LME
il quale tiene una lista aggiornata di tutti i corrieri che incontra.
In figura vediamo la ricezione dell’agenda da parte dell’LME:
Nella prossima figura vediamo un esempio di invio e ricezione di messaggi da parte di utenti
che si trovano nella stessa località:
Nel caso in cui un utente debba inviare un messaggio ad un altro ME che non si trova nella
località, verrà attivato il protocollo di routing.
In figura vediamo la richiesta e il successivo invio da parte dell’LME, della lista dei corrieri che
si trovano in località:
Di seguito notiamo, lato ME, il feedback di esecuzione dell’algoritmo NHC.
6. Conclusioni e sviluppi futuri
Per concludere, abbiamo quindi visto come sia possibile effettuare il delivery dei messaggi in
ambienti disconnessi ed impromptu, sfruttando la mobilità e la molteplicità degli utenti per
dare un’astrazione di connessione tra MANET.
Connessione che deve ovviamente tener conto dei limiti del modello: elevati ritardi, non
affidabilità della consegna dei messaggi.
Il prototipo progettato è aperto a implementazioni future nella gestione di diversi tipi di
messaggi, non solamente di testo ma anche messaggi multimediali.