Servizi continui su rete IEEE
802.11 – Music Everywhere
Presentazione di Alberto Mercati
Reti di Calcolatori LS
Scenario applicativo: adattamento di
servizi continui a reti wireless
 Servizi continui
 Problemi su reti IP: come garantire
QoS?
 Problemi delle reti wireless
 Perdita di pacchetti
 Handoff del client
 Caratteristiche dello scenario
 Servizio di streaming fornito da server
legacy
 Rete Wi-Fi con più Access Point
 Hard horizontal handoff
Architettura del sistema
RTP streaming
QoS monitoring
Proxy
Circular Buffer
RTP streaming
Internet
RTP streaming
Ritrasmissione
Circular Buffer
Mobile client
 Architettura a 3 livelli
 Server
 Client
 Proxy (intermediario)
 Due livelli di buffering
 Client
 Proxy
 Proxy fornisce supporto a:
Streaming Server
 Mobilità
 Ritrasmissione
…
Punti fondamentali
 RTP-Retransmission: è una proposta di estensione del protocollo
RTP (Real Time Protocol), studiata per la ritrasmissione di pacchetti
persi
 Non compromette il corretto funzionamento di RTP (compreso RTCP)
 Funziona anche con intermediari che non implementano RTP-R
 Adattamento in banda del servizio: transcodifica dinamica dello
stream audio per adattarsi a mutazioni delle condizioni operative
(congestioni, handoff prediction, ecc…)
 Cosa ho fatto io?
 Progetto e implementazione del sottosistema di buffering
(lettura/scrittura, riproduzione, ecc…)
 Progetto ed implementazione del Proxy
 Studio dell’adattamento in banda
 Cosa NON ho fatto: Server, Client, monitoring dello stato della rete lato
Client e predizione di handoff, implementazione del supporto a RTP-R
Buffering
 Il buffering sul Client è la
soluzione normalmente
adottata per risolvere:
 Funzionalità del buffer
 Proxy (finestra nascosta, reperimento
frame): ActiveRTPBuffer.
 Client (inserimento fuori seq,
riproduzione): PlayerBuffer.
 Utilizzo delle “metafore” proprie di JMF
(classe DataSource)
 Jitter
 Perdita di pacchetti
 Arrivo fuori sequenza
FrameWindow
write
DataSource
Parser
read
DynamicCircularBuffer
Multiplexer
DataSource
ActiveRTPBuffer
Disponibile
per utilizzo
tramite JMF
Ottenuta tramite il
supporto JMF ad
RTP
ActiveRTPBuffer
PlayChain
PlayerBuffer
Funzionamento del sistema MUSE
 Client Fisso
 Non si verifica handoff
 Ci possono essere occasionali perdite di pacchetti
Proxy buffer
3
2
1
Client buffer
0
NACK 2
2
1
Finestra nascosta
0
Funzionamento del sistema MUSE
 Client mobile
 Previsione di handoff
 Congestione
 Diminuzione di banda
Proxy buffer
5
Handoff prediction,
Congestione,
ecc…
45 43 3 22
Transcodifica dinamica del
payload dei pacchetti RTP
Client buffer
1
0
A parità di banda e memoria
impiegata, abbiamo una
durata maggiore della
riproduzione
Funzionamento del sistema MUSE
 Client mobile
 Handoff
 Ripristino sessione: impiego del supporto per RTP-R
Proxy buffer
5
5
4
3
2
4
1
Finestra nascosta
Client buffer
3
0
Handoff
2
1
0
Funzionamento del sistema MUSE
 Client mobile
 Handoff
 Ripristino sessione: impiego del supporto per RTP-R
Proxy buffer
8
7
Client buffer
6
2
1
0
NACK 3
5
4
3
2
1
Finestra nascosta
0
NACK 4
NACK 5
Funzionamento del sistema MUSE
 Al momento del ripristino dopo un handoff, ci si aspetta che:
 Il buffer del Client sia vicino allo svuotamento
 Il buffer del Proxy sia di grandi dimensioni e quasi completamente
occupato
 È necessario:
 “Scaricare” dati sul Client
 Liberare risorse sul Proxy
All’occorrenza i
buffer devono
comportarsi come
due “vasi
comunicanti”,
eventualmente
ridimensionandosi
Proxy buffer
Client buffer
Informazioni di contesto
 Per tutta la durata del servizio è necessario raccogliere informazioni
di contesto per:
 Conoscere lo stato del Client
 Valutare la QoS
 Gestire frame rate
 Informazioni comunicate dal Client al Proxy tramite opportuni
pacchetti KeepAlive:





Dimensione buffer del Client
Spazio libero e spazio occupato sul buffer
Numero di frame ricevuti dall’inizio della sessione
Numero di sequenza dell’ultimo frame correttamente ricevuto
Tempo equivalente ai dati mediali contenuti nel buffer
Test e risultati sperimentali (1)
Proxy Buffer
Number of frames
Buffer size
250
N° frames
I test riportati illustrano
i risultati della parte di
progetto di mia
competenza
200
150
100
50
0
0
5000
10000
15000
20000
25000
Test 1:
35000
40000
45000
50000
35000
40000
45000
50000
40000
45000
50000
Client Buffer
1. Ridimensionamento
del buffer
Number of frames
Buffer size
N° frames
300
250
200
150
100
50
0
0
5000
10000
15000
20000
25000
30000
ms
RTP-Retransmission
45520
Sequence Number
2. Gestione della
ritrasmissione dopo
un handoff
30000
ms
45510
45500
45490
45480
45470
0
5000
10000
15000
20000
25000
ms
30000
35000
Test e risultati sperimentali (2)
Test 2:
Proxy Buffer
Number of frames
250
N° frames
1. Ritrasmissione di
pacchetti persi con
RTP-R
Buffer size
200
150
100
50
0
0
2. Combinazione di
handoff e perdita di
pacchetti
10000
20000
30000
40000
50000
60000
70000
50000
60000
70000
50000
60000
70000
ms
Client Buffer
Number of frames
Buffer size
N° frames
400
300
200
100
0
0
10000
20000
30000
40000
ms
RTP-Retransmission
Sequence Number
21400
21200
21000
20800
20600
20400
20200
0
10000
20000
30000
40000
ms
Conclusioni
 Implementazione RTP-R e nuove opportunità offerte ()
 Efficacia della ritrasmissione basata su RTP-R
 Nuove opportunità, non solo per reti wireless ma anche per Internet
 Architettura a tre livelli ()
 Approccio efficace per adattare servizi continui a reti wireless
 Nessuna modifica da apportare al servizio originario
 Impiego di RTP-R per la ritrasmissione dei pacchetti persi
durante un handoff ()
 In tutti i test da noi effettuati, RTP-R si è sempre dimostrato in grado di
gestire anche la perdita di sequenze di pacchetti consecutivi
 Le note dolenti
 Adattamento in banda (): caratteristica non funzionante. Abbiamo
incontrato problemi che non siamo ancora riusciti a superare
 JMF ()
Servizi continui su rete IEEE
802.11 – Music Everywhere
Presentazione di Alberto Mercati
Reti di Calcolatori LS
FINE