Controllo della Qualità del Servizio in applicazioni distribuite con vincoli real-time per reti wireless di sensori

Transcript

1 Università degli Studi di Pisa FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica Tesi di Laurea Specialistica Controllo della Qualità del Servizio in applicazioni distribuite con vincoli real-time per reti wireless di sensori Candidato: Francesco Piga Relatori: Chiar.mo Prof. Paolo Ancilotti Chiar.mo Prof. Giuseppe Lipari Dott. Paolo Pagano Anno Accademico

2 Alla mia famiglia A Marianna Al mio Amico Alberto

3 Sommario I recenti miglioramenti in ambito hardware, lo sviluppo di sistemi operativi real-time per dispositivi embedded e il supporto dello stack di rete al traco real-time permettono di utilizzare le reti wireless di sensori in applicazioni che richiedono grandi risorse computazionali e qualità del servizio: esempio sono le applicazioni di tracking basate sulla visione multinodo. Nelle applicazioni soft real-time distribuite, la Qualità del Servizio dipende da due fattori: dalla qualità del servizio fornita a livello di rete, mediante l'allocazione di risorse (banda), e la qualità del servizio fornita dal sistema operativo come la possibilità di schedulare secondo requisiti real-time i task che si occupano della trasmissione/ricezione dati e anche di altre attività, come ad esempio l'image processing. Infatti entrambi i fattori concorrono alla performance complessiva dell'applicazione. Il simulatore è uno strumento molto importante per lo sviluppo e l'analisi di applicazioni innovative. Nel laboratorio ReTiS Lab della Scuola Superiore Sant'Anna di Pisa è stato sviluppato il simulatore RTNS, una integrazione del noto simulatore di rete NS-2 con il simulatore RTSim, che si occupa della simulazione del kernel sul nodo. Nel presente lavoro di tesi il simulatore RTNS è stato arrichito con il supporto per la realizzazione del meccanismo di accesso al mezzo senza contesa (GTS) come previsto dallo standard IEEE La validazione del lavoro è stata eettuata analizzando il comportamento di una rete wireless di sensori strutturata secondo una topologia a stella e realizzata per supportare una semplice applicazione di tracking distribuito.

4 Indice Prefazione x 1 Introduzione alle reti wireless di sensori Introduzione alle reti wireless di sensori Cenni sui sistemi real-time Motivazioni al lavoro di tesi La suite di protocolli IEEE Introduzione Architettura di IEEE Il livello sico Il livello MAC Tipologie di Nodi Topologie di rete Struttura del superframe Tipologie di pacchetto Il pacchetto beacon Il pacchetto command Il pacchetto data Il pacchetto acknowledgment Tipologie di traco e trasferimento dati Traco non real-time: CAP Descrizione Generale L'algoritmo CSMA-CA Traco real-time: CFP

5 INDICE v Descrizione Generale Pacchetto di comando GTS Speciche GTS nel pacchetto beacon Primitive di gestione dei GTS Procedure di allocazione Procedura di deallocazione Trasmissione e ricezione dati L'ambiente di Simulazione L'importanza della simulazione Il simulatore NS Descrizione del Nodo Wireless Il simulatore RTSim Il simulatore RTNS Le reti WPAN in NS Il package WPAN Supporto per il protocollo IEEE La classe Mac802_15_ Attivazione di nodo Coordinator Attivazione di nodo Device La trasmissione dati su banda garantita Aspetti implementativi e modiche Implementazione del database Primitive e metodi implementati Le primitive GTS di MLME Metodi di supporto al meccanismo GTS Trasmissione mediante GTS Uno scenario applicativo soft real-time: il tracking distribuito Introduzione al tracking distribuito L'applicazione di tracking Applicazione e Agente Il modulo di networking La microcamera Oggetti in movimento

6 INDICE vi Il modulo computazionale Invio di un report Ricezione di un report Lo scenario di tracking Valutazione di performance Scenario taxiway Scenario supermercato Conclusioni 92

7 Elenco delle gure 1.1 Parametri temporali tipici di un task real-time Lo stack di IEEE Organizzazione logica del livello PHY Topologia a Stella e Peer-to-Peer Struttura del superframe in PAN beacon-enable Struttura del pacchetto di beacon Il campo superframe specication Struttura del pacchetto di comando Struttura del pacchetto di dati Struttura del pacchetto di acknowledgement Trasferimento dati nodo tra nodo Device e nodo Coordinator Trasferimento dati nodo tra nodo Coordinator e nodo Device Diagramma di usso del meccanismo CSMA-CA Diagramma di sequenza per l'allocazione di un GTS Diagramma di sequenza della deallocazione di un GTS Frammentazione di GTS in seguito a deallocazione Rappresentazione NS-2 del nodo wireless Schema di gestione eventi RTNS Rappresentazione modulare del nodo RTNS Diagramma di sequenza per l'inizializzazione di una nuova PAN Diagramma delle classi che costituiscono il database GTS Diagramma di classi degli oggetti IPApp e IPAgent

8 ELENCO DELLE FIGURE viii 5.2 Diagramma di classi degli oggetti coordagent e coordapp Diagramma di sequenza della procedura di invio di un report Diagramma di sequenza della procedura di ricezione di un report scenario della simulazione Distribuzione scenario taxiway Ecienza time-based vs. event-based Latenza time-based vs. event-based Confronto dell'ecienza del sistema con traco best-eort e real-time Eetto del task di carico sulla latenza di elaborazione e invio del pacchetto Scheduling FCFS e FP nello scenario taxiway Distribuzione scenario market [Confronto GTS e CSMA-CA scenario market (protocol timeout) Confronto GTS e CSMA-CA (packet size)

9 Elenco delle tabelle 2.1 PHY Bitrates Tabella dei possibili comandi del MAC tab: Formato del pacchetto di comando per richiesta/rilacio GTS campo GTS Characteristics del pacchetto di comando per richiesta/rilacio GTS campo GTS Field del pacchetto beacon campo GTS Specication del pacchetto di sottocampo GTS Field campo GTS List del pacchetto di sottocampo GTS Specication 28

10 Prefazione Il presente lavoro di tesi ha come obiettivo quello di mostrare quali siano i fattori che incidono sulla Qualità del Servizio (QoS) nelle reti wireless di sensori quando vengono utilizzate per supportare applicazioni soft real-time. La QoS locale al nodo - intesa come possibilità del sistema operativo real-time di privilegiare l'esecuzione di processi critici rispetto ad altri - viene spesso trascurata se confrontata alla QoS fornita a livello di rete: tuttavia entrambi i fattori devono essere considerati nell'analisi delle prestazioni del sistema. L'analisi di entrambi gli aspetti è stata eettuata mediante l'utilizzo del simulatore RTNS e tramite l'implementazione di una applicazione realtime. Nel capitolo 1 vengono introdotti il mondo delle reti wireless di sensori e dei sistemi soft real-time. Nel capitolo 2 viene illustrato il protocollo IEEE , il più usato nelle reti wireless di sensori, con particolare attenzione al meccanismo del GTS necessario al supporto del traco real-time. Nel capitolo 3 viene mostrato l'ambiente di simulazione utilizzato durante il lavoro, a partire dal simulatore NS-2 e RTSim no all'integrazione di questi al ne di ottenere un ambiente simulativo completo - RTNS - in grado di simulare sia il comportamento di rete che quello locale al nodo. Nel capitolo 4 viene introdotto il package di supporto a WPAN nativo in NS-2 per la simulazione del protocollo IEEE Viene, altresì, descritta l'estensione del package stesso con il meccanismo di GTS ( Guaranteed Time Slot) per supportare traco real-time. Nel capitolo 5 viene descritta l'implementazione di una applicazione di tracking distribuito basata sulle reti wireless di sensori e vengono mostrati i risultati di QoS ottenuti al variare di alcune metriche globali. Nel capitolo 6 sono descritte le conclusioni di questo lavoro di tesi.

