MUSE Progetto di un servizio di audio streaming in reti wireless Progetto realizzato da: Leardini Francesco Mercati Alberto Morsiani Marco Bologna Presentazione a cura di: Morsiani Marco C.d.L.S. Ingegneria Informatica Università di Bologna Reti di Calcolatori LS Prof. Antonio Corradi – AA

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 Buffer

Architettura del sistema Server 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-Retransmission Gestione 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

Handoff Monitor Business Logic Retransmission Subsystem Wireless Interface User Interface PlayerBuffer Architettura Client Interfacciamento con l’utente finale Interfacciamento con il proxy PlayerBuffer Parser Multiplexer DataSource PlayChain DataSource Circular Buffer Ricezione pacchetti audio, riempimento del buffer circolare e rilevamento dei pacchetti mancanti Buffer con struttura a ring: ● Scritture e letture mediante due puntatori (head e tail). ● Estensione del componente unibo Estrazione di pacchetti dal buffer Logica realizzativa di RTP-Retransmission Presentazione del medium

New Session 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 RTP specifica 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 modo significativo 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 RS 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-MultiplexingSSRC-Multiplexing ClientProxy RTP/RTCP 1 RTP/RTCP 2 ClientProxy 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 ClientProxy 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 Thread Retransmission Thread RTP Receiver RTP Sender Proxy Buffer Finestra di riavvolgimento Client Buffer Original Stream Retransmission Stream NACK RTP-Retransmission (5): funzionamento Gap detected! ProxyClient 3

Sessione ripristinata e streaming Handoff Stato del Client: Proxy Original Stream Client RTP Sender Retransmission Thread Retransmission Thread RTP Receiver Proxy Buffer Finestra di riavvolgimento Client Buffer Retransmission Stream Ripristino della sessione interrotta con RTP-Retransmission Gap detected! NACK 4 NACK 5 NACK 6 89

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 predefinita 2.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 della ritrasmissione nell’ipotesi che il Proxy effettui il drop di un frame ogni 20 Gestione della sessione a fronte di un handoff della durata di circa 3 secondi

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: Java MP3 PlugIn: RTP/RTCP: RTP-Retransmission: Extended RTP Profile for RTCP-based Feedback: Subversion: