MUSE BT
Proxy
Colombini Gabriele
231491
Invio di Streaming Audio attraverso rete wireless Bluetooth
Mobilità attraverso la rete Bluetooth, con passaggio eventuale
da un Access Point ad un altro
Continuità di servizio a seguito di handoff
Server: mantiene le canzoni sotto forma di mp3
Proxy: agisce da mediatore tra Client e Server
Access Point: permette la accedere alla rete Bluetooth
Client: riceve le richieste dell’utente e riproduce il file
audio richiesto
Introduzione
Zona di handoff
Zona critica
Struttura
Doppio livello di bufferizzazione
Buffer sul Client che permette la riproduzione durante la
situazione di handoff e di disconnessione da qualsiasi Access Point
Buffer sul Proxy che permette di memorizzare i frame inviati dal
Server durante le situazioni di handoff e di disconnessione da
qualsiasi Access Point e di inviarli al Client una volta riconnesso
Utilizzo di NCSOCKS come infrastruttura di rete
Mobility Management: gestione degli handoff che occorrono nel
passaggio da un Access Point ad un altro
Connection Awareness: conoscenza di tutte le informazioni circa
lo stato attuale della connessione (qualità del segnale, probabilità
di handoff)
Soluzione
ApplicationProxy: thread in
continuo ascolto, in attesa di una
richiesta di connessione al servizio
proveniente da Client
SessionProxy: thread che viene
generato appena ricevuta una
richiesta di connessione da un
Client
RTPProxy: thread utilizzato per
gestire il flusso multimediale:
riceve il flusso dal Server,
inoltrandolo al Client
Proxy
Application
Proxy
Session
Proxy
RTP
Proxy
Per ogni Client che si
connette viene creata un
interfaccia bnep per
l’incapsulamento dei dati
ETH0
AP
Lato Access Point le
interfacce bnep create sono
unite con bridge a pan0
ETH0
L’interfaccia di rete eth0
viene unita tramite bridge
all’interfaccia virtuale pan0
PAN0
BNEP0
Unica rete a cui i Device
si collegano tramite
una serie di bridge
Access Point
Proxy
Client 1
BNEP0
BNEP1
…
BNEPn
Client n
BNEP0
Ad ogni Client è
associato un IP
fisso
Trasparenza al
Proxy: continua
ad inviare
sempre allo
stesso IP
 Il Proxy
potrebbe
continuare a
inviare al vecchio
Access Point
SOLUZIONE!?!
Handoff
ETH0
ETH0
PAN0
PAN0
Handoff
BNEP0
BNEP0
A regime il livello di riempimento è minimo
Durante la fase handoff
I frame provenienti dal Server vengono memorizzati nel
buffer
In questa fase il livello di riempimento si alza costantemente,
fino alla riconnessione del Client
Dopo essersi riconnesso il Client invia il numero di sequenza
dell’ultimo frame ricevuto
Il Proxy riprende l’invio dal frame con numero di sequenza
ricevuto
Ora il buffer è pieno (o quasi)…e se si verifica un altro
handoff?????
Politica Adottata: 2 differenti velocità
Bassa: a regime
Alta: dopo la riconnessione del Client
Buffer
Problema di gestione delle risorse
Per molto tempo (a regime) il buffer è
quasi vuoto ma alloca comunque lo stesso
numero di risorse di quando è pieno
Buffer dinamico: modifica la sua capacità in base alla situazione
50 Frame quando non deve immagazzinare i frame
provenienti dal Server
150 Frame quando il Client è disconnesso
Buffer dinamico
Proxy
Session
RTP
Proxy
Handoff
Handoff
Probabilità
Imminente
Alta
Il Proxy invia iterativamente i frame che arrivano dal
Server
Il Client notifica che si sta avvicinando a una situazione di
handoff: il Proxy ingrandisce il proprio buffer
Il Client notifica che la situazione di handoff è imminente:
Il Proxy blocca l’invio dei frame al Client e comincia a
memorizzare quelli provenienti dal Server
Disconnessione
Proxy
Session
RTP
Proxy
Reconnect
Ack
Ack
Il Client invia un messaggio di riconnessione con il sequence
number dell’ultimo frame ricevuto
Il Proxy risponde con un Ack al Client
Questa fase viene eventualmente iterata fino a quando il
Client riceve l’Ack
Il Client invia un Ack al Proxy
Il Proxy riprende l’invio dei frame immagazzinati
Riconnessione
Per i test sono stati utilizzati 5 portatili
Un portatile per il Client
Due portatili per gli Access Point
Un portatile per il Proxy
Un portatile per il Server
160
140
120
F
r 100
a
80
m
e 60
40
20
0
6
12
18
24
30
37
43
49
55
61
67
74
80
86
92
98
104
111
117
123
129
135
141
148
154
160
166
172
178
185
191
197
203
209
215
222
228
234
240
246
252
259
265
271
277
283
0
Tempo in sec
Il Proxy Ilcomincia
si
ricomincia
prepara
a ad
aimmagazzinare
inviare
eventuale
i che
frame
ihandoff:
al
frame
Client,
ingrandisce
svuotando
dal
il
Proxy
invia
i un
frame
riceve
dal provenienti
Server
Server
buffer
Test
Il Sistema progettato garantisce continuità di servizio
anche a fronte di ripetuti handoff
L’utilizzo di un buffer dinamico permette di gestire al
meglio l’allocazione di risorse
Il protocollo utilizzato garantisce al Client la ricezione di
tutti i frame della canzone, ad esclusione di quelli persi per
il protocollo UDP
Per il futuro…
Adattamento del servizio in base alla caratteristiche del
Device
Aggiunta di funzionalità che permettono di controllare il
flusso audio in uscita dal Proxy
Utilizzo di differenti dispositivi device, come ad esempio
Palmari
Conclusioni e sviluppi
Fine