DE60008251T2

DE60008251T2 - System und verfahren zur vereinfachten übertragung von ip-daten über ein mpeg netzwerk

Info

Publication number: DE60008251T2
Application number: DE60008251T
Authority: DE
Inventors: Reem Safadi; Robert Mack; Arthur Jost
Original assignee: Arris Technology Inc; General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 1999-08-20
Filing date: 2000-08-21
Publication date: 2004-12-09
Anticipated expiration: 2020-08-22
Also published as: CN1408180A; DE60008251D1; AU6791100A; EP1210825A1; EP1210825B1; CA2382408A1; BR0013472A; WO2001015455A1

Description

BEREICH DER ERFINDUNG
Die vorliegende Erfindung bezieht sich im Allgemeinen auf ein System und ein Verfahren zum Übertragen digitaler Informationen und vor allem zum Erleichtern der Übertragung von IP-Daten über digitale MPEG-Netzwerke.
HINTERGRUND DER ERFINDUNG
Die Nachrichtenübermittlung in der modernen Gesellschaft hat sich durch das Aufkommen derart weit verbreiteter Datennetze wie etwa öffentliche Fernsprechsysteme, das Internet (einschließlich des World Wide Web) und Kabel- und Satellitenfernsehsysteme erheblich verbessert. Ein wichtiges Protokoll zum Transferieren von Informationen, beispielsweise durch das Internet, ist das gut bekannte Internet-Protokoll (IP). Für Kabel- und Satellitensysteme ist ein wichtiger Mechanismus jedoch der MPEG-Transportstrom (d. h. MPEG-2). Zur Erleichterung der Interoperabilität wurden Normen entwickelt, die festlegen, wie IP-Datagramme in MPEG-2-Transportpakete umgesetzt werden, wie ersichtlich unter Bezug auf die ATSC-Datenrundfunk-Spezifikation, ATSC T3/S13 Dok. 010 DVS-161, R3ev 1,0 Entwurf, 31. März 1999 und die digitale Fernsehtechnik (DVB): DVB-Spezifikation für Datenrundfunk, EN 301 192 V. 1.2.1 (1999-01) (abrufbar bei http://www.etsi.org). Gemäß DVB-Norm wird ein wie in 1 gezeigtes komplettes IP-Datagramm 10 in eine Vielzahl von IP-Datagramm-Fragmente 12₁ , ..., 12_n fragmentiert, wenn es länger als 1008 Bytes ist. Dann wird jedes IP-Datagramm-Fragment 12₁ , ...,12_n in einen DVB-MPE-Datagrammabschnitt 14₁ , ..., 14_n (einen "DSM-CC"-Abschnitt gemäß der ATSC-Norm) verkapselt. Jeder DVB-MPE-Datagrammabschnitt wird dann selbst zerlegt und in einem Nutzlastabschnitt eines MPEG-2-Transportpakets 16₁ , ..., 16_n , 16_i+1 , ..., 16_n getragen, wobei dieses Paket auf 188 Bytes beschränkt ist.
Obgleich ziemlich kompliziert, wie in 1 gezeigt, ist die Interoperabilität zwischen dem IP und der MPEG sowohl möglich als auch wünschenswert, da sie Kabel- und Satellitensystembetreibern eine Möglichkeit bietet, Teilnehmern verbesserte Dienste anzubieten. Als Beispiel hat das Advanced Television Enhancement Forum (ATVEF), eine Cross-Industry-Gruppe, eine Norm zur Bereitstellung verbesserter Fernseh-Programmgestaltung, die Internettechnologien verwendet, festgelegt, wie unter Bezug auf die Enhanced Content Specification, Advanced Television Enhancement Forum (ATVEF), Version 1.1r26 (nachfolgend als "ATVEF-Dokument" bezeichnet) ersichtlich. Das ATVEF-Dokument offenbart eine ATVEF-Bindung, die eine Definition davon, wie ATVEF auf einem gegebenen Netz läuft, ist (d. h. die ATVEF-Bindung bietet den "Klebstoff" zwischen der ATVEF-Spezifikation und einer gegebenen Netzspezifikation). Das ATVEF-Dokument offenbart ferner, dass das Binden an das IP die Referenzbindung ist, da das IP auf sozusagen jedem beliebigen Netz läuft.
Außerdem wird in Betracht gezogen, die ATVEF-Daten unter Verwendung eines wie im RFC 1112 beschriebenen IP-Multicast-Mechanismus zu verteilen. Während also das IP auf MPEG-Netzen gemäß den oben genannten ATSC- oder DVB-Normen getragen werden kann, beispielsweise zur Implementierung des ATVEF, bestehen eine Vielzahl von Mängeln.
Ein solcher Mangel ist Leistungsschwäche. Durch das Erleichtern der IP-Protokoll-Beförderung innerhalb des MPEG-Transportstroms gemäß den oben genannten Normen wird die der Umsetzung von IP-Datagrammen in MPEG-2-Transportpakete zugehörige Verarbeitung nicht optimiert. Genauer gesagt soll eine Set-Top-Box (STB) oder dergleichen an dem empfangenden Ende herkömmlich eine Vielzahl von MPEG-Transportpaketen empfangen, um die DVB-MPE-Abschnitte wieder zusammenzufügen und das Ergebnis syntaktisch analysieren, um das Ziel zu bestimmen, oder noch schlimmer, um die fragmentierten IP-Datagramme wieder zusammenzusetzen, um das Ziel von dem Adressfeld zu bestimmen. Die STB soll dann bestimmen, ob das festgehaltene IP-Datagramm zur weiteren Verarbeitung auf höhere Schichten weitergeleitet werden soll. Aufgrund der kontinuierlichen Strömung von IP-Datagrammen, beispielsweise in einem IP-Multicast-Szenario, kann der Vorgang der syntaktischen Analyse und der Wiederzusammensetzung eine erhebliche Menge an Verarbeitungsbetriebsmitteln (z. B. CPU-Zyklen, Speicher etc.) verbrauchen. Dieser Verbrauch reduziert die Gesamtleistung der STB, gleichgültig, ob eine auf der STB laufende Anwendung eine Verbindung hergestellt hat (d. h. eine Notwendigkeit für die IP-Datagramme geschaffen hat) oder nicht.
Ein Ansatz auf dem Fachgebiet, offenbart in M. Dolan, A Discussion of ATVEF and Its Possible Bindings onto the ATSC Transport, Version 1.0, Entwurf 3, 16. Februar 1999, zur Behandlung der Bindung von IP an MPEG, schlägt die Verwendung einer MPEG-System-Datenkonstruktion (d. h. als Tabelle des virtuellen Kanals bezeichnet) vor, damit dem empfangenden Terminal (z. B. STB) explizit jede ATVEF-Datenpaketkennung (PID), eine Datenkomponente eines MPEG-Dienstes, angegeben wird. Dieser Ansatz bringt jedoch unerwünschte Kopplung und andere Leistungsschwächen mit sich. Beispielsweise beschränkt dieser Ansatz die IP-Datagramme auf ein einzelnes System, das heißt, die VCT (Tabelle des virtuellen Kanals) kann sich nicht leicht über mehrere Systeme erstrecken, da VCTs systemspezifisch (homogen, d. h. mehrere Kabelsysteme/Kopfstellen, oder heterogen, d. h. über Satellit und Kabel) sind.
Folglich besteht der Bedarf, ein verbessertes Verfahren und System zur Übertragung von IP-Daten an einen Teilnehmer bereitzustellen, das einen oder mehrere der oben angeführten Mängel auf ein Mindestmaß herabsetzt oder behebt.
WO 97/20413 offenbart ein Paketvermittlungssystem, das beispielsweise das Übertragen von TCP/IP-Verkehr über einen MPEG-Datenstrom ermöglicht. Der Empfänger für den TCP/IP-Verkehr wird einer temporären IP-Adresse zugeteilt und ein Teil dieser Adresse wird als Paketkennung (PID) für die MPEG-Transportpakete verwendet.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Vorteil der vorliegenden Erfindung ist Leistungsfähigkeit. Hat eine auf einer Set-Top-Box laufende Anwendung keine Verbindung zum Empfangen von IP-Daten hergestellt, dann müssen die IP-Datagramme nicht weitergeleitet werden und, was wichtiger ist, müssen keine Wiederzusammensetzung und syntaktische Analyse, auf welche im Hintergrund Bezug genommen wurde, vorgenommen werden, um die IP-Datagramme zu rekonstruieren. Ist jedoch eine Verbindung hergestellt worden, wird ein Deskriptor (in einer PMT) an die Set-Top-Box, die einen Datenstrom einer MAC-Zieladresse zuordnet, gesendet. Die Erfindung gestattet ein früheres Filtern zur Bestimmung, ob gewisse MPEG-Datenströme die erwünschten IP-Daten enthalten. Die Leistungsschwäche und unnötige Verwendung von Betriebsmitteln herkömmlicher Ansätze werden durch die vorliegende Erfindung umgangen.
Es ist ein Verfahren zum Erleichtern der Lieferung von Inhalt in einem Inhaltsdatenstrom an ein Terminal bereitgestellt. Das Verfahren umfasst drei Hauptschritte. Der erste Schritt schließt das Erzeugen eines Deskriptors für den Inhaltsdatenstrom, der eine Zieladresse umfasst, ein. Der nächste Schritt schließt das Übertragen des Deskriptors auf das Terminal in einer PMT (Program Map Table) ein. Der dritte Schritt schließt das Lokalisieren des Inhaltsdatenstroms an dem Terminal unter Verwendung der Zieladresse in dem Deskriptor ein.
In einer bevorzugten Ausführungsform beinhaltet der Inhalt Internet-Protokoll-Datagramme (IP-Datagramme), bei denen der Inhaltsdatenstrom in einem MPEG-2-Transportstrom (Moving Pictures Expert Group-2 Transportstrom) auf das Terminal übertragen wird. In einer weiteren bevorzugteren Ausführungsform ist der Inhalt mit der ATVEF-Spezifikation (Spezifikation des Advanced Television Enhancement Forum) zur verbesserten Fernseh-Programmgestaltung konform. In noch einer weiteren bevorzugten Ausführungsform sind die ATVEF-Daten so konfiguriert, dass sie einen audiovisuellen Dienst verbessern, der dem Terminal über den MPEG-Transportstrom ebenfalls bereitgestellt ist. Somit gestattet die Erfindung die Lieferung verbesserter audiovisueller Dienste.
Der Deskriptor gestattet ein früheres Filtern, ohne dass das Terminal, das ein digitales Verbraucherterminal (DCT = digital consumer terminal) sein kann, eine Vielzahl von DVB-MPE- oder DSM-CC-Abschnitten empfangen und untersuchen, oder schlimmer, diese Abschnitte syntaktisch analysieren muss, um das IP-Datagramm wiederherzustellen. Dies wäre nötig, um das Zieladressenfeld innerhalb des Datagramms zu untersuchen, um zu bestimmen, ob das wiederhergestellte Datagramm auf höhere Schichten weitergeleitet werden soll (d. h. wenn eine Anwendung schon eine Verbindung mit ähnlichen Attributwerten, z. B. einer IP-Multicast-Adresse, hergestellt hat). Die Erfindung minimiert die Belastung der Terminal-Betriebsmittel und gestattet eine effiziente Zuordnung mehrerer Datenströme, die mit dem audivisuellen Dienst einhergehen sollen. Die Erfindung gestattet eine eigenständige Dienstdefinition (d. h. im Deskriptor enthalten), die somit zur Verwendung über mehrere Systeme angepasst werden kann, da die PMT im Gegensatz zur Tabelle des virtuellen Kanals (VCT) nicht systemspezifisch ist.
Eine Vorrichtung zum Erzeugen des Deskriptors und ein Terminal, das konfiguriert ist, um den Deskriptor zu erkennen und ihn zu verwenden, liegen ebenfalls vor.
Weitere Ziele, Merkmale und Vorteile der vorliegenden Erfindung werden dem Fachmann auf dem Gebiet durch die nachfolgende detaillierte Beschreibung und die beigelegten Zeichnungen, die die Merkmale dieser Erfindung beispielhaft, jedoch nicht einschränkend darstellen, deutlich.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine Darstellung eines Umsetzungsschemas des Stands der Technik zur Umsetzung von IP-Datagrammen in MPEG-Transportpakete;
2 ist eine Blockschaltbildansicht eines Systems zur lokalen IP-Dateneinfügung (Kopfstellen-IP-Dateneinfügung) gemäß der vorliegenden Erfindung;
3 ist eine vereinfachte Blockschaltbildansicht von Protokollstapeln, die verschiedenen Komponenten zur Unterstützung der vorliegenden Erfindung zugehören;
4 ist eine vereinfachte Blockschaltbildansicht einer PMT (Program Map Table), die einen erfindungsgemäßen Deskriptor enthält; und
5 ist ein vereinfachtes Ablaufdiagramm der Verarbeitung, die in einer erfindungsgemäßen Set-Top-Box (Terminal) geschieht.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Nun Bezug nehmend auf die Zeichnungen, in denen gleiche Verweiszahlen verwendet werden, um identische Komponenten in den unterschiedlichen Ansichten zu kennzeichnen, ist 2 ein Blockschaltbild eines erfindungsgemäßen Systems 20. Das System 20 ist konfiguriert, um einem Teilnehmer 22 den Zugriff auf Internet-Protokoll-Daten (IP-Daten) mittels eines Terminals 24 (in 1 als ASTB für Advanced Set-Top-Box bezeichnet) zu gestatten oder zu erleichtern. Die IP-Daten können ATVEF-Daten sein, die zur Bereitstellung verbesserter audiovisueller Dienste verwendet werden, die eventuell auf einer mit dem Terminal 24 verbundenen Anzeige 26 angezeigt sind. Das System 20 stellt die unterschiedlichen Einrichtungen dar, die bei der Einfügung von IP-Daten in MPEG-Datenströme an einer lokalen oder Kopfstellen-Stelle beteiligt sind. Bei einer (nicht gezeigten) alternativen Ausführungsform können die IP-Daten bei einem National Access System (NAS) eingefügt werden und zu einer Gesamtheit von Terminals 24 rundgesendet werden. 2 stellt ferner eine Vielfalt von IP-Datenquellen, wie etwa einen Netzwerkserver 30, einen Internet-Gateway 32 und einen Vertikalaustastlücken-zu-MPEG-Transcoder (VBI-zu-MPEG-Transcoder) 34 dar. 2 zeigt ferner einen Rundsendungs-Domain-Name-Server (DNS) 36, einen digitalen adressierbaren Controller (DAC = digital addressable controller) 38, eine Vermittlung, wie etwa eine Ethernet-Vermittlung 40, einen IP-Encapsulator 42, einen Controller 44, ein modulares Verarbeitungssystem (MPS = modular processing system) 46, eine Satellitenschüssel 48, einen Aufwärtsumsetzer 50 und eine Kabelanlage 52.
Das Terminal 24 kann eine beliebige erweiterte Set-Top-Box (ASTB advanced set-top box), ein Set-Top-Terminal, ein Verbraucherterminal, wie etwa ein digitales Verbraucherterminal (DCT = digital consumer terminal), ein Kabelfernseh-Unterhaltungsterminal, wie etwa ein digitales Verbraucherterminal (DCT), ein Digitalfernsehgerät oder einen Host mit POD-Leistungsfähigkeit (POD = point of deployment), einschließlich eines entsprechend konfigurierten Personal-Computers (PC), beinhalten.
Das erfindungsgemäße Terminal 24 kann eine Plattform zum Laufenlassen von Third-Party-Anwendungen bereitstellen, die konfiguriert sein können, um Verbindungen zu IP-Datenquellen, die einem gegenwärtig abgestimmten Dienst zugeordnet sind, oder auf einem vollständig anderen Transportstrom (TS) verfügbar sind, anzufordern. Das Terminal 24 ist konfiguriert, um den Datenstrom (d. h. eine bestimmte Paketkennung-PID), der die angeforderten IP-Daten trägt, unter Verwendung eines erfinderischen Deskriptors zu lokalisieren und anschließend die von den MPEG-Transportpaketen genommenen IP-Datagramm-Fragmente wieder zusammenzusetzen. Die IP-Daten werden dann extrahiert und an IP-Schicht-Software, die ebenfalls auf dem Terminal 24 läuft, zur weiteren Verarbeitung weitergeleitet. Das Terminal 24 kann anderweitig herkömmliche, auf dem Stand der Technik bekannte Komponenten beinhalten, die gemäß der hierin beschriebenen Erfindung modifiziert wurden. Der Netzwerkserver 30, der Internet-Gateway 32 und der Transcoder 34 können herkömmliche, dem durchschnittlichen Fachmann auf dem Gebiet bekannte Komponenten beinhalten.
Der digital adressierbare Controller (DAC) 38 gewährt den bereits eingesetzten Terminals 24 unter anderen Funktionen die lokale Steuerung und Autorisierung zur Funktionalität. Der DAC 38 kann eine im Handel erhältliche Einrichtung, wie etwa das Modell DAC 6000 Digital Adressable Controller, der bei General Instrument Corporation, Horsham Pennsylvania, USA erhältlich ist, beinhalten.
Der IP-Encapsulator 42 (und sein zugehöriger Controller 44) kann auch im Handel erhältliche, dem durchschnittlichen Fachmann auf dem Gebiet bekannte Komponenten beinhalten.
Das MPS 46 ist als Verarbeitungsplattform für eingehende Digitaldatenströme konfiguriert. Das MPS 46 kann digitale Verarbeitungsfunktionen wie Verschlüsselung/Entschlüsselung, Strommultiplexing, Ratenkonvertierung, Meldungseinfügung- und -extrahierung durchführen und kann mit einer Vielfalt von Eingangs- und Ausgangsoptionen, wie etwa DS3 E/A, 64/256 QAM (Ausgang) bei ZF, einen MPEG-2-Transportstrom (TS) tragend, und dergleichen, konfiguriert werden. Das MPS 46 kann eine im Handel erhältliche Einrichtung, wie etwa das Modell MPS-Modular Processing System, das bei General Instrument Corporation, Horsham, Pennsylvania, USA erhältlich ist, beinhalten.
Der Aufwärtsumsetzer 50 ist so konfiguriert, dass er (i) ein 64 oder 256 QAM-Signal bei ZF von dem MPS 46 empfängt und (ii) das ZF-Signal zu HF zur Verteilung auf einem ausgewählten physikalischen Kanal auf der Anlage 52, wie bekannt, aufwärts umsetzt. Der Aufwärtsumsetzer 50 kann eine im Handel erhältliche Komponente, wie etwa das Modell C6U von General Instrument Corporation, Horsham Pennsylvania, USA beinhalten.
Die vorliegende Erfindung schließt das Erzeugen eines Deskriptors, der mit einer PMT (Program Map Table) auf der Kabelanlage, die dazu bestimmt ist, von einem oder mehreren der Terminals 24 empfangen und verarbeitet zu werden, übertragen wird, ein. Entwickler von Third-Party-Anwendungen können Einweg-IP-Datagramme (z. B. IP-Multicast enthaltende ATVEF-Daten) auf deren Anwendungen, die innerhalb des Terminals 24 laufen, übertragen werden. Ohne den oben beschriebenen Deskriptor muss das Terminal 24 wesentliche Verarbeitung betreiben, um Datenströme, die nach den erwünschten IP-Daten suchen, syntaktisch zu analysieren, oder schlimmer, muss es die fragmentierten IP-Datagramme wieder zusammensetzen, um die Zieladresse wiederzugewinnen und zu verarbeiten. Der erfindungsgemäße Deskriptor erleichtert eine frühere Entscheidungsfindung und ein schnelleres Verarbeiten im Terminal 24.
Immer noch Bezug nehmend auf 2 sind dem IP-Encapsulator 42 überein Netz, wie beispielsweise einem Internet-Netz, IP-Datagramme von verschiedenen IP-Datenquellen bereitgestellt. Diese IP-Datenquellen können einen lokalen Netzwerkserver 30, einen Transcoder 34, der einen oder mehrere analoge Rundfunke als Eingaben aufweist, die die in der Vertikalaustastlücke enthaltenen IP-Daten bereitstellen, oder einen Gateway 32 über seine Verbindungen zum Internet umfassen. Diese Quellen übertragen ihrerseits die IP-Datagramme über die Vermittlung 40 an den IP-Encapsulator 42. Während er als Ethernet gezeigt ist, kann der Pfad von der IP-Datenquelle zum Encapsulator 42 andere Übertragungstechnologien beinhalten. Der IP-Encapsulator 42 extrahiert IP-Daten von Ethernet-Frames und verkapselt sie, in einer Ausführungsform, in den DVB-MPE-Datagrammabschnitten 14₁ , ..., 14_n , wie beispielhaft in 1 gezeigt. Die unten stehende Tabelle 1 zeigt eine beispielhafte Syntax für die DVB-MPE-Abschnitte. Die DVB-MPE-Norm ist eine öffentliche Norm und wird in Verbindung mit Tabelle 1 nur insofern beschrieben werden, als sie relevant zur vorliegenden Erfindung ist. Der IP-Encapsulator 42 segmentiert danach die DVB-MPE-Datagramm-Abschnitte in MPEG-Transportpakete 16_l und überträgt diese auf das modulate Verarbeitungssystem 46. Das MSP 46 empfängt die MPEG-Transportpakete von dem IP-Encapsulator 42 und kann die empfangenen PID-Ströme mit MPEG Video-/Audiodiensten, die von einer Satelliten-Abwärtsstrecke 48 oder einem Videoserver oder dergleichen empfangen werden, multiplexen.
In einer alternativen Ausführungsform kann der Netzwerkserver 30 die DVB-MPE-Verkapselung der IP-Datagramme durchführen und das Ergebnis direkt dem MPS 46 über eine DVB-System-Parallel-Schnittstelle (SPI) oder asynchrone serielle Schnittstelle (ASI) bereitstellen.
Tabelle 1. DVB-MPE-Datagrammabschnitt
Der table_id Parameter ist ein 8-Bit-Feld, das auf "0x3E" eingestellt ist, was auf DSM-CC-Abschnitte mit privaten Daten gemäß ISO/IEC 13818-6 [2] hinweist. Die deviceld_1 bis deviceld_6 Parameter definieren eine MAC_address_[1..6], d. h. dies ist ein 48-Bit-Feld, das die MAC-Adresse des Ziels enthält. Die MAC-Adresse ist somit in 6 Feldern von jeweils 8 Bits, mit deviceld_1 bis zu deviceld_6 gekennzeichnet, fragmentiert. Das deviceld_1 Feld enthält vorzugsweise das höchstwertige Byte der MAC-Adresse, während deviceld_6 das niedrigstwertige Byte enthält. RFC 1112 spezifiziert die Umsetzung von Multicast-IP-Adressen in Ethernet-MAC-Adressen. Die MAC-Adressfelder sind in einer bevorzugten Ausführungsform in Übereinstimmung mit dieser Umsetzung kodiert. Die Umsetzung ist unkompliziert und wie folgt. Die IP-Multicast-Adresse wird in die entsprechende Hardware-Multicast-Adresse umgesetzt, indem die niedrigstwertigen 23 Bits der IP-Multicast-Adresse in die wertniedrigsten 23 Bits der Multicast-MAC-Adresse 01.00.5E.00.00.00 (hexadezimal) platziert werden.
Außerdem ist der section_number Parameter ein 8-Bit-Feld. Wird das IP-Datagramm in mehreren Abschnitten getragen, dann gibt dieses Feld die Position des Abschnitts innerhalb des Fragmentierungsvorgangs an. Andernfalls ist es Null. Es versteht sich, dass in einer Ausführungsform die IP-Datagramm-Fragmente der Datenverbindungsschicht geliefert werden müssen, damit sie nicht größer als die Größe der größten Übertragungseinheit (MTU) von 1008 Bytes sind. Dadurch ist es nicht nötig, die IP-Datagramm-Fragmente weiter über die DVB-MPE-Datagrammabschnitte hinweg zu fragmentieren. Der last_section_number Parameter ist ein 8-Bit-Feld, das die Nummer des letzten Abschnitts angibt, der verwendet wird, um das Datagramm zu tragen, d. h. die Nummer des letzten Abschnitts des Fragmentierungsvorgangs.
Immer noch Bezug nehmend auf 2 wird eine Beschreibung des Betriebs der Erfindung auf dem Netzwerk (im Gegensatz zum Terminal) dargelegt. Der DAC 38 sendet Befehle an das MPS 46 (z. B. load_mps Befehle), um Dienst-Remultiplexing, Meldungseinfügung und Extrahierung programmspezifischer Informationen (PSI) und Dienstverschlüsselung zu steuern. Des Weiteren sendet der DAC 38 andere Befehle (z. B. Include Component Befehle) an das MPS 46, welche die elementaren Eingabe-PID-Ströme, die in einen definierten Ausgabedienst eingeschlossen werden sollen, identifizieren. Diese Fähigkeit des MPS 46 wird verwendet werden, um die zutreffenden PID-Ströme, welche die IP-Daten tragen, in einen bestimmten Dienstmultiplex umzusetzen. Erfindungsgemäß werden die von dem DAC 38 gesendeten Befehle (z. B. Include Component) auch verwendet werden, um dem MPS 46 (i) einen stream_type und (ii) den oben beschriebenen Deskriptor, der dem Eingabe-PID-Strom zugehört, welcher für die Terminals 24 bestimmte IP-Datagramme trägt, bereitzustellen. Das MPS kann somit eine PMT, einschließlich des stromartigen und Adressdeskriptors auf dem MPEG-2-Transportstrom aussenden. Die in Terminal 24 auftretende Verarbeitung unter Verwendung des erfinderischen Deskriptors wird nachfolgend genauer beschrieben.
3 stellt Protokollstapel einer IP-Datenquelle, beispielsweise der Netzwerkserver 30, der IP-Encapsulator 42, das MPS 46 und das Terminal 24, für Einweg-IP-Datagramm-Rundsendungen bereit. In 3 gezeigt, bietet der IP-Encapsulator 42 einem Third-Party-Netzwerkserver 30 eine Standard-Netzschnittstelle. Der wie oben beschriebene Encapsulator 42 führt die Verkapselung empfangener IP-Datagramme in, beispielsweise, DVB-MPE-Datagrammabschnitten, wie die in 1 gezeigten Abschnitte 14₁ , ..., 14_n , durch. Die verkapselten IP-Datagramme werden dann in MPEG-Transportpakete, die zur Verteilung an die Terminals 24 mittels beispielsweise 64/256 QAM über den Aufwärtsumsetzer 50 an das MPS 46 weitergeleitet werden, segmentiert.
4 zeigt eine erfindungsgemäße PMT (Program Map Table) 54. Die PMT 54 kann, wie dem durchschnittlichen Fachmann auf dem Gebiet bekannt ist, auf einem Program-Map-Datenstrom eines MPEG-2-Transportstroms übertragen werden.
Die gemäß der Erfindung erhaltene Optimierung wird erreicht, indem die zutreffenden Informationen des IP- sowie MPEG-Protokolls kombiniert werden, um frühere Entscheidungsfindung und ein schnelleres Verarbeiten im Terminal 24 zu erleichtern. Diese Optimierung wird bewerkstelligt, indem eine neue Datenstruktur definiert wird, die in der MPEG-Nomenklatur als Deskriptor bezeichnet wird. Dem durchschnittlichen Fachmann auf dem Gebiet ist bekannt, dass bei MPEG-2 der Transport-Multiplex verschiedene Programmströme (Dienste) umfassen kann, die in einer PAT (Program Association Table) angegeben sind. Jeder Programmstrom (Dienst) kann einen oder mehrere Video-, Audio- und Daten-PES (paketierte Elementarströme) beinhalten. Die PMT (Program Map Table) weist auf die Elementarströme, die ein Programm ausmachen, hin. Die PMT 54 umfasst beispielsweise, wie in 4 gezeigt, einen PCR-Strom (d. h. einen Zeitreferenzstrom) 56,, einen ersten Videostrom 56₂ , einen ersten Audiostrom 56₃ , einen zweiten Audiostrom 56₄ und einen Datenstrom 56_k . Die PMT 54 weist auf jeden Elementarstrom hin, indem sie in der Tabelle eine jeweilige Paketkennungsnummer (PID- Nummer) bereitstellt, bei der der bestimmte Strom in dem Transportstrom als Ganzes gefunden werden kann. Beispielsweise ist in der PMT 54 angegeben, dass der Videostrom für die Programmnummer 1 auf der PID = 54 getragen wird. Des Weiteren weist jeder Eintrag in der PMT 54 einen entsprechenden elementarstromartigen Deskriptor, wie etwa die Art Deskriptor 58 für den Datenstromeintrag 56_k , auf.
Wie ferner dargestellt, umfasst jeder derartige Strom, für einen MPEG-Dienst (ein MPEG-Programm), der (das) IP-Datagramme innerhalb zwei oder mehreren Elementar-PID-Strömen von stream_type = 0x0D (DSM-CC-Abschnitten) trägt, erfindungsgemäß ferner eine PMT 54 des Adressdeskriptors 60. Das heißt, wenn eine Datenkomponente (d. h, ein Elementarstrom), die in einem gegebenen audiovisuellen Dienst zugeordnet ist, sich aus IP-Datagrammen zusammensetzt, ist der Adressdeskriptor 60, der ermöglicht, dass das Terminal 24 bestimmt, wann es syntaktisch analysieren und wiederherstellen muss (d. h. beispielsweise die IP-Datagramme aus den DSM-CC-Abschnitten wieder zusammensetzen muss) und wann es die eingehenden Daten ignorieren soll, eingeschlossen. Insbesondere wird der Adressdeskriptor 60 von dem Terminal 24 verarbeitet, um zu bestimmen, ob der Komponenten-PID-Strom die Multicast-IP-Daten trägt.
Außerdem wird der Deskriptor 60 eine oder mehrere Multicast-Medienzugriffsteuerungsadressen (Multicast-MAC-Adressen) der DVB-MPE-Datagrammabschnitte, die innerhalb eines bestimmten Komponenten-PID-Stroms getragen werden, tragen. Da MPEG-Meldungen in der Länge auf 1024 Bytes beschränkt sind, ist die maximale Anzahl von MAC-Adressen auf ungefähr 150 Einträge, je nach Anzahl anderer Deskriptoren, die in der PMT getragen werden, sowie der Anzahl identifizierter Komponenten-PIDs, beschränkt. In konstruierten Ausführungsformen sollten maximal 150 Einträge ausreichend Raum lassen, um die üblich definierten PMT-Deskriptoren (z. B. Sprache, bedingter Zugriff etc.) sowie die Pflicht-PMT-Meldungsfelder zu tragen. In einer alternativen Ausführungsform, kann dann eine Auswahl an MAC-Adressen spezifiziert werden, wenn auf einem bestimmten PID-Strom mehr als 150 MAC-Adressen getragen werden oder wenn viele Daten-PID-Ströme vorhanden sind, die jeweils sehr viele verschiedene IP-Datagramm-Ströme tragen. Der Deskriptor 60 ermöglicht, dass das Terminal 24 die Daten-PID-Ströme, welche die angeforderten IP-Daten tragen, schnell und effizient identifiziert ohne die DVB-MPE-Meldungen extrahieren oder wieder zusammensetzen zu müssen, um die Multicast-MAC-Adressen zu filtern.
Eine beispielhafte Syntax für den Deskriptor 60 ist unten in Tabelle 2, zusammen mit den damit in Beziehung stehenden Definitionen, gezeigt. Tabelle 2. Adressdeskriptor
Der descriptor_tag Parameter ist eine 8-Bit vorzeichenlose ganzzahlige Menge, welche die bestimmte Deskriptordatenstruktur definiert. Der descriptor_length Parameter ist eine 8-Bit vorzeichenlose ganzzahlige Menge, welche die Länge des Deskriptors, der unmittelbar auf das Feld folgt, definiert. Der Längenparameter umfasst alles in der Deskriptorstruktur, außer dem descriptor_tag Parameter und dem Längenbyte selbst. Der data_stream_content Parameter ist ein 8-Bit Feld der aufgezählten Art, das die Inhalte des Deskriptors identifiziert. Der multicast_mac_addr_included Deskriptor umfasst einen Satz Ziel-Multicast-MAC-Adressen. Der multicast_mac_addr_range_included Deskriptor umfasst eine Auswahl an Ziel-Multicast-MAC-Adressen, wobei die Auswahl durch die highest_mac_address und lowest_mac_address Felder spezifiziert ist. num_of_mac_addresses ist eine 8-Bit vorzeichenlose ganze Zahl, die die Anzahl in diesem Deskriptor enthaltener Multicast-MAC-Adressen angibt. Der multicast_mac_addess Parameter ist eine 48-Bit-Multicast-MAC-Gruppenadresse.
highest_mac_address ist eine 48-Bit-Multicast-Gruppen-MAC-Adresse, die die größte von dem Deskriptor getragene Adresse ist.
lowest_mac_address ist eine 48-Bit-Multicast-Gruppen-MAC-Adresse, die die kleinste von dem Deskriptor getragene Adresse ist. Weitere Variationen sind möglich, je nach den Einzelangaben eines beliebigen Kabel- und/oder Satellitenfernsehsystems.
5 zeigt ein Ablaufdiagramm, das darstellt, wie eine auf Terminal 24 ausführende Anwendung eine Verbindung herstellen kann, um IP-Daten zu empfangen. 5 zeigt ferner wie das Terminal 24, insbesondere ein Teil des Dekodierers davon, Multicast-IP-Datagramme, die von einer Anwendung angefordert wurden, lokalisiert und extrahiert, indem die zugehörige Multicast-MAC-Adresse spezifiziert wird. Der Vorgang der Anwendungsverbindung beginnt in Schritt 62.
In Schritt 64 öffnen auf dem Terminal 24 ausführende Anwendungen "Socket-"Verbindungen, um IP-Daten, typischerweise von einer Inband-IP-Datenquelle, zu erhalten. In einer alternativen Ausführungsform umfasst das Terminal 24 jedoch einen Kabelmodem-Tuner und einen zugehörigen Schaltkreis und eine Software, was ermöglicht, dass die auf dem Terminal 24 ausführenden Anwendungen IP-Daten von einer mit DOCSIS konformen IP-Datenquelle erhalten. Beispielsweise umfassen im Handel erhältliche Terminals, wie das Modell DCT 5000, erhältlich von General Instrument Corporation, Horsham, Pennsylvania, USA, eine derartige Kabelmodem-Leistungsfähigkeit. Die Socket-Netzschnittstelle stellt den Verbindungen mit den Inband-IP-Daten- sowie DOCSIS-Datenquellen einen recvfrom Datagrammdienst bereit. Außerdem wird diese Schnittstelle einen sendto Datagrammdienst und einen Zweiweg-Socketstrom-Datendienst für Verbindungen über nur den DOCSIS-Kanal unterstützen. Das Verfahren geht zu Schritt 66 über.
In Schritt 66 bestimmt die Verarbeitungslogik welche Art oder welcher Typ von Verbindung von der Anmeldung angefordert wurde. Wenn die Anwendung eine Socketstromverbindung (d. h. TCP-Verbindung) öffnet oder UDP-Datagramme stromaufwärts senden will, verwendet das Terminal 24 ein Mittel zur Übertragung stromaufwärts, beispielsweise einen DOCSIS-Port, wie in Schritt 68 gezeigt. Wenn eine Anwendung eine Socketverbindung öffnet und nach einer bestimmten Ziel-IP-Adresse und einem UDP-Port "nur horchen" möchte, wird das Terminal 24 auf dem gegenwärtig abgestimmten Inband-Dienst und, optional, dem DOCSIS-Port (wenn das Terminal 24 dementsprechend ausgerüstet ist) nach den Daten horchen. Es sei betont, dass die Multicast-IP-Adresse und der UDP-Port der Anwendung "wohl bekannt" sein mag (d. h. von der zugewiesenen Nummer-Autorität veröffentlicht oder anderweitig verfügbar gemacht wurde) oder der auf dem Terminal 24 laufenden Anwendung durch andere Mechanismen (z. B. einer ATVEF-Ankündigung) zugeführt werden kann.
In Schritt 70 wird die Multicast-IP-Adresse in eine Multicast-MAC-Adresse umgesetzt. Diese Umsetzung kann bewerkstelligt werden, indem die niedrigeren 23 Bits der Multicast-IP-Adresse in die niedrigeren 23 Bits der Multicast-MAC-Adresse 01.00.5E.00.00.00 umgesetzt werden. Dieser Umsetzungs-Ansatz ist in RFC 1112 dargelegt, der hier in seiner Gesamtheit unter Bezugnahme angeführt ist. Der Vorgang geht dann zum Entscheidungsschritt 72 über. Das Verarbeiten, das zu diesem Zeitpunkt geschieht, als "A" bezeichnet (d. h. umgehend vor dem Entscheidungsschritt 72), ist der Anfangs-Verarbeitungspunkt für das Terminal 24, wann immer eine "neue" PMT (Program Map Table) empfangen wird.
In Schritt 72 bestimmt das Terminal 24, ob die empfangene PMT einen PID-Datenstrom der Stromart 0x0D enthält. Beispielsweise weist der paketierte Elementarstrom, wie in 4 gezeigt, der als 56_k identifiziert ist, ein stream_type 0x0D auf, was darauf hinweist, dass die in jenem Datenstrom enthaltenen Daten IP-Daten sind. Ist die Antwort "NEIN", dann verzweigt sich das Verfahren nach Schritt 74, wobei der Teil des Dekodierers des Terminals 24 die auf dem Terminal 24 laufende Anwendung darüber informiert, dass die angeforderten IP-Daten nicht auffindbar waren. Das Verfahren geht zu Schritt 76 über, wobei der Teil des Dekodierers wartet (z. B. eine Schleife bildet), bis eine neue PMT empfangen wird. Zu einem solchen Zeitpunkt, wenn vom Terminal 24 eine neue PMT empfangen wird, wird die Steuerung zu Punkt "A" übergeben.
Ist die Anwort zum Entscheidungsschritt 72 jedoch "JA", dann geht das Verfahren zu Schritt 78 über.
In Schritt 78 bestimmt der Teil des Dekodierers, ob die vom Terminal 24 empfangene PMT (z. B. die in 4 gezeigte PMT 54) den Adressdeskriptor 60 gemäß der vorliegenden Erfindung enthält. Ist die Antwort "NEIN", dann geht das Verfahren zu Schritten 80 und 82 über, wobei der herkömmliche Ansatz zur Verarbeitung empfangener Daten befolgt wird. Das heißt, die DVB-MPE-Datagrammabschnitte werden extrahiert, die IP-Datagramm-Fragmente werden untersucht. Insbesondere wird der Dekodierer das table_id Feld von Meldungen, die innerhalb der ersten Daten-PID-Komponente von stream_type 0x0D getragen werden, untersuchen. Entspricht table_id nicht 0x3E (DVB-MPE-Datagrammabschnitt), ignoriert der Teil des Dekodierers die Meldung und schaut sich die nächste Meldung im PID-Strom an. Wie im Hintergrund beschrieben, ist dieser Ansatz nicht optimal und kann dem Terminal 24 unnötige Betriebsmittel-Lasten aufbürden (z. B. Verarbeitungs- und Speicheranforderungen).
Ist die Anwort zu Schritt 78 jedoch "JA", dann geht das Verfahren zu Schritt 84 über. In Schritt 84 extrahiert und verarbeitet der Teil des Dekodierers des Terminals 24 alle im in der PMT 54 enthaltenen Deskriptor 60 aufgelisteten MAC-Adressen. Wie in Tabelle 2 gezeigt, kann der Deskriptor 60 insbesondere die Multicast-MAC-Adressen identifizieren oder kann eine Auswahl an Multicast-MAC-Adressen angeben. Das Verfahren geht dann zu Schritt 86 über.
In Schritt 86 bestimmt der Teil des Terminals 24, ob die angeforderten IP- Daten, wie sie von der umgesetzten Multicast-MAC-Adresse (aus Schritt 70) angegeben wird, im Deskriptor 60 oder in der im Deskriptor 60 spezifizierten Auswahl aufgelistet sind. Ist die Antwort "NEIN", dann geht das Verfahren zu Schritt 88 über, wobei die auf dem Terminal 24 laufende Anwendung darüber informiert wird, dass die IP-Daten gegenwärtig nicht auffindbar sind, dass die Suche jedoch fortgesetzt wird. Der Teil des Dekodierers des Terminals 24 verarbeitet auch alle anderen Adressdeskriptoren, die anderen Daten-PID-Strömen von stream_type 0x0D zugehören, auch wenn die angeforderte MAC-Adresse gefunden wurde. Dies ist deshalb, weil es sein kann, dass identische Multicast-MAC-Adressen auf anderen Strom-Komponenten getragen werden. Dieses Szenario geschieht, weil der Umsetzungs-Ansatz, welcher für die Umsetzung von Multicast-IP-Adressen in Multicast-MAC-Adressen verwendet wird, nicht garantiert einzigartige Multicast-MAC-Adressen produziert. Multicast-IP-Adressen weisen 28-wertige Bits auf (wobei die ersten vier fest sind und eine Adresse der Klasse D identifizieren). Wie oben beschrieben, werden nur die niedrigeren 23 Bits in die niedrigeren 23 Bits-Positionen der Multicast-MAC-Aderesse 01.00.5E.00.00.00 umgesetzt. Daher ist es möglich, unterschiedliche Multicast-IP-Adressen in dieselbe Multicast-MAC-Adresse umzusetzten; wenigstens bei dem im RFC 1112 dargelegten Ansatz, der in einer konstruierten Ausführungsform verwendet wird. Vorzugsweise berücksichtigen die IP-Datenquellen (beispielsweise wie in 2 gezeigt) dieses Detail, indem sie eine Multicast-Adresse oder eine Auswahl an Adressen auswählen, um eine einzigartige Multicast-MAC-Adresse auf einem beliebigen bestimmten Netz beizubehalten.
Das Verfahren geht zu Schritt 90 über.
In Schritt 90 wählt der Dekodierer von Terminal 24 einen Strom oder mehrere Ströme aus und beginnt mit der Meldungsextrahierung. Sobald der Dekodierer mit dem Extrahieren der DVB-MPE-Datagrammabschnitte, die innerhalb eines oder mehrerer Daten-PID-Ströme getragen werden, begonnen hat, stellt er sicher, dass das table_id Feld der Meldungen "0x3E" ist, was angibt, dass die Meldung ein DVB-MPE-Datagrammabschnitt ist. Dieser Schritt ist als Entscheidungsschritt 92 in 5 gezeigt. Ist die Antwort "NEIN", dann verzweigt sich das Verfahren nach Schritt 94, wobei die nächste DSM-CC-Meldung zur Verarbeitung extrahiert wird. Ist die Anwort zu Schritt 92 jedoch "JA", dann verzweigt sich das Verfahren nach Schritt 96.
In Schritt 96 (z. B. table_id = "0x3E") vergleicht der Dekodierer des Terminals 24 die 48-Bit-Multicast-Adresse, wie sie innerhalb des Datagrammabschnitts (siehe 1) getragen wird, mit der angeforderten Multicast-MAC-Adresse (in Schritt 70 gebildet). Die Filterungs- und Vergleichsschritte sind als Schritte 96, 98 in 5 gezeigt. Ist die Antwort "JA", dann ist bestätigt, dass der DVB-MPE-Datagrammabschnitt ein Segment des von der Anwendung angeforderten IP-Datagramms trägt. Die Steuerung geht zu Schritt 100 über, wobei der Dekodierer des Terminals 24 die IP-Datagramm-Segmente aus den DVB-MPE-Datagrammabschnitten extrahiert. Der Dekodierer des Terminals 24 wird danach das extrahierte IP-Datagramm-Fragment an einen IP-Schicht-Softwareteil, der ebenfalls auf Terminal 24 läuft, wie in Schritt 102 gezeigt, weiterleiten. Das Verfahren geht dann zu Schritt 94 über, wobei die nächste Meldung zur weiteren Verarbeitung extrahiert wird.
Wenn die Anwort zu Schritt 98 jedoch "NEIN" ist, dann muss trotzdem noch eine weitere Überprüfung vorgenommen werden. Die Datenverbindungsschicht der Verarbeitung von Terminal 24 verhält sich vorzugsweise in ähnlicher Weise wie eine Standard-Netzschnittstelle. Daher muss der Dekodierer des Terminals 24 überprüfen, um zu bestimmen, ob die MAC-Adresse eine sogenannte Rundsendungs-MAC- Adresse (d. h. alle Einsen) ist. Bestimmt der Dekodierer des Terminals 24, dass eine MAC-Rundsendungs-Adresse empfangen wurde, wie in Schritt 104 gezeigt, dann wird er das IP-Datagramm-Fragment aus dem DVB-MPE-Datagrammabschnitt extrahieren und ihn zu der IP-Schicht zur weiteren Verarbeitung, wie oben in Schritten 100, 102 beschrieben, weiterleiten.
BEISPIEL
Die vorliegende Erfindung ist zum Erleichtern der Lieferung von Inhalt in einem Inhaltsdatenstrom (z. B. IP-Datagrammen) an ein Terminal angepasst. In einem bestimmten Beispiel ist der Inhalt mit einer ATVEF-Spezifikation (Spezifikation des Advanced Television Enhancement Forum) zur verbesserten Fernseh-Programmgestaltung konform. Die ATVEF-Norm ermöglicht die Zuordnung von HTML-Seiten zu einem audiovisuellen Dienst, die zur Rundsendung und zum Empfang durch einen konformen Empfänger, wie etwa ein Terminal 24, angepasst sind. Der Inhalt wird über ein IP-Protokoll geliefert. Die im Hintergrund erwähnte ATVEF-Spezifikation spezifiziert nicht den Lieferungs- oder Bindungsmechanismus unter der IP-Schicht, obgleich gewisse Normen, wie auch im Hintergrund erläutert, vorgeschlagen wurden, welche die Umsetzung (Anpassung) des IP-Protokolls in eine MPEG-Transportschicht (in 1 gezeigt) bereitstellen. Zum Beispiel werden die ATVEF-Transport-Rundsendungsdaten der Art B als drei unterschiedliche Komponenten an eine Anwendung (die auf Terminal 24 ausführt) geliefert: Ankündigungen, Trigger und Betriebsmittel. Ankündigungen können auf einer "wohl bekannten" Multicast-IP-Adresse und einem UDP-Port an eine Anwendung geliefert werden. Jede Ankündigung weist auf einen Trigger und ein Betriebsmittel hin, die für die Anwendung auf den spezifizierten Multicast-IP-Adressen und UDP-Ports verfügbar sind. In einer üblichen Anordnung sind die Ankündigungen, Trigger und Betriebsmittel als Teil derselben Datenstrom-Komponente eingeschlossen. Diese Datenstrom- Komponente wird einem bestimmten MPEG-Programm zugeordnet werden, indem diese Komponente innerhalb der PMT identifiziert wird. Die Datenstrom-Komponenten von stream_type = "0x0D" (d. h.
DSM_CC_section) können beispielsweise diese ATVEF-IP-Daten enthalten. Erfindungsgemäß ist die PMT konfiguriert, um einen Adressdeskriptor 60 zu tragen, der durch das Terminal 24 verwendet wird, um zu bestimmen, ob die Datenstrom-Komponente die IP-Daten trägt. Der Deskriptor 60 umfasst die Ziel-Multicast-Adresse der IP-Daten innerhalb des Stroms. Der Teil des Dekodierers des Terminals 24 kann dann diese Information verwenden, um schnell zu bestimmen, ob der Datenstrom die für das gegenwärtig abgestimmte MPEG-Programm bestimmten IP-Daten trägt, ohne dazu fortlaufend die IP-Daten zu extrahieren und diese an höhere Schichten zur Filterung weiterzuleiten.
Die Grundanwendung der vorliegenden Erfindung zur Ermöglichung verbesserter audiovisueller Dienste über ATVEF ist wie folgt. Als erstes wird das Terminal 24 auf einen IP-Daten, die einem ATVEF-Inhalt entsprechen, enthaltenden MPEG-Dienst abgestimmt. Eine auf dem Terminal 24 laufende Anwendung fordert dann eine Verbindung zu einer wohl bekannten Multicast-IP-Adresse und einem UDP-Port, die ATVEF-Ankündigungen tragen, an. Das Terminal 24 lokalisiert und extrahiert, gemäß der MPEG-2-Norm, eine PAT (Program Association Table), um die dem audiovisuellen Dienst zugehörige PMT zu finden. Dann extrahiert das Terminal 24 die PMT, um die verschiedenen Dienstkomponenten (Audio, Video, Daten), die dem abgestimmten Dienst zugehören, zu identifizieren. Wenn das Terminal 24 Datenkomponenten-PID-Ströme von stream_type 0x0D (DSM-CC-Abschnitte) beobachtet, dann untersucht es, erfindungsgemäß, die erfinderischen Adressdeskriptoren (z. B. den Adressdeskriptor 60), der einem derartigen Inhaltsdatenstrom zugehört. Das Terminal 24 bestimmt vom Deskriptor 60 aus, dass der PID-Strom IP-Daten und ferner die Multicast-MAC-Adressen, die einem derartigen Inhaltsdatenstrom zugehören, trägt.
Der Dekodierer des Terminals 24 analysiert dann die Liste von MAC-Adressen im Deskriptor 60 (oder mehreren Deskriptoren 60, wenn mehrere Komponenten-Datenströme der Art 0x0D vorhanden sind) syntaktisch, wobei er nach der von der Anwendung angeforderten Multicast-MAC-Adresse sucht. Die Liste von Multicast-Ziel-MAC-Adressen kann, lokal, zur späteren Verarbeitung gecachet werden.
Ist die angeforderte Multicast-MAC-Adresse (z. B. wie in Schritt 70, 5 umgesetzt) in der Liste von Multicast-MAC-Adressen im Deskriptor 60 enthalten, dann weist das Terminal 24 einen PID-Filter an, die DVB-MPE-Datagrammabschnitte aus dem/den jeweiligen Daten-PID-Strom/-Strömen zu extrahieren. Andererseits bildet das Terminal 24 beim Warten auf eine neue PMT-Version eine Schlaufe.
Das Terminal 24 beginnt dann damit, die DVB-MPE-Datagrammabschnitte zu extrahieren. Das Terminal 24 vergleicht die MAC-Adressen-Felder in dem DVB-MPE-Datagrammabschnitt (d. h. die device_Id Parameter in Tabelle 1) mit der angeforderten Multicast-MAC-Adresse. Besteht eine Übereinstimmung, dann extrahiert das Terminal 24 ein oder mehrere IP-Datagramm-Fragmente aus der entsprechenden DVB-MPE-Datagrammabschnitt-Nutzlast.
Das Terminal 24 leitet dann das IP-Datagramm-Fragment, das einen Teil der ATVEF-Ankündigungsmeldung trägt, an die IP-Schicht-Software zur Wiederzusammensetzung zu einem vollständigen IP-Datagramm und zur weiteren Verarbeitung der IP-Schicht weiter.
Wenn die Anmeldung von dem Teilnehmer 22 freigegeben worden ist, kann sie danach eine Verbindung zu (einer) Trigger- und Betriebsmittel-IP- Adresse(n) und UDP-Ports, wie in der festgehaltenen Ankündigung vorgesehen, anfordern.
In einer Ausführungsform bestimmt die Anwendung, welcher ATVEF-Trigger und welche ATVEF-Betriebsmittel angefordert werden sollen, basierend auf beispielsweise nur einer Sprachbevorzugung. Die Anwendung fordert ferner (in dem Betriebssystem des Terminals 24) ausreichend Speicher/Bandbreite an, um das größte Betriebsmittel/das schnellste Herunterladen zu akzeptieren. Gemäß der ATVEF-Norm (siehe Hintergrund) sind unterschiedliche Ebenen von Betriebsmitteln, die variierende Ebenen von Speicher verwenden und/oder eine größere Bandbreite erfordern, vorgesehen.
Das Terminal 24 untersucht dann die gecacheten Multicast-MAC-Adressen aus früher untersuchten PMT-Deskriptoren 60, die den Daten-PID-Strömen zugehören. Das Terminal 24 bestimmt, welcher Strom die angeforderten IP-Daten trägt und extrahiert die IP-Daten-Fragmente aus den DVB-MPE-Datagrammabschnitten. Das Terminal 24 leitet dann die festgehaltenen IP-Datagramm-Fragmente an die IP-Schicht-Software zur Wiederzusammensetzung zu einem vollständigen IP-Datagramm und zur weiteren IP-Verarbeitung weiter. Die Anwendung cachet die festgehaltenen Betriebsmitteldaten und verarbeitet einen Trigger auf ähnliche Weise, wenn er am Terminal 24 ankommt. Durch das Vorangehende gewinnt ein Teilnehmer effizient Zugriff auf einen durch ATVEF-Daten verbesserten audiovisuellen Dienst.
Erfindungsgemäß ist eine in einem MPEG-Digitalnetz verwendete PMT (Program Map Table) konfiguriert, um eine neue Meldung – einen Adressdeskriptor – zu tragen. Der Adressdeskriptor erleichtert die Lieferung von IP-Daten an ein Teilnehmer-Terminal, indem er Informationen (d. h. eine Multicast-MAC-Adresse) bereitstellt, die dem Terminal soweit nützlich ist, dass sie den Komponenten-PID-Datenstrom, der den Inhalt (IP-Daten) trägt, effizient lokalisiert.
Das Vorangehende ist beispielhaft und von der Art her nicht einschränkend; Modifikationen und Variationen sind möglich ohne den Bereich der Erfindung, der lediglich durch die angehängten Ansprüche beschränkt ist, zu verlassen. Es versteht sich, dass Variationen möglich sind. Es versteht sich beispielsweise, dass, obwohl das Obengenannte ein Szenario beschreibt, in dem die Inband-IP-Daten direkt einem bestimmten MPEG-Programm (d. h. einem audiovisuellen Dienst) zugehören, alternative Ausführungsformen ein System bereitstellen, in dem eine Anwendung auf Terminal 24 Dienste, die IP-Daten, entweder innerhalb des gegenwärtig abgestimmten MPEG-Transportstroms (wie oben beschrieben) oder einem vollständig anderen MPEG-Transportstrom oder -strömen tragen, lokalisieren kann. Die vorliegende Erfindung ist außerdem im Allgemeinen auf das Erleichtern der Lieferung von IP-Daten anwendbar, wobei ein Beispiel dafür das Tragen von ATVEF-IP-Daten ist. Weitere Verwendungen jedoch umfassen, beschränken sich aber nicht auf, die Erleichterung der Lieferung von IP-Daten von einer Internet-Webseite, oder als anderes Beispiel, die Lieferung von Codeobjekten an das Terminal 24 (z. B. Betriebssysteme, Anwendungen etc.).

Claims

Ein Verfahren zum Erleichtern der Lieferung von Inhalt in einem Inhaltsdatenstrom an ein Terminal (24), wobei das Verfahren folgende Schritte beinhaltet: Erzeugen eines Deskriptors (60) für den Inhaltsdatenstrom, wobei der Deskriptor (60) mindestens eine Zieladresse umfasst, wobei die mindestens eine Zieladresse mindestens eine Multicast-Medienzugriffssteuerungsadresse beinhaltet; und Übertragen des Deskriptors auf das Terminal (24) in einer PMT (54) (Program Map Table); Lokalisieren des Inhaltsdatenstroms an dem Terminal (24) unter Verwendung der Zieladresse in dem Deskriptor (60).
Verfahren gemäß Anspruch 1, das ferner folgenden Schritt umfasst: Extrahieren einer Meldung, die dem identifizierten Inhalt aus dem Inhaltsdatenstrom entspricht.
Verfahren gemäß Anspruch 1, wobei der Datendienst in einem MPEG-2-Transportstrom (Moving Pictures Expert Group-2) auf das Terminal übertragen wird.
Verfahren gemäß Anspruch 3, wobei der Inhalt mit einer ATVEF-Spezifikation (Advanced Television Enhancement Forum) zur verbesserten Fernseh-Programmgestaltung konform ist.
Verfahren gemäß Anspruch 4, wobei der ATVEF-Inhalt unter Verwendung des UDP-Protokolls (User Datagram Protocol) und des IP-Protokolls (Internet Protocol) getragen wird, wobei das Verfahren ferner folgende Schritte beinhaltet: Verkapseln von IP-Datagrammen in eine Form, die in einem MPEG-2-Transportstrom getragen werden kann; und Übertragen der verkapselten IP-Datagramme auf das Terminal (24) im Transportstrom.
Verfahren gemäß Anspruch 5, wobei der Übertragungsschritt folgenden Unterschritt beinhaltet: Sammelsenden der verkapselten Datagramme an eine Vielzahl von Terminals, einschließlich des Terminals (24).
Verfahren gemäß Anspruch 5, wobei die Form einer DVB-MPE-Spezifikation (Digital Video Broadcasting/Multi-Protocol Encapsulation) für Datagrammabschnitte entspricht.
Verfahren gemäß Anspruch 5, wobei die Form einer ATSC-Spezifikation (Advanced Television Systems Committee) für adressierbare Angelegenheiten entspricht.
Verfahren gemäß Anspruch 6, das ferner folgende Schritte umfasst: Ausführen einer Anwendung auf dem Terminal (24), das zur Verwendung des Inhalts konfiguriert ist; Anfordern einer Verbindung zu einer Multicast-IP-Adresse, an der sich der Inhalt befinden kann; und Umsetzen der Multicast-IP-Adresse in eine entsprechende Multicast-Medienzugriffssteuerungsadresse.
Verfahren gemäß Anspruch 9, wobei der Schritt des Lokalisierens des Inhaltsdatenstromsfolgende Unterschritte umfasst: Extrahieren der mindestens einen Multicast-Medienzugriffssteuerungsadresse, die in dem Deskriptor aus der PMT (54) (Program Map Table) eingeschlossen ist; und Bestimmen, ob die umgesetzte Multicast-Medienzugriffssteuerungsadresse in der extrahierten mindestens einen Multicast-Medienzugriffssteuerungsadresse eingeschlossen ist.
Verfahren gemäß Anspruch 10, das ferner folgenden Schritt umfasst: Extrahieren einer Meldung, die dem ATVEF-Inhalt entspricht, wenn die umgesetzte Multicast-Medienzugriftssteuerungsadresse in der extrahierten mindestens einen Multicast-Medienzugriftssteuerungsadresse eingeschlossen ist.
Verfahren gemäß Anspruch 11, das ferner folgenden Schritt umfasst: Bereitstellen eines verbesserten audiovisuellen Dienstes in Übereinstimmung mit der extrahierten Meldung über die Anwendung.
Verfahren gemäß Anspruch 1, wobei der Datendienst ein audiovisueller Dienst ist und wobei der Inhaltsdatenstrom und die PMT (54) (Program Map Table) dem audiovisuellen Dienst zugehören.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei das Verfahren die Lieferung des Inhaltsdatenstroms an das Terminal (24) durch einen MPEG-Transportstrom (Moving Pictures Expert Group) zum Verbessern eines Datendienstes, der durch diesen MPEG-Transportstrom getragen wird, erleichtert, wobei das Verfahren folgenden Schritt umfasst: Wiedergewinnen einer Meldung aus dem Inhaltsdatenstrom, der dem Inhalt, der die in dem Deskriptor (60) eingeschlossene Zieladresse verwendet, entspricht.
Verfahren gemäß Anspruch 14, wobei die Meldung in demselben Dienststrom des MPEG-Transportstroms wie der Datendienst getragen wird.
Verfahren gemäß Anspruch 15, wobei der Inhalt ATVEF (Advanced Television Enhancement Forum) konformen Inhalt beinhaltet.
Eine Vorrichtung zum Erleichtern der Lieferung eines Inhaltsdatenstroms, einschließlich Inhalts, durch einen MPEG-Transportstrom (Motion Pictures Expert Group Transportstrom) an ein Terminal (24) zum Verbessern eines audiovisuellen Dienstes, wobei die Vorrichtung Folgendes beinhaltet: einen Speicher, der konfiguriert ist, um eine dem Inhaltsdatenstrom zugehörige Multicast-IP-Adresse abzuspeichern; und einen Prozessor, der konfiguriert ist, um einen Adressdeskriptor (60) zu erzeugen, welcher zum Einschluss in einer PMT (54) (Program Map Table) vorgesehen ist, wobei der Deskriptor (60) mindestens eine in Übereinstimmung mit der Multicast-IP-Adresse erzeugte Zieladresse umfasst; wobei Medienzugriffssteuerungs-Zieladresse beinhaltet.
Ein Terminal, das Folgendes beinhaltet: eine Anwendung, die konfiguriert ist, um eine Verbindung mit einer Multicast-IP-Adresse zum Empfang von Inhalt, der konfiguriert ist, um einen Datendienst zu verbessern, anzufordern; ein Mittel zur Überprüfung einer PMT (54) (Program Map Table), die dem audiovisuellen Dienst zugehört, für die Bestimmung der Anwesenheit eines Adressdeskriptors (60), wobei der Adressdeskriptor (60) eine Multicast-Medienzugriffssteuerungsadresse umfasst; und ein Mittel zur Wiedergewinnung einer Meldung, die dem Inhalt entspricht, wenn diese Multicast-Medienzugriffssteuerungadresse verwendet wird, und Bereitstellen der Meldung an die Anwendung.