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/ATSC/A-91 Implementation Guidelines for the ATSC Data Broadcast Standard (Doc. A-90) (June 10, 2001).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- Doc. A/91 10 June 2001 ATSC Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard (Doc. A/90) Advanced Television Systems Committee 1750 K Street, N.W. Suite 1200 Washington, D.C. 20006 www.atsc.org ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 The Advanced Television Systems Committee (ATSC), is an international, non-profit membership organization developing voluntary standards for the entire spectrum of advanced television systems. Specifically, ATSC is working to coordinate television standards among different communications media focusing on digital television, interactive systems, and broadband multimedia communications. ATSC is also developing digital television implementation strategies and presenting educational seminars on the ATSC standards. ATSC was formed in 1982 by the member organizations of the Joint Committee on InterSociety Coordination (JCIC): the Electronic Industries Association (EIA), the Institute of Electrical and Electronic Engineers (IEEE), the National Association of Broadcasters (NAB), the National Cable Television Association (NCTA), and the Society of Motion Picture and Television Engineers (SMPTE). Currently, there are approximately 190 members representing the broadcast, broadcast equipment, motion picture, consumer electronics, computer, cable, satellite, and semiconductor industries. ATSC Digital TV Standards include digital high definition television (HDTV), standard definition television (SDTV), data broadcasting, multichannel surround-sound audio, and satellite direct-to-home broadcasting. 2 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Table of Contents 1. SCOPE ......................................................................................................................................................... 9 2. REFERENCES ............................................................................................................................................. 9 3. ACRONYMS AND DEFINITIONS.............................................................................................................. 10 3.1 Acronyms 10 3.2 Definitions 11 3.3 This Document’s Table Structure Format 11 4. INTRODUCTION TO THE IMPLEMENTATION GUIDELINES OF THE ATSC A/90 DATA BROADCAST SPECIFICATION........................................................................................................................................ 11 5. INTRODUCTION TO THE ATSC A/90 DATA BROADCAST STANDARD.............................................. 12 5.1 Data Service Definition 15 5.2 Data Encapsulations 15 5.2.1 Packetization of Data Entities 16 5.3 Encapsulation Protocol Selection Guidance 17 5.3.1 Bounded Data Blobs 18 5.3.2 Network Datagrams 18 5.3.3 Streaming Data 19 5.4 Constraints 20 5.5 Data Receiver Support 20 6. ATSC DATA BROADCAST ENCAPSULATION PROTOCOLS............................................................... 20 6.1 ATSC Data Broadcast Encapsulation Protocols 20 6.1.1 Data Download Protocol 20 6.1.1.1 Overview 20 6.1.2 Identification and Versioning 22 6.1.3 Asynchronous Data Modules in the Data Download Protocol 23 6.1.4 Asynchronous Data Streaming in the Data Download Protocol 25 6.1.5 Non-Streaming Synchronized Data Modules (Synchronized Data Download Protocol) 25 6.1.6 Data Download Protocol Hierarchy 25 6.1.7 Data Download Protocol in an MPEG-2 Transport Stream Packet 26 6.1.8 DSMCC_section 27 6.1.9 DownloadServerInitiate (DSI) 28 6.1.10 DownloadInfoIndication (DII) 30 6.1.10.1 DII and DSI Descriptors 32 6.1.10.1.1 Module Link Descriptor 33 6.1.10.1.2 CRC32 Descriptor 33 6.1.10.1.3 Group Link Descriptor 34 6.1.11 DownloadDataBlock (DDB) 34 6.1.12 DownloadCancel (DC) 37 6.1.13 PSIP Announcement of the Data Download Protocol 38 6.1.13.1 Data Service Descriptor in PSIP 39 6.1.13.2 PID Count Descriptor 39 3 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 6.1.14 Discovery of a Data Download Protocol Program Element 39 6.1.14.1 PSIP Service Location Descriptor (SLD) and the Program Map Table (PMT) 39 6.1.15 Binding of a Data Download Protocol Program Element 40 6.1.15.1 Protocol Encapsulation 40 6.1.15.2 Download Descriptor 40 6.1.16 DSMCC_section CRC32 / Checksum Calculation 41 6.1.16.1 CRC32 Calculation 41 6.1.16.2 Checksum Encoding and Decoding 41 6.2 The ATSC DSM-CC Addressable Section 42 6.2.1 Overview 42 6.2.2 LLC Encapsulation 43 6.2.3 Datagram Transport 44 6.2.4 DSM-CC Addressable Section Stream Syntax 45 6.2.5 Data Transport Specification Usage 46 6.2.6 DSM-CC Addressable Section Mapping into MPEG-2 Transport Stream Packets 48 6.2.7 PSIP Announcement of the DSM-CC Addressable Section 49 6.2.7.1 Data Service Descriptor in PSIP 49 6.2.7.2 PID Count Descriptor 49 6.2.8 Discovery of a DSM-CC Addressable Section Program Element 50 6.2.8.1 PSIP Service Location Descriptor (SLD) and the Program Map Table (PMT) 50 6.2.9 Binding of a DSM-CC Addressable Section Program Element 50 6.2.9.1 Protocol Encapsulation 50 6.2.9.2 Multiprotocol Encapsulation Descriptor 51 6.3 Synchronous and Synchronized Data Streaming 51 6.3.1 Definitions 52 6.3.2 Encapsulation of PES Packets in Transport Stream Packets 52 6.3.3 Synchronous Data Streaming 53 6.3.4 Synchronous Data Streaming of Network Datagrams 58 6.3.5 Synchronized Data Streaming 59 6.3.6 Synchronized Data Streaming of Network Datagrams 63 6.3.7 PSIP Announcement of Synchronized and Synchronous Data Streams 64 6.3.7.1 Data Service Descriptor in PSIP 65 6.3.7.2 PID Count Descriptor 65 6.3.8 Discovery of Synchronous and Synchronized Data Streaming Program Elements 65 6.3.8.1 PSIP Service Location Descriptor (SLD) and the Program Map Table (PMT) 65 6.3.9 Binding of the Synchronized and Synchronous Data Streaming Program Elements 66 6.4 Data Piping 66 6.4.1 PSIP Announcement of the Data Piping Protocol 66 6.4.1.1 Data Service Descriptor in PSIP 67 6.4.1.2 PID Count Descriptor 67 6.4.2 Discovery of a Data Piping Protocol Program Element 67 6.4.2.1 PSIP Service Location Descriptor (SLD) and Program Map Table (PMT) 67 6.4.3 Binding of a Data Piping Protocol Program Element 68 6.4.3.1 Protocol Encapsulation 68 4 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 7. PSIP DATA SERVICE EVENT ANNOUNCEMENT .................................................................................. 68 7.1 Data Service Descriptor 70 7.2 PID Count Descriptor 71 8. DATA SERVICE PROGRAM ELEMENT DISCOVERY AND BINDING ................................................... 71 8.1 Association Tag Descriptor 76 8.2 Data Service Discovery–The Basic Algorithm 76 8.2.1 PSIP Structures 76 8.2.2 MPEG-2 Structures 77 8.2.3 A/90 Service Description Framework Information 77 8.3 Data Service Table (DST) 77 8.3.1 Tap Structures 81 8.4 Network Resource Table (NRT) 83 8.5 Service Discovery and Binding—Putting It All Together 85 9. BUFFER MODEL ....................................................................................................................................... 87 9.1 Buffer Model for Asynchronous Data Elementary Streams 88 9.2 Smoothing Buffer Descriptor 89 9.3 Maximum Bitrate Descriptor 90 9.4 Buffer Model for Synchronous Data Elementary Streams 90 9.5 Buffer Model For Synchronized Data Services 91 9.5.1 T-STD for Synchronized Program Elements 91 9.5.2 Data Service Levels 94 9.5.2.1 Synchronized Stream Calculation Pseudo Code 95 Annex A: A Descriptor Location Matrix 1. SERVICE DESCRIPTION FRAMEWORK (SDF) DESCRIPTOR LOCATIONS ....................................... 96 1.1 Data Download Protocol Descriptor Location Matrix 96 Annex B: ATSC Data Broadcast Encapsulation Protocols 1. SCOPE ....................................................................................................................................................... 97 1.1 Data Download Protocol Messages 97 1.1.1 DSM-CC Section 97 1.1.1.1 DSM-CC Message Header and DSM-CC Download Data Header 98 1.1.1.2 Download Server Initiate Message 100 1.1.1.3 Download Info Indication Message 102 1.1.1.4 Download Cancel Message 103 1.1.1.5 Download Data Block Message 104 1.1.1.6 Encapsulating Download Messages into MPEG-2 Transport Stream Packets 105 Annex C: Sample Encapsulations 1. DATA DOWNLOAD PROTOCOL EXAMPLE ......................................................................................... 107 1.1 Sample Tables 107 5 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 1.1.1 Sample DSI 107 1.1.2 Sample DII for Group 1 (English) 109 1.1.3 Sample DDB (for English module) 111 1.1.4 Sample DII for Group 1 (French) 113 1.1.5 Sample DDB (for French module) 115 1.2 DSM-CC Addressable Section Example 116 1.3 Data Piping Example 118 Annex D: ATSC Data Broadcast Encapsulation Protocols 1. SCOPE ..................................................................................................................................................... 120 1.1 ATSC Table Hierarchy Discussion 121 6 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Index of Tables and Figures Table 5.1 Encapsulation Protocol Selection Matrix 17 Table 6.1 TransactionId Subfields 23 Table 6.2 MPEG-2 Transport Stream Packet Header for DSM-CC Section 27 Table 6.3 DSI Message 28 Table 6.4 DII Message 30 Table 6.5 II and DSI Descriptors 33 Table 6.6 Module Link Descriptor Syntax 33 Table 6.7 CRC32 Descriptor Syntax 34 Table 6.8 Group Link Descriptor Syntax 34 Table 6.9 DDB Message 35 Table 6.10 DC Message 37 Table 6.11 Download Descriptor Syntax 41 Table 6.12 DSMCC_addressable_section Syntax 46 Table 6.13 MPEG-2 Transport Packet Header for DSM-CC addressable section 49 Table 6.14 Multiprotocol Encapsulation Descriptor Syntax 51 Table 6.15 Synchronous Data in PES 54 Table 6.17 Synchronized Streaming Data in PES 60 Table 6.18 Synchronous and Synchronized Protocol_Encapsulation Field Values 66 Table 7.1 Data Service Descriptor Syntax 71 Table 7.2 PID Count Descriptor Syntax 71 Table 8.1 Association Tag Descriptor 76 Table 8.2 Data Services Table 78 Table 8.3 Network Resources Table 84 Table 9.1 Smoothing Buffer Descriptor Location Matrix 90 Table 9.2 Maximum Bitrate Descriptor Location Matrix 90 Table A1 SDF Descriptor Location Matrix 96 Table A2 Data Download Protocol Descriptor Location Matrix 96 Table B1 DSM-CC Section Format 98 Table B2 DSM-CC Message Header 99 Table B3 DSM-CC Download Data Header 99 Table B4 DSM-CC Adaptation Header 100 Table B5 Download Server Initiate Message 101 Table B6 Group Link Descriptor 102 Table B7 Download Info Indication Message 102 Table B8 Module Link Descriptor 103 Table B9 CRC32 Descriptor 103 Table B10 Download Cancel Message 104 Table B11 Download Data Block Message 104 Table B12 MPEG-2 Transport Stream Packet Header 105 Table C1 Sample DSI 107 Table C2 Sample DII for Group 1 (English) 110 Table C3 Sample DDB (for English module) 111 Table C4 Sample DII for Group 1 (French) 113 7 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Table C5 Sample DDB (for French module) 115 Table C6 DSM-CC Addressable Section Example 117 Table C7 Data Piping Example 119 Figure 5.1 Graphical encapsulation overview and relation to other standards. 13 Figure 5.2 Data service components. 14 Figure 5.3 ATSC Data Broadcast protocol packetization, synchronization, and protection layers. 15 Figure 6.1 Structure of the one-layer and two-layer download scenarios. 22 Figure 6.2 Cyclic transmission of information in a data carousel. 24 Figure 6.3 Data download protocol module fragmentation. 26 Figure 6.4 LLC encapsulation. 43 Figure 6.5 SNAP header. 43 Figure 6.6 LLC/SNAP encapsulation. 44 Figure 6.7 Device ID mapping. 45 Figure 6.8 DSM-CC addressable section syntax. 46 Figure 6.9 A DSMCC_addressable_section encapsulated and mapped into one or more MPEG-2 Transport Stream packets. 48 Figure 6.10 Encapsulation of synchronous PES packets in MPEG-2 Transport Stream packets. 53 Figure 6.11 Encapsulation of IP packets for synchronous data streaming using PES frames. 59 Figure 6.12 Encapsulation of IP packets for synchronized data streaming using PES frames. 64 Figure 7.1 Event Table hierarchy. 69 Figure 8.1 The Relationship of the VCT, PMT, DST, and NRT in the SDF 75 Figure 8.2 Service description block diagram.. 86 Figure 9.1 Transport system target data decoder model for asynchronous data elementary streams. 88 Figure 9.2 System target data decoder buffer model for synchronized data services. 92 Figure B1 Packing DSM-CC Sections into MPEG-2 Transport Stream Packets 106 Figure D1 Example ATSC table hierarchy. 120 Significant Contributors to this Document John R. Mick Jr., SkyStream Networks Corporation Rich Chernock, IBM Corporation Regis Crinon, Sharp Laboratories of America/Intel Corporation Edwin Heredia, Samsung Information Systems America/Microsoft Corporation Art Allison, National Association of Broadcasters Michael A. Dolan, DIRECTV 8 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard 1. SCOPE This document provides a set of guidelines for the use and implementation of the Advanced Television Systems Committee (ATSC) Data Broadcast Standard. These guidelines are intended to be recommendations for the usage of the ATSC Data Broadcast Standard as described in the ATSC Standard, A/90 (2000), “Data Broadcast Standard” [1]. As such, they facilitate the efficient and reliable implementation of data broadcast services. The information contained herein applies to data service providers as the primary entity that assembles the elements of each data channel. It also applies to broadcasters, network operators, and infrastructure 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. The document uses the terminology defined in ATSC Data Broadcast Standard [1] and should be read in conjunction with [1]. 2. REFERENCES [1] ATSC Standard A/90 (2000), “ ATSC Data Broadcast Standard” [2] ISO/IEC 13818-1: “Information technology—Generic coding of moving pictures and associated audio information, Part 1: Systems—International Standard (IS)” [3] ISO/IEC 13818-2: “Information technology—Generic coding of moving pictures and associated audio information, Part 2: Video—International Standard (IS)” [4] ISO/IEC 13818-6: “Information technology—Generic coding of moving pictures and associated audio information, Part 6: Extension for Digital Storage Media Command and Control (DSM-CC), International Standard (IS)” [5] IETF RFC 791: “Internet Protocol”, J. Postel, 01.09.1981 [6] ATSC Standard A/65A (2000), “Program and System Information Protocol (PSIP) for Terrestrial Broadcast and Cable” [7] IETF RFC 1112: “Host Extensions for IP Multicasting” [8] ISO/IEC 8802-2 (ANSI/IEEE standard 802.2), “Information technology— Telecommunications and information exchange between systems, Local and metropolitan area networks, Specific requirements, Part 2: Logical link control” [9] IETF RFC1042: “A standard for the Transmission of IP Datagrams over IEEE 802 Networks,” J. Postel and J. Reynolds, February 1988. 9 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 3. ACRONYMS AND DEFINITIONS 3.1 Acronyms The following acronyms are used within this document: ATSC Advanced Television Systems Committee ATVEF Advanced Television Enhancement Forum CRC Cyclic Redundancy Check DAU Data Access Unit DAVIC Digital Auido Visual Council DC DownloadCancel DDB DownloadDataBlock DEBn Data Elementary Stream Buffer DET Data Event Table DII DownloadInfoIndication DSI DownloadServerInitiate DST Data Service Table DSM-CC Digital Storage Media Command and Control DTV Digital Television EIT Event Information Table EPG Electronic Program Guide ES Elementary Stream ESCR Elementary Stream Clock Reference IETF Internet Engineering Task Force IP Internet Protocol ISO International Organization for Standardization IPX Internetwork Packet Exchange LLC/SNAP Logical Link Control and Subnetwork Attachment Point LSB Least Significant Byte LTST Long Term Service Table MGT Master Guide Table MPEG Moving Picture Experts Group MTU Maximum Transmission Unit 10 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 NRT Network Resources Table PAT Program Association Table PCR Program Clock Reference PES Packetized Elementary Stream PID Packet Identification PMT Program Map Table PSIP Program and System Information Protocol PTS Presentation Time Stamp RFC Request For Comment SBn Smoothing Buffer SDF Service Description Framework SLD Service Location Descriptor TBn Transport Buffer TS Transport Stream U-N User to Network VCT Virtual Channel Table 3.2 Definitions For definitions used in this document, see the ATSC Data Broadcast Standard [1]. 3.3 This Document’s Table Structure Format The syntactic tables located in this document have been constructed such that the data structure definitions are centralized within the description. Thus, a table element having sub-elements has been described sequentially within the table so that implementers can easily reference all the data elements of the data structure. The typical syntax lists the name of the “major” element and then indents for all elements and sub-elements of the data structure. Binary field values in tables are sometimes designated by single quotes, such as ‘0’ or ‘01’, and sometimes by a ‘b’ suffix, such as 0b or 01b. 4. INTRODUCTION TO THE IMPLEMENTATION GUIDELINES OF THE ATSC A/90 DATA BROADCAST SPECIFICATION This document contains recommendations on the usage of the Advanced Television Systems Committee (ATSC) Data Broadcast Standard [1]. The Implementation Guide examines in detail many of the components of the ATSC Data Broadcast Standard [1]. The Implementation Guide is organized as follows: • Section 5 provides a high-level general overview of the ATSC Data Broadcast Standard [1] including criteria for selecting the appropriate encapsulation protocol. 11 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 • Section 6 explores in detail each encapsulation protocol including the examination of each field of the encapsulation protocol. Additionally, suggestions regarding the usage of the fields are provided, along with the field ranges and other valuable information. • Section 7 focuses on the announcement of a Data Service in the ATSC environment using the Program and System Information Protocol (PSIP). • Section 8 examines the Service Description Framework (SDF) used by applications to discover their resources and to bind the resources to the applications. • Section 9 focuses on the buffer models specified by the ATSC Data Broadcast Standard [1]. Additionally, the Implementation Guideline contains four annexes. The annexes cover the following: • Annex A contains a matrix of the descriptors used by the ATSC Data Broadcast Standard [1] and the table locations in which they may be used. • Annex B describes the messages that are used for the data broadcast encapsulation protocols defined in the ATSC Data Broadcast Standard [1]. • Annex C provides examples showing the encoding of a simple two-layer asynchronous non-streaming Data Service via the non-flow controlled download scenario. • Annex D provides an example of the Service Description Framework’s (SDF) construction of a Data Service that contains the Program elements of Annex C. The SDF example illustrates the Program elements announcement using PSIP and the Program elements discovery along with the application’s binding to the Program elements. The Implementation Guide should be read in conjunction with the ATSC Data Broadcast Standard [1]. In the case of any discrepancies between the two documents then the ATSC Data Broadcast Standard [1] takes precedence. 5. INTRODUCTION TO THE ATSC A/90 DATA BROADCAST STANDARD The ATSC A/90 Data Broadcast Standard [1] describes the available encapsulation protocols used to transport data within the ATSC MPEG-2 Transport multiplex. The specification explains the Service Description Framework (SDF) used for the discovery of Program elements and the binding of applications to their Program Elements. Additionally, the specification describes the additions to the ATSC Program and System Information Protocol (PSIP) standard [6] such that a Data Service may be announced within the existing Electronic Program Guide (EPG) mechanisms. The specification also explains the use of elements in MPEG-2 PSI to aide the SDF for binding of applications to their Program Elements. It must also be noted that the ATSC Program and System Information (PSIP) standard [6] and MPEG-2 PSI (PAT and PMT) aid the SDF with the discovery of Program Elements. Figure 5.1 provides an overview of the ATSC Data Broadcast Standard as described in [1]. 12 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Applications Application level interface service service service service specific specific specific specific datagram ATSC spec. (eg IP/IPX) data download DSM-CC data download ATSC DSM-CC addressable data section encapsulation DSM-CC ATSC streaming Section data piping PES MPEG-2 Private Section MPEG-2 Transport Stream Protocol encapsulation: Data Data Addressable Section Data Piping Streaming Encapsulation Download : Service specific : ATSC defined : Other standards (IETF,ISO) : DSM-CC defined Figure 5.1 Graphical encapsulation overview and relation to other standards. The basis of the ATSC Data Broadcast Standard [1] is formed by the MPEG-2 Transport Stream (TS) as defined in ISO/IEC 13818-1 (MPEG-2 systems) [2] and amendments 1 and 2 specifying registration procedures for the copyright identifier and the format identifier, respectively. Data information can be transported within this MPEG-2 TS by means of the following encapsulation protocols: • Data Piping • Data Streaming • Addressable Sections • Data Download Figure 5.1 identifies what is standardized and 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]. The IETF has standardized the Internet Protocol (IP) in RFC 791 [5]. The ATSC has specified within the ATSC Data Broadcast Standard [1] the ATSC Data Piping protocol, the ATSC data streaming encapsulation, the ATSC DSM-CC addressable section encapsulation, and the ATSC Download protocol. Within Figure 5.1, the encapsulation of the Internet Protocol (IP) is just an example. Other network protocols can also be encapsulated. As shown in Figure 5.1, the ATSC Data Broadcast Standard [1] specifies different encapsulation protocols for different application areas. 13 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 The Data Piping specification provides minimal information on how to acquire and assemble the data bytes from the MPEG-2 TS. It only specifies how to put data into the MPEG-2 Transport Stream packets. The data streaming specification provides additional functionality, especially for timing. It is possible to achieve synchronous data broadcast or synchronized data broadcast (see Section 5.3). The data streaming specification is based on PES packets as defined in MPEG-2 ISO/IEC 13818- 1 [2]. The ATSC DSM-CC addressable section encapsulation and the ATSC Download protocol specifications are built using the DSM-CC framework of MPEG-2 ISO/IEC 13818-6 [4]. The mapping of the DSM-CC protocols onto MPEG-2 TS utilizes the MPEG-2 Private Sections as defined in MPEG-2 ISO/IEC 13818-1 [2]. The ATSC Data Broadcast Standard [1] has added specific information in order for the framework to work within the ATSC environment, especially in conjunction with the Program and System Information Protocol (PSIP) [6]. In the ATSC Data Broadcast standard, each data service may be composed of one or more applications integrated to the remaining ATSC infrastructure by means of Announcement, Discovery, and Binding functions (See Figure 5.2). Figure 5.2 Data service components. The announcement and discovery specification is part of the ATSC A/65 Program and System Information Protocol (PSIP) specification [6], along with the new elements documented in the ATSC Data Broadcast Standard [1]. Additionally, further discovery definition and application binding are part of the Service Description Framework (SDF) that is described in the ATSC Data Broadcast Standard [1]. Finally, data delivery is part of the ATSC Data Broadcast Standard [1]. Figure 5.3 illustrates the packetization, synchronization, and protection layers of the ATSC Data Broadcast protocols as per [1]. 14 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Non-flow data controlled carousel DSM-CC download LLC/ MPEG-2 LLC/ A V SNAP IP PTS IP SNAP SDF PSIP checksum checksum checksum MPEG-2 PTS CRC32 CRC32 CRC32 DSM-CC Data DSM-CC MPEG-2 PES packets addressable Piping sections sections sections MPEG-2 Transport Stream Figure 5.3 ATSC Data Broadcast protocol packetization, synchronization, and protection layers. The following paragraphs provide a set of implementation guidelines regarding how to utilize the different encapsulation protocols. 5.1 Data Service Definition A Data Service is the collection of applications and associated resources signaled in the Data Service Table (DST) of the Service Description Framework. A Data Service is required to have one program element (data elementary stream) conveying the DST and optionally the Network Resources Table (NRT). A virtual channel, as described by the PSIP Virtual Channel Table (VCT), may include a maximum of a single Data Service. The minor_channel_number of a data-only channel (service_type 0x04 in the VCT) must be in the range 100-999. A Data Service may be composed of any number of program elements and other resources, and the program elements may include any combination of the encapsulation protocols specified in the ATSC Data Broadcast Standard. The discovery of a Data Service in an ATSC Transport multiplex is independent of the announcement of a Data Service. The announcement procedure formalizes the technique used to signal the Data Service event (i.e., the start time and the duration) during which the Data Service is active. The discovery procedure formalizes the mechanism used for identifying the presence of a Data Service and for identifying the components comprising the Data Service. The binding mechanism describes a way to provide application specific parameters and resource signaling. The announcement of a Data Service is documented in Section 7 herein and Section 11 of the ATSC Data Broadcast Standard [1]. The discovery and binding of a Data Service is discussed in Section 8 of this document and Section 12 of the ATSC Data Broadcast Standard [1]. 5.2 Data Encapsulations As illustrated in Figure 5.1 and Figure 5.3, there are multiple ways to encapsulate data within the ATSC Transport multiplex. The mechanisms have different characteristics concerning timing, 15 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 filtering, overhead, size, etc. The selection of the appropriate mechanism is based on the specific requirements of the target application. The level of detail of the ATSC Data Broadcast Standard [1] varies for the different encapsulation protocols. In the case of the DSM-CC addressable section encapsulation (see Section 6.2 of this document and Section 8 of the ATSC Data Broadcast Standard [1]) and the Download protocol (see Section 6.1 of this document and Section 7 of the ATSC Data Broadcast Standard [1]), the specification is very detailed. Thus, this Implementation Guideline only requires very few application specific definitions. In the case of the other protocols, there is significant freedom for implementers to make their own decisions. 5.2.1 Packetization of Data Entities Generally, data of any protocol is transmitted in a packetized form (“data entities”). These data entities may have different lengths. If the data is not packetized or the packetization method is irrelevant or hidden to the ATSC transmission chain the most appropriate way of transmission is Data Piping (see Section 6.4 of this document and Section 10 of the ATSC Data Broadcast Standard [1]). At the MPEG-2 Transport Stream layer, data is transmitted within MPEG-2 Transport Stream packets with a fixed length of 188 bytes (184 bytes payload); therefore, data entities of higher layers must often be split at the transmission side and must be re-assembled at the reception device. For the splitting of the data entities, there are several possible packetization mechanisms: • Private mechanisms based on the Data Piping • MPEG-2 Packetized Elementary Streams (PES) • MPEG-2 Private Sections • DSM-CC Data Download Blocks MPEG-2 PES provides a mechanism to transmit data entities 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-2 for synchronization of Video and Audio). MPEG-2 PES was chosen by ATSC Data Broadcast Standard [1] for the transmission of all synchronous data streams and for synchronized data streaming (see Section 6.3 in this document and Section 9 of the ATSC Data Broadcast Standard [1]). MPEG-2 Private Sections can be used to transmit data entities of variable size with a maximum length for each data entity of just less than 4 Kbytes (encapsulation specific). The transmission is asynchronous. Data entities can be recombined to form larger data objects (for example, modules reassembled from download data blocks). MPEG-2 Private Sections are built in a way that MPEG-2 demultiplexers currently available on the market can filter out single sections in hardware, thereby reducing the required software processing power of the receiver. This concept is the main reason why the MPEG-2 Private Sections have been chosen as the mechanism for the transmission of asynchronous network protocols and data downloads (Download protocol). The Download protocol provides a means of re-assembling sections (DownloadDataBlocks) into modules, where the section data may be up to 4066 bytes in size. DSM-CC Addressable sections are used for the carriage of data entities like IP datagrams. Again, these sections are designed to engage the section filtering capability of receivers. 16 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 5.3 Encapsulation Protocol Selection Guidance The following text offers guidance for when a particular encapsulation technique might be selected. The list is not all encompassing; it is provided as a starting point for the selection of an encapsulation mechanism. Table 5.1 provides a generalized guide for determining the recommended encapsulation method. The column headings represent the data size characteristics. The row headings represent the data timing or synchronization requirements. Table 5.1 Encapsulation Protocol Selection Matrix Bounded Unbounded/Streaming Network Datagram Asynchronous Asynchronous Module Asynchronous Data Streaming DSM-CC Addressable Download Protocol Download Protocol Sections Synchronous Synchronous Data Streaming (PES) Synchronous Data Streaming (PES) Synchronized Synchronized Data Synchronized Data Streaming (PES) Synchronized Data Download Protocol Streaming (PES) The delivery of asynchronous data elementary streams is not subject to any timing constraints derived from the presence of MPEG-2 Systems timestamps in the ATSC Transport Stream. In essence, asynchronous data elementary streams are not time sensitive streams and the bytes of such streams are delivered at a fixed leak rate from a well-defined Transport System Target Decoder (T-STD) buffer model to the data receiver. Asynchronous data elementary streams have stream_type value 0x0B, 0x0D or 0x95. Synchronous data elementary streams are used for applications requiring continuous streaming of data to the receiver at a regular and piece-wise constant data rate. Synchronous data is delivered as a stream of 2-byte data access units, each data access unit being associated with a precise delivery time derived directly from the PTS field in the PES packet header and a leak rate specified either in the PES packet header or the synchronous data header structure at the beginning of the PES packet payload. The Presentation Time Stamps in the PES packets specifies the time of delivery of the first synchronous data access unit in the PES packet relative to the System Time Clock (STC) reconstructed from the PCR fields in the ATSC Transport Stream. The leak rate is then used to infer the delivery time for each of the following synchronous access units within the same PES packet. Delivery of the synchronous data access units in the next PES packet starts at the time specified by the PTS of that next PES packet. The PCR timestamps may be delivered in the Transport Packets conveying the synchronous data elementary stream. The delivery of synchronous data access units is governed by a well-defined T-STD buffer model. The difference between synchronous data and asynchronous data is the fact that synchronous data access units have been defined for the sole purpose of delivering bytes out of the T-STD buffer model according to a strict timing tied to the 27 MHz System Time Clock of the receiver. Synchronous data elementary streams have stream_type value 0xC2. Synchronized data elementary streams are used for applications requiring presentation of data at precise but not necessarily regular instants. The presentation times are typically, but not necessarily, associated with some other reference video, audio or data elementary stream. Synchronized data is delivered as a series of Data Access Units spanning one or several PES packets. The time separating two consecutive synchronized Data Access Units is arbitrary. A synchronized data elementary stream includes Presentation Time Stamps. The Program Clock Reference timestamps are typically delivered in the MPEG-2 Transport Stream packets of a 17 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 reference elementary stream, but they may be in the same elementary stream as the synchronized data. The purpose of the PTS timestamps is to specify the instant in time, relative to the STC, at which a data access unit must be rendered/displayed in the receiver. The T-STD for synchronized data elementary streams includes an additional buffer for re-assembling data bytes into synchronized Decoding Access Units. Therefore, as opposed to synchronous data access units, synchronized data access units have been defined for the purpose of presenting data at precise times. Also, as opposed to synchronous data access units, consecutive synchronized data access units may not be of the same size. Consequently, the T-STD for synchronized data elementary streams goes one step further by providing a buffer for collecting data bytes pertaining to a Data Access Unit before it is decoded and presented at a precise instant of the receiver System Time Clock. Synchronized data elementary streams have stream_type value 0x06 or 0x14. 5.3.1 Bounded Data Blobs A data blob or a data module could be a representation of a file, a group of files, a directory of files, a group of directories containing files, a module, a hierarchy of modules, an object, a group of objects, or a bounded data entity whose boundaries are known to the content author. The definition of a data module is not defined by this document or by the ATSC Data Broadcast Standard [1]. However, for the purpose of this section, a data module can generally be viewed to represent a finite sized entity that is to be delivered to a data receiver. Data modules that have no synchronization requirements associated with them should be delivered using the asynchronous module delivery method of the Download protocol. (See Section 6.1.3 of this document and Section 7 of the ATSC Data Broadcast Standard [1] for additional information.) Data modules that are to be repetitively delivered should use the data carousel option of the asynchronous Download protocol. Otherwise, the non-flow controlled scenario of the Download protocol should be used. Synchronized data modules should be delivered using the synchronized Download protocol. (See Section 6.1 of this document and Section 7 of the ATSC Data Broadcast Standard [1] for additional information.) 5.3.2 Network Datagrams Network datagrams, for example Internet Protocol (IP) datagrams or Internetwork Packet Exchange (IPX) datagrams, can be encapsulated in various manners. The different encapsulation methods are intended to meet specific needs of different applications. ATSC DSM-CC addressable sections are the method of delivery for asynchronous network datagrams. Datagrams that do not have any timing or synchronization requirements associated with them should be delivered using the DSM-CC addressable sections encapsulation. (See Section 6.2 in this document and Section 8 of the ATSC Data Broadcasting Standard [1] for additional information.) For example, this method of delivery would be useful for delivering web pages, providing turbo-internet service, or for delivering Advanced Television Enhancement Forum (ATVEF) content. Datagrams that are synchronized to a program by using a Presentation Time Stamp (PTS) are conveyed in the synchronized streaming protocol. (See Section 6.3.5 in this document and Section 9 of the ATSC Data Broadcasting Specification [1] for additional information Examples of synchronized datagrams include datagram triggers, and audio/video associated enhanced data. Synchronous datagrams are carried using the synchronous streaming protocol. 18 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 5.3.3 Streaming Data Streaming data can be synchronous, synchronized, or asynchronous. Asynchronous streaming data should be carried by the asynchronous data Download protocol. (See Section 6.1.4 in this document and Section 7 of the ATSC Data Broadcast Standard [1] for additional information.) The delivery of asynchronous data elementary streams is not subject to any timing constraints derived from the presence of MPEG-2 Systems timestamps in the ATSC Transport Stream. In essence, asynchronous data elementary streams are not time sensitive streams and the bytes of such streams are delivered at a fixed leak rate from a well-defined Transport System Target Decoder (T-STD) buffer model to the data receiver. Asynchronous data elementary streams have stream_type value 0x0B, 0x0D or 0x95. All data that is synchronous is carried using the synchronous streaming encapsulation where the data is transported in Packetized Elementary Stream (PES) packets. The synchronous data streaming protocol has been harmonized with SCTE DVS132. (See Section 6.3.3 in this document and Section 9 of the ATSC Data Broadcast Standard [1] for additional information.) Synchronous data elementary streams are used for applications requiring continuous streaming of data to the receiver at a regular and piece-wise constant data rate. Synchronous data is delivered as a stream of 2-byte synchronous_data_access_units, each synchronous_data_access_unit being associated with a precise delivery time derived directly from the PTS field in the PES packet header and a leak rate specified either in the PES packet header or the synchronous data header structure at the beginning of the PES packet payload. The Presentation Time Stamps in the PES packets specifies the time of delivery of the first synchronous_data_access_unit in the PES packet relative to the System Time Clock (STC) reconstructed from the PCR fields in the ATSC Transport Stream. The leak rate is then used to infer the delivery time for each of the following synchronous_data_access_units. The PCR timestamps may be delivered in the Transport Packets conveying the synchronous data elementary stream. The delivery of synchronous_data_access_units is governed by a well-defined T-STD buffer model. The difference between synchronous data and asynchronous data is the fact that synchronous_data_access_units have been defined for the sole purpose of delivering bytes out of the T-STD buffer model according to a strict timing tied to the 27 MHz System Time Clock of the receiver. Synchronous data elementary streams have stream_type value 0xC2. Synchronized data should be carried in the synchronized streaming protocol. The synchronized streaming protocol has been harmonized with DVB. (See Sections 6.3.5 and 6.1.5 respectively, and Sections 9 and 7 respectively of the ATSC Data Broadcast Standard [1] for additional information.) Synchronized data elementary streams are used for applications requiring presentation of data at precise but not necessarily regular instants and in connection to a reference video, an audio or another data elementary stream. Synchronized data is delivered as a series of Data Access Units spanning one or several PES packets. The time separating two consecutive synchronized Data Access Units is arbitrary. A synchronized data elementary stream includes Presentation Time Stamps. The Program Clock Reference timestamps are delivered in the MPEG-2 Transport Stream packets of the reference elementary stream. The purpose of the PTS timestamps is to specify the instant in time, relative to the STC, at which a data access unit must be rendered/displayed in the receiver. The T-STD for synchronized data elementary streams includes an additional buffer for re-assembling data bytes into synchronized Decoding Access Units. Therefore, as opposed to synchronous data access units, synchronized data access units have been defined for the purpose of presenting data concurrently with another media stream. Consequently, the T-STD for synchronized data elementary streams goes one step further by providing a buffer for collecting data bytes pertaining to a Data Access Unit before it is 19 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 decoded and presented at a precise instant of the receiver System Time Clock. Synchronized data elementary streams have stream_type value 0x06 or 0x14. 5.4 Constraints Section 1.3 of the ATSC Data Broadcast Specification A/90 [1] constrains the data broadcast standard in the following fashion: “This standard shall not be used for the carriage of the following elementary streams: • Video elementary streams with stream_type 0x02 • Audio elementary streams with stream_type 0x81 Other ATSC standards define transmission of elementary streams of these two stream types.” The purpose of these constraints is to prevent the use of A/90 to transmit program video and audio in non-ATSC authorized forms and was not intended to prevent non-programmatic video and audio from being transmitted as data. 5.5 Data Receiver Support A data receiver may support any combination of the encapsulation protocols. A data receiver that encounters an unsupported encapsulation protocol, or any other unsupported data item delivered via the Transport multiplex, should seamlessly discard the unsupported information. 6. ATSC DATA BROADCAST ENCAPSULATION PROTOCOLS The following sections describe the ATSC Data Broadcast Standard [1] encapsulation protocols described in Sections 7, 8, 9, and 10 of [1]. 6.1 ATSC Data Broadcast Encapsulation Protocols The following sections describe the ATSC Data Broadcast Standard [1] encapsulation protocols described in Sections 7, 8, 9, and 10 of [1]. 6.1.1 Data Download Protocol The data download protocol is specified in Section 7 of the ATSC Data Broadcast Standard [1]. 6.1.1.1 Overview The ATSC Data Broadcast Standard uses the DSM-CC User-To-Network Download Protocol, as defined in 13818-6 [4], to carry four different types of data: • Carousel delivery (cyclic transmission) of finite data modules to a receiver • One time, non-flow controlled delivery of finite data modules to a receiver • Non-flow controlled, asynchronous delivery of streaming data to a receiver • Non-flow controlled, synchronized delivery of non-streaming data to a receiver This section provides an introduction to the general features of the data download protocol that are common to all of these four types of data download scenario. Within the following discussion, the term module is a generic term to describe an ordered collection of bytes. It should not be interpreted to imply a file or specific object boundary. The nature of the items the term represents is outside the scope of ATSC Data Broadcast Standard [1] and of this document. 20 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 The Download Protocol is used to deliver modules. Each module is broken up into blocks for the purpose of transmission. The blocks of a module must all be of the same size, except for the last block of the module, which may be smaller. Each block may have up to 4066 bytes of data for the data carousel scenario, one-time finite module scenario, or asynchronous streaming data scenario, and up to 4058 bytes for the synchronized non-streaming data scenario. The maximum number of blocks in a module is 65,535. Therefore, a module may contain up to 266,469,376 bytes in the first three scenarios and up to 265,945,088 bytes in the synchronized non-streaming data scenario. The modules are clustered into groups, and the groups in turn may be clustered into supergroups. The supergroups are useful for two reasons: • They can be used to provide a two level hierarchical structuring of the modules. • They can be used to allow a larger number of modules in the download scenario than would be possible with the group structure alone. A group may contain up to 507 modules. A supergroup may contain up to 405 groups. Therefore, a single download scenario may contain up to 205,335 modules. There is a mechanism called the module_link_descriptor that can be used to link multiple modules from the same group into a single logical data item, so it is possible to transmit individual data items that are much larger than the maximum module size. There is also a mechanism called the group_link_descriptor that can be used to link any subset of groups within a supergroup into a single logical grouping. The Download Protocol uses several types of messages to manage the delivery of the data: • A DownloadDataBlock (DDB) message delivers an individual block of a module. It includes an identifier of the module and a 16-bit block number giving the position of the block in the module. • A DownloadInfoIndication (DII) message describes the modules in a group. It uses a moduleInfoBytes field to identify the modules in the group and give the size of the blocks used to deliver the modules, the size and version number of each module, and possibly other information about each module. • A DownloadServerInitiate (DSI) message describes the groups in a supergroup. It uses a groupInfoBytes field to identify the DII messages for the groups in the supergroup and give the size, version number, and possibly other information about each group. • A DownloadCancel (DC) message indicates the termination of a download scenario; i.e., it indicates that no more DDB, DII, or DSI messages will be forthcoming. (This allows a receiver to reclaim all resources such as buffers, etc., allocated to the download scenario.) All of the messages of a single download scenario must be in the same data elementary stream (i.e., be contained in transport packets having the same PID). The DownloadDataBlock message is usually called a download data message, while the other three types of messages are usually called download control messages. Typically the DSI and DII messages will be transmitted repeatedly, even when they have not changed, to accommodate receivers that tune to the data service in the middle of a download scenario. Thus, a receiver will often receive multiple instances of the same version of these messages. A scenario consisting of only a single group is called a one-layer download scenario. A scenario consisting of a supergroup containing multiple groups is called a two-layer download scenario. In the case of a one-layer scenario the DII message is the top-level control message. In the case of a two-layer scenario the DSI message is the top-level control message. 21 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 A Data Service provider may use a one-layer or two-layer scenario, depending on the total number of modules to be delivered and the perceived value of having a two-layer structuring for them. A data receiver should support both one-layer and two-layer download scenarios. Figure 6.1 illustrates both one-layer and two-layer download scenarios. one-layer download scenario two-layer download scenario DSI message DII message DII message DII message DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB DDB Block DDB DDB Block Module Module Group Group SuperGroup DSI: DownloadServerInitiate DII: DownloadInfoIndication DDB: DownloadDataBlock message Figure 6.1 Structure of the one-layer and two-layer download scenarios. Every module in the download scenario must be referenced by a DII message of the scenario. It is also strongly recommended that in a two-layer download scenario every group should be referenced by the DSI message of the scenario. 6.1.2 Identification and Versioning Each download scenario has associated with it a 32-bit identifier called the downloadId, which appears as a field in the DII, DC, and DDB messages of the scenario. This identifier may be chosen arbitrarily, except that it must be unique within the transport stream. Each module has associated with it a 16-bit identifier called the moduleId. This moduleId may be selected arbitrarily, except that it may not be in the range 0xFFF0 to 0xFFFF, and it must be unique within the download scenario to which the module belongs. This implies that groups can share modules, since the moduleId is not scoped by the group. The DII messages use the moduleId to reference the modules in the group. Also, each DDB message uses the moduleId to identify the module to which the block in the DDB message belongs. 22 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Each module has associated with it an 8-bit version number called the moduleVersion, which appears in the DDB messages for the blocks of the module, and in the DII messages pointing to the module. Neither the DSM-CC standard nor the ATSC Data Broadcast Standard specify how module versioning should be handled, except for an implicit assumption that the moduleVersion changes whenever the content of the module changes. The recommended practice is to increment the moduleVersion whenever the content of the module changes, with wrap-around from 255 to 0. Each download control message (DSI, DII, or DC) has associated with it a 32-bit number called the transaction_id, which includes both a unique identifier and a version number for the message. The subfields of this transaction_id are defined as shown in Table 6.1, where bit 31 is the high order bit and bit 0 is the low order bit: Table 6.1 TransactionId Subfields Subfield No. of Value Bits originator 2 ‘10’, indicating transaction_id is assigned by the server (transaction_id[31..30]) version 14 arbitrary, but must be modified whenever message is changed (transaction_id[29..16]) identification 15 0 for top-level control message (DSI message for two-layer scenario, (transaction_id[15..1]) DII message for one-layer scenario) non-zero value for other control messages (DII message for two-layer scenario, DC message in all cases), unique within the download scenario, serves as group identifier in two-layer download scenario. updated_flag 1 must be toggled every time the control message is updated (transaction_id[0]) The recommended practice is to increment the value in the version subfield whenever the message is changed, with wraparound to 0 when the top of the range is reached, and to reflect the lowest order bit of this subfield in the updated_flag subfield. Note that a receiver can always locate the top-level control message of a data download scenario by just looking for a control message with the identification subfield of the transaction_id equal to 0. The DSI messages use the transaction_id of the DII messages to reference the groups of the supergroup. It follows from this that a data receiver can detect any change to any module of a download scenario by just monitoring the transaction_id of the top-level control message of the scenario; i.e., when any module of the download scenario changes, the version subfield of the transaction_id of the top-level control message changes. It works like this: Whenever a module changes in any way, the version number of the module changes. This causes a change in the DII message referencing the module, so the version subfield of the transaction_id of that DII message changes as well. In a two-layer download scenario, this causes a change in the DSI message for the scenario, so the version subfield of its transaction_id changes. 6.1.3 Asynchronous Data Modules in the Data Download Protocol The non-flow control scenario embodies the unidirectional, one time transmission of a bounded data image to a data receiver. The data carousel cyclically repeats the contents of the carousel, one or more times. If a data 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. Because 23 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 the non-flow controlled scenario is a sub-set of the data carousel, for the remainder of this section references to the data carousel imply a reference to the non-flow controlled delivery case as well. Figure 6.2 illustrates a data carousel implementation of the Download protocol. 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 dow nload 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 DownloadInfoIndication () M8: “file3” M8_size Figure 6.2 Cyclic transmission of information in a data carousel. Within a data carousel, the data is structured into modules, depicted (for example) in Figure 6.1 as M2, M3 and M8. This abstraction could represent the contents of a number of files, say “file1”, “file2” and “file3” as in this example, or the module could be a complex data object. In both cases, the definition of module is outside the scope of ATSC Data Broadcast Standard [1] and of this document. Each module is divided to form the payload of one or more download data messages each defined using the DSM-CC DownloadDataBlock (DDB) 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 the DSM-CC DownloadInfoIndication (DII) and DownloadServerInitiate (DSI) syntax. A third control message, DownloadCancel (DC), can be used to signal the end of a download. In the above example, each download message has been inserted only once and the DownloadDataBlocks from the same module have been inserted adjacent to one another and in order. There are no restrictions on how often a particular message is inserted into a single loop of the data carousel, the order, or the relative position of messages. This freedom allows the data carousel to be created in whatever way best suits a particular use. In addition, the message frequency and the order of insertion need not be fixed and can change dynamically as required. The descriptions of the modules in the download protocol are provided by DownloadInfoIndication messages. All the modules comprising a download scenario must be announced in DownloadInfoIndication messages. An additional organizational layer is enabled through the use of DownloadServerInitiate messages that provides a grouping capability for modules. 24 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 6.1.4 Asynchronous Data Streaming in the Data Download Protocol Asynchronous data streaming services are carried via the DSM-CC Download protocol and are identified by the module size being unspecified (zero value). The moduleId, moduleSize, moduleVersion and moduleInfoLength fields associated with a data module conveying asynchronous streaming data must appear in one of the DownloadInfoIndication messages and the value of the moduleSize field must be set to 0. An example of the use of the asynchronous data streaming might be the transmission of a stock ticker service or weather information. 6.1.5 Non-Streaming Synchronized Data Modules (Synchronized Data Download Protocol) The non-flow controlled scenario of the data download protocol may also be used to convey non- streaming, synchronized data modules. This mode is supported by adding time information in the DSM-CC adaptation header in the DownloadDataBlock message as specified in [1]. The resulting protocol is called the Synchronized Download protocol. Time information in the DSM- CC adaptation header is in the form of a Presentation Time Stamp (PTS) as defined in [3]. It is recommended that the section_syntax_indicator bit be set to 0 and the checksum field be set to 0x0000 to indicate that the checksum has not been calculated. The purpose of this recommendation is to facilitate insertion of time-stamped DSM-CC sections into the ATSC multiplex (or modification of an existing time-stamp in a synchronized module) by not requiring the multiplexer to (re)calculate either a checksum or CRC32. The payload_unit_start_indicator field in any MPEG-2 Transport Stream packet conveying the beginning of a DSM-CC section containing non-streaming, synchronized data is set to 1. The value of the pointer_field must always be set to 0. This condition indicates that the DSM-CC section starts immediately after the pointer_field. The purpose of this constraint is to fix the position of the PTS in the Transport Stream packets allowing the remultiplexing equipment to modify the time stamp more easily. In addition, it is recommended that the transport packet adaptation field not be used, in order to further ensure that the position of the PTS be located at a fixed offset from the start of the packet. This recommendation results in a value for the adaptation_field_control of 0x01, signifying “No adaptation_field, payload only”. Furthermore in this case, an MPEG-2 Transport Stream packet must not include the beginning of more than one DSM-CC section. The transmission of all sections belonging to a single synchronized data module must be finished before the transmission of the next synchronized data module is allowed to start. 6.1.6 Data Download Protocol Hierarchy A download scenario will be encapsulated using the DSM-CC User-To-Network Download protocol as represented in Figure 6.3. 25 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Module Image Module Image #2 #1 DII DDB DDB DDB DII DDB DDB DDB Section Section Section Section M2T M2T M2T M2T M2T M2T M2T Figure 6.3 Data download protocol module fragmentation. The DownloadInfoIndication (DII) message(s) publishes all the modules belonging to a Group. The DII is encapsulated into one DSMCC_section and then fragmented into one or more MPEG-2 Transport Stream packets (M2T). In the case where the data module listing information is too large to fit within the payload of a single DSMCC_section, then the two-layer download scenario mechanism must be used. (A two-layer download scenario incorporates a DownloadServerInitiate (DSI) message describing a superGroup, where each of the Groups in a superGroup is described by its own DII message.) The encapsulated images are first segmented into one or more DownloadDataBlocks (DDBs). In turn, the DDBs are encapsulated into DSMCC_sections and then fragmented into one or more MPEG-2 Transport Stream packets identified by a common elementary_PID value. All data download protocol messages, DSMCC_sections, and MPEG-2 Transport Stream packets of the same download scenario will be placed in the same Transport Stream Packet Identifier (PID) except for the PSI/SDF/PSIP information as required by the ATSC Data Broadcast Standards [1] and [6]. 6.1.7 Data Download Protocol in an MPEG-2 Transport Stream Packet Each MPEG-2 Transport Stream packet will contain a portion of the data download protocol encapsulation. The MPEG-2 Transport Stream packet header for those MPEG-2 Transport Stream packets containing the start of a DSMCC_section is defined as follows: 26 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 Table 6.2 MPEG-2 Transport Stream Packet Header for DSM-CC Section Field Name No. of Field Notes Bits Value sync_byte 8 0x47 transport_error_indicator 1 Set in the transmission system to indicate an error in the current Transport Stream packet. 1 payload_unit_start_indicator 1 Set to 1b in the first MPEG-2 Transport Stream packet (PUSI) and 0b in all remaining MPEG-2 Transport Stream packets that comprise the encapsulated section. In the case of back-to-back sections, this bit will also be set when the new section starts in the MPEG-2 payload. transport_priority 1 0b PID 13 transport_scrambling_control 2 00b = Not scrambled. See MPEG-2 Systems [2] for additional choices. adaptation_field_control 2 01 = No adaptation field, payload only. See MPEG-2 Systems [2] for additional choices. continuity_counter 4 0x0 to 0xF Each successive packet on a given PID will have the continuity counter incremented over the value carried in the previous packet. pointer_field 8 0 to 182 Indicates the location of the section start in bytes following this field. This field is only included in the first MPEG-2 Transport Stream packet of the section encapsulation. This field is present when the payload_unit_start_indicator bit is set and the value is the number of bytes until the new section starts in the MPEG payload. When the packet contains the start of a synchronized DDB (Synchronized Download protocol), the pointer field must be set to zero and the payload must start immediately afterwards. payload N*8 The DSMCC_section will be contained here. The length (N) can be up to 183 bytes in a packet when the PUSI bit is set, and up to 184 bytes otherwise. If the final bytes of section are less than the length of the payload area of the MPEG-2 Transport Stream packet, then either a new section may be started assuming the correct pointer field, etc., or the TS packet may be padded out with 0xFF. The Synchronized Download protocol requires that all payloads start immediately following the pointer_field in the MPEG-2 Transport Stream packet. Thus, all payloads must be padded out for this protocol. 6.1.8 DSMCC_section Each download scenario message (either the DSI, the DII, the DC or the DDB) described below is encapsulated in a DMSCC_section. The DSMCC_section syntax is modeled after the MPEG-2 Transport Stream private_section syntax. The DSMCC_section fields that are included in each message are described below providing a linear look at the entire DSMCC_section that will be constructed. 1 Constructs of the form NMb signify bit fields. 27 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 6.1.9 DownloadServerInitiate (DSI) The DownloadServerInitiate message is used for the two-layer download scenario and it describes each of the Groups in the next layer. Table 6.3 DSI Message Field Name No of Field Notes Bits Value DSMCC_section() { table_id 8 0x3B 0x3B = DSM-CC section with DownloadServerInitiate messages. section_syntax_indicator 1 0b indicates that the checksum/CRC32 field contains a checksum. 1b indicates that the checksum/CRC32 field contains a CRC32. private_indicator 1 This field is set to the complement of the section_syntax_indicator flag. reserved 2 11b dsmcc_section_length 12 The number of bytes from table_id_extension through the last byte of the CRC32/Checksum field. The maximum value is 4093. table_id_extension 16 This field is set to the 2 least significant bytes of the transactionId in the dsmccMessageHeader. reserved 2 11b version_number 5 This field is set to 00000b. current_next_indicator 1 1b This field is set to 1b, indicating that the information in the DSI is always current. section_number 8 0x00 This field is set to 0x00. last_section_number 8 0x00 This field is set to 0x00. downloadServerInitiate() { dsmccMessageHeader() { protocolDiscriminator 8 0x11 DSMCC message. dsmccType 8 0x03 U-N Download message. messageId 16 0x1006 DownloadServerInitiate message. transactionId() { This 32-bit field is split into the sub- fields as indicated below. (See Section 6.1.2 for additional information.) originator subfield 2 10b ‘10’ indicating that the server sets this field. version subfield 14 The value in this field is incremented/changed each time any message in the download scenario is updated. identification subfield 15 0x0000 ‘000000000000000’ (all zeros). The DSI is a top-level control message. 28 ATSC Implementation Guidelines for the ATSC Data Broadcast Standard 10 June 01 updated subfield 1 This field is toggled each time the DSI message is updated. } End of sub-fields in transactionId. reserved 8 0xFF adaptationLength 8 0x00 This field is set to 0x00, indicating that no adaptation header is present. messageLength 16 The length of message following this field (from serverID field up to, but not including the checksum/CRC32 field). dsmccAdaptatinHeader() { Not used if the adaptation length field is zero. } } End dsmccMessageHeader(). serverId 20B This field is set to 20 bytes, each containing the value 0xFF compatibility_descriptor() { The compatibilityDescriptorLength field is set to 0x0000, indicating no compatibility_descriptor. compatibilityDescriptorLength 16 0x0000 Specifies the total length of the descriptors that follow, not including the compatibilityDescriptorLength itself. } privateDataLength 16 Length in bytes of the following GroupInfoIndication structure groupInfoIndication(){ numberOfGroups 16 Number of groups in the loop to follow. for (i=0; i 0) { dsmccAdaptionHeader() { adaptationType 8 0x00 or If 0x04 then a PTS is present. 0x04 if (adaptionType == 0x04) { reserved 16 ‘1…1’b '0010' 4 Same as in PES header so PTS information is byte aligned. PTS[32…30] 3 marker_bit 1 1b PTS[29…15] 15 marker_bit 1 1b PTS[14…0] 15 marker_bit 1 1b } } End dsmccAdaptionHeader(). } } End dsmccDownloadDataHeader(). moduleId 16 The moduleId field identifies to which module this block belongs. The moduleId is an identifier for the module that is described by the moduleSize, moduleVersion, and moduleInfoByte fields. The values 0xFFF0 to 0xFFFF are reserved by DAVIC. moduleVersion 8 reserved 8 0xFF blockNumber 16 Position of block with the module. The field’s numbering starts with zero, and zero corresponds to the first block. for(i=0;i