MHP - Multimedia Home Platform

Multimedia - ein Begriff, der in aller Munde ist. "Multi" steht für die große Vielfalt und Arten kultureller Medien, wobei man diesen Begriff heutzutage durchaus auch mit der "Informationsflut" durch Massenkommunikation verbinden kann. Der Konsument hat es einerseits schwer, die für ihn interessanten Informationen aus einem riesigen Informationsangebot herauszufiltern, andererseits wählt er aus, durch welches Medium er "versorgt" werden möchte. In Haushalten stapeln sich Endgeräte wie Fernseher, Videorekorder, Decoder, Hi-Fi-Anlage, Personal Computer, Spielkonsolen und Telefon. Es wäre doch schön, wenn man für all diese Sachen nur ein einziges Gerät bzw. einen einzigen Empfänger hätte. Voraussetzung hierfür ist allerdings ein vordefinierter Standard, der dann die TV-, Rundfunk-, Computer- und Internetwelten zusammenführen und verbinden kann.

[1]; [6]; [10]

MHP als Bindeglied

[in Anlehnung an [6], Bild 2; http://www.uni-weimar.de/~koch17/rbs/pics/abb_bindeglied.jpg]

Im Rahmen eines DVB-Projektes (Digital Video Broadcasting) entstand ein Konzept für eine "Multimedia Home Platform" (MHP), die einen gemeinsamen, hardware-unabhängigen Standard oder eine Schnittstellendefinition für digitale Anwendungen und Dienste von Fernsehen bis hin zum Internet darstellen sollte, sodass alle Endgeräte aller Anbieter alle Anwendungen, einschließlich der Zusatzdienste, empfangen können. Dennoch ist der gleichberechtigte Wettbewerb am Markt innerhalb der einzelnen Segmente ("horizontaler Markt") garantiert. Im Gegensatz dazu bezeichnet man eine Marktstruktur, in der Programm, über Codierung und Verbreitung, bis hin zu den Endgeräten in einer Hand liegt, als "vertikalen Markt" (z.B. Kirchgruppe/Premiere/d-Box).

[1] S. 2, 5, 6; [10]

Im Folgenden werden Architektur, Profile, Implementationsansätze und Beispielanwendungen beschrieben und erläutert.

2. MHP-Architektur

Die MHP-Architektur gliedert sich in 3 Schichten. Die obere Schicht stellen verschiedenste Anwendungen (Applications) wie z.B. elektronischer Programmführer (EPG), Homebanking, E-Mail usw. dar. Aufgesetzt auf die untere Hardware-Schicht, bildet die Systemsoftware wie z.B. Betriebssystem die mittlere Ebene. Damit nun die einzelnen Anwendungsprogramme auch einwandfrei funktionieren, müssen sie auf das Betriebssystem abgestimmt sein. Dafür sorgt das "Application Programming Interface" (API), die Schnittstelle zwischen Anwendungen und Systemsoftware. Im Standard der Multimedia Home Platform ist diese Schnittstelle eindeutig beschrieben. Weiterhin wird sie in diesem Zusammenhang auch als "offen" bezeichnet, da sie allen Benutzern bekannt ist und zur Verfügung steht. Das heißt nun für die Praxis, dass Anwendungsprogramme geschrieben werden, welche auf die MHP-API abgestimmt sind. Die MHP-API ist auf Endgeräten unterschiedlichster Hardware (hier meist "Set-Top-Box") vorhanden, und somit werden auch alle Anwendungsprogramme verstanden.

[1] S. 8 ff.; [6]

Der im DVB-Projekt beschriebene Standard für eine offene hardwareunabhängige API basiert auf der Programmiersprache Java. Somit bildet die Java Virtual Machine (JVM) einen wesentlichen Bestandteil der oben erwähnten, auf Set Top Boxen intergrierten, Systemsoftware.

[1] S. 20

Eine Untermenge der Anwendungsprogramme bilden zum Beispiel alle Pay-TV-Programme. Somit kommt ein weiterer Bestandteil zur MHP-Architektur hinzu, der den Zugang von Benutzern zu solchen Anwendungsprogrammen kontrolliert und steuert. Hier findet das Verfahren des "Conditional Access" (CA) Anwendung, bei dem die zu übertragenden Daten beim Sender verschlüsselt und beim Empfänger entschlüsselt werden. Weiterhin wird ein sogenannter "Loader" vorgesehen, der die Systemsoftware auf dem neuesten Stand hält und somit die ihre Zukunktssicherheit gewährleistet. Die Eigenschaften dieses Loaders sind jedoch nicht im MHP-Standard spezifiziert, sodass jeder Endgerät-Hersteller frei über dessen Implementation entscheiden kann.

[1]; [2]; [6]

MHP-Architektur

[in Anlehnung an [6], Bild 4; http://www.uni-weimar.de/~koch17/rbs/pics/abb_architektur.jpg]

2.1. Standardisierte DVB-API und Transportprotokolle

Eine Standardisierte API ist Voraussetzung dafür, dass Entwickler von Anwendungen und Diensten diese betriebssystemunabhängig herstellen können. Somit ist eine gewisse "Plattform-Kompatibilität" gewährleistet, was durch die Verwendung einer plattformunabhängigen Programmiersprache noch weiter unterstützt wird.

[1] S. 20

Die sog. "Middleware" (s. Abb. MHP-Architektur) beinhaltet Systembestandteile wie die eigentliche API, Interpreter, run-time Engine, virtuelle Maschine, Bibliotheken, Loader, Datenbanken und Event-Manager. Sie ist für folgende Systemfunktionen verantwortlich:

Start und Kontrolle der Anwendungen
Management von Sitzungen, Ereignissen, Kommunikation und Input/Output
Steuerung von Sicherheit und Zugriff
Laden verschiedenster Anwendungsinhalte
Navigation und Selektion innerhalb des Anwendungsangebotes

Die API soll lokal gespeicherte Anwendungen in gleicher Weise unterstützen wie die sowohl in Echtzeit als auch in "non-real time" heruntergeladenen Applikationen, das sog. "Look and Feel" der Anwendungen aufrechterhalten, den Zugriff auf Datenbanken ermöglichen und trotzdem den Wettstreit zwischen Anwendungsentwicklern und -implementierern erlauben.

Es werden grundsätzlich 2 Arten von Appikationen unterschieden, zum einen die prozeduralen Anwendungen ("procedural application")

und zum anderen die deklarativen Anwendungen ("declarative applications"). Erstgenannte basieren auf sog. "low-level functions" und werden verwendet, wenn großer Optimierungsgrad gefordert wird, sind aber plattformabhängig, d.h. sie müssen auf den jeweiligen Plattformen verifiziert werden. Vom Datenumfang her sind sie klein, enthalten direkt ausführbaren Code und steigern somit die Performance. Prozedurale Anwendungen verwenden sog. "high-level functions", und sind durch Plattformunabhängigkeit, und somit -kompatibilität, größere Datenpakete und schlechtere aber genauere Performance gekennzeichnet. Jede Anwendung ist generell prozedural oder deklarativ.

[2] S. 3..8

Für die MHP-Schnittstelle (API) wurden drei Profile definiert: "Enhanced Broadcast", "Interactive Broadcast" und "Internet Access". Enhanced Broadcast verbindet Audio- und Videoübertragung mit heruntergeladenen Anwendungsprogrammen und erlaubt somit nur lokale Interaktivität, da kein Rückkanal verwendet wird. Im Gegensatz dazu existiert im Profil des Interactive Broadcasts ein Rückkanal, der eine bestimmte, vom Überträgerservice abhängige, Breite von Nutzerinteraktion ermöglicht. Im Internet-Access-Profil werden Internetdienste und deren Verknüpfung mit Rundfunk- und Fernsehübertragungsservice bereitgestellt.

[1] S. 20; [3] S. 54..57; [6]

MHP-Profile

[in Anlehnung an [6], Bild 3; http://www.uni-weimar.de/~koch17/rbs/pics/abb_profile.jpg]

Um mit der Außenwelt kommunizieren zu können, muß die Multimedia Home Platform auf die verschiedensten Netzwerktypen (Satellit, Kabel, terrestrisch) abgestimmt sein. In einem Teil der MHP-Spezifikation werden daher netzwerkunabhängige Transportprotokolle definiert. Sie werden in Protokolle für "Streamed Video und Audio" und Protokolle für Applikationen und Daten unterteilt. Broadcast-Dienste werden für ein System mit "downstream"-Kanal und Internet-Dienste mit sowohl "downstream"- als auch Interaktions-Kanal bereitgestellt.

[1] S. v; [2]; [6] S. 4

Broadcast Channel Protocols

[übernommen aus: http://pda.etsi.org/exchangefolder/ts_102812v010101p.pdf; S.55 Figure 8;

nur über Registrierung bei http://www.etsi.org/getastandard/home zugänglich !]

Interaction Channel Protocols

[übernommen aus: http://pda.etsi.org/exchangefolder/ts_102812v010101p.pdf; S.57 Figure 9;

nur über Registrierung bei http://www.etsi.org/getastandard/home zugänglich !]

2.2. Das CA-System und das Common Interface

An dieser Stelle soll ein wesentlicher Gesichtspunkt der MHP-Spezifikation betrachtet werden, das Zugangssystem (CA), seine Ausgestaltung und Einbindung. Die objektiv einfachste Lösung wäre ein einheitliches CA-System, was allen Anbietern gleichermaßen offen steht. Das heißt aber keine Berücksichtigung unterschiedlicher Marktinteressen in gleicher Weise. Somit ergibt sich die Forderung nach einem "Common Interface" (CI) für das CA-System, um einen offenen Decoder-Markt zu unterstützen. Nur so können Decoder von verschiedenen Anbietern mit unterschiedlichem CA-System in den verschiedenen Märkten (Satellit, Kabel, terrestrisch) frei abgesetzt werden. Das Common Interface stellt einen einfach austauschbaren, von außen steckbaren Hardware-Baustein (ähnlich einer PC-Karte) dar, der die Verbindung zwischen Endgerät und Smartcard herstellt. Smartcard werden zur Autorisierung des Endkunden verwendet. Um Forderungen nach einem offenen CA-System und einem offenen Zugang aller Marktpartner gerecht zu werden, muss eine klare Trennung des CA-Systems, einerseits von der Hardware, andererseits aber auch von anderen Softwarekomponenten des Gesamtsystems, insbesondere API-System und Betriebssystem (OS), erfolgen.

[1]; [6]

Um ein offenes CA-System zu realisieren, existieren grundsätzlich zwei Möglichkeiten, die sich in Funktion und Struktur wesentlich unterscheiden. Das erste Verfahren wird "Multicrypt" genannt. Hier fügt jeder Anbieter seinem zu übertragenden Programm die CA-Kennung seines CA-Systems bei. Somit befinden sich auf dem Sendeweg Programmpakete mit einer Kennung eines beliebigen CA-Systems. Somit muss das Empfangsgerät des Endkunden mit je einem CA-Modul und einer Smartcard für den jeweiligen, gewünschten Pay-Anbieter ausgestattet sein. Um trotzdem flexibel zu sein, d.h. Programme mehrerer Anbieter empfangen zu können, müssen die CA-Module im Endgerät in irgendeiner Weise auswechselbar sein. Hier greift das Konzept des Commen Interface. Dem Multicryt-Verfahren steht des "Simulcrypt"-Verfahren entgegen. Hier fügt jeder Anbieter seinem Programmsignal die CA-Kennung aller verwendeten CA-Systeme bei, sodass alle auf dem Markt befindlichen Decoder angesprochen werden können. Somit können, unabhängig vom implementierten CA-System, alle Endgeräte alle Programme empfangen. Dieses Verfahren fordert hohen technischen Aufwand auf der Senderseite, dafür aber kostengünstige und einfache Endgeräte auf Empfängerseite, folgt also einem alten Grundsatz des Rundfunks.

[1] S. 11..13

Beide Verfahren stehen prinzipiell gleichwertig nebeneinander, es können zugangsoffene CA-Systeme realisiert werden. Die verschiedenen Marktteilnehmen bewerten die jeweiligen Vorteile und Nachteile der beiden Verfahren unterschiedlich. Somit fordert ein DVB-MHP-System die Unterstützung von Multicrypt und Simulcrypt.

[1] S. 12, 13

2.3. Anwendungsbeispiele und Hardware

In diesem Abschnitt werden, größtenteils grafisch, Beispiele für Hardware und Anwendungen dargestellt. Die End-/Empfangsgeräte, von den meisten Anbietern als "MHP Set-Top-Box" bezeichnet, ähneln vom Aussehen her sehr stark herkömmlichen Receivern. Die Markteinführung MHP-fähiger Endgeräte der meisten Anbieter beginnt mit dem Frühjahr dieses Jahres.

[8], [9]

Panasonic TU-DSF41

[http://www.panasonic.de/produkte/graphics/datenbank/tu-dsf41_9.jpg]

Nokia Mediaterminal 511 S

[http://www.nokia.de/home_communications/produkte/media_terminal/img/header_3.jpg]

Grundig SINIO DTR 6111 S CI

[http://www.grundig.de/produkte/digital/pics/sinio_dtr6111sci_silber_off.jpg]

Als Beispiele für MHP-Anwendungsprogramme sind ein Elektonischer Programmführer (EPG - Electronic Program Guide), Informationsdienste (Super Teletext, Newsticker, usw.), E-Commerce-Dienste (homebanking) und Anwendungen, die auf TV-Programminhalte abgestimmt sind (Hintergrundinformationen zu Sendungen, usw.) zu nennen. Hier einige Beispiele:

[8]; [9]; [10]

ZDF.vision EPG

[http://www.mhp-forum.de/content/ZDFVision/PGERST1.jpg]

Airport-Service (Flugzeiten)

[http://www.mhp-forum.de/content/airportinfo/ArribadesA1.jpg]

interaktive Werbesendung (inklusive Homebanking)

[http://www.mhp-forum.de/content/interactive_ad/17.jpg]

Golfspiel (Hintergrundinformation zum Sendungsinhalt)

[http://www.mhp-forum.de/content/interactive_golf/screen.jpg]

3. IRT MHP-Referenzimplementierung

Am Institut für Rundfunktechnik GmbH (IRT) in München wurde mit der "MHP-Referenzimplementierung" (RI) ein Grundstein für die Einführung des DVB-MHP-Standards gelegt. Die Referenzimplementierung stellt eine mögliche Umsetzung der standardisierten MHP-API dar. Sie ist fast ausschließlich in Java geschrieben und läuft auf PC-Plattformen unter Windows und Linux und kann Verbindung mit der geeigneter, evtl. angepasster Java Virtual Machine (JVM) auf andere Systeme portiert werden. Die benötigten Hardwarekomponenten sind in der folgenden Abbildung dargestellt..

Hardware für MHP-RI

[in Ahnlehnung an [5], Bild 3; http://www.uni-weimar.de/~koch17/rbs/pics/abb_RI.jpg]

Die MHP-RI kann als MHP-Betriebssystem in Endgeräte integriert werden und bietet Programmanbietern, Software- und Geräteherstellern wertvolle Diensten bei der Entwicklung ihrer MHP-Produkte, da diese nicht auf allen Set-Top-Boxen getestet werden müssen. Weiterhin bietet eine Referenzimplementierung folgende Vorteile. Es können relativ einfach Inkonsistenzen, fehlende API-Funktionen im MHP-Standard entdeckt und Möglichkeiten zur Standarderweiterung getestet werden. Die MHP-RI ist parametisierbar, damit sie auf Set-Top-Boxen und Chips, jeweils mit spezifischen Merkmalen und Restriktionen portiert werden kann.

[4], [5]

4. Ausblick

Wenn die MHP-Endgeräte auf den Markt kommen und für Kunden relativ erschwinglich geworden sind, dann wird die rasante Entwicklung bzw. Produktion von Anwendungsprogrammen und Diensten zur deutlichen Belebung und Expansion des Marktes führen. Anwendungen wie Internet via TV, eMail, eCommerce, interaktive Spiele, Bildtelefone usw. werden den "einfachen" Fernseher in den Hintergrund verdrängen. Die technische Entwicklung wird auch dahingehend fortschreiten, dass zum Beispiel Set-Top-Boxen mit Festplattenspeichern ausgestattet werden und digitale "In-Home-Netzwerke", bei denen Fernseher und PC auch mit anderen medialen Komponenten verbunden sind, entstehen. Diese Dinge eröffnen vollig neue, zum Teil noch unbekannte, Anwendungsfelder.

[1] S. 27; [10]

Als wichtigstes Grundsatz der MHP-Standardisierung und Produktion/Entwicklung von Entgeräten und Software bleibt aber der Wunsch, dem Kunden eine einfache und komfortable Nutzung aller Angebote des Marktes mit nur einem Endgerät zu ermöglichen.

5. Quellen und Links

informativ:

http://www.mhp-forum.de

http://www.dvb.org

http://www.tv-plattform.de

http://www.irt.de

http://www.etsi.org

http://www.heise-online.de/ct/01/18/094/default.shtml

http://www.heise-online.de/ct/01/20/146/default.shtml

"Ausblicke auf die 4-C-Landschaft / MHP-Plattform", Audio Professional, Nr. 6 November/Dezember 2001, Seite 10 ff.

bezugnehmend zu Text und Abbildungen:

[1] http://www.mhp-forum.de/press/basispapier.pdf