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/fw-js/docs/ATSC/A-90 ATSC DATA BROADCAST STANDARD.pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- Doc. A/90 26 July 00 ATSC DATA BROADCAST STANDARD (INCLUDING AMENDMENT 1 AND CORRIGENDUM 1 AND CORRIGENDUM 2) ADVANCED TELEVISION SYSTEMS COMMITTEE Blank Page ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 ATSC DATA BROADCAST STANDARD ATSC STANDARD Table of Contents 1. SCOPE...................................................................................................................................................... 1 1.1 Purpose 1 1.2 Organization 1 1.3 Constraints 1 2. REFERENCES ........................................................................................................................................ 2 2.1 Normative References 2 2.2 Informative References 3 2.3 Reference Acquisition 3 3. DEFINITIONS AND STRUCTURES .................................................................................................... 5 3.1 Compliance Notation 5 3.2 Acronyms and Abbreviations 5 3.3 Global Terms 7 3.4 Section and Data Structure Syntax Notation 11 3.5 Special Field Meanings 11 3.6 Code Points 11 3.6.1 Table ID Values 11 3.6.2 Stream Type Values 12 3.6.3 Descriptor Tag Values 12 3.6.4 Table Types 12 4. SYSTEM ASSUMPTIONS ................................................................................................................... 13 4.1 ”Distribution, Local” Diagram Assumptions 13 4.2 Receiver Diagram Assumptions 13 5. OVERVIEW OF THE DATA BROADCASTING MECHANISMS .................................................. 14 5.1 Data Download Protocol 14 5.2 DSM-CC Addressable Sections 14 5.3 Asynchronous Data 14 5.4 Synchronous and Synchronized Streaming Data 14 5.5 Data Piping 15 5.6 Data Services 15 6. DSM-CC COMPATIBILITY DESCRIPTOR ...................................................................................... 16 6.1 Compatibility Descriptor Syntax 16 6.2 IEEE OUI Specifier 18 —i— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 7. DATA DOWNLOAD PROTOCOL ...................................................................................................... 19 7.1 Introduction 19 7.1.1 Transmission of Streaming and Non-streaming Asynchronous Data 19 7.1.2 Transmission of Non-streaming, Synchronized Data 19 7.1.3 Structure of the Non-flow Controlled and Carousel Scenarios 20 7.2 Data Download Protocol Specification 23 7.2.1 DSM-CC Section Syntax for User-to-Network Download Protocol 23 7.2.2 DSM-CC Adaptation Header Syntax 25 7.2.3 Download Control Messages 26 7.2.3.1 DSM-CC Message Header Syntax 26 7.2.3.2 Download Server Initiate Message Syntax 27 7.2.3.3 Download Info Indication Message Syntax 28 7.2.3.4 Module Description Syntax 30 7.2.3.5 Download Cancel Message Syntax 30 7.2.3.6 Descriptors for the Download Control Messages 31 7.2.3.6.1 Module Link Descriptor 31 7.2.3.6.2 CRC32 Descriptor 32 7.2.3.6.3 Group Link Descriptor 33 7.2.4 Download Data Block Message Syntax 33 7.2.4.1 Download Data Header Syntax 33 7.2.4.2 Download Data Block Message Syntax 34 8. DSM-CC ADDRESSABLE SECTION ............................................................................................... 36 8.1 Encapsulation Rules in DSM-CC Addressable Sections 38 9. SYNCHRONOUS AND SYNCHRONIZED STREAMING DATA .................................................. 39 9.1 Synchronous Data Bitstream Syntax 39 9.1.1 Synchronous Data Header 40 9.1.2 Synchronous Data Sequence Structure 41 9.2 Synchronized Data Bitstream Syntax 41 9.2.1 Synchronized Data Packet Structure 41 9.3 IP Encapsulation 43 10. DATA PIPING .............................................................................................................................. 44 11. DATA SERVICE ANNOUNCEMENT REQUIREMENTS ...................................................... 45 11.1 Introduction 45 11.2 Virtual Channels 45 11.3 Data Event Table 45 11.4 Extended Text Table 50 11.5 Data Service Descriptor 50 11.6 PID Count Descriptor 53 11.7 Announcement of Future Data Services 53 12. SERVICE DESCRIPTION FRAMEWORK............................................................................... 57 12.1 Association Tag Descriptor 57 12.2 Data Service Table 58 12.2.1 Data Service Table Bytes 59 — ii — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 12.2.2 Tap Structure 63 12.2.2.1 Definition of the Selector Structure 64 12.2.3 Download Descriptor 67 12.2.4 Multiprotocol Encapsulation Descriptor 68 12.3 Network Resources Table 69 12.3.1 Network Resources Table Bytes Structure 71 12.3.2 DSM-CC Resource Descriptor 71 12.3.2.1 Announcement of Data Streams in Other MPEG-2 Programs and Transport Streams 73 12.3.2.2 Internet Protocol Version 4 Resource Descriptor 74 12.3.2.3 Internet Protocol Version 6 Resource Descriptor 75 12.3.2.4 URL Resource Descriptor 76 13. SYSTEM TARGET DECODER MODEL .................................................................................. 77 13.1 Smoothing Buffer Descriptor 77 13.1.1 Data Service Belonging to a Virtual Channel of “service_type of 0x04” 78 13.1.2 Data Service Belonging to a Virtual Channel of “service_type of 0x02 or 0x03” 78 13.1.3 Descriptors in the ES Information Descriptor Loop 79 13.1.4 Descriptors in the Extended Program Information Descriptor Loop 79 13.1.5 Buffering 79 13.2 Buffer Model for Synchronized Data Services 80 13.2.1 General Constraints 80 13.2.2 Data Elementary Stream Buffer for Synchronized Services 81 13.2.3 Minimum Elementary Stream Buffer Size 81 13.2.4 Buffer Sizes and Data Service Levels 81 13.2.5 Buffer Arrangement 82 ANNEX A – DEPARTURES FROM THE DSM-CC STANDARD .................................................................. 83 AMENDMENT 1 ............................................................................................................................................ 89 CORRIGENDUM 1 ........................................................................................................................................ 91 CORRIGENDUM 2 ........................................................................................................................................ 93 — iii — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 1. SCOPE 1.1 Purpose This standard was prepared by the Advanced Television Systems Committee (ATSC) Technology Group on Distribution (T3). The document was approved by T3 on May 17, 2000 for submission by letter ballot to the membership of the full ATSC as an ATSC Standard. The document was approved by the members of the ATSC on July 26, 2000. This document defines a Standard for data transmission compatible with digital multiplex bit streams constructed in accordance with ISO/IEC 13818-1 (MPEG-2 Systems). It also specifies the mechanisms necessary to allow applications to be associated with data referenced by a PID. Prior to being recommended by T3, as an ATSC Standard, this document was designated Doc. T3/S13-010. Upon balloting to T3, this document was designated Doc. T3/504. 1.2 Organization The document is organized as follows: • Section 1 — Provides this general introduction. • Section 2 — Lists references and applicable documents. • Section 3 — Provides a definition of terms, acronyms, abbreviations, syntax formats and code points for this document. • Section 4 — Describes the ATSC transmission system assumptions. • Section 5 — Provides an introduction to the data carriage mechanisms. • Section 6 — Specifies the DSM-CC compatibility descriptor. • Section 7 — Specifies the transmission of data modules. • Section 8 —Specifies the transmission of asynchronous datagrams. • Section 9 — Specifies the transmission of streaming data. • Section 10 — Specifies the transmission of data via piping. • Section 11 — Specifies how this standard makes use of and supplements the A/65 ATSC Program and System Information Protocol (PSIP). • Section 12 — Specifies the application signaling framework. • Section 13 —Specifies the buffer models for data services. • Annex A — Additions to support Data Broadcasting. 1.3 Constraints 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. —1— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 2. REFERENCES 2.1 Normative References The following documents are normative for this Standard. They are listed in alphabetical order. In case of any conflicts, the ATSC standards take precedence over the other normative references: 1. ATSC Standard A/53 (1995) — ATSC Digital Television Standard. 2. ATSC Standard A/65A (2000) — Program and System Information Protocol for Terrestrial Broadcast and Cable. 3. Editorially removed; Included in Reference [2]. 4. Editorially removed; Included in Reference [2]. 5. IEEE 802-1990 — IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture. 6. IETF RFC 1112 — Host Extensions for IP Multicasting. 7. Editorially removed. 8. IETF RFC 2396 — Uniform Resource Identifiers (URI). Generic Syntax. 1998. 9. ISO/IEC/TR3 8802-1:1997 Information Technology — Telecommunications and Information Exchange between Systems -- Local and Metropolitan Area Networks — Specific Requirements — Part 1: Overview of Local Area Network Standards. 10. ISO/IEC 8802-2: 1998 Information Technology — Telecommunications and Information Exchange between Systems -- Local and Metropolitan Area Networks — Specific Requirements — Part 2: Logical Link Control. 11. ISO/IEC 13818-1 | ITU-T Rec. H.222.0:1996, Information Technology — Generic coding of moving pictures and associated audio — Part 1: Systems. 12. Technical Corrigendum 1:1999 to ISO/IEC 13818-1:1996. 13. Amendment 1:1997 to ISO/IEC 13818-1:1996 — Registration procedure for "copyright identifier". 14. Amendment 2:1997 to ISO/IEC 13818-1:1996 — Registration procedure for "format identifier". 15. ISO/IEC 13818-2 | ITU-T Rec. H262, 1995, Information Technology — Generic coding of moving pictures and associated audio — Part 2: Video. 16. ISO/IEC 13818-6, 1998 — MPEG-2 Digital Storage Media command & Control, Chapter 2, 4, 5, 6, 7, 9 and 11. 17. Amendment 2:2000 to ISO/IEC 13818-6 — Additions to support Synchronized Download Services, Opportunistic Data Services and Resource Announcement in Broadcast and Interactive Services. —2— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 18. ISO/IEC DIS 16500-7 — 1998 Information Technology -- Generic Digital Audio- Visual Systems -- Part 7: Basic Security Tools. 19. SCTE DVS 051 — Methods for Asynchronous Data Services Transport 20. SCTE DVS 132 — Standard Method for Isochronous Data Service Transport — Chapter 5. 21. SMPTE 325M — Digital Television: 1999 - Opportunistic Data Broadcast Flow Control 2.2 Informative References The following documents are informative for this Standard: 1. ETSI EN 301 192 V1.2.1 — Digital Video Broadcasting (DVB); DVB Specification for Data Broadcasting (1999-6). 2. ATSC T3-512 — ATSC Data Broadcast Standard Implementation Guidelines - draft. 2.3 Reference Acquisition • ATSC Standards: Advanced Television Systems Committee (ATSC), 1750 K Street N.W., Suite 1200 Washington, DC 20006 USA; Phone 202.828.3130; Fax 202.828.3131; Internet http://www.atsc.org/stan&rps.html • IEEE Standards: Institute of Electrical & Electronics Engineers, Inc. 445 Hoes Lane, PO Box 1331, Piscataway, NJ 08855-1331, USA; Phone 800.678.IEEE (4333); Outside USA and Canada 732.981.9667; Internet http://www.ieee.org ; Email customer-service@ieee.org • IETF Standards: Internet Engineering Task Force (IETF), c/o Corporation for National Research Initiatives, 1895 Preston White Drive, Suite 100, Reston, VA 20191-5434 USA; Phone 703.620.8990; Fax 703.758.5913; Internet: http://www.ietf.org/rfc • ISO Standards: Global Engineering Documents, World Headquarters, 15 Inverness Way East, Englewood, CO 80112-5776; Phone 800.854.7179; Fax 303.397.2750; Internet http://global.ihs.com —3— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 ISO Central Secretariat, 1, rud de Varembe, Case postale 56, CH-1211 Geneve 20, Switzerland; Phone +41 22 749 01 11; Fax + 41 22 733 34 30; Internet http://www.iso.ch ; Email central@iso.ch • SCTE Standards Society of Cable Telecommunications Engineers Inc., 140 Philips Road, Exton, PA 19341; Phone 610.363.6888; Fax 610.363.5898; Internet http://scte.org Email scte@scte.org • SMPTE Standards Society of Motion Picture and Television Engineers, 595 W. Hartsdale Avenue, White Plains, NY 10607-1824; Phone 914.761.1100; Fax: 914.761.3115; Internet http://www.smpte.org —4— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 3. DEFINITIONS AND STRUCTURES 3.1 Compliance Notation As used in this document, “shall” denotes a mandatory provision of the standard. “Should” denotes a provision that is recommended but not mandatory. “May” denotes a feature whose presence does not preclude compliance that may or may not be present at the option of the implementer. 3.2 Acronyms and Abbreviations The following acronyms and abbreviations are used within this Standard: ATSC Advanced Television Systems Committee bslbf bit serial, leftmost bit first CRC Cyclic Redundancy Check CVCT Cable Virtual Channel Table DASE DTV Applications Software Environment DAU Data Access Unit DEBn Data Elementary Stream Buffer for synchronized data elementary stream n DEBSn Data Elementary Stream Buffer Size for synchronized data elementary stream n DES Data Elementary Stream DET Data Event Table DSM-CC Digital Storage Media Command and Control DTS Decoding Time-Stamp DST Data Service Table DTV Digital Television DVB Digital Video Broadcast EIT Event Information Table ES Elementary Stream ETM Extended Text Message ETT Extended Text Table HTML Hypertext Markup Language IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization —5— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 ITU International Telecommunication Union LLC-SNAP Logical Link Control – Sub Network Access Protocol MAC Media Access Control MGT Master Guide Table MPEG Moving Picture Experts Group MTU Maximum Transmission Unit NRT Network Resources Table OUI Organization Unique Identifier PAT Program Association Table PCR Program Clock Reference PES Packetized Elementary Stream PID Packet Identifier PMT Program Map Table PSI Program Specific Information PSIP Program and System Information Protocol PTS Presentation Time Stamp PU Presentation Unit rpchof remainder polynomial coefficients, highest order first RRT Rating Region Table SDT Service Description Table SCTE Society of Cable Telecommunications Engineers SI System Information STD System Target Decoder STT System Time Table TBn Transport Buffer for data elementary stream n TBSn Transport Buffer Size for data elementary stream n TCP/IP Transmission Control Protocol/Internet Protocol TS Transport Stream TVCT Terrestrial Virtual Channel Table UTC Coordinated Universal Time1 1 Since agreement could not be achieved by the ITU on using either the English word order, CUT, or the French —6— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 uimsbf Unsigned Integer, Most Significant Bit First nbomsbf Network Byte Order (most significant byte first), Most Significant Bit First. VCT Virtual Channel Table 3.3 Global Terms The following terms are used throughout this document: application: An aggregation of related data items, including but not limited to: procedural code, declarative data and other data. asynchronous data: Stand-alone or audio/video-related data transmitted with no strong timing requirements in the sense that it is not associated with any transmitted clock references and availability of data in a data receiver is not governed by any such clock references. audio-visual event: An event (see definition below) where elementary streams are all of type video or audio. ATSC: Advanced Television Systems Committee. The committee responsible for the coordination and development of voluntary technical standards for advanced television systems. bit rate: The rate at which the bit stream is delivered from the channel to the input of a decoder. bps: Bits per second. byte-aligned: A bit in a coded bit stream is byte-aligned if its position is a multiple of 8-bits from the first bit in the stream. communication channel: A digital medium that transports a digital stream. A communication channel can be uni-directional or bi-directional. constant bit rate: Operation where the bit rate is constant from start to finish of the bit stream. CRC: The cyclic redundancy check used to verify the correctness of the data. data access unit: The portion of a synchronized or synchronous Data Elementary Stream that is associated with a particular MPEG-2 Presentation Time Stamp. data carousel: The scenario of the DSM-CC User-to-Network Download protocol that embodies the cyclic transmission of data. data elementary stream: The payloads of a series of consecutive MPEG-2 Transport Streams packets referenced by a unique PID value. data element: A self-contained subset of a data elementary stream. data module: An ordered sequence of bytes of a bounded size. data receiver: Any device capable of receiving and consuming data carried on an MPEG-2 Transport Stream. word order, TUC, the compromise was to use neither. —7— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 data service: A collection of applications and associated data elementary streams as signaled in a Data Service Table of the Service Description Framework. A data service is characterized by a profile and a level. datagram: A datagram is the fundamental protocol data unit in a packet-oriented data delivery protocol. Typically, a datagram is divided into header and data areas, where the header contains full addressing information (source and destination addresses) with each data unit. Datagrams are most often associated with connectionless network and transport layer services. data source: The provider of data that is being inserted into the MPEG-2 Transport Stream. decoded stream: The decoded reconstruction of a compressed bit stream. decoder: An embodiment of a decoding process. decoding (process): The process defined in the Digital Television Standard that reads an input coded bit stream and outputs decoded pictures, audio samples, or data objects. encoding (process): A process that reads a stream of input pictures or audio samples and produces a valid coded bit stream as defined in the Digital Television Standard. event: A collection of elementary streams with a common time base, an associated start time, and an associated end time. An event is equivalent to the common industry usage of “TV program.” forbidden: This term, when used in clauses defining the coded bit stream, indicates that the value shall never be used. This is usually to avoid emulation of start codes. Huffman coding: A type of source coding that uses codes of different lengths to represent symbols which have unequal likelihood of occurrence. instance: See table instance. Kbps: 1,000 bits per second. latency: The total time from when a data object is transmitted in a MPEG-2 transport stream until the time it is fully decoded in the data receiver. layer: One of the levels in the data hierarchy of the video and system specification. level: The abstracted dimension that is used to refer to the size of the Data Elementary Buffer in the Transport System Target Decoder governing the delivery of Data Access Units of a Data Service. This differs from the definition provided in [15]. logical channel: See virtual channel. Maximum Transmission Unit: The largest amount of data that can be transferred in a single unit across a specific physical connection. When using the Internet Protocol, this translates to the largest IP datagram size allowed. Mbps: 1,000,000 bits per second. MPEG: Refers to standards developed by the ISO/IEC JTC1/SC29 WG11, Moving Picture Experts Group. MPEG may also refer to the Group. MPEG-2: Refers to the collection of ISO/IEC standards 13818-1 through 13818-6. —8— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 multiplexer (Mux): A physical device that is capable of inserting MPEG-2 transport stream packets into and extracting MPEG-2 transport stream packets from an MPEG-2 transport stream. multiprotocol encapsulation: The encapsulation of datagrams in addressable sections. opportunistic data: Data inserted into the remaining available bandwidth in a given transport stream after all necessary bits have been allocated for video, audio and other services. packet: A packet is a set of contiguous bytes consisting of a header followed by its payload. packet identifier (PID): A unique integer value used to associate elementary streams of a program in a single or multi-program transport stream. payload: Payload refers to the bytes following the header byte in a packet. PES packet header: The leading fields in a PES packet up to but not including the PES_packet_data_byte fields where the stream is not a padding stream. In the case of a padding stream, the PES packet header is defined as the leading fields in a PES packet up to but not including the padding_byte fields. PES packet: The data structure used to carry elementary stream data. It consists of a packet header followed by PES packet payload. PES stream: A continuous sequence of PES packets of one elementary stream with one stream_id. physical channel: A generic term to refer to the each of the 6-8 MHz frequency bands where television signals are embedded for transmission. Also known as the physical transmission channel (PTC). One analog virtual channel fits in one PTC but multiple digital virtual channels typically coexist in one PTC. The calculations in this document are generally based on the ATSC 6 MHz channel capacity. physical transmission channel: See physical channel. presentation time-stamp (PTS): A field that may be present in a PES packet header that indicates the time that a presentation unit is presented in the system target decoder. presentation unit (PU): A decoded audio access unit or a decoded picture. program: A collection of program elements. Program elements may be elementary streams. Program elements need not have any defined time base; those that do have a common time base and are intended for synchronized presentation. The term program is also used in the context of a “television program” such as a scheduled daily news broadcast. In this Standard the term “event” is used for the latter to avoid ambiguity. program clock reference (PCR): A time stamp in the transport stream from which decoder timing is derived. program element: A generic term for one of the elementary streams or other data streams that may be included in a program. For example: audio, video, data, etc. program specific information (PSI): PSI consists of normative data which is necessary for the demultiplexing of transport streams and the successful regeneration of programs. —9— ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 profile: A defined subset of data delivery characteristics. This differs from the definition provided in [15]. PSIP: Program and System Information Protocol is a collection of tables describing virtual channel attributes, event features, and other information [2]. reserved: This term, when used in clauses defining the coded bit stream, indicates that the field may be used in the future for Digital Television Standard extensions. scrambling: The alteration of the characteristics of a video, audio or coded data stream in order to prevent unauthorized reception of the information in a clear form. This alteration is a specified process under the control of a conditional access system. section: A data structure comprising a portion of an ISO/IEC 13818-1 [11] or ISO/IEC 13818-6 [16]-defined table, such as the Program Association Table (PAT), Conditional Access Table (CAT), Program Map Table (PMT) or DSM-CC section. All sections begin with the table_id and end with the CRC_32 or a checksum field, and their starting points within a packet payload are indicated by the pointer_field mechanism defined in [11]. Service Description Framework: The information conveyed in the program element and providing the Data Service Table and optionally the Network Resource Table of a single data service. start codes: 32-bit codes embedded in the coded bit stream that are unique. They are used for several purposes including identifying some of the layers in the coding syntax. Start codes consist of a 24-bit prefix (0x000001) and an 8-bit stream_id. STD input buffer: A first-in, first-out buffer at the input of a system target decoder for storage of compressed data from elementary streams before decoding. stream: An ordered series of bytes. The usual context for the term stream is the series of bytes extracted from Transport Stream packet payloads that have a common unique PID value (e.g., video PES packets or Program Map Table sections). stream data: A stream is a data object which has no specific start or end. The decoding system may need only a small fraction of the total data to activate a given application. An example includes stock ticker services. synchronous data: Data that uses MPEG-2 PCRs and MPEG-2 PTSs with the objective of delivering data units with timing constraints, these data units being processed for presentation and/or display as a standalone stream. synchronized data: Data that uses MPEG-2 PCRs and MPEG-2 PTSs with the objective of matching presentation and/or display of data units with access units of other streams (typically audio and video). system target decoder (STD): A hypothetical reference model of a decoding process used to describe the semantics of the Digital Television Standard multiplexed bit stream. table: The collection of re-assembled sections bearing a common version number. table instance: Tables are identified by the table_id field. However, in cases such as the Data Event Table, several instances of a table are defined simultaneously. All instances are conveyed — 10 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 in Transport Stream packets of the same PID value and have the same table_id field value. Each instance has a different table_id_extension value. Tap: A reference to a data resource, including but not limited to: a data elementary stream, a data carousel module, or a network resource. time-stamp: A term that indicates the time of a specific action such as the arrival of a byte or the presentation of a presentation unit. transport stream: Refers to the MPEG-2 Transport Stream syntax for the packetization and multiplexing of video, audio, and data signals for digital broadcast systems [11], [12], [13], [14]. transport stream packet header: The leading fields in a Transport Stream packet up to and including the continuity_counter field. virtual channel: A virtual channel is the designation, usually a number, that is recognized by the user as the single entity that will provide access to an analog TV program or a set of one or more digital elementary streams. It is called “virtual” because its identification (name and number) may be defined independently from its physical location. 3.4 Section and Data Structure Syntax Notation Tables defined in this standard conform to the generic private section syntax defined in [11] and the DSM-CC section format defined in [16]. This document contains symbolic references to syntactic elements. The notation used is distinctive to aid the reader in recognizing elements that are the same as they are in referenced standards. These references are typographically distinguished by the use of a different font (e.g., restricted), may contain the underscore character (e.g., sequence_end_code) and may consist of character strings that are not English words (e.g., dynrng). When syntactic elements from [16] are used the form used therein is retained (e.g. thisIsString, or ThisIsString). When elements from [11] or existing ATSC Standards are used the notation form “sequence_end_code” is used. Where an element has a difference from a similar term in a reference, a variation in the form which may be a combination of the two styles is used. New elements have an entirely new name in the form “sequence_end_code”. 3.5 Special Field Meanings reserved — Fields in this Standard marked “reserved” shall not be assigned by the user, but shall be available for future use. Decoders are expected to disregard reserved fields for which no definition exists that is known to the decoder. Each bit in the fields marked “reserved” shall be set to one until such time as they are defined and supported. user_private — Indicates that the field is not defined within the scope of this Standard. zero — Indicates that the bit or bit field shall have the value zero. 3.6 Code Points 3.6.1 Table ID Values For convenience, all table_id values assigned or used by this standard are listed below: — 11 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Data Event Table 0xCE Data Service Table 0xCF Network Resources Table 0xD1 Long Term Service Table 0xD2 DSM-CC Addressable Section Table 0x3F DSM-CC Section Table 0x3B and 0x3C 3.6.2 Stream Type Values For convenience all stream_type values defined or used by this standard are listed below: PES packets containing streaming, synchronized data 0x06 DSM-CC sections containing asynchronous data 0x0B DSM-CC addressable sections 0x0D DSM-CC sections containing non-streaming, synchronized data 0x14 Sections conveying Data Service Table, Network Resources Table 0x95 PES packets containing streaming, synchronous data 0xC2 3.6.3 Descriptor Tag Values For convenience all descriptor tag values defined or used by this standard are listed below: Association Tag descriptor 0x14 Data Service descriptor 0xA4 PID Count descriptor 0xA5 Download descriptor 0xA6 Multiprotocol Encapsulation descriptor 0xA7 Module Link descriptor 0xB4 CRC32 descriptor 0xB5 Group Link descriptor 0xB8 3.6.4 Table Types For convenience, the ranges for all table_type values defined or used by this standard are listed below: Data Event Table 0x1100-0x117F Extended Text Table associated with DET 0x1200-0x127F Long Term Service Table 0x1180 — 12 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 4. SYSTEM ASSUMPTIONS This section describes system assumptions for the ATSC data broadcasting Standard. The ATSC data broadcast system diagram is shown in Figure 4.1. content origination distribution, local receiver creation ATSC ATSC present Originator Re-Mux Emission Receiver to viewer local insertion local insertion Delete from Delete from Ignore or multiplex multiplex WEB pass through to other equipment Hop Latency (Lh) Presentation Latency (Lp) System Latency (Ls) Figure 4.1 ATSC Data Broadcast System Diagram 4.1 ”Distribution, Local” Diagram Assumptions Distribution and emission entities need to (re)generate the Transport Streams. For example, a network may multiplex two shows and a stock ticker onto one Transport Stream, and the local stations may elect to replace portions of the national feed with local material. This has to be accomplished within the throughput latency and data rate limits of all components of the national broadcast passed through. This Standard covers the delivery of data from the last part of the distribution chain (emission transmitter) to a receiver. While they are significant, issues related to delivery of data from originating points to this “last transmitter” using transport mechanisms other than ATSC transmission (such as disks, tapes, various types of network connections, etc.) are not described. 4.2 Receiver Diagram Assumptions Receivers are assumed to vary greatly in the number of services they are capable of presenting and their ability to store data or process it in some meaningful way. Some may decode and present several audio/video broadcasts along with multiple data services. Others may be designed to perform a single function (such as delivering a stock ticker) as inexpensively as possible. These data broadcast buffering requirements are specified in sections 11 and 13. — 13 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 5. OVERVIEW OF THE DATA BROADCASTING MECHANISMS The following is a brief description of the data carriage mechanisms defined in the ATSC Data Broadcast Standard. 5.1 Data Download Protocol This document defines the carriage of data using the non-flow controlled scenario and the data carousel scenario of the DSM-CC User-to-Network Download protocol defined in [16]. The ATSC use of the DSM-CC Download protocol supports the transmission of the following: asynchronous data modules, asynchronous data streaming, and non-streaming synchronized data. Non-streaming synchronized data is conveyed in data modules encapsulated in DSM-CC sections including Presentation Time Stamp (PTS) values as defined in [11]. An example is sporadically transmitted application data temporally associated with a video stream. Data carried by the Download protocol may be error protected, since the DSM-CC sections used for this protocol include a CRC_32 or a checksum field. 5.2 DSM-CC Addressable Sections This document defines transmission of datagrams in the payload of MPEG-2 Transport Stream packets by encapsulating the datagrams in DSM-CC addressable sections. This mechanism shall be used for the asynchronous delivery of datagrams. 5.3 Asynchronous Data Asynchronous data has the following characteristics: • There is no MPEG-2 Systems [11] timing associated with the delivery of data • The smoothing buffer can go empty for indeterminate periods of time • The data is carried in DSM-CC sections or DSM-CC addressable sections 5.4 Synchronous and Synchronized Streaming Data This document supports synchronous and synchronized data streaming using PES. Synchronous data streaming is defined as the streaming of data with timing requirements in the sense that the data and clock can be regenerated at the receiver into a synchronous data stream. Synchronous data streams have no strong timing association with other data streams and shall be carried in PES packets. Synchronized data streaming implies a strong timing association between PES streams referenced by different PIDs. Synchronized streaming data shall be carried in PES packets. An example is application data associated with a video stream. Synchronous or synchronized multiprotocol datagrams shall be carried in PES packets. For an MPEG-2 Program including at least one synchronized or synchronous data elementary stream, a valid PCR_PID value shall be specified in the Program Map Table in which the program is listed and in particular, the PCR_PID value shall not be equal to 0x1FFF. — 14 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Furthermore, as required in section 2.7.2 of [11], the time interval between successive occurrences of the PCR base field in Transport Stream packets of the Program element referenced by the PID value PCR_PID shall be less than or equal to 100 milliseconds. The same PCR_PID value shall appear in the Service Location Descriptor (See [2]) of the virtual channel that includes the synchronized and/or synchronous data elementary stream. 5.5 Data Piping This document defines data piping as a mechanism for delivery of arbitrary user defined data inside an MPEG-2 Transport Stream. Data is inserted directly into the payload of MPEG-2 Transport Stream packets. No methods are specified in this standard for fragmentation or re- assembly of data sent in this manner. 5.6 Data Services A data service is a collection of one or more data broadcast types. For example, a data service may include streaming synchronized data and asynchronous multiprotocol encapsulated data. — 15 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 6. DSM-CC COMPATIBILITY DESCRIPTOR The DSM-CC compatibility descriptor [16] is used in both the DSM-CC User-to- Network Download protocol (see section 7) and the Service Description Framework (see section 12). The compatibility descriptor may be used to specify data receiver hardware and/or software requirements for proper acquisition and rendering of a data service. 6.1 Compatibility Descriptor Syntax The semantics of the compatibility_descriptor fields are defined in [16]. It is reproduced in Table 6.1 below for convenience. Table 6.1 DSM-CC Compatibility Descriptor Syntax No. of bits Format compatibility_descriptor() { compatibilityDescriptorLength 16 uimsbf descriptorCount 16 uimsbf for(i=0;i 0) { dsmccAdaptationHeader() } } protocolDiscriminator — This 8-bit field shall be set to 0x11 as defined in Chapter 2 of [16]. dsmccType — This 8-bit field shall be set to 0x03 as defined in Table 2.2 of Chapter 2 in [16]. messageId — This 16-bit field shall be set as defined in Table 7-4 of section 7.3 in [16]. — This 32-bit field shall be used as a versioning and identification mechanism for transaction_id the Download control messages as defined in Table 7.4 below. — 26 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Table 7.4 Semantics of the Transaction ID Field Bits Value Sub-field Description transaction_id[31..30] '10’ Control The value of this 2-bit field is defined in [16] as equal message to 0x02 when the transaction_id has been assigned by originator the network - In a broadcast scenario this is implicit. transaction_id[29..16] User- Control This 14-bit field shall be modified every time the defined message control message is updated version transaction_id[15..1] User- Control This 15-bit field shall be used to identify the control defined message message. This must and can only be all zeros for the identification top-layer control message. All non-top-level control messages must have one or more non-zero bit(s) transaction_id[0] User- Updated flag This 1-bit field must be toggled every time the control defined message is updated adaptationLength — This 8-bit field shall be set as defined in [16]. messageLength — This 16-bit field shall be set as defined in [16]. 7.2.3.2 Download Server Initiate Message Syntax The syntax and field semantics of the DownloadServerInitiate message are defined in [16]. It is reproduced in Table 7.5 below for convenience. Table 7.5 Download Server Initiate Message Syntax No. of bits Format DownloadServerInitiate() { dsmccMessageHeader() serverId 160 uimsbf compatibility_descriptor() privateDataLength 16 uimsbf for(i = 0; i< privateDataLength; i++) { privateDataByte 8 uimsbf } } serverId — This 160-bit field shall be set to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF. compatibility_descriptor() — This structure shall be as described in Chapter 6 of this standard. The value of the compatibilityDescriptorLength shall be equal to 0x0000. privateDataLength — This 16-bit field shall define the length in bytes of the following private data bytes. privateDataByte — This 8-bit field shall represent a byte of the private data field. The private data fields shall only consist of the GroupInfoIndication structure defined in Table 7.6 below. — 27 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Table 7.6 Group Information Indication Syntax No. of bits Format GroupInfoIndication() { numberOfGroups 16 uimsbf for(i=0; i 0) { dsmccAdaptationHeader() } } protocolDiscriminator — This 8-bit field value shall be set to 0x11 as specified in Chapter 2 of [16]. dsmccType — This 8-bit field value shall be set to 0x03 as specified in Table 2-2 in Chapter 2 of [16]. messageId — This 16-bit field value shall be set to 0x1003 as specified in Table 7-4 in section 7.3 of [16]. downloadId — This 32-bit field shall be set according to [16]. In the case of a carousel scenario of the Download protocol, this field shall be set to be equal to the value of carousel_id if it is specified in the download_descriptor in the associated Data Service Table. adaptationLength — This 8-bit field that shall indicate the total length in bytes of the dsmccAdaptation Header that is included in the dsmccDownloadDataHeader structure. This length shall be a multiple of four bytes. The value of adaptationLength shall be equal to 0x08 when the fields of a Synchronized Download protocol adaptation header is present. Otherwise, the value of adaptationLength shall be set to 0x00 to indicate that no adaptation field is present. messageLength — This 16-bit field shall be set as defined in chapter 7 of [16]. 7.2.4.2 Download Data Block Message Syntax The DownloadDataBlock message conveys a single block of a data module. The bit stream syntax for the DownloadDataBlock message is defined in Table 7.14 below. — 34 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Table 7.14 DSM-CC Download Data Block Message Syntax No. of bits Format downloadDataBlock() { dsmccDownloadDataHeader() moduleId 16 uimsbf moduleVersion 8 uimsbf reserved 8 '11111111' blockNumber 16 uimsbf for(i=0;i 0) { for(j = 0; j 1) { app_id_description 16 uimsbf for(i=0;i< app_id_byte_length-2;i++) { app_id_byte 8 bslbf } } tap_count 8 uimsbf for( i = 0; i < tap_count; i++) { protocol_encapsulation 8 uimsbf action_type 7 uimsbf resource_location 1 bslbf Tap() tap_info_length 16 uimsbf for( k=0; k 0 ) { selector_type 16 uimsbf for( i=2; i 0){ for(j = 0; j < resource_descriptor_count_in_section; j++) { compatibility_descriptor() dsmccResourceDescriptor() } } private_data_length 16 uimsbf for( i = 0; i < private_data_length; i++) { private_data_byte 8 bslbf } } The semantics of the fields comprising the NetworkResourcesTable() structure is defined below. resource_descriptor_count_in_section— This 8-bit field shall specify the number of resource descriptors listed in the Network Resources Table section. — This structure shall contain a DSM-CC compatibility descriptor as compatibility_descriptor() described in section 6 of this standard. Its purpose shall be to signal compatibility requirements of the data service so the receiving platform can determine its ability to use this data service. This standard does not define the content of this structure. dsmccResourceDescriptor() — This structure shall represent a DSM-CC Resource Descriptor as defined in [16]. private_data_length — This 16-bit field shall specify the length in bytes of the private field to follow. private_data_byte — This 8-bit field shall represent one byte of the private field data. 12.3.2 DSM-CC Resource Descriptor This section provides a minimum list of the dsmccResourceDescriptor used in the Network Resources Table section structure. The general format of a Resource descriptor is defined in [16]. It is reproduced in Table 12.16 below for convenience. — 71 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Table 12.16 General Format of the DSM-CC Resource Descriptor Syntax No. of Bits Format dsmccResourceDescriptor { commonDescriptorHeader() resourceDescriptorDataFields() } The commonDescriptorHeader shall be normative and shall be included with every resource descriptor definition. The format of the resourceDescriptorDataFields structure depends on the value of the resourceDescriptorType field in the commonDescriptorHeader. The resourceDescriptorDataFields structures are defined in section 12.3.3, 12.3.4, 12.3.5, 12.3.6 and 12.3.7. The commonDescriptorHeader structure is defined in Table 12.17 below. Table 12.17 DSM-CC User-to-Network Common Descriptor Header Syntax No of bits Format commonDescriptorHeader() { resourceRequestId 16 uimsbf resourceDescriptorType 16 uimsbf resourceNum 16 uimsbf associationTag 16 uimsbf resourceFlags 8 bslbf resourceStatus 8 bslbf resourceLength 16 uimsbf resourceDataFieldCount 16 uimsbf if (resourceDescriptorType == 0xffff) { typeOwnerId 24 uimsbf typeOwnerValue 24 uimsbf } } resourceRequestId — This 16-bit field shall be set as specified in [16]. At present, the only value for this field is 0xFFFF to indicate that this field is not applicable. Assignment of the other values for this field is beyond the scope of this standard. resourceDescriptorType — This 16-bit field shall specify the specific network resource. This 16- bit field shall be set as specified in [16]. The resource descriptors defined in [17] may also be used. resourceNum — This 16-bit field shall consist of two fields, a 2-bit field resourceNum[15,14] and a 14-bit field resourceNum[13…0] , respectively. The field resourceNum[15,14] represents bit number 15 and 14 of the resourceNum field. The field resourceNum[15,14] shall indicate who assigned the resource. This field shall be set to '11' to indicate that the resource number was assigned by the network. The field resourceNum[13…0] represents bit number 13 through 0 of the resourceNum field. The field resourceNum[13…0] shall identify the resource uniquely within the service. — 72 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 associationTag — This 16-bit shall identify the communication channel uniquely. The value of this field shall be set as defined in [16]. The two most significant bits of this field shall be set to ‘11’ to indicate that its value was assigned by the network. The value of the associationTag field shall be unique within the Network Resources Table. resourceFlags — This 8-bit field shall consist of three fields, a 2 bit resourceFlags[7,6] field, a 4-bit resourceFlags[5…2] field and a 2-bit resourceFlags[1,0] field. The field resourceFlags[7,6] represents bit number 7 and 6 of the resourceFlags field. The value of resourceFlags[7,6] shall identify the entity which is responsible for allocating the resource. The field resourceFlags[5…2] represents bit number 5 through 2 of the resourceFlags field. The value of resourceFlags[5…2] shall identify the negotiation type of the resource. The field resourceFlags[1,0] represents bit number 1 and 0 of the resourceFlags field. The value of resourceFlags[1,0] shall identify from which view the Resource Descriptor is being presented. The resourceFlags[7,6] field shall be set to ‘00’ by the Server to indicate that entity responsible for allocating and controlling the resource is unknown.. The resourceFlags[5…2] field shall be set to ‘0000’ to indicate that the resource is Mandatory Non- negotiable (no alternative offered in case of failure). The resourceFlags[1,0] field shall be set to ‘11’ to indicate that the resource is listed as seen by the client. resourceStatus — This 8-bit field shall define the status of the requested resource between the Server and the Network or Client. The resourceStatus field shall be set to 0x04 to indicate that the resource is assigned. resourceLength — This 16-bit field shall specify the length in bytes of the total length of the section which follows the commonDescriptorHeader. The value of the resourceLength resourceDataField field depends on the particular type of the resourceDescriptor being defined and the actual data in the resource descriptor. resourceDataFieldCount — This 16-bit field shall be set as specified in [16]. typeOwnerId — This 24-bit field shall be set as specified in [16]. typeOwnerValue — This 24-bit field shall be as specified in [16]. 12.3.2.1 Announcement of Data Streams in Other MPEG-2 Programs and Transport Streams Reference to MPEG-2 data elementary stream belonging to another MPEG-2 Program or to another MPEG-2 Transport Stream shall be made by means of the deferredMpegProgramElement Resource Descriptor. Use of the URLResourceDescriptor over the deferredMpegProgramElement shall be allowed provided that an ATSC standard exists for associating Uniform Resource Identifiers (URIs) with individual events listed in EIT-k's or DET-k's and the standard provides a mechanism for resolving the URI in a URLResourceDescriptor to a unique combination of transport_stream_id, program_number and elementary_PID values. The deferredMpegProgramElement descriptor allows data receivers to locate data elementary streams residing in a different program of either this MPEG-2 Transport Stream or a remote MPEG-2 Transport Stream. The deferredMpegProgramElement descriptor includes an associationTag field which allows identification of an elementary_PID value in a remote MPEG-2 Transport Stream. This requires that the association — 73 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 tag descriptor defined in Table 12.1 be used in the remote PMT in the same fashion as described in section 12.1. The resourceDescriptorType value associated with this resource descriptor shall be equal to 0x0014. The deferredMpegProgramElement structure is defined in Table 12.18 below. Table 12.18 Deferred MPEG Program Element Descriptor Syntax No. of bits Format deferredMpegProgramElement() { originatorId 16 uimsbf mpegTransportStreamId 16 uimsbf mpegProgramNum 16 uimsbf streamType 8 uimsbf associationTag 16 uimsbf } originatorId — This 16-bit field shall be set to 0x0000. mpegTransportStreamId — This 16-bit field shall identify the remote Transport Stream. The field shall convey a copy of its associated channel_TSID value as specified to be in the Virtual Channel Table and defined in [2]. mpegProgramNum — This 16-bit field shall specify the value of the MPEG program_number field used in the Program Association Table (PAT) and the Program Map Table (PMT) tables for this Program. streamType— This 8-bit field shall indicate the type of the data elementary stream as it appears in the Program Map Table associated with the program element. associationTag — This 16-bit field shall specify the value of the association tag associated with the remote data elementary stream. The remote PMT shall include an association_tag_descriptor() descriptor as defined in Table 12.1 above to allow identification of the elementary_PID value assigned to the remote MPEG-2 data packets. 12.3.2.2 Internet Protocol Version 4 Resource Descriptor The DSM-CC IPResourceDescriptor descriptor or the URLResourceDescriptor shall be used to signal the usage of a bi-directional communication channel supporting the Internet Protocol Version 4. The IPResourceDescriptor is defined in [17]. It is reproduced in Table 12.19 below for convenience. The resourceDescriptorType value associated with this resource descriptor is 0x0009. — 74 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 Table 12.19 Definition Of The IP Resource Descriptor Syntax No. of Bits Format IPResourceDescriptor () { sourceIpAddress 32 uimsbf sourceIpPort 16 uimsbf destinationIpAddress 32 uimsbf destinationIpPort 16 uimsbf ipProtocol 16 uimsbf } sourceIpAddress — This 32-bit field shall specify the IP version 4 source address. sourceIpPort — This 16-bit field shall specify the port which the data will be transmitted from. destinationIpAddress — This 32 bit-field shall specify the IP version 4 destination address. destinationIpPort — This 16 bit field shall specify the port which the data will be transmitted to. — This 16-bit field shall specify the protocol which is being carried over the IP stream. ipProtocol These are defined to be 0x0006 for TCP and 0x0011 for UDP. 12.3.2.3 Internet Protocol Version 6 Resource Descriptor The DSM-CC IPV6ResourceDescriptor descriptor or the URLResourceDescriptor descriptor shall be used to signal the usage of a bi-directional communication channel supporting the Internet Protocol Version 6. The IPV6ResourceDescriptor is defined in [17]. It is reproduced in Table 12.20 below for convenience. The resourceDescriptorType value associated with this resource descriptor is 0x0015. Table 12.20 Definition Of The IPV6 Resource Descriptor Syntax No. of Bits Format IPV6ResourceDescriptor () { sourceIpV6Address 128 nbomsbf sourceIpV6Port 16 nbomsbf destinationIpV6Address 128 nbomsbf destinationIpV6Port 16 nbomsbf ipV6Protocol 16 uimsbf } sourceIpV6Address — This 128-bit field shall specify the IP version 6 source address. A value equal to 0 shall indicate that this is not a valid IP address. sourceIpV6Port — This 16-bit field shall specify the port which the data will be transmitted from. destinationIpV6Address — This 128 bit-field shall specify the IP version 6 destination address. destinationIpV6Port — This 16-bit field shall specify the port which the data will be transmitted to. — 75 — ATSC ATSC Data Broadcast Standard (A/90) 26 July 00 ipV6Protocol— This 16-bit field shall specify the protocol which is being carried over the IP stream. These are defined to be 0x0006 for TCP and 0x0011 for UDP. The sourceIpV6Address, sourceIpV6Port, destinationIpV6Address and destinationIpV6Port fields shall be transmitted as uimsbf bytes and following a Network Byte Order (most significant byte transmitted first). 12.3.2.4 URL Resource Descriptor The DSM-CC URLResourceDescriptor descriptor may be used to signal the usage of a resource defined by a Uniform Resource Locator (URL) as defined in [8]. The only alternative method for signaling a communication channel supporting either Internet Protocol Version 4 or 6 shall be to use an IPResourceDescriptor or an IPV6ResourceDescriptor, respectively. Use of the URLResourceDescriptor over the deferredProgramElement shall be allowed provided the condition that an ATSC standard exists for associating Uniform Resource Identifiers (URIs) with individual events listed in EIT-k's or DET-k's and the standard provides a mechanism for resolving the URI in a URLResourceDescriptor to a unique combination of transport_stream_id, program_number and elementary_PID values. The URL resource descriptor is defined in [17]. It is reproduced in Table 12.21 for convenience. The resourceDescriptorType value associated with this resource descriptor is 0x0016. Table 12.21 URL Resource Descriptor Definition Syntax No of Bits Format URLResourceDescriptor() { URL_length 16 uimsbf for(i=0; i