DE112008000552B4 - Verfahren und Vorrichtung zum Empfangen von Rundfunk - Google Patents

Verfahren und Vorrichtung zum Empfangen von Rundfunk Download PDF

Info

Publication number
DE112008000552B4
DE112008000552B4 DE112008000552.4T DE112008000552T DE112008000552B4 DE 112008000552 B4 DE112008000552 B4 DE 112008000552B4 DE 112008000552 T DE112008000552 T DE 112008000552T DE 112008000552 B4 DE112008000552 B4 DE 112008000552B4
Authority
DE
Germany
Prior art keywords
field
information
channel
data
transport
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.)
Expired - Fee Related
Application number
DE112008000552.4T
Other languages
English (en)
Other versions
DE112008000552T5 (de
Inventor
Ga-hyun Ryu
Sung-II Park
Jong-Hwa Kim
Kyo-shin Choo
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of DE112008000552T5 publication Critical patent/DE112008000552T5/de
Application granted granted Critical
Publication of DE112008000552B4 publication Critical patent/DE112008000552B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/90—Wireless transmission systems
    • H04H60/91—Mobile communication networks
    • 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
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/65—Arrangements characterised by transmission systems for broadcast
    • H04H20/71—Wireless systems
    • H04H20/72—Wireless systems of terrestrial networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [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/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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport 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/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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/08—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Verfahren zum Empfangen eines Rundfunkdienstes für Mobilkommunikation, wobei das Verfahren umfasst:Bestimmen (8810) eines vorgegebenen Transportkanals unter Verwendung aus einem Dienstinformationskanal extrahierter Dienstkonfigurationsinformationen;Extrahieren (8820) eines Transportpaketes aus dem bestimmten Transportkanal;Extrahieren (8830) von Informationen bezüglich des Transportpaketes aus dem extrahierten Transportpaket;Erzeugen (8840) einer Kombination von Kapselungspaketen, die jeweils wenigstens ein Transportpaket aufweisen, durch Extrahieren der Informationen bezüglich des Transportpaketes; undErzeugen (8850) einer Kombination von Anwendungsdaten, die wenigstens ein Kapselungspaket aufweisen, unter Verwendung von Informationen bezüglich der Kapselungspakete, die aus der Kombination der Kapselungspakete extrahiert werden.

Description

  • Technisches Gebiet
  • Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Empfangen von Rundfunk und insbesondere ein Verfahren und eine Vorrichtung zum Empfangen von Rundfunk, der als mobiler Rundfunkdienst bereitgestellt wird.
  • Technischer Hintergrund
  • Das ATSC (Advanced Television System Committee) ist eine Gruppe, die von den Standards für terrestrischen digitalen Fernsehrundfunk (DTV) die Standards für digitale Fernsehübertragung (DTV) in den USA definiert. Ein Hauptaspekt der durch das ATSC definierten Standards betrifft Audio-/Video (AV)-Kompression und Senden. Das heißt, ein Videosignal wird entsprechend dem MPEG2-Standard komprimiert, Ton- und Sprachsignale werden entsprechend dem AC-3-Standard komprimiert, und diese Signale werden unter Verwendung des Restseitenbandverfahrens (vestigial side band - VSB) gesendet. Das Restseitenbandverfahren, das ein Standard für terrestrischen digitalen Fernsehempfang ist, ist in sofern vorteilhaft, als es die Nutzung von Frequenzbändern erweitert und so die Reichweite von digitalem Fernsehen maximiert, es ist jedoch insofern von Nachteil, als es nur schwer bei Mobilfernsehen eingesetzt werden kann, da ein Funksignal bei Bewegung nur schwer zu empfangen ist.
  • Zwischenzeitlich sind, da der Bedarf an Rundfunkdiensten, wie beispielsweise terrestrischen DMB-Rundfunkdiensten und Satelliten-DMB-Rundfunkdiensten, für die ein Mobilkommunikationsgerät verwendet wird, zugenommen hat und die Anforderungen an Rundfunkdienste zugenommen haben und vielfältiger geworden sind, verschiedene Rundfunkverfahren eingeführt worden, die derartige Bedürfnisse von Verbrauchern befriedigen.
  • Die Druckschrift DE 600 08 251 bezieht sich auf ein System und Verfahren zur vereinfachten Übertragung von IP-Daten über ein MPEG-Netzwerk, wobei zum Erleichtern der Lieferung von Inhalt in einem Inhaltsdatenstrom an ein Terminal, ein Descriptor für den Inhaltsdatenstrom erzeugt wird, wobei der Descriptor mindestens eine Zieladresse umfasst, wobei die mindestens eine Zieladresse mindestens eine Multicast-Medienzugriffssteuerungsadresse beinhaltet, der Descriptor auf das Terminal in einer Program Map Tabelle übertragen wird und der Inhaltsdatenstrom an den Terminal unter Verwendung der Zieladresse in dem Descriptor lokalisiert wird.
  • Die Druckschrift DE 103 60 431 A1 bezieht sich auf ein Verfahren zum Aufbereiten, Übertragen und Darstellen interaktiver Datendienste auf DVB-Endgeräten. Es wird vorgeschlagen zusätzliche Information zu Audio- und Video-Daten in MPEG-Transportströmen zu übertragen, wobei die zusätzlichen Daten als IP-Daten übertragen werden. Empfangsseitig werden zur Wiederherstellung der übertragenen Audio- und Video-Daten und der zusätzlichen Informationen ein Tuner, ein Demultplexer und ein MPEG-Decoder eingesetzt.
  • Die Druckschrift DE 101 39 066 A1 bezieht sich auf ein Verfahren und eine Anordnung zum Verbessern der Empfangseigenschaften von DVB-Signalen, wobei insbesondere beim Empfangen von mobilen Empfängern, bei denen die DVB-Signale senderseitig als MPEG-Transportstrom-Pakete erzeugt werden, wird senderseitig mindestens ein Teil der MPEG-Transportstrompakete vor einem Modulator nach dem Interleaving-Prinzip verschachtelt und empfangsseitig nach einem Demodulator nach dem gleichen Interleaving-Prinzip wird die Verschachtelung wieder rückgängig gemacht.
  • Es ist Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zum Empfangen eines Rundfunkdienstes für Mobilkommunikation sowie eine verbesserte Vorrichtung zum Empfangen eines Rundfunkdienstes für Mobilkommunikation zur Verfügung zu stellen.
  • Diese Aufgabe wird durch die Gegenstände der unabhängigen Ansprüche gelöst.
  • Figurenliste
    • 1A und 1B stellen einen MCAST-Daten-Protokollstapel gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 2 stellt einen MCAST-Daten-Protokollstapel gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 3 stellt schematisch die Struktur eines A-VSB-MCAST-Sendesystems gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 4 stellt schematisch die Struktur eines A-VSB-MCAST-Sendesystems gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 5 stellt schematisch eine OMA-BCAST-Dienstschicht gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 6 stellt schematisch eine Endgerät-Netzwerk-Protokollschnittstelle gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 7A bis 7D stellen ein Hochgeschwindigkeits-Dienstzugriffsverfahren dar, das von einem ATSC-MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung unterstützt wird.
    • 8A und 8B stellen ein Hochgeschwindigkeits-Dienstzugriffsverfahren dar, das von dem ATSC-MCAST-System gemäß einer anderen Ausführungsform der vorliegenden Erfindung unterstützt wird.
    • 9A und 9B stellen ein Hochgeschwindigkeits-Dienstzugriffsverfahren dar, das von dem ATSC-MCAST-System gemäß einer anderen Ausführungsform der vorliegenden Erfindung unterstützt wird.
    • 10A bis 10C stellen Dienstkonfigurationsinformationen gemäß einer Ausführungsform der vorliegenden Erfindung dar,
    • 11 stellt die Struktur eines in 10A dargestellten ‚version_indicator_information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 12 stellt die Struktur eines ‚frame_group_information()‘-Feldes dar.
    • 13 stellt die Struktur eines in 10A dargestellten ‚turbo_channel_information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 14 stellt die Struktur eines in 10A dargestellten ‚additional_service_information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 15 stellt die Struktur eines Turbo_channel_information_description()-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 16A stellt die Struktur eines in 10B dargestellten turbo_channel_configuration()-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 16B stellt die Struktur eines turbo_channel_configuration()-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 17 stellt die Struktur eines in 16A dargestellten discriptor_loop()-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 18 stellt die Struktur eines ‚frame_group_update‘-Feldes dar, wenn der Wert eines in 17 dargestellten ‚tag‘-Feldes auf ,0' eingestellt ist.
    • 19A stellt die Struktur eines ‚Frame_Slicing_Duration_Update‘-Feldes gemäß einer Ausführungsform der Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚1‘ gesetzt ist.
    • 19B stellt die Struktur des ‚Frame_Slicing_Duration_Update‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚1‘ eingestellt ist.
    • 20A stellt die Struktur eines ‚SRS_position_update‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚2‘ eingestellt ist.
    • 20B stellt die Struktur des ‚SRS_position_update‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚2‘ eingestellt ist.
    • 21A stellt die Struktur eines ‚turbo_channel_update‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚3‘ eingestellt ist.
    • 21B stellt die Struktur eines ‚turbo_channel_update‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚3‘ eingestellt ist.
    • 22A stellt die Struktur eines ‚BD_Packet‘-Feldes gemäß einer Ausführungsförm der vorliegenden Erfindung dar.
    • 22B stellt die Struktur eines ‚BD_Packet‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 23 stellt die Struktur eines broadcast descriptors (BD) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 24A stellt die Struktur eines ‚Channel_info_update()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert eines in 23 dargestellten ‚tag‘-Feldes ‚1‘ ist.
    • 24B stellt die Struktur eines ‚Channel_info_update()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 24C stellt die Struktur des ‚Channel_info_update()‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 25A stellt einen IP mapping descriptor gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 23 dargestellten ‚tag‘-Feldes ‚1‘ ist.
    • 25B stellt den IP mapping descriptor gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 26 stellt die Struktur in 25A dargestellten ‚IP_channel_description‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 27A stellt die Struktur eines ‚IP_address_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert eines in 26 dargestellten ‚tag‘-Feldes ‚1‘ ist.
    • 27B stellt die Struktur des ‚IP_address_table‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 26 dargestellten ‚tag‘-Feldes ‚1‘ ist.
    • 28 stellt die Struktur eines ‚MAC_address_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 26 dargestellten ‚tag‘-Feldes ‚2‘ ist.
    • 29 stellt die Struktur eines ‚Text_description_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 26 dargestellten ‚tag‘-Feldes ‚3‘ ist.
    • 30A stellt eine MCAST-Multiplexstruktur gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 30B stellt eine MCAST-Multiplexstruktur gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 31A stellt eine MCAST-Rahmenstruktur sowie eine LMT gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 31B stellt eine MCAST-Rahmenstruktur sowie eine LMT gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 32 stellt ein Verfahren zum Prüfen einer Änderung eines Teil-Datenkanals unter Verwendung von Virtual-Map-Identifizierung (VMI) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 33 ist ein Flussdiagramm, das ein Verfahren zum Beziehen eines Dienstes unter Verwendung von VMI gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 34A stellt die Struktur einer Location-Map-Tabelle (LMT) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 34B stellt im Detail die Struktur der LMT in 34A gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 35A und 35B stellen die Struktur der LMT gemäß Ausführungsformen der vorliegenden Erfindung dar.
    • 36 stellt die Struktur eines in 35 dargestellten ‚LMT_information‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 37A und 37B stellen die Struktur der LMT und des ’LMT‘_information‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 38 stellt die Struktur der LMT gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 39 stellt die Struktur eines MCAST-Rahmens und einer Verbindungsinformationstabelle (linkage information table - LIT) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 40 stellt die Struktur einer LIT gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 41A und 41B stellen die Struktur einer LIT gemäß einer weiteren Ausführungsform der vorliegenden Erfindung dar.
    • 42A ist ein Flussdiagramm, das ein Verfahren zum Bereitstellen eines Dienstes unter Verwendung einer LMT und einer LIT gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 42B ist ein Flussdiagramm, das ein Verfahren zum Bereitstellen eines Dienstes unter Verwendung einer LMT und einer LIT gemäß einer anderen Ausführungsform der vorliegenden Erfindung darstellt.
    • 43 stellt die Struktur von Objektübertragungsinformationen gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 44 stellt die Struktur eines in 43 dargestellten ‚directory_information‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 45 stellt die Struktur eines in 43 dargestellten ‚time_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 46 stellt die Struktur eines ‚content_name_descriptor‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert eines in 43 dargestellten ‚tag‘-Feldes ‚1‘ ist.
    • 47 stellt die Struktur eines ‚mime_type_description‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert eines in 43 dargestellten ‚tag‘-Feldes ‚2‘ ist.
    • 48 stellt die Beziehung zwischen einem Kapselungspaket und einem Transportpaket in einem MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 49A und 49B stellen die Struktur eines Kapselungspaketes zur Signalisierung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 50A und 50B stellen die Struktur eines Kapselungspaketes für Echtzeitdaten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 51 stellt die Syntax eines Kapselungspaketes für Echtzeitdaten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 52A und 52B stellen die Syntax eines Kapselungspaketes für IP-Daten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 53 stellt die Syntax eines Kapselungspaketes für IP-Daten gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 54A und 54B stellen die Struktur eines Paketes für Objektdaten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 55A und 55B stellen die Struktur eines Paketes für Objektdaten gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 56 stellt ein Verfahren zum Übertragen von Objektdaten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 57 stellt den Einsatz von Anwendungsschicht-Vorwärtsfehlerkorrektur (application layer forward error correction - AL-FEC) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 58 stellt Header-Strukturen eines Transportpaketes und ein Transportpaket gemäß Ausführungsformen der vorliegenden Erfindung dar.
    • 59 stellt die Syntax eines Transportpaketes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 60A und 60B stellen die Struktur eines Transportpaketes, eines Base-Headers und eines zusätzlichen Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
    • 61A und 61B stellen die Struktur eines ‚padding_field‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert eines in 60 dargestellten ‚tag‘-Feldes ‚0‘ ist.
    • 62 stellt die Struktur eines ‚LMT_field‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 60 dargestellten ‚tag‘-Feldes ‚1‘ ist.
    • 63 stellt die Struktur eines ‚compression_field_parameter‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 60 dargestellten ‚tag‘-Feldes ‚2‘ ist.
    • 64A und 64B stellen die Struktur eines Signalisierungs-Paketes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 65 stellt einen Prozess des Bereitstellens von OMA-BCAST-Dienst in einem MCAST-Übertragungssystem gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 66 stellt ein Verfahren zum Bereitstellen eines Dienstes unter Verwendung von MCAST, das OMA-BCAST unterstützt, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 67 stellt vier Schichten zum Schutz eines Dienstes und von Inhalt gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 68 stellt einen Stromsparmechanismus gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 69 stellt Parameter, die sich auf MCAST-Frame-Slicing beziehen, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 70 stellt Parameter, die sich auf Energiesparen beziehen, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 71, ist ein Diagramm, das ein Verfahren zum Zuweisen jedes Dienstes zu einer vorgegebenen Bandbreite für Burst-Mode-Übertragung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 72 ist ein Diagramm, das Rotation von Diensten für Burst-Mode-Übertragung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 73 ist ein Diagramm, das eine Generatormatrix gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 74 ist ein Flussdiagramm, das ein Verfahren zum Bestimmen von deg(vi) gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 75 ist ein Flussdiagramm, das eine Verbindung von Nachrichten-Knoten mit einem Code-Knoten gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 76 ist ein Flussdiagramm, das im Detail die in 75 dargestellte Operation S7520 gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 77 ist ein Blockschaltbild einer MCAST-Rundfunkempfangsvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung.
    • 78 ist ein Flussdiagramm, das ein Verfahren zum Empfangen von Rundfunk gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 79 stellt schematisch ein A-VSB-MCAST-Empfangssystem gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 80 ist ein Blockschaltbild einer Rundfunkempfangsvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung, die in der Lage ist, ein Fehlerpaket anzuzeigen.
    • 81 ist ein Flussdiagramm, das ein Verfahren zum Empfangen von Rundfunk gemäß einer Ausführungsform der vorliegenden Erfindung darstellt, mit dem ein Fehlerpaket angezeigt wird.
    • 82A und 82B stellen die Struktur eines Pre-Headers gemäß Ausführungsformen der vorliegenden Erfindung dar.
    • 83 ist ein Flussdiagramm, das ein Verfahren zum Verarbeiten eines DCI durch eine Rundfunkempfangsvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 84A stellt ein Verfahren zum Aktualisieren von TCC bei adaptivem Time-Slicing-Verfahren gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 84B stellt ein Aktualisierungsverfahren unter Verwendung eines BD bei adaptivem Time-Slicing-Verfahren gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 85 ist ein Blockschaltbild einer Rundfunkdienst-Sendevorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung.
    • 86 ist ein Blockschaltbild einer Rundfunkdienst-Empfangsvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung.
    • 87 ist ein Flussdiagramm, das ein Verfahren zum Senden eines Rundfunkdienstes gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 88 ist ein Flussdiagramm, das ein Verfahren zum Empfangen eines Rundfunkdienstes für Mobilkommunikation gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • Ausführliche Beschreibung der Erfindung
  • Technisches Problem
  • Die vorliegende Erfindung schafft ein Rundfunkdienst-Transportverfahren sowie eine Vorrichtung, mit denen ein Rundfunkdienst mit hohem Qualitätsstandard in einem Mobilkommunikationssystem schnell und effizient bereitgestellt werden kann, sowie ein Verfahren und eine Vorrichtung zum Empfangen eines Rundfunkdienstes.
  • Technische Lösung
  • Die vorliegende Erfindung schafft ein Verfahren zum Transportieren eines Rundfunkdienstes für Mobilkommunikation, wobei das Verfahren Erzeugen eines Kapselungspaketes, das Konfigurationsinformationen, die zu sendenden Anwendungsdaten entsprechen, und die Anwendungsdaten enthält, Erzeugen von Transportpaketen, die Daten bezüglich des Kapselungspaketes aufweisen, durch Unterteilen des Kapselungspaketes in Pakete vorgegebener Größe, wobei die Transportpakete Informationen bezüglich der Strukturen der Transportpakete enthalten, und Erzeugen von Dienstkonfigurationsinformationen umfasst, die festgelegte Informationen über einen Kanal mit den Transportpaketen enthalten, und die Dienstkonfigurationsinformationen in einen Dienstinformationskanal an einer vorgegebenen Position von wenigstens einem Transportkanal in einem Transport-Stream enthalten.
  • Vorteilhafte Effekte
  • Gemäß der vorliegenden Erfindung kann, da Dienstkonfigurationsinformationen in einem vorgegebenen Bereich eines Transportrahmens vorhanden sind, eine Rundfunkdienst-Empfangsvorrichtung unter Verwendung der Dienstkonfigurationsinformationen auf einen Transportkanal zugreifen, ohne einen Signalisierungsinformations-Kanal zu verarbeiten. Damit ist es möglich, eine Wartezeit einer Rundfunkdienst-Empfangsvorrichtung zum Empfangen eines Rundfunkdienstes zu verkürzen, die entsteht, bis auf jeden der Rundfunkdienste zugegriffen wird, nachdem ein Signalisierungsinformations-Kanal in dem Transport-rahmen erfasst worden ist und der Signalisierungsinformations-Kanal interpretiert worden ist.
  • Des Weiteren werden gemäß der vorliegenden Erfindung die Strukturen eines Kapselungspaketes und eines Transportpaketes entsprechend dem bereitgestellten Typ von Anwendungsdaten adaptiv bestimmt, um so einen Datenbereich effizient zu nutzen und die Geschwindigkeit der Datenübertragung zu erhöhen.
  • Des Weiteren werden gemäß der vorliegenden Erfindung Decoder-Konfigurationsinformationen zusammen mit einem Rundfunkdienst transportiert, der Echtzeit-Medien-Daten bereitstellt, und so kann eine empfangende Seite die Spezifikation eines Decoders, der für das Format der bereitgestellten Medien-Daten geeignet ist, im Voraus unter Verwendung der Decoder-Konfigurationsinformationen aktualisieren.
  • Beste Ausführungsweise
  • Gemäß einem Aspekt der vorliegenden Erfindung wird eine Vorrichtung zum Transportieren eines Rundfunkdienstes für Mobilkommunikation geschaffen, wobei die Vorrichtung eine Kapselungspaket-Erzeugungseinheit, die ein Kapselungspaket erzeugt, das Konfigurationsinformationen, die zu sendenden Anwendungsdaten entsprechen, und die Anwendungsdaten enthält, eine Transportpaket-Erzeugungseinheit, die Transportpakete erzeugt, die Daten bezüglich des Kapselungspaketes aufweisen, indem das Kapselungspaket in Pakete vorgegebener Größe aufgeteilt wird, wobei die Transportpakete Informationen bezüglich der Strukturen der Transportpakete umfassen, und eine Dienstkonfigurationsinformations-Erzeugungseinheit enthält, die Dienstkonfigurationsinformationen erzeugt, die festgelegte Informationen über einen Kanal mit den Transportpaketen enthalten, und die Dienstkonfigurationsinformationen in einem Dienstinformations-Kanal an einer vorgegebenen Position von wenigstens einem Transportkanal in einem Transport-Stream enthalten.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Empfangen eines Rundfunkdienstes für Mobilkommunikation geschaffen, wobei das Verfahren Bestimmen eines vorgegebenen Transportkanals unter Verwendung aus einem Dienstinformations-Kanal extrahierter Dienstkonfigurationsinformationen, Extrahieren eines Transportpaketes aus dem vorgegebenen Transportkanal, Extrahieren von Informationen bezüglich des Transportpaketes aus dem extrahierten Transportpaket, Erzeugen einer Kombination von Kapselungspaketen, die jeweils wenigstens ein Transportpaket aufweisen, durch Extrahieren der Informationen bezüglich des Transportpaketes, und Erzeugen einer Kombination von Anwendungsdaten, die wenigstens ein Kapselungspaket aufweisen, unter Verwendung von Informationen bezüglich der Kapselungspakete einschließt, die aus der Kombination der Kapselungspakete extrahiert werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird eine Vorrichtung zum Empfangen eines Rundfunkdienstes für Mobilkommunikation geschaffen, wobei die Vorrichtung eine Transportkanal-Bestimmungseinheit, die einen vorgegebenen Transportkanal unter Verwendung von Dienstkonfigurationsinformationen bestimmt, die aus einem Dienstinformations-Kanal extrahiert werden; eine Transportpaket-Extraktionseinheit, die ein Transportpaket aus dem bestimmten Transportkanal extrahiert; eine Transportpaketinformations-Extraktionseinheit, die Informationen bezüglich des Transportpaketes aus dem extrahierten Transportpaket extrahiert; eine Kapselungspaket-Kombinationseinheit, die eine Kombination von Kapselungspaketen, die jeweils wenigstens ein Transportpaket aufweisen, unter Verwendung der Informationen bezüglich des Transportpaketes erzeugt, und eine Anwendungsdaten-Kombinationseinheit, die eine Kombination von Anwendungsdaten, die wenigstens ein Kapselungspaket aufweisen, unter Verwendung von Informationen bezüglich der Kapselungspakete erzeugt, die aus der Kombination der Kapselungspakete extrahiert werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Transportieren eines Stream geschaffen, wobei das Verfahren Einfügen eines zweiten Transport-Stream, der für ein Mobil-Endgerät zum Empfangen von Rundfunkdaten erforderlich ist, in einen ersten Transport-Stream und Transportieren des ersten Transport-Stream einschließt, in den der zweite Transport-Stream eingefügt ist.
  • Der zweite Transport-Stream kann an einer vorgegebenen Position in den ersten Transport-Stream eingefügt werden.
  • Das Verfahren kann des Weiteren Erzeugen von Signalisierungsinformationen einschließen, die wenigstens Informationen bezüglich der Position des zweiten Transport-Stream oder Informationen enthalten, die erforderlich sind, um den zweiten Transport-Stram zu verarbeiten, wobei während des Transports des ersten Transport-Stream weiterhin die Signalisierungsinformationen transportiert werden.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Empfangen eines Stream geschaffen, wobei das Verfahren Erzeugen eines zweiten Transport-Stream durch Empfangen eines ersten Transport-Stream, in den der zweite Transport-Stream eingefügt ist, und Verarbeiten des zweiten Transport-Stream einschließt.
  • Der zweite Transport-Stream kann an einer vorgegebenen Position in den ersten Transport-Stream eingefügt werden.
  • Während des Erzeugens des zweiten Transport-Stream können des Weiteren Signalisierungsinformationen erzeugt werden, die wenigstens Informationen bezüglich der Position des zweiten Transport-Stream oder Informationen enthalten, die zum Verarbeiten des zweiten Transport-Stream erforderlich sind, und das Verarbeiten des zweiten Transport-Stream kann Verarbeiten des zweiten Transport-Stream auf Basis der Signalisierungsinformationen einschließen.
  • Ausführungsweise der Erfindung
  • Um die Erläuterung zu vereinfachen, folgt eine Definition von Abkürzungen und Termini, die in der vorliegenden Patentbeschreibung verwendet werden:
    Anwendungsschicht: Audio/Video (A/V)-Streaming, und Internet Protokoll (IP)- und Nichtechtzeit(NRT)-Dienste
    ATSC-M/H-Endgerät: eine Endgeräteinrichtung, die auf einen ATSC-M/H-Dienst zugreift
    ATSC-M/H-Dienst: ein ATSC-Rundfunkdienst, der für Mobil- und Hand-Endgeräte bestimmt ist
    ATSC-M/H-System eine Kombination aus einem Dienstsystem und Kopfstations-Anlagen (head-end equipment), die einen ATSC-M/H-Dienst über Rundfunk und wahlweise über einen Interaktionskanal verfügbar macht
    Cluster: eine Gruppe einer beliebigen Anzahl von Sektoren, in denen ein Turbo-Fragment angeordnet ist
    primärer Dienst: ein erster Prioritätsdienst, den ein Benutzer beim Anschalten sieht. Dies ist ein optionaler Dienst eines Rundfunkanbieters.
    Verbindungsschicht (link layer):
    FEC-Codierung, Partitionierung und Mapping zwischen einem Turbo-Stream und Clustern
    Verbindungsinformationstabelle tabelle (linkage information table - LIT):
    eine Verbindungsinformationstabelle zwischen Dienstkomponenten, die überall in einem MCAST-Paket angeordnet ist
    Standortzuordnungstabelle lle (location map table (LIT):
    eine Standortinformationstabelle, die überall in einem MCAST-Paket zugeordnet ist.
    MCAST-Paket: ein Transportpaket, das in einem MCAST-Paket definiert ist
    MCAST-Sendung: eine Gruppe von MCAST-Paketen, die decodiert werden, nachdem Turbo-Pakete aus einer Paketgruppe extrahiert worden sind
    MCAST-Stream: eine Sequenz von MCAST-Paketen
    MCAST-Transportschicht:t: eine in ATSC-MCAST definierte Transportschicht
    MPEG-Daten: ein Transport-Stream ohne Sync-Byte
    MPEG-Datenpaket: ein TS-Paket ohne Sync-Byte
    Sendung: eine Gruppe von 624 Transportströmen von MPEG-Datenpaketen
    Sektor: ein 8-Byte-Raum, der in einem Anwendungsfeld (AF) eines Transportstream (TS) oder einem MPEG-Datenpaket reserviert ist
    SIC: ein Typ eines Turbo-Stream, der ein Signalisierungsinformations-Kanal ist, der Informationen zum Verarbeiten aller. Turbo-Streams beinhaltet
    Teilkanal: ein physikalischer Raum für AV-Streaming-, Internetprotokoll (IP)- und NRT-Daten
    Teil-Datenkanal: ein physikalischer Raum für Teilkanal-Komponenten
    Transportschicht: eine in ATSC-MCAST definierte Transportschicht
    Turbo-Kanal: ein physikalischer Raum zum Speichern von Transport-Streams Die Schutzstufen von Turbo-Kanälen können sich voneinander unterscheiden.
    Turbo-Stream: Turbo-codierter Transport-Stream
    VSB-Frame: 626 Segmente, die aus zwei Datenfeld-Sync-Segmenten und 624 (Daten + Vorwärtswählerkorrektur)-Segmenten bestehen
    A-VSB: ein weiterentwickeltes VSB-System
    AF: Adaptionsfeld in einem A/53-definierten Transport-Stream-Paket
    ATSC: Advanced Television Systems Committee
    BD: broadcast descriptor
    BCAST: OMA-Mobilrundfunk-Dienstfreigabeeinrichtung
    IRD: integrierter Empfänger und Decoder
    DC: Decoder-Konfiguration
    DCI: Decoder-Konfigurations-Informationen
    DFS: Datenfeld-Sync
    DVB: digitaler Video-Rundfunk (digital video broadcasting)
    ES: Elementar-Stream
    EC-Kanal: Elementarkomponenten-Kanal
    FEC: Vorwärtswählerkorrektur
    F/L: Erste/Letzte
    IMT: IP-Mapping-Tabelle
    IPEP: IP-Kapselungspaket
    LMT: Positionszuordnungstabelle (location map table)
    LIT: Verbindungsinformations-Tabelle
    MAC: Medienzugriffsschicht (medium access layer)
    MCAST: mobiler Rundfunk (mobile broadcasting)
    OEP: Objekt-Kapselungspaket
    OMA: Open Mobile Alliance
    PCR: Programmtakt-Bezug
    PSI: programmspezifische Informationen
    PSIP programmspezifisches Informationsprotokoll
    REP: Echtzeit-Kapselungspaket
    SD-VFG: Dienstunterteilung in variabler Rahmen-Gruppe
    SEP: Signalisierungs-Kapselungspaket
    SG: Dienstführer
    SIC: Signalisierungsinformations-Kanal
    SRC: Zusatz-Bezugssequenz
    TS: Transport-Stream (transport stream)
  • Im Folgenden werden beispielhafte Ausführungsformen der vorliegenden Erfindung ausführlicher unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.
  • Ein MCAST-Übertragungssystem gemäß der vorliegenden Erfindung ist in der Lage, verschiedene Typen von Diensten zusammen bereitzustellen oder nur einen spezifischen Typ Dienst bereitzustellen, so beispielsweise einen Intemet-Protokoll(IP)-Dienst. 1 stellt einen Fall dar, in dem verschiedene Typen von Diensten zusammen bereitgestellt werden. 2 stellt einen Fall dar, in dem nur ein bestimmter Typ Dienst bereitgestellt wird.
  • 1A und 1B stellen einen MCAST-Daten-Protokollstapel gemäß einer Ausführungsform der vorliegenden Erfindung dar. Wie unter Bezugnahme auf 1A und 1B zu sehen ist, werden verschiedene Typen von Inhalt gesendet, so dass verschiedene Typen von Diensten über ein MCAST-Sendesystem bereitgestellt werden. Beispiele für Dienste, die von dem MCAST-Übertragungssystem unterstützt werden, so ein Echtzeitdienst, ein IP-Dienst und ein Objekt-Download-Dienst, werden im Folgenden beschrieben. Die Typen von Diensten, die das MCAST-Übertragungssystem unterstützen kann, sind jedoch nicht darauf beschränkt.
  • In einem Echtzeit-Dienst werden Daten in Echtzeit empfangen, und sie sind für die unmittelbare Verwendung beim Empfang bestimmt. Zu Typen von Echtzeitdaten gehören Video-, Audio- und Zusatzinformationen, die zusammen mit Audio/Video (A/V) angeboten werden sollen.
  • Als IP-Dienst werden im weitesten Sinne alle Typen von Diensten bezeichnet, die Dienste einschließen, die IP-basierte Daten verwenden, so beispielsweise IP-Data Casting. Bei einem IP-Dienst wird erwartet, dass in Echtzeit empfangene IP-basierte Daten unmittelbar beim Empfang in naher Zukunft verwendet werden. Ansonsten kann der IP-Dienst auch auf einen Dienst erweitert werden, bei dem IP-basierte Daten als ein Objekt heruntergeladen werden und in einer Speicherrichtung gespeichert werden, um sie später zu verwenden.
  • Ein Objekt-Download-Dienst ist dadurch gekennzeichnet, dass Multimediadaten oder allgemeine Objektdaten zu jedem beliebigen Zeitpunkt empfangen und in Reaktion auf ein Steuersignal angezeigt oder gespeichert werden.
  • Die Eigenschaften von Daten, die von dem MCAST-System unterstützt werden, um einen Dienst bereitzustellen, werden im Folgenden beschrieben.
  • MCAST unterstützt H.264/AVC-Videocodierung und -decodierung in einem IRD. Um vollständige Übereinstimmung mit der Spezifikation und Aufwärtskompatibilität der zukünftigen erweiterten Versionen zu ermöglichen, sollte der IRD in der Lage sein, Datenstrukturen zu überspringen, die aktuell „reserviert“ sind oder die Funktionen entsprechen, die durch den IRD nicht implementiert werden.
  • In Bezug auf Profil und Stufe unterstützt MCAST Codieren und Decodieren wie folgt:
    Codieren: ein H.264/AVC-Bitstrom sollte den Einschränkungen entsprechen, die in ITU-T Recommendation H.264 beschrieben sind (H.264, empfohlen durch ITU-T)/ISO/IEC 14496-10 für Stufe 1.3 des Basisprofils, wobei constraint_set1_flag ‚1‘ entspricht.
    Decodieren: desgleichen sollte ein IRD, der H.264/AVC unterstützt, in der Lage sein, Bilder unter Verwendung des Basisprofils von Stufe 1.3 zu decodieren und wiederzugeben, wenn constraint_set1-flag ‚1‘ entspricht.
  • Bei einem Abtast-Seitenverhältnis sollte ein quadratisches (1:1) Abtast-Seitenverhältnis zum Decodieren verwendet werden, und jeder IRD sollte Decodieren und Wiedergeben von Bildern mit einem quadratischen (1:1) Abtast-Seitenverhältnis zum Decodieren unterstützen.
  • In Bezug auf Random-Zugangspunkte (random access points) wird empfohlen, dass Sequenz- und Bild-Parametergruppen zusammen mit einem Random-Zugangspunkt wenigstens einmal alle zwei Sekunden gesendet werden.
  • Was Audio angeht, so unterstützt das ATSC-MCAST MPEG-4-AAC-Profil, das MPEG-4-HE-AAC-Profil und das MPEG-HE-AAC-v2-Profil. Um vollständige Übereinstimmung mit ISO/IEC 14496-3[5] und Aufwärtskompatibilität mit zukünftigen erweiterten Funktionen zu ermöglichen, sollte der IRD in der Lage sein, Datenstrukturen zu überspringen, die aktuell „reserviert“ sind oder die Funktionen entsprechen, die durch den IRD nicht implementiert werden.
  • Was einen Audio-Modus angeht, so sollte Audio in Mono, parametrischem Stereo oder 2-Kanal-Stereo entsprechend der in dem HE-AAC-v2-Profil, Stufe 2 definierten Funktionalität codiert werden oder entsprechend der in dem HE-AAC-v2-Profil, Stufe 4 definierten Funktionalität, wie in ISO/IEC 14496-3 einschließlich der Nachträge 1 und 2[5] spezifiziert, in Multikanal codiert werden. Des Weiteren sollte der IRD in der Lage sein, Mono, parametrisches Stereo oder 2-Kanal-Stereo der Funktionalität zu codieren, die in dem HE-AAC-v2-Profil, Stufe 2, spezifiziert in ISO/IEC 14496-3 einschließlich der Nachträge 1 und 2[5], definiert ist.
  • Was die Bitraten betrifft, sollte die maximale Bitrate von Audio beim Decodieren 192 kbit/s für ein Stereo-Paar nicht übersteigen, und die maximale Bitrate von codiertem Audio sollte 320 kbit/s für Mehrkanal-Audio nicht übersteigen. Beim Decodieren sollte der IRD das HE-AAC-v2-Profil und eine ausgewählte Stufe mit maximal 192 kbit/s für ein Stereo-Paar unterstützen.
  • Des Weiteren sollte der IRD, was Matrix-Downmixing angeht, Matrix-Downmixing unterstützen, wie es in MPEG-4 definiert ist.
  • MCAST ist jedoch nicht auf das oben beschriebene Codierverfahren beschränkt. Streams, die mit einem anderen Codierverfahren codiert sind, beispielsweise MPEG-2-Video/BSAC, können auch übertragen werden, indem das Codierverfahren direkt/indirekt ausgedrückt wird.
  • 2 stellt einen MCAST-Daten-Protokollstapel gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar. Das heißt, 2 stellt ein Fall dar, in dem nur ein IP-Dienst über MCAST bereitgestellt wird.
  • Eine Paketschicht segmentiert die Signalisierungsinformationen und ein IP-Datagram in MCAST-Pakete und fügt einen Übertragungs-Header hinzu. Der Signalisierungsinformations-Kanal (SIC) beinhaltet Signalisierungsinformationen bezüglich jedes Turbo-Kanals. Bei mobilen Diensten ist schneller Bezug von Diensten ein wichtige Anforderung.
  • MCAST reduziert die Schritte des Abstimmen, Demultiplexierens und Decodierens der Dienste und gewährleistet so den schnellen Bezug von Diensten.
  • Des Weiteren unterstützt MCAST das Konzept eines primären Dienstes. Der primäre Dienst ist ein erster Prioritätsdienst, den ein Nutzer in einem kontinuierlichen Modus bezieht. In einem allgemeinen Fall von Dienstzugang in einem Turbo-Stream sollte der SIC zunächst zur Turbo-Verarbeitung bezogen und decodiert werden. Der SIC beinhaltet physikalische Decodierungsinformationen und eine einfache Beschreibung aller Turbo-Dienste. Bei dem primären Dienst ist schneller Zugang möglich, da Zugangsinformationen in dem Data Field Sync (DFS) definiert sind. Ein schnelles Zugangsverfahren wird weiter unten unter Bezugnahme auf 7 bis 9 beschrieben.
  • Der primäre Dienst und der SIC sollten sich in einem kontinuierlichen Übertragungsmodus befinden, und der SIC sollte in jedem Rahmen (frame) vorhanden sein. In dem kontinuierlichen Übertragungsmodus werden Rahmen kontinuierlich gesendet. In einem Burst-Übertragungsmodus wird eine Vielzahl von Rahmen jeweils zu einem bestimmten Zeitpunkt übertragen (weitere Details befinden sich in 68). Der SIC ist obligatorisch. Der primäre Dienst ist jedoch optional und hängt von einem Service-Provider ab.
  • 3 stellt schematisch die Struktur eines A-VSB-MCAST-Übertragungssystems gemäß einer Ausführungsform der vorliegenden Erfindung dar. MCAST unterstützt, wie unter Bezugnahme auf 3 zu sehen ist, verschiedene Typen von Diensten. Eine MCAST-Architektur setzt sich aus vier Schichten zusammen, d. h. einer Anwendungsschicht, einer Transportschicht, einer Datenverbindungsschicht und einer physikalischen Schicht. Diese Schichten sind in 3 von links nach rechts dargestellt.
  • Die Transportschicht stellt die anwendungsspezifischen Informationen und Fragmentierungs-Informationen von Anwendungsdaten bereit und kapselt elementare Einheiten mit einer vordefinierten Syntax. Anwendungs-Streams werden nach spezifischem Typ gekapselt und zu Paketen fester Länge multiplexiert, die als ‚MCAST-Turbo-Stream‘ bezeichnet werden. Die Pakete bilden später Turbokanäle.
  • Die Verbindungsschicht empfängt Turbo-Kanäle und wendet spezielle Vorwärtsfehlerkorrektur (FEC), beispielsweise eine Code-Rate usw., auf jeden der Turbo-Kanäle an. Signalisierungsinformationen, die in einem SIC vorhanden sind, sind wichtig, und so wird die stärkste Vorwärtsfehlerkorrektur darauf angewendet, so dass eine signalisierte Anwendung selbst auf einer niedrigeren Stufe des Signal-Rausch-Verhältnisses empfangen werden kann. Dann werden Turbo-Kanäle, auf die Vorwärtsfehlerkorrektur angewendet worden ist, zusammen mit den Normal-TS-Paketen zu einer A-VSB-MAC-Schicht übertragen.
  • Eine A-VSB-MAC-Schicht fügt ein robustes Paket, das zusätzliche Daten beinhaltet, die ein Mobilendgerät empfangen kann, in einen Normal-TS ein bzw. zu ihm hinzu. Ein robustes Paket kann beispielsweise in einen Null-Paket-Bereich eines MPEG-TS eingefügt werden oder in einen privaten Datenbereich eines MPEG-2-TS integriert werden. Die A-VSB-MAC-Schicht öffnet Adaptions-Felder (AF) in Normal-TS-Paketen, wenn dies erforderlich ist. In diesem Fall sind die SIC-Übertragungs-Signalisierungsinformationen zum Verarbeiten des robusten Paketes definiert, und der SIC kann einfach bezogen werden, da er an einer vorgegebenen Position vorhanden ist, oder unter Verwendung eines Flag, das die Position des SIC anzeigt. Die A-VSB-MAC-Schicht spezifiziert, wie oben beschrieben, ein Verfahren oder Informationen bezüglich des Einfügens oder Hinzufügens des robusten Paketes in bzw. zu einem Normal-TS. Um insgesamt einen Gewinn und ein Ergebnis (Verbesserung) bezüglich der Effizienz gegenüber einem System zu erreichen, die ein 8-VSB-System ursprünglich nicht aufweist, und gleichzeitig Kompatibilität aufrechtzuerhalten, werden robuste Daten einer deterministischen Rahmen-Struktur zugeordnet, signalisiert und zu einer physikalischen 8-VSB-Schicht übertragen. Auch ein Exciter arbeitet deterministisch auf der physikalischen Schicht, gesteuert von der MAC-Schicht, und fügt Signalisierungsinformationen in ein DFS ein.
  • MCAST stellt einen Echtzeitdienst, einen IP-Dienst und einen Objekt-Dienst als Anwendungsdienste bereit. Wenigstens einer dieser Dienste wird in einem MCAST-Stream pro Turbo-Kanäle multiplexiert. Das heißt, MCAST ist in der Lage, einen primären Dienst bereitzustellen, um einen Hochgeschwindigkeits-Anfangsdienst zu beziehen.
  • Um verschiedene Dienst bereitzustellen, überträgt MCAST wenigstens einen von vier Datentypen, d. h. Echtzeit-Audio, Echtzeit-Video, IP oder Objekt-Signalisierung. Um die Dienstqualität von Anwendungen zu verbessern, kann beispielsweise eine Anwendungsschicht-FEC (AL-FEC) auf einen Objekt-Stream oder einen IP-Stream angewendet werden, wenn eine große Menge von Dateien übertragen wird. AL-FEC wird weiter unten unter Bezugnahme auf 57 beschrieben.
  • 4 stellt schematisch die Struktur eines A-VSB-MCAST-Übertragungssystems gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar. Wie unter Bezugnahme auf 4 zu sehen ist, unterstützt MCAST nur einen IP-Dienst. Das A-VSB-MCAST-Übertragungssystem ist das gleiche wie das in 3 dargestellte, wobei jedoch nur IP-Dienste zu einem MCAST-Stream für jeden der Turbo-Kanäle multiplexiert werden.
  • 5 stellt schematisch die Struktur einer OMA-BCAST-Dienstschicht gemäß einer Ausführungsform der vorliegenden Erfindung dar. In 5 entspricht ein ‚Endgerät‘ einem ‚ATSC-M/H-Endgerät‘ bezüglich der Funktionen, und die anderen Elemente entsprechen einem ‚ATSC-M/H-System‘.
  • BCAST-5 ist eine Rundfunkdienstschicht-Schnittstelle für einen oberen Teil einer Verwaltungsschicht. Ein unterster Teil dieser Schnittstelle ist das Internet-Protokoll (IP), das dann wiederum eine Schnittstelle mit einem oberen Teil von Schnittstelle X-3/X-4 aufweist.
  • BCAST-6 ist die interaktive Dienstschicht-Schnittstelle für den oberen Teil der Verwaltungsschicht.
  • BCAST-7 stellt eine Schnittstelle dar, die Signalisierung für Teilnehmer-Verwaltung und Dienst-/Inhalt-Transaktionen unterstützt.
  • BCAST-8 stellt dienstgebundene Interaktivität dar.
  • X-3 und X-4 werden in dieser Patentbeschreibung als identisch betrachtet. Sie stellen eine Trägerschicht dar und transportieren mit der Schnittstelle BCAST-5 zusammenhängende Daten. Für einen unteren Teil spezifiziert diese Schnittstelle den A-VSB-Träger. Für einen oberen Teil spezifiziert diese Schnittstelle BCAST-Transport, der die Lieferung von BCAST-5 unterstützt.
  • X-5 und X-6 werden in dieser Patentbeschreibung als identisch betrachtet. Sie stellen einen optionalen Interaktivitäts-Netzwerk/Träger dar, die Daten transportiert, die mit den Schnittstellen BCAST-6, BCAST-7 und BCAST-8 zusammenhängen.
  • Die Schnittstellen BCAST-1, BCAST-2, BCAST-3, BCAST-4, BDS-1, BDS-2, X-1 und X-2 sind für diese Patentbeschreibung nicht relevant und werden hier nicht beschrieben.
  • 6 stellt schematisch die Struktur einer Endgerät-Netzwek-Protokollschnittstelle gemäß einer Ausführungsform der vorliegenden Erfindung dar. In 6 wird eine ATSC-M/H-Endgerät-Netzwerk-Schnittstelle ausführlicher unter Verwendung der Konzepte einer BCAST-Schnittstelle und einer MCAST-Struktur beschrieben. 6 stellt einen Protokollstapel dar, der bezüglich ATSC-M/H nicht nur für einen Broadcast-Interaktivmodus, sondern auch für einen Broadcast-Only-Modus vorgeschlagen wird. Der Stapel ist in zwei Hauptteile unterteilt. Einer der Hauptteile ist eine ATSC-M/H-Dienstschicht, die aus Verfahren besteht, die auf alle ATSC-M/H-Empfänger angewendet werden können, sowie aus optionalen Interaktivitäts-Verfahren. Unterhalb der ATSC-M/H-Dienstschicht befinden sich drei Trägerschichten, von denen eine die ATSC-M/H-Trägerschicht darstellt und die andere einen beliebigen optionalen interaktiven Träger darstellt.
  • Ein Signalisierungsverfahren des MCAST-Systems wird im Folgenden beschrieben. Eine wichtige Anforderung an mobilen Rundfunk ist ein schneller Zugang zu Diensten. ATSC-MCAST schafft zwei repräsentative Möglichkeiten für einen schnellen Dienstzugang, d. h. einen primären Dienst und einen Teil von ES-Signalisierungsinformationen für einen Echtzeit-Mediendienst. Ein schnelles Dienstzugangsverfahren, das von dem ATSC-MCAST-System unterstützt wird, wird weiter unten unter Bezugnahme auf 7 beschrieben.
  • Des Weiteren kann das ATSC-MCAST-System einen SIC bereitstellen. Der SIC kann wichtige Informationen für die Verarbeitung eines Turbo-Kanals beinhalten. Der SIC kann wichtige Informationen beinhalten, die unabdingbar sind, damit ein Benutzer eine Rundfunkübertragung sehen kann. Der SIC kann beispielsweise physikalische Decodierungsinformationen oder eine kurze Beschreibung einer Turbo-Dienste beinhalten, die optional ist. Der SIC muss zuerst verarbeitet werden, um andere Turbo-Kanäle zu verarbeiten. Der SIC wird weiter unten unter Bezugnahme auf 10 beschrieben.
  • Ein primärer Dienst und der SIC sind in einem kontinuierlichen Übertragungsmodus vorhanden, und der SIC kann in allen Rahmen vorhanden sein. Obwohl der SIC ein unabdingbares Element ist, kann ein Service-Provider bestimmen, ob der primäre Dienst bereitgestellt wird.
  • 7 stellt ein Verfahren für schnellen Dienstzugang dar, das von einem ATSC-MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung unterstützt wird. Ein primärer Dienst wird, wie unter Bezugnahme auf 7 zu sehen ist, entsprechend dem Verfahren für schnellen Dienstzugang bereitgestellt. Der primäre Dienst hat hohe Priorität für einen Benutzer hinsichtlich des Empfangs eines Broadcast-Dienstes.
  • Das heißt, 7A stellt einen Prozess des Empfangens eines Dienstes in einem MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Eine Rundfunk-Empfangsvorrichtung prüft die Position eines SIC durch Interpretieren eines DFC. Dann greift die Rundfunk-Empfangsvorrichtung auf Basis der geprüften Position des SIC auf den SIC zu, wie dies mit Pfeil (1) angedeutet ist. Der SIC beinhaltet Informationen bezüglich der Anzahl von Turbo-Kanälen, die einen Rahmen bilden, und Informationen bezüglich der Struktur jedes der Turbo-Kanäle (Turbo-Kanal-Decodierinformationen, Meta-Informationen usw.).
  • Die Rundfunk-Empfangsvorrichtung greift unter Verwendung der in dem SIC beinhalteten Informationen auf einen gewünschten Turbo-Kanal zu, wie dies mit Pfeil (2) angedeutet ist, und bezieht Daten einer Anwendungsschicht durch Verarbeiten eines über den gewünschten Turbo-Kanal empfangenen Turbo-Stream, wie dies Pfeil (3) angedeutet ist.
  • Damit ein Benutzer einen Rundfunk-Dienst empfangen kann, ist, wie oben beschrieben, eine vorgegebene Wartezeit erforderlich, da die oben beschriebenen Prozesse durchgeführt werden müssen, nachdem der Rundfunk-Empfangsvorrichtung Strom zugeführt worden ist und ein Rundfunk-Signal empfangen worden ist. Um ein Problem dahingehend zu lösen, dass ein Rundfunk-Dienst erst bereitgestellt wird, wenn der SIC vollständig interpretiert ist, wird ein Dienst unterstützt, der als Standard bereitgestellt werden, bevor die Rundfunk-Empfangsvorrichtung arbeitet und den SIC empfängt. Dieser Dienst wird als ein ‚primärer Dienst‘ bezeichnet. Der primäre Dienst wird von einem Rundfunk-Service-Provider bereitgestellt und ist dafür gedacht, dass ihn der Benutzer als erstes sehen kann.
  • 7B stellt einen Prozess des Bereitstellens eines primären Dienstes durch ein MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung dar. In 7B sind Zugriffsinformationen zum Zugreifen auf einen primären Dienst von einer vorgegebenen Position eines Transport-Rahmens vorhanden.
  • Bei einem ATSC-Transport-Rahmen gemäß den ATSC-Standards können Zugangsinformationen für Zugang zu einem primären Dienst in DFS definiert sein. So kann die Rundfunk-Empfangsvorrichtung direkt auf einem Turbo-Stream für den primären Dienst von dem DFS zugreifen, ohne einen SIC zu suchen und zu verarbeiten, wie dies mit Pfeil (1) angedeutet ist.
  • 7C stellt ein Verfahren zum Übertragen eines Turbo-Streams für einen primären Dienst gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein Turbo-Stream für einen primären Dienst wird auf die gleiche Weise erzeugt wie andere Turbo-Streams und kann ähnlich wie der andere Turbo-Stream bei der Übertragung einem Transport-Rahmen zugeordnet werden. Ein Turbo-Stream für einen primären Dienst kann jedoch über einen Restdatenbereich eines Transport-Rahmens übertragen werden. Im Allgemeinen ist die Größe eines Restdatenbereiches eines Transport-Rahmens kleiner als die eines Kanals für einen primären Dienst, und so wird ein Turbo-Stream des primären Dienstes entsprechend der Größe des Restdatenbereiches des Transport-Rahmens unterteilt und über eine Vielzahl von Transport-Rahmen übertragen.
  • Signalisierungsinformationen, die weiter unten beschrieben werden, können auf ähnliche Weise übertragen werden. Das heißt, Signalisierungsinformationen können entweder über einen separaten Kanal, wie beispielsweise einen SIC, oder einen Restdatenbereich eines Transport-Rahmens übertragen werden. Ein Verfahren, das es einem Benutzer gestattet, Signalisierungsinformationen zu beziehen, während er einen primären Dienst sieht, wird im Folgenden in Bezug auf einen Fall, in dem Signalisierungsinformationen über einen separaten Kanal übertragen werden, sowie einen Fall beschrieben, in dem Signalisierungsinformationen über einen Restdatenbereich eines Transport-Rahmens übertragen werden.
  • 7D ist ein Flussdiagramm, das ein Verfahren zum Beziehen von Signalisierungsinformationen in einem MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S710 wird nach einem Rundfunk-Signal gesucht, wenn einer Rundfunk-Empfangsvorrichtung Strom zugeführt wird.
  • In Vorgang S720 verarbeitet die Rundfunk-Empfangsvorrichtung einen Turbo-Stream für einen primären Dienst. Der Turbo-Stream für einen primären Dienst kann in einem zusätzlichen Turbo-Kanal übertragen werden oder kann in mehrere Teile aufgeteilt werden und in einem Restdatenbereich eines Transport-Rahmens übertragen werden.
  • In Vorgang S730 stellt die Rundfunk-Empfangsvorrichtung den primären Dienst unter Verwendung des Ergebnisses der Verarbeitung in Vorgang S720 bereit. Simultan zu Vorgang S730 wird Vorgang S740 durchgeführt, um Signalisierungsinformationen zu beziehen. Informationen, die anzeigen, ob die Signalisierungsinformationen oder der Turbo-Stream für einen primären Dienst über einen separaten Kanal oder einen Restdatenbereich eines Transport-Rahmens übertragen werden, können in einem vorgegebenen Bereich eines Transport-Rahmens gespeichert werden, und die Signalisierungsinformationen sowie der Turbo-Stream für einen primären Dienst werden unter Verwendung dieser Informationen bezogen. Bei einem ATSC-System können diese Informationen im DFS gespeichert werden.
  • Wenn die Signalisierungsinformationen über einen separaten SIC übertragen werden, wird Vorgang S742 durchgeführt, um Signalisierungsinformationen zu beziehen, indem der SIC verarbeitet wird. Wenn die Signalisierungsinformationen in mehrere Teile aufgeteilt und über einen Restdatenbereich eines Transport-Rahmens übertragen werden, wird Vorgang S744 durchgeführt, um die Signalisierungsinformationen aus dem Restdatenbereich des Transport-Rahmens zu beziehen.
  • In Vorgang S750 wird festgestellt, ob die Signalisierungsinformationen aktualisiert sind. Wenn die Signalisierungsinformationen aktualisiert sind, wird Vorgang S740 erneut durchgeführt, um die aktualisierten Signalisierungsinformationen zu beziehen. Wenn die Signalisierungsinformationen nicht aktualisiert sind, wird Vorgang S760 unter Verwendung der Signalisierungsinformationen durchgeführt, um so Kanalwechsel durchzuführen.
  • 8 stellt ein Verfahren für schnellen Zugriff dar, das von einem ATSC-MCAST-System gemäß einer anderen Ausführungsform der vorliegenden Erfindung unterstützt wird. Wie unter Bezugnahme auf 8 zu sehen ist, werden Signalisierungsinformationen für schnellen Dienstzugang unterteilt.
  • Bei einem Echtzeit-Rich-Media-Dienst sollten Informationen, wie beispielsweise PSI (PAT, PMT, CAT oder NIT) zunächst erfasst werden, um Multimediadaten in einem Rundfunk-Empfänger zu decodieren. Ein Benutzer kann Video ansehen, nachdem er alle PSI empfangen hat. Obwohl der Empfänger einen Decodier-Rahmen bezogen hat, muss der Benutzer warten, bis der Empfänger decoderspezifische Informationen aus den PSI empfängt.
  • ATSC-MCAST hat vorgeschlagen, einen sog. Descriptor von spezifischen Informationen eines Multimedia-Decoders zu transportieren, die in jeden Multimedia-Elementar-Stream (ES) zu integrieren sind. Dies bedeutet, dass Decoder-Konfigurationsinformationen und Multimediadaten gleichzeitig transportiert werden. Daher muss der Empfänger nicht darauf warten, die PSI zu beziehen.
  • Das heißt, 8A ist ein Schema, dass die Dienstzugangszeit bei ATSC-MCAST gemäß der vorliegenden Erfindung mit der bei einem herkömmlichen Rundfunk-System vergleicht.
  • Es wird beispielsweise davon ausgegangen, das eine Übertragungsperiode von PAT und PMT 0,5 Sekunden beträgt und eine Übertragungsperiode eines I-Rahmens δ Sekunden beträgt. Im ungünstigsten Fall dauert es 0,5 + 0,5 + δ Sekunden bis zum Erscheinen des ersten Video-Bildes, da PAT, PMT und der I-Rahmen erfasst werden müssen. Bei ATSC-MCAST dauert es jedoch nur δ Sekunden, um einen ersten I-Rahmen zur Darstellung auf dem Empfänger zu bringen. Dementsprechend kann ATSC-MCAST den I-Frame beim Empfangen desselben schnell verarbeiten. Decoderspezifische Informationen werden unter Bezugnahme auf 8B beschrieben.
  • 8B stellt Decoder-Konfigurationsinformationen (DCI) gemäß einer Ausführungsform der vorliegenden Erfindung dar. Die DCI sind in einem ‚DCI-fleld‘-Feld enthalten.
  • Das in 8B dargestellte ’DCI_field‘-Feld bezieht sich auf Echtzeit-Medien in einer MCAST-Kapselungsschicht. In einem ‚decoder specific information‘-Feld, das in dem ‚DCI_fleld‘-Feld enthalten ist, sind spezifische Informationen für einen Medien-Decoder enthalten. Das ‚DCI_field‘-Feld kann nur in einem Kapselungspaket für Echtzeit-Medien vorhanden sein.
  • Ein ‚Content Type‘-Feld stellt einen Inhalts-Typ in dem Stream dar. Beispiele für den Inhalts-Typ, der entsprechend dem Wert dieses Feldes definiert ist, sind die Folgenden: [Tabelle 1]
    Wert Beschreibung des Inhalt-Typs
    0 reserviert
    1 H.264/AVC
    2 HE-AAC
    3 - 255 TBD
  • Ein ‚Max Decoding Buffer Size‘-Feld zeigt die Länge eines Decodier-Puffers in Bytes an. Die Definition eines Puffers hängt vom Typ eines Stream ab.
  • Ein ‚DSI length‘-Feld zeigt die Länge eines ‚decoder specific information‘-Feldes an, die in Bytes beschrieben wird.
  • Das ‚Decoder Specific Information‘-Feld beinhaltet decoderspezifische Informationen. Das ‚Decoder Specific Information‘-Feld hängt von dem Stream-Typ ab und stellt die Spezifikationen des Decoders dar.
  • 9 stellt ein Verfahren für schnellen Zugang dar, das von einem ATSC-MCAST-System gemäß einer anderen Ausführungsform der vorliegenden Erfindung unterstützt wird.
  • In 9 wird davon ausgegangen, dass IP-Datacasting oder ein IP-Service über MCAST bereitgestellt wird. Im Allgemeinen muss ein Dienstführer (service guide - SG) simultan zu IP-Datacasting oder dem IP-Dienst bereitgestellt werden, um IP-Datacasting oder den IP-Dienst bereitzustellen. Ein allgemeiner Rundfunk-Empfänger muss zunächst den SG beziehen, um IP-Datacasting oder den IP-Service zu beziehen. Im Folgenden wird ein SG, der in OMA-BCAST definiert ist, als ein Beispiel für SG verwendet, er ist jedoch darauf beschränkt. Jeder beliebige SG, der Informationen bezüglich IP-Datacasting oder eines IP-Services bereitstellt, oder Zugangsinformationen zum Zugang zu IP-Datacasting oder dem IP-Dienst können verwendet werden.
  • Ein Benutzer muss zunächst den SG beziehen, um einen Dienst über IP-Datacasting zu empfangen, und daher muss eine Rundfunk-Empfangsvorrichtung im Bereitschaftszustand sein, bis der SG empfangen wird, und zwar unabhängig davon, ob der Benutzer den SG verlangt. Um dieses Problem zu lösen, werden Informationen, die zum Empfangen von IP-Datacasting oder des IP-Service erforderlich sind, übertragen, so dass der Dienst zuerst bereitgestellt werden kann, ohne den SG zu empfangen. Dementsprechend ist schneller Dienstzugang hinsichtlich IP-Datacasting oder des IP-Dienstes möglich.
  • Das heißt, 9A stellt die Struktur von Transportdaten dar, die für schnellen Dienstzugang bei IP-Datacasting gemäß einer Ausführungsform der vorliegenden Erfindung verwendet werden.
  • Ein SIC enthält IP-Informationen zum Empfangen eines SG, wie beispielsweise die IP-Adresse des SG. Es ist möglich, eine feste Adresse zu verwenden, die einer Rundfunk-Empfangsvorrichtung bereits bekannt ist, so beispielsweise die IP-Adresse des SG, oder anzuzeigen, dass der SG in den IP-Informationen enthalten ist. Beispielsweise ist es möglich, Übertragung des SG in IP-Informationen unter Verwendung eines Flag indirekt auszudrücken, das IP-Informationen anzeigt, die dem SG entsprechen.
  • Des Weiteren kann der SIC zusätzliche Informationen beinhalten, um einem Benutzer einen Dienst bereitzustellen, bevor die Rundfunk-Empfangsvorrichtung den SG vollständig oder teilweise bezieht. Im Folgenden wird ein Dienst, der einem Benutzer bereitgestellt werden kann, bevor ein SG teilweise oder vollständig bezogen wird, als ein ‚repräsentativer Dienst‘ bezeichnet. Die zusätzlichen Informationen können Informationen zum Bereitstellen entweder von IP-Datacasting, das dem repräsentativen Dienst entspricht, oder des IP-Dienstes oder Informationen beinhalten, die die Position der Informationen anzeigen. Des Weiteren können die zusätzlichen Informationen eine IP-Adresse beinhalten, die sich auf den repräsentativen Dienst bezieht. An einer Position, die durch die IP-Adresse angezeigt wird, ist ein Stream zum Bereitstellen des repräsentativen Dienstes oder von Informationen, die zum Bereitstellen des repräsentativen Dienstes erforderlich sind, vorhanden. Ein Beispiel für derartige Informationen sind Flute-Session-Informationen, ein Session-Description-Protokoll (SDP) oder Stream-Verarbeitungsinformationen.
  • In einem MCAST-Sysstem kann es einen oder eine Vielzahl repräsentativer Dienste geben. Wenn eine Vielzahl repräsentativer Dienste bereitgestellt werden, werden der Rundfunk-Empfangsvorrichtung Informationen bezüglich der repräsentativen Dienste zugeführt, so dass ein Benutzer einen von ihnen auswählen kann. Wenn ein Benutzer einen einer Vielzahl repräsentativer Dienste auswählt, wird der ausgewählte repräsentative Dienst bereitgestellt, bis die Rundfunk-Empfangsvorrichtung den SG vollständig bezogen hat. Nachdem der SG vollständig bezogen worden ist, kann der Benutzer einen gewünschten Dienst erneut auf Basis des SG auswählen.
  • Als Alternative dazu kann nur ein repräsentativer Dienst bereitgestellt werden, oder ein ausgewählter repräsentativer Dienst kann selbst dann ohne eine Benutzerauswahl bereitgestellt werden, wenn eine Vielzahl repräsentativer Dienste bereitgestellt werden.
  • Innerhalb eines Turbo-Kanals werden ein IP-Stream zum Bereitstellen eines repräsentativen Dienstes und IP-Streams zum Bereitstellen eines allgemeinen Broadcast-Dienstes übertragen.
  • 9B ist ein Flussdiagramm, das ein Verfahren für schnellen Dienstzugang für IP-Datacasting gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S910 wird eine IMT bezogen. Die IMT stellt Zuordnungsinformationen zwischen einer IP-Adresse und einem Turbo-Kanal dar und kann über einen SIC übertragen werden.
  • In Vorgang S920 wird festgestellt, ob ein Transportsystem einen repräsentativen Dienst bereitstellt. Wenn kein repräsentativer Dienst bereitgestellt wird, wird Vorgang S932 durchgeführt, um einen SG zu beziehen. In diesem Fall ist es nicht möglich, einem Benutzer einen Rundfunk-Dienst bereitzustellen, ehe nicht ein vorgegebener Teil oder der gesamte SG bezogen worden ist. Wenn ein repräsentativer Dienst bereitgestellt wird, wird Vorgang S934 durchgeführt, um dem Benutzer den repräsentativen Dienst bereitzustellen. Das heißt, der repräsentative Dienst wird durch Parsing eines Streams bereitgestellt, wobei er unter Verwendung von Informationen bezüglich des repräsentativen Dienstes bereitgestellt wird, die in dem SIC (oder DFS) und einer IMT enthalten sind. Gleichzeitig wird Vorgang S936 zum Beziehen des SG in einem Hintergrund durchgeführt.
  • Nachdem der SG vollständig bezogen worden ist, wird Vorgang S940 durchgeführt, um festzustellen, ob die Benutzereingabe empfangen worden ist. Wenn die Benutzereingabe nicht empfangen worden ist, wird Vorgang S952 durchgeführt, um wiederholt den repräsentativen Dienst wiederzugeben oder im Bereitschaftszustand zu bleiben, bis die Benutzereingabe empfangen wird. Wenn die Benutzereingabe empfangen wird, wird Vorgang S954 durchgeführt, um einen IP-Stream zu verarbeiten und wiederzugeben, der einem durch den Benutzer ausgewählten Kanal entspricht.
  • 10A stellt Dienstkonfigurationsinformationen gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • SIC enthält Signalisierungsinformationen, so beispielsweise Informationen, die Turbo-Kanal-Informationen betreffen. Das heißt, der SIC weist Dienstkonfigurationsinformationen auf, die Turbo-Kanal-Positionsinformationen bezüglich jedes der Turbo-Kanäle in einem A-VSB-Rahmen beinhalten, Time-Slicing-Informationen sowie Informationen zum Verarbeiten jedes der Turbo-Kanäle. Der SIC kann ein Typ von Turbo-Kanal sein und kann an einer vorgegebenen Position in einem A-VSB-Rahmen vorhanden sein.
  • Die Struktur der Dienstkonfigurationsinformationen wird im Folgenden unter Bezugnahme auf 10A beschrieben.
  • Ein ‚turbo_channel_informatian_flag‘-Feld zeigt an, ob Turbo-Kanal-Informationen vorhanden sind. In der vorliegenden Ausführungsform beinhaltet das ‚turbo_channel_information‘-Feld Turbo-Kanal-Informationen, die weiter unten ausführlich unter Bezugnahme auf 13 beschrieben werden.
  • Ein ‚addftional_service_information-flag‘-Feld zeigt an, ob Beschreibungs-Informationen eines Turbo-Dienstes vorhanden sind. In der vorliegenden Ausführungsform beinhaltet das ‚additional_service_information‘-Feld zusätzliche Beschreibungsinformationen aller Turbo-Kanäle. Zusätzliche Dienstinformationen werden weiter unten ausführlich unter Bezugnahme auf 14 beschrieben werden.
  • Ein ‚padding_flag‘-Feld zeigt an, ob ein Padding-Bereich vorhanden ist.
  • Ein ‚version_indicator_information()‘-Feld zeigt die Version der Dienstkonfigurationsinformationen und den Zeitpunkt zum Aktualisieren dieser Informationen an. In der aktuellen Ausführungsform werden die Version des ‚ServiceConfigurationInformation()‘-Feldes und der Zeitpunkt zum Aktualisieren dieses Feldes angezeigt. Das ‚version_indicator_information()‘-Feld wird weiter unten ausführlich unter Bezugnahme auf 11 beschrieben.
  • Ein ‚frame_group_information()‘-Feld zeigt die Nummer eines aktuellen Rahmens und die Gesamtzahl von Rahmen innerhalb einer Rahmen-Gruppe an. Das ‚frame_group_information()‘-Feld wird weiter unter ausführlich unter Bezugnahme auf 12 beschrieben.
  • Ein ‚byte‘-Feld zeigt Füll- bzw. Padding-Bytes an und wird von einem Codierer verwendet. Es dient dazu, einen nicht zugewiesenen Bereich mit einem Wert OxFF aufzufüllen.
  • Ein ‚CRC‘-Feld enthält einen CRC-Wert.
  • 10B stellt Dienstkonfigurationsinformationen gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚current_frame_number‘-Feld zeigt die aktuelle Rahmen-Nummer an. Die Rahmen-Nummer wird innerhalb einer Rahmen-Gruppe um 1 inkrementiert.
  • Ein ‚total_frame_number‘-Feld zeigt die Gesamtzahl von Rahmen in der Rahmen-Gruppe an.
  • In der aktuellen Ausführungsform können die Dienstkonfigurationsinformationen Informationen bezüglich TCC oder eines broadcast descriptors (BD) entsprechend der aktuellen Rahmen-Nummer enthalten. Das heißt, wenn die aktuelle Rahmen-Nummer eine geradzahlige Nummer ist, sind die Informationen bezüglich des TCC enthalten, und wenn die aktuelle Rahmen-Nummer eine ungeradzahlige Nummer ist, sind die Informationen bezüglich des BD enthalten.
  • Ein ‚TCC_next_update_offset‘-Feld zeigt die Gesamtzahl von Rahmen vor Aktualisierung der Version der Turbo-Kanal-Konfigurationsinformationen an. In der aktuellen Ausführungsform beinhaltet das ‚Turbo_channel_configuration‘-Feld die Turbo-Kanal-Konfigurationsinformationen.
  • Ein ‚TCC_version‘-Feld besteht aus 3 Bits und zeigt die Versionsnummer von TCC-Feldern an. Die Versionsnummer sollte immer dann, wenn sich eines der sich auf die TCC beziehenden Felder ändert, um 1 modulo 8 inkrementiert werden.
  • Ein ‚number_of_turbo_channel‘-Feld zeigt die Gesamtzahl von Turbo-Kanälen an, die in A-VSB transportiert werden. Die Anzahl gestreuter SRS-Kanäle wird ebenfalls in diesem Feld angegeben.
  • Ein ‚turbo_channel_configuration‘-Feld enthält Turbo-Kanal-Konfigurationsinformation. Das ‚turbo_channel_configuration‘-Feld wird weiter unten ausführlicher unter Bezugnahme auf 16 beschrieben.
  • Ein ‚BD_next_update_offset‘-Feld zeigt die Anzahl von Rahmen vor Aktualisierung von BD an.
  • Ein ‚BD-paket()‘-Feld beinhaltet einen broadcast descriptor. Das ‚BD_paket()‘-Feld wird weiter unten ausführlicher unter Bezugnahme auf 22 beschrieben.
  • 10C stellt Dienstkonfigurationsinformationen gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar. Die in 10C dargestellten Dienstkonfigurationsinformationen sind bis auf ein ‚wake_up_mode‘-Feld die gleichen wie die in 10B dargestellten.
  • Das ‚wake_up_mode‘-Feld zeigt TCC-Parsing-Modus der folgenden TCC beim dem ‚TCC_next_update_offset‘-Feld an. Wenn der Wert dieses Feldes beispielsweise auf ‚1‘ eingestellt ist, kann Parsing der folgenden TCC durchgeführt werden.
  • 11 stellt die Struktur des in 10A dargestellten
    version_indicator_information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Bei mobilem Rundfunk sind die Dienstkonfigurationsinformationen außerordentlich wichtig. Ein ‚version_indicator_information()‘-Feld, das beschrieben wird, enthält Update-Informationen der Dienstkonfigurationsinformationen. So zeigt ein ‚service configuration Information()‘-Feld die genaue Position und Version eines Rahmens an, der geändert werden soll.
  • Ein ‚frame_counter‘-Feld zeigt die Gesamtzahl der Rahmen an, die gesendet werden, bevor sich die Dienstkonfigurationsinformationen ändern. Nachdem ein Transport-Rahmen empfangen wird, ändern sich die Dienstkonfigurationsinformationen.
  • Ein ‚version‘-Feld zeigt die Version der Dienstkonfigurationsinformationen an. Immer wenn sich die Dienstkonfigurationsinformationen ändern, wird der Wert der Version um 1 erhöht.
  • 12 stellt die Struktur des in 10A dargestellten ‚frame_group_information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Eine Rahmen-Gruppe ist eine Gruppe von Rahmen, die durch MCAST-Frame-Slicing erzeugt wird, und tritt periodisch beginnend mit der gleichen Rahmen-Nummer auf. In einem Übertragungssystem wird eine Methode, bei der Übertragungsdaten, die einen Dienst betreffen, in wenigstens einen Rahmen integriert werden und der Rahmen in einem Burst-Modus übertragen wird, als eine Frame-Slicing-Methode bezeichnet. Wenn die Frame-Slicing-Methode angewendet wird, gibt es Rahmen, die keine Daten bezüglich eines Zieldienstes enthalten, und ein Endgerät kann in einem Abschnitt, in dem ein derartiger Rahmen übertragen wird, in einen Ruhemodus übergehen, ohne ein Signal zu empfangen, wodurch Energie eingespart wird. Ein Burst-Abschnitt zeigt eine Rahmen-Gruppe an, die Daten bezüglich des Zieldienstes beinhaltet, und kann unter Verwendung einer Rahmen-Nummer ausgedrückt werden, die weiter unten beschrieben wird.
  • Ein ‚current_frame_number‘-Feld zeigt die Nummer eines aktuellen Rahmens in einer Rahmen-Gruppe an. Die Rahmen-Nummer kann innerhalb einer Rahmen-Gruppe um 1 inkrementiert werden.
  • Ein ‚total_frame_number‘-Feld zeigt die Gesamtzahl von Rahmen in der Rahmen-Gruppe an.
  • 13 stellt die Struktur des in 10A dargestellten ‚turbo_channel_information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚turbo_channel_information()‘-Feld zeigt Turbo-Kanal-Informationen an und beinhaltet Informationen, die für eine Vielzahl von Turbo-Kanälen unabdingbar sind. Physikalische Decodier-Informationen, Informationen, die anzeigen, ob MCAST-Frame-Slicing vorliegt, und die Gesamtzahl von Turbo-Kanälen sind wichtige Faktoren. Insbesondere, wenn MCAST-Frame-Slicing unterstützt wird, zeigt das ‚turbo_channel_information()‘-Feld die Nummer eines aktuellen Rahmens sowie die Gesamtzahl von Rahmen-Blöcken an, die für einen ausgewählten Turbo-Kanal empfangen werden sollen.
  • Ein ‚version‘-Feld besteht aus drei Bits und zeigt die Version der Turbo-Kanal-Informationen an. In der aktuellen Ausführungsform kann die Version immer dann um 1 zunehmen, wenn das ‚turbo_channel_information()‘-Feld geändert wird. Wenn die Version geändert wird, sollten die Turbo-Kanal-Informationen im Voraus transportiert werden.
  • Ein ‚Turbo_svc‘-Feld zeigt die Gesamtzahl von Turbo-Kanälen in einem A-VSB-System gemäß einer Ausführungsform der vorliegenden Erfindung an.
  • Ein ‚Turbo_svc_id‘-Feld zeigt die Kennung eines aktuellen Turbo-Kanals an.
  • Ein ‚Is_Enhanced‘-Feld zeigt an, ob Daten Basisdaten oder erweiterte Daten sind. Wenn beispielsweise ein „skalierbarer“ Video-Codec angewendet wird, können ein Elementar-Stream und ein erweiterter Stream in einem separaten Turbo-Kanal oder einem Teil-Datenkanal enthalten sein. Wenn der Elementar-Stream und der erweiterte Stream in dem separaten Turbo-Kanal enthalten sind, ist es möglich, zwischen dem Elementar-Stream und dem erweiterten Stream unter Verwendung des ‚Is_Enhanced‘-Feldes zu unterscheiden.
  • Ein ‚MCAST_Frame_Slicing_flag‘-Feld gibt an, ob ein aktueller Turbo-Stream in einem Burst-Modus übertragen wird.
  • Ein ‚MCAST_AL_FEC_flag‘-Feld gibt an, ob ein aktueller Turbo-Stream Anwendungsschicht-FEC (AL-FEC) unterstützt.
  • Ein ‚turbo_start_position‘-Feld zeigt eine Startposition eines Turbo-Kanals an.
  • Ein ‚turbo_fragments_bits‘-Feld zeigt den Index einer Turbo-Kanal-Länge an.
  • Ein ‚turbo_arrange_index‘-Feld zeigt eine Zahl an. Wenn die Zahl n ist, bedeutet dies, dass jedes n-te Paket ein Turbo-Kanal-Fragment enthält.
  • Ein ‚coding_rates‘-Feld zeigt den Index einer Turbo-Kanal-Codierrate an.
  • Ein ‚start_frame_number‘-Feld zeigt eine Anfangs-Rahmen-Nummer eines aktuellen Turbo-Dienstes an, wenn MCAST-Frame-Slicing vorliegt.
  • Ein ‚frame_block_number‘-Feld gibt die Gesamtzahl eines aktuellen Turbo-Kanals an.
  • 14 stellt die Struktur des in 10A dargestellten
    ‚additional_service-information()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein SIC stellt eine Struktur zum Transportieren zusätzlicher Informationen bereit. In der aktuellen Ausführungsform enthält das ‚additional_service_information()‘-Feld zusätzliche Informationen. Das ‚additional_service_information()‘-Feld kann unter Verwendung einer Vielzahl von Blöcken geliefert werden und zeigt den aktuellen sowie letzte Indizes segmentierter Blöcke an.
  • Ein ‚current_index‘-Feld zeigt den Index eines aktuellen Index innerhalb der Gesamtzahl von Beschreibungsblöcken an.
  • Ein ‚last_index‘-Feld zeigt den Index eines letzten Blocks innerhalb der Gesamtzahl der Beschreibungsblöcke an.
  • Ein ‚length‘-Feld zeigt die Länge zusätzlicher Dienstinformationen an.
  • Ein ‚user_data‘-Feld zeigt die Syntax privater Nutzerdaten an, die <tag><length><data> folgen sollten. Die tag-Werte können gemäß Tabelle 2 definiert werden. [Tabelle 2]
    Tag Kennung
    0 reserviert
    1 turbo channel information descriptor
    2 - 255 TBD
  • Wenn der Tag-Wert ‚1‘ ist, enthält das ‚user_data‘-Feld einen turbo channel information descriptor, der weiter unten unter Bezugnahme auf 15 beschrieben wird.
  • 15 stellt die Struktur eines `Turbo_channel_information_description()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar. Die Struktur des ‚Turbo_channel_information_description()‘-Feldes gleicht der des in 13 dargestellten ‚turbo_channel_information‘-Feldes.
  • 16A stellt die Struktur des in 10B dargestellten
    ‚turbo_channel_configuration()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚turbo_channel_configuration()‘-Feld beinhaltet Konfigurationsinformationen, die für Turbo-Kanäle unabdingbar sind. Das ‚turbo_channel_configuration()‘-Feld kann ähnlich wie das In 13 dargestellte ‚turbo_channel_information‘-Feld wichtige Informationen beinhalten, so beispielsweise physikalische Decodier-Informationen, Informationen, die anzeigen, ob Frame-Slicing vorliegt, sowie Informationen bezüglich der Gesamtzahl von Turbo-Kanälen.
  • Ein ‚selector_bits‘-Feld zeigt an, ob Frame-Slicing, ein gestreuter SRS-Kanal, ein Turbo-Kanal oder ein ‚turbo_channel_descriptor_loop‘-Feld vorhanden ist. Die folgende Tabelle 3 zeigt die Definition des ‚selector_bits‘-Feldes entsprechend seinem Wert. In Tabelle 3 kann ‚x‘ ‚0‘ oder ‚1‘ betragen. [Tabelle 3]
    selector_bits-Wert Beschreibung
    0B1xx Frame-Slicing
    OBx1 x Position des gestreuten SRS-Kanals
    OBxOx Turbo-Kanal-Position
    0Bxx1 turbo channel descriptor loop
  • Ein ‚turbo_channel_id‘-Feld zeigt die Kennung des Turbo-Kanals an. Wenn ein bestimmter descriptor bzw. Descriptor des Turbo-Kanals enthalten ist, dient dieses Feld zur Identifizierung des Turbo-Kanals. Wenn dieses Feld jedoch einen vorgegebenen Wert hat, beispielsweise 0 × 1f, dann wird der Descriptor auf alle Turbo-Kanäle angewendet. Wenn beispielsweise ein Feld, das Informationen bezüglich einer Rahmen-Gruppe beinhaltet, aktualisiert wird und der Wert des ‚turbo_channel_id‘-Feldes 0 × 1f beträgt, werden die Informationen bezüglich der Rahmen-Gruppe auf ein ‚turbo_channel_configuration‘-Feld angewendet, das sich auf alle Kanäle bezieht.
  • Ein ‚start_frame_number‘-Feld zeigt die Nummer eines Anfangs-Rahmens eines Dienstes an, der in einem Burst-Modus geliefert wird. Der Anfangs-Rahmen ist ein erster Rahmen, der zu empfangen ist, um den Dienst zu beziehen.
  • Ein ‚frame_count‘-Feld zeigt die Gesamtzahl von Rahmen an, die zu empfangen sind, um den Dienst in dem Burst-Modus zu beziehen.
  • Ein ‚reserved‘-Feld ist ein für zukünftige Verwendung reserviertes Feld. Der Wert des ‚reserved‘-Feldes ist auf ‚1‘ festgelegt. In der vorliegenden Patentbeschreibung ist die Funktion des ‚reserved‘-Feldes die gleiche, und es wird daher im Folgenden nicht mehr beschrieben.
  • Ein ‚turbo_cluster_size‘-Feld zeigt Cluster-Größe von SRS-Streams an, die in einer Vielzahl von Sektoren verstreut sind.
  • Ein ‚is_enhanced‘-Feld zeigt an, ob ein aktueller Turbo-Kanal erweiterte Daten beinhaltet. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, kann dies bedeuteten, dass der aktuelle Turbo-Kanal erweiterte Daten beinhaltet. In diesem Fall sollten Basis- und erweiterte Kanäle die gleiche Turbo-Kanal-Kennung nutzen. Ein Empfänger kann beide Kanäle empfangen und sie als ein Kanal bereitstellen. Wenn beispielsweise ein ‚skalierbarer‘ Video-Codec anwendet wird, ist die Qualität von Video, die beim Empfang von beiden Kanälen geboten wird, höher als wenn nur ein Kanal empfangen wird.
  • Ein ‚adaptive_time_slicing_flag‘-Feld zeigt an, ob ein aktueller Turbo-Kanal adaptives Time-Slicing unterstützt. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, kann dies bedeuten, dass der aktuelle Turbo-Kanal adaptives Time-Slicing unterstützt. Eine physikalische Konfiguration wird entsprechend diesem Feld geändert.
  • Ein ‚coding_rates‘-Feld zeigt den Index einer Turbo-Kanal-Codierrate an.
  • Ein ‚full_packet_flag‘-Feld zeigt an, ob ein erster Sektor eines Turbo-Streams über ein Null-Paket oder ein spezifiziertes PID-Paket übertragen wird. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, wird der erste Sektor über ein Null-Paket oder ein spezifiziertes PID-Paket ohne ein AF-Header-Feld transportiert. Desgleichen wird der erste Sektor über das AF transportiert, wenn der Wert dieses Feldes auf ‚0‘ eingestellt ist.
  • Ein ‚turbo_start_sector‘-Feld zeigt die physikalische Startposition des Turbo-Stream an.
  • Ein ‚turbo_cluster_size‘-Feld zeigt Cluster-Größe des Turbo-Stream in einer Vielzahl von Sektoren an.
  • Ein ‚turbo_channel_descriptor_loop()‘-Feld stellt zusätzliche optionale Informationen bezüglich des Turbo-Kanals bereit. Dieses Feld wird weiter unten ausführlicher unter Bezugnahme auf 17 beschrieben.
  • 16B stellt die Struktur des in 10B dargestellten
    ‚turbo_channel_configuration()‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Die Struktur des in 16B dargestellten ‚turbo_channel_configuration()‘-Feldes ist bis auf das ‚enhanced_protection_mode‘-Feld die gleiche wie die des in 16A dargestellten ‚turbo_channel_configuration()‘-Feldes.
  • Ein ‚enhanced_protection_mode‘-Feld zeigt an, ob ein erweiterter Schutzmodus unterstützt wird. Dies ist der Fall, wenn ein Fehler entsprechend dem Typ der übertragenen Daten oder einer Kommunikationsumgebung leicht korrigiert werden kann. In diesem Fall kann Fehlerkorrektur einfach ausgeführt werden, indem die Länge von Nutzdaten in einem Paket reduziert wird und ein RS-Byte vergrößert wird. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, ist die Nutzdaten-Länge eines Transportpaketes 168 Bytes lang, und das RS-Byte hat 40 Bytes. Wenn der Wert dieses Feldes jedoch auf ‚0‘ eingestellt ist, ist die Nutzdaten-Länge 188 Bytes lang, und das RS-Byte hat 20 Bytes.
  • 17 stellt die Struktur des in 16A dargestellten ‚descriptor_loop()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚descriptor_loop()‘-Feld ermöglicht Signalisierung zusätzlicher Informationen bezüglich jedes der Turbo-Kanäle. Eine Änderung von Informationen, wie beispielsweise der Rahmen-Gruppen-Nummern, einer Dauer von Time-Slicing bezüglich der Turbo-Kanäle und der Positionen der Turbo-Kanäle, werden mit dem ‚descriptor_loop()‘-Feld signalisiert.
  • Ein ’next_indicator‘-Feld ist ein 1-Bit-Feld und zeigt das Vorhandensein des folgenden ‚descriptor_information‘-Feldes an. Wenn der Wert dieses Feldes auf ‚1‘ gestellt ist, folgt das ‚descriptor_information‘-Feld. Wenn der Wert dieses Feldes auf ‚0‘ eingestellt ist, ist kein ‚descriptor_information‘-Feld in dem ‚descriptor_loop()‘-Feld vorhanden.
  • Ein ‚tag‘-Feld zeigt die Kennung des ‚descriptar_information‘-Feldes wie in der folgenden Tabelle 4 definiert an. [Tabelle 4]
    Tag Beschreibung
    0 Rahmen-Gruppen-Aktualisierung
    1 Frame-Slicing-Dauer-Aktualisierung
    2 SRS-Positions-Aktualisierung
    3 Turbo-Kanal-Positions-Aktualisierung
    4 -127 für zukünftige Verwendung reserviert
  • Ein ‚length‘-Feld zeigt die Gesamtlänge des ‚descriptor_information‘-Feldes in Bytes an.
  • Ein ‚descriptor_information‘-Feld kann entsprechend dem Wert des ‚tag‘-Feldes verschieden definiert sein. Das in Tabelle 4 definierte ‚descriptor_information‘-Feld wird weiter unten ausführlicher unter Bezugnahme auf 18 bis 21 beschrieben.
  • 18 stellt die Struktur eines ‚frame_group_update‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚0‘ eingestellt ist.
  • Rahmen-Gruppen-Aktualisierung kann beim Ändern einer Periode von Time-Slicing angewendet werden. Das heißt, das ‚Frame_group_update‘-Feld kann verwendet werden, um die Gesamtzahl von Frame-Gruppen zu aktualisieren. Das ‚Frame_group_update‘-Feld kann wenigstens 6 Sekunden vor der Aktualisierung signalisiert werden. Die in diesem Feld beinhalteten Informationen werden auf die Konfigurationen aller Turbo-Kanäle angewendet. Wenn dieses Feld empfangen wird, kann ein ‚selector bits‘-Feld auf ‚0 × 001‘ eingestellt werden, um Rahmen-Gruppen-Aktualisierung anzuzeigen und ein ‚turbo_channel_id‘-Feld kann auf einen vorgegebenen Wert eingestellt werden, beispielsweise '0 × 1f, der bestimmt wird, um Rahmen-Gruppen-Aktualisierung auf den gesamten Turbo-Kanal anzuwenden.
  • Ein ‚next_update_offset‘-Feld zeigt die Gesamtzahl an Rahmen an, die verbleiben, bevor die Anzahl neuer GOF (Groups Of Frame) angewendet wird. Dieses Feld hat einen relativen Wert, der auf den oben beschriebenen ‚TCC_next_update_offset‘-Feld basiert. So wird der Wert dieses Feldes geändert, wenn TCC aktualisiert wird. Das heißt, der Wert dieses Feldes wird nicht Rahmen für Rahmen geändert, sondern wird immer dann geändert, wenn sich die TCC-Version ändert, um damit die Häufigkeit zu reduzieren, mit der TCC aktualisiert wird.
  • Ein ‚new_GOF‘-Feld zeigt die Gesamtzahl neuer GOF an.
  • 19A stellt die Struktur eines ‚Frame_Slicing_Duration_Update‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn das in 17 dargestellte ‚tag‘-Feld auf’1‘ eingestellt ist.
  • Ein ‚Frame_Slicing_Duration_Update‘-Feld wird eingesetzt, wenn die Anzahl von Rahmen, die Frame-Slicing bilden, in einem aktuellen Turbo-Kanal geändert wird. Die folgende Gleichung 1 kann angewendet werden, um eine Pausen-Dauer zu berechnen, wenn Frame-Slicing angewendet wird. In diesem Fall wird Aktualisierung in Einheiten der Anzahl von Rahmen durchgeführt, die eine Rahmen-Gruppe bilden. ( TCC _ next _ update + start _ frame _ number ) * 48.4 ms + jitter time
    Figure DE112008000552B4_0001
  • In Gleichung (1) bedeutet ‚Jitter-Zeit‘ eine Setup-Zeit, die für eine physikalische Schicht erforderlich ist, und ‚48,4 ms‘ steht für einen Zyklus, in dem ein VSB-Rahmen übertragen wird. Die vorliegende Erfindung ist jedoch nicht auf den VSB-Rahmen beschränkt, wenn eine Übertragungsperiode durch einen anderen Transport-Rahmen und eine andere Rahmen-Gruppe bestimmt wird.
  • Ein ‚new_start_frame_number‘-Feld zeigt die Nummer eines neuen Anfangs-Rahmens für Frame-Slicing innerhalb einer GOF an.
  • Ein ‚new_frame_count‘-Feld zeigt eine neue Abschluss-Rahmen-Nummer für Frame-Slicing innerhalb der GOF an.
  • 19B stellt die Struktur des ‚Frame_Slicing_Duration_Update‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚1‘ eingestellt ist.
  • Gleichung (2) bezeichnet eine Zeit, die erforderlich ist, um einen ersten Rahmen für Frame-Slicing in einem ‚descriptor_information‘-Feld zu beziehen, dessen Syntax in 19B dargestellt ist: ( TCC _ next _ update _ offset + next _ update _ offset ) * 48.4 ms + jitter time
    Figure DE112008000552B4_0002
  • Die in 19B dargestellten ‚descriptor_information‘-Felder sind bis auf ein ‚next_update_offset‘-Feld die gleichen wie die in 19A dargestellten.
  • Das ‚next_update_offset‘-Feld zeigt die Position eines Rahmens, auf den neue Frame-Slicing-Informationen angewendet werden sollen, auf Basis eines ‚TCC_next_update_offset‘-Feldes an.
  • 20A stellt die Struktur eines ‚SRS_position_update‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚2‘ eingestellt ist.
  • Ein ‚SRS_position_update‘-Feld wird verwendet, wenn sich die Position eines gestreuten SRS ändert. Ein Zeitpunkt, zu dem neue Positionsinformationen angewendet werden sollen, kann auf Basis des Anfangs einer GOF relativ berechnet werden.
  • Ein ‚start_frame_offset‘-Feld zeigt die Nummer eines Anfangs-Rahmens an, auf den die neue SRS-Position innerhalb einer neuen GOF angewendet werden soll.
  • Ein ‚turbo_cluster_size‘-Feld zeigt die Größe eines neuen Turbo-Clusters in einer Vielzahl von Sektoren an.
  • 20B stellt die Struktur des ‚SRS_position_update‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚2‘ eingestellt ist.
  • Das ‚SRS_position_update‘-Feld ist bis auf ein ‚next_update_offset‘-Feld das gleiche wie das in 20A dargestellte.
  • Das ‚next_update_offset‘-Feld zeigt eine nächste Aktualisierungs-Position an, an der die folgenden Werte angewendet werden.
  • Ein Zeitpunkt, zu dem neue Positionsinformationen angewendet werden sollen, kann ausgedrückt werden, indem die Werte eines ‚TCC_next_update_offset‘-Feldes und des ‚next_update_offset‘-Feldes addiert werden. Ansonsten kann der Wert des ‚next_update_offset‘-Feldes als ein relativer Wert des Wertes des ‚TCC_next_update_offset‘-Feldes verwendet werden.
  • 21A stellt die Struktur eines ‚turbo_channel_update‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚3‘ festgelegt wird.
  • Das ‚turbo_channel_update‘-Feld wird verwendet, wenn die Position eines Turbo-Kanals aktualisiert wird. Dieses Feld sollte nach Empfang eines ‚TCC_next_update_offset‘-Feldes angewendet werden, das anzeigt, dass eine neue GOF empfangen wird.
  • Eine ‚start_frame_offset‘-Feld zeigt die Nummer eines Anfangs-Rahmens innerhalb einer neuen GOF an. Von diesem Rahmen an sollte ein neues ‚turbo_cluster_size‘-Feld angewendet werden.
  • Ein ‚is_enhanced‘-Feld zeigt an, ob ein aktueller Turbo-Kanal erweiterte Daten beinhaltet. Wenn der Wert dieses Feldes auf ‚1‘ gestellt ist, kann dies bedeuten, dass der aktuelle Turbo-Kanal erweiterte Daten beinhaltet. In diesem Fall können Basis- und Erweiterungskanäle, wie oben beschrieben, die gleiche Turbo-Kanal-Kennung verwenden.
  • Ein ‚coding_rates‘-Feld zeigt den Index einer Turbo-Kanal-Codierrate an.
  • Ein ‚full_packet_flag‘-Feld zeigt an, ob ein erster Sektor in einem Turbo-Stream über ein Null-Paket oder ein spezifisches PID-Paket ohne Verwendung eines AF-Header-Feldes übertragen wird. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, kann der erste Sektor des Turbo-Streams von einem Null-Paket oder einem spezifizierten PID-Paket ohne Verwendung des AF-Header-Feldes transportiert werden. Wenn der Wert dieses Feldes auf ‚0‘ eingestellt ist, kann der erste Sektor von dem AF-Header-Feld transportiert werden.
  • Ein ‚turbo_start_sector‘-Feld zeigt eine physikalische Anfangsposition des Turbo-Stream an.
  • Eine ‚turbo_cluster_size‘-Feld zeigt die Cluster-Größe des Turbo-Stream in einer Vielzahl von Sektoren an.
  • 21B stellt die Struktur des ‚turbo_channel_update‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 17 dargestellten ‚tag‘-Feldes auf ‚3‘ eingestellt ist.
  • Das in 21B dargestellte ‚turbo_channel_update‘-Feld ist bis auf ein ‚next_update_offset‘-Feld, ein ‚adaptive_time_slicing_flag‘-Feld und ein ‚enhanced_protection_mode‘-Feld das gleiche wie das in 21A dargestellt.
  • Das ‚next_update_offset‘-Feld zeigt eine Aktualisierungsposition an, an der die folgenden Werte angewendet werden. Ein Zeitpunkt, zu dem neue Positionsinformationen angewendet werden, kann ausgedrückt werden, indem die Werte eines ‚TCC_next_update_offset‘-Feldes und eines ‚next_update_offset‘-Feldes addiert werden. Ansonsten kann der Wert des ‚next_update_offset‘-Feldes als ein relativer Wert des ‚TCC_next_update_offset‘-Feldes verwendet werden.
  • Das ‚adaptive_time_slicing_flag‘-Feld zeigt an, ob ein aktueller Turbo-Kanal adaptives Time-Slicing unterstützt. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, kann daraus geschlossen werden, dass der aktuelle Turbo-Kanal adaptives Time-Slicing unterstützt. Die physikalische Konfiguration des ‚turbo_channel_update‘-Feldes wird aufgrund dieses Feldes geändert.
  • Das ‚enhanced_protection_mode‘-Feld zeigt an, ob der aktuelle Turbo-Kanal einen erweiterten Schutzmodus unterstützt. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, kann daraus geschlossen werden, dass der aktuelle Turbo-Kanal den erweiterten Schutzmodus unterstützt.
  • Wenn der Wert dieses Feldes beispielsweise auf ‚1‘ eingestellt ist, kann die Länge Nutzdaten in einem Transportpaket 168 Bytes betragen, und die Länge des RS-Byte kann 40 Bytes betragen, um erweiterten Schutz zu gewährleisten. Wenn jedoch der Wert dieses Feldes auf ‚0‘ eingestellt ist, kann die Länge der Nutzdaten 188 Bytes betragen, und die Länge des RS-Byte kann 20 Bytes betragen.
  • 22A stellt die Struktur eines ‚BD_Packet‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das ‚BD_Packet‘-Feld wird genutzt, um zusätzliche Informationen zu transportieren, die sich auf Turbo-Streams beziehen, so beispielsweise eine IP-Mapping-Tabelle und Turbo-Kanal-Aktualisierungsinformationen. Dieses Feld ist auf alle Turbo-Kanäle anzuwenden und kann innerhalb mehrerer Fragmente transportiert werden.
  • Ein ‚first_last‘-Feld besteht aus zwei Bits und gibt, wie in Tabelle 5 definiert, an, ob ein Paket ein erstes oder letztes Paket ist. [Tabelle 5]
    Wert Beschreibung
    00 mittleres Paket einer Reihe
    01 letztes Paket einer Reihe
    10 erstes Paket einer Reihe
    11 das einzige Paket
  • Ein ‚padding_flag‘-Feld gibt an, ob Padding-Bytes vorhanden sind.
  • Ein ‚BD_version‘-Feld besteht aus drei Bits und zeigt die Versionsnummer eines broadcast descriptors (BD) an. Die Versionsnummer sollte immer dann, wenn der BD aktualisiert wird, um 1 modulo 8 inkrementiert werden.
  • Ein ‚padding_length‘-Feld gibt die Nummer von Bytes zum Auffüllen in einem ‚BD_packet‘-Feld an.
  • Ein ‚padding_byte‘-Feld weist einen oder mehr 8 Bit-Werte auf, die auf ‚0 × FF‘ eingestellt sind und von einem Codierer eingefügt werden können. Dieses Feld wird von einem Decoder verworfen.
  • Ein ‚BD_Fragment‘-Feld beinhaltet fragmentierte BD. Das heißt, ein BD wird in eine Vielzahl von Fragmentteilen unterteilt und wird über das ‚BD_Fragment‘-Feld geliefert. Ein BD wird weiter unten ausführlich unter Bezugnahme auf 23 beschrieben.
  • 22B stellt die Struktur eines ‚BD_Packet‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Das in 22B dargestellte ‚BD Packet‘-Feld ist bis auf ein ‚System_time_flag‘-Feld und einem ‚system_time‘-Feld das gleiche wie das in 22A dargestellt.
  • Das ‚System_time_flag‘-Feld zeigt an, ob Systemzeitinformationen vorliegen. In der vorliegenden Patentbeschreibung beinhaltet ein ‚system_time‘-Feld die Systemzeitinformationen. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, bedeutet dies, dass das ‚system_time‘-Feld vorhanden ist.
  • Das ‚system_time‘-Feld zeigt die Systemzeit an. Die Systemzeit kann auf Basis der absoluten Zeit, wie beispielsweise UTC, ausgedrückt werden, die unabhängig vom Ort die gleiche ist, kann jedoch auch auf Basis von Zeit ausgedrückt werden, die durch ein Übertragungssystem beeinflusst wird. Die Systemzeit kann zum Korrigieren von Zeit in einem Endgerät verwendet werden. Zu diesem Zweck kann ein Differenzwert (Offset-Zeit) entsprechend einem Ort angewendet werden. Die Systemzeit kann verwendet werden, um die Zeit einer Dienstbereitstellungsseite mit der einer Dienstempfangsseite in Übereinstimmung zu bringen oder diese Zeiten zu korrigieren. Beispielsweise können Informationen, wie ein ESG (Electronic Service Guide), Zeitinformationen enthalten, z.B. Zeiten, zu denen jeder Dienst beginnt oder endet. In diesem Fall kann eine Rundfunk-Empfangsvorrichtung einen Dienst, der einem Benutzer bereitgestellt werden soll, genau nach Plan unter Verwendung von Systemzeitinformationen beginnen oder beenden.
  • 23 stellt die Struktur eines Broadcast-Descriptors (BD) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Der BD ist in mehrere BD-Fragmente fragmentiert und wird einem ‚BD_packet‘-Feld zugeordnet.
  • Ein ‚number_of_BD‘-Feld zeigt die Gesamtzahl von ‚Broadcast_Descriptor_information‘-Feldern an, die weiter unten beschrieben werden.
  • Ein ‚tag‘-Feld zeigt den Typ von Daten an, die in dem ‚Broadcast_Descriptor_information‘-Feld enthalten sind. Beispiele für Datentypen entsprechend dem Wert dieses Feldes sind die folgenden: [Tabelle 6]
    Tag Beschreibung
    0 untersagt
    1 Kanal-Info-Aktualisierung
    2 IP mapping descriptor
    3 - 127 reserviert
  • Ein ‚length‘-Feld zeigt die Länge des ‚Broadcast_Descriptor_Information‘-Feldes an.
  • Der Typ der Daten in dem ‚Broadcast_Descriptor_information‘-Feld wird entsprechend Tabelle 6 bestimmt. Die Struktur des ‚Broadcast_Descriptor_information‘-Feldes entsprechend dem Datentyp wird weiter unten unter Bezugnahme auf 24 und 25 beschrieben.
  • 24A stellt die Struktur eines ‚Channel_info_update()‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn das in 23 dargestellte ‚tag‘-Feld einen Wert 1 hat.
  • Das ‚channel_info_update()‘-Feld dient dazu, Turbo-Kanal-Informationen zu aktualisieren. Dieses Feld zeigt an, wenn neue Turbo-Kanal-Informationen angewendet werden sollten. Versions- und Turbo-Kanal-Konfigurationsinformationen können in diesem Feld enthalten sein.
  • Ein ‚update_frame_counter‘-Feld zeigt eine relative Rahmen-Nummer auf Basis der Bezugs-Rahmen-Nummer an, auf die die neue TCC angewendet werden soll.
  • Ein ‚new_TCC_version‘-Feld zeigt die Version der Informationen der TCC an. Dieses Feld sollte identisch mit einem ‚TCC_version‘-Feld sein, das in einem SIC vorhanden ist, wenn Aktualisierung durchgeführt wird.
  • Ein ‚number_of_turbo_channel‘-Feld zeigt die Anzahl folgender new_turbo_channel_configuration()-Felder an.
  • Die Struktur eines ‚new_turbo_channel_configuration()‘-Feldes kann die gleiche sein wie die des oben beschriebenen ‚turbo_channel_configuration()‘-Feldes.
  • 24B zeigt die Struktur des ‚Channel_info_update()‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn das in 23 dargestellte ‚tag‘-Feld einen Wert 1 hat.
  • Das in 24B dargestellte ‚Channel_info_update()‘-Feld ist bis auf ein ‚next_update_offset‘-Feld das gleiche wie das in 24A dargestellte.
  • Das ‚next_update_offset‘-Feld zeigt einen Rahmen an, auf den ein neuer TCC angewendet werden soll. Dieses Feld hat einen relativen Wert, der auf einem ‚BD_next_update_offset‘-Feld basiert.
  • 24C stellt die Struktur des ‚Channei_info_update()‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Das in 24C dargestellte ‚Channel_info_update()‘-Feld ist bis auf ein ‚update_frame_counter‘-Feld und ein ‚new_TCC_version‘-Feld das gleiche wie das in 24B dargestellte.
  • Das ‚update_frame_counter‘-Feld zeigt einen Rahmen an, auf den ein neuer TCC angewendet werden soll.
  • Das ‚new_TCC_version‘-Feld zeigt die Versionsinformationen der TCC an. Der Versionswert kann identisch mit dem der Version von TCC in einem SIC sein.
  • 25A stellt ein IP mapping descriptor gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 23 dargestellten ‚tag‘-Feldes auf ‚1‘ eingestellt ist.
  • Der IP mapping descriptor stellt Mapping- bzw. Zuordnungsinformationen zwischen einem IP-Stream und einem Turbo-Kanal bereit. Wenigstens Turbo-Kanal-Informationen, eine IP-Adresse, eine MAC-Adresse oder eine einfache Beschreibung eines IP können in dem IP mapping descriptor enthalten sein. In der aktuellen Ausführungsform zeigt eine IP-Mapping-Tabelle (IMT) einen IP mapping descriptor an.
  • Ein ‚Extended_version‘-Feld zeigt an, ob die IMT aktualisiert ist. Wenn der Wert dieses Feldes auf ‚0‘ eingestellt ist, ist daraus zu schließen, dass die IMT selbst dann nicht aktualisiert ist, wenn ein ‚BD_version_number‘-Feld aktualisiert ist.
  • Ein ‚Number_of_IP‘-Feld zeigt die Gesamtzahl von IP-Streams an.
  • Eine ‚Reference_ch_flag‘-Feld zeigt an, ob ein aktueller Kanal ein Bezugskanal ist. Wenn der Wert dieses Feldes auf ‚1‘ eingestellt ist, ist daraus zu schließen, dass der aktuelle Kanal der Bezugskanal ist. Ein Beispiel des Bezugskanals kann ein ESG-Sammelkanal sein. Bei ESG-Informationen handelt es sich um eine große Menge an Informationen, und daher können im Allgemeinen die ESG-Informationen nicht vollständig in einem Kanal enthalten sein. In diesem Fall kann eine Rundfunk-Empfangsvorrichtung alle ESG-Informationen nur über den Bezugskanal sammeln. Daher kann über einen individuellen Kanal eine kleinere Menge an ESG-Informationen als über den Bezugskanal übertragen werden, um so Inhalt eine größere Bandbreite zuzuweisen.
  • Ein ‚turbo_channel_id‘-Feld zeigt die Kennung eines aktuellen Turbo-Kanals an.
  • Eine ‚LMT_index_number‘-Feld zeigt die Positionen der IP-Streams in einem Turbo-Kanal an. Die IP-Streams werden einem Teil-Datenkanal in dem Turbo-Kanal zugeordnet.
  • Ein ‚number_of_IP_ch_descriptor‘-Feld zeigt die Anzahl von ‚IP_channel_description‘-Feldern an, die folgen.
  • Ein ‚IP_channel_description‘-Feld beinhaltet zusätzliche Informationen des IP-Channel. Dieses Feld wird weiter unter ausführlich unter Bezugnahme auf 26 beschrieben.
  • 25B stellt einen IP-Mapping-Descriptor gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Die in 25B dargestellte IMT ist bis auf ein ‚number_of_channel‘-Feld und ein ‚VMI‘-Feld die gleiche wie die in 25A dargestellte.
  • Das ‚number_of_channel‘-Feld zeigt die Gesamtzahl von Turbo-Kanälen oder Teil-Datenkanälen an.
  • Das ‚VMI (virtual map ID)‘-Feld zeigt die Kennung eines Teil-Datenkanals in einem Turbo-Kanal an.
  • 26 stellt die Struktur des in 25A dargestellten ‚IP_channel_description‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das ‚IP_channel_description‘-Feld wird verwendet, um zusätzliche Informationen bezüglich eines IP-Kanals zu übertragen, wie dies oben beschrieben ist.
  • Ein ‚tag‘-Feld dient dazu, dem ‚IP_channel_table‘-Feld enthaltende Daten zu identifizieren. Die Typen von Daten entsprechend dem Wert dieses Feldes sind die folgenden: [Tabelle 7]
    Tag Beschreibung
    0 untersagt
    1 IP-Adressen-Tabelle
    2 MAC-Adressen-Tabelle
    3 Text-Beschreibungs-Tabelle
    4 - 255 reserviert
  • Ein ‚Length‘-Feld zeigt die Länge des ‚IP_channel_description‘-Feldes in Bytes an.
  • Ein ‚IP_channel_table()‘-Feld zeigt IP-Kanalinformationen an, so beispielsweise eine IP-Adresse und einen Port. Dieses Feld wird weiter unten ausführlich unter Bezugnahme auf 27 bis 29 beschrieben.
  • 27A stellt die Struktur eines ‚IP_address_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn das in 26 dargestellte ‚tag‘-Feld ‚1‘ ist.
  • Ein ‚IP_version‘-Feld zeigt die IP-Version, d.h. 4 oder 6, an, die vorliegende Erfindung ist jedoch nicht darauf beschränkt. Das heißt, es kann für eine andere Version reserviert sein.
  • IPv4-Adresse und IPv6-Adresse werden in RFC 791 und RFC 2460 ausführlicher beschrieben. Des Weiteren wird die Port-Nummer in RFC 793 für TCP und RFC 768 für UDP ausführlicher beschrieben.
  • 27B stellt die Struktur eines ‚IP_address_table‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 26 dargestellten ‚tag‘-Feldes ‚1‘ ist.
  • Das in 27B dargestellte ‚IP_address_table‘-Feld ist bis auf ein ‚port_number_usage_flag‘-Feld das gleiche wie das in 27A dargestellte.
  • Das ‚port_number_usage_flag‘-Feld zeigt an, ob eine Port-Nummer vorhanden ist. In der aktuellen Ausführungsform wird in einem ‚IP_address_table‘-Feld angezeigt, ob ein ‚port_number‘-Feld vorhanden ist.
  • 28 stellt die Struktur eines ‚MAC_address_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 26 dargestellten ‚tag‘-Feldes ‚2‘ ist.
  • Die Mac-Adresse wird in RFC 1042 ausführlich beschrieben.
  • 29 stellt die Struktur eines ‚Text_description_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 26 dargestellten ‚tag‘-Feldes ‚3‘ ist.
  • Ein ‚text_description_table‘-Feld stellt Textbeschreibung bezüglich eines IP-Channels bereit.
  • Ein ‚ISO_639_language_code‘-Feld zeigt an, dass die folgenden Textinformationen durch den ISO 639-3-Sprachcode identifiziert werden. In der aktuellen Ausführungsform enthält ein ‚description‘-Feld die Textinformationen.
  • Das ‚description‘-Feld stellt eine Textbeschreibung des IP-Channel bereit. Die Textbeschreibung ist in IOS 8859-1-Zeichen codiert.
  • Eine Multiplexing-Struktur des MCAST-Systems wird im Folgenden beschrieben.
  • Ein Transport-Rahmen enthält eine Vielzahl von Turbo-Kanälen und jeder der Turbo-Kanäle enthält eine Vielzahl von Teilkanälen. Des Weiteren kann jeder der Teilkanäle Teil-Datenkanäle enthalten. Der gleiche Typ Daten wird über die Teilkanäle übertragen. Die Teil-Datenkanäle können die Dienste selbst oder Dienst-Komponenten sein.
  • Über MCAST können verschiedene Typen von Daten multiplexiert und übertragen werden, oder es kann nur ein bestimmter Typ von Daten übertragen werden. Als Beispiele für den ersteren Fall können Signalisierungsdaten, Echtzeit-Medien-Daten, IP-Daten und Objekt-Daten multiplexiert und übertragen werden. Als Beispiele für den letzteren Fall können nur Signalisierungsdaten und IP-Daten übertragen werden. Im letzteren Fall können die Teil-Datenkanäle unter Bezugnahme auf den IP-Kompressionstyp kategorisiert werden.
  • Signalisierungsdaten werden über ein 168- oder 188 (oder 187)-Byte-MCAST-Transportpaket übertragen. Die Länge des Transportpaketes ist variabel. Eine LMT gibt die Positionen und die Nummern aller Teil-Datenkanäle an. Des Weiteren kann die LMT die Position von Daten angeben, die den Teil-Datenkanälen zugeordnet sind, oder die Positionen von IP-Streams in einem Turbo-Kanal.
  • Die folgende LMT kann in einem Transportpaket in einem Turbo-Datenkanal vorhanden sein oder periodisch oder nicht periodisch in einem Paket an einer Spezifizierungs-Position vorhanden sein. Die LMT kann beispielsweise in einem ersten Signalisierungs-Teil-Datenkanal oder einem MCAST-Paket-Header vorhanden sein. Des Weiteren kann die LMT in jedem der Rahmen vorhanden sein, wird jedoch möglicherweise nicht übertragen, wenn die Positionen von Dienst-Komponenten im Rahmen festgelegt sind.
  • Eine LIT enthält Dienstkonfigurationsinformationen und die Nummer sowie die Kennung jedes der Teil-Datenkanäle.
  • Ein herkömmliches Rundfunksystem sucht über PID-Filterung nach einem gewünschten Programm, während ein MCAST-System einem Benutzer einen gewünschten Dienst direkt bereitstellen kann, indem die genaue Position von Daten, die jeden Dienst bilden, Rahmen für Rahmen über eine LMT und/oder eine LIT ohne Durchführen von Filtern erfasst wird.
  • 30A stellt eine MCAST-Multiplexing-Struktur gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • 30A stellt im Einzelnen einen Fall dar, in dem Signalisierungs-Daten, Echtzeit-Daten, IP-Daten und Objekt-Daten multiplexiert werden. Ein Rahmen ist in einen Dienstzugriffsbereich zum Zugriff auf einen Dienst, beispielsweise eine LMT oder eine LIT, und einen Datenbereich zum Senden bzw. Übertragen von Daten unterteilt. Ein MCAST-Tranport-Rahmen gemäß einer Ausführungsform der vorliegenden Erfindung kann übertragen werden, während er in einen Transport-Rahmen eines anderen Rundfunksystems eingefügt ist, kann separat übertragen werden oder kann übertragen werden und dabei Eins-zu-Eins einem Transport-Rahmen eines anderen Rundfunksystems zugeordnet werden. In der aktuellen Ausführungsform wird ein MCAST-Transport-Rahmen über einen ATSC-Transport-Rahmen übertragen.
  • Der MCAST-Transport-Rahmen wird, wie oben beschrieben, entsprechend dem Datentyp in Teilkanäle unterteilt. Die Teilkanäle sind Kanäle, die physikalisch unterteilt werden, indem Turbo-Kanäle, die einen Daten-Stream übertragen, entsprechend dem Datentyp unterteilt werden. In 30A sind Teilkanäle in einen Teilkanal für einen Echtzeit-Datentyp, einen Teilkanal für einen IP-Datentyp und einen Teilkanal für einen Objekt-Datentyp unterteilt.
  • Die Teilkanäle können in unabhängige Teil-Datenkanäle unterteilt sein. Ein Teil-Datenkanal enthält mehr als ein Transportpaket. Ein Teil-Datenkanal besteht aus einer Gruppe von 188 Bytes (oder 168 Bytes)-MCAST-Transportpaketen innerhalb eines ATSC-Rahmens. Die Paketlänge kann variabel sein.
  • 30B stellt eine MCAST-Multiplexing-Struktur gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • 30B stellt im Einzelnen einen Fall dar, in dem nur Signalisierungs-Daten und IP-Daten multiplexiert werden. LMT-Informationen können übertragen werden und dabei in einem SIC oder einem IP-Datentyp-Teilkanal enthalten sein.
  • 31A stellt eine MCAST-Rahmenstruktur und eine LMT gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • 31A stellt ausführlicher den in 30A dargestellten Teilkanal dar. Wie unter Bezugnahme auf 31A zu sehen ist, besteht ein MCAST-Transport-Rahmen aus einem Signalisierungs-Teilkanal, einem Echtzeit-Medien-Teilkanal, einem IP-Teilkanal sowie einem Objekt-Teilkanal, d.h., wenigstens einer von drei Typen von Daten, beispielsweise Echtzeit-Medien-Daten, IP-Daten und Objekt-Daten, wird über den MCAST-Transport-Rahmen übertragen.
  • Jeder der Teilkanäle enthält einen Teil-Datenkanal.
  • Der Echtzeit-Medien-Teilkanal überträgt Echtzeit-Medien-Daten, wie beispielsweise einen A/V-Stream. In der aktuellen Ausführungsform besteht der Echtzeit-Medien-Teilkanal aus einem Teil-Datenkanal 1 (R-1) und einem Teil-Datenkanal 2 (R-2). Der IP-Teilkanal überträgt IP-Daten und enthält in der aktuellen Ausführungsform einen Teil-Datenkanal (IP-1). Der Objekt-Teilkanal überträgt Objektdaten, die in Echtzeit verwendet werden, oder verwendet werden, nachdem sie empfangen und in einer Rundfunkdienst-Empfangsvorrichtung gespeichert worden sind. In der aktuellen Ausführungsform enthält der Objekt-Teilkanal einen Teil-Datenkanal 1 (O-1), einen Teil-Datenkanal 2 (O-2), einen Teil-Datenkanal 3 (O-3) und einen Teil-Datenkanal (O-4).
  • Ein Dienst besteht aus mehr als einer Dienstkomponente. Daher müssen alle Dienstkomponenten eines Dienstes empfangen werden, um den Dienst bereitzustellen. Ein Teil-Datenkanal ist ein Weg, über den nur eine Dienstkomponente übertragen wird. Daher müssen, um auf einen Dienst zuzugreifen, die Positionen aller Teil-Datenkanäle, die jeweils Dienstkomponenten übertragen, bekannt sein.
  • Dienstzugangsinformationen, wie beispielsweise ein LMT oder eine LIT zum Zugreifen auf Dienstkomponenten, die einen Dienst bilden, sind in einem Header-Teil eines Transportpaketes enthalten. Das Transportpaket kann wenigstens ein ‚Header‘-Feld, ein ‚LMT‘-Feld, ein ‚LIT‘-Feld und Nutzdaten enthalten.
  • Ein LMT-Feld stellt die Struktur des Teil-Datenkanals sowie physikalische Positionsinformationen bereit, wie dies weiter unter ausführlich unter Bezugnahme auf 34 beschrieben ist.
  • 31B stellt eine MCAST-Rahmenstruktur und eine LMT gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Wie unter Bezugnahme auf 31B zu sehen ist, werden über einen MCAST-Frame nur IP-Daten übertragen, und VMI-Daten sind enthalten, um einen Teil-Datenkanal zu identifizieren.
  • Es ist sehr wichtig, dass die Position eines Teil-Datenkanals in einem MCAST-Rahmen erfasst wird, und diese Informationen sind, wie oben beschrieben, in einer LMT enthalten. Die Position des Teil-Datenkanals wird unter Verwendung eines Offset in dem Rahmen erfasst. Wenn jedoch eine Veränderung in dem Teil-Datenkanal auftritt, d.h., wenn ein Teil-Datenkanal hinzugefügt oder gelöscht wird, ist es erforderlich, diese Veränderung zu erkennen. Wenn Teil-Datenkanäle durch Virtual-Map-Identifizierung (Virtual Map Identification - VMI) identifiziert werden können, ist es möglich, auf einfache Weise, eine Veränderung der Teil-Datenkanäle zu prüfen. Die VMI wird ausführlich unter Bezugnahme auf 32 beschrieben.
  • 32 stellt ein Verfahren zum Prüfen einer Veränderung eines Teil-Datenkanals unter Verwendung von Virtual-Map-Identifizierung (VMI) gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Die VMI gemäß einer Ausführungsform der vorliegenden Erfindung ist in Signalisierungsinformationen, wie beispielsweise einer LMT, einer LIT oder einer IMT, enthalten. Die VMI ist eine Kennung, die Teil-Datenkanäle identifiziert. Unter Verwendung der VMI ist es möglich, festzustellen, ob ein Teil-Datenkanal verändert ist.
  • Wie unter Bezugnahme auf 32 zu sehen ist, sind in einem vorangehenden Rahmen Teil-Datenkanäle, die einen Dienst 1 bilden, Audio 1, Video 1 und ein Bild 1. Diesen Teil-Datenkanälen werden Werte 1, 3 bzw. 5 als VMI-Werte zugeordnet.
  • In einem folgenden Rahmen wird der Teil-Datenkanal, der dem Bild 1 entspricht, gelöscht. Wenn die Position eines Teil-Datenkanals nur mit einem Offset in einem Rahmen angezeigt wird, ist es nicht sinnvoll, einen Offset als eine Kennung zu verwenden, da sich Offsets von Teil-Datenkanälen von Rahmen zu Rahmen unterscheiden. Wenn jedoch den Teil-Datenkanälen VMI jeweils als eindeutige Kennungen zugeordnet werden, kann ein Teil-Datenkanal, in dem eine Veränderung stattfindet, genau erkannt werden.
  • 33 ist ein Flussdiagramm, das ein Verfahren zum Beziehen eines Dienstes unter Verwendung von VMI gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S3310 wird eine LMT und/oder ein LIT bezogen.
  • In Vorgang S3320 wird die VMI eines Teil-Datenkanals, der eine Dienstkomponente überträgt, die einen angeforderten Dienst bildet, geprüft.
  • In Vorgang S3330 wird ein IMT bezogen.
  • In Vorgang S3340 wird eine VMI in einem aktuellen Turbo-Kanal geprüft.
  • In Vorgang S3350 werden Daten gewonnen, indem auf einen gewünschten Teil-Datenkanal zugegriffen wird.
  • 34A stellt die Struktur einer LMT gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Eine LMT gemäß einer Ausführungsform der vorliegenden Erfindung enthält ein ‚type bitmap‘-Feld, ein ‚version number‘-Feld und wenigstens ein ‚sub data channel number‘-Feld.
  • Das ‚type bitmap‘-Feld zeigt den Typ von Daten an, die in einem MCAST-Transportrahmen enthalten sind, der in vorgegebenen Zeitintervallen übertragen wird. Es wird davon ausgegangen, dass Objekt-Daten, Echtzeit-Medien-Daten und IP-Daten über den MCAST-Transport-Rahmen übertragen werden.
  • Das ‚type bitmap‘-Feld besteht aus drei Bits, von denen jedes anzeigen kann, ob ein Typ Daten vorhanden ist. Beispielsweise wird angenommen, dass ein erstes Bit anzeigt, ob Echtzeit-Medien-Daten in dem Rahmen vorhanden sind, ein zweites Bit anzeigt, ob IP-Daten in dem Rahmen vorhanden sind, ein drittes Bit anzeigt, ob Objekt-Daten in dem Rahmen vorhanden sind, und wenn Daten vorhanden sind entspricht dies einem Fall, in dem der Bit-Wert ‚1‘ ist. Wenn der Wert des ‚type bitmap‘-Feldes ‚111‘ ist, bedeutet dies also, dass alle Typen von Daten vorhanden sind, und wenn der Wert des ‚type bitmap‘-Feldes ‚01 1‘ ist, bedeutet dies, dass IP-Daten und Objekt-Daten vorhanden sind.
  • Das ‚version number‘-Feld zeigt die Version der LMT an.
  • Das ‚sub data channel number‘-Feld zeigt die Gesamtzahl von Teil-Datenkanälen für jeden Typ Daten an. Der Wert dieser Felder entspricht der Anzahl von ‚channel pointer‘-Feldern, die die physikalische Adresse eines Teil-Datenkanals anzeigen.
  • Wie unter Bezugnahme auf 34A zu sehen ist, sind, da die I-‚channel pointer‘-Felder vorhanden sind, die Echtzeit-Medien-Daten entsprechen, I-Teil-Datenkanäle vorhanden, die Echtzeit-Medien-Daten übertragen.
  • Jedes der ‚channel pointer‘-Felder zeigt die physikalische Position eines Teil-Datenkanals an. Index-Nummern können den ‚channel pointer‘-Feldern sequenziell zugeordnet werden. Die den ‚channel pointer‘-Feldern in der LMT sequenziell zugeordneten Nummern werden als ‚LMT-Index-Nummern‘ bezeichnet. Die LMT-Index-Nummern sind möglicherweise nicht in den ‚channel pointer‘-Feldern enthalten, sondern können den ‚channel pointer‘-Feldern sequenziell zugeordnet werden, wenn eine Rundfunk-Empfangsvorrichtung ein ‚LMT‘-Feld interpretiert. Die LMT-Index-Nummern werden zugewiesen, um auf die Kanal-Zeiger (channel pointer) von Teilkanälen, die jeweilige Dienste bilden, in der LIT Bezug zu nehmen.
  • 34B stellt im Detail die Struktur der LMT gemäß 34A dar.
  • Wenn angenommen wird, dass der Wert des ‚type bitmap‘-Feldes ‚011‘ ist, der Wert des ‚sub data channel numer‘-Feldes für IP-Daten ‚2‘ ist und der Wert des ‚sub data channel number‘-Feldes ‚3‘ ist, zeigen die ‚channel pointer‘-Felder 1 und 2 die Positionen von Teil-Datenkanäle für IP-Daten an, und die ‚channel pointer‘-Felder 3 bis 5 zeigen die Positionen von Teil-Datenkanälen für IP-Daten an. Wenn LMT-Index-Nummern diesen ‚channel pointer‘-Feldern sequenziell zugeordnet werden, werden LMT-Index-Nummern von 1 bis 5 jeweils den ‚channel pointer‘-Feldern 1 bis 5 zugeordnet.
  • 35A und 35B stellen die Strukturen einer LMT gemäß Ausführungsformen der vorliegenden Erfindung dar.
  • Ein ‚tag‘-Feld zeigt an, ob LMT-Informationen integriert werden. In der vorliegenden Ausführungsform sind LMT-Informationen in einem ‚LMT_information‘-Feld enthalten.
  • Ein ‚length‘-Feld besteht aus acht Bits und zeigt die Länge eines ‚LMT_information‘-Feldes an.
  • Das ‚LMT_information‘-Feld gibt die Positionen von Teil-Datenkanälen in einem Teilkanal und Signalisierungs-Daten (SD) in einem Signalisierungs-Teilkanal an. Das ‚LMT_information‘-Feld wird unter Bezugnahme auf 36C beschrieben.
  • 36 stellt die Struktur des in 35 dargestellten ‚LMT_information‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚LMT_coverage‘-Feld zeigt die Anzahl folgender LMT an, die identisch mit einer aktuellen LMT sind. Wenn beispielsweise der Wert eines ‚version_number‘-Feldes, das weiter unter beschrieben wird, ‚1‘ ist und der Wert des ‚LMT_coverage‘-Feldes ‚001‘ ist, bedeutet dies, dass eine LMT vorhanden ist, deren Version ‚1‘ ist. Desgleichen wird, wenn eine folgenden LMT mit der aktuellen LMT nicht identisch ist, der Wert dieses Feldes auf ‚0‘ eingestellt.
  • Ein ‚version_number‘-Feld besteht aus vier Bits und zeigt die Version der LMT an. Die Versionsnummer sollte immer dann, wenn sich das LMT-bezogene Feld ändert, um 1 modulo 16 inkrementiert werden.
  • Ein ‚LMT_boundary‘-Feld zeigt die Positionen von Paketen an, die von einer aktuellen LMT abgedeckt werden. Der Wert des ‚LMT_boundary‘-Feldes ist nicht beschränkt, wenn er die durch die aktuelle LMT abgedeckten Pakete darstellen kann. Beispielsweise kann der Wert dieses Feldes die Offsets oder die Gesamtzahl der durch eine aktuelle LMT abgedeckten Pakete anzeigen.
  • Ein ‚SD_end_offset‘-Feld ist ein 8-Bit-Feld, das die Endposition eines Signalisierungs-Teilkanals anzeigt. Wenn keine Signalisierungsdaten in dem Signalisierungs-Teilkanal enthalten sind, sollte der Wert dieses Feldes auf ‚0‘ eingestellt sein.
  • Ein ‚number_iP‘-Feld zeigt die Anzahl von IP-Teil-Datenkanälen an.
  • Ein ‚IP_end_offset‘-Feld ist ein 8-Bit-Feld, das die Endpositionen von IP-Teil-Datenkanälen innerhalb eines IP-Teilkanals anzeigt. Wenn keine IP-Daten in einem ersten IP-Teil-Datenkanal enthalten sind, sollte der Wert dieses Feldes auf ‚0‘ eingestellt sein.
  • 37A und 37B stellen die Struktur einer LMT und eines ‚LMT_information‘-Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Die LMT zeigt, wie unter Bezugnahme auf 37A zu sehen ist, die Abschluss-Offset-Informationen von Teil-Datenkanälen an. Teil-Datenkanäle übertragen jeweils vier Typen von Daten, d.h. Signalisierungs-Daten, Echtzeit-Medien-Daten, IP-Daten und Objekt-Daten, und die Positionen der Teil-Datenkanäle entsprechend dem Typ werden mit Abschluss-Offsets (ending offsets) ausgedrückt.
  • Ein Anfangswert jedes Teil-Datenkanals ist stets ‚1‘, und Nummern werden den Teil-Datenkanälen individuell entsprechend dem Teil-Datentyp zugeordnet. Wenn es jedoch keinen ersten Teil-Datenkanal gibt, ist der Wert eines ‚next_indicator()‘-Feldes auf ‚0‘ festzulegen.
  • Wenn ein gültiges Datenpaket temporär in einer oder mehreren Paketgruppen nicht vorhanden ist, ist der Offset eines entsprechenden Teil-Datenkanals gleich dem eines vorhergehenden Paketes. Der Offset des ersten Teil-Datenkanals wird auf ‚0‘ eingestellt.
  • Jedes der Felder wird unter Bezugnahme auf 37B definiert.
  • Ein ‚SEP_flag‘-Feld zeigt an, ob ein Signal-Kapselungspaket (Signal Encapsulation Packet - SEP) vorhanden ist.
  • Ein ‚SEP_end_offset‘-Feld ist ein 8-Bit-Feld, das die Endposition eines SEP-Teil-Datenkanals anzeigt, wenn der Wert des ‚SEP_flag‘-Feldes ‚1‘ ist.
  • Ein erstes ‚next_indicator‘-Feld zeigt an, ob darüber hinaus ein ‚real_time_end_offset‘-Feld vorhanden ist. Wenn der Wert dieses Feldes ‚0‘ ist, gibt es keine ‚real_time_end_offset‘-Feld mehr, und wenn der Wert dieses Feldes ‚1‘ ist, bedeutet dies, dass ein ‚real_time_end_offset‘-Feld weiter vorhanden ist.
  • Das ‚real_time_end_offset‘-Feld ist ein 7-Bit-Feld, das die Endposition des Echtzeit-Teil-Datenkanals anzeigt, der Echtzeit-Medien-Daten überträgt. Wenn eine aktuelle MCAST-Paketgruppe keine Echtzeit-Daten aufweist, wird der Wert dieses Feldes auf ‚0‘ eingestellt, oder möglicherweise existiert dieses Feld nicht.
  • Ein zweites ‚next_indicator‘-Feld zeigt an, ob darüber hinaus ein weiteres ‚IP_end_offset‘-Feld vorhanden ist. Wenn der Wert dieses Feldes ‚0‘ ist, ist ein aktuelles ‚IP_end_offset‘-Feld ein letztes Feld, und wenn der Wert dieses Feldes ‚1‘ ist, ist ein weiteres ‚IP_end_offset‘-Feld vorhanden.
  • Ein ‚IP_end_offset‘-Feld ist ein 7-Bit-Feld, das die Endposition eines IP-Teil-Datenkanals anzeigt, der IP-Daten überträgt. Wenn kein IP-Teil-Datenkanal in dem aktuellen MCAST-Paket vorhanden ist, wird der Wert dieses Feldes auf ‚0‘ festgelegt, oder dieses Feld ist möglicherweise nicht vorhanden.
  • Ein drittes ‚next_indicator‘-Feld zeigt an, ob darüber hinaus ein weiteres ‚object_end_offset‘-Feld vorhanden ist. Wenn der Wert dieses Feldes ‚0‘ ist, ist ein aktuelles ‚object_end_offset‘-Feld ein letztes Feld, und wenn der Wert dieses Feldes ‚1‘ ist, folgt ein ‚object_end_offset‘-Feld.
  • Ein ‚object_end_offset‘-Feld ist ein 7-Bit-Feld, das die Endposition eines Objekt-Teil-Datenkanals anzeigt, der Objekt-Daten überträgt. Wenn kein Objekt-Teil-Datenkanal in der aktuellen MCAST-Paketgruppe vorhanden ist, wird der Wert dieses Feldes auf ‚0‘ eingestellt, oder möglicherweise existiert dieses Feld nicht.
  • 38 stellt die Struktur einer LMT gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚LMT_coverage‘-Feld zeigt die Anzahl folgender LMT an, die mit der aktuellen LMT identisch sind. Wenn eine nachfolgende LMT nicht mit der aktuellen LMT identisch ist, ist der Wert dieses Feldes auf ‚0‘ einzustellen.
  • Ein ‚version_number‘-Feld ist ein 2-Bit-Feld, das die Version der LMT anzeigt. Die Versionsnummer sollte immer dann, wenn sich eines der LMT bezogenen Felder ändert, um 1 modulo 4 inkrementiert werden.
  • Ein ‚selector_bits (SEP, umgekehrt, IP)‘-Feld zeigt den Typ eines vorhanden Teil-Datenkanals an. In 38 ist, da angenommen wird, dass nur IP-Daten über einen MCAST-Rahmen übertragen werden, ein zweites Bit ein reserviertes Bit. Wenn ein erstes Bit ‚1‘ ist, bedeutet dies, dass ein SEP-Teil-Datenkanal vorhanden ist, und wenn ein drittes Bit ‚1‘ ist, bedeutet dies, dass ein IP-Teil-Datenkanal vorhanden ist.
  • Ein ‚LMT_length‘-Feld zeigt die Länge eines LMT-Feldes an.
  • Ein ‚LMT_boundary‘-Feld zeigt die Anzahl von Offsets von Paketen an, die durch eine aktuelle LMT abgedeckt werden.
  • Ein ‚number of SEP‘-Feld ist ein 8-Bit-Feld, das die Gesamtzahl von SEP-Teil-Datenkanälen anzeigt.
  • Ein ‚VMI‘-Feld zeigt die Kennung von Teil-Datenkanälen an, die in einem Turbo-Kanal eindeutig zugeordnet sind.
  • Ein ‚SEP_end_offset‘-Feld ist ein 8-Bit-Feld, das die Endposition eines SEP-Teilkanals anzeigt.
  • Ein ‚num_of_IP‘-Feld zeigt die Anzahl von IP-Teil-Datenkanälen an.
  • Ein ‚IP_end_offset‘-Feld ist ein 8-Bit-Feld, das die Endposition eines IP-Teil-Datenkanals anzeigt. Sowohl das ‚Sep_end_offset‘-Feld als auch das ‚IP_end_offset‘-Feld werden berechnet, indem Pakete auf Basis eines Paketes gezählt werden, das die LMT enthält. In einer anderen Ausführungsform der vorliegenden Erfindung kann ein Offset in Bytes berechnet werden.
  • 39 stellt die Strukturen eines MCAST-Rahmens und einer LIT gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Eine LIT kann sich auf einem Signalisierungs-Teilkanal befinden, der an erster Position in einem Turbo-Kanal, der Daten enthält, innerhalb eines ATSC-Rahmens steht. Jeder Dienst besteht aus einer oder mehr Dienstkomponenten, und die LIT zeigt eine Liste der Dienstkomponenten an. Das heißt, die LIT sollte Informationen über die Dienstzusammensetzung angeben. Die Position eines Teil-Datenkanals wird aus der oben beschriebenen LMT erfasst.
  • Die LIT ist nahe mit der LMT verwandt und kann in jedem der Rahmen vorhanden sein.
  • 40 stellt die Struktur einer LIT gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚service_number‘-Feld zeigt die Anzahl von Diensten an, die in einem MCAST-Rahmen gemäß der vorliegenden Erfindung enthalten sind.
  • Ein ‚version_number‘-Feld zeigt die Version der LIT an.
  • Jedes der Dienst-Felder besteht aus einem ‚service identifier‘-Feld und wenigstens einem ‚LMT index number‘-Feld. Die ‚LMT-Index-Nummer‘ wird einem ‚channel pointer‘-Feld zugeordnet, wie dies oben in 34B beschrieben ist Damit ist eine Rundfunk-Empfangsvorrichtung in der Lage, die physikalische Adresse eines Teil-Datenkanals für einen gewünschten Dienst in einem Transport-Rahmen durch Interpretieren der LIT zu erfassen.
  • 41A und 41B stellen die Struktur einer LIT gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Wenn eine Vielzahl von Teil-Datenkanälen einen Dienst bilden, gibt die LIT die Struktur des Dienstes an. Die Positionen der Teil-Datenkanäle können anhand der Offset-Informationen der Teil-Datenkanäle bestimmt werden, die in der LMT enthalten sind. Das heißt, jede Komponente kann über einen akkumulierenden Zähler jedes der Teil-Datenkanäle identifiziert werden.
  • Ein ‚num_of_service‘-Feld ist ein 6-Bit-Feld, das die Anzahl verfügbarer Dienste in einem aktuellen Rahmen anzeigt.
  • Ein ‚version_number‘-Feld ist ein 10-Bit-Feld, das die Versionsnummer von LIT-bezogenen Feldern anzeigt. Die Versionsnummer sollte immer dann, wenn sich eines der LIT-bezogenen Felder ändert, um 1 inkrementiert werden.
  • Ein ‚service_ID‘-Feld ist ein 8-Bit-Feld, das einen Dienst in einem Turbo-Kanal identifiziert.
  • Ein ‚next_indicator‘-Feld ist ein 1-Bit-Feld, das anzeigt ob, welche zusätzlichen ‚next_indicator‘-Felder und ‚LMT_index_number‘-Felder vorhanden sind. Wenn der Wert dieses Feldes ‚1‘ ist, bedeutet dies, dass die zusätzlichen ‚next_indicator‘-Felder und ‚LMT_index_number‘-Felder vorhanden sind, und wenn der Wert dieses Feldes ‚0‘ ist, existieren das ‚next_indicator‘-Feld und das ‚LMT_index_number‘-Feld nicht mehr.
  • Ein ‚type_info‘-Feld zeigt den Typ eines Teil-Datenkanals an, der durch das ‚LMT_index_number‘-Feld angezeigt wird, und der entsprechend dem Wert dieses Feldes wie folgt definiert ist: [Tabelle 8]
    Wert Beschreibung
    00 reserviert
    01 Echtzeit-Daten
    10 IP-Daten
    11 Objekt-Daten
  • Ein ‚LMT_index_numer‘-Feld ist ein 7-Bit-Feld, das einen Array-Index jeder LMT anzeigt. Der Wert dieses Feldes wird entsprechend dem ‚type_info‘-Feld individuell erhöht. Das heißt, wie unter Bezugnahme auf 40 zu sehen ist, die LMT-Index-Nummer wird unabhängig von dem Typ des Teil-Datenkanals sequenziell erhöht. Jedoch wird, wie unter Bezugnahme auf 41 zu sehen ist, die LMT-Index-Nummer entsprechend dem Typ des Teil-Datenkanals individuell erhöht.
  • Beispielsweise wird davon ausgegangen, dass zwei Kanal-Zeiger, die einem IP-Teil-Datenkanal entsprechen, und drei Kanal-Zeiger, die einem Objekt-Teil-Datenkanal entsprechen, in einem MCAST-Rahmen vorhanden sind. In diesem Fall werden, wie unter Bezugnahme auf 40 zu sehen ist, LMT-Index-Nummern von 1 bis 5 den Kanal-Zeigern sequenziell zugeordnet, und so werden LMT-Index-Nummern von 3 bis 5 jeweils den Kanal-Zeigern zugeordnet, die dem Objekt-Teil-Datenkanal entsprechen. Die LMT-Index-Nummern werden jedoch, wie unter Bezugnahme auf 41 zu sehen ist, individuell entsprechend dem Typ des Teil-Datenkanals erhöht, und so werden LMT-Index-Nummern von 1 bis 3 jeweils den Kanal-Zeigern zugeordnet, die dem Objekt-Teil-Datenkanal entsprechen.
  • 42A ist ein Flussdiagramm, das ein Verfahren zum Bereitstellen eines Dienstes unter Verwendung einer LMT und einer LIT gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • Ein LMT-Feld wird, wie unter Bezugnahme auf 42A zu sehen ist, in regelmäßigen Intervallen übertragen und in einem vorgegebenen Bereich eines MCAST-Rahmens positioniert. In Vorgang S4201 erfasst und interpretiert eine Rundfunkdienst-Empfangsvorrichtung, wenn sie einen Transport-Rahmen empfängt, ein Signalisierungs-Paket, das Dienstzugriffsinformationen enthält und sich in einem vorgegebenen Bereich des Transport-Rahmens befindet.
  • In Vorgang S4203 stellt die Rundfunkdienst-Empfangsvorrichtung fest, ob in dem Signalisierungs-Paket ein LMT-Feld vorhanden ist. Wenn in Vorgang S4203 festgestellt wird, dass keine LMT-Felder in dem Signalisierungs-Paket vorhanden ist, wird in Vorgang S4205 festgestellt, ob ein vorangegangenes LMT-Feld in der Rundfunkdienst-Empfangsvorrichtung gespeichert worden ist. Wenn in Vorgang S4205 festgestellt wird, dass ein vorangegangenes LMT-Feld in der Rundfunkdienst-Empfangsvorrichtung vorhanden ist, geht das Verfahren zu Vorgang S4211 über.
  • Wenn in Vorgang S4203 festgestellt wird, dass ein LMT-Feld in dem Signalisierungs-Paket vorhanden ist, stellt die Rundfunkdienst-Empfangsvorrichtung in Vorgang S4207 unter Verwendung von Versionsinformationen, die in dem LMT-Feld enthalten sind, fest, ob die Version des LMT-Feldes aktualisiert worden ist. Wenn in Vorgang S4207 festgestellt wird, dass die Version des LMT-Feldes aktualisiert worden ist, wird das LMT-Feld in Vorgang S4209 interpretiert. Indem das LMT-Feld in Vorgang S4209 interpretiert wird, werden Informationen über die Positionen von Teil-Datenkanälen gewonnen.
  • In Vorgang S4211 stellt die Rundfunkdienst-Empfangsvorrichtung fest, ob ein LIT-Feld in dem Signalisierungspaket vorhanden ist. Wenn in Vorgang S4211 festgestellt wird, dass kein LIT-Feld vorhanden ist, wird in Vorgang S4213 festgestellt, ob ein vorangegangenes LIT-Feld in der Rundfunkdienst-Empfangsvorrichtung vorhanden ist. Wenn in Vorgang S4213 festgestellt wird, dass ein vorangegangenes LIT-Feld vorhanden ist, geht das Verfahren zu Vorgang S4219 über.
  • Wenn in Vorgang S4211 festgestellt wird, dass ein LIT-Feld in dem Signalisierungs-Paket vorhanden ist, wird in Vorgang S4215 die Version des LIT-Feldes festgestellt. Indem das LIT-Feld in Vorgang S4217 interpretiert wird, werden Verbindungsinformationen über jeden der Dienste, d.h., Dienstkonfigurationsinformationen, gewonnen.
  • In Vorgang S4219 werden die Dienste anhand der Ergebnisse der Interpretationen des LMT-Feldes und des LIT-Feldes bezogen und dann verarbeitet.
  • 42B ist ein Flussdiagramm, das ein Verfahren zum Bereitstellen eines Dienstes unter Verwendung einer LMT und einer LIT gemäß einer anderen Ausführungsform der vorliegenden Erfindung darstellt.
  • Eine LMT beinhaltet, wie unter Bezugnahme auf 42B zu sehen ist ein ‚LMT_coverage‘-Feld, und so kann die Position einer nachfolgenden LMT selbst dann erfasst werden, wenn ein Paket, das die LMT enthält, aufgrund eines Fehlers nicht empfangen werden kann oder LMT nicht periodisch eingefügt werden. Dementsprechend variieren die Position des LMT und ein Zyklus, in dem das LMT-Feld in ein Transportfeld eingefügt wird. In 42B mit den gleichen Bezugszahlen wie denen in 42A gekennzeichnete Vorgänge sind die gleichen wie diejenigen in 42A, und daher wird eine ausführliche Beschreibung derselben weggelassen.
  • In Vorgang S4220 wird, wie unter Bezugnahme auf 42B zu sehen ist, eine LMT aus einem MCAST-Rahmen entsprechend LMT-Zeiger-Informationen extrahiert, die aus einer vorhergehenden LMT extrahiert wurden. Die LMT-Zeiger-Informationen zeigen auf die Position einer nachfolgenden LMT. Dementsprechend kann, selbst wenn die LMT nicht in einen vorgegebenen Bereich des Transport-Rahmens eingefügt wird, die LMT einfach aus dem Transport-Rahmen extrahiert werden.
  • In Vorgang S4203 wird festgestellt, ob ein LMT-Feld an der durch die LMT-Zeiger-Informationen angezeigten Position vorhanden ist. Wenn in Vorgang S4203 festgestellt wird, dass ein LMT-Feld vorhanden ist, geht das Verfahren zu Vorgang S4207 über. Wenn im Vorgang S4203 festgestellt wird, dass kein LMT-Feld vorhanden ist, geht das Verfahren zu Vorgang S4230 über. Wenn kein LMT-Feld an der durch die LMT-Zeiger-Informationen angezeigten Position vorhanden ist, deutet dies auf einen Fall hin, in dem das LMT-Feld weggelassen wird, und einen Fall, in dem ein Fehler in dem LMT-Feld erzeugt wird.
  • In Vorgang S4230 wird auf Basis von Informationen bezüglich der Gesamtzahl von LMT, deren Version die gleiche ist, und die in dem vorangegangenen LMT-Feld enthalten sind, festgestellt, ob das vorangegangene LMT-Feld gültig ist. Die Tatsache, dass das vorangegangene LMT-Feld gültig ist, bedeutet, dass es weiter verwendet werden kann. Wenn in Vorgang S730 festgestellt wird, dass das vorangegangene LMT-Feld gültig ist, geht das Verfahren zu Vorgang S4211 über.
  • Die Struktur von Transport-Informationen entsprechend einem Datentyp wird im Folgenden beschrieben.
  • Zunächst müssen im Fall eines Echtzeit-Rich-Dienstes PSI von MPEG-2 und ATSC bezogen und decodiert werden, um Multimedia-Elementar-Streams in einem Broadcasting-System zu decodieren. Dann muss ein Decoder auf den Empfang eines Rahmens warten, der zuerst zu decodieren ist. Anschließend kann ein Benutzer Video betrachten. In MCAST werden wichtige Decodierinformationen zu einem Informations-Descriptor decodiert, der in jedem der Multimedia-Elementar-Streams enthalten ist.
  • In diesem Fall können Decoder-Konfigurationsinformationen (DCI) und Multimedia-Daten simultan für schnellen Zugang übertragen werden, wie dies oben beschrieben ist. Das heißt, die DCI werden in einen I-Rahmen eingefügt und dann übertragen. Die DCI sind oben unter Bezugnahme auf 4 beschrieben worden.
  • 43 stellt die Struktur von Objekt-Übertragungsinformationen gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚Object_Delivery_information‘-Feld enthält, wie unter Bezugnahme auf 43 zu sehen ist, Signalisierungsinformationen zum Übertragen eines Objektes. Das ‚Object_Delivery_information‘-Feld enthält das Ablaufdatum des Objektes, Parameter für AL-FEC und einen zusätzlichen Descriptor. Verzeichnis-Komponenten sind Objekte oder andere Verzeichnisse.
  • Ein ‚object_Delivery_information‘-Feld kann über ein Signalisieruns-Kapselungspaket (SEP) übertragen werden.
  • Ein ‚directory_information_flag‘-Feld zeigt an, ob ein Verzeichnis vorhanden ist.
  • Objekt-Informationen können in einem Baum mit einem Verzeichnis ausgedrückt werden. Wenn der Wert des ‚Directory_information_flag‘-Feldes ‚1‘ ist, kann daraus geschlossen werden, dass ein Verzeichnis vorhanden ist.
  • Ein ‚number_of_objects‘-Feld zeigt die Gesamtzahl von Objekten an, die über das ‚object_delivery_information‘-Feld übertragen werden.
  • Ein ‚number_of_directory‘-Feld zeigt die Gesamtzahl von Verzeichnis-Informatioinen an. In der aktuellen Ausführungsform enthält ein ‚directory_information‘-Feld Verzeichnis-Informationen.
  • Das ‚directory_information‘-Feld beinhaltet Verzeichnis-Informationen, die weiter unter ausführlicher unter Bezugnahme auf 44 beschrieben werden.
  • Ein ‚object_id‘-Feld zeigt die Kennung des Objektes an.
  • Ein ‚expire_time_flag‘-Feld zeigt an, ob das Objekt eine Ablaufzeit hat.
  • Ein ‚LMT_index_number‘-Feld zeigt die Index-Nummern von Teil-Datenkanälen an, die entsprechend dem Datentyp kategorisiert sind.
  • Ein ‚object_extension_id‘-Feld wird als eine zusätzliche Kennung einer Vielzahl von Objekten verwendet, wenn die Objekte in dem gleichen Teil-Datenkanal übertragen werden.
  • Ein ‚AL-FEC_mode‘-Feld zeigt einen AL-FEC-Modus an. Beispiele für den AL-FEC-Modus entsprechend dem Wert dieses Feldes sind die folgenden: [Tabelle 9]
    Wert Modus
    0 MCAST_AL_FEC
    1 - 15 reserviert
  • Ein ‚total_length‘-Feld zeigt die Länge des Objektes in Bytes an.
  • Ein ‚time_table‘-Feld beinhaltet Zeitinformationen, die verhindern, dass Objekte nach ihren Ablaufzeiten verwendet werden. Dieses Feld wird weiter unten ausführlich unter Bezugnahme auf 45 beschrieben.
  • Ein ‚encoding_mode‘-Feld zeigt einen Codier-Modus an, der von AL-FEC verwendet wird. Beispiele für den Codier-Modus entsprechend dem Wert dieses Feldes sind die folgenden: [Tabelle 10]
    Wert Beschreibung (n, k)
    0 (2880, 2304)
    1 (1920,1536)
    2 (960, 768)
    3-15 reserviert
  • Ein ‚padding_length‘-Feld zeigt eine Padding- bzw. Auffülllänge in einem letzten Quellenblock des Objektes an.
  • Ein ‚number_of_descriptors‘-Feld zeigt die Anzahl nachfolgender ‚descriptor‘-Felder an.
  • Ein ‚tag‘-Feld zeigt Datentypen von Objekten an. In der aktuellen Ausführungsform zeigt dieses Feld den Typ von Daten an, die in dem ‚descriptor‘-Feld enthalten sind. Beispiele für Datentypen entsprechend dem Wert dieses Feldes sind die folgenden: [Tabelle 11]
    Wert Beschreibung
    0 untersagt
    1 content_name_description
    2 mime_type_description
    3-15 reserviert
  • Ein ‚length‘-Feld zeigt die Längen von ‚descriptor‘-Feldern in Bytes an.
  • Ein ‚descriptor‘-Feld zeigt Descriptoren entsprechend dem Wert des ‚tag‘-Feldes an.
  • Das ‚descriptor‘-Feld entsprechend dem Wert des ‚tag‘-Feldes wird weiter unten ausführlich unter Bezugnahme auf 46 und 47 beschrieben.
  • 44 stellt die Struktur des in 43 dargestellten ‚directory_information‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚number_of directory‘-Feld zeigt die Anzahl von Verzeichnissen an.
  • Ein ‚directory_id‘-Feld zeigt die Kennung des Verzeichnisses an.
  • Ein ‚directory_name-length‘-Feld zeigt die Länge des Namens des Verzeichnisses in Bytes an.
  • Ein ‚directory_name‘-Feld zeigt den Namen des Verzeichnisses in Zeichen nach ISO 8859-1 codiert an.
  • Ein ‚number_of_components‘-Feld zeigt die Anzahl von Komponenten an, die in jedem der Verzeichnisse enthalten sind.
  • Ein ‚object_id, directory_id‘-Feld zeigt die Kennungen von Objekten oder anderen Verzeichnissen an.
  • 45 stellt die Struktur eines in 43 dargestellten ‚time_table‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚years‘-Feld zeigt ein Jahr an. Es ist möglich, auszudrücken, wie viel Zeit seit einem bestimmten Zeitpunkt vergangen ist. Wenn beispielsweise das Jahr 1970 ein Bezugsjahr ist und der Wert dieses Feldes ‚0‘ ist, bedeutet dies das Jahr 1970.
  • Ein ‚months‘-Feld zeigt einen Monat von Januar bis Dezember an.
  • Ein ‚days‘-Feld zeigt ein Datum an.
  • Ein ‚hours‘-Feld zeigt eine Stunde von ein bis vierundzwanzig Uhr an.
  • Ein ‚minutes‘-Feld zeigt eine Minute von einer bis sechzig Minuten an.
  • 46 stellt die Struktur eines ‚content_name_descriptor‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 43 dargestellten ‚tag‘-Feldes ‚1‘ ist.
  • Ein ‚content_name_length‘-Feld zeigt die Länge eines Inhaltsnamens in Bytes an.
  • Ein ‚content_name‘-Feld zeigt den Namen von Inhalt codiert in Zeichen nach ISP 8859-1 an.
  • 47 stellt die Struktur eines ‚mime_type_description‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 43 dargestellten ‚tag‘-Feldes ‚2‘ ist.
  • Ein ‚mime_type_length‘-Feld zeigt die Länge des Mime-Type in Bytes an („mime“ steht für „Multipurpose Internet Mail Extensions“).
  • Ein ‚mime_type‘-Feld zeigt einen Mime-Type an. Dieses Feld ist auf die Strings eingestellt, die jeden beliebigen Medientyp codieren, der bei IANA registriert ist. Ausführliche Informationen finden sich in RFC 2045, RFC 2046 sowie unter httn://www.iana.org/assignments/media-typs.
  • 48 stellt die Beziehung zwischen einem Kapselungspaket und einem Transportpaket in einem MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • In dem MCAST-System ist eine Transportschicht in eine Kapselungsschicht und eine Paketbildungsschicht unterteilt. Die Kapselungsschicht ist für ein Fragment von Anwendungsdaten verantwortlich, und die Transportschicht unterteilt das Kapselungspaket in MCAST-Transportpakete.
  • Das heißt, die Kapselungsschicht kapselt alle Typen von Anwendungsdaten, so dass sie an ein A-VSB-Übertragungsverfahren angepasst werden. Das heißt, ein Kapselungspaket mit einer Struktur, die an Anwendungsdaten angepasst ist, wird so erzeugt, dass sie für das Format der Anwendungsdaten geeignet ist. Die Anwendungsdaten schließen Echtzeit-Medien-Daten, IP-Daten, Objekt-Daten und Signalisierungs-Daten ein. Das Kapselungspaket hat je nach einem Anwendungstyp eine spezielle Struktur.
  • Die Paketbildungsschicht unterteilt ein von einer Kapselungsschicht erzeugtes Kapselungspaket in wenigstens ein Transportpaket. Die Größe des Transportpaketes kann verschieden festgelegt werden, so beispielsweise auf 168 oder 188 Bytes.
  • Die Nutzdaten des MCAST-Paketes können verknüpft übertragen werden. Das heißt, ein Teil der Kapselungspakete oder alle beiden oder mehr können in einem MCAST-Paket enthalten sein. Gemäß der vorliegenden Erfindung werden ein ‚first_last‘-Feld sowie ein ‚pointer_field‘-Feld verwendet, um diese Situation anzuzeigen und dabei Bits zu sparen.
  • Das ‚first_last‘-Feld und das ‚pointer_field‘-Feld, die in einem Header-Bereich eines Transportpaketes vorhanden sind, der weiter unten beschrieben wird, können wie folgt definiert werden: [Tabelle 12]
    first_lastfield pointer-Feld Beschreibung
    Erstes Kapselungspaket Zweites Kapselungspaket
    00 1 beginnt in vorangegangenem TP und endet in diesem TP beginnt in diesem TP und endet nicht in diesem Paket
    01 1 beginnt in diesem TP und endet in diesem Paket
    10 1 beginnt und endet in diesem TP beginnt in diesem TP und endet nicht in diesem Paket
    11 1 beginnt in diesem TP und endet in diesem Paket
  • Das ‚pointer_field‘-Feld zeigt an, ob ein MCAST-Transportpaket zwei oder mehr Kapselungspakete enthält. Wenn der Wert dieses Feldes ‚1‘ ist, bedeutet dies, dass zwei oder mehr Kapselungspakete in dem MCAST-Transportpaket vorhanden sind. In der aktuellen Ausführungsform ist der Wert dieses Feldes ‚1‘ und daher sind zwei oder mehr Kapselungspakete in dem MCAST-Transportpaket enthalten.
  • Das ‚first_last‘-Feld zeigt an, ob der Anfang und das Ende des Kapselungspaketes in dem MCAST-Transportpaket enthalten sind. Um die Erläuterung zu vereinfachen, werden ein vorangehendes Paket und ein nachfolgendes Paket als ein erstes Kapselungspaket bzw. ein zweites Kapselungspaket von zwei oder mehr aufeinanderfolgenden Kapselungspaketen bezeichnet. Wenn zwei oder mehr Kapselungspakete in dem MCAST-Transportpaket enthalten sind, sind das Ende des ersten Kapselungspaketes und der Anfang des zweiten Kapselungspaketes in dem MCAST-Transportpaket enthalten.
  • Ein erstes Bit des ‚first_last‘-Feldes zeigt an, ob der Anfang des ersten Kapselungspaketes in dem MCAST-Transportpaket enthalten ist, und ein zweites Bit desselben zeigt an, ob das Ende des zweiten Kapselungspaketes in dem MCAST-Transportpaket enthalten ist. Wenn beispielsweise der Wert dieses Feldes ‚10‘ ist, sind sowohl der Anfang als auch das Ende des ersten Kapselungspaketes in dem MCAST-Transportpaket enthalten, und nur der Anfang des zweiten Kapselungspaketes ist in dem MCAST-Transportpaket enthalten.
  • 49 bis 55 stellen Beispiele eines Kapselungspaketes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • 49A und 49B stellen die Struktur eines Kapselungspaketes für Signalisierung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das in 49A dargestellte Paket enthält einen 4-Byte-Header und Nutzdaten. Die Nutzdaten können eine Beschreibung oder Metadaten einer Anwendung, wie beispielsweise einen ESG und einen elektronischen Programmführer (EPG), enthalten. Des Weiteren enthalten die Nutzdaten optionale Daten, wie beispielsweise eine IP-Zuordnungsinformations-Tabelle und Metadaten-Informationen eines Objektes.
  • Ein ‚first_last‘-Feld ist ein 2-Bit-Feld, das angibt, ob ein Kapselungspaket ein erstes oder letztes ist. Dieses Feld kann entsprechend dem Wert desselben wie in Tabelle 5 dargestellt, definiert sein.
  • Ein ‚compression_flag‘-Feld ist ein 1-Bit-Feld, das angibt, ob Nutzdaten komprimiert sind oder nicht. Wenn der Wert dieses Feldes ‚1‘ ist, kann dies bedeuten, dass die Nutzdaten komprimiert sind.
  • Ein ‚signal_type‘-Feld zeigt den Typ der Nutzdaten an. Der Typ der Nutzdaten entsprechend dem Wert dieses Feldes kann wie in Tabelle 13 oder Tabelle 14 dargestellt sein. [Tabelle 13]
    Wert Beschreibung
    0 untersagt
    1 [TBD]
    2 Objekt-Transport-Informationen
    3-31 reserviert
    [Tabelle 14]
    Wert Beschreibung
    0 untersagt
    1 IP _mapping_Table
    2-31 reserviert
  • Ein ‚sequence_number‘-Feld ist ein 8-Bit-Feld, das einen Wert anzeigt, der innerhalb des gleichen Datentyps eines Kapselungspaketes inkrementiert wird. Der Wert dieses Feldes bewegt sich umlaufend bis ‚0‘, wenn er einen Maximalwert erreicht. Das ‚sequence_number‘-Feld wird bei Sendewiederholung für eine Objektfragmentierungs-Kennung verwendet.
  • Ein ‚version_number‘-Feld ist ein 4-Bit-Feld, das die Versionsnummer eines Signalisierungs-Kapselungspaketes (SEP) anzeigt. Die Versionsnummer wird immer dann um 1 inkrementiert, wenn eine Kapselungs-Nutzdatenversion geändert wird.
  • Ein ‚packet_length‘-Feld zeigt die Länge der Nutzdaten in dem Paket in Bytes an.
  • Ein ‚data_byte‘-Feld ist ein 8-Bit-Feld. Der Typ der Daten, die über die Nutzdaten übertragen werden, hängt von dem Wert des ‚signal_type‘-Feldes ab.
  • 50A und 50B stellen die Struktur eines Kapselungspaketes für Echtzeit-Daten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das in 50 dargestellte Paket ist ein Kapselungspaket für einen Echtzeit-Datentyp und enthält einen Header, ein zusätzliches Feld sowie Nutzdaten.
  • Ein ‚first_last‘-Feld ist ein 2-Bit-Feld, das angibt, ob ein Kapselungspaket ein erstes oder letztes Paket ist. Dieses Feld kann entsprechend seinem Wert wie in Tabelle 5 dargestellt, definiert werden.
  • Ein ‚RT_type‘-Feld ist ein 6-Bit-Feld, das den Typ von Daten anzeigt, die über die Nutzdaten übertragen werden. Ein Beispiel des Datentyps entsprechend dem Wert dieses Feldes kann sich wie folgt darstellen: [Tabelle 15]
    Wert Beschreibung
    0 Audio
    1 Video
    3-63 reserviert
  • Ein ‚DCI_flag‘-Feld zeigt an, ob Decoder-Konfigurationsinformationen (DCI) im Header des Kapselungspaketes vorhanden sind. In der aktuellen Ausführungsform enthält das ‚DCI_field‘-Feld DCI.
  • Ein ‚DC_version‘-Feld zeigt die Version der DCI an. Der Wert dieses Feldes häng eng mit dem Wert des DC-Feldes (bzw. des DCI-Feldes) eines Transportpaketes zusammen und sollte so festgelegt werden, dass er gleich ist.
  • Ein ‚addition flag‘-Feld zeigt an, ob zusätzliche Informationen in dem Header des Kapselungspaketes vorhanden sind. Bei der aktuellen Ausführungsform enthält das ‚additional_field‘-Feld zusätzliche Informationen.
  • Ein ‚DCI_Iength‘-Feld zeigt in Bytes die Länge des ‚DCI_field‘-Feldes in dem Header des Paketes an.
  • Das ‚DCI_field‘-Feld zeigt die DCI an. Das ‚DCI_field‘-Feld (bzw. ein ‚Decoder_Configuration_Information‘-Feld) ist oben unter Bezugnahme auf 4 beschrieben worden.
  • Ein ‚packet_length‘-Feld zeigt in Bytes die Länge der Nutzdaten eines Paketes an, das auf das ‚packet_length‘-Feld folgt.
  • Ein ‚PTS_flag‘-Feld zeigt an, ob PTS-Informationen im Header des Kapselungspaketes vorhanden sind. In der aktuellen Ausführungsform enthält ein ‚PTS‘-Feld PTS-Informationen.
  • Eine ‚DTS_flag‘-Feld zeigt an, ob DTS-Informationen in dem Header des Kapselungspaketes vorhanden sind. In der aktuellen Ausführungsform enthält ein ‚DTS‘-Feld DTS-Informationen.
  • Ein ‚padding_flag‘-Feld zeigt an, ob Füll-Bytes in dem Header des Kapselungspaketes vorhanden sind.
  • Ein ‚scrambling_control‘-Feld signalisiert einen Scrambling-Modus der Nutzdaten des Kapselungspaketes.
  • Das ‚PTS‘-Feld ist ein 33-Bit-Feld, das einen Presentation-Time-Stamp (PTS) anzeigt, wie er in ISO/IEC 13818-1 definiert ist.
  • Das ‚DTS‘-Feld ist ein 33-Bit-Feld, das einen Decoding-Time-Stamp (DTS) anzeigt, wie er in ISO/IEC 13818-1 definiert ist.
  • Ein ‚padding_length‘-Feld zeigt in Bytes die Länge von Füll-Daten in dem Paket an. In der aktuellen Ausführungsform enthält ein ‚padding_byte‘-Feld Füll-Daten.
  • Das ‚padding_byte‘-Feld hat einen 8-Bit-Wert, der ‚0 × FF‘ gleich ist, und kann von einem Codierer eingefügt werden. Dieses Feld wird von einem Codierer verworfen.
  • Ein ‚data_byte‘-Feld besteht aus 8 Bits.
  • 51 stellt die Syntax eines Kapselungspaketes für Echtzeit-Daten gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar. Die Felder in dem in 51 dargestellten Kapselungspaket sind die gleichen wie die in 50.
  • 52A und 52B stellen die Syntax eines Kapselungspaketes für IP-Daten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das in 52 dargestellte Paket dient dazu, ein IP-Datagram zu übertragen. Das IP-Datagram kann in eine Vielzahl von Kapselungspaketen unterteilt und dann übertragen werden. Es muss dargestellt werden, ob ein aktuelles Paket ein letztes Paket ist, und in diesem Fall kann ein ‚first_last‘-Feld, das weiter unter beschrieben wird, angewendet werden. Als Alternative dazu kann, wenn der Wert eines ‚first_last‘-Feldes auf ‚0 × 01‘ oder ‚0 × 03‘ eingestellt ist, festgestellt werden, dass ein aktuelles IP-Kapselungspaket ein letztes ist.
  • Wenn ein Ziel-Kapselungspaket ein erstes ist, beinhaltet ein Header-Feld Informationen, die anzeigen, ob dieses Kapselungspaket ein erstes oder letztes Paket ist, Informationen, die anzeigen, ob zusätzliche Informationen vorhanden sind, Informationen bezüglich des Formats von IP-Daten, die in einem Nutzdatenbereich enthalten sind, und Informationen bezüglich der Länge des Kapselungspaketes.
  • Wenn das Ziel-Kapselungspaket kein erstes Paket ist, enthält das Header-Feld Informationen, die anzeigen, ob dieses Kapselungspaket ein erstes oder letztes Paket ist, Sequenznummer-Informationen und Informationen bezüglich der Länge des Kapselungspaketes.
  • Ein zusätzliches Header-Feld beinhaltet Informationen, die anzeigen, ob nachfolgende zusätzliche Informationen vorhanden sind, Informationen bezüglich des Typs zusätzlicher Informationen, Informationen bezüglich der Länge der zusätzlichen Informationen und die zusätzlichen Informationen.
  • Ein ‚first_last‘-Feld ist ein 2-Bit-Feld, das anzeigt, ob ein aktuelles Paket ein erstes oder letztes Paket ist. Dieses Feld kann entsprechend dem Wert desselben wie in Tabelle 5 dargestellt, definiert werden.
  • Ein ‚addition_flag‘-Feld ist ein 1-Bit-Feld, das anzeigt, ob zusätzliche Informationen vorhanden sind. In der aktuellen Ausführungsform enthält ein ‚additional_data‘-Feld zusätzliche Informationen. Wenn der Wert dieses Feldes ‚1‘ ist, kann daraus geschlossen werden, dass das ‚additional_data‘-Feld vorhanden ist.
  • Ein ‚IP_type‘-Feld ist ein 5-Bit-Feld, das den Typ von Daten anzeigt, die über eine IP-Nutzinformationen übertragen werden. Dieses Feld kann beispielsweise dazu dienen, zwischen IPv4 und IPv6 zu unterscheiden.
  • Ein ‚sequence_number‘-Feld besteht aus 4 Bits und wird innerhalb des gleichen Datentyps eines Kapselungspaketes um 1 inkrementiert. Der Wert dieses Feldes bewegt sich umlaufend bis ‚0‘, wenn er einen Maximalwert erreicht. Dieses Feld dient bei Sendewiederholung als eine IP-Fragmentierungs-Kennung.
  • Ein ‚encapsulation_packet_length‘-Feld besteht aus 12 Bits und zeigt die Längt der Nutzinformation in Bytes an.
  • Ein ‚continuity_flag‘-Feld besteht aus 1 Bit und zeigt an, ob tag-, length-, additional_data-Felder folgen. Wenn der Wert dieses Feldes ‚0‘ ist, wird daraus ersichtlich, dass ein aktuelles Feld ein letztes Feld ist, das zusätzliche Informationen beinhaltet.
  • Ein ‚tag‘-Feld ist ein 7-Bit-Feld, das den Typ eines ‚additional_data‘-Feldes anzeigt. Dieses Feld wirkt als ein Container, der verschiedene Typen von Informationen beinhalten kann, die zusätzlich für die Übertragung von IP-Daten erforderlich sind. Der Typ der Informationen, die zusätzlich benötigt werden, ist nicht beschränkt.
  • Ein ‚length‘-Feld zeigt die Länge des ‚additional_data‘-Feldes in Bytes an.
  • Die Länge des ‚additional_data‘-Feldes kann verschieden bestimmt werden. Die zusätzlichen Daten enthalten Daten entsprechend dem ‚tag‘-Feld.
  • Ein ‚payload‘-Feld kann verschieden festgelegt werden und enthält IP-Paket-Daten, wie sie in dem IP_type‘-Feld definiert sind.
  • 53 stellt die Syntax eines Kapselungspaketes für Echtzeit-Daten gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Das in 53 dargestellte Paket ist bis auf die Tatsache, dass ein Header verändert worden ist, das gleiche wie das in 52.
  • 54A und 54B stellen die Struktur eines Paketes für Objekt-Daten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das in 54A dargestellte Paket ist ein Kapselungspaket zum Übertragen eines Objekt-Datentyps. Das Paket enthält eine Vielzahl von Transportpaketen, über die ein Objekt-Datentyp übertragen wird. Das Paket ist in einen Header, zusätzliche Informationen und eine Nutzinformation unterteilt. Ein zusätzliches Header-Feld beinhaltet zusätzliche Informationen bezüglich der Nutzinformation.
  • Objekt-Daten werden über einen Objekt-Teil-Datenkanal entsprechend zwei der Verfahren transportiert, die weiter unten ausführlich unter Bezugnahme auf 56 beschrieben werden.
  • Wenn ein Kapselungspaket ein erstes Paket ist, enthält ein Header-Feld Informationen, die anzeigen, ob dieses Paket ein erstes oder ein letztes Paket ist, Informationen, die anzeigen, ob zusätzliche Informationen vorhanden sind, Identifizierungsinformationen der Objekt-Daten, die über ein Nutzinformations-Feld geliefert werden, Informationen bezüglich des Typs der Objekt-Daten und Informationen bezüglich der Länge des Paketes. Wenn ein Kapselungspaket kein erstes Paket ist, beinhaltet das Header-Feld Informationen, die anzeigen, ob dieses Paket ein erstes oder ein letztes Paket ist, Informationen, die anzeigen, ob zusätzliche Informationen vorhanden sind, Sequenznummer-Informationen und Informationen bezüglich der Länge des Paketes.
  • Das zusätzliche Header-Feld beinhaltet Informationen, die anzeigen, ob nachfolgende zusätzliche Informationen vorhanden sind, Informationen bezüglich des Typs der zusätzlichen Informationen, Informationen bezüglich der Länge der zusätzlichen Informationen und die zusätzlichen Informationen.
  • Ein ‚first_last‘-Feld zeigt an, ob ein aktuelles Paket ein erstes oder ein letztes Kapselungspaket ist. Dieses Feld kann gemäß dem Wert desselben definiert werden, wie dies in Tabelle 5 dargestellt ist.
  • Ein ‚addition_flag‘-Feld zeigt an, ob zusätzliche Informationen im Header des Kapselungspaketes vorhanden sind. In der aktuellen Ausführungsform beinhaltet ein ‚additional_field‘-Feld die zusätzlichen Informationen.
  • Ein ‚object_ID‘-Feld dient dazu, alle Objekte zu identifizieren, die über den gleichen Teil-Datenkanal geliefert werden.
  • Ein ‚object_type‘-Feld gibt den Typ von Objekt-Daten an, beispielsweise jpeg (komprimiert oder nicht), Text (komprimiert oder nicht) oder mp3.
  • Ein ‚sequence_number‘-Feld zeigt Fragmentierungs-Informationen an.
  • Ein ‚packet_length‘-Feld zeigt die Länge nachfolgender Daten an.
  • Ein ‚continuity_flag‘-Feld gibt an, ob ein ‚additional_field‘ folgt. Wenn der Wert dieses Flags auf ‚1‘ eingestellt ist, bedeutet dies, dass das ‚additional_field‘-Feld folgt, und wenn der Wert dieses Feldes auf ‚0‘ eingestellt ist, bedeutet dies, dass ein aktuelles ‚additional_field‘-Feld das letzte Feld ist.
  • Ein ‚tag‘-Feld zeigt den Typ von objektdecorder-spezifischen Informationen an. Dieses Feld zeigt die Unterteilung des Typs der Objekt-Daten an, der in dem ‚object_type‘-Feld angegeben ist. Wenn beispielsweise das ‚object_type‘-Feld Text (komprimiert) anzeigt, kann der Datentyp entsprechend einem Komprimierungsverfahren unterteilt werden. In diesem Fall kann der Datentyp als mittels ‚GZIP komprimierter Text‘ über das ‚tag‘-Feld ausgedrückt werden.
  • Ein ‚length“-Feld‘ drückt die Länge des ‚additional_field_data‘-Feldes in Bytes aus.
  • Ein ‚additional_field_data‘-Feld beinhaltet die für den Objekt-Decoder spezifischen Informationen.
  • Ein ‚Nutzinformations‘-Feld beinhaltet die Objekt-Daten.
  • 55A und 55B stellen die Struktur eines Paketes für Objekt-Daten gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚First_last‘-Feld ist ein 2-Bit-Feld, das anzeigt, ob ein Paket ein erstes oder ein letztes Kapselungspaket ist. Die Definition dieses Feldes entsprechend einem Wert desselben ist in Tabelle 5 dargestellt.
  • Ein ‚object_delivery_mode‘-Feld zeigt einen Quellen-Blockmodus an. Wenn der Wert dieses Feldes ‚0‘ ist, kann eine Quellen-Blocknummer nicht verwendet werden, und wenn der Wert dieses Feldes ‚3‘ ist, ist es für zukünftige Zwecke reserviert.
  • Ein ‚object_extention_id‘-Feld wird als eine zusätzliche Kennung einer Vielzahl von Objekten verwendet, wenn die Objekte innerhalb des gleichen Teil-Datenkanals übertragen werden.
  • Ein ‚source_block_number_8‘-Feld besteht aus 8 Bits und zeigt die Nummer eines Quellen-Blocks an. Der Wert dieses Feldes stellt die Nummer eines Quellen-Blocks dar, zu dem ein aktuelles OEP gehört.
  • Ein ‚source_block_number-16‘-Feld besteht aus 16 Bits und zeigt die Nummer eines Quellen-Blocks an. Der Wert dieses Feldes stellt die Nummer eines Quellen-Blocks dar, zu dem ein aktuelles OEP gehört.
  • Ein ‚version‘-Feld zeigt die Versionsnummer von Objektdaten an. Die Versionsnummer wird immer dann um 1 erhöht, wenn die Objekt-Daten geändert werden. Eine Änderung an einem Objekt bedeutet, dass das Objekt aktualisiert wird. Wenn beispielsweise ein Name zu einer Map-Datei hinzugefügt wird, wird ein Objekt, das die Map-Datei ist, geändert.
  • Eine ‚fragment_number‘ zeigt Fragmentierungs-Informationen eines Feld-Quellen-Blocks oder eines Objektes an, wenn die Länge des Quellen-Blocks oder des Objektes eine maximale Länge des Paktes übersteigt.
  • Ein ‚packet_length‘-Feld zeigt die Paketlänge in Bytes an.
  • 56 stellt ein Verfahren zum Übertragen von Objekt-Daten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Eines oder mehrere Elemente von Objekt-Daten werden jeweils über einen Teil-Datenkanal geliefert. Ein Fall, in dem ein Element von Objekt-Daten über einen Teil-Datenkanal geliefert wird, wird als ein Einzelobjekt-Modus bezeichnet, und ein Fall, in dem eine Vielzahl von Elementen von Objekt-Daten über einen Teil-Datenkanal geliefert werden, wird als ein Mehrfachobjekt-Modus bezeichnet.
  • In dem Mehrfachobjekt-Modus müssen Kennungen jeweils einer Reihe von Objekt-Daten in dem Teil-Datenkanal zugeordnet werden. Als Alternative dazu kann eine Vielzahl von Elementen von Objekt-Daten, die über den gleichen Teil-Datenkanal übertragen werden können, mittels einer Objekt-Kennung identifiziert werden. Ansonsten kann, wenn ein Paket ein ‚additional_field‘-Feld zum Übertragen zusätzlicher Informationen, wie beispielsweise charakteristischer Informationen von Objekt-Daten, beinhaltet, eine Reihe von Objekten in dem gleichen Teil-Datenkanal identifiziert werden, indem ein ‚object_extension_id‘-Feld in ein ‚additional_field‘-Feld eingefügt wird.
  • 57 stellt die Anwendung von AL-FEC gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein OEP-Paket enthält einen Header und eine Nutzinformation und besteht aus einer Vielzahl von Transportpaketen. Ein SEP stellt Nutzungsinformationen von AL-FEC und spezifische Parameter bereit. Ein Verfahren zum Anordnen einer AL-FEC-Schicht und von Objekten wird im Folgenden unter Bezugnahme auf 57 beschrieben.
  • Wenn MCAST-AL-FEC angewendet wird, werden Objekte in eine Vielzahl von Quellen-Blöcken fragmentiert. Jeder der Quellen-Blöcke besteht aus Paketen mit einer vorgegebenen Länge. Die Länge und die Anzahl von Paketen werden von einem MCAST-AL-FEC-Codiermodus bestimmt. Nachdem MCAST-AL-FEC-Codieren durchgeführt worden ist, wird ein redundantes Paket hinzugefügt. Fehlerkorrektur kann innerhalb des Bereiches des redundanten Paketes durchgeführt werden.
  • Im Folgenden wird ein MCAST-Transportpaket beschrieben.
  • 58A und 58B stellen ein Transportpaket und eine Header-Struktur des Transportpaketes gemäß Ausführungsformen der vorliegenden Erfindung dar.
  • Ein Transportpaket gemäß einer Ausführungsform der vorliegenden Erfindung enthält, wie unter Bezugnahme auf 58A zu sehen ist, ein Basis-Header-Feld, ein PCR-Informations-Feld, ein Zeiger-Feld, ein Padding-Feld, ein LMT-Feld, ein LIT-Feld und ein Nutzinformations-Feld.
  • Das Base-Header-Feld beinhaltet Informationen, die anzeigen, ob ein Transportpaket ein erstes oder ein letztes Kapselungspaket ist, Informationen, die anzeigen, ob ein PCR vorhanden ist, Informationen, die anzeigen, ob DCI in einem Header-Feld des Kapselungspaketes vorhanden sind, Informationen, die anzeigen, ob ein Padding-Bereich vorhanden ist, Informationen, die anzeigen, ob eine LMT vorhanden ist, und Informationen, die anzeigen, ob eine LIT vorhanden ist. Diese Felder werden weiter unten ausführlich unter Bezugnahme auf 59 beschrieben.
  • 58B stellt die Struktur eines Padding-Feldes eines Transportpaketes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Das Padding-Feld des Transportpaketes gemäß einer Ausführungsform der vorliegenden Erfindung kann Padding-Längeninformationen und Padding-Bytes enthalten.
  • Ein LMT-Feld und ein LIT-Feld in dem Transportpaket entsprechen der obenstehenden Beschreibung unter Bezugnahme auf 34 bis 41.
  • 58C und 58D stellen ein Transportpaket und eine Header-Struktur des Transportpaketes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Das in 58C und 58D dargestellte Paket kann verwendet werden, wenn nur ein Typ von Daten übertragen wird, d.h., wenn nur IP-Daten über ein MAST-System übertragen werden.
  • 59A stellt die Syntax eines Transportpaketes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚first_last‘-Feld zeigt an, ob ein Transportpaket ein erstes oder ein letztes Kapselungspaket ist. Die Definition dieses Feldes gemäß dem Wert desselben ist in Tabelle 5 dargestellt.
  • Ein ‚DC_flag‘-Feld zeigt an, ob DCI in dem Header eines Kapselungspaketes vorhanden sind. In der aktuellen Ausführungsform enthält ein ‚decoder_configuration_information‘-Feld die DCI.
  • Ein ‚pointer_flag‘-Feld zeigt an, ob ein ‚point-field‘-Feld in dem Header eines Transportpaketes vorhanden ist.
  • Ein ‚padding_flag‘-Feld zeigt an, ob ein ‚padding‘-Feld in dem Header des Transportpaketes vorhanden ist.
  • Ein ‚LMT_flag‘-Feld zeigt an, ob ein ‚LMT_field‘-Feld in dem Header des Transportpaketes vorhanden ist.
  • Ein ‚LIT_flag‘-Feld zeigt an, ob ein ‚LIT_field‘-Feld in dem Header des Transportpaketes vorhanden ist.
  • Ein ‚PCR_flag‘-Feld zeigt an, ob das Transportpaket ein ‚PCR_field‘-Feld enthält. Wenn der Wert dieses Feldes ‚1‘ ist, kann daraus geschlossen werden, dass das Transportpaket das ‚PCR-field‘-Feld enthält.
  • Ein ‚pointer_field‘-Feld zeigt die Anfangsposition einer zweiten Nutzinformation an, wenn zwei Kapselungspakete in einem Transportpaket vorhanden sind.
  • Ein ‚padding_length‘-Feld zeigt in Bytes die Padding-Größe innerhalb eines Paketes an.
  • Ein ‚padding_byte‘-Feld hat einen 8-Bit-Wert, der ‚0 × FF‘ gleich ist, das durch einen Codierer eingefügt wird. Das ‚padding_byte‘-Feld wird durch einen Decoder verworfen.
  • Die Felder von einem ‚type_bitmap‘-Feld bis zu einem ‚object_channel_pointer‘-Feld haben die gleiche Struktur wie die in 34 dargestellte LMT und werden daher nur kurz beschrieben.
  • Das ‚type_bitmap‘-Feld zeigt den Typ von Daten an, die über ein Transportpaket geliefert werden. Jedes Bit dieses Feldes hat eine einzigartige Bedeutung. Ein erstes Bit dieses Feldes bedeutet, dass ein Echtzeit-Datenkanal vorhanden ist, ein zweites Bit dieses Feldes bedeutet, dass ein IP-Datenkanal vorhanden ist, und ein drittes Bit dieses Feldes bedeutet, dass ein Objekt-Datenkanal vorhanden ist.
  • Ein ‚version_number‘-Feld zeigt die Versionsnummer einer LMT an. Die Versionsnummer wird immer dann, wenn LMT-Daten geändert werden, um 1 modulo 16 erhöht.
  • Ein ‚real-time_channel-number‘-Feld zeigt die Anzahl von Teil-Datenkanälen in einem Echtzeit-Medientyp-Kanal an.
  • Ein ‚IP_channel_number‘-Feld zeigt die Anzahl von Teil-Datenkanälen in einem IP-Type-Kanal an.
  • Ein ‚object_channel_number‘-Feld zeigt die Anzahl von Teil-Datenkanälen in einem Objekttyp-Kanal an.
  • Ein ‚real-time_channel_pointer‘-Feld zeigt die Position eines Teil-Datenkanals des Echtzeit-Datentyps in einem Datenkanal an.
  • Ein ‚IP_channel_pointer‘-Feld zeigt die Position eines Teil-Datenkanals eines IP-Datentyps in dem Datenkanal an.
  • Ein ‚object_channel_pointer‘-Feld zeigt die Position eines Teil-Datenkanals des Objekt-Datentyps in dem Datenkanal an.
  • Die Felder von einem ‚service_number‘-Feld bis zu einem ‚LMT_index_number‘-Feld sind die gleichen wie die der in 40 dargestellten LIT und werden daher hier nur kurz beschrieben.
  • Ein ‚service_number‘-Feld zeigt die Anzahl von Diensten an, die innerhalb eines Datenkanals genutzt werden können.
  • Ein ‚version_number‘-Feld zeigt die Versionsnummer eines LlT-Feldes an. Die Versionsnummer wird immer dann um 1 erhöht, wenn Signalisierungsdaten geändert werden.
  • Ein ‚service_ID‘-Feld identifiziert einen Dienst in einem Turbo-Kanal. Die Kennung hat einen eindeutig zugeordneten Wert in dem Turbo-Kanal.
  • Ein ‚next_indicator‘-Feld zeigt das Vorhandensein eines nachfolgenden ‚next_indicator‘-Feldes und eines nachfolgenden ‚LMT_number‘-Feldes an. Wenn der Wert dieses Feldes beispielsweise ‚0‘ ist, bedeutet dies, dass kein ‚next_indicator‘-Feld und kein ‚LMT_number‘-Feld mehr vorhanden ist.
  • Das ‚LMT_index_number‘-Feld zeigt die Position eines Teil-Datenkanals in einer LMT an.
  • Ein ‚index_number‘-Feld zeigt die Sequenznummer eines Elementar-Kanals an, der mit einem Dienst verbunden ist.
  • Ein ‚Program_clock_reference_base‘/‚Program_clock_reference_extension‘-Feld enthält einen 42-Bit-PCR, der in zwei Teile unterteilt und dann codiert wird. Der erste Teil ist ein 33-Bit-Feld, dessen Wert eine Basis ist, die sich aus der gleichen Gleichung ergibt, wie sie in 2-1 auf Seite 14 in der Spezifikation MPEG-2 13818-1 definiert ist. Der zweite Teil ist ein 9-Bit-Feld, dessen Wert sich aus der gleichen Gleichung ergibt, wie sie in 2-2 auf Seite 14 in der Spezifikation MPEG-2 13818-1 definiert ist.
  • Ein ‚data_byte‘-Feld besteht aus 8 Bits und enthält Kapselungs-Paketdaten.
  • 59B stellt die Struktur eines Transportpaketes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Die Felder in dem in 59B dargestellten Transportpaket sind die gleichen wie diejenigen in dem in 59A dargestellten Transportpaket.
  • 59C stellt die Struktur eines Transportpaketes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Die Struktur des in 59C dargestellten Transportpaketes ist mit Ausnahme eines ‚Error_flag‘-Feldes die gleiche wie die des Transportpaketes in 19A.
  • Das ‚Error_flag‘-Feld zeigt an, ob in einem aktuellen Paket ein Fehler vorhanden ist. Wenn der Wert dieses Feldes ‚1‘ ist, ist ein Fehler in diesem Paket vorhanden, wenn das Paket entpackt wird.
  • 59D stellt die Struktur eines Transportpaketes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Die Felder in dem in 59D dargestellten Transportpaket sind die gleichen wie die in dem in 59A dargestellten Transportpaket.
  • 60A und 60B stellen die Strukturen eines Transportpaketes, eines Basis-Headers und eines zusätzlichen Feldes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Das in 60A dargestellte Transportpaket enthält eine Vielzahl von Header-Feldem und ein Nutzinformations-Feld. Jedes der Header-Felder enthält Basis-Header-Informationen, Informationen, die anzeigen, ob ein Zeiger vorhanden ist, LMT-Informationen, zusätzliche Informationen und eine Nutzinformation. Ein IP-Datagram und Signalisierungspakete werden über das Nutzinformationsfeld geliefert.
  • 60A stellt im Detail die Syntax eines Transportpaketes gemäß einer anderen Ausführungsform der vorliegenden Erfindung dar.
  • Ein ‚first_last‘-Feld ist ein 2-Bit-Feld, das angibt, ob ein Paket das erste oder das letzte Kapselungspaket ist, wie es in Tabelle 5 definiert ist.
  • Ein ‚signal_pkt_indicator‘-Feld zeigt an, ob Nutzinformations-Daten Signalisierungsdaten sind. Wenn der Wert dieses Feldes ‚1‘ ist, kann daraus entnommen werden, dass über ein ‚payload‘-Feld gelieferte Daten Signalisierungsdaten sind.
  • Ein ‚error_indicator‘-Feld zeigt an, ob ein Paket einen Fehler enthält.
  • Ein ‚additional_flag‘-Feld ist ein 1-Bit-Feld, das anzeigt, ob zusätzliche Informationen vorhanden sind. In der aktuellen Ausführungsform beinhaltet ein ‚additional_field‘-Feld zusätzliche Informationen. Wenn der Wert dieses Feldes ‚1‘ ist, kann daraus geschlossen werden, dass das ‚additional_field‘-Feld vorhanden ist.
  • Ein ‚compression_flag‘-Feld zeigt an, ob das IP-Datagram komprimiert ist. Wenn der Wert dieses Feldes ‚1‘ ist, bedeutet dies, dass ein IP-Datagram, das über das ‚payload‘-Feld geliefert wird, komprimiert ist.
  • Ein ‚pointer_flag‘-Feld zeigt an, ob ein anderes IP-Datagram oder Signalisierungsdaten vorhanden sind. Wenn der Wert dieses Feldes ‚1‘ ist, kann daraus geschlossen werden, dass ein anderes IP-Datagram oder Signalisierungsdaten vorhanden sind.
  • Ein ‚continuity_flag‘-Feld ist ein 1-Bit-Feld, das anzeigt, ob ein ‚<tag>length><additional field data>‘-Feld vorhanden ist. Das heißt, wenn das ‚<tag>length><additional field data>‘-Feld als das ‚Add.Field‘-Feld bezeichnet wird, kann daraus geschlossen werden, dass das ‚Add.Field‘-Feld vorhanden ist, wenn der Wert des ‚continuity_flag‘-Feldes ‚1‘ ist, und dass das ‚Add.Field‘-Feld nicht vorhanden ist, wenn der Wert des ‚continuity_flag‘-Feldes ‚0‘ ist.
  • Ein ‚tag‘-Feld definiert den Datentyp zusätzlicher Informationen wie folgt: [Tabelle 16]
    Tag Beschreibung
    0 Padding-Feld
    1 LMT-Feld
    2 Kompressionsparameter-Feld
    3-127 reserviert
  • Ein ‚length‘-Feld zeigt die Länge nachfolgender zusätzlicher Informationen an. In der aktuellen Ausführungsform beinhaltet ein ‚additional_field‘-Feld zusätzliche Informationen, und so zeigt das ‚length‘-Feld die Länge des ‚additional_field‘-Feldes an.
  • Das ‚addition_field‘-Feld beinhaltet die zusätzlichen Informationen.
  • Ein ‚pointer_field‘-Feld ist ein 8-Feld, das einen Offset von dem Beginn des Transportpaketes zu dem ersten Byte eines zweiten Kapselungspaketes in dem Transportpaket anzeigt, wenn das Transportpaket zwei oder mehr Kapselungspakete enthält.
  • Eine ‚data_byte‘-Feld enthält ein IP-Datagram oder Signalisierungsdaten. Daten können fragmentiert sein.
  • 61A und 61B stellen die Struktur eines ‚paddling_field‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 60 dargestellten ‚tag‘-Feldes ‚0‘ ist.
  • Das ‚tag‘-Feld zeigt an, dass ein Padding-Feld folgt.
  • Ein ‚length‘-Feld ist ein 8-Bit-Feld, das die Länge des Padding-Feldes anzeigt. In der vorliegenden Ausführungsform beinhaltet ein ‚padding_byte‘-Feld Padding-Daten und so zeigt das ‚length‘-Feld die Länge des ‚padding_byte‘-Feldes an.
  • Das ‚padding_byte‘-Feld hat einen 8-Bit-Wert, der gleich ‚0 × FF‘ ist und von einem Codierer eingefügt werden kann. Dieses Feld wird von einem Decodierer verworfen.
  • 62 stellt die Struktur eines ‚LMT_field‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 60 dargestellten ‚tag‘-Feldes ‚1‘ ist.
  • Ein ‚tag‘-Feld zeigt an, dass LMT-Informationen folgen. In der aktuellen Ausführungsform enthält ein ‚LMT_information‘-Feld LMT-Informationen.
  • Ein ‚length‘-Feld ist ein 8-Bit-Feld, das in Bytes die Länge eines ‚LMT_information‘-Feldes anzeigt.
  • Das ‚LMT_information‘-Feld enthält Positionsinformationen aller IP-Daten innerhalb eines IP-Teil-Datenkanals und Positionsinformationen aller Signalisierungsdaten innerhalb eines Teil-Datenkanals. Dieses Feld ist oben unter Bezugnahme auf 34 bis 39 beschrieben worden.
  • 63 stellt die Struktur eines ‚compression_field-parameter‘-Feldes gemäß einer Ausführungsform der vorliegenden Erfindung dar, wenn der Wert des in 60 dargestellten ‚tag‘-Feldes ‚2‘ ist.
  • Ein ‚tag‘-Feld zeigt an, ob Informationen bezüglich der Kompressionsparameter folgen. In der vorliegenden Ausführungsform enthält ein ‚compression_parameter‘-Feld Informationen bezüglich der Kompressionsparameter.
  • Ein ‚length‘-Feld ist ein 8-Bit-Feld, das die Länge eines ‚compression_type‘-Feldes und des ‚compression_parameter‘-Feldes in Bytes angibt.
  • Das ‚compression_type‘-Feld zeigt einen Kompressions-Typ an. Zusätzliche Informationen bezüglich des Kompressions-Typs sollten durch ein ‚additional_field‘-Feld transportiert werden. Ein Beispiel eines Kompressions-Typs gemäß dem Wert des ‚compression_type‘-Feldes ist das Folgende: [Tabelle 17]
    Kompressionsparameter Beschreibung
    0 Keine Kompression
    1 ROHC
    2 - 255 reserviert
  • Das ‚compression_parameter‘-Feld beinhaltet Parameter bezüglich der Kompression von Nutzinformationen. Die Parameter variieren entsprechend dem Kompressions-Typ.
  • 64A und 64B stellen die Struktur eines Signalisierungspaketes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Signalisierungsdaten werden über eine Nutzinformation eines MCAST-Transportpaketes transportiert. Die Signalisierungsdaten beinhalten zusätzliche Informationen bezüglich eines IP-Datagrams. IMT-Informationen, die über ein Signalisierungs-Paket transportiert werden, enthalten Verbindungsinformationen zwischen IP-Streams und IP-Teil-Datenkanälen.
  • Ein ‚signal_type‘-Feld zeigt den Typ von Daten, die mittels der Nutzinformation geliefert werden, wie folgt an: [Tabelle 18]
    Wert Beschreibung
    0 Untersagt
    1 IP-Mapping-Tabelle
    2 - 31 reserviert
  • Ein ‚version_number‘-Feld ist ein 3-Bit-Feld, das die Versionsnummer eines Signalisierungspaketes anzeigt. Die Versionsnummer wird immer dann um 1 inkrementiert, wenn Signalisierungsdaten, die über die Nutzinformation übertragen werden, geändert werden.
  • Ein ‚payload_length‘-Feld ist ein 16-Bit-Feld, das die Länge folgender Signalisierungsdaten anzeigt.
  • Ein ‚data_byte‘-Feld beinhaltet Signalisierungsdaten gemäß einem ‚signal_type‘-Feld.
  • Ein Verfahren zur Unterstützung von OMA-BCAST über MCAST und die Beziehung zwischen OMA-BCAST und MCAST gemäß einer Ausführungsform der vorliegenden Erfindung werden im Folgenden beschrieben.
  • Ein ATSC-M/H-Endgerät unterstützt nicht nur IPv6, sondern auch IPv4 für allgemeine Kapselung und Netzwerk-Paketübertragung. Ein ATSC-M/H-System kann sowohl IPv6 als auch IPv4 nutzen. Internet-Protokoll ermöglicht es, eine Trägerschicht und eine Verwaltungsschicht abstrakt und logisch voneinander zu unterscheiden. IP-Datagramme werden in ein MCAST-Transportpaket gekapselt. Für MCAST-Übertragung sind Zuordnungsinformationen zwischen einem IP-Datagram und einem Turbo-Kanal erforderlich, und derartige IP-Adresszuordnungs-Sigalisierung kann über die oben beschriebene IMT durchgeführt werden.
  • Im Folgenden wird eine Verbindung zwischen einem OMA-BCAST-dienst und MCAST beschrieben. Die wichtigsten Faktoren dieser Verbindung sind Signalisierung, Auffinden eines Eintrittpunktes eines Dienstführers (service guide) und Auffinden von Übertragungs-Sitzungen. Zu diesem Zweck müssen IP-Streams und Transport-Kanäle miteinander verbunden werden und signalisiert werden. Für Zugriff auf einen OMA-BCAST-Dienst muss zunächst ein Eintrittspunkt von Dienstankündigungs-Informationen gewährleistet sein. Die Dienstankündigungs-Informationen können über mehr als einen Turbo-Kanal geliefert werden. In MCAST werden die Positions-Informationen eines Turbo-Kanals des Eintrittspunktes des Dienstes unter Verwendung einer IMT übertragen, die über einen SIC übertragen wird. Des Weiteren kann eine IMT, die Positionsinformationen von IP-Streams beinhaltet, die in Turbokanälen enthalten sind, an einer vorgegebenen Position jedes der Turbo-Kanäle vorhanden sein. Um die Erläuterung zu vereinfachen, werden Zuordnungsinformationen (mapping information), die über einen SIC übertragen werden, als ‚i-IMT‘ bezeichnet, und Zuordnungsinformationen in einem Turbo-Kanal, der Daten überträgt, werden, werden als ‚IMT‘ bezeichnet.
  • Um einen OMA-BCAST-Dienstführer bereitzustellen, sind ein Dienstführer-Ankündigungskanal und ein Dienstführer-Lieferkanal in Turbo-Kanälen enthalten. Das heißt, einer der Turbo-Kanäle kann zahlreiche Informationen liefern, die sich auf Dienst-Fragmente für einen Dienstführer in allen Turbo-Kanälen beziehen, so beispielsweise einen Gesamt-ESG. Des weiteren kann dieser Kanal einen Dienstankündigungs-Kanal bereitstellen. Der Gesamt-ESG-Kanal stellt Positionsinformationen von IP-Strömen bereit, die in anderen Turbokanälen enthalten sind, um so Zugang zu den anderen Turbokanälen zu ermöglichen und einen spezifischen IP-Stream zu beziehen.
  • 65 stellt einen Prozess des Bereitstellens eines OMA-BCAST-Dienstes mit einem MCAST-Übertragungssystem gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein SIC enthält, wie unter Bezugnahme auf 65 zu sehen ist, eine i-IMT, die eine Liste aller Dienste-Eintrittspunkte beinhaltet. Die Dienst-Eintrittspunkte beschreiben einen speziellen Dienstführer oder einen Gesamt-Dienstführer-Kanal. Die i-IMT beinhaltet Positionsinformationen von IP-Strömen in Turbo-Kanälen.
  • Eine Rundfunk-Empfangsvorrichtung bezieht die i-IMT von dem SCI. Die i-IMT enthält Positionsinformationen eines Kanals einschließlich des speziellen Dienstführers oder des Gesamt-Dienstführer-Kanals. Die Rundfunk-Empfangsvorrichtung greift auf Basis der in der i-IMT enthaltenen Positionsinformationen auf einen Turbo-Kanal zu.
  • In jedem der Turbo-Kanäle ist ein Signalisierungs-Teil-Datenkanal vorhanden, der Signalisierungsdaten überträgt, und eine IMT kann in dem Signalisierungs-Teil-Datenkanal vorhanden sein. Die IMT kann Positionsinformationen wenigstens eines Dienstführer-Ankündigungskanals aufweisen, der in einem entsprechenden Rundfunk-Kanal einem Dienstführer-Lieferkanal enthalten ist, sowie IP-Streams. Die Rundfunk-Empfangsvorrichtung bezieht einen Dienstführer auf Basis der in der IMT enthaltenen Positionsinformationen. Die Rundfunk-Empfangsvorrichtung kann auf einen bestimmten Dienst auf Basis der Informationen in dem Dienstführer zugreifen. Ein Verfahren, das es einem Benutzer gestattet, einen Dienst zu empfangen, wird weiter unten ausführlich unter Bezugnahme auf 66 beschrieben.
  • 66 stellt ein Verfahren zum Bereitstellen eines Dienstes unter Verwendung von MCAST, das OMA-BCAST unterstützt, gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Zunächst müssen, um OMA-BCAST zu unterstützen, ein Dienstführer(SG)-Ankündigungskanal und ein SG-Lieferkanal über mehr als einen Kanal geliefert werden. Die Rundfunk-Empfangsvorrichtung muss sequenziell auf den SG-Ankündigungskanal und den SG-Lieferkanal zugreifen. Der SG-Lieferkanal überträgt Fragmente eines Dienstführers, und der Dienstführer stellt Metadaten bereit, die sich auf Rundfunk- bzw. Broadcast-Dienste beziehen, beispielsweise eine Anordnung von Broadcast-Diensten. Der SG-Ankündigungskanal stellt Informationen zum Verarbeiten des SG-Lieferkanals bereit.
  • Die Rundfunk-Empfangsvorrichtung greift zunächst auf einen SIC zu, um einen Turbo-Kanal zu prüfen, über den der SG-Ankündigungskanal geliefert wird. Ein i-IMT beinhaltet die IP-Adresse des SG-Ankündigungskanals oder Positionsinformationen des SG-Ankündigungskanals oder eines Kanals, der IP-Streams enthält. Beispielsweise kann die i-IMT Zuordnungsinformationen zwischen der IP-Adresse des SG-Ankündigungskanals und der Nummer eines Turbo-Kanals beinhalten.
  • Die Rundfunk-Empfangsvorrichtung kann Informationen bezüglich des in der i-IMT enthaltenen Kanals anzeigen, so dass ein Benutzer einen spezifischen Kanal auswählen kann oder ein Ankündigungskanal beliebig als ein Standard ohne Benutzereingabe ausgewählt werden kann. Wenn der Benutzer den spezifischen Kanal auswählt, wird auf den ausgewählten Kanal unter Verwendung der IP-Adresse des ausgewählten Kanals und der in dem i-IMT enthaltenen Informationen zugegriffen. Auf diese Weise ist es möglich, dem Benutzer einen Dienstführer oder einen Dienst bereitzustellen.
  • In einem Turbo-Kanal ist ein Signalisierungs-Teil-Datenkanal vorhanden, der Signalisierungsdaten überträgt. In einem Signalisierungs-Teil-Datenkanal ist eine IMT, die Positionsinformationen von Streams beinhaltet, die über einen aktuellen Turbo-Kanal geliefert werden, vorhanden. Beispielsweise können Zuordnungsinformationen zwischen den IP-Adressen von IP-Strömen, die über einen aktuellen Turbo-Kanal geliefert werden, und einem Teil-Datenkanal enthalten sein.
  • Die Rundfunk-Empfangsvorrichtung kann die Positionsinformationen des SG-Ankündigungskanals aus der IMT beziehen. Auf einen Teil-Datenkanal, der den SG-Ankündigungskanal enthält, wird unter Verwendung der IP-Adresse des SG-Ankündigungskanals zugegriffen, die aus der i-IMT und der IMT bezogen wird. Die Rundfunk-Empfangsvorrichtung bezieht die Positionsinformationen des SG-Lieferkanals durch Verarbeiten des SG-Ankündigungskanals. Beispielsweise kann die IP-Adresse des SG-Lieferkanals durch Verarbeiten des SG-Ankündigungskanals bezogen werden. Da Zuordnungsinformationen zwischen IP-Adressen und Teil-Datenkanälen in der bereits bezogenen IMT vorhanden sind, greift die Rundfunk-Empfangsvorrichtung auf den SG-Lieferkanal unter Verwendung der IP-Adresse des SG-Lieferkanals und der IMT zu und bezieht einen Dienstführer von dem SG-Lieferkanal.
  • Der Dienstführer besteht aus Metadaten bezüglich eines Broadcast- bzw. Rundfunkdienstes, der bereitgestellt werden soll, wie beispielsweise einem ESG und einem EPG, wie dies oben beschrieben ist. Die Rundfunk-Empfangsvorrichtung kann einem Benutzer den Dienstführer so bereitstellen, dass der Benutzer einen gewünschten Rundfunkdienst auswählen kann oder kann einen Rundfunkdienst bereitstellen, der als Standard angegeben ist. Wenn der Benutzer einen gewünschten Rundfunkdienst auswählt, wird der ausgewählte Broadcast-Dienst unter Verwendung des Dienstführers bereitgestellt. Der Dienstführer kann beispielsweise die IP-Adressen von IP-Streams enthalten, die Dienste bereitstellen. Da die bereits bezogene IMT die Zuordnungsinformationen zwischen den IP-Adressen und den Teil-Datenkanälen enthält, wird ein IP-Stream unter Verwendung der IP-Adressen der IP-Streams, die Rundfunkdienste bereitstellen, die von dem Dienstführer bezogen werden und der IMT bezogen. Die Rundfunk-Empfangsvorrichtung stellt den ausgewählten Rundfunkdienst unter Verwendung des bezogenen IP-Stream bereit.
  • Eine OMA-BCAST-Dienstschicht wird im Folgenden kurz beschrieben.
  • Ein Dienstführer ermöglicht es, Dienste und Inhalte zu beschreiben, die von Service-/Content-Providem sowohl über einen Broadcast- bzw. Rundfunk-Kanal als auch einen interaktiven Kanal bereitgestellt werden oder über Abonnement oder Kauf bereitgestellt werden. Des Weiteren beschreibt der Dienstführer ein Verfahren des Zugreifens auf Dienste. Was den Endnutzer angeht, so ist der Dienstführer ein Zugangspunkt zum Auffinden von Diensten oder Inhalten, die aktuell genutzt werden können oder genutzt werden sollen. Des Weiteren stellt der Dienstführer einen Daten-Eintrittspunkt für einen beliebigen gerichteten Dienst bereit.
  • Der Dienstführer hat die folgenden Funktionen.
  • Zunächst erzeugt ein Dienstführer-Datenmodell einen Dienst, einen Plan, Inhalt, Datenbereitstellung bezüglich des Kaufens und Zugreifens und interaktive Daten in einer Dienstführer-Fragmentform.
  • Zweitens ermöglicht Auffindung des Dienstführers Auffindung eines Eintrittspunktes eines Anfangs-Bootstraps und des Dienstführers.
  • Drittens wird die Lieferung des Dienstführers nicht nur über einen optionalen interaktiven Kanal, sondern auch über einen Broadcast-Kanal durchgeführt.
  • Schließlich gewährleist Dienstführer-Aktualisierung, -Verwaltung und -Vollständigkeit, dass der Dienstführer aktuell und vollständig genug ist, um ihn einem Benutzer zur Betrachtung bereitzustellen.
  • Ein ATSC-M/H-Endgerät unterstützt die obligatorischen Teile des OMA-BCAST-Dienstführers für die Funktionalität des Dienstführers. Des Weiteren sind die mit interaktiven Verfahren, Lieferung und Nutzung des Dienstführers zusammenhängenden Teile in dieser Patentbeschreibung als optional zu interpretieren, und zwar selbst dann, wenn diese als obligatorisch angegeben werden.
  • Im Folgenden werden ein Übertragungsweg und Übertragung gemäß dem Datenformat beschrieben. Zuerst wird Echtzeit-A/V-Stream-Übertragung über Broadcasting beschrieben.
  • Um Echtzeit-Lieferung audiovisueller Broadcast-Dienste für ATSC-M/H zu realisieren, wird das RTP-UDP-Protokoll als Transportprotokoll angewendet. Die verschiedenen Audio- und Video-Formate kapseln zu RTP über spezifische RTP-Nutzinformations-Formate, die jeweils für einen spezifischen Codec definiert sind. Die Aspekte der Stream-Lieferung werden durch den optionalen Einsatz von Empfangs-Berichterstattung verbessert.
  • Das ATSC-M/H-Endgerät unterstützt die obligatorischen Teile von OMA-BCAST-Datei-und-Stream-Verteilung für die Echtzeit-Lieferung audio-visueller Ströme. Des Weiteren kann das Endgerät die dazugehörigen Liefervorgänge von OMA-BCAST-File-und-Stream-Verteilung unterstützen.
  • Im Folgenden wird Übertragung eines A/V-Streams, der über einen bidirektionalen Kanal angefordert wird, beschrieben.
  • Das RTP/UDP-Transportprotokoll wird auch für die Lieferung von audio-visuellen Streams über den interaktiven Kanal für On-Demand-Dienste angewendet. Da der interaktive Modus optional ist, kann das ATSC-M/H-Endgerät die interaktiven Teile von OMA-BCAST-Stream-Verteilung unterstützen, wie sie in der Patentbeschreibung angegeben sind.
  • Im Folgenden wird Nicht-Echtzeit-Übertragung von Inhalt über einen Broadcast-Kanal beschrieben.
  • Zu diesem Zweck wird, um die Lieferung von Nicht-Echtzeit-Inhalt über einen Broadcast-Kanal zu realisieren, FLUTE/UDP als Transportprotokoll angewendet. Die Robustheit der Datei-Lieferung kann auf zwei Wegen verbessert werden, d.h. durch Anwenden von Anwendungsschicht-FEC oder durch Anwenden von Post-Delivery(Fehlerfcorrektur)-Prozeduren, die über einen optionalen Rückkanal arbeiten.
  • Das ATSC-M/H-Endgerät unterstützt die obligatorischen Teile der Spezifikation von OMA-BCAST-Datei-und-Stream-Verteilung (OMA BCAST File and Stream Distribution) für die Nicht-Echtzeit-Lieferung von Inhalt. Des Weiteren kann das Endgerät die dazugehörigen Liefervorgänge von OMA-BCAST-Datei-und-Stream-Verteilung unterstützen.
  • Im Folgenden wird Nicht-Echtzeit-Übertragung von Inhalt über einen interaktiven Kanal beschrieben. Da der interaktive Modus optional ist, kann das ATSC-M/H-Endgerät die interaktiven Teile von OMA-BCAST-Datei-Verteilung unterstützen, wie sie in der Spezifikation angegeben sind. Es ist anzumerken, dass in diesem Fall nur die obligatorischen Teile der Spezifikation unterstützt werden.
  • Als letztes unterstützt das ATSC-M/H-Endgerät Zusatzdaten, Werbung und Benachrichtigung wie sie in der Spezifikation definiert sind.
  • Schutz eines Dienstes und von Inhalt über OMA-BCAST wird im Folgenden beschrieben.
  • 67 stellt schematisch die Struktur von vier Schichten zum Schutz eines Dienstes und Inhaltes gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Zum Schutz des Dienstes werden zwei Schlüssel-Verwaltungssysteme (KMS) unterstützt. Eines der beiden KMS ist endgerät-basiertes KMS (DRM-Profil), das Schlüssel-Verwaltung darstellt, die durch ein Endgerät durchgeführt wird. Das andere KMS ist smartcard-basiertes KMS (Smartcard-Profil), das mittels (U)SIM oder (R)UIM/CSIM durchgeführt wird.
  • Ein ATSC-M/H-Endgerät kann die beiden KMS unterstützen, jedoch möglicherweise auch keines von ihnen unterstützen.
  • Wenn das ATSC-M/H-Endgerät endgerät-basiertes KMS unterstützt, unterstützt es die obligatorischen Teile des in den Spezifikationen definierten DRM-Profils.
  • Wenn das ATSC-M/H-Endgerät smartcard-basiertes KMS unterstützt, unterstützt es die obligatorischen Teile des Smartcard-Profils, wie sie in den Spezifikationen definiert sind.
  • Beide oben aufgeführten KMSs gewährleisten hohe Sicherheit für den Schutz von Mobilgeräte-Diensten, und sie können gleichzeitig eingesetzt werden.
  • Die vier Schichten werden im Folgenden unter Bezugnahme auf 59 beschrieben.
  • Eine Verkehrs-Schicht verwendet IPsec, SRTP oder ISMAcryp als ein Verkehrs-Kryptogramm.
  • IPsec ist eine kapselnde Sicherheits-Nutzinformation (ESP) und verwendet AES-128-cbc mit explizitem IV als einen Verschlüsselungsalgorithmus in jedem IP-Paket. Authentifizierung ist optional und verwendet HMAC-SHA-1-96.
  • SRTP verwendet AES-128-CTR als einen Verschlüsselungsalgorithmus. Authentifizierung ist optional und verwendet HMAN-SHA-1-80.
  • ISMACryp 1.1 mit OMA-BCAST spezifiziert Erweiterungen für Codec-Agnostizismus. AES-BYTE-CTR wird als ein Verschlüsselungsalgorithmus verwendet. Authentifizierung ist optional und verwendet HMAC-SHA1.
  • Eine Schlüsselverwaltungs-Schicht, eine Rechteverwaltungs-Schicht und eine Registrierungsschicht für das DRM-Profil unter Verwendung von Microsoft PlayReady sind in den Spezifikationen spezifiziert.
  • Eine Schlüsselverwaltungs-Schicht, eine Rechteverwaltungs-Schicht und eine Registrierungsschicht für das DRM-Profil unter Verwendung von OMA DRM 2.0 sind in den Spezifikationen spezifiziert.
  • Eine Schlüsselverwaltungs-Schicht, eine Rechteverwaltungs-Schicht und eine Registrierungsschicht für ein Smartcard-Profil sind in den Spezifikationen spezifiziert.
  • Ein Endgerät, das Interaktivität unterstützt, kann entweder DRM-Profil oder Smartcard-Profil oder beide unterstützen. Bei dem DRM-Profil wird die Lieferung von langfristigen Schlüsselnachrichten (long-term key messages - LTKMs) über einen interaktiven Kanal unterstützt, und die Lieferung von LTKM über einen Broadcast-Kanal kann unterstützt werden.
  • Ein Endgerät, das Interaktivität nicht unterstützt, kann das DRM-Profil unterstützen. Lieferung von LTKM über einen Broadcast-Kanal wird unterstützt.
  • Ein ATSC-M/H-Endgerät kann Inhaltsschutz unterstützen. Wenn das ATSC-M/H-Endgerät Inhaltsschutz unterstützt, unterstützt es entweder Microsoft PlayReady oder OMA DRM v2.0 oder beide.
  • Ein MCAST-System gemäß einer Ausführungsform der vorliegenden Erfindung ermöglicht optionale Unterstützung für einen interaktiven Kanal. Die Unterstützung interaktiver Merkmale ist optional für das ATSC-M/H-Endgerät. Wenn jedoch das ATSC-M/H-Endgerät interaktive Merkmale unterstützt, unterstützt das Endgerät die Spezifikation von OMA-BCAST 1.0 für Adress-Interaktivität. Für diese Spezifikationen werden die obligatorischen Teile unterstützt. Aspekte der Darstellungsschicht von ATSC-M/H gemäß einer Ausführungsform der vorliegenden Erfindung werden im Folgenden beschrieben.
  • In Bezug auf Video-Codec unterstützt ein ATSC-M/H-Endgerät den Video-Codec H.264/AVC. Des Weiteren unterstützt das ATSC-M/H-endgerät wenigstens eine der folgenden fünf Fähigkeiten:
    • Decodieren von Bitstreams, die H.264/AVC Level 1b des Basis-Profils entsprechen, mit einem ‚constraint_set1_flag‘-Feld, dessen Wert ‚1‘ ist;
    • Decodieren von Bitstreams, die H.264/AVC Level 1.2 des Basis-Profils entsprechen, mit einem ‚constraint_set1_flag‘-Feld, dessen Wert ‚1‘ ist;
    • Decodieren von Bitstreams, die H.264/AVC Level 2 des Basis-Profils entsprechen, mit einem ‚constraint_set1_flag‘-Feld, dessen Wert gleich ‚1‘ ist;
    • Decodieren von Bitstreams, die H.264/AVC Level 3 des Basis-Profils entsprechen, mit einem ‚constraint_set1_flag‘-Feld, dessen Wert ‚1‘ ist; und
    • Decodieren von Bitstreams, die H.264/AVC Level 4 des Basis-Profils entsprechen, mit einem ‚constraint_set1_flag‘-Feld, dessen Wert ‚1‘ ist.
  • Das ATSC-M/H-Endgerät kann optional mehr als eine dieser Fähigkeiten unterstützen, sowie eine Fähigkeit, die das Decodieren von Stufen und Profilen unterstützt, die höher sind als die durch diese Fähigkeit erforderten.
  • In Bezug auf eine Frame-Rate decodiert das ATSC-M/H-Endgerät alle Frame-Raten, die durch das H.264/AVC-Profil zugelassen werden, sowie Stufen, die mit der implementierten Fähigkeit verbunden sind. Die Frame-Raten können variable Frame-Raten einschließen.
  • Decoder sind nicht erforderlich, um Bitstreams zu decodieren, wenn der maximale Abstand zwischen zwei Bildern 0,7 Sekunden übersteigt.
  • Was ein Seitenverhältnis angeht, decodiert das ATSC-M/H-Endgerät alle Seitenverhältnisse, die das H.264/AVC-Profil zulässt, und eine Stufe, die mit der implementierten Fähigkeit zusammenhängt.
  • Was die Luminanzauflösung angeht, decodiert das ATSC-M/H-Endgerät jede Luminanzauflösung, die von dem H.264/AVC-Profil zugelassen wird, und eine Stufe, die mit der implementierten Fähigkeit zusammenhängt.
  • In Bezug auf den Farbwert (chromacity) decodiert das ATSC-M/H-Endgerät jeden zulässigen Wert von Farb-Grundwerten (colour_primaries), Übertragungscharakteristiken und Matrixkoeffizienten.
  • In Bezug auf das Chrominanz-Format decodiert das ATSC-M/H-Endgerät jeden zulässigen Wert eines chroma_sample_loc_type_top-Feldes und eines chroma_sample_loc_type_bottom-Feldes.
  • Bezüglich des Audio-Codec unterstützt das ATSC-M/H-Endgerät entweder HE-AAC-v2 oder AMR-WB+ (Extended AMR-WB) oder beide.
  • Zunächst wird HH AAC v2 beschrieben. Das ATSC-M/H-Endgerät unterstützt mono-/parametrisches Codieren oder eine Zwei-Kanal-Stereo-Funktion, wie sie im HE-AAC-v2-Profil, Stufe 2 definiert ist. Das ATSC-M/H-Endgerät kann optional Decodieren von Multikanal-Audio unterstützen, das im HE-AAC-v2-Profil, Stufe 4 definiert ist.
  • Bezüglich der Profile unterstützt das ATSC-M/H-Endgerät das HE-AAC-v2-Profil. Optional unterstützt das ATSC-M/H-Endgerät Decodieren des HE-AAC-Profils. In Bezug auf die Bitrate unterstützt das ATSC-M/H-Endgerät jede beliebige Bitrate, die durch das HE-AAC-v2-Profil zugelassen wird und eine ausgewählte Stufe.
  • In Bezug auf die Abtastfrequenz decodiert das ATSC-M/H-Endgerät jede Audio-Abtastrate, die durch das HE-AAC-v2-Profil und die ausgewählte Stufe zugelassen wird.
  • In Bezug auf die Dynamikregelung unterstützt das ATSC-M/H-Endgerät das Dynamikregelungs-Werkzeug MPEG-4-AAC.
  • Was das Downmixing angeht, unterstützt das ATSC-M/H-Endgerät das Matrix-Downmixing, wie es in MPEG-4 definiert ist.
  • AMR-WB wird im Folgenden beschrieben.
  • In Bezug auf einen Audio-Modus führt das ATSC-M/H-Endgerät Decodieren in Mono- und Stereo durch, wobei die Funktionalität in AMR-WB+ definiert ist.
  • In Bezug auf die Abtastfrequenz ist das ATSC-M/H-Endgerät in der Lage, jede Audio-Abtastrate zu decodieren, die durch AMR-WB+ für Mono und Stereo zugelassen wird.
  • Was die Untertitelung angeht, so kann das ATSC-MIH-System Untertitel und Untertitel für Hörgeschädigte unter Verwendung des 3GPP-Timed-Text-Formats bereitstellen. Das ATSC-M/H-Endgerät sollte das 3GPP-Timed-Text-Format für Untertitel und Untertitel für Hörgeschädigte unterstützen.
  • 68 stellt einen Energieverwaltungsmechanismus gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Im Allgemeinen sind kritische Einrichtungen für den Energieverbrauch ein Anzeigebildschirm, wie beispielsweise eine Flüssigkristallanzeige, und ein Funkfrequenz(HF)-Modul. In diesem Abschnitt wird ein Stromsparmechanismus auf Basis von RF-Modul-Steuerung beschrieben.
  • In einem allgemeinen Rundfunk- bzw. Broadcast-System muss ein HF-Modul angeschaltet werden und alle Eingangs-Rahmen überwachen, um einen gewünschten Rahmen zu ermitteln. In ATSC-MCAST werden alle Turbo-Dienste gruppiert und einer Sequenz-Gruppe von Rahmen zugeordnet, und Informationen bezüglich der Rahmen, beispielsweise der Positionen und der Zahl des Rahmens, werden über einen SIC geliefert. Anhand der gelieferten Informationen kann eine Rundfunk-Empfangsvorrichtung zwischen einer Ruheperiode und einer Arbeitsperiode unterscheiden.
  • 68 stellt Beispiele von MCAST-Frame-Slicing und Rahmen-Nummern dar, die dazu dienen, einen Dienst zu identifizieren. Wenn beispielsweise ein Benutzer-Programm Nr. 1 auswählt, kann das HF-Modul so arbeiten, dass Rahmen Nr. 1 bis Nr. 4 aus HF-Rahmen-Gruppen empfangen werden. Das heißt, eine Transportschicht weist eine physikalische Schicht an, die Rahmen Nr. 1 bis Nr. 4 zu empfangen. Die Nummer der HF-Rahmen-Gruppen und die Dauer des Frame-Slicing können variieren, und Informationen bezüglich einer Änderung derselben werden über den SIC übertragen.
  • Eine feste Anzahl von MCAST-Paketen sind Burst-Einheiten. Die Anzahl von MCAST-Paketen variiert entsprechend der Funktion eines Turbocodier-Modus. Die Anzahl von MCAST-Paketen kann sich bei jedem Burst ändern.
  • 69 ist ein Diagramm, das Parameter darstellt, die sich auf MCAST-Frame-Slicing gemäß einer Ausführungsform der vorliegenden Erfindung beziehen.
  • Ein Verfahren zum Übertragen von Daten gemäß einem Burst-Übertragungsverfahren wird im Folgenden beschrieben.
  • 69 stellt Parameter dar, die für Time-Slicing verwendet werden. Die Definition der Parameter ist wie folgt: [Tabelle 19]
    Parameter Beschreibung
    Bp Burst-Periode (Rahmen)
    Bd Burst-Dauer (Rahmen)
    Ot Aus-Zeit (Rahmen)
    Bs Burst-Größe (Block)
    Bb Burst-Bandbreite (Block/Rahmen)
    Cb Konstante Bandbreite (Block/Rahmen)
  • Die Beziehung zwischen Parametern Bd, Bb, Bp und Cb wird als ‚Bd × Bb= Bp × Cb‘ ausgedrückt.
  • 70 ist ein Diagramm, das Parameter darstellt, die sich auf Stromsparen gemäß einer Ausführungsform der vorliegenden Erfindung beziehen. Es sind drei Stufen erforderlich, um einem Kanal mehrere Burst-Dienste zuzuweisen. Zunächst muss eine vorgegebene Bandbreite für jeden der Dienste unter Verwendung der folgenden Gleichung (3) berechnet werden. In Gleichung (3) bezeichnet ‚Tc‘ eine Turbo-Codierrate, beispielsweise 1/2, 1/3 oder 1/4. Cb n = 32 × 8 × 78 24.2 ( ms ) × 188 208 × Tc
    Figure DE112008000552B4_0003
  • Zweitens wird jeder der Dienste der vorgegebenen Bandbreite zugeordnet.
  • 71 ist ein Diagramm, das ein Verfahren gemäß einer Ausführungsform der vorliegenden Erfindung darstellt, mit dem jeder Dienst einer vorgegebenen Bandbreite für Burst-Modus-Übertragung zugewiesen wird. Eine Gesamt-Bandbreite wird berechnet durch: CbToT = Cb 1 + Cb 2 + … + CbN .
    Figure DE112008000552B4_0004
  • Drittens müssen Dienste Nr. 2 bis Nr. 3 um 90 Grad im Uhrzeigersinn oder entgegen dem Uhrzeigersinn gedreht werden.
  • 72 ist ein Diagramm, das Drehung von Diensten für Burst-Modus-Übertragung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • AL-FEC gemäß einer Ausführungsform der vorliegenden Erfindung wird im Folgenden beschrieben.
  • In Bezug auf Codieren ist MCAST AL-FEC ein verknüpfter Code aus zwei linearen Blockcodes. Ein innerer und ein äußerer Code sind als Generator-Matrizen oder äquivalent als Graphen definiert. Ein innerer und ein äußerer Code weist beispielsweise einen Nachrichtencode (u1, u2) auf. u1 und u2 stellen jeweils einen Bitstream mit einer Länge L dar, die größer ist als ‚1‘. Desgleichen wird das Codewort in dem Code als (v1, v2, v3, v4, v5, v6) ausgedrückt, und vi{i=1,...6} ist ein Bitstream mit einer Länge L.
  • Wenn eine in Gleichung (5) dargestellten Matrix G gegeben ist, wird das Nachrichtenwort (u1, u2) zu einem Codewort (v1, v2, v3, v4, v5, v6) durch v1 = u1, v2 = u1(+)u2, v3 = u1(+)u2, v4 = u2, v5 = u1 und v6 = u2 codiert. Der obenstehende Operator (+) kennzeichnet einen XOR(exclusive-OR)-Bitstream. G = 1 2 3 4 5 6   v u [ 1 1 1 0 1 0 0 1 1 1 0 1 ]   1 2
    Figure DE112008000552B4_0005
  • Da die Länge des Codeworts dreimal größer ist als die Länge des Nachrichtenworts, beträgt eine Coderate 1/3. Die Generator-Matrix kann herkömmlicherweise durch einen Graphen ausgedrückt werden.
  • 73 ist ein Graph, der eine Generator-Matrix gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Der Graph in 73 stellt die in Gleichung (5) dargestellte Matrix G dar. Die Beschreibung des Graphen ist äquivalent zu der einer Generator-Matrix. Jede Spalte in dem Graphen entspricht einem Codewort-Knoten (v1, i = 1, ...,6) während jede Reihe für einen Nachrichtencode (u1, u2) steht. Der Wert in der x-ten Reihe und der y-ten Spalte der Matrix G bedeutet die Linie zwischen ux und vy in dem Graphen. Der Grad eines Knotens (u oder v) stellt die Anzahl von Linien dar, die mit dem Knoten verbunden sind und wird als deg(u oder v) bezeichnet. Beispielsweise ist deg(u1) 4 und deg(v3) ist 2. Die Generator-Matrix ist ein wichtiges Element, das ordnungsgemäß konstruiert werden muss.
  • Die Konstruktion einer Generator-Matrix wird im Folgenden beschrieben.
  • Es wird angenommen, dass die Anzahl von Nachrichten-Knoten k ist und die Anzahl von Code-Knoten n ist. Eine Code-Rate ist k/n. Ein Nachrichten-Wort wird durch (u1, u2, ....., uk) dargestellt und ein Codewort wird durch (v1, v2, ....., vn) dargestellt. Zunächst wird ein Graph konstruiert, und eine Generator-Matrix wird über eine Transformation eines Graphen gewonnen. Ein Graph wird in zwei Schritten erzeugt. Der erste Schritt besteht darin, den Grad von Codewort-Knoten (deg(vi)) zu bestimmen. Der zweite Schritt besteht darin, Nachrichten-Knoten und Codewort-Knoten zu verbinden.
  • Das heißt, im ersten Schritt sind k Nachrichten-Knoten und n alc Codewort-Knoten gegeben, und der Grad von Codewort-Knoten (deg(vi)) wird wie folgt bestimmt.
    1. 1. Bestimmen von dMax aus einem Konstruktionsparameter Δ. Δ ist ein integraler Wert von 1 bis 16. dMax wird durch den Wert des Konstruktionsparameters Δ spezifiziert. Wenn beispielsweise Δ ‚8‘ ist, ist dMax ‚61‘.
    Tabelle 20
    Δ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
    dmax 917 388 231 158 117 91 74 61 52 44 38 34 30 27 24 22
    • 2. Bestimmen eines Feldes integraler Werte, {N[i] | i = 1, 2, ..., dMax}, und zwar wie folgt:
      • wenn ein äußerer Code konstruiert wird, N[1]=n und N[i]=0 (i=2, ...., dMax),
      • wenn ein Zwischencode konstruiert wird, N [ 1 ] = ⌊ n ⋅ 2 ⋅ Δ ⋅ d M a x − 100 d M a x ( 100 + 2 ⋅ Δ ) ⌋
        Figure DE112008000552B4_0006
         N [ i ] = ⌊ n ⋅ 100 100 + 2 ⋅ Δ ⋅ d M a x + 1 d M a x − 1 ⋅ 1 i ⋅ ( i − 1 ) ⌋ ,   i = 3, … , d M a x
        Figure DE112008000552B4_0007
         N [ 2 ] = n − N [ 1 ] − ∑ i = 3 d M a x N [ i ]
        Figure DE112008000552B4_0008
      wobei [x] eine größte positive ganze Zahl kennzeichnet, die kleiner oder gleich x ist.
    • 3. Bestimmen der Grade jedes Codewort-Knotens (deg(v1,), deg(v2), ...,deg(vn)) gemäß dem in 63 dargestellten Flussdiagramm.
  • 74 ist ein Flussdiagramm, das ein Verfahren zum Bestimmen von deg(Vi) gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang 7410 werden ganzzahlige Variablen (k1, k2, ...,km) auf ‚0‘ initialisiert, d. h. k1 = k2 =...= km = 0, wobei m eine größte ganze Zahl bezeichnet, so dass N[m] nicht Null ist. Die andere ganzzahlige Variable wird auf ‚1‘ eingestellt.
  • In Vorgang S7420 wird ein Index a, wie beispielsweise a = arg i min i = 1, … , m k i N [ i ]
    Figure DE112008000552B4_0009
    bestimmt.
  • Wenn eine Vielzahl minimaler Werte vorhanden sind, wird eine Gruppe von Indizes {a, b, ..., c} bestimmt.
  • In Vorgang S7430 ist der Grad von vj a, und j wird um 1 erhöht. Des Weiteren ist der Grad von vj b und j wird um 1 erhöht. Dieser Vorgang wird wiederholt, bis alle Indizes verwendet worden sind.
  • In Vorgang S7440 werden nur Variablen (ka, kb, ..., kc) um 1 erhöht, die in der Gruppe von Indizes {a, b, ..., c} spezifiziert werden.
  • In Vorgang S7450 wird geprüft, ob alle Grade (deg(vj), j=1, ...,n) bestimmt sind. Wenn nicht alle von ihnen bestimmt sind, wird Vorgang S7420 wiederholt.
  • In dem zweiten Schritt sind k Nachrichten-Knoten und n Codewort-Knoten gegeben, die Grade von Codewort-Knoten sind deg(vi), und Nachrichten-Knoten, die mit einem Codewort-Knoten verbunden sind, werden entsprechend dem Flussdiagramm in 64 geprüft.
  • 75 ist ein Flussdiagramm, das eine Verbindung von Nachrichten-Knoten mit einem Code-Knoten gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S75190 wird eine Index-Variable j eines Codewort-Knotens vj so initialisiert, dass sie ‚1‘ ist.
  • In Vorgang S7520 wird eine Gruppe von Nachrichten-Knoten-Indizes {a, b, ..., c} ermittelt, die mit dem Codewort-Knoten vj verknüpft werden soll. Die Anzahl von Elementen ([{a, b, ..., c}]) in dieser Gruppe sollte dem Grad von vj, deg(vj) gleich sein.
  • In Vorgang S7530 werden Nachrichten-Knoten identifiziert, die mit dem Codewort-Knoten vj mit {ua, ub, ..., uc} verbunden werden sollen.
  • In Vorgang 7540 werden die oben beschriebenen Vorgänge für alle Codewort-Knoten wiederholt.
  • 76 ist ein Flussdiagramm, das ausführlich Vorgang 7520 aus 75 gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S7610 werden Indexgruppen U und S von Nachrichten-Knoten jeweils auf {1,...,k} und {} initialisiert. Die Gruppen U und S sind der Reihenfolge nach geordnete Gruppen und die Reihenfolge wird wie folgt definiert. Wenn das x-te Element a und das y-te Element b in der Gruppe U oder S gegeben sind, und x < y, dann gilt a < b und umgekehrt. Diese Initialisierung wird nur einmal vor jedem Aufruf dieser Prozedur durchgeführt.
  • In Vorgang S7620 wird nach Ermitteln eines Pseudozufallswertes x in {1, ..., |U|} der Nachrichten-Knoten-Index, der zurückgeführt werden soll, durch das x-te Element in der Gruppe U ermittelt, wobei |U| die Anzahl aller Elemente in der Gruppe U angibt. Dann verschiebt sich dieses Element von der Gruppe U in die Gruppe S. Auf diese Weise sind alle zuvor ausgewählten Nachrichten-Knoten-Indexwerte in der Gruppe S enthalten, während die anderen nicht ausgewählten Werte in der Gruppe U verbleiben.
  • In Vorgang S7630 wird festgestellt, ob die Gruppe U eine leere Gruppe ist. Wenn die Gruppe U leer ist, wird Vorgang S7630 durchgeführt, um die Gruppen S bzw. U auf {1, ..., k} und {} zu initialisieren.
  • Ein Vorgang zum Ermitteln einer Nachrichten-Knoten-Indexnummer x in {0, ..., |U|} ist in 76 nicht spezifiziert. Dieser Vorgang wird mittels Mersenne-Twister (MT) durchgeführt, bei dem es sich um einen Pseudozufallszahl-Erzeugungsalgorithmus handelt, der 1996/97 von Makoto Matsumoto und Takuji Nishimura entwickelt und 2002 verbessert wurde. Es steht der Standard-C-Code der Erfinder zur Verfügung, der für jeden beliebigen Zweck einschließlich der kommerziellen Nutzung frei verfügbar ist.
  • Bevor eine Prozedur aufgerufen wird, wird Mersenne-Twister (MT) von einer ganzen 32-Bit-Initialzahl ohne Vorzeichen initialisiert. Um eine Nachrichten-Knoten-Indexnummer x in {1, ..., |U|} zu ermitteln, wird dann eine ganze 32-Bit-Zahl ohne Vorzeichen erzeugt, eine minimale ganze Zahl e, wie beispielsweise |U| <= 2e wird ermittelt, höchstwertige e-Bits werden ermittelt und die vorangegangene Prozedur wird verworfen und wiederholt, wenn die Zahl größer ist als oder genauso groß wie |U|. Wenn die Zahl kleiner ist als |U|, ist die Nachrichten-Knoten-Indexzahl x die Zahl +1, die in {1, ..., |U|} liegt.
  • Ein Verfahren zum Konstruieren einer Generator-Matrix wird im Folgenden beschrieben.
  • Jede Spalte entspricht einem Codewort-Knoten (vi, i = 1, ..., n) in einem Graph, und jede Reihe steht für einen Nachrichten-Knoten (ul, i = 1, ..., k). Wenn ux mit vy in dem Graphen verbunden ist, ist das Element in der x-ten Reihe und der y-ten Spalte in der Generator-Matrix ‚1‘. Wenn keine Verbindung vorliegt, ist das Element Null.
  • Vorkonstruierte AL-FEC-Codes werden im Folgenden beschrieben.
  • Um einen MCAST-AL-FEC-Code zu definieren, werden zwei Matrizen definiert. Eine von ihnen ist für den inneren Code bestimmt und die andere für den äußeren Code.
  • Wenn ein (n, k)-MCAST-AL-FEC-Code gegeben ist, ist der innere Code ein (n, k + δk)-Code, und der äußere Code ist ein (k + δk, k)-Code. k + δk ist die Anzahl von Codewort-Knoten in dem äußeren Code und von Nachrichten-Knoten in den inneren Codes.
  • Um deg(vj) in dem inneren Code zu definieren, muss ein Konstruktionsparameter Δ vorhanden sein.
  • Um die Verbindung zwischen uj und vj in dem inneren und dem äußeren Code zu definieren, muss eine Zufalls-Initialzahl für die Mersenne-Twister-Prozedur bereitgestellt werden. Diese Initialzahl wird sowohl für den inneren als auch den äußeren Code verwendet.
  • So reichen die drei Parameter δk, Δ und Initialzahl aus, um einem MCAST-AL-FEC-Code zu definieren. Für die drei verschiedenen (n, k)-MCAST-AL-FEC-Codes sind diese Parameter im Folgenden aufgelistet: [Tabelle 21]
    (n, k) δk, Δ, Initialzahl
    (2880, 2304) (10, 6,14)
    (1920, 1536) (3, 8, 6)
    (960, 768) (1, 8, 8)
  • 77 ist ein Blockschaltbild einer MCAST-Rundfunk-Empfangsvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung. Wie unter Bezugnahme auf 77 zu sehen ist, enthält die Rundfunk-Empfangsvorrichtung eine Signalisierungsinformations-Extrahiereinrichtung 7701, eine Datenbezugseinheit 7702 und eine Datenverarbeitungseinheit 7703.
  • Die Signatisierungsinformations-Extrahiereinrichtung 7701 bezieht Signalisierungsinformationen, die erforderlich sind, um einen Transport-Kanal zu verarbeiten. Die Signalisierungsinformationen können über einen Transport-Kanal, wie beispielsweise einen SIC, geliefert werden. Die Signalisierungsinformationen können wenigstens Konfigurationsinformationen bezüglich eines ATSC-M/H-Stream, Fehlerkorrekturinformationen bezüglich des Transport-Kanals oder Konfigurationsinformationen des Transport-Kanals enthalten, die erforderlich sind, um den Transport-Kanal zu verarbeiten.
  • Die Signalisierungsinformationen können kontinuierlich oder diskontinuierlich in einem normalen ATSC-Stream integriert und dann übertragen werden. Die Signalisierungsinformationen sind an einer vorgegebenen Position eines Rahmens enthalten, oder Positionsinformationen der Signalisierungsinformationen sind an der vorgegebenen Position des Rahmens enthalten, so dass Signalisierungsinformations-Extrahiereinrichtung 7701 die Position der Signalisierungsinformationen erkennen kann. Des Weiteren kann die Position der Signalisierungsinformationen angezeigt werden, indem ein spezifischer Bitstrom innerhalb oder außerhalb eines Kanals integriert wird, der die Signalisierungsinformationen überträgt.
  • Signalisierungsinformationen sind wichtige Informationen, da sie Informationen enthalten, die erforderlich sind, um andere Transport-Kanäle zu verarbeiten, und so zusätzlichen Code zur Fehlerkorrektur enthalten können. Die Signalisierungsinformationen können innerhalb des Bandes oder außerhalb des Bandes übertragen werden oder über eine spezifische Position eines Transport-Streams übertragen werden.
  • Die Datenbezugseinheit 7702 bezieht über den Transport-Kanal übertragene Pakete. Der Terminus ‚Transport-Kanal‘, der in der vorliegenden Patentbeschreibung verwendet wird, weist eine weitere Definition auf, als sie in einem allgemeinen Broadcasting- bzw. Rundfunksystem verwendet wird. Das heißt, der Terminus ‚Transport-Kanal‘ gemäß der vorliegenden Erfindung enthält einen Stream, der geliefert wird und dabei in einem anderen Transport-Stream enthalten ist. Beispielsweise ist es möglich, einen normalen ATSC-Stream (MPEG-2 TS) zu übertragen, indem ein MPEG-2-TS-Stream oder ein anderer Typ von Transport-Stream in diesen über eine zusätzliche Anzeige in dem normalen ATSC-Stream integriert wird. In der aktuellen Ausführungsform bezieht die Rundfunk-Empfangsvorrichtung Daten durch Verarbeiten eines Transport-Streams, der in einem normalen Stream enthalten ist. Daten können entsprechend einem vorgegebenen Verfahren oder unter Verwendung der oben beschriebenen Signalisierungsinformationen bezogen werden, die über einen spezifischen Kanal, wie beispielsweise einen SIC, übertragen werden. Ein Transport-Stream gemäß der vorliegenden Erfindung, der von einem Mobil-Endgerät empfangen werden soll, wird in einen anderen Transport-Stream eingefügt, oder Informationen, die diese Einfügung anzeigen, werden über einen SIC übertragen. Beispielsweise ist ein Transport-Stream in einem MPEC-2-TS-Nullpaket-Bereich oder in einem privaten Datenfeld eines MPEG-2-TS enthalten.
  • Wenn ein Transport-Stream gemäß der vorliegenden Erfindung, der von einem Mobil-Endgerät empfangen werden soll, in einen anderen Transport-Stream eingefügt wird (oder zu ihm hinzugefügt wird), kann/können auch ein zusätzlicher Header oder Anzeigeinformationen enthalten sein, um den eingefügten oder hinzugefügten Stream zu verarbeiten. Beispielsweise kann eine Kombination von Informationen bezüglich der Anfangs- und der Endposition des hinzugefügten Stream, Informationen bezüglich der Länge des hinzugefügten Stream, Informationen, die anzeigen, ob der hinzugefügte Stream vorhanden ist, und anderen Informationen enthalten sein, die benötigt werden, um den hinzugefügten Stream zu verarbeiten.
  • Die Datenbezugseinheit 7702 kann, obwohl in den Zeichnungen nicht dargestellt, eine Metainformations-Ausgabeeinheit sowie eine Transport-Kanal-Zugriffseinheit enthalten.
  • Die Metainformations-Ausgabeeinheit gibt Metadaten bezüglich eines bereitgestellten Broadcast-Dienstes aus. Die Metadaten stellen Informationen bezüglich des bereitgestellten Broadcast-Dienstes bereit, so beispielsweise einen ESG, einen EPG oder einen OMA-BCAST-Dienstführer. Die Metadaten können Informationen enthalten, die erforderlich sind, um ein Transportpaket zu verarbeiten. Für SDP-Daten zum Verarbeiten von IP-Strömen können beispielsweise ebenfalls in den Metadaten enthalten sein. Informationen, die die Position des Transport-Kanals anzeigen, der IP-Streams enthält, können ebenfalls in den Metadaten enthalten sein. Das heißt, verschiedene Informationen bezüglich des Dienstes können als Metadaten betrachtet werden. Im Folgenden wird die vorliegende Erfindung in Bezug auf einen OMA-BCAST-Dienstführer als ein Beispiel für Metadaten beschrieben. Ein Dienstführer muss bezogen werden, indem sequenziell auf einen Dienstführer-Ankündigungskanal und einen Dienstführer-Lieferkanal zugegriffen wird, um einen Dienst entsprechend OMA-BCAST bereitzustellen. Ein Transport-Kanal, der einen Dienstführer-Ankündigungskanal überträgt, kann in einem i-IMT in einem SIC spezifiziert werden, wie dies oben beschrieben ist. So bezieht die Metainformations-Ausgabeeinheit Metadaten bezüglich eines Dienstes, der über den Transport-Kanal bereitgestellt wird, aus der i-IMT und gibt sie anschließend aus.
  • Wenn ein MCAST-Übertragungssystem schnellen Zugriff, wie z.B. durch den oben beschriebenen primären Dienst unterstützt, ist es möglich, einen primären Dienst simultan zum Beziehen von Metadaten bereitzustellen.
  • Die Transport-Kanal-Zugriffseinheit greift auf einen Transport-Kanal zu, der einen von einem Benutzer ausgewählten Broadcast-Dienst bereitstellt. Als Alternative dazu kann ein Transport-Kanal automatisch von der Rundfunk-Empfangsvorrichtung oder einem Broadcast-Dienstprovider ausgewählt werden.
  • Wenn der Transport-Kanal ausgewählt wird, werden Daten bezogen, die über den Transport-Kanal übertragen werden. Die über den Transport-Kanal übertragenen Daten können in Paket-Einheiten, Bytestream-Einheiten oder Bitstream-Einheiten konstruiert sein. Fehlerschutz-Code kann zu Daten hinzugefügt werden, um einen Fehler darin zu korrigieren. In diesem Fall wird der Fehler unter Verwendung des Fehlerschutz-Codes korrigiert. Die über den Transport-Kanal übertragenen Daten können, wie oben beschrieben, an einer bestimmten Position oder einer einem SIC bekannten Position vorhanden sein, und die Transport-Kanal-Zugriffseinheit kann alle diese Informationen verarbeiten. Gemäß einer anderen Ausführungsform der vorliegenden Erfindung kann jedoch die Verarbeitung dieser Informationen durch die Datenbezugseinheit 7703 durchgeführt werden.
  • Die Datenverarbeitungseinheit 7703 verarbeitet bezogene Daten. Die Daten können in Paket-Einheiten, Bytestream-Einheiten oder Bitstream-Einheiten verarbeitet werden. Wenn die Daten in Paket-Einheiten verarbeitet werden, ist ein Header in jedem der Pakete vorhanden. Jeder Header beinhaltet die Konfigurationsinformationen eines Paketes, und die ursprünglichen Daten werden auf Basis der Konfigurationsinformationen wiederhergestellt.
  • Das heißt, das MCAST-Übertragungssystem gemäß der aktuellen Ausführungsform fragmentiert Anwendungsdaten in Kapselungspakete und segementiert die Kapselungspakete in Transportpakete. In diesem Fall stellt die Datenverarbeitungseinheit 7703 die Kapselungspakete unter Verwendung der Header-Informationen der Transportpakete wieder her und stellt die ursprünglichen Anwendungsdaten unter Verwendung der Header-Informationen der Kapselungspakete wieder her.
  • Gemäß einer anderen Ausführungsform der vorliegenden Erfindung können Daten in Paket-Strömen verarbeitet werden. In diesem Fall werden die Konfigurationsinformationen bezüglich der Paket-Streams, beispielsweise der oben beschriebenen LMT, bezogen und dann werden die Daten ermittelt, indem die in den Paket-Streams enthaltenen Pakete verarbeitet werden.
  • Die ermittelten Daten werden über eine Ausgaberichtung (nicht dargestellt) ausgegeben, nachdem sie decodiert worden sind, oder ohne dass sie decodiert worden sind. Die Ausgabeeinrichtung führt Verarbeitung und Ausgabe der Daten in Zugriffseinheiten (AU) durch, um einem Benutzer einen Broadcast-Dienst bereitzustellen. Die Zugriffseinheit bezeichnet eine minimale Einheit, die durch eine Ausgabeeinrichtung oder eine Decodiereinrichtung abgeteilt und verarbeitet werden kann. Bei Video beispielsweise können I-, P- und B-Rahmen-Pakete AU-Einheiten sein, und bei einem MPEG-2-Transportpaket können PES oder Abschnitts-Daten die AU-Einheiten sein.
  • Die Rundfunk-Empfangsvorrichtung kann, obwohl in den Zeichnungen nicht dargestellt, des Weiteren ein Kanaleinstellmodul, einen HF-Empfänger, eine Basisband-Verarbeitungseinrichtung und eine Empfangseinrichtung für Informationen bezüglich eines eingebetteten Stream enthalten. Das Kanaleinstellmodul stellt eine Frequenz auf einen Kanal ein, und die HF-Empfangsvorrichtung empfängt ein Signal, das der eingestellten Frequenz entspricht. Die Basisband-Verarbeitungseinrichtung verarbeitet das empfangene Signal und wandelt es in einen Bitstream um, um das Signal an einem letzteren Teil zu verarbeiten. Die Empfangseinrichtung für Informationen bezüglich eines eingebetteten Stream empfängt Informationen bezüglich eines eingebetteten Stream. Die Informationen bezüglich eines eingebetteten Stream können alle Informationen sein, die erforderlich sind, um den eingebetteten Stream zu verarbeiten, wobei dies Informationen einschließt, die angeben, ob ein eingebetteter Stream vorhanden ist, den Typ des eingebetteten Stream oder ein Verfahren zum Verarbeiten des eingebetteten Stream, d. h. äußeres Interleaving, RS-Paritätsinformationen, Zeit-Interleaving.
  • Wenn ein erster Transport-Stream einen zweiten Transport-Stream in dem gleichen oder einem anderen Format enthält, wird der unter Bezugnahme auf 77 beschriebene eingebettete Stream verwendet, um den eingeschlossenen zweiten Transport-Stream anzuzeigen. So werden Informationen zum Verarbeiten des eingebetteten Stream innerhalb des Bandes oder außerhalb des Bandes übertragen, oder eine vorgegebene Bedingung oder ein Wert werden verwendet, so dass die Rundfunk-Empfangsvorrichtung ihn erkennen kann.
  • 78 ist ein Flussdiagramm, das ein Verfahren zum Empfangen einer Broadcast-Übertragung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S7810 wird eine Frequenz eines Kanals eingestellt.
  • In Vorgang S7820 wird ein Signal empfangen, das der eingestellten Frequenz entspricht.
  • In Vorgang S7830 werden Informationen bezüglich eines eingebetteten Stream empfangen.
  • In Vorgang S7840 werden Signalisierungsinformationen bezogen, die Informationen zum Verarbeiten eines oder mehrerer Transport-Kanäle beinhalten. In der vorliegenden Patentbeschreibung können Signalisierungsinformationen über einen SIC übertragen werden.
  • In Vorgang S7850 werden Informationen eines Transport-Kanals einem Benutzer bereitgestellt, um die Auswahl des Benutzers zu erhalten.
  • In Vorgang S7860 wird ein Transport-Kanal, der einen Dienst bereitstellt, auf Basis der Eingabe des Benutzers ausgewählt. Als Alternative dazu kann ein vorgegebener Transport-Kanal als Standardwert ausgewählt werden.
  • In Vorgang S7870 werden Daten über einen oder mehrere Transport-Kanäle empfangen.
  • In Vorgang S7880 werden die empfangenen Daten verarbeitet.
  • In Vorgang S7890 werden die verarbeiteten Daten ausgegeben.
  • Ein Transport-Rahmen gemäß einer Ausführungsform der vorliegenden Erfindung kann über einen Transport-Rahmen, der in einem ATSC-Transportsystem verwendet wird, oder separat übertragen werden. Wenn ein Transport-Rahmen, der einen Transport-Stream beinhaltet, der in einem anderen Transportsystem verwendet wird, übertragen wird, können einige der in 78 dargestellten Vorgänge entsprechend einer anderen Ausführungsform der vorliegenden Erfindung übersprungen werden.
  • 79 stellt schematisch ein A-VSB-MCAST-Empfangssystem gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Ein über einen Tuner empfangenes Broadcast- bzw. Rundfunksignal wird einem Benutzer über eine physikalische Schicht, eine Datenverbindungsschicht, eine Transportschicht und eine Anwendungsschicht bereitgestellt. Die Vorgänge der in 79 dargestellten Schichten sind entgegengesetzt zu denen von Schichten in einem MCAST-Übertragungssystem.
  • Die physikalische Schicht bezieht einem MCAST-Transport-Rahmen aus dem empfangenen Rundfunksignal. Der MCAST-Transport-Rahmen kann in einen Transport-Rahmen in einem anderen Transportsystem eingefügt und dann übertragen werden. So muss die physikalische Schicht den MCAST-Transport-Rahmen beziehen. Wenn der MCAST-Transport-Stream in einen ATSC-Transport-Rahmen eingefügt und dann übertragen wird, wird der MCAST-Transport-Stream bezogen, indem ein ‚deterministic frame sync(DFS)‘-Feld erfasst wird, wobei der MCAST-Transport-Stream in N Pakete unterteilt ist. Der MCAST-Transport-Rahmen hat eine deterministische Struktur, und so können die N Pakete unabhängig von dem Vorhandensein eines Fehlers in den MCAST-Transport-Rahmen integriert werden.
  • Die Datenverbindungsschicht korrigiert Fehler in über einen Turbo-Kanal übertragenen Daten sowie in einer Vielzahl von über einen SIC übertragenen Elementen von Signalisierungsinformationen. Eine sendende Seite kann spezifische FEC (eine Coderate usw.) auf jeden Turbo-Kanal anwenden. Insbesondere kann robuste FEC auf die Signalisierungsinformationen in dem SIC angewendet werden. Die Datenverbindungsschicht in der Rundfunk-Empfangsvorrichtung kann Fehlerkorrektur unter Verwendung von zusätzlichem Code, wie beispielsweise FEC, durchführen.
  • Die Transportschicht in der Rundfunk-Empfangsvorrichtung enthält eine Paketbildungs-Schicht und eine Kapselungsschicht. Die Paketbildungs-Schicht erzeugt ein Kapselungspaket durch Verarbeiten eines multiplexierten Transportpaketes, und die Kapselungsschicht stellt die ursprünglichen Anwendungsdaten sowie anwendungsspezifische Informationen durch Verarbeiten des Kapselungspaketes wieder her. Die Anwendungsdaten können Echtzeit-Mediendaten, IP-Daten, Objekt-Daten und Signalisierungs-Daten enthalten.
  • Ein Transport-Rahmen, der in dem MCAST-Übertragungssystem verwendet wird, hat eine deterministische Struktur. Das heißt, integrale Pakete sind in einem Transport-Rahmen vorhanden. Wenn ein Transport-Rahmen eine deterministische Struktur hat, ist dies wirkungsvoll, da ein ‚sync‘-Feld oder ein ‚CC‘-Feld aus Paketen entfernt werden kann. In einem System, das Daten in Paketgruppen-Einheiten gemäß der vorliegenden Erfindung multiplexiert und überträgt, macht Multiplexing unter Verwendung einer Paketgruppe Empfang aller Pakete erforderlich, die die Paketgruppe bilden. Wenn ein Fehler in einigen der Pakete auftritt, müssen die fehlerhaften Pakete ebenfalls empfangen werden, um die Paketgruppe zu bilden. Ansonsten werden ein Abschluss-Offsetwert eines Teil-Datenkanals und die Position von Daten der tatsächlichen Paketgruppe geändert, wodurch verhindert wird, dass alle Pakete vollständig empfangen werden. Beispielsweise zeigen Informationen, wie z.B. eine LMT, die die Position eines Transport-Kanals anzeigt, die Position von Daten unter Verwendung eines Offset-Wertes in einem Rahmen an, und daher muss die physikalische Schicht selbst ein fehlerhaftes Paket zu einer oberen Schicht übertragen.
  • Daher ist es, wenn ein Fehler in einem bestimmten Paket auftritt, erforderlich, anzuzeigen, dass das Auftreten des Fehlers in diesem Paket angezeigt wird, oder eine Paket-Demultiplexeinrichtung wird über diese Tatsache informiert. Über das Auftreten eines Fehlers kann wie folgt informiert werden.
  • Zunächst wird das Auftreten eines Fehlers durch ein ‚error_indicator‘-Feld in dem Header eines Paketes angezeigt. Dieses Verfahren wird im Fall eines MPEG-2-TS angewendet. Die Paketeffizienz wird jedoch verschlechtert, da ein neues Feld zu dem Header eines Paketes hinzugefügt werden muss.
  • Zweitens wird ein Hardware-Signal-Flag gesetzt, um anzuzeigen, dass ein Fehler in einem aktuellen Paket auftritt. Wenn ein ‚error_indicator‘-Feld nicht verwendet wird, wird über zusätzliche Signalisierung angezeigt, dass ein Fehler auftritt. Jedoch entsteht Overhead, da Signalisierungsinformationen mit dem Paket synchronisiert werden müssen.
  • Drittens wird ein zusätzliches Feld, das in den Standards nicht spezifiziert ist, für jedes Paket erzeugt, und das ‚error_indicator‘-Feld wird in das zusätzliche Feld integriert. Dies ist jedoch unpraktisch, da ein Endgerät individuell Informationen einfügen muss, die das Auftreten eines Fehlers darstellen.
  • Um diese Probleme zu lösen, wird das Auftreten eines Fehlers implizit unter Verwendung einer Kombination von Feldern angezeigt, die eine Diskrepanz entsprechend der Struktur des Paket-Headers zeigt. Das Auftreten eines Fehlers kann angezeigt werden, indem der Header eines fehlerhaften Paketes so konstruiert wird, dass er in einem tatsächlichen Paket nicht vorhanden ist. Das heißt, der Header des fehlerhaften Paketes wird unter Verwendung einer Kombination von Feldern konstruiert, die in dem Paket-Header tatsächlich nicht existieren können. Da eine derartige Header-Struktur nicht vorhanden sein kann, stellt eine Paket-Demultiplexiereinheit fest, dass ein Paket mit einer derartigen Header-Struktur ein fehlerhaftes Paket ist.
  • Im Folgenden wird eine Ausführungsform des Headers eines fehlerhaften Paketes dargestellt, wie sie in MCAST definiert ist:
    First_last 0 × 00
    DC_flag 0 × 01
  • Diese Felder bedeuten, dass ein Kapselungspaket kein erstes Paket ist und dass es Decoderkonfigurations-Informationen enthält.
  • Decoderkonfigurations-Informationen sind stets an einer Position enthalten, an der ein erstes Paket eines Kapselungspaketes enthalten ist, und können daher nicht in einem MCAST-Paket vorhanden sein. So stellt ein Endgerät fest, dass ein Paket, das eine derartige Header-Struktur aufweist, ein fehlerhaftes Paket ist.
  • 80 ist ein Blockschaltbild einer Rundfunk-Empfangsvorrichtung, die in der Lage ist, ein Fehlerpaket anzuzeigen, gemäß einer Ausführungsform der vorliegenden Erfindung. Die Rundfunk-Empfangsvorrichtung enthält, wie unter Bezugnahme auf 80 zu sehen ist, ein HF-Modul 8001, eine Basisband-Verarbeitungseinheit 8002, eine DFS-Erfassungseinheit 8003, eine Preheader-Einfügeeinheit 8004, eine Demultiplex-Einheit 8005 und eine Wiedergabeeinrichtung (renderer) 8006. Das HF-Modul 8001 empfängt ein analoges Broadcast-Signal und die Basisband-Verarbeitungseinheit 8002 erzeugt einen Bitstream entsprechend dem ATSC- und dem A-VSB-Standard. Die DFS-Erfassungseinheit 8003 unterteilt durch Erfassen von DFS den Bitstream in N Pakete.
  • Die Preheader-Einfügeeinheit 8004 fügt einen Preheader in jedes der Pakete ein. Der Preheader kann eine Kennung enthalten, die den Typ des Pakets darstellt, Fehlerinformationen, die anzeigen, ob ein Fehler in dem Paket vorhanden ist, sowie ein ‚CC‘-Feld, mit dem geprüft wird, ob Kontinuität entsprechend dem Typ des Paketes vorhanden ist. Mit dem ‚CC‘-Feld ist es möglich, festzustellen, ob ein Paket verlorengegangen ist.
  • Die Struktur des Preheaders gemäß einer Ausführungsform der vorliegenden Erfindung wird weiter unten unter Bezugnahme auf die 82 beschrieben.
  • Die Demultiplex-Einheit 8005 demultiplexiert ein Transportpaket. In diesem Fall kann die Kennung, die den Typ des Paketes darstellt und in dem Preheader enthalten ist, verwendet werden.
  • Die Wiedergabeeinrichtung 8006 verarbeitet Daten und gibt das Verarbeitungsergebnis aus.
  • 81 ist ein Flussdiagramm, das ein Verfahren zum Empfangen einer Broadcast-Übertragung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt, mit der ein fehlerhaftes Paket angezeigt wird.
  • In Vorgang S8110 wird ein Bitstrom von einer Basisband-Verarbeitungseinrichtung empfangen.
  • In Vorgang S8120 wird der Bitstrom unter Verwendung von DFS in N Pakete unterteilt. Der Wert von N kann entsprechend einem Übertragungsmodus variieren.
  • In Vorgang S8130 wird Fehlerkorrektur durchgeführt. Ein Verfahren der Fehlerkorrektur entspricht einem Verfahren des Fehlerschutzes, das an einer sendenden Seite verwendet wurde. Beispielsweise kann RS-Decodierung oder Außen-Decodierung durchgeführt werden.
  • In Vorgang S8140 werden die Typen der Pakete identifiziert. Beispielsweise wird festgestellt, ob ein Transportpaket entweder ein Signalisierungspaket, das Signalisierungsdaten beinhaltet, oder ein allgemeines Datenpaket ist.
  • In Vorgang S8150 wird eine Kennung zu jedem der Pakete entsprechend dem Paket-Typ hinzugefügt. Beispielsweise wird ‚0 × 30‘ als eine Kennung zu dem Signalisierungspaket hinzugefügt, das Signalisierungsinformationen enthält, und ‚0 × 47‘ wird als eine Kennung zu einem allgemeinen MCAST-Transportpaket hinzugefügt.
  • In Vorgang S8160 wird festgestellt, ob ein Fehler in den Paketen vorhanden ist, und wenn ein Fehler vorhanden ist, werden Informationen, die diese Tatsache anzeigen, zu dem Paket hinzugefügt, das den Fehler aufweist.
  • In Vorgang S8170 wird festgestellt, ob alle oben beschriebenen Vorgänge für alle Pakete durchgeführt worden sind. Wenn dies nicht der Fall ist, werden die oben beschriebenen Vorgänge wiederholt.
  • In Vorgang S8180 werden die Pakete von einem Demultiplexer auf einer Transportschicht verarbeitet. Die oben beschriebenen Vorgänge S8110 bis S8170 werden durch die Basisband-Verarbeitungseinrichtung oder unterhalb der Transportschicht durchgeführt.
  • 82A und 82B stellen die Struktur eines Preheaders gemäß Ausführungsformen der vorliegenden Erfindung dar.
  • Der Preheader kann ein Sync-Byte und ein CC-Feld enthalten. Das Sync-Byte besteht aus einem Byte und beinhaltet Identifizierungsinformationen, die einen Pakettyp identifizieren. ‚0 × 38‘ kann beispielsweise ein Signalisierungspaket anzeigen, und ‚0 × 47‘ kann ein allgemeines Datenpaket anzeigen.
  • Das CC-Feld ist ein 1-Byte-Feld und kann ein Fehler-Flag beinhalten, das anzeigt, ob ein Fehler in einem Paket vorhanden ist. Wenn ein Fehler vorhanden ist, kann ein Bit des CC-Feldes verwendet werden, um den Fehler anzuzeigen. Beispielsweise zeigt ‚0, 1, 2, 3, 4, ...., 254, 255, 0, 1, 2, 3, ...‘ an, dass kein Fehler vorhanden ist, und ‚0, 1, 2, 3, 4, ...., 126, 127, 0, 1, 2, 3, ...‘ zeigt an, dass ein Fehler vorhanden ist.
  • 83 ist ein Flussdiagramm, das ein Verfahren zum Verarbeiten eines DCI durch eine Rundfunk-Empfangsvorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
  • In Vorgang S8310 wird ein MCAST-Transportpaket empfangen.
  • In Vorgang S8320 wird ein RAP-Flag geprüft.
  • Wenn das RAP-Flag aktiviert ist, wird in Vorgang S8330 ein Kapselungspaket konstruiert.
  • In Vorgang S8340 wird ein DCI-Flag geprüft.
  • In Vorgang S8350 wird Parsing eines DCI-Feldes durchgeführt.
  • In Vorgang S8360 wird ein Decoder so eingestellt, dass er dem DCI-Feld entspricht.
  • 84A stellt ein Verfahren zum Aktualisieren von TCC in adaptivem Time-Slicing gemäß einer Ausführungsform der vorliegenden Erfindung dar.
  • Eine GOF besteht, wie unter Bezugnahme auf 84A zu sehen ist, aus fünf Rahmen, und die Zahlen von 0 bis 5 werden jeweils Rahmen zugewiesen, die zu jeder der GOF gehören.
  • Ein ‚TCC_next_update_offset‘-Feld kann über ein ‚service configuration information‘-Feld in einem SIC übertragen werden und enthält einen Rahmen, dessen TCC zu aktualisieren ist. Das heißt, wenn das ‚TCC_next_update_offset‘-Feld einen Wert von 4 hat, bedeutet dies, dass die TCC nach vier Rahmen aktualisiert werden.
  • Der Wert eines ‚Next-update-offset‘-Feldes variiert entsprechend dem Kanaltyp, und ein Zeitpunkt, zu dem TCC in jedem der Kanäle aktualisiert wird, kann unter Verwendung des ‚TCC_next_update_offset‘-Feldes sowie des ‚Next_update_offset‘-Feldes berechnet werden. In der aktuellen Ausführungsform wird ein Zeitpunkt, zu dem TCC in einem Turbo-Kanal aktualisiert werden, so berechnet, dass er TCC_next_update__offset+Next_update_offset entspricht.
  • Zunächst wird ein Zeitpunkt, zu dem TCC in einem Kanal A aktualisiert werden, beschrieben.
  • Beim Empfangen eines Rahmens mit einem Wert 1, der zu einer ersten GOF gehört, ermittelt die Rundfunk-Empfangsvorrichtung die Werte des ‚TCC_next_update_offset‘-Feldes und des ‚Next_update_offset‘-Feldes. In der aktuellen Ausführungsform ist der Wert des ‚TCC_next_update_offset‘-Feldes ‚4‘, und der Wert des ‚Next_update_offset‘-Feldes ist ‚0‘. So werden die Turbo-Kanal-Konfigurationsinformationen (TCC) des Kanals A zu einem Zeitpunkt aktualisiert, der durch die Summe der Werte des ‚TCC_next_update_offset‘-Feldes und des ‚Next_update_offset‘-Feldes gezeigt wird, d.h. nach vier Rahmen. Dementsprechend werden die geänderten TCC beginnend mit einem Rahmen angewendet, der einen Wert 5 hat und zu der ersten GOF gehört.
  • Desgleichen werden in einem Kanal B die geänderten TCC von einem Rahmen an angewendet, der einen Wert 2 hat und zu einem zweiten GOF gehört, und in einem Kanal C wird die geänderte TCC von einem Rahmen an angewendet, der einen Wert 5 hat und zu dem zweiten GOF gehört.
  • 84B stellt ein Aktualisierungsverfahren unter Verwendung eines BD bei adaptivem Time-Slicing gemäß einer Ausführungsform der vorliegenden Erfindung dar. 84B stellt im Detail ein Verfahren zum Aktualisieren einer IMT und von Kanalinformationen unter Verwendung von Informationen dar, die in einem BD enthalten sind. Ähnlich wie 84A besteht ein GOF aus 5 Rahmen und Zahlen von 0 bis 5 werden jeweils Rahmen zugewiesen, die zu jedem der Rahmen gehören.
  • Es wird davon ausgegangen, dass bei einem Rahmen, der einen Wert 1 hat und zu einer ersten GOF gehört, eine Rundfunk-Empfangsvorrichtung den Wert eines ‚BD_next_update_offset‘-Feldes ermittelt. In der aktuellen Ausführungsform ist der Wert des ‚BD_next_update_offset‘-Feldes ‚4‘.
  • Des Weiteren werden die Werte eines ‚update_frame_counter‘ (oder ‚channel_info_update‘)-Feldes, das in einem ‚channel_info_descriptor‘-Feld enthalten ist, und eines ‚extended version‘-Feldes, das in einem ‚IMT‘-Feld enthalten ist, ermittelt. In der aktuellen Ausführungsform hat das ‚BD_next_update_offset‘-Feld einen Wert von 4, und das ‚extended version‘-Feld hat einen Wert von 0. So wird die IMT zu einem Zeitpunkt aktualisiert, der durch die Summe der Werte des ‚BD_next_update_offset‘-Feldes und des ‚extended version‘-Feldes angezeigt wird, d.h. nach vier Rahmen. Dementsprechend wird die aktualisierte IMT von einem Rahmen ab angewendet, der einen Wert von 5 hat und zu der ersten GOF gehört.
  • Des Weiteren werden Turbo-Kanal-Informationen zu einem Zeitpunkt aktualisiert, der durch die Summe der Werte des ‚BD_next_update_offset‘-Feldes und des ‚update_frame_counter‘-Feldes angegeben wird, d.h. nach sieben Rahmen. So werden die aktualisierten Kanal-Informationen beginnend mit einem Rahmen verwendet, der einen Wert 2 hat und zu einer zweiten GOF gehört. Dass die Turbo-Kanal-Informationen aktualisiert werden, gilt nicht nur für einen Fall, in dem Turbo-Kanal-Konfigurationsinformationen geändert werden, sondern auch für einen Fall, in dem einige Turbo-Kanäle zugefügt oder entfernt werden.
  • Wenn der BD aus einer Vielzahl von Rahmen besteht, ist der Wert des ‚update_frame_counter‘-Feldes größer als ‚0‘.
  • 85 ist ein Blockschaltbild einer Vorrichtung 8500 zum Transportieren eines Broadcast-Dienstes gemäß einer Ausführungsform der vorliegenden Erfindung.
  • Die Vorrichtung 8500 enthält, wie unter Bezugnahme auf 85 zu sehen ist, eine Kapselungspaket-Erzeugungseinheit 8510, eine Transportpaket-Erzeugungseinheit 8520 sowie eine Dienstkonfigurationsinformations-Erzeugungseinheit 8530.
  • Die Kapselungspaket-Erzeugungseinheit 8510 empfängt Anwendungsdaten, erzeugt ein Kapselungspaket, das Konfigurationsinformationen, die dem Typ zu transportierender Anwendungsdaten entsprechen, und die Anwendungsdaten enthält, und gibt das Kapselungspaket an die Transportpaket-Erzeugungseinheit 8520 aus.
  • In einer Ausführungsform der vorliegenden Erfindung sind die Anwendungsdaten Signalisierungsdaten, Echtzeit-Medien-Daten, IP-Daten oder Objekt-Daten. In Abhängigkeit von dem Typ von Anwendungsdaten werden Informationen über das Kapselungspaket verschieden festgelegt.
  • Das heißt, ein Kapselungspaket, das Echtzeit-Medien-Daten gemäß einer Ausführungsform der vorliegenden Erfindung enthält, enthält in einem Header-Bereich Decoder-Konfigurationsinformationen (DCI), die die Spezifikationen eines Ziels-Decoders bestimmen.
  • Die Transportpaket-Erzeugungseinheit 8520 empfängt das KapselungspPaket von der Kapselungspaket-Erzeugungseinheit 8510, unterteilt das Kapselungspaket in wenigstens ein Transportpaket vorgegebener Größe, das Daten des Kapselungspaketes und Informationen über das Transportpaket selbst enthält, und gibt das Transportpaket an die Dienstkonfigurationsinformations-Erzeugungseinheit 8530 aus.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung erzeugt die Transportpaket-Erzeugungseinheit 8520 ein Transportpaket, das einen Basis-Header-Bereich, einen Zeiger-Bereich, einen Padding-Bereich, einen Location-Map-Table (LMT)-Bereich, einen Verbindungsinformations-Tabellen (LIT)-Bereich und einen Nutzinformations-Bereich enthält.
  • Die Dienstkonfigurationsinformations-Erzeugungseinheit 8530 empfängt das Transportpaket von der Transportpaket-Erzeugungseinheit 8520, erzeugt Dienstkonfigurationsinformationen, die festgelegte Informationen über einen Kanal enthalten, der das Transportpaket enthält, und gibt die Dienstkonfigurationsinformationen an einen SIC (nicht dargestellt) an einer vorgegebenen Position von wenigstens einem Transportkanal auf einem Transport-Stream aus.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung enthält die Dienstkonfigurationsinformations-Erzeugungseinheit 8530 eine Dienstkonfigurationsinformations-Bestimmungseinheit, die Dienstkonfigurationsinformationen bestimmt, die Informationen über einen Turbo-Kanal und Rahmengruppen-Informationen enthalten.
  • 86 ist ein Blockschaltbild einer Vorrichtung 8600 zum Empfangen eines Broadcast-Dienstes gemäß einer Ausführungsform der vorliegenden Erfindung. Die Vorrichtung 8690 enthält, wie unter Bezugnahme auf 86 zu sehen ist, eine Transportkanal-Bestimmungseinheit 8610, eine Transportpaket-Extrahiereinheit 8620, eine Transportpaketinformations-Extrahiereinheit 8630, eine Kapselungspaket-Kombiniereinheit 8640 und eine Anwendungsdaten-Kombiniereinheit 8650.
  • Die Transportkanal-Bestimmungseinheit 8610 bestimmt einen vorgegebenen Transportkanal unter Verwendung von Dienstkonfigurationsinformationen, die aus einem Dienst-Informationskanal an einer vorgegebenen Position in einem empfangenen Rahmen extrahiert werden, und gibt Informationen über den bestimmten Transportkanal an die Transportpaket-Extrahiereinheit 8620 aus.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung werden Informationen über einen Turbo-Kanal und Rahmengruppen-Informationen aus den Dienstkonfigurationsinformationen extrahiert.
  • Die Transportpaket-Extrahiereinheit 8620 extrahiert ein Transportpaket aus dem durch die Transportkanal-Bestimmungseinheit 8610 bestimmten Transportkanal und gibt das Transportpaket an die Transportpaket-Informationsextrahiereinheit 8630 aus.
  • Die Transportpaketinformations-Extrahiereinheit 8630 extrahiert Transportpaket-Informationen aus dem durch die Transportpaket-Extrahiereinheit 8620 extrahierten Transportpaket und gibt die Transportpaket-Informationen an die Kapselungspaket-Kombiniereinheit 8640 aus.
  • Die Kapselungspaket-Kombiniereinheit 8640 ermittelt eine Kombination von Kapselungspaketen einschließlich wenigstens eines Transportpaketes unter Verwendung der extrahierten Transportpaket-Informationen und gibt sie an die Anwendungsdaten-Erzeugungseinheit 290 aus.
  • In einer Ausführungsform der vorliegenden Erfindung werden Basiskonfigurations-Informationen, eine LMT, eine LIT und ein Programmtakt-Bezugswert (PCR) aus dem Transportpaket extrahiert.
  • Die Anwendungsdaten-Kombiniereinheit 8650 empfängt die Kombination der Kapselungspakete von der Kapselungspaket-Kombiniereinheit 8640, extrahiert Kapselungspaket-Informationen aus den Kapselungspaketen und erzeugt Anwendungsdaten, die wenigstens ein Kapselungspaket enthalten, unter Verwendung der extrahierten Kapselungspaket-Informationen.
  • 87 ist ein Flussdiagramm eines Verfahrens zum Transportieren eines Broadcast-Dienstes gemäß einer Ausführungsform der vorliegenden Erfindung.
  • In Vorgang 8710 wird ein Kapselungspaket erzeugt, das Konfigurationsinformationen, die an den zu transportierenden Typ von Anwendungsdaten angepasst sind, und die Anwendungsdaten enthält.
  • In Vorgang 8720 werden Transportpakete, die Daten bezüglich des Kapselungspaketes enthalten, hergestellt, indem das Kapselungspaket in Pakete vorgegebener Größe geteilt wird. Die Transportpakete enthalten Informationen über die Strukturen der Transportpakete.
  • In Vorgang 8730 werden Dienstkonfigurationsinformationen erzeugt, die Informationen enthalten, die bezüglich eines Kanals festgelegt sind, der die Transportpakete enthält, und in einen SIC an einer vorgegebenen Position wenigstens eines Transportkanals in einem Transport-Stream integriert.
  • 88 ist ein Flussdiagramm eines Verfahrens zum Empfangen eines Broadcast-Dienstes für Mobilkommunikation gemäß einer Ausführungsform der vorliegenden Erfindung.
  • In Vorgang 8810 wird ein vorgegebener Transportkanal unter Verwendung von Dienstkonfigurationsinformationen bestimmt, die aus einem SIC extrahiert werden.
  • In Vorgang 8820 wird ein Transportpaket aus dem bestimmten Transportkanal extrahiert.
  • In Vorgang 8830 werden Informationen über das Transportpaket aus dem Transportpaket extrahiert.
  • In Vorgang 8840 wird eine Kombination von Kapselungspaketen, die jeweils wenigstens ein Transportpaket aufweisen, unter Verwendung der Informationen über das Transportpaket erzeugt.
  • In Vorgang 8850 wird eine Kombination von Anwendungsdaten, die wenigstens eines der Kapselungspakete enthalten, unter Verwendung von Informationen über die Kapselungspakete erzeugt, die aus den Kapselungspaketen extrahiert werden.
  • Die oben beschriebenen Ausführungsformen der vorliegenden Erfindung können als Computerprogramme ausgeführt werden und in digitalen Universalcomputem implementiert werden, die die Programme unter Verwendung eines computerlesbaren Aufzeichnungsmedium ausführen. Zu Beispielen für das computerlesbare Aufzeichnungsmedium gehören magnetische Speichermedien (beispielsweise ROM, Disketten, Festplatten usw.), optische Aufzeichnungsmedien (beispielsweise CD-ROM oder DVD) und Speichermedien wie beispielsweise Trägerwellen (z.B. Übertragung über das Internet).
  • Die Datenfelder, Paketstrukturen, API und jeder Block von Flussdiagramm-Darstellungen, die zum Erläutern der obenstehenden Ausführungsformen der vorliegenden Erfindung beschrieben wurden, können mittels Computerprogramm-Befehlen implementiert werden. Diese Computerprogramm-Befehle können einem Prozessor eines Universalcomputers, eines speziellen Computers oder anderer programmierbarer Datenverarbeitungsvorrichtungen, die eine Maschine bilden, bereitgestellt werden, so dass die Befehle, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der in dem Flussdiagramm-Block bzw. den Blöcken gegebenen Funktionen schaffen. Diese Computerprogramm-Befehle können auch in einem durch Computer nutzbaren oder durch Computer lesbaren Speicher gespeichert werden, der einen Computer oder eine andere programmierbare Datenverarbeitungsvorrichtung anweisen kann, auf eine bestimmte Weise zu arbeiten, so dass diese durch den durch Computer verwendbaren oder Computer lesbaren Speicher gespeicherten Befehle ein Erzeugnis bilden, das Befehlsmittel enthält, die die in einem Block bzw. Blöcken eines Flussdiagramme angegebene Funktion implementieren. Computerprogramm-Befehle können auch in einen Computer oder eine andere programmierbar Datenverarbeitungsvorrichtung geladen werden, um zu bewirken, dass eine Reihe von Funktionsschritten auf dem Computer oder der anderen programmierbaren Vorrichtung durchgeführt werden, um einen durch Computer implementierten Prozess zu erzeugen, so dass die Befehle, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Schritte zum Implementieren der in dem Block bzw. den Blöcken des Flussdiagramms angegebenen Funktionen schaffen.
  • Jeder Block der Flussdiagramm-Darstellungen kann ein Modul, Segment oder einen Abschnitt von Code darstellen, der ein oder mehrere ausführbare Befehle zum Implementieren der angegebenen logischen Funktionen enthält. Es ist weiterhin zu bemerken, dass in alternativen Umsetzungen die Funktionen, die in den Blöcken aufgeführt sind, außerhalb der Reihenfolge auftreten können. Zwei nacheinander dargestellte Blöcke können im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können in Abhängigkeit von der jeweiligen Funktionalität in umgekehrter Reihenfolge ausgeführt werden.
  • Des Weiteren können die in der vorliegenden Patentbeschreibung dargestellten Datenfelder und Pakete durch andere Datenfelder und Pakete ersetzt werden, die die gleichen Funktionen erfüllen können.

Claims (2)

  1. Verfahren zum Empfangen eines Rundfunkdienstes für Mobilkommunikation, wobei das Verfahren umfasst: Bestimmen (8810) eines vorgegebenen Transportkanals unter Verwendung aus einem Dienstinformationskanal extrahierter Dienstkonfigurationsinformationen; Extrahieren (8820) eines Transportpaketes aus dem bestimmten Transportkanal; Extrahieren (8830) von Informationen bezüglich des Transportpaketes aus dem extrahierten Transportpaket; Erzeugen (8840) einer Kombination von Kapselungspaketen, die jeweils wenigstens ein Transportpaket aufweisen, durch Extrahieren der Informationen bezüglich des Transportpaketes; und Erzeugen (8850) einer Kombination von Anwendungsdaten, die wenigstens ein Kapselungspaket aufweisen, unter Verwendung von Informationen bezüglich der Kapselungspakete, die aus der Kombination der Kapselungspakete extrahiert werden.
  2. Vorrichtung zum Empfangen eines Rundfunkdienstes für Mobilkommunikation, wobei die Vorrichtung umfasst: eine Transportkanal-Bestimmungseinheit (8610), die einen vorgegebenen Transportkanal unter Verwendung von Dienstkonfigurationsinformationen bestimmt, die aus einem Dienstinformations-Kanal extrahiert werden; eine Transportpaket-Extraktionseinheit (8620), die ein Transportpaket aus dem bestimmten Transportkanal extrahiert; eine Transportpaketinformations-Extraktionseinheit (8630), die Informationen bezüglich des Transportpaketes aus dem extrahierten Transportpaket extrahiert; eine Kapselungspaket-Kombiniereinheit (8640), die eine Kombination von Kapselungspaketen, die jeweils wenigstens ein Transportpaket aufweisen, unter Verwendung der Informationen bezüglich des Transportpaketes erzeugt; und eine Anwendungsdaten-Kombiniereinheit (8650), die eine Kombination von Anwendungsdaten, die wenigstens ein Kapselungspaket aufweisen, unter Verwendung von Informationen bezüglich der Kapselungspakete herstellt, die aus der Kombination der Kapselungspakete extrahiert werden.
DE112008000552.4T 2007-05-14 2008-05-14 Verfahren und Vorrichtung zum Empfangen von Rundfunk Expired - Fee Related DE112008000552B4 (de)

Applications Claiming Priority (19)

Application Number Priority Date Filing Date Title
US91777607P 2007-05-14 2007-05-14
US60/917,776 2007-05-14
US93847707P 2007-05-17 2007-05-17
US60/938,477 2007-05-17
US94461907P 2007-06-18 2007-06-18
US60/944,619 2007-06-18
US97432107P 2007-09-21 2007-09-21
US60/974,321 2007-09-21
US97848807P 2007-10-09 2007-10-09
US60/978,488 2007-10-09
US4755608P 2008-04-24 2008-04-24
US7136408P 2008-04-24 2008-04-24
US7136908P 2008-04-24 2008-04-24
US61/071,369 2008-04-24
US61/047,556 2008-04-24
US61/071,364 2008-04-24
US7139308P 2008-04-25 2008-04-25
US61/071,393 2008-04-25
PCT/KR2008/002699 WO2008140263A1 (en) 2007-05-14 2008-05-14 Method and apparatus for transmitting broadcast, method and apparatus for receiving broadcast

Publications (2)

Publication Number Publication Date
DE112008000552T5 DE112008000552T5 (de) 2010-02-18
DE112008000552B4 true DE112008000552B4 (de) 2020-04-23

Family

ID=40002401

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112008000552.4T Expired - Fee Related DE112008000552B4 (de) 2007-05-14 2008-05-14 Verfahren und Vorrichtung zum Empfangen von Rundfunk

Country Status (8)

Country Link
US (1) US8717961B2 (de)
KR (1) KR101227029B1 (de)
BR (1) BRPI0805829B1 (de)
CA (1) CA2667571C (de)
DE (1) DE112008000552B4 (de)
FI (1) FI124830B (de)
MX (1) MX2009004942A (de)
WO (1) WO2008140263A1 (de)

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7343413B2 (en) 2000-03-21 2008-03-11 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US8380854B2 (en) 2000-03-21 2013-02-19 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
US8532012B2 (en) * 2007-12-07 2013-09-10 Industrial Technology Research Institute Methods and devices for scalable reception in wireless communication systems
US8411625B2 (en) * 2008-07-04 2013-04-02 Nokia Siemens Networks Oy Variable coding length for resource allocation
US8514888B2 (en) * 2008-09-12 2013-08-20 Industrial Technology Research Institute Methods and devices for wireless broadcasting service communication environment
KR101635890B1 (ko) * 2008-11-18 2016-07-04 엘지전자 주식회사 방송 신호를 수신하는 방법 및 방송 수신기
US8156237B2 (en) * 2008-12-09 2012-04-10 Lg Electronics Inc. Method of processing non-real time service and broadcast receiver
CN101998504B (zh) * 2009-08-10 2013-04-10 电信科学技术研究院 多载波聚合系统中下行信息的传输方法及装置
KR20120078718A (ko) * 2009-09-14 2012-07-10 톰슨 라이센싱 스트림의 기본적인 패킷들의 선택에 의한 ｍｐｅｇ?２ ｔｓ 다중화된 멀티미디어 스트림의 분배방법
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
EP2362650A1 (de) * 2010-02-26 2011-08-31 Panasonic Corporation Effiziente Signalisierung einer physikalischen Schicht für ein digitales Rundfunksystem
US8941779B2 (en) * 2012-03-21 2015-01-27 Sony Corporation Non-closed caption data transport in standard caption service
US20130024900A1 (en) * 2010-04-04 2013-01-24 Jong Yeul Suh Method and apparatus for processing non-real-time broadcast service and content transmitted by broadcast signal
CN107360130B (zh) * 2010-04-20 2021-05-07 三星电子株式会社 用于传送和接收媒体数据的接口装置和方法
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US10015286B1 (en) 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
WO2012058643A2 (en) 2010-10-29 2012-05-03 F5 Networks, Inc. System and method for on the fly protocol conversion in obtaining policy enforcement information
KR20120084237A (ko) 2011-01-19 2012-07-27 삼성전자주식회사 엠엠티(ｍｍｔ)에서 엠엠티 인캡슐레이터를 전송하는 방법
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
KR101803970B1 (ko) * 2011-03-16 2017-12-28 삼성전자주식회사 컨텐트를 구성하는 장치 및 방법
KR20120138604A (ko) * 2011-06-14 2012-12-26 삼성전자주식회사 멀티미디어 시스템에서 복합 미디어 컨텐츠를 송수신하는 방법 및 장치
US9246819B1 (en) * 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
US9553817B1 (en) * 2011-07-14 2017-01-24 Sprint Communications Company L.P. Diverse transmission of packet content
US9021156B2 (en) 2011-08-31 2015-04-28 Prashanth Nimmala Integrating intellectual property (IP) blocks into a processor
US8805926B2 (en) 2011-09-29 2014-08-12 Intel Corporation Common idle state, active state and credit management for an interface
US8713240B2 (en) 2011-09-29 2014-04-29 Intel Corporation Providing multiple decode options for a system-on-chip (SoC) fabric
US8711875B2 (en) 2011-09-29 2014-04-29 Intel Corporation Aggregating completion messages in a sideband interface
US8713234B2 (en) 2011-09-29 2014-04-29 Intel Corporation Supporting multiple channels of a single interface
US8775700B2 (en) 2011-09-29 2014-07-08 Intel Corporation Issuing requests to a fabric
US8874976B2 (en) 2011-09-29 2014-10-28 Intel Corporation Providing error handling support to legacy devices
US8929373B2 (en) 2011-09-29 2015-01-06 Intel Corporation Sending packets with expanded headers
EP3518442B1 (de) 2011-10-13 2021-08-04 Samsung Electronics Co., Ltd. Verfahren zum senden und empfangen eines multimediadienstes
US9053251B2 (en) 2011-11-29 2015-06-09 Intel Corporation Providing a sideband message interface for system on a chip (SoC)
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
EP2853074B1 (de) 2012-04-27 2021-03-24 F5 Networks, Inc Verfahren zur optimierung von inhaltsdienstanfragen und vorrichtungen dafür
KR102267861B1 (ko) 2012-06-19 2021-06-23 소니그룹주식회사 대화형 텔레비전을 위한 트리거 파라미터 테이블의 확장
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
WO2014175617A1 (ko) 2013-04-23 2014-10-30 ㈜ 소닉티어 직접 오디오 채널 데이터 및 간접 오디오 채널 데이터를 이용한 스케일러블 디지털 오디오 인코딩/디코딩 방법 및 장치
KR101421201B1 (ko) * 2013-04-23 2014-07-22 한국산업은행 비압축 오디오 채널 데이터 및 압축 오디오 채널 데이터를 이용한 스케일러블 디지털 오디오 인코딩/디코딩 방법 및 장치
US9749680B2 (en) * 2013-08-19 2017-08-29 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
GB2542282B (en) * 2013-10-22 2018-08-01 Canon Kk Method, device, and computer program for encapsulating partitioned timed media data in a server
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US9955230B2 (en) * 2013-12-06 2018-04-24 Institut Fur Rundfunktechnik Gmbh OFDM based broadcast communication system
EP3090518B1 (de) * 2014-01-03 2020-02-12 LG Electronics Inc. Verfahren und vorrichtung zum senden/empfangen eines rundfunksignals einschliesslich robust-header-compression-paketstrom
CA2921664C (en) 2014-01-14 2017-09-12 Lg Electronics Inc. Method and apparatus for transmitting/receiving broadcasting signal including robust header compression packet stream and fast information
CN105981392A (zh) * 2014-02-11 2016-09-28 Lg电子株式会社 广播接收装置及其操作方法
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
JP6667128B2 (ja) * 2014-08-28 2020-03-18 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
WO2016031173A1 (ja) * 2014-08-28 2016-03-03 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
ES3034665T3 (en) 2014-10-01 2025-08-21 Dolby Int Ab Decoding an encoded audio signal using drc profiles
CN105765943B (zh) 2014-10-20 2019-08-23 Lg 电子株式会社 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法和接收广播信号的方法
KR101804926B1 (ko) * 2014-11-04 2017-12-05 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
KR101823486B1 (ko) 2014-12-10 2018-03-14 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
MX364588B (es) * 2015-02-17 2019-05-02 Sony Corp Aparato de transmision, metodo de transmision, aparato de recepcion y metodo de recepcion.
JPWO2016136489A1 (ja) * 2015-02-27 2017-12-07 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
KR101638791B1 (ko) * 2015-03-13 2016-07-12 한국디엠비 (주) 고화질 dmb를 위한 계층적 비디오 스트림 다중화 방법, 역다중화 방법
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US10063422B1 (en) * 2015-12-29 2018-08-28 Amazon Technologies, Inc. Controlled bandwidth expansion in compressed disaggregated storage systems
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
US12464021B1 (en) 2016-01-20 2025-11-04 F5, Inc. Methods for providing secure access using preemptive measures and devices thereof
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
MX2019006172A (es) * 2016-11-30 2019-07-10 Guangdong Oppo Mobile Telecommunications Corp Ltd Procedimiento de transmisión de información, aparato terminal y aparato de red.
US10911261B2 (en) 2016-12-19 2021-02-02 Intel Corporation Method, apparatus and system for hierarchical network on chip routing
US10846126B2 (en) 2016-12-28 2020-11-24 Intel Corporation Method, apparatus and system for handling non-posted memory write transactions in a fabric
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
CN109615423B (zh) 2018-11-29 2020-06-16 阿里巴巴集团控股有限公司 业务的处理方法及装置
KR102631694B1 (ko) 2020-01-02 2024-01-31 재단법인 대구경북과학기술원 데이터에 대한 암/복호화 및 채널코딩을 수행하는 방법 및 시스템
KR102408433B1 (ko) * 2021-07-27 2022-06-10 한국항공우주연구원 다중 데이터 전송 방법 및 시스템
WO2023096724A1 (en) * 2021-11-24 2023-06-01 Apple Inc. Packet framing for application data unit transmission

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10139066A1 (de) 2001-08-09 2003-02-27 Rohde & Schwarz Verfahren und Anordnung zum Verbessern der Empfangseigenschaften von DVB-Signalen
DE60008251T2 (de) 1999-08-20 2004-12-09 General Instrument Corporation System und verfahren zur vereinfachten übertragung von ip-daten über ein mpeg netzwerk
DE10360431A1 (de) 2003-12-19 2005-07-21 Technotrend Ag Verfahren zum Aufbereiten, Übertragen und Darstellen interaktiver Datendienste auf DVB-Endgeräten
US20060136976A1 (en) * 2000-11-29 2006-06-22 International Business Machines Corporation Re-mapping and interleaving transport packets of multiple transport streams for processing by a single transport demultiplexor
JP2007006349A (ja) * 2005-06-27 2007-01-11 Funai Electric Co Ltd データ伝送システム、送信装置、受信装置、およびデータ伝送方法

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5400401A (en) 1992-10-30 1995-03-21 Scientific Atlanta, Inc. System and method for transmitting a plurality of digital services
US6215530B1 (en) 1995-05-22 2001-04-10 Scientific-Atlanta, Inc. Logical and composite channel mapping in an MPEG network
JP2000069454A (ja) * 1998-08-24 2000-03-03 Victor Co Of Japan Ltd デジタル放送受信機
JP3928311B2 (ja) 1999-09-06 2007-06-13 三菱電機株式会社 ターボ符号の誤り訂正復号装置およびターボ符号の誤り訂正復号方法
US6598226B1 (en) 1999-11-12 2003-07-22 Zenith Electronics Corporation Apparatus and method for providing, retrieving, and using data guide information supplied in a digital vestigial sideband signal
US7693508B2 (en) 2001-03-28 2010-04-06 Qualcomm Incorporated Method and apparatus for broadcast signaling in a wireless communication system
US20020146038A1 (en) * 2001-04-05 2002-10-10 Scott Casavant Method and apparatus for inserting local data into a broadcast stream
JP3624855B2 (ja) 2001-05-22 2005-03-02 ソニー株式会社 正規化装置、方法、プログラムおよび該プログラムを記録した記録媒体ならびに通信端末装置
WO2003010975A1 (en) 2001-07-23 2003-02-06 Thomson Licensing S.A. System and method for broadcast of independently encoded signals on atsc channels
US7369520B2 (en) 2001-10-02 2008-05-06 Nokia Corporation Internet protocol address to packet identifier mapping
US20040190629A1 (en) 2002-07-19 2004-09-30 Cooper Jeffrey Allen System and method for broadcast of independently encoded signals on atsc channels
KR100482287B1 (ko) * 2002-10-26 2005-04-14 한국전자통신연구원 디지털 데이터 방송을 위한 동기화 스트림 데이터 삽입장치 및 그 방법
KR100509253B1 (ko) 2002-12-27 2005-08-23 한국전자통신연구원 매체접근제어 처리장치의 송신제어기 및 그 방법
US7792121B2 (en) 2003-01-03 2010-09-07 Microsoft Corporation Frame protocol and scheduling system
US7499469B2 (en) 2003-01-13 2009-03-03 Broadcom Corporation Method and system for generating digital video broadcast (DVB) transport stream from direct satellite system (DSS) transport stream
JP2006526298A (ja) 2003-05-13 2006-11-16 テレフオンアクチーボラゲット エル エム エリクソン（パブル） イーサネットアクセスシステムに関係した装置及び方法
GB2407738A (en) 2003-10-27 2005-05-04 Nokia Corp Accessing broadcast services through a service portal
KR20050056708A (ko) 2003-12-10 2005-06-16 주식회사 팬택앤큐리텔 이동통신 시스템의 ｒｌｐ 프레임의 처리방법
KR100595208B1 (ko) * 2004-03-19 2006-07-03 엘지전자 주식회사 Ｄｍｂ 수신기 및 소비 전력 절감 방법
US20050273833A1 (en) 2004-05-14 2005-12-08 Nokia Corporation Customized virtual broadcast services
US20050289592A1 (en) 2004-06-29 2005-12-29 Larri Vermola System and method for service listings
US7827579B2 (en) 2004-09-09 2010-11-02 Nokia Corporation Mobile television electronic service guide delivery system
KR100565089B1 (ko) 2004-10-06 2006-03-30 삼성전자주식회사 디지털 오디오 방송(ｄａｂ)에서의 비디오 서비스 제공 및수신방법 및 그 장치
JP4828906B2 (ja) 2004-10-06 2011-11-30 三星電子株式会社 デジタルオーディオ放送でのビデオサービスの提供及び受信方法、並びにその装置
US7532857B2 (en) 2005-03-02 2009-05-12 Rohde & Schwarz Gmbh & Co. Kg Apparatus, systems and methods for providing time diversity for mobile broadcast services
US7732944B2 (en) * 2005-04-19 2010-06-08 Lineage Power Corporation Central current share coordinator, method of current sharing and battery plant employing the same
KR100698273B1 (ko) 2005-06-03 2007-03-22 엘지전자 주식회사 멀티미디어 방송 시스템 및 멀티미디어 방송 채널 관리방법
WO2007013026A2 (en) 2005-07-27 2007-02-01 Koninklijke Philips Electronics, N.V. Apparatus and method for ip datagram and rs-parity encapsulation and de-encapsulation
KR101270275B1 (ko) 2005-08-17 2013-05-31 삼성전자주식회사 방송 시스템에서의 통지 메시지 제공 방법 및 장치
KR100724890B1 (ko) 2005-09-05 2007-06-04 삼성전자주식회사 디브이비-에이치 수신기에서 리드-솔로몬 복호를 위한프레임 경계 검출 방법 및 장치와 이를 이용한 멀티프로토콜 캡슐화-순방향 에러 정정 복호 방법
CN100446574C (zh) 2005-09-08 2008-12-24 电子科技大学 一种用于移动和手持无线电视广播的传输帧方法
WO2007052976A1 (en) 2005-11-07 2007-05-10 Samsung Electronics Co., Ltd. Method and apparatus for delivering service guide contents and notification event information in a mobile broadcast system
KR20070049042A (ko) 2005-11-07 2007-05-10 삼성전자주식회사 휴대 방송 시스템에서 서비스 가이드 컨텐츠 및 통지이벤트 정보의 전송 방법 및 절차
KR20060059877A (ko) 2005-11-11 2006-06-02 텔레폰악티에볼라겟엘엠에릭슨(펍) 이더넷 접근 시스템에 관한 장치 및 방법
US8275002B2 (en) 2007-05-14 2012-09-25 Samsung Electronics Co., Ltd. Broadcasting service transmitting apparatus and method and broadcasting service receiving apparatus and method for effectively accessing broadcasting service
KR101373013B1 (ko) 2007-05-14 2014-03-14 삼성전자주식회사 방송 서비스로의 효율적인 액세스를 위한 방송 전송 장치및 방법 및 방송 서비스 수신 장치 및 방법
KR100957121B1 (ko) 2008-02-22 2010-05-13 성균관대학교산학협력단 키 분배 방법 및 인증 서버

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60008251T2 (de) 1999-08-20 2004-12-09 General Instrument Corporation System und verfahren zur vereinfachten übertragung von ip-daten über ein mpeg netzwerk
US20060136976A1 (en) * 2000-11-29 2006-06-22 International Business Machines Corporation Re-mapping and interleaving transport packets of multiple transport streams for processing by a single transport demultiplexor
DE10139066A1 (de) 2001-08-09 2003-02-27 Rohde & Schwarz Verfahren und Anordnung zum Verbessern der Empfangseigenschaften von DVB-Signalen
DE10360431A1 (de) 2003-12-19 2005-07-21 Technotrend Ag Verfahren zum Aufbereiten, Übertragen und Darstellen interaktiver Datendienste auf DVB-Endgeräten
JP2007006349A (ja) * 2005-06-27 2007-01-11 Funai Electric Co Ltd データ伝送システム、送信装置、受信装置、およびデータ伝送方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ISO/IEC 13818-1
ISO/IEC 14496-3

Also Published As

Publication number Publication date
KR20110086645A (ko) 2011-07-28
KR101227029B1 (ko) 2013-01-28
CA2667571A1 (en) 2008-11-20
US20090296624A1 (en) 2009-12-03
BRPI0805829A2 (pt) 2011-08-30
CA2667571C (en) 2015-09-15
DE112008000552T5 (de) 2010-02-18
US8717961B2 (en) 2014-05-06
FI124830B (fi) 2015-02-13
FI20095927L (fi) 2009-09-09
WO2008140263A1 (en) 2008-11-20
BRPI0805829B1 (pt) 2020-05-26
MX2009004942A (es) 2009-06-03

Similar Documents

Publication Publication Date Title
DE112008000552B4 (de) Verfahren und Vorrichtung zum Empfangen von Rundfunk
US9980015B2 (en) Method of receiving a broadcasting signal and receiving system for receiving a broadcasting signal
KR101122200B1 (ko) 방송 송신 방법 및 장치와 방송 수신 방법 및 장치
JP6309622B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
KR101710403B1 (ko) 방송 신호 수신 방법 및 수신 시스템
US20180213216A1 (en) Media data transmission device, media data reception device, media data transmission method, and media data rececption method
EP3285491A1 (de) Verfahren und vorrichtung zum senden oder empfangen von dienstsignalisierung für einen rundfunkdienst
US11758205B2 (en) Broadcasting signal transmitting device, broadcasting signal receiving device, broadcasting signal transmitting method, and broadcasting signal receiving method
KR102034593B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN106105136A (zh) 用于处理混合广播服务的装置和用于处理混合广播服务的方法
KR102818747B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee