A Five-Phase Reservation Protocol (FPRP) for Mobile Ad Hoc Networks

Si pone il problema di implementare l'accesso a divisione di tempo (TDMA) al mezzo da parte dei nodi nodi di una rete ad-hoc, tenendo presente che quest'ultima è una rete multi-hop in cui quindi I nodi non sono tutti a distanza di comunicazione diretta, e questo perciò permette l'utilizzo del riuso di frequenza. Il protocollo in questione propone un nuovo sistema di assegnamento dei time slots (scheduling) ai nodi che vogliono comunicare all'interno della rete. I protocolli MAC tradizionali sono meccanismi del tipo contention-based, in cui quindi ogni nodo compete per accedere al mezzo. Perciò essi non sono molto adatti ai traffici che presentano determinati requisiti di QoS. Sono state proposte delle soluzioni per introdurre il TDMA nelle reti ad-hoc. I primi algoritmi prevedevano delle soluzioni centralizzate in cui ci sarebbe una stazione centrale che assegna i time slots ai vari nodi della rete in base alle richieste che gli arrivano. Però questa soluzione non è scalabile perchè queste stazioni centrali devono avere informazioni su tutta la rete, e più la rete sarà grande e più sarà difficile ricevere informazioni aggiornate e quindi consistenti. Inoltre la stazione centrale costituisce un punto di caduta singolo, cioè se esso cade allora cade tutta la rete. Altri algoritmi prevedono soluzioni distribuite senza la coordinazione di una stazione centrale. Però in questa situazione, all'inizio del funzionamento della rete, ad ogni nodo dovrà essere assegnato un canale TDMA fisso, il chè risulta complicato da implementare. Inoltre essi richiedeno alcune informazioni sulla topologia della rete (topoligy-dependent), e non consentono il riuso di frequenza. In seguito sono stati sviluppati altri algoritmi che sono topology-transparent, cioè sono indipendenti dalla topologia della rete, e sono quindi immuni alla mobilità dei nodi. Però anche qui non si è considerato la possibilità del riuso in frequenza, e inoltre essi utilizzano un canale separato per l'invio dei feedback alle richieste di riservazione dei canali.

L’algoritmo proposto
L'algoritmo proposto in questo paper consente di riservare parallelamente i timeslots da parte dei nodi che sono lontani tra loro e quindi non possono interferire sulla stessa frequenza. Esso permette trasmettere i messaggi di riservazione in un ambiente contention-based, ai soli nodi che si trovano a 2 hop di distanza. Perciò questo tipo di accesso al mezzo è resistente ai frequenti cambi di topologia, e inoltre è scalabile perchè i nodi non necessitano di conoscere l'intera topologia della rete e tutte le richieste di riservazione che sono state fatte. Per quanto riguarda il problema delle “hidden stations”, non viene usato il meccanismo RTS/CTS perchè può portare comunque a delle collisioni e altri problemi di vario genere. D'altra parte l'algoritmo usa sarà capace di rilevare le collisioni che avvengono in un nodo e a segnararle all'altro nodo che sta partecipando alla comunicazione.

Assunzioni
Le assunzioni fatte in questo lavoro sono le seguenti: • I canali sono bi-direzionali • I nodi hanno un timing ben sincronizzato tra loro • Il link tra due nodi è simmetrico e senza rumore • Durante l'applicazione dell'algoritmo la topologia della rete non cambia

Funzionamento
La sequenza dei frame durante la comunicazione è composta da un Reservation Frame (RF) e una sequenza di Information Frame (IF). L'IF è composto da un certo numero di Information Slots (IS) dove i nodi possono trasmettere i propri dati. L'RF è composto da N Reservation Frames (RS) utilizzato dai nodi per riservare il relativo IS negli IF che seguono. Ogni RS è composto da M Reservation Cycle (RC) dove un nodo ha un dialogo in 5 fasi con i propri vicini a 2 hop di distanza, con lo scopo di riservare un IS. I vicini che ricevono la richiesta dal nodo considerato possono accettarla o rigettarla. Nel caso in cui si verifichino più richieste per uno stesso slot, allora si assume che avviene una collisione e nessuno dei nodi riusce a riservarlo.

