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 Servizio
di 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
di 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
di 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:
di 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.
di 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.
di 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:
di 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
di 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
di 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-
di 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
di 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,
di 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
di 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).
di 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.
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
di 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.
di 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
di 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
di 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.
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
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
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
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
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
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.
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)
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
di 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
trasporto
Le 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
di 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
di 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
di 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.
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.
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
di 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.
di 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.
di 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
di 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 diversi in reti non orientate alla connessione e pu essere utilizzato livelli di priorit; a tal fine viene utilizzato il campo DSCP con il traffico multicast e unicast, supportando esso i flussi (DiffServ Code Point), ottenuto dal campo type-of-service multicast con la stessa efficacia di quella offerta ai flussi (TOS) del pacchetto IPv4, [45], o dal campo traffic class di unicast. IPv6. Ogni valore del campo DSCP corrisponde ad una Tale protocollo fa uso di un approccio orientato ai classe di servizio e tutti i pacchetti aventi lo stesso campo destinatari; piuttosto che lasciare il compito al mittente di DSCP (pochi flussi aggregati) riceveranno lo stesso tenere traccia di un numero di destinatari potenzialmente trattamento allinterno della rete. elevato, pi sensato che siano i destinatari a gestire le La marcatura del campo DSCP dei pacchetti IP viene proprie necessit. effettuata dai router ai bordi della rete o addirittura dagli Si noti infine che lRSVP non un protocollo di routing, ma stessi terminali dutente che li generano in base ai requisisti utilizza i protocolli di routing, in quanto consulta le tabelle del prestazionali richiesti. router locale per le route. A ciascuna classe, che definita tramite un insieme di parametri caratteristici (larghezza di banda, probabilit di DiffServ perdita di pacchetti, jitter, ritardo, ecc), assegnata una Il DiffServ un meccanismo di trattamento differenziato in certa priorit di trattamento in rete. Ad ogni classe quindi rete del traffico associato a servizi distinti con il quale si associata una diversa strategia di instradamento che riescono a soddisfare diversi requisiti di QoS. determina la strategia con cui i pacchetti vengono gestiti La tecnologia DiffServ si fonda sul meccanismo di all'interno della rete (Per-Hop Behaviour, PHB). Non allocazione preferenziale delle risorse, vengono cio previsto nessun protocollo di segnalazione e nessuna introdotti dei livelli di priorit e in base ad essi il traffico viene informazione sullo stato dei router. Ogni router infatti deve opportunamente trattato nella rete. Contrariamente
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.344 inoltre DiffServ non specifica servizi, il servizio percepito mantenere esclusivamente le informazioni per il dallutente semplicemente il risultato dei vari PHB. management dei diversi PHB, che sono in numero finito e Come per la tecnologia IntServ, il trattamento differenziato indipendenti dal numero di microflussi aggregati; il numero di dei servizi prevede la definizione di opportuni SLA (Service informazioni da mantenere sono in definitiva proporzionali al Level Agreement) tra Service Provider e Network Provider. numero di classi di servizio e non al numero di flussi d'applicazione. L'architettura di DiffServ si propone quindi di incrementare le Uso congiunto di IntServ e DiffServ Anche se queste tecnologie sono state definite prestazioni del protocollo IP, introducendo diversi livelli di separatamente, non detto che debbano essere utilizzate in servizio con una scalabilit ottimale, senza operare al livello modo esclusivo. IntServ efficiente nelle piccole reti, come del singolo flusso o richiedere segnalazioni ad ogni hop. ad esempio le LAN, dove i flussi da gestire sono pochi e non Larchitettura DiffServ viene specificata da IETF in [44] e a si hanno problemi di scalabilit; DiffServ al contrario tale metodo fa riferimento il DVB. consente la gestione della QoS per grossi aggregati di LIETF definisce differenti tipi di PHB: traffico e pu quindi essere implementato su reti trasporto Default Forwarding (DF), corrispondente al servizio metropolitane o backbone. Best Effort,
Expedited Forwarding (EF), [227], lAssured Forwarding (AF), [228], Class Select (CS), [45]. DiffServ su MPLS La metodologia DiffServ non offre garanzie quantitative endto-end (lallocazione garantita di una certa misura di risorse trasmissive in tutto il percorso) che sono spesso previste nei requisiti di QoS di un servizio. LMPLS (Multiprotocol Label Switching), definito in [212] e [213], colma la carenza suddetta, fornendo supporto ad un ambiente connection oriented, nel quale possibile riservare risorse ed utilizzare in modo efficiente la rete mediante applicazioni di traffic
Si osservi inoltre che il DiffServ specifica solo il campo DSCP, e dunque le classi di servizio, e i PHBs dei routers, mentre spetta alloperatore di rete decidere quali particolari prestazioni far corrispondere alla singola coppia DSCP-PHB;
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.345 engineering, per una completa gestione end-to-end della 9.4.2 DSCP packet marking QoS. Letichettatura secondo il modello DiffServ utilizza il campo MPLS una tecnologia per reti IP che permette di instradare di 8 bit Type of Service (ToS) dellIP header e viene descritta flussi di traffico tra origine (Ingress Node) e destinazione nella specifica RFC 2474 [45]. Le reti compatibili con questa (Egress Node), tramite lutilizzo di identificativi (label) tra ultima specifica utilizzano 6 bit del campo ToS per contenere coppie di router adiacenti ed operazioni semplici sulle il codice dei servizi differenziati (un valore numerico usato etichette stesse. Inoltre lMPLS dausilio allinstradamento nella rete per gestire le politiche di gestione della coda dei IP che, invece di richiedere a ciascun nodo di controllare la router). Invece le reti che non seguono la specifica RFC propria tabella di routing per stabilire linterfaccia duscita del 2474 [45] utilizzano 3 bit del campo ToS per determinare la traffico, permette di stabilire, controllando la label dingresso, precedenza. Nelle reti IP progettate per trasportare i servizi quali siano le label e l'interfaccia duscita per il traffico. DVB, deve essere usata letichettatura riportata nella Tabella 9.4.1 Il punto di vista DVB: Qualit del servizio tramite DiffServ Affinch la rete fornisca allutente la Qualit del Servizio (QoS) richiesta, il DVB fa riferimento al metodo di classificazione del traffico secondo il modello DiffServ descritto nella specifica RFC 2475, [44], cfr. 9.4. Si prevede lidentificazione del tipo di dati contenuti in ogni datagramma ed un meccanismo per dare priorit al traffico basato su questa classificazione. I pacchetti IP, che transitano sullinterfaccia IPI-1, devono essere opportunamente etichettati dalla sorgente (cfr. 3.1.3). 9-10. Si consiglia di usare il valore DSCP completo.
Tipo di traffico Voice Bearer (nota 1) Real-time Video Bearer (alta priorit) (nota 2) Real-time Video Bearer (minore priorit) (nota 3) Segnalazione voce e video Dati best effort Valore IP DSCP 0b110000 0b100010 0b100100 0b011010 0b000000 Precedenza IP corrispondente 0b110 0b100 0b100 0b011 0b000
NOTA 1: Il voice bearer qui elencato per assicurarsi che non ci sia interferenza con i servizi DVB-IPTV. NOTA 2: Etichettatura normale per video real-time. NOTA 3: Luso di questa etichettatura dipende dallapplicazione. destinata a permettere a un CSP di indicare che alcuni pacchetti video sono meno importanti di altri.
Tabella 9-10: Etichettature DSCP corrispondenti codici di priorit IEEE 802.1p. I pacchetti devono essere etichettati usando le impostazioni Class of Service (CoS) di livello 2 nei bit di User Priority della porzione 802.1p dellheader 802.1Q [46]. Questi possono essere mappati nei bit di IP Precedence/DSCP nel byte ToS dellheader IPv4.
9.4.3 Priorit in Ethernet Le interfacce IPI-1, IPI-2 e IPI-3 (cfr. Figura 3-2) su un Home Network Segment (HNS) basato su MAC Ethernet devono supportare lo standard IEEE 802.1Q [46], con classi di priorit dutente definite. In una trama Ethernet compatibile con lo standard IEEE 802.1Q [46] deve essere supportato un campo che segue lo standard IEEE 802.1p [47]. Letichettatura deve essere basata sul metodo DiffServ CodePoint (DSCP). Per un HNS basato su MAC Ethernet, i valori DSCP indicati in Tabella 9-11 sono usati per mappare un tipo di traffico sui
Tipo di traffico Voice bearer (v. nota) Video bearer (alta priorit) Video bearer (minore priorit) Segnalazione video Valore IP DSCP 0b110000 0b100010 0b100100 0b011010 Valore IEEE802.1p di priorit dutente corrispondente 0b110 0b100 0b100 0b011
Dati best effort 0b000000 0b000 NOTA: Il voice bearer qui elencato per assicurarsi che non ci sia interferenza con i servizi DVB-IPTV.
Tabella 9-11: Valori DSCP e corrispondente etichettatura Ethernet IEEE 802.1p Lheader 802.1Q [46] aggiunge 4 byte di dati nellheader di una trama Ethernet. Il campo di priorit 802.1p uno dei campi nellheader 802.1Q [46], ed un campo di 3 bit. Ogni dispositivo di switching, che implementa la specifica IEEE 802.1Q [46], pu usare il campo di priorit di utente per determinare la classe di scheduling cui appartiene un pacchetto. Mappare il campo IP Precedence facile, dato che pu essere copiato direttamente nel campo di priorit di utente, poich i due campi sono entrambi lunghi 3 bit. Per mappare il campo DSCP nel campo di priorit di utente, il DSCP deve essere shiftato a destra di 3 bit, cio il campo di priorit di utente corrisponde ai primi 3 bit del campo DSCP. Per mappare il campo di priorit di utente nel campo DSCP, il campo di priorit di utente deve essere verificato per i valori che corrispondono al valore di priorit nella terza colonna. Se non corrisponde a nessuno di questi valori, il pacchetto deve essere tracciato con un valore DSCP che la priorit di utente shiftata a sinistra di 3 bit.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.348 ricostruire linformazione (pacchetto) mancante. Il FEC pu essere utilizzato sia con la modalit di consegna unicast, 9.5 Tecniche per ridurre leffetto delle che con la modalit di consegna multicast. perdite In questo paragrafo sono descritti i meccanismi per il recupero degli errori basati sulla ritrasmissione dei pacchetti persi, quelli basati sulluso di opportuni FEC, e le combinazioni di queste due tecniche. Lapproccio che si basa sulla ritrasmissione recupera le perdite di pacchetto richiedendo la ritrasmissione da parte del mittente o da parte di server di ritrasmissione intermedi. necessario quindi lutilizzo di messaggi di feedback dal ricevitore verso il mittente o verso uno o pi server di ritrasmissione. Se viene individuata una perdita di pacchetto, ad esempio rilevando una discontinuit nella sequenza di numerazione dei pacchetti, il ricevitore richiede al mittente o ai server intermedi adibiti a tale funzione di ritrasmettere i pacchetti persi. La ritrasmissione pu essere effettuata con modalit unicast o multicast a seconda della distribuzione dei client che richiedono la ritrasmissione. Lapproccio che si basa sul FEC opera aggiungendo informazioni ridondanti ai dati trasmessi. Tali informazioni sono sfruttate dal decodificatore in caso di perdita per Si tenga presente che il ricevitore pu in maniera autonoma operare tecniche di mascheramento degli errori che permettono di minimizzare gli artefatti visibili, (cfr. [146]), sostituendo le informazioni perse con una loro predizione ottenuta sulla base delle informazioni ricevute correttamente. Lo svantaggio delluso della tecnica di occultamento degli errori sta nellincremento della complessit delle funzioni nel ricevitore. Quando viene selezionato uno schema per attenuare i fenomeni di perdita dei pacchetti e il relativo protocollo, dovrebbero essere presi in considerazione almeno i seguenti aspetti, che dovrebbero guidare la scelta delle tecniche pi idonee:
la componente di servizio di diffusione televisiva su IP oggetto della protezione, ad esempio uno stream video real time, o un EPG, o unapplicazione dati; il tipo di meccanismo di trasmissione dei dati relativi alla componente elementare da proteggere, ad esempio multicast, unicast, o P2P;
il protocollo o lelaborazione delloverhead a lato mittente e ricevente; gli aspetti generali sulla larghezza di banda della rete; la locazione (distribuzione geografica) degli eventi di perdita dei pacchetti nel percorso tra la sorgente del servizio e il terminale dutente; i punti della rete in cui il contenuto pu essere modificato (ad esempio per linserimento della pubblicit) e quindi soggetto a degradazione di qualit; la possibilit che molti utenti siano interessati dallo stesso evento di perdita dei pacchetti, come pu tipicamente verificarsi nei servizi Broadcast Lineari con trasmissione di tipo multicast; le diverse possibilit di controllo e i diversi interessi delle entit che gestiscono i domini Service Provider, Network Provider e Consumer possono portare a preferire meccanismi differenti. Per esempio, il Service Provider pu essere pi interessato a meccanismi di attenuazione degli errori a livello applicativo, mentre il Network Provider pu essere pi interessato a meccanismi di protezione a livello di collegamento; ciascun meccanismo di attenuazione della perdita dei pacchetti possiede un range atteso di prestazioni, che generalmente dipende dellapplicazione specifica.
alcuni meccanismi possono essere combinati meglio con altre funzioni;
il traffico di servizio di diffusione televisiva su IP dovr condividere la capacit del link con altri tipi di traffico che possono avere tolleranze diverse, come ad esempio lInternet best effort. Una variet di tecnologie di link (per esempio xDSL e tecnologie wireless) hanno una serie di meccanismi regolabili per il controllo derrore specifici per i link. Questi meccanismi specifici per i link devono essere adattati per supportare economicamente i requisiti di controllo derrore sul traffico aggregato e non possono essere assunti adattati ai limiti specifici del servizio in questione. Di seguito verr fornita una panoramica sui meccanismi di controllo degli errori per servizi di diffusione televisiva su IP e sui relativi standard. 9.5.1 Ritrasmissione dei pacchetti persi
Un approccio possibile per ridurre limpatto della perdita dei pacchetti quello di utilizzare protocolli di ritrasmissione (Acknowledgment ReQuest - ARQ). Possono essere applicate numerose tecniche, per reagire alla perdita dei pacchetti, basate su una qualche forma di feedback dal ricevitore (o dai ricevitori) al mittente. In genere, il nodo target invia al nodo sorgente dei messaggi che riferiscono lo
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.350 rate di trasmissione in caso di perdita di pacchetti), questo stato dei pacchetti e che spesso sono messaggi di approccio opera efficacemente soprattutto per la consegna acknowledgement. Esistono molte varianti degli approcci di di piccole quantit di dati sotto vincoli di ritardo laschi. ritrasmissione, ma il fondamento comune di tutte le tecniche opinione consolidata che questo meccanismo non sia basate su feedback lo sfruttamento del fatto che una rete appropriato per la distribuzione su IP di video broadcast a IP interattiva, piuttosto che broadcast (ad una sola via). bitrate elevato e relativamente costante, per il quale 9.5.1.1 Ritrasmissione TCP e controllo della importante assicurare una riproduzione video continua congestione (senza interruzioni) ad alta qualit per lintera durata. Il TCP definisce anche unopzione per gli acknowledgement La tecnica di ritrasmissione pi comune nel caso di selettivi (Selective Acknowledgement - SACK). Tale tecnica trasmissioni unicast basata sul Transmission Control emula il controllo del rate, vantaggioso per i media stream, e Protocol (TCP), il quale prevede che il nodo target client riduce il traffico dei messaggi di acknowledgement; il invii un messaggio di acknowledgement per ogni pacchetto supporto per questa opzione non per pervasivo. I TCP ricevuto. La ritrasmissione di un pacchetto interviene meccanismi di ritrasmissione TCP e quelli di controllo della nel caso di non ricezione da parte del mittente del relativo congestione sono descritti in molti documenti, tra cui il [165], acknowledgement ed in tal modo la perdita del pacchetto che descrive un meccanismo di SACK, il [149] che propone recuperata. Il meccanismo adattativo relativamente al rate un meccanismo per recuperare i segmenti persi in caso di di trasmissione dei pacchetti in quanto questo viene ridotto finestra di congestione piccola o in caso di perdita di pi finch gli acknowledgement non confermino lassenza di segmenti in una singola finestra di trasmissione, e l[175], perdita dei pacchetti. Lassunzione alla base di questo che espone un particolare algoritmo per lopzione SACK. approccio che la perdita dei pacchetti viene causata dalla Unaltra tecnica di ritrasmissione applicabile alle trasmissioni congestione, che pu essere diminuita riducendo il rate di multicast stata analizzata, in IETF, nel contesto del trasmissione. Dal momento che il meccanismo di recupero trasferimento affidabile, in multicast, di grandi quantit di dati dei pacchetti persi del TCP (ritrasmissione) accoppiato con (cio il trasferimento di file), RMT (Reliable Multicast un meccanismo di controllo della congestione (riduzione del Transport). I riferimenti sono le RFC [168], [169], [170],
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.351 ogni singolo pacchetto RTP, ma riporta delle statistiche sulla [171], [172]. Questi documenti descrivono una tecnica, nota perdita dei pacchetti (e sul jitter), che il nodo sorgente pu come NACK-Oriented Reliable Multicast Protocol (NORM), valutare per determinare se ladattamento sia adeguato o per la consegna affidabile di file in multicast, basata su meno. Unestensione dellRTCP per lAudio-Visual Profile acknowledgement negativi. A differenza degli approcci ARQ (AVP) consente ai ricevitori di fornire feedback pi immediati di tipo unicast come il TCP, il protocollo NORM meno ai mittenti, consentendo cos di realizzare meccanismi di ridondante in quanto non richiede linvio di messaggi di recupero efficienti basati su feedback (come ad esempio la acknowledgement per ogni pacchetto. Sebbene lo scenario ritrasmissione). Pi precisamente, la ritrasmissione RTP che ha motivato il lavoro dellIETF RMT stato quello del specificata dallIETF utilizza un sistema semplice in cui i trasporto di file, anche il trasporto di stream multicast pu ricevitori richiedono la ritrasmissione di specifici pacchetti trarre benefici dalle tecniche con acknowledgement negativi. persi tramite l'invio di pacchetti di acknowledgement 9.5.1.2 Ritrasmissione RTP negativo (RTCP NACK) che costituiscono un flusso RTCP associato alla sessione RTP. Un ricevitore pu usare un La ritrasmissione RTP (Real Time Protocol) unaltra singolo pacchetto NACK per richiedere la ritrasmissione di tecnica di recupero delle perdite dei pacchetti per uno o pi pacchetti persi. Il server che riceve gli applicazioni real-time. I pacchetti RTP ritrasmessi vengono acknowledgement negativi pu essere lo stesso oppure pu inviati in uno stream separato dallo stream RTP originario. In essere diverso dalla sorgente dello stream RTP multicast modo analogo alle ritrasmissioni TCP, si assume che sia originario. Il documento [182] specifica la modalit con cui i disponibile un feedback dai ricevitori ai mittenti, ma a pacchetti RTCP NACK sono correlati al mittente multicast differenza di TCP, RTP/UDP non impone che il controllo di per un particolare stream RTP. Le modalit con cui la congestione riduca il rate di trasmissione dei pacchetti, sorgente della ritrasmissione risponde con una rendendo questo meccanismo potenzialmente pi ritrasmissione dei pacchetti mancanti, in unicast o in appropriato per lo streaming video. multicast, vengono specificate nelle RFC [36], [173], [174], Il Real Time Control Protocol (RTCP) [36], protocollo [144] e nei documenti [183], [184]. compagno di RTP, non prevede un acknowledgement per
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.352 Tale tecnica prevista per esser utilizzata sia per servizi 9.5.1.3 Correlazione di eventi di perdita di unicast (CoD e Broadcast TV con Trick Mode), sia per pacchetti e ritrasmissione adattata servizi multicast (Live Media Broadcast). Il cammino del feedback, nel caso di feedback basato su Larchitettura di ritrasmissione pi semplice fa riferimento ai RMT o RTCP/RTP, pu suggerire la causa della perdita dei servizi CoD e Broadcast TV con trick mode ed costituita da pacchetti e imporre in questo modo la tattica pi efficace per due componenti principali: la ritrasmissione. Per eventi di perdita dei pacchetti correlati (ad esempio molti eventi di perdita vicini ad uno stesso punto di un albero multicast) ci saranno molte richieste di ritrasmissione, inviate da particolari gruppi di utenti verso il server. Sulla base di tale informazione possibile operare convenientemente la ritrasmissione dei pacchetti persi, in modalit multicast piuttosto che unicast, con effetti vantaggiosi sulla distribuzione (sia nello spazio che nel tempo) della ritrasmissione e sui relativi requisiti di scalabilit e di banda. 9.5.1.4 RET: lapproccio DVB alla ritrasmissione Nellannesso F del documento [18] del DVB, viene illustrata la tecnica di ritrasmissione identificata come RET (RETransmission). Questa tecnica, basata sulla ritrasmissione RTP (cfr. 9.5.1.2), definisce il meccanismo con cui fornire un FeedBack (FB) (NACK) immediato verso la rete utilizzando il protocollo RTCP e la modalit di ritrasmissione dei pacchetti persi da parte di un RET server.
un HNED con un client RTP per gli stream dei media e un client RTP per il recupero delle perdite;
un server CoD/MBwTM con un server RTP per gli stream dei media e funzionalit server RTP RET per la ritrasmissione. Queste ultime possono risiedere fisicamente su un server dedicato. Come illustrato in Figura 9-9 la procedura di recupero consiste di tre passi: lo stream CoD/MBwTM trasmesso in unicast su RTP (1, in figura) con una perdita di pacchetto RTP; rivelata la perdita da parte dellHNED, il client RET dellHNED invia un messaggio di feedback RTCP FB al server RET (2, in figura); il server risponde al messaggio RTCP FB ritrasmettendo il pacchetto richiesto (denominato pacchetto RET) al client RET (3, in figura).
Figura 9-9: Procedura RET per servizi unicast (CoD e Broadcast TV con trick mode) Pi complesso il caso dei servizi Live Media Broadcast (LMB), perch lo stream dei media in multicast, mentre lo stream di riparazione pu essere multicast o unicast. Nellarchitettura relativa possono essere presenti molteplici server RET ciascuno dei quali gestisce i messaggi RTCP (FB) provenienti da un particolare sottoinsieme di client RET di HNED. La modalit di recupero in unicast opera con modalit analoghe a quella per servizi CoD/MBwTM, in cui il server RET ritrasmette il pacchetto mancante al solo client che ha effettuato la richiesta. Luso del multicast nella ritrasmissione dei pacchetti persi risulta vantaggiosa nel caso in cui la perdita interessi pi HNED, come illustrato in Figura 9-10.
Figura 9-10: Procedura RET per servizi multicast (Live Media Broadcast) La perdita pu interessare anche il downstream dallHE al server LMB RET e in tal caso, anche se ci fuori dallambito di interesse del DVB in quanto non coinvolge linterfaccia IPI-1, la soluzione pu essere quella di instaurare tra le suddette entit una procedura RET unicast analoga a quella descritta in precedenza. In tali situazioni il server LMB RET in grado di rilevare, per proprio conto, la perdita e quindi inoltra in multicast un messaggio RTCP Feed Forward (FF) ai client coinvolti, prevenendo linvio dei messaggi RTCP FB. Una volta che ha disponibilit del pacchetto perso il server LMB RET lo invia in multicast ai client coinvolti nella perdita. Ovviamente ci
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.354 Al FEC di livello fisico viene usualmente affiancata in prevede che i client RET negli HNED attendano un certo trasmissione la tecnica dellinterleave che consente in tempo prima di inviare la richiesta di ritrasmissione. ricezione di ottenere (dopo loperazione di de-interleave) una Lannesso F della specifica [17], definisce tutti i dettagli delle distribuzione degli errori uniforme nellambito della sequenza procedure sullinterfaccia IPI-1 ed i formati dei pacchetti di dati su cui si operato. In tal modo si riconducono le RTCP previsti. perdite a burst, che avvengono nella trasmissione, in errori 9.5.2 Tecniche di Forward Error Correction e di sparsi distribuiti in maniera casuale. Ci consente a sua Interleave volta di massimizzare la capacit di correzione dei codici FEC di livello fisico che, si ricorda, operano al meglio proprio Le tecniche Forward Error Correction (FEC) possono essere su errori sparsi. Linterleaving consiste nellintercalare convenientemente applicati per la protezione di flussi in due blocchi di bit, costituenti una sequenza sufficientemente modalit: il FEC a livello fisico usato in genere per lunga di dati (cfr. [214]). Questa tecnica, a differenza delle correggere errori su bit o simboli individuali e il FEC a livello precedenti, non richiede un aumento della ridondanza, ma applicativo (AL-FEC) o di trasporto usato in genere per introduce un ritardo proporzionale alla lunghezza dei blocchi recuperare interi pacchetti persi. di bit oggetto dellinterleaving e del cosiddetto fattore di In queste tecniche, la quantit totale di dati che viene inviata interleaving cio il numero di blocchi su cui si opera; infatti superiore a quella che deve essere comunicata; per operare la decodifica (preceduta dal de-interleaving) linformazione aggiunta fa s che i dati da comunicare necessario attendere che tutti i blocchi a cui stata possono essere ricostruiti da qualsiasi sottoinsieme, purch applicata la stessa operazione di interleaving siano sufficientemente ampio, di dati trasmessi. I dati diventano interamente ricevuti. cos resistenti ad un determinata quantit di perdita (al Esistono due principali classi di interleaver: gli interleaver a massimo la differenza tra le dimensioni dei dati trasmessi e blocchi e gli interleaver convoluzionali. Questi ultimi gli originale). elaborano i dati in un flusso continuo, mentre gli interleaver a blocchi riordinano i simboli allinterno di un singolo blocco di dati.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.355 Gli schemi FEC/interleave possono correggere solo burst di 9.5.2.1 FEC a livello fisico errori di lunghezza inferiore alla profondit dei loro Tra i FEC a livello fisico pi noti si possono citare quelli interleave, profondit che impone un ritardo sulla utilizzati dalle piattaforme DVB per la diffusione televisiva trasmissione dei pacchetti. broadcast; nellambito del presente lavoro assumono Linterleaving ha infatti leffetto di incrementare di parecchi rilevanza i FEC a livello fisico utilizzati dai sistemi xDSL. millisecondi la latenza della trasmissione. Le reti di accesso in tecnologia DSL incorporano schemi di In pratica nei sistemi DSL vengono comunemente usate due FEC/Interleave come parte delle funzionalit del modem modalit operative: DSL. Questi schemi dipendono dalla particolare versione di DSL e, in alcuni casi, la profondit dellinterleave pu essere regolata (entro un certo range) dal Provider della rete. Per migliorare lestensione della DSL in condizioni di rumore stazionario, si fa uso dei Trellis Code (TC) e dei codici ReedSolomon (RS). Queste codifiche sono in grado di correggere errori di bit/byte isolati, ma non le sequenze di errori di bit consecutivi (burst) introdotte dal rumore impulsivo. Quindi per poter correggere tali sequenze viene postposto (in trasmissione) al FEC linterleaving dei dati. Nel caso di codici Reed-Solomon, linterleaving assicura che due simboli adiacenti nella trasmissione provengano da due codeword diverse. Loperazione di de-interleaving (in ricezione) distribuisce infatti un burst di errori in pi parole di codice in modo tale che gli errori per parola di codice possano essere corretti.
fast mode, che non fa uso dellinterleaving e introduce un ritardo ridotto, ma soggetta a rumore impulsivo; linterleaved mode, che pu correggere quasi tutti gli eventi di rumore impulsivo al costo di un ritardo addizionale dovuto allinterleaving.
9.5.2.2 FEC a livello applicativo e a livello di trasporto Il FEC a livello applicativo e a livello di trasporto si riferisce di solito a tecniche di recupero dei pacchetti persi. In queste tecniche viene inviata una quantit di dati maggiore dello stream da comunicare, con la propriet che lo stream pu essere ricostruito da un qualsiasi sottoinsieme sufficientemente grande di dati trasmessi. In questo modo lo stream in grado di recuperare una certa quantit di perdite (al massimo la differenza tra la dimensione dei dati
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.356 video stream da perdite di pacchetto di tipo a burst. La trasmessi e quella dei dati originari). Per le applicazioni di generazione di FEC packet si basa su una matrice (di streaming ci sono numerosi vantaggi nellusare codici FEC pacchetti) di dimensioni LxD. I FEC packet sono sistematici, in cui i pacchetti originari dello stream (source generati dallOR esclusivo (XOR) dei pacchetti media. packet) vengono inviati insieme ad una certa quantit di Tali codici risultano adeguati per reti IP private, overhead costituita dai FEC packet. I FEC packet possono mentre non sono abbastanza robusti per reti IP con essere usati per recuperare i source packet che sono stati alte perdite, come Open Internet. persi tra il mittente e il ricevitore. Esistono molti schemi ETSI TS 126.346, Multimedia Broadcast/Multicast: Protocols and Codes [62]. possibili di FEC a livello applicativo e a livello di trasporto Questo standard, prodotto dal 3GPP, definisce una per lo streaming di media, che possono essere applicati alla struttura generica per lapplicazione del FEC ai media diffusione televisiva su IP. Alcuni schemi di correzione delle stream. La struttura non specifica per RTP e opera cancellazioni per lo streaming di media che sono stati immediatamente sopra il livello UDP. Questa struttura standardizzati sono i seguenti: potrebbe essere usata con codici FEC differenti, tuttavia il 3GPP specifica e richiede il supporto solo di IETF RFC 2733 [175]. un particolare codice: il codice Raptor. Questa specifica definisce un semplice meccanismo per applicare codici di parit a blocchi corti agli stream RTP. Lo schema limitato dal basso numero di pacchetti che possono essere protetti come un blocco (24 pacchetti). Questo RFC non stato implementato ampiamente e diventer presto obsoleto grazie ad un aggiornamento che fornisce blocchi leggermente pi lunghi (48 pacchetti) e la possibilit di applicare una protezione diversa a parti differenti di ogni pacchetto.
SMPTE Specification 2022-1: Forward Error Correction for Real-time Video/Audio Transport Over IP Networks [61]. Questo standard stato progettato per proteggere un
DVB Bluebook a086r8 DVB-IPTV 1.4: Transport of MPEG 2 TS Based DVB Services over IP Based Networks (and associated XML) [18]. Il DVB ha effettuato una valutazione dei codici FEC per applicazioni di tipo televisive su IP producendo una specifica sui FEC basata su un approccio a strati con uno strato di base costituita da un semplice codice di parit (XOR) adottate dal SMPTE-2022-1 [61] e uno strato pi avanzato basato sui codici Raptor utilizzato nelle specifiche 3GPP [62]. Il meccanismo stato attentamente esaminato e valutato dal DVB in relazione alle prestazioni, flessibilit e agli aspetti di implementazione, per
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.357 IETF RFC 3926 [193]. Il FLUTE fornisce meccanismi soddisfare vari requisiti. Per una descrizione per segnalare ed elencare le propriet di un file al dettagliata dellattivit del DVB in merito si rimanda al protocollo Asynchronous Layered Coding (ALC), in successivo 10.2.3. maniera tale che i ricevitori possano assegnare questi parametri ai file ricevuti. L'oggetto, per essere L'IETF ha recentemente avviato un gruppo di lavoro trasmesso, viene partizionato in uno o pi blocchi fecframe per standardizzare una struttura per l'applicazione sorgente. Per ogni blocco sorgente, possono essere del FEC ai media stream, su linee guida analoghe a quelle generati ulteriori simboli di riparazione mediante del 3GPP (Multimedia Broadcast/Multicast Service per le reti l'applicazione di un codice FEC. Il FLUTE potrebbe cellulari 3G). Non si specifica un particolare codice FEC ma essere utilizzato con diversi codici FEC, tuttavia il 3GPP specifica e richiede il supporto di un unico si definiscono i FEC Building Block, per separare la codice specifico, ovvero il codice Raptor [63]. Il definizione dei protocolli, che utilizzano il FEC, dalla FLUTE insieme al Raptor consente il supporto di specifica dei codici FEC veri e propri. Questo approccio programmi multicast molto efficienti, nonch di servizi consente di utilizzare nello streaming il codice FEC giudicato di tipo carosello. Quest'ultimo supportato in maniera pi efficiente in alternativa alla [175]. Il DVB-IP AL-FEC si efficiente da parte della propriet fontana del codice Raptor. avvale di questo concetto. ETSI TS 102 472 Digital Video Broadcasting: IP Datacast over DVB-H: Content Delivery Protocols FEC per servizi di download [64]. Sono stati standardizzati alcuni schemi FEC da utilizzarsi in Il Content Delivery Protocol (CDP) per il file di servizi di download di file: consegna nel DVB-H riutilizza la tecnologia di
ETSI TS 126 346: Universal Mobile Telecommunications System (UMTS); Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs [62]. Per servizi di delivery download di questo standard viene applicato il File Delivery over Unidirectional Transport (FLUTE), come specificato nel documento
download delivery 3GPP MBMS [62]. L'uso di codici Raptor fortemente raccomandato, in particolare per file con dimensioni superiori a 32 kByte.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.358 di riparazione iniziali per l'attuale blocco di sorgente, le 9.5.3 Combinazione di FEC e ritrasmissione richieste di ritrasmissione necessitano di essere inviate solo Le tecnologie FEC e di ritrasmissione per il recupero di errori nel caso in cui questi dati di riparazione iniziali non siano non sono necessariamente tecnologie concorrenti, ma sufficienti. Se la perdita superiore a ci che pu essere possono essere utilizzati in maniera combinata e riparato dai primi dati di riparazione, possono essere complementare. Mediante l'applicazione di tali combinazioni, effettuate le richieste di ritrasmissione e in risposta il possono essere ottenute alcune interessanti prestazioni. mittente pu inviare ulteriori dati di riparazione per il blocco L'importanza dei benefici dipende, tra gli altri, dal servizio sorgente che indipendente dai primi dati di riparazione. considerato, dalla modalit di distribuzione considerata, vale Tale sistema pu ridurre la quantit di messaggi di feedback a dire multicast o unicast, e/o del numero di server di necessari e quindi pu consentire di ridurre la quantit ritrasmissione. necessaria di server di ritrasmissione rispetto ai tradizionali Per meccanismi basati sulla ritrasmissione e combinati con meccanismi di ritrasmissione. In un setup alternativo, viene un meccanismo di riparazione FEC, i pacchetti di fornito un livello predefinito di protezione AL-FEC a acknowledgement negativo (NACK) possono determinare la condizione che sia in grado di correggere tutti gli errori trasmissione di FEC packet, invece di pacchetti di dati previsti (vale a dire lo stesso livello di AL-FEC protezione originali. Questo pu essere utile soprattutto per il caso di per un meccanismo solo AL-FEC). Per ogni blocco sorgente trasmissione multicast, dato che i FEC packet possono il ricevitore pu inviare un pacchetto acknowledgement servire la richiesta di ritrasmissione di diversi ricevitori, che chiedendo che l'invio di dati FEC per un blocco sorgente sia potrebbero osservare la perdita di pacchetti differenti. Tale terminato in anticipo, in quanto il ricevitore ha ricevuto gi sistema pu consentire di ridurre la larghezza di banda abbastanza dati per recuperare il blocco. Tale sistema pu utilizzata per la trasmissione. consentire di ridurre la larghezza di banda media rispetto ad Per meccanismi basati su FEC, l'introduzione di messaggi di un meccanismo con solo AL-FEC. feedback pu essere utilizzata per influenzare la strategia del mittente. Ad esempio, se i ricevitori sono consapevoli del fatto che il mittente trasmette alcune piccola quantit di dati
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.359 9.6.1 Ritrasmissione vs Forward Error 9.6 Considerazioni comparative sulle Correction
tecniche
Per lanalisi dei meccanismi di protezione dalla perdita dei pacchetti abbastanza comune iniziare da un semplice modello unicast di un client che richiede il contenuto a un server. Questo modello pu adattarsi bene ad alcuni scenari, ma non necessariamente sufficiente per la gamma di servizi in esame. In particolare, bisogna notare che vengono presi in considerazione meccanismi di distribuzione multicast, in cui il controllo di errore pu avere effetti sulla scalatura del servizio. Bisogna notare anche che lo stream di dati video pu essere conservato in cache e modificato in vari punti tra la locazione in cui il contenuto viene acquisito (ad esempio un Super Head End) e il dispositivo della rete domestica che presenta lo stream decodificato sullo schermo dellutente. I meccanismi di controllo di errore dovrebbero essere considerati in relazione a locazioni specifiche allinterno dellarchitettura di distribuzione dei servizi. Pu accadere che un singolo meccanismo non sia sufficiente per larchitettura di servizio end-to-end.
Ambiti di applicabilit Gli ambiti di applicabilit delle tecniche di ritrasmissione (come ad esempio il TCP) e delle tecniche FEC sono diversi. Il campo di applicabilit delle tecniche di ritrasmissione ristretto ai casi in cui disponibile tra il server e il client una connessione di rete bidirezionale. Le ritrasmissioni sfruttano il fatto che il nodo target pu comunicare la perdita dei pacchetti al nodo sorgente. Nel caso delle reti broadcast realizzabile solamente il FEC. Nel caso di reti interattive sono possibili entrambe le tecniche. Latenza Entrambe le tecniche introducono latenza relativa alla semplice pila RTP-UDP-IP. Nel caso di approcci basati sulle ritrasmissioni, il ritardo almeno pari al tempo richiesto per inviare un acknowledgement e ricevere il pacchetto di sostituzione. Nei casi in cui anche gli acknowledgement possono essere persi, il ritardo include pure il tempo richiesto per determinare se un acknowledgement andato perduto, per ritrasmettere lacknowledgement e per ricevere la risposta. In pratica, il playout dei media deve essere ritardato del massimo ritardo atteso, altrimenti il playout
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.360 dei pacchetti sperimentata e dal numero dei client. Le due dovr essere messo in pausa quando si verificano gli eventi tecniche differiscono nelle tattiche di adattamento. sopra descritti. Nel caso degli approcci basati sul FEC, il ritardo al ricevitore almeno pari al tempo pi lungo tra linvio di un FEC packet Rilevamento della presenza di perdite Nel caso degli approcci basati sulle ritrasmissioni, il nodo e linvio del primo pacchetto sorgente che protegge. La sorgente rileva la presenza di perdita dei pacchetti non ricezione dei pacchetti seguenti diventa cos prevedibile. appena riceve un acknowledgement negativo, oppure quando viene rilevata lassenza di un acknowledgement Occupazione di banda positivo, e pu determinare il livello della perdita dei Le due tecniche consumano pi banda della semplice pila pacchetti dai cammini degli ACK o dei NACK. RTP-UDP-IP. Nel caso degli approcci basati sulle Nel caso degli approcci basati sul FEC, la possibilit da ritrasmissioni, richiesta banda supplementare per gli parte del nodo sorgente di rilevare la presenza della perdita acknowledgement e le ritrasmissioni. Loccupazione di dei pacchetti dipende dallesistenza di un feedback dai client banda degli acknowledgement una funzione della quantit al server, per esempio attraverso luso di RTCP, che riporta delle perdite di pacchetti e del numero dei client. Dato che la lesperienza della ricezione dei pacchetti. Quindi in teoria il dimensione dei pacchetti di acknoledgement piccola, nodo sorgente potrebbe cambiare il grado del FEC. loccupazione di banda di un singolo client modesto. Quando le ritrasmissioni vengono inviate in multicast, loccupazione di banda una funzione della quantit delle Cache dei media stream Entrambe le tecniche hanno implicazioni per quanto riguarda perdite di pacchetti di tutti i client. Quando le ritrasmissioni il se e il dove mettere in cache nella rete i media stream. Nel vengono inviate in modalit unicast, la banda una funzione caso degli approcci basati sulle ritrasmissioni, pu essere della quantit delle perdite di pacchetti di ogni client e del necessario mettere i media stream in cache vicine alla rete numero dei client. di accesso in modo da ridurre la catena dei nodi attraverso Nel caso degli approcci basati sul FEC, loccupazione di cui devono passare gli acknowledgement ed evitare il banda dipende dal grado della capacit di recupero degli sovraccarico dei server centrali con le richieste di errori fornita, ma costante indipendentemente dalla perdita
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.361 usano tecnologie DSL che supportano cammini a doppia ritrasmissione. In questa maniera si riduce il round trip time latenza, compresi lADSL [178], lADSL2 [179], lADSL2+ tra la sorgente e il client al prezzo dellinserimento di [180] e il VDSL2 [177]. La doppia latenza fornisce due funzionalit di livello applicativo vicino alla rete di accesso. cammini logici per i dati attraverso il canale fisico: Invece, gli approcci basati sul FEC non richiedono capacit di caching dei contenuti ai bordi della rete. un cammino con un alto ritardo di interleaving 9.6.2 Implicazioni relative alluso del FEC a livello fisico Semplici implementazioni del FEC a livello fisico interessano tutti i dati in un link e hanno effetto su tutti i servizi che usano quel link fisico. Per esempio, se il FEC-interleave del DSL stato regolato con una profondit di 10 ms, allora quel ritardo di 10 ms interesser tutti i servizi che attraversano quel link DSL. Un ritardo addizionale di 10 ms avrebbe un effetto dannoso sia sui servizi (tipo VoIP) che sul throughput TCP. Queste considerazioni sono importanti per unanalisi complessiva e per fornire una soluzione che aiuti un servizio a non avere effetti negativi su un altro servizio. Per esempio, per i servizi di web-browsing e di gioco, il criterio pi importante quello di minimizzare il ritardo per gli scambi di dati molto piccoli, e in questo caso una bassa latenza molto pi importante di una bassa perdita di pacchetti, mentre per i servizi di diffusione televisiva su IP il contrario. Implementazioni pi recenti di FEC a livello fisico (interleaved) che permette bassi tassi di errore, un cammino con un basso ritardo di interleaving (fast path) che spesso presenta tassi di errore pi elevati. Il fast path pu essere usato per applicazioni sensibili al ritardo, come la voce, mentre linterleaved path pu essere usato per applicazioni sensibili agli errori. Anche il VDSL2 ha un meccanismo opzionale per cambiare dinamicamente la profondit dellinterleaver in modo da minimizzare limpatto sulla distribuzione di video quando i canali voce sono accesi o spenti. Il FEC a livello fisico e il FEC a livello applicativo non sono indipendenti e le loro connessioni devono essere tenute in considerazione nel calcolo dei tassi di errore complessivi alluscita. Il rumore impulsivo costituito da burst di rumore di breve durata (decine di microsecondi) con alta potenza. Il rumore impulsivo attenuato nellADSL e nel VDSL usando codici FEC con interleaving, che richiedono un codice di interleaving sufficientemente lungo per correggere dei burst di errore abbastanza lunghi causati dal rumore impulsivo. Per lADSL/2/2+ e per il VDSL2, un forte rumore impulsivo
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.362 percepibili accettabili dallutente. quindi consigliabile che i cancella un intero simbolo DMT (Discrete Multitone servizi televisivi su IP utilizzino anche uno o pi meccanismi Modulation) di 250 microsecondi, o a volte perfino un piccolo di controllo di errore a livello applicativo. numero di pi simboli DMT consecutivi. Il valore INP In base ad analisi svolte, sia le ritrasmissioni che il FEC a (Impulse Noise Protection) il numero di simboli DMT livello applicativo sono applicabili in certi scenari di rete di consecutivi che possono essere corretti in modo affidabile. interesse. Limplicazione che larchitettura di tali servizi LINP cresce allaumentare del ritardo e della ridondanza debba racchiudere entrambe le tecniche. Il caso peggiore di della codifica. LADSL ha un INP pari a 1, lADSL2+ pari a 2 lunghezza del burst di perdita di pacchetti sequenziali si ha e il VDSL2 ha un INP pari a 16. Il ritardo di trasmissione pu durante i guasti dei link con meccanismi di protezione a impattare sulla qualit del servizio per i servizi live broadcast livello IP (Profilo A). In questo caso consigliato che e interattivi. Il ritardo addizionale pu avere effetto su altre larchitettura per servizi televisivi su IP sia in grado di metriche di qualit del servizio come il tempo di sostenere burst di perdite di pacchetti di durata fino a 250 cambiamento del canale. Lo schema FEC introduce anche ms. Inoltre metodi PLC/EC (Packet Loss Concealment/Error un overhead addizionale per la correzione degli errori e Concealment) possono essere impiegati insieme ai metodi quindi richiede banda aggiuntiva, che pu essere un di ritrasmissione e ai metodi FEC. problema in alcuni scenari di servizio. Come si gi accennato, il DVB ha portato avanti una 9.6.3 Uso congiunto di tecniche differenti valutazione dettagliata dei codici FEC proposti per le applicazioni di diffusione televisiva su IP, giungendo alla Data la scala WAN dei servizi di diffusione televisiva su IP, il definizione di un nuovo codice FEC specifico basato su un numero delle entit logiche coinvolte, la potenziale sistema ibrido, costituito da un semplice codice di parit distribuzione geografica degli eventi di perdita dei pacchetti, XOR preso da [61] e dal codice Raptor, [62]. Anche lATIS la variet delle tecnologie di link e la condivisione dei link prevede limpiego di tale codice nellambito della propria con altri tipi di traffico, ci si aspetta che i meccanismi di architettura. controllo derrore specifici per il livello di collegamento non Per una descrizione dettagliata dellattivit del DVB in merito siano sufficienti da soli ad assicurare delle prestazioni si rimanda al successivo 10.2.3.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.363 In questo contesto lo standard 2022-1 dellSMPTE, [61], 10 Qualit del Servizio: definisce una tecnica di FEC a livello applicativo per tecniche AL-FEC per lIPTV correggere errori legati ad eventi di perdita di pacchetti su reti IP. I meccanismi FEC sono in tal caso utilizzati non tanto 10.1 Gli standard 2022-1 e 2022-2 come usualmente avviene per correggere gli errori introdotti dellSMPTE dal canale di trasmissione, quanto per compensare perdite LSMPTE ha approvato il Code of Practice #3 del Pro-MPEG di pacchetti dovute ai meccanismi di funzionamento delle reti Forum come proprio standard con il nome SMPTE 2022-1 IP (scarto di pacchetti nei router, ricezione dei pacchetti out [61]. Si noti che lo standard 2022-1 un documento molto of time, cfr. 9.1.1). rilevante, anche in quanto viene riferito da architetture e In particolare viene definito un meccanismo strutturato per il standard differenti soprattutto per aspetti qualitativi che FEC, senza tuttavia specificare le circostanze in cui tale riguardano il Forward Error Correction. meccanismo dovrebbe esser usato. Infatti lasciata La sempre crescente necessit di distribuire contenuti audioallimplementatore la facolt di determinare se e quando video compressi, come i Transport Stream MPEG-2, e la utilizzare il FEC sulla base delle caratteristiche della rete IP progressiva crescita della banda disponibile nelle reti IP in uso e se il meccanismo in grado o meno di soddisfare i private e in Internet hanno spinto fortemente alluso di tali requisiti dellapplicazione considerata. infrastrutture di trasporto per la diffusione dei suddetti Le applicazioni a cui fa riferimento questo standard sono le contenuti. Tuttavia i protocolli di trasporto tradizionali previsti applicazioni audio/video real-time e possono impiegare per reti IP non consentono la realizzazione di un servizio con qualsiasi schema di trasporto previsto per i contenuti audiocaratteristiche di qualit tali da soddisfare a pieno le video trattati. Il FEC introdotto da SMPTE fa parte quindi dei esigenze dellutente. cosiddetti Application Layer FEC, in quanto si colloca a Al fine di compensare tali carenze vengono definiti opportuni livello dellapplicazione ed indipendente dal trasporto meccanismi distribuiti sui vari strati dellarchitettura di utilizzato. Lo standard definisce due livelli di FEC: comunicazione. livello A che prevede un solo FEC stream;
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.364 le quali sono pi tollerabili errori occasionali rispetto livello B che prevede due FEC stream. alloverhead introdotto dal FEC. Sempre in questo contesto, lo standard [186] (cfr. 10.1.2) Su reti IP, le tre cause tipiche di perdita di pacchetti sono: dellSMPTE indica le modalit di applicazione dei protocolli di trasporto esistenti, per trasportare flussi MPEG-2 Transport Stream su reti IP in maniera unidirezionale, realtime e a bitrate costante (CBR). Le applicazioni a cui fa riferimento questo standard sono sempre applicazioni audio/video real-time, che possono prevedere qualsiasi schema di compressione che sia incapsulato in un flusso MPEG-2 Transport Stream a bitrate costante. In tale ambito sono inoltre definite due classi di apparati:
assenza di riordino dei pacchetti in ricezione; perdite a burst dovute a scarto di pacchetti operato da entit di rete;
classe 1: supporta pacchetti Transport Stream a 188 byte; classe 2: supporta pacchetti Transport Stream a 188 byte e 204.
10.1.1 Standard SMPTE per Forward Error Correction In molte applicazioni gli errori causati da perdite di pacchetti in reti IP non possono esser accettati e quindi queste applicazioni possono trarre vantaggio dallapplicazione di un meccanismo di FEC. Luso del FEC, come viene definito in [61], pu essere raccomandato, ma vi sono applicazioni per
pacchetti scartati a causa di bit-error (trascurabili in reti wired). Quando si usano i meccanismi previsti da questo standard, viene scartato lintero pacchetto anche se questo affetto da un unico bit errato, non essendo previsti meccanismi in grado di gestire pacchetti contenenti errori. Il meccanismo previsto opera su un certo numero di pacchetti consecutivi contenenti payload di tipo audio/video (media packet) generando un corrispondente FEC packet il cui payload contiene le informazioni per il recupero di uno o pi pacchetti audio/video persi tra quelli corrispondenti (cfr, Figura 10-1). Il contenuto di tali FEC packet conforme a quanto definito dal protocollo RTP per i pacchetti Generic Forward Error Correction (cfr. RFC 2733, [175]) aventi le stesse finalit. LRFC 2733 permette luso dei codici di correzione di errore tradizionali. Il vantaggio pi importante di questo schema che si pu usare con qualsiasi formato di trasporto audio/video standardizzato purch incapsulato in pacchetti
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.365 Relativamente allRFC 3550, si prevedono i seguenti vincoli RTP (media packet), ma con la limitazione che il numero di aggiuntivi: pacchetti consecutivi su cui calcolato il payload del FEC packet non superi il valore di 24. l'uso, da parte di mittenti e riceventi, dei seguenti bit Per recuperare perdite di tipo burst, lSMPTE definisce definiti dagli associati standard di trasporto audio/video: unestensione al meccanismo previsto dallRFC 2733, [175]. bit Padding (P), Tale estensione prevede che gli stessi codici tradizionali di bit Marker (M), correzione siano applicati a media packet non consecutivi, bit Extension (X), con l'ulteriore vincolo la lunghezza spaziati anche di un numero maggiore di 24 pacchetti. dellestensione deve essere costante per tutta la Ciascun FEC packet quindi associato a pacchetti durata della sessione. periodicamente selezionati. Quindi pacchetti RTP di tipo I parametri seguenti devono essere settati dal mittente nel media packet consecutivi, persi, possono essere recuperati modo indicato: a partire da FEC packet consecutivi (cfr, Figura 10-2). il campo CSRC Count (CC) deve essere posto a zero. Questo significa che non ci sono voci nel CSRC 10.1.1.1 Schema di incapsulamento RTP dei (Contributing SouRCe list); media packet il valore del campo SSRC (Syncronization SouRCe Lo standard SMPTE 2022-1, [61], introduce alcune limitazioni relativamente alla costruzione di media packet, protetti da uno schema FEC. Queste saranno brevemente descritte qui di seguito. previsto obbligatoriamente luso dellRTP, in quanto fornisce uno header standard per i pacchetti. Gli apparati devono utilizzare unicamente il protocollo RTP, come specificato nellRFC 3550, [36], e, conseguentemente, non richiedono ulteriori modalit di comunicazione. identifier un identificatore della sorgente scelto in modo random) non pu essere considerato affidabile da parte del ricevitore, il trasmettitore libero di assegnarlo a qualsiasi valore. Non vi obbligo di assegnazione casuale per il numero iniziale di sequenza come suggerito nel RFC 3550, [36]. 10.1.1.2 Generazione dei FEC packet
Come gi accennato in 10.1, lo schema FEC definito nello standard SMPTE 2022-1, [61], una versione estesa di
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.366 quello introdotto dallRFC 2733, [175]. Ogni FEC packet associato a media packet periodicamente selezionati. Pertanto, i media packet consecutivi possono essere recuperati da FEC packet consecutivi. Il processo viene descritto con maggiore dettaglio nella Figura 10-1, in cui i pacchetti RTP sono graficamente disposti lungo righe e colonne secondo indici crescenti, L indica il numero delle colonne di pacchetti protetti e D indica il numero delle righe. Il vantaggio maggiore dello schema proposto rispetto allRFC 2733, [175], la capacit di correggere burst di errori. La funzione di correzione degli errori lo XOR, che ha la capacit di recuperare un singolo pacchetto perso tra quelli su cui calcolato. Se viene utilizzato uno schema Figura 10-1: Schema di codifica monodimensionale basato sullo XOR (cio applicato a D Nella Figura 10-1 lo schema di codifica previsto per L*D pacchetti consecutivi), un burst di errore di due o pi media packet. Il periodo scelto tra media packet coperti da pacchetti persi non recuperabile. Tuttavia se si usa uno un determinato FEC packet pari ad L. In tal modo il schema bidimensionale, la capacit di recupero aumenta, payload del kth FEC packet calcolato su D pacchetti dato che si recuperano fino a L pacchetti consecutivi. numerati nL+k (0 n D - 1). Lallineamento delle colonne riportato in Figura 10-1 a scopo puramente illustrativo. La tecnica di interleaving dei pacchetti non definita dallo standard. Alcune implementazioni possono avvalersi dellallineamento di Figura 10-1 per semplicit, ma esistono alcuni vantaggi derivanti da tecniche di interleaving dei
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.367 ricevitori di livello B devono processare zero, uno o due pacchetti alternative come riportato negli annessi informativi stream FEC. dello standard, [61]. Il secondo stream FEC deve essere applicato a una serie L In questo standard vengono definiti due livelli di protezione di pacchetti consecutivi, in cui L il periodo con il quale FEC, il livello A e il livello B. I dispositivi di livello A operano stato ricavato il primo stream (cfr. Figura 10-1). Se le su un unico stream FEC, quelli di livello B operano colonne sono allineate questo fatto produrr una struttura contemporaneamente su due stream FEC simultanei. Questi FEC come mostrata nella Figura 10-1, dove i pacchetti stream FEC devono essere indirizzati su porte UDP etichettati con RTP sono i media packet, i pacchetti separate, per consentire loro di avere numeri di sequenza etichettati con FEC colonna sono il primo stream di FEC gestiti separatamente, al fine di mantenere una compatibilit packet, mentre i pacchetti etichettati con FEC riga sono il allindietro con le implementazioni che supportano un unico secondo stream di FEC packet. flusso FEC. Per i mittenti che emettono uno stream FEC, i media packet devono essere inviati verso la porta di destinazione N (dove N un numero intero, anche per RFC 3550, [36]), e il singolo stream di FEC packet deve essere inviato verso la porta di destinazione N+2. Per i mittenti che emettono due stream FEC, il primo stream di FEC packet deve essere inviato verso la porta di destinazione N+2 e il secondo stream di FEC packet deve essere inviato verso la porta di destinazione N+4. La funzione FEC in trasmissione deve poter essere abilitata o disabilitata. I ricevitori di livello A devono processare zero o uno stream Figura 10-2: Struttura della modalit FEC 2D FEC e devono avere la possibilit di poter continuare a funzionare nominalmente in presenza di due flussi FEC. I
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.368 Dato che lunico traffico RTP inviato e ricevuto dagli apparati Il secondo stream FEC in grado di far fronte ad ogni conformi a questo standard composto dai media packet e singola perdita di pacchetto e il primo stream FEC in grado dai FEC packet associati, questi ultimi devono utilizzare per di far fronte a perdite burst di lunghezza fino a L. il campo payload type un valore di tipo dinamico, secondo Un FEC packet costruito inserendo un FEC header e un quanto previsto da RFC 3550, [36], ed in particolare il primo FEC payload nel payload di un pacchetto RTP come valore disponibile, che 96 in decimale. Inoltre devono mostrato in Figura 10-3. essere applicate le seguenti restrizioni aggiuntive:
il trasmettitore deve impostare il campo SSRC a zero per essere compatibile con lo standard 2022-1, [61]. Altri valori di SSRC sono riservati. Il valore del campo SSRC deve essere usato dal ricevitore. non c alcun requisito affinch il numero di sequenza iniziale venga assegnato casualmente, come suggerito nellRFC 3550, [36]. Il campo timestamp sui FEC packet deve essere ignorato dai ricevitori. Formato dellheader FEC
Figura 10-3: Struttura del FEC packet 10.1.1.3 Formato dellheader RTP del FEC packet LRFC 2733, [175] pone dei vincoli sui valori dei campi nellheader RTP, in particolare specifica il fatto che i campi P, X, M e CC vengono ricavati dai media packet, ma a causa delle restrizioni imposte (cfr. 10.1.1.1) i valori di tali campi sono come definiti nello standard 2022-1, [61], dellSMPTE.
10.1.1.4
Lheader FEC descritto nellRFC 2733, [175], originariamente di 12 byte. Per permettere lestensione allo schema di correzione di errore, lheader FEC deve essere definito come segue (cfr. Figura 10-4).
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.369 I campi addizionali sottostanti devono essere modificati rispetto allRFC 2733, [175], o sono nuovi. Le loro definizioni sono le seguenti:

