Confronto fra le implementazion

Il primo test presentato riguarda una verifica dell’implementazione del sistema all’interno del simulatore iTETRIS per confrontarne le prestazioni con quelle ottenute nella versione standard di NS-3. Le figure 5.3 e 5.4 mostrano i risultati ottenuti rispet- tivamente nello scenario Andrea Costa e Pasubio nella condizione ideale di una pene- trazione totale della tecnologia di tipo full. Ciascuna delle due figure rappresenta l’an- damento dei valori in due direzioni di interesse sia per la procedura di formazione reattiva che per quella proattiva: le linee relative alle performance dei protocolli otte- nute con iTETRIS sono mostrate sul grafico in rosso, mentre quelle relative ad NS-3 sono in blu. Le linee scure si riferiscono sempre ai valori ottenuti dalla modalità reale.

Ad un primo impatto si nota che le due implementazioni tendono in generale ad avere andamenti non perfettamente identici, specialmente nello scenario Pasubio, nel quale si ha una prestazione della versione di NS-3 migliore. Questa differenza è chia- ramente del tutto prevedibile data la grande diversità nell’architettura dei due simula- tori ed è dovuta a differenti fattori. In primo luogo occorre ricordare che la gestione degli eventi è notevolmente diversa nelle due piattaforme: come illustrato nel para- grafo 3.1, l’esecuzione di una simulazione all’interno di iTETRIS è suddivisa in step temporali costanti, del valore di 25ms nel caso del protocollo decentralizzato, per cui la reazione agli eventi dei vari componenti del protocollo avviene necessariamente in istanti temporali non precisi e con un ritardo che dipende da questo intervallo di tempo.

Se ad esempio un nodo ricevesse un messaggio dopo 10ms dall’inizio di uno step di simulazione, prima di essere informato di questo evento e poter eseguire un’op- portuna risposta deve attendere la fine del ciclo, per cui reagirà con circa 15ms di ritardo. Queste limitazioni ed il loro possibile impatto sulle logiche dei protocolli non sono ovviamente presenti all’interno della versione originale implementata all’interno di NS-3, nella quale i componenti sono attivati quando necessario senza alcun tipo di ritardo. In secondo luogo, come illustrato nel paragrafo 5.2, la risoluzione utilizzata non è quella che permette di ottenere i migliori risultati in assoluto, ma è stato neces- sario scendere a compromessi fra le prestazioni ottenute dal protocollo ed il tempo fisicamente necessario per eseguire le simulazioni.

117

Figura 5.3: Confronto dell’implementazione del protocollo decentralizzato in NS-3 ed iTETRIS per lo scenario A.

Costa nelle direzioni 68° e -8°. I grafici indicano il numero di veicoli rilevati da ciascuna implementazione e quelli ottenuti con la modalità reale. Il primo grafico per ogni direzione si riferisce alla modalità di formazione dei gruppi reattiva, il secondo a quella proattiva.

0 10 20 30 Reactive 68° 0 10 20 30 Proactive 68° 0 10 20 30 40 50 60 70 Reactive -8° 0 10 20 30 40 50 60 70 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Proactive -8°

Real mode iTETRIS implementation NS-3 implementation

# of vehicles

118

Figura 5.4: Confronto dell’implementazione del protocollo decentralizzato in NS-3 ed iTETRIS per lo scenario Pa-

subio per le direzioni 70° e 153°. I grafici indicano il numero di veicoli rilevati da ciascuna implementazione e quelli ottenuti con la modalità reale. Il primo grafico per ogni direzione si riferisce alla modalità di formazione dei gruppi reattiva, il secondo a quella proattiva.

0 10 20 30 40 Reactive 70° # of vehicles 0 10 20 30 40 Proactive 70° 0 25 50 75 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Reactive 153° 0 25 50 75 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Proactive 153°

119

Figura 5.5: Confronto dell’implementazione del protocollo decentralizzato in NS-3 ed iTETRIS per lo scenario A.

Costa nella direzione -8 e Pasubio nella direzione 153°. I grafici mostrano la distanza del veicolo più lontano rilevata dal protocollo per ciascuna implementazione ed il limite della modalità reale di 170 metri. Il primo grafico per ogni direzione si riferisce alla modalità di formazione dei gruppi reattiva, il secondo a quella proattiva.

0 50 100 150 200 250 300 350 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Reactive -8° 0 75 150 225 300 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Proavtive -8° 0 75 150 225 300 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Reactive 153° 0 75 150 225 300 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Proactive 153°

Real mode limit 170m iTETRIS implementation NS-3 implementation

distance (m)

120

