MUSEProgetto di un servizio di audio Progetto di un servizio di audio

streamingstreamingin reti wirelessin reti wireless

Progetto realizzato da:Leardini FrancescoMercati AlbertoMorsiani Marco

Bologna 16-02-2007

Presentazione a cura di:

Morsiani Marco

C.d.L.S. Ingegneria Informatica Università di Bologna

Reti di Calcolatori LS Prof. Antonio Corradi – AA. 2005-06

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 audio streaming fornito

da server legacy– Rete Wi-Fi con più Access Point– Hard horizontal handoff

Specifiche del sistema

RTP streaming

QoS monitoring

Ritrasmissione

RTP streaming

• Architettura a 3 livelli: Client, Proxy e Server progettazione del Server indipendente dalla specifica implementazione del Client

• Doppio livello di bufferizzazione dello stream (Client e Proxy) per garantire continuità dell’erogazione del flusso audio a fronte di handoff orizzontali del Client

• RTP/RTCP come protocollo di streaming • RTP-Retransmission come tecnica di recupero dei dati andati persi• Progetto realizzato su piattaforma Java standard (J2SE + JMF)

Mobile client Proxy Streaming Server

Circular BufferCircular Buffer

Architettura del sistemaServer

Proxy

A.P.

Client

• Handoff

• Riconnessione e Streaming

• Connessione e Streaming• Handoff

• Riconnessione e Streaming

• Connessione e Streaming

Tematiche da me affrontate

Progetto e implementazione del Client

monitoring dello stato della rete e

predizione dell’handoff esclusi

Progetto e implementazione di RTP-RetransmissionGestione dell’handoff e successivo rispristino della sessione

Analisi dell’entità Client• Si interfaccia all’end-user: permette di effettuare richieste

ed effettua la presentazione dei contenuti mediali• Monitora costantemente lo stato della rete• Gestione della sessione durante un handoff e delle

modalità del suo ripristino• Interazione con i contenuti del Server mediata da un

Proxy

• Comunicazione a 3 livelli: RTP + RTP Retransmission: per il trasporto dei frame audio socket TCP: per garantire coordinamento tra le entità (attraverso

un protocollo ad-hoc) socket UDP: per la trasmissione di informazioni di contesto al

Proxy

HandoffMonitor

Business Logic

RetransmissionSubsystem

Wireless Interface

User Interface

PlayerBuffer

Architettura Client

Interfacciamento con l’utente finale

Interfacciamento con il proxy

PlayerBuffer

Parser

Multiplexer

DataSource

PlayChain

DataSource

CircularBuffer

Ricezione pacchetti audio, riempimento del buffer

circolare e rilevamento dei pacchetti mancantiBuffer con struttura a ring:● Scritture e letture mediante due puntatori (head e tail).● Estensione del componente uniboEstrazione di pacchetti dal buffer

Logica realizzativa di

RTP-Retransmission

Presentazione del medium

New Session

Proxy Proxy System

Client

Attivazione proxy

Streaming

New Session Ok

Get Medium

Get Ok

Restore Session

Restore Session Ok

Streaming

Handoff Prevision

Handoff

Protocollo di comunicazione Client-Proxy

identificativo della sessione

porta di ascolto per protocollo RTPspecifica

l'identificativo della sessione

nuova porta di ascolto per

ritransmissione

porta di ascolto per

ritransmissione

RTP-RTCP (richiami)• Supporto di base al trasporto di dati real-time audio e

video• Sessione RTP: associazione fra due applicazioni

comunicanti con RTP; è identificata da un indirizzo di rete e una coppia di porte (per i pacchetti RTP e RTCP)

• Indipendente dai protocolli sottostanti: decisione di impiegare il livello di trasporto UDP Meno overhead: significativo in applicazioni real-time Meno garanzie: no certezze di consegna e di ordinamento

• Pacchetto RTP: dati applicativi e metadati formato del medium, numero di sequenza, identificativo del mittente, indicazione temporale

• Pacchetto RTCP: monitoraggio della trasmissione RTP numero pacchetti ricevuti, pacchetti persi, jitter, partecipanti alla sessione

La perdita di pacchetti può degradare in modosignificativo la qualità del medium ricevuto

RTP-Retransmission (1)• Proposta di estensione del protocollo RTP studiata per la

ritrasmissione di pacchetti persi, efficace in applicazioni real-time con vincoli sul ritardo non stringenti

è sufficiente un lieve ritardo iniziale nella presentazione del medium per permettere il set-up della sessione

• Applicabile ad unicast e piccoli gruppi multicast• Aggiunta di uno stream di ritrasmissione associato allo

