Elaborato Esposito Lorenzo N46-000163

Transcript

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Reti di calcolatori
Protocolli di Routing per reti VANET
Anno Accademico 2012-2013
Candidato:
Lorenzo Esposito
matr. N46/000163
Alla mia famiglia, che mi ha sempre
sostenuto e aiutato in questi anni.
Ai miei amici e compagni di corso, per il
supporto datomi, e i numerosi consigli.
Indice
Introduzione
4
Capitolo 1. Panoramica sulle reti VANET
6
1.1
1.2
1.3
1.3.1
1.3.2
Principali caratteristiche e dispositivi di rete
Scenari di applicazione
Meccanismi per il routing
Beaconing
Flooding e Route Discovery
6
8
9
9
10
Capitolo 2. Protocolli di routing per reti VANET
2.1
2.1.1
2.1.2
2.1.3
2.2
2.2.1
2.3
2.3.1
2.3.2
2.4
2.4.1
2.5
2.5.1
12
Topology-Based Routing Protocols
Proactive - OLSR
Reactive - DSR
Hybrid - ZRP
Position-Based Routing Protocols
GPSR
Geocast-Based Routing Protocols
IVG
ROVER
Cluster-Based Routing Protocols
CBLR
Broadcast-Based Routing Protocols
BROADCOMM
13
13
15
17
20
20
23
24
25
27
28
30
30
Conclusioni
Bibliografia
32
33
III
Introduzione
Le proiezioni demografiche dei principali istituti statistici internazionali ci segnalano
oramai da tempo l’accelerazione del fenomeno dell’inurbamento a scala globale.
Nelle città si sta concentrando la gran parte della popolazione del nostro pianeta e le
distorsioni che ne conseguono sono già sotto gli occhi di tutti: dalle gravi tensioni sociali,
alle crisi economiche globali, ai preoccupanti livelli di disoccupazione, fino ad arrivare ai
problemi legati all’ambiente ed al consumo di risorse naturali.
In tal senso assume particolare rilievo il concetto di Smart City, ovvero un modello di città
che fa uso di adeguate tecnologie, in special modo di quelle dell’informazione e della
comunicazione (ICT), al fine di migliorare la qualità della vita dei propri cittadini e
garantire il massimo dell’efficienza: maggiore competitività con minore consumo di
risorse.
Lo sviluppo di una mobilità intelligente (Smart Mobility) rappresenta una delle sfide più
difficili nell’ambito delle Smart City. L’obiettivo è quello di offrire al cittadino una nuova
gamma di servizi ed applicazioni che lo possa agevolare nello spostamento sul tessuto
cittadino, garantendogli una migliore qualità di viaggio.
Negli ultimi anni, la ricerca ha investito molto nel campo dell’ITS (Intelligent
Transportation System), e in special modo nello sviluppo di particolari reti Ad-Hoc tra
veicoli: le VANET (Vehicular Ad Hoc Networks).
Lo scopo principale di una rete VANET è quello di realizzare un meccanismo di sicurezza
4
attiva, attraverso l’inter-comunicazione tra i veicoli. Un veicolo che percorre una data
strada, può diffondere attraverso la rete informazioni viarie molto utili ai veicoli vicini e a
quelli che sopraggiungono sul percorso. Le informazioni trasmesse interessano le
condizioni stradali, la velocità di percorrenza dei veicoli, lo stato del traffico o l’eventuale
presenza di incidenti lungo il percorso. Grazie a questo continuo scambio di informazioni,
il conducente del veicolo sarà messo immediatamente in guardia in presenza di
un
potenziale pericolo sulla strada; in questo modo si può diminuire drasticamente il numero
di incidenti.
Lo scambio di informazioni è altamente dinamico e non coinvolge solo i veicoli, ma anche
le infrastrutture stradali, che a tal fine, saranno dotate di opportuni sensori.
Lo scopo di questa tesi è fornire una panoramica sui principali aspetti delle reti VANET
con particolare attenzione ai protocolli di livello network.
Nel primo capitolo di questo elaborato verrà inquadrato l’ambiente VANET, fornendo una
descrizione delle principali caratteristiche, degli scenari di applicazione, e delle possibili
tecniche utilizzate per lo scambio di informazioni e della creazione delle rotte.
Nel secondo capitolo, invece, saranno analizzati i protocolli di routing concepiti per
operare su queste reti; di tali protocolli verrà fornita una classificazione e ne sarà
analizzato il funzionamento, focalizzando l’attenzione sulle procedure tipiche che li
caratterizzano: il discovery dei nodi all’interno della rete, il beaconing per la trasmissione
periodica delle informazioni, e le tecniche di flooding per la trasmissione in broadcast.
5
Capitolo 1
Panoramica sulle reti VANET
Le Vehicular Ad-Hoc Network, comunemente chiamate con l’acronimo VANET,
rappresentano una sottocategoria delle reti Mobile Ad-Hoc Network (MANET). Queste
reti si basano sulla comunicazione cooperativa tra nodi paritetici, senza la necessità di
infrastrutture di rete preesistenti e formano configurazioni dinamiche (Ad-Hoc).
1.1 Principali caratteristiche e dispositivi di rete
E’ importante sottolineare che le VANET hanno caratteristiche peculiari che le
differenziano dalle generiche MANET. Le principali differenze riguardano:

Velocità di spostamento dei nodi - I veicoli, data la loro elevata mobilità,
generano continuamente diversi scenari e di conseguenza, il rapido mutamento della
topologia delle reti. Tuttavia, bisogna tener presente che la mobilità veicolare è
vincolata a strade e autostrade, ciò significa che vi è un certo grado di predicibilità
sulla mutazione della topologia della rete stessa.

Assenza di problematiche energetiche - I veicoli non hanno problemi di
reperimento dell’energia necessaria per effettuare le comunicazioni, dato che i
dispositivi di rete installati sono alimentati dalla batteria dello stesso veicolo. Ciò
consente un maggiore impiego di risorse hardware rispetto alle MANET, e quindi la
priorità può essere focalizzata sulle performance e non sul consumo energetico.
6
Le comunicazioni in ambito VANET infatti sono realizzate con tecnologie wireless
avanzate come DSRC (Dedicated Short-Range Communication).

Utilizzo di sistemi di posizionamento - I veicoli sono dotati di sistemi di
posizionamento come il GPS (Global Positioning System). Questi sono in grado di
rivelare la posizione geografica del veicolo sul territorio e forniscono conoscenza
sull’ambiente circostante. Queste informazioni sono di vitale importanza poiché
permettono di implementare algoritmi di routing più efficienti.
Per realizzare le comunicazioni Inter-Veicolari (IVC), si utilizzano due tipologie di
dispositivi: OBU e RSU.

Le OBU (On Board Unit) sono dispositivi installati sui veicoli che gestiscono la
comunicazione. Le modalità di comunicazione previste in ambito VANET sono
due: V2V e V2I. La comunicazione V2V (Vehicle-to-Veichle) coinvolge due o più
veicoli, mentre la comunicazione V2I (Vehicle-to-Infrastructure) coinvolge il
veicolo e le infrastrutture stradali (RSU).
Le OBU devono fornire una connessione wireless al veicolo, eseguire il routing
Ad-Hoc, controllare la congestione della rete, supportare la mobilità per il
protocollo IP ed implementare, in collaborazione con altri strumenti e dispositivi,
meccanismi per garantire la sicurezza e la trustiness della comunicazione.

Le RSU (Road Side Unit) sono stazioni radio installate sulle infrastrutture
stradali, come segnali, semafori, pali della luce od anche edifici adiacenti le strade.
Questi dispositivi devono scambiare informazioni di sicurezza con le altre RSU ed
inoltrarle a tutti i veicoli nel range di copertura; inoltre possono fornire connettività
Internet alle OBU e prevedere meccanismi di estensione della rete Ad Hoc ai
veicoli che sopraggiungono nella zona.
7
In Figura 1.1 possiamo osservare una tipica configurazione di una rete VANET e le
possibili comunicazioni in questo scenario.
Figura 1.1 – VANET Scenario
1.2 Scenari di applicazione
Analizziamo adesso più nel dettaglio quali sono le applicazioni previste per le reti
veicolari. Possiamo individuare 4 macro-categorie di applicazioni [6]:

SICUREZZA ATTIVA - Le applicazioni di sicurezza attiva rivestono un ruolo
di primaria importanza poiché apportano il maggiore impatto sulla sicurezza
stradale. Queste applicazioni hanno lo scopo di segnalare al conducente condizioni
di warning che possono riguardare condizioni anormali del traffico, condizioni di
pericolo stradale o incidenti occorsi lungo il percorso.

SERVIZI PUBBLICI - In questa categoria abbiamo tutte quelle applicazioni di
supporto alle autorità e alle forze dell’ordine utili alla segnalazione di emergenze.
8

ASSISTENZA ALLA GUIDA - Conferiscono in questa categoria le applicazioni
che consentono di migliorare e semplificare la guida, come il cruise control
cooperativo (C-ACC), assistenza nella svolta a sinistra, servizi di Smart Parking.

