Sez_IX

pag. IX.302

La diffusione televisiva su Internet: architetture e tecnologie

Sezione IX: Qualit del Servizio

di Elena Mammi, Giuseppe Russo, Paolo Talone

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.303 Differente situazione si ha, invece, nella progettazione di tale 9 Qualit del Servizio: aspetti generali tipologia di servizi su reti IP di tipo tradizionale, quale lOpen Uno degli obiettivi principali di un servizio di diffusione Internet, in cui il traffico viene trasportato con lapproccio di televisiva su rete IP quello di fornire una qualit percepita tipo best effort. questo il caso delle cosiddette reti dallutente assimilabile a quella delle altre piattaforme di unmanaged (cfr. 1.3). diffusione della TV digitale (Satellite, terrestre). In tal caso per raggiungere gli obiettivi di qualit prefissati Il raggiungimento di tale obiettivo si scontra con non possibile ricorrere a meccanismi di rete che problematiche significative, che derivano dalla natura stessa consentano una gestione controllata del traffico associato ad dellinfrastruttura di trasporto che, come ben noto, non un particolare servizio. Si deve quindi ricorrere ad una serie stata concepita originariamente in vista del supporto di di tecniche a livello applicativo di tipo end-to-end, ovvero tra servizi con requisiti di isocronismo e affidabilit del la sorgente del servizio e il terminale dutente, che trasferimento delle informazioni, tipici invece dei servizi di contrastino il deterioramento del servizio, recuperando, ove diffusione di contenuti audio/video. possibile, le deficienze del trasferimento. La capacit di fornire agli utenti alti livelli di qualit del servizio un aspetto essenziale di tali servizi e costituisce, quindi, un requisito primario per le relative architetture. Spesso, per raggiungere i livelli di qualit richiesti, i servizi di diffusione televisiva vengono forniti attraverso reti IP chiuse, generalmente di propriet degli operatori di TLC, nelle quali sono previsti meccanismi di controllo e gestione del traffico, che consentono di ottimizzare il trasporto in rete delle informazioni associate a ciascun servizio. questo il caso delle cosiddette reti managed (cfr. 1.3). Di tali tecniche si fornir una panoramica nel 9.4. Come si illustrato nelle precedenti sezioni dedicate agli aspetti architetturali, per i servizi di diffusione televisiva su rete IP si prefigura spesso uno sviluppo verso ambienti operativi di tipo NGN. In tal caso, trattandosi questultima di una rete di tipo managed (con trasporto IP) ma con specifiche funzioni standardizzate, in particolare a livello di trasporto (NGN transport stratum functions, end-to-end QoS signaling functions, Resource and Admission Control Functions - RACF), nella progettazione dei servizi si dovr tener conto delluso di tali funzioni e della loro influenza sui parametri di qualit (ancora in fase di studio a livello

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.304 internazionale), in vista del raggiungimento degli obiettivi di dati relativi ai quadri I e P producono deterioramenti diversi rispetto a quelli relativi ai quadri B, dovuti alla qualit di servizio prefissati. propagazione temporale dellerrore; In generale, i parametri critici fondamentali che caratterizzano la qualit di trasmissione in una rete IP sono:

il codec usato; la pacchettizzazione utilizzata; dello stream di trasporto

la perdita di pacchetti, la latenza (ritardo end-to-end),

la distanza e il profilo delle perdite;

il jitter. Per servizi di diffusione televisiva, valori ragionevoli di jitter e di latenza non sono problematici per la presenza nei Set Top Box (STB) dei buffer de-jitter, la cui dimensione viene stabilita in maniera tale da essere compatibile con le prestazioni degli elementi di rete e i decoder video. Gli stream audio/video sono invece molto sensibili alla perdita di informazione e quindi alla perdita di pacchetti in reti IP. In tal caso, infatti, i decodificatori ricevono in ingresso flussi deteriorati e, conseguentemente, la qualit del servizio tende a degradare. Le deficienze del trasporto dellinformazione associata ad un servizio hanno un peso differente sulla qualit percepita dallutente (QoE), in funzione di una serie di variabili, tra cui: il tipo di dati persi: informazioni di sistema e di header producono gravi deterioramenti;

il bitrate di codifica, dato che per lo stesso tasso di perdita dei pacchetti, i deterioramenti dovuti ad una perdita avvengono pi frequentemente su uno stream video a rate pi elevato (cio vi sono pi errori visibili per unit di tempo). In Figura 9-1 si illustra graficamente un esempio di come i parametri di QoS possano influenzare la QoE.

Figura 9-1:Esempio di effetto dei parametri di QoS sulla QoE

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.305 delle perdite di pacchetto derivanti soprattutto da disturbi Inoltre perdite nei metadati, come la guida elettronica ai fisici nelle linee dutente equipaggiate con sistemi xDSL, programmi (EPG), la guida elettronica ai contenuti (ECG) e i rappresentati attraverso il modello REIN (Repetitive dati utente interattivi, possono causare problemi ancora pi Electrical Impulse Noise, cfr. 9.1.1). gravi sulle funzionalit del servizio. LITU-T, [100], riprende sostanzialmente il documento del pertanto essenziale che, nei servizi di diffusione televisiva DSL Forum, in particolare per definire i requisiti di servizio in su rete IP, vengano supportati dei meccanismi atti a termini di valori massimi di latenza, jitter ed occorrenza degli garantire l'integrit dei dati di controllo e a minimizzare le eventi di perdita di pacchetti e gli andamenti del Packet Loss perdite dei dati che rappresentano i media codificati. Rate (PLR) in funzione del bitrate per perdite di pacchetti isolate e perdite a burst. Questo viene riportato sia per 9.1 La perdita di pacchetti servizi SDTV che per servizi HDTV. Come gi detto in precedenza, la perdita di pacchetti Il documento [164] dellATIS, invece, costituisce un rapporto costituisce il fenomeno pi difficilmente contrastabile e pi tecnico riguardante il fenomeno della perdita di pacchetti nel influente sul degrado della qualit dei servizi di diffusione trasporto di un servizio televisivo su rete IP. Il documento in televisiva su reti IP. questione, analizzando le caratteristiche del fenomeno ed i Esistono una serie di documenti tecnici che trattano le relativi effetti sul servizio, si propone di discutere possibili diverse cause della perdita di pacchetti e i relativi modelli soluzioni, fornendo altres raccomandazioni per la loro statistici per la rappresentazione dei fenomeni pi comuni. applicabilit ad un servizio di diffusione televisiva su rete IP. Tra i pi significativi si ricorda il documento prodotto dal DSL Forum [146], ripreso in seguito dai gruppi di lavoro dellITU-T [100], e il documento [164] dellATIS che fa riferimento al documento [181] redatto dallANSI. Il documento [146] si focalizza sui requisiti di QoE richiesti per servizi Triple-Play. Per giungere a definire tali requisiti, oltre ad altri aspetti, viene effettuata una significativa analisi 9.1.1 Cause della perdita di pacchetti La perdita di pacchetti lungo il percorso di trasporto in rete di un servizio di diffusione televisiva su rete IP pu avvenire principalmente a causa di:

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.306 tipico leffetto del Repetitive Electrical Impulse Noise Errori di livello fisico sui pacchetti durante il loro (REIN). trasferimento in rete (ad esempio dovuti ad Nei sistemi DSL si fa solitamente uso, a livello fisico, interferenze elettriche nella rete delloperatore o nella di codici FEC di tipo Reed Solomon e di interleaving. rete domestica, specialmente se wireless). Quando tali sistemi vengono sopraffatti da un REIN, I comuni protocolli di livello 2, come Ethernet, alluscita del decodificatore DSL si genera un errore impongono uno scarto di pacchetti in presenza di non incorreggibile. Viene infatti cancellato, in genere, un riscontro della Frame Check Sequence (FCS). Questo intero blocco di lunghezza pari alla profondit funzionamento traduce un singolo errore su un bit in dellinterleaver. un evento di perdita del pacchetto (errori casuali). Altri Si tenga presente che una tipica configurazione per protocolli (come in ATM) forniscono un meccanismo DSL una profondit dellinterleaver di 8 o 16 ms. per inoltrare i pacchetti con errore permettendo al In questi casi, quindi, il parametro principale terminale dutente di operare una qualche forma di costituito dalla durata della perdita. recupero dellerrore. Il documento [164] evidenzia unaltra causa di errori fisici, maggiormente legata agli apparati della rete domestica (Set Top Box, Home Gateway, ecc). Infatti i dispositivi di consumer electronics, con alimentazione energetica fornita dalla rete domestica (commerciale), sono soggetti a transitori, a picchi di potenza e ad eventi di power switching allinterno dellambiente domestico. Concettualmente i diversi dispositivi hanno risposte diverse che possono determinare eventi di errore sul bit, oppure provocare il riavvio del dispositivo (cosa che incide sul throughput per un certo periodo di tempo portando alla perdita di una sequenza di pacchetti). In particolare le reti wireless domestiche possono essere pesantemente influenzate dal rumore e dalle interferenze radioelettriche, mentre nel caso dei sistemi DSL