Figura 10-4: Definizione dell'header FEC I seguenti campi devono essere usati come definito dallRFC 2733, [175]:
E: deve essere posto a 1 per indicare che lheader esteso. Mask: deve essere impostato a zero per le implementazioni che supportano lo standard SMPTE 2022, invece deve essere usato il campo NA per le implementazioni che non supportano questo standard. N: questo bit riservato per estensioni future dellheader e deve essere posto a zero. D: questo bit deve essere impostato a zero per i FEC packet del primo stream FEC, a 1 per i FEC packet del secondo stream FEC. Questo bit viene fornito come mezzo aggiuntivo per determinare quali FEC packet sono associati a quale stream FEC. Type: questo campo indica quale codice di correzione FEC viene scelto e deve essere impostato a zero nel caso di uso del metodo XOR. Nel caso duso di FEC di tipo differente opportuni valori del campo dovranno essere impostati dallapplicazione. I ricevitori devono ignorare i pacchetti con il valore di un tipo non riconosciuto. Index: questo campo usato per codici di protezione pi complessi e deve essere impostato a zero. Per il metodo XOR, un unico FEC packet protegge ciascun
SNBase low bit: 16 bit meno significativi del numero di sequenza minimo dei pacchetti (media packet) associati al FEC packet; nel caso in cui numeri di sequenza di 16 bit sono sufficienti, questo parametro deve contenere lintero numero di sequenza. Length recovery: questo campo dovrebbe essere usato per determinare la lunghezza di ogni media packet associato al FEC packet. PT recovery: questo campo dovrebbe essere usato per determinare il Payload Type di ciascun media packet associato al FEC packet. TS recovery: questo campo dovrebbe essere usato per recuperare il timestamp di ciascun media packet associato al FEC packet.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.370 I media packet protetti da un certo FEC packet devono gruppo di media packet e quindi il campo Index conterr sempre 0. essere definiti come quelli con numeri di sequenza dati dalla Offset: questo campo di un byte il periodo usato per formula SNBase + j*Offset, 0 j NA. selezionare i media packet associati con questo FEC packet, e deve essere il parametro L per i pacchetti 10.1.1.5 Aspetti di sagomatura del traffico calcolati sulle colonne (il primo stream FEC). Per i FEC pacchetti calcolati sulle righe (il secondo stream FEC), questo parametro deve essere sempre 1. Questo I trasmettitori che utilizzano il meccanismo FEC dovrebbero campo deve essere tenuto costante dal trasmettitore assicurarsi che i FEC packet siano interallacciati con i media per ogni stream FEC durante una trasmissione. packet in modo tale da evitare il verificarsi di variazioni NA: questo campo di un byte indica il numero di temporali elevate del data rate trasmesso. Lo standard in media packet associati a questo FEC packet, e deve oggetto suggerisce alcuni accorgimenti per sagomare essere il parametro D per i pacchetti appartenenti al opportunamente lo stream IP in uscita dal sistema FEC. primo stream FEC, e deve corrispondere al parametro Si noti che ogni singolo FEC packet indica il numero di L per i pacchetti appartenenti al secondo stream FEC. Questo campo deve essere tenuto costante dal sequenza base (SN-base), loffset (L) e un numero di trasmettitore per ogni stream FEC durante una pacchetti di dati (NA). I ricevitori devono osservare questi trasmissione. valori trasmessi in ogni FEC packet per associare SNBase ext bit: questo campo per luso con correttamente il FEC packet ai media packet. protocolli che richiedono numeri di sequenza estesi pi lunghi di 16 bit. Dove numeri di sequenza di 16 bit 10.1.1.6 Tolleranza al riordinamento dei sono sufficienti, questo parametro deve essere posto a zero. Per i protocolli con numeri di sequenza pi pacchetti lunghi questo campo deve contenere i successivi otto Per i pacchetti che viaggiano su reti IP non viene garantita la bit pi significativi del numero di sequenza oltre quelli consegna nellordine con cui sono stati inviati. La contenuti nellSNBase. numerazione in sequenza garantita dallRTP, che dovrebbe permettere la correzione di questo effetto da parte
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.371 del dispositivo di ricezione. Qualsiasi riordinamento 10.1.2 Standard SMPTE per trasporto di flussi dovrebbe essere di piccole dimensioni, meno di dieci TS MPEG-2 a bitrate costante su reti IP pacchetti fuori sequenza. Pur essendo essenzialmente uno standard di trasporto, Se invece un pacchetto fuori sequenza al di l del limite lSMPTE 2022-2, [186] stato sviluppato congiuntamente suddetto, al fine di limitare la latenza complessiva del allSMPTE 2022-1, [61], e viene logicamente visto come sistema, pu essere scartato, per poi essere recuperato strato di trasporto di flussi audio/video conformi a questo dallo schema FEC come se si trattasse di un pacchetto ultimo. In [186] si forniscono infatti valutazioni di overhead perso. Se un sistema mantiene pi matrici FEC pu tollerare ed altri parametri relativi proprio allimpiego congiunto dei il riordinamento allinterno di questo gruppo di matrici. due standard. Da ci deriva la collocazione di questo Il ricevitore dovrebbe quindi riordinare i pacchetti entro un paragrafo, dedicato alla descrizione dello standard [186], in minimo di dieci pacchetti prima di ricorrere allapplicazione questa parte del lavoro. del FEC. La tecnica prevista [186], analogamente ad una delle 10.1.1.7 Configurazione di sistema modalit di trasporto definite dal DVB, [17], quella facente uso dellRTP, basata su due RFC dellIETF, [35], [36] con poche particolarizzazioni relative a specifici valori di campi nellheader dei pacchetti RTP. 10.1.2.1 Configurazione del trasmettitore
I seguenti parametri devono essere i parametri minimi necessari per un sistema configurabile:
i trasmettitori e i ricevitori devono supportare tutti i numeri di porta della serie di porte registrate, e la gamma di porte dinamiche o private come identificate nel registro di porte IANA; lo stream FEC deve usare lo stesso indirizzo IP di destinazione (o unicast o multicast) del flusso di dati (media packet) associato; lo stream FEC deve usare la stessa porta UDP di sorgente del flusso di dati (media packet) associato.
Nel 3.7.1.1 si sono riportate alcune considerazioni riguardanti lopportunit di evitare la cosiddetta frammentazione dei pacchetti nei sistemi di trasporto di contenuti audio-video in reti IP. Anche lo standard SMPTE 2022-2, [186], raccomanda che venga evitata la frammentazione IP alluscita del dispositivo
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.372 lunghezza dei pacchetti IP quella relativa ad un valore di trasmittente, garantendo che i pacchetti IP emessi dal MTU pari a 1500. Pacchetti IP lunghi sono sconsigliati a dispositivo siano di lunghezza conforme alla MTU della rete. causa delleccessivo impatto che avrebbe la perdita di un Il bit dont fragment dei pacchetto IP deve quindi essere pacchetto sul flusso TS ricostruito. Daltra parte pacchetti posto ad 1. Lunit massima di trasmissione (MTU) troppo corti causano un eccessivo overhead (di dati di generalmente di 1500 byte, in quanto gli end-point vengono protocollo rispetto al flusso trasmesso), quindi la lunghezza solitamente connessi a reti Ethernet. del pacchetto deve essere stabilita sulla base di un 10.1.2.2 Incapsulamento del TS in opportuno compromesso tra questi due fattori tenendo conto RTP/UDP/IP delle caratteristiche della rete e di quelle dellapplicazione con particolare riguardo ai meccanismi di recupero previsto obbligatoriamente luso del protocollo RTP (RFC disponibili. Per semplicit il valore viene scelto costante 3550, [36]) utilizzando lo schema di incapsulamento durante una sessione di spedizione e ricezione. I valori che utilizzato dallRFC 2250, [37], per lincapsulamento in RTP vengono generalmente usati sono 1, 4 o 7. dei Transport Stream MPEG-2. Lo standard precede due modalit operative relativamente Alle RFC 3550, e RFC 2250, sono apportate le restrizioni alla lunghezza dei pacchetti TS. Alla prima corrisponde la seguenti: lunghezza 188 byte, alla seconda 204 byte. La prima il bit di Padding (P) posto a zero. Questo significa modalit supportata da dispositivi di classe 1 mentre che non ci saranno byte di padding nel payload. dispositivi di classe 2 possono supportare entrambe le il bit Extension (X) posto a zero. Questo significa modalit operative. Come gi detto, la lunghezza dei che non ci saranno header extension. pacchetti TS deve essere mantenuta costante per la durata il bit Marker (M) posto sempre a zero. Questo della sessione. significa che non ci saranno discontinuit nello stream Un ricevitore di classe 2 pu determinare la lunghezza del durante una sessione. Il numero di pacchetti MPEG Transport Stream che pacchetto TS verificando la lunghezza del payload dei possibile inserire in un pacchetto IP va da un minimo di 1 a pacchetti RTP: se il pacchetto TS di 188 byte allora la un massimo di 7, ipotizzando come limitazione della
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.373 Transport Stream (MPTS), nei quali potrebbero essere lunghezza del payload RTP un divisore esatto di 188 e presenti pi PCR (associati a programmi differenti) che non di 204; viceversa per i pacchetti di 204 byte. potrebbero cambiare nel tempo. Nel caso di stream CBR La versione attuale dellRFC 2250, [37], non menziona non richiesto che i sistemi trasmittenti aggancino il loro esplicitamente i pacchetti da 204 byte; cos la maggior parte timestamp RTP ad alcun PCR. delle implementazioni esistenti supportano pacchetti di 188 I sistemi di ricezione non dovranno assumere che i byte. timestamp RTP siano agganciati ai PCR. Inoltre il PCR non 10.1.2.3 Temporizzazione deve essere modificato, in valore e in posizione, dai dispositivi trasmittenti. I pacchetti nulli presenti nello stream I sistemi basati su MPEG-2 Transport Stream prevedono sono tenuti preservati dai dispositivi trasmittenti. che linformazione per il recupero della temporizzazione sia presente nel TS medesimo (informazione PCR). Questa informazione temporale precisa inserita solamente in alcuni pacchetti TS, perci nel dominio IP non tutti i pacchetti IP conterranno il suddetto timestamp. LRFC 2250, [37], presenta sua volta un meccanismo di recupero della temporizzazione, sebbene il clock di questo meccanismo abbia una risoluzione di soli 90kHz (contro i 27 MHz del PCR). Comunque sotto determinate limitazioni ci potrebbe esser sufficiente a consentire il recupero del clock per gli stream CBR. LRFC 2250, [37], richiede che il clock RTP sia derivato (agganciato) dal clock PCR, ma questa non una richiesta realistica per sistemi che gestiscono i Multi-Program 10.1.2.4 Overhead FEC buffer e implicazioni sulla latenza Vengono poste delle limitazioni ai valori dei parametri di L e di D per limitare la latenza introdotta, facilitare linteroperabilit e semplificare le implementazioni. Al minimo i trasmettitori e i ricevitori devono supportare tutte le combinazioni di valori di L e di D che soddisfino i seguenti limiti:
L D 100 1 L 20
4 D 20
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.374 Queste limitazioni si rivolgono ad entrambi gli stream FEC. Valutazione della latenza Un apparato supporter solamente due stream FEC nel La Tabella 10-1, tratta da [186], riporta i valori delloverhead, della latenza e della capacit di ricostruzione recupero di caso in cui L 4 . pacchetti persi, per differenti valori di L e di D. Vengono considerati 7 pacchetti TS per ogni pacchetto IP.
Latenza Overhead 3Mbps XOR (5,10) XOR (10,10) XOR (20,5) XOR (8,8) XOR (10,5) XOR (8,5) XOR (5,5) XOR (4,6) XOR (6,4) 10% 10% 20% 12,5% 20% 20% 20% 16.7% 25% 175,5 ms 350,9 ms 350,9 ms 224,6 ms 175,5 ms 140,4 ms 87,7 ms 84,2 ms 84,2 ms 30 Mbps 17,5 ms 35,1 ms 35,1 ms 22,5 ms 17,5 ms 14,0 ms 8,8 ms 8,4 ms 8,4 ms 100 Mbps 5,3 ms 10,5 ms 10,5 ms 6,7 ms 5,3 ms 4,2 ms 2,7 ms 2,5 ms 2,5 ms Max numero di pacchetti recuperabili 5 pacchetti IP 10 pacchetti IP 20 pacchetti IP 8 pacchetti IP 10 pacchetti IP 8 pacchetti IP 5 pacchetti IP 4 pacchetti IP 6 pacchetti IP Dimensione Buffer 66400 Byte 132800 Byte 132800 Byte 84992 Byte 66400 Byte 53120 Byte 33200 Byte 31872 Byte 31872 Byte
10.1.2.5
Tabella 10-1: Overhead e latenza configurare il numero della dovrebbero supportare la Configurazione del sistema versione IGMP2 e potrebbero supportare la 3.
Il terminale dovrebbe permettere di configurare il byte TOS dellheader IP. In questa maniera saranno permessi sia i valori tradizionali TOS, sia la mappatura DiffServ (cfr. 9.4). Mittenti e destinatari dovrebbero esser in grado di
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.375 Internet o di altro tipo c una componente di deriva, dal 10.1.2.6 Jitter, latenza, tolleranza al momento che il carico della rete cambia in un periodo di 24 riordinamento e cifratura ore; questa sar maggiore, di almeno 30-40 ms. Per Negli annessi allo Standard SMPTE 2022-2, [186], vengono semplicit queste due componenti possono essere trattate fornite indicazioni su alcuni parametri per valutare le come una sola, fornendo un buffer con un jitter budget di prestazioni di sistemi basati su tale standard. 120 ms. Questo buffer dovrebbe essere fatto lavorare a mezzo carico, procurando una latenza di 60 ms. Per Prestazioni flessibilit, si raccomanda che sia possibile modificare la Le applicazioni a cui fanno riferimento i meccanismi descritti dimensione del buffer, poich la rete pu avere prestazioni nel documento SMPTE 2022-2, [186], sono applicazioni di in termini di jitter significativamente peggiori o migliori trasporto professionali nel contesto della collaborazione rispetto ai valori suddetti. Lassorbimento del jitter deve (punto-punto) e della distribuzione (punto - multipunto). essere gestito con attenzione, per assicurare che il flusso Queste classi di applicazioni devono fornire una qualit del MPEG rigenerato sia ancora legale anche in termini di servizio definita; ci pu essere ottenuto solo conoscendo la accuratezza del PCR. qualit del servizio del supporto di rete. Il documento definisce un modello di rete di riferimento e un numero di criteri con obiettivi di prestazioni di rete delimitati per diverse classi di qualit del servizio di rete. Tolleranza al jitter Il jitter della rete pu essere assorbito dal buffer di ricezione. In genere il jitter di rete composto da due componenti. C una prima componente ad alta frequenza, causata dai picchi di traffico nella rete; che tende ad avere un valore basso, dellordine di 10-15 ms. Sulle reti che trasportano traffico
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.376 Cifratura Latenza Sar possibile usare i sistemi standard di MPEG Conditional La latenza del processo di elaborazione di un flusso TS Access prima dellincapsulamento IP. Per gli utenti che MPEG-2 al fine di generare un corrispondente flusso di vorrebbero mandare in streaming contenuti senza usare pacchetti IP per il trasferimento in rete determinata dalla MPEG Conditional Access, IPsec fornisce mezzi di cifratura combinazione di contributi dovuti al buffer di tolleranza al a livello IP. jitter, al sistema FEC e al meccanismo di recupero della temporizzazione. Per la valutazione della latenza complessiva del servizio si deve tener conto inoltre della presenza di contributi addizionali legati alle latenze del processo di codifica/decodifica MPEG e della trasmissione in rete IP. Alcune applicazioni professionali per videocomunicazione interpersonale hanno requisiti di round trip delay molto stringenti. Un round trip delay di 400 ms considerato come il peggior ritardo accettabile per applicazioni live di video e audio. Tolleranza al riordinamento dei pacchetti Per i pacchetti che viaggiano su reti IP non viene garantita la consegna nellordine con cui sono stati inviati. La numerazione in sequenza garantita dallRTP, che dovrebbe permettere la correzione di questo effetto allinterno del terminale di ricezione. Qualsiasi riordinamento dovrebbe essere di piccole dimensioni, meno di dieci pacchetti fuori posto.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.377 nella Figura 10-5. In questo modello per tutti gli input
10.2 Raptor Code

