TECNICHE DI ERROR RESILIENCE PER VIDEOCOMUNICAZIONI REAL-TIME IN AMBIENTE UMTS A COMMUTAZIONE DI PACCHETTO

Transcript

1 UNIVERSITÀ DEGLI STUDI DI ROMA La Sapienza FACOLTÀ DI INGEGNERIA TESI DI LAUREA IN INGEGNERIA DELLE TELECOMUNICAZIONI TECNICHE DI ERROR RESILIENCE PER VIDEOCOMUNICAZIONI REAL-TIME IN AMBIENTE UMTS A COMMUTAZIONE DI PACCHETTO Materia: Teoria dei Segnali RELATORE CH.MO PROF. ROBERTO CUSANI LAUREANDO LUCA CAMPANELLI ANNO ACCADEMICO 2002/2003

2 Sommario 1 Introduzione alle videocomunicazioni in ambiente UMTS L evoluzione delle reti mobili Third Generation Partnership Project (3GPP) Obiettivi della tesi Modalità di trasporto Vantaggi dell architettura a commutazione di pacchetto Le classi di servizio Architettura a commutazione di circuito: 3G-H.324M Il protocollo H Il protocollo H Il codificatore AMR (Adaptive Multi Rate) Il coder H Architettura a commutazione di pacchetto 12 2 Implementazione del codec video H Introduzione La raccomandazione ITU-T H Immagini in ingresso e tipi di codifica La codifica Intra La codifica INTER Tecnica del block matching Struttura del bitstream Controllo di flusso Algoritmo di flow-control Frame Skipping 33 3 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Impacchettamento del flusso H.263 in RTP 37

3 3.1.1 Modi di impacchettamento del flusso H.263 in RTP Selezione dei modi per l intestazione del Payload H Il protocollo UDP IP 47 4 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e Strato 2 (PDCP, RLC, MAC) Il sottostrato PDCP Il sottostrato RLC Il sottostrato MAC Lo strato fisico Canali fisici dedicati in uplink e downlink 61 5 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Introduzione Uplink power control per i canali DPCCH e DPDCH Downlink power control per i canali DPCCH e DPDCH Comportamento del terminale Comportamento dell UTRAN 71 6 Effetti di errori sul canale e tecniche di error resilience implementate Introduzione Effetti degli errori sul flusso video Error Resilience Tools in H Error resilience nei quadri codificati INTRA Error resilience nei quadri codificati INTER Occupazione di banda e qualità Prestazioni delle tecniche implementate Cenni sulle tecniche di error concealment 91 Conclusioni e sviluppi futuri 95 BIBLIOGRAFIA 97

4 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 1 Introduzione alle videocomunicazioni in ambiente UMTS 1.1 L evoluzione delle reti mobili Negli ultimi 20 anni lo sviluppo delle reti mobili ha attraversato tre generazioni: la prima, agli inizi degli anni ottanta (es. TACS), supportava servizi voce tradizionali (Legacy Services). La seconda (2G), a partire dagli anni novanta, affiancava all erogazione del servizio telefonico la fornitura di servizi dati. La rete prevalente di seconda generazione è il Global System for Mobile Communication (GSM). Poiché le reti GSM sono concepite per offrire servizi vocali basati sulla commutazione di circuito (Circuit Switching- CS ) e permettono la trasmissione dati solo a basso bit rate, mal si prestano alla fornitura di servizi quali Internet, basati sulla commutazione di pacchetto (Packet Switching- PS ). Negli ultimi anni, la tecnologia General Packet Radio Service (GPRS) è stata integrata alla rete GSM per il supporto di servizi a commutazione di pacchetto; la rete GPRS è definita di 2.5G. L UMTS rappresenta l evoluzione delle reti GSM/GPRS verso la fornitura di servizi di videocomunicazione real-time, Internet e applicazioni dati a banda larga. Il sistema 1

5 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 UMTS è stato definito dal 3 rd generation Partnership Project (3GPP), un associazione di organi di standardizzazione, tra cui l ETSI (European Telecommunication Standards Institute) e l ARIB (Association of Radio Industry Businesses). Il processo di standardizzazione dell UMTS è progredito seguendo più fasi: la prima, nota come Release 99 (R99), definisce i domini fondamentali per la fornitura di servizi CS e PS; la seconda, detta Release 4 (R4), aggiunge nuovi servizi e definisce la separazione tra controllo e trasporto (bearer); la terza, Release 5 (R5) introduce il dominio IMS (IP Multimedia Subsystem), per la fornitura di servizi multimediali a commutazione di pacchetto; la quarta, Release 6 (R6) è attualmente in evoluzione Third Generation Partnership Project (3GPP) Il 3 rd Generation Partnership Project (3GPP) è un progetto di collaborazione tra alcuni enti di standardizzazione, quali ETSI (European Telecommunication Standard Institute), ARIB (Association of Radio Industries and Business), TTA (Telecommunication Technology Association), CWTS (China Wireless Telecommunication Standard Group) e TTC (Telecommunication Technology commettee). L obiettivo principale del 3GPP è il coordinamento dello sviluppo delle specifiche tecniche (Technical Specification) e dei report (Technical Report) per il sistema radiomobile di terza generazione. La gestione del progetto è diretta dal Project Coordination Group (PCG), costituito da cinque Technical Specification Group (TSG), ognuno dei quali è formato al suo interno dai vari Working Group (WG): Services and System Aspects (SA) Core Network (CN) 2

6 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 Terminals (T) GSM EDGE Radio Access Network (GERAN) Radio Access Network (RAN) Obiettivi della tesi Nel presente lavoro di tesi vengono trattate tecniche di error resilience per videocomunicazioni in ambiente UMTS. È da sottolineare che attualmente la videochiamata e le comunicazioni voce sono gli unici servizi UMTS ad essere offerti mediante rete a commutazione di circuito. L obiettivo nel medio termine è quello di erogare tutti i servizi su reti a commutazione di pacchetto. Dopo una breve introduzione generale sul sistema UMTS e sulle sue classi di servizio, si darà una breve descrizione dell attuale architettura e dei relativi protocolli (CAP. 1). Successivamente saranno descritti il codec video implementato durante la tesi (CAP.2), la pila protocollare considerata (CAP. 3), e l architettura di rete dell interfaccia radio UMTS (CAP. 4). Si tratterà poi il controllo di potenza dell UMTS (CAP. 5), di fondamentale importanza, in quanto l obiettivo del presente lavoro è stato quello di raggiungere un trade-off tra il livello dell erogazione di potenza, e la qualità del video decodificato. Infine si mostrerà come le tecniche di error resilience implementate (CAP. 6) permettano una diminuzione della potenza in trasmissione, lasciando invariata la qualità del video. 3

7 Introduzione alle videocomunicazioni in ambiente UMTS Cap Modalità di trasporto Le architetture di rete si differenziano a seconda della modalità di commutazione adottata. In particolare il trasporto del flusso multimediale può avvenire secondo due modalità: commutazione di circuito. commutazione di pacchetto. Nel primo caso si stabilisce una connessione su un circuito virtuale dedicato, che soddisfi a caratteristiche di banda e QoS (Qualità of Service) negoziate all atto dell instaurazione della connessione stessa. Nel secondo scenario si ha una trasmissione connectionless e il flusso di dati è suddiviso in pacchetti che vengono instradati in maniera del tutto indipendente l uno dall altro. A seconda dei protocolli della pila protocollare sarà possibile garantire o meno l ordine di consegna dei pacchetti, operazione che richiede un compromesso con i vincoli temporali cui il flusso deve soddisfare. L attuale servizio di comunicazioni video real-time in ambiente UMTS sfrutta la modalità a commutazione di circuito, mentre per il futuro è previsto il passaggio ad una architettura a commutazione di pacchetto. Il prossimo paragrafo fornirà una panoramica sullo scenario attuale di funzionamento del servizio a circuito per poi passare ad approfondire gli aspetti legati al futuro scenario a pacchetto. 4

8 Introduzione alle videocomunicazioni in ambiente UMTS Cap Vantaggi dell architettura a commutazione di pacchetto In futuro la fornitura di servizi multimediali che combinano voce, video e accesso ad Internet, sarà interamente basata su un trasporto a commutazione di pacchetto, quindi su reti IP. La presenza di servizi ad alta flessibilità in un ambiente che prevede l interoperabilità tra reti di diverso tipo (UMTS, GSM/GPRS e reti IP) ha portato alla definizione dell IMS, acronimo di IP Multimedia Subsystem come nuovo dominio per la definizione di scenari di servizio innovativi e per la convergenza di dati e voce in un unica infrastruttura di rete ( Converged network ). Il sottosistema IMS è interamente basato su IP per il livello di trasporto e SIP (Session Initiation Protocol) è il protocollo di segnalazione scelto dal 3GPP per il controllo della sessione. Le motivazioni e i benefici alla base della Converged network sono: Riduzione dei costi dell infrastruttura: la realizzazione della converged network comporterà infatti l abbandono dell attuale dominio a commutazione di circuito, con una conseguente diminuzione dei capitali investiti dagli operatori mobili. Il passaggio ad un dominio basato su tecnologia IP, quindi a commutazione di pacchetto, implicherà costi minori rispetto agli elementi delle reti telefoniche classiche. Minori costi di manutenzione: la scelta di una rete IP based determina una riduzione dei costi operativi e di manutenzione, grazie ad una più semplice gestione degli apparati di rete, se paragonata alle componenti dell attuale rete telefonica. Inoltre gli operatori non dovranno investire nello sviluppo di competenze per tecnologie multiple, in quanto la Converged Network utilizza un unica tipologia di rete per la segnalazione e il trasporto. 5

9 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 Servizi innovativi: l integrazione di voce e dati offre l opportunità di sviluppare servizi innovativi, detti Enhanced Services Le classi di servizio L ampia gamma di servizi erogabili sulla rete UMTS, ha reso necessaria la definizione di quattro classi di servizio che si distinguono per le differenti specifiche di qualità di servizio (QoS): 1. Conversational class: si riferisce al trasporto di traffico real-time. Tra i servizi tipici di questa classe sono inclusi quello voce e di videochiamata. La caratteristica principale della conversational class è un ritardo di trasferimento che deve essere mantenuto entro i 100ms, in considerazione dei tempi di percezione umana delle immagini e della voce. Inoltre il suddetto ritardo deve avere delle variazioni contenute ed è necessario il mantenimento del sincronismo tra i diversi flussi mediali (nel caso di trasferimento di un flusso multimediale). 2. Streaming class: si riferisce al trasporto di traffico unidirezionale sia audio che video. Come la conversational, la streaming class è caratterizzata dal mantenimento delle relazioni temporali tra le varie entità che compongono il flusso e da una limitata variazione del ritardo di trasferimento. Quest ultimo deve essere contenuto entro i 250ms. 3. Interactive class: si riferisce all interazione fra un utente (un umano o una macchina) e un apparato remoto. Esempi di interazione che coinvolgono l uomo sono il web browsing, l accesso ad un server di rete oppure la ricerca all interno di un database. Un 6

10 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 esempio di interazione di una macchina con l apparato remoto è l interrogazione automatica di un data base. Questa classe prevede che vi sia sempre una risposta dell apparato remoto ad un eventuale richiesta dell utente, che il roud trip delay sia contenuto entro tempi ragionevoli e che il flusso di dati sia soggetto ad un basso tasso d errore. 4. Background class: si riferisce al trasferimento di dati in background. Esempi di servizi in background sono la consegna di , la spedizione di SMS, il download di un file. È la classe meno stringente dal punto di vita dei vincoli temporali. Per il ritardo di trasferimento infatti, non è esplicitato alcun limite in quanto l utente non ha la necessità di ricevere i dati in tempo reale. D altra parte la background class richiede la massima affidabilità e sicurezza della trasmissione nonché l assoluta integrità del flusso di dati. È evidente che il principale fattore di distinzione tra le classi di servizio è la sensibilità al ritardo di trasferimento: si passa dalla conversational class, molto sensibile al ritardo, alla background class, che non presenta requisiti espliciti in termini di ritardo. Inoltre mentre le prime due classi ben si prestano al trasporto di traffico in tempo reale, le ultime due sono pensate per applicazioni quali Internet o servizi di messaggistica. Il presente lavoro ha avuto come oggetto di studio le videocomunicazioni real time in ambiente UMTS. Quindi si è fatto riferimento alle specifiche della conversational class per quanto concerne la QoS. La necessità di mantenere il ritardo end-to-end entro i 100 ms impedisce l utilizzo di un canale di ritorno per chiedere la ritrasmissione di dati errati. Come mostrato anche nel cap. 4, si opera in modalità FEC, e non ARQ. 7

11 Introduzione alle videocomunicazioni in ambiente UMTS Cap Architettura a commutazione di circuito: 3G-H.324M La raccomandazione ITU-T H.324 definisce un insieme di standard per la trasmissione di dati e flussi multimediali a basso bit-rate su reti a commutazione di circuito. H.324M modifica leggermente H.324, e descrive gli standard per la trasmissione su reti mobili. Sulla base delle raccomandazioni ITU-T, 3GPP ha deciso l utilizzo, per i terminali di terza generazione operanti in reti a circuito, dello standard 3G-H.324M, descritto in 3GPP TS L architettura è mostrata in figura 1.1. Video I/O Equipment Audio I/O Equipment Video Codec H.263, [MPEG-4, H.261 ] Speech Codec 3GPP-AMR, [G ] Optional Receive Path Delay Multiplex/ Demultiplex H.223, H.223 Annex A, H.223 Annex B, [H.223 Annex C, H.223 Annex D] Optional Multilink H.324 Anne x H 3GPP Network User Data Applications [T.120, ] Data Protocols [V.14, LAPM, ] System Control H.245 CCSRL NSRP[LAP M/V.42] Call Set -up Figura 1.1: architettura protocollare dello standard 3G-H.324M I terminali 3G-324M (per reti mobili) si basano su H.324 Annex C (noto come H.324M), e Annex H se è supportata l operazione di mobile multilink. Le modifiche apportate da 3GPP rispetto a H.324M sono riportate in 3GPP TS

12 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 L architettura base di H.324 consiste di un multiplexer che miscela tra di loro i vari tipi di flussi mediali in un unico bitstream (protocollo H.223), di algoritmi di compressione audio e video (AMR e H.263) e di un protocollo di controllo che esegue automaticamente la negoziazione della capacità e l assegnazione dei canali logici (H.245). Limitando la presente analisi alla co-decodifica e trasmissione di flussi multimediali in ambiente UMTS, è possibile considerare lo schema semplificato di figura 1.2. Vengono considerati come codec video H.263/H.263+ e AMR (Adaptive Multi Rate) come codec audio (prescelto dal 3GPP). H.245 H.263 AMR Adaption Layer Multiplex Layer H.223 3GPP Network Figura 1.2: schema semplificato dello standard 3G-H.324M Il protocollo H.223 H.223 descrive il protocollo di multiplazione usato nei terminali H.324. E orientato al pacchetto, e ogni pacchetto può contenere un sottoinsieme di LC (Logical Channel), fino ad un massimo di Ogni LC rappresenta un singolo media, o un canale di controllo. LC 0 è riservato ai messaggi di controllo di H.245 9

