Progetto MUSE MUSic Everywhere Presentazione di Leardini Francesco Reti di calcolatori LS

Scopo del progetto Realizzare un sistema in grado di fornire un servizio continuo di audio streaming su rete wireless verso device mobili. Garantire QoS  particolare attenzione a: Perdita pacchetti trasmessi Perdita pacchetti trasmessi Possibilità di handoff Possibilità di handoff (legata alla mobilità dei disposivi client) (legata alla mobilità dei disposivi client)

Architettura del sistema Server Internet Notti magiche.mp3 Sunrise.mp3 Spirito.wav... RTP streaming Media Req Proxy-Server protocol Presenti tre livelli: Server - Proxy – Client Soluzione proy-based  svincola il Server da alcune funzioni ( adattamento in banda )  risolve al meglio le esigenze specifiche del client HandoffManager Handoff prevision Client NACK (last frame)

Componenti realizzati All’interno del progetto sono stati realizzati individualmente le seguenti entità: Streaming server Predittore dell’handoff Meccanismo per le notifiche al client

Streaming Server Mantiene le risorse di interesse per il servizio (sotto forma di file audio: wave, mp3) (sotto forma di file audio: wave, mp3) Trasmette i media on-demand aprendo una sessione RTP per ogni richiesta (  protocollo Proxy-Server) Sviluppato su due livelli (  in base alle responsabilità) Session layer: gestione richieste di servizio e scambio dei Session layer: gestione richieste di servizio e scambio dei messaggi protocollo Proxy-Server messaggi protocollo Proxy-Server Transport layer: creazione e gestione della sessione RTP Transport layer: creazione e gestione della sessione RTP

Protocollo Proxy-Server GET(mediaID, RTPport)  Permette di richiedere un file audio specificando: specificando: ID del brano (conoscenza statica) ID del brano (conoscenza statica) Porta RTP di ascolto sul Proxy Porta RTP di ascolto sul ProxyGet_ok  Conferma la ricezione della richiesta In seguito viene trasmesso lo stream In seguito viene trasmesso lo stream

Importanza della previsione La previsione consente di avviare un’azione proattiva a fronte di un possibile handoff: Ridimensionamento del buffer (client/proxy) per creare una “riserva” di frame e far fronte all’eventuale periodo di disconnessione Ridimensionamento del buffer (client/proxy) per creare una “riserva” di frame e far fronte all’eventuale periodo di disconnessione  Aspetto centrale del sistema!

Politiche di handoff Sono state considerate due politiche di handoff: Reattiva :  minimizza il numero degli handoff Reattiva :  minimizza il numero degli handoff  tempi più lunghi di handoff (ricerca nuovo AP)   tempi più lunghi di handoff (ricerca nuovo AP)  Proattiva :  aumenta il numero degli handoff   riduzione tempi di handoff (eseguo prima ricerca AP)  riduzione tempi di handoff (eseguo prima ricerca AP) Ampia libertà concessa ai costruttori di schede wireless nella scelta dell’una o dell’altra strategia  Adottata per le previsioni una una scheda Intel/pro (politica reattiva)  Considerate entrambe le politiche per la previsione

Schema componenti principali per la previsione WirelessDeviceManager Interagisce con la scheda, interrogandola per desumere dettagli circa l’AP corrente e la lista di quelli visibili, i valori dei relativi RSSI, ecc. HandoffManager Componente attivo di primaria importanza. Coordina tutte le entità che cooperano alla previsione dell’handoff per realizzare le diverse strategie di previsione. GreyPrediction Implementa il modello di Grey utilizzato per filtrare i valori degli RSSI rilevati Predizione handoff

Previsione REATTIVA Predizione handoff L’utente si allontana dall’AP, la potenza del segnale diminuisce… … se il valore del segnale rilevato scende al di sotto della soglia stabilita  predizione handoff  notifica la client CASO 2 L’utente torna sui propri passi, il segnale torna a migliorare  Torniamo al contesto iniziale CASO 1 L’utente esce dalla cella relativa all’AP cui è attualmente connesso  handoff! HANDOFF Notifica al client

Previsione PROATTIVA (soft/hard) Predizione handoff L’utente si allontana dall’AP, la potenza del segnale diminuisce…...viene rilevata un nuovo AP Caso SOFT-PROACTIVE Notifica previsione handoff se: nuovo RSSI migliore dell’isteresi – ε valore RSSI attuale scadente (in base alla soglia stabilita) Caso HARD-PROATCIVE Il nuovo AP ha un valore del segnale migliore dell’isteresi – ε  Predizione handoff  Notifica al client Notifica al client

Conclusioni Prototipo funzionante Definizione protocolli ad-hoc Implementazione protocollo RTP-R Possibilità di fronteggiare periodi in assenza di segnale di circa 4 sec (1000÷1600 ms, nei casi peggiori 2000 ms, per ripristinare la connessione ) Totale trasparenza di ritrasmissione, handoff e dimensionamento dei buffer

Fine Progetto MUSE MUSic Everywhere