In questo paragrafo verr data una descrizione dei codici Raptor e dei codici da cui derivano, ovvero i codici a fontana e i codici LT (Luby Transform). In particolare i codici a fontana possono essere di vari tipi; nel lavoro vengono esaminati i codici a fontana lineari casuali. Tali codici di correzioni vengono utilizzati per poter recuperare le perdite di pacchetti che avvengono in canali con cancellazioni, quali Internet. 10.2.1 Canali con cancellazione I canali con cancellazioni hanno notevole importanza dato che Internet un canale con cancellazioni. Su internet i file inviati vengono segmentati in pacchetti e ogni pacchetto o viene ricevuto senza errore oppure non viene ricevuto. Anche i canali rumorosi, a cui sono stati applicati buoni codici di correzione di errore, si comportano come canali con cancellazione; molte volte questi codici si comportano in maniera perfetta, occasionalmente il decodificatore fallisce e riporta lerrore, cos il ricevitore sa che lintero pacchetto stato perso. Un semplice modello di canale per descrivere questa situazione un canale con cancellazione q-ario, illustrato
nellalfabeto di ingresso
{0,1, 2,..., q 1} si ha un probabilit 1 f , e una f . La

'?' pari a
I
di trasmettere linput senza errore pari a probabilit di consegnare loutput
dimensione q dellalfabeto pari a 2 , dove I il numero di bit in un pacchetto.
Figura 10-5: Esempio di canale con cancellazione 8-ario I metodi utilizzati per la comunicazione sui canali con cancellazioni impiegano un canale di feedback, che va dal
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.378 ricevitore al mittente e che viene usato per controllare la (1 f ) di pacchetti casuale. Se devono essere ritrasmessi ritrasmissione dei pacchetti cancellati. I protocolli che tutti i pacchetti che mancano a uno o pi ricevitori, allora utilizzano la ritrasmissione, cfr. 9.5.1, hanno il vantaggio di queste ritrasmissioni saranno estremamente ridondanti. lavorare in maniera indipendente dalla probabilit di Ogni ricevitore avr gi ricevuto gran parte dei pacchetti cancellazione
f.
ritrasmessi. 10.2.2 Codici a fontana I codici a fontana sono codici a grafo sparso per canali con cancellazioni, dove i file vengono trasmessi in tanti pacchetti di piccole dimensioni, ognuno dei quali o viene ricevuto senza errore oppure non viene ricevuto. I protocolli standard di trasferimento di file scompongono un file in K parti della dimensione di un pacchetto, per poi trasmettere iterativamente un pacchetto fino a quando non viene ricevuto con successo. Per permettere al trasmettitore di scoprire i pacchetti che devono essere ritrasmessi necessario un canale di ritorno. Al contrario i codici a fontana costruiscono pacchetti che sono funzioni random dellintero file. Il trasmettitore invia pacchetti al ricevitore senza sapere quali pacchetti vengano ricevuti. Una volta che il ricevitore ha ricevuto N pacchetti qualsiasi, con N leggermente maggiore della dimensione
Tuttavia se si vuole seguire scrupolosamente la teoria di Shannon si noter che questi protocolli comportano degli sprechi. Infatti se la probabilit di cancellazione f grande, allora il protocollo che identifica i pacchetti mancanti invier un numero grande di messaggi di feedback. Se invece viene utilizzato il protocollo che invia messaggi di acknowledgement per i pacchetti non ricevuti, allora possibile che il ricevitore riceva molte copie ridondanti di alcuni pacchetti, conducendo ad un uso massiccio del canale di feedback. Secondo la teoria di Shannon non c bisogno del canale di feedback, in quanto la capacit del canale forward
(1 f ) * I bit, con o senza feedback. A questo rate

