Lavori futuri

Lo sviluppo del modulo calradio LLA pu`o dirsi completata per l’esportazione di statistiche di livello MAC e PHY.

Grazie alla struttura dati per l’esportazione delle statiche, pu`o facilmente essere preso come modello per lo sviluppo di moduli per altri device o per altre tecnologie. Quel che resta da sistemare, `e lo sviluppo del modulo che si occupa delle statistiche dei link, implementando le funzionalit`a per la ricerca e la popolazione della struttura dati presentata precedentemente. Vanno inoltre definite delle funzioni per ricavare delle misure dai dati raccolti, come ad esempio il throughput di un link, oppure statistiche circa quale sia il link che utilizza maggiormente il canale, etc.

Attualmente, le statistiche relative ai link, sono gestite solo fino all’appli-cazione cliente. Ovvero, CalRadio, qualora riceve un pacchetto, ne estrapola le caratteristiche richieste ed invia tale informazioni ad un client (lato UL-LA), il quale si serve di un apposito character device per immagazzinare i risultati.

Per quanto riguarda l’architettura in generale, questa si `e dimostrata sta-bile durante i test eseguiti. La stabilit`a `e un requisito essenziale, sopratutto in un sistema cos`ı complesso, composto da diversi “point of failure”. Difat-ti, possono presentarsi problemi nella CalRadio come nella comunicazione client-server o ancora applicazioni (LU). L’importante `e che il core di UL-LA rimanga stabile, anche in presenza di guasti nei sistemi correlati. Se questo non fosse, un crash del framework provocherebbe un arresto dell’intera macchina che fa hosting di ULLA in seguito ad un KERNEL PANIC.

2.9. CONTRIBUTO 69

Inoltre, per poter gestire questi errori, `e importante inserire dei meccanis-mi di notifica degli errori. Ad esempio, le statistiche provenienti da CalRadio, contengono un campo apposito per la segnalazione degli errori. In questo mo-do si riesce a capire quanmo-do il device non funziona correttamente, oppure se la comunicazione `e interrotta. Risulta quindi importante, nelle applicazioni future, continuare in quest’ottica per mantenere il sistema il pi`u resistivo possibile agli errori delle applicazioni correlate.

Kernel Space vs User Space

I moduli appena descritti sono implementati su un sistema Linux. Questi quindi possono essere visti come un set di applicazioni che cooperano tra loro.

Uno dei concetti fondamentali su cui si basa l’architettura dei sistemi Unix `e quello della distinzione fra il cosiddetto user space, che contraddis-tingue l’ambiente in cui vengono eseguiti i programmi, e il kernel space, che `e l’ambiente in cui viene eseguito il kernel.

Ogni programma vede se stesso come se avesse la piena disponibilit`a della CPU e della memoria ed `e completamente ignaro del fatto che altri program-mi possono essere messi in esecuzione dal kernel, salvo nel caso utilizzi i meccanismi di comunicazione previsti dall’architettura.

Grazie a questa separazione non `e possibile che singolo programma dis-turbi l’esecuzione di un altro programma o del sistema e questo `e il principale motivo della stabilit`a di un sistema unix-like nei confronti di altri sistemi in cui i processi non hanno di questi limiti, o che vengono eseguiti al livello del kernel.

Pertanto deve essere chiaro a chi programma in Unix che l’accesso diretto all’hardware non pu`o avvenire se non all’interno del kernel; al di fuori del kernel, il programmatore deve usare le opportune interfacce che quest’ultimo espone verso lo user space.

In ULLA il software che opera in user space `e costituito dalle applicazioni LU e dall’applicazione client per la comunicazione. Oltre a questi, vi sono i thread generati per gestione delle statistiche e dei campionamenti. Il core di ULLA come i moduli LP, operano invece in spazio kernel.

In questo capitolo abbiamo mostrato l’architettura del framework ULLA sia nel contesto pi`u ampio del progetto ARAGORN sia come applicazione stand alone nell’ambito della tesi. Per ULLA `e stato sviluppato un modulo per estrapolare statistiche di livello MAC e PHY dai device CalRadio.

Inoltre sono state definite le strutture dati a supporto di tali moduli e utilizzabili per lo sviluppo di altri LP. Queste strutture dati, sono state modellate per essere utilizzabili anche con tecnologie diversi dallo standar 802.11 per le reti WiFi.

Sono inoltre stati definiti dei parametri avanzati, rispetto a quelli stan-dard usati da ULLA, in modo da supportare in sensing dello spettro radio, esportando contemporaneamente statistiche riguardanti il CCA per tredici canali. Per una lista completa dei parametri disponibili, si veda l’Appen-dice A.

Vedremo nel capitolo successivo, la parte mancante della descrizione del-l’architettura in Figura 2.7, ovvero parleremo dei dispositivi CalRadio.

Capitolo 3

CalRadio

CalRadio `e un device sviluppato alla UCSD (UC San Diego) nel progetto Calit2 [22].

