Comunicazione fra i nod

Focalizzandosi sugli scenari nei quali il numero di veicoli equipaggiati con le tecnologie di comunicazione utilizzate in questo progetto è ridotto rispetto al numero totale di nodi si è cercato di sviluppare un protocollo ottimizzato alla raccolta di in- formazioni sullo stato del traffico in modo che fosse il più semplice ed estendibile possibile.

Analizzando i risultati ottenuti attraverso il protocollo decentralizzato detta- gliato in precedenza si è rilevato che il numero medio di membri all’interno di un gruppo varia in modo approssimativamente proporzionale al variare della penetra- zione della tecnologia utilizzata8_{. Questo risultato è in linea con le aspettative e non}

dipende dalla particolare implementazione o da possibili difetti nella procedura di for- mazione dei gruppi del protocollo utilizzato. Il concetto di gruppo è stato introdotto per ottimizzare la comunicazione fra veicoli e per migliorare la raccolta dei dati, ma il suo scopo viene a mancare quando il numero di membri che lo compongono è molto ridotto. L’utilità di raggruppare i singoli nodi in plotoni si riduce negli scenari nei quali è presente una scarsa penetrazione a causa dell’overhead comunque presente per la formazione e per la gestione del suo ciclo di vita. Si è quindi deciso di eliminare completamente questo concetto durante la definizione di questo nuovo protocollo.

La decisione di eliminare il raggruppamento dei veicoli può comportare la crea- zione di una comunicazione disorganizzata fra i nodi, che, essendo indipendenti e non più controllati da un gestore, potrebbero trasmettere una gran quantità di messaggi causando problemi di intasamento con il conseguente aumento delle collisioni, da cui deriva una riduzione delle prestazioni del protocollo, nel caso la concentrazione dei veicoli superi una certa soglia, che potrebbe essere anche abbastanza contenuta nei casi peggiori. Per porre rimedio a questo problema si è deciso di introdurre forti limi- tazioni sulle possibilità di comunicazione di un nodo con l’ambiente circostante.

Il primo vincolo che ci si è dati per ridurre il problema descritto consiste nella riduzione dei possibili destinatari, eliminando le comunicazioni dirette fra i veicoli che vengono limitati allo scambio di dati con i dispositivi infrastrutturali (V2I). Si è infatti ritenuto superfluo lo scambio di messaggi fra i veicoli durante lo sviluppo del protocollo, avendo deciso di non adottare politiche di routing per i messaggi e di li- mitare quindi la raccolta dei dati all’interno del solo raggio di copertura di una RSU.

97

Il secondo vincolo riguarda la logica di scambio di messaggi dei nodi: per rein- trodurre una figura di gestore che si occupa di coordinare e di controllare le comuni- cazioni si è deciso di vietare la trasmissione di messaggi da parte dei veicoli se questa non viene esplicitamente richiesta. I veicoli rimangono quindi in uno stato di inattività in assenza di stimoli ricevuti dall’esterno; solo quando ricevono un messaggio da parte di un dispositivo infrastrutturale possono trasmettere una risposta, dopo aver verifi- cato che alcune condizioni siano soddisfatte. In seguito alla ricezione del messaggio e l’eventuale invio di una risposta, il nodo ritorna nello stato inattivo. In questo modo alle RSU viene dato il completo controllo sulle comunicazioni dei nodi che parteci- pano alla raccolta dei dati.

I messaggi inviati da un dispositivo infrastrutturale per sollecitare lo scambio informazioni sono dei beacon che, similmente a quelli introdotti in precedenza proto- collo decentralizzato, contengono le direzioni alle quali è interessata la RSU. Quando un nodo riceve tale messaggio controlla se la propria direzione attuale è conformate, cioè se è compresa all’interno di una certo angolo di tolleranza, ed in caso affermativo procede ad inviare una risposta. Vi sono due differenze però rispetto ai messaggi bea- con introdotti in precedenza: questi contengono una singola direzione ed indicano al nodo un intervallo di tempo entro il quale rispondere. Le informazioni contenute in questi messaggi sono mostrate nella Tabella 4.13.

Le immediate vicinanze di una qualsiasi RSU sono le aree più critiche per il potenziale sovraffollamento di veicoli, soprattutto nel caso di penetrazioni molto ele- vate, e la conseguente quantità di trasmissioni dati che possono essere avviate con un singolo beacon inviato dalla RSU. Per limitare in modo semplice il numero potenziale di nodi che possono rispondere ad un particolare messaggio si è deciso di permettere la comunicazione ai soli veicoli che procedono in una delle direzioni controllate dalla RSU inserendo un solo valore all’interno della richiesta. Per ottenere informazioni su

Tabella 4.13: Informazioni contenute nei messaggi beacon inviati dalle RSU.

