[go: up one dir, main page]

DE112011103965B4 - Verfahren zur Übertragung eines Rundfunkdienstes sowie Verfahren und Vorrichtung zum Empfang eines Rundfunkdienstes - Google Patents

Verfahren zur Übertragung eines Rundfunkdienstes sowie Verfahren und Vorrichtung zum Empfang eines Rundfunkdienstes Download PDF

Info

Publication number
DE112011103965B4
DE112011103965B4 DE112011103965.4T DE112011103965T DE112011103965B4 DE 112011103965 B4 DE112011103965 B4 DE 112011103965B4 DE 112011103965 T DE112011103965 T DE 112011103965T DE 112011103965 B4 DE112011103965 B4 DE 112011103965B4
Authority
DE
Germany
Prior art keywords
trigger
service
data
nrt
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE112011103965.4T
Other languages
English (en)
Other versions
DE112011103965T5 (de
Inventor
Sanghyun Kim
Kwansuk Kim
Dongwan Seo
Jongyeul Suh
Joonhui Lee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of DE112011103965T5 publication Critical patent/DE112011103965T5/de
Application granted granted Critical
Publication of DE112011103965B4 publication Critical patent/DE112011103965B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/015—High-definition television systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26283—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for associating distribution time parameters to content, e.g. to generate electronic program guide data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren für eine Ausstrahlungsempfängervorrichtung zum Empfangen einer Ausstrahlung, umfassend:Empfangen eines Ausstrahlungs-Stream, der Medien enthält, darunter Audio oder Video;Erhalten einer IP-Adresse für einen ersten Auslöser aus dem Ausstrahlungs-Stream;Empfangen (S240) eines ersten Auslösers mit der IP-Adresse,wobei der erste Auslöser Informationen enthält, die eine Kennung zum Identifizieren eines ausgelösten deklarativen Objekts (TDO, Triggered Declarative Object) repräsentieren, Informationen, die eine erste Auslöserzeit repräsentieren, und Informationen, die eine erste Auslöseraktion repräsentieren und wobei die erste Auslöseraktion eine Vorbereitung repräsentiert;Extrahieren (S240) der Informationen, die die Kennung repräsentieren, der Informationen, die die erste Auslöserzeit repräsentieren, und der Informationen, die die erste Auslöseraktion repräsentieren, aus dem ersten Auslöser;Durchführen (S250) der ersten Auslöseraktion in der ersten Auslöserzeit für das durch die Kennung identifizierte TDO, wenn eine Empfangszeit des ersten Auslösers vor der ersten Auslöserzeit liegt; undsofortiges Durchführen der ersten Auslöseraktion für das durch die Kennung identifizierte TDO, wenn eine Empfangszeit des ersten Auslösers nach der ersten Auslöserzeit liegt,wobei das TDO eine Nichtechtzeit-(NRT, non-real time service)-Dienst Anwendung ist, die von dem ersten Auslöser ausgelöst wird,wobei die Vorbereitung die Ausführung des TDO vorbereitet, damit das TDO zur Auslöserzeit reibungslos funktioniert.

Description

  • FACHGEBIET
  • Die vorliegende Erfindung betrifft ein Verfahren zur Übertragung eines Rundfunkdienstes, ein Verfahren zum Empfang des Rundfunkdienstes sowie eine Vorrichtung zum Empfang des Rundfunkdienstes.
  • STAND DER TECHNIK
  • Über das digitale Fernsehen (DTV) werden neben der ursprünglichen Funktion des Fernsehens (TV), die in der Wiedergabe von Video und Audio bestand, nun verschiedene zusätzliche Dienste angeboten. Beispielsweise können einem Benutzer Sendungsdaten wie z.B. ein elektronischer Programmführer (EPG) übermittelt werden; außerdem können Rundfunkdienste mindestens zweier Kanäle einem Benutzer gleichzeitig zur Verfügung gestellt werden. Gerade weil eine DTV-Empfangsanlage eine erhebliche Speicherkapazität umfasst und mit einem Datenkommunikationskanal sowie dem Internet (wodurch eine bidirektionale Kommunikation ermöglicht wird) verbunden ist, werden über Rundfunksignale noch weitere Dienste zugänglich. Außerdem nimmt der Bedarf nach den vielfältigen Diensten mit der zunehmenden Vielfalt der über Rundfunksignale angebotenen Dienste zu.
  • Das Dokument US 2009 / 0 276 819 A1 offenbart ein Verfahren zum Empfang einer Rundfunkausstrahlung für eine Ausstrahlungsempfängervorrichtung. Hierbei werden durch die Ausstrahlungsempfängervorrichtung Auslöser empfangen, welche vorbestimmte Aktionen auslösen.
  • Ferner offenbart das Dokument US 2002 / 0 056 129 A1 Auslöser mit Zeitattributen, die einen Zeitpunkt oder Zeitraum angeben, indem der jeweilige Auslöser ein vorbestimmtes Ereignis auslösen soll.
  • Das Dokument WO 2007 / 083 824 A1 offenbart ein Verfahren und eine Vorrichtung zur Übertragung von rundfunkausstrahlungsbezogenen Inhalten über einen zuvor ermittelten Benachrichtigungsübertragungskanal.
  • BESCHREIBUNG DER ERFINDUNG
  • TECHNISCHES PROBLEM
  • Gemäß den Ausführungsformen der Erfindung werden ein Verfahren zum Empfang und zur Verarbeitung eines Nicht-Echtzeit-Dienstes sowie ein Verfahren zur Übertragung des Nicht-Echtzeit-Dienstes bereitgestellt.
  • Gemäß den vorliegenden Ausführungsformen werden auch ein Verfahren zur Verknüpfung eines über einen Nicht-Echtzeit-Dienst heruntergeladenen Inhaltes mit einem Rundfunkdienst sowie eine entsprechende Empfangsvorrichtung bereitgestellt.
  • Gemäß den vorliegenden Ausführungsformen werden ferner ein Übertragungsverfahren zur Verknüpfung eines Nicht-Echtzeit-Dienstes mit einem Echtzeit-Rundfunkdienst, ohne dabei eine typische Empfangsvorrichtung zu stören, sowie eine entsprechende Empfangsvorrichtung bereitgestellt.
  • TECHNISCHE LÖSUNG
  • Gemäß einer Ausführungsform umfasst ein Verfahren zum Empfang eines Rundfunkdienstes: Empfangen eines ersten paketierten Stroms; Extrahieren von Laufzeitdaten aus einem Kopf des ersten paketierten Stroms; Extrahieren von Vorbereitungsauslöserdaten, die eine Zieldienstkennung umfassen, aus einem Payload des ersten paketierten Stroms; und Aufnahme der Vorbereitung eines der Zieldienstkennung entsprechenden Objektes zur späteren Aktivierung des Objektes, sofern es sich bei einer aktuellen Zeit um eine durch die extrahierten Daten identifizierte Vorbereitungszeit handelt.
  • Gemäß einer weiteren Ausführungsform umfasst eine Vorrichtung zum Empfang eines Rundfunkdienstes: eine zum Empfang eines ersten paketierten Stroms konfigurierte Empfangseinheit; eine zum Extrahieren von Wartungstriggerdaten, die eine Zieldienstkennung aus einem Payload des ersten paketierten Stroms umfassen, konfigurierte Auslöserverarbeitungseinheit; sowie einen zur Verwaltung eines der Zieldienstkennung entsprechenden Objektes als Reaktion auf die Wartungstriggerdaten konfigurierten Service-Manager, wobei der Service-Manager die Aktivierung des Objektes beibehält, sofern das Objekt bereits aktiviert ist, und wobei der Service-Manager das Objekt aktiviert, sofern es noch nicht aktiviert ist.
  • Gemäß einer weiteren Ausführungsform umfasst ein Verfahren zur Übertragung eines Rundfunkdienstes: Einfügen der einer Aktivationszeit eines Zieldienstes entsprechenden Laufzeitdaten in einen Kopf eines ersten paketierten Stroms; Einfügen von Aktivationsauslöserdaten, die eine Kennung des Zieldienstes umfassen, in ein Payload des ersten paketierten Stroms; und Übertragen eines ersten paketierten Stroms.
  • Gemäß noch einer weiteren Ausführungsform umfasst ein Verfahren zur Übertragung eines Rundfunkdienstes: Einfügen von Wartungstriggerdaten, die eine Kennung des Zieldienstes umfassen, in ein Payload des ersten paketierten Stroms; und Übertragen des ersten paketierten Stroms an ein Empfangsgerät, wobei die Wartungstriggerdaten die Wartung der Aktivierung des Objektes auslösen, sofern das Objekt im Empfangsgerät bereits aktiviert ist, wobei die Wartungstriggerdaten die Aktivierung des Objektes auslösen, sofern das Objekt im Empfangsgerät noch nicht aktiviert ist.
  • VORTEILHAFTE WIRKUNGEN
  • Gemäß einer Ausführungsform wird ein über einen Nicht-Echtzeit-Dienst heruntergeladener Inhalt mit einem Echtzeit-Rundfunkdienst verknüpft.
  • Außerdem wird gemäß einer Ausführungsform ein über einen Nicht-Echtzeit-Dienst heruntergeladener Inhalt mit einem Echtzeit-Rundfunkdienst verknüpft, ohne dabei ein bereits vorhandenes Empfangsgerät zu stören.
  • Außerdem wird gemäß einer Ausführungsform ein Rundfunkdienst mit präziser Zeitsteuerung bereitgestellt.
  • Figurenliste
    • 1 ist ein Konzeptdiagramm der Art und Weise, auf die RT- und NRT-Dienste bereitgestellt werden.
    • 2 ist eine Ansicht einer Struktur eines NRT-Dienstes nach einer Ausführungsform.
    • 3 ist eine Ansicht einer Struktur eines Protokollstacks eines NRT-Dienstes nach einer Ausführungsform.
    • 4 ist eine Ansicht eines Beispiels des Protokollstacks eines mobilen NRT-Dienstes.
    • 5 ist eine Ansicht eines Abschnitts eines Bitstroms eines Abschnitts einer TVCT- (VCT) Tabelle nach einer Ausführungsform.
    • 6 und 7 sind Ansichten, die veranschaulichen, wie ein Wert eines service_type-Feldes nach einer Ausführungsform zu definieren ist.
    • 8 ist eine Ansicht eines data_service_table_section)-Feldes zur Kennzeichnung einer Anwendung der NRT-Dienst- und Bitstrom-Syntax des data_service_table_bytes-Feldes eines DST-Abschnitts.
    • 9 ist eine Ansicht eines Verfahrens zum Empfang und zur Übertragung eines NRT-Dienstes in einer Empfangsanlage unter Einsatz der Norm ATSC A/90 zur Übertragung von Datenströmen sowie der Norm ATSC A/92 zur Übertragung eines IP-Multicast-Stroms.
    • 10 und 11 sind Ansichten eines Verfahrens zur Signalisierung von DSM-CC-adressierbaren Abschnittsdaten mit VCT gemäß einer weiteren Ausführungsform.
    • 11 zeigt ein Verfahren zur Signalisierung von DSM-CC-adressierbaren Abschnittsdaten mit VCT gemäß einer weiteren Ausführungsform.
    • 12 und 13 sind Ansichten einer Bitstromsyntax von NST nach einer Ausführungsform.
    • 14 ist eine Ansicht der Bitstromsyntax eines NRT_component_descriptor (MH_component_descriptor)-Feldes nach einer Ausführungsform.
    • 15 ist eine Ansicht der Bitstromsyntax eines NRT_component_descriptor-Feldes nach einer Ausführungsform, das NRT_component_data enthält.
    • 16 ist eine Ansicht der Bitstromsyntax eines NRT-IT-Abschnitts zur Signalisierung einer NRT-Anwendung nach einer Ausführungsform.
    • 17 ist eine Ansicht einer Syntaxstruktur eines Bitstroms des NRT-Abschnitts (NRT_component_table_section) nach einer Ausführungsform.
    • 18 ist eine Ansicht der Bitstromsyntaxstruktur einer SMT-Sitzung, die nach einer Ausführungsform Signalisierungsdaten über NRT-Dienstdaten bereitstellt.
    • 19 ist eine Ansicht eins FDT-Schemas zum Mapping einer Datei und eines content-id-Feldes nach einer Ausführungsform.
    • 20 ist eine Ansicht eins FDT-Schemas zum Mapping einer Datei und eines content_id-Feldes nach einer Ausführungsform.
    • 21 ist ein Flussdiagramm einer Operation eines Empfangsgeräts nach einer Ausführungsform.
    • 22 und 23 sind Ansichten einer Empfangsanlage nach einer Ausführungsform, die einen NRT-Inhalt eines NRT-Dienstes empfängt, speichert und wiedergibt.
    • 24 ist ein Flussdiagramm eines Verfahrens des Empfangens und Bereitstellens eines NRT-Dienstes durch ein Empfangsgerät nach einer Ausführungsform.
    • 25 ist eine Ansicht einer Bitstromsyntax eines Triggers nach einer Ausführungsform.
    • 26 ist eine Ansicht einer PES-Struktur nach einem synchronisierten Datenstromverfahren mit Trigger nach einer Ausführungsform.
    • 27 ist eine Ansicht einer synchronisierten Datenpaketstruktur eines PES-Payloads zur Übertragung eines Triggers als Bitstromsyntax nach einer Ausführungsform.
    • 28 ist eine Ansicht einer Inhaltstypkennungsstruktur in tap() auf DST nach einer Ausführungsform.
    • 29 ist eine Ansicht einer Syntax einer PMT und einer Dienstkennung nach einer Ausführungsform.
    • 30 ist eine Ansicht einer Triggerstromkennung nach einer Ausführungsform.
    • 31 ist eine Ansicht einer AIT nach einer Ausführungsform.
    • 32 ist eine Ansicht einer STT nach einer Ausführungsform.
    • 33 ist ein Blockdiagramm eines Sendegeräts zur Übertragung von TDO sowie eines Triggers nach einer Ausführungsform.
    • 34 ist ein Blockdiagramm eines Empfangsgeräts zum Empfang von TDO sowie eines Triggers nach einer Ausführungsform.
    • 35 ist ein Flussdiagramm eines Verfahrens zur Übertragung eines Triggers nach einer Ausführungsform.
    • 36 ist ein Flussdiagramm einer Operation eines Empfangsgeräts 300 nach einer Ausführungsform.
    • 37 ist ein Flussdiagramm eines Verfahrens zum Empfang eines Triggers unter Einsatz einer Triggertabelle nach einer Ausführungsform.
    • 38 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass die Trigger-Signalisierungsdaten und der Trigger nach einer Ausführungsform mit DST übertragen werden.
    • 39 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit einem Triggerstromdeskriptor übertragen wird.
    • 40 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit einem Stromtyp übertragen wird.
    • 41 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit AIT übertragen wird.
    • 42 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit STT übertragen wird.
    • 43 ist ein Zeitdiagramm nach einer Ausführungsform der vorliegenden Erfindung.
    • 44 ist ein Zeitdiagramm eines Verfahrens zur Übertragung von Aktivierungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
    • 45 ist ein Zeitdiagramm nach einer Ausführungsform der vorliegenden Erfindung.
    • 46 ist ein Flussdiagramm eines Verfahrens zur Übertragung von Wartungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
    • 47 zweigt, wie Wartungstriggerdaten nach einer nach einer Ausführungsform der vorliegenden Erfindung.
    • 48 ist ein Zeitdiagramm nach einer Ausführungsform der vorliegenden Erfindung.
    • 49 ist ein Zeitdiagramm eines Verfahrens zum Empfang von Vorbereitungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
    • 50 ist ein Flussdiagramm eines Verfahrens zum Empfang von Vorbereitungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
  • AUSFÜHRUNGSFORM DER VORLIEGENDEN ERFINDUNG
  • Nachfolgend werden bevorzugte Ausführungsformen der vorliegenden Erfindung anhand der beigefügten Zeichnungen ausführlich beschrieben. Die in den beigefügten Zeichnungen dargestellten und unten beschriebenen erfindungsgemäßen Konfigurationen und Operationen sind mindestens beispielhaft beschrieben, und der technische Grundgedanke der vorliegenden Erfindung sowie deren wichtigste Konfigurationen und Operationen werden dadurch nicht eingeschränkt.
  • Die vorliegend verwendeten Begriffe orientieren sich soweit möglich unter Berücksichtigung der Funktionen der vorliegenden Erfindung am aktuellen Sprachgebrauch, können jedoch aufgrund der Absichten oder Gewohnheiten des Fachgebiets sowie der Entstehung neuer Technologien auch davon abweichen. In einigen Fällen werden Begriffe willkürlich durch einen Anmelder ausgewählt; in diesem Fall werden ihre Bedeutungen in der Beschreibung ausführlicher dargelegt. Dementsprechend sind die vorliegend verwendeten Begriffe auf der Grundlage der Begriffe und Inhalte der vorliegenden Erfindung, und nicht einfach dem Namen nach aufzufassen.
  • Außerdem bedeutet unter den Begriffen der vorliegenden Erfindung ein Echtzeit-Dienst (RT-Dienst) wörtlich einen in Echtzeit dargebotenen Dienst. Mit anderen Worten ist der Dienst zeitlich begrenzt. Ein Nicht-Echtzeit-Dienst (NRT) hingegen ist ein anderer Dienst als der RT-Dienst, der in NRT erfolgt. Mit anderen Worten ist der Dienst zeitlich unbegrenzt. Außerdem werden die Daten eines NRT-Dienstes als NRT-Dienstdaten bezeichnet.
  • Ein erfindungsgemäßes Empfangsgerät kann NRT-Dienste über ein Medium wie z.B. eine terrestrische Welle, ein Kabel oder das Internet empfangen.
  • Ein NRT-Dienst kann in einem Speichermedium des Empfangsgeräts gespeichert und dann auf einer Anzeigevorrichtung zu einem vorbestimmten Zeitpunkt oder auf Anforderung des Benutzers gezeigt werden. Der NRT-Dienst wird in einem Dateiformat empfangen, und wird nach einer Ausführungsform in einem Speichermedium gespeichert. Beim Speichermedium kann es sich nach einer Ausführungsform um eine im Empfangsgerät eingebettete Festplatte (HDD) handeln. In einem weiteren Beispiel kann es sich beim Speichermedium um einen USB-Speicher oder eine externe HDD handeln, die jeweils mit der Empfangsanlage verbunden sind.
  • Um die Dateien, aus denen ein NRT-Dienst besteht, zu empfangen, sie in einem Speichermedium zu speichern und dem Benutzer einen dienst bereitzustellen, sind Signalisierungsdaten erforderlich. Vorliegend werden diese Signalisierungsdaten als NRT-Signalisierungsdaten bezeichnet.
  • Der NRT-Dienst umfasst ortsfeste und mobile NRT-Dienste nach einem Verfahren zum Empfang von IP-Datagrammen, insbesondere NRT-Signalisierungsdaten. Im Einzelnen wird der ortsfeste NRT-Dienst an ein ortsfestes Empfangsgerät, und der mobile NRT-Dienst an ein mobiles Empfangsgerät übertragen.
  • 1 ist ein Konzeptdiagramm der Art und Weise, auf die RT- und NRT-Dienste bereitgestellt werden.
  • Ein Sender überträgt den RT-Dienst auf herkömmliche Weise, d.h. wie eine terrestrische Sendung (oder mobile Sendung) nach dem Stand der Technik. Zu diesem Zeitpunkt überträgt der Sender den RT-Dienst, und kann dann während der Übertragung zur Übertragung des NRT-Dienstes eine verbleibende Bandbreite gebrauchen. Mit anderen Worten werden RT- und NRT-Dienste über denselben oder auch unterschiedliche Kanäle übertragen. Deshalb sind Dienst-Signalisierungsdaten (oder NRT-Dienst-Signalisierungsdaten) erforderlich, damit ein Empfangsgerät den RT-Dienst vom NRT-Dienst trennen und den getrennten NRT-Dienst ggf. zur Bereitstellung an einen Benutzer speichern kann. Die NRT-Dienst-Signalisierungsdaten werden nachfolgend ausführlicher beschrieben.
  • Beispielsweise überträgt ein Sender Rundfunkdienstdaten in Echtzeit und Nachrichtenclips, Wetterdaten, Werbung und Push-VOD in Nicht-Echtzeit. Außerdem kann es sich bei NRT-Daten nicht nur um Nachrichtenclips, Wetterdaten, Werbung und Push-VOD, sondern auch um konkrete Szenen, detaillierte Daten eines konkreten Programms sowie Vorschauen im Echtzeit-Sendestrom handeln.
  • Ein typisches Empfangsgerät (d.h. ein Legacy-Gerät) kann den RT-Dienst empfangen und verarbeiten, den NRT-Dienst kann es aber womöglich nicht empfangen oder verarbeiten. Mit anderen Worten: Das typische Empfangsgerät (Legacy-Gerät) wird auf einem Kanal, der einen RT-Dienst sendet, von einem NRT-Strom grundsätzlich nicht beeinflusst. Das heißt: Selbst dann, wenn ein NRT-Dienst empfangen wird, kann das typische Empfangsgerät den empfangenen NRT-Dienst nicht verarbeiten, denn es umfasst keine Einheit, die eine entsprechende Verarbeitung ermöglichen würde.
  • Andererseits empfängt das erfindungsgemäße Empfangsgerät (d.h. ein NRT-Gerät) den NRT-Dienst in Kombination mit dem RT-Dienst, und verarbeitet den NRT-Dienst entsprechen; also kann es einem Zuschauer eine breitere Palette an Funktionen anbieten als ein typisches Empfangsgerät.
  • 2 ist eine Ansicht einer Struktur eines NRT-Dienstes nach einer Ausführungsform.
  • Der NRT-Dienst umfasst mindestens einen in 2 gezeigten Inhalt (oder Inhalt oder NRT-Inhalt), und der Inhalt umfasst gemäß einer Ausführungsform mindestens eine Datei. Erfindungsgemäß sind die Begriffe „Datei“ und „Objekt“ gleichbedeutend.
  • Der Inhalt ist eine unabhängig wiedergabefähige Mindesteinheit. Beispielsweise werden Nachrichten in NRT gesendet. Enthält die Nachricht Wirtschaftsnachrichten, politische Nachrichten und Lifestyle-Nachrichten, so kann es sich um einen NRT-Dienst handeln, und jede kann als Inhalt bezeichnet werden. Außerdem kann jede der Wirtschaftsnachrichten, politischen Nachrichten und Lifestyle-Nachrichten mindestens eine Datei umfassen.
  • Zu diesem Zeitpunkt kann der NRT-Dienst im Paketformat MPEG-2-Transportstrom (TS) über denselben Sendekanal als der RT-Dienst oder über einen exklusiven Sendekanal übertragen werden. In diesem Fall kann dem TS-Paket der NRT-Dienstdaten zur Identifizierung des NRT-Dienstes eine eindeutige PID zugewiesen und anschließend übertragen werden. Gemäß einer Ausführungsform der vorliegenden Erfindung werden NRT-Dienstdaten auf IP-Basis in ein MPEG-2-TS-Paket paketiert und anschließend übertragen.
  • Zu diesem Zeitpunkt werden die zum Empfang der NRT-Dienstdaten erforderlichen NRT-Dienstsignalisierungsdaten über einen NRT-Dienst-Signalisierungskanal übertragen. Der NRT-Dienst-Signalisierungskanal wird über einen spezifischen IP-Strom auf einer IP-Schicht übertragen, und zu diesem Zeitpunkt kann dieser spezifische IP-Strom in ein MPEG-2-TS-Paket paketiert und anschließend übertragen werden. Die über den NRT-Dienst-Signalisierungskanal übertragenen NRT-Dienstsignalisierungsdaten können mindestens eine von einer Service Map Table (SMT), einer NRT-Service Table (NST), einer NRT Content Table (NCT), einer NRT Information Table (NRT-IT) und einer Text Fragment Table (TFT) enthalten. Die NST oder SMT liefert Zugangsdaten über mindestens einen auf einer IP-Schicht betriebenen Dienst bzw. über die Inhalte oder Dateien, aus denen der NRT-Dienst besteht. Die NRT-IT oder NCT liefert Zugangsdaten über die Inhalte oder Dateien, aus denen der NRT-Dienst besteht.
  • Außerdem können NRT-Dienstsignalisierungsdaten, insbesondere SMT (oder NST) und NRT-IT (oder NCT), in eine PSIP-Tabelle auf MPEG-2 TS aufgenommen werden oder über einen NRT-Dienstsignalisierungskanal auf einer IP-Schicht in einem virtuellen Kanal übertragen werden. Außerdem kann eine Mehrzahl NRT-Dienstdaten über einen virtuellen Kanal bereitgestellt werden.
  • Die NRT-IT enthält Daten, die einen zur Speicherung in einem Empfangsgerät herunterladbaren Inhalt beschreiben. Die der NRT-IT zur Verfügung gestellten Daten können einen Inhaltstitel (beispielsweise den Namen eines herunterladbaren Programms), die Dauer, für die der Inhalt zum Herunterladen zur Verfügung steht, Inhaltsempfehlungen, Verfügbarkeit von Untertiteln, Inhaltskennungen und sonstige Metadaten enthalten.
  • Außerdem liefert die TFT eine detaillierte Beschreibung eines Inhalts oder Dienstes. Die TFT kann eine Datenstruktur enthalten, die mehrere Sprachen unterstützt, und kann folglich detaillierte Beschreibungen in verschiedenen Sprachen (z.B. jeder Spring enthält einer Sprache) darstellen. Die Textfragmenttabelle kann in privaten Abschnitten enthalten sein, die einen table_id-Wert (TBD) aufweisen und können mittels TFT_id identifiziert werden. Ein TFT-Abschnitt kann in IP-Paketen auf einem Dienstsignalisierungskanal enthalten sein, und eine Multicast-IP-Adresse (224.0.23.60) und ein Port (4937) kann durch IANA dem Dienstsignalisierungskanal zugewiesen werden.
  • Zunächst kann ein Empfangsgerät z.B. unter Bezugnahme auf ein service_category-Feld in der SMT feststellen, ob ein entsprechender Dienst der NRT-Dienst ist. Außerdem kann das Empfangsgerät den NRT-Dienst anhand der SMT über ein NRT_service_id-Feld eindeutig erkennen.
  • Außerdem kann der NRT-Dienst eine Mehrzahl Inhalte enthalten. Der Empfänger kann einen NRT-Inhalt anhand eines content_id-Feldes in der NCT oder NRT-IT erkennen. Außerdem können der NRT-Inhalt und der NRT-Dienst dadurch miteinander verbunden werden, dass das NRT_channel_id-Feld der NCT mit dem NRT_service_id-Feld abgeglichen wird.
  • Außerdem kann der NRT-Dienst über eine FLUTE-Sitzung übertragen werden, und das Empfangsgerät kann der FLUTE-Sitzung die FDT-Daten entnehmen. Dann wird der content_id-Wert der extrahierten FDT-Daten auf den content_id-Wert der NCT oder OMA-BCAST SG abgebildet werden, um den von einem Benutzer ausgewählten NRT-Dienstinhalt zu bestätigen und zu empfangen. Wird die Abbildungsmethode z.B. kurz beschrieben, identifiziert das Empfänger jede Datei, aus der der NRT-Inhalt besteht, über die TOI- und content_location-Felder der FDT in der FLUTE-Sitzung. Jede TOI oder der Content-Location-Wert und der Inhalt bilden den content_ID-Wert der FDT auf das content_id-Feld der NCT oder das content_id-Feld der OMA BCAST SG ab, um den NRT-Inhalt zu bestätigen und zu empfangen.
  • 3 ist eine Ansicht einer Struktur eines Protokollstacks eines NRT-Dienstes nach einer Ausführungsform.
  • Für den festen NRT-Dienst wird der NRT-Dienst eines Dateiformats in eine IP-Schicht IP-paketiert und dann im MPEG-2 TS-Format über einen bestimmten Kanal übertragen.
  • Über eine Program Specific Information- (PSI) oder Program and System Information Protocol-Tabelle (PSIP) auf MPEG-2-Basis, beispielsweise eine VCT, wird festgestellt, ob in einem virtuellen Kanal ein NRT-Dienst vorhanden ist, und die Kennungsdaten des NRT-Dienstes werden signalisiert.
  • Gemäß einer Ausführungsform wird der NRT-Dienstsignalisierungskanal, der die Signalisierungsdaten des NST-Dienstes, die die Zugangsdaten des NRT-Dienstes auf IP-Basis signalisiert, in einen spezifischen IP-Strom der IP-Schicht paketiert und anschließend im MPEG-2 TS-Format übertragen.
  • Mit anderen Worten: Ein Sender paketiert den NRT-Inhalt oder -Dateien im FTP-Verfahren, wie in 3 gezeigt, und paketiert anschließend den paketierten NRT-Inhalt oder -Dateien im ALC- (Asynchronous Layered Coding) oder LCT-Verfahren (Layered Coding Transport). Dann werden die paketierten ALC- oder LCT-Daten im UDP-Verfahren paketiert. Dann werden die paketierten UDP-Daten nochmal im IP-Verfahren paketiert, und werden dann IP-Daten. Hier können die IP-Daten eine FDT (File Description Table) enthalten, die Daten über eine FLUTE-Sitzung (File Delivery over Unidrectional Transport) enthält. Die paketierten IP-Daten werden vorliegend u.U. der Vereinfachung halber als IP-Datagramm bezeichnet.
  • Außerdem wird das IP-Datagramm des NRT-Dienstes in eine adressierbare Abschnittstruktur verkapselt und nochmal in einem MPET-2 TS-Format paketiert. D.h., eine adressierbare Abschnittstruktur weist einen Kopf und eine CRC-Prüfsumme, die einem IP-Datagramm hinzugefügt werden. Das Format der adressierbaren Abschnittstruktur wird strukturell mit einem DSM-CC-Abschnittsformat (Digital Storage Media Command and Control) für private Datenübertragungen abgeglichen. Dementsprechend kann der adressierbare Abschnitt als DSM-CC-adressierbarer Abschnitt bezeichnet werden.
  • Außerdem können NRT-Dienstsignalisierungsdaten, insbesondere mindestens eine von SMT (oder NST) und NRT-IT (oder NCT), die zum Empfang von NRT-Inhalten/-Dateien erforderlich sind, über einen NRT-Dienstsignalisierungskanal auf einer IP-Schicht übertragen werden. Daher können die Signalisierungsdaten des NRT-Dienstes im IP-Verfahren paketiert werden, um sie über den Signalisierungskanal des NRT-Dienstes auf einer IP-Schicht zu übertragen. Der Signalisierungskanal des NRT-Dienstes wird ins IP-Datagramm, das eine allgemein bekannte IP-Adresse aufweist, verkapselt und gemäß einer Ausführungsform per Multicast übertragen.
  • Außerdem können die Signalisierungsdaten des NRT-Dienstes in die Abschnittsdaten von PSI- (Programm Specific Information) oder PSIP-Tabellen (Program and System Information Protocol) aufgenommen und dann übertragen werden. Außerdem kann die PSI-Tabelle eine PMT (Program Map Table) und eine PAT (Program Association Table) enthalten. Die PSIP-Tabelle kann eine VCT (Virtual Channel Table), eine TVCT (Terrestrial Virtual Channel Table), eine CVCT (Cable Virtual Channel Table), eine STT (System Time Table), eine RRT (Rating Region Table), eine ETT (Extended Text Table), eine DCCT (Direct Channel Change Table), eine DCCSCT (Direct Channel Change Selection Code Table), eine EIT (Event Information Table) und eine MGT (Master Guide Table) enthalten.
  • Ferner kann als Daten für die digitale Rechteverwaltung und Verschlüsselung von Rundfunkdiensten zum Schutz des NRT-Dienstes vor rechtswidriger Verteilung und Vervielfältigung die von der Open Mobile Alliance (OMA) vorgeschlagene BCAST DRM (BroadCast Services Enabler Suite Digital Rights Management) eingesetzt werden.
  • Außerdem können die oben erwähnten Abschnittsdaten der PSI- (Program Specific Information), PSIP- (Program and System Information Protocol) Tabellen, DSM-CC-adressierbaren Abschnittsdaten sowie OMA BCAST DRM-Daten in Einheiten von 184 Bytes eingeteilt; dann wird jeder 184-Byte-Einheit ein 4-Byte-MEPG-Kopf hinzugefügt, um ein aus 188 Bytes bestehendes MPEG-2 TS-Paket zu ergeben. Zu diesem Zeitpunkt handelt es sich bei einem der PID des MPEG-Kopfes zugewiesenen Wert um einen eindeutigen Wert, der in TS-Paket zur Übertragung des NRT-Dienstens und des Signalisierungskanals des NRT-Dienstes identifiziert.
  • MPEG-2 TS-Pakete können in einem vorbestimmten Übertragungsverfahrens, z.B. einem 8-VSB-Übertragungsverfahren, auf einer physischen Schicht moduliert werden und anschließend an ein Empfangssystem übertragen werden.
  • Ferner ist 4 eine Ansicht einer Struktur eines Protokollstacks eines NRT-Dienstes nach einer weiteren Ausführungsform.
  • 4 ist eine Ansicht eines Beispiels des Protokollstacks eines mobilen NRT-Dienstes. Wie in 4 gezeigt, wird zwischen einer IP-Schicht und einer physischen Schicht eine Anpassungsschicht angeordnet. Im Ergebnis können das IP-Datagramm der Mobildienstdaten und das IP-Datagramm der Signalisierungsdaten übertragen werden, ohne ein MPEG-2 TS-Format zu verwenden.
  • Mit anderen Worten: Ein Sender paketiert den NRT-Inhalt oder -Dateien im FTP-Verfahren, wie in 4 gezeigt, und paketiert sie anschließend im ALC-(Asynchronous Layered Coding)/LCT-Verfahren (Layered Coding Transport). Dann werden die paketierten ALC- oder LCT-Daten im UDP-Verfahren paketiert. Dann werden die paketierten ALC-/LCT-/UDP-Daten nochmal im IP-Verfahren paketiert, und werden dann ALC-/LCT-/UDP-/IP-Daten. Die paketierten ALC/LCT-/UDP-/IP-Daten werden vorliegend u.U. der Vereinfachung halber als IP-Datagramm bezeichnet. Zu diesem Zeitpunkt werden die OMA BCAST SG-Daten demselben Verfahren unterzogen wie der NRT-Inhalt/-Datei, um das IP-Datagramm aufzubauen.
  • Außerdem, wenn die zum Empfang des NRT-Inhalts/-Dateien erforderlichen Signalisierungsdaten eines NRT-Dienstes (z.B. SMT) über einen Signalisierungskanal eines Dienstes übertragen, wird der Signalisierungskanal des Dienstes im UDP-(User Datagram Protocol) Verfahren paketiert, und die paketierten UDP-Daten werden nochmal im IP-Verfahren paketiert, um UDP-/IP-Daten zu werden. Die UDP-/IP-Daten werden vorliegend u.U. der Vereinfachung halber als IP-Datagramm bezeichnet. Zugleich wird der Signalisierungskanal des NRT-Dienstes ins IP-Datagramm, das eine allgemein bekannte IP-Zieldresse sowie die allgemein anerkannte UDP-Zielportnummer aufweist, verkapselt und gemäß einer Ausführungsform per Multicast übertragen.
  • Außerdem werden in Bezug auf die OMA BCAST DRM zum Leistungsschutz ein UDP-Kopf und ein IP-Kopf sequenziell hinzugefügt, um ein IP-Datagramm zu bilden.
  • Das IP-Datagramm des NRT-Dienstes, der Signalisierungskanal des NRT-Dienstes und die Mobildienstdaten werden auf einer Anpassungsschicht gesammelt, um einen RS-Rahmen zu erzeugen. Der RS-Rahmen kann das IP-Datagramm der OMA BCAST SG enthalten.
  • Die Länge (d.h. die Reihenzahl) einer Spalte im RS-Rahmen wird auf 187 Bytes festgelegt, und die Länge (d.h. die Spaltenzahl) einer Reihe beträgt N Bytes (N kann je nach Signalisierungsdaten wie z.B. einem Übertragungsparameter für TPC_Daten variieren).
  • Der RS-Rahmen wird in einem vorbestimmten Übertragungsverfahrens, z.B. einem VSB-Übertragungsverfahren, auf einer physischen Schicht moduliert und anschließend an ein Empfangssystem übertragen.
  • Außerdem, ob der NRT-Dienst übertragen wird, wird über eine PSI-/PSIP-Tabelle signalisiert. Beispielsweise wird an die VCT oder TVCT signalisiert, ob der NRT-Dienst übertragen wird.
  • 5 ist eine Ansicht eines Abschnitts eines Bitstroms eines Abschnitts einer TVCT- (VCT) Tabelle nach einer Ausführungsform.
  • In 5 weist die TVCT Tabelle in einem Beispiel die Form eines privaten MPEG-2-Abschnitts auf, ist aber hierauf nicht beschränkt.
  • Wenn die VCT und PID des Audio/Video geparst und anschließend über die TVCT übertragen werden, können die PID-Daten (Paketkennung) ermittelt werden.
  • Daher enthält der TVCT-Tabellenabschnitt einen Kopf, einen Körper und einen Endsatz. Ein Kopfabschnitt kann ein table_id- oder protocol_version-Feld enthalten. Ein transport-stream_id-Feld ist ein 16-Bit-Feld und stellt eine MPEG-2 TS ID in einer von einem PID-Wert von 0 zu Multiplexzwecken definierten PAT (Program Association Table) der. Im Kopfteil ist ein num_channels_in_section-Feld ein 8-Bit-Feld und stellt die Anzahl virtueller Kanäle in einem VCT-Abschnitt dar. Letztens enthält ein Endsatzteil ein CRC_32-Feld.
  • Zunächst wird nachfolgend der Kopf beschrieben.
  • Ein table_id-Feld (8 Bit) wird auf 0xC8 eingestellt, und lässt erkennen, dass es sich bei einem entsprechenden Tabellenabschnitt um einen Abschnitt handelt, der eine TVCT darstellt.
  • Ein section_syntax_indicator-Feld (1 Bit) wird auf 1 eingestellt, und zeigt, dass der Abschnitt einer allgemeinen Abschnittsyntax folgt.
  • Ein private_indicator-Feld (1 Bit) wird auf 1 eingestellt.
  • Ein section_length-Feld (12 Bit) beschreibt die Anzahl der bis zum Abschnittsende verbleibenden Bits ab dem section_length-Feld. Der Wert des section_length-Feldes kann nicht höher als 1021 eingestellt werden.
  • Ein table_id_extension-Feld (16 Bit) kann auf 0x000 eingestellt werden.
  • Ein version_number Feld (5 Bit) kann 0 enthalten und stellt die Versionsnummer der VCT dar.
  • Ein current_next_indicator-Feld (1 Bit) zeigt, dass der entsprechende Tabellenabschnitt derzeit anwendbar ist, falls er auf 1 eingestellt ist.
  • Ein section_number Feld (8 Bit) stellt die Nummer des entsprechenden Tabellenabschnitts unter den TVCT-Abschnitten dar. In einem ersten Abschnitt der TVCT sollte section_number auf 0x00 eingestellt werden.
  • Ein last_section_number Feld (8 Bit) stellt den Tabellenabschnitt mit der letzten und höchsten Nummer unter den TVCT-Abschnitten dar.
  • Ein protocol_version-Feld (8 Bit) ist eine Funktion, die es ermöglicht, dass eine Tabellenart Parameter mit einer anderen Struktur liefert als diejenige, die in einem aktuellen Protokoll definiert wird. Heute ist 0 der einzig gültige protocol_version-Wert. Ein protocol_version-Feld mit einem anderen Wert als 0 kann für eine zukünftige Version der Norm verwendet werden, um eine andere Tabelle zu identifizieren, die eine andere Struktur aufweist.
  • Anschließend wird der Körper beschrieben.
  • Ein num_channels_in_section-Feld (8 Bit) stellt die Nummern der virtuellen Kanäle im VCT-Abschnitt dar. Die Nummern werden durch eine Tabellenabschnittslänge eingeschränkt.
  • Ein short_name-Feld (16 Bit) stellt mittels eines sequenziellen 16-Bit-Codewertes von 1 bis 7 den Namen des virtuellen Kanals dar.
  • Ein major_channel_number-Feld (10 Bit) stellt eine Hauptkanalnummer dar, die mit einem durch Wiederholung in einer Zählschleife definierten virtuellen Kanal in Verbindung steht. Jeder virtuelle Kanal sollte mit einer Haupt- und Nebenkanalnummer in Verbindung stehen. Die Hauptkanalnummer fungiert zusammen mit der Nebenkanalnummer als Referenznummer eines virtuellen Kanals eines Benutzers.
  • Ein minor_channel_number-Feld (10 Bit) stellt Neben- oder Subkanalnummern im Bereich von 0 bis 999 dar. Deses Feld fungiert zusammen mit major_channel_number als zweites der Zahl oder einer Kanalnummer eines zweiten Teils, die den rechten Teil darstellt. Das minor_channel_number-Feld wird auf 0 eingestellt, sofern es beim service_type um Analogfernsehen handelt. Handelt es sich beim service_type um ATSC_digital_television oder ATSC_audio_only, wird eine Nebenzahl im Bereich von 1 bis 99 verwendet. Ein minor_channel_number-Wert überlappt sich in einer TVCT nicht mit dem major_channel_number-Wert.
  • Ein modulation_mode-Feld (8 Bit) stellt einen Modulationsmodus eines mit einem virtuellen Kanal in Verbindung stehenden Trägers dar.
  • Ein carrier_frequency-Feld (32 Bit) weist einen Empfehlungswert von 0 auf. Obwohl das Feld zur Identifizierung einer Trägerfrequenz verwendet wird, wird dies nicht empfohlen.
  • Ein channel_TSID-Feld (16 Bit) ist ein vorzeichenloses Ganzzahlfeld, das eine mit einem ein MPEG-2-Programm enthaltenden TS in Verbindung stehende MPEG-2 TS ID darstellt, d.h. eine Referenz eines virtuellen Kanals im Bereich von 0x0000 bis 0xFFFF.
  • Ein program_number-Feld (16 Bit) identifiziert eine vorzeichenlose Ganzzahl, die mit einem in einer PAT eines MPEG-2-Programms und einer PMT eines TS-Programms definierten virtuellen Kanal in Verbindung steht. Ein virtueller Kanal, der einem Analogdienst entspricht, enthält als program_number 0xFFFF.
  • Ein ETM_location-Feld (2 bit) beschreibt die Existenz und den Standort einer erweiterten Textnachricht (Extended Text Message - ETM).
  • Ein access_controlled-Feld (1 Bit) weist darauf hin, dass der Zugriff auf Ereignisse, die mit einem virtuellen Kanal in Verbindung stehen, kontrolliert wird, sobald es eingestellt wird. Ist die Fahne auf 0 eingestellt, ist der Zugriff auf ein Ereignis nicht eingeschränkt.
  • Ein hidden-Feld (1 Bit) weist darauf hin, dass ein Benutzer auf einen virtuellen Kanal nicht durch direkte Eingabe einer virtuellen Kanalnummer zugreifen kann, sobald es eingestellt wird. Ein verborgener virtueller Kanal wird weggelassen, wenn sich ein Benutzer durch die Kanäle zappt, und wird angezeigt, wenn der Benutzer auf die undefinierte oder direkte Kanaleingabe zugreift. Ein typischer Anwendungsbereich eines verborgenen Kanals ist Testsignal- und NVOD-Dienst. Der verborgene Kanal und dessen Ereignisse können je nach Status eines hide_guide-Bits auf einer EPG-Anzeige angezeigt werden.
  • Ein hidden_guide-Feld ermöglicht, dass ein virtueller Kanal und dessen Ereignisse auf einer EPG-Anzeige angezeigt werden, sobald es mit 0 für einen verborgenen Kanal eingestellt wird. Das Bit steht mit keinem Kanal in Verbindung, der kein verborgenes Bitset aufweist, also werden nicht verborgene Kanäle und deren Ereignisse ohne Rücksicht auf den Status eines hide_guide-Bits auf einer EPG-Anzeige stets angezeigt. Ein typischer Anwendungsbereich eines verborgenen Kanals, in dem ein hidden_guide-Bitset auf 1 eingestellt ist, ist ein Testsignal und ein Dienst, die über einen Zeiger auf Anwendungsebene leicht erhältlich sind.
  • Ein service_type-Feld (6 Bit) stellt eine über einen virtuellen Kanal übertragene Dienstart dar. 6 und 7 sind Ansichten, die veranschaulichen, wie ein Wert eines service_type-Feldes nach einer Ausführungsform zu definieren ist. Gemäß einer Ausführungsform heißt ein in 6 dargestellter service_type-Wert (z.B. 0x04, dass service_type ATSC_data_only_service ist, und NRT-Dienst über einen virtuellen Kanal übertragen wird. Gemäß einer weiteren Ausführungsform heißt ein in 7 dargestellter service_type-Wert (z.B. 0x08, dass service_type ATSC_nrt_service ist, und ein virtueller Kanal einen ATSC-konformen NRT-Dienst bereitstellt.
  • Ein source_id-Feld (16 Bit) stellt die Quelle eines mit einem virtuellen Kanal in Verbindung stehenden Programms dar.
  • Ein descriptors_length-Feld stellt die Gesamtlänge (Byteeinheit) eines Deskriptors des nachfolgenden virtuellen Kanals dar.
  • Ein descriptor()-Feld enthält mindestens null Deskriptoren.
  • Ein additional_descriptors_length-Feld stellt die Gesamtlänge (Byteeinheit) des nachfolgenden VCT-Deskriptors dar.
  • Letztlich ist in CRC_32-Feld in Bezug auf den Endsatz ein 32-Bit-Feld, und enthält einen CRC-Wert (Cyclic Redundancy Check - zyklische Blockprüfung), der dafür sorgt, dass keine Ausgabe von Registern eines in einem MPEG-2-System definierten Decoders nach der Verarbeitung eines ganzen STT-Abschnitts erfolgt.
  • 8 ist eine Ansicht eines data_service_table_section)-Feldes zur Kennzeichnung einer Anwendung der NRT-Dienst- und Bitstrom-Syntax des data_service_table_bytes-Feldes eines DST-Abschnitts. Die ATSC-konformen NRT-Dienstdaten oder NRT-Dienstsignalisierungsdaten eines Senders können über den DST-Tabellenabschnitt der 8 übertragen werden.
  • Im Nachfolgenden ist die Semantik der Felder, die eine data_service_table_section-Struktur enthalten, wie folgt.
  • Ein table_id-Feld (8 Bit) als Feld für die Typkennung eines entsprechenden Tabellenabschnitts ist ein Tabellenabschnitt, in dem ein entsprechender Tabellenabschnitt durch dieses Feld DST darstellt. Beispielsweise erkennt ein Empfangsgerät, dass es sich bei einem entsprechenden Tabellenabschnitt um einen Tabellenabschnitt handelt, der DST darstellt, sofern ein Wert des Feldes 0xCF ist.
  • Ein section_syntax_indicator-Feld (1 Bit) definiert ein Abschnittsformat der DST, und das Abschnittsformat kann z.B. die MPEG-Kurzsyntax sein.
  • Ein private_indicator-Feld (1 Bit) lässt erkennen, ob das Format eines entsprechenden Abschnitts einem privaten Abschnittsformat folgt, und kann auf 1 eingestellt werden.
  • Ein private_section_length-Feld (12 Bit) stellt eine nach einem entsprechenden Feld verbleibende Tabellenabschnittslänge dar. Außerdem übersteigt kein Wert dieses Feldes 0xFFD.
  • Ein table_id_extension-Feld (16 Bit) hängt von einer Tabelle ab, und kann ein logischer Teil eines table_id-Feldes sein, der einen Bereich der übrigen Felder identifiziert.
  • Ein version_number Feld (5 Bit) stellt die Versionsnummer der DST dar.
  • Ein current_next_indicator-Feld (1 Bit) lässt erkennen, ob ein übertragener DST-Tabellenabschnitt derzeit anwendbar ist. Beträgt der Feldwert 0, heißt dies, dass noch keine Tabelle vorliegt und die nächste Tabelle gültig ist.
  • Ein section_number-Feld (8 Bit) stellt eine Abschnittsnummer in Abschnitten dar, in denen ein entsprechender Tabellenabschnitt eine DST-Tabelle darstellt. section_number des ersten Abschnitts in einer DST ist auf 0x00 eingestellt. Der section_number-Wert wird mit zunehmender DST-Abschnittsnummer um eins erhöht.
  • Ein last_section_number-Feld (8 Bit) stellt die letzte Abschnittsnummer dar, die eine DST-Tabelle darstellt, d.h. die höchste Abschnittsnummer.
  • data_service_table_bytes stellt einen Datenblock dar, der eine DST ist; dessen Struktur wird nachfolgend ausführlich beschrieben.
  • Ein CRC_32-Feld ist ein 32-Bit-Feld, und enthält einen CRC-Wert (Cyclic Redundancy Check - zyklische Blockprüfung), der dafür sorgt, dass keine Ausgabe von Registern eines in einem MPEG-2-System definierten Decoders nach der Verarbeitung eines ganzen DST-Abschnitts erfolgt.
  • Im Nachfolgenden ist die Semantik der Felder, die eine data_service_table_bytes-Struktur enthalten, wie folgt.
  • Ein sdf_protocol_version-Feld (8 Bit) beschreibt die Version eines SDF-Protokolls (Service Description Framework).
  • Ein application_count_insection-Feld (8 Bit) stellt die Anzahl der in einem DST-Abschnitt aufgeführten Anwendungen dar.
  • Ein compatibility_descriptor()-Feld lässt erkennen, dass eine entsprechende Struktur einen DSM-CC-kompatiblen Deskriptor enthält. Dessen Zweck besteht darin, kompatible Anforderungen einer Anwendung auf einer Empfangsplattform zu signalisieren, um einen entsprechenden Datendienst zu verwenden, nachdem dessen Eignung festgestellt worden ist.
  • Ein app_id_byte_length-Feld (16 Bit) beschreibt die Anzahl der zur Identifikation einer Anwendung verwendeten Bytes.
  • Ein app_id_description-Feld (16 Bit) beschreibt das Format und die Semantik der nachfolgenden Anwendungskennungsbytes. Beispielsweise kann ein app_id_description-Wert wie in der Tabelle 1 beschrieben werden. [Tabelle 1]
    Wert Applikationsidentifizierungsformat
    0x0000 DASE application
    0x0001-0x7FFF ATSC reserved
    0x8000-0xFFFF User private
  • Ein app_id_byte-Feld (8 Bit) stellt ein Byte einer Anwendungskennung dar.
  • Ein tap_count-Feld (8 Bit) beschreibt die Anzahl der für die entsprechende Anwendung verwendeten Tap()-Strukturen.
  • Ein protocol_encapsulation-Feld (8 Bit) beschreibt eine zur Übertragung eines von einem Tap()-Feld erwähnten konkreten Datenelements verwendete Protokoll-Verkapselungsart. Ein Wert des protocol_encapsulation-Feldes wird der Tabelle 2 entsprechend definiert.
    Wert Verkapseltes Protokoll
    0x00 Not in a MPEG-2 Transport Stream
    0x01 Asynchronous non-flow controlled scenario of the DSM-CC Download protocol encapsulated in DSM-CC sections
    0x02 Non-streaming Synchronized Download protocol encapsulated in DSM-CC sections
    0x03 Asynchronous multiprotocol datagrams in Addressable Sections using LLC/SNAP header
    0x04 Asynchronous IP datagrams in Addressable Sections
    0x05 Syncrhronized streaming data encapsulated in PES
    0x06 Synchronous streaming data encapsulated in PES
    0x07 Synchronized streaming multiprotocol datagrams in PES using LLC/SNAP header
    0x08 Synchronous streaming multiprotocol datagrams in PES using LLC/SNAP header
    0x09 Synchronized streaming IP datagrams in PES
    0x0A Synchronous streaming IP datagrams in PES
    0x0B Proprietary Data Piping
    0x0C SCTE DVS 051 asynchronous protocol [19]
    0x0D Asynchronous carousel scenario of the DSM-CC Download protocol encapsulated in DSM-CC sections
    0x0E Reserved for harmonization with another standard body
    0x0F-0x7F ATSC reserved
    0x80-0xFF User defined
  • Ein action_type-Feld (7 Bit) stellt ein von einem Tap() erwähntes Datenattribut dar.
  • Ein resource_location-Feld (1 Bit) beschreibt einen Standort eines association_tag-Feldes, das einem in der nächsten Tap-Struktur aufgeführten association_tag-Wert entspricht. Ist ein entsprechendes Feld auf 0 eingestellt, existiert association_tag in einer PMT eines aktuellen MPEG-2-Programms. So existiert ein entsprechendes association_tag-Feld im DSM-CC-Ressourcendeskriptor in einer NRT (Network Resources Table) eines entsprechenden Datendienstes, wenn das entsprechende Feld auf 1 eingestellt ist.
  • Ein Tap()-Feld kann Daten über die Suche nach einem Datenelement eines Anwendungszustandes in einem Kommunikationskanal einer unteren Schicht enthalten. Ein association_tag-Feld in einem Tap()-Feld kann Daten über Entsprechungen zwischen Datenelementen eines Anwendungszustandes enthalten. Ein Wert eines association_tag-Feldes in einer Tap-Struktur entspricht einem Wert eines association_tag-Feldes eines Association Tag-Deskriptors in einer aktuellen PMT. Beispielsweise kann ein Tap()-Feld eine spezifische Struktur, insbesondere die Felder der Tabelle 3, aufweisen. [Tabelle 3]
    Syntax bit Anzahl Format
    Tap () {
    tap_id 16 uimsbf
    use 16 uimsbf
    association_tag 16 uimsbf
    selector()
    }
  • Ein tap_id-Feld (16 Bit) wird von einer Anwendung verwendet, um Datenelemente zu identifizieren. Ein tap_id-Wert liegt in einem von den Werten der mit Tap() in Verbindung stehenden ap_id_byte-Felder in DST Bereich. Ein tap_id-Wert wird von einem Datendienstanbieter ausgewählt. Außerdem kann der tap_id-Wert zur Behandlung eines Datenelements durch eine Anwendung verwendet werden.
  • Ein Use-Feld (16 Bit) wird verwendet, um einen von association_tag erwähnten Kommunikationskanal zu identifizieren.
  • Ein association_tag-Feld (16 Bit) identifiziert eindeutig entweder einen in einer NRT aufgeführten DSM-CC-Resourcendeskriptor oder einen in einer PMT aufgeführten Elementar-Datenstrom. Ein Wert eines entsprechenden Feldes kann mit einem association_tag-Wert von association_tag_descriptor identisch sein.
  • Ein Selector()-Feld beschreibt ein konkretes Datenelement, das in einem vom association_tag-Feld erwähnten Kommunikationskanal oder Elementar-Datenstrom verfügbar ist. Außerdem kann die Selector-Struktur auf ein für ein entsprechendes Datenelement erforderliches Protokoll hinweisen.
  • Ein tap_info_length-Feld (16 Bit) beschreibt die Anzahl der Bytes der Deskriptoren in dem nächsten eines entsprechenden Feldes.
  • Ein descriptor()-Feld kann Deskriptordaten gemäß einem entsprechenden Deskriptorformat enthalten.
  • Ein app_info_length-Feld (8 Bit) beschreibt die Anzahl der Bytes der nächsten Deskriptoren eines entsprechenden Feldes.
  • Ein descriptor()-Feld kann Deskriptordaten gemäß einem entsprechenden Deskriptorformat enthalten.
  • Ein app_data_length-Feld (16 Bit) beschreibt die Länge einer Byteeinheit aus app_data_byte-Feldern.
  • Ein app_data_byte-Feld (8 Bit) stellt die mit Anwendungs- und sonstigen privaten Datenfeldern in Verbindung stehenden Eingabeparameter in 1 Byte dar.
  • Ein service_info_length-Feld (8 Bit) beschreibt die Anzahl der Byteeinheiten des nächsten Deskriptors.
  • Ein descriptor()-Feld kann Deskriptordaten gemäß einem entsprechenden Deskriptorformat enthalten.
  • Ein service_private_data_length-Feld (16 Bit) beschreibt die Länge einer Byteeinheit in privaten Feldern.
  • Ein service_private_data_byte-Feld (8 Bit) stellt ein privates Feld in 1 Byte dar.
  • 9 ist eine Ansicht eines Verfahrens zum Empfang und zur Übertragung eines NRT-Dienstes in einer Empfangsanlage unter Einsatz der Norm ATSC A/90 zur Übertragung von Datenströmen sowie der Norm ATSC A/92 zur Übertragung eines IP-Multicast-Stroms.
  • Mit anderen Worten: Daten über den Strom, aus dem jeder virtuelle Kanal besteht, werden dem service_location_descriptor der VCT oder dem ES_loop der PMT signalisiert. Beispielsweise, wie in 7 oder 8 gezeigt, ist die VCT-Dienstart 0x02 (d.h. digitale A/V-Daten), 0x04 (d.h. nur Daten) oder 0x08 (d.h. nur NRT-Dienst), kann der NRT-Dienststrom auf den virtuellen Kanal übertragen werden. Wenn zu diesem Zeitpunkt 0x95 (d.h. DST-Übertragung) einem stream_type-Feldwert in einem Dienststandortdeskriptor (oder ES_loop einer PMT) zugewiesen wird, heißt dies, dass der Inhalt übertragen wird. Weist der stream_type-Feldwert keinen Wert auf, oder ist er nicht 0x05, wird nur typisches A/V gesendet. Das heißt: Wenn der stream_type-Feldwert im Dienststandortdeskriptor 0x05 enthält, ist ein Elementary_PID-Feldwert zu diesem Zeitpunkt ein PID-Wert einer DST (Data Service Table). Daher kann die DST über Elementary_PID empfangen werden.
  • Über die DST sind Anwendungsarten sowie detaillierte Daten über Datensendeströme, die über den Kanal gesendet werden, erhältlich. Mit der DST wird die NRT-Anwendung (d.h. NRT-Dienst) identifiziert.
  • D.h. das app_id_description-Feld der DST definiert das Format und die Interpretation der nachfolgenden Anwendungskennungsbytes. Gemäß einer Ausführungsform wird 0x0003 dem App_id_description-Feld zugewiesen, um die NRT-Anwendung zu identifizieren. Der oben erwähnte Zahlenwert ist nur ein Beispiel, und ist keineswegs als Einschränkung des Schutzumfangs der vorliegenden Erfindung aufzufassen.
  • Ist der App_id_description-Feldwert 0x0003, wird der nachfolgende Application_id_byte-Wert ein Service ID-Wert der NRT-Anwendung. Eine Service ID der NRT-Anwendung kann einen URI-Wert aufweisen, der einen entsprechenden Dienst weltweit eindeutig identifiziert.
  • Nach der Identifizierung der NRT-Anwendung wird die PID eines vom IP-Datagramm eines Signalisierungskanals eines NRT-Dienstes getrennten MPEG-2 TS-Pakets über die Tap-Daten durchsucht. Dann ist ein IP-Datagram, das einen Signalisierungskanal eines NRT-Dienstes sendet, aus den MPEG-2 TS-Paketen erhältlich, die eine über die Tap-Daten erhaltene PID aufweisen, und die Signalisierungsdaten des NRT-Dienstes sind dem derart erhaltenen IP-Datagramm zu entnehmen. Zu diesem Zeitpunkt kann es sich bei den IP-Zugangsdaten des Signalisierungskanals des NRT-Dienstes um allgemein bekannte IP-Zugangsdaten, d.h. eine allgemein bekannte IP-Adresse und eine allgemein bekannte UDP-Portnummer, handeln.
  • Mit anderen Worten: Wenn der Protocol_encapsulation-Feldwert in der DST 0x04 ist, wird ein asynchroner IP-Strom übertragen, und wenn der Selector_type-Feldwert 0x0102 ist, kann ein device_id-Wert, aus dem die Zieladresse hervorgeht, über selector_bytes gesendet werden. multiprotocol_encapsulation_descriptor wird zur präzisen Interpretation des selector_bytes-Wertes verwendet, und die Anzahl der gültigen Bytes im device_id-Wert wird signalisiert. Hieraus ergibt sich durch die Tap-Daten eine IP-Multicast-Adresse (oder - Adressenbereich) des Signalisierungskanals des NRT-Dienstes, die an die entsprechende PID übertragen wird.
  • Demnach greift ein Empfangsgerät auf die Multicast-Adresse (oder - Adressenbereich) zu, um den IP-Strom, d.h. IP-Paket, zu empfangen, und entnimmt dann die Signalisierungsdaten des NRT-Dienstes dem erhaltenen IP-Paket.
  • Dann empfängt das Empfangsgerät NRT-Dienstdaten, d.h. NRT-Inhalte/- Dateien, um diese auf der Grundlage der entnommenen Signalisierungsdaten des NRT-Dienstes in einem Speichermedium zu speichern oder auf einer Anzeigevorrichtung anzuzeigen.
  • Gemäß einer weiteren Ausführungsform kann ein stream-type-Feldwert einer DST statt 0x95 ein neues 0x96 aufweisen, um den NRT-Dienst zu signalisieren. Dies liegt daran, dass eine Störung des NRT-Dienstes, d.h. einer neuen Anwendung, auftreten kann, wenn ein typisches Empfangsgerät nur auf der Grundlage des Vorliegens eines Stromtyps von 0x95 feststellt, ob ein Datensendestrom vorliegt. In diesem Fall kann ein typisches Empfangsgerät dies bei der Neubezeichnung eines Stroms außer Acht lassen, um die Rückwärtskompatibilität zu gewährleisten.
  • 10 und 11 sind Ansichten eines Verfahrens zum Empfang eines NRT-Dienstes mittels DSM-CC-adressierbarer Abschnittsdaten gemäß einer weiteren Ausführungsform.
  • Ein Datenübertragungsverfahren mittels DST stellt die Norm zur Übertragung von IP-Datagrammen aller Arten über digitale Sendeströme dar, und kann für den NRT-Dienst ineffizient sein. So zeigen 1 und 10 ein Verfahren zum Empfang des NRT-Dienstes mittels Signalisierung der PID eines konkreten Stroms, der IP-Adressendaten und Abschnittsdaten des IP-Datagramms hinsichtlich des NRT-Dienstes enthält, über die Daten des DSM-CC-adressierbaren Abschnitts.
  • Wie in 10 gezeigt, kann das Empfangsgerät Daten empfangen, wonach der Strom des NRT-Dienstes über den virtuellen Kanal übertragen wird, wenn eine Dienstart der VCT (oder TVCT) 0x08 (d.h. nur NRT-Dienst) ist. D.h., das Empfangsgerät kann durch Abbildung der PID eines virtuellen Kanals auf eine Kanalnummer Daten darüber erhalten, ob den service_type-Daten zufolge ein NRT-Dienst vorliegt.
  • Wenn zu diesem Zeitpunkt 0x0D einem stream_type-Feldwert in einem Dienststandortdeskriptor einer VCT (oder ES_loop einer PMT) zugewiesen wird, heißt dies, dass der DSM-CC-Strom übertragen wird. Ein Elementary_PID-Feldwert kann zu diesem Zeitpunkt der PID-Wert eines DSM-CC-adressierbaren Abschnitts sein. Dementsprechend empfängt das Empfangsgerät über Elementary_PID einen DSM-CC-adressierbaren Abschnitt, der NRT-Dienstdaten enthält.
  • D.h., das Empfangsgerät kann die PID des DSM-CC-adressierbaren Abschnitts über VCT oder PMT erhalten. Hier kann das Empfangsgerät ein NRT_IP_address_list_descriptor_A()-Feld erhalten, das eine IP-Adresse eines Signalisierungskanals eines NRT_dienstes oder eine IP-Adresse der FLUTE-Sitzung zur Übertragung von NRT-Dienstdaten enthält, das der der PMT des entsprechenden Stroms entnommenen PID entspricht.
  • Außerdem kann das EMpfangsgerät DSM-CC-adressierbare Abschnittsdaten vom IP-Multicast-Stream oder dem IP-Subnetz auf der Grundlage der einem NRT_IP_address_list_descriptor_A()-Feld entnommenen IP-Adresse empfangen. Das Empfangsgerät kann durch Durchsuchen eines DSM-CC-adressierbaren Abschnitts mit einer der den empfangenen DMS-CC-adressierbaren Abschnittsdaten entnommenen PID ein entsprechendes IP-Datagramm erhalten, das konkrete NRT-Dienstdaten (z.B. A, B oder C) enthält.
  • 11 ist eine Ansicht eines Verfahrens zur Signalisierung von DSM-CC-adressierbaren Abschnittsdaten mit VCT gemäß einer weiteren Ausführungsform.
  • Wie oben erwähnt, kann das Empfangsgerät Daten erhalten, dass der NRT-Dienststrom übertragen werden kann, wenn ein service_type in der VCT 0x02, 0x04 oder 0x08 ist. Außerdem kann das Empfangsgerät eine elementary_PID mit einem Stromtyp von 0x0D dem service_location_descriptor()-Feld entnehmen, um den DSM-CC-Strom zu empfangen. Hier kann das Empfangsgerät ein NRT_IP_address_list_descriptor_B()-Feld erhalten, das eine IP-Adresse eines Signalisierungskanals eines NRT_dienstes oder eine IP-Adresse der FLUTE-Sitzung zur Übertragung von NRT-Dienstdaten enthält, das der entnommenen elementary_PID entspricht.
  • Außerdem kann das Empfangsgerät DSM-CC-adressierbare Abschnittsdaten vom IP-Multicast-Stream oder dem IP-Subnetz auf der Grundlage der einem NRT_IP_address_list_descriptor_B()-Feld entnommenen IP-Adresse empfangen. Das Empfangsgerät kann durch Parsen des DSM-CC-adressierbaren Abschnitts mit einer der empfangenen elementary_PID entsprechenden PID den empfangenen DSM-CC-adressierbaren Abschnittsdaten das IP-Datagramm entnehmen, das den gewünschten NRT-Dienst (z.B. A, B oder C) enthält.
  • Die Verfahren zum Extrahieren der Signalisierungsdaten des NRT-Dienstes sowie die NRT-Dienstdaten werden nachfolgend beschrieben. Hier wird 0x08 dem Wert des service_type-Feldes in VCT zugewiesen, und weist darauf hin, dass mindestens ein NRT-Dienst an einen entsprechenden virtuellen Kanal übertragen wird.
  • Mit anderen Worten, wenn das Empfangsgerät eingeschaltet und ein Kanal per Werkseinstellungen oder durch einen Benutzer mittels eines Tuners ausgewählt wird, entnimmt der Handler des PSI-/PSIP-Abschnitts einem über den ausgewählten Kanal empfangenen Signal die VCT und PMT. Ebenfalls parst der Handler des PSI-/PSIP-Abschnitts die entnommene VCT, um zu bestätigen, ob ein NRT-Dienst vorliegt. Dies wird durch Überprüfen des service_type_Feldwertes in einer virtuellen Schleife der VCT bestätigt. Wenn z.B. der service_type-Feldwert nicht 0x08 ist, wird durch den entsprechenden virtuellen Kanal kein NRT-Dienst übertragen. Zu diesem Zeitpunkt funktioniert das Empfangsgerät aufgrund der im virtuellen Kanal enthaltenen Daten bestimmungsgemäß, da der virtuelle Kanal einen bestehenden Dienst (d.h. ATSC-Legacy-Dienst) sendet.
  • Wenn außerdem in Bezug auf einen Demultiplexer ein service_type-Feldwert aufgrund einer Kontrolle eines Servicemanagers 0x08 ist, wird durch einen entsprechenden virtuellen Kanal ein NRT-Dienst gesendet. In diesem Fall wird die PID der DST durch Parsen eines Dienststandortsdeskriptors in einer virtuellen Kanalschleife der VCT extrahiert. Außerdem wird mittels der extrahierten PID die DST empfangen.
  • Darüber hinaus bestätigt das Empfangsgerät, ob ein über einen aus der empfangenen DST gelieferter Dienst ein NRT-Dienst ist.
  • Der NRT-Dienst wird aufgrund eines App_id_description-Feldwertes bestätigt.
  • Gemäß einer Ausführungsform wird 0x0003 dem App_id_description-Feld zugewiesen, um die NRT-Anwendung zu identifizieren. Der oben erwähnte Zahlenwert ist nur ein Beispiel, und ist keineswegs als Einschränkung des Schutzumfangs der vorliegenden Erfindung aufzufassen.
  • Ist der App_id_description-Feldwert in der DST 0x0003, wird der nachfolgende Application_id_byte-Wert ein Service ID-Wert der NRT-Anwendung (d.h. NRT-Dienst). Deshalb extrahiert der Servicemanager oder der PSI-/PSIP-Abschnittshandler Tap() der PID eines vom IP-Datagramm des Signalisierungskanals des NRT-Dienstes getrennten MPEG-2 TS-Pakets, nachdem die NRT-Anwendung (d.h. NRT-Dienst) erkannt worden ist. Dann wird der PMT die Stream-PID entnommen, die den association_tag-Wert der extrahierten Tap enthält.
  • Außerdem kann der adressierbare Abschnittshandler nach dem Empfang von MPEG-2 TS-Paketen, die der extrahierten Stream-PID entsprechen, durch Entfernung der Entkapselung, d.h. eines MPEG-2-Kopfes, den DSM-CC-adressierbaren Abschnitt erhalten.
  • Dann entnimmt das Empfangsgerät das IP-Datagramm, das einen Signalisierungskanal eines NRT-Dienstes sendet, durch Entfernung eines Abschnittskopfes und einer CRC-Prüfsumme vom DSM-CC-adressierbaren Abschnitt, und entnimmt so die Signalisierungsdaten des NRT-Dienstes dem erhaltenen IP-Datagramm. Hier handelt es sich bei den Zugangsdaten des IP-Datagramms, das den Signalisierungskanal des NRT-Dienstes sendet, um eine allgemein bekannte Ziel-IP-Adresse und eine allgemein bekannte UDP-Portnummer.
  • Mit anderen Worten: Wenn der Protocol_encapsulation-Feldwert in der DST 0x04 ist, wird ein asynchroner IP-Strom übertragen, und wenn der Selector_type-Feldwert 0x0102 ist, kann ein device_id-Wert, aus dem die Zieladresse hervorgeht, über selector_bytes gesendet werden. multiprotocol_encapsulation_descriptor wird zur präzisen Interpretation des selector_bytes-Wertes verwendet, und die Anzahl der gültigen Bytes im device_id-Wert wird signalisiert. Hieraus ergibt sich durch die Tap-Daten eine IP-Multicast-Adresse (oder - Adressenbereich) des Signalisierungskanals des NRT-Dienstes, die an die entsprechende PID übertragen wird.
  • Demnach greift ein Empfangsgerät auf die Multicast-Adresse (oder - Adressenbereich) zu, um den IP-Strom, d.h. IP-Paket, zu empfangen, und entnimmt dann die Signalisierungsdaten des NRT-Dienstes dem erhaltenen IP-Paket.
  • Das Empfangsgerät empfängt NRT-Dienstdaten, d.h. NRT-Inhalte/- Dateien, um diese auf der Grundlage der entnommenen Signalisierungsdaten des NRT-Dienstes in einem Speichermedium zu speichern oder auf einer Anzeigevorrichtung anzuzeigen.
  • Außerdem kann der NRT-Dienst gemäß einer Ausführungsform mit einem DCD-Dienst (Dynamic Content Delivery) versehen werden. Beim DCD-Dienst handelt es sich um einen Dienst zur Sendung von Inhalten an ein Empfangsgerät entweder in regelmäßigen Abständen oder auf Anforderung eines Benutzers; dabei werden die Inhalten aufgrund der Empfängerdaten aus einem Server gewählt. Der DCD-Dienst unterstützt eine Punkt-zu-Punkt-Methode sowie eine Sendemethode in einem Kommunikationsmittel zur Lieferung von Inhalten, und der oben erwähnte NRT-Dienst wird nach einer OMA BCAST-Methode und einer der Sendemethoden des DCD-Dienstes übertragen.
  • Die NRT-Dienstdaten können über den DCD-Dienst der OMA BCAST-Methode gesendet werden. In diesem Fall kann das Empfangsgerät die DCD-Kanaldaten erhalten, um den NRT-Dienst zu empfangen, und kann den NRT-Dienst aufgrund der DCD-Kanaldaten über einen entsprechenden DCD-Kanal empfangen.
  • Außerdem können die DCD-Kanaldaten in die NST aufgenommen und übertragen werden. Beispielsweise empfängt das Empfangsgerät die NST und erhält die DCD-Kanaldaten über das DCD-Ladeprogramm.
  • Außerdem kann die NST Metadaten des DCD-Kanals erhalten, die über einen DCD-Verwaltungskanal zur Signalisierung der DCD-Kanaldaten empfangen werden. Dementsprechend kann das Empfangsgerät zum Empfang eines NRT-Dienstes und von Metadaten Daten über einen Kanal durch die NST erhalten.
  • Folglich greift das Empfangsgerät über NST auf den DCD-Kanal zu, ohne dass die Signalisierungsdaten des NRT-Dienstes übertragen werden, und empfängt dann den NRT-Dienst, wenn eine NST übertragen wird, die DCD-Kanaldaten enthält.
  • So ist es in mehreren Hinsichten vorteilhaft, dass die NST Metadaten eines Kanals zum Empfang von NRT-Diensten enthält.
  • Zunächst kann die Zugangsgeschwindigkeit des Dienstes durch Empfang der Kanalmetadaten erhöht werden, die den NRT-Dienst direkt von der NST empfangen, ohne die Signalisierungsdaten des NRT-Dienstes aufgrund der Dienstart eines virtuellen Kanals zu empfangen.
  • Außerdem können Aktualisierungen einer Kanalwechseleinheit in einer Sendeumgebung in Echtzeit signalisiert werden.
  • Außerdem können Zugangsdaten in OMA BCAST SG durch Bezugnahme auf NST erhalten werden. Beispielsweise empfängt das Empfangsgerät die Metadaten des DCD-Kanals aufgrund der DCD-Kanaldaten in der NST, und erhält die Zugangsdaten, um den NRT-Dienst aufgrund der von der NST erhaltenen Signalisierungsdaten des NRT-Dienstes und der DCD-Kanalmetadaten zu empfangen.
  • Letztens kann eine mit einem anderen virtuellen Kanal in Verbindung stehende NST, die eine Liste von NRT-Diensteinheiten enthält, übertragen werden. Folglich können Listendaten des NRT-Dienstes über einen Signalisierungskanal eines spezifischen NRT-Dienstes nicht auf einer PSI- oder PSIP-Schicht, sondern auf einer IP-Schicht übertragen werden. Folglich kann in diesem Fall die Rückwärtskompatibilität auf PSI oder PSIP vorbehalten werden.
  • Wie oben erwähnt, können außerdem die DCD-Kanaldaten, insbesondere auch die DCD-Kanalmetadaten, in den Zugangsdaten der SG in OMA BCAST enthalten sein, und die Zugangsdaten entsprechen der NRT-Dienstdaten in NST. Im Einzelnen kann das Empfangsgerät in NST die NRT-Dienstdaten von einem Zugangsfragment von OMA BCAST SG erhalten. So kann das Empfangsgerät Daten über den Empfang des NRT-Dienstes durch Empfangen der den erhaltenen NRT-Dienstdaten entsprechenden NST erhalten.
  • Außerdem kann der über den DCD-Kanal übertragene NRT-Dienst nach zugewiesener Dienstkategorie eingeteilt werden. Beispielsweise kann die Dienstkategorie des über den DCD-Kanal übertragenen NRT-Dienstes durch 0x0F gekennzeichnet werden.
  • 12 und 13 sind Ansichten einer Bitstromsyntax von NST nach einer Ausführungsform.
  • Hier wird die entsprechende Syntax zum besseren Verständnis in einem privaten MPEG-2-Abschnittsformat erzeugt; das Format der entsprechenden Daten kann jedoch variieren. Beispielsweise können die entsprechenden Daten nach einer weiteren Methode in einem SDP-Format (Session Description Protocol) ausgedrückt und über ein SAP (Session Announcement Protocol) signalisiert werden.
  • Die NST beschreibt die Dienst- und IP-Zugangsdaten in einem virtuellen Kanal zur Übertragung von NST, und liefert die NRT-Sendestromdaten eines entsprechenden Dienstes mittels einer Kennung des NRT-Sendestroms, d.h. NRT_service_id, in jedem Dienst. Ferner beschreibt die NST die Beschreibungsdaten jedes festen NRT-Dienstes in einem virtuellen Kanal, und ein Deskriptorbereich kann weitere Daten enthalten.
  • Ein table_id-Feld (8 Bit) als Feld für die Typkennung eines entsprechenden Tabellenabschnitts ist ein Tabellenabschnitt, in dem ein entsprechender Tabellenabschnitt durch dieses Feld NST darstellt.
  • Ein section_syntax_indicator-Feld (1 Bit) definiert ein Abschnittsformat der NST, und das Abschnittsformat kann z.B. die MPEG-Kurzsyntax sein.
  • Ein private_indicator-Feld (1 Bit) lässt erkennen, ob das Format eines entsprechenden Abschnitts einem privaten Abschnittsformat folgt, und kann auf 1 eingestellt werden.
  • Ein section_length-Feld (12 Bit) stellt eine nach einem entsprechenden Feld verbleibende Tabellenabschnittslänge dar. Außerdem übersteigt kein Wert dieses Feldes 0xFFD.
  • Ein table_id_extension-Feld (16 Bit) hängt von einer Tabelle ab, und kann ein logischer Teil eines table_id-Feldes sein, der einen Bereich der übrigen Felder identifiziert. Hier enthält ein table_id_extension-Feld ein NST_protocol_version-Feld.
  • Das NST_protocol_version-Feld (8 Bit) zeigt eine Protokollversion zur Mitteilung, dass die NST Parameter mit einer anderen Struktur liefert als diejenige, die in einem aktuellen Protokoll definiert wird. Aktuell beträgt der Wert dieses Feldes 0. Wird der Feldwert später anders als mit 0 gekennzeichnet, gilt dies einer Tabelle mit einer anderen Struktur.
  • Ein version_number Feld (5 Bit) stellt die Versionsnummer der NST dar.
  • Ein current_next_indicator-Feld (1 Bit) lässt erkennen, ob ein übertragener NST-Tabellenabschnitt derzeit anwendbar ist. Beträgt der Feldwert 0, heißt dies, dass noch keine Tabelle vorliegt und die nächste Tabelle gültig ist.
  • Ein section_number-Feld (8 Bit) stellt eine Abschnittsnummer in Abschnitten dar, in denen ein entsprechender Tabellenabschnitt eine NST-Tabelle darstellt.
  • section_number des ersten Abschnitts in einer NST (NRT Service Table) ist auf 0x00 eingestellt. Der section_number-Wert wird mit zunehmender NST-Abschnittsnummer um eins erhöht.
  • Ein last_section_number-Feld (8 Bit) stellt die letzte Abschnittsnummer dar, die eine NST-Tabelle darstellt, d.h. die höchste Abschnittsnummer. (Höchstes section_number)
  • Ein carrier_frequency-Feld (32 Bit) teilt eine Sendefrequenz mit, die einem Kanal entspricht.
  • Ein channel_TSID-Feld (16 Bit) ist eine eindeutige Kanalkennung eines Sendestroms, in dem ein entsprechender NST-Abschnitt derzeit gesendet wird.
  • Ein program_number-Feld (16 Bit) stellt die Nummer eines mit einem virtuellen Kanal in Verbindung stehenden Programms dar.
  • Ein source_id-Feld (16 Bit) stellt die Quelle eines mit einem virtuellen Kanal in Verbindung stehenden Programms dar.
  • Ein num_NRT_services-Feld (8 Bit) stellt die Anzahl der in einem NST-Abschnitt enthaltenen NRT-Dienste dar.
  • Außerdem liefert die NST Daten über eine Mehrzahl fester NRT-Dienste mittels einer Zählschleife. Danach kann jeder feste NRT-Dienst mit denselben Felddaten versehen werden.
  • Ein NRT_service_status-Feld (2 Bit) kennzeichnet einen Zustand eines entsprechenden mobilen Dienstes. Hier lässt die MSB erkennen, ob ein entsprechender mobiler Dienst aktiv (1) oder inaktiv (0) ist, und ob der entsprechende mobile Dienst verborgen (1) ist oder nicht (0). Hier wird ein Zustand des entsprechenden NRT-Dienstes identifiziert, wenn der mobile Dienst ein NRT-Dienst ist. Verborgene Dienste werden hauptsächlich für exklusive Anwendungen verwendet; von einem typischen Empfangsgerät werden sie nicht berücksichtigt.
  • Ein SP_indicator-Feld (1 Bit) ist ein Feld, aus dem der Leistungsschutz hervorgeht, sofern der auf mindestens eine der zur sinnvollen Darstellung eines entsprechenden mobilen Dienstes anwendbare Leistungsschutz erforderlichen Komponenten eingestellt ist.
  • Ein CP_indicator-Feld (1 Bit) lässt erkennen, ob der Inhaltsschutz eines entsprechenden NRT-Dienstes eingestellt ist. Beträgt der CP_indicator-Feldwert 1, so heißt dies, dass der Inhaltsschutz auf mindestens eine der zur sinnvollen Darstellung eines entsprechenden mobilen Dienstes erforderlichen Komponente angewendet wird.
  • Ein NRT_service_id-Feld (16 Bit) ist eine eindeutige Kennung eines entsprechenden NRT-Dienstes in einem Bereich einer entsprechenden NRT-Sendung. Der NRT_service_id-Wert wird während des entsprechenden Dienstes nicht verändert. Wenn hier der Dienst eingestellt wird, kann ein NRT_service_id des Dienstes bis zum Ablauf einer entsprechenden Zeit für keinen anderen Dienst verwendet werden, um Verwechselungen zu vermeiden.
  • Ein Short_NRT_service_name-Feld (8*8 Bit) zeigt einen Kurznamen des NRT-Dienstes. Wenn kein Kurzname des NRT-Dienstes vorhanden ist, kann das Feld mit einem Nullwert (z.B. 0x00) eingefüllt werden.
  • Ein NRT_service_category-Feld (6 Bit) kennzeichnet eine Dienstart im entsprechenden NRT-Dienst.
  • Ein num_components-Feld (5 Bit) zeigt die Anzahl der IP-Stromkomponenten im NRT-Dienst.
  • Wenn ein IP_version_flag-Feld (1 Bit) auf 0 eingestellt ist, bedeutet dies, dass ein source_IP_address-Feld, ein NRT_service_destination_IP_address-Feld und ein component_destination_IP_address-Feld IPv4-Adressen sind. Wenn ein source_IP_address-Feld auf 1 eingestellt ist, sind ein NRT_service_destination_IP_address-Feld und ein component_destination_IP_address-Feld IPv4-Adressen.
  • Ein source_IP_address_flag-Feld (1 Bit) lässt erkennen, ob eine Fahne gesetzt ist, dass ein Quellen-IP-Adressenwert für den entsprechenden NRT-Dienst auf ein quellenspezifisches Multicast hinweist.
  • Ist eine Fahne auf 1 gesetzt, so lässt ein NRT_service_destination_IP_address_flag-Feld (1 Bit) erkennen, dass ein NRT_service_destination_IP_address-Feld für Komponenten eines entsprechenden NRT-Dienstes eine Standard-IP-Adresse bereitstellt.
  • In Bezug auf ein source_IP_address-Feld (128 Bit) ist ein entsprechendes Feld vorhanden, sofern source_IP_address_flag auf 1 gesetzt ist; es liegt aber kein entsprechendes Feld vor, wenn es auf 0 gesetzt ist. Existiert ein entsprechendes Feld, enthält das entsprechende Feld eine Quellen-IP-Adresse aller Sendekomponente des IP-Datagramms des entsprechenden NRT-Dienstes. Die eingeschränkte Verwendung einer 128 Bit langen Adresse eines entsprechenden Feldes ist für die zukünftige Verwendung durch IPv6 bestimmt, das aber derzeit keine Verwendung findet. Source_IP_address wird zur Quellen-IP-Adresse desselben Servers, der alle Kanäle einer FLUTE-Sitzung sendet.
  • In Bezug auf ein NRT_service_destination_IP_address-Feld (128 Bit) ist ein source_IP_address-Feld vorhanden, sofern source_IP_address_flag auf 1 gesetzt ist; es liegt aber kein entsprechendes source_IP_address-Feld vor, wenn es auf 0 gesetzt ist. Liegt kein entsprechendes source_IP_address-Feld vor, existiert ein component_destination_IP_address-Feld für jede Komponente in einer num_components-Schleife. Die eingeschränkte Verwendung einer 128 Bit langen Adresse eines source_IP_address-Feldes ist für die zukünftige Verwendung durch IPv6 bestimmt, das aber derzeit keine Verwendung findet. NRT_service_destination_IP_Address wird signalisiert, sofern eine Ziel-IP-Adresse einer Sitzungsebene der FLUTE-Sitzung vorliegt.
  • Außerdem liefert die NST Daten über eine Mehrzahl Komponenten mittels einer Zählschleife. Ist ein Wert eines entsprechenden Wertes auf 1 gesetzt, so lässt ein essential_component_indicator-Feld (1 Bit) erkennen, dass es sich bei einer entsprechenden Komponente um eine für den NRT-Dienst erforderliche Komponente handelt. Andernfalls handelt es sich bei der entsprechenden Komponente um eine ausgewählte Komponente.
  • Ein port_num_count-Feld (6 Bit) zeigt die Nummern der UDP-Ports, die mit einer entsprechenden UDP-/IP-Stromkomponente in Verbindung stehen. Werte der Ziel-UDP-Portnummern werden ab einem Wert des component_destination_UDP-port_num-Feldes um eins erhöht.
  • Ist component_destination_IP_address_flag-Feld (1 Bit) auf 1 gesetzt, heißt dies, dass für eine entsprechende Komponente ein component_destination_IP_address-Feld vorliegt.
  • In Bezug auf ein component_destination_IP_address-Feld (128 Bit) ist ein entsprechendes Feld vorhanden, sofern component_destination_IP_address_flag auf 1 gesetzt ist; es liegt aber kein entsprechendes Feld vor, wenn component_destination_IP_address_flag auf 0 gesetzt ist. Existiert ein entsprechendes Feld, enthält das entsprechende Feld eine Quellen-IP-Adresse aller Sendekomponente des IP-Datagramms des entsprechenden NRT-Dienstes. Die eingeschränkte Verwendung einer 128 Bit langen Adresse eines entsprechenden Feldes ist für die zukünftige Verwendung durch IPv6 bestimmt, das aber derzeit keine Verwendung findet.
  • Ein component_destination_UDP_port_num-Feld (16 Bit) zeigt die Nummer eines Ziel-UDP-Ports einer entsprechenden UDP-/IP-Stromkomponente.
  • Ein num_component_level_descriptors-Feld (4 Bit) zeigt die Nummern der Deskriptoren, die zusätzliche Daten über eine entsprechende IP-Stromkomponente liefern.
  • Ein component_level_descriptors-Feld identifiziert mindestens einen Deskriptor, der zusätzliche Daten über eine entsprechende IP-Stromkomponente liefert.
  • Ein num_NRT_service_level_descriptors-Feld (4 Bit) stellt die Anzahl der NRT-Service-Level-Deskriptoren eines entsprechenden Dienstes dar.
  • NRT_service_level_descriptor() identifiziert keinen oder mindestens einen Deskriptor, der zusätzliche Daten über einen entsprechenden NRT-Dienst liefert. Hier kann für den NRT-Dienst ein entsprechender Diensttyp bereitgestellt werden. Der spezifische Diensttyp enthält einen Portaldienst, der Web-Inhalte, Push-VOD und A/V-Download anbietet.
  • Ein num_virtual_channel_level_descriptors-Feld (4 Bit) beschreibt die Anzahl der virtuellen Channel-Level-Deskriptoren eines entsprechenden virtuellen Kanals dar.
  • virtual_channel_level_descriptor() ist ein Deskriptor, der zusätzliche Daten über einen von einer entsprechenden NST beschriebenen virtuellen Kanal liefert.
  • Außerdem wird der NRT-Dienst über FLUTE übertragen, und Zugangsdaten über die NST-Tabelle stehen auf die nachfolgende Weise mit den FLUTE-Sitzungsdaten in Verbindung.
  • Source_IP_address ist eine Quellen-IP-Adresse desselben Servers, der alle Kanäle der FLUTE-Sitzung sendet.
  • NRT_service_destination_IP_Address wird signalisiert, sofern eine Ziel-IP-Adresse einer Sitzungsebene der FLUTE-Sitzung vorliegt.
  • Eine Komponente kann auf einen Kanal in der FLUTE-Sitzung abgebildet werden, und eine zusätzliche Ziel-IP-Adresse (die sich von einer durch die Sitzung signalisierten IP-Adresse unterscheidet) wird in jedem Kanal über component_destination_IP_address signalisiert.
  • Außerdem wird eine Ziel-Portnummer durch component_destination_UDP_port_num signalisiert, und die Anzahl der Zielports ab component_description_UDP_port_num kann außerdem durch port_num_count vorgegeben werden.
  • Eine Mehrzahl Kanäle kann durch Vorgabe einer Mehrzahl Ports für eine Ziel-IP-Adresse konfiguriert werden. Hier kennzeichnet eine Komponente eine Mehrzahl Kanäle. Es ist jedoch generell wünschenswert, einen Kanal über eine Ziel-IP-Adresse zu identifizieren. Typischerweise wird jedoch ein Kanal auf eine Komponente abgebildet.
  • Inhalte/Dateien für den NRT-Dienst werden über FLUTE übertragen, und die entsprechenden FLUTE-Sitzungsdaten werden mittels Zugangsdaten auf der NST-Tabelle signalisiert.
  • 14 ist eine Ansicht der Bitstromsyntax eines NRT_component_descriptor (MH_component_descriptor)-Feldes nach einer Ausführungsform.
  • NRT_component_descriptor() wird in einer component_descriptor-Schleife in jeder Komponente jedes NRT-Dienstes in der NST gezeigt. Dann entsprechen alle Parameter in einem entsprechenden Deskriptor den für Komponenten eines NRT-Dienstes verwendeten Parametern.
  • Nachfolgend werden alle über das NRT_component_descriptor der 14 übertragenen Daten beschrieben.
  • Ein component_type-Feld (7 Bit) identifiziert ein Codierungsformat einer Komponente. Der Kennungswert kann einer der dem payload_type eines RTP-/AVP-Stroms zugewiesenen Werte sein. Außerdem kann der Kennungswert ein dynamischer Wert im Bereich von 96 bis 127 sein. Die Werte des Feldes für Komponenten, die per RTP übertragene Medien darstellen, sind identisch mit denjenigen im payload_type eines RTP-Kopfes des IP-Stroms, der eine entsprechende Komponente sendet.
  • Ein zusätzlicher Wert eines component_type-Feldes im Bereich von 43 bis 71 wird in der zukünftigen Fassung der Norm definiert. Wird der NRT-Dienststrom aufgrund von FLUTE übertragen, kann 38 (das für eine FLUTE-Komponente in ATSC definierte component_type) oder 43 (d.h. ein unbesetzter Wert) kann als component_type der neuen NRT-Sendung definiert und verwendet werden.
  • Ein num_STKM_streams-Feld (8 Bit) identifiziert die Nummern der STKM-Ströme, die mit einer entsprechenden Komponente in Verbindung steht.
  • Ein STKM_stream_id-Feld (8 Bit) identifiziert den STKM-Strom, der Schlüssel zur Entschlüsselung der erhaltenen entsprechenden geschützten Komponente enthält. Hier wird auf das STKM_stream_id-Feld im Komponentendeskriptor des STKM-Stroms Bezug genommen.
  • Ein NRT_component_data (component_type)-Feld liefert mindestens einen zum Ausdrücken einer entsprechenden Komponente erforderlichen Parameter sowie andere Parameter. Hier bestimmt sich eine Struktur eines NRT_component_data-Elements nach einem Wert eines component_type-Feldes.
  • Eine FDT (File Delivery Table) von FLUTE-Sitzungen wird zur Lieferung von Listen aller Inhalte verwendet, und enthält Größen, Datentypen sowie sonstige Daten über damit verbundene Inhalte, um die Inhalte zu erhalten.
  • Folglich werden erfindungsgemäß Daten zum Zugriff auf die FLUTE-Sitzung, die einen entsprechenden Inhalt sendet, mittels NST erhalten, um einen mittels NRT-IT erhaltenen ausgewählten Inhalt von SG zu erhalten. Außerdem werden Daten erfindungsgemäß in einer Datei, die über eine entsprechende FLUTE-Sitzung übertragen wird, auf Daten eines NRT-IT-Inhalts abgebildet. In diesem Fall wird die Kennung des Dienstes, der den entsprechenden Inhalt enthält, über das NRT_service_id der NST aufgelöst.
  • Der NRT-Dienst wird über FLUTE übertragen, und Zugangsdaten über die NST-Tabelle stehen auf die nachfolgende Weise mit den FLUTE-Sitzungsdaten in Verbindung.
  • Source_IP_address ist eine Quellen-IP-Adresse desselben Servers, der alle Kanäle der FLUTE-Sitzung sendet.
  • NRT_service_destination_IP_Address wird signalisiert, sofern eine Ziel-IP-Adresse einer Sitzungsebene der FLUTE-Sitzung vorliegt.
  • Eine Komponente kann auf einen Kanal in der FLUTE-Sitzung abgebildet werden, und eine zusätzliche Ziel-IP-Adresse (die sich von einer durch die Sitzung signalisierten IP-Adresse unterscheidet) wird in jedem Kanal über component_destination_IP_address signalisiert. Außerdem wird eine Ziel-Portnummer durch component_destination_UDP_port_num signalisiert, und die Anzahl der Zielports ab component_description_UDP_port_num kann außerdem durch port_num_count vorgegeben werden.
  • Eine Mehrzahl Kanäle kann dadurch einer Ziel-IP-Adresse zugewiesen werden, dass eine Mehrzahl Ports gekennzeichnet wird; in diesem Fall kennzeichnet eine Komponente eine Mehrzahl Kanäle. Es wird jedoch empfohlen, einen Kanal anhand einer Ziel-IP-Adresse zu differenzieren; in diesem Fall wird auf eine Komponente ein Kanal abgebildet.
  • component_attribute_byte kann zur Signalisierung eines zusätzlichen Attributs einer Komponente, aus der eine Sitzung besteht, verwendet werden. Hierdurch können zusätzliche Parameter signalisiert werden, die zur Signalisierung einer FLUTE-Sitzung erforderlich sind.
  • In dieser Hinsicht sind Parameter zur Signalisierung der FLUTE-Sitzung erforderlich; diese enthalten die unbedingt erforderlichen Parameter sowie wahlweise erforderliche Parameter, die mit einer entsprechenden FLUTE-Sitzung in Verbindung stehen. Zu den unbedingt erforderlichen Parametern gehören zunächst einmal Parameter wie z.B. eine Quellen-IP-Adresse, die Anzahl Kanäle in der Sitzung, die Ziel-IP-Adresse und die Portnummer jedes Kanals in der Sitzung, die TSI (Transport Session Identifier) der Sitzung sowie die Start- und Endzeit der Sitzung. Zu den wahlweisen Parametern, die mit einer entsprechenden FLUTE-Sitzung in Verbindung stehen, gehören Parameter wie z.B. FEC OTI (Object Transmission Information) sowie die Daten die dem Empfangsgerät erst mitteilen, dass die Sitzung interessierende Dateien enthält, und die Bandbreitenvorgabe.
  • Die Anzahl der Kanäle in der Sitzung kann ausdrücklich festgelegt werden, oder durch Addierung der Anzahl der Ströme, aus denen die Sitzung besteht, ermittelt werden. Über die NST und component_descriptor können Parameter wie z.B. eine Start- und Endzeit der Sitzung, eine Quellen-IP-Adresse, die Ziel-IP-Adresse und die Portnummer jedes Kanals in der Sitzung, die TSI (Transport Session Identifier) der Sitzung sowie die Anzahl der Kanäle in der Sitzung signalisiert werden.
  • 15 ist eine Ansicht der Bitstromsyntax eines NRT_component_descriptor-Feldes nach einer Ausführungsform, das NRT_component_data enthält.
  • Ein NRT-Dienst kann in mehreren FLUTE-Sitzungen enthalten sein. Jede Sitzung kann je nach IP-Adressen und Port der Sitzung mittels mindestens eines NRT-Komponentendeskriptors signalisiert werden.
  • Nachfolgend wird jedes NRT_component_data-Feld beschrieben.
  • Ein TSI-Feld (16 Bit) stellt die TSI einer FLUTE-Sitzung dar.
  • Ein session_start_time-Feld zeigt eine Startzeit der FLUTE-Sitzung. Wenn alle Werte der entsprechenden Felder 0 sind, heißt dies, dass eine Sitzung bereits läuft.
  • Ein session_end_time-Feld zeigt eine Endzeit der FLUTE-Sitzung. Wenn alle Werte der entsprechenden Felder 0 sind, heißt dies, dass eine Sitzung endlos weiterläuft.
  • Aus einem tias_bandwidth_indicator-Feld (1 Bit) gehen Fahnen hervor, die TIAS-Bandbreitendaten (Transport Independent Application Specific) enthalten. Geht daraus hervor, dass das TIAS-Bandbreitenfeld existiert, wird ein entsprechendes Bit auf 1 eingestellt; geht daraus hervor, dass das TIAS-Bandbreitenfeld nicht existiert, wird das entprechende Bit auf 0 eingestellt.
  • Aus einem as_bandwidth_indicator-Feld (1 Bit) gehen Fahnen hervor, die AS-Bandbreitendaten (Application Specific) enthalten. Geht daraus hervor, dass das AS-Bandbreitenfeld existiert, wird ein entsprechendes Bit auf 1 eingestellt; geht daraus hervor, dass das AS-Bandbreitenfeld nicht existiert, wird das entsprechende Bit auf 0 eingestellt.
  • Ein FEC_OTI_indicator-Feld (1 Bit) lässt erkennen, ob FEC-OTI bereitgestellt wird.
  • Ein tias_bandwidth-Feld zeigt eine TIAS-Höchstbandbreite.
  • Ein as_bandwidth-Feld enthält eine AS-Höchstbandbreite.
  • Ein FEC_encoding_id-Feld zeigt die in der entsprechenden FLUTE-Sitzung verwendete FEC-Codierungskennung.
  • Ein FEC_instance_id-Feld zeigt die in der entsprechenden FLUTE-Sitzung verwendete FEC-Instanzenkennung.
  • Bereitgestellt wird ein Verfahren zur Bereitstellung aller zum Empfang der FLUTE-Sitzung erforderlichen Daten durch Signalisieren derselben Parameter wie oben mittels Flute-Komponenten-Datenbytes sowie zum Empfang der Dateien durch Empfang von Daten über alle über die FLUTE-Sitzung, die über die Sitzung erhaltene FDT verwendet gelieferten Dateien.
  • Dieser FLUTE-Komponentendeskriptor kann über eine Component_level_descriptor-Schleife der NST geliefert werden. Liegt eine Mehrzahl FLUTE-Kanäle vor, kann ein FLUTE-Komponentendeskriptor nur in einer der Komponenten der mehreren Kanäle über eine Component_level_descriptor-Schleife übertragen werden, da TSI und session_start_time, session_end_time, d.h. Parameter auf Sitzungsebene, einmal signalisiert werden sollten.
  • 16 ist eine Ansicht der Bitstromsyntax eines NRT-IT-Abschnitts zur Signalisierung einer NRT-Anwendung nach einer Ausführungsform.
  • Die aus der NRT-IT zur Verfügung gestellten Daten können einen Inhaltstitel (beispielsweise den Namen eines herunterladbaren Programms), die Dauer, für die der Inhalt zum Herunterladen zur Verfügung steht, Inhaltshinweise, Verfügbarkeit von Untertiteln, Inhaltskennungen und sonstige Metadaten enthalten. Ein Inhalt kann mindestens eine Datei enthalten. Beispielsweise kann ein Audio-/Video-Clip in einem zur Anzeige auf einem Bildschirm verwendeten JPEG-Vorschaubild wiedergegeben werden.
  • Eine NRT-IT-Instanz kann Daten enthalten, die einem willkürlich vorbestimmten Zeitraum entsprechen, oder aber sie kann einen NRT-Inhalt beschreiben, der zu einem vorbestimmten Zeitpunkt beginnt und zu einem unbestimmten zukünftigen Zeitpunkt endet. Jede NRT-IT zeigt eine Startzeit und eine Dauer, die unbestimmt sein kann. Jede NRT-IT-Instanz kann in 256 Abschnitte eingeteilt werden. Jeder Abschnitt enthält Daten über eine Mehrzahl Inhalte. Daten eines konkreten Inhalts können nicht in mindestens zwei Abschnitte eingeteilt noch gespeichert werden.
  • Der herunterladbare Inhalt, der sich über einen längeren Zeitraum erstreckt als die Dauer mindestens einer NRT-IT-Instanz, ist der erste der NRT-It. Die Inhaltsbeschreibung wird nach Verfügbarkeit in NRT_information_table_section() gespeichert. Wenn also ein Wert von last_section_Number größer 0 ist (d.h. NRT-IT wird an eine Mehrzahl Sitzungen gesendet), können alle Inhaltsbeschreibungen in einem anderen konkreten Abschnitts als der erste Abschnitt dieselbe oder eine höhere Verfügbarkeit aufweisen als die Inhaltsbeschreibung des nachfolgenden Abschnitts.
  • Jede NRT-IT identifiziert einen mit einem konkreten Wert eines gültigen service_id in Verbindung stehenden NRT-Dienst in einem konkreten virtuellen Kanal in dem Zeitraum.
  • Ein table_id-Feld (8 Bit) wird auf 0xTBD eingestellt, und lässt erkennen, dass es sich bei einem entsprechenden Tabellenabschnitt um einen Abschnitt handelt, der eine NRT-IT darstellt.
  • Ein service_id-Feld (16 Bit) beschreibt ein mit einem NRT-Dienst in Verbindung stehendes service_id-Feld, das einen vom Abschnitt beschriebenen Inhalt zeigt.
  • Ein NRT_IT_version_number-Feld (5 Bit) wird als Menge in mindestens einem NRT_content_table_section() definiert, das einen hinsichtlich von service_id, current_next_indicator, protocol_version und time_span_start-Feldern gemeinsamen Wert aufweist. Dadurch wird eine Versionsnummer einer NRT-IT-Instanz identifiziert. Die Versionsnummer wird um 1 Modulo 32 erhöht, wenn ein Feld einer NRT-Instanz verändert wird.
  • Ein current_next_indicator-Feld (1 Bit) zeigt, dass der entsprechende Tabellenabschnitt derzeit anwendbar ist, falls er auf 1 eingestellt ist.
  • Ein protocol_version-Feld (8 Bit) wird auf 0 eingestellt. Eine Funktion von protocol_version ermöglicht einen zukünftigen Tabellentyp mit Parametern, die eine andere Struktur aufweisen als diejenigen, die im aktuellen Protokoll definiert sind. Heute ist 0 der einzig gültige protocol_version-Wert. Ein anderer Wert als 0 im protocol_version-Feld wird zur Kennzeichnung anderer Tabellen mit anderen Strukturen in der zukünftigen Fassung der Norm verwendet.
  • Ein time_span_start-Feld (32 Bit) stellt eine Startzeit einer in GPS sec ausgedrückten Instanzdauer von 00:00:00 UTC, 6. Januar 1980 dar. Eine Uhrzeit in time_span_start wird auf 00 Min der Uhrzeit eingestellt. Ein Wert 0 in time_span_start entspricht einer Dauer einer NRT-IT-Instanz ab einer negativen Vergangenheit. Ein time_span-Wert ist in jedem Abschnitt einer NRT-IT-Instanz aus mehreren Abschnitten identisch. Werte von time_span_start und time_span_length sind derart eingestellt, dass sie sich nicht mit einer anderen NRT-IT-Instanz eines IP-Subnetzes in einer vorgegebenen Dauer überlappen.
  • Ein time_span_length-Feld (11 Bit) identifiziert eine Anzahl Min ab der in time_span_start vorgegebenen Zeit, die von der Instanz abgedeckt ist. Sobald dieser Wert eingestellt wird, ändert sich der time_span_length-Wert nicht in einem time_span_start-Wert. Ist ein time_span_length-Wert gleich 0, deckt eine NRT-IT-Instanz einen ganzen Zeitraum ab time_span_start in der unbestimmten Zukunft ab. Ist ein time_span_start-Wert gleich 0, hat time_span_length keine Bedeutung.
  • Ein time_span_start-Wert ist in jedem Abschnitt einer NRT-IT-Instanz aus mehreren Abschnitten identisch. Werte von time_span_start und time_span_length sind derart eingestellt, dass sie sich nicht mit einer anderen NRT-IT-Instanz eines IP-Subnetzes in einer vorgegebenen Dauer überlappen.
  • Ein num_items_in_section-Feld (8 Bit) stellt die Anzahl der in einem NRT-IT-Abschnitt beschriebenen Inhalte dar.
  • Ein content_linkage-Feld (16 Bit) stellt eine Identifikationsnummer in einem Bereich von 0x0001 bis 0xFFFF dar. 0x0000 wird nicht verwendet. content_linkage ist eine Verknüpfungsfunktion für zwei: Dadurch wird mindestens eine mit dem NRT-Dienst in Verbindung stehende Datei der FLUTE FDT mit den Metadaten der NRT-IT verknüpft und TF_id ausgebildet (Kennung für TF [Text Fragment] in TFT [Text Fragment Table)]). Ein Wert eines content_linkage-Feldes entspricht einem Wert eines FDTContent-Linkage-Elements oder einem Wert eines FCL-Elements (File Content Linkage) in der FLUTE FDT jeder mit einem Inhalt in Verbindung stehenden Datei. Eine Prioritätsregel wird dann angewendet, wenn jeder Inhaltsverknüpfungswert in FLUTE FTD, zu dem ein entsprechendes Inhaltsverknüpfungselement gehört, abgeglichen wird.
  • Eine TF_available-Fahne (boolesche Fahne) wird auf 1 gesetzt, wenn TF in einer TFT eines Signalisierungskanals eines Dienstes vorliegt. Ist Text Fragment in einem Signalisierungsdienst eines Kanals des Inhalts nicht enthalten, wird ein Wert des TF_available-Feldes auf 0 eingestellt.
  • Wird eine low_latency-Fahne (boolesche Fahne) auf 1 eingestellt, während ein Benutzer wartet, ist der Inhalt in einer aktuellen digitalen Übertragung mit hinreichend kurzer Verzögerungsdauer gültig, in der ein Erfassungsversuch erfolgt. Ist sie auf 0 eingestellt, wird eine Erfassungs-Verzögerungsdauer verlängert, und eine Benutzeroberfläche schlägt einem Benutzer eine Post View vor.
  • Ein playback_length_in_seconds (20 Bit) ist eine Ganzzahl, die eine Wiedergabedauer eines Inhalts in Sekunden darstellt. Ein Inhalt, der Texte und/oder Standbilder enthält, weist einen Wert gleich 0 auf. In Bezug auf einen Inhalt, der Audio- oder Audio-/Video-Inhalte enthält, stellt playback_length_in_sections eine Wiedergabedauer des Audio- oder Audio-/Video-Inhalts dar.
  • Ist eine content_length_included-Fahne (boolesche Fahne) auf 1 eingestellt, existiert ein content_length-Feld in der Wiederholung einer Zählschleife. Ist sie auf 0 eingestellt, geht daraus hervor, dass das content_length-Feld in der Wiederholung einer Zählschleife nicht existiert.
  • Ist eine playback_delay_included-Fahne (boolesche Fahne) auf 1 eingestellt, existiert ein playback_delay-Feld in der Wiederholung einer Zählschleife. Ist sie auf 0 eingestellt, geht daraus hervor, dass das playback_delay-Feld in der Wiederholung einer Zählschleife nicht existiert.
  • Ist eine expiration_included-Fahne (boolesche Fahne) auf 1 eingestellt, existiert ein expiration-Feld in der Wiederholung einer Zählschleife. Ist sie auf 0 eingestellt, geht daraus hervor, dass das expiration-Feld in der Wiederholung einer Zählschleife nicht existiert.
  • Ein duration-Feld (12 Bit) stellt eine erwartete Zykluszeit eines Karussells, das einen erwähnten Inhalt enthält, in einem Bereich von 1 bis 2880 Min dar. Ein Empfangsgerät verwendet einen duration-parameter zur Ermittlung der Erfassungsdauer des erwähnten Inhalts.
  • playback_delay (20 Bit) wird mit einer Nummer des nächsten sec des ersten Bytes vor der Wiedergabe eines damit verbundenen Inhalts während der Pufferung des eingehenden Stroms ausgedrückt. Ein Wert von 0 heißt, dass die Wiedergabe sofort beginnt. Ist kein playback_delay eingestellt, erfasst ein Empfangsgerät vor der Wiedergabe eine ganze Datei oder Datei.
  • Ein expiration-Feld (32 Bit) stellt eine Endzeit in GPS sec von 00:00:00 UTC, 6. Januar 1980 dar. Nach dem Ablauf wird der Inhalt aus dem Speicher gelöscht. Ist der Inhalt nicht abgelaufen, wendet das Empfangsgerät ein von einem Speicherressourcenverwaltungsunternehmen ausgewähltes Verfahren an.
  • Ein content_name_length-Feld (8 Bit) stellt die Länge (Byteeinheit) von content_name_text dar.
  • Ein content_name_text()-Feld stellt einen Inhaltstitel in einem System dar, das eine Mehrzahl Stringstrukturen aufweist.
  • Ein content_descriptors_length-Feld (12 Bit) stellt eine ganze Länge (Byteeinheit) von content_descriptor dar, das auf Inhaltsebene zusätzliche Daten liefert.
  • content_descriptor ist ein Deskriptor, der auf jeden Inhalt zusätzlich angewendet wird.
  • descriptor_length (10 Bit) stellt eine ganze Länge (Byteeinheit) eines Deskriptors dar.
  • Ein Deskriptor wird generell auf alle im aktuellen NRT-IT-Abschnitt beschriebenen Inhalte angewendet.
  • 17 ist eine Ansicht einer Syntaxstruktur eines Bitstroms des NRT-Abschnitts (NRT_component_table_section) nach einer Ausführungsform. Es folgt eine ausführliche Beschreibung jedes Feldes des NCT-Abschnitts.
  • In 17 enthält ein table_id-Feld (8 Bit) als Kennung einer Tabelle eine Kennung, die die NCT identifiziert.
  • Ein section_syntax_indicator-Feld (1 Bit) definiert ein Abschnittsformat der NCT.
  • Ein private_indicator-Feld (1 Bit) lässt erkennen, ob die NCT einem privaten Abschnitt folgt.
  • Ein section_length-Feld (12 Bit) stellt die Abschnittslänge der NST dar.
  • Ein NRT_channel_id-Feld (16 Bit) stellt einen Wert dar, der einen NRT-Dienst, der einen in der NCT beschriebenen Inhalt enthält, eindeutig identifiziert.
  • Ein version_number Feld (5 Bit) stellt die Versionsnummer der NCT dar.
  • Ein current_next_indicator-Feld (1 Bit) lässt erkennen, ob Daten in einem entsprechenden NCT derzeit anwendbar sind oder in Zukunft anwendbar sein werden.
  • Ein section_number Feld (8 Bit) stellt die Abschnittsnummer eines aktuellen NCT-Abschnitts dar.
  • Ein last_section_number Feld (8 Bit) stellt die letzte Abschnittsnummer der NCT dar.
  • Ein protocol_version-Feld (8 Bit) zeigt eine Protokollversion, die die NCT zulässt, die NST Parameter mit anderen Strukturen sendet als diejenigen, die in einem aktuellen Protokoll definiert werden. (Ein vorzeichenloses 8-Bit-Ganzzahlfeld, dessen Aufgabe es ist, dieser NRT-Inhaltstabelle in Zukunft zu ermöglichen, Parameter zu enthalten, die anders strukturiert sind als diejenigen, die im aktuellen Protokoll definiert werden. Derzeit beträgt der protocol_version-Wert 0. protocol_version-Werte ungleich Null können von einer zukünftigen Version dieser Norm verwendet werden, um strukturell andersartige Tabellen zu kennzeichnen.)
  • Ein num_contents_in_section-Feld (8 Bit) zeigt die Anzahl der Inhalte in der NCT. Zu diesem Zeitpunkt stellt die Anzahl der Inhalte die Anzahl der über einen durch source_id vorgegebenen virtuellen Kanal übertragenen Inhalte dar.
  • Später wird eine Zählschleife (oder Inhaltsschleife) sovielmal durchlaufen wie die dem num_contents_in_section-Feldwert entsprechende Anzahl Inhalte, um detaillierte Daten über einen jeweiligen entsprechenden Inhalt zu liefern.
  • Ein content_version-Feld (32 Bit) zeigt die Versionsnummer für Inhalte (oder Dateien), die einen bestimmten content_id-Wert aufweisen. Vorliegend wird also davon ausgegangen, dass derselbe Inhalt, d.h. dessen content_id-Wert 0x0010 wird gesendet, sofern ein content_id-Wert eines von einem Empfangsgerät vorher empfangenen Inhalts 0x0010 ist. Zu diesem Zeitpunkt wird der vorher gespeicherte Inhalt durch Empfangen des neu angekündigten Inhalts über die NCT aktualisiert oder ersetzt. Gemäß dieser Ausführungsform heißt der content_version-Feldwert eine Seriennummer, die eine Releaseversion darstellt, den Zeitpunkt der Veröffentlichung (Release) aber auch unmittelbar darstellen kann. Zu diesem Zeitpunkt kann ein neues Feld zur Darstellung des Zeitpunktes der Veröffentlichung (Release) verwendet werden, wenn es schwierig ist, den Zeitpunkt der Veröffentlichung im content_version-Feld darzustellen.
  • Ein content_id-Feld (16 Bit) zeigt eine eindeutige Kennung des Inhalts (der Datei).
  • Ein content_available_start_time-Feld (32 Bit) und ein content_available_end_time-Feld (32 Bit) stellen eine Start- und Endzeit einer den Inhalt übertragenden FLUTE-Sitzung dar.
  • Ein ETM_location-Feld (2 bit) beschreibt die Existenz und den Standort einer erweiterten Textnachricht (Extended Text Message - ETM).
  • Ein content_length_in_seconds-Feld (30 Bits) stellt eine tatsächliche Wiedergabedauer eines entsprechenden Inhalts in Sekunden dar, wenn es sich beim Inhalt (der Datei) um eine A/V-Datei handelt.
  • Ein content_size-Feld (48 Bit) stellt die Größe des Inhalts (der Datei) in Byteeinheiten dar.
  • Ein content_delivery_bit_rate-Feld (32 Bit) stellt eine Bitrate, mit der der Inhalt (die Datei) übertragen wird; hierbei handelt es sich um eine Zielbitrate. Mit anderen Worten: Wenn ein Dienstanbieter oder Sender einen entsprechenden Inhalt sendet, zeigt das content_delivery_bit_rate-Feld, wie viel Bandbreite zuzuteilen ist. Wenn also ein Empfangsgerät content_size und content_delivery_bit_rate verwendet, ergibt sich daraus die Mindestdauer zum Empfang eines entsprechenden Inhalts (oder Datei). D.h., die zum Empfang des Inhalts erforderliche Zeit wird geschätzt und dem Benutzer mitgeteilt. Außerdem wird die Mindestempfangszeit mittels der Gleichung (content_size * 8) / (content_delivery_bit_rate) in Sekunden ermittelt.
  • Ein content_title_length-Feld (8 Bit) stellt die Länge von content_title_text() in Byteeinheiten dar. Wird dieses Feld verwendet, weiß das Empfangsgerät, wie viele Bytes zu lesen sind, um die content_title_text()-Daten zu ermitteln.
  • Ein content_title_text()-Feld stellt einen Inhaltstitel im Format einer Mehrstringstruktur dar.
  • D.h., das Empfangsgerät verwendet die NCT, um die Konfigurationsdaten von NRT-Inhalten/-Dateien zu ermitteln, und liefert einen Leitfaden für die NRT/Datei aufgrund der ermittelten Konfigurationsdaten des NRT-Inhalts/-Datei. Außerdem erhält das Empfangsgerät die Zugangsdaten der FLUTE-Sitzung, die den vom Leitfaden ausgewählten Inhalt/Datei von der NST überträgt, und empfängt den ausgewählten Inhalt unter Verwendung der ermittelten Zugangsdaten der FLUTE-Sitzung.
  • Außerdem kann die vorliegende Erfindung Containerdaten, Codierungsdaten und Decodierungsparameter von Medienobjekten in der NCT enthalten, die zur Wiedergabe der Inhalte/Dateien, aus denen der NRT-Dienst besteht, und diesen anschließend senden. Demnach werden die Containerdaten, Codierungsdaten und Decodierungsparameter von Medienobjekten jedes Inhalts von einer Empfangsanlage extrahiert, die zur Wiedergabe der Inhalte/Dateien und verwendet diese bei der Wiedergabe.
  • 18 ist eine Ansicht der Bitstromsyntaxstruktur einer SMT-Sitzung, die nach einer Ausführungsform Signalisierungsdaten über NRT-Dienstdaten bereitstellt.
  • Hier wird die entsprechende Syntax zum besseren Verständnis in einem privaten MPEG-2-Abschnittsformat erzeugt; das Format der entsprechenden Daten kann jedoch variieren.
  • Die SMT beschreibt Signalisierungsdaten (oder Signalisierungsdaten des NRT-Dienstes) und IP-Zugangsdaten eines mobilen Dienstes in Ensemble, in dem die SMT gesendet wird. Die SMT verwendet Transport_Stream_ID, d.h. eine Kennung eines Sendestroms, der jeden Dienst enthält, und liefert Sendestromdaten eines entsprechenden Dienstes. Ferner enthält die SMT Beschreibungsdaten jedes mobilen Dienstes (NRT-Dienstes) in einem Ensemble, und enthält weitere Daten in einem Deskriptorbereich.
  • Wie oben erwähnt, kann die SMT-Sitzung als IP-Stromformat in den RS-Rahmen aufgenommen und dann gesendet werden. In diesem Fall beschreiben die RS-Rahmendecoder eines Empfangsgeräts eingegebene RS-Rahmen, die später decodiert werden, und gibt die decodierten RS-Rahmen als entsprechende RS-Rahmenhandler aus. Außerdem teilt jeder RS-Rahmenhandler den eingegebenen RS-Rahmen in Reiheneinheiten auf, um M/H TP zu bilden, und gibt diesen dann als M/ZH TP-Handler aus.
  • Nachfolgend werden einige Beispiele von Feldern aufgeführt, die per SMT übertragen werden.
  • Ein table-id-Feld (8 Bit) ist ein Feld, aus dem ein Tabellentyp hervorgeht; hierdurch wird bestätigt, dass dieser Tabellenabschnitt ein Tabellenabschnitt in SMT ist. (table_id: Eine vorzeichenlose 8-Bit-Ganzzahl, aus der der Typ des in der SMT (Service Map Table) definierten Tabellenabschnitts hervorgeht.
  • Ein section_syntax_indicator-Feld (1 Bit) definiert ein Sitzungsformat der DST, und das Sitzungsformat kann die MPEG-Kurzsyntax (0) von MPEG sein. (section_syntax_indicator: Dieses 1-Bit-Feld wird auf 0 eingestellt, damit stets gezeigt wird, dass diese Tabelle aus der „Kurz“form der privaten MPEG-2-Abschnittstabelle abgeleitet ist).
  • Ein private_indicator-Feld (1 Bit) lässt erkennen, ob die SMT einem privaten Abschnitt folgt. (private_indicator: Dieses 1-Bit-Feld wird auf 1 eingestellt).
  • Ein section_length-Feld (12 Bit) stellt eine nach einem entsprechenden Feld verbleibende SMT-Sitzungslänge dar. (section_length, Ein 12-Bit-Feld. Hiervon wird die Anzahl der diesem Feld unmittelbar folgenden Bytes dieses Tabellenabschnitts vorgegeben. Der Wert dieses Feldes darf 4093 (0xFFD) nicht übersteigen).
  • Ein table_id_extension-Feld (16 Bit) hängt von einer Tabelle ab, und kann ein logischer Teil eines table_id-Feldes sein, der einen Bereich der übrigen Felder identifiziert. (table_id_extension: Dies ist ein tabellenabhängiges 16-Bit-Feld. Es gilt logisch als Bestandteil des table_id-Feldes, aus dem der Umfang der übrigen Felder hervorgeht).
  • Hier enthält ein table_id_extension-Feld ein SMT_protocol_version-Feld.
  • Das SMT_protocol_version-Feld (8 Bit) zeigt eine Protokollversion, die es ermöglicht, dass die SMT Parameter mit einer anderen Struktur liefert als diejenige, die in einem aktuellen Protokoll definiert wird. (SMT_protocol_version: (Ein vorzeichenloses 8-Bit-Ganzzahlfeld, dessen Aufgabe es ist, dieser SMT in Zukunft zu ermöglichen, Parameter zu enthalten, die anders strukturiert sind als diejenigen, die im aktuellen Protokoll definiert werden. Derzeit beträgt der SMT_protocol_version-Wert 0. SMT_protocol_version-Werte ungleich Null können von einer zukünftigen Version dieser Norm verwendet werden, um strukturell andersartige Tabellen zu kennzeichnen).
  • Ein ensemble_id-Feld (8 Bit) enthält Werte von 0x00 bis 0x3F als mit dem entsprechenden Ensemble in Verbindung stehenden ID-Wert. (ensemble_id: Dieses 8-Bit-Ganzzahlfeld im Bereich 0x00 bis 0x3F ist die mit diesem Ensemble verbundene Ensemble ID. Der Wert dieses Feldes ist aus der vom Basisbandprozessor des Subsystems der physischen Schicht getragenen parade_id abzuleiten; hierzu sind die parade_id der damit verbundenen Parade für die unerheblichsten 7 Bits und 0 als erheblichstes Bit zu verwenden, sofern das Ensemble über den Primary RS-Rahmen getragen wird, und 1 ist als erheblichstes Bit zu verwenden, wenn das Ensemble über den Secondary RS-Rahmen getragen wird).
  • Ein version_number-Feld (5 Bit) stellt die Versionsnummer der SMT dar. Ein current_next_indicator-Feld (1 Bit) lässt erkennen, ob eine übertragene SMT-Tabellensitzung derzeit anwendbar ist. (current_next_indicator: Ein 1-Bit-Indikator, der darauf hinweist, dass die gesendete SMT derzeit anwendbar ist, wenn er auf 1 eingestellt ist. Ist das Bit auf 0 eingestellt, heißt dies, dass die gesendete Tabelle noch nicht anwendbar ist und als nächste Tabelle gültig wird. Gemäß dieser Norm ist es nicht erforderlich, dass „nächste“ Tabellen (die mit current_next_indicator gleich 0) unbedingt zu senden sind. Eine Aktualisierung der derzeit anwendbaren Tabelle ist durch Erhöhung des version_number-Werts zu signalisieren).
  • Ein section_number-Feld (8 Bit) stellt eine aktuelle SMT-Sitzungsnummer dar. (section_number: Dieses 8-Bit-Feld liefert die Abschnittsnummer dieses NRT-SST- (Service Signaling Table) Abschnitts. Der section_number-Wert des ersten Abschnitts in einer NRT-SST ist auf 0x00 eingestellt. Der section_number-Wert ist mit jedem weiteren Abschnitt der NRT-SST um 1 zu erhöhen).
  • Ein last_section_number-Feld (8 Bit) stellt die letzte Abschnittsnummer dar, die eine SMT-Tabelle darstellt.
  • (last_section_number: Dieses 8-Bit-Feld liefert die Nummer des letzten Abschnitts (d.h. der Abschnitt mit dem höchsten section_number) der SST, zu der dieser Abschnitt gehört).
  • Ein num_services-Feld (8 Bit) stellt die Anzahl der in einer SMT-Sitzung enthaltenen Dienste dar. (num_services: Dieses 8-Bit-Feld stellt die Anzahl der in dieser SMT-Sitzung enthaltenen Dienste dar). Mindestens ein mobiler Dienst, mindestens ein NRT-Dienst, oder mobile und NRT-Dienste können über das Ensemble empfangen werden, das die SMT aufweist. Wenn nur NRT-Dienste über das Ensemble übertragen werden, das SMT aufweist, kann es auf die Anzahl der in der SMT enthaltenen NRT-Dienste hinweisen.
  • Später wird eine Zählschleife (oder Dienstschleife) sovielmal durchlaufen wie die dem num_service-Feldwert entsprechende Anzahl Dienste, um Signalisierungsdaten über eine Mehrzahl Dienste zu liefern. D.h., Signalisierungsdaten eines entsprechenden Dienstes wird von jedem Dienst in der SMT-Sitzung angezeigt. Hier kann es sich beim Dienst um einen mobilen oder NRT-Dienst handeln. Zu diesem Zeitpunkt kann jeder Dienst mit den nachfolgenden Felddaten versehen werden.
  • Ein service_id-Feld (16 Bit) stellt einen Wert dar, der einen entsprechenden Dienst (eine vorzeichenlose 16-Bit-Ganzzahl, die diesen Dienst innerhalb des Umfangs dieses SMT-Abschnitts eindeutig kennzeichnet) eindeutig identifiziert. Das service_id eines Dienstes ändert sich während der Lebensdauer des Dienstes nicht.
  • Der Klarheit halber wird empfohlen, dass, wenn ein Dienst eingestellt wird, das service_id dieses Dienstes erst nach Ablauf einer entsprechenden Dauer für einen anderen Dienst wieder verwendet wird. Wenn es sich hier beim Dienst um einen NRT-Dienst handelt, kann der NRT-Dienst durch das service_id identifiziert werden.
  • Ein Multi_ensemble_service-Feld (2 Bit) lässt erkennen, ob ein entsprechender Dienst über mindestens ein Ensemble übertragen wird.
  • Außerdem lässt das entsprechende Feld erkennen, ob der Dienst als Teil des über ein entsprechendes Ensemble übertragenen Dienstes wiedergegeben wird. Mit anderen Worten: Handelt es sich beim Dienst um einen NRT-Dienst, lässt das Feld erkennen, ob der NRT-Dienst über mindestens ein Ensemble übertragen wird. (multi_ensemble_service: Ein 2-Bit-Aufzählungsfeld, das erkennen lässt, ob der Dienst über mehr als ein Ensemble getragen wird. Außerdem lässt dieses Feld erkennen, ob der Dienst nur mit dem über dieses Ensemble getragenen Teil des Dienstes wiedergegeben werden kann).
  • Ein service_status-Feld (2 Bit) kennzeichnet einen Zustand eines entsprechenden Dienstes. Hier lässt die MSB erkennen, ob ein entsprechender Dienst aktiv (1) oder inaktiv (0) ist, und die LSB lässt erkennen, ob der entsprechende Dienst verborgen (1) ist oder nicht (0). Wenn hier der Dienst ein NRT-Dienst ist, lässt die MSB des service_status-Feldes erkennen, ob ein entsprechender NRT-Dienst aktiv (1) oder inaktiv (0) ist, und die LSB lässt erkennen, ob der entsprechende NRT-Dienst verborgen (1) ist oder nicht (0).
  • Ein SP_indicator-Feld (1 Bit) lässt erkennen, ob der Leistungsschutz eines entsprechenden Dienstes eingestellt ist. Wenn der Wert eines SP_indicator-Feldes 1 ist, wird der Leistungsschutz auf die zur sinnvollen Darstellung eines entsprechenden Dienstes erforderlichen Komponenten angewendet.
  • Ein short_service_length-Feld (3 Bit) stellt die Länge eines Kurznamens eines Dienstes im short_service_name-Feld in Byteeinheiten dar.
  • Ein short_service_name-Feld stellt einen Kurznamen eines entsprechenden Dienstes dar. (short_service_name: Der Kurzname des Dienstes, von dem jedes Zeichen nach UTF-8 zu codieren ist [29]. Liegen die Bytes im Kurznamen in ungerader Zahl vor, enthält das zweite Byte des letzten des Bytepaares pro durch das short_service_name_length-Feld gekennzeichnete Paarenzahl 0×00). Beispielsweise wird ein Kurzname des mobilen Dienstes angezeigt, wenn es sich beim Dienst um einen mobilen Dienst handelt; handelt es sich um einen NRT-Dienst, wird ein Kurzname des NRT-Dienstes angezeigt.
  • Ein service_category-Feld (6 Bit) kennzeichnet eine Kategorie eines entsprechenden Dienstes. Ist ein Wert eines entsprechenden Feldes auf einen „nur informativen“ Wert eingestellt, wird er als informative Beschreibung der Dienstkategorie behandelt. Ein Empfangsgerät ist erforderlich, um ein component_level_descriptors()-Feld der SMT zu überprüfen, um eine tatsächliche Kategorie des empfangenen Dienstes zu identifizieren. Das service_category-Feld weist für Dienste mit einer Video- und/oder Audiokomponente eine Komponente auf NTP-Zeitbasis auf.
  • V.a. hinsichtlich der vorliegenden Erfindung weist ein entsprechender Dienst auf einen NRT-Dienst hin, wenn ein service_category-Feld 0×0E enthält. In diesem Fall wird darauf hingewiesen, dass es sich bei den Signalisierungsdaten eines derzeit in einer SMT-Sitzung beschriebenen Dienstes um die Signalisierungsdaten eines NRT-Dienstes handelt.
  • Ein num_services-Feld (5 Bit) zeigt die Anzahl der IP-Stromkomponenten in diesem Dienst.
  • Ist das IP_version_flag-Feld (1 Bit) auf 0 eingestellt, weist es darauf hin, dass source_IP_address, service_destination_IP_address und component_destination_IP_address-Felder IPv4-Adressen sind. Der Wert von 1 für dieses Feld wird vorbehalten, um in Zukunft darauf hinzuweisen, dass source_IP_address-, service_destination_IP_address- und component_destination_IP_address-Felder für IPv6 bestimmt sind. Die Verwendung der IPv6-Adressen ist derzeit noch nicht definiert.
  • Ein eingestelltes source_IP_address_flag-Feld (1 Bit) lässt erkennen, ob eine Fahne gesetzt ist, dass ein Quellen-IP-Adressenwert für diesen Dienst auf ein quellenspezifisches Multicast hinweist.
  • Ist ein service_destination_IP_address_flag-Feld (1 Bit) eingestellt, weist dies darauf hin, dass eine entsprechende IP-Stromkomponente über ein IP-Datagramm übertragen wird, dass eine andere Ziel-IP-Adresse als service_destination_IP_address aufweist.
  • Wenn also die Fahne gesetzt ist, verwendet eine Empfangsanlage component_destination_IP_address als destination_IP_address, und berücksichtigt ein service_destination_IP_address-Feld in einer num_channels-Schleife nicht. (service_destination_IP_address_flag: Eine boolesche 1-Bit-Fahne, die, sofern sie auf 1 gesetzt ist, erkennen lässt, dass ein service_destination_IP_adress-Wert vorliegt, um als Standard-IP-Adresse der Komponenten dieses Dienstes zu fungieren).
  • In Bezug auf ein source_IP_address-Feld (32 oder 128 Bit) ist eine Interpretation erforderlich, sofern source_IP_address_flag auf 1 gesetzt ist; es liegt aber kein Interpretationsbedarf vor, wenn es auf 0 gesetzt ist.
  • Ist das source_IP_address_flag-Feld auf 1 eingestellt und das IP_version_flag-Feld auf 0 eingestellt ist, weist dieses Feld auf eine 32-Bit-IPv4-Adresse hin, die eine Quelle eines entsprechenden Kreiskanals darstellt. Ist das IP_version_flag-Feld auf 1 eingestellt, weist dieses Feld auf eine 32-Bit-IPv6-Adresse hin, die eine Quelle eines entsprechenden virtuellen Kanals darstellt. (source_IP_address: Dieses Feld liegt vor, wenn source_IP_address_flag auf 1 eingestellt ist, und liegt nicht vor, wenn service_IP_address_flag auf 0 eingestellt ist. Liegt es vor, enthält dieses Feld die Quellen-IP-Adresse des ganzen IP-Datagramms, das die Komponenten dieses Dienstes trägt. Die konditionale Verwendung der 128 Bit langen Version dieses Feldes soll die eventuelle Verwendung von IPv6 in Zukunft ermöglichen, obwohl die Verwendung von IPv6 derzeit noch nicht definiert ist).
  • Handelt es sich beim Dienst um einen NRT-Dienst, wird das source_IP_address-Feld eine Quellen-IP-Adresse desselben Servers, der alle Kanäle der FLUTE-Sitzung sendet.
  • In Bezug auf ein service_destination_IP_address (32 oder 128 Bit) ist eine Interpretation erforderlich, sofern service_destination_IP_address_flag auf 1 gesetzt ist; es liegt aber kein Interpretationsbedarf vor, wenn es auf 0 gesetzt ist. Ist das service_destination_IP_address_flag-Feld auf 1 eingestellt und das IP_version_flag-Feld auf 0 eingestellt ist, weist dieses Feld auf eine 32-Bit-IPv4-Adresse eines entsprechenden virtuellen Kanals hin.
  • Ist das service_destination_IP_address_flag-Feld auf 1 eingestellt und das IP_version_flag-Feld auf 1 eingestellt ist, weist dieses Feld auf eine 64-Bit-IPv6-Adresse eines entsprechenden virtuellen Kanals hin. Kann das entsprechende service_destination_IP_address nicht interpretiert werden, muss ein component_destination_IP_address-Feld in einer num_components-Schleife interpretiert werden, und eine Empfangsanlage verwendet component_destination_IP_address, um auf eine IP-Stromkomponente zuzugreifen. (service_destination_IP_address: Dieses Feld liegt vor, wenn service_destination_IP_address_flag auf 1 eingestellt ist, und liegt nicht vor, wenn service_destination_IP_address_flag auf 0 eingestellt ist. Liegt kein entsprechendes service_destination_IP_address vor, existiert ein component_destination_IP_address-Feld für jede Komponente in einer num_components-Schleife. Die konditionale Verwendung der 128 Bit langen Version dieses Feldes soll die eventuelle Verwendung von IPv6 in Zukunft ermöglichen, obwohl die Verwendung von IPv6 derzeit noch nicht definiert ist). Handelt es sich beim Dienst um einen NRT-Dienst, wird das service_destination_IP_Address-Feld mit einer Ziel-IP-Adresse desselben Servers einer Sitzungsebene der FLUTE-Sitzung signalisiert.
  • Außerdem liefert die SMT Daten über eine Mehrzahl Komponenten mittels einer Zählschleife.
  • Später wird eine Zählschleife (oder Komponentenschleife) sovielmal durchlaufen wie die dem num_components-Feldwert entsprechende Anzahl Dienste, um Zugangsdaten über eine Mehrzahl Komponenten zu liefern. Mit anderen Worten: Zugangsdaten über jede Komponente werden bereitgestellt. Zu diesem Zeitpunkt können die nachfolgenden Felddaten über jede Komponente bereitgestellt werden. Hier entspricht eine Komponente gemäß einer Ausführungsform einer FLUTE-Sitzung.
  • Ein auf 1 eingestelltes essential_component_indicator-Feld (1 Bit) weist darauf hin, dass diese Komponente für den Dienst unentbehrlich ist. Sonst weist dieses Feld darauf hin, dass es sich um eine optionale Komponente handelt).
  • Ist component_destination_IP_address_flag-Feld (1 Bit) auf 1 gesetzt, heißt dies, dass für die Komponente ein component_destination_IP_address-Feld vorliegt.
  • Ein port_num_count-Feld (6 Bit) zeigt die Nummern der Ziel-UDP-Ports, die mit dieser UDP-/IP-Stromkomponente in Verbindung stehen. Die Werte der Ziel-UDP-Portnummern beginnen ab dem component_destination_UDP_port_num-Feld und werden außer im Falle von RTP-Strömen um eins erhöht, wenn die Ziel-UDP-Portnummern ab dem component_destination-UDP_port_num-Feld beginnen, und um zwei erhöht werden, um die mit den RTP-Strömen in Verbindung stehenden RTCP-Ströme zu ermöglichen.
  • Ein component_destination_UDP_port_num-Feld (16 Bit) zeigt die Nummer eines Ziel-UDP-Ports dieser UDP-/IP-Stromkomponente. Für RTP-Ströme ist der Wert von component_estimation_UDP_port_num eine gerade Zahl, und der nächsthöchste Wert stellt die Ziel-UDP-Portnummer des damit in Verbindung stehenden RTCP-Stroms dar).
  • Ein component_destination_IP_address-Feld (32 oder 128 Bit) liegt vor, wenn component_destination_IP_address_flag auf 1 eingestellt ist, und liegt nicht vor, wenn component_destination_IP_address_flag auf 0 eingestellt ist. Ist dieses Feld vorhanden, stimmt die Zieladresse des IP-Datagramms, das diese Komponente des M/H-Dienstes trägt, mit der Adresse in diesem Feld überein. Ist dieses Feld vorhanden, stimmt die Zieladresse des IP-Datagramms, das diese Komponente trägt, mit der Adresse in dem M/H_service_destination_IP_address-Feld überein. Die konditionale Verwendung der 128 Bit langen Version dieses Feldes soll die eventuelle Verwendung von IPv6 in Zukunft ermöglichen, obwohl die Verwendung von IPv6 derzeit noch nicht definiert ist).
  • Ein num_component_level_descriptors-Feld (4 Bit) zeigt die Nummern der Deskriptoren, die zusätzliche Daten über eine Komponentenebene liefern.
  • component_level_descriptor()-Felder sind so viele in der Komponentenschleife enthalten wie eine dem Wert des num_component_level_descritors-Feldes entsprechende Zahl, damit zusätzliche Daten über die Komponente geliefert werden.
  • Ein num_service_level_descriptors-Feld (4 Bit) zeigt die Nummern der Deskriptoren, die zusätzliche Daten über eine entsprechende Dienstebene liefern.
  • service_level_descriptor()-Felder sind so viele in der Dienstschleife enthalten wie eine dem Wert des num_service_level_descritors-Feldes entsprechende Zahl, damit zusätzliche Daten über den Dienst geliefert werden. Zusätzliche Daten werden geliefert, wenn es sich beim Dienst um einen mobilen Dienst handelt; handelt es sich um einen NRT-Dienst, werden zusätzliche Daten über den NRT-Dienst angezeigt.
  • Ein num_ensemble_level_descriptors-Feld (4 Bit) zeigt die Nummern der Deskriptoren, die zusätzliche Daten über eine Ensembleebene liefern.
  • ensemble_level_descriptor()-Felder sind so viele in der Ensembleschleife enthalten wie eine dem Wert des num_ensemble_level_descriptors-Feldes entsprechende Zahl, damit zusätzliche Daten über das Ensemble geliefert werden.
  • Außerdem kann conponent_descriptor() als component_level_descriptors() der SMT der 18 bereitgestellt werden.
  • component_descriptor() wird als ein Wert von component_level_descriptors() der SMT verwendet, und beschreibt zusätzliche Signalisierungsdaten einer entsprechenden Komponente.
  • Daher können in Bezug auf einen mobilen NRT-Dienst die zum Empfang einer entsprechenden FLUTE-Sitzung erforderlichen Signalisierungsdaten mittels des Komponentendeskriptors der 14 bereitgestellt werden.
  • Wenn z.B. ein component_type-Feldwert des Komponentendeskriptors der 14 38 ist, liefert ein component_data(component_type)-Feld Daten zur FLUTE-Dateienlieferung, wie in 15 gezeigt. Da jedes Feld der 14 und 15 oben beschrieben wurde, wird auf überlappende Beschreibungen verzichtet.
  • 19 ist eine Ansicht eins FDT-Schemas zum Mapping einer Datei und eines content_id-Feldes nach einer Ausführungsform. 20 ist eine Ansicht eins FDT-Schemas zum Mapping einer Datei und eines content_id-Feldes nach einer Ausführungsform. Diese stellen ein Verfahren zur Bezeichnung von Eingabedateien auf FDT-Instanzebene. NRT-Inhalte enthalten eine Mehrzahl Dateien. Da keine Datei markiert ist, ist es schwierig, eine mit NRT-Inhalten in Verbindung stehende Datei zu suchen. Also wird, wie in 19 und 20 gezeigt, content_id in die FDT jeder Datei eingefügt.
  • Wenn vorliegend ein gemeinsames Attribut aller in FDT erklärten Dateien zu definieren ist, ist unter „FDT-Instanzebene“ eine Ebene zu verstehen, die einen Definitionsteil des gemeinsamen Attributs enthält. Unter „FDT-Dateiebene“ kann eine Ebene zu verstehen sein, die eine Definition eines einzelnen Attributs jeder Datei enthält.
  • Ein Empfangsgerät erkennt, ob ein über einen entsprechenden Kanal übertragener Dienst ein NRT-Dienst auf SMT-Basis ist. Außerdem identifiziert das Empfangsgerät einen Inhalt und Datei des entsprechenden NRT-Dienstes.
  • Wie oben erwähnt, obwohl das Empfangsgerät eine Datei und Inhalt im NRT-Dienst identifizieren kann, hat es keine Daten über die Dateien des Inhalts, und kann sie deshalb nicht miteinander abgleichen. So kann es vorkommen, dass das Empfangsgerät den NRT-Dienst nicht verarbeitet.
  • Daher stellt die vorliegende Erfindung ein Verfahren bereit, um erkennen zu können, ob ein Inhalt verwandt ist. Mit anderen Worten zeigt ein entsprechendes Verfahren, welche Dateiarten in einem Inhalt enthalten sind. In diesem Fall kann das Empfangsgerät den NRT-Dienst bestimmungsgemäß verarbeiten. Demnach kann das entsprechende Verfahren aufgrund der FDT-Daten in der FLUTE-Sitzung, die den NRT-Dienst sendet, bezeichnet werden. Beispielsweise wird jede Datei, aus der ein Inhalt besteht, aufgrund eines in der FLUTE-Sitzung gekennzeichneten content_location- und TOI-Feldes identifiziert. content_id in FDT wird mit einer Inhaltskennung (content_id) der NCT oder einer Inhaltskennung eines Inhaltsfragments in OMB BCAST SG abgeglichen.
  • In 19 und 20 erklärt ein mit 1 markierter Teil eine Inhaltskennung auf FDT-Instanzebene, und diese erklärte Inhaltskennung wird allen in einer entsprechenden FDT-Instanz erklärten Dateien zugewiesen. Selbstverständlich kann dies dadurch aufgehoben werden, dass auf Dateiebene eine neue Inhaltskennung zugewiesen wird. Oder, sofern eine konkrete Datei einem anderen Inhalt, der in der FDT-Instanzebene nicht definiert ist, kann dies durch Zuweisung einer unten beschriebenen content_id auf Dateiebene mitgeteilt werden. Diese Ausführungsform drückt content_id in 16 Bits aus.
  • In Bezug auf einen mit 2 gekennzeichneten Teil, wenn eine Datei in der FDT-Instanz in verschiedenen Inhalten mit einer content_id-Erklärung auf Dateiebene enthalten ist, signalisiert dieses Verfahren, welche Datei, alle Dateien eines Inhalts, zu welchem Eintrag gehört.
  • Ein Teil 3 ist ein Verfahren zur Mitteilung, ob eine entsprechende Datei für jede Datei eine Eingabedatei ist. Mit anderen Worten: Eine einer Root-Datei entsprechende Datei, die unter mehreren Dateien, aus denen ein Inhalt besteht, als erste wiedergegeben wird, oder zwangsläufig als erste ausgeführt wird, um auf einen Inhalt zugreifen zu können, wird als Eintragsdatei bezeichnet, und stellt eine Methode zur Mitteilung dieser Information dar. Ein Eintragsattribut kann weggelassen werden, und sein Standardwert ist falsch. Wird es weggelassen, heißt dies, dass eine entsprechende Datei keine Eintragsdatei ist. „Eintrag“ ist der Kopf einer Datei, die zur Ausführung der Datei verarbeitet werden muss. Z.B. kann es sich bei „index.html“ um einen „Eintrag“ handeln. So kann eine Eintragsdatei auf „richtig“, und sonstige Dateien auf „falsch“ eingestellt werden. Über die Eintragsdatei kann die wiederholte Übertragung derselben Datei wirksam gesteuert werden. Sobald eine Datei heruntergeladen worden ist, bezeichnet die Eintragsdatei eine Inhaltsdatei einer anderen Referenz, so dass sie in einer weiteren Instanz nicht mehr heruntergeladen werden muss.
  • Eine konkrete Datei fungiert als Eintrag in einer konkreten Gruppe, während eine mit einer Dateiebene in Verbindung stehende Gruppe signalisiert, ob ein Eintrag möglich ist, ihre entsprechende Rolle kann aber in eine andere Gruppe fallen. Wird eine Inhaltskennung in einer FDT-Instanzebene zugewiesen, kann ein Verfahren zur Mitteilung einer Eintragsdatei als die beiden nachfolgenden Verfahren betrachtet werden.
  • Ein Verfahren zur zusätzlichen Zuweisung einer Inhaltskennung auf Dateiebene zu einer Datei, die einer Eintragsdatei entspricht, wobei das Eintragsattribut auf richtig eingestellt wird: In diesem Fall wird eine Inhaltskennung in einer FDT-Instanzebene und einer Dateiebene verdoppelt, weist aber die flexibelste Struktur auf. D.h., obwohl eine der Datei- und FDT-Instanzebene content_id vorgeben kann, wenn eine weitere content_id gemeinsam in der Datei- und FDT-Instanzebene vorgegeben, hat die content_id der Dateiebene Vorrang vor der der FDT-Instanzebene.
  • Wie eine andere Ausführungsform des FDT-Schemas der 20 kann auf die als Eintragsdatei fungierenden Dateien in der Inhaltskennungsdefinition der FDT-Instanzebene Bezug genommen werden. Dazu wird gemäß der Ausführungsform der 20 FDT_content_ID_type für eine Inhaltskennung auf FDT-Instanzebene zusätzlich identifiziert, und wie im Teil 2 gezeigt, wird um ein content_location einer Eintragsdatei erweitert. Im Falle des Teils 2 wird eine Eintragsebene mit deren content_id definiert. Beispielsweise zeigt jede content_id, welche Eintragsdatei existiert.
  • In diesem Verfahren wird content_location verdoppelt, was die Signalisierung erschweren kann, die Konfiguration der Eintragsdatei ist jedoch durch jeden Inhalt sofort erhältlich.
  • 21 ist ein Flussdiagramm einer Operation eines Empfangsgeräts nach einer Ausführungsform.
  • In 21 empfängt ein Empfangsgerät gemäß einer Ausführungsform die Signalisierungsdaten eines NRT-Dienstes über einen Signalisierungskanal des NRT-Dienstes, zeigt die NRT-Leitfadendaten aufgrund der empfangenen Signalisierungsdaten, und empfängt die Dienstdaten des ausgewählten NRT-Inhalts, um einen NRT-Dienst bereitzustellen.
  • Nachdem das Empfangsgerät eingeschaltet worden ist, wählt ein Benutzer in der Operation S1000 zunächst einen Kanal aus. Dann wird je nach dem ausgewählten Kanal ein physischer Übertragungskanal eingeschaltet.
  • Dann werden in der Operation S1010 die VCT und PMT einem über den eingeschalteten physischen Übertragungskanal empfangenen Sendesignal entnommen. Dann wird in der Operation S1020 durch Parsen der empfangenen TVCT (VCT) geprüft, ob ein NRT-Dienst vorliegt. Dies wird durch Überprüfen des service_type_Feldwertes in einer virtuellen Schleife der VCT bestätigt. Beispielsweise liegt ein NRT-Dienst vor, wenn ein service_type-Feld 0x08 aufweist. Außerdem, wenn nicht 0×08, da ein entsprechender virtueller Kanal den NRT-Dienst nicht sendet, kann eine entsprechende Operation wie z.B. A/V-Dienst je nach den Daten im virtuellen Kanal in der Operation S1111 erfolgen.
  • Außerdem, sofern festgestellt wird, dass ein NRT-Dienst vorliegt, erfolgt ein PID(PID=PID_NST)-Abgleich mit einer konkreten PID(PID_NST) des Stroms, der eine allgemein bekannte IP-Adresse für die Signalisierungskanaladresse des NRT-Dienstes in der Operation S1030 erhalten, da ein entsprechender virtueller Kanal einen NRT-Dienst überträgt.
  • Außerdem empfängt das Empfangsgerät ein TP (Transport Packet), das dieselbe PID aufweist wie der in der Operation S1040 erhaltene PID-Wert (PID_NST).
  • Dann entnimmt das Empfangsgerät dem erhaltenen TP die Signalisierungsdaten des NRT-Dienstes, die eine NST (NRT Service Table) enthalten, oder entnimmt dem erhaltenen TP eine IP-Adresse des Signalisierungskanals des NRT-Dienstes, um die in einem anderen Format über eine IP-Schicht in der Operation S1050 übertragenen Signalisierungsdaten zu empfangen.
  • Dann erhält das Empfangsgerät die Kanaldaten über eine Sendung der NRT-Dienstdaten durch jeden NRT-Dienst von der NST in der Operation S1060.
  • Dann erhält das Empfangsgerät in der Operation S1070 eine NCT (NRT Content Table), die einen mit einem Channel_id-Wert identischen NRT_channel_id-Feldwert enthält, eine Kennung der erhaltenen Kanaldaten von den Signalisierungsdaten des NRT-Dienstes.
  • Dann erhält das Empfangsgerät in der Operation S1080 die Inhaltsdaten über NRT-Inhalte, aus denen jeder NRT-Dienst besteht, aus jedem Feld der erhaltenen NCT. Beispielsweise können die Inhaltsdaten gemäß einer Ausführungsform der NCT mindestens eines der content_delivery_bit_rate, content_available_start_time, content_available_end_time und content_title_text()-Felder enthalten.
  • Dann zeigt das Empfangsgerät in der Operation S1090 die NRT-Leitfadendaten mittels der Inhaltsdaten. Ein Benutzer kann die zu verwendenden bzw. zu erhaltenden NRT-Inhalte anhand der angezeigten NRT-Leitfadendaten auswählen.
  • Dann erhält das Empfangsgerät die Zugangsdaten des ausgewählten NRT-Inhalts von der NST in der Operation S1100. Die Zugangsdaten des NRT-Dienstes kann z.B. Kanal- oder IP-Adressendaten zum Empfang von NRT-Dienstdaten enthalten.
  • Außerdem greift das Empfangsgerät auf einen Kanal oder Server zur Übertragung des NRT-Dienstes mittels der erhaltenen Zugangsdaten des NRT-Dienstes, um in der Operation S1110 einen entsprechenden NRT-Inhalt zu erhalten, und führt je nach dem NRT-Inhalt eine entsprechende Operation aus.
  • 22 und 23 sind Ansichten einer Empfangsanlage nach einer Ausführungsform, die einen NRT-Inhalt eines NRT-Dienstes empfängt, speichert und wiedergibt.
  • Das Empfangsgerät der 23 kann eine Betriebssteuerungseinheit 100, eine Basisband-Verarbeitungseinheit 110, einen Dienst-Demultiplexer 120, einen Stromkomponentenhandler 130, einen Medienhandler 140, einen Dateienhandler 150, einen Servicemanager 160, einen PVR-Manager 170, eine erste Speichereinheit 180, einen SG-Handler 190, einen EPG-Manager 191, einen NRT-Servicemanager 192, eine Anwendungsmanager 194, eine Middleware-Maschine 193, einen Darstellungsmanager 195 und eine Benutzeroberflächenmanager (UI-Manager) 196 umfassen.
  • Die Basisband-Verarbeitungseinheit 110 kann einen Tuner 111 und einen Demodulator umfassen. Der Dienst-Demultiplexer 120 kann einen MPEG-2 TP-Handler 121, einen PSI/PSIP-Handler 122, einen MPEG-2 TP-Demultiplexer 123, einen Descrambler 124 und eine zweite Speichereinheit 125 umfassen.
  • Der Stromkomponentenhandler 130 kann einen PES-Demodulator (Packetized Elementary Stream) 131, einen ES-Demodulator (Elementary Stream) 132, einen PCR-Handler 133, einen STC-Handler 134, einen DSM-CC-adressierbaren Abschnittshandler 135, einen IP-Datagrammhandler 136, einen Descrambler 137, einen UDP-Handler 138, einen Dienstsignalisierungsabschnitts-Handler 138-1 und ein CAS (Conditional Access System) 139 umfassen.
  • Der Medienhandler 140 kann einen A/V-Demodulator 141 umfassen. Der Dateienhandler 150 kann einen ALC-/LCT-Stromhandler 151, einen Dateien-Rekonstruktionspuffer 152, einen XML-Parser 153, einen FDT-Handler, einen Dekompressor 155, eine dritte Speichereinheit 156 und einen Dateiendecoder 157 umfassen.
  • In 23 stellt der Tuner 111 ein Sendesignal eines gewünschten Kanals unter den über eine terrestrische Welle empfangenen Signale je nach der Steuerung des Servicemanagers 160 ein, und konvertiert das eingestellte Sendesignal dann in ein IF-Signal (Intermediate Frequency) herunter, um es an den Demodulator 112 auszugeben. Der Tuner 111 kann Echtzeit- und Nicht-Echtzeit-Ströme empfangen. Erfindungsgemäß wird der Nicht-Echtzeit-Strom als NRT-Strom bezeichnet.
  • Der Demodulator 112 regelt automatisch die Verstärkung, führt eine Trägerrückgewinnung eines digitalen IF-Signals eines vom Tuner 111 eingegebenen Passbandes durch, wandelt das digitale IF-Signal in ein Basisbandsignal um und führt dann eine Kanalentzerrung durch. Beispielsweise wird zur automatischen Verstärkungsregelung, Trägerrückgewinnung und Taktrückgewinnung ein VSB-Demodulationsprozess durchgeführt, wenn es sich beim Sendesignal um ein VSB-Modulationssignal handelt.
  • Die demodulierten und kanalentzerrten Daten im Demodulator 112 werden in einem MPEG-2 TS-Paketformat an den MPEG-2 TP-Handler 121 ausgegeben.
  • Der MPEG-2 TP-Handler 121 umfasst einen MPEG-2 TP-Puffer und einen MPEG-2 TP-Parser, und analysiert nach der Zwischenspeicherung einer Ausgabe des Demodulators 112 einen TS-Kopf. Wenn dann eine Ausgabe des Demodulators 112 ein A/V-TS-Paket für ein NRT- oder NRT-TS-Paket ist, wird sie an den Demultiplexer 123 ausgegeben, und wenn sie ein TS-Paket für eine PSI-/PSIP-Tabelle ist, wird sie an den PSI-/PSIP-Handler 112 ausgegeben.
  • Der PSI-/PSIP-Handler 112 umfasst einen PSI-/PSIP-Abschnittspuffer und einen PSI-/PSIP-Parser, und stellt nach der Zwischenspeicherung eines aus dem MPEG-2 TP-Handler 121 ausgegebenen TS-Pakets eine entsprechende Tabelle aus den PSI-/PSIP-Abschnittsdaten des TS-Pakets wieder her und parst sie unter Bezugnahme auf eine Tabellenkennung. Zu diesem Zeitpunkt wird mittels eine stable_id-Feldes, eines section_number-Feldes und eines last_section_number-Feldes in einem entsprechenden Abschnitt ermittelt, ob eine Tabelle einen Abschnitt oder eine Mehrzahl Abschnitte enthält. Außerdem werden Abschnitte mit der Tabellenkennung gesammelt, um eine entsprechende Tabelle zu vervollständigen. Beispielsweise werden Abschnitte mit einer VCT zugewiesenen Tabellenkennung gesammelt, um die VCT zu vervollständigen. Außerdem werden die geparsten Daten jeder Tabelle durch den Servicemanager 160 gesammelt, um sie in der ersten Speichereinheit 180 zu speichern. Die Tabellendaten wie z.B. VCT, PAT, PMT und DST werden im oben beschriebenen Verfahren in der ersten Speichereinheit gespeichert. Der Servicemanager 160 speichert die Tabellendaten in der ersten Speichereinheit 180 in einem Servicemap- und Leitfadendatenformat.
  • Sofern es sich beim eingegebenen TS-Paket um ein Echtzeit-A/V-TS-Paket handelt, teilt der Demultiplexer 123 das TS-Paket in ein Audio TS-Paket und ein Video TS-Paket ein, und gibt diese dann in den PES-Decoder 131 aus. Ist das eingegebene TS-Paket ein NRT-TS-Paket, wird es an den DSM-CC-Handler 135 ausgegeben. Sofern das TS-Paket eine PCR (Program Clock Reference) enthält, gibt es der Demultiplexer 123 außerdem an den PCR-Handler 133 aus; enthält es CA-Daten (Conditional Access), wird es an die CAS 139 ausgegeben. Ein NRT-TS-Paket enthält ein TS-Paket mit NRT-Signalisierungsdaten sowie ein TS-Paket mit einem Signalisierungskanal eines NRT-Dienstes. Eine eindeutige PID zur Kennzeichnung des NRT-Dienstes wird dem TS-Paket der NRT-Dienstdaten zugewiesen, und die PID eines TS-Pakets, das den Signalisierungskanal des NRT-Dienstes enthält, mittels DST und PMT extrahiert.
  • Ist ein Payload des eingegebenen TS-Pakets codiert, gibt es der Demultiplexer 123 an den Descrambler 124 aus; dann empfängt der Descrambler 124 die zur Decodierung erforderlichen Daten (die zur Codierung verwendeten Kontrollwörter) von der CAS 139, und decodiert das TS-Paket.
  • Der Demultiplexer 123 speichert ein A/V-Paket in Echtzeit, das auf eine Anforderung nach vorübergehender Aufzeichnung, programmierter Aufzeichnung und Zeitversetzung hin in der zweiten Speichereinheit 125. Die zweite Speichereinheit 125 ist ein Massenspeichermedium, und kann z.B. eine HDD umfassen. Download (d.h. Speicherung) und Aktualisierung (d.h. Wiedergabe) erfolgen durch die zweite Speichereinheit 125 je nach einer Steuerung des PVR-Managers 170.
  • Der Demultiplexer 123 trennt ein Audio TS-Paket und ein Video TS-Paket von dem von der zweiten Speichereinheit aktualisierten A/V-TS-Paket und gibt sie dann auf die Wiedergabeanforderung hin an den PES-Decoder 131 aus.
  • Um die oben aufgeführten Prozesse durchzuführen, wird der Demultiplexer 123 durch den Servicemanager 160 und/oder den PVR-Manager 170 gesteuert.
  • D.h., wenn ein service_type-Feldwert in der VCT darauf hinweist, dass ein NRT-Dienst übertragen wird, extrahiert der Servicemanager 160 die Kennungsdaten jedes NRT-Dienstes aus dem von einer virtuellen Kanalschleife der VCT erhaltenen NRT_service_descriptor() und speichert diese, und extrahiert dann die DST PID aus einem Dienststandortdeskriptor (oder einer ES_loop der PMT) der VCT, um die DST zu empfangen.
  • Dann wird der NRT-Dienst anhand der empfangenen DST identifiziert, und die PID eines MPEG-2 TS-Pakets, das den Signalisierungskanal des NRT-Dienstes enthält, wird extrahiert, um den identifizierten NRT-Dienst mittels DST und PMT zu empfangen. Die extrahierte PID wird an den Demultiplexer 123 ausgegeben. Der Demultiplexer 123 gibt der PID entsprechende MPEG-2 TS-Pakete, die vom Servicemanager 160 ausgegeben wurde, an den adressierbaren Abschnittshandler 135 aus.
  • Die PCR ist ein zur zeitlichen Synchronisierung der Audio- und Video-ES im A/V-Decoder 141 verwendeter Zeitreferenzwert. Der PCR-Handler 133 stellt die PCR im Payload des eingegebenen TS-Pakets wieder her und gibt sie an den STC-Handler 134 aus. Der STC-Handler 134 stellt die STC (System Time Clock), d.h. eine Referenzuhr eines Systems, aus der PCR her und gibt diese an den A/V-Decoder 141 aus.
  • Der PES-Decoder 131 enthält einen PES-Puffer und einen PES-Handler, und entfernt nach der Zwischenspeicherung eines Audio TS- und Video TS-Pakets einen TS-Kopf vom TS-Paket, um Audio- und Video-PES wiederherzustellen. Die wiederhergestellten Audio- und Video-PES werden an den ES-Decoder 132 ausgegeben. Der ES-Decoder 132 enthält einen ES-Puffer und einen ES-Handler, und entfernt jeden PES-Kopf vom Audio- und Video-PES, um Audio- und Video-ES, d.h. reine Daten, wiederherzustellen. Die wiederhergestellten Audio- und Video-ES werden an den A/V-Decoder 141 ausgegeben.
  • Der A/V-Decoder 141 decodiert das Audio- und Video-Es durch jeden Decodierungsalgorithmus, um einen vorherigen Kompressionszustand wiederherzustellen, und gibt ihn an den Darstellungsmanager 195 aus. Zu diesem Zeitpunkt erfolgt die Zeitsynchronisierung, wenn Audio- und Video-ES nach STC decodiert werden. Z.B. umfasst ein Audio-Decodierungsalgorithmus mindestens einen AC-3-Decodierungsalgorithmus, einen MPEG 2-Audiodecodierungsalgorithmus, einen MPEG 4-Audiodecodierungsalgorithmus, einen AAC-Decodierungsalgorithmus, einen AAC+-Decodierungsalgorithmus, einen HE AAC-Decodierungsalgorithmus, einen AAC SBR-Decodierungsalgorithmus, einen MPEG-Surround-Decodierungsalgorithmus und einen BSAC-Decodierungsalgorithmus. Ein Videodecodierungsalgorithmus umfasst mindestens einen von einem MPEG 2-Videodecodierungsalgorithmus, einem MPEG 4-Videodecodierungsalgorithmus, einem H.264-Decodierungsalgorithmus, einem SVC-Decodierungsalgorithmus und einem VC-1-Decodierungsalgorithmus.
  • Die CAS 139 umfasst einen CA-Strompuffer und einen CA-Stromhandler, und nach der Zwischenspeicherung eines aus dem MPEG-2 TP-Handler abgegebenen TS-Pakets oder der von einem UDP-Datagrammhandler 138 wiederhergestellten und ausgegebenen Daten stellt sie die zur Decodierung des gespeicherten TS-Pakets erforderlichen Daten (z.B. zur Codierung verwendete Kontrollwörter) oder Leistungsschutzdaten wieder her. D.h. EMM (Entitlement Management Message) und ECM (Entitlement Control Message) im Payload des TS-Pakets werden extrahiert, und die zur Decodierung erforderlichen Daten werden mittels Analyse der extrahierten EMM und ECM entnommen. Die ECM kann ein bei der Codierung verwendetes Kontrollwort (CW) enthalten. Zu diesem Zeitpunkt kann das Kontrollwort mittels eines Codierungsschlüssels codiert werden. Die EMM kann einen Codierungsschlüssel sowie Qualifikationsdaten der entsprechenden Daten enthalten. Die zur Decodierung erforderlichen Daten, die der CAS 139 entnommen wurden, werden an den Descrambler 124 und 137 ausgegeben.
  • Der DSM-CC-Abschnittshandler 135 umfasst einen DSM-CC-Abschnittspuffer und einen DSM-CC-Abschnittsparser, und stellt nach der Zwischenspeicherung eines aus dem Demultiplexer 123 ausgegebenen TS-Pakets einen adressierbaren Abschnitt im Payload des TS-Pakets wieder her. Nach der Wiederherstellung des IP-Datagramms durch Entfernung eines Kopfes und einer CRC-Prüfsumme des adressierbaren Abschnitts wird das wiederhergestellte IP-Datagramm an den IP-Datagrammhandler 136 ausgegeben.
  • Der IP-Datagrammhandler 136 umfasst einen IP-Datagrammpuffer und einen IP-Datagrammparser. Nach der Pufferung des vom DSM-CC-Abschnittshandlers 135 gelieferten IP-Datagramms extrahiert und analysiert der IP-Datagrammhandler 136 einen Kopf des gepufferten IP-Datagramms, um das UDP-Datagramm aus dem Payload des IP-Datagramms wiederherzustellen und gibt ihn dann an den UDP-Datagrammhandler 138 aus.
  • Zu diesem Zeitpunkt, sofern das IP-Datagramm codiert ist, wird das codierte UDP-Datagramm im Descrambler 137 decodiert und anschließend an den UDP-Datagrammhandler 138 ausgegeben. Beispielsweise empfängt der Descrambler 137 Daten (z.B. ein zur Codierung verwendetes Kontrollwort), die zur Decodierung erforderlich sind, von der CAS 138 und decodiert dann das UDP-Datagramm, um es dann an den UDP-Datagrammhandler 138 auszugeben.
  • Der UDP-Datagrammhandler 138 umfasst einen UDP-Datagrammpuffer und einen UDP-Datagrammparser. Nach der Pufferung eines vom IP-Datagrammhandler 136 oder dem Descrambler 137 gelieferten IP-Datagramms extrahiert und analysiert der UDP-Datagrammhandler 138 einen Kopf des gepufferten UDP-Datagramms, um die im Payload des UDP-Datagramms enthaltenen Daten wiederherzustellen. Wenn zu diesem Zeitpunkt die wiederhergestellten Daten Leistungsschutzdaten sind, werden sie an die CAS 139 ausgegeben; handelt es sich bei den wiederhergestellten Daten um Signalisierungsdaten des NRT-Dienstes, werden sie an den Dienstsignalisierungs-Abschnittshandler 138-1 ausgegeben; und handelt es sich bei den wiederhergestellten Daten um NRT-Dienstdaten, werden sie an den ALC-/LCT-Stromhandler 151 ausgegeben.
  • Mit anderen Worten: Es handelt sich bei den Zugangsdaten des IP-Datagramms, das den Signalisierungskanal des NRT-Dienstes sendet, um eine allgemein bekannte Ziel-IP-Adresse und eine allgemein bekannte UDP-Portnummer.
  • Daher enthalten der IP-Datagrammhandler 136 und der UDP-Datagrammhandler 138 eine allgemein bekannte Ziel-IP-Multicastadresse sowie eine allgemein bekannte Ziel-UDP-Portnummer, und extrahiert einen IP-Multicaststrom, der einen Signalisierungskanal eines NRT-Dienstes, d.h. NRT-Dienstsignalisierungsdaten, um diese an den Dienstsignalisierungs-Abschnittshandler 138-1 auszugeben.
  • Außerdem umfasst der Dienstsignalisierungs-Abschnittshandler 138-1 einen Dienstsignalisierungs-Abschnittspuffer und einen Dienstsignalisierungs-Abschnittsparser, uns stellt die NST aus den Signalisierungsdaten des NRT-Dienstes wieder her und parst diese, um sie an den Dienstmanager 160 auszugeben. Wenn die NST geparst wird, können die Zugangsdaten der FLUTE-Sitzung, die Inhalte/Dateien, aus denen der NRT-Dienst besteht, sowie die zur Wiedergabe des NRT-Dienstes erforderlichen Signalisierungsdaten extrahiert werden. Beispielsweise können die zur Wiedergabe von Inhalten/Dateien des NRT-Dienstes erforderlichen Daten extrahiert werden, die von der NST an jede FLUTE-Sitzung gesendet werden. Die zur Wiedergabe der Inhalte/Dateien des NRT-Dienstes erforderlichen Daten können Container-, Codierungsdaten oder Decodierungsparameter eines Medienobjektes umfassen.
  • Die geparsten Daten aus der NST werden durch den Servicemanager 160 gesammelt, um sie in dann der ersten Speichereinheit 180 zu speichern. Der Servicemanager 160 speichert die aus der NST extrahierten Daten in der ersten Speichereinheit 180 in einem Servicemap- und Leitfadendatenformat. In einem anderen Beispiel kann der NRT-Servicemanager 182 als Servicemanager 160 fungieren. D.h., die geparsten Daten aus der NST werden durch den NRT-Servicemanager 192 gesammelt, um sie in dann der ersten Speichereinheit 180 zu speichern.
  • Der ALC-/LCT-Stromhandler 151 umfasst einen ALC-/LCT-Strompuffer und einen ALC-/LCT-Stromparser, und nach der Pufferung vom UDP-Datagrammhandler 138 ausgegebener Daten, die eine ALC-/LCT-Struktur aufweisen, analysiert er einen Kopf sowie eine Kopferweiterung einer ALC-/LCT-Sitzung aus den Pufferdaten. Aufgrund des Analyseergebnisses des Kopfes und der Kopferweiterung der ALC-/LCT-Sitzung werden die an die ALC-/LCT-Sitzung an den XML-Parser 153 ausgegeben, wenn sie eine XML-Struktur aufweisen. Weisen die Daten eine Dateistruktur auf, werden sie nach der Zwischenspeicherung im Dateien-Wiederherstellungspuffer 152 an den Dateiendecoder 157 oder in der dritten Speichereinheit 156 ausgegeben. Der ALC-/LCT-Stromhandler 151 wird durch den NRT-Servicemanager 192 gesteuert, sofern die an die ALC-/LCT-Sitzung gesendeten Daten für einen NRT-Dienst bestimmt sind. Wenn zu diesem Zeitpunkt die an die ALC-/LCT-Sitzung gesendeten Daten komprimiert sind, werden sie nach der Entkomprimierung im Dekompressor 155 an mindesten einen vom XML-Parser 153, Dateiendecoder 157 und die dritte Speichereinheit 156 ausgegeben.
  • Der XML-Parser 153 analysiert die über die ALC-/LCT-Sitzung übertragenen XML-Daten, und wenn die analysierten Daten für einen Dienst auf Dateibasis bestimmt sind, werden sie an den FDT-Handler 154 ausgegeben. Sind die analysierten Daten für einen Dienstleitfaden bestimmt, werden sie an den SG-Handler 190 ausgegeben.
  • Der FDT-Handler 154 analysiert und verarbeitet eine FDT (File Description Table) des FLUTE-Protokolls über eine ALC-/LCT-Sitzung. Der FDT-Handler 154 wird durch den NRT-Servicemanager 192 gesteuert, sofern die empfangene Datei für einen NRT-Dienst bestimmt ist.
  • Der SG-Handler 190 sammelt und analysiert für einen Dienstleitfaden bestimmte Daten, die in der XML-Struktur gesendet werden, und geben sie an den EPG-Manager 191 aus.
  • Der Dateiendecoder 157 decodiert eine aus dem Dateien-Wiederherstellungspuffer 152 oder dem Dekompressor 155 ausgegebene oder eine von der dritten Speichereinheit 156 hochgeladene Datei mittels eines vorbestimmten Algorithmus, wodurch diese an die Middleware-Maschine 193 oder den A/V-Decoder 141 ausgegeben werden.
  • Die Middleware-Maschine 193 interpretiert Daten mit einer Dateistruktur, d.h. Anwendung, und führt diese aus. Außerdem kann die Anwendung über den Darstellungsmanager 195 an einen Bildschirm oder Lautsprecher ausgegeben werden. Die Middleware-Maschine 193 ist gemäß einer Ausführungsform eine Middleware-Maschine auf JAVA-Basis.
  • Der EPG-Manager 191 empfängt Dienstleitfadendaten vom SG-Handler 190 auf eine Benutzereingabe hin, und wandelt die empfangenen Dienstleitfadendaten dann in ein Anzeigeformat um, um sie an den Darstellungsmanager 195 auszugeben. Der Anwendungsmanager 194 führt die allgemeine Verwaltung der in dem Format, z.B. Datei, empfangenen Verarbeitungs-Anwendungsdaten durch.
  • Der Servicemanager 160 sammelt und analysiert PSI-/PSIP-Tabellendaten oder Signalisierungsdaten eines NRT-Dienstes, die an einen Signalisierungskanal eines NRT-Dienstes, um eine Servicemap zu erzeugen, und speichert diese dann in der ersten Speichereinheit 125. Außerdem steuert der Servicemanager 160 Zugangsdaten über einen vom Benutzer gewünschten NRT-Dienst, und steuert auch den Tuner 111, den Demodulator 112 und den IP-Datagrammhandler 136.
  • Die Betriebssteuerungseinheit 100 steuert mindestens einen vom Servicemanager 160, PVR-Manager 170, EPG-Manager 191, NRT-Dienstmanager 192, Anwendungsmanager 194 und dem Darstellungsmanager 195 gemäß einem Benutzerbefehl und führt so eine vom Benutzer gewünschte Funktion aus.
  • Der NRT-Dienstmanager 192 führt die allgemeine Verwaltung eines in einem Inhalts-/Dateiformat übertragenen NRT-Dienstes über die FLUTE-Sitzung auf einer IP-Schicht.
  • Der UI-Manager 196 liefert eine Benutzereingabe an die Betriebssteuerungseinheit 100 über die UI.
  • Der Darstellungsmanager 195 liefert dem Benutzer über mindestens einen von einem Lautsprecher und einem Bildschirm mindestens eines von vom A/V-Decoder 141 ausgegebenen Audio-/Videodaten, von der Middleware-Maschine 193 ausgegebenen Dateidaten und vom EPG-Manager 191 ausgegebenen Dienstleitfadendaten.
  • Außerdem erhält einer vom Dienstsignalisierungs-Abschnittshandler 138-1, Servicemanager 160 und dem NRT-Servicemanager 192 Inhalte, aus denen der NRT-Dienst besteht, oder IP-Zugangsdaten auf der eine Datei sendenden FLUTE-Sitzung von einer FLUTE-Sitzungsschleife einer NST (oder einer Komponentenschleife einer NST). Ferner erhält der eine Zugangsdaten auf FLUTE-Ebene von einem in der Komponentenschleife der NST erhaltenen component_descriptor().
  • Dann greifen der ALC-/LCT-Stromhandler und der Dateiendecoder 157 die FLUTE-Dateilieferungssitzung mittels der erhaltenen Zugangsdaten auf FLUTE-Ebene, um Dateien in der Sitzung zu sammeln. Sind die Dateien einmal gesammelt worden, stellen sie einen NRT-Dienst dar. Dieser NRT-Dienst kann in der dritten Speichereinheit 156 gespeichert oder an die Middleware-Maschine 193 oder den A/V-Decoder 141 ausgegeben werden, um auf einem Darstellungsdienst angezeigt zu werden.
  • Die dritte Speichereinheit 158, d.h. ein Speichermedium, das eine Datei wie z.B. NRT-Dienstdaten speichert, kann mit der zweiten Speichereinheit 125 geteilt oder separat verwendet werden.
  • 24 ist ein Flussdiagramm eines Verfahrens des Empfangens und Bereitstellens eines NRT-Dienstes durch ein Empfangsgerät nach einer Ausführungsform.
  • Das Empfangsgerät kann Signalisierungsdaten eines NRT-Dienstes über einen Signalisierungskanal eines NRT-Dienstes oder durch Empfang eines IP-Datagramms im Falle eines mobilen NRT-Dienstes erhalten, und erhält in der Operation S2010 die SMT von den Signalisierungsdaten des NRT-Dienstes.
  • Dann erhält das Empfangsgerät in der Operation S2020 NRT-Dienstdaten von der SMT. Die Daten des NRT-Dienstes können durch Parsen von NRT_service_info_descriptor in einer Deskriptorschleife auf Dienstebene erhalten werden. Die erhaltenen NRT-Dienstdaten können Anforderungsdaten einer Anwendungsart für jeden NRT-Dienst oder andere NRT-Dienste umfassen.
  • Später gibt in der Operation S2030 das Empfangsgerät den NRT-Dienstleitfaden aufgrund der erhaltenen NRT-Dienstdaten aus. Der NRT-Dienstleitfaden kann Anwendungs- und Dienstkategoriedaten jedes Dienstes enthalten. Außerdem können detaillierte Daten ferner aufgrund jedes Feldes des NRT-Dienstdatendeskriptors angezeigt werden. Die detaillierten Daten können Kapazitätsdaten eines entsprechenden NRT-Dienstes gemäß einem storage_requirement-Feld oder Audio- oder Video-Codecdaten über einen entsprechenden NRT-Dienst gemäß einem audio_codec_type- oder video_codec_type-Feld umfassen. Ein Benutzer kann den zu empfangenden NRT-Dienst auswählen und diesen aufgrund der im Dienstleitfaden enthaltenen Daten empfangen.
  • Dann erhält das Empfangsgerät die Kennung (content_id) von Inhalten, aus denen der ausgewählte NRT-Dienst besteht, von der NST in der Operation S2040. Das Empfangsgerät erhält eine dem ausgewählten NRT-Dienst entsprechende NRT_service_id von der SMT, erhält eine NCT, die denselben NRT_channel_id-Wert wie die NRT_service_id aufweist, und erhält eine Kennung (content_id) für Inhalte, aus denen ein entsprechender NRT-Dienst besteht, über die erhaltene NCT.
  • Dann greift das Empfangsgerät auf die FLUTE-Sitzung zu, um unter Verwendung der empfangenen Inhaltskennung (content_id) in der Operation S2050 eine Datei zu empfangen, aus der der entsprechende Inhalt besteht. Da jede Datei, aus der der Inhalt besteht, mit TOI oder einem Inhaltsstandortsfeld der FDT in der FLUTE-Sitzung abgeglichen wird, empfängt das Empfangsgerät eine Datei eines entsprechenden Inhalts unter Verwendung der FLUTE-Sitzung in der Operation S2060. Zum Empfang kann der Empfang einer entsprechenden Datei oder eines entsprechenden Objektes gehören, wenn nach dem Lesen der FDT in einer entsprechenden FLUTE-Sitzung ein content_id-Attributfeld einer entsprechenden Datei mit der erhaltenen content_id identisch ist.
  • Außerdem parst das Empfangsgerät die FDT-Instanzen einer entsprechenden FLUTE-Sitzung, um eine Liste der einem Inhalt entsprechenden Dateien zu erhalten. Ferner erhält das Empfangsgerät Eintragsdaten, insbesondere eine Liste der als Eintrag fungieren Dateien, unter den Dateienlisten.
  • Schließlich liefert das Empfangsgerät in der Operation S2080 einem Benutzer je nach dem erhaltenen Inhalt und der diesem entsprechenden Dateiliste oder Eintragsdaten einem Benutzer einen NRT-Dienst.
  • Die über den NRT-Dienst heruntergeladenen Daten können zu dem vom Benutzer gewünschten Zeitpunkt verwendet werden, da sie von einer Echtzeitsendung getrennt sind.
  • Außerdem kann ein Sender nach der Übertragung des NRT-Dienstes im Voraus und seiner Speicherung in einem Empfangsgerät einen Inhalt des entsprechenden NRT-Dienstes kennzeichnen, der zu dem Zeitpunkt ausgeführt wird, dass eine bestimmte Echtzeitsendung gesendet oder der NRT-Dienst angezeigt wird. Gemäß einer Ausführungsform der vorliegenden Erfindung kann der NRT-Dienst Inhalte enthalten, die im Voraus heruntergeladen werden und mit einer Echtzeitsendung verknüpft ist und zum bestimmten Zeitpunkt ausgeführt wird. Gemäß einer Ausführungsform der vorliegenden Erfindung kann der NRT-Dienst ferner Inhalte enthalten, die im Voraus hergestellt werden, um einen bestimmten NRT-Dienst zum bestimmten Zeitpunkt auszuführen. Ein zum bestimmten Zeitpunkt ausgelöster NRT-Dienstinhalt, der mit einer Echtzeitsendung verknüpft ist, um für einen konkreten NRT-Dienst eine konkrete Aktion zu veranlassen, wird als TDO (Triggered Declarative Object) bezeichnet. So wird eine NRT-Dienstanwendung je nachdem, ob sie zum bestimmten Zeitpunkt ausgeführt wird, als NDO (Non-Real Time Declarative Object) oder als TDO bezeichnet.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung kann ein Sender Triggerdaten zur Auslösung des TDO senden. Die Triggerdaten können Daten zur Ausführung einer konkreten Aktion für ein konkretes TDO zum bestimmten Zeitpunkt enthalten.
  • Außerdem können die Triggerdaten Trigger-Signalisierungsdaten zur Signalisierung des Triggers sowie Triggerdaten, aus denen ein Trigger besteht, umfassen. Ferner können die Sendungstriggerdaten eines Datenstroms als Triggerstrom bezeichnet werden. Die Triggerdaten können sich auch auf sich selbst beziehen.
  • Ein derartiger Trigger kann mindestens eines von einer Triggerkennung zur Identifizierung eines Triggers, einer TDO-Kennung zur Identifizierung eines auszulösenden NRT-Dienstes sowie Aktionsdaten und Triggerzeit über ein TDO enthalten.
  • Die Triggerkennung kann eine eindeutige Kennung eines Triggers sein. Beispielsweise kann ein Sender mindestens einen Trigger in die über EIT bereitgestellten Sendungsdaten eines vorbestimmten Zeitpunkts aufnehmen. In diesem Fall kann das Empfangsgerät eine Aktion auf dem Triggerziel-TDO zu dem für jeden Trigger bestimmten Zeitpunkt aufgrund mindestens eines Triggers ausführen. Zu diesem Zeitpunkt kann das Empfangsgerät jeden Trigger mittels einer Triggerkennung identifizieren.
  • Eine TDO-Kennung kann eine Kennung eines NRT-Diensteinhalts, d.h. Ziel eines Triggers, sein. So kann die TDO-Kennung mindestens eine von einer Trigger-NRT-Dienstkennung (NRT_service_id), Inhaltsverknüpfung (content_linkage) und URI oder URL eines NRT-Inhaltseintrags umfassen. Außerdem kann die TDO-Kennung eine Zielkennung (target_service_id) zur Identifizierung eines später beschriebenen Triggerziel-TDO umfassen.
  • Ferner können die TDO-Aktionsdaten Daten über eine Aktion eines TDO eines Triggerziels umfassen. Bei den Aktionsdaten kann es sich um mindestens eines von den Ausführungs-, Beendungs- und Suspendierungsbefehlen des Ziel-TDO handeln. Ferner können die Aktionsdaten Befehle zur Erzeugung einer konkreten Funktion oder eines konkreten Ereignisses im Ziel-TDO umfassen. Wenn z.B. die Aktionsdaten den Ausführungsbefehl des Ziel_TDO enthalten, kann ein Trigger die Aktivierung des Ziel-TDO beim Empfangsgerät anfordern. Wenn außerdem die Aktionsdaten den Suspendierungsbefehl des Ziel-TDO enthalten, kann ein Trigger dem Empfangsgerät mitteilen, dass das Ziel-TDO suspendiert wird. Wenn außerdem die Aktionsdaten den Beendungsbefehl des Ziel-TDO enthalten, kann ein Trigger dem Empfangsgerät mitteilen, dass das Ziel-TDO beendet wird. So kann der Sender aufgrund eines Echtzeit-Inhalts eine TDO-Operation im Empfangsgerät über einen Trigger steuern.
  • Ferner kann eine Triggerzeit eine zur Ausführung (Auslösung) einer für das Ziel-TDO bestimmten Aktion heißen. Außerdem kann die Triggerzeit in einem konkreten virtuellen Kanal mit dem Videostrom synchronisiert werden, um den NRT-Dienst mit einer Echtzeitsendung zu verknüpfen. So kann der Sender eine Triggerzeit in Bezug auf die vom Videostrom erwähnte PCR bezeichnen. So kann der Sender ein TDO zu dem vom Sender vorgegebenen Zeitpunkt in Bezug auf die vom Videostrom erwähnte PCR auslösen. Ferner kann der Sender einen Trigger mit einer Triggerkennung im Kopf eines Videostroms signalisieren, um eine präzise Triggerzeit zu senden.
  • Außerdem kann die Triggerzeit mit UTC-Zeit gekennzeichnet werden. Im Falle von UTC-Zeit handelt es sich bei der Triggerzeit nicht um eine relative, sondern um eine absolute Zeit.
  • Die Triggerzeit kann eine präzise Triggerzeit, oder kann eine ungefähre Startzeit umfassen. Ferner kann das Empfangsgerät durch Empfang der ungefähren Zeit eine Aktion eines Ziel-TDO vor der präzisen Triggerzeit in Voraus vorbereiten. Beispielsweise kann das Empfangsgerät die Ausführung des TDo im Voraus vorbereiten, damit das TDO zur Triggerzeit reibungslos funktioniert.
  • 25 ist eine Ansicht einer Bitstromsyntax eines Triggers nach einer Ausführungsform.
  • Hier liegt der Trigger bzw. die Triggerdaten in Triggertabellenform vor, und eine entsprechende Syntax ist zum besseren Verständnis in einer privaten MPEG-2-Abschnittsform. Das Format der entsprechenden Daten kann jedoch variieren. Beispielsweise können die entsprechenden Daten nach einer weiteren Methode in einem SDP-Format (Session Description Protocol) ausgedrückt und über ein SAP (Session Announcement Protocol) signalisiert werden.
  • Ein table_id-Feld (8 Bit) wird willkürlich auf 0XTBD eingestellt, und lässt erkennen, dass es sich bei einem entsprechenden Tabellenabschnitt um einen Abschnitt handelt, der einen Trigger darstellt.
  • Ein section_syntax_indicator-Feld wird auf 1 eingestellt, und zeigt, dass der Abschnitt einer allgemeinen Abschnittsyntax folgt.
  • Ein private_indicator-Feld wird auf 1 eingestellt.
  • Ein section_length-Feld beschreibt die Anzahl der bis zum Abschnittsende verbleibenden Bits ab dem section_length-Feld.
  • Ein source_id-Feld stellt die Quelle eines mit einem virtuellen Kanal in Verbindung stehenden Programms dar.
  • Ein TTT_version_number-Feld stellt die Versionsdaten eines Triggers dar. Außerdem stellen die Versionsdaten eines Triggers die Version eines Triggerprotokolls dar. Die Triggerversionsdaten können verwendet werden, um zu bestimmen, wann eine Veränderung einer Triggerstruktur oder eines Triggers selbst vorliegt. Beispielsweise stellt das Empfangsgerät fest, dass keine Triggerveränderung vorliegt, wenn die Triggerversionsdaten identisch sind. Außerdem stellt das Empfangsgerät fest, dass keine Triggerveränderung vorliegt, wenn die Triggerversionsdaten unterschiedlich sind. Beispielsweise können die Triggerversionsdaten eine Mehrzahl Versionsnummern enthalten, und das Empfangsgerät kann aufgrund einiger der Mehrzahl Versionsnummern feststellen, ob eine Triggerveränderung vorliegt.
  • Ein current_next_indicator-Feld zeigt, dass der entsprechende Tabellenabschnitt derzeit anwendbar ist, falls er auf 1 eingestellt ist.
  • Ein section_number-Feld zeigt eine Nummer eines entsprechenden Tabellenabschnitts.
  • Ein last_section_number Feld stellt den Tabellenabschnitt mit der letzten und höchsten Nummer unter den Abschnitten dar.
  • Ein num_triggers_in_section-Feld zeigt eine Anzahl Trigger eines entsprechenden Tabellenabschnitts. In einer Sitzung können ein oder mehrere Trigger vorliegen. Außerdem wird die nächste Zählschleife sovielmal wie die Anzahl der Trigger ausgeführt.
  • Ein trigger_id-Feld stellt eine eindeutige Kennung eines Triggers dar.
  • Ein trigger_time-Feld zeigt einen Zeitpunkt, zu dem ein Trigger ausgeführt wird. Außerdem kann vorkommen, dass dieses Feld in der Sitzung nicht enthalten ist; in diesem Fall kann es sich bei der Triggerzeit um eine vom Sendestrom auf die oben erwähnte Weise bezeichnete Zeit handeln.
  • Ein trigger_action-Feld zeigt Aktionsdaten eines zur Triggerzeit ausgeführten Triggers. Eine Triggeraktion kann mindestens einen von einem Vorbereitungsbefehl des Ziel-TDO, einem Ausführungsbefehl des Ziel-TDO, einem Suspendierungsbefehl des Ziel-TDO und einem Beendungsbefehl des Ziel-TDO enthalten. Die Triggeraktion kann ferner einen Befehl enthalten, der einen konkreten Befehl oder ein konkretes Ereignis erzeugt.
  • Ein trigger_description_length-Feld stellt die Länge von trigger_description_text dar.
  • Ein trigger_description_text-Feld zeigt eine Beschreibung eines entsprechenden Triggers in Textformat.
  • Ein service_id_ref-Feld stellt eine Kennung eines Ziel-TDO eines Triggers dar. Außerdem kann ein service_id_ref-Feld beispielsweise auch ein NRT_service_id-Feld einer SMT oder NST zeigen, um den NRT-Dienst eines Ziel-TDO eines Triggers zu identifizieren.
  • Ein content_linkage-Feld stellt eine Kennung eines Ziel-TDO-Inhalts eines Triggers dar. Beispielsweise kann ein content_linkage-Feld ein content_linkage-Feld einer NRT-IT oder NCT zeigen, um einen Ziel-TDO-Inhalt eines Triggers zu identifizieren. Außerdem können ein service_id_ref-Feld und ein content_linkage-Feld in einer Klasse zur Identifizierung eines Ziel-TDO enthalten sein.
  • Ein num_trigger_descriptors-Feld stellt die Anzahl der Triggerdeskriptoren dar.
  • Ein trigger_descriptor()-Feld stellt einen Deskriptor dar, der Daten über einen Trigger enthält.
  • Liegt ein Trigger in einem Tabellenformat des privaten MPEG-2-Abschnitts vor, kann ein Sender einen Trigger nach einem virtuellen Kanal senden.
  • Ein erstes Verfahren eines Senders zur Übertragung eines Triggers kann die Übertragung des 0X1FF-Stroms, der die Triggertabelle enthält, d.h. PSIP-Grund-PID, umfassen. Das erste Verfahren kann die Triggertabelle von den anderen Tabellen dadurch unterscheiden, dass die table_id der Triggertabelle zugewiesen wird.
  • Außerdem umfasst ein zweites Verfahren zur Übertragung eines Triggers die Zuweisung der einer Triggertabelle entsprechenden PID zu einer MGT (Master Guide Table) und die Übertragung eines entsprechenden PID-Stroms, der die Triggertabelle enthält. Das zweite Verfahren verarbeitet mit der Triggertabelle alle Tabellen in einem entsprechenden PID-Strom.
  • Außerdem werden gemäß einer Ausführungsform mindestens eines von Trigger und Trigger-Signalisierungsdaten über einen MPEG-2-PES übertragen, um die mit dem Video und Audio synchronisierte präzise Zeit als Triggerzeit zu bezeichnen.
  • Nachfolgend wird die Video- und Audiosynchronisierung des MPEG-2-PES beschrieben. Ein Empfängerdecoder funktioniert synchron mit einem Zeitstempel eines Senderdecoders. Der Codierer weist einen Hauptoszillator, der als STC (System Time Clock) bezeichnet wird, sowie einen Zähler auf. Die STC ist in einem konkreten Programm sowie einer Hauptuhr eines Programms für Video- und Audiocodierer enthalten.
  • Ferner, wenn ein Videorahmen oder ein Audioblock in einer Codierereingabe vorliegt, wird die STC gesampelt. Ein Samplingwert und ein konstanter Wert, die der Verzögerung der Codierer- und Decodiererpuffer entsprechen, werden hinzugefügt, um Darstellungszeitdaten, d.h. PTS (Presentation Time Stamp) zu erzeugen, die dann in den ersten Teil eines Bild- oder Audioblocks eingefügt werden. Werden die Rahmen umgeordnet, wird ein DTS (Decode Time Stamp) eingefügt, der einen Zeitpunkt darstellt, zu dem die Daten in einem Decoder zu decodieren sind. Bis auf die Rahmenumordnung des B-Bildes sind DTS und PTS gleich. DTS ist außerdem im Falle der Rahmenumordnung erforderlich. Wird DTS verwendet, ist eine PTS immer vorhanden. Sie können in einem Abstand von höchstens etwa 700 msec eingefügt werden. Außerdem wird in ATSC definiert, dass PTS und DTS in den Startteil jedes Bildes eingefügt werden.
  • Außerdem enthält eine Ausgabe eines Codiererpuffers einen Zeitstempel wie z.B. eine PCR (Program Clock Reference) in einer Transportpaketebene. Außerdem tritt ein PCT-Zeitstempel in einem Abstand von höchstens 100 msec auf, und wird zur Synchronisierung der STC eines Decoders und der STC eines Codierers verwendet.
  • Außerdem können Video- und Audiostrom jeweils eine einer gemeinsamen STC entsprechende PTS oder DTS enthalten, um den Audiostrom mit dem Decoder zu synchronisieren. So zeigen PTS und DTS, wann in jeder Decodiereinheit der Audio- und Videostrom wiedergegeben werden, und werden zur Synchronisierung von Audio und Video verwendet.
  • Beispielsweise gibt ein Decoder des Empfangsgeräts ein PES-Paket im empfangenen TS-Strom als Video-PES-Depacketizer aus und gibt einen in einen TS-Paketkopf eingefügten PCR-Wert an einen PCR-Zähler aus. Dann zählt der PCR-Zähler 100 des PCR-Wertes und gibt es an eine Abgleicheinheit aus. Ferner gibt der Video-PES-Depacketizer einen Kopf eines PES-Paket an einen DTS-/PTS-Extraktor aus, puffert den ES (Elementary Stream), d.h. die anzuzeigenden Bilddaten, in einem ES-Puffer & -Decoder. Die DTS-/PTS-Extraktionseinheit extrahiert die DTS- und PTS-Werte aus dem PES-Paketkopf und gibt diese an die Abgleicheinheit aus. Die Abgleicheinheit gibt jedes Signal dafür an eine Decodierung-/Anzeigesteuereinheit aus, wenn der vom PCR-Zähler eingegebene PCR-Wert ein DTS-Wert wird oder der PCR-Wert von 100 ein PTS-Wert wird. Die Decodierungs-/Anzeigesteuerungseinheit empfängt ein Signal, wonach der PCR-Wert der DTS-Wert aus der Abgleicheinheit wird, und decodiert die im ES-Puffer & Decoder gepufferten Bilddaten, um sie in einem decodierten Stromspeicher zu speichern. Außerdem zeigt die Decodierungs-/Anzeigesteuereinheit die im decodierten Stromspeicher gespeicherten decodierten Bilddaten über eine Anzeigeeinheit, wenn das Signal erhalten wird, dass der PCR-Wert der PTS-Wert aus der Abgleicheinheit wird.
  • Außerdem enthält MPEG-2-PES im Kopf PTS und DTS, die die während der Datenübertragung übertragenen Daten mit einem ES oder Darstellungszeit unter einer Mehrzahl ES synchronisieren. Dies wird als synchronisiertes Datenstromverfahren bezeichnet.
  • D.h., gemäß einer Ausführungsform umfasst ein Sender Trigger- oder - ströme im Payload des PES, und bezeichnet die Triggerzeit als PTS-Wert des PES-Paketkopfes im oben beschriebenen synchronisierten Datenstromverfahren. In diesem Fall kann das Empfangsgerät ein Ziel-TDO zum präzisen Zeitpunkt gemäß dem PCR-Wert auslösen, auf den sich der einen Trigger enthaltende PES bezieht. Außerdem kann ein Sender einen Trigger zur präzisen Zeit der Audio- und Videodarstellung synchronisieren, zu der der Sender einen Trigger mit der PTS des PES-Paketkopfes auslösen soll, die als Triggerzeit bezeichnet wird sowie die PTS des Audio- und Video-PES-Paketkopfes.
  • Außerdem kann in Bezug auf den Kopf eines einen Trigger enthaltenden PES-Strompakets ein stream_type-Wert 0×06 sein, um zu zeigen, dass ein synchronisiertes Datenstromverfahren vorliegt, die stream_id kann eine Kennung eines vorbestimmten Stroms zeigen, und PES_packet_length kann die Länge eines das Payload des PES-Stroms enthaltenden PES-Stroms zeigen.
  • 26 ist eine Ansicht einer PES-Struktur nach einem synchronisierten Datenstromverfahren mit Trigger nach einer Ausführungsform.
  • Wie in 26 gezeigt, kann der PES des synchronisierten Datenstromverfahrens einen PES-Kopf und -Payload enthalten. Das PES-Payload kann eine synchronisierte Datenpaketstruktur aufweisen. Wie oben erwähnt, kann der Trigger, der eine Triggertabelle oder einen anderen Datentyp enthält, in das PES-Payload der 26 aufgenommen und dann übertragen werden. Außerdem kann ein Sender den Trigger in einem IP-Datagrammformat paketieren, und kann den paketierten Trigger in einem IP-Datenbereich aufnehmen und übertragen.
  • 27 ist eine Ansicht einer synchronisierten Datenpaketstruktur eines PES-Payloads zur Übertragung eines Triggers als Bitstromsyntax nach einer Ausführungsform.
  • Wie in 26 und 27 gezeigt, kann der Trigger in die synchronisierte Datenpaketstruktur aufgenommen und dann übertragen werden. Es folgt eine ausführliche Beschreibung jedes Feldes der Struktur.
  • Ein data_identifier-Feld ist eine Kennung eines in einem PES-Datenpaket enthaltenen Datentyps. Dies kann je nach Typ auf 0X22 eingestellt werden.
  • Ein sub_stream_id-Feld ist eine (private benutzerdefinierte) Kennung, die von einem Benutzer eingestellt werden kann.
  • Ein PTS_extention_flag-Feld zeigt, ob ein PTS_extention-Feld vorliegt. Ist dieser Feldwert gleich 1, kann das PTS_extension-Feld im PES_data_packet-Feld enthalten sein. Außerdem kann dieses Feld gleich 0 sein, wenn kein PTS_extension-Feld vorhanden ist.
  • Ein output_data_rate_flag-Feld kann auf 0 eingestellt werden.
  • Ein synchronized_data_packet_header_length-Feld zeigt die Länge eines optischen Feldes im PES-Paketkopf. Dieses Feld kann aufgenommen werden, wenn das PTS_extension_flag-Feld gleich 1 ist, und stellt die Länge, insbesondere auch synchronized_data_private_data_byte(s), dar.
  • Ein PTS_extension-Feld erweitert die vom Kopf eines entsprechenden PES-Pakets gelieferte PTS. Dieses Feld kann 9-Bit-PCR-Erweiterungsdaten enthalten. Außerdem kann ein Empfangsgerät die PTS-Auflösung der synchronisierten Daten von 11,1 µs (90 kHz), d.d. dem MPEG-2-Standard, auf 37 ns (27 MHz) erweitern.
  • Ein synchronized_data_private_data_byte-Feld stellt ein Payloadbyte eines synchronisierten PES-Pakets dar. Stellt das protocol_encapsulation-Feld der DTS eines von einem synchronisierten Datagramm, einem IP-Datagramm ohne LLC/SNAP und einem Multiprotokoll mit LLS/SNAP dar, kann das synchronized_data_byte-Feld ein einzigartiges Datagramm enthalten. Wenn also LLC/SNAP verwendet wird, kann ein 8-Byte-LLC/SNAP-Kopf in nur dem ersten 8-Byte-synchronized_data_byte des PES-Pakets gezeigt werden.
  • Wenn also ein Sender einen Trigger in einen synchronisierten Datenstrom (stream_type) des PES aufnimmt und diesen sendet, kann ein Empfangsgerät dem Payload des PES den Triggerstrom entnehmen. Außerdem kann das Empfangsgerät an einem Ziel-TDO mittels des PTS-Wertes des PES-Kopfes als Triggerzeit eine Aktion ausführen. Daher kann das TDO zum präzisen Zeitpunkt einer Rahmeneinheit dadurch ausgelöst werden, dass ein Trigger auf PTS-Basis synchronisiert wird, d.h. eine Referenzzeit zur Darstellungssynchronisierung von Video und Audio. Wenn außerdem eine Triggerzeit mit PTS gekennzeichnet wird, ist Video- und Audiosynchronisierung leicht durchführbar.
  • Außerdem werden gemäß einer Ausführungsform Trigger-Signalisierungsdaten über den Empfang des Triggerstroms gesendet. Ein Empfangsgerät empfängt Trigger-Signalisierungsdaten sowie einen Triggerstrom im synchronisierten Datenstrom des PES aufgrund der empfangenen Trigger-Signalisierungsdaten.
  • Ein Verfahren zur Übertragung von Trigger-Signalisierungsdaten, um einen mit synchronisiertem Datenstreaming gesendeten Triggerstrom zu empfangen, kann variieren. Trigger-Signalisierungsdaten werden in einem der nachfolgenden Verfahren übertragen: 1. Ein Übertragungsverfahren über DST; 2. Ein Übertragungsverfahren über einen service_id-Deskriptor; 3. Ein Übertragungsverfahren über einen Triggerstrom-Deskriptor; und 4. Ein Übertragungsverfahren durch Definieren eines Stromtyps eines Triggerstroms.
  • Gemäß einer Ausführungsform können Trigger-Signalisierungsdaten für den NRT-Dienst über DST übertragen werden. Die DST ist eine Tabellensitzung zur Übertragung von Datendiensten. Da deren Beschreibung sowie die Beschreibung ihres data_service_bytes() mit denen der 8 identisch sind, wird auf überlappende Beschreibungen verzichtet.
  • Die DST kann Signalisierungsdaten zum Empfang jedes ES, aus dem ein Datendienst besteht, enthalten. Dementsprechend können Trigger-Signalisierungsdaten zum Empfang des Triggerstroms in der DST enthalten sein.
  • Außerdem kann jeder Datendienst mindestens eine Anwendung enthalten, und jede Anwendung kann in einer Anwendungs-Identifikationsstruktur enthalten sein, die eine Anwendungskennung wie z.B. app_id umfasst. Ferner kann jede Anwendung mindestens ein Datenelement enthalten, das eine entsprechende Anwendung oder Datenstrom darstellt.
  • So umfasst ein Sender zur Übertragung eines Triggerstroms über den Datendienst einen Triggerstrom in einem konkreten virtuellen Kanal, den er sendet. Außerdem kann der Sender in jeder Anwendung einen Triggerstrom umfassen und diesen übertragen. Daher werden Ausführungsformen zur Übertragung von Trigger-Signalisierungsdaten nach zwei Verfahren beschrieben.
  • Ist ein Triggerstrom in einem virtuellen Kanal enthalten, wird ein Datendienst zur Übertragung des Triggerstroms als Triggerdienst bezeichnet. In diesem Fall kann ein Sender eine feste Dienstkennung (service_ID) einem Triggerdienst zuweisen.
  • So kann ein Empfangsgerät feststellen, dass ein Triggerstrom an einen virtuellen Kanal gesendet wird, wenn die service_ID als Festwert 0x01 aufweist.
  • Hier kann der Sender in einer Anwendungskennungsstruktur in DST Trigger-Signalisierungsdaten umfassen und diese übertragen.
  • Beispielsweise fügt der Sender als App_id_description-Feldwert der DST 0x0001 hinzu, um einen Wert zu setzen, der einer interaktiven Anwendung zur Verknüpfung eines NT-Dienstes wie TDO mit einer Echtzeitsendung zu verknüpfen. Außerdem kann app_id_byte_length 3 Bytes (0x0003) verwenden, und app_id_byte kann 0x01 zugewiesen werden, um zu zeigen, dass der entsprechende Datendienst Triggerstrom-Signalisierungsdaten enthält.
  • Daher empfängt das Empfangsgerät die DST im oben beschriebenen Verfahren, und kann ein Trigger-Signalisierungsdaten enthaltendes tap() identifizieren, wenn app_id_byte_length 0x0003 ist, app_id_description 0x0001 ist und app_id_byte 0x01 ist. Das Empfangsgerät entnimmt der identifizierten tap()-Struktur Trigger-Signalisierungsdaten, die einen association_tag-Wert enthalten, und association_tag_descriptor empfängt einen Strom mit derselben PID wie das extrahierte association_tag von dem in der vom Sendestrom extrahierten PMT aufgeführten Daten-ES, um den Triggerstrom zu empfangen.
  • Wie oben erwähnt, wird der NRT-Dienst über SMR und NST signalisiert, und kann mit einer 16-Bit-service_id eindeutig identifiziert werden. Außerdem können Inhalte, aus denen ein NRT-Dienst besteht, über ontent_lengate oder eine Inhaltskennung in NCT oder NRT-IT identifiziert werden. Also kann der Triggerdienst wie der NRT-Dienst durch Erweiterung von app_id_byte über DST gesendet werden. Beispielsweise kann app_id_byte Daten enthalten, die ein service_ID-Feld des Triggerdienstes und content_linkage-Feld kombinieren. Dementsprechend entsprechen die ersten 16 Bits von app_id_byte einem service_id-Feld in SMT oder NST, und die nachfolgenden 32 Bits entsprechen einem Inhaltsverknüpfungsfeld in NCT oder NRT-IT.
  • Wie oben kann der Sender Trigger-Signalisierungsdaten ins tap() aufnehmen, und sendet diese über eine Anwendungskennungsstruktur der DST, wenn in jedem Kanal ein Strom enthalten ist.
  • Gemäß einer Ausführungsform können außerdem Trigger-Signalisierungsdaten über ein protocol_encapsulation-Feld der DST übertragen werden. Beispielsweise wird keine app_id zugewiesen, wenn app_id_byte_length in DST auf 0x0000 eingestellt ist. Enthält protocol_encapsulation 0x0F, heißt dies, dass in einer entsprechenden tap()-Struktur Trigger-Signalisierungsdaten enthalten sind. So kann ein Empfangsgerät von der entsprechenden tap()-Struktur Trigger-Signalisierungsdaten empfangen, sofern app_id_byte_length 0x0000 ist und protocol_encapsulation 0x0F ist. Hierdurch wird ein PID-Wert der PMT erhalten, der einen Triggerstrom kennzeichnet, und der Triggerstrom wird wie oben empfangen.
  • Gemäß einer Ausführungsform können außerdem Trigger-Signalisierungsdaten über ein content_type_descriptor-Feld der DST übertragen werden.
  • Wie in 28 gezeigt, ist eine content_type_descriptor-Struktur in tap() auf DST nach einer Ausführungsform wie folgt.
  • Ein descriptorTag kann 0x72 aufweisen, um contentTypeDescriptor darzustellen.
  • Ein descriptorLength-Feld stellt die Gesamtlänge eines Deskriptors in Byteeinheiten dar.
  • Ein contentTypeByte-Feld stellt einen MIME-Medientypwert der von tap erwähnten Daten, die mit dem Deskriptor verbunden sind. Der MIME-Medientyp wird in 5 von RFC2045, Abschnitt [8] definiert.
  • So kann ein content_type_descriptor einer tap()-Struktur hinzugefügt werden, die gemäß einer Ausführungsform Trigger-Signalisierungsdaten enthält. So kann ein Empfangsgerät von der entsprechenden tap()-Struktur Trigger-Signalisierungsdaten empfangen, sofern app_id_byte_length 0x0000 ist und content_type_descriptor der tap()-Struktur dem vorbestimmten Inhalt entspricht. Hierdurch wird ein PID-Wert der PMT erhalten, der einen Triggerstrom kennzeichnet, und der Triggerstrom wird wie oben empfangen. Der MIME-Medientyp kann mit einem konkreten Typ gekennzeichnet werden, um über einen content_type_descriptor zu zeigen, dass Triggerdienst-Signalisierungsdaten vorhanden sind.
  • Wie oben erwähnt, kann ein NRT-Dienst ein Triggerdienst zur Übertragung von Triggerströmen, und kann jeweils andere Ströme an Inhalte im Triggerdienst übertragen. In diesem Fall kann jede Anwendung einen Triggerstrom umfassen.
  • So kann eine Ausführungsform in jedem Inhalt eines NRT-Dienstes einen Triggerstrom enthalten und diesen übertragen. In diesem Fall kann die oben beschriebene Anwendungs-Kennungsstruktur verwendet werden. Wenn z.B. app_id_byte_length 0x0003 ist, heißt dies, dass der Triggerstrom über einen NRT-Dienst mittels einer Dienstkennung übertragen wird. Wenn app_id_byte_length 0x0007 ist, heißt dies, dass der Triggerstrom von jedem Inhalt mittels einer Dienstkennung und einer Inhaltsverknüpfung übertragen wird. Sofern er wie oben definiert ist, kann jeder Triggerstrom jedem NRT-Dienst oder -Inhalt entsprechend übertragen werden. Da der nächste Schritt eines Verfahrens zur Übertragung und zum Empfang eines Triggerstroms mit dem zur Übertragung eines Triggerstroms für jeden virtuellen Kanal identisch ist, wird auf überlappende Beschreibungen verzichtet.
  • 29 ist eine Ansicht einer Syntax einer PMT und einer Dienstkennung nach einer Ausführungsform.
  • Wie in 29 gezeigt zeigt eine PMT (Program Map Table) Daten eines in jedem Kanal gesendeten Programms. Eine PAT (Program Association Table), in der packet_ID als 0x00 definiert und übertragen wird, kann die PMT durch Parsen der packet_ID der PMT empfangen.
  • Außerdem kann ein service_identifier_descriptor in einer Deskriptorschleife jedes ES der PMT enthalten sein. Dann kann sie Listendaten der Dienste in jedem Programmelement enthalten.
  • Nachfolgend wird eine Struktur des service_identifier_descriptor beschrieben.
  • Ein descriptor_tag-Feld zeigt, dass der Deskriptor service_id_descriptor() ist und 0xC2 aufweisen kann.
  • Ein descriptor_length-Feld stellt die Länge (Byteeinheit) von diesem Feld bis zum Ende des Deskriptors dar.
  • Ein service_count-Feld zeigt die Anzahl der Dienste in einem Programmelement, die den Deskriptor aufweisen.
  • Ein service_id-Feld zeigt eine Dienstkennung in einem Programmelement, das den Deskriptor aufweist.
  • Gemäß einer Ausführungsform können Triggersströme über eine allgemein bekannte IP-Adresse übertragen werden. Um einen Trigger zu signalisieren, kann ein Sender außerdem eine konkrete service_id (z.B. 0x01) enthalten, die einem Triggerstrom in einem service_identifier_descriptor entspricht, und kann diesen übertragen. D.h., die Trigger-Signalisierungsdaten auf dem Trigger-Empfangsstrom können über einen service_identifier_descriptor gesendet werden. Wenn also eine service_id von service_id_descriptor in einer ES-Deskriptorschleife der PMT 0x01 ist, stellt das Empfangsgerät fest, dass elementary_PID in der ES-Schleife die PID ist, die den Triggerstrom darstelt, und empfängt den Triggerstrom über die PID.
  • 30 ist eine Ansicht einer Triggerstromkennung nach einer Ausführungsform. Gemäß einer Ausführungsform kann ein Trigger über einen Triggerstromdeskriptor übertragen werden. Wie der oben beschriebene service_identifier_descriptor kann der Triggerstromdeskriptor in einer ES-Deskriptorschleife in einer ES-Schleife der PMT enthalten sein. Wenn also ein Triggerstrom vorliegt, kann ein Triggerstromdeskriptor in einer ES-Deskriptorschleife existieren. Wenn ein Triggerstromdeskriptor identifiziert wird, kann ein Empfangsgerät den Triggerstrom dadurch empfangen, dass eine PID des Triggerstroms von elementary_PID in einer entsprechenden ES-Schleife empfangen wird.
  • Auf diese Weise kann ein Triggerstromdeskriptor zur Übertragung von Trigger-Signalisierungsdaten mindestens eines von einer service_id (target_service_id) des TDO, einem Triggerziel in einem Triggerstrom und einem Triggerstrom, der eine IP-Adressenliste sendet, enthalten. Der Triggerstromdeskriptor der 30 wird gemäß einer Ausführungsform bereitgestellt, und dessen Struktur wird nachfolgend beschrieben.
  • Ein descriptor_tag-Feld zeigt einen trigger_stream_descriptor, wenn es auf einen vorbestimmten Wert eingestellt ist.
  • Ein descriptor_length-Feld stellt die Länge (Byteeinheit) von diesem Feld bis zum Ende des Deskriptors dar.
  • Ein target_service_count-Feld stellt die Anzahl der NRT-Zieldienste (TOD) mindestens eines Triggers im Triggerstrom dar.
  • Ein target_service_id-Feld zeigt eine service_id des NRT-Zieldienstes (TOD) mindestens eines Triggers im Triggerstrom dar. Ein Empfangsgerät kann vor dem Empfang eines Triggerstroms mittels des target_service_id-Feldes eine service_id identifizieren.
  • Ein target_content_item_count-Feld stellt die Anzahl der NRT-Zieldienstinhalte mindestens eines Triggers im Triggerstrom dar.
  • Ein target_content_linkage-Feld stellt eine Verknüpfung eines NRT-Zieldienstinhalts (content_linkage) mindestens eines Triggers im Triggerstrom dar.
  • Außerdem wird gemäß einer Ausführungsform ein Triggerstromdeskriptor bereitgestellt; so kann er offensichtlich auch zusätzliche Daten enthalten oder eine andere Konfiguration aufweisen kann. Wenn beispielsweise für jeden Kanal ein Triggerstrom übertragen wird, kann ein content_item-Feld weggelassen werden. Wenn außerdem mindestens eines von einem trigger_stream_identification_information-Feld und einem profile_information-Feld hinzugefügt werden, um den Triggerstrom zu identifizieren.
  • Ein Sender kann Listendaten eines NRT-Zieldienstes eines Triggers wie z.B. TDO mittels des trigger_stream_descriptor senden. Außerdem kann der Sender Trigger-Signalisierungsdaten mit den target_service_id- und target_content_linkage-Feldern übertragen, wenn einem Inhalt zufolge ein weiterer Trigger vorliegt. Außerdem kann ein Triggerstromdeskriptor ferner eine Liste von IP-Adressendaten oder Portnummern enthalten, die einen Triggerstrom übertragen.
  • Gemäß einer Ausführungsform kann ein Sender einen Stromtyp kennzeichnen, und sendet die Trigger-Signalisierungsdaten. Ein Empfangsgerät extrahiert die Trigger-Signalisierungsdaten unter Verwendung eines Stromtyps aus der PMT und empfängt den Triggerstrom mittels der Trigger-Signalisierungsdaten. Beispielsweise kann 0x96, einer der derzeit vorläufig eingestellten Stromtypen, als Triggerstrom bezeichnet werden. In diesem Fall hat ein typisches Empfangsgerät keine Informationen darüber, dass ein Stromtyp 0x96 ist, kann den Triggerstrom nicht verarbeiten und berücksichtigt ihn deshalb nicht. So wird die Rückwärtskompatibilität eines Submodell-Empfangsgeräts gewährleistet.
  • Gemäß einer Ausführungsform kann ein Trigger in einer AIT (Application Information Table) zur Übertragung von Anwendungsdaten in einer Datensendung wie z.B. MHP (Multimedia Home Platform) oder ACAP (Advanced Common Application Platform) enthalten sein und übertragen werden. 31 ist eine Ansicht einer AIT nach einer Ausführungsform.
  • Außerdem kann gemäß einer weiteren Ausführungsform ein Trigger in einem Deskriptor der STT enthalten sein, um sich als Triggerzeit auf eine STT zu bezieh, und dann übertragen werden. 32 ist eine Ansicht einer STT nach einer Ausführungsform.
  • 33 ist ein Blockdiagramm eines Sendegeräts zur Übertragung von TDO sowie eines Triggers nach einer Ausführungsform.
  • Unter Bezugnahme auf 33 umfasst das Sendegerät 200 eine NRT-Dienst-Sendeeinheit 210, eine Triggersendeeinheit 220, einen Multiplexer 230 und einen Demodulator 240. Die NRT-Dienst-Sendeeinheit 210 umfasst einen NRT-Dienst- (TDO) Erzeuger 211 und einen NRT-Dienst-Signalisierungsdatenerzeuger 212. Die Triggersendeeinheit 220 umfasst einen Triggererzeuger 221 und einen Trigger-Signalisierungsdatenerzeuger 222.
  • Der NRT-Dienst- (TDO) Erzeuger 211 empfängt Daten zur Erzeugung von NRT-Diensten von einem Dienstanbieter, um den NRT-Dienst zu erzeugen, paketiert den erzeugten NRT-Dienst in einem IP-Datagramm, und paketiert dann das paketierte IP-Datagramm in einem Sendepaket (TP). Die paketierten NRT-Dienstdaten werden an den Multiplexer 230 gesendet.
  • Der NRT-Diensterzeuger 211 überträgt Metadaten, insbesondere Kanaldaten, über den NRT-Dienst in transmission und service_id an den NRT-Dienst-Signalisierungsdatenerzeuger 212. Außerdem, wenn es sich beim erzeugten NRT-Dienst um TDO handelt, extrahiert der NRT-Diensterzeuger 211 Triggerdaten, insbesondere eine Triggerzeit zur Auslösung von TDO, Kennungsdaten und Triggeraktionsdaten eines Ziel-TDO, und sendet diese dann an den Triggererzeuger 221.
  • Der NRT-Dienst-Signalisierungsdatenerzeuger 212 erzeugt Signalisierungsdaten eines NRT-Dienstes, um mittels der NRT-Dienst-Metadaten den NRT-Dienst zu empfangen, und paketiert die erzeugten Signalisierungsdaten des NRT-Dienstes an das TP, um diese an den Multiplexer 230 zu senden.
  • Außerdem erzeugt der Triggererzeuger 221 Triggerdaten mittels Triggerdaten des vom NRT-Dienst- (TDO) Erzeuger empfangenen TDO. Die erzeugten Triggerdaten werden in ein TP paketiert, um sie an den Multiplexer 230 zu übertragen. Außerdem überträgt der Triggererzeuger 221 Metadaten zum Empfang eines Triggers, wie z.B. die PID (Packet Identifier) der gesendeten Triggerdaten, an den Trigger-Signalisierungsdatenerzeuger 222.
  • Der NRT-Dienst-Signalisierungsdatenerzeuger 22 erzeugt Signalisierungsdaten eines NRT-Dienstes aufgrund der empfangenen Metadaten und paketiert das Triggersignal in Daten in einem TP, um diese an den Multiplexer 230 zu senden.
  • Der Multiplexer 230 multiplexiert die empfangenen TP jedes Kanals und überträgt dann das multiplexierte Signal an den Modulator 240.
  • Der Modulator 240 moduliert das multiplexierte Signal und sendet es an das externe Gerät. Das Modulationsverfahren kann variieren, und die vorliegende Erfindung ist darauf nicht beschränkt.
  • 34 ist ein Blockdiagramm eines Empfangsgeräts zum Empfang von TDO sowie eines Triggers nach einer Ausführungsform.
  • Unter Bezugnahme auf 34 umfasst das Sendegerät 300 einen Demodulator 310, einen Demultiplexer 320, eine Trigger-Verarbeitungseinheit 330, eine NRT-Dienstverarbeitungseinheit 340 und einen Servicemanager 350. Die Trigger-Verarbeitungseinheit 330 umfasst einen Triggerempfänger 331 und einen Trigger-Signalisierungsdatenempfänger 332. Die NRT-Dienst-Verarbeitungseinheit 340 umfasst einen NRT-Dienst- (TDO) Empfänger 341 und einen NRT-Dienstsignalisierungsdatenempfänger 342.
  • Der Demodulator 310 empfängt ein moduliertes Signal vom Sender 200 und demoduliert das empfangene Signal nach einem vorbestimmten Modulationsverfahren, um es an den Demultiplexer 320 zu übertragen.
  • Der Demultiplexer 320 demultiplexiert das demodulierte Signal, um ein ursprüngliches TP für jeden Kanal wiederherzustellen, damit sie jeder Kanal an jeden Empfänger der Trigger-Verarbeitungseinheit 330 oder der NRT-Dienst-Verarbeitungseinheit 340 sendet.
  • Der NRT-Dienst-Signalisierungsdatenempfänger 342 empfängt die paketierten Signalisierungsdaten des NRT-Dienstes vom Multiplexer 320, und stellt diese wieder her, um Daten über den NRT-Dienst zu extrahieren, und sendet sie dann an den NRT-Dienst (TDO) Empfänger 341. Der NRT-Dienst- (TDO) Empfänger 341 empfängt die TP des NRT-Dienstes vom Multiplexer 320 mittels Daten über den Empfang des NRT-Dienstes, stellt diese als Dienstdaten wieder her sendet sie dann an den Servicemanager 350.
  • Außerdem empfängt der NRT-Dienst-Signalisierungsdatenempfänger 332 die paketierten Trigger-Signalisierungsdaten vom Multiplexer 320, extrahiert Daten über den über den Empfang eines Triggers, und sendet sie dann an den Triggerempfänger 331. Der Triggerempfänger 331 empfängt TP, die einen Trigger enthalten, vom Multiplexer 32 mittels Daten über den Empfang des NRT-Dienstes, und stellt die Triggerdaten wieder her, um sie dann an den Servicemanager 350 zu senden.
  • Der Servicemanager 350 empfängt mindestens eines von Trigger- oder NRT-Dienst- (TDO) Daten von der Trigger-Verarbeitungseinheit 330 oder der NRT-Verarbeitungseinheit 340. Außerdem führt der Servicemanager 350 eine Triggeraktion aus und wendet sie zur Triggerzeit auf ein Triggerziel-TDO an, damit eine Triggeraktion am TDO ausgeführt wird.
  • 35 ist ein Flussdiagramm eines Verfahrens zur Übertragung eines Triggers nach einer Ausführungsform.
  • Unter Bezugnahme auf 35 erzeugt der NRT-Diensterzeuger 211 NRT-Dienstdaten durch den Empfang von NRT-Dienstdaten von einem externen Gerät oder aufgrund der vom NRT-Dienstanbieter in der Operation S100 empfangenen Daten. Ferner paketiert der NRT-Diensterzeuger 211 die erzeugten Daten in ein TP. Außerdem überträgt der NRT-Diensterzeuger 211 Daten über den Empfang von TP, die NRT-Dienst enthalten, an den NRT-Dienst-Signalisierungsdatenerzeuger 212.
  • Dann erzeugt der NRT-Dienst-Signalisierungsdatenerzeuger 212 die oben beschriebenen Signalisierungsdaten des NRT-Dienstes und paketiert sie dann in ein TP in der Operation S110.
  • Außerdem stellt der NRT-Diensterzeuger 211 in der Operation S120 fest, ob der erzeugte NRT-Dienst ein TDO ist.
  • Außerdem, wenn es sich beim erzeugten NRT-Dienst um TDO handelt, überträgt der NRT-Diensterzeuger 211 Triggerdaten, insbesondere eine Triggerzeit zur Auslösung von TDO-Triggeraktionen, und der Triggererzeuger erzeugt Triggerdaten unter Verwendung der empfangenen Daten in der Operation S130. Die erzeugten Triggerdaten werden in ein TP paketiert, um sie an den Multiplexer zu übertragen. Beispielsweise kann eine target_service_id des Ziel-TDO sowie die auf einen Zieldienst angewendeten Triggeraktionsdaten können in einen paketierten Strom, d.h. das Payload des PES, paketiert und dann übertragen werden. Außerdem werden die Triggerzeitdaten in PTS- oder DTS-Format bezeichnet, in das Payload oder den Kopf eines PES eingefügt und dann übertragen. Wird das synchronisierte Datenstreamingverfahren verwendet, werden PTS des Triggerstroms und PTS des Video- und Audiostroms synchronisiert, um die richtige Wiedergabezeit einzustellen.
  • Außerdem erzeugt der NRT-Dienst-Signalisierungsdatenerzeuger 222 Trigger-Signalisierungsdaten zur Erkennung und zum Empfang eines vom Triggererzeuger 221 empfangenen Triggers und paketiert die erzeugten Triggersignaldaten in ein TP, um sie in der Operation S140 an den Multiplexer 230 zu senden. Hier können die Trigger-Signalisierungsdaten einen in eine PMT eingefügten trigger_stream_descriptor oder service_identifier_descriptor enthalten, und kann eine packet_id eines jedem Deskriptor entsprechenden Triggerstroms enthalten. Außerdem können die Trigger-Signalisierungsdaten eine packet_id eines Triggerstroms in einer TAP-Struktur der DST enthalten.
  • Später multiplexiert der Multiplexer 230 mindestens eines von NRT-Dienstdaten in TP-Form, NRT-Dienst-Signalisierungsdaten, Triggerdaten und Trigger-Signalisierungsdaten durch jeden Sendekanal und sendet sie an den Modulator 240.
  • Außerdem moduliert der Modulator 240, um das modulierte Signal zu übertragen, und überträgt es in der Operation S160 an ein externes Empfangsgerät oder ein Rundfunknetz.
  • 36 ist ein Flussdiagramm einer Operation eines Empfangsgeräts 300 nach einer Ausführungsform.
  • Zunächst, wenn das Empfangsgerät 300 eingeschaltet ist, wird in der Operation S200 ein Kanal durch einen Benutzer ausgewählt, oder ein vorbestimmter Kanal wird ausgewählt. Der Demodulator 310 demoduliert das empfangene Signal vom ausgewählten Kanal, und der Demultiplexer 320 demultiplexiert das demodulierte Signal durch jeden Sendekanal. Ferner empfangen der NRT-Dienst-Empfänger 341 und der NRT_Dienst-Signalisierungsdatenempfänger 342 NRT-Dienstdaten und übertragen diese an den Servicemanager 350, wie oben beschrieben.
  • Dann bestätigt der Trigger-Signalisierungsdatenempfänger 332 oder der NRT-Dienst-Signalisierungsdatenempfänger 342 in der Operation S220, ob ein Triggerempfang möglich ist. Die Bestätigung des Triggerempfangs kann in einem der oben beschriebenen Verfahren erfolgen. D.h., der Trigger-Signalisierungsdatenempfänger 332 oder der NRT-Dienst-Signalisierungsdatenempfänger 342 verwendet eines von einem Verfahren zur Bestätigung einer einem Trigger entsprechenden PID in MGT oder PID auf PSIP-Basis, einem Verfahren zur Verwendung einer tap-Struktur der DST, einem Verfahren zur Verwendung eines service_identifier_descriptor oder trigger_stream_descriptor, einem Verfahren zur Verwendung eines Triggerstromtyps und einem Verfahren zur Verwendung von AIT oder STT, um zu bestätigen, ob ein Triggerempfang möglich ist.
  • Außerdem, wenn bestätigt wird, dass ein Triggerempfang möglich ist, empfängt der Trigger-Signalisierungsdatenempfänger 332 ein TP, das Trigger-Signalisierungsdaten enthält, und sendet dieses dann in der Operation S230 an den Triggerempfänger 331.
  • Später extrahiert der Triggerempfänger 331 Triggerdaten aus dem empfangenen TP mittels der Trigger-Signalisierungsdaten und sendet es in der Operation S240 an den Servicemanager 350. Beispielsweise kann der Triggerempfänger 331 einen Triggerstrom mittels einer dem trigger_stream_descriptor entsprechenden packet_id empfangen. Außerdem extrahiert der Triggerempfänger 331 Triggerdaten vom Triggerstrom und sendet sie an den Servicemanager 350. Außerdem, wenn es sich beim empfangenen Triggerstrom um PES handelt, wird die PTS im Kopf des PES als Triggerzeit extrahiert, und eine target_service_id und Triggeraktion im Payload des PES werden extrahiert, um sie an den Servicemanager 350 zu senden.
  • Außerdem führt der Servicemanager 350 eine Triggeraktion am Ziel-TDO zur Triggerzeit aus, damit in der Operation S250 eine Triggeraktion am TDO ausgeführt wird. Vor allem wenn es sich bei der PTS des PES um eine Triggerzeit handelt, wird die PTS des Triggerstroms im Kopf des Audio- und Videostroms mit der PTS synchronisiert, um eine präzise Wiedergabezeit zu gewährleisten.
  • 37 ist ein Flussdiagramm eines Verfahrens zum Empfang eines Triggers unter Einsatz einer Triggertabelle nach einer Ausführungsform.
  • Der Demodulator 310 empfängt und demoduliert ein Sendesignal für den ausgewählten Kanal. Außerdem empfängt der Trigger-Signalisierungsdatenempfänger 332 eine PSIP-Tabelle über den Demultiplexer 320 und stellt fest, ob in der empfangenen Tabelle eine Triggertabelle vorliegt, um in der Operation S310 einen Triggerdienst zu identifizieren. Der Trigger-Signalisierungsdatenempfänger 332 durchsucht die einer Triggertabelle zugewiesene PID von einer Tabelle auf MGT- oder PSIP-Basis, oder durchsucht eine der einer Triggertabelle zugewiesenen table_id entsprechende Tabelle, um einen Triggerdienst zu identifizieren.
  • Wird der Triggerdienst nicht identifiziert, stellt das Empfangsgerät 300 allgemeine Rundfunkdienste bereit.
  • Außerdem, wenn der Triggerdienst identifiziert wird, der Triggerempfänger 331 empfängt die durchsuchte Triggertabelle und parst sie in den Operationen S320 und S330.
  • Dann empfängt der Servicemanager 350 Triggerdaten, insbesondere die Triggerzeit, Triggeraktion und Ziel-TDO-Kennungsdaten, die in der Triggertabelle geparst werden, und führt an einem entsprechenden TDO zur entsprechenden Triggerzeit in der Operation S340 eine entsprechende Triggeraktion aus.
  • 38 ist ein Flussdiagramm einer Operation eines Empfangsgeräts 300 in dem Fall, dass die Triggersignalisierungsdaten und der Trigger nach einer Ausführungsform mit DST übertragen werden.
  • Wenn ein physischer Sendekanal in der Operation S3000 ausgewählt wird und ein von einem Tuner ausgewählter Kanal eingestellt wird, empfängt das Empfangsgerät 300 in der Operation S3010 die VCT und PMT von einem über den eingestellten physischen Sendekanal empfangenen Sendesignal mittels des Demodulators 310 und des Demultiplexers 320. Dann parst der PSI-/PSIP-Abschnittshandler oder der Trigger-Signalisierungsdatenempfänger 332 oder der NRT-Dienst-Signalisierungsdatenempfänger 342 die empfangene VCT und PMT, um zu bestätigen, ob ein NRT-Dienst vorliegt.
  • Wenn z.B. der Wert des service_type-Feldes der VCT weder 0x04 noch 0x08 ist, da der entsprechende virtuelle Kanal nicht nur NRT-Dienst sendet, funktioniert das Empfangsgerät 300 nach den Daten im virtuellen Kanal bestimmungsgemäß. Obwohl der service_type-Feldwert nicht nur NRT-Dienst bedeutet, kann der entsprechende virtuelle Kanal einen NRT-Dienst enthalten. Dieser Fall wird als im entsprechenden virtuellen Kanal enthaltener NRT-Hilfsdienst bezeichnet, und das Empfangsgerät 300 kann dasselbe Verfahren ausführen wie im Fall des Empfangs eines NRT-Dienstes.
  • Dann stellt der NRT-Dienst-Signalisierungsdatenempfänger 342 oder der Trigger-Signalisierungsdatenempfänger 332 fest, dass der NRT-Dienst über einen entsprechenden virtuellen Kanal empfangen wird, wenn ein service_type-Feldwert 0x04 oder 0x08 ist. In diesem Fall, wenn ein Wert eines stream_type-Feldes in einem service_location_descriptor der VCT (oder einer ES-loop einer PMT) 0x95 ist (d.h. DST-Sendung), wird die DST mittels eines Wertes eines Elementary_PID-Feldes in der Operation S3020 empfangen. Dies kann im Demultiplexer 320 erfolgen und durch den Servicemanager 350 gesteuert werden.
  • Außerdem identifiziert der Trigger-Signalisierungsdatenempfänger 342 einen Triggerdienst von der empfangenen DST in der Operation S3040. Ein Verfahren zur Erkennung eines Triggerdienstes verwendet eines von einem Verfahren zur Erkennung eines app_id_description und app_id_byte zugewiesenen spezifischen Wertes mittels einer Anwendungs-Kennungsstruktur, einem Verfahren zur Erkennung eines einem protocol_encapsulation-Feld zugewiesenen spezifischen Wertes und einem Verfahren zur Erkennung eines einen content_type_descriptor enthaltenden tap-Feldes.
  • Wird der Triggerdienst aus der empfangenen DST nicht identifiziert, da die Triggerdaten einen allgemeinen NRT-Dienst über einen entsprechenden virtuellen Kanal sendet, funktioniert das Empfangsgerät 300 in der Operation S3030 dem NRT-Dienst im entsprechenden virtuellen Kanal entsprechend bestimmungsgemäß.
  • Außerdem, wenn der Triggerdienst aus der DST identifiziert wird, extrahiert der Trigger-Signalisierungsdatenempfänger 332 tap aus einer DST, die Trigger-Signalisierungsdaten (PID von trigger_stream) in der Operation S3060.
  • Außerdem extrahiert der Trigger-Signalisierungsdatenempfänger 332 in der Operation S3070 die stream_PID aus der PMT, die association_tag des extrahierten Tap enthält.
  • Der Triggerempfänger 331 empfängt MPEG-2 TS_Pakete, die der extrahierten stream_PID entsprechen, und entfernt eine Entkapselung, d.h. TS-Kopf, um den PES-Strom wiederherzustellen, der den Triggerstrom enthält. Der stream_type eines PES-Pakets, das den Triggerstrom enthält, kann 0x06, was einem synchronisierten Datenstrom entspricht. Der Triggerempfänger 331 parst mindestens eines von PTS eines PES-Paketkopfes vom wiederhergestellten PES-Strom, einer Ziel-TDO-Kennung im Triggerstrom, einer Triggerkennung oder Triggeraktionsdaten in der Operation S3070.
  • Dann führt der Servicemanager 350 in der Operation S3080 eine Aktion am Ziel-TDO zur Triggerzeit mittels der PTS des PES-Paketkopfes, der als Triggerzeit einen Trigger enthält, aus. Hier kann es sich beim Ziel-TDO um den aus der geparsten Ziel-TDO-Kennung hervorgehenden NRT-Dienst handeln. Außerdem kann es sich bei der Aktion um einen Vorbereitungs-, Ausführungs-, Suspendierungs- oder Beendungsbefehl handeln, der aus den geparsten Triggeraktionsdaten hervorgeht.
  • 39 ist ein Flussdiagramm einer Operation eines Empfangsgeräts 300 in dem Fall, dass ein Trigger nach einer Ausführungsform mit einem Triggerstromdeskriptor übertragen wird.
  • Wenn ein physischer Sendekanal in der Operation S3000 ausgewählt wird und ein von einem Tuner ausgewählter Kanal eingestellt wird, empfängt das Empfangsgerät 300 in der Operation S4000 die VCT und PMT von einem über den eingestellten physischen Sendekanal empfangenen Sendesignal mittels des Demodulators 310 und des Demultiplexers 320. Das Sendesignal enthält VCT und PMT, und der Trigger-Signalisierungsdatenempfänger 332 oder der PSI-/PSIP-Abschnittshandler parst die empfangenen VCT und PMT.
  • Außerdem bestätigt der Trigger-Signalisierungsdatenempfänger 332, ob ein Trigger von der VCT und PMT an einen entsprechenden virtuellen Kanal gesendet wird. Hierzu stellt der Trigger-Signalisierungsdatenempfänger 332 in der Operation S4020 fest, ob ein trigger_stream_descriptor in der ES_descriptor-Schleife vorliegt, der einem entsprechenden virtuellen Kanal entspricht. Ob ein trigger_stream_descriptor vorliegt, bestimmt sich danach, ob ein stream_type Wert 0x06 (synchronisiertes Datenstreaming) und ein descriptor_tag-Feld eines entsprechenden Deskriptors identisch mit einem Wert ist, der derart eingestellt ist, dass er einem trigger_stream_descriptor entpsircht, nachdem in einer ES_descriptor-Schleife nach Deskriptoren gesucht worden ist.
  • Wird festgestellt, dass trigger_stream_desciptor aus der PMT nicht identifiziert wird und daher kein trigger_stream_descriptor vorliegt, da ein entsprechender virtueller Kanal keinen Trigger sendet, funktioniert das Empfangsgerät 300 in der Operation S4025 im entsprechenden virtuellen Kanal bestimmungsgemäß.
  • Wenn dann ein trigger_stream_descriptor vorliegt, extrahiert der Trigger-Signalisierungsdatenempfänger 332 in der Operation S4030 die Elementary_PID in der entsprechenden ES_loop der PMT. Bei der extrahierten stream_PID kann es sich um einen PID-Wert eines Stroms, der einen Triggerstrom enthält.
  • Dann empfängt der Triggerempfänger 331 MPEG-2 TS-Pakete, die der extrahierten stream_PID entsprechen, und entkapselt sie (d.h. entfernt einen TS-Kopf), um den PES-Strom wiederherzustellen, der den Triggerstrom enthält. Der stream_type eines PES-Pakets, das den Triggerstrom enthält, kann 0x06, was einem synchronisierten Datenstrom entspricht. Der Triggerempfänger 331 parst mindestens eines von PTS eines PES-Paketkopfes vom wiederhergestellten PES-Strom, einer Ziel-TDO-Kennung im Triggerstrom, einer Triggerkennung oder Triggeraktionsdaten in der Operation S4040.
  • Dann führt der Servicemanager 350 in der Operation S4050 eine Aktion am Ziel-TDO zur Triggerzeit mittels der PTS des PES-Paketkopfes, der als Triggerzeit einen Trigger enthält, aus. Hier kann es sich beim Ziel-TDO um den aus der geparsten Ziel-TDO-Kennung hervorgehenden NRT-Dienst handeln. Außerdem kann es sich bei der Aktion um einen Vorbereitungs-, Ausführungs-, Suspendierungs- oder Beendungsbefehl handeln, der aus den geparsten Triggeraktionsdaten hervorgeht.
  • 40 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit einem Stromtyp übertragen wird.
  • Wenn ein physischer Sendekanal ausgewählt wird und ein von einem Tuner ausgewählter Kanal eingestellt wird, empfängt das Empfangsgerät 300 die VCT und PMT von einem über den eingestellten physischen Sendekanal empfangenen Sendesignal mittels des Demodulators 310 und des Demultiplexers 320. Das Sendesignal enthält VCT und PMT, und der Trigger-Signalisierungsdatenempfänger 332 oder der PSI-/PSIP-Abschnittshandler parst in der Operation S400 die empfangenen VCT und PMT.
  • Außerdem bestätigt der Trigger-Signalisierungsdatenempfänger 332, ob ein Trigger von der VCT und PMT an einen entsprechenden virtuellen Kanal gesendet wird. Hierzu stellt der Trigger-Signalisierungsdatenempfänger 332 in der Operation S410 fest, ob 0x96, d.h. der spezifische Stromtyp in der ES_descriptor-Schleife vorliegt, der einem entsprechenden virtuellen Kanal entspricht.
  • Wird festgestellt, dass 0x96 aus dem Stromtyp nicht identifiziert wird und daher kein Stromtyp vorliegt, da ein entsprechender virtueller Kanal keinen Trigger sendet, funktioniert das Empfangsgerät 300 in der Operation S415 im entsprechenden virtuellen Kanal bestimmungsgemäß.
  • Wenn dann der Stromtyp 0x96 ist, extrahiert der Trigger-Signalisierungsdatenempfänger 332 in der Operation S420 die Elementary_PID in der entsprechenden ES_loop der PMT. Bei der extrahierten stream_PID kann es sich um einen PID-Wert eines Stroms, der einen Triggerstrom enthält.
  • Dann empfängt der Triggerempfänger 331 MPEG-2 TS-Pakete, die der extrahierten stream_PID entsprechen, und entkapselt sie (d.h. entfernt einen TS-Kopf), um den PES-Strom wiederherzustellen, der den Triggerstrom enthält. Der Triggerempfänger 331 parst mindestens eines von PTS eines PES-Paketkopfes vom wiederhergestellten PES-Strom, einer Ziel-TDO-Kennung im Triggerstrom, einer Triggerkennung oder Triggeraktionsdaten in der Operation S430.
  • Dann führt der Servicemanager 350 in der Operation S440 eine Aktion am Ziel-TDO zur Triggerzeit mittels der PTS des PES-Paketkopfes, der als Triggerzeit einen Trigger enthält, aus. Hier kann es sich beim Ziel-TDO um den aus der geparsten Ziel-TDO-Kennung hervorgehenden NRT-Dienst handeln. Außerdem kann es sich bei der Aktion um einen Vorbereitungs-, Ausführungs-, Suspendierungs- oder Beendungsbefehl handeln, der aus den geparsten Triggeraktionsdaten hervorgeht.
  • 41 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit AIT übertragen wird.
  • Der Trigger-Signalisierungsdatenempfänger 332 empfängt AIT mittels des Demodulators 310 und des Demultiplexers 320 in der Operation S500.
  • Außerdem bestätigt der Trigger-Signalisierungsdatenempfänger 332, ob ein Trigger von der AIT gesendet wird. Hierzu bestätigt der Trigger-Signalisierungsdatenempfänger 332 in der Operation S510, ob ein trigger_descriptor in der AIT vorhanden ist.
  • Wird festgestellt, dass kein trigger_descriptor vorhanden ist, da eine entsprechende Anwendung keinen Trigger enthält, funktioniert das Empfangsgerät 300 in der Operation S515 dem entsprechenden Anwendungsdienst entsprechend bestimmungsgemäß.
  • Außerdem, wenn ein Triggerdeskriptor vorhanden ist, extrahiert der Triggerempfänger 332 Triggerdaten aus dem Triggerdeskriptor und parst die extrahierten Triggerdaten, um sie in der Operation S530 an den Servicemanager 350 zu senden.
  • Dann führt der Servicemanager 350 in der Operation S540 eine Aktion am Ziel-TDO zur Triggerzeit mittels der geparsten Triggerdaten aus. Hier kann es sich beim Ziel-TDO um den aus der geparsten Ziel-TDO-Kennung hervorgehenden NRT-Dienst handeln. Außerdem kann es sich bei der Aktion um einen Vorbereitungs-, Ausführungs-, Suspendierungs- oder Beendungsbefehl handeln, der aus den geparsten Triggeraktionsdaten hervorgeht.
  • 42 ist ein Flussdiagramm einer Operation eines Empfangsgeräts in dem Fall, dass ein Trigger nach einer Ausführungsform mit STT übertragen wird.
  • Der Trigger-Signalisierungsdatenempfänger 332 empfängt SST mittels des Demodulators 310 und des Demultiplexers 320 in der Operation S600.
  • Außerdem bestätigt der Trigger-Signalisierungsdatenempfänger 332, ob ein Trigger von der STT gesendet wird. Hierzu bestätigt der Trigger-Signalisierungsdatenempfänger 332 in der Operation S610, ob ein trigger_descriptor in der STT vorhanden ist.
  • Wird festgestellt, dass kein trigger_descriptor vorhanden ist, da eine entsprechende STT keinen Trigger enthält, funktioniert das Empfangsgerät 300 in der Operation S615 dem Sendesignal entsprechend bestimmungsgemäß.
  • Außerdem, wenn ein Triggerdeskriptor vorhanden ist, extrahiert der Triggerempfänger 332 Triggerdaten aus dem Triggerdeskriptor und parst die extrahierten Triggerdaten, um sie in der Operation S630 an den Servicemanager 350 zu senden.
  • Dann führt der Servicemanager 350 in der Operation S540 eine Aktion am Ziel-TDO zur Triggerzeit mittels der geparsten Triggerdaten aus. Hier kann es sich beim Ziel-TDO um den aus der geparsten Ziel-TDO-Kennung hervorgehenden NRT-Dienst handeln. Außerdem kann es sich bei der Aktion um einen Vorbereitungs-, Ausführungs-, Suspendierungs- oder Beendungsbefehl handeln, der aus den geparsten Triggeraktionsdaten hervorgeht.
  • Nachfolgend wird ein Triggerdaten-Übertragungsmuster gemäß einer Ausführungsform der vorliegenden Erfindung unter Bezugnahme auf die 43 und 44 beschrieben. Vor allem wird ein Übertragungsmuster für Aktivierungs-Triggerdaten beschrieben.
  • In einer Ausführungsform kann es sich bei Triggerdaten, die eine als der Aktivierung entsprechender Wert eingestellte Triggeraktion enthalten, um Aktivierungs-Triggerdaten handeln. Die Aktivierungs-Triggerdaten lösen die Aktivierung (Ausführung) eines einer target_service_ID entsprechenden Objektes aus.
  • 43 ist ein Zeitdiagramm nach einer Ausführungsform der vorliegenden Erfindung.
  • Wie in 43 gezeigt, da das Sendegerät 200 nicht unbedingt weiß, wann das Empfangsgerät 300 einen Kanal wechselt, wenn das Empfangsgerät 300 eingeschaltet ist, und wenn das Empfangsgerät 300 einen Kanal auswählt, in dem ein entsprechender NRT-Dienst vorhanden ist, kann das Sendegerät 200 heruntergeladene Inhalte, die auf NRT-Art übertragen wurden, wiederholt und in regelmäßigen Abständen terrestrich senden.
  • Aus diesem Grund kann das Sendegerät 200 die Aktivierungs-Triggerdaten in regelmäßigen Abständen übertragen. Wenn jedoch die Aktivierungs-Triggerdaten in sehr kurzen Zeiträumen gesendet werden, kann es zu einer Overheadsituation des Empfängers 300 kommen, da es die Aktivierungs-Triggerdaten in regelmäßigen Abständen überprüfen muss. Wenn andererseits die Aktivierungs-Triggerdaten in sehr langen Zeiträumen gesendet werden, kann das Empfangsgerät 300 die empfangenen NRT-Daten nicht aktivieren, obwohl es die den Aktivierungs-Triggerdaten entsprechenden NRT-Daten empfangen hat. Deshalb müssen die Aktivierungs-Triggerdaten rechtzeitig übertragen werden.
  • In 43 zeigt eine Aktivationszeit T1, wann die Aktivierung eines NRT (T1)-Dienstes ausgelöst wird. Eine tatsächliche Zeit Te zeigt, wann der NRT (T1) die letzte Sendung vor der Aktivationszeit T1 anfängt. Eine Veränderungszeit einer Sendungsdauer To zeigt, wann sich eine Sendungsdauer der Aktivierungs-Triggerdaten ändert. Die Veränderungszeit der Sendungsdauer To ist ein Zeitparameter, der vom Sendegerät 200 festgelegt werden kann. Ein Zeitfenster Tp1 zeigt den Abschnitt vor der tatsächlichen Zeit T2. Ein Zeitfenster Tp2 zeigt den Abschnitt zwischen der tatsächlichen Zeit T2 und der Aktivationszeit T1. Ein Zeitfenster Tp3 zeigt den Abschnitt zwischen der tatsächlichen Zeit Te und der Veränderungszeit der Sendungsdauer To. Ein Zeitfenster Tp4 zeigt den Abschnitt zwischen der Veränderungszeit der Sendungsdauer To und der Aktivationszeit T1.
  • Um den NRT-(T1) Dienst zur Aktivationszeit T1 auszuführen, muss das Empfangsgerät 300 den Empfang und die Speicherung des NRT-(T1) Dienstes vor der Aktivationszeit T1 abschließen und die Aktivierungs-Triggerdaten für den NRT-(T1) Dienst empfangen. Hierzu, wenn das Empfangsgerät 300 einen Kanal einstellt, der den NRT-(T1) Dienst vor der tatsächlichen Zeit Te sendet und diesen Kanal solange beibehält, bis der Empfang des NRT-(T1) Dienstes abgeschlossen ist, kann das Empfangsgerät 300 den NRT-(T1) Dienst vor der Aktivationszeit T1 speichern. Selbst wenn die Aktivierungs-Triggerdaten im Zeitfenster Tp2 gesendet werden, kann das Empfangsgerät 300 den NRT-(T1) Dienst also nicht empfangen, und es kann sein, dass die Sendung der Aktivierungs-Triggerdaten im Zeitfenster Tp2 sinnlos ist.
  • Wenn das Empfangsgerät 300 jedoch auf einen anderen Kanal wechselt, nachdem es den Kanal eingestellt hat, der den NRT-(T1) Dienst im Zeitfenster Tp1 sendet, und den Empfang des NRT-(T1) Dienstes dann abgeschlossen hatte, kann das Empfangsgerät 300 den NRT-(T1) Dienst beibehalten, wenn das Empfangsgerät 300 auf den Kanal wechselt, der den NRT-(T1) Dienst im Zeitfenster Tp2 sendet. So muss das Sendegerät 200 die Aktivierungs-Triggerdaten im Zeitfenster Tp2 senden.
  • Das Sendegerät 200 kann das Zeitfenster Tp3 vom Zeitfenster Tp4 anhand der Veränderungszeit der Sendungsdauer To unterscheiden, um die Aktivierungs-Triggerdaten zu senden. Vor der Veränderungszeit der Sendungsdauer To, da mindestens eine Zeit vorliegt, die dem Zeitfenster Tp4 entspricht, bis der NRT-(T1) Dienst ausgeführt wird, sendet das Sendegerät die Aktivierungs-Triggerdaten in einem langen Zeitraum. In diesem Fall kann das Sendegerät 200 die Aktivierungs-Triggerdaten durch n * Tp4-Zeit übertragen.
  • Da andererseits eine kurze Dauer zwischen der Veränderungszeit der Sendungsdauer To und der Aktivationszeit T1, bis der NRT-(T1) Dienst ausgeführt wird, kann das Sendegerät 200 die Aktivierungs-Triggerdaten in einem kurzen Zeitraum senden. In diesem Fall kann das Sendegerät 200 die Aktivierungs-Triggerdaten mehrfach M sendung, wobei M der Anzahl der Kurzzeit-Sendungen (Kurzeit-Sendungszahl) entspricht. In diesem Fall kann der kurze Zeitraum P (Tp4) [Tp4/M]. [] bedeutet ein Gauß-Symbol. Die Kurzzeit-Sendungszahl M kann unter Berücksichtigung der Kanalwechselzeit des Empfängers 300 festgelegt werden. Wenn also das Empfangsgerät 300 auf einen Kanal wechselt, der den NRT-(T1) Dienst P (Tp4) früher als die Aktivationszeit T1 bereitstellt, kann der NRT-(T1) Dienst auf normale Art bereitgestellt werden.
  • Wenn das Empfangsgerät 300 einen Kanal einstellt, der einen T1-Dienst zwischen T1 - P (Tp4) und der Aktivationszeit T1 sendet, kann der NRT-(T1) Dienst nicht auf normale Weise bereitgestellt werden; diese Situation ist jedoch weniger wahrscheinlich, da nur eine kurze Zeit zur Verfügung steht. Außerdem kann dieser Fall um Wartungs-Triggerdaten ergänzt werden.
  • Obwohl die tatsächliche Zeit T2 vor der Veränderungszeit der Sendungsdauer To liegt, ist die vorliegende Erfindung darauf nicht beschränkt. D.h., die Veränderungszeit der Sendungsdauer To kann vor der tatsächlichen Zeit Te liegen.
  • 44 ist ein Flussdiagramm eines Verfahrens zur Übertragung von Aktivierungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
  • Erstens stellt die Trigger-Sendeeinheit 220 in der Operation S5101 die Aktivationszeit T1 des NRT-Dienstes (T1) ein, der ein Zielobjekt ist, stellt die Veränderungszeit der Sendungsdauer To in der Operation S5103 ein und stellt die Kurzzeit-Sendungszahl M in der Operation S5105 ein.
  • Liegt die aktuelle Systemszeit t vor der Veränderungszeit der Sendungsdauer To, überträgt die Trigger-Sendeeinheit 220 in der Operation S5107 die Aktivierungs-Triggerdaten für den NRT-(T1) Dienst in einem langen Zeitraum in der Operation S5109. In diesem Fall kann die Trigger-Sendeeinheit 220 die Aktivierungs-Triggerdaten durch n * Tp4-Zeit übertragen.
  • Liegt die aktuelle Systemszeit t vor der Veränderungszeit der Sendungsdauer To und vor der Aktivationszeit T1 des NRT-(T1) Dienstes, überträgt die Trigger-Sendeeinheit 220 in der Operation S5111 die Aktivierungs-Triggerdaten für den NRT-(T1) Dienst in einem kurzen Zeitraum in der Operation S5113.
  • Liegt die aktuelle Systemszeit t nach der Aktivationszeit T1 des NRT-(T1) Dienstes, überträgt die Trigger-Sendeeinheit 220 in der Operation S5111 die Aktivierungs-Triggerdaten für den NRT-(T1) Dienst in der Operation S5115.
  • Nachfolgend wird ein Triggerdaten-Übertragungsmuster gemäß einer weiteren Ausführungsform der vorliegenden Erfindung unter Bezugnahme auf die 45 bis 47 beschrieben. Vor allem wird ein Übertragungsmuster für Wartungs-Triggerdaten (MTD) beschrieben.
  • In einer Ausführungsform kann es sich bei Triggerdaten, die eine als der Wartung entsprechender Wert eingestellte Triggeraktion enthalten, um Wartungs-Triggerdaten handeln.
  • Wenn ein Objekt, das einer Zieldienstkennung der Wartungs-Triggerdaten am Empfangsgerät 300 aktiviert wird, können die Wartungs-Triggerdaten die Beibehaltung der Aktivation des Objektes auslösen. Wenn das Objekt, das einer Zieldienstkennung der Wartungs-Triggerdaten am Empfangsgerät 300 nicht aktiviert wird, können die Wartungs-Triggerdaten außerdem die Aktivation des Objektes auslösen.
  • 45 ist ein Zeitdiagramm nach einer weiteren Ausführungsform der vorliegenden Erfindung.
  • In 45 zeigt eine Aktivationszeit Ta eine Aktivationszeit eines TDO, und eine Endzeit Tf zeigt eine Endzeit des TDO. Eine Zusatz-Aktionszeit Taction zeigt, wann eine Zusatzaktion für das TDO nach der AKtivationszeit Ta und vor der Endzeit Tf ausgelöst (aktiviert) wird. Ein Zeitfenster Tplife zeigt den Abschnitt zwischen der Aktivationszeit Ta und der Endzeit Tf, besonders aber die Lebensdauer des TDO. Ein Zeitfenster Tp1 zeigt den Abschnitt zwischen der Aktivationszeit Ta und der Zusatz-Aktionszeit Taction. Ein Zeitfenster Tp2 zeigt den Abschnitt zwischen der Zusatz-Aktionszeit Taction und der Endzeit Tf.
  • Wenn das Empfangsgerät 300 einen eingestellten Kanal vom Kanal A auf den Kanal B wechselt und dann zum Kanal A zurückkehrt, muss das Empfangsgerät 300 das vorher ausgeführte TDO erneut ausführen. Wenn alternativ ein NRT-Inhalts-TDO, das dem Kanal A entspricht, im Empfangsgerät 300 im Voraus gespeichert wird und das Empfangsgerät 300 nach der Aktivationszeit Ta des TDO zum Kanal A zurückkehrt, muss das Empfangsgerät 300 das TDO ausführen. Hierzu kann das Sendegerät 200 gemäß einer Ausführungsform der vorliegenden Erfindung Wartungs-Triggerdaten übertragen.
  • Hat das Empfangsgerät 300 diesen NRT-Inhalt heruntergeladen und gespeichert, kann es sein, dass das Empfangsgerät 300 in den nachfolgenden Fällen MTD benötigt. D.h., wenn das Empfangsgerät 300 einen eingestellten Kanal vom Kanal A auf den Kanal B wechselt und dann innerhalb des Zeitfensters Tplife zum Kanal A zurückkehrt, wird die MTD u.U. vom Empfangsgerät 300 benötigt. Wenn außerdem das Empfangsgerät 300 ausgeschaltet ist und dann beim Kanal A wieder eingeschaltet wird und innerhalb des Zeitfensters Tplife zum Kanal A zurückkehrt, wird die MTD u.U. vom Empfangsgerät 300 benötigt. Wenn das Empfangsgerät 300 den eingestellten Kanal vom Kanal A auf den Kanal B innerhalb des Zeitfensters Tplife wechselt, und dann innerhalb des Zeitfensters Tplife zum Kanal A zurückkehrt, wird die MTD u.U. vom Empfangsgerät 300 benötigt. Wenn das Empfangsgerät 300 ausgeschaltet ist und dann beim Kanal A wieder innerhalb des Zeitfensters Tplife eingeschaltet wird und innerhalb des Zeitfensters Tplife zum Kanal A zurückkehrt, wird die MTD u.U. vom Empfangsgerät 300 benötigt.
  • Wird die MTD benötigt, sendet das Sendegerät 200 die MTD weiterhin innerhalb des Zeitfensters Tplife, wodurch ein mit der MTD in Verbindung stehendes TDO erneut ausgeführt werden kann. Die Sendungsdauer Pmtd einer MTD kann unter Berücksichtigung des Umstandes eingestellt werden, ob das Empfangsgerät 300 ein- oder ausgeschaltet ist und wann ein Kanalwechsel erfolgt.
  • 45 zeigt ein Beispiel, in dem eine TDO-Aktion zum Zeitpunkt der Taction innerhalb des Zeitfensters Tplife einmal ausgeführt wird. In diesem Fall kann das Sendegerät 200 eine MTD konfigurieren und innerhalb des Zeitfensters Tp1 in derselben Form übertragen wie eine ATD. Außerdem kann das Sendegerät 200 eine MTD derart konfigurieren und übertragen, dass eine konkrete Zusatz-Aktion der ATD hinzugefügt wird. Im Zeitfenster Tp2 nach der Ausführung der TDO-Aktion kann das Sendegerät 200 eine MTD in derselben Form wie die der TDO-Aktion entsprechenden Triggerdaten konfigurieren und übertragen, oder es kann eine MTD derart konfigurieren und übertragen, dass eine konkrete Zusatz-Aktion den der TDO-Aktion entsprechenden Triggerdaten hinzugefügt wird.
  • 46 ist ein Flussdiagramm eines Verfahrens zur Übertragung von Wartungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
  • Die Trigger-Sendeeinheit 220 stellt in der Operation S5201 für ein TDO ein, das ein Zielobjekt ist, eine Aktivationszeit Ta ein.
  • Die Trigger-Sendeeinheit 220 legt in der Operation S5203 eine Sendungsdauer einer MTD Pmtd für das Zielobjekt fest. Die Sendungsdauer der MTD Pmtd kann als vorbestimmter Wert eingestellt werden. Die Sendungsdauer Pmtd der MTD kann außerdem unter Berücksichtigung des Umstandes eingestellt werden, ob das Empfangsgerät 300 ein- oder ausgeschaltet ist und wann ein Kanalwechsel erfolgt.
  • Liegt die aktuelle Systemszeit t vor der Aktivationszeit T1 des Zielobjektes in Operation S5205, überträgt die Trigger-Sendeeinheit 220 in der Operation S5207 die MTD des Zielobjektes nicht.
  • Liegt die aktuelle Systemszeit t nach der Aktivationszeit Ta des Zielobjektes und vor einer Endzeit Tf des Zielobjektes, bestätigt die Trigger-Sendeeinheit 220 in der Operation S5211, ob die Triggerdaten verändert worden sind.
  • Sind die Triggerdaten verändert worden, überträgt die Trigger-Sendeeinheit 220 in der Operation S5213 die veränderten Triggerdaten und die Wartungs-Triggerdaten, die eine Zusatz-Aktion enthalten.
  • Sind die Triggerdaten nicht verändert worden, überträgt die Trigger-Sendeeinheit 220 in der Operation S5215 die unveränderten Triggerdaten und die Wartungs-Triggerdaten, die die Zusatz-Aktion enthalten.
  • Liegt die aktuelle Systemszeit t nach der Endzeit Tf des Zielobjektes, stellt die Trigger-Sendeeinheit 220 in der Operation S5217 die Sendung der Wartungs-Triggerdaten ein.
  • 47 zeigt, wie Wartungstriggerdaten nach einer nach einer Ausführungsform der vorliegenden Erfindung empfangen werden.
  • Zunächst empfängt der Triggerempfänger 331 des Empfangsgeräts 300 die Wartungs-Triggerdaten in der Operation S5301. Der Empfang der Wartungs-Triggerdaten kann gemäß verschiedenen oben beschriebenen Ausführungsformen erfolgen.
  • Wenn ein Objekt, das einer Zieldienstkennung der Wartungs-Triggerdaten entspricht, in der Operation S5303 bereits aktiviert worden ist, behält ein Servicemanager 350 des Empfangsgeräts 300 die Aktivation des Objektes in der Operation S5305 bei.
  • Wenn ein Objekt, das einer Zieldienstkennung der Wartungs-Triggerdaten entspricht, in der Operation S5303 noch nicht aktiviert worden ist, aktiviert der Servicemanager 350 des Empfangsgeräts 300 das Objekt in der Operation S5305.
  • Nachfolgend wird eine Empfangszeit der Triggerdaten gemäß einer Ausführungsform der vorliegenden Erfindung unter Bezugnahme auf die 48 bis 50 beschrieben. Vor allem wird die Empfangszeit der PTD (Vorbereitungs-Triggerdaten) beschrieben.
  • In einer Ausführungsform kann es sich bei Triggerdaten, die eine als der Vorbereitung entsprechender Wert eingestellte Triggeraktion enthalten, um Vorbereitungs-Triggerdaten handeln. Durch Parsen der Vorbereitungs-Triggerdaten ist es möglich, eine Zieldienstkennung für die Vorbereitung sowie eine Vorbereitungs-Triggerzeit zu erhalten. Die Vorbereitungs-Triggerdaten lösen die Vorbereitung eines der target_service_ID entsprechenden Objektes aus.
  • Das Sendegerät 200 kann Vorbereitungs-Triggerdaten eines TDO liefern, die vor der Aktivationszeit im Voraus verarbeitet werden müssen, wobei es sich um einen Trigger der nachfolgenden Vorverarbeitung handelt.
  • Wenn vor der Aktivationszeit ein Internetanschluss überprüft und ein mit dem TDO in Verbindung stehender herunterladbarer Inhalt heruntergeladen werden muss, können die Vorbereitungs-Triggerdaten gesendet werden.
  • Wenn außerdem das TDO im Hintergrund aktiviert werden muss, da die Erstellung einer Benutzeroberfläche lange dauert, können die Vorbereitungs-Triggerdaten gesendet werden. Dies kann dann der Fall sein, wenn eine Decodierung im Voraus erfolgen muss, da viele Daten wie z.B. Bilddaten zur Verwendung bei der Erstellung der Benutzeroberfläche vorliegen, oder die Erstellung der Benutzeroberfläche unter Verwendung der mit dem TDO in Verbindung stehenden Metadaten lange dauert. Außerdem kann dies dann der Fall sein, wenn ein web-basiertes TDO im Voraus heruntergeladen werden muss.
  • Um die Zugriffsmöglichkeit auf einen Server im Voraus zu überprüfen oder eine Verbindung zum Server im Voraus herzustellen, können die Vorbereitungs-Triggerdaten gesendet werden.
  • Die oben erwähnten Vorverarbeitungsmaßnahmen können miteinander kombiniert werden.
  • 48 ist ein Zeitdiagramm nach einer Ausführungsform der vorliegenden Erfindung.
  • In 48 zeigt eine Vorbereitungs-Triggerzeit Tp, wann die Vorbereitung des TDO durch eine PTD ausgelöst wird. Eine Aktivationszeit Ta zeigt, wann das TDO aktiviert wird, und eine Endzeit Tf zeigt, wann das TDO beendet wird.
  • Ein Zeitfenster Tpa zeigt den Abschnitt zwischen der Vorbereitungs-Triggerzeit Tp und der Aktivations-Triggerzeit Ta, und das Zeitfenster Tplife zeigt dabei den Abschnitt zwischen der Aktivationszeit Ta und der Endzeit Tf.
  • Das Zeitfenster Tpa kann je nach Vorverarbeitungsmaßnahme variieren.
  • Empfängt das Empfangsgerät 300 die mit dem Download von Inhalten in Verbindung stehenden Vorbereitungs-Triggerdaten, kann es besser sein, den Inhalt möglichst bald herunterzuladen. Hierzu kann das Sendegerät 200 gemäß einer Ausführungsform der vorliegenden Erfindung Vorbereitungs-Triggerdaten übertragen, die eine auf 0 eingestellte Vorbereitungs-Triggerzeit aufweisen. D.h., wenn das Empfangsgerät 300 die Vorbereitungs-Triggerzeit mit der auf 0 eingestellten Vorbereitungs-Triggerzeit empfängt, kann das Empfangsgerät 300 mit dem Download des Inhalts sofort anfangen.
  • Das Empfangsgerät 300 kann beim Empfang einer PTD für ein TDO, für das die herunterzuladenden Inhalte zur Aktivations- oder Triggervorbereitung des TDO benötigt werden, unmittelbar vor der Aktivationszeit Ta scheitern. Wird der Inhalt nicht heruntergeladen, obwohl der herunterzuladende Inhalt zur Aktivierung des TDO benötigt wird, kann das Empfangsgerät 300 das TDO zur Aktivationszeit Ta nicht aktivieren oder den Inhalt nach der Aktivation herunterladen. Enthält eine TDO-Aktion derartige Daten, kann das Empfangsgerät 300 bestimmen, dass das TDO aufgrund der TDO-Aktion aktiviert wird.
  • Das Sendegerät 200 kann die Vorbereitungs-Triggerzeit Tp eines TDO, das die Erstellung einer UI oder die Überprüfung eines Netzwerks benötigt, je nach der Art des TDO einstellen. Das Sendegerät 200 kann eine PTD mit einer auf Tp eingestellten Triggerzeit weiterhin senden, und zwar ebenfalls innerhalb des Zeitfensters Tpa.
  • Das Empfangsgerät 300 vergleicht die Vorbereitungs-Triggerzeit Tp mit der aktuellen Systemzeit, und, wenn die aktuelle Systemzeit nach der Vorbereitungs-Triggerzeit Tp liegt, fängt das Empfangsgerät 300 an, das TDO vorzubereiten, sobald die PTD eingeht, um die Vorbereitung des TDO möglichst bald vor der Aktivationszeit Ta abschließen zu können.
  • 49 ist ein Zeitdiagramm eines Verfahrens zum Empfang von Vorbereitungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
  • Im Einzelnen zeigt 49 ein Verfahren zur Verarbeitung von Vorbereitungs-Triggerdaten zum Download.
  • Erstens empfängt eine Trigger-Empfangseinheit 331 des Empfängers 300 in der Operation S5401 Vorbereitungs-Triggerdaten, und die Vorbereitungs-Triggerdaten werden in der Operation S5403 geparst und gespeichert. Der Empfang der Vorbereitungs-Triggerdaten kann gemäß verschiedenen oben beschriebenen Ausführungsformen erfolgen, in denen die Triggerdaten empfangen werden.
  • Wenn es sich bei den empfangenen Vorbereitungs-Triggerdaten nicht um Vorbereitungs-Triggerdaten zum Download in der Operation S5405 handelt, verarbeitet ein Servicemanager 350 die empfangenen Vorbereitungs-Triggerdaten als Vorbreitungs-Triggerdaten einer anderen Art in der Operation S5407.
  • Wenn es sich bei den empfangenen Vorbereitungs-Triggerdaten nicht die Vorbereitungs-Triggerdaten zum Download in der Operation S5405 handelt, bestätigt der Servicemanager 350 eine Internetverbindung in der Operation S5407.
  • Ist die Internetverbindung nicht normal, ignoriert der Servicemanager 350 die empfangene PTD in der Operation S5411. Der Servicemanager 350 kann die empfangene PTD speichern und ignorieren, aber nicht löschen, um die Last der Verarbeitung einer kontinuierlich empfangenen herunterzuladenden PTD zu reduzieren. Wenn ein mit der herunterzuladenden PTD in Verbindung stehendes TDO eingestellt wird, kann der Servicemanager 350 die empfangene PTD löschen.
  • Ist die Internetverbindung normal, fängt der Servicemanager 350 zur Triggerzeit der empfangenen Vorbereitungs-Triggerdaten an, den Inhalt in der Operation S5413 herunterzuladen. In diesem Fall kann der Dienstmanager 350 im Hintergrund das einer Zieldienstkennung der empfangenen Vorbereitungs-Triggerdaten entsprechende TDO aktivieren, damit das aktivierte TDO Inhalte herunterlädt. Außerdem kann der Servicemanager 350 die Zieldienstkennung und eine Download-URL einem Downloadmanager bereitstellen, damit der Downloadmanager die Inhalte herunterlädt.
  • Das aktivierte TDO oder der Downloadmanager speichert die heruntergeladenen Inhalte in der Operation S4515. Wenn der Downloadmanager die Inhalte herunterlädt, speichert der Downloadmanager die heruntergeladenen Inhalte in Verbindung mit der Zieldienstkennung.
  • 50 ist ein Flussdiagramm eines Verfahrens zum Empfang von Vorbereitungstriggerdaten nach einer Ausführungsform der vorliegenden Erfindung.
  • Vor allem zeigt 50, wie eine PTD zu verarbeiten ist, die den Hintergrund eines TDO aktivieren muss, um das TDO vorzubereiten.
  • Erstens empfängt eine Trigger-Empfangseinheit 331 des Empfängers 300 in der Operation S5501 Vorbereitungs-Triggerdaten, und die Vorbereitungs-Triggerdaten werden in der Operation S5503 geparst und gespeichert. Der Empfang der Vorbereitungs-Triggerdaten kann gemäß verschiedenen oben beschriebenen Ausführungsformen erfolgen, in denen die Triggerdaten empfangen werden. Durch Parsen der empfangenen Vorbereitungs-Triggerdaten ist es möglich, eine Zieldienstkennung sowie eine Vorbereitungs-Triggerzeit zu erhalten.
  • Liegt die aktuelle Systemzeit t nach der Vorbereitungs-Triggerzeit Tp in der Operation 5505, aktiviert der Servicemanager 350 ein einer Zieldienstkennung der Vorbereitungs-Triggerdaten entsprechendes TDO im Hintergrund in der Operation 5507. Mit anderen Worten: Liegt die Empfangszeit der PTD vor der Vorbereitungs-Triggerzeit Tp, aktiviert der Servicemanager 350 das TDO im Hintergrund, wenn die Empfangszeit die Vorbereitungs-Triggerzeit Tp erreicht. Liegt die Empfangszeit der PTD nach der Vorbereitungs-Triggerzeit Tp, aktiviert der Servicemanager 350 das TDO sofort im Hintergrund. In diesem Fall behält der Servicemanager 350 selbst dann den Hintergrundzustand bei, ohne das TDO einzustellen, wenn der eingestellte Kanal des Empfängers 300 gewechselt wird.
  • Liegt die aktuelle Systemzeit t nach der Aktivationszeit Ta des TDO, wechselt der Servicemanager 350 den Zustand des TDO zum Vordergrund in der Operation S5511. Vor allem wenn das Empfangsgerät 300 zu einem Dienstkanal des TDO zwischen der Aktivationszeit Ta des TDo und einer Endzeit Tf des TDO zurückkehrt, wechselt der Servicemanager 350 den Zustand des TDO in den Vordergrund.
  • Liegt die aktuelle Systemszeit t nach der Endzeit des TDO in der Operation S5513, stellt der Servicemanager 350 in der Operation S5515 das TDO ein. Vor allem wenn ein TDO im Hintergrund aktiviert ist und nicht in den Vordergrund überführt wird, stellt der Servicemanager 350 ein derartiges TDO ein. In diesem Fall muss der Servicemanager 350 wissen, wann das TDO endet. Hierzu kann die ATD die Endzeit des TDO enthalten.
  • Erfindungsgemäße Triggerempfangs- und -sendeverfahren können in dem computerlesbaren Aufzeichnungsmedium gespeichert werden, das ROM, RAM, CD-ROM, Magnetbänder, Disketten, optische Datenspeichergeräte und Trägerwellen (wie z.B. Datenübertragung über das Internet) umfasst.
  • Das computerlesbare Aufzeichnungsmedium kann auch über netzwerkgekoppelte Rechensysteme verteilt werden, so dass der computerlesbare Code auf verteilte Art gespeichert und ausgeführt wird. (Außerdem können funktionelle Programme, Codes und Codesegmente zur Ausführung der vorliegenden Erfindung vom Fachmann auf dem erfindungsrelevanten Fachgebiet ohne Schwierigkeit erzeugt werden).
  • Außerdem, obwohl Ausführungsbeispiele oben gezeigt und beschrieben wurden, ist die vorliegende Erfindung nicht auf die konkreten oben beschriebenen Ausführungsformen beschränkt, vielmehr kann sie vom Fachmann modifiziert werden, ohne den in den nachfolgenden Patentansprüchen beanspruchten Schutzumfang der vorliegenden Erfindung zu verlassen. Außerdem sind diese Varianten nicht einzeln unter Berücksichtigung des technischen Geistes oder Perspektive der vorliegenden Erfindung aufzufassen.

