Ottimizzazioni ad iTETRIS

Durante l’implementazione del protocollo decentralizzato ed il successivo lo sviluppo del protocollo centralizzato sono state apportate numerose modifiche al si- mulatore utilizzato per adattarlo alle particolari esigenze del progetto e per migliorare le prestazioni ottenute. Alcune di queste modifiche sono apparse subito necessarie mentre per altre è stato necessario un lungo lavoro di test per individuare il problema ed implementare una modifica. Si è cercato di creare un’implementazione di queste modifiche il più generale possibile in modo che possano essere riutilizzate in seguito per la creazione di applicazioni differenti rispetto a quelle specificatamente sviluppate per questa tesi. In seguito sono illustrati i cambiamenti più rilevanti apportati alla piat- taforma iTETRIS.

L’insieme di queste modifiche ha prodotto miglioramenti molto significativi dei risultati ottenuti, ma ha reso non compatibile la versione utilizzata in questo progetto

106

con quella standard. In particolare per poter riutilizzare l’interfaccia con iCS2 _svilup-

pata in un’altra applicazione occorre utilizzare questa versione modificata della piat- taforma. Benché questo possa creare problemi, la decisione di apportare queste modi- fiche si è resa indispensabile per ottenere risultati accettabili dai protocolli implemen- tati.

Una prima modifica molto importate è stata il cambiamento del tempo dello step di simulazione utilizzato dal simulatore3 _{durante l’esecuzione. Studiando il protocollo}

decentralizzato per poi procederne all’adattamento ad iTETRIS è infatti appasto su- bito completamente inadeguato il valore originario di un secondo e si è quindi proce- duto ad apportare le opportune modifiche sia ad iCS sia alla sua interfaccia dedicata all’interazione con i vari componendi del sistema per rendere la risoluzione configu- rabile e per ridurre il valore minimo ad un millisecondo. Per permettere la massima flessibilità nell’impostazione di questo parametro ne è stata prevista la possibilità di modifica attraverso il file di configurazione utilizzato per avviare una simulazione.

La riduzione dello step di simulazione comporta un aumento del tempo com- plessivo di simulazione sia a causa del corrispondente incremento dei cicli di iCS ne- cessari a terminarla, sia a causa della maggior quantità di eventi che è possibile gene- rare al protocollo. Durante la fase di test è stata posta particolare attenzione alla scelta del valore ottimale per i vari protocolli utilizzati al fine da ottenere un adeguato com- promesso fra le prestazioni ottenute ed il tempo impiegato dal simulatore per comple- tare l’esecuzione. In generale la scelta di una risoluzione minore aumenta le presta- zioni del protocollo, ma genera un grande incremento del tempo impiegato per termi- nare la simulazione. A titolo di esempio passando da 25ms a 5ms si ha un migliora- mento molto lieve delle prestazioni a fronte di un tempo di simulazione di quasi tre volte maggiore passando da circa un’ora e mezza a più di quatto ore. Si è scelto di utilizzare il valore di 25ms per il protocollo decentralizzato, mentre per il protocollo centralizzato si è scelta la risoluzione di 50ms, in quanto quest’ultimo si è rilevato meno sensibile alle variazioni di questo parametro. Tutti i dati presentati nel seguito di questo capitolo utilizzano questi valori, salvo diversamente indicato.

Una seconda modifica che ha influito in modo molto significativo sulle presta- zioni ottenute dal protocollo è stata una modifica nella modalità di scheduling dei

2 _{Alla descrizione di questo componente è dedicato il paragrafo 3.2.1.} 3 _{Per ulteriori dettagli si faccia riferimento al paragrafo 3.1.4.}

107

messaggi all’interno di NS-3. Confrontano le prestazioni del protocollo decentraliz- zato originale in NS-3 standard con quelle ricavate dall’implementazione in iTETRIS prima di implementare questa modifica, si ottenevano valori non soddisfacenti ed allo stesso tempo un numero di collisioni di svariati ordini di grandezza superiore. Inve- stigando la causa di questo problema si è infine scoperto che l’implementazione ori- ginale dell’interfaccia iNCI4 _{di NS-3 per la comunicazione con iCS prevedeva la sche-}

dulazione di tutti i messaggi scambiati dai nodi all’interno di uno step di simulazione all’inizio dello stesso, creando un’enorme congestione con un conseguente grande nu- mero di collisioni.

Questo vanificava qualsiasi tentativo per alleviare questo problema implemen- tata nel protocollo attraverso la scelta casuale dell’istante di invio dei messaggi. Per ovviare al problema si è aggiunta la possibilità per l’applicazione di specificare l’istante d’invio del messaggio all’interno dello step di simulazione successivo in modo tale da avere una simulazione più realistica. Per ottenere questo risultato è stato necessario modificare numerosi componenti: il server di comunicazione implemen- tato in NS-3 e la sua interfaccia con iCS per prevedere la schedulazione dell’invio dei messaggi nell’istante indicato dall’applicazione; la sottoscrizione apposita utilizzata dall’applicazione prevedendo questo valore; adattare iCS perché comunicasse oppor- tunamente questa informazione al simulatore di rete. Dopo aver implementato questa ottimizzazione le prestazioni fra le due implementazioni si sono allineate ed anche il numero di collisioni è sceso a valori comparabili fra le due versioni.

La grande influenza dei cambiamenti della risoluzione e della modalità di sche- dulazione sui risultati ottenuti è mostrata nella Figura 5.2 per due direzioni nello sce- nario di Pasubio. Nel grafico è mostrato il numero di vetture rilevato dal protocollo decentralizzato in modalità reattiva con diverse configurazioni: nella versione origi- nale in NS-3 (in nero), in quella con risoluzione di un secondo (in verde), prima della modifica alla modalità di schedulazione dei messaggi (in blu) e nella versione finale che utilizza le due ottimizzazioni precedentemente illustrate (in rosso).

