INDICE

1. Introduzione

2. Introduzione alla tecnologia DVB-T

   1. Segnali digitali nella DVB-T

   2. I decoder MHP e le funzioni di interattività

   3. Digital Video Broadcasting Project

   4. Lo standard MHP

3. Aspetti tecnici di trasmissione digitale

   1. Trasmissione digitale e transport stream

   2. Il protocollo DSM-CC

4. Le applicazioni sviluppate per MHP: le Xlet

   1. L’ambiente Java delle Xlet

   2. Interfaccia grafica delle Xlet

5. Prototipo applicativo: XletUOL

   
   

6. Conclusioni

   
   

In questi ultimi anni si sta verificando una vera e propria rivoluzione nel settore delle trasmissioni televisive.

In effetti, il sistema televisivo attuale utilizza, per la maggior parte, la tecnologia analogica per la trattazione dei segnali trasmessi.

E’ evidente, soprattutto analizzando altre realtà del mondo elettronico, che la tecnologia digitale sta prendendo il sopravvento su quella analogica; esempi di questo fatto si possono confermare considerando la diffusione di CD, DVD, modem digitali e macchine fotografiche digitali al posto delle obsolete musicassette, videocassette e modem analogici.

Tale progresso tecnologico, dovuto alla tecnologia digitale, ha portato ad un miglioramento nella qualità offerta all’utente, grazie soprattutto alla compressione dei segnali ed alla notevole riduzione del rumore presente.
Sotto questa ottica, il sistema televisivo non può restare indietro.

Ormai sono alcuni anni che, grazie ai nuovi standard emanati, anche la televisione può entrare a far parte del mondo digitale. Ente supervisore di questa nuova tecnologia è il DVB (Digital Video Broadcasting), che predispone e supervisiona le specifiche per l’introduzione del digitale nella televisione. Attualmente sono state sviluppate tre classi di specifiche, che si differenziano per il mezzo trasmissivo.

Il primo tipo di tecnologia studiata è stata quella satellitare, che oggi è anche la più diffusa in ambito mondiale.

In seguito è nata la tecnologia che sfrutta cavi ad alta velocità di trasmissione, ma, soprattutto in Italia, tale tecnologia non ha avuto una diffusione su larga scala.

E’ per questo motivo che è in corso di introduzione la nuova tecnologia digitale terrestre.

Attualmente, solamente pochi Stati al mondo stanno adottando quest’ultimo tipo di tecnologia; per questo motivo, il caso italiano è considerato di particolare interesse dalle altre nazioni, ed frequentemente è caso di studio all’estero.

Il motivo per cui l’Italia ha deciso di sperimentare questa nuova tecnologia è l’alta diffusione della tecnologia analogica, a fronte di una ancora scarsa introduzione di quella digitale, soprattutto di tipo satellitare. Con la televisione digitale terrestre, infatti, il sistema di ricezione è uguale a quello analogico, utilizzando l’antenna tradizionale

In questo contesto, si è sentita la necessità di approfondire la questione, studiando le specifiche tecniche che realizzano questa nuova tecnologia.

Il lavoro di questa tesi è stato sviluppato in due parti distinte:

• una parte teorica, in cui sono state ricercate ed analizzate le specifiche e gli standard che costituiscono la DVB-T;

• una parte pratica, dove viene sviluppata un’applicazione per il digitale terrestre, in grado di far interagire l’utente con i programmi televisivi.

Queste due parti sono state sviluppate durante lo svolgimento di due tirocini universitari. La prima parte, che riguarda una attività di ricerca, è stata elaborata presso Sytel Reply S.p.A. di Milano, azienda che si occupa della gestione di metadati per le emittenti televisive.

La parte applicativa, invece, è stata sviluppata presso Bassnet S.p.A. a Firenze, ente che si occupa di ricerca ed innovazione in ambito informatico.

Gli obiettivi preposti erano quelli di una conoscenza approfondita delle specifiche tecniche a fondamento della televisione digitale terrestre; quindi si è pensato di sviluppare un elaborato per testare le reali funzionalità dell’aspetto interattivo della DVB-T.

La trattazione della tesi corrisponde allo svolgimento delle attività.

Nel primo capitolo viene introdotta la tecnologia DVB-T.

Nella prima sezione si analizzano i segnali e la tecnologia digitale che costituiscono la DVB-T, enunciando i benefici che vengono apportati.

Nella seconda sezione viene trattato l’aspetto di interattività che viene fornito all’utente, insieme ad una breve analisi sul componente necessario per decodificare i segnali digitali: il Set Top Box.

La terza e quarta sezione mostrano due argomenti correlati: la prima parte effettua una panoramica sull’ente che emana e supervisiona le specifiche relative al DVB-T; la seconda parte considera invece lo standard MHP, e si occupa della parte interattiva associata al digitale terrestre.

Il secondo capitolo analizza più in dettaglio la tecnologia trasmissiva che permette la diffusione dei segnali digitali.

Viene suddiviso in due parti.

La prima si occupa principalmente della creazione del transport stream, ovvero il flusso di segnali che viene diffuso dai trasmettitori.

La seconda sezione tratta più in dettaglio del protocollo di trasporto DSM-CC, responsabile della trasmissione delle applicazioni MHP.

Il terzo capitolo introduce l’aspetto applicativo del digitale terrestre: le Xlet.

Una prima parte si occupa del sistema sottostante a queste applicazioni, ovvero l’ambiente Java e le specifiche API JavaTV, e studiandone il loro ciclo di vita.

La seconda parte tratta brevemente le funzionalità grafiche che tali applicazioni forniscono.

L’ultimo capitolo tratta dell’elaborato sviluppato, introducendone le funzionalità, mostrando il ciclo di vita e, infine, commentando le parti più importanti del codice.

Capitolo 2: Introduzione alla tecnologia DVB –

2.1 – Segnali digitali nella DVB – T

Fino ad oggi, il sistema televisivo predominante ha utilizzato segnali analogici per la trasmissione dei programmi televisivi.

La televisione digitale terrestre, denominata tecnicamente DTT (Digital Terrestrial Television) o DVB-T (Digital Video Broadcasting – Terrestrial), utilizza segnali digitali al posto di quelli analogici per la modulazione dei canali televisivi, con la capacità aggiuntiva di rendere disponibili alcune funzioni interattive agli utenti.

L’attuale sistema di ricetrasmissione televisiva via etere prevede l’utilizzo dei segnali analogici: la trasmissione avviene in radio frequenza mediante onde elettromagnetiche. La portante radio che definisce la banda di trasmissione (il canale) viene modulata in forma continua in ampiezza ed in frequenza per trasmettere immagini in movimento e suoni.

IL DVB-T utilizza invece segnali digitali: essi risultano dal campionamento del segnale analogico ad intervalli fissi di tempo e successiva quantizzazione, ottenendo sequenze di numeri binari (sequenze di bit 1 e 0), che possono essere opportunamente ridotte di dimensioni grazie ad algoritmi di compressione (Mpeg).

Il processo di conversione da analogico a digitale è il seguente:

Campionamento -> Quantizzazione -> Codifica/Compressione

Il mezzo di trasmissione è del tutto analogo a quello della televisione analogica: etere e radio frequenza.

Gli impianti di radioricezione della DTT sono identici a quelli utilizzati per la ricezione analogica, come identiche sono le bande di frequenza utilizzate: 48 in banda UHF e 7 in banda III (VHF).

Le attuali antenne e la rete di distribuzione all’interno degli edifici, con gli opportuni dispositivi intermedi (derivatori, amplificatori, multiplexer/demultiplexer), sono già adatte alla ricezione digitale; in qualche caso, tuttavia, potrebbe essere necessario il montaggio di un modulo supplementare, se non si dispone di un’antenna nelle banda su cui è irradiato il segnale, o una revisione e ottimizzazione del sistema di ricezione esistente, data la necessità del segnale digitale di essere ricevuto con una potenza ed una pulizia adeguata per essere visualizzato correttamente. In generale è previsto che le nuove reti digitali si avvalgano degli stessi siti di trasmissione della TV analogica; quindi, in teoria, non è necessario cambiare il puntamento della propria antenna.

Ovviamente non deve essere installata alcuna parabola, necessaria invece per la TV satellitare: per la DVB-T è sufficiente l’antenna tradizionale con cui si ricevono le attuali emittenti analogiche nazionali e locali.

La DTT quindi si avvale di tecniche digitali per la modulazione dei segnali informativi, come del resto avviene con i computer, CD e DVD, macchine fotografiche digitali e telefoni cellulari.

I principali benefici che la tecnologia digitale introduce sono i seguenti:

• un numero molto maggiore di programmi disponibili;

• una migliore qualità delle immagini e dell’audio;

• la possibilità di usufruire di servizi interattivi resi disponibili dalle emittenti o da altri fornitori, compresa la pubblica amministrazione.

Il numero dei programmi che è possibile trasmettere in digitale è notevolmente maggiore: sulla stessa banda di frequenza in cui viene trasmesso un solo canale analogico, in digitale se ne possono trasportare da 5 a 7, grazie all’evoluzione delle tecniche di compressione utilizzate ed in base alla qualità dei programmi prefissata dalle emittenti. Vengono così estesi i limiti dell’attuale sistema televisivo, che non consente l’introduzione di ulteriori programmi.

Utilizzando segnali digitali, come nel caso dei CD, dei DVD o della telefonia mobile, la qualità delle immagini e dell’audio risulta migliore, poiché tali segnali non sono soggetti ai disturbi e alle interferenze tipiche dei segnali analogici.

Una seconda distinzione da fare riguarda le modalità con cui i segnali vengono propagati sino all’utente finale; infatti la DTT non è l’unica tecnologia che sfrutta segnali digitali per la ricetrasmissione dei programmi televisivi.

DVB-T si inserisce in un contesto più ampio, il Digital Video Broadcasting (DVB), che rappresenta un consorzio di organizzazioni operanti nel settore televisivo, quali broadcaster, operatori di rete e sviluppatori software, riuniti con lo scopo di studiare e produrre standard per la diffusione dei segnali televisivi.

Per quanto riguarda la trasmissione dei programmi televisivi mediante segnali digitali, tale consorzio ha sviluppato tre classi di standard diverse, che si differenziano soprattutto per il mezzo attraverso il quale passa il contenuto informativo.

• DVB-S è lo standard che riguarda la trasmissione dei segnali digitali attraverso l’uso di satelliti e di parabole per la ricezione.

• DVB-C permette la ricezione dei segnali digitali utilizzando cavi ad alta velocità di trasmissione.

• Infine, DVB-T si occupa della trasmissione dei segnali digitali via etere, sfruttando il sistema di radiodiffusione analogico preesistente.

D’ora in poi verranno trattate le tecnologie che permettono l’implementazione di servizi interattivi (MHP) nella distribuzione del segnale digitale per via terrestre (DVB-T).

2.2 – I decoder MHP e le funzioni di interattività

Per ricevere i segnali digitali forniti dalla DTT è necessario possedere un decoder, denominato Set Top Box (STB), da collegare alla presa d’antenna ed al televisore tramite una presa SCART (la presa analoga usata per collegare, ad esempio, un videoregistratore, un lettore DVD oppure un decoder satellitare).

Tramite il Set Top Box è possibile decodificare i segnali digitali ed utilizzare le applicazioni interattive associate ai programmi e ai canali televisivi.

Questi ricevitori decodificano una frequenza per volta, perciò non è possibile vedere programmi differenti su due televisori con un solo Set Top Box: per vedere canali differenti, è necessario un decoder per ogni televisore.

