Abschlussbericht der Projektgruppe „Middleware“

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen

Ausschuss für technische Regulierung in der Telekommunikation (ATRT)

Bonn, Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 2

Abschlussbericht der Projektgruppe Middleware des ATRT

Berichterstatter: Dr. Helmut Stein und Dr. Klaus Illgner-Fehns als Ko-Vorsitzende

Verteiler: ATRT Projektgruppe Middleware ATRT- BNetzA

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 3

Inhaltsverzeichnis

1. Vorwort ...... 6

2. Management Summary……………………………………………………………….....7

3. Einführung und Zielsetzung ...... 8

3.1. Eine erste Begriffsklärung…………………………………………………...... 8

3.1.1. Middleware ...... 9

3.1.2. Applikation ...... 9

3.1.3. API ...... 9

3.1.4. Funktion ...... 9

4. Interessen und Anforderungen der Marktteilnehmer ...... 10

4.1 Marktrelevanz der Interessen und Anforderungen ...... 10

4.2 Interessen und Anforderungen der Plattformbetreiber…………………………12

4.2.1 Allgemeine Anforderungen ...... 15

4.2.2 Funktionale Anforderungen...... 15

4.2.3 Technische Anforderungen ...... 16

4.2.4 Kernpunkte der Anforderungen ...... 17

4.3 Interessen und Anforderungen kommerzieller Middleware-Anbieter………...18

4.4 Interessen und Anforderungen der Systemanbieter……………………………20

4.5 Interessen und Anforderungen der Endgerätehersteller……………………….21

4.6 Interessen und Anforderungen der Inhalteanbieter

(Programmveranstalter und Diensteanbieter)…………………………………...255

4.6.1 Sichtweise von Sky Deutschland...... 27

4.6.2 Gemeinsamkeiten der Inhalteanbieter………………………………………30

4.7 Interessen und Anforderungen der Nutzer………………………………………31

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 4

4.8 Interessen und Anforderungen weiterer Marktteilnehmer……………………..34

4.9 Zusammenfasung der Interessen und Positionen der Marktteilnehmer……...35

5. Darstellung der Systeme im Markt ...... 40

5.1 Middleware und API: Aufgaben in der Systemarchitektur…………………..…40

5.2 Standardisierte Systeme für TV und das Zusammenwachsen mit dem Internet……………………………………………………………………………….46

5.2.1 GEM (MHP) ...... 46

5.2.2 HbbTV...... 48

5.2.3 OPIF ...... 51

5.2.4 MHEG ...... 53

5.2.5 Weitere Systeme, ...... 54

5.3 Lösungskonzepte für TV auf Basis etablierter Web-Technologien……………54

5.4 Cloud- basierte Lösungen…………………………………………………………56

5.5 Firmenspezifische Systemlösungen……………………………………………...59

5.6 Ausblick……………………………………………………………………………...60

6. Vertiefende Bestimmung der Begriffe ...... 61

6.1.1 Middleware ...... 64

6.1.2 Applikation ...... 64

6.1.3 API...... 65

6.1.4 Funktion ...... 65

7. Zusammenfassung...... 65

8. Mitglieder der Projektgruppe ...... 68

A. Allgemeine Anhänge ...... 70

A.1 Mandat der Projektgruppe ...... 70

A.2 Glossar ...... 71

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 5

A.3 Abkürzungen...... 75

B Spezifische Anhänge…………………………………………………………………82

B.1 Proprietäre Systeme……………………………………………………………….82

B.1.1 NDS MediaHighway…………………………………………………………..82

B.1.2 Nagra OpenTV…………………………………………………………………87

B.1.3 Microsoft MediaRoom…………………………………………………………91

B.1.4 Cisco Videoscape……………………………………………………………..93

B.1.5 Cloud-basierte Lösungen von Alcatel-Lucent……………………………...97

B.1.6 GoogleTV auf Android-Basis……………………………………………….100

B.1.7 AppleTV auf iOS-Basis……………………………………………………..102

B. 2 Smart Meter- Applikationen……………………………………………………..102

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 6

1. Vorwort

„Was lange währt wird endlich gut!“

Nach vielen Monaten unterschiedlich aktiver Phasen konnte die Projektgruppe Middleware des ATRT ihren Bericht nun fertigstellen. Die Erarbeitung dieses Berichtes erforderte abschnittsweise umfangreiche und kontroverse Diskussionen. Das was Marktteilnehmer technisch aber auch hinsichtlich der Geschäftsmodelle mit dem Begriff „Middleware“ verbinden, weist deutliche Unterschiede auf. Ergänzend, man könnte auch sagen erschwerend, kommt hinzu, dass sich das Marktumfeld aufgrund schneller technischer Entwicklungen weiterhin stetig verändert. Umso erfreulicher ist es, dass es gelang, Definitionen für die 4 in einem engen technischen Zusammenhang stehenden Begriffe „Middleware“, „API“, „Funktion“, und „Applikation“ gemeinsam abzustimmen.

Wir bedanken uns bei den Mitgliedern der ATRT Projektgruppe Middleware für ihre intensive und engagierte Mitarbeit. Besonderer Dank gilt hier der Redaktionsgruppe, bestehend aus Alexa Christ, Carsten Engelke, Ulrich Freyer, Patrick Krisam, Dr. Georg Lütteke, Dr. Helmut Stein und Bernd Tröger. Wir danken auch der Bundesnetzagentur für die kontinuierliche Begleitung der Diskussionen, namentlich Herrn Feller. Carine Chardon danken wir für Layout und Gestaltung.

Wir hoffen mit diesem Bericht einen Beitrag zum Verständnis der sich sehr schnell verändernden Software-Architekturen und der daraus resultierenden komplexen und sich verändernden Märkten leisten zu können.

München, 01.08.2013

Dr. Helmut Stein und Dr. Klaus Illgner (Ko-Vorsitzende)

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 7

2. Management Summary Die erste Aufgabe der PG Middleware war es, Definitionen der Begriffe Middleware und Anwendungs-Programmierschnittstelle (API) zu erarbeiten und zwar fokussiert auf die funktionale und technische Integration in Empfangsgeräten für digitale Audio- und Video-Dienste. Dabei waren die Vorgaben des TKG zu berücksichtigen. Es sollte eine umfassende inhaltliche Bestandsaufnahme der Marktsituation sowie der in diesen Bereichen wirkenden Marktmechanismen beschrieben werden. Dazu sollte insbesondere eine Übersicht über die jeweiligen Interessen und Anforderungen der Marktteilnehmer erstellt werden. Die Arbeit in der PG Middleware offenbart, dass die Begriffe Middleware und API durch die weiteren Kern-Begriffe Funktion und Applikation ergänzt werden müssen. Selbst mit der Erweiterung der Begriffe wird klar, dass im konkreten Fall die Abgrenzung zwischen einzelnen Begriffen auf Grund wechselseitiger Abhängigkeiten fließend sein kann. Die Analyse verschiedener Softwarearchitekturen, insbesondere neuerer Endgeräte, wie Smart-TVs, Tablets, Smartphones, usw. und deren Vernetzung zeigt auf, dass es in diesen Systemen kaum mehr einheitlich strukturierte bzw. ganzheitliche Softwarelösungen gibt. Die Vielfalt der in diesem Bericht aufgezeigten Ansichten der Marktteilnehmer führt dazu, dass eine durchgängige Anwendung einer universellen API für alle Geräte und Anwendungen wenig realistisch erscheint. Die Internet-Funktionalität moderner Endgeräte liefert hingegen technische Voraussetzungen für eine weitgehende Anwendbarkeit und Vernetzbarkeit von Applikationen unter Einbeziehung verschiedenster Infrastrukturen. Damit erscheint es möglich, dass künftig eine Vielzahl von Applikationen über verschiedene Plattformen und/oder Infrastrukturen verteilt und auf unterschiedlichen Endgeräten nutzbar wird. Für die Bereitstellung von Applikationen durch Dritte ist die Möglichkeit des Zugangs zu Funktionalitäten des Gerätes über definierte und offene Schnittstellen (API) essentiell. Der Zugang zu diesen Funktionen und Schnittstellen für Dritte wird nicht durchgängig bereitgestellt.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 8

3. Einführung und Zielsetzung

Die Arbeit der PG Middleware basiert auf dem vom ATRT (Ausschuss für Technische Regulierung in der Telekommunikation) erteilten Mandat (Anhang A 1).

Im Rahmen des Berichtes werden die Begriffe „Middleware“, „API“, „Applikation“, und „Funktion“ diskutiert und umfassend beschrieben. Die Begriffe werden von den Marktteilnehmern unterschiedlich interpretiert und variieren insbesondere entsprechend der jeweiligen Position im Markt. Vor einer Analyse der Systeme und des Marktes ist daher eine Klärung der Begrifflichkeiten notwendig. Dabei wurde versucht, einen Konsens zu erzielen.

Um die Abhängigkeiten der vorstehend angeführten Begriffe in Bezug auf die Position im Markt besser verstehen zu können, müssen insbesondere die Begriffe Middleware und API eineindeutig voneinander abgegrenzt werden.

3.1. Eine erste Begriffsklärung

Ausgangspunkt ist ein abstrahiertes Modell eines Endgerätes, das neben dem Betriebssystem eine als Middleware bezeichnete Softwareschicht enthält. Diese beinhaltet eine Sammlung von Funktionalitäten, die im Endgerät verfügbar sind und auf die von Applikationen über Anwendungs-Programmierschnittstellen (API) zugegriffen werden kann.

Abbildung 1: Generisches Middleware-Modell

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 9

3.1.1. Middleware

In der Informatik wird Middleware (deutsch: Diensteschicht oder Zwischenanwendung) als anwendungsneutrale Softwareschicht verstanden, die zwischen Betriebssystem und Applikation vermittelt.

Middleware stellt somit eine Umgebung zum Ausführen von Applikationen und die Schnittstellen zu benötigten Funktionen bereit. Die Komplexität der Systeminfrastruktur bleibt den darauf aufsetzenden Applikationen damit verborgen.

Es gibt allerdings auch Systeme, bei denen die Systemsoftware als ein monolithischer Block ausgeführt ist. Bei diesen Systemen sind keine Middleware-Funktionen für Anwender verfügbar, da keine zugehörige APIs definiert sind und entsprechende Applikationen nicht möglich sind (z.B. Zapping-Box).

3.1.2. Applikation

Eine Applikation ist ein Software-Modul das über eine oder mehrere API auf eine Middleware zugreifen kann. Es lassen sich damit erweiterte Funktionen und/oder Funktionalitäten des Endgeräts für die Nutzer bereitstellen (z.B. EPG).

Applikationen können integraler Bestandteil eines Endgerätes sein und werden dann vom Endgerätehersteller spezifiziert. Sie können aber auch von Dritten zur Verwendung auf dem Endgerät bereitgestellt werden.

3.1.3. API

API ist die Abkürzung für „Application Programming Interface“ und bedeutet Anwendungs-Programmierschnittstelle. Es handelt sich um eine Software- Schnittstelle, die Applikationen den Zugang zu Funktionen des Endgerätes zur Verfügung stellt.

3.1.4. Funktion

Mit Funktion bezeichnet man die Eigenschaften und Aufgaben von Software- Modulen zur Interaktion und dem Datenaustausch zwischen ansonsten

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 10

entkoppelten Software–Modulen, Applikationen, Betriebssystemen und Service-Schnittstellen. Es lassen sich bei den Funktionen unterschiedliche Gruppen bilden (z.B. Streaming, Download, Player-Control, Loader, Life Cycle Management).

4. Interessen und Anforderungen der Marktteilnehmer

Alle an der Wertschöpfungskette Beteiligten haben das Interesse, auch durch Angebote auf den jeweils anderen Stufen dieser Kette zusätzliche Erträge zu generieren. Dies gilt gleichermaßen für Plattformbetreiber, Middleware-Anbieter, Systemanbieter, Endgerätehersteller und Inhalteanbieter. Eine solche Vorgehensweise kann den Wettbewerb stärken. Sie kann gleichzeitig aber auch eine stärkere vertikale Integration bewirken.

Der Nutzer nimmt als Adressat der Wertschöpfungskette eine Sonderrolle unter den übrigen Marktteilnehmern ein.

4.1. Marktrelevanz der Interessen und Anforderungen

Die in Endgeräten integrierten Middleware-Lösungen haben für die weitere Entwicklung der digitalen Welt eine entscheidende Bedeutung. Dadurch werden dem Nutzer neue Inhalte auf den Endgeräten verfügbar gemacht. Dazu gehören unter anderem:

• Video-on-Demand (VOD)

• Programmbegleitende Applikationen (z.B. Mediatheken, Red Button, Voting, EPG, Nachrichten, …)

• Programmunabhängige Applikationen (z.B. Apps, Recommendation Engines, Widgets, Portale, Werbung, Gaming, …)

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 11

In Deutschland hat sich die Entwicklung des Marktes stark entlang der verschiedenen Verbreitungswege orientiert.

• Verbreitung über Satellit oder Terrestrik

• Reiner Retail-Markt, die Endgerätehersteller entwickeln die Software der Endgeräte selbst, wobei die gerätebezogene Middleware meist aus einem herstellerspezifischen und einem standardisierten Teil besteht.

• Verbreitung über Kabel

• Bei den führenden Kabelnetzbetreibern Kabel Deutschland (KDG), Unitymedia/Kabel BW, Tele Columbus und Primacom ist zur Zeit keine Middleware implementiert.

• Es gibt auch einen von den Kabelnetzbetreibern unabhängigen Retail- Markt für Endgeräte mit Software der Endgerätehersteller und CI / CI+ Modulen.

• Verbreitung durch Telefonnetzbetreiber

• Deutsche Telekom: Microsoft Middleware

• Vodafone: NDS Middleware

• Telefonica (Hansenet): Alcatel Middleware

• Verbreitung durch Pay-TV Anbieter

• Sky Deutschland: NDS Middleware

• Verbreitung über das offene Internet (OTT)

• Auf die OTT-Verbreitung fokussierte Plattformbetreiber mit unabhängigen Lösungen (z.B. Google-TV, Apple-TV, Zattoo, Elgato, u.a.).

Die Funktionalitäten der Middleware in einer konkreten Plattform werden insbesondere von den Interessen folgender Marktteilnehmer bestimmt:

• Plattformbetreiber

• Middleware-Anbieter

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 12

• Systemanbieter

• Endgerätehersteller

• Inhalteanbieter (Programmveranstalter und Diensteanbieter)

• Nutzer

In den nachfolgenden Abschnitten 4.2. bis 4.8 stellen die verschiedenen Marktteilnehmern ihre Interessen und Anforderungen dar. Diese beruhen nicht zwangsläufig auf einem Konsens der Projektgruppe.

4.2. Interessen und Anforderungen der Plattformbetreiber

Unterscheidung der Plattformbetreiber

Es kann zwischen folgenden Arten von Plattformbetreibern unterschieden werden:

a) Plattformbetreiber mit eigener Netzinfrastruktur

• Kabelnetzbetreiber mit eigener Verschlüsselung und Programmaggregation (Kabel Deutschland (KDG), Unitymedia KabelBW, Tele Columbus, PrimaCom, NetCologne, etc.)

• TelCos (traditionelle Telekommunikationsunternehmen, DSL- und Mobilfunk-Anbieter), die über ihre Infrastruktur IPTV- oder OTT-Dienste anbieten (Telekom Deutschland, Vodafone, E-Plus, O2, etc.)

• Satellitennetz-Betreiber, die Programme und Dienste ausschließlich über Satelliten-Direktempfang [direct-to-home (DTH)] an Nutzer vermarkten (z.B. HD+-Plattform von SES)

Inwieweit sich Plattformen auch in der digitalen Terrestrik (DTT) entwickeln und das Stadium der Planung verlassen, bleibt abzuwarten.

b) Plattformbetreiber ohne eigene Netzinfrastruktur

• Programm-Aggregatoren mit eigener Verschlüsselung (z.B. Sky Deutschland, Zattoo, etc.), die mit eigener Endkundenbeziehung ihre Programmpakete über Infrastrukturen Dritter vermarkten.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 13

Zu a)

Aus der Sicht der Plattformbetreiber mit eigener Infrastruktur schließt das Endgerät den Verantwortungsbereich gegenüber dem Nutzer ab. Sie stehen mit ihren Angeboten gegenüber dem Nutzer in der Verantwortung und stellen seinen ersten Ansprechpartner dar. Dies gilt unabhängig vom Entwicklungsstand und Ursprung der vom Nutzer eingesetzten Endgeräte. Der Kabelnetzbetreiber möchte daher ein möglichst großes Maß an Einheitlichkeit bei den Endgeräten haben, um einen hohen Qualitätsstandard beim Nutzer garantieren zu können. Andererseits verlangt der immer stärker werdende Infrastrukturwettbewerb, dass der Kabelnetzbetreiber in der Lage ist, seine technische Infrastruktur ständig weiterzuentwickeln, um an Innovationen teilzuhaben. Dies erfordert auch die stetige Fortentwicklung der Plattformfunktionalitäten.

Telcos unterscheiden sich von Kabelnetzbetreibern lediglich durch die stärkere Orientierung an Übertragungsverfahren und Softwaresystemen des Internets.

Als Plattformbetreiber für den Satelliten-Direktempfang (DTH) ermöglicht z.B. HD+ deutschlandweit den Empfang verschlüsselter Free-TV-Angebote in HD. Als herstellerneutrale und allen Programmveranstaltern grundsätzlich offen stehende Plattform ist es die Strategie von HD+, über möglichst viele HD- fähige Endgeräte empfangbar zu sein. Statt auf proprietäre Technik, setzt HD+ daher auf offene Standards und Industriestandards sowie Selbstzertifizierung.

Eine spezifische Middleware zum Empfang der linearen, verschlüsselten HD- Programme ist für HD+-Empfangsgeräte nicht definiert. Den Endgeräteherstellern steht es vielmehr frei, eine beliebige Middleware einzusetzen und eigene Leistungsmerkmale zu implementieren, solange die Minimalanforderungen des DTH-Plattformbetreibers (z.B. an Signal- und Kopierschutz) eingehalten werden. Diese sind in einer eigenen HD+- Spezifikation (Minimalanforderungen) definiert. Die Dienste der HD+-Plattform können über zertifizierte Set-Top-Boxen sowie über das CI+-Modul von HD+

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 14

empfangen werden. Letzteres setzt ein CI+- zertifiziertes Endgerät (STB oder iDTV) voraus.

Um der technologischen Entwicklung zu entsprechen und den Nutzern auch interaktive, webbasierte Anwendungen anbieten zu können, setzt HD+ mit seiner Erweiterung „HD+ SmartTV“ auf den HbbTV-Standard. Eine spezifische HbbTV-Implementierung wird nicht vorgeschrieben, stattdessen verfolgt HD+ auch hier einen offenen Ansatz. So kann der Endgerätehersteller z.B. den Browser für seine HbbTV-Implementierung frei wählen (z.B. Opera, Access, ANT, Webkit) und auch komplette Middleware-Systeme mit HbbTV-Support verwenden. Diese technologische Offenheit der Plattform fördert sowohl Innovationen, als auch den Wettbewerb unter den Endgeräteherstellern und führt somit zu einer größeren Endgerätevielfalt, aus der die Nutzer auswählen können.

Zu b)

Für Plattformbetreiber ohne eigene Netzinfrastruktur definiert das Endgerät die Schnittstelle Nutzer. Die Angebote vom Pay-TV-Anbieter Sky Deutschland sind zum Beispiel nicht werbefinanziert, sondern ausschließlich abhängig von Abonnement-Einnahmen. Dieses Geschäftsmodell zielt darauf ab, das Abonnement möglichst lange zu sichern. Dafür muss das Endgerät den technischen Anforderungen entsprechen. Im Unterschied zu Plattformbetreibern mit eigener Infrastruktur muss der Plattformbetreiber ohne eigene Infrastruktur Endgeräte für unterschiedliche Infrastrukturen anbieten, um eine möglichst weite Verbreitung zu erreichen. Wie bei Plattformbetreibern mit eigener Infrastruktur kommt hier der Quersubventionierung des Endgerätes eine hohe Bedeutung zu.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 15

4.2.1. Allgemeine Anforderungen der Plattformbetreiber

• Stand der Technik bei Softwaretechnologien

• Erweiterbarkeit und Zukunftssicherheit

• Kosteneffektive technische Implementierung

• Verfügbarkeit von leistungsfähigen Entwicklungstools (Authoring Tools)

• Offener Prozess der Weiterentwicklung von Middlewaresystemen, um neue Produkte und Geschäftsmodelle umsetzen zu können.

• Vollständig spezifizierte und den Marktteilnehmern unter marktgerechten Bedingungen zugängliche Lösungen, die einen Wettbewerb der Middleware-Anbieter ermöglichen.

• Unterstützung der Implementierung von Middleware in Endgeräten durch offene Schnittstellen zu internen Baugruppen innerhalb der Set-Top-Box und Bereitstellung geeignete Testumgebungen (Test-Suites).

• Sicherstellung der Interoperabilität durch geeigneten Zertifizierungsprozess (e.g. Selbstzertifizierung auf der Basis einer umfangreichen Test-Suite)

• Stabilität

• Administrierbarkeit / Update-Fähigkeit

• Möglichkeit zur Einheitlichkeit und Transparenz der Nutzerführung und Angebotsdarstellung.

• Unterstützung von Verschlüsselungssystemen und der entsprechenden Sicherheitsanforderungen der Inhalteanbieter.

4.2.2. Funktionale Anforderungen der Plattformbetreiber

• Unterstützung der relevanten funktionalen Anforderungen der Inhalteanbieter

• Unterstützung der relevanten Geschäftsmodelle der beteiligten Marktteilnehmer

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 16

• Unterstützung von hybriden Endgeräten durch Transport von Applikationen sowohl über Rundfunknetze, als auch über IP-Netze

• Unterstützung von Signalschutz und Jugendschutz durch entsprechende Verarbeitung der relevanten Daten

