Studio e analisi del protocollo 802 - Facoltà di Ingegneria altro working group (1609) e sono...

Facoltà di Ingegneria

Corso di Studi in Ingegneria Informatica

Elaborato finale in Reti di Calcolatori

Studio e analisi del protocollo 802.11p

Anno Accademico 2011/2012

Candidato:

GIOVANNI TOSCANO

matr. N46000690

Indice

Introduzione 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Cenni preliminari su DSRC 61.1 DSRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 IEEE 802.11p 92.1 MAC Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 PHY Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 OFDM su 802.11p . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Differenze tra 802.11a e 802.11p . . . . . . . . . . . . . . . . . . . . . 11

3 Implementazioni del protocollo 802.11p 133.1 Tecniche di realizzazione . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Software Defined Radio . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Trasmettitore 802.11p realizzato con GNU Radio e USRP2 . . 173.2.2 Ricevitore 802.11p realizzato con la piattaforma Open Air

Interface ExpressMIMO . . . . . . . . . . . . . . . . . . . . . 193.3 Modifica dei driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 802.11p tramite modifica dei driver . . . . . . . . . . . . . . . 243.3.2 802.11p di GCDC . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Confronto tra SDR e modifica dei driver . . . . . . . . . . . . . . . . 28

Conclusioni 30

Bibliografia 31

II

Introduzione

Lo scopo di questo elaborato è quello di analizzare sia il principio di funzionamentoe le nuove modalità operative introdotte dallo standard IEEE 802.11p sia alcuneimplementazioni che sfruttano questo nuovo protocollo nell’ambito degli ambientiveicolari. Lo sviluppo di 802.11p è stato reso possibile grazie all’introduzione dellabanda di frequenza DSRC (Dedicated Short Range Comunication) che ha consen-tito di fornire servizi nelle comunicazioni da veicolo a veicolo (V2V) e da veicolo ainfrastruttura (V2I).

Nel primo capitolo, in particoalre, ci soffermeremo sulla descrizione dei compo-nenti delle comunicazioni DSRC. La sicurezza stradale e la gestione del traffico sonosempre state un obiettivo importante da conseguire e a tal fine per la realizzazionedi un’architettura di comunicazione hanno lavorato sinergicamente differenti gruppidi lavoro. Il primo team di ricercatori dell’IEEE 802.11 (gruppo p), da cui prendenome l’omonimo standard, si è occupato di fornire i meccanismi, le funzioni e i servi-zi impiegati dai livelli MAC (Medium Access Control) e PHY (fisico). Tale standardfunge quindi da base e su ciò si fonda la struttura dei servizi ITS (Intelligent trans-port systems). Tali servizi avanzati dei livelli superiori, sono stati resi disponibili daun altro working group (1609) e sono conosciuti come IEEE 1609.2,1609.3,1609.4.Tale progetto fu autorizzato dalla FCC (Federal Communications Commission) cheè un’agenzia indipendente del governo degli Stati Uniti. I protocolli IEEE 802.11pe IEEE 1609.1-2-3-4 che ricoprono l’ambito delle comunicazioni interveicolari, sonoconosciuti come Wireless Access in Vehicular Environments (WAVE).

Nel secondo capitolo invece tratterò più ampiamente del funzionamento svoltodal protocollo IEEE 802.11p e si condurrà un confronto tra 802.11a e 802.11p perchèpur essendo simili sfruttano parametri diversi.

Con il terzo capitolo, invece, si apre una seconda parte di questo lavoro di ricerca.

4

Facoltà di Ingegneria - Corso di Studi in Ingegneria Informatica Studio e analisi del protocollo 802.11p

Qui ho focalizzato la mia attenzione sulle implementazioni del protocollo 802.11pe sulle tecniche utilizzate per realizzare trasmettitori. Inoltre viene effettuata unarassegna sui fattori chiave che determinano la scelta dell’implementazione ottimale.

5

Capitolo 1

Cenni preliminari su DSRC

1.1 DSRC

Lo sviluppo dello standard 802.11p è strettamente legato all’introduzione dell’ar-chitettura DSRC. 802.11p costitusce la base per il funzionamento di DSRC.Questultimo, acronimo di Dedicated Short Range Comunication, è uno standard introdot-to negli Stati Uniti dalla FCC (Federal Communication Commission) che, nel 1999,riservò 75 MHz di banda nella frequenza dei 5.9 GHz [1] (5.850 - 5.925) per sup-portare le comunicazioni da veicolo a veicolo (V2V, Vehicle to Vehicle) e da veicoloa infrastruttura (V2I, Vehicle to infrastructure). Infatti i sistemi DSRC consistonoin OBU (On Board Unit) e RSU (Road Side Unit). Il termine Short Range staad indicare una copertura di centinaia di metri, minore ad esempio di quella deicellulari.

Lo spettro DSRC è strutturato in sette canali da 10MHz. La Banda di guarda è

Figura 1.1: Spettro DSRC

di 5 MHz (una parte dello spettro DSRC non utilizzata con l’obiettivo di prevenireinterferenze). Il canale 178 (5.885 – 5.895 GHz) è riservato esclusivamente allecomunicazioni di sicurezza ed è detto canale di controllo (CCH, Control Channel)

6


