IPTV, la televisione arriva con l ADSL

Transcript

1 PIATTAFORME IPTV, la televisione arriva con l ADSL MAURO ORGHI GARIELE ELIA DARIO ERCOLE CLAUDIO FRANCO ENZO GASSINO John Chambers, il Presidente e CEO di Cisco Systems, ha dichiarato recentemente 1 : Video is emerging as the key strategic application in the service provider triple play bundle of consumer entertainment, communication and online services. As consumers demand more sophisticated information and entertainment services in their home, tightly coupled applications, devices and networks will be essential.... Il Triple Play, la convergenza del mondo del broadcasting e di quello della banda larga e della telefonia è uno dei fenomeni da lungo tempo previsti e annunciati ma che solo in questa decade sta diventando una delle realtà più importanti nel processo evolutivo della rete e dei servizi. La trasformazione del mondo del multimedia, grazie ad esempio ai nuovi protocolli di compressione come MPEG-4, l evoluzione delle piattaforme di rete IP, dei microprocessori per terminali, dei sistemi di protezione dei contenuti e la riduzione dei costi di vari componenti, in primis quelli dei sistemi di memoria di massa, hanno progressivamente reso economicamente possibile l introduzione di servizi TV attraverso reti broadband, quali l ADSL e le sue evoluzioni. Ma se l arrivo della TV ha da un lato posto nuove sfide in termini di costi e prestazioni all evoluzione delle reti IP, dall altro offre anche importanti possibilità e prospettive per l evoluzione dei servizi televisivi, in primo luogo con l introduzione di interattività e dei contenuti on demand. Questo articolo analizza le principali tecnologie che sono alla base di uno dei tre cardini di questa convergenza, la televisione su reti IP o, brevemente, la IPTV. 1. Introduzione Per comprendere pienamente le motivazioni che stanno alla base della crescente spinta verso il triple play occorre analizzare il macro scenario competitivo presente oggi nel mondo delle telecomunicazioni, gli sviluppi tecnologici nel campo della larga banda e delle piattaforme per i servizi multimediali basati sul paradigma IP ed infine i fattori sociologici che generano nuove esigenze e nuove richieste di servizio da parte della popolazione. (1) CMPILC-001 Lo scenario competitivo è caratterizzato in primo luogo da fattori commerciali, quali la diffusione dei servizi broadband e la necessità degli operatori di allargare la base degli utenti della larga banda con una seconda ondata, dopo quella degli utenti Internet da PC. Gli operatori di rete fissa devono inoltre compensare le perdite di ricavi dovute alla migrazione degli utenti verso i servizi mobili per il traffico voce; in questo contesto il cosiddetto triple play, con la possibilità di offrire attraverso un unica rete e un unico collegamento i servizi voce, broadband Internet e TV, sembra essere un ottima possibilità per mantenere i clienti e aumentare i fatturati. NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

2 Dal punto di vista tecnologico la convergenza su protocolli IP delle architetture di rete, con costi di rete decrescenti e crescente capacità di trasporto e commutazione di traffico, le nuove tecnologie di compressione del video, l evoluzione delle tecnologie hardware relativamente alla costruzione dei terminali o delle memorie di massa, permettono oggi la realizzazione di piattaforme di rete e di servizio triple play prima impossibili. Ultimi, ma non meno fondamentali per un effettivo successo dei servizi, i fattori sociologici che determinano una sempre maggiore disaffezione dalle forme tradizionali di televisione commerciale da parte di fasce crescenti di popolazione che si rivolgono altrove, per esempio ad Internet, per i loro bisogni di informazione ed intrattenimento; utenti questi che non riescono ad essere serviti dai tradizionali servizi TV. Di qui, l enorme diffusione dei servizi di scambio di contenuti attraverso i sistemi peer to peer in Internet, che, pur in violazione alle leggi sul copyright di molti Paesi, intasano i due terzi della banda di tutti gli operatori al mondo, dimostrando una fortissima richiesta latente di contenuti da parte dei nuovi clienti. IPTV si può definire, rispetto al mondo del broadcasting, come la prossima generazione di TV digitale, ma si pone obiettivi e utilizza architetture differenti da quelle del paradigma Internet TV o Internet streaming, cioè dello streaming di contenuti multimediali su Internet. Le differenze sono innanzitutto nel tipo di contenuti e palinsesti offerti agli utenti e nel tipo di terminale da utilizzare, ovvero la TV con il relativo settop box (ST), ma esiste anche una profonda differenza di modelli di business, cioè lo streaming su Internet tende ad essere un servizio offerto in maniera disgiunta dalle offerte di accesso alla rete broadband, e viene erogato da parte di operatori che occupano un anello della catena del valore distinto rispetto a quello degli ISP (Internet Service Provider) e dei NSP (Network Service Provider), i cui obiettivi sono quelli di raggiungere un pubblico spesso supernazionale o comunque esterno al bacino del singolo operatore di rete o Internet provider. Nell articolo cercheremo dunque di analizzare questi elementi di forza insieme a quelli che potrebbero rallentare o rendere poco conveniente, anche economicamente, la diffusione dei questi servizi. 2. Introduzione ai servizi dell ecosistema IPTV I servizi IPTV sono pensati per avere modalità di fruizione e semplicità di utilizzo tipiche del televisore; la loro metafora è differente dai servizi di accesso a contenuti multimediali attraverso portali a larga banda che sono presenti su Internet. L utente deve essere dotato di un apposito ricevitore (ST), simile ai prodotti per TV satellitare o DTT (Digital Terrestrial Television), collegato da un lato alla TV e dall altro, invece che a un cavo d antenna, a una connessione ADSL. In alcuni prodotti commerciali, il ST dispone già di un modem ADSL incorporato; in altri casi, il modem è esterno e collegato al ST tramite una connessione Ethernet, ad esempio. I servizi video IPTV si suddividono in Servizi di roadcast TV (TV) e Servizi di Video on Demand (VoD). I Servizi di roadcast TV consistono nella fruizione contemporanea da parte degli utenti di un canale televisivo tradizionale, Free to air o Pay TV, in maniera del tutto simile a quanto avviene sulla TV tradizionale; nel caso di servizio Pay Per View, l utente paga per vedere una trasmissione a un orario prestabilito. I canali live possono essere raggruppati in pacchetti di offerta (ad esempio: asic, Premium, ) che l utente può sottoscrivere. I servizi TV sfruttano tipicamente le funzionalità di multicast presenti su una rete IP. In generale, per i servizi TV le operazioni di selezione e programmazione dei canali, ma anche la navigazione per l acquisizione di informazioni sui contenuti, sono rese disponibili tramite la guida interattiva EPG (Electronic Program Guide) e vengono effettuate a video con l utilizzo del dispositivo remoto (telecomando e/o tastiera). Il service provider può creare e rendere disponibili EPG diversificate e personalizzate per profilo utente. Tra i servizi più specificamente legati ai contenuti TV, rientra il videoregistratore digitale o Personal Video Recorder (PVR) che nel mondo IPTV viene realizzato in due diverse modalità: Local PVR (LPVR): videoregistrazione digitale sull hard disk, che potrà essere collegato o interno al ST. Network-based PVR (NPVR): videoregistrazione digitale su spazio messo a disposizione nell infrastruttura (tipicamente su server) del service provider. La caratteristica di questo servizio è quella di consentire la memorizzazione contemporanea anche di più canali; inoltre, la quantità di memoria a disposizione è notevolmente più estesa rispetto a quella generalmente disponibile su hard disk locale. In entrambi i casi, durante la visualizzazione dei contenuti sono resi disponibili le funzionalità tipiche di un videoregistratore (trick play): play, pause, (fast-)rewind, (fast-)forward, stop ed eventuali funzionalità evolute, quali l instant replay. Per i servizi TV possono inoltre essere messe a disposizione dell utente le seguenti funzionalità: Time shifting: è il servizio che consente di richiedere e visualizzare contenuti che nel palinsesto TV erano programmati in precedenza (per un numero di giorni stabilito dal service provider); Pause Live TV: consente all utente di mettere in pausa il flusso video live che sta guardando e di riprendere la visione dal punto di interruzione in un momento successivo. I servizi di Video on Demand (VoD) permettono la visione su richiesta di contenuti multimediali messi a disposizione dal service provider. L utente interagisce direttamente con il catalogo creato dal service provider per navigare, richiedere, ricevere e 48 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

3 visualizzare in tempo reale (streaming) i contenuti audio/video di proprio gradimento, avendo a disposizione le funzioni tipiche di un videoregistratore (trick-play). Per l erogazione dei servizi VoD vengono principalmente utilizzati i tradizionali meccanismi di streaming unicast della rete IP; la qualità dell audiovisivo fruito dall utente è funzione della banda (garantita) disponibile e il numero di utenti servibili contemporaneamente dipende dalla capacità della rete che si è costruita. I meccanismi unicast possono però anche essere utilizzati in modalità diversa dallo streaming: con la modalità Download and Play (D&P), i contenuti vengono in parte o totalmente memorizzati sull hard disk, di cui deve essere provvisto il ST, e pertanto tra l istante di selezione del contenuto e la sua fruizione intercorre un certo lasso di tempo, che sarà funzione delle politiche commerciali adottate dal service provider. Da notare che, in questo caso, non essendoci contemporaneità tra trasmissione e visualizzazione, la banda garantita non dovrà necessariamente essere elevata. Sfruttando invece i meccanismi multicast su canali predefiniti, viene erogato il servizio Near VoD (NVoD), per il quale alcuni contenuti vengono ritrasmessi in modo continuativo ad intervalli di tempo prestabiliti. A tutti gli effetti, sia dal punto di vista dell erogazione che della fruizione da parte dell utente, si tratta di un servizio TV e può essere utilizzato dal service provider per trasmettere, ad esempio, i titoli più richiesti ad un costo inferiore rispetto al servizio VoD, in quanto consente di limitare il carico sui video server e sulla rete. Per tutti i servizi TV e VoD è disponibile la funzionalità di Parental Control che, tramite l utilizzo di login e password o di un semplice PIN, consente di limitare gli accessi ai contenuti su base rating (grado di violenza, pornografia) da parte di alcune classi di utenti della postazione (in primis a bambini e minori). Inoltre, interagendo tramite il dispositivo remoto con la UI (User Interface) dei servizi IPTV che viene creata dal service provider e visualizzata sul televisore, l utente potrà anche selezionare una serie di servizi interattivi messi a disposizione dal service provider, quali: Web rowsing: ovvero la possibilità di navigare in Internet dalla TV. Il servizio può essere fornito in configurazione full Internet, che può presentare talvolta problemi di look & feel delle pagine e di conseguenza limitare l usabilità dei siti, o walled garden, che comprende un insieme di portali informativi progettati per la navigazione televisiva ma che, in quanto tale, consente una navigazione limitata tra i soli siti consentiti dal service provider; Gaming: il ST funziona come game console; l utente può accedere ad un catalogo di giochi e tramite la connessione broadband può anche interagire con altri giocatori in ambienti multiplayer; Applicazioni di comunicazione: , SMS, MMS, Chat, VideoChat, multiroom viewing, 2.1 La protezione dei contenuti La diffusione a pagamento di contenuti digitali di valore implica rischi non indifferenti per tutti gli attori coinvolti nella catena del valore: sia il Content Provider, che ne cede i diritti d uso, sia il Service Provider, che effettivamente li commercializza e li distribuisce, sia l utente che li acquista sono infatti inevitabilmente esposti, ed in qualche misura indifesi, di fronte al pericolo di un potenziale utilizzo non autorizzato dei contenuti medesimi. Di qui la necessità di mettere in campo un adeguato sistema di protezione che tuteli tanto i soggetti quanto le risorse e che tipicamente si esplica secondo due modalità leggermente diverse: Conditional Access (CA) e Digital Rights Management (DRM). I sistemi di Conditional Access, che rappresentano la soluzione di protezione tradizionalmente impiegata nella televisione digitale, e quindi nell IPTV, si basano su tre componenti: roadcast Equipment: genera il flusso criptato da trasmettere. La chiave per la decifratura del flusso viene inserita negli Entitlement Control Message (ECM) i quali a loro volta vengono cifrati con la chiave dell Entitlement Management Message (EMM). Security Module (Smart Card): autorizza la decriptazione degli EMM e quindi degli ECM da cui viene ricavata la chiave per mettere in chiaro il flusso audiovisivo. ST: è il dispositivo che ospita il Security Module e che, ricevuta la chiave di decriptazione, decifra il segnale. L approccio è evidentemente di tipo on/off: chi è autorizzato ad accedere ai contenuti, lo fa senza alcuna restrizione. Nelle soluzioni DRM la salvaguardia dei contenuti di valore si esplica in modo tale che questi ultimi siano fruibili dagli utenti autorizzati esclusivamente in conformità a regole specificate dai Content Provider e registrate in apposite licenze d uso. Il rispetto di tali regole è garantito da un componente sicuro (hardware o software) presso il cliente, che esplica le funzioni di DRM ed interagisce da una parte con il Service Provider e dall altra con l utente. Il contenuto, quindi, può essere fruito esclusivamente dopo aver recuperato la licenza e solo, ad esempio, per un certo numero di volte, per un particolare intervallo di tempo o secondo una modalità specifica (duplicazione, spostamento, ). I sistemi di protezione dei contenuti, i CA ma in particolare i DRM, sono strategici e centrali nella catena del valore, per il controllo che creano contemporaneamente sugli utenti finali, sui fornitori di piattaforme e di terminali e sui fornitori di servizio. Non a caso attorno a questi sistemi si sta sviluppando un accesa battaglia fra varie aziende e consorzi, sia per il controllo del mercato che per le importanti royalties da brevetti che saranno riscosse. NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