Dialogo in 5 fasi
1. Reservation phase: in cui il nodo richiedente invia ai suoi vicini un Reservation Request (RR) 2. Collision report phase: in cui i nodi riportano eventuali collisioni che si verificano nella fase 1. Se un nodo rileva una collisione allora lo segnala con un Collision Report (CR). Se il nodo che ha fatto la richiesta non riceve alcun CR allora vuol dire che ha vinto la riservazione e diventa un Transmission Node (TN). 3. Reservation Confirmation phase: se non ci sono collisioni allora il nodo richiedente invia una conferma di riservazione dello slot ai suoi vicini. 4. Reservation Acknowledgement phase: quest'ultimi risponderanno con un Reservation Acknowledgement (RA). Questa serve più che altro al nodo richiedente per sapere se effettivamente ci sono dei nodi vicino a lui, o se è isolato. Inoltre serve a comunicare ai nodi a 2 hop di distanza l'avvenuto successo della riservazione. Il deadlock è una situazione in cui si possono venire a trovare due o pià nodi vicini che hanno riservato lo stesso IS. Il daedlock può essere di due tipi: isolato (quando i nodi TN hanno solo vicini deadlock) e non isolato (quando hanno vicini anche non deadlock). Il deadlock accade quando questi nodi TN non hanno un vicino in comune che gli può comunicare che è avvenuta una collisione. Perciò entrambi i nodi pensano di aver vinto la riservazione ed entreranno nella fase 2. La fase 4 serve anche per prevenire questa situazione, infatti se i nodi che hanno fatto la riservazione non ricevono un ACK allora vuol dire che potrebbe essere avvenuto un deadlock. 5. Packing and Elimination phase: In questa fase si cerca di risolvere il problema del deadlock non isolato. I nodi che si trovano a 2 hop dal TN inviano ai propri vicini un Packing Packet (PP), in modo tale che loro sanno che una riservazione è avvenuta a 3 hop di distanza, e perciò saranno incoraggiati a riservare quel determinato IS. Questo con lo scopo di massimizzare il riuso di frequenza all'interno della rete (maximal packing). I pacchetti sono inviati dai TN ai nodi vicini in modo tale che se uno di loro è anch'esso un TN sullo stesso slot allora si fermerà di trasmettere.

Contention Policy
Il protocollo FPRP ha bisogno di un metodo di accesso del tipo contention-based per accedere al Reservation Frame). Si potrebbe pensare di usare il protocollo ALOHA che come sappiamo divide il tempo di accesso di un canale in time slots. Ma il protocollo ALOHA è progettato per operare in reti a singolo salto, mentre noi siamo interessati a lavorare in una rete multi-hop. Quello che allora si è proposto è di modificare l'algoritmo Rivest’s pseudo-Bayesian broadcasting algorithm
per questo scopo. Questo algorimo ogni nodo stima il numero dei propri vicini e calcola quindi la sua probabilità di accedere al canale come:

p = 1/n dove n all'inizio è il numero dei propri vicini, e poi viene aggiornato secondo i seguenti criteri: In caso di successo della riservazione o di idle: n = n-1 in caso di collisione: n = n + (e-2)-1

E-TDMA
Il protocollo presentato è composto da due TDMA schedules: uno broadcast in cui ad ogni nodo è assegnato un solo slot, ed è usato per scambiare informazioni di controllo tra i nodi (control schedule). Il secondo invece è usato per la trasmissione di dati (information schedule) e in questo caso un nodo può riservare il numero di slot di cui ha bisogno. Le riservazioni, in entrambi i casi, vengono fatte nel solo vicinato a distanza di 1 hop, quindi, visto che l'algoritmo lavora solo nell'ambito locale, esso risulta molto scalabile. Se un nodo necessita di comunicare con un suo vicino, riserverà il time slot coinvolgendo solo i nodi vicini a lui. Se il nodo con il quale sta comunicando sente una collisione sul canale allora lo comunica al nodo trasmittente che provvederà a riservare un diverso time slot.

Assunzioni
• • • • I nodi hanno il timing perfettamente sincronizzato tra loro I link sono simmetrici La topologia della rete è abbastanza stabile Ogni nodo può applicare il Five Phase Reservetion Protocol

