design and implementation of routing protocols with anonymity for vehicular ad-hoc networks in urban...

7/31/2019 Design and implementation of routing protocols with anonymity for vehicular ad-hoc networks in urban environm

1/98

i

PROYECTO FINAL DE MSTER

Design and implementation of routing

protocols with anonymity for vehicular ad-hoc networks in urban environments

Estudios: Mster en Ingeniera Telemtica Autor: Luis Felipe Urquiza Aguiar Directora: Mnica Aguilar Igartua Co-directora: Carolina Tripp Barba

Barcelona, Julio 2012


2/98


3/98

iii

ACKNOWLEDGEMENT This Final Master Project has been funded by Secretaria Nacional de Educacin Superior,Ciencia y Tecnologa SENESCYT of the Republic of Ecuador by contract 20100222 under theScholarship Program for Development of human talent 2010 in collaboration with NationalPolytechnic School.

RECONOCIMIENTO

Este Proyecto Final de Master ha sido financiado por la Secretaria Nacional de EducacinSuperior, Ciencia y Tecnologa SENESCYT de la Repblica del Ecuador mediante Contrato20100222, dentro del Programa de Becas para el Fortalecimiento y Desarrollo del TalentoHumano en Ciencia y Tecnologa 2010 en convenio con la Escuela Politcnica Nacional.

[1]


4/98


5/98

v

DEDICATORIA [1]

A mi mami Yolanda y mi papi William, por no dejarme de cuidar.

A mi hermano Pal y a mis hermanas Nathaly y Lisseth. Ejemplo, bondad y orgullo.

A Mnica, por sentarte das frente a m, escuchndome hablar de carritos y protocolos con elmismo inters como si del descubrimiento de un afecto adverso en un medicamento se tratara.

Te quiero.

A los que se den tiempo de leer este proyecto.


6/98


7/98

vii

AGRADECIMIENTOS

Quiero expresar un especial agradecimiento a la Doctora Mnica Aguilar, por su inigualablepaciencia y por el tiempo que ha dedicado en este proyecto desde su inicio, contribuyendo consus ideas y supervisando los resultados para que este trabajo sea cada vez mejor.

No puedo dejar de agradecer a Carolina Tripp, que me mostr siempre su buena predisposicinpara trabajar junto a m, en una idea de la cual no particip desde un principio y que sin susavances y guas me hubiera sido imposible avanzar a la velocidad necesaria.

Muy aparte de esas dos grandes personas con las que he trabajado directamente, quiero decirgracias al extenso grupo de personas del Departamento de Ingeniera Telemtica que tuvierontiempo para esclarecer dudas y asentar ideas durante mis estudios y especialmente en larealizacin de este proyecto final.

Estas lneas pueden ser escritas gracias a mi familia que confa en m ms de lo que yo mismo lohago, sin su apoyo y amor me sera imposible estar aqu. Gracias tambin a mi aa Evelia, porconfiar en m y saber que no la iba a defraudar.

Debo agradecer a Dios tan presente en cada detalle de este mundo y en mi vida a travs de mifamilia y seres queridos. A mis amigos los de toda la vida, los de sangre y los que he hecho enel camino gracias por estar ah, a mis nuevos amigos, los de Barcelona, son otra constancia delas bendiciones que Dios tiene para m; sin ellos, Barcelona slo sera esa ciudad maravillosaque es y no ese lugar donde tambin me siento en casa.

Ms que agradecer a mi pas Ecuador o a su gobierno por la oportunidad de estudiar en elextranjero (estoy agradecido con ellos), quiero dar las gracias a toda la gente que sin saberlohicieron posible esto, hablo de toda la poblacin pobre de mi patria, pues quiz dejaron derecibir algo que mejore su nivel de vida para que yo est hoy aqu. Espero poder devolver esesacrificio inconsciente que hacen por m cuando regrese.


8/98


9/98

ix

INDEX

ACKNOWLEDGEMENT ........................................................................................................... iii

RECONOCIMIENTO .................................................................................................................. iii

DEDICATORIA ........................................................................................................................... v

AGRADECIMIENTOS .............................................................................................................. vii

INDEX ......................................................................................................................................... ix

FIGURE INDEX ........................................................................................................................ xiii

RESUM ......................................................................................................................................... 1

RESUMEN .................................................................................................................................... 3

ABSTRACT .................................................................................................................................. 5

GLOSSARY .................................................................................................................................. 7

1 Introduction and Objectives .................................................................................................. 9

1.1 Objectives .................................................................................................................... 10

2 Vehicular Ad hoc Networks VANETs ................................................................................ 11

2.1 Vehicular Ad Hoc Network Architectures .................................................................. 11

2.2 VANET Characteristics ............................................................................................... 12

2.3 Vehicular applications and Internet requirements ....................................................... 132.3.1 Content downloading .......................................................................................... 13

2.3.2 P2P location significant advertising .................................................................... 13

2.3.3 P2P (driver to driver) interaction ......................................................................... 13

2.3.4 Sensing the environment ..................................................................................... 14

2.4 Network and Internet services ..................................................................................... 14

2.4.1 Routable addresses and position based addressing ............................................. 14

2.4.2 Routing in the vehicular grid ............................................................................... 14

2.4.3 Emergency routing when the grid has failed ....................................................... 15

2.5 Routing Protocols classification .................................................................................. 15

2.5.1 Topology-based Routing Protocols ..................................................................... 16

2.5.2 Geographic (Position-based) Routing ................................................................. 16

3 Ad Hoc On-demand Distance Vector: AODV .................................................................... 19

3.1 AODV Operation ........................................................................................................ 19

3.1.1 Route Discovery .................................................................................................. 19

3.1.2 Route Maintenance .............................................................................................. 203.2 Buffering in AODV ..................................................................................................... 21


10/98

Design and implementation of routing protocols for vehicular networks with privacy in urbanenvironments

x

3.3 Modifications of AODV .............................................................................................. 21

3.4 Secure Implementations of AODV ............................................................................. 21

4 Greedy Perimeter Stateless Routing for Wireless Networks: GPSR ................................... 23

4.1 GPSR Algorithm ......................................................................................................... 23

4.1.1 Greedy forwarding .............................................................................................. 23

4.1.2 Perimeter forwarding ........................................................................................... 24

4.2 GPSR Drawback ......................................................................................................... 24

4.3 GPSR Modifications ................................................................................................... 25

4.3.1 Enhanced GPSR Routing in Multi-Hop Vehicular Communications throughMovement Awareness GPSR-MA .......................................................................................... 25

4.3.2 Movement Prediction-based Routing (MOPR) Concept for Position-basedRouting in Vehicular Networks ............................................................................................... 25

4.3.3 Greedy Perimeter Stateless Routing with Lifetime: GPSR-L ............................. 26

4.3.4 Advance Greedy Forwarding: AGF .................................................................... 26

4.3.5 Improved GPSR Routing Protocol ...................................................................... 26

5 Greedy Perimeter Stateless Routing with Buffer: GPSR-B ................................................ 29

5.1 GPSR-B algorithm ...................................................................................................... 29

5.1.1 Establishing reachable neighbours ...................................................................... 29

5.1.2 Greedy Forwarding ............................................................................................. 30

5.1.3 Buffering as an alternative to Perimeter mode .................................................... 31

5.2 GPSR with buffer and building restriction .................................................................. 33

5.2.1 Building presence ................................................................................................ 33

5.2.2 GPSR-BB Building condition ............................................................................. 34

6 Crowds ................................................................................................................................ 37

6.1 Anonymity ................................................................................................................... 37

6.2 Crowds Operation ....................................................................................................... 37

6.3 Degree of Anonymity .................................................................................................. 38

6.4 Security Analysis......................................................................................................... 396.4.1 A local eavesdropper ........................................................................................... 39

6.4.2 End server ............................................................................................................ 39

6.4.3 Collaborating Crowds ......................................................................................... 39

7 Crowds over routing protocols in VANETs ........................................................................ 41

7.1 Crowds variant ............................................................................................................ 41

7.2 Equations Adaptation for VANETs ............................................................................ 42