che veicola gli allarmi più importanti e i beacon. E’ l’unico canale condiviso tratutti i dipositivi WAVE e realizza quindi un punto di incontro tra i nodi. I duecanali ai margini dello spettro sono riservati per applicazioni future ed usi specialicome la prevenzione avanzata degli incidenti (canale 172) e per utilizzi di pubblicasicurezza (canale 184). I restanti canali (174,176,180,182) sono di servizio (SCH,Service Channel) utilizzati per le restanti applicazioni e per le normali comunicazioni.Coppie di questi canali adiacenti possono anche essere combinate in un canale da 20MHz. Tuttavia l’esigenza di avere canali di 10 Mhz è legata all’intenzione di volerutilizzare applicazioni in parallelo e quindi ridurre in parte la congestione dei canali.Inoltre test fisici confermano che canali a 10 MHz sono migliori sia per ritardi che perl’effetto doppler riscontrati negli ambienti veicolari[2]. La banda DSRC è licenziatacioè sono poste delle restrizioni sulla tecnologia e quindi regolata da diverse normecome l’uso di un determinato standard a differenza delle bande ISM (IndustrialScientific and Medical) 900MHz, 2,4GHz e 5GHz che non sono licenziate[1].

Lo stack protocollare dell’architerruta DSRC include differenti protocolli per ognilivello [2]. A livello fisico e di accesso al mezzo, DSRC utilizza 802.11p, su cui cisoffermeremo dettagliatamente nel prossimo paragrafo. I livelli superiori sono gestitida standard definiti dal gruppo di lavoro IEEE 1609:

• 1609.4 per lo switching del canale;

• 1609.3 per i servizi di rete;

• 1609.2 per i servizi di sicurezza.

DSRC utilizza un protocollo a livello rete chiamato WSMP (WAVE Short MEssageProtocol) ma permette l’utilizzo anche di protocolli del livello rete IPv6 insieme aquelli di trasporto TCP e UDP[2]. La scelta dipende dal tipo di applicazione.

7


Figura 1.2: Architettura DSRC

8

Capitolo 2

IEEE 802.11p

IEEE 802.11p è un emendamento dello standard 802.11 che aggiunge alcune modalitàe modifica parametri del livello MAC e PHY per consentire la comunicazione negliambienti veicolari. Le modifiche riguardano principalmente lo standard 802.11a cheopera sui 5GHz. La frequenza utilizzata dal livello PHY 802.11p, infatti, non è2.4 Ghz ma 5.9 GHz. Ciò permette di sfruttare lo spettro DSRC e di effettuareoperazioni con basso overhead[1].

Lo standard IEEE 802.11p ha gli obiettivi di:

• descrivere le funzioni e i servizi richiesti dalle stazioni WAVE;

• definire delle interfacce per comunicare con i livelli superiori.

2.1 MAC Layer

Al fine di comprendere le modifiche apportante al livello MAC è necessario ricordarele differenze tra BSS, SSID, BSSID. Un BSS (Basic Service Set) è l’unità elementaredello standard 802.11 ed è costituito da un insieme di stazioni che possono comuni-care tra loro. Un Service Set Identifier (SSID) è il nome con cui la rete si identificaed è inviato tramite frame di beacon da un access point nel caso BSS infrastruttura.Il BSSID invece identifica l’indirizzo MAC (6 byte, 48 bit) dell’access point.

Per consentire di effetturare una comunicazione tra veicoli nel modo più efficientepossibile e ridurre l’overhead delle operazioni tipiche di 802.11, non sono utilizzatidal protocollo 802.11p i servizi di autenticazione, associazione e scansione attiva opassiva di access point[1]. Una novità introdotta dal protocollo è la modalità WAVE.I veicoli possono comunicare tra loro con un overhead ridotto perchè sfruttano lostesso BSSID wildcard (ogni bit del BSSID è 1, FF:FF:FF:FF:FF:FF) e lo stesso

9


canale. Ad una stazione in modalità WAVE è consentito trasmettere e ricevereframe dati con un BSSID wildcard indipendentemente dal proprio WBSS. WaveBasic Service Set (WBSS) è costituito da un insieme di stazioni (veicoli) operanti inmodalità WAVE che sfruttano un BSSID comune[1]. L’instaurazione di un WBSSavviene quando una stazione in modalità WAVE invia una beacon WAVE contenentele informazioni sul tipo di servizio e parametri necessari per autoconfigurarsi. Bastaun solo scambio della beacon WAVE per consentire a più veicoli di unirsi al WBSS.Una stazione non può appartenere a più di un WBSS. La beacon WAVE è ricevutadalle stazioni e inviata ad altre per aumentare il numero elementi appartenenti alWBSS. Questa, quindi, viene creata da un veicolo che ne fa richiesta tramite beaconWAVE e resta attiva anche se il primo veicolo non c’è più. Cessa di esistere quandonon ci sono più veicoli che la compongono. La wildcard BSSID è utilizzata dallestazioni per comunicazioni sicure, sono ricevuti da tutti le stazioni e senza la necessitàdi appartenere ad uno specifico WBSS[1].

Il sottolivello MAC è equivalente a quello IEEE 802.11e EDCA [3] (EnhancedDistributed Channel Access). L’ECDA mantiene i meccanismi di riscontro (ACK) eRequest To Send/Clear to Send (RTS/CTS) ed aggiunge la possibilità di sfruttareuna Transmission Opportunity (TXOP). Pertanto i messaggi sono classificati indifferenti ACs (Access Categories), dove AC0 ha la priorità più bassa e AC3 la piùalta.

2.2 PHY Layer