dovrebbero essere possibili comunicazioni affidabili con laiuto di un codice FEC appropriato. La dispendiosit dei protocolli con ritrasmissione evidente soprattutto nel caso di canale broadcast con cancellazioni, in quanto ognuno dei tanti destinatari riceve una frazione
K del file originale, lintero file pu essere recuperato.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.379 di pacchetti codificati generati pu essere determinato al I costi computazionali dei migliori codici a fontana sono volo. asintoticamente piccoli e scalano linearmente con la Indipendentemente dalle statistiche degli eventi di dimensione del file. cancellazione sul canale, si possono inviare tanti pacchetti Un codice a fontana produce per un dato insieme di K codificati quanti sono necessari per permettere al simboli in ingresso ed un flusso potenzialmente infinito di decodificatore di recuperare i dati sorgente. I dati sorgente simboli di uscita. Per questo motivo si pu immaginare il codificatore di un codice a fontana come una fontana che possono essere decodificati da qualsiasi insieme di K produce un flusso interminabile di gocce dacqua, che sono pacchetti codificati, con K leggermente pi grande di K . i pacchetti codificati. Supponendo che il file sorgente originale abbia una dimensione di K * I bit, si pu dire che ogni goccia contenga I bit codificati. Chiunque desideri ricevere il file codificato deve ricevere un numero di goccie leggermente pi grande di K , cos da poter recuperare lintero file. I simboli di uscita sono ottenuti in maniera indipendente uno dall'altro e in modo casuale. Ciascun simbolo di uscita infatti dato dalla somma di un insieme di simboli d'ingresso e tale insieme scelto seguendo una determinata distribuzione. Si suppone inoltre che i simboli d'uscita contengano al loro interno l'informazione che descrive quali simboli d'ingresso hanno contribuito a generarli. I codici a fontana sono senza rate, ovvero il numero di pacchetti codificati, che possono essere generati dal messaggio sorgente, potenzialmente illimitato e il numero 10.2.2.1 Il codice a fontana lineare casuale I codici a fontana pi semplici sono i codici lineari casuali. Si consideri un codificatore per un file di dimensione K pacchetti
( s1 , s2 ,, sK ) ; in questo caso, un pacchetto
lunit elementare che o viene trasmessa intatta o viene cancellata dal canale con cancellazione. Si assume che un pacchetto sia composto da un numero intero di bit. Ad ogni ciclo di clock, identificato con n , il codificatore genera K bit casuali
{Gkn }
e il pacchetto trasmesso tn
impostato alla somma bit a bit, modulo 2, dei pacchetti sorgente per i quali Gkn 1. Quindi tn viene generato come segue:
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.380 K I pacchetti vengono trasmessi, ma a causa delle perdite tn = sk Gkn dovute al canale un certo numero di pacchetti non arriva al
k =1
Questa somma pu essere ottenuta eseguendo degli XOR successivi tra i pacchetti. Si pu pensare che ogni insieme di
ricevitore, che, supponiamo, raccoglie N pacchetti. Si assuma che il ricevitore conosca il frammento della matrice generatrice G associato ai suoi pacchetti.
K bit definisca una nuova colonna in una matrice binaria

generatrice del codice e che cresce ad ogni ciclo di clock, come illustrato nella Figura 10-6.
G pu essere generata da un generatore di numeri casuali

deterministico e il ricevitore ha un generatore identico sincronizzato a quello del codificatore. In alternativa, il mittente potrebbe scegliere una chiave casuale, quale vengono determinati i
kn , data la
tramite un
K bit
{Gkn }
processo pseudo-casuale, e potrebbe inviare tale chiave nellheader del pacchetto. Fintanto che la dimensione del pacchetto molto pi grande della dimensione della chiave (che deve essere solo di 32 bit), questa chiave introduce solo un piccolo overhead. In alcune applicazioni, ogni pacchetto avr gi un header per altri scopi, che il codice a fontana pu utilizzare per la sua chiave. Nel seguito si chiamer G il frammento di matrice di dimensioni K x N . A questo punto bisogna stabilire qual la probabilit di successo nella decodifica. Se N < K , allora il ricevitore non possiede abbastanza informazioni per recuperare il file. Se
Figura 10-6: Matrice generatrice di un codice lineare casuale
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.381 N = K , allora plausibile che il ricevitore possa recuperare Nel caso in cui N sia leggermente pi grande di K , ovvero il file. N = K + E con E che indica il piccolo numero di pacchetti Se la matrice G di dimensioni
K x K invertibile (modulo
G
1
in eccesso, si deve calcolare la probabilit che la matrice binaria di dimensioni K x N contenga una matrice di dimensioni
2), il ricevitore pu calcolare linversa Gaussiana, e recuperare:

sk = tnGnk1 n =1 N
per eliminazione
K x K invertibile. Tale probabilit viene
indicata con 1 , dove
la probabilit che il ricevitore
La probabilit che una matrice binaria di dimensioni
K x K
non sia in grado di decodificare il file una volta ricevuti gli E pacchetti in eccesso. Nella Figura 10-7 viene graficata la probabilit di fallimento
casuale sia invertibile il prodotto di K probabilit, ognuna delle quali la probabilit che una nuova colonna di G sia linearmente indipendente dalle precedenti colonne. Il primo fattore, 1 2
rispetto ad E per il caso in cui
K = 100 (il grafico appare identico per tutti i K > 10 ). Per qualsiasi K la probabilit di fallimento limitata
superiormente da:
) , la probabilit che la prima colonna di
( E ) 2 E
Questo limite mostrato sempre in Figura 10-7 mediante la linea tratteggiata.
G non sia composta da tutti zeri. Il secondo fattore,
(1 2
( K 1)
) , la probabilit che la seconda colonna di G
non sia composta da tutti zeri e non sia uguale alla prima colonna. Iterando, la probabilit di invertibilit diventa:
(1 2 ) * (1 2
K
(K 1)
) ** (1 1/ 8) * (1 1/ 4) * (1 1/ 2 )
che pari a 0,289 per ogni K maggiore di dieci.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.382 dellinversa ai pacchetti ricevuti, che di circa
K2 2
operazioni per pacchetto. Anche se un codice casuale non un codice perfetto in senso tecnico (infatti ha solo una probabilit di 0,289 di recuperare il file una volta arrivati K pacchetti), per il canale con cancellazione quasi perfetto. Un eccesso di
E pacchetti aumenta la probabilit di E successo ad almeno (1 ) , con = 2 . Allora,
Figura 10-7: Prestazioni della fontana lineare casuale Il numero di pacchetti necessari per avere una probabilit di successo di 1 di circa K + log 2 (1/ ) . Il costo di codifica atteso per ogni pacchetto di
allaumentare della dimensione del file K , i codici a fontana lineari casuali possono avvicinarsi in maniera arbitraria al limite di Shannon, ma i loro costi di codifica e di decodifica sono quadratici e cubici rispetto al numero di pacchetti codificati. quindi preferibile una soluzione con un costo computazionale minore.
K operazioni per 2
pacchetto, dato che in media devono essere sommati met dei pacchetti (unoperazione sul pacchetto lo XOR di due pacchetti di dimensione I bit). Il costo di decodifica atteso la somma del costo dellinversione della matrice, che di circa
K 3 operazioni binarie, e del costo dellapplicazione
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.383 10.2.3 Il codice Luby Transform Il codice Luby Transform (LT) mantiene le buone prestazioni del codice a fontana lineare casuale, ma riduce drasticamente le complessit di codifica e di decodifica. Si pu pensare al codice LT come un codice a fontana lineare casuale sparso, con un algoritmo di decodifica approssimato, ma molto economico. 10.2.3.1 Codificatore grado medio d significativamente pi piccolo di K , allora il grafo sparso. Si pu pensare al codice risultante come un codice con matrice generatrice a bassa densit irregolare. 10.2.3.2 Decodificatore
La decodifica di un codice a grafo sparso particolarmente semplice nel caso di un canale con cancellazione. Il compito del decodificatore quello di recuperare s da t = sG , dove
Ogni pacchetto codificato
tn prodotto dal file sorgente
G la matrice associata al grafo (proprio come nel codice a

fontana lineare casuale, si assume che il decodificatore conosca in qualche modo la matrice pseudo-casuale G ). Un modo semplice per tentare di risolvere questo problema tramite lalgoritmo del massage-passing, che si basa sul passaggio di informazione tra i diversi nodi del grafo. Si pu pensare a questo algoritmo come ad un algoritmo sommaprodotto, spiegato nel documento [192], dove per tutti i messaggi o sono completamente incerti oppure sono completamente certi. I messaggi incerti affermano che un che
( s1 , s2 ,,
sK ) nel modo seguente:
si scegliere in modo casuale il grado da una distribuzione di gradi appropriata di sorgente;
(d ) ;
d n del pacchetto
la scelta
dipende dalla dimensione
K del file
si scegliere, uniformemente a caso, ingresso distinti, e settare bit, modulo 2, di quei
d n pacchetti di
tn uguale alla somma bit a
d n pacchetti.
sk pu avere qualsiasi
valore, con la stessa probabilit; i messaggi certi affermano
Questa operazione di codifica definisce un grafo che connette i pacchetti codificati ai pacchetti sorgente. Se il
sk ha un particolare valore, con probabilit 1. La
semplicit di questi messaggi permette una semplice
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.384 descrizione del processo di decodifica. I pacchetti codificati conseguenza (quadro b), il nodo check viene scartato e
tn verranno chiamati nodi check.

Il processo di decodifica, il seguente:
viene sommato il valore di s1 (1) ai check a cui connesso (quadro c), disconnettendo
s1 dal grafo. Allinizio della
trovare un nodo check pacchetto sorgente
tn che connesso ad un solo
seconda iterazione (quadro c), il quarto nodo check connesso ad un unico bit sorgente, s2 . Questo viene impostato a
sk (se tale nodo non esiste, allora
lalgoritmo di decodifica si arresta a questo punto e fallisce il recupero di tutti i pacchetto sorgente): si pone sk = tn ; si somma
t4 (quadro d), e viene sommato ai due check a s3 , e concordano sul valore di s3 che
cui connesso (quadro e). Alla fine, ci sono due nodi check entrambi connessi a viene restituito nel quadro f.
sk a tutti i nodi check tn che sono connessi a sk , ovvero tn = tn + sk per tutti gli n per cui Gnk = 1 ;
rimuovere tutti gli edge connessi al pacchetto sorgente sk .
ripetere il punto 1 finch non vengono determinati tutti gli sk .
La Figura 10-8 mostra un esempio del processo di decodifica: ci sono tre pacchetti sorgente e quattro pacchetti ricevuti, che hanno i valori
t1 , t2 , t3 , t4 = 1011 allinizio
dellalgoritmo. Alla prima iterazione, il solo nodo check che connesso con ad un unico bit sorgente il primo nodo check (quadro a); questo bit sorgente
s1 viene settato di
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.385 10.2.3.3 Disegno della distribuzione dei gradi La distribuzione di probabilit
(d )
una parte critica, in
quanto pacchetti codificati occasionali devono avere un grado elevato (cio d deve essere simile a K ) per assicurare che non ci siano pacchetti sorgente non connessi. Molti pacchetti devono avere un grado basso, in modo che il processo di decodifica possa cominciare e andare avanti e in modo che il numero totale di addizioni coinvolte nella codifica e nella decodifica venga tenuto basso. Per una data distribuzione di gradi
(d ) ,
le
Figura 10-8: Decodifica per un codice a fontana con K=3 bit sorgente e N=4 bit codificati
statistiche del processo di decodifica possono essere predette da una versione appropriata dellevoluzione della densit, una tecnica sviluppata prima per i codici con controllo di parit a bassa densit, come specificato nel documento [192]. Le complessit di codifica e di decodifica scalano entrambe linearmente con il numero di edge nel grafo, quindi la quantit cruciale il grado medio dei pacchetti. Si possono pensare gli edge come alle palle e i pacchetti sorgente come ai contenitori. Affinch la decodifica abbia successo, ogni pacchetto sorgente deve avere sicuramente almeno un edge in esso. Il codificatore mette gli edge in pacchetti sorgente a caso, cos il numero di edge deve essere almeno
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.386 Questa distribuzione di gradi in pratica non funziona bene, in dellordine di Klog e K . Se il numero di pacchetti ricevuti quanto le fluttuazioni intorno al comportamento atteso fanno vicino al K ottimo di Shannon, e se la decodifica s che ad un certo punto nel processo di decodifica non ci possibile, allora il grado medio di ogni pacchetto deve saranno nodi check di grado unitario, e inoltre alcuni nodi essere almeno log e K , e le complessit di codifica e di sorgente non riceveranno connessioni. Per risolvere questi problemi serve una piccola modifica. decodifica di un codice LT saranno certamente almeno La distribuzione solitona robusta ha due parametri extra, c Klog K . stato dimostrato che questo limite sulle
e
complessit pu essere ottenuto tramite unattenta scelta della distribuzione dei gradi. Idealmente, per evitare ridondanza, bene che il grafo ricevuto possieda la propriet che ad ogni iterazione solo un nodo check abbia grado 1. Ad ogni iterazione, quando il nodo check in questione viene processato, i gradi nel grafo vengono ridotti in modo che appaia un nuovo nodo check di grado 1. Questo comportamento ideale ottenuto per mezzo della distribuzione solitona ideale:
e , ed disegnata in modo da assicurare che il numero atteso di check con grado 1 sia circa:
K S clog e ( ) K
piuttosto che 1, dallinizio alla fine del processo di decodifica. il parametro
un limite sulla probabilit che la decodifica

'
(1) = 1/ K
(d ) =
1 d ( d 1)
per d = 2, 3, , K
fallisca dopo la ricezione di un certo numero di pacchetti K . Il parametro c una costante di ordine 1, se lo scopo quello di dimostrare il teorema principale di Luby sui codici LT; in pratica, tale costante pu essere vista come un parametro libero, che d buoni risultati con un valore un po pi piccolo di 1. Si definisce una funzione positiva:
Il grado atteso nel caso di questa distribuzione circa
log e K .
K s 1 per d = 1, 2,..., 1 K d S S K s (d ) = log( ) per d = S K K per d > 0 S

rappresentata in Figura 10-9, a cui viene sommata la distribuzione solitona ideale , e poi si normalizza per ottenere la distribuzione solitona robusta,
:
Figura 10-9: Le distribuzioni (d) e (d) per il caso K=10000, c=0:2, =0,05 che d S=244, K/S=244 e Z=1,3 Lanalisi di Luby, riportata in [189], spiega come il piccolo d alla fine di abbia il ruolo di assicurare che il processo di decodifica inizi, e il picco in per d = K / S viene incluso per assicurare che ogni pacchetto sorgente sia connesso ad un check almeno una volta. Il risultato chiave che, per un valore appropriato della costante c , la ricezione di
( ) = ( ( ) + ( )) / Z
dove Z = d ( d ) + ( d ) . Il numero di pacchetti codificati richiesto al lato ricevitore per assicurare che la decodifica giunga a conclusione, con probabilit almeno (1 ) ,
K = KZ .
K = K + 2log e ( S / ) S check assicura che tutti i pacchetti

possono essere recuperati almeno con una probabilit di
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.388 In pratica, i codici LT possono essere regolati in modo che 1 . Nella Figura 10-10, la probabilit di fallimento un file di dimensione originale K 10000 pacchetti venga ammissibile al decodificatore stata settata abbastanza recuperato con un overhead di circa il 5%. La Figura 10-11 grande, poich la probabilit di fallimento reale molto pi mostra gli istogrammi del numero di pacchetti richiesto per piccola di quella suggerita dallanalisi conservativa. una coppia di impostazioni dei parametri, ottenendo overhead medi inferiori al 5% e al 10% rispettivamente.
Figura 10-11: Istogrammi del numero di pacchetti N necessario per recuperare un file di dimensione K=10000 pacchetti Figura 10-10: Il numero dei check di grado unitario S(a) e la quantit K(b) rispetto ai due parametri c e , per K=10000
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.389 La Figura 10-12 mostra la linea dei tempi di tre decodifiche. 10.2.4 I codici Raptor una caratteristica di un buon codice LT che sia possibile una decodifica molto piccola finch non siano stati ricevuti I codici Raptor sono stati disegnati e ottimizzati per la poco pi di K pacchetti, momento in cui ha luogo una flessibilit, la bassa complessit e la potente protezione cascata di decodifica. dalle cancellature. Questi codici possono generare tanti simboli codificati da un blocco sorgente quanti sono necessari per contrastare gli effetti della perdita dei pacchetti. In alternativa possono generare pochi simboli codificati in modo da limitare la quantit di espansione di banda o il tempo addizionale di trasmissione continuando comunque a fornire un livello di protezione adeguato contro la perdita dei pacchetti. I codici Raptor riescono a migliorare le prestazioni dei codici LT, ottenendo dei tempi di codifica e di decodifica lineari, mediante la concatenazione di un codice LT indebolito e di un codice esterno che aggiusta i gap nel codice LT. Lidea della codifica Raptor, come spiegata nel documento [191], quella di rilassare le condizioni dei codici LT; viene Figura 10-12: Prestazioni pratiche dei codici LT richiesto infatti che solo una frazione costante dei simboli di ingresso sia recuperabile. I codici Raptor usano un codice LT con un grado medio d circa pari a 3. Con questo grado medio pi basso, il decodificatore pu lavorare nel senso che non si blocca, ma una frazione dei pacchetti sorgente non sar connessa al grafo e quindi non sar recuperata. La
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.390 frazione attesa non recuperata
% f = e d che per d = 3
il 5%. Inoltre, se K grande, la legge dei grandi numeri assicura che la frazione di pacchetti non recuperata in una
% particolare realizzazione sar molto vicina ad f . Quindi,

lespediente studiato da Shokrollahi quello di trasmettere
% un file di K pacchetti, precodificandolo prima in K
K % 1 f
pacchetti con un codice esterno eccellente che pu correggere le cancellazioni se il tasso di cancellazione
% esattamente f , e poi trasmettendo questo file leggermente

pi grande usando un codice LT debole. Questultimo codice, una volta ricevuti poco pi di K pacchetti, pu Figura 10-13: Diagramma schematico di un codice Raptor Esistono diversi tipi di codici Raptor che si differenziano per il codice esterno utilizzato e per la distribuzione dei gradi del codice LT; ma principalmente i codici Raptor si dividono in due grandi gruppi: i codici Raptor sistematici e non sistematici. I primi consentono di includere nei dati trasmessi i dati sorgente. Nell'approccio non-sistematico, in ingresso al codificatore LT vengono posti non i simboli sorgente, ma dei simboli intermedi generati tramite un codice esterno che effettua la pre-codifica.
% % recuperare (1 f ) K dei pacchetti precodificato, che sono

circa K pacchetti, e poi viene usato il codice esterno per recuperare il file originale. La Figura 10-13 illustra un diagramma schematico per un codice Raptor.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.391 su sui opera lalgoritmo DF Raptor. La dimensione dei Il codice Raptor per sua natura non-sistematico, simboli sorgente viene scelta in maniera tale che ogni necessario quindi trovare un meccanismo che consenta di simbolo sorgente sia mappato in un pacchetto di dati trasformare il codice Raptor non-sistematico in un codice completo o in una certa frazione di un pacchetto quando sistematico. Questo meccanismo consiste in un'appropriata viene trasmesso. Poi il codificatore DF Raptor processa un funzione di corrispondenza tra parole d'informazione e blocco di simboli sorgente (per esempio un completo file di parole di codice, in maniera tale che le prime K parole di dati da trasmettere o un blocco di uno stream continuo di codice corrispondano ai primi simboli sorgente. Quindi dati) in un blocco di simboli di uscita codificati pi grande nell'approccio sistematico si applica un ulteriore predella lunghezza che pi si preferisce. Ogni simbolo processamento ai simboli d'ingresso, e loutput di questo codificato ha la stessa dimensione di un simbolo sorgente pre-processamento diviene linput del codificatore Raptor ed determinato dallo XOR bit a bit di un numero di simboli non-sistematico. La differenza fondamentale tra codice sorgente secondo lalgoritmo DF Raptor. Ogni simbolo sistematico e non sistematico sta quindi, non nella struttura codificato viene generato indipendentemente dagli altri e del codice stesso, ma nel pre-processamento che viene non esiste un limite al numero di simboli codificati che effettuato sui simboli d'ingresso per ottenere la sistematicit possono essere generati da un dato blocco sorgente. I del codice. simboli di uscita generati vengono poi pacchettizzati come 10.2.4.1 Implementazione dei codici Raptor necessario per la trasmissione sulla rete. A lato ricevitore, possono non essere ricevuti tutti i simboli codificati a causa Lex Digital Fountain (ora acquisita da Qualcomm) ha di pacchetti persi o corrotti. Per, finch vengono ricevuti realizzato unimplementazione efficiente dei codici Raptor, la con successo abbastanza simboli codificati, il decodificatore cui teoria stata illustrata nel paragrafo precedente. Raptor pu recuperare i simboli sorgente originali. Il numero Lalgoritmo usato dalla Digital Fountain (DF) prende il nome di simboli codificati che devono essere ricevuti con successo di DF Raptor. per poter recuperare interamente i dati solo leggermente I dati da codificare vengono prima divisi in elementi di pi grande del numero dei simboli sorgente nel blocco dimensione fissa (simboli sorgente) che sono unit atomiche sorgente. Non fa alcuna differenza per lalgoritmo di
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.392 che legano ogni simbolo codificato con i simboli sorgente da decodifica DF Raptor quali simboli codificati specifici cui viene ottenuto mediante lo XOR. vengano ricevuti o in quale ordine arrivino, ma ogni simbolo Il processo di decodifica semplicemente lopposto: dato un codificato ricevuto pu essere usato per recuperare i dati numero adeguato di simboli codificati ricevuti e avendo originali. conoscenza degli XOR usati per crearli, vengono ricavati tutti i simboli sorgente.
Figura 10-14: il DF Raptor codifica un blocco di k simboli sorgente come n simboli codificati (con n maggiore di k) al fine di proteggere i simboli sorgente dalle perdite Il processo di codifica DF Raptor semplicemente un algoritmo per costruire nuovi simboli codificati calcolando lo XOR bit a bit di simboli sorgente specifici. Il processo di codifica pu essere visto come un grafo con connessioni
Figura 10-15: I Raptor DF impiegano un codice a fontana LT per generare un illimitato numero di simboli codificati dai simboli sorgente Una componente centrale del DF Raptor un codice LT. Ogni simbolo codificato LT viene generato a caso e in modo indipendente come lo XOR di un particolare sottoinsieme di simboli sorgente. Il grado di ogni simbolo codificato LT il numero di simboli sorgente usati per generarlo, e la chiave
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.393 La complessit di codifica e di decodifica di un codice LT dellalgoritmo LT luso di una distribuzione di probabilit direttamente legata alla distribuzione dei gradi. Pi piccolo per controllare il grado di ogni simbolo codificato. il grado medio, meno operazioni XOR devono essere Ogni simbolo codificato viene generato secondo il seguente eseguite nel calcolare ogni simbolo codificato, e pi semplici algoritmo: diventano le elaborazioni di codifica e di decodifica. Allo viene scelto un grado specifico d a caso, secondo la stesso tempo, la distribuzione dei gradi deve permettere al distribuzione dei gradi; processo di decodifica di recuperare completamente lintero dato il grado d , i d simboli sorgente specifici blocco sorgente con un numero di simboli codificati ricevuti vengono scelti a caso secondo una distribuzione uniforme; solo leggermente pi grande del numero totale di simboli sorgente. Sono state determinate distribuzioni di gradi per il valore del simbolo codificato quindi la somma XOR bit a bit dei simboli sorgente selezionati. codici LT con buone prestazioni, ma la complessit Ogni simbolo codificato LT viene poi trasmesso insieme risultante non lineare rispetto al numero di simboli allinformazione per il ricevitore che indica il grado e i simboli sorgente. sorgente selezionati (per esempio, linformazione pu Per ottenere una complessit lineare, il DF Raptor codifica in rappresentare il seme usato da un comune generatore di due passi: numeri pseudo-casuali). Quindi il decodificatore a allinizio, un algoritmo di precodifica a bassa conoscenza dei d simboli sorgente specifici utilizzati per complessit viene applicato al blocco di ingresso dei generare ogni simbolo codificato, sebbene i valori dei simboli sorgente per creare un blocco precodificato; simboli sorgente non siano noti finch non completa la poi viene applicato un codice LT sul blocco decodifica. precodificato per generare un numero illimitato di simboli codificati. Dato che ogni simbolo codificato viene generato indipendentemente e a caso usando la stessa distribuzione dei gradi, tutti i simboli codificati ricevuti sono ugualmente importanti per recuperare i simboli sorgente.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.394 sorgente di essere recuperato completamente usando un numero di simboli codificati ricevuti solo leggermente pi grande del numero totale di simboli sorgente. 10.2.5 Applicazioni I codici a fontana rappresentano delle soluzioni eccellenti in molte situazioni, come ad esempio la memorizzazione di dati e il broadcast. 10.2.5.1 Immagazzinamento dei dati
Figura 10-16: I due passi della codifica DF Raptor La decodifica implica, come detto in precedenza, le operazioni inverse: lutilizzo dei simboli codificati ricevuti per recuperare i simboli precodificati e lutilizzo di questi simboli per recuperare il blocco sorgente. Il codice LT impiegato nel DF Raptor usa una distribuzione dei gradi che fornisce una bassa complessit a spese della protezione dalle perdite. Anche se il codice LT pu non permettere il recupero completo dei simboli precodificati al decodificatore, lalgoritmo di precodifica pu operare su qualunque simbolo precodificato sia stato recuperato per poter recuperare completamente il blocco sorgente. Le prestazioni dei codici DF Raptor sono state ottimizzate mediante un disegno attento dellalgoritmo di precodifica e della distribuzione dei gradi usata nel codice LT. Il DF Raptor ha complessit di codifica e di decodifica lineari con la dimensione del blocco sorgente e permette al blocco
Si supponga di voler eseguire il back-up di un file grande su nastri magnetici e hard drive inaffidabili, con un tasso di guasti catastrofici (in cui vengono persi permanentemente alcuni pacchetti memorizzati in un dispositivo) di circa 10-3 per giorno. Un codice a fontana pu essere utilizzato per diffondere i pacchetti codificati in tutti i dispositivi di immagazzinamento disponibili. Per recuperare il file, di dimensione K pacchetti, bisogna semplicemente trovare
K K pacchetti da qualsiasi dispositivo. I pacchetti