11 Capitolo 1 Introduzione alle reti wireless di sensori 1.1 Introduzione alle reti wireless di sensori La forma più comune di elaborazione dell'informazione prevede che l'uomo sia al centro del sistema di elaborazione e utilizzi, in modo attivo, il sistema di calcolo: di solito quest'ultimo è un dispositivo general purpose come un laptop o un computer desktop, ma anche un dispositivo portabile come un PDA o un cellulare. Se le informazioni elaborate servono ad attuare una forma di controllo sull'ambiente esterno (ad esempio un'applicazione di ucio), è l'uomo ad attuare tale controllo in modo attivo: pertanto, in questo caso, l'elaborazione dell'informazione e il controllo sull'ambiente sono indirettamente legate. In altre situazioni può essere richiesta l'integrazione completa tra l'elaborazione delle informazioni e il controllo dell'ambiente, senza basarsi su un'interazione umana attiva: questo è il caso dei sistemi embedded. In questi sistemi la computazione delle informazioni e il controllo avvengono indipendentemente dall'ausilio di un'entità umana. Il progresso tecnologico ha portato ad una diusione massiccia dei sistemi embedded nella vita quotidiana: il 98% dell'intelligenza articiale è di tipo embedded, basti pensare ai sistemi elettronici presenti negli elettrodomestici, nelle automobili, nelle abitazioni, negli uci, ecc. Circa 4 miliardi di processori embedded sono stati venduti l'ultimo anno con un fatturato di

12 Capitolo 1. Introduzione alle reti wireless di sensori 2 60 miliardi di euro e una crescita annua del 14%. Si stima che nel 2010 i processori embedded venduti saranno 16 miliardi e nel 2020 si raggiungerà la soglia di 40 miliardi di unità (fonte Artemis). Nei prossimi 5 anni è prevista una crescita della diusione dei dispositivi embedded soprattuto nei settori dell'automotive(36%), automazione industriale (22%), telecomunicazioni (37%), elettronica di consumo(44%) e attrezzature medico-sanitarie (33%). Il motivo di questa crescita è dovuto al valore aggiunto in termini di innovazione tecnologica che il dispositivo embedded garantisce al prodotto nale; basti pensare che oggigiorno un telefono cellulare presenta molte più funzionalità rispetto a quelle di un laptop prodotto alcuni anni prima. Per la realizzazione di un ambiente intelligente, in cui i dispositivi embedded sono in grado di manipolare le informazioni che raccolgono e condividerle con altri dispositivi, è necessario disporre di un ulteriore componente: la comunicazione tra i dispositivi. La comunicazione può essere realizzata mediante la realizzazione di una rete cablata (wired), nella quale transitano i dati che i dispositivi intendono trasmettere. Tuttavia, a seconda del tipo di applicazione, l'utilizzo di una soluzione wired risulta impraticabile. Un aspetto non trascurabile è che essa presenta un costo non irrilevante, e nel caso i dispositivi da collegare siano numerosi costituisce un problema alla realizzazione della rete stessa. Inoltre essa limita la mobilità dei dispositivi e può impedire al trasduttore o all'attuatore di essere collocati in prossimità del fenomeno da monitorare. Negli ultimi anni si sta diondendo una nuova classe di reti chiamata Rete di Sensori Wireless (WSN). Queste reti consistono in una serie di nodi individuali in grado in interagire con l'ambiente: essi possono monitorare o controllare i parametri sici che interessano. Tuttavia tali nodi hanno la necessità di collaborare per assolvere pienamente ai propri scopi, in quanto generalmente un singolo nodo non è in grado di svolgere completamente l'attività di elaborazione e controllo: pertanto la collaborazione tra i nodi avviene mediante una rete wireless. In particolare un singolo nodo può espletare alcune funzionalità di elaborazione di base, oltre a quelle relative alla comunicazione wireless, e la possibilità di monitorare l'ambiente oppure di agire sull'ambiente tramite il controllo, come descritto ad esempio in [10]. Le reti wireless di reti sono molto potenti in quanto consentono una grande essibilità di utilizzo in varie tipologie di applicazioni. Nella maggior parte di queste, si può individuare una chiara dierenza tra i nodi sorgenti dei

13 Capitolo 1. Introduzione alle reti wireless di sensori 3 dati, ossia i nodi che eettuano le operazioni di monitoraggio dell'ambiente, e i nodi chiamati sink ai quali i dati vanno trasmessi e nei quali avviene l'elaborazione degli stessi. I nodi sink possono essere parte della rete wireless oppure esterni a quest'ultima. Il tipo di interazione tra i nodi sorgenti e il sink dipende dal tipo di applicazioni che si intende realizzare. Per esempio nel presente lavoro di tesi sono state considerate applicazioni relative a: Rilevazione di un evento : in questo caso i nodi sorgente trasmettono i messaggi contenenti la misurazione eettuata solo quando si è vericato un particolare evento. L'evento può essere rilevato da un singolo nodo oppure, caso più complicato, richiedere la collaborazione di nodi vicini o remoti. Il nodo sink, una volta ricevute le informazioni, provvede alla loro elaborazione. Tracking : la sorgente di un evento può essere mobile e pertanto la WSN può essere utilizzata per inviare messaggi che indichino la posizione della sorgente al nodo sink. Tipicamente per fare ciò i nodi sensori devono cooperare prima che l'informazione venga inviata al nodo sink oppure può essere prevista una logica di elaborazione sul sink per correlare tra loro le informazioni di un singolo evento. Questa cooperazione tra i sensori può avvenire sia nello spazio (invio di informazioni solo dai nodi che si trovano in una certa area) oppure nel tempo (inviare informazioni periodicamente). Nei due esempi appena descritti è molto importante il concetto di posizionamento dei sensori. Questo può essere ben pianicato e ssato dai requisiti applicativi (quando è possibile il posizionamento diretto) oppure casuale (quando ad esempio un gran numero di nodi vengono lasciati cadere in una regione da un aereo). Inoltre quando i nodi sensori sono mobili possono essere congurati in modo da ottimizzare autonomamente il proprio posizionamento nella rete. Un altro aspetto molto importante riguardante le reti wireless è quello relativo alla Qualità del Servizio(QoS). I tradizionali requisiti di qualità del servizio, come garanzie sul ritardo massimo o sulla banda minima, sono irrilevanti quando l'applicazione è tollerante alla latenza o la quantità di dati trasmessi è molto piccola. Infatti, in alcuni casi l'applicazione potrebbe richiedere l'invio occasionale di pacchetti, in altri possono essere richiesti maggiori requisiti di adabilità. Il ritardo infatti è molto importante quan-

14 Capitolo 1. Introduzione alle reti wireless di sensori 4 do gli attuatori devono essere controllati in real-time dalla rete di sensori: in questo caso non è importante tanto il numero di pacchetti inviati quanto la quantità e la qualità delle informazioni utili, relative all'evento o all'ambiente osservato, che il nodo sink è in grado di estrarre dai pacchetti ricevuti. La qualità del servizio, intesa come garanzia di rispetto di vincoli su ritardo, jitter o perdita di pacchetti, consente di utilizzare la WSN in applicazioni di tipo soft real-time che tollerano ritardi dell'ordine dei millisecondi. Non è adatta invece per applicazioni di tipo hard real-time, che a causa degli stringenti vincoli temporali sono tipicamente realizzate su reti cablate (CAN bus ad esempio) e in cui vengono utilizzati solo i livelli sico, data-link e applicazione, evitando la trasmissione multi-hop. A più alto livello, un secondo modo di intendere la qualità del servizio è quello direttamente osservabile dall'utente, come la qualità percepita durante una comunicazione voce o una trasmissione video. Un parametro di QoS in questa seconda accezione potrebbe essere la probabilità di rivelare o noticare un evento: ad esempio, un messaggio di allarme non noticato ad una stazione di sorveglianza potrebbe essere considerata una mancanza al pari a una deadline miss in un sistema hard real-time. 1.2 Cenni sui sistemi real-time Nel linguaggio comune, con il termine di sistema real-time si intende un sistema che reagisce ad un evento entro un tempo limitato. Ad esempio un sito che fornisce i risultato delle partite di calcio è real-time se il risultato è aggiornato non appena viene segnato un goal. In tal caso l'istante temporale che passa della realizzazione del goal all'aggiornamento del risultato non ha un signicato preciso e solitamente è dell'ordine di pochi secondi. Quando viene utilizzato un computer per controllare un dispositivo sico (come un robot in movimento), il tempo necessario al processore per reagire ad un evento dell'ambiente può dipendere signicativamente dalla performance complessiva del sistema. Nel caso del robot, una manovra correttiva eettuata tardivamente può causare seri danni al sistema e/o all'ambiente circostante. Pertanto un sistema real-time può essere denito più precisamente come un sistema in cui le singole elaborazioni devono essere eseguite entro limiti temporali predeniti [3]. Pertanto la performance nale del sistema non soltanto dipende dalla correttezza funzionale dei risultati forniti

15 Capitolo 1. Introduzione alle reti wireless di sensori 5 dalla computazione, ma anche dal tempo entro il quale tali risultati sono prodotti. I sistemi real-time vengono spesso modellati come un set di Task concorrenti: ogni task rappresenta una attività computazionale che deve essere eseguita entro un set di vincoli temporali. Se la stessa attività computazionale deve essere eseguita numerose volte su dati diversi, un task può essere caratterizzato da una serie di istanze multiple dette jobs. I parametri temporali più signicativi che deniscono una attività computazionale real-time sono: Release Time r i : istante temporale nel quale un task diventa pronto per l'esecuzione; Start Time S i : istante in cui un task inizia la propria esecuzione per la prima volta; Computation Time C i : tempo necessario al processore per eseguire il task senza interruzioni; Finish Time f i : istante temporale nel quale il task termina la propria esecuzione; Response Time R i : tempo che intercorre tra il Release Time del task e il Finish Time (R i = f i r i ); Absolute Deadline d i : istante temporale prima del quale il task deve essere completato; Relative Deadline D i : tempo che intercorre tra Absolute Deadline e Release Time, prima del quale il task dovrebbe essere completato (D i = d i r i ). Questi parametri sono schematicamente illustrati in gura 1.1: Figura 1.1: Parametri temporali tipici di un task real-time

16 Capitolo 1. Introduzione alle reti wireless di sensori 6 In base al tipo di requisiti temporali che sono deniti per una elaborazione, i sistemi real-time sono raggruppati in 4 categorie di base: 1. hard real-time: quando tutti i job di un task devono essere eseguiti entro la propria deadline ( j f i,j d i,j ), altrimenti può avvenire un fallimento critico del sistema. 2. firm real-time: quando solo un numero limitato di job può essere soggetto a deadline miss. 3. soft real-time: quando il valore del risultato prodotto dal sistema degrada progressivamente con il suo tempo di risposta. Per alcune applicazioni non esiste una deadline associata al job. Infatti l'obbiettivo del sistema è quello di minimizzare il tempo di risposta. L'associazione di una deadline soft ad ogni job indica che quel job dovrebbe essere completato entro la deadline per ottenere la miglior performance del sistema. Il vericarsi di un evento di deadline miss in questo caso non comporta eetti disastrosi come per i sistemi hard real-time: il sistema prosegue nel suo funzionamento ma con un livello di performance più basso. 4. non real-time: se non esiste alcun vincolo temporale sul risultato della computazione ma solo la correttezza della stessa. Una attività computazionale può essere attivata da un timer a istanti temporali predeniti (time-triggered) oppure in seguito al vericarsi di un particolare evento (event-triggered). Quando le attivazioni di un job sono separate da un intervallo di tempo ssato, il task è detto periodico e l'istante di attivazione tra un job e il successivo è detto periodo. Nel caso in cui le attivazioni dei job non siano regolari, il task è invece detto aperiodico; se esiste un minimo tempo di inter-arrivo tra due attivazioni consecutive del job, il task è detto sporadico. Il carico di lavoro di un processore in un sistema general purpose dipende dalla quantità di calcolo computazionale richiesta nell'unità di tempo. In un sistema real-time dipende anche dai vincoli temporali di ciascun task. Infatti lo stesso insieme di task, con una data richiesta computazionale e un pattern di arrivo, può causare un carico maggiore se vengono ridotte le deadline dei singoli task. Per misurare il carico di un sistema real-time è stato introdotto il concetto di domanda del processore, denita su un intervallo temporale e pari alla somma dei

17 Capitolo 1. Introduzione alle reti wireless di sensori 7 tempi di computazione dei task aventi istante di attivazione e deadline interni all'intervallo considerato. Nel caso di task periodici, il carico prodotto da ogni task è chiamato utilizzazione (U i ) e viene calcolato come il rapporto tra il tempo richiesto per la computazione (C i ) e il periodo del task (T i ): essa rappresenta la banda computazionale richiesta dal task al processore. Quando la richiesta computazionale da parte dei task supera il tempo di elaborazione disponibile sulla CPU, il sistema entra in uno stato di sovraccarico (overload): le attività computazionali iniziano ad accumularsi nella coda del sistema e il tempo di risposta del task cresce indenitivamente con il crescere della coda. La condizione di overload implica il vericarsi di una o più deadline miss. Per un set di task periodici, la condizione di sovraccarico viene realizzata quando U p = n i=1 U i > 1: a seconda del tipo di scheduler utilizzato puà accadere che un task sia soggetto a deadline miss anche se non si verica la situazione di sovraccarico. Negli ultimi anni i sistemi real-time hanno iniziato ad interessare nuovi domini applicativi, come sistemi multimediali, apparati di monitoraggio, reti di telecomunicazioni, cioè applicazioni time-sensitive: questi sistemi sono detti soft real-time in quanto i task dell'applicazione hanno dei requisiti temporali meno stringenti rispetto ai sistemi hard real-time. In questi sistemi il degrado della prestazione a causa di un deadline miss viene valutato attraverso un parametro di qualità del servizio (QoS) scelto in base all'applicazione. Un esempio può essere un'applicazione di tracking video nella quale, al ne di aumentare la risposta del sistema, la ricerca dell'oggetto in movimento avviene inizialmente in una piccola porzione della scena invece che sull'intero campo di visualizzazione. Se l'oggetto non viene rilevato, la ricerca viene eettuata nuovamente considerando una porzione di scena maggiore, no ad eettuare uno scanning dell'intera area. Se il sistema è stato progettato bene, la probabilità di rilevare l'oggetto nella posizione predetta è molto alta e la ricerca avviene molto velocemente con un basso carico computazionale: in caso contrario il tempo necessario e il carico computazionale saranno maggiori, compatibilmente con la dimensione della scena analizzata.

18 1.3 Motivazioni al lavoro di tesi Le motivazioni che hanno portato al presente lavoro di tesi sono molteplici e sostanzialmente legate alle straordinarie potenzialità fornite dalle reti wireless di sensori e ai domini applicativi che possono essere esplorati tramite questa tecnologia. Naturalmente, prima di realizzare una nuova applicazione, la necessità di realizzare un modello simulativo più fedele possibile alla realtà limita i rischi di insuccesso e permette di studiare il sistema in tutte le sue potenzialità, anche in situazioni dicilmente realizzabili nel caso reale. Nasce così la necessità di disporre di un software di simulazione completo in grado di considerare, non soltanto gli aspetti relativi alla trasmissione di rete, ma anche quelli riguardanti il comportamento del sistema operativo. L'uso del simulatore RTNS ha parzialmente risolto questa necessità: è necessario però integrare quest'ultimo con l'implementazione del meccanismo di supporto al traco real-time previsto dal protocollo di trasmissione usato nelle reti di wireless di sensori. Tramite l'implementazione del meccanismo di trasmissione mediante GTS è possibile gestire un traco di tipo soft realtime allocando banda: questo è appunto uno degli obiettivi del lavoro di tesi. L'altro obbiettivo riguarda la realizzazione di una applicazione che dimostri la validità del meccanismo implementato e serva per dimostrare che in applicazioni soft real-time distribuite basate sulla comunicazione di rete, come nel caso delle reti wireless di sensori, non è suciente considerare solo la qualità del servizio a livello di rete: occorre considerare anche il comportamento del sistema operativo. I miglioramenti in campo hardware consentono oggigiorno di sfruttare potenzialità computazionali maggiori anche per i dispositivo come le board di sensori che in origine erano demandate soltanto a rilevazioni di tipo ambientale. Pertanto, verrà simulata una applicazione di tracking distribuito basata sulla visione multinodo nella quale i nodi rivelatori eettuano una scansione di una porzione di scena e inviano report ad un nodo coordinatore nel quale è implementata una logica per il riconoscimento di un determinato evento. Le performance di tale applicazione verranno analizzate in un'ottica soft real-time per mostrare come il comportamento dell'applicazione dipenda complessivamente da entrambi i fattori descritti in precedenza. obiettivi

19 Capitolo 2 La suite di protocolli IEEE Introduzione Il protocollo MAC è stato standardizzato nell'ottobre del 2003 dall'institute of Electrical and Electronics Engineers (IEEE) [5]. Lo standard denisce lo strato sico e lo strato MAC (Medium Access Control) delle WPAN (Wireless Personal Area Network) a basso rate trasmissivo (LR - Low Rate). Non bisogna confondere IEEE con Zigbee [1], standard emergente per reti di sensori e applicationi wireless, che utilizza i layer IEEE e integra anche ulteriori servizi. IEEE è stato progettato per soddisfare i requisiti di applicazioni che richiedono un bitrate trasmissivo medio/basso, requisiti di ritardo (delay) non troppo stringenti, ma in particolar modo è stato curato l'aspetto di riduzione al minimo del consumo energetico. 2.2 Architettura di IEEE Al ne di semplicare lo standard, l'architettura di IEEE è stata suddivisa 3 blocchi che prendono il nome di strati (layers). Ogni strato fornisce servizi agli strati superiori, rendendoli disponibili mediante un interfaccia di accesso, e si occupa di una parte specica dello standard: l'architettura

20 Capitolo 2. La suite di protocolli IEEE segue il modello OSI come mostrato in gura 2.1 Un nodo LR-WPAN con- Figura 2.1: Lo stack di IEEE siste in un livello sico (PHY), che include il tranceiver a radio frequenza e che gestisce i meccanismi di accesso al mezzo, e un livello data-link (MAC), che permette l'accesso al canale sico e consente di eseguire correttamente tutti i tipi di trasferimento previsti. I livelli superiori nello stack consistono: un livello SSCS (Service Specic Convergence Sublayer) che, in base al servizio richiesto, esegue le azione necessarie per richiedere la trasmissione dati; un livello LLC (Logical Link Control) che denisce i tipi di servizio ottenibili per un trasferimento dati (ad esempio adabile, orientato alla connessione); un livello di rete (NETWORK) che si occupa della congurazione della rete, della gestione e invio dei messaggi di routing; un livello applicazione (APPLICATION) che rappresenta le funzionalità e i servizi ad alto livello che il device fornisce. La denizione degli ultimi 2 livelli non è trattata nello standard che si occupa solo di formalizzare il livello PHY e il livello MAC.

21 Capitolo 2. La suite di protocolli IEEE Il livello sico Il livello sico di IEEE (PHY) si occupa dell'impostazione della frequenza e successivamente della generazione della portante trasmissiva, del riconoscimento del segnale e della modulazione e codica dei dati. Rispetto alle tradizionali trasmissioni radio, lo stato sico di IEEE è stato progettato per ridurre al massimo il consumo energetico. In generale i servizi oerti dal livello sico sono i seguenti: Attivazione e deattivazione della radio, Rilevazione del livello energetico nel canale (Energy Detection), Indicazione della qualità del canale per rilevazione di collisioni, Clear Channel Assessment (CCA), Trasmissione e Ricezione dati dalla portante. I bitrate oerti dal PHY sono mostrati in tabella 2.1. Data Rate Symbol Rate Banda Canali Modulazione 20Kbps 20Ksyms MHz 1 BPSK 40Kbps 40Ksyms MHz 10 BPSK 250Kbps 62.5Ksyms GHz ISM 16 O-QPSK Tabella 2.1: PHY Bitrates In totale sono disponibili 27 canali, ma il livello MAC utilizza un canale per volta in quanto il protocollo implementato è monocanale. Pertanto il livello PHY denisce una interfaccia tra il livello MAC e il canale radio, attraverso il rmware e l'hardware del tranceiver radio. Concettualmente è prevista una entità di gestione, chiamata PLME ( Physical Layer Management Entity), che fornisce un'interfaccia alle funzionalità di gestione che possono essere richieste. PLME gestisce anche un database di informazioni e richieste che provengono dal livello superiore: questo database è chiamato PIB (PHY PAN Information Base). I servizi che il PHY fornisce sono accessibili tramite SAP (Service Access Point): il servizio di invio/ricezione dati (PD-SAP) e il servizio di gestione (PLME-SAP). Il pacchetti che provengono dal livello MAC (MPDU) vengono incapsulati insieme ad informazioni aggiuntive. Quando un MPDU arriva al livello sico viene indicato come PSDU

22 Capitolo 2. La suite di protocolli IEEE (Physical service data unit) e costituisce il payload del pacchetto PHY. Prima del PSDU viene inserito un header usato per la sincronizzazione del dispositivo di ricezione (SHR - Synchronizzation Header) e un header proprio dello strato sico (PHR - PHY Header) contentente la lunghezza del payload: il pacchetto completo prende il nome di PPDU (PHY Protocol Data Unit). La dimensione massima consentita per il PSDU è pari a 127 bytes. Figura 2.2: Organizzazione logica del livello PHY Il livello MAC Il livello MAC (Medium Access Controll) è responsabile della multiplazione del usso dati, del controllo dell'accesso al mezzo, del riconoscimento dei frame e della gestione dell'errore; inoltre gestisce tutti gli accessi al canale radio tramite richieste che vengono eettuate verso il livello PHY. In generale, i compiti del MAC risultano essere: Generazione dei network beacons, Sincronizzazione con i beacons, Supporto alla associazione/deassociazione alla PAN, Supporto alla sicurezza, Gestione e utilizzo del meccanismo CSMA-CA per l'accesso al mezzo, Mantenimento e gestione del meccanismo dei GTS. Le funzionalità che il MAC fornisce sono diversicate in base alla tipologia del nodo: esso fornisce una interfaccia tra il livello SSCS e il livello PHY.

23 Capitolo 2. La suite di protocolli IEEE Come per il PHY, anche il MAC include una entità di gestione chiamata MLME (MAC Layer Management Entity). Il database di informazioni gestito da MLME è chiamata MPIB (MAC PAN information base) e contiene informazioni relative all'indirizzo del Coordinator, indirizzo MAC assegnato al nodo, etc. Il livello MAC fornisce servizi attraverso due diversi SAP: il servizio dati, accessibile attraverso MCPS-SAP (MAC common part service access point), e il servizio di richiesta/gestione, accessibile attraverso MLME-SAP Tipologie di Nodi Lo standard distingue fondamentalmente due tipogie di nodi che possono partecipare alla realizzazione di una WPAN: 1. Full Function Device (FFD): il quale dispone delle piene funzionalità che il MAC ore e può operare nella rete come PAN Coordinator, ossia coordinatore dell'intera PAN, come semplice Coordinator, oppure come Device 2. Reduced Function Device (RFD): il quale può operare solo come Device. Il nodo Device è tipicamente un semplice nodo sensore che colleziona delle misurazioni nell'ambiente in cui è collocato e invia il risultato di tali misurazioni al nodo Coordinator o al nodo PAN Coordinator nel quale può essere anche presente una fase di elaborazione delle informazioni ottenute; sia FFD che RFD possono assumere il ruolo di Device. Il nodo Coordinator è il nodo responsabile della gestione della rete/ sottorete WPAN e svolge funzioni molto più complesse rispetto al semplice Device. Lo standard prevede due diverse modalità di accesso al mezzo: beacon-enabled : è basata su una struttura a superframe. Il superframe è delimitato da network beacon, e si ripete periodicamente con la stessa lunghezza. Tramite il superframe i nodi possono sincronizzarsi con il Coordinator: in questo modo si è in grado di disciplinare la comunicazione tra i vari nodi della rete. Inoltre ogni superframe è diviso in una parte attiva, eettivamente utilizzata per la comunicazione, seguita da una parte non attiva durante la quale i dispositivi entrano in uno stato

24 Capitolo 2. La suite di protocolli IEEE a basso consumo energetico. La struttura del superframe e le modalità di trasmissione verranno illustrate meglio nel paragra successivi. non beacon-enable : non prevede l'uso di un superframe di sincronizzazione della comunicazione:pertanto l'accesso al canale avviene in modo completamente asincrono. Entrambe le modalità prevedono che i Device si associno al nodo Coordinator tramite un'apposita procedura. I compiti che deve svolgere un nodo Coordinator all'interno della PAN risultano essere: Mantenere aggiornata la lista dei device associati. Il protocollo prevede infatti che i Device facciano richiesta esplicita di associazione/deassociazione al Coordinator utilizzando speciali pacchetti di segnalazione; Allocare un indirizzo su 16-bit ai Device che risultano associati. Ogni nodo dispone di un indirizzo a 64-bit ma quando il nodo eettua una richiesta di associazione al Coordinator può richiedere un indirizzo a 16-bit che utilizzerà per tutte le comunicazioni successive; Inviare periodicamente il frame di beacon se in beacon mode; Scambiare pacchetti dati con il Device o con altri Coordiator. 2.3 Topologie di rete Una LR-WPAN può essere congurata secondo due topologie: la topologia a stella e la topologia peer-to-peer. La scelta della topologia dipende sostanzialmente dal tipo di applicazione che si intende realizzare. Entrambe sono mostrate in gura 2.3. Nella topologia a stella viene stabilita una comunicazione tra il Device e un singolo nodo PAN Coordinator. Infatti un nodo FFD, dopo essere stato attivato, può inizializzare una rete e diventare PAN Coordinator. Le reti a stella operano indipendentemente le une dalle altre e questo è reso possibile dall'utilizzo di un unico identicatore (PAN ID) per ogni rete all'interno del raggio d'azione del segnale radio. Dopo la scelta del PAN ID, il Coodinator permette ai vari nodi, sia FFD che RFD di unirsi alla rete e partecipare alla comunicazione. Tutti i Device che operano in una rete a stella devono

25 Capitolo 2. La suite di protocolli IEEE disporre di un indirizzo a 64-bit univoco che viene utilizzato per lo scambio di messaggio con il Coordinator: in seguito alla procedura di associazione, il Coordinator può assegnare al Device un indirizzo a 16-bit che sostituisce il precedente a 64-bit. Anche nella topologia peer-to-peer è prevista la presenza del PAN Coordinator ma in questo caso tutti i Device possono comunicare direttamente tra loro ntanto che risiedono nel range d'azione del segnale radio. La procedura di elezione del PAN Coordinator è semplice: il primo nodo FFD che eettua l'accesso al canale di sico diviene appunto PAN Coordinator. Un esempio di utilizzo della topologia peer-to-peer è il cluster-tree. La rete cluster-tree è un particolare tipologia di rete peer-to-peer nella quale la maggior parte dei nodi sono FFD e possono comunicare direttamente tra loro. Un solo nodo assume il ruolo di PAN Coodinator per l'intero albero di connessione. I nodi RFD possono connettersi ai vari FFD in qualità di end point della rete (foglie). Estendendo la topologia peer-to-peer è inoltre possibile costruire reti più complesse come reti mesh o ad-hoc. (a) (b) Figura 2.3: Topologia a Stella e Peer-to-Peer 2.4 Struttura del superframe Lo standard prevede l'uso di una struttura a superframe che è denita dal nodo PAN Coordinator. Il superframe è delimitato dalla presenza di pacchetti detti beacon ed è suddiviso in 16 slot temporali. Tutti i superframe hanno la stessa lunghezza e possono essere costituiti da un periodo attivo e un periodo non attivo durante il quale il PAN Coordinator e i Device

26 Capitolo 2. La suite di protocolli IEEE possono spegnere la radio ed entrare in una fase di risparmio energetico: il PAN Coordinator resta acceso per tutta la durata periodo attivo. Il periodo attivo risulta ulteriormente suddiviso in un periodo di accesso a contesa (CAP - Contention Access Period) seguito da un periodo di accesso senza contesa (CFP - Contention Free Period) costituito da un numero variabile di GTS (Guaranteed Time Slots) continui, descritti nella sezione I Device sono attivi della fase di trasmissione o ricezione tramite GTS solo se hanno una GTS allocata oppure nella fase CAP solo se devono trasmettere o ricevere dati dal Coordinator. La lunghezza del periodo attivo e del periodo inattivo, come anche la durata del singolo slot temporale sono completamente congurabili tramite i parametri BO (Beacon Order), SO (Superframe Order), come illustrato in gura 2.4. Ogni device che intende Figura 2.4: Struttura del superframe in PAN beacon-enable comunicare con il PAN Coodinator durante la fase CAP, compete con gli altri device all'accesso al mezzo tramite il meccanismo CSMA-CA e deve garantire che tutta la transazione sia conclusa prima della ricezione del prossimo pacchetto di beacon: solo i pacchetti di acknowledgement vengono trasmessi immediatamente. Il CAP deve iniziare immediatamente dopo la trasmissione del beacon e deve terminare immediatamente prima dell'inizio del periodo CFP. Lo standard denisce una durata minima della fase CAP, mincaplength, pari a 440 simboli. Per supportare applicazioni real-time che necessitano di allocazione di banda e requisiti sul delay, una porzione del superframe può essere dedicata

27 Capitolo 2. La suite di protocolli IEEE all'accesso senza contesa (CFP - Contention Free Period) nella quale il PAN Coordinator alloca, ai singoli Device richiedenti, slot temporali all'interno del periodo attivo. Ogni porzione temporale allocata viene chiamata GTS e può comprendere in numero variabile di slot. Lo standard prevede un numero massimo di GTS allocabili pari a 7: pertanto deve sempre valere la relazione: ngt S SD nslot i mincap Length (2.1) i=1 dove nslot i rappresenta in numero di slot della i-esima GTS, ngts è il numero di GTS complessive allocate dal Coordinator e la durata di ciascuno slot è pari a abaseslotduration 2 SO. I Device che utilizzano i GTS devono garantire che tutte le trasmissioni terminino prima dell'inizio della prossima GTS o entro la ne del CFP. Durante il CFP non viene utilizzato il meccanismo CSMA-CA ma la trasmissione avviene immediatamente quando un pacchetto è disponibile. Questo meccanismo sarà ampiamente trattato nel paragrafo Tipologie di pacchetto Il protocollo denisce la struttura dei pacchetti in modo tale da mantenere al minimo la complessità, ma al tempo stesso in modo che siano sucientemente robusti in caso di trasmissione in un canale aetto da rumore. Il pacchetto che proviene dai livelli superiori viene incapsulato nei livelli inferiori tramite l'inserimento di intestazioni (header) contenenti informazioni aggiuntive per la gestione della trasmissione del pacchetto. Lo standard prevede 4 tipologie di pacchetto: Il pacchetto beacon utilizzato dal nodo Coordinator per trasmettere i beacon, Il pacchetto command utilizzato per eettuare richieste di servizio, Il pacchetto data utilizzato per tutti i trasferimenti di dati, Il pacchetto acknowledgement usato per confermare la corretta ricezione di un pacchetto contente dati o comandi.

28 Capitolo 2. La suite di protocolli IEEE Il payload di questi pacchetti (MSDU) viene incapsulato dal MAC: prima del payload viene inserito un header (MHR - MAC Header) contenente varie informazioni tra le quali l'indirizzo del nodo mittente e quello del nodo destinatario; dopo il payload viene inserito un footer (MHF - MAC Footer) contenente una sequenza di check. Il pacchetto MAC completo di header, payload e footer viene indicato come (MPDU ) e inviato al livello PHY Il pacchetto beacon Il pacchetto beacon (in gura 2.5) viene generato da un FFD quando la PAN è in modalità beacon-enable, per denire la struttura del superframe e consentire la sincronizzazione dei nodi, oppure quando in modalità non beacon-enable per permettere al Device di localizzare la rete (network discovery). Un FFD può iniziare la trasmissione del pacchetto di beacon sia per diventare PAN Coordinator di una nuova PAN oppure, in qualità di Device associato ad un altro Coordinator, per indicare la propria presenza nella rete. Le informazioni contenute nel pacchetto di beacon permettono di identicare una PAN attiva, e di riconoscere il PAN Coordinator che la gestisce: queste informazioni sono indispensabili ai Device per richiedere l'associazione alla rete. La trasmissione del pacchetto di beacon deve avere priorità maggiore rispetto a tutte le operazioni di trasmissione e ricezione. La mancata ricezione del pacchetto di beacon infatti comporta notevoli problemi, il più importante dei quali è la perdita di sincronizzazione da parte dei nodi Device. In questo caso il campo più importante del pacchetto di beacon è sicuramente quello relativo alla struttura del superframe, detto Superframe Specication, illustrato in gura 2.6. Il campo Beacon Order (BO) indica l'intervallo di trasmissione del beacon e conseguentemente la durata del superframe. Il beacon interval (BI) viene infatti calcolato come: BI = abasesuperframeduration 2 BO Tutti i pacchetti beacon devono essere trasmessi all'inizio di ogni superframe. La costante abasesuperframeduration è denita dal protocollo, ed è pari a 960 simboli, lunghezza che costituisce il superframe quando BO e pari a 0. Inoltre se 0 BO 14, la PAN è in modalità beacon-enable, poichè

29 Capitolo 2. La suite di protocolli IEEE Figura 2.5: Struttura del pacchetto di beacon Figura 2.6: Il campo superframe specication è prevista la trasmissione dei beacon. Se BO = 15 il beacon non viene trasmesso a meno che non sia richiesto tramite la ricezione di un apposito comando. Il campo Superframe Order indica la durata del periodo attivo del superframe, detto Superframe Duration. Se 0 SO BO 14, la superframe duration (SD) viene calcolato come: SD = abasesuperframeduration 2 SO Se SO = 15, nessun periodo attivo segue la ricezione del beacon. Il campo Final CAP specica l'ultimo slot utilizzabile all'interno della parte attiva del superframe, per l'accesso in modalità a contesa (CAP). Questo campo deve avere un valore maggiore a quello della costante amin- CAPLength, denita dal protocollo e pari a 440 simboli Il pacchetto command Il pacchetto command viene generato dal MAC ogni qualvolta un Device intenda eettuare delle richieste al nodo coordinator. I tipi di comandi che un FFD o un RFD può trasmettere/ricevere sono riassunti in tabella 2.2 Ad ogni comando è associato un id univoco che pertanto viene utilizzato

30 Capitolo 2. La suite di protocolli IEEE Comando FFD RFD Tx Rx Tx Rx Richiesta associatione x x x Risposta associazione x x x Notica disassociazione x x x x Richiesta dati x x x Notica conitto su PAN ID x x x Notica di nodo orfano x x x Richiesta beacon x x Allineamento con Coordinator x x x Richiesta GTS x x Tabella 2.2: Tabella dei possibili comandi del MAC per riconoscere il tipo di comando e interpretare correttamente i parametri inseriti all'interno del pacchetto. La struttura del pacchetto di comando è mostrata in gura 2.7 Figura 2.7: Struttura del pacchetto di comando Il pacchetto data Il pacchetto dati viene creato dal MAC ogni volta che l'applicazione o i livelli dello strato superiore eettuano una richiesta di invio dati. La struttura del pacchetto dati è mostrata in gura Il pacchetto acknowledgment Il pacchetto di acknowledgement viene creato dal MAC ogni volta che è richiesta una conferma riguardo la corretta ricezione di un pacchetto dati o di un pacchetto di comando, mentre non viene trasmesso se il device non è in grado di gestire il pacchetto ricevuto o il comando richiesto. Il nodo che ha prodotto il messaggio originario attende la conferma di ricezione per un

31 Capitolo 2. La suite di protocolli IEEE Figura 2.8: Struttura del pacchetto di dati certo periodo di tempo dopo il quale, assumendo che la trasmissione abbia avuto esito negativo, può inviare nuovamente il pacchetto dati o comando. Il numero di ritrasmissioni consecutive è limitato. Se il pacchetto di acknowledgement viene ricevuto, il nodo assume che la trasmissione abbia avuto esito positivo. La struttura del pacchetto di acknowledgement è mostrata in gura 2.9. Figura 2.9: Struttura del pacchetto di acknowledgement 2.6 Tipologie di traco e trasferimento dati La modalità di trasferimento dati sono diversicate in base al tipo di nodo che intende iniziare la comunicazione. Se un nodo Device intende trasmettere dati al nodo Coordinator di una beacon-enable PAN, per prima cosa attende di ricevere il pacchetto di beacon. Una volta che questo è stato ricevuto, il Device utilizza le informazioni contenute per sincronizzarsi con il superframe. Quando inizia la fase di CAP, mediante il meccanismo slotted CSMA-CA 2.6.1, il Device può inviare i dati al nodo Coordinator. Se invece la PAN è in modalità nonbeacon-

32 Capitolo 2. La suite di protocolli IEEE enable, il Device invia i pacchetti di dati utilizzando il meccanismo unslotted CSMA-CA. Figura 2.10: Trasferimento dati nodo tra nodo Device e nodo Coordinator in beacon-enable PAN (1) e non beacon-enable PAN (2) Quando il Coordinator intende trasmettere dati a un Device in una beacon-enable PAN, inserisce in un campo del pacchetto di beacon l'indirizzo del Device destinatario ad indicare la presenza di un pacchetto pendente. Alla ricezione del beacon, il Device può richiedere l'invio dei dati al Coordinator trasmettendo a quest'ultimo un apposito pacchetto di comando MAC. Quando il coordinator riceve il comando, notica la corretta ricezione mediante un pacchetto di acknowledgment e in seguito trasmette il pacchetto pendente. Inne il Device può confermare la corretta ricezione del pacchetto dati inviando a sua volta un pacchetto di acknowledgement. Le fasi di invio dei pacchetti dati e dei comandi avvengono utilizzando il meccanismo CSMA-CA. Se invece la PAN è in modalità non beacon-enable, il Coordinator memorizza i dati temporaneamente e attende una richiesta esplicita da parte del Device, che avviene con la ricezione di un apposito comando MAC. Alla ricezione del comando di richiesta dati, il Coordinator invia un pacchetto di acknowledgment e in seguito i dati richiesti. Quando il Device riceve il pacchetto dati, invia un messaggio di acknowledgement per noticare la corretta ricezione. Le fasi di invio dei pacchetti dati e dei comandi avvengono mediante il meccanismo unslotted CSMA-CA. Tutte le trasmissioni di pacchetti dati avvengono mediante l'invocazione della primitiva MCPS-DATA.request alla quale è possibile specicare la modalità di trasmissione tramite un parametro chiamato TxOptions.

33 Capitolo 2. La suite di protocolli IEEE Figura 2.11: Trasferimento dati nodo tra nodo Coordinator e nodo Device in beacon-enable PAN (1) e non beacon-enable PAN (2) Traco non real-time: CAP Descrizione Generale Come illustrato precedentemente, nella fase di CAP un nodo Device può eettuare una trasmissione di pacchetti dati o comandi tramite il meccanismo CSMA-CA. CSMA-CA viene utilizzato per evitare il fenomeno delle collisioni ( e conseguentemente le ritrasmissioni) quando la trasmissione da parte di vari dispositivi avviene su un mezzo condiviso. Nel momento in cui un nodo vuole tentare una trasmissione, ascolta il canale (Listen-before- Transmit). Se il canale è occupato la stazione attiva un timer di durata casuale (detto timer di backo ) il quale viene decrementato solo durante i periodi di inattività del canale. Allo scadere del timer, la stazione eettua un altro tentativo di invio del pacchetto L'algoritmo CSMA-CA La trasmissione dati mediante l'algoritmo CSMA-CA viene attuata per tutti i pacchetti dati o comando che vengono trasmessi durante la fase di CAP. Il protocollo IEEE prevede due versioni di CSMA-CA: la prima detta slotted CSMA-CA viene utilizzata se il nodo appartiene a una beacon-enable PAN; la seconda detta unslotted CSMA-CA viene utilizzata se il nodo appartiene a una non beacon-enable PAN o se non è in grado di rilevare la presenza del beacon. Nella modalità slotted CSMA-CA, i periodi di backo di ogni device sono allineati con la durata degli slot: in questo

34 Capitolo 2. La suite di protocolli IEEE modo viene mantenuta una sincronizzazione tra tutti i periodi di backo dei device in una beacon-enable PAN. In unslotted CSMA-CA, invece, non esiste alcuna relazione temporale tra i periodi di backo dei vari nodi. Ogni device mantiene tre variabili per ogni trasmissione che vuole eettuare tramite CSMA-CA: NB - Numero di Backo : indica il numero di tentativi eettuati per la trasmissione corrente; CW - Finestra di contesa : indica il numero di tentativi di accesso al canale con esito positivo che è necessario eettuare prima di trasmettere eettivamente i dati; BE - Esponente di backo : utilizzato per calcolare quanti periodi di backo il device deve attendere prima di tentare l'accesso al canale. Gli step dell'algoritmo, sia per la modalità slotted che unslotted, sono riassunti in gura 2.12 Il protocollo denisce un numero massimo di tentativi di accesso al canale detto macmaxcsmabackos che è posto pari a 4, prima di dichiarare fallito l'accesso al canale. Questo algoritmo di trasmissione è intrinsecamente best-eort: non esistono garanzie che un pacchetto possa essere eettivamente trasmesso. Mediamente la modalità slotted CSMA-CA consente un numero inferiore di ritrasmissioni rispetto alla modalità unslotted CSMA-CA ma comunque non è possibile determinare esattamente quale sia la latenza trasmissiva dovuta all'accesso al canale, a causa della natura randomica del periodo di backo. Il delay trasmissivo introdotto dall'algoritmo è teoricamente innito, pertanto l'algoritmo non è adatto per applicazioni di tipo soft real-time Traco real-time: CFP Descrizione Generale Come illustrato nel paragrafo 2.4, durante la fase CFP il nodo Coordinator è in grado di allocare al nodo Device uno o più slot temporali all'interno del superframe: in questo modo è possibile allocare banda trasmissiva ad un nodo che necessita di limitare il ritardo di trasmissione. Il GTS è un

35 Capitolo 2. La suite di protocolli IEEE Figura 2.12: Diagramma di usso del meccanismo CSMA-CA

36 Capitolo 2. La suite di protocolli IEEE meccanismo opzionale supportato dal protocollo IEEE e può essere introdotto solo se la PAN è beacon-enable. Il corretto funzionamento si basa su una stretta sincronizzazione tra i nodi che costituiscono la PAN, la quale viene garantita tramite la trasmissione dei pacchetti di beacon. Infatti senza una procedura di sincronizzazione non sarebbe possibile disciplinare la trasmissione tra i vari nodi della PAN. I GTS possono essere di due tipi: GTS per la trasmissione e GTS per la ricezione. Il PAN Coordinator può allocare un massimo di due GTS ad ogni nodo Device: una in trasmissione e/o una in ricezione e indica la propria disponibilità ad allocare i GTS in un apposito campo all'interno del pacchetto di beacon. I nodi Device possono richiedere l'utilizzo dei GTS mediante richiesta esplicita al nodo Coordinator tramite un apposito pacchetto di comando in cui viene indicato il numero di slot del GTS richiesto e la direzione associata alla richiesta. Un GTS deve essere correttamente allocato dal PAN Coordinator prima di essere utilizzato dal device. Il PAN coordinator decide se eettuare l'allocazione richiesta in base ai requisiti della GTS e in base alla capacità disponibile nel superframe, seguendo l'ordine d'arrivo delle richieste (FIFO). Tutti i GTS assegnati ai nodi Device devono essere continue all'interno del CFP, con il primo GTS allocato che inizia subito dopo la fase di CAP e l'ultimo GTS allocato che termina subito prima della ne del CFP e pertanto prima della trasmissione di un nuovo pacchetto di beacon da parte del Coordinator. Il PAN coordinator deve disporre di un database per poter inserire le informazioni relative all'allocazione, deallocazione ed eventuale modica dei GTS allocati al device: in particolare, per ogni GTS, il PAN coordinator deve poter conoscere lo slot iniziale, la lunghezza, la direzione e il device alla quale il GTS è associato. Ogni nodo Device può richiedere l'allocazione di un GTS in trasmissione e/o in ricezione e per ogni GTS allocato il device essere in grado di memorizzare informazioni riguardandi slot iniziale, la lunghezza e la direzione. Se un device perde la sincronizzazione con il PAN Coordinator, tutte i GTS allocati al suddetto device devono essere cancellati. Nei paragra sucessivi verranno trattate le informazioni contenute nel pacchetto di beacon per la gestione delle GTS ( ), le primitive che il protocollo denisce per eettuare una richiesta/rilascio di GTS ( ), la procedura di allocazione ( ), la procedura di deallocazione ( ) e

37 Capitolo 2. La suite di protocolli IEEE le modalità di trasmissione/ricezione dati ( ) Pacchetto di comando GTS La richiesta di allocazione o deallocazione di un GTS viene eettuata mediante un apposito comando di richiesta. Tale comando è caratterizzato dal campo Command Frame Identier con valore pari a 0x09 e può essere inviato solo da nodi Device associati a un PAN Coordinator, e che pertanto utilizzano un indirizzo a 16-bit. Il comando risulta essere formattato come segue: Octets: MHR Fields Command Frame Identier GTS Characteristics Tabella 2.3: GTS tab: Formato del pacchetto di comando per richiesta/rilacio Il campo header (MHR) presenta una lunghezza di sette bytes (otteti) e contiene informazioni relative al mittente del pacchetto (macshortaddress del nodo a 16-bit), identicatore della PAN alla quale il nodo è associato, e richiesta di invio del messaggio di acknowledgement. Per una trattazione più accurata di tale campo si rimanda a [5]. Il campo GTS Characteristics presenta una lunghezza di 8 bit, risulta formattato come mostrato in gura ed è costituito dai seguenti sotto-campi: bits: GTS Length GTS DirectionGTS Characteristic Type Reserved Tabella 2.4: campo GTS Characteristics del pacchetto di comando per richiesta/rilacio GTS GTS Length (bit 0-3): rappresenta la lunghezza del GTS che si intende allocare o deallocare; GTS Direction (bit 4): rappresenta la direzione associata al GTS (0 = trasmissione, 1 = ricezione); Characteristics Type (bit 5): rappresenta il tipo di richiesta (0 = deallocazione, 1=allocazione).

38 Capitolo 2. La suite di protocolli IEEE Speciche GTS nel pacchetto beacon Le informazioni relative alla richiesta/rilascio dei GTS sono inserite all'interno del pacchetto beacon in un particolare sottocampo chiamato GTS Fields. Il sottocampo GTS Fields, la cui struttura è illustrata in tabella 2.5, è suddiviso in tre parti: Octets: 1 0/1 variable GTS Spacication GTS Direction GTS List Tabella 2.5: campo GTS Field del pacchetto beacon GTS Specication : ha una lunghezza di 8 bit e risulta formattato come illustrato in tabella: Octets: GTS Descriptor count Reserved GTS Permit Tabella 2.6: Field campo GTS Specication del pacchetto di sottocampo GTS Il GTS Description Count (bit 0-2) indica il numero di decrittori di GTS contenuti all'interno del campo GTS List. In ogni beacon possono esser presenti un massimo di 7 descrittori di GTS. Il GTS Permit (bit 7) indica se il PAN Coordinator è in grado di accettare richieste di GTS. I bit 4-6 sono riservati e non vengono utilizzati. GTS Direction : ha una lunghezza di 8 bit e i bit 0-6 indicano la direzione dell'i-esimo GTS contenuta nella GTS List. Se il bit è settato, il GTS è in ricezione, vicevera è un GTS in trasmissione, relativamente all direzione device-coordinator. GTS List : ha una lunghezza variabile e contiene una lista di descrittori di GTS la cui struttura è illustrata in tabella: Bits: Device Short Address GTS Starting Slot GTS Length Tabella 2.7: campo GTS List del pacchetto di sottocampo GTS Specication Il Device Short Address (bit 0-15) rappresenta l'indirizzo a 16-bit del nodo Device che eettua la/il richiesta/rilascio del GTS, ottenuto tramite la procedura di associazione con il nodo Coordinator.

39 Capitolo 2. La suite di protocolli IEEE Il GTS Starting Slot (bit 16-19) indica da quale slot temporale inizia il GTS allocato al device. Il GTS Length (bit 20-23) indica il numero di slot consecutivi che costituiscono la GTS allocata. Tutte le informazioni descritte precedentemente vengono inserite dal PAN Coordinator per noticare la corretta allocazione/deallocazione dei GTS. Queste informazioni sono temporanee e vengono rimosse dal pacchetto di beacon dopo un numero pari a amaxdescpersistencetime trasmissioni. Tramite la ricezione periodica del pacchetto di beacon il nodo Device è in grado di processare queste informazioni e conoscere lo stato dei GTS allocati Primitive di gestione dei GTS Le primitive di richiesta dei GTS e gestione degli stessi sono denite dal MLME-SAP GTS. Lo standard impone l'utilizzo di queste primitive da parte dei livelli superiori, quando un nodo Device intende richiede GTS ad un nodo Coordinator. MLME-GTS.request() : primitiva utilizzata dal livello superiore per richiedere al livello MAC l'avvio di una procedura di l'allocazione oppure deallocazione di un GTS, se il nodo è un Device; se il nodo è un Coordinator viene invece utilizzata per richiedere la deallocazione di un GTS precedentemente allocato. I parametri in ingresso alla primitiva sono nell'ordine: GTSCharacteristics, SecurityLevel, KeyIdMode, KeySource, KeyIndex Il parametro più importante è GTSCharacteristics il quale indica oltre al tipo di GTS e alla sua lunghezza, se la richiesta è relativa ad una allocazione o deallocazione. Quando viene invocata la primitiva MLME-GTS.request in un nodo Device, MLME tenta di generare un comando di allocazione/deallocazione

40 Capitolo 2. La suite di protocolli IEEE di GTS, con le informazioni contenute nel campo GTSCharacteristics. Se la trasmissione del pacchetto di comando ha esito positivo, MLME attende una conferma tramite pacchetto di acknowledgement della corretta ricezione del comando da parte del nodo PAN Coordinator. Se l'invio del comando non ha successo, l'evento viene noticato al livello superiore tramite un apposito codice d'errore mediante la primitiva MLME-GTS.conrm. Se viene confermata la corretta ricezione del comando tramite il pacchetto di acknowledgement relativamente a una richiesta di allocazione, il nodo Device attende conferma della allocazione del GTS nel pacchetto di beacon. Tale conferma è rappresentata dall'inserimento, all'interno del campo GTS List, di un descrittore di GTS contenente la specica della richiesta e l'indirizzo a 16-bit del nodo richiedente. La notica della da parte del livello MAC corretta allocazione avviene tramite l'invocazione della primitiva MLME-GTS.conrm con le caratteristiche della GTS richiesta. Se viene confermata la corretta ricezione del comando tramite il pacchetto di acknowledgement relativamente a una richiesta di deallocazione, il nodo device invoca la MLME-GTS.conrm con le caratteristiche del GTS deallocato. Alla ricezione di un comando di allocazione, MLME del PAN Coordinator verica la possibilità di allocazione: se l'allocazione è possibile, invoca la MLME-GTS.indication al livello superiore; inoltre genera un descrittore di GTS con le caratteristiche della GTS richiesta, lo slot iniziale all'interno del CFP, e l'indirizzo a 16-bit del nodo richiedente e inserisce tale descrittore nel pacchetto di beacon. Se la GTS non può essere allocata, il PAN Coordinator genera un descrittore di GTS con le caratteristiche della GTS richiesta, l'indirizzo a 16-bit del nodo richiedente e lo slot iniziale settato a 0. Alla ricezione di un comando di deallocazione, MLME del PAN Coordinator invia un pacchetto di acknowledgement e notica la deallocazione al livello superiore tramite MLME-GTS.indication. MLME-GTS.conrm() : primitiva utilizzata per confermare la corretta allocazione o deallocazione di un GTS al livello superiore. I parametri in ingresso della primitiva sono, nell'ordine: GTSCharacteristics

41 Capitolo 2. La suite di protocolli IEEE Status Viene invocata in seguito a una MLME-GTS.request per noticare l'esito della allocazione o deallocazione del GTS. Il parametro GTSCharacteristics indica il tipo e la lunghezza del GTS oltre all'operazione richiesta (allocazione o deallocazione). Il parametro Status indica l'esito della MLME-GTS.request. MLME-GTS.indication() :primitiva utilizzata dal livello MAC al livello superiore per confermare l'allocazione o la deallocazione di un GTS. I parametri in ingresso alla primitiva sono nell'ordine: GTSCharacteristics, SecurityLevel, KeyIdMode, KeySource, KeyIndex La semantica di questa primitiva è la medesima della primitiva MLME- GTS.request vista precedentemente Procedure di allocazione Un device che intende richiedere l'allocazione di GTS, deve invocare la primitiva MLME-GTS.request con le speciche del GTS richiesto come visto nel paragrafo La MLME del device genera, a seguito della richiesta, un pacchetto di comando (vedi ) da inviare al PAN Coordinator con il campo GTSCharcteristics opportunamente settato: in particolare il valore del parametro Characteristics Type viene settato a uno per indicare una richiesta di allocazione. Dopo l'invio del pacchetto di comando, il MAC del nodo Device attende conferma della corretta ricezione da parte del PAN Coordinator mediante il pacchetto di acknowledgement: se tale pacchetto viene ricevuto, il livello MAC attende conferma della allocazione del GTS, indicata all'interno del pacchetto di beacon tramite un descrittore, per al massimo agtsdescpersistencetime superframe. Il device comunica un fallimento al livello superiore tramite la primitiva MLME-GTS.confirm con stato pari a NO_DATA se non rileva la presenza di un descrittore relativo alla richiesta eettuata, entro il

42 Capitolo 2. La suite di protocolli IEEE tempo previsto. Se il descrittore che viene rilevato è relativo alla richiesta eettuata, l'indirizzo a 16-bit indicato corrisponde l'indirizzo del device, e lo slot iniziale risulta diverso da zero, viene noticata la corretta allocazione al livello superiore tramite la primitiva MLME-GTS.conrm con le caratteristiche del GTS allocato e stato pari a SUCCESS. Se invece il valore dello slot iniziale risulta pari a zero, viene noticata la mancata allocazione del GTS tramite MLME-GTS.confirm con le caratteristiche del GTS richiesto e stato pari a DENIED. Il livello MAC del PAN Coordinator deve noticare la ricezione del pacchetto di comando con la trasmissione di un pacchetto di acknowledgement. Alla ricezione del pacchetto di comando con la richiesta di allocazione di una GTS, il PAN Coordinator deve vericare la disponibilità di spazio all'interno del superframe in base alla lunghezza del GTS richiesto, della attuale lunghezza del CAP e al numero di GTS attivi correntemente allocati, come indicato nella relazione 2.1. Le richieste devono essere servite in modalità FCFS e la decisione di allocazione deve essere eettuata entro agtsdescpersistencetime superframe. Dopo aver vericato la possibilità di allocazione del GTS, il PAN Coordinator genera un descrittore di GTS relativo alla richiesta e contenente l'indirizzo a 16-bit del nodo richiedente. Se il GTS viene allocato, la conferma di allocazione avviene settando parametro relativo allo slot iniziale al valore in cui inizierà il GTS allocato e il parametro lunghezza al numero di slot richiesti. Se il GTS non può essere allocato per mancanza di disponibilità all'interno del superframe, il parametro relativo allo start slot viene settato a zero. In caso di allocazione avvenuta con successo, MLME invoca la primitiva MLME-GTS.indication con le caratteristiche del GTS allocato. Il decrittore di GTS appena creato deve essere inserito del sottocampo GTSList del pacchetto di beacon per al massimo agtsdescpersistencetime superframe dopo i quali viene rimosso automaticamente. Il diagramma di sequenza 2.13 mostra la procedura di allocazione Procedura di deallocazione Un nodo Device che intende richiedere la deallocazione di GTS esistente, deve invocare la primitiva MLME-GTS.request con le speciche del GTS richiesto come visto nel paragrafo La MLME del device genera, a

43 Capitolo 2. La suite di protocolli IEEE Figura 2.13: Diagramma di sequenza per l'allocazione di un GTS seguito della richiesta, un pacchetto di comando (vedi ) da inviare al PAN Coordinator con il campo GTSCharcteristics opportunamente settato: in particolare il valore del parametro Characteristics Type viene settato a zero per indicare una richiesta di deallocazione. Dopo l'invio del pacchetto di comando, il livello MAC del nodo Device attende conferma della corretta ricezione da parte del PAN Coordinator mediante il pacchetto di acknowledgement: se tale pacchetto viene ricevuto, il device conferma la deallocazione noticando il successo dell'operazione al livello superiore mediante la MLME-GTS.confirm con lo stato pari a SUCCESS. Il livello MAC del PAN Coordinator deve noticare la ricezione del pacchetto di comando con la trasmissione di un pacchetto di acknowledgement. Alla ricezione del pacchetto di comando con la richiesta di deallocazione di un GTS, il PAN Coordinator verica l'esistenza del GTS e che sia eettivamente allocato al nodo Device che ne richiede la deallocazione, controllando le speciche della GTS da deallocare e l'indirizzo a 16-bit indicato nel pacchetto di comando. Se non esiste un GTS eettivamente associato al nodo Device che ha eettuato la richiesta, quest'ultima viene ignorata. In caso contrario la richiesta di deallocazione viene portata a termine e viene noticato il cambiamento al livello superiore con l'invocazione della primitiva MLME-GTS.indication con le caratteristiche del GTS deallocato e con il sottocampo Characteristics Type settato a zero per indicare la deallocazione. La procedura di deallocazione può anche essere attivata dal PAN Coordinator in seguito a:

44 Capitolo 2. La suite di protocolli IEEE richiesta esplicita da parte del livello superiore, 2. non utilizzo della GTS da parte del device. In entrambi i casi MLME del PAN Coordinator genera un descrittore di GTS relativo alla deallocazione contenente l'indirizzo a 16-bit del nodo e le speciche del GTS deallocato. In caso di deallocazione avvenuta con successo, MLME invoca la primitiva MLME-GTS.indication con le caratteristiche del GTS deallocato. Il decrittore di GTS appena creato deve essere inserito del sottocampo GTSList del pacchetto di beacon per un massimo di agtsdescpersistencetime superframe dopo i quali viene rimosso automaticamente. Relativamente al secondo caso, il PAN Coordinator deve essere in grado di vericare se un GTS allocato ad un device sia eettivamente utilizzato o meno. Il protocollo denisce due regole che consentono al MLME del PAN Coordinator di determinare il mancato utilizzo del GTS allocato: Per un GTS allocato in trasmissione, se non vengono ricevuti pacchetti dati per almeno 2 n superframe; Per un GTS allocato in ricezione, se non vengono ricevuti pacchetti di acknowledgement per almeno 2 n superframe. dove n = 2 8 BO se 0 BO 8 altrimenti n = 1 se 9 BO 14. In caso non siano previsti i pacchetti di acknowledgement, la seconda regola non è applicabile. Il diagramma in gura 2.14 riassume i passi della procedura di deallocazione. La deallocazione di un GTS può comportare la frammentazione del superframe, come mostrato in gura 2.15 In questo caso MLME del PAN Coordinator deve prevedere una gestione degli slot temporali in modo tale da massimizzare la durata del periodo di CAP: questo si ottiene rilocando i GTS ancora validi. La procedura di rilocazione consiste sostanzialmente nella modica del valore dello start slot iniziale dei GTS allocati. Se avviene una rilocazione di GTS a seguito di una deallocazione, il PAN Coordinator deve noticare ai device interessati le modiche apportate, inserendo opportuni descrittori di GTS nel campo GTSList del pacchetto di beacon. Il device che rileva nel pacchetto beacon un descrittore di GTS contenente il

45 Capitolo 2. La suite di protocolli IEEE Figura 2.14: Diagramma di sequenza della deallocazione di un GTS proprio indirizzo a 16-bit e parametri di GTS modicati, deve aggiornare lo slot iniziale del GTS allocato a utilizzarlo immediatamente con le nuove modiche apportate Trasmissione e ricezione dati Quando viene invocata la primitiva MCPS-DATA.request da parte di un nodo Device con il parametro TxOption indicante la richiesta di trasmissione mediante GTS, il MAC deve eettuare le seguenti azioni: 1. determinare se esiste un GTS in trasmissione allocata al device, 2. se la GTS esiste, trasmettere il pacchetto MPDU durante la GTS, immediatamente e senza usare il meccanismo di CSMA-CA, garantendo la ne della transazione prima della ne del GTS allocato e in ogni caso prima della ne del CFP. Se la trasmissione non può essere completata prima della ne del GTS allocato, quest'ultima deve essere posticipata ne all'inizio del prossimo GTS nel prossimo superframe. 3. se il GTS non esiste, MPDU deve essere trasmesso usando CSMA-CA durante la fase di CAP. Se il nodo Device possiede un GTS allocato in ricezione, il livello MAC deve garantire che il transceiver radio sia acceso e in modalità ricezione pochi istanti prima dell'inizio del GTS e per tutta la durata dello stesso, come indicato nello slot iniziale e nella lunghezza.

46 Capitolo 2. La suite di protocolli IEEE Figura 2.15: Frammentazione di GTS in seguito a deallocazione Quando viene invocata la primitiva MCPS-DATA.request da parte di un PAN Coordinator con il parametro TxOption indicante la richiesta di trasmissione mediante GTS, il MAC deve eettuare le seguenti azioni: 1. determinare se esiste un GTS in ricezione allocata al device il cui indirizzo di destinazione è indicato nel MPDU; 2. se un GTS esiste, il livello MAC del PAN Coordinator deve ritardare la trasmissione no all'inizio del GTS e in questo caso non deve essere indicato l'indirizzo del nodo Device nella lista dei pacchetti pendenti all'interno pacchetto di beacon. Quando inizia il GTS, MPDU deve essere trasmesso immediatamente senza l'utilizzo del meccanismo di CSMA-CA e la trasmissione deve essere completata entro la durata del GTS. In caso contrario la trasmissione deve esser ritardata sino al prossimo GTS nel prossimo superframe. 3. se un GTS non esiste, l'indirizzo del nodo destinatario viene inse-

47 Capitolo 2. La suite di protocolli IEEE rito nella lista degli indirizzi pendenti del pacchetto di beacon e la trasmissione avviene durante la fase CAP. Per tutte le GTS allocate in trasmissione ai nodi Device, il MAC del PAN Coordinator deve garantire che il trasceiver radio sia attivo in ricezione prima dell'inizio di ogni GTS e per tutta la durata del GTS. Pertanto devono essere presi in considerazione eventuali tempi di TurnaroundTime dovuti al passaggio dalla modalità di trasmissione a quella di ricezione e viceversa del transceiver radio.

48 Capitolo 3 L'ambiente di Simulazione 3.1 L'importanza della simulazione La simulazione è un importante strumento di analisi nello sviluppo di sistemi distribuiti e nella fase di testing di nuovi protocolli di rete. Un sistema è una collezione di componenti interagenti tra di loro dei quali si vuole studiare ed analizzare il comportamento. L'interazione può essere spontanea oppure organizzata in modo da soddisfare certe speciche di comportamento. Per poter studiare il comportamento del sistema occorre realizzare un modello dello stesso, ossia una rappresentazione del sistema. L'evoluzione del sistema viene poi descritta tramite gli stati che esso può assumere. Uno stato descrive la condizione istantanea di tutte le componenti del sistema e ha una corrispondenza con lo stato del modello che rappresenta il sistema. Naturalmente lo stato del modello risulta semplicato rispetto quello del sistema vero e proprio in quanto esiste un certo livello di astrazione, funzionale alle misure che si vogliono eettuare sul modello e che indica che alcune caratteristiche dello stato del sistema sono state omesse. Il modello più semplice è quello che consente di ottenere tutte e sole le misure desiderate. Trovare una soluzione al modello signica perturbare il modello stesso con delle variabili d'ingresso che interagendo con le variabili di stato del modello restituiscono delle variabili in uscita che possano essere analizzate. L'analisi delle variabili in uscita può essere eettuata in forma matematica oppure in forma simulata ossia analizzando l'evoluzione delle variabili di

49 Capitolo 3. L'ambiente di Simulazione 39 stato del modello e misurando direttamente le variabili d'uscita. Pertanto la simulazione ricostruisce un sistema che evolve attraverso una serie di stati come un sistema reale. La simulazione in assoluto più utilizzata nell'ambito delle telecomunicazioni e del networking è quella a eventi discreti, nella quale il cambiamento di stato del sistema prende il nome di evento e il simulatore elabora le informazioni in corrispondenza di ogni evento (discreto) fornendo le opportune variabili di uscita. Tramite la simulazione è pertanto possibile completare e validare l'analisi matematica soprattutto per sistemi complessi con un grande numero di nodi interagenti. Essa consente di progettare, senza costi aggiuntivi, dei sistemi ipotetici e nuovi, confrontare tra di loro due sistemi, ottimizzare il valore di determinati parametri o rilevare i punti critici (bottle-neck) con la possibilità di analizzare il comportamento del modello anche in condizioni che sono dicilmente realizzabili e misurabili in un sistema reale. L'analisi di performance tramite simulazione è particolarmente importante nei sistemi real-time dove le garanzie di ritardi e throughput sono fondamentali per la buona realizzazione del sistema nale. Nei sistemi hard real-time l'evento di deadline miss, causato da un ritardo nella risposta del sistema, può compromettere la correttezza del sistema stesso; nei sistemi soft real-time, tale evento è meno critico ma la qualità del servizio dipende comunque da parametri come il ritardo medio e quello massimo. I simulatori di rete esistenti permettono di simulare fedelmente il comportamento della rete e di sistemi distribuiti con una grande varietà di protocolli, ma si focalizzano esclusivamente sul comportamento relativo alla comunicazione. Non viene infatti modellizzato in alcun modo il comportamento temporale delle applicazioni che sono presenti nei vari nodi e che generano il traco che uisce nella rete: questo signica che le computazioni eettuate da un ipotetico sistema operativo presente nel nodo avvengono senza introdurre alcun ritardo. Quando si analizza un sistema real-time l'assunzione eettuata precedentemente non risulta più valida in quanto i ritardi del sistema operativo causato da altre attività nel processore e/o dalla modalità di scheduling possono avere un impatto rilevante sulla qualità del servizio.

50 Capitolo 3. L'ambiente di Simulazione Il simulatore NS-2 NS-2 [6] è un simulatore di rete event-driven nato per la valutazione e lo studio di protocolli di rete. Per motivi di ecienza, NS-2 è scritto in 2 linguaggi: C++ : un linguaggio compilato con cui sono implementate la maggior parte dei modelli degli oggetti di NS-2. L'uso di C++ consente grande essibilità nella estensione e creazione di nuovi modelli e risulta essere più veloce in termini di velocità di calcolo. Lo svantaggio principale riguarda la complessità in termini di scrittura. OTcl : un linguaggio di scripting interpretato utilizzato come interfaccia alle classi implementate in C++. OTcl viene principalmente utilizzato nella scrittura degli scenari di simulazione. Ogni classe che viene implementata in C++ rappresenta un elemento di rete. La maggior parte delle classi in C++ presenta anche una controparte implementata in OTcl (shadow class). L'operazione di binding() consente di controllare e settare tramite OTcl variabili denite all'interno della classe C++. Inoltre è possibile denire nelle classi dei comandi che consentono di invocare opportuni metodi tramite OTcl. I risultati della simulazione vengono resi diponibili tramite un le di traccia che può essere analizzato oine. Essendo NS-2 un simulatore event-driven, la realtà viene modellata come una successione di eventi. La classe Scheduler tiene traccia del tempo attuale di simulazione e degli eventi che sono stati generati: essa infatti contiene una lista degli eventi, istanze di oggetti della classe Event, pronti per essere eseguiti. In NS-2 sono implemetati vari tipi di scheduler che processano gli eventi in modo diverso a seconda della politica decisionale scelta. Quando lo scheduler determina l'esecuzione di un evento, lo ricerca all'interno della lista, ordinata per tempo di schedulazione, e lo esegue preparandosi poi all'esecuzione dell'evento sucessivo. L'esecuzione di eventi contemporanei avviene in ordine di inserimento (FIFO), e l'unità temporale che viene usata nel simulatore è il secondo. L'oggetto più importante in una simulazione di rete wireless risulta essere il Mobile Node, il quale aggiunge le funzionalità di mobilità e l'uso del canale wireless all'oggetto Node. Il nodo mobile presenta una struttura

51 Capitolo 3. L'ambiente di Simulazione 41 modulare: i vari oggetti che lo compongono eseguono le proprie elaborazioni e una volta terminate, comunicano i risultati agli oggetti adiacenti. Quando viene creato un nuovo nodo, viene anche creata una nuova istanza per tutti gli oggetti che lo compongono. L'architettura del nodo wireless è mostrata in gura 3.1. Le componenti Figura 3.1: Rappresentazione NS-2 del nodo wireless che costituiscono il nodo possono essere sostituite con componenti standard oppure con componenti implementate per soddisfare specici requisiti di simulazione. Una rete radio possiede, poi, un oggetto particolare chiamato God (General Operation Director), unico per ogni simulazione. Si tratta di

52 Capitolo 3. L'ambiente di Simulazione 42 un oggetto che memorizza tutte le informazioni inerenti lo stato dell'ambiente, della rete e dei nodi. Nelle versioni attuali God memorizza il numero dei terminali mobili e una tabella con gli hop minimi necessari per andare da un nodo ad un altro. Qui di seguito viene riportato un esempio di congurazione e di inizializzazione di una rete wireless. $ns node-config -adhocrouting DumbAgent \ -lltype LL \ -mactype Mac/802_15_4 \ -ifqtype Queue/DropTail/PriQueue \ -ifqlen 50 \ -anttype Antenna/OmniAntenna \ -proptype Propagation/TwoRayGround \ -phytype Phy/WirelessPhy \ -channel Channel/WirelessChannel \ -topoinstance $topo \ -agenttrace OFF \ -routertrace OFF \ -mactrace ON \ -movementtrace OFF Descrizione del Nodo Wireless Quando un pacchetto deve essere trasmesso, l'agente lo fornisce al modulo Address Demuxer. I pacchetti, implementati dalla classe Packet, sono eventi che vengono gestiti dallo scheduler prima dell'istante in cui devono essere trasmessi. Il pacchetto viene utilizzato per modellizzare la trasmissione di un messaggio nella rete ed è costituito principalmente da un campo Header, contenente tutte le informazioni rilevanti per la corretta trasmissione del pacchetto e la gestione da parte dei vari protocolli, e da un campo Payload che solitamente risulta essere vuoto ma che vien simulato tramite la dimensione del pacchetto. Estendendo la classe Packet, è possibile denire nuovi tipi di pacchetto per nuovi protocolli, oppure aggiungere informazioni al pacchetto creando nuovi header. L'oggetto Address Demuxer è implementato dalla classe AddressClassifier: esso analizza l'indirizzo di destinazione del pacchetto e se questo coincide con l'indirizzo del nodo, invia il pacchetto al PortDemuxer, imple-

53 Capitolo 3. L'ambiente di Simulazione 43 mentato dalla classe PortClassifier; mentre in caso contrario il pacchetto viene inviato al modulo che gestisce il routing. Il pacchetto in seguito raggiunge il livello LL (Link Layer), implementato dalla classe LL: è previsto anche l'oggetto ARP che implementa la risoluzione degli indirizzi di rete. LL processa i pacchetti, introducendo un ritardo di elaborazione, e li fornisce al livello MAC attraverso una coda di interfaccia, IFq: la dimensione della coda è settabile dall'utente. I pacchetti presenti della coda IFq vengono gestiti dal MAC singolarmente: un nuovo pacchetto viene fornito al MAC solo quando il precedente è stato completamente trasmesso. In NS-2 sono implementate varie tipologie di code in base al tipo di gestione prevista: ad esempio è possibile utilizzare una coda prioritaria per la gestione dei pacchetti di routing o estenderla per supportare ulteriori tipologie di pacchetto. Il livello MAC,implementato dalla classe Mac, denisce le regole per accedere al canale sico, implementato a sua volta dalla classe Channel: quest'ultimo simula la propagazione del segnale nel canale. Tutti i nodi della rete wireless vengono collegati al canale: quando un pacchetto viene trasmesso, viene ricevuto da tutti i nodi nel raggio di trasmissione del segnale radio. La maggiore complessità del nodo risiede nell'oggetto MAC, il quale simula sia i vari protocolli di accesso al canale sia gli eventuali meccanismi di carrier-sense e collision detection/avoidance. Inne l'oggetto NetIF viene usato per simulare l'interfaccia hardware del nodo wireless. Il Radio Propagation Model simula l'attenuazione del segnale per eetto della propagazione al ne di calcolare la potenza di quest'ultimo quando viene ricevuto: ai pacchetti trasmessi viene associata un valore di energia che degrada in base al modello di propagazione scelto e che tendenzialmente dipendente dalla distanza tra nodo mittente e nodo destinatario. Un pacchetto non risulta ricevuto se il valore di energia associata alla trasmissione dello stesso è inferiore ad una certa soglia denita proprio dal modello di propagazione. I protocolli di rete sono realizzati in NS-2 come Agenti, tramite la classe Agent, la quale può essere estesa per implementare nuovi protocolli di comunicazione. In particolare deve essere ridenito il metodo recv() della classe Agent: questo metodo denisce infatti come gestire il pacchetto in base alle informazioni in esso contenute. Ogni agente dispone di un indirizzo INET e di una porta utilizzata per la comunicazione. L'applicazione che genera il traco di rete viene modellizzata dalla classe

54 Capitolo 3. L'ambiente di Simulazione 44 Application, che utilizza l'agente per inviare e ricevere i pacchetti. Poiché l'applicazione risulta collocata in un livello superiore rispetto all'agente, quest'ultimo è in grado di analizzare i pacchetti prima di fornirli all'applicazione. Nel capitolo 4 verrà analizzato nel dettaglio il supporto di NS-2 alle reti WPAN. 3.3 Il simulatore RTSim RTSim [9, 12] è una collezione di librerie scritte in C++ che consente di modellizzare e simulare sistemi embedded a singolo processore o multiprocessore, entrambi con un sistema operativo real-time e un set di processi concorrenti. RTSim è costituito da 2 parti: Metasim : libreria generica utilizzata per simulare eventi discreti; RTLib : libreria, basata sulla precedente, per simulare eventi discreti e task real-time; Il modello di un processo, Task, viene realizzato come una sequenza nita di richieste di esecuzione chiamate job, i quali eseguono una serie di istruzioni: queste ultime sono identicate da una porzione di codice, che simulano il comportamento temporale del task (tempo di utilizzo del processore), ma è anche possibile associare al task un comportamento esecutivo determinato da una serie di azioni che vengono eettivamente eseguite al termine del task. Nel momento in cui un job viene attivato, l'istante di attivazione viene indicato come arrival time. In base a quest'ultimo i task vengono suddivisi in: Periodici : se i vari arrival time sono tra loro separati da un intervallo temporale costante chiamato periodo. Sporadici : se i vari arrival time sono tra loro separati da un intervallo temporale che non è costante ma non può assumere un valore minimo inferiore ad una certa soglia detta minimum interarrival time. Aperiodici : se i vari arrival time sono completamtente scorrelati tra loro. I task di un sistema real-time presentano dei vincoli temporali (deadline) entro cui, dopo l'istante di attivazione, devono essere completamente eseguiti

55 Capitolo 3. L'ambiente di Simulazione 45 al ne di garantire il corretto funzionamento di tutto il sistema. Un esempio di deadline per i task periodici è il periodo: un task periodico deve completare la propria esecuzione entro l'attivazione successiva, pertanto prima della ne del periodo. Se un task non completa l'esecuzione entro la deadline si ha un evento detto deadline miss il quale può avere conseguenze diverse sul comportamento complessivo in base al tipo di sistema real-time. Il sistema risulta composto da: uno o più processori, un sistema operativo real-time, una politica di scheduling per l'assegnazione della CPU. Una schedulazione corrisponde ad un evento discreto che viene gestito tramite un apposito Handler da un motore di simulazione chiamato Metasim. Ad esempio, se la schedulazione è relativa ad un evento di attivazione, il relativo gestore inserirà il task nella coda dei processi pronti. Il tempo di utilizzo del processore da parte dei task viene misurato in termini di tick, ossia istruzioni al secondo. La classe Task implementata in RTSim consente la creazione di task generici. Le istruzioni che realizzano il corpo del task sono invece implementate mediante la classe Instr. Il codice che simula il comportamento del task viene associato al task stesso mediante l'invocazione del metodo insertcode() della classe Task: essa prevede come parametro in ingresso una stringa che rappresenta il nome dell'istruzione da eseguire quando viene schedulato il task. La corrispondenza tra il nome dell'istruzione e la classe che implementa l'istruzione stessa viene eettuata in oggetto statico di tipo registerinfactory, denito in RTSim, che prende il nome di registro statico. La classe Task consente di generare Task periodici, aperiodici o sporadici e di denire per ogni task una deadline relativa e un periodo. 3.4 Il simulatore RTNS Il Real Time Network Simulator (RTNS) [11, 7, 8] è un software di simulazione sviluppato nel laboratorio ReTiS Lab della Scuola Superiore Sant'Anna di Pisa per modellare il meccanismi del sistema operativo in applicazioni di

56 Capitolo 3. L'ambiente di Simulazione 46 rete distribuite 1. RTNS integra il simulatore NS-2 (Network Simulator) con il simulatore RTSIM (Real Time Operating System SIMulator) colmando il gap tra i simulatori di rete e di sistemi operativi. Infatti in generale un simulatore di rete come NS-2 non considera nella sua analisi il ritardo introdotto dall'attività del sistema operativo sul particolare nodo della rete: il motivo principale di questa assunzione deriva dal fatto che questo ritardo risulta come ordine di grandezza inferiore a quello introdotto dallo stack di rete. Un'altra motivazione errata è il considerare che il servizio oerto da una rete wireless di sensori sia di tipo best-eort. L'assunzione precedente, infatti, non è più vera se si considerano reti con velocità trasmissive elevate, in cui la latenza di invio è comparabile con quella introdotta dal sistema operativo. Integrando NS-2 con RTSim è possibile simulare anche la presenza di un sistema operativo real-time: in questo modo viene realizzato un modello che descrive l'attività computazionale sul nodo. Infatti in un contesto come quello delle applicazioni di rete, la comunicazione tra i vari nodi avviene mediante lo scambio di pacchetti che vengono generati da apposite applicazioni. La generazione di un pacchetto è il risultato dell'esecuzione di un task preventivamente attivato e in seguito schedulato dal sistema operativo. Se la schedulazione di tale task avviene con un ritardo a causa della presenza di carico nella CPU, cioè a seguito della attivazione di un task a priorità maggiore, la generazione del pacchetto dal momento della richiesta sarà aetta da ritardo: quest'ultimo potrebbe anche non essere trascurabile in applicazioni particolarmente sensibili come nel caso di applicazioni real-time. Quanto detto precedentemente vale anche per i task demandati all'invio e alla ricezione degli stessi pacchetti nella rete. L'integrazione tra i due simulatori, che utilizzano scheduler diversi e code diverse per gestire la generazione degli eventi, è stata eettuata mantenendo NS-2 come simulatore principale e denendo in NS-2 un evento speciale: il cosimulatore processa tutti gli eventi che, in un certo istante, si sono vericati in RTSim e li inserisce nella coda di NS-2. Per mantenere sincronizzato il tempo logico di RTSim con quello di NS-2, ogni qualvolta un oggetto di RTSim inserisce al tempo t un evento nella coda di schedulazione, allo stesso 1 Un tool simulativo analogo risulta essere TrueTime [4] che fornisce l'astrazione del sistema operativo sui nodi e dei meccanismi di rete per WSN. Tuttavia anche tale simulatore non supporta il meccanismo di CFP previsto dallo standard IEEE

57 Capitolo 3. L'ambiente di Simulazione 47 istante t viene inserito un evento rtsim_event nella coda di schedulazione di NS-2, come illustrato in gura 3.2. Quando l'evento rtsim_event viene Figura 3.2: Schema di gestione eventi RTNS schedulato, un handler processa tutti gli eventi che sono stati inseriti nella coda di schedulazione di RTSim all'istante t. Il metodo adjust_timer viene invocato dopo ogni attivazione di un task per mantenere sincronizzati i tempi di esecuzione dei due simulatori. La rappresentazione del nuovo nodo mobile denito in RTNS è illustrata in gura 3.3. Sono state ridenite una nuova classe agente, RTAgent, e una nuova classe applicazione, RTNSApp, derivate rispettivamente della classe Agent e Application di NS-2. Il costruttore della classe RTNSApp prevede la creazione di un oggetto Kernel che simula il sistema operativo, e di un oggetto Scheduler per la gestione delle attivazioni dei task. Dopo aver creato i task, questi vengono associati allo scheduler tramite il metodo addtask(); con il metodo createload() è invece possibile simulare il carico presente sulla CPU. Tramite il metodo CreateNetworkTask() della classe RTNSApp vengono create le istanze dei task che simulano la trasmissione e la ricezione dei pacchetti. Le classi che deniscono i task di invio e ricezione dati, entrambe derivati dalla classe RTTask, sono: SendTask : implementa il task di invio aperiodico. Questa prevede il metodo activate() per l'attivazione del task quando un nuovo pacchetto deve essere trasmesso. Le istruzioni che rappresentano l'esecuzione del task sono implementate mediante la classe SendInstr: il tempo di ese-

58 Capitolo 3. L'ambiente di Simulazione 48 Figura 3.3: Rappresentazione modulare del nodo RTNS cuzione di tale istruzione è sso. invio è indicata come send(). Nel registro statico l'istruzione di ReceiveTask : implementa il task di ricezione aperiodico. Anch'essa prevede il metodo activate() per l'attivazione del task da parte di RTNSApp ogni volta che un pacchetto viene generato dall'applicazione oppure recapitato a quest'ultima da parte di un generatore di traco. Le istruzioni che rappresentano l'esecuzione di questo task sono implementate tramite la classe ReceiveInstr: questa preleva un pacchetto dall'agente. Se non vi sono pacchetti, l'istruzione si blocca in attesa di essere riattivata in modo esplicito dall'agente quando arriva un pacchetto. Nel registro statico l'istruzione di ricezione è indicata come receive(). Oltre all'istruzione send() e receive() è prevista l'istruzione delay(time) utilizzata per simulare una porzione di codice che occupa un tempo nito sulla CPU per essere eseguito. Tutte le funzionalità descritte precedentemente sono state esportate tramite appositi comandi OTcl: in questo modo è possibile congurare i parametri

59 Capitolo 3. L'ambiente di Simulazione 49 direttamente dallo script di simulazione. Nel seguente listato invece sono riportati i comandi necessari alla creazione di un nodo RTNS: ;#Inizializzazione simulatore RTSim set rtsim [new RTSimInit] ;# Settaggio risoluzione della CPU (tick al secondo) $rtsim resolution ;# Creazione agente set agt [new Agent/UDP/RTAgent] $ns attach-agent station agt ;# Creazione SO con relativo scheduler set app [new Application/Traffic/CBR/RTApp FCFS] $app attach-agent agt ;# Simulazione del carico sulla CPU $app createloadtask

60 Capitolo 4 Le reti WPAN in NS Il package WPAN Nel simulatore NS-2 a partire dalla versione 2.28 è stato integrato il supporto al protocollo IEEE sviluppato da J. Zheng e altri presso i laboratori Samsung di Cuny [13]. Grazie a tale package è possibile utilizzare NS-2 per simulare il comportamento di reti wireless di sensori a basso rate trasmissivo (LR-WPAN). La maggior parte del codice è scritto con il linguaggio C++ ed è stato implementato in maniera da avere una corrispondenza il più possibile fedele con lo standard IEEE Infatti sono stati sviluppati i livelli PHY, MAC e SSCS e la maggior parte delle funzionalità previste dallo standard per ogni livello. In particolare per il livello MAC le funzionalità implementate sono: Accesso al mezzo mediante slotted CSMA-CA e unslotted CSMA-CA, Supporto alle topologie star e peer-to-peer, Modalità beacon-enable e non beacon-enable, Associazione e disassociazione dei device, Trasmissione diretta e indiretta. Invece, per il livello PHY le funzionalità implementate sono: Energy Detection,

61 Capitolo 4. Le reti WPAN in NS-2 51 Clear Channel Assessment, Link Quality Detection, Scansione dei canali, Modello dell'errore. Il livello SSCS è stato implementato per mostrare come sia possibile interfacciare il livello MAC con un livello superiore. Il package prevede anche una versione di NAM migliorata e il supporto per la realizzazione del le di traccia. In questo package non è previsto il supporto all'allocazione dei GTS e alla trasmissione su banda garantita: pertanto nel presente lavoro di tesi, esso è stato integrato con le funzionalità necessarie all'allocazione, utilizzo e deallocazione dei GTS da parte dei nodi. 4.2 Supporto per il protocollo IEEE Nel package WPAN sono previsti degli appositi comandi in OTcl che consentono di modicare il comportamento del nodo; essi sono: 1. $node sscs startpancoord <txbeacon=1> <BO=3> <SO=3> : che permette l'inizializzazione di un nodo PAN Coordinator. Il parametro tx- Beacon viene utilizzato per discriminare se il PAN Coordinator possa o meno trasmettere pacchetti di beacon e di conseguenza se la PAN sia di tipo beacon-enable o non beacon-enable; nel primo caso i parametri BO e SO specicano i valori di beacon order e superframe order; 2. $node sscs startdevice <isffd=1> <assopermit=1> <txbeacon=0> <BO=3> <SO=3>: che permette l'inizializzazione di un nodo device. Il parametro isffd discrimina il tipo di device (RFD oppure FFD); assopermit indica se verrà attuata la procedura di associazione al PAN Coordinator; txbeacon inne assume signicato illustrato nella prima istruzione e ha validità solo nel caso di un device di tipo FFD. Nelle sezioni successive verrà descritta la sequenza di azioni necessarie all'inizializzazione del nodo e alla creazione della rete con riferimento alla modalità beacon-enable (4.2.3 e 4.2.2).

62 Capitolo 4. Le reti WPAN in NS La classe Mac802_15_4 La classe Mac802_15_4, derivata dalla classe Mac di NS-2, implementa le funzionalità e i servizi oerti dal MAC IEEE In essa vengono deniti tutti quei metodi e primitive previsti dallo standard che realizzano le entità di gestione (MLME) e trasmissione/ricezione dati (MCPS). La struttura dati MAC_PIB denisce la MAC PAN Information Base, contenente tutte le informazioni inerenti il corretto funzionamento del livello MAC, come l'indirizzo a 16-bit e a 64-bit del nodo, il valore di BO e SO, etc. Come illustrato nel capitolo 3, tutte le funzionalità dell'entita MLME vengono compiute secondo una serie di azioni, tipicamente consistenti in una fase di richiesta, una fase di conferma e una fase di notica. Al ne di gestire lo stato delle richieste ed evitare l'overlapping delle stesse, le primitive di servizio MLME vengono realizzate come macchina a stati: esse, infatti, sono suddivise in sotto-richieste o step consecutivi che corrispondo allo stato di esecuzione della primitiva stessa; la struttura taskpending tiene traccia dell'attuale stato di esecuzione di ogni primitiva. Quando una sotto-richiesta viene completata, invoca un apposito metodo dispatch(), denito nella classe MAC , fornendogli il risultato della propria esecuzione: esso, in base alle informazioni contenute nella struttura dati taskpending, permette alla primitiva di proseguire dal punto in cui era stata interrotta fornendole il risultato della sotto-richiesta. Per i dettagli implementativi relativi alla classe Mac802_15_4 si rimanda al codice di WPAN Attivazione di nodo Coordinator Tramite il comando $node sscs startpancoord, si richiede al livello SSCS di dare inizio alle azioni necessarie per la creazione di un PAN Coordinator e pertanto di una nuova PAN. Il comando invoca il metodo SSCS802_15_4::startPANCoord, nel quale vengono eseguite una serie di chiamate alle primitive di MLME, come de- nite dallo standard. La creazione di una nuova PAN prevede che il nodo eettui una preventiva scansione del canale trasmissivo al ne di trovare una frequenza libera da utilizzare per la futura comunicazione. Inizialmente il livello SSCS invoca la primitiva MLME-SCAN.request tramite la quale il livello MAC fornisce un servizio di scansione del canale sico. Il MAC denisce

63 Capitolo 4. Le reti WPAN in NS-2 53 vari tipi di scansioni del canale (ED, attiva, passiva, orphan): nella fase di creazione di una nuova PAN la modalità di scansione prevista è quella attiva. In questo modo il nodo, per ogni canale logico, abilita il tranceiver in ricezione per una durata massima di abasesuperframeduration (2 n 1) simboli, dove n è un parametro modicabile, e memorizza le informazioni sui pacchetti di beacon che riceve in una lista di descrittori. Alla ne della scansione, il livello MAC fornisce la lista al livello superiore (SSCS) mediante la primitiva MLME-SCAN.confirm. Il livello SSCS analizza la lista di descrittori alla ricerca di un canale libero, dando priorità ai canali 2.4GHz. Una volta scelto il canale e settato il parametro macassociationpermit per indicare la disponibilità ad associare device al PAN coordinator, SSCS invoca la primitiva MLME-START.request con la quale un PAN Coordinator può stabilire una nuova PAN (o modicare la congurazione del superframe) e iniziare la trasmissione dei pacchetti di beacon sul canale. Tra i vari parametri di ingresso della primitiva è necessario specicare l'identicativo della PAN, il valore del SO (superframe order) e del BO (beacon order) e il canale scelto nella scansione precedente. Se non si verica alcuna situazione di errore, il nuovo nodo è abilitato a trasmettere i beacon per la nuova PAN, ad intervalli pari al BI (beacon interval). In gura 4.1 è mostrato il diagramma di sequenza della azioni relative alla creazione del nodo Coordinator e della nuova PAN, con l'interazione tra gli oggetti SSCS, MAC e PHY Attivazione di nodo Device L'attivazione di un nodo Device avviene tramite il comando $node sscs startdevice con il quale viene invocato il metodo SSCS802_15_4::start- Device. SSCS eettua una chiamata al metodo MLME-SCAN.request per operare una scansione passiva del canale, grazie a cui è possibile determinare la presenza di nodi coordinator mentre stanno trasmettendo pacchetti di beacon. Come nel caso precedente, le informazioni contenute nei pacchetti di beacon ricevuti vengono memorizzate in una lista di descrittori. Quando viene invocata la primitiva MLME-SCAN.confirm con lo stato di SUCCESS dal parte del MAC, la lista di descrittori viene processata e SSCS seleziona il PAN Id della PAN e setta opportunamente i campi della MPIB prima di proseguire con la procedura di associazione. Quest'ultima prevede l'invocazione della primitiva MLME-ASSOCIATE.request, tramite la quale viene inviato un apposito comando di richiesta di associazione con la modalità

64 Capitolo 4. Le reti WPAN in NS-2 54 Figura 4.1: Diagramma di sequenza per l'inizializzazione di una nuova PAN

65 Capitolo 4. Le reti WPAN in NS-2 55 CSMA-CA. A seguito dell'invio del comando di richiesta, il MAC resta in attesa di un messaggio di acknowledgement: se il messaggio non viene ricevuto entro un tempo prestabilito, viene restituito un messaggio di notica al livello superiore. La ricezione del messaggio di acknowlegmenent non implica immediatamente l'eettiva associazione del nodo: infatti il livello SSCS del device attende per macresponsewaittime simboli un messaggio di association response: questo viene inviato dal nodo coordinator al quale viene richiesta l'associazione quando verica la eettiva possibilità di associare alla PAN un nuovo nodo. Se il coordinator conferma l'associazione del nodo device, fornisce a quest'ultimo un indirizzo a 16-bit (macshortaddress). In seguito all'invio di un pacchetto di acknowledgement, che notica la corretta ricezione del pacchetto di association response, il livello MAC del nodo device invoca la primitiva MLME-ASSOCIATE.indication per indicare al livello SSCS l'esito della procedura di associazione. Quando il nodo risulta eettivamente associato al PAN Coordinator, SSCS invoca la primitiva MLME-SYNC.request per dare inizio ad una procedura di sincronizzazione con il coordinator. Tale sincronizzazione viene realizzata sempre grazie all'invio dei pacchetti di beacon da parte del nodo coordinator: il device infatti abilita il transceiver in ricezione ad intervalli regolari e attende la ricezione di un pacchetto di beacon per abasesuperframeduration (2 n 1) simboli. Se non viene ricevuto nessun beacon recante lo stesso PANId del nodo, la ricerca viene ripetuta per un numero di tentativi pari a amaxlostbeacons. Se il pacchetto di beacon viene rilevato entro il tempo e il numero di tentativi stabiliti, il livello MAC invoca la primitiva MLME-BEACON-NOTIFY.indication per indicare che la sincronizzazione è avvenuta con successo. Se nessun beacon viene rilevato, il livello MAC notica una perdita di sincronizzazione mediante la primitiva MLME-SYNC-LOSS.indication. 4.3 La trasmissione dati su banda garantita In seguito alle operazioni di associazione e sincronizzazione, il nodo device può iniziare a trasmettere e ricevere pacchetti nella PAN. L'unico meccanismo di trasmissione dati in una PAN beacon-enable implementato nel package WPAN è slotted CSMA-CA, che come visto nel capitolo 3 non è adatto per il supporto di applicazioni real-time. L'aspetto più importante di questo lavoro di tesi è stata la realizzazione del supporto al meccanismo di

66 Capitolo 4. Le reti WPAN in NS-2 56 accesso senza contesa (CFP) previsto dallo standard, mediante l'implementazione dei GTS, e delle primitive necessarie all'allocazione e deallocazione degli stessi Aspetti implementativi e modiche Per la realizzazione del meccanismo GTS, sono state introdotte nel package WPAN le strutture dati necessarie a modellizzare, relativamente al sottocampo dei GTS, il contenuto del pacchetto di beacon e del pacchetto di comando. GTSDescriptor contiene le informazioni relative al singolo descrittore di GTS: struct GTSDescriptor { UINT_16 devaddr16; UINT_8 slotspec; } // --(0123):GTS starting slot // --(4567):GTS length GTSField implementa la lista di descrittori di GTS. Per ogni pacchetto di beacon possono essere inseriti sino a un massimo di 7 descrittori come previsto dallo standard. struct GTSFields { UINT_8 spec; UINT_8 dir; //GTS specification // --(012): GTS descriptor count // --(3456): reserved // --(7): GTS permit //GTS directions // --( ): // for up to 7 descriptors: //1 = receive only //0 = transmit only // --(7): reserved

67 Capitolo 4. Le reti WPAN in NS-2 57 }; GTSDescriptor list[7]; //GTS descriptor list GTSSpec contiene la lista di descrittori inserita nel pacchetto di beacon e viene utilizzata per processare le informazioni di ogni singolo descrittore. struct GTSSpec { GTSFields fields; }; UINT_8 count; bool permit; bool recvonly[7]; UINT_8 slotstart[7]; UINT_8 length[7]; //GTS descriptor count //GTS permit //reception only //starting slot //length in slots GTSChar rappresenta il campo GTSCharacteristics del pacchetto di comando utilizzato in fase di richiesta di allocazione o deallocazione: struct GTSChar { UINT_8 specific; // GTS Characteristic // -- (0123) GTS Length // -- (4) GTS Direction // -- (5) GTS Characteristic Type // -- (67) Reserved UINT_8 gtslength; bool gtsdirection; bool gtschartype; } Implementazione del database Per consentire la gestione dei descrittori dei GTS, è stata realizzata una struttura dati che implementa un database. In fase di progettazione del