MOBILE BUSINESS - Un grande blocco di applicazioni rientrano nella
categoria di mobile business. Tipiche applicazioni sono quelle per il pagamento
elettronico (strade a pedaggio, parcheggio, carburante…), per il noleggio di
automobili, ma anche servizi per la gestione delle flotte, per la diagnostica del
veicolo ed per l’instantant messaging tra veicoli.
1.3 Meccanismi per il routing
1.3.1 Beaconing
Beaconing è un termine piuttosto ambiguo, e può essere usato in vari contesti.
Se facciamo riferimento allo standard IEEE 802.11, per beaconing intendiamo il processo
mediante cui un Access Point (AP) segnala periodicamente la sua presenza nella rete
attraverso particolari frame inviate in broadcast, chiamate appunto beacon frame.
In ambito VANET, i beacon sono particolari messaggi inviati in broadcast da ogni veicolo
della rete ad intervalli regolari, tipicamente compresi tra 0.1s e 1s, al fine di aumentare la
conoscenza cooperativa [6].
Tipicamente hanno dimensione ridotta, pertanto contengono una quantità limitata di dati
come il valore dell’identificativo del veicolo, la sua posizione, la direzione, la velocità e
poche altre informazioni reperite dai sensori attivi del veicolo.
Figura 1.2 – Beaconing: periodic, single hop broadcast messages
9
I beacon message sono inviati sul canale in modalità broadcast a tutti i vicini che rientrano
nel range di copertura del veicolo (Figura 1.2). La comunicazione è single hop, e
solitamente le informazioni trasmesse nei pacchetti di beacon non sono re-inoltrate. In
diverse applicazioni, il beaconing può essere innescato in corrispondenza di eventi che si
verificano sulle strade, come incidenti o segnalazioni di pericolo.
Nel successivo capitolo vedremo come diversi protocolli geografici e diverse applicazioni
atte alla la trasmissione di informazioni attraverso tecniche multicast e broadcast, facciano
affidamento a questa tecnica.
1.3.2 Flooding e Route Discovery
Per Route Discovery intendiamo quel processo di rete che consente al nodo di determinare
una rotta verso la destinazione. La creazione delle rotte avviene mediante la diffusione in
broadcast di messaggi che contengono informazioni sui link esistenti nella rete, e il
Flooding (inondamento) rappresenta una delle tecniche maggiormente utilizzate per la
propagazione di questi pacchetti.
Nel Flooding, ogni nodo re-inoltra un messaggio ricevuto su tutte le interfacce di rete.
Quest'algoritmo è molto semplice da implementare, tuttavia un suo utilizzo, soprattutto in
reti molto affollate, genera un numero esponenziale di messaggi ridondanti a causa dalle
continue ritrasmissioni da parte di ogni nodo. L’overhead introdotto, pertanto riduce
drasticamente le prestazioni della rete stessa.
Per questa ragione, nel corso degli anni sono state proposte diverse ottimizzazioni
dell'algoritmo del Flooding, con l’obiettivo di ridurre il numero delle ritrasmissioni e di
conseguenza, il numero dei messaggi ridondanti. Una classificazione degli algoritmi di
broadcast è la seguente [16]:
Flooding semplice
Il Flooding semplice consiste nella trasmissione omnidirezionale del pacchetto a tutti i
nodi nell’area di copertura del mittente. Questi a loro volta invieranno il pacchetto a tutti i
loro vicini compresi quelli dai quali hanno appena ricevuto il pacchetto.
10
Probability Based Flooding
Per limitare il numero di messaggi nella rete si utilizza un TTL (Time To Live) oppure il
contatore di salto (hop count). Ogni volta che un nodo riceve un nuovo messaggio,
inizializza il contatore con valore "1" e definisce un ritardo di trasmissione chiamato
Random Assessment Delay (RAD). Se durante il RAD, il nodo riceve nuovamente lo
stesso messaggio, incrementa il contatore di 1. Allo scadere del RAD, il pacchetto sarà reinoltrato solo se il contatore è al di sotto di una certa soglia prefissata, altrimenti verrà
scartato.
Area Based Flooding
Con questo metodo, un nodo prima di inviare o ritrasmettere un pacchetto, appone la sua
posizione geografica nell’header. Quando un nodo riceve per la prima volta un pacchetto,
controlla la posizione del mittente e calcola la distanza massima a cui può ritrasmettere il
pacchetto, in base alla sua posizione corrente e alla copertura della propria antenna. Tale
distanza prende il nome di “area di copertura addizionale”.
Se l’area di copertura è inferiore ad un certo valore di soglia fissato, il nodo scarterà il
pacchetto e tutte le sue repliche ricevute successivamente, altrimenti, il nodo setta un RAD
al pacchetto prima di ritrasmetterlo.
Durante il tempo di attesa RAD, il nodo può ricevere nuovamente lo stesso pacchetto da
qualche altro nodo, in questo caso il nodo ricalcola l’area di copertura e ritesta le
condizioni di soglia. Tutte queste operazioni vengono effettuate continuamente sino allo
scadere del RAD.
11
Capitolo 2
Protocolli di routing per reti VANET
Nel
capitolo
precedente
abbiamo
analizzato
le
speciali
caratteristiche
che
contraddistinguono le reti VANET dagli altri tipi di reti mobili Ad-Hoc. Sulla base di
queste analisi, possiamo convincerci di come tali aspetti rendano più difficile lo sviluppo
di protocolli di routing efficienti. I nodi della rete non devono comportarsi come semplici
End-Point, ma devono essere in grado di operare anche a livello di rete. Essi infatti,
devono gestire autonomamente procedure di routing e inoltrare pacchetti verso altre
destinazioni all’interno della rete. L'obiettivo principale di questi protocolli è quello di
fornire percorsi ottimali tra i nodi cercando di minimizzare il sovraccarico della rete. Nel
corso degli anni ne sono stati proposti diversi, in particolare, come evidenziato in Figura
2.1, è possibile distinguere cinque differenti classi di protocolli [1], [3], [10].
Figura 2.1 – Classificazione dei protocolli di routing per reti VANET
12
2.1 Topology-Based Routing Protocols
In questa categoria rientrano tutti i protocolli di routing tradizionali concepiti per le reti
MANET, ma ancora applicabili per le VANET. Per inoltrare un pacchetto dal nodo
sorgente alla destinazione, tali protocolli utilizzano le informazioni sui link esistenti,
presenti nelle tabelle di routing. Individuiamo tre sottocategorie di protocolli di routing
topology-based: proactive, reactive e hybrid.
2.1.1 Proactive
I protocolli proattivi utilizzano tabelle di routing che memorizzano informazioni su tutti i
percorsi possibili nella rete, anche se non correntemente in uso. Ogni entry nella tabella di
routing contiene il next-hop sul percorso verso la destinazione. La tabella deve essere
aggiornata di frequente per riflettere i cambiamenti repentini che avvengono sulla
topologia della rete stessa, e dev’essere trasmessa periodicamente ai nodi vicini.
Generalmente questi protocolli utilizzano due strategie di routing differenti: Link State o
Distance Vector.
Un protocollo proattivo molto adoperato in quest’ambito è il protocollo OLSR [2].
OLSR
Il protocollo OLSR (Optimized Link State Routing) implementa la strategia di routing link
state eseguendo un routing hop-by-hop. I nodi mantengono aggiornate le proprie
informazioni sulla topologia della rete scambiandosi periodicamente dei messaggi.
Questi messaggi vengono diffusi nella rete mediante una tecnica di flooding ottimizata.
Neighbor Knowledge Flooding – Per ridurre le ritrasmissioni di pacchetti duplicati nella
stessa ragione, OLSR utilizza una tecnica di flooding ottimizzata basata sulla conoscenza
dei vicini, nota come Multi-Point Relaying. Ogni nodo nella rete sceglie un set di nodi nel
suo vicinato, affidandogli il compito di ritrasmettere i suoi pacchetti. Un nodo abilitato a
questo compito è chiamato Multi-Point Relay (MPR), e con gli altri MPR va a comporre il
Multi-Point Relays set (MPRs) del nodo.
13
Multi-Point Relay
Figura 2.2 – Differenze tra flooding semplice(A) e flooding ottimizzato con i MPR (B)
Questa tecnica prevede che i vicini di un nodo N, che non sono MPR per tale nodo,
ricevano e processino ugualmente il pacchetto inviato in broadcast da N, ma non lo
ritrasmettano. A questo scopo, ogni nodo mantiene una tabella chiamata MPR Selector Set
con l’insieme dei vicini che l’hanno selezionato come MPR. Ogni nodo sceglie i suoi
MPR tra i vicini, in modo che ogni messaggio che esso genera possa raggiungere tutti i
suoi 2hop-neighbor, ossia tutti i vicini a distanza di due hop. Imponendo tale vincolo, si
assicura che i messaggi inviati da ogni nodo raggiungano ogni nodo della rete.
OLSR messages - Un tipico messaggio in OLSR è l’HELLO message. Esso viene inviato
periodicamente da ogni nodo per informare i vicini della propria presenza e contiene gli
indirizzi dei nodi vicini, gli indirizzi dei vicini non più raggiungibili, gli indirizzi dei
propri MPR. Avendo settato il campo TTL = 1, l’HELLO message non viene mai reinoltrato. Un altro messaggio fondamentale è il Topology Control Message (TC). Questo
viene inviato dai nodi della rete che sanno di essere stati selezionati come MPR da parte di
un altro nodo, e contiene informazioni sulla topologia della rete. Il TimeToLive (TTL) di
questi messaggi è settato a 255, in modo che questi, a differenza dei primi, giungano a tutti
i nodi della rete.
14
Routing table calculation - Sulla base delle informazioni sui vicini, scambiate con i
messaggi di HELLO, e di quelle della topologia della rete, scambiate con i messaggi di
TC, i nodi sono in grado di calcolare localmente la propria tabella di routing.
2.1.2 Reactive
I protocolli di routing reattivi (chiamati anche reactive On-Demand) determinano il
percorso dalla sorgente alla destinazione solo quando effettivamente è necessario inviare
un pacchetto su tale percorso. Il vantaggio consiste nella riduzione dell’overhead di rete e
nel mantenimento di poche rotte, ma di contro vi è l’introduzione di una latenza legata al
calcolo del percorso. Analizziamo ora in dettaglio il protocollo DSR [4].
DSR
Il protocollo DSR (Dynamic Source Routing) è un protocollo reattivo di tipo source
routing: ogni pacchetto contiene la lista degli hop da attraversare per giungere alla
destinazione. Ogni host mobile che partecipa alla rete ad hoc, deve mantenere una route
cache, nella quale vengono memorizzate le rotte che ha scoperto verso altri host. Quando
un nodo deve inviare un pacchetto verso un altro nodo della rete, il mittente innanzitutto
verifica se è disponibile un percorso verso la destinazione nella cache, altrimenti da avvio
alla fase di Route Discovery. Durante l’attesa nella fase di discovery, l’host può proseguire
la normale elaborazione e continuare a inviare/ricevere pacchetti attraverso la rete. Ogni
entry nella route cache ha associata una scadenza, al termine della quale la voce viene
eliminata. Dato che la rete è soggetta a continui cambiamenti, un host che utilizza una
certa route ha l’obbligo di verificarne il suo corretto funzionamento. Quest’operazione di
monitoraggio è chiamata Route Maintenance.
Route Discovery - Un host che dà inizio alla procedura di Route Discovery invia in
flooding un pacchetto di Route Request (RREQ) a tutti gli host che si trovano nel raggio di
trasmissione. Il messaggio di RREQ oltre ai vari dati satellite contiene quattro campi
chiave:
15
 l’indirizzo dell’initiator della richiesta;
 l’indirizzo del target della richiesta;
 il Request Identifier (REQ_ ID), ossia l’identificatore univoco della richiesta;
 una Route Record, che contiene la lista degli indirizzi dei nodi già attraversati;
