Evaluarea tehnologiilor de comunicații VANET pentru [622758]

Universitatea Politehnica București
Facultatea de Transporturi
Departamentul Electronică și Telecomenzi în Transporturi

LUCRARE DE LICENȚĂ

Evaluarea tehnologiilor de comunicații VANET pentru
transmiterea mesajelor de siguranță rutieră

Coordonator științific:
S.l. dr. ing. Șoriga Ștefan -Gabriel
Absolvent: [anonimizat]
2016

1
Cuprins

Listă de figuri ……………………………………………………………………………………………………………………………2
Listă cu tabele ………………………………………………………………………………………………………………………….3
Listă de acronime ……………………………………………………………………………………………………………………..4
1. Comunicații folosite în rețelele VANET …………………………………………………………………………………6
1.1. Protocoale de comunicații VANET …………………………………………………………………………….. 10
1.2. Standarde definite în Statele Unite ale Americii ………………………………………………………….. 15
1.3. Standarde definite în Europa ……………………………………………………………………………………. 19
1.4. Reglementări la nivel european ………………………………………………………………………………… 22
2. Simularea rețelelor VANET ………………………………………………………………………………………………. 27
2.1. Simulatorul de rețea de sine stătător ………………………………………………………………………… 27
2.2. Simulatorul de rețea conectat cu simulatorul de trafic ………………………………………………… 28
2.3. Aplicații inteligente de siguranță a vehiculelor ……………………………………………………………. 30
2.3.1. Avertizarea post -coliziune …………………………………………………………………………………. 32
2.4. Instrumente de simulare a comunicațiilor în rețele VANET ………………………………………….. 33
2.4.1. VEINS ……………………………………………………………………………………………………………… 33
2.4.2. SUMO …………………………………………………………………………………………………………….. 36
2.4.3. OMNeT++ ……………………………………………………………………………………………………….. 42
2.4.4. OpenStreetMap ……………………………………………………………………………………………….. 45
2.4.5. TraCI ………………………………………………………………………………………………………………. 47
2.4.6. MiXiM ( Simulatorul Mixt) …………………………………………………………………………………. 48
3. Evaluarea tehnologiilor de comunicații VANET ………………………………………………………………….. 50
3.1. Introducere ……………………………………………………………………………………………………………. 50
3.1.1. Beaconing ……………………………………………………………………………………………………….. 51
3.2. Scenariul simulat …………………………………………………………………………………………………….. 52
3.2.1. Simulatorul de trafic …………………………………………………………………………………………. 52
3.2.2. Simulatorul de rețea ………………………………………………………………………………………… 54
3.3. Rezultatul simulărilor ………………………………………………………………………………………………. 55
3.4. Concluzii ………………………………………………………………………………………………………………… 61
4. Bibliografie ……………………………………………………………………………………………………………………. 62
5. Anexă ……………………………………………………………………………………………………………………………. 67

2
Listă de figuri

Figura 1.1 Arhitectura de ansamblu a unei rețele VANET ………………………………………………… 6
Figura 1.2 Arhitectura de referință C2C -CC …………………………………………………………………… 9
Figura 1.3 Lățimea de bandă alocată standardului DSRC în SUA ……………………………………. 16
Figura 1.4 Stiva de protocoale WAVE în SUA ……………………………………………………………… 16
Figura 1.5 Banda de frecvențe alocată în Europa pentru DSRC ………………………………………. 20
Figura 1.6 Arhitectura protocoalelor folosite de sistemul de comunicații C2C -CC …………….. 20
Figura 1.7 Stiva de protocoale C2C -CC ……………………………………………………………………….. 21
Figura 2.1 Tipuri de modele de mobilitate ……………………………………………………………………. 27
Figura 2.2 Simulatorul de rețea OMNeT++ conectat cu simulatorul de trafic SUMO folosind
TraCI ……………………………………………………………………………………………………………………….. 29
Figura 2.3 Implementarea Veins în simulatoar e …………………………………………………………….. 34
Figura 2.4 Diferite granulatii de simlari; de la stanga la dreapta: macroscopic, microscopic,
sub-microscopic (iar in cerc: mesoscopic) …………………………………………………………………….. 37
Figura 2.5 Intersecție în SUMO …………………………………………………………………………………… 41
Figura 2.6 Compunerea modulelor în OMNeT++ ………………………………………………………….. 44
Figura 3.1 Zonă a Bucureștiului în SUMO ……………………………………………………………………. 53
Figura 3.2 Simulatorul de rețea OMNeT++ în cadrul unei simulări …………………………………. 54
Figura 3.2 Harta intersecției ………………………………………………………………………………………… 56
Figura 3.4 Totalul pachetelor pierdute pentru 30 de vehicule ………………………………………….. 56
Figura 3.5 Totalul pachetelor pierdute pentru 40 de vehicule ………………………………………….. 57
Figura 3.6 Totalul pachetelor pierdute pentru 50 de vehicule ………………………………………….. 57
Figura 3.6 Harta drum drept ……………………………………………………………………………………….. 58
Figura 3.7 Totalul pachetelor trimise ……………………………………………………………………………. 59
Figura 3.8 Totalul pachetelor puse în așteptare ……………………………………………………………… 59
Figura 3.9 Totalul pachetelor recepționate broadcast ……………………………………………………… 60

3
Listă cu tabele

Tabelul 1.1 Servicii definite pentru mediul de 5 GHz …………………………………………………….. 13
Tabelul 1.2 Comparație standarde IEEE 802.11a vs IEEE 802.11p …………………………………. 17
Tabelul 1.3 Comparație DSRC în banda de 915 MHz vs 5.9 GHz ………………………………….. 18
Tabelul 2.1 Aplicații de siguranță publică …………………………………………………………………….. 32
Tabelul 2.2 Aplicații incluse în SUMO ………………………………………………………………………… 40
Tabelul 3.1 Parametrii de simulare ………………………………………………………………………………. 55

4
Listă de acronime

AIFS Arbitration Interframe Space
C2CC Car to Car Communication
CAN Controller Area Network
CCA Clear Channel Assessment
CCH Control Channel
CSMA/CA Carrier -Sense Multiple Access with
Collision Avoidance
CTT Current Traveling Time
CW Contention Window
DARPA Defence Advanced Research
Projects Agency
DCF Distributed Coordination Function
DIFS Distributed Interframe Space
DRP Dynamic Route Planning
DSRC Dedicated Short Range
Communication
ECU Electronic Control Unit
EDCA Enhanced Distributed Channel
Access Function
EIFS Extended Interframe Space
EMS Emergency Medical Services
ETC Electronic Toll Collection
ETSI European Telecommunications
Standards Institute
FCC Federal Communication
Commission
FDM Frequency Division Multiplex
FHWA U.S. Department of Transportation
and Federal HighWay
Administration
GlomoSim Global Mobile Information System
Simulator
HBEFA Handbook Emission Factors for
Road Transport
IDM/IM Driving Model with Intersection
Management
IDM/LC Intelligent Driving Model with
Lane Changing
IEEE Institute of Electrical and

5
Electronics Engineers
IFS Interframe Space
IP Internet Protocol
ITS Intelligent Transport System
ITS-DLR Institute of Transportation Systems
at the German Aerospace Center
ITT Ideal Traveling Time
IVC Inter Vehicle Communication
LAN Local Area Networks
LIN Local Interconnect Network
LLC Logical Link Control
MAC Media Access Control
MAN Metropolitan Area Networks
MANET Mobile Ad -Hoc Network

6
1. Comunicații folosite în rețelele VANET

Rețelele VANET au făcut posibilă apariția unei noi clase de aplicații orientate
spre furnizarea unei experiențe la volan improvizată, mai sigură și cooperativă.
Aplicațiile pot fi împărțite în două tipuri: a plicații de eficientizare a traficului ,
printre care sunt cele care răspund cu privire la îmbunătățirea experienței
conducătorulu i auto și aplicații de siguranța circulației, care contribuie la
îmbunătățirea siguranței conducătorilor auto. Imaginea de ansamblu a unui sistem de transport inteligent ar consta nu doar în VA NET, ci în multe rețele de
suport conectate între ele, în scopul de a sprijini diferite caracteristici așa cum se observă în figura 1.1. Vehiculele se vor conecta la alte vehicule și unitățile
rutiere laterale fixe. Unitățile laterale ale drumurilor, semna le de trafic, centrele
de colectare a taxelor vor face parte dintr -o rețea centrală care se conectează, de
asemenea la diverse centre de control, cum ar fi centre de expediere de urgență, de control al traficului și camera de control ale poliției care form ează împreună o
rețea fără contact. Aplicațiile de siguranță publică, cum ar fi alarmarea
vehiculelor de urgență în apropiere, alerta post-coliziune, raportarea accidentului,
avertizarea cu privire la punctul mort și pre -coliziune sunt de interes mai mare,
deoarece acestea reprezintă utilizarea cea mai semnificativă pentru VANET și
fac dreptate la revizuirea cheltuielilor și a infrastructurii necesare pentru a le
sprijini.

Figura 1.1 Arhitectura de ansamblu a unei rețele VANET

7
Administrația Națională Pen tru Siguranța Traficului pe Autostradă
(NHTSA) a identificat și stabilit cerințele pentru aplicațiile inteligente pentru
siguranța vehiculelor în SUA. Aplicațiile menționate mai sus și mai multe vor
trebui să coexiste în aceeași rețea fără să utilizeze res ursele partajate, în scopul
de a furniza utilizatorului toate caracteristicile promise. Testarea performanței
aplicațiilor și a altor caracteristici legate de VANET este necesară în fază de
dezvoltare. Comportamentul complex al vehiculelor, șoferilor și diferitele
modele observate în lumea reală sunt greu de reprodus din cauza constrângerilor
asupra resurselor disponibile ceea ce face dificilă crearea unui VANET în lumea
reală, în scopul testării. De exemplu, în cazul în care o aplicație trebuie testată în
mijlocul orașului, setată pe 50 de mașini, ar avea nevoie de fapt, de 50 de mașini
dotate cu echipamentul de testare, 50 de persoane care să conducă mașinile și un teren de testare. Cealaltă opțiune disponibilă pentru comunitatea de cercetare este
de a sim ula VANET cu ajutorul simulatoarelor de rețea cu modele de mobilitate
definite pentru a simula mișcarea punctelor, de a folosi un simulator de trafic
dedicat pentru a realiza același lucru. Pentru a îndeplini o aplicație, trebuie fie
într-un mediu realist simulate cu interoperabilitatea pentru toate rețelele diferite.
-Modelează realistic mișcarea și comportamentul vehiculelor
-Modelează VANET, toate rețelele de sprijin protocoalele utilizate
-Oferă flexibilitatea de noi aplicații
În prezent, comunicațiile între vehicule se bucură de atenție considerabilă
din partea comunității industriașilor auto și cercetătorilor, deoarece sunt capabile
să ofere servicii atât sistemelor inteligente de transport cât și conducătorilor auto
și pasagerilor. În ac est context, rețelele VANET (Vehicular Ad Hoc Network)
devin un nou tip de rețea wireless creată spontan de vehiculele aflate în mișcare și echipate cu interfețe wireless care folosesc, sau nu, aceeași tehnologie de
comunicație. Aceste rețele pot fi gândit e ca fiind sisteme de comunicație pe
distanțe scurte și medii. O rețea VANET este o formă de rețea mobilă ad hoc
(MANET) care oferă servicii de comunicație între vehiculele învecinate, dar și între vehicule și echipamentele fixe de pe marginea drumului.
Inovațiile recente din domeniul tehnologiilor wireless, prezentate în
capitolele anterioare, permit rețelelor VANET să dezvolte arhitecturi dedicate
mediilor urbane, rurale, autostrăzilor, etc.. Aceste arhitecturi trebuie să permită
comunicația între vehicu lele învecinate și între vehicule și dispozitivele
amplasate pe marginea șoselelor. Se disting trei posibilități:

8
• rețea wireless ad hoc vehicul-la -vehicul, pe baza comunicațiilor V2V, fără
suportul infrastructurii.
• Comunicații V2I prin puncte de acces wire less susținute de o rețea cablată
(backbone). Acestea sunt rețele VANET cu arhitectură de WLAN.
• O arhitectură hibridă (V2X) în care comunicațiile nu se bazează în mod
constant pe o infrastructură fixă, dar în caz că există, o exploatează în
vederea îmbunătățirii performanțelor. În acest caz, vehiculele pot comunica cu infrastructura prin single -hop sau prin multi- hop, în funcție
de poziția lor față de punctul de conectare la infrastructură.
C2C-CC a propus un cadru de referință pentru arhitectura rețelelor VANET,
distingând trei domenii: domeniul în- vehicul (in- vehicle), domeniul ad hoc și
domeniul infrastructural.
Domeniul în -vehicul se referă la rețeaua locală din interiorul fiecărui vehicul,
compusă de obicei din două echipamente: unitatea de bord (OBU) și una sau mai
multe unități de aplicație (AU). Un OBU este un dispozitiv cu capabilități de
comunicație wireless, în timp ce AU este un dispozitiv care rulează aplicații folosind OBU ca mijloc de comunicare. AU poate fi parte integrantă din vehicul,
conectat permanent la OBU, sau poate fi un dispozitiv portabil, de exemplu un
laptop sau PDA, care se atașează la OBU din când în când. AU și OBU sunt
conectate împreună prin conexiuni cablate sau wireless (de exemplu Bluetooth). Separarea AU și OBU este o separare logică, ele putând fi găsite în același
echipament hardware.
Domeniul ad hoc este o rețea formată din vehicule echipate cu OBU și unități
fixe de infrastructură (RSU). Dacă OBU este echipat cu un echipament de
comunicație wireless dedicat aplicațiilor de siguranță rutieră, atunci vehiculele
formează o rețea MANET. OBU-urile și RSU -urile pot fi văzute ca fiind
nodurile mobile, respectiv statice, ale unei rețele ad hoc. Un RSU poate fi
conectat la o rețea infrastructurală care la rândul ei poate fi conectată la Internet.
RSU -urile pot comunica unul cu altul direct sau prin multi -hop. Rolul lor este să
îmbunătățească siguranța traficului. Acest lucru se realizează prin rularea unor aplicații dedicate și prin trimiterea, recepționarea sau retrimiterea datelor în