I ricevitori DVB-T sono dispositivi molto complessi, composti da una circuteria analogica dedicata alla demodulazione del segnale ricevuto, e da una parte digitale assimilabile ad un calcolatore elettronico.

Dal segnale ricevuto e demodulato si ottiene uno stream binario che viene elaborato dalla circuteria digitale. L’elaborazione del segnale digitale viene effettuata mediante un microprocessore ed il software ad esso associato.

Qualsiasi funzionalità implementata dal ricevitore è controllata via software, che è strutturato in due parti: la prima parte costituisce un vero e proprio sistema operativo che amministra le risorse hardware, mentre la seconda parte si occupa dell’implementazione delle varie funzionalità.

Il software di gestione dei ricevitori può essere aggiornato da remoto permettendo il miglioramento delle funzioni già predisposte e la realizzazione di funzioni non previste all’atto dell’immissione sul mercato.

La definizione di Application Programming Interface (API) mette a disposizione dei programmatori che devono aggiornare il software del ricevitore una ampia gamma di librerie e routine che consentono una semplice riscrittura delle nuove applicazioni senza dover necessariamente conoscere in dettaglio le specifiche del sistema DVB-T.

I Set Top Box esistenti sono di due tipi:

• STB non interattivi (detti zapper), in grado di ricevere solo i programmi televisivi digitali;

• STB interattivi che, oltre a ricevere i programmi televisivi, sono in grado di usufruire dei nuovi servizi interattivi disponibili; questo modello viene caratterizzato con la sigla MHP.

L’interattività permette all’utente di interagire tramite il telecomando con la programmazione TV e con i servizi commerciali e di pubblica utilità disponibili. Si può considerare un esempio di servizio di pubblica utilità l’attuale televideo, che viene richiamato con il telecomando mentre si sta vedendo un programma TV; con la tecnologia digitale, tali servizi possono essere resi visibili contemporaneamente ai programmi, mediante suddivisione dello schermo, ed essere molto più funzionali ed attraenti.

Il STB interattivo è un decoder munito di una uscita verso la rete telefonica mediante un modem tradizionale (V.90 o ISDN), oppure mediante un modem a banda larga (ASDL).

Il collegamento del STB verso la rete di telecomunicazioni è denominato canale di interazione o canale di ritorno.

Le funzioni di interattività, infatti, possono comportare un dialogo tra il decoder ed un centro servizi, ente preposto alla fornitura dei servizi richiesti.

La connessione telefonica, perciò, è un elemento fondamentale della DTT per usufruire a pieno dei servizi interattivi; ad esempio sarà possibile partecipare attivamente ai programmi televisivi, esprimendo preferenze o selezionando prodotti, tramite semplici operazioni sul telecomando anziché effettuando telefonate o inviando SMS.

Alcuni servizi che i cittadini possono usufruire tramite la televisione possono essere: informazioni sul traffico, prenotazioni sanitarie, lezioni universitarie e indicazioni per i turisti.

Tipici fornitori di servizio saranno le pubbliche amministrazioni centrali o locali, che renderanno disponibili sul digitale terrestre servizi accessibili attualmente solo da internet.

Il costo dei servizi interattivi dipenderà dal fornitore di tali servizi. Inoltre, nel caso in cui un servizio richieda l’uso del canale di ritorno, il costo dipenderà anche dal fornitore della rete di telecomunicazioni.

2.3 – Digital Video Broadcasting Project

Il Digital Video Broadcasting Project (DVB) è un consorzio di organizzazioni, sia pubbliche che private, operanti nel settore televisivo. Comprende oltre 260 imprese tra broadcaster, produttori hardware, operatori di rete, sviluppatori software ed enti regolatori sparsi in 35 Stati diversi impegnati nella progettazione di standard globali per la trasmissione della televisione digitale ed i suoi servizi correlati.

Durante il 1991, i produttori di apparecchiature televisive ed i broadcaster si confrontarono per realizzare una piattaforma europea con l’obiettivo di sviluppare un sistema televisivo digitale, perciò si ritrovarono a discutere della nascita di un gruppo di lavoro, che avrebbe controllato lo sviluppo della televisione digitale in Europa. Questo gruppo si chiamava ELG, European Launching Group, che si ingrandì fino ad includere i principali gruppi di interesse sui media europei, sia pubblici che privati. Nel settembre del 1993 ELG cambiò il proprio nome in Digital Video Broadcasting Project (DVB), con lo scopo di incrementare lo sviluppo della televisione digitale, già presente in Europa.

Il DVB Project rese disponibile un forum per racchiudere in un gruppo gli interessi di tutte le principali emittenti televisive europee, con la promessa di sviluppare un sistema televisivo digitale completo basato su un approccio unico.

Divenne subito chiaro che sarebbero stati i sistemi satellitari e via cavo a trasmettere i primi servizi di televisione digitale. Pochi problemi tecnici ed un piano regolatore più semplice permise un loro sviluppo più rapido rispetto al sistema terrestre. Le priorità di mercato permisero al digitale satellitare e al sistema di diffusione via cavo di svilupparsi rapidamente; la tecnologia terrestre sarebbe stata sviluppata più tardi.

Entro il 1997 il DVB Project ha portato a termine con successo i piani iniziali, così il progetto è entrato nella fase successiva, promuovendo i suoi standard aperti in tutto il mondo, e facendo della televisione digitale una realtà.

Il DVB Project è organizzato in quattro moduli principali, governati dall’Assemblea Generale e dal suo Steering Board.

La General Assembly è l’entità a capo del DVB Project.

Lo Steering Board viene eletto dall’Assemblea Generale; definisce l’orientamento delle politiche generali e detiene la loro coordinazione e gestione. Lo Steering Board approva le specifiche DVB e le offre alle organizzazioni internazionali per la standardizzazione.

Ogni modulo si occupa di una parte specifica del lavoro da effettuare. I moduli Commercial Module e Technical Module sono le entità fondamentali nello sviluppo delle specifiche DVB; l’Intellectual Property Rights Module si occupa delle problematiche di IPR mentre il Promotion and Communications Module si occupa della promozione del DVB in tutto il mondo.

Infine vengono creati gruppi di lavoro ad hoc per sviluppare realmente le specifiche del DVB. Nascono inizialmente dai vari moduli per poi focalizzarsi in argomenti specifici, considerando obiettivi ben definiti.

Il DVB Project sviluppa le specifiche per i sistemi televisivi digitali, che vengono convertiti in standard da enti internazionali di standardizzazione come ETSI o CENELEC, attraverso la collaborazione dei membri nei numerosi gruppi di lavoro. Una volta che le specifiche vengono tradotte in standard, vengono promosse per l’adozione e l’utilizzazione in tutto il mondo.

Ogni standard DVB viene proposto dal Commercial Module che, basandosi sui bisogni di mercato, predispone una serie di requisiti che descrivono diversi parametri, come i servizi da fornire all’utente ed il prezzo da apportare.

Una volta che il Commercial Module ha definito i propri obiettivi, i requisiti vengono inoltrati al Technical Module.

In pratica le specifiche DVB vengono sviluppate dal Technical Module e dai suoi gruppi di lavoro; qui vengono definite le specifiche tecnologiche per soddisfare i requisiti degli utenti e vengono esaminate le tecnologie disponibili.

Una volta che il Technical Module ha ricevuto il consenso delle specifiche prodotte dal Commercial Module, vengono inoltrate allo Steering Board, che ne dà l’approvazione finale.

Infine esse vengono passate agli enti di standardizzazione internazionali per definire gli standard.

Gli standard del DVB si basano principalmente sul sistema di compressione MPEG-2 per la codifica sorgente audio e video.

Il sistema di codifica audio si attiene allo standard MPEG layer II (MUSICAM) usato nel digital audio broadcasting.

Lo standard MPEG-2 del sistema di codifica video accetta in ingresso quattro livelli da codificare: low level, main level, high 1440 level e high level, che si differenziano per la qualità offerta. Ognuno è caratterizzato da un certo bit rate di sorgente.

Come risultato della codifica, lo standard MPEG-2 offre differenti profili; ciascun profilo è caratterizzato da un set di strumenti di compressione.

I profili sono 5: simple profile, main profile, SNR scalable profile, spatially scalable profile e high profile. Ognuno di essi è progressivamente più sofisticato, e aggiunge strumenti di compressione al precedente.

Non tutte le combinazioni di livelli e profili sono approvati dallo standard: solo undici delle venti combinazioni sono accettate.

La codifica di sorgente MPEG-2 utilizzata da DVB è caratterizzata dall’uso della combinazione Main profile e main level: mainprofile@mainlevel.

Dopo la codifica di sorgente, i canali da trasmettere vengono accorpati in un unico stream mediante una operazione di multiplexing.

Grazie a queste tecniche di compressione è possibile mettere molta più informazione sfruttando la stessa capacità di canale di quella analogica. Ma l’uso di MPEG-2 da solo non può rendere i servizi interoperabili: la modulazione, il multiplexing, i servizi e l’accesso condizionato devono essere ridefiniti.

Uno degli aspetti fondamentali del DVB Project è l’impegno a rendere i diritti di proprietà intellettuale disponibili in modo imparziale e non discriminatorio. Le politiche di IPR del DVB sono orientate a proteggere gli interessi delle licenze, con lo scopo di sviluppare prodotti e servizi da rendere disponibili sul mercato.

Le specifiche più importanti del DVB sono quelle relative alla trasmissione dei segnali digitali: DVB-S per il satellite, DVB-C per il cavo e DVB-T per la trasmissione terrestre; sono diffuse in tutto il mondo e formano le basi per la maggior parte di altri standard alternativi.

Il primo standard di trasmissione approvato è stato DVB-S per la trasmissione satellitare: emesso nel 1994, basato sulla codifica QPSK e considerato adesso lo standard de facto per le applicazioni televisive digitali nelle trasmissioni satellitari mondiali.

DVB-C, il meccanismo di trasmissione via cavo, assomiglia molto a DVB-S, ed è basato sulla codifica 64-QAM, sebbene supporti degli schemi di modulazione migliori.

Sono seguite le specifiche per definire servizi di informazione, un sistema di contesa comune e un codice di comportamento per l’accesso condizionato. Il gruppo previde che l’uso dei servizi interattivi sarebbe incrementato negli anni, così la predisposizione verso tali servizi ha influenzato le specifiche seguenti.

DVB-T è il sistema di trasmissione DVB più giovane dei tre, nonché il più sofisticato. E’ basato sulle modulazioni COFDM (Coded Orthogonal Frequency Divisional Multiplexing), QPSK, 16 QAM e 64 QAM. DVB-T permette ai fornitori di servizi di essere compatibili, nonché di migliorare la copertura della trasmissione analogica utilizzando una frazione della potenza trasmessa; inoltre estende la portabilità della televisione digitale terrestre nel campo dei dispositivi mobili, impossibile in precedenza, o in altri sistemi digitali. Per la trasmissione dei segnali DVB-T è stato adottato l’approccio di rete ad una singola frequenza (SFN). La specifica DVB-T è stata accordata nel dicembre del 1995 ed ultimata dall’approvazione ETSI nell’aprile del 1996.

Il DVB Project si è espanso in nuove aree da quando è incominciata l’attività del Multimedia Home Platform Launching Group. Il primo risultato ottenuto è stato il rilascio della prima specifica DVB-MHP nel giugno del 2000. Nel maggio del 2001 è stata adottata dal DVB una nuova strategia tecnica ed economica, con lo scopo di costruire un ambiente di contenuti che combinasse la stabilità e l’interoperabilità del mondo della trasmissione televisiva, con il vigore, l’innovazione e l’offerta di servizi del mondo di internet.