Campo Tipo Descrizione

RSUId intero Identificatore della RSU che richiede la formazione del gruppo.

Direction _{double Singolo valore di direzione al quale si riferisce il mes-}

saggio corrente.

MaxResponse _{intero Intervallo di tempo entro il quale la RSU aspetta le ri-}

98

tutte le direzioni controllate, queste vengono esplorate in messaggi beacon successivi attraverso una politica di round robin.

Il secondo parametro inviato in un messaggio di beacon dalla RSU indicata l’in- tervallo di tempo entro il quale i nodi possono rispondere. Alla fine del tempo allocato la RSU provvederà ad una nuova trasmissione per una differente direzione. Un nodo che riceve un messaggio da una RSU controlla se la propria direzione attuale è con- formate con quella indicata ed in caso negativo scarta il messaggio. In caso positivo sceglie un ritardo per l’invio del proprio messaggio di risposta casualmente attraverso una distribuzione uniforme in modo che il valore massimo possibile sia quello speci- ficato dalla RSU. È stato deciso di lasciare un piccolo delay, configurabile fra le im- postazioni del nodo, fra la trasmissione di un beacon e l’inizio dell’invio delle risposte e fra la fine delle risposte e l’invio di un nuovo messaggio dalla RSU per evitare anche la remota, ma possibile, sovrapposizione di questi messaggi. A tal fine il valore di ritardo calcolato dal nodo è limitato sia inferiormente, a questo delay, che superior- mente, al valore indicato dalla RSU sottratto il delay. Trascorso questo periodo il nodo invia la sua la sua risposta previa riverifica del controllo di conformità per evitare la trasmissione nel caso la propria direzione si sia discostata da quella prevista. In se- guito alla comunicazione il nodo ritorna in uno stato di inattività.

La trasmissione del tempo massimo di risposta all’interno dei messaggi inviati dalla RSU può sembrare superflua ma è stata introdotta per garantire il controllo com- pleto sul protocollo di comunicazione ai dispositivi dell’infrastruttura. Due RSU po- trebbero utilizzare una temporizzazione differente senza la necessità di alcun inter- vento sui singoli nodi. Questo parametro può influire in modo rilevante sulle perfor- mance del protocollo, infatti la scelta di un valore troppo breve può portare ad un aumento delle collisioni nel caso in cui molti veicoli vogliano rispondere, viceversa un valore molto lungo riduce la frequenza con le quali vengono raccolte le informa- zioni.

È inoltre possibile adattare questo parametro sia alle condizioni morfologiche del particolare incrocio, ad esempio per allocare un valore minore in una direzione con una sola corsia ed un tempo maggiore per una strada con più corsie, sia dinami- camente in base alle condizioni istantanee del traffico, ad esempio aumentando il tempo concesso nelle direzioni che al momento sono molto affollate. Nella valuta- zione di questo protocollo si è scelto di impostare questo parametro staticamente sia perché ci si è concentrati soprattutto sulle prestazioni negli scenari con basse concen- trazioni di veicoli nei quali ha poco impatto, sia perché i risultati ottenuti negli altri scenari è rimasta comunque accettabile.

99

Come introdotto nel paragrafo 2.3, occorre stabilire quando interrompere la tra- smissione delle risposte ai beacon da parte di un nodo. Un veicolo dopo essere entrato all’interno dell’incrocio potrebbe comunicare delle informazioni di scaso interesse alla RSU in quanto non dipendenti direttamente dalla condizione del traffico; per que- sto motivo è utilizzata una soglia configurabile superata la quale il veicolo risponde ad un ultimo beacon in cui indica alla RSU la sua uscita dalla raccolta dati. È inoltre importante evitare che i nodi continuino a rispondere dopo aver superato l’incrocio, è

Figura 4.6: Schematizzazione di una serie di messaggi beacon nel protocollo centralizzato. I nodi con direzione 120°

rispondo al beacon entro 300ms. Il nodo a invia l’ultimo messaggio avendo superato la soglia configurata (a). Suc- cessivamente risponde il nodo con direzione -90° entro 100ms (b). I nodi con direzione 30° devono rispondere entro 200ms. In nodo o invia il suo ultimo messaggio (c). Tornano a rispondere i nodi con direzione 120°. In nodo a ignora il beacon e rimane inattivo (d). In questo esempio i tempi di risposta ai beacon tengono conto della singola corsia nella direzione -90° e del maggiore traffico in direzione 120° rispetto a 30°.

100

pertanto previsto che, una volta terminata la comunicazione con una particolare RSU, non possano riprenderla fino a quando non ne incontrano un’altra.

In Figura 4.6 è schematizzato il funzionamento completo di questo protocollo con un esempio nel quale i tempi di risposta ai beacon sono modificati dinamicamente per illustrare le possibilità offerte.