68 Capitolo 4. Le reti WPAN in NS-2 58 database il requisito fondamentale è stato quello di implementare un modulo di gestione dati in grado di consentire l'inserimento e l'estrazione dei GTS in modo agevole. La classe gtsdb implementa il database e permette al nodo Coordinator di conoscere sia i GTS disponbili che quelli allocati. Lo stesso database è presente nel livello MAC del nodo Device ma le informazioni da gestire in questo caso sono minori. Il database contiene due liste di oggetti di tipo gtselem: gtslist : contiene le informazioni relative a GTS allocate che sono correntemente utilizzate dai device e partecipano alla realizzazione del CFP; gtsinactivelist : contiene le informazioni relative a GTS deallocate le quali devono essere noticate ai rispettivi nodi. La classe gtselem contiene tutte le informazioni associate ad un descrittore di GTS ed è organizzata in due moduli: Modulo informazione : mantiene le informazioni sul descrittore allocato e in particolare: lo slot iniziale del GTS(starting_slot), il numero di slot che lo costituiscono (lenght), l'indirizzo del device che ha richiesto il GTS (devaddre16 ), la direzione associata al GTS (direction). Modulo gestione : mantiene informazioni necessarie al corretto utilizzo del GTS allocato e alla gestione dello stesso. Di particolare importanza sono le informazioni riguardanti: l'istante d'inizio del GTS (start_timer), la dimensione in secondi del GTS allocato (gts_capability). Ad ogni gtselem viene inoltre associata una coda di dimensione unitaria, pkt_pending, in modo tale da permettere la memorizzazione temporanea di un pacchetto che richiede di essere trasmesso in modalità CFP quando il GTS non è ancora attivo: contestualmente viene memorizzato lo stato della primitiva MCPS-DATA.request nella variabile pkt_status, per permettere a quest'ultima di proseguire dal punto della sua interruzione.