Struttura Frame
Il canale TDMA viene partizionato in due fasi: un’epoca di controllo dove il protocollo applica lo schedule, e un’epoca di informazione dove avvengono le trasmissioni dati degli utenti. L’epoca di informazione è suddivisa in K frame di informazione che contengono L slot, dove le stazioni possono trasmettere. Il numero di slot assegnati ad un nodo dipende dal tipo di traffico scambiato, e viene deciso dall’ETDMA nella fase di information schedule. L’epoca di controllo è composta da due fasi: un fase di contesa e una fase di allocazione. La fase di contesa è divisa in N slot suddivisi a sua volta in un certo numero di cicli in 5 fasi del protocollo FPRP per la contesa del corrispondente colore temporaneo. La fase di allocazione è composta da N frames, in ognuno di quali i nodi vicini si scambiano informazioni come stabilito nella fase precedente. Il control schedule avviene in broadcast, e nella teoria dei grafi un broadcast schedule corrisponde alla colorazione dei nodi a distanza di 2 hop. Per questo motivo il control shedule viene chiamato anche colore. Ci sono due tipi di colori nel control schedule: il colore temporaneo e il colore permanente. Un nodo può avere un solo colore temporaneo e un solo colore permanente. I colori temporanei vengono usati per effettuare la riservazione di qualche slot di informazione o per ottenere un colore permanente. Essi durano solo il periodo di un frame. I colori permanenti servono a scambiare informazioni di scheduling con i propri vicini (non per fare le riservazioni). Essi sono usati per stabilizzare le connessioni quando i nodi sono fermi, permettendogli quindi dei periodi di trasmissione contention-free. Un colore permanente dura molto più a lungo di uno temporaneo e viene usato fino a quando il nodo non ha più niente da trasmettere o quando avviene una collisione. Se avviene questa

collisione allora il nodo abbandonerà questo colore permanente e ne acquisirà un altro. Il primo frame della fase di allocazione, che chiamiamo A1, sarà formato da M slot per i colori permanenti e N slot per i colori temporanei. Il numero di slot riservati per i colori temporanei decrementerà progressivamente nei frame A successivi.

Dettagli del protocollo
Un nodo che vuore riservare un determinato slot impara direttamente lo scheduling dei nodi vicini e impara invece indirettamente lo scheduling dei nodi a 2 hop di distanza. Infatti il nodo considerato viene a sapere se un nodo vicino ha riservato un qualche slot per ricevere dati da un suo vicino. Perciò un generico nodo non ha bisogno di comunicare direttamente con i nodi a 2 hop di distanza. Fase di contesa Come abbiamo detto, nella fase di contesa un nodo si contende un colore temporaneo tramite l’uso del FPRP protocol. Il colore temporaneo sarà poi usato per riservare uno slot di informazione o un colore permanente. Fase di allocazione In questa fase il nodo considerato trasmette il proprio schedule ai nodi vicini usando un schedule update frame all’interno degli slot relativi al proprio colore permanente. Ascolta poi lo schedule dei nodi vicini negli altri slot. In base agli schedule ricevuti dai propri vicini un nodo può fare gli aggiustamenti necessari al proprio schedule. In particolare gli stati principali in cui un nodo si può trovare è lo stato attivo in cui trasmette o riceve da un altro nodo e lo stato idle in cui non fa niente. Le operazioni più importanti che un nodo può fare sono 2: la riservazione e il rilascio di uno slot. Un nodo può rilasciare uno slot nel control scheduling o nell’information scheduling quando non ha più niente da trasmettere o quando verifica che è avvenuta una collisione. Esso poi comunicherà l’avvenuto rilascio ai nodi vicini tramite un su_frame. Riservare un nuovo slot è invece più difficile che rilasciarlo a causa delle possibili collisioni che si possono verificare con gli altri nodi. Il funzionamento è il seguente: • Il nodo sceglie lo slot da riservare e invia in broadcast il proprio schedule • Intento riceve gli schedule dai suoi nodi vicini • In base agli schedule ricevuti, modifica il proprio schedule • Può quindi adesso riservare uno slot per il colore permanente nel control schedule o uno slot di informazione nel Information schedule • Se vuole inviare dati al nodo j allora sceglierà uno slot in ci entrambi i nodi si troveranno nello stato di idle Le performance di questo protocollo sono migliori quando c’è poca mobilità dei nodi e quindi la topologia non cambia troppo frequentemente. In particolare, se i nodi sono immobili l’accesso al mezzo sarà collitions-free. Se i nodi si muovono, allora c’è la probabilità di avere delle collisioni all’interno degli slot riservati nell’epoca di informazione. A seguito di una collisione i nodi dovranno scegliere uno nuovo slot da riservare. La collisione può avvenire durante tutta la durata dell’epoca di informazione. Per ridurre il tempo di collisione si può pensare di aggiornare più spesso gli schedule dei nodi. Ma questo porta come svantaggio un maggiore overhead e un minor tempo di trasmissione per i nodi.