Ogni host mantiene una lista con le coppie <Initiator Address, REQ_ID> delle RREQ che
ha ricevuto di recente, così che possa scartare eventuali pacchetti duplicati.
La fase di Route Discovery ha successo quando il nodo che ha inviato la richiesta, riceve il
pacchetto di Route Reply (RREP) contenente la lista degli hop da seguire fino alla
destinazione.
In accordo con le premesse fatte, possiamo specificare i 4 passi fondamentali che
caratterizzano l’algoritmo di Route Discovery:
1. Se la coppia <Initiator Address, REQ_ID> per la RREQ ricevuta viene trovata
nella lista delle RREQ ricevute di recente, allora il pacchetto viene scartato e non
avviene alcun altra elaborazione.
2. Se l’indirizzo dell’host che ha ricevuto la RREQ è già nel Route Record della
richiesta, allora il pacchetto viene scartato e non avviene alcun altra elaborazione.
3. Se l’indirizzo target della RREQ coincide proprio con l’indirizzo dell’host che ha
ricevuto la richiesta, allora questo aggiunge il suo indirizzo nella lista degli hop da
seguire e invia il pacchetto di RREP verso la sorgente.
4. Se non ricadiamo in nessuno dei tre casi precedenti, l’host aggiunge il proprio
indirizzo nel Route Record della richiesta e ritrasmette in broadcast RREQ.
Ogni nodo che processa la RREQ verifica se è presente all’interno della propria route
cache un’entry con un percorso verso la sorgente della richiesta. Se non è presente,
sfruttando la lista di hop attraversati della Route Record, può aggiornare la sua Route
Cache con un percorso verso tale host.
Route Maintenance - A differenza dei protocolli di routing convenzionali, il DSR è
beaconless; ciò significa che non è previsto un invio periodico di messaggi con gli
eventuali aggiornamenti delle rotte. Alla procedura di Route Maintenance è affidato il
16
controllo dinamico del funzionamento della linea e il compito di informare il mittente di
eventuali errori di routing. Durante una trasmissione, sarà compito dei livelli superiori,
tipicamente del livello Data Link, segnalare problemi di trasmissione (per esempio se una
rotta è scaduta, e viene superato il numero massimo di ritrasmissioni possibili). Un host
che non riesce ad inoltrare un pacchetto al next-hop previsto, invia al mittente il pacchetto
di Route Error (RERR). Questo pacchetto contiene l’indirizzo dell’host che ha rilevato
l’errore di routing e l’indirizzo della destinazione a cui si stava tentando di trasmettere il
pacchetto. Quando un pacchetto di RERR viene trasmesso, tutte le rotte in errore nella
route cache vengono troncate in quel punto. Se il nodo initiator non ha un percorso
alternativo verso la destinazione nella sua Route Cache, sarà costretto a ripetere una nuova
fase di Route Discovery. Sono possibili numerose ottimizzazioni del protocollo DSR; una
soluzione può essere quella di impostare i nodi della rete in modalità “Promiscuos Mode”
così da far captare tutto il traffico delle trasmissioni passanti attorno ai nodi, dando la
possibilità ai nodi di individuare nuovi percorsi.
2.1.3 Hybrid
I protocolli ibridi rappresentano un mix di protocolli sia proattivi che reattivi; essi mirano
a ridurre la latenza nella fase di Route Discovery dei protocolli reattivi e l’overhead legato
al Beaconing dei protocolli proattivi.
Un protocollo molto utilizzato è ZRP [5].
ZRP
Il protocollo ZRP (Zone Routing Protocol) fa parte della famiglia dei protocolli ibridi.
Ogni nodo divide la rete in due regioni:
 Regioni interne o routing zone, di dimensioni fissate, in cui utilizza un meccanismo
di routing proattivo per mantenere le rotte;
 Regioni esterne, in cui utilizza un meccanismo di routing reattivo per il calcolo del
percorso per raggiungere un nodo esterno;
ZRP utilizza due protocolli: IARP e IERP.
17
IARP (IntrAzone Routing Protocol)
IARP è un protocollo di tipo proactive. Esso ha il compito di assicurare che ogni nodo
all'interno di una routing zone possieda una tabella di routing consistente e che venga
aggiornata periodicamente. Le informazioni contenute in tabella sono necessarie per poter
effettuare la ricerca di tutti i nodi all'interno della zona.
La routing zone di un nodo N è definita come l'insieme dei nodi che hanno distanza da N
minore o uguale ad un parametro ρ, noto come zone radius. In Figura 2.3 è rappresentato
un esempio di routing del nodo S con ρ = 2.
Figura 2.3 – IARP Routing
Affinché un nodo possa costruire una routing zone è necessario che conosca i suoi vicini,
ossia i nodi raggiungibili con percorsi lunghi un hop. L’identificazione dei vicini può
essere effettuata attraverso l'uso del protocollo NDP (Neighbor Discovery Protocol).
Questo protocollo è definito a livello MAC e tipicamente opera attraverso la trasmissione
periodica di messaggi di beacon chiamati HELLO.
L'associazione o la dissociazione di un nodo in una routing zone è un evento importante
per la routing zone stessa. Quest'evento viene gestito dal protocollo IARP il quale opererà
solamente nella zona interessata, senza comunicarlo ad altre zone in cui l’evento ha scarso
valore, in modo da minimizzare l’overhead.
IERP (IntErzone Routing Protocol)
IERP è un protocollo di tipo reactive. Esso svolge due compiti: il primo è quello di
effettuare ricerche di nodi in altre zone; il secondo è quello di ricercare un percorso per
18
raggiungere di una specifica destinazione. La ricerca di un percorso viene effettuata dai
nodi posizionati sui bordi di una zona, detti Border Node, i quali reperiscono informazioni
riguardanti i nodi di altre zone. Il reperimento di tali informazioni avviene tramite lo
scambio di messaggi tra border node e nodi all'interno di altre zone.
IERP ottimizza la fase di Route Discovery attraverso un altro protocollo, il BRP
(Bordercast Resolution Protocol). Il protocollo BRP non inoltra il pacchetto di Route
Query (che è a tutti gli effetti un pacchetto di RREQ) da vicino a vicino, bensì lo inoltra
verso i nodi periferici non ancora raggiunti, come esplicitato in Figura 2.4. Quando un
nodo A riceve una Route Query da B, A marca come coperti tutti i nodi che fanno parte
della routing zone di A e di B. Successivamente passa alla creazione di un albero di
bordercast che ha come radice se stesso (A). Quest’albero conterrà tutti i nodi periferici
ancora non coperti dalla Route Query. Come ultimo passaggio, il nodo A inoltrerà la
Route Query a tutti i nodi periferici, quindi segnalerà l'avvenuta copertura di questi nodi.
Come visto, le operazioni compiute dal protocollo BRP di IERP non risultano molto
diverse a quelle di un protocollo classico con funzioni di Route Discovery. Il mittente
genera il pacchetto di richiesta di comunicazione indicando in esso l'ID del nodo che vuole
contattare, dopodiché lo invia ad un sottoinsieme di nodi determinato dal protocollo BRP.
Quando un nodo riceve una Route Request, se è a conoscenza di un cammino verso il
nodo destinazione risponde con un messaggio di Route Reply contenente il cammino, in
caso contrario utilizzerà a sua volta il protocollo BRP per inoltrare la Route Request ad
altri nodi.
Figura 2.4 – Attraversamento dei border node con il Protocollo BRP
19
2.2 Position Based Routing
I protocolli di routing Position Based, conosciuti anche come geografici, basano le loro
funzioni di routing su informazioni posizionali. I nodi inviano i pacchetti sfruttando la
posizione geografica del nodo di destinazione piuttosto che gli indirizzi di rete.
Ogni nodo dev’essere in grado di ottenere la propria posizione e quella dei suoi vicini
attraverso sistemi di posizionamento geografico (GPS). Queste informazioni posizionali
sono diffuse dai vari nodi nella rete con tecniche di beaconing.
Quando la sorgente deve inviare un pacchetto, appone la posizione geografica della
destinazione nell’header; attraverso questa sola informazione il nodo realizza il routing, e
non avrà bisogno di effettuare fasi di Route Discovery, di Route Maintanence, e di
conoscere la topologia della rete.
Date le sue caratteristiche, i protocolli di routing Position Based sono considerati più
stabili e adatti agli ambienti VANET caratterizzati da un’elevata mobilità.
I protocolli di routing geografici si dividono a loro volta in tre classi:
 Protocolli Delay Tolerant Network (DTN);
 Protocolli Non Delay Tolerant Network (Non-DTN);
 Ibridi;
