DE69933811T2

DE69933811T2 - Digitaler Multimediaempfänger und einen solchen Empfänger umfassendes Netzwerk mit IEEE 1394 serial Bus Schnittstelle

Info

Publication number: DE69933811T2
Application number: DE69933811T
Authority: DE
Inventors: Adrian Charles Basingstoke Paskins
Original assignee: Sony United Kingdom Ltd
Current assignee: Sony Europe Ltd
Priority date: 1998-04-24
Filing date: 1999-04-15
Publication date: 2007-08-30
Anticipated expiration: 2019-04-16
Also published as: JP4339439B2; EP0952733A2; EP0952733B1; KR19990083394A; EP0952733A3; US6591419B2; US20020196374A1; MY125023A; DE69933811D1; JP2000032016A

Description

Die Erfindung betrifft ein digitales Multimediagerät, z.B. ein digitales Videogerät, sowie eine Anordnung und ein Verfahren, die es dem Gerät ermöglichen, mit einem anderen Gerät auf einem gemeinsamen Bus zu kommunizieren.
Es ist auf dem Gebiet der digitalen Videoverarbeitung bekannt, digitale Videosignale so zu kodieren, daß in dem Empfänger eine spezielle Verarbeitung benötigt wird, um die Videosignale reproduzieren zu können. Es wurde insbesondere vorgeschlagen, ein Modul für bedingten Zugriff [Conditional Access Module] vorzusehen, das die ganze Entwürfelung und andere Funktionen für den bedingten Zugriff eines digitalen Fernsehempfängers ausführen kann. Dies ermöglicht es, den bedingten Zugriff und die Signaldekodierfunktionen von einem Host-Empfänger zu trennen, so daß ein generischer digitaler Fernsehempfänger mit vielen verschiedenen Systemen mit bedingtem Zugriff in verschiedenen Conditional Access Modulen zusammenarbeiten kann.
Um eine Kommunikation zwischen einem Conditional Access Modul und einem digitalen Fernsehempfänger zu ermöglichen, wurde von CENELEC (EN50221 Common Interface Specification for conditional Access and other Digital Video Broadcasting Decoder Applications) eine allgemeine Schnittstelle [Common Interface] vorgeschlagen und standardisiert. Dieser Common-Interface-Standard definiert ein Transportstrom-Interface, in dem verschiedene virtuelle Kanäle im Zeitmultiplex verschachtelt werden, sowie ein Befehls-Interface [Command Interface], über das verschiedene zusätzliche Befehlsdaten gesendet werden. Auf diese Weise ermöglicht das Common Interface die Verbindung eines Conditional Access Module mit einem digitalen Fernsehempfänger oder einem beliebigen anderen digitalen Videogerät.
Basis für die vorliegende Erfindung ist die Erkenntnis, daß es vorteilhaft wäre, ein Conditional Access Module in einem lokalen Netzwerk von digitalen Multimediageräten, einschließlich Audio- und Videogeräten, vorzusehen, so daß die verschiedenen in dem Conditional Access Module verfügbaren Funktionen allen Geräten in dem Netz zur Verfügung gestellt werden können.
Es wurde ein Standard vorgeschlagen, um verschiedene digitale Videogeräte in einem lokalen Netzwerk miteinander zu verbinden. Insbesondere IEEE 1394 ist ein IEEE-Standard von 1995 für einen seriellen Hochleistungsbus, der einen als serieller IEEE-1394-Bus bezeichneten Bus für die gegenseitige Verbindung verschiedener digitaler audiovisueller Consumer-Produkte definiert.
Die IEEE-1394-Spezifikation definiert einen physikalischen Verbinder, ferner die elektrische Signalisierung sowie einen Satz von Verknüpfungs- und Transaktionsprotokollen, die es dem seriellen Bus ermöglichen, sich selbst zu konfigurieren und Audio-, Video- und Steuerinformationen effizient zu transportieren.
Außerdem wurde ein weiterer Satz von Zusatzprotokollen definiert, um MPEG-Daten zu transportieren und Steuermechanismen zwischen verschiedenen Gerätschaften an dem seriellen IEEE-1394-Bus zur Verfügung zu stellen. Diese Protokolle sind in der Spezifikation "Digital Interface for Consumer Electronic Audio/Video Equipment" (IEC 1883) definiert.
Die IEEE-1394-Spezifikation definiert Mechanismen und Protokolle, um zwei Typen von Daten, nämlich asynchrone und isochrone Daten, zu transportieren.
Asynchrone Daten stellen im allgemeinen keine Anforderungen an den Transportmechanismus bezüglich der Zeit, z.B. bezüglich des auftretenden Jitters oder der Verzögerung bei der Übertragung. Diese Daten können z.B. für Dateidaten oder für allgemeine Befehls- und Statusdaten benutzt werden.
Isochrone Daten stellen hingegen strenge Anforderungen bezüglich niedrigen Jitters und einer festen oder begrenzten Verzögerung für die Übertragung und können für MPEG-kodierte Audio- und Videodaten benutzt werden.
Im Hinblick auf die Entwicklungen im Zusammenhang mit dem seriellen IEEE-1394-Bus wird nun in Betracht gezogen, ein Conditional Access Module unter Verwendung des seriellen IEEE-1394-Busses mit einer Anzahl von verschiedenen digitalen Multimediageräten, wie Audio- und/oder Videogeräten zu verbinden. Unglücklicherweise treten bei der Implementierung eines solchen Systems jedoch erhebliche Probleme auf. Es wurden IEEE-1394-bezogene Protokolle entwickelt, die für die Benutzung mit Einzelkanal-MPEG-Datenströmen bestimmt sind, während die eigenen Protokolle für verschiedene Befehlsdaten vorgesehen sind. So haben insbesondere das allgemeine Interface für bedingten Zugriff [Conditional Access Common Interface] und der serielle IEEE-1394-Bus unterschiedliche Standards.
Die Literaturstelle Banks D et al.: "Breaking open the set top box" Proceedings of the SPIE, SPIE, Bellingham, VA, US, Band 3228, 4. November 1997 (1997-11-04), Seiten 105-116, XP002064906 ISSN: 0277-786X, befaßt sich mit dem Aufbrechen einer Set-Top-Box, indem die für den Netzwerkzugriff spezifischen Funktionen von den anwendungsspezifischen Funktionen physikalisch getrennt werden. Für die Verbindung von ankommenden Rundfunksignalen ist ein Gateway für den Netzwerkzugriff vorgesehen. Dies ermöglicht es, einen Transportstrom (oder einen Teil dieses Stroms) über einen IEEE-1394-Bus an ein oder mehrere Geräte, wie einen PC, ein digitales Fernsehgerät oder einen digitalen Videorekorder usw., zu senden. Das Gateway für den Netzwerkzugriff kann die Transportstrompakete auf der Basis des Programmidentifizierer(PID)-Werts in dem Paket-Header filtern. Auf diese Weise ist es möglich, nur das (die) interessierende(n) Programme) für die Ausgabe auf den IEEE-1394-Bus auszuwählen.
Das Patentdokument EP-A-0 905 932, das nur unter Artikel 54(3) EPÜ relevant ist, beschreibt die Verwendung eines IEEE-1394-Busses, der mit einer Anzahl von Set-Top-Boxen sowie mit einer Anzahl von Modulen zur Durchführung eines Entwürfelungsprozesses an dem von den Set-Top-Boxen ausgegebenen Datenstrom verbunden ist. Für den Fall, daß ein Rundfunksignal empfangen wird, extrahiert das PID-Filter unter Bezugnahme auf einen PID nur das Paket für das gewünschte Programm aus dem von dem Demodulator ausgegebenen Transportstrom, und es wird nur das Paket für das gewünschte Programm von dem digitalen Interface der Set-Top-Box ausgesendet.
Ein erster Aspekt der vorliegenden Erfindung betrifft das Problem, daß der zu dem Conditional Access Module gesendete Transportstrom für das Common Interface alle virtuellen Kanäle enthält und dadurch einen erheblichen Teil der über den seriellen IEEE-1394-Bus verfügbaren Bandbreite in Anspruch nimmt.
Der erste Aspekt der vorliegenden Erfindung befaßt sich auch mit dem Problem, daß es oft nicht genügt, lediglich den virtuellen Kanal an ein Conditional Access Module zu senden, den er für das Entwürfeln benötigt, da möglicherweise auch andere Daten in dem Transportstrom von dem Conditional Access Module benötigt werden.
Nach dem ersten Aspekt der vorliegenden Erfindung ist ein digitaler Multimedia-Empfänger vorgesehen für die Benutzung mit einem Modul für bedingten Zugriff [Conditional Access Module] unter Verwendung einer allgemeinen Schnittstelle [Common Interface],
mit einem Ausgang für einen seriellen IEEE-1394-Bus, um auf dem Bus einen Transportstrom zu einem Conditional Access Module zu senden,
mit einem Leser zum Lesen der Inhalte eines Transportstroms und zum Identifizieren der Daten, die für die Verarbeitung durch ein Conditional Access Module nicht benötigt werden,
mit einem Stripper zum Herausfiltern wenigstens einiger der identifizierten, nicht benötigten Daten aus dem Transportstrom,
mit einem Kodierer zum Erzeugen von geeigneten AV/C-CTS-Befehlen mit Headern, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Befehls-Interface entsprechen, und
mit einem Sender, um durch den Ausgang und über einen seriellen IEEE-1394-Bus die von dem Kodierer erzeugten AV/C-CTS-Befehle und alle übrigen Daten des Transportstroms zu senden, die nicht herausgefiltert wurden,
wobei der Empfänger ausgebildet ist, um einen von dem Conditional Access Module über den seriellen IEEE-1394-Bus zurückgeführten verarbeiteten Transportstrom zusammen mit AV/C-CTS-Befehlen mit Headern zu empfangen, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Befehls-Interface entsprechen,
wobei der Empfänger ferner einen Dekodierer aufweist, um aus den empfangenen AV/C-CTS-Befehlen passende Common-Interface-Objekte zu erzeugen.
Nach dem ersten Aspekt der Erfindung ist ferner ein Netzwerk von digitalen Multimediageräten vorgesehen, die über einen seriellen IEEE-1394-Bus miteinander verbunden sind, wobei das Netzwerk aufweist:
einen Empfänger zum Senden eines Transportstroms über den seriellen IEEE-1394-Bus unter Verwendung eines Common Interface und
ein Conditional Access Module zum Empfangen eines Transportstroms über den seriellen IEEE-1394-Bus unter Verwendung des Common Interface,
wobei der Empfänger aufweist:
einen Leser zum Lesen der Inhalte eines Transportstroms und zum Identifizieren der Daten, die für die Verarbeitung durch das Conditional Access Module nicht benötigt werden,
einen Stripper zum Herausfiltern wenigstens einiger der identifizierten, nicht benötigten Daten aus dem Transportstrom,
einen Kodierer zum Erzeugen von geeigneten AV/C-CTS-Befehlen mit Headern, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Befehls-Interface entsprechen, und
einen Sender, um durch den Ausgang und über einen seriellen IEEE-1394-Bus die von dem Kodierer erzeugten AV/C-CTS-Befehle und alle übrigen Daten des Transportstroms zu senden, die nicht herausgefiltert wurden,
wobei das Conditional Access Module einen verarbeiteten Transportstrom zusammen mit AV/C-CTS-Befehlen mit Headern zurückführt, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Befehls-Interface entsprechen,
wobei der Empfänger ausgebildet ist, um den verarbeiteten Transportstrom und AV/C-CTS-Befehle zu empfangen und ferner einen Dekodierer aufweist, um aus den empfangenen AV/C-CTS-Befehlen passende Common-Interface-Objekte zu erzeugen.
Da die einzigen Daten, die aus dem Transportstrom herauszufiltern sind, die Daten sind, die eindeutig als solche identifiziert werden, die von dem Conditional Access Module nicht benötigt werden, enthält der herausgefilterte Transportstrom alle Daten, die von dem Conditional Access Module benötigt werden. In der Praxis wird der Stripper darüber hinaus virtuelle Kanäle herausfiltern, die Rundfunkprogramm-Inhaltsdaten enthalten. Die Rundfunkprogramm-Inhaltsdaten nehmen den größten Teil der Bandbreite des Transportstroms in Anspruch. Deshalb hat das Herausfiltern dieser Daten einen ganz erheblichen Effekt auf die Reduzierung der Gesamtbandbreite des Transportstroms.
Die vorliegende Erfindung ist auf jeden beliebigen Typ von digitalen Multimediageräten anwendbar, einschließlich solcher Geräte, die Audiodaten, Videodaten, andere Multimediadaten oder eine Mischung davon verarbeiten. Sie ist besonders vorteilhaft für digitale Videogeräte, die zumindest Videodaten behandeln.
Der Transportstrom ist vorzugsweise ein MPEG-2-Transportstrom und wird in isochronen Kanälen unter dem IEC1883-Format übertragen.
In dem MPEG-Transportstrom befindet sich eine Tabelle mit programmspezifischen Informationen (PSI), so daß nicht benötigte Teile des Transportstroms für das Herausfiltern identifiziert werden können.
Der Empfänger kann nicht nur aus der PSI sondern auch aus dem Benutzerstatus, d.h. daraus, welches Programm der Benutzer anschauen oder aufzeichnen möchte, usw., feststellen, welche Ströme herausgefiltert werden sollen. Da Empfänger im allgemeinen nur ein Bild zu einer Zeit anzeigen können, ist dieses dann das einzige, das entwürfelt werden muß, während alle anderen ignoriert werden können.
Die folgende Beschreibung, die lediglich als Beispiel dient und auf die anliegenden Zeichnungen Bezug nimmt, soll die Erfindung weiter verdeutlichen.
1 zeigt eine Common-Interface-Architektur für DVB,
2(a) zeigt ein Netzwerk digitaler Multimediageräte,
2(b) zeigt ein Netzwerk digitaler Geräte mit einem Conditional Access Module,
3 zeigt einen IEEE-1394-Protokollstapel,
4 zeigt einen Protokollstapel für eine PC-Karten-Implementierung eines DVB-Common-Interface,
5 zeigt einen Protokollstapel für eine IEEE-1394-Implementierung eines DVB-Common-Interface,
6 zeigt schematisch eine Vorrichtung für die Implementierung eines Common-Interface-Befehls-Interface über einen seriellen IEEE-1394-Bus,
7 zeigt einen Protokollstapel für eine PC-Karten-Implementierung eines DVB-Common-Interface,
8 zeigt eine Vorrichtung zur Implementierung eines Common-Interface-Befehls-Interface über einen seriellen IEEE-1394-Bus,
9 zeigt eine Common-Interface-Konfiguration, die einen seriellen IEEE-1394-Bus benutzt,
10 zeigt einen Transportstrom-Interface-Protokollstapel für eine IEEE-1394-Implementierung eines DVB-Common-Interface,
11(a) und (b) zeigen einen Transportstrom und eine zugehörige Tabelle.
Wie oben erwähnt wurde, wurde bereits ein Standard für ein Common Interface für ein Conditional Access Module spezifiziert. 1 zeigt die Architektur dieses Standards.
Ein Empfänger oder Host 2 ist mittels des Common Interface 6 mit einem Common Interface Module, wie einem Conditional Access Module 4, verbunden.
Andere Typen von Common Interface Modules können HF-Eingangs-Frontenden umfassen, z.B. für den Empfang von Satellitensendungen, ferner Audiodekodierer für "Auditel"-Szenenbeschreibungen für Sehbehinderte, Module zur Messung des Zuschauerverhaltens usw..
Die DVB-(Digital Video Broadcast)-Common-Interface-Spezifikation definiert die physikalische Schicht des Common Interface, so daß dieses mit dem von PCMCIA spezifizierten PC-Karten-Standard konform ist. Mit anderen Worten, das Common Interface, das die physikalische Verbindung bildet, umfaßt einen 68-Wege-Verbinder mit der Standard-PC-Karten-Anordnung, wie sie heute in zahlreichen Personalcomputern benutzt wird. Das DVB-Common-Interface wurde jedoch mit einer Schichtarchitektur entworfen, um die Benutzung neuer physikalischer Schichten (z.B. des Smart-Card-Formfaktors) mit den gleichen Protokollen der oberen Schicht zu ermöglichen. Mit anderen Worten, die auf beiden Seiten der physikalischen Verbindung durchgeführte Verarbeitung wurde so entwickelt, daß unterschiedliche physikalische Anordnungen für die Verbindung benutzt werden können, ohne daß die Art und Weise, in der die standardisierte Verarbeitung wirkt, verändert wird.
Wie 1 zeigt, enthält das DVB-Common-Interface zwei Hauptteile, nämlich ein Transportstrom-Interface 8 und ein Befehls-Interface 10.
Das Transport-Interface 8 wird benutzt, um einen Transportstrom von dem Empfänger oder Host 2 zu dem Modul 4 und zurück zu dem Empfänger 2 zu übertragen. Der Empfänger 2 empfängt ein HF-Eingangssignal 12, wobei mit Hilfe eines Tuners 14 ein spezielles Band ausgewählt und dieses Band in dem Demodulator 16 demoduliert wird. Das Ausgangssignal des Demodulators 16 umfaßt einen Transportstrom mit virtuellen Zeitmultiplexkanälen. Diese werden über das Transportstrom-Interface 8 einem Entwürfeler 18 in dem Modul 4 zugeführt. Der Entwürfeler 18 identifiziert diejenigen virtuellen Kanäle, für die er bestimmt ist und sendet einen Transportstrom, in denen die ausgewählten virtuellen Kanäle entwürfelt wurden, über das Transportstrom-Interface 8 an den Empfänger 2 zurück. In dem Empfänger 2 wählt ein Demultiplexer 20 einen geforderten virtuellen Kanal aus und liefert MPEG-Pakete, die sich auf diesen virtuellen Kanal beziehen, an einen MPEG-Dekodierer 22, der seinerseits ein Audio-/Video-Ausgangssignal 24 ausgibt.
Der zweite Teil des DVB-Common-Interface ist das Befehls-Interface 10. Dieses sieht ein höheres Protokoll vor, das es dem Host-Empfänger 2 und dem Modul 4 ermöglicht, zu kommunizieren, und daß es darüber hinaus Anwendungen in dem Host-Empfänger 2 oder dem Modul 4 ermöglicht, über das Interface auf Ressourcen zuzugreifen. Für die Kommunikation über das Befehls-Interface sind standardisierte Codes und Datenformate vorgesehen.
Ein Mikroprozessor 26 des Host-Empfängers 2 und ein Mikroprozessor 28 des Moduls 4 können mit Hilfe des Befehls-Interface miteinander kommunizieren. Darüber hinaus kann das Gesamtsystem ein MODEM, einen Graphikgenerator usw. aufweisen, und das Befehls-Interface kann auch benutzt werden, um Steuerinformationen zu diesen Geräten zu übertragen. So kann das Modul 4 beisüielsweise den Wunsch haben, über ein MODEM mit einem Fernsteuerzentrum zu kommunizieren, um Einzelheiten über Abonnementgebühren zu erfahren, und dann eine Fernsehanzeige so zu steuern, daß diese entsprechende Meldungen über den Abonnementstatus anzeigt. Diese Kommunikation kann mit Hilfe des Befehls-Interface 10 erreicht werden.
Wie oben erwähnt wurde, wurde bereits vorgeschlagen, verschiedene digitale Videogeräte über einen seriellen IEEE-1395-Bus miteinander zu verbinden. 2a zeigt ein Netzwerk, in dem ein digitaler Fernsehempfänger 30 mit einem digitalen Videorekorder 32 verbunden ist, der seinerseits mit einem digitalen Videodisk-Gerät 34 verbunden ist, das seinerseits mit einem Personalcomputer 36 verbunden ist.
Der IEEE-1394-Bus ist ein serieller Bus, der einen preiswerten Mechanismus für die Übertragung von Audio-, Video- und Steuerinformationen zwischen Geräten ermöglicht. Er eignet sich sehr gut für audiovisuelle Consumer-Anwendungen, und man geht davon aus, daß er in weitem Umfang für zahlreiche neue digitale Consumer-Produkte benutzt wird. Er ist besonders attraktiv, da er einen "Plug-and-Play"-Betrieb bietet. Mit anderen Worten, ein zusätzliches Gerät kann ohne eine spezielle Rekonfigurierung des Netzwerks an das Netz angeschlossen werden, und es sind Protokolle enthalten, mit denen Geräte in dem Netzwerk automatisch feststellen, welche anderen Geräte vorhanden sind.
Die IEEE 1394 Trade Association ist eine Industriegruppierung, in der alle an dem seriellen IEEE-1394-Bus interessierten Industrieparteien vereinigt sind. Diese Trade Association hat einen Protokollsatz definiert, der einen Satz von Befehlen bietet, die über den seriellen IEEE-1394-Bus in dem Format des oben erwähnten IEC-1883-Funktionssteuerprotokolls (FCP) auszuführen sind. Dieser Befehlssatz ist bekannt als Audio-/Video-Control-Command-Transactions (AV/C-CTS) und ist in dem Dokument "AV/C Digital Interface Command Set" definiert, das von der IEEE 1394 Trade Association entwickelt wurde (siehe AV/C Digital interface Command Set Version 2.0D, 26. März 1997, Audio/Video Working Group of the IEEE 1394 Trade Association). Der AV/C-CTS stellt allgemeine Einrichtungs- und Steuerbefehle sowie Sätze von Befehlen speziell für digitale Videorekorder und Tuner zur Verfügung. Sie werden unter Verwendung eines Headers und von Nutzdaten kodiert. Der Header enthält eine Information, wie die Zieladresse, sowie den Opcode, der die Funktion des Befehls spezifiziert. Weitere Operanden der Befehle werden in den Nutzdaten des Befehls transportiert.
Somit kann die Datenkommunikation über den seriellen IEEE-1394-Bus als eine Schichtstruktur mit dem aus den verschiedenen Protokollschichten gebildeten Protokollstapel betrachtet werden, der in 3 dargestellt ist.
Für die Befehlsinformation, die z.B. einen Videorecorder anweist, die Wiedergabe eines Videosignals zu starten, werden Daten als asynchrone Daten über den seriellen IEEE-1394-Bus gesendet. Dies ist auf der linken Seite des Protokollstapels von 3 dargestellt.
Die Befehle werden unter Verwendung des AV/C-CTS-Protokolls gesendet, wobei ein spezieller AV/C-CTS-Befehl einen Header besitzt, der für seine Zieleinheit, z.B. einen Videorekorder, spezifisch ist und die geforderte Grundfunktion, z.B. das Abspielen eines Videobands, anzeigt. Der AV/C-CTS-Header spezifiziert Felder für den Befehlstyp (z.B. Befehl, Status, Anfrage, Mitteilung usw.), den Untereinheitstyp und den Untereinheits-Identifizierer, so daß er die Ziel-Untereinheit für einen Befehls-AV/C-Rahmen und die Quell-Untereinheit für einen Antwort-AV/C-Rahmen definiert. Auf diese Weise arbeitet der AV/C-CTS nach einem Befehl/Antwort-Schema mit einer ersten Untereinheit, die einen Befehls-AV/C-Rahmen an eine zweite Untereinheit sendet, und der zweiten Untereinheit, die mit einem Antwort-AV/C-Rahmen antwortet.
Der Opcode für den Befehl ist ebenfalls in dem Header so spezifiziert, daß er die Grundfunktion angibt. Die Nutzdaten können so angeordnet sein, daß sie weitere Operanden oder zusätzliche Informationen spezifizieren, die z.B. anzeigen, daß das Abspielen mit einer bestimmten Geschwindigkeit, wie langsamer Vorwärtslauf, schneller Vorwärtslauf, schnellster Vorwärtslauf, erfolgen soll.
Die Protokollschicht des AV/C-CTS wurde so entwickelt, daß sie mit der darunter liegenden Protokollschicht, dem IEC-1883-Funktions-Steuerprotokoll, konform ist. Dieses ist ein spezielles Protokoll zum Adressieren eines Knotens (einer Einheit in dem Netzwerk) mit angehängten Daten. Somit würde das IEC-1883-FCP im vorliegenden Fall das AV/C-CTS als angehängte Daten übertragen.
AV/C-CTS-Protokolle sind eine spezifische Befehlssatz-Implementierung des FCP. Die AV/C-CTS-Befehle werden kodiert, indem ein FCP-Rahmen benutzt wird, dessen Header die Ziel- und Quelladresse des IEEE-1394-Knotens (Geräts), die Rahmendatenlänge, den CRC und weitere Informationen spezifiziert. Insbesondere bilden die ersten vier Bits der FCP-Rahmen-Nutzdaten ein Feld, das den Befehlssatz spezifiziert, der von dem FCP-Rahmen ausgeführt werden soll. Der Header des FCP-Rahmens transportiert in diesem Feld einen Wert "0", um anzuzeigen, daß er einen AV/C-CTS- Befehl transportiert. Durch die Benutzung anderer Werte in diesem Feld könnten andere Befehlssätze als AV/C-CTS durch den FCP-Rahmen transportiert werden. Der Rest der FCP-Rahmen-Nutzdaten enthält den AV/C-Header und Nutzdaten.
Die in der IEEE-1394-Spezifikation definierten Protokollschichten enthalten eine IEEE-1394-Transaktionsschicht, die die Lieferungs- und Quittungsdaten für die Daten behandelt, sowie eine IEEE-1394-Verknüpfungsschicht, die die verschiedenen Daten-Verknüpfungen an die verschiedenen Einheiten liefert. Die unterste Schicht schließlich ist die physikalische IEEE-1394-Schicht, die die physikalischen Verbindungen umfaßt.
Die Transaktionsschicht liefert einen Satz von Diensten für Anwendungen, die in Geräten an dem IEEE-1394-Bus ablaufen, insbesondere ausschließlich für asynchrone Daten. Dieses sind Dienste, wie Lesen und Schreiben und das Aktivieren von Geräten, um auf andere Geräte an dem Bus zuzugreifen, indem eine Knoten-ID des Geräts und die Adresse innerhalb des Knotens spezifiziert werden. Die Dienste sind so gestaltet, daß sie Lese- und Schreibvorgänge sowie Quittungen zurück zu dem Anfragenden vorsehen. Die Transaktions-Schicht sieht auch "Verriegelungs"-Dienste vor. Diese sind als "atomare" Operationen definiert, was bedeutet, daß diese Operationen zeitlich unteilbar sind, so daß z.B. eine "Prüf- und Einstell"-Operation von einem Gerät an ein anderes nicht mittendrin durch ein anderes Gerät unterbrochen wird, das die gleiche Stelle modifiziert. Dies ist für einen Peer-to-Peer-Bus, wie IEEE 1394, bei dem zahlreiche Geräte mit gleicher Priorität aufeinander zugreifen können, sehr wichtig.
Die Verknüpfungsschicht bewirkt die Paketisierung der asynchronen und isochronen Daten. Die Verknüpfungsschicht sieht auch eine Zyklussteuerung vor, die es ermöglicht, daß isochrone Daten mit geringer Latenz und begrenztem Jitter transportiert werden.
Die unterste Schicht ist die physikalische Schicht (oder die PHY-Schicht in der IEEE-1394-Terminologie). Sie bewirkt die elektrische Signalisierung und Kodierung der zu sendenden und zu empfangenden Datenbits in der untersten Ebene. Die PHY-Schicht bewirkt auch die Arbitration der untersten Schicht zwischen Geräten an dem Bus, so daß nur ein Gerät den Bus zu einer Zeit betreiben kann. Die PHY-Schicht definiert auch den Verbinder und die erforderlichen Eigenschaften für die Kabelmedien.
Die Protokollschichten für isochrone Daten, wie MPEG-Daten, sind auf der rechten Seite von 3 dargestellt.
Die isochronen Daten werden entsprechend der IEC-1883-Protokollschicht gesendet. Diese wird von der IEEE-1394-Verknüpfungsschicht direkt unterstützt, die die verschiedenen Verbindungen mit der physikalischen IEEE-1394-Schicht einrichtet. Insbesondere richtet die IEC-1883-Protokollschicht einen isochronen Kanal zwischen zwei Geräten an dem Bus ein.
Die IEEE-1394-Spezifikation definiert die untersten Schichten für die Beförderung von isochronen Daten, nämlich die physikalischen und Verknüpfungsschichten, wie sie oben beschrieben wurden. Die IEC-1883-Protokolle liefern Mechanismen, die den effizienten Transport von AV-Daten unter Verwendung eines allgemeinen isochronen Paket-Headers (CIP-headers) ermöglichen. Dieser erlaubt es, AV-Datenpakete für den Transport über den IEEE-1394-Bus aufzutrennen, außerdem besitzt er Felder für das Signaldatenformat (Standard- oder hochauflösende Videodaten, Halbbildrate 50 Hz oder 60 Hz). Die IEC-1883-Spezifikation stellt auch das Konzept logischer Kanäle und Steckverbindungen für die Beförderung und Verbindung von AV-Daten zwischen Geräten auf den IEEE-1394-Bus zur Verfügung.
Auf diese Weise stellen der serielle IEEE-1394-Bus und die zugehörigen Protokolle einen Mechanismus für periphere Audio-/Videogeräte zur Verfügung, um zusammen mit digitalen Audio-/Videodaten Befehls- und Steuerinformationen zu übertragen.
Als Basis für die vorliegende Erfindung wird vorgeschlagen, daß auch ein Common Interface Module, wie ein Conditional Access Module, unter Verwendung eines seriellen IEEE-1394-Busses mit einem Netzwerk von digitalen Videogeräten verbunden werden kann.
2b zeigt das Netzwerk von 2a, das jedoch darüber hinaus ein Conditional Access Module 38 enthält. Diese Anordnung besitzt eine Anzahl signifikanter Vorteile gegenüber der zuvor vorgeschlagenen PC-Karten-Implementierung des DVB-Common-Interface.
Mit dem auf dem Netzwerk vorgesehenen Conditional Access Module können die Funktionen für bedingten Zugriff von jedem peripheren Gerät in gleicher Weise benutzt werden. Darüber hinaus muß kein spezielles peripheres Gerät Leistung an das Modul liefern oder als Protokollbrücke agieren, über die das Modul mit dem Rest des Netzwerk kommuniziert.
Da das Modul an dem Netzwerk physikalisch nicht eng an irgendeinen speziellen Empfänger gebunden sein muß, besteht mehr Flexibilität bezüglich seiner physika lischen Form und seiner Positionierung. Mit anderen Worten, während vorher ein Conditional Access Module mit der Rückseite eines Empfängers oder Videorekorders verbunden sein mußte, ermöglicht das Netzwerk die Plazierung des Moduls an irgendeiner bequemen Position und in irgendeiner bequemen Form.
Falls Funktionen für bedingten Zugriff statt in einem separaten Conditional Access Module in einem speziellen Gerät, wie einem Empfänger, eingebettet sind, eröffnet das Netzwerk anderen Geräten die Möglichkeit, von den eingebetteten Funktionen für bedingten Zugriff Gebrauch zu machen.
4 zeigt die verschiedenen Protokollschichten, die den Protokollstapel für das Befehls-Interface eines Common Interface bilden, wie er in einem PC-Kartenformat implementiert ist. In dieser Figur sind auch die entsprechenden Abschnitte des oben erwähnten Dokuments EN50221 über die Common-Interface-Standards angegeben.
In der obersten Schicht, der Anwendungsschicht, sind die verschiedenen Anwendungen und Ressourcen vorgesehen.
Darunter befindet sich die Sitzungs-Schicht. Wenn ein spezielles Gerät eine Anwendung besitzt, die die Benutzung einer Ressource erfordert, richtet sie mit Hilfe der Sitzungs-Schicht eine Sitzung mit einer anderen Ressource ein.
Der Prozeß benutzt alle Schichten bis hinunter zu der untersten physikalischen Schicht. Von der untersten physikalischen Schicht aus werden dann alle verschiedenen Schichten bis hinauf zu der Ressource des anderen Geräts benutzt. Mit anderen Worten, die Daten werden zwischen der Ressource und der Anwendung übertragen, indem die Daten von der Anwendung herunter durch alle Schichten bis zu der physikalischen Schicht verarbeitet werden, wo sie dann zurück bis zu der Ressource verarbeitet werden. Die Daten können dann in ähnlicher Weise von der Ressource zu der Anwendung zurückkehren.
Untere Schichten sind im allgemeinen zu den oberen Schichten hin transparent, so daß es einer Anwendung, wenn sie eine Sitzung mit einer Ressource anfordert, nicht bewußt ist, wie die Sitzungs-Schicht oder niedrigere Schichten diese Sitzung zustande bringen.
Die unterste generische Schicht des DVB-Common-Interface ist die generische Transportschicht. Diese Schicht sieht einen Satz von elf Transportobjekten vor, die benutzt werden, um die Erzeugung und die Beseitigung von Transportverbindungen zu steuern und über diese Transportverbindungen Daten zu befördern.
Unter der generischen Transportschicht richtet die PC-Karten-Transportschicht das Senden von Daten in Wirklichkeit so ein, daß es für die Übertragung über das durch die PC-Karte definierte elektrische/physikalische Interface geeignet ist. Da tiefere Schichten transparent sind, ist es für die generische Transportschicht nicht wichtig, wie die weitere Datenkommunikation stattfindet. Insbesondere ist es für die generische Transportschicht nicht wichtig, ob das PC-Kartenformat benutzt wird.
Unter Bezugnahme auf 5 wird eine Lösung für das Problem der Anordnung des Befehls-Interface auf dem seriellen IEEE-1394-Bus vorgeschlagen.
Diese Lösung basiert auf dem Senden der Befehlsdaten des Befehls-Interface mittels asynchroner Daten auf dem seriellen IEEE-1394-Bus und schlägt vor, die AV/C-CTS-Protokolle so zu erweitern, daß sie die Befehlsdaten transportieren.
Wie in 5 dargestellt, ist die PC-Karten-Transportschicht, die zuvor die höhere generische Transportschicht verarbeitete, durch eine IEEE-1394-Common-Interfacespezifische Transportschicht ersetzt.
Wie oben erwähnt wurde, sind die niedrigeren Schichten zu der generischen Transportschicht transparent. Deshalb müssen die generische Transportschicht und die höheren Schichten die verschiedenen spezifischen Transportschichten nicht kennen, und die Funktion des Standard-Befehls-Interface wird nicht geändert.
Befehle werden in der generischen Transportschicht in der gleichen Weise erzeugt, wie zuvor. Sie werden jedoch nicht durch die PC-Kartenanordnung sondern durch die für das IEEE-1394-Common-Interface spezifische Transportschicht nach Maßgabe der IEEE-1394-Anordnung behandelt.
Die erweiterten AV/C-CTS-Protokolle stellen einen Mechanismus für die Beförderung der Befehls-Interface-Protokolle zur Verfügung. Im Ergebnis transportieren die AV/C-CTS-Protokolle die neu definierte IEEE-1394-Common-Interface-spezifische Transportschicht.
Die vorgeschlagenen Erweiterungen an den AV/C-CTS-Protokollen sind die folgenden. Den elf Objekten des Befehls-Interface wird jeweils ein AV/C-CTS-Opcode hinzugegeben, so daß es für jedes einzelne der elf Objekte des Befehls-Interface einen separaten AV/C-CTS-Befehl gibt. Die Objekte des Befehls-Interface können dann innerhalb der Nutzdaten des AV/C-CTS-Befehls kodiert werden, wobei eine ähnliche Syntax benutzt wird, wie sie bei der PC-Karten-Implementierung verwendet wird.
Das AV/C-CTS-Protokoll kann so erweitert werden, daß es weitere als "Untereinheits-Typen" definierte periphere Geräte abdeckt, und das Conditional Access Module kann als neuer Untereinheits-Typ definiert werden. Auf diese Weise wird jeder der elf neuen AV/C-CTS-Opcodes als ein solcher erkannt, der im Gegensatz zu Opcodes, die für Fernsehempfänger, Videorecorder usw. bestimmt sind, für ein Conditional Access Module bestimmt ist.
Auf diese Weise kann das Befehls-Interface weiterhin in der gleichen Weise arbeiten, wie es zuvor für die PC-Karten-Implementierung definiert wurde. Es ist nicht notwendig, die oberen Schichten zu modifizieren oder irgendwelche Kenntnisse über die Kommunikationsmittel der unteren Schicht zu besitzen. Ähnlich wird die Kommunikation der Befehls-Interface-Daten unter Verwendung der für den seriellen IEEE-1394-Bus bereits definierten Standards erreicht, so daß keine Modifizierungen an diesen Standards erforderlich sind.
Auf diese Weise ist es möglich, ein Conditional Access Module zur Verfügung zu stellen, das über den seriellen IEEE-1394-Bus arbeitet, indem lediglich zusätzliche AV/C-CTS-Opcodes vorgesehen werden, die Transportobjekten des Befehls-Interface entsprechen.
6 zeigt schematisch eine Vorrichtung, wie einen Host-Empfänger 2 oder ein Conditional Access Module 4, die ein Befehls-Interface über einen seriellen IEEE-1394-Bus implementiert.
Ein Mikroprozessor 26, 28, kann weiterhin in der üblichen Weise Befehlsdaten erzeugen und empfangen. Es sind jedoch zusätzliche Funktionsblöcke, nämlich ein Kodierer 40 und ein Dekodierer 42 vorgesehen, um die Daten entsprechend den erweiterten AV/C-CTS-Protokollen umzuwandeln.
Der Kodierer 40 erzeugt geeignete AV/C-CTS-Befehle mit Headern, die passende Exemplare der elf Opcodes enthalten, die den elf Objekten des Befehls-Interface entsprechen. Objekte des Befehls-Interface können dann auch in den Nutzdaten der AV/C-CTS-Befehle enthalten sein, indem eine ähnliche Syntax wie die Syntax für die PC-Karten-Implementierung benutzt wird.
Andererseits erzeugt der Dekodierer 42 aus den Opcodes passende Befehls-Interface-Objekte und Nutzdaten der empfangenen AV/C-CTS-Befehle.
Es ist ein Sender 44 vorgesehen, um die AV/C-CTS-Befehle, z.B. unter dem IEC-1883-Protokoll, über einen Port 48 zu senden.
Ein Empfänger 46 empfängt AV/C-CTS-Befehle von dem Port 48 und unterscheidet passende AV/C-CTS-Befehle, indem er im Gegensatz zu Opcodes, die für andere Einheiten benutzt werden, Exemplare der elf neuen Common-Interface-Opcodes identifiziert.
7 zeigt eine alternative Lösung für das Problem der Übertragung von Befehls-Interface-Daten über den seriellen IEEE-1394-Bus.
Im Einzelnen wird vorgeschlagen, einen isochronen Kanal zu benutzen, um die Befehls-Interface-Daten zu transportieren. Dies hat den Vorteil, daß für DVB-Common-Interface-Befehls-Interface-Daten eine Bandbreite garantiert werden kann, was sehr nützlich ist, wenn Anwendungen, z.B. Graphiken, laufen, die eine schnelle Antwort und eine geringe Verzögerung erfordern. Es wird vorgeschlagen, daß bei der Initialisierung zwei isochrone Kanäle erzeugt werden, einer, der von dem Host zu dem Modul und ein anderer, der von dem Modul zu dem Host verläuft.
Aus dem Vergleich von 4 und 7 erkennt man, daß die Transportschicht-Implementierung von 7, nämlich die PC-Karten-Transportschicht, durch eine IEEE-1394-Common-Interface-spezifische Transportschicht ersetzt wurde.
Da niedrigere Schichten zu der generischen Transportschicht hin transparent sind, hat das Ersetzen der PC-Karten-Transportschicht keine Auswirkung auf die generische Transportschicht, und die IEEE-1394-Common-Interface-spezifische Transportschicht behandelt lediglich die Daten der generischen Schicht in einer für den seriellen IEEE-1394-Bus geeigneten Weise. Wenn eine Sitzung erforderlich ist, um Befehls-Interface-Daten zwischen eine Anwendung und einer Ressource zu übertragen, arbeiten die IEEE-1394-spezifische Common-Interface-Transportschicht und die IEC-1883-implementierte Verknüpfungsschicht zusammen, um zwei isochrone Kanäle einzurichten, über die die Befehlsdaten gesendet werden können.
8 zeigt schematisch eine Vorrichtung, wie einen Host-Empfänger 2 oder ein Modul 4, mit einem entsprechenden Mikroprozessor 26 oder 28.
Wie dargestellt, ist ein zusätzlicher Funktionsblock 50 vorgesehen. Dieser kommuniziert über den seriellen IEEE-1394-Bus, z.B. mittels des IEC-1883-Protokolls, mit anderen Geräten, um isochrone Kanäle einzurichten. Die Befehlsdaten des Befehls-Interface können dann über einen geeigneten Kanal gesendet oder empfangen werden.
Sobald die isochronen Übertragungskanäle eingerichtet sind, sind keine Quittungen oder dgl. erforderlich. Deshalb benötigt die dem seriellen IEEE-1394-Bus entsprechende Seite des Interface keine Kenntnis und erfordert auch keinerlei Modifizierung im Hinblick auf die Befehls-Interface-Daten, die gesendet werden. Diese Implementierung kann jedoch vorzugsweise einige der oben diskutierten Merkmale enthalten. Insbesondere kann das AV/C-CTS-Protokoll trotzdem so erweitert werden, daß es zusätzlich zu den vorherigen Einheiten, wie dem Empfänger und dem Videorekorder, ein Conditional Access Module als einen weiteren Untereinheits-Typ definiert. Dies erlaubt eine verbesserte Interoperabilität mit anderen Geräten an dem seriellen IEEE-1394-Bus, die insbesondere die Identifizierung des Conditional Access Module durch andere Peripheriegeräte an dem seriellen IEEE-1394-Bus ermöglicht.
Die Transportobjekte des Befehls-Interface bestehen aus Objekten, die für die Erzeugung und Beseitigung von Transportverbindungen benutzt werden, und Objekten, die zur Beförderung der Daten für die höheren Protokollschichten benutzt werden. Die auf die Steuerung bezogenen Objekte können entweder jeweils in separaten AV/C-CTS-Befehlen oder in einem generischen AV/C-CTS-Befehl als AV/C-CTS-Befehle kodiert werden.
Die für die Datenbeförderung benutzten Objekte können dann benutzt werden, um die Daten auf den isochronen Kanälen zu und von den Modulen zu befördern.
Mit anderen Worten, die generische Transportschicht definiert elf Objekte, die in zwei Sätze aufgeteilt werden können. Ein Satz wird für das Verbindungsmanagement, das Einrichten und Schließen von Transportverbindungen benutzt, während der andere Satz für die Datenbeförderung über eine existierende Transportverbindung benutzt wird, die zuvor mit Hilfe der anderen Transportobjekte eingerichtet wurde. Im allgemeinen werden Transportverbindungen nicht sehr häufig eingerichtet, und die am häufigsten benutzten Transportobjekte sind diejenigen, die für die Beförderung von Daten verwendet werden.
Die Benutzung des isochronen Kanals gewährleistet Bandbreite für Anwendungen. Deshalb sind die Transportobjekte, die auf den isochronen Kanälen am häufigsten benutzt werden, Transportobjekte, die Daten befördern und nicht solche, die Verbindungen usw. einrichten. Die Transportobjekte für das Verbindungsmanagement könnten deshalb weiterhin als AV/C-CTS-Befehle befördert werden, wie dies oben diskutiert wurde, und würden die Effizienz des Schemas nicht sehr beeinträchtigen. Da ein Schichtschema benutzt wird, muß der generischen Transportschicht nicht bekannt sein, ob die Objekte als asynchrone oder als isochrone Daten befördert wurden. Es kann passender sein, die Transportobjekte für das Verbindungsmanagement als AV/C-CTS-Befehle zu befördern.
Auf der anderen Seite könnten alle elf Transportobjekte des Befehls-Interface in der gleichen Weise kodiert werden wie bei der gegenwärtigen DVB-Common-Interface-Spezifikation und dann in den isochronen IEEE-1394-Kanälen befördert werden. Dies vermeidet die Benutzung des AV/C-Befehlssatzes, da dieser nur für die Benutzung mit den asynchronen Daten benötigt wird.
Die Verwendung eines isochronen Kanals für das Befehls-Interface hat den Nachteil, daß dem Befehls-Interface zugeteilte Bandbreite verschwendet wird, wenn es die vorgesehenen isochronen Kanäle nicht vollständig ausfüllt. Insbesondere wird Bandbreite, die für intensive Anwendungen zugeteilt ist, verschwendet, wenn diese Anwendungen nicht aktiv sind.
Es wäre möglich, die Bandbreite der benötigten isochronen Kanäle dynamisch zuzuteilen, und zwar in Abhängigkeit davon, wieviel die Anwendungen in irgendeiner Zeit benötigen. Ein Host und ein Modul könnten mit einem niedrigen Bandbreite-Vorgabewert für die isochronen Kanäle des Befehls-Interface initialisieren und dann, wenn eine Anwendung eine schnellere Antwort erfordert, die Zuteilung von mehr Bandbreite anfordern. Das Gerät (Host oder Modul), das die Extrabandbreite benötigt, kann den isochronen Ressourcenmanager kontaktieren und die erforderliche Extrabandbreite anfordern. Falls dann die Bandbreite verfügbar ist, kann sie diesem Gerät zugeteilt werden. In der gleichen Weise kann Bandbreite aufgegeben werden. Das Gerät, das die Bandbreite anfordert, kann dann auf dem die Extrabandbreite benutzenden, existierenden isochronen Kanal und über die existierende Verbindung ausgeben.
Der isochrone Ressourcenmanager ist eine Vorrichtung, die an dem Bus benötigt wird, wenn isochrone Kanäle ermöglicht werden sollen. Verschiedene Geräte könnten in der Lage sein, die funktion des isochronen Ressourcenmanagers auszuüben, und es findet eine Arbitration statt, die es einem Gerät erlaubt, zum isochronen Ressourcenmanager zu werden.
Um ein Conditional Access Module in einem Netzwerk mit einem seriellen IEEE-1394-Bus einzusetzen, ist es auch notwendig, daß Transportströme zu dem und von dem Conditional Access Module fließen.
Die PC-Karten-Implementierung eines DVB-Common-Interface befördert die Transportströme, die dedizierte elektrische Verbindungen an dem Host und Modulverbinder benutzen. Der serielle IEEE-1394-Bus sieht keine solche physikalische Verbindung vor, sondern nur einen Satz von isochronen Kanälen, die logische Verbindungen zwischen Host und Modul zur Verfügung stellen. Deshalb muß ein Verbindungsprotokoll definiert werden, um Transportstromverbindungen zwischen Host und Modul herstellen zu können.
Die IEC-1883-Implementierungen bezüglich des Managements serieller Busse sind mit dem IEEE-1394-Interface-Standard konform. Nach diesen Implementierungen und Standards soll ein als Knoten bekanntes Ausrüstungselement, das über eine Interface-Karte mit dem IEEE 1394 verbunden ist, die Eignung zum Zyklusmaster haben. Mit anderen Worten, es ist eine Zyklusmastereinheit vorgesehen, um das Timing der von allen Knoten auf dem seriellen IEEE-1394-Bus benutzten isochronen Kanäle zu steuern. Jeder Knoten kann auch die Funktion des isochronen Ressourcenmanagers übernehmen, so daß ein isochroner Ressourcenmanager die Zuteilung von isochronen Ressourcen an Knoten auf dem seriellen IEEE-1394-Bus steuern kann. Mit anderen Worten, der Ressourcenmanager kann spezielle isochrone Kanäle zwischen speziellen Knoten einrichten. Schließlich sollte ein Knoten, der gerade isochrone Pakete sendet oder empfängt, Steckverbinder-Steuerregister zur Verfügung stellen, die selbst dazu benutzt werden, audiovisuelle Verbindungen zwischen Knoten auf dem seriellen IEEE-1394-Bus einzurichten und zu steuern.
Die in dem IEC-1883-Standard beschriebenen Protokolle sehen ein Verfahren zum Steuern eines isochronen Datenflusses zwischen Geräten vor, die über den seriellen IEEE-1394-Bus miteinander verbunden sind. Nach diesem Standard besitzen die Geräte Eingangs- und Ausgangsstecker zum Senden und Empfangen von isochronen Datenflüssen. Jeder Stecker kann nur einen isochronen Datenfluß befördern, und dieser isochrone Datenfluß wird in einem isochronen Datenkanal befördert, der selbst nur einen isochronen Datenfluß befördern kann.
Zwischen zwei Steckern wird eine Verbindung hergestellt, die die Nummer des isochronen Kanals und die geforderte Bandbreite definiert.
Verbindungen können an einem Stecker überlagert sein, um zu ermöglichen, daß ein isochroner Datenfluß mit mehr als einem Zielstecker verbunden wird. Obwohl in diesem Fall mehr als eine Verbindung vorhanden ist, ist es trotzdem nur ein isochroner Kanal, der den Datenfluß befördert.
9 zeigt eine mögliche Konfiguration, in der ein Conditional Access Module 38 an einen seriellen IEEE-1394-Bus angeschlossen ist.
Es wird vorgeschlagen, isochrone Kanäle zu benutzen, um die MPEG-Transportströme zu befördern. Insbesondere wird vorgeschlagen, daß isochrone Kanäle IEC-1883-Protokolle benutzen, um den MPEG-Transportstrom unter Verwendung des oben erwähnten allgemeinen isochronen Paket-Headers (CIP-Headers) zu transportieren.
10 zeigt die verschiedenen Protokollschichten, aus denen der geeignete Protokollstapel aufgebaut ist.
Die oberen Schichten entsprechen den oberen MPEG-Schichten, die für das Common Interface benutzt werden, so daß die höheren generischen Protokollschichten des Common Interface keinerlei Modifizierungen erfordern.
Zur Implementierung dieses Systems wird vorgeschlagen, daß das Conditional Access Module und der Host-Empfänger jeweils wenigstens einen Eingangsstecker und einen Ausgangsstecker besitzen, wie in IEC 1883 definiert, ferner ein Master-Eingangs- und -Ausgangsstecker-Steuerregister, wie in IEC 1883 definiert, und ein Eingangs- und Ausgangsstecker-Steuerregister für jeden implementierten Stecker, wie in IEC 1883 definiert.
Es wird nun ein Verbindungsprotokoll für die in 9 dargestellte Anordnung beschrieben, das benutzt werden könnte, um Transportströme zwischen dem Host-Empfänger 30 und dem Conditional Access Module 38 zu übertragen.
Zunächst identifiziert der Host 30 alle in dem Netzwerk vorhandenen DVB-Common-Interface-Module, wobei er vorzugsweise den in dem AV/C-CTS-Protokoll definierten Untereinheits-Mechanismus benutzt. Der Host 30 fordert dann von dem isochronen Ressourcenmanager die Benutzung von zwei isochronen Kanälen an, jeweils mit der Bandbreite, die notwendig ist, um den geforderten Transportstrom zu befördern.
Der Host 30 konfiguriert dann das Eingangsstecker-Steuerregister des Conditional Access Module 38, um auf dem ersten isochronen Kanal einen Transportstrom zu empfangen, und konfiguriert sein eigenes Ausgangsstecker-Steuerregister, um den Transportstrom auf diesen Kanal auszugeben. Der Host 30 konfiguriert dann das Ausangsstecker-Steuerregister des Moduls, um den Transportstrom auf dem zweiten isochronen Kanal auszugeben, und konfiguriert sein eigenes Eingangsstecker-Steuerregister, um den Transportstrom auf diesem Kanal zu empfangen.
Der Host 30 kann dann über den ersten isochronen Kanal einen verwürfelten Transportstrom senden und über den zweiten isochronen Kanal den verwürfelten Transportstrom von dem Modul 38 zurück empfangen.
Da das Conditional Access Module 38 nicht mit einem speziellen Gerät verbunden ist, ist es auch nicht mehr wesentlich, daß ein entwürfelter reiner Transportstrom zu der Quelle 30 des verwürfelten Stroms zurückgesendet werden muß. Somit kann das Conditional Access Module 38 flexibler genutzt werden und einen reinen Strom zu einem Gerät senden, das sich von dem unterscheidet, aus dem der verwürfelte Strom empfangen wurde.
Natürlich muß der von dem Empfänger 30 empfangene verwürfelte Transportstrom zu dem Conditional Access Module 38 gesendet werden. Es ist für das Conditional Access Module dann jedoch möglich, den enrwürfelten Transportstrom (über den Empfänger) nur zu dem digitalen Videorekorder 32 oder sowohl zu dem digitalen Videorekorder 32 als auch zu dem Empfänger 30 zu senden. Das Conditional Access Module 38 muß somit entweder an ein Ziel oder an zwei Ziele senden.
Bei dem in 9 dargestellten Beispiel besteht ein erster Vorschlag darin, daß der Empfänger 30 über die notwendigen Ressourcen zum Schalten des Transportstroms verfügt, um den Transportstrom aus dem Conditional Access Module 38 zu empfangen und dann über einen dritten isochronen Kanal entweder als normale serielle IEEE-Bus-Übertragung oder als Common-Interface-Transportstrom weiterzuleiten. Diese Ressourcen werden in der Tat benutzt, um reine Ströme zu dem digitalen Videorekorder 32 zu führen, wenn das Conditional Access Module 38 nicht benötigt wird. Dieser Vorschlag würde es ermöglichen, daß anstelle des ganzen Transportstroms nur der interessierende Programmstrom zu dem digitalen Videorekorder 32 gesendet wird.
Ein zweiter Vorschlag besteht darin, zwei Transportstromverbindungen zu benutzen, nämlich einen von dem Host 30 zu dem Modul 38 und den anderen von dem Modul 38 zu dem digitalen Videorekorder 32.
Diese Verbindungen könnten ähnlich eingerichtet und konfiguriert werden, wie dies oben beschrieben wurde, wobei jedoch der zweite isochrone Kanal zwischen dem Modul 38 und dem digitalen Videorekorder 32 eingerichtet wird. Dies hätte den Vorteil, daß die Notwendigkeit umgangen wäre, daß der Host-Empfänger selbst das Programm zu dem digitalen Videorekorder 32 zurückschaltet. Dies würde wiederum die Benutzung der Ressourcen in dem Host-Empfänger 30 für andere Anwendungen oder eine preiswertere Implementierung des Hosts ermöglichen.
Natürlich würde der digitale Videorekorder 32 in diesem Fall den ganzen Transportstrom empfangen, er könnte jedoch so ausgebildet sein, daß er unter dem Einfluß des Hosts 30 oder in einem Stand-Alone-Modus aus den Strömen alles herausfiltert, was nicht interessiert.
Die Anordnung von 9 kann auch folgendermaßen konfiguriert werden.
Statt daß der Host-Empfänger 30 einen benötigten Programmstrom aus dem digitalen Videorekorder 32 zurückschaltet, können überlagerte Verbindungen benutzt werden. Nach der Einrichtung isochroner Verbindungen zwischen dem Host-Empfänger 30 und dem Conditional Access Module 38 überlagert der Host-Empfänger 30 dann eine Verbindung von dem Conditional Access Module 38 zu dem digitalen Videorekorder 32. Wie oben erwähnt wurde, benutzt das Überlagern einer Verbindung den gleichen isochronen Kanal, richtet diesen jedoch an ein zusätzliches Ziel, im vorliegenden Fall an den digitalen Videorekorder 32.
Diese Konfiguration hat den Vorteil, daß die Schaltressourcen des Host-Empfängers 30 nicht benutzt werden, also keine zusätzliche Bandbreite gebraucht wird, wenn der Transportstrom nicht nur zu dem Host-Empfänger 30 sondern auch zu dem digitalen Videorekorder 32 gesendet wird.
Es sei noch einmal darauf hingewiesen, daß das zweite Ziel, im vorliegenden Fall der digitale Videorekorder 32, den ganzen Transportstrom empfängt. Dies könnte jedoch ein Vorteil sein, wenn das zweite Ziel beispielsweise eine Anzeigevorrichtung in einem anderen Raum ist. Es würde insbesondere ermöglichen, daß die Auswahl des Programmstroms unabhängig von dem Host-Empfänger 30 erfolgen kann.
Die Benutzung von Conditional Access Modules in Verbindung mit dem seriellen IEEE-Bus eröffnet die Möglichkeit zu einem weiteren Kommunikationstyp, der bisher für den seriellen IEEE-1394-Bus nicht in Betracht gezogen wurde. Statt einen entwürfelten Transportstrom zu dem Host-Empfänger 30 zurückzuführen, kann der Transportstrom beispielsweise zu einem (nicht dargestellten) zweiten Conditional Access Module zur weiteren Verarbeitung oder Entwürfelung weiterer virtueller Kanäle des Transportstroms weitergeleitet werden. Zu diesem Zweck wird vorgeschlagen, daß der Host-Empfänger 30 den isochronen Ressourcenmanager kontaktiert, um einen dritten isochronen Kanal anzufordern, das Ausgangs-Steuerregister des ersten Moduls 38 konfiguriert, um die Rückverbindung zwischen dem ersten Modul 38 und dem Host 30 zu beseitigen, und unter Verwendung des zweiten isochronen Kanals eine neue Verbindung zwischen dem ersten Modul 38 und zweiten Modulen einrichtet. Der Host 30 konfiguriert dann die Eingangssteckerregister des zweiten Moduls, um einen Transportstrom auf dem zweiten isochronen Kanal zu empfangen, und konfiguriert das Ausgangsstecker-Steuerregister des zweiten Moduls, um unter Verwendung des dritten isochronen Kanals eine Verbindung zwischen dem zweiten Modul und dem Host 30 einzurichten. Er konfiguriert dann sein eigenes Eingangsstecker-Steuerregister, um den Transportstrom auf dem dritten isochronen Kanal zu empfangen.
Somit steht es dem Host frei, ob alle verfügbaren Module benutzt werden oder eine Auswahl von Modulen.
Entsprechend der PC-Karten-Implementierung des Conditional Access Module wird der volle Transportstrom, so wie er von dem Host-Empfänger empfangen wird, zu dem Conditional Access Module weitergeleitet. Durch das Plazieren des Transportstroms in dieser Schicht wird das Interface vereinfacht, da der Host-Empfänger keine Kenntnis über die Funktion des Conditional Access Module benötigt. Insbesondere kann das Conditional Access Module private Ströme empfangen und benutzen, von denen der Host-Empfänger keine Kenntnis hat oder die er nicht versteht. Diese Ströme können eine Entwürfelungsinformation, eine Abonnementsinformation usw. enthalten.
Das DVB-Common-Interface definiert, daß der Transportstrom eine Bitrate von wenigstens 58 Mbit/s haben soll. Deshalb erfordert das Befördern eines Transportstroms zu und von einem Conditional Access Module über den seriellen IEEE-1394-Bus eine Bandbreite von mindestens 116 Mbit/s. Darüber hinaus erfordert jedes zusätzliche Modul wenigstens weitere 58 Mbit/s an Bandbreite. Der serielle IEEE-1394-Bus hat verschiedene Standard-Bandbreiten. Wie aus dem oben Gesagten erkennbar ist, wäre der serielle Bus mit 100 Mbit/s jedoch ausgeschlossen, und der serielle Bus mit 400 Mbit/s wäre schnell aufgefüllt, wenn Conditional Access Modules benutzt werden.
Entsprechend den Standards für den seriellen IEEE-1394-Bus können 63 Geräte an einem einzigen Bus benutzt werden. Mit Conditional Access Modules jedoch, die derart große Bandbreiten benötigen, gibt es jedoch eine relativ niedrige Grenze für die Zahl der unabhängigen Module, die an dem Bus benutzt werden können.
Bei der Übertragung des vollen Transportstroms über das Netzwerk wird die Bandbreite sehr ineffizient genutzt, da irgendein Conditional Access Module üblicherweise nur ein oder zwei virtuelle Kanäle des Transportsstroms entwürfelt. Das Conditional Access Module kann auch andere Datenströme in dem Transportstrom benötigen, die jedoch im Vergleich zu den Programmströmen, die Video- und Audioinforationen enthalten, im allgemeinen relativ kleine Bitraten haben. Es ist deshalb wahrscheinlich, daß eine große Informationsmenge über das Netz übertragen wird, wobei nur sehr wenig davon in dem Conditional Access Module verarbeitet wird. Dies führt zu einer Restriktion der Anwendungen des Conditional Access Module und weiterer Geräte, die den seriellen IEEE-1394-Bus benutzen.
Eine Lösung für dieses Problem bestände darin, daß der Empfänger 30 nur solche Programmströme aussendet, die verarbeitet werden sollen. Da im allgemeinen nur ein oder zwei Programmströme gleichzeitig benutzt werden, würde dies die erforderliche Bitrate dramatisch reduzieren, und da der Transportstrom ein Strom von Paketen ist, können Pakete unabhängig von den Paketen anderer Ströme herausgefiltert werden, so daß ein Transportstrom zurückbleibt, der noch mit dem DVB-Common-Interface kompatibel ist.
Ein Conditional Access Module benötigt üblicherweise jedoch zusätzliche Ströme, die Berechtigungs- und Verschlüsselungsinformationen enthalten. Falls der Host-Empfänger diese Ströme nicht identifizieren kann, ist er nicht in der Lage, zu entscheiden, welche Ströme an die einzelnen Conditional Access Module gesendet werden sollen. Selbst wenn diese Ströme identifiziert werden können, kann es so viele verschiedene Informationsströme geben, daß die Zahl jenseits der Möglichkeiten des Host-Empfängers zum Ausfiltern und Senden liegt.
Falls diese zusätzlichen Ströme nicht zu dem Conditional Access Module gesendet werden, läßt sich natürlich keine korrekte Funktion des Moduls erreichen.
Ein Transportstrom enthält üblicherweise eine Tabelle oder Karte, z.B. eine MPEG-programmspezifische Information (PSI), die die verschiedenen vorhandenen Programmströme anzeigt, sowie weitere Identifizierungskarten. Da in der Tabelle jedoch nicht notwendigerweise alle diese Daten in dem Transportstrom identifiziert sind, kann es sein, daß ein Host-Empfänger nicht in der Lage ist, das Vorhandensein bestimmter Daten zu identifizieren.
Es wäre für ein Conditional Access Module möglich, dem Host-Empfänger zu signalisieren, welche Ströme es benötigt. Dies würde jedoch eine Erweiterung oder Modifizierung der Funktionalität der höheren Schicht der Common-Interface-Standards erfordern, und dies sollte nach Möglichkeit vermieden werden.
11(a) zeigt schematisch zeitmultiplexverschachtelte Datenströme zusammen mit einer zugehörigen Tabelle.
11(b) zeigt schematisch die Tabelle von 11(a).
Aus der Tabelle ist erkennbar, daß ein Gerät den Inhalt zugehöriger Datenströme bestimmen kann, z.B., daß der Datenstrom 1 sich auf einen Programmkanal D bezieht. Wie dargestellt ist, ist es jedoch nicht notwendig, daß alle Datenströme in der Tabelle identifiziert werden.
Es wird hier vorgeschlagen, daß der Host-Empfänger die Programmströme identifizieren sollte, von denen bekannt ist, daß sie nicht benötigt werden, statt die Programmströme zu identifizieren, die benötigt werden. Auf diese Weise kann der Host-Empfänger alle diejenigen Programmströme sicher herausfiltern, die nicht benötigt werden, während sichergestellt ist, daß andere Datenströme, die von dem Conditional Access Module benötigt werden, in dem Datenstrom, der zu dem Conditional Access Module gesendet wird, noch vorhanden sind.
Wenn in dem Beispiel von 11 der Kanal B von dem Conditional Access Module entwürfelt werden soll, filtert der Host-Receiver die Ströme 1, 2 und 6 heraus, für die er aus der Tabelle entscheiden kann, daß sie sich auf Rundfunkkanäle A, C und D beziehen. Falls es in den Strömen 3 und 5 zusätzliche Informationen gibt, die von dem Conditional Access Module benötigt werden, werden diese dem Conditional Access Module zugeführt.
Im Falle von MPEG-Strömen werden nur solche Programmströme entfernt, die der Host-Empfänger aus den MPEG-programmspezifischen Informationsdaten (PSI-Daten) identifizieren kann. Diese PSI-Daten sind in der MPEG-2-Systemspezifikation (ISO/IEC 13818-1 Generic Coding of Moving Picture and Associated Audio Systems) spezifiziert und in einem MPEG-Transportstrom immer vorhanden und können deshalb benutzt werden, um die vorhandenen Programmströme zu identifizierten. Durch das Ent fernen von bekannten Programmströmen bleiben private Daten, von denen der Host-Empfänger keine Kenntnis haben kann, in dem Transportstrom erhalten, der über das Common Interface auf dem seriellen IEEE-1394-Bus gesendet wird.
Da der überwiegende Teil des Transportsstroms aus Videoprogrammströmen besteht, wird die von dem Common Interface auf dem IEEE-1394-Netzwerk benötigte Bandbreite durch das Entfernen von unerwünschten Videoprogrammströmen signifikant reduziert.

