1、ETSI TR 101 202 1.2.1 (2003-01) Technical Repor Digital Video Broadcasting (DVB); Implementation guidelines for Data Broadcasting 2 ETSI TR 101 202 VI .2.1 (2003-01) The pre ent d Reference RTR/JTC-DVB-142 Keywords broadcasting, data, digital, DVB, TV, video ETSI 650 Route des Lucioles F-O6921 Sophi
2、a Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 O0 Fax: +33 4 93 65 47 16 Siret No 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) No 7803/88 Important notice Individual copies of the present document can be downloaded from: http:lwmv.etsi .arq
3、cument may be made available in more than one electronic version or in print. In any ca e of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of th
4、e PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at ha p:/pa rta I. etsi I a rgltbist
5、at uslstatus .as p If you find errors in the present document, send your comment to: Cori vriaht Notifica tion No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. O European Telecommunications Standard
6、s Institute 2003. O European Broadcasting Union 2003. All rights reserved. DECTTM, PLUGTESTSTMand UMTSTMare Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade
7、 Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI 3 ETSI TR 101 202 VI . 2.1 (2003-01) Contents Intellectual Property Rights 5 Foreword . 5 1 2 3 3.1 3.2 4 4.1 4.2 4.2.1 4.3 4.3.1 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.5 4.5.1 4.5.2 4.5.3 4.6 4.6.1 4.
8、6.2 4.6.3 4.6.4 4.6.4.1 4.6.4.2 4.6.4.3 4.6.5 4.6.6 4.6.6.1 4.6.6.2 4.6.6.3 4.6.6.4 4.6.6.5 4.6.6.6 4.6.6.7 4.6.6.8 4.6.6.9 4.6.6.10 4.6.7 4.6.7.1 4.6.7.2 4.7 4.7.1 4.7.2 4.7.2.1 4.7.2.2 Scope 6 References 6 Definitions and abbreviations . 7 Definitions 7 Abbreviations . 7 Rules of operation 9 Async
9、hronousISynchronizedSynchronous Data Streaming Usage of the adaptation field 11 Asynchronous Data Streaming . 12 SynchronousISynchronized Data Streaming . 12 Synchronous Data Streaming 12 Synchronized Data Streaming . 13 Multiprotocol encapsulation . 13 Overview 13 Data transport 13 Information in t
10、he SI . 14 Data carousel 15 Introduction . 15 Data carousel Groups and SuperGroups . 16 Use ofthe one-layer data carousel 16 Use ofthe two-layer data carousel 16 The data carousel consists of a single group the description of which is too large for a single DownloadInfoIndication message . 16 The da
11、ta carousel delivers a single version of an application but supports a number of different receiver profiles . 17 The data carousel simultaneously delivers more than one version of an application for a single receiver profile 17 Assignment and use of transactionld values . 17 Use of descriptors spec
12、ific to the DVB data carousel . 18 Type descriptor . 18 Name descriptor 19 Info descriptor . 19 Module link descriptor 19 CRC32 descriptor 19 Location descriptor 19 Estimated download time descriptor . 19 Group link descriptor 19 Private descriptor 20 Compressed module descriptor . 20 Information in
13、 the SI and PSI . 20 Descriptor in SI . 20 Descriptors in PSI . 21 21 21 Platform independence 23 23 24 ETSI 4 ETSI TR 101 202 VI . 2.1 (2003-01) 4.7.2.3 4.7.2.4 4.7.2.5 4.7.3 4.7.3.1 4.7.3.2 4.7.3.3 4.7.3.4 4.7.4 4.7.4.1 4.7.4.2 4.7.4.3 4.7.4.4 4.7.4.5 4.7.5 4.7.5.1 4.7.5.2 4.7.5.3 4.7.6 4.7.7 4.7.
14、7.1 4.7.7.2 4.7.7.3 4.7.7.4 4.7.8 4.7.8.1 4.7.8.2 4.7.9 Transmission of objects . 25 Object References . 26 Taps and associations 28 BIOP Control Stnichues . 30 Interoperable Object Reference (IOR) 30 BIOP Profile Body 31 Lite Options Profile Body . 33 Carousel NSAP address 34 BIOP Messages . 35 Dir
15、ectory . 35 39 40 41 Download Data 42 42 43 DownloadDataBlock 44 MPEG-2 Sections 44 Use of PSI descrip 44 Carousel identifier descriptor 45 Stream identifier descripto 47 Association tag descriptor 46 Deferred association tags descriptor 48 Information in the SI and PSI . 48 SI Descriptor . 48 Descr
16、iptors in PSI . 49 Assignment and use of transactionld values . 49 Annex A: DSM-CC messages for data carousel 51 A . 1 dsmccMessageHeader 51 A.2 dsmccDownloadDataHeader 52 A.3 DownloadServerInitiate 52 A.4 DownloadInfoIndication 53 A.5 DownloadDataBlock 54 A.6 DownloadCancel 55 Annex B: Encapsulatio
17、n of DSM-CC messages in MPEG-2 sections . 56 Annex C: Naming of objects in directories 58 C . 1 Data structures used for names in DSM-CC User-to-User API . 58 C.2 Data structures used for names in object carousels 59 C.3 CORBA strings in object carousels 59 Annex D: Example of an object carousel . 6
18、0 Annex E: Bibliography 63 History 64 ETSI 5 ETSI TR 101 202 VI .2.1 (2003-01) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI membe
19、rs and non-members, and can be found in ETSI SR O00 3 14: “Intellectual Property Rights (7PRs); Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (5). All published
20、 ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This Technical Report (TR) has been produced by Joint Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comit Europen de Normalisation ELECtrotechnique (CENE
21、LEC) and the European Telecommunications Standards Institute (ETSI). NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to Co-ordinate the drafting of standards in the specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body by including in the M
22、emorandum of Understanding also CENELEC, which is responsible for the standardization of radio and television receivers. The EBU is a professional association of broadcasting organizations whose work includes the Co-ordination of its members activities in the technical, legal, programme-making and p
23、rogramme-exchange domains. The EBU has active members in about 60 countries in the European broadcasting area; its headquarters is in Geneva. European Broadcasting Union CH-I218 GRAND SACONNEX (Geneva) Switzerland Tel: +41 22 717 21 11 Fax: +41227172481 Founded in September 1993, the DVB Project is
24、a market-led consortium of public and private sector organizations in the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters marke
25、t-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the broadcast industry. ETSI 6 ETSI TR 101 202 VI .2.1 (2003-01) 1 Scope The present document provides implementation guidelines for the use and implementation of the Digital Video Broadcasting (DVB
26、) data broadcast service in a DVB digital broadcast environment including satellite-, cable-, MMDS- and terrestrial networks. The guidelines are intended to be highly recommended rules for the usage of the DVB data broadcast specification as put down in EN 301 192 i. As such, they facilitate the eff
27、icient and reliable implementation of data broadcast services. The rules apply to broadcasters, network operators as well as manufacturers. The rules are specified in the form of constraints on the data broadcast implementation. The specification of these functions in no way prohibits end consumer d
28、evice manufacturers from including additional features, and should not be interpreted as stipulating any form of upper limit to the performance. NOTE: It is highly recommended that the end consumer device should be designed to allow for future compatible extensions to the DVB data broadcast specific
29、ation. All the fields “reserved“ (for ISO), “reserved-futureuse“ (for ETSI), and “user defiied“ in the EN 301 192 i should be ignored by end consumer devices not to make use of them. The “reserved“ and “reserved-futureuse“ field may be specified in the future by the respective bodies, whereas the “u
30、ser defiied“ field will not be standardized. This guidelines document uses the terminology defined in EN 301 192 i and should be read in conjunction with that document. 2 Re fe re nces For the purposes of this Technical Report (TR) the following references apply: il ETSI EN 301 192 (V1.3.1): “Digita
31、l Video Broadcasting (DVB); DVB specification for data broadcasting“. ISO/IEC 13 8 18-1 : “Information technology - Generic coding of moving pictures and associated audio information: Systems“. 21 31 ETSI ETS 300 802: “Digital Video Broadcasting (DVB); Network-independent protocols for DVB interacti
32、ve services. 41 ISO/IEC 138 18-6: “Information technology - Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC“. 51 61 IETF RFC 791 (1981): “Internet Protocol“, J. Postel. ETSI EN 300 468: “Digital Video Broadcasting (DVB); Specification for Service In
33、formation (SI) in DVB systems“. ETSI EN 300 472: “Digital Video Broadcasting (DVB); Specification for conveying ITU-R System B Teletext in DVB bitstreams“. ETSI EN 300 743 : “Digital Video Broadcasting (DVB); Subtitling system“. OMG Specification (1995): “The Common Object Request Broker: Architectu
34、re and Specification“, Revision 2 .O. IETF RFC 1521 (1993): “MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for SpeciSling and Describing the Format of Internet Message Bodies“, N. Borenstein, N. Freed. IETF RFC 1590 (1994): “Media Type Registration Procedure“, J. Postel (Updates
35、RFC 1521). James Rumbaugh (1995): “OMT: The Object Model“, JOOP 7.8. IETF RFC 11 12 (1988): “Host extensions for IP multicasting“, S.E. Deering. 71 SI 91 lo1 111 121 i31 ETSI 7 ETSI TR 101 202 VI .2.1 (2003-01) i41 IETF RFC 2464 (1 998): “Transmission of IPv6 Packets over Ethernet Networks“, M.Crawf
36、ord. 3 3.1 Definitions and abbreviations De fi nit ions For the purposes of the present document, the following terms and definitions apply: broadcaster (SERVICE Provider): organization which assembles a sequence of events or programmes to be delivered to the viewer based upon a schedule component (
37、ELEMENTARY Stream): one or more entities which together make up an event, e.g. video, audio, teletext, data Digital Storage Media - Command e.g. a data carousel like application can be based on top of Data piping and an IP broadcast one on top of Data streaming. Such arrangements are of course part
38、of service specific choices. 4.2.1 Fragmentation of datagrams Generally data of any kind of protocols are transmitted in packetized form (“datagrams“). These datagrams may have different length. If the data are not packetized or the packetization method is irrelevant or hidden to the DVB transmissio
39、n chain the most appropriate way of transmission is the Data Pipe (see EN 301 192 i, clause 4). ETSI 11 ETSI TR 101 202 VI .2.1 (2003-01) On the layer of MPEG-2 Transport Stream data are transmitted within packets with a fixed length of 188 bytes (1 84 bytes payload), therefore datagrams of higher l
40、ayers must be fragmented at the transmission side and be re-assembled at the reception. For fragmentation of the datagrams there are three possible ways (see also figure 4.1): Private mechanisms based on the Data Pipe. MPEG-2 Packetized Elementary Streams (PES). MPEG-2 Sections. MPEG-2 PES provides
41、a mechanism to transmit datagrams of variable size with a maximum length of 64 kbytes. Additionally it provides the facility to synchronize different data streams accurately (as used in MPEG for synchronization of Video and Audio), therefore it was chosen by DVB for the transmission of synchronous a
42、nd synchronized but also asynchronous data streams (see EN 301 192 i, clauses 5 and 6). MPEG-2 Sections can be used to transmit datagrams of variable size with a maximum length of 4 kbytes. The transmission is asynchronous. MPEG-2 Sections are built in a way that MPEG-2 demultiplexers available on t
43、he market can filter out single sections in hardware which may reduce the required software processing power of the receiver. This is the main reason why the MPEG-2 Sections have been chosen as the mechanism for the transmission of encapsulated protocols and data carousels. For data broadcasting ser
44、vices in the DVB framework the data-broadcast-id-descriptor (EN 300 468 6) can be present in the PMT, i.e. use of this descriptor is optional. 4.3 Data Pipe The Data Pipe is an asynchronous transportation mechanism for data. The data are inserted directly in the payload of MPEG-2 Transport packets.
45、There is no mechanism for fragmentation and reassembly of datagrams defined. This - if required - is part of the application definition. For instance, the payload-uni-start-indicator could be used to signal the start of a datagram in a packet while the transport-priority field could signal the end o
46、f a datagram. The continuity-counter shall be used as defined by MPEG (ISO/IEC 13818-1 2, clause 2.4.3). 4.3.1 Usage of the adaptation field The main use of the Adaptation Field is stuffing. However, it is possible to use it for other purposes, e.g. the transmission of PCR. 4.4 AsynchronouslSynchron
47、izedlSynchronous Data Streaming 4.4.1 Usage of the adaptation field According to ISO/IEC 13818-1 2, clause 2.4.3 a PES packet always has to start at the first payload byte of an MPEG-2 Transport Packet. This means that for PES packets which are not aligned with the MPEG-2 Transport Packet there is s
48、tuffing necessary. Since MPEG only allows stuffing bytes at the end of the packet for sections and not for PES (see ISO/IEC 13818-1 2, clause 2.4.3.3) stuffing can only be achieved by using Adaptation fields. This is no real constraint for the performance of a decoder since most demultiplexer implem
49、entations provide the automatic extraction of Adaptation Fields and therefore no additional processing power is required. An Adaptation Field that is only used for stuffing can be created by setting all adaptation field flags (discontinuity-indicator, random-access-indicator, elementary-stream-priority-indicator, PCR-flag, OPCR-flag, splicing-point-flag, transport-private-data-flag, adaptation-field-extension-flag) to “O“ and inserting the number of required stuffing bytes. The elementary-stream-priority-indicator and the adaptation-field-extension-