69 Capitolo 4. Le reti WPAN in NS-2 59 Sono inoltre presenti due oggetti timer: start_ e stop_. Infatti l'attivazione di un GTS e la sua terminazione avvengono per mezzo di timer, con handler diversi in base al tipo di GTS allocata. Quando scade il timer associato ad un GTS in trasmissione, il relativo handler estrae un pacchetto pendente dalla coda del gtselem (se presente). In seguito eettua una richiesta al livello PHY per attivare il transceiver radio in trasmissione e invoca la primitiva MCPS-DATA.request del MAC per richiedere l'invio del pacchetto precedentemente estratto. Invece quando scade il timer associato ad un GTS in ricezione, il relativo handler eettua una richiesta al livello PHY per attivare il traceiver radio in ricezione. I metodi implementati nella classe gtsdb per la gestione delle informazioni in esso contenute sono: insert(...): inserisce un nuovo gtselem nella gtslist. creategtsspec(struct* GTSSpec): inizializza la struttura GTSSpec passata come paramentro con i valori contenuti all'interno del database. I vari campi della struttura vengono inizializzati con le informazioni contenute nella gtslist, relativamente ai descrittori. Ogni volta che un descrittore è inserito in una GTSSpec, il campo ntimes, inizializzato al valore amaxdescpersistencetime, viene decrementato. Quando raggiunge il valore zero, il descrittore conserva la sua posizione nella gtslist, ma non viene più inserito nella struttura GTSSpec. Se il numero di descrittori all'interno della gtslist è inferiore a sette, i restanti descrittori della GTSSpec vengono riempiti con le informazioni presenti nella gtsinactivelist, no al raggiungimento del numero massimo consentito. Tale metodo viene invocato dal livello MAC prima della costruzione del pacchetto beacon. settimers(...): attiva tutti i timer relativi ai GTS presenti nella gtslist e riempie il campo gts_capability. Tale metodo viene invocato dal livello MAC subito dopo la trasmissione del pacchetto di beacon, al ne di sincronizzare l'attivazione dei timer con quelli dei rispettivi device. findactivegts(...): eettua una ricerca all'interno della gtslist

70 Capitolo 4. Le reti WPAN in NS-2 60 per vericare la presenza di un GTS in trasmissione o in ricezione precedentemente attivato. Il livello MAC invoca tale metodo ogniqualvolta sia necessario trasmettere un pacchetto nel CFP per determinare se il GTS associato sia attivo o meno. checkexpired(...): decrementa il valore del campo gtschance che indica il numero di possibilità di utilizzo del GTS prima che venga deallocato: quando tale campo raggiunge il valore zero, il descrittore di GTS viene estratto dalla gtslist e inserito nella gtsinactivelist per indicare al nodo che lo utilizzava in precedenza l'avvenuta deallocazione. Il metodo viene invocato dopo ogni trasmissione del pacchetto di beacon. Il nodo Coordinator accede al proprio database di GTS: 1. quando, tramite la ricezione di un pacchetto di comando, è richiesta l'allocazione o la deallocazione di un GTS, al ne di aggiornare lo stato del database. 2. prima dell'invio di un pacchetto di beacon, per costruire il sottocampo GTSSpec. 3. ogni volta che riceve un pacchetto da parte di un nodo con GTS allocato, per aggiornare la possibilità di utilizzo del relativo GTS. Figura 4.2: Diagramma delle classi che costituiscono il database GTS

71 Capitolo 4. Le reti WPAN in NS Primitive e metodi implementati Le primitive GTS di MLME Le primitive implementate per la gestione della allocazione/deallocazione dei GTS sono: MLME-GTS.request: primitiva invocata dal livello SSCS per richiedere al MLME del livello MAC l'invio di un comando di richiesta di allocazione o deallocazione. MLME-GTS.confirm: primitiva utilizzata dal MLME per noticare al livello superiore il risultato derivante da una procedura di richiesta di allocazione o deallocazione avviata mediante la primitiva MLME- GTS.request. MLME-GTS.indication: primitiva utilizzata da livello MLME per noticare al livello superiore eventuali modiche sullo stato dei GTS allocati. In particolare di seguito verrà descritta in dettaglio l'implementazione della primitiva MLME-GTS.request su cui si basa l'intero meccanismo. Questa primitiva, come la maggior parte di quelle presenti nel package WPAN, è strutturata secondo vari step. Ogni singolo step rappresenta una elaborazione al termine della quale viene eettuata una sotto-richiesta, tipicamente corrispondente con l'invocazione di una primitiva di interfaccia del livello PHY o di una funzione specica del livello MAC. Le informazioni, relative allo stato della primitiva MLME-GTS.request, presenti nella struttura dati taskpending sono elencate nel listato seguente: bool UINT_8 char UINT_8 bool UINT_8 mlme_gts_request; mlme_gts_request_step; mlme_gts_request_frfunc[81]; mlme_gts_request_gtscharacteristics; mlme_gts_request_securityenable; mlme_gts_request_gtssuperframetimes; Il metodo dispatch(), invocato al termine di una sottorichiesta, utilizza tali informazioni per vericare lo stato di esecuzione di una primitiva e per consentire a quest'ultima di proseguire dal punto in cui era stata interrotta.

