Porting in ambiente OSSIE di un'implementazione SCA-compliant della waveform FM3TR per Software-Defined Radio

UNIVERSITÀ DEGLI STUDI DI PISA

FACOLTÀ DI INGEGNERIA

CORSO DI LAUREA IN

INGEGNERIA DELLE TELECOMUNICAZIONI

Tesi di Laurea Specialistica

"Porting in ambiente OSSIE di un'implementazione SCA-compliant

della waveform FM3TR per Software-Defined Radio"

Candidato

Emanuele CARMASSI

Relatori

Prof. Ing. Marco LUISE Prof. Ing. Filippo GIANNETTI Dott. Ing. Claudio CICCONETTI

Ing. Mario DI DIO

i

Introduzione……….1

Cap. 1 – La Software-Defined Radio (SDR)………..3

1.1 Cenni storici e Definizione...3

1.2 Vantaggi di un sistema SDR ...5

1.3 Schema architetturale ed operativo di una SDR ideale ...7

1.4 SDR e Cognitive Radio ...10

1.5 Una piattaforma HW SDR-oriented: USRP ...11

Cap. 2 – SCA ed OSSIE………13

2.1 Software Communication Architecture (SCA) ...13

2.1.1 Generalità sulla piattaforma SCA ...13

2.1.2 Requisiti fondamentali di identificazione per Architetture SDR...14

2.1.3 L'architettura e le specifiche di SCA ...16

2.1.4 Object Request Broker ORB ...18

2.1.5 Il concetto di “porta” di un componente secondo SCA ...21

2.1.6 Core Framework di SCA ...22

2.1.7 Realizzazione di una waveform SCA compliant...30

2.2 OSSIE ...30

ii

Cap. 3 – La Waveform FM3TR………33

3.1 Uso e requisiti generali ... 33

3.2 Modalità Voce e applicazione PTT ... 33

3.3 Modalità Dati e applicazione ITM ... 34

3.4 Componenti Software ... 35

3.4.1 Trama FM3TR ... 37

3.4.2 Pacchetto MHAL ... 37

3.4.3 Messaggio di Frequency Hopping ... 38

3.4.4 Componenti SCA FM3TR (GPP) ... 39

3.4.5 Componenti FM3TR (DSP) ... 44

3.4.6 Componenti FM3TR per la conversione UP/DOWN (FPGA) ... 48

3.5 Flusso a pacchetti ... 51

Cap. 4 – Porting della waveform FM3TR in ambiente OSSIE………55

4.1 Scenario del codice fornito da Calit2 ... 55

4.1.1 Applicazione ... 57

4.1.1.1 Istallazione ... 57

4.1.1.2 Analisi generale della struttura software ... 58

4.2 Porting su OSSIE ... 64

4.2.1 Metodo di lavoro ... 64

4.2.2 La waveform OSSIE realizzata ... 65

4.2.2.1 Generatore e Ricevitore di pacchetti ... 66

4.2.2.2 Componente DLC ... 68

4.2.2.2.1 DLC_tx ... 68

4.2.2.2.2 DLC_rx ... 69

iii

4.2.3 Analisi delle criticità incontrate nel porting ...75

4.2.4 Sviluppi futuri...75

Cap. 5 – Conclusioni……….……….…77

Appendice……….………..…79

La Software Communications Architecture (SCA) è un’architettura aperta che garantisce ai componenti che costituiscono una Software Defined Radio (SDR) un elevato grado di portabilità e interoperabilità.

Nel primo capitolo di questo lavoro di tesi è descritta l’architettura di una SDR, i suoi elementi, e i suoi vantaggi. Nel secondo capitolo è descitta la struttura gerarchica di SCA. In particolare il Core Framework (CF), le interfacce e i file del Domain Profile. Nel secondo capitolo è altresì descritto OSSIE, un ambiente

open-source di sviluppo per waveforrm SCA-compliant.

Il terzo capitolo descrive i componenti della waveform Future Multi-band Multi-waveform Modular Tactical Radio (FM3TR) realizzati dall’Istituto Calit2. La waveform FM3TR è nata come standard militare. Essa implementa un sistema riconfigurabile con due canali, uno voce ed uno dati, modulati CPFSK e con un algoritmo di frequency hopping sulle bande UHF e VHF militari (30 Mhz – 400 Mhz).

Nel capitolo terzo sono descritti con particolare attenzione i componenti FM3TR che rispettano l’architettura SCA.

Il quarto capitolo illustra in dettaglio l’operazione di porting della waveform FM3TR nell’ambiente OSSIE e le principali criticità incontrate. Il capitolo si conclude con la descrizione dei futuri sviluppi.

Nel quinto capitolo sono riassunte le conclusioni e le prospettive di questo lavoro di tesi.

La Software Defined Radio

(SDR)

1.1. Cenni Storici e Definizione

Una delle possibili definizioni di una Software Defined Radio (SDR) può essere questa:

“una radio sostanzialmente software, per cui, il comportamento dello strato fisico può essere significativamente alterato attraverso cambiamenti del proprio codice”[1].

Quando la radio fu inventata, gli standard e le operazioni radio sono state implementate tramite piattaforme hardware specifiche. I generatori di segnale, i modulatori e demodulatori, i filtri, i convertitori di frequenza erano componenti fisici ed ogni nuovo sistema radio era progettato per realizzare uno standard specifico, una specifica waveform [Appendice]. Ad esempio un trasmettitore-ricevitore FM era costruito in hardware per realizzare esclusivamente la waveform FM.

Oggi, invece, puntiamo a realizzare un dispositivo che riesca ad operare con standard diversi ed eterogenei semplicemente agendo sul software. Sembrerebbe il più ambizioso dispositivo di telecomunicazioni oggi realizzabile, invece questa è l’opportunità che emerge dalle Software Defined Radios.

Thomas Sundquist [2] afferma:

“Immaginiamo una tecnologia che può trasformare la radio di cucina in un telefono GSM, in un ricevitore GPS o magari in un terminale satellitare. O, perché no, nel telecomando apricancello del garage?”

4

Storia

Il termine “Software Defined Radio” fu coniato nel 1991 da Joseph Mitola, che pubblicò il primo documento sull’argomento nel 1992 [3]. Anche se il concetto fu presentato per la prima volta nel 1991, le SDR hanno le loro origini nel settore della Difesa alla fine degli anni ‘70 negli Stati Uniti.

L’origine e molti successivi progetti SDR coinvolgono il settore della Difesa perché per essa le comunicazioni radio sono particolarmente importanti. I militari utilizzano diversi tipi di equipaggiamenti radio, e questi sono tradizionalmente single purpose. Single purpose significa che ogni specifica waveform richiede hardware dedicato.

Una delle prime iniziative pubbliche di software radio fu il progetto statunitense e militare denominato SpeakEasy, progetto che fu portato avanti dal 1992 al 1995. L’obiettivo primario del progetto era quello di usare una piattaforma programmabile per emulare circa dieci esistenti radio militari, operanti in bande di frequenza diverse comprese tra 2 e 2000 MHz. Fra esse c’erano le radio per le forze terrestri (VHF , FM e SINCGARS), quelle per le forze d’aviazioni (VHF e AM), quelle per le forze navali (VHF AM e HF SSB teleprinters) e quella satellitare microwave QAM. Il progetto si prefiggeva inoltre di poter includere facilmente in futuro nuovi standard, così che le comunicazioni militari potessero tenere il passo con le nuove tecniche di codifica, modulazione e filtraggio.

Oggi il punto di riferimento per la ricerca e lo sviluppo è l’SDR Forum [4], un’organizzazione internazionale senza scopo di lucro nata nel 1996 al fine di accelerare lo sviluppo dei sistemi di comunicazione radio basati su SDR. Il forum è nato perché il concetto di SDR ha avuto un consenso altamente positivo. Si contano infatti più di 100 organizzazioni in tutto il mondo che partecipano al forum, la maggior parte delle quali sono costituite da aziende costruttrici di apparati radio, che ovviamente traggono ampi benefici da un tale approccio comune, e molte università che contribuiscono alla ricerca scientifica ed allo sviluppo di sistemi radio.

