download tesi - MobiLab - Università degli Studi di Napoli Federico II

Progetto e valutazione di algoritmi per la raccolta
dati affidabili su reti di sensori senza cavo
mostrata in figura 4.1 dove si individuano 9 nodi sensori, di cui quello con
id pari a 0 (nodo più a destra) è il nodo sink mentre gli altri sono i nodi
addetti alle misurazioni. Le linee punto punto in grigio rappresentano i
collegamenti che godono di una probabilità di perdita dei pacchetti inferiore
al 30%, mentre quelli in rosso collegamenti con probabilità compresa tra il
30% e il 70%. Risulta chiaro, dalle caratteristiche esposte in tabella 4.1, che
per avere una completa caratterizzazione dell’evento monitorato è
necessario che ogni sensore recapiti la propria misurazione/i al nodo sink,
quindi una perdita di pacchetto dovuta alla congestione della rete o alla
bassa qualità del link tra i nodi causerà una situazione in cui il nodo sink
non avrà a disposizione tutte le informazioni necessarie al monitoraggio
della zona interessata.
Riguardo lo schema implementativo dell’applicazione questo risulta essere
molto semplice e uno stralcio del file di configurazione è presentato in
configuration Simple_Data_Gathering {}
implementation {
components Main, SurgeM, TimerC, LedsC, NoLeds, Photo, RandomLFSR,
GenericCommPromiscuous as Comm, Bcast, MultiHopRouter as
multihopM, QueuedSend, Sounder;
....
SurgeM.TimerControlCoverage -> TimerC.Timer[unique("Timer")];
SurgeM.MeasureTimer -> TimerC.Timer[unique("Timer")];
SurgeM.RouteControl -> multihopM;
SurgeM.Send->multihopM.Send[AM_SURGEMSG];
multihopM.ReceiveMsg[AM_SURGEMSG]->Comm.ReceiveMsg[AM_SURGEMSG];
//Per mandare e ricevere messaggi di misurazione
SurgeM.SendMeasureMsg -> Comm.SendMsg[AM_MEASUREMSG];
SurgeM.ReceiveMeasureMsg -> Comm.ReceiveMsg[AM_MEASUREMSG];
//usato dal sink per ricevere le misure
SurgeM.ReceiveMeasure -> Comm.ReceiveMsg[AM_SURGEMSG];
Figura 4.2: Stralcio del file di configurazione della prima simulazione
88
1
3
2