9
domeniul ad hoc . În funcție de echipamentele de infrastructură, există două tipuri
de domenii infrastructurale : zone publice de acces wireless și zone dedicate
comunicațiilor V2V și V2I prin utilizarea de RSU -uri. Așadar, rețelele VANET
pot fi implementate prin integrarea vehiculelor în zone dedicate sau în zone
publice de acces aflate de -a lungul drumului. Asemenea zone de acces pot opera
individual, ca zone private, sau ca modalitate de acces la Internet pusă la
dispoziție de diferiți operatori. În absența RSU -urilor și zonelor de acces, OBU
poate utiliza comunicația mobilă (4G) . În acest caz, trebuie dotat cu interfețe
corespunzătoare. Este posibilă și combinarea acestor scenarii de implementare. Indiferent de modalitățile anterioare, întotdeauna există posibilitatea ca
vehiculele să poată comunica unele cu altele fără vreo infr astructură
.

Figura 1.2 Arhitectura de referință C2C -CC

Viitoarele sisteme inteligente de transport consideră vehiculele ca noduri active,
responsabile cu colectarea și transmiterea informațiilor critice. În consecință,
rețelele VANET pot coexista cu rețelele de senzori. În acest scenariu, vehiculele
vor fi capabile să colecteze date, să le proceseze și să transmită informația la alte
noduri (fixe sau mobile), în ceea ce devine un sistem global de comunicație.
Scopul acestei licențe a fos t de a aduna cerințe, design, implementarea și
testarea unei aplicații de siguranță publică pentru VANET care este în
conformitate cu standardul WAVE folosind un path de testare scalabil. Aplicația
suportă următoarea caracteristică:

10
Raportarea accidentul ui (Avertizare post- accident): Cele mai moderne
vehicule din zilele de astăzi sunt echipate cu o varietate de senzori de bord (
frâne cu anti -blocare, senzori de declanșare a air -bag-urilor, accelerometru,
giroscoape) care, atunci când sunt utilizate împr eună pot detecta o coliziune.
Vehiculele implicate într -un accident va utiliza VANET pentru a începe imediat
transmiterea de mesaje către vehiculele din jurul ei, alertându- le despre accident.
Informații despre accident vor fi, de asemenea, transmise. Ac est lucru va alerta
vehiculele în apropiere care sunt pe traiectoria vehiculului accidentat, să
încetinească și să se oprească la o distanță sigură, evitându -se astfel coliziuni și
salvându- se mai mulți oameni de la a fi lezați sau omorâți, în special în timpul
condițiilor meteo nefavorabile, cu vizibilitate scăzută. Simularea va modela din
nou reacția șoferilor la această caracteristică a aplicației făcând vehiculele să se
oprească la o distanță sigură față de vehiculul avariat, prin urmare, modificarea
fluxului de trafic în simulare.
1.1. Protocoale de comunicații VANET
În prezent sunt în lucru numeroase programe naționale, regionale si
internaționale cu privire la comunicaț iile dedicate pe distante scurte (Dedicated
Short Range Communications – DSRC ). Vom disc uta numai de preocupările
organizației internaționale pentru standardizare (ISO), comitetului european de standardizare (CE N). In cadrul ISO toate activităț ile cu privire la DSRC sunt
tratate de comisia tehnica TC204. Acolo sunt doua grupuri de lucru (Work ing
Group – WG) diferite care d ezvoltă standardele de comunicație DSRC sau
asemănă toare DSRC. Adi țional standardelor de comunicație, multe alte grupuri
de lucru dezvolta standarde pentru aplicațiile care utilizează DSRC ca suport de
comunicaț ie.
– Grupul de lucru 15 ( WG15) – responsabil cu comunicațiile dedicate pe
distante scurte pentru aplicaț iile DSRC, este angajat in doua teme de lu cru,
una destinata nivelului Aplicaț ie (L7) si ce alaltă destinata gestionarii
resurselor.
– Grupul de lucru 16 ( WG16) – responsabil cu comunicațiile/protocoalele
de comunicaț ie pe dista nte medii si lungi prin interfețe radio. Deși acestea

11
nu sunt clasificate ca DSRC din cauza câ torva motive care includ raza de
operare, rat ele de date implicate si aplicaț iile suportate, actualul standard
DSRC Nord American in banda de 5.9 GH z, in ciuda numelui, se
potrivește mai degrabă acestui grup de lucru decâ t WG15. Acest grup
cuprinde subgrupuri care studiază printre altele posibilitatea accesului la
internet, arh itectura sistemelor de c omunicație, culegerea informaț iilor de
la vehicule, etc.. TC204/WG16 are înț elegeri de cooperare cu: WAVE
IEEE 802.11p si P1609, ETSI ERM TG37 – standardele 3G/4G,
specificaț ii si teste, IETF – Internet Network Mobility (NEMO), ITU-R
WP 8A – Standarde globale radio.
CEN a dezvoltat propriul set de standarde DSRC, care include standardele
destinate nivelul ui Fizic (L1), nivelului Legă tură de Date (L2), si nivelului
Aplicaț ie (L7). Recent, ETSI a creat un comitet tehnic pentru standardizare in
domeniul sistem elor intelige nte de transport (TC ITS). Pe lângă aceste
organizații de standardizare au apărut consorț ii industriale, de exemplu Car2Car
Communication Consortium (C2C -CC) in Europa sau Vehicle Safety
Communication Consortium (VSCC) in Statele Unite. Rezultatul acestor
demersuri sunt standardele IEEE 1609.x si IEEE 802.11p in Statele Unite.
În paralel, ISO (ISO TC204/WG16 – Comunicații pe distanțe întinse) a
creat un standard pentru distanțe medii și lungi, numit CALM (Continous
Communications Air Interfac e for Long and Medi um Range). CALM nu este o
colecție complicată de tehnologii radio noi, netest ate, ci prima cale standardizată
dedicată integrării comunicaț iilor GP RS cu tehnologia WLAN optimizată pentru
vehicule (WAVE 802.11p). Câteva aplicaț ii CALM :
• suportul serviciilor internet;
• suportul aplicațiilor specifice sistemelor inteligente de transport –
independente de mediul de transmisie prin DSRC L7;
• deschiderea către o noua generație de aplicaț ii:
• siguranța circulaț iei: Vehicle Safety Communication
• aplicații come rciale cu necesităț i mari de rate de date pe distanț e lungi.

12

Problema specific ă
de transport Sisteme de servicii
CVO (Corporate
Vehicle Observatory) Interfata tractor – trailer
Atenț ionare la rollover
Electronic Border Clearence
Weigh Station Bypass Clearance
CVO Fleet Management
Onboard Safety Data Transfer
Tractor -Trailer Matching
Transit Vehicle Data Transfer
Inspectarea vehiculelor pentru siguranță
Drivers Daily Log
Alte Servicii Probe Data Collection
Access Controll
Vehicle Manufacturer Info

Plata electronic Toll Collection
ITS Service Payment
Other payments
Rental Car Processing
Plata parcării

13
Plata mancării
Plata alimentării

Siguranță Vehicle to vehicle Data Transfer
Highway Rail Intersection Warning
Informaț ii de trafic Transfer audio – Streaming
Actualizăr i harta
Internet Mobil
Date de trafic
Informații de călă torie
Înregistrări de vehicule (Vehicle Registration)
Prioritizarea vehiculelor de tranzit
Transfer date de diagnostic
Transfer video – bloc
Transfer audio – bloc
Transfer video – streaming
Înregistrarea serviciilor de reparaț ie
Actualizare software la vehicul
VSC OBU to OBU
VSC RSU to OBU
Tabelul 1.1 Servicii definite pentru mediul de 5 GHz
Este interesantă specificarea serviciilor prinse la Informații de Trafic:
Internet mobil, Transfer audio și video, în forma de streaming ș i de fișiere,

14
acestea necesitând lățimi fo arte mari de banda. CALM definește 5 scenarii de
comunicaț ii:
0 – V2I fără IPv6
1 – V2I/V2V Local cu IPv6
2 – V2I MIPv6
3 – V2I NEMO
4 – V2V Non -IPv6
Toate acest e eforturi se fac î n scopul creării unor specificații capabile să
permită comunicarea între vehicule și între vehicule și infrastructura ș oselelor
(V2V, V2I, C2C, C2I, pe scurt C2X). Aceasta ar face posibila apar iția unei
varietăți de aplicații destinate creșterii siguranței si confortului călătorului,
notificarea situațiilor de urgență , optimizarea traficul ui, accesul la internet.
Aplicațiile și tehnologiile V2X au necesități și caracteristici specifice, cu câ teva
implicații tehnice ș i politice serioase. Multe aplicații, ca să indice corect locația
unui accident și ca să știe cum să reacționeze la recepționarea unui mesaj, se
bazează pe cunoașterea exactă a poziț iei nodurilor, ceea ce presupune că oricâ nd,
oriunde se poate ști poziția unui individ, lucru care poate intra in conflict cu
libertatea acestuia. O alta problema pleacă de la mobil itatea vehiculelor care
formează rețeaua; aplicaț iile nu pot ut iliza sesiuni sau rutare stabilă. Lăsând
deoparte provocă rile tehnice ș i filosofice, trebuie lua te în considerare ș i
influenț ele politice. Trebuie negociată eliberarea frecvenț elor radio sau instalarea
infrastructurii. Mai mult, situațiile diferite de la regiune la regiune sunt împotriva
realizării unei armoniză ri inte rnaționale. Pe când în Japonia deja există o
infrastructura pentru sistemele de informare și c omunicare cu vehiculele (VICS)
și pentru colectarea electronică a taxelor (ETC), în unele zone, ca Germania, puțin probabil că comunicaț iilor V2X li se va permite să folosească infrastructura
de colectare a plăților. Pe câ nd Statele Unite se confrunta cu problema șofatului
pe distante lungi în zone puțin populate, principala problemă japoneză este cea a
șoselelor înguste și aglomerate pe distanțe scurte ș i stivuire a câtorva benzi,
exemplul autost răzii metropolitane din Tokio. Pe când în Statele Unite

15
specificațiile V2X sunt realizate în principal de furnizorii de infrastructură iar
numărul autorităților implicate este mai degrabă limitat (Departamentul de
Transport DOT, Comisia Federala de comunic ații FCC), î n Europa este greu de
realizat o infrastructura comună datorita existentei multor autorități naționale.
1.2. Standarde definite în Statele Unite ale Americii
Părțile implicate în cercetarea ș i standardizarea comunicațiilor wi reless
dedicate I TS sunt producătorii de autovehicule ș i guvernul (DOT). Eforturi le
principale sunt concentrate în proiecte finanț ate de DOT precum Programul de
Integrare Vehicul Infrastructura (Vehicle Infrastructure Integration Program –
VII) ș i Sistemul de Evitar ea a Co liziunilor prin Intersecții Cooperante
(Cooperative Intersection Collision Avoidance System – CICAS). Consorțiile
industriale care sprijină aceste eforturi sunt VIIC (Vehicle Infrastructure
Integration Consortium) ș i CAMP (Crash Avoidance Metrics Partnersh ip).
În 1992, Societatea Americana pentru Testarea Materialelor (American
Society of Testing Materials – ASTM) evaluează tehnica ETC în America de
Nord și introduce s tandardul US DSRC. US DSRC ocupă banda de frecvența de
915 Mhz si utilizează tehnologia TDMA. Dezavantajul este că nu poate suporta
transferuri de fiș iere largi (rata de transmisie de numai 0.5 Mbps). Raza de
transmisie: aprox. 30 m.
În 19 99 Comisia Federală de Comunicaț ii (Federal Communications
Commission – FCC ) decide să aloce 75 Mhz î n banda de 5.9 GHz ca spectru
pentru comunicațiile dedicate pe distanț e scurte (DSRC), exclusiv pentru uz
vehicular cu scop principal, creșterea siguranței. Figura 1.3 oferă o privire de
ansamblu a canalului alocat. Avantajul este o rata de tran smitere de 1 – 27 Mbps
cu o rază de transmitere de aprox. 1000 m.

16

Figura 1.3 Lățimea de bandă alocată standardului DSRC în SUA

Protocoalele de comunicaț ie pe ntru V2X au fost standardizate î n cadrul
IEEE. Nivelul fizic (PHY) și MAC sunt definite î n IEEE 802.11p. Nivele le
superioare de comunicaț ie sunt definite de seria I EEE 1609.x, și formează
împreuna ceea ce se cheamă Acces Wireless pentru Mediul Vehicular (Wireless
Access for the Vehicular Environme nt – WAVE). Figura 1. 4 prezintă stiva de
protocoale rezultată .

Figura 1.4 Stiva de protocoale WAVE în SUA

17

Funcț ionalităț ile nivelelor a flate deasupra nivelului fizic și MAC sunt
descrise î n seria de documente IEEE 1609.x:
 IEEE 1609.1 gestionarea mai multor fluxuri de date s imultane, gestionarea
memoriei ș i altor resurse ale sistemului
 IEEE 1609.2 acoperă metodele de secur itate pentru mesajelor WAVE
împotriva atacurilor.
 IEEE 1609.3 acoperă serviciile și protocoalele de re țea WAVE
 IEEE 1609.4 acoperă în principal cum trebuie să opereze mai multe canale
– incluzând canalele de control și de serviciu
În 2001 ASTM utilizează IEEE 802.11a/RA ca noua propunere de standard
de nivel jos pentru DSRC, incluzând nivelele PHY și MAC (datorită
compatibilităț ii 802.11a cu vechiul DSRC 1999).

