MUS.E. BT MUSic Everywhere with BlueTooth

MUS.E. BTMUSic Everywhere with BlueTooth

a proxy based architecture for stream continuity during bluetooth handoffs

Authors:Lorenzo Bricchi

Simone CortecchiaGuido 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

NCSOCKS

SSE E SSSSIIOONN

RRTTPP

FFLLOOWW

JMFClient

CLIENT PROXY SERVER

JMFProxyJMFServer

BufferController

FlowLevelManager

ControlFlowThread

FlowLevelManager

ControlFlowThread

FlowLevelManager

SessionCommSender

SessionManager

SessionData

HandoffManager

SingleSessionThread

SingleSessionManager

SingleSessionData

ProxyManager

StreamRequestThread

PortsSet

SingleSessionThread


SingleSessionData

ServerManager

StreamRequestThread

PortsSet

Requests: Stream,Stop,Handoff High,Normal,Low

Velocity

Responses:Confirm,

RewindComplete

Requests: ForwardStreamRequest

Stop

Response:Confirm

RTP stream RTP stream

BufferController

AckSender AckReceiver

Architettura del sistema

CircularBuffer

CircularBuffer

ClientControl

Protocollo: caratteristiche di base

CLIENT

PROXY

SERVER

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

2 7

1

2 7

1: StreamRequest 2: ForwardStreamRequest 3: Confirm & RTPStream 4: Confirm & RTPStream 5: Ack message sending

1

ServerProxy HProxy 1

23

4

5

5

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


23

4

5

NCSOCKSHandoff likelihood high

HARD HANDOFF SCENARIO

5

6


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 & RTPStream10: Ack message sending11: End of media

1


23

4

5

9

9

NCSOCKSHandoff likelihood high

10

HARD HANDOFF SCENARIO

5

6

710

11

8


NCSOCKS Handoff initiated

Messaggi di gestione: rewind & co. La richiesta di rewind permette al Client di recuperare i

frames inevitabilmente persi durante l’handoffClient ProxyHProxy1

StreamFrame 99 Ricezione

Frame 100Frame 101Frame 102

ackInizio handoff

Fine handoff

Timeout

Frames persiRewind (100)

StreamFrame 99

Frame 100Frame 101Frame 102

RewindFrame 100Frame 101Frame 102Ricezione

ack

StreamRicezione

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

RequestKind

SessionPort

FlowPort

RTPPort Song

RequestKind=0, richiesta iniziale.

IDProxy

SessionPortProxy

FlowPortProxy

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.

ProxyHSessionPort

ProxyHFlowPort

ProxyHRTPPort

IDRequest

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

IDRequest

Response

RequestKind 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!

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

NCSOCKS

SSE E SSSSIIOONN

RRTTPP

FFLLOOWW

JMFClient

CLIENT PROXY SERVER

JMFProxyJMFServer

BufferController

FlowLevelManager

ControlFlowThread

FlowLevelManager

ControlFlowThread

FlowLevelManager

SessionCommSender

SessionManager

SessionData

HandoffManager

SingleSessionThread


SingleSessionData

ProxyManager

StreamRequestThread

PortsSet

SingleSessionThread


SingleSessionData

ServerManager

StreamRequestThread

PortsSet


Velocity

Responses:Confirm,

RewindComplete


Stop

Response:Confirm


BufferController



CircularBuffer

CircularBuffer

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.

ProxyManager StreamRequestThread

SingleSessionThrea

SingleSessionData

SingleSessionManager AckReceiverThread

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

NCSOCKS

SSE E SSSSIIOONN

RRTTPP

FFLLOOWW

JMFClient

CLIENT PROXY SERVER

JMFProxyJMFServer

BufferController

FlowLevelManager

ControlFlowThread

FlowLevelManager

ControlFlowThread

FlowLevelManager

SessionCommSender

SessionManager

SessionData

HandoffManager

SingleSessionThread


SingleSessionData

ProxyManager

StreamRequestThread

PortsSet

SingleSessionThread


SingleSessionData

ServerManager

StreamRequestThread

PortsSet


Velocity

Responses:Confirm,

RewindComplete


Stop

Response:Confirm


BufferController



CircularBuffer

CircularBuffer

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

…clientCLIENT

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 DataSourceb) inserisce lo stream nel suo buffer circolare per mezzo di

un Parserc) avvia un Multiplexer e la riproduzione audio su un

Player.

Client ClientControl avviato dal livello

Flowa) intercetta gli eventi JMF scatenati

durante il funzionamento del sistema : - StreamMappedEvent - InactiveReceiveStreamEvent, - NewReceiveStreamEvent e ByeEventb) 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 Unibob) 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

Client 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!!!

MUS.E. BT MUSic Everywhere with BlueTooth

Documents

Transcript of MUS.E. BT MUSic Everywhere with BlueTooth