Meccanismi di scarto dei pacchetti negli apparati di rete, in corrispondenza di eventi di congestione. Lo scarto di pacchetti pu avvenire a causa di sovraccarichi transitori dei buffer negli apparati di rete. Loccupazione del buffer controllabile fino ad un certo grado da parte delloperatore, qualora abbia a disposizione informazioni adeguate sulle caratteristiche del traffico. Possono tuttavia crearsi svantaggi nel tentativo di gestire potenziali eventi di sovraccarico del buffer, derivanti da basse utilizzazioni di link e nodi. Inoltre, anche in reti con una utilizzazione medio bassa possono esserci grandi variazioni nel carico di traffico istantaneo, sia su periodi lunghi, che su periodi brevi. Si pu prevedere quindi che questi eventi di congestione transitoria possano essere osservati anche in reti ben progettate.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.307 Le perdite dovute alla congestione non dovrebbero Eccessivo ritardo di trasferimento end-to-end che rende i essere confuse con la congestione persistente che si relativi pacchetti inutilizzabili dal ricevitore. ha nel caso in cui un link venga esaurito In questi casi i parametri da considerare sono costituiti permanentemente. Si deve assumere che i Service dal tempo massimo di attesa e dalla relativa probabilit Provider progettino in maniera adeguata i servizi e le di perdita (dei pacchetti). reti che li supportano, in maniera tale che non si Fenomeni del genere possono essere causati anche dal verifichino congestioni persistenti. fatto che i protocolli di trasporto utilizzati (esempio tipico I video possono essere codificati a ciclo aperto con lUDP) non prevedano meccanismi di recupero dei una scala di quantizzazione fissa, conducendo ad un pacchetti fuori sequenza. traffico a bitrate variabile (VBR) con una qualit Microinterruzioni del flusso dati (ad es. link failure di un approssimativamente costante, oppure possono cammino in rete ed attivazione del cammino alternativo). essere codificati ad un bitrate allincirca costante con Per le reti IP esistono dei meccanismi di protezione dai qualit variabile. Gli attuali formati commerciali di link failure, che operano a diversi livelli. Tali meccanismi video digitali sono generalmente ottimizzati per canali hanno differenti scale temporali e quindi per ogni di trasmissione dedicati a velocit costante, tramite meccanismo considerato vi un periodo di tempo per il meccanismi di adattamento per generare un traffico a quale si ha una perdita di pacchetti. Questi meccanismi rate approssimativamente costante. Nel caso di includono: stream a rate costante si suppone che i sovraccarichi protezione del link a livello fisico (ad esempio dei buffer non costituiscano un problema significativo. SONET) con procedure di recupero da guasti, che in Per dimensionare invece i buffer in maniera adeguata genere operano su scale temporali di circa 50 ms; per la multiplazione statistica di stream video VBR, le meccanismi di protezione a livello IP (come ad statistiche del traffico degli stream VBR devono esempio MPLS Fast Reroute) con procedure di essere caratterizzate in modo corretto. I guadagni recupero da guasti, che operano comunemente su della multiplazione statistica sono significativi per scale temporali di qualche centinaio di millisecondi; interfacce di rete aggregate (ad esempio GbE con meno di 100 stream video). La caratterizzazione del meccanismi di instradamento di livello IP, che in traffico video VBR, seppur di complessit rilevante, genere operano su scale temporali dellordine dei importante anche per definire in maniera pi secondi o delle decine di secondi. conveniente le politiche di sagomatura del traffico.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.308 In questi casi quindi il parametro principale costituito la caratterizzazione degli ambienti rumorosi in dal tempo di interruzione, ovvero dal tempo che impiega particolari locazioni; ogni meccanismo a ripristinare il servizio, attivando un i protocolli e le caratteristiche della rete; cammino alternativo. Con riferimento agli eventi di microinterruzione, la Tabella 9-1 mostra il numero di le architetture e i meccanismi di rete. pacchetti di 1500 byte (dimensione di default della Maximum Transfer Unit) che verrebbero persi, a diversi Dallosservazione del comportamento di tipiche infrastrutture rate nominali di trasmissione, in eventi di interruzione di di reti IP possibile ricavare, attraverso opportune durata specificata. campagne di misura, valori tipici dei parametri che maggiormente riescono a rappresentare, da un punto di 10 ms 50 ms 100 ms 500 ms vista statistico, categorie di reti IP differenti da un punto di 1 4 8 42 1 Mbps vista della qualit del trasporto. 4 21 42 208 5 Mbps Ad esempio lANSI fornisce alcune indicazioni sulle 8 42 83 417 10 Mbps prestazioni attese per diverse categorie di rete [181], Tabella 9-1: Numero di pacchetti IP persi illustrate dalla Tabella 9-2. Questo tipo di caratterizzazione per durata delle perdite tuttavia molto generico in quanto i profili dettagliati degli 9.1.2 Caratterizzazione statistica degli eventi eventi di perdita sono specifici della particolare rete considerata. di perdita dei pacchetti La caratterizzazione statistica degli eventi di perdita di pacchetti risulta non semplice, in quanto il fenomeno deriva, come illustrato in 9.1.1, dalla coesistenza di molteplici cause e dai particolari meccanismi di rete presenti. Tra i fattori che influenzano maggiormente le caratteristiche del fenomeno di perdita si ricordano:

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.309 Profilo di rete Profilo A Profilo B Profilo C Descrizione Reti IP pienamente gestite con distanza di routing e di cammino vincolate Reti IP parzialmente gestite con distanza di routing e di cammino meno vincolate Reti IP non gestite (Internet) con qualsiasi distanza disponibile di routing e di cammino Perdita di pacchetti di tipo casuale < 0,05% < 2% < 20% Massima perdita di pacchetti in sequenza Solo durante i guasti dei link Burst < 200 ms, avviene ogni 1000 secondi Burst < 10 ms, avviene ogni 10 secondi

Tabella 9-2: Eventi di errori operativi per profilo di rete vincolo per il quale allinterno di un burst sparso devono occorrere meno di Gmin pacchetti consecutivi ricevuti. Il valore di Gmin viene scelto in maniera tale che il tasso minimo effettivo di perdita, allinterno di un burst, corrisponda al pi basso tasso di perdita dei pacchetti, per il quale si presenta qualche distorsione visibile allinterno del media stream decodificato. I burst sparsi sono spesso dovuti a congestioni di rete, al meccanismo Random Early Discard (RED) utilizzato dai router per evitare le congestioni di rete, assicurando cos che le proprie code non si riempiano [149], e ad effetti relativi. Burst continui I burst continui sono periodi durante i quali vengono persi tutti i pacchetti. Perdite contigue possono avvenire a causa

9.1.3 Modelli di perdita dei pacchetti Da un punto di vista di modellazione statistica vengono individuati tre modelli fondamentali che possono caratterizzare singolarmente o in combinazione eventi di perdita di pacchetti in varie tipologie di reti IP [146], [100]. Burst sparsi I burst sparsi, sono periodi temporali, dellordine di alcuni secondi, in cui si ha un elevato tasso di perdita di pacchetti. Queste perdite possono essere rappresentate secondo i modelli di Markov [147] o di Gilbert-Elliott [148], [215]. Un burst sparso un periodo che inizia e termina con un pacchetto perso o scartato, durante il quale vengono soddisfatti alcuni vincoli. Nella specifica [144] viene definito il

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.310 Si parte dallanalisi delle tipiche strategie di incapsulamento della pacchettizzazione IP (ovvero linserimento di molti delle informazioni, costituenti le componenti elementari di un pacchetti di Transport Stream allinterno di un pacchetto IP), servizio (video/audio/dati) in pacchetti IP, fino a giungere al delle interruzioni per guasti dei link allinterno di una rete IP suggerimento di indicazioni sulla scelta di particolari opzioni e di altri fenomeni. di codifica e di pacchettizzazione. Perdite isolate (random) Ladattamento pi comune dei pacchetti Transport Stream I pacchetti persi isolati si presentano tipicamente a causa di (TS) MPEG-2 per il trasporto su IP consiste bit error nella trasmissione o di collisioni eccessive nelle reti nellincapsulamento di sette pacchetti TS in un singolo ad area locale. pacchetto UDP, come illustrato nella Figura 9-2. 9.1.4 Effetto della perdita dei pacchetti Sia ATIS che ITU-T riportano una serie di considerazioni riguardanti i possibili effetti della perdita dei pacchetti sulla percezione della qualit del servizio da parte dellutente.