13 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 Il protocollo H.223 è suddiviso in 2 strati, Adaptation Layer, e Multiplex Layer. Il trasferimento dei dati del Multiplex Layer avviene per mezzo di MUX-PDU. Una tabella di multiplazione descrive a quale LC sono allocati i singoli ottetti di ogni PDU. Gli errori nelle MUX-PDU sono controllati con il campo HEC nell header delle MUX- PDU. Sopra a ML si trova l Adaptation Layer, che può essere di 3 tipi: 1. AL1, per le informazioni di controllo. Non fornisce controllo di errore. 2. AL2, per il trasferimento del flusso audio. Le AL2-PDU contengono 1 ottetto per CRC e 1 ottetto opzionale per il sequence number. 3. AL3, per il trasferimento del flusso video. Le AL3-PDU contenngono 2 ottetti per CRC, e 1 o 2 ottetti opzionali di controllo. AL3 consente una ritrasmissione limitata. Per l utilizzo in reti wireless, sono stati definiti 4 annexes, creando 4 livelli di rivelazione e correzione di errore Il protocollo H.245 H.245 specifica sintassi e semantica dei messaggi di controllo end-to-end, e le procedure per il loro uso. E usato, principalmente, per l apertura e chiusura di canali logici, capabilities exchange, trasmissione della tabella di multiplazione H.223. Solo un sottoinsieme di tutti i messaggi H.245 sono usati nei terminali 3G-H.324M. I messaggi appartengono a 4 categorie: 1. Richiesta (richiede una risposta) 2. Risposta (in seguito a una richiesta) 3. Comando (richiede una azione) 4. Indicazione (solo informativo) 10

14 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 I messaggi H.245 sono trasportati sul canale logico LC 0, aperto all inizio della comunicazione e che rimane attivo fino alla fine del collegamento end-to-end. Considerate le caratteristiche del mux H.223, la banda per i messaggi H.245 è allocata a seconda della necessità. Poiché la maggior parte del traffico si ha all inizio e alla fine della sessione, questo scelta permette di fornire una maggiore larghezza di banda per i flussi video e audio. Il controllo d errore non è supportato Il codificatore AMR (Adaptive Multi Rate) Il codec AMR supporta bit-rate di 12.2, 10.2, 7.95, 7.40, 6.70, 5.90, 5.15 e 4.75 kbit/s. Il codificatore opera su frame di 20 ms, corrispondenti a 160 campioni alla frequenza di campionamento di 8000 campioni al secondo. Lo schema per la codifica multi-rate è detto ACELP (Algebraic Code Excited Linear Prediction Coder), il coder è noto come MR-ACELP. Ogni 10 campioni, il segnale vocale è analizzato e vengono ricavati, codificati e trasmessi i parametri del modello CELP. Il decodificatore, ricevuti i parametri, è in grado di ricostruire una stima del segnale vocale. Il protocollo AMR effettua error concealment, mediante frame substitution, e manda a 0 l output, in caso di errori non recuperabili, in modo da evitare suoni fastidiosi Il coder H.263 Il codec H.263 (e anche la versione successiva H.263+) è adatto a fornire una buona compressione video in ambienti a basso bitrate. La codifica fa uso di quadri di tipo INTRA e INTER con tecniche di motocompensazione. E' possibile regolare la qualità del video per rimanere nella banda prevista. Diverse opzioni supplementari (4 per H.263, 12 per H.263+) permettono di ottenere una migliore qualità, o un flusso robusto 11

15 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 a errori introdotti nel canale radiomobile. Il 3GPP ha scelto come mandataria la versione base dell H.263. L H.263 verrà descritto nel dettaglio nel seguito della trattazione. 1.4 Architettura a commutazione di pacchetto Lo scenario futuro del servizio di videocomunicazione in ambiente UMTS prevede l erogazione del servizio tramite un architettura a commutazione di pacchetto. Quindi ci si riferisce ad una trasmissione connectionless, con i singoli flussi mediali incapsulati in pacchetti che vengono instradati indipendentemente l uno dall altro. In questo contesto, l architettura protocollare di riferimento definita in ambito 3GPP risulta notevolmente differente rispetto a quella relativa all ambiente a commutazione di circuito (figura 1.3). H.263 RTP UDP IP RLC/PDCP MAC Physical Layer Figura 1.3: architettura protocollare per videocomunicazioni a commutazione di 12

16 Introduzione alle videocomunicazioni in ambiente UMTS Cap.1 In particolare sono presenti i seguenti strati aggiuntivi rispetto al caso a circuito: RTP (Real-Time Transport Protocol); UDP (User Datagram Protocol); IP (Internet Protocol); PDCP (Packet Data Convergence Protocol) nel layer 2. Al di sotto di essi ci saranno i sottostrati RLC e MAC nello strato 2, e infine il Physical Layer. I flussi uscenti dai rispettivi coder, vengono incapsulati nelle PDU dei vari strati citati, con un conseguente aumento dell overhead (dovuto ai campi delle intestazioni protocollari) che causa una limitazione della banda effettiva disponibile per l informazione d utente. Questo aspetto è gestito dal protocollo PDCP, presente solo nel piano d utente ed necessario solo nel dominio a pacchetto, che ammette metodi di compressione dell header. Indipendentemente dalle lunghezze dei pacchetti, i vari protocolli inseriranno i seguenti header fissi: RTP UDP IPv4 (Ipv6) 12 byte; 8 byte; 20 byte (40 byte); I protocolli introdotti verranno descritti nel dettaglio nei capitoli successivi. 13

17 Implementazione del codec video H.263 Cap2 2 Implementazione del codec video H Introduzione In questo capitolo verranno trattate le parti dello standard ITU-T H.263 implementate durante lo svolgimento del presente lavoro (tramite la programmazione del co-decodificatore). Con la crescita dell esigenza di comunicazioni video è cresciuto l interesse per lo sviluppo di tecniche di video compressione. Tra i vari standard che si sono imposti per le modalità di trasferimento di contenuti video, il 3GPP ha previsto l utilizzo dei codec video H.263 (mandatario) e MPEG-4 (opzionale), particolarmente indicati per le trasmissioni video a basso bit rate, poiché garantiscono buone prestazioni sia dal punto di vista dell efficienza di compressione sia dal punto di vista della robustezza all errore. Lo studio proposto si concentra sull H.263, in quanto codec obbligatorio da supportare per le videochiamate UMTS. 14

18 Implementazione del codec video H.263 Cap2 2.2 La raccomandazione ITU-T H.263 Il codec H.263 è stato standardizzato nel 1996 ed ha subito degli aggiornamenti alle versioni 2 e 3 rispettivamente nel 1998 e nel La raccomandazione riguardante lo standard specifica completamente la struttura e il comportamento del decodificatore, la sintassi e l organizzazione del bitstream. A causa della molteplicità di opzioni selezionabili sono definiti diversi profili in base alle modalità di utilizzo del servizio video, e livelli, che specificano la complessità minima che deve essere garantita dal decodificatore. Il profilo 0 (baseline) è incluso come mandatario in tutte le applicazioni UMTS che implichino il trasferimento di dati video, non utilizza opzioni avanzate di codifica, ma fornisce all interno della flusso codificata (bitstream) alcuni punti di risincronizzazione al fine di garantire il recupero del sincronismo. In presenza di errori in trasmissione questi marker, che per lo più sono degli header che identificano porzioni specifiche del flusso video, possono essere non individuati dal decodificatore. Per evitare questi problemi sono state studiate tecniche di error resilience che verranno trattate nel seguito e che rappresentano il fulcro del presente lavoro. Lo standard H.263 è stata realizzato per videofonia o videoconferenza; in queste applicazioni si ha a che fare con bassi frame rate e si lavora con immagini di piccolo formato, generalmente QCIF (Quarte of Common Intermediate Format) caratterizzato da 144x176 pixel, e con bit rate in trasmissione attorno ai 64 Kbps. Le raccomandazioni ITU-T precisano le tecniche di codifica e decodifica da usare e l organizzazione dei dati compressi, ma alle varie implementazioni viene lasciata ampia libertà su come realizzare i blocchi logici previsti e sulle operazioni da eseguire per realizzare una funzione raccomandata. Nel 1995 è stata emanata la raccomandazione ITU-T H.263 il cui algoritmo di codifica si basa sulla precedente raccomandazione ITU- T H

19 Implementazione del codec video H.263 Cap2 Figura 2.4: schema a blocchi del codificatore H Immagini in ingresso e tipi di codifica Il codificatore H.263 (figura 2.1) lavora su sequenze video non interallacciate di frame rate variabile. Ogni immagine in ingresso è rappresentabile come una matrice Y (di 144 linee e 176 colonne per il formato QCIF) per le componente di luminanza e due matrici U e V per le componenti di crominanza. Queste componenti rappresentano i valori campionati dell immagine originale come definito nella raccomandazione 601 del CCIR. Sono previsti cinque formati standardizzati per le immagini in ingresso: sub- QCIF, QCIF, CIF, 4CIF, 16CIF. Per ciascuno di questi formati la struttura del campionamento della luminanza, in pixel per linea e linee per figura, è di tipo ortogonale. Se la matrice di luminanza ha M pixel per linea e N linee, le matrici delle due crominanze hanno M/2 pixel e N/2 linee per figura, sempre ottenute con un campionamento di tipo ortogonale (campionamento 4:2:0). Le matrici Y, U e V della 16

20 Implementazione del codec video H.263 Cap2 sequenza vengono divise in blocchi non sovrapposti di 8x8 pixel. Quattro blocchi di luminanza sono raggruppati e formano i macroblocchi come indicato in figura 2.2. Ad un macroblocco, in ordine con il sottocampionamento, appartiene un blocco 8x8 di ciascuna matrice di crominanza. L H.263 prevede che una fila di macroblocchi (per il formato QCIF) formi il cosiddetto gruppo di blocchi (GOB). Figura 2.5: Struttura di un immagine: GOB, macroblocchi e blocchi 17

21 Implementazione del codec video H.263 Cap2 Nella codifica di un immagine si procede per macroblocchi, da sinistra verso destra all interno di una GOB. Questo procedimento è chiamato scansione raster per macroblocchi. L H.263 distingue tre tipi di quadri a seconda del metodo di codifica usato: Intra (frame I) Nella codifica viene rimossa solo la ridondanza spaziale, esattamente come se fosse un immagine fissa. Predetta (frame P) La codifica INTER si basa sulla predizione del frame attuale dalla codifica del frame (I o P) precedente, al fine di eliminare la ridondanza temporale. Per questo motivo il rapporto di compressione di un frame P è maggiore di quello di un frame I. Interpolata (frame P-B). La codifica PB si basa, analogamente al frame P, sulla predizione. Il frame B viene codificato riferendosi al frame (I o P) precedente e al frame P seguente. Questo modo di codifica non appartiene alla versione baseline. Per rispettare le caratteristiche tecniche della videochiamata UMTS, descritte nei capitoli seguenti, sono state effettuate alcune scelte sulle caratteristiche delle sequenze in ingresso e del codificatore: Sequenze di formato QCIF, a 16 fps Coder H.263 profile 0 1 frame I e 15 frame P per ogni GOP (Group Of Pictures) codifica a kbps 18

22 Implementazione del codec video H.263 Cap2 2.4 La codifica Intra Le sequenze da codificare sono caratterizzate da un elevata ridondanza spaziale (pixel vicini nello spazio hanno caratteristiche simili) e temporale (quadri vicini in tempo sono molto simili). La codifica di tipo INTRA elimina la ridondanza spaziale, ma non quella temporale. In questo modo un quadro INTRA è indipendente dai quadri precedenti, e può essere considerato un punto di riferimento nella sequenza (key frame). La codifica di un quadro INTRA si avvale di tecniche block based, cioè che agiscono indipendentemente su ciascun blocco di 8x8 pixel. La codifica INTRA di un quadro si compone di diverse operazioni: 1. viene calcolata la trasformata DCT (Discrete Cosine Transform) bidimensionale di ogni blocco 8x8: il passaggio dal dominio spaziale a quello trasformato è il primo passo per l eliminazione della ridondanza spaziale: l occhio umano è più sensibile alle basse frequenze spaziali che non a quelle più elevate. La DCT consente di separare il contenuto di potenza di ogni frequenza spaziale dell immagine. La componente C m,n della DCT bidimensionale di un blocco 8x8 è espressa dalla formula (2 + 1) (2 + 1), = ( ) ( ) π i m π j n Cm n α m β n Bi, j cos cos, 0 m,n 7 i= dove α ( 0) = β (0) = e 8 1 α ( m) = β ( n) =, 1 m,n

23 Implementazione del codec video H.263 Cap2 e B i,j rappresenta il valore (di luminanza o crominanza) del pixel (i,j) del blocco 8x8 da trasformare. 2. i coefficienti DCT calcolati vengono quantizzati. Le componenti continue dei coefficienti DCT (DC) vengono sempre divise per 8, mentre per le alternate (AC) è possibile scegliere un valore q in un range tra 1 e 31, e tutte le AC vengono divise per 2q. In questo modo si da un peso maggiore alla componente continua dell immagine rispetto alle componenti di frequenza maggiore. A seguito della quantizzazione, poiché nella divisione si trascurano eventuali decimali dopo la virgola, molti coefficienti sono pari a i coefficienti quantizzati vengono ordinati secondo una scansione a zig-zag (figura 2.3), che permette di disporli in un vettore in ordine crescente di frequenza. Poiché la potenza delle immagini è, in genere, maggiore nelle componenti di bassa frequenza, l ordinamento zig-zag genera un vettore con molte componenti diverse da zero nelle prime posizioni, e molti valori nulli alla fine. Figura 2.6: scansione a zig-zag dei coefficienti DCT quantizzati 20

24 Implementazione del codec video H.263 Cap2 4. Si procede poi a una codifica del tipo RLE (Run Lenght Encoding): ogni componente non nulla (esclusa la DC che rimane inalterata) del vettore ottenuto dopo zig-zag viene codificato con una tripletta (LAST, RUN, LEVEL): LAST vale 1 solo se si sta codificando l ultimo coefficiente non nullo del vettore, altrimenti vale 0. RUN indica il numero di coefficienti nulli hanno preceduto quello (diverso da zero) attuale LEVEL rappresenta il valore del coefficiente che si sta codificando 5. Infine ogni tripletta viene codificata secondo una tabella di Huffmann. In questo modo vengono rappresentati con meno bit le triplette più probabili, e con più bit quelle meno frequenti. Ogni vettore di 64 elementi viene quindi codificato dagli 8 bit della DC, più bit che rappresentano le parole VLC della codifica entropica. Seguendo i 5 passi elencati ogni blocco 8x8 viene rappresentato da una sequenza di bit che verrà inserita nel bitstream come parte del quadro INTRA. 2.5 La codifica INTER La codifica INTER si basa sulla eliminazione della ridondanza temporale di una sequenza video. In effetti, a meno di movimenti molto veloci, che decorrelano temporalmente i frame di una sequenza, due quadri successivi hanno molte caratteristiche in comune. Sia I k 1 il frame precedente ricostruito, e I k il frame attuale, da codificare. Due operazione fondamentali vengono eseguite nel blocco di predizione: 21

