[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1146672A1 - Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem - Google Patents

Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem Download PDF

Info

Publication number
EP1146672A1
EP1146672A1 EP00107694A EP00107694A EP1146672A1 EP 1146672 A1 EP1146672 A1 EP 1146672A1 EP 00107694 A EP00107694 A EP 00107694A EP 00107694 A EP00107694 A EP 00107694A EP 1146672 A1 EP1146672 A1 EP 1146672A1
Authority
EP
European Patent Office
Prior art keywords
broadcast
item
information
data
attribute
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.)
Withdrawn
Application number
EP00107694A
Other languages
English (en)
French (fr)
Inventor
Ralf c/o Home Network Comp. Europe R&D Schäfer
Gil c/o Home Network Company Europe R&D Müller
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.)
Sony Deutschland GmbH
Original Assignee
Sony International Europe GmbH
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 Sony International Europe GmbH filed Critical Sony International Europe GmbH
Priority to EP00107694A priority Critical patent/EP1146672A1/de
Publication of EP1146672A1 publication Critical patent/EP1146672A1/de
Withdrawn legal-status Critical Current

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/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/95—Arrangements characterised by the broadcast information itself characterised by a specific format, e.g. an encoded audio stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H2201/00—Aspects of broadcast communication
    • H04H2201/10—Aspects of broadcast communication characterised by the type of broadcast system
    • H04H2201/20—Aspects of broadcast communication characterised by the type of broadcast system digital audio broadcasting [DAB]

