1 / 13

Progetto MUSE MUSic Everywhere

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:

Download Presentation

Progetto MUSE MUSic Everywhere

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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 • Possibilità di handoff (legata alla mobilità dei disposivi client)

  3. 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 Internet Server HandoffManager Architettura del sistema Proxy-Server protocol Media Req Media Req RTP streaming RTP streaming Media Req Notti magiche.mp3 Sunrise.mp3 Spirito.wav ... RTP streaming NACK (last frame) Client Handoff prevision

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

  5. Streaming Server • Mantiene le risorse di interesse per il servizio (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 messaggi protocollo Proxy-Server • Transport layer: creazione e gestione della sessione RTP

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

  7. 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  Aspetto centrale del sistema!

  8. Politiche di handoff Sono state considerate due politiche di handoff: Reattiva: minimizza il numero degli handoff   tempi più lunghi di handoff (ricerca nuovo AP)  Proattiva: aumenta il numero degli handoff   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

  9. 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 WirelessDeviceManager Schema componenti principali per la previsione HandoffManager GreyPrediction

  10. … 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! L’utente si allontana dall’AP, la potenza del segnale diminuisce… Notifica al client Predizione handoff HANDOFF Previsione REATTIVA

  11. ...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 L’utente si allontana dall’AP, la potenza del segnale diminuisce… Notifica al client Predizione handoff Previsione PROATTIVA (soft/hard)

  12. 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

  13. Fine Progetto MUSE MUSic Everywhere

More Related