802.11p apporta delle modifiche ad 802.11a. La tecnica di modulazione impegataè quindi OFDM . Come detto precedentemnte la frequenza operativa è spostatada 5 GHz a 5.9 GHz. Questo per consentire l’utilizzo dello spettro DSRC e dei 7canali da 10 MHz (anzichè 20 MHz per 802.11a). Rispetto al livello MAC che èaggiornabile tramite software, una modifica radicale del livello PHY comporterebbeun cambiamento radicale dello standard[1].

2.2.1 OFDM su 802.11p

La tecnica di modulazione adottata da 802.11p è OFDM acronimo di Orthogonal Fre-quency Division Multiplexing e consiste in un tipo di modulazione a multi-portante,che utilizza cioè un numero elevato di sottoportanti tra loro ortogonali. Sono uti-lizzati 7 canali di 10 MHz, suddivisi in 52 sottocanali, di cui 4 sono utilizzati per

10


operazioni di controllo e i restanti per trasmettere dati. Ogni portante è modulataattraverso una modulazione di tipo convenzionale(BPSK,QPSK,16-QAM,64QAM).Il sistema è reso molto più resistente all’ interferenza intersimbolica (ISI) perchètrasmette ad una bassa frequenza per simbolo.

Figura 2.1: Tassi trasmissivi disponibili in un canale[2].

2.3 Differenze tra 802.11a e 802.11p

A livello fisico il protocollo 802.11p disserisce da 802.11a da due aspetti fondamentali:La frequenza operativa è 5.9 GHz anziché 5GHz e la durata di un simbolo OFDMè raddoppiata da 4 microsecondi a 8 microsecondi[4]. Le costanti temporali, quindi,sono raddoppiate in modo da dimezzare la banda occupata a 10 MHz e raddoppiareil tempo di guardia tra simboli OFDM. Così è evitata l’interferenza intersimbolicadovuta all’aumentata dispersione temporale causata dalla mobilità.

11


Figura 2.2: Differenze tra 802.11a e 802.11p

12

Capitolo 3

Implementazioni del protocollo 802.11p

3.1 Tecniche di realizzazione

Il presente lavoro di ricerca si pone come obiettivo fondamentale quello di effettuareun’analisi approfondita delle implementazioni del protocollo 802.11p esaminandolesotto plurimi aspetti. La scarsa produzione di chipset commerciali che supportano lostandard IEEE 802.11p ha portato il settore della ricerca ad analizzare le prestazio-ni di 802.11p attraverso strumenti di simulazione come ad esempio NS-2 (NetworkSimulator). Quest’ultimo crea un ambiente di simulazione per i differenti protocollidella rete (TCP, UDP, WLAN). Nelle simulazioni, la rete è tipicamente costituitada un’alta densità di veicoli che si scambiano informazioni o in direzioni oppostelungo un percorso rettilineo oppure in prossimità di incroci ed effettuando quindiun’analisi sulla performance. Tuttavia, solo attraverso esperimenti reali si possonovalutare le prestazioni e la robustezza dello standard. Una prima possibile soluzio-ne per realizzare prototipi può essere quella di utilizzare una tecnica che permettadi costruire trasmettitori e/o ricevitori radio non più hardware ma quasi completa-mente software. Si utilizza un’antenna che riceve il segnale modulato alla frequenzadi 5.9 GHz, un demodulatore che riporta il segnale in banda base e un blocco diconversione analogico-digitale che converte il segnale continuo in segnale numerico.La restante parte hardware, programmabile, viene controllata via software. Taletecnologia prende il nome di Software Defined Radio (SDR) e attraverso l’utiliz-zo di schede, permette di avere un elevato grado di flessibilità nella realizzazione emodifica del livello fisico e di accesso al mezzo. Sebbene offra dei vantaggi per laprototipazione, il costo da sostenere è molto elevato. Una significativa implemen-tazione tramite software defined radio di 802.11p è un trasmettitore sviluppato dairicercatori del Centro di Ricerca per le Telecomunicazioni di Vienna e l’Università

13


del Salento che combina GNU Radio (software) con USRP (Universal Software Ra-dio Peripheral, hardware). Un ricevitore invece è stato realizzato al Sophia Antipolisutilizzando la piattaforma OpenAirInterface ExpressMIMO sviluppata da Eurecome Telecom ParisTech. Un’altra soluzione prevede l’utilizzo di schede di rete wirelessconformi allo standard IEEE 802.11, facilmente reperibili in commercio e a bassocosto. Attraverso la modifica dei driver è possibile configurare i parametri hardwarein maniera opportuna per operare in 802.11p. Alcune implementazioni fanno usodei driver ath5k delle schede WLAN Atheros che possono supportare 802.11p per-ché sono in grado di operare alla frequenza di 5.9GHz. Nei prossimi paragrafi cisoffermeremo più ampiamente sulla descrizione di alcune piattaforme SDR e sullaloro architettura, come sono stati realizzati i prototipi e analizzeremo la modificadei driver che sfruttano lo standard oggetto di questo elaborato.

3.2 Software Defined Radio

Software Defined Radio è un sistema di comunicazione dove i componenti che sonotipicamente realizzati in hardware sono invece costruiti utilizzando software. I pro-gettisti per rendere più efficace questa piattaforma hanno utilizzato solo i componentibase di un sitema di trasmissione, riducendo al minimo i componenti elettronici. Uti-lizzando tecniche software di elaborazione dei segnali digitali, ad un certo punto dellacatena di ricezione il segnale deve essere digitalizzato e passato al dominio software.Nelle schede di rete wireless, invece, l’elaborazione dei segnali avviene in hardware.La scelta di quello che dovrebbe essere realizzato in hardware e in software dipendedalle caratteristiche dell’implementazione. Realizzare un dispositivo di questo tiporichiede che siano rispettate le seguenti condizioni:

• L’antenna deve essere compatibile ad operare alla frequenza di interesse;

• I convertitori ADC e DAC devono avere una frequenza di campionamentodue volte più grande la frequenza del segnale di interesse (per il Teorema delCampionamento);

• La parte software del sistema deve avere abbastanza potenza di elaborazioneper gestire tutti i segnali.

Nel nostro caso la frequenza portante dell’antenna è di 5,9 GHz e quindi i convertito-ri per lavorare in modo corretto dovrebbero avere una frequenza di campionamentoalmeno pari a 11,8 GHz! Attualmente è impossibile ottenere tutti questi campioni

14


Figura 3.1: Schema di funzionameto dei Software Defined Radio

e quindi dopo aver ricevuto il segnale tramite l’antenna, un demodulatore opera aduna frequenza intermedia (IF) a quella della portante ed ottiene così un numerominore di campioni. Il passo successivo è la digitalizzazione. La parte hardwaredi un sistema Software Defined Radio è costituita da schede sulle quali è integratoun microprocessore general purpose chiamato Field Programmable Gate Array (FP-GA) o un Digital Signal Processor (DSP), convertitori analogico-digitale (ADC) edigitale-analogico (DAC), ricevitori e trasmettitori. L’hardware delle schede wire-less invece è costituito da dispositivi Application Specific Integrated Circuit (ASIC)creati appositamente per risolvere un’applicazione ben precisa (specific purpose) esvolgere le funzioni necessarie.

I DSP sono microprocessori specifici ed hanno un’architettura ottimizzata perl’elaborazione dei segnali. Ad esempio in un sistema di elaborazione di segnali mul-timediali i DSP svolgono svariate operazioni matematiche tramite tipici algoritmi.Forniscono anche supporto ad altri circuiti come ai microcontrollori. Infatti l’elabo-razione dei segnali un’attività che richiede molte operazioni che non possono essereeseguite tutte da un solo dispositivo. Anche i microprocessori general purpose pos-sono eseguire gli stessi algoritmi ottimizzati di un DSP ma non sono utilizzabili sudispositivi mobili. Tipicamente sono utilizzati in sistemi real-time e di streaming.

15


Gli ASIC sono circuiti integrati personalizzabili per funzioni specifiche. La pro-gettazione di questi circuiti è molto costosa mentre la produzione in larga scalaè vantaggiosa rispetto ad altri. Sono molto veloci ed hanno un consumo energe-tico basso. La funzionalità specifica degli ASIC è fornita attraverso un hardwaredescription language (HDL). Sono utilizzati molto nell’elettronica di consumo.

Gli FPGA sono circuiti integrati e possono essere configurati dall’azienda produt-trice oppure dall’utente. Contengono dei componenti logici programmabili chiamatilogic blocks ed un sistema di collegamento che permette di connettere i blocchi traloro. Anche la loro configurazione è quindi realizzata tramite (HDL) come per gliASIC. Gli FPGA possono essere utilizzati per implementare qualsiasi funzione chepossono svolgere gli ASIC. Inoltre permettono un alto grado di efficienza ed hannoottime caratteristiche per elaborazioni digitali complesse. Sono molto utilizzati neiprototipi perchè in caso di errori possono essere riprogrammati.

Come si può notare dalla figura 2, gli FPGA costituiscono un ottimo compro-messo tra efficienza e flessibilità e per questo motivo sono i più utilizzati nellaprototipazione e quindi sulle schede SDR.

Figura 3.2: Efficienza e flessibilità tra architetture differenti

16


3.2.1 Trasmettitore 802.11p realizzato con GNU Radio e USRP2

Un importante lavoro sull’implementazione del protocollo 802.11p è stato condottodal Centro di Ricerca per le Telecomunicazioni di Vienna e l’Università del Salen-to[4]. La scheda utilizzata USRP2 (Universal Software Radio Peripheral versione2) prodotta attualmente dalla Ettus Research ed in grado di lavorare perfettamentecon il framework SDR GNU Radio. Le principali caratteristiche della motherboardutilizzata sono:

• FPGA contenente due microprocessori RISC a 32 bit;

• 2 ADC a 14-bit;

• 2 DAC a 16-bit;

• un DDC (Digital Down Converter) con rapporti di decimazione programmabili;

• un DUC (Digital Up Converter) ;

• un DDC (Digital Up Converter);

• un’ interfaccia Gigabit Ethernet;

• un’ interfaccia seriale da 2 Gbps high-speed;

• Sistema multicanale MIMO con 8 antenne;

• 1 MB SRAM.

Tutti questi componenti lavorano con un clock a 100 MHz. Il ricetrasmettitore ècostituito da una daughter board da collegare alla motherboard e per questa imple-mentazione è stata scelto il modello XCVR-2450 che ha le seguenti caratteristiche:

• 30 MHz di banda in trasmissione e ricezione;

• frequenza di lavoro da 2,4 a 2,5 GHz e da 4,9 a 5,9 GHz;

• potenza trasmissiva di 100 mW (20dBm) ;

• oscillatore locale indipendente in trasmissione e ricezione;

• controllo automatico del guadagno fino a 70 dB;

• 16 linee ingresso/uscita per il controllo di dispositivi esterni come antenne eswitch.

17


