Ip TV Adsl

PIATTAFORME
IPTV, la televisione arriva con lADSL
MAURO BORGHI GABRIELE ELIA DARIO ERCOLE CLAUDIO FRANCO ENZO GASSINO
John Chambers, il Presidente e CEO di Cisco Systems, ha dichiarato recentemente1: 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, levoluzione 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 lintroduzione di servizi TV attraverso reti broadband, quali lADSL e le sue evoluzioni. Ma se larrivo della TV ha da un lato posto nuove sfide in termini di costi e prestazioni allevoluzione delle reti IP, dallaltro offre anche importanti possibilit e prospettive per levoluzione dei servizi televisivi, in primo luogo con lintroduzione 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.
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 ununica rete e un unico collegamento i servizi voce, broadband Internet e TV, sembra essere unottima possibilit per mantenere i clienti e aumentare i fatturati.
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)
http://newsroom.cisco.com/dlls/2005/corp_111805.html? CMP=ILC-001
NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005
47
BORGHI ELIA ERCOLE FRANCO GASSINO IPTV, la televisione arriva con lADSL
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, levoluzione 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, lenorme 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 (STB), 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. Nellarticolo 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 dellecosistema 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. Lutente deve essere dotato di un apposito ricevitore (STB), simile ai prodotti per TV satellitare o DTT (Digital Terrestrial Television), collegato da un lato alla TV e dallaltro, invece che a un cavo dantenna, a una connessione ADSL. In alcuni prodotti
commerciali, il STB dispone gi di un modem ADSL incorporato; in altri casi, il modem esterno e collegato al STB tramite una connessione Ethernet, ad esempio. I servizi video IPTV si suddividono in Servizi di Broadcast TV (BTV) e Servizi di Video on Demand (VoD). I Servizi di Broadcast 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, lutente paga per vedere una trasmissione a un orario prestabilito. I canali live possono essere raggruppati in pacchetti di offerta (ad esempio: Basic, Premium, ) che lutente pu sottoscrivere. I servizi BTV sfruttano tipicamente le funzionalit di multicast presenti su una rete IP. In generale, per i servizi BTV le operazioni di selezione e programmazione dei canali, ma anche la navigazione per lacquisizione di informazioni sui contenuti, sono rese disponibili tramite la guida interattiva EPG (Electronic Program Guide) e vengono effettuate a video con lutilizzo 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 BTV, rientra il videoregistratore digitale o Personal Video Recorder (PVR) che nel mondo IPTV viene realizzato in due diverse modalit: Local PVR (LPVR): videoregistrazione digitale sullhard disk, che potr essere collegato o interno al STB. Network-based PVR (NPVR): videoregistrazione digitale su spazio messo a disposizione nellinfrastruttura (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 linstant replay. Per i servizi BTV possono inoltre essere messe a disposizione dellutente 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 allutente 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. Lutente interagisce direttamente con il catalogo creato dal service provider per navigare, richiedere, ricevere e
48
visualizzare in tempo reale (streaming) i contenuti audio/video di proprio gradimento, avendo a disposizione le funzioni tipiche di un videoregistratore (trick-play). Per lerogazione dei servizi VoD vengono principalmente utilizzati i tradizionali meccanismi di streaming unicast della rete IP; la qualit dellaudiovisivo fruito dallutente 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 sullhard disk, di cui deve essere provvisto il STB, e pertanto tra listante 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 dellerogazione che della fruizione da parte dellutente, si tratta di un servizio BTV 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 BTV e VoD disponibile la funzionalit di Parental Control che, tramite lutilizzo 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, lutente potr anche selezionare una serie di servizi interattivi messi a disposizione dal service provider, quali: Web Browsing: 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 lusabilit 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 STB funziona come game console ; lutente pu accedere ad un catalogo di giochi e tramite la connessione broadband pu anche interagire con altri giocatori in ambienti multiplayer; Applicazioni di comunicazione: e-mail, 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 duso, sia il Service Provider, che effettivamente li commercializza e li distribuisce, sia lutente 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 nellIPTV, si basano su tre componenti: Broadcast 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. STB: il dispositivo che ospita il Security Module e che, ricevuta la chiave di decriptazione, decifra il segnale. Lapproccio 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 duso. 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 dallaltra con lutente. 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 unaccesa battaglia fra varie aziende e consorzi, sia per il controllo del mercato che per le importanti royalties da brevetti che saranno riscosse.
49
3. Il Centro Servizi
Headend Video Distribution
Headend Equipment IRD
Transport
Access
Encoders IRD
GigaBit Switches TV Management Platform VOD Servers
DSLAM Backbone IP STB with Smartcard
Switch Gigabit Ethernet Scrambling
Il Centro Servizi IPTV ospita tutte le componenti necessarie allerogazione e alla gestione dei servizi video. Allinterno del centro servizi sono collocati gli apparati che costituiscono lheadend per lerogazione dei contenuti BTV (Broadcast 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 STB VOD = = = =
Conditional Access System
3.1 Headend , contenuti BTV

Scopo dellheadend quello di acquisire dalla sorgente, adattare e distribuire i contenuti video live che fanno parte dellofferta dei servizi IPTV. Lheadend 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 dallheadend 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
Digital Subscriber Line Access Multiplexer Integrated Receiver Decoder Set-Top Box Video On Demand
FIGURA 1 Esempio di architettura del servizio IPTV.
2.2 Larchitettura del servizio
I servizi IPTV vengono distribuiti tramite unarchitettura costituita da tre macro blocchi: Il Centro Servizi, che costituito dagli elementi che concorrono nelle fasi di fornitura e gestione dei servizi stessi, quali lheadend, per lacquisizione, ladattamento e la distribuzione dei contenuti live e i server, dove risiedono il middleware (lo strato software che consente linteg ra zi on e tra la pia ttaforma del service provider e lo strato tecnoloTrasporto gico dellarchitettura) e il IRD sistema per la protezione dei contenuti; La Rete di Trasporto, Encoders costituita dalla dorsale di IRD trasporto e dalla rete metropolitana, cio dagli apparati di instradamento GigaBit dei pacchetti IP e dai colSwitches Backbone legamenti in fibra ottica; La Rete di accesso, Gigabit Ethernet costituita dalle compoScrambling Switch nenti di raccolta/multiplazione e distribuzione verso gli apparati di rete domestica, dai collegaContent menti in fibra e rame e Protection System dalla rete domestica DSLAM = Digital Subscriber Line Access Multiplexer IRD = Integrated Receiver Decoder stessa (home network). STB = Set-Top Box Nella figura 1 indicata la rappresentazione grafica FIGURA 2 Distribuzione dei contenuti Multicast (TVLive). di quanto fin qui brevemente accennato.
Accesso
DSLAM IP STB with Smartcard
Distribuzione contenuti Multicast Fruizione contenuti Multicast
50
(solitamente MPEG-2), sia in formato SPTS (Single content provider esterni (ad esempio Time Warner, Program Transport Stream) che in formato MPTS Fox, ) su reti di contribuzione dedicate o diretta(Multiple Program Transport Stream); nellultimo mente su supporto fisico (ad esempio cassette caso i programmi devono essere de-multiplati in Digital Betacam). SPTS per poter essere trattati come singoli canali Una volta acquisiti, i contenuti vengono codifidalla piattaforma. I flussi in ingresso, se compressi, cati da encoder software specializzati per tecnica sono decodificati e, se criptati, decriptati. che possono adottare codifiche multi-passo (per I singoli canali sono quindi codificati da encomigliorare la qualit a parit di bit rate) e che adatder specializzati per tecnica di codifica (ad esemtano i contenuti, in termini di bit rate e formati, alle pio MPEG-2, MPEG-4 AVC, MS-VC1) con bit rate e caratteristiche della rete, dei terminali e della QoS caratteristiche adeguate alle caratteristiche della richiesta. rete daccesso, alla tipologia di terminali utilizzati, I contenuti sono quindi criptati da server dediai formati video supportati. I flussi in uscita dagli cati del sistema di CA/DRM di protezione dei conencoder vengono criptati da server dedicati del tenuti e memorizzati allinterno del catalogo dei sistema di CA/DRM di protezione dei contenuti, contenuti; la funzionalit di catalogo svolta dai incapsulati in IP e distribuiti in multicast sul backCentral VoD Server collocati a livello di headend bone. La distribuzione di tutti i canali video avviene (figura 3). attraverso il backbone fino agli apparati della rete di accesso DSLAM (Digital Subscriber Line Access Multiplexer); dai DSLAM inviato allutente finale un VOD singolo canale video. La Edge Servers selezione del canale che luCentral VOD GigaBit tente desidera ricevere Servers Switches avviene attraverso il protoSwitch collo IGMP (Internet Group Scrambling Management Protocol) con richieste generate dal STB Backbone verso il DSLAM a cui atteEncoders DSLAM stata la linea utente. IP STB with Smartcard Tutte le operazioni di acquisizione, adattamento e Content Protection System distribuzione vengono eseEdge VOD guite in modalit real time Servers dagli apparati che compongono lheadend BTV (ricevitori satellitari e/o DTT, encoHeadend Video Distribution Trasporto Accesso der, streamer, sistema di protezione dei contenuti); DSLAM = Digital Subscriber Line Access Multiplexer Distribuzione contenuti Ulnicast tali apparati sono tipicaSTB = Set-Top Box Fruizione contenuti Unicast = VOD Video On Demand mente centralizzati a livello di centro servizi. Un certo grado di distribuzione del- FIGURA 3 Distribuzione dei contenuti Unicast (VOD). lheadend si pu realizzare prevedendo la dislocazione a livello regionale degli Poich la fruizione dei flussi VoD comporta lo apparati per lacquisizione, trasformazione e distristabilirsi di una sessione IP unicast tra video serbuzione di canali locali; in alternativa, possono ver e ogni STB che richiede il servizio, prevista essere previste reti di contribuzione regionali verso la distribuzione a livello regionale dei video server lheadend centralizzato. (Edge VoD Server) al fine di permettere il partizio3.2 Headend, contenuti VoD namento del carico sui server e lottimizzazione dellutilizzo di banda sulla rete di trasporto. La Lo scopo di questo headend quello di acquidistribuzione dei contenuti avviene dai Central sire, adattare, memorizzare, distribuire e permetverso gli Edge Server. tere la fruizione dei contenuti VoD. Tutte le fasi, Gli Edge Server effettuano lo streaming in eccetto la fruizione, sono svolte in modalit off unicast verso i client attraverso il protocollo line (non real time ) da processi automatici e RTSP (Real Time Streaming Protocol). Tale prosemiautomatici supportati dagli strumenti forniti tocollo consente al client la richiesta e il condalla componente DAM (Digital Asset trollo della fruizione dei contenuti attraverso Management) della piattaforma. comandi VCR like (Fast Forward, Rewind, I contenuti VoD sono generalmente forniti da Pause, Stop, Play).
51
3.3 Il ruolo centrale del middleware per IPTV
Il ruolo centrale nellarchitettura svolto dal cosiddetto IPTV middleware che ha il compito di: garantire lintegrazione 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 lerogazione dei servizi IPTV; supportare lintegrazione 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 Subscriber Service Provider Content Provider pi rapida evoluzione, perch nella Portal Framework sua evoluzione si confrontano da un lato importanti industrie che Digital Asset Subscriber Content Providers Network cercano di imporre soluzioni proManager Manager Manager & prietarie, dallaltra sforzi di stanService Manager dardizzazione delle associazioni che gi hanno standardizzato la TV digitale satellitare e terrestre (ad Server esempio DVB Forum). Manager La mancanza di un middleware Device standard rende molto frammentato Manager il mercato delle applicazioni e dei servizi, rendendo difficili le economie di scala sui prezzi e rallenSERVICE CONTROL (User Presence/Service Admission Control/Session Management/Accounting/Unified Directory) tando leffettivo decollo commerciale dellofferta. La piattaforma di middleware Network (IP, ATM, xDSL, GBE, Metro, ...) realizza un modello client/server Middleware Client/Browser con la componente server centralizzata a livello di headend e la ATM = Asynchronous Transfer Mode componente client residente sul EPG = Electronic Program Guide GBE = GigaBit Ethernet STB. La fruizione dei servizi IPTV IPTV = Internet Protocol TeleVision avviene attraverso linterazione STB = Set-Top Box STB IPTV xDSL = x Digital Subscriber Line utente, che utilizza il telecomando, con la UI (User Interface) definita e gestita dalla piattaforma. FIGURA 4 Architettura funzionale del middleware. La componente client, utilizzando le funzionalit di base del STB, supporta la presentazione 3.3.1 Channel Manager grafica della UI, la decodifica, la decriptazione e la visualizzazione dei contenuti. La tipologia di client La componente supporta le funzionalit legate supportato una delle caratteristiche distintive di alla gestione canali video BTV; in particolare peruna piattaforma di middleware: si parla di fat mette: client (o di soluzione client based) quando lin la definizione dei canali, lassociazione dei tera UI viene generata e gestita tramite un procanali con gli stream generati dagli encoder, la gramma proprietario eseguito dal STB, mentre il definizione dellindirizzo IP del gruppo multicast termine thin client viene generalmente utilizzato utilizzato per la trasmissione in rete del canale; per le soluzioni basate su browser, in cui il STB, limpostazione e la modifica dello stato del tramite browser appunto, si limita ad effettuare il canale (on line, off line, hidden, ...); rendering di pagine HTML generate lato server. la definizione e la modifica dei metadati assoUna soluzione browser based facilita lintegrazione ciati ai canali: numero canale, nome, descridi nuovi tipi di terminali (STB) ai quali essenzialzione, tipologia (Basic, Premium, Pay Per View, mente richiesta la sola compatibilit a livello di ...), genere (News, Movies, Sport, ...), livello di browser; mentre linterazione client/server (HTTP e rating associato al canale (adatto a tutti, per JavaScript) della UI ha generalmente prestazioni minori accompagnati, per adulti), multilingua, inferiori rispetto ad una soluzione client based. Una stereo, . soluzione client based ottimizza linterazione
Digital Right Manager Transaction Manager Advertising Manager Packaging Manager Channel Manager EPG Manager Profiling Manager Pricing Manager
client/server della UI, ma lintegrazione di nuovi tipi di terminali comporta unattivit 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, DB server. Il DB generalmente di tipo centralizzato; per ottimizzare laccesso possono essere previsti diversi livelli caching. Le componenti e funzionalit principali di una piattaforma di middleware sono riassunte nella figura 4.
52
3.3.2 EPG (Electronic Program Guide) Manager
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 dellinterazione utente sulla guida: selezione canali e programmi, richieste di informazioni (visualizzazione dei meta-dati associati ai canali e ai programmi), richieste di registrazione programmi, ... .
3.3.3 Digital Asset Manager (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.
3.3.4 Subscriber Manager
I pacchetti di offerta sono generalmente commercializzati sotto forma di abbonamento che lutente 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 lutente pu effettuare on line, direttamente dalla UI sul televisore o dal portale daccesso ai servizi IPTV (Portal Framework nella figura 4), senza richiedere lintervento di un operatore. La componente di Packaging Manager supporta la definizione dei pacchetti di offerta attraverso le funzionalit di: packaging di canali live (esempio: definizione dei gruppi di canali associati agli abbonamenti: Base, Sport, Calcio, ...); packaging di contenuti VoD (Bundle, Subscription VoD), appoggiandosi alle funzionalit fornite dal DAM. La componente di Pricing Manager 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 dallutente.
3.3.6 Transaction Manager
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, e-mail, ...); la gestione di gruppi di utenti; la abilitazione/disabilitazione dellaccount alla fruizione di servizi o bundle di servizi; la abilitazione/disabilitazione dellaccount alla fruizione di package e bundle di contenuti.
3.3.5 Packaging Manager e Pricing Manager
Compito del Transaction Manager quello di supportare lesecuzione e mantenere la traccia di tutte le transazioni che avvengono allinterno della piattaforma di erogazione del servizio. Per le transazioni quali la modifica delle sottoscrizioni effettuate on-line dallutente e lacquisto di contenuti VoD o di eventi PPV, la componente supporta anche linterazione con i sistemi di billing e di CRM attraverso il mantenimento di un DB di tutte le transazioni eseguite e lesposizione di API (Application Programming Interface). Nel caso di variazioni delle sottoscrizioni di servizi e pacchetti che sono fatturati periodicamente, linterazione con tali sistemi pu avvenire in modo differito, ad intervalli di tempo prestabiliti, rispetto alleffettiva esecuzione della transazione. Per lacquisto di contenuti on demand ed eventi in PPV (Pay Per View), per i quali pu essere richiesto il pagamento prima della loro fruizione, linterazione con il sistema di billing deve essere on line. Il DB 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, ... .
3.3.7 Profiling Manager
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.
responsabile della gestione, per ognuno degli utenti abilitati, dei dati di profilatura che comprendono informazioni relative alla tipologia daccesso 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-
53
tal control (esempio: contenuti per adulti visibili solo inserendo il PIN); le liste dei canali preferiti, dei canali bloccati, dei bookmark.
3.3.8 Advertising Manager
Fornisce le funzionalit di base per ladvertising che pu essere effettuato sulla UI, attraverso lutilizzo 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 dellutente, a quella legata al contesto dei contenuti che lutente sta fruendo.
3.3.9 Server Manager e Device Manager
Alcuni flussi audiovisivi sono erogati dal vivo, o pi in generale in modalit diffusiva (BTV), 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 lindirizzo 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 5.
4.1 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. Laccesso 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).
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 sullordine 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; unaltra 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.
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 uninterfaccia GbE verso la rete e devono supportare direttamente IP multicast. Al DSLAM collegata lutenza domestica, attraverso la linea ADSL, la CPE (Customer Premises Equipment, o router di accesso), la rete domestica ed infine il terminale IPTV o STB. La coppia DSLAM-CPE diventa lo snodo principale per lintegrazione dei servizi triple play (Internet, voce e TV), in quanto il punto in cui i tre servizi convergono verso lutente e verso la rete domestica e deve essere in grado di garantire la loro coesistenza sulla tratta pi critica dellintera 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
Headend
Middleware CAS Content Management VoD Server EPG Edge Router Metro GbE
Rete di Distribuzione
Sede cliente
VOD Server Metro MAN GbE
Feeder GbE CWDM/DWDM metro ring
DSLAM
STB CPE ADSL PC
NAS
Dorsale Encoder
Contribuzione
Video Streaming Metro GbE Metro GbE DSLAM CWDM/DWDM metro ring Feeder GbE MAN NAS STB VOD = = = = Metropolitan Area Network Network Access Server Set-Top Box Video On Demand STB CPE ADSL PC
Content Provider VOD Server Metro = = = = = =
MAN GbE
ADSL CAS CPE DSLAM EPG GBE
Asymmetric Digital Subscriber Line Conditional Access System Customer Premises Equipment Digital Subscriber Line Access Multiplexer Electronic Program Guide GigaBit Ethernet
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 uneventuale interfaccia WiFi (IEEE 802.11b/g). Siccome il STB per la fruizione del servizio IPTV deve essere collocato vicino al televisore, nel caso la CPE sia distante dal STB e non sia disponibile un cablaggio in rame che supporti Ethernet (cavo UTP5), necessario ricorrere a tecnologie alternative che non richiedono linstallazioni di nuovi cavi (no new cable); ad esempio la tecnologia WiFi che ha lenorme 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 luso. 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.1 Caratteristiche hardware

I STB 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 lobiettivo di minimizzare il costo del sistema. Sui STB 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 MB), porte seriali (ad esempio USB), 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 STB 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 dallhardware. Daltro canto, per supportare un numero sempre maggiore di codec e di for-
5. Terminali
I terminali per IPTV, come i decoder per TV digitale terrestre o satellitare, vengono generalmente chiamati set-top box (STB).
55
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 dallelaborazione di flussi video (Sigma Designs EM8xxx, AD Blackfin, Philips PNX1x00, Equator BSP-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. Lulteriore tendenza allintegrazione, 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, IBM Pallas, Sigma Designs SMP863x). da notare tuttavia che larchitettura logica del sistema rimane internamente equivalente alle soluzioni dual chip. Lassenza 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 dellinterfaccia utente. Mentre il video viene generato dal media processor, solitamente la grafica sintetica origina dallaltro 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 STB. 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 STB 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 dallarchitettura
selezionata per il processore principale, in quanto non tutti i sistemi operativi supportano tutte le architetture. Un produttore di STB 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 STB 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 STB, 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 lOS 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 lobiettivo 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 STB 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); loccupazione 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 allOS 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
Daltro canto, per poter avviare e controllare la riproduzione di media senza abbandonare lapplicazione web, linterprete 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 STB. Come per le altre parti del STB, 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 STB non possono consegnare alloperatore 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 allintegrazione finale del servizio; ad esempio, il middleware scelto ha bisogno di modifiche al browser, i video server richiedono qualche adattamento di protocollo, loperatore 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 limmagine software ed infine possono emergere incompatibilit sul formato di codifica video .... Vista la complessit del software dei STB, che porta a scoprire errori quando questi sono gi in campo, e vista la necessit di preservare nel tempo linvestimento fatto sul terminale, esiste sempre un meccanismo per aggiornare, tutta o in parte, limmagine software di questi sistemi. La modalit di aggiornamento dipende da come il STB 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 STB 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 limmagine 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.
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 STB, e che quindi include sintonizzatore e decodificatore? Accanto al sintonizzatore DTT o a quello satellitare potremmo aspettarci che si diffondano anche i sintonizzatori IP? Lunica 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 STB e per i broadcaster satellitari e terrestri si aprono varie opportunit per potenziare i loro servizi: dallintroduzione 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 lefficienza trasmissiva (DVB-S 2), ad un uso massiccio del canale broadband (DSL). Trovando modelli di business soddisfacenti per tutte le parti, i STB 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 STB 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 & Burn (Scarica & Masterizza) e naturalmente dovrebbe costare pi del VoD, visto che il contenuto va ad arricchire la videoteca dellutente. 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.
5.3 Set-top box: uno sguardo al futuro

