Direct Diffusion L implementazione di un framework e di un applicazione. Marco Sinigaglia Abstract Le reti di prossima generazione saranno composte da piccoli device in grado di comunicare, elaborare e sondare l ambiente esterno. Questi nodi devono instaurare una rete dinamica. I sensori hanno una risorsa energetica limitata, da qui l esigenza di progettare protocolli che ne sfruttino la capacità elaborativa piuttosto che la comunicazione tra di essi. In questo articolo si illustra un protocollo denominato Direct Diffusion: un paradigma datacentric e application-aware. Le comunicazioni si effettuano con dati associati a dei nomi e i nodi partecipano attivamente all instradamento dei dati. Si sfrutta la capacità elaborativa anche per l aggregazione dei dati. In questo articolo se ne discute il funzionamento, si presenta un framework che la implementa e si illustra un applicazione dimostrativa. Introduzione L evoluzione tecnologica ha reso possibile lo sviluppo di micro sistemi hardware economici, a basso consumo di energia e multifunzionali. I sensori ascoltano l ambiente esterno e convertono l accadimento di un evento fisico in un impulso elettrico; l informazione così ottenuta viene elaborata e trasmessa ad altri sensori. L impiego di uno svariato numero di sensori collegati tra di loro costituisce una Wireless Sensor Network (WSN). Gli scenari applicativi sono molteplici, quelli più di rilievo sono i seguenti: monitoraggio climatico di una foresta, la rilevazione di materiale radioattivo in una città, il tracking di oggetti in movimento di animali o persone. Il routing nelle WSNs è alquanto provocatorio a causa delle inerenti caratteristiche che lo accumunano alle altre reti wireless ma che non lo caratterizzano sufficientemente. Dato l elevato numero dei nodi di sensori non è possibile costruire un schema di indirizzamento globale: l overhead di gestione per l ID sarebbe troppo alto. Di conseguenza, i tradizionali protocolli Ip non possono essere applicati per le WSNs. Il know-how delle reti wireless adhoc presenta delle analogie con le reti di sensori, aiuta a capirne lo scenario ma non sono sufficienti a definire il sistema. Molti sono gli algoritmi si routing proposti per per risolvere il problema delle WSNs, gli obbiettivi principali sono: Adattamento. Essendo, in alcuni scenari, la topologia della rete dinamica, i sensori devono definire autonomamente il migliore percorso considerando lo stato, attuale, della rete; efficienza energetica. Ridurre le trasmissioni tra i nodi utilizzando, ad esempio, la capacità elaborativa per aggregare informazioni ridondanti in un unico pacchetto; Scalabilità; Robustezza. Il protocollo analizzato in quest articolo è denominato direct diffusion. Appartiene alla famiglia di protocolli proattivi denominati Sensor Protocol for Information via Negotation (SPIN) che rimediano alle deficienze del classico flooding negoziando e adattano le risorse.
In seguito verrà descritto il paradigma, presentata una implementazione nel framework allegato e illustrata una relativa applicazione su di esso. Direct Diffusion L idea principale del paradigma Direct Diffusion è : Adattarsi; auto organizzarsi senza l intervento umano; limitare il consumo energetico impiegando il collaborative processing. Direct Diffusione implementa una rete proattiva: si traccia un percorso dalla sorgente al destinatario prima della trasmissione del dato. Questa tecnica permette l ottimizzazione dell efficienza energetica utilizzando la capacità elaborarativa di ciascun nodo. Direct Diffusion è una derivazione degli Spin: è data-centric e un paradigma application aware, nel senso che i dati generati dai sensori sono etichettati da un coppia di attributovalore. Di seguito verrà illustrato il funzionamento del protocollo con riferimento allo scenario dell applicazione sviluppata. L utente vuole monitorare il livello di alcuni gas (CO2 e CO) ed essere avvisato se l evento concentrazione dei gas in una determinata regione X supera una soglia Y risulta essere vera mentre è attivo il sistema. Il nodo, incaricato a ricevere il risultato della query, è denominato sink, esso emette, periodicamente, un interesse che descrive il compito assegnatoli dall utente. Figure 1 Diffusione dell Interesse Il sink emette l interesse in broadcasting ed esso si diffonde nella rete con una connessione punto-a-punto (Figure 1). L interesse, propagandosi nella rete, configura uno stato, determinato dal gradiente, in ciascun nodo; il gradiente ha il compito di condurre i dati, che soddisfano l interesse, al sink. Ciascun sensore, che riceve l interesse, alloca un gradiente verso il nodo da cui lo ha ricevuto. Il processo continua finchè i gradienti, dalla sorgente fino al sink, non sono configurati (Figure 2a). Generalizzando, il gradiente specifica un attributo per la direzione e uno con un valore; un nodo ha, al massimo, tanti gradienti quanti sono i vicini, ciascuno si distingue dall altro per l attributo valore, che ne denota la potenza. E compito del progettista definire l attributo valore, nel caso dell applicazione denota l intervallo del dato. I nodi, dotati del rilevatore di gas, si attivano al ricevimento dell interesse se, e solo se, sono collocati nella regione X, i nodi intermediari impostano unicamente il gradiente.
Figure 2 Trasmissione del dato Il dato, generato da un sensore come reazione ad un evento, è tipicamente il rilevamento di un fenomeno. Nel caso in esame si tratta di la soglia di CO2 è superata nella regione X. Quando un nodo riceve, o genera, il dato utilizza il gradiente per riconoscere il prossimo destinatario. Il procedimento si ripete su ogni nodo fino al sink. Il dato, inizialmente, si propaga su più traiettorie; è il sink a decidere quale sia, in primis, il nodo più conveniente e, in cascata, ciascun nodo scelto lungo la traiettoria sceglierà un nodo preferenziale (Figure 2b). Il rinforzo avviene utilizzando una regola locale definita dal progettista. I nodi intermediari sono in grado di aggregare l informazione ricevuta da più sensori in un informazione unica e più accurata. Il sink periodicamente rinfresca e rispedisce l interesse quando inizia a ricevere i dati dalla sorgente. Questo è necessario perché gli interessi non sono trasmessi affidabilmente nella rete. Framework Architettura L architettura del framework è composta da (Figure 3): Core. Ha il compito di schedulare i processi rappresentati dalle istanze Task. Task. Classe astratta che lo scheduler pone in esecuzione. Dispone dei servizi base del framework; Message. E l entità dato trasmessa tra i nodi; Network. Libreria per l interfaccia di rete. Diffusion Protocol. Task che gestisce il protocollo Direct Diffusion. User Task. Task definito dall utente, di fatto, l applicazione. Figure 3 Architettura del framework
Stack del protocollo Lo stack del protocollo è visualizzato in Figure 4: sul lato sinistro sono raffigurati i livelli Iso mentre sulla destra i corrispondenti livelli implementati nel framework con, affiancati, i corrispettivi piani gestionali. Figure 4 Stack del protocollo Essendo il framework sviluppato sulla Java Virtual Machine sono stati utilizzati gli strumenti messi a disposizione: il livello di trasporto è costituito dalla DatagramSocket di Java e i messaggi sono spediti in unicast o multicast. Essendo l ambiente di sviluppo costituito da PC, Il framework utilizza l Ip di un rete Ethernet. I messaggi, generati da un nodo, vengono serializzati, inviati nella rete come datagrammi, ricevuti dal destinatario, deserializzati e infine notificato, a livello applicativo, l arrivo di un nuovo messaggio. Il livello applicativo è composto da più task, uno scheduler li esegue in base agli eventi riscontrati. Nel framework sono definiti i seguenti task: l implementazione di direct diffusion; emettitore di eventi percepiti dall esterno; ricettore di eventi; filtro per l aggregazione di dati. Il protocollo combina, tra di loro, vari piani gestionali: Gestione Energetica : l energia, risorsa critica in un sensore, è massimizzata non inviando dati nella rete finchè qualcuno non manifesta l interesse. Il numero di messaggi trasmessi viene ridotto aggregandoli tra di loro utilizzando dei filtri definiti dall utente. Gestione dei task: schedula i task in base alla posizione geografica. La rilevazione di eventi esterni viene attivata solo se appartenente alla regione specificata dalla query dell utente. Spazio dei nomi e Matching In direct diffusion i dati sono definiti da una lista di triple attributo-operatore-valore. L attributo indica la semantica del dato,l operatore descrive come matchare gli attributi tra di loro e, infine, il valore il dato.
Di seguito, con riferimento all applicazione sviluppata, è riportato un esempio di interesse emesso dal sink: class IS interest //tipo di device device EQ airdetector //materia da esaminare element EQ CO2 //sostanza da rilevare concentration GE 20% //concentrazione minima longitude GE 20 //longitudine latitude LE 40 //latitudine interval is 100 ms //intervallo richiesto tra ciascun dato expire IS 05:12:20 //ora della scadenza Si noti che gli attributi sono definiti per lo scenario in esame, questi dipendono dall applicazione e vanno definiti dal progettista. Il match tra due messaggi è determinato applicando una regola che, sinteticamente, valuta le espressioni di assegnamento (Device Is air) con quelle condizionali (Device Eq air) in base all operatore (euqal, greater, less,..). Un esempio: Device Is air matcha con Device Eq air, mentre Concentration Is 20 non matcha con Concentration LE 10 dove LE sta per Lower or Equal. A tal fine il framework contiene un interprete per il linguaggio. Modello iterazionale L iterazione che avviene tra il nodo che genera l evento e quello che lo ascolta è definita dal modello Publish Subscribe. I nodi abilitati a sentire gli eventi esterni si registrano nel framework utilizzando l interfaccia publish: public void publish(htask ht, HPublished hp, AttributeList list) Il nodo pubblica che è in grado di generare gli eventi del tipo list; l handler del task, addetto a simularli, è ht; hp è l handler specifico per quella pubblicazione. La chiamata non ha nessun effetto sullo stato della rete; nel caso della ricezione di un interesse che matcha con quello pubblicato viene attivata la trasmissione dati. Il sink, che manifesta l interesse a causa della query dell utente, ha il ruolo di subscriber. Esso si registra, presso il framework, come interessato a una tipologia di eventi. public void subscribe(htask f, HSubscribed hp, AttributeList list) List, in questo caso, descrive gli eventi di cui il nodo si registra. Diversamente da publish, questa istruzione cambia lo stato della rete: il nodo inizia ad inviare, in broadcast e periodicamente, messaggi di interesse. Avvenute entrambe le registrazioni, gli interessi si diffondono fino al rispettivo publisher identificato dal match con il dato da lui pubblicato e con quello sottoscritto dalla sorgente. A questo punto il sensore inizia la trasmissione dati.
Figure 5 Modello Iterazionale Publish-Subscribe Propagazione dell interesse All atto della registrazione del sink, come subsriber, inizia l invio periodico di messaggi d interesse, questi contengono due dati importanti: un intervallo temporale: datarate ; una scadenza temporale: expire. Il primo specifica, al subscriber, la frequenza con cui effettuare la rilevazione e l invio dei dati. In una prima fase vengono inviati messaggi d interesse denominati esplorativi, questi hanno un intervallo molto largo di rilevazione. Lo scopo è di esplorare l ambiente per localizzare la sorgente. In una seconda fase, che inizia quando il sink riceve i primi dati, seleziona un percorso preferenziale secondo una regola locale. Si rinizia l invio di messaggi, sempre di interesse, ma con un intervallo di rilevazione più basso. Quando la sorgente riceve questo nuova richiesta, inizia l invio dei dati vero e proprio. Il secondo parametro caratterizza lo stato debole della rete: l interesse, e con esso il gradiente, scade dopo un determinato periodo temporale. Per mantenere lo stato deve essere periodicamente rinfrescato con l invio di messaggi dal sink. Il rinfresco avviene con una serie di messaggi in cui viene ritardato l expire dell interesse. Ciò aumenta l overhead ma incrementa la robustezza della rete: nel caso un nodo cada sono disponibili altre strade. Si esamina, ora, come viene memorizzato ed elaborato un interesse da ciascun nodo. Ogni nodo ha una cache di interessi (la struttura è visualizzata in Figure 6). Ciascun elemento si distingue, dall altro, per la lista di attributi assegnatogli. Due interessi si discernono dagli attributi. Per esempio nell applicativo si differiscono quando hanno una diversa sostanza da rilevare o una diversa soglia o, piuttosto, una diversa regione da monitorare. Ciascun elemento può avere più gradienti, un gradiente definisce: la frequenza a cui inviare il dato; l indirizzo del nodo mittente; il momento dell ultimo match avvenuto; il momento della scadenza.
Figure 6 Diagramma Uml dell'interst cache Come detto pocanzi, le rete è in uno stato debole: i gradienti decadono allo scadere del tempo assegnatogli e, con essi, gli interessi. Alla ricezione di un interesse il nodo controlla se è già stato ricevuto esaminando la cache e, in caso affermativo, lo scarta. In seguito controlla se matcha con gli interessi esistenti: 1. nel caso affermativo. Se esiste già un gradiente per quel nodo lo si aggiorna con quello appena ricevuto, se non esiste si crea un nuovo gradiente. 2. nel caso negativo. Si crea un nuovo interesse e un nuovo gradiente. Quando un nodo riceve un messaggio non ha indicazioni per capire se l emittente sia un sink o meno in quanto l iterazione è locale. Il rinvio dell interesse è un broadcast. Il gradiente e fault tolernace Il gradiente specifica, nel caso più generale, un valore e una direzione. Il progettista assegna una semantica al valore a seconda del compito da eseguire. Nel caso dell applicativo, il valore è la frequenza con cui inviare il dato. Nella Figure 7 è riportato un esempio di settaggio dei gradienti tra i vari nodi. Ciascuna freccia rappresenta un gradiente, il colore è il tipo di interesse a cui appartiene, l etichetta numerica l ora di scadenza e la lunghezza è proporzionale al valore della frequenza. Figure 7 Il gradiente La freccia rossa indica che il gradiente è scaduto. E da notare che ciascun nodo stabilisce più gradienti dello stesso tipo tra i suoi vicini, ciò garantisce la possibilità di riportare il dato al sink anche in caso del fault di qualche nodo intermediario.
In sostanza la propagazione degli interessi setta uno stato nella rete per facilitare il ritorno dei dati al sink. Propagazione del dato Il sensore, che possiede le informazioni richieste dal, inizia a trasmettere i dati. Nel caso dell applicazione, il sensore inizia a monitorare l andamento delle sostanze richieste nel caso in cui è collocato nella zona specificata e la concentrazione superi una certa soglia. Riporto un esempio di dato : class IS data //tipo di device device IS airdetector //materia esaminata element IS CO2 //sostanza rilevata concentration IS 50% //concentrazione longitude EQ 20 //longitudine latitude EQ 40 //latitudine timestamp IS 05:12:10 //momento temporale dell evento Il messaggio, di tipo dato, è spedito, in unicast, a ciascun interessato. Il nodo, che lo riceve, cerca un match tra i suoi interessi (Figure 8) con due possibilità: 1. non riscontra nessun match: il messaggio viene eliminato, caso del nodo con la freccia rossa; 2. c è un match: il messaggio viene inviato fino al sink; Figure 8 Progazione del dato Alla ricezione di ogni messaggio viene controllata la cache, l obbiettivo è di previene il formarsi di loop che porterebbero a inutili sprechi energetici. Rinforzo della traiettoria Il sink, come abbiamo già visto, inizialmente invia messaggi d interesse, denominati d esplorazione, per individuare i publisher. Questi messaggi richiedono al nodo sorgente di inviare i dati ad un intervallo ampio. Quando la sorgente inizia a rispondergli, con dei messaggi denominati events data gradient, i messaggi giungono al sink da più traiettorie.
Il sink sceglie la traiettoria da rinforzare con delle regole locali. La scelta adottata nel framework è quella di rinforzare il vicino da cui, per primo, ha ricevuto il messaggio concorde con l interesse. Questa regola seleziona, empiricamente, il percorso con il ritardo più corto. Essa è reattiva ai cambiamenti: se un traiettoria invia dati più velocemente rispetto ad altre, il nodo seleziona quest ultima. Per rinforzare il vicino, il sink, rimanda l interesse iniziale ma con un intervallo più breve, vediamo un esempio: class IS interest //tipo di device device EQ airdetector //materia da esaminare element EQ CO2 //sostanza da rilevare concentration GE 20% //concentrazione minima longitude GE 20 //longitudine latitude LE 40 //latitudine interval is 10 ms //intervallo più piccolo Il nodo che lo riceve nota che ha già un gradiente corrispondente ma, quest ultimo, ha specificato un intervallo più breve. Intuitivamente il flusso di uscita è aumentato. Il nodo, accortosi del rinforzo, deve, a sua volta, applicare la medesima regola locale scegliendo un vicino da rinforzare. Riparazione locale per traiettorie fallite Precedentemente si è descritto le modalità con cui il sink rinforza una traiettoria. I nodi intermediari applicano,a loro volta, le regole di rinforzo. Questo è utile per riparazioni locali di percorsi che non funzionano o che hanno basse prestazioni. Figure 9 Recovery di una traiettoria Nella Figure 9 il nodo A, a cui è associato un datarate preferenziale, cade. Il nodo B sceglie di rinforzare un altro percorso (arancione). Filtri (aggregazione dati)
Figure 10 Filtro Direct diffusion permette di definire dei task denominati filtri. I filtri si registrano nel nodo e, se il messaggio ricevuto matcha, vengono messi in esecuzione. Un possibile utilizzo dei filtri è l aggregazione dei dati. In Figure 10 è visualizzato un filtro impiegato nell applicazione sviluppata. La sorgente A e la B rilevano, entrambi, la presenza di CO2 e spediscono un messaggio per notificarlo al sink. Sul nodo C si attiva il filtro che unisce i due messaggi in un unico messaggio spedito, infine, al sink. Simulazioni L applicativo è composto da una serie di nodi preconfigurati. Vi sono due sorgenti di CO2, una di CO, un sink di CO2 e un filtro. I nodi utilizzati come collegamento non vengono specificati con dei task. La simulazione, avvenuta in laboratorio, si è basta su quattro nodi. I risultati hanno dimostro che: il filtro aggrega i dati consentendo un minor traffico nella rete; il sink seleziona una strada preferenziale e, se un nodo cade, recupera una strada alternativa; un nodo sensore invia i dati solo se vi è un nodo che manifesta l interesse. Conclusioni Direct diffusion si dimostra essere un protocollo flessibile, adattabile ed efficiente. Utilizzando il data-naming il progettista è in grado, facilmente, di plasmare la rete sfruttandone l aggregazione dei dati. La parte più critica è, a mio avviso, l impostazione del gradiente. Come detto nel corso dell articolo, il gradiente è composto da una direzione e un valore. Il valore assume delle semantica a seconda dello scenario. Il gruppo di ricerca, che sviluppa il protocollo, accenna ad una serie di librerie, in corso di definizione, per adattare il gradiente, in base allo scenario applicativo. Un altro punto critico consiste nella regola locale con cui un nodo preferisce un percorso piuttosto che un altro. Nell applicazione si sceglie il nodo da cui, per prima, si è ricevuto il dato, questa politica predilige il percorso con minor latenza ma non è detto che sia la più affidabile. Un alternativa sarebbe quella di scegliere il nodo che, statisticamente, ha consegnato il maggior numero di dati. Il protocollo non permette QoS: non è garantito che un pacchetto arrivi a destinazione; non è possibile garantire una banda tra i nodi; non vi è bilanciamento del carico per evitare potenziali congestioni.