CROMA
Il metodo di accesso al mezzo del protocollo IEEE 802.11 non è adatto per lavorare in ambienti multi-hop, perché presenta ugualmente il problema delle stazioni nascoste, il problema delle stazioni esposte, non introduce alcuna politica per garantire il QoS ai flussi che la richiedono e inoltre presenta problemi di “fairness”. I protocolli collision-free permettono ai nodi della rete di riservare un canale per un certo intervallo di tempo per

effettuare la trasmissione di dati. Questo tipo di approccio permette di sostenere traffici che richiedono anche determinati requisiti di QoS, visto che l’accesso al mezzo avviene in modo deterministico. L’algoritmo proposto approfitta dei vantaggi presenti negli algoritmi di tipo contention-based per sviluppare un ambiente in cui il tempo è diviso in slot e quindi i nodi comunicano in questi slot in maniera contantion-free.

Descrizione del protocollo
CROMA (Collision-free Receiver-Oriented MAC) è un protocollo di routing distribuito sviluppato per reti mobili e ad-hoc, in cui i nodi operano a singola frequenza e con antenne direzionali. Esso divide il tempo in frame, che a loro volta sono suddivisi in time-slots. Ognuno di questi time-slot sarà attribuito ad un nodo ricevente che può instaurare una comunicazione con un certo numero di nodi trasmittenti. Nel proprio time-slot il nodo receiver può effettuare il polling dei nodi sender per instaurare una comunicazione. Per questo motivo il protocollo CROMA è detto receiver oriented.

Struttura del frame
Per lo studio di questo protocollo si assume, come per tutti i protocolli TDMA, che i nodi sono perfettamente sincronizzati tra di loro. Come abbiamo detto, CROMA divide il tempo in frame che sono a loro volta divisi in time slots. Ogni time slot sarà suddiviso in tre parti: REQ-mini-slot (request) e RTR-mini-slot (ready to receive) per la segnalazione tra i due nodi, e DATA-mini-slot per lo scambio dei dati. Il REQ-mini-slot è usato dai nodi che hanno dati da trasmettere (requesting nodes) per mandare un REQ al nodo receiver. Il RTR-mini-slot è usato per mandare il riscontro al messaggio REQ o ai dati precedentemente trasmessi; ed è inoltre usato da un nodo receiver per effettuare il polling dei sender nodes che vogliono inviarli dei dati su un time slot che hanno riservato. Gli altri nodi vicini sentiranno l’invio dell’RTR, e quindi eviteranno di tramettere durante quel determinato time slot. Se un nodo che ha trasmesso un REQ non riceve alcun messaggio RTR, allora entrerà in una fase di attesa e ritenterà la ritrasmissione nelle trame successive. La fase di attesa è imposta essere come un backoff esponenziale. Infine il DATA-mini-slot è usato per la trasmissione dei dati che avranno una dimensione fissa.

Dynamic destination-Sequense Distance-Vector (DSDV)
Questo algoritmo di instradamento cerca di importare la strategia dei protocolli del tipo Distance-Vector all'interno delle reti Ad-hoc. A differenza di questi ultimi però il DSDV introduce i numeri di sequenza per indicare se una route è valida, oppure è obsoleta. Questo consente di evitare la formazione di loop all'interno della rete, ed evita anche il problema del count-to-infinity. Ad ognuno dei nodi all'interno della rete sarà assegnato un numero di sequenza che sarà aggiornato ogni volta che rileva un cambiamento di topologia nella rete. Ogni nodo nel suo routing table avrà poi un certo numero di entry relative alle diverse destinazioni a cui è associato quindi un destination sequence number che sarà aggiornato ogni volta che il nodo rileva che c'è stato un cambiamento nella relativa route.