Parametri IEEE 802.11a IEEE 802.11 p
Spectru 5.15-5.35,5.725 -5.825
GHz 5.85-5.925GHz
Canal BW 20MHz 10MHz
Num ăr de canale 12 7
Numă r de
subcanale 52(48 data+4 pilot) 52(48 data+4 pilot)
Numă r maxim (64 –
QAM) 54Mbps 27Mbps
Numă r minim (BP
SK) 6Mbps 3Mbps
Suprafaț a
Canalului 312.5KHz 156.25KHz
TFFT 3.2µs 6.4µs
TGI 0.8µs 1.6µs
TSYM 4µs 8µs
Tabelul 1.2 Comparație standarde IEEE 802.11a vs IEEE 802.11p
În 2002 ASTM confirma ă standardul DSRC – E2213 -02.

18
• propune spectrul de 5.9 Ghz pentru standardul DSRC
• pentru tehnologia de comunicaț ie preia ca punct de plecare IEEE 802.11a
• pentru nivelul PHY: modifică 802.11a
• pentru nivelul MAC: similar 802.11
• rata de transmisie: 1 ~ 27 Mbps
În 2003 E2213 -03 este acceptat de către FCC și devine standardul DSRC î n
America de Nord. ASTM propune specificaț iile standardului E2213 -03 la IEEE,
și aceasta contribuie la apariția IEEE 802.11p. Standardul definește 7 canale de
10 MHz (unul de control ș i 6 de serviciu). Antenele (direcționale sau
omnidirecționale) conectate la RSU trebuie montate la înălț imi intre 6 si 15 m .

915 MHz DSRC 5.9 GHz DSRC
Raza < 30m Raza ~ 1000m
Rate de date = 0.5 Mbps Rate de date de aprox. 6 ~ 27
Mbps
Destinat ETC, dar poate fi utilizat si pentru
alte opera ții Destinat pentru acces general la
internet dar poate fi utilizat si pentru ETC
Un singur c anal licenț iat 7 canale licenț iate
Necesita software si e lectronica speciala
(customizată ) Utilizează software si
electronica obisnuită
V2I V2I si V2V
Mod de lucru comanda -raspuns Mod de lucru comanda -răspuns
si punct la punct
Tabelul 1.3 Comparație DSRC în banda de 915 MHz vs 5.9 GHz

19
1.3. Standarde definite în Europa
Activitaț ile de cercetar e și standardizare ale comunicațiilor V2I în Europa
sunt conduse în principal de două entităț i, proiectele de cercetare fina nțate public
și C2C -CC. În ceea ce privește cercetarea, un număr mare de proiecte europene
și naționale au produs sau încă produc rezultate valoroase pe ntru diferite arii ale
comunicațiilor V2I. Noua generație de proiecte de cercetare ținteș te acum testele
operaț ionale (Fie ld Operational Test – FOT) ca să valideze soluț iile propuse de
proiectele anterioare. Un exemplu de astfel de proiect este SIM -TD din
Germania.
Numărul uriaș de proiecte a fost motivul creă rii pro iectului COMeSafety,
care coordoneaz ă diferite alte proiec te. Rolul sau este sa garantează că rezultatul
diferitelor proiecte este, cel pu țin într -o anumită măsură , compati bil cu al
celorlalte. Pe de altă parte, se asigură că rezultatele proiectului iau în considerare
pregă tirile de planificare și standardizare ale C2C -CC.
C2C-CC este în Europa organizaț ia care conduce procesul d e
standardizare. Este un consorțiu industrial în care OEM -uri, furnizorii si
institutele de cercetare consolidează scopurile diferitelor proiecte de cercetare.
Mai mult, C2C-CC pregătește și suport ă activităț i de genul procesului de alocare
al frecvenț elor. Aceste activit ăți, împreuna cu cele de standardizare sunt î n final
realizate de ETSI.
Rezultatul actual al act ivităț ilor C2C -CC poate fi sumarizat după cum
urmează . In ceea ce privește alocarea frecvențelor, o lă rgime de banda dedicat ă
de 30 MHz va fi disponibilă pentru aplicațiile de siguranță ale traficului în banda
de 5.8 Ghz. Încă 20 de MHz pot fi puși la dispoziț ie ca exte nsii ulterioare, pentru
siguranța ș oselel or și eficiența traficului. Aplicațiile ITS fără implicații de
siguranță pot utiliza 20 MHz, sub cei 30 MHz, din banda ISM.

20

Figura 1.5 Banda de frecvențe alocată în Europa pentru DSRC

In privința protocoalelor de comunicație, figura ilus trează stiva de
protocoale C2C -CC. Cea mai importanta diferen ța, comparativ cu alte protocoale
de comunica ție V2I propuse în Statele Unite ș i Japonia, este orie ntarea puternică
către comunicația directă V2V cu o concentrare mai mic ă asupra comunicaț iei
V2I. Aceasta se reflectă în protocoalele de transport și rețea C2C -CC care oferă
atribute ca diseminare multi- hop a mesajel or și routare geografică .

Figura 1.6 Arhitectura protocoalelor folosite de sist emul de comunicații C2C -CC

21

Figura 1.7 Stiva de protocoale C2C -CC
În final, Europa împrumută standardul american, astfel î ncât spectrul ITS
în Europa standardizat în august 2008 arată că în figura de mai jos: banda de 30
Mhz la 5.9 Ghz (5.875 Ghz – 5.905 Ghz) specificaț ia WAVE (Wireless Access
in Vehicular Enviroments).
Se observă cele doua nivele de nivel inferior, nivel ul fizic (PHY) canal de
10 Mhz în banda ITS de 5.9 Ghz, IEEE 802.11 p (care este un 802.11a, OFDM)
și controlul accesului la mediu (MAC), nivelul MAC de baz ă al standardului
802.11, CSMA/CA . Î n plus MAC -X IEEE P1609.4.
Nivelele superioare sunt definite de IEEE 1609.x. Standardul WAVE a
fost definit pentru servicii de atenționări locale de pericole, atenționă ri
cooperative de pericole, dise minarea informației de trafic, schimb de fișiere P2P.
IEEE 1609. 1 WAVE Resource Manager: definește platforma de bază
pentru aplicaț ii (Basic Application Platform) ș i protocoalele de citire – scriere
date la nivelul aplica ție între RSU si OBU. Primele aplic ații sunt disponibile
numai în scop de test.

22
IEEE 1609.2: Serviciul de securitate al transmisiilor radio pentru ITS in
banda de 5.9 Ghz. Defineș te mecanismele de securitate ale DSRC in 5.9 Ghz
(vechiul IEEE 1556).
Asigură anonimatul, autenticitatea și conf idenț ialitatea.
IEEE 1609.3: Servicii de re țea WAVE (WAVE Networking Services),
descrie și explică modul de lucru al stivei de protocoale DSRC. Interfeț ele de
aplicație, gestionarea configura țiilor de rețea, modul de transmisie și recepț ie al
Mesajului Scurt WAVE (WSM – WAVE Short Message).
IEEE 1609.4: Operarea multicanal WAVE (WAVE Multi -Channel
Operation), descrie modul de operare al benzii de frecventa DSRC. Gestionează
utilizarea nivelelor mai joase ale celor 7 canale DSRC.
Se integrează strâ ns cu 8 02.11p. IEEE 802.11p: specificație Wireless LAN
Medium Ac cess Control (MAC) și specificație nivelului fizic AC.
1.4. Reglementări la nivel european
Eforturile europene de reglementare în domeniul VANET s-au axat cu
predilecție pe tehnologiile cu rază scurtă și medie care operează în benzi de
frecvență dedicate, tehnologii destinate în special comunicațiilor ad hoc. Această
secțiune prezintă echivalentul european al IEEE 802.11p/WAVE, ITS -G5.
ITS-G5 este numele standardizat al profilului european în stadiu de proiect
ETSI ES 202 663. Profilul european se bazează pe IEEE 802.11 -2007 și va
deveni referință normativă de îndată ce va fi finalizat. Deoarece amendamentul
IEEE 802.11p la standardul 802.11 ar e în prezent statutul de proiect (draft),
acesta nu poate fi folosit ca normă în profilul european. Cu toate acestea, ideile și
metodele descrise de 802.11p sunt esențiale pentru multe aplicații ITS și nu
poate fi ignorat, tehnologia de acces ITS -G5 incluz ând toate caracteristicile
802.11p.
Puntul de plecare al profilului european este decizia Comisiei Europene
din 5 august 2008 privind utilizarea armonizată a spectrului de frecvențe radio în

23
banda de 5.875 – 5.925 GHz pentru aplicații ITS legate de sigur anță. Profilul
definește și acoperă trei game de frecvență:
• ITS-G5A. Reglementează operarea tehnologiei de acces ITS -G5 în
spectrul european dedicat aplicațiilor ITS legate de siguranță (folosesc
mecanisme de securitate pentru protecția datelor): 5.875- 5.905 GHz.
Pentru dezvoltări ulterioare se ia în considerare și banda 5.905- 5.925 GHz,
cu observația că în această bandă nu poate fi asigurată protecția datelor.
• ITS-G5B. Reglementează operarea în spectrul european dedicat
aplicațiilor ITS care nu privesc sig uranța (se asigură lipsa de interferență
dar sunt implementate fără mecanisme de securitate): 5.855 – 5.875 GHz.
• ITS-G5C. Reglementează operarea aplicațiilor ITS în banda de frecvențe
publică 5.470 – 5.725 GHz.
Pentru ITS -G5A, ECC a decis deja desemnarea , ITS-G5B este în prezent o
recoma ndare. Pentru comparație: Statele Unite folosesc un spectru de 75 MHz în
banda 5.850- 5.925 GHz, Japonia folosește 80 MHz în banda 5.770- 5.850 GHz.
Cei 30 MHz între 5.875- 5.905 GHz sunt în prezent împărțiți în 3 canale de c âte
10 MHz fiecare, unde primul, SCH1, este principalul canal de serviciu pentru
mesajele legate de siguranță și eficiență rutieră (pentru rată mare de transfer,
mesaje legate de siguranță cu prioritate medie, mesaje multi-hop și geocast la al
doilea hop), al doilea, SCH2, este canalul de serviciu utilizat numai cu putere de
emisie mică pentru comunicații pe distanțe foarte scurte, în principal între
vehicule și echipamente de infrastructură (pentru comunicații ad -hoc), și ultimul,
între 5.895 -5.905, este c analul de control, CCH, care poate fi utilizat, pe lângă
mesajele de control, și de mesajele sensibile la întârzieri (pentru latență mică,
pachete periodice, mesaje legate de siguranță cu prioritate mare, mesaje multi-
hop și geocast la primul hop). Din cauza datelor transmise pe canalul de control, una din cele mai importante caracteristici ale profilului european constă în
necesitatea stațiilor ITS de a asculta permanent pe canalul de control. În timp ce
canalul de control este comun tuturor aplicațiilor, serviciile legate de optimizare
și informare pot utiliza și propriul canal de 20 MHz în banda 5.4 GHz, așa cum descrie ITS -G5C. ITS -G5C folosește tehnologia de acces ITS -G5 în mod similar

24
cu ITS -G5A și ITS -G5B, dar pe un canal de frecvențe diferit. Totuși, deoarece
banda de frecvențe 5.4-5.7 GHz are nevoie de selectarea dinamică a frecvențelor,
trebuie folosit un RSU cu rol de master DFS, care să monitorizeze alocarea
spectrului și să anunțe pe canalul de control canalele de serviciu disponibile. Din
cauza asocierii cu un master DFS, latența minimă obținută este mai mare decât în
cazul ITS -G5A și ITS -G5B. Astfel, aceasta este o tehnologie bună pentru
aplicațiile legate de optimizarea traficului, cu cerințe de întârziere scăzute spre
medii. Deoarece ITS -G5 operează în aceeași bandă ISM de 5 GHz cu alte
tehnologii, interferența cu acestea va fi inevitabilă, lucru care va limita performanța.
Densitatea maximă a puterii spectrale pentru stațiile ITS care respectă
profilul european ETSI ES 202 663 trebuie limitată la 23dBm/MHz EIRP. Puterea totală nu trebuie să depășească 33 dBm EIRP cu un interval TPC de 30 dB. Emisiile nedorite trebuie ținute sub -65 dBm/MHz mai jos de 5.815 GHz și
deasupra 5.925 GHz și sub -55dB/MHz mai jos de 5.850.
Deși ITS -5G (ca și IEEE 80 2.11p) folosește nivelul fizic IEEE 802.11a
adaptat la viteze mari ale vehiculelor, care permite rate de transfer de până la 27
Mbps într -un canal de 10 MHz, din moment ce aplicațiile legate de siguranță
rutieră necesită robustețe ridicată, cel mai probabil va fi aleasă o rată de transfer
mai mică ( de ex., 6 Mbps).
Raza de acoperire depinde de puterea de emisie, rata de date și de
condițiile curente ale mediului de propagare, dar se preconizează a fi de cel puțin 500 m la putere maximă și rată de date minimă, și peste 1 km în condiții de
vizibilitate directă.
La fel ca IEEE 802.11p, ITS -G5, folosește protocolul IEEE 802.11
CSMA. Deoarece cu CSMA pot apare coliziuni pe timp nelimitat, nu sunt
suportate comunicațiile în timp real, cu termene stricte.