Il protocollo più significativo in questo ambito è GPSR [9].
2.2.1 GPSR
Il protocollo GPSR [9] (Greedy Perimeter Stateless Routing) rappresenta uno dei più
famosi protocolli di routing di tipo greedy, ed appartiene alla famiglia dei Non-DTN.
I protocolli appartenenti a questa famiglia assumono come ipotesi che ci sia sempre un
certo numero di nodi disponibili sulla rete, ai quali è possibile affidare la comunicazione.
Per questa ragione funzionano bene su reti molto affollate, come nel caso di una rete
veicolare in ambito urbano. Il suo principio di funzionamento è basato su una semplice
regola [8]: i nodi inviano sempre i loro pacchetti al vicino (neighbor) più vicino alla
destinazione. Questo approccio può dimostrarsi fallimentare se non ci sono dei nodi vicini
20
più vicini alla destinazione, se non il destinatario stesso. I vari protocolli di routing
Position Based gestiscono in differente modo il fallimento della comunicazione.
L’algoritmo di routing GPSR implementa due possibili modalità di forwarding per i
pacchetti: Greedy Forwarding che usa quando possibile, e Perimeter Forwarding.
Greedy Forwarding - I messaggi generati dai nodi della rete, contengono un campo dove
è contrassegnata la posizione geografica del nodo destinazione. Attraverso questa
informazione, un nodo intermedio che riceve un messaggio e che non è il diretto
destinatario, può ritrasmettere il messaggio al nodo del suo vicinato che è geograficamente
più vicino al nodo destinazione. Questo criterio di forwarding fa si che si vengano a creare
dei percorsi tra sorgente e destinazione con un minimo numero di hop. Analizziamo un
caso pratico di applicazione dell’algoritmo Greedy Forwarding:
Figura 2.5 – Greedy Forwarding
In Figura 2.5, il nodo x ha necessità di inviare un messaggio al nodo D. Il raggio di
trasmissione del nodo x è individuato dal cerchio tratteggiato, mentre l’arco passante in y
ha un raggio pari alla distanza tra y e D. Il nodo x inoltrerà il messaggio per D al nodo y
poiché questo risulta essere il più vicino alla destinazione nel suo raggio di trasmissione,
ovvero vale la relazione:
d(y, D)< d(z, D) ∀ z ϵ N(i)
Tale procedura sarà reiterata se possibile fino al raggiungimento di D.
GPSR utilizza largamente un servizio di beaconing per fornire ad ogni nodo la posizione
dei vicini. In ogni beacon message, il nodo appone la sua posizione geografica attraverso
le coordinate x e y, codificate su 4 Byte con rappresentazione in virgola mobile.
21
Per evitare sincronizzazioni di messaggi di beacon tra i vari nodi, essi vengono trasmessi
in maniera casuale in un intervallo di tempo B, dove di B è l’ampiezza del quanto di
tempo di trasmissione di un beacon. Se un nodo i non riceve nessun messaggio di beacon
da un vicino per un intervallo T, assume che il vicino in questione sia uscito dal raggio
d'azione o che non riesca ad inviare i messaggi. In entrambi i casi il vicino viene
cancellato dalla tabella dei vicini di i. Il quanto di tempo che intercorre tra due messaggi di
beacon non è fisso, ma dipende dalla densità di nodi che si trovano in un dato momento in
un'area geografica. Nel caso di alta densità di nodi in una determinata area, il quanto deve
essere piccolo. Se i riceve un beacon da j, esso inserisce j nella sua tabella dei vicini.
Supponiamo che durante il quanto di tempo per la ritrasmissione del pacchetto di beacon, j
si sposta nuovamente, ed esca dal vicinato di i. In questo caso, il nodo i crede di avere
ancora come vicino j, cosa invece falsa. Come è possibile vedere dall'esempio appena
esposto, errori di questo tipo sono molto frequenti nel caso in cui si sceglie un quanto di
tempo lungo per i pacchetti di beacon. Per questo motivo, la determinazione di un corretto
quanto è molto importante per la stabilità della rete. Riduzioni del numero di messaggi
circolanti nella rete sono comunque possibili. Ad esempio, è possibile concatenare ai
messaggi di comunicazione tra nodi messaggi di beacon, intervenendo opportunamente su
alcuni parametri.
Il Greedy Forwarding è molto semplice e veloce ma non può essere applicato sempre.
Osserviamo in Figura 2.7 un caso pratico in cui il criterio è inapplicabile.
Figura 2.6 – Greedy Forwarding non applicabile
Quando non è possibile utilizzare il Greedy Forwarding viene utilizzato il Perimeter
Forwarding. In Figura 2.6, si può osservare come il nodo x che ha ricevuto il pacchetto, sia
22
il nodo più vicino alla destinazione D. I nodi y e w ricadono nel raggio di trasmissione di
x, ma sono più lontani dalla destinazione D. I nodi v e z invece, sono più vicini alla
destinazione D, ma non sono raggiungibili da x.
Perimeter Forwarding - Quando il nodo x riceve un messaggio che non è in grado di
ritrasmettere con tecnica Greedy, utilizza la tecnica Perimeter, basata sulla “regola della
mano destra”. Questa tecnica prevede che il messaggio sia re-inoltrarlo al primo nodo che
si trova percorrendo in senso antiorario l’arco partendo da x. Facendo riferimento alla
Figura 2.6, in base alla regola della mano destra avremo il seguente attraversamento
(x→w→v→D→z→y→x). Questa operazione di navigazione da x a D con ritorno ad x, va
a generare una forma poligonale, un perimetro, che racchiude l’area vuota tra x e D.
Ogni pacchetto inviato è contrassegnato da un flag, che indica se la modalità con cui sta
avvenendo il forwarding è Greedy o Perimeter. Dopo aver trovato con la modalità
Perimeter un nuovo nodo utile per la costruzione del percorso, i pacchetti ritornano
nuovamente in modalità Greedy.
2.3 Geocast-Based Routing Protocols
I protocolli di routing che abbiamo analizzato in precedenza sono unicast; ciò significa che
ogni pacchetto generato da una sorgente è destinato ad un solo nodo della rete.
In questo paragrafo invece, saranno proposti protocolli di routing multicast per le reti
VANET. Essi si dividono in due categorie: Geocast-Based e Cluster-Based. Una
comunicazione si definisce multicast se il pacchetto è inviato da parte di una singola
sorgente ad un gruppo di nodi specifico, con una comunicazione multi-hop.
Figura 2.7 – Geobroadcast – il sender S inizia una comunicazione multihop in una determinata regione geografica
23
I protocolli Geocast-Based realizzano un servizio multicast che consente ad un singolo
veicolo di trasmettere pacchetti a tutti gli altri veicoli presenti in una specifica area
geografica chiamata zona di rilevanza (ZOR – Zone Of Relevance) [10]. Per limitare il
flooding alla relativa ZOR, si definisce la zona di inoltro (ZOF – Zone of forwarding),
ossia l’area geografica entro la quale i veicoli devono consegnare i pacchetti fino al
raggiungimento della ZOR. I protocolli Geocast-Based si dividono in beacon based e
beaconless. Ne analizziamo in questo caso due: IVG [11] e ROVER [12].
2.3.1 IVG
Il protocollo IVG [11] (Inter-Vehicular Geocast) è molto utilizzato in situazioni di
pericolo imminente (ad esempio per segnalare un incidente avvenuto lungo la strada).
Il veicolo in panne invia un messaggio di allarme in broadcast. I nodi che ricevono tale
messaggio non lo re-inviano immediatamente, ma aspettano un certo tempo chiamato
defer_time, per prendere una decisone sul re-invio del messaggio. Quando il defer_time si
esaurisce, se il nodo non ha ricevuto altri messaggi di allarme da altri veicoli alle spalle,
deduce di essere il Relay Node. Il relay node è quel nodo che si trova a maggior distanza
dal nodo che ha generato l’allarme, ed esso è il responsabile del re-invio del messaggio.
IVG riduce il numero di messaggi propagati sulla rete mantenendo dinamicamente un solo
relay node per ogni senso di marcia. Questa tecnica di selezione del relay node rende
inutile l’utilizzo di messaggi periodici di beacon, pertanto il protocollo è beaconless.
Figura 2.8 – il nodo z invia l’allarme; x è il nodo più lontano, pertanto diventa Relay Node e inoltra il
messaggio verso w (che non sarebbe raggiunto da y).
24
2.3.2 ROVER
Il protocollo ROVER [12] (RObust VEhicular Routing) adotta una tecnica di routing
simile a quella di AODV. I pacchetti di controllo sono inviati in flooding nella rete, mentre
i pacchetti dati sono inviati in modalità unicast. ROVER assume che:
 Ogni veicolo sia dotato di un identificatore univoco, il VIN (Vehicular
Identification Number);
 Ogni veicolo sia provvisto di ricevitore GPS per accedere a mappe digitali;
 La ZOR sia un area rettangolare;
 La ZOF includa il sender e la ZOR;
