Controllo della Qualità del ServizioControllo della Qualità del Servizioin applicazioni distribuite in applicazioni distribuite

con vincoli real-timecon vincoli real-timeper reti wireless di sensoriper reti wireless di sensori

CandidatoCandidato: Francesco PigaFrancesco Piga

Relatori: Relatori: Prof. P. Ancilotti Prof. G. Lipari Dott. P. Prof. P. Ancilotti Prof. G. Lipari Dott. P. PaganoPagano

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+

Applicazionedistribuita

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

1. CAP (Contention Access Period) slotted CSMA-CA

2. 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:1. primitiva MLME-GTS.request 2. invio di comando richiesta (GTS request)

1. Numero di slot2. Direzione

3. Notifica di allocazione1. Slot iniziale nel CFP 2. Numero di slot3. Direzione

Traffico real-time: deallocazione GTS

Deallocazione Esplicita Pan Coordinator Device

Deallocazione Implicita Pan Coordinator

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% 18% 12%

MAC & PHY 42% 26% 22%

Il package WPAN in NS-2

•CSMA-CA•Beacon e Sincr.•Assoc. e Disassoc.•TX Diretta e

Indiretta•Filtraggio •Modello erroreMECCANISMO MECCANISMO GTSGTS

•ED•CCA•LQI•Filtraggio•Canali

multipli

RTNS (Real-Time Network Simulator)

Sviluppato da: J. Zheng, Samsung (Cuny)

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

Totali Oggetti #

Rilevati Oggetti

rilevati Oggetti #1

ievent

N

i

irilev TT

L

(Latenza)

(Efficienza)

Applicazione di tracking distribuito(topologia a stella, beacon-enabled)

Camera

Vista

Scena

Oggetto in movimento

Report di rivelazione

Metriche QoS valutate:

[0] [1] [2]

[3]

[C]

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:

1. Time-based Tramite un timer periodico

2. Event-based In seguito alla ricezione di un report

dal nodo trigger (nodo 0)

Scenari simulati

Scenario Scenario TaxiwayTaxiway

Scenario MarketScenario Market

Scenario TAXIWAYconfronto Event-based e Time-based(al variare della dimensione della finestra di rivelazione) (1)

1. Modalità Event-based efficienza degrada

Report suddivisi in finestre di rivelazione

diverse!

2. Modalità Time-based efficienza migliora

Aumenta probabilità di rivelazione nella stessa finestra

Scenario TAXIWAYconfronto 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-basedconfronto 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-basedconfronto 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