2.4 – Lo standard MHP

Il Multimedia Home Platform è uno standard progettato dal DVB Project. Dopo anni di deliberazioni, DVB ha prodotto un insieme di specifiche che definiscono una piattaforma middleware. Partendo dal middleware, si è pensato di promuovere l’interoperabilità tra le applicazioni MHP ed i terminali, e tra i terminali stessi. Il risultato ottenuto è il pacchetto MHP, un insieme di misure centrate attorno alle specifiche MHP, basate su Java, ed un insieme di accordi stipulati per assicurare l’interoperabilità dei dispositivi presenti sul mercato.

Nella sua concezione più semplice, MHP è un insieme di API Java che permettono la scrittura di applicazioni interoperabili. Queste vengono trasmesse come parte dello stream MPEG-2 che costituisce un segnale digitale televisivo, ed un ricevitore conforme a MHP può eseguire queste applicazioni sullo schermo.

MHP definisce l’interfaccia tra le applicazioni interattive ed i terminali sui quali le applicazioni vengono eseguite; questa interfaccia separa le applicazioni dei diversi fornitori di servizi dagli specifici dettagli software e hardware dei terminali.

MHP estende gli standard definiti da DVB che riguardano le trasmissioni televisive utilizzando segnali digitali, includendo i servizi interattivi, perciò le applicazioni DVB-MHP sono destinate alla tv digitale in tutte le sue versioni: satellitare, terrestre o via cavo, effettuando pochissimi cambiamenti all'hardware ed al software sottostante. MHP rappresenta un’apertura alla multimedialità attraverso il mezzo televisivo, poiché usa codici comuni a tantissime applicazioni.

DVB-MHP risiede in cima al sistema operativo di un STB, e rappresenta il traduttore locale che permette al Set Top Box di capire quali applicazioni e servizi devono essere attivati.

Durante la creazione di MHP, il DVB Project ha scelto di utilizzare Java per lo sviluppo del core del middleware. La sua realizzazionepermette ai produttori di contenuti di elaborare le proprie applicazioni indipendentemente dal sistema sottostante, sia esso presente nella versione di decoder satellitare, terrestre o via cavo.

Alcuni elementi di MHP vengono forniti da altre organizzazioni: per esempio, le applicazioni Java si basano sulle API JavaTV, mentre vengono utilizzate le API HAVI per realizzare l’interfaccia grafica.

L’architettura di MHP è definita su tre livelli:

• Resources: MPEG processing, dispositivi I/O, CPU, memoria e sistema grafico.

• System Software: usa le risorse con lo scopo di fornire una visione astratta della piattaforma alle applicazioni.

• Applications: le implementazioni di MHP includono un application manager per controllare le applicazioni che vengono eseguite.

MHP si basa sulla piattaforma DVB-J, che include una macchina virtuale definita nella Java Virtual Machine di Sun Microsystem. I pacchetti software forniscono l’application program interface (API), tra cui le JavaTV di Sun formano la parte principale.

Le applicazioni accedono alla piattaforma tramite queste API; infatti l’implementazione del middleware MHP richiede la mappatura tra queste API e le risorse sottostanti.

MHP permette l’implementazione di diverse applicazioni interattive. Alcuni esempi possono essere: EPG (Electronic Programme Guide), servizi informativi come il ‘super teletext’, applicazioni legate al contenuto televisivo, e-commerce, e-government, internet, servizi meteo, di traffico e di pubblica utilità, giochi stand-alone, pubblicità interattive.

Nello standard MHP tali applicazioni vengono chiamate Xlet e possono essere composte solo da tipologie precise di dati: classi java, file xml o txt, immagini png, jpg o gif, audio mp2 e video mpg. Le Xlet per essere trasmesse necessitano di un preventivo impacchettamento in moduli di dimensione massima di 64Kbyte. La sequenza di moduli che compone un’applicazione di solito viene associata ad un particolare canale tv. Tale associazione avviene nel Multiplexer, dove è possibile creare un’associazione per ogni Xlet trasmessa.

A questo punto il flusso in uscita dal Multiplexer (il Transport Stream) viene modulato in una delle 3 tipologie possibili definite dal Digital Video Broadcasting: terrestre(DVB-T), satellitare (DVB-S) e cavo(DVB-C).

Dopo la modulazione il segnale viene trasmesso e quindi ricevuto dai terminali.

Il middleware del ricevitore contiene un componente, l’application manager, che è responsabile del monitoring dei servizi e della gestione delle applicazioni; segnala all'utente la lista delle applicazioni MHP disponibili sul canale televisivo.

Prima che l’application manager possa eseguire un’applicazione MHP, devono accadere alcune cose: la prima è che il ricevitore deve sapere se esiste un’applicazione MHP; in seguito deve sapere se un utente ha il permesso di eseguirla in un dato momento; infine il decoder deve essere capace di accedere alle risorse necessarie per eseguire l’applicazione, come i file class ed i file data e asset.

Quando l'utente effettua una selezione dalla lista delle applicazioni disponibili, l’application manager inizia la fase di download in memoria dei moduli relativi all'applicazione scelta. Non tutti i moduli che compongono l'applicazione vengono scaricati: il download avviene solo per quelli necessari alla partenza della Xlet. Successivamente, e solo se realmente necessari, verranno scaricati anche quelli rimanenti. Questo meccanismo somiglia al modello di caricamento delle pagine del televideo ed è pensato per ridurre i tempi di attesa del telespettatore.

I soggetti attivi nella trasmissione dei segnali digitali e delle applicazioni MHP sono i seguenti:

• Content Producer, che elabora le applicazioni MHP, come giochi, EPG o servizi informativi.

• Broadcaster, che si occupano della diffusione dei canali televisivi e della aggregazione delle applicazioni interattive.

• Operatori di rete MHP. In alcuni casi, come nella trasmissione satellitare, l’operatore di rete non coincide con il broadcaster, perciò le applicazioni MHP vengono aggregate da un operatore di rete prima della trasmissione.

• Venditore dei terminali MHP: l’elemento più importante della catena MHP è il set top box, sul quale le applicazioni MHP vengono eseguite.

All'interno dello standard vengono definiti 3 profili, per evidenziare i servizi che possono essere forniti in base alle tecnologie disponibili.

Tale Profilo si riferisce ad un’area applicativa e, di conseguenza, alle capacità dei STB; quindi esiste un forte legame tra i profili e le release dello standard.

Sebbene ci siano tre profili, le specifiche MHP rilasciate sono solamente due; il motivo è che le funzionalità dei primi due profili sono all’incirca le stesse, perciò sono stati incorporati in una sola specifica.

I tre profili su cui si basa MHP sono:

• Enhanced Broadcast, definito nella specifica MHP 1.0 (ES 201 812);

• Interactive TV, definito nella specifica MHP 1.0 (ES 201 812);

• Internet Access, definito nella specifica MHP 1.1 (TS 102 812);

Oltre alla definizione dei profili, gli standard MHP si occupano di altre questioni, come la piattaforma DVB-J (Java), i meccanismi MHP di sicurezza, i protocolli di download delle applicazioni.

Il profilo Enhanced Broadcast è il profilo base ed è stato progettato per mostrare le funzionalità del sistema middleware esistente e le applicazioni possibili da eseguire.

Come suggerisce il nome, questo profilo è adatto per Set Top Box con nessuna o poca capacità del canale di ritorno e rappresenta il più semplice dei tre profili in termini di prestazioni.

Permette solamente l'arricchimento del contenuto audio-video con informazioni e immagini visualizzabili e navigabili sullo schermo tv. Per questo profilo non sono richieste performance particolari dei set-top box.

Comprende la Java virtual machine, le API Java DVB, i protocolli di trasporto broadcast e le opzioni HTML.

Il profilo Interactive TV è il profilo intermedio che permette di utilizzare il canale di ritorno per fornire servizi multimediali interattivi più complessi rispetto al profilo base; contiene estensioni di API Java più appropriate per l’interattività ed il supporto al canale di ritorno, nonché protocolli di trasporto migliori.

Infine il profilo Internet Access considera STB ancora più sofisticati, con un potere di elaborazione ed una memoria maggiori. Permette, tramite il canale di ritorno, di accedere ai contenuti di Internet. Questo profilo necessita di performance di alto livello essendo obbligatoria l'adozione di un browser internet e di un client di e-mail embedded nel set-top box. Contiene le API Java per l’accesso ad internet, nonché un elemento HTML opzionale chiamato DVB-HTML.

Lo standard di base è costituito dalla specifica MHP 1.0 (ES 201 812).

La specifica 1.0.X contiene:

• l’architettura base di MHP;

• informazioni dettagliate sui profili “Enhanced Broadcasting” ed “Interactive TV”;

• diversi formati contenuti in MHP, che includono JPEG, MPEG-2 video e audio;

• protocolli di trasporto, che includono DSM-CC per la trasmissione broadcast e IP per il canale di ritorno;

• modelli di applicazione DVB-J;

• modelli di applicazione DVB-HTML;

• allegati al profilo DSM-CC, una presentazione testuale e varie API;

MHP 1.0.X specifica l’ambiente dove si possono eseguire le applicazioni per la tv interattiva digitale, indipendentemente dall’hardware e dal software sottostante, che sono specifici del produttore di STB.

La specifica MHP 1.0 fornisce un insieme di caratteristiche e funzioni richieste dai profili ‘enhanced broadcasting’ ed ‘interactive broadcasting’.

In seguito è stata emanata la specifica MHP 1.1 (TS 102 812) per implementare il profilo “Internet Access”. MHP 1.1.X contiene:

• informazioni dettagliate sui profili “Interactive TV” ed “Internet Access”;

• la disponibilità per l’immagazzinamento delle applicazioni nella memoria persistente;

• download delle applicazioni mediante i canali broadcast o di interazione;

• estensioni al DVB-J per supportare meglio le applicazioni e l’accesso a lettori di smart card non certificati;

• specifiche di DVB-HTML;

• supporta la gestione di plug-in interoperabili (per il supporto di formati di applicazioni non conformi);

• supporto per i riferimenti bidirezionali tra il contenuto di MHP ed il contenuto internet;

MHP 1.1 è stata sviluppata basandosi sulla specifica MHP 1.0 con lo scopo di supportare meglio l’uso del canale di interazione e per specificare gli elementi che promuovono l’interoperabilità con il contenuto internet. Infatti MHP 1.1 è semplicemente un’altra versione della specifica MHP 1.0, basata sugli stessi file sorgente. Perciò in gran parte il contenuto di MHP 1.0 è ripetuto in MHP 1.1.

Con MHP 1.1, grazie al profilo Internet Access, le applicazioni possono controllare le operazioni basilari dei client residenti su internet (web browser, e-mail).

Per aggiungere queste funzionalità ed integrare il formato applicativo DVB-J, MHP 1.1 ha definito un nuovo tipo di applicazione opzionale: DVB-HTML, che è un linguaggio di mark-up basato su HTML; permette ad un ricevitore di presentare le applicazioni della tv interattiva digitale in HTML. Le specifiche DVB-HTML presentano le stesse estensioni e restrizioni delle specifiche del linguaggio W3C esistente.

Il software stack MHP è un progetto complicato. L’approccio a livelli utilizzato da MHP, con la possibilità di costruire API MHP sopra altre API MHP, rende possibile un approccio modulare nella costruzione del software.

