MUS.E. BT MUSic Everywhere with BlueTooth a proxy based architecture for stream continuity during bluetooth handoffs Authors: Lorenzo Bricchi Simone Cortecchia Guido Vigliotti Corso di Reti di Calcolatori LS – A.A. 2005/2006

Sommario  Obiettivo del progetto  Architettura del sistema  Protocollo di comunicazione  Caratteristiche dei messaggi  Conclusioni e sviluppi futuri

Obiettivo  Rendere possibile l’erogazione di un servizio di audio streaming in reti wireless Bluetooth  Architettura proxy-based  Continuità di servizio Divisione in livelli Uso di buffers circolari

Ipotesi iniziali  Client conosce staticamente l’indirizzo di Server e due Proxies  Server e Proxies collegati da rete cablata  I Proxies hanno conoscenza reciproca  Server invia lo stream ad entrambi i Proxies  Massimo 7 Clients, Proxies interscambiabili

Architettura: progettazione  Suddivisione in livelli di responsabilità Session: crea e gestisce le sessioni, invia e riceve comunicazioni, regola i livelli inferiori Flow: controlla la trasmissione/ricezione, monitora il buffer RTP: realizza lo streaming, gestisce il buffer circolare

UNIBO Package NCSOCKSNCSOCKS S SSESESSSIIOONNSSESESSSIIOONNSION RTPRTPRTPRTP FLOWFLOWFLOWFLOW JMFClient CLIENTPROXYSERVER JMFProxy JMFServer Buffer Controller FlowLevel Manager ControlFlow Thread FlowLevel Manager ControlFlow Thread FlowLevel Manager SessionCommSender Session Manager SessionData HandoffManager SingleSessionThread SingleSessionManager Single SessionData Proxy Manager StreamRequestThread Ports Set SingleSessionThread SingleSessionManager Single SessionData ServerManager StreamRequestThread Ports Set Requests: Stream,Stop,Handoff High,Normal,Low Velocity Responses: Confirm, RewindComplete Requests: ForwardStreamRequest Stop Response: Confirm RTP stream Buffer Controller AckSender Ack Receiver Architettura del sistema Circular Buffer Circular Buffer ClientControl

Protocollo: caratteristiche di base CLIENT PROX Y SERVE R  I messaggi sono scambiati per mezzo di datagrammi UDP  Sul Client è presente una sola porta di sessione  Su Proxy e Server vengono creati all’avvio dei “set” di porte, ciascuno contenente una porta di sessione; inoltre possiedono una porta generale di accettazione richieste  Il Client fa la prima richiesta sulla porta generale; tutte le altre comunicazioni avvengono a livello di “portSet”

1: StreamRequest 2: ForwardStreamRequest 3: Confirm & RTPStream 4: Confirm & RTPStream 5: Ack message sending 1 Server Proxy HProxy Sequenza dei messaggi

Handoff e librerie NCSOCKS  Handoff: passaggio del Client dal Proxy1 al ProxyH  Le librerie NCSOCKS forniscono, su S.O. Linux, connection awareness in termini di stato della connessione, disponibilità, intensità del segnale (RSSI), larghezza di banda e ritardo.  Tre stati per la connessione (connected, not connected, handoff) e cinque livelli di probabilità di handoff: none, low, medium, high e initiated.  Ad ogni variazione di probabilità di handoff, viene scatenato un evento utilizzabile a livello applicativo per decidere i provvedimenti da adottare.

1: StreamRequest 2: ForwardStreamRequest 3: Confirm & RTPStream 4: Confirm & RTPStream 5: Ack message sending 6: High handoff likelihood 1 Server Proxy HProxy NCSOCKS Handoff likelihood high HARD HANDOFF SCENARIO 5 6 Sequenza dei messaggi

Hard handoff scenario  Problema: la tecnologia BT non permette ai dispositivi di avere attive più connessioni contemporanee  Hard handoff.  Non si può avveritire il ProxyH che sta per arrivare un Client, né il Proxy1 che un Client lo sta per lasciare! Le NCSOCKS non forniscono infatti nessun metodo centralizzato con cui un Proxy riesca ad identificare un Client specifico di cui sta perdendo la connessione.  Soluzione: uso di ack e avviso di handoff al ProxyH attraverso il Proxy1.

1: StreamRequest 2: ForwardStreamRequest 3: Confirm & RTPStream 4: Confirm & RTPStream 5: Ack message sending 6: High handoff likelihood 7: Increase resize window proxyH 8: Forward increase & response 9: Handoff initiated, HandoffRequest & RTPStream 10: Ack message sending 11: End of media 1 Server Proxy HProxy NCSOCKS Handoff likelihood high 10 HARD HANDOFF SCENARIO Sequenza dei messaggi NCSOCKS Handoff initiated