7.3 Crowds over AODV .................................................................................................... 43

7.3.1 Crowds Flow process .......................................................................................... 43


11/98

Index

xi

7.3.2 Reply mechanism ................................................................................................ 44

7.4 Crowds over GPSR ..................................................................................................... 45

7.4.1 Crowds Flow process .......................................................................................... 45

7.4.2 Reply mechanism ................................................................................................ 46

8 SIMULATIONS AND RESULTS ...................................................................................... 49

8.1 Simulation tools .......................................................................................................... 49

8.1.1 Network simulator NCTUns 6.0 ......................................................................... 49

8.1.2 Citymob ............................................................................................................... 51

8.1.3 Logging tool ........................................................................................................ 52

8.2 Scenario description and simulation settings .............................................................. 52

8.2.1 Mobility model of the scenario ........................................................................... 52

8.2.2 Traffic Model ...................................................................................................... 538.2.3 Simulation Settings ............................................................................................. 54

8.3 Performance Evaluation of GPSR-BB ....................................................................... 54

8.3.1 Delay and Packet loses Analysis ......................................................................... 55

8.3.2 Average hops and average neighbours ................................................................ 57

8.3.3 Type error analysis .............................................................................................. 58

8.3.4 Throughput and Transmission Rate .................................................................... 61

8.4 Crowds evaluation: Single hop Scenario..................................................................... 65

8.4.1 Anonymity Analysis ............................................................................................ 65

8.4.2 Average number of hops ..................................................................................... 66

8.4.3 Losses Analysis ................................................................................................... 66

8.4.4 Delay Analysis .................................................................................................... 67

8.4.5 Final Analysis ...................................................................................................... 68

8.5 Crowds Evaluation: Real Scenario ............................................................................. 68

8.5.1 Anonymity Analysis ............................................................................................ 69

8.5.2 Average number hops .......................................................................................... 70

8.5.3 Losses Analysis ................................................................................................... 71

8.5.4 Delay Analysis .................................................................................................... 71

8.5.5 Final Analysis ...................................................................................................... 72

9 CONCLUSIONS AND FUTURE WORKS ....................................................................... 75

10 BIBLIOGRAPHY ........................................................................................................... 77

11 APPENDIX 1: Equation to determinate if two vehicles are in line-of-sight in aManhattan layout ......................................................................................................................... 81

12 APPENDIX 2: LOG FORMAT DESCRIPTION ........................................................... 83


12/98


13/98

xiii

FIGURE INDEX

Figure 2-1 Vehicular Ad Hoc Network Architecture .................................................................. 12Figure 2-2 routing in overlay ...................................................................................................... 15Figure 2-3 Taxonomy of Various Routing Protocols in VANET[9] ........................................... 16Figure 3-1 AODV messages flow ............................................................................................... 20Figure 4-1 Greedy Forwarding example [3]................................................................................ 23Figure 4-2 Greedy Forwarding Failure[3] ................................................................................... 24Figure 5-1 Hello Message in GPSR-B ....................................................................................... 29Figure 5-2 GPSR-B Forwarding scheme .................................................................................... 31Figure 5-3 Buffer logic in GPSR-B ............................................................................................. 32Figure 5-4 Schema used for sending buffered packets ................................................................ 33Figure 5-5 The Building Model example scenario [27] .............................................................. 34Figure 5-6 Parameters to determine if two vehicles are in line-of-sight in a Manhattan layout . 34Figure 5-7 GPSR-BB Forwarding scheme .................................................................................. 35Figure 5-8 Buffer logic in GPSR-BB .......................................................................................... 36Figure 6-1 Paths in a Crowds ...................................................................................................... 38Figure 7-1 Decision flow process for Crowds over AODV ........................................................ 43Figure 7-2 Feedback mechanism in AODV ................................................................................ 44Figure 7-3 Crowds over GPSR variants flow decision ............................................................... 45Figure 7-4 Crowds over GPSR flow decision ............................................................................. 46Figure 7-5 Feedback mechanism in GPSR ................................................................................. 47Figure 8-1 Simulation scenario ................................................................................................... 53

Figure 8-2 Comparison of mean delay ........................................................................................ 55Figure 8-3 Comparison of Packet loses ....................................................................................... 55Figure 8-4 Delay distribution for 15 nodes scenario ................................................................... 56Figure 8-5 Delay distribution for 30 nodes scenario ................................................................... 56Figure 8-6 Delay distribution for 60 nodes scenario ................................................................... 56Figure 8-7 Comparison of Average hops .................................................................................... 57Figure 8-8 Comparison of Average neighbours .......................................................................... 58Figure 8-9 Type Error scenario 15 nodes .................................................................................... 59Figure 8-10 Type Error scenario 30 nodes .................................................................................. 59Figure 8-11 Type error scenario 60 nodes .................................................................................. 60

Figure 8-12 Average Throughput and Transmission rate Scenario with 15 nodes ..................... 61Figure 8-13 Average Throughput and Transmission rate Scenario with 30 nodes ..................... 61Figure 8-14 Average Throughput and Transmission rate scenario 60 nodes .............................. 62Figure 8-15 Throughput vs. time Scenario with 15 nodes .......................................................... 62Figure 8-16 Transmission rate vs. time Scenario with 15 nodes ................................................. 62Figure 8-17 Throughput vs. time Scenario with 30 nodes .......................................................... 63Figure 8-18 Transmission rate vs. time Scenario with 30 nodes ................................................. 63Figure 8-19 Throughput vs. time Scenario with 60 nodes .......................................................... 64Figure 8-20 Transmission Rate vs. time Scenario with 60 nodes ............................................... 64Figure 8-21 Right guesses vs. Forwarding probability Single hop scenario ............................... 65

Figure 8-22 Sender Anonymity level vs. Forwarding probability Single hop scenario .............. 65Figure 8-23 Average number of hops vs. Forwarding probability Single hop scenario ............. 66


14/98

Design and implementation of routing protocols for vehicular networks with privacy in urbanenvironments

xiv

Figure 8-24 Losses percentage vs Forwarding probability Single hop scenario ......................... 67Figure 8-25 Average Delay vs. Forwarding probability Single hop scenario ............................. 67Figure 8-26 Sender Anonymity vs. Average hops Single hop scenario ...................................... 68Figure 8-27 Right guesses vs. Forwarding probability Real scenario ......................................... 69Figure 8-28 Sender Anonymity level vs. Forwarding probability Real scenario ....................... 69Figure 8-29 Average number of hops vs. Forwarding probability Real scenario ....................... 70Figure 8-30 Losses percentage vs. Forwarding probability Real scenario .................................. 71Figure 8-31 Average Delay vs. Forwarding probability Real scenario ....................................... 72Figure 8-32 Anonymity vs. Forwarding probability Real scenario ............................................. 72


15/98

1

RESUM A dia d'a vui les comunicacions vehiculars son una rea dinvestigaci en augment, impulsadaprincipalment per la necessitat de millorar la seguretat en la conducci per part dels fabricantsdautombils i Autoritats de Transport Pblic. Les components essencials d una xarxa decomunicacions vehicular han estat establertes sota el concepte de VANET (Vehicular Ad hocNetwork).

Existeix un munt doportunitats per el desenvolupament daplicacions civils per les VANETs.El camp dinvestigaci prioritari per els fabricants dautombils, aix com per les autoritatsgovernamentals de transport, es millorar la seguretat en la conducci; aplicacions amb capacitat

per informar als vehicles vens sobre el clima, condicions de lestat de la carretera, retencions iaccidents pode n arribat a salvar moltes vides, a ms doptimitzar els recursos destinats per aemergncies, respondre ms rpidament a crisis, entre daltres utilitats. Algunes daquestesaplicacions requereixen dels serveis de seguretat de la informaci per fomentar el seu s.

Un dels serveis de seguretat de la informaci ms important per la utilitzaci daplicacions enVANETs ser la privacitat, de manera ms explcita lanonimat en el sentit que si alg volcollaborar notificant emergncies, lestat del trnsit, el comportament dun conductor sospits,necessriament requerir enviar informaci referent a la seva posici estimada, per sense volerser rastrejat. En relaci a aquest fet, aquest projecte Final de Mster posa a prova la idonetatdun mecanisme dano nimat web anomenat Crowds [1] en protocols denrutament per xarxes adhoc vehiculars.