25
Profilul ETSI ES 202 663 adresează următoarele servicii IEEE 802.11:
• servicii de management al spectrului de frecvențe pentru ITS -G5C. Se
referă la împărțirea uniformă a canalelor de comunicație prin alocarea
dinamică a frecvențelor (Dynamic Frequency Selecti on – DFS) și la
reducerea automată a puterii de transmisie când sunt prin preajmă alte rețele (Transmit Power Control – TPC). Aceste mecanisme sunt prezente
în standardul IEEE 802.11h.
• diferențiere de trafic și prioritizare;
• selectarea serviciilor de dat e MAC: DCF, EDCA, fragmentare/de –
fragmentare (ultima numai pentru ITS -G5C);
• selectarea serviciilor de control MAC: ACK;
• selectarea serviciilor de management MAC: cadre de management al spectrului;
• nivelul fizic OFDM;
O funcționalitate esențială înglobată de profilul european este comunicarea
în afara contextului BSS. Acest tip de comunicare permite schimbul imediat de
cadre de date și evită latența asociată cu stabilirea unui BSS.
Pe lângă specificațiile de nivel fizic și MAC, profilul european trebuie să
armonizeze și alte aspecte ale tehnologiilor de acces:
• Limitele rețelei. Setarea razei de acoperire pentru o singură stație ITS și
încărcarea totală permisă pentru un canal de comunicație;
• Controlul puterii de emisie. Specificarea nivelurilor de putere, metode de
calibrare și fixarea minimelor și maximelor valorii EIRP pentru un OBU;
• Îmbunătățirea MAC. Dezvoltarea unor noi algoritmi MAC pe baza dezavantajelor cunoscute ale CSMA- ului specificat de IEEE 802.11 -2007.
Sunt în discuție algoritmi care funcționează pe baza TDMA.
• Co-existența cu CEN DSRC. Din cauza învecinării spectrelor, între ITS –
G5A și ITS -G5B, pe de o parte, și CEN DSRC, pe de altă parte, s -ar putea
produce interferențe. Sunt investigați deja algoritmi și mecanisme de co –
existență.

26
• Îmbunătățirea fiabilității nivelului PHY. Sistemele actuale folosesc adesea
mecanisme de sincronizare și estimare a canalului optimizate pentru
utilizarea staționară sau de interior. Se încearcă adaptarea acestora la
mediile rutiere.
• Alte frecvențe. Pentru reducerea problemelor cauzate de obstacole, se
încearcă utilizarea unui canal cu frecvență redusă în banda de 870 MHz,
ca amendament la spectrul ITS de 5.9 GHz.

27
2. Simularea rețelelor VANET

Două tendințe majore au fost observate în comunitatea de cercetare atunci
când vine vorba de simularea VANET. Cele două sunt explicate mai jos:
2.1. Simulatorul de rețea de sine stătător
În această abordare, un simulator de rețea este folosit pentru a simula aspectul
de rețea al VANET și un cadru de mobilitate în cadrul simulatorului de rețea,
cuplat cu un model de mobilitate este utilizat pentru a modela mobilitatea vehiculelor în VANET. Figură 2.4 prezintă tipurile de modele de mobilitate
utilizate.

Figura 2.1 Tipuri de modele de mobilitate
Modele sintetice : Acest ea sunt modele matematice care modelează fluxul
traficului ca modele stocastice – în cazul în care mobilitatea vehiculelor este
considerată a fi un model de flux pur întâmplător – unde mobilitatea vehiculelor
pe un drum este considerat a fi un fenomen hidrodinamic cu mașini care urmează
modele – unde comportamentul fiecărui vehicul este modelat după vehiculele din
fața lui. Dezavantajul major al acestor modele este complexitatea implicată în
modelarea comportamentelor umane detaliate.
Modele pe bază de sondaj : Folosesc informații despre fluxul de vehicule
adunate din sondaje. De exemplu, studiile cu privire la timpul în care lucrătorii
din SUA fac navetă, ora prânzului, distanța parcursă oferite de către

28
departamentul American al muncii sunt folosite pentru a genera un model de
mobilitate în încercarea de a modela în mod realist traficul la ore diferite din zi.
Modelul de mobilitate bazat pe agendă este un exemplu bun întrucât combină
activitățile sociale, mișcările geografice, mișcarea fiecărui nod este bazată pe
agendă șoferului din acea perioadă de timp a zilei
Modele bazate pe urmărire : Urmărirea vehiculelor este creată prin
extragerea directă a modelelor de mobilitate generice de urme de circulație a vehiculului. Cu toate că această abordare oferă un mode l de mobilitate destul de
realist, are un dezavantaj major al disponibilității limitate a urmelor de circulație
pentru vehicule.
2.2. Simulatorul de rețea conectat cu simulatorul de trafic
În această metodă de simulare VAN ET, un simulator de rețea este cuplat
cu un simulator de trafic dedicat. Aici simulatoarele de rețea sunt singurele responsabile pentru simularea protocoalelor de rețea folosite de VANET.
Mobilitatea fiecărui nod din simulare este controlată de un simulator de trafic dedicat și poziția actualizată este transmisă la simulatorul de rețea periodic.
Cristoph Sommeret a ajuns la concluzia că este neces ar o platform ă
puternic ă pentru VANET unde rezultatele simulării nu sunt dependente în
întregime sau influențate prea tare de mobilitatea modelului utilizat. A cest lucru
a condus la dezvoltarea VEINS ( Simularea vehiculelor în rețea), un cadru deschis de simulare, sursă care se folosește de două simulatoare – OMNeT++
pentru manipularea simulării de rețea și SUMO pentru manipularea simulării traficului rutier micr oscopic. Cele două simulatoare rulează în paralel și
comunică cu o conexiune TCP că în figură 2.2 de control al traficului.

29

Figura 2.2 Simulatorul de rețea OMNeT++ conectat cu simulatorul de trafic SUMO folosind
TraCI

Interfața (Traci), un protocol standardizat, este folosit pentru
comunicare. Această abordare față de simularea VANET oferă următoarele
avantaje:
-Simularea rețelei este independent de simularea traficului
-Traficul este simulat mult mai realist, complet, cu semnale de trafic, benzi,
intersecții și limite de viteză
-Simulatorul de rețea poate exercita de asemenea, controlul asupra vehiculului,
modifică proprietăți asociate, oferă feedback cu privire la modelul de mobilitate utilizat, făcându -l mai rea list și mai dinamic

30
2.3. Aplicații inteligente de siguranță a vehiculelor
Administrația Națională pentru siguranță traficului pe autostradă
(NHTSA), parte din Departamentul de Transport al Statelor Unite ( DOT) a
identificat și studiat a plicații le inteligenț e de siguranță a vehiculelor pentru
VANET. Cerințele specifice au fost stabilite pentru fiecare aplicație. Tabelul 2.1
prezintă câteva aplicații cu o scurtă descriere.
Dintre aceste aplicații, cele aplicația de interes pentru această licență este
explica tă în detaliu mai jos, iar cerințele enumerate, sunt de asemenea
menționate. Este de așteptat că vehiculele care participă la un VANET să fie echipate cu o unitate de bord (OBU), care are interfață cu calculatorul central al
vehiculului, alți pe senzorii î n bord și vor fi responsabili pentru furnizarea
capacității de comunicare cu mașina. Înainte de a vorbi despre aplicații, termenii
folosiți în cerințele aplicației sunt definiți:
Mod de transmisie : Descrie dacă transmisia este declanșată de un
eveniment sau dacă este trimisă periodic.
Frecvența minimă: Rată la care ar trebui repetată o transmisie
.
Aplicația Descrierea
Avertizarea apropierii vehiculului de
urgențe Oferă șoferului un avertisment pentru a
ceda prioritatea unul vehicul de urgențe
care se apropie
Avertizarea după accident Această aplicație din vehicul previne
apropierea de o zonă cu vehicule avariate( din cauza unui accident sau a
unei problem tehnice), care este oprită
pe partea carosabilă sau în apropierea
ei, determinând folosirea informațiilor
de pe hartă sau GPS.
Avertizarea cu privire la încălcarea Avertizează șoferul să oprească la
marcajul prestabilit atunci când

31
semnalului de trafic culoarea semaforului indică oprirea și
este posibil ca acesta să îl încalce.
Asistentul pentr u virare la stânga Oferă informații șoferilor cu privire la
traficul din sens opus, pentru a -I ajuta
să vireze la stânga într -o intersecție
semnalizată, dar fără marcaj pentru la
stânga.
Avertizarea în zonele cu vizibilitate
redusă Avertizează vehiculul d acă este pe cale
să iasă dintr -o locație cu vizibilitate
scăzută ( fie pentru el, fie pentru vehiculele din sens opus) și un alt
vehicul se apropie și este posibil să
intre în acest spațiu.
Informații despre pietoni la trecerile
desemnate Oferă o atențion are vehiculelor dacă
este vreun pericol de impact cu un pierton sau un copil care se află pe
trecere.
Avertizare de viteză în curbă Ajută conducătorul să stabilească
viteza potrivită la intrarea în curbă.
Avertizarea pentru zonă de lucru Avertismentele d e siguranță pentru
zonele de lucru se referă la detectarea
unui vehicul într -o zonă de lucru și la
emiterea unei înștiințări pentru conducător.
Adaptarea cooperării pentru
menținerea automată a vitezei Această aplicație va folosi comunicarea
dintre vehicu le pentru a obține
dinamica de conducere a vehiculului și
pentru a spori performanțele de
menținere automată a vitezei.

32
Detectarea unui accident imminent Poate fi folosită pentru a pregăti șoferul
de o coliziune iminentă.
Tabelul 2.1 Aplicații de siguranță publică

Latența admisibila: Durată maximă de timp permisă între atunci când
sunt disponibile informații care trebuie transmise și atunci când este primită
Rază maximă necesară de comunicare : Distanță de comunicare
maximă între cele două unități care este necesară pentru a susține în mod eficient
o aplicație particulară.
2.3.1. Avertizarea post -coliziune
Această aplicaț ie permite unui vehicul defect care a fost implicat într -un
accident sau care a suferit o defecțiune mecanică subită să avertizez e traficul
vehicular cu privire la această situație. Senzorii de bord ai vehiculului determină dacă vehiculul a fost implicat într -un accident sau se confruntă cu defecțiuni
mecanice. Sistemul OBU al vehiculului afectat va trimite mesaje vehiculelor care
se apropie și unităților rutiere prin care este anunțata starea sa.

Necesitățile comunicării:
-Comunicare de la vehicul la unitate rutieră sau de la vehicul la vehicul
-Comunicare pe o singură cale
-Comunicare point-to -multipoint
-Mod de transmisie: determinat de eveniment
-Frecvența minimă ( rata de actualizare) : 1Hz
-Latență admisibilă: 0.5 sec
-Date de transmis și/sau primit:
• Poziție

33
• Sens
• Starea vehiculului
-Raza maximă necesară de comunicare: 300m

2.4. Instrumente de simulare a comunicațiilor în rețele
VANET
Scopul acestei licențe a fost de a pune în aplicare și de a testa o aplicație
de siguranță publică, cu următoarea caracteristică: Alerta post -coliziune
îndeplinind cerințele stabilite de NHTSA. Aplicația dezvolt ată urma să fie
implementată pe un path de simulare capabil să simuleze toate aspectele
VANET, și de asemenea, reflectând rezultatul reacției vehiculelor datorită
prezenței aplicației. Reacția rezultată a unui vehicul ar fi similară cu modul în
care șoferu l vehiculului ar reacționa la informațiile primite, prin urmare,
modificarea fluxului de trafic în timp real.
Înainte de a implementa aplicația, a fost necesar să se decidă cu privire la
un test de simulare VANET mai întâi și să se analizeze caracteristic ile și
capacitățile furnizate pentru a se dezvoltă, simula și testa aplicația. Simulatorul a trebuit să fie capabil să simuleze VANET pentru a asigura control aplicației să mimeze comportamentul uman, atunci când acesta conduce un vehicul. Rețeaua
de simulare a vehiculelor (VEINS ) a fost aleasă deoarece oferă o platformă
bună, cu toate caracteristicile necesare. Caracteristicile prevăzute și mai multe
detalii despre componentele care formează VEINS vor fi explicate în detaliu în
următoarele secțiuni.
2.4.1. VEINS

Veins, este un simulator de rețea cu sursă deschisă, proiectat ca o suită de
modele de simulări pentru a putea crea o rețea de vehicule. Aceste modele sunt executate de către un simulator de rețea bazat pe evenimente (OMNeT++) în

34
timp ce interacționează cu un simulator de trafic (SUMO). Celelalte componente
ale lui Veins au grijă de setările, rularea si monitorizarea simulării.
Acest lucru constituie un cadru de simulare. Ceea ce înseamnă că Veins
este menit să fie baza pentru scr ierea codurilor de simulare pentru aplicații
specifice. În timp ce Veins este utilizat, acesta rămâne nemodificat, doar câțiva
parametri rulează pentru unele cazuri cu utilizare specifică, iar acesta este
conceput pentru a servi ca un mediu de execuție pentru codul scris de utilizator.
De obicei, codul scris de utilizator va fi o cerere care urmează să fie evaluată prin intermediul unei simulări. Cadrul are grijă de următoarele: modelarea
structurilor de protocoale la nivel inferior și mobilitatea nodurilor , verificarea
configurațiilor pentru simulării, asigurarea executării corespunzătoare și colectarea rezultatelor înainte si după simulare.
Veins conține un număr mare de modele de simulare, care sunt aplicabile
pentru simularea unei rețea de vehicule.

Figura 2.3 Implementarea Veins în simulatoare

Modelele de simulare Veins servește ca un set de instrumente: o mare
parte din ceea ce este necesar pentru a se putea construi o simulare
corespunzătoare, extrem de detaliată a unei rețele de vehicule. Cu toa te acestea,
un cercetător care dezvoltă o simulare știe ce modele sunt disponibile pentru a le

35
folosi în munca sa. De exemplu, nimeni nu dorește să folosească un model
proiectat pentru orașe pentru a simula un scenariu de autostradă.
Cu ajutorul lui Veins, fiecare simulare se realizează prin execturarea celor
două simulatoare in pararel: OMNeT++ (pentru simularea de rețea) și SUMO (
pentr u simularea traficului rutier ) . Cele două simulatoare sunt conectate printr –
un socket TCP. Protocolul folosit pentru ace astă comunicare a fost standardizat
si se numeste Traffic Control Interface ( TraCI ) . Acest protocol permite
cuplarea bidirecțională pentru ambele simulatoare. Mișcarea vehiculelor în simulatorul de trafic SUMO este reflectat ca deplasarea nodurilor intr -o simulare
OMNeT++ . Nodurile pot interacționa cu simularea traficului rutier.