Figura 9-2: Trasporto dei Transport Stream MPEG-2 nelle trame Ethernet

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.311 Si tenga presente che linformazione video MPEG-2 Lobiettivo quello di inserire pi pacchetti Transport Stream strutturata in termini di quadri I, quadri P e quadri B, dove i possibili in una singola trama Ethernet, senza superare la quadri I (Intra frame) sono codificati in maniera indipendente dimensione di default di 1500 byte della Maximum Transfer dagli altri (e sono quindi pi costosi in termini di bit), mentre i Unit (MTU) Ethernet, in modo tale da minimizzare la quantit quadri P e B sono interpolati sulla base dei quadri I o P di overhead. Come si pu notare dalla Figura 9-2, questo precedenti e successivi (risultando cos meno costosi dei meccanismo porta a 10528 bit di informazione MPEG-2 quadri I in termini di bit). I quadri I, P e B sono organizzati in trasportati in ogni trama Ethernet, indipendentemente GOP (Group Of Picture) di struttura fissa o variabile che si dalladozione o meno del protocollo RTP. La specifica [18] ripetono senza soluzione di continuit nel flusso video definisce lincapsulamento dei Transport Stream MPEG-2 codificato. I pacchetti TS non corrispondono a punti di direttamente nei pacchetti UDP (oppure in RTP/UDP) per sincronizzazione delle codifiche video o audio contenute nei servizi di diffusione televisiva. corrispondenti payload e i quadri video codificati non sono Si noti che, in conformit allo standard Ethernet, un singolo generalmente sincronizzati con i pacchetti IP in quanto, viste bit error conduce alla perdita dellintera trama. I pacchetti IP le dimensioni tipiche, occupano pi pacchetti. persi possono contenere una variet di informazioni legate Quindi, dato che la codifica di ciascun quadro video prevede al servizio di diffusione televisiva, tra cui: unintestazione (header) contenente parametri per la informazioni di segnalazione e controllo; decodifica, se il pacchetto che viene perso include tale informazioni dei media. informazione allora pu essere perso lintero quadro (senza Un errore o una sequenza di errori in un bit stream audio o considerare gli algoritmi che il decodificatore MPEG pu video pu causare effetti variabili da un impatto sullaudio o operare per occultare gli errori). Nel caso peggiore la perdita sul video decodificato non percepibile per lutente, fino alla di un pacchetto contenente lheader di un quadro Intra, pu perdita completa del segnale video o audio a seconda del portare alla perdita di tutti i quadri video codificati finch non tipo di informazioni perse e della robustezza viene ricevuto il quadro I successivo. dellimplementazione. La Figura 9-3 mostra un esempio dellimpatto della perdita di un singolo pacchetto IP (contenente sette pacchetti MPEG-

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.312 quadro). Se il pacchetto perso coinvolge un quadro B, il 2) su un quadro video nel caso in cui linformazione persa deterioramento interessa solo quel quadro della durata di 33 faccia parte di un quadro B (a sinistra) o di un quadro I (a ms. Si noti che nellesempio riportato in figura non stato destra). Dato che il quadro I un quadro chiave usato nella inserito nessun algoritmo di occultamento delle perdite nel compressione dei seguenti quadri P e B, il deterioramento decodificatore. del quadro I si propaga nel tempo attraverso 14 quadri video (GOP) o per almeno mezzo secondo (assumendo 33 ms per

Figura 9-3: Impatto delle perdita di un singolo pacchetto IP (quadro B e quadro I) I quadri codificati (I, P o B) contengono dei timestamp, come ad esempio il Program Clock Reference (PCR). Il rate con cui vengono inviati i quadri I controllabile, e ha effetto sulla resistenza della codifica alla perdita di pacchetti, sulla banda

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.313 oppure come elemento principale (ad esempio nel servizio di e sul ritardo. Inviare quadri I ad un rate pi alto riduce il Music on Demand). tempo di recupero da una perdita di pacchetti e il ritardo tra il Leffetto della perdita dei pacchetti sulle combinazioni di momento in cui un ricevitore si unisce ad uno stream in stream collegati (ad esempio audio e video combinati come corso e il momento in cui pu iniziare a decodificare e un singolo contenuto per lutente finale) un argomento di visualizzare lo stream, tutto questo al prezzo di un maggiore base per lo sviluppo delle metriche per la Quality of utilizzo della banda. necessario quindi un compromesso Experience (QoE). tra la capacit di recupero degli errori e loccupazione di banda. Limpatto della perdita dellinformazione di segnalazione e di controllo un'altra problematica potenziale. Sebbene alcune Da quanto finora esposto risulta quindi fondamentale, per informazioni di segnalazione e controllo possano essere minimizzare limpatto della perdita dei pacchetti IP sulla aggiornate periodicamente (ad esempio le EPG), leffetto codifica, determinare sia le opzioni di codifica sia le strutture della perdita dipende in realt dalla specifica informazione di di pacchettizzazione pi convenienti. controllo persa. Questo rappresenta pi un problema di Ci, ovviamente non si limita al caso di codifica MPEG-2 robustezza nel progetto di un sistema o di un protocollo. Per incapsulata nel TS, ma analoghe considerazioni possono esempio, la configurazione dei meccanismi di cifratura e di valere per codifiche video e pacchettizzazioni differenti. Ad scambio delle chiavi dovrebbe essere molto robusta dato esempio lATIS esamina i casi di altri tipi di codifiche video che gli eventi di perdita dei pacchetti in tal caso devono (come ad esempio H.264, AVC o VC-1) incapsulate essere totalmente recuperati. direttamente in RTP, piuttosto che nei TS MPEG-2. Analogo interesse riveste anche lo studio delleffetto della perdita dei pacchetti sullinformazione audio MPEG, dato che i servizi diffusivi includono linformazione audio, o come una componente dello stream del contenuto televisivo,

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.314 In particolare, le metriche raccomandate vengono organizzate in quattro livelli di qualit, definiti in [155], 9.2 Metriche di qualit del servizio ovvero: Per la caratterizzazione dettagliata della qualit di un servizio lapproccio comunemente seguito quello di definire una serie di metriche, ovvero di misure di uno o pi parametri di un modello, atto a rappresentare alcuni aspetti delle prestazioni di un servizio. Esistono molteplici definizioni di metriche per servizi di diffusione televisiva ed alcune relative in particolare alla diffusione di contenuti audio video su reti IP. Tra le prime si ricorda, come fondamentale, la norma DVB [154], specifica per le piattaforme di diffusione di programmi televisivi con codifica MPEG-2, utilizzando il TS MPEG-2. Tra le seconde si possono menzionare le metriche [156], [157] [158], [159], [145], [160], [161], [36], [144] e [162] e quelle ITU-T [163] e [143] per parametri legati al trasporto IP (jitter, ritardo oltre soglia, ecc.). In questo paragrafo, si riporta con un certo dettaglio il punto di vista dellATIS, definito nei documenti [153], [140] e [155], in quanto fornisce un approccio integrato alla problematica delle metriche per servizi di diffusione televisiva su rete IP, giungendo a raccomandare luso di insiemi di metriche specifici per aspetti differenti della QoS.

Qualit della Transazione (Transaction Quality), cio dellinterazione del servizio con lutente; illustrati graficamente nella Figura 9-4 in cui si evidenziano anche gli indicatori di QoE la cui relazioni con i parametri di QoS deve essere ulteriormente specificata. Per ciascuno di questi livelli vengono suggeriti opportuni insiemi di metriche.

Qualit del Trasporto (Transmission Quality); Qualit dei Media Stream (Media Stream Quality); Qualit del Contenuto (Content Quality);

Figura 9-4: Classificazione dei livello di qualit, dei parametri di QoS e degli indicatori di QoE

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.315 di tipo on demand basati su indirizzamento unicast. Nel caso Questa organizzazione dei livelli di qualit pu essere di servizi Broadcast Lineari basati su indirizzamento daiuto nel valutare la metodologia di strumentazione che multicast, viene prevista unanalisi futura basata sulla rete deve essere impiegata in una determinata rete e in MBone, per fornire valutazioni sulle prestazioni di rete particolari punti di misurazione. attese. LATIS definisce infatti anche una serie di possibili punti di misurazione delle metriche distribuiti lungo il percorso 9.2.1 I servizi Broadcast Lineari end-to-end che va dalla sorgente del servizio ovvero Video Head End (VHE) (con terminologia conforme allarchitettura Il documento [140] descrive i servizi Broadcast Lineari come ATIS) allIPTV Terminal Function (ITF) dellutente del analoghi alla classica forma di televisione offerta su servizio. La definizione di tali punti aiuta ad adattare le piattaforme terrestri o satellitari. misurazioni alle specifiche esigenze dei differenti attori Un servizio Broadcast Lineare fornisce uno stream (domini), che contribuiscono alla realizzazione del servizio, essenzialmente continuo che scorre dal Content Provider restringendo ad esempio le misurazioni ad uno solo dei allITF (ovvero il Set Top Box), attraversando i domini del domini dellarchitettura (cfr. 7). Service Provider e del Network Provider, come definiti Si tenga presente che linsieme delle metriche QoS dallarchitettura, [140]. Il Service Provider acquisisce il specificato in [153] non esaustivo, in quanto al momento contenuto da una sorgente (Content Provider) e lo converte dellapprovazione di tale documento larchitettura IPTV in uno stream continuo di pacchetti per la distribuzione e la dellATIS non era stata ancora definita in maniera completa. visualizzazione finale sullo schermo dellITF. Il Service Le metriche raccomandate dallATIS si riferiscono a servizi Broadcast Lineari, definiti in [140], anche se molte di queste possono essere applicate ad altri servizi IPTV, come ad esempio il Video On Demand (VOD). Ci a maggior ragione dal momento che, per definire tali metriche, lATIS riporta delle considerazioni, la cui maggior parte relativa a servizi Provider pu replicare lo stream per pi Network Provider usando una struttura IP Multicast e i Network Provider possono a loro volta replicare lo stream per pi reti domestiche. Il Service Provider pu fornire elaborazioni aggiuntive dello stream video (ad esempio, inserimento di canali a contenuto locale, inserimento di pubblicit e altro).

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.316 Il servizio Broadcast Lineare pu essere offerto in diversi modi (corrispondenti a differenti modelli di business), in cui i Livello di qualit corrispondente ruoli associati ai diversi domini possono essere svolti Qualit di Trasporto distintamente da provider differenti oppure aggregati da Qualit dei Media Stream parte di provider multi-ruolo. Qualit del Contenuto (Payload) In relazione a tali modelli, le misurazioni possono essere o Qualit della Transazione meno ristrette per dominio. Un dominio pu scegliere di condividere un sottoinsieme (ad esempio in forma aggregata) della quantit di informazioni derivanti dalle misurazioni. Perci, i modelli di business possono avere effetto su come e su cosa pu essere misurato e quindi dovrebbero essere tenuti in considerazione quando vengono raccomandate misurazioni di metriche. 9.2.1.1 Punti di misurazione Con una schematizzazione fatta per domini, lATIS nella Figura 9-5 illustra il modello di riferimento ad alto livello per la misurazione della QoS. In questo modello vengono identificati i reference point per le misurazioni e rappresentati, con opportuna simbologia (cfr. Tabella 9-3), i punti di misurazione, relativi ai differenti livelli di qualit definiti. Tabella 9-3: Simbologia punti di misurazione Le linee tratteggiate rappresentano interazioni di controllo o di trasferimento file o fisiche, le linee continue rappresentano flussi di streaming. Nel documento [155] viene fornito un modello pi dettagliato di quello riportato in Figura 9-5 per tener conto della possibile inserzione di contenuti nei nodi intermedi (VHO, VSO) del dominio del Network Provider. Per le metriche raccomandate sono definiti i possibili punti di misurazione in relazione a tali modelli.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.317

Figura 9-5: Modello ad alto livello per la misurazione della QoS scenario di fruizione del servizio Broadcast Lineare da parte di un utente dotato di ITF. Da una prospettiva di servizio, nel Broadcast Lineare possono essere identificate le seguenti azioni eseguite dallutente:

9.2.2 Scenario di fruizione del servizio Broadcast Lineare Al fine di rendere pi esplicita lanalisi e la collocazione, nellambito dei differenti livelli di qualit definiti, delle metriche prescelte, il documento [153] introduce un tipico

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.318 richiesto allapplicazione supporto allutente per essere 1. accensione del STB (cfr. 9.2.2.1); 2. uso della EPG e selezione di uno stream/canale pronta a ricevere gli input dellutente. (cfr. 9.2.2.2); 3. visione di uno stream/canale (cfr. 9.2.2.3); 9.2.2.2 Step 2: Uso dellEPG per selezionare 4. selezione di un canale differente (cambio canale) uno stream/canale IPTV (cfr. 9.2.2.4); Lutente utilizza lEPG, per selezionare i servizi (ad esempio, 5. spegnimento del STB o transito su servizi Video On Demand (cfr. 9.2.2.5). i canali) disponibili. comune che lutente usi un Nei paragrafi seguenti sono descritte le cinque fasi telecomando per controllare la navigazione tramite lEPG. identificate ed introdotti esempi di categorie di metriche di La disponibilit, la semplicit duso, la correttezza e la QoS per ogni fase. velocit di risposta sono alcuni esempi di metriche di qualit del servizio o di criteri associati allEPG. LATIS si concentra 9.2.2.1 Step1: Accensione del Set Top Box sulla velocit di risposta dellEPG. Per lutente importante il tempo che il dispositivo impiega Determinare quali problemi sussistano per la generazione o per avviarsi ed essere pronto per la fruizione di servizi. linstradamento di un canale verso un ITF significa, quindi, LATIS assume che lITF, al momento dellavvio prima di valutare la Quality of Experience (QoE), relativamente alla raggiungere la modalit di disponibilit del servizio, prenda selezione di un canale in rete. Le latenze dei Join e Leave parte ad un insieme di comunicazioni di setup/controllo IGMP sono considerate metriche importanti, dal momento coinvolgenti le funzioni per laccesso alla rete/servizio che sono in relazione con il tempo impiegato per mostrare il orientati allIPTV nelle reti del Service Provider (SP)/Network nuovo canale, qualora il sistema debba attendere lo stop del Provider (NP). Il traffico scambiato in questa fase tutto di vecchio canale prima della trasmissione di quello nuovo. controllo. Inoltre, il cambiamento del canale pu essere bloccato a Esempi di metriche includono il tempo di boot necessario al causa del DRM e quindi dovr essere definita una metrica Sistema Operativo dellITF per essere pronto e il tempo DRM nellITF per identificare la perdita del servizio per questa ragione.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.319 9.2.2.3 Step 3: Visione di uno stream/canale il tempo con cui il buffer di compensazione del jitter dellITF raggiunge il massimo livello della sua capacit IPTV di ridurre il jitter prima di inoltrare il segnale video alla Lo scenario in cui un utente guarda uno stream/canale IPTV funzione di decodifica. pu essere caratterizzato dallesperienza visiva e uditiva del Da un punto di vista delle perdite di pacchetti IP (che si fruitore del servizio. Molti aspetti del servizio, tra cui i ripercuotono sui relativi pacchetti MPEG-TS), per identificare problemi nella qualit del contenuto video, il trasporto del un rimedio per la degradazione e il blocco del servizio per i video e le prestazioni del livello di trasporto IP, possono canali visualizzati sono necessarie metodologie per influenzare il video. individuino in modo specifico il tipo e la sorgente dellerrore. Esempi di deterioramenti del segnale video includono il Esempi di categorie di metriche, che possono essere blocco immagine, il blurring, la distorsione ai bordi e altro. utilizzate in questa fase, riguardano principalmente, ma non Questi deterioramenti possono essere il risultato di vari esclusivamente, la qualit del trasporto. elementi nellarchitettura di Service Delivery. Un esempio In tale ambito si ricordano: pu essere la creazione di uno stream video per includere la le metriche IETF [156], [157] [158], [159], [145], [160], pubblicit (esistono parecchi punti di inserzione possibili [161], [36], [144], [162] e ITU-T [163], [143], come il nellarchitettura). Inoltre, sono importanti la qualit dellaudio jitter, la perdita (ritardo oltre la soglia), i gap e i burst; e la sincronizzazione con il segnale video. In questa fase il le metriche definite [154] per le piattaforme DVB che traffico tutto di tipo dati ed , di solito, unidirezionale includono le metriche MPEG-2 TS; (include solo la ricezione del segnale). le ritrasmissioni. Da un punto di vista dellanalisi delle prestazioni in termini di latenza di un flusso IPTV Broadcast Lineare specifico, si 9.2.2.4 Step4: Cambio canale considerano determinanti i due seguenti fattori: Con lazione cambio canale si identifica uno scenario in cui

il tempo necessario allapplicazione nellITF per elaborare i pacchetti in ingresso e consegnare il contenuto al decodificatore MPEG;

il fruitore del servizio passa da un canale allaltro, ma rimane allinterno della tipologia di servizio Broadcast Lineare (invece di passare ad unaltra tipologia di servizio IPTV tra

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.320 di ridurre il jitter, prima di inoltrare il segnale video alla quelli definiti in [140]). Ci si aspetta che vi possano essere funzione di decodifica; piccole differenze di prestazione a seconda del servizio il tempo richiesto nellITF dal processo di decodifica IPTV che viene selezionato. MPEG. I servizi Broadcast Lineari vengono generalmente supportati usando tecniche di trasporto multicast. Il tempo per ricevere 9.2.2.5 Step 5: Spegnimento del STB o transito il nuovo canale pu essere influenzato dalla locazione del sul VOD canale televisivo nella rete, per esempio in prossimit del Lutente non dovrebbe avere alcun interesse di prestazione DSLAM o in locazioni pi remote nellarchitettura del in questa fase, che viene menzionato solo per completezza. Network Provider (che coinvolge uno o pi proxy IGMP). Il traffico generato in tale fase tutto di controllo. Un esempio dei tempi che intervengono nelloperazione di cambio di canale, legati al flusso di controllo e dati il seguente: 9.2.3 Metriche per il servizio Broadcast Lineare Si definiscono delle metriche che soddisfano la necessit di misurazione di un sistema end-to-end basato sullo scenario di fruizione definito nel 9.2.1. Il documento [153] include due insiemi di metriche, classificate come Metriche Primarie (cfr. 9.2.3.3) e Metriche Raccomandate (cfr. 9.2.3.4), assunte universali e di utilit in tutte le implementazioni di servizi IPTV in reti differenti. Prima di riportare i due insiemi di metriche vengono illustrate le informazioni ausiliarie per la loro esatta definizione. Infatti per fornire flessibilit senza ambiguit, le metriche sono completamente definite quando vengono combinate con linformazione ancillary. Ci deriva dal fatto che le singole metriche, a volte, possono essere presentate con differenti

il tempo impiegato per lo scambio di informazioni per il DRM che pu bloccare il Content Delivery; il tempo tra lazione dellutente e la trasmissione dei messaggi multicast (ovvero leave/join) alla rete; il tempo impiegato da tutti gli elementi di rete per elaborare le richieste multicast e larrivo dello stream multicast allITF (ovvero la latenza di join e di leave dellITF); il tempo necessario allapplicazione nellITF per elaborare i pacchetti in entrata e consegnare il contenuto al motore di decodifica MPEG; il tempo con cui il buffer di compensazione del jitter dellITF raggiunge il massimo livello della sua capacit

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.321 durate, periodi di misurazione ed accuratezze; inoltre limiti (ovvero la perdita di pi di un dato numero di possono essere riportate come valori individuali o statistiche pacchetti indistinguibile a causa della dimensione del numero di sequenza); aggregate per intervalli diversi. Linformazione ancillary viene chiamata colloquialmente informazione di header, tempo di inizio (Anno-Mese-Giorno Ore:Minuti:Secondi). dal momento che pu apparire una sola volta nellheader di un file contenente molte istanze di valori delle metriche. Questi dati possono anche trovarsi in un elemento di configurazione. Le metriche sono completamente specificate quando accompagnate dalle seguenti informazioni ancillary: 9.2.3.1 Comportamento delle metriche

il nome della metrica cui si riferisce lheader in questione; la durata di ogni misurazione: unit della durata (per esempio, secondi); se la metrica una singola misurazione o una statistica: se una statistica che tipo di statistica (massimo, minimo, medio, o altro); se una statistica il numero totale delle misurazione che compongono la statistica.

I contatori smettono di aumentare al loro valore massimo (cio, un contatore a 16 bit con un valore di 65535 non incrementer ulteriormente finch non venga reimpostato a zero). Le proporzioni vengono espresse come una frazione binaria, essendo 0xFFFF la pi grande proporzione esprimibile. Per esempio, 0 sarebbe espresso come 0x0000 e 1 come 0xFFFF. Il tipo il formato per le comunicazioni a livello macchina e pu essere usato per calcolare un valore di presentazione comprensibile per luomo. I periodi di tempo sono limitati dal valore pi grande esprimibile, per esempio un contatore di millisecondi a 16 bit, con un valore di 65535 rappresenterebbe un valore di 65535 secondi o maggiore. Gli intervalli di tempo usati per calcolare le proporzioni sono in secondi. Il jitter e il ritardo sono espressi in millisecondi.

Le metriche dovrebbero essere specificate con le seguenti informazioni ancillary:

accuratezza;


I calcoli che eseguono una divisione per zero restituiscono un output pari a zero. Tutte le metriche si riferiscono a un singolo stream IPTV. I valori Mean Opinion Score (MOS) vengono espressi come una funzione binaria moltiplicata per 4 pi 1, essendo 0xFFFF la pi grande proporzione esprimibile. Per esempio, 1 sar espresso come 0x0000 e 5 come 0xFFFF. I valori possono essere decimali compresi tra 1 e 5, con 5 eccellente e 1 cattivo.

I livelli di jitter dovrebbero essere misurati con un accuratezza migliore di 2 millisecondi. Tuttavia, in alcuni punti di misurazione questo non possibile.

9.2.3.3 Metriche primarie La tabella che segue mostra le metriche primarie su cui si basano le metriche IPTV raccomandate. Queste metriche rappresentano le metriche di base che potrebbero essere misurate in un sistema end-to-end. LATIS non assume che venga sempre utilizzato lRTP e permette il trasporto del Transport Stream MPEG direttamente su UDP. In questo ultimo caso (ovvero quando non viene usato lRTP) risulta complicato calcolare in maniera accurata molte metriche generalmente riferite ai pacchetti IP, tra cui la quantit di pacchetti scartati.

9.2.3.2 Accuratezza delle metriche

Le proporzioni e i contatori possono soffrire di inaccuratezze o differenze dovute sia alla definizione dellintervallo di misurazione sia al rate potenzialmente elevato di pacchetti allinterno del sistema IPTV. Ad esempio si noti che nelle misurazioni che si affidano sul campo a 4 bit Continuity Counter del Transport Stream, questo pu essere utilizzato solamente per rilevare sequenze relativamente corte di pacchetti persi. I ritardi dovrebbero essere misurati con unaccuratezza migliore di 5 millisecondi. Tuttavia, in alcuni punti di misurazione questo non possibile.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.323 Nome Total Packets Received Total Packets Lost Total Packets Discarded Total Bytes Received Total Expected Bytes Total Expected Packets Out-of Order Packets Gap Count Gap Loss Gap Length Burst Count Burst Loss Burst Length Burst Bytes Length Gmin Threshold MPEG-2 TS PSI Error Threshold Definizione Numero totale di pacchetti ricevuti in un intervallo di misurazione (il tipo del pacchetto viene identificato nellheader) Numero totale di pacchetti persi o corrotti in un intervallo di misurazione (non include gli scarti) Numero totale di pacchetti scartati in un intervallo di misurazione (include le perdite dovute ad arrivo in ritardo o fuori sequenza) Numero totale di byte ricevuti in un intervallo di misurazione Numero totale di byte attesi in un intervallo di misurazione Numero totale di pacchetti attesi in un intervallo di misurazione (il tipo del pacchetto viene identificato nellheader) Numero di pacchetti fuori sequenza in un intervallo di misurazione [162] Numero di gap in un intervallo di misurazione. Un gap viene misurato come un intervallo tra due burst [144] Numero di pacchetti persi durante un gap [144] Numero di pacchetti attesi durante i gap in un intervallo di misurazione [144] Numero di burst in un intervallo di misurazione. Un burst viene misurato in una finestra scorrevole in cui viene perso pi di un pacchetto [144] Numero di pacchetti persi durante i burst per un dato intervallo di misurazione [144] Numero di pacchetti attesi durante i burst per un dato intervallo di misurazione [144] Numero di byte attesi durante i burst per un dato intervallo di misurazione [144] Numero minimo di pacchetti che devono essere ricevuti prima e dopo un pacchetto perso affinch questo venga classificato in un gap [144] Tempo in cui viene superato il tempo atteso di ricezione delle tavole PSI (Il valore di default 500 ms e viene usato per incrementare un contatore piuttosto che un evento come definito in [154]) Numero totale di byte in un MPEG TS PID per un dato intervallo di misurazione [154] Millisecondi che superano listante di ricezione atteso del Presentation Time Stamp [154] Tipo Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Contatore Millisecondi

MPEG-2 TS Total Bytes per PID MPEG-2 TS Presentation Time Stamp (PTS) Error Threshold

Contatore Millisecondi

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.324 Nome Total Bytes per program/channel Measurement Interval Report Interval Sampling Interval Loss Period Threshold Loss Distance Threshold IPTV Definizione Numero totale di byte in un programma/canale IPTV per un dato intervallo di misurazione Periodo di tempo della finestra di misurazione Tempo per compilare un array di metriche di QoS da riportare Intervallo di tempo alla fine del quale viene calcolato il valore di una variabile Massimo numero di pacchetti persi consecutivi [145] Minimo numero di pacchetti consecutivi ricevuti tra due Loss Period [145] Tipo Contatore Secondi Secondi Secondi Contatore Contatore

Tabella 9-4: Metriche primarie Per le metriche raccomandate sono definiti i possibili punti di misurazione riportati nel modello di Figura 9-5 con riferimento ai menzionati livelli di qualit.

9.2.3.4 Metriche raccomandate per lIPTV La lista delle metriche raccomandate da ATIS [155] riportata in Tabella 9-5. Le metriche raccomandate sono organizzate nei livelli di qualit definiti in [155] (cfr. 9.2).Nome

Definizione Metriche riguardanti la qualit della trasmissione

Tipo

RTP Packet Loss Rate before Error Correction (EC) [proporzione] RTP Packet Loss Rate after EC [proporzione]

Totale dei pacchetti persi sul totale dei pacchetti attesi per un dato intervallo di misura, calcolato prima dei meccanismi di correzione derrore (quali FEC e ARQ). un indicatore di errori della rete e riguarda la possibilit per un utente di guardare un programma/canale senza correzioni derrore. Totale dei pacchetti persi sul totale dei pacchetti attesi per un dato intervallo di misura, calcolato dopo i meccanismi di correzione derrore (quali FEC e ARQ). Misura lefficacia delle tecniche di correzione per modificarle, se necessario, per incrementare la QoE

intero 16 bit senza segno


La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.325 Nome Definizione Totale dei pacchetti scartati sul totale dei pacchetti attesi per un dato intervallo di misura. RTP Packet Discard Rate la proporzione di pacchetti scartati perch arrivati con un certo ritardo o fuori sequenza se il decoder non pu [proporzione] riordinare i pacchetti. Identifica gli eventi di errore (scarto di pacchetti) aggiuntivi rispetto alle perdite di pacchetti allinterno rete Out of Order Packet Rate Totale dei pacchetti fuori sequenza sul totale dei pacchetti attesi per un dato intervallo di misura. [proporzione] la proporzione di pacchetti arrivati fuori sequenza. indicativo delle condizioni della rete. RTP Burst Loss Rate before EC [proporzione] RTP Burst Loss Rate after EC [proporzione] RTP Burst Length before EC [contatore] RTP Burst Loss Rate after EC [proporzione] RTP Gap Loss Rate before EC [proporzione] RTP Burst Loss Rate after EC [proporzione] Totale dei pacchetti persi in un burst (cfr. tabella precedente) sul totale dei pacchetti nel burst, calcolata prima dei meccanismi di correzione derrore. la proporzione di pacchetti persi allinterno di un burst. Indica come influiscano le perdite transitorie gravi ed utile per configurare le tecniche di correzione derrore. Totale dei pacchetti persi in un burst sul totale dei pacchetti nel burst, calcolata dopo i meccanismi di correzione derrore. la proporzione di pacchetti non corretti allinterno di un burst. Combina distribuzione di scarti e perdite. Indica la gravit dei problemi transitori che danneggiano la qualit video. Lunghezza dei periodi burst calcolata prima dei meccanismi di correzione derrore. Indica come influiscono le perdite transitorie gravi ed utile per configurare le tecniche di correzione derrore. Lunghezza media dei periodi burst. calcolata dopo i meccanismi di correzione derrore. Indica come influiscono le perdite transitorie gravi. Totale dei pacchetti persi in un gap (cfr. tabella precedente) sul totale di pacchetti attesi nel periodo del gap, calcolato prima dei meccanismi di correzione derrore. la proporzione di pacchetti persi allinterno del periodo del gap. Indica le condizioni di perdita durante un periodo di buona qualit. Totale dei pacchetti persi in un gap sul totale di pacchetti attesi nel periodo del gap, calcolata dopo i meccanismi di correzione derrore. la proporzione di pacchetti non corretti allinterno del periodo del gap. un indicatore delle perdite residue durante un periodo di buona qualit; combina distribuzione di scarti e perdite. intero 16 bit senza segno intero 16 bit senza segno intero 16 bit senza segno intero 16 bit senza segno Tipo

intero 16 bit senza segno intero 32 bit senza segno intero 16 bit senza segno


La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.326 Nome Mean RTP Gap Length before EC [proporzione] Mean RTP Burst Length after EC [proporzione] Smoothing jitter [tempo] Peak Packet to Packet Delay Variation (PPDV) [tempo] RTP Loss Period Count [contatore] Definizione La lunghezza media dei gap tra burst consecutivi in un intervallo di misurazione, calcolata prima dei meccanismi di correzione derrore. Indica le condizioni di perdita durante un periodo di buona qualit. La lunghezza media di gap tra burst in un intervallo di misurazione, calcolata dopo i meccanismi di correzione derrore. un indicatore delle perdite residue durante un periodo di buona qualit;combina la distribuzione di scarti e perdite. Tipo intero 16 bit senza segno


Variazione del ritardo dovuto allo smoothing previsto del flusso di pacchetti (IP o RTP) in un intervallo di intero 32 bit campionamento. senza segno Indica la scala delle variazioni di ritardo nel punto di ricezione che non sono dovute a congestione di rete; il jitter di (millisecondi) trasporto. Variazione del ritardo tra pacchetto e pacchetto (IP o RTP) in un intervallo di campionamento. Indica la scala delle variazioni di ritardo nel punto di ricezione che sono dovute a congestione di rete; il jitter istantaneo della rete. Conteggio del numero delle volte che il periodo di perdita eccede la soglia del periodo di perdite come definita nella tabella precedente. Indica la frequenza di ricorrenza di perdite gravi che portano al blocco della visualizzazione (schermo nero). utile per definire le tecniche di correzione pi idonee. Conteggio delle volte che il numero dei pacchetti RTP ricevuti tra eventi di perdita eccedenti la soglia Loss Period Threshold minore della Loss Distance Threshold come definita nella tabella precedente. intero 32 bit senza segno (millisecondi) intero 16 bit senza segno

RTP Loss Distance Count intero 16 bit Indica la frequenza di condizioni per cui il video sfarfaller a causa delle perdite dello schermo dovute alleccedenza [contatore] senza segno di perdita che portano il ricevitore a non avere abbastanza pacchetti per ricoprire lo schermo. utile per definire le tecniche di correzione pi idonee. RTP Minimum Loss Distance [contatore] Minimo numero di pacchetti RTP tra eventi di perdita eccedenti la soglia Loss Period Threshold. Pu esser utilizzato per determinare se lITF in grado di recuperare e mostrare il canale allutente. utile per definire le tecniche di correzione pi idonee. intero 16 bit senza segno

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.327 Nome RTP Maximum Loss Period [contatore] Packet Retransmissions [contatore] Definizione Massimo numero di pacchetti RTP in un evento di perdita eccedente la soglia Loss Period Threshold. Riporter il massimo tempo per il quale uno schermo sfarfalla o diventa nero. utile per definire le tecniche di correzione pi idonee. Numero di pacchetti RTP/UDP ritrasmessi in un intervallo di misurazione. indicativa delle condizioni derrore e delluso della banda. Metriche riguardanti la qualit dei Media Stream MPEG-2 TS Sync Loss Count [contatore] MPEG-2 TS Sync Byte Error Count [contatore] MPEG-2 TS Continuity Count Error Count [contatore] MPEG-2 TS PID Error Count [contatore] MPEG-2 TS Program Specific Information (PSI) error Count [contatore] Conteggio degli eventi di perdita di sincronizzazione a livello di TS MPEG-2, [154]. intero 32 bit senza segno intero 32 bit senza segno intero 16 bit senza segno intero 16 bit senza segno Tipo

Conteggio dei byte indicatori di sincronizzazione nel TS MPEG-2 errati, [154].

Conteggio dellordine non corretto di pacchetti, di pacchetti duplicati o di eventi di pacchetti persi al livello di TS MPEG-2 su base PID, [154].


Conteggio delle occorrenze di errori su un PID definiti come: il PID non ricorre nel periodo specificato dallutente, [154]. Somma di PAT_error, PAT_error2, PMT_error, PMT_error2 come definiti in [154], per ogni evento, occorrente in un intervallo di campionamento, che eccede la soglia MPEG-2 TS PSI Error Threshold definita nella tabella precedente. Indica se gli elementi delle tabelle trasportate nel TS MPEG-2 mancano o sono errati. Metriche riguardanti la qualit dei contenuti



La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.328 Nome MOS-V [MOS da 1 (cattivo) a 5 (eccellente)] MOS-A [MOS da 1 (cattivo) a 5 (eccellente)] MOS-AV [MOS da 1 (cattivo) a 5 (eccellente)] MPEG-2 TS Per PID bandwidth [bitrate] Program/ channel Bandwidth [bitrate] MPEG-2 TS PCR jitter [tempo] MPEG-2 TS PCR Failures Count [contatore] Definizione Video MOS, la stima della qualit delle immagini percepita dallutente. Questa metrica viene fornita relativamente alla visione di un programma senza audio e dipende dalla qualit della sorgente, dalla risoluzione dellimmagine, dalla codifica, dai codificatori, dalla trasmissione e dal mascheramento degli errori. Audio MOS, la stima della qualit dellaudio percepita dallutente. Questa metrica viene fornita relativamente allascolto un programma e dipende dalla qualit della sorgente, dalla qualit dellaudio, dalla codifica, dai codificatori, dalla trasmissione e dal mascheramento degli errori. Tipo intero 16 bit senza segno


Audio-Video MOS, la stima della qualit dellaudio e del video combinata percepita dallutente. Questa metrica viene fornita relativamente alla visione di un programma e dipende dalla qualit della sorgente, dalla intero 16 bit risoluzione dellimmagine, dalla qualit dellaudio, dalla sincronizzazione AV, dalla codifica, dai codificatori, dalla senza segno trasmissione e dal mascheramento degli errori. Larghezza di banda per un certo PID, escludendo loverhead IP. Questa metrica riporter il bitrate associato a un PID per aiutare ad identificare la congestione e la perdita di pacchetti relativamente ad uno stream MPEG elementare. intero 32 bit senza segno (bps)

Totale della larghezza di banda per un programma/canale includendo overhead RTP, UDP e IP. Si esclude il FEC e intero 32 bit la ritrasmissione. senza segno Questa metrica utile per stabilire se il programma/canale causer congestione in rete. (bps) utile per lallocazione della banda. Livello di jitter PCR. intero 32 bit Questa metrica consente di identificare gli istanti in cui la selezione di un canale e la sua visione non sar permessa senza segno a causa di un disallineamento dellorologio PCR causato del jitter PCR. (millisecondi) Somma dei valori di PCR Error, PCR Repetition Error, and PCR Discontinuity Indicator Error counts, come definiti in [154], in un intervallo di campionamento. intero 32 bit Questa metrica identificher i momenti in cui la selezione di un canale e la sua visione non sar permessa a causa senza segno di assenza di informazioni sulla temporizzazione PCR e la perdita di allineamento dellorologio del PCR.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.329 Nome Buffer ITF overflow [contatore] Buffer ITF underflow [contatore] AV Synch [tempo] Definizione Numero totale di volte in cui il jitter del buffer di ricezione va in overflow per un programma/canale. Questa metrica identifica gli istanti in cui lo schermo dellutente sfarfaller o si bloccher. Numero totale di volte in cui il jitter del buffer di ricezione va in underflow per un programma/canale. Questa metrica identifica gli istanti in cui lo schermo dellutente sfarfaller o si bloccher. La differenza nel tempo di playout tra audio e video stream. Questa metrica identifica il momento in cui la visione di un canale danneggiata a causa disallineamento tra audio e video. Questa metrica pu essere di difficile calcolo. Tipo intero 16 bit senza segno intero 16 bit senza segno 16 bit senza segno (millisecondi) intero 16 bit senza segno

MPEG-2 TS Proportion of I frames or slices impaired Numero di quadri I o slice danneggiati su il numero totale di quadri I o slice ricevuti. [proporzione] MPEG-2 TS Proportion of P and B frames or slices Numero di quadri P e B o slice danneggiate su il numero totale di quadri P e B o slice ricevute. impaired [proporzione] MPEG-2 TS Packet loss rate within I frames Numero di pacchetti persi o scartati sul numero totale di pacchetti attesi allinterno dei quadri I. [proporzione] MPEG-2 TS Packet loss rate within P and B frames Numero di pacchetti persi o scartati sul numero totale di pacchetti attesi allinterno dei quadri P e B. [proporzione] Metriche riguardanti la qualit della transazione IGMP Join Latency [tempo] Tempo trascorso tra la trasmissione di un messaggio IGMP join e la ricezione del primo pacchetto video di un target media stream. Questa influisce sullesperienza dellutente nel momento in cui questo ultimo seleziona e cambia canale.


intero 16 bit senza segno intero 16 bit senza segno

16 bit senza segno (millisecondi)

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.330 Nome IGMP Leave Latency [tempo] Definizione Tempo trascorso tra la trasmissione di un messaggio IGMP leave e la ricezione dellultimo pacchetto video di un target media stream. Questa influisce sullesperienza dellutente nel momento in cui questo ultimo scegli e scambi canale. Tempo trascorso tra il tempo in cui lITF richiede un canale differente al tempo in cui il video totalmente riportato sul display dello schermo. Questa influisce sullesperienza dellutente nel momento in cui questo ultimo scegli e scambi canale. Numero di servizi distinti che risentono degli eventi di guasto sul sistema DRM. Questa metrica aiuter nel valutare le operazioni di cambio di canale e di richiesta di visione di un programma bloccato dal sistema DRM. Si considerano gli eventi di guasto del sistema DRM, evidenziando i difetti DRM che possono ripercuotersi sui servizi. Service_Impairments_Error (cfr. 5.5.3 di [154]), numero di occorrenze in cui il servizio MPEG disponibile ma danneggiato. Questa metrica identifica i momenti in cui il canale selezionato (e la relativa visione) potrebbe essere danneggiato. Tempo trascorso dal momento in cui il client IPG (Interactive Program Guide) nellITF richiede i dati di servizio IPG al transaction server al momento in cui avviene la ricezione. Questo influenza la velocit alla quale la guida ai programmi viene aggiornata sullo schermo, se lITF non possiede nella cache linformazione. Tempo trascorso dal momento in cui si accende lITF fino a quando il sistema operativo pronto. Valori di soglia potrebbero esser appropriati per questa metrica. Tempo trascorso dal momento in cui il sistema operativo pronto fino a quando lapplicazione di servizio visibile sullo schermo e lITF online e pronto per linput dellutente. Linizializzazione dellITF coinvolge una serie di transazioni quali autorizzazione, discovery e altre. Questa metrica aiuta lidentificazione dei problemi in questa fase. Valori di soglia potrebbero esser appropriati per questa metrica. Tipo 16 bit senza segno (millisecondi) 16 bit senza segno (millisecondi) intero 16 bit senza segno

Channel Change Delay [tempo]

DRM Error [contatore] MPEG-2 TS Service Impairments Error [contatore] IPG Transaction Delay [tempo]


ms 16 bit senza segno 32 bit senza segno (millisecondi) 32 bit senza segno (millisecondi)

ITF OS Boot Time [tempo]

ITF Service Boot Time [tempo]

Tabella 9-5: Metriche consigliate dall'ATIS

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.331 obiettivi sul jitter sono basati sulle esperienze degli operatori e sulle capacit di buffering dei STB. 9.3 Requisiti ed obiettivi per la qualit del

trasportoLe tabelle e i grafici che vengono illustrati in questo paragrafo riportano i requisiti di perdita, latenza e jitter nel trasporto dei pacchetti IP, per ottenere degli obiettivi soddisfacenti di qualit del servizio. I risultati riportati si basano sul corposo lavoro del DSL Forum, [146], ripreso successivamente da ATIS [164] e recentemente da ITU-T, [100]. Latenza e jitter La latenza e il jitter di rete dovrebbero essere progettati per allinearsi strettamente con i parametri del STB (come il tempo dattesa e la dimensione del buffer) e con il disegno generale della rete e quindi possono variare a seconda dellimplementazione. Tipici buffer de-jitter dei STB possono immagazzinare 100-500 ms di video (di tipo SDTV), quindi il jitter della rete deve essere contenuto in questi limiti e variazioni di ritardo, oltre questi, si manifesteranno come perdite. Anche aumentare il buffering produce effetti negativi sulla latenza del cambiamento di canale, quindi idealmente i buffer de-jitter dovrebbero essere il pi piccoli possibile. Gli Perdita di pacchetti Gli obiettivi sulla perdita dei pacchetti vengono fissati in termini di periodo di perdita e distanza di perdita, come definiti nella specifica [145]. Essenzialmente la distanza di perdita una misura dellintervallo tra eventi di perdita dei pacchetti o derrore consecutivi, mentre un periodo di perdita la durata di un evento di perdita o derrore (per esempio, quanti pacchetti vengono persi in quella durata). I tassi di perdita di pacchetti nelle tabelle che seguiranno sono obiettivi atti ad assicurare una qualit soddisfacente per il livello di servizio dellutente finale, ipotizzando assente, o comunque minimo, loccultamento delle perdite. Se le prestazioni dellinfrastruttura di rete sono al di sotto dei livelli richiesti, si pu fare uso di tecniche a livello di rete (per esempio prioritizzazione del traffico, interleaving e Forward Error Correction dei dati) e di meccanismi a livello applicativo (per esempio FEC a livello applicativo o Automatic Repeat reQuest), come delineato nel documento [146] e di cui si fornir una descrizione nel 9.5 per raggiungere i livelli di prestazione richiesti. Inoltre lutilizzo di queste tecniche pu consentire di migliorare la qualit

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.332 livello fisico (Reed Solomon, interleaving) per contrastare i dellesperienza per rendere pi competitive le offerte dei disturbi sulle linee dutente, viene considerato un periodo di servizi. perdita maggiore di un singolo pacchetto. Infatti se si verifica Molto spesso i requisiti di qualit dellIPTV vengono espressi una perdita di tipo REIN (cfr. 9.1.1) il periodo di perdita come massimo un evento di errore su un certo intervallo di corrisponde a 8 o 16 ms. tempo, ad esempio il DVB fissa un requisito di al massimo Il periodo di perdita raccomandato viene usualmente un artefatto visibile ogni ora, [18]. specificato inferiore ai 16 ms. Ci costituisce un Questo concetto diverso da quello di tempo medio tra gli compromesso tra la capacit di protezione dagli errori indotti eventi usato da DSL Forum, [146] e fatto proprio da ITU-T, dal rumore impulsivo nei sistemi xDSL assicurata da [100], e ATIS, [164], come parametro per ricavare le tabelle profondi interleaver a livello fisico, il ritardo aggiuntivo e i grafici illustrati nel presente paragrafo. introdotto da tale tecnica per le altre applicazioni ed i Infatti, se le perdite sono indipendenti e casuali, allora un requisiti di QoE per il servizio video che hanno lobiettivo di tempo medio tra gli eventi di quattro ore implica che ridurre il numero di deterioramenti visibili ad un massimo di lobiettivo di massimo una perdita in unora non sar uno ogni ora. Il periodo di perdita condurr alla perdita di un soddisfatto all'incirca una volta al giorno (cio vengono visti numero diverso di pacchetti, a seconda del bitrate dello due errori allinterno della stessa ora circa una volta al stream video, come illustrato nelle tabelle seguenti. giorno). Allo stesso modo, un tempo medio tra le perdite di Si tenga conto del fatto che le tecniche di recupero delle mezzora significa che molto spesso si verificher pi di una perdite (es: AL-FEC), di cui si far unampia trattazione nel perdita in un periodo qualsiasi di mezzora. seguito, tentano anche di superare il limite dei 16 ms, recuperando i pacchetti persi a causa del REIN. Idealmente il periodo di perdita massimo dovrebbe corrispondere ad un pacchetto IP, dato che anche un Differente il caso degli eventi di risincronizzazione del singolo pacchetto perso pu condurre a un deterioramento modem DSL che implicano una durata del periodo di perdita molto vistoso del servizio, come mostrato nella Figura 9-3 di pacchetti dellordine di 10-20 secondi. Non richiesto che nel caso del video. Tuttavia, per tener conto di un possibile un sistema IPTV mantenga un servizio normale con un ambiente xDSL e delle relative tecniche FEC utilizzate a

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.333 (per esempio, FEC e interleaver) e meccanismi di evento del genere. Tali eventi potrebbero essere considerati attenuazione delle perdite. dei fuori servizio piuttosto che un difetto di qualit. Lapplicazione video dovrebbe essere in grado di funzionare I requisiti riportati nelle tabelle e nei grafici illustrati nel normalmente in presenza di difetti operativi normali. Nella seguito (tratte dal documento del DSL Forum [146] e riprese considerazione di operativit di tipo normale rientrano le da [100]) sono state ricavate a partire da dati misurati su operazioni di automatic protection switching (APS) causate implementazioni di servizi esistenti, studi su criteri oggettivi e da eventi di guasto di link rete (cfr. 9.1.1). Viene su criteri soggettivi di misurazione della qualit percepita e raccomandata laggiunta di meccanismi per minimizzare o sulla base di standard esistenti (ATIS, DVB, ITU-T [216] e eliminare leffetto visibile delle microinterruzioni da APS dato [143]). Si assume quindi che: che questi eventi interessano usualmente un numero elevato di utenti. tutti i possibili deterioramenti che possono essere Considerando altri meccanismi di protezione, la durata sopportati nella diffusione di un servizio, senza compromettere significativamente la qualit percepita, potenziale della perdita dei pacchetti pu essere pi lunga. sono riassunti globalmente attraverso valori di soglia Per esempio, una riconvergenza completa della tabella di di grandezze significative (latenza, jitter, PLR, routing IP (IGP) implicherebbe burst potenziali di perdite dei distanza di perdita, periodo di perdita), valutate endpacchetti dellordine di 30 secondi (cfr. 9.1.1). Anche tali to-end (cio dalla sorgente del servizio alluscita del eventi sono generalmente considerati dei fuori servizio STB verso il televisore inclusi i meccanismi di correzione delle perdite che possono essere applicati piuttosto che un difetto di qualit Non richiesto quindi che a livello di rete o a livello applicativo). Tali valori quindi un sistema IPTV mantenga un servizio normale in presenza si configurano come obiettivi (minimi) per garantire un di eventi del genere. livello di qualit sufficiente; Lobiettivo generale della progettazione di un sistema di la distanza di perdita degli eventi derrore dovrebbe diffusione televisiva su IP quello di minimizzare gli effetti essere limitata al massimo ad un evento ogni 60 percepiti delle perdite usando una opportuna combinazione minuti per lSDTV e ad uno ogni 4 ore per lHD. Un di meccanismi di rete, meccanismi di recupero delle perdite evento derrore definito come una perdita o una corruzione di un piccolo gruppo di pacchetti IP

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.334 contenenti ognuno fino a 7 pacchetti MPEG di il codec di tipo MPEG-2; lunghezza 188 byte; il multiplex di trasporto il Transport Stream MPEG-2; dovrebbe essere garantito un margine di rumore si hanno 7 pacchetti di 188 byte per ogni pacchetto IP; sufficiente nel link xDSL per contrastare il rumore di linea e una profondit dellinterleaver FEC adeguata loccultamento delle perdite assente o minimo (tassi di perdita tollerabili possono essere pi grandi a per contrastare il rumore impulsivo, in modo da ottenere il Bit Error Rate (BER) richiesto per seconda del grado e della qualit delloccultamento raggiungere gli obiettivi di perdita dei pacchetti, senza delle perdite operato dal STB); eccessiva degradazione per gli altri servizi; loutput dellencoder avviene dopo lapplicazione di

i decodificatori STB dovrebbero adottare tecniche di occultamento derrore per minimizzare limpatto provocato da pacchetti video persi o corrotti.

ogni meccanismo di protezione a livello applicativo dal lato utente;

9.3.1 SDTV: obiettivi delle prestazioni del Broadcast a livello di trasporto La Tabella 9-6 mostra i parametri minimi per una soddisfacente qualit dellesperienza per servizi SDTV ed stata elaborata facendo le seguenti assunzioni:

le metriche riguardano i flussi IP contenenti solamente stream video, mentre gli stream IP per altri componenti di servizio possono avere requisiti di prestazione diversi.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.335 Bitrate del TS (Mbit/s) 3,0 3,75 5,0 Latenza Jitter Durata massima di un singolo errore 16 ms 16 ms 16 ms Periodo di perdita corrispondente (in pacchetti IP) 6 pacchetti IP 7 pacchetti IP 9 pacchetti IP Distanza di perdita un evento di errore ogni ora un evento di errore ogni ora un evento di errore ogni ora Corrispondente tasso medio di perdita dei pacchetti dello stream video IP 5,85e-6 5,46e-6 5,26e-6

< 200 ms < 200 ms < 200 ms

< 50 ms < 50 ms < 50 ms

Tabella 9-6: Parametri minimi raccomandati da ITU-T a livello di trasporto per una QoE soddisfacente per servizi SDTV codificati MPEG-2 La Tabella 9-7 mostra gli obiettivi di prestazione per la qualit dellesperienza per contenuti video in definizione standard codificati MPEG-4 AVC o VC-1 ed basata sulle seguenti assunzioni: seconda del grado e della qualit delloccultamento delle perdite operato dal STB);