In seguito sono riportate modifiche che hanno avuto un minor peso sui risultati ottenuti, ma che sono nondimeno importanti per la corretta implementazione dei pro- tocolli all’interno di iTETRIS.

108

La versione standard della piattaforma di simulazione utilizzata supporta la pos- sibilità d’invio di messaggi secondo modalità di comunicazione differenti (fra cui uni- cast, geobroadcast, topobroadcast, etc.), ma prevedeva l’implementazione della sola modalità unicast per lo scambio di messaggi. I protocolli utilizzati in questo progetto utilizzano esclusivamente la modalità di comunicazione di geobroadcast, eseguendo un eventuale filtraggio dei messaggi a livello applicativo. Per attivare il supporto di questa modalità si sono rese necessarie una serie di modifiche all’interno del solo iCS dato che in NS-3 era stata già prevista questa modalità di comunicazione. L’area di copertura di propagazione è stabilita con due modalità: la prima consiste nelle impo- stazioni fisiche del dispositivo di trasmissione all’interno di NS-3 (potenza del se- gnale, guadagno dell’antenna, etc.), mentre la seconda è un raggio di propagazione impostato dall’applicazione attraverso un parametro nella sottoscrizione per l’invio di

Figura 5.2: Confronto fra varie ottimizzazioni di iTETRIS per il protocollo decentralizzato nelle direzioni -23° e 153°

dello scenario di Pasubio. La traccia nera è il risultato ottenuto con la versione originale del protocollo in NS-3, quella verde il risultato ottenuto con la risoluzione di 1s, quella blu rappresenta il risultato ottenuto con 25ms, ma con la schedulazione originale dei messaggi ed infine la traccia rossa contiene i risultati con risoluzione di 25ms e schedu- lazione dei messaggi modificata come descritto.

0 5 10 15 20 Pasubio -23° 0 10 20 30 40 50 200 250 300 350 400 450 500 550 600 650 700 Pasubio 153°

NS-3 Standard iTETRIS 25ms iTETRIS 25ms fixed schedule iTETRIS 1s

# of vehicles

109

messaggi5_{. Un messaggio geobroadcast viene simulato in NS-3 e, nel caso sia ricevuto}

da un nodo, iCS controlla se il ricevente è all’interno del raggio di propagazione pre- visto dal mittente ed in caso affermativo consegna il messaggio all’applicazione, al- trimenti lo scarta. Il raggio di propagazione massimo è quindi sempre dettato dalle impostazioni del simulatore di rete, mentre quello minimo può essere scelto dall’ap- plicazione.

Per poter funzionare correttamente i protocolli utilizzati devono poter scambiare dati fra nodi differenti, è quindi necessario poter aggiungere un payload ai messaggi. Come è stato illustrato nel paragrafo 3.2.1, per ottimizzare la comunicazione fra l’ap- plicazione ed iCS si è deciso di inviare esclusivamente l’identità di un pacchetto me- morizzato localmente, senza la necessità della sua trasmissione completa. Per ottenere questo risultato si è modificata nuovamente la sottoscrizione per l’invio di messaggi in modo che possa contenere questo identificativo, ed il formato utilizzato da iCS per comunicare ad una applicazione la ricezione di un nuovo messaggio. Sono stati inoltre apportati i cambiamenti necessari ad iCS per supportare questo scambio di dati: questo dato non viene comunicato ad NS-3, ma rimane confinato all’interno di questo com- ponente che provvedere ad inserirlo nei messaggi ricevuti correttamente prima di no- tificarli all’applicazione. Cercando di creare un’implementazione il più generale pos- sibile si è deciso di utilizzare come formato per questo payload il tipo stringa di di- mensione variabile, in modo tale che possa essere utilizzato non solo per contenere un identificatore intero, ma anche una quantità di dati variabile ed arbitrariamente for- mattata da una particolare applicazione.

Per migliorare la gestione delle sottoscrizioni è stata prevista la condivisione del loro identificatore fra iTETRIS e le applicazioni. Questa modifica si è resa necessaria in quanto la versione originale di questo framework identifica le sottoscrizioni sola- mente con il tipo quando procede a richiedere ad una applicazione quali desidera ri- muovere. Dato che le applicazioni sviluppate contengono innumerevoli sottoscrizioni di una stessa tipologia (ad esempio nel caso di vari messaggi inviati contemporanea- mente) è necessario identificarle correttamente durante la procedura di eliminazione. Per ottenere questo comportamento iCS comunica l’identificativo all’applicazione du- rante la richiesta, la cancellazione e la conferma6 _{delle sottoscrizioni. In questo modo}

5 _{Per semplicità si considera sempre l’area di propagazione di un messaggio circolare.}

6 _{Utilizzata ad esempio per confermare la schedulazione di un messaggio nella fase di ricezione dei dati}

110

le applicazioni ed iCS condividono un identificatore univoco permettendo una ge- stione più accurata della loro vita.

Sono stati infine apportati numerose correzioni ed ottimizzazioni minori all’in- terno di iCS e dell’estensione di NS-3 con lo scopo di ridurre le risorse necessarie alla simulazione e di velocizzarne l’esecuzione. A questo fine è stata anche introdotta la sottoscrizione illustrata nel paragrafo 3.2.1, volta ad ottimizzare la comunicazione all’applicazione delle posizioni dei nodi presenti nel sistema.