Software Defined Radio: integrare per innovare

Software Defined Radio: integrare per innovare
Introduzione
L’attuale industria wireless si sta rapidamente espandendo utilizzando numerosi
nuovi standard e dispositivi. Nuove tecnologie wireless sono state introdotte a ritmo
sempre più serrato. I consumatori si attendono telefoni cellulari multi-funzione in
grado di parlare, ricevere e-mail e scaricare video da un unico dispositivo portatile.
La globalizzazione ha reso indispensabile che questi dispositivi siano affidabili e
possano comunicare dal Giappone all’Inghilterra, agli Stati Uniti. Progettisti e
costruttori devono continuamente trovare il modo di sviluppare la tecnologia in modo
flessibile ed economicamente conveniente.
E’ evidente che il settore dell’industria wireless sta cambiando e diventando più
complesso che mai. La SDR (Software Defined Radio), un dispositivo di
comunicazione il cui funzionamento dal layer fisico fino ai livelli di protocollo più
elevati è prevalentemente definito tramite software, offre una struttura che consente
questo cambiamento. Questa struttura supporta radio multimodo-multibanda,
roaming globale, riconfigurabilità in condizioni reali di funzionamento e
programmazione in onda, riducendo i problemi che sorgono con l’utilizzo di nuovi
standard di comunicazione. La SDR offre la flessibilità necessaria a cambiare le
funzioni operative di una radio tramite una semplice modifica del codice software
nell’hardware di elaborazione (DPS) del dispositivo. La SDR offre ulteriori vantaggi,
tra cui un migliore utilizzo dello spettro che aumenta ulteriormente il valore della
tecnologia.
Figura 1: Front-End RF SDR
La SDR è supportata dall’U.S. Department of Defense’s Joint Tactical Radio System
(JTRS)[1], dalla Defense Advanced Research Projects Agency’s (DARPA) next
Generation (XG) Communications program[2], e dalla Federal Communications
Commission’s (FCC) Cognitive Radio Technology Proceedings[3]. Ora l’SDR sta
entrando nel mercato consumer, semplificando i cicli di progettazione e introducendo
una gamma di nuove applicazioni. Tuttavia, gli sviluppatori SDR si trovano di fronte
ad un compito difficile quando devono verificare e validare i loro progetti e
necessitano di strumenti di test flessibili e potenti, tanto quanto la tecnologia stessa.
Questo articolo analizza queste attività ed offre soluzioni di test ai problemi che
emergono.
SDR & SCA: semplificare e unificare
La SDR raggiunge l’obiettivo di supportare tutti i diversi standard e tecnologie
offrendo un’architettura radio comune. Sostenuta dal programma JTRS, la SCA
(Software Communications Architecture)[1] è stata adottata come architettura radio
software standard per i sistemi di comunicazione militari. La SCA è una struttura ad
architettura aperta che assicura portabilità, riutilizzabilità e scalabilità dei componenti
hardware e software, così come la interoperabilità tra prodotti sviluppati secondo le
sue linee guida. La SCA avrà alla fine un certo impatto sul settore delle
comunicazioni radio commerciali, perché le architetture commerciali
comprenderanno la maggior parte delle funzionalità già attualmente considerate
nell’SCA. I problemi e le sfide che le implementazioni SCA stanno ora superando,
sono simili a quelle che incontreranno le implementazioni commerciali. La SCA è già
entrata nel mondo commerciale e costituisce la base del Forum SRA (Software
Radio Architecture) [4] dell’SDR.
Figure 2: Struttura software dell’SCA
Tuttavia, la flessibilità che consente all’SDR di supportare tecnologie e standard
diversi, pone sfide impreviste alla validazione dei progetti SDR e alla verifica dei
prodotti finali. La difficoltà dei test SDR nasce dall’elevato numero di differenti moduli
che interagiscono tra loro. Il numero risultante di combinazioni di componenti rende
difficile la verifica del corretto funzionamento di ogni singola combinazione, se non si
dispone di flessibili configurazioni di test. Per ottenere una progettazione efficiente e
un rapido sviluppo dei prodotti, è necessario offrire agli sviluppatori strumenti di test
flessibili.
Integrazione di apparecchiature di test nell’SCA
Man mano che le applicazioni SDR iniziano ad essere riconfigurabili in condizioni
normali di funzionamento e la programmazione via etere è alle porte, si prevede che
un sempre maggior numero di moduli interagiranno nel contesto di una singola
forma d’onda. Le attuali implementazioni dell’SDR hanno una flessibilità tale per cui
la semplice modifica del contenuto di un file di configurazione può cambiare una
forma d’onda applicativa. Il grande numero di moduli software differenti che si
possono combinare per intergire in qualsiasi istante, rende difficile eseguire il test e
la validazione da parte dei progettisti e dei produttori.
Dopo aver completato l’emulazione a livello di sistema e aver validato la funzionalità
del modulo software, arriva il momento di trasferire il tutto sull’hardware reale.
Esistono numerose cause di errore che possono influire sulle prestazioni corrette di
un dato dispositivo. In particolare, possono emergere difetti hardware, bug software
ed errori di calcolo di progettazione che devono essere isolati durante i vari stadi del
ciclo di sviluppo dell’SDR. Test più realistici portano ad un funzionamento più
affidabile dell’SDR.
Gli strumenti, in particolare quelli destinati ad applicazioni wireless, possono far parte
dell’attrezzatura necessaria alla progettazione e al test delle future radio software.
L’integrazione delle apparecchiature di test nell’SCA offre la possibilità di creare
un’astrazione per ogni componente del sistema, permettendo loro di interagire,
indipendentemente dalla loro implementazione fondamentale, di espandere le
possibilità di auto-test dell’applicazione e di consentire un facile passaggio dalle
condizioni di simulazione a quelle di installazione. Gli esempi che seguono illustrano
due di questi metodi.
Test del ricevitore: simulazione delle prestazioni del sistema in ricezione
I generatori di forme d’onda arbitrarie (AWG – Arbitray Waveform Generator)
consentono di avvicinare le condizioni di test a quelle operative reali di ricezione
fornendo una sorgente di segnali analogici e digitali, oltre a una fonte di rumore e
possibilità di modulazione per i test dei ricevitori SDR. L’uscita digitale dell’AWG può
essere usata per stimolare i circuiti digitali o simulare le prestazioni di un ADC. Si
ottengono ulteriori vantaggi quando il segnale dell’AWG viene integrato nella forma
d’onda applicativa di un dispositivo SDR. Questa integrazione consente al framework
principale di controllare l’AWG nello stesso modo con cui controlla qualsiasi altro
componente software o dispositivo. Così facendo, il segnale dell’AWG si può
includere nella forma d’onda applicativa con la sola modifica di un file XML
(Extensible Markup Language).
Di conseguenza, è possibile sviluppare un’applicazione specifica per il test di un
qualsiasi gruppo di componenti. Quando uno specifico set di componenti viene
combinato per realizzare una data applicazione, una versione modificata della stessa
forma d’onda che comprende i moduli di test può essere utilizzata per verificare e
validare le prestazioni dei moduli originali. Inoltre, il codice usato nelle configurazioni
di test precedenti può essere riutilizzato praticamente senza alcuna modifica,
copiando la funzionalità principale del codice precedente nel nuovo modulo di test.
Per integrare un AWG nella forma d’onda di una applicazione sviluppata secondo le
linee guida dell’SCA, è necessario creare un componente proxy che lavori come un
adattatore tra l’AWG, il core framework e la forma d’onda. Questo adattatore,
chiamato anche wrapper, prende le caratteristiche della classe di “LoadableDevice”,
così come definita dall’SCA. Con queste caratteristiche, l’adattatore è in grado di
allocare o disallocare certe capacità e possiede l’interfaccia per caricare e scaricare
forme d’onda predefinite nella memoria delle forme d’onda del generatore.
Queste capacità, configurate al momento della creazione del componente proxy,
rappresentano le caratteristiche fisiche dell’AWG e sono descritte in un file XML.
Il wrapper necessita della propria interfaccia IDL (Interface Definition Language) per
poter interagire con altri componenti. Questa interfaccia costituisce il punto di
ingresso per il trattamento delle chiamate middleware. Il wrapper attende e risponde
ad ogni chiamata effettuata dall’applicazione.
Figure 3: Integrazione di un AWG nell’SCA per il test e la validazione di forme d’onda
applicative
Dopo che il wrapper è stato creato e inizializzato, la forma d’onda applicativa
assegna le capacità richieste, carica la forma d’onda richiesta, realizza le necessarie
connessioni tra i componenti ed avvia tutti i componenti, compreso l’AWG. Il file di
forma d’onda da caricare nella memoria può essere creato utilizzando gli strumenti
per l’editing delle forme d’onda inclusi nell’AWG, oppure utilizzando altri strumenti
specializzati, come MATLAB. Per integrare l’AWG in una forma d’onda esistente, è
necessario modificare il file SAD (Software Assembly Descriptor) dell’applicazione
per includere il wrapper come un componente e descrivere le necessarie
connessioni. Come mostrato in Figura 3, l’AWG può essere connesso a differenti
stadi del ricevitore, al fine di isolare meglio un modulo o moduli specifici per il test.
Una volta creata, la forma d’onda applicativa effettua l’inizializzazione e la
configurazione dell’apparecchiatura e di tutte le funzioni di test necessarie a
verificare la corretta prestazione dell’applicazione. L’applicazione stessa è
responsabile dell’esecuzione dei test sul componente o sul set di componenti
desiderato. L’applicazione fornisce i dati di test, li trasferisce all’AWG che a sua volta
li invia al componente da provare. L’applicazione monitorizza i componenti provati e
verifica il loro corretto funzionamento. In caso di guasto, l’applicazione può far
scattare un allarme e registrare l’operazione. L’informazione registrata, assieme al
fatto di conoscere l’esistenza di una fonte di guasto, consente un debug più accurato.
Test del trasmettitore: determinazione delle cause/effetti nelle caratteristiche di
segnali che variano nel tempo
A seguito delle norme FCC sull’utilizzazione dello spettro, la validazione delle forme
d’onda SDR diventa un elemento cruciale del ciclo di sviluppo. Come con ogni radio
digitale, possono nascere diverse possibili fonti di errori operativi, quali componenti
spuri causati da non linearità dell’amplificatore di potenza, clipping del segnale
introdotti dal DAC, troncamenti di fase e jitter periodico. Nel caso dell’SDR il
problema aumenta, in quanto ogni differente set di componenti software che
comprende una forma d’onda applicativa deve essere validato. Nel momento in cui le
applicazioni SDR iniziano a implementare ulteriori forme d’onda e standard, che
possono anche occupare bande di frequenza differenti, il processo di validazione si
complica e richiede maggiore flessibilità da parte dell’apparecchiatura di test. Date le
previste tendenze nello sviluppo dell’SRD, lo scenario è destinato a diventare più
complesso man mano che la tecnologia progredisce. L’implementazione di diverse
tecnologie che si basano sulle caratteristiche della radio cognitiva, come il
programma XG [2], richiede una rigorosa e idonea validazione, poiché la non
conformità alle norme può causare seri problemi di prestazioni nei sistemi coinvolti.
Gli analizzatori di spettro in tempo reale (RTSA - Real-Time Spectrum Analyzers)
sono ideali per il test e la validazione di trasmettitori radio. Con segnali RF che usano
modulazioni complesse e variazioni del segnale, è indispensabile tenere il passo con
la natura variabile nel tempo dei segnali. A causa delle limitazioni strutturali dei
sistemi di trigger e di buffer della memoria degli analizzatori di spettro e degli
analizzatori di segnali vettoriali tradizionali, questi strumenti hanno un basso valore di
attendibilità e un’elevata incertezza nella cattura di eventi variabili nel tempo.
Analogamente agli AWG, gli RTSA richiedono degli adattatori e un’interfaccia IDL.
Sebbene non esistano capacità di carico software definite nelle apparecchiature di
test, l’adattatore stesso può leggere un file di configurazione e quindi caricare questa
configurazione nello strumento. Questa capacità di carico consente di utilizzare una
procedura semplificata per configurare l’RTSA da integrare in un framework SCA. Il
contenuto e il formato dei file di configurazione dipendono dall’applicazione. Per
supportare i codici di test preesistenti, il contenuto del file di configurazione può
essere costituito dagli script usati dalle configurazioni di test precedenti. Usando
questo tipo di approccio, ogni volta che una forma d’onda applicativa viene
esemplificata, si può caricare il corrispondente file di configurazione impostando così
nell’RTSA la corretta modalità di acquisizione, la frequenza centrale, l’intervallo di
frequenza e qualsiasi altro attributo necessario. Come con qualsiasi altro dispositivo
SCA, il wrapper per l’RTSA deve avere un set di capacità operative da allocare o
disallocare durante il runtime. Nel caso dell’RTSA, le capacità di allocazione possono
ridursi ad una semplice proprietà che indica se l’analizzatore è disponibile o se sta
operando con un’altra forma d’onda.
Figure 4: Integrazione di un RTSA nell’SCA per il test e la validazione di forme d’onda
applicative
Conclusioni
La progettazione SDR comporta nuovi tipi di test e richiede un approccio flessibile
all’integrazione e alla validazione di sistemi e sottosistemi. Utilizzando le
caratteristiche proprie dell’SCA, un approccio integrato ai metodi di test consente di
passare facilmente dalla progettazione all’installazione. La creazione di wrapper
software attorno alle apparecchiature di test e nella forma d’onda di definizione di
un’applicazione SDR, facilita e accelera questo processo per i dispositivi di
comunicazione SDR.
Con il proliferare sul mercato dei dispositivi SDR, le tradizionali apparecchiature
utilizzate per la progettazione e il test delle tecnologie wireless diventeranno presto
obsolete. L’SDR scavalca l’attuale settore industriale del wireless e richiede nuove
metodologie di progettazione. Le apparecchiature di test RF e wireless devono
fornire soluzioni per l’SDR integrando strumenti di analisi, di misura e sonde nel
framework SCA.
Referenze
1. JTRS Program http://jtrs.army.mil/
2. XG Program http://www.darpa.mil/ato/programs/XG/
3. FCC Cognitive Radio Technologies Proceeding (CRTP)
http://www.fcc.gov/oet/cognitiveradio/
4. SDR Forum http://www.sdrforum.org/
Panoramica su Tektronix
Tektronix, Inc. è un produttore di strumenti di test, misura e controllo che offre a
livello mondiale soluzioni di misura a società operanti nel settore dei semiconduttori,
dei computer e delle telecomunicazioni. Grazie a 60 anni di esperienza, Tektronix
permette ai suoi clienti di progettare, costruire, installare e gestire le tecnologie
avanzate e le reti di telecomunicazioni globali delle prossime generazioni. Tektronix
ha sede a Beaverton, nello Stato dell’Oregon (U.S.A.), e opera in 19 Paesi. Il sito
web Tektronix è www.tektronix.com
###
Tektronix è un marchio registrato di Tektronix, Inc. Tutti gli altri nomi commerciali a cui si fa riferimento
sono marchi di servizio, marchi di fabbrica o marchi registrati delle rispettive aziende.