L’obiettivo del protocollo è di trasmettere un messaggio M, da un veicolo A, a tutti gli
altri veicoli in una ZOR Z. Il pacchetto è quindi costituito da una tripla <A, M, Z>. Un
veicolo che riceve il pacchetto, lo accetta solo se all’istante di ricezione è all’interno della
ZOR, altrimenti lo scarta. Tutti i veicoli nella ZOF sono parte del processo di routing, ma
solamente i veicoli appartenenti alla ZOR “passano” un messaggio ricevuto ai livelli
superiori di applicazione.
Figura 2.9 – ROVER: (A) ZRREQ flooding – (B) vehicles which respond with ZRREP make up the multicast tree
Route Discovery - L’obiettivo della Route Discovery è quello di costruire un albero di
multicast dal veicolo sorgente, a tutti i veicoli all’interno della ZOR Z.
25
Come possiamo osservare dalla Figura 2.9 (A), il processo di Route Discovery è iniziato
dal veicolo più in alto nella ZOR (Originator), che invia in flooding in tutta la ZOF un
messaggio di Zone Route Request (ZRREQ). Esso contiene: il VIN Originator, la sua
posizione, la ZOR corrente, il sequence number (SS), la ZOF.
Ogni veicolo che riceve per la prima volta un messaggio di ZRREQ con quel sequence
number, lo accetta solo se è all’interno della ZOF e non è troppo lontano dal mittente.
Tener conto anche della distanza del mittente consente di costruire un albero di multicast
“robusto”. Se un veicolo accetta il pacchetto di ZRREQ dovrà:
 inviare un messaggio di Zone Route Reply (ZRREP) al veicolo distante un hop che
gli ha inviato il messaggio di ZRREQ;
 memorizzare le informazioni <SS, Z, VIN ORIGINATOR> in una tabella di
routing;
 re-inviare in broadcast il messaggio di ZRREQ, includendo il VIN dell’originator,
