Seguendo il medesimo approccio utilizzato per la trasmissione, anche il codice del ricevitore è stato strutturato secondo un’organizzazione gerarchica. Il Main VI, di cui sono stati riportati Block Diagram e Frontal Panel in figura 5.8 e figura 5.9 rispettivamente, provvede sia alla fase di inizializzazione dei parametri, sia alla definizione delle funzioni LabVIEW che permettono di configurare la NI-USRP per l’acquisizione dei campioni. Affinché questa azione venga svolta correttamente, è necessario completare alcune operazioni preliminari che prevedono: l’apertura della sessione in ricezione (niUSRP Open Rx Session), la specifica dei riferimenti di clock e frequenza, e la configurazione dei parametri I/Q rate e carrier frequency, in accordo con i valori impiegati in trasmissione, mediante l’apposito VI (niUSRP Configure Signal). Conclusa tale procedura, viene inizializzata la ricezione tramite l’USRP (niUSRP Initiate) che, come precedentemente esposto, permette solamente l’acquisizione di un numero limitato di campioni, specificato dall’utente mediante il controllo “Number of Sample”. Per ovviare a tale comportamento, il VI adibito a suddetta operazione (niUSRP Fetch Rx Data (poly) ), è stato collocato all’interno di una struttura while che consente di acquisire i blocchi dei campioni ricevuti in sequenza, simulando così un’acquisizione continua del segnale. La ricezione risulta pertanto scandita dall’esecuzione dell’istruzione ricorsiva, la quale, per ciascuna iterazione svolta, presenta un nuovo vettore di dati da elaborare tramite software. Ad eccezione del primo, scartato in quanto corrotto dagli effetti transitori degli elementi RF dell’hardware, ogni nuovo blocco viene sottoposto all’algoritmo di sincronizzazione, descritto nel precedente paragrafo, al solo scopo di rivelare la presenza del segnale utile. Quando tale evento si verifica, sia il blocco in esame, sia quelli immediatamente successivi, in numero pari al valore specificato in “Number of Block to Save” vengono ordinati, per mezzo di uno shift-register, all’interno di un singolo vettore. Ovviamente, la dimensione del vettore nel quale sono conservati risulta maggiore del numero di campioni che compongono il segnale ricevuto, al fine di evitare la perdita di informazioni. A questo punto il vettore così generato viene posto in ingresso ad una struttura case, la cui esecuzione è governata da una variabile booleana (un flag) associata alla terminazione della sequenza acquisita. All’interno del case viene ripetuta l’esecuzione dell’algoritmo di sincronizzazione, considerando solamente la sezione iniziale del vettore (corrispondente ai primi due blocchi acquisiti), al fine di stimare l’indice associato al primo campione utile del segnale. Determinato tale valore, il VI “Data_Detection_&_Extraction_Signal” permette di estrarre la sola sequenza di campioni utili, basandosi sui parametri condivisi tra trasmettitore e ricevitore, specificati in fase di inizializzazione. Conseguentemente a questa operazione incontriamo il blocco LabVIEW che svolge la funzione del
92
demodulatore multiportante, la cui struttura è riportata in figura A.4 in appendice A, per maggiore chiarezza.
Indipendentemente dalla forma d’onda impiegata in trasmissione, nello svolgimento delle simulazioni è stato considerato il demodulatore relativo ad un tradizionale segnale OFDM. Tale scelta è giustificata sia dalla notevole somiglianza tra i formati di segnalazione analizzati in questo lavoro, sia dall’esigenza dei sistemi di quinta generazione di risultare compatibili con i dispositivi operanti sull’attuale rete radiomobile, i quali, nella maggioranza dei casi, prevedono una tecnologia trasmissiva basata sull’OFDM. Il demodulatore è stato strutturato in maniera tale da prevedere un processing duale ed inverso rispetto al modulatore impiegato in trasmissione. Pertanto, dopo l’operazione di filtraggio e conseguente decimazione, i campioni del segnale sono inseriti all’interno di una matrice, la cui organizzazione è tale da presentare, per ognuna delle sue righe, tutti e soli i campioni (nel dominio temporale) associati ad un simbolo OFDM con relativo prefisso ciclico. Questa viene quindi posta in ingresso ad una istruzione ricorsiva di tipo for la quale, ad ogni sua iterazione, preleva ed opera su una singola riga della matrice. In questo modo è possibile operare le medesime operazioni su tutti i simboli OFDM, (vettori di elementi), in maniera sequenziale. La prima operazione svolta nel ciclo prevede la rimozione del prefisso ciclico associato al simbolo in esame. Successivamente sul vettore di N campioni rimanente è applicata l’operazione di FFT che permette di passare, dai campioni del segnale nel dominio temporale, alla rappresentazione dei simboli ricevuti sulle varie sotto-portanti, in frequenza. A questo punto è possibile rimuovere le sotto-portanti virtuali, aggiunte in trasmissione per definire le bande di guardia. Conclusa tale azione, il vettore di elementi restante viene posto in ingresso al seguente VI “Select Pilot” che, come suggerisce il nome, provvede a copiare i simboli pilota in un apposito vettore, la cui posizione è individuata sulla base degli indici specificati in “Pilot_Position_Vector”. Si rende necessaria l’adozione di tali simboli in quanto, grazie ad essi, è possibile determinare il profilo in frequenza del canale di comunicazione. Sfruttando le proprietà di ortogonalità del segnale OFDM analizzate nei capitoli precedenti, congiuntamente all’adozione del prefisso ciclico, i simboli ricevuti da ciascuna sotto-portante risultano nella forma:
Dove: rappresenta l’indice del simbolo in esame, quello relativo alla sotto-portante considerata,
identifica il coefficiente (complesso) della risposta in frequenza del canale associato alla SC n- ennesima, mentre è una variabile aleatoria gaussiana a media nulla, che tiene in conto dell’effetto del rumore. Riferendoci ad un simbolo generico ( , senza perdita di generalità,
93
dalla (5.6) possiamo notare come dipenda da grandezze relative alla sola sotto-portante in esame. Per le portanti pilota, delle quali sono noti i simboli trasmessi, è pertanto possibile ricavare una stima dei coefficienti di canale in frequenza, tramite:
Dove è stato posto ad evidenziare che la (5.7) sia applicabile solamente per le sotto-portanti pilota. Abbiamo così ottenuto un campionamento della risposta in frequenza del canale di comunicazione, basato sulla disposizione delle SC pilota all’interno del simbolo OFDM. A questo punto, è quindi sufficiente effettuare un’operazione di interpolazione sui campioni per stimare la totalità dei coefficienti, da utilizzare per l’equalizzazione. Nello svolgimento delle simulazioni, avendo considerato una portante pilota ogni 12 sotto-portanti utili, una semplice interpolazione lineare, implementata mediante il VI “Channel Estimation Fix” si è rivelata sufficiente alla determinazione del profilo in frequenza del canale di comunicazione. Determinati gli per ognuna delle sotto-portanti utili, l’operazione di equalizzazione è stata implementata banalmente tramite:
Completata la procedura di equalizzazione, dal vettore di elementi vengono rimossi i simboli pilota, tramite il VI “Remove Pilot”, mentre quelli utili rimanenti vengono posti in ingresso al demapper che effettua l’operazione di decisione, sulla base della costellazione 4QAM considerata in trasmissione e basandosi sulla strategia decisionale a massima verosimiglianza. Mediante un generatore PRBS (identico a quello impiegato dal trasmettitore), vengono ricavate le esatte sequenze di bit e simboli trasmessi, le quali, tramite un confronto membro a membro con quelle effettivamente ricevute, permettono di calcolare le prestazioni, in termini BER e SER delle forme d’onda trasmesse. Una volta determinate le probabilità di errore su bit e simboli, nel caso lo si desideri, è possibile salvare i risultati ottenuti all’interno di un file .txt, specificandone il nome ed il percorso tramite i controlli associati ai relativi VI.
94
95
96