25 Implementazione del codec video H.263 Cap2 1. la stima del movimento (ME Motion Estimation) 2. la motocompensazione (MC Motion Compensation) La ME si basa sull ipotesi che ogni macroblocco di un immagine possa essere considerato come traslazione di un macroblocco dell immagine che la precede nel tempo. Le traslazioni non sono le stesse per tutto il quadro, ma possono variare da macroblocco a macroblocco. Lo scopo della ME è di calcolare, secondo i metodi descritti più avanti, per ogni macroblocco che compone l immagine, un vettore di movimento (MV) che definisce lo spostamento che il macroblocco a cui è associato ha subito dal frame k-1 al frame k. Così, spostando ogni macroblocco di I k 1 secondo il relativo MV, si ottiene una prima stima Î k del frame attuale. Ogni componente (orizzontale e verticale) di un MV viene poi codificata in maniera differenziale rispetto ai MV dei macroblocchi vicini: ogni MV è composto dalla somma di una parte predetta dal valore dei MV dei macroblocchi adiacenti e da una parte differenza detta MVD (Motion Vector Difference). A ogni MVD è poi associata una VLC, che viene inserita nel bitstream. Si calcola poi l errore di predizione e k = I k - Î k che tiene conto delle modifiche avvenute nella scena rappresentata al fine di ricostruire Ī k fedelmente. L errore di predizione e k viene sottoposto alle 5 operazioni descritte in precedenza per i quadri INTRA. Per ogni macroblocco vengono quindi inviati al decoder le parole VLC associate agli MVD relativi alle componenti orizzontale e verticale del MV, e i coefficienti DCT quantizzati dell errore di predizione. Si noti che per la predizione ci si riferisce all immagine ricostruita e non all immagine originale all istante k-1; ciò perché in ricezione si ripete lo stesso procedimento e le uniche immagini a disposizione in decodifica sono quelle ricostruite. Migliore risulta la predizione e minori sono i dati e k da trasmettere, ottenendo così una riduzione della banda necessaria a parità di qualità. 22

26 Implementazione del codec video H.263 Cap2 Le operazioni descritte permettono di ottenere per i quadri P valori di compressione molto maggiori di quelli dei quadri I Tecnica del block matching Lo standard non specifica alcun metodo di motion estimation per ottenere i MV. La tecnica più semplice è quella del block-matching. Il macroblocco da stimare viene confrontato, pixel a pixel, con blocchi della stessa dimensione e interni ad un area di ricerca centrata nel frame precedente nella posizione del macroblocco in questione (figura 2.4). La raccomandazione ITU-T non specifica la dimensione dell area di ricerca, ma impone come range di variazione sia per la componente orizzontale che per quella verticale l intervallo [-16;15.5]. Figura 2.7: tecnica del block matching Il metodo che garantisce il risultati migliori è la ricerca full search: il MV viene valutato considerando tutte le possibili traslazioni rigide del macroblocco entro l area di 23

27 Implementazione del codec video H.263 Cap2 ricerca nell immagine Ī k-1. Il macroblocco del frame precedente che minimizza un opportuna funzione di costo determina le componenti del motion vector: MV = ( MV x, MV y ) = arg min x, y A ( C( MV, MV )) x y la scelta della funzione di costo C è lasciata all implementatore. Nel presente lavoro nel sia nel caso della Full-Search che della Diamond-Search si è usata la SAD (Sum of Absolute Difference): SAD ( x, y) ( MVx, MVy ) = F( x, y) ( i, j) G( i + MVx, j + MVx ) i= 1 j= 1 dove F è il valore di luminanza del pixel nel macroblocco corrente in posizione (x,y) e G è il valore di luminanza del corrispondente pixel nel MB di riferimento e spostato di (MV x ;MV y ) Diamond Search Oltre alla full search, al fine di trovare il macroblocco best-mach è stata implementata anche la diamond search (ricerca a diamante), che permette di velocizzare la ricerca dei motion vector. La diamond search (figura 2.5) utilizza sempre una finestra di ricerca 16x16 per il calcolo della SAD (Sum of Absolute Difference) facendo variare i motion vector nell intervallo [-16;15.5]. La ricerca segue i seguenti passi: 1. Si considera il punto centrale di partenza dell algoritmo di ricerca, che si ipotizza di coordinate (x,y). Esso ha otto punti adiacenti. Nella ricerca del best-maching si calcola la SAD (per la cui formula si faccia riferimento alla descrizione della full- 24

28 Implementazione del codec video H.263 Cap2 search) per i quattro macroblocchi candidati del quadro precedente centrati nei punti di coordinate (x+1,y), (x-1,y), (x,y+1) e (x,y-1). Il valore minimo dei quattro computati si salva in una variabile D1. 2. Si sceglie il punto con il minimo valore di SAD fra quelli considerati nel passo precedente. A partire da esso, si applica di nuovo l algoritmo precedente alla ricerca di un nuovo punto a SAD minima fra i quattro candidati. Il valore minimo trovato si salva nella variabile D1 dopo aver spostato il valore di quest ultima in D2. Figura 2.8: diamond search 3. Il punto a SAD minima del passo 2 viene scelto come nuovo punto centrale. Come prima, ai quattro punti ad esso adiacenti (individuati come sopra) si applica il computo della SAD. Si copia la variabile D2 in D3, D1 in D2 e in D1 si salva il nuovo valore minimo individuato. Se sono verificate simultaneamente le condizioni D1 >= D2 e D1 >= D3 la ricerca si interrompe. In caso contrario si effettua il passo 4. 25

29 Implementazione del codec video H.263 Cap2 4. Adottando l ultimo punto a SAD minima individuato come punto centrale, si calcola la SAD per i quattro punti ad esso adiacenti per individuare un nuovo punto di minimo. Si sposta D2 in D3, D1 in D2 e si salva il nuovo valore in D1. Se risulta D1>=D2 e D1>= D3 la ricerca si interrompe. In caso contrario si itera il passo Struttura del bitstream Il bitstream H.263 descrive la sequenza video dopo compressione. È composto da alcuni header fissi, che permettono il riconoscimento delle principali strutture della sequenza (es. inizio di un nuovo frame, caratteristiche del quadro), da header variabili (es. valore di quantizzazione, tipo di macroblocco) per descrivere i parametri di un quadro, o anche di un singolo macroblocco, e dal payload, che rappresenta l informazione, compressa come mostrato nei paragrafi precedenti. Queste informazioni sono strutturate in modo gerarchico. L organizzazione del bitstream ricalca la struttura nella quale vengono suddivisi i quadri in ingresso. In particolare, sono definiti quattro livelli sintattici: quadro (picture layer, figura 2.6): tra gli identificatori di maggior rilievo quello di inizio frame (PSC), di temporizzazione (TR), di formato immagine e del modo di codifica (PTYPE) e del parametro di quantizzazione di base (PQUANT). A livello di picture layer il payload è costituito dal contenuto del campo GOBs 26

30 Implementazione del codec video H.263 Cap2 Figura 2.9: picture header di un quadro H.263 gruppo di blocchi (GOB layer): il campo GOBs del picture layer è composto dalla sequenza dei blocchi di informazione delle varie GOB, ognuno dei quali è mostrato in figura 2.7. Tra i vari campi (tutti opzionali) dell header della GOB, GBSC (Group of Block Start Code) è il più importante: permette infatti l identificazione di ogni GOB anche in caso di errori nei bit delle GOB precedenti. Gli altri header sono assenti se manca GBSC. Nel flusso realizzato in fase di studio non si è reso necessario l utilizzo di GBSC, in quanto, almeno per i quadri INTRA, ogni GOB viene incapsulata in un pacchetto RTP, ed è quindi sempre distinguibile dalle altre. L utilizzo dell header della GOB nei quadri INTER è sconsigliato per l elevato aumento di banda che comporta. In definitiva, nel caso in analisi, l header della GOB è completamente assente, e dopo i picture header il flusso è composto da 99 blocchi Macroblock Data. Figura 2.10: header di una GOB macroblocco (MB layer): il primo campo COD (1 bit) indica se il macroblocco (nel caso di codifica INTER) è codificato o meno. Se COD=1, non vengono trasmesse altre informazioni per il macroblocco. In caso di codifica (COD=0), seguono le informazioni sul tipo di macroblocco (campi MCBPC, MODB, CBPB e CBPY), e su eventuali modifiche al valore di quantizzazione (DQUANT). I campi 27

31 Implementazione del codec video H.263 Cap2 MVD sono presenti solo per i macroblocchi di tipo INTER (per quadri P o B). Il campo Block Data contiene i coefficienti DCT dei 4 blocchi del macroblocco ed è presente sia nei macroblocchi di tipo INTRA che in quelli di tipo INTER (in questo caso contiene i coefficienti DCT della motocompensazione). I campi descritti sono mostrati in figura 2.8 Figura 2.11: header di un macroblocco blocco (block layer, figura 2.9): include i coefficienti DCT quantizzati e codificati entropicamente (parole VLC). E da rimarcare che per blocchi di un macroblocco di tipo INTRA sono usati 8 bit per il coefficiente DC ed un numero variabile per ogni coefficiente AC, come descritto in precedenza. Diversamente, i coefficienti DCT dei blocchi di un macroblocco INTER sono tutti rappresentati con parole VLC. Figura 2.12: organizzazione dei dati di un blocco 2.7 Controllo di flusso Uno degli aspetti critici della codifica video in ambiente UMTS è l occupazione di banda del flusso proveniente dallo strato applicativo. Infatti, sebbene il trasporto considerato sia a commutazione di pacchetto, e sia quindi possibile variare la banda a disposizione di ogni servizio, i tempi per allocare una maggiore quantità di banda ai dati video sono troppo elevati rispetto alle variazioni istantanee di bitrate del flusso video. 28

32 Implementazione del codec video H.263 Cap2 Nella figura 2.10 è possibile osservare le rapide variazioni di banda che si ottengono con codifica H.263 a quantizzazione costante del video Carphone", e le minori oscillazioni del bitrate di un video quasi statico, Claire. Carphone e Claire: codifica a quantizzazione costante bit/s GOP Carphone Claire Figura 2.13: occupazione di banda a qualità costante Il codec H.263 non è dotato di strumenti per il controllo di flusso. Per mantenere il bitrate al di sotto di una soglia stabilita è possibile solo il frame-skipping: alcuni frame non vengono codificati, e il decoder riproporrà a video, al posto dei frame saltati, l ultimo frame disponibile. Chiaramente la qualità del video, in caso di bitrate limitato e controllato solo per mezzo di frame-skipping, sarà molto bassa, a causa degli scatti molto visibili nel video in caso di scene ricche di movimento. Il codec H.263 non prevede un sistema di controllo di flusso: vengono quindi utilizzati algoritmi come TMN5 e TMN8 per mantenere costante il bitrate. 29

33 Implementazione del codec video H.263 Cap2 Nel simulatore descritto, tuttavia, si è preferito un approccio più semplice, ed è stato implementato un controllo di flusso che agisce sulla quantizzazione dei quadri INTRA, su quella dei quadri INTER, e opera, in caso di necessità, una particolare forma di frame-skipping Algoritmo di flow-control Nel presente paragrafo sono descritti l algoritmo di flow-control sviluppato, e i risultati ottenuti in termini di occupazione di banda e qualità dell immagine, in confronto alla semplice codifica a quantizzazione fissa. In primo luogo vengono fissati dei limiti per le variazioni dei coefficienti di quantizzazione per i quadri I (QI) e P (QP): QI è compreso tra 6 e 20, e QP tra 8 e 26. La limitazione superiore è necessaria per evitare di rispettare il limite di banda trasmettendo immagini di qualità pessima, in caso di scene particolarmente movimentate: in situazioni limite è preferibile operare frame-skipping, e mantenere a valori non limite i coefficienti di quantizzazione. È stato scelto di usare anche un limite inferiore per QI e QP in quanto valori troppo bassi di quantizzazione causano un aumento di banda al quale non corrisponde un proporzionale aumento in qualità, a causa della minore capacità dell occhio umano di distinguere i dettagli in un video. Infine, QI e QP vengono inizializzati rispettivamente a 13 e 15, valori che in media garantiscono una piccola occupazione di banda con una qualità accettabile. Fissati i limiti per QI e QP, l algoritmo opera su due livelli: 1. analisi dei bit occupati da ogni quadro P 2. analisi dei bit occupati di un GOP 30

34 Implementazione del codec video H.263 Cap2 I due livelli di analisi e gestione del controllo di flusso non sono del tutto indipendenti, e la modifica di uno dei parametri del controllo sui quadri P comporta variazioni anche notevoli nel comportamento del controllo su tutta la GOP. All inizio di ogni GOP si considerano disponibili GOP_MAX bit: nel caso in esame una GOP è composta di 1 quadro I e 15 quadri P e il frame-rate è pari a 16 fps; volendo rispettare il limite di 48 kbit/s, risulta GOP_MAX=48000; viene anche inizializzato GOP_RESID=GOP_MAX. Viene codificato il primo quadro della GOP (quadro INTRA), e vengono sottratti i bit utilizzati a GOP_RESID (GOP_RESID=GOP_RESID-BIT_INTRA) Per il quadro successivo sono quindi disponibili MAX_P=GOP_RESID/(15-n) bit, dove n è il numero d ordine, all interno della GOP, del quadro attuale (n=0,1,,15). Viene codificato il quadro n-imo con il valore QP in memoria, e viene confrontato il numero di bit occupati con il massimo calcolato in precedenza: Se BIT_INTER > MAX_P + 15% QP viene aumentato di una unità (QP=QP+1); Se BIT_INTER < MAX_P - 15% QP viene decrementato di una unità (QP = QP-1) Altrimenti QP rimane invariato Terminata la codifica di tutti i quadri della GOP, si confrontano il numero di bit occupati nella GOP (BIT_GOP) con MAX_GOP: Se BIT_GOP > MAX_GOP + 15% QP viene aumentato di una unità (QP=QP+1) Se BIT_GOP < MAX_GOP - 15% QP viene decrementato di una unità (QP = QP-1) Altrimenti QP rimane invariato 31

35 Implementazione del codec video H.263 Cap2 In ogni caso QI viene posto pari a QP-1, o a QI_MAX o QI_MIN, nel caso che QP- 1 sia fuori dal range di valori previsti per QI. I punti sopra esposti vengono ripetuti per ogni GOP. Nell algoritmo descritto alcune scelte meritano una ulteriore spiegazione: L utilizzo della dimensione (in bit) di un quadro per scegliere la quantizzazione da usare nella codifica del quadro successivo presuppone che nella maggior parte dei casi un movimento non si esaurisca in un unico quadro, ma comprenda più frame successivi: in effetti, con una distanza temporale tra quadri di 1/16 s, quasi sempre un movimento della telecamera, o di una persona ripresa ha una durata di almeno 3-4 quadri. Questo permette quindi di utilizzare la dimensione di un quadro per prevedere quella del quadro successivo. Alla fine di ogni GOP QI viene posto pari a QP-1: questo per permettere che la qualità del quadro I non sia troppo diversa da quella del quadro P precedente. Grosse differenze di qualità tra quadro P e quadro I portano infatti a un fastidioso effetto di flash dell immagine all inizio di ogni GOP. La scelta di lasciare un margine, attorno alle soglie MAX_P e MAX_GOP, è giustificata dalla ricerca di maggiore stabilita dell algoritmo di controllo di flusso, anche, in alcuni casi, a scapito di piccoli superamenti del bitrate massimo stabilito: la mancanza del margine porta, in alcune situazioni, a oscillazioni anche crescenti delle dimensioni dei quadri codificati. 32