Gnu Radio è un Software Defined Radio ed è costituito da un insieme di modulisoftware liberi ed open-source[9]. Gnu Radio fornisce dei blocchi per l’elaborazionedei segnali per implementare componenti hardware. Quindi attraverso una libreriadi blocchi e degli strumenti per poterli collegare, il programmatore realizza un gra-fo in cui i nodi rappresentano i blocchi e gli archi rappresentano il flusso dei dati.Le applicazioni GNU Radio sono prima scritte in nel linguaggio di programmazio-ne Python e C++[9]. La metodologia che è stata adottata è quella di scrivere, incodice MATLAB, l’implementazione del trasmettitore. Questo perché l’utilizzo delframework GNU Radio è abbastanza complesso e MATLAB invece è un linguaggiodi programmazione facile da usare e versatile. Successivamente ogni blocco deve es-sere testato e confrontato con il corrispondente blocco MATLAB[4]. Per realizzareuna trasmissione OFDM, GNU Radio mette a disposizione dei blocchi OFDM imple-mentati nativamente. Il generatore OFDM è molto semplice ed esegue le principalioperazioni[4]:

• symbols mapping: crea una costellazione di simboli. Esso traduce il payloadin simboli secondo una delle modulazioni disponibili (BPSK, QPSK, 16QAMor 64QAM);

• IFFT: esegue la trasformata inversa di Fourier;

• cyclic prefix: è utilizzata nell’intervallo di guardia per eliminare l’interferenzainter-simbolica dal precedente simbolo;

• scaling: Normalizza alla potenza media del segnale;

• traning sequence: prende in ingresso una sequenza da una tabella statica ela inserisce davanti ad ogni simbolo OFDM. Si noti, in caso di sistema reale,la sequenza di training deve essere inserita una sola volta prima del primosimbolo OFDM della frame.

Questi blocchi sono stati scritti interamente in C++. Lo schema a blocchi del

Figura 3.3: Blocchi OFDM disponibili in GNU Radio

trasmettitore è formato da[4]:

18


• MAC and PLCP header: La costruzione della frame è stata eseguita utilizzan-do il linguaggio Python;

• CRC-32: l’algoritmo disponibile in GNU Radio non è conforme allo standarde quindi ne è stato scritto uno in C++;

• scrambler: scritto in python, permette la trasmissione e la ricezione di daticriptati. Il campo Data è messo in XOR con una sequenza scrambler ottenutada uno script Python;

• convolutional Encoder: trasmettendo un numero maggiore di bit del segnaleoriginale si introduce una certa ridondanza che può essere utilizzata per deter-minare il segnale originale in presenza di un errore. L’encoder ha n sommatorimodulo-2 e 2 generatori polinomiali g0=1338 e g1=1718 con rate R = 1/2 cioè2 bit in uscita per 1 in ingresso. Chiamate A e B le uscite la sequenza correttadi uscita è [A(1),B(1)],[A(2),B(2)] e così via;

• interleaver: esegue due permutazioni consecutive sui bit codificati di un singoloblocco OFDM. La prima assicura che i bit vengano mappati su sottoportantinon adicenti. La seconda assicura che i bit adiacenti codificati vengono mappatialternativamente sul bit meno e più significativo della costellazione;

• symbols mapping: divide il flusso di bit proveniente dall’interleaver in gruppidi N bit in base alla modulazione utilizzata;

• pilots: ad ogni input è associato un simbolo OFDM;

• permutation carriers: permuta gli ingressi ed aggiunge zeri.

In figura 3.4 sono mostrati i blocchi che compongono il trasmettitore. Gli ultimiblocchi con bordo tratteggiato sono già stati discussi precedentemente.

L’installazione dell’ambiente GNU Radio 3.22 è avvenuta su un PC con siste-ma operativo GNU/Linux (Ubuntu 8.10) e la scheda USRP2 con daughter boardXCVR2450 è stata collegata all’interfaccia ethernet del PC.

3.2.2 Ricevitore 802.11p realizzato con la piattaforma OpenAir Interface ExpressMIMO

Il ricevitore è stato sviluppato da Eurecom e Telecom ParisTech. A differenza di altrepiattaforme SDR , la scheda OpenAirInterface ExpressMIMO è costituita da DSP

19


Figura 3.4: Diagramma a blocchi del trasmettitore

indipendenti[6]. Altri vantaggi sono l’incremento della capacità di rete, manuten-zione ad un costo ridotto ed uno sviluppo di nuovi servizi più veloce. I componentiprincipali sono:

• 4 ADC;

• 4 DAC;

• supporto all’elaborazione multimodale fino ad 8 differenti canali (Il passaggiotra due canali viene effettuata in fase di esecuzione);

• GSM;

• UMTS o LTE;

• DSP indipendenti che sono controllati da un processore SPARC LEON3 a 32bit della Gaisler Aeroflex.

Tutti i componenti sono connessi tramite una Advanced Virtual Component In-terface (AVCI). I dispositivi DSP sono formati da Control Sub-System (CSS), Pro-cessing Unit (PU) e Memory Sub-System (MSS). CSS è comune a tutti i DSP edè specializzata attraverso parametri. Per ricetrasmettitori che utilizzano pacchetti

20


brevi come impone 802.11p le caratteristiche CSS quali trasferimenti DMA in paral-lelo su più PU, preparazione del comando successivo nei registri di controllo mentrela PU è occupata e la distribuzione del flusso di controllo da parte della UC sono digrande importanza. UC non è stata integrata in CSS quindi il flusso è gestito dalprocessore LEON3. L’architettura della piattaforma è costituita da:

Figura 3.5: Architettura DSP standardizzata

• VCI RAM: memorizza le tabelle delle permutazioni dell’deinterleaver ed anchei campioni del segnale d’ingresso;

• front-end processor (FEP): contiene un’unità di elaborazione vettoriale edun’unità che calcola la DFT/IDFT;

• channel decoder: include un decodificatore Viterbi usato per la decodifica dicodici convoluzionali nel caso siano necessari elevati guadagni di decodifica delsegnale;

• deinterleaver: esegue le operazioni inverse di un interleaver per distribuireerrori sull’intero simbolo OFDM ricevuto;

• preprocessor: connette l’antenna radio esterna con la parte di elaborazione.

21


Figura 3.6: Piattaforma OpenAirInterface ExpressMIMO

La parte software della piattaforma è una libreria C++ che consente di emulare tuttele funzioni di elaborazione in banda base del ricetrasmettitore in un ambiente pura-mente software. Tale libreria prende il nome di libembb (Library for ExpressMIMOBaseBand).

La metodologia adottata è comunque realizzare un flusso sequenziale di blocchiscritti in C costruiti con libembb. La libreria di emulazione libembb presenta lestesse primitive funzionali che sono disponibili sull’ hardware reale e accessibile at-traverso le stesse interfacce. Anche i processori DSP hanno un insieme di funzioniC++ che permettono di eseguire operazioni, restituire valori della PU e operazionidi trasferimento. Per ottenere dati accurati sapendo che i DSP elaborano contempo-raneamente, un approccio comune è la co-simulazione HW / SW con simulatori qualiModelsim[6]. Infine il ricevitore viene programmato ed eseguito sulla piattaformahardware.

Analizziamo come è stato realizzato il ricevitore sulla piattaforma ExpressMIMO.La struttura di un pacchetto 802.11p è composta da una parte costante che com-prende preambolo (Short Training Symbol per la sincronizzazione, Long TrainingSymbol per il canale e un campo Signal per specificare come dovrà essere codificatoil messaggio trasmesso) ed una parte variabile di simboli OFDM. Per la sincronizza-zione dei pacchetti il preprocessore genera un interrupt non appena sono disponibili640 nuovi campioni[7]. Sono utilizzati un rilevatore di energia combinato con uncorrelatore basato su FFT (tra 256 campioni in arrivo e i 160 campioni dell’ STS

22


Figura 3.7: Struttura di una frame

più zeri fino a 256) per sincronizzare STS noti. Ogni picco rilevato indica il puntodi inizio di un pacchetto. La dimensione della finestra è quindi di 256 campioni e ilFront-End Processor (FEP) esegue lo shift conoscendo la dimensione di un simboloOFDM. Inoltre il FEP calcola l’energia, la trasformata e l’antitrasformata discretadi Fourier, il prodotto e l’argomento massimo della correlazione. Dopo il confrontocon un valore di soglia dell’energia si passa alla stima del canale che in questo caso èeseguita dal microprocessore LEON3[7]. La stima del canale prevede l’utilizzo di unpreambolo noto e la conseguente stima del canale partendo dal segnale ricevuto. Seper alcuni simboli (dette portanti pilota) sono stati trasmessi un set di valori noti,possiamo stimare l’effetto del canale su quelle sottoportanti e quindi, per interpola-zione (se le portanti pilota sono disposte lungo tutto il canale) di tutto lo spettro delcanale. L’interpolazione comporta uno sforzo di calcolo notevole e quindi in questoprogetto si è deciso di fare una stima iniziale della portante pilota e una successivacorrezione in ampiezza e fase viene applicata ai quattro pettini di portante. Per larilevazione dei campi Signal e Data sono richiesti il FEP, il Deinterleaver e il Chan-nel Decoder. Il campo Signal contiene il tipo di modulazione, il numero di simbolicontenuti nel campo Data, coding rate, la lunghezza della PPDU (tra 0 e 4095 by-te). Quando il messaggio è ricevuto il decodificatore Viterbi opera sul messaggio elo trasferisce al livello MAC.

3.3 Modifica dei driver

Un’altra tecnica per implementare il protocollo 802.11p è quella di modificare op-portunamente il funzionamento della scheda wireless andando ad agire sul driver.Infatti i driver permettono di realizzare una parte del livello MAC. Tramite un’in-terfaccia API (Application program Interface) è possibile modificare i parametri

23


hardware e accedere al livello PHY e MAC. Tuttavia per modificare i driver è neces-sario possedere il codice sorgente tramite cui il programamtore può effettuare questeoperazioni. La maggior parte dei driver sono scritti per sistemi operativi Linux equindi come conseguenza sono open-source. Il che costituisce un vantaggio per laloro proprietà di essere facilmente accessibili. Il riuso dei meccanismi , utilizzati inprecedenza per modificare i driver, è problematico in quanto i driver sono scritti perspecifici circuiti. Non si prestano pertanto ad un impiego generale, il che costituisceun deterrente non trascurabile. Per ovviare a questo inconveniente è stato ideatoil progetto SoftMAC. Questo si pone l’obiettivo di astrarre le funzioni specifche deidispositivi e renderle generali in modo da rendele più ampiamente fruibili. La sceltadelle schede wireless da utilizzare dipende dalla loro configurabilità. Il chipset piùutilizzato è Atheros.

3.3.1 802.11p tramite modifica dei driver

