1 MUSE2 Reti di Calcolatori L-S Progetto di un servizio di audio streaming in reti wireless Progetto di un servizio di audio streaming in reti wireless Autore: Andrea Bergamini Progetto in collaborazione con Bambini Stefano e Pierangeli Diego Bologna, 2/11/2006

2 Sommario ► Target Progettuale ► Architettura generale del sistema ► Analisi dell’entità Client ► Gestione dell’Handoff ► Protocolli adottati ► Conclusioni e sviluppi futuri

3 Target progettuale ► Realizzazione di una applicazione distribuita per lo streaming di contenuti audio in reti wireless IEEE (Wi-Fi) verso un dispositivo mobile ► Gestione opportuna di un possibile handoff del dispositivo ► Realizzazione di una infrastruttura di supporto quanto più flessibile e scalabile ► Interesse prevalente nella logica e nell’implementazione dell’architettura del client

4 Architettura del sistema Proxy1 Manager1 SUBNET1 SUBNET2 Manager2 Proxy2 Server Client

5 Analisi dell’entità Client ► Il Client si occupa di interfacciarsi all’end-user fornendo ad esso contenuti audio ► Deve garantire la continuità della sessione anche a fronte di handoff (che può anche prevedere disconnessioni di durata limitata) E’ possibile avere una previsione sempre corretta della sua migrazione? Quali provvedimenti adottare in caso di previsione errata? ► Bisogna effettuare delle scelte progettuali precise in fase di analisi ► A livello implementativo, client realizzato su piattaforma Java standard (J2SE+JMF)

6 Client Proxy / Manager UDP RTP / RTCP Wi-fi Analisi dell’entità Client Comunicazione Interazione del client con i contenuti del server mediata da un proxy (creato da un manager, responsabile di quella subnet) Due livelli: ► RTP / RTCP per il trasporto dei frame audio ► UDP per garantire coordinamento tra le entità (attraverso un protocollo ad-hoc)

7 Wireless Interface Parser Multiplexer Circular Buffer Handoff Monitor Predictor User Interface Client Analisi dell’entità Client Interfacciamento con proxy / manager della subnet Ricezione pacchetti audio e riempimento di un buffer circolare Buffer con struttura a ring: ● Scritture e letture mediante due puntatori (head e tail). ● Gestione di situazioni critiche con condizionamento del flusso in ingresso ● Estensione del componente unibo Estrazione di pacchetti dal buffer e inoltro al JMF per la presentazione Interfacciamento con l’utente finale per la riproduzione dei contenuti audio Monitoraggio dell’handoff, grazie all’uso di un predittore, che cerca di predirre uno spostamento del client da subnet a subnet

8 Protocollo di attivazione del Client Server Client Manager n Proxy n SUBNETn ► E’ il protocollo che gestisce, in una fase iniziale, l’ingresso di un client in una subnet, e che permette ad esso di iniziare lo streaming audio > CREATE_FIRST _PROXY NEW_STREAM_ REQUEST Il Client contatta il Manager di quella subnet per farsi creare un proxy a lui dedicato: uso di una tabella (conoscenza statica) SubnetManag. …… SUB1 SUB2 x.x.x.x Erogazione dei contenuti dal server al client attraverso la mediazione del proxy Client

9 Predizione di Handoff   Obiettivo: intervenire in modo opportuno o a fronte di un’handoff del client, o a fronte di una previsione di handoff.   Il dispositivo client, facendo uso dell’HandoffMonitor, stabilisce politiche di gestione dell’handoff, secondo due modelli: proattivo e reattivo.   Due protocolli per la gestione dell’handoff, a seconda che il predittore effettui una predizione corretta, oppure sbagliata (rientra in quest’ultimo anche il caso che il predittore non effettui nessuna predizione!).   Ad intervalli regolari, l’HandoffMonitor rileva (mediante JWRAPI) l’AP al quale il client è correntemente connesso. La variabile initialAP contiene il MAC dell’AP al quale il client è connesso inizialmente. Se viene rilevato un AP diverso da quello della variabile, ho avuto Handoff → protocollo di predizione sbagliata.

10 Predizione di Handoff   A fronte di una previsione di migrazione individuata dal predittore (per una subnet diversa da quella in cui il client risiede), viene instaurato un opportuno protocollo di handoff, secondo un modello proattivo.   Se dopo un timeout (custom), il MAC dell’AP al quale il client è attualmente connesso (rilevato dall’HandoffMonitor) coincide con quello impostato nella variabile initialAP, la predizione è sbagliata: nessuno spostamento effettivo del client.   Se invece è diverso, vengono instaurati due diversi protocolli, di previsione corretta o errata, a seconda che l’AP rilevato dal predittore coincida o meno con quello al quale il client è attualmente connesso (individuato dall’HandoffMonitor).   Nel primo caso, grazie ad una previsione corretta, e al modello proattivo, rispondiamo in modo immediato alle richieste di flusso del client. Nel secondo caso invece, il protocollo di previsione errata permette, in modo reattivo, di “preparare” la rete di destinazione ad ospitare il client (gestendo anche il suo “deficit” di pacchetti).

11 Previsione di Handoff corretta Manager1 SUBNET1 SUBNET2 Server Client SUBNET3 Proxy1 Manager2Proxy2 Manager3 NEW_AP (SUBNET2) NEW_PROXY _SUBNET > NEW_PROXY _RESPONSE Rilevazione del predittore di una possibile migrazione verso la SUBNET2 Avvertimento al proxy, per fargli iniziare il protocollo di handoff Trasferimento del buffer proxy-to-proxy Streaming audio nella nuova subnet Continuità dello streaming audio anche a fronte di disconnessioni grazie ad un livello di bufferizzazione sul client Migrazione del client nella nuova sottorete: la predizione era corretta STREAM_ REQUEST

12 Previsione di Handoff errata Manager1 SUBNET1 SUBNET2 Server Client SUBNET3 Proxy1 Manager2Proxy2 Manager3Proxy3 > Il client migra verso una sottorete diversa da quella rilevata dal predittore: grazie alla rilevazione dell’HandoffMonitor Bisogna adottare politiche adeguate Il Client contatta il Manager della nuova rete per farsi creare un Proxy a lui dedicato NEW_PROXY PREDICTION _WRONG PROXY_END Protocollo di predizione errata (semplificato) STREAM_ REQUEST

13 Conclusioni e Sviluppi Futuri La sessione sul client è garantita a fronte di un handoff Dai benchmark effettuati si è riscontrato un buono streaming sul client senza interruzioni nell’ascolto, anche a fronte di handoff multipli. Le scelte progettuali adottate garantiscono estendibilità e flessibilità al sistema Sviluppi futuri: Coinvolgimento nel sistema di più entità client (non testato ma predisposizione dell’infrastruttura all’accettazione) Estensione dell’interfaccia utente per permettere la scelta del brano ad un utente → DEMO