Le API possono essere divise in due parti. Una parte si occupa dei servizi relativi agli stream MPEG, l’altra permette la costruzione di applicazioni direttamente sopra le API pJava.

Le API principali che si occupano di MPEG sono le API section filtering; le altre API che riguardano MPEG sono costruite sopra di esse. Le API service information analizzano le sezioni, che contengono le tabelle Service Information, per costruire il database Service Information che costituisce il nucleo delle API SI.

Le API DSM-CC analizzano le sezioni DSM-CC direttamente, ed utilizzano le API service information per cercare quali stream in un servizio contengono gli object carousel DSM-CC.

Le API tuner control si affidano alle API SI per individuare il transport stream che deve essere sintonizzato. Una volta che si hanno le informazioni sulla frequenza e sulla polarità, si può accedere al tuner hardware per sintonizzarsi sul corretto transport stream.

Le API JavaTV service selection utilizzano le API SI con lo scopo di trovare il servizio che deve essere sintonizzato. Fatto questo, si usano le API tuning e JMF per sintonizzare il transport stream corretto e visualizzare il servizio.

Le API application management si affidano alle API service selection (poiché ogni applicazione è associata ad un servizio), quindi c’è una relazione importante tra API service selection ed application manager. Le API service selection utilizzano le API application management per terminare le applicazioni quando viene selezionato un nuovo servizio o quando viene distrutto un service context.

DVB ha incominciato ad occuparsi di MHP dal 1997. Considerando il lavoro compiuto dal DVB nella produzione di specifiche per la trasmissione televisiva digitale, lo sviluppo di uno standard per l’utilizzo di applicazioni interattive rappresenta un aspetto chiave per la transizione dalla tv analogica a quella digitale.

Capitolo 3: Aspetti tecnici di trasmissione digitale

3.1 – Trasmissione digitale e transport stream

In un sistema broadcast digitale, una tipica struttura trasmissiva potrebbe essere la seguente:

In questa struttura, l’encoder viene usato per convertire il segnale analogico in ingresso in uno digitale con formato MPEG-2.

Un encoder può generare due tipi di stream MPEG.

Il primo tipo di stream è il constant bit rate; questi stream hanno sempre il solito bit rate, non interessandosi della complessità del segnale.

Se il segnale è troppo complesso per essere codificato nel bit rate specifico, la qualità viene ridotta; d’altra parte, se vengono utilizzati meno dati rispetto al bit rate specificato, lo stream viene riempito con pacchetti nulli fino al raggiungimento del bit rate corretto. Questo codifica rende l’elaborazione semplice, ma viene sprecata della banda.

L’altro tipo di stream che può essere generato è quello a bit rate variabile. In questo caso il bit rate dello stream può essere modificato dinamicamente, così la banda utilizzata varia in base alla complessità del segnale. Poiché alcune immagini hanno bisogno di maggiore banda per la codifica rispetto ad altre, la qualità viene mantenuta costante mentre l’occupazione di banda cambia. Lo stream a bit rate variabile comporta una elaborazione un po’ più complessa, ma fornisce maggiori vantaggi quando diversi stream MPEG vengono multiplexati insieme.

Il multiplexer prende uno o più stream MPEG e li associa in un singolo transport stream. Gli stream in ingresso possono essere elementary stream, altri transport stream oppure dati MPEG semplici.

Ogni transport stream di solito ha a disposizione una larghezza di banda prefissata, che dipende dal mezzo di trasmissione e dalla rete trasmissiva. Il compito del multiplexer è inserire un insieme di servizi in questa banda. Il modo più facile per farlo è usare uno stream MPEG a bit rate costante, poiché si sa esattamente quanta banda utilizza lo stream, quindi configurare un multiplexer risulta semplice. Questa soluzione è però inefficiente, poiché non è detto che tutti gli stream usino tutta la banda a disposizione: il problema dello spreco della banda è molto importante, in quanto i costi per la trasmissione sono alti, specialmente per quella satellitare, perciò è consigliabile trasmettere meno pacchetti nulli possibile.

Per questo motivo è meglio utilizzare stream MPEG a bit rate variabile, insieme ad una tecnica chiamata statistical multiplexing. Mentre il bit rate di ciascuno stream può variare considerevolmente, queste variazioni sono minori considerando diversi stream multiplexati insieme. In questo modo il problema del bit rate variabile è più facile da trattare: riservando un buffer separato per ogni stream, il multiplexer può disporre i pacchetti nel modo più efficiente.

I segnali digitali non possono essere trasmessi direttamente: prima devono essere modulati, quindi convertiti in segnali analogici per trasmetterli utilizzando segnali radio o segnali elettrici su cavo.

Le trasmissioni satellitare, terrestre e cablata possiedono caratteristiche differenti, perciò utilizzano modulazioni diverse.

Il modulation scheme è il modo in cui viene convertita l’informazione digitale in un segnale analogico trasmissibile. Il meccanismo di trasmissione satellitare utilizza la modulazione QPSK, il cavo la QAM, la trasmissione terrestre l’OFDM. Cavo e satellite utilizzano uno schema di modulazione simile; la trasmissione terrestre utilizza invece uno schema differente per fornire una maggiore resistenza agli errori causati dai segnali riflessi.

La modulazione viene effettuata dal modulatore, che prende un transport stream in ingresso e produce una uscita analogica passata al dispositivo di trasmissione. Dopo l’utilizzo del modulatore, i segnali trattati sono analogici e riguardano le trasmissioni radio.

I segnali vengono modulati alle basse frequenze, quindi vengono trasmessi. Le frequenze di trasmissione in realtà sono molto più alte, e potrebbe essere difficile modulare direttamente i segnali a tali frequenze. Per questo i segnali vengono modulati a bassa frequenza, quindi vengono convertiti ad alta frequenza prima della loro trasmissione. Questo processo viene effettuato utilizzando un upconverter, che non fa altro che convertire il segnale ad una frequenza più alta. Ogni transport stream viene trasmesso ad una frequenza diversa, così l’upconverter avrà impostazioni diverse per ogni transport stream gestito.

Alla fine del processo il segnale è pronto per la trasmissione, perciò c’è bisogno di un trasmettitore e di un’antenna.

Il segnale televisivo digitale viene trasmesso come uno stream di dati MPEG-2, detto transport stream. Il data rate di un transport stream è di circa 40 Mb/s, sufficiente per sette/otto canali televisivi distinti.

Un transport stream è composto da un insieme di ‘sotto-stream’, gli elementary stream, dove ciascuno può contenere o una traccia audio codificata MPEG-2, o una traccia video MPEG-2, o alcuni dati incapsulati in uno stream MPEG-2. Ogni elementary stream possiede un PID che agisce da identificatore di pacchetto unico per quel dato elementary stream all’interno di un transport stream.

Di seguito viene mostrato il processo di costruzione di un transport stream.

Si consideri un transport stream che contenga un singolo canale TV, supponendo di avere una sola traccia video ed una sola traccia audio.

La prima cosa da fare è codificare il video e l’audio nel formato MPEG-2 utilizzando un codificatore MPEG-2, hardware oppure software.

Alla fine della codifica si ottengono due elementary stream, uno contenente la traccia audio codificata MPEG-2 ed uno contenente la traccia video. Questi due stream dovrebbero avere entrambi la stessa lunghezza, con le tracce contenute che iniziano dal solito istante, in modo che audio e video risultino sincronizzati.

Quindi è possibile codificare i dati in uno stream MPEG-2, utilizzando un tool che genera uno stream MPEG-2 da una directory gerarchica; questo processo produce un altro elementary stream. In questo caso non sussistono problemi temporali, poiché i dati vengono semplicemente ripetuti nello stream e non devono essere perfettamente sincronizzati con gli altri stream, a differenza di audio e video.

A questo punto sono state ottenute tutte le parti del canale TV, detto anche servizio, codificate in stream MPEG-2 separati. Adesso bisogna multiplexare i vari stream in un singolo stream più grande, il transport stream, utilizzando un multiplexer MPEG-2. Questo tool assegna un Packet Identifier (PID) ad ogni stream; gli elementary stream vengono suddivisi in transport packet, dove ogni pacchetto è lungo 188 byte e viene identificato tramite il PID. Il multiplexer prende questi transport packet e li inserisce nel transport stream.

Ogni stream avrà un bit rate differente: ad esempio sono necessari più dati per codificare un secondo di video piuttosto che un secondo di audio, quindi lo stream audio conterrà meno dati. Gli stream a bit rate più alto, come quelli video, avranno più pacchetti inseriti dentro il transport stream finale per ogni pacchetto audio o dati che viene aggiunto. Non è insolito che per ogni pacchetto di uno stream audio inserito, vengano inseriti due pacchetti dati e circa dieci pacchetti per il video.

Tramite questo meccanismo si otterrebbe un transport stream che contiene un certo numero di elementary stream, senza indicare quali tipi di dati vengono trasportati, e come ricostruire tali stream nel ricevitore. Per risolvere questo problema, devono essere aggiunte altre informazioni al transport stream; questi dati vengono codificati in alcuni elementary stream che vengono aggiunti al transport stream durante la fase di multiplexing, detti service information.

Il service information è un semplice database che descrive la struttura del transport stream. Contiene un certo numero di tabelle: ognuna descrive un servizio contenuto nel transport stream; tali tabelle elencano gli elementary stream che formano un servizio, evidenziano i PID degli stream ed i tipi di dati contenuti.

Effettuando la descrizione di un transport stream tramite un service information piuttosto che includendo le informazioni all’interno di un elementary stream comporta un grande vantaggio: è possibile riutilizzare uno stesso elementary stream in diversi servizi.

Se un transport stream contiene più servizi, si deve multiplexare tutti gli stream audio, video e dati di tutti i servizi presenti. Il service information descriverà quali elementary stream appartengono ai diversi servizi.

Alcune tabelle descrivono i servizi specifici contenuti in un transport stream, mentre altre sono più generali e descrivono la struttura del transport stream stesso. In alcuni casi gli elementary stream contenenti le service information vengono trasmessi con un PID fissato per rendere più facile la loro ricerca ai decoder, mentre, in altri casi, i PID delle SI vengono memorizzati in un’altra tabella SI.

Le tabelle SI più importanti che si trovano in un transport stream DVB sono il Program Association Table (PAT) ed il Program Map Table (PMT).

Il PAT è la tabella fondamentale per SI; è l’unica tabella che viene trasmessa con un PID fisso e mostra il PID dell’elementary stream che contiene il PMT di un servizio.

Il PMT è la tabella che descrive come è composto un servizio. Questa tabella descrive tutti gli elementary stream di un servizio e notifica al ricevitore quale stream contiene il Program Clock Reference (PCR) MPEG per il servizio. Il PMT non viene trasmesso con un PID prefissato, ed esiste un PMT per ogni servizio contenuto nel transport stream.

MHP definisce una tabella extra service information (SI) chiamata Application Information Table (AIT). Questa tabella viene trasmessa come qualsiasi altro servizio contenente un’applicazione MHP, e contiene la descrizione delle applicazioni MHP associate a quel servizio; ad esempio, se un servizio è associato a due applicazioni, questa tabella conterrà due voci.

L’AIT contiene tutte le informazioni di cui un ricevitore ha bisogno per eseguire l’applicazione e per dire all’utente quali applicazioni sono disponibili. Include elementi come il nome dell’applicazione, la locazione dei file e qualsiasi argomento che deve essere passato all’applicazione quando viene avviata.