Un altro importante lavoro sull’implementazione del protocollo 802.11p è stato con-dotto dall’Istituto delle Telecomunicazioni dell’ Università di Aveiro che ha esegui-to un’implementazione del livello fisico 802.11p[8], basata sulla modifica dei driveropen-source ath5k e ha effettuato una serie di esperimenti sia in LOS(line of sight)e NLOS(non-line of sight). Il sistema è costituito:

• un computer Single-board (ALIX3D3);

• schede wireless IEEE 802.11a/b/g;

• schede wireless IEEE 802.11p;

• GPS;

• Debian Linux Squeeze;

• driver modificati ath5k;

Ad oggi, il codice sorgente dei driver modificati non è stato reso disponibile. Gli au-tori dicono che una prima versione disponibile potrebbe essere rilasciata nel 2014 maciò non è stato ancora concesso. La prima dimostrazione viene eseguita utilizzandotre OBU (On board Unit): due ricevitori video, che operano su diversi canali, e unostreamer che è in grado di commutare su entrambi i due canali. Inoltre la piattafor-ma è in grado di trasmettere il video in tempo reale dai veicoli davanti ad essa inmodo che ostacoli come camion di grandi dimensioni possono diventare trasparentiai veicoli dietro di loro.

24


Figura 3.8:

3.3.2 802.11p di GCDC

Grand Challenge Driving Cooperative (GCDC) è una competizione tra team inter-nazionali per fornire la più efficace cooperazione di sistemi V2I in scenari di trafficopredeterminati. E’ una sfida internazionale e unica nel campo della guida coopera-tiva. Il GCDC ,infatti, mira ad accelerare l’attuazione di tali sistemi e a contribuirein modo significativo alla soluzione di problemi di sicurezza, efficienza e traffico intutto il mondo[12]. GCDC ha utilizzato con successo 802.11p nelle comunicazioniV2V e V2I sfruttando driver modificati di ath5k (il cui sorgente è disponibile susito gcdc.net). Lo stack contiene i driver per le schede wireless Atheros modificatie un demone in user-space che permette di comunicare da V2V o V2I utilizzandoil protocollo CALM. E’ descritto nella documentazione come un generico, leggero,open-source IEEE 802.11p per Linux, basato sulla progetto CVIS originale. CVIS(Cooperative Vehicle-Infrastructure Systems) è un progetto partito nel febbraio 2006e terminato nel 2010 con 60 partner partecipanti . Il progetto è stato coordinato daERTICO – ITS Europe. E’ basato sullo standard CALM (Communications Accessfor Land Mobiles) e fornisce una completa interoperabilità fra diversi produttoridi auto[11]. L’implementazione del progetto CVIS richiedeva hardware costoso, nonmolto diffuso che non sarebbe stato prodotto a lungo. Inoltre i componenti hardwareerano closed-source (hardware abstaction layer) e non potevano essere distribuiti

25


come open-source o modificati. Tuttavia GCDC è riuscita a risolvere i problemiriguardanti i livelli più bassi e a sperimentare un’implementazione Linux di 802.11popen-source. CALM è un insieme di protocolli, procedure e processi di gestione per

Figura 3.9: Stack di comunicazione GCDC[12]

servizi ITS e non è implementato ai livelli 1 e 2. Questa funzione spetterebbe aiproduttori di schede. I livelli PHY e MAC sono conformi all’ IEEE 802.11p. PerGCDC a livello MAC è necessario solo un indirizzo di broadcast. Non ci sono ACK,RTS, CTS e di conseguenza nessun NAV. Ogni veicolo GCDC opera nel suo canaledi controllo (CCH) con 10 MHz di banda, ma deve essere pronto ad operare nei ca-nali di servizio (SCH), in modo da tenere aperta la possibilità di utilizzare un canalediverso nel caso in cui il carico di traffico sia troppo elevato. Il software open-sourcedistribuito contiene aggiornamenti ai moduli kernel per il supporto IEEE 802.11p:

• ath: modifica dei driver del kernel per le schede WLAN basate su chipsetAtheros;

• mac80211: modifica dei driver mac80211 del kernel. Mac80211 è un frameworkcon il quale gli sviluppatori di driver possono scrivere driver per dispositiviwireless SoftMAC[14]. Questi dispositivi permettono un controllo maggio-re dell’hardware permettendo di gestire e generare le frame 802.11 in soft-ware. Mac80211 implementa le funzioni di callback per i dispositivi SoftMAC.Mac80211 poi dipende da cfg80211 sia per la registrazione al sotto sistema di

26


rete e per la configurazione. La configurazione è gestita da cfg80211 sia attra-verso nl80211 e wireless extensions. Nl80211 (netlink interface) è un headerche insieme a cfg80211è destinato a sostituire wireless extensions[14].

Figura 3.10: Framework Linux Wireless

27


3.4 Confronto tra SDR e modifica dei driver

