Controllo della Qualità del Servizio in applicazioni distribuite con vincoli real-time per reti wireless di sensori Candidato: Francesco Piga Relatori: Prof. P. Ancilotti Prof. G. Lipari Dott. P. Pagano Università di Pisa Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Pisa, 2 Ottobre 2008

Sommario Introduzione Cenni sullo standard IEEE802.15.4 Supporto traffico soft real-time Ambiente di simulazione Il simulatore RTNS (Real-Time Network Simulator) Implementazione meccanismo GTS (Guaranteed Time Slots) Analisi simulativa Scenari simulati Risultati ottenuti Conclusioni

Introduzione Le reti wireless di sensori Prima: applicazioni di monitoraggio (logging) Ora: applicazioni multi-tasking distribuite basate su RTOS Applicazioni distribuite time-sensitive Sistema operativo Scheduling Allocazione di risorse (memoria) Rete Supporto traffico real-time QUALITY OF SERVICE (QoS) Simulatore + Applicazione distribuita

LO STANDARD IEEE802.15.4 Velocità massima 250 kb/s = 62.5 ksym/s @ 2.4GHz (codifica 16-aria , 1sym = 4 bits); Struttura a superframe (beacon-enabled, 16 slot): Periodo inattivo Periodo attivo CAP (Contention Access Period) slotted CSMA-CA CFP (Contention Free Period) GTS (max 7) Traffico real-time

Traffico real-time: allocazione GTS La richiesta di allocazione di GTS da parte di nodo Device: primitiva MLME-GTS.request invio di comando richiesta (GTS request) Numero di slot Direzione Notifica di allocazione Slot iniziale nel CFP

Traffico real-time: deallocazione GTS Deallocazione Esplicita Pan Coordinator Device Deallocazione Implicita Il PAN Coordinator deve prevedere la rilocazione dei GTS Massimizzare durata del CAP

Il simulatore NS-2 E’ stato scelto NS-2 perché: Molto diffuso nella comunità scientifica C++/OTcl Nato per simulazione wired… …estensione CMU per nodo wireless Supporto per 802.15.4 nativo ( v2.28 in poi) Simulatori NS-2 OPNET QualNet Tranport 75% 18% 7% Network 70% 12% MAC & PHY 42% 26% 22%

RTNS (Real-Time Network Simulator) Il package WPAN in NS-2 Sviluppato da: J. Zheng, Samsung (Cuny) CSMA-CA Beacon e Sincr. Assoc. e Disassoc. TX Diretta e Indiretta Filtraggio Modello errore ED CCA LQI Filtraggio Canali multipli MECCANISMO GTS RTNS (Real-Time Network Simulator)

Supporto al meccanismo GTS in NS-2 Strutture dati: Descrittore di GTS GTSDescriptor Lista Descrittori GTSField Pacchetto beacon GTSSpec Pacchetto di comando GTSCharacteristic Comandi di accesso: $node sscs startPANCoord <txBeacon=1> <BO=3> <SO=3> <GTSPerm=0> $node sscs startGTS <GTSReq=1> <GTSLen=1> <GTSDir=0> Realizzazione primitive MLME: MLME-GTS.request MLME-GTS.confirm MLME-GTS.indication Realizzazione database Classe gtsElem Descrittore GTS e timer sincronizzazione Classe gtsDB Lista descrittori GTS allocati e deallocati

Il database dei GTS Presente sia sul nodo PAN Coordinator che sul Device Progettato in modo da: Consentire l’allocazione e la deallocazione dei GTS Consentire la costruzione del campo GTSFields nel beacon Massimizzare CAP in caso di rilocazione dei GTS Interrogato dal PAN Coordinator e dai Device Attivare timer di sincronizzazione nel CFP Interrogato dal PAN Coordinator Allocare/Deallocare un GTS Invio pacchetto di beacon

Simulatore RTNS (Real-Time Network Simulator) Sviluppato presso ReTiS Lab Integra le funzionalità di NS-2 con quelle offerte da Metasim RTLib Evento speciale rtns-event Inserito nella coda NS-2 all’istante t Processa tutti gli eventi di RTSim sino all’istante t. Il nodo RTNS Modulo computazionale Altre attività di elaborazione Modulo di rete Task di invio e ricezione

Applicazione di tracking distribuito (topologia a stella, beacon-enabled) [0] [1] [2] Camera Vista Scena Oggetto in movimento Report di rivelazione Metriche QoS valutate: [3] [C] (Latenza) (Efficienza)

Protocollo di rivelazione L’elaborazione dei report è basata su una finestra di rivelazione Il nodo coordinatore elabora i report per identificare il percorso effettuato dall’oggetto Finestra attivata in 2 modi: Time-based Tramite un timer periodico Event-based In seguito alla ricezione di un report dal nodo trigger (nodo 0)

Scenari simulati Scenario Taxiway Scenario Market

Scenario TAXIWAY confronto Event-based e Time-based (al variare della dimensione della finestra di rivelazione) (1) Modalità Event-based efficienza degrada Report suddivisi in finestre di rivelazione diverse! Modalità Time-based efficienza migliora Aumenta probabilità di rivelazione nella stessa finestra

Scenario TAXIWAY confronto Event-based e Time-Based (al variare della dimensione della finestra di rivelazione) (2) Il ritardo di rivelazione è dettato dalla dimensione della finestra di rivelazione. Nel caso time-based è inferiore perché l’attivazione è scorrelata dall’evento. Tempo di attesa per processare report relativo all’evento è mediamente inferiore

Scenario TAXIWAY – Event-based confronto tra CSMA-CA e GTS (con presenza di nodi di disturbo) Set-point a piena efficienza (pto = 7 sec) Presenza di 2 nodi che generano traffico best-effort Efficienza degrada con CSMA-CA Backoff ritarda trasmissione Collisioni Efficienza garantita con GTS

Scenario TAXIWAY – Event-based confronto tra scheduling FCFS – FP Set-point a piena efficienza e uso GTS (pto = 7 sec) Presenza di task di carico (periodico) sulla CPU dei nodi rivelatori Condizione di sovraccarico (U > 1) Perdita efficienza fino al 50% Aumento latenza di 50 volte!

Scenario MARKET – Event-based confronto tra CSMA-CA e GTS Il comportamento non dipende più dalle caratteristiche della rete Entrambi i meccanismi congestionati dal tipo di traffico Aumenta la probabilità che il report del nodo “trigger” non attivi la finestra… … report in finestre diverse non vengono processati

Scenario Market – Event-based confronto tra CSMA-CA e GTS (con frammentazione dei pacchetti) Set-point a piena efficienza (pto = 20 sec) Dimensione massima: 100 bytes Frammentazione dei report In CSMA-CA aumenta sensibilità: Perdita ordinamento Collisioni Impossibilità di accesso al mezzo

Conclusioni Tramite l’analisi simulativa è stato validato il funzionamento del meccanismo di GTS implementato su RTNS. E’ inoltre stato dimostrato come la QoS di una applicazione soft real-time distribuita dipenda pesantemente: Attività del RTOS (scheduling) Attività della rete (management di banda) Entrambi gli aspetti DEVONO essere considerati per la valutazione di performance del sistema.

Grazie per l’attenzione