72 Capitolo 4. Le reti WPAN in NS-2 62 In particolare il campo mlme_gts_request_frfunc contiene l'identicativo della sottorichiesta invocata dalla primitiva prima di interrompere il proprio usso di esecuzione. Anché la primitiva venga riattivata, il valore di tale campo deve coincidere con l'identicativo della funzione che ha invocato il metodo dispatch(). Gli step seguiti dalla primitiva MLME-GTS.request sono: step 0 : viene vericata l'eettiva associazione del nodo ad un PAN Coordinator, mediante controllo sull'indirizzo macshortaddress a 16-bit memorizzato nella MPIB in seguito alla procedura di associazione. 1. Se il nodo non dispone di un macshortaddress, viene invocata la primitiva MLME-GTS.conrm con stato NO_SHORT_AD- DRESS ad indicare che il device non è associato a nessun PAN Coordinator. 2. Se il device dispone di un (macshortaddress) valido, viene costruito un MSDU contentente un pacchetto di comando GTS con le informazioni del parametro GTSCharacteristics. In seguito viene invocato il metodo csmabegin() per procedere al tentativo di trasmissione del pacchetto di comando in modalità slotted CSMA-CA. step 1 : viene controllato il risultato della scansione del canale mediante CSMA-CA, codicato mediante uno stato. 1. Se il canale è libero (stato uguale a p_idle), viene eettuata una richiesta di trasmissione del pacchetto di comando al livello PHY, mediante abilitazione in trasmissione del trasceiver radio, invocando la primitiva PLME-SET-TRX-STATE.request con parametro TX-ON. 2. Se il canale è occupato dalle trasmissioni di altri nodi e il meccanismo di accesso al mezzo fallisce, viene invocata la primitiva MLME-GTS.conrm con stato CHANNEL_ACCESS_FAI- LURE. step 2 : in seguito alla trasmissione del pacchetto di comando, MLME attende la ricezione del pacchetto di acknowlegment per un tempo pari a macackwaitduration simboli. In questo caso viene abilitato il