ZOR, e SS;
I veicoli in ZOF non appartenenti a ZOR non inoltrano messaggi di ZRREP - Fig 2.9 (B).
Al termine del processo di flooding, a differenza di quanto accade in AODV, il nodo
sorgente non avrà ricevuto indietro alcun ZRREP. I nodi intermedi, che ricevono invece
tale messaggio, memorizzano nella loro tabella di routing il VIN del veicolo che gli ha
inviato questo messaggio, il valore di SS e il VIN ORIGINATOR.
Data Transfer - Con le informazioni a disposizione ogni nodo può costruire il suo albero
di routing multicast, che ha come radice l’originator. Tutti i nodi dell’albero multicast che
si è venuto a creare, compreso l’originator, inoltrano i messaggi M con tecnica unicast
verso i nodi da cui ha ricevuto in precedenza il messaggio di ZRREP. Grazie alle
informazioni contenute nella Route Table che si è venuta a creare col processo di Route
Discovery, ogni messaggio viene propagato attraverso l’albero multicast.
Route Timeout - Data la mobilità dei veicoli, la ZOR per una certa applicazione verrà a
modificarsi nel corso del tempo. In generale, se un veicolo invia molti messaggi in un
26
tempo breve nella stessa ZOR, non avrà bisogno di effettuare una nuova fase di Route
Discovery per ogni messaggio. Consideriamo come esempio, il caso di veicoli che
viaggiano sulla stessa corsia a 90 Km/h. La ZOR può cambiare solo di 25 m in un
secondo. Se il veicolo sorgente si muove di più di 25 m rispetto la posizione che occupava
all’inizio della fase di Route Discovery la ZOR sarà “invalidata”; in caso contrario lo
scambio di messaggi proseguirà senza problemi.
2.4 Cluster-Based Routing Protocols
I protocolli di routing Cluster-Based dividono la rete in gruppi, chiamati appunto clusters.
Ogni cluster raccoglie nodi che hanno le stesse caratteristiche, come: lo stesso senso di
marcia, la stessa velocità e così via. Inoltre, ogni cluster ha un suo capo, chiamato cluster
head, che è responsabile della gestione dei processi comunicativi all’interno del cluster e
al suo esterno. All’interno del cluster i nodi comunicano con path diretti, mentre le
comunicazioni esterne sono affidate al capo cluster, che crea a tale scopo infrastrutture di
rete virtuali. Questo schema realizzativo consente di ottenere una buona scalabilità per
grandi reti, anche se può incrementare l’overhead e i ritardi in reti altamente dinamiche.
Nella seguente figura si può osservare una tipica configurazione di rete a cluster.
Figura 2.10 – Cluster-Based Routing
Un protocollo di routing cluster-based molto apprezzato in ambito VANET è sicuramente
CBLR [15].
27
2.4.1 CBLR
L’algoritmo di routing CBLR [15] (Cluster-Based Location Routing) può essere
classificato come reactive, ed è basato su informazioni posizionali.
Ogni cluster-head mantiene due tabelle: la Cluster Table e la Cluster Neighbor Table.
La Cluster Table contiene le posizioni geografiche dei membri del cluster, mentre la
Cluster Neighbor Table contiene le posizioni geografiche e dei gateway nodes, attraverso
il quale il cluster-head può raggiungere un cluster vicino.
L’algoritmo di routing si articola in 4 passi:
Formation of Clusters - I cluster head inviano periodicamente dei beacon messagge di
HELLO in broadcast sulla rete. All’inizio della comunicazione, ogni nodo parte da uno
“stato d’indecisione”, avvia un timer e invia in broadcast sulla rete un messaggio di
HELLO. Se il nuovo nodo riceve un messaggio di HELLO dal cluster head prima
dell’esaurimento del timer, si assocerà a quel cluster e risponderà con un messaggio di
Reply HELLO. In caso contrario, diventerà esso stesso un cluster head.
Se il nodo di un cluster riceve un messaggio di HELLO da parte di un altro cluster head,
esso memorizzerà il suo indirizzo di rete e la sua posizione nella cluster neighbor table,
quindi cambierà il proprio stato da nodo semplice a gateway del suo cluster. Al termine di
queste operazioni, informa il capo cluster sui cambiamenti avvenuti.
Location Discovery Process - Quando un nodo sorgente deve inviare un pacchetto verso
una destinazione, verifica per prima cosa se nella sua tabella di routing è presente la sua
posizione geografica. In tal caso, invia il pacchetto verso il nodo più vicino alla
destinazione, altrimenti se tale informazione non è presente, oppure la rotta verso la
destinazione è scaduta, memorizzerà il pacchetto in un buffer e nel contempo darà inizio
alla fase di Discovery. Il nodo che da inizio a questa fase, invierà in broadcast sulla rete un
pacchetto di Location Request (LREQ). Per ottimizzare il flooding in queste reti, la
ritrasmissione dei pacchetti LREQ è concessa solo ai gateway node (verso altri gateway di
un differente cluster) ed ai cluster-head. Quando un cluster head riceve un pacchetto di
28
LREQ, legge innanzitutto l’ID del pacchetto, per determinare se ha già trattato
precedentemente la stessa richiesta. Se è così, scarta il pacchetto, altrimenti, se il nodo
destinazione è presente nel suo cluster, risponde al nodo sorgente con un messaggio di
Location Reply (LREP). Col messaggio di LREP, il nodo sorgente della richiesta viene a
conoscenza della posizione del destinatario. Se invece il nodo destinazione non è un
membro del suo cluster, il cluster head sarà costretto a re-inoltrare il pacchetto di LREQ
verso i cluster-head vicini, attraverso i suoi gateway nodes. Quando la LREQ perviene ad
un cluster head che è in grado di risolvere la richiesta, questi invierà indietro un pacchetto
di LREP al vicino più vicino alla sorgente, quindi raggiungerà finalmente la sorgente della
richiesta. I pacchetti di Reply, non devono mantenere alcun percorso di routing dalla
sorgente alla destinazione. Infatti, il routing inverso è costruito sulla posizione geografica
del nodo sorgente, specificata nel pacchetto di request; ciò significa che i percorsi
intrapresi da LREQ e da LREP possono essere differenti. In ultima analisi, se il nodo
sorgente non riceve alcun messaggio di LREP entro un periodo di tempo massimo fissato
a priori (max_time), attraverso una procedura di exponential backoff dovrà re-inviare il
paccheto di LREQ.
Routing of Data Packets - Dal momento che l’algoritmo non si basa sul source routing, i
pacchetti viaggiano dalla sorgente alla destinazione in base alla località. L' instradamento
effettivo di pacchetti di dati è realizzato grazie alla posizione della sorgente, della
destinazione e dei vicini. Inoltre, poiché la trasmissione è in direzione del nodo di
destinazione, il percorso trovato sarà più breve rispetto ad altri meccanismi di routing.
Maintenance of location information - Il protocollo CBLR è adatto in scenari in cui la
topologia della rete cambia molto velocemente, poiché le posizioni della sorgente e della
destinazione sono aggiornate durante ogni comunicazione, e con i pacchetti di
acknowledgment. Prima di cominciare la comunicazione vera e propria, la sorgente invia
un pacchetto di controllo alla destinazione, per segnalargli la sua nuova posizione. uesto
modo esso potrà salvarla nella sua routing table, quindi invierà un ack alla sorgente.
29
2.5 Broadcast-Based Routing Protocols
Il routing broadcast è usato frequentemente in ambito VANET, sia per la condivisione di
informazioni generiche tra veicoli (sul traffico, sul tempo, sulle condizioni stradali, per
segnalazioni e warning), sia per realizzare il processo di Route Discovery che molti
protocolli implementano. Il broadcast deve garantire che un messaggio trasmesso da un
nodo sulla rete pervenga a tutti i veicoli presenti nel suo range di copertura, tipicamente
realizzando una comunicazione multihop. [13]
Sono stati proposti diversi algoritmi di routing broadcast-based, uno dei più importanti è
senza dubbio BROADCOMM [14].
2.5.1 BROADCOMM
BROADCOMM [14] è un protocollo utilizzato per migliorare la qualità delle
comunicazioni broadcast in situazioni di emergenza su autostrade. Questo protocollo è
basato su un routing geografico, ma a differenza di altri ha una struttura gerarchica.
Struttura gerarchica - La rete è partizionata in celle e i nodi sono organizzati in due
livelli di gerarchia. Nel primo livello sono inclusi tutti i nodi di una cella. Questi nodi
possono comunicare con gli altri nodi della cella, e con i nodi esterni alla cella, purché
siano nel raggio di comunicazione del veicolo. In accordo con le specifiche del canale
fisico e del livello MAC, si ha che la dimensione ottimale di una cella è compresa tra 350
e 400 m. Il secondo livello della gerarchia è rappresentato dai riflettori di cella (Cell
Reflectors). Solitamente, appartengono a questa categoria quei i nodi che vengono a
trovarsi nel centro geografico della cella. Anche i Cell Reflector, come i normali nodi,
possono comunicare con tutti i veicoli della cella ed eventualmente con quelli esterni, ma
pur sempre presenti nel raggio di copertura del veicolo.
Per comunicazione di primo livello si intende la comunicazione tra il nodo di una cella e il
suo Cell Reflector mentre, per comunicazione di secondo livello si intende la
comunicazione tra due Cell Reflector. Un nodo viene “eletto” Cell Reflector dai membri
della cella stessa con un processo chiamato Cell Reflector Selection. Il Cell Reflector si
30
comporta come una Base Station (BS) virtuale della cella, realizzando in questo modo
un’infrastruttura di rete virtuale.
Creazione della cella - Come in molti protocolli geografici, si utilizza largamente un
servizio di beaconing di messaggi di HELLO. I nodi si scambiano questi messaggi
periodicamente, in modo da determinare la posizione, la distanza l’uno dall’altro e la
velocità. La cella viene creata dalla prima auto che non è in grado di raggiungere un'altra
auto avanti a sè. Come detto, ogni cella creata avrà una dimensione fissa a 400 m e sarà
contrassegnata da un ID, che viene trasmesso nei messaggi di HELLO.
Cell Reflection Selection - Dato che ogni nodo all’interno di una cella conosce la
posizione degli altri nodi e la dimensione della cella stessa, si è in grado di individuare
facilmente il nodo centrale, il Cell Reflector. Esso stesso, accorgendosi della sua posizione
centrale nella cella, invia un particolare messaggio di HELLO in cui comunica agli altri
nodi “io sono il cell reflector, e sarò la BS della cella”.
Broadcast Communication - In caso di emergenza il meccanismo di broadcast è
realizzato dal cell reflector. Esso invia messaggi di warning a tutti i membri della cella e al
cell reflector che segue, il quale a sua volta, invierà in broadcast tale messaggio a tutti gli
altri nodi della sua cella e così via (Figura 2.11). Se la rete è molto intasata, il cell reflector
può diventare un collo di bottiglia nel processo; in tali situazioni è consigliabile scegliere
un ulteriore cell reflector in modo da dividere bilanciare il carico del processo.
Figura 2.11 – BROADCOMM protocol : A typical broadcast communication
X – Generic node; BSi – Cell reflector
31
Conclusioni
In questa tesi è stato esplorato l’ambiente VANET, ed è stata proposta una classificazione
e l’analisi di alcuni protocolli di routing implementabili per questa tipologia di reti.
Diversi studi, in chiave comparativa e valutativa, sono stati proposti sui vari algoritmi.
Nello studio trattato in [18], si è osservato come in situazioni di alta e media densità di
traffico, sia in città che su autostrada, il protocollo DSR offra un Throughput più elevato
rispetto OLSR e ZRP [19], ma al contempo una latenza altrettanto elevata, che suggerisce
in casi pratici l’impiego di OLSR. Come evidenziato dallo studio effettuato in [9] e [19],
un protocollo geografico come GPSR è da privilegiare rispetto ad un protocollo TopologyBased nel caso in cui si desidera un tempo di risposta basso da parte della rete, a scapito di
un minor Packet Delivery Ratio (PDR). Il protocollo ROVER, come studiato in [12], è
invece consigliato quando si vuole offrire la massima QoS end-to-end, poiché garantisce in
molti casi pratici un PDR quasi pari al 100%. Il protocollo CBLR [15] offre tempi di
risposta bassi e un PDR comparabile, e in alcuni casi migliore di quello offerto da DSR,
ma ha il peso della gestione delle informazioni posizionali. Infine, il protocollo
BROADCOMM [14], col suo schema gerarchico offre una migliore QoS rispetto a
protocolli che si basano su tecniche di flooding più semplice, e si adatta particolarmente in
ambienti autostradali più che cittadini.
In conclusione, possiamo affermare che non esiste alcun protocollo di routing in grado di
garantire performance di rilievo in tutti gli scenari applicativi. Ognuno ha i suoi pro e
contro. In relazione allo scenario applicativo, il tipo di overhead introdotto (determinato
dal beaconing o dal peso della costruzione delle rotte), e le modalità di trasmissione,
incidono molto sulla scelta di un protocollo di comunicazione anziché un altro.
32
Bibliografia
[1]
R. Kumar and M. Dave, “A Comparative Study of Various Routing Protocols in
VANET”, In IJCSI, 2011
[2]
T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler and A.Qayyum et L. Viennot.
“Optimized Link State Routing Protocol”, In IEEE INMIC, 2001
[3]
M. Altayeb, I. Mayhgoub, “A Survey of Vehicular Ad hoc Networks Routing
Protocols”, In ISSR journal, 2013
[4]
D. B. Johnson, D. A. Maltz, “Dynamic Source Routing In Ad-Hoc Wireless
Networks”, in MOBICOM, 1996
[5]
Z.J. Haas, M.R. Pearlman, “The Zone Routing Protocol (ZRP) For Ad-Hoc
Networks”, In IETF Internet draft, 1997
[6]
E. Schoch, F. Kargl and M. Weber, “Communication Patterns in VANETs”, In
IEEE Communications Magazine, 2008
[7]
P. Nijkamp, A. Caragliu, C. Del Bo, “Smart Cities in Europe”, 2009
[8]
R. Karimi, N. Ithnin, S. A. Razak, S. Najafzadeh, “Non DTN Geographic Routing
Protocols for Vehicular Ad Hoc Networks”, In IJCSI, 2011
[9]
B. Karp, H.T. Kung, “GPSR : Gready Perimeter Stateless Routing for Wireless
Networks”, In MOBICOM’00, 2000
[10]
S. Allal, S.Boudjit, “Geocast Routing Protocols for VANETs: Survey and
Geometry-Driven Scheme Proposal”, In JISIS, 2013
[11]
A.Bachir, A. Benslimane, “A Multicast Protocol In Ad-Hoc Networks Inter-
Vehicle Geocast”, In IEEE, 2003
33
[12]
M. Kihl, M. Sichitiu, T. Ekeroth, and M. Rozenberg, “Reliable Geographical
Multicast Routing In Vehicular Ad-Hoc Networks”, In WWIC’07, 2007
[13]
U. Nagaraj, P.Dhamal, “Broadcasting Routing Protocols in VANET”, IISTE, 2011
[14]
M. Durresi, A. Durresi, “Emergency Broadcast Routing Protocol for Inter-Vehicle
Communication”, In IEEE, 2005
[15]
R. A. Santos, R. M. Edwards, A. Edwards, D. Belis, “A Novel Cluster-Based
Location Routing Algorithm For Inter-Vehicular Communication”, In IEEE, 2004
[16]
B. Williams, T. Camp, “Comparison of Broadcasting Techniques for Mobile Ad-
Hoc Networks”, In MOBIHOC, 2002
[17]
P. Duddalwar, A. Deshmukh, S. S. Dorle, “A Comparative Study of Routing
Protocol in Vehicular Ad Hoc Network”, In IJETAE, 2012
[18]
S. Kaur, Dr. G. S. Josan, “Performance Evaluation Of Topology Based Routing
Protocols In Vanet”, In IJERA, 2012
[19]
N. Sharma, “Performance Analysis Of GPSR Routing Protcol In VANET”, In
IJCSET, 2013
34

Elaborato Esposito Lorenzo N46-000163

Transcript

Documenti analoghi

30.10.2015 - Giorgio Roverato

Centrostiledesign di Davide Cipriani

Software di supervisione Vijeo Citect

Una rassegna di algoritmi per Data Fusion in reti

sintesi

Saffire PRO 40 scheda prodotto

saffire pro 24

K-Lite installazione pacchetto codec Scarichiamo il pacchetto dei

Le armi e gli armamenti italiani dal 1935 al 1945

Per tomba il mare

pdf