Nella descrizione precedente si `e vista come la FPGA si occupi della parte software della catena di ricezione. Nell’ approccio usato da noi in cui la USRP svolge solo il compito della conversione del segnale in basso, la parte di signal processing `e svolta solo dalla CPU del calcolatore connesso tramite USB 2.0, nel caso USRP, o tramite cavo ethernet nel caso USRP2. Questo approccio viene definito appunto fully-software.
Per capire i vantaggi alla base di questo tipo di approccio si devono analizzare gli inconvenienti del caso completamente hardware. Le problematiche che risiedono in un approccio di tipo ”fully-hardware” possono essere sintetizzate in due punti. In primo luogo il dispositivo gode di scarsa flessibilit`a. Una volta costruito l’hardware esso resta sostanzialmente uguale, e
Tabella 2.2: Daughterboards e relative frequenze Daughterboard RX TX BasicRX 1MHz÷250MHz - BasicTX - 1MHz÷250MHz LFRX DC-30MHz - LFTX - DC-30MHz DBSRX 800MHz ÷ 2.4GHz - RFX400 400MHz÷ 500MHz 400MHz÷ 500MHz @ 100+mW RFX900 800MHz÷ 1000MHz 800MHz÷ 1000MHz @ 200+mW RFX1200 1150MHz÷1450MHz 1150MHz÷1450MHz @ 200+mW RFX1800 1,5GHz÷2.1GHz 1,5GHz÷2.1GHz @ 100+mW RFX2400 2.3GHz÷2.9GHz 2.3GHz÷2.9GHz@ 100+mW TVRX (fig.2.9) 50MHz÷800MHz - WBRX (fig.2.10) 50MHz÷2.2GHz 50MHz÷2.2GHz
non possono essere apportate, in linea di massima, modifiche ad una catena che ne fa uso, se non sostiuendo l’intero blocco hardware. Un secondo problema non trascurabile `e il costo di svilupppo, progettazione e realizzazione di circuiti integrati che implementino precise funzionalit`a richieste.
Come gi`a detto la SDR si propone di risolvere queste problematiche con una soluzione scalabile e facilmente aggiornabile. Tutto questo in ogni caso non esclude la nascita di nuove problematiche che sono legate alla programmazione, nonch´e alle risorse computazionali limitate dalla CPU. Nel nostro caso specifico ad esempio si prevede la ricezione di un segnale in real-time.Il segnale ricevuto, tramite appunto USRP, viene mandato all”’elaboratore soft- ware”. Da qui in poi entra quindi in gioco la capacit`a di processare della CPU che attraverso l’infrastruttura SCA-complaint OSSIE, chevedremo successivamente pi`u in dettaglio, gestisce la catena di ricezione implementata, con tutte le sue problematiche e i suoi vantaggi. Nello specifico si ha un aumento del carico computazionale che in genere mette a rischio, se non affrontato adeguatamente, la corretta ricezione real-time.
Nel corso di questo lavoro di tesi ci si `e imbattuti pi`u volte nelle problematiche dovute all’ acquisizione in real-time. Si rimanda ai capitoli successivi la descrizione di tali casi.
Software Communications
Architecture (SCA)
Come appreso dai capitoli precedenti quando si ha a che fare con un progetto di una SDR, dobbiamo disporre di due sezioni fondamentali, quella hardware e quella software. Se la parte hardware ha nell’uso dell’Universal Software Radio Peripheral, una soluzione comune e soddisfacente. La parte software ad oggi pu`o essere implementata in diversi modi. Uno di questi, che poi `e quello utilizzato, `e l’uso di SCA. Questa pu`o essere definita come una struttura che lavora per migliorare il “dialogo” tra parte hardware e software.
Una volta descritti i tasselli principali che compongono SCA, descriveremo la piattaforma utilizzata in questo lavoro, OSSIE, una piattaforma open-source che fa riferimento ai vincoli e alla struttura SCA, in sintesi SCA-compliant
3.1
Joint Tactical Radio System (JTRS) e SCA
A partire dal 1997 il dipartimento della difesa (Department of Defense - DoD) degli Stati Uniti D’America ha avviato un progetto che mirava alla risoluzione di alcuni problemi propri della propagazione radio. Problemi legati ad esempio alla modulazione, ai sistemi multi-banda o multi-modo, e soprattutto problemi legati alla programmabilit`a dei sistemi radio.Questo programma prendeva il nome di Joint Tactical Radio System (JTRS).
Il progetto JTRS `e un sistema SDR che nasce per uso militare, sviluppato per la comu- nicazione tra le varie divisioni delle forze armate della difesa americana. Esso pu`o essere considerato come il primo passo nell’affermazione della Software Communications Architec- ture. Oggi JTRS afferma che SCA non `e un sistema specifico ma piuttosto una serie di principi da seguire durante il progetto. Il governo degli Stati Uniti inizialmente si aspettava che SCA diventasse uno standard commerciale apprezzato, ed in virt`u di tale previsione design`o le
specifiche per soddisfare i requisiti delle applicazioni sia commerciali che militari.
L’architettura SCA descrive in che modo operano e come sono legati tra loro i componenti
Figura 3.1: Struttura software SCA
software e hardware che formano un JTRS. Indica inoltre quali sono le specifiche minime di cui necessita una piattaforma hardware per essere compatibile con il modello, cio`e in modo che il software creato secondo le regole SCA sia funzionante.
La struttura software di SCA `e stata progettata in modo che possa essere un’architettura facilemente aggiornabile, scalabile, che facilit`a l’iteroperabilit`a tra componenti, ed in cui nuovi apparati possano essere facilemente inseriti senza problemi di compatibilit`a.
In particolare SCA definisce l’ambiente operativo e ne specifica i servizi e le interfacce. L’ambiente operativo `e caratterizzato da:
una struttura base, chiamata Core Framework (CF) middleware, il CORBA
un sistema operativo basato sullo standard Portable Operating System Interface POSIX In figura 3.1 `e mostrata la relazione che intercorre tra l’ambiente operativo (CF o CTS vedi figura 3.2) e i componenti SDR non di base.
La struttura software SDR mostra che i componenti non di base sono riassunti fuori dal- l’hardware fondamentale e come tutte le entit`a sono connesse attraverso un bus logico di tipo software basato su CORBA. Per consentire ai modem non-CORBA, di interfacciarsi con componenti CORBA (una descrizione pi`u dettagliata verr`a fatta nel paragrafo successivo), sono previsti degli adattatori. Si possono utilizzare bus diversi nei sottosistemi Red e Black (nell’ambito della sicurezza, i componenti che portano informazioni riservate protette da
meccanismi di crittografia sono detti “Red ”, quelli che portano informazioni accessibili a tutti sono detti “Black ”).
Figura 3.2: Ambienti di sviluppo SCA
Il sistema operativo fornisce tutte le funzionalit`a necessarie per il supporto delle applicazioni in tempo reale. `E utile disporre di interfacce standards per i servizi del sistema operativo, in modo da facilitare il riutilizzo delle applicazioni.
POSIX `e uno standard industriale molto diffuso, che pu`o essere compatibile con il middleware CORBA. Questo standard presenta delle caratteristiche che vanno oltre quelle strettamente necessarie, per questo SCA raccomanda l’uso di POSIX 1003.13, che ha requisiti minori ma sufficienti.
Il CF rappresenta uno dei componenti chiave di un sistema SCA. Esso `e formato dall’insieme dei servizi e delle interfacce per il livello applicativo, che astraggono i livelli inferiori software e hardware. In particolare esso prevede:
interfacce di livello per le applicazioni interfacce per il controllo del sistema
interfacce di servizio che suppportano applicazioni principali e secondarie
un profilo di sistema, cio`e un insieme di file che descrivono le caratteristiche dei disposi- tivi hardware e dei componenti software, quali interfacce, funzionalit`a, locazioni logiche e interdipendenze.
Le applicazioni comprendono tutte le funzioni per la comunicazione, quali elaborazione numerica dei segnali, protocolli al livello di collegamento, protocolli di rete per la gestione del routing, sicurezza, operazioni di I/O. Si distinguono tra: applicazioni principali (che fanno parte del CF) e altre pi`u generali, dove le prime forniscono supporto alle seconde con una operazione di controllo.
del sistema operativo `e limitato dal profilo definito per POSIX. Le funzionalit`a di rete, definite da protocolli ad un livello inferiore rispetto a quello applicativo, non sono limitate da questa interfaccia in quanto gi`a presenti nel cuore del sistema operativo. Per un sistema SDR si utilizza un modello di riferimento noto come Programmable Modular Communication System (PMCS). Questo introduce i vari ruoli funzionali svolti dai diversi componenti software e le interfacce per il controllo e per il trasferimento dei dati.
SCA realizza i blocchi funzionali del modello di riferimento definendo delle unit`a funzionali
Figura 3.3: Relazione tra strutture di SCA
standard di tipo software chiamate “Resource”. Si definiscono poi i “Devices” che rap- presentano tipi di “Resource” utilizzati dalle applicazioni come componenti software per il supporto dei dispositivi hardware utilizzati. L’architettura software non indica le funzionalit`a di un “Resource” ma sar`a il programmatore a definirle. Le “Resources” sono gestite da un componente software chiamato DomainManager, per mezzo del quale vengono definiti i parametri che le caratterizzano. Esse possono comunicare tra loro e talvolta esiste anche una dipendenza tra una “Resource” e l’altra. In accordo con il middleware CORBA, esse sono degli oggetti di cui sono definite le interfacce con il linguaggio IDL. Grazie a questa definizione, agendo soltanto su queste interfacce `e possibile eliminare una “Resource” o crearne di nuove. L’architettura prevede degli adattatori, questi sono delle “Resource” o dei “Devices” che permettono l’utilizzo di componenti non compatibili con CORBA. In figura 3.4 sono mostrati esempi di implementazioni di “Resource”.
Il ModemDevice rappresenta un controllo, per interfacciarsi con il blocco funzionale mo- dem e con le sue funzionalit`a. Le funzionalit`a del ModemDevice dipendono dal particolare sistema SDR che si vuole realizzare e non sono stabilite dal CF. Le principali funzioni sono
Figura 3.4: Modello di “ Resources”
modulazione/demodulazione, codifica, sincronizzazione e funzioni di spread spectrum. Inoltre questo “Device” comprende l’implementazione dell’antenna e l’elaborazione del segnale a RF. L’ I/O Device permette l’accesso ai dispositivi hardware del sistema, grazie a delle interfacce fisiche esterne. Anche queste funzioni non sono stabilite dal CF, ma dipendono dalla struttura hardware del sistema.
Il SecurityDevice estende le funzioni di sicurezza ai dispositivi hardware. Il NetworkResource prevede funzioni quali bridge, link, repeater e router. Queste non sono specificate dal CF, ma vengono abilitate in base alle caratteristiche del sistema. Il LinkResource riassume i livelli di collegamento con le interfacce. Le funzioni della UtilityResource consistono nella traduzione dei messaggi e anch’esse non sono definite dal CF.
La struttura che viene creata e che si interfaccia con l’utente prende il nome di waveform. Una waveform in generale `e vista come una ”funzione radio”, dove ogni funzione utilizzata per realizzare uno specifico segnale radio `e incluso nel concetto di waveform. Se consideriamo una catena di ricezione ( o trasmissione) tutti i diversi componenti ( modulatore, filtri ecc...) fanno parte del concetto di waveform. Nello specifico una waveform SCA pu`o essere descritta come una o pi`u resources software e/o hardware devices. I blocchi principali per la creazione di una waveform sono creati dal livello applicazioni del CF.