Progetto MUSE
MUSic Everywhere
Presentazione di Leardini Francesco
Reti di calcolatori LS
Scopo del progetto
Realizzare un sistema in grado di fornire un
servizio continuo di audio streaming su rete
wireless verso device mobili.
Garantire QoS  particolare attenzione a:


Perdita pacchetti trasmessi
Possibilità di handoff
(legata alla mobilità dei disposivi client)
Architettura del sistema
Proxy-Server protocol
Media Req
Server
RTP streaming
Media Req
Internet
RTP streaming
Sunrise.mp3
Spirito.wav
...
Client
Handoff prevision
HandoffManager
NACK (last frame)
Media Req
RTP streaming
Notti magiche.mp3
Componenti realizzati
All’interno del progetto sono stati realizzati
individualmente le seguenti entità:
Streaming server
Predittore dell’handoff
Meccanismo per le notifiche al client
Streaming Server
Mantiene le risorse di interesse per il servizio
(sotto forma di file audio: wave, mp3)
Trasmette i media on-demand aprendo una sessione
RTP per ogni richiesta ( protocollo Proxy-Server)
Sviluppato su due livelli ( in base alle responsabilità)

Session layer: gestione richieste di servizio e scambio dei
messaggi protocollo Proxy-Server

Transport layer: creazione e gestione della sessione RTP
Protocollo Proxy-Server
GET(mediaID, RTPport)
 Permette di richiedere un file audio
specificando:


ID del brano (conoscenza statica)
Porta RTP di ascolto sul Proxy
Get_ok
 Conferma la ricezione della richiesta
In seguito viene trasmesso lo stream
Importanza della previsione
La previsione consente di avviare un’azione
proattiva a fronte di un possibile handoff:
Ridimensionamento del buffer (client/proxy) per
creare una “riserva” di frame e far fronte
all’eventuale periodo di disconnessione
 Aspetto centrale del sistema!
Politiche di handoff
Sono state considerate due politiche di handoff:
Reattiva:  minimizza il numero degli handoff 
 tempi più lunghi di handoff (ricerca nuovo AP) 
Proattiva:  aumenta il numero degli handoff 
 riduzione tempi di handoff (eseguo prima ricerca AP) 
Ampia libertà concessa ai costruttori di schede wireless nella scelta
dell’una o dell’altra strategia
 Adottata per le previsioni una una scheda Intel/pro (politica reattiva)
 Considerate entrambe le politiche per la previsione
Schema
componenti principali
HandoffManager
Componente attivo diper
primariala previsione
importanza. Coordina tutte le entità
che cooperano alla previsione
dell’handoff per realizzare le
diverse strategie di previsione.
HandoffManager
Predizione handoff
WirelessDeviceManager
Interagisce con la scheda,
interrogandola per desumere
dettagli circa l’AP corrente e la
lista di quelli visibili, i valori dei
relativi RSSI, ecc.
GreyPrediction
GreyPrediction
WirelessDeviceManager
Implementa il modello di Grey
utilizzato per filtrare i valori degli
RSSI rilevati
Previsione REATTIVA
L’utente si allontana dall’AP, la
potenza del segnale diminuisce…
Predizione handoff
Notifica al client
HANDOFF
CASO 1
… se il valore del segnale rilevato
scende al di sotto della soglia stabilita
CASO 2
 predizione handoff
L’utente torna sui propri passi, il segnale
 notifica
la client
torna
a migliorare
L’utente esce dalla cella relativa all’AP
cui è attualmente connesso  handoff!
 Torniamo al contesto iniziale
Previsione PROATTIVA (soft/hard)
L’utente si allontana dall’AP, la
potenza del segnale diminuisce…
Caso HARD-PROATCIVE
Il nuovo AP ha un valore del segnale
migliore dell’isteresi – ε
 Predizione handoff
 Notifica al client
Notifica al client
Caso SOFT-PROACTIVE
Notifica previsione handoff se:
...viene rilevata un nuovo AP
•nuovo RSSI migliore dell’isteresi – ε
•valore RSSI attuale scadente
(in base alla soglia stabilita)
Conclusioni
• Prototipo funzionante
• Definizione protocolli ad-hoc
• Implementazione protocollo RTP-R
• Possibilità di fronteggiare periodi in assenza di
segnale di circa 4 sec
(1000÷1600 ms, nei casi peggiori 2000 ms, per ripristinare la connessione)
• Totale trasparenza di ritrasmissione, handoff e
dimensionamento dei buffer
Progetto MUSE
MUSic Everywhere
Fine