73 Capitolo 4. Le reti WPAN in NS-2 63 transceiver radio in ricezione invocando la primitiva PLME-SET-TRX- STATE.request con parametro RX-ON. step 3 : se il pacchetto di acknowledgement viene ricevuto entro il tempo di attesa stabilito, le azioni seguenti dipendono dal tipo di richiesta eettuata nel pacchetto di comando: Se il campo gtschartype è settato, ossia si tratta di una richiesta di allocazione, MLME si pone in attesa di ricezione del pacchetto di beacon contentente la conferma di allocazione del GTS richiesto. Se il campo gtschartype non è settato, ossia si tratta di una richiesta di deallocazione, il pacchetto di acknowledgement notica la conferma della avvenuta deallocazione e pertanto viene invocata la primitiva MLME-GTS.conrm con stato NO_DATA. Se il pacchetto di acknowledgement non viene ricevuto, MLME eettua un nuovo tentativo di invio del pacchetto di comando riportando lo stato della primitiva allo step 1, no ad un numero di tentativi pari a amaxframeretries. Se il numero di tentativi possibili è stato esaurito, viene invocata la primitiva MLME-GTS.conrm con stato NO_ACK. step 4 : dopo che le azioni descritte negli step precedenti hanno avuto esito positivo, la primitiva MLME-GTS.request permane in questo step per un numero pari a agtsdescpersistencetime ricezioni del pacchetto di beacon. Se allo scadere del numero di ricezioni stabilito, il campo GTSSpec presente nel pacchetto beacon non contiene un descrittore di GTS consistente con la richiesta eettuata nel pacchetto di comando, viene invocata la primitiva MLME-GTS.confirm con stato pari a NO_DATA ad indicare che l'allocazione ha avuto esito negativo. Se il campo GTSSpec presente nel pacchetto di beacon contiene un descrittore di GTS coincidente con la richiesta eettuata nel pacchetto di comando e indirizzo associato coincidente con quello del nodo, il descrittore viene memorizzato nel database se il campo slotstart risulta essere diverso da zero; contestualmente viene invocata la primitiva MLME-GTS.confirm con stato pari a

74 Capitolo 4. Le reti WPAN in NS-2 64 SUCCESS. Se lo slot iniziale del GTS è pari a 0, viene invocata la primitiva MLME-GTS.confirm con stato pari a DENIED, ad indicare che l'allocazione è stata negata Metodi di supporto al meccanismo GTS A supporto del meccanismo dei GTS sono stati introdotti diversi metodi, tra i quali si possono citare i seguenti: checkchangesingts(): questo metodo verica che all'interno del pacchetto beacon sia presente un descrittore che notichi una eventuale modica dello slot iniziale del GTS. Questa situazione può vericarsi quando il PAN Coordinator intende deallocare un GTS (lo slot iniziale sarà posto al valore 0), oppure a causa della rilocazione dei GTS dovuta al un procedimento di deallocazione che interessa un altro nodo (in tal caso lo slot iniziale verrà aggiornato al valore opportuno). canproceedgts(): questo metodo viene invocato all'interno della primitiva MCPS-DATA.request per vericare la possibilità di invio del pacchetto nel GTS attivo. Infatti la trasmissione di un pacchetto all'interno del CFP può avvenire solo se l'intero procedimento di trasmissione viene concluso entro la durata del GTS. In particolare il metodo aggiorna il valore del gts_capability del descrittore di GTS contenuto nel database, decrementandolo di una quantità pari alla dierenza tra l'istante in cui il pacchetto è pronto per essere trasmesso e l'istante in cui il GTS è iniziato. In seguito verica che la durata della transazione di invio transac sia inferiore alla valore di gts_capability. Infatti transac risulta essere: transac = T tx + T prop + IF S oppure, nel caso sia richiesta la trasmissione del pacchetto di acknowledgement: transac = T tx + 2 T prop + T tx_ack + IF S dove i vari contributi temporali sono:

75 Capitolo 4. Le reti WPAN in NS T tx : tempo di trasmissione del pacchetto pari al rapporto tra la dimensione del pacchetto e il rate di trasmissione; 2. T prop : tempo di propagazione del segnale nel mezzo trasmissivo; 3. IF S: tempo di elaborazione del pacchetto al nodo ricevente, il quale dipende dalla dimensione del pacchetto stesso; 4. T tx_ack: tempo necessario alla trasmissione del pacchetto di acknowledgement. In caso aermativo, il pacchetto potrà essere trasmesso e il valore di gts_capability verrà decrementato della quantità transac, altrimenti la trasmissione verrà posticipata al prossimo GTS Trasmissione mediante GTS Come illustrato nella sezione , la trasmissione dati viene realizzata mediante una chiamata alla primitiva MCPS-DATA.request: tramite il parametro TxOption viene indicata la modalità di trasmissione richiesta per il tipo di pacchetto. Nel package WPAN, il pacchetto viene ricevuto dal livello MAC a seguito della chiamata della funzione recv(), la quale a sua volta invoca la primitiva MCPS-DATA.request con l'opzione di trasmissione richiesta. La versione nativa di WPAN prevedeva il settaggio della modalità trasmissiva tramite in comando OTcl inserito nello script di simulazione e tutti i dati venivano trasmessi utilizzando la suddetta modalità. Pertanto, in questa fase iniziale di sviluppo del meccanismo di CFP, l'opzione di trasmissione è stata associata al valore di un campo, FlowID, contenuto nell'header IP del pacchetto da trasmettere: se questo è pari ad un opportuno valore scelto dall'utente, l'opzione di trasmissione del pacchetto viene settata opportunamente dalla funzione recv() prima dell'invocazione della primitiva MCPS-DATA.request. Di conseguenza si può vericare che una sorgente invii pacchetti dati sia durante il CAP sia, se dispone di un GTS valido, durante il CFP. La primitiva MCPS-DATA.request è stata modicata per supportare la modalità trasmissiva tramite GTS: gli step seguiti dalla primitiva sono: step 0 : vengono controllate le informazioni contenute nell'header del pacchetto da trasmettere e settata la modalità trasmissiva utilizzata. Un MPDU avente come payload il pacchetto proveniente dal livello superiore (MSDU), viene creato tramite la funzione constructmpdu(). A

76 Capitolo 4. Le reti WPAN in NS-2 66 questo punto, tramite la funzione checkgtstx(), la primitiva verica che il GTS in trasmissione sia attivo: in caso aermativo, la primitiva prosegue con lo step sucessivo. in caso negativo, il pacchetto e lo stato della primitiva vengono memorizzati nell'oggetto gtselem associato al descrittore di GTS. step 1 : la primitiva si trova in questo step quando un GTS è attivo o in seguito allo scadere del timer che determina l'inizio del GTS. Per procedere con la trasmissione del MPDU, viene chiamata la funzione canproceedgts che verica se l'intera transazione di trasmissione possa essere conclusa prima del termine del GTS allocato: in caso aermativo, la primitiva PLME-SET-TRX-STATE.request viene invocata con parametro TX_ON per procedere con la trasmissione del MPDU. in caso negativo, il pacchetto e lo stato della primitiva vengono memorizzati dell'oggetto gtselem associato al descrittore di GTS: in questo modo la trasmissione del pacchetto viene posticipata alla prossima attivazione del GTS. step 2 : la trasmissione del pacchetto può richiedere l'attesa di un eventuale messaggio di acknowledgement da parte del nodo ricevente: se è stato richiesto il messaggio di acknowledgement, viene invocata la primitiva PLME-SET-TRX-STATE.request con parametro RX_ON per abilitare il tranceiver radio in ricezione. se non è richiesto il pacchetto di acknowledgement, la procedura di invio può essere conclusa: viene invocata la primitiva MCPS- DATA.confirm con stato pari a SUCCESS. step3 : la primitiva attende la ricezione del pacchetto di acknowlegment per un tempo pari a macackwaitduration simboli: se il pacchetto viene ricevuto entro il tempo stabilito, il pacchetto pendente contenuto nell'oggetto gtselem associato al GTS viene cancellato a notica dell'avvenuta trasmissione, e la primitiva termina la sua esecuzione invocando MCPS-DATA.confirm con stato pari a SUCCESS.

77 Capitolo 4. Le reti WPAN in NS-2 67 se il pacchetto non viene ricevuto, MCPS-DATA.request eettua un nuovo tentativo di invio del MPDU, riprendendo la procedura dallo step 1. Il numero massimo di tentativi di invio è pari a amaxframeretries. se il numero massimo di tentativi di invio del pacchetto è stato superato, la primitiva termina cancellando il pacchetto e invocando la primitiva MCPS-DATA.confirm con stato pari a NO_ACK. L'accesso alle funzionalità descritte precedentemente può avvenire tramite lo script di simulazione. Nel seguente listato sono mostrati i comandi da inserire nello script di simulazione per abilitare il nodo Coordinator ad allocare i GTS e per permettere ai nodi Device di eettuare una richiesta di allocazione/deallocazione. $node sscs startpancoord <txbeacon=1> <BO=3> <SO=3> <GTSPerm=0> $node sscs startgts <GTSReq=1> <GTSLen=1> <GTSDir=0>

