Servizi continui su rete IEEE 802.11 – Music Everywhere Presentazione di Alberto Mercati Reti di Calcolatori LS.

Presentazione sul tema: "Servizi continui su rete IEEE 802.11 – Music Everywhere Presentazione di Alberto Mercati Reti di Calcolatori LS."— Transcript della presentazione:

1 Servizi continui su rete IEEE 802.11 – Music Everywhere Presentazione di Alberto Mercati Reti di Calcolatori LS

2 Scenario applicativo: adattamento di servizi continui a reti wireless Servizi continui  Problemi su reti IP: come garantire QoS? Problemi delle reti wireless  Perdita di pacchetti  Handoff del client Caratteristiche dello scenario  Servizio di streaming fornito da server legacy  Rete Wi-Fi con più Access Point  Hard horizontal handoff

3 Architettura del sistema Mobile client Internet Proxy RTP streaming Streaming Server RTP streaming Circular Buffer RTP streaming QoS monitoring Ritrasmissione Architettura a 3 livelli  Server  Client  Proxy (intermediario) Due livelli di buffering  Client  Proxy Proxy fornisce supporto a:  Mobilità  Ritrasmissione  …

4 Punti fondamentali RTP-Retransmission: è una proposta di estensione del protocollo RTP (Real Time Protocol), studiata per la ritrasmissione di pacchetti persi  Non compromette il corretto funzionamento di RTP (compreso RTCP)  Funziona anche con intermediari che non implementano RTP-R Adattamento in banda del servizio: transcodifica dinamica dello stream audio per adattarsi a mutazioni delle condizioni operative (congestioni, handoff prediction, ecc…) Cosa ho fatto io?  Progetto e implementazione del sottosistema di buffering (lettura/scrittura, riproduzione, ecc…)  Progetto ed implementazione del Proxy  Studio dell’adattamento in banda  Cosa NON ho fatto: Server, Client, monitoring dello stato della rete lato Client e predizione di handoff, implementazione del supporto a RTP-R

5 Buffering Il buffering sul Client è la soluzione normalmente adottata per risolvere:  Jitter  Perdita di pacchetti  Arrivo fuori sequenza DataSource Parser DynamicCircularBuffer FrameWindow Multiplexer write read DataSource Ottenuta tramite il supporto JMF ad RTP Disponibile per utilizzo tramite JMF Funzionalità del buffer  Proxy (finestra nascosta, reperimento frame): ActiveRTPBuffer.  Client (inserimento fuori seq, riproduzione): PlayerBuffer.  Utilizzo delle “metafore” proprie di JMF (classe DataSource) ActiveRTPBuffer PlayChain PlayerBuffer

6 Funzionamento del sistema MUSE Client Fisso  Non si verifica handoff  Ci possono essere occasionali perdite di pacchetti 0123 Proxy bufferClient buffer 012 NACK 2 Finestra nascosta

7 Funzionamento del sistema MUSE Client mobile  Previsione di handoff  Congestione  Diminuzione di banda 2345 Proxy bufferClient buffer Handoff prediction, Congestione, ecc… 01 2345 A parità di banda e memoria impiegata, abbiamo una durata maggiore della riproduzione Transcodifica dinamica del payload dei pacchetti RTP

8 Funzionamento del sistema MUSE 345 Proxy bufferClient buffer 012 Handoff 345 012 Client mobile  Handoff  Ripristino sessione: impiego del supporto per RTP-R Finestra nascosta

9 Funzionamento del sistema MUSE Proxy bufferClient buffer 012345 012678 NACK 3 NACK 4 NACK 5 345 Client mobile  Handoff  Ripristino sessione: impiego del supporto per RTP-R Finestra nascosta

10 Funzionamento del sistema MUSE All’occorrenza i buffer devono comportarsi come due “vasi comunicanti”, eventualmente ridimensionandosi Proxy buffer Client buffer Al momento del ripristino dopo un handoff, ci si aspetta che:  Il buffer del Client sia vicino allo svuotamento  Il buffer del Proxy sia di grandi dimensioni e quasi completamente occupato È necessario:  “Scaricare” dati sul Client  Liberare risorse sul Proxy

11 Informazioni di contesto Per tutta la durata del servizio è necessario raccogliere informazioni di contesto per:  Conoscere lo stato del Client  Valutare la QoS  Gestire frame rate Informazioni comunicate dal Client al Proxy tramite opportuni pacchetti KeepAlive:  Dimensione buffer del Client  Spazio libero e spazio occupato sul buffer  Numero di frame ricevuti dall’inizio della sessione  Numero di sequenza dell’ultimo frame correttamente ricevuto  Tempo equivalente ai dati mediali contenuti nel buffer

12 Test e risultati sperimentali (1) I test riportati illustrano i risultati della parte di progetto di mia competenza Test 1: 1.Ridimensionamento del buffer 2.Gestione della ritrasmissione dopo un handoff

13 Test e risultati sperimentali (2) Test 2: 1.Ritrasmissione di pacchetti persi con RTP-R 2.Combinazione di handoff e perdita di pacchetti

14 Conclusioni Implementazione RTP-R e nuove opportunità offerte ( )  Efficacia della ritrasmissione basata su RTP-R  Nuove opportunità, non solo per reti wireless ma anche per Internet Architettura a tre livelli ( )  Approccio efficace per adattare servizi continui a reti wireless  Nessuna modifica da apportare al servizio originario Impiego di RTP-R per la ritrasmissione dei pacchetti persi durante un handoff ( )  In tutti i test da noi effettuati, RTP-R si è sempre dimostrato in grado di gestire anche la perdita di sequenze di pacchetti consecutivi Le note dolenti  Adattamento in banda (  ): caratteristica non funzionante. Abbiamo incontrato problemi che non siamo ancora riusciti a superare  JMF (  )

15 Servizi continui su rete IEEE 802.11 – Music Everywhere Presentazione di Alberto Mercati Reti di Calcolatori LS FINE