Caracteristici:
• Este bazat pe sursă deschisă 100% oferind extensibilitate fără restricții
• Permite reconfigurarea online și redirecționarea vehiculelor in reacție către
pachete le de rețea
• Se bazează pe încrederea modulului de mobilitate pentru transport și
punerea in aplicare de către comunitatea științifica Trafic și Transport
• Se bazează pe modele complet detaliate ale IEEE 802.11p si IEEE 1609.4
DSRC/WAVE, inclusiv operarea mu lti-canal, accesarea canalelor QoS,
zgomot și efecte de interferențe
• Poate include modele pentru rețelele mobile, de exemplu: LTE
• Poate simula un oraș intreg , in timp real, pe o singură stație de lucru
• Poate fi implementat pe clustere de calcul pentru sim ulare in MRIP care
poate fi distribuit în paralel
• Poate importa scenarii intregi din OpenStreetMap, inclusiv clădiri, limite
de viteză, numărul benzilor de circulatie, semafoare, acces si restricții de
întoarcere
• Furnizează surse de date pentru o gamă largă de valori, inclusiv timpul de
călătorie si a emisiilor CO2

36
2.4.2. SUMO
În cercetarea traficului, patru clase de modelare a fluxului de trafic sunt
diferențiate în funcție de nivelul de detaliu al simulării. Pentru modelarea
macroscopica , fluxul de trafic este entitatea de bază. Modelarea microscopica
simulează mișcarea fiecărui vehicul de pe stradă, mai ales comportamentul
vehiculului, depinde atât de reacțiile șoferului cât și mișcarea fizică a
vehiculului. Simulările mesoscopice sunt s ituate la limita dintre simulările
microscopice și macroscopice. Pentru acest mod de simulare, mișcarea vehiculului este simulată folosind începutul unei aglomerații iar vehiculul se
deplasează între aceste cozi.
Modelarea sub-microscopica analizează v ehiculele ca și la modelarea
microscopica dar în această modelare se extinde împărțirea în substructuri
ulterioare, care descriu viteza de rotație a motorului în raport cu viteză
vehiculului sau treapta preferată a conducătorului auto. Prin acest mod se po t
face calcule mai detaliate în comparație cu simulări simple microscopice. Cu toate acestea, există un dezavantaj și anume faptul că această modelare sub-microscopică necesită timp îndelungat pentru calcul. Acest lucru limitează
dimensiunea rețelelor care urmează să fie simulate.

37

Figura 2.4 Diferite granulatii de simlari; de la stanga la dreapta: macroscopic, microscopic,
sub-microscopic (iar in cerc: mesoscopic)

Într-o simulare continuă a spațiului, fiecare vehicul are o poziție descrisă
ca o analiză de numere. În contrast, aceste simulări spațiale discrete sunt
realizate automat folosind celule. În acest fel străzile sunt împărțite în celule iar
mișcarea vehiculelor pe străzi în simulare se face prin trecerea de la o celulă la
alta.
Aproape fiecare p rogram de simulare utilizează propriul model pentru
mișcarea vehiculului. Aproximativ toate modelele sunt numite „mașini urmărind
modele”: comportamentul conducătorului auto este menit să fie dependent de
distanța lui față de vehiculul din fața lui și vite za de conducere a vehiculului.
Dezvoltarea programului „Simularea mobilității urbane”, sau „SUMO” pe
scurt, a început în anul 2000. Motivul principal pentru dezvoltarea acestui program cu sursă deschisă, a fost de a simula traficul rutier la nivel microsco pic
și în acest fel sprijină comunitatea de cercetare a traficului cu ajutorul unor
algoritmi proprii care pot fi implementați și evaluați, fără a fi nevoie de muncă
fizică pentru a obține o simulare de trafic completă, cum ar fi punerea în aplicare

38
sau în ființarea unor metode de a face față cu rețelele de drumuri și controalele de
trafic. Prin furnizarea acestui instrument, DLR (Transport for London) a vrut să
facă:
• Algoritmi comparabili, asemenea unei arhitecturi de bază și un model
comun;
• De a obține ajutor suplimentar din partea altor contribuitori.
Începând cu anul 2001, a fost realizată prima versiune de rulare, iar
SUMO a fost utilizat într -un număr mare de proiecte realizate în cadrul DLR.
Principală aplicație a fost de a pune în aplicare și să evalueze metodele de
gestionare a traficului, cum ar fi noile sisteme de iluminare a traficului sau a unor noi abordări de orientare a traficului. În plus, SUMO a fost utilizat pentru
estimarea traficului pe termen scurt (30 de minute) în timpul evenimentelor mari, cu mulți participanți, iar pentru supravegherea și evaluarea traficului s-au
folosit rețelele GSM.
Din 2002, SUMO este de asemenea utilizat și în alte instituții. Aici,
interesul principal a fost de a evalua comunicarea dintre vehicul către un alt
vehicul și de la un vehicul către infrastructură. Două mari proiecte ar trebui să fie
menționate în acest context, în primul rând, Traci, care este o extensie SUMO și oferă posibilitatea de a comunica cu aplicații externe, efectuate la Universitatea
din Lubeck de către Axel Wegener. Cel de -al doilea proiect cu un mare impact
este „TraNS”, o conexiune directă între SUMO și simulatoarele NS2, OMNeT++ care utilizează Traci pentru comunicare.
Caracteristici:
• Modul de lucru este complet (rețeaua și rutele de import, simularea)
• Simulare
– Mișcarea vehiculelor în coliziune liberă;
– Diferite tipuri de vehicule;
– Străzi cu mai multe benzi și cu schimbarea benzii de rulare;
– Intersecții bazate pe regulile de dreapta;

39
– Ierarhia tipurilor de intersec ții;
– O interfață openGL cu utilizatorul;
– Administrarea rețelelor a mai mult de 10 000 de străzi;
– Rapiditatea vitezei de execuție;
– Comunicarea cu alte aplicații în același timp folosind Traci;
• Rețea
– Pot fi importate mai multe formate de rețea (VISUM, Vissim,
Shapefiles, OSM, Tiger, RoboCup,XML);
– Valorile lipsă sunt determinate în mod heuristic;
• Rutare
– Rute microscopice – fiecare vehicul are așa ceva;
– Alocarea dinamică pentru utilizator;
• Probabilitate ridicată
– Doar pentru standardul C++, și sunt folosite biblioteci portabile;
– Existența pachetelor de distribuție pentru Linux și Windows;
• Interoperabilitate ridicată prin utilizarea datelor XML

Aplicații incluse
SUMO reprezintă doar numele aplicației de simulare, dar de asemenea
numele pachetului software complet inculde mai multe aplicații necesare
pentru pregătirea simulării. Acest pachet include:

40
Numele aplicației Scurtă descriere
SUMO Simulare microscopică fără vizualizare; linie de comandă
GUISIM Simulare microscopică cu interfață grafică.
NETCONVERT Importarea și generarea rețelelor; citește rețelele de
drumuri din diferite formate și face conversia în formatul
SUMO.
NETGEN Generează rețele abstracte pentru simularea SUMO.
DUAROUTER Calculează cele mai rapide rute prin intermediul rețelei,
importă diferite tipuri de cereri. Efectuat de către DUA.
JTRROUTER Calculează rute folosind intersecțiile ca fiind procente.
DFROUTER Calculează rute cu ajutorul măsurătorilor din buclele de
inducție.
OD2TRIPS Importă matrici O/D și le împarte în drumuri pentru
vehicule.
POLYCONVERT Importă puncte de interes și poligoane din diferite
formate și le transformă într -o descriere care poate fi
vizualizată prin GUISIM.
AdditionalTools Mai multe tipuri de soluții pentru diferite probleme pot fi
rezolvate cu ajutorul acestor instrumente.
Tabelul 2.2 Aplicații incluse în SUMO
Sunt abordate două obiective majore de proiectare: software -ul trebuie
să fie rapid și trebuie să fie portabil. Datorită acestui fapt, primele versiuni
dezvoltate erau rulate din linie de comandă și nu exista nicio interfață grafică iar
parametrii erau ins erați manual. Prin folosirea acestei metode, viteza de execuție
era crescută. Din cauza acestor obiective, software -ul a fost împărțit în mai multe
părți. Fiecare dintre ele au un anumit scop și trebuie să fie executați în mod individual. Datorită acestei divizări, reiese o extindere mai ușoară a fiecărei
aplicații din cadrul pachetului, deoarece fiecare pachet este mai mic decât o aplicație monolitică care face totul. De asemenea, permite utilizarea unor
structuri de date mai rapide, fiecare pachet este adaptat la scopul curent, în loc de
a se folosi pachete complicate și care sunt încărcate mai greu.

41

Figura 2.5 Intersecție în SUMO

Figura 2.5 descrie o rețea de drumuri obișnuită în SUMO. Figura a fost
marcată explicit, în scopul de a explica în detaliu această secțiune. O “Banda” în
SUMO se referă la drumul care leagă două intersecții. Fiecare bandă din rețea
are un identificator unic asociat cu el. ID -urile corespunzătoare benzilor sunt
marcate în figură. De asemenea, ID -urile pentru sensul opus diferă doar prin
semnul acestora. Intersecțiile din figură sunt marcate prin A,B,C și D. Rutele
vehiculelor din SUMO sunt definite ca un șir de caractere, care este o colecție de ID-uri de benzi. De exemplu, o rută circulară care începe din intersecția A și se
termină în același punct ar fi definită ca “5704455 5710290 -5701408 –
5701331”. O bandă poate fi împărțită în mai multe. Aici, fiecare bandă este
unică.

42
2.4.3. OMNeT++

Mediul de simulare OMNeT++ a fost disponibil, în mod public, din anul
1997. Acesta a fost creat prin intermediul rețelelor de comunicații,
multiprocesoarelor și a altor sisteme distribuite teoretic ca suprafețe de aplicare,
dar în loc să se construiască un stimulator de specialitate, a fost proiectat într -un
mod foarte general. De atunci, această idee s-a dovedit a fi eficientă și
OMNeT++ a fost utilizat în numeroase domenii de la simulări de rețea de
așteptare la simulări de rețea wirel ess și ad- hoc, de la simularea proceselor de
afaceri de la persoană la persoană, comutator optic și zona de stocare simulărilor
de rețea.
OMNeT++ este un C++ pe bază de simulator de eveniment discret pentru
modelare rețele de comunicație, multiprocesoare și alte distribuite sau sisteme
paralele. OMNeT++ este o sursă publică și poate fi folosit sub Licența
Academică Publică care face software -ul gratuit pentru utilizare non- profit.
Motivația de dezvoltare OMNeT++ a fost de a produce o puternică sursă deschi să de simulare a unui eveniment discret, care pot fi utilizate de către
instituțiile academice, educaționale și comerciale orientate spre cercetarea
simulărilor rețelelor de calculatoare și sistemele distribuite sau parale. OMNeT
++ încearcă să umple golul dintre sursele deschise, software -ul de simulare
orientat spre cercetare, cum ar fi NS -2 și costisitoarele alternative comerciale,
cum ar fi OPNET. O altă secțiune a acestei lucrări prezintă o comparație cu alte
pachete de simulare. OMNeT ++ este disponibil pentru toate platformele comune
inclusiv Linux, Mac OS/X și Windows, cu ajutorul dispozitivului sau al lanțului de GCC Microsoft Visual C++.
OMNeT ++ reprezintă o abordare cadru. În loc de a furniza în mod direct
componente de simulare pentru rețele de calculatoare, rețele de așteptare sau alte
domenii, acesta oferă echipamentul și instrumentele necesare pentru scrierea unor astfel de simulări de bază. Zonele specifice de aplicare sunt susținute de diverse modele de simulare și cadre , cum ar fi Cadrul de mobilitate sau a

43
cadrului INET. Aceste modele sunt dezvoltate complet independent de OMNeT
++ și urmeze propriile lor cicluri de eliberare.
De la prima sa lansare, modele de simulare au fost dezvoltate de către
diverse persoane și grupuri de cercetare pe ntru mai multe zone inclusiv: rețele
wireless și ad- hoc, rețele de senzori, IP și Rețelele IPv6, MPLS, canale radio,
rețele peer -to-peer, Zona de stocare a rețelelor (SANs), rețele optice, rețele de
așteptare, sisteme de fișiere, interconexiuni de mare vit eză (InfiniBand) și altele.
Unele dintre modelele de simulare sunt porturile de implementări a protocolului
din viața reală, cum ar fi de rutarea daemon Quagga Linux sau stiva BSD TCP /
IP, altele au fost scrise direct pentru OMNeT ++. Într -o alta secțiune a acestei
lucrări, se vor prezenta într -o manieră mai detaliată, aceste proiecte. În plus față
de grupurile universitare de cercetare și instituțiie de cercetare non -profit,
anumite companii precum IBM, Intel, Cisco, Thales și Broadcom folosesc, de
asemen ea, OMNeT ++ cu succes în proiecte comerciale sau de cercetare interne.
OMNeT++ este un caz de simulare a rețelei separat bazat pe obiecte, cu o
arhitectură generică și poate fi utilizat pentru a simula următoarele:
• Rețele care comunică cu sau fără fir
• Modelarea protocolului
• Multiprocesoare și sisteme hardware distribuite
Un model de simulare în OMNeT++ este format dintr -un aranjament bine
construit de “module” reutilizabile care sunt conectate între ele și pot transmite
mesaje între ele. Cel mai mic b loc de construcție într -un model de simulare este
numit “modul simplu. Modulele simple sunt create în C++ și pot fi făcute să se
comporte ca atare. Modulele simple sunt grupate în module compuse. Modulele
simple și compuse comunică prin trimiterea de mesaj e în “porțile” lor prin
conexiuni care se întind între module sau alte module compuse.

44