il codec di tipo MPEG-4 AVC o VC-1; il multiplex di trasporto il Transport Stream MPEG-2; si hanno 7 pacchetti di 188 byte per ogni pacchetto IP; loccultamento delle perdite assente o minimo (tassi di perdita tollerabili possono essere pi elevati a

le metriche sono end-to-end dalluscita del codificatore della sorgente, alluscita dellalgoritmo di protezione a livello applicativo dal lato utente; le metriche riguardano flussi IP contenenti solamente gli stream video, mentre gli stream IP per altre componenti di servizio possono avere requisiti di prestazione diversi.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.336 Bitrate del TS (Mbit/s) 1,75 2,0 2,5 3,0 Latenza Jitter Durata massima di un singolo errore 16 ms 16 ms 16 ms 16 ms Periodo di perdita corrispondente (in pacchetti IP) 4 pacchetti IP 5 pacchetti IP 5 pacchetti IP 6 pacchetti IP Distanza di perdita un evento di errore ogni ora un evento di errore ogni ora un evento di errore ogni ora un evento di errore ogni ora Corrispondente tasso medio di perdita dei pacchetti dello stream video IP 6,68e-6 7,31e-6 5,85e-6 5,85e-6

< 200 ms < 200 ms < 200 ms < 200 ms

< 50 ms < 50 ms < 50 ms < 50 ms

Tabella 9-7: Parametri minimi raccomandati da ITU-T a livello di trasporto per una QoE soddisfacente per servizi SDTV codificati MPEG-4 AVC, VC-1 o AVS 9.3.2 SDTV: obiettivi delle prestazioni del VoD e dei contenuti premium a livello di trasporto opinione condivisa che i requisiti per le prestazioni di rete delle applicazioni broadcast SDTV precedentemente elencati dovrebbero essere seguiti anche per i servizi VoD e contenuti premium. 9.3.3 HDTV: obiettivi delle prestazioni a livello di trasporto comunemente concordato che, idealmente, i servizi HDTV soddisfino il criterio di un evento di deterioramento visibile ogni 12 ore o meglio. Nel seguito viene proposto un valore di quattro ore come distanza di perdita minima per i servizi HDTV, ipotizzando che non tutti gli errori conducano a un deterioramento visibile, poich:

la perdita dellinformazione della trama B a volte sotto la soglia di visibilit;


verr usato loccultamento degli errori nei decodificatori HDTV. La Tabella 9-8 mostra il periodo di perdita e la distanza di perdita per lHDTV MPEG-2 sotto le seguenti ipotesi: il codec di tipo MPEG-2; il multiplex di trasporto il Transport Stream MPEG-2; si hanno 7 pacchetti di 188 byte per ogni pacchetto IP; il STB ha un certo livello di occultamento derrore;Bitrate del TS (Mbit/s) 15 Latenza Jitter

loutput dellencoder avviene dopo lapplicazione di ogni meccanismo di protezione a livello applicativo dal lato utente; le metriche riguardano flussi IP contenenti solamente stream video, mentre gli stream IP per altre applicazioni possono avere requisiti di prestazione diversi.

Durata massima Periodo di perdita di un singolo corrispondente (in errore pacchetti IP) 16 ms 24 pacchetti IP

Distanza di perdita un evento di errore ogni 4 ore un evento di errore ogni 4 ore un evento di errore ogni 4 ore

Corrispondente tasso medio di perdita dei pacchetti dello stream video IP 1,169e-6

< 200 ms

< 50 ms

17

< 200 ms

< 50 ms

16 ms

27 pacchetti IP

1,16e-6

18,1

< 200 ms

< 50 ms

16 ms

29 pacchetti IP

1,171e-6

Tabella 9-8: Parametri minimi raccomandati da ITU-T a livello di trasporto per una QoE soddisfacente per servizi HDTV codificati MPEG-2 a Tabella 9-9 elenca i requisiti di prestazione per la qualit dellesperienza per materiali video in alta definizione decodificati MPEG-4 AVC o VC-1, considerando le seguenti ipotesi:

il codec di tipo MPEG-4 AVC, VC-1, o codec AVS;


il multiplex di trasporto il Transport Stream MPEG-2; si hanno 7 pacchetti di 188 byte per ogni pacchetto IP; il STB ha un certo livello di occultamento derrore; loutput dellencoder avviene dopo lapplicazione di ogni meccanismo di protezione a livello applicativo dal lato utente;Bitrate del TS (Mbit/s) 8 10 12 Latenza Jitter

le metriche riguardano flussi IP contenenti solamente stream video, mentre gli stream IP per altre applicazioni possono avere requisiti di prestazione diversi.

< 200 ms < 200 ms < 200 ms

< 50 ms < 50 ms < 50 ms

Durata massima Periodo di perdita Tasso medio corrispondente di di un singolo corrispondente (in Distanza di perdita perdita dei pacchetti dello errore pacchetti IP) stream video IP un evento di 16 ms 14 pacchetti IP 1,28e-6 errore ogni 4 ore un evento di 16 ms 17 pacchetti IP 1,24e-6 errore ogni 4 ore un evento di 16 ms 20 pacchetti IP 1,22e-6 errore ogni 4 ore

Tabella 9-9: Parametri minimi raccomandati da ITU-T a livello di trasporto per una QoE soddisfacente per i servizi HDTV codificati MPEG-4 AVC, VC-1 o AVS Il PLR nel range di 10-6 raccomandato per i servizi video pu richiedere tecniche speciali di controllo derrore per raggiungere lobiettivo. Il documento [146] fornisce maggiori dettagli sul BER della rete, sulle prestazioni del FEC e sulle opzioni di mitigazione.

9.3.4 Grafici della PLR obiettivo La Figura 9-6, tratta dal documento del DSL Forum [146] e ripresa da [100], riporta graficamente i dati di Tabella 9-6 e Tabella 9-8 mostrando i tassi di perdita dei pacchetti richiesti come una funzione del bitrate e del tempo tra gli eventi di

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.339 perdita non corretti, nel caso di eventi di perdite a burst tipici del DSL, di durata pari a 16 ms.

Figura 9-6: PLR richiesto per soddisfare un tempo medio tra gli eventi di perdita di 1, 2 e 4 ore ipotizzando che ogni evento sia un errore DSL incorreggibile che perde 16 millisecondi di dati contigui La Figura 9-7, tratta dal documento del DSL Forum [146] e ripresa da [100], riporta, sempre per codifica video MPEG-2, landamento del PLR in funzione del bitrate nel caso di eventi di perdite a burst di durata di 8 ms.

Figura 9-7: PLR richiesto per soddisfare un tempo medio tra gli eventi di perdita di 1, 2 e 4 ore ipotizzando che ogni evento sia un errore DSL incorreggibile che perde 8 millisecondi di dati contigui Nelle figure di questo paragrafo si assume sempre che ogni pacchetto IP trasporti 7 pacchetti MPEG, ognuno lungo 188 byte, e che le statistiche dellerrore siano stazionarie e tempo invarianti. Leffetto ripple il risultato dellapprossimazione a un numero intero del numero di pacchetti IP persi o corrotti; quindi per 8 ms di dati video persi in un TS MPEG-2 ad un bitrate di 3 Mbit/s, si hanno:


pacchetti MPEG totali per secondo = (3 Mbit/s)/(8 bit per byte)/(188 byte per pacchetto MPEG) = 1994,7 pacchetti MPEG per secondo; pacchetti IP totali per secondo = 1994,7/(7 pacchetti MPEG per secondo) = 285 pacchetti IP per secondo;

una perdita di 8 ms corrispondente a (285 pacchetti IP per secondo)*0,008 secondi = 2,28 pacchetti IP persi. Dato che viene perso un intero pacchetto IP se viene persa una parte di esso, si arrotonda al seguente numero intero, ovvero tre pacchetti IP, e dato che i byte persi non sono necessariamente allineati ai limiti del pacchetto IP, questo numero potrebbe essere ulteriormente arrotondato a quattro pacchetti. A differenza delle precedenti figure relative a perdite di pacchetti a burst la Figura 9-8 si riferisce al caso di perdite di pacchetti isolate riportando i tassi di perdita dei pacchetti (PLR) come una funzione del bitrate e del tempo medio tra eventi di perdita non corretti.

Figura 9-8: PLR richiesto per soddisfare un tempo medio tra gli eventi di perdita di 1, 2 e 4 ore ipotizzando pacchetti persi isolati Nella Figura 9-8, tratta dal documento del DSL Forum [146] e ripresa da [100], sono evidenziati i punti corrispondenti a codifica video/bitrate/tempo medio tra eventi di perdita non corretti, gi considerati nelle tabelle precedenti per il caso di perdite di pacchetti a burst. In particolare sono cerchiati:

in arancione i punti rappresentativi del video SDTV con una distanza di perdita di unora tra gli eventi di perdita dei pacchetti; in rosso i punti rappresentativi del video HDTV con una distanza di perdita di quattro ore tra gli eventi di perdita dei pacchetti.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.341 LATIS, nel documento [164] riporta, per il PLR, andamenti 9.4 QoS tramite architetture di sistema e analoghi a quelli di Figura 9-8 e Figura 9-7 valutati per tempi meccanismi di rete medi tra eventi di perdita di 0,5, 1,5 e 4 ore. Nella diffusione di servizi televisivi su IP i requisiti di QoS possono essere soddisfatti in maniera pi agevole in In aggiunta ai tassi medi di perdita dei pacchetti, che infrastrutture IP di tipo managed, ovvero in reti IP incidono sulla qualit delle immagini e dellaudio, e alle proprietarie. In tali reti, infatti, risulta possibile introdurre metriche disponibili (cfr. 9.2), pu essere vantaggioso opportuni meccanismi di controllo e gestione del traffico, che definire un secondo insieme di limiti sui forti deterioramenti. consentono di ottimizzare il trasporto in rete delle Questi limiti si applicherebbero ai deterioramenti della informazioni associate a ciascun servizio. Tali meccanismi qualit che cadono tra i degradamenti generati dai limiti sulla forniscono un supporto significativo al raggiungimento degli perdita dei pacchetti specificati precedentemente e le obiettivi di qualit prefissati. Ci non toglie che in tali reti sia metriche di fuori servizio totale (ovvero schermo nero) possibile comunque prevedere, in ausilio di strategie pi specificate dallaffidabilit delle metriche. Questi legate alla rete, luso di tecniche di recupero delle perdite deterioramenti grossolani potrebbero includere perdite di (tramite FEC o ritrasmissione) che operano end-to-end. interi quadri video, ripetizioni di quadri (freeze), o una perdita In ambienti managed luso combinato delle tecniche di breve durata di audio o video o controllo intelligibile (per suddette consente spesso di raggiungere requisiti di qualit esempio, a causa del protection switching). Le metriche di servizio molto stringenti (come quelli riportati in 9.3), al devono ancora essere definite, basate su input industriali e fine di ottenere per i servizi televisivi su IP una QoE simile a potrebbero essere specificate dalla frequenza dellevento di quella tipica delle altre piattaforme di diffusione televisiva errore per unit di tempo, per esempio, un massimo di un (satellite, terrestre). errore grave al giorno e la durata del deterioramento. Luso di tecniche di recupero delle perdite assume ancora pi importanza in ambienti unmanaged, quali Open Internet, in cui non pensabile, invece, lintroduzione di meccanismi di gestione del traffico.

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.342 A livello rete, al fine di garantire la QoS su una rete IP vi IntServ sono fondamentalmente due possibili modalit: Pi nel dettaglio lIntServ (Integrated Services) un modello che prevede che, prima dell'inoltro del traffico di un servizio fornire risorse tali da soddisfare la domanda di picco in rete, venga effettuata, tramite opportuno protocollo di attesa, con un sostanziale margine di sicurezza. Questo metodo viene chiamato overprovisioning ed segnalazione, una richiesta a livello di rete, con la quale molto semplice, ma anche troppo costoso in termini venga prenotato un certo quantitativo di risorse specifiche di banda e quindi poco utilizzato. Inoltre questa per il tipo di traffico associato al servizio. Tale richiesta si soluzione fallirebbe qualora la domanda di picco manifesta in una segnalazione che contiene, per esempio, crescesse pi velocemente delle previsioni, in quanto richieste di larghezza di banda minima e di massimo ritardo disporre di ulteriori risorse richiede tempo; accettabile. Si tratta di una procedura con conferma, ovvero amministrare la banda disponibile, facendo s che i la rete (intendendo questa come l'insieme di tutti i dispositivi pacchetti a cui deve essere garantita una determinata QoS ottengano un trattamento privilegiato rispetto agli atti alla gestione dell'Integrated Service) deve fornire una altri pacchetti, questo metodo viene chiamato risposta alle specifiche richieste, garantendo (o meno) la prioritizzazione. Per dare quindi una certa priorit fornitura di quanto richiesto per il particolare flusso di ad un terminato traffico, bisogna poter identificare i traffico. pacchetti a cui assegnare un determinato trattamento L'inizio dell'inoltro dei pacchetti in rete avviene solo quando privilegiato. I metodi principali per differenziare il traffico sono: la rete ha risposto positivamente alle necessit richieste dal integrated services (IntServ), [211], metodo che si trasmittente. Durante la trasmissione la rete, che rispetta le basa sulla prenotazione delle risorse che specifiche richieste, mantiene uno stato determinato per garantiscano al servizio le prestazioni necessarie; ogni flusso di traffico. differentiated services (DiffServ), [44],metodo nel Il protocollo usato nel modello IntServ per la gestione della quale gli utenti della rete definiscono a priori la segnalazione il protocollo RSVP (Resource Reservation quantit massima di traffico "privilegiato" che possono generare. Protocol), definito in [211]. LRSVP si occupa di riservare DiffServ su MPLS una determinata larghezza di banda su ciascun nodo, che

La diffusione televisiva su Internet: architetture e tecnologie Sezione IX: Qualit del Serviziodi Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.343 allIntServ, il DiffServ non prevede l'allocazione di risorse e deve supportare le funzionalit RSVP, per un determinato quindi la rete non mantiene uno specifico stato per ogni flusso, lungo un percorso di dati specificato. flusso di traffico. LRSVP un protocollo di prenotazione di risorse di rete (le Lidea invece di questo meccanismo quella di fornire risorse vengono allocate prima dell'inizio della trasmissione), differenti servizi, creando delle classi di servizio con diver

Sez_IX

Documents

Transcript of Sez_IX