5

1.2. Vantaggi di un sistema SDR

La scelta di muoversi in maniera decisa nella direzione della SDR, da parte del mondo militare e successivamente anche da parte della comunità degli sviluppatori e di molte imprese di telecomunicazioni, è dovuta ai sostanziali vantaggi che questa tecnologia offre. Interoperabilità, affidabilità, flessibilità, sicurezza, facilità di aggiornamento, economicità, sono solo alcuni esempi dei numerosi vantaggi di questa tecnologia.

Interoperabiltà e flessibilità

Da sempre aree geograficamente distinte, ma anche organi dello stesso stato, hanno sviluppato e adottato protocolli e canoni di comunicazione radio diversi, impedendo la comunicazione reciproca. È questo il caso di America ed Europa, di Esercito e Marina, o dei corpi di primo soccorso. Quello che sembra un problema di interoperabilità hardware insolubile, perchè richiede sistemi hardware distinti risulta essere via software semplicemente un cambio di parametri.

Un altro esempio di flessibilità per una software radio è semplicemente la possibilità di poter cambiare banda di lavoro, o addirittura cambiare lo standard da realizzare. Come già detto, lo stesso dispositivo può implementare un ricevitore TV e un’interfaccia Wireless LAN (WLAN).

In questo modo i produttori di radio possono rapidamente aggiungere funzionalità alle loro radio, e simultaneamente possono offrire una qualità migliore del prodotto. Per questo la programmabilità della software radio è una caratteristica chiave delle SDR.

Affidabilità, sicurezza e facilità d’aggiornamento

Una radio può essere dotata di meccanismi di crittografia dei dati, meccanismi di frequency hopping, meccanismi di protezione dall’interferenza. Il vantaggio offerto dalla SDR è che tali algoritmi possono essere modificati/aggiornati in maniera rapidissima, perfino over-the-air.

Economicità

L’impatto economico derivato dall’uso della SDR è un fattore centrale nell’analisi dei vantaggi di questo approccio. Usando SDR, un ricevitore FM può

6

essere realizzato scrivendo poche linee di codice, implementando la waveform su un normale PC, e connettendo il PC a un dispositivo hardware a basso costo con un generico front-end a Radio Frequenza RF (per esempio una Universal Software Radio Peripheral USRP). Questa soluzione creerebbe una radio FM molto costosa e con un alto consumo di energia. Tuttavia, questa stessa piattaforma (PC e USRP) può essere usata per implementare un ricevitore TV, un’interfaccia Wireless LAN, senza la richiesta di alcun hardware aggiuntivo.

Più waveform SDR possono essere lanciate sulla stessa piattaforma, nello stesso modo in cui diversi programmi sono eseguiti in parallelo sullo stesso PC. Tuttavia, proprio come nel caso di altre tecnologie software, il limite è la disponibilità di risorse computazionali della piattaforma come: la memoria disponibile ad ogni livello di gerarchia, la velocità di traferimento della memoria, la velocità di clock e il numero di core della CPU, la velocità dei Digital to Analog Converter (DAC) e dei Analog to Digital Converter (ADC) e la tipologia di hardware RF utilizzato per il front-end. Le risorse di calcolo disponibili oggi permettono di implementare molteplici e differenti waveform sulla stessa piattaforma. Il risultato più evidente è la diminuzione della dimensione dei componenti e l’abbattimento dei costi. Infatti, implementare cinque differenti waveforms non è cinque volte costoso, ma magari solo un poco più costoso che implementare una singola waveform.

Il concetto di SDR non è nuovo, ma l’impiego di questa tecnologia in passato era impossibile a cause delle limitate prestazioni di esecuzione dei processori. La rapida evoluzione delle capacità di calcolo dell’elettronica digitale ha reso pratici molti processi una volta possibili solo teoricamente. Infatti, è possibile oggi eseguire significative quantità di elaborazione del segnale su un processore general purpose (General Purpose Processor GPP) piuttosto che attraverso l’utilizzo di hardware special-purpose. Per esempio, utilizzando l’USRP, il processore installato su un PC moderno è abbastanza veloce per eseguire contemporaneamente alcuni differenti tipi di waveform. Di fatto il “collo di bottiglia” è, in molti casi pratici, la velocità limitata della connessione USB tra il PC e l’USRP. Ecco perché l’USRP2, la versione successiva alla USRP, utilizza l’interfaccia Gigabit Ethernet piuttosto che quella USB.

7

L’approccio SDR è la base per la tecnologia SoftModem: un softmodem è un modem con pochissimo hardware, progettato per utilizzare le risorse del computer host, ad esempio CPU e RAM, ma a volte anche l’hardware audio presente. In altri termini, sono le risorse del computer host ad eseguire la maggior parte dei compiti precedentemente svolti dall’hardware dedicato dei modem tradizionali.

Allo stesso modo più interfacce WLAN possono essere implementate oggi eseguendo gran parte dell’elaborazione sulla CPU del PC piuttosto che avere associato all’interfaccia un chip dedicato all’elaborazione del segnale digitale. In conclusione, avere la maggior parte delle funzioni di modulazione implementate in software, fornisce aggiornamenti più facili, implementazione più semplice dei nuovi standard, riduzione dei costi di produzione, riduzione della grandezza dei componenti, e riduzione del peso dei componenti. Oggi la maggior parte dei modem che sono integrati in sistemi computer portatili (laptop, netpc e PDA) sono softmodem.

1.3 Schema architetturale ed operativo di una SDR ideale

La strada intrapresa per arrivare alla definizione di un sistema SDR prevede il conseguimento di due obiettivi:

• spostare il confine tra mondo analogico e digitale nei trasmettitori e nei ricevitori il più vicino possibile all’antenna;

• eseguire l’elaborazione del segnale il più possibile via software. Questi due obiettivi richiedono l’utilizzo di convertitori ADC e DAC e la sostituzione della tecnologia Application Specific Integrated Circuit (ASIC) [Appendice] con quella Digital Signal Processing (DSP).

Lo schema “ideale” di un transceiver SDR presenta uno stadio analogico ridotto ai minimi termini: gli unici componenti analogici sono l’antenna, il filtro passa banda e l’amplificatore a bassa cifra di rumore. La conversione analogico digitale viene effettuata subito a radio frequenza, in modo da poter effettuare l’elaborazione del segnale in modo completamente digitale, su una board completamente riprogrammabile. Lo schema del ricevitore SDR illustrato nella

8

Fig. 1.1 è definito “ideale” per una serie di motivi che lo rendono di difficile realizzazione pratica.

Fig. 1. 1 – Schema di ricevitore Software Defined Radio ideale [9].

Innanzitutto, è impensabile impiegare un solo stadio RF per un sistema “multi-band”. Le cause sono l’impossibilità di costruire antenne e amplificatori a bassa cifra di rumore su bande di lavoro grandi. Si parla infatti di una banda che si estende da qualche decina/centinaio di KHz fino alla gamma dei GHz [Appendice].

Attualmente l’unico modo per garantire l’operabilità in modalità “multi-band” è quello di costruire più stadi RF, uno per banda di impiego del sistema SDR, o di limitare lo stadio unico RF ad una gamma di frequenze ben limitata e precisa. Inoltre, problemi di velocità e di jitter dell’ADC rendono impraticabile la conversione A/D, applicata direttamente a RF.

9

La soluzione che risulta al momento più praticabile è nota con il nome di “Digital Radio Transceiver”, il cui schema di ricezione è illustrato in Fig. 1.2. La sua struttura ricalca quella normalmente adottata per i cosiddetti “Wideband transceiver” con la parte RF completamente analogica ed il mondo digitale che si estende fino allo stadio a Frequenza Intermedia (Intermediate Frequency IF). Il convertitore analogico digitale (ADC) campiona l’intero spettro allocato al sistema; il “Programmable Down Converter” provvede ad effettuare le seguenti operazioni:

• Down conversion: conversione numerica da una frequenza intermedia alla banda base (BB) mediante l’impiego di una look-up table che contiene i campioni di una portante sinusoidale. La look-up table sostituisce l’oscillatore locale utilizzato nei down converter analogici;

• Canalizzazione: selezione della portante, mediante una operazione di filtraggio numerico. Questa operazione nei ricevitori analogici viene effettuata mediante un filtro analogico, con specifiche alquanto rigorose, prima della conversione in BB;

• Sample Rate Adaptation: sotto/sovracampionamento del segnale in uscita dal filtro di canalizzazione per adeguare il rate dei campioni alla larghezza di banda del segnale selezionato, che risulta essere un segnale a banda stretta se paragonato al segnale a tutto spettro in ingresso al convertitore ADC.

Il segnale numerico in uscita dallo stadio IF viene poi sottoposto al processing di banda base. La costruzione di un “Digital Radio Transceiver” presenta, tuttavia, non poche difficoltà in entrambi gli stadi IF e BB. Per lo stadio IF sussistono problemi essenzialmente di natura tecnologica legati alle prestazioni dei convertitori A/D e D/A che impongono una scelta di compromesso tra velocità di campionamento e risoluzione: maggiore è la velocità di campionamento e minore è il numero di bit con cui si possono rappresentare i campioni.

Anche in banda base sussistono problemi di carattere tecnologico legati alla potenza di calcolo e al consumo di potenza dei DSP. È necessario reperire una potenza di calcolo sufficiente da consentire l’esecuzione in real-time del software che definisce l’interfaccia radio. Questo può richiedere l’impiego di più processori in parallelo a seconda della complessità delle interfacce radio da implementare.

10

L’impiego di DSP nel processing di banda base deve in ogni caso sottostare a dei vincoli ben precisi, che risultano particolarmente stringenti se considerati dal punto di vista di un terminale mobile:

• limitata complessità circuitale; • basso costo;

• basso consumo di potenza;

• ridotte dimensioni del transceiver.

1.4 SDR e Cognitive Radio

Secondo la FCC (Federal Communication Commission) la definizione di Cognitive Radio (CR), e quindi la differenza con SDR, è la seguente:

“Un Cognitive Radio è un dispositivo radio che può adattare i parametri di trasmissione sulla base dell'interazione con l'ambiente in cui opera. La maggior parte dei dispositivi CR sarà probabilmente basata sulla tecnologia SDR, ma i requisiti di un CR non prevedono di essere basati su software o di essere riprogrammabili”.

Un CR è un'entità che percepisce l’ambiente in cui opera, ne raccoglie i dati, ottiene informazioni dai dati raccolti, identifica le strategie da adottare dalle informazioni raccolte e trasforma queste strategie in azioni. Pertanto, in principio ogni CR è basato su una piattaforma SDR, pur non essendo questo un requisito strettamente necessario.

Infatti, un dispositivo CR differisce dagli altri dispositivi radio per le possibilità di apprendimento, non per il fatto di essere basato su SDR. Tuttavia, il beneficio di una piattaforma SDR è sicuramente notevole, in quanto permette di realizzare le funzionalità di apprendimento e ragionamento del dispositivo via software tramite algoritmi di alto livello, ad esempio adattativi o di machine-learning.

Il termine Cognitive Radio è stato utilizzato per la prima volta da Joseph Mitola nel 1999 [5].

11

1.5 Una piattaforma HW SDR-oriented: la USRP

L’USRP è una periferica di front-end per l’implementazione di Radio Software sviluppata da Ettus LLC [6]. L’USRP è un dispositivo Hardware a basso costo progettato per la ricerca e la rapida prototipizzazione delle applicazioni SDR. Il dispositivo è formato da una motherboard e da una (o più) daughterboard. Mentre la motherboard svolge funzionalità generiche, le daughterboard si differenziano nelle funzioni e nei range frequenziali.

L’USRP permette di creare una software radio utilizzando un qualsiasi computer. Il computer svolge la funzione di elaborazione dell’informazione, mentre l’USRP svolge la funzione di front-end, cioè comprende lo stadio RF, il campionamento a frequenza intermedia e lo shift in banda base. Il collegamento PC USRP avviene nella prima versione dell’USRP con una porta USB 2.0, mentre con una porta Gigabit Ethernet nella seconda versione.

L’USRP è un progetto open-source, composto da schemi e driver disponibili gratuitamente, e dal software per l’integrazione con il framework di sviluppo per SDR: GNU Radio [7]. L’approccio hardware open source permette agli sviluppatori di progettare e realizzare nuove daughterboard oltre a quelle vendute da EttusResearch.

In Fig. 1.3 è riportata un esempio di collegamento PC – USRP.

Fig. 1. 3 – Schema di collegamento PC - USRP.

Di seguito, Fig. 1.4, è riportato il diagramma a blocchi semplificato dell’USRP.

12

SCA ed OSSIE

2.1 Software Communications Architecture (SCA)

2.1.1 Generalità sulla piattaforma SCA

La Software Communications Architecture (SCA) è un’architettura non proprietaria sviluppata dal Dipartimento della Difesa Statunitense (DoD - U.S. Department of Defense), ed esattamente dal programma Joint Tactical Radio System JTRS. SCA è nata per standardizzare lo sviluppo delle SDR.

Nonostante le sue origini militari, SCA introduce molti criteri e caratteristiche che si applicano anche alle applicazioni commerciali.

SCA è un’architettura di riferimento aperta che indica ai progettisti come gli elementi hardware e software devono operare in armonia all’interno di una SDR.

Se uno sviluppatore progetta un sistema in conformità alle regole SCA, il sistema risulterà portabile su un altro sistema SCA-compliant, indipendentemente dal sistema operativo e dall’hardware di cui tale sistema è dotato.

Lo scopo di SCA è definire un ambiente operativo (Operating Enviroment, OE), al cui interno è definito il Core Framework (CF). Il CF implementa il management, la dislocazione, la configurazione e il controllo dei componenti hardware/software del sistema radio in esecuzione.

14

Ci sono due obiettivi chiave di SCA: la flessibilità e l’interoperabilità. Questi sono fattori importanti perché SCA intende fornire la portabilità delle applicazioni tra hardware differenti e supportare quindi il riuso dei moduli software nelle waveform progettate.

2.1.2 Requisiti fondamentali d’identificazione per Architetture SDR

In ambiente SCA ogni applicazione radio è chiamata waveform. La Fig. 2.1 mostra due generiche waveform W1 e W2. Ogni componente Ci,j della

waveform è un entità standalone che esegue sul segnale un’operazione di processing o alcune funzionalità di controllo, richieste dalla waveform. I componenti possono avere poi molteplici implementazioni. Ogni implementazione è associata a uno specifico dispositivo d’elaborazione D. In Fig. 2.1 C2,1 ha tre implementazioni.

15

Fig. 2. 1 – Diagramma a blocchi di semplici waveform e di piattaforme SDR [17].

Entrambe le waveform girano su due piattaforme diverse, P1 e P2.

Le piattaforme sono in genere composte da un qualsiasi dispositivo d’elaborazione riprogrammabile, Dm,n , come ad esempio un processore General

Purpose Processor (GPP), un Digital Signal Processor (DSP), una Field-Programmable Gate Array (FPGA), un Application-Specific Integrated Circuit (ASIC) o da un insieme di essi. Inoltre le due piattaforme possono essere modulari, ovvero possono essere aggiunti nuovi elementi di elaborazione. Un esempio di piattaforme così fatte sono gli hot-swappable blade system.

Data la natura eterogenea delle piattaforme SDR è necessario un modello (component model) che definisce le funzioni del componente, tutte le interfacce previste da esso e i protocolli che utilizza per realizzare e gestire lo scambio di informazioni con gli altri componenti.

Per garantire che la waveform sia indipendente da una successiva dislocazione sulla piattaforma è necessario un ambiente di lavoro comune detto Operational Environment (OE).

La waveform, e quindi i suoi componenti, risiedono inizialmente, in una certa locazione della memoria di massa; il file system si occupa della

16

memorizzazione, dell’organizzazione e dell’accesso alla parte di memoria in cui risiede la waveform.