4 Headend Video Distribution Headend Equipment IRD VOD Servers IRD Encoders Gigait Switches TV Management Platform Gigabit Ethernet Scrambling Transport ackbone Switch DSLAM Access IP ST with Smartcard 3. Il Centro Servizi Il Centro Servizi IPTV ospita tutte le componenti necessarie all erogazione e alla gestione dei servizi video. All interno del centro servizi sono collocati gli apparati che costituiscono l headend per l erogazione dei contenuti TV (roadcast TV) e dei contenuti VoD (Video on Demand), i server che ospitano il middleware IPTV e il sistema di CA/DRM utilizzato per la protezione dei contenuti. Content Protection System DSLAM IRD ST VOD Conditional Access System Digital Subscriber Line Access Multiplexer Integrated Receiver Decoder Set-Top ox Video On Demand FIGURA 1 Esempio di architettura del servizio IPTV. 2.2 L architettura del servizio I servizi IPTV vengono distribuiti tramite un architettura costituita da tre macro blocchi: Il Centro Servizi, che è costituito dagli elementi che concorrono nelle fasi di fornitura e gestione dei servizi stessi, quali l headend, per l acquisizione, l adattamento e la distribuzione dei contenuti live e i server, dove risiedono il middleware (lo strato software che consente l integrazione tra la piattaforma del service provider e lo strato tecnologico dell architettura) e il sistema per la protezione dei contenuti; La Rete di Trasporto, costituita dalla dorsale di trasporto e dalla rete metropolitana, cioè dagli apparati di instradamento dei pacchetti IP e dai collegamenti in fibra ottica; La Rete di accesso, costituita dalle componenti di raccolta/multiplazione e distribuzione verso gli apparati di rete domestica, dai collegamenti in fibra e rame e dalla rete domestica stessa (home network). Nella figura 1 è indicata la rappresentazione grafica di quanto fin qui brevemente accennato. IRD IRD Content Protection System Encoders Gigait Switches Gigabit Ethernet Scrambling DSLAM Digital Subscriber Line Access Multiplexer IRD Integrated Receiver Decoder ST Set-Top ox FIGURA 2 Distribuzione dei contenuti Multicast (TVLive). 3.1 Headend, contenuti TV Scopo dell headend è quello di acquisire dalla sorgente, adattare e distribuire i contenuti video live che fanno parte dell offerta dei servizi IPTV. L headend permette di interfacciare le diverse fonti di provenienza dei contenuti, quali possono essere ad esempio: reti di contribuzione dedicate o trasmissioni satellitari e digitali terrestri. I flussi video sono acquisiti dall headend sotto forma di stream digitali; nel caso siano previsti flussi di contribuzione analogici, questi sono convertiti in digitale (figura 2). I flussi digitali sono generalmente acquisiti in modalità non compressa in formato SDI (Serial Digital Interface) oppure in modalità compressa Trasporto ackbone Switch DSLAM Accesso IP ST with Smartcard Distribuzione contenuti Multicast Fruizione contenuti Multicast 50 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

5 (solitamente MPEG-2), sia in formato SPTS (Single Program Transport Stream) che in formato MPTS (Multiple Program Transport Stream); nell ultimo caso i programmi devono essere de-multiplati in SPTS per poter essere trattati come singoli canali dalla piattaforma. I flussi in ingresso, se compressi, sono decodificati e, se criptati, decriptati. I singoli canali sono quindi codificati da encoder specializzati per tecnica di codifica (ad esempio MPEG-2, MPEG-4 AVC, MS-VC1) con bit rate e caratteristiche adeguate alle caratteristiche della rete d accesso, alla tipologia di terminali utilizzati, ai formati video supportati. I flussi in uscita dagli encoder vengono criptati da server dedicati del sistema di CA/DRM di protezione dei contenuti, incapsulati in IP e distribuiti in multicast sul backbone. La distribuzione di tutti i canali video avviene attraverso il backbone fino agli apparati della rete di accesso DSLAM (Digital Subscriber Line Access Multiplexer); dai DSLAM è inviato all utente finale un singolo canale video. La selezione del canale che l utente desidera ricevere avviene attraverso il protocollo IGMP (Internet Group Management Protocol) con richieste generate dal ST verso il DSLAM a cui è attestata la linea utente. Tutte le operazioni di acquisizione, adattamento e distribuzione vengono eseguite in modalità real time dagli apparati che compongono l headend TV (ricevitori satellitari e/o DTT, encoder, streamer, sistema di protezione dei contenuti); tali apparati sono tipicamente centralizzati a livello di centro servizi. Un certo grado di distribuzione dell headend si può realizzare prevedendo la dislocazione a livello regionale degli apparati per l acquisizione, trasformazione e distribuzione di canali locali; in alternativa, possono essere previste reti di contribuzione regionali verso l headend centralizzato. 3.2 Headend, contenuti VoD Central VOD Servers Scrambling Encoders Lo scopo di questo headend è quello di acquisire, adattare, memorizzare, distribuire e permettere la fruizione dei contenuti VoD. Tutte le fasi, eccetto la fruizione, sono svolte in modalità off line (non real time) da processi automatici e semiautomatici supportati dagli strumenti forniti dalla componente DAM (Digital Asset Management) della piattaforma. I contenuti VoD sono generalmente forniti da Gigait Switches Content Protection System Headend Video Distribution content provider esterni (ad esempio Time Warner, Fox, ) su reti di contribuzione dedicate o direttamente su supporto fisico (ad esempio cassette Digital etacam). Una volta acquisiti, i contenuti vengono codificati da encoder software specializzati per tecnica che possono adottare codifiche multi-passo (per migliorare la qualità a parità di bit rate) e che adattano i contenuti, in termini di bit rate e formati, alle caratteristiche della rete, dei terminali e della QoS richiesta. I contenuti sono quindi criptati da server dedicati del sistema di CA/DRM di protezione dei contenuti e memorizzati all interno del catalogo dei contenuti; la funzionalità di catalogo è svolta dai Central VoD Server collocati a livello di headend (figura 3). Edge Servers DSLAM Digital Subscriber Line Access Multiplexer ST Set-Top ox VOD Video On Demand FIGURA 3 Distribuzione dei contenuti Unicast (VOD). VOD Switch ackbone Edge VOD Servers Trasporto DSLAM IP ST with Smartcard Accesso Distribuzione contenuti Ulnicast Fruizione contenuti Unicast Poiché la fruizione dei flussi VoD comporta lo stabilirsi di una sessione IP unicast tra video server e ogni ST che richiede il servizio, è prevista la distribuzione a livello regionale dei video server (Edge VoD Server) al fine di permettere il partizionamento del carico sui server e l ottimizzazione dell utilizzo di banda sulla rete di trasporto. La distribuzione dei contenuti avviene dai Central verso gli Edge Server. Gli Edge Server effettuano lo streaming in unicast verso i client attraverso il protocollo RTSP (Real Time Streaming Protocol). Tale protocollo consente al client la richiesta e il controllo della fruizione dei contenuti attraverso comandi VCR like (Fast Forward, Rewind, Pause, Stop, Play). NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

6 3.3 Il ruolo centrale del middleware per IPTV Il ruolo centrale nell architettura è svolto dal cosiddetto IPTV middleware che ha il compito di: garantire l integrazione delle diverse componenti funzionali quali: video server, ricevitori, encoder, streamer, sistema di protezione dei contenuti; supportare i processi di acquisizione, trasformazione e distribuzione dei contenuti; permettere la definizione e l erogazione dei servizi IPTV; supportare l integrazione con sistemi esterni quali gli OSS e i sistemi di CRM e di billing. Il middleware per IPTV è uno dei componenti tecnologici meno standardizzati da enti de jure e in più rapida evoluzione, perché nella sua evoluzione si confrontano da un lato importanti industrie che cercano di imporre soluzioni proprietarie, dall altra sforzi di standardizzazione delle associazioni che già hanno standardizzato la TV digitale satellitare e terrestre (ad esempio DV Forum). La mancanza di un middleware standard rende molto frammentato il mercato delle applicazioni e dei servizi, rendendo difficili le economie di scala sui prezzi e rallentando l effettivo decollo commerciale dell offerta. La piattaforma di middleware realizza un modello client/server con la componente server centralizzata a livello di headend e la componente client residente sul ST. La fruizione dei servizi IPTV avviene attraverso l interazione utente, che utilizza il telecomando, con la UI (User Interface) definita e gestita dalla piattaforma. La componente client, utilizzando le funzionalità di base del ST, supporta la presentazione Content Provider Digital Asset grafica della UI, la decodifica, la decriptazione e la visualizzazione dei contenuti. La tipologia di client supportato è una delle caratteristiche distintive di una piattaforma di middleware: si parla di fat client (o di soluzione client based ) quando l intera UI viene generata e gestita tramite un programma proprietario eseguito dal ST, mentre il termine thin client viene generalmente utilizzato per le soluzioni basate su browser, in cui il ST, tramite browser appunto, si limita ad effettuare il rendering di pagine HTML generate lato server. Una soluzione browser based facilita l integrazione di nuovi tipi di terminali (ST) ai quali è essenzialmente richiesta la sola compatibilità a livello di browser; mentre l interazione client/server (HTTP e JavaScript) della UI ha generalmente prestazioni inferiori rispetto ad una soluzione client based. Una soluzione client based ottimizza l interazione client/server della UI, ma l integrazione di nuovi tipi di terminali comporta un attività di porting del client sul nuovo terminale (attività che coinvolge sia il fornitore della piattaforma di middleware che il fornitore del terminale). La componente server è normalmente realizzata, utilizzando tecnologie web, su architetture a tre livelli: Web server, Application server, D server. Il D è generalmente di tipo centralizzato; per ottimizzare l accesso possono essere previsti diversi livelli caching. Le componenti e funzionalità principali di una piattaforma di middleware sono riassunte nella figura 4. SERVICE CONTROL (User Presence/Service Admission Control/Session Management/Accounting/Unified Directory) ATM EPG GE IPTV ST xdsl Digital Right Channel Portal Framework Content Providers EPG Asynchronous Transfer Mode Electronic Program Guide Gigait Ethernet Internet Protocol TeleVision Set-Top ox x Digital Subscriber Line Packaging Profiling Channel Subscriber Network (IP, ATM, xdsl, GE, Metro,...) Middleware Client/rowser ST IPTV FIGURA 4 Architettura funzionale del middleware. Advertising Subscriber Pricing Transaction Service Provider Network & Service Server Device La componente supporta le funzionalità legate alla gestione canali video TV; in particolare permette: la definizione dei canali, l associazione dei canali con gli stream generati dagli encoder, la definizione dell indirizzo IP del gruppo multicast utilizzato per la trasmissione in rete del canale; l impostazione e la modifica dello stato del canale (on line, off line, hidden,...); la definizione e la modifica dei metadati associati ai canali: numero canale, nome, descrizione, tipologia (asic, Premium, Pay Per View,...), genere (News, Movies, Sport,...), livello di rating associato al canale (adatto a tutti, per minori accompagnati, per adulti), multilingua, stereo,. 52 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