corrotti non devono preoccupare, in quanto vengono saltati per trovare pi pacchetti altrove. Questo metodo di immagazzinamento presenta vantaggi anche in termini di velocit di recupero di un file. In genere un file viene immagazzinato in settori successivi di un hard
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.395 drive, per consentirne una letture rapida, ma se come che f = 0.1% dei pacchetti venga perso in ogni casa. In un succede occasionalmente viene perso un pacchetto approccio standard in cui il file viene trasmesso come una (essendo la parte iniziale che deve essere letta fuori traccia sequenza piana di pacchetti senza codifica, ogni casa per un momento, provocando un burst di errori che non pu dovrebbe inviare al broadcaster notifiche dei fK pacchetti essere corretto dal codice a correzione derrore), allora deve mancanti e richiederne la ritrasmissione. Con 10000 utenti, essere eseguita unintera rotazione dellhard drive per tutti richiedenti queste ritrasmissioni, ci sarebbe una riportare il pacchetto allinizio per una seconda lettura. Il richiesta di ritrasmissione per quasi tutti i pacchetti. Cos il tempo impiegato per una rotazione produce un fastidioso broadcaster dovrebbe ripetere lintero broadcast due volte ritardo nel file system. Al contrario, se i file venissero per assicurare che la maggior parte degli utenti abbia memorizzati con il principio a fontana, con le gocce digitali ricevuto lintero film, e tali utenti dovrebbero aspettare circa immagazzinati in uno o pi settori consecutivi sul drive, due volte il tempo ideale prima che il download sia completo. allora non si dovrebbe mai sopportare il ritardo della rilettura Se il broadcaster usasse un codice a fontana per codificare di un pacchetto; la perdita di un pacchetto diventerebbe il film, allora ogni utente potrebbe recuperare il film da meno importante e, di conseguenza, lhard drive potrebbe K K pacchetti qualsiasi. In questo modo il broadcast essere gestito pi velocemente, con livelli di rumore pi deve durare per soli 1.1K pacchetti circa, ed ogni casa pu elevati e con meno risorse dedicate alla codifica di canale recuperare con successo lintero file. rumoroso. Unaltra applicazione il broadcast di dati verso le 10.2.5.2 Broadcast macchine. Per esempio, si pu pensare di inviare via satellite gli aggiornamenti ai database dei navigatori. Ci sono Si consideri il caso in cui 10000 sottoscriventi in unarea centinaia di migliaia di veicoli, che possono ricevere i dati vogliano ricevere una film digitale da un broadcaster. Il solamente quando si trovano in strade allaperto; non broadcaster pu inviare il film in pacchetti su una rete esistono canali di feedback. Un metodo standard per inviare broadcast, per esempio per mezzo di una linea telefonica a i dati quello di metterli in un carosello, facendo il broadcast larga banda, oppure per mezzo del satellite. Si supponga dei pacchetti in una sequenza periodica fissa. Se una
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.396 macchina si trova in un tunnel e perde alcune centinaia di pacchetti, sar comunque in grado di recuperarli lora 10.3 AL-FEC: lapproccio DVB successiva quando il carosello ricominciato, oppure li potr Il documento [18] definisce un protocollo opzionale che recuperare il giorno successivo. Se invece il satellite usasse prevede luso di Forward Error Correction a livello un codice a fontana, ogni macchina dovrebbe ricevere solo applicativo (AL-FEC) per lo streaming nellambito di servizi una quantit di dati pari alla dimensione del file originale, pi DVB-IP trasportati su RTP. LAL-FEC un protocollo a strati un 5%. basato sulla combinazione dei seguenti codici FEC:
un semplice codice di parit interallacciato basato sui pacchetti, equivalente a un sottoinsieme del codice definito nella specifica [61];
il codice Raptor, definito nel documento [62] e nel documento [64]. Il codice descritto nella specifica [61] applicabile solamente al caso di media trasportati allinterno di un singolo flusso RTP. In questo caso i FEC packet possono essere trasmessi in uno o pi livelli, con il primo livello che contiene i pacchetti generati dal codice di parit interallacciato e gli altri livelli opzionali che contengono i pacchetti generati dal codice Raptor. I ricevitori elaborano solo i pacchetti del livello o dei livelli che supportano. Una propriet chiave del codice definito in questa specifica la possibilit del supporto simultaneo di pi livelli e i FEC packet derivanti da questi livelli possono essere combinati al ricevitore per ottenere prestazioni di correzione derrore migliori rispetto a quelle ottenibili da un singolo livello.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.397 trasferimento di contenuti, mentre le specifiche per i FEC Nel seguito verranno definiti il primo livello, i livelli seguenti, Scheme definiscono i codici FEC veri e propri. Il Building alcune procedure di decodifica ibrida e, infine, dei protocolli Block FEC descrive le regole che entrambe le tipologie di FEC completi per video multicast e unicast, sia con specifiche devono seguire, in modo da poter essere lincapsulamento nel TS MPEG-2, sia con il trasporto diretto utilizzate congiuntamente, fornendo quindi il collante tra i di audio e video su RTP. protocolli Content Delivery e i FEC Scheme. 10.3.1 Codice basato sulla specifica SMPTE La specifica organizzata in componenti modulari che 2022-1 vengono poi combinati per formare i protocolli completi, per i servizi DVB-IP. Questi componenti modulari includono un La codifica basata sulla specifica [61] pu essere applicata FEC Streaming Framework e un certo numero di schemi agli stream che soddisfano i relativi requisiti che sono quelli FEC. Il FEC Streaming Framework equivalente a quello delle specifiche SMPTE 2022-1 e 2022-2, con alcune definito nel documento [62], che fornisce un framework per modifiche ed eccezioni. un protocollo globale per lapplicazione del FEC ai media stream. Gli schemi FEC descritti definiscono sia i 10.3.2 Codice Raptor componenti del protocollo secondo il Building Block FEC La specifica [150], definita dal gruppo di lavoro Reliable dellIETF, per diverse classi di applicazioni, sia la modalit in Multicast dellIETF, descrive un approccio alla specifica di cui il codice FEC Raptor viene applicato per le applicazioni protocolli che usano il FEC operando una separazione tra la di streaming. definizione del protocollo e la specifica del codice FEC stesso. A tal proposito, nellambito del cosiddetto Building Block FEC, che si occupa della protezione mediante FEC dei flussi dati trasmessi in streaming, vengono fornite specifiche separate per i Content Delivery Protocol (CDP) e per i FEC Scheme. Le specifiche per i Content Delivery Protocol definiscono i protocolli di comunicazione per il 10.3.3 FEC Streaming Framework Si definisce un framework per la definizione dei CDP, nel senso del Building Block FEC, il quale si occupa della protezione FEC dei flussi dati trasmessi in streaming su UDP. Non viene definito un CDP completo, piuttosto
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.398 vengono descritti solo gli aspetti comuni a tutti i protocolli Content Delivery che supportino lo streaming di dati su UDP. Il framework definito non specifico per un singolo protocollo di streaming, e fornisce protezione FEC per i flussi dei protocolli applicativi su UDP e per la protezione combinata di pi flussi. Per esempio, pi flussi RTP possono essere protetti insieme ai flussi RTCP associati e potenzialmente insieme anche ad altri flussi collegati, come i pacchetti dei protocolli di sicurezza. I protocolli Content Delivery che usano questo framework devono provvedere alla comunicazione di due tipi di informazione dal mittente al ricevente:
linformazione FEC Streaming Configuration, che dipende dello schema FEC utilizzato, richiesta dal FEC Streaming Framework, ad esempio per la definizione dei flussi UDP che sono protetti dal FEC Streaming Framework. I mezzi per trasportare linformazione FEC Streaming Configuration devono essere definiti da ogni protocollo Content Delivery.
Figura 10-17: Architettura del FEC Streaming Framework 10.3.3.1 La procedura
Il meccanismo definito consta di tre passi:
linformazione FEC Object Transmission, informazione specifica per un particolare schema FEC e definita da ogni schema FEC. I protocolli Content Delivery devono definire un mezzo per trasportare questa informazione dal mittente al ricevente. La Figura 10-17 schematizza larchitettura precedentemente delineata.
costruzione di un blocco sorgente a partire dai media packet che appartengono a uno o pi flussi UDP. Il flusso UDP pu includere, per esempio, pacchetti RTP e RTCP e anche altri protocolli connessi allo stream; generazione di FEC packet source inserendo nei media packet unestensione opzionale per indicare il
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.399 Dal lato mittente previsto quindi un meccanismo che blocco sorgente e la posizione allinterno del blocco sorgente occupata dai dati relativi al media packet; elabora i pacchetti UDP originali per creare: generazione dei pacchetti FEC repair, trasmessi su una copia dei pacchetti originali nella forma di uno o UDP, che possono essere usati dal decodificatore pi blocchi sorgente. Il blocco sorgente un blocco FEC per ricostruire le porzioni mancanti del blocco logico di dati al quale verr applicato il codice FEC e sorgente. viene costruito concatenando la Source Packet I dati protetti possono provenire da diversi flussi UDP protetti Information (SPI) per ogni media packet. collettivamente. In generale, verranno costruiti pi blocchi Generalmente, lSPI di un pacchetto contiene un sorgente per uno stream, ognuno dei quali viene costruito a breve identificatore del flusso a cui appartiene il pacchetto UDP flow ID, un indicatore della partire da insiemi diversi di media packet. Per esempio, un lunghezza del pacchetto, il payload UDP e possibili blocco sorgente pu essere costruito da quei media packet byte di padding; relativi a un particolare segmento temporale dello stream. i pacchetti FEC source per la trasmissione al Un ricevitore che supporta questo framework per lo ricevitore. streaming deve supportare sia il formato dei pacchetti FEC Il FEC Streaming Framework usa il codificatore FEC source sia quello dei pacchetti FEC repair. specifico dello schema FEC in uso, per generare la quantit Non si definisce come il mittente determini quali pacchetti voluta di simboli repair da un blocco sorgente. Questi simboli sorgente debbano essere inclusi in determinati blocchi repair vengono poi inviati al ricevitore usando il formato dei sorgente. Tale corrispondenza pu essere definita da un pacchetti FEC repair. CDP specifico, oppure pu essere lasciata al mittente e I pacchetti FEC repair vengono inviati a loro volta ad una dipendere dallimplementazione seppur con alcuni vincoli porta di destinazione UDP diversa da qualunque porta di sulla memoria del ricevitore. Tuttavia, un CDP specifico destinazione dei pacchetti UDP originali, come indicato deve definire la modalit con cui un mittente comunica al dellinformazione FEC Streaming Configuration. ricevente il massimo intervallo di tempo che il mittente Il ricevitore recupera i media packet originali direttamente da lascer tra un pacchetto FEC source e il relativo pacchetto qualsiasi pacchetto FEC source ricevuto. Il ricevitore usa FEC repair. anche i pacchetti FEC source ricevuti per costruire una
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.400 FEC Packet Identification viene derivata dagli altri campi copia dei media packet nello stesso formato del blocco allinterno del pacchetto sorgente. sorgente costruito dal mittente. Se viene perso un qualsiasi media packet relativo a un certo Il ricevitore dei pacchetti FEC repair deve anche essere in blocco sorgente, allora la copia del blocco sorgente al grado di identificare il blocco sorgente e la relazione tra i dati ricevitore sar incompleta. Se viene ricevuta una quantit repair contenuti e il blocco sorgente originario. Questa sufficiente di pacchetti FEC source e FEC repair relativi a informazione nota come informazione FEC Repair Packet quel blocco sorgente, allora il framework FEC pu usare Identification e deve essere codificata in un campo specifico lalgoritmo di decodifica FEC definito dallo schema FEC per dei pacchetti FEC repair, il campo Repair FEC Payload ID recuperare una copia integra del blocco sorgente. Lo SPI dei (cfr. Figura 10-19), i cui contenuti e il cui formato vengono pacchetti sorgente mancanti pu essere estratto dalle parti definiti dallo schema FEC. Gli schemi FEC possibili in completate del blocco sorgente e usato per ricostruire i questo framework devono essere sistematici e devono pacchetti sorgente da passare allapplicazione. basarsi sui blocchi sorgente. Lo schema FEC pu definire diversi formati del campo FEC Payload ID per i pacchetti Il ricevitore dei pacchetti FEC source deve essere in grado FEC source e FEC repair. di identificare il blocco sorgente e la posizione allinterno del blocco sorgente a partire dalla SPI derivata da ogni 10.3.3.2 Il protocollo pacchetto. Questa informazione nota come informazione Source FEC Packet Identification e pu essere inviata dal In questo paragrafo vengono specificati gli elementi del trasmettitore in vari modi., Tipicamente pu essere protocollo per il FEC Streaming Framework. Il protocollo codificata in un campo specifico allinterno del formato del consta di tre passi, che vengono descritti nelle sezioni pacchetto FEC source, chiamato campo Source FEC seguenti: Payload ID (cfr. Figura 10-18). I contenuti esatti e il formato costruzione di un blocco sorgente dai pacchetti del campo Source FEC Payload ID vengono definiti dallo sorgente. Il codice FEC verr applicato a questo schema FEC. In alternativa, lo schema FEC o il CDP blocco sorgente per produrre i dati repair; possono definire la modalit con cui linformazione Source
un formato per i pacchetti contenenti i dati source.
un formato per i pacchetti contenenti i dati repair. Il funzionamento del FEC Streaming Framework controllato da informazioni FEC Streaming Configuration. Una specifica di protocollo completa che usa questo framework deve specificare i mezzi per determinare e comunicare questa informazione tra il mittente e il ricevente. Struttura del Source Block Questa sezione definisce la struttura del blocco sorgente. Un blocco sorgente consiste nella concatenazione di SPI per almeno un pacchetto UDP sorgente originale. Indichiamo con:
L[i]: denota due ottetti che rappresentano il valore di l(i) nellordinamento in byte della rete (prima lottetto di ordine maggiore) del pacchetto UDP i-esimo. f[i]: denota un UDP flow ID intero che identifica il flusso UDP da cui stato preso li-esimo pacchetto. F[i]: denota un singolo ottetto che rappresenta il valore di f[i]. s[i]: il pi piccolo intero tale che s[i] x T (l[i] + 3); da notare che s[i] la lunghezza di SPI[i] in unit di simboli di dimensione T. P[i]: denota s[i] x T (l[i] + 3) ottetti pari a zero; questi sono ottetti di padding che servono ad allineare linizio di ogni pacchetto UDP con linizio di un simbolo.
n: numero di pacchetti UDP nel blocco sorgente; pu essere determinato dinamicamente durante il processo di costruzione del blocco sorgente. T: dimensione dei simboli sorgente in byte; questa informazione viene fornita dallo schema FEC. i: indice al pacchetto UDP (i+1)-esimo da aggiungere al blocco sorgente, con 0in. R[i]: denota il numero di ottetti del payload UDP del pacchetto UDP i-esimo. l[i]: indicazione di lunghezza associata al pacchetto UDP i-esimo; la natura dellindicazione di lunghezza definita dallo schema FEC.
SPI[i]: la concatenazione di F[i], L[i], R[i] e P[i]. Il blocco sorgente viene costruito concatenando gli SPI[i] per i = 0, 1, 2,, n-1. la dimensione del blocco sorgente, S, quindi data dalla somma {s[i] x T, i = 0,, n-1}. I blocchi sorgente sono identificati da Source Block Number interi e i simboli allinterno di un blocco sorgente sono identificati da Encoding Symbol ID interi. I simboli sono numerati consecutivamente a partire da zero allinterno del blocco sorgente. Ad ogni media packet associato lEncoding Symbol ID del primo simbolo che contiene lo SPI di quel pacchetto. Cos il valore dellEncoding Symbol ID associato al j-esimo media packet, ESI[j], dato da:
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.402 ESI[j] = 0, per j = 0 ESI[j] = sum{s[i], i = 0,, j-1}, per 0<j<n. Linformazione Source FEC Packet Identification composta dallidentit del blocco sorgente e dallEncoding Symbol ID associato al pacchetto. Un flusso UDP definito univocamente da un indirizzo IP di sorgente e di destinazione e da valori di porte UDP di sorgente e di destinazione. Lassegnazione dei valori UDP flow ID ai flussi UDP fa parte dellinformazione FEC Streaming Configuration. Formato del pacchetto per i pacchetti FEC source Il formato del pacchetto per i pacchetti FEC source deve essere usato per trasportare il payload di un pacchetto UDP sorgente originale. La Figura 10-18 mostra la struttura dei pacchetti FEC source, formata dal pacchetto UDP originale seguito, opzionalmente, dal campo Source FEC Payload ID.
Figura 10-18: Struttura dei pacchetti FEC source I campi di header IP e UDP devono essere identici a quelli del media packet originale. Il campo Original UDP Payload deve essere identico al payload UDP del media packet originale. Il payload UDP del pacchetto FEC source deve essere formato dal campo Original UDP Payload, seguito dal campo Source FEC Payload ID. Il campo Source FEC Payload ID, se presente, contiene linformazione richiesta per il funzionamento dellalgoritmo FEC, in particolare per la derivazione dellinformazione Source FEC Packet Identification. Il formato del Source FEC Payload ID e la derivazione dellinformazione Source FEC Packet Identification vengono definiti dallo schema FEC. Lo schema FEC o il CDP possono definire i mezzi per derivare linformazione Source FEC Packet Identification dalle altre informazioni nel media packet (per esempio dal numero RTP Sequence). In questo caso, il campo Source FEC Payload
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.403 allinterno di un pacchetto pu essere determinato dalla ID non viene appeso al pacchetto e il pacchetto FEC source lunghezza del simbolo e dalla lunghezza del pacchetto. Nei identico al media packet originale. pacchetti FEC repair non devono essere inclusi simboli repair parziali. Formato del pacchetto per i pacchetti FEC repair La Figura 10-19 mostra il formato del pacchetto FEC repair. Informazione FEC Streaming Configuration Linformazione FEC Streaming Configuration uninformazione di cui il FEC Streaming Framework necessita per poter applicare la protezione FEC ai flussi UDP. Una specifica CDP completa per lo streaming che usi il framework qui specificato deve includere i dettagli su come questa informazione venga derivata e comunicata tra il mittente e il ricevente. Figura 10-19: Formato dei pacchetti FEC repair Linformazione FEC Streaming Configuration include lidentificazione di un numero di flussi di pacchetti UDP. Ogni Il payload UDP formato da un campo Repair FEC Payload flusso di pacchetti UDP unicamente identificato dalla ID e da uno o pi simboli repair generati dal processo di seguente tupla: codifica FEC. {Source IP Address, Destination IP Address, Source UDP Il campo Repair FEC Payload ID contiene linformazione Port, Destination UDP Port}. necessaria per il funzionamento dellalgoritmo FEC. Tale informazione viene definita dallo schema FEC, cos come il Una singola istanza del FEC Streaming Framework fornisce formato del campo Repair FEC Payload ID. protezione FEC per tutti i pacchetti di un insieme specificato Qualsiasi numero di simboli repair interi pu essere di flussi di pacchetti UDP, per mezzo di uno o pi flussi di contenuto allinterno di un pacchetto FEC repair, soggetto a pacchetti UDP contenenti pacchetti repair. Linformazione restrizioni nella dimensione del pacchetto o altre restrizioni FEC Streaming Configuration include: definite dallo schema FEC. Il numero di simboli repair
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.404 pacchetti nel flusso FEC repair devono essere pacchetti per ogni istanza del FEC Streaming Framework: FEC repair come specificato nella descrizione del formato lidentificazione del flusso o dei flussi di pacchetti del pacchetto per i pacchetti FEC repair nel 10.3.3.2 e UDP che trasportano i pacchetti FEC repair, noti come flussi FEC repair; devono riferirsi alla stessa istanza FEC Streaming per ogni flusso di pacchetti UDP sorgente protetti dai Framework. flussi FEC repair: Il FEC Streaming Framework deve essere informato della lidentificazione del flusso UDP di pacchetti che dimensione dei simboli da usare per ogni blocco sorgente. trasporta i media packet; Tale informazione pu essere inclusa nellinformazione FEC un identificatore intero, compreso tra 0 e 255, per il Streaming Configuration o pu essere comunicata in altri flusso precedente. Questo identificatore deve modi, per esempio allinterno del campo FEC Repair essere unico tra tutti i flussi di pacchetti UDP protetti Payload ID una specifica Content Delivery Protocol dallo stesso flusso FEC Repair; completa deve specificare come questa informazione venga lo schema FEC che deve essere applicato. Al mittente o al ricevente possono essere presenti pi comunicata tra il mittente e il ricevente. istanze del FEC Streaming Framework, con informazioni FEC Streaming Configuration separate e indipendenti. Una Requisiti per lo schema FEC singola istanza del FEC Streaming Framework protegge tutti Per poter essere usato con questo framework, uno schema i pacchetti di tutti i flussi di pacchetti UDP prima specificati, FEC deve: cio tutti i pacchetti su quei flussi devono essere pacchetti aderire ai requisiti della specifica [150]; FEC source, come specificato nella descrizione del formato essere sistematico; del pacchetto per i pacchetti FEC source nel 10.3.3.2. Un basarsi su blocchi sorgente che non si singolo flusso di pacchetti UDP non deve essere protetto da sovrappongono e contigui allinterno dello stream; pi di una istanza FEC-SF. specificare come il Source Block Number e lEncoding Un singolo flusso FEC Repair fornisce pacchetti repair per Symbol ID associati a un pacchetto sorgente vengano una singola istanza del FEC-SF. Altri pacchetti non devono derivati o comunicati dal mittente al ricevente (per essere trasmessi allinterno di questo flusso, cio tutti i
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.405 esempio, allinterno del campo Source FEC Payload Maximum Source Block Length: numero intero non ID); negativo minore di 216, in unit di simboli;
specificare come la lunghezza dei simboli venga derivata o comunicata dal mittente al ricevente (per esempio, come parte dellinformazione FEC Object Transmission);
specificare come lindicazione di lunghezza, l[i], inclusa nellinformazione Source Packet, venga derivata da un pacchetto UDP; specificare come la lunghezza dellinformazione Source Packet, s[i], venga derivata da un pacchetto UDP. 10.3.4 Gli schemi FEC per lo streaming In questo paragrafo vengono descritti degli schemi FEC Raptor per la protezione sia per flussi di pacchetti arbitrari, sia per un singolo flusso di pacchetti ordinati in sequenza. 10.3.4.1 Schemi FEC Raptor per flussi di pacchetti arbitrari Questa sezione definisce uno schema FEC Raptor per la protezione di flussi di pacchetti arbitrari su UDP. Formati e codici Gli elementi dellinformazione FEC Object Transmission per questo schema FEC e i loro range di valori sono i seguenti:
Encoding Symbol Size: numero intero non negativo minore di 216, in unit di byte. La Figura 10-20 mostra un formato di codifica per questa informazione in un campo di 4 byte:
Figura 10-20: Informazione FEC Object Transmission comune codificata per lo schema FEC Raptor per flussi di pacchetti arbitrari Il Source FEC Payload ID composto dai campi seguenti:
Source Block Number (SBN): identificatore intero di 16 bit per il blocco sorgente cui si riferiscono i dati sorgente allinterno del pacchetto;
Encoding Symbol ID (ESI): indice di 16 bit del simbolo di partenza del pacchetto sorgente nel blocco sorgente. Linterpretazione dellESI viene definita dal FEC Streaming Framework. La Figura 10-21 mostra il formato del Source FEC Payload ID.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.406 Procedure Questo schema FEC usa le procedure del framework definito nel 10.3.3.1, per costruire un blocco sorgente su cui applicare il codice FEC. Il mittente deve allocare i Source Figura 10-21: Formato del Source FEC Payload ID per lo schema FEC Raptor per flussi di pacchetti arbitrari Block Number ai blocchi sorgente in modo sequenziale, tornando a zero dopo lSBN 216-1. Il Repair FEC Payload ID composto dai seguenti campi: Durante la costruzione del blocco sorgente: Source Block Number (SBN): identificatore intero di lindicazione di lunghezza, l[i], inclusa 16 bit per il blocco sorgente cui si riferiscono i simboli nellinformazione Source Packet per ogni pacchetto, repair allinterno del pacchetto; deve essere la lunghezza del payload UDP;
Encoding Symbol ID (ESI): identificatore intero di 16 bit per i simboli di codifica allinterno del pacchetto;
Source Block Length (SBL): numero di 16 bit dei simboli sorgente nel blocco sorgente. Linterpretazione dellSBN, dellESI e dellSBL viene definita dalla specifica FEC Code. La Figura 10-22 mostra il formato del Repair FEC Payload ID.
il valore di s[i] nella costruzione dellinformazione Source Packet per ogni pacchetto deve essere lintero pi piccolo tale che s[i] x T (l[i] + 3).
Figura 10-22: Formato del Repair FEC Payload ID
Specifica FEC Code Deve essere usato il codificatore FEC Raptor specificato dal DVB nel documento [18]. Il blocco sorgente passato al codificatore FEC Raptor deve essere formato dal Source Block, costruito secondo la descrizione della struttura del Source Block nel 10.3.3.2 esteso con zero o pi simboli di padding in modo tale che il numero totale di simboli nel blocco sorgente sia uguale alla Maximum Source Block Length segnalata nellinformazione FEC Object Transmission. Cos il valore del parametro K usato dal codificatore FEC uguale alla Maximum Source Block
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.407 pacchetto. Il valore di ESI sistemato in un pacchetto repair Length per tutti i blocchi dello stream. I simboli di padding dato dalla formula seguente: devono essere composti interamente da byte settati al ESIrepair = Irepair + K valore zero. La dimensione dei simboli, T, da usare per la costruzione del blocco sorgente e dei simboli repair uguale allEncoding dove Irepair lindice del simbolo repair nella sequenza dei Symbol Size, segnalata nellinformazione FEC Object simboli repair, in cui il primo simbolo repair ha indice zero, il Transmission. Il parametro T deve essere settato in modo secondo indice 1, e cos via, e K il numero di simboli che il numero di simboli sorgente in ogni blocco sorgente sia sorgente (uguale al parametro Maximum Source Block al massimo Kmax = 8192. Length). Il campo Source Block Length del campo Repair FEC Il parametro Maximum Source Block Length, e quindi il Payload ID deve essere impostato al numero di simboli numero di simboli usati nelle operazioni di codifica e inclusi nellinformazione Source Packet di pacchetti associati decodifica FEC, deve essere settato a uno dei valori al blocco sorgente, prima di fare padding al Maximum specificati in [18]. Le derivazioni di altri parametri, che sono Source Block Length. raccomandate, vengono presentate successivamente. Costruzione dei pacchetti per la codifica Come gi descritto in precedenza, ogni pacchetto repair contiene le seguenti informazioni: Trasporto Questo sottoparagrafo descrive lo scambio di informazioni tra il codificatore/decodificatore Raptor e un qualsiasi protocollo di trasporto che fa uso del FEC Raptor per lo streaming. Il codificatore Raptor per lo streaming richiede le seguenti informazioni dal protocollo di trasporto per ogni blocco sorgente:
Source Block Number (SBN); Encoding Symbol ID (ESI); Source Block Length (SBL);
simbolo o simboli repair. Il numero dei simboli repair contenuto allinterno di un pacchetto repair viene calcolato dalla lunghezza del
la dimensione dei simboli, T,in byte;
il numero di simboli nel blocco sorgente, K; il Source Block Number (SBN);
KMAX: numero massimo di simboli sorgente per blocco sorgente (KMAX = 1281); KMIN: obiettivo minimo sul numero di simboli per blocco sorgente;
i simboli sorgente da codificare. Il codificatore Raptor fornisce al protocollo di trasporto linformazione dei pacchetti da codificare composta, per ogni pacchetto repair, da: Source Block Number (SBN); Encoding Symbol ID (ESI); Source Block Length (SBL);
GMAX: obiettivo massimo sul numero di simboli per pacchetto repair. Un requisito su questi parametri dingresso che ceil(B/P) KMAX. Il parametro di trasporto T viene calcolato come segue: sia G = min{ceil(PxKMIN/B), P/A, GMAX};
simboli repair. Il protocollo di trasporto deve comunicare questa informazione in modo trasparente al decodificatore Raptor.
Parametri di esempio Viene effettuata una raccomandazione per la derivazione del parametro di trasporto T, basata sui seguenti parametri dingresso:
B: dimensione massima del blocco sorgente, in byte; A: fattore di allineamento dei simboli, in byte, cio la dimensione dei simboli T un multiplo di A; P: dimensione massima del payload dei pacchetti repair (senza il Repair FEC Payload ID), in byte, che deve essere un multiplo di A;
il numero approssimativo di simboli per pacchetto dato da: T = floor(P/(AxG))xA. Il valore di T derivato dovrebbe essere considerato come una guida per il valore reale di T usato. Pu essere vantaggioso assicurare che T sia un divisore di P, oppure pu essere vantaggioso settare T a un valore pi piccolo per minimizzare gli sprechi quando vengono usati simboli repair di dimensione piena per recuperare simboli sorgenti parziali alla fine dei pacchetti sorgente persi (finch il numero massimo di simboli sorgente in un blocco sorgente non superi KMAX). Inoltre, la scelta di T pu dipendere dalla distribuzione delle dimensioni dei media packet, per esempio, se tutti i media packet hanno la stessa dimensione, allora vantaggioso scegliere T in modo che la dimensione reale del payload di un pacchetto repair P,
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.409 Stream MPEG-2 allinterno del quale vengono multiplati tutti dove P multiplo di T, sia uguale (o pi lunga del minor i dati per il servizio. In questo caso i Sequence Number RTP numero di byte possibile) al numero di byte che ogni media possono essere usati per derivare linformazione Source packet occupa nel blocco sorgente. FEC Packet Identification. Un vantaggio di questo schema Impostazioni raccomandate per i parametri dingresso sono: rispetto a quello visto nel paragrafo precedente che non A=16, KMIN=640 e GMAX=10. modifica in nessun modo i media packet, quindi pu essere La seguente tabella mostra i parametri di trasporto ottenuti usato in presenza di attrezzature obsolete che non dallalgoritmo illustrato, assumendo i valori raccomandati e riconoscerebbero i media packet modificati secondo lo P=1424. schema precedente. In questo schema FEC, il ruolo svolto dal Source FEC Dimensione massima del Dimensione G G*T Payload ID dello schema precedente sostituito dal numero del simbolo T blocco sorgente B di sequenza. I numeri di sequenza dei pacchetti allinterno di 16 KB 10 128 1280 ogni flusso da proteggere devono essere incrementati di 32 KB 10 128 1280 ununit per ogni pacchetto dello stream. La dimensione 128 KB 7 192 1344 256 KB 4 352 1408 dellinformazione Source Packet allinterno di un dato Tabella 10-2: Esempio di valori dei parametri Source Block per ogni pacchetto allinterno di un dato flusso di pacchetti ordinati in sequenza deve essere lo stesso e 10.3.4.2 Schema FEC Raptor per un singolo viene derivato dalla dimensione dei pacchetti FEC repair, flusso di pacchetti ordinati in sequenza che devono avere tutti la stessa dimensione per un dato Questo paragrafo definisce uno schema FEC per la blocco sorgente. protezione FEC di un singolo flusso di pacchetti in cui ogni media packet contiene un numero di sequenza unico. Si fa riferimento a tale flusso come ad un flusso di pacchetti ordinati in sequenza. Un esempio primario sarebbe la protezione FEC di un flusso RTP contenente un Transport
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.410 Procedure Formato e codici Questo schema FEC usa le procedure del framework gi Per quanto riguarda linformazione FEC Object definito per costruire un blocco sorgente cui possa essere Transmission, la struttura la stessa definita nel paragrafo applicato il codice FEC. Il mittente deve allocare i Source precedente. Il campo Source FEC Payload ID non viene Block Number ai blocchi sorgente in modo sequenziale, usato e i media packet non vengono modificati. Il formato del tornando a zero dopo il Source Block Number 216-1. Repair FEC Payload ID costituito da: Durante la costruzione del blocco sorgente: Initial Sequence Number (ISN del flusso i): campo di 16 bit che specifica i 16 bit pi bassi del numero di sequenza del primo pacchetto da includere in questo sotto-blocco. Se i numeri di sequenza sono pi corti di 16 bit, allora il Sequence Number ricevuto deve essere logicamente completato con bit di padding settati a zero per diventare lungo 16 bit.
lindicazione di lunghezza, l[i], inclusa nellinformazione Source Packet per ogni pacchetto, deve essere dipendente dal protocollo che viene trasportato. il valore di s[i] nella costruzione dellinformazione Source Packet per ogni pacchetto deve essere uguale al numero dei simboli repair in ogni pacchetto repair, che deve essere lo stesso per tutti i pacchetti repair di un blocco.
Encoding Symbol ID (ESI): campo di 16 bit che indica quali simboli repair sono contenuti allinterno di questo pacchetto repair. LESI fornito lESI del primo simbolo repair nel pacchetto.
Source Block Length (SBL): campo di 16 bit che specifica la lunghezza in simboli del blocco sorgente. La Figura 10-23 mostra il formato del Repair FEC Payload ID.
Derivazione dellinformazione Source FEC Packet Identification Linformazione Source FEC Packet Identification per un media packet viene derivata dal numero di sequenza del pacchetto e dallinformazione ricevuta in qualsiasi pacchetto FEC Repair appartenente al blocco sorgente. I blocchi sorgente sono identificati dal numero di sequenza del primo pacchetto sorgente del blocco; questa informazione viene
Figura 10-23: Formato del Repair FEC Payload ID
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.411 segnalata in tutti i pacchetti Repair FEC associati al blocco la Source Packet Information Length Lp per il blocco sorgente nel campo Initial Sequence Number. La lunghezza sorgente; dellinformazione Source Packet (in byte) per i media packet lInitial Sequence Number I del blocco sorgente. allinterno del blocco sorgente uguale alla lunghezza del Quindi lEncoding Symbol ID per il pacchetto con il numero payload contenente i simboli di codifica dei pacchetti repair di sequenza NS viene determinato tramite la formula (cio che non include il Repair FEC Payload ID) per quel seguente: blocco, che deve essere la stessa per tutti i pacchetti repair. ESI = (NS I) LP. La Source Packet Information Length (SPIL) in simboli Si noti che tutti i pacchetti repair associati a un dato Source uguale a questa lunghezza diviso lEncoding Symbol Size Block devono contenere la stessa Source Block Length e lo (che segnalata nellinformazione FEC Object stesso Initial Sequence Number. Transmission). Linsieme dei pacchetti sorgente inclusi nel blocco sorgente Derivazione degli Encoding Symbol ID dei pacchetti repair: viene determinato dallInitial Sequence Number (ISN) e dal lEncoding Symbol ID per un pacchetto repair indica quali Source Block Length (SBL) con la modalit che verr simboli repair contiene il pacchetto, ed dato direttamente spiegata in seguito. Siano: dal campo Encoding Symbol ID del Repair FEC Payload ID.
I: Initial Sequence Number del blocco sorgente; LP: Source Packet Information Length in simboli; Procedure per i flussi RTP Nel caso specifico di flussi di pacchetti RTP, il campo RTP Sequence Number deve essere usato come numero di sequenza nelle procedure prima descritte. Lindicazione di lunghezza inclusa nellinformazione Source Packet deve essere la lunghezza del payload RTP pi la lunghezza dei CSRC, se ve ne sono, e i byte di padding RTP, se ve ne sono. Da notare che questa lunghezza
LB: Source Block Length in simboli. I media packet con i numeri di sequenza da I a I+LB/LP-1 compresi vengono inclusi nel blocco sorgente. LEncoding Symbol ID per un pacchetto viene derivato dalle seguenti informazioni: il numero di sequenza Ns del pacchetto;
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.412 dove n il numero nominale dei pacchetti TS di 188 byte per sempre uguale alla lunghezza del payload UDP del pacchetto IP Source. pacchetto alla quale viene tolto12. La dimensione massima del blocco sorgente viene determinata dalla configurazione applicativa al mittente. Parametri di esempio Lalgoritmo conduce a parametri di trasporto per i Transport raccomandato lutilizzo dellalgoritmo descritto tra i Stream MPEG-2 come quelli riportati nella tabella parametri desempio in 10.3.4.1. Nel caso di stream RTP sottostante, assumendo i valori raccomandati per A, KMIN e che trasportano Transport Stream MPEG-2, la dimensione massima dei pacchetti repair dovrebbe essere fissata a: GMAX. P = ceil((n188 + 15)/A)A
Pacchetti massimi per periodo di protezione 100 200 300 400 Pacchetti TS nominali per pacchetto IP 7 7 7 7 Dimensione massima del pacchetto P 1344 1344 1344 1344 Dimensione massima del blocco sorgente B 134400 268800 403200 537600 G Dimensione del simbolo T 192 336 672 672
7 4 3 2
Tabella 10-3: Esempio di valori dei parametri
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.413 (che possono includere sia FEC packet SMPTE 2022-1 che 10.3.5 Decodificatore FEC FEC packet Raptor) per la ricostruzione di un blocco sorgente allinterno dei precedenti pacchetti max-block-size 10.3.5.1 Requisiti del decodificatore e/o allinterno dellinizio di una finestra temporale max-blocksize-time prima del tempo corrente, allora il decodificatore I decodificatori FEC compatibili con il documento [18] deve recuperare lintero blocco sorgente. devono supportare lelaborazione dei pacchetti SMPTE Il decodificatore che verr descritto in seguito soddisfa 2022-1. Questo significa che, ogni volta che: questo requisito ed compatibile con le raccomandazioni viene ricevuto un pacchetto FEC SMPTE 2022-1; finora fatte solamente se in grado di decodificare con vengono ricevuti tutti i media packet, tranne uno, successo un dato un set di pacchetti. protetti da questo FEC packet, allinterno dei precedenti media packet max-block-size e/o allinterno dellinizio di una finestra temporale max-block-sizetime prima del tempo corrente; 10.3.5.2 Procedure di decodifica ibrida
non sia passato il tempo nel quale il media packet rimanente utile al decodificatore dei media, allora deve essere applicata loperazione di decodifica SMPTE 2022-1 e i pacchetti recuperati risultanti devono essere passati al decodificatore dei media. I requisiti di cui sopra si applicano indipendentemente dal tempo di arrivo o dallordine dei pacchetti coinvolti. I parametri max-block-size e max-block-size-time fanno parte dellinformazione FEC Configuration e verranno discussi in 10.3.6. I decodificatori FEC possono supportare in aggiunta i FEC packet Raptor. In questo caso, se un ricevitore riceve un insieme matematicamente sufficiente di pacchetti di codifica
Nel caso in cui un ricevitore riceva pacchetti FEC repair da pi livelli, inclusi i pacchetti generati secondo i codici illustrati in 10.3.1 e 10.3.2, pu essere realizzata la decodifica combinata le cui procedure sono delineate nel presente paragrafo. La decodifica combinata procede in tre passi:
Decodifica SMPTE 2022-1: sono elaborati i FEC packet codificati secondo lSMPTE 2022-1, insieme ai media packet ricevuti, per recuperare zero o pi media packet. Decodifica Raptor: se mancano ancora media packet, allora vengono elaborati i pacchetti codificati secondo il Raptor, insieme ai media packet ricevuti e a quelli
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.414 recuperati al passo precedente, usando le procedure lo XOR dei campi Timestamp (TS) degli header RTP standard della decodifica Raptor per recuperare zero dei pacchetti protetti; o pi media packet. lo XOR dei payload RTP dei pacchetti protetti. Decodifica ibrida: se mancano ancora pacchetti Nel primo passo delloperazione di conversione, i campi di sorgente, allora i rimanenti pacchetti SMPTE 2022-1 ogni media packet ricevuto o recuperato protetto da un FEC non processati vengono convertiti in una forma in cui packet SMPTE 2022-1 ricevuto, vengono messi in XOR nei possono essere aggiunti al processo di decodifica campi corrispondenti del FEC packet. Dopo questa Raptor, e quindi si continua con la decodifica Raptor. operazione, i campi del FEC packet sono ognuno uguale La conversione dei pacchetti SMPTE 2022-1 e il loro uso allo XOR dei campi corrispondenti dei pacchetti protetti nella decodifica Raptor vengono descritti in 10.3.5.3. rimanenti non recuperati. 10.3.5.3 Conversione pacchetti SMPTE 2022-1 Nel secondo passo delloperazione di conversione, per ogni pacchetto FEC SMPTE 2022-1 rimanente, vengono Lobiettivo delloperazione di conversione dei pacchetti concatenati i seguenti campi per formare il payload di un SMPTE 2022-1 quello di convertire questi pacchetti in una pacchetto Raptor repair virtuale: forma tale da poter essere inclusi nel processo di decodifica Raptor. Secondo lSMPTE 2022-1, ogni FEC packet viene costruito applicando unoperazione di protezione, basata sullo XOR, a un numero D di pacchetti sorgente (i pacchetti protetti). Il payload UDP del pacchetto SMPTE 2022-1 contiene anche i seguenti dati:
un singolo byte di zeri; un indicazione di lunghezza di due byte, uguale allo XOR delle lunghezze dei payload RTP dei pacchetti protetti non recuperati, prese direttamente dal pacchetto FEC SMPTE 2022-1; un campo di due bit, uguale allo XOR dei campi RTP Version dei pacchetti protetti non recuperati. Questo campo uguale a zero se il numero dei pacchetti protetti non recuperati pari e diverso da 2; sette bit impostati a zero, corrispondenti allo XOR dei bit di RTP Padding (P), Extension (X), CSRC Count
un header FEC contenente: il campo Length Recovery, che lo XOR delle lunghezze dei payload RTP dei pacchetti protetti; lo XOR dei campi Payload Type (PT) degli header RTP dei pacchetti protetti;
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.415 (CC) e Marker (M) appartenenti ai pacchetti protetti un numero di byte di padding di valore zero, in modo non recuperati, che devono tutti essere zero secondo che la lunghezza totale del payload del pacchetto lSMPTE 2022-1; repair virtuale sia uguale alla lunghezza dei payload
un campo di sette bit uguale allo XOR dei campi RTP Payload Type (PT) dei pacchetti protetti non recuperati, presi direttamente dal corrispondente campo dellheader FEC SMPTE 2022-1; un campo di 16 bit uguale allo XOR dei campi RTP Sequence Number dei pacchetti protetti non recuperati. I Sequence Number dei pacchetti protetti non recuperati possono essere calcolati esplicitamente basandosi sui valori SNbase, offset e NA dellheader FEC del pacchetto FEC per lSMPTE 2022-1; un campo di 32 bit uguale allo XOR dei campi RTP Timestamp (TS) dei pacchetti protetti non recuperati, presi direttamente dal corrispondente campo dellheader FEC SMPTE 2022-1; un campo di 32 bit uguale allo XOR dei campi RTP SSRC dei pacchetti protetti non recuperati. Questo campo uguale a zero se il numero di pacchetti protetti non recuperati pari e uguale allSSRC dello stream diverso; lo XOR dei payload RTP dei pacchetti protetti non recuperati, presi direttamente dal resto del pacchetto FEC SMPTE 2022-1;
degli altri pacchetti Raptor repair, che devono essere tutte uguali. Il payload del pacchetto repair virtuale risultante uguale allo XOR dellinformazione Source Packet dei pacchetti protetti non recuperati. 10.3.6 Protocolli FEC Content Delivery Sulla base dei meccanismi di trasporto generali definiti dal DVB in [18] sono altres specificati, sempre in [17], diversi protocolli cosiddetti FEC Content Delivery specifici per la diffusione di contenuti TS MPEG-2 con protezione FEC facente uso delle componenti definite nei precedenti paragrafi. 10.3.6.1 TS MPEG-2 multicast su RTP
definito un protocollo Content Delivery per la distribuzione multicast protetta con FEC dei Transport Stream MPEG-2 su RTP. Protocolli di controllo Linformazione FEC Configuration deve essere consegnata usando i meccanismi Service Discovery del DVB descritti nel
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.416 pacchetti FEC repair. Solo i livelli FEC richiesti devono documento [18]. Il record DVB Broadcast Discovery pu essere inviati al ricevitore. contenere gli indirizzi e le porte multicast per uno o pi livelli Il server pu fornire i parametri FEC max-block-size, maxFEC. I ricevitori possono scegliere a quali livelli unirsi a block-size-time e linformazione FEC Object Transmission seconda delle capacit e della configurazione locale. nellheader Transport della risposta RTSP SETUP. Il Flow ID Quando viene fornito il livello Raptor, il Flow ID allinterno per il flusso TS MPEG-2 deve essere pari a zero. dellinformazione Source Packet per il flusso TS MPEG-2 deve essere zero. Protocollo di trasporto La protezione FEC del Transport Stream MPEG-2 pu Protocollo di trasporto essere fornita secondo quanto descritto nei 10.3.1 e La protezione FEC del Transport Stream MPEG-2 pu 10.3.2. Quando viene fornito un livello Raptor, deve essere essere fornita secondo quanto descritto nei 10.3.1 e usato lo schema FEC definito in 10.3.4.2. 10.3.2. Quando viene fornito un livello Raptor, deve essere usato lo schema FEC definito nel 10.3.4.2. 10.3.6.3 Video unicast generico 10.3.6.2 TS MPEG-2 unicast su RTP definito un protocollo Content Delivery per la distribuzione definito un protocollo Content Delivery per la distribuzione unicast protetta con FEC dei Transport Stream MPEG-2 su RTP. Protocolli di controllo Il ricevitore deve indicare nellheader Transport della richiesta RTSP SETUP quali livelli FEC sono necessari per fornire i numeri di porta che dovrebbero essere usati per i unicast protetta con FEC di stream audio/video arbitrari (per esempio, H.264 incapsulato in RTP) e viene fornito per descrivere come il FEC possa essere applicato ad estensioni future del documento [18] che indirizza lincapsulamento diretto di stream audio/video in RTP. Protocolli di controllo Il ricevitore deve indicare nellheader Transport della richiesta RTSP SETUP quali livelli FEC sono necessari per
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.417 fornire i numeri di porta che dovrebbero essere usati per i pacchetti FEC repair. Solo i livelli FEC richiesti devono 10.4 Valutazione delle prestazioni delle essere inviati al ricevitore. Il server pu fornire i parametri tecniche AL-FEC FEC max-block-size, max-block-size-time e linformazione FEC Object Transmission nellheader Transport della 10.4.1 Valutazione delle prestazioni del codice risposta RTSP SETUP. Raptor Protocollo di trasporto Si assume che lo stream audio/video venga trasportato da uno o pi flussi UDP. La protezione FEC per questi flussi UDP pu essere fornita usando le procedure riportate in 10.3.1 e in particolare lo schema FEC del 10.3.2. LATIS concentra la sua attenzione sullapplicazione di un FEC Raptor per lo streaming di servizi multimediali, cos come definito in dettaglio nel documento [62]. Il documento [164] fornisce una descrizione dettagliata di come il FEC possa essere applicato allIPTV, riportando anche dei risultati che mostrano i compromessi tra i requisiti di banda e la latenza per certi casi duso. Nellapproccio seguito dallATIS i pacchetti vengono raggruppati in blocchi sorgente, ognuno dei quali rappresenta un periodo di tempo specifico allinterno dello stream, noto come periodo di protezione. La protezione FEC applicata in modo indipendente ad ogni blocco sorgente, cosicch i pacchetti inviati allinterno di ogni periodo di protezione sono formati dai media packet e da FEC packet di correzione addizionali, come illustrato nella Figura 10-24.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.418 Perdite a burst della durata di 8ms possono essere causate da rumore elettrico impulsivo su una linea DSL (cfr. 9.1.1):
se i bit error causati da un impulso elettrico possono essere corretti dal livello fisico, allora non si avr nessuna perdita di pacchetti,
se non possono essere corretti allora i bit error vengono distribuiti sul periodo di interleaving, causando un efficace burst di fuori servizio. In alcune configurazioni comuni di DSL, questo periodo di interleaving proprio di circa 8ms. Perdite a burst pi lunghe sono tipicamente causate da processi di automatic protection switching (APS) causati da eventi di guasto di link rete (cfr. 9.1.1). I meccanismi di protezione di switching SONET/SDH possono condurre a una durata potenziale della perdita dei pacchetti dellordine di 50 ms. Per alcuni altri meccanismi di protezione (per esempio, reroute MPLS veloce, convergenza IGP rapida) la durata potenziale della perdita dei pacchetti pu essere pi lunga, pu essere infatti dellordine di 250 ms. Sono stati simulati due codici FEC:
Figura 10-24: Un approccio FEC generico per lo streaming Attraverso simulazioni vengono ricavati grafici che mostrano loverhead FEC richiesto per ottenere un obiettivo di qualit rappresentato da un tempo medio tra eventi di perdita (eventi di errore non corretti di 4 ore) in presenza di perdite burst. Levento di perdita in questo contesto definito come un caso in cui il codice FEC non in grado di correggere i pacchetti persi in un blocco. Vengono considerate perdite a burst brevi (della durata di 8ms) e perdite a burst pi lunghe (della durata di 50ms, 200ms e 250ms).
un codice ideale, che ha la propriet che, se un blocco sorgente contiene k pacchetti, allora la ricezione di k pacchetti qualsiasi, con una qualunque
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.419 combinazione di media packet e FEC packet per il considerato il caso peggiore in assoluto per il tasso di blocco, permette il recupero del blocco; perdita. Nel secondo insieme di simulazioni, la frequenza il codice Raptor, come specificato in [62]. delle perdite a burst tale che il tasso di perdita dei Le simulazioni sono state svolte per uno stream a 2 Mbit/s pacchetti prima del FEC circa 1x10-4. (cio in Standard Definition) e per uno stream a 6 Mbit/s La Figura 10-25 e la Figura 10-26 mostrano loverhead (cio in High Definition), con una durata del tempo di necessario per avere un tempo medio tra le perdite di simulazione di 128 ore. quattro ore per uno stream a 2 Mbit/s; la Figura 10-25 stata prodotta per un tasso di perdita dei pacchetti di 5x10-3, Perdite a burst di breve durata (8 ms) la Figura 10-26 per un tasso di perdita di 1x10-4. Nel primo insieme di simulazioni, la frequenza delle perdite a burst tale che il tasso di perdita dei pacchetti prima del FEC approssimativamente 5x10-3, che pu essere
Figura 10-25: Requisiti di overhead FEC per uno stream a 2 Mbit/s in presenza di perdite a burst di 8ms e di un tasso di perdita dei pacchetti globale di 5x10-3 La Figura 10-27 e la Figura 10-28 mostrano loverhead necessario per avere un tempo medio tra le perdite di quattro ore, ma in questo caso per uno stream a 6 Mbit/s; la
Figura 10-26: Requisiti di overhead FEC per uno stream a 2 Mbit/s in presenza di perdite a burst di 8ms e di un tasso di perdita dei pacchetti globale di 1x10-4 Figura 10-27 relativa a un tasso di perdita dei pacchetti di 5x10-3, mentre la Figura 10-28 relativa a un tasso di perdita di 1x10-4.
Figura 10-27: Requisiti di overhead FEC per uno stream a 6 Mbit/s in presenza di perdite a burst di 8ms e di un tasso di perdita dei pacchetti globale di 5x10-3
Figura 10-28: Requisiti di overhead FEC per uno stream a 6 Mbit/s in presenza di perdite a burst di 8ms e di un tasso di perdita dei pacchetti globale di 1x10-4 un overhead leggermente maggiore rispetto a questo, poich la protezione FEC viene fornita solo nella forma di pacchetti interi e il codice FEC stesso ha un overhead addizionale intrinseco. La Figura 10-29 e la Figura 10-30 mostrano loverhead necessario per correggere perdite a burst della durata di 250ms, sotto lipotesi che queste perdite siano eventi isolati, per uno stream a 2 Mbit/s (Figura 10-29) e per uno stream a 6 Mbit/s (Figura 10-30).
Perdite a burst di durata maggiore (250 ms, 200 ms, 50 ms) Il minimo overhead richiesto per recuperare perdite a burst lunghi dato dalla formula seguente:
dove Tburst la durata del burst di fuori servizio e Tprotezione la durata del periodo di protezione. In pratica necessario
Figura 10-29: Requisiti di overhead FEC per uno stream a 2 Mbit/s in presenza di perdite a burst di 250ms La Figura 10-31 e la Figura 10-32 mostrano loverhead necessario per correggere perdite a burst di 200ms, per uno
Figura 10-30: Requisiti di overhead FEC per uno stream a 6 Mbit/s in presenza di perdite a burst di 250ms stream a 2 Mbit/s (Figura 10-31) e per uno stream a 6 Mbit/s (Figura 10-32).
Figura 10-31: Requisiti di overhead FEC per uno stream a 2 Mbit/s in presenza di perdite a burst di 200ms La Figura 10-33 e la Figura 10-34 mostrano loverhead necessario per correggere perdite a burst di 50ms, sempre
Figura 10-32: Requisiti di overhead FEC per uno stream a 6 Mbit/s in presenza di perdite a burst di 200ms per uno stream a 2 Mbit/s (Figura 10-33) e per uno stream a 6 Mbit/s (Figura 10-34).
Figura 10-33: Requisiti di overhead FEC per uno stream a 2 Mbit/s in presenza di perdite a burst di 50ms Linee guida generali Le simulazioni precedentemente illustrate mostrano i requisiti di banda su una rete con tassi di perdita dei pacchetti piuttosto elevati (per una rete gestita). In reti ben progettate, ci si aspetta che i tassi di perdita dei pacchetti possano essere minori e i burst di fuori servizio possano essere ben limitati da una durata inferiore ai 250ms considerati in precedenza. Gli approcci FEC possono essere usati ad entrambi gli estremi delle prestazioni di rete. I costi
Figura 10-34: Requisiti di overhead FEC per uno stream a 6 Mbit/s in presenza di perdite a burst di 50ms dei sistemi terminali sono gli stessi a entrambi gli estremi, la sola differenza la banda richiesta. Quando si considerano approcci FEC e di networking, i costi di questa banda addizionale dovrebbero essere bilanciati attentamente con lalternativa di costi di network engineering pi elevati associati con lottenimento di tassi di perdita dei pacchetti end-to-end pi bassi.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.425 10.4.2.1 Parametri di selezione 10.4.2 Confronto tra SMPTE 2022-1, Raptor e La qualit dei servizi audiovisivi distribuiti nelle reti IP codice ibrido influenzata dalle caratteristiche tipiche delle reti stesse, Il documento [151] del DVB stato prodotto per fornire un background informativo relativamente al processo di valutazione che ha condotto a selezionare lapproccio ibrido nella specifica [18], che prevede luso di FEC a livello applicativo per la protezione di stream audiovisivi che transitano in infrastrutture di rete di tipo IP. Il documento [151] composto da due parti: la prima presenta i criteri di valutazione approvati prima dellinizio del processo di selezione delle possibili soluzioni, la seconda costituisce la relazione sul processo di valutazione medesimo. Il documento [151] riporta le valutazioni della commissione DVB-IPI sui seguenti codici AL-FEC proposti: come la latenza e gli errori. Come usuale nel lavoro del DVB il punto di partenza per il lavoro tecnico costituito da requisiti di tipo commerciale definiti dal Commercial Module. Relativamente alla specifica in oggetto, [18], tale requisito stato cos espresso: Inclusione di strategie adeguate per la protezione dagli errori, come un meccanismo FEC, per permettere ai servizi DVB di essere trasportati su reti di accesso tipicamente di tipo IP con una qualit del servizio accettabile.
La soluzione scelta deve essere in linea con il lavoro degli altri enti di standardizzazione, come il DSLForum. La soluzione scelta deve fornire flessibilit in modo da coprire un range ragionevole di tipologie di rete e una variet di modelli di business. Inoltre, la soluzione scelta deve essere estensibile in modo da soddisfare futuri requisiti dello streaming. La soluzione scelta deve essere implementabile sugli HNED senza determinare un aumento significativo dei costi dei prodotti.
SMPTE 2022-1, specificato nel documento [61]; codice Raptor specificato nel documento [62]; codifica ibrida, in cui viene trasmessa una combinazione di pacchetti SMPTE 2022-1 e Raptor.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.426 LAL-FEC prefigurato lavora in maniera end-to-end tra il il pre-calcolo del FEC, per permettere un impiego server dei contenuti, dislocato tipicamente nella rete core, e successivo quando il contenuto viene inviato in streaming (CoD); il terminale dutente collegato alla rete domestica. I parametri che si sono ritenuti maggiormente significativi per la possibilit di applicazione anche per modalit di trasporto dei flussi audio-video direttamente su RTP guidare il processo di selezione dello schema FEC pi ovvero senza un Transport Stream MPEG-2; idoneo, sono i seguenti:
le caratteristiche di perdita di pacchetti delle reali implementazioni di reti di accesso di tipo IP, come ad esempio le DSL. Tali reti potrebbero includere luso dellinterleaving a livello fisico per migliorare le prestazioni di trasporto; le ulteriori perdite di pacchetti che potrebbero aver luogo nella rete core a causa della congestione o nella rete domestica a causa, ad esempio, delladozione di tecnologie wireless; la sensibilit agli errori della codifica audio/video (A/V); la flessibilit e la capacit dello schema FEC (codifica e decodifica) di eseguire la correzione minima e massima con costo minimo (di elaborazione e di memoria) per numerosi stream simultanei; il costo dellinefficienza in larghezza di banda tipica del codice, ovvero la differenza tra la banda richiesta dal codice e la banda minima teorica necessaria (di un FEC ideale) per il servizio nelle condizioni di perdita date.
la lunghezza variabile dinamicamente dei pacchetti IP che trasportano contenuto audio/video. di perdita dei
10.4.2.2 Caratteristiche pacchetti
Le caratteristiche riguardanti la perdita dei pacchetti dovrebbero essere fornite dagli operatori di rete e dai venditori di chip DSL, in forma di dati raccolti dalle implementazioni, oppure in forma di una dichiarazione sul livello di errore residuo che dovrebbe pertanto essere corretto dal livello applicativo. Le metriche di perdita dei pacchetti end-to-end nel caso peggiore possono essere fornite in termini di tasso medio di perdita e di distribuzione delle perdite (che possono essere casuali o a burst) per i pacchetti IP, indipendentemente dal bit rate. Le caratteristiche del rumore impulsivo nei sistemi DSL, resi disponibili dallITU, [152], sono state usate come base per le valutazioni.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.427 FEC. I punti chiave che risultano da questo diagramma sono Sebbene laccesso DSL sia chiaramente un caso rilevante i seguenti. (in cui i risultati possono variare largamente), importante tener conto anche della presenza delle reti core, di accesso Esistono altri meccanismi che possono influire sulla e home per una valutazione accurata delle caratteristiche di qualit di servizio per raggiungere il livello minimo di accettabilit (al massimo un artefatto visibile ogni ora), perdita dei pacchetti. questi sono: il FEC/interleave a livello DSL; 10.4.2.3 Sistema di riferimento per le il tipo di codifica audio/video; valutazioni qualsiasi tecnica di occultamento derrore nel La Figura 10-35 illustra un esempio di distribuzione di un decodificatore. servizio video in una rete con accesso in tecnologia DSL Le prestazioni del FEC a livello applicativo dovrebbero fornire unadeguata protezione dagli errori con o senza dalla sorgente al destinatario. la presenza di questi meccanismi (mostrata nella figura precedente come minimum correction e maximum correction).
Quando altri meccanismi sono presenti, lAL-FEC dovrebbe tenere in conto gli effetti causati dal fallimento di tali meccanismi in corrispondenza di condizioni derrore critiche. Quando altri meccanismi sono presenti, il carico sul FEC a livello applicativo viene ridotto in condizioni normali derrore, portando a possibili riduzioni di costi in termini di latenza, memoria, potenza di calcolo e altro. Gli spazi presenti in Figura 10-35 nel dominio della rete core e in quello della rete home mettono in evidenza la possibile presenza di altri tipi di reti con
Figura 10-35: Requisiti di correzione minima e massima per il dominio della rete di accesso DSL La Figura 10-35 mette in evidenza i componenti attraverso cui viene trasportato il servizio e la posizione logica dellAL-
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.428 possibile influenza sulla perdita dei pacchetti. Tali reti dovrebbero essere tenute idealmente in Le prestazioni di ogni AL-FEC sono state valutate in termini considerazione nella specifica delle prestazioni del di: FEC di livello applicativo, anche se queste possono overhead richiesto dal FEC per un determinato target variare a seconda delle implementazioni. in tutte le condizioni di perdita prefissate, espresso come rapporto tra dati FEC e dati protetti (%); 10.4.2.4 Criteri di valutazione dello schema flessibilit: FEC cambiamento dinamico delloverhead o/e della In questo paragrafo sono descritti i criteri per la valutazione dimensione dei blocchi (allinterno o tra i blocchi di uno schema FEC utilizzati dal DVB nelle seguenti FEC); condizioni di simulazione: range dei periodi di protezione, ovvero dimensione dei blocchi FEC; tre possibili distribuzioni derrore: -3 -5 adeguatezza allutilizzo con una grande variet di perdite casuali (PLR da 10 a 10 ), -3 -5 strategie di trasmissione FEC; perdite a burst (PLR da 10 a 10 con distribuzioni basate sui risultati ITU per DSL), perdite minori di 10-5;
esigenze di memoria per la sorgente dello streaming per il buffering (byte); requisiti di elaborazione per la sorgente dello streaming misurati come: numero massimo e numero medio di operazioni XOR
latenza massima addizionale dovuta al FEC variabile a seconda dellapplicazione (VOD = 100 ms, Broadcast = 400 ms); bit rate per il VOD pari a 2 Mbit/s e per il Broadcast da 2 a 6 Mbit/s (entrambi basati su H.264/AVC); tempo medio tra due errori incorreggibili pari a quattro ore10.
10
Generalmente i requisiti di qualit dellIPTV vengono espressi come massimo un evento di errore su un certo intervallo di tempo; ad esempio il
DVB fissa un requisito di al massimo un artefatto visibile ogni ora. Se si considera invece il tempo medio tra gli eventi di perdite incorregibili, allora in presenza di perdite indipendenti e casuali, un tempo medio tra gli eventi di 4 ore implica che lobiettivo di massimo un artefatto visibile ogni ora non sar soddisfatto all'incirca una volta al giorno (cio vengono visti due errori allinterno della stessa ora circa una volta al giorno).
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.429 numero massimo e numero medio di dichiarazioni capacit di scartare il flusso FEC e di processare solo condizionali (IF..THEN); i pacchetti originari come ordinariamente (garantendo numero massimo e numero medio di switching dei cos il funzionamento di STB che non implementino il contenuti; FEC); dimensione massima e dimensione media di capacit di aggiungere o rimuovere i FEC packet. memoria temporanea addizionale necessaria; numero massimo e numero medio di thread (qualora 10.4.2.5 Simulazioni del DVB ve ne fossero); Una questione importante nelle valutazioni effettuate stato banda massima di memoria. il modo in cui i diversi codici ordinano i pacchetti per la esigenze di memoria del STB per il buffering e trasmissione, in quanto influenza la latenza e quindi influisce lelaborazione (byte); sulle esigenze sulla larghezza di banda dei codici. Sono requisiti di elaborazione per il STB misurati come: possibili molti ordinamenti per entrambi i codici. Nelle numero massimo e numero medio di operazioni simulazioni effettuate vengono presi in considerazione i due XOR; seguenti ordinamenti pi significativi: numero massimo e numero medio di dichiarazioni condizionali (IF..THEN); trasmissione a rate costante, in cui i FEC packet numero massimo e numero medio di switching dei vengono inviati interallacciati ai pacchetti a cui fanno contenuti; riferimento; dimensione massima e dimensione media di trasmissione a burst, in cui i FEC packet vengono memoria temporanea addizionale necessaria; trasmessi in maniera raggruppata successivamente ai numero massimo e numero medio di thread (qualora pacchetti a cui fanno riferimento. ve ne fossero).
scalabilit, cio ladeguatezza per il costo e per limplementazione dellhardware; quantit di dati persi e visibilit degli artefatti quando fallisce il FEC;
I grafici che seguono riportano il rate di perdita di pacchetti in funzione delloverhead del FEC necessario, per ottenere lobiettivo di qualit di servizio prefissato. La banda minima richiesta stata valutata svolgendo simulazioni ripetute,
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.430 aumentando gradualmente loverhead FEC fino ad ottenere Caso multicast Per il caso multicast stata usata una latenza massima lobiettivo di tempo medio tra le perdite dei pacchetti. addizionale di 400ms. I grafici che verranno illustrati in Sebbene non sia lunico criterio di valutazione per lAL-FEC, seguito mostrano loverhead FEC richiesto per ottenere un limpegno di banda aggiuntivo rappresenta il costo della tempo medio tra le perdite dei pacchetti di quattro ore, soluzione per loperatore: un consumo di banda eccessivo rispetto al tasso di perdita dei pacchetti, sia nel caso di per il FEC si pu tradurre in una qualit di servizio pi perdita casuale che nel caso di perdita REIN. Il calcolo bassa, in un minor numero di servizi o in un target di delloverhead si basa sul numero di byte inviati, incluso mercato minore (minor numero di utenti serviti a causa di lheader IP e altri header, non semplicemente sul rapporto limitazioni di velocit di accesso). tra pacchetti di correzione e pacchetti sorgente. Il tempo di simulazione stato di 96 ore ed stato misurato Le figure includono anche un grafico per un codice a il tempo medio tra le perdite dei pacchetti. blocchi ideale, che rappresenta loverhead teorico pi basso che potrebbe raggiungere lobiettivo di qualit entro la Nelle simulazioni sono stati usati due modelli di perdita: latenza massima usando un codice FEC a blocchi e fornisce perdita dei pacchetti casuale unutile guida su quanta larghezza di banda dedicata al FEC un modello di perdita basato sul Repetitive Electrical realmente necessaria per fornire la protezione FEC Impulse Noise (REIN) dei sistemi DSL. richiesta e su quanto overhead dovuto a inefficienza nel Il modello REIN conduce a delle perdite a burst di lunghezza codice FEC stesso. fissa (8ms), che sono disposte a caso in modo da ottenere un tasso di perdita globale allinterno del range di interesse di 10-6 e 10-3. Quindi, i risultati esposti nel caso REIN costituiscono un ottimo indice delle prestazioni del codice in presenza di perdite a burst. Nel seguito sono riportati i risultati delle simulazioni rispettivamente nei casi di trasmissione multicast e unicast.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.431 ottenere un tempo medio tra le perdite di quattro ore, Risultati con ordinamento di trasmissione a rate costante rispetto al tasso di perdita, nei casi di perdita casuale e Come detto in precedenza, i grafici di questa sezione e della perdita REIN, per stream a 2 e 6 Mbit/s. seguente mostrano loverhead FEC minimo richiesto per
Figura 10-36: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-37: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 400ms, perdita casuale, trasmissione costante 400ms, perdita casuale, trasmissione costante
Figura 10-38: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-39: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 400ms, perdita REIN, trasmissione costante 400ms, perdita REIN, trasmissione costante
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.433 Risultati con ordinamento di trasmissione a burst Le curve per il codice a blocchi ideale e per il codice Raptor sono per una trasmissione a rate costante, confrontata con la trasmissione a burst per il SMPTE 2022-1.
Figura 10-40: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-41: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 400ms, perdita casuale, trasmissione a burst 400ms, perdita casuale, trasmissione a burst
Figura 10-42: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-43: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 400ms, perdita REIN, trasmissione a burst 400ms, perdita REIN, trasmissione a burst Dallanalisi dei risultati delle simulazioni si possono dedurre le seguenti considerazioni: nel modello di perdita casuale che in quello di perdita REIN;
il codice Raptor richiede costantemente un overhead vicino al minimo possibile per un codice a blocchi (rappresentato nei grafici con la linea rossa); loverhead richiesto per il codice Raptor cresce lentamente allaumentare del tasso di perdita; un overhead Raptor modesto del 9% fornisce una protezione FEC fino a un tasso di perdita di 10-3 sia
il codice SMPTE 2022-1, con un rate di trasmissione costante, si comporta in modo simile al codice ideale tutte le volte che il PLR rimane sotto un valore di soglia intorno a 10-4 e solo in caso di perdita casuale (questo il caso poich il codice SMPTE 2022-1 riga un semplice codice di parit, ottimo quando sia necessario solo un pacchetto di dati di protezione per blocco);
intorno a un rate di perdita di 10-4 per il caso di perdita casuale, il codice SMPTE 2022-1 richiede overhead pi elevato circa il 34% per lo stream a 2 Mbit/s e il 20% per lo stream a 6 Mbit/s; a seconda dellordinamento di trasmissione, al di sopra di un tasso di perdita dei pacchetti di 3x10-4 per il caso REIN, non esistono configurazioni del codice SMPTE 2022-1 che supportino lobiettivo di qualit richiesto (misurato in tempo medio tra le perdite dei pacchetti). Tuttavia, quando si usa un obiettivo di qualit leggermente inferiore (ad esempio lo stesso tempo ma misurato in tempo medio tra blocchi FEC con errore), possibile configurare il SMPTE 2022-1 per raggiungere lobiettivo di qualit richiesto; lordinamento a burst per il codice SMPTE 2022-1 richiede un po meno overhead per tassi di perdita elevati, anche se ancora significativamente maggiore dei Raptor; lordinamento di trasmissione a burst per il codice SMPTE 2022-1 offre miglioramenti significativi nel caso REIN, apportando miglioramenti al codice a blocchi ideale, che usa un ordinamento di trasmissione costante; la scelta dellordinamento di trasmissione a burst o costante per i codici Raptor provoca una piccola differenza nelloverhead richiesto;
lordinamento di trasmissione a burst per il SMPTE 2022-1 non permette di raggiungere lobiettivo di qualit in caso di perdita REIN per lintero range di perdite. Da notare che la simulazione basata su un obiettivo di qualit inferiore pu essere soddisfatta dal SMPTE 2022-1. Nei casi suddetti, i parametri per il codice SMPTE 2022-1 sono stati selezionati per fornire le migliori prestazioni per ogni particolare tasso e modello di perdita attraverso unampia ricerca del possibile insieme di parametri. In pratica, ci si aspetta che i tassi di perdita e i modelli derrore siano, in larga misura, sconosciuti a priori. In particolare, per i casi REIN, il codice SMPTE 2022-1 su colonne, con un numero di colonne uguale alla lunghezza del burst, fornisce una protezione adeguata, fintanto che eventi con due burst di errori allinterno di un periodo di protezione avvengano solo una volta ogni quattro ore o meno. Questo pu avvenire quando il rate di perdita globale alto o quando c una forte correlazione tra i burst. Inoltre, se errori singoli di perdite casuali si verificano ad una distanza di tempo ravvinata ad un burst, allora potrebbero non essere corretti.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.436 singolo pacchetto non inficia sulle prestazioni di correzione Caso unicast derrore del codice. Contenuto memorizzato/bufferizzato Come in precedenza, sono state svolte simulazioni ripetute In questi casi il contenuto disponibile sul server prima della durata di 96 ore, con loverhead FEC aumentato per dellinvio allutente; per i servizi VOD il contenuto ogni simulazione fino ad ottenere lobiettivo di qualit fissato. immagazzinato nella sua interezza e per il live broadcast La procedura faststart viene ripetuta ogni 10 minuti durante con trick mode il contenuto bufferizzato per almeno la simulazione per modellare leffetto del cambiamento di qualche centinaio di millisecondi, quando lutente attiva il canale ripetuto o luso dei trick mode. trick mode mettendo in pausa il broadcast multicast. Come di consueto, i grafici di questa sezione e della In questi scenari il codice Raptor incorpora una tecnica di seguente mostrano loverhead minimo richiesto per ottenere riempimento del buffer veloce (chiamata in questo lobiettivo di tempo medio tra le perdite di quattro ore, documento faststart), che permette alla dimensione del rispetto al tasso di perdita, relativamente ai casi di perdita blocco protetto di essere aumentata gradualmente durante i casuale e di perdita REIN, per stream a 2 e 6 Mbit/s. primi pochi secondi di trasmissione. Questa tecnica possibile solo a causa dellindipendenza tra la dimensione del blocco e loverhead previsto dal Raptor; inoltre la possibilit di variare in modo flessibile loverhead in un
Figura 10-44: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-45: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 100ms (contenuto immagazzinato/bufferizzato), perdita casuale 100ms (contenuto immagazzinato/bufferizzato), perdita casuale
Figura 10-46: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-47: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 100ms (contenuto immagazzinato/bufferizzato), perdita REIN 100ms (contenuto immagazzinato/bufferizzato), perdita REIN
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.439 figure seguenti mostrano i risultati delle simulazioni per Contenuto live questo caso. Nel caso di distribuzione unicast di contenuto live (ad esempio in reti che non supportano il multicast) la Ordinamento di trasmissione a rate costante dimensione dei blocchi per il codice Raptor limitata dai requisiti di latenza massima dovuta al FEC di 100ms. Le
Figura 10-48: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-49: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 100ms (contenuto live), perdita casuale, trasmissione costante 100ms (contenuto live), perdita casuale, trasmissione costante
Figura 10-50: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-51: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 100ms (contenuto live), perdita REIN, trasmissione costante 100ms (contenuto live), perdita REIN, trasmissione costante
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.441 confrontata con la trasmissione a burst per il codice Trasmissione a burst SMPTE 2022-1. Le curve per il codice a blocchi ideale e per il codice Raptor sono per una trasmissione a rate costante,
Figura 10-52: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-53: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 100ms (contenuto live), perdita casuale, trasmissione a burst 100ms (contenuto live), perdita casuale, trasmissione a burst
Figura 10-54: Transport Stream MPEG-2 a 2 Mbit/s, latenza di Figura 10-55: Transport Stream MPEG-2 a 6 Mbit/s, latenza di 100ms (contenuto live), perdita REIN, trasmissione a burst 100ms (contenuto live), perdita REIN, trasmissione a burst Il codice Raptor soddisfa lobiettivo di qualit per tutti i tassi di errore con un overhead prossimo al minimo possibile. Il codice SMPTE 2022-1 soddisfa lobiettivo di qualit con overhead minimo solo nei casi in cui il tasso di perdita sia sotto una soglia intorno a un rate di perdita dei pacchetti di 10-4. Con lordinamento di trasmissione costante e perdite REIN, il codice Raptor richiede un overhead inferiore o circa uguale alloverhead del codice SMPTE 2022-1 per tutti i tassi di perdita. Per altri casi (trasmissione a burst e/o perdita casuale) il codice SMPTE 2022-1 richiede un overhead leggermente minore per tassi di perdita al di sotto della soglia. Per tassi di perdita bassi e in presenza di perdita casuale, il codice SMPTE 2022-1 semplicemente un codice di parit 1D, che ideale. In questi casi il SMPTE 2022-1 presenta meno overhead del Raptor.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.443 Raptor, mentre, per quanto riguarda il SMPTE 2022-1, Analisi dei risultati delle simulazioni sopra la soglia si ha una riduzione delloverhead Si presenta un riepilogo dei risultati ottenuti secondo rispetto al caso di trasmissione costante, ma ancora lordinamento di trasmissione e il tipo di perdita. molto maggiore delloverhead dei Raptor. Video live multicast e unicast
Esiste una soglia per il tasso di perdita in entrambi i casi: sotto la soglia loverhead del SMPTE 2022-1 molto basso e vicino a quello dei Raptor (a volta maggiore, a volta minore), mentre sopra la soglia loverhead del SMPTE 2022-1 significativo (sempre molto maggiore rispetto a quello dei Raptor). La soglia intorno a un rate di perdita dei pacchetti di 10-4 (in realt tra 5*10-5 e 2*10-4) a seconda dei casi. Nel caso di ordinamento di trasmissione costante e perdite casuali, sotto la soglia loverhead del SMPTE 2022-1 leggermente inferiore a quello dei Raptor, mentre sopra la soglia loverhead dei Raptor molto inferiore a quello del SMPTE 2022-1. Nel caso di ordinamento di trasmissione costante e perdite a burst (REIN), sotto la soglia loverhead dei Raptor leggermente inferiore a quello del SMPTE 2022-1 e sopra la soglia loverhead dei Raptor molto inferiore a quello del SMPTE 2022-1. Quindi in questo caso loverhead dei Raptor sempre il pi basso. Nel caso di ordinamento di trasmissione a burst e perdite casuali, la trasmissione a burst non ha molto effetto sotto la soglia e non incide sulloverhead dei
Nel caso di ordinamento di trasmissione a burst e perdite a burst (REIN), come detto in precedenza, la trasmissione a burst non ha molto effetto sulloverhead dei Raptor, mentre, per quanto riguarda il SMPTE 2022-1, si ha una riduzione delloverhead sia sotto che sopra la soglia, anche se sopra la soglia loverhead molto maggiore di quello dei Raptor. Da notare che sotto la soglia loverhead del SMPTE 2022-1 leggermente inferiore a quello dei Raptor.
Contenuto unicast immagazzinato o bufferizzato
Il codice Raptor pu utilizzare la modalit di trasmissione faststart in modo da usare molta meno banda del SMPTE 2022-1 in tutti i casi.
Quando non viene utilizzato il meccanismo di faststart, i risultati sono gli stessi di quelli per il video multicast e unicast. In tutti i casi, i risultati ottenuti mostrano loverhead richiesto dai parametri per la configurazione migliore per il codice SMPTE 2022-1 secondo le linee guida per il settaggio dei parametri SMPTE 2022-1 e secondo la specifica [61]. I parametri sono stati selezionati tra varie configurazioni (incluse quelle che prevedono solo pacchetti riga, solo
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.444 lordinamento di trasmissione a burst, la variazione pacchetti colonna, entrambi i tipi di pacchetti e diverse significativa e su un periodo di tempo pi lungo. dimensioni della matrice) e riportando solo loverhead pi Per poter supportare i ricevitori non aggiornati in caso di basso che ha raggiunto la qualit richiesta. Questo significa multicast, ogni volta che possibile, luso del FEC non che la scelta del codice stata basata implicitamente sulla dovrebbe introdurre jitter addizionale significativo nei media conoscenza completa dei modelli e dei tassi di perdita in packet. Tuttavia lutilizzo dellordinamento di trasmissione ogni caso. proposto per i codici Raptor introduce una piccola quantit di jitter aggiuntivo allarrivo dei pacchetti al ricevitore. Anche In conclusione, i requisiti sulla qualit della rete (obiettivo di lutilizzo dellordinamento di trasmissione costante proposto tasso di perdita end-to-end) dipendono significativamente per il SMPTE 2022-1 introduce una piccola quantit di jitter dalla scelta del codice FEC (SMPTE 2022-1 o Raptor): i addizionale quando i burst vengono sagomati sul link di requisiti sulla qualit della rete sono molto pi stringenti se accesso. Gli ordinamenti di trasmissione sono viene scelto il SMPTE 2022-1, poich questo lavora bene intercambiabili tra i codici, rendendo possibili molte solo finch il tasso di perdita dei pacchetti rimane sotto la alternative. soglia precedentemente definita (intorno a 10-4). Nelle simulazioni precedenti, il jitter massimo addizionale nel 10.4.2.6 Valutazioni su latenza, jitter e caso dei codici Raptor intorno ai 40ms per i casi in cui la sagomatura del traffico latenza di 400ms, e nella maggior parte dei casi molto inferiore. Infine, la latenza in queste simulazioni stata Tutte le simulazioni svolte assumono che il traffico inviato interpretata come latenza addizionale, introdotta tra la debba mantenere un bit rate costante, sebbene lo schema sorgente e il playout dovuta allintroduzione del FEC e che SMPTE 2022-1 a bit rate costante raddoppi in realt il bit equivalente alla dimensione del buffer di dati FEC che deve rate istantaneo ogni volta che viene inviato un pacchetto di essere presente al ricevitore. Questo tempo si aggiunge correzione, ci visibile soltanto come una variazione nel bit direttamente al tempo di risposta per le azioni dellutente, rate su periodi di tempo molto brevi. Tuttavia, per come il cambio del canale, il rewind, il forwarding e altro.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.445 Nel caso di contenuto live, lo schema Raptor aggiunge una piccola quantit al tempo tra levento che accade effettivamente al mittente e la presentazione allutente (distinta dal tempo di risposta per le azioni dellutente). Questo tempo addizionale al massimo pari a 40 ms e, dato che il ritardo end-to-end globale di solito molto maggiore di 40ms, non viene considerato significativo, soprattutto perch non contribuisce al tempo di risposta per le azioni dellutente. Lo schema Raptor sufficientemente flessibile da poter ridurre questo ritardo, se richiesto. Infine, nelle valutazioni effettuate sono state verificate solo le due latenze di 100ms e 400ms. La latenza minore conduce a un tempo di cambio dei canali pi corto, ma ha come costo la necessit di un overhead FEC maggiore per un certo Figura 10-56: Compromesso tra latenza e banda FEC livello di protezione. Al contrario, la latenza pi lunga porta a un tempo di cambio dei canali maggiore in cambio di un La Figura 10-56 suggerisce che possibile un risparmio di overhead FEC pi basso. La Figura 10-56 illustra tale larghezza di banda significativo se il budget di latenza viene compromesso per un codice ideale e per diversi obiettivi di aumentato da 100ms a 200ms, ma mostra anche che c un qualit (Mean Time Between Artifacts, MTBA). guadagno molto piccolo facendo crescere la latenza oltre i 400ms. In particolare, la Figura 10-56 getta dubbi sulla validit pratica del caso di 2 Mbit/s e 100ms, in quanto a un operatore che vincolato ad usare una codifica a 2 Mbit/s risulterebbe molto utile il risparmio di larghezza di banda
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.446 Tuttavia, il possibile numero di combinazioni abbastanza FEC che potrebbe essere ottenuto con un budget di latenza ampio da poter offrire molti livelli diversi di protezione. di 200ms. 10.4.2.7 Valutazioni sulla flessibilit 10.4.2.8 Valutazioni sui requisiti di elaborazione e di memoria Il codice Raptor stato progettato per avere una complessit computazionale modesta, in modo da essere facilmente implementabile in software su dispositivi con risorse limitate come i STB e i dispositivi mobili. Il codice SMPTE 2022-1 stato progettato per avere una complessit computazionale molto bassa, in modo da essere facilmente implementabile in software o in hardware. Per entrambi i codici, la complessit della codifica confrontabile con la complessit della decodifica. Per i codici Raptor, entrambe le complessit scalano linearmente con il volume dei dati che devono essere codificati/decodificati, rendendo i requisiti computazionali globali proporzionali al bit rate del servizio e abbastanza indipendenti dalle perdite o dal livello di protezione. La complessit della codifica Raptor per gli scenari qui considerati nella zona di 2 MIPS (Million Instruction Per Second) per Mbit/s (quindi uno stream a 6 Mbit/s richieder circa 12 MIPS di potenza di calcolo per la codifica, sebbene in pratica il tempo di codifica dipenda anche dalla velocit
I criteri per la valutazione della flessibilit dei codici FEC sono i seguenti:
variazione dinamica delloverhead e/o della dimensione dei blocchi (allinterno o tra i blocchi FEC); gamma di periodi di protezione;
idoneit allutilizzo con una grande variet di strategie di trasmissione FEC. Il codice Raptor fornisce una completa flessibilit in termini di overhead (quantit di protezione) e di dimensione dei blocchi (periodo di protezione). Questi parametri possono essere settati indipendentemente, secondo i requisiti delle applicazioni, inoltre le prestazioni della correzione degli errori del codice rimangono vicine a quelle ideali per ogni settaggio dei parametri. Le impostazioni di tali parametri possono essere cambiate facilmente in modo dinamico e possono essere supportati efficientemente periodi di protezione tra le decine e le migliaia di millisecondi. Per il codice SMPTE 2022-1, il periodo di protezione e la quantit di protezione sono correlati e vincolati e in pratica vengono supportate solo determinate combinazioni.
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.447 mentre il numero di operazioni XOR richiesto per la codifica del bus di memoria e dalla disponibilit di cache/DMA). Per o la decodifica SMPTE 2022-1 per gli stessi scenari di esempio, la Digital Fountain ha costruito un server con unoperazione per ogni simbolo sorgente nel SMPTE 2022-1 processore a 3 GHz che esegue una codifica Raptor a 2 1D e di due operazioni per ogni simbolo sorgente nel Gbit/s, lequivalente di 1000 stream video a 2 Mbit/s. I SMPTE 2022-1 2D. sistemi di elaborazione SMPTE 2022-1 codificano a circa Tuttavia, in pratica, per ogni simbolo queste operazioni 400 Mbit/s e, quindi, prestazioni simili possono essere vengono svolte sul chip (in cache) e quindi il collo di bottiglia facilmente ottenute dai Raptor con requisiti di elaborazione la velocit con cui i dati possono essere spostati tra la modesti. memoria e il processore, piuttosto che il numero preciso di Sono possibili anche ottimizzazioni hardware dei codici operazioni XOR. Tutti i processori moderni utilizzano il Raptor in forma di assistenza hardware per le operazioni pipelining e quindi possono svolgere le operazioni XOR sul XOR o di completa implementazione del codice in hardware chip simultaneamente allo spostamento dei dati per e possono migliorare ulteriormente le capacit. operazioni future tra la memoria esterna al chip e quella Lapplicazione del codice Raptor per lo streaming stata interna al chip. Ci significa che una riduzione nelle progettata in modo che, per un certo rate/latenza dello operazioni XOR non si traduce necessariamente in un stream, la dimensione e la struttura dei blocchi dal punto di aumento significativo della velocit di codifica o di vista del codificatore siano le stesse per ogni blocco. Cos, decodifica. la sequenza di operazioni richieste per codificare i FEC Con i codici Raptor, i requisiti minimi di memoria per la packet per un blocco pu essere calcolata o immagazzinata codifica e la decodifica dei dati al codificatore e al in anticipo ed eseguita velocemente (in software o in decodificatore sono leggermente maggiori della dimensione hardware) per ogni blocco. Questo vero anche nel caso in dei blocchi sorgente. Al decodificatore, i dati ricevuti (che cui la dimensione del blocco (in termini di pacchetti) sono un misto di dati sorgente e dati FEC) possono essere differisca tra i periodi di protezione. trasformati sul posto nei blocchi sorgente recuperati. Il numero di operazioni XOR richiesto per la codifica o la Quindi, questi requisiti di memoria sono inferiori ai 350 KB decodifica Raptor per gli scenari qui considerati si aggira per la dimensione dei blocchi pi grande considerata. intorno alle 12-14 operazioni per ogni simbolo sorgente,
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.448 Con il SMPTE 2022-1, il codificatore ha bisogno solo di 10.4.2.9 Valutazioni sul supporto della avere dei buffer per immagazzinare i FEC packet di un trasmissione a strati blocco di protezione. Dato che la quantit di protezione Tra i criteri di valutazione presente la capacit di sempre inferiore alla quantit di dati, un codificatore SMPTE aggiungere o rimuovere i FEC packet che fa riferimento alla 2022-1 richiede una memoria molto pi piccola della trasmissione a strati dei dati FEC in modo da poter evitare, dimensione dei blocchi sorgente. Al decodificatore, il anche nel caso multicast, la trasmissione di dati FEC non SMPTE 2022-1 richiede solo memoria sufficiente per necessari sulle linee DSL con bassi tassi di perdita di immagazzinare il blocco di protezione corrente e i suoi FEC pacchetti. packet. Questo significa che un decodificatore SMPTE Il codice Raptor in grado di generare un insieme 2022-1 richiede una memoria leggermente pi grande della effettivamente illimitato di FEC packet per qualsiasi dimensione dei blocchi sorgente. dimensione dei blocchi e il costo computazionale A seconda dellordinamento di sequenza usato, il incrementale per la generazione di FEC packet addizionali decodificatore pu aver bisogno di pi memoria. Ad molto basso. I FEC packet del Raptor sono generati da un esempio, quando i FEC packet sono sistemati allinterno del processo pseudo-random, in modo che pacchetti diversi blocco successivo a quello che proteggono, il decodificatore siano essenzialmente equivalenti per il ricevitore in termini ha bisogno del doppio della memoria per immagazzinare il della loro utilit per la decodifica. Quindi, tali pacchetti blocco corrente e quello di protezione successivo. possono essere distribuiti tra i gruppi multicast in un modo Per i decodificatori, questo requisito di memoria ancora arbitrario e i ricevitori possono lasciare o unirsi al gruppo a molto modesto confrontato con la memoria richiesta, ad seconda della quantit di FEC packet di cui necessitano. esempio, per limmagazzinamento di una singola trama Tale meccanismo non pu essere implementato con la dopo decodifica. stessa efficienza e flessibilit usando il codice SMPTE 2022-1, poich in tal caso i FEC packet sono generati in base a una semplice struttura specifica, sono in numero limitato e vengono inviati allo stesso gruppo multicast. I
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.449 difficile da ottenere se bisogna tenere la latenza molto ricevitori che necessitano di tutti i pacchetti di un dato codice bassa. SMPTE 2022-1 per raggiungere le prestazioni di correzione In generale, la protezione combinata pi efficiente della degli errori illustrate in precedenza (ascoltare solo protezione separata e, in particolare, la protezione separata parzialmente una trasmissione condurr a prestazioni dello stream audio a bit rate relativamente basso pu peggiori). risultare estremamente inefficiente. Inoltre la protezione 10.4.2.10 Valutazioni sui criteri aggiuntivi combinata pu racchiudere anche i pacchetti RTCP che forniscono linformazione di sincronizzazione tra gli stream I criteri seguenti sono inclusi nel documento dei criteri di audio e video. valutazione:
funzionamento continuo dei prodotti STB esistenti in presenza di dati FEC; possibilit per i nuovi prodotti STB di usare o ignorare i dati FEC;
10.4.2.11 Valutazioni su applicazioni di content download Per le applicazioni content download esistono molte soluzioni differenti. Nel caso multicast, le soluzioni basate su FEC presentano vantaggi significativi rispetto alle altre. Il codice Raptor proposto per le applicazioni di streaming DVB-IPI adeguato anche per le applicazioni content download (ed stato adottato per tali applicazioni dal 3GPP e dal DVB CBMS). Lo stesso codice pu quindi essere usato sia per lo streaming che per il content download. Non disponibile alcuna descrizione sulla modalit e sulla possibilit che il codice SMPTE 2022-1 possa essere applicato al content download: questo codice stato chiaramente sviluppato per i servizi di streaming solo nei
supporto per la protezione combinata di stream differenti (per esempio, quando i pacchetti audio e video vengono inviati in due stream separati). Il Raptor compatibile con tutti questi criteri. Il FEC SMPTE 2022-1 compatibile con i primi due criteri e ritenuto compatibile anche con il terzo. Il codice SMPTE 2022-1 non supporta la protezione combinata di stream differenti (sono necessari stream di protezione separati per ogni flusso RTP). Nel caso di stream audio in particolare, che hanno molta meno larghezza di banda degli stream video, la protezione di alta qualit sar estremamente
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.450 rosso identifica il risultato peggiore. Quando il risultato tra i casi di perdita dei pacchetti estremamente bassa. Il codice due codici molto vicino, viene utilizzato un carattere SMPTE 2022-1 per natura un codice a blocchi corti e per il arancione per identificare il codice che si comporta in modo content download molto pi efficiente un codice a blocchi leggermente peggiore. grandi se deve essere usato il FEC. 10.4.2.12 Sintesi sul confronto tra Raptor e SMPTE 2022-1 La Tabella 10-4 riassume i risultati finora descritti. Il carattere verde indica il risultato migliore, mentre quello
Criteri Costo di banda tassi di perdita >~ 10 - broadcast SD MPEG-2 TS (400ms) - broadcast HD MPEG-2 TS (400ms) - unicast SD MPEG-2 TS (100ms)
-4
SMPTE 2022-1 costante Alto Alto Alto
SMPTE 2022-1 a burst Alto Alto Alto
Raptor
Commenti
Basso Basso Basso Grazie al meccanismo di faststart, il Raptor ha un overhead molto basso in caso di contenuto immagazzinato/bufferizzato Grazie al meccanismo di faststart, il Raptor ha un overhead molto basso in caso di contenuto immagazzinato/bufferizzato
- unicast HD MPEG-2 TS (100ms) Costo di banda tassi di perdita <~ 10-4 - broadcast SD MPEG-2 TS (400ms) - broadcast HD MPEG-2 TS (400ms)
Alto
Alto
Basso
Basso Basso
Pi basso Pi basso
Basso Basso
Criteri SMPTE 2022-1 costante Modesto SMPTE 2022-1 a burst Pi basso Raptor Commenti Grazie al meccanismo di faststart, il Raptor ha un overhead molto basso in caso di contenuto immagazzinato/bufferizzato Grazie al meccanismo di faststart, il Raptor ha un overhead molto basso in caso di contenuto immagazzinato/bufferizzato Il SMPTE 2022-1 non potrebbe fornire un tempo medio tra le perdite dei pacchetti di quattro ore per un numero di casi di perdita a burst. Tuttavia, potrebbe essere ottenuto un obiettivo leggermente pi debole di tempo medio tra gli artefatti (errori visibili) di quattro ore
- unicast SD MPEG-2 TS (100ms)
Basso
- unicast HD MPEG-2 TS (100ms)
Modesto
Pi basso
Basso
Supporto della qualit target per il range/modelli della perdita dei pacchetti stimati
Vedi commento
Perdite ulteriori di pacchetti che potrebbero avvenire nella rete core a causa della congestione e/o dellambiente domestico (per esempio tecnologie wireless)
Non ancora valutato
S (ma un numero fisso di Settaggio flessibile dei parametri del combinazioni e correlazione S (del codice diretta tra overhead e dimensione tutto) del blocco di protezione) Complessit computazionale Pi bassa Modesta Scalabilit (per esempio, codifica di S S migliaia di stream)
Criteri Esigenze di memoria (codificatore) Esigenze di memoria (decodificatore) Visibilit degli artefatti dopo decodifica FEC Funzionamento continuo dei prodotti STB esistenti in presenza di dati FEC Possibilit per i nuovi prodotti STB di usare o ignorare i dati FEC Conferma dellIPR dello schema FEC compatibile con le regole del DVB Supporto efficiente dellincapsulamento diretto di audio/video in RTP (come definito nel TS 102 005): supporto per la protezione combinata di pacchetti audio e video Supporto efficiente dellincapsulamento diretto audio/video in RTP (come definito nel TS 102 005): supporto per pacchetti di lunghezza variabile Idoneit per il servizio Content Download SMPTE 2022-1 SMPTE 2022-1 Raptor costante a burst Pi bassa Modesta Modesta Modesta S S S S S S La compatibilit SMPTE 2022-1 IPR attualmente in fase di elaborazione da parte del SMPTE I Raptor possono proteggere molti stream RTP e RTCP insieme mentre il SMPTE 2022-1 deve considerare ogni stream RTP e RTCP separatamente Commenti
Entrambi i codici possono svolgere correzione parziale
No
S (meno efficiente)
No (molto meno efficiente)
Tabella 10-4: Confronto tra Raptor e SMPTE 2022-1 Quindi lordinamento di trasmissione scelto ha un impatto significativo sulle prestazioni e sul costo di banda. Il confronto tra i due codici differisce anche in base al tasso di perdita dei pacchetti. Nel caso venga usata la trasmissione a
di Elena Mammi, Giuseppe Russo, Paolo Talone pag. IX.453 decoder esistenti. Il codice Raptor supporta diversi requisiti burst e per tassi di perdita sotto una certa soglia (tra 5*10-5 e -4 futuri che il SMPTE 2022-1 non supporta. 2*10 ), il codice SMPTE 2022-1 richiede leggermente meno Dal momento che nessuno dei due codici ottimale in tutti i banda del codice Raptor. Nel caso non venga usata la casi, stato definito un codice ibrido con prestazioni simili trasmissione a burst e per tassi di perdita sotto una certa alle migliori prestazioni di entrambi i codici. soglia (tra 5*10-5 e 2*10-4), sia il codice SMPTE 2022-1 che quello Raptor richiedono un overhead di banda simile, 10.4.2.13 Il codice ibrido sebbene vi siano differenze a seconda del caso specifico. -5 Per tassi di perdita sopra una certa soglia (tra 5*10 e stato proposto un codice ibrido tra il codice SMPTE 2*10-4), il codice Raptor richiede molte meno banda del 2022-1 1D per colonne e il codice Raptor, per fornire una codice SMPTE 2022-1. La soglia identificata attraverso singola soluzione FEC scalabile con prestazioni simili alle queste simulazioni dipende dallobiettivo di qualit, dal bit migliori prestazioni di entrambi i codici in tutti i casi. Questo rate dello stream sorgente, dal budget di latenza e dai paragrafo presenta i risultati ottenuti per questo codice modelli di perdita. Quando viene usato il meccanismo di ibrido. Nei grafici seguenti, i casi ibridi sono indicati con la faststart dei Raptor per il contenuto unicast/bufferizzato, il dicitura Raptor P<n>, dove <n> il numero dei pacchetti di Raptor richiede meno overhead del SMPTE 2022-1. Per parit utilizzati. Il valore di <n> scelto in ogni caso il pi quanto riguarda gli aspetti di implementazione (complessit, piccolo tale che lobiettivo di qualit possa essere ottenuto esigenze di memoria e altro), sebbene vi siano differenze tra con i soli pacchetti SMPTE per tassi di perdita di 10-5 e i codici, non sono stati identificati problemi significativi per inferiori. Come si vede dai grafici seguenti il codice ibrido nessuno dei due codici. Entrambi i codici soddisfano il proposto da DVB raggiunge lobiettivo di fornire una singola requisito di compatibilit allindietro attrezzature verso i soluzione FEC scalabile con prestazioni simili alle migliori prestazioni di entrambi i codici in tutti i casi.

