Music Everywhere with BT

Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract In questi ultimi anni, grazie all'evoluzione delle piattaforme computazionali e alla disponibilità di nuove forme di connettività, si sta realizzando la visione del cosiddetto Pervasive Computing, cioè computazione in qualsiasi momento e in qualsiasi posto. Anche la ricerca in campo multimediale si è mossa in questa direzione e sta attualmente affrontando nuove problematiche legate all erogazione di servizi continui in reti mobili quali, ad esempio, il mantenimento della continuità di servizio a fronte di spostamenti dei terminali mobili. Questo progetto si pone in questo ambito con l obiettivo di rendere possibile l erogazione di un servizio di audio streaming in reti wireless Bluetooth (BT), realizzando un applicazione distribuita per lo streaming di flussi multimediali verso dispositivi mobili (Personal Digital Assistant, cellulari ) e collegati all infrastruttura fissa grazie all uso della tecnologia wireless bluetooth. una serie di canzoni sotto forma di file audio, come mp3, un Client che riceve le varie richieste dell utente, riproducendo il file audio richiesto e un Proxy che agisce da mediatore tra Client e Server, ricevendo le richieste dei Client, inoltrandole al Server e ricevendo i flussi audio dal Server, smistandoli ai corretti Client. Grazie all interposizione del Proxy l architettura proposta consente di progettare il Server in modo indipendente dalla specifica implementazione del Client, e permette di decentralizzare (dal Server al Proxy) l esecuzione delle operazioni di ritrasmissione dati che si rendono necessarie a seguito degli spostamenti dei Client fra diverse località wireless. 1. Introduzione Il sistema realizzato è costituito da tre differenti unità: un Server, che mantiene Figura 1: Infrastruttura del sistema progettato 1

Infatti nello scenario preposto un Client può spostarsi all interno della rete bluetooth, passando di volta in volta da un Access Point (in seguito abbrevieremo tale termine in AP) ad un altro. A fronte di questi spostamenti, si possono verificare delle situazioni di discontinuità nella riproduzione dei file audio, dovute alla momentanea disconnessione del Client dagli AP (handoff orizzontali) e la conseguente perdita di pacchetti. Gli obiettivi principali del progetto quindi sono prima di tutto sopperire a tale perdita e garantire continuità del servizio di riproduzione di file multimediali. La relazione è organizzata nel seguante modo. La prima parte descrive l infrastruttura di rete utilizzata. La seconda tratta il livello applicativo, in particolare analizza dettagliatamente il Proxy e i protocolli utilizzati per la comunicazione tra le diverse entità coinvolte. Infine la terza parte espone i test realizzati. Per maggiori dettagli relativi al Server, al Client e alle tecniche utilizzate per la comunicazione tra le entità, si rimanda alle relazioni degli altri componenti del gruppo. connessione dei vari Device al Proxy. In particolar modo questi Access Point sono dei semplici PC, dotati ognuno di un dongle bluetooth. Ogni AP è connesso con tutti gli altri presenti nella rete BT e al Proxy tramite cavo di rete. Per rendere completamente trasparente al livello applicativo il passaggio del Device da un Access Point ad un altro, si è utilizzato NCSOCKS come infrastruttura di rete. NCSOCKS (Nomadic Computing SOCKetS) sono delle API, realizzate presso le Università di Bologna e Napoli, che oltre ai classici servizi di connettività di rete, forniscono informazioni alle applicazioni che hanno necessità di conoscere le condizioni del canale wireless, la locazione del dispositivo e la probabilità di un eventuale handoff. AP ETH0 PAN0 BNEP1 BNEP2 BNEPn 2. Infrastruttura di rete La rete bluetooth che è stata utilizzata nel progetto è composta fondamentalmente da una serie da AP disposti a distanza di circa 15 metri l uno dall altro, che permettono la 2 Client1 BNEP0 PAN0 Figura 2: Architettura di rete tra AP e Client Clientn BNEP0 PAN0

