Post on 01-May-2015
transcript
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