Sez IX

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sez IX

Caricato da

Copyright:

Formati disponibili

pag. IX.

La diffusione televisiva su Internet: architetture e tecnologie

Sezione IX: Qualit del Servizio

di Elena Mammi, Giuseppe Russo, Paolo Talone

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;

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

Le metriche dovrebbero essere specificate con le seguenti informazioni ancillary:

9.2.3.2 Accuratezza delle metriche

Definizione Metriche riguardanti la qualit della trasmissione

intero 16 bit senza segno

intero 16 bit senza segno

intero 16 bit senza segno

intero 16 bit senza segno

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

intero 32 bit senza segno

intero 32 bit senza segno

intero 32 bit senza segno

intero 16 bit senza segno

intero 16 bit senza segno

intero 16 bit senza segno intero 16 bit senza segno

16 bit senza segno (millisecondi)

Channel Change Delay [tempo]

intero 16 bit senza segno

ITF OS Boot Time [tempo]

ITF Service Boot Time [tempo]

Tabella 9-5: Metriche consigliate dall'ATIS

ogni meccanismo di protezione a livello applicativo dal lato utente;

< 200 ms < 200 ms < 200 ms

< 50 ms < 50 ms < 50 ms

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

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

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

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

< 200 ms < 200 ms < 200 ms