36 Implementazione del codec video H.263 Cap Frame Skipping Come detto, il solo controllo di flusso implementato non è sufficiente a mantenere l occupazione di banda entro i limiti fissati, in quanto non è mai possibile raggiungere i valori limite per la quantizzazione; inoltre, alcuni video molto movimentati non rientrano nei 48 kbit/s anche portando la quantizzazione agli estremi. Per tornare a un occupazione di banda vicina ai limiti, si è quindi deciso di operare frame-skipping: alcuni quadri non vengono codificati, risparmiando una notevole quantità di bit, e con un effetto che in molti casi è trascurabile, anche in un video non fluido come quello a 16 fps. Una prima tecnica di frame-skipping consiste nel non codificare più alcun quadro di una GOP una volta raggiunto il limite di bit: ad esempio, se i primi 8 frame di una GOP (che dura 1 s) occupano bit, tutti i frame dal 9 al 15 non vengono codificati, e in decodifica viene riproposto a video il frame 8. Chiaramente la banda è così sempre rispettata, ma la qualità percepita in caso di video ricchi di movimento, quindi con forte applicazione del frame-skipping, può risultare scarsa, a causa dei continui scatti nel video. Nell implementazione del controllo di flusso si è optato per un frame-skipping di tipo diverso. In punti fissi della GOP vengono confrontati i bit occupati fino a quel momento dalla codifica con quelli previsti, ed eventualmente non viene codificato il frame successivo. Questo avviene dopo la codifica dei frame 4, 8, 12. In particolare dopo il frame 12 è possibile skippare 2 frame consecutivi, il 13 e il 14. Con questo metodo è possibile skippare fino a 4 frame in ogni GOP, con una buona riduzione di banda, ma senza eccessivi scatti dell immagine. Chiaramente, la limitazione sul numero massimo di frame da saltare comporta un non sempre rigoroso rispetto del bitrate, ma nelle simulazioni effettuate, orientate maggiormente ad aspetti di error resilience ed error concealment, si è verificato che la presenza saltuaria di una GOP a bitrate superiori ai bit/s non comporta variazioni notevoli dei risultati. Un ulteriore vantaggio del modello di frame-skipping implementato è che, rispetto a un frame-skipping classico, un concealment dei quadri I basato sull ultimo quadro della 33

37 Implementazione del codec video H.263 Cap2 GOP precedente è facilitato, in quanto l ultimo quadro della GOP viene sempre codificato, ed è sempre disponibile al decoder per tecniche di error concealment. Nelle figure sono mostrate le prestazioni dell algoritmo di controllo di flusso comprensivo di frame-skipping: nel primo esempio viene mostrato Carphone" codificato a quantizzazione costante pari a 22, e codificato con controllo di flusso, e nel secondo Claire, con quantizzazione costante pari a 14, e con controllo di flusso. È possibile notare come nel caso di Carphone anche dopo controllo di flusso permangano delle GOP a bitrate eccessivo, che comunque non danno variazioni significative in termini di prevenzione e trattamento degli errori. Il bitrate medio nei due casi è molto vicino (circa bit/s), anche se la grandezza più significativa è il bitrate di ogni GOP. Sia in Carphone che in Claire vengono smussati i picchi di banda nelle GOP più movimentate, e la qualità del video non viene peggiorata. Il confronto tra i PSNR delle sequenze a quantizzazione costante e codificate con flow control, infatti, è sempre simile, tranne nel caso di frame skipping: tuttavia il valore del PSNR per i frame non codificati è poco rilevante, in quanto non viene percepita una immagine affetta da errori, ma solo, eventualmente, un breve scatto nel video. 34

38 Implementazione del codec video H.263 Cap2 bit/s Carphone: controllo di flusso no flow control flow control GOP Figura 2.14: occupazione di banda con e senza flow control per la sequenza Carphone Carphone: PSNR con e senza flow control no flow control flow control PSNR frame Figura 2.15: a confronto il PSNR della sequenza Carphone con e senza flow control 35

39 Implementazione del codec video H.263 Cap2 bit/s Claire: controllo di flusso no flow control flow control GOP Figura 2.16: occupazione di banda con e senza flow control per la sequenza Claire Claire: PSNR con e senza flow control no flow control flow control 34 PSNR frame Figura 2.17: a confronto il PSNR della sequenza Claire con e senza flow control In conclusione, la tecnica di flow control sviluppata permette di ottenere un video a bitrate quasi costante, rendendo validi e significativi i successivi studi sulle tecniche di prevenzione e recupero da situazioni di errore. 36

40 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 3 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP 3.1 Impacchettamento del flusso H.263 in RTP Il flusso video uscente da un codificatore H.263 può essere direttamente incapsulato in un protocollo. Considerando il contesto real-time, come già anticipato, nel presente lavoro di tesi è previsto l utilizzo di RTP (Real-Time Transport Protocol) per il trasporto del flusso video. La PDU-RTP è mostrata in figura bit 31 V P X CC M PT Sequence Number Timestamp Syncronization Source (SSRC) identifier Contributing Source (CSRC) identifier Figura 3.18: campi di un pacchetto RTP 37

41 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 Ciascun pacchetto RTP prevede un header fisso seguito dal campo H.263 Payload Header, a sua volta seguito dal bitstream compresso H.263. I seguenti campi dell intestazione fissa di RTP vengono utilizzati per gli stream video H.263: Marker bit (M bit): è settato ad 1 quando il pacchetto corrente trasporta la fine di un frame; è posto a 0 in caso contrario. Payload Tipe (PT): specifica il formato dell H.263 video payload utilizzando il valore specificato dal profilo RTP in uso. Timestamp: codifica l istante di campionamento del frame video contenuto nel pacchetto dati RTP. Il timestamp RTP è lo stesso per pacchetti successivi se un frame video ne occupa più di uno. Per il flusso video H.263 il timestamp RTP è fa riferimento ad un clock a 90 KHZ, lo stesso utilizzato per stream video nel protocollo H.261. Per ciascun pacchetto RTP, l intestazione fissa RTP è seguita dall intestazione del payload H.263, che è a sua volta seguita dal bitstream compresso H.263. La dimensione dell intestazione del payload H.263 è variabile in relazione alle modalità utilizzate, così come sarà evidenziato in dettaglio in seguito. Il layout di un pacchetto video RTP H.263 è mostrato nella seguente figura: 0 bit 31 RTP header H.263 payload header H.263 bitstream Figura 3.19: layout di un pacchetto video RTP H

42 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap Modi di impacchettamento del flusso H.263 in RTP Ciascun pacchetto RTP trasporta un solo pacchetto video H.263. Per questi ultimi è sempre presente la H.263 payload header. Per l intestazione del payload H.263 sono definiti tre formati (modo A, modo B e modo C). Nel modo A, prima del bitstream video compresso H.263, in un pacchetto è presente un intestazione del payload di lunghezza pari a 4 byte. Questo permette la frammentazione a gruppi di GOB. Nel modo B viene utilizzata un intestazione del payload pari ad 8 byte e ciascun pacchetto inizia ai limiti del macroblocco (MB) senza l opzione per i quadri di tipo P e B. Infine nel modo C è definita una intestazione del payload di lunghezza 12 byte per supportare la frammentazione a gruppi di macroblocchi con l opzione per i quadri P e B. La modalità prescelta per ciascuna intestazione viene indicata dai campi F e P, sempre presenti all inizio della payload header. È possibile interfacciare tra loro pacchetti di modi differenti. Per questo motivo tutte le applicazioni client devono avere la capacità di ricevere i pacchetti di tutte le modalità, con l eccezione di quelli relativi al mode C che è opzionale. Di seguito vengono trattati nello specifico i tre modi di impacchettamento Modo A In questa modalità un bitstream H.263 viene pacchettizzato a livello di GOB o a livello di quadri. I pacchetti del modo A iniziano sempre con il codice d inizio del quadro H.263 (picture start code) o con il flusso relativo ad una GOB, ma non contengono necessariamente l intera informazione della GOB stessa. Come anticipato nel modo A vengono utilizzati quattro bytes per l intestazione del payload H.263. La definizione dell intestazione del payload è mostrata nella figura 3.3. La modalità di impacchettamento è indicata dal flag F, che per il modo A è uguale a 0. I pacchetti del modo A possono cominciare all inizio di un GOB anche se non è presente un intestazione del GOB nel bitstream. 39

43 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 0 bit 31 F P SBIT EBIT SRC I U S A R DBQ TRB TR Figura 3.20: intestazione del payload H.263 per il modo A I campi dell header hanno il seguente significato: F (1 bit): indica il modo dell intestazione del payload. F = 0 indica il modo A, F=1 indica il modo B o il modo C a seconda del bit P P (1 bit): se è uguale a 0 indica un frame normale di tipo I o P, mentre se è posto a 1 indica un PB frame; quando F = 1, P indica anche il modo (B se P = 0 e C se P = 1) SBIT (3 bit): lo Start Bit Position specifica il numero di bit più significativi che devono essere ignorati nel primo byte di dati EBIT (3 bit): il Bit End Position specifica il numero di bit meno significativi che devono essere ignorati nell ultimo byte di dati SRC (3 bit): specifica la risoluzione del quadro corrente ed è rappresentato dai bit 6, 7 e 8 del campo PTYPE definito dall H.263 I (1 bit): specifica il tipo di codifica del quadro corrente ed è rappresentato dal bit 9 del campo PTYPE; se I = 0 il quadro è di tipo INTRA, mentre se I = 1 il quadro è di tipo INTER 40

44 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 U (1 bit): è rappresentato dal bit 10 del campo PTYPE dell H.263 e viene posto ad 1 se l opzione Unrestricted Motion Vector è abilitata S (1 bit): è rappresentato dal bit 11 del campo PTYPE dell H.263 e viene posto ad 1 se l opzione Syntax-based Arithmetic Coding è abilitata A (1 bit): è rappresentato dal bit 12 del PTYPE dell H.263 e viene posto ad 1 se l opzione Advanced Prediction è abilitata R (4 bit): È un campo riservato e deve essere posto a zero DBQ (2 bit): parametro per la quantizzazione differenziale usato per calcolare il quantizzatore per i frame B a partire da quello del frame P, quando viene utilizzata l opzione dei PB frame; dovrebbe assumere lo stesso valore del campo DBQUANT definito dall H.263 e viene posto a zero se l opzione dei frames PB non viene utilizzata TRB (3 bit): è il Temporal Reference per i frame B e viene posto a zero se l opzione dei PB frames non viene utilizzata Modo B In questo modo un bitstream H.263 può essere frammentato a livello dei macroblocchi. Quando un pacchetto inizia al limite di un macroblocco è consigliabile l uso di questa modalità escludendo l uso dell opzione dei quadri PB. I pacchetti nel modo B sono pensati per una GOB la cui dimensione è maggiore della massima 41

45 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 dimensione del pacchetto permessa dal protocollo sottostante, il che rende impossibile incapsulare una o più GOB complete in un pacchetto. L intestazione del payload H.263 per il modo B è mostrata nella figura 3.4. Per quanto detto in precedenza i flag F e P saranno settati ad 1 e 0 rispettivamente. 0 bit 31 F P SBIT EBIT SRC QUANT GOBN MBA R I U S A HMV1 VMV1 HMV2 VMV2 Figura 3.21: intestazione del payload H.263 per il modo B I campi F, P, SBIT, EBIT, SRC, I, U, S ed A hanno lo stesso significato assunto nel modo A. I restanti campi sono definiti come segue: QUANT (5 bit): indica il valore di quantizzazione del primo macroblocco codificato all inizio del pacchetto e viene posto a 0 se il pacchetto inizia con l intestazione di una GOB; questo campo è l equivalente del campo GQUANT definito dall H.263 GOBN (5 bit): è il numero della GOB posta all inizio del pacchetto; la numerazione della GOB è specificato differentemente a seconda della risoluzione MBA (9 bit): è l offset all interno della GOB del primo macroblocco nel pacchetto, partendo da zero con l ordine di scansione (es.: MBA=2 per il terzo MB di una GOB) 42

46 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 HMV1, VMV1 (7 bit ciascuno): sono i predittori orizzontali e verticali per i vettori di spostament del primo macroblocco nel pacchetto; quando vengono utilizzati quattro vettori di spostamento per il macroblocco corrente con l opzione di predizione avanzata, questi dovrebbero essere i predittori per il vettore di spostamento per il blocco numero 1 nel macroblocco. Ciascun campo di 7 bits, con un numero in complemento a due, codifica un predittore del vettore di spostamento con risoluzione al mezzo pixel HMV2, VMV2 (7 bit ciascuno): sono i predittori orizzontali e verticali dei vettori di spostamento per il blocco numero 3 nel primo macroblocco del pacchetto quando vengono utilizzati quattro vettori di spostamento con l opzione di predizione avanzata. Questi due campi non vengono utilizzati quando il macroblocco ha un solo vettore di spostamento. Ciascun campo di 7 bits, con un numero in complemento a due, codifica un predittore del vettore di spostamento con risoluzione al mezzo pixel R (2 bit): è un campo riservato e deve essere posto a zero Modo C In questo modo un bitstream H.263 viene frammentato a livello di macroblocchi dei frame P con l opzione per i frames P e B. Tale modo è stato pensato per quelle GOB le cui dimensioni sono maggiori della massima dimensione permessa per il pacchetto del protocollo sottostante quando viene utilizzata l opzione per i PB frame. L intestazione del payload H.263 per il modo B è mostrata nella figura 3.5. I flag F e P saranno settati entrambi ad 1. 43

47 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 0 bit 31 F P SBIT EBIT SRC QUANT GOBN MBA R I U S A HMV1 VMV1 HMV2 VMV2 RR DBQ TRB TR Figura 3.22: intestazione del payload H.263 per il modo B I campi F, P, SBIT, EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, HMV2, VMV2, sono definiti analogamente al modo B. I restanti campi TR, DBQ, TRB sono definiti come nel modo A, ad eccezione del campo RR che occupa 19 bit (attualmente riservati) che vanno posti a Selezione dei modi per l intestazione del Payload H.263 I modi dovrebbero essere selezionati attentamente in base alla dimensione del pacchetto da inviare alla rete, alle opzioni di codifica prescelte ed ai protocolli delle reti sottostanti. Più specificatamente, il modo A dovrebbe essere usato per i pacchetti che iniziano con una GOB o con il Pycture Start Code ed i modi B e C dovrebbero essere usati quando all inizio del pacchetto è posto un macroblocco. È fortemente raccomandato l utilizzo del modo A ogni volta che è possibile, data la sua maggiore semplicità rispetto ai modi B e C. Inoltre l intestazione del payload H.263 è più piccola di quella dei modi B e C. Un altro vantaggio del modo A è che esso semplifica il recupero degli errori in presenza di perdita di pacchetti. Per il decoder infatti risulta più semplice la risincronizzazione a livello di GOB, ossia l individuazione della corrispondente intestazione o del Picture Start Code, piuttosto che a livello di MB. 44

48 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap Il protocollo UDP Il protocollo UDP (User Data Protocol) è stato preferito al protocollo TCP per le videocomunicazioni real-time, in quanto permette di contenere il ritardo di trasferimento end-to-end. Adotta una modalità di trasferimento senza connessione e non fornisce alcuna garanzia sulla qualità di servizio. Non prevede alcuna funzionalità di recupero dell errore, di controllo di flusso e di riordinamento delle unità informative. Le unità di dati UDP sono denominate datagrammi utente e possono assumere lunghezza variabile. Lo schema di un pacchetto UDP si presenta come in figura Source Port Destination Port Datagram Length Checksum Application Data Figura 3.23: struttura di un pacchetto UDP L intestazione contiene i seguenti campi: Source Port (16 bit): è un campo opzionale (se non è presente assume per default il valore 0) e indica l indirizzo di porta del processo che sta trasmettendo. In caso di assenza di informazioni specifiche può essere assunto anche come indirizzo a cui destinare una eventuale risposta. 45