Figura 2.6 Compunerea modulelor în OMNeT++
Un modul compus care formează un Card de Interfață de Rețea (NIC) în
OMNeT++ este prezentat în Figura 3.4. Modulele simple pot fi folosite pentru a
modela algoritmii folosind C++ de câte ori este necesar. OMNeT++ oferă intstrumentele necesare pentru a defini structura întregului sistem furnizând
următoarele caracteristici:
• Module îmbinate ierarhic
• Comunicare inter -modulară folosind mesaje prin canale
• Parametrii modulului flexibili
• Limbaj de descriere a rețelei (NED) folosită pentru a define topologia rețelei
• Editarea textului și a grafici fișierelor NED
Un model de simulare OMNeT++ constă în următoarele:
• Fișierele .ned codate folosind limbajul de descriere a rețelei (NED), care descriu poziția și conexiunile dintre diverse module. De asemenea,
valorile pentru parametrii privind modulele simple pot fi definite aici
• Fișierele .msg care conțin definițiile me sajelor care definesc diverse tipuri
de mesaje cu câmpuri de date, care ulterior sunt traduse de OMNeT++
către C++
• Fișiere sursă C++ pentru module simple

45
• Nucleul de simulare utilizat pentru gestionarea simulării și clasa de
bibliotecii pentru simulării, toate în C++
• Fișierul .ini este utilizat pentru a specifica parametrii utilizabili în mod
explicit pentru toate modulele implicate la orice nivel al ierarhiei.

2.4.4. OpenStreetMap

OpenStreetMap (OSM) este un proiect de colaborare pentru a putea crea o
hartă a lumii care se poate edita. Acesta a fost creat de către Steve Coast în
Marea Britanie, in anul 2004, și a fost inspirat de succesul Wikipedia și
preponderența hărților cu datele proprietare din Marea Britanie și din alte părți.
De atunci, acesta a cre scut la peste 2 milioane de utilizatori înregistrați, care pot
colecta date folosind dispozitive GPS, fotografii aeriene, precum și alte surse
gratuite.
Mai degrabă decât harta propriu -zisă, datele generate de proiectul
OpenStreetMap sunt considerate ca fi ind producția sa primară. Datele sunt apoi
disponibile pentru a putea fi utilizate în aplicații tradiționale, cum ar fi utilizarea sa de către Craigslist, Osm And, Geocaching, MapQuest Open, software -ul
statistic JMO, și Foursquare pentru a înlocui Google Maps. Există și roluri
neobișnuite cum ar fi înlocuirea datelor implicite incluse cu receptoare GPS.
Istoric
Steve Coast a fondat proiectul în anul 2004, concentrându -se inițial pe
cartografierea Regatului Unit. În Marea Britanie și în altă parte, guvernu l alegea
si finanța proiecte ca Ordnance Survey care a creat seturi masive de date, dar nu a reușit să le distribuie în mod liber și pe scară largă. În aprilie 2006, s-a creat
Fundația OpenStreetMap pentru a încuraja creșterea, dezvoltarea și distribuirea
de date geospațiale libere pentru oricine care dorea să le foloseasca și să le
distribuie mai departe. În decembrie 2006, Yahoo a confirmat faptul că

46
OpenStreetMap ar putea să se foloseasca de fotografie aeriană ca backup pentru
a produce harta.
În 2007, A utomotive date de navigație (AND) au donat un sistem complet
de date rutiere pentru Țările de Jos și drumurile principale pentru India si China.
La sfârșitul anului 2007, Universitatea Oxford a devenit prima organizație
majoră ce utiliza datele de pe OpenS treetMap pe site -ul lor principal.
Modalitățile de a importa si exporta datele au continuat să crească. Pănâ în
anul 2008, proiectul a dezvoltat instrumente pentru a exporta datele OSM către unitățile portabile GPS, care să înlocuiască existența lor și hăr țile neactualizate.
În noiembrie 2010, Bing a schimbat licența lor pentru a putea permite
utilizarea imaginilor de la sateliți pentru a face hărți.
In 2012, au fost lansate prețurile pentru Google Maps ceea ce a condus la
trecerea site -urilor importante către serviciile OpenStreetMap. Printre acestea au
fost Foursquare, Craiglist care au adoptat OSM, și Apple, a încheiat un contract
cu Google și a lansat o platformă de cartografiere automată care utilizeaza datele
Tom Tom si OpenStreetMap.

Software pentru vizualizarea hărților:
Browser web. Datele furnizate de proiectul OpenStreetMap pot fi
vizualizate într -un browser web cu suport JavaScript prin intermediul (Hypertext
Transfer Protocol HTTP) de pe site -ul său oficial.
OsmAnd este software -ul gratuit pentru Android și iOS, dispozitive mobile
care pot utiliza date vectoriale offline din OSM.
Hărți GNOME. Harta GNOME este un grafic front-end scris în JavaScript
și a fost introdus în GNOME 3.10. Acesta oferă un mecanism pentru a găsi
locația utilizatorului c u ajutorul GeoClue, găsește instrucțiuni de ghidare prin
GraphHopper și poate livra o listă ca răspuns la întrebări.

47
Marble este o aplicație de tip glob virtual KDE care au primit suport
pentru OpenStreetMap.
FoxtrotGPS este o hartă care permite vizualizar ea GTK+ . Este disponibil
în magaziile SHR sau Debian.
Emerillon . Un alt tip ce permite vizualizarea pe bază de GTK+.
Formatul de date
OpenStreetMap utilizează o structură de date topologic, cu patru elemente
de bază:
• Nodurile sunt puncte cu o poziție geografică, stocate ca coordonate
conform WGS 84. Ele mai sunt folosite pentru a reprezenta caracteristici
pe hartă, cum ar fi punctele de vârf.
• Modurile în care sunt afișate ordonat nodurile, reprezentând o polilinie, sau, eventual, un poligon în cazul în care acestea formează o buclă închisă.
Ele sunt utilizate atât pentru reprezentarea caracteristicilor liniare, cum ar fi străzi și râuri, și zone, cum ar fi păduri, parcuri, zone de parcare și
lacuri.
• Relațiile sunt liste de noduri, în cazul în care fieca re membru poate avea
optional un rol ( șir de caractere ) . Relațiile sunt utilizate pentru a
reprezenta relația dintre noduri și căile existente. Exemplele includ
restricții de viraj pe drumuri, căi care se întind pe mai multe căi existente.
• Etichetele. E le sunt folosite pentru a stoca metadatele despre obiectele din
hartă ( cum ar fi tipul lor, numele si proprietățile fizice ale acestora ).

2.4.5. TraCI
Traci reprezintă Interferența de Control al Traficului, iar acest lucru este
ceea ce dă acces lumii exterioa re la o simulare SUMO în curs, în timp real.
Acesta folosește o arhitectură TCP server/client pentru a furniza acces la SUMO.
Ca parte din proiectul VEINS, modulul Manager de Scenariu TraCI în OMNeT a

48
fost introdusă ca parte a cadrului MiXiM. Acest lucru ne dă posibilitatea de a
cupla OMNeT și SUMO ca în figura 2.2. Acesta permite unei simulări de rețea
care rulează în OMNeT++ să trimită comenzi TraCI care controlează simularea
traficului în SUMO. Protocolul TraCI explică în detaliu mesageria și formatul
mesajului care ar fi utilizat. Există diferite clase de comenzi Traci, cele
importante în această licență sunt enumerate mai jos:
• Returnarea valorii vehiculului: Acest set de comenzi interoghează SUMO
despre valoarea unei anumite variabile referitoare la un anumit vehicul
din pasul precedent
• Returnarea valorii rutei: Acest set de comenzi interoghează SUMO despre
informații referitoare la o anumită rută a unui vehicul din simulare.
• Schimbarea statusului vehiculului: Acest set de comenzi stabilește valoarea variabilelor legate de un anumit vehicul.

2.4.6. MiXiM ( Simulatorul Mixt)
MiXiM este un cardu de modelare OMNeT++ pentru simularea rețelelor
fixe și mobile. MiXiM reprezintă “Simulatorul Mixt”. Acesta oferă modele
detaliate ale diferitelor straturi ale mode lului OSI, împreună cu modele precise
de propagare a undelor radio și estimarea interferenței. El are, de asemenea, o
bibliotecă vastă de protocoale de rețea care pot fi incorporate în orice simulare.
Din moment ce urmează ierarhia modulară, de module simple care formează mai
multe module compuse complexe, o mare flexibilitate fiind disponibilă atunci
când vine vorba de dezvoltare de noi module compuse. De asemenea, modulele simple făcute de utilizator, pot fi adăugate în cardu, permițând utilizatorului să
modeleze module compuse personalizate. Această caracteristică este necesară
pentru punerea în aplicare a acestei licențe, unde aplicația este implementată ca
modul simplu și apoi încorporate într -un modul compus mai complex, care
definește vehiculul în sim ulare. Acesta susține o simulare de rețea cu până la
1000 de noduri.

49
Cadrul de simulare VEINS vine ca o parte din MiXiM, adăugând suport
pentru IEEE 802.11p, IEEE 1609.4 și IEEE 1609.3(WSMP).

50
3. Evaluarea tehnologiilor de comunicații VANET

Transmiterea mesajelor în mod continuu și transmiterea mesajelor doar în
cazul unui eveniment pentru V2V, joacă un rol important pentru transmiterea
informațiilor broadcast către vehicule și mașini Acest capitol tratează simularea
comunicării de la mașină la mașină în diferite medii pe o scară largă realistă (
trafic real și hartă ) bazate pe strandardul IEEE -802.11p și investighează
probabilitatea de transmitere a mesajelor în mod continuu și transmiterea mesajelor doar atunci când există o mașina defectă sau avariată.
Studierea standardului IEEE-802.11p este necesară pentru a afla daca această
tehnologie este eficientă înainte de a fi implementată în lumea reală.
3.1. Introducere
Din cauza creșterii numărului de mașini pe drumurile orașelor din majoritatea
țărilor supune orașele la riscul experimentării emisiilor de CO2, accidentelor și
ambuteiajelor din trafic care conduc la calitatea scăzută a vieții. Pentru a rezolva
aceste probleme, cer cetătorii au lucrat la mai multe soluții, una dintre ele fiind
determinată de comunicarea dintre mașini. Comunicarea de la mașină la mașină (
C2CC), cunoscută și sub denumirea de comunicare de la vehicul la vehicul (
V2V) bazată pe tehnologia wireless au f ost concepute pentru a ajuta mașinile să
“vorbească” între ele, dar și cu unitățile de drum laterale (RSU). V2V permite mai multe aplicații pentru a face drumurile convenabile și în condiții de siguranță. Pentru aplicația de securitate, V2X poate reduce ac cidentele, dar și
densitatea traficului. Printre exemplele de aplicare a siguranței se regăsesc: advertisment pentru părăsirea benzii de circulație, autoturisme obstacol,
detectarea defecțiunilor, accidente și coliziuni etc. Exemplele sunt de taxare
electr onică, sistemul inteligent de semaforizare, congestionarea traficului,
adaptarea vitezei cu control de distanță, sistemul de management al traficului etc.
pe lângă informațiile online despre trafic, informații de parcare, sistem de
navigare sunt câteva exe mple de aplicare pentru V2X pentru a ajuta șoferii.

51
3.1.1. Beaconing
Conceptul C2CC se bazează pe difuzarea informației de către toate
mașinile, ceea ce permite fiecărui vehicul să afle topologia mașinilor în timp
real. Aceste informații sunt transmise sub forma unor mesaje periodice care sunt
cunoscute sub denumirea de beacon. Acestea pot conține anumite informații
despre mașini, precum: viteza, coordonarea, accelerarea, etc..
Beaconing în VANET trebuie să radiodifuzeze într -un mod frecvent
deoarece acesta conțin e informații se modifică dinamic. Astfel pentru un sistem
bazat pe VANET, probabilitatea de semnale luminoase primite cu succes
reprezintă un parametru important.
În plus, așa cum a fost menționat anterior, standardul IEEE 802.11p este
utilizat pentru comunicațiile în VANET. IEEE 802.11p utilizează un Media
Access Control (MAC), protoc ol care se bazează pe un Carrier Sense Multiple
Access Protocol cu evitarea coliziunii(CSMA/CA). Mesajele de tip beacon sunt
trimise pe un interval fix în VANET. Cele mai multe aplicații vehiculare folosesc
10Hz pentru rata de generație, de asemenea, un beacon este de aproximativ 256
biți (inclusiv câmpurile de securitate).
Prin urmare, numeroși cercetători au lucrat la calcularea, măsurarea și
modelarea conceptului de beaconin g. Există mai multe studii care sunt
concentrate pe modelele matematice și analitice pentru beaconing și mai multe
simulări care au fost realizate pe baza conceptului de bază al VANET. De
asemenea, câteva studii au măsurat statisticile beaconing- ului în lu mea reală și,
cu toate acestea, până în prezent, nu există nicio simulare realistă pe scară largă
despre comunicarea de la mașină la mașină, într -un oraș real, cu trafic real. Din
cauza cheltuielilor ridicate și pericolele care pot apărea pentru testarea n oilor
tehnologii pentru transportul în lumea reală, simularea joacă un rol important
pentru a afla care este avantajul și eficiența tehnologiei înainte de aplicare. O
cerere reală de trafic și hartă sunt considerate de încredere în simulatorul de
mobilitate (SUMO) și comunicarea reală de la mașină la mașină, este simulată cu
ajutorul unui cunoscut simualtor de rețea (OMNeT++).

52
3.2. Scenariul simulat
În acest capitol prezentăm scenariul simulat, obținut prin mai multe zone de
trafic și hărți. După aceea, configur ația simulatorului de rețea este definită și
scenariul de simulare va fi prezentat. Rezultatele vor fi discutate în secțiunea
următoare.
3.2.1. Simulatorul de trafic
Scenariile simulate în SUMO sunt construite din două părți: rețele
rutiere(hărți), inclusiv drum uri, semafoare, intersecții etc. și cer ințele de trafic
care constau în detalii legate de mașinile implicate în trafic cum ar fi proprietăți
fizice pentru fiecare mașină, timpul de plecare și de destinație, pozițiile acestora.
Rețeaua de drumuri SUMO poate fi generată de o aplicație numită
„netgen”, care este furnizată odată cu pachetul SUMO, sau mai poate fi generată
prin importarea unei hărti rutiere digitale. Cererea de trafic poate fi definită cu
diferite surse. Pentru scenarii de proporții mari, de obicei, sunt utilizate matrici
O/D (matrici de origine/destinație). Aceste matrici descriu mișcarea dintre zonele de alocare a traficului în numărul vehiculului pe unitatea de timp.
Un set de date este utilizat pentru rețeaua rutieră și de simular e a cer erii
traficului. Figura 3.1 reprezintă rețeaua de străzi și de trafic a Bucureștiului, iar
harta a fost importată din OpenStreetMap (baza de date OSM).