WRP
È un protocollo di routing prottivo, di tipo Distance Vector, che fa uso di particolari tabelle per evitare la creazione di loop all'interno dei percorsi di rete. In questo protocollo pgni nodo non memorizza solo la topologia della rete ma memorizza anche altre tabelle per avere più accurate informazioni. In particolare, ogni nodo fa uso di 4 tabelle: • Tabella delle distanze: memorizza le informazioni di rete possedute dai nodi vicini. Più precisamente memorizza una matrice in cui ogni elemento riporta la distanza e il nodo precedente per un dato vicino per raggiungere una destinazione. La tabella di routing: che contiene la topologia aggiornata della rete, il nodo precedente e successivo in una route per raggiungere una destinazione e un flag per indicare la validità del percorso La tabella dei costi dei link: riporta appunto il costo di spedire un pacchetto su un determinato link Lista dei messaggi ritrasmessi: ogni entry di questa tabella contiene I messaggi di update che dovranno essere ritrasmessi e un contatore che verrà decrementato ogni qualvolta un messaggio di update non ha avuto riscontro e deve quindi essere ritrasmesso. Questo meccanismo quindi serve a individuare link adiacenti che sono caduti.

• • •

Il funzionamento è il seguente: Quando un nodo riceve un messaggio di update, it update the distance for its links, but also checks the other neighbors' distance. So the convergence is much faster than DSDV. But, due the complexity of maintenance of multiple tables, it demands a larger memory and greater processing power from nodes. Futher, in high dynamic and large ad-hoc networks the control overhead is the same of DSDV.

Source Tree Adaptive Routing
È un algoritmo di tipo proactive di tipo Source Routing, perciò ogni nodo della rete mantiene in memoria la lista dei nodi da attraversare per raggiungere le diverse destinazioni. I nodi costruiscono questi percorsi (source tree) tramite lo scambio di particolari pacchetti contenenti Link-State Update (LSU). Questi LSU possono essere scambiati in modalità differenti: • LORA (Least Overhead Routing Approach), in cui gli update sono scambiati solo tra i nodi adiacenti; • ORA (Optimum Routing), in cui i pacchetti attraversano l'intera rete e vengono inviati a intervalli regolari; L'invio degli LSU avvengono quando avviene un cambio nella tolopogia di rete

Temporally Ordered Routing Approach
È un algoritmo di routing di tipo reattivo, efficiente, scalabile, e molto adattivo ai cambiamenti della topologia della rete, per questo è stato proposto per reti altamente dinamiche come lo sono le reti ad-hoc. Il suo funzionamento si basa sui pesi assegnati ai nodi nel partecipare nella route verso una certa destinazione. Quando una route viene creata, il peso di tutti i nodi viene settato con il valore NULL. La sorgente inizia quindi con l'inviare in broadcast un pacchetto di request QRY con l'ID del nodo di destinazione.

Se un nodo della rete riceve un pacchetto QRY può fare le seguenti cose: • Se il proprio peso è NULL allora ritrasmette il pacchetto in broadcast ai propri vicini. • Se il proprio peso non è NULL allora vuol dire che ha in memoria un percorso verso la destinazione. Allora spedisce un messaggio UPD con il proprio peso al nodo che gli ha inviato la QRY Un nodo che riceve un messaggio di UPD fa le seguenti operazioni: • Setta il proprio peso con quello ricevuto nel pacchetto UPD ma incrementato di uno • Invia un pacchetto UPD con il proprio peso ai nodi vicini Alla fine verrà costruito un grafo aciclico in cui i nodi che partecipano alla route saranno caratterizzati da pesi decrescenti andando dalla sorgente verso la destinazione.

Zone Routing Protocol
È Il primo protocollo ibrido che combina le strategie proattive e reattive. In questo protocollo viene definita la cosiddetta Routing Zone che sarebbe l'insieme di nodi che distano un certo numero di hop (Routing Radious) dal nodo considerato. All'interno della Routing Zone si usa un algoritmo di tipo proactive, perciò un nodo che riceve un pacchetto destinato ad un altro nodo interno alla propria RZ allora invia direttamente il pacchetto in unicast verso il nodo di destinazione. Se invece quest'ultimo non si trove nello stesso RZ allora si avvierà una procedura di Route Discovery per cui i nodi periferici invieranno un pacchetto di RREQ ai propri vicini che sono quindi in altre RZ.