Vi possono essere anche altri fattori minori che possono influenzare le presta- zioni ottenute, come la diversa versione del simulatore NS-3 utilizzata all’interno di iTETRIS rispetto a quella adoperata per la raccolta dei dati nell’implementazione ori- ginaria.

Inoltre nelle diverse simulazioni è stata mantenuta la stessa configurazione dei componenti che compongono il protocollo, per ottenere dei risultati che fossero il più possibile confrontabili tra di loro. È evidente come la differente natura della piatta- forma iTETRIS possa beneficiare da vincoli temporali più laschi nelle varie fasi del protocollo in modo tale da mitigare il ritardo introdotto. Occorre però prestare parti- colare attenzione nel cambiamento di questi parametri in quanto si potrebbe modifi- care significativamente il comportamento del sistema, rendendo difficile il confronto tra i differenti risultati ottenuti.

Confrontando i tracciati ottenuti dai protocolli con il reale numero di vetture presenti si può osservare in alcuni casi una sottostima della reale quantità di nodi pre- senti nel tratto stradale, imputabile a diversi fattori. Il più importante tra questi ri- guarda il fatto che l’attività di un gruppo viene sempre terminata nel momento in cui il leader raggiunge una distanza di 20 metri dalla RSU. Superato tale limite si ha un immediato crollo del numero di nodi rilevati dal sistema in quanto potrebbero venire disattivati anche dei veicoli che si trovano ancora relativamente lontani dall’incrocio (e quindi ancora rilevati nella modalità reale).

Un altro fattore riguarda il rischio sempre presente che alcuni nodi escano anche solo temporaneamente da un gruppo a causa di un valore di direzione non conforme a quello previsto dalla RSU oppure per via di alcune iterazioni di probe fallite a se- guito di alcune perdite di pacchetti dovute ad un elevato numero di collisioni.

Questi difetti possono in generale essere in parte corretti attraverso degli inter- venti al sistema finalizzati a perfezionare la gestione del ciclo di vita dei singoli gruppi ma possono anche essere sensibilmente attenuati da una logica aggiuntiva collocata internamente alle varie RSU. Compito di tale ipotetico modulo dovrebbe essere quello di raffinare i dati ottenuti direttamente dai singoli gruppi, applicando un filtro per eli- minare variazioni improvvise o errori e per migliorare le informazioni disponibili a seconda del loro contesto e soprattutto avendo a disposizione lo stato corrente dei segnali di semaforici emessi dalla RSU.

Si consideri ad esempio il caso in cui viene rilevata la chiusura di un gruppo dotato di una velocità media particolarmente bassa contestualmente all’emissione di

121

un segnale di stop per quella direzione da parte della RSU. Una logica sufficiente- mente intelligente potrebbe facilmente intuire che in realtà i veicoli appartenenti al gruppo appena chiuso non possono avere oltrepassato l’incrocio, visto che la loro ve- locità era prossima allo zero ed il semaforo stava segnalando loro di fermarsi. Vice- versa, se la chiusura di un gruppo viene riscontrata quando le vetture hanno accesso all’incrocio è possibile rinforzare ancora per qualche secondo la loro presenza basan- dosi sulla velocità rilevata e sul tratto stradale che ancora devono percorrere prima di raggiungere la RSU.

Procedendo più concretamente all’analisi dei risultati si osserva innanzitutto l’andamento sinusoidale del numero dei veicoli presenti nelle diverse direzioni. Que- sto è chiaramente dovuto al fatto che in condizioni di traffico intenso i veicoli proce- dono dapprima ad accodarsi in attesa di poter accedere all’incrocio ed in seguito su- perano la RSU abbandonano il tratto stradale monitorato non appena ricevono un se- gnale verde dal semaforo. Nel complesso i protocolli riescono a seguire piuttosto fe- delmente il reale andamento del traffico, pur presentando sottostime e, meno frequen- temente nella versione implementata in iTETRIS, sovrastime.

Le direzioni che raggiungono valori di densità maggiore negli scenari di A. Co- sta e Pasubio sono rispettivamente quelle di -8° e 153°; incidentalmente tali tratti stra- dali dispongono anche di un maggior numero di corsie per senso di marcia (rispetti- vamente 3 e 4). Nel caso della direzione -8° si verificano frequenti picchi che ecce- dono il numero di veicoli rilevati in modalità reale. In realtà, come mostrato in Figura 5.5, tale sovrastima non è dovuta a degli errori del sistema ma è imputabile alle lunghe code che si presentano nel tratto stradale in esame: al crescere del numero di veicoli che si accodano in attesa di accedere all’incrocio, la RSU riceve frequentemente dei riscontri da gruppi a distanza elevata i cui membri superano molto spesso i 200 metri di distanza, fornendo pertanto dei dati qualitativamente migliori rispetto a quelli ideali ma limitati a una visione di 170 metri.