Messaggi di gestione: rewind & co.  La richiesta di rewind permette al Client di recuperare i frames inevitabilmente persi durante l’handoff Client ProxyH Proxy1 Stream Frame 99 Ricezione Frame 100 Frame 101 Frame 102 ack Inizio handoff Fine handoff Timeout Frames persi Rewind (100) Stream Frame 99 Frame 100 Frame 101 Frame 102 Rewind Frame 100 Frame 101 Frame 102 Ricezione ack Stream Ricezione  Altri messaggi per la gestione dello stream sono: accelerate: se il buffer del Client si svuota troppo normal: quando il buffer del Client ritorna a livello di regime low: se per qualche motivo si riempie troppo stop: per terminare la ricezione sul Client

Tipologia e formato dei messaggi  Richiesta stream: messaggio sincrono bloccante Client deve attendere la conferma e il portSet Request Kind Session Port Flow Port RTP Port Song RequestKind=0, richiesta iniziale. ID Proxy SessionPort Proxy FlowPort Proxy RTPPort Request Response  Increase resize window: messaggio sincrono bloccante indiretto Attesa della risposta, necessaria per sapere subito il portSet sul ProxyH e fare lo switch più rapidamente in seguito, demandata a un thread separato ID presente per considerazioni su futuri sviluppi “increase” Messaggio già diretto alla porta di sessione assegnatagli dal Proxy. ID necessario (in futuro) per inoltrare la richiesta al ProxyH. ProxyH SessionPort ProxyH FlowPort ProxyH RTPPort ID Request Response

Tipologia e formato dei messaggi  Richiesta rewind: messaggio sincrono bloccante diretto Attesa della risposta, necessaria per essere sicuri l’operazione di rewind è stata completata correttamente, demandata a un thread separato. ID presente per considerazioni su futuri sviluppi  Gestione stream: messaggio asincrono Risposta non necessaria, reinvio su indicazione dei componenti di controllo ID non necessario perché già indirizzati alla porta di sessione corretta ID Request Response Request Kind Timestamp “rewindOK” RequestKind=1, richiesta di rewind. Timestamp: relativo all’ultimo frame ricevuto dal Proxy1. Accelerate “accelerate” Normalize “normal” SlowDown “low”  Il fatto che i messaggi viaggino su canali separati e che la loro frequenza sia tutto sommato bassa rendono non necessaria una loro bufferizzazione.

Creazione sessioni  Perché le sessioni sul ProxyH vengono create su richiesta del Server e non del Proxy1?  A causa dell’ipotesi iniziale di trasmissione contemporanea del Server (che assegna gli ID) ai Proxies  il Client che fa l’handoff deve trovare una sessione con lo stesso ID a cui agganciarsi.  Così facendo però il massimo numero di Clients è sempre 7! QQuesto scenario è già supportato dal formato dei messaggi “increase RewindWindow” e “rewind”.  Scenario più generale: ProxyH crea le sessione e riceve lo stream dal Server solo quando Client fa l’handoff  nessuna garanzia di avere lo stesso ID sul ProxyH (probabilità 1/7)…  …ma centralizzando la conoscenza delle coppie ID-canzone non ci sono comunque problemi: già al messaggio “increase RewindWindow” il ProxyH può creare la sessione e recuperare lo stream  al rewind tutto è già pronto!

Conclusioni e sviluppi futuri  Il protocollo elaborato regola correttamente il sistema garantendo la continuità di servizio prefissata.  Sia i messaggi sia il protocollo sono pronti a supportare una probabile estensione del progetto, quale l’uso di Proxy che ricevano lo stream dal Server solo al momento dell’handoff di un Client. Magari sfruttando le funzionalità di co-location awareness delle librerie NCSOCKS

Sommario  Strutture dati di livello Session Client Proxy e Server  Risorse Hardware: analisi Software: ottimizzazione e riusabilità  Problemi e sviluppi futuri

UNIBO Package NCSOCKSNCSOCKS S SSESESSSIIOONNSSESESSSIIOONNSION RTPRTPRTPRTP FLOWFLOWFLOWFLOW JMFClient CLIENTPROXYSERVER JMFProxy JMFServer Buffer Controller FlowLevel Manager ControlFlow Thread FlowLevel Manager ControlFlow Thread FlowLevel Manager SessionCommSender Session Manager SessionData HandoffManager SingleSessionThread SingleSessionManager Single SessionData Proxy Manager StreamRequestThread Ports Set SingleSessionThread SingleSessionManager Single SessionData ServerManager StreamRequestThread Ports Set Requests: Stream,Stop,Handoff High,Normal,Low Velocity Responses: Confirm, RewindComplete Requests: ForwardStreamRequest Stop Response: Confirm RTP stream Buffer Controller AckSender Ack Receiver Architettura del sistema Circular Buffer Circular Buffer ClientControl