78 Capitolo 5 Uno scenario applicativo soft real-time: il tracking distribuito 5.1 Introduzione al tracking distribuito In questo lavoro di tesi si è scelto di simulare una semplice applicazione di tracking distribuito per valutare i beneci derivanti dall'introduzione del meccanismo di CFP e studiare il comportamento di una rete di sensori secondo un'ottica real-time. Grazie ai miglioramenti in campo hardware, è possibile disporre di sensori con una capacità computazionale in grado di consentirne l'utilizzo anche per applicazioni che richiedono molte risorse computazionali, come nel caso dell'object detection. Un'applicazione di tracking distribuito prevede il posizionamento di nodi di rilevazione in punti strategici dello spazio (sensor planning). Questi nodi sono dotati di una microcamera e di un apposito rmware grazie ai quali sono in grado di rilevare il movimento di un oggetto e inviare un report al nodo controllore. Supponendo che lo scopo del tracking sia quello determinare se un oggetto abbia o meno eettuato un certo percorso, dall'integrazione dei report spediti sulla rete sarà possibile decifrare il percorso dell'oggetto, nonché predire la posizione in istanti futuri o misurarne la velocità. Una applicazione di questo tipo prevede che i nodi forniscano i risultati

79 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 69 delle rilevazioni entro dei limiti temporali precisi e deniti. In ambito realtime questo signica tenere in considerazione non soltanto i tempi necessari alla comunicazione sulla rete, ma anche quelli legati all'elaborazione sulla CPU. Una volta ricevuti i vari report, il nodo coordinatore può elaborarli in base a un prolo di rilevazione scelto. Naturalmente il signicato di ogni report fornito dai nodi al controllore dipende anche dal tipo di protocollo implementato per la rilevazione: il semplice protocollo implementato in questa fase di studio prevede la denizione di una nestra temporale di rilevazione chiamata Protocol Timeout utilizzata per accettare i messaggi di report provenienti dai vari nodi. Tale nestra temporale può essere attivata dalla ricezione di un report proveniente da un nodo ben determinato, oppure essere attivata periodicamente da un timer hardware sul controllore. Quando la nestra di rilevazione viene chiusa, il nodo controllore può processare i report ricevuti e eseguire delle azioni in base ai risultati ottenuti, come ad esempio, cambiare il set-point di un ipotetico sistema di controllo oppure attivare un dispositivo di emergenza. 5.2 L'applicazione di tracking L'architettura del nodo base di NS-2 è stata estesa per poter simulare il comportamento del sistema operativo, in modo tale da non trascurare nella fase di analisi i tempi necessari al nodo per elaborare i dati di ingresso e per richiedere al processore l'esecuzione delle operazioni di invio e ricezione dati. Pertanto l'agente e l'applicazione connesse al nodo sono state estese con le funzionalità fornite dalle classi RTAgent e RTNSApp denite in RTNS. Tutti i nodi utilizzati nella simulazione dispongono di un sistema operativo, di una CPU, e di uno scheduler: quest'ultimo viene utilizzato dal sistema operativo per gestire l'attivazione dei processi in base alla politica più opportuna come FCFS o FP. Il prototipo del Kernel viene realizzato mediante l'astrazione della politica di scheduling e l'accesso alle risorse del nodo. L'esecuzione di una attività nel nodo corrisponde all'attivazione di un Task consistente in un numero di istruzioni predenito. Quando il nodo deve eseguire una attività, il task relativo viene attivato e inserito nella coda dei processi attivi da parte del sistema operativo, in attesa di essere schedulato. L'esecuzione di una attività non è pertanto istantanea, ma occupa un tempo

80 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 70 nito e parametrizzato in RTApp. Inoltre prima di essere eseguito il task deve attendere l'attivazione e la terminazione dei task che sono stati inseriti nella coda precedentemente o che hanno una priorità maggiore di quella del task stesso. L'applicazione denita nel nodo simula il comportamento del rmware che gestisce il nodo stesso. Essa è costituita da una serie di attività che sono organizzate in due moduli di task: Modulo di networking : costituito da task che si occupano dell'invio e della ricezione dei pacchetti nella rete. I task di questo modulo sono di tipo aperiodico, costituiti da un numero di istruzioni costante, come spiegato nella sezione 3.4, e la loro attivazione viene forzata quando deve essere trasmesso o ricevuto un pacchetto. Modulo computazionale : costituito da task che simulano le attività del processore connesse all'acquisizione delle immagini e alla elaborazione delle stesse. I task di questo modulo sono periodici e in particolare simulano l'attività della camera e l'elaborazione delle immagini in seguito all'acquisizione delle stesse. Gli oggetti descritti in seguito sono implementati dalle classi IPApp, IPAgent (gura 5.1) per quanto riguarda il nodo mittente, coordagent e coordapp (gura 5.2) per il nodo coordinator. I Task di invio e ricezione sono implementati rispettivamente dalle classi sendtask, e receivetask. La classe camera implementa l'astrazione della microcamera installata sui nodi device mentre la classe Image rappresenta l'oggetto in movimento nella scena. Per consentire la gestione delle informazioni provenienti dai vari nodi, sono stati introdotti i concetti di: Vista che identica l'angolo solido catturato dalla microcamera; Scena che identica il contenuto attuale di tutte le viste. Se le microcamere dei nodi sono orientate verso la stessa parte di scena, la vista risultante è la stessa per tutti i nodi e questo permette di avere un certo grado di ridondanza sugli eventi che si vericano in quella porzione dello spazio. Inoltre per rappresentare il contenuto del pacchetto di report è stato introdotto un nuovo header di pacchetto, hdr_image contente le informazioni

81 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 71 Figura 5.1: Diagramma di classi degli oggetti IPApp e IPAgent Figura 5.2: Diagramma di classi degli oggetti coordagent e coordapp

82 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 72 riguardanti l'identicativo dell'oggetto rilevato (che come detto precedentemente corrisponde all'istante della creazione dello stesso) e l'identicativo della vista Applicazione e Agente Come anticipato nella sezione 3.4, le classi RTAgent e RTNSApp sono state implementate per estendere le funzionalità oerte rispettivamente della classi Agent e Application di NS-2 e fornire al nodo l'astrazione del sistema operativo e della gestione dei task. Le classi che sono state implementate per la realizzazione dello scenario simulativo sono: IPAgent : derivata dalla classe RTAagent. Essa ridenisce il metodo send- Done(), invocato ogniqualvolta viene eseguito il sendtask, il quale genera un pacchetto di report, per ogni immagine contenuta in memoria nel vettore storedimages. Se la dimensione del pacchetto di report provenitente dall'applicazione risulta maggiore della packet_size massima denita dall'agente, esso viene frammentato in pacchetti di dimensioni pari a quella supportata. Inoltre nel costruttore è prevista la chiamata al metodo imagefactory() per la generazione degli oggetti in movimento come verrà descritto in seguito. IPApp : derivata dalla classe RTNSApp. L'attributo storedimages simula la memoria che contiene le immagini rivelate dall'oggetto cam. Tramite il metodo createapplicationtasks() vengono inizializzato un task di tipo IPTask; mentre tramite il metodo createnetworktasks() vengono creati i task relativi al modulo di networking. Altri metodi implementati nella classe sono: elaborateimage(): implementa la procedura di elaborazione delle immagini rilevate dalla camera; activatesend(): attiva il task di invio sendtask. CoordAgent : derivata dalla classe RTAgent. L'attributo pto_ rappresenta il protocol-timeout, ossia la nestra di rilevazione entro la quale vengono accettati i messaggi di report trasmessi. Gli attributi starting_node e start_tracking vengono utilizzati per determinare quando riattivare

83 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 73 l'inizio del protocol-timeout: il primo attributo in particolare rappresenta l'indirizzo di un nodo che viene usato come trigger per attivare la ricezione dei report all'interno della nestra di rilevazione. La ne del protocol-timeout è determinata dallo scadere del timer cpt: il relativo handler invoca il metodo FillEvent() per processare tutti i dati raccolti. Altri metodi implementati sono: elaboratereport(): che viene utilizzato per determinare il percorso eettuato da un oggetto in base alle informazioni contenute nei report raccolti all'interno di una nestra di rilevazione. recvdone(): che memorizza le informazioni contenute nel pacchetto ricevuto: è invocato dalla CoordApp quando il task di ricezione ReceiveDataTask viene eseguito. recv(): che viene invocato ogni volta che viene ricevuto un pacchetto; a sua volta richiama il metodo recv della classe CoorApp per attivare il task di ricezione. CoordApp : derivata dalla classe RTNSApp. Ridenisce il metodo create- NetworkTasks() al ne di attivare solo il task receivetask. Per il coordinator infatti non sono previste operazioni di invio di pacchetti Il modulo di networking Il modulo di networking viene realizzato mediante il metodo create- NetworkTasks(), implementato nella classe RTNSApp, ed è costituito da due task: il sendtask che simula le istruzioni necessarie alla generazione di un pacchetto da inviare nella rete, e il receivetask che invece simula la ricezione. Quando un pacchetto deve essere trasmesso, l'applicazione attiva il task di invio che viene inserito nella coda dei processi attivi in attesa di essere schedulato. La ne dell'esecuzione del task, dopo il tempo necessario al suo completamento, viene comunicata all'agente collegato all'applicazione, il quale può trasmettere il pacchetto richiesto inviandolo al livello sottostante: in questo modo viene simulato il tempo necessario alla generazione del pacchetto di report. Quando un pacchetto deve essere ricevuto, l'agente attiva il task di ricezione dell'applicazione, per simulare la procedura di ricezione e l'inserimento del pacchetto in memoria prima di essere processato. Dopo la schedulazione del task e la sua terminazione, l'agente può processare il

84 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 74 pacchetto ricevuto: in questo modo viene simulato il tempo necessario alla procedura di ricezione del pacchetto. Inoltre per gestire l'inserimento e l'estrazione di pacchetti, i nodi sono stati dotati di una memoria che può essere limitata oppure innita (come nel caso della simulazione in esame). Tutti i dati ricevuti o trasmessi vengono inseriti in memoria prima della relativa operazione La microcamera Per simulare l'acquisizione di una immagine, il nodo che eettua la trasmissione dei report è stato equipaggiato con un oggetto camera, che simula un dispositivo di acquisizione video. L'oggetto camera è implementato dalla classe Camera; gli attributi left_- corner_posx_, left_corner_posy_, e square_size_ deniscono l'angolo solido di rilevazione della camera mentre il framerate di acquisizione è determinato dal periodo di attivazione di IPTask. Inne l'attributo view_ identica la vista all'interno della scena che come si vedrà in seguito servirà ad descrivere il percorso seguito dall'oggetto in movimento. La rilevazione di un oggetto da parte della camera avviene tramite il metodo detect(): esso verica che la posizione dell'oggetto risulti interna all'angolo solido di rilevazione della camera Oggetti in movimento L'oggetto che si muove all'interno della scena è rappresentato dalla classe Image. Gli attributi posx_ e posy_ rappresentano le coordinate x e y della posizione iniziale dell'oggetto, mentre gli attributi vx_ e vy_ la rispettive componenti di velocità. L'oggetto è identicato mediante l'attributo time che rappresenta l'istante di apparizione nella scena. Il movimento dell'oggetto avviene all'interno di un piano x, y. Tramite la funzione membro ImageFactory() viene generato un numero variabile di oggetti caratterizzati da tempi di apparizione diversi nella scena: essi vengono memorizzati in ordine di creazione nel vettore globale img. I tempi di apparizione degli oggetti possono essere generati in maniera deterministica (attraverso un le di traccia) oppure in maniera statistica, secondo una distribuzione di probabilità che ne denisce il tempo di inter-arrivo. Per gestire l'apparizione degli oggetti nella scena viene utilizzato il timer TimerImage; il numero di oggetti

85 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 75 attualmente presenti nella scena ad ogni istante è rappresentato dal contatore cnt, che rappresenta anche l'indice nel vettore img dell'ultimo oggetto apparso. Il timer TimerImage viene inizializzato con l'istante temporale di creazione del primo oggetto: quando esso scade, il relativo handler incrementa il contatore cnt e schedula nuovamente il timer con un valore temporale pari alla dierenza tra l'istante di apparizione del nuovo oggetto e di quello precedente. Il movimento degli oggetti viene realizzato tramite l'utilizzo di un secondo timer, TimerSpeed, che viene schedulato periodicamente: esso aggiorna la posizione di tutti gli oggetti presenti nel vettore img a partire dal primo sino a quello avente indice pari a cnt. L'aggiornamento viene eettuato solo se entrambe le coordinate x e y dell'oggetto sono interne alla griglia che rappresenta lo scenario. Quando la posizione di un oggetto risulta interna all'angolo di rilevazione della camera, quest'ultima è in grado di rilevarlo. Naturalmente la velocità dell'oggetto e il framerate della camera incidono sulla probabilità di rilevazione dell'oggetto: ad esempio, se l'oggetto è troppo veloce rispetto al frequenza di acquisizione della camera la probabilità che esso non venga rilevato è molto alta Il modulo computazionale Nel modulo computazionale è previsto il task periodico, implementato dalla classe IPTask, che simula l'acquisizione delle immagini. Quando il task viene creato, il suo periodo è impostato sul valore pari all'inverso del framerate della camera. Il corpo del task è costituito dall'istruzione getimage(), che simula l'acquisizione di tutte le immagini rilevate dalla camera e l'inserimento in memoria delle stesse. L'attivazione del task consiste nell'inserimento di un evento nella coda di Metasim. Quando lo scheduler processa il task, viene simulata l'esecuzione dell'istruzione getimage(), la quale occuperà la CPU per un certo numero di tick: la simulazione dell'esecuzione viene completata con invocazione del metodo elaborateimage() (denito nella classe IPApp), che simula il comportamento delle istruzione getimage() ovvero I/O della camera. Il metodo elaborateimage(), tramite la chiamata alla funzione detect() della classe Camera, processa tutti gli oggetti contenuti nel vettore img a partire dal primo no a quello di indice cnt. Se un oggetto viene rilevato, esso è inserito nella coda storedimage e contestualmente viene in-

86 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 76 crementato il valore del contatore imagedetected (entrambi attributi della classe IPApp). La ne dell'esecuzione del task è rappresentata dall'invocazione del metodo onend() della classe IPTask: questo eettua l'attivazione del task di invio sendtask un numero di volte pari al valore di imagedetected. Inoltre per rappresentare il contenuto del pacchetto di report è stato introdotto un nuovo header di pacchetto, hdr_image contente le informazioni riguardanti l'identicativo dell'oggetto rilevato (che come detto precedentemente corrisponde all'istante della creazione dello stesso) e l'identicativo della vista Invio di un report Alla creazione dell'applicazione, il task iptask viene attivato per la prima volta e inserito nella coda dello scheduler di Metasim, in attesa di essere schedulato. Quando lo scheduler assegna la CPU al task, le istruzioni getimage() vengono eseguite e viene simulato il tempo necessario all'acquisizione delle immagini da parte della camera. Il comportamento delle istruzioni è rappresentato dal metodo elaborateimage() della classe IPApp. Al termine di IPTask, per ogni immagine rilevata viene invocato il metodo activate- Send() della classe IPApp, la quale a sua volta provvede all'attivazione del task di invio SendTask. Quest'ultimo, dopo il tempo necessario alla schedulazione e all'esecuzione del task di invio, invoca il metodo senddone() della classe IPAgent, con il quale viene generato il pacchetto contenente il report da trasmettere: questo viene fornito al livello MAC e trasmesso al nodo destinatario. La gura 5.3 riassume quanto descritto Ricezione di un report La ricezione di un pacchetto da parte dell'agente nel nodo coordinatore avviene mediante l'invocazione del metodo recv() di CoordAgent eettuata dal livello MAC. Al ne di attivare il task che simula la ricezione del pacchetto, CoordAgent invoca il metodo recv() della classe CoordApp: in tal modo, mediante una chiamata alla funzione activate(), il task ReceiveDataTask viene attivato e inserito nella coda dei processi attivi di Metasim. In seguito alla sua schedulazione ed esecuzione, il task ReceiveDataTask invoca il me-

87 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 77 Figura 5.3: Diagramma di sequenza della procedura di invio di un report todo recvdata() della classe CoordApp: la ne dell'operazione di ricezione del pacchetto viene noticata al CoordAgent mediante invocazione al metodo recvdone(). La sequenza delle azioni che vengono eseguite quando viene ricevuto un pacchetto di report è illustrata in gura Lo scenario di tracking Lo scenario studiato prevede il posizionamento di quattro nodi lungo un percorso denito. Le camere dei 4 nodi sono orientate in modo da avere viste ortogonali tra loro, come mostrato in gura 5.5. Un quinto nodo assolve al compito di coordinatore. La topologia WPAN utilizzata è quella a stella in modalità beacon-enable per consentire la procedura di associazione al PAN Coordinator e la trasmissione mediante CAP e CFP. Il PAN Coordinator invia pacchetti di beacon con valore di BO = 4 e SO = 4: pertanto non è prevista una fase di inattività all'interno del superframe. Durante la simulazione gli oggetti entrano dal margine sinistro della griglia lungo il percorso, proseguendo orizzontalmente. In corrispondenza del nodo 1, in modo casuale, possono cambiare direzione. Le microcamere dei nodi rilevano un oggetto che attraversa la propria porzione di scena e inviano il pacchetto di report al nodo coordinatore. Per ogni oggetto che passa sulla scena si avranno sino a un massimo di 3 report che possono essere processati per identicare uno dei due possibili percorsi scelti dall'oggetto. La logica del coordinatore, implementata mediante il metodo elaboratereport() citato precedentemente,

88 Capitolo 5. Uno scenario applicativo soft real-time: il tracking distribuito 78 Figura 5.4: Diagramma di sequenza della procedura di ricezione di un report Figura 5.5: scenario della simulazione