Definitions

  • the present invention relates to the field of information service provision. More particularly, the present invention relates to the information service provision for a broadcast medium.
  • XML Extensible Markup Language
  • W3C World Wide Web consortium
  • An XML Parser uses the DTD as input and checks compliance of incoming data against the DTD.
  • the DAB System is the upcoming standard for digital audio broadcasting in the mobile environment.
  • a so-called DAB Ensemble allows to broadcast several audio channels and data channels simultaneously.
  • a general broadcast file transfer protocol MOT is standardised.
  • the MOT protocol basically provides a container, which takes any type of data and broadcast the data to any connected broadcast receiver.
  • an additional header is provided, which can be used to transmit additional information about the broadcast data.
  • the present invention is not limited to the DAB system. It basically requires the existence of a broadcast file transfer protocol comparable to the MOT protocol.
  • Fig. 3 depicts the general structure of such a broadcast object container. It consists of a header and a body.
  • the header provides at least two attributes ID and Version.
  • the ID attribute is used to identify a broadcast object uniquely among all other broadcast objects in the same broadcast channel.
  • the Version attribute is used to indicate updates of the broadcast data in the body part.
  • the body carries the service data to be transmitted from the server side to the receivers. Header and body are not necessarily transmitted as one data chunk, but the broadcast file transfer protocol defines rules that guarantee that header and respective body can be put together on receiving side.
  • the method to transmit an information service in a broadcast transmission system, wherein said information service is logically fragmented into data fragments which build together with corresponding signalling information respective broadcast objects which can be transmitted independently from each other according to the present invention comprises the following steps:
  • a type of a broadcast object which is included within said signalling information gets mapped to the header.
  • a type of a broadcast object which is included within said signalling information gets mapped to the object body.
  • mapping of the data fragment is performed according to a document type definition which corresponds to the type of the data fragment.
  • said document type definitions are defined according to the XML standard.
  • the present invention provides a transmission protocol for an information service, preferrably using XML, based on a broadcast file transfer protocol.
  • a transmission protocol for an information service preferrably using XML, based on a broadcast file transfer protocol.
  • the abstract protocol mechanisms described in the parallel European Patent Application "Method to transmit an information service in a broadcast transmission system" which is directed to transmission protocols and filed by the applicant of this application on the same filing day as this application is combined with the upcoming standard for document exchange XML in the internet and the means provided by a general broadcast file transfer protocol.
  • the method to receive an information service transmitted in a broadcast transmission system comprises the following step: parsing the header and corresponding object body by a parser which determines the type of received data, checks the validity and decodes the received data by the use of tags.
  • the invention is not limited to this specific embodiment which is an advantageous realization and shows in particular the rules for the transmission protocol, i.e. mapping or coding of information to generate broadcast objects to be transmitted.
  • the reception i.e. demapping or decoding, needs to be performed according to rules corresponding to the rules for mapping to correctly rebuild the transmitted information service.
  • UML Unified Modelling Language
  • Every object defines an entity, which consists of a set of attributes. For better readability some comments are inserted. The comments are surrounded by "--" signs. Additional illustrations depict the assumed information service structure, information system structure and the structure of broadcast files.
  • Fig. 1 depicts an example of the generic structure of an information service to be broadcast using the method of the present invention. It consists basically of three types of service objects, which are Service, Category and Item. Every service object may have several attributes with several types and cardinalities. The relationship between Service, Category and Item is that the information service (Service) consists of one to many information categories (Category) and an information category has one to many items.
  • Service information service
  • Category information categories
  • An information category has one to many items.
  • Fig. 2 shows the system structure assumed for the present invention. It consists basically of several content providers 1, a broadcast server 2 and an arbitrary number of terminals 3. Content Providers 1 deliver content of different categories to the broadcast server, e.g. News, Traffic Information and POI, i.e. point of interest. It is beyond the scope of the present invention how this is done.
  • the broadcast server 2 takes the data via an interface 2a and builds the information service comprising of service objects.
  • the service objects are used to build broadcast objects.
  • the broadcast objects are transmitted as a broadcast file sequence by use of a broadcast file transfer protocol.
  • a terminal 3 receives broadcast files and feeds the files to the processing of broadcast objects. Then broadcast objects are used to create service objects on the fly and to provide access to the data by any application program.
  • the present invention combines XML and the broadcast transmission protocol according to the parallel European Patent Application "Method to transmit an information service in a broadcast transmission system" which is directed to transmission protocols and filed by the applicant of this application on the same filing day as this applicationto provide an information service over a broadcast medium on the basis of a broadcast file transfer protocol.
  • XML so-called DTDs (Document Type Definitions) are used to define the structure of a valid document for a certain application domain. In the following it is described how broadcast object information is mapped to broadcast files and XML documents.
  • the required Object ID consists of a type information (Type), an identifier (ID) and a version information (Version).
  • Type a type information
  • ID an identifier
  • Version a version information
  • the type information specifies the structure of the broadcast object in order to allow for appropriate processing of the object.
  • the assumed underlying broadcast file transfer protocol provides at least two header parameter, an ID and a Version.
  • the ID identifies uniquely an object among others.
  • the Version parameter indicates updates of the broadcast file.
  • No equivalent header parameter for the type information of a broadcast object can be assumed.
  • This can be solved by two different ways: First, the type information (Type) is encoded together with the identifier (ID) in the ID parameter of the broadcast file header. It depends on the context how this encoding could look like in detail, e.g. in case that the ID is kind of a filename a new string can be built which consists of the original filename and a substring which determines the type of the broadcast object.
  • a second solution is to store the type information in the body of the broadcast file, e.g. as a first parameter. This requires to start processing of the body in order determine the type of the broadcast object, but can be an appropriate solution when the first solution can not be applied. Whatever solution is chosen, it is used for the whole service. This means all broadcast objects are identified by
  • Fig. 4 illustrates the steps to map the Service Directory broadcast object to a XML encoded broadcast file. To the left the Service Directory object together with its attributes is depicted.
  • the Service Directory object comprises besides the information service specific attributes Name, Language, ServiceArea and so on from the Service object, and it provides the following signalling information:
  • the attributes of the OBJECT ID are mapped as described above.
  • the figure shows only the first solution.
  • the remaining attributes of the broadcast object are mapped according to the Service Directory DTD and encoded in the broadcast file body.
  • the Service Directory DTD has basically the following structure:
  • the DTD specifies the valid structure for a Service Directory. All received data in a terminal is parsed by a XML Parser, which determines if received data is Service Directory data and checks validity. All information is encoded by the use of tags.
  • the first definition is ⁇ !ELEMENT Service Directory (ProtocolVersion, 7)>.
  • the nested tags are attributes of the Service Directory broadcast object and are defined separately.
  • the ProtocolVersion tag is defined by ⁇ !ELEMENT ProtocolVersion (#PCDATA). This specifies that ProtocolVersion is a valid entity, which provides data of type (#PCDATA).
  • #PCData is an abbreviation for parsed character data means basically that it is text.
  • Fig. 5 illustrates the steps to map the Category Directory broadcast object to a XML encoded broadcast file. To the left the Category Directory object together with its attributes is depicted.
  • the Category Directory object consists of the Object ID, the NoOfCategories attribute and the Category Data.
  • the Category Directory consists of a Category Directory Header and an associated Category Data object.
  • the attributes of the OBJECT ID are mapped as described above.
  • the figure shows only the first solution.
  • the remaining attributes of the broadcast object are mapped according to the Category Directory DTD and encoded in the broadcast file body.
  • the Category Directory DTD has basically the following structure:
  • the DTD specifies the valid structure for a Category Directory. All received data in a terminal is parsed by a XML Parser, which determines if received data is Category Directory data and checks validity. All information is encoded by the use of tags.
  • the first definition is ⁇ !ELEMENT CategoryDirectory (NoOfCategories, Category*)>.
  • NoOfCategories is defined in the line below as #PCDATA.
  • the star following CategoryData specifies that one CategoryDirectory entity consists of zero to many CategoryData tags.
  • the CategoryData tag consists of two further tags CategoryName and CategoryIconId and two so-called XML attributes CategoryID and CategoryVersion.
  • the two tags map to the exemplary category attributes Name and Icon. Thereby it is assumed that the icon data is not stored itself in the broadcast file body, but an ID (CategoryIconId) is used for referencing to the icon data. It is not important for the present invention how this is realised.
  • the CategoryID attributes ID and Version of CategoryData are mapped to XML attributes. This is defined by ⁇ !ATTLIST CategoryData Categoryld CDATA #REQUIRED>.
  • An XML attribute is defined as an attribute belonging to a certain tag (here: CategoryData). It provides additional information for the processing and presentation of the tag.
  • CDATA is a specification of the attribute type. It means that the attribute value is character data, which is the most general type for an attribtue. #REQUIRED enforces that a value for the attribute is specified.
  • the attributes ID and Version are used to distinguish between several categories and to indicate updates of categories. This means they are used mainly for processing of data and are not dedicated for direct use by the user.
  • the actual content of the broadcast file body carries the attributes of the Category Directory encoded in accordance to the DTD.
  • mapping of the Item Directory, Item Dynamic Data List, Item Main Data List and Item Subset Directory follows the same principles as described above, but adapted to the specific structure of the respective broadcast object.
  • Fig. 6 depicts on the left hand side the structure of the Item Directory object, i.e. of the header and the data. It consists of the Object ID, the category linking information, the vertical fragmentation information, the NoOfItems attribute and the Item Core Data.
  • Fig. 7 depicts the structure of the Item Dynamic Data List object i.e. of the header and the data. It consists of the Object ID, the category linking information, the vertical fragmentation information, the attribute NoOfItems and the Item Dynamic Data.
  • Fig. 8 depicts the structure of the Item Main Data List object, i.e. header and data. It consists of the Object ID, the category linking information, the vertical fragmentation information, the NoOfItems attribute and the Item Main Data.
  • Fig. 10 depicts the structure of the Item Subset Directory object, i.e. header and data. It is the equivalent of the Item Directory object. It consists of the Object ID, the category linking information, the NoOfItems attribute, the vertical fragmentation information, and the Item Subset Data.
  • a Referenced Attribute broadcast object works differently due to the nature of this broadcast object.
  • a Referenced Attribute is always used when an attribute value requires too much space (bandwidth or storage), is updated more or less frequently or it has a predefined format, which does not fit to the format of the remaining attributes.
  • An example is a picture, which is encoded in JPEG format while remaining attributes are encoded with XML.
  • Fig. 9 shows the mapping of a Referenced Attribute.
  • the left hand side shows the structure of the Referenced Attribute object. It consists of the Object ID and the referenced attribute.
  • the attributes of the OBJECT ID are mapped as described above.
  • the figure shows only the first solution.
  • the referenced attribute is carried in the broadcast file body in its original, predefined format.
  • mapping of the Item Subset broadcast object works differently due to the nature of this broadcast object.
  • the ItemSubset object shows the following structure. It consists of the Object ID, the category linking information, the vertical fragmentation information, the NoOfItems attribute and the Item Data:
  • An Item Subset is always used when an information category is part of the service that is provided in a predefined format that is different from the one used for the remaining service and that should not be adapted. In this case only a vertical fragmentation scheme is applied and a so-called Item Subset Directory determines which subsets (vertical fragments) exist. Each subset contains several items (ItemData) and every item is provided with its whole set of item attributes (no horizontal fragmentation). But the structure of the subsets is not specified by the transmission protocol. Instead it is assumed that each item has an ID and a Version information and an additional processing unit is responsible for accessing the Item attributes. Additionally the attributes CategoryID, SubsetNo and NoOfItems are also carried together with the item data in the broadcast file body, but their format is also not specified. It depends on the format of the item data, which is an appropriate format.
  • the MOT protocol is standardised for the transmission of broadcast files.
  • Each data object is transmitted by use of a basic structure, which is illustrated in Fig. 12, i.e. a 7 bytes header followed by a header extension of variable length and an object body of variable length.
  • the header contains elementary information for the handling in the receiver.
  • the header extension contains additional information, which is necessary for the handling of certain types of data objects.
  • the object body carries the object to be broadcast.
  • the MOT protocol provides two parameters ContentName and VersionNumber, which are part of the header extension.
  • the ContentName is a character field that contains a unique name or identifier for the object with a variable length. Different character sets are supported by a character set indicator field.
  • the VersionNumber is an unsigned binary number starting at 0 and being incremented by 1 each time the version changes. A change of the VersionNumber indicates that the content of the object body has changed.
  • the VersionNumber is encoded with 8 bit and enables to distinguish 256 states.
  • the ID attribute of each broadcast object is mapped to the ContentName parameter.
  • the Type attribute is encoded together with the ID attribute and mapped to the ContentName parameter.
  • the ID is "HotelDirectory” and Type is "ItemDirectory”
  • a combined string can be built "HotelDirectory_ItemDirectory.xml”.
  • the underscore separates ID and Type.
  • the MOT protocol works with file extensions.
  • "xml" is an appropriate file extension.
  • the ID attribute is mapped to the ContentName and the Type information is part of the object body, e.g. as a binary encoded parameter at the beginning of the object body.
  • the Version attribute of each broadcast object is mapped to the VersionNumber parameter.
  • the two parameters ContentType and ContentSubtype which are part of the header must be set. Both parameters together provide a 2-step classification of the broadcast file.
  • the setting depends on the specific content and must be set in accordance to the protocol rules of the MOT protocol, e.g. image/BMP for bitmap images.
  • an information service to be broadcast may comprise more or less types of service objects which also might be build accordinging to other rules. It is self evident that in such a case the XML DTDs have to be adapted appropriately.
  • the present invention can of course be applied to other transmission protocols than DAB/MOT.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Circuits Of Receivers In General (AREA)
EP00107694A 2000-04-10 2000-04-10 Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem Withdrawn EP1146672A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP00107694A EP1146672A1 (de) 2000-04-10 2000-04-10 Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP00107694A EP1146672A1 (de) 2000-04-10 2000-04-10 Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem

Publications (1)

Publication Number Publication Date
EP1146672A1 true EP1146672A1 (de) 2001-10-17

Family

ID=8168414

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00107694A Withdrawn EP1146672A1 (de) 2000-04-10 2000-04-10 Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem

Country Status (1)

Country Link
EP (1) EP1146672A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1608093A1 (de) * 2004-06-15 2005-12-21 Samsung Electronics Co., Ltd. Verfahren und Vorrichtung zum Dekodieren von MOT Daten
EP1335605A3 (de) * 2002-02-01 2010-04-21 Sony United Kingdom Limited Verfahren und Vorrichtung zur Bereitstellung binärer digitaler TV-daten aus strukturiertem Datenformat
US7844644B2 (en) 2003-12-13 2010-11-30 Samsung Electronics Co., Ltd. Method and apparatus for managing data written in markup language and computer-readable recording medium for recording a program
CN102073534A (zh) * 2011-02-24 2011-05-25 深圳市同洲电子股份有限公司 数据解析方法及装置
US7996567B2 (en) 2003-03-31 2011-08-09 Sony United Kingdom Limited Audio processing

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ETSI: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) protocol", EN 301 234 - V1.2.1, February 1999 (1999-02-01), pages 1 - 31, XP002146079, Retrieved from the Internet <URL:http://www.etsi.org> [retrieved on 20000823] *
EUREKA 147 MOT TASK GROUP: "Digital Audio Broadcasting System - Rules of Operation for the Multimedia Object Transfer Protocol (RO MOT)", DRAFT ETSI TR 101 497 - V1.1.1, March 2000 (2000-03-01), pages 1 - 47, XP002146080, Retrieved from the Internet <URL:http://www.eurekadab.org/etsi/tr101497web.pdf> [retrieved on 20000824] *
LUBELL J: "STRUCTURED MARKUP ON THE WEB", MARKUP LANGUAGES,US,MIT PRESS, CAMBRIDGE, MA, vol. 1, no. 3, 1999, pages 7 - 22, XP000863188, ISSN: 1099-6621 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1335605A3 (de) * 2002-02-01 2010-04-21 Sony United Kingdom Limited Verfahren und Vorrichtung zur Bereitstellung binärer digitaler TV-daten aus strukturiertem Datenformat
US7996567B2 (en) 2003-03-31 2011-08-09 Sony United Kingdom Limited Audio processing
US7844644B2 (en) 2003-12-13 2010-11-30 Samsung Electronics Co., Ltd. Method and apparatus for managing data written in markup language and computer-readable recording medium for recording a program
EP1608093A1 (de) * 2004-06-15 2005-12-21 Samsung Electronics Co., Ltd. Verfahren und Vorrichtung zum Dekodieren von MOT Daten
CN100379293C (zh) * 2004-06-15 2008-04-02 三星电子株式会社 对多媒体对象传输数据解码的方法和设备
CN102073534A (zh) * 2011-02-24 2011-05-25 深圳市同洲电子股份有限公司 数据解析方法及装置
CN102073534B (zh) * 2011-02-24 2014-07-30 深圳市同洲电子股份有限公司 数据解析方法及装置