49 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 Destination Port (16 bit): indica l indirizzo di poorta di destinazione. Length (16 bit): indica la lunghezza in ottetti del datagramma, includendo sia i dati informativi che l header. Il valore minimo che può assumere è 8, corrispondente alla lunghezza dell header. Checksum (16 bit): è un campo opzionale tramite il quale è possibile proteggere tutto il datagramma UDP. All intestazione segue un campo denominato Application Data contenente i dati di utente, generati da un processo applicativo. UDP accetta dal livello superiore i dati senza imporre alcun vincolo sulla loro lunghezza; eventualmente esegue la frammentazione e invia i singoli pacchetti in datagrammi IP distinti. Come come già anticipato il campo checksum è opzionale; è possibile fare a meno di usarlo, ove non necessario, ottenendo una riduzione del carico elaborativo per la trasmissione e la ricezione di un datagramma utente UDP. Infatti nel caso in cui si utilizzano reti altamente affidabili, la verifica di errori non è indispensabile. 46

50 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap IP IP è un protocollo di strato 3 che offre come servizio principale il trasferimento di unità informative. Fornisce, tra le altre, le seguenti funzionalità: Definisce lo schema di indirizzamento; Definisce l unità base per il trasferimento dei dati attraverso Internet e quindi specifica il formato di tutti i dati che attraversano l inter-rete Definisce la strada che un unità di dati deve percorrere per arrivare a destinazione Specifica un insieme di regole che host e router devono seguire per processare le unità informative Definisce le modalità per la segmentazione e l aggregazione delle unità di dati. Il servizio offerto è inaffidabile poiché la consegna di un unità informativa non è garantita. Quest ultima può essere persa, duplicata, ritardata o consegnata fuori sequenza. Né al mittente né al destinatario giunge notifica circa il verificarsi delle suddette condizioni. Il servizio è senza connessione e quindi ogni unità informativa è trattata in modo indipendente dalle altre: ciò implica che ognuna di esse può percorrere una strada diversa per giungere a destinazione. Le unità di dati dello strato IP sono dette datagrammi. Quest ultimo è composto da un intestazione seguita da un campo informativo che contiene i dati di utente. Il formato del datagramma IP è illustrato in figura 3.7. La lunghezza massima di un datagramma è di ottetti. La lunghezza fissa dell header è di 20 byte per la versione IPv4 e di 40 byte per IPv6. È possibile inserire una parte opzionale che può raggiungere al massimo i 40 byte. 47

51 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap V e r s H L E N S ervice T y p e T ota l L en g t h Id e n tifica tio n F la g + F r a g m e n t O ffset T im e to L iv e P r otoc ol H ea d e r C h e c k s u m S o u r ce IP A d d r ess D e stin a tio n IP A d d r e ss O p tio n s P a d d in g D a ta. D a ta Figura 3.24: campi del datagramma IP I campi in figura 3.7 hanno i seguenti significati: Vers (4 bit): specifica la versione del protocollo usata; HLEN (4 bit): lunghezza dell intestazione (specificata in parole di 32 bit); Service Type (8 bit):specifica i parametri della qualità di servizio richiesti dall utente quali l affidabilità e la velocità del trasferimento; 3 bit specificano l importanza del datagramma; i 3 bit seguenti possono essere utilizzati per richiedere particolari caratteristiche di ritardo, portata e affidabilità; Total Length (16 bit): specifica la lunghezza complessiva del datagramma misurata in ottetti, includendo l intestazione e i dati; la lunghezza di un datagramma è sempre uguale ad un multiplo di 4 byte; Identification (16 bit): numero identificativo del datagramma; è un valore identificativo assegnato dal processo sorgente al datagramma o ai suoi frammenti; Flags (3 bit): è composto dai sub-campi X, DF e MF; X : non usato e posto a zero; 48

52 Trasporto del flusso H.263 nella pila protocollare RTP/UDP/IP Cap.3 DF (Don t Fragment): se uguale a 0 indica che il datagramma può essere segmentato, mentre è posto a 1 in caso contrario; MF (More Fragment): se uguale a 0 indica che quello in questione è l ultimo frammento del datagramma, mentre è posto ad 1 se ne seguono altri; Fragment Offset (13 bit): indica la posizione (espressa in unità di 8 byte) di un frammento all interno del un datagramma originario; Time to Live (8 bit): specifica il numero massimo di router che possono essere attraversati dal datagramma; Protocol (8 bit): indica a quale protocollo dello strato superiore deve essere trasferitoli contenuto informativo del datagramma; Header Checksum (16 bit): è un campo di controllo dell intestazione del datagramma; Source Address (32 bit): indirizzo di sorgente IP; Destination Address (32 bit): indirizzo di destinazione IP; Options: campo di lunghezza variabile multipla di 8 bit; Padding: rende l intestazione multipla di 32 bit mediante l introduzione di zeri. 49

53 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 4 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e Strato 2 (PDCP, RLC, MAC) In questo e nel prossimo capitolo verrà analizzato il percorso, nello user plane, dei pacchetti IP (strato 3) attraverso gli strati 2 e 1 dell architettura protocollare dell interfaccia radio UMTS (Uu). In figura 4.1 sono mostrati gli elementi funzionali degli strati del control plane, e degli strati 1-2 dello user plane. 50

54 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 C-plane signalling U-plane information RRC control L3 control control control control PDCP PDCP Radio Bearers L2/PDCP BMC L2/BMC RLC RLC RLC RLC RLC RLC RLC RLC L2/RLC Logical Channels MAC PHY L2/MAC Transport Channels L1 Figura 4.25: Strati 1-2 e 3 dell interfaccia radio UMTS Le funzioni principali dello strato 1 sono codifica di canale, interleaving, spreading, e modulazione. Lo strato 1 si interfaccia con il sottostrato MAC attraverso i Transport Channel, e i dati codificati e modulati vengono trasferiti, in aria, sui Physical channel. Lo strato 2 è suddiviso nei seguenti sottostrati: 1. MAC (Medium Access Control Protocol): si interfaccia con lo strato fisico in basso e con il sottostrato RLC in alto. Si occupa principalmente di mappare i canali logici nei canali di trasporto, e di scegliere un appropriato formato di trasporto per i canali di trasporto, sulla base del rate istantaneo dei canali logici. 51

55 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 2. RLC (Radio Link Control Protocol): si interfaccia con MAC, in basso, e PDCP o BMC, in alto. Opera funzioni di segmentazione/concatenazione di pacchetti, e può operare in Trasparent Mode (Tr), Unacknowledged Mode (UM), Acknowledged Mode (AM). 3. PDCP (Racket Data Convergence Mode Protocol): posto tra RLC e lo strato 3, e presente solo nel dominio a commutazione di pacchetto, esegue funzioni di header compression. 4. BMC (Broadcast/Multicast Control Protocol): posto tra RLC e lo strato 3, adatta i servizi broadcast e multicast all interfaccia radio Il sottostrato PDCP Uno degli aspetti critici dell interfaccia radio UMTS è l occupazione di banda. Il trasferimento di flussi multimediali real-time in un ambiente a pacchetto si basa sui protocolli RTP/UDP/IP, i cui header introducono una rilevante percentuale di overhead. Considerando, ad esempio, il trasferimento di voce in formato AMR, ogni pacchetto RTP contiene circa 20 byte di dati. L header RTP è di 12 byte, ai quali si sommano 8 byte dell header UDP, e 40 per gli header IPv6 (mandatario nei terminali UMTS in ambiente a pacchetto), oppure 20 per gli header IPv4. Si arriva quindi a byte di overhead per trasmettere 20 byte di dati (figura 4.2). 52

56 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 Figura 4.26: Overhead RTP/UDP/IP nel caso di trasmissione di pacchetti voce Nel caso di trasmissione di flussi video di bitrate di kb/s, la dimensione del campo dati del pacchetto RTP è maggiore, da alcune decine di byte trasferendo una GOB per ogni pacchetto RTP, fino ad alcune centinaia di byte, volendo minimizzare la percentuale di overhead. È comunque ipotizzabile una compressione degli header anche per flussi video. Un ulteriore vantaggio dell header compression è la riduzione del packet error rate: a parità di BER, la trasmissione di un minor numero di bit per ogni pacchetto comporta la riduzione del numero di pacchetti errati. D altra parte, i metodi di header compression utilizzati (RFC 2507, RFC 3095) presentano un problema: un errore su un header compresso comporta la perdita non solo del pacchetto coinvolto nell errore, ma anche di alcuni pacchetti successivi. La propagazione dell errore avviene in quanto la compressione è ottenuta inviando alla prima trasmissione, o in particolari momenti, l header non compresso; per i pacchetti successivi non vengono trasmessi i campi statici degli header (es. version per IP), o quelli con variazioni prevedibili (es. numeri di sequenza) e viene comunicata solo la variazione degli altri campi. Appare chiaro che, in caso di errore sull header di un pacchetto, la natura differenziale dell algoritmo di compressione utilizzato comporta la non corretta decompressione di alcuni header 53

57 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 successivi. Per minimizzare gli effetti di errori sugli header compressi si possono utilizzare tecniche di compressione robuste, come ROHC (RObust Header Compression), descritta nella RFC La descrizione degli algoritmi di compressione degli header esula dagli scopi del presente studio. Il dato fondamentale da sottolineare è che la dimensione media degli header compressi è compresa tra 2 e 7 byte Il sottostrato RLC Il sottostrato RLC opera principalmente funzioni di segmentazione e concatenazione di pacchetti. Ogni istanza RLC, inoltre, è configurata dal RRC (Radio Resource Control) per operare in una di tre possibili modalità: transparent mode (Tr), unacknowledged mode (UM), acknowledged mode (AM). Per tutte le tre modalità, il controllo di errore con CRC è eseguito nello strato fisico, e il risultato è comunicato al RLC insieme ai dati. Nel transparent mode non viene aggiunto overhead ai dati provenienti dagli strati superiori. Le PDU rivelate errate dallo strato fisico possono essere scartate o segnalate come errate e trasmesse allo strato superiore. Nella modalità transparent generalmente i dati provenienti dagli strati superiori non vengono segmentati, anche se sono supportate in questa modalità limitate funzioni di segmentazione/concatenazione. L acknowledged mode fornisce un canale di ritorno, permettendo l utilizzo di tecniche ARQ (Automatic Repeat Request), i cui parametri (es. delay e qualità) sono controllati dal RRC. L aumento del delay medio è tale da sconsigliare l utilizzo della modalità AM per applicazioni real-time o streaming, mentre i vantaggi dal punto di vista del BER consentono collegamenti affidabili in contesti interattivi o background. 54

58 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 In unacknowledged mode non si usa protocollo di ritrasmissione, e la consegna dei dati non è garantita (figura 4.3). I pacchetti non corretti possono essere segnati errati o scartati. Sono fornite funzionalità di segmentazione/concatenazione, che vengono segnalate per mezzo di specifici campi nell header della RLC-PDU. Dal lato trasmettitore, è possibile eliminare automaticamente dal buffer di trasmissione le SDU non trasmesse entro un limite di tempo stabilito. Le RLC-PDU sono dotate di sequence number per permettere la verifica dell integrità dei dati. È da sottolineare che la modalità unacknowledged è unidirezionale, non avendo un canale di ritorno. La protezione dagli errori, quindi, è quella fornita con CRC e turbocodifica dallo strato fisico. UM è usato in caso di trasmissioni con stretti vincoli temporali in ambiente a pacchetto, come la trasmissione di flussi multimediali, (es.voice over IP (VoIP), o flussi video). Nel seguito del documento si considererà solo la modalità UM. U E /U T R A N R a d io In te rfa c e (U u ) U T R A N /U E U M -S A P U M -S A P T ra n s m is s io n b u ffe r S e g m e n ta tio n & C o n c a te n a tio n T ra n s m ittin g U M R L C e n tity R e c e ivin g U M R L C e n tity R e a s s e m b ly R e m o ve R L C h e a d e r A d d R L C h e a d e r R e c e p tio n b u ffe r C ip h e ri n g D e c ip h e rin g D C C H /D T C H U E C C C H /S H C C H /D C C H /D T C H /C T C H U T R A N D C C H /D T C H U T R A N C C C H /S H C C H /D C C H /D T C H /C T C H U E Figura 4.27: Flusso dei dati attraverso il sottostrato RLC-UM 55

59 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 Le funzioni del RLC-UM le principali sono: 1. Segmentazione e riassemblazione: è possibile segmentare PDU di strati superiori in RLC PU (Payload Units) di dimensioni minori. Ogni RLC-PDU trasporta un PU, e la dimensione della RLC-PDU è calcolata, per ogni entità RLC, in base al minimo bitrate del flusso dagli strati superiori: quindi nei periodi di bitrate elevato verranno generate diverse RLC-PDU in un periodo di trasmissione 2. Concatenazione: se il contenuto di una RLC-SDU non occupa un numero intero di PU, la prima parte della successiva RLC-SDU può essere concatenata con l ultimo segmento della precedente RLC-SDU in un unico PU 3. Padding: quando non è possibile eseguire concatenazione, e i dati non riempiono tutto un PU, vengono inseriti padding bit per ottenere una RLC-PDU 4. Verifica del sequence number: questa funzione permette di scoprire RLC-SDU corrotte verificando il sequence number delle RLC-PDU quando queste vengono riassemblate in una RLC-SDU. Una RLC-SDU corrotta è scartata. 56

60 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap Il sottostrato MAC L interfaccia tra RLC e MAC è costituita dai canali logici, tra i quali il DTCH (Dedicated Traffic CHannel), canale dedicato, sul quale vengono trasportati i dati dei flussi multimediali, provenienti dagli strati superiori. Il sottostrato MAC è formato da tre entità logiche (figura 4.4): PCCH BCCH CCCH CTCH SHCCH ( TDD only ) MAC Control DCCH DTCH DTCH MAC-d MAC-hs MAC-c/sh Associated Downlink Signalling HS-DSCH HS-DSCH PCH Associated Uplink Signalling FACH FACH RACH CPCH USCH USCH DSCH DSCH DCH DCH ( FDD only ) ( TDD only ) ( TDD only ) Figura 4.28: Entità logiche del sottostrato MAC 1. MAC-b: per la gestione del canale BCH (Broadcast CHannel) 2. MAC-c/sh: gestisce i canali comuni e condivisi: PCH (Paging CHannel), FACH (Forward link Acces CHannel), RACH (Random Access CHannel), CPCH (uplink Common racket CHannel), e DSCH (Downlink Shared CHannel) 3. MAC-d: è responsabile della gestione dei canali dedicati DCH (Dedicated CHannel) allocati a una UE 57

61 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 Le funzioni principali del sottostrato MAC includono: 1. Mappatura dei canali logici nei canali di trasporto: verrà considerato solo il canale logico DTCH, che si ipotizzerà mappato nel canale di trasporto DCH. DTCH, tuttavia, può essere collegato anche con i canali di trasporto RACH e CPCH, in uplink, e FACH e DSCH in downlink. 2. Selezione del Transport Format: per ogni canale di trasporto viene scelto il formato di trasporto (che descrive le caratteristiche del canale) tra quelli dei Transport Format Combination Set, in base al bitrate di sorgente. 3. Multiplazione/demultiplazione: la multiplazione dei diversi flussi provenienti dagli strati superiori può avvenire solo nel sottostrato MAC per i canali di trasporto comuni (RACH/FACH/CPCH), o anche nello strato fisico per i flussi dei canali dedicati. Tuttavia, per i canali dedicati, MAC può multipare solo flussi con stesse caratteristiche di QoS. Le MAC-PDU sono stringhe di bit non necessariamente multiple di 8 bit. Per quanto riguarda la struttura dei pacchetti MAC-PDU, lo strato MAC aggiunge alle MAC-SDU un header variabile, come mostrato in figura 4.5. MAC header MAC SDU TCTF UE-Id type UE-Id C/T MAC SDU Figura 4.29: Campi della MAC-PDU 58