< 50 ms < 50 ms < 50 ms

alcuni meccanismi possono essere combinati meglio con altre funzioni;

10.2 Raptor Code

{0,1, 2,..., q 1} si ha un probabilit 1 f , e una f . La

di trasmettere linput senza errore pari a probabilit di consegnare loutput

dimensione q dellalfabeto pari a 2 , dove I il numero di bit in un pacchetto.

(1 f ) * I bit, con o senza feedback. A questo rate

K del file originale, lintero file pu essere recuperato.

( s1 , s2 ,, sK ) ; in questo caso, un pacchetto

K bit definisca una nuova colonna in una matrice binaria

G pu essere generata da un generatore di numeri casuali

Figura 10-6: Matrice generatrice di un codice lineare casuale

2), il ricevitore pu calcolare linversa Gaussiana, e recuperare:

K x K invertibile. Tale probabilit viene

indicata con 1 , dove

la probabilit che il ricevitore

La probabilit che una matrice binaria di dimensioni

rispetto ad E per il caso in cui

) , la probabilit che la prima colonna di

G non sia composta da tutti zeri. Il secondo fattore,

) , la probabilit che la seconda colonna di G

che pari a 0,289 per ogni K maggiore di dieci.

E pacchetti aumenta la probabilit di E successo ad almeno (1 ) , con = 2 . Allora,

K 3 operazioni binarie, e del costo dellapplicazione

Ogni pacchetto codificato

tn prodotto dal file sorgente

G la matrice associata al grafo (proprio come nel codice a