30.11.2012 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />

dati affidabili su reti <strong>di</strong> sensori senza cavo<br />

1. trasmissione <strong>di</strong> : pacchetti singoli vs blocchi <strong>di</strong> pacchetti vs stream<br />

<strong>di</strong> pacchetti in quanto il recapito affidabile <strong>di</strong> singoli pacchetti può<br />

essere importante ad esempio per dati aggregati, quello <strong>di</strong> blocchi<br />

adatto per applicazioni che usano meccanismi <strong>di</strong> <strong>di</strong>sseminazione <strong>di</strong><br />

query nella rete, mentre quello <strong>di</strong> stream adatto per applicazioni col<br />

compito <strong>di</strong> consegna perio<strong>di</strong>che <strong>di</strong> gruppi <strong>di</strong> misurazioni<br />

2. recapito garantito vs recapito stocastico in quanto per alcune<br />

applicazioni può essere necessario un alto livello <strong>di</strong> affidabilità,<br />

come le query <strong>di</strong>stribuite, ect mentre altre possono anche tollerare<br />

per<strong>di</strong>te purchè contenute in un certo range (ad esempio quando<br />

molti sensori provvedono ad inviare misurazioni correlate tra <strong>di</strong><br />

loro);<br />

3. dai no<strong>di</strong> sensori al sink vs dal nodo sink ai sensori e in questo<br />

caso si parla <strong>di</strong> “forward path” quando il flusso è quello che parte<br />

dai no<strong>di</strong> e arriva al Sink e <strong>di</strong> “reverse path” quando il flusso<br />

interessa i dati inviati dal sink verso i no<strong>di</strong> della rete.<br />

Il “Reliable Multi-Segment Transport” (RMST) proposto da Heidemann et<br />

al. [61] e il “Pump Slowly, Fetch Quickly” (PSFQ) <strong>di</strong> Wan et al. [62]<br />

realizzano un protocollo <strong>di</strong> trasporto per il recapito al sink <strong>di</strong> blocchi <strong>di</strong><br />

pacchetti. L’RMST fu progettato per essere utilizzato unitamente al <strong>di</strong>rect<br />

<strong>di</strong>ffusion [63] e prevede uno schema <strong>di</strong> recapito dei pacchetti <strong>di</strong> tipo “endto-end”.<br />

Il protocollo è basato su l’utilizzo selettivo <strong>di</strong> messaggi NACK e<br />

può essere usato secondo due schemi: “caching mode” e “non caching<br />

mode”. Secondo il primo schema un numero <strong>di</strong> no<strong>di</strong> lungo un percorso, ad<br />

esempio quello utilizzato dal <strong>di</strong>rect <strong>di</strong>ffusion per recapitare i dati al nodo<br />

sink, sono denominati come “RMST node”. Ogni RSMT node provvede a<br />

memorizzare in cache i frammenti <strong>di</strong> dati che compongono il flusso <strong>di</strong><br />

comunicazione, e a mantenere un timer associato ad ogni flusso <strong>di</strong><br />

comunicazione. Quando un frammento non è ricevuto prima che il timer sia<br />

76

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!