Nel caso dell’implementazione in iTETRIS le imprecisioni riscontrate nel tratto di direzione 153° dello scenario Pasubio sono invece sintomo dell’inaccuratezza del protocollo in condizioni di densità estremamente elevate, nonostante anche in questo caso la Figura 5.5 mostri la capacità dei sistema di lavorare su un’area più ampia ri- spetto a quella impostata nella modalità reale. Le imprecisioni non sono tali da com- promettere in maniera critica il funzionamento complessivo del sistema ma in alcuni casi, specialmente quando la densità raggiunge valori di circa 70 veicoli, si assiste ad una sottostima abbastanza rilevante, superiore anche alle 15 unità. Il fatto che tale

122

tratto stradale sia oltretutto quello che dispone del più elevato numero di corsie (quat- tro) tra tutte le simulazioni suggerisce che l’elevato numero di veicoli che si trovano a comunicare in un’area relativamente ristretta comporta necessariamente delle diffi- coltà per il sistema. Si può comunque ricavare un elemento positivo tenendo conto che nelle situazioni di elevata densità la modalità di formazione proattiva presenta una precisione leggermente migliore tra i due protocolli.

La versione NS-3 del protocollo è meno affetta da queste limitazioni e riesce spesso ad ottenere risultati migliori rispetto alla modalità reale in questa direzione, soprattutto nella seconda parte della simulazione dove trae beneficio dai dati ricevuti da veicoli che sono a distanze fino a circa 300 metri dalla RSU. Si ha però un maggior rumore, soprattutto nella modalità di formazione proattiva, nella quale in alcuni mo- menti è difficile capire l’andamento del flusso del traffico. Nonostante questo la mag- giore reattività garantita dall’architettura di questo simulatore porta inevitabilmente dei benefici in questo scenario caratterizzato da una densità di veicoli molto alta.

Osservando le differenti implementazioni si può inoltre notare come le distanze massime ottenute in NS-3, in blu, siano quasi sempre superiori rispetto a quelle in iTETRIS, mostrate in rosso. Questa discrepanza motiva in parte le minori prestazioni di quest’ultima versione ed è causata molto probabilmente dal ritardo introdotto dalla piattaforma che impedisce una reazione veloce dei nodi ai messaggi ricevuti.

Soprattutto nello scenario di A. Costa, si può notare come l’implementazione in iTETRIS presenti un risultato generalmente più stabile e con meno rumore, sia per quando riguarda il numero di veicoli rilevati, che per il valore di distanza dei nodi che partecipano alla raccolta dei dati. Questo comportamento è particolarmente accen- tuato per nella modalità proattiva di formazione dei gruppi e per la direzione 68°.

Volendo quantificare la differenza fra le prestazioni delle due versioni si è pro- ceduto a calcolare il valore del delta dai risultati sul numero di vetture rilevate ottenuti, prendendo come riferimento quelli estratti dall’implementazione in NS-3, come mo- strato in Figura 5.6. Nel grafico è mostrata la differenza media percentuale fra i risul- tati ottenuti nei due casi per ogni direzione monitorata all’interno dei due scenari. Si può notare un comportamento mediamente peggiore rispetto al riferimento, anche se i risultati acquisiti sono abbastanza variegati. Nel caso della direzione 70° di Pasubio si ha ad esempio una prestazione media peggiore per la modalità di formazione reat- tiva e migliore per quella proattiva; nella direzione -113° ed in parte anche in quella 170° di A. Costa il risultato è invece opposto. Lo scenario di A. Costa è indubbiamente più favorevole all’implementazione realizzata rispetto a quello di Pasubio.

123

Benché queste differenze siano comunque non trascurabili, si possono ritenere le due implementazioni abbastanza simili considerando soprattutto le funzionalità ag- giuntive offerte da iTETRIS, soprattutto per quanto riguarda la verifica delle euristi- che di gestione del traffico che potranno utilizzare i dati raccolti in tempo reale. Si è pertanto ritenuto accettabile l’implementazione ottenuta che, seppure non perfetta, permette comunque di ottenere risultati comparabili ed in ogni caso decisamente mi- gliori rispetto a quelli possibili con la versione standard della piattaforma iTETRIS, come mostrato in Figura 5.2.

Nel seguito di questo capitolo tutti i risultati mostrati faranno riferimento all’im- plementazione dei protocolli all’interno della piattaforma di simulazione iTETRIS.