Il confronto tra SDR e modifica dei driver risulta imprescindibile e un punto di par-tenza ineludibile per chi voglia implementare il protocollo 802.11p. Per entrambele tipologie emergono vantaggi e svantaggi. In questo paragrafo quindi, si focalizzal’attenzione sulle loro peculiarità con l’obiettivo di comprendere quale sia la soluzio-ne ideale nel contesto delle reti veicolari. Pertanto, si mostreranno le prerogative checonsentano la scelta di un’implementazione anziché un’altra. La selezione della piat-taforma ottimale, oltre ad essere legata all’utilizzo finale, dovrebbe essere condottaprendendo in considerazione le seguenti caratteristiche: L’aspetto economico dellapiattaforma è un primo parametro per la scelta. Il costo dei sistemi di tipo SoftwareDefined Radio è generalmente molto elevato anche se è possibile trovare in commer-cio versioni più economiche ma con funzionalità di base. Al crescere del numero didispositivi coinvolti nella realizzazione, il costo di produzione diventa elevato. Con-trariamente il costo complessivo dell’hardware richiesto dalle piattaforme, basate sumodifica dei driver, risulta essere relativamente basso poiché la notevole diffusionedelle schede di rete wireless, disponibili in commercio, le ha rese più economiche. Laportabilità intesa come la possibilità di svolgere le medesime funzioni in un ambientedifferente da quello originale costituisce un altro elemento utile. La modifica del li-vello MAC nei chipset risulta maggiormente portabile. Essa è realizzata utilizzando,nella maggior parte dei casi, il linguaggio di programmazione C che risulta menodifficile rispetto ad una combinazione di linguaggi che vengono eseguiti sulle piattor-me SDR. Queste ultime , infatti, richiedono la compresenza di ulterior conoscenzerispetto al linguaggio C (GNU radio ad esempio) che complicano la programmazioneda parte dell’utente. L’efficienza gioca un ruolo importante con l’approccio basatosulla modifica di driver che permette alte prestazioni e offre il vantaggio riguardantela scalabilità. La scalabilità rappresenta un fattore critico per le applicazioni distri-buite e indica la capacità di adattarsi all’aumento di veicoli, all’incremento dei datie alla diversificazione delle funzionalità richieste. Infatti operando con modifichesoftware che agiscono a livello kernel, l’installazione su un numero elevato di veicoliè resa più semplice da attuare. I chipset commerciali (generalmente ASIC) consen-tono di velocizzare le operazioni da effettuare perchè utilizzano hardware specifico enon introducono ritardi come le piattaforme SDR che invece effettuano operazionivia software. Concludendo la flessibilità cioè la possibilità di personalizzare, modi-ficare e controllare diversi parametri di livello fisico e MAC, risulta certamente lacaratteristica fondamentale. Le piattaforme basate su modifiche dei driver offrono

28


una minor flessibilità per quanto riguarda la configurazione dei parametri del livelloMAC e soprattutto del livello fisico rispetto ai sistemi SDR. Questi ultimi invecesono molto più flessibili e permettono modifiche,tramite aggiornamenti, dei livelliPHY e MAC.

29

Conclusioni

In questo elaborato abbiamo visto come funziona lo standard 802.11p, le novità intro-dotte, le modifiche a livello MAC e PHY, come sono stati realizzati alcuni dispositiviche lo supportano e di quanto sia importante nelle comunicazioni interveicolari. Sipresenta, quindi, nei prossimi anni, uno scenario promettente che impiega tale tec-nologia per fornire servizi per la sicurezza dei passeggeri di una vettura, per unamigliore gestione del traffico, per la segnalazione di incidenti o lavori. Si consideriad esempio lo scenario in cui un veicolo che non ha visibilità per qualche motivo(preceduto da un camion o per la presenza di nebbia fitta) in cui venga segnalatala forte pressione del pedale del freno da un altro veicolo posto 100 m lungo la stes-sa direzione. Oppure una situazione in cui i veicoli provenienti dal senso oppostosegnalino al conducente della vettura un incidente o situazioni pericolose. Questiesempi e moltissimi altri ci aiutano a comprendere che le comunicazioni in ambientiveicolari sono il prossimo passo da compiere per l’industria dell’auto.

30

Bibliografia

[1] D.Jiang, L.Delgrossi, ”IEEE 802.11p: Towards an InternationalStandard for Wireless Access in Vehicular Environments”

[2] John B. Kenney, Member IEEE, ”Dedicated Short-Range Communica-tions (DSRC) Standards in the United States”

[3] Stephan Eichler, ”Performance Evaluation of the IEEE 802.11p WAVECommunication Standard”

[4] A.Cosantini, ”Implementation of an IEEE 802.11p transmitter in open-source Software Defined Radio”

[5] D.Carona, A.Serrador, P.Mar, R.Abreu, N.Ferreira, T.Meireles, J.Matos,J.Lopes, ”A 802.11p prototype implementation”

[6] C.Schmidt-Knorreck, D. Knorreck, R. Knopp ”IEEE 802.11p ReceiverDesign for Software Defined Radio Platforms”

[7] ”Porting the 802.11p receiver on the ExpressMIMO Platform”https://twiki.eurecom.fr/twiki/pub/OpenAirInterface/AcropolisWinter12/lab_OAI2.pdf

[8] F. Neves,A. Cardote, S. Sargento, ”Real-world Evaluation of IEEE802.11p for Vehicular Networks”

[9] Gnuradio, ”The GNU Software Radio” http://www.gnuradio.org

[10] CVIS, ”Cooperative Vehicle Infrastructure Systems”http://www.cvisproject.org/

[11] Qfree, ”The future of intelligent transport system”http://www.cvisproject.org/download/qfree_cvis_brosjyre.pdf

31


[12] ”The Grand Cooperative Driving Challenge” http://www.gcdc.net

[13] ”Intelligent Transport System and Services for Europe”http://www.ertico.com/

[14] ”Official LinuxWireless wiki” http://linuxwireless.org/en/users/Documentation

32

Studio e analisi del protocollo 802 - Facoltà di Ingegneria altro working group (1609) e sono...

Documents

Transcript of Studio e analisi del protocollo 802 - Facoltà di Ingegneria altro working group (1609) e sono...