MUS.E. BT MUSic Everywhere with BlueTooth

1. MUS.E. BTMUSic 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

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

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

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

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

6. Architettura del sistema CLIENT PROXY SERVER Requests: ForwardStreamRequest Stop Requests: Stream,Stop,Handoff High,Normal,Low Velocity Proxy Manager Single SessionData ServerManager Session Manager SessionData S E S S I O N N C S O C K S StreamRequestThread StreamRequestThread HandoffManager SingleSessionManager SingleSessionManager SessionCommSender SingleSessionThread SingleSessionThread Response: Confirm Responses: Confirm, RewindComplete AckSender Single SessionData Ports Set Ack Receiver Ports Set FlowLevel Manager FlowLevel Manager FLOW FlowLevel Manager ControlFlow Thread ControlFlow Thread Buffer Controller Buffer Controller RTP stream RTP stream RTP JMFClient ClientControl JMFProxy JMFServer Circular Buffer Circular Buffer UNIBO Package

7. Protocollo: caratteristiche di base • 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” PROXY SERVER CLIENT 1 1 2 2 7 7

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

9. 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, notconnected, 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.

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

11. 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 nonforniscono 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.

12. Sequenza dei messaggi 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 HARD HANDOFF SCENARIO Server 2 Proxy 1 Proxy H 3 8 1 4 11 5 10 7 9 5 10 6 9 NCSOCKS Handoff likelihood high NCSOCKS Handoff initiated

13. Messaggi di gestione: rewind & co. • La richiesta di rewind permette al Client di recuperare i frames inevitabilmente persi durante l’handoff ProxyH Client Proxy1 Stream Frame 99 Stream Frame 99 Ricezione ack Inizio handoff Frame 100 Frame 101 Frame 102 Frame 100 Frame 101 Frame 102 Frames persi Fine handoff Rewind (100) Rewind ack Timeout Frame 100 Frame 101 Frame 102 Ricezione 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

14. 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 Request RequestKind=0, richiesta iniziale. Proxy SessionPort Proxy FlowPort Proxy RTPPort ID 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” ID Request 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 Response

15. 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 Request Kind ID Timestamp Request RequestKind=1, richiesta di rewind. Timestamp: relativo all’ultimo frame ricevuto dal Proxy1. “rewindOK” Response • 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 SlowDown Normalize Accelerate “accelerate” “low” “normal” • Il fatto che i messaggi viaggino su canali separati e che la loro frequenza sia tutto sommato bassa rendono non necessaria una loro bufferizzazione.

16. 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! • 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! • Questo scenario è già supportato dal formato dei messaggi “increase RewindWindow” e “rewind”.

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

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

19. Architettura del sistema CLIENT PROXY SERVER Requests: ForwardStreamRequest Stop Requests: Stream,Stop,Handoff High,Normal,Low Velocity Proxy Manager Single SessionData ServerManager Session Manager SessionData S E S S I O N N C S O C K S StreamRequestThread StreamRequestThread HandoffManager SingleSessionManager SingleSessionManager SessionCommSender SingleSessionThread SingleSessionThread Response: Confirm Responses: Confirm, RewindComplete AckSender Single SessionData Ports Set Ack Receiver Ports Set FlowLevel Manager FlowLevel Manager FLOW FlowLevel Manager ControlFlow Thread ControlFlow Thread Buffer Controller Buffer Controller RTP stream RTP stream RTP JMFClient ClientControl JMFProxy JMFServer Circular Buffer Circular Buffer UNIBO Package

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

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

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

23. 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).

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

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

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

27. Memoria e CPU • Non vengono utilizzati algoritmi di codifica • Rendering del contenuto multimediale semplificato

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

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

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

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

32. Sommario • Livello Flow e QoS • descrizione funzionalità • Livello RTP • streaming audio • classi • Prove sperimentali • Conclusioni

33. Architettura del sistema CLIENT PROXY SERVER Requests: ForwardStreamRequest Stop Requests: Stream,Stop,Handoff High,Normal,Low Velocity Proxy Manager Single SessionData ServerManager Session Manager SessionData S E S S I O N N C S O C K S StreamRequestThread StreamRequestThread HandoffManager SingleSessionManager SingleSessionManager SessionCommSender SingleSessionThread SingleSessionThread Response: Confirm Responses: Confirm, RewindComplete AckSender Single SessionData Ports Set Ack Receiver Ports Set FlowLevel Manager FlowLevel Manager FLOW FlowLevel Manager ControlFlow Thread ControlFlow Thread Buffer Controller Buffer Controller RTP stream RTP stream RTP JMFClient ClientControl JMFProxy JMFServer Circular Buffer Circular Buffer UNIBO Package

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

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

36. 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 diQoS

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

38. 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)creaun RTPReceiver(Unibo) fa partire invio dati(Unibo) CLIENT

39. …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

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

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

42. 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: • si appoggia alle funzionalità del package Unibo • 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. • realizza i meccanismi di rewind e di variazione della velocità di trasmissione comandati dai livelli superiori

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

44. Prove Sperimentali

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

46. 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!!!