Il componente che si occupa del lancio della waveform è detto application

factory. Quest’ultimo esegue le assembly instructions che sono:

1. trovare la waveform in memoria;

2. caricare e istanziare ogni componente sull’appropriato dispositivo della piattaforma;

3. connettere ogni componente al successivo;

4. eseguire ogni controllo necessario affnché la waveform risulti correttamente in esecuzione.

Il meccanismo di comunicazione per lo scambio di informazioni, dati e controllo, fra i diversi dispositivi e componenti della piattaforma è svolto da un livello software detto di middleware. Esso racchiude il livello di trasporto. Il middleware è necessario anche per consentire ad ogni waveform di poter essere dislocata, senza cambiamenti di logica o granularità, su un’altra piattaforma SCA-compliant.

Il meccanismo che controlla e tiene traccia di tutte le risorse, hardware e software, e dell’interfaccia con l’utente è detto device manager.

La capacità di poter configurare i diversi componenti hardware e la possibilità che essi si scambino messaggi dati e controllo è fornita dal proxie per i device.

L’elemento che tiene conto delle risorse disponibili richieste dalle piattaforme è detto capacity model. Oltre a garantire le richieste dei componenti, questo permette che le diverse waveform possano essere riconfigurate.

È evidente che la realizzazione e la raffinatezza di queste entità varia a seconda dell’applicazione. Alcune entità non essenziali inoltre sono opzionali. Ad esempio è possibile includere un meccanismo di memorizzazione delle notifiche detto di log service.

2.1.3 L’architettura e le specifiche di SCA

SCA disciplina la struttura e il funzionamento delle SDR, assicurando che ogni elemento hardware e software operi in accordo al programma JTRS.

17

Lo SCA fu sviluppato come architettura aperta per raggiungere i seguenti obiettivi:

• economicità derivante l’utilizzo di componenti Comercial Off-The-Shelf (COTS);

• portabilità delle waveform;

• riutilizzo dei codici software già sviluppati;

• interoperabilità tra sistemi JTRS;

• inserimento di tecnologie avanzate;

• astrazione dall’hardware sottostante.

SCA si basa su componenti COTS, su interfacce standard e modelli well-known. L’OE permette di produrre e gestire applicazioni SDR, realizzare l’indipendenza dalle specifiche piattaforme hardware e tutelare le proprietà intellettuali tramite il riuso del software già scritto. Queste caratteristiche si traducono in uno sviluppo delle SDR più semplice e veloce, ed in applicazioni più flessibili, gestibili e aggiornabili.

Un importante aspetto dell’architettura SCA è che descrive solamente il comportamento atteso dai componenti, dalle waveform e dall’ambiente operativo, e non indica i dettagli di implementazione. Questo fornisce la giusta libertà agli sviluppatori, ma può anche portare a problemi di portabilità per errate interpretazioni delle specifiche.

Per facilitare la portabilità della waveform SCA è stata sviluppata come architettura scalabile in grado di supportare piattaforme con notevoli differenze di funzionalità, dagli hub di comunicazione fissi ai dispositivi portatili. Per la stessa ragione SCA specifica anche lo standard di packaging e di dislocazione della waveform.

Ci sono alcuni “misunderstanding” riguardanti SCA che devono essere affrontati. Il principale è pensare che seguendo la specifica SCA, il codice scritto risulti portabile. Per creare un codice portabile e riutilizzabile i componenti devono essere creati con pratiche di sviluppo che intenzionalmente raggiungono questo obiettivo. Lo SCA aiuta solamente a raggiungere l’obiettivo.

18

Un altro malinteso è che SCA significhi SDR. SCA è la più completa e robusta architettura per sviluppare SDR ma non è il solo modo per implementare una SDR.

Un altro pregiudizio è pensare che l’overhead introdotto da SCA sia troppo pesante e che le radio SCA-compliant siano praticamente non realizzabili. In molti casi invece considerati i vantaggi di portabilità e riusabilità, l’overhead introdotto è ragionevole e giustificato.

Le specifiche SCA

La struttura software SCA mostrata in Fig. 2.2 definisce l’ambiente operativo (Operational Environment) per astrarre le risorse hardware e software.

L’OE fornisce i meccanismi per collocare i componenti sulla piattaforma. L’OE definisce anche le interfacce per la gestione e il controllo dell’applicazione e dei suoi componenti, indipendentemente dalla loro particolare implementazione.

Fig. 2. 2 – La struttura software di SCA.

2.1.4 Object Request Broker ORB

Il Common Object Request Broker Architecture (CORBA) è il cuore dell’architettura software. SCA impone l’uso di un CORBA minimale. Il CORBA

19

è creato, standardizzato e controllato dall’OMG Object Management Group [10]. Il CORBA è un meccanismo che permette a oggetti diversi (cioè generati su differenti macchine e con differenti linguaggi di programmazione) di comunicare, scambiandosi dati in tutta sicurezza a run-time. Questo standard è l’ideale per applicazioni di tipo server/client. Infatti nel caso di una waveform SCA ogni componente è un server e/o un client.

In conclusione SCA impone l’uso di CORBA per garantire lo scambio trasparente di informazioni tra i componenti ed è stato scelto proprio per la sua semplicità, apertura e indipendenza rispetto alla piattaforma hardware.

Tutti gli oggetti ORB sono identificati attraverso un nome univoco che sta ad indicare l'oggetto specifico, ovunque esso si trovi nel mondo. In questo modo le funzionalità di un oggetto possono essere utilizzate da un altro oggetto ovunque questi si trovino. La gestione di questa operazione da parte del CORBA spetta all' Interoperable Object Reference (IOR).

Il CORBA utilizza un'interfaccia di tipo Interface Description Language (IDL) la quale specifica le porte di comunicazione che gli oggetti offriranno all’esterno. Ogni oggetto che avrà bisogno di una funzione che fa riferimento al CORBA dovrà utilizzare un’interfaccia IDL che specifichi il tipo di operazione da eseguire. IDL non è un vero e proprio linguaggio di programmazione, esso definisce le interfacce ma non dispone di una struttura propria dei linguaggi di programmazione. IDL definisce gli accordi tra le due parti in gioco (client e server), specificando le risorse disponibili. Vengono quindi generati dal compilatore dell'IDL i proxy skeleton e stub, rappresentati in Fig. 2.3.

20

Fig. 2. 3 – Esempio di comunicazione inter-ORB [8].

Si può notare in figura che gli skeleton e gli stub lavorano al di sopra del livello ORB, in questo modo server e client possono essere implementati con diversi linguaggi, e allo stesso tempo sono in grado di comunicare in modo sicuro e scalabile. Ogni Server Object ha un riferimento unico, ma il Client può usufruirne in diversi modi. Una volta ottenuto il riferimento il client effettua la sua richiesta per una particolare operazione, questo lo fa passando attraverso lo stub che effettua la richiesta attraverso l'ORB che poi la inoltrerà a sua volta allo skeleton, ed infine al Server Object.

Il blocco ORB contiene le risorse necessarie per inoltrare le richieste dal client al server. Tipicamente però essi non sono direttamente connessi, e si ha quindi la necessità di un nuovo livello che fa capo ai protocolli GIOP/IIOP, che inoltrano la richiesta tra un ORB e l'altro. Tutto ciò risulta trasparente ai due oggetti che vogliono comunicare. Tutto quello di cui hanno bisogno i due oggetti che vogliono comunicare sono i riferimenti, per problemi quali errori di richiesta, controllo risorse e peso del carico computazionale sono gli stessi ORB ad occuparsene.

Come già detto nel caso di una waveform SCA le interfacce del CF sono descritte in IDL. Infatti quando si implementa una waveform tutti i componenti

21

che la costituiscono sono anch'esse descritte nell'IDL. Lo skeleton e lo stub vengono creati una volta compilato l'IDL, questo vuol dire, come già detto che ad un livello più basso ogni componente, sia esso Resource o Device, è un server o un client.