L architettura di rete che viene utilizzata per effettuare la comunicazione tra i dispositivi è mostrata in figura 2. Per la comunicazione dei dispositivi di rete viene utilizzato il protocollo IP, che necessita di un protocollo BNEP per l incapsulamento dei pacchetti da trasmettere sul canale L2CAP. Quando infatti un Device si connette all Access Point, viene creata da entrambi le parti un interfaccia BNEPx (BNEP0 sul Device e BNEPn sull Access Point, con n dipendente dal numero di Device connessi all AP). Lato AP è presente anche l interfaccia ETH0, che garantisce l accesso alla rete interna, permettendo quindi la comunicazione tra tutti gli Access Point e il Proxy. Tutte le interfacce BNEP presenti sull Access Point sono unite tramite un bridge all interfaccia virtuale PAN0, che a sua volta è collegato, sempre con un bridge con l interfaccia ETH0. Con questa struttura, riusciamo quindi ad avere un unica rete alla quale ogni Mobile Device si collega tramite semplicemente una serie di bridge. Per lo scambio di informazioni, richieste e notifiche tra le tre entità coinvolte, si è pensato di utilizzare il protocollo di rete UDP, meno affidabile del TCP, ma che garantisce maggiore velocità alla trasmissione. 3.1. Realizzazione interna 2 Attesa Cnnessione Server New Proxy Session 1 6 4 5 3 3. Proxy Il livello applicativo è composto fondamentalmente da tre entità attive: il Server, che riceve le richieste di streaming di file multimediali, il Proxy che si occupa di fare l intermediario tra il Server e il Device, e infine il Client, che permette al utente di ascoltare le varie canzoni. Figura 3: Funzionamento interno del Proxy In figura 3 è mostrato il funzionamento interno del Proxy. Come si può notare un Thread è sempre in attesa che un nuovo Device faccia richiesta di connessione al servizio. 3

Una volta ricevuta tale richiesta, con i relativi parametri (la porta alla quale dovranno essere inviati tutte le notifiche) (1), viene generato un nuovo Thread (2), al quale viene affidato il compito di servire il Device appena connesso, ricevendo le sue richieste, inoltrandole al Server e viceversa (6). Una volta creata una nuova istanza del Proxy Session, viene, da questo, inoltrata la richiesta del Device al Server, con in aggiunta la porta del Proxy alla quale il Server dovrà inviare i messaggi di notifica (3). Una volta ricevuta la risposta (4), il Proxy Session invia al Device la notifica di avvenuta connessione (5). A questo punto il Device è effettivamente connesso al Server e può quindi richiedere il servizio di audio streaming. Per poter funzionare, ovviamente è necessario che siano note: La porta sulla quale il Proxy è in attesa di nuove connessioni entranti; La porta del Server sulla quale attende nuove richieste di connessione inoltrate dal Proxy; L indirizzo IP del Proxy; L indirizzo IP del Server; Una volta che il Device è connesso, può richiedere una canzone al Proxy. Per inviare il file audio dal Server al Proxy si è penato di utilizzare il protocollo RTP; per quanto riguarda invece l invio tra Proxy e Device, non si è fatto uso di tale protocollo in quanto molti dei Device leggeri attualmente disponibili in commercio non lo supportano ancora. Si è pensato invece di utilizzare una trasmissione di tipo seriale basata direttamente sulle funzionalità rese disponibili dallo stack bluetooth. Dal flusso RTP in ingresso, il Proxy estrae ogni singolo frame della canzone (classe ExtBuffer), per poi inviarlo direttamente al Device usando semplicemente una istanza della classe SocketDatagram. Tuttavia la classe coinvolta nell invio, ExtBuffer, non è una classe serializzabile: si è dovuto quindi ricreare una classe analoga, ma ovviamente serializzabile, in modo tale da poter inviare ogni singolo buffer tramite la SocketDatagram. 3.2. Protocollo di handoff La realizzazione di un protocollo di handoff è risultato necessario per poter effettuare una sorta di sincronizzazione tra Proxy e Device durante le fasi immediatamente precedente, durante e successiva a un handoff. L handoff è una situazione che si verifica quando un Device si sconnette da un Access Point per passare ad un altro il cui segnale viene ricevuto in maniera più robusta. L obiettivo del progetto è, come detto nell introduzione, garantire a fronte di queste situazioni di handoff una continuità di servizio nella 4