4.2.3. Technische Anforderungen der Plattformbetreiber

• DVB-Kompatibilität: Zugriffsmöglichkeit auf alle Signale, die gemäß EN 300 468 (Specification for Service Information (SI) in DVB Systems) vorgesehen sind

• Schnittstellen zu den DVB- Signalisierungselementen gemäß EN 300 468 • Unterstützung aller verwandten Audio- und Video-Codecs sowie aller Transport Container- Formate (z.B. MPEG 2 TS) • Kompatibilität zu den relevanten IETF-Standards für IP Dienste

• Unterstützung von Content Delivery- Netzwerken

• Zeitgemäße Streaming Technologien und Streaming Protokolle (wie Adaptive Streaming)

• Zugriffsmöglichkeiten der Applikationen auf alle Ressourcen des Endgeräts

• Verständigung zum Ablauf von “Application Lifecycle“ zum Start, ggf. zum Interagieren und zur Terminierung von Applikationen

• Die Leistungsfähigkeit der Applikationen muss der Nutzererwartung entsprechen. Die üblichen Ressourcen der Endgeräte-Hardware müssen dies erfüllen können.

• Portierbarkeit auf unterschiedliche technische Typen und Populationen von Endgeräten • Unterstützung verschiedener CA/DRM-Systeme • Portierbarkeit auf unterschiedliche Multitasking-Betriebssysteme

• Integrierbarkeit auf unterschiedliche Play-out Center (POC)- und Backend- Systeme

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 17

• Verfügbarkeit von Betriebskonzepten und leistungsfähigen Monitoring und Reporting Tools

4.2.4. Kernpunkte der Anforderungen der Plattformbetreiber

Die allgemeinen, funktionalen und technischen Anforderungen der Plattformbetreiber lassen sich wie folgt zusammenfassen:

• Applikationen auf dem TV-Gerät werden von den Nutzern erwartet. Die softwaretechnischen Systeme zur Umsetzung müssen eine kundenfreundliche Umsetzung ermöglichen und zugleich die Flexibilität bieten, dieses neue Marktsegment marktgerecht zu entwickeln. Kosteneffizienz, Integrationsfähigkeit in die vorhandenen Plattformen, Weiterentwicklungsmöglichkeiten, Softwarestabilität und Wettbewerb der Systemanbieter sind weitere Schlüsselanforderungen.

• Keine Festschreibung bestimmter Standards von Middleware, damit innovative Entwicklungen in einem sich dynamisch entwickelnden Markt möglich bleiben.

• Offenheit für unterschiedliche Geschäftsmodelle

• Diskriminierungsfreier Zugang zu programmbezogenen [bounded] und programmunabhängigen [unbounded] Applikationen. Solche werden nur in dem Maße entwickelt, als sie sich auf Endgeräten mit einer gesicherten Reichweite implementieren lassen.

• Erfüllung der funktionalen Anforderungen der Inhalteanbieter (also Programmveranstalter und Diensteanbieter), da diese bei der linearen Verbreitung integriert und beworben werden.

• Offene Spezifikationen und Schnittstellen, um den Wettbewerb der Middleware-Anbieter zu ermöglichen.

• Leistungsfähige Geschäftsmodelle, die das Endgerät integrieren, erfordern möglichst kostengünstige Lösungen. Middleware von Anbietern wie NDS, Nagravision und anderen sind bei vielen Endgeräteherstellern umgesetzt.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 18

Dies ermöglicht einen Wettbewerb auf Hardware-Basis, womit die Vergleichbarkeit der Angebote ermöglicht wird. Parallel dazu können Middleware-Lösungen unabhängig von den Interessen der Endgerätehersteller entwickelt werden und den langfristigen Interessen der Plattformbetreiber folgen.

• Als zukunftssichere Lösung müssen die Endgeräte eine funktionale Offenheit über drei Jahre hinaus abdecken und innovative Lösungen innerhalb dieses Zeitraumes bereits abbilden können.

4.3. Interessen und Anforderungen der Middleware-Anbieter

Folgende Kernfunktionen soll Middleware für Plattformbetreiber erfüllen:

• Einsatz auf verschiedener Hardware unterschiedlicher Endgeräte-hersteller (Geräteunabhängigkeit)

• Einheitliche und konsistente Nutzerschnittstellen über verschiedene Endgeräte (“Branding“)

• Einsatz von Applikationen auf verschiedenen Endgeräte-Typen ohne spezifische Anpassungen

Um diese Vorgaben erfüllen zu können, arbeiten Middleware-Anbieter wie Nagravision, NDS und andere mit den Endgeräteherstellern und Chip-Herstellern (z.B. Broadcom, ST, IBM, Intel, ….) zusammen, um möglichst viele der Middleware-Funktionalitäten im Chipsatz zu integrieren. Um Applikationen konsistent einbinden zu können stellt die Middleware entweder ein ‚Execution Environment‘ oder ein ‚Declarative Environment‘ zur Verfügung, die jeweils von der Hardware der Endgeräte entkoppelt sind und nur gewisse Mindestanforderungen an die Leistungsfähigkeit [performance] und Schnittstellen der Hardware stellen.

Middleware-Anbieter von ‚Execution Environments' folgen den Vorgaben des Plattformbetreibers, damit die als Anwendungsprogramme geschriebenen Applikationen auf dem Endgerät ausführbar sind. Dabei kann eine Applikation auch die Steuerung des Endgerätes übernehmen. Der Middleware-Anbieter muss

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 19

gleichzeitig aber auch innovative Applikationen vorantreiben. Nur dadurch können sie den Vorteil im Prinzip offener Middleware gegenüber proprietären Middleware- Lösungen aufrechterhalten.

Kunden der Middleware-Anbieter sind die Plattformbetreiber und die Endgeräte- hersteller. Entscheidend für ihren Geschäftserfolg ist daher die kosteneffiziente und flexible Umsetzung der Anforderungen der Plattformbetreiber und Endgerätehersteller.

Darüber hinaus sind auch folgende Aspekte wesentlich:

• Steigerung der Effizienz durch Einsatz neuester Technologien.

• Erweiterung der Middleware gemäß den Marktanforderungen.

• Flexible Architektur, um spezifische Anforderungen schnell und mit vertretbarem Aufwand umsetzen zu können.

• Fokussierung auf Kernthemen als Teil des eigenen Produktangebots und einfache Integrationsmöglichkeiten für Komponenten Dritter (z.B. Recommendation Engine, Advertising Solution, …).

• Minimierung kundenspezifischer Anpassungen.

Kapitel 5 gibt eine Übersicht über die im Markt vertretenen proprietären Systeme als auch der standardisierten Lösungen. Über das Internet treten neben die „klassischen“ aus dem TV entwickelten Middleware-Lösungen auch rein aus der Internet-Technik entwickelte Lösungen (Yahoo TV Widgets, Apple TV, Google TV) auf.

Die neue Offenheit bei Browser-Standards stellt zunehmende Beeinträchtigung der Geschäftsmodelle der Plattformbetreiber und Inhalteanbieter dar, weil durch Standards wie HbbTV und CE-HTML Geschäftsbereiche sehr dynamisch besetzt werden, die von den Plattformbetreibern in Zusammenarbeit mit Middleware- Anbietern entwickelt und auf dem aktuellen Stand gehalten werden müssen. Trotzdem ist die verfügbare Reichweite sowie die Akzeptanz durch die Nutzer entscheidend für den Erfolg und den Einführungszeitraum neuer interaktiver Applikationen.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 20

Middleware-Anbieter haben ihr Interesse an einer schnellen Integration von HbbTV bekundet. Dieser Integrationsprozess ist komplex, da sich die Middleware- Entwicklung an internationalen Entwicklungen orientiert, was den Handlungsspielraum der Middleware-Anbieter zur Entwicklung eigener Standards und Schnittstellen begrenzt.

4.4. Interessen und Anforderungen der Systemanbieter

Zum Portfolio von Systemanbietern gehören primär Ende-zu-Ende- Systemlösungen. Im nachfolgenden Bild sind die Funktionsblöcke und die Funktionen einer Ende-zu-Ende-Systemlösung für Multiscreen Video dargestellt. Diverse Endgeräte werden dabei über ein Multiscreen Content Delivery Network (CDN) mit den Applikationen aus der Cloud beliefert.

Multi Screen Cloud Multi Screen CDN Multi Screen Client

Offer Management Content Management Content Delivery • Linear TV service • Asset mgmt • Streaming • Video service mgmt • workflow • Multi-source • Rights mgmt • entitlements • Content routing Applications • Account mgmt • Community • Storefront • advertising • Player Content • Community Preparation • Search Subscriber Commerce Management • Encoding / • Subscription packages transcoding • Subscription levels • Rights definition • DRM mgmt • End-user information • pricing • Origin servers

Abbildung 2: Funktionsblöcke einer Ende-zu-Ende Systemlösung für Multi Screen

Es sind folgende Funktionen gegeben:

• Content Management ( z.B. Einspielung, Publizieren, Inhalte- und Werbemanagement)

• Nutzer- und Angebotsmanagement ( z.B. Authentifizierung, Werbung, Pay- per-View, Kauf, Miete, Inhaltebündelung)

• Content Preparation ( z.B. Erwerb, Codierung, Speicherung)

• Content Delivery an verschiedenste Endgeräte (incl. Smartphones, Tablets und Smart-TV-Endgeräte)

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 21

• Applikationen für die Nutzung auf unterschiedlichen Endgeräten (z.B. Electronic Programme Guide (EPG), Video on Demand (VoD), Personal Video Recorder (PVR), Endgerätebedienung, Kundenservice, Bezahlvorgänge, Unterstützung von Internet-Technologien und Standards wie Flash, HTML5, HbbTV).

Die typische Middlewarefunktion ist in dieser Architektur nicht mehr wiederzufinden, weshalb es dann auch konsequenterweise keine Anforderung dafür ergibt.

4.5. Interessen und Anforderungen der Endgerätehersteller

Aus Sicht der Endgerätehersteller weist eine Middleware folgende Eigenschaften auf:

• Eine Middleware stellt unabhängig von Hardware und Betriebssystem des Endgerätes alle erforderlichen Funktionen (z.B. Programmumschaltung, Lautstärkeeinstellung, EPG, PVR, Service–Informationen,…) für Applikationen zur Verfügung.

• Eine Middleware stellt eine Schnittstelle für die Bedienoberfläche [graphic user interface (GUI)] zur Verfügung. Dabei kann es sich sowohl um native (d.h. im Gerät fest implementierte) als auch um interpretierte (d.h. extern zugeführte und vom Gerät ausgeführte) GUIs handeln.

• Eine Middleware kann einen API-Layer für eigene und/oder externe Applikationen zu Verfügung stellen.

• Eine Middleware kann APIs von Dritten (z.B. HbbTV) ein- und anbinden.

• Eine Middleware interagiert mit Hardware und Applikationen. Die Middleware kann hardwaregebundene Funktionen enthalten (z.B. EPG).

Der Begriff Middleware ist hier enger gefasst als bei den Middleware-Anbietern. HbbTV, MHP oder MHEG 5 sind aus Sicht der Endgerätehersteller APIs, die auf der Middleware des Endgerätes aufsetzen. Abhängig von den Funktionen des Endgerätes kann auch überhaupt keine Software im Sinne einer Middleware vorhanden sein.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 22

Das folgende Bild zeigt ein Beispiel für die Architektur eines hybriden Endgerätes mit Middleware, das sowohl Rundfunksignale nach DVB-Standard empfangen als auch Applikationen aus dem Internet darstellen kann, wobei sich beide mittels interaktiver Lösungen miteinander verknüpfen lassen.

GUI A 3rd Party API oder P Browser C STB-Applications I SVG/HTML A / C/C++ API L D I R Teletext RCU Media- SI- EPG Data Processing N M Modul Modul center Modul Modul base U L M FrontEnd BackEnd CI SI SI RTSP X o W Modul Modul Modul Modul Receiver Modul a d DVB-Stack CA/DRM IP-Stack e r HadwareAbstractionsLayer HW-Driver

Hybrid-HW

Abbildung 3: Beispiel der Architektur eines hybriden Endgerätes

Bei den Endgeräteherstellern ist einerseits zwischen Herstellern von Set-Top- Boxen sowie IDTVs zu unterscheiden, andererseits zwischen Endgeräten, die für den Retail-Markt produziert werden und solchen, die im Auftrag von Plattformbetreibern gefertigt werden. Alle Endgerätehersteller entwickeln zunehmend hybride Endgeräte und verwenden teilweise eigene Middleware- Lösungen für Interaktivität.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 23

Folgende Aspekte führen dazu, dass heute produzierte Endgeräte die Nutzung eines immer größeren Angebots von Applikationen ermöglichen: a. Zunehmende Prozessorleistung und größere Speicherkapazität b. Große hochauflösende Flachbildschirme ermöglichen in Verbindung mit hybriden Endgeräten auch die optimale Darstellung von Bewegtbild- Angeboten aus dem Internet. c. Neue Geschäftsmodelle werden derzeit von den Marktteilnehmern (weiter) entwickelt. Dies erfordert allerdings entsprechende Prozessorleistung. d. Die Entwicklung von Endgeräten wird in erster Linie von den Endgeräteherstellern, unabhängig von den Plattformbetreibern vorangetrieben.

Die zusätzlichen Leistungsmerkmale hybrider Endgeräte erhöhen die Attraktivität für die Nutzer. Zudem bieten sie für die Endgerätehersteller über deren Smart-TV- Portale die Möglichkeit, Kooperationen mit Inhalteanbietern einzugehen und neue Geschäftsmodelle zu entwickeln. Hierzu gehören: a. Umsatzanteile an Werbeeinnahmen von Applikationen und EPG-Lösungen b. Vertrieb von Wetten [gambling] c. Integration von Online-Spielen d. Nutzung sozialer Netzwerke (z.B. Facebook) e. Inhalte-Vertrieb (Umsatzanteile an Video-on-Demand (VoD), Online-Presse, Wetterdienst, ...).

Solche Geschäftsmodelle befinden sich derzeit noch in der Phase der Entwicklung und werden je nach Endgerätehersteller mehr oder weniger aktiv verfolgt, wobei Umfang, Modalitäten sowie Erfolg solcher Modelle im Markt derzeit noch ungeklärt sind.

Die Anforderungen an eine Middleware aus Sicht der Endgerätehersteller lassen sich wie folgt beschreiben:

Bei der Entwicklung von Endgeräten spielen viele Parameter eine Rolle. Dazu gehören unter anderem die Größe des Zielmarktes, Funktionen und Varianten der

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 24

Endgeräte, Länderbesonderheiten, Zertifizierungen und verschiedene Plattformbetreiber. Abhängig davon entwickeln die Endgerätehersteller das jeweilige Gesamtkonzept eines Endgerätes (Hardware, Betriebssystem, ob/welche Middleware, …..).

Eine wesentliche Anforderung an eine Middleware aus Sicht der Gerätehersteller ist, unverhältnismäßige Zertifizierungsprozesse zu vermeiden, sowie die Kosten für die Implementierung gering zu halten. Dem Endgerätehersteller soll stets die unternehmerische Entscheidung überlassen bleiben, ob und mit welchem Funktionsumfang eine Middleware eingesetzt wird. Damit besteht gleichermaßen die Anforderung an Inhalteanbieter und/oder Plattformbetreiber, Inhalte (Programme und Dienste) so anzubieten, dass diese auch ohne Middleware nutzbar sind. Mit Blick auf den Wettbewerb zwischen den Endgeräteherstellern ist es wichtig, weiterhin Differenzierungsmöglichkeiten der Produkte zu bewahren. Da die Endgerätehersteller das wirtschaftliche Risiko für ihre Produkte tragen, dürfen sie in den Entwicklungsprozessen und der Produktgestaltung nicht mehr als unbedingt erforderlich eingeschränkt werden.

Die Möglichkeit, auf standardisierte Lösungen zurückzugreifen, ist für die Endgerätehersteller vorteilhaft, wenn die Endgeräte damit in allen gängigen Infrastrukturen ohne aufwändige Modifikationen funktionieren und keine Zulassungsprozeduren erfordern. Hierfür bedarf es allerdings der Unterstützung der Standards durch die Inhalteanbieter ohne zusätzliche Anforderungen. Standards, die von allen Marktteilnehmern unterstützt werden, liegen auch im Interesse der Nutzer. Idealerweise funktionieren damit alle Dienste und Applikationen unabhängig von Region und Anbieter.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 25

4.6. Interessen und Anforderungen der Inhalteanbieter (Programmveranstalter und Diensteanbieter)

Die Gruppe der Inhalteanbieter besteht aus den Programmveranstaltern (für das lineare Fernsehen) und den Diensteanbietern (für beliebige Applikationen). Diese Gruppe ist heute nicht mehr so homogen wie früher. Die wichtigsten Inhalteanbieter sind: a. Free-TV-Anbieter

Dazu gehören die öffentlich-rechtlichen Rundfunkanstalten und die privaten Free-TV- Programmveranstalter. Es handelt sich dabei schwerpunktmäßig um lineare Angebote. Es werden aber auch Angebote für andere Gerätetypen und solche für eine individuelle Mediennutzung (nicht-lineare) immer wichtiger, um im Markt ausreichend präsent zu sein. b. Pay-TV- Anbieter

Hierzu zählen in erster Linie die linearen und nicht-werbefinanzierten Angebote von großen Media- und Verlagshäusern, die umfangreichen Zugriff auf Urheberrechte von Inhalten haben. Auch hier spielen Formate und Angebote für eine nicht-lineare Mediennutzung auf vielfältigen Geräteplattformen eine wichtiger werdende Rolle. c. Anbieter nicht-linearer Inhalte

Es handelt sich um die Verbreitung video-naher Abrufdienste (wie z.B. VoD) und den Zugang auf hybride Endgeräte über das Internet. Mit der wachsenden Nutzung des Internets spielen diese Art der Inhalte auch für andere Branchen eine Rolle. Dazu zählen zum Beispiel Verlage und Plattformbetreiber, aber auch Firmen, die Internetdienste anbieten (Google, Facebook, …). Sie erwerben exklusive Übertragungsrechte und vermarkten die Inhalte dann entsprechend.

Für alle vorstehend angeführten Inhalteanbieter besteht die Notwendigkeit, attraktive Applikationen zu entwickeln und anzubieten. Mit der Entwicklung hybrider TV-Geräte bekommen diese Anwendungen eine sehr hohe Bedeutung. Dabei spielen personalisierte, abrufbare [on-demand] und interaktive

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 26

Applikationen eine wachsende Rolle. Das lässt sich an folgenden Beispielen verdeutlichen

• Auf dem HbbTV-Standard basierende sogenannte „red-button“-Applikationen aller großen Programmveranstalter (ARD, ZDF, RTL, Pro7Sat1,.), wie z.B. Mediatheken, Teletext, EPG, Abstimmungen [voting], Werbung und Verkaufsportale.

• Verschiedene Inhalteanbieter entwickeln spezifische VoD- Applikationen, die gemeinsam mit Endgeräteherstellern vermarktet werden (z.B. Netflix, Hulu, Acetrax, Lovefilm, Maxdome)

• Portale der Endgerätehersteller für Smart-TV als Zugang zu einer Vielzahl von mehr oder weniger medienorientierten Anwendungen, die ausschließlich über das Internet angeboten werden.

• Diensteanbieter sehen neue Applikationen auf dem Smart-TV-Markt durch Werbevermarktung, Suchmaschinen und andere Maßnahmen (z.B. Google, Apple, Microsoft, …)

Für alle Inhalteanbieter ist die Erzielung möglichst großer Reichweiten wichtig. Daraus folgt, dass die technischen Voraussetzungen auf den Endgeräten möglichst einheitlich sein sollten, sie also idealerweise über standardisierte und frei zugängliche Schnittstellen (APIs) verfügen. Der von den APIs bereitgestellte Funktionsumfang muss die Anforderungen an moderne und attraktive Applikationen erfüllen.

Darüber hinaus sind technische Standards essentiell, um sowohl die verschiedenen Geschäftsinteressen der Anbieter linearer TV-Angebote gegenüber den Interessen der Plattformbetreiber zu schützen, als auch der Dynamik der Entstehung neuer Geschäftsmodelle von Inhalteanbietern durch gesicherte Rahmenbedingungen ausreichend Entwicklungsmöglichkeiten zu bieten

Insbesondere Free-TV-Anbieter sehen in der eigenständigen Gestaltung und Kontrolle der gesamten Präsentation als auch der Navigation der mit einem

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 27

Programm zusammenhängenden Applikationen eine fundamentale Anforderung, die nur durch offene Standards gewährleistet werden kann.

Dies ist ein wesentlicher Grund, warum sich die Free-TV-Anbieter sehr schnell auf den Standard HbbTV geeinigt haben. Reine OTT-Portaldienste (wie Netflix, Hulu und Amazon) haben sich dagegen den technischen Rahmenbedingungen von individuellen Middleware-Strukturen angepasst. Die „neuen“ Marktteilnehmer mit ihren Systemplattformen (wie Google, Apple und Microsoft) streben hingegen eine hohe vertikale Durchdringung des Marktes an.

Auch wenn sich Inhalteanbieter in den angeführten Aspekten grundsätzlich einig sind, so gibt es doch wegen der differenzierten Geschäftsmodelle unterschiedliche Schwerpunktbildungen, die sich auch auf die technische Infrastruktur auswirken

4.6.1. Sichtweise von Sky Deutschland

Für den Inhalteanbieter Sky Deutschland steht der zahlende Kunde als Nutzer im Mittelpunkt aller Innovationen. Dafür erwartet dieser ein Höchstmaß an Ausfallsicherheit und Zuverlässigkeit der angebotenen Inhalte. Dies gilt insbesondere für zeitkritische Angebote wie Live-Sportübertragungen. Bei Ausfällen oder anderen technischen Problemen wendet sich der Nutzer unmittelbar an den Kundendienst von Sky Deutschland. Technische Probleme bedeuten daher Unannehmlichkeiten für den Nutzer und Kosten für Sky Deutschland.