Similar Documents

Publication Publication Date Title
US7647552B2 (en) XML encoding scheme
US6825781B2 (en) Method and system for compressing structured descriptions of documents
US7043686B1 (en) Data compression apparatus, database system, data communication system, data compression method, storage medium and program transmission apparatus
JP4373721B2 (ja) マークアップ言語文書を符号化するための方法およびシステム
US20040054669A1 (en) Method for dividing structured documents into several parts
US7577740B2 (en) Scalable vehicle processing system
KR20050016558A (ko) Ｘｍｌ 문서의 구조적 스트리밍을 위한 방법 및 장치
MXPA03011675A (es) Sistema y metodo para la sincronizacion mejorada entre un servidor y un cliente.
CN101040283A (zh) 表格相关数据缩减
WO2000011850A9 (en) Optimizing server delivery of content by selective inclusion of optional data based on optimization criteria
MXPA03011673A (es) Sistema y metodo para comunicaciones servidor cliente mejoradas de mensajes de correo electronico.
EP1330924A1 (de) Binäres format für mpeg-7 instanzen
US20020107881A1 (en) Markup language encapsulation
MXPA03011674A (es) Metodo para conducir datos entre un servidor y un cliente.
CN101465791B (zh) 一种基于单向链路的文件传输方法
CN102916991B (zh) 一种数据传输方法、系统以及装置
CN100489838C (zh) 具有格式改编的对象传输方法及设备
US5377329A (en) Reducing data transmission by indexed caching
US20080313291A1 (en) Method and apparatus for encoding data
US20050086594A1 (en) Mixed content includes and encodes
EP1146672A1 (de) Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem
EP1146673A1 (de) Verfahren zur Übertragung eines Informationsdienstes in einem Rundfunkübertragungssystem
KR100500196B1 (ko) 멀티미디어 메타데이터의 오류 내성 부호화/복호화 장치및 방법
JP2006216024A (ja) 交換フォーマットメッセージの効率的な変換
TW473673B (en) Method and apparatus for compressing scripting language content

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

Kind code of ref document: A1

Designated state(s): DE FR GB

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17P Request for examination filed

Effective date: 20011112

AKX Designation fees paid

Free format text: DE FR GB

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SONY DEUTSCHLAND GMBH

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SONY DEUTSCHLAND GMBH

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20121031