Una variant del Crowds especialment adaptada per VANETs que no tenen en compte el autoreenviament de paquets es porta a terme utilitzant AODV [2] (un protocol denrutament reactiubasat en topologia) i amb una variant de GPRS [3] (un dels protocols geogrfics ms coneguts)que inclou ls duna cu a (buffer) i tenint en compte la presncia dels edificis per seleccionar elsnodes que es faran servir en el segent salt.

Shan realitzat proves de simulaci utilitzant leina NCTuns 6.0 [4] en un escenari unihop permesurar lexactitud de les frmules obtingudes per Crowds sense prdues, i en un escenari realde mltiples salts per avaluar el seu acompliment, tot aix centrant-se a analitza r latacant en elcostat del servidor.

Finalment, es proporcionen resultats i treballs futurs relacionats amb millores daquestmecanisme simple i prometedor danonimat de VANETs.


16/98


17/98

3

RESUMEN Hoy en da las comunicaciones vehiculares son un rea de investigacin creciente, impulsadaprincipalmente por la necesidad de mejorar de la seguridad en la conduccin por parte de losfabricantes de automviles y las Autoridades de Transporte Pblico. Los componentesesenciales de una red para comunicaciones vehiculares se han llegado a establecer bajo elconcepto de VANET (Vehicular Ad hoc Network).

Existe un sinfn de oportunidades para el desarrollo de aplicaciones civiles para las VANETs. Elcampo de investigacin prioritario para los fabricantes de automviles, as como para lasautoridades gubernamentales de transporte es mejorar la seguridad en la conduccin;aplicaciones que pueden ser capaces de informar a los vehculos neighbours sobre el clima,condicin de la carretera, atascos y accidentes pueden llegar a salvar muchas vidas adems deoptimizar los recursos destinados a emergencias, responder ms rpidamente a crisis, entre otras

utilidades. En algunas de estas aplicaciones se requieren servicios de seguridad de lainformacin para fomentar su uso

Uno de los servicios de seguridad de la informacin ms importante para la usabilidad deaplicaciones en VANETs ser la privacidad, de manera ms explcita "anonimato" en el sentidoque si alguien quiere colaborar notificando emergencias, el estado del trfico, elcomportamiento de un conductor sospechoso, necesariamente l/ella requerir enviarinformacin referente a su posicin estimada, pero sin querer ser rastreado. Basado en estehecho, este Proyecto Final de Mster pone a prueba la idoneidad del mecanismo de anonimatoweb llamado Crowds [1] en protocolos de enrutamiento para redes ad hoc vehiculares.

Una variante de Crowds especialmente adaptado para VANETs que no tiene en cuenta el autorenvo de paquetes se lleva a cabo sobre AODV [2] (un protocolo de enrutamiento reactivobasado en topologa) y en una variante propia de GPSR [3] (uno de los protocolos geogrficosms conocidos) que incluye el uso de un buffer y toma en cuenta la presencia de edificios paraseleccionar los nodos que sern el siguiente salto.

Se realizaron pruebas de simulacin utilizando NCTuns 6.0 [4] en un escenario unihop paramedir la exactitud de las frmulas obtenidas para Crowds sin prdidas, y en un escenario real demltiples saltos para evaluar su desempeo, todo esto centrndose en analizar al atacante dellado del servidor.

Finalmente, se proporcionan los resultados y trabajos futuros relacionados con mejoras estemecanismo simple y promisorio de anonimato en VANETs.


18/98


19/98

5

ABSTRACT Nowadays vehicle communications are an increasing research area, driven by navigation safetyrequirements and by the investments of car manufacturers and Public Transport Authorities. Theessential vehicle grid components are coming into place finalizing the concept of VANET(Vehicular Ad hoc Network).

There are unlimited opportunities for civilian car to car application for VANETs. The priorityresearch field for Car Manufacturers as well as Governmental Transportation Authorities is thesafe navigation. Applications that may be able to inform the neighbouring vehicles aboutweather, road condition, traffic jams, and accidents can save many lives and also optimize theresources for emergency, improve the respond time to emergency among others importantapplication. Some of these applications will require security information services to promote itsuse.

One of the most important security information services for the application usability inVANETs will be the privacy, more explicitly Anonymity in the sense if someone wants tocollaborate notifying emergencies, traffic state, suspicious driver behaviour, necessarily he/shewill require to send for instance his/her estimated position but without being tracked. Base inthis fact, this Final Master Project tests the suitability of anonymity web mechanism calledCrowds [1] over routing protocols in vehicular Ad Hoc Networks.

A Crowds variant that does not consider self-forwarding specially adapted for VANETs isimplemented over AODV [2] (a reactive topology routing protocol) and a GPSR [3]variant (awell-known position-located rountig protocol) that includes the use of a buffer and building

aware condition to select its forwarding nodes.

Simulation tests were done using NCTuns 6.0 [4] for a single hop scenario to measure theaccuracy of the formulas obtained for ideal cases of Crowds, and evaluate its performance in areal multi hop scenario focusing in the End Server attack.

Finally, results and future works related to improve this simple and promissory anonymitymechanism over VANETs are provided.


20/98


21/98

7

GLOSSARY AGF Advance Greedy Forwarding

AODV Ad hoc On demand Distance VectorAP Access PointAU Application UnitsBER Bit Error RateBM Building ModelBS Base StationCBR Constant Bit RateCSMA/CA Carrier sense multiple access with collision avoidanceCSMA/CD Carrier Sense Multiple Access with Collision DetectionDM Downtown Model

DOS Denied Of ServiceDTN Delay Tolerance Network FIFO First In First OutFTP File Tranfer ProtocolGGSN Gateway GPRS Support NodeGLS Geo Location ServiceGNU GNU's Not UnixGPL General Public LicenseGPRS General Packet Radio ServiceGPS Global Position System

GPSR Greedy Perimeter Stateless RoutingGPSR-B Greedy Perimeter Stateless Routing with BufferGPSR-BB Greedy Perimeter Stateless Routing with Buffer and Building awareGPSR-L Greedy Perimeter Stateless Routing with LifetimeGPSR-MA Greedy Perimeter Stateless Routing Movement AwarenessGUI Graphical User InterfaceHTTP Hiper Text Transfer ProtocolID IdentifierIEEE Institute of Electrical and Electronics EngineersIP Internet Protocol

IS-AODV Intrusion detection for secure clustering and routing in Mobile Multi-hopWireless NetworksITS Intelligent Transportation SystemsJP JumpLAN Local Area Network LOS Line Of SightMAC Media Access ControlMANET Mobile Ad hoc Network MM Manhattan ModelMOPR Movement Prediction-based RoutingMS Mobile Station

MS-AODV More Stable Ad hoc On-Demand Distance Vector Routing ProtocolNCC Network Control Center


22/98

Design and implementation of routing protocols with anonymity for vehicular networks inurban environments

8

NCTUns National Chiao Tung University Network SimulatorNS2 Network Simulator 2OBS Optical Burst SwitchingOBU On-Board UnitOLS Overlay Location ServiceOSPF Open Shortest Path FirstQoS Quality of ServiceRAODV Reliable Ad hoc On-demand Distance Vector Routing ProtocolRCST Return Channel Satellite TerminalRERR Route ErrorRIP Routing Information ProtocolRREP Route ReplayRREQ Route RequestRS Relay Station

RSU RoadSide UnitRTCP Real Time Control ProtocolRTP Real Time ProtocolSAODV Secure Ad hoc On demand Distance VectorSAR Security-Aware Routing ProtocolSDP Session Description ProtocolSGSN Serving GPRS Support NodeSM Simple ModelSS Suscriber StationTAODV Trust Model Based Routing Protocol for Secure Ad Hoc Networks

TCP Transmission Control ProtocolTX TransmissionUDP User Datagram ProtocolUWB Ultra Wide BandV2V Vehicle-to-VehicleVANET Vehicular Ad hoc Network VLS Vehicle Grid Location ServiceWDM Wave Division MultiplexionWUSB Wireless Universal Serial Bus