CORBA crea un bus software flessibile per supportare piattaforme modulari e riconfigurabili, isolando le applicazioni dalla piattaforma specifica; proprio come un livello di trasporto. Risulta, grazie a CORBA che, per una data applicazione, diversi componenti possono essere distribuiti su diversi processori, computer o reti e figurare ancora come se fossero co-locati. Sicuramente CORBA introduce un ulteriore livello di complessità, e qualora non sia usato in modo efficiente può risultare computazionalmente pesante per la SDR implementata. Tuttavia il beneficio in termini di coerenza e interoperabilità fra le applicazioni distribuite è in molte situazioni maggiore del peso di overhead aggiunto da CORBA. Senza contare che esiste una vasta varietà di implementazioni di CORBA altamente ottimizzate tra cui: e*ORB (PrismTech), ORBexpress (Objective Interface).

Nel caso si implementino solo le funzionalità elementari di CORBA e un protocollo di trasporto ottimizzato, invece del TCP/IP, i ritardi di CORBA risultano una piccola frazione del tempo totale di elaborazione.

2.1.5 Il concetto di “porta” di un componente secondo SCA

Ogni componente ha un set ben definito di porte. Per definire una porta è necessario specificare due proprietà:

• Una porta può essere di input o di output. Le porte di input ricevono, e quindi rispondono a chiamate e richieste remote. Le porte di output, invece, fanno richieste, anche con procedure remote, ai componenti a cui sono connesse. Una connessione può essere fatta solo tra una porta di input e una di output dello stesso tipo (non si possono interconnettere due porte di input o due porte di output). Il tipo di porta è definito sulla base del tipo di oggetto che deve essere passato sul link connessione. Le porte di input rappresentano il lato server. Queste aspettano (passivamente) una

22

chiamata remota. Le porte di output sono usate dai client per le richieste al server.

Nel contesto di una waveform SCA, le porte di output inviano dati, mentre le porte di client ricevono dati. Un componente SCA può essere client o server, o entrambi;

• ogni porta appartiene ad un tipo ben definito (well-defined type). Assegnare un tipo a una porta è equivalente a definire la sua interfaccia. È possibile usare tipi già standard (come integer, floating point, ecc.) o crearne di personalizzati. Quando si crea un nuovo tipo bisogna dare un nome al tipo e definire i metodi supportati. Questo è fatto tramite il linguaggio IDL.

In SCA comunemente si usano le espressioni di uses port e provides port. Le porte uses richiedono dati o servizi ad un altro componente, mentre le porte provides ritornano con i dati richiesti o con il servizio eseguito. Un componente SCA assume il ruolo di client-CORBA quando effettua una chiamata su una uses port e di server-CORBA quando risponde alla richiesta sulla provides port. Quindi nel contesto di sviluppo di waveform provides port è sinonimo di input port, e use port di outport.

2.1.6 Core Framework di SCA

Un framework è un insieme di classi e metodi che costituiscono un modello riutilizzabile per una specifica classe di software. SCA definisce nel Core Framework (CF) un insieme di interfacce che regolano la dislocazione e la gestione delle waveform e dei loro componenti. Queste interfacce determinano l’architettura e un livello del sistema dettagliato. Il CF SCA comprende:

• interfacce base per applicazioni;

• interfacce base per dispositivi;

• interfacce di framework di servizio;

• interfacce di framework di controllo;

• Domanin Profile.

Le interfacce SCA del CF sono definite nel CORBA IDL. Le relazioni tra le interfacce sono mostrate in modo semplificato in Fig. 2.4.

23

Fig. 2. 4 – Relazioni semplificate delle SCA CF IDL [17].

Base Application Interfaces

Nello SCA tutti i componenti della waveform sono tenuti a implementare le interfacce base d’applicazione. A livello più alto, di queste interfacce, c’è l’interfaccia Resource che fornisce un’interfaccia comune per la configurazione ed il controllo (come ad esempio in comportamento di start e stop) del componente software ed eredita le seguenti interfacce base:

• LifeCycle è utilizzata per inizializzare e rilasciare una risorsa.

• TestableObject fornisce le interfacce contenenti test di capacità.

• PropertySet fornisce le operazioni per configurare e interrogare le

proprietà delle risorse.

• PortSupplier fornisce l’operazione per ottenere il riferimento della

porta di un oggetto.

Le interfacce base di applicazione includono anche le interfacce Port e

ResourceFactory. La prima è utilizzata per connettere i componenti di tipo

Resource. La seconda è un’interfaccia opzionale usata per creare e abbattere le risorse, ed inoltre per fornire ai componenti le funzionalità di connessione e disconnessione necessarie per assemblare la waveform.

24

Più in dettaglio ogni interfaccia definisce i metodi utilizzati dal Domain Profile per istallare e controllare i componenti. La relazione tra le interfacce di applicazione è mostrata in Fig 2.5. È da notare che l’interfaccia Resource è creata da ResourceFactory.

Fig. 2. 5 – Diagramma delle relazioni delle interfacce di applicazione [8].

Interfaccia PortSupplier

Le porte provide ereditano dall’interfaccia PortSupplier l’operazione getPort() che è usata per ottenere una specifica porta da un componente (per esempio è utilizzata da connectPort() ).

Interfaccia lifeCycle

Definisce due operazioni, inizialize() per settare un componente ad un preciso stato iniziale, e releaseObject() per deallocare un componente quando questo non è più necessario.

Interfaccia Port

Un sistema SCA è composto da più componenti che comunicano fra loro attraverso le porte. Queste porte ereditano dalla classe Port due operazioni per instaurare le comunicazioni: connectPort() e disconnectPort(). Quando una

25

waveform è installata, tutte le connessioni tra componenti devono essere impostate. Supponiamo per esempio di voler stabilire una connessione tra la porta

use sul componente A e la porta provide sul componente B. Durante l’istallazione

il metodo connectionPort() è chiamato sulla porta use di A e la connessione con la porta provide di B è stabilita. Per recuperare il riferimento di B, SCA chiama il

Naming Service del Domain Manager (vedi Frame Control Interfaces).

Interfaccia PropertySet

È usata per accedere alle proprietà dei componenti. Essa definisce due operazioni: configure() che esegue runtime la configurazione delle proprietà, e query() per leggere il valore della proprietà di un componente.

Interfaccia TastableObject

È ereditata da un componente per eseguire test di costruzione. Il progettista del sistema può usare l’operazione di runTest() per testare il componente, per esempio per cercare errori all’interno del componente.

Interfaccia Resource

Ogni componente software nelle waveform SCA eredita l’interfaccia di Resource; questa a sua volta eredita i vari metodi da LifeCycle, TastableObject, PortSupplier, e PropertySet. Resource fornisce due operazioni: start() e stop(). Questi permettono di avviare e arrestare il componente (come ad esempio avviare o arrestare la generazione di un segnale).

Interfaccia ResourceFactory

L’interfaccia Resource può esere creata attraverso ResourceFactory. Inoltre ResourceFactory deve essere utilizzata per abbattere Resource.

Base Device Interfaces

Queste interfacce consentono l’interazione con il dispositivo hardware (device) fornendo un proxy al resto del framework. Questa astrazione permette la comunicazione fra elementi che non sono CORBA e il resto del framework. Queste sono le interfacce di particolare interesse per gli ingegneri dell’hardware e gli sviluppatori dei driver, ed includono le interfacce:

26

• Device che fornisce una rappresentazione logica del dispositivo

hardware. Essa deriva dall’interfaccia Resource ma la estende per fornire la gestione dello stato e della capacità (alloca e dealloca capacità). Un ASIC o una parte di hardware è un tipico esempio di hardware fisico rappresentato da questa interfaccia;

• LoadableDevice che estende le funzionalità di Device. Aggiunge

funzioni di caricamento e scaricamento che modificano (in esecuzione) il comportamento del dispositivo fisico. FPGA e DSP sono tipici esempi di componenti hardware rappresentati da questa interfaccia;

• ExecutableDevice che estende l’interfaccia LoadableDevice

permettendo l’esecuzione e la terminazione di risorse. Un tipico esempio di dispositivo rappresentato da questa interfaccia è il GPP. In realtà ogni processore con capacità di multithread può essere rappresentato da questa interfaccia;