Sky Deutschland strebt daher an, die Erwartungen seiner Kunden an ein perfektes Produkterlebnis zu erfüllen. Dafür müssen allerdings folgende Voraussetzungen erfüllt sein:

• Die Technik muss in sich so konsistent wie möglich sein. Nur so können Komplikationen ausgeschlossen werden, wenn unterschiedliche technische Konfigurationen auf dem Markt vorhanden sind (zum Beispiel durch die Installation unterschiedlicher Applikationen). Das Ziel ist es, die Stabilität des Sky-Angebots zu gewährleisten. Die Analyse und Behebung von Fehlern wird für die Sky-Hotline erschwert, wenn zunächst unterschiedliche

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 28

Konfigurationsmöglichkeiten des Endgeräts beim Kunden erfragt werden müssen und nicht von einem einheitlichen Angebot bei allen Nutzern ausgegangen werden kann.

• Anwendungen von Dritten auf dem Angebot von Sky müssen daher bestimmte Voraussetzungen erfüllen. Grundlage für solche Anwendungen ist zunächst einmal eine kommerzielle Vereinbarung auf der Basis von nicht diskriminierenden, fairen und angemessenen Konditionen. Dies gilt insbesondere vor dem Hintergrund der Investitionen von Sky in die Technik sowie der damit verbundenen laufenden Kosten. Außerdem muss durch einheitliche und effiziente Testmethoden ein kontrollierter Zugriff sichergestellt werden, so dass die Produktqualität und -stabilität und die Sicherheit der Sky-Angebote durch den Einsatz von Applikationen Dritter nicht beeinträchtigt werden. Ein optimierter Kostenansatz für diese Tests ist dabei für Sky unerlässlich.

• Als Inhalteanbieter im Pay-TV-Umfeld muss Sky sein Geschäftsmodell auf einer langfristigen Kalkulation aufbauen. Für ein attraktives Angebot sind hohe Vorlaufinvestitionen notwendig, die vor allem mittels der Kunden- Abonnements refinanziert werden.

• Darüber hinaus sorgen auch Vereinbarungen und Verträge von Sky mit Lizenzgebern dafür, dass für die Umsetzung der Anforderungen an die Form der Inhalteverwertung bestimmte Restriktionen gelten. Diese gehen an einigen Stellen über die Beschränkung des reinen Inhaltezugriffs hinaus und können sich auf die gesamte Nutzererfahrung [user experience] beziehen. Die Einschränkungen des Vorspulens von Aufzeichnungen von HD+ -Programmen verdeutlichen, dass sich solche Restriktionen nicht nur auf das Angebot von Sky beschränken. Die hochwertigen Sky-Angebote sind zudem einem erhöhten Risiko der Piraterie ausgesetzt, dem mit einem zusätzlichen Aufwand bezüglich der Sicherheit der gesamten Infrastruktur begegnet werden muss.

• Letztendlich spielt neben Qualität, Stabilität und Sicherheit des Angebots, der Wirtschaftlichkeit, dem Schutz der Investitionen und der Dienstgüte

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 29

[quality of service (QoS)] auch die Zukunftssicherheit für Sky eine entscheidende Rolle. Letztere ermöglicht ein inhaltlich wie technisch entwicklungsoffenes Angebot.

Den geschilderten Anforderungen trägt die Middleware „Fusion“ von NDS Rechnung, die auch von anderen internationalen Pay-TV-Anbietern (z.B. DirecTV, Viasat) in anderen Märkten eingesetzt wird, wie zum Beispiel den Mitgliedern der Sky-Familie BSkyB und Sky Italia. Damit können Synergien über die Grenzen einzelner Märkte in Europa hinaus genutzt werden. Demgegenüber müssen Standards wie HbbTV als (derzeit noch) zu elementar angesehen werden, da sie zum Beispiel kein ausreichendes DRM1 zum Schutz der Inhalte ermöglichen, wie es für das Geschäftsmodell von Sky unabdingbar ist.

Dem Kunden von Sky bleibt stets die Wahl, ob er sich für ein zuverlässiges Angebot mit einer geregelten Nutzererfahrung [user experience] entscheidet oder ob er lieber den Weg einer flexibleren (aber damit auch anfälligeren) selbstkonfigurierten Lösung geht, wie z.B. den Empfang von Free-TV- Programmen auf einem Computer (PC, Laptop, Notebook, Tablet, …..)2. Hierbei nimmt der Nutzer in Kauf, dass ihm bei Problemen keine eindeutig definierten Ansprechpartner für die Fehler-Analyse und –Behebung zur Verfügung stehen. Demgegenüber bieten integrierte Lösungen, wie sie auch im weniger traditionellen Medienumfeld zum Beispiel von Apple und Google angeboten werden, dem jeweiligen Anbieter eine Möglichkeit der Einflussnahme auf die gesamte Nutzererfahrung [user experience] und somit auf die Erfüllung der daran geknüpften hohen Erwartungen der Kunden.

Es ist fraglich, ob überhaupt Vergleiche mit anderen Marktsegmenten berechtigt sind. Denn trotz der Konvergenz von Broadcast, Broadband,

1 HbbTV unterstützt bereits in Version TS 102 796 v1.1.1. CI+ und mit der Version v1.2.1 seit Oktober 2012 auch eine direkte Anbindung an 2 DRM-Systeme.

2 Bei HbbTV-Angebote auf hybriden Empfangsgeräten hat der Programmveranstalter die volle Kontrolle über die „user experience“, es gibt keine Notwendigkeit einer „Selbstkonfiguration“.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 30

Computer und Telekommunikation beschränkt sich der Ruf nach eventueller technischer Vereinheitlichung häufig vornehmlich auf den traditionellen Broadcast-Bereich. Niemand käme aber je auf den Gedanken, z.B. Android als verbindliches Betriebssystem auf allen Smartphones zu verlangen.

All diese Betrachtungen spielen auch vor dem Hintergrund eine Rolle, dass Sky durch neue Angebote wie z.B. Sky Go mittlerweile nicht nur die Funktion eines klassischen Programmanbieters ausfüllt, sondern zunehmend auch Angebote nicht-linearer Inhalte über Datennetze und Telekommunikations- Infrastrukturen (3PPG) in sein Portfolio aufgenommen hat.

Nachfolgend die Definitionen der vier Begriffe durch Sky Deutschland

Middleware bezeichnet jede Software, die anderer Software das Zusammenspiel ermöglicht. Dies geschieht häufig so, dass die Komplexität der interagierenden Software und ihre Infrastruktur verborgen werden.

API bezeichnet den Satz von Schnittstellen, den eine Middleware ihren Applikationen zur Verfügung stellt. Dabei definiert ein API nur die Anbindung auf Quelltextebene.

Applikation bezeichnet eine Software zur Lösung von anwenderbezogenen Aufgaben und Problemen, die nützliche und/oder gewünschte Funktionen ermöglicht bzw. unterstützt.

Funktion bezeichnet die Aufgabe einer Applikation, die sie zu erfüllen hat.

4.6.2. Gemeinsamkeiten der Inhalteanbieter

Aus Sicht der Inhalteanbieter lassen sich die folgenden Kernanforderungen an ein Middleware-System identifizieren:

• Essentiell sind standardisierte und offen zugängliche Anwendungs- Programmierschnittstellen (API),

• damit Anwendungen nur einmal entwickelt werden müssen und unmittelbar auf allen marktrelevanten Geräten ablauffähig sind und

• damit sich ein Wettbewerb zwischen Middleware-Anbietern entwickeln kann, der zu einem ökonomischen Regulativ wird.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 31

• APIs zu leistungsfähigen und allen „State of the art“-Funktionalitäten müssen den Inhalteanbietern zugänglich sein. Alle relevanten funktionalen Anforderungen der Inhalteanbieter müssen unterstützt und offen zugänglich sein. Authentifizierten Applikationen muss der Zugriff auf alle erforderlichen Ressourcen eines Endgerätes möglich sein.

• Unterstützung der Implementierung von Middleware in Endgeräten durch geeignete Testumgebungen. Die Interoperabilität der Implementierungen muss gewährleistet sein, ggf. durch einen geeigneten Zertifizierungsprozess (z.B. Selbst-Zertifizierung).

• Nutzer wenden sich bei Fehlern an den Kundenservice ihres Vertragspartners. Fehlerdiagnose und -behebung sind davon abhängig, dass die technischen und operativen Anwendungsmerkmale ein hohes Maß an Übereinstimmung aufweisen, da bei der Fülle von Endgeräten und Inhalte-Angeboten sonst keine Transparenz hergestellt werden kann. Solche Standards sind essentiell, um eine Verunsicherung der Nutzer und damit eine potenzielle Ablehnung der Inhalte-Angebote zu vermeiden.

• Diskriminierungsfreie Präsentation von Applikationen, die durch andere parallel laufende Applikationen nicht beeinträchtigt werden darf. Die Integrität von Applikationen muss gewährleistet sein.

4.7. Interessen und Anforderungen der Nutzer

Die Integration der unterschiedlichen technischen Infrastrukturen hat sich in der Vergangenheit zumeist zu Lasten der Nutzer (=Verbraucher) vollzogen. So ergaben sich bei digitalen Endgeräten oft Investitionsrisiken nicht nur mit Blick auf die technisch begrenzte Lebensdauer, sondern auch hinsichtlich ihrer beschränkten Einsetzbarkeit bei unterschiedlichen Infrastrukturen und / oder Plattformen. Dass es für den Nutzer trotz oder gerade wegen der großen Zahl von Labels auf den Endgeräten in der Regel intransparent bleibt, welche technischen Spezifikationen als Standards anerkannt und indikativ zu gelten haben und welche für rein proprietäre Systeme stehen, macht die Auswahl des passenden Endgerätes nicht leichter.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 32

Generell ist der Nutzer zumindest in der linearen Fernsehwelt nicht daran gewöhnt und auch nicht gewillt, sich mit den Tücken komplexer technischer Infrastrukturen oder Endgeräte auseinander zu setzen. Infolge des zunehmenden Einsatzes proprietärer Systeme bei interaktiven Applikationen haben die Nutzer allerdings mit zahlreichen Problemen zu kämpfen. Dazu gehören unter anderem:

• Eine große Endgerätevielfalt bei gleichzeitig geringer Produkttransparenz

• Eine zu geringe Prozessorleistung und Speicherkapazität für die Abbildung interaktiver Applikationen

• Eine für viele Applikationen unzureichende Auflösung der Bildschirme

• Eine nicht störungsfreie Übertragung von Video, Audio und Daten infolge unzureichender Übertragungskapazität des jeweiligen Netzes. Dies betrifft OTT-Dienste, die über „unmanaged networks“ verbreitet werden, also Netze, die dem Nutzer keine Bandbreite und / oder „Quality of Service (QoS)“ garantieren.

Art und Umfang der Nutzung multimedialer Inhalte haben sich zwar aus Sicht des herkömmlichen Fernsehens kaum geändert. Das interaktive Fernsehen ist jedoch nicht mit einer angestrebten und auf entsprechenden Geschäftsmodellen basierenden personalisierten Mediennutzung vergleichbar. So gilt:

• Der Umgang mit personalisierten, interaktiven Medienangeboten ist im Internet gelernt und damit vielen Nutzern bekannt.

• Viele Nutzer unterscheiden kaum noch zwischen linearem Fernsehen und Medienangeboten aus dem Internet. Sie wünschen daher auch mehr Wahlfreiheit auf dem Fernseher.

• Eine größere inhaltliche Vielfalt und die Entwicklung neuer Formate treiben die Innovationen im Bereich der Übertragungsnetze und Endgeräte.

• Eine geringere Abhängigkeit von festgelegten Programmabläufen verändert bisherige Sehgewohnheiten und generiert neue Bedürfnisse beim Nutzer.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 33

• Die Nutzer erwarten einen umfassenden und Zugang zu Programmen und Diensten aller Art, sowie die freie Wahl ihrer Endgeräte und einen uneingeschränkten Umgang mit diesen.

Daher kommt es aus Sicht der Verbraucherzentrale Bundesverbandes (VzBv) bei der Middleware entscheidend darauf an, sich an den aufgezeigten Kriterien zu orientieren. Denn nur dann wird es gelingen, eine Zersplitterung des Marktes zu verhindern, den Wettbewerb der Inhalteanbieter unabhängig von Plattformen zu fördern und bei den Nutzern Akzeptanz für die Angebote zu gewinnen. Es gilt also, eine nutzerorientierte und intuitiv bedienbare Bedienoberfläche zu schaffen, sowie den Zugang zu allen Inhalten auf dem betreffenden Endgerät zu ermöglichen. Es darf weder ein Medienbruch, noch ein Ausschluss einzelner Programme oder Dienste geben. Das Endgerät muss dabei in der vollständigen und alleinigen Kontrolle des Nutzers verbleiben.

Wesentlich durch OTT und PVRs getrieben, gibt es einen zunehmenden Trend zur zeitlich und inhaltlich individuelleren Gestaltung des Fernseh- und Dienstekonsums. Elektronische Programmführer (EPG) und Recommendation Engines, soweit von unabhängiger Seite angeboten bzw. individuell einstellbar, können es dem Nutzer erleichtern, in der heute schwer überschaubaren Medienvielfalt, zu navigieren und interessante Inhalte aufzufinden. Damit unvereinbar sind die Bestrebungen einzelner Anbieter, wesentliche Nutzungsmöglichkeiten nicht zuzulassen. Dazu gehört zum Beispiel das Sperren von Kardinalfunktionen beim PVR wie Vorspulen oder Aufzeichnen.

Die durchschnittliche TV-Nutzungsdauer ist weiter ansteigend. Trotz des sehr großen Internetangebots decken zumindest bei der Unterhaltung noch immer eine Vielzahl frei empfangbarer (=unverschlüsselter) TV-Programme und die verschlüsselten Pay-TV-Angebote die Wünsche der Nutzer weitgehend ab. Eine schnelle Abkehr vom bekannten linearen Nutzerverhalten und eine Hinwendung zu ausschließlich nicht-linearen Verhaltensformen ist daher nicht zu erwarten. Wer interaktiv sein möchte, wird dies am PC, Laptop, Notebook, Tablet oder Smartphone tun. Dennoch wird es auch in Zukunft ein anhaltend hohes Interesse am analogen Teletext geben.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 34

Weitere kritische Punkte, die einer breiten interaktiven Nutzung multimedialer Inhalte auf Endgeräten entgegenstehen:

• Der Nutzer wird in der Regel beim Kauf der Endgeräte nicht über Einschränkungen bei deren Anwendung informiert.

• Der Nutzer will in der zeitlichen und örtlichen Nutzung von Inhalten und Endgeräten nicht eingeschränkt sein.

• Die meisten Endgeräte weisen nur eine Schnittstelle CI+ auf, bei der Schnittstelle CI waren es dagegen meist zwei.

• Auf CI+-Modulen ist nur ein CA-System zugelassen, bei CI-Modulen waren es bis zu zwei.

• Bei Endgeräten mit zwei oder mehr Tunern lässt sich nicht gleichzeitig ein verschlüsseltes Programm aufzeichnen und ein anderes verschlüsseltes Programm über Flachbildschirm oder Videoprojektor wiedergeben.

• Es gibt keine Gewähr einer anbieterübergreifenden Mindestfunktionalität.

• Oft besteht die Möglichkeit einer umfassenden Kontrolle über das Endgerät durch den Inhalteanbieter oder Plattformbetreiber ohne vorherige Zustimmung des Nutzers.

• Der Nutzer hat auf bestimmte Prozesse bei der Endgerätenutzung keinen Einfluss (z.B. Firmware-Update, Aktivierung von HD+ , …..). Er erhält meist auch keine Information darüber.

Der Nutzer erhält meist keine Informationen darüber, welche Daten bei den interaktiven Applikationen erhoben und wofür diese verwendet werden. In der Regel wird vorher auch seine Zustimmung nicht eingeholt.

4.8. Interessen und Anforderungen weiterer Marktteilnehmer

Die bisher aufgezeigten Aspekte sind auch für neue Gruppen von Marktteilnehmer relevant. Hierzu gehört insbesondere die intelligente Heimvernetzung Als ein Beispiel ist im Anhang “Smart Metering“ angeführt.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 35

4.9. Zusammenfassung der Anforderungen und der Positionen der Marktteilnehmer

Wie vorstehend dargestellt, haben die verschiedenen Marktteilnehmer, also Plattformbetreiber, Middleware-Anbieter, Systemanbieter, Endgerätehersteller sowie Inhalteanbieter verschiedene Interessen und Anforderungen in Bezug auf Middleware, API, Applikationen und Funktionen.

Endgeräte bilden die Brücke für den Zugriff auf Inhalte durch die Nutzer. Die in vielen Endgeräten integrierten Middleware-Lösungen sind für die weitere Entwicklung der digitalen Welt von entscheidender Bedeutung. Damit können den Nutzern neue Dienste verfügbar gemacht werden (z.B. EPG, VoD, Mediatheken, Apps, Portale, Werbung etc.). Deshalb haben die Marktteilnehmer in der Wertschöpfungskette der Middleware zunehmend Aufmerksamkeit geschenkt.

Eine zunehmende Bedeutung hat die Auswahl der Middleware in den vergangenen Jahren für die Plattformbetreiber erlangt, wobei man zwischen solchen mit und ohne eigene Netzinfrastruktur unterscheiden muss. Der Großteil stattet seine Endgeräte schon mit firmenspezifischen Systemlösungen für Middleware aus (u. a. von NDS, Microsoft, Alcatel-Lucent), die sich voneinander unterscheiden.

Dabei achten Plattformbetreiber mit eigener Infrastruktur, bei denen im Endgerät Funktionen des Netzabschlusses realisiert sind, darauf, dass die Endgeräte ein Mindestmaß an Einheitlichkeit aufweisen, um einen hohen Qualitätsstandard beim Nutzer garantieren zu können. Aus Sicht dieser Plattformbetreiber darf der Einsatz und die Fortentwicklung der Middleware nicht durch regulatorische Vorgaben rund um die Middleware, API und den Funktionen behindert werden.

Plattformbetreiber ohne eigene Infrastruktur müssen Endgeräte für unterschiedliche Infrastrukturen anbieten. Die Funktion einzelner Applikationen sowie die Dienstgüte (QoS) hängen stark von der Zusammenarbeit der verschiedenen Marktteilnehmer ab.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 36

Wegen der unterschiedlichen Ausgangssituationen (bezüglich Einheitlichkeit, Erweiterbarkeit und Anwendbarkeit) werden unter anderem folgende Anforderungen erhoben:

• Stabiler Zugang für den Nutzer • „state-of-the-art“ Funktion der angebotenen Applikationen • Innovationsfähigkeit für neue Geschäftsmodelle • Vielfalt der Applikationen • Keine Festschreibung von Standards • Kostengünstige Lösungen durch Wettbewerb • Zukunftssicherheit durch lange Lebensdauer der Endgeräte

Middleware-Anbieter haben ein Interesse daran, dass ihre Lösungen auf verschiedenen Endgeräten unterschiedlicher Hersteller ohne Anpassungen von Applikationen laufen können. Das wird von einigen Middleware-Anbietern dadurch erreicht, dass sie ihre Lösung für Middleware zusammen mit ihren zugleich angebotenen CA-System an die verschiedenen Chipsätze adaptieren. Um die Plattformbetreiber als ihre Hauptkunden langfristig an sich zu binden, müssen die Middleware-Anbieter gemäß deren Marktanforderungen flexibel und schnell agieren sowie zugleich kundenspezifische Anpassungen gering halten. Der derzeitige Trend hin zu Browser-Lösungen, die auf Internetstandards basieren, stellt derartige Kooperationsmodelle zwischen Middleware-Anbieter und Plattformbetreiber vor Herausforderungen.

Eine neue Gruppe bilden die Systemanbieter, die primär Ende-zu-Ende- Systemlösungen im Portfolio haben. Hierbei handelt es sich um cloud-basierte Lösungen, die in der Cloud vorgehaltene Inhalte und Anwendungen über unterschiedliche Netze für eine Vielzahl von Endgeräte-Typen verfügbar machen. Hierbei kommt keine klassische monolithische Middleware mehr zum Einsatz. Vielmehr gibt es über das jeweilige Gesamtsystem verteilte Softwarelösungen, für die sich allgemeine Anforderungen nur schwer definieren lassen.

Aus Sicht der Endgerätehersteller stellt die Middleware unabhängig von Hardware und Betriebssystem des Endgerätes alle erforderlichen Funktionen für Applikationen zur Verfügung. Zugleich stellt sie eine Schnittstelle für die

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 37

Bedienoberfläche bereit. Eine Middleware ist ein wichtiger Bestandteil moderner hybrider Endgeräte, die sowohl Rundfunksignale nach DVB-Standard empfangen, als auch Applikationen aus dem Internet darstellen können, wobei sich mittels interaktiver Lösungen beides verknüpfen lässt. Trotzdem sollte dem Endgerätehersteller stets die unternehmerische Entscheidung überlassen bleiben, ob und mit welchem Funktionsumfang eine Middleware eingesetzt wird, da sie das wirtschaftliche Risiko für ihre Produkte tragen und in ihren Entwicklungsprozessen und der Produktgestaltung nicht eingeschränkt werden sollten.

Die zusätzlichen Leistungsmerkmale hybrider Endgeräte erhöhen die Attraktivität für die Nutzer. Zudem bieten sie für die Endgerätehersteller über deren Smart-TV- Portale die Möglichkeit, Kooperationen mit Inhalteanbietern einzugehen und neue Geschäftsmodelle zu entwickeln. Solche Geschäftsmodelle befinden sich derzeit noch in der Phase der Entwicklung und werden je nach Endgerätehersteller mehr oder weniger aktiv verfolgt, wobei Umfang, Modalitäten sowie Erfolg solcher Modelle im Markt derzeit noch ungeklärt sind.