Ad Hoc On Demand Distance Vector (AODV)
È un protocollo di routing di tipo reattivo e non-source. Il suo scopo è quello di minimizzare il numero di messaggi broadcast spediti in rete per la costruzione delle route che vengono aggiornate solo su richiesta, quando è necessario. Quindi ogni nodo della rete non avrà nella propria tabella i percorsi verso tutte le destinazioni. Vantaggi dell'AODV: • Consente di ottenere rapidamente percorsi verso nuove destinazione tramite messaggi di richiesta • Consente di eliminare dalla routing table i cammini che sono scaduti, cioè non usati per un certo periodo di tempo; • Reagisce velocemente alle rotture dei link e ai cambiamenti della topologia • Eredita dal protocollo DSDV il meccanismo dei numeri di sequenza che gli consente di creare route prive di loop, ed evitare quindi il count-to-infinity. Usa tre tipi di messaggi: • RREQ • RREP • RERR Quando un nodo cerca una route verso una nuova destinazione, invia in broadcast ai nodi vicini, un messaggio RREQ. Il percorso verrà ottenuto quando il pacchetto raggiunge il nodo di destinazione o quando raggiunge un nodo intermedio che possiede un percorso ancora valido verso quest'ultimo. I nodi suddetti risponderanno con un messaggio RREP spedito in unicast verso il nodo richiedente. Ogni nodo che riceve il RREQ memorizza al proprio interno il percorso inverso verso il nodo richiedente, in modo da permettere succissivamente di spedirgli il RREP.

Se un nodo non riceve alcuna risposta entro un certo intervallo di tempo al proprio RREQ allora invierà un nuovo RREQ con un TTL pià alto. Ogni nodo monitora i suoi vicini inviando periodicamente degli Hello Messages. Questo permette al nodo di accorgersi quando si sono verificate delle cadute dei link o cambiamenti nella topologia. Se questo avviene allora il nodo considerato invierà un messaggio RERR per informare i nodi vicini dell'evento. I nodi che saranno informati non saranno tutti i nodi vicini, ma saranno quelli per cui il nodo li considera precursori all'interno delle route che coinvolgono il link caduto.

Numeri di sequenza
I numeri di sequenza vengono usati per evitare il formarsi di loop all'interno di una route, e per evitare il problema del count-to-infinity. In particolare ci sono due numeri di sequenza. Ad ogni nodo della rete sarà assegnato un SN che viene aggiornato in due situazioni: • Prima di generare un messaggio RREQ il nodo deve incrementare di 1 il suo SN • Prima di generare un messaggio RREP il nodo dovrà impostare il proprio SN al valore massimo tra quello corrente che possiede e quello che ha ricevuto con l'RREQ Nei messaggi RREQ saranno presenti i seguenti campi: • Destination Sequence Number (DSN): SN del nodo di destinazione • Source Sequense Number (SSN): SN del nodo sorgente mentre nel messaggio RREP sarà presente solo il DSN. Nel momento della generazione del RREQ, il DSN sarà ricavato dai precedenti cammini scaduti o non validi, oppure se la destinazione è nuova, allora sarà impostato a 0. Quando un nodo riceve un messaggio RREP aggiornerà il DSN contenuto nella propria routing table con quella contenuta nel messaggio.

RERR
Il messaggio RERR può essere inviato in tre diverse situazioni: • Se il nodo corrente scopre che il link al nodo successivo è caduto • Se non ha alcuna route valida verso la destinazione • Se riceve un RERR riguardante uno o più cammini nella sua routing table Un nodo che riceve un messaggio RERR aggiornerà il DSN e imposterà l'hop count a infinito per invalidare la route.

Riparazioni locali
Il protocollo considerato permette anche di effettuare delle riparazioni locali, nel senso che se il nodo che rileva la caduta di un link lungo la route considerata non è molto distante dalla destinazione allora può inviare un messaggio RREQ per individuare un nuovo percorso. Se non riceve alcuna RREP dopo un centro intervallo di tempo allora invierà un RERR verso il nodo sorgente. Però alcune volte non risulta conveniente effettuare riparazioni locali perchè si rischia di trovare percorsi che sono molto più lunghi del precedente.

Dynamic Source Routing (DSR)
È un protocollo di routing reattivo del tipo source routing, perciò ogni pacchetto scambiato contiene l'intero percorso dalla sorgente alla destinazione. Il routing dei pacchetti sarà effettuato da parte dei nodi, semplicemente andondo a leggere il next hop all'interno dell'intestazione del pacchetto stesso. Quindi il DSR non necessita di inviare messaggi di segnalazione periodici per l'aggiornamento dei percorsi, e quindi evita il consumo di banda dovuto all'overhead, ed evita il relativo consumo di potenza da parte dei nodi. I meccanismi che caratterizzano il percorso sono 2: • Il Route Discovery per la scoperta del percorso verso il nodo di destinazione • Il Route Maintenance per il mantenimento dei percorsi