• AggregateDevice è usata per rappresentare dispositivi composti,

che formati da più dispositivi logici sono presentati al dominio come una singola interfaccia.

Framework Control Interfaces

Queste interfacce forniscono al Core Framework funzionalità di gestione e controllo sull’intero dominio. Ci sono quattro interfacce in questa categoria:

ApplicatioFactory, Application, DeviceManager, e DomainManager.

L’interfaccia ApplicationFactory è usata per creare istanze di una specifica waveform. Essa ottiene istruzioni di assemblaggio dal Domain Profile. Queste istruzioni includono una lista dei componenti che costituiscono la waveform, la loro ubicazione e le loro rispettive connessioni. ApplicatioFactory trova il giusto Device basandosi sulle capacità disponibili, lancia il componente, stabilisce le rispettive connessioni ed esegue la configurazione e inizializzazione iniziale. La Fig. 2.6 mostra graficamente le operazioni semplificate dell’ApplicatioFactory.

27

Fig. 2. 6 – Operazioni dell’Application Factory [17].

Dopo aver creato l’applicazione, ApplicationFactory ritorna con un istanza creata dall’interfaccia Application. Questa interfaccia fornisce un contenitore per tutte le risorse nella waveform, permettendo la configurazione della waveform e le indagini di stato di ogni singola interfaccia. Questa interfaccia è anche responsabile di terminare l’applicazione, rilasciando tutte le risorse usate e restituendo al dispositivo host le capacità assegnate.

L’interfaccia DeviceManager è utilizzata per gestire l’insieme dei dispositivi logici. Solitamente questa interfaccia è usata per rappresentare una board abilitata al CORBA. Quando istanziata, l’interfaccia DeviceManager crea il file system per la board che rappresenta e lancia tutti i dispositivi logici sotto suo controllo. DeviceManager inoltre ottiene l’ubicazione del DomainManager e si registra come parte del dominio radio di quest’ultimo.

L’interfaccia DomainManager controlla e mantiene lo stato generale della radio. Essa crea il FileManager che conterrà il (o i) file system di ogni DeviceManager registrati sotto il suo dominio. DomainManager imposta il naming_context per la radio nel naming_service di CORBA. Inoltre DomainManager fornisce un’interfaccia di registrazione per l’interfacce DeviceManager, Device, Application e Service, gestisce l’accesso ai

28

DeviceManager registrati e alle applicazioni istallate e fornisce l’interfaccia utente.

Framework Services Interfaces

Queste interfacce sono utilizzate per eseguire tutte le operazioni relative ai file. Permettono di accedere ai file attraverso la piattaforma SCA distribuita:

• File fornisce l’accesso e le operazioni base a file individuali

all’interno del dominio radio. Ad esempio lettura, scrittura, chiusura;

• FileSystem permette l’acceso remoto a file system fisici e la

creazione, cancellazione, copia e così via dei file. Tipicamente il FileSystem è limitato a una parte di hardware o a un singolo sistema operativo (OS Operating System);

• FileManager permette la gestione di molteplici e distribuiti

FileSystem. Questo può essere visto come un file system root che monta e smonta gli altri file system.

Domain Profile

Tutta l’informazione relativa alle applicazioni e alle piattaforme all’interno di SCA è racchiusa nell’insieme di file chiamato Domain Profile. Questi file descrivono le interfacce, i modelli di capacità, le proprietà, le interdipendenze, l’interconnessioni, e le ubicazioni logiche di ogni componente all’interno del dominio. Queste informazioni sono descrtitte in linguaggio XML (eXtensible Markup Language) [Appendice]. Le relazioni fra i descrittori del Domain Profile è mostrata in Fig. 2.7.

29

Fig. 2. 7 –Relazioni tra i descrittori del Domain Profile [17].

I file Software Package Descriptor (SPD) descrivono i componenti software e la loro implementazione. Le interfacce fornite ed usate da ogni componente sono descritte nei file Software Component Descriptor (SCD), e un riferimento di questo file è incluso nel SPD. Le proprietà di ogni componente sono descritte nei file Properties Descriptor (PRF). Per proprietà si intende la rappresentazione di ogni caratteristica, logica e fisica del componente.

La waveform, o le waveform, sono descritte nel file Software Assembly Descriptor (SAD), che include una lista dei componenti che compongono ogni waveform, le connessioni fra loro, e gli specifici requisiti di dislocazione e configurazione. Il file SAD contiene un file SPD per ogni componente della waveform.

Le caratteristiche della piattaforma sono descritte nel file Device Package Descriptor (DPD) e Device Configuration Descriptor (DCD); entrambi questi file sono noti come Device Profile. Ogni componente hardware è descritto con il file DPD e il file SPD. Il file DPD inoltre contiene il file PRF, che descrive le caratteristiche del dispositivo come serial number, tipo di processore, capacità. Il file DCD contiene una lista dei dispositivi inizialmente dislocati dal

30

DeviceManager all’accensione e l’informazione necessaria per localizzare il DomainManager.

2.1.7 Realizzazione di una Waveform SCA-compliant

Le waveform SCA sono applicazioni radio componibili e distribuite, eseguite da uno o più componenti (Resource). L’ottimale granularità dipende dalle caratteristiche dell’applicazione e della piattaforma e dal compromesso fra

reusability e overhead.

Gli sviluppatori che seguono le specifiche SCA assumo che determinati servizi saranno forniti dall’ OE ma devono implementare bene le interfacce del CF per garantire che ogni componente operi in armonia nella struttura.

Il corretto sviluppo di una waveform SCA richiede la costruzione di un modello di analisi della waveform (UML model e simulation), la definizione delle interfacce della waveform (IDL interfaces, stubs e skeletons), lo sviluppo dell’effettiva elaborazione di segnale che deve svolgere ogni componente e l’assemblaggio di ogni componente della waveform (XML Domain Profile). Sebbene non è necessario seguire questo iter scrupolosamente, questo procedimento facilita lo sviluppo, il testing e la documentazione della waveform da progettare.

Per sviluppare applicazioni SCA-compliant sono disponibili strumenti che facilitano enormemente lo sviluppo dei componenti e della waveform SCA. Un esempio è OSSIE, ma esistono anche Spectra (PrismTech), Component Enabler (Zeligsoft) e SCA Architect (Communication Research Center Canada).

2.2 OSSIE Open Source SCA Implementation Embedded

2.2.1 Caratteristiche principali

Il progetto Open Source SCA Implementation Embedded (OSSIE) è un’iniziativa del gruppo wireless @ Virginia Tech per fornire un’implementazione di SCA open-sorce. In modo da permettere l’apprendimento e la ricerca sulle SDR, sulle cognitive radio e sul distributed wireless computing senza costi ed anche a chi ha basse esperienze di architetture software complesse.

31

In altre parole OSSIE consente un rapido sviluppo di prototipi e sistemi di comunicazioni sperimentali SCA-compliant.

OSSIE è scritto in C++ ed utilizza omniORB, come implementazione di CORBA, e il parser Xerces XML, entrambi open-source. È sviluppato per Linux e precisamente supporta le distribuzione Fedora e Ubuntu. La prima versione di OSSIE fu rilasciata nel luglio del 2004, ad oggi la versione più recente è la 0.8.2.

Attualmente OSSIE non è certificato da JTRS Test & Evalutation Lab (JTEL) che mantiene la capacità di test e il codice certificato per il programma JTRS, ma le future versioni potrebbero esserle.

2.2.2 OSSIE Waveform Workshop

OSSIE implementa gli elementi elementari necessari per costruire waveform che rispettano le ipotesi SCA basilari come ad esempio la definizione della maggior parte delle interfacce descritte nel CF SCA. L’insieme completo degli strumenti forniti da OSSIE è detto Waveform Workshop Fig 2.8. Esso include l’OSSIE Eclipse Feature (OEF) che è lo strumento per lo sviluppo dei componenti e delle waveform, e permette di lanciare il domain manager, il device manager, l’ALF (ALF non è un acronimo), l’OSSIE Waveform Developer (OWD) e la Dashboard. L’OEF è un plug-in di Eclipse [Appendice] che richiede, oltre l’istallazione dello stesso Eclipse, anche l’istallazione di Java.