53

Figura 3.1 Zonă a Bucureștiului în SUMO
Fiecare scenariu din sumo are un fișier <nume>.sumo.cfg care este asociat cu
fișierele <nume>.net.xml și <nume>.rou.xml spre a fi utilizate la începutul și
sfârșitul simulării. Schema XML folosită este descrisă mai jos :
<configuration >
<input> <net-file value="erlangen.net.xml"/> <route-files value="erlangen.rou.xml"/> <additional-files value="erlangen.poly.xml"/> </input> <time> <begin value="0"/> <end value="1000"/> <step-length value="0.1"/>
</time>
<gui_only> <start value="true"/>

54
</gui_only>
</configuration>
3.2.2. Simulatorul de rețea
Secțiunea anterioară pregătește traficul realist și harta în SUMO. În acestă
secțiune este prezentat modul de configurare a simulatorului de rețea pentru a
rula simularea VANET. Cadrul Veins implementează 802.11p în OMNeT++ cu
toti parametrii impliciți. La început, traficul de vehicule este generat în SUMO și
apoi este conectat cu simulatorul de rețea prin TraCI, iar OMNeT++ consider ă
toate mașinile ca noduri și simulează scenariul. Dacă are orice schimbare în
rețea, Veins poate schimba scenariul mașinilor din SUMO.
Traficul din București este simulat ca rețea VA NET în OMNeT++, unde
fiecare mașină comunică prin utilizarea standardului IEEE 802.11p. Principalii
parametrii care sunt folosiți în acest studiu pentru simulatorul de rețea sunt
prezentați în tabe lul 3.1.

Figura 3.2 Simulatorul de rețea OMNeT++ în cadrul unei simulări

55
Scenariul de simulare în cazul unui accident în trafic se realizează prin
transmiterea în mod continuu atunci când se produce evenimentul. Acest
scenariu se realizează folosind configurația, setul de date si de parametrii din
Tabelul 3.1
Dimensiunea mediului de simulare 3 Km
Parametrii specifici 802.11p
Puterea maximă trimisă pentru rețea 20mW
Pragul de atentuare minim pentru
semnal -89dBm
Frecvența purtătoare pentru canal 5.890 GHz
Puterea TX 20mW
Bit rate 18Mbps
Layerul Wave
Intervalul beacon 1s
Lungimea headerului 256 biți
Mobilitate
Începerea accidentului 40s
Durata accidentului 30s
Tabelul 3.1 Parametrii de simulare
3.3. Rezultatul simulărilor
Simularea este realizată cu ajutorul OMNeT++, SUMO și Veins. Mașinile
comunică cu mașinile vecine prin transmiterea informațiilor, iar astfel datele
necesare sunt colectate.
Principalul obiectiv al acestui capitol este investigarea evaluarea
performanțelor pentru transmiterea pachetelor. Pentru transmiterea pachetelor
am ales două scenarii și anume:
– transmiterea pachetelor în momentul producerii accidentului;
-transmiterea pachetelor în mod continuu (beaconing);
Pentru primul scenariu am luat o intersecție din București și am realizat o
comparație între cele două metode de transmitere a pachetelor pentru numărul de
pachete pierdute.

56

Figura 3.2 Harta intersecției

S-au efectuat trei simulări pe aceeași hartă iar numărul de vehicule a fost
schimbat de fiecare dată. În cadrul primei simulării, numărul de vehicule a fost
de 30, pentru cea de -a doua simulare n umărul de vehicule a fost de 40 și pentru
ultima simulare n umărul de vehicule a fost de 50.

Figura 3.4 Totalul pachetelor pierdute pentru 30 de vehicule

57

Figura 3.5 Totalul pachetelor pierdute pentru 40 de vehicule

Figura 3.6 Totalul pachetelor pierdute pentru 50 de vehicule

Din Figurile 3.4, 3.5, 3.6 reiese faptul că pe măsură ce numărul de
vehicule din jurul accidentului crește, pentru transmiterea pachetelor în mod
continuu (beacon) observăm că totalul de pachete pierdute cresc considerabil
ceea ce duce la netransmiterea pachetelor importante pentru atențio narea
accidentului. În cazul transmiterii pachetelor doar în cazul evenimentului există
pachete pierdute dar nu așa de multe ca pentru beaconing, ceea ce duce la

58
recepționarea pachetelor de către celelalte mașini și informarea lor în timp util
pentru a se realiza un trafic fluid, fără alte accidente.
Pentru cel de -al doilea scenariu am ales o zonă cu drum drept din
București cu un număr de 50 de vehicule . Pentru acest scenariu am realizat o
comparație între cele două metode de transmitere a datelor pentru următorii
parametrii: totalul pachetelor trimise, totalul pachetelor puse în așteptare și totalul pachetelor recepționate broadcast.

Figura 3.6 Harta drum drept

59

Figura 3.7 Totalul pachetelor trimise

Figura 3.8 Totalul pachetelor puse în așteptare

60

Figura 3.9 Totalul pachetelor recepționate broadcast
Așa cum putem observa din c ele trei figuri 3.6, 3.7 și 3.8 pentru
transmiterea în mod continuu avem foarte multe pachete trimise și recepționate
broadcast însă numărul de pachete puse în așteptare este foarte mare ceea ce
duce la o așteptare de primire a pachetelor. Pentru transmiterea pachetelor doar în cazul evenimentului, pachetele trimise și recepționate broadcast sunt doar
atunci când se produce accidentul sunt comparativ puține față de cealaltă me todă
de transmitere deoarece pachetele sunt trimise doar de acele vehicule care se află
în aproprierea indicentului și nu duce la o supra încărcare de pachete.

61
3.4. Concluzii
Acest capitol a investigat diferite simulări VANET comparând și selectând
cadre Veins care conectează SUMO și OMNET++. Utilizând, apoi, Veins,
SUMO și OMNET++ a fost făcută o a unui caz real, la scară mare , pentru
comunicarea bazată pe VANET (mașină -mașină) într-un mediu de lucru urban
cu trafic real. Mașinile circulă într -un oraș real și comunică prin 802.11p în timp
sunt colectate rezultate. Apoi, se realizează o comparație între cele două metode
de transmitere în cazul unui eveniment din circulația rutieră .
Pe baza celor două scenari i, am ajuns la concluzia că, pentru transmisia de tip
beaconing, se ocupă multă lățime de bandă ceea ce duce, în cazul unui trafic
aglomerat, la posibilitatea de a se pierde pachete. Astfel,există posibilitatea ca
informația esențială în cazul unui evenime nt din trafic nu ar mai ajunge și la
ceilalți participanți la trafic.
În cazul metodei de transmitere a datelor după ce s- a produs un eveniment,
am ajuns la concluzia că pachetele ajung doar la acele vehicule care se află în apropierea. Așadar acest lucru nu afectează întreaga rețea cu o aglomerație, iar
prioritizarea traficului se realizează eficient față de cealaltă metodă de transmitere (beaconing).

62
4. Bibliografie

[1] http://www.nhtsa.gov.
[2] VD Khairnar, SN Pradhan, “ Comparative Study of Simulation for Vehicular
Ad-Hoc Network “,International Journal of Computer Applications (0975 –
8887) Volume 4 – No.10, August 2010.
[3] Collier, W.C.; Weiland, R.J.; , "Smart cars, smart highways," Spectrum,
IEEE , vol.31, no.4, pp.27 -33, April 1994 doi: 10.1109/6.272224.
[4] Widhiasi, A.; Mohanan, V.; Pasha, M.F.; Budiarto, R.; , "Vertical Handover
Scheme for Car -to-Car Communication Based on IEEE 802.21 Standard,"
Computer Engineering and Applications (ICCEA), 2010 Second International Conference on , vol.1, no., pp.143-147, 19 -21 March 2010 doi:
10.1109/ICCEA.2010.36.
[5] IEEE 802.11p Wireless Access for Vehicular Environments, Draft Standard.
[6] Hannes Hartenstein (Editor), Kenneth Laberteaux (Editor), VANET Vehicular Applications and Int er-Networking Technologies, John Wiley & Sons
ISBN: 978 -0-470-74056 -9.January 2010.
[7] M. Fiore, J. Haerri, F. Filali, and C. Bonnet, \ Vehicular mobility simulation
for VANETS," in Proceedings of the 40th Annual Simulation Symposium
(ANSS 2007), Norfolk, Virginia, March 2007.
[8] Vaishali D. Khairnar, S. N. Pradhan, “Comparative Study of Simulation for
Vehicular Ad -Hoc Network”, International Journal of Computer Applications
(0975 – 8887) Volume 4 – No.10, August 2010.
[9] D. Schrank, B. Eisele, T. Lomax , “Urban Mobility Report 2012,” Texas
Transp. Inst., Texas A&M Univ. Syst., College Station, TX, Dec 2012.
[10] F. H. Administration, “Traffic congestion and reliability – trends and
advanced strategies for congestion mitigation,” Federal Highway Administration,
Tech. Rep., 2005.
[11] Ali Bin Tariq, “Simulation of Beaconing in Vehicular Ad- Hoc Networks”,
Master of Science Thesis, December 2011, Tampere University of Technology.
[12] H. Hartenstein and K. Laberteaux. VANET: Vehicular Applications and
Inter-Networking Technologies. John Wiley and Sons, 2009.
[13] “Assessment of the applicability of cooperative vehicle -highway automation
systems to bus transit and intermodal freight: case study, “California Partners for
Advanced Transit and Highways (PATH), 2004.
http://repositories.cdlib.org/cgi/viewcontent.c gi?article=1629&context=its/path.

63
[14] Huaqun Guo; “Automotive Informatics and Communicative Systems:
Principles in Vehicular Networks and Data Exchange”; British Cataloguing in
Publication Data ; 2009; ISBN 978 -1-60566 -338-8.
[15] LAN MAN Standards Comm ittee of the IEEE Computer Society.Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
IEEE Standard 802.11. Technical report, 1999.
[16] IEEE P802.11 -REVmaTM/D7.0, “Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications,” Revision of 802.11 -1999,
June 2006.
http://grouper.ieee.org/groups/802/11/Reports/tgp_update.htm.
[19] William Stallings Data and Computer Communications 6th edition
Publisher: Prentice Hall Copyright: 2007.
[20] "IEEE Draft Stan dard for Wireless Access in Vehicular Environments
(WAVE) – Multi-Channel Operation," IEEE Pl609.41D9, August 2010, pp. 1 –
61, 2010.
[21] Chi -Sheng Lin; Jia -Chin Lin; , "Novel Channel Estimation Techniques in
IEEE 802.11p Environments," Vehicular Technology Conference (VTC 2010-Spring), 2010 IEEE 71st , vol., no., pp.1-5, 16- 19 May 2010.
[22] van Eenennaam, M.; van de Venis, A.; Karagiannis, G.; , "Impact of IEEE
1609.4 channel switching on the IEEE 802.11p beaconing performance," Wireless Days (WD), 2012 IFIP , vol., no., pp.1-8, 21 -23 Nov. 2012.
[23] R. A. Uzcategui and G. Acosta -Marum, "Wave: A Tutorial," IEEE
Communications Magazine, vol. 47, pp. 126- 133, May, 2009.
[24] IEEE P802.11p, “Amendment 3: wireless access in vehicular environments
(WAVE),” Draft D0.26, January 2006.
[25] IEEE P1609.1, “Trial- use standard for wireless access in vehicular
environments (WAVE) – resource manager,” Draft D17, July 2006.
[26] IEEE P1609.2, “Trial- use standard for wireless access in vehicular
environments (WAVE) – security services for applicationsand management
messages,” Draft D7, April 2006.
[27] IEEE P1609.3, “Trial- use standard for wireless access in vehicular
environments (WAVE) – networking services,” Draft D22, January 2007.
[28] IEEE P1609.4, “Trial- use standard for wireless access in vehicular
environments (WAVE) – multi- channel operation,” Draft D08, July 2006.
[29] “Fcc allocates spectrum in 5.9 ghz range for intelligent transportation systems uses,” News, Federal Communications Commission, 1999.