62 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 Tuttavia, nel caso di DTCH mappato su DCH senza multiplazione di strato MAC, nessun header è necessario (lo strato MAC in questo caso opera in maniera trasparente). Se invece è stata eseguita la multiplazione di livello MAC, è necessario solo il campo C/T, di 4 bit. Nella UE, per l uplink, tutte le MAC-PDU consegnate allo strato fisico durante un TTI (Transmission Time Interval, corrisponde alla durata dell interleaving) sono definite come Transport Block Set (TBS). Un TBS consiste di uno o più Transport Block (TB), ciascuno contenente una MAC-PDU. 4.2 Lo strato fisico Nello strato fisico i canali di trasporto vengono mappati nei canali fisici. L unico canale di trasporto dedicato è il DCH, attraverso il quale arrivano, non distinguibili dallo strato fisico, i dati di utente e le relative informazioni di controllo. Il DCH è mappato in due canali fisici: il DPDCH (Dedicate Physical Data CHannel), che trasporta le informazioni provenienti dagli strati superiori, e il DPCCH (Dedicated Physical Control CHannel), che contiene informazioni di controllo inserite dallo strato fisico. Il bitrate del DPDCH può variare ogni 10 ms (durata di un radio frame), mentre il DPCCH è caratterizzato da bitrate costante. Nel seguito vengono brevemente indicate le principali operazioni compiute sul flusso di dati nel mappaggio dal canale di trasporto DCH al canale fisico DPDCH. La descrizione delle varie procedure esula dagli scopi di questo documento. Ogni TTI lo strato MAC invia allo strato fisico un Transport Block Set. Ai vari TB vengono aggiunti alcuni bit di protezione CRC, successivamente i TB protetti sono concatenati e inviati al codificatore di canale (per il DCH è possibile scegliere tra codifica convoluzionale a rate 1/3 o 1/2 e turbocodifica a rate 1/3) e vengono aggiunti i Tail Bit. Successivamente si opera l interleaving, la divisione in radio frame (si usa un numero di frame pari al 59

63 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 numero di TB del TBS), viene eseguito il rate matching e i bit sono inseriti negli slot dei radio frame. La struttura dei radio frame e dei relativi slot per i canali DPDCH e DPCCH è descritta in seguito. Nell esempio seguente sono mostrate le varie fasi indicate (figura 7.1). In tabella 4.1 sono indicati i parametri di riferimento dell esempio. Transport block size 640 bits Transport block set size 4*640 bits CRC 16 bits Coding Turbo coding, coding rate = 1/3 TTI 40 ms Tabella 4.1 Transport block CRC attachment #1 640 #4 640 TrBk concatenation #1 CRC #4 CRC Turbo coding R=1/ Tail bit attachment 1 st interleaving Tail 12 Radio frame segmentation Rate matching 7884 #1 # #1 # N RM N RM4 To TrCh Multiplexing Figura 4.30: Operazioni di strato fisico 60

64 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap Canali fisici dedicati in uplink e downlink Passando a descrivere i canali fisici DPDCH e DPCCH, bisogna distinguere tra uplink e downlink. In uplink la modulazione utilizzata è la BPSK con multiplazione dei rami in fase e in quadratura; sul ramo in fase viene trasmesso DPDCH, su quello in quadratura DPCCH. Il canale radio è diviso temporalmente in radio frame della durata di 10 ms (38400 chips). Ogni radio frame è diviso in 15 slot, della durata di ms (2560 chips). L organizzazione dei dati all interno di ogni slot è descritta in figura 4.7. DPDCH Data N data bits T slot = 2560 chips, N data = 10*2 k bits (k=0..6) DPCCH Pilot N pilot bits TFCI N TFCI bits FBI N FBI bits TPC N TPC bits T slot = 2560 chips, 10 bits Slot #0 Slot #1 Slot #i Slot #14 1 radio frame: T f = 10 ms Figura 4.31: Struttura del radio frame e dei canali DPDCH e DPCCH in uplink ( Per il canale DPDCH lo Spreading Factor assume valori variabili tra 256 e 4 k k =, k=0 6). In uno slot possono essere inseriti N data 10*2 bit. SF 256/ 2 = Il bitrate del canale DPDCH varia quindi tra 15 kb/s (SF=256) e 960kb/s (SF=4). Per il canale 61

65 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 DPCCH lo Spreading Factor è fisso e pari a 256, quindi il bitrate del DPCCH è pari a 15 kb/s. Nel DPCCH sono presenti quattro campi di informazioni di controllo, introdotte nello strato fisico, non tutti obbligatori: 1. Pilot: bit necessari per permettere la rivelazione coerente 2. TFCI (Transport Format Combination Indicator): il TFCI informa il ricevitore della combinazione dei formati dei canali di trasporto mappati in DPDCH trasmessi contemporaneamente. Per ogni radio link possono esserci più DPDCH, ms solo un DPCCH 3. FBI (FeedBack Information): bit presenti se si usa in downlink trasmissione in diversità closed loop 4. TPC (Transmission Power Control): comandi per il controllo di potenza In downlink la modulazione usata è la QPSK, con multiplazione in tempo dei dati utente e delle informazioni di controllo di strato fisico. Il canale fisico è chiamato downlink Dedicated Physical Channel (DPCH). La struttura del DPCH è mostrata in figura

66 Architettura protocollare dell interfaccia radio UMTS (Uu): strati 1 e 2 Cap.4 DPDCH DPCCH DPDCH DPCCH Data1 N data1 bits TPC N TPC bits TFCI N TFCI bits T slot = 2560 chips, 10*2 k bits (k=0..7) Data2 N data2 bits Pilot N pilot bits Slot #0 Slot #1 Slot #i Slot #14 One radio frame, T f = 10 ms Figura 4.32: Struttura del radio frame e dei canali DPDCH e DPCCH in downlink La modulazione QPSK usata permette di inserire su un solo canale i dati di controllo e di utente. Lo Spreading Factor nel downlink varia da 512 a 4; i bitrate supportati dal DPCH variano da 15 kb/s (SF=512) a 1920 kb/s (SF=4). 63

67 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 5 Il controllo di potenza per i canali dedicati DPDCH e DPCCH 5.1 Introduzione Il controllo di potenza è uno degli aspetti più importanti nel WCDMA, soprattutto per l uplink. Senza alcun controllo sulla potenza trasmessa, un terminale vicino a una Base Station (BS) potrebbe bloccare l intera cella, o comunque pregiudicare il collegamento di terminali lontani dalla BS, dando luogo ad un problema di tipo nearfar. La strategia ottima per massimizzare la capacità della cella consiste nell equalizzare la potenza per bit che la BS riceve da ogni terminale. Nello standard UMTS sono definite delle procedure separate per il controllo sui canali comuni da quelle per i canali dedicati: I canali comuni in uplink utilizzano una procedura definita Open Loop Power Control. 64

68 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 I canali dedicati utilizzano invece una procedura definita Closed Loop Power Control. Questa, a sua volta, sfrutta due procedure denominate Inner Loop e Outer Loop. Mentre il controllo open loop applicato sui canali comuni determina la qualità delle risorse condivise, i controlli closed loop hanno lo scopo di mantenere la qualità della comunicazione tra UTRAN e UE con un valore di SIR (Signal to Interference Ratio) il più vicino possibile al minimo richiesto per la tipologia del servizio richiesto. Infatti, minore è il SIR richiesto, minore sarà la potenza trasmessa, e maggiore il numero di utenti per cella. È evidente quindi l importanza, nel contesto di una videocomunicazione UMTS, di poter accettare un elevato numero di errori in aria (quindi una bassa potenza di trasmissione), pur mantenendo una buona qualità del video. Il tema degli errori nel flusso video sarà sviluppato e approfondito nel capitolo successivo. Open Loop Power Contol: questo tipo di controllo viene utilizzato quando il terminale mobile è in stato di riposo. La stazione base (Node-B) invia sui canali comuni di controllo (BCCH) l'informazione della potenza con cui sta trasmettendo sul PCCPCH, il terminale compara questa informazione con il segnale effettivamente ricevuto ed è in grado di calcolare l'attenuazione di tratta e stimare il livello di potenza necessario per raggiungere un determinato SIR nella direzione uplink del canale RACH. Quando il terminale avvia una procedura di richiesta di connessione inizia a trasmettere con un livello di potenza di 10 db sotto il livello stimato e, se il Node-B non riesce a ricevere correttamente il mobile, quest'ultimo ripete la richiesta aumentando progressivamente la potenza fino a raggiungere il massimo livello calcolato dalle informazioni del sistema. Questa procedura garantisce che una richiesta per una nuova connessione non vada ad interferire con le comunicazioni già in corso. Inner Loop Power Control: questo controllo, che viene denominato anche Fast Closed Loop Power Control, ha il compito di rispondere alle variazioni repentine delle caratteristiche di propagazione (fast Rayleigh fading), ed è basato sui segnali 65

69 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 effettivamente ricevuti dal Node-B e dall'ue durante la connessione. Entrambi gli elementi della rete misurano il SIR ricevuto (SIR est ), e lo comparano con l'obiettivo di SIR ottimale comunicato dall'rnc tramite i canali di controllo (SIR target ). Se il Node-B rileva un SIR est più basso del valore SIR target definito dall'rnc, viene inviato al terminale un comando TPC con la richiesta di aumentare la potenza in Tx. La stessa procedura viene eseguita dal terminale mobile verso l'altra direzione del collegamento. Le motivazioni del power control in downlink sono differenti: in una situazione oneto-many non c è il problema near-far. Tutti i segnali in una cella sono inviati dalla BS verso tutti i terminali. Tuttavia, è preferibile fornire un margine di potenza addizionale per i terminali che si trovano a bordo cella, che soffrono di una maggiore interferenza dovuta alle altre celle. Il comando TPC (Transmit Power Control) trasporta l'informazione sulle variazioni di potenza, che in genere avvengono per quanti di 1 db. È comunque possibile con un solo comando far variare la potenza con un passo molto più ampio. Viene trasmesso 1500 volte al secondo in entrambe le direzioni, quindi una volta ogni time-slot: una tale frequenza di aggiornamento è più rapida anche del fast Rayleigh fading, almeno per terminali in movimento a velocità moderata. La logica con cui viene generato il TPC è la seguente: 1. Il SIR est è al SIR target, viene inviato il comando TPC di ridurre la potenza di un gradino. 2. Il SIR est è < al SIR target, viene inviato il comando TPC di aumentare la potenza di un gradino. È interessante notare che, anche se il SIR est è uguale al SIR target, viene comunque inviato un comando TPC di riduzione della potenza: questo comporta un continuo aggiustamento della potenza anche se la trasmissione si trova in condizioni ottimali. 66

70 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 Outer Loop Power Control: con il controllo outer loop il RNC determina il valore di SIR target che dovrà essere utilizzato nell'inner loop. Il RNC valuta le misure di qualità effettuate sul segnale (potenza Rx e BER) e, in funzione di questi valori e del tipo di servizio richiesto, stabilisce il SIR target da utilizzare sul collegamento. Questo controllo, che viene effettuato indipendentemente per ciascuna connessione, si aggiorna con una frequenza di circa 100 volte al secondo. L Outer Loop Power Control è tipicamente implementato verificando, tramite il campo CRC (aggiunto ai dati nello strato fisico), la frequenza degli errori. Se la qualità della trasmissione peggiora, l RNC comunica alla BS di incrementare il SIR target. 3GPP non specifica l algoritmo da utilizzare nella decisione del SIR target, ma impone solo che venga comunicato dal RNC alla BS. Sono quindi possibili diverse strategie per il calcolo del SIR target. L algoritmo descritto nel presente documento è di semplice implementazione, ma è particolarmente adatto allo studio degli effetti degli errori di canale sulle videocomunicazioni UMTS. L ipotesi fondamentale sulla quale si basa l algoritmo considerato è la lenta variazione del rapporto E b /N 0, intendendo con lenta quasi statica rispetto ai tempi di variazione del SIR target (1/100 s). In un caso quasi stazionario è possibile decidere il SIR target sulla base del BLER richiesto in maniera semplice. Se, per esempio, si richiede un BLER=10-2, si inizia la trasmissione dati con un SIR target standard, e ogni 1/100s viene valutato se il Transport Block ricevuto è corretto o meno. Se è corretto, il SIR target viene decrementato di uno step calcolato sulla base del rapporto E b /N 0 ; se il blocco è affetto da errore il SIR target viene incrementato di /BLER. Quindi se =0.1 db e 1/BLER=100, in caso di Transport Block affetto da errore il SIR target viene incrementato di 10 db. In una situazione statica, esisterà un SIR target minimo che con alta probabilità comporterà la ricezione di un blocco errato. A regime, verrà ricevuto un blocco errato ogni 100, come richiesto. 67

71 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 Nel seguito si farà sempre riferimento a una situazione di questo tipo, e tutti gli studi sugli effetti degli errori sulle videocomunicazioni UMTS si baseranno sull ipotesi di distribuzione uniforme dei Transport Block errati. Una tale ipotesi è quasi sempre verificata in ambienti quasi statici mediante un algoritmo simile a quello descritto in precedenza, e può essere verificata anche in situazioni non statiche (es. terminale in movimento, rapide fluttuazioni di tipo Rayleigh) mediante algoritmi diversi, basati su modelli più complessi. Lo studio di tecniche di error resilience effettuato è di fondamentale importanza in un ambiente basato su W-CDMA, come UMTS, in quanto direttamente collegato con la tematica del power control: le tecniche di error resilience descritte nel capitolo seguente, congiuntamente alle tecniche di error concealment sviluppate nel corso dello studio, delle quali si dà ampia descrizione nella tesi Tecniche di error concealment per videocomunicazioni real-time in ambiente UMTS a commutazione di pacchetto (di Paolo Cesare), hanno permesso di determinare un valore massimo di BLER (Block Error Rate sui Transport Block) per mantenere accettabile la qualità della sequenza video mostrata al terminale in ricezione. Maggiore è il tasso di errore tollerabile, minore sarà il SIR target richiesto, con evidenti benefici a tutti gli utenti della cella. L ipotesi di uniformità della distribuzione dell errore permette di studiare solo il caso di collegamento in ambiente quasi statico, ma la forte limitazione è stata scelta anche per fornire un modello base, dal quale è poi possibile partire per approfondire lo studio in situazioni più complesse. 5.2 Uplink power control per i canali DPCCH e DPDCH La potenza iniziale in trasmissione in uplink è settata dagli strati superiori. Successivamente la procedura di power control gestisce il livello di potenza del canale DPCCH e del corrispondente DPDCH nel caso in cui fosse presente. L operazione 68