L’ OWD fornisce l’interfaccia grafica per l’utente. Sostanzialmente è l’OEF, con in più il supporto Python. Questo permette allo sviluppatore di progettare nuovi componenti e interconnetterli per creare nuove waveform. È l’OWD che produce i file XML necessari al corretto funzionamento dei componenti e della waveform. Il codice sorgente del componente è automaticamente generato in modo da rispettare le interconnessioni definite dal framework SCA.

L’ALF è lo strumento per la visualizzazione e il debugging della waveform e dei dati. Questo permette di lanciare la waveform su una specifica piattaforma, visualizzare la waveform come diagramma a blocchi e testare le porte dei componenti utilizzando gli strumenti di controllo come l’analizzatore di spettro e il diagramma IQ. Questo strumento è stato sviluppato in Python.

32

La Dashboard è lo strumento per la configurazione, l’istallazione e l’esecuzione in runtime della waveform. Inoltre questo strumento permette di visualizzare e modificare a runtime le proprietà dei componenti.

Fig. 2. 8 – OSSIE Waveform Workshop [18].

OSSIE fornisce una libreria di componenti, per l’elaborazione del segnale, di base, per facilitare lo sviluppo di waveform. Nella libreria sono presenti: Generatore e Ricevitore di simboli, Modulatore e Demodulatore FM, Interpolatore e Decimatore, amplificatore a controllo automatico di amplificazione (AGC), Canale di prova ed altri. Inoltre è presente anche il componente per interfacciarsi con l’USRP.

OSSIE è disponibile in free download [11], insieme a esercizi di laboratorio che permettono di familiarizzare con gli strumenti e l’ambiente OSSIE, e con i principi di SCA.

La Waveform FM3TR

3.1 Uso e requisiti generali

La waveform Future Multi-band Multi-waveform Modular Tactical Radio (FM3TR) fu sviluppata inizialmente come progetto di cooperazione internazionale tra Stati Uniti, Germania, Francia ed Inghilterra al fine di sviluppare un sistema di comunicazione riconfigurabile, per applicazioni di terra ed airborne.

FM3TR definisce due modi operativi: voce e dati. La modalità voce è utilizzata per supportare l’applicazione PTT (Push-To-Talk) mentre la modalità dati è utilizzata per supportare l’applicazione ITM (Instant Text Messaging).

La waveform FM3TR è uno standard aperto ed è oggi usato come strumento per promuovere l’architettura SCA, ovvero promuovere lo studio e le discussioni sui progetti SDR e di porting ed infine per promuovere l’interoperabilità internazionale [12].

3.2 Modalità Voce e applicazione PTT

La “modalità voce” della waveform FM3TR è utilizzata come applicazione PTT per trasportare i campioni di voce tra due terminali (per esempio due Personal Computer (PC) di laboratorio o due terminali PTT). La modalità voce si basa su una modulazione Pulse-Code Modulation (PCM) a 16 KHz dove i campioni sono poi codificati secondo lo standard Continuosly Variable Slope Delta (CVSD).

Per la modalità voce non è previsto nessun controllo d’accesso al canale radio. Facoltativamente l’applicazione PTT può verificare se il terminale sta ricevendo prima di istanziare una nuova sessione PTT in trasmissione.

Inoltre l’applicazione PTT deve essere in grado di soddisfare le seguenti specifiche:

34

• utilizzare un codec CVSD;

• possibilità di operare in modalità broadcast con un singolo canale condiviso fra 2-3 unità;

• possibilità di connessione con un dispositivo audio esterno tramite Ethernet (TCP/IP o UDP/IP su Ethernet).

3.3 Modalità Dati e applicazione ITM

La modalità dati FM3TR utilizza lo stesso canale di trasporto radio (16Kbps) della modalità voce, applicando ai dati una codifica Reed-Solomon (R-S) come protezione d’errore. L’introduzione della codifica R-S porta il rate dei dati a 9.6 Kbps.

La specifica FM3TR richiede l’utilizzo di una Automatic Repeat reQuest (ARQ). Nella modalità opzionale Frequency Division Duplexing (FDD) gli Acknowledgements (ACK) sono inviati simultaneamente su una frequenza diversa da quella dei dati. Nella modalità half duplex l’ARQ utilizzato è più semplice ed il componente che se ne occupa è il Datalink Layer Control (DLC).

Come per il canale voce non è previsto alcun controllo di accesso al canale radio. Se il messaggio collide con un altro messaggio il sistema ritrasmette il messaggio grazie all’ARQ.

Le caratteristiche della modalità dati della FM3TR sono:

• i messaggi sono trasmessi con codifica R-S;

• ogni terminale è identificato da un indirizzo da 1 Byte;

• ogni pacchetto sul livello DataLink è identificato da un indirizzo di 11 Byte;

• l’ARQ sul canale unidirezionale è implementato dal componente DLC;

• per la modalità broadcast non è fornito alcun meccanismo di ARQ;

• non è implementato alcun controllo d’accesso al mezzo radio. L’applicazione ITM genera un messaggio di testo (Max 48 KBytes). Il messaggio è frammentato dal componente DLC in pacchetti DataLink di lunghezza ottimale per la Bit Error Rate (BER) attesa sul canale.

L’applicazione ITM deve supportare le seguenti specifiche:

• possibilità di operare in modalità broadcast con un singolo canale condiviso fra 2-3 unità;

35

• possibilità di conferenze dove i messaggi sono inviati in modalità broadcast agli utenti partecipanti;

• capacità di sessioni ITM bidirezionali.

3.4 Componenti Software

Le applicazioni PTT e ITM utilizzate dal progetto Calit2 [14] sono scritte in Java e vengono eseguite su un PC Linux separato dalla SDR su cui risiedono invece i componenti FM3TR. I seguenti componenti software sono l’insieme dei componenti sviluppati da Raytheon e Calit2 nel corso dei loro progetti SDR della waveform FM3TR descritti a partire dal Paragrafo 3.4.4: Net Device, DLC, R-S codec, DataMAC, VoiceMAC, CVSD Codec, MHAL modem, DataConditioning, Add S-code, S-code correlator, A-code correlator, CPFSK Modulation e CPFSK Demodulation.

Per semplicità d’uso l’interfaccia Graphical User Interface (GUI) ad entrambe le applicazioni PTT e ITM è unica.

Nelle figure seguenti è riassunto il sistema realizzato dal progetto Calit2.

36

Fig. 3. 2 – Sistema FM3TR: applicazioni PTT e ITM [16].

SDR-4000 è la piattaforma SDR costruita da Spectrum Signal Processing [13], utilizzata dal progetto Calit2 per realizzare la waveform FM3TR. Questa è collegata tramite Ethernet ad un PC su cui risiedono le applicazioni PTT e ITM.

37

La piattaforma SDR-4000 come si vede dalla Fig. 3.3 è composta da un processore general purpose GPP, un DSP e una FPGA, ognuno dei quali svolge funzioni diverse. In particolare il GPP elabora i dati provenienti dalle applicazioni ITM e PTT per formare trame FM3TR. Il DSP effettua il data-conditioning e la modulazione/demodulazione delle trame FM3TR. La FPGA svolge la traslazione da banda base a IF, implementa l’algoritmo di Frequency Hopping e la conversione A/D, D/A.

I diversi colori dei blocchetti dei componenti differenziano i componenti generati da Raytheon (FM3TR base code) da quelli generati da Calit2 (New Code). Il progetto Calit2 è partito dal codice Raytheon al fine di ampliare le funzioni della radio. È necessario sottolineare che i due progetti utilizzano hardware diverso quindi la parte di codice non SCA-compliant è stato riadattato.

3.4.1 Trama FM3TR

La trama FM3TR è composta da 5 hop. Ogni hop contiene 100 bit. L’ultimo hop è di sincronizzazione. I primi quattro hop contengono 80 bit di dati e 20 bit nulli. Un frame contiene in totale 40 Byte informativi.