23/98

9

1 Introduction and ObjectivesNowadays vehicle communications are increasing research area, driven by navigation safetyrequirements and by the investments of car manufacturers and Public Transport Authorities. Theessential vehicle grid components are coming into place finalizing the concept of VANET(Vehicular Ad hoc Network).

There are unlimited opportunities for civilian car to car application for VANETs. The priorityresearch field for Car Manufacturers as well as Governmental Transportation Authorities is thesafe navigation. Applications that may be able to inform the neighbouring vehicles aboutweather, road condition, traffic jams, and accidents can save many lives and also optimize theresources for emergency, improve the respond time to emergency among others importantapplications.

Also new spectrums of commercial applications are appearing simultaneously with thedevelopment of safe navigation applications such as parking occupancy, optimization of courierroutes, a proactive advertisement platform, etc. Some of both applications type will requiresecurity information services to promote its use.

One of the most important security information services for the application usability inVANETs will be the privacy, more explicitly Anonymity in the sense if someone wants tocollaborate notifying emergencies, traffic state, suspicious driver behaviour, necessarily he/shewill require to send for instance his/her estimated position but without being tracked. Forapplications as described before this Final Master Project tests the suitability of anonymity webmechanism called Crowds over routing protocols in vehicular Ad Hoc Networks.

From chapter two to four, surveys of VANETs and of two representative protocols AODV andGPSR are presented. Section five describes our developed GPSR variant named GPSR-BB forthis project in detail, that improves the GPSR technique when a local maximum is reached,based on MOPR features and adding a new one that allows GPSR-BB taking into account thepresence of buildings for choosing the next forwarding nodes.

Then, the chapters six and seven present the working criteria of Crowds and its adaptation forbeing employed over VANETs, especial emphasis receives the End Server Attack analysis andthe adaptation of the equations without considering self-forwarding for single hop case becauseit does not have practical sense in a VANET.


24/98

Design and implementation of routing protocols with anonymity for vehicular networks inurban environments

10

Chapter eight is devoted to the results of the simulations done to evaluate GPSR-BB againstAODV in different density vehicle scenarios, the accuracy of the theoretical anonymityformulas that describes Crowds when it is implemented over GPSR-BB and AODV in a singlehop scenario including the packet loses effect in the quality of services measurements. Also avery real scenario that only considers a subset of user using Crowds anonymity service isassessed showing the anonymity level and quality of service obtained.

Finally conclusions about the obtained results of our developed GPSR-BB and theimplementation of Crowds anonymity service are given; also are provided some futures worksfor improving the results shown in this project.

1.1 Objectives

The main objective of this project is the adaptation of the web anonymity technique Crowds for working with routing protocols for VANETs to test it in a real multi hop scenario.

Some additional goals to achieve the principal objective are:

To develop and implement a GPSR variant in NCTuns 6.0, in order to provide a faircomparison between a topology reactive protocol as AODV and a located-based as ourGPSR variant.

Test the behaviour of our GPSR-BB against AODV, and original GPSR in differentvehicle density scenarios.

Modify the normal workflow of GPSR-BB and AODV to support Crowds in theirrouting criteria [work supervised and co-developed by Carolina Tripp 1]

1 Carolina Tripp is a PhD student in the Telematics Engineering Department of the Technical Universityof Catalonia
http://sertel.upc.edu/users/ctripphttp://sertel.upc.edu/users/ctripphttp://sertel.upc.edu/users/ctripphttp://sertel.upc.edu/users/ctripp


25/98

11

2 Vehicular Ad hoc NetworksVANETs

Traditional traffic management systems are based on centralized infrastructures where camerasand sensors implemented along the road collect information on density and traffic state andtransmit this data to a central unit to process it and make appropriate decisions. This type of system is very costly in terms of deployment and is characterized by a long reaction time forprocessing and information.

With the rapid development of wireless communication technologies a new decentralizedarchitecture based on vehicle-to-vehicle communications (V2V) has created a very real interestthese last few years for car manufacturers, the Research and Development community andtelecom operators. Thus, a new concept was born: vehicular ad hoc network (VANET), which

theoretically is no more than a specific type of traditional mobile ad hoc networks (MANET)but the road-constrained characteristics of these networks and the high mobility of the vehicles,their unbounded power source, and the emergence of roadside wireless infrastructures makeVANETs an important research topic.

The main purpose of VANETs is to be a platform to support intelligent inter-vehiclecommunication to improve traffic safety but it is also useful for traffic management, and othersupplementary services.

2.1 Vehicular Ad Hoc Network Architectures

The VANET architecture can be divided into three domains: in-vehicle, ad-hoc andinfrastructure domain [5].

The in-vehicle domain refers to a local network inside each vehicle. Logically, it is composedof two types of units: an on-board unit (OBU) and one or more application units (AUs).

An OBU is a device placed in the vehicle with communication capabilities. On the other hand,an AU is a device executing a single or a set of applications while making use of the OBUscommunication capabilities. The AU and OBU are usually connected with a wired connection,while wireless connection is also possible (using e.g., Bluetooth, WUSB, or UWB).


26/98

Design and implementation of routing protocols with anonymity for vehicular ad-hoc networksin urban environments

12

The ad-hoc domain is a network composed of vehicles equipped with OBUs and roadside units(RSUs) that are placed stationary along the road. OBUs of different vehicles form a mobile adhoc network (MANET). OBUs and RSUs can be seen as nodes of an ad-hoc network,respectively, mobile and static nodes. An RSU can be attached to an infrastructure network,which in turn can be connected to the Internet. RSUs can also communicate to each otherdirectly or via multi-hop, and their primary role is the improvement of road safety, by executingspecial applications and by sending, receiving, or forwarding data in the ad hoc domain.

Infrastructure, whether roadside or embedded in the highway, is an important part of vehicularnetwork systems because can be used to help in the provision of security and privacy forVANET applications.

Figure 2-1 Vehicular Ad Hoc Network Architecture

2.2 VANET Characteristics

According to [6],VANETs can be distinguished from other kinds of ad hoc networks as follows:

Highly dynamic topology. Due to high speed of movement between vehicles, the topology of VANETs is always changing.

Frequently disconnected network. Due to the same reason, the connectivity of a VANET mayalso change frequently. Especially when the vehicle density is low, it has higher probability thatthe network is disconnected.

Sufficient energy and storage. A common characteristic of nodes in VANETs is that nodes havesufficient energy and computing power (including both storage and processing)

Geographical type of communication. Compared to other networks that use unicast or multicastwhere the communication end points are defined by ID or group ID, the VANETs often have anew type of communication which the data is addressed taking into account the geographicalpositions of the intermediary nodes and destination node.


27/98

Vehicular Ad hoc Networks VANETs

13

Mobility modelling and predication . Due to highly mobile node movement and dynamictopology, mobility models and predication play an important role in network protocol design forVANETs. Vehicular nodes are usually constrained by prebuilt highways, roads and streets.

Various communication environments . VANETs are usually operated in two typical

communication environments. In highway traffic scenarios is one-dimensional movement;while in city conditions it becomes much more complex. The streets in a city are often separatedby buildings, trees and other obstacles.

Hard delay constraints . In some VANET applications, the network does not require high datarates but has hard delay constraints. (Safety applications).

Interaction with on-board sensors . It is assumed that the nodes are equipped with on-boardsensors to provide information which can be used to form communication links and for routingpurposes.

2.3 Vehicular applications and Internet requirements

In [7] it is examined innovative peer to peer content sharing applications that can still operatewith intermittent connectivity and sporadic vehicular traffic and connectivity, taking intoaccount that vehicles are among the few communication nodes that can continue operating whenthe Internet goes away during urban emergency. In normal operation protocol and applicationdesign must account for easy access to the Internet.