Route Discovery
Se un nodo che deve comunicare con un altro nodo non conosce il percorso su cui instradare il pacchetto allora avvia la procedura di route discovery. Viene inviato un messaggio RREQ contenente il route record in cui è riportata la sequenza dei nodi attraversati in quel momento per raggiungere il nodo di destinazione. Un nodo della rete che riceve un messaggio RREQ, prima cosa di tutto verifica che non l'abbia già ricevuto andando a leggere il request id. Dopo si verifica questa situazione: • Se il nodo che ha ricevuto il RREQ coincide con il nodo di destinazione allora la ricerca è terminata e viene inviato un messaggio di route reply verso il nodo sorgente. • Altrimenti il nodo considerato inserisce il proprio indirizzo nel route record e inoltra il pacchetto RREQ agli altri nodi

Route Maintenance
La route maintenance è l'operazione usata per monitorare lo stato del percorso considerato. Per fare ciò, un nodo della rete che sta usando qualcuno dei percorsi che ha memorizzato, contemporaneamente controlla lo stato delle operazioni. Se rileva che è avvenuta la caduta di qualche link, allora cancella la route considerata dalla propria tabella di routing, e invia un messaggio RERR verso il nodo sorgente. I nodi che riceveranno questo messaggio cancelleranno anche loro la route considerata dalla propria tabellam e nel caso che ne hanno bisogno, avvieranno un processo di route discovery per la destinazione considerata

Location Aided Routing
È un particolare protocollo d routing che fa uso dell’informazione geografica dei nodi ottenuta con sistemi, quale ad esempio il GPS. L’obbiettivo di questi tipi di protocolli è quello di ridurre l’overhead all’interno della rete in modo da ridurre i consumi energetici dei nodi della rete. Per fare ciò, invece di effettuare il flooding sull’intera rete, Il LAR lo limita ad una zona delimitata grazie alle informazioni geografiche dei nodi. Supponiamo che il nodo sorgente conosca la posizione iniziale e la velocità del nodo destinazione con il quale vuole comunicare. Allora potrà calcolare localmente quale potrebbe essere la posizione del nodo destinazione negli istanti successivi. In particolare andrà a calcolare la cosiddetta expected zone che sarebbe un’area di raggio calcolato in base alla posizione iniziale e la velocità del nodo destinazione. Quindi l’expected zone è la zona dove il nodo sorgente si aspetta di trovare il nodo destinazione. In base a questa informazione il nodo sorgente calcola il request zone che è un’area dove sono contenuti i nodi che potrebbero partecipare all’instradamento dei pacchetti verso la destinazione, e quindi solo questi nodi

possono inoltrare le route request inviate da parte del nodo sorgente. Per aumentare le possibilità di raggiungere il nodo di destinazione è opportuno includere l’expected zone nella request zone Esistono diverse varianti del protocollo LAR: • • LAR Schema 1: che costruisce la Request Zone come un rettangolo fatto in modo da avere il nodo sorgente su un vertice e in modo da includere l’Expected Zone LAR Schema 2: invece di specificare la Request Zone nella route request, si specifica la posizione del nodo destinazione e la distanza dal nodo sorgente. Nella route request generata dal nodo sorgente viene indicata la distanza di quest’ultimo dal nodo di destinazione. Un nodo che successivamente riceve la route request verifica per prima cosa che la sua distanza sia inferiore a quella riportata all’interno del messaggio. Se è inferiore allora scrive la propria distanza all’interno del messaggio e poi lo inoltra ai nodi vicini. Se invece è superiore allora il pacchetto viene scartato.

Fish Eye State Protocol
È un protocollo molto simile ai protocolli di tipo link state, visto che ogni nodo conserva una tabella di routing, una tabella dei nodi vicini, e una tabella della topologia. Però a differenza dei protocolli link state, l'FSR non effettua il flooding in tutta la rete ma solo ai nodi vicini. In particolare l'idea è quella di mantenere informazioni aggiornate sui collegamenti con i vicini e diminuire poi sempre di più il livello di accuratezza all'aumentare della distanza, cioè il numero di hop. Esso come DSDV fa uso dei numeri di sequenza per individuare quali sono le informazioni più recenti.

Sign up to vote on this title
UsefulNot useful