Claims

Digitaler Multimedia-Empfänger (30) für die Benutzung mit einem Modul für bedingten Zugriff [Conditional Access Module] (38) unter Verwendung einer allgemeinen Schnittstelle [Common Interface], mit einem Ausgang für einen seriellen IEEE-1394-Bus, um auf dem Bus einen Transportstrom zu einem Conditional Access Module (38) zu senden, mit einem Leser zum Lesen der Inhalte eines Transportstroms und zum Identifizieren der Daten, die für die Verarbeitung durch ein Conditional Access Module (38) nicht benötigt werden, mit einem Stripper zum Herausfiltern wenigstens einiger der identifizierten, nicht benötigten Daten aus dem Transportstrom, mit einem Kodierer (40) zum Erzeugen von geeigneten AV/C-CTS-Befehlen mit Headern, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Common Interfaces entsprechen, und mit einem Sender, um durch den Ausgang und über einen seriellen IEEE-1394-Bus die von dem Kodierer (40) erzeugten AV/C-CTS-Befehle und alle übrigen Daten des Transportstroms zu senden, die nicht herausgefiltert wurden, wobei der Empfänger (30) ausgebildet ist, um einen von dem Conditional Access Module (38) über den seriellen IEEE-1394-Bus zurückgeführten verarbeiteten Transportstrom zusammen mit AV/C-CTS-Befehlen mit Headern zu empfangen, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Common Interfaces entsprechen, wobei der Empfänger (30) ferner einen Dekodierer (42) aufweist, um aus den empfangenen AV/C-CTS-Befehlen passende Common-Interface-Objekte zu erzeugen.
Digitaler Multimedia-Empfänger nach Anspruch 1, bei dem der Empfänger ein digitaler Videoempfänger (30) für die Behandlung zumindest von Videodaten ist.
Netzwerk von digitalen Multimediageräten, die über einen seriellen IEEE-1394-Bus miteinander verbunden sind, wobei das Netzwerk aufweist: einen Empfänger (30) zum Senden eines Transportstroms über den seriellen IEEE-1394-Bus unter Verwendung eines Common Interface und ein Conditional Access Module (38) zum Empfangen eines Transportstroms über den seriellen IEEE-1394-Bus unter Verwendung des Common Interface, wobei der Empfänger (30) aufweist: einen Leser zum Lesen der Inhalte eines Transportstroms und zum Identifizieren der Daten, die für die Verarbeitung durch das Conditional Access Module (38) nicht benötigt werden, einen Stripper zum Herausfiltern wenigstens einiger der identifizierten, nicht benötigten Daten aus dem Transportstrom, einen Kodierer (40) zum Erzeugen von geeigneten AV/C-CTS-Befehlen mit Headern, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Common Interfaces entsprechen, und einen Sender, um durch den Ausgang und über einen seriellen IEEE-1394-Bus die von dem Kodierer (40) erzeugten AV/C-CTS-Befehle und alle übrigen Daten des Transportstroms zu senden, die nicht herausgefiltert wurden, wobei das Conditional Access Module (38) einen verarbeiteten Transportstrom zusammen mit AV/C-CTS-Befehlen mit Headern zurückführt, die geeignete AV/C-CTS-Opcodes enthalten, die Transportobjekten des Common Interfaces entsprechen, wobei der Empfänger (30) ausgebildet ist, um den verarbeiteten Transportstrom und AV/C-CTS-Befehle zu empfangen und ferner einen Dekodierer (42) aufweist, um aus den empfangenen AV/C-CTS-Befehlen passende Common-Interface-Objekte zu erzeugen.
Netzwerk nach Anspruch 3, bei dem das erste Gerät (30) und das zweite Gerät (38) digitale Videogeräte für die Behandlung zumindest von Videodaten sind.
Empfänger nach Anspruch 2 oder Netzwerk nach Anspruch 4, bei denen der Transportstrom ein MPEG-2-Transportstrom ist.
Empfänger oder Netzwerk nach einem der vorhergehenden Ansprüche, bei denen der Transportstrom in isochronen Kanälen im IEC-1883-Format gesendet wird.
Empfänger oder Netzwerk nach einem der vorhergehenden Ansprüche, bei denen die nicht benötigten Daten unter Bezugnahme auf programmspezifische Informationen in dem Transportstrom identifiziert werden.