64
[30] Noori, H “Realistic Urban Traffic Simulation as Vehicular Ad-Hoc Network
(VANET) via Veins Framework “, 12th Conference of Open Innovations
Framework Prgramm. FRUCT, Nov.2012.
[31] Bechler M, Franz WJ, Wolf L. Mobile Internet access in FleetNet.
InVert eilten Systemen KiVS 2003, 2003.
[32] Gongjun Yan, Khaled Ibrahim and Michele C. Weigle, "Vehicular Network
Simulators," In Vehicular Networks: From Theory to Practice, Stephan Olariu
and Michele C. Weigle, Eds. Chapman & Hall/CRC, 2009.
[33] Choffnes DR , Bustamante FE. Modelling vehicular traffic and mobility for
vehicular wireless networks.Technichal Report, Department of Computer
Science, Northwestern University,NWU -CS-05-03, July 2005.
[34] J. Yoon, M. Liu, and B. Noble, “Random waypoint considered harmful,” INFOCOM 2003. Twenty -Second Annual Joint Conference of the IEEE
Computer and Communications. IEEE Societies, 2003.
[35] SUMO introduction in the sourceforge website.
http://sourceforge.net/apps/mediawiki/sumo/
[36] Gongjun Yan, Khaled Ibrahim a nd Michele C. Weigle, "Vehicular Network
Simulators," In Vehicular Networks: From Theory to Practice, Stephan Olariu and Michele C. Weigle, Eds. Chapman & Hall/CRC, 2009.
[37] http://www.vissim.com/
[38] Michael Behrisch, Laura Bieker, Jakob Erdmann and Daniel Krajzewicz.
SUMO – Simulation of Urban MObility: An Overview In: SIMUL 2011, The
Third International Conference on Advances in System Simulation, 2011.
[39] C. Sommer, R. German, and F. Dressler, “Bidirectionally Coupled Network
and Road Traffic Simulation for Improved IVC Analysis,” IEEE Transactions on
Mobile Computing, vol. 10, pp. 3– 15, January 2011.
[40] S. Krau, “Microscopic traffic simulation: Rob ustness of a simple approach,”
Tech. Rep. 306, Deutsches Zentrum f ¨ ur Luft- und Raumfahrt, 1997.
[41] TraNS official website. Available: http://lca.epfl.ch/proje cts/trans
[42] Rajive Bagrodia, Richard Meyer, Mineo Takai, Yu an Chen, Xiang Zeng,
Jay Ma rtin, and Ha Yoon Song. “Parsec: A parallel simulation environment for
complex systems. Computer, 31(10):77 –85, 1998.
[43] OPNET Technologies, 2008. Available at: http://www.opnet.com
[44] Kevin Fall and Kannan Varadhan. The ns Manual (formerly ns Notes and
Documentation). VINT, 2006.
[45] OMNeT++ official website. Available: http://www.omnetpp.org
[46] OMNeT++ User Manual. Available:

65
http://www.omnetpp.org/doc/omnetpp41/manual/usman.htm
[47] S. Y. Wang, C. L. Chou, Y. H. Chiu, Y. S. Tzeng, M. S. Hsu , Y. W. Cheng,
W. L. Liu, and T. W.Ho. NCTUns 4.0: An Integrated Simulation Platform for
Vehicular Traffic. In Communication, and Network Researches," WiVec'07,
2007.
[48] Sommer, C.; German, R.; Dressler, F.; , "Bidirectionally Coupled Network
and Road T raffic Simulation for Improved IVC Analysis," Mobile Computing,
IEEE Transactions on , vol.10, no.1, pp.3- 15, Jan. 2011.Veins – Vehicles in
Network Simulation, http://veins.car2x.org/
[49] Aamir Hassan, Tony Larsson “On the requirements on models and
simulator design for integrated VANET Simulation”8th International Workshop
on Intelligent transportation System, March 2011 Hamburg Germany.
[50] Weingartner, E.; vom Lehn, H.; Wehrle, K.; , "A Performance Comparison
of Recent Network Simulators," Communicat ions, 2009. ICC '09. IEEE
International Conference on , vol., no., pp.1-5, 14 -18 June 2009 doi:
10.1109/ICC.2009.5198657.
[51] Harri, J.; Filali, F.; Bonnet, C., "Mobility models for vehicular Ad-Hoc networks: a survey and taxonomy," Communications Survey s & Tutorials, IEEE
, vol.11, no.4, pp.19- 41, Fourth Quarter 2009 doi: 10.1109/SURV.
2009.0904039.
[52] MOVE (MObility model generator for VEhicular networks): Rapid Generation of Realistic Simulation for VANET, 2007.Available at:
http://lens1.csie.ncku.e du.tw/MOVE/index.htm.
[53] Michal Piorkowski, Maxim Raya, Ada Lezama Lugo, Panos
Papadimitratos, Matthias Grossglauser and Jean Pierre Hubaux, “TraNS: Realistic Joint Traffic and Network Simulator for VANETs”, Poster at the 13th ACM Annual International C onference on Mobile Computing and Networking
MobiCom'07, Montreal, Canada, September 2007.
[54] Fiore, M.; Harri, J.; Filali, F.; Bonnet, C.; , "Vehicular Mobility Simulation
for VANETs," Simulation Symposium, 2007. ANSS '07. 40th Annual , vol., no., pp.301 -309, 26- 28 March 2007 doi: 10.1109/ANSS.2007.44.
[55] David R. Choffnes, Fabián E. Bustamante, “An integrated mobility and
traffic model for vehicular wireless networks”, VANET '05 Proceedings of the
2nd ACM international workshop on Vehicular Ad -Hoc n etworks Pages 69 – 78.
[56] Karnadi, F.K.; Zhi Hai Mo; Kun-chan Lan; , "Rapid Generation of Realistic
Mobility Models for VANET," Wireless Communications and Networking
Conference, 2007.WCNC 2007. IEEE , vol., no., pp.2506- 2511, 11- 15 March
2007 doi: 10.1 109/WCNC.2007.467.

66
[57] R. Fernandes, P. d’Orey, and M. Ferreira, “Divert for realistic simulation of
heterogeneous vehicular networks,” in Mobile Ad-Hoc and SensorSystems
(MASS), 2010 IEEE 7th International Conference on. IEEE, 2010, pp. 721– 726.
[58] H .Conceição, L. Damas, M. Ferreira, and J. Barros, “Large -scale simulation
of V2V environments,” in Proceedings of the 2008 ACM symposium on Applied
computing. ACM, 2008, pp. 28 –33.
[59] Fernandes, R.; Ferreira, M.; , "Scalable VANET Simulations with NS -3,"
Vehicular Technology Conference (VTC Spring), 2012 IEEE 75th , vol., no.,
pp.1- 5, 6-9 May 2012.
[60] A. Kopke, M. Swigulski, K. Wessel, D. Willkomm, PT Haneveld, TEV
Parker, OWVisser, HS Lichte, and S. Valentin. Simulating wireless and mobile networks in OMNeT++ the MiXiM vision. In Proceedings of the 1st international conference on Simulation tools and techniques for communications,
networks and systems & workshops, pages 1- 8. ICST, 2008.
[61] Noori, H; Badihi Olyae, B; “A Novel Study on Beaconing for VANET-
basedVehicle to Vehicle Communication: Probability of Beacon Delivery in Realistic Large -Scale Urban Area using 802.11p “,The 4th International
Conference on Smart Communications in Network Technologies,(IEEE SaCoNet 2013) Paris, France, June 17- 19, 2013.
[62] B.Zhou, J. Cao, H. Wu; , “Adaptive traffic light control of multiple
intersections in WSN -based ITS”, 978- 1-4244 -8331, IEEE, 2011.
[63] Huaqun Guo; Shen Tat Goh; Foo, N.C.S.; Qian Zhang; Wai -Choong Wong;
, "Performance evaluation of 802.11p de vice for secure vehicular
communication," Wireless Communications and Mobile Computing Conference
(IWCMC), 2011 7th International , vol., no., pp.1170- 1175, 4 -8 July 2011.
[64] Uppoor, S.; Fiore, M.; , "Large -scale urban vehicular mobility for
networking research," Vehicular Networking Conference (VNC), 2011 IEEE ,
vol., no., pp.62 -69, 14-16 Nov. 2011.
[65] OpenStreetMap, http://www.openstreetmap.org
[66] Reinders, R.; van Eenennaam, M.; Karagiannis, G.; Heijenk, G.; ,
"Contention window analysis for beaconing in VANETs," Wireless Communications and Mobile Computing Conference (IWCMC), 2011 7th International , vol., no., pp.1481- 1487, 4 -8 July 2011 doi:
10.1109/IWCMC.2011.5982757.
[67] van Eenennaam, M.; Remke, A.; Heijenk, G.; , "An analytical model for beaconing in VANETs," Vehicular Networking Conference (VNC), 2012 IEEE ,
vol., no., pp.9 -16, 14 -16 Nov. 2012.
[68] Veins, http://veins.car2x.org/

67
5. Anexă

În această anexă se descrie etapele implicate în instalarea și configurarea
instrum entelor pentru simularea VANET.

OpenStreetMap și SUMO
Pentru obținerea fișierului .osm trebuie să intrăm pe web site -ul
https://www.openstreetmap.org/ și să alegem o zonă pe care dorim să o
exportăm.
SUMO oferă o aplicație de linie de comandă numită Netconvert care este
folosită pentru a importa si genera rețele, care pot fi folosite de SUMO și alte
instrumente. De asemenea Netconvert proiectează coordonatele geografice
(latitudine și longitudine) către coordonatele x-y și aplică diferența necesară
pentru a traduce axele pentru primul cadran
Următoarea linie de comandă este folosită pentru a realiza rețeaua de drumuri
dorită
$ ./netconvert –osm-files map.osm
-o map.net.xml
–junctions.join
–remove-edges.isolated
–remove-edges.by-vclass “rail_slow, rail_fast,
bicycle, pedestrian”

68
Tabelul 5.1 descrie opț iunile utilizate în detaliu .
Opțiuni Descriere
–osm-files Numele fișierului .osm
-o Producerea fișierului .net.xml
–junctions -join Scrie informații despre intersecții
–remove -edges.isolated Ștergerea marginilor izolate
–remove -edges.by -vclass Ștergerea marginilor aferente pentru clasa
de vehicul menționat
Figura 5.1 Descrierea opțiunilor utilizate în NETCONVERT
Fișierul rezultat map.net.xml din etapa anterioară este acum folosit pentru
a genera un fișier Trips utilizând script-ul RandomTrips furnizat ca parte a
pachetului în SUMO. Acest script generează un set de cereri aleatoare pentru
două puncte din rețeaua de drumuri. Acestea sunt apoi utilizate în crearea de rute
de vehicule. Se utilizează următoarea linie de comand ă.
$ python /home/izabel/Downloads/sumo0.25.0/tools/randomTrips.py
-n map.net.xml -e 100 -l
$ pyton /home/izabel/Downloads/sumo-0.25.0/tools/randomTrips.py
-n map.net.xml -r map.rou.xml -e 100 -l
Pentru adăugarea unor detalii în plus cum ar fi clădiri, apă etc. trebuie să
ne ducem către site -ul: http://sumo.dlr.de/wiki/Networks/Import/OpenStreetMap
și să copiem într -un fișier text codurile pentru Polygons.
$ polyconvert –net-file map.net.xml –osm-files map.osm –
type-file typemap.xml -o map.poly.xml

<polygonTypes>
<polygonType id="waterway" name="water"
color=".71,.82,.82" layer="-4"/>
<polygonType id="natural" name="natural"
color=".55,.77,.42" layer="-4"/>

69
<polygonType id="natural.water" name="water"
color=".71,.82,.82" layer="-4"/>
<polygonType id="natural.wetland" name="water"
color=".71,.82,.82" layer="-4"/>
<polygonType id="natural.wood" name="forest"
color=".55,.77,.42" layer="-4"/>
<polygonType id="natural.land" name="land"
color=".98,.87,.46" layer="-4"/>
<polygonType id="landuse" name="landuse"
color=".76,.76,.51" layer="-3"/>
<polygonType id="landuse.forest" name="forest"
color=".55,.77,.42" layer="-3"/>
<polygonType id="landuse.park" name="park"
color=".81,.96,.79" layer="-3"/>
<polygonType id="landuse.residential"
name="residential" color=".92,.92,.89" layer="-3"/>
<polygonType id="landuse.commercial" name="commercial"
color=".82,.82,.80" layer="-3"/>
<polygonType id="landuse.industrial" name="industrial"
color=".82,.82,.80" layer="-3"/>
<polygonType id="landuse.military" name="military"
color=".60,.60,.36" layer="-3"/>
<polygonType id="landuse.farm" name="farm"
color=".95,.95,.80" layer="-3"/>
<polygonType id="landuse.greenfield" name="farm"
color=".95,.95,.80" layer="-3"/>
<polygonType id="landuse.village_green" name="farm"
color=".95,.95,.80" layer="-3"/>
<polygonType id="tourism" name="tourism"
color=".81,.96,.79" layer="-2"/>

70
<polygonType id="military" name="military"
color=".60,.60,.36" layer="-2"/>
<polygonType id="sport" name="sport"
color=".31,.90,.49" layer="-2"/>
<polygonType id="leisure" name="leisure"
color=".81,.96,.79" layer="-2"/>
<polygonType id="leisure.park" name="tourism"
color=".81,.96,.79" layer="-2"/>
<polygonType id="aeroway" name="aeroway"
color=".50,.50,.50" layer="-2"/>
<polygonType id="aerialway" name="aerialway"
color=".20,.20,.20" layer="-2"/>
<polygonType id="shop" name="shop"
color=".93,.78,1.0" layer="-1"/>
<polygonType id="historic" name="historic"
color=".50,1.0,.50" layer="-1"/>
<polygonType id="man_made" name="building"
color="1.0,.90,.90" layer="-1"/>
<polygonType id="building" name="building"
color="1.0,.90,.90" layer="-1"/>
<polygonType id="amenity" name="amenity"
color=".93,.78,.78" layer="-1"/>
<polygonType id="amenity.parking" name="parking"
color=".72,.72,.70" layer="-1"/>
<polygonType id="power" name="power"
color=".10,.10,.30" layer="-1" discard="true"/>
<polygonType id="highway" name="highway" color=".10,.10,.10" layer="-1" discard="true"/>
<polygonType id="boundary" name="boundary"
color="1.0,.33,.33" layer="0" fill="false" discard="true"/>

71
<polygonType id="admin_level" name="admin_level"
color="1.0,.33,.33" layer="0" fill="false" discard="true"/>
</polygonTypes>
În acest moment rutele au fost generate în fișierele .xml, iar acum trebuie
să configuram fișierele pentru sumo-gui.
Pentru a putea importa harta în SUMO trebuie să avem un anumit set de
configurații . Deschidem fișierul cu un editor text și trebuie sa avem urmă toarele
comenzi configurate:
<configuration>
<input> <net-file value="erlangen.net.xml"/> <route-files value="erlangen.rou.xml"/> <additional-files value="erlangen.poly.xml"/> </input>
<time>
<begin value="0"/> <end value="1000"/> <step-length value="0.1"/> </time>
<gui_only>
<start value="true"/> </gui_only> </configuration>

Pentru verificare scriem în terminal sumo-gui map.sumo.cfg și o să ne
deschidă harta pe car e am dorit să o export ăm.

72