Die Möglichkeit auf standardisierte Lösungen zurückzugreifen, ist für die Endgerätehersteller vorteilhaft, weil die Endgeräte damit in allen standardisierten Umfeldern ohne aufwändige Modifikationen und Zulassungsprozeduren funktionieren. Hierfür bedarf es allerdings der Unterstützung des Standards durch die Inhalteanbieter ohne zusätzliche Anforderungen.

Für die Gruppe der Inhalteanbieter (Free-TV-Anbieter, Pay-TV-Anbieter, Anbieter nicht-linearer Inhalte) besteht die Notwendigkeit attraktive Applikationen zu entwickeln und anzubieten. Dazu spielen personalisierte, abrufbare (on- demand) und interaktive Applikationen eine wachsende Rolle.

Kernanforderungen an ein Middleware-System aus Sicht der Inhalteanbieter sind:

• standardisierte und offen zugängliche Anwendungs-Programmierschnittstellen (API),

• um Anwendungen nur einmal entwickelt zu müssen und auf allen marktrelevanten Geräten anbieten zu können

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 38

• damit sich ein Wettbewerb zwischen Middleware-Anbietern als ökonomisches Regulativ entwickeln kann.

• die Zugang zu allen „State of the art“-Funktionalitäten bieten

• Die Interoperabilität der Implementierungen muss gewährleistet sein.

• Standards sind essentiell, um eine Verunsicherung der Nutzer und damit eine potenzielle Ablehnung der Inhalte-Angebote zu vermeiden.

• Diskriminierungsfreie Präsentation von Applikationen, die durch andere parallel laufende Applikationen nicht beeinträchtigt werden darf. Die Integrität von Applikationen muss gewährleistet sein.

Für Sky-Deutschland spielt die Ausfallsicherheit und Zuverlässigkeit der angebotenen Inhalte eine zentrale Rolle. Deshalb muss die Technik in sich so konsistent wie möglich sein. Zukunftssicherheit muss auch gewährleistet sein, weil dadurch ein inhaltlich wie technisch entwicklungsoffenes Angebot ermöglicht wird

Den Anforderungen trägt die Middleware „Fusion“ von NDS Rechnung. Standards wie HbbTV müssen demgegenüber als (derzeit noch) zu elementar angesehen werden, da sie zum Beispiel kein ausreichendes DRM1 zum Schutz der Inhalte ermöglichen, wie es für das Geschäftsmodell von Sky unabdingbar ist.

Für zukünftige Anwendungsbereiche sind für Sky Deutschland standardisierte und offen zugängliche Anwendungs-Programmierschnittstellen (API) essentiell, deren Zugänglichkeit allen Anbietern gewährleistet sein muss. Der Lifecycle, eine diskriminierungsfreie Präsentation und die Integrität von Applikationen müssen sichergestellt sein (keine gegenseitige Beeinträchtigung durch andere Applikationen).

Der Nutzer ist zumindest in der linearen Fernsehwelt generell nicht daran gewöhnt und auch nicht gewillt, sich mit den Tücken komplexer technischer Infrastrukturen oder Endgeräte auseinander zu setzen. Viele Nutzer

1 Siehe Fußnote auf Seite 29

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 39

unterscheiden zudem kaum noch zwischen linearem Fernsehen und Medienangeboten aus dem Internet. Sie wünschen daher auch mehr Wahlfreiheit auf dem Fernseher. Die Nutzer erwarten einen umfassenden und diskriminierungsfreien Zugang zu Programmen und Diensten aller Art, sowie die freie Wahl ihrer Endgeräte und einen uneingeschränkten Umgang mit diesen.

Aus Sicht der Nutzer ist es wichtig, eine Zersplitterung des Marktes zu verhindern, den Wettbewerb der Inhalteanbieter unabhängig von Plattformen zu fördern, um breitere Akzeptanz für die Angebote zu gewinnen. Dazu gilt es, eine nutzerorientierte und intuitiv Bedienoberfläche zu schaffen und Zugang zu allen Inhalten auf einem Endgerät zu ermöglichen.

Wesentlich durch OTT und PVRs getrieben gibt es einen zunehmenden Trend zur zeitlich und inhaltlich individuelleren Gestaltung des Fernseh- und Dienste- konsums. Damit unvereinbar sind die Bestrebungen einzelner Anbieter, wesentliche Nutzungsmöglichkeiten nicht zuzulassen. Dazu gehört zum Beispiel das Sperren von Kardinalfunktionen beim PVR wie Vorspulen oder Aufzeichnen.

Die durchschnittliche TV-Nutzungsdauer ist weiter ansteigend. Trotz des sehr großen Internetangebots decken zumindest bei der Unterhaltung noch immer eine Vielzahl frei empfangbarer (=unverschlüsselter) TV-Programme und die verschlüsselten Pay-TV-Angebote die Wünsche der Nutzer weitgehend ab. Eine schnelle Abkehr vom bekannten linearen Nutzerverhalten und eine Hinwendung zu ausschließlich nicht-linearen Verhaltensformen sind daher nicht zu erwarten.

Fazit

• Verbindliche regulatorische Vorgaben bestimmter Standards von Middleware werden zurzeit von einem überwiegenden Teil der Marktteilnehmern nicht als sinnvoll erachtet, damit innovative Entwicklungen in einem sich dynamisch entwickelnden Markt möglich bleiben.

• Relevante Marktteilnehmer fordern einen offenen und diskriminierungsfreien Zugang zu standardisierten und leistungsfähigen „State-of-the-Art“-API- Funktionalitäten. Hierfür soll Applikationen der Zugriff auf die notwendigen Ressourcen des Endgerätes ermöglicht werden.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 40

• Die Marktteilnehmer gehen von einer sich fortsetzenden dynamischen Entwicklung der Hardware, Middleware und Applikationen aus. Auch wenn Applikationsentwickler möglichst alle Funktionen einsetzen wollen, müssen die Geräte / Systeme ökonomisch vertretbar im Markt positionierbar und betreibbar bleiben.

• Die Unterstützung der Implementierung von Middleware in Endgeräten durch geeignete, gemeinsam akzeptierte Testumgebungen wird allgemein angestrebt. Die Interoperabilität der Implementierungen müsste gewährleistet sein, was durch einen geeigneten Zertifizierungsprozess (z.B. Selbstzertifizierung) erfolgen kann.

• Es besteht Einvernehmen, dass ein “Lifecycle-Management“ von Applikationen notwendig ist. Hierzu müssen aber erst noch Aspekte wie z.B. die gegenseitige Beeinträchtigung, Kompromittierung, Sicherheit, Kooperationsverhalten, Kontrolle über Applikationen usw. im Detail betrachtet und bewertet werden.

5. Darstellung der Systeme im Markt

5.1. Lage und Aufgaben von Middleware und API in der Systemarchitektur

Ein Endgerät besteht aus den drei Hauptbausteinen Mechanik, Hardware und Software (Bild 5.1.1). Zum besseren Verständnis der verschiedenen Ansätze wird im Folgenden an Hand von aufeinander aufbauenden Diagramme beschrieben, welche Lage die Middleware in ihrer Rolle als Diensteschicht, die zwischen Applikationen und Betriebssystem vermittelt, in der gesamten Systemarchitektur einnimmt. Es ist dabei anzumerken, dass der Begriff Middleware nicht losgelöst von dem Begriff API verwendet werden kann.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 41

Abbildung 4: Prinzipieller Geräteaufbau

Das bisherige Verständnis basiert darauf, dass die Middleware Teil eines in sich abgeschlossenen Endgerätes ist (monolitisches Konzept). Die relevante Hardware ist oft auf einem Chip [System on Chip (SoC)] untergebracht. Daher entstehen zum Teil hoch verdichtete Software-Implementierungen, wo eine klare Trennung zwischen Diensteschicht bzw. Middleware und Betriebssystem kaum mehr möglich ist.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 42

Applikation

API 1 API 2 API n

Funktion A Funktion C Funktion E Funktion B Funktion D Middleware Funktion F

Betriebssystem

Gerät

Abbildung 5: Funktionen und Schnittstellen der Middleware

Eine Middleware deckt eine Vielzahl von Funktionen ab, die zum Teil untereinander vernetzt sind und über Anwendungs-Programmierschnittstellen interagieren. Eine Applikation kann je nach Komplexität auf eine einzelne oder mehrere API zurückgreifen (Abbildung 5).

Die über eine Middleware bereitgestellten Funktionen sind nicht notwendigerweise nur auf das Endgerät beschränkt. Damit Applikationen beispielsweise überhaupt auf das Endgerät gelangen können, muss auch server- seitig im Headend eine Middleware mit entsprechenden Funktionen und Schnittstellen vorgehalten werden. In jüngerer Zeit ist eine weitere Delokalisierung von Funktionen zu beobachten. Gerade über das Internet besteht die Möglichkeit, dass Applikationen auch mit Funktionen auf anderen Endgeräten interagieren (Multiscreen), oder eben Web-basierte Funktionen nutzen (Cloud).

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 43

In der bisherigen Darstellung sind Basiselemente einer Middleware und ihres direkten Umfeldes beschrieben worden. Schaut man sich die diversen Funktionen in einem Endgerät innerhalb und außerhalb der Middleware genauer an, so lassen sich in Verbindung damit unterschiedliche Gruppen von APIs feststellen (Abbildung 6).

Applikation A Applikation Z

VoD …

offenes offenes offenes offenes offenes API API API API API Internes API

Service- AV-Decoder Middleware System Protection SI-Decoder remote Download management Streaming DRM

Betriebssystem, Treiber, ……

Abbildung 6: Funktionen und Schnittstellen in Endgeräten

Externe Applikationen (grün) greifen über von außen zugängliche APIs (rot) auf Funktionen zu, die von verschiedenen Modulen (Software und / oder Hardware) bereitgestellt werden (gelb). Ein API kann Funktionen mehrerer Module zusammenfassen.

Ein System kann APIs auch nur intern bereitstellen (magenta), die dann auch nur von „internen“ Applikationen genutzt werden können. Applikationen (wie z.B. VoD) können sowohl als Third Party- Applikation oder als „interne“ Applikation realisiert sein. Die Entscheidung, welche APIs nach außen verfügbar gemacht werden, trifft der Systemanbieter oder ist aus dem jeweiligen Standard ersichtlich.

Technisch sind zunächst die eigentlichen Applikationen sowie deren grafische Darstellung (Rendering) zu unterscheiden. Applikationen können als eine Art Programm geschrieben werden, welche auf eine Zielplattform übertragen und dort ausgeführt werden (execution environment bzw. Laufzeitumgebung). Dafür

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 44

müssen die Endgeräte mit den entsprechenden Anwendungs- Programmierschnittstellen (API) ausgestattet sein. Diese bestehen in der Regel aus einem umfangreichen Softwarepaket zur Abdeckung der verschieden Funktionen. Die gesamte grafische Darstellung sowie die Nutzerschnittstelle [user interface (UI)] sind im Anwendungsprogramm codiert.

Als Alternative hat über das Internet der Interpreter im Browser eine Renaissance erlebt. Der Browser interpretiert HTML-Dateien und stellt deren Inhalt dar (declarative environment). Gerade für dynamische Seiten sind heute Ergänzungen mit unterschiedlichen Script-Sprachen (javascript) üblich, die über APIs weitere Funktionalitäten des Endgerätes nutzen. Damit können Browser vergleichbar leistungsfähig wie Anwendungsprogramme werden.

Aus technischer Sicht bedeutet das zwei Hauptarten von APIs, nämlich “executive“ und “declarative“. Daneben gibt es noch eine dritte Version, die mit der jeweils speziellen Endgeräteimplementation zusammenhängt. Es handelt sich um die “native execution“-API (Abbildung 7).

Applika Applika Applika Applika Applika Applika -tion -tion -tion -tion -tion -tion

Laufzeit- Deklarative Native umgebung Umgebung Ausführung

Middleware

Betriebssystem und Treiber

Hardware

Abbildung 7: Technische Grundformen von APIs

Die Software digitaler TV-Empfangsgeräte war anfangs wegen der begrenzten Ressourcen der Hardware sowie der Prozessoren als ein monolithischer Block

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 45

ausgebildet, um insbesondere die Leistungsfähigkeit der Softwarefunktionalitäten zu optimieren. Aus Kosten- und Leistungsgründen wird dieses Konzept nach wie vor im OEM-Bereich von einigen Plattformbetreibern auch für komplexere Softwarefunktionalitäten genutzt.

Applikationen und Schnittstellen zur Hardware waren hier eng miteinander verbunden. In einem solchen monolithischen Block kann eine spezifische Middleware im Sinne von Schnittstellen zu Applikationen und Betriebssystem ( Diensteschicht) nicht identifiziert werden.

Die verschiedenen Lösungen von Middleware erschienen zunächst als Gesamtpakete auf dem Markt. Hier finden sich standardisierte Lösungen z.B. auf Basis von MHP, aber auch proprietäre System, wie z.B. auf Basis von Nagra, OpenTV und NDS. Allerdings können auch proprietäre Systeme Teile von standardisierten Systemen enthalten. So lässt sich der Standard HbbTV, der in vielen Endgeräten integriert ist, auch als Komponente in proprietäre Systeme integrieren. Im Laufe der Zeit haben sich immer stärker auch modulare Lösungen etabliert, bedingt durch die unterschiedlichen Anwendungsbereiche sowie durch den Einfluss internet-basierter Technologien und den Einsatz der Cloud. Damit wird aus dem monolithischen Gesamtpaket ein Ansammlung einzelner Software- Pakete, deren Zusammenwirken nach außen als eine „neue“ Gesamt-Middleware erscheint. Derartige Lösungsansätze bauen zu großen Teilen aus standardisierten Web-Technologien auf, wobei auf die eingesetzten Versionsnummern der Systeme geachtet werden muss. Durch die unterschiedliche Kombination solcher Teilelemente entstehen allerdings wieder zueinander inkompatible Gesamtlösungen.

In neuster Zeit halten auch immer mehr „middleware-less-“Systeme im Endgerätemarkt Einzug. Bei diesen wandern die Middleware-Funktionen zum einen Teil in das Betriebssystem und der andere Teil in die Applikationen, z.B. Linux als Betriebssystem, wo alle weiteren Funktionselemente Teil der Applikation sind.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 46

5.2. Standardisierte Systeme für TV und das Zusammenwachsen mit dem Internet

Die nachfolgend gewählte Klassifizierung orientiert sich daran, dass es Systeme gibt, die in einem offenen, allen zugänglichen Prozess entwickelt werden, und allen Markteilnehmern zugängliche Standards in Abgrenzung zu Systemen, die von einem Marktteilnehmer individuell und ohne Öffentlichkeit entwickelt werden. Praktische Realsierungen im Markt können unterschiedliche Kombinationen aus beiden Welten enthalten.

5.2.1 GEM (MHP)

Im DVB-Projekt hat man schon früh damit begonnen, über das lineare Fernsehen hinaus sich auch mit interaktiven Anwendungen zu befassen. Anlass war u.a. die steigende Bedeutung elektronischer Programmführer [Electronic Program Guide (EPG)]. Vor allem Pay-TV-Anbieter waren hier aktiv und hatten sich für proprietäre Lösungen (z.B. OpenTV, Media-Highway,…) als Middleware entschieden. Deswegen sah man es als nötig an, neben den proprietären Lösungen für Middleware und APIs auch eine standardisierte Lösung zu haben, um der beginnenden Fragmentierung der Märkte entgegenzuwirken.

Die Arbeiten an der DVB Multimedia Home Platform (MHP) als offenem Middleware-Standard für interaktive Anwendungen begannen 1997 mit der Entwicklung der Commercial Requirements. Im Jahre 1999 wurde die erste Version der Technischen Spezifikation verabschiedet und 2000 als ETSI- Standard TS 101 812 publiziert. In der Folgezeit wurde der Standard ständig erweitert Es handelt sich hierbei um eine Execution Engine (einschließlich eines Declarative Environment), basierend auf APIs in der Programmiersprache Java mit einem umfangreichen Anwendungsbereich für die verschiedenen Nutzungsfelder (Targets), wie

• Broadcast (Kabel, Satellit, Terrestrik)

• IPTV

• Web-TV/ OTT

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 47

• Packaged Media (Blu-ray).

Das weltweite Interesse an einer standardisierten Lösung hat in verschiedenen Bereichen der Welt bald dazu geführt, angepasste Varianten zu entwickeln, die den jeweiligen regionalen und nutzungsspezifischen Bedürfnissen genügen. Diese nutzen eigene spezifische APIs auf einem Kern gemeinsamer APIs. Die US-Variante OCAP (Open Cable Application Platform) wurde unter dem Markennamen „tru2way“ im US-Kabelmarkt eingeführt und wird auch in Korea verwendet. Mit ACAP (Advanced Common Application Platform) wurde eine weitere US-Variante für den terrestrischen Bereich entwickelt. Eine japanische Variante wurde von ARIB (Association of Radio Industries and Business) für dessen interaktive Execution Engine (ARIB B23) geschaffen. Es lag daher nahe, einen Dachstandard GEM (Globally Executable Middleware) zu entwickeln, der die Gemeinsamkeiten der einzelnen Varianten in sich vereint. Eine Untermenge von GEM ist als Middleware- Standard BD-J in allen Blu-ray Playern enthalten und steckt so zum Beispiel auch in der PlayStation 3.

GEM hat inzwischen die Rolle des Basisstandards übernommen, in dem MHP als die Variante für Europa, Asien und Lateinamerika fungiert. Die Struktur von GEM mit den schon erwähnten Targets Broadcast, IPTV, OTT und Packaged Media ist im nachfolgenden Bild dargestellt. Einzelne Targets können durch Hinzufügen weiterer Elemente kombiniert werden. So ist aus der Kombination von Broadcast und OTT ein Hybrid Broadcast/Broadband Target entstanden. Weltweit ist GEM inzwischen in über 100 Mio. Endgeräten implementiert. Den Hauptanteil bilden Blu-ray Player. In Europa ist MHP nur in Italien zu einem Erfolg geworden.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 48

Abbildung 8: Aufbau von GEM

5.2.2 HbbTV

„Connected-TV“-Empfangsgeräte können zusätzlich zum Anschluss an ein Rundfunkübertragungssystem auch an das Internet angeschlossen werden. Völlig unabhängig und getrennt vom Rundfunkempfang bieten diese Geräte mit herstellereigenen Portalen den Zugang zu ausgesuchten Websites und zum Internet, wofür in der Regel eine Middleware mit eingebauten Browse- Lösungen verwendet wird, die zwar auf bekannten Internetstandards wie CE- HTML, Javascript etc. aufbauen, allerdings in unterschiedlichen und nicht kompatiblen Konstellationen. Diese Entwicklung widerspricht dem Wunsch nach einem horizontalen Markt. Es kam daher sehr schnell die Frage nach einer offenen standardisierten Lösung auf.

Mit der dafür erforderlichen Standardisierung hat sich seit 2008 eine Initiative unter der Bezeichnung „HbbTV“ (Hybrid broadcast broadband Television) befasst, aus der dann später das HbbTV-Konsortium hervorging. Das erste Ergebnis war eine Spezifikation, die im Juni 2010 als ETSI TS 102 796 V1.1.1 veröffentlicht wurde.

Der HbbTV-Standard stellt eine geschäftsmodell-neutrale Technologie- Plattform bereit, auf deren Basis alle Marktteilnehmer Anwendungen und

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 49

Portale entwickeln können. Ein wesentliches differenzierendes Merkmal des Standards ist die nahtlose Verzahnung von Rundfunk- und Internet- Funktionalitäten. HbbTV greift weitgehend auf bereits vorliegende technische Spezifikationen bzw. Standards zurück. Er basiert hauptsächlich auf den folgenden Grundbausteinen:

• CE-HTML (CEA-2014)

• Browser-Spezifikation des Open IPTV Forums (OIPF)

• DVB- Spezifikation zu Transport und Signalisierung von Applikationen (TS 102 809).

CE-HTML und die OIPF-Spezifikationen greifen wiederum auf die Spezifikationen des World-Wide-Web Consortiums (W3C) zurück. Die Zusammenhänge sind im nachfolgenden Bild veranschaulicht.

Browser

Interaktion Transport, Signalisier zw TV und Browser für

TS 102

Abbildung 9: Zusammensetzung des HbbTV-Standards

Der CE-HTML-Standard spezifiziert ein HTML-Profil für CE-Geräte und ist optimiert für die Darstellung von weitgehend den Web-Standards

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 50

entsprechenden HTML-/Javascript-Seiten auf CE-Geräten. CE-HTML enthält allerdings keine Elemente für die Einbindung dieses Systems in eine DVB- Umgebung. Das leistet die Browser-Spezifikation des Open IPTV-Forums. Mit den für HbbTV ausgewählten Elementen dieser beiden Spezifikationen sind die wesentlichen Browser-Funktionen definiert.

Weitere Zusatzfunktionen liefert der DVB-Standard „Signalling and carriage of interactive applications and services in hybrid broadcast/broadband environments“(ETSI TS 102 809). In enger Anlehnung an den MHP-Standard regelt dieser Standard, wie Applikationen, die aus einem TV-Programm heraus gestartet werden sollen, in den DVB-Multiplexen signalisiert werden. Damit wird u.a. sichergestellt, dass nur solche Applikationen gestartet werden können, die gemeinsam mit dem gewählten Programm signalisiert werden.

Es bestehen verschiedene Wege HbbTV-Applikationen zu starten. Aus dem linearen Programm heraus gibt es die Möglichkeit dem Zuschauer mittels eines „Red Button“ auf dem Bildschirm, der nach kurzer Zeit wieder verschwindet, die Verfügbarkeit von programmbezogenen Informationen [bounded application] zu signalisieren. Bei entsprechender Aktivierung werden die WEB-Inhalte der Applikation entweder über das Internet oder aus dem Broadcast-Karusell geladen. Zusätzlich ermöglicht HbbTV auch programmunabhängige Applikationen [unbound application], wie z.B. Elektronische Programmführer oder auch Spiele von Netz- und Plattformbetreibern oder ganze Applikations-Portale.