Strutture dati di livello Session  Compiti del livello Session Realizzazione di tutte le funzionalità di livello applicativo. Comunicazione e coordinamento con il livello di rete tramite scambio di messaggi. Definizione di componenti standard e uniformi per affrontare il problema dell’etereogenità e garantire trasparenza nell’utilizzazione dei servizi.

Strutture dati: Client (1)  SessionManager Configurazione dei parametri di comunicazione. Interfacciamento con le librerie NCSOCKS.  SessionComunicationThread Thread per la gestione della comunicazione con il Proxy, modello sincrono.  HandoffThread Thread incaricato di effettuare lo switch tra 2 proxy.

Strutture dati: Client (2)  SessionData Contiene info di sessione quali porte impegnate per la comunicazione, indirizzo dei destinatari, socket utilizzate, etc.  separazione parte statica e parte dinamica.  AckSenderThread Thread per la gestione del protocollo heart-beat  leggero overhead.

Strutture dati: Proxy (1)  ProxyManager Inizializza e gestisce le strutture dati necessarie a tenere traccia dello svolgimento dell’attività: vettore delle sessioni attive, coda dei client in attesa. Operazioni di look-up per trovare PortSets disponibili.  StreamRequestThread Thread in attesa di richieste di servizio (politica FCFS).

Strutture dati: Proxy (2)  SingleSessionManager Gestisce le operazioni relative all’avvio, all’interruzione e alla velocità del flusso audio e quelle di ingrandimento della finestra di rewind.  SingleSessionThread Thread impiegato per una comunicazione bidirezionale verso il server e verso il client: azioni di receive e forward.

Strutture dati: Proxy (3)  AckReceiverThread Dotato di un timer interno che viene azzerato dopo la ricezione di un ack; se scatta il timeout si considera il client non più connesso. RICHIESTE

Analisi risorse fisiche  La CPU è la risorsa più contesa perché viene coinvolta in diverse fasi del recapito della presentazione multimediale.  La memoria: usata per bufferizzare i dati al fine di continuare la riproduzione, anche in presenza di momentanei problemi di trasmissione.  La banda trasmissiva: l'utilizzo degli algoritmi di compressione (MPEG) riduce notevolmente la richiesta di banda mantenendo un buona qualità di riproduzione.

Memoria e CPU  Non vengono utilizzati algoritmi di codifica  Rendering del contenuto multimediale semplificato

Banda trasmissiva  Impiego di banda sul client abbastanza limitato  Utilizzo della restante parte di banda per erogare altri servizi

Ottimizzazione delle risorse software  Buffer dinamico Sul lato proxy la dimensione del buffer viene aumentata a run-time nel momento in cui si avvicina il momento di handoff.  On-Demand Activation Sul lato proxy e client l’attivazione dei processi per la ricezione dello stream avviene su richiesta e solo dopo aver ricevuto opportuni messaggi di conferma a livello di sessione.

Riusabilità delle risorse software  Nel momento in cui termina la trasmissione di uno stream, le strutture dati di un client non vengono distrutte ma riassegnate dal ProxyManager a client in attesa.  Il settaggio dei parametri di comunicazione avviene in fase di creazione dei Manager. riduzione tempi di attesa a run-time

Problemi e sviluppi futuri  Ambienti non noti a priori  discovery dinamico delle risorse.  Nuove funzionalità a livello utente  estensione della semantica dei messaggi senza modificare le entità che si occupano della loro spedizione.  Portabilità dell’applicazione su dispositivi mobili meno evoluti  utilizzo di librerie per la gestione del segnale Bluetooth integrate direttamente nell’hardware dei sistemi.

Sommario  Livello Flow e QoS descrizione funzionalità  Livello RTP streaming audio classi  Prove sperimentali  Conclusioni

UNIBO Package NCSOCKSNCSOCKS S SSESESSSIIOONNSSESESSSIIOONNSION RTPRTPRTPRTP FLOWFLOWFLOWFLOW JMFClient CLIENTPROXYSERVER JMFProxy JMFServer Buffer Controller FlowLevel Manager ControlFlow Thread FlowLevel Manager ControlFlow Thread FlowLevel Manager SessionCommSender Session Manager SessionData HandoffManager SingleSessionThread SingleSessionManager Single SessionData Proxy Manager StreamRequestThread Ports Set SingleSessionThread SingleSessionManager Single SessionData ServerManager StreamRequestThread Ports Set Requests: Stream,Stop,Handoff High,Normal,Low Velocity Responses: Confirm, RewindComplete Requests: ForwardStreamRequest Stop Response: Confirm RTP stream Buffer Controller AckSender Ack Receiver Architettura del sistema Circular Buffer Circular Buffer ClientControl