Dopo aver visto alcune caratteristiche hardware e software dei STB, e dopo aver riconosciuto gli attori coinvolti in questo mercato, interessante porci alcune domande su quale possa essere il futuro dei terminali IPTV. Lanalisi 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 Blu-ray ), la rete domestica.
6.1 Codifiche Video: da MPEG-2 a MPEG-4

6.1.1 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.
57
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.
< 0.384 Mbps < 1.5 Mbps 1-2 Mbps 2-3 Mbps 4-6 Mbps 8-10 Mbps 12-20 Mbps 27.5-40 Mbps 32-40 Mbps 34-50 Mbps 140 Mbps 168 Mbps 216 Mbps 270 Mbps 1-1.5 Gbps
Video conference (MPEG-4) Video in a window (MPEG-1) VHS quality full screen (MPEG-2) Broadcast NTSC Broadcast PAL Professional PAL Broadcast HDTV (MPEG-2) (MPEG-2) (MPEG-2) (MPEG-2)
DVB satellite multiplex (MPEG-2 Transport) (MPEG-2) Professional HDTV (MPEG-2-I) Contribution TV Contribution TV Raw NTSC Raw PAL Raw contribution PAL Raw HDTV (MPEG-2-I) (uncompressed) (uncompressed) (uncompressed) (uncompressed)
FIGURA 6 Richieste di banda per i diversi sistemi televisivi.
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 dallutente 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 MPEG2 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 allarticolo 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 9800 3500 4000 5000 7000 8000 9000 impiego nel contesto IPTV. 2500 5500 Ottima Ottima Tipicamente una codifica 2300 4500 MPEG-2 parte da un conte2000 3000 Scarsa Scarsa 352x480 MPEG2 720x480 MPEG2 nuto audio/video digitale non compresso (o poco Bit rate compresso), organizzato in frame (quadri dellimmagine) FIGURA 7 Andamento della relazione fra risoluzione, bit rate e qualit. che si presentano con una velocit di ripetizione di 25
Qualit percepita Qualit percepita
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 lopzione capped variable). Una codifica VBR (Variable Bit 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 lIPTV) occorre produrre una codifica CBR (Constant Bit 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 dellencoder, tenendo conto che la relazione fra risoluzione, bit rate e qualit ha landamento delle curve riportate in figura 7. Sono curve che descrivono lesperienza empirica di qualit soggettiva
9800
Bit rate
58
PSNR (dB relative)
nelloperare 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. Laudio 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 laudio di tipo Dolby Digital 5.1 Laudio 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) 12.0 molto pi efficace ma non compatibile con quelle precedenti, in realt usata per 10.0 codificare laudio nelle nuove tecnologie, ad esempio in MPEG-4 AVC, 8.0 descritta nel paragrafo successivo.
6.0
AVC avr raggiunto la maturit che oggi hanno ad esempio le implementazioni dei codificatori MPEG2. 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 (STB) per la decodifica; inoltre si verifica una diffusa difficolt di interoperabilit di un STB con codificatori di costruttori diversi. Per i contenuti on demand , sono disponibili alcuni codificatori (anche prodotti software) mentre ancora in corso ladeguamento dei video server a gestire contenuti codificati MPEG-4 AVC.
6.1.3 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.
6.1.2 MPEG-4 AVC
4.0
Il nuovo standard congiunto ISO MPEG-4 Part10 2.0 (MPEG-4 AVC) - ITU H.264 permette un salto nella Fonte: Tandberg capacit di compressione 0.0 video e audio, riducendo il 2.5 3.0 1.0 1.5 2.0 bit rate necessario rispetto a Bit rate (Mbit/s) MPEG-2 anche del 50%, MPEG-4 AVC/m MPEG-4ASP WMV9 (beta) MPEG-2 rendendo molto pi fattibile la trasmissione di video di qualit broadcasting su reti ADSL. FIGURA 8 Confronto tra le performance delle tecnologie di codifica. H.264/AVC contiene numerose nuove funzionalit che gli consentono di comprimere il video in VC1 deriva dallesperienza pluriennale di maniera molto pi efficiente dei codec precedenti, Microsoft con la tecnologia WM9 (Windows Media in particolare di MPEG-2, al prezzo di una mag9), che ha comunque come target il PC come tergiore complessit del codificatore. minale (formato progressivo e non interallacciato), Lobiettivo dichiarato di pari qualit rispetto ad risoluzioni inferiori a quella televisiva (tipicamente MPEG-2 a met del bit rate va inteso come un CIF (352x278) rispetto al PAL (720x576), bit rate obiettivo a regime, quando limplementazione degli inferiori. VC1 viene indicato come un profilo di algoritmi facenti parte della tecnologia MPEG-4 WM9: Advanced Profile.
59
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 lelementary stream per il video.
6.2 I protocolli per streaming e controllo

6.2.1 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 laudio, 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 informa6.2.2 Lo stack di protocolli per i contenuti live zioni di controllo per la sincronizzazione degli ES: PTS (Presentation Time Stamp) e DTS (Decode Poich il tratto pi critico del percorso di rete Time Stamp). Lo standard MPEG-2 consente due rappresentato dalla tratta ADSL, si dar unindicatipi di multiplazione dei pacchetti PES: zione dei protocolli presenti al di sopra del livello MPEG Program Stream: riguarda il caso di pacfisico in tale tratta. chetti PES strettamente correlati e con la stessa La caratterizzazione della banda fisica disponibase tempi. Si applica a contesti nei quali sia bile sulla tratta ADSL deve essere tale da garantire bassa la probabilit di errori e consente una pi la raggiungibilit di unelevata percentuale di facile elaborazione dei dati in ricezione. la utenza sul doppino telefonico, che introduce atteforma di multiplexing usata nei device di video nuazione e perdite proporzionali alla sua lunstorage, tipicamente i DVD; ghezza; a titolo di esempio, i valori a cui si fa riferi MPEG Transport Stream: ciascun PES spezmento sono quelli dellADSL a 4 Mbit/s (4832 zato in transport packets di dimensione fissa; Kbit/s in downstream e 320 Kbit/s in upstream), lo stream pu contenere pacchetti provenienti dellofferta Telecom Italia. da PES indipendenti. la forma di multiplexing Interessa qui analizzare la componente downidonea al caso di trasmissioni su media potenstream, sulla quale transitano i contenuti zialmente affetti da errore e quando interessa audio/video poich pone i maggiori vincoli. assemblare pi programmi nello stesso stream. la forma di multiplazione adottata dal D V B (Digital Video Broadcasing), il consorzio europeo per la Video Video ES Packetizer PES standardizzazione della Encoder distribuzione dei segnali PES #1 televisivi, e non solo. Il DVB Audio Audio ES Packetizer PES TS Error Prot. & PES #2 Program # Encoder si occupa sopratutto della Modulation Channel trasmissione televisiva satel DVB-C (Cable) Formatter/ PES litare digitale (DVB-S) , ma Data DVB-S (Satellite) Packetizer DVB-T (Terrestrial) definisce in generale come i Service segnali MPEG-2 sono traDVB = Digital Video Broadcasting Information ES = Elementary Stream smessi anche su cavo (DVBPES = Packetizer Elementary Stream C), o a frequenze televisive TS = Transport Stream terrestri (DVB-T) e anche come sono gestite le inforFIGURA 9 Componenti dello stream MPEG-2 e Multiplazione a livello applicativo. mazioni di servizio, le EPG (guide programmi) e gli
Transport Multiplex
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 quellinsieme di dati di controllo che servono per gestire le associazioni fra gli ES e descriverli. Linsieme di SI (si veda oltre) deriva in parte dallo standard MPEG-2 in parte integrato con campi definiti in ambito DVB. Allinterno 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 DVB 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.
60
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 Video packet Audio packet Programme Association Table (PAT) Other packets Programme Map Table (PMT) sono trasportate allinterno di tabelle di segnalazione, pac51 64 51 0 15 51 10 51 chetti di piccole dimensioni nel 1 TS, separati ed asincroni Packet header includes Programme guides, rispetto ai PES (Packetised PAT lists PIDs for PAT lists PIDs associated a unique packet ID (PD) programme map tables with a particular programme Subtitles, Elementary Stream). for each stream Multimedia data, Network Info = 10 Video = 51 Internet packets, Prog 1 = 15 Audio (English) = 64 Esempi di tabelle di segnalaetc Prog 2 = 301 Audio (French) = 66 zione sono: Prog 3 = 511 Subtitle = 101 etc. etc PAT (PID 0x000) (Program Association Table): riporta la lista dei Packet FIGURA A Transport Stream. Identifier (PID) associati ai singoli programmi; CAT (PID 0x001) (Conditional Un insieme di tre flag per indicare zione. Il clock di sistema 27 Access Table): inviata nel caso di come il pacchetto deve essere Mhz; in ricezione viene generato ES criptati, fornisce le informaprocessato; un clock locale e da questo zione sul tipo di scrambling ed Packet Identifier (PID) (per il suo estratto un contatore che viene indica i PID associati ad altre inforruolo, si veda sopra); confrontato con il PCR ricevuto; le mazioni sullaccesso condizionale; Due bit usati dalle procedura di eventuali differenze sono usate PMT (Program Map Table): definicontrollo daccesso; per correggere la frequenza delsce linsieme di PID associati ad Due bit per indicare la presenza loscillatore locale in ricezione; un singolo programma: il PID di dell"adaptation field": DTS (Decoding Time Stamp) e questa tabella per ciascun pro- 01 no adaptation field, payPTS (Presentation Time Stamp): gramma quello precedenteload only; sono trasferiti nellheader di ogni mente letto nella PAT. - 10 adaptation field only, no PES e servono per stabilire gli Il DVB ha definito alcune ulteriori payload; istanti di decodifica di un singolo tabelle opzionali con lo scopo di - 11 adaptation field followed by frame e dunque la sincronizzadescrivere i servizi trasportati (il ruolo payload; zione fra ES. di queste tabelle direttamente com- 00 Reserved for future use; La dimensione di un transport packet prensibile dal nome): se presente, ladaptation field si 188 bytes, di cui 4 di header. In questo NIT (PID 0x010) (Network colloca a valle dellheader, prima header fondamentale il campo di 13 Information Table): contiene infordel payload. Un contenuto imporbit del PID per individuare i singoli PES mazioni sul mezzo fisico su cui tante delladaptation field il PCR; di cui il transport packet parte. Nel linformazione trasportata Continuity Counter (4 bit): contatransport stream non garantito alcun (esempio, se si tratta di satellite: tore molto utile per valutare le ordine di trasmissione dei pacchetti, transponder, symbolrate, FEC, ); continuit dei pacchetti ricevuti e cio non vi sincronizzazione fra i PES BAT (Bouquet Association Table); per segnalare eventuali perdite. presenti. Per mantenere il bit rate del SDT (Service Description Table); TDT (Time and Date Table); 188 bytes transport RST (Running Status payload header payload header payload packet header stream Table); payload adaptation transport transport EIT (Event Information sync continuity adaptation unit start transport scrambling field error PID byte priority counter field indicator control control indicator Table). 8 1 1 1 13 2 2 4 La figura A, tratta da [3], PID = Packet Identifier riporta un esempio di spezzone di Transport Stream. FIGURA B Transport Packet. La sincronizzazione fra gli
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 rice-
mulitplex impostato in fase di configurazione possono essere inseriti anche pacchetti di stuffing (PID = 0x1fff). La struttura di un transport packet riportata in figura B: Il significato dei vari campi dellheader il seguente: Synchronisation Byte: identifica linizio del pacchetto. Il suo valore, fisso, 0x47;
61
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 loverhead dei protocolli. Non lunica 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 lassenza 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 STB 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, luso di RTP consentirebbe una maggior efficienza e flessibilit nella gestione degli elementary stream audio e video. Oggi, come detto in precedenza, laudio viene normalmente trasportato embedded insieme al video in unico transport stream; con luso di RTP ogni flusso elementare potrebbe viaggiare per proprio conto, poich in RTP sono presenti i controlli per sincronizzare i flussi. Ad esempio luso di RTP nella modalit sopra accennata sarebbe vantaggioso nel caso di audio multilingua: se laudio viaggia embedded con il video sono possibili due alternative entrambe inefficienti: si possono trasmettere sempre tutti i canali audio associati alle varie lingue che lutente pu scegliere di ascoltare, con lovvio spreco di banda sulla tratta critica ADSL, oppure si pu trasmettere dallheadend 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 dellelementary 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 (STB) e che fornisce alla parte sorgente informazioni di controllo istantaneo sullo stato della comunicazione; utilizzando questo pro-
tocollo 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 delloverhead 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.
6.2.3 Il ruolo del multicast
I contenuti live sono trasmessi utilizzando lopzione 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 luso 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, lutente inizia a fruire del contenuto presente sul canale prescelto nel momento della sua connessione, ricevendo quanto in quel momento viene trasmesso e non dallinizio. Lopzione multicast di IP significa associare al flusso un indirizzo compreso in un range particolare (da 224.0.0.0 a 239.255.255.255) 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 luso 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 dellIPTV, assume che tutti flussi multicast erogati dallheadend 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 lutente, cio tecnicamente il STB, richiede di ricevere un canale live, o di rilasciarlo, il protocollo standardizzato in IETF IGMP (Inter net 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 laggancio 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 STB, disconnessione a livello fisico, ).
62
Componenti (descrizione)
Il peso dello stack dei protocolli
Componenti Componenti Unit di (valore) (valore) misura Peso % 2 96 192 100 188 1316 128 256 12 8 20 18 8 54 66 1370 1382 8 5+48 29 29 145 145 199 203 4832 4197 4186 3813 3802 3521 3510 3610 # Kbps Kbps Kbps B B Kbps Kbps B B B B B B B B B B B B B B B B B Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s Kbit/s 78,92 78,69 11,02 11,02 15,12 15,43 4,10 4,41 0,91
Numero canali audio Banda canale audio Componente audio TS Transport Stream (stima) Dimensione pacchetto TS
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 laudio 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 delloverhead dei protocolli, che assorbe oltre il 15 % della banda disponibile sullATM, su reti IP si riduce al 4 %; in un servizio Triple Play, meno dell80% della banda fisica disponibile rimane utilizzabile per i contenuti audio/video; la banda massima configurabile allencoder 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 (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) Banda fisica downstream su tratta ADSL Banda netta disponibile per il payload ATM (senza RTP) Banda netta disponibile per il payload ATM (con RTP) Banda netta disponibile per il TS (senza RTP) Banda netta disponibile per il TS (con RTP) Banda netta disponibile per il video (senza RTP) Banda netta disponibile per il video (con RTP) Banda 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
RTP = Real Time Protocol SNAP = SubNetwork Access Protocol TS = Transport Stream
TABELLA A Valori assoluti e percentuali per un flusso audio/video.
La URL con cui viene fatta la richiesta di aggancio del tipo igmp://multicast_address:port . Come indicato in precedenza, attualmente laudio 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 (dellordine di millisecondi). Come gi per la TV digitale da satellite, nella IPTV tale tempo tende a raggiungere lordine 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);
63
tempi di gestione dei tasti del telecomando da parte del STB (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 daccesso. 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 laccettabilit.
6.2.4 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 nellofferta 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 VBR (Variable Bit 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 GB, che nel caso di contenuti HD arriva ad oltre 12 GB; 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 STB. Dal punto di vista dei protocolli alcune alternative sono possibili: FTP: il protocollo pi tradizionale, ma meno efficiente; FLUTE ( File Deliver y over Unidr ectional Transport - RFC 3926): protocollo multicast; Protocolli in uso nel peer to peer come BitTorrent, 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 allutente. A differenza dei contenuti live lutente fruisce del contenuto prescelto dal suo inizio e non dallistante 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 daccesso 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 linvio 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 STB sul dialetto usato da uno specifico video server. Il STB 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 STB hanno la flessibilit richiesta, si possono verificare incompatibilit fra alcuni modelli di STB ed i video server che fanno parte della piattaforma in uso.
6.2.5 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 STB che per i servizi presenti in aggiunta a quelli audio/video. Per le necessarie attivit di gestione del STB sono usati ad esempio: DHCP per lassegnazione dinamica degli indirizzi IP; DNS per la risoluzione dei nomi; Protocolli per lupload 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 STB, allaccensione o periodicamente, si aggancia per attingere alle informazione indicate sopra. Per la fruizione di altri servizi il protocollo prevalentemente usato HTTP (i STB sono device browser based). Via HTTP vengono scaricate le pagine HTML ed i JavaScript che realizzano linterfaccia utente, residenti sul server di middleware. Informazioni per lidentificazione del STB e dellutente, menu, EPG, meta dati sono scaricati sul STB per questa via.
64
Vi sono piattaforme il cui client pu essere progettato in maniera differente: anzich produrre linterfaccia 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 dellocchio 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 dallutente a valle del passaggio attraverso le risorse che compongono unarchitettura 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 dellimplementazione 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 (nellesempio 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 allheadend, 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 anchessa 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 dellerogazione e della distribuzione, inclusa la rete domestica: pu essere efficacemente verificato vicino al STB, 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 TR101-290; - 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 STB: viene determinato una volta per tutte in fase di test per quanto riguarda la qualit ed in fase di assurance per quanto riguarda laffidabilit. Qualit del televisore: fuori delle possibilit di verifica da parte dellerogatore del servizio IPTV, ma pu essere verificato dallutente 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 laspetto dellaffidabilit di ciascuno degli elementi della catena, che possono provocare perdite parziali di qualit o totali (schermo nero). Pertanto sar necessario tenere sotto controllo anche levenienza che uno degli elementi della catena si guasti. Se si ipotizza che la qualit finale (percepita dallutente) 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 lattivit di verifica della qualit sono sostanzialmente due: STB ed headend. La qualit finale data dal prodotto di quella erogata dallheadend per la qualit del canale erogazione. Sul STB (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 STB ed i contatori di errore pubblicati sulla MIB, per potere essere letti dal sistema di gestione del STB. Per la gestione della QoS da parte dellopera-
65
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, lintroduzione 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. Dallaltro lato, levoluzione 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 allevoluzione delle piattaforme informatiche e dei terminali, in 7. Conclusioni particolare i STB, che dovranno risultare in grado di sfruttare linterattivit permessa dalle reti broadLa strada dellevoluzione dei servizi IPTV a band nellIPTV, con efficacia industriale ma anche e livello mondiale appena iniziata e sta ponendo soprattutto soddisfazione e interesse da parte nuove sfide sul fronte dellingegnerizzazione e degli utenti finali. In questo senso si verificher un dello sviluppo delle infrastrutture di rete a larga confronto tra gli standard proposti in ambito DVB banda sugli aspetti pi informatici relativi alle piatForum e ISMA Forum e piattaforme proprietarie taforme, ai sistemi di streaming e di content on proposte da alcuni colossi quali Microsoft. demand, alla terminalistica e ai temi di protezione Sempre in questottica lIPTV dovr forse trodei contenuti. Sfide che coinvolgono tutti gli attori vare forme di sinergia e integrazione con i servizi di del mondo delle telecomunicazioni, sia gli operatori TV in mobilit, anchessi basati sul protocollo IP. che le manifatturiere che i system integrators. Come lIPTV, la mobile TV permetter interattivit anche a un livello personale oltre che in mobilit. Le bande di trasmissioni coinvolte possono essere ANATOMY OF THE LONG TAIL NETFLIX RHAPSODY AMAZON.COM Online services carry for more inventory than ridotte, grazie alla minore traditional retailers. Rhapsody, for example, offers TOTAL INVENTORY: TOTAL INVENTORY: TOTAL INVENTORY: dimensione dei display dei 19 times as many songs as Wal-Marts stock 735,000 songs 2,3 million books 25,000 DVDs of 39,000 tunes.The appetite for Rhapsodys more cellulari, ma le architetture obscure tunes (charted below in green) makes up the so-called Long Tail. Meanwhile, even as consumers di interattivit presenteranno typical typical typical flock to mainstream books, music, and films (right), molti punti di similitudine e Barnes&Noble Blockbuster Wall-Mart there is real demand for niche fare found only online. store 130000 store store possibile contatto. books 3000 books 3000 songs Collegato allevoluzione 6,100 delle piattaforme sar il THE NEW GROWTH MARKET: cambiamento radicale che OBSCURE PRODUCTS YOU CANT GET ANYWHERE BUT ONLINE si verificher nel modo di TOTAL SALES TOTAL SALES TOTAL SALES fare e utilizzare la pubblicit: per la regionalizzazione dei Songs 2,000 available at contenuti, per linterattivit e 22% 57% 20% both Wal-Mart per la possibilit di personaand lizzazione dei messaggi, che Rhapsody product not available in offline retail stores nel mondo del broadcasting 1,000 Songs non evidentemente possiavailable only on Rhapsody bile mentre nativamente inseribile nel mondo IPTV. 0 Ma forse la pi grande 39,000 100,000 200,000 500 0 novit che lIPTV porter Titles ranked by popularity sar la trasformazione e il passaggio della televisione da un evento del FIGURA 10 Concetto della Long Tail. momento a un evento che rimane nel tempo: proAverage number of plays per month on Rhapsody
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 dellallarme; - generazione di log (in forma tabellare e grafica); - alert/pop up locali sul sistema di monitoraggio; - trap SNMP; - alerting attraverso linoltro di Mail/SMS a specifici destinatari, per il superamento della soglia stabilita per ciascun controllo attivato.
66
gressivamente, si assister alla messa a disposizione on demand di contenuti tv gi trasmessi, anche solo pochi minuti o poche ore prima. Sar possibile rivedere il telegiornale appena trasmesso, oppure andare allindietro nel palinsesto tv per rivedere la puntata del telefilm che si persa il giorno prima. il passaggio dalla linear TV a un mondo nuovo, quello della cosiddetta catch up TV o Time Shifted TV. Questa trasformazione, che dar ai contenuti televisivi la permanenza allinfinito che hanno per esempio i libri o i film, ha le potenzialit per cambiare profondamente il significato stesso di televisione. Lesplosione dei contenuti a disposizione porter a nuovi modelli di valorizzazione degli stessi, che consentiranno di valorizzare anche quei contenuti che oggi non vengono diffusamente commercializzati in quanto rivolti a nicchie di utenti e quindi oggi non profittevoli. La forza nuova sar di poter vendere contenuti non solo di super grido, che chiamano milioni di persone davanti alla TV tutti alla stessa ora a vedere la stessa cosa, ma anche una miriade di contenuti pi specifici e di nicchia che, tutti sommati, costruiranno una volume di componenti con fatturati paragonabili ai contenuti superpremium: non pi contenuti da pochi e uguali per tutti ma tantissimi e diversi per ciascuno: il concetto di Long Tail2 che, applicato in primis al campo dei servizi di musica on line, risulta valido per tutti i tipi di media (figura 10). Questa possibilit di valorizzare i contenuti pi diversi sar probabilmente la caratteristica vincente, anche commercialmente, del mondo della TV su broadband, in una parola, della IPTV.
ABBREVIAZIONI
[1] [2] [3] [4] [5]
BIBLIOGRAFIA
[6]
G. Mazara e altri: DTT, IP TV, DRM, STB, HD TV: panoramica dello stato dellarte (DPC 2004.02333);11/2004 http://erg.abdn.ac.uk/research/future-net/digitalvideo/mpeg2.html http://erg.abdn.ac.uk/research/future-net/digitalvideo/mpeg2-trans.html http://www.ece.utexas.edu/~bevans/courses/ee381k/ projects/fall98/zhou/literatureSurvey.pdf Olivier Verscheure, Pascal Frossard and Maher Hamdi; MPEG-2 Video Services over Packet Networks: Joint Effect of Encoding Rate and Data Loss on UserOriented QoS. Proceedings of NOSSDAV 98, Cambridge, 7/1998, pp. 257-264. C. Anderson: Wired magazine Issue 12.10; 10/2004 http://www.wired.com/wired/archive/12.10/tail.html
2D ADSL AG API ATM AVC BSS BTV CA(S) CBR CPE CPU CRM CWDM D&P DAM DB DCT DRM DSL DSLAM DTT DVB DVD DVI DVR DWDM ECM EMM EPG ES ETSI FLUTE fps FTP GB GbE GOP HD HDD HD-DVD HDMI HDTV HTML IETF IGMP IP IPG IPTV ISO ITU
(2)
"Anatomy of the Long Tail" tratta dalle fonti: Erik Brynjolfsson and Jeffrey Hu, MIT, e Michael Smith, Carnegie Mellon; Barnes & Noble; Netflix; Realnetworks [6].
Two-Dimensional Asymmetric Digital Subscriber Line Access Gateway (sinonimo: RG) Application Programming Interface Asynchronous Transfer Mode Advanced Video Coding Business Support System Broadcast TeleVision Conditional Access (System) Constant Bit Rate Customer Premises Equipment Central Processing Unit Customer Relationship Management Coarse Wavelength Division Multiplexing Download and Play Digital Asset Manager Data Base Discrete Cosine Transform Digital Rights Management Digital Subscriber Line Digital Subscriber Line Access Multiplexer Digital Terrestrial Television Digital Video Brodcasting Digital Versatile Disc Digital Video Interface Digital Video Recorder Dense Wavelength Division Multiplexing Entitlement Control Message Entitlement Management Message Electronic Program Guide Elementary Stream European Telecommunications Standards Institute File Delivery over Unidirectional Transport frames per second (frame/s) File Transfer Protocol GigaByte Gigabit Ethernet Group Of Picture High Definition Hard Disk Drive HD-Digital Versatile Disc High Definition Multimedia Interface High Definition TeleVision Hyper Text Markup Language Internet Engineering Task Force Internet Group Management Protocol Internet Protocol Interactive Program Guide IP TeleVision International Organization for Standardization International Telecommunication Union
67
LPVR MMS MPEG MPTS MS-VC1 NAT NPVR NTSC NVoD OS OSS P2P PAL PC PCR PDA PES PID PIN POP PPV PVC PVR QoS RAM RG RSS RTCP RTP RTSP SD SDTV SMPTE SMS SNMP SP SPTS STB TCP TS UDP UI URL USB VBR VCR VoD VoIP WiFi
Local PVR Multimedia Message Service Moving Picture Experts Group Multiple Program Transport Stream Microsoft Video Codec 1 Network Address Translation Network PVR National Television System Committee Near VoD Operating System Operational Support System Peer to Peer Phase Alternate Line Personal Computer Program Clock Reference Personal Data Assistant Packetised Elementary Stream Packet IDentifier Personal Identification Number Point Of Presence Pay Per View Permanent Virtual Circuit Personal Video Recorder Quality of Service Random-Access Memory Residential Gateway (sinonimo: AG) Really Simple Syndication Real Time Control Protocol Real-Time Protocol Real-Time Streaming Protocol Standard Definition Standard Definition TeleVision Society of Motion Picture and Television Engineers Short Message Service Simple Network Management Protocol Service Provider Single Program Transport Stream Set-Top Box Transmission Control Protocol Transport Stream User Datagram Protocol User Interface Uniform Resource Locator Universal Serial Bus Variable Bit Rate VideoCassette Recorder Video on Demand Voice over IP Wireless Fidelity
Mauro Borghi si laureato con lode in Ingegneria Elettronica presso lUniversit di Parma nel 1998. Dal 2000 lavora in Telecom Italia Lab, dove si occupato di servizi Internet e multimedia. Limpegno si poi concentrato su argomenti legati alla televisione digitale, in particolare focalizzandosi sulle architetture software dei set-top box per IPTV e sulla televisione ad alta definizione. Dal 1995 utilizza e sviluppa su sistemi GNU/Linux, promuovendo le tecnologie e le idee del software open source.
Gabriele Elia si laureato in Ingegneria Elettronica al Politecnico di Torino, dove nel 1994 ha ricevuto il Dottorato in Ingegneria Informatica e dei Sistemi. Ha iniziato la sua a t t i v i t p r e s s o l o C S E LT ( o g g i T I L A B ) occupandosi dello sviluppo e innovazione di servizi sulle reti IP, prima narrowband (Tin.it) e poi a larga banda (ADSL). Si occupato di accesso alle reti IP, applicazioni Web, servizi di messaggistica e messaggistica unificata, servizi di directory, sistemi di search e information retrieval, ambienti per comunit virtuali. Dal 2004 responsabile, sempre presso il centro R&D, dellArea di Ricerca sui servizi basati sui contenuti e dei temi collegati, quali le piattaforme interattive ed i sistemi per la protezione dei contenuti; in particolare lattivit riguarda i servizi interattivi sulla TV digitale terrestre, la mobile TV, la televisione su IP, i servizi di musica online.
Dario Ercole si laureato in Ingegneria Elettronica al Politecnico di Torino nel 1985. Nello stesso anno entrato in TILab (gi C S E LT ) o c c u p a n d o s i d i a r c h i t e t t u r e a m i c r o p r o c e s s o r e , r e t i AT M e r e t i I P, d i erogazione di servizi multimediali su Internet a larga banda, di architetture di Centri Servizi Internet. Attualmente opera nellarea Content to Person Services" e dal 2003 segue il Progetto IPTV, per lofferta di servizi a larga banda fruibili su TV ed erogati su canale ADSL.
Claudio Franco si laureato con lode in Ingegneria Elettronica presso il Politecnico di Torino nel 1972. Nel 1973 entrato in CSELT (oggi TILab); attualmente opera in Telecom Italia Innovation & Engineering Services. Nei numerosi anni si occupato di reti a pacchetto, sviluppo e testing sulla pila di protocolli OSI, network management, applicazioni multimediali ed accesso a larga banda. Da alcuni anni collabora nei progetti collegati al tema IPTV.
Enzo Gassino in CSELT (oggi TILAB) dal 1974, si occupato di progetto e sviluppo di sistemi software per telecomunicazioni maturando esperienze in metodologie e ambienti di sviluppo, problematiche di affidabilit e tolleranza ai guasti, architetture distribuite, ambienti grafici e multimediali. Negli ultimi anni ha partecipato a diversi progetti riguardanti levoluzione degli OSS e BSS di Wireline, seguendo in particolare la definizione degli aspetti architetturali e di integrazione. Attualmente opera nellarea Content to Person Services dove si occupa di piattaforme di middleware per servizi IPTV.
68

Ip TV Adsl

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ip TV Adsl

Uploaded by

Copyright:

Available Formats

PIATTAFORME

IPTV, la televisione arriva con lADSL

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

2. Introduzione ai servizi dellecosistema IPTV

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

2.1 La protezione dei contenuti

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

GigaBit Switches TV Management Platform VOD Servers

DSLAM Backbone IP STB with Smartcard

Switch Gigabit Ethernet Scrambling

Content Protection System DSLAM IRD STB VOD = = = =

Conditional Access System

3.1 Headend , contenuti BTV

FIGURA 1 Esempio di architettura del servizio IPTV.

2.2 Larchitettura del servizio

DSLAM IP STB with Smartcard

Distribuzione contenuti Multicast Fruizione contenuti Multicast

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

3.3 Il ruolo centrale del middleware per IPTV

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

3.3.2 EPG (Electronic Program Guide) Manager

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

4.1 La rete di trasporto e metropolitana

4.2 La rete di accesso e il CPE (Customer Premises Equipment)

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

VOD Server Metro MAN GbE

Feeder GbE CWDM/DWDM metro ring

STB CPE ADSL PC

Content Provider VOD Server Metro = = = = = =

ADSL CAS CPE DSLAM EPG GBE

FIGURA 5 Esempio di architettura di rete.

5.1 Caratteristiche hardware

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

5.2 Caratteristiche software

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

5.3 Set-top box: uno sguardo al futuro

6.1 Codifiche Video: da MPEG-2 a MPEG-4

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

FIGURA 6 Richieste di banda per i diversi sistemi televisivi.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

PSNR (dB relative)

6.1.2 MPEG-4 AVC

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

6.2 I protocolli per streaming e controllo

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

La struttura del Transport Stream

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

Il peso dello stack dei protocolli

TABELLA A Valori assoluti e percentuali per un flusso audio/video.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

6.3 Qualit del servizio

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

[1] [2] [3] [4] [5]

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

You might also like