Claims (8)

  1. Verfahren für eine Ausstrahlungsempfängervorrichtung zum Empfangen einer Ausstrahlung, umfassend: Empfangen eines Ausstrahlungs-Stream, der Medien enthält, darunter Audio oder Video; Erhalten einer IP-Adresse für einen ersten Auslöser aus dem Ausstrahlungs-Stream; Empfangen (S240) eines ersten Auslösers mit der IP-Adresse, wobei der erste Auslöser Informationen enthält, die eine Kennung zum Identifizieren eines ausgelösten deklarativen Objekts (TDO, Triggered Declarative Object) repräsentieren, Informationen, die eine erste Auslöserzeit repräsentieren, und Informationen, die eine erste Auslöseraktion repräsentieren und wobei die erste Auslöseraktion eine Vorbereitung repräsentiert; Extrahieren (S240) der Informationen, die die Kennung repräsentieren, der Informationen, die die erste Auslöserzeit repräsentieren, und der Informationen, die die erste Auslöseraktion repräsentieren, aus dem ersten Auslöser; Durchführen (S250) der ersten Auslöseraktion in der ersten Auslöserzeit für das durch die Kennung identifizierte TDO, wenn eine Empfangszeit des ersten Auslösers vor der ersten Auslöserzeit liegt; und sofortiges Durchführen der ersten Auslöseraktion für das durch die Kennung identifizierte TDO, wenn eine Empfangszeit des ersten Auslösers nach der ersten Auslöserzeit liegt, wobei das TDO eine Nichtechtzeit-(NRT, non-real time service)-Dienst Anwendung ist, die von dem ersten Auslöser ausgelöst wird, wobei die Vorbereitung die Ausführung des TDO vorbereitet, damit das TDO zur Auslöserzeit reibungslos funktioniert.
  2. Verfahren nach Anspruch 1, wobei das Ausführen der ersten Auslöseraktion in der ersten Auslöserzeit umfasst: Vorbereiten des durch die Kennung identifizierten TDO in der ersten Auslöserzeit, wenn eine Empfangszeit des ersten Auslösers vor der ersten Auslöserzeit liegt, und wobei das sofortige Durchführen der ersten Auslöseraktion umfasst: sofortiges Vorbereiten des durch die Kennung identifizierten TDO, wenn eine Empfangszeit des ersten Auslösers nach der ersten Auslöserzeit liegt.
  3. Verfahren nach Anspruch 2, wobei das Vorbereiten des TDO zumindest eines des Folgenden umfasst: vorab Herunterladen eines herunterladbaren Inhalts, der mit dem TDO assoziiert ist, vorab Vorbereiten einer Benutzerschnittstelle für das TDO, und vorab Durchführen einer Verbindung zum Server für das TDO.
  4. Verfahren nach Anspruch 1, ferner umfassend: Herunterladen (S1110) des TDO von einem Nichtechtzeit-(NRT, Non-Real Time)-Dienst.
  5. Verfahren nach Anspruch 4, wobei das Herunterladen des TDO vom NRT-Dient umfasst: Erhalten (S1110) von NRT-Dienst-Zugriffsinformationen, zu denen das TDO gehört, aus einer NRT-Dienst-Tabelle (NST, NRT Service Table), und Herunterladen (S1110) des TDO von einem NRT-Dienst unter Verwendung der NRT-Dienst-Zugriffsinformationen, wobei die NRT-Dienst-Zugriffsinformationen Kanalinformationen oder IP-Adressinformationen zum Herunterladen des TDO beinhalten.
  6. Verfahren nach Anspruch 2, wobei das Vorbereiten des TDO umfasst: Ausführen des TDO im Hintergrund, um das TDO vorzubereiten; und das Ausführen des TDO im Hintergrund wird fortgeführt, auch wenn eine Kanaländerung zwischen der ersten Auslöserzeit und einer Aktivierungszeit des TDO erfolgt.
  7. Verfahren nach Anspruch 1, ferner umfassend: Empfangen eines zweiten Auslösers, enthaltend Informationen, die die Kennung repräsentieren, Informationen, die eine zweite Auslöserzeit repräsentieren, und Informationen, die eine zweite Auslöseraktion repräsentieren; und Durchführen der zweiten Auslöseraktion für das durch die Kennung identifizierte TDO in der zweiten Auslöserzeit, wobei die zweite Auslöseraktion die Ausführung repräsentiert.
  8. Verfahren nach Anspruch 1, wobei die erste Auslöserzeit mit den Medien, darunter das Audio oder Video, synchronisiert wird.