ETSI publizierte im November 2012 mit TS 102 796 v1.2.1 eine erweiterte Version des Standards Diese ergänzt einige für den Markt wichtige Funktionalitäten, u.a. Adaptive Streaming, basierend auf MPEG DASH und Advanced DRM.

Für die nächste Version HbbTV 2.0, deren Entwicklung inzwischen begonnen wurde, wird u.a. die Unterstützung eines zweiten Bildschirms [second screeen] und Weiterentwicklungen im Rahmen von HTML 5 erwartet.

In Deutschland wird HbbTV von einer großen Anzahl von Endgeräteherstellern (TV, STB) unterstützt. Eine große Zahl von Programmveranstaltern stellt eine

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 51

Vielzahl von Applikationen bereit. Daneben gibt es auch eine wachsende Anzahl “unbounded“-Applikationen von Webseiten-Anbietern in den Portalen bzw. App-Stores der Endgerätehersteller. HbbTV wird auch von Netzbetreibern unterstützt und von einigen auch als Basis eigener Angebote genutzt.

HbbTV hat inzwischen internationale Bedeutung erlangt und ist in mehreren europäischen Ländern, wie Frankreich, Spanien, Schweiz und Dänemark, operativ. Eine wachsende Anzahl von Ländern bereitet die Aufnahme von HbbTV-Diensten vor. Auch außerhalb Europas wächst die Bedeutung von und das Interesse an HbbTV. Insbesondere in Asien finden viele Testausstrahlungen statt, weil HbbTV Teil von Ausschreibungen ist.

5.2.3 OPIF

Das Open IPTV Forum (OPIF) wurde 2007 als internationales Gremium gegründet und hat sich die Entwicklung und Unterstützung von IPTV- Standards zur Aufgabe gemacht. Das OIPF betrachtet sowohl „managed services“ als auch „unmanaged services" (z.B. OTT). Das OIPF hat 61 Mitglieder aus allen relevanten Bereichen der Industrie (Stand: Juli 2012).

Die Hauptziele des OIPF sind

- interoperable Spezifikationen zur Übertragung von geschützten und ungeschützten Medieninhalten und interaktiven Diensten über offene und geschlossene IP-Netze und

- der Aufbau einer entsprechenden Endgeräte- und Dienstezertifizierung, um einen horizontalen Markt zu erreichen .

Im Rahmen dieser Arbeit sind bisher zwei aufeinander aufbauende Spezifikationen entstanden (Release 1 & 2). Schon in Release 1 wurden folgende Profile entwickelt, welche die Minimalfunktionalität von OIPF- konformen TV- Geräten zusammenfassen:

• Open Internet Profile (OIP)

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 52

• Baseline Managed Profile (BMP)

• Enhanced Managed Profile(EMP)

Das OIP (Open Internet Profile) adressiert OTT-Angebote die keine Unterstützung der Dienstgüte (QoS) im Netz oder dem Endgerät voraussetzen. Das BMP (Baseline Managed Profile) erweitert das OIP um Scheduled Content und Streamed VoD (managed und unmanaged). Des Weiteren sieht die Spezifikation den Software- Update der Geräte vor. Das EMP (Enhanced Managed Profile) fügt dem BMP native Unterstützung für QoS, Managed Networks (wie etwa IMS), ETSI-kompatible Broadband Content Guides und TR-069-konformes Remote Management hinzu.

Nachfolgend werden die in den beiden Releases behandelten Funktionen vorgestellt.

Release 1 (2010)

- Lineares Fernsehen, persönlicher Videorecorder, elektronischer Programmführer und hybride Programmverteilung (IPTV und Rundfunk)

- Inhalteabruf per Stream und per Download

- Programmbegleitende Inhalte und Inhalte ohne Programmbezug

- Kommunikationsdienste, Informationsdienste und deren Verflechtung mit den übertragenen Inhalten

Wie bereits im vorherigen Kapitel erläutert, bilden die OIPF-Spezifikationen die wesentliche Grundlage für den HbbTV- Standard.

Release 2 (2011)

- HTTP Adaptive Streaming von Live- und On-demand-Inhalten durch ISO MPEG DASH- Unterstützung

- Metadaten und Signalisierung von Notfalldiensten

- SIP-Unterstützung für Kommunikationsdienste

- DVB-basiertes Fast Channel Change und Retransmission

- Netzbasierter Videorecorder und zeitversetzes Fernsehen (timeshift)

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 53

- Weitere Funktionen beziehen sich auf personalisierte Inhalte und Lesemarken, Session/Service Transfer & Handover, Kontrolle & Beschränkungen von Trickplay und Play-out , Teilen von Inhalten zwischen einzelnen Nutzern, Inhalteerwerb, Unterstützung von Widgets für deklarative Anwendungen (Browser), mobile Geräte zur Fernbedienung des TV-Geräten und Set-Top-Boxen(STB) basierend auf DLNA, bessere Integration von CI+-basierten CA-Systemen, SAML- basiertes Single Sign-on.

In Zukunft arbeitet das OIPF zur Straffung seiner Arbeit an sogenannten Feature Packages (Spezifikationen von inhaltlich gut abgrenzbaren Funktionen mit klarer Positionierung gegenüber sämtlichen existierenden OIPF- Spezifikationen). Diese adressieren Marktanforderungen und technische Anforderungen (ggf. auch nur weniger OIPF-Mitglieder) und ermöglichen es, diese sehr schnell in das existierende OIPF-Rahmenwerk von Spezifikationen aufzunehmen.

In 2012 arbeitet das OIPF verstärkt an der Zertifizierung kompatibler Hardware und Software. Ein entsprechendes Zertifizierungsregime ist in enger Kooperation mit dem HbbTV-Konsortum im Aufbau befindlich.

5.2.4 MHEG

MHEG ist die Abkürzung für „Multimedia and Hypermedia Information Coding Experts Group“, eine gemischte Arbeitsgruppe von ISO und IEC. Der Standard ISO13522-5 bildet die Grundlage für MHEG, ETSI ES 202 184 beschreibt den aktuellen Stand.

Als MHEG-5 wird der 5. Teil des MHEG-Standards bezeichnet. Er beschreibt die Wiedergabe und Darstellung interaktiver Multimediainhalte auf Endgeräten, unabhängig von der zugrunde liegenden Hardware. MHEG-5 wird in UK, Irland, Australien, Neuseeland und Hongkong als Middleware eingesetzt. Für CI+ wird MHEG-5 ebenfalls verwendet.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 54

MHEG-5 ist eine deskriptive Sprache, ähnlich wie HTML. Allerdings wurde bei MHEG-5 der Schwerpunkt auf interaktive Multimediainhalte gelegt. Eine ressourcen-schonende Middleware war ein erklärtes Ziel bei der Definition von MHEG-5, um die Kosten für die Endgeräte niedrig zu halten.

MHEG-5 arbeitet objektorientiert und ermöglicht es deshalb, Objekte (z. B. Grafiken) gezielt auf dem Bildschirm zu platzieren. Ebenso können auch Videoinhalte skaliert und auf dem Bildschirm beliebig verschoben werden. Bild-, Ton- und Videoobjekte lassen sich synchronisieren und exakt zueinander ausrichten. Die MHEG-Applikationen werden im DS-MCC- Karussell übertragen und unterstützen auch einen Rückkanal.

5.2.5 Weitere Systeme

Es gibt weitere Systeme im internationalen Umfeld, die derzeit allerdings keine Relevanz für den deutschen Markt haben. Diese unterscheiden sich konzeptionell relativ wenig von den beschriebenen Systemen.

5.3. Lösungskonzepte für TV auf Basis etablierter Web- Technologien

Ab 2007 begannen einige TV-Hersteller damit, hybride TV-Geräte mit herstellereigenen Portalen zu ausgesuchten Websites und zum Internet auf den Markt zu bringen. Die in diesen Portalen aufgeführten Websites sind für den Empfang und die Wiedergebe auf TV-Geräten sowie die Navigation mit einer Fernbedienung optimiert. Dazu verwendet man in der Regel eine Middleware mit eingebauten Browser-Lösungen, wie sie schon für Internetanwendungen bekannt sind. Sie benutzen zwar bekannte Grundbausteine wie z.B. CE-HTML, Java, Javascript, allerdings in unterschiedlichen und nicht kompatiblen Konstellationen.

Viele TV-Endgerätehersteller nutzen als Software-Plattform eine Kombination von einem Linux-Derivat als Betriebssystem und einem Browser als Middleware. Jeder Browser unterstützt hierbei natürlich die jeweils gültigen internationalen

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 55

Technologiestandards, wodurch es ermöglicht wird, übergreifende Anwendungen für diese zu entwickeln. Grundsätzlich beherrscht jeder Browser dabei folgende Technologien:

• HTML oder CE-HTML (Struktur der Anwendung)

• CSS (Darstellung der Anwendung)

• Javascript (Logik der Anwendung)

Allein diese Technologien bieten jedoch noch keine TV-spezifischen Funktionen an. Die Geräte-Ansteuerung erfolgt durch innerhalb des Browser zur Verfügung gestellten Softwarebibliotheken, die von Entwicklern durch eine Javascript- Schnittstelle genutzt werden können.

Abbildung 10: Schematischer Aufbau einer Middleware-Plattform auf Basis von Linux- und Browser-Technologien

Der Umfang dieser Bibliotheken ist hierbei den Herstellern überlassen. Folgende Funktionen werden im Regelfall von diesen Schnittstellen bereitgestellt:

• Abspielen Tastenbelegung der Fernbedienung

• Kanalwahl (Tuning)

• Videoaufzeichnung

• Unterstützung von Streaming-Protokollen für Videosignale über IP

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 56

Daneben werden sowohl von Dritten bereitgestellte Bibliotheken, als auch offene Schnittstellen-Standards (insbesondere HbbTV) eingebaut.

Damit sind Kombinationslösungen entstanden, die einerseits HbbTV und damit einen horizontale Markt unterstützen und sich andererseits durch herstellerspezifische Anwendungen vom Rest des Marktes unterscheiden.

5.4. Cloud- basierte Lösungen

Die nächste Generation an Videolösungen sind cloud-basierte Online-Video- Plattformen. Diese erlauben es den Diensteanbietern eine flexible Lösung zu implementieren.

Damit ergeben sich • offene Schnittstellen, • modulare Bauweise, • Flexibilität bezüglich . neuer Bausteine und Client-Technologien, • Unterstützung agiler Weiterentwicklung, basierend auf neuen Anforderungen • und einiges mehr.

Abbildung 11: Modulare cloud-basierte Online-Video-Plattform

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 57

Eine Multiscreen-Plattform sollte den Prinzipien moderner Software-Entwicklung entsprechen, d.h. eine diensteorientierte Architektur [service oriented architecture (SOA)] aufweisen, bei der jeder Dienst bzw. jede Funktion einer Middleware in der Art entwickelt ist, dass sie flexibel erweitert werden kann.

Basierend auf dieser modularen Architektur kann die Gesamtlösung flexibel zusammengestellt werden und ermöglicht dem Diensteanbieter somit leichte Anpassbarkeit an die heutigen Anforderungen und existierende Systeme, sowie höchste Flexibilität für die Zukunft. Beispiele solcher modularer Funktionen sind: • Commerce • Content Management • Subscriber Management • Offer Management • Headend Funktionen • Content Syndication • Content Delivery Network (CDN) • Kundenapplikationen

Dies ermöglicht unter anderem auch die flexible Skalierung einzelner Komponenten. Ein Resultat dieser Modularität ist, dass eine solche Lösung als alleinstehende Plattform, aber auch als sogenannte Overlay-Plattform eingesetzt werden kann. Es ist die Abkehr von Limitierungen traditioneller Middleware-Systeme, die oft begrenzte Funktionalitäten bieten und als eine monolithische Plattform existieren, hin zu einer modularen und flexiblen Plattform, mit der sich kostenoptimiert neue Endkundendienste schnell einführen lassen. Dies ermöglicht den Diensteanbietern schnell auf neue Marktanforderungen reagieren zu können.

Gerade in der heutigen Zeit ist es außerdem wichtig, flexibel auf neue Endgeräte und Client-Technologien reagieren zu können. Dabei spielen standardisierte Ansätze (z.B. HbbTV-konforme Clients, HTML5-basierte Clients) ebenso eine Rolle wie

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 58

proprietäre Systeme (z.B. iOS, Connected-TV). Hinzu kommen die traditionellen, proprietären STB-Clients. Um auf die ständig wachsende Vielfalt reagieren zu können, sind unterschiedliche Ansätze für Client-Software notwendig. Das sind API für die Integrationen zu älteren, proprietären Lösungen und gerätespezifischen Clients (wie iOS- Apps), aber auch vorgefertigte Player Development Kits (wie Flash, HTML5, …). Damit werden nicht nur rein DVB-basierte Systeme unterstützt, sondern natürlich auch der stark wachsende Markt hybrider Lösungen. Zu diesen neuen Bausteinen kommen durch neue Geschäftsmodelle auch zusätzlich Anforderungen hinzu, wie beispielsweise Content Syndication. Dabei handelt es sich um die Möglichkeit des Zugriffs auf Inhalte anderer Plattformen und Quellen (z.B. Content-Partnern), aber auch das Ausspielen zu anderen Plattformen. Eng verbunden mit dieser Content-Syndication ist die Rechte-Syndication (Zeitfenster, Zugriffskontrolle von Videoinhalten), aber auch das Vorgeben sowie bewusste Freigeben von Werbenetzwerken.

Beispiele für Content-Syndication sind • Diensteanbieter mit Tochtergesellschaften in Regionen oder anderen Ländern, • Syndication des eigenen Contents in andere Plattformen, • Player-Einbindung in andere Plattformen oder Websites, • Nutzung von iTunes oder YouTube als Werbe- oder Verkaufskanal.

Um dem ständig wachsenden Wettbewerb von OTT-Anbietern ein Diensteangebot entgegen zu setzen und um die eigenen Kunden auch auf denjenigen Geräten zu erreichen, mit denen sie viel Zeit verbringen, gibt es neue Streaming-Technologien basieren auf Adaptive Streaming, um auch über „unmanaged networks“ Dienste anbieten zu können. Diese neue Streaming-Formate müssen natürlich ebenfalls von neuen Video- Plattformen unterstützt werden.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 59

Abbildung 12: Beispiele für Content Syndication

5.5. Firmenspezifische Systemlösungen

Die ersten Lösungen für APIs im Bereich des interaktiven digitalen Fernsehens - den Begriff Middleware gab es damals noch nicht – wurden ab Mitte der 90er Jahre von Plattformbetreibern im Pay-TV-Bereich entwickelt. Die Geschäftsmodelle basierten alle auf vertikalen Märkten mit proprietären Set-Top-Boxen, die mit proprietärer Software insbesondere proprietären Lösungen für CA-Systeme und APIs betrieben wurden. Eine erste Gruppe von interaktiven Anwendungen, für die APIs benötigt wurden, waren elektronische Programmführer. Die Entwicklungen wurden später in Technologieunternehmen ausgelagert, und von diesen zum großen Teil bis heute weiterentwickelt. So sind z. B. NDS MediaHighway und Nagra OpenTV entstanden. Es gibt heute eine Vielzahl proprietärer Industriesystemen im Markt, welche die in den vorangehenden Kapiteln beschriebenen Anwendungsbereiche abdecken. Sie haben sich zum großen Teil von ihren jeweiligen Anfängen deutlich weiterentwickelt und sich den Gegebenheiten der Technologie- und Marktentwicklung angepasst. So sind aus den ursprünglichen monolithischen, TV-zentrischen und endgerätbezogenen Ansätzen inzwischen modulare Ende-zu-Ende Systemkonzepte entstanden, bedingt durch die unterschiedlichen Anwendungsbereiche sowie durch den Einfluss internet-basierter Technologien und den Einsatz in der Cloud. Dazu ist in jüngster Zeit als weiterer Bereich noch die Anwendung von „Second Screen“

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 60

gekommen Viele dieser Lösungen greifen auf standardisierte Teilelemente insbesondere aus dem Web-Bereich zurück, werden jedoch in der Kombination und durch die Hinzunahme proprietärer Teilelemente insgesamt wieder proprietär. Mit dem Aufkommen von IPTV wurde die serverseitige Steuerung zu einem zentralen Element des Gesamtsystems. Eine Lösung bietet Microsoft Mediaroom. Hierbei handelt es sich eine Ende-zu-Ende IPTV- Systemlösung für managed und unmanaged Netze. Microsoft stellt im Rahmen ihres Produktes sämtliche erforderlichen Backend-Komponenten, sowie Client-Software für die unterschiedlichsten Endgeräte zur Verfügung. Die nächste Generation an Lösungen sind cloud-basierte Online-Video-Systeme. . Derartige Systeme, die es den Diensteanbietern erlauben, flexible Lösungen zu implementieren, werden unter anderm von Alcatel-Lucent und Cisco angeboten. Die globalen Player Google und Apple sorgen mit dem Markteintritt von GoogleTV und AppleTV für weitere Elemente in der Palette der proprietären Systeme. Beide Lösungen bauen auf den etablierten Betriebssystemen Android und iOS auf, die sich voll unter der Kontrolle der beiden Firmen befinden. Diese Kontrolle wird sich somit auch auf die Middleware-Systeme erstrecken.

5.6. Ausblick

Grundsätzlich stellt sich die Frage wie ein signifikanter Markt für Applikationen entwickelt werden kann. Dazu sind die entsprechenden technischen Systeme eine wichtige Voraussetzung. Wegen der Vielzahl der im Markt eingesetzten Systeme, proprietärer als auch standardisierter Natur, sind die Markterfolgschancen für Applikationen noch nicht abschätzbar, wobei der Markterfolg mehr ist als nur die Realisierung technischer Systeme, insbesondere von der Verfügbarkeit der entsprechenden Eco-Systeme abhängt.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 61

6. Vertiefende Bestimmung der Begriffe Im Folgenden werden die Begriffe „Middleware“, „Applikation“, „API“ und „Funktion“ auf Basis der in diesem Dokument beschrieben Entwicklungen vertieft.

Die Zusammenstellung der Sichtweisen der Marktteilnehmer macht deutlich, dass die genannten Begriffe zum Teil unterschiedlich interpretiert werden. Bei der Definition der Begriffe sollten diese daher von den spezifischen Anwendungsszenarien abstrahiert werden. Damit soll der Tatsache Rechnung getragen werden, dass all diese Begriffe in unterschiedlichem Kontext auch mit unterschiedlicher Tragweite verwendet werden. Zudem können einzelne Komponenten einer technischen Plattform nicht immer eineindeutig nur einem dieser Begriffe zugeordnet werden. Zum Beispiel kann eine Flash Engine entweder Bestandteil der Middleware sein oder eine Applikation darstellen.

Ausgangspunkt für die Definitionen der Begriffe in Kapitel 3 war der Bezug auf die Endgeräte. Hier fällt zunächst auf, dass eine konkrete und eindeutige Abgrenzung einer Middleware im Software-Stack eines Gerätes kaum möglich ist. Damit sind Standardisierungsprozesse in diesem Bereich schwierig. Hintergrund ist neben technischen Aspekten (Integrationstiefe) auch die strategische Frage, welche Funktionen verfügbar sein sollten. Bild 6.1 veranschaulicht dies grafisch. Geeigneter erscheint innerhalb des Software-Stacks eines Endgerätes von „Service Enablern“ zu sprechen, die relativ gut abgrenzbar sind. Die Middleware kann jedoch umfangreicher sein und sowohl Funktionen des Betriebssystems als auch von Applikationen einschließen.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 62

„Middleware“

Applikationen

„Service Enabler“

Spezifische Betriebssystem Software Schnittstellen (driver = Schnittstelle zur Hardware)

Special purpose Speicher Graphik Prozessor DeMUX AV Decoder RAM FLASH SoC

Tuner crypto I/O I/O I/O Power Hardware

Netzwerk - Anschlüße A/V I/O Tastatur DVB-C / S / T Ethernet CI+ HDMI SPDIF USB Antennen Mechanik

Abbildung 13: Service Enabler

Im Kern geht es darum, dass die Middleware Applikationen Anwendungs- Programmierschnittstellen (API) bereitstellt, über die Applikationen auf Funktionen der Middleware zugreifen können. Ein API kann hierbei Funktionen mehrere Software-Module einbeziehen.

Applikation A Applikation Z

VoD …

offenes offenes offenes offenes offenes API API API API API Internes API

Service- AV-Decoder Middleware System Protection SI-Decoder remote Download management Streaming DRM

Betriebssystem, Treiber, ……

Abbildung 14: Funktionen und Schnittstellen in Endgeräten

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 63

In den tatsächlichen Ausführungen sind heute zwei wesentliche Besonderheiten relevant.

Zum einen kann ein System APIs auch nur intern bereitstellen, die dann auch nur von Applikationen genutzt werden können, die explizit für diese API berechtigt werden. Damit kann erheblicher Einfluss auf die Gestaltungsspielräume von Inhalteanbietern genommen werden. Beispielsweise kann ohne Zugang zu Streaming-Funktionalität kein VoD-Service aufgebaut werden.

Zum anderen greifen in aktuellen technischen Entwicklungen Applikationen auf Funktionen zu, die nicht notwendigerweise vom Endgerät selbst bereitgestellt werden. Die älteste Variante sind Systeme, in denen ein Service-Headend Funktionen bereitstellt [managed services]. Insbesondere über die Internet- Technik kommen heute zwei weitere Modelle einer Dislozierung von Funktionen zum Tragen. Es ist möglich, dass Applikationen ergänzend auf Funktionen anderer Endgeräte zugreifen. Dies trifft zum Beispiel auf Anwendungen in der Heimvernetzung und bei Multiscreen-Applikationen zu. Funktionen können aber ebenso von einem cloud-basierten Server bereitgestellt werden. Insofern muss die Middleware unter Umständen als eine virtuelle Softwareschicht oder verteilte Softwareschicht angesehen werden.