7 3.3.2 EPG (Electronic Program Guide) Questa componente fornisce funzionalità e strumenti a supporto delle fasi di: creazione e modifica del palinsesto; acquisizione dei dati relativi alla programmazione dei canali live provenienti da provider esterni; associazione dei meta-dati relativi ai canali e ai programmi (ora programmazione, genere, rating, informazioni sul programma,...), definizione eventi PPV; generazione, aggiornamento e personalizzazione della guida elettronica da visualizzare sui terminali; gestione dell interazione utente sulla guida: selezione canali e programmi, richieste di informazioni (visualizzazione dei meta-dati associati ai canali e ai programmi), richieste di registrazione programmi, Digital Asset (DAM) Il DAM è dedicato alla gestione dei contenuti VoD. Si tratta di una componente esterna alla parte core della piattaforma di middleware che fornisce funzionalità e strumenti a supporto delle fasi di: definizione e mantenimento del catalogo dei contenuti; acquisizione dei contenuti e dei meta-dati associati (in genere, assieme ai contenuti VoD vengono forniti dai content provider una serie di meta-dati quali: titolo del film, durata, genere, regista, attori principali, trama, livello di rating,...); categorizzazione e aggregazione dei contenuti (per genere, per regista, per livello di rating,...); definizione periodo di disponibilità/fruibilità del contenuto; definizione/gestione politiche di prezzo; definizione/gestione bundle dei contenuti; distribuzione e pubblicazione Subscriber Supporta le funzionalità relative alla gestione degli utenti; in particolare permette: la gestione degli account abilitati alla fruizione dei servizi IPTV; la definizione e la gestione dei dati degli utenti (anagrafica, indirizzo, contatti telefonici, ,...); la gestione di gruppi di utenti; la abilitazione/disabilitazione dell account alla fruizione di servizi o bundle di servizi; la abilitazione/disabilitazione dell account alla fruizione di package e bundle di contenuti Packaging e Pricing Queste due componenti cooperano con i sistemi di CRM e di billing con cui devono essere integrati per mantenere allineati i profili di offerta e le politiche di prezzo da attuare. I pacchetti di offerta sono generalmente commercializzati sotto forma di abbonamento che l utente può sottoscrivere e sono gestiti direttamente dai sistemi di CRM e di billing; la piattaforma di middleware è responsabile delle variazioni di sottoscrizioni e degli acquisti di eventi PPV o contenuti VoD che l utente può effettuare on line, direttamente dalla UI sul televisore o dal portale d accesso ai servizi IPTV (Portal Framework nella figura 4), senza richiedere l intervento di un operatore. La componente di Packaging supporta la definizione dei pacchetti di offerta attraverso le funzionalità di: packaging di canali live (esempio: definizione dei gruppi di canali associati agli abbonamenti: ase, Sport, Calcio,...); packaging di contenuti VoD (undle, Subscription VoD), appoggiandosi alle funzionalità fornite dal DAM. La componente di Pricing permette di: definire le politiche legate alle diverse tipologie di offerte sia per i contenuti live che VoD; applicare le politiche definite alle transazioni on line effettuate dall utente Transaction Compito del Transaction è quello di supportare l esecuzione e mantenere la traccia di tutte le transazioni che avvengono all interno della piattaforma di erogazione del servizio. Per le transazioni quali la modifica delle sottoscrizioni effettuate on-line dall utente e l acquisto di contenuti VoD o di eventi PPV, la componente supporta anche l interazione con i sistemi di billing e di CRM attraverso il mantenimento di un D di tutte le transazioni eseguite e l esposizione di API (Application Programming Interface). Nel caso di variazioni delle sottoscrizioni di servizi e pacchetti che sono fatturati periodicamente, l interazione con tali sistemi può avvenire in modo differito, ad intervalli di tempo prestabiliti, rispetto all effettiva esecuzione della transazione. Per l acquisto di contenuti on demand ed eventi in PPV (Pay Per View), per i quali può essere richiesto il pagamento prima della loro fruizione, l interazione con il sistema di billing deve essere on line. Il D di tutte le transazioni eseguite fornisce supporto anche ad altre componenti della piattaforma per realizzare ad esempio la visualizzazione sul televisore della lista degli acquisti effettuati oppure tracciare quante volte un particolare contenuto è stato acquistato e visto, Profiling È responsabile della gestione, per ognuno degli utenti abilitati, dei dati di profilatura che comprendono informazioni relative alla tipologia d accesso utilizzato, al profilo di servizio e alle offerte opzionali sottoscritte, ai terminali utilizzati. Permette inoltre di gestire e mantenere: le impostazioni utente quali: PIN di acquisto, PIN di blocco canali, livello di rating per paren- NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

8 tal control (esempio: contenuti per adulti visibili solo inserendo il PIN); le liste dei canali preferiti, dei canali bloccati, dei bookmark Advertising Fornisce le funzionalità di base per l advertising che può essere effettuato sulla UI, attraverso l utilizzo di strumenti tipici delle applicazioni web, quali banner e/o box informativi. Alcune piattaforme di middleware possono fornire una serie di funzionalità evolute (basate sulla correlazione di dati di profilig, dati relativi alle transazioni effettuate, dati anagrafici e altri dati sensibili), in grado di supportare un tipo di advertising mirato che può andare dalla semplice pubblicità su base locale, a quella basata sulle preferenze dell utente, a quella legata al contesto dei contenuti che l utente sta fruendo Server e Device Forniscono le funzionalità per la gestione dei server della piattaforma di middleware e dei terminali. Supportano interfacce standard o espongono API che consentono la loro integrazione con gli OSS esistenti. 4. La rete La progettazione ed il dimensionamento di una rete IP geografica per il trasporto di servizi televisivi a larga banda esula dagli scopi di questo articolo, per cui ci si limiterà ad alcuni principi generali. La caratteristica principale delle reti IP è quella di realizzare un trasporto best effort, che è particolarmente adatto a trasportare in modo molto efficiente traffico dati su scala planetaria, mentre si è rivelato meno adatto a trasportare in modo nativo il traffico di tipo voce o video (che ha maggiori requisiti sull ordine di consegna dei pacchetti e sui ritardi di consegna accettabili), per cui è stato necessario realizzare soluzioni che garantissero la qualità del servizio per questi tipi di traffico. Una soluzione a questo problema è di sovradimensionare le risorse a disposizione della rete (banda, capacità di commutazione dei pacchetti,...), in modo che la modalità best effort sia comunque in grado di garantire i requisiti necessari; un altra soluzione è stata quella di prenotare delle risorse per i tipi di traffico più esigenti, garantendo così la qualità del servizio erogato, ad esempio realizzando delle reti IP sovrapposte in tecnologia MPLS in grado di gestire la QoS (maggiori dettagli sulla verifica della qualità dei servizi video al paragrafo 6.3). Le caratteristiche dei servizi IPTV richiedono la disponibilità in rete di una grande quantità di banda (ogni canale occupa almeno alcuni Mbit/s), una bassa perdita ed una latenza bassa e non troppo variabile. La rete deve inoltre supportare la modalità di trasporto multicast, che consente di gestire in modo efficiente i canali televisivi dal vivo. Alcuni flussi audiovisivi sono erogati dal vivo, o più in generale in modalità diffusiva (TV), cioè lo stesso flusso viene erogato per tutti gli utenti: questo servizio è trasportato in modo particolarmente efficiente da reti che supportano IP Multicast. Questo tipo di trasporto emula quello delle reti televisive tradizionali (via etere o satellite) e prevede che una sola copia del flusso venga inviato in rete, identificandolo con un indirizzo di destinazione particolare; i nodi della rete sono in grado di interpretare l indirizzo di destinazione e duplicare il flusso ove necessario per fargli raggiungere tutte le destinazioni previste. Per soddisfare questi requisiti è tipicamente necessario realizzare una rete virtuale ad hoc, che sia in grado di segregare il traffico IPTV dal traffico Internet best effort. Una tipica architettura di rete di un servizio IPTV è rappresentata in figura La rete di trasporto e metropolitana La dorsale, o backbone, è una rete IP geografica, costituita da router IP di grossa capacità (GigaRouter) con collegamenti ottici ad alta velocità, sulla quale è possibile realizzare reti virtuali MPLS, in grado di segregare tipi diversi di traffico. L accesso alla dorsale avviene attraverso un certo numero di PoP (Point of Presence), tipicamente collocati presso le maggiori aree metropolitane. Alla dorsale sono collegate le reti metropolitane, tipicamente realizzate con switch Gigabit Ethernet ed articolate in switch di raccolta (Feeder), anelli CWDM/DWDM metropolitani e switch di concentrazione (Metro). 4.2 La rete di accesso e il CPE (Customer Premises Equipment) Ai Feeder sono collegati i DSLAM (Digital Subscriber Line Access Multiplexer) per i servizi IPTV, mediante collegamento Gigabit Ethernet (GbE), eventualmente tramite ulteriore anello CWDM/DWDM. I DSLAM per servizi IPTV (o triple play in generale) devono disporre di un interfaccia GbE verso la rete e devono supportare direttamente IP multicast. Al DSLAM è collegata l utenza domestica, attraverso la linea ADSL, la CPE (Customer Premises Equipment, o router di accesso), la rete domestica ed infine il terminale IPTV o ST. La coppia DSLAM-CPE diventa lo snodo principale per l integrazione dei servizi triple play (Internet, voce e TV), in quanto è il punto in cui i tre servizi convergono verso l utente e verso la rete domestica e deve essere in grado di garantire la loro coesistenza sulla tratta più critica dell intera catena di erogazione, cioè la tratta ADSL. Pertanto sia il DSLAM che la CPE devono essere in grado di segregare i traffici relativi alle diverse tipologie di servizio e gestire le priorità relative, al fine di garantire il rispetto dei requisiti minimi di banda, ritardo, jitter, ecc.. Questa segregazione viene realizzata utilizzando dei PVC (Permanent Virtual Circuit) ATM (Asynchronous Transfer Mode) sulla tratta ADSL con banda garantita e imponendo della priorità ai 54 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