72 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 dell anello interno di power control regola la potenza del DPCCH e del DPDCH alla stesso modo, senza apportare variazioni al fattore di guadagno. Ogni eventuale cambiamento della potenza trasmessa sul DPCCH viene attuato immediatamente prima della partenza del campo PILOT. Il cambiamento rispetto al valore precedente è segnalato dalla UE ed è denotato con DPCCH (in db). Il valore rispetto al quale si effettua la variazione è sempre quello dello slot precedente eccetto per il caso di trasmissione in modalità compressa. In tale eventualità infatti ci si riferisce al livello di potenza dell ultimo slot prima del transmission gap. Durante la procedura di controllo la potenza trasmessa dalla UE non eccede un valore massimo consentito che è tenuto al di sotto del massimo valore di potenza di uscita erogabile dal terminale e di un valore che può essere settato dalla segnalazione degli strati superiori. Il controllo di potenza sarà eseguito mentre la potenza trasmessa dalla UE è al di sotto di questo valore. L anello interno di controllo di potenza regola il livello di potenza al fine di mantenere il signal-to-interference (SIR) ricevuto ad un dato SIR target (SIR target ). Le celle in servizio dovrebbero stimare il rapporto segnale interferenza (SIR est ) ricevuto sul canale in uplink per poi generare un comando di TPC da trasmettere una volta per slot secondo le seguenti regole: se SIR est >SIR target il comando TPC trasmesso assumerà il valore 0 ; se SIR est <SIR target il comando TPC trasmesso assumerà il valore 1. In caso di ricezione di più comandi di TPC relativi ad un singolo slot la UE li combinerà assieme per ottenere da essi un singolo TPC (TPC_cmd). Nel fare ciò la UE avrà il supporto di due algoritmi. Quale di essi debba essere usato è specificato da un parametro specifico di strato alto PowerControlAlgorithm ed è sotto il controllo dell UTRAN. Se questo campo indica il valore algoritmo 1 allora il parametro di strati 1 PCA assume il valore 1; se il campo dello strato più alto indica il valore algoritmo 2 allora il PCA assume il valore 2. 69

73 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 Il passo TPC è un parametro di strato 1 derivato anch esso dal corrispondente parametro specifico dello strato più alto TPC-StepSize il quale è sotto il controllo dell UTRAN. Se quest ultimo indica il valore db1 TPC assume il valore 1 db; se indica il valore db2 TPC assume il valore 2 db. Il parametro TPC-StepSize è applicato solo all algoritmo 1 poiché nell algoritmo 2 il TPC è settato sempre a 2 db. Una volta ottenuti i valori sopra descritti la UE regolerà la potenza trasmessa sul DPCCH con un passo DPCCH in accordo alla seguente formula: DPCCH (db)= TPC x TPC_cmd. 5.3 Downlink power control per i canali DPCCH e DPDCH Il controllo di potenza in downlink controlla contemporaneamente i canali DPDCH e DPCCH. Le variazioni di potenza sono uguali per i due canali, quindi rimane invariato il di potenza tra i due canali, che viene determinato dalla rete. I campi TFCI, TPC, e PILOT del DPCCH hanno un offset di potenza rispettivamente di PO1, PO2, PO3 db rispetto alla potenza del DPDCH. I valori di offset possono variare nel tempo mediante segnalazione SSDT. 70

74 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap Comportamento del terminale Il terminale genera i comandi TPC per controllare la potenza trasmessa dalla BS, e li inserisce nel campo TPC del DPCCH in uplink. L UE verifica la modalità di power control in downlink (DPC_MODE, deciso da UTRAN) per scegliere tra due modalità di generare il comando TPC: 1. se DPC_MODE è impostato a 0, il terminale manda un comando TPC in ogni slot, e lo trasmette nel primo campo TPC libero nel uplink DPCCH 2. se DPC_MODE è impostato a 1, il terminale ripete lo stesso comando TPC per 3 slot e il nuovo comando TPC è trasmesso in modo tale da avere un nuovo TPC all inizio di ogni frame Comportamento dell UTRAN Dopo aver ricevuto il comando TPC, UTRAN regola la potenza di trasmissione. Se DPC_MODE=0, UTRAN stima il comando TPC ogni slot, modificando di conseguenza la potenza di trasmissione. Se DPC_MODE=1, la stima e le variazioni di potenza si ripetono ogni tre slot. Dopo aver ricevuto il k-imo comando TPC, UTRAN varia la potenza attuale P(k-1) secondo la formula: P(k)=P(k-1)+P TPC (k)+p bal (k), dove P TPC (k) è il k-imo aggiustamento di potenza dovuto all inner loop power control, e P bal (k) è una correzione necessaria per bilanciare i livelli di potenza sui radio link. Per quanto riguarda il calcolo di P TPC (k): se il valore di Limited Power Increase Used è Not used, allora 71

75 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 P TPC + TPC if TPCest( k) = 1 ( k ) =, [db]. TPC if TPCest ( k) = 0 Se Limited Power Increase Used è impostato a Used, allora P TPC + ( k) = 0 TPC TPC se TPC se TPC est est ( k) = 1 ( k) = 1 e e sum( k) + TPC < Power_Raise_Limit sum( k) + TPC Power_Raise_Limit, [db] se TPC ( k) = 0 est dove sum ( k) = k 1 PTPC ( i) i= k DL_Power_Averaging_Window_Size è la somma temporanea degli ultimi DL_Power_Averaging_Window_Size aggiustamenti (in db) dell inner power loop. Per la prima variazione di potenza dopo l attivazione della modalità Limited Power Increase Used, si usa la formula (1), invece della (2). Power_Raise_Limit e DL_Power_Averaging_Window_Size sono configurati da UTRAN. Il parametro TPC può assumere quattro valori: 0.5, 1, 1.5 o 2 db. È mandatorio per UTRAN supportare variazioni di 1 db, mentre gli altri valori sono opzionali. A quanto descritto sopra possono essere applicate restrizioni particolari: 1. in caso di rete congestionata, UTRAN può ignorare i comandi TPC provenienti dal terminale; 72

76 Il controllo di potenza per i canali dedicati DPDCH e DPCCH Cap.5 2. la potenza media dei simboli trasmessi sul DPDCH non può superare Maximum_DL_Power (db), né essere inferiore a Minimum_DL_Power (db). Per simbolo si intende un simbolo QPSK prima dello spreading, che non contenga DTX. Maximum_DL_Power (db) e Minimum_DL_Power (db) sono limiti validi per un channelisation code. 73

77 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 6 Effetti di errori sul canale e tecniche di error resilience implementate 6.1 Introduzione Le reti mobili sono caratterizzate da caratteristiche trasmissive altamente variabili, a seconda delle condizioni del collegamento radio (interferenza di altri terminali, multipath, ostacoli). In particolare in ambiente UMTS riveste fondamentale importanza l interferenza degli altri terminali, motivo per il quale uno degli aspetti critici della tratta radio di un collegamento UMTS è il controllo di potenza, già descritto in precedenza. Per permettere al maggior numero di utenti possibile di utilizzare la stessa cella, quindi, è necessario cercare di minimizzare la potenza di trasmissione di ogni terminale. Chiaramente, a un abbassamento della potenza trasmessa in una connessione corrisponde, per l utente in ricezione, una diminuzione della potenza ricevuta. Aumenta quindi il tasso di errore del canale. Per quanto riguarda l aspetto della trasmissione di video real-time, è quindi necessario ottimizzare il codec video non solo in funzione di un compromesso banda-qualità, ma anche tenendo conto dei benefici che porta alla rete 74

78 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 una potenza di trasmissione minore per ogni terminale. È necessario, quindi, che le prestazioni del codec vengano ottimizzate in funzione del tasso di errore nel canale, che, come detto, è inversamente proporzionale alla potenza trasmessa. Lo scopo di questo capitolo è descrivere tecniche che permettano di ottenere sequenze video di qualità accettabile, pur essendo affette da una quantità considerevole di errori. Una sequenza di immagini non codificata contiene ridondanza spaziale e temporale, che il codificatore sfrutta ed elimina per ottenere un flusso codificato a basso bitrate. Tuttavia, la perdita di ridondanza compromette la resistenza agli errori del flusso se il segnale è trasmesso su un canale con errori, come quello radio. L effetto del canale può essere modellato, in prima approssimazione, da errori a burst, ovvero si verificano sequenze di più bit consecutivi errati, piuttosto che errori su singoli bit. L uso di codifica di canale e interleaving decorrelano gli errori, permettendo quindi di considerare un canale equivalente affetto da errori sparsi. In particolare, è stato visto che il flusso codificato di bit, in ambiente UMTS, viene protetto per mezzo di interleaving (uno fisso da 10 ms più un interleaving opzionale di durata variabile), turbocodifica, o codifica convoluzionale, ed infine un codice CRC a protezione dei Transport Block. Come spiegato nei capitoli precedenti, per la simulazione degli effetti degli errori di canale sul flusso video, è stata ipotizzata la presenza di un interleaving opzionale da 40 ms, di un turbocodice 1:3, e di un codice CRC da 16 bit per ogni Transport Block da 640 bit, come mostrato in figura 4.6. Il codice CRC da 16 bit permette, su ogni Transport Block, di correggere fino a 7 bit errati su 640, e di rivelarne da 8 a 15. Il parametro più importante a livello di canale è il Bit Error Rate (BER); nella presente tesi sarà invece considerato il tasso di Transport Block errati, ovvero il BLER (BLock Error Rate). Verranno analizzate varie tecniche di error resilience e error concealment, al fine di ottenere il minimo BLER da richiedere per una qualità accettabile del video. La qualità del video sarà valutata mediante analisi del PSNR dei singoli frame. 75

79 Effetti di errori sul canale e tecniche di error resilience implementate Cap Effetti degli errori sul flusso video Come descritto nel paragrafo precedente, ogni Transport Block che viene trasmesso allo strato due può trovarsi in tre stati: 1. TB privo di errori, in quanto ricevuto correttamente, oppure affetto da meno di 8 bit errati, e quindi corretti dal CRC 2. TB affetto da un numero di bit errati compresi tra 8 e 15: il TB viene comunque inviato allo strato due, con la segnalazione dell errore riscontrato 3. TB affetto da più di 15 bit errati, quindi giudicato corretto dallo strato fisico. Lo studio presentato è orientato alla prevenzione e al trattamento degli effetti sul video degli errori del secondo tipo, quindi segnalati agli strati superiori, ma verrà mostrato come possa essere utile anche con errori del terzo tipo. Inoltre, sono state applicate alcune ipotesi semplificative: 1. gli errori non cadono sugli header IP, UDP, RTP 2. gli errori non cadono sugli header del quadro Come detto, nella architettura considerata, il numero minimo di bit errati per ogni Transport Block trasmesso allo strato due è 7. Tuttavia, nel caso di codifica video, la presenza di uno o più bit consecutivi errati produce quasi sempre gli stessi effetti. Infatti, un errore sul bit può avere effetti limitatamente distruttivi, può provocare la perdita di un blocco codificato, o causare perdita di sincronia, costringendo il decodificatore a scartare tutti i bit fino al successivo marker di risincronizzazione. Negli ultimi due casi, quindi, l effetto di un singolo errore diventa equivalente a quello di un errore a burst: 76

80 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 1. un errore con effetti limitatamente distruttivi è, ad esempio, quello su un bit di un coefficiente DC INTRA di un macroblocco. Il decodificatore non perde la sincronia, in quanto i coefficienti DC INTRA sono sempre trasmessi con 8 bit, e l effetto sul video è limitato a una perdita di qualità solo sul MB corrente. Questo tipo di errore è il meno distruttivo; in questo caso, un singolo errore sul bit più significativo del coefficiente DC è equivalente a 7 errori consecutivi sui bit dello stesso coefficiente; 2. un errore su un bit di una parola VLC causa danni maggiori: in questo caso, il decoder non riesce a interpretare correttamente l informazione ricevuta dal punto in cui si verifica l errore in poi, e salta tutti i bit successivi, corretti o meno, in cerca del successivo marker di sincronizzazione valido. In questo caso, quindi, un errore su un singolo bit ha l effetto di un errore a burst. In più, oltre a una eventuale propagazione spaziale dell errore, si può verificare una propagazione temporale dell errore, in quanto gran parte dell informazione ricevuta, corretta o meno, viene utilizzata per predirre alcune caratteristiche del quadro successivo. Ad esempio, un errore su un Motion Vector non rimane limitato al quadro affetto da errore, ma si propaga ai quadri successivi, a causa della natura differenziale della codifica dei quadri P. Il ritorno a una situazione corretta avviene solo al successivo quadro INTRA. Sono necessarie, nella codifica, tecniche che migliorino la robustezza del flusso video agli errori (error resilience tools). Alcuni errori non possono tuttavia essere corretti, e si procede a una post-processazione del segnale video nel decodificatore, per evitare che errori residui non rivelati portino a evidenti distorsioni dell immagine. Si parla in questo caso di tecniche di error concealment. 77

81 Effetti di errori sul canale e tecniche di error resilience implementate Cap Error Resilience Tools in H.263 Nel presente paragrafo vengono analizzati alcuni metodi, proposti in letteratura, o pensati ex novo, per aumentare la robustezza all errore di un flusso video H.263. Tra le tecniche descritte in letteratura, soprattutto due sono di particolare rilievo: 1. Protezione degli I-Frame. Ipotizzando un errore su un bit di una parola VLC all inizio di un I-Frame, nel caso che sia usato un solo marker di sincronizzazione per frame, l intero I-Frame verrà scartato dal decoder, causando una propagazione distruttiva dell errore nei P-Frame successivi, con un ritorno alla normalità solo con il successivo I-Frame. Poiché i coefficienti DC INTRA hanno lunghezza fissa, si può pensare di trasmettere prima tutti i coefficienti DC e poi le parole VLC. In questo modo, un errore su una parola VLC non pregiudica l intero I-Frame. Ad esempio, nel formato QCIF si usano 6 coefficienti DC INTRA per MB (quattro di luminanza e due di crominanza), per un totale di 594, ciascuno rappresentato da 8 bit. Nel H.263 classico si trasmettono, per ogni MB, il coefficiente DC e poi le parole a lunghezza variabile. Il metodo descritto, invece, invia prima i 594 byte dei coefficienti DC (4752 bit), e poi le parole VLC. Allora, un errore su un bit delle VLC non pregiudica il recupero dei coefficienti DC, e si evita quindi di perdere l intero frame. Un errore su una qualunque delle 594 parole dei coefficienti DC pregiudica solo quel valore, e, poiché l errore è su una parola di lunghezza fissa (8 bit), non viene persa la sincronia. 2. Impacchettamento di una GOB per pacchetto RTP. Se, come nel caso considerato, il flusso H.263 è incapsulato secondo il protocollo RTP, è possibile scegliere la grandezza del campo dati di ogni pacchetto RTP. In ambiente UMTS, ci sono tre motivi per decidere di impacchettare ogni GOB di un quadro I in un pacchetto RTP: 78

82 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 a. Sapendo che ogni GOB è in un pacchetto differente, un errore su una GOB non si propaga oltre la fine della GOB stessa; infatti, anche scegliendo di non usare l header della GOB, il campo dati del pacchetto RTP inizia sempre con la componente continua del primo blocco della GOB. È quindi possibile recuperare da errori precedenti; b. per un flusso a 48 kbit/s, l impacchettamento in RTP permette di limitare il delay end-to-end, rimanendo nelle specifiche della classe conversational; c. è consigliabile che i pacchetti RTP non eccedano i 1500 byte circa, per evitare segmentazione a livello IP, che aumenterebbe il ritardo di trasmissione. Le due tecniche illustrate comportano entrambe miglioramenti nella robustezza del flusso codificato all errore. Tuttavia, in ambiente UMTS, non è pensabile l invio delle componenti DC prima delle parole VLC: per i tre motivi descritti, è importante incapsulare una GOB in ogni pacchetto RTP. Nel seguito, si supporrà che ogni GOB di un quadro I sia il payload di un singolo pacchetto RTP. Per quanto riguarda i quadri P, non è pensabile ragionare come sopra: le dimensioni di un quadro P codificato variano da poche centinaia a poche migliaia di bit. Un impacchettamento RTP per GOB porterebbe a un eccessivo incremento di banda. È stato quindi scelto, per i quadri di tipo INTER, di incapsulare un intero quadro in ogni pacchetto RTP, adottando altre strategie per aumentare la resistenza del flusso codificato agli errori. Passando alle tecniche sviluppate nel corso della sperimentazione, si è deciso di intervenire cercando di prevenire i due tipi di propagazione dell errore che si verificano quando una parola VLC è affetta da errori: è quindi stata limitata la propagazione spaziale degli errori, nei quadri I, e la propagazione temporale degli errori, per quanto riguarda i quadri P. 79