Ad ogni applicazione trasmessa è associato un identificatore memorizzato nell’AIT. Questo identificatore permette alle altre parti del sistema di riferirsi all’applicazione univocamente. Ogni identificatore consiste di due parti, un organization ID a 32 bit, unico per ogni organizzazione che produce applicazioni MHP, ed un application ID a 16 bit.

Quindi due applicazioni segnalate nello stesso AIT non possono avere i soliti organization ID e application ID.

Le applicazioni possono essere avviate o fermate automaticamente dal ricevitore, in base all’indicatore di stato presente nell’AIT. Questo status indicator dice se l’applicazione deve essere avviata automaticamente quando viene selezionato il servizio, se deve essere terminata automaticamente da un ricevitore o se un utente può avviarla manualmente.

Le applicazioni vengono trasmesse come parte di un transport stream MPEG-2 in un Object Carousel DSM-CC.

L’AIT contiene un application location descriptor che identifica l’object carousel che contiene l’applicazione, nonché il path dentro l’object carousel, poiché un object carousel può contenere più applicazioni.

Quando viene selezionato un nuovo servizio che contiene un’applicazione MHP, il ricevitore cerca l’AIT di quel servizio. Se ne trova uno, confronta l’elenco delle applicazioni segnalate con quelle attualmente in esecuzione. Le applicazioni che stanno girando ma che non sono segnalate nel nuovo AIT vengono terminate, mentre ogni applicazione segnalata nel nuovo AIT viene avviata automaticamente.

In AIT è presente un external application authorization descriptor che permette ad un broadcaster di indicare se un’applicazione precedentemente avviata può continuare ad essere eseguita.

Nel linguaggio adottato da DVB, un transport stream viene detto anche multiplex, poiché consiste di un insieme di servizi multiplexati insieme. Su una frequenza di trasmissione può essere trasmesso uno ed un solo multiplex. Ogni multiplex di solito viene trasmesso con un data rate di circa 40 Mb/s; la scelta di questo data rate è dovuta alle limitazioni di banda del mezzo trasmissivo.

All’interno del multiplex, un gruppo di elementary stream che costituisce un singolo canale televisivo viene chiamato service. Il numero di elementary stream che compongono un servizio non è detto che rimanga costante: può variare tra i diversi programmi di un particolare servizio (ad esempio, alcuni programmi possono essere trasmessi in più lingue o con più angoli di ripresa), o addirittura potrebbe cambiare all’interno dello stesso programma televisivo.

Un programma televisivo viene detto event. Da un certo punto di vista, un servizio consiste di un numero di elementary stream che vengono trasmessi simultaneamente, ma da un altro punto di vista, il servizio consiste di una serie di eventi individuali trasmessi uno dopo l’altro.

L’immagine seguente illustra un transport stream reale, ripreso da un transport stream analyzer.

Un program è sinonimo di service nella terminologia MPEG.

Come illustrato dall’immagine, il multiplex contiene diversi servizi, dove ciascun servizio contiene almeno uno stream audio, uno stream video e di solito alcuni stream dati.

La prima colonna indica il tipo di stream; i numeri che precedono il tipo rappresentano il particolare servizio.

La seconda colonna mostra i valori PID di ogni elementary stream. Di solito gli elementary stream che appartengono allo stesso servizio possiedono valori PID simili.

Le ultime due colonne mostrano, graficamente e numericamente, il bit rate di ogni elementary stream espresso in Mb/s.

La traccia video digitale viene codificata con un bit rate di circa 3-5 Mb/s; il data rate totale di un servizio di solito è di 4-6 Mb/s. Questo bit rate comporta una qualità inferiore a quella di un DVD, ma permette ad un broadcaster di inserire più servizi all’interno di un multiplex. Ovviamente i broadcaster desiderano inserire più servizi possibili all’interno di un multiplex, con lo scopo di trasmettere più canali utilizzando la stessa banda di frequenza (infatti un multiplex occupa una banda di frequenza in modo esclusivo).

Un transport stream riunisce fisicamente un insieme di servizi, ma tali servizi possono essere raggruppati anche logicamente. Un gruppo logico di servizi viene chiamato bouquet.

Si consideri il caso in cui un broadcaster deve trasmettere 50 canali; la trasmissione avviene attraverso il satellite, ed il transport stream è limitato a 40 Mb/s (copre all’incirca 8 canali), perciò c’è bisogno di 7 transport stream per trasmettere tutti i servizi.

Si assuma di vendere l’accesso a questi servizi in pacchetti differenziati, così un utente può scegliere di acquistare il pacchetto base (che contiene 13 canali), il pacchetto per lo sport (8 canali sportivi) o il pacchetto per i film (5 canali).

Per identificare quali canali appartengono ad un certo pacchetto, si potrebbe raggrupparli in un unico transport stream, ma, in questo caso, il pacchetto base è troppo grande per essere contenuto in un unico multiplex. Assegnando un bouquet ad ogni pacchetto, è possibile raggruppare i servizi nei transport stream in un modo efficiente, tramite un meccanismo di raggruppamento logico.

Infine, un broadcaster viene detto anche network, e può trasmettere diversi transport stream.

Riassumendo:

• Un network è un’azienda che trasmette uno o più transport stream.

• Un transport stream è uno stream MPEG-2 contenente diversi servizi.

• Un servizio è un canale TV e consiste di una serie di eventi consecutivi.

• Un evento è un singolo programma televisivo e comprende diversi elementary stream.

• Un elementary stream è uno stream MPEG-2, diviso in pacchetti, contenente tracce audio, video o dati binari codificati in MPEG-2.

• I servizi contenuti in diversi transport stream, possono essere raggruppati logicamente in un bouquet.

Un servizio può essere identificato tramite tre valori, che sono:

• l’original network ID, identificatore del network che trasmette il servizio;

• il transport stream ID, per identificare un transport stream di un particolare network;

• il service ID, per identificare un servizio all’interno del transport stream.

Per identificare un elementary stream si utilizza un component tag, che viene usato dai ricevitori per decidere quale servizio eseguire.

3.2 – Il protocollo DSM-CC

DSM-CC è uno standard per la trasmissione di dati basato sullo stream MPEG; è uno dei metodi principali per trasmettere le applicazioni ai ricevitori.

DSM-CC è l’acronimo di Digital Storage Media – Command e Control. Le specifiche dello standard includono il controllo dei server video MPEG in una rete (play, stop e pausa di un video o di un audio), il supporto per la trasmissione di dati utilizzando MPEG-2, codici temporali per video MPEG-2, semplice trasmissione di dati e trasmissione di file system. DSM-CC si occupa di svariati argomenti, e ci sono diverse parti delle specifiche DSM-CC che non sono direttamente collegate alle specifiche MHP.

I sistemi broadcast sono per loro natura unidirezionali. I dati vengono trasmessi da un trasmettitore ad un set top box, ed il ricevitore non può richiedere dati specifici al trasmettitore. Questo significa che un ricevitore non può richiedere un file specifico dal server, come avviene invece con i PC, che possono richiedere un file dalla rete o da un hard disk. Poiché un ricevitore non può accedere ai dati in questo modo, deve essere trovata un’altra soluzione.

La soluzione è semplice: il broadcaster trasmette periodicamente ogni file del filesystem, ed il ricevitore rimane in attesa per quelli che gli interessa. Le elaborazioni eseguite sul ricevitore dicono quali file interessano per la trasmissione. Un esempio pratico di questo tipo di soluzione è il sistema teletext: ciascuna pagina ha un numero preciso, e viene trasmessa a turno. Quando un utente digita il numero di una pagina, la televisione aspetta che la pagina venga trasmessa, dopodichè viene decodificata e visualizzata. Questo tipo di soluzione viene detto carousel.

Nel DSM-CC i dati vengono trasmessi in blocchi chiamati moduli piuttosto che in pagine, ma il principio è lo stesso: i dati vengono divisi in moduli, ai quali vengono aggiunte alcune descrizioni, ed infine ogni modulo viene trasmesso a rotazione.

DSM-CC supporta due tipi di carousel.

Nella TV interattiva, la semplice trasmissione dei dati da un broadcaster ad un ricevitore viene effettuata utilizzando i data carousel DSM-CC. Un data carousel consiste in una serie di moduli, dove ogni modulo contiene un dato come un file; questo modulo può essere diviso in blocchi per rendere la trasmissione più facile.

Si considerino due moduli. Supponiamo che il modulo A sia piccolo e che possa essere inserito dentro un singolo blocco, mentre il modulo B sia più grande e necessiti di due blocchi per mantenere tutti i suoi dati. Un data carousel semplice trasmetterà prima il blocco contenente il modulo A, quindi la prima parte del modulo B, infine il blocco contenente la seconda parte del modulo B; quindi rincomincia a trasmettere il blocco contenente il modulo A.

Come fa il ricevitore a sapere quando termina il modulo A ed inizia il modulo B?

Gli elementi di un carousel DSM-CC sono contenuti in un insieme di messaggi DSM-CC. Questi si dividono in due categorie: DSM-CC Download Data Message, che contengono i dati appartenenti ai moduli del carousel, e DSM-CC Download Control Message, che dicono al ricevitore come sono organizzati i Download Data Message nei moduli.

Il messaggio DownloadDataBlock è l’unico tipo di Download Data Message presente. Un messaggio DownloadDataBlock corrisponde ad un blocco di dati che viene trasmesso come singola unità. Ogni DownloadDataBlock ha anche la stessa grandezza, ad eccezione dell’ultimo blocco in un modulo, così si rende più facile l’analisi dei messaggi da parte del ricevitore.

Tramite il messaggio DownloadDataBlock vengono trasportati i dati in un carousel, mentre la struttura di un modulo viene definita da uno o più Download Control Message.

I data carousel funzionano bene per il sistema teletext o per una semplice applicazione, ma possiedono alcune limitazioni: il broadcaster trasmette blocchi di dati attraverso una connessione MPEG-2, ma questa soluzione non dice niente sulla natura dei dati.

L’applicazione che legge il data carousel deve conoscere il formato del contenuto e come lo deve trattare. Per le applicazioni MHP è un grande problema, poiché è importante conoscere la struttura dei file e delle directory per distinguere il codice delle applicazioni dalle risorse.

In situazioni complicate questo meccanismo non è molto utile, ed in questi casi l’object carousel fornisce una migliore soluzione.

Gli object carousel sono costruiti in cima ad un modello data carousel, e lo estende aggiungendo il concetto di file, directory e stream. Permette ad un carousel di contenere un vero filesystem, un insieme di directory e di file che formano una struttura a directory come in un PC.

Oltre ad essere costruiti sopra i data carousel DSM-CC, gli object carousel sono costruiti anche in cima al framework Object Request Broker (ORB) definito da CORBA. Ogni oggetto all’interno dell’object carousel viene trasmesso come un messaggio BIOP (Broadcast Inter-ORB Protocol) definito da CORBA, ed ogni messaggio è contenuto dentro un modulo data carousel DSM-CC.

In un object carousel possono essere trasportati i seguenti tipi di messaggi:

• File message, che rappresentano i file; contengono i dati che formano i file.

• Directory message, rappresentano i contenitori logici di un insieme di file message. Ciascuna directory DSM-CC contiene un certo numero di file (come le directory di un file system), ed un directory message contiene i riferimenti ai file che stanno dentro quella directory.

• Stream message sono riferimenti agli stream MPEG-2, che contengono i dati audio e video. Ogni stream message può riferirsi ad un singolo programma MPEG-2 oppure ad uno o più elementary stream.