9 Headend Rete di Distribuzione Sede cliente Middleware CAS Edge Router Metro GbE VOD Server Metro Feeder GbE DSLAM ST Content Management MAN GbE CWDM/DWDM metro ring CPE ADSL VoD Server PC EPG NAS Encoder Contribuzione Dorsale Video Streaming Metro GbE Metro GbE DSLAM ST Content Provider VOD Server Metro MAN GbE Feeder GbE CWDM/DWDM metro ring CPE ADSL PC ADSL CAS CPE DSLAM EPG GE Asymmetric Digital Subscriber Line Conditional Access System Customer Premises Equipment Digital Subscriber Line Access Multiplexer Electronic Program Guide Gigait Ethernet MAN NAS ST VOD Metropolitan Area Network Network Access Server Set-Top ox Video On Demand FIGURA 5 Esempio di architettura di rete. diversi tipi di traffico: Internet è quello meno prioritario, la voce (VoIP) quello a maggiore priorità. La CPE termina la tratta ADSL e si interfaccia alla rete domestica con una o più interfacce Ethernet ed un eventuale interfaccia WiFi (IEEE b/g). Siccome il ST per la fruizione del servizio IPTV deve essere collocato vicino al televisore, nel caso la CPE sia distante dal ST e non sia disponibile un cablaggio in rame che supporti Ethernet (cavo UTP5), è necessario ricorrere a tecnologie alternative che non richiedono l installazioni di nuovi cavi (no new cable); ad esempio la tecnologia WiFi che ha l enorme vantaggio di potere essere collegata a terminali senza necessità di cablaggio, ma male si adatta alle caratteristiche del traffico IPTV (banda elevata, IP multicast), per cui ne va attentamente valutato l uso. Una seconda promettente alternativa è rappresentata dalle PowerLine, che sono in grado di veicolare il traffico di una Ethernet sul cablaggio elettrico domestico, ma presentano una notevole sensibilità ad interferenze sulla rete elettrica (alimentatori switching, lampade a basso consumo energetico) ed hanno una portata che, andando oltre quella della singola abitazione, può generare disturbi ad analoghi impianti dei vicini di casa. 5. Terminali I terminali per IPTV, come i decoder per TV digitale terrestre o satellitare, vengono generalmente chiamati set-top box (ST). 5.1 Caratteristiche hardware I ST possono essere assimilati a PC di dimensioni molto ridotte, in cui sono state sviluppate le funzionalità di decodifica video e audio, mentre vengono eliminate o ridotte tutte le funzionalità non essenziali, evidentemente perseguendo l obiettivo di minimizzare il costo del sistema. Sui ST è presente una CPU (anche se spesso con prestazioni e architettura diverse dai comuni PC), una memoria RAM (che attualmente varia tra la decina e il centinaio di M), porte seriali (ad esempio US), un adattatore di rete (solitamente Ethernet), un sottosistema di generazione di segnali video con acceleratori per funzioni grafiche 2D, un sottosistema per comandare le uscite audio. Spesso, invece, manca un disco rigido (se si eccettuano i Digital Video Recorder), sostituito da una piccola memoria flash per il software di sistema. I requisiti hardware dei ST sono particolarmente stringenti. Vi sono esigenze di: forte integrazione, in modo da ridurre il numero di componenti e quindi il costo complessivo; bassi consumi, per non incorrere in problemi di dissipazione termica; silenziosità e affidabilità, che fanno propendere per sistemi senza parti in movimento (nessun disco, nessuna ventola). Le particolari esigenze computazionali degli algoritmi di decompressione dei media digitali fanno sì che queste operazioni siano normalmente assistite dall hardware. D altro canto, per supportare un numero sempre maggiore di codec e di for- NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

10 mati, risulta necessario rendere questo hardware flessibile e quindi programmabile. La sintesi tra queste due spinte opposte ha fatto nascere processori specializzati ma programmabili, che mettono a fattor comune le accelerazioni richieste dall elaborazione di flussi video (Sigma Designs EM8xxx, AD lackfin, Philips PNX1x00, Equator SP-15, Texas Instruments DM642). A questi media processor vengono di solito affiancati processori general purpose per la gestione di tutte le attività non direttamente legate alla decodifica. Le architetture hardware di questo tipo vengono dette dual chip. L ulteriore tendenza all integrazione, dettata da ragioni di costo, è alla base dello sviluppo di soluzioni single chip, in cui host processor e media processor confluiscono sullo stesso silicio (ATI Xilleon, ST 55xx/710x, Philips Viper, IM Pallas, Sigma Designs SMP863x). È da notare tuttavia che l architettura logica del sistema rimane internamente equivalente alle soluzioni dual chip. L assenza di piste di interconnessione esterne permette però prestazioni più elevate nello scambio dati tra i vari sottosistemi. Una ulteriore funzionalità che viene integrata sia nelle soluzioni dual chip che in quelle single chip è il mixing tra video e grafica sintetica, necessaria in tutte le situazioni in cui si vogliano mostrare contemporaneamente sullo schermo sia uno o più video, sia elementi grafici dell interfaccia utente. Mentre il video viene generato dal media processor, solitamente la grafica sintetica origina dall altro processore. Il mixing risulta tanto più sofisticato quanti più sono i layer sovrapposti che riesce a gestire, e quanto più permette un controllo fine sul grado di trasparenza/opacità degli stessi (alpha blending). La scelta del chip principale (o della coppia di chip) è un passo fondamentale nella creazione di un nuovo ST. Per questa ragione, i produttori di chip generalmente non si limitano a fornire il silicio, ma creano dei progetti hardware di riferimento (reference design/board) attorno al loro prodotto ed integrano e mettono a punto il software di base necessario al loro funzionamento: sistemi di sviluppo e debugging, sistema operativo e driver, media player ottimizzato sulle accelerazioni hardware disponibili. I produttori di ST progettano, a partire da un reference design, un sistema che abbia esattamente le caratteristiche e le funzionalità del prodotto cui mirano: rispetto al reference design, alcuni elementi saranno da aggiungere, ed altri da togliere. Quanto più il progetto finale riesce a rimanere vicino a quello di riferimento, tanto più il software di corredo sarà adatto e immediatamente utilizzabile, diminuendo le necessarie integrazioni di nuovi componenti software, come ad esempio i driver per gestire i dispositivi aggiunti. 5.2 Caratteristiche software Un ulteriore ed importante elemento è la scelta del sistema operativo (OS). Questa scelta presenta innanzi tutto qualche dipendenza dall architettura selezionata per il processore principale, in quanto non tutti i sistemi operativi supportano tutte le architetture. Un produttore di ST deve poi tener conto delle opzioni supportate dal produttore di chip e dai suoi partner per i reference design. I sistemi operativi per dispositivi come i ST vengono detti embedded, per distinguerli da quelli per i PC e per i server, e per sottolinearne la minore visibilità e le minori esigenze in termini di risorse. Tuttavia la distinzione è in certi casi sottile: ad esempio, Linux si è dimostrato un sistema operativo così versatile da occupare una importante posizione di mercato sia sui ST, sia in ambito server. Le alternative a Linux si possono classificare in due gruppi: quelle commerciali, in cui il fornitore del sistema operativo è distinto dal fornitore del silicio (Windows CE, VxWorks, QNX,...), e quelle in bundle, in cui l OS viene offerto insieme al processore (ad esempio OS/20 o OS/21 sui chip di ST Microelectronics). Questo non vuol dire che non ci siano aziende nate proprio con l obiettivo di creare apposite versioni di Linux per i sistemi embedded : semplicemente hanno dovuto o voluto adottare modelli di business differenti (il leader del settore è in questo caso MontaVista). I principali fattori che concorrono a determinare il sistema operativo giusto per un ST sono: il costo (le soluzioni commerciali impongono quasi sempre una royalty su ogni dispositivo in campo); la presenza di componenti di base (come lo stack protocollare TCP/IP) affidabili e non soggetti ad ulteriori royalty; la conformità agli standard (come ad esempio quello POSIX); le prestazioni e la possibilità di configurarlo per operare in modo real-time (con tempi di risposta predicibili e garantiti su certi task); l occupazione di memoria, sia in esecuzione che su supporto di memorizzazione non volatile; il tempo di boot (sebbene questo dipenda in forte misura anche da altri fattori); la disponibilità di applicazioni e librerie di programmazione utili per le funzionalità da realizzare; la qualità dei sistemi di sviluppo e di test disponibili; la presenza di un ecosistema vivo e vitale attorno all OS e ai componenti software che verranno impiegati. Una delle applicazioni principali che vengono appoggiate sul sistema operativo è senza dubbio il browser, essendo la maggioranza delle piattaforme di middleware basate su un paradigma di tipo web. Il browser ha tuttavia caratteristiche particolari. Da un lato infatti è necessario adattarsi al contesto televisivo: il browser non sta in una finestra, ma occupa tutto lo schermo; non ha quasi mai barre di scorrimento o menù a tendina; non si basa su interazioni di tipo point and click. 56 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

11 D altro canto, per poter avviare e controllare la riproduzione di media senza abbandonare l applicazione web, l interprete JavaScript del browser viene esteso con funzioni proprietarie (in assenza di uno standard) che lo collegano al media player e ad altre risorse locali del ST. Come per le altre parti del ST, anche in questo caso ci sono aziende specializzate nel fornire browser per ambienti embedded (la più nota è forse Ant), oltre alle alternative open source (ad esempio Mozilla), o ai browser offerti insieme al sistema operativo (Explorer su Windows CE). Nella situazione attuale, caratterizzata da soluzioni verticali e dalla mancanza o scarsa maturità degli standard, i fornitori di ST non possono consegnare all operatore del servizio IPTV una macchina con un software su cui non si prevedano modifiche e aggiunte. I terminali sono infatti uno dei punti critici in cui si concentrano gli adattamenti necessari all integrazione finale del servizio; ad esempio, il middleware scelto ha bisogno di modifiche al browser, i video server richiedono qualche adattamento di protocollo, l operatore del servizio deve incorporare la propria soluzione di telegestione dei terminali, il fornitore della soluzione di protezione dei contenuti, dopo aver adattato il media player, deve certificare digitalmente l immagine software ed infine possono emergere incompatibilità sul formato di codifica video... Vista la complessità del software dei ST, che porta a scoprire errori quando questi sono già in campo, e vista la necessità di preservare nel tempo l investimento fatto sul terminale, esiste sempre un meccanismo per aggiornare, tutta o in parte, l immagine software di questi sistemi. La modalità di aggiornamento dipende da come il ST carica il proprio software quando viene avviato, ovvero se effettua il boot dalla memoria flash, o se invece lo carica dalla rete. Nel primo caso si tratta di sostituire il contenuto della memoria flash con una nuova immagine software, e il ST può ricevere notifica della disponibilità di una nuova versione tramite il sistema di telegestione, o semplicemente eseguendo un controllo ogni volta che viene avviato. Nel caso di boot da rete, in cui solitamente l immagine software viene continuamente trasmessa su un canale multicast, una volta aggiornato il server che la eroga, tutti i terminali acquisiranno automaticamente la nuova immagine al primo riavvio. 5.3 Set-top box: uno sguardo al futuro Dopo aver visto alcune caratteristiche hardware e software dei ST, e dopo aver riconosciuto gli attori coinvolti in questo mercato, è interessante porci alcune domande su quale possa essere il futuro dei terminali IPTV. L analisi non può prescindere dalle evoluzioni, siano esse attese o in atto, sui sistemi adiacenti : i televisori, i terminali per TV digitale satellitare e terrestre, i lettori/registratori di dischi (DVD, ma anche HD-DVD e lu-ray), la rete domestica. Elementi di analisi rilevanti possono essere: I televisori vanno verso il paradigma solo display o verso quello di sistema integrato, che ingloba le funzionalità tipiche del ST, e che quindi include sintonizzatore e decodificatore? Accanto al sintonizzatore DTT o a quello satellitare potremmo aspettarci che si diffondano anche i sintonizzatori IP? L unica cosa sicura al momento è che lo schermo sarà ad alta definizione. La migrazione da MPEG-2 a codifiche più avanzate è appena cominciata. Dovendo sostituire i terminali, per i costruttori di ST e per i broadcaster satellitari e terrestri si aprono varie opportunità per potenziare i loro servizi: dall introduzione di un hard disk, per abilitare servizi come il time shifting, il digital video recording (DVR) e il Push VoD, a sintonizzatori satellitari di ultima generazione per incrementare l efficienza trasmissiva (DV-S 2), ad un uso massiccio del canale broadband (DSL). Trovando modelli di business soddisfacenti per tutte le parti, i ST ibridi (DTT e IPTV, o satellitari e IPTV) sono tecnologicamente pronti.... Quale diventerà il punto di aggregazione dei contenuti sulla rete domestica? Prevarrà il modello di tipo Media Center o quello di tipo PC companion, oppure i ST e i PC continueranno ad appartenere a mondi non comunicanti? I terminali per IPTV, aggiungendo le parti meccaniche necessarie, potrebbero leggere e scrivere DVD e loro evoluzioni. Vedremo questo tipo di convergenza? Un servizio possibile diventa quello che si potrebbe chiamare Download & urn (Scarica & Masterizza) e naturalmente dovrebbe costare più del VoD, visto che il contenuto va ad arricchire la videoteca dell utente. Molte delle soluzioni appena ipotizzate già sono state prototipate o sono addirittura disponibili sul mercato; ciò che resta da vedere è quali saranno quelle che avranno una diffusione di massa. 6. Standard e protocolli Contrariamente a quanto visto per il middleware, il ruolo degli standard è importantissimo per quanto riguarda la digitalizzazione del segnale televisivo ed il suo trasporto sul canale IP: la decennale esperienza delle reti televisive digitali (via cavo, satellitari o terrestri) costituisce una solida base di partenza per il modo IPTV. 6.1 Codifiche Video: da MPEG-2 a MPEG MPEG-2 Il segnale televisivo analogico PAL (Phase Alternate Line) digitalizzato ma non compresso richiede una disponibilità di banda di 270 Mbit/s, al di sopra della capacità trasmissiva di molti dei mezzi disponibili per la distribuzione di segnali televisivi su reti IP. NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