83 Effetti di errori sul canale e tecniche di error resilience implementate Cap Error resilience nei quadri codificati INTRA Come detto in precedenza, anche per motivi legati al ritardo end-to-end, ogni GOB di un quadro I fa parte di un singolo pacchetto RTP. Tuttavia, nel caso di errore all inizio del payload RTP, l intera GOB viene persa (figure 6.1 e 6.2) Figura 6.33: quadro INTRA privo di errori Figura 6.34: propagazione spaziale dell errore in una quadro INTRA Un errore di questo tipo comporta due problemi: 1. la perdita di tutta una GOB, oltre a essere molto evidente all occhio, porta il PSNR a valori decisamente bassi ( da 30 db del frame privo di errori a 19.6) 80

84 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 2. una propagazione temporale dell errore nei frame P successivi: in figura 6.3 è mostrato il 15 frame, l ultimo prima del successivo quadro I. L errore si è propagato seguendo il movimento dei quadri successivi. Figura 6.35: propagazione dell errore sul quadro INTRA al quindicesimo quadro INTER La soluzione implementata per ridurre la propagazione spaziale dell errore prevede l inserimento, nel flusso codificato, di due marker di sincronizzazione, della lunghezza fissa di 15 bit. In questo modo, in presenza di un errore su una parola VLC, nella maggior parte dei casi è possibile non perdere tutta la GOB. Quando il decoder trova un parola VLC inesistente cerca, avanzando bit a bit con una finestra da 15 bit, la parola di risincronizzazione. Il recupero della sincronia non è automatico: in alcuni casi l errore non trasforma la parola VLC in un insieme di bit senza significato, ma in un altra parola VLC, compromettendo l utilità del marker, se l errore non viene rivelato prima di esso. In figura 6.4 vengono mostrati alcuni esempi di errore nel flusso H.263 in presenza dei marker: nei primi due casi (6.4a e 6.4b), l errore viene rivelato dal decoder, e, identificato il marker, viene ripristinata la correttezza della decodifica. Nel terzo caso (6.4c), il decoder rivela l errore quando ormai il marker è stato già superato: in questa situazione 2/3 di GOB sono danneggiati. 81

85 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 6.4a 6.4b 6.4c Figura 6.36: limitazione della propagazione dell errore nel quadro INTRA La banda in più necessaria per l inserimento dei marker è di 15*2*9=270 bit per ogni quadro I. Poiché un quadro I ricorre ogni secondo, l aumento di banda è di 270 bit/s, sicuramente accettabile nel contesto UMTS. Considerazioni più approfondite sul trade-off banda/qualità in presenza di tecniche di error resilience saranno presentate in seguito. E da notare che l inserimento dei marker proposto rende il flusso codificato non conforme all H Error resilience nei quadri codificati INTER I quadri INTER, diversamente dai quadri INTRA, vengono incapsulati ognuno in un pacchetto RTP. È già stato detto che non è pensabile l uso dei marker di sincronizzazione anche per i quadri INTER: infatti l aumento di banda sarebbe di 15*2*9*15=4050 bit/s, troppo per una codifica a 48 kbit/s. La soluzione proposta è, anche in questo caso, non compatibile con lo standard H.263: solitamente i quadri P sono riferiti al quadro precedente, sia questo di tipo I o P. Un errore su un quadro P comporta la propagazione temporale dell errore in tutti i quadri P successivi, fino alla ricezione di un nuovo quadro I. Un primo metodo per evitare la propagazione temporale dell errore consiste nel permettere che i quadri P siano riferiti sempre all ultimo quadro I ricevuto, e non al quadro precedente. In questo modo, un eventuale errore su un quadro P danneggia solo il quadro interessato, e può essere facilmente mascherato mediante tecniche di error concealment. Tuttavia, il riferire tutti i quadri P al quadro I, 82

86 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 anche in presenza di soli 15 quadri predetti tra due quadri INTRA, comporta un aumento di banda che, in sequenze movimentate come Carphone, può arrivare anche al 50%. Una soluzione di questo tipo è, pertanto, inapplicabile. Analizzando in dettaglio le dimensioni dei singoli quadri codificati si è visto che i quadri finali di una GOP, se riferiti al quadro I, e non al precedente, diventano di dimensioni anche doppie rispetto alla codifica riferita al quadro precedente. Sono pertanto gli ultimi quadri della GOP a pesare maggiormente sull aumento totale di banda. La soluzione proposta prevede di riferire al quadro I i primi 6 quadri P della GOP, e al precedente i quadri successivi. Questa tecnica presenta numerosi vantaggi: 1. la propagazione dell errore è bloccata per i primi 6 quadri P (chiaramente nell ipotesi di ricezione corretta del quadro I), al prezzo di un modesto aumento di banda, che verrà analizzato in seguito; 2. eventuali errori che colpiscano gli ultimi frame di una GOP saranno propagati per un tempo, al massimo, di mezzo secondo, diversamente dalla propagazione per tutta la GOP di errori sul primo frame P con codifica tradizionale; 3. il metodo descritto rende facilmente applicabili tecniche di error concealment basate sul confronto tra un frame e il precedente Occupazione di banda e qualità Passando a descrivere le prestazioni delle due tecniche di error resilience implementate, una prima verifica importante riguarda il compromesso banda/qualità. Come si nota dai grafico delle figure 6.5, 6.6 e 6.7, grazie all algoritmo di controllo di flusso sviluppato, la banda occupata non è variata nelle sequenze meno movimentate, come Claire, o Salesman, mentre è aumentata nelle scene finali di Carphone. 83

87 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 Carphone: controllo di flusso e resilience no resilience resilience bit/s GOP Figura 6.37: occupazione di banda con e senza tecniche di error resilience per la sequenza Carphone Claire: controllo di flusso e resilience no resilience resilience bit/s GOP Figura 6.38: occupazione di banda con e senza tecniche di error resilience per la sequenza Claire 84

88 Effetti di errori sul canale e tecniche di error resilience implementate Cap Salesman: controllo di flusso e resilience no resilience resilience bit/s GOP Figura 6.39: occupazione di banda con e senza tecniche di error resilience per la sequenza Salesman Verificato l effettivo mantenimento della banda occupata, va analizzato il PSNR delle sequenze codificate con le tecniche di error resilience in confronto con la codifica classica, per verificare se il mantenimento della banda sia a scapito della qualità. I risultati, in figura, mostrano che anche i valori di PSNR delle sequenze considerate rimangono, dopo co-decodifica resilient sui valori della codifica classica, o comunque poco sotto. I valori bassi del PSNR di alcuni frame, soprattutto della sequenza Carphone, sono causati dal frame-skipping. Per tali frame, valori bassi del PSNR non sono indicativi di scarsa qualità del video: in caso di frame skippati è da valutare la fluidità del video, piuttosto che il valore del PSNR. 85

89 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 Carphone: PSNR e resilience no resilience resilience PSNR frame Figura 6.40: a confronto il PSNR della sequenza Carphone con e senza tecniche di error resilience Claire: PSNR e resilience no resilience resilience PSNR frame Figura 6.41: a confronto il PSNR della sequenza Claire con e senza tecniche di error resilience 86

90 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 PSNR Salesman: PSNR e resilience no resilience resilience frame Figura 6.42: a confronto il PSNR della sequenza Salesman con e senza tecniche di error resilience Prestazioni delle tecniche implementate Senza dubbio, in caso di assenza di errori nel flusso codificato, sarebbe da preferire una codifica classica. Tuttavia, passando a considerare BLER vicini a quelli tipici di una rete UMTS (es ), i miglioramenti dovuti alle tecniche di error resilience implementate consentono una minore perdita di informazione, rimanendo, come mostrato, su valori di qualità molto vicini a una codifica non resilient, e rendono più semplice ed efficace l utilizzo di tecniche di error concealment, non trattate nella presente tesi, ma delle quali si accenna nelle conclusioni. Nel seguito del capitolo 87

91 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 verranno confrontati alcuni frame INTRA codificati senza tecniche di error resilience e affetti da errore con gli stessi frame codificati in maniera robusta all errore e affetti dagli stessi errori. Lo stesso confronto sarà poi mostrato per alcune sequenze di quadri INTER. In figura 6.11 è mostrato un quadro codificato INTRA della sequenza Carphone senza errori, lo stesso quadro codificato senza tecniche di error resilience nel quale è danneggiato il terzo macroblocco della seconda GOB, e sempre lo stesso quadro codificato con i marker di sincronizzazione proposti e affetto dallo stesso errore. 6.11a: PSNR b: PSNR c: PSNR 26.4 Figura 6.43: prestazioni delle tecniche di error resilience per i quadri INTRA Il miglioramento dal punto di vista del PSNR è evidente, e la tecnica di error resilience adottata limita la propagazione spaziale dell errore, rendendo anche migliore il risultato di un successivo error concealment, che nasconderà del tutto l errore. 88

92 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 Nelle figure 6.12 e 6.13 vengono mostrate situazioni simili per quadri INTRA delle sequenze Claire e Salesman. 6.12a: PSNR b: PSNR c: PSNR 23.4 Figura 6.44: prestazioni delle tecniche di error resilience per i quadri INTRA 6.13a: PSNR b: PSNR c: PSNR 26.5 Figura 6.45: prestazioni delle tecniche di error resilience per i quadri INTRA Nelle figure 6.14 e 6.15 verranno mostrate le prestazioni della tecnica di error resilience implementata per i quadri INTER applicata alla sequenza Carphone. 89

93 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 Verranno mostrati alcuni quadri P consecutivi, dei quali uno affetto da errore, nei due casi di codifica non robusta e di codifica resilient. Figura 6.46: il secondo quadro della sequenza è affetto da errore. In assenza di tecniche di error resilience, l errore si propaga Figura 6.47: lo stesso errore della figura 6.14 non può propagarsi, grazie alle tecniche di error resilience sviluppate 90

94 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 Come si nota dalle immagini proposte, nel caso di codifica senza resilience tools, un errore su un quadro INTER (seconda immagine) permane, e si propaga anche ai quadri successivi, in quanto ogni quadro è riferito al precedente. Permettendo che i quadri P siano riferiti al quadro I, la propagazione dell errore è cancellata: nel secondo gruppo di immagini, infatti, solo il secondo quadro è errato, mentre gli altri sono intatti. Con questo metodo, anche un concealment del quadro danneggiato è un operazione semplice: basta infatti sostituirlo con il precedente, ottenendo solo un effetto simile a quello dovuto a frame-skipping. In conclusione, è stato mostrato come rinunciando in minima parte alla qualità media della sequenza video, si possa ottenere una elevata robustezza all errore, che permette al decodificatore di utilizzare tecniche di error concealment, descritte brevemente nel prossimo paragrafo, con risultati molto migliori dell uso di error concealment su sequenze codificate in maniera non robusta. 6.4 Cenni sulle tecniche di error concealment Con il termine error concealment si fa riferimento a un post-processing di una sequenza (o di un singolo frame) affetta da errore, al fine di nascondere gli effetti dell errore sull immagine. Il post-processing può essere effettuato mediante interpolazione delle porzioni di immagine non corrotte, o mediante sostituzione di alcuni blocchi del quadro affetto da errore con blocchi del quadro precedente. Nel presente paragrafo verranno brevemente descritte le ipotesi sulle quali si basano le tecniche di error concealment sviluppate durante il lavoro, ma non presentate in questa tesi. Verrà quindi mostrato come le tecniche di error resilience presentate permettano un concealment più semplice ed efficace di quello applicabile a sequenze prive di tecniche di error resilience. Il concealment dei quadri I prevede la sostituzione dei macroblocchi affetti da errore con i macroblocchi corrispondenti del quadro 91

95 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 precedente, che nel caso studiato è il 15 (e ultimo) quadro P della GOP (in seguito quadro P15). Per poter effettuare concealment sul quadro I è necessario che il quadro P15 non sia affetto da errore, o comunque danneggiato a causa di propagazione degli errori. Se nessuna tecnica di error resilience fosse stata applicata sul flusso video, un errore su un qualsiasi P-frame della GOP si sarebbe propagato fino a P15, rendendolo inutilizzabile per il concealment. Un primo vantaggio dell uso delle tecniche di resilience sui quadri P descritte in precedenza è che un errore su uno dei primi 6 quadri della GOP rimane temporalmente localizzato e non può propagarsi fino a P15. La probabilità che P15 sia danneggiato scende da quella che capiti un errore in uno dei quadri nell intervallo P1-P15 a quella che capiti un errore nell intervallo P7-P15. È evidente che, grazie al resilience dei quadri P, è possibile applicare tecniche di concealment sui quadri I in un numero maggiore di casi. Sempre considerando il concealment dei quadri I, è da sottolineare come il numero dei macroblocchi da sostituire influisca sulla qualità del frame dopo PSNR. È stato visto che l utilizzo delle tecniche di error resilience sviluppate per i quadri I limita la propagazione spaziale dell errore all interno della GOB. L applicazione di tali tecniche consente, nel caso peggiore, di operare concealment su un terzo di GOB (quindi 3 o 4 macroblocchi), piuttosto che su tutta la GOB, ottenendo quindi valori di PSNR più elevati, e un quadro di riferimento molto vicino a quello effettivamente trasmesso, con evidente vantaggio per la qualità dei successivi quadri P. Passando a descrivere il concealment dei quadri P, è da notare che, a causa della natura predittivo-differenziale dei P frame, gli errori sul bitstream degli stessi raramente producono errori localizzati in una zona dell immagine. Più spesso un errore su un quadro P è caratterizzato da piccole distorsioni distribuite su tutto il quadro (figura 6.16). 92

96 Effetti di errori sul canale e tecniche di error resilience implementate Cap.6 Figura 6.48: errore su un frame INTER Per i frame P non è di facile applicazione un concealment del tipo utilizzato per i quadri I; si è scelto quindi di sostituire il frame P affetto da errore con il frame precedente, per errori sui primi 5 quadri P della GOP, e di non operare concealment nella seconda metà della GOB. Ricordando che la tecnica di resilience implementata prevede che i primi 6 quadri P (P1-P6) di una GOP siano codificati usando come riferimento il quadro I, un qualunque tipo di concealment effettuato sui primi 5 P frame di una GOP non avrà alcun effetto sugli altri frame della sequenza. Questa caratteristica risulta fondamentale in sequenze con elevato movimento: per video di questo tipo, ma privi di tecniche di error resilience, un concealment basato sulla sostituzione dell intero quadro con il precedente porta a un quadro spesso molto diverso dall originale. Al contrario, in molti casi un errore non danneggia eccessivamente il quadro, lasciando inalterate alcune caratteristiche del frame utilizzate per una corretta decodifica dei frame successivi. In questi casi la propagazione dell errore è molto più evidente nelle sequenze con il concealment attivo, che in quelle affette da errori, rendendo di fatto inutile il concealment stesso. Tuttavia, l adozione delle tecniche di error resilience per i quadri P descritte in precedenza permette di operare concealment sui primi 5 quadri P della GOP senza alcun tipo influenza sui quadri successivi. Eventuali errori nella 93