1 / 17

MUSE BT - Client

MUSE BT - Client. Music Everywhere BlueTooth progetto Client. Reti di Calcolatori LS AA 2007-2008. Acquaviva Luca - 231767. Music Everywhere Bluetooth. MUSE BT in 3 Parole: Bluetooth Mobilità Continuità. Specifiche: Erogare un servizio di audio streaming;

aglaia
Download Presentation

MUSE BT - Client

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. MUSE BT - Client MusicEverywhereBlueTooth progetto Client Reti di Calcolatori LS AA 2007-2008 Acquaviva Luca - 231767

  2. Music Everywhere Bluetooth MUSE BT in 3 Parole: Bluetooth Mobilità Continuità Specifiche: • Erogare un servizio di audio streaming; • Utilizzo della tecnologia Wireless Bluetooth; • Mobilità attraverso le reti Bluetooth; Obiettivo: • Continuità del servizio a fronte di handoff orizzontali , rappresentati dallo spostamento del dispositivo da una cella ad un’altra. MUSE BT - Client –Acquaviva Luca

  3. MUSE BT – Sistema • Entità del sistema: • Server • mantiene i file audio mp3; • Proxy • Mediatore tra client e server. • Access Point • Accesso del client al proxy. • Dispositivo mobile (client); • Riproduzione dello stream ricevuto dal proxy. proxy Rtp Lan Bluetooth MUSE BT - Client –Acquaviva Luca

  4. MUSE BT – Infrastruttura di Rete Rtp AP Responsabilità dell’infrastruttura di rete : Trasparenza a livello di rete ; la comunicazione avviene sempre tra client e proxy indipendentemente dall’ap che fornisce copertura. AP AP handoff trasparente Soluzione: uso di bridge sugli AP per uniformare La rete tra proxy e client. MUSE BT - Client –Acquaviva Luca

  5. MUSE BT – Infrastruttura di Rete 2 Proxy IP Proxy ETH0 Problema nascondere al proxy ed al client i vari AP per semplificare la comunicazione. AP ETH0 • Soluzione PAN come bridge tra 2 interfacce ! • Creazione dinamica dell’interfaccia BNEP alla connessione di un client. • Collegamento dinamico tra PAN e BNEP alla creazione della bnep; Un AP gestisce 1 PAN e fino a 7 BNEP. • Collegamento tra PAN e ETH dell’AP. PAN0 BNEP0 Risultato il tutto viene visto come un’unica rete. Proxy e Client comunicano direttamente conoscendo solo i reciproci indirizzi IP. BNEP0 IP Client Client MUSE BT - Client –Acquaviva Luca

  6. Soluzione Proposta CLM & NCSOCKScome infrastruttura di supporto: • Mobility Management: gestione degli handoff che occorrono nel passaggio da un Access Point ad un altro (CLM) • Connection Awareness: conoscenza di tutte le informazioni circa lo stato attuale della connessione (qualità del segnale, probabilità di handoff) (NCSOCKS) Comunicazione: • Protocollo UDP , socket datagram offerte da NCSOCKS. Garanzia di Continuità: • Buffer sul Client che permette la riproduzione durante la situazione di handoff e di disconnessione dal proxy. MUSE BT - Client –Acquaviva Luca

  7. CLM • Mobility Management: Demone lato mobile che monitora costantemente l’area di copertura del device in cerca di AP, e che decide a quale connettersi in base: • Potenza del Segnale. • Banda disponibile. • Risultato: handoff trasparenti al client, eseguiti interamente dal CLM. MUSE BT - Client –Acquaviva Luca

  8. NCSOKCS Supporto per l’Applicazione Client che Offre: Connection Awareness: conoscenza delle informazioni relative allo stato della connessione. • primitive di comunicazione che considerano lo stato della comunicazione (estensione socket datagram) UDP. • funzionalità di notifica delle informazioni di stato della connessione e della probabilità di handoff (Connection Monitor) rilevate dal CLM. MUSE BT - Client –Acquaviva Luca

  9. Client - Buffer Circolare Buffer Circolare Client • Permette la riproduzione durante i vari handoff : continuità del servizio. Oltre la continuità • Riduzione Problemi dovuti al Jitter : sfruttando il ritardo di esecuzione introdotto dal buffer. • Ordinamento frame oltre UDP:I frame ricevuti dal client vengono memorizzati in un buffer circolare ordinandoli in base al loro numero di sequenza, risolvendo la limitazione di UDP. MUSE BT - Client – Acquaviva Luca

  10. Client - Responsabilità • Responsabilità Client: • Attivare la sessione di comunicazione con il Proxy. • Inviare le richieste delle traccie. • Concorrentemente • Ricevere e riprodurre lo stream audio , utilizzando un buffer circolare per garantire la continuità del servizio durante gli handoff . • Monitorare lo stato della connessione gestendo e notificando eventuali handoff. MUSE BT - Client –Acquaviva Luca

  11. Client - Handoff Management Problema : Il proxy non è supportato da NCSOCKS e non ha alcuna informazione sullo stato della connessione del client. Soluzione: monitorare la connessione lato cliente per fare notificare il proprio stato al proxy. • Notifica Probabile handoff (incremento buffer proxy). • Notifica inizio handoff (Sospensione Trasmissione) • Notifica Riconnessione , fine handoff. (Ripresa Trasmissione). APPL. CLIENT Proxy NCSOCKS Sharedmemory CLM MUSE BT - Client – Acquaviva Luca

  12. Client - Interazione Client/Proxy • Dopo una fase iniziale di inizializzazione della sessione. • Stream emesso dal server verso il proxy via rtp. • Proxy inoltra frame per frame tutto lo stream direttamente al client. • Client bufferizza i dati in arrivo e riproduce lo stream Buffer Circolare per Continuità del Servizio e Riduzione del Jitter. Rtp AP AP Variante cosa succede se durante la trasmissione avviene un handoff !? MUSE BT - Client – Acquaviva Luca

  13. Client - handoff !! Durante la normale erogazione del servizio il client si sposta. • Client : Richiesta di Riconnessione il sequencenumber dell’ultimo frame correttamente salvato. • Proxy: Preparazione alla trasmissione a partire dall’ultimo frame ricevuto dal Cliente. • Proxy: Invio di un ack al client. • Client: invio di un ack al proxy. • Proxy: Ripristino trasmissione. Durante la normale erogazione del servizio il client si sposta. • Client : rileva alta probabilità di handoff e la notifica al Proxy. • Proxy: aumento dinamico del buffer. • Client: Inizio handoff notifica al proxy. • Proxy: interruzzione della trasmissione ed attesa di Riconnessione. Rtp AP AP MUSE BT - Client – Acquaviva Luca

  14. Client – Test Andamento del Buffer Fase 1 Precaricamento Buffer. Fase 2 Inizio Riproduzione . Fase 3 handoff e riconnessione al nuovo AP. Inizio handoff : Sconnessione temporanea dal proxy. Fine handoff: Riconnessione al proxy. Andamento del Buffer del Client durante una prova. Prova : erogazione di uno stream audio con handoff ripetuti. Risultato: Continuità del servizio ed evidenza di qualche problema di incertezza di NCSOCKS. MUSE BT - Client – Acquaviva Luca

  15. Conclusioni • Pro • Semplificazione dello sviluppo dell’applicazione. • Handoff trasparenti allo strato applicativo. • Handoff eseguti in tempi limitati , Risparmio di risorse per la bufferizzazione. • Contro • Riscontro di problemi di incertezza nell’inizio di un handoff. • Distribuzione limitata vincolata a sistemi linux. • Difficilmente installabile su dispositivi mobili pda e smartphone. Obiettivo parallelo valutazione di ncsocks. MUSE BT - Client – Acquaviva Luca

  16. Client - Sviluppi Futuri • Estensione ed Inserimento di controlli per il flusso audio; • Adattamento del servizio in base al device; MUSE BT - Client –Acquaviva Luca

  17. Client Fine MUSE BT - Client – Acquaviva Luca

More Related