Fig. 3. 4 – Formato trama FM3TR.

Sei frame FM3TR vengono raggruppati in un’unica supertrama composta da sei FM3TR frame con un frame di preambolo e due frame FM3TR di fine messaggio (EOM).

Fig. 3. 5 – Formato supertrama.

3.4.2 Pacchetto MHAL

Questo formato di pacchetto è quello che si scambiano il Modem Device MHAL e il corrispondente componente nel DSP. Inoltre questa struttura permette l’operazione di multiplexing del canale dati e del canale voce.

38

Il campo TYPE è stato aggiunto, rispetto alla specifica originale, dal Progetto Calit2 per ottenere un corretto multiplexing/demultiplexing tra il ramo voce e quello dati.

Fig. 3. 6 – Formato pacchetto MHAL.

3.4.3 Messaggio di Frequency Hopping

Le frequenze di trasmissione e ricezione cambiano ad ogni hop. Il meccanismo di Frequency Hopping è controllato dal modem FM3TR (cioè dal DSP), che invia messaggi di controllo all’FPGA. Da notare che la rivelazione del frame dati è fatta dalle funzioni di modulazione/demodulazione (DSP) non dalla FPGA.

In Fig. 3.7 vediamo lo scambio di messaggi tra DSP e FPGA in trasmissione. Il flusso dati scambiato consiste in un flusso preambolo, 6 frame FM3TR, 2 EOM, modulati secondo lo standard Continuous Phase Frequency Shift Keying (CPFSK).

I messaggi di controllo sono incorporati nel flusso dati. Ogni hop del frame FM3TR, come già detto, contiene 80 bit dati e 20 bit NULL. L’hop inizia con 5 simboli zero. Questi servono per dare un tempo di guardia al transceiver necessario per il cambio di frequenza. Per lo stesso motivo l’hop termina con 15

39

simboli zero. Questa struttura di messaggio è identificata dall’FPGA che in accordo con essa cambia la frequenza di trasmissione. Prima della trasmissione in aria l’FPGA cambia il valore del campione di controllo a zero.

Fig. 3. 7 – Segnalazione di controllo del frequency hop in trasmissione [16].

In ricezione, Fig. 3.8, il DSP invia al FPGA un messaggio di controllo per settare la frequenza di ricezione per l’hop successivo. Questo avviene appena il DSP ha finito di ricevere 80 simboli. Il messaggio di controllo del DSP è inviato sul canale di trasmissione dati, come per la trasmissione. Quando l’FPGA riceve il messaggio di controllo, setta la frequenza di ricezione ed elimina il messaggio di controllo ricevuto senza trasmetterlo.

Fig. 3. 8 –Segnalazione di controllo del frequency hop in ricezione [16].

3.4.4 Componenti SCA FM3TR (GPP)

Net Device (Data e Voice). Questo componente si occupa del trasporto dei pacchetti dati o voce tra la piattaforma SDR-4000 e le applicazioni (ITM e PTT) sul PC. Il componente Net Device setta la modalità di utilizzo, voce e dati. In altre parole il Net Deveice agisce come interfaccia tra i componenti SCA CORBA e lo stack TCP/IP.

40

Le interfacce del Net Device verso i componenti FM3TR rispettano le specifiche SCA. L’interfaccia verso il PC è di tipo TCP/IP/Ethernet, e contiene un buffer per gestire i temporanei cambiamenti di rate delle applicazioni. Il Net Device Voice trasferisce il traffico voce dal socket PTT al codec CVSD e viceversa. Il Net Device Data trasferisce il traffico dal socket ITM verso (e da) il DLC. L’utilizzo di due differenti socket, come l’utilizzo di due porte separate (una per ITM ed una per PTT) offre completa indipendenza fra le due applicazioni.

Come vedremo nel paragrafo 3.5.1 ai dati grezzi (raw data) l’applicazione aggiunge un header ad ogni pacchetto in modo da indicare l’informazione sulla lunghezza del pacchetto. Questo però ha solo significato locale, tra il PC e l’unità SDR-4000 dove risiede il componente Net Device.

DLC (Data Link Control). Segmento dati. Questo componente è una

risorsa SCA che esegue la frammentazione e il riassemblaggio dei messaggi dati, da e per l’applicazione ITM. In questo componente inoltre risiede la funzionalità ARQ per garantire la consegna dei messaggi.

In trasmissione, il componente DLC riceve messaggi dati dal Net Device (Data), divide il messaggio in più frammenti (se necessario), costruisce il DLC_frame per ogni messaggio/frammento e trasmette il DLC_frame verso il Data MAC per l’ulteriorie elaborazione prima della trasmissione in aria. Per garantire la corretta ricezione del messaggio il DLC implementa un semplice meccanismo ARQ mostrato in Fig. 3.10 e Fig. 3.11.

La struttura del frame generato dal DLC (DLC_frame) è mostrata in Fig. 3.9.

41

I campi src, dst, msg_len e Data segment sono quelli provenienti dall’applicazione. Il campo msg_id è aggiunto dal DLC. MAX_DATA_LENGTH indica la dimensione del DLC_frame calcolata in modo di avere la massima correzione d’errore, minime ritrasmissioni, etc.

In ricezione, il DLC riceve i frame di tipo dati dal componente MAC (decodificati R-S). Basandosi sull’informazione contenuta nell’header, il DLC continua a assemblare frammenti per tutta la lunghezza del messaggio. Successivamente il DLC inoltra il messaggio al Net Device. Ogni volta che il DLC riceve un frame del messaggio invia un ACK verso il Data-MAC (non c’è codifica R-S per i messaggi di ACK) per informare dell’avvenuta ricezione. Il Data MAC provvederà ad inviare l’ACK al trasmettitore.

Nelle figure seguenti è riassunto il comportamento del meccanismo ARQ del DLC. In rosso è marcato lo stato iniziale.

Fig. 3. 10 – Stato del processo ARQ di tramsmissione [16].

Fig. 3. 11 – Stato del processo ARQ di ricezione [16].

Codec Reed-Solomon (R-S). Il codec R-S è il componente della waveform

42

l’applicazione. Il sistema utilizza due codici, uno interno ed uno esterno. Il codice interno è l’RS(105,72,7) mentre il codice esterno è l’RS(16,14,5). Il secondo codice è previsto nel caso in cui si implementi sistema full-duplex e quindi l’ARQ opzionale, detto anche ARQ-per-hop. È dimostrato però che se il codice esterno è implementato nel sistema half duplex la probabilità d’errore è maggiore.

Durante il processo di decodifica, il decoder R-S può fallire a causa di troppi errori sui simboli.

I codici Reed-solomon sono codici sistematici. Il codice RS(n, k, m) trasforma una parola composta da k simboli in una da n simboli. I simboli di parità aggiunti sono 2t cioè n-k. Ogni simbolo è composto da m bit. Il potere rivelatore del codice è n mentre il potere correttore del codice è t.

Fig. 3. 12 – Codice R-S.

Per le proprietà della codifica Reed Solomon il decoder esterno può correggere un simbolo errato (potere correttore del codice) e rivelarne fino a 16 (potere rivelatore del codice). Quando questo decoder esterno fallisce, i simboli vengono passati così come sono al decoder interno. Quando il decoder interno fallisce il blocco viene semplicemente cancellato. I test dimostrano che il secondo codec, quello più esterno effettivamente introduce nuovi errori se questo è utilizzato nel sistema half-duplex.

Il codificatore R-S trasforma un blocco da 126 Byte in uno da 210 Byte. Nel caso in cui riceva un blocco corrispondente a un messaggio ACK, il codec, senza alcuna codifica/decodifica lo trasmette direttamente al Data MAC o al DLC.

Sul lato trasmissione il componente DLC passa il messaggio testo, cioè 126 Byte, proveniente dall’applicazione ITM all’R-S codec. I 126 Byte sono divisi in due blocchi da 63x8 bit. Entrambi i blocchi sono riarrangiati in 72