Il livello FLOW  controlla quanto sta avvenendo durante la trasmissione/ricezione del flusso RTP  gestisce QoS : prima dell’erogazione vengono decisi i valori dei parametri che riguardano il buffer del livello RTP durante lo streaming monitoring del livello del buffer azioni statiche azioni dinamiche

FlowLevelManager  gestisce il livello di flow nel client, nel proxy e nel server  viene creato dai rispettivi livelli di Session quando ci sono le condizioni per avviare lo streaming  crea i componenti di livello RTP, li inizializza e li avvia  fa partire il BufferControllerThread su proxy e client  avvia l’entità di basso livello ClientControl sul client

BufferControllerThread  si occupa di monitorare il livello del buffer di livello RTP  se il limite superiore o quello inferiore vengono superati avverte il SessionManager azione dinamica di QoS

Il livello RTP  realizza lo streaming audio dal server al client utilizzando il proxy come intermediario  utilizza le funzionalità messe a disposizione da: JMF Package Unibo

Streaming audio server-proxy… SERVER PROXY crea DataSource(JMF) crea un RTPSender(Unibo) arrivo frame e inserimento nel buffer crea un processor(JMF) crea RTPMultiplexer(Unibo) crea un RTPSender(Unibo) crea un RTPParser(Unibo) aggiunge endpoint del rx(Unibo) specifica l’endpoint del tx(Unibo) preleva frame dal buffer fa partire invio dati(Unibo) crea un RTPReceiver(Unibo) fa partire invio dati(Unibo) CLIENT

…client CLIENT crea RTPManager(JMF) si mette in attesa di evento ReceiveStream riceve frame audio inizia riproduzione audio crea Parser(Unibo) crea Multiplexer(Unibo) crea un player(JMF) inserisce frame nel buffer preleva frame dal buffer

Client & Server  JMFServer a)crea le strutture dati necessarie alla trasmissione (Processor e DataSource) b)le inizializza, impostando come destinazioni entrambi i Proxy c)avvia lo streaming che prosegue fino al termine del brano o al comando di “stop” arrivato dal Client.  JMFClient a)riceve lo stream come DataSource b)inserisce lo stream nel suo buffer circolare per mezzo di un Parser c)avvia un Multiplexer e la riproduzione audio su un Player.

Client ClientControl avviato dal livello Flow a)intercetta gli eventi JMF scatenati durante il funzionamento del sistema : - StreamMappedEvent - InactiveReceiveStreamEvent, - NewReceiveStreamEvent e ByeEvent b)intraprende le azioni opportune sul JMFClient

Proxy  JMFProxy è il componente più complesso di questo livello, a causa del suo duplice ruolo di destinatario dello stream trasmesso dal Server e di mittente per il Client: a)si appoggia alle funzionalità del package Unibo b)utilizza un Parser per spezzare lo stream (visto come DataSource) ed inserirlo nel CircularBuffer ed un Mutiplexer per ricostruire il flusso da inviare al Client. c)realizza i meccanismi di rewind e di variazione della velocità di trasmissione comandati dai livelli superiori

Prove Sperimentali  Sistemi Operativi :  Windows + pulsanti per simulare handoff  Linux + NCSOCKS  parametri considerati :  TTW (Time To Wait) : tempo, in millisecondi, che il Multiplexer aspetta per prelevare i frames dal buffer e ricostruire il flusso audio  dimensione del buffer

Prove Sperimentali TTW dimensione buffer Client58 ms200 frames.WAV Proxy<=58 ms100 frames Client78 ms200 frames.MP3 Proxy<=78 ms100 frames

Conclusioni(1)  Windows : l’evento di ricezione di un nuovo stream che si manifesta nel momento dell’handoff non viene sempre ricevuto handoff non avviene in maniera ottimale peggioramento della qualità dell’audio riprodotto per un breve lasso di tempo

Conclusioni(2)  Linux ha sempre il comportamento desiderato ma…  …NCSOCKS hanno eccessivi tempi di ricollegamento tra i dispositivi client e proxy non è possibile una continuità di servizio se non con un dimensionamento enorme del buffer sul proxy, ma… …problemi a livello di gestione delle risorse!!!