2.3.1 Content downloadingThe drivers in the vehicular grid are interested in accessing to location dependent and awarecontent. This includes not only delay-sensitive content, but also delay-tolerant content, namelyproximity advertising and marketing segments (e.g., movie clips from the nearby theaters).Limited Roadside access points encourage the mobile users to cooperatively assemble the filethrough BitTorrent-style, P2P file sharing. Network coding could enhance P2P content sharingbut it is necessary that each AP must provide a coded stream consistent with the others, for thusthe torrent coordinator in the Internet must anticipate which APs must be served and withwhat generations.

2.3.2 P2P location significant advertisingAnother application that benefits from multiple neighbours do wnloading is Ad Torrent .

Where the access p oint feeds passing cars with randomly selected ad segments. Next, each car probabilistically disseminates the pieces using an epidemic (gossip) scheme. As a result theneighbourhood becomes populated with ads (querying the neighbourhood or soliciting network coding downloads from neighbours. The main difference from Content Download is that AdTorrent epidemically disseminates segments. The Internet plays an important role; for example,the APs will deliver the Ads that are most popular in the area. The learning must be coordinatedin the Internet servers since the individual vehicle interests are ephemeral.

2.3.3 P2P (driver to driver) interactionThere is also content that is generated and consumed entirely in the vehicle grid. A goodexample is content and messages related to navigation safety (stream accident video). This will


28/98


14

allow cars to make a better informed decision. In the intermittent situation network coding cangreatly enhance stream reliability.

2.3.4 Sensing the environmentVehicular networks are emerging as important sensor platforms for proactive urban monitoring

and for sharing and disseminating data of common interest. Each vehicle can sense one or moreevents, process sensed data, and route messages to other vehicles. Vehicles can generate muchlarger volumes of data than traditional sensor networks. They can also store the data, instead of periodically reporting it to sinks. Building upon previously proposed techniques for epidemicinformation dissemination in mobile ad hoc networks, a lightweight strategy for proactive urbanmonitoring is proposed in MobEyes [8]. The basic idea is to exploit vehicle mobility andwireless broadcast to opportunistically diffuse concise summaries (meta-data) of the data storedin cars. The data can be harvested by agents for forensic investigation. Data is discarded aftertimeout.

2.4 Network and Internet services

2.4.1 Routable addresses and position based addressingAddressing is a major challenge in the management of vehicular network mobility and animportant enabler of interconnection to and through the Internet. First, we must distinguishbetween Unique Identifier (e.g., license plate#; Vehicle-ID#), and; Routable Address (geo-coordinates, or; unique ID (typically IP address) for conventional routing, e.g. AODV). MobileIP is fine for movable nodes (like laptops), but it does not scale well in very dynamic populationlike vehicles. I t is important to maintain in the vehicle grid a unique IP address for cars, toavoid collisions in TCP connections and routing mishaps in AODV.

Af ter solving the unique IP address issue, one must focus on routable address selection. Thegoal is efficient packet delivery between cars in the vehicular grid as well as between InternetServers and mobile vehicles. With adequate architecture support, geo-routing takes a packet allthe way to the neighbour hood of the target destination. From that point, the receiver uniqueidentifies (e.g. IP address) carried in the packet header will enable correct delivery. A criticalcomponent of the geo-routing address structure is the Geo Location Service (GLS), a distributedservice that maps a vehicle name to the set of most recent geo locations. A possible solution forVANET must be capable to operate autonomously in emergency mode is to implement twoparallel versions of GLS, namely: OLS (Overlay Location Service) and VLS (Vehicle Grid

Location Service). OLS is maintained within the Internet infrastructure with overlaytechnology; VLS is maintained entirely in the vehicle grid (Figure 2-2) .

2.4.2 Routing in the vehicular gridIn general, the vehicle grid will support many routing options simultaneously, the selectiondepending on the name/address map scheme. The prominent scheme, especially to remotedestinations, will be geo-routing. Yet geo-routing in vehicular grids poses research challenges.The first issue is vulnerability to dead end traps. Vehicle grids are full of such traps.

The presence of the infrastructure has again an important impact on urban routing. In mostcases, one must find a route to the closest Access Point, to connect to the Internet, or to remotevehicles. In a city with advanced wireless infrastructure deployment, it will take only a few hops


29/98


15

to reach the nearest AP, in day traffic conditions. Routing over the infrastructure instead of theVehicular Grid to reach remote vehicles will be the norm.

Offering an infrastructure that is instantly available to support vehicles is itself a challenge.Roadside Access Points must be placed in special locations. Traffic lights are perfectly

positioned to act as traffic routers. They already form a traffic grid; are located where traffic ismost intense and are equipped with power and directly maintained by local municipalities.

Figure 2-2 routing in overlay

2.4.3 Emergency routing when the grid has failed

In major disasters like earthquakes or hurricane, power lines will be down, communicationsinfrastructure is either out of power or heavily congested. This is when the VANET steps in asthe ultimate Emergency Network. The VANET continues to run in spite of natural disasters, andis able to configure itself and route information using the available resources. Queries are sentout to the VANET by Emergency Management Agencies to gather information about vehicletraffic in the city and also about road conditions. The queries are high priority and are instantlyrelayed by intermediate vehicles to the entire city. Within seconds, detailed congestion mapsare created and optimal routes are planned and forwarded to the emergency vehicles already onroute. If necessary, evacuation routes are configured to lead unfortunate motorists to safety.

The VANET plays a pivotal role in the recovery as it is always on the ready. VANET routing

protocols are designed to work well even without infrastructure. No extra protocols must bebootstrapped for P2P operation.

2.5 Routing Protocols classification

In [9] there is a taxonomy of the VANET routing protocols. As shown in Figure 2-3, there aretwo categories of routing protocols: topology-based and geographic routing. Topology-basedrouting uses the information about links that exist in the network to perform packet forwarding.Geographic routing uses neighbouring location information to perform packet forwarding.


30/98


16

Figure 2-3 Taxonomy of Various Routing Protocols in VANET [9]

2.5.1 Topology-based Routing ProtocolsThese routing protocols use links information that exists in the network to perform packetforwarding. They can be divided into proactive (table-driven) and reactive (on-demand)routing. But in fact the two options construct a routing table.

2.5.1.1 Proactive (table-driven) Proactive routing carries the distinct feature: the routing information such as the nextforwarding hop is maintained in the background regardless of communication requests. Controlpackets are constantly broadcast and flooded among nodes to maintain the paths or the link states between any pair of nodes even though some of paths are never used.

2.5.1.2 Reactive (On Demand) Reactive routing opens a route only when it is necessary for a node to communicate withanother node. It maintains only the routes that are currently in use, thereby reducing the burdenon the network. Reactive routings typically have a route discovery phase where query packetsare flooded into the network in search of a path. The phase completes when a route is found.

2.5.2 Geographic (Position-based) RoutingIn geographic (position-based) routing, the forwarding decision by a node is primarily made

based on the position of a packets destination and the posi tion of the nodes one -hopneighbours. The position of the nodes one -hop neighbours is obtained by the beacons sent

periodically with random jitter. Nodes that are within a nodes radio range will becomeneighbours of the node. Geographic routing assumes each node knows its location, and thesending node knows the receiving nodes location by the increasing popularity of GlobalPosition System (GPS) unit.

2.5.2.1 Non-Delay Tolerance Network Non- Overlay The fundamental principle in the greedy approach is that a node forwards its packet to its

neighbour that is closest to the destination. The forwarding strategy can fail if no neighbour iscloser to the destination than the node itself.


31/98


17

2.5.2.2 Non-Delay Tolerance Network - Overlay An overlay routing has the characteristic that the routing protocol operates on a set of representative nodes overlaid on top of the existing network. In the urban environment,decisions are made at junctions as these are the places where packets make turns onto a differentroad segment.

2.5.2.3 Non-Delay Tolerance Network - Hybrid There are protocols that use greedy forwarding but also exploit topology knowledge acquired byoverlay network or heuristic.

2.5.2.4 Delay Tolerance Network There are vehicular routing protocols designed for VANETs which are treated as a form of Delay Tolerant Network (DTN). Since nodes are highly mobile, in this type of a network, theysuffer from frequent disconnections. To overcome this, packet delivery is augmented byallowing nodes to store the packets when there is no contact with other nodes.

2.5.2.5 Hybrid It is a combination of non-DTN and DTN approach that includes the greedy mode, and the DTNmode. It switches from non-DTN mode to DTN mode by estimating the connectivity of thenetwork.

It has been included a briefly summary performed by Lee, also in [9] with the different featuresof the most well-known protocols for VANETs.

RoutingProtocol

Type Sub Types Overhead Mobility Model Propagation Model

FSR Topology based Proactive All l ink s ta tes I DM on Ma nha tta n

Grid

Unknown

AODV Topology based Reactive Path states IDM on ManhattanGrid, Videlio, MTS

Road blocking,Probabilisticshadowing

AODV+PGB Topology based Reactive Path states MTS Probabilisticshadowing

DSR Topology based Reactive Path states IDM on ManhattanGrid, Videlio

Road blocking

TORA Topology based Reactive Path states IDM on ManhattanGrid

Unknown

GPSR Position based Non DTN, Non Overlay

Beacons MTS Probabilisticshadowing

GPSR+AGF Posi tion based Non DTN, Non Overlay

Beacons MTS Probabilisticshadowing

PRBDV Position based Non DTN, Non Overlay

Beacons a nd pathstates

Unknown Unknown

GRANT Position based Non DTN, Non Overlay

Two hop beacons Static trace from auniform distribution

Road blocking

GPCR Position based Non DTN, Non Overlay

Beacons VanetMobisim Road blocking

GpsrJ+ Position based Non DTN,Overlay


CAR Position based Non DTN,Overlay

Path states a ndbeacons

MTS Probabilisticshadowing

GSR Position based Non DTN,Overlay

Beacons Videlio, M Gridmoblity

Road blocking

ASTAR Position based Non DTN,Overlay

Beacons M Grid mobility Road blocking


32/98


18

Table 2-1 Summary of VANET routing protocols [9]

In next chapters AODV, GPSR and a novel modification of GPSR are described in detail.

STBR Position based Non DTN,Overlay

Beacons Unknown Unknown

GyTAR Position based Non DTN,Overlay

Beacons Proprietory Free space

LOUVRE Position based Non DTN,Overlay


CBF Position based Non DTN, Non Beacon

Data boradcast Random way point Two Ray groundpropagation model

TOGO Position based Non DTN, Hybrid Beacons and databroadcast

VanetMobisim Road blocking

VADD Position based DTN Beacons Unknown UnknownGeOpps Position based DTN Beacons MTS NoneGeoDTN+Nav

Position based Hybrid Beacons VanetMobisim Road blocking


33/98

19

3 Ad Hoc On -demand DistanceVector: AODV

AODV is most widely used protocol for MANET, and its algorithm has been the basis forseveral implementations of routing protocols in VANET. AODV has been evaluated in differentscenarios for VANETs [10][11][12] which have demonstrated that its performance is similar toproactive and geographic routing protocols and even better in high density scenarios.

AODV is a reactive protocol, variation of the Bellman-Ford distant vector algorithm, adapted towork in a mobile environment. It determines a route to a destination only when a node wants tosend a packet. Routes are maintained as long as they are needed by the source while there isconnectivity between nodes in the path. Sequence numbers ensure the freshness of routes andguarantee the loop-free routing [2].

3.1 AODV Operation

An AODV node maintains a routing table that holds information like: destination address, next-hop address hop count, destination sequence and lifetime. In order to keep updated the routingtable, the AODV protocol has two tasks well defined; the first one is the Route Discovery andthe second task is the Route Maintenance.

3.1.1 Route DiscoveryThe Route Discovery is used when it does not exist a route to a certain destination, it could bebecause this node has never had to send any data flow to that destination or the route hasexpired and its freshness is not warranty. For discovering a route AODV uses the following twomessages:

3.1.1.1 Route Request The AODV Route Request RREQ is a broadcast message sent by the source, which needs toestablish a data link with a destination; this broadcast message is received by the nodes aroundthe source, and these rebroadcast the message until reach the destination node or respond to thesource with the new route.

A RREQ message includes the source nodes IP address, destination nodes IP address, sourcenodes sequence number, destination nodes sequence number, and broadcast ID number. Eachtime a source node uses RREQ, the broadcast ID number will be incremented.


34/98


20

Depending on the information carried by the RREQ message, nodes receiving this packetupdate their information for the source node and set up backwards pointers to the source node inthe routing tables. Nodes keep track of the RREQ's source IP address and broadcast ID. If theyreceive a RREQ which they have already processed, they discard the RREQ and do not forwardit. To prevent unnecessary network-wide dissemination of RREQs, the originating node couldsetup a maximum number of hops to build a route.

3.1.1.2 Route Replay A Route Replay message can be sent by the destination node or by an intermediate node. Anintermediate node may send RREP only if it has a route to the destination with correspondingsequence number greater than or equal to that contained in the RREQ (the most recent sequencenumber for the destination of which the source node is aware).

RREP message is unicasted back from the destination to the source, hence nodes set up forwardnodes to the destination. The source updates its routing information in the routing table for thatdestination if receives a RREP message that has a greater sequence number or contains the samesequence or contains the same sequence number with a smaller hop count. Also a RREPmessage includes the time for which nodes receiving the RREP consider the route to be validinto the Lifetime field.

3.1.2 Route MaintenanceA route is maintained while the communication between source and destination node, after thata timer is triggered to delete the route of the routing tables. The route maintenance task useshello and route error messages for keeping updated the routing tables.

3.1.2.1 Hello Message

The Hello Message has the purpose to advertise periodically the node`s presence in the coveragerange of its neighbours to preserve a route. If an intermediate does not receive a Hello Messageof its Next Hop, it assumes that there is not more connectivity and a local link fail has occurred.It is not necessary that a node send Hello Message if its routing table is empty. This approachavoids an unnecessary flood of traffic.

Figure 3-1 AODV messages flow


35/98

AODV: Ad Hoc On-demand Distance Vector

21

3.1.2.2 Route Error message The Route Error message is sent when a node in a route has detected a link local breakage andafter that a local repair mechanism has failed, the node propagates a route error RERRmessage to the source node to inform it of the now unreachable destination. After receivingthe RERR, if the source node still desires the route, it can reinitiate route discovery. Figure3-1 summarizes the AODV message behavior:

3.2 Buffering in AODV

The AODV protocol uses a buffer in two different situations. The first one, when a node has tosend a packet to destination for which it does not have a route. In this case the node shouldbuffer the packets until a route discovery process obtain a fresh route to the destination or thebuffered packets will be discard after the maximum number of RREQ went sent and a timerexpires.

A second buffer, called a local buffer is used when a link local breakage occurs and basically itstores the packet waiting a RREP from the destination while a timer does not expires. As a localrepair must be quick, only one RREQ message is sent.

3.3 Modifications of AODV

In the survey done in [13], a classification of AODV variants was presented based on Alternatebackup route, Routing techniques or energy consumption. The first two variants look forincrease the reliability of the protocol using all the paths available at the same time or using the

path with the best stability. The last modification time is intended to control the powertransmission to save energy or calculate the best route knowing the energy spent for using eachroute.

3.4 Secure Implementations of AODV

The modifications of AODV explained before do not consider security issues: In [14] acomparative study of secure AODV variants based on security services was done. According tothis comparative study none protocol provides all the security services, more over none of thereviewed protocols in the study provide anonymity. The Table 3-1s hows the results of the study.

Table 3-1 Comparison study based on Basic Security Services over AODV [12]

PerformanceParameters type SAODV A-SAODV MS-AODV RAODV TAODV ISAODV SARCentral trustauthority

CArequired

CArequired

NOTrequired

NOTrequired

NOTrequired

NOTrequired

CA/KDCrequired

Authentication Yes Yes No Yes Yes Yes YesConfidentiality No No No No No Yes YesIntegrity Yes Yes No Yes Yes Yes YesNonrepudiation Yes Yes No Yes Yes Yes YesAvailability No No No No No No No


36/98


22

It has been observed none of secure routing protocol provides the availability service. Twoprotocols ISAODV [15] and SAR provide the Confidentiality, Integrity, Authentications, Nonrepudiation. Only one protocol MSAODV [16] does not provide any basic security services.

[15 20][21]


37/98

23

4 Greedy Perimeter StatelessRouting for Wireless Networks:

GPSR Greedy Perimeter Stateless Routing (GPSR) for Wireless Networks [3], is a well-knowngeographical routing protocol specially designed for VANETs. It is the base for novel protocolsthat intend to improve GPSR performance results, changing the requirements to forward packetsor the logic to find a neighbour node, but always keeping the principle of forwarding the packetto the closest node to the destination hop-by-hop.

4.1 GPSR Algorithm

GPSR, uses two different techniques for forwarding packets: greedy forwarding, which is usedby default, and perimeter forwarding, which is used in the regions where greedy forwardingcannot be used.

4.1.1 Greedy forwardingWith GPSR, packets are marked by their originator with their destinations' locations. As aresult, a forwarding node can make a locally optimal (the neighbour geographically closest tothe packet's destination), greedy choice in choosing a packet's Next Hop.

Figure 4-1 Greedy Forwarding example [3]


38/98

Design and implementation of routing protocols with anonymity for vehicular Ad-hoc networksin urban environments

24

Due to the nodes require knowing their neighbours' positions, periodically neighbours` position(a simple beaconing algorithm) is needed, each node transmits a beacon to the broadcast MACaddress, containing only its own identifier (e.g., IP address) and position. This beaconingmechanism does represent proactive routing protocol traffic. To minimize the cost of beaconing,GPSR piggybacks the local sending node's position on all data packets it forwards, and runs all

nodes' network interfaces in promiscuous mode, so that each station receives a copy of allpackets for all stations within radio range.

GPSR's beacon mechanism could be fully reactive by having nodes solicit beacons with abroadcast "neighbour request" only when they have data traffic to forward.

4.1.2 Perimeter forwardingThere are topologies in which the only route to a destination requires a packet move temporarilyfarther in geometric distance from the destination, An example is shown in Figure 4-2, in whichnode x does not have a closer node to the destination (D) than itself, In these cases perimeterforwarding mode is used to avoid discarding the packets and try to reach the destination.

Figure 4-2 Greedy Forwarding Failure [3]

GPSR seeks to exploit these cycle-traversing properties of known right-hand rule to routearound voids. In Figure 4-2, traversing the cycle (x wvDzyx) by the right-handrule amounts to navigating around the pictured void, specifically, to nodes closer to thedestination than x (in this case, including the destination itself, D). The sequence of edgestraversed by the right-hand rule is called perimeter.

The state accumulated in these packets is cached by nodes, which recover from local maxima in

greedy forwarding by routing to a node on a cached perimeter closer to the destination. Thisapproach requires a heuristic, the no-crossing heuristic, to force the right-hand rule to findperimeters that enclose voids in regions where edges of the graph cross.

4.2 GPSR Drawback

The main problem of GPSR is the use of outdate information to select the next forwarding node.It is possible to find inconsistencies in the neighbour tables or in destination nodes locationwritten in the packet.

The neighbour table problem is to select a node which is out of range, resulting in packet loss.This happen often because often the nearest neighbour to the destination node is also the farthest


39/98

Greedy Perimeter Stateless Routing for Wireless Networks: GPSR

25

neighbour. Due to destination nodes location included in the packet header never is updated byany forwarding node; packets with high delay will never arrive to the destination node and willget lost in a location where the destination is no longer.

According to experiments performed in [12], where the exactly information of best located next

forwarding node and the destination node`s position are available for all nodes. Theperformance increase around of 16% by an accurate selection of the Next Hop but the majorimprovement occurs when the exact location of the destination node is kwon; reached anenhancement of the 56% in the delivery rate.

4.3 GPSR Modifications

As was said, at present GPSR is the based for novel position-based protocols. There are manyvariants for GPSR that try to improve its performance applying the optimizations describedinside GPSR article, or adding new restrictions to do an accurate forwarding decision. All theenhancements are related to beaconing mechanism or developments more efficient ways thanPerimeter to deal with greedy failure.

Following, is found a summary of the more representative modifications of GPSR

4.3.1 Enhanced GPSR Routing in Multi-Hop VehicularCommunications through Movement Awareness GPSR-MA

In GPSR, it is assumed the packet source can determine the coordinates of the destination nodeusing a location lookup service. A bigger problem is related to the accuracy of positions. InGPSR-MA [22] each node can determine the neighbour s position and adjust the destination

coordinates carried inside every transmitted data packet accordingly

GPSR-MA extends the set of parameters used for taking a routing decision with the inclusion of the speed and the direction of movement of the vehicle. Speed is an absolute value measured inm/s, while movement direction is an absolute angle between nodes speed vector and thesegment connecting it to the destination. Nodes include such parameters into periodic locationupdate packets, an overhead of two octets added to the GPSR header.

GPSR-MA uses the a metric calculated as an combination of speed (s) and direction ( )explained before, and the distance (d) between the Next Hop and the destination with atolerance range computed as a percentage of the coverage range.

4-1

With speed , distance, movement are weights associated with each function. The route with thebiggest total weight is selected as Next Hop

4.3.2 Movement Prediction-based Routing (MOPR) Concept forPosition-based Routing in Vehicular Networks

MOPR [23] implements an estimation of connectivity called link stability to select the nextforwarding node. The link stability is defined as:

[ ] [ ] 4-2


40/98


26

The links lifetime is defined as a period in which a neighbour is into the coverage range of thenode and is a constant value that depends of the used routing protocol. The neighbour with thegreater Link Stability is selected.

In MOPR over GPSR when a vehicle wants to send or forward data, it first estimates the future

geographic location after a duration time T in seconds for each neighbour. Then, it selects asNext Hop the closest neighbour to the destination which has not a future location out of itscommunication rage after the time T. By doing that, MOPR-GPSR avoids the case when a NextHop goes out of the communication range during a data packet transmission. Thus, decreasesthe data loss and link-layer and transport retransmissions, which increases the routingperformances

4.3.3 Greedy Perimeter Stateless Routing with Lifetime: GPSR-LGPSR-L [24] uses the lifetime of a neighbour s link as the metric to choose the next forwardingnode, without the stability concept described in MOPR. To compute the lifetime of a link it isnecessary that Hello Messages include position, speed and direction and a time stamp.

The Next Hop is selected from the nodes that have a lifetime greater than the propagation andtransmission delay of a packet.

4.3.4 Advance Greedy Forwarding: AGFIn Advanced Greedy Forwarding over GPSR presented in [12] nodes send Hello Messages withspeed and direction information periodically and information about the packet travel time isalso added in the header.

A node receiving a packet checks if the destination is listed in its neighbour table and the entryis still valid, taking into account the packet travel time and the nodes and the destinationsvelocity vectors. If the destination is in the neighbour table, but the new position estimation tellsthat the destination is most likely already out of the range, then the node closest to the newposition of the destination is chosen as a Next Hop.

If no destination is found in the neighbour table the node consults the packet travel time andestimates whether it may potentially reach the position of the destination recorded in the packetheader within one hop, taking into account a distance potentially traveled by the destinationnode within the packet travel time. If yes, a non-propagating broadcast (RREQ) is sent around,with the search for the destination. If no answer is received (either from the destination, or thenode that has the destination in its table and is closer to the destination than the current node),

then the next closest to the destination node is chosen, and the process repeats until the packetreaches the destination node.

4.3.5 Improved GPSR Routing ProtocolThe proposal of Improved GPSR [25] is that nodes use Hello Messages to inform of theirposition, speed and number of neighbouring nodes . With this information each nodecan predict the direction of the node comparing two consecutive position received by aneighbour.

The next forwarding node is chosen from the neighbours that are traveling towards destinationnode, and is the node that has the minimum value of shown in equation 4-3.


41/98

Greedy Perimeter Stateless Routing for Wireless Networks: GPSR

27

[ ] 4-3

If there are two neighbours with the minimum , the slower node is selected because thecommunication link can be maintained relatively longer.


42/98


43/98

29

5 Greedy Perimeter StatelessRouting with Buffer: GPSR -B

The best GPSR improvement will be achieved applying mechanisms for keeping updated thelocation of nodes neighbour and the destination node`s position through time. The modificationof the GPSR proposed here only takes into account to save precise neighbour s location becausethe position of the destination node is fixed in the scenarios where this protocol and itsvariations will be tested, and to avoid Perimeter mode, instead it is proposed a buffer solution.

Under GPSR modifications section, widely used four variants were described briefly. All foursolutions includes very similar approaches to determinate the location of their neighbours butchoose the next forwarding node in different way. Two of them choose the closest neighbour todestination, and the other two protocols compute new metrics based on speed, distance,

direction among others.

5.1 GPSR-B algorithm

GPSR with Buffer, as all the variants of GPSR, can be split in two mechanisms: the first onerelated to determinate if a neighbour in the neighbour list is still reachable by the node and thesecond mechanism is about how select to the next forwarding node.

5.1.1 Establishing reachable neighboursAs mentioned in the introduction of this chapter, the accurate information about the actualposition of a neighbour has a strong impact in the performance of GPSR, because knowing it,the node is aware of which neighbours are reliable as next forwarding nodes avoiding sendingpackets to an unreachable node.

For developing GPSR with buffer (called GPSR-B), it is used Hello Messages betweenneighbours similar to those proposed in [12], [22], [25], [26] following is described each fieldthat the Hello Message, showed in the Figure 5-1 Hello Message in GPSR-B, it must contain.

ID(32bits)

PositionLatitude

(20 bits)

PositionLongitude

(20 bits)

Vx8bits

Vy8bits

TimeStamp

16bits

Figure 5-1 Hello Message in GPSR-B


44/98


30

ID node: This field has 4 bytes and identifies the node. Position: The position field uses 5 bytes to transmit the geographical coordinates of the

node; 20 for latitude and 20 bits for longitude. The 20 bits are distributed as follows:o 8 bits for grades including the direction (North, South, East or West)o 6 bits for minutes; ando 6 bits for seconds.

Velocity vector : It uses 2 bytes, one byte for the speed in the x axis field and one for thespeed in y axis. Each node could compute its velocity vector storing two consecutive

positions. The speed in each axis is encoded using twos complement notation forexpressing negative values in the vector.

TimeStamp This field uses 2 bytes to send information of hour, minutes and seconds. Asusual in the location based protocols it is assumed that all the clocks are synchronized.

The Hello Message could be sent followed as accurately as desired, but huge amount of signaling traffic may produce undesired congestion. However, tests about this parameter were

performed varying the hello interval. T hey confirm that the performance of the protocol isgood with a hello interval set in 1 second (as is usual in other protocols like AODV), a short orlarge interval could be used when a high (highways) or slow (traffic jams) node mobility aredetected.

GPSR-B establishes which nodes are reachable in the same way that MOPR over GPSR does,but with a little difference: instead of computing a future position of each neighbour and verifyif the distance between the node and its neighbours is greater than the coverage range, GPSR-Bestimates the current neighbour s position but restricts the maximum distance between the nodeand its neighbours to 95% of the coverage range. GPSR-B adopts this strategy because theestimation of the position is more exact when it is shorter-term estimation.

5.1.2 Greedy ForwardingFor taking the forwarding decision, GPSR-B uses the same principle described in originalGPSR and also used in MOPR over GPSR. It is to choose the closest neighbour to destinationnode`s position. It is important to remark that GPSR does not include any modification in theformat of data packets and only includes the position of the destination with a 5 bytes fieldnecessary to select the Next Hop. Further fields or techniques could be implemented tomaintain updated the destination nodes location. As mentioned in the introduction this firstintended of GPSR-B does not include any improvement because the scenarios used in thisproject does not consider mobile destinations.

The Figure 5-2 shows the pseudo code describing the whole process (validates neighbours andchooses Next Hop). The do while loop looks for the first node in the neighbour list that is in thecoverage range. If there is no neighbour in the coverage range, the last node in the list isselected as candidate for doing the rest of comparisons. Then the neighbour candidate iscompared with the rest of the nodes in the list within coverage range, if one of these nodes iscloser to the destination than the current candidate, therefore there is a new neighbour candidate.

At the end of scrolling the list, the candidate node is the Next Forwarding Node. Only in casethat there is no neighbour in coverage range of the chosen node is no closer to the destinationthan the sender node (or current forwarding node) the packets are stored in the buffer-


45/98

Greedy Perimeter Stateless Routing with Buffer: GPSR-B

31

/*Searching the first neighbour in the coverage range */ do

{ selected = getIdNodeByPosition ( temp ); Danterior =Distance ( selected , destination ); temp ++;

if( temp==neighbours ) break; } while ( Distance ( selected , node )> 240 );

/*Looking for a closest neighbour to the destination node */ while ( temp != neighbours )

{ currentNode = nei_list . getIdNodeByPosition ( temp ); if ( Distance ( currentNode , node )< 240 ) { DcurrentNode =Distance ( currentNode , destination );

if ( DcurrentNode < Danterior ) {

selected = currentNode ; }

} }

if ( Distance ( selected , destination )< Distance ( node , destination )&&Distance ( node , selected ) < 240)

{SendByNextHop(selected);

}

Figure 5-2 GPSR-B Forwarding scheme

5.1.3 Buffering as an alternative to Perimeter modeOne important drawback of GPSR is the implementation of Perimeter forwarding, intended torecover from a local maximum, but is not clear when the algorithm comes back to work ingreedy forwarding. Also mobility can induce routing loops for face routing (Perimeter mode)according to [6]. In [7] it is mentioned that schemes to prevent, recover from traps are moreefficiently than planarization.

In order to avoid the problems of Perimeter forwarding, GPSR-B stores packets in a bufferwhen a local maximum happens. This is when there is no neighbour that meets all therequirements. GPSR-B tries to send the packets in the buffer periodically, seeking a neighbourthat meets for next forwarding node requirements. The length of the period could be setdepending of the mobility of nodes, stability of the neighbours or others criteria. If a packet is

not sent after a time threshold, the packet will be discarded. Also in order to provide a bufferwith a reactive behaviour, the buffer tries to send the stored packets when a Hello Message isreceived, because at this time at least one neighbour may be a possible next forwarding node.

In the developed code for this project we consider a very short period of 0,5 seconds to try tosend the buffered packets, of course the problem with this strategy is only the very high numberof operations required, but it could not be consider a major issue because VANET nodes areconsidered free of energy consumption problems and limited computation power problems.

The pseudo code used for this part of the development is presented in Figure 5-3. As the readercan see, the two conditions required for the Next Hop are validated (coverage range and

distance to the destination). If one of the two conditions is not satisfied, the packets are sent to a


46/98


32

buffer for this destination, if this buffer is full packets are dropped. The two conditions arevalidated independently for statistical purposes.

//Send to the buffer because all the nodes are out of range; if ( NodeDistance ( selected , node )> 240 )

{ if (!buffer. ifExist ( dst_ip )) {

buffer . insert ( dst_ip , CurrentTime ()); if ( buffer . attachPkt ( dst_ip , pkt ) < 0 ) { //Buffer full

freePacket ( pkt ); }

} else {

if ( ctrl_table . attachPkt ( dst_ip , pkt ) < 0 ) freePacket ( pkt );

}

}//Send to the buffer because there are neighbours in coverage rangebut there is no one nearer than the current node ; if ( NodeDistance ( selected , destination )> NodeDistance ( node , destination ))

{ ToBuffer

}

Figure 5-3 Buffer logic in GPSR-B

It is important to notice that the implementation of the buffer may be considered a carry andforwarding strategy, very used in intersection-based routing protocols. Also the buffer

implemented allows the protocol to retry to send packets which were not sent by detectedproblems in layer two and to switch constantly between the two modes operation becauseGPSR-B works always in greedy forwarding mode.

The buffer searches a next forwarding node for each destination that is in the bufferperiodically; and for each destination the packets a

design and implementation of routing protocols with anonymity for vehicular ad-hoc networks in urban...

Documents