12 Analogamente il sistema televisivo nord-americano, che pure ha una minor resa cromatica, richiede 168 Mbit/s. La situazione diventa nettamente più pesante se si prende in considerazione la televisione ad alta definizione, per cui la banda richiesta diventa superiore ad 1 Gbit/s. La figura 6 (tratta da [2]) illustra graficamente la situazione. < Mbps < 1.5 Mbps 1-2 Mbps 2-3 Mbps 4-6 Mbps 8-10 Mbps Mbps Mbps Mbps Mbps 140 Mbps 168 Mbps 216 Mbps 270 Mbps Gbps Video conference Video in a window VHS quality full screen roadcast NTSC roadcast PAL Professional PAL roadcast HDTV DV satellite multiplex Professional HDTV Contribution TV Contribution TV Raw NTSC Raw PAL Raw contribution PAL Raw HDTV Per questo si rendono necessarie tecniche di codifica dette lossy che riducano drasticamente la banda richiesta conservando, pur introducendo perdite di informazione, una qualità percepita dall utente non inferiore a quella a cui è abituato con il segnale televisivo ricevuto da altri media (quali ad esempio la TV analogica). Poiché lo standard MPEG-2 fornisce una buona compressione usando algoritmi standard, è stato scelto come tecnologia di codifica per la televisione digitale. Uno dei punti chiave per la futura diffusione dei servizi IPTV su ADSL è la maturità raggiunta dalla nuova generazione di codificatori: negli anni Novanta la finalizzazione dello standard ISO MPEG-2 permise la nascita della TV digitale satellitare, su cavo, su reti terrestri, la diffusione dei DVD: tutti questi media utilizzano codifiche video MPEG- 2 a bit rate variabili da 4 a circa 10 Mbit/s. Per la descrizione delle tecnologie di codifica (MPEG-2, MPEG-4 AVC, ) si rimanda all articolo Tecnologie di codifica Audio e Video in ambiente fisso e mobile pubblicato in questo stesso numero del Notiziario. Qui si aggiungono solamente alcune notazioni relative al loro impiego nel contesto IPTV. Tipicamente una codifica MPEG-2 parte da un contenuto audio/video digitale non compresso (o poco compresso), organizzato in frame (quadri dell immagine) che si presentano con una velocità di ripetizione di 25 (MPEG-4) (MPEG-1) (MPEG-2) (MPEG-2) (MPEG-2) (MPEG-2) (MPEG-2) (MPEG-2 Transport) (MPEG-2) (MPEG-2-I) (MPEG-2-I) (uncompressed) (uncompressed) (uncompressed) (uncompressed) FIGURA 6 Richieste di banda per i diversi sistemi televisivi. Ottima Scarsa Qualità percepita x480 MPEG2 fps (frame al secondo) per contenuti PAL (per contenuti NTSC il frame rate è di 29,97 fps). MPEG-2 supporta sia video interallacciati che progressivi; la modalità interallacciata, tipica dei televisori analogici, scompone un frame (quadro) in due fields (semiquadri) che contengono rispettivamente le righe pari e quelle dispari del quadro. Il bit rate in uscita da un encoder MPEG-2 può essere costante o variabile (esiste anche l opzione capped variable ). Una codifica VR (Variable it Rate) usa la banda istantanea necessaria a mantenere la qualità della codifica intorno al valore nominale; per scene complesse o con notevole movimento i valori di picco possono diventare anche multipli del valore nominale; è una configurazione non applicabile per canali a banda limitata, dove non è mai permesso superare il limite imposto dalla banda fisica, pena la produzione di artefatti in decodifica. In questi contesti (tale è l IPTV) occorre produrre una codifica CR (Constant it Rate) in cui ad ogni frame è assegnato lo stesso bit rate, penalizzando, in alcune circostanze, la qualità ed in altre introducendo padding, cioè inefficienza. È stato definito un numero di livelli e profili per la compressione video in MPEG-2. I livelli tengono conto della risoluzione mentre i profili tengono conto della qualità del video. Ciascuno di essi comprende un sottoinsieme delle funzionalità complessive descritte in MPEG-2. Le implementazioni di MPEG-2 normalmente riguardano una specifica coppia di profili e livelli. Per la distribuzione agli utenti del segnale nei sistemi IPTV si utilizza il Main Profile Main Level (MP@ML), che copre una gamma di compressioni da 1 Mbit/s a 15 Mbit/s. Le principali risoluzioni utilizzate per sistemi PAL sono: 720 x 576 x 25 fps (PAL Full-D1); 704 x 576 x 25 fps (PAL Full-D1); 544 x 576 x 25 fps (PAL 3/4-D1); 352 x 576 x 25 fps (PAL Half-D1). La scelta della risoluzione più appropriata in codifica viene impostata, a livello di configurazione dell encoder, tenendo conto che la relazione fra risoluzione, bit rate e qualità ha l andamento delle curve riportate in figura 7. Sono curve che descrivono l esperienza empirica di qualità soggettiva 9800 it rate Ottima Scarsa FIGURA 7 Andamento della relazione fra risoluzione, bit rate e qualità. Qualità percepita x480 MPEG it rate 58 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