• Stream Event message descrive un insieme di punti di sincronizzazione, chiamati stream event, che sono contenuti in uno stream. Questi messaggi dicono al ricevitore quali stream event sono presenti nello stream e li associa con un nome.

• Service Gateway message sono concettualmente simili ai Directory message. La differenza sta nel fatto che i Service Gateway message identificano la directory root dell’object carousel; questo significa che ciascun object carousel avrà un solo Service Gateway.

Un object carousel è composto da una serie di messaggi BIOP trasportati in un data carousel DSM-CC. I tipi di messaggi rappresentano i differenti tipi di oggetti che si possono trovare in un object carousel.

I messaggi DSM-CC contengono il payload all’interno dello stesso messaggio. Per esempio, un File message conterrà il contenuto completo di un file.

Ogni object carousel consiste in un directory tree, diviso in una serie di moduli, che possono contenere uno o più file o directory. Ogni modulo può contenere diversi file, e la sua grandezza massima è di 64 KB: non è permesso inserire file in un modulo per una grandezza superiore a 64 KB. Inoltre non è permesso suddividere i file su più moduli, così i file più grandi di 64 KB devono essere inseriti in un proprio modulo, che conterrà solo quel file. I file contenuti in un modulo possono provenire da qualsiasi parte del directory tree, non è necessario che sia contenuta anche la loro directory.

Questi moduli vengono trasmessi uno dopo l’altro fino a che non vengono trasmessi tutti; a quel punto il processo riparte dall’inizio e viene ritrasmesso il primo modulo. Per accedere ad un file, il ricevitore deve aspettare finché non riceve il modulo che lo contiene; quando lo riceve, analizza il modulo ed accede al file. Questo meccanismo potrebbe risultare inefficiente quando la quantità di dati trasmessa è piuttosto grande.

Viene illustrato un esempio di object carousel, supponendo di voler trasmettere le seguenti directory:

index.html 1256 byte

image1.jpg 4040 byte

image2.jpg 120346 byte

audio

audio/clip1.aiff 26430 byte

classes

classes/Main.class 23020 byte

classes/Big.class 59982 byte

classes/Other.class 26947 byte

Vengono creati i moduli da trasmettere inserendoci i file. Per prima cosa, vengono inseriti in un modulo i primi due file: index.html e image1.jpg.

Se venisse aggiunto il file image2.jpg, la grandezza del modulo supererebbe i 64 KB, perciò non è possibile. Comunque è possibile aggiungere il file clip1.aiff.

Inoltre è possibile aggiungere l’annotazione della directory audio senza causare problemi.

Infine sarebbe possibile aggiungere qualche file contenuto nella directory classes, ma questo non viene fatto per ottimizzare i tempi di caricamento. Questo modulo è definito, quindi si può proseguire con la creazione dei rimanenti.

Il file image2.jpg è più grande di 64 KB, ma non è possibile dividerlo in più moduli, perciò costituirà un modulo a parte. Questo modulo sarà più grande di 64 KB, ma non si può fare altrimenti.

Infine vengono aggiunti al carousel i file della directory classes. Questi file non possono essere inseriti tutti nello stesso modulo, ma vengono organizzati in modo che possano essere caricati il più velocemente possibile. La prima cosa che viene inserita al nuovo modulo è la registrazione della directory classes. Poiché la directory entry serve per accedere ai file contenuti in essa, si cerca di aggiungere a questo modulo più file classes possibili. In questo caso significa aggiungere i file Main.class e Other.class. L’ultimo file Big.class costituirà un modulo proprio.

Questo esempio di spartizione dei file in moduli potrebbe non essere il più efficiente: dipende quali file sono necessari e la relazione tra essi, così in una implementazione reale è molto importante stare attenti a creare il carousel più efficiente.

Quando si trasmette un DSM-CC carousel, questi moduli possono essere trasmessi più di una volta.

Trasmettendo alcuni moduli più volte rispetto ad altri, la grandezza totale del carousel aumenta ma il tempo di accesso dei file più usati diminuisce, mentre quello dei file usati meno frequentemente aumenta. Questo scostamento deve essere considerato attentamente quando viene progettato un carousel, per ottimizzare la velocità di scaricamento. E’ possibile che un file venga ripetuto in diversi moduli, così si fornisce un approccio granulato e si ottimizza l’object carousel.

La disposizione dei carousel è un arte piuttosto che una scienza, molto dipende dai dati utilizzati nei carousel, quando sono necessari e la grandezza dei file. Non si può dire quale disposizione dei carousel sia la più efficiente in un caso generale: bisogna conoscere la progettazione e la struttura dell’applicazione che utilizzerà i dati del carousel.

Capitolo 4: Le applicazioni sviluppate per MHP: le Xlet

4.1 – L’ambiente Java delle Xlet

Come già detto, il core di MHP si basa su Java: in particolare sono state adottate una Personal Java Virtual Machine ed una serie di API, tra cui le API Java TV di Sun ricoprono un ruolo fondamentale.

Tali API forniscono la piattaforma di sviluppo per i servizi interattivi della televisione digitale, utilizzando il linguaggio di programmazione Java.

Le API JavaTV sono state progettate per accedere alle funzionalità fornite dai ricevitori digitali, che comprendono lo streaming audio e video, l’accesso condizionato, l’accesso ai canali dati, i controlli per cambiare canale e quelli per l’interfaccia grafica sul televisore; per la gestione del media trasmesso in broadcast vengono sfruttate le API Java Media Framework (JMF 1.0).

Inoltre, queste API definiscono funzionalità addizionali, come la sincronizzazione dei media ed il controllo del ciclo di vita delle applicazioni.

La sincronizzazione dei media permette ai contenuti interattivi di sincronizzarsi con l’audio ed il video di un programma televisivo.

L’ambiente hardware e software implementato in un ricevitore digitale include i seguenti livelli:

• Hardware Layer, definito dall’hardware del STB;

• Real Time Operative System (RTOS) Layer, il livello che include il sistema operativo real-time ed i vari driver;

• Java Technology Layer, che include la piattaforma Java con le relative API JavaTV;

• Application Layer, dove vengono eseguite le applicazioni.

L’ambiente software comprende la piattaforma Java e le API JavaTV, eseguite sopra il sistema operativo real-time (RTOS).

Al livello più basso, il RTOS e le relative librerie controllano l’hardware attraverso un insieme di driver. Il RTOS fornisce il supporto di sistema necessario per implementare la Java Virtual Machine e le librerie che compongono la piattaforma Java.

Le API JavaTV forniscono un livello di astrazione che permette ai programmatori di non occuparsi dei dettagli specifici dell’hardware sottostante; queste API si differenziano dallo standard MHP, poiché non sono vincolate ai sistemi DVB per la TV digitale. Le applicazioni scritte usando le API JavaTV possono essere eseguite su qualsiasi tipo di piattaforma in grado di supportarle; tale portabilità è fondamentale per gli sviluppatori di applicazioni e di contenuti che vogliono vendere i loro prodotti su mercati differenti.

Sebbene le API JavaTV non costituiscono lo standard per la TV interattiva, di fatto sono incluse in moltissimi standard emanati.

Le API JavaTV sono composte da un insieme di pacchetti Java; il package più importante è javax.tv.xlet, che contiene le classi che definiscono il ciclo di vita delle applicazioni.

Alle JavaTV mancano alcune funzionalità fondamentali, che però vengono fornite da altre API; ad esempio, il supporto per il canale di ritorno viene fornito da java.net, mentre il supporto per il controllo dei contenuti audio e video viene fornito dal JMF.

Le applicazioni sviluppate per MHP vengono chiamate applicazioni DVB-J. Sono scritte in Java e consistono in un insieme di classi trasmesse in broadcast. Spesso si fa riferimento a tali applicazioni con il nome di Xlet.

In pratica, un’applicazione Java convenzionale non si adatta bene all’ambiente televisivo digitale.

Questo modello presuppone l’esecuzione di una sola applicazione in una data macchina virtuale, e che l’applicazione stessa abbia il controllo completo del proprio ciclo di vita.

In un ricevitore televisivo digitale, invece, è frequente che più applicazioni vengano eseguite nello stesso momento.

A tal proposito viene considerato il funzionamento delle applet che, a differenza delle normali applicazioni, possono essere avviate da una sorgente esterna, il web browser, ed alcune di esse possono essere eseguite sulla stessa pagina web nello stesso momento.

Ovviamente il sistema televisivo digitale è diverso dal Web, perciò devono essere adottati alcuni cambiamenti affinché questi concetti si adattino al ricevitore digitale.

Una Xlet quindi non è un’applicazione Java standard: è una particolare applicazione concepita per essere scaricata ed eseguita sui decoder interattivi; esse sono state introdotte da Sun nella specifica JavaTV, ed adottate come formato applicativo Java per MHP.

Sono molto simili ad applet: come nelle applet, l’interfaccia Xlet permette ad un software specifico esterno, l’application manager nel caso del ricevitore MHP, di controllarne il ciclo di vita, avviando o fermando l’applicazione. L’interfaccia Xlet si trova nel package javax.tv.xlet.

Come le classi applet, l’interfaccia Xlet contiene i metodi che permettono all’application manager di inizializzare, avviare, mettere in pausa e distruggere una applicazione.

Poiché potrebbero esserci più Xlet che vengono eseguite nello stesso momento, esse non possono effettuare alcuni compiti che potrebbero influenzare la Java Virtual Machine; in particolare, una Xlet non deve mai richiamare il metodo ‘System.exit()’ per terminare l’applicazione .

La differenza più importante tra applet e Xlet è che una Xlet può essere messa in pausa ed essere riavviata in un secondo momento. La ragione è semplice: nel caso di un ricevitore digitale, diverse applicazioni potrebbero essere eseguite nello stesso momento, mentre le capacità dell’hardware permettono ad una sola applicazione di essere visibile; quelle non visibili perciò devono essere messe in pausa con lo scopo di mantenere le risorse libere per l’unica applicazione mostrata.

Le interfacce fondamentali da utilizzare sono definite nelle API JavaTV.

Le interfacce javax.tv.xlet.Xlet e javax.tv.xlet.XletContext servono per interagire con l’application manager in merito al ciclo di vita e al contesto in cui la Xlet viene eseguita.

Una Xlet di fatto implementa i 4 metodi presenti nell’interfaccia javax.tv.xlet.Xlet:

• initXlet: questo metodo viene invocato dall’application manager per inizializzare l’Xlet;

• startXlet: è la funzione che serve per eseguire l’Xlet;

• pauseXlet: usata per mettere in pausa l’Xlet;

• destroyXlet: invocata quando l’application manager termina l’Xlet.

Il ciclo di vita di una Xlet è caratterizzato da 4 stati:

• Loaded: la Xlet viene creata ma non ancora inizializzata. Se durante questa fase viene rilevata un’eccezione, si passa direttamente allo stato Destroyed. Una Xlet può trovarsi in questo stato solo una volta durante tutto il suo ciclo di vita.

• Paused: la Xlet viene inizializzata, e può trovarsi in questo stato sia dopo che il metodo initXlet ritorna con successo dallo stato Loaded, oppure dopo che il metodo pauseXlet ritorna con successo dallo stato Active. In questo stato, la Xlet deve limitare al massimo l'utilizzo delle risorse condivise e soprattutto non impegnare la GUI televisiva.