DE112011103965.4T 2010-12-26 2011-12-23 Verfahren zur Übertragung eines Rundfunkdienstes sowie Verfahren und Vorrichtung zum Empfang eines Rundfunkdienstes Active DE112011103965B4 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201061427199P 2010-12-26 2010-12-26
US61/427,199 2010-12-26
US201161429459P 2011-01-04 2011-01-04
US61/429,459 2011-01-04
PCT/KR2011/010051 WO2012091370A1 (ko) 2010-12-26 2011-12-23 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치

Publications (2)

Publication Number Publication Date
DE112011103965T5 DE112011103965T5 (de) 2013-08-22
DE112011103965B4 true DE112011103965B4 (de) 2018-11-15

Family

ID=46383334

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112011103965.4T Active DE112011103965B4 (de) 2010-12-26 2011-12-23 Verfahren zur Übertragung eines Rundfunkdienstes sowie Verfahren und Vorrichtung zum Empfang eines Rundfunkdienstes

Country Status (8)

Country Link
US (3) US8726328B2 (de)
EP (1) EP2658247A4 (de)
KR (2) KR101455557B1 (de)
CN (1) CN103283219B (de)
CA (1) CA2823037C (de)
DE (1) DE112011103965B4 (de)
GB (1) GB2501021B (de)
WO (1) WO2012091370A1 (de)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8422509B2 (en) 2008-08-22 2013-04-16 Lg Electronics Inc. Method for processing a web service in an NRT service and a broadcast receiver
WO2012099427A2 (ko) * 2011-01-19 2012-07-26 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
CN103959808A (zh) * 2011-12-02 2014-07-30 索尼公司 信息处理装置、信息处理方法以及程序
CA2859115C (en) * 2012-02-07 2020-01-21 Sony Corporation Receiving apparatus, receiving method, and program
WO2014025207A1 (en) * 2012-08-07 2014-02-13 Lg Electronics Inc. A method and an apparatus for processing a broadcast signal including an interactive broadcast service
KR102145744B1 (ko) 2013-06-12 2020-08-28 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CA3068668C (en) 2013-08-19 2022-04-12 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
CN105814897A (zh) * 2013-12-09 2016-07-27 Lg电子株式会社 处理包括广播内容和与广播内容有关的应用的广播信号的接收机和方法
WO2015102395A1 (en) 2014-01-02 2015-07-09 Lg Electronics Inc. Broadcast receiving device and operating method thereof
KR102163920B1 (ko) * 2014-01-03 2020-10-12 엘지전자 주식회사 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법
CN106464677A (zh) * 2014-04-09 2017-02-22 Lg电子株式会社 发送/接收广播信号的方法和设备
WO2015194904A1 (ko) * 2014-06-20 2015-12-23 삼성전자 주식회사 Ip 기반 방송 망에서 전송 패킷 압축 기법
KR101875667B1 (ko) * 2014-06-30 2018-07-06 엘지전자 주식회사 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
US10645674B2 (en) 2014-08-22 2020-05-05 Lg Electronics Inc. Method for transmitting broadcast signals, apparatus for transmitting broadcast signals, method for receiving broadcast signals and apparatus for receiving broadcast signals
JP6667128B2 (ja) 2014-08-28 2020-03-18 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
WO2016031173A1 (ja) 2014-08-28 2016-03-03 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
US9553843B1 (en) 2014-10-08 2017-01-24 Google Inc. Service directory profile for a fabric network
CN106961634B (zh) * 2017-03-31 2020-01-17 青岛海信电器股份有限公司 Vod视频结束播放后启动dtv信号的方法、装置和终端设备
US10575063B2 (en) * 2017-11-03 2020-02-25 Dish Network L.L.C. Message tunneling over closed captioning
DE112019007561T5 (de) * 2019-07-23 2022-04-21 Google Llc Funkfrequenzzustands-Bewusste Audiopufferung
KR102564057B1 (ko) 2022-04-04 2023-08-07 서울대학교산학협력단 오브젝트 레벨 혼잡 제어 장치 및 방법

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020056129A1 (en) * 1999-10-05 2002-05-09 Dean J. Blackketter Trigger having a time attribute
WO2007083824A1 (en) * 2006-01-17 2007-07-26 Matsushita Electric Industrial Co., Ltd. Method and apparatus for broadcast content related notification
US20090276819A1 (en) * 2008-05-02 2009-11-05 Jin Pil Kim Method of receiving broadcasting signal and apparatus for receiving broadcasting signal

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6006256A (en) * 1996-03-11 1999-12-21 Opentv, Inc. System and method for inserting interactive program content within a television signal originating at a remote network
US7584491B2 (en) * 2001-04-25 2009-09-01 Sony Corporation System and method for managing interactive programming and advertisements in interactive broadcast systems
JP2002344399A (ja) * 2001-05-16 2002-11-29 Matsushita Electric Ind Co Ltd 情報配信システム、情報配信装置、及び受信端末
JP2006311120A (ja) * 2005-04-27 2006-11-09 Matsushita Electric Ind Co Ltd デジタル放送受信装置
US20080072106A1 (en) * 2006-09-20 2008-03-20 Bruce Hamilton Method and system of specifying semantics of a late trigger
KR101581354B1 (ko) * 2008-03-07 2015-12-30 엘지전자 주식회사 방송 신호 수신 방법 및 방송 신호 수신 장치
KR101581359B1 (ko) * 2008-06-09 2015-12-30 엘지전자 주식회사 방송 신호 수신 방법 및 수신 시스템
US8099752B2 (en) * 2008-12-03 2012-01-17 Sony Corporation Non-real time services
US8863171B2 (en) * 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
US20120050619A1 (en) * 2010-08-30 2012-03-01 Sony Corporation Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020056129A1 (en) * 1999-10-05 2002-05-09 Dean J. Blackketter Trigger having a time attribute
WO2007083824A1 (en) * 2006-01-17 2007-07-26 Matsushita Electric Industrial Co., Ltd. Method and apparatus for broadcast content related notification
US20090276819A1 (en) * 2008-05-02 2009-11-05 Jin Pil Kim Method of receiving broadcasting signal and apparatus for receiving broadcasting signal