stream originale

R S

Original STREAM

Retransmission STREAM

Come realizzare il multiplexing dei 2 stream?

RTP-Retransmission (2)

• Flessibilità e facilità di trattamento da parte della rete

• In multicast ogni ricevente può stabilire una sessione di ritrasmissione unicast separata

• Maggiore uso di porte

• Minimizza uso delle porte • No sessioni multicast:

associazione stream originale e stream di ritrasmissione problematica

Session-Multiplexing SSRC-Multiplexing

Client Proxy

RTP/RTCP 1

RTP/RTCP 2 Client Proxy

RTP / RTCP

RTP-Retransmission (3)

Sessione 1: stream originale

Sessione 2: stream di ritrasmissione• Il Client segnala la mancata ricezione di un pacchetto RTP tramite

un messaggio di feedback RTCP (NACK)• Il Proxy effettua lo stream di ritrasmissione dei pacchetti richiesti

attraverso RTP

Session-Multiplexing

Client Proxy

RTP/RTCP 1

RTP/RTCP 2

• NACK: messaggio RTCP di feedback utilizzato dal Receiver per inviare richieste di ritrasmissione

• RTP Retransmission Packet: pacchetto RTP utilizzato dal Sender per ritrasmettere un pacchetto perso

HEADER

PAYLOAD

original sequence number

pari al sequence nuber del pacchetto RTP originale ad

esso associato

payload del pacchetto RTP

originale

RTP-Retransmission (4)

Tipo di Payload: RTPFB (Transport layer FB

message)

sequence number del pacchetto RTP originale

perso

sequence number incrementato di una unità rispetto a quello

dell’ultimo pacchetto inviato sullo stream di ritrasmissione

i campi SSRC, timestamp, payload type, marker bit, CSRC count, e lista dei CSRC corrispondenti a quelli del pacchetto originale

Retransmission

ThreadRetransmission

Thread

RTPReceiver

RTPSender

Proxy Buffer

Finestra di riavvolgimento Client

Buffer

Original Stream

Retransmission StreamNACK

3

4321

21 4

RTP-Retransmission (5): funzionamento

Gap detected!

Proxy Client

3

• Sessione ripristinata e streaming• Sessione ripristinata e streaming

• Handoff• HandoffStato del Client:

Proxy

Original Stream

ClientRTP

Sender

RetransmissionThread

RetransmissionThread

RTPReceiver

Proxy Buffer

Finestra di riavvolgimento Client

Buffer

Retransmission Stream

7

54 6

Ripristino della sessione interrotta con RTP-

Retransmission

Gap detected!

123

456

654

456 NACK4

NACK5

NACK6

8 9

Buffer Policies del Client• Buffer caratterizzato da due soglie:Soglia “alta” → livello di riempimento da raggiungere per iniziare la

presentazione del medium Soglia “bassa” → numero minimo di frame sempre presenti nel buffer

quando in funzione

contributo alla continuità e fluidità della presentazione del medium

• Comportamento:1. Start-up: buffer circolare con una dimensione predefinita2. Predizione di handoff: incremento dinamico della dimensione per

immagazzinare il maggior numero di frame in arrivo 3. Ripristino delle dimensioni iniziali se livello di riempimento sotto ad

una soglia “intermedia”

controllo sull’impegno delle risorse di memoria

Test e risultati sperimentali

Gestione dellaritrasmissione nell’ipotesiche il Proxy effettui ildrop di un frame ogni 20

Gestione della sessione a fronte di un handoffdella durata di circa3 secondi

RTP-Retransmission

050

100150200250300350400

0 5000 10000 15000 20000 25000 30000

time

nac

k

RTP-Retransmission

0100200300400500600700800

0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000

time

nac

k

Conclusioni

• Architettura a tre livelli ()– Approccio efficace per adattare servizi continui a reti wireless– Nessuna modifica da apportare al servizio originario

• Efficacia della ritrasmissione basata su RTP-R ()– 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

– Nuove opportunità, non solo per reti wireless ma anche per Internet

• Mancata integrazione di RTP-Retransmission in JMF ()– Infrastruttura JMF un po’ troppo “chiusa”

Riferimenti• JMF: http://java.sun.com/products/java-media/jmf/2.1.1/specdownload.html

• Java MP3 PlugIn: http://java.sun.com/products/java-media/jmf/mp3/download.html

• RTP/RTCP: http://www.ietf.org/rfc/rfc3550.txt

• RTP-Retransmission: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-12.txt

• Extended RTP Profile for RTCP-based Feedback: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-11.txt

• Subversion: http://subversion.tigris.org/