13 nell operare con codifiche MPEG-2, piuttosto che ricavate da elaborazioni teoriche. Dalle curve si può notare che: A risoluzione piena (Full-D1) è necessario poter disporre di una banda superiore ai 4,5 Mbit/s per una qualità accettabile. Avendo a disposizione una banda fisica inferiore e quindi una banda per la componente video ancora minore è consigliabile ridurre la risoluzione in codifica fino ad half-d1. Sarà compito del decoder effettuare un upscaling del video per riportarlo ai valori richiesti dai televisori (normalmente 704x576 è più che sufficiente). Vi sono aree di bit rate per le quali la qualità è altamente sensibile a variazioni di banda anche piccole, per cui un tuning attento è essenziale. Andare oltre certi valori di bit rate in codifica non produce vantaggi nella qualità del segnale codificato, per cui la banda sarebbe sprecata. L audio associato ad un contenuto video varia in funzione della sorgente: si va da contenuti a cui è associato un canale mono a contenuti per i quali l audio è di tipo Dolby Digital 5.1 L audio può essere codificato in vario modo, con crescente efficienza: le codifiche più comuni sono MPEG-1 Layer 1, Layer 2 e Layer 3 (MP3), in particolare si usa sovente MPEG-1 Layer 2. Il segnale viene tipicamente codificato a bit rate compresi fra 96 Kbit/s e 384 Kbit/s. La codifica MPEG-2 AAC (Advanced Audio Coding) molto più efficace ma non 12.0 compatibile con quelle precedenti, è in realtà usata per 10.0 codificare l audio nelle nuove tecnologie, ad esempio in MPEG-4 AVC, 8.0 descritta nel paragrafo successivo MPEG-4 AVC Il nuovo standard congiunto ISO MPEG-4 Part10 (MPEG-4 AVC) - ITU H.264 permette un salto nella capacità di compressione video e audio, riducendo il bit rate necessario rispetto a MPEG-2 anche del 50%, rendendo molto più fattibile la trasmissione di video di qualità broadcasting su reti ADSL. H.264/AVC contiene numerose nuove funzionalità che gli consentono di comprimere il video in maniera molto più efficiente dei codec precedenti, in particolare di MPEG-2, al prezzo di una maggiore complessità del codificatore. L obiettivo dichiarato di pari qualità rispetto ad MPEG-2 a metà del bit rate va inteso come un obiettivo a regime, quando l implementazione degli algoritmi facenti parte della tecnologia MPEG-4 PSNR (d relative) AVC avrà raggiunto la maturità che oggi hanno ad esempio le implementazioni dei codificatori MPEG- 2. Oggi (fine 2005) prove di laboratorio hanno dimostrato che non è così, soprattutto per le codifiche live che sono quelle più impegnative per i vincoli temporali, ed una codifica richiede ancora sostanzialmente lo stesso bit rate per fornire la stessa qualità di una codifica MPEG-2. Tecnologicamente, per i contenuti live si assiste oggi ad una maggior disponibilità di prodotti commerciali per la codifica e ad una scarsità di prodotti affidabili (ST) per la decodifica; inoltre si verifica una diffusa difficoltà di interoperabilità di un ST con codificatori di costruttori diversi. Per i contenuti on demand, sono disponibili alcuni codificatori (anche prodotti software) mentre è ancora in corso l adeguamento dei video server a gestire contenuti codificati MPEG-4 AVC Altre codifiche La sola reale tecnologia di codifica video alternativa alle due brevemente presentate sopra è la tecnologia MS-VC1 (Microsoft Video Codec 1). In realtà essa è concorrente come rapporto qualità/requisiti ad MPEG-4 AVC. La figura 8, prodotta da un soggetto terzo (Tandberg, che costruisce gli encoder per entrambe le tecnologie) indica che il confronto è appunto con MPEG-4 AVC it rate (Mbit/s) MPEG-4 AVC/m WMV9 (beta) MPEG-4ASP MPEG-2 FIGURA 8 Confronto tra le performance delle tecnologie di codifica. Fonte: Tandberg VC1 deriva dall esperienza pluriennale di Microsoft con la tecnologia WM9 (Windows Media 9), che ha comunque come target il PC come terminale (formato progressivo e non interallacciato), risoluzioni inferiori a quella televisiva (tipicamente CIF (352x278) rispetto al PAL (720x576), bit rate inferiori. VC1 viene indicato come un profilo di WM9: Advanced Profile. NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

14 Microsoft ha sottoposto la sua tecnologia a SMPTE poiché ambisce a farlo diventare uno standard, almeno nel contesto nord americano. Strutturalmente e concettualmente la tecnologia è analoga alle tecnologie MPEG; si tratta sempre di una tecnologia di codifica differenziale. Le differenze sono nella scelta degli algoritmi e nelle modalità implementative dei codec. La codifica può essere incapsulata in vari formati di streaming, da quelli tipici Microsoft (con estensione.asf) con cui può essere visualizzata da PC con il player Microsoft, al Transport Stream entro cui costituisce l elementary stream per il video. 6.2 I protocolli per streaming e controllo Il livello applicativo Uno stream MPEG-2 è costituito da più componenti, chiamati Elementary Stream (ES): un programma contiene tipicamente un ES per il video, uno o più per l audio, dati di controllo, e dati con valore informativo come i sottotitoli. Ciascun ES viene suddiviso in pacchetti PES (Packetised Elementary Stream), di dimensione fissa o variabile, che iniziano con un header di 6 bytes in cui sono presenti le informazioni sul tipo di ES che contiene, sulla sua lunghezza ed informazioni di controllo per la sincronizzazione degli ES: PTS (Presentation Time Stamp) e DTS (Decode Time Stamp). Lo standard MPEG-2 consente due tipi di multiplazione dei pacchetti PES: MPEG Program Stream: riguarda il caso di pacchetti PES strettamente correlati e con la stessa base tempi. Si applica a contesti nei quali sia bassa la probabilità di errori e consente una più facile elaborazione dei dati in ricezione. È la forma di multiplexing usata nei device di video storage, tipicamente i DVD; MPEG Transport Stream: ciascun PES è spezzato in transport packets di dimensione fissa; lo stream può contenere pacchetti provenienti da PES indipendenti. È la forma di multiplexing idonea al caso di trasmissioni su media potenzialmente affetti da errore e quando interessa assemblare più programmi nello stesso stream. È la forma di multiplazione adottata dal DV (Digital Video roadcasing), il consorzio europeo per la standardizzazione della distribuzione dei segnali televisivi, e non solo. Il DV si occupa sopratutto della trasmissione televisiva satellitare digitale (DV-S), ma definisce in generale come i segnali MPEG-2 sono trasmessi anche su cavo (DV- C), o a frequenze televisive terrestri (DV-T) e anche come sono gestite le informazioni di servizio, le EPG (guide programmi) e gli Video Video ES Encoder Audio Data Audio ES Encoder Packetizer PES Packetizer PES Formatter/ Packetizer eventuali sistemi di crittografia. La figura 9 schematizza quanto descritto. Come ingressi al Transport Multiplex, oltre a più di un PES, sono indicate le SI (Service Information), cioè quell insieme di dati di controllo che servono per gestire le associazioni fra gli ES e descriverli. L insieme di SI (si veda oltre) deriva in parte dallo standard MPEG-2 in parte è integrato con campi definiti in ambito DV. All interno di un TS possono essere trasportati sia un programma singolo, in questo caso si parla di SPTS (Single Program Transport Stream), sia una combinazione di più programmi, in questo caso si parla di MPTS (Multiple Program Transport Stream). La configurazione SPTS è tipica nel contesto IPTV e può contenere semplicemente i PES di audio e video; nel caso delle trasmissioni regolamentate dal DV la configurazione tipica è MPTS; in questo caso è tassativo includere le informazioni di controllo comprese nelle SI per identificare i singoli programmi. Nel riquadro di approfondimento La struttura del Transport Stream vengono descritte in maggior dettaglio sia la struttura di questo strato di controllo che la struttura dei singoli pacchetti che lo compongono Lo stack di protocolli per i contenuti live Poiché il tratto più critico del percorso di rete è rappresentato dalla tratta ADSL, si darà un indicazione dei protocolli presenti al di sopra del livello fisico in tale tratta. La caratterizzazione della banda fisica disponibile sulla tratta ADSL deve essere tale da garantire la raggiungibilità di un elevata percentuale di utenza sul doppino telefonico, che introduce attenuazione e perdite proporzionali alla sua lunghezza; a titolo di esempio, i valori a cui si fa riferimento sono quelli dell ADSL a 4 Mbit/s (4832 Kbit/s in downstream e 320 Kbit/s in upstream), dell offerta Telecom Italia. Interessa qui analizzare la componente downstream, sulla quale transitano i contenuti audio/video poiché pone i maggiori vincoli. PES DV Digital Video roadcasting ES Elementary Stream PES Packetizer Elementary Stream TS Transport Stream Program # PES #1 PES #2 Transport Multiplex Service Information FIGURA 9 Componenti dello stream MPEG-2 e Multiplazione a livello applicativo. TS Error Prot. & Modulation Channel DV-C (Cable) DV-S (Satellite) DV-T (Terrestrial) 60 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

15 La struttura del Transport Stream Ogni Elementary Stream (ES) video e audio inserito in un TS (Transport Stream) viene identificato con uno specifico PID (Packet IDentifier); questo permette al ricevitore di riconoscere e filtrare i pacchetti in base al loro PID. La descrizione di quali ES devono essere combinati per costruire un programma sono trasportate all interno di tabelle di segnalazione, pacchetti di piccole dimensioni nel TS, separati ed asincroni rispetto ai PES (Packetised Elementary Stream). Esempi di tabelle di segnalazione sono: PAT (PID 0x000) (Program Association Table): riporta la lista dei Packet Identifier (PID) associati ai singoli programmi; CAT (PID 0x001) (Conditional Access Table): inviata nel caso di ES criptati, fornisce le informazione sul tipo di scrambling ed indica i PID associati ad altre informazioni sull accesso condizionale; PMT (Program Map Table): definisce l insieme di PID associati ad un singolo programma: il PID di questa tabella per ciascun programma è quello precedentemente letto nella PAT. Il DV ha definito alcune ulteriori tabelle opzionali con lo scopo di descrivere i servizi trasportati (il ruolo di queste tabelle è direttamente comprensibile dal nome): NIT (PID 0x010) (Network Information Table): contiene informazioni sul mezzo fisico su cui l informazione è trasportata (esempio, se si tratta di satellite: transponder, symbolrate, FEC, ); AT (ouquet Association Table); SDT (Service Description Table); TDT (Time and Date Table); RST (Running Status Table); EIT (Event Information Table). La figura A, tratta da [3], riporta un esempio di spezzone di Transport Stream. La sincronizzazione fra gli Video packet Audio packet ES e la rigenerazione del clock al ricevitore si effettuano usando indicatori di temporizzazione (time stamps) trasportati nel TS stesso; in particolare: PCR (Program Clock Reference): è trasportato in un campo di pacchetti TS dedicati oppure dei pacchetti video stessi e serve alla ricostruzione di una base tempi coerente fra trasmissione e ricezione. Il clock di sistema è 27 Mhz; in ricezione viene generato un clock locale e da questo estratto un contatore che viene confrontato con il PCR ricevuto; le eventuali differenze sono usate per correggere la frequenza dell oscillatore locale in ricezione; DTS (Decoding Time Stamp) e PTS (Presentation Time Stamp): sono trasferiti nell header di ogni PES e servono per stabilire gli istanti di decodifica di un singolo frame e dunque la sincronizzazione fra ES. La dimensione di un transport packet è 188 bytes, di cui 4 di header. In questo header è fondamentale il campo di 13 bit del PID per individuare i singoli PES di cui il transport packet è parte. Nel transport stream non è garantito alcun ordine di trasmissione dei pacchetti, cioè non vi è sincronizzazione fra i PES presenti. Per mantenere il bit rate del mulitplex impostato in fase di configurazione possono essere inseriti anche pacchetti di stuffing (PID 0x1fff). La struttura di un transport packet è riportata in figura : Il significato dei vari campi dell header è il seguente: Synchronisation yte: identifica l inizio del pacchetto. Il suo valore, fisso, è 0x47; Packet header includes a unique packet ID (PD) for each stream FIGURA A Transport Stream. transport packet stream sync byte transport error indicator 1 Programme Association Table (PAT) Programme Map Table (PMT) PAT lists PIDs for programme map tables Network Info 10 Prog 1 15 Prog Prog etc. PAT lists PIDs associated with a particular programme Video 51 Audio (English) 64 Audio (French) 66 Subtitle 101 etc Other packets Programme guides, Subtitles, Multimedia data, Internet packets, etc Un insieme di tre flag per indicare come il pacchetto deve essere processato; Packet Identifier (PID) (per il suo ruolo, si veda sopra); Due bit usati dalle procedura di controllo d accesso; Due bit per indicare la presenza dell "adaptation field": - 01 no adaptation field, payload only; - 10 adaptation field only, no payload; - 11 adaptation field followed by payload; - 00 Reserved for future use; se presente, l adaptation field si colloca a valle dell header, prima del payload. Un contenuto importante dell adaptation field è il PCR; Continuity Counter (4 bit): contatore molto utile per valutare le continuità dei pacchetti ricevuti e per segnalare eventuali perdite. 188 bytes header payload header payload header payload payload unit start indicator 1 8 PID Packet Identifier FIGURA Transport Packet. transport priority 1 PID 13 transport scrambling control 2 adaptation field control 2 continuity counter 4 adaptation field NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

16 Il payload da inserire nello stack di protocolli è tipicamente costituito dal massimo numero intero di transport packet (dimensione 188 bytes ciascuno, paragrafo 6.2.1) che può essere allocato in una trama Ethernet (1500 bytes). Per questo il payload ha dimensione 1316 bytes (7 trame intere da 188 bytes ciascuna). Questa scelta consente di sfruttare al massimo il contenuto informativo trasportabile in una singola trama Ethernet, e quindi di contenere l overhead dei protocolli. Non è l unica possibile: valori maggiori del numero di frame aggregati in un unico segmento di payload sarebbero possibili, anche fino ad un ordine di grandezza superiore, ma non sono consigliabili su reti IP per non dover ricorrere alla frammentazione dei pacchetti IP ed al loro successivo riassemblaggio con costi di ritardo e rischi di errore. Al di sopra del livello di rete (IP), il livello di trasporto è in questo caso sempre UDP: il vantaggio è la maggior velocità (il tipo di contenuti ed i vincoli imposti dallo streaming real time non consentono i ritardi introdotti dalla eventuale ritrasmissione di pacchetti errati), il costo è l assenza di meccanismi di recupero degli errori. Un pacchetto UDP errato viene semplicemente scartato ma provoca la perdita di ben 7 frame di contenuto. Fra il livello di trasporto ed il livello applicativo (Transport Stream) può essere inserito il protocollo RTP (Real Time Protocol), protocollo standard IETF per il trasferimento controllato di audio e video. Il suo uso è opzionale ed attualmente sovente non usato ed il ST è in grado di interpretare sia flussi incapsulati in RTP che flussi in cui le trame sono direttamente inserite nel payload del pacchetto UDP. Al costo di un ulteriore aggiunta di overhead e di capacità di elaborazione sia lato encoder che lato decoder, l uso di RTP consentirebbe una maggior efficienza e flessibilità nella gestione degli elementary stream audio e video. Oggi, come detto in precedenza, l audio viene normalmente trasportato embedded insieme al video in unico transport stream; con l uso di RTP ogni flusso elementare potrebbe viaggiare per proprio conto, poiché in RTP sono presenti i controlli per sincronizzare i flussi. Ad esempio l uso di RTP nella modalità sopra accennata sarebbe vantaggioso nel caso di audio multilingua: se l audio viaggia embedded con il video sono possibili due alternative entrambe inefficienti: si possono trasmettere sempre tutti i canali audio associati alle varie lingue che l utente può scegliere di ascoltare, con l ovvio spreco di banda sulla tratta critica ADSL, oppure si può trasmettere dall headend un numero di flussi separati dello stesso contenuto pari al numero di lingue offerte con un appesantimento della banda occupata sul backbone e sulla rete metro, oltre che del numero di encoder coinvolti. Con RTP si trasmette sempre un solo flusso dell elementary stream video e tanti flussi audio quante le lingue offerte. A RTP è associato un protocollo di controllo RTCP (Real Time Control Protocol) che agisce a ritroso dal decoder (ST) e che fornisce alla parte sorgente informazioni di controllo istantaneo sullo stato della comunicazione; utilizzando questo protocollo si possono ipotizzare soluzioni, ad oggi commercialmente non implementate, di adeguamento automatico della banda. Nel riquadro di approfondimento Il peso dello stack dei protocolli viene descritto il calcolo dell overhead causato dagli header dei vari protocolli presenti nello stack, al di sotto del livello applicativo e fino al livello fisico ed il peso che esso ha sulla banda fisica disponibile Il ruolo del multicast I contenuti live sono trasmessi utilizzando l opzione multicast del protocollo IP. Al disopra del livello di rete lo stack di protocolli rimane invariato rispetto agli altri tipi di contenuti audio/video: a livello di trasporto si usa UDP ed a livello applicativo è opzionale l uso di RTP. La scelta del multicast è fondamentale per minimizzare il numero di flussi IP che circolano sul backbone e sulla rete metro. Con questa scelta circola infatti un solo flusso per ogni canale live che viene erogato. Come per i canali televisivi tradizionali, l utente inizia a fruire del contenuto presente sul canale prescelto nel momento della sua connessione, ricevendo quanto in quel momento viene trasmesso e non dall inizio. L opzione multicast di IP significa associare al flusso un indirizzo compreso in un range particolare (da a ) ed una porta a livello di trasporto. La coppia indirizzo/porta identifica univocamente il flusso multicast e quindi il canale live. Le regole del multicast in rete prevedono, mediante l uso di protocolli di segnalazione fra router, che il flusso multicast circoli su una sottorete solo se utenti ad essa attestati, o attestati a sottoreti a valle di quella in esame, lo abbiano richiesto. Il modello di servizio in atto, nel caso dell IPTV, assume che tutti flussi multicast erogati dall headend siano ricevuti da ciascun DSLAM, che provvede a replicarli sulle porte degli utenti che ne fanno richiesta. In questo contesto sono dunque costantemente presenti sul backbone e sulla rete metro tutti flussi multicast relativi ai canali live erogati. Il protocollo con cui l utente, cioè tecnicamente il ST, richiede di ricevere un canale live, o di rilasciarlo, è il protocollo standardizzato in IETF IGMP (Internet Group Management Protocol). Normalmente la versione attualmente implementata sui sistemi commerciali è la versione 2. Il protocollo IGMP contiene, fra le altre, primitive di Join, di Leave e di Membership Report per un flusso multicast. La Join e la Leave hanno il ruolo intuitivo di richiedere l aggancio ed il rilascio di un flusso. La primitiva di Membership Report informa la risorsa erogante a monte (nel caso IPTV il DSLAM, in generale il primo router) che il flusso multicast corrente continua ad essere di interesse del device che genera la primitiva; in mancanza di tale riscontro, allo scadere di un timeout, il flusso su quella porta viene bloccato (cause possibili: spegnimento del ST, disconnessione a livello fisico, ). 62 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

17 Il peso dello stack dei protocolli Componenti (descrizione) Componenti (valore) Numero canali audio 2 anda canale audio 96 Unità di misura # Kbps Peso % Componente audio TS Transport Stream (stima) Kbps Kbps Nella tratta ADSL, le trame Ethernet sono trasferite in ATM, e ciò comporta il maggior peso di overhead. La tabella A riassume in valori assoluti e percentuali la situazione per un flusso audio/video. Si suppone che l audio sia un audio stereo, ciascun canale codificato a 96 Kbit/s. Poiché il servizio è un servizio di tipo Triple Play, occorre riservare una quota della banda fisica alle componenti VoIP e dati; in tabella si sono fatte delle ipotesi che hanno valore esemplificativo; in particolare è una scelta di modello di servizio decidere se riservare una quota fissa di banda per i dati. Interessante notare dalla tabella che: il peso in percentuale dell overhead dei protocolli, che assorbe oltre il 15 % della banda disponibile sull ATM, su reti IP si riduce al 4 %; in un servizio Triple Play, meno dell 80% della banda fisica disponibile rimane utilizzabile per i contenuti audio/video; la banda massima configurabile all encoder per la componente video è di 3,5 Mbit/s. In altre tratte del percorso di rete, a monte della tratta ADSL, una parte dei protocolli, soprattutto nella parte bassa dello stack, non è presente. La descrizione è qui riferita al trasporto di contenuti live, ma al di sotto del livello applicativo essa è applicabile anche ai contenuti on demand. Dimensione pacchetto TS Dimensione pacchetto (payload stack protocolli) Componente VoIP Componente dati Header RTP (opzionale) Header UDP Header IP Overhead Ethernet (Header + CRC) Header LLC/SNAP Header totale (senza RTP) Header totale (con RTP) Dimensione totale trama Eth (senza RTP) Dimensione totale trama Eth (con RTP) Header AAL5 Celle ATM Numero celle per pacchetto (senza RTP) Numero celle per pacchetto (con RTP) Header totale ATM (senza RTP) Header totale ATM (con RTP) Header totale stack di protocolli (senza RTP) Header totale stack di protocolli (con RTP) anda fisica downstream su tratta ADSL anda netta disponibile per il payload ATM (senza RTP) anda netta disponibile per il payload ATM (con RTP) anda netta disponibile per il TS (senza RTP) anda netta disponibile per il TS (con RTP) anda netta disponibile per il video (senza RTP) anda netta disponibile per il video (con RTP) anda netta disponibile per il video (con RTP ma senza TS) ADSL ATM CRC LLC Asymmetric Digital Subscriber Line Asynchronous Transfer Mode Cyclic Redundance Code Logical Link Control TAELLA A Valori assoluti e percentuali per un flusso audio/video. Kbps Kbps 0,91 Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s 4,10 4,41 11,02 11,02 15,12 15,43 78,92 78,69 RTP Real Time Protocol SNAP SubNetwork Access Protocol TS Transport Stream La URL con cui viene fatta la richiesta di aggancio è del tipo igmp://multicast_address:port. Come indicato in precedenza, attualmente l audio è tipicamente trasportato nello stesso Transport Stream del video per cui una sola URL è sufficiente; nel caso uno o più canali audio fossero erogati separatamente dal video ad essi dovrebbero essere associate URL proprie, con la stessa sintassi indicata sopra. Un aspetto rilevante di qualità del servizio IPTV per i canali live è il tempo di zapping (passaggio da un canale ad un altro), che dovrebbe tendere ad essere vicino a quello del cambio canale con la TV analogica (dell ordine di millisecondi). Come già per la TV digitale da satellite, nella IPTV tale tempo tende a raggiungere l ordine di grandezza dei secondi, per il sommarsi di almeno quattro componenti di ritardo: tempi di leave e successivo join del protocollo IGMP (dovrebbe incidere solo per le decine di millisecondi); NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

18 tempi di gestione dei tasti del telecomando da parte del ST (può essere un addendo molto pesante; notare che un cambio canale usando i tasti Ch+ e Ch- è più veloce che usare i tasti numerici); tempi di scaricamento di informazioni relative al nuovo canale prescelto residenti sul middleware (mini EPG, la modalità di scaricamento è normalmente una get HTTP); tempo di buffering da parte del decoder, per assorbire il jitter introdotto dalla rete; il decoder video deve inoltre attendere un frame di riferimento per iniziare correttamente la decodifica. Sono possibili azioni di work around del problema, che abbattono tali tempi al prezzo però di appesantimenti della piattaforma sia in termini di risorse necessarie (server, distribuiti sugli edge della rete) che di traffico sulla rete d accesso. Un esempio importante di queste soluzioni tecnologiche è il meccanismo di ICC (Instant Channel Changing) che è parte caratterizzante del prototipo di piattaforma per IPTV di Microsoft, che sostituisce per un certo periodo di tempo i flussi multicast con flussi unicast memorizzati per tutti i flussi disponibili su risorse specifiche della piattaforma. La soluzione azzera i tempi di zapping ma oltre a richiedere risorse aggiuntive introduce ritardi così rilevanti nel playing del canale da renderne problematica l accettabilità Lo stack di protocolli per contenuti on demand I contenuti on demand possono essere fruiti in modalità streaming o in modalità D&P (Downlaod and Play, paragrafo 2). I servizi IPTV, oggi presenti sul mercato, generalmente utilizzano la modalità streaming per contenuti Standard Definition, ma soprattutto per includere nell offerta un catalogo di titoli in High Definition, la modalità D&P è oggi quella più facilmente praticabile a causa delle limitazioni di banda sulle rete xdsl di accesso su rame. La modalità D&P equivale a scaricare file di grosse dimensioni codificati fuori linea tipicamente in modalità VR (Variable it Rate) e 2-pass. Ad esempio un film di 90 minuti codificato MPEG-2 a 4 Mbit/s produce un file di più di 2,5 G, che nel caso di contenuti HD arriva ad oltre 12 G; la codifica MPEG-4 può realisticamente far risparmiare da un terzo ad un mezzo del bit rate di codifica e quindi della dimensione del file. Lo scaricamento di tali file richiede molto tempo (in funzione della banda utilizzabile nelle ore di scaricamento) e la presenza di un hard disk nel ST. Dal punto di vista dei protocolli alcune alternative sono possibili: FTP: il protocollo più tradizionale, ma meno efficiente; FLUTE (File Delivery over Unidrectional Transport - RFC 3926): protocollo multicast; Protocolli in uso nel peer to peer come ittorrent, dove sono coinvolte sia la componente downstream che upstream della tratta ADSL. Nella modalità streaming i protocolli in uso sono gli stessi indicati sopra per i contenuti live con le due seguenti differenze: Non viene usato il multicast; ogni istanza di contenuto richiesta da un utente viene erogata ad hoc da parte di un server posizionato il più possibile ravvicinato all utente. A differenza dei contenuti live l utente fruisce del contenuto prescelto dal suo inizio e non dall istante corrente. Circolano in rete tante copie dello stesso contenuto quante sono le richieste contemporanee da parte degli utenti. Tali copie interessano i vari segmenti della rete in relazione alla posizione del server erogante; se i video server distribuiti sugli edge della rete hanno in cache il contenuto richiesto, soltanto la rete d accesso è interessata. Viene usato un protocollo di controllo della sessione di erogazione del contenuto chiamato RTSP (Real Time Streaming Protocol) che viaggia su TCP, a differenza del contenuto che viaggia sempre incapsulato in UDP. La fase di apertura della sessione con l invio da parte del video server di informazioni tecniche e di metadati relativi al contenuto, strutturati usando SDP (Session Description Protocol, è un altro standard IETF) come linguaggio descrittivo è una fase problematica per la possibilità offerta dal protocollo di includere o meno alcune primitive. Ciò si traduce nel sorgere di differenti dialetti implementativi di RTSP e nella necessità di coordinamento fra video server e ST sul dialetto usato da uno specifico video server. Il ST deve dunque conoscere a priori con quale video server dovrà dialogare ed essere in grado di riconoscere più di un dialetto. Poiché non sempre i ST hanno la flessibilità richiesta, si possono verificare incompatibilità fra alcuni modelli di ST ed i video server che fanno parte della piattaforma in uso Lo stack di protocolli per altri servizi Accanto ai protocolli usati per il trasporto di audio e video, il servizio IPTV ne richiede il supporto di altri sia per attività di gestione del ST che per i servizi presenti in aggiunta a quelli audio/video. Per le necessarie attività di gestione del ST sono usati ad esempio: DHCP per l assegnazione dinamica degli indirizzi IP; DNS per la risoluzione dei nomi; Protocolli per l upload delle informazioni di configurazione e/o per il caricamento di versioni aggiornate del codice. Queste operazioni possono essere effettuate utilizzando un server TFTP (Trivial FTP) ed il relativo protocollo in modalità unicast, ma sempre più diffusamente sono effettuate facendo circolare in rete alcuni flussi multicast di servizio ai quali il ST, all accensione o periodicamente, si aggancia per attingere alle informazione indicate sopra. Per la fruizione di altri servizi il protocollo prevalentemente usato è HTTP (i ST sono device browser based). Via HTTP vengono scaricate le pagine HTML ed i JavaScript che realizzano l interfaccia utente, residenti sul server di middleware. Informazioni per l identificazione del ST e dell utente, menu, EPG, meta dati sono scaricati sul ST per questa via. 64 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

19 Vi sono piattaforme il cui client può essere progettato in maniera differente: anziché produrre l interfaccia utente localmente mediante browser, almeno parte di essa viene generata con applicazioni residenti su server e semplicemente remotizzata sul client usando protocolli di remotizzazione del desktop come RDP (Remote Desktop Protocol, ancora uno standard IETF). Opera in questo modo il prototipo di piattaforma ad oggi realizzato da Microsoft nei confronti dei client da essa supportati. 6.3 Qualità del servizio Non esiste una soluzione univoca al problema di valutare la qualità del video percepita da parte di un osservatore. Esistono vari modelli matematici che tentano di stimare la qualità, alcuni sono molto semplici, altri molto complessi. I primi in genere calcolano qualche parametro fisico del segnale (il più semplice è il PSNR Peak Signal to Noise Ratio), i secondi in genere tengono conto della funzionalità dell occhio umano (il più comune è il HVS; si veda ad esempio [4]). Questi modelli si possono applicare sia alla valutazione della qualità di una codifica che alla valutazione della qualità del segnale video ricevuto dall utente a valle del passaggio attraverso le risorse che compongono un architettura di rete e di servizio per IPTV. La precedente figura 8 è un esempio di applicazione del modello semplice alla valutazione di una tecnologia di codifica (ed implicitamente dell implementazione di un costruttore, Tandberg). Ha il pregio di essere una metodologia oggettiva e ripetibile ed il difetto di poter non corrispondere alla qualità percepita. Le curve del rapporto segnale rumore sono costruite confrontando, frame per frame, una sorgente digitale (nell esempio un clip di una partita di calcio a risoluzione piena) con il codificato e rilevando gli artefatti introdotti nel frame dalla codifica (il rumore). La qualità del servizio offerto agli utenti IPTV dipende da un insieme di fattori: Qualità della sorgente dei contenuti forniti dai Content Provider: a questo livello il controllo non è funzionale a rilevare condizioni di degrado, quanto piuttosto a: - controllare che il segnale in ingresso ai codificatori non sia assente; - controllare la qualità come erogata dal Content Provider. Può essere verificata (sia come qualità che affidabilità) in modo efficiente all headend, che è un ambiente generalmente presidiato da personale tecnico specializzato. Qualità della codifica; viene definita in modo opportuno in fase di progetto e configurazione, sulla base delle risorse di rete disponibili, del tipo di contenuti e del tipo di servizio erogato; può anch essa venire verificata (per qualità ed affidabilità) una volta per tutte a livello di headend. È un tipo di verifica preliminare per individuare i tipi di codifica ed i costruttori più affidabili. Non è quindi un controllo da effettuare con continuità. Qualità dell erogazione e della distribuzione, inclusa la rete domestica: può essere efficacemente verificato vicino al ST, meglio se in modo diffuso, in quanto vengono presi in esame anche eventuali tratte di rete domestica. Entrano in gioco molteplici fattori: - valutazione attraverso parametri di rete (IP: packet loss, packet mis-ordering, jitter); - assume che il degrado della qualità dipenda esclusivamente dalla rete, perchè la sorgente si considera priva di errori; - è la soluzione tecnologicamente più semplice; - devono essere individuate empiricamente le soglie di riferimento, al di sopra delle quali c è degrado del video. Valutazione attraverso parametri del Transport Stream (continuity counter, PCR jitter,...): - i parametri da monitorare ed i possibili errori sono definiti nella specifica ETSI TR ; - richiede strumentazione specifica - applicabile sia a contenuti in chiaro che criptati. Valutazione del Video Elementary Stream: - occorre gestire metriche tipo MPQM (Moving Picture Quality Metrics) [5]. Qualità del ST: viene determinato una volta per tutte in fase di test per quanto riguarda la qualità ed in fase di assurance per quanto riguarda l affidabilità. Qualità del televisore: è fuori delle possibilità di verifica da parte dell erogatore del servizio IPTV, ma può essere verificato dall utente stesso in maniera guidata, ad esempio confrontando la qualità di fruizione di un DVD e canale TV diffusivo. Oltre a questi fattori oggettivi, si potrebbero considerare anche le aspettative del cliente o il tipo di contenuto; questi fattori possono incidere sui fattori precedenti andandone a modificare i pesi, ma non la sostanza. Vi è inoltre da tenere in conto l aspetto dell affidabilità di ciascuno degli elementi della catena, che possono provocare perdite parziali di qualità o totali (schermo nero). Pertanto sarà necessario tenere sotto controllo anche l evenienza che uno degli elementi della catena si guasti. Se si ipotizza che la qualità finale (percepita dall utente) sia data dal contributo indipendente dei fattori indicati, la cui verifica può essere realizzata analizzando la catena di distribuzione in punti specifici, i punti su cui può concentrarsi l attività di verifica della qualità sono sostanzialmente due: ST ed headend. La qualità finale è data dal prodotto di quella erogata dall headend per la qualità del canale erogazione. Sul ST (o in sua prossimità) si può verificare la qualità del canale di erogazione, analizzando i pacchetti del livello di trasporto (TS oggi, RTP in futuro) per perdite e ritardi. Queste misure sono piuttosto semplici e potrebbero essere effettuate direttamente dal ST ed i contatori di errore pubblicati sulla MI, per potere essere letti dal sistema di gestione del ST. Per la gestione della QoS da parte dell opera- NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre

20 tore sono anche significativi i seguenti due altri aspetti: Individuazione di indici di sintesi che aggreghino i più significativi KPI (Key Performance Indicators) a seconda del livello/tipologia di operatore (Esercizio, Customer Care, Marketing, Content Provider); Individuazione del tipo di informazioni da generare in caso di allarmi. Esempi desunti da soluzioni di costruttori sono: - cattura di spezzoni video a monte e a valle dell allarme; - generazione di log (in forma tabellare e grafica); - alert/pop up locali sul sistema di monitoraggio; - trap SNMP; - alerting attraverso l inoltro di Mail/SMS a specifici destinatari, per il superamento della soglia stabilita per ciascun controllo attivato. 7. Conclusioni La strada dell evoluzione dei servizi IPTV a livello mondiale è appena iniziata e sta ponendo nuove sfide sul fronte dell ingegnerizzazione e dello sviluppo delle infrastrutture di rete a larga banda sugli aspetti più informatici relativi alle piattaforme, ai sistemi di streaming e di content on demand, alla terminalistica e ai temi di protezione dei contenuti. Sfide che coinvolgono tutti gli attori del mondo delle telecomunicazioni, sia gli operatori che le manifatturiere che i system integrators. ANATOMY OF THE LONG TAIL Online services carry for more inventory than traditional retailers. Rhapsody, for example, offers 19 times as many songs as Wal-Mart s stock of 39,000 tunes.the appetite for Rhapsody s more obscure tunes (charted below in green) makes up the so-called Long Tail. Meanwhile, even as consumers flock to mainstream books, music, and films (right), there is real demand for niche fare found only online. Average number of plays per month on Rhapsody 6,100 2,000 1, Songs available at both Wal-Mart and Rhapsody Songs available only on Rhapsody FIGURA 10 Concetto della Long Tail. RHAPSODY TOTAL INVENTORY: 735,000 songs coinvolte possono essere ridotte, grazie alla minore dimensione dei display dei cellulari, ma le architetture di interattività presenteranno molti punti di similitudine e possibile contatto. Collegato all evoluzione delle piattaforme sarà il cambiamento radicale che si verificherà nel modo di fare e utilizzare la pubblicità: per la regionalizzazione dei contenuti, per l interattività e per la possibilità di personalizzazione dei messaggi, che nel mondo del broadcasting non è evidentemente possibile mentre è nativamente inseribile nel mondo IPTV. Ma forse la più grande novità che l IPTV porterà sarà la trasformazione e il passaggio della televisione da un evento del momento a un evento che rimane nel tempo : protypical Wall-Mart store 3000 songs Titles ranked by popularity Un primo passo evolutivo sarà quello riguardante le tecnologie per gestire a costi sempre inferiori e con buone qualità del servizio bande sempre crescenti. Da un lato, l introduzione di IPTV e in particolare di servizi on demand, comporterà sul piano delle tecnologie di rete lo sviluppo della capacità di smaltire traffico IP sui backbone e sulle reti metropolitane e di accesso, con caratteristiche di qualità di servizio (jitter, perdita di pacchetti) molto stringenti. Dall altro lato, l evoluzione verso la alta definizione HDTV (High Definition TV), che richiederà una quantità di banda tripla o quadrupla per canale rispetto a quella attualmente usata in standard definition SDTV (Standard Definition TV), sarà sicuramente una innovazione forte per gli utenti, e permetterà di ridurre o eliminare il gap con Paesi come Giappone e Stati Uniti in cui i servizi HDTV sono già partiti sulle reti TV via cavo, ma accentuerà ulteriormente questo fenomeno. Un secondo passo sarà legato all evoluzione delle piattaforme informatiche e dei terminali, in particolare i ST, che dovranno risultare in grado di sfruttare l interattività permessa dalle reti broadband nell IPTV, con efficacia industriale ma anche e soprattutto soddisfazione e interesse da parte degli utenti finali. In questo senso si verificherà un confronto tra gli standard proposti in ambito DV Forum e ISMA Forum e piattaforme proprietarie proposte da alcuni colossi quali Microsoft. Sempre in quest ottica l IPTV dovrà forse trovare forme di sinergia e integrazione con i servizi di TV in mobilità, anch essi basati sul protocollo IP. Come l IPTV, la mobile TV permetterà interattività anche a un livello personale oltre che in mobilità. Le bande di trasmissioni AMAZON.COM TOTAL INVENTORY: 2,3 million books typical arnes&noble store books NETFLIX typical lockbuster store 3000 books THE NEW GROWTH MARKET: OSCURE PRODUCTS YOU CAN T GET ANYWHERE UT ONLINE TOTAL SALES 22% TOTAL SALES 57% product not available in offline retail stores TOTAL INVENTORY: 25,000 DVDs TOTAL SALES 39, , , % 66 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005