riproduzione del flusso audio sul Device. È evidente che durante questa fase di disconnessione tra Proxy e Device, i frame in arrivo dal Server sul Proxy devono essere memorizzati, per poter essere inviati al Device solo successivamente alla sua riconnessione alla rete bluetooth. Per questo quindi si è pensato di far uso nel Proxy di un buffer circolare. Il problema principale legato a questa politica, è sicuramente la gestione delle risorse; è evidente infatti che per poter garantire continuità di servizio è necessario memorizzare un elevato numero di frame (superiore a 100), comportando quindi un ingente occupazione di risorse. Come detto precedentemente però, questa memorizzazione risulta necessaria solo durante la fase di disconnessione del Device dalla rete. Durate la fase di connessione invece, è sufficiente mantenere memorizzati solo pochi frame. Quindi per limitare l occupazione di risorse si è pensato di utilizzare un buffer circolare dinamico, capace di modificare la sua dimensione in base alla probabilità di handoff. A regime infatti la sua dimensione è limitata a poche decine di frame, per aumentare a circa 200 nella fase immediatamente precedente a una disconnessione. Infine ritorna al valore iniziale solo dopo la riconnessione del Device e il riempimento del proprio buffer. In figura 4 è evidenziato lo scambio di messaggi di sincronizzazione che il Proxy e il Device effettuano prima della disconnessione di quest ultimo da un Access Point e dopo la conseguente riconnessione ad un altro. Proxy Frame1 Frame2 Framen Ack Ack Ack Device Disconnect Reconnect Reconnect Reconnect Receive Ack Figura 4: Scambio di messaggi tra Proxy e Device in caso di handoff Dopo una prima fase a regime, in cui il Proxy invia iterativamente i frame della canzone al Client, si può verificare una situazione di handoff in cui il Device si avvicina a una zona in 5

cui la ricezione è relativamente bassa. A questo punto il Device invia un messaggio di Disconnect al Proxy, che interrompe l invio del frame, continuando a ricevere il flusso RTP dal Server, e memorizzando ogni singolo frame nel buffer circolare. Una volta che il Device si è riconnesso ad un Access Point, invia un messaggio di Reconnect, contenente il numero di sequenza del frame dal quale deve ricominciare l invio; quindi il Proxy risponde con un messaggio di Ack. Questa ultima fase, può essere ripetuta diverse volte, in quanto il messaggio di Ack del Proxy può non arrivare a destinazione. La situazione è descritta in figura 5. Figura 5: Connessione tra AP e Proxy Ipotizziamo che il Device passi dalla zona 1 alla zona 2. Tale passaggio è del tutto trasparente al Proxy, che infatti dovrà continuare a inviare i frame alla porta e all indirizzo IP concordati in fase di inizializzazione. Tuttavia è possibile che per il lento aggiornamento delle tabelle di routing, il primo messaggio di Ack, venga instradato ancora alla zona 1, comportando inevitabilmente la 1 2 6 perdita sua ed eventualmente dei primi frame della canzone. Per ovviare a questo problema, si è pensato di inviare iterativamente i messaggi di Reconnect, dal Device al Proxy, e di Ack dal Proxy al Device; non appena quest ultimo lo riceve, invia in risposta un messaggio di Received Ack. Solo alla ricezione di quest ultimo pacchetto il Proxy ricomincia l erogazione dei frame, memorizzati precedentemente nel buffer circolare. Ovviamente il Proxy non può restare in attesa indefinita della riconnessione del Device; infatti nel caso in cui gli Access Point non fossero disposti nel modo ottimale, il Device potrebbe non riconnettersi a nessun AP. Per questo si è pensato di inserire un timeout di attesa del pacchetto Reconnect: nel caso questo timeout scadesse, il Proxy avvia una procedura di disconnessione forzata del Device e di liberazione delle risorse occupate. È evidente che durante la fase di disconnessione il Device, per poter garantire continuità di servizio, deve far uso di un proprio buffer, che inevitabilmente, non essendo durante questa fase riempito dal Proxy, va progressivamente svuotandosi. Per garantire di poter effettuare più di un handoff per ogni canzone, si è pensato di utilizzare differenti velocità di trasmissione dei frame dal Proxy al Device; in particolar modo si è pensato a due differenti velocità:

Normale Velocità, che viene utilizzata durante la normale erogazione del servizio, quando cioè il Server invia il file al Proxy che a sua volta lo inoltra al Device; Alta Velocità, che viene utilizzata alla riconnessione del Device al nuovo Access Point, quando cioè il buffer del Client si è svuotato quasi completamente, permettendo quindi la sua ricarica al livello raggiunto prima della situazione di handoff. 3.3. Caratteristiche dei messaggi In un sistema distribuito è ovviamente necessario prevedere una serie di messaggi per lo scambio di informazioni, per le richieste e per la sincronizzazione tra le varie entità coinvolte. La classe predisposta a tale comunicazione è ProtocolPacket. _type Figura 6: Formato del pacchetto ProtocolPacket Il campo _type serve semplicemente per identificare il tipo di pacchetto, che può essere uno tra: Ack Connect Connected _object 7 Disconnect Format Frame Handoff Reconnect Song_Request In base al tipo di pacchetto, il Proxy si attende un particolare Object che verrà utilizzato in base all occorrenza. Come si può notare, nel pacchetto non viene inserito l id con il quale viene identificato ogni Device collegato al servizio. Infatti il Server e il Proxy aprono un canale di comunicazione distinto per ogni sessione e questo fa si che ogni singolo messaggio venga spedito su una porta d ascolto specifica associata ad ogni particolare Id, evitando quindi il rischio di ambiguità o scambio di messaggi. 4. Test, Conclusioni e sviluppi futuri Per effettuare i test sono stati utilizzati cinque PC: uno sul quale è stato fatto girare il Server, uno per il Proxy, due per gli Access Point e infine uno per il Device. L utilizzo delle librerie NCSOCKS ci ha obbligato a utilizzare un sistema Linux sugli Access Point e sul Device; in particolar modo è stata utilizzata la versione Ubuntu 7.10. I file audio utilizzati sono tutti in formato mp3 caratterizzati da una bit rate pari a 128 Kbit/sec. Per effettuare un corretto handoff si sono posizionati gli Access Point ad una distanza di circa 15 metri l uno

dall altro. Ogni test, che consisteva nell erogazione del flusso streaming di una canzone completa, prevedeva la realizzazione di almeno due handoff. In figura 7 è evidenziato l andamento del livello e della dimensione del circolar buffer del Proxy in uno di questi test. Come si può osservare, nella prima fase, quando il Device è correttamente connesso alla rete, il Proxy riceve i frame dal Server e li inoltra immediatamente al Client. Quindi si verifica una prima situazione di handoff: il Proxy termina l invio dei frame e comincia quindi a immagazzinare nel buffer quelli provenienti dal Server (fase 1). Una volta riconnesso, il Device invia il Sequence Number dell ultimo frame ricevuto, permettendo al Proxy di riprendere l invio dal primo frame utile. In questa fase (fase 2), come spiegato nel capitolo 3, la velocità di trasmissione del Proxy aumenta, permettendo un rapido riempimento del buffer del Device, associato ad un contemporaneo svuotamento del proprio, in modo tale da poter supportare eventuali altri handoff. F r a m e 200 150 100 50 0 1 2 0 19 39 59 78 98 118 137 157 177 196 216 236 255 275 Tempo in sec Livello Buffer Dimensione Buffer Figura 7: Dimensione e andamento livello buffer nel Proxy Tutti i test effettuati hanno dato esito positivo, garantendo una riproduzione corretta senza interruzioni anche a fronte di disconnessione dalla rete Bluetooth. L infrastruttura di rete e il protocollo realizzato permettono un handoff molto rapido (circa 4 secondi), ) variabile in base alla topologia della rete realizzata, garantendo inoltre l arrivo di tutti i frame della canzone inviati dal Server (a parte quelli persi a causa del protocollo UDP utilizzato). Il problema principale legato a questo tipo di applicazione, come detto precedentemente, è relativo all occupazione di risorse, in particolare sul Proxy. Tale problema però è stato limitato progettando un buffer dinamico, capace di modificare la propria dimensione in base alla probabilità di handoff. Il progetto è aperto a molti sviluppi futuri in particolare a modifiche riguardanti l aggiunta di una funzionalità di down-scaling: ovvero 8

adattamento del servizio in base alle caratteristiche del Device (tipo di Device, tipo di periferiche audio, livello batteria etc) e l aggiunta di funzionalità lato Client come la possibilità di mettere in pausa e successivamente riavviare la riproduzione del file audio. 5. Riferimenti Sito web del corso: http://www.lia.deis.unibo.it/courses/ RetiLS/ Sito web Mobilab: http://www.mobilab.unina.it/ncsoc KSdwnd.htm Sito web Java Media Framework: http://java.sun.com/products/javamedia/jmf/ 9