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
Divisione in
livelli

Continuità di
servizio
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
Architettura del sistema
CLIENT
N
C
S
O
C
K
S
Session
Manager
SessionData
PROXY
Requests:
Stream,Stop,Handoff
High,Normal,Low
Velocity
SERVER
Requests:
Single
ForwardStreamRequest
SessionData
Stop
Proxy
Manager
ServerManager
StreamRequestThread
StreamRequestThread
SingleSessionManager
SingleSessionManager
HandoffManager
SessionCommSender
AckSender
Responses:
Confirm,
RewindComplete
FlowLevel
Manager
SingleSessionThread
Ack
Receiver
Response:
Confirm
SingleSessionThread
Single
SessionData
Ports
Set
Ports
Set
FlowLevel
Manager
ControlFlow
Thread
FlowLevel
Manager
ControlFlow
Thread
S
E
S
S
I
O
N
F
L
O
W
Buffer
Controller
Buffer
Controller
RTP stream
JMFClient ClientControl
RTP stream
JMFProxy
JMFServer
Circular
Buffer
Circular
Buffer
UNIBO Package
R
T
P
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
7
2
7
Sequenza dei messaggi
1: StreamRequest
2: ForwardStreamRequest
3: Confirm & RTPStream
4: Confirm & RTPStream
5: Ack message sending
2
Proxy 1
1
4
5
5
Server
3
Proxy H
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.
Sequenza dei messaggi
1: StreamRequest
2: ForwardStreamRequest
3: Confirm & RTPStream
4: Confirm & RTPStream
5: Ack message sending
6: High handoff likelihood
HARD HANDOFF
SCENARIO
2
Proxy 1
1
4
5
5
6
NCSOCKS
Handoff likelihood high
Server
3
Proxy H
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.
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
1
HARD HANDOFF
SCENARIO
Server
2
3
Proxy 1
Proxy H
8
4
5
10
7
5
6
NCSOCKS
Handoff likelihood high
9
10
9
NCSOCKS
Handoff initiated
11
Messaggi di gestione: rewind & co.
 La richiesta di rewind permette al Client di recuperare i
frames inevitabilmente persi durante l’handoff
Client
Proxy1
Stream
Frame 99
Ricezione
ack
Inizio handoff
Frame 100
Frame 101
Frame 102
Frames persi
Timeout
ProxyH
ack
Ricezione
Fine handoff
Rewind (100)
Stream
Frame 99
Frame 100
Frame 101
Frame 102
Rewind
Frame 100
Frame 101
Frame 102
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
Request
Session
Port
Flow
Port
RTP
Port
Song
RequestKind=0, richiesta iniziale.
Response

ID
Proxy
Proxy
SessionPort FlowPort
Proxy
RTPPort
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
Request
“increase”
ID
Messaggio già diretto alla porta di sessione assegnatagli dal Proxy.
ID necessario (in futuro) per inoltrare la richiesta al ProxyH.
Response
ProxyH
ProxyH
SessionPort FlowPort
ProxyH
RTPPort
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
Request
Kind
ID
Timestamp
RequestKind=1, richiesta di rewind.
Timestamp: relativo all’ultimo frame ricevuto dal Proxy1.
Response “rewindOK”

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
Accelerate
Normalize
SlowDown
“accelerate”
“normal”
“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!

 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”.
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
Architettura del sistema
CLIENT
N
C
S
O
C
K
S
Session
Manager
SessionData
PROXY
Requests:
Stream,Stop,Handoff
High,Normal,Low
Velocity
SERVER
Requests:
Single
ForwardStreamRequest
SessionData
Stop
Proxy
Manager
ServerManager
StreamRequestThread
StreamRequestThread
SingleSessionManager
SingleSessionManager
HandoffManager
SessionCommSender
AckSender
Responses:
Confirm,
RewindComplete
FlowLevel
Manager
SingleSessionThread
Ack
Receiver
Response:
Confirm
SingleSessionThread
Single
SessionData
Ports
Set
Ports
Set
FlowLevel
Manager
ControlFlow
Thread
FlowLevel
Manager
ControlFlow
Thread
S
E
S
S
I
O
N
F
L
O
W
Buffer
Controller
Buffer
Controller
RTP stream
JMFClient ClientControl
RTP stream
JMFProxy
JMFServer
Circular
Buffer
Circular
Buffer
UNIBO Package
R
T
P
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.
ProxyManager
SingleSessionThrea
StreamRequestThread
SingleSessionManager
SingleSessionData
AckReceiverThread
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
Architettura del sistema
CLIENT
N
C
S
O
C
K
S
Session
Manager
SessionData
PROXY
Requests:
Stream,Stop,Handoff
High,Normal,Low
Velocity
SERVER
Requests:
Single
ForwardStreamRequest
SessionData
Stop
Proxy
Manager
ServerManager
StreamRequestThread
StreamRequestThread
SingleSessionManager
SingleSessionManager
HandoffManager
SessionCommSender
AckSender
Responses:
Confirm,
RewindComplete
FlowLevel
Manager
SingleSessionThread
Ack
Receiver
Response:
Confirm
SingleSessionThread
Single
SessionData
Ports
Set
Ports
Set
FlowLevel
Manager
ControlFlow
Thread
FlowLevel
Manager
ControlFlow
Thread
S
E
S
S
I
O
N
F
L
O
W
Buffer
Controller
Buffer
Controller
RTP stream
JMFClient ClientControl
RTP stream
JMFProxy
JMFServer
Circular
Buffer
Circular
Buffer
UNIBO Package
R
T
P
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
azioni statiche
 durante lo streaming monitoring del
livello del buffer
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
crea DataSource(JMF)
PROXY
crea un RTPSender(Unibo)
crea un processor(JMF)
crea RTPMultiplexer(Unibo)
crea un RTPSender(Unibo)
crea un RTPParser(Unibo)
aggiunge endpoint del rx(Unibo)
fa partire invio dati(Unibo)
specifica l’endpoint del tx(Unibo)
crea un RTPReceiver(Unibo)
arrivo frame e inserimento
nel buffer
preleva frame dal buffer
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)
inserisce frame nel buffer
crea un player(JMF)
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
Flow
avviato dal livello
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
Client
TTW
dimensione
buffer
58 ms
200 frames
.WAV
Proxy
<=58 ms
100 frames
Client
78 ms
200 frames
.MP3
Proxy
<=78 ms
100 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!!!