Applikation

API API API API API

Funktion Funktion Funktion Funktion Funktion Funktion Funktion Funktion Funktion Funktion Funktion

Multistack device Service-headend Netzinfrastruktur Endgeräte

Abbildung 15: Verteilte Middleware

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 64

6.1.1. Middleware

Der Begriff Middleware in Empfangsgeräten für audiovisuelle Inhalte bezeichnet heute eine Software-Schicht, die umfangreiche Funktionen für Applikationen bereitstellen kann. Die Middleware kann proprietär oder standardisiert sein, je nach Anwendung und Zweck. Die Schicht ist im Wesentlichen oberhalb des Betriebssystems angesiedelt, eine klare Abgrenzbarkeit in der Umgebung ist je nach Implementierung aber nicht gegeben. Die Middleware stellt eine Verbindung zwischen unterschiedlichen funktionalen Modulen her. Für die Nutzung von Funktionen stellt die Middleware Anwendungs-Programmierschnittstellen (API) bereit, die aber nicht in jedem Fall von außen von Dritten unabhängig aufrufbar sind. Endgeräte können heute parallel über mehrere Middleware-Stacks verfügen. Darüber hinaus können Funktionen, die über die Middleware eines Endgerätes bereitgestellt werden, tatsächlich in einem Server-Headend oder auf einem anderen Endgerät ausgeführt werden.

Zunehmende Verbreitung finden heute deklarative Umgebungen (Browser), die aber mit Laufzeitelementen ergänzt sind (z.B. javascript). Unter diesem Blickwinkel können auch Browser in Zusammenwirken mit java-script APIs zu Systemfunktionen (z.B. AV-Player) als Middleware bezeichnet werden.

6.1.2. Applikation

Applikationen sind Software-Module, die auf der Basis eines bestimmten Middleware-Systems, Funktionen eines Endgeräts so zusammenschalten, dass für den Anwender der Applikation ein spezifischer Nutzen entsteht (z.B. EPG oder Wetter-Applikation). Applikationen können entweder integraler Bestandteil eines Endgerätes sein und werden dann vom Hersteller spezifiziert oder von Dritten auf dem Endgerät bereitgestellt. Applikationen greifen zur Realisierung von Funktionen über Anwendungs- Programmierschnittstellen (API) auf von der Middleware oder anderweitig vom System bereitgestellte Funktionen zu.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 65

6.1.3. API

API ist die Kurzform von Application Programming Interface und bedeutet übersetzt Anwendungs-Programmierschnittstelle. Es handelt sich um eine Software-Schnittstelle, die Applikationen den Zugang zu Funktionen des Endgerätes zur Verfügung stellt.

6.1.4. Funktion

Als Funktion bezeichnet man die Eigenschaften von Software-Modulen zur Interaktion und dem Datenaustausch zwischen ansonsten entkoppelten Software–Modulen (Applikationen, Betriebssysteme, Service-Schnittstellen). Es lassen sich bei den Funktionen unterschiedliche Gruppen bilden (z.B. Streaming, Download, Player-Control, Loader, Life Cycle Management).

7. Zusammenfassung

Die vereinfachte Definition der Software-Funktionen eines Endgerätes wie sie als erste Begriffsklärung in Abb.1 im Kapitel 3.1 in diesem Bericht eingeführt wurde, muss nach den Erkenntnissen der PG Middleware deutlich erweitert werden.

Zentrale Ursache ist, dass sich Vielfalt und Struktur von Endgeräten für audiovisuelle Inhalte erheblich erweitert haben. Dies beruht vor allem auf dem Markteintritt von neuen Playern mit grundsätzlich anderen Endgeräte-Architekturen.

Ausgangslage ist zunächst die Definition der Begriffe „Middleware“, „Applikation“, „API“ und „Funktion“ wie in Kapitel 3.1 beschrieben. Gegenüber dem Mandat der PG wurden hier bereits die Begriffe „Middleware“ und „API“ präzisiert und die zusätzlichen Begriffe „Funktion“ und „Applikation“ eingeführt. Middleware ist danach ein integraler Bestandteil der Software-Architektur eines Endgerätes. Es handelt sich um einen Software-Layer im Wesentlichen oberhalb des Betriebssystems, der über Anwendungs-Programmierschnittstellen (API) Funktionen für eigenständige Applikationen bereitstellt. Bislang beinhaltete Middleware lediglich eine Umgebung zum Ausführen von Applikationen.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 66

Entsprechend der Forderung des Mandats im Hinblick auf die Regelung des § 48 TKG „Interoperabilität von Fernsehgeräten“ eine inhaltliche Bestandsaufnahme der Marktsituation vorzunehmen wird zunächst in Kapitel 4 eine umfangreiche Zusammenstellung der Interessen und Anforderungen und Marktteilnehmer geliefert. Dem folgt ergänzend in Kapitel 5 eine Darstellung der Systeme im Markt.

In der Gruppe der Marktteilnehmer haben Plattformbetreiber, Middleware-Anbieter, Systemanbieter, Endgerätehersteller Inhalteanbieter und Nutzer ihre Interessen zum Ausdruck gebracht. Was die Ausgestaltung einer Middleware angeht, so sind die Interessen der Marktteilnehmer je nach Marktsegment und Geschäftsmodell sowie nach Endgeräteart (Rundfunk, Internet, hybrid) unterschiedlich. Daraus resultiert auch eine vielschichtige, an individuellen Bedürfnissen ausgerichtete technische Infrastruktur im Markt. Auch die erwartete Marktentwicklung spielt eine Rolle, wobei grundsätzlich die Fähigkeit offener bzw. standardisierter Lösungen zur Schaffung großer Märkte und die Umsetzung spezifischer Lösungen zur Unterstützung des jeweiligen Geschäftsmodells verfolgt wird.

Nutzer nehmen als Abnehmer der vielfältigen Angebote und Geschäftsmodelle eine etwas andere Sichtweise ein. Ein einfacher Zugang und die intuitive Benutzbarkeit stehen im Vordergrund und fördern die Akzeptanz. Eine durch Fragmentierung verursache Unübersichtlichkeit der Angebote und hohe Kosten infolge geringem Wettbewerb mindern eher die Akzeptanz.

Die Darstellung der Systeme im Markt in Kapitel 5 umfasst sowohl eine funktionale Beschreibung der Grundbausteine als auch eine Zusammenstellung einzelner im Markt etablierter Gesamtlösungen. Dabei werden standardisierte Systeme für TV und das Zusammenwachsen mit dem Internet, web-basierte Technologien, cloud-basierte Lösungen und firmenspezifische Lösungen vorgestellt. Die Analyse heutiger Systeme offenbart, dass die Definitionen aus Kapitel 3 zu erweitern sind.

Zentrale Erkenntnisse der Arbeit der PG Middleware sind:

• Eine Middleware in den besprochenen Anwendungen ist nicht monolithisch als ein definierter Layer lokalisierbar. Sie besteht stattdessen aus verteilten Architekturen. Teile der Middleware können sowohl parallel in mehreren und separaten Software-Stacks innerhalb eines Endgerätes vorhanden sein, aber

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 67

auch verteilt über mehrere ansonsten eigenständige Geräte (Consumer- Endgeräte als auch Server).

• Endgeräte stehen vermehrt in Interaktion mit den Service-Headends.

• APIs stellen den Zugang für Applikationen zu vorhandenen oder extern nutzbaren Funktionen mit verschiedenstem Funktionsumfang bzw. unterschiedlicher Funktionstiefe her.

• Die Grenzen zwischen Funktion und Applikation sind fließend, nicht zuletzt durch die Möglichkeiten des Downloads von Funktionen.

• Applikationen können sowohl vom Nutzer manuell als auch durch Autostart sowohl im Endgerät als auch im Service-Headend aktiviert werden.

• Die Verwendung all der in diesem Dokument genutzten Begriffe ist heute zunehmend eine Grauzone, die mehr von den dahinter liegenden Geschäftsinteressen als von hart abgrenzbaren Kriterien gesteuert ist.

• Es ist zu beobachten, dass in Endgeräte oft mehrere Software-Stacks integriert sind (allerdings werden Endgeräte auch in der Produktion teurer, je mehr Software-Stacks sie integriert haben).

• Internet-Funktionen liefern eine weitgehende Vernetzbarkeit unter Einbeziehung von Servern.

Damit Anbieter von Inhalten und Diensten in die Lage versetzt werden, diese auf verschiedenen Endgeräten bereitstellen zu können, ist ein Zugang zu den APIs notwendig. Die Abstufung reicht von komplett abgeschlossenen Systemen bis hin zu offen standardisierten Systemen. Je offener der Zugang ist, desto leichter ist es möglich allen Nutzern in gleicher Weise den Zugang zu allen Inhalten und Diensten zu ermöglichen.

Die Vielfalt der in diesem Bericht aufgezeigten Systeme führt jedoch dazu, dass eine durchgängige Anwendung einer einzigen universellen API über alle Geräte und Anwendungen hinweg wenig realistisch erscheint. Die Internet-Funktionalität moderner Endgeräte liefert technische Voraussetzungen einer weitgehenden

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 68

Anwendbarkeit und Vernetzbarkeit von Applikationen unter Einbeziehung verschiedenster Infrastrukturen.

Dadurch erscheint es perspektivisch dennoch möglich, dass fast alle Applikationen über viele Netze verteilt und auf allen Endgeräten, teilweise auch in Kombination mit mehreren Endgeräten, zukünftig nutzbar sein werden. Nicht zuletzt wird mit der Nutzung von Second Screen bzw. Companion Screen“ die Welt noch komplexer und vielfältiger, da unterschiedliche Geräte mit weiteren Systemarchitekturen interagieren und dennoch gemeinsam für Anwendungen genutzt werden können. Regulatorische Eingriffe wären daher kontraproduktiv und würden die Innovation der Technik einschränken.

Die zunehmende Verwendung von Internet-Standards (W3C und IETF), wenn auch in unterschiedlicher Kombination bei den jeweiligen Gesamtlösungen, eröffnet grundsätzlich Perspektiven für eine Harmonisierung der Märkte und eine Zunahme der Akzeptanz durch die Nutzer, wenn es die Marktteilnehmer denn wollen.

8. Mitglieder der Projektgruppe

Dieser Bericht wurde von den folgenden Mitgliedern der Projektgruppe im Konsens erstellt (in alphabetischer Reihenfolge):

Agentur für Medientechnik Ulrich Freyer Alcatel Lucent Deutschland AG Klaus Ruf, Wolfgang Schmid ANGA Carsten Engelke ASTRA Plattform Services Konstantin Schaefer Arcor AG & Co KG Andreas Berger BITKOM Bernd Klusmann, Michael Schidlack BNetzA Martin Feller, Karsten Höllerer Deutsche Telekom AG Patrik Krisam, Peter Willems Eutelsat (Kabelkiosk) Gerald Plischke Fraunhofer Fokus Stefan Arbanowski IRT Dr. Klaus Illgner-Fehns ISDM Dr. Helmut Stein Intel GmbH Rebecca Porath

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 69

Kabel Deutschland GmbH Christoph Schaaf Kathrein Werke KG Ralf Exler LOEWE Bernd Weickert Lutec Dr.Georg Lütteke Nacamar Stefan Mundinar, Uwe Schnepf NAGRA Rudi Stelzl NDS / CISCO Petra Schmietendorf NSN Stefan Schneiders Panasonic Martin Fähnrich Sky Deutschland Stefan Heimbecher TechniSat Digital GmbH Markus, Häp TeleColumbus Volker Belz TPVision Volker Blume Unitymedia KabelBW Gruppe Martin Herkommer, Daniel Hesselbarth, Viktor Janik Bernd Tröger Verbraucherzentrale Bundesverband Michael Bobrowski Verbraucherzentrale Rheinland-Pfalz Michael Gundall Vodafone D2 GmbH Markus Nittenwilm VPRT Sebastian Artymiak ZVEI Alexa Christ, Carine Chardon

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 70

A. Allgemeine Anhänge

A.1. Mandat der Projektgruppe

1. Aufgaben

1.1 Abgegrenzt voneinander sollen Vorschläge für funktionale und auf die technische Integration in Empfangsgeräten für digitale Audio- und Videodienste abzielende Definitionen der Begriffe Middleware und Anwendungs-Programmierschnittstelle (API) erarbeitet werden. Dabei sind die Vorgaben des TKG zu berücksichtigen.

1.2 Im Hinblick auf die Regelung in § 48 Abs. 2 Nr. 2 TKG soll eine umfassende inhaltliche Bestandsaufnahme der Marktsituation, insbesondere des aktuellen Sachstands der Aktivitäten zur Standardisierung bzw. Spezifizierung von Middleware und API in Standardisierungsorganisationen bzw. Industriekonsortien vorgenommen werden.

1.3 Die in den Bereichen Middleware und API wirkenden Marktmechanismen sollen beschrieben werden.

1.4 Dazu soll insbesondere eine Übersicht über die jeweiligen Positionen

und Interessen der unterschiedlichen Marktakteure (Rundfunkanbieter, Netzbetreiber, Geräteindustrie, Middleware-Anbieter und Nutzer) erstellt werden.

2. Zeitrahmen

Die Projektgruppe legt sechs Monate nach ihrer Einsetzung einen ersten Bericht vor, dem die Struktur des Abschlussdokuments und die bis dahin erarbeiteten Textentwürfe dazu zu entnehmen sein müssen. Das abschließende Arbeitsergebnis soll dem Lenkungskreis von der Projektgruppe neun Monate nach ihrer Einsetzung vorgelegt werden

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 71

A.2. Glossar

Anwendungs- siehe API Programmierschnittstelle Applikationsschnittstelle siehe API API [application programming Software-Schnittstelle zwischen Anwendungen interface] und den Betriebsfunktionen digitaler Endgeräte BNetzA siehe: Bundesnetzagentur Bundesnetzagentur (BNetzA) Bundesoberbehörde, als nationaler Regulierer für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen. DLNA [Digital Living Network Alliance] Internationales Konsortium zur Entwicklung von Standards, Anforderungen und Empfehlungen für digitale Heimnetzwerke DRM System zur Verwaltung und Steuerung von Nutzungsrechten digitaler Inhalte im Nutzerbereich. DSL [digital subscriber line] Zusammenfassender Begriff für die digitalen Übertragungstechniken in Zweidraht- Telekommunikations-Zugangs-netzen. Typische Varianten sind ADSL2+ und VDSL. DVB- [Digital Video Broadcasting]- Internationales Konsortium mit aktuell ca. 270 Projekt Mitgliedern, bestehend aus Rundfunkveranstaltern, Hard- und Software-Herstellern, Netzbetreibern, Forschungseinrichtungen und Regulierungsbehörden. Das DVB-Projekt verfolgt die Zielsetzung, technische Spezifikationen für den digitalen Rundfunk und Dienste zu erarbeiten und der Standardisierung zuzuführen. DVB-S, DVB-C, DVB-T Erste Generation von digitalen DVB- Übertragungssystemen für digitalen Rundfunk über Satellit, Kabel und Terrestrik. Endkunde siehe: Nutzer ETSI [European Telecommunications Durch die EU anerkannte Standards Institute] Standardisierungsorganisation, die sich zum Ziel gesetzt hat, global anwendbare Standards für die “Information and Communications Technologies“ (ICT) zu erarbeiten. Dies schließt “fixed, mobile, radio, converged, broadcast and internet technologies“ mit ein. HbbTV „Hybrid Broadcast Broadband TV“ ist ein internationales Industriekonsortium, das die Entwicklung von technischen Standards für hybride Fernsehempfänger, die Broadcast und OTT-Internet Verbindungen nutzen, zum Ziel hat. Hybrides Endgerät Endgerät, das klassischen digitalen Rundfunk (DVB-S, DVB -C, -T) sowie WEB-Inhalte empfangen, wiedergeben und ggf. speichern kann.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 72

iDTV [integrated digital television] Digitales Fernsehgerät (TV-Gerät), bei dem Empfangsteil und Wiedergabeteil (für Video und Audio) in einem Gehäuse integriert sind. Intermodaler Wettbewerb Wettbewerb zwischen mehreren Übertragungsnetzen, die ggf. auch verschiedene Übertragungstechniken verwenden. Interoperabilität [interoperability] Möglichkeit für einen Nutzer, mit seinem Endgerät für den Empfang verschlüsselter und unverschlüsselter Inhalte ohne Austausch des Endgerätes innerhalb einer Übertragungstechnik von einem Anbieter zu einem anderen wechseln zu können. IP [Internet protocol] In Computernetzen weit verbreitetes Netzwerkprotokoll, welches die Grundlage des Internets bildet. Es ist die Implementierung der Vermittlungsschicht des TCP/IP-Modells bzw. der Vermittlungsschicht (network layer) des OSI-Modells. IPTV [Internet protocol television] Systeme zur Verbreitung von Programmen und Diensten über managed networks unter Verwendung von IP-Protokollen. Es handelt sich also nicht um das öffentliche Internet, Damit kann eine Dienstgüte (quality of service - QoS) sichergestellt werden. Die Authentifizierung und Übertragung von Nutzungsrechten erfolgt durch bidirektionale Kommunikation zwischen dem Endgerät (= Client) und der IPTV-Kopfstelle [headend] (= Server). Konsument Siehe: Nutzer Lock-in-Effekt Bindung eines Nutzers an ein Angebot in so hohem Maße, dass der Nutzer selbst kostengünstigere oder bessere Konkurrenzangebote nicht annimmt, da die individuellen Kosten für den Wechsel zu hoch sind Matching Verfahren der Abfrage des CA-Moduls für CI (CICAM) beim Boot-Vorgang des Endgerätes nach einem spezifischen Bitmuster (als Matching-Bitmuster bezeichnet). Liegt dieses vor, dann sind entsprechende Kopierschutzfunktionen gegeben. MPEG [Motion Picture Experts Group] Internationales Industriekonsortium, das sich zum Ziel gesetzt hat, technische Systeme für die Datenreduktion (Datenkompression) digitaler Video- und Audiosignale und entsprechende Datencontainerformaten für den Transport der komprimierten Daten zu entwickeln. Die wesentlichsten bisherigen Ergebnisse sind die Standards für MPEG-1, MPEG-2 und MPEG-4 und das Transportstrom-Containerformat. Netzzugang Möglichkeit für einen Inhalteanbieter, seine Programme/Dienste über das jeweilige Netz bis zum Nutzer zu transportieren bzw. transportieren zu lassen. Nutzer [user] Personen oder Personengruppen, die Programme/ Dienste empfangen, wiedergeben, ggf. speichern

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 73

und vorhandene Interaktivität nutzen. Vergleichbare Bezeichnungen sind Verbraucher, Konsument, Endkunde und Teilnehmer. Offener Standard [open standard] Verbindliches technisches Regelwerk, das von einem nationalen oder internationalen Standardisierungsgremium erstellt wird oder von Konsortien (wie Verbänden, Foren, ..), bei denen die Mitarbeit für alle Interessierten offen ist. OIPF [Open IPTV Forum] Internationales Industriekonsortium zur Entwicklung von interoperablen, offenen Lösungen für IPTV OMA [Open Mobile Alliance] Marktgetriebenes internationales Industriekonsortium zur Entwicklung von interoperablen Lösungen für mobile Dienste. OMA wurde 2002 gegründet und hat heute etwa 200 Mitglieder OSGi Alliance Die OSGi Alliance (früher „Open Services Gateway Initiative“) spezifiziert eine hardwareunabhängige dynamische Softwareplattform, die es erleichtert, Anwendungen und ihre Dienste per Komponentenmodell („Bundle/Service“) zu modularisieren und zu verwalten („Service Registry“). Die OSGi-Plattform setzt eine Java Virtual Machine (JVM) voraus und bietet darauf aufbauend das OSGi-Programmiergerüst. Playout (-Center) Zentrum eines Inhalteanbieters, Netzbetreibers oder Plattformbetreibers für die technische Aufbereitung von Signalen zur Verbreitung über bestimmte Zugangsnetze. QoS [quality of service] Mindestanforderungen an die (permanente) technische Qualität eines Programms/Dienste OTT Abkürzung für „over the top“; bezeichnet die Übertragung von Inhalten über das freie Internet auf best-effort – Basis. Set-Top-Box (STB) Digitales Endgerät mit Empfangsteil und digitaler Signalverarbeitung, aber ohne Wiedergabeteil für Audio und Video. Standardisierung Technologische Empfehlungen der jeweils für eine Übertragungstechnik führenden Industrie- und Standardisierungsorganisationen mit Relevanz für den europäischen Markt STB siehe: Set-Top-Box Teilnehmer siehe: Nutzer Transportstrom MPEG-Datencontainerformat, das es erlaubt, datenreduzierte (komprimierte) digitale Video- und Audiosignale sowie Daten zu einem in sich geschlossenen Datenstrom zu multiplexen, der dann unter Anwendung entsprechen-der Modulationsverfahren (u.a. DVB-S, -C, -T) über Zugangsnetze übertragen werden kann. Verbraucher siehe: Nutzer

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 74

VoD [video on demand] Inhalte, die von einem Anbieter auf Abruf und gegen Bezahlung dem Nutzer mittels Streaming oder Download zur Verfügung gestellt werden Web-TV Systeme zur Verbreitung von Programmen und Diensten über das öffentliche Internet unter Verwendung von IP-Protokollen nach dem “best effort“-Prinzip. Zugangsberechtigungssystem siehe: CA-System

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 75

A.3. Abkürzungen A/V Audio/Video

AC3 Adaptive Transform Coder 3

ACAP Automated Content Access Protocol

ADSL Asymmetric Digital Subscriber Line

AES Advanced Encryption Standard

ANGA Verband Deutscher Kabelnetzbetreiber e.V.

Application Programming Interface (Anwendungs- API Programmierschnittstelle) Alliance for Telecommunications Industry Solutions IPTV ATIS IIF Interoperability Forum Ausschuss für technische Regulierung in der ATRT Telekommunikation AVC Audio Video Codec

