This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/DVB/TR 101 202 Implementation guidelines for Data Broadcasting v1.2.1 (2003-01).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- ETSI TR 101 202 V1.2.1 (2003-01) Technical Report Digital Video Broadcasting (DVB); Implementation guidelines for Data Broadcasting European Broadcasting Union Union Européenne de Radio-Télévision EBU·UER 2 ETSI TR 101 202 V1.2.1 (2003-01) Reference RTR/JTC-DVB-142 Keywords broadcasting, data, digital, DVB, TV, video ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case 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 the 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 http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: editor@etsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2003. © European Broadcasting Union 2003. All rights reserved. TM TM TM DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members. TM TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. TM 3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI 3 ETSI TR 101 202 V1.2.1 (2003-01) Contents Intellectual Property Rights ................................................................................................................................5 Foreword.............................................................................................................................................................5 1 Scope ........................................................................................................................................................6 2 References ................................................................................................................................................6 3 Definitions and abbreviations...................................................................................................................7 3.1 Definitions..........................................................................................................................................................7 3.2 Abbreviations .....................................................................................................................................................7 4 Rules of operation ....................................................................................................................................9 4.1 Introduction ........................................................................................................................................................9 4.2 Selection of the appropriate profile ..................................................................................................................10 4.2.1 Fragmentation of datagrams .......................................................................................................................10 4.3 Data Pipe ..........................................................................................................................................................11 4.3.1 Usage of the adaptation field ......................................................................................................................11 4.4 Asynchronous/Synchronized/Synchronous Data Streaming ............................................................................11 4.4.1 Usage of the adaptation field ......................................................................................................................11 4.4.2 Asynchronous Data Streaming ...................................................................................................................12 4.4.3 Synchronous/Synchronized Data Streaming...............................................................................................12 4.4.4 Synchronous Data Streaming......................................................................................................................12 4.4.5 Synchronized Data Streaming.....................................................................................................................13 4.5 Multiprotocol encapsulation.............................................................................................................................13 4.5.1 Overview ....................................................................................................................................................13 4.5.2 Data transport..............................................................................................................................................13 4.5.3 Information in the SI...................................................................................................................................14 4.6 Data carousel ....................................................................................................................................................15 4.6.1 Introduction.................................................................................................................................................15 4.6.2 Data carousel Groups and SuperGroups .....................................................................................................16 4.6.3 Use of the one-layer data carousel ..............................................................................................................16 4.6.4 Use of the two-layer data carousel..............................................................................................................16 4.6.4.1 The data carousel consists of a single group the description of which is too large for a single DownloadInfoIndication message.........................................................................................................16 4.6.4.2 The data carousel delivers a single version of an application but supports a number of different receiver profiles.....................................................................................................................................17 4.6.4.3 The data carousel simultaneously delivers more than one version of an application for a single receiver profile ......................................................................................................................................17 4.6.5 Assignment and use of transactionId values ...............................................................................................17 4.6.6 Use of descriptors specific to the DVB data carousel.................................................................................18 4.6.6.1 Type descriptor .....................................................................................................................................18 4.6.6.2 Name descriptor ....................................................................................................................................19 4.6.6.3 Info descriptor .......................................................................................................................................19 4.6.6.4 Module link descriptor ..........................................................................................................................19 4.6.6.5 CRC32 descriptor..................................................................................................................................19 4.6.6.6 Location descriptor................................................................................................................................19 4.6.6.7 Estimated download time descriptor .....................................................................................................19 4.6.6.8 Group link descriptor ............................................................................................................................19 4.6.6.9 Private descriptor ..................................................................................................................................20 4.6.6.10 Compressed module descriptor .............................................................................................................20 4.6.7 Information in the SI and PSI .....................................................................................................................20 4.6.7.1 Descriptor in SI .....................................................................................................................................20 4.6.7.2 Descriptors in PSI .................................................................................................................................21 4.7 Object carousel .................................................................................................................................................21 4.7.1 Introduction.................................................................................................................................................21 4.7.2 Platform independence ...............................................................................................................................23 4.7.2.1 Overview...............................................................................................................................................23 4.7.2.2 Supported U-U Objects .........................................................................................................................24 ETSI 4 ETSI TR 101 202 V1.2.1 (2003-01) 4.7.2.3 Transmission of objects.........................................................................................................................25 4.7.2.4 Object References .................................................................................................................................26 4.7.2.5 Taps and associations............................................................................................................................28 4.7.3 BIOP Control Structures .............................................................................................................................30 4.7.3.1 Interoperable Object Reference (IOR) ..................................................................................................30 4.7.3.2 BIOP Profile Body ................................................................................................................................31 4.7.3.3 Lite Options Profile Body .....................................................................................................................33 4.7.3.4 Carousel NSAP address ........................................................................................................................34 4.7.4 BIOP Messages...........................................................................................................................................35 4.7.4.1 Directory ...............................................................................................................................................35 4.7.4.2 File ........................................................................................................................................................38 4.7.4.3 Stream ...................................................................................................................................................39 4.7.4.4 Service Gateway ...................................................................................................................................40 4.7.4.5 StreamEvent ..........................................................................................................................................41 4.7.5 Download Data Carousel Messages............................................................................................................42 4.7.5.1 DownloadInfoIndication .......................................................................................................................42 4.7.5.2 DownloadServerInitate .........................................................................................................................43 4.7.5.3 DownloadDataBlock .............................................................................................................................44 4.7.6 MPEG-2 Sections .......................................................................................................................................44 4.7.7 Use of PSI descriptors.................................................................................................................................44 4.7.7.1 Carousel identifier descriptor ................................................................................................................45 4.7.7.2 Association tag descriptor .....................................................................................................................46 4.7.7.3 Stream identifier descriptor...................................................................................................................47 4.7.7.4 Deferred association tags descriptor......................................................................................................48 4.7.8 Information in the SI and PSI .....................................................................................................................48 4.7.8.1 SI Descriptor .........................................................................................................................................48 4.7.8.2 Descriptors in PSI .................................................................................................................................49 4.7.9 Assignment and use of transactionId 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: Encapsulation 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 .............................................................................................60 Annex E: Bibliography ..........................................................................................................................63 History ..............................................................................................................................................................64 ETSI 5 ETSI TR 101 202 V1.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 members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). All published 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é Européen de Normalisation ELECtrotechnique (CENELEC) 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 Memorandum 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 programme-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-1218 GRAND SACONNEX (Geneva) Switzerland Tel: +41 22 717 21 11 Fax: +41 22 717 24 81 Founded in September 1993, the DVB Project is 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 market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the broadcast industry. ETSI 6 ETSI TR 101 202 V1.2.1 (2003-01) 1 Scope The present document provides implementation guidelines for the use and implementation of the Digital Video Broadcasting (DVB) 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 [1]. As such, they facilitate the efficient 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 device 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 specification. All the fields "reserved" (for ISO), "reserved_future_use" (for ETSI), and "user defined" in the EN 301 192 [1] should be ignored by end consumer devices not to make use of them. The "reserved" and "reserved_future_use" field may be specified in the future by the respective bodies, whereas the "user defined" field will not be standardized. This guidelines document uses the terminology defined in EN 301 192 [1] and should be read in conjunction with that document. 2 References For the purposes of this Technical Report (TR) the following references apply: [1] ETSI EN 301 192 (V1.3.1): "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". [2] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated audio information: Systems". [3] ETSI ETS 300 802: "Digital Video Broadcasting (DVB); Network-independent protocols for DVB interactive services. [4] ISO/IEC 13818-6: "Information technology - Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC". [5] IETF RFC 791 (1981): "Internet Protocol", J. Postel. [6] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems". [7] ETSI EN 300 472: "Digital Video Broadcasting (DVB); Specification for conveying ITU-R System B Teletext in DVB bitstreams". [8] ETSI EN 300 743: "Digital Video Broadcasting (DVB); Subtitling system". [9] OMG Specification (1995): "The Common Object Request Broker: Architecture and Specification", Revision 2.0. [10] IETF RFC 1521 (1993): "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", N. Borenstein, N. Freed. [11] IETF RFC 1590 (1994): "Media Type Registration Procedure", J. Postel (Updates RFC 1521). [12] James Rumbaugh (1995): "OMT: The Object Model", JOOP 7.8. [13] IETF RFC 1112 (1988): "Host extensions for IP multicasting", S.E. Deering. ETSI 7 ETSI TR 101 202 V1.2.1 (2003-01) [14] IETF RFC 2464 (1998): "Transmission of IPv6 Packets over Ethernet Networks", M.Crawford. 3 Definitions and abbreviations 3.1 Definitions 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 (ELEMENTARY Stream): one or more entities which together make up an event, e.g. video, audio, teletext, data Digital Storage Media - Command & Control (DSM-CC): Refers to the standard ISO/IEC 13818-6. LLC/SNAP: Refers to the standards ISO/IEC 8802-2 and ISO/IEC 8802-1. MPEG-2: Refers to the standard ISO/IEC 13818. Systems coding is defined in part 1. Video coding is defined in part 2. Audio coding is defined in part 3. multiplex: stream of all the digital data carrying one or more services within a single physical channel section: syntactic structure used for mapping all service information into ISO/IEC 13818-1 Service Information (SI): digital data describing the delivery system, content and scheduling/timing of broadcast data streams etc. NOTE: It includes MPEG-2 Program Specific Information (PSI) together with independently defined extensions. sub-table: sub-table is comprised of a number of sections with the same value of table_id, table_id_extension and version_number NOTE: The table_id_extension field is equivalent to the fourth and fifth byte of a section when the section_syntax_indicator is set to a value of "1". table: table is comprised of a number of sections with the same value of table_id transport stream: data structure defined in ISO/IEC 13818-1 NOTE: It is the basis of the Digital Video Broadcasting (DVB) standards. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: API Application Portability Interface BIOP Broadcast Inter ORB Protocol bit/s bits per second bslbf bit string, left bit first CDR Common Data Representation CORBA Common Object Request Broker Architecture CRC Cyclic Redundancy Check DDB DownloadDataBlock message of DSM-CC DII DownloadInfoIndication message of DSM-CC DSI DownloadServerInitiate message of DSM-CC DSM-CC U-N DSM-CC User to Network DSM-CC U-U DSM-CC User to User DSM-CC Digital Storage Media - Command & Control DVB Digital Video Broadcasting EIT Event Information Table ETSI 8 ETSI TR 101 202 V1.2.1 (2003-01) GIF Graphics Interchange Format HTML HyperText Markup Language IDL Interface Definition Language IETF Internet Engineering Task Force IOR Interoperable Object Reference IP Internet Protocol JPEG Joint Photographic Experts Group LLC Logical Link Control MAC Medium Access Control MPEG Moving Pictures Expert Group MTU Maximum Transport Unit NPT Normal Play Time NSAP Network Service Access Point OMG Object Management Group OMT Object Modelling Technique ORB Object Request Broker PAT Program Association Table PCR Program Clock Reference PES Packetized Elementary Stream PID Packet Identifier PLL Phase Locked Loop PMT Program Map Table ppm parts per million PSI Program Specific Information PTS Presentation Time Stamp RFC Request For Comments SDT Service Description Table SI Service Information SIS Systems for Interactive Services SNAP SubNetwork Attachment Point TS Transport Stream uimsbf unsigned integer, most significant bit first ETSI 9 ETSI TR 101 202 V1.2.1 (2003-01) 4 Rules of operation This clause contains some recommendations on the usage of the Digital Video Broadcasting (DVB) data broadcasting specification. 4.1 Introduction Figure 4.1 gives an overview of the data broadcast specification as put down EN 301 192 [1]. Applications Application level interface service service service service service service specific specific specific specific specific specific datagram DVB spec. (eg object IP/IPX) DVB data DSM-CC DVB multi object carousel protocol DVB data DSM-CC DSM-CC DSM-CC data data DVB streaming priv. data data piping PES Section MPEG-2 Transport Stream Application area: Data Data Multi-protocol Data Object Registered Piping Streaming encapsulation Carousel Carousel service data_broadcast_id: 0x0001 0x0002 0x0005 0x0006 0x0007 t.b.d 0x0003 0x0004 : Service specific : DVB defined : Other standards (IETF,ISO) : DSM-CC defined Figure 4.1: Graphical overview and relation to other standards The basis of the complete specification is formed by the MPEG-2 Transport Stream (TS) as defined in ISO/IEC 13818-1 [2]. Data information can be transported within this MPEG-2 TS by means of application areas. The application areas are: • Data piping. • Data streaming. • Multiprotocol encapsulation. • Data carousel. Furthermore in figure 4.1 the object carousel is depicted. This carousel is used by the specification for Network Independent Protocols for Interactive Services ETS 300 802 [3]. A registered service is shown on the right hand side of the figure. DVB allows to register private implementations for data broadcast services, as described in annex A of EN 301 192 [1]. ETSI 10 ETSI TR 101 202 V1.2.1 (2003-01) Figure 4.1 shows what is standardized by which body. ISO has standardized the MPEG-2 TS in ISO/IEC 13818-1 [2] and the DSM-CC framework in ISO/IEC 13818-6 [4]. IETF has standardized the Internet Protocol (IP) in RFC 791 [5]. DVB has specified within the data broadcast specification EN 301 192 [1] the DVB data piping, DVB data streaming, DVB multiprotocol encapsulation, DVB data carousel and DVB object carousel parts. Within figure 4.1 the encapsulation of the Internet Protocol (IP) is just an example. Other protocols can also be encapsulated. As shown in figure 4.1, the specification for data broadcast EN 301 192 [1] specifies different service levels for all application areas. The data piping specification does not give much information on how to get the data out of the MPEG-2 TS. It more or less only specifies how to put data into MPEG-2 Transport Stream packets. In comparison with the other application areas a lot of service specific hard- and/or software has to be built to get a service running. The data streaming specification gives some more functionality, especially for timing. It is possible to do asynchronous data broadcast, synchronized broadcast or synchronous broadcast. The specification is based on PES packets as defined in MPEG-2 ISO/IEC 13818-1 [2]. The multiprotocol encapsulation, data carousel and object carousel application areas specifications are all built using the DSM-CC framework of MPEG-2 ISO/IEC 13818-6 [4]. It is based on MPEG-2 private sections as defined in MPEG-2 ISO/IEC 13818-1 [2]. DVB has added specific information to get the framework working in the DVB environment, especially in conjunction with the Service Information specification EN 300 468 [6]. In the specification for data broadcast EN 301 192 [1], every application area is defined by two parts as shown in figure 4.2. Control Transport Application Areas #a #b #c #d MPEG 2 TS Control: SI and PSI Transport: Databroadcast transport specification Figure 4.2: Transport and control specification parts The control specification is part of the EN 300 468 [6] Service Information specification, the transport part of the specification is part of the EN 301 192 [1] data broadcast specification. The following clauses give implementation guidelines how to use the different application areas. 4.2 Selection of the appropriate profile As shown in figure 4.1 there are different ways to transmit data via MPEG-2 DVB Transport Streams. The mechanisms have different characteristics concerning filtering, overhead, size, etc. The selection of the appropriate mechanism has to be based on the specific requirements of the target application. The level of detail of the specification varies for the different profiles. In case of Multiprotocol Encapsulation (see EN 301 192 [1], clause 7) and Data Carousels (see EN 301 192 [1], clause 9) the specification is very detailed, which only requires very few application specific definitions, in case of the other profiles there is much freedom. Furthermore, it is possible to use application areas for other purposes than the recommended ones; 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 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 transmission chain the most appropriate way of transmission is the Data Pipe (see EN 301 192 [1], clause 4). ETSI 11 ETSI TR 101 202 V1.2.1 (2003-01) On the layer of MPEG-2 Transport Stream data are transmitted within packets with a fixed length of 188 bytes (184 bytes payload), therefore datagrams of higher layers 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 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 and synchronized but also asynchronous data streams (see EN 301 192 [1], 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 the 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 services 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. There is no mechanism for fragmentation and reassembly of datagrams defined. This - if required - is part of the application definition. For instance, the payload_unit_start_indicator could be used to signal the start of a datagram in a packet while the transport_priority field could signal the end of 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 Asynchronous/Synchronized/Synchronous 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 stuffing 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 implementations 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 "0" and inserting the number of required stuffing bytes. The elementary_stream_priority_indicator and the adaptation_field_extension_flag shall be set to zero, since the affiliated features have no meaning for Data Streaming. ETSI 12 ETSI TR 101 202 V1.2.1 (2003-01) 4.4.2 Asynchronous Data Streaming Asynchronous Data Streaming is used in the case that the PES mechanism is of advantage for applications that need the asynchronous transmission of datagrams. Since no synchronization is necessary for this kind of transmission the stream_id "private_stream_2" (see ISO/IEC 13818-1 [2]) has been chosen which implicitly excludes the usage of the PES packet header fields. Therefore the PES_packet_length field is immediately followed by the datagram. The definition of the datagram format is part of the private implementation ant therefore not subject of the DVB specification. 4.4.3 Synchronous/Synchronized Data Streaming In order to meet the requirements of the Synchronous and Synchronized Data Streaming an additional header, specific to this DVB application profile has been defined (see EN 301 192 [1], table 1). The field stream_id shall be set to "private_stream_1", allowing for the usage of the PES header fields, especially the PTS. Usage of the time stamps requires the definition of Access Units. Since this is application dependant it has not been defined within the DVB data broadcasting specification. The first byte of this header (which is from MPEG-2 PES point of view the first payload byte) contains the data_identifier. It is defined in accordance with the specifications for embedding of EBU-data (EN 300 472 [7]) and DVB-subtitling (EN 300 743 [8]) and indicates the type of Data Streaming (synchronous /synchronized). A combination of Synchronized and Synchronous Data Streaming in the same PES packet is not allowed. However, both types of streaming data can be carried as part of a same program in separate PID's. The field sub_stream_id may be used for private definition. The two flags PTS_extension_flag and output_data_rate_flag indicate the existence of an output data rate field and of a field for PTS extension. The usage of these fields is explained below. The PES_data_packet_header_length indicates the length of the header and allows the addition of private bytes in the header. The DTS field in PES header is of no use while the PTS shall be coded in the same way as defined by MPEG in ETS 300 802 [3]. 4.4.4 Synchronous Data Streaming Synchronous data streaming may be used if the output data rate at the receiver side needs to be very accurate. The receiver clock is synchronized by the PCR. The 9 bit PTS_extension is needed to position data access units (a bit, a byte or few bytes depending on how one defines access units) very accurately over a large range of data rates (kbit/s to Mbit/s). The 9 bits extends the accuracy of the PTS clock from 11 µs to the same accuracy as a 27 MHz clock (37 ns). Precise positioning of the data is required if multiple data decoders receiving the same data services (and knowing the latency through the process) have to output the data at the same time in an aligned way, or if it is required to maintain synchronization in the data output stream following a temporary loss of signal. The field output_data_rate is used in order to specify the output data rate for the synchronous data stream. With the 28 bit accuracy (instead of the 400 bit/s resolution of 22 bit ES_rate in PES header) it is possible to implement PLL (with clock down conversion) with a ratio of data output rate to 27 MHz (±30 ppm) covering a wide range of data rates. The output_data_rate field conveys the bit rate of the regenerated signal for a synchronous data stream. The encoding of the bit rate of the data stream into the output_data_rate field depends on the application. Applications which require bit rates which are a multiple of 1 bit per second may encode the data streams bit rate into the output_data_rate field directly with the units of output_data_rate as bits/second. Applications which require a continuous range of bit rates to be regenerated within the 30 ppm tolerance specified by MPEG for the 27 MHz system_clock_frequency may encode the bit rate of the data stream into the output_data_rate field as: • output_data_rate = bit rate x M/system_clock_frequency; ETSI 13 ETSI TR 101 202 V1.2.1 (2003-01) where M is chosen to be a number sufficiently large to express the range of bit rates required for the application with the desired bit rate accuracy. The practical range of bit rates for synchronous data streaming with a system_clock_frequency of 27 MHz is 1 bit/s to 27 Mbit/s. Note that the decoder model described in clause 12 of EN 301 192 [1] is not necessarily applicable if the output data rate field is used. ES_rate in the PES header can be used without the output_data_rate field in the PES data_packet for applications where the 400 bit/s accuracy of ES_rate is adequate (e.g. T1 and E1). If both ES_rate and output_data_rate are present in an encoded stream, the decoder can use either of the rates. The recommended buffer size for synchronous data streaming is 4 800 byte. This gives sufficient capacity for a typical maximum multiplexing jitter of 4 ms and a bit rate up to 9 Mbit/s. 4.4.5 Synchronized Data Streaming Synchronized Data Streaming is used when the data stream shall be synchronized with another MPEG-2 PES stream. 4.5 Multiprotocol encapsulation 4.5.1 Overview The multiprotocol encapsulation provides a mechanism for transporting data network protocols on top of the MPEG-2 Transport Streams in DVB networks. It has been optimized for carriage of the Internet Protocol (IP) (RFC 791 [5]), but can be used for transportation of any other network protocol by using the LLC/SNAP encapsulation. It covers unicast (datagrams targeted to a single receiver), multicast (datagrams targeted to a group of receivers) and broadcast (datagrams targeted to all receivers). 48-bit MAC addresses are used for addressing receivers. However, DVB does not specify how the MAC addresses are allocated to the receivers. Due to the broadcast nature of DVB networks, security of the data is very important. The encapsulation allows secure transmission of data by supporting encryption of the packets and dynamically changing MAC addresses. 4.5.2 Data transport The datagrams are transported in datagram_sections which are compliant to the DSMCC_section format for private data. The section format provides an efficient format for mapping the datagrams to the MPEG-2 Transport Stream packets and support filtering of datagrams based on the MAC address using existing hardware or software demultiplexers. The section format permits fragmenting datagrams into multiple sections. If the length of the datagram is less or equal than 4 080 bytes (including the possible LLC/SNAP header), the datagram shall be sent in one section. In case of IP and the LLC/SNAP header being omitted, the MTU shall be set to 4 080 bytes or less, so that the datagrams will never be fragmented. In case of IP and the LLC/SNAP header being present the MTU shall be set to 4 074 or less. The MAC address has been divided into 6 bytes that are located in two groups. The reason for this is that the bytes 5 and 6 are in place of the table_id_extension field of the DSMCC_section while bytes 1, 2, 3 and 4 are in the payload area of the DSMCC_section. MSB LSB 48-bit MAC address byte: 1 2 3 4 5 6 table .... section MAC MAC .... last MAC MAC MAC MAC .... section : id length address address reserved section address address address address 6 5 number 4 3 2 1 ETSI 14 ETSI TR 101 202 V1.2.1 (2003-01) Some demultiplexers are able to filter bytes 5 and 6 with hardware while filtering bytes 1, 2, 3 and 4 is done in software. It is recommended that the two bytes of the MAC address which most probably differentiate the receivers are put to the bytes 5 and 6. This is normally the case with IEEE MAC addresses and it is recommended that all MAC addresses are constructed in this way. Payload scrambling is controlled by a 2-bit field payload_scrambling_control. If the value of these bits is '00', the payload is not scrambled. If the payload is scrambled, the scrambling algorithm is private to the service. The mechanism how the scrambling method is signalled to the receiver is not defined by DVB. MAC address scrambling provides further security by dynamically changing MAC addresses. By changing the control word that is used for scrambling the MAC addresses periodically, monitoring of the stream can be prevented as the destination of a particular datagram can not be determined by observing the MAC addresses. It also strengthens the security as collecting datagrams destined to a single receiver is difficult. The delivery mechanism of control words used for scrambling the MAC addresses is not defined by DVB. Address scrambling is controlled in the section header by a 2-bit field address_scrambling_control. If the value is these bits is '00', the MAC address is not scrambled. It should be noted that using MAC address scrambling without payload scrambling is of no use, since the protocol address that is part of the datagram is visible in the clear. The LLC/SNAP encapsulation provides a multiprotocol encapsulation that can be used for carrying any network protocol, including IP. There is an optimization for carrying IP that allows transmitting IP datagrams without the LLC/SNAP header. This is controlled by the LLC_SNAP_flag bit in the section header. If the value of the bit is '0', the payload contains a bare IP datagram. If the value of the bit is '1', the payload contains an LLC/SNAP encapsulation which consists of the LLC/SNAP structure LLC_SNAP() followed by the datagram bytes. The optimized way of carrying IP can be used for both IPv4 and IPv6. The section_number and last_section_number fields must both be '0' when carrying the IP protocol. The section may contain stuffing after the datagram. The stuffing bytes may be used, for example, for making the payload of the section to be multiple of a block size when a block encryption code is used. The value of these bytes is not specified and in case of payload encryption they should not be assigned a fixed value as it would help breaking the encryption. The datagram_section has a checksum or a CRC_32 in the end depending on the value of the section_syntax_indicator. It is recommended to use the CRC_32 as it provides a slightly better protection against bit errors as it can be checked by hardware in most hardware demultiplexers while the checksum has to be normally checked by software. 4.5.3 Information in the SI For services using multiprotocol encapsulation, the data_broadcast_descriptor shall be present in the SDT or the EIT. The multiprotocol_encapsulation_info structure [1] is carried in the selector_byte field. MAC_address_range field is used for signalling to the receiver which bytes of the MAC_address are significant for filtering. The significant bytes of the MAC address are at the least significant end of the MAC address. The MAC_IP_mapping_flag signals whether the mapping of multicast IP addresses to MAC addresses is done according to RFC 1112 [13] for IPv4 multicast addresses and RFC 2464 [14] IPv6 multicast addresses. It should be noted that as DVB does not define that the MAC addresses are used as defined by IEEE, alternative, possibly more optimized, mappings are allowed. Alignment indicator indicates if the datagram_section is 8-bit aligned or 32-bit aligned to the Transport Stream packets. 8-bit alignment essentially means that it is not aligned. Alignment is useful in implementations which input Transport Stream packets and rely on the beginning of the section being on a 32-bit boundary for enabling efficient comparison operations in filtering. The alignment is performed using the adaptation field of the Transport Stream packet and / or stuffing bytes at the end of the sections. The max_sections_per_datagram field defines the maximum number of section that are used for carrying a single datagram (for IP this is restricted to be 1). This defines the maximum length of the datagram. Typically a receiver has to combine the fragments of the datagram before passing it on, so this field defines the size of the buffer that the receiver has to have for combining a datagram of the maximum length. ETSI 15 ETSI TR 101 202 V1.2.1 (2003-01) 4.6 Data carousel 4.6.1 Introduction The data carousel is a transport mechanism that allows a server (the broadcast component of an application) to present a set of distinct data modules to a decoder (a program that is run by a receiver) by cyclically repeating the contents of the carousel, one or more times. If an application decoder wants to access a particular module from the data carousel, it may simply wait for the next time that the data for the requested module is broadcast. A good example of the data carousel concept that is widely understood is the Teletext system. In this system, a complete set of Teletext pages is cyclically broadcast in some of the lines of an analogue video signal that are not part of the active picture. When users requests a page, they must usually wait for the next time the page is broadcast. The maximum length of time the user has to wait can be determined by the time it takes for a complete cycle of the carousel, which in turn can be deduced from the size of the carousel and the rate at which data can be broadcast. M8-1 M8-2 M8-0 M8-3 M3-2 M8-4 M3-1 M8-5 M3-0 M8-6 M2-0 M8-7 M8-8 download data message (MX-Y): DownloadDataBlock () block_size X = module_id cycle_time Y = block_number M2: "file1" M2_size M3: "file2" download control message: M3_size DownloadServerInitiate () or DownloadInfoIndication () M8: "file3" M8_size Figure 4.3: Cyclic transmission of information in a data carousel Within a data carousel the data is structured into Modules, depicted in figure 4.3 as M2, M3 and M8. This could simply be the contents of a number of files, say "file1", "file2" and "file3" as in this example. Each Module is divided up to form the payload of one or more download data messages each defined using the DSM-CC DownloadDataBlock syntax. The number of such messages depends on the size of the Module and the maximum payload of each download data message. Information describing each Module and any logical grouping is provided by download control messages, defined using either the DSM-CC DownloadServerInitiate or DownloadInfoIndication syntaxes as appropriate. In this example each download message has been inserted only once and DownloadDataBlocks from the same Module have been inserted adjacent to one another and in order. There are however, no restrictions on how often a particular message is inserted into a single loop of the carousel and the order and relative position of messages. This allows the data carousel to be created in whatever way best suits a particular use. In addition the frequency and order of insertion of messages into the data carousel do not need to be fixed and can change dynamically as required. ETSI 16 ETSI TR 101 202 V1.2.1 (2003-01) 4.6.2 Data carousel Groups and SuperGroups A logically consistent set of Modules within the data carousel may be clustered together to form a Group as defined in EN 301 192 [1]. The description of the Modules in the Group is provided by a DownloadInfoIndication message. There are no restrictions on how Modules are associated into Groups and, in particular, one Module may be a member of more than one Group. Groups may be clustered together to form a SuperGroup as defined in EN 301 192 [1]. The description of the Groups in the SuperGroup is provided by a DownloadServerInitiate message. NOTE: A SuperGroup may contain any number of Groups, even only one. The structure of the data carousel (in Groups and SuperGroups) does not necessarily reflect the structure of the content. For purpose of clarification the exact DSM-CC messages are depicted in annex A. Annex B gives information about the inclusion of DSM-CC messages in MPEG-2 sections. 4.6.3 Use of the one-layer data carousel If the data carousel consists only of a single Group and the complete description of the Group can be contained within a single DownloadInfoIndication message (i.e. one-layer of control information) then a one-layer data carousel can be used. In all other cases a two-layer data carousel should be used. The DownloadInfoIndication message is the only download control message in the data carousel and is referred to as the top-level control message. NOTE: Although there is only one defined download control message there may be multiple insertions of the same message in a single loop of the data carousel. An example where a one-layer data carousel would be appropriate would be the delivery of a small HTML based application (say 10 to 20 Modules) authored to support HTML V1.0 only. 4.6.4 Use of the two-layer data carousel A two-layer data carousel has one or more DownloadInfoIndication messages and a single DownloadServerInitiate message (i.e. two-layers of control information). The DownloadServerInitiate message is referred to as the top-level control message. A two-layer data carousel should be used in the situations described below. These are the Guidelines for specific circumstances and can be mixed together as necessary. 4.6.4.1 The data carousel consists of a single group the description of which is too large for a single DownloadInfoIndication message In this situation as many DownloadInfoIndication messages as necessary should be used to describe all the Modules in the large Group. This effectively divides the large Group up into a number of smaller Groups each defined by its own DownloadInfoIndication message. Since a data carousel can only have a single top-level control message this imposes the use of a two-layer carousel. To be able to recreate the original large Group the new smaller Groups need to be linked together. This is achieved by including group_link_descriptor() in the description of each of the new small Groups in the DownloadServerInitiate message. An example would be the delivery of a large HTML based application (say 500+ Modules) authored to support HTML V1.0 only. ETSI 17 ETSI TR 101 202 V1.2.1 (2003-01) 4.6.4.2 The data carousel delivers a single version of an application but supports a number of different receiver profiles In this situation the data carousel should consist of a Group for each different receiver profile that is to be supported, with common Modules shared amongst more than one Group. An example would be the delivery of a small HTML based application (say 10 to 20 Modules) authored to support HTML V1.0, V2.0 and V3.0. The data carousel would be structured as a SuperGroup containing three Groups. Many of the Modules would be common to all three Groups, e.g. GIFs and JPEGs, but some would be specific to only one Group, e.g. a particular HTML version of a page. The groupCompatability structure associated with each Group would be used to determine which Group should be used for a given receiver profile. 4.6.4.3 The data carousel simultaneously delivers more than one version of an application for a single receiver profile In this situation the data carousel should consist of a Group for each version of the application being delivered. Since there is no Group versioning mechanism available, the DownloadServerInitiate message should only reference the Group that describes the most recent version. This means that new viewers who access the data carousel via the top-level control message will automatically use this version. If a new version of the application is to be added to the data carousel whilst still delivering existing versions then a new Group should be created. The DownloadServerInitiate message should be updated to remove any reference to the previous "most recent" Group and now reference the new "most recent" Group. This imposes the restriction that the receiver must store locally the relevant top-level (DownloadServerInitiate) control message if it wishes to continue to access an older version still being broadcast. NOTE: The transactionId field in the data_broadcast_descriptor could be used to point directly at the DownloadInfoIndication message that describes an older version of the Group still in the data carousel. An example would be using the receiver as a software download interface to a mass storage device where it is desirable to continue to broadcast a large file to completion even though a more recent version of the same file is also being broadcast. 4.6.5 Assignment and use of transactionId values The use of the transactionId in the DVB data carousel is inherited from its use as defined by the DSM-CC specification, and as such it can appear somewhat complex. The transactionId has a dual role, providing both identification and versioning mechanisms for download control messages, i.e. DownloadInfoIndication and DownloadServerInitiate messages. The transactionId should uniquely identify a download control message within a data carousel, however it should be "incremented" whenever any field of the message is modified. NOTE: The term "incremented" is used in the DSM-CC specification. Within the scope of the DVB data carousel this should be interpreted as "changed". The transactionId has been split up into a number of sub-fields defined in table 4.1. This reflects the due role of the transactionId (outlined above) and constraints imposed by DVB to reduce the minimum level of filtering required by receivers. However, to increase interoperability the assignment of the transactionId has been designed to be independent of the expected filtering in target receivers. ETSI 18 ETSI TR 101 202 V1.2.1 (2003-01) Table 4.1: Sub-fields of the transactionId Bits Value Sub-field Description 0 User-defined Updated flag This must be toggled every time the control message is updated 1 to 15 User-defined Identification This must and can only be all zeros for the top-level control message. All non-top-level control messages must have one or more non-zero bit(s). 16 to 29 User-defined Version This must be incremented/changed every time the control message is updated. 30 to 31 Bit 30 - zero Originator This is defined in the DSM-CC specification Bit 31 - non-zero (ISO/IEC 13818-6 [4]) as 0x02 if the transactionId has been assigned by the network - in a broadcast scenario this is implicit. Due to the role of the transactionId as a versioning mechanism any change to any message in the data carousel will cause the transactionId of the top-level control message to be incremented. The change propagates up through the structure of the data carousel as follows. Any change to a Module will necessitate incrementing its moduleVersion field. This change must be reflected in the corresponding field in the description of the Module in the DownloadInfoIndication message(s) that describes any Group(s) that includes it. Since a field in the DownloadInfoIndication message is changed its transactionId must be incremented to indicate a new version of the message. Again (in the case of a two-layer data carousel) this change must be reflected in the corresponding field in the description of the Group in the DownloadServerInitiate message that describes the SuperGroup. Since fields in the DownloadServerInitiate message have changed its transactionId must also be incremented. This is useful since just by looking at the transactionId of the top-level control message a change to any message in the data carousel can be detected. If the transactionId of any control message is referenced in the corresponding field of a data_broadcast_descriptor in SI (see EN 300 468 [6], clause 6.2.6) then this will need to be updated to reflect any changes. One consequence of this is that changes to the content of the data carousel may necessitate re-acquisition of the modified SI tables. Due to the repetition rate of SI which can be up to 2 s, this may be an undesired side-effect that reduces the speed of response of dynamic data services. To avoid this behaviour the value of 0xFFFFFFFF for the contents of the transactionId field in the data_broadcast_descriptor can be used to indicate any top-level control message is valid. The encapsulation of download control messages within MPEG-2 Transport Streams is defined in the DSM-CC specification. It specifies that the 2 least significant bytes of the transactionId field are copied into the table_id_extension field of the DSMCC_section header. This means that if the PID on which the DVB data carousel is being broadcast is known the top-level control message can be located without knowing its transactionId by setting up the section filters for table_id = 0x3B (download control messages) and table_id_extension = 0x0000 or 0x0001. Table 4.1a reflects the encoding of the section header fields for the different message type. Table 4.1a: Encoding of DSM-CC section_fields Message table_ table_id_extension version_ section_ last_section_ id number number number Download-ServerInitiate 0x3B two LSB bytes of 0x00 0x00 0x00 (DSI) transaction_id of DSI Download-InfoIndication 0x3B two LSB bytes of 0x00 0x00 0x00 (DII) transaction_id of DII Download-DataBlock 0x3C moduled module blockNumber % 256 Max(section_ (DDB) Version % 32 number) 4.6.6 Use of descriptors specific to the DVB data carousel All descriptors described in this clause are optional. 4.6.6.1 Type descriptor With this descriptor the type of the Module or Group of the data carousel is transmitted. Its use is proprietary to the service provider. A string of 'char' fields specifies the type of the module following the Media Type specifications RFC 1521 [10] and RFC 1590 [11]. ETSI 19 ETSI TR 101 202 V1.2.1 (2003-01) 4.6.6.2 Name descriptor With this descriptor the name of the Module or Group in the data carousel is transmitted. Its use is proprietary to the service provider. 4.6.6.3 Info descriptor With this descriptor information about the Module or Group in the data carousel is transmitted. Its use is proprietary to the service provider. 4.6.6.4 Module link descriptor The module_link_descriptor provides information about which Modules of one group are to be linked to get a complete piece of data out of the carousel. Within this descriptor two fields, the position field and the module_id field together indicate what is the first module in the list (position = 0x00, module_id = next module number), what is the next module (position = 0x01, module_id = next module number) and what is the last module (position = 0x02) in the list in case of a multi-module linkage. 4.6.6.5 CRC32 descriptor With this descriptor CRC-32 calculation over a complete Module is indicated. The CRC-32 bits of the Module are part of the descriptor. 4.6.6.6 Location descriptor The location descriptor in a DownloadServerInitiate message indicates on which PID a Group of the data carousel can be found. The DownloadInfoIndication message of the Group to be found has to be on that PID. The same mechanism can be used in the DownloadInfoIndication message to find all the Modules on different PIDs. This is a very powerful means to operate with Groups and Modules for different kinds of users. 4.6.6.7 Estimated download time descriptor The descriptor for estimated download time has been introduced in order to provide an indication to the receiver of the time it will take to download a Module or Group. Some care is needed in how it is used. The download time will obviously be sensitive to the bitrate available to deliver the data carousel. This may be a problem where the data carousel is produced separately from playout of that carousel. If playout of the same data carousel is at one bitrate on one day (e.g. 1 Mbit/s) and at another bitrate on the next day (e.g. 2 Mbit/s) then the estimated download time can not be correct for both (or even either!). NOTE: One approach would be to calculate the value for estimated download time based on the minimum playout bitrate. Obviously it may be more practical in some cases for the receiver to simply indicate how much of the data has been received based on received messages. 4.6.6.8 Group link descriptor The description of the Modules in a Group is provided by a DownloadInfoIndication message. The number of Modules that may be described is determined by the maximum size of such a message and the size of the description of each Module. The encapsulation of such download control messages within MPEG-2 sections limits the maximum size to just under 4 kbytes. The size of a simple Module description (say basic information and a name descriptor of 30 bytes) is about 40 bytes. This means that the DownloadInfoIndication message can describe about 100 Modules which will be sufficient in most cases but not all. In the later situation as many DownloadInfoIndication messages as necessary should be used to describe all the Modules in the large Group. This effectively divides the large Group up into a number of smaller Groups each defined by its own DownloadInfoIndication message. To be able to recreate the original large Group the new smaller Groups need to be linked together. This is achieved by including group_link_descriptor() in the description of each of the new small Groups in the DownloadServerInitiate message. ETSI 20 ETSI TR 101 202 V1.2.1 (2003-01) 4.6.6.9 Private descriptor If a service provider has a need for a private descriptor the syntax of the private descriptor in (EN 301 192 [1], clause 9.2.10) shall be used. 4.6.6.10 Compressed module descriptor Presence of the compressed_module_descriptor indicates that the data in the module has the "zlib" structure as defined in RFC 1951. The ZLIB structure is defined as: zlib structure(){ No. of bytes compression_method 1 flags_check 1 compressed_data n check value 4 } 4.6.7 Information in the SI and PSI Access to the data carousel can be achieved via descriptors in either SI or PSI. This provides some flexibility in how the service is identified. 4.6.7.1 Descriptor in SI For services using data carousel(s), the data_broadcast_descriptor shall be present in the SDT or the EIT, i.e. use of this descriptor is mandatory. The data_broadcast_id field shall be set to 0x0006 to indicate the use of the DVB data carousel. The component_tag will identify the PID on which the data carousel is broadcast by association with a similar tag in the stream_identifier_descriptor() for the particular stream in the PMT. The data_carousel_info structure (EN 301 192 [1]) is carried in the selector_byte field. The carousel_type_id indicates which kind of data carousel is used (figure 4 in EN 301 192 [1]). The use of the transaction_id is depicted above in clause 4.6.4. The time_out_value_DSI and time_out_value_DII gives some indication to the receiver of how long it shall wait before assuming an error condition. The leak_rate is included for optimization of the receiving device. By giving the leak_rate a decoder is able to compute whether a service can be decoded. The leak rate may also be given in a smoothing_buffer_descriptor or a maximum_bitrate_descriptor in which case the values given in both descriptors shall be consistent. However, the usage of a maximum bitrate descriptor is not recommended". The advantages of using an SI based access to the carousel instead of the PSI one are: • The transactionId can be used to explicitly identify the top-level control message in the data carousel. • By including the transactionId field in this descriptor, updates to the data carousel (which will cause a change in transactionId) can be detected by filtering on just the SI. NOTE: This behaviour can be avoided by using the special value of transactionId, 0xFFFFFFFF, as described in clause 4.6.4. • The descriptor does not consume any space in the PSI tables (which may be a scarce resource). The disadvantage of using an SI based access to the carousel instead of the PSI one is: • The repetition period of SI can be up to 2 s which can introduce delay to the initial access of the service. ETSI 21 ETSI TR 101 202 V1.2.1 (2003-01) 4.6.7.2 Descriptors in PSI For services using data carousel(s), the data_broadcast_id_descriptor can be present in the PMT, i.e. use of this descriptor is optional. The data_broadcast_id field shall be set to 0x0006 to indicate the use of the DVB data carousel. The advantage of using this mechanism is that: • The maximum repetition period of PSI is only 0,1 s which allows fast initial access to the service. The disadvantages of this mechanism are that: • There is no transactionId field so explicitly identify the top-level control message. As such only download control messages from a single data carousel may be transported on the identified elementary stream. • The descriptor does not provide any information about the time-out period for download control messages. This information must still be obtained from the descriptor in SI. • The descriptor consumes some space (albeit small) in the PSI tables. • The descriptor in SI must still be included as well. 4.7 Object carousel 4.7.1 Introduction A DSM-CC object carousel facilitates the transmission of a structured group of objects from a broadcast Server to broadcast Receivers (Clients) using directory objects, file objects and stream objects. The actual directory and content (object implementations) are located at the Server. The Server repeatedly inserts the mentioned objects in the DVB compliant MPEG-2 Transport Stream using the object carousel protocol. The object carousel is part of a DVB Service as shown in figure 4.4. The transmitted directory and file objects contain the content of the objects, while the transmitted stream objects are references to other streams in the broadcast. The stream objects may also contain information about the DSM-CC events that are broadcast within a particular stream. DSM-CC events can be broadcast with regular stream data and can be used to trigger DSM-CC applications. ETSI 22 ETSI TR 101 202 V1.2.1 (2003-01) Directory Stream File (reference) Directory Object Carousel Directory File File Stream Directory (reference) Stream+Events File (references) StreamEvents AV Program DVB Service AV Program DVB Service Figure 4.4 Example of including object carousel specification in DVB Services Multiple Clients can recover the object implementations by reading the repeatedly transmitted carousel data, hence mimicking the Server's objects in a local object implementation. The objects in the carousel offer Clients a way to access applications and content used by these applications, more or less as if there was an interactive connection with the Server. The following sections provide guidelines regarding the implementation and use of DSM-CC U-U object carousels in DVB-compliant broadcast networks and in interactive systems compliant to DVB-SIS (ETS 300 802 [3]). This clause focuses on the following subjects: • Platform independence; • Encoding of BIOP control structures used in U-U object carousels; • Encoding of BIOP data messages used in U-U object carousels; • Encoding of Download Data Carousel messages; • Encoding of DSM-CC sections; • Use of PSI descriptors for object carousels; and • Use of SI descriptors for object carousels. The scope is illustrated in figure 4.5 by the area surrounded by thick lines. Figure 4.5 shows the protocol stacks defined by DVB-SIS for both Broadcast and Interactive Networks. ETSI 23 ETSI TR 101 202 V1.2.1 (2003-01) Application(s) U-U API DSM-CC U-U Object Carousel UNO-CDR / RPC (BIOP) (IIOP) Download TCP Data Carousel IP DSM-CC Sections PPP-MP MPEG-2 TS Broadcast Network Interactive Network Figure 4.5: Place of object carousel protocols in the DVB-SIS framework 4.7.2 Platform independence 4.7.2.1 Overview The object carousel specification is platform-independent and compatible with the DSM-CC User-to-User specification of ISO/IEC 13818-6 [4] and with the Object Request Broker (ORB) framework as defined by CORBA (OMG Specification [9]). Within the DSM-CC User-to-User (U-U) system environment, a structured group of objects is referred to as a Service Domain. The Service Domain has a Service Gateway which can be seen as the top-level directory of the structured group of objects. As such the Service Gateway provides a context for the graph of service names (i.e. object names) that is published to the Clients. A Service Domain can be located at a Server in an interactive network as well as on a Server in a broadcast Network. In the latter case the objects within the Service Domain are broadcast by means of an object carousel. NOTE: For naming of objects please refer to annex C of the present document. The data and attributes of a single Object within an object carousel are transmitted in a single message. The message format is specified by the object carousel specification and is referred to as the BIOP message format (Broadcast Inter ORB Protocol). BIOP messages are broadcast in a single Module of a DSM-CC Data Carousel (ISO/IEC 13818-6 [4]). One Module may contain one or more BIOP messages. According to the DSM-CC Data Carousel specification each Module is fragmented into one or more Blocks which are carried in a DownloadDataBlock message. Each DownloadDataBlock message is of the same size (except for the last block of the Module which may be of a smaller size) and is transmitted in turn in an MPEG-2 section as specified in (ISO/IEC 13818-6 [4]). The encapsulation rules for DownloadDataBlock messages in MPEG-2 sections are such that Blocks can be acquired directly from the Transport Stream using hardware filters found generally on demultiplexers. Objects within Service Domains are identified using object references. DSM-CC U-U uses the Interoperable Object Reference (IOR) structure as defined by CORBA. The object reference contains all the information that is necessary to retrieve the object from one or more Servers in the network. The structure in the IOR that contains the location information of a single instance of a stored Object is called a profile body. An IOR may contain multiple Profile Bodies to indicate multiple (network) locations of the object. The object carousel specification uses two Profile Bodies. These two Profile Bodies: BIOPProfileBody and LiteOptionsProfileBody, are used to refer to objects that are located either in the same object carousel or in another object carousel, respectively. The first Profile Body is called the Broadcast Inter ORB Protocol (BIOP) Profile Body and is solely used to refer to objects within the same object carousel (i.e. Service Domain). It facilitates the unique identification of the Object using the identifier of the object carousel, the identifier of the Module in which the object is broadcast, and an unique key that identifies the object within the Module. The identifier of the object carousel is linked to a DVB-service via a descriptor in the PMT of the MPEG program. ETSI 24 ETSI TR 101 202 V1.2.1 (2003-01) The second Profile Body is called the Lite Options Profile Body and is used to refer to objects in another Service Domain (either Interactive or Broadcast). It facilitates applications to connect to another Service Domain using a globally unique NSAP address format. For Service Domains in DVB-compliant networks the NSAP address is linked to a particular DVB-service. 4.7.2.2 Supported U-U Objects The object carousel specification is designed to support a number of the interfaces defined in the Application Portability Interface (API) of DSM-CC U-U (User-to-User). This section provides guidelines regarding the objects and interfaces supported within object carousels (see for interface definitions ISO/IEC 13818-6 [4]): Table 4.2: Objects with supported READER interfaces Object Supported READER Interfaces DSM::Directory Access, Directory DSM::File Base, Access, File DSM::Stream Base, Access, Stream DSM::ServiceGateway Access, ServiceGateway BIOP::StreamEvent Base, Access, Stream, Event It should be noted that the semantics of the API for broadcast networks will differ slightly from the semantics of the API for interactive networks. The cause for this lies in the broadcast nature of the network. A typical example is with the Stream interface where a pause ("now") API call for streams delivered via the broadcast network may freeze the image on screen but not pause the delivery of the (broadcast) stream. DVB Guideline: The present document does not provide any guidelines regarding the precise operation of the DSM-CC U-U interface in Broadcast networks. The DSM-CC interface Access will return attributes (i.e. object properties like read permission and access times) which are set to default values because the broadcast of these attributes is not defined in BIOP ISO/IEC 13818-6 [4] and in ETS 300 802 [3]. DVB Guideline: The present document does not provide any guidelines regarding the broadcasting of Access attributes in object carousel. Figure 4.6 shows the relationships between the U-U Objects using OMT notation [12]. Object Stream File Directory 1+ BIOP::StreamEvent ServiceGateway Binding Tap EventList Content Name IOR refers to BiopEsTap BiopProgramTap StrNptTap StrStatusTap StrEventTap Figure 4.6: Supported Objects within object carousel ETSI 25 ETSI TR 101 202 V1.2.1 (2003-01) In an object carousel the following information is transmitted for each object: Directory object data: List of Bindings, where each Binding binds a Name to an object reference (IOR). In addition, each Binding may also contain some additional attributes of the bound object to support the fast browsing through directories. In the current object carousel specifications this is only used for the contentSize attribute for file objects. File object data: File content data and the contentSize attribute. Stream object data: A list of identifiers (called Taps) referring to one or more streams in the Broadcast network. Each Tap refers to either an Elementary Stream (BiopEsTap) or to a complete MPEG program (BiopProgramTap). Additionally other identifiers may be present that point to broadcast channels that contain control information for the stream (such as Taps that refer to StreamDescriptors for NPT, status/mode and events). The stream object data also includes the StreamInfo attribute. ServiceGateway object data: Identical to Directory object because ServiceGateway inherits from Directory. Special for the ServiceGateway object is that it contains the Root directory of the Service Domain. StreamEvent object data: Similar to the Stream object data, but extended with the EventList attribute and a list of eventIds. These attributes contain a list of DSM-CC event names and a mapping of those to eventIds. 4.7.2.3 Transmission of objects The data and attributes of one U-U Object in an object carousel are transmitted in one message. The message format is specified by the Broadcast Inter ORB Protocol (BIOP) and is referred to as the BIOP Generic Object Message format (or BIOP message for short). A BIOP Message consists of a MessageHeader, a MessageSubHeader and a messageBody. The MessageHeader provides information about the version of the BIOP protocol and the length of the BIOP message. The MessageSubHeader contains information about the conveyed Object such as objectType (File, Stream, Directory) and objectKey (the unique identifier within a Module). The messageBody depends on the objectType and contains the actual U-U Object's data. The size of a BIOP message is variable. BIOP messages are broadcast in Modules of Data Carousels (ISO/IEC 13818-6 [4]). A Module is formed by the one or more concatenated BIOP Messages (see figure 4.7) and are thus of variable length. Within the Module each Object is identified by the objectKey. An Object can easily be found by parsing subsequently the objectKey field of the BIOP message and the length of the BIOP message. According to the DSM-CC Data Carousel specification each module is fragmented into one or more Blocks which are carried in a DownloadDataBlock message. Each DownloadDataBlock message is of the same size (except for the last block of the Module which may be of a smaller size) and is transmitted in turn in an MPEG-2 private section as specified in ISO/IEC 13818-6 [4]. The encapsulation rules for DownloadDataBlock messages in MPEG-2 private sections are such that Blocks can be acquired directly from the Transport Stream using hardware filters found generally on demultiplexers. ETSI 26 ETSI TR 101 202 V1.2.1 (2003-01) Message Headers and SubHeaders Object Carousel: BIOP messages Obj-1 (Directory) Obj-2 (Stream) Obj-3 (File) Download Data Carousel : Module-1 Modules Download DataBlock Headers and Block-1 Block-2 Block-3 Block-4 Block-5 Blocks DSM-CC Section-1 Section-2 Section-3 Section-4 Section-5 Sections Section Headers Figure 4.7: Encapsulation and fragmentation of BIOP Messages in Modules, Blocks, and MPEG-2 sections The acquisition of an object from the broadcast network requires the complete acquisition of the module in which the object is contained. This requires knowledge of the delivery parameters of the Module such as module version, module size, block size, timing and broadcast channel. These delivery parameters are transmitted in a DownloadInfoIndication message which has to be acquired from the network before acquiring the module (ISO/IEC 13818-6 [4]). One DownloadInfoIndication message can describe the delivery parameters of multiple modules. The retrieval of an object from the Broadcast network is therefore a two-step process. Within BIOP the object reference of the Service Gateway of a Service Domain is transmitted in a DownloadServerInitiate message (ISO/IEC 13818-6 [4]). This message can be found using information from either the PSI or the PSI and SI. 4.7.2.4 Object References BIOP uses CORBA's Interoperable Object Reference (see also ISO/IEC 13818-6 [4] and OMG [9]). An object reference contains for each network location one Profile Body. The type of Profile Body depends on the protocols that are necessary to acquire the Object from the Server. For an IOR that refers to an Object within the same broadcast Service Domain (i.e. within the same object carousel), the BIOP Profile Body identifies the location of the BIOP message that conveys the Object data and attributes. The BIOP Profile Body consists therefore of an ObjectLocation component and a ConnBinder component (see figure 4.8). Figure 4.8 illustrates how the object reference (IOR) with BIOP Profile Body can be resolved into the Object that it refers to. The ObjectLocation identifies the object in the U-U object carousel by means of the triple carouselId, moduleId and objectKey. The ConnBinder consists of a sequence of Taps (see clause 4.7.2.5). The Taps identify via the PMT the streams on which the DownloadInfoIndication message is broadcast that contains the Module Delivery Parameters of the object. ETSI 27 ETSI TR 101 202 V1.2.1 (2003-01) IOR BIOPProfileBody ObjectLocation DownloadInfoIndication objectKey module delivery param moduleId moduleId carouselId Tap 2 ConnBinder Optional PMT More Taps PMT DownloadDataBlock Tap 1 Optional moduleId module delivery More Taps params of other blockNumber modules module data Object Object Object Object Module 1 TapUse = BIOP_DELIVERY_PARA_USE 2 TapUse = BIOP_OBJECT_USE Figure 4.8: How an IOR with BIOP profile body can be resolved into an Object The ConnBinder shall contain at least one Tap that 'points' via the PMT to the DownloadInfoIndication message. The moduleId in the IOR is used to determine the appropriate delivery parameters in the DownloadInfoIndication message. The delivery parameters shall in turn contain at least one Tap that 'points' (also via the PMT) to the DownloadDataBlock messages that convey the Module. Finally the objectKey from the IOR is used to identify the Object message in the Module. Note that both the ConnBinder and the module delivery parameters may contain more than one Tap. Additional Taps may identify alternative streams where the same Module (with possible other delivery parameters) is transmitted. For an IOR that refers to an object in another Service Domain the Lite Options Profile Body is used. The Lite Options Profile Body uses a globally unique NSAP address to identify the Service Domain which may be either Interactive or Broadcast. For Service Domains in DVB-compliant broadcast networks the NSAP address identifies a particular DVB-service as specified in EN 301 192 [1] (see figure 4.9). Figure 4.9 illustrates how the object reference (IOR) with a Lite Options Profile Body can be resolved into the Service Gateway of a broadcast Service Domain. The Profile Body contains a Service Location component that contains in turn the NSAP address. The NSAP address identifies the broadcast Service Domain using the triple transport_stream_id, service_id, and orginal_network_id of the DVB service in which the object carousel is broadcast. Using the PAT and the PMT of the service the IOR of the Service Gateway is found in a DownloadServerInitiate message. This IOR contains in turn an BIOP Profile Body that points to the Service Gateway Object of the broadcast Service Domain. The resolve operation of the BIOP Profile Body is identical as in figure 4.8. ETSI 28 ETSI TR 101 202 V1.2.1 (2003-01) IOR LiteOptions.Pr.Body DownloadServerInitiate IOR ServiceLocation NSAP BIOPProfileBody carousel_id Transport_id ObjectLocation PAT PMT objectKey org_network_id service_id moduleId See carouselId previous path_name() Figure ConnBinder Tap Optional More Taps Figure 4.9: How an IOR with Lite Options Profile Body can be resolved into a Service Gateway 4.7.2.5 Taps and associations IORs do not refer to streams directly by means of a PID, because PIDs can be changed by re-multiplexers. DSM-CC has defined therefore Taps (ISO/IEC 13818-6 [4]) which are used in a similar way as component tags in DVB SI. A Tap consists of: id this field is for private use (shall be set to zero if not used) use field indicating the usage of the Tap. association_tag (association tag) field to associate the Tap with a particular (Elementary) Stream. selector optional selector, to select the associated data from the associated (Elementary) Stream. The presence of the selector depends on the use field. The following use values are used within object carousels: 1) BIOP_DELIVERY_PARA_USE: The ConnBinder component of an BIOP Profile Body shall include such Taps to indicate the connections at which the DownloadInfoIndication() messages are broadcast that describe the module delivery parameters of the Module in which the object is conveyed (see figure 4.10). The selector field of such Taps contains a transactionId field and a timeout field. The value of the transactionId field shall be set to the transactionId of the DownloadInfoIndication() message that contains the module delivery parameters. The timeout field shall be set to the time-out period in microseconds to be used to time out the acquisition of the DownloadInfoIndication message. 2) BIOP_OBJECT_USE: Used in the DownloadInfoIndication() messages which convey the module delivery parameters of the Modules to indicate the elementary stream on which the Modules are broadcast. The selector field is empty. 3) BIOP_ES_USE, BIOP_PROGRAM_USE: The Stream object contains such Taps to indicate the stream(s) that are associated with the object. Where a BIOP_ES_USE refers to a single Elementary Stream and BIOP_PROGRAM_USE refers to a complete MPEG-2 Program (DVB Service). The selector field of both Tap types is empty. 4) STR_STATUS_AND_EVENT_USE, STR_EVENT_USE, STR_STATUS_USE, STR_NPT_USE: The Stream object and StreamEvent object may contain these Taps to indicate the various sub-streams that are associated with the object. The selector field of all such Taps is empty. ETSI 29 ETSI TR 101 202 V1.2.1 (2003-01) Tap use PMT DownloadInfoIndication st id 1 descriptor loop transactionId association_tag carousel_id_descr carouselId module delivery param selector moduleId transactionId ES loop Tap 2 time-out PID 2 nd descriptor loop Optional More Taps association_tag_descr association_tag module delivery use params of other modules selector Figure 4.10: Use of association_tag descriptor to indicate elementary streams (TapUse = BIOP_DELIVERY_PARA_USE). In the course of resolving an object, Clients have to associate the Taps to the connections of the broadcast network. Clients need, therefore, an association table that makes the association between the Taps and the connections of the broadcast network. To support the implementation of U-U object carousels in Broadcast Networks based on MPEG-2 Transport Streams, ISO/IEC 13818-6 [4] defines three descriptors that can be inserted into MPEG-2 PMTs: 1) The carousel_identifier_descriptor labels a PMT with a carousel_id, identifying that all association_tags present in the PMT belong to that U-U object carousel (providing a scope for the association tags (see figure 4.10). 2) The association_tag_descriptor labels an Elementary Stream with an association_tag, associating all Taps containing this tag with this Elementary Stream (see figure 4.10). Like a Tap, an association_tag_descriptor also contains a use field and an optional selector field. Setting this use field to 0x0000, labels the Elementary Stream that a DownloadServerInitiate message (DSI) is transmitted at this stream. This DSI contains the IOR of the ServiceGateway. 3) The deferred_association_tags_descriptor contains a list of association_tags that are associated with (Elementary Streams in) another MPEG-2 program (PMT) or that refer to another program (for use with BIOP_PROGRAM_USE Taps). Figure 4.11 illustrates the use of the deferred_association_tags_descriptor to point to another program. Tap id PMT 1st descriptor loop use carousel_id_descr PMT association_tag carouselId 1st descriptor loop deferred_assoc_tag_descr descriptors association_tag ES loop transport_stream_id PAT PID audio program_number 2nd descriptor lp. org_network_id descriptors ES loop PID video PID 2nd descriptor lp. 2nd descriptor loop descriptors descriptors Figure 4.11: Use of deferred_association_tag descriptor to indicate an MPEG-2 program (TapUse = PROGRAM_USE) ETSI 30 ETSI TR 101 202 V1.2.1 (2003-01) 4.7.3 BIOP Control Structures BIOP control and data structures are defined in ISO/IEC 13818-6 [4] using the platform-independent specification language OMG IDL (Interface Definition Language) as defined in OMG [9]. The 'bits-on-the-wire' encoding is defined by the CDR (Common Data Representation, OMG [9]) encoding rules that converts IDL grammar to bits on the wire. BIOP uses the CDR Lite encoding rules (ISO/IEC 13818-6 [4] which uses maximum length numbers in sequences and byte alignment. Consequently, CDR Lite achieve a much more compact packing of data, compared to CDR. NOTE: This also implies that all strings are terminated by a null character and that this character forms part of the string length. (For an example see in table 4.9 the fields objectKind_length and objectKind_data). In this clause the BIOP control structures are shown using an MPEG-2 syntax and guidelines are provided concerning the encoding of the fields. Fields that are affected by the guidelines are shaded. In clause 4.7.4 the BIOP messages are shown using an MPEG-2 syntax. In the case of any differences between the IDL structures defined in ISO/IEC 13818-6 [4] and the structures defined in the following clauses, the defined structures in ISO/IEC 13818-6 [4] will be correct. 4.7.3.1 Interoperable Object Reference (IOR) DSM-CC uses the Interoperable Object Reference (IOR) format defined by OMG for object references at the Client- Server Inter-operability Interface. Table 4.3 shows the syntax of the IOP::IOR (ISO/IEC 13818-6 [4]). Table 4.3: IOP::IOR syntax Syntax bits Type Value Comment IOP::IOR { type_id_length 32 uimsbf N1 for (i=0; i::". In order to reduce the size of IORs, DSM-CC defines aliases of 3 characters. The type_ids for Objects used in a DVB object carousels are shown in table 4.4. ETSI 31 ETSI TR 101 202 V1.2.1 (2003-01) Table 4.4: U-U Objects type_id Full type_id alias type_id "DSM::Directory" "dir" "DSM::File" "fil" "DSM::Stream" "str" "DSM::ServiceGateway" "srg" "BIOP::StreamEvent" "ste" DVB Guideline: Only the alias type_id fields shall be used with DVB compliant systems. This implies that no alignment stuffing bytes have to be inserted by the Server when using these aliases. An IOR that refers to an object transmitted in the same U-U object carousel contains a BIOP Profile Body in the taggedProfileList. ISO/IEC 13818-6 [4] allows an IOR to contain more than one profile body. DVB Guideline: DVB compliant receivers shall be able to process at least the first of these profile bodies, while the other profile bodies may be ignored. There shall be at least 1 taggedProfile included in an IOR. For objects carried in a broadcast object carousel, the first taggedProfile shall be either a TAG_BIOP profile or a TAG_LITE_OPTIONS. 4.7.3.2 BIOP Profile Body The BIOP Profile Body has a LiteComponentProfile structure which follows the MultipleComponentProfile structure. Table 4.5 shows the syntax of the BIOP Profile Body including the mandatory ObjectLocation component and ConnBinder Component. ETSI 32 ETSI TR 101 202 V1.2.1 (2003-01) Table 4.5: BIOP Profile Body syntax Syntax bits Type Value Comment BIOPProfileBody { profileId_tag 32 uimsbf 0x49534F06 TAG_BIOP (BIOP Profile Body) profile_data_length 32 uimsbf * profile_data_byte_order 8 uimsbf 0x00 big endian byte order liteComponents_count 8 uimsbf N1 BIOP::ObjectLocation { componentId_tag 32 uimsbf 0x49534F50 TAG_ObjectLocation component_data_length 8 uimsbf * carouselId 32 uimsbf + moduleId 16 uimsbf + version.major 8 uimsbf 0x01 BIOP protocol major version 1 version.minor 8 uimsbf 0x00 BIOP protocol minor version 0 objectKey_length 8 uimsbf N2 for (k=0; k Constant for DVB OUI dvb_service_location () { transport_stream_id 16 uimsbf + original_network_id 16 uimsbf + service_id 16 uimsbf + (= MPEG-2 program_number) reserved 32 bslbf 0xFFFFFFFF } } The semantics of the AFI, type, carouselId, specifierData, transport_stream_id, original_network_id, and service_id, and fields are as defined in EN 301 192 [1]. 4.7.4 BIOP Messages 4.7.4.1 Directory The BIOP::DirectoryMessageBody structure consists of a loop of Bindings. A binding correlates an object name (i.e. bindingName) to an IOR and provides additional information about the object. The IOR must include the BIOP Profile Body when the referenced object belongs to the Carousel. Strings shall be terminated by the character "0x0". The BIOP Directory message is an instantiation of the generic object message format. ETSI 36 ETSI TR 101 202 V1.2.1 (2003-01) Table 4.9: BIOP::DirectoryMessage syntax Syntax bits Type Value Comment BIOP::DirectoryMessage() { magic 4x8 uimsbf 0x42494F50 "BIOP" biop_version.major 8 uimsbf 0x01 BIOP major version 1 biop_version.minor 8 uimsbf 0x00 BIOP minor version 0 byte_order 8 uimsbf 0x00 big endian byte ordering message_type 8 uimsbf 0x00 message_size 32 uimsbf * objectKey_length 8 uimsbf N1 for (i=0; i and a use value of 0x0100. ETSI 48 ETSI TR 101 202 V1.2.1 (2003-01) NOTE: This matching provides the flexibility to distribute the object carousel over multiple elementary streams and still use the same component_tag value in the different PMTs to refer to this particular data broadcast service. 4.7.7.4 Deferred association tags descriptor An object carousel may use multiple PIDs, Services, and Transport Streams to broadcast the objects and associated control information. To facilitate Clients with the localization of all association_tags that are used in the different MPEG-2 Programs for the object carousel, a descriptor is defined that may be inserted in the first descriptor loop of the PMTs of the MPEG-2 Programs that implement the object carousel. The deferred_assocation_tags_descriptor contains association_tags that are used within the object carousel but that are not associated with a PID in the PMT in which the descriptor resides. The deferred_association_tags_descriptor contains therefore a forward reference to an MPEG-2 Program that does contain the PID to which the association tag is linked. Multiple deferred association tags descriptors may be inserted in a PMT if necessary. In addition a deferred_association_tag_descriptor may be used to refer to another DVB service (MPEG-2 program) as a result of a BIOP_PROGRAM_USE Tap. NOTE: Deferred_association_tags must be used whenever an object carrousel is broadcast using multiple services. For every service that carries a part of the carrousel, the list of deferred association_tags must be complete to avoid failing or false mapping of association_tags. The syntax and semantics of the deferred_association_tags_descriptor() are described in table 4.19. Table 4.19: deferred_association_tags_descriptor Syntax bits Type Value Comment deferred_association_tags_descriptor () { descriptor_tag 8 uimsbf 0x15 descriptor_length 8 uimsbf * association_tags_loop_length 8 uimsbf 2xN1 length in bytes for (n=0; n0) { dsmccAdaptationHeader() } } The protocolDiscriminator field is used to indicate that the message is a MPEG-2 DSM-CC message. The value of this field shall be 0x11. NOTE: The use of protocolDiscriminator 0x11 is dependent upon the response of ITU-T SG11 and ISO/IEC JTC1 to a liaison letter requesting that this value be assigned to DSM-CC. The dsmccType field is used to indicate the type of MPEG-2 DSM-CC message. The value of this field shall be 0x03 to indicate that the message is a U-N Download message. The messageId field indicates the type of message which is being passed. The values of the messageId are defined within the scope of the dsmccType. The transactionId field is used for session integrity and error processing and shall remain unique for a period of time such that there will be little chance that command sequences collide. The transactionId is of local significance, i.e. the value should be chosen by the broadcast server. The reserved field is ISO/IEC 13818-6 [4] reserved. This field shall be set to 0xFF. The adaptationLength field indicates the total length in bytes of the adaptation header. The messageLength field is used to indicate the total length in bytes of the message following this field. This length includes any adaptation headers indicated in the adaptationLength and the message payload indicated by the messageId field. ETSI 52 ETSI TR 101 202 V1.2.1 (2003-01) A.2 dsmccDownloadDataHeader Table A.2: DSM-CC Download Data Header Format Syntax Number of Bytes dsmccDownloadDataHeader() { ProtocolDiscriminator 1 DsmccType 1 MessageId 2 DownloadId 4 Reserved 1 AdaptationLength 1 MessageLength 2 for(adaptationLength>0) { dsmccAdaptationHeader() } } The protocolDiscriminator field is used to indicate that the message is a MPEG-2 DSM-CC message. The value of this field shall be 0x11. NOTE: The use of protocolDiscriminator 0x11 is dependent upon the response of ITU-T SG11 and ISO/IEC JTC1 to a liaison letter requesting that this value be assigned to DSM-CC. The dsmccType field is used to indicate the type of MPEG-2 DSM-CC message. The value of this field shall be 0x03 to indicate that the message is a U-N Download message. The messageId field indicates the type of message which is being passed. The values of the messageId are defined within the scope of the dsmccType. The downloadId field is used to associate the download data messages and the download control messages of a single instance of a download scenario The reserved field is ISO/IEC 13818-6 [4] reserved. This field shall be set to 0xFF. The adaptationLength indicates the total length in bytes of the adaptation header. The messageLength field is used to indicate the total length in bytes of the message following this field. This length includes any adaptation headers indicated in the adaptationLength and the message payload indicated by the messageId field. A.3 DownloadServerInitiate Table A.3: DownloadServerInitiate message Syntax Number of Bytes DownloadServerInitiate() { dsmccMessageHeader() serverId 20 compatibilityDescriptor() privateDataLength 2 for(i=0;i