Also Published As

Publication number Publication date
CN103283219B (zh) 2016-08-31
GB2501021A (en) 2013-10-09
EP2658247A4 (de) 2014-12-31
GB201311853D0 (en) 2013-08-14
DE112011103965T5 (de) 2013-08-22
US9215497B2 (en) 2015-12-15
US20140304760A1 (en) 2014-10-09
GB2501021B (en) 2017-03-29
CN103283219A (zh) 2013-09-04
US8726328B2 (en) 2014-05-13
CA2823037C (en) 2016-05-24
EP2658247A1 (de) 2013-10-30
KR20130087584A (ko) 2013-08-06
KR101455557B1 (ko) 2014-11-04
CA2823037A1 (en) 2012-07-05
KR20140094628A (ko) 2014-07-30
US20160066065A1 (en) 2016-03-03
WO2012091370A1 (ko) 2012-07-05
US20130291050A1 (en) 2013-10-31

Similar Documents

Publication Publication Date Title
DE112011103965B4 (de) Verfahren zur Übertragung eines Rundfunkdienstes sowie Verfahren und Vorrichtung zum Empfang eines Rundfunkdienstes
DE112011103963B4 (de) Verfahren zum Übertragen eines Rundfunkdienstes, Verfahren zum Empfangen des Rundfunkdienstes und Vorrichtung zum Empfangen des Rundfunkdienstes
DE112011104029B4 (de) Rundfunkdienst-Sendeverfahren, Rundfunkdienst-Empfangsverfahren und Rundfunkdienst- Empfangsgerät
KR101695514B1 (ko) 방송 서비스 전송 방법, 그 수신 장치 및 그 수신 장치의 부가 서비스 처리 방법
KR101976052B1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
KR101703866B1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
CA2827370C (en) Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
KR101735881B1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
CA2824965C (en) Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
KR101713369B1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
CA2827384C (en) Apparatus and method for transmitting and receiving a broadcasting service

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final