BCG Broadband Content Guide

BDG Bundesdatenschutzgesetz

BiM Binary MPEG format for XML

Bundesverband Informationswirtschaft, BITKOM Telekommunikation u. Neue Medien BNetzA Bundesnetzagentur

C&R Compliance & Robustness

CA Conditional Access

CAM Conditional Access Module

CAS Conditional Access System

CDN Content Delivery Network

CDP Content Delivery Protocols

CE Consumer Electronics

CEA Consumer Electronics Association

CENELEC Comité Européen de Normalisation Electrotechnique

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 76

CI Common Interface

CICAM Common Interface Conditional Access Module

CI Plus oder CI+ Common Interface Plus CI2, CIv2 Common Interface Version 2

CoD Content on Demand Content Protection & Copy Management; Name des DVB CPCM DRM-Systems CPE Customer Premises Equipment

CR Commercial Requirement

CSA Common Scrambling Algorithm

CSAv3 Common Scrambling Algorithm Version 3

Digital Europe, europäischer Industrieverband der ITK- DE und CE- Hersteller, früher EICTA DES, 3DES Digital Encryption Standard

DHCP Dynamic Host Configuration Protocol

DLNA Digital Living Network Alliance

DRM Digital Rights Management

DSM-CC Digital Storage Media Command and Control

DSL Digital Subscriber Line

DTAG Deutsche Telekom AG

DTCP Digital Transmission Content Protection

DTCP-IP Digital Transmission Content Protection over IP

DTH Direct to Home

DVB Digital Video Broadcasting

DVB-C Digital Video Broadcasting - Cable

DVB-S Digital Video Broadcasting - Satellite

DVB-SI Digital Video Broadcasting - Servcie Information

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 77

DVB-T Digital Video Broadcasting - Terrestric Digital Video Broadcasting - Service Discovery and DVB-STP Selection Transport Protocol

EBU European Broadcast Union

ECM Entitlement Control Message

E.I.C.T.A. siehe DE

EIT DVB Event Information Table

EMM Entitlement Management Message

EPG Electronic Program Guide

ESG Electronic Service Guide

ETSI European Telecommunications Standards Institute

EU European Union

FCC Fast Channel Change

FLO Mobile TV-Technologie von Qualcomm File Delivery over Unidirectional Transport (FLUTE) FLUTE protocol

FTA Free to Air

FUS Firmware Update Service

GEM Globally Executable MHP

GSE Generic Stream Encapsulation

GUI Graphical User Interface

GW Gateway

HBBTV Hybrid Broadcast Broadband TV

HDCP High-bandwidth Digital Copy Protection

HDTV High Definition Television

HDMI High Definition Multimedia Interface

HE-AAC High Efficiency Advanced Audio Coding

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 78

HN Home Network

HNED Home Network End Device

HTML Hypertext Markup Language

http Hypertext Transfer Protocol

ICMP Internet Control Message Protocol

ID Identifier

iDTV Integrated Digital TV

IEEE Institute of Electrical and Electronics Engineers

ITU International Telecommunications Union

iTV Interactive TV

IGMP Internet Group Management Protocol (RFC3376)

IP Internet Protocol

IPDC IP DataCast

IPTV IP TeleVision

ISP Internet Service Provider

JMStV Jugendmedienschutz-Staatsvertrag

JSS Jugendschutzsatzung

KBW Kabel Baden-Württemberg GmbH & Co. KG

KDG Kabel Deutschland Holding AG

KJM Kommission für Jugendmedienschutz

LTE Long Term Evolution

MediaFLO MobileTV-Technologie von Qualcomm

MHP Multimedia Home Platform

MHEG-5 Middleware Standard of the Multimedia and Hypermedia information coding Expert Group

MPAA Motion Picture Association of America

MPEG Moving Picture Experts Group

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 79

MPEG2 TS MPEG-2 Transport Stream

MW Middleware

NAS Network Attached Server

NGN Next-Generation-Network

OCAP Open Cable Application Platform

OMA Open Mobile Alliance OMA- Open Mobile Alliance Broadcast (Mobile Broadcast BCAST Services Enabler Suite)

OS Operating System

OSGi Open Services Gateway Initiative

OSI Open Systems Interconnection

OTT Over The Top

PAT DVB Program Association Table

PC Personal Computer

PES Packetized Elementary Stream

PKI Public Key Infrastruture

PMT DVB Program Map Table

POC Play-out Center

PSI Programme Specific Informations

PSI/SI Programme Specific Information / Service Information

PVR Personal Video Recorder

QoS Quality of Service

RÄStV Rundfunkänderungsstaatsvertrag

RFC Request For Comments

Remote Management Services (auch DVB TM IPI RMS Unterfachgruppe) RS Requirement Specification

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 80

RStV Rundfunkstaatsvertrag

RSVP Resource Reservation Protocol

RTCP Realtime Transport Control Protocol RTCPSS RTCP Extensions for Single-Source Multicast Sessions M with Unicast Feedback RTP Real-time Transport Protocol (RFC3550)

RTSP Real Time Streaming Protocol

SAP Session Announcement Protocol

SCF Service Control Function

SD&S Service Discovery and Selection

SDP Session Description Protocol

SDT DVB Service Description Table

SDTV Standard Definition Television

SG Service Guide

SI Service Information

SIP Session Initiation Protocol

SoC System on Chip

SOHO Small Office/Home Office

SP Service Provider

SPP Service Purchase and Protection

SRM System Renewability Messages

SSL Secure Sockets Layer

STB Set-Top-Box

SVC Scalable Video Codec

TCP Transmission Control Protocol

TelCo Telecommunications Operator

TKG Telekommunikationsgesetz

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 81

TS Transport Stream

TV Television

UDP User Datagram Protocol

UI User Interface

UM Unitymedia GmbH

UMTS Universal Mobile Telecommunications System

UPnP Universal Plug and Play

USI Usage State Information

VDSL Very High Bit Rate Digital Subscriber Line

VC1 Windows Media Video Codec

VCR Video Cassette Recorder

VOD Video On Demand

VoIP Voice over IP

VPN Virtual Private Network

VPRT Verband Privater Rundfunk und Telemedien

WiFi Wireless Fidelity

WiMAX Worldwide Interoperability for Microwave Access

WLAN Wireless Local Area Network

wTVML Worldwide TV Mark-up Language

WWW World Wide Web

XML eXtensible Markup Language

ZVEI Zentralverband der Elektrotechnik- und Elektronikindustrie

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 82

B. Spezifische Anhänge

B.1 Proprietäre Systeme

B.1.1 NDS MediaHighway

Einführung

Schon seit Mitte der neunziger Jahre steht NDS an der Spitze der Entwicklung von Schlüsseltechnologien für Pay-TV, u.a. in den Bereichen Middleware, EPG, interaktives Fernsehen, Video-on-Demand und HDTV. Anfang 2002 revolutionierte NDS das Geschäft mit TV-Middleware durch die Einführung der XTV-Technologie mit integrierter DVR (Digital Video Rekorder)-Funktionalität auf der Set-Top-Box. Heute läuft NDS Middleware auf mehr als 175 Millionen Endgeräten.

MediaHighway™ ist die neueste Generation von NDS Middleware- Produkten; dessen Softwaredesign auf folgenden Grundprinzipien basiert:

• Einfache Portierbarkeit und Abstraktion von der jeweiligen Endgeräte- Hardware.

• Systemoffene Architektur ermöglicht die Integration offener Standards.

• Leistungsstarke Anwendungs-Programmierschnittstellen (API) gestatten Betreibern und externen Designern die Entwicklung kontextbezogener Anwendungen

• Einsatz mehrerer, paralleler Anwendungs-Engines und Multi-Threading

• Die Middleware-Infrastruktur unterstützt Funktionen in den Bereichen Konvergenz und Konnektivität. Das gilt sowohl für Endgeräte in vertikalen STB-Märkten, als auch in wie horizontalen CE-Märkten

• Einsatz in „managed“ und „unmanaged“ Netzen

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 83

Software-Architektur im Überblick

Nachfolgendes Bild stellt den Gesamtaufbau der Software als eine Architektur aus verschiedenen Ebenen dar.

User Interface

Applications

Language-dependant Platform API

Application Services

Middleware Services API

Middleware Services

Fusion-OS API

Fusion-OS

Abbildung 16: MediaHighway-Architektur

Die unterste Ebene, Fusion-OS, übernimmt die Hardware-Abstraktion des jeweiligen Endgeräts wie einer STB, also die Isolierung von den jeweiligen Hardware-Komponenten. Dies ermöglicht die Portierbarkeit der MediaHighway- Middleware auf unterschiedliche Host-Plattformen. Die nächste Ebene, Middleware Services, übernimmt alle Kernaufgaben für die TV-zentrischen Dienste, wie das SI-, Media-, Systemressourcen-, PVR-, Diagnose- und CAS-Management. Zudem liegt hier der Grafik-Stack. Auch die Protocol-Stacks liegen in dieser Ebene. Sie werden von der Middleware und höheren Software-Ebenen benötigt, um so in verschiedenen Umgebungen arbeiten zu können, also etwa in einer Rundfunkumgebung (z.B. mit DSMCC- Object Carousel Protocol) und parallel in internet- basierten Infrastrukturen (z.B. über WAN oder LAN). Dies beinhaltet die verschiedenen IP-basierten Protokolle für die Anwendungsebene, wie etwa UPnP oder Management Level Protokolle (wie beispielsweise TR069).

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 84

Es folgt die Ebene Application Services. Sie umfasst verschiedene Application-Engines sowie Komponenten für eine einfachere Entwicklung von Applikationen.

Die Application-Layer kann sowohl heruntergeladene als auch residente Applikationen beinhalten. Das sprachabhängige Plattform-API abstrahiert die Dienstfunktionen der darunterliegenden Ebenen Application Services und Middleware Services.

Portierbarkeit

Wie vorstehend erwähnt, ist das API der Softwareebene Fusion-OS ein zentraler Teil des gesamten Middleware-Stacks. Die Schnittstelle bietet eine Reihe von flexiblen und erweiterbaren API-Spezifikationen. So können die Leistungsmerkmale der jeweiligen Geräte-Hardware in eindeutiger und präziser Weise offengelegt und abstrahiert werden. Das wiederum erlaubt es der Middleware, zielführend auf die Hardware-Ressourcen zuzugreifen und einen bestimmten Middleware-Dienst auszuführen.

Diese Ebene der Hardware-Abstraktion gestattet also eine verbesserte Vorgehensweise zur Integration verschiedener Endgeräte-Hardware wie unterschiedlichste STBs. Gleichzeitig wird der Prozess der Treiberentwicklung einfacher, effizienter und standardisierter. Das API basiert auf offenen Standards (wie POSIX). Somit sorgt das Fusion-OS- API in Kombination mit dem modularen Software-Design für eine deutlich reduzierte Time-to-Market, um neue STBs in den Markt einzuführen. In den API-Entwicklungsprozess fließt sowohl die Expertise der Chip-Hersteller, wie die des Middleware-Anbieters ein. So gestattet das Fusion-OS- API eine vereinheitlichte Middleware-Implementierung über unterschiedliche Hardware-Plattformen hinweg bei gleichzeitig verbesserter Leistung.

Hauptmerkmale

MediaHighway unterstützt alle Übertragungswege: Kabel, Satellit, Terrestrik, IPTV, OTT und beliebige Kombinationen davon. Im OTT-Modus unterstützt MediaHighway PDL (Progressive Download) und ABR (Adaptive Bit Rate) für das Streaming über das offene Internet.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 85

Neben den traditionellen TV-, DVR- und VOD-Funktionen unterstützt MediaHighway zusätzlich auch folgende Merkmale:

• Restart und Catch-up- TV (bei konventionellen TV-Betreibern über OTT- Ausspielung mit HTTP-Adaptive Bitrate Streaming)

• Heim-Netzwerkfähigkeit durch die Unterstützung von UPnP- und DLNA- Protokoll-Stacks. Das ermöglicht den mit MediaHighway ausgestatteten Endgeräten die Kommunikation mit anderen kompatiblen Geräten

• 3D-Animations-Funktion

• Kontextbezogene Widgets

• Externe DVR-Speicherung

• Einbindung von Mess-Systemen für neuartige Empfehlungs- und Promotion-Angebote

• Fernüberwachung

• Globale Suche

MediaHighway bildet auch die Basis, um eine Kommunikation zwischen der STB und anderen Endgeräten eines Nutzers, wie beispielsweise Smartphone oder Tablet, zu ermöglichen.

Application Engines und APIs

MediaHighway unterstützt verschiedene Arten von Application Engines. Es ist dabei auch möglich, mehrere Application-Engines zu kombinieren, um so verschiedene Arten von Applikationen zeitgleich auszuführen. Zum Beispiel können Applikationen in Flash und HTML 5 parallel unterstützt werden. Ebenso ist es nicht erforderlich, die EPG-Hauptfunktion zu beenden, etwa um eine interaktive Anwendung zu starten – beides kann parallel laufen. Der Application Engine Manager – eine der Middleware-Komponenten – verwaltet sowohl die Application Engines als auch den Lebenszyklus der einzelnen Applikationen. Dies gibt Applikations-Entwicklern die nötige Flexibilität, um attraktive Applikationen zu gestalten und den Lebenszyklus jeder einzelnen Applikation mittels des EPG zu steuern.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 86

MediaHighway bietet eine Vielzahl von APIs. So können Betreiber und externe Entwickler spezifische Applikationen gestalten, die zuverlässig auf der Middleware laufen. Die APIs lassen sich verschiedenen Funktionsgruppen zuordnen. Dazu gehören:

• Auslesen von SI-Daten, Kanal-Info, Genre, Zusammenfassung, Eigenschaften, Infos zur DVR-Aufnahme.

• Ausführen von Befehlen aus Widgets (Kanalwahl, Zappen, Erinnerung aktivieren, etc.).

• Inhalte über Widget für DVR-Aufnahme vormerken.

• Video-Inhalte aus zugelassenen Content-Quellen abspielen (basierend auf den spezifischen und von der jeweiligen Set-Top-Box unterstützten Video-Codecs).

Das API für HTML 5-Anwendungen ist ein JavaScript-API; die Flash- Anwendungen greifen auf die Dienste über das ActionScript-API zu.

Anwendungen können entweder lokal im Gerät installiert sein oder durch den Broadcast-Stream oder über eine IP-Verbindung heruntergeladen werden – und das entweder in Form von Widgets oder als klassische Anwendungen.

Anmerkung: Seit 1.August .2012 gehört NDS zu Cisco und bringt damit sein Lösungsportfolio und die Unternehmensexpertise bei Cisco ein. Zur CES 2013 in Las Vegas wurde erstmals das weiterentwickelte Angebot Cisco Videoscape Unity vorgestellt. Dieses nutzt die Technologien von NDS, um die bestehende Architektur von Videoscape zu bereichern und zur neuen, integrierten Plattform Videoscape Unity zu verbinden. Das gilt vor allem hinsichtlich der Client-Software, wozu das Multiplattform-Middleware- Angebot MediaHighway zählt. Die weiteren Technologien und Lösungen aus dem NDS-Portfolio adressieren u.a. die Themen Sicherheit, Werbung und Bedienoberflächen.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 87

B.1.2 Nagra OpenTV

NAGRA OpenTV ist einer der führenden Anbieter für TV-Middleware- Lösungen der letzten 15 Jahren mit weltweit über 170 Millionen ausgestatteten Endgeräten. Eines der Hauptziele dieser Plattform ist Unabhängigkeit von der STB-Hardware. Damit können TV-Anbieter preiswerte Set-Top-Boxen (STB) aussuchen, dabei die Investion in die STB-Software schützen und eine stabile Plattform für Applikationsentwickler anbieten.

Die neueste Version der NAGRA OpenTV-Middleware umfasst ein offenes Eco-System – zum einen gegenüber dem Endgerät, zum anderen gegenüber dem Backend und Backend-Diensten. NAGRA nutzt hierbei soweit wie möglich offene Standards und garantiert die Interoperabilität mit verschiedensten Eco-Systemen und Endgeräten. Die OpenTV-Middleware ist schnell auf neue Hardware zu portieren, zu integrieren und schließlich auszurollen.

OpenTV- Middleware abstrahiert die Hardware der Endgeräte von der Applikation, die auch die Darstellung der Bedienoberfläche übernimmt. Diese Abstraktion garantiert, dass auf vielen unterschiedlichen Endgeräten (TV- Empfängern, STB) die gleichen Funktionen realisiert und angeboten werden können. Das unterstützt den TV-Betreiber in seiner Strategie Unabhängigkeit vom STB-Hersteller zu erlangen und letztendlich den STB- Preis durch Wettbewerb zu verringern.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 88

Abbildung 17: OpenTV- Middleware- Architektur

OpenTV- Middleware basiert auf einer offenen Architektur, welche die Vorteile von Linux als Betriebssystem, bewährten Open-Source - Komponenten und den neuesten Entwicklungen im Chipbereich zu Nutze macht. In der heutigen OpenTV- Software sind jahrelange Erfahrungen und Expertenwissen aus dem Bereich des digitalen Fernsehens sowie aktuelle Neuerungen aus dem Breiband- und Internetbereich gebündelt. Basierend auf offenen Standards berücksichtigt das OpenTV-Middleware-System heute insbesondere folgende Aspekte:

1. Die Nutzung von HTML und SVG als generelle Entwicklungsumgebung für die Bedienoberfläche und Applikation garantiert, dass existierende Bedienoberflächen und Applikationen wieder verwendet werden können.

2. Durch eine „Sandbox“- Architektur wird eine Umgebung geschaffen, in der die Bedienoberfläche / Applikation die Gesamtstabilität des Endgerätes nicht gefährden kann.

3. Mit dem Wissen, dass

a. permanent weitere Standards für Applikationsentwicklung aufkommen,

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 89

b. weltweit regionale Unterschiede in der Implementierung von Applikationen bestehen und

c. weitere alternative Applikationsumgebungen (App Store, TV Application Stores) entstehen,

wurde die Möglichkeit geschaffen, über HTML hinaus, auch andere Entwicklungsumgebungen zu nutzen.

Anwendungstypen

Die OpenTV-Middleware unterstützt vielfältige Applikationstypen. Dazu gehören:

• Integrierte Applikationen (Embedded Applications) Diese sind auf dem Endgerät lokal gespeichert (typischerweise in Flash-Speichern) und immer verfügbar

• TV-basierte Applikationen (Broadcast Applications) Diese werden mit den TV- und Radio-Inhalten übertragen bzw. signalisiert (DVB).

• IP-basierte Applikationen (Broadband Applications) Diese werden über die Breitbandverbindung zur Verfügung gestellt, zum Beispiel durch http.

• Widgets Diese werden auf das Endgerät runtergeladen und gespeichert, um eine schnelle Ausführung zu garantieren.

Anwendungsumgebungen

Um die vorstehend genannten Anwendungstypen zu unterstützen, bietet die OpenTV-Middleware folgende Anwendungsumgebungen:

• HTML5-Browser

• SVG-Browser (SVG + JavaScript)

• Weitere Browser und Engines (Programme zum Verarbeiten und zur Darstellung von Applikationssprachen) von Dritten (z.B. HbbTV).

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 90

Je nach Applikationsumgebung werden die Ressourcen des Endgeräts unterschiedlich stark beansprucht (Prozessor und Speicher).

HTML5 ist inzwischen die wichtigste Applikationsumgebung für Multimedia-Applikationen geworden. HTML5-Anwendungen lassen sich mit minimalem Entwicklungsaufwand auf unterschiedliche Endgeräte portieren.

Die skalierbare Vektorgrafik [scalable vector graphics (SVG)] bietet die Möglichkeit, ansprechende und schnelle Applikationen auf Endgeräten mit eingeschränkten Ressourcen zu erstellen. SVG ist ein W3C-Standard und funktional in HTML5 enthalten.

Die verschiedenen Applikationsumgebungen laufen als vom Hauptprogramm getrennte Applikationen, so dass die Sicherheit und Stabilität immer sichergestellt sind.

Schnittstellen

Die OpenTV-Middleware bietet folgende Schnittstellenebenen:

• CCOM-API oder SDK (Software Development Kit = Software- Entwicklungswerkzeug zur Nutzung einer bestimmten Programmierumgebung) Diese Schnittstelle wird von der Applikationsebene genutzt, um auf die Middleware- Funktionalität zuzugreifen. Typischerweise wird dazu JavaScript gebraucht, wobei andere Sprachen möglich sind.

• Application Environment-API (AE API) Über diese Schnittstelle greifen die Applikationsumgebungen (Browser und Engines) auf die Middleware zu. Sie ist in der Programmiersprache C implementiert.

• Portierungsschnittstelle Diese Schnittstelle befindet sich zwischen Middleware und STB. Die Middleware greift hier über die Treiber der STB Hardware zu.

Die OpenTV-Middleware verzichtet auf die Nutzung von proprietären Schnittstellen und greift stattdessen über Standardschnittstellen auf Linux

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 91

und andere Elemente auf der Treiberebene des Endgerätes zu (z.B. Direct FB).

CCOM steht für Client Component Object Model (Objekt-Modell für Applikationskomponenten). CCOM und das dazugehörige SDK sind für jeden zugänglich und ermöglichen Applikationsentwicklern den Umgang mit OpenTV leicht und schnell zu erlernen, damit zu experimentieren und schließlich Applikationen zu entwickeln.

Middleware Komponenten

Die Kernkomponenten für TV bilden die Grundfunktionalität der OpenTV - Middleware, die von den Applikationsumgebungen für die Darstellung der Bedienoberfläche genutzt wird. Beispiele für solche Kernkomponenten sind die PVR-Komponenten (Personal Video Recorder) und Home Networking- Komponenten (Heimnetzwerk). Die Kernkomponenten und die Applikationsumgebungen sind über eine D-Bus-Struktur (Desktop Bus, Software-System für Interprozesskommunikation, Bestandteil jeder modernen Linux-Distribution) verbunden. Durch die Nutzung von D-Bus können leicht und schnell weitere Komponenten von Dritten in die Middleware integriert werden.