• Active: in questo stato la Xlet è attiva e utilizza le risorse necessarie per fornire i suoi servizi; se è dotata di GUI, allora dovrebbe essere l'unica applicazione abilitata a ricevere gli eventi dal telecomando.

• Destroyed: in questo stato la Xlet deve rilasciare tutte le risorse in uso per predisporsi alla terminazione.

Una sequenza tipica del ciclo di vita può essere la seguente:

1. L’application manager carica la classe principale della Xlet, su segnalazione del broadcaster, e ne crea un’istanza: l’applicazione si trova nello stato Loaded.

2. Quando l’utente sceglie di avviare l’Xlet, o un’altra applicazione segnala che l’Xlet deve partire automaticamente, l’application manager invoca il metodo initXlet. L’Xlet usa il ‘context’ per inizializzarsi, ed eventualmente per richiedere alcune risorse, come le immagini. Quando l’inizializzazione è completata, l’Xlet si trova nello stato Paused, ed è pronta per essere avviata.

3. Una volta che il metodo initXlet ritorna con successo, l’application manager richiama il metodo startXlet. Questo comporta il passaggio dallo stato Paused allo stato Active, così l’Xlet sarà capace di interagire con l’utente ed utilizzare le risorse necessarie per fornire i servizi per cui è stata creata.

4. Durante l’esecuzione, l’application manager può invocare il metodo pauseXlet; questo comporta il passaggio dell’applicazione dallo stato Active allo stato Paused. L’applicazione potrà tornare nello stato Active richiamando il metodo startXlet: questa situazione può accadere svariate volte in tutta la vita di una Xlet.

5. Alla fine del ciclo di vita, l’application manager invoca il metodo destroyXlet, che comporta il passaggio allo stato Destroyed, liberando tutte le risorse. A seguito di questa operazione, l’istanza di questa Xlet non può essere più richiamata.

Ogni Xlet ha a disposizione un “contesto di applicazione”, l’XletContext, che è un’istanza della classe javax.tv.xlet.XletContext.

Questo context è simile alla classe AppletContext associata ad una applet: in entrambi i casi il contesto viene usato dall’applicazione per accedere alle proprietà dell’ambiente circostante e per comunicare i cambiamenti di stato all’application manager.

L’interfaccia javax.tv.xlet.XletContext prevede i seguenti metodi:

• notifyDestroyed;

• notifyPaused;

• getXletProperty;

• resumeRequest.

I metodi notifyDestroyed e notifyPaused permettono ad una Xlet di notificare al decoder che l’applicazione sta per terminare o per mettersi in pausa; in questo modo, il ricevitore conosce lo stato di ogni applicazione e può effettuare le azioni appropriate. Questi metodi devono essere richiamati immediatamente prima che l’Xlet entri negli stati Paused o Destroyed, a causa del fatto che il ricevitore potrebbe effettuare alcune operazioni per le quali l’applicazione non è detto che sia pronta.

Una Xlet può richiedere di passare dallo stato Paused allo stato Active usando il metodo resumeRequest. Questo può accadere quando si verifica un certo evento, rilevato ad esempio nello stream MPEG. Questo metodo richiede che un’applicazione venga fatta partire nuovamente, anche se il software del ricevitore potrebbe scegliere di ignorare questa richiesta a causa di limiti nelle risorse.

Il metodo getXletProperty permette alla Xlet di accedere alle proprietà segnalate dal broadcaster. Attualmente è stata definita una sola proprietà da JavaTV e da MHP, XletContext.ARGS, che permette ad un’applicazione di accedere agli argomenti che le vengono segnalati tramite AIT.

Di seguito viene mostrato cosa succede quando una Xlet chiede di cambiare il proprio stato tramite l’Xlet context. Si consideri una Xlet che vuole mettersi in pausa e successivamente richiede di riavviarsi.

1. Per prima cosa, l’Xlet notifica al suo Xlet context che si è messa in pausa, invocando il metodo XletContext.notifyPaused().

2. L’Xlet context inoltra questa informazione all’application manager presente nel middleware.

3. L’application manager aggiorna il suo stato interno per notificare che l’applicazione si è messa in pausa, quindi l’Xlet si ferma.

4. Quando un’applicazione vuole riavviare le operazioni, ad esempio perché è passato un certo tempo prefissato oppure perché l’utente ha premuto un tasto, viene richiamato dalla Xlet il metodo XletContext.requestResume().

5. Come prima, l’Xlet context passa tale richiesta all’application manager.

6. L’application manager può quindi decidere se riavviare l’applicazione oppure no. Se la riavvia, aggiorna il proprio stato interno per notificare il cambiamento, quindi chiama il metodo startXlet() sulla Xlet: come tutte le altre operazioni che controllano il ciclo di vita della Xlet, questo metodo viene richiamato direttamente dall’application manager e non attraverso l’Xlet context.

7. Infine l’Xlet riavvierà le proprie operazioni.

Il costruttore della classe principale di ogni Xlet deve essere lasciato vuoto: quando il middleware avvia un’applicazione, all’inizio crea un’istanza della classe principale. In questo modo invoca il costruttore di default, se esiste, ed esegue il codice contenuto.

In realtà una Xlet possiede un altro metodo che deve essere usato per questo tipo di setup: il metodo initXlet(), che permette un controllo migliore delle operazioni. Tutte le inizializzazioni devono essere fatte nell’implementazione di questo metodo. Durante l’inizializzazione, se qualcosa fallisse verrebbe lanciata un’eccezione, passando direttamente allo stato Destroyed.

Le Xlet possono essere eseguite su un software open source, chiamato XleTView, che permette di emulare un middleware MHP su PC. E’ un progetto open source autorizzato sotto licenza pubblica GNU.

4.2 - Interfaccia grafica delle Xlet

Ogni Xlet deve implementare l’interfaccia Xlet, presente nel package javax.tv.xlet delle API JavaTV di Sun.

Per costruire l’interfaccia grafica devono essere importati altri package:

• java.awt.*;

• java.awt.event.*;

• org.havi.ui.*;

• org.havi.ui.event.*;

• org.dvb.ui.*;

• org.dvb.event;

Questi package servono per fornire le necessarie funzionalità grafiche ed i rispettivi eventi per implementare l’interfaccia utente.

In pratica, il modello grafico definito dallo standard MHP viene supportato dai package sopra citati, tra i quali spicca quello Havi.

Classe fondamentale per gestire il layout su schermo è la HScene, presente nei pacchetti forniti da Havi. HSceneFactory è la classe che permette di richiamare l’unica istanza HScene.

Il modello grafico definito dallo standard MHP è basato su tre differenti layer.

Al livello più basso si trova il Background layer, che può contenere un colore o una immagine statica (rappresentata da un particolare frame MPEG-2).

Nel secondo livello è situato il Video layer, rappresentato dal flusso A/V del canale TV o da una qualsiasi altra fonte in formato MPEG-2.

Al livello più alto infine si trova il Graphic layer, che contiene la grafica creata nella Xlet, e può essere strutturato su più livelli sovrapposti.

Questo modello grafico è supportato dai package messi a disposizione dallo standard, tra i quali quello più importante viene fornito da Havi.

In tale package, il container di più alto livello nella Xlet è rappresentato dalla classe org.havi.ui.HScene, che possiede caratteristiche specifiche per i decoder digitali.

La classe che ci permette di richiedere l'unica istanza della HScene è fornita dallo stesso package e si chiama org.havi.ui.HSceneFactory.

Oltre ad Havi e AWT è possibile utilizzare un package specifico DVB, org.dvb.ui, dove è possibile trovare classi di utilità come la DvbColor, che permette di gestire anche le trasparenze tramite il parametro alpha, non presente nella classe java.awt.Color.

Il font di sistema supportato in MHP è il Tiresias.

I formati grafici supportati sono: png, jpg, gif e mpg(I-Frame).

Di seguito viene esposto un esempio di codice che recupera l'istanza di HScene e ci posiziona un HContainer e un HText.

HSceneFactory hsf = HSceneFactory.getInstance();

HScene scene =

hsf.getFullScreenScene(HScreen.getDefaultHScreen().getDefaultHGraphicsDevice());

// risoluzione a schermo pieno

scene.setSize(720,576);
scene.setLayout(null);
HContainer cont = new HContainer(10,10,720,576);

HText text = new HText("Casella di testo!",160, 200, 300, 60, new Font("Tiresias", Font.PLAIN, 26), Color. black, Color. white, new HDefaultTextLayoutManager());
cont.add(text);
scene.add(cont);
scene.setVisible(true);
scene.repaint();

Gli eventi associati al telecomando definiti in MHP sono i tasti numerici, le frecce di navigazione, il tasto OK ed i 4 tasti colorati: rosso, verde, giallo e blu.

Lo standard non definisce l’evento per il tasto EXIT, anche se è presente sulla quasi totalità dei decoder, quindi genera degli eventi non-standard e non sempre coerenti sui vari decoder.

MHP fornisce due possibilità per la gestione degli eventi nelle Xlet:

• il classico meccanismo java, fornito in AWT, che si realizza implementando l'interfaccia java.awt.event.KeyListener.

• le classi del package org.dvb.event.

Le classi principali del package org.dvb.event sono la EventManager e la UserEventRepository, che gestiscono rispettivamente la registrazione degli eventi ed il repository degli eventi a cui si è realmente interessati. Un esempio di registrazione degli eventi è il seguente:

UserEventRepository repository = new UserEventRepository("UserRepository");
repository.addAllColourKeys();

EventManager manager = EventManager.getInstance();

manager.addUserEventListener(this, repository);

Questo approccio ha il vantaggio di non imporre ad una Xlet di richiedere il focus tramite la HScene, come invece prevede il modello AWT.

Capitolo 5: Prototipo applicativo: XletUOL

Infine, per dimostrare le funzioni di interattività che può fornire la televisione digitale terrestre, è stata sviluppata un’applicazione MHP demo che implementa un sistema di prenotazione bibliotecario.

L’Xlet elaborata ripresenta le funzionalità di UOL (User On Line): questo è un sistema presente su Web che consente l’accesso, tramite un terminale connesso in rete, ad un archivio di biblioteche, con la possibilità di ricercare e prenotare un testo.

Grazie a questa applicazione, un utente ha la possibilità di prenotare un libro direttamente dal proprio televisore, solo con l’utilizzo del telecomando e del Set Top Box.

Il sistema prevede che l’utente sia già iscritto al servizio UOL tramite una biblioteca associata, perciò è già a conoscenza del suo codice identificativo.

Questa Xlet, quindi, dà la capacità di inserire il titolo o l’autore del libro desiderato, selezionando la biblioteca di interesse tramite un menù a comparsa.

Il servizio offerto è di sola prenotazione, non di ricerca, perciò un libro già prenotato risulta semplicemente non disponibile.

E’ previsto un dialogo tra il Set Top Box dell’utente ed il centro servizi che gestisce la prenotazione: esso elabora la richiesta, fornisce la risposta all’utente ed eventualmente prenota il libro.

Per sviluppare l’applicazione è stato utilizzato l’emulatore XleTView, un emulatore open source del middleware MHP, reperibile gratuitamente su Internet sotto licenza GNU.

Lo scenario di questo elaborato si presenta nel seguente modo:

• All’avvio dell’applicazione viene mostrata, sullo schermo televisivo, una interfaccia grafica che presenta i campi editabili dall’utente per inserire i valori di interesse. I campi visualizzati riguardano l’Autore, il Titolo e la Biblioteca, seguiti da un bottone Invio di conferma.

I primi due sono delle semplici campi di testo, mentre il terzo rappresenta un menù in cui l’utente può selezionare la scelta desiderata.

• Una volta che l’utente ha definito i campi di interesse, invia la richiesta al centro servizi, che effettuerà le mansioni di elaborazione e ricerca sul database delle biblioteche.

• Se la ricerca è andata a buon fine, ovvero il testo richiesto è presente nella biblioteca e disponibile per la prenotazione, viene visualizzata una interfaccia con i risultati ottenuti. Se invece non è andata a buon fine, viene visualizzata una finestra di popup che notifica l’assenza del testo, oppure un errore nella richiesta immessa.

• Se l’utente è soddisfatto dell’esito della ricerca, e vuole proseguire con la prenotazione, ha la possibilità di inserire il proprio codice identificativo ed il codice relativo al testo. Quindi invia la conferma di prenotazione.

• Infine, viene mostrata un’ultima schermata che notifica l’avvenuta prenotazione del libro, con la possibilità di proseguire nella ricerca di un ulteriore testo.

Durante tutto il ciclo di vita dell’applicazione, viene fornita all’utente la possibilità di uscire dall’applicazione; inoltre, se l’esito della ricerca ha prodotto risultati che non lo soddisfano, è prevista la possibilità di tornare alla pagina iniziale di ricerca.

La problematica più importanti che questo elaborato ha sollevato è la difficoltà, per il programmatore, nella gestione degli eventi.

Effettuando una semplice considerazione, infatti, si evince che, nell’ambito televisivo, non è possibile alcuna interazione con i comandi comuni di un PC: è evidente che non esiste alcuna tastiera per immettere i caratteri voluti e, fatto ancora più importante, non esiste un puntatore, come il mouse, per selezionare i campi voluti e navigare all’interno dell’interfaccia.

Per ovviare a questi problemi si sono implementate alcune soluzioni.

In particolare, una volta avviata l’applicazione, si posiziona il focus, ovvero la parte evidenziata e modificabile dall’utente, nel primo campo di testo visualizzato: in questo caso, il focus viene preimpostato sul campo Autore. Durante l’esecuzione dell’Xlet, tale focus è navigabile mediante i tasti colorati presenti nel telecomando.

Come già anticipato, un altro problema, legato all’aspetto di presentazione piuttosto che all’implementazione, è la possibilità di inserire dei caratteri nei campi da editare solo tramite l’utilizzo del telecomando. Tale problema è fondamentale da risolvere, poiché l’utente non predispone di una tastiera.

La soluzione adottata è stata quella di fornire una tastiera da visualizzare sullo schermo televisivo: essa, come il campo da editare, ottiene immediatamente il focus appena l’Xlet viene avviata, ed è navigabile mediante i tasti cursore presenti sul telecomando.

Per facilitare la lettura dell’applicazione ed informare sui comandi disponibili, è presente nel layout una sezione di informazione, dove si spiega all’utente le funzionalità offerte e gli eventi attivi.

La struttura del layout viene perciò divisa in tre parti principali:

• una sezione di informazioni, con sfondo nero, che indica all’utente i comandi e gli eventi associabili che risultano disponibili in un dato momento;

• il corpo principale dell’applicazione, dove vengono visualizzati i campi di testo da editare, la tastiera e la risposta delle query al database.

• una sezione di uscita, che informa l’utente sui tasti attivi per uscire dall’applicazione o tornare alla maschera iniziale di ricerca.

Ovviamente particolare attenzione è stata rivolta alla gestione dei casi di errore: ad ogni ricerca effettuata, viene controllata la presenza dell’elemento ricercato; se i caratteri immessi sono errati o non presenti, l’applicazione visualizza una finestra di popup per notificare l’errore di esecuzione.

Inoltre, quando si invia la prenotazione di un testo scelto, compare una finestra per richiedere la conferma dei dati immessi, data l’importanza delle azioni effettuate.

Per rendere operativa questa applicazione demo, è stato implementato un database di prova MS Access, contenente i testi presenti nelle varie biblioteche, oltre ad una tabella aggiuntiva contenente le generalità ed i codici di ogni utente iscritto al servizio.

In seguito viene illustrato il funzionamento ed il ciclo di vita della Xlet.

Avviando l'applicazione compare una interfaccia iniziale, contenente due campi di testo, un menù a tendina per la scelta della biblioteca ed un pulsante per inviare la ricerca del libro al database.

Per inserire le parole sui campi di testo si deve utilizzare la tastiera visualizzata.

Quando l’Xlet viene avviata, il focus è predefinito per attivare il campo autore ed il tasto 'G' della tastiera.

I tasti che si possono premere in questo stato sono il tasto rosso, il tasto verde, il tasto blu, i tasti freccia ed il tasto Ok.

Il tasto rosso permette di avanzare il focus dei campi: da Autore ad Invio, passando dal Titolo e dalla Biblioteca. Una volta arrivati al pulsante di invio della ricerca, premendo nuovamente il tasto rosso si ritorna al campo Autore, implementando un meccanismo ciclico.

Il tasto verde ha il funzionamento analogo, ma in verso opposto.

I tasti freccia servono invece per scorrere i tasti della tastiera. Infine, premendo Ok si inserisce il carattere evidenziato nel campo di testo attivo.

Premendo il tasto blu, appare una finestra per richiedere l'uscita dall'applicazione. Questa nuova finestra richiede la conferma di uscita: in questo caso, solo i tasti freccia SINISTRA e DESTRA sono attivi per la conferma di uscita applicazione.

Quando è attivo il campo biblioteca, si ha a disposizione un menù a tendina. Premendo i tasti SU e GIU è possibile scorrere le biblioteche presenti; infine è possibile visualizzare il menù a tendina premendo il tasto Ok.

Infine è possibile inviare la richiesta di ricerca del libro, attivando il pulsante Invio; una volta formulata la query, avviene uno dei seguenti due casi:

• La query non ha successo, poiché l’inserimento dei campi è errato oppure il libro richiesto non è disponibile nella biblioteca selezionata.

• La query ha successo. In questo caso compare una nuova interfaccia, che evidenzia i risultati della richiesta al database, mostrando l'autore, il titolo ed il codice del libro.

Nella nuova schermata è possibile prenotare il libro immettendo il codice utente ed il codice del libro.

Inoltre diviene attivo un nuovo tasto, quello giallo, per permettere di tornare all’interfaccia iniziale se la richiesta attuale non soddisfa l'utente.

Per immettere il codice utente ed il codice del libro si digitano le cifre tramite i tasti numerici.

Se il codice immesso è sbagliato, è possibile correggerlo premendo il tasto a sinistra, eliminando l'ultima cifra inserita.

Infine si attiva il pulsante Ok per trasmettere la richiesta di prenotazione del testo.

Ogniqualvolta che si preme questo tasto, compare una finestra di conferma di prenotazione.

In caso di errore nella digitazione dei codici utente o del libro, compare una finestra di popup per notificare l’errore avvenuto.

Infine, se i codici inseriti sono corretti, compare l'ultima interfaccia per la notifica della prenotazione.

A questo punto, è possibile effettuare una ulteriore ricerca, premendo il pulsante e tornando alla schermata iniziale, oppure uscire dall'applicazione premendo il tasto blu.

Capitolo 6: Conclusioni

Tramite lo studio e le analisi effettuate durante il periodo di tesi, sono stati esaminati gli standard e le soluzioni tecnologiche, ottenendo una completa visione della tecnologia sottostante al sistema di televisione digitale terrestre.

Nella prima fase sono state analizzate accuratamente le specifiche di interesse emanate dal consorzio DVB. In particolare è stata effettuata una intensa attività di ricerca ed analisi di notizie, tutorial e standard reperibili in Internet, sia nei siti ufficiali delle organizzazioni dedicate, come DVB e MHP, sia tramite i diversi forum di discussione o grazie a siti elaborati da semplici appassionati.

Tale attività ha prodotto tutto il materiale teorico presente nella tesi, ovvero l’introduzione, gli aspetti trasmissivi e la trattazione alle applicazioni interattive, le Xlet.

In seguito, è stato possibile vedere in pratica un possibile beneficio che questa nuova tecnologia può apportare, sviluppando un sistema di prenotazione bibliotecaria navigabile sul televisore di casa.

Durante l’elaborazione del suddetto sistema, si sono riscontrati alcuni aspetti rilevanti. In particolare, poiché la materia trattata è in corso di introduzione ed ancora sperimentale, per adesso è scarsa la presenza di documentazione e di guide che estendino le specifiche Java relative alle API JavaTV.

E’ per questo motivo che durante lo sviluppo si sono utilizzate principalmente le classi fornite dalla SDK Java, attingendo tutti i componenti ed i relativi eventi dal pacchetto Swing. Gran parte del lavoro è stato dedicato allo studio di una interfaccia utente usabile. Poichè l’applicazione sviluppata rientra nell’ambito televisivo, è assente una tastiera per immettere i caratteri, perciò si è sentito la necessità di presentarla all’interno dell’interfaccia grafica, risolvendo i problemi di inserimento e tracciando costantemente i caratteri che un utente può digitare. Ovviamente tale soluzione è ottimizzabile, ad esempio inserendo un suggeritore automatico che assista l’utente durante la digitazione. Inoltre, per risolvere il problema di navigazione all’interno dell’interfaccia, si è adottata la seguente soluzione: all’avvio dell’applicazione, viene predisposto automaticamente il componente attivo, ovvero modificabile

dall’utente; in seguito l’Xlet risulta navigabile mediante i tasti colorati presenti sul telecomando. Infine è stata riservata una sezione all’interno dell’interfaccia per informare l’utente sui possibili comandi che può azionare tramite l’utilizzo del telecomando.

Possibili sviluppi futuri che questa tesi può offrire riguardano un’analisi più approfondita sul protocollo di trasporto DSM-CC, che rappresenta uno standard molto complicato e non strettamente legato al DVB-T, ma comunque di necessaria implementazione per la trasmissione delle applicazioni. Inoltre, sarebbe fondamentale costruire un player in grado di riprodurre e di gestire a nostro piacimento i transport stream.

Per quanto riguarda l’elaborato, è possibile effettuare un suo ulteriore sviluppo, implementando la connessione alla rete telefonica ed utilizzando un database reale e più complesso; inoltre, per quanto riguarda l’interfaccia grafica, sarebbero completamente da riprogettare le funzionalità ed il layout della tastiera.

BIBLIOGRAFIA – SITI DI RIFERIMENTO

Per l’introduzione, le informazioni sono state elaborate dai seguenti siti:

http://www.dgtvi.it

http://www.digitale-terrestre.com

http://www.digitaleterrestre.tv.it

http://www.dvb.org

http://www.mhp.org

http://www.dtg.org.uk

Per i paragrafi riguardanti il Digital Video Broadcasting Project ed il Multimedia Home Platform, le informazioni sono state elaborate dai seguenti siti:

http://www.dvb.org

http://www.mhp.org

http://portal.etsi.org/broadcast/kta/dvb/dvb.asp

http://www.dtg.org.uk

http://www.mokabyte.it/2004/04/jtdi-1.htm

Le informazioni riguardanti le API Java TV, le Xlet ed il software XleTView sono state elaborate dai seguenti siti:

http://java.sun.com/products/javatv/overview.html

http://www.interactivetvweb.org

http://www.mokabyte.it/2004/05/jtdi-2.htm

http://xletview.sourceforge.net

Le informazioni riguardanti la struttura trasmissiva, DSM-CC e stack MHP sono state elaborate dal sito:

http://www.interactivetvweb.org