La piattaforma `e dotata di un transceiver che opera secondo lo standard 802.11b e che permette di implementare via software il livello MAC. Questa proprie`a rende a tutti gli effetti CalRadio una SDR (software defined radio). CalRadio `e dotata di un chip DSP della Texas Instruments, il quale viene programmato in linguaggio C, al fine di implementare il livello MAC.

La piattaforma `e inoltre dotata di un processore ARM che permette l’esecuzione di un sistema operativo Linux.

CalRadio `e quindi una dispositivo stand alone, che implementa la tec-nologia wireless 802.11b. Nella tesi il dispositivo non viene utilizzato per operare in maniera autonoma, ma viene collegato al framework ULLA per estrarre statistiche di livello MAC e PHY.

3.1 Specifiche tecniche

CalRadio `e composta di:

- TI TMS320VC5471 ARM+ DSP (ARM7TDMI + 5410 style DSP) - 8-bit software controlled internal status LEDs

- Power On/Off key, 2-GP keys, and reset control key - Power management

- Operation from WallWart (Plug Transformer) (9 - 14 volt) via power connector

- Size 4 x 6 x 3

- Four external LED indicators - External reset pushbuttons - RJ45 Ethernet jack

- Dismountable antennas - SMA connector - 10/100 Ethernet Phy

- 4 channel ADC 100KSPS (TLV2541) - 4 channel DAC 100KSPS (TLV5636)

- Jumpers on all power connections to measure current draw - Serial port connector (external) Mini-DIN

- EMIF pins to mezzanine connector + Vcc

- 2 Mbytes static RAM - ARM side, 512KB - DSP - 16 Mbytes SDRAM - ARM side

- 4 Mbytes Flash ROM - ARM side - DSP Expansion connector

Software

Il software caricato e gestito dal processore ARM, `e composto di due elementi principali: is sistema operativo UCLinux e un bootloader.

Il bootloader di CalRadio `e chiamato “crload”. Quando il processore viene avviato, o in seguito ad un reset, esegue il bootloader, il quale si occupa di inizializzare tutti i registri, caricare la mappa della memoria, impostare la modalit`a operativa, avviare il sistema operativo ed infine, presenta un menu dal quale possono essere avviate operazioni di debug, caricamento, avvio del sistema Linux, etc.

Il bootloader viene eseguito dal codice Assembly, descritto dal file head c5471.ASM e le operazioni svolte sono:

1. Inserire le tabelle dei vettori in memoria 2. Impostare vari parametri della memoria 3. Impostare la frequenza del clock

3.1. SPECIFICHE TECNICHE 73

4. Abilitare il chip UART per l’I/O da console 5. Eseguire un check della memoria

6. Inizializzare il DSP

7. Eseguire il bootstrap del DSP

8. Spostare il bootloader dalla flash alla RAM 9. Avviare la GUI dei comandi

L’inizializzazione del DSP consiste dei seguenti passi:

1. Impostare tutti i registri del DSP alla configurazione di default 2. Impostare la mailbox per la comunicazione con l’ARM

3. Caricare i registri per i chip HFA3863 e MAX2821 4. Istanziare l’handler delle interrupt

5. Inizializzare il ciclo principale di gestione del DSP

All’arrivo di una interrupt che segnala la ricezione di un pacchetto (generata dal transceiver), il DSP:

1. Imposta il DMA per leggere il pacchetto 2. Calcola il CRC

3. Manda un ACK

4. Sposta il pacchetto in un buffer, per trasferirlo all’ARM Il ciclo principale di gestione del DSP esegue le seguenti operazioni:

1. Controlla continuamente lo stato della mailbox (poll) e qualora sia pre-sente un pacchetto proveniente dall’ARM. In caso sia prepre-sente, gestisce la spedizione.

2. In caso sia presente un messaggio, ricevuto dal transceiver, diretto all’ARM, questo chiama invoca una interrupt verso l’ARM.

3. Nel caso il DSP debba mostrare dei messaggi dei debug, viene segnalata all’ARM la presenza di questi.1

4. Nel caso siano presenti delle statistiche di livello MAC o PHY, viene segnalata all’ARM la presenza di queste.2

3.2 Architettura

L’hardware che compone CalRadio consiste di un processore ARM inter-connesso mediante una memoria condivisa ad un DSP che implementa via software il livello MAC 802.11b. Nelle Figure 3.2 e 3.1, viene mostrata CalRadio e uno schema della sua architettura.

(a) CalRadio (b) CalRadio

Figura 3.1: CalRadio

Nel pannello frontale della radio, si vedono i led programmabili, atti a mostrare le fasi di comunicazione, o utili per segnalare l’esecuzione di deter-minate operazioni. Nella parte posteriore, vi `e un tap RJ45 per il collega-mento ethernet, l’adattatore per l’antenna e l’ingresso per l’alimentazione, oltre ad una porta di comunicazione seriale.

L’architettura mostrata in Figura 3.2, mostra l’interazione tra il micro-processore ARM, il DSP e il trasmettitore RF.

Vediamo ora in dettaglio queste componenti.