B.1.3 Microsoft MediaRoom

Microsoft MediaRoom ist eine Ende-zu-Ende IPTV-Systemlösung für managed und unmanaged Netze. Microsoft stellt im Rahmen ihres Produktes sämtliche erforderlichen Backend-Komponenten, sowie Client- Software für die unterschiedlichsten Endgeräte zur Verfügung. Analog zu anderen IPTV- Lösungen bildet MediaRoom die Kernfunktionen linearer Rundfunk, Navigator (EPG), nicht-lineare Telemediendienste und interaktive Applikationen ab. Die Bedienoberfäche und ihre Funktionen sind ansprechend und intuitiv zu bedienen. MediaRoom erweitert die netzseitige Dienstgüte durch eigene QoS- Verfahren, wie Instant Channel Change und UDP Package Retry. In Abhängigkeit von der zur Verfügung stehenden

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 92

Bandbreite des Anschlusses können mehrere Programme gleichzeitig konsumiert bzw. aufgezeichnet werden. Die Verwendung mehrerer Endgeräte in einem Haushalt / LAN ist möglich. Auch Media Sharing auf unterschiedlichen Set-Top-Boxen ist ein bedeutendes Merkmal, der auf Basis von MediaRoom realisierten Dienste im Markt.

Die Spielekonsole Microsoft Xbox 360 lässt sich nach Provisionierung mit einem MediaRoom Client ebenfalls als IPTV-Endgerät verwenden, Microsoft bietet außerdem Clients für Tablets, Smartphones und PCs auch andere an, darunter beispielsweise für iOS, WP7 oder Silverlight. Zusätzliche Clients werden außerdem über ein Device Enablement Kit implementiert, um auch auf zusätzlichen Endgeräten MediaRoom Clients zu implementieren. Dadurch werden unter anderem auch hybride STBs und Android-basierte Geräte addressiert, Clients dieser Art werden zum Beispiel vom Microsoft MediaRoom e2e Integrator Alcatel-Lucent zur Verfügung gestellt.

Auf Basis eines Software Development Kits lassen sich Applikationen erstellen, die nahtlos in die Nutzerführung der Client-Software eingebunden werden. Das Ergebnis ist eine Navigation ohne Bruch in der Darstellung oder Bedienung. Das angebotene SDK ist proprietär, kann allerdings über standardisierte Web-Schnittsellen / APIs mit anderen Applikationen zusammenarbeiten. Die Implementierung von dienstegebundenen [bound] und diensteunabhängigen [unbound] Applikationen ist möglich, die Freigabe für Nutzer obliegt jedoch stets dem Diensteanbieter [service provider]. MediaRoom stellt Dritten(z.B. Rundfunkveranstaltern) derzeit keine offene Schnittstelle für die transparente Weiterleitung zur Verfügung. Pläne hinsichtlich einer Öffnung auf Basis des offenen Standards HbbTV sind nicht bekannt.

Microsoft MediaRoom verfügte in der Anfangsphase nach der Markteinführung auch über eine Browser-Lösung. Der Browser beherrschte die einschlägigen Sprachelemente (HTML, CSS,…) und Javascript mit restriktiven Einschränkungen. Eine weitgehende Interoperabilität mit Web-

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 93

oder HbbTV-Applikationen war nicht gegeben. Die Programmierung von Applikation erfolgte auf einem Subset von Standard Techniken wie HTML, CSS oder AJAX.

Mit der Weiterentwicklung von MediaRoom kann diese Plattform nun auch für Multiscreen und OTT-Dienste eingesetzt werden. Dies wird hauptsächlich durch die Unterstützung von Adaptive Streaming für VoD sowie Live-TV verwendet.

B.1.4 Cisco Videoscape

Mit der Produktreihe Videoscape hat Cisco im vergangenen Jahr eine IPTV-Lösung der neuen Generation vorgestellt, die vom Anspruch her weit über bisherige Systeme hinausgeht.

Ein wesentliches Kennzeichen von Videoscape ist die Einbeziehung aller Endgeräte, die heute für die Konsumierung von Video-Inhalten der verschiedensten Ausprägungen relevant sind. Dabei ist die Lösung trotzdem offen genug, um auch zukünftige, neue Endgeräte-Klassen nicht auszuschließen.

Videoscape adressiert also nicht nur die klassische Verteilung von IPTV und On-demand-Inhalten an die Set-Top-Box am Fernsehgerät, sondern bezieht ebenso alle anderen Endgeräte wie PC, Tablet und Smartphones mit ein. Dabei positioniert sich Videoscape als eine Multiprotokoll- und Multi-DRM-Umgebung mit dem Ziel, möglichst umfassend alle Endgeräteklassen und -Fabrikate zu bedienen. Dazu zählen dann auch Spielekonsolen und internetfähige Fernsehgeräte (Connected TV). Spezieller Wert wird zunächst auf die Einbindung von iOS- und Android- Produkten gelegt. Die mobilen Endgeräte werden in der “Homezone” der Nutzer via WLAN unterstützt. Parallel dazu beinhaltet Videoscape ebenso eine speziell ausgelegte Video-Distribution über 3G-Mobilfunknetze.

Wesentliches Merkmal ist also die gleichförmige Einbindung von “managed” Endgeräten, wie Set-Top-Boxen, die in der Verantwortung der

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 94

Diensteanbieter [service provider] liegen, als auch von “unmanged” Endgeräten, die vom Nutzer selbst betrieben werden (z.B. Smartphones).

Ebenso wie die umfassende Einbeziehung aller Endgeräte-Klassen für videorelevante Darstellung ist ein weiteres Kennzeichen von Videoscape die Einbeziehung aller Arten von Video-Inhalten, seien es die klassischen TV- Broadcasts, On-demand-Inhalte (wie Mediatheken), aber auch Internet- Video- Inhalte externer Anbieter, die nicht klassischerweise einen Zugang zu allen Endgeräte-Klassen haben. Hierunter fallen beispielsweise die OTT[over the top]- Anbieter, die mit ihren Videoangeboten normalerweise nicht auf den TV-Geräten präsent sind. Videoscape eröffnet dem Diensteanbieter hier ein zweiseitiges Geschäftsmodell, das gezielte Absprachen mit diesen OTT`s erlaubt. Deren Inhalte können dann redaktionell betreut werden, in die Kataloge des Diensteanbieters integriert werden und mit vereinbarter Dienstgüte an die Nutzer ausgeliefert werden. Dafür gilt der Begriff “Syndicated Media”

Die übergreifenden Designziele, die mit dieser Lösung verfolgt wurden, sind somit neben hoher Skalierung und Verfügbarkeit der Service “Any Content on any Device”.

Ebenso werden zusätzliche Inhalte und Dienste unterstützt, wie Aufzeichnungen (NetworkPVR), Weiter-Sehen –[(catch-up, start-over]. Um diese sowohl auf gemanagten und ungemanagten Endgeräten verfügbar zu machen, sind Cloud-Services unerlässlich. Als Beispiel sei auf die Recordings verwiesen. Obwohl lokale Festplatten zur Aufzeichnung bei Set- Top-Boxen weiterhin unterstützt werden, können die Recordings von mobilen Endgeräten nur an zentraler Stelle erfolgen. Beide Varianten können mit einem Konzept zur Virtualisierung von Speicherkapazität kombiniert werden.

Die Cloud-Unterstützung kann zukünftig noch weiter ausgebaut werden, indem auch für bestimmte Anwendungsfälle (Endgeräte mit geringer Prozessorkapazität) das Rendering der Daten direkt im Data Center vorgenommen wird. Auf den Endgeräten existiert dann lediglich noch eine

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 95

Browser-Instanz, die eine Streaming-Version der Dienste (wie EPG, On- demand-Kataloge oder integrierte Web–Dienste) abbildet, sowie eine Instanz, welche die Steuersignale der Fernbedienung weiterleitet.

Mit Cisco Videoscape Voyager Virtual im Data Center sowie Cisco Videoscape Voyager Vantage wird Cisco den Cloud- und Client-Anteil verfügbar machen (Ankündigung CES 2012). Diese Technologie ist insbesondere für Migrationsszenarien, aber auch als Investitionsschutz für existierende Set-Top Boxen interessant.

Sowohl hierzu, als auch zur Unterstützung der web-basierten Streaming- Formate sowie der Adaptive Bitrate-Formate (Apple HLS, Microsoft Smooth, …) ist eine effiziente Netz- Unterstützung zur Distribution dieser Inhalte erforderlich. Dies geschieht durch inhärente Einbeziehung von CDN (Content Delivery Network)-Komponenten in Videoscape.

Abbildung 18: Cisco Videoscape Portfolio

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 96

Somit sind die drei elementaren Komponenten von Videoscape benannt:

- cloud- basierte Transcoding Ressourcen, Medienverwaltung [ content management system (CMS)] sowie allgemeine Backend Funktionen

- Multiprotokollfähige CDN-Unterstützung auf Netzebene für effiziente Video- Distribution

- Unterstützung aller Client-Endgeräte-Klassenklassen

Zur Steuerung der gesamten Plattform, zur Verwaltung der Nutzer, Endgeräte und Dienste wird in Videoscape das Konzept einer separaten Video Control Plane Instanz “Conductor” verfolgt und kurzfristig verfügbar gemacht. Die Conductor-Komponenten sind in alle Elemente von Videoscape integriert und kommunizieren über API`s mit der Conductor- Backend-Instanz. Insbesondere werden auch alle Videoscape-Clients (managed und unmanaged) auf diese Weise in die Plattform einbezogen.

Aufgrund dieser API`s ergeben sich ebenso vielfältige Integrationsmöglichkeiten mit externen Komponenten und damit auch eine offene und modulare Plattform, um den Standardisierungsgedanken voranzutreiben. Bei der Entwicklung der Control Plane, die auf asynchronem Messaging zwischen den Komponenten basiert, wurde insbesondere auf eine schlanke und damit hoch skalierbare Implementierung abgestellt. Das verwendete Messaging Protokoll ist standard-basiert und allgemein nutzbar.

Aufgrund dieser allgemeinen Nutzbarkeit ergibt sich eine Verwendung des Videoscape-Plattform-Messaging auch außerhalb der eigentlichen Control Plane-Funktionen innerhalb der Datenpfade für die verschiedenen Dienste. Hierdurch werden neue Dienste möglich die dann auch standardisierungsfähig wären), wie beispielsweise Integration von Social Networks, Realtime Web Services, Interaktives Fernsehen, Presence Services und vieles mehr.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 97

B.1.5 Cloud- basierte Lösungen von Alcatel-Lucent

Die nächste Generation an Videolösungen sind cloud-basierte Online- Video-Plattformen. Diese erlauben es den Diensteanbietern flexible Lösungen zu implementieren. Hierbei wird besonderen Wert auf die Multiscreen-Fähigkeit gelegt, d.h. die Inhalte sind auf verschiedensten Endgeräten mit Bildschirm (z.B. TV-Gerät, PC, Tablet, Smartphone, …) darstellbar . Damit werden neue Interaktionen an Videodiensten ermöglicht. Die Alcatel-Lucent Multiscreen-Plattform “The Platform“ bietet die Fähigkeit, zentral die unterschiedlichsten Videostreams zu erzeugen und zeitgesteuert oder als Video-on-Demand auf verschiedensten Endgeräten zur Verfügung zu stellen.

Abbildung 19: Modulare cloud-basierte Online-Video-Plattform von Alcatel-Lucent

Eine Multiscreen-Plattform sollte den Prinzipien moderner Software- Entwicklung entsprechen, d.h. eine diensteorientierte Architektur [Service Oriented Architecture (SOA)] aufweisen, bei der jeder Dienst bzw. jede Funktion einer Middleware in der Art entwickelt ist, dass seine Funktion flexibel erweitert werden kann.

Basierend auf dieser modularen Architektur kann die Gesamtlösung flexibel zusammengestellt werden und ermöglicht dem Diensteanbieter somit

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 98

leichte Anpassbarkeit an die heutigen Anforderungen und existierende Systeme, sowie höchste Flexibilität für die Zukunft.

Beispiele solcher modularer Funktionen sind:

• Commerce,

• Content Management ThePlatform),

• Subscriber Management,

• Offer Management,

• Headend Funktionen,

• Content Syndication,

• Content Delivery Network (Velocix),

• Nutzerapplikationen.

Abbildung 20: Funktionalitäten, die mit Multiscreen-Video ermöglicht werden

Dies ermöglicht unter anderem auch die flexible Skalierung einzelner Komponenten. Ein Resultat dieser Modularität ist, dass eine solche Lösung als alleinstehende Plattform, aber auch als sogenannte Overlay-Plattform eingesetzt werden kann. Es erfolgt die Abkehr von Limitierungen traditioneller Middleware-Systeme, die oft begrenzte Funktionalitäten bieten und als eine monolithische Plattform existieren, hin zu einer modularen und

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 99

flexiblen Plattform, mit der sich kostenoptimiert neue Dienste für die Nutzer schnell einführen lassen. Dies ermöglicht den Diensteanbietern, schnell auf neue Marktanforderungen reagieren zu können.

Zu diesen neuen Bausteinen kommen durch neue Geschäftsmodelle auch zusätzliche Anforderungen, wie beispielsweise Content Syndication. Dabei handelt es sich um die Möglichkeit des Zugriffs auf Inhalte anderer Plattformen und Quellen (z.B. Content-Partnern), aber auch das Ausspielen zu anderen Plattformen. Eng verbunden mit dieser Content-Syndication ist die Rechte-Syndication (Zeitfenster, Zugriffskontrolle von Videoinhalten), aber auch das Vorgeben sowie bewusste Freigeben von Werbenetzwerken.

Abbildung 21: Beispiele für Content Syndication

Die Multiscreen-Video-Plattform vereinigt die Stärken der Alcatel-Lucent in Multimedia-Technologie und Applikationen und Dienste mit ‚ThePlatform‘, dem führenden Hersteller von Videomanagement-Lösungen. Mit dieser Lösung können Diensteanbieter die nächste Generation an Videodiensten einläuten, in der jeglicher Inhalt auf jeglichem Endgerät dargestellt werden kann.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 100

B.1.6 Google TV auf Android-Basis

Die von dem amerikanischen Unternehmen Google und seinen Partnern Intel, Sony und Logitech vorgestellte Plattform „Google-TV1“ basiert auf dem Betriebssystem Android in der Version 3.0 oder höher. Momentan steht der Dienst in Europa noch nicht zur Verfügung. Durch die bereits vollzogene Markteinführung in den USA sind allerdings verschiedene technische Eigenschaften bereits bekannt. Es ist davon auszugehen, dass für Google-TV Mindestanforderungen an die Hardware gestellt werden, die der Hardware-Vielfalt, wie es sie bei Smartphones gibt, Grenzen setzt Allerdings variieren diese abhängig von der jeweiligen Umsetzung in einem Produkt, da sich aufgrund der Flexibilität dieser Plattform die unterschiedlichsten Endgeräte mit Google TV verbinden lassen. Bisherige Google TV-Geräte basieren alle auf dem Intel-Prozessor Typ Atom CE 4100 SoC, der bis zu zwei HD-Streams verarbeiten kann und andere Verbesserungen in Bezug auf die Leistungsfähigkeit der Grafik bietet2. Ob und wann Google TV auch für andere Prozessoren verfügbar ist, liegt im Ermessen von Google.

Ein Google TV-Gerät kann z.B. auch ein Blue-ray Player sein und muss keinen Tuner für Broadcast-Signale aufweisen. Ist jedoch ein Tuner integriert, dann können native Android-Apps auf die Informationen von Live- TV-Signalen zugreifen und auch zwischen ihnen umschalten. Auf einem Google TV-Gerät können nur Android- oder Web-Apps laufen. Für den Zugriff von Web-Apps auf Google TV-Geräte gibt es auch eine JQuery Libary.

Das für Google-TV genutzte Eingabegerät muss im Gegensatz zu z.B. einer normalen Fernbedienung folgende Eingabemöglichkeiten zur Verfügung stellen:

1 http://www.google.com/tv/index.html

2 http://www.google.com/tv/index.html

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 101

• Für Video-Abspielgeräte übliche Tasten wie Play, Pause usw.

• Steuerkreuz

• Alphanumerische Tastatur

• Maus oder vergleichbares Eingabegerät

Als Middleware kommt entweder der integrierte Browser (z.B. Chrome) mit Unterstützung von Web-Technologien oder das Betriebssystem zum Ausführen von nativen Android-Apps in Frage. Hier ähnelt sich die Plattform stark den Bemühungen anderer Hersteller auf Basis von Linux und Web- Standards, ihre Middleware umzusetzen. Auch das Android-Betriebssystem hat so z.B. einen Linux-Kern und das dazugehörige SDK steht Entwicklern kostenfrei zur Verfügung. Eigentlich handelt es sich bei Google TV um den Versuch, durch die Entwicklung einer umfangreichen weit vorangeschrittenen Plattform mit vielen Funktionalitäten einen Quasi- Standard zu etablieren.

Somit lassen sich auf einem Google-TV-Gerät im Prinzip alle Dienste und Applikationen, die auf einem Browser in einem iDTV zur Verfügung gestellt werden können, auch auf einem Google TV- Geräten nutzen. Zusätzlich können viele bereits bestehende Android-Applikationen, die bereits für andere Android-fähige Endgeräte (wie Smartphones oder Tablets erstellt wurden, auch für GoogleTV-Geräte angepasst und dann genutzt werden. Lediglich Anpassungen der Nutzerschnittstelle müssen vorgenommen werden.

Anwendungen lassen sich somit auf Basis folgender Technologien realisieren:

1. Standard-Web-Technologien wie HTML, CSS, Javascript (sog. Web- App)

2. Android -SDK (auf Java basierend) (sog. Android-App)

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 102

B.1.7 Apple TV auf iOS-Basis

Die Firma Apple bietet mittlerweile in der zweiten. Generation das Produkt „Apple TV“ an. Diese basiert technisch auf dem iPhone/iPod und hat iOS als Betriebssystem. Ein Apple-TV-Gerät soll andere Home Entertainment- Geräte, wie Receiver oder DVD-Player nicht ersetzen. Der Funktionsumfang von Apple TV ist jedoch wegen seines Konzepts als Stand-Alone-Gerät eingeschränkt. Auf einem Apple TV-Gerät läuft lediglich das Programm „Apple TV Software“, welches typische Apple- Dienste, wie iTunes und iCloud sowie einige andere ausgewählte Mediendienste wie YouTube zur Verfügung stellt. Zusammengefasst lässt sich ein Apple TV- Gerät also als iPod mit einem Fernseher als Bildschirm bezeichnen. Aufgrund der nicht vorhandenen Möglichkeit, Apps zu installieren oder über einen Browser auf Web-Apps zuzugreifen, behält Apple die volle Kontrolle über den verfügbaren Inhalt. Über iTunes bzw. iCloud kann jedoch auf eigenen lokal oder in der Cloud gespeicherten Inhalt zugegriffen werden, welcher auf das Apple TV-Gerät gestreamt werden muss.

B. 2 Smart Meter- Applikationen

Die intelligente Verknüpfung individueller Strom- und Wasserverbrauchsprofile der Nutzer mit der Koordination traditioneller und alternativer Stromerzeugungsverfahren führen zu einer Verdichtung von Daten, die aggregiert, analysiert und wieder für den Nutzer aufbereitet werden müssen. Unabhängig davon, welche Strategien die beschlossene Energiewende mit sich bringen wird, ist allerdings erkennbar, dass in diesem Zusammenhang auch auf Netzbetreiber (Kabelnetzbetreiber und TelCos) Herausforderungen zukommen werden, dies über ihre Infrastrukturen zu unterstützen. Was Applikationen (Apps) bereits auf den Smartphones bewirkt haben, steckt beim interaktiven Fernsehen noch in den Kinderschuhen. Erst relativ wenige Applikationen sind heute im HbbTV-Format über das Fernsehen verfügbar. In der Regel unterstützen STBs und IDTVs nur einen kleinen Anteil. Die Integration der

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 103

Dienste – wie zum Beispiel Strom-Portale – auf alle Endgeräte ist wegen des Fehlens klarer Vorgaben entsprechender Integrationsschritte und Standards sehr komplex.

Die Entwicklung wird bei der Darstellung von Verbrauchsdaten nicht stehenbleiben. In-Haus-Vernetzung über WLAN ermöglicht nicht nur die Anbindung von STBn, IDTVs und PVRs, sondern sind auch Grundlage für zukünftige „Machine-to-Machine“ (M2M)- Kommunikation. Daraus folgt, dass weitere Interessensgruppen in die Geschäftsmodelle zu integrieren sind, die bisher weder als Stromerzeuger, noch als Plattformbetreiber entscheidenden Einfluss besaßen. Je nachdem, wer die Lasten der Einführung intelligenter Verbrauchsmanagement-Systeme tragen wird, will sicherstellen, dass diese Rechte nicht durch den Einfluss Dritter beschnitten werden.

Interoperabilität ist die Grundlage dafür, dass sich neue Geschäftsmodelle im Markt durchsetzten können, ohne alte Monopolstrukturen zu verschärfen oder neue aufzubauen. Das ist nicht so sehr eine politische Aufgabe, sondern vielmehr eine technische und betriebswirtschaftliche Herausforderung, deren Lösung möglichst effiziente Konstellationen und Geschäftsmodelle hervorbringen soll. Da die gesamte Wertschöpfungskette nicht durch einen Marktteilnehmer allein finanziert werden kann, muss es zu einer breit angelegten Arbeitsteilung kommen. API-Standards für interaktive Anwendungen sind das beste Mittel, die bereits etablierten Systemumgebungen zu nutzen. Dies gilt unabhängig davon, ob proprietäre oder standardisierte Middleware- Strukturen verwendet werden.

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013 ATRT Projektgruppe Middleware Abschlussbericht Seite 104

Abbildung 22: Smart Metering

Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA) Oktober 2013