Architettura
di Sistemi (STB) per Digitale Terrestre
su alcune innovazioni
Alcuni dei paesi che hanno aderito allo standard DVB hanno pubblicato documenti di specifiche tecniche riguardanti il ricevitore in cui, partendo dai requisiti minimi richiesti dallo standard, si definiscono i profili adatti allo specifico mercato nazionale. In Italia, un consorzio di aziende formato dai tre principali broadcasters italiani, RAI, Mediaset e TV Internazionale (Telecom) e dalla Fondazione Ugo Bordoni (incaricata di coordinare le sperimentazioni relative al T-Government) ha fondato DGTVi, con lo scopo di indirizzare il processo di sviluppo della TV digitale.
Nel
Settembre 2004, DGTVi ha rilasciato un documento tecnico, specifico
per il mercato italiano, “Compatible
DTTV receivers
for the Italian market”,
meglio noto come D-Book, la cui ultima versione, D-Book 1.1, è stata
rilasciata nel 2006. Un'altra pubblicazione a carattere
nazionale, “Il libro bianco sulla
televisione
digitale terrestre”,
riguardante, tra gli altri argomenti, anche le caratteristiche
tecniche di un ricevitore, era già stata commissionata
dall'Autorità per le Garanzie nelle Comunicazioni e
rilasciata
nel 2000. Prendendo come riferimento le specifiche tecniche definite
dallo standard DVB e dalle pubblicazioni sopra citate, in
questo
capitolo verranno descritte le architetture hardware e software del
STB e le sue funzionalità di base.
Il STB è un apparato esterno ed indipendente rispetto al televisore, al quale si collega per mezzo di cavi di connessione SCART. L'alternativa al STB esterno, è integrarne le funzionalità in televisori di nuova concezione, nel qual caso si parla in modo più appropriato di Integrated Receiver Decoder (IRD). Le differenze tra le due specifiche non sono sostanziali e quelle evidenziate riguardano principalmente l'obbligatorietà o meno di qualche requisito. La possibilità di ridisegnare completamente il modello architetturale della TV è già allo studio da tempo, ma l'impossibilità di sostituire nel breve periodo il parco TV attuale, 20 milioni di abitazioni in Italia con almeno un televisore per un totale di più di 50 milioni di apparecchi, la rapida evoluzione delle tecnologie ed il tempo richiesto dalle sperimentazioni sul campo, inducono a pensare che il STB possa rimanere per anni la soluzione più adottata.
Il Set Top Box oggetto della presente analisi, è dotato di piattaforma DVB MHP per l'area applicativa, di un canale di ritorno per l'interattività avanzata, di un sistema modulare di controllo dell'accesso ai servizi (Conditional Access System) e di un lettore di Smart Card per generici servizi interattivi. La sua architettura generale, vista ad un livello alto di astrazione, evidenzia i principali blocchi funzionali e le interfacce, come rappresentata in figura 4.1. Nello stesso schema, è indicata anche la suddivisione delle architetture hardware e software che saranno sviluppate successivamente.
| Software Applicativo ( EPG, Teletext avanzato, ecc. )
| Architettura Software |
| API | |
| Software Residenti ( Sistema Operativo, Navigatore SI,
Java,browser XML ed HTML, ecc. ) | |
| Hardware e Firmware ( microprocessore, memorie RAM e Flash,
bootloader,
componenti di codifica,
decodifica e interfacce esterne ) |
Architettura Hardware |
Figura 4.1: Architettura generale del Set Top Box
Al livello più basso dello stack troviamo la composizione hardware e firmware del STB. Questo livello comprende il Microprocessore, i differenti tipi di memoria, il bootloader, gli apparati di decodifica e le interfacce con l'esterno, sia in input che in output.
Al livello superiore si colloca il software residente, come quello del Sistema Operativo, solitamente proprietario, i software di servizio, come ad esempio quello di gestione della navigazione, ed il middleware. Il soprastante strato di interfacciamento, l'Application Programming Interface (API), fornisce infine al livello Applicativo la capacità di interagire con il software residente e con le risorse del sistema.
Le principali funzionalità richieste ad un STB, svolte sotto il controllo del microprocessore, sono:
1) convertire il segnale ricevuto attraverso l'antenna in un formato MPEG-2 transport bit-stream,
2) se necessario, verificare i diritti dell'utente con il sistema di Accesso Condizionato e decodificare il flusso di bits dopo aver decrittografato le chiavi di protezione,
3) estrarre dal transport bit-stream i flussi audio, video e dati,
4) ricodificarli per renderli compatibili con il sistema analogico in uso.
Si tenga presente che, a partire dai requisiti minimi richiesti dallo standard, adattati ai mercati nazionali, è possibile realizzare diverse combinazioni degli elementi qui di seguito descritti.
Figura 4.2: Architettura Hardware del Set Top Box
In base alla descrizione funzionale, possiamo distinguere nell'architettura hardware di un STB, i seguenti principali componenti:
il Front-end, composto da un Sintonizzatore, un Convertitore Analogico/Digitale, un Demodulatore, un modulo per il controllo dell'errore (FEC)
il Demultiplexer
il Descrambler, opzionale, interagente col Demultiplexer
i Decodificatori per Video, Audio e Dati
l'Unità di controllo, composta da un Microprocessore, un Bootloader, le memorie ROM, RAM e Flash
un Processore Grafico, opzionale, con memoria RAM Video
i Codificatori Audio e Video per l'output dei segnali
le interfacce standard, come ad esempio SCART e PAL
le interfacce opzionali, come la Common Interface per l'accesso condizionato, il lettore di Smart Card, il Modem o un'interfaccia Ethernet.
Il front-end è il modulo dedicato alla ricezione e demodulazione del segnale digitale broadcast. La sua prima componente è il Sintonizzatore, che si occupa di ricercare in modo automatico ogni segnale presente all'interno dell'intervallo di frequenze disponibili e di riconoscere la modalità trasmissiva (modulazione, symbol rate e correzione di errore). Le frequenze su cui deve operare sono quelle centrali della banda III VHF a 7 Mhz e delle bande IV e V UHF a 8 Mhz. Nel caso non siano già disponibili i dati relativi alla sintonia di un particolare canale richiesto dall'utente, il sintonizzatore riceve dalle tabelle PSI/SI le informazioni che gli consentono di posizionarsi correttamente su di esso.
Figura
4.3: Front-End STB
Il front-end del STB terrestre è dotato di un connettore di ingresso di tipo femmina per il sintonizzatore, conforme con lo standard IEC 60169-2, come indicato nella figura 4.3. Deve essere presente inoltre un by-pass RF analogico che deve funzionare anche in stato di stand-by.
Il Convertitore A/D trasforma il segnale ricevuto da analogico a digitale ed il Demodulatore ne estrae il flusso modulato di bit. Infine, il componente dedicato alla correzione dell'errore, chiamato FEC (Forward Error Correction), corregge gli errori eventualmente verificatisi nel corso della trasmissione. Come risultato, viene rilasciato un pacchetto di dati digitalizzati, sotto forma di transport bit-stream.
Da osservare, che, in un contesto di trasmissione di flussi di dati digitalizzati, i termini modulatore e demodulatore non corrispondono a traslazioni in frequenza, ma indicano, rispettivamente, un generatore di forme d'onda "modulate dai dati" per la fase di trasmissione, ed un elaboratore del segnale ricevuto, per quella di ricezione. Il demodulatore del STB deve essere conforme alla normativa sulla modulazione e la codifica del segnale per la trasmissione terrestre EN 300 744 [1] e TR 101 190 [6], basata su COFDM.
Si può fare un'altra interessante osservazione, a proposito del front-end: la sua semplice sostituzione permette al STB la piena compatibilità con gli standard di trasmissione via cavo (DVB-C) e satellitare (DVB-S).
Il Demultiplexer, ricevuti i pacchetti TS dal Front-end, ricompone i flussi relativi ai programmi ed effettua la sincronizzazione dei flussi audio e video secondo la codifica di trasporto MPEG-2. Utilizzando le tabelle PSI e DVB-SI, a seconda dei servizi richiesti dall'utente, seleziona tramite gli appositi identificatori gli Elementary Streams necessari, definiti in EN 301 192, e li invia alle rispettive unità di decodifica video, audio e dati. Quando è presente anche un sistema di Accesso Condizionato, il Demultiplexer collabora strettamente con il Descrambler, inviandogli i TS da decodificare e ricevendone in cambio una versione “in chiaro” su cui operare. La selezione dei Transport Streams da inviare al descrambler viene fatta interpretandone il descrittore CA, come definito in ETR 289 [10].
Il Descrambler è l’unità incaricata, quando necessario, della decodifica del segnale precedentemente oscurato alla sorgente tramite l’algoritmo standard DVB, il Common Scrambling Algorithm (CSA). Le specifiche della procedura di descrambling e dell'algoritmo, per palesi motivi di sicurezza, vengono fornite dallo European Telecommunications Standards Institute (ETSI) solo dopo la sottoscrizione di un accordo di riservatezza. Requisito minimo richiesto è che il Set Top Box sia in grado di processare in parallelo almeno sei differenti flussi con differenti sistemi di accesso condizionato, sia a livello di trasporto (TS), sia in formato PES. Il decoder deve essere anche dotato di un by-pass, che permetta di oltrepassare l’unità di decodifica a quei flussi di dati che non abbiano necessità.
Il decodificatore video deve rispettare le linee guida fornite dalle specificazioni dei documenti ETR 154 [11], con riferimento agli standard ISO/IEC 13818 1 [4], ISO/IEC 13818 2 [12], ETS 300 468 [13], ETR 211 [14], ETS 300 294 [15] ed essere conforme a MPEG 2 MainProfile@MainLevel (MP@ML). Il codec video deve soddisfare alcuni requisiti minimi:
risoluzioni (riferite ai pixel di luminanza) di: 720x576, 544x576, 480x576, 352x576 o 352x288, rappresentabili, sulle uscite video analogiche, anche a pieno schermo (fullscreen), come descritto in ETR154 [11].
formato immagini video 4:3 e 16:9 (aspect ratio information)
supporto del formato MPEG-1
Il decodificatore audio deve rispettare le linee guida fornite dalle specificazioni dei documenti ETR 154 [11], con riferimento agli standard ISO/IEC 13818-3 [16]. In particolare devono essere soddisfatti i seguenti requisiti:
Supporto di MPEG 2 layer I e II, III opzionale, ma è raccomandata l’estrazione di almeno una coppia di canali stereo MPEG-2 ed il supporto per MP3.
Supporto delle velocità di campionamento 32 kHz , 44.1 kHz, 48 kHz e opzionalmente, 16 kHz, 22.05 e 24 kHz.
Per il sincronismo audio-video, almeno un decoder audio dovrà rispettare i requisiti di decodifica specificati in ETR 154 [11], il ritardo relativo introdotto dal decoder fra segnali audio e video non dovrà superare i 5 ms ed i livelli di set-up dovranno risultare in linea con ETR 154.
La configurazione dell’unità di controllo richiama quella di un personal computer: una CPU, un bootloader, alcune memorie diverse tra loro per formato e destinazione d'uso, un processore grafico per le funzionalità più avanzate ed un insieme di porte logiche di I/O. La CPU si occupa di inizializzare e gestire le diverse componenti del STB e di eseguire le applicazioni TV interattive. Il bootloader, residente nel firmware, ha invece il compito di caricare il sistema operativo, i drivers, le applicazioni ed i loro aggiornamenti attraverso: il canale broadcast, il canale interattivo, un modulo connesso alla Common Interface o una qualsiasi tra le interfacce dati presenti. Per impedire il caricamento di software non certificato, il bootloader utilizza un protocollo di sicurezza basato su un meccanismo crittografico asimmetrico, utilizzando le chiavi pubbliche memorizzate sul STB.
Come abbiamo visto, le memorie utilizzate differiscono tra loro per taluni aspetti: mentre le memorie ROM (Read-Only Memory) mantengono l'informazione al momento dello spegnimento del sistema, ma non vengono riscritte, accade l'opposto per le RAM (Random Access Memory), che non forniscono memoria permanente. Per superare questa dicotomia, si utilizzano delle memorie ROM riprogrammabili elettricamente (EPROM), alla cui categoria appartengono anche le memorie Flash impiegate nei Set Top Box. Queste ultime, in particolare, offrendo il vantaggio aggiuntivo di una riscrittura “a blocchi” invece che “byte a byte”, sono impiegate per il software di sistema operativo e dei servizi residenti, di cui possono consentire l'aggiornamento. In materia di memoria, le indicazioni date dal D-Book sono:
almeno 16 Mbytes liberi (raccomandati 24) di memoria SDRAM (Synchronous Dynamic RAM), per eventuali applicazioni MHP,
2 Mbytes di memoria Flash liberi, condivisi tra tutti i broadcasters, al netto di un eventuale sistema di sicurezza MHP.
Una possibile configurazione dell’unità di controllo del Set Top Box potrebbe quindi essere: 16-32 Mbytes di RAM, 8-16 Mbytes di memoria Flash e 4-8 Mbytes di video RAM. Tra le funzionalità che un STB deve offrire, vi sono inoltre: un orologio ed un calendario (opzionale), in tempo reale, aggiornati via Service Information (SI) e, possibilmente, un timer per il controllo automatico di accensione e spegnimento.
Un codificatore Audio per il suono stereofonico è attualmente un convertitore digitale/analogico, ma non è necessario in quei sistemi che supportano già il segnale digitale. Un codificatore Video è invece più complesso, a causa della necessità di conversione anche del formato, da Y/Cr/Cb a RGB per il formato PAL.
Il Set Top Box deve essere in grado di gestire funzionalità grafiche per il proprio controllo tramite on-screen-display (OSD) e per il navigatore di base guidato dalle informazioni DVB-SI. La funzionalità estesa deve essere in grado di gestire opzioni grafiche avanzate e la visualizzazione del segnale OSD. Viene raccomandato inoltre che il segnale OSD sia disponibile sull'uscita PAL, ove presente. Il STB deve inoltre soddisfare i seguenti requisiti minimi:
risoluzione 720x576 con aspect ratio 16:9 e 4:3
supporto simultaneo di grafica, video e still pictures
supporto della sottotitolazione DVB (ETSI 300 743 [17]).
256 colori più trasparenza, con modo di presentazione specificato dalle API.
Con lo standard ETSI TS-102-201-V1.2.1 [18] sono state ridefinite le caratteristiche minime delle interfacce, anche opzionali, di un STB:
connettore input: IEC 60169-2 femmina, 75 ohm
connettore output (pass-through): IEC 60169-2 maschio, 75 ohm
secondo EN 50049-1 e EN 50157-2-1
RGB (possibile anche Y/C se necessario)
CVBS: PAL out
output audio
A/V Control Pin 8
CVBS: PAL out
output audio
Y-C (super VHS)
disponibile all'uscita SCART
uscita audio secondo IEC4B(Sec)316
RS232 C secondo EN 50221 - connettore maschio a 9 pin
RS232 D secondo EN 50221 - connettore femmina a 9 pin (opzionale)
ITU-T V.90 "A digital modem and analogue modem pair for use on the Public Switched Telephone Network (PSTN) at data signalling rates of up to 56000 bit/s downstream and up to 33600 bit/s upstream" – ITU-T V.92 fornisce un miglioramento prestazionale ed è consigliato.
ITU-T V.42 "Error-correcting procedures for DCEs using asynchronous - to - synchronous conversion" - (correzione errori)
ITU-T V.42bis "Data compression procedures for Data Circuit-terminating Equipment (DCE) using error correction procedures" - (compressione dati)
supporto DTMF (Dual Tone Multi-Frequency), PABX, carrier selection
connettore RJ-11
porta ANSI/IEA RS232 – 9 PIN (solo per modem esterno)
omologazione del Ministero delle Telecomunicazioni, necessaria per il connettore alla linea nazionale
slot per SIM a tecnologia GSM – atto a fornire un canale interattivo mobile via GSM (EN 301 195 [19]) o via GPRS (TS 101 113 [20])
può essere interno o esterno al Set Top Box
l'inserimento della SIM card non deve comportare l'apertura del decoder
connettore per canale interattivo fisso di tipo RJ 45
Interfaccia FireWire IEEE 1394, MPEG-2 compatibile secondo le specificazioni IEC 61883.
Common Interface secondo EN 50221 [21], TS 101 699 [22] e ETSI R206-001 [23]
PC cards di tipo I e II (il tipo III è opzionale)
caratteristiche meccaniche del modulo, come da figura 4.4
Figura 4.4: Modulo per Common Interface - Linee guida realizzative
secondo lo standard ISO 7816 parte 1-3 [24] e ETSI R206-001 [23]
supporto delle carte sincrone (facoltativo)
fino a 16 sessioni per ogni istanza della risorsa, ma una sola “connessa”
le sessioni “non connesse” possono solo leggere le informazioni riguardanti lo stato della carta e del lettore
L'architettura software di un Set Top Box può essere rappresentata con uno stack a livelli, i cui elementi principali sono: 1) i drivers dei dispositivi hardware, 2) il software di sistema operativo, 3) le applicazioni residenti ed il middleware di supporto alle applicazioni, 4) le applicazioni esterne (Fig. 4.5).
Tutti i livelli più bassi sono concettualmente accorpabili in un unico blocco, rappresentante il software residente del sistema al momento del set-up del STB, mentre il livello superiore rappresenta l'insieme delle applicazioni esterne caricate su di esso successivamente al set-up.
|
Applicazioni di servizio (scaricabili e aggiornabili) | |
| Livello API del Middleware | |
| Applicazioni residenti | Middleware |
| Livello API del Sistema Operativo | |
|
Sistema Operativo (Real-time) | |
| Livello di astrazione hardware | |
|
Drivers dei dispositivi hardware | |
Il software residente fornisce due classi di funzioni: una dedicata alla gestione interna di hardware, firmware e servizi di base (i.e. Navigatore e Teletext) e l'altra di supporto alle applicazioni esterne, perché possano, attraverso l'interfaccia API, avere accesso alle risorse del STB.
Seguendo lo schema dello stack, al livello più basso troviamo i drivers, che convertono i comandi di una particolare unità hardware in un insieme di comandi comprensibili dal sistema operativo. I drivers consentono quindi l'utilizzo dei singoli dispositivi hardware da parte del sistema operativo del STB.
Tra questi due strati, viene qui evidenziata un'ulteriore interfaccia logica, la Hardware Abstraction Layer (HAL), la cui finalità immediata è di governo della comunicazione tra le parti. In generale, un buon disegno di questo livello di astrazione può garantire ai produttori di sistemi operativi il funzionamento su hardware differenti, mentre una particolare attenzione allo stesso da parte dei produttori di STB consente agli stessi di non dotarsi di un sistema operativo proprietario. Vedremo in seguito come anche la piattaforma middleware DVB MHP abbia affrontato l'impiego della HAL.
Il sistema operativo gestisce tutte le risorse hardware, che rende disponibili alle applicazioni attraverso un insieme di API. Nonostante la somiglianza con l'architettura di un personal computer, un STB deve corrispondere a dei requisiti che sono essenziali per la tipologia di mercato cui si rivolge la televisione digitale terrestre: velocità ed affidabilità. L'utente televisivo non deve percepire fastidiosi ritardi in risposta alle proprie richieste e nemmeno accorgersi di situazioni di errore o di blocco durante l'esecuzione delle stesse, che devono pertanto essere gestite direttamente dal sistema. Per quanto detto, il sistema operativo utilizzato è solitamente un sistema di tipo Real-Time (RTOS), che offre esattamente queste capacità. In linea generale, anche il sistema operativo fornisce un set di API proprietarie che possono essere impiegate dagli sviluppatori di applicazioni che intendono utilizzarne direttamente le funzioni.
Al livello immediatamente superiore dello stack abbiamo le applicazioni residenti ed il middleware. Tra le applicazioni residenti troviamo il Navigatore ed il Teletext di base. Il navigatore interpreta le tabelle ed i descrittori secondo la normativa DVB SI (ETS 300 468) [13] e fornisce la lista dei servizi presenti su tutti i canali accessibili e tutte le informazioni riguardanti la programmazione, consentendo all’utente di configurare e di controllare la sintonia del STB. Il produttore del STB ne fornisce una versione comprendente tutte le funzionalità di base, di cui cura anche l'aspetto grafico. Il ricevitore provvede anche all'interpretazione delle informazioni destinate al Teletext (ETS 300 472 [26]), visualizzandole tramite funzioni grafiche, o reinserendole all’interno delle righe del Vertical Blanking Interval (VBI) nel segnale analogico in uscita, secondo la tecnologia utilizzata per il teletext nel televisore analogico.
Il middleware del Set Top Box è quello strato software che permette alle applicazioni esterne di utilizzare le risorse disponibili. Questo livello di astrazione consente alle applicazioni di non doversi preoccupare di conoscere il sistema in dettaglio, riducendo notevolmente la complessità del loro sviluppo. Il middleware standard progettato dal consorzio DVB è la piattaforma Multimedia Home Platform (MHP 1.1.1) [27], che fornisce alle applicazioni esterne l'insieme di API attraverso cui interagire con le risorse del STB.
Le applicazioni esterne possono generare un'innumerevole quantità di servizi interattivi e possono quindi rappresentare una delle più importanti novità percepite dall'utente. Si possono citare come esempi il super-teletext e l'EPG, ma anche la posta elettronica, i giochi, il commercio elettronico e le transazioni bancarie, il Video on Demand ed il Near Video on Demand, la registrazione digitale con PVR e tutti i servizi della Pubblica Amministrazione che rientrano nel progetto di T-Government.
I profili definiti da MHP definiscono in crescendo le funzionalità utilizzabili dalle applicazioni (Fig.4.6); questa suddivisione fa sì che chi sviluppa soluzioni software possa indicare esattamente a quale classe di STB siano rivolte. È previsto che il numero di profili oggi esistenti possano aumentare e che degli stessi possano essere rilasciate versioni superiori. Il criterio di fondo, da tenere ben presente nelle valutazioni di un STB, è che ogni profilo superiore, od ogni suo nuovo livello dello s, rimangano compatibili con i precedenti, mantenendone le funzionalità originarie.
Figura 4.6: Aree Applicative e Livelli dei Profili MHP
Le caratteristiche di interattività del primo profilo definito, l'Enhanced Broadcast [28], risultano limitate alle applicazioni residenti ed a quelle ricevute secondo le modalità di trasporto broadcast, con una comunicazione, quindi, di tipo unidirezionale. L'interattività è perciò solo locale e si concretizza prevalentemente attraverso l'uso di un telecomando (o altro apparato analogo). L'utente può così attivare programmi accessori, come l'EPG, il Teletext avanzato, servizi di news e giochi, navigare sullo schermo TV ed interrogarli, ottenendo risposte in forma di immagini, video ed informazioni. I protocolli di trasporto disponibili per la trasmissione broadcast, sono le Sezioni MPEG-2 ed il DSM-CC User-to-User Object Carousel, mentre è considerato opzionale lo stack IP Multicast. I protocolli di trasporto saranno descritti più avanti, in questo stesso capitolo. Poiché la prima realizzazione di MHP aveva tra i suoi principali obiettivi anche quello di fornire un supporto alle applicazioni software non native, già nel primo profilo fu prevista la possibilità di impiego di specifici plug-in.
Il profilo Interactive Broadcast [28] mantiene inalterato l'insieme dei protocolli di trasporto broadcast del profilo precedente, ma viene consigliata l'adozione del supporto Java allo stack IP Multicast. La differenza sostanziale riguarda invece l'interattività, che questa volta prevede un canale di ritorno bidirezionale per la comunicazione tra l'utente ed il broadcaster. Tra i protocolli da utilizzare troviamo HTTP, lo stack TCP/IP ed un ibrido tra la trasmissione broadcast ed il canale interattivo, DSM-CC e HTTP. Viene aggiunto, anche se in forma opzionale, un insieme di protocolli della famiglia DSM-CC, così come vengono inseriti anche i packages delle API Java necessari all'impiego del canale di ritorno ed alla sua sicurezza. Per quanto riguarda le applicazioni, viene introdotto un nuovo standard, DVB-HTML, con l'obiettivo di aumentare l'affinità tra il mondo Web e la TV interattiva, in grado di realizzare un'interfaccia ipertestuale paragonabile ad un “super teletext”. In tal senso viene specificato un supporto Java in grado di inserire Xlets in pagine DVB-HTML di applicazioni DVB-HTML, valido per tutti e tre i profili.
Il profilo Internet Access [27] fornisce un'interattività completa con il mondo Internet grazie alla definizione delle interfacce dalla piattaforma DVB-Java alle applicazioni client Internet. Nei protocolli broadcast diventa mandataria la presenza dello stack IP Multicast, così come, sul lato del STB, quella dei packages di API Java corrispondenti, che si sommano a quelli già presenti per la gestione della comunicazione sul canale di ritorno e la sua sicurezza. Viene inoltre inserito un supporto Java e DVB HTML specifico per l'accesso a Internet, che permette ora di accedere a diversi servizi: navigare con un browser Web, inviare posta elettronica, partecipare a newsgroup tramite Usenet. Il lettore di smart card diventa, con questo profilo e la versione 1.1.2 di MHP, non ancora rilasciata, ma comunemente accettata, uno strumento adatto a lanciare i primi servizi di T-Government ed i futuri servizi bancari e di commercio elettronico, sfruttando appieno l'esperienza maturata nel campo della sicurezza su Internet. Non solo, l'uso del canale internet può offrire la possibilità di scaricare nuove applicazioni, giochi, informazioni, non solo dal broadcaster televisivo, ma anche da un Interactive Service Provider (ISP), non esattamente un Internet Service Provider, anche se i ruoli sono destinati a coincidere. L'ISP cui si fa riferimento in questo contesto è l'interfaccia verso il broadcaster ed è uno dei nuovi attori in gioco in questo contesto.
L'architettura MHP è rappresentabile con uno stack a tre livelli, composto dalle risorse, dal software di sistema e dalle applicazioni (Fig. 4.8). Riprendendo il discorso sull'architettura di un generico Set Top Box ricordiamo, tra le risorse, gli apparati per il processo di stream MPEG-2, i devices di I/O, la CPU e le memorie.
Figura 4.8: Architettura MHP
Il software di sistema fornisce una visione astratta delle risorse alle applicazioni, isolandole dall'hardware e garantendone in questo modo la portabilità. Sempre nel software di sistema troviamo la Java Virtual Machine (JVM), il cui compito primario è la traduzione delle istruzioni dal formato Java bytecode al codice macchina. I bytecodes possono anche non risiedere in modo permanente nel STB ma, grazie alle loro ridotte dimensioni, possono essere scaricati quando necessario e rimossi al termine dell'esecuzione dal meccanismo di garbage collection della JVM. La gestione del ciclo di vita di tutte le applicazioni MHP, non solo quelle DVB-J, è demandata all'Application Manager, sulla base delle informazioni di segnalazione contenute nei Transport Streams MPEG-2. L'Application Manager è definito anche “Navigatore”.
I Plug-in rappresentano degli insiemi di funzionalità che possono essere aggiunte a quelle della piattaforma per interpretare i formati di applicazioni e contenuti non specificati direttamente da DVB-MHP [27].
Figura 4.9:Tipologie di Plug-in
Esistono due versioni possibili di plug-in, evidenziati nella figura 4.9:
I plug-in che sono anche applicazioni MHP e che svolgono funzioni specifiche per altre applicazioni, sono definiti plug-in interoperabili e considerati di tipo “A”. Possono essere forniti da qualunque fonte.
I plug-in che utilizzano codice realizzativo specifico, ad esempio un codice nativo oppure un'implementazione particolare delle API Java, sono chiamati Plug-in dipendenti dalla specifica realizzazione (implementation-specific plug-in). Lavorano direttamente con le risorse del STB e per questo motivo devono essere forniti dai produttori degli stessi. Appartengono alla categoria “B” dei plug-in [27].
Poiché insieme ai normali servizi audio/video possono essere inviate dal fornitore dei servizi anche altre informazioni, di qualunque natura, è necessario che vi siano dei protocolli di trasporto e comunicazione che lo consentano e con la massima sicurezza possibile. Per lo stesso principio, laddove venga realizzata un'interazione tra l'utente ed il provider, devono essere forniti protocolli che realizzino la comunicazione indipendentemente dalla natura del mezzo trasmissivo con cui viene realizzata.
I protocolli utilizzati dalla piattaforma MHP sono stati definiti sulla base dei meccanismi e protocolli standard ISO MPEG 2-Parte 6 DSM CC [30], opportunamente integrati da API DVB. Grazie al sistema di incapsulamento di pacchetti di protocolli in apposite strutture dati, noto come Multiprotocol Encapsulation (MPE), sono in grado di fornire supporto ad Internet Protocol (IP), sia sul canale di interazione che broadcast.
Le configurazioni che la rete di comunicazione può assumere sono due: un canale di downstream dal service provider all’utente finale, o la combinazione di un canale di downstream con un canale di ritorno. Le due configurazioni corrispondono ad un sistema di soli servizi broadcast ad interattività locale e ad un sistema di servizi broadcast interattivi che si appoggiano ad un canale di ritorno per comunicare con il fornitore del servizio.
Vediamo ora quali sono i protocolli ed i meccanismi utilizzati per la comunicazione ed il trasporto delle informazioni, distinguendoli per tipologia di canale. La sicurezza della comunicazione mono e bi-direzionale verrà trattata nel capitolo sulla sicurezza dell'intero sistema di broadcasting interattivo, mentre i protocolli DSM-CC e quelli legati ai particolari canali di interazione vengono affrontati in due paragrafi specifici del presente capitolo.
La tecnologia DVB consente una trasmissione multicast di grandi quantità di dati ad alta velocità. Questi dati possono appartenere a differenti tipologie e richiedere metodi di trasporto diversi. Per esemplificare le differenze di tipologia possiamo citare gli aggiornamenti del firmware, i dati testuali, le immagini, i servizi Internet (IP tunneling) e le applicazioni software. Al fine di consentire una corretta trasmissione, con una eventuale, quando necessaria, ripetizione ad intervalli predefiniti, vengono classificate alcune aree tipologiche di dati, corrispondenti ad altrettanti profili broadcast [31].
Data Piping: supporta i servizi che richiedono un rilascio dei dati in modo asincrono, di tipo end-to-end, e trasferisce i dati all'interno del payload dei Transport Streams.
Data Streaming: supporta quei servizi che richiedono un rilascio dei dati di tipo end-to-end ed orientato allo streaming di dati, in modo sincrono, asincrono o sincronizzato, a seconda che necessitino o meno dei requisiti di temporizzazione. Il trasporto avviene all'interno dei pacchetti PES.
Multiprotocol Encapsulation (MPE): supporta quei servizi che richiedono il trasporto di datagrams di un protocollo di trasmissione, ad esempio l'IP Datacasting con cui si virtualizza una comunicazione Internet multicast unidirezionale. Il trasporto avviene incapsulando i datagrams nelle Sezioni specificate per il DSM-CC Data Carousel, conformi alle Sezioni Private MPEG 2. MPE supporta anche un meccanismo standard di segnalazione per i servizi Internet Protocol / Media Access Control (IP/MAC) su network DVB che consente la realizzazione di ricevitori in grado di auto-sintonizzarsi al rilevamento di flussi IP/MAC all'interno dei Transport Streams. Il meccanismo di segnalazione utilizza una apposita tabella, la IP/MAC Notification Table (INT).
Data Carousels: supportano quei servizi che richiedono la trasmissione periodica di moduli di dati con dimensione nota. Questi moduli possono poi essere, nel tempo, aggiornati, aggiunti o rimossi dal carosello e, se richiesto dal servizio, accorpati in Gruppi, i quali a loro volta possono essere aggregati in Super-Gruppi. I dati vengono trasportati all'interno di un DSM-CC Data Carousel conforme allo standard MPEG-2 DSM-CC, accompagnato da descrittori e strutture specifici per reti DVB. Il metodo è realizzato in modo che non vi sia nessun riferimento esplicito ai parametri identificativi (PIDs) e di sincronizzazione, permettendo così una preparazione off-line del contenuto.
Object Carousels: supportano quei servizi che richiedono la trasmissione periodica di DSM-CC User-User (U-U) Objects, come definito dallo standard DVB Systems for Interactive Services (SIS) (ETS 300 802 [43]). La trasmissione dei dati viene effettuata secondo le specifiche MPEG-2 all'interno di un DSM-CC Data Carousel conforme allo standard MPEG-2 DSM-CC Data Carousel e DSM-CC Data Objects (ISO/IEC 13818-6 [30]).
Protocolli di livello superiore basati su flussi di dati asincroni: questa specificazione supporta la trasmissione di protocolli che richiedono un rilascio orientato al flusso di dati asincroni. Il trasporto di questi blocchi di dati avviene all'interno di pacchetti PES.
Lo stack di protocolli del canale broadcast rappresentato dalla figura 4.10 evidenzia l'insieme dei protocolli accessibili dalle applicazioni MHP, in funzione del proprio profilo di riferimento.
Figura 4.10: Stack di protocolli del canale broadcast
I protocolli utilizzati, in parte adottati da altri standard ed in parte proprietari, sono:
MPEG-2 Transport Streams, Private Sections, DSM-CC Data Carousels
DSM-CC User-to-User Object Carousel (con le restrizioni definite in ETSI EN 301 192 [31] e TR 101 202 [32]
DSM-CC Private Data
DVB Multiprotocol Encapsulation [31], basato sul protocollo DSM-CC Private Data.
DVB Service Information [33] [14]
IP Signaling [33] [14]
Internet Protocol (IP)
User Datagram Protocol (UDP)
Nel seguito del capitolo vengono ripresi e sviluppati i componenti più interessanti sotto il profilo del trasporto di dati, applicazioni e protocolli embedded: DSM-CC Data Carousels, Object Carousels e User to User Object Carousel.
Le applicazioni MHP interattive di profilo superiore, Internet Access ed Enhanced Broadcast, necessitano di comunicare con il mondo esterno utilizzando un canale di ritorno. Lo stack di protocolli del canale di interazione, rappresentato dalla figura 4.11, definisce l'insieme dei protocolli accessibili da tale categoria di applicazioni MHP.
I protocolli definiti per il canale di ritorno sono raggruppati in due insiemi distinti: quelli dipendenti dal mezzo fisico della comunicazione e quelli indipendenti dal medesimo. Questo livello di astrazione favorisce la realizzazione della comunicazione, consentendo l'adozione nel tempo di nuovi mezzi trasmissivi senza che ciò incida sul livello di protocolli indipendenti dalla rete sottostante.
La documentazione tecnica riguardante il canale interattivo comprende diverse specificazioni per i protocolli che dipendono dall'infrastruttura di rete (i.e. ETS 300 801 per PSTN/ISDN [34]), chiamati protocolli dipendenti dalla rete, e due documenti specifici per i protocolli indipendenti, ETS 300 802 [43] e TR 101 194 [35], che trattano i principali requisiti DVB che consentono di abilitare i servizi interattivi ed i modi in cui realizzarli. Gli standard DVB per le specifiche reti di comunicazione (PSTN/ISDN, GSM, etc.) e i meccanismi di trasporto (DSM-CC), verranno trattati nel seguito del capitolo.
Figura 4.10: Stack di protocolli del canale broadcast
I Network Independent Protocols (DVB-NIP) derivano dallo standard DAVIC e ciò ha fatto sì che anche la terminologia e la logica DVB risultassero un'eredità specifica dello stesso. La più significativa tra esse riguarda il raggruppamento in cinque canali logici, denominati da S1 ad S5, di tutte le possibili combinazioni di interazione tra l'utente ed il broadcaster, le differenti tipologie di dati, tra cui i diversi dati di controllo, ed i protocolli di comunicazione utilizzati. Anche gli stacks di protocolli vengono perciò presentati nello standard secondo questa logica e risulterebbe fuorviante riportarli nel contesto di questo lavoro. In sintesi, i protocolli utilizzati per realizzare l'interazione attraverso un canale di ritorno, in parte adottati da altri standard, ed in parte sviluppati da DVB come adeguamento agli stessi, sono:
Internet Protocol (IP)
Transmission Control Protocol (TCP)
User Datagram Protocol (UDP)
Point-to-Point Protocol (PPP) e Multilink Point-to-Point Protocol (MP)
Simple Network Management Protocol (SNMP)
PPP Internet Protocol Control Protocol (IPCP)
Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP)
Digital Storage Media - Command and Control (DSM-CC)
DCM-CC User to User
DCM-CC User to User object carousel
DCM-CC download
DCM-CC User compatibility
Universal Networked Object – Remote Procedure Call (UNO-RPC)
Universal Networked Object-Common Data Representation(UNO-CDR)
Specifici del Servizio – Sono quei protocolli proprietari utilizzati da un particolare servizio, secondo le specifiche indicate nelle linee guida per il broadcasting di dati [32]; per questo tipo di protocolli, DVB fornisce un meccanismo di registrazione.
Protocolli di risoluzione dei nomi tramite DNS - Nota: se gli indirizzi dei Server DNS vengono forniti sia dalla rete che dall'applicazione, hanno precedenza quelli forniti dalla rete.
Il sistema di distribuzione delle applicazioni MHP agli utenti viene realizzata per mezzo di una particolare tecnologia dello standard MPEG-2, il Digital Storage Media - Command and Control (DSM-CC) [30], in funzione del quale DVB ha realizzato delle apposite interfacce software di integrazione con il sistema di broadcasting interattivo. La funzionalità di base del DSM-CC è la gestione di flussi di dati in formato MPEG bit-stream, per i quali fornisce strumenti e protocolli atti ad operarvi. La sua funzionalità originaria è quella di sistema di memorizzazione di video digitali, con funzionalità tipiche di un Video Cassette Recorder (VCR), avanzamento veloce, riavvolgimento, pausa e posizionamento, ma lo sviluppo successivo lo ha portato al controllo di server video MPEG ed al broadcasting di dati di qualunque tipo.
Poiché in un modello broadcast unidirezionale l'utente non può accedere direttamente ai dati di proprio interesse, ma deve attenderne l'invio da parte del broadcaster, il sistema adottato è quello di una ripetizione continua e ciclica dell'invio delle informazioni, denominato carosello. DSM-CC fornisce questa funzionalità per mezzo dei Data Carousels ed Object Carousels. Un esempio della logica di un carosello è fornito dal servizio Teletext, per il quale la richiesta di una pagina informativa comporta un'attesa, anche se a volte non percepita, del successivo invio da parte del broadcaster. Il sistema di invio periodico di dati sotto forma di carosello consente anche di variarne la frequenza relativa al proprio interno: per rimanere sull'esempio del Teletext, le pagine considerate più importanti potranno essere inserite più volte di altre all'interno dello stesso carosello, in modo che l'attesa dell'utente risulti minore.
L'adozione del DSM-CC all'interno di un sistema broadcast di televisione digitale interattiva, assume però un ben più ampio significato. Le informazioni che possono essere trasportate sulla rete, insieme al flusso audio video ed invisibili ad esso, sono intere applicazioni software, strutture dati, pacchetti di protocolli di comunicazione e quant'altro si ritenga utile. Non solo, alcune delle principali funzioni supportate riguardano il download dei dati, l'accesso a files remoti, la verifica della compatibilità tra i servizi da inviare e la configurazione di sistema del STB, la gestione degli eventi indicati da segnalatori negli streams audio/video, oltre ad una consistente e non ambigua temporizzazione degli stessi.
I due strumenti utilizzati, Data Carousel ed Object Carousel, differiscono tra loro essenzialmente nell'identificazione degli oggetti trasportati: il primo non se ne occupa, mentre il secondo fornisce le informazioni e gli strumenti necessari alla loro gestione. Va specificato però che l'Object Carousel è stato costruito sopra il Data Carousel e ne costituisce un'estensione, il che significa che il sistema nel suo complesso utilizza le stesse strutture elementari. I Data Carousels vengono spesso utilizzati per aggiornare il software di sistema, mentre gli Object Carousels contengono solitamente applicativi software, ad esempio l'EPG, giochi, servizi commerciali etc.
Il Data Carousel trasporta quindi moduli di dati, di contenuto non specificato, verso il ricevitore, delegando al STB il compito della loro rielaborazione. Come già anticipato nel paragrafo sui protocolli di trasporto per il canale broadcast, i moduli di dati trasportati possono essere accorpati in Gruppi, che a loro volta possono essere aggregati in Super-Gruppi. I moduli stessi possono anche essere frazionati internamente in Blocchi. La presenza di un solo Gruppo oppure di più di uno aggregati in un Super-Gruppo comporta alcune variazioni legate ai messaggi utilizzati per il trasporto.
Figura 4.16: Struttura di un Data Carousel
Nei due differenti casi il relativo Data Carousel viene definito ad uno o due livelli, in riferimento al grado di indirettezza nella mappatura dei gruppi (Figura 4.16).
La struttura di un Object Carousel è invece simile ad un albero di directories, in cui gli oggetti vengono identificati da un elemento denominato Service Gateway, posto in cima alla gerarchia degli elementi (Figura 4.17). Gli oggetti contenuti possono essere files .txt .jpg o anche sowtare applicativo che utilizzerà tali oggetti. Gli oggetti raggruppati ed in relazione tra loro sono definiti un Service Domain. La struttura a directories permette al STB di ricostruire le applicazioni ed eseguirle utilizzando gli oggetti, dei quali conosce già l'esatta ubicazione.
Figura 4.17: Gerarchia di un Object Carousel
Vediamo ore come vengono utilizzati i protocolli per realizzare l'interattività del STB. Nel modello DSM-CC i dati vengono generati da un Server ed inviati ad un Client ed entrambi vengono considerati User del Network DSM-CC (Figura 4.18). Il modello di riferimento del sistema è composto da tre elementi, un User-client, un User-server ed un Network. Una delle sue funzionalità è la gestione e la negoziazione delle risorse, che gestisce attraverso Sessioni, a cui sono associate le risorse necessarie al rilascio del servizio. Il modello definisce un'entità logica chiamata Session and Resource Manager (SRM), che gestisce in modo centralizzato le sessioni e le risorse. La combinazione del SRM e della rete sottostante viene definita Network.
Figura 4.18: DSM-CC - Modello di riferimento
Il sistema di segnalazione tra il client ed il server è chiamata segnalazione User-to-User (UU). Il sistema di segnalazione tra il Client e SRM o tra il Server e SRM è chiamata segnalazione User-to-Network (UN). Nel contesto di servizi interattivi DVB, le comunicazioni e le negoziazioni con l'infrastruttura della rete non sono necessarie, perciò non vi è uso del protocollo UN, se non in casi particolari in cui sia richiesto un controllo della sessione.
Le parti rilevanti delle specificazioni DSM-CC, per quanto concerne i servizi interattivi, sono: User-to-User (UU), User-to-User (UU) Object Carousels, Download e User Compatibility.
Le primitive User-to-User consentono l'esecuzione di un grande numero di applicazioni multimediali grazie al sistema di distribuzione MPEG in ambienti eterogenei e forniscono l'accesso ad oggetti multimediali come streams e files. La parte U-U dello standard definisce due interfacce, la Application Portability Interface e la Client-Service Interoperability Interface. La prima (gateway di servizio; stream; file; directory) si applica sia ai servizi basati su un'interattività locale, sia a quelli con interattività di tipo unidirezionale e bidirezionale. Nel primo caso i dati sono inviati ripetutamente per mezzo del UU Object Carousel, nel secondo invece su richiesta, attraverso la Client-Service Interoperability Interface.
La Client-Service Interoperability Interface necessita dell'uso di Remote Procedure Calls (RPC) per richiedere le operazioni sulla rete. Gli standard DAVIC e DVB Interactive Services (IS) hanno optato per il protocollo Internet Inter-ORB Protocol (IIOP), dove ORB fa riferimento all'Object Request Broker, un meccanismo standard per l'interoperabilità tra Clients e Servers eterogenei.
Le API U-U, per motivi di interoperabilità sono strettamente vincolate alla Client-Service Interoperability Interface, per quanto concerne l'interattività, ma il loro impiego può anche essere quello di accesso ad oggetti locali o ricevuti via broadcast. Per realizzare ciò il Client deve realizzare localmente un sottoinsieme delle funzionalità del User-to-User. Poichè le API U-U non consentono di comunicare con il Server che fornisce gli oggetti, il Server dovrà inviare gli oggetti più importanti più frequentemente degli altri.
La trasmissione periodica di applicazioni in un Data Carousel è standardizzata in DSM-CC download protocol, in particolare l'uso dei moduli, il loro frazionamento e come rilevare problemi di coerenza causati dall'aggiornamento dei moduli stessi. In ogni modo, per garantire l'interoperabilità tra Clients e Broadcast Servers, è standardizzato anche il trasporto degli oggetti U-U nei Moduli e quello dei moduli nella rete broadcast.
Nelle reti Broadcast, un Server può comunicare con Clients con differenti architetture. Si rende perciò necessario avere un protocollo di rappresentazione che specifichi come gli oggetti U-U sono trattati. Come precedentemente descritto, i dati di tipo Object sono trasportati tramite il protocollo Internet Inter-ORB Protocol (IIOP) sulla cima dello stack TCP/IP. In IIOP, la rappresentazione a livello fisico è definita dal Common Data Representation (CDR) per rendere possibile uno scambio di oggetti tra ORB con differenti architetture. Al fine di evitare di avere due protocolli di rappresentazione differenti in Clients ibridi, anche U-U Object Carousels fa uso di CDR.
Tutte le ultime definizioni sono compatibili con il framework Object Request Broker (ORB) definito dallo standard Common Object Request Broker Architecture (CORBA). Per questo motivo è chiamato Broadcast Inter-ORB Protocol (BIOP).
La specificazione BIOP consiste di tre elementi:
La definizione del BIOP profile body, che fornisce un riferimento univoco ad un oggetto U-U nella rete Broadcast.
I formati del messaggio BIOP. BIOP è composto da quattro messaggi che condividono una comune struttura di messaggio. Questi messaggi sono convertiti a livello fisico per mezzo del Common Data Representation (CDR), come specificato da UNO. I messaggi BIOP convogliano, tra le altre cose, gli oggetti U-U.
Il trasporto del messaggio BIOP. I messaggi BIOP sono trasportati nei moduli del Data Carousels, che possono contenere messaggi BIOP multipli. I moduli sono frammentati in blocchi (come definito dal protocollo DSM-CC Download) e vengono trasferiti in Sezioni DSM CC.
Il protocollo DSM-CC Download trasferisce dati e software dal Server al Client, dividendo l'immagine in moduli ed i moduli in blocchi e può essere usato per realizzare i caroselli di dati con trasmissione periodica delle informazioni, allocate in moduli, al Client dal Server.. Il protocollo supporta diversi modelli di reti, tra cui il download a controllo di flusso e quello broadcast, per i quali utilizza lo stesso insieme di messaggi.
Il meccanismo per la realizzazione di caroselli di applicazioni viene convenzionalmente descritto con uno stack a tre livelli: il layer applicativo specifica il tipo di contenuto dei moduli, oggetti o altro, il Transport Layer il modo in cui i moduli vengono trasportati (i.e. DSMCC_sections in Transport Streams).
| Application layer |
| Data Carousel layer |
| Transport layer |
Figura 4.19: Stack realizzativo del carosello di applicazioni
A seconda del tipo di contenuto, i caroselli di dati sono suddivisi in:
caroselli ad immagine singola
caroselli ad immagine multipla
object carousels.
DSM-CC User Compatibility gestisce le compatibilità tra il STB ed il Server. Attraverso appositi descrittori, trasferisce un elenco delle interfacce (hardware e software) presenti sul STB al Server, in modo che questi possa decidere quali dati inviare.
La Client-Service Interoperability Interface necessita dell'uso di Remote Procedure Calls (RPC) per richiedere operazioni sulla rete. Inoltre, l'interoperabilità richiede una rappresentazione dei dati standard (il modo in cui i dati sono codificati a livello fisico) come pure un formato standard per fare riferimento agli oggetti. Nello standard DSM-CC, le specificazioni adottate, con queste tre caratteristiche, sono Universal Networked Objects (UNO) definiti in OMG (RFC 1717 [36]), che contiene anche Common Data Representation (CDR) e Interoperable Object Reference (IOR). Tutti insieme, formano il General Inter-ORB Protocol (GIOP). GIOP utilizza lo stack TCP/IP come transport layer per i messaggi. All'interno di UNO, la combinazione di GIOP e TCP/IP è denominata Internet Inter-ORB Protocol (IIOP). IIOP è specificato da DAVIC così come da DVB Interactive Services (IS).
Le applicazioni MHP assumono sul STB la forma di directories di files di programma associate a files di dati. Tutti i servizi che contengono un'applicazione, trasportano anche una tabella informativa, la Application Information Table (AIT), che riporta alcuni identificatori, tra cui i principali sono il nome dell'applicazione, l'azienda produttrice, la posizione dei files, i parametri di chiamata. La combinazione dell'identificatore dell'applicazione e di quello dell'azienda produttrice deve risultare univoca.
Nella figura 4.12 viene rappresentata l'architettura dell'ambiente applicativo, comprendente l'ambiente procedurale di DVB-Java e quello dichiarativo di DVB-HTML, gli elementi di comunicazione tra i due (Bridge) ed un Monitor per il controllo del ciclo di vita delle applicazioni.
Figura 4.12: Architettura di Sistema dell'ambiente applicativo
Con la versione 1.1 di MHP è stato introdotto un elemento di supporto al linguaggio HTML, lo standard DVB-HTML. La necessità di disporre di un linguaggio come HTML deriva innanzitutto dalla possibilità di accedere agevolmente ai contenuti di Internet, attraverso il canale di ritorno, e da quella, non meno importante, di unificare più facilmente il mondo Web, la televisione, gli apparati handheld e mobile, producendo contenuti pubblicabili sulle diverse piattaforme. Per realizzare questo processo, DVB-HTML si appoggia al linguaggio eXtensible Markup Language (XML), proprio grazie al quale viene resa possibile la creazione di documenti pubblicabili su apparati di differente tipologia. Le specifiche per DVB-HTML includono una versione modulare di XHTML, CSS, DOM Level2 ed ECMA Script, sui quali però, in questo lavoro, il discorso non verrà approfondito.
La piattaforma DVB-J offre un supporto per lo sviluppo di applicazioni DVB-Java e rappresenta il riferimento applicativo della piattaforma MHP. La scelta di operare con lo stack Java, basato sulla PersonalJava Specification adattata secondo le necessità della televisione, è motivata dalle sue caratteristiche di portabilità e di ottimizzazione, poiché grazie alla Java Virtual Machine (JVM) realizzata da Sun MicroSystems, può produrre codice multipiattaforma. Ultimamente, con l'avvento di Java to Micro Edition (J2ME), Sun ha ridefinito i profili standard in PersonalJava e Personal Basis Profiles. Grazie alla versione J2ME, introdotta con MHP 1.1.2, vengono ottimizzate ulteriormente le prestazioni estendendo la portabilità del codice agli apparati mobili di ridotte dimensioni ed a basso consumo energetico (PDA, cellulari, apparati handheld in generale). Uno specifico impiego di J2ME, e del Personal Basis Profile, verrà descritto nel capitolo sulla sicurezza del sistema, in relazione all'utilizzo delle API per la comunicazione con le Smart Cards.
Seguendo la filosofia di tutto lo sviluppo dello standard DVB, MHP ha adottato parti di standard già disponibili ed aperti, includendo, adattando e supportando insiemi di API differenti (Fig. 4.13).
Figura 4.13: Stack della piattaforma DVB-J
Le principali API standard adottate sono:
Java, di Sun MicroSystems, comprendente i packages:
Core Java, che contiene le API necessarie allo sviluppo di applicazioni, come ad esempio java.lang e java.util.
Java TV, per la gestione del ciclo di vita delle applicazioni
Home Audio/Video interoperability (HAVi), che fornisce un set dedicato all'interconnesione domestica tra apparati audio e video, aggiungendo componenti grafiche (widgets) come estensione a quelle dell'Abstract Windowing Toolkit (AWT) e fornendo uno strumento adatto all'interazione con le applicazioni.
Digital Audio Video Council (DAVIC), che svolge le più importanti attività concernenti il flusso di trasporto MPEG, dal tuning all'accesso condizionato.
DVB, che fornisce un insieme di funzionalità complementari a quelle sopra descritte, rendendo il tutto consistente (ad esempio la classe org.dvb.ui.DvbColor, che aggiunge un canale alpha (trasparenza) alla classe java.awt.Color, oppure la gestione delle informazioni trattate con DVB-SI, etc.).
Abbiamo visto precedentemente quali protocolli trasportino le informazioni riguardanti le applicazioni ed in quale modo e come ciò consenta di predisporre l'ambiente in cui ciascuna applicazione possa operare. Vediamo ora quali scenari si possano configurare.
Le specificazioni MHP al riguardo contemplano tre modalità di realizzazione di un file system: completamente attraverso il canale broadcast, solamente attraverso il canale di interazione oppure in modo ibrido, parzialmente attraverso il canale broadcast e completato da quello di interazione. In ognuno di questi scenari, comunque, viene inviato al ricevitore un percorso di ricerca contenente una lista di indirizzi e utilizzato per localizzare quei files che possano in seguito essere specificati da percorsi incompleti. Gli elementi di questa lista sono referenziati sia da file compressi (di tipo .zip o .jar), sia da URL base ai quali è poi concatenato il percorso del file richiesto.
Talvolta, i caroselli che trasportano i dati dell’applicazione possono andar persi o risultare inaccessibili, nel qual caso, in presenza di una memoria cache, il sistema può continuare a fornire i dati memorizzati nella stessa, in attesa di un ripristino dello stato operativo.
Nello scenario ibrido, tutte le directories del file system vengono trasmesse sul canale broadcast, mentre i files (alcuni o tutti) sono inviati sul canale interattivo. Le due modalità vengono definite:
Broadcast file delivery: in cui i files e gli streams vengono trasportati come oggetti all’interno di un messaggio BIOP::File di un Object Carousel.
Interaction Channel Delivery: in cui vengono trasferiti solo files di dati.
Il controllo elementare del ciclo di vita di un'applicazione MHP broadcast si realizza al momento della selezione di un servizio, che può essere effettuata sia dall'utente attraverso il telecomando, che da una qualunque applicazione MHP dotata di funzionalità EGP. Il Servizio è considerato da MHP l'unità elementare di presentazione ed esecuzione dei contenuti, in quanto composto da quelle parti di contenuto che devono essere presentati all'utente contemporaneamente, ad esempio, flussi di audio, video e dati, informazioni di servizio ed applicazioni.
Ogni servizio è accompagnato da una specificazione del suo contesto operativo, definita Service Context, che rappresenta e delimita l'ambiente in cui un servizio viene presentato e ne consente il trattamento come singola entità. Nelle applicazioni DVB-Java un service-context è rappresentato da un'istanza della classe ServiceContext, in quelle DVB-HTML da un oggetto JavaObject, restituito dalle API di comunicazione tra i due linguaggi, con le stesse caratteristiche della classe ServiceContext di un'applicazione DVB-J. Poiché un service-context può presentare un solo servizio alla volta, la selezione di un nuovo servizio provocherà l'arresto di quello in corso, tranne quelle parti di contenuto esplicitamente richieste dal nuovo servizio. Il limite al numero di service-contexts che possono essere presentati simultaneamente è imposto invece dal ricevitore MHP.
Vediamo come viene realizzata la selezione di un servizio per le differenti applicazioni:
In un'applicazione DVB-J, selezionare un servizio significa richiamare il metodo Select() di un'istanza javax.tv.service.selection.ServiceContext della classe.
In un'applicazione con accesso Internet, selezionare un servizio corrisponde all'attivazione di un link ad un dvb:locator rappresentante il servizio.
In un'applicazione DVB-HTML, selezionare un servizio corrisponde ad attivare un link ad un dvb:locator lo rappresenta, oppure richiamare il metodo Select() di un JavaObject rappresentante un service-context.
Come abbiamo già visto in precedenza, le applicazioni viaggiano all'interno dei Transport Streams MPEG-2 e le informazioni che le riguardano sono contenute in records all'interno dell'Application Information Table (AIT) relativa ad un preciso servizio. All'arrivo di una nuova applicazione, il ricevitore esamina le informazioni contenute nella tabella AIT associata e verifica la conformità della propria configurazione con il profilo MHP indicato nella stessa e, nel caso si tratti di un profilo più elevato di quello disponibile, non la esegue. Alla scelta di un nuovo servizio, l’Application Manager termina le applicazioni appartenenti unicamente al dominio del servizio in corso e, tra quelle appartenenti al nuovo service-context, lancia immediatamente quelle segnalate come applicazioni ad avvio automatico. Per le rimanenti applicazioni che si trovavano in esecuzione, verifica se la tabella AIT le segnala come autorizzate, altrimenti le termina.
Il ciclo di vita di un'applicazione DVB-MHP assume forma diversa a seconda che l'applicazione appartenga alla piattaforma DVB-J o DVB HTML. Nel caso di un'applicazione DVB-Java, definita Xlet Application, il lifecycle richiama quello di un applet Java ed è formato da quattro stati: Loaded, Paused, Active e Destroyed. Nel caso di un'applicazione DVB HTML, il lifecycle è composto da cinque stati: Loading, Active, Paused, Destroyed e Killed. I seguenti diagrammi di transizione riassumono gli stati e le transizioni tra essi, inerenti alle applicazioni DVB-J e DVB-HTML (Figg, 14 e 15).
Figura 4.14: Diagramma di stato del ciclo di vita di un'applicazione DVB-J
Figura 4.15: Diagramma di stato del ciclo di vita di un'applicazione DVB-HTML
Gli standard DVB per la gestione dell'interattività attraverso un canale di ritorno, come abbiamo già visto, si suddividono in due gruppi: quelli specifici del mezzo fisico di comunicazione e quelli indipendenti dal medesimo. Per rendere più semplice la produzione di specificazioni tecniche, DVB ha adottato un modello semplificato dello stack OSI (Fig. 4.20).
I criteri seguiti per la suddivisione in layers sono:
Livello Fisico: definisce tutti i parametri della trasmissione fisica.
Livello di Trasporto: definisce tutte le strutture dati più rilevanti ed i protocolli di comunicazione.
Livello Applicativo: riguarda il software di applicazioni interattive ed il loro ambiente di esecuzione.
Le specificazioni rilasciate relative ad i diversi mezzi fisico di comunicazione, riguardano quindi i due livelli più bassi del modello adottato da DVB, rappresentato dalla figura 4.20.
Figura 4.20: Modello di riferimento adottato
All'insieme di protocolli indipendenti dalla rete, il DVB Project ha affiancato una serie di specifiche per le particolari infrastrutture di comunicazione: PSTN, ISDN, DECT, GSM, GPRS, xDSL ed altre in via di definizione. Il middleware MHP, dal canto suo, è in grado di utilizzare qualunque canale di ritorno (PSTN, ADSL, GSM, GPRS, UMTS, Ethernet etc.) purché la connessione supporti lo stack di protocolli TCP/IP.