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-97 Software Download Data Service.pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- Doc. A/97 16 November 2004 ATSC Standard: Software Download Data Service Advanced Television Systems Committee 1750 K Street, N.W. Suite 1200 Washington, D.C. 20006 www.atsc.org ATSC Software Download Data Service Standard 16 November 2004 The Advanced Television Systems Committee, Inc., is an international, non-profit organization developing voluntary standards for digital television. The ATSC member organizations represent the broadcast, broadcast equipment, motion picture, consumer electronics, computer, cable, satellite, and semiconductor industries. 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 140 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 Software Download Data Service Standard 16 November 2004 Table of Contents 1. SCOPE .....................................................................................................................................................5 1.1 Purpose 5 1.2 Application 5 1.3 Organization 5 2. REFERENCES .........................................................................................................................................5 2.1 Normative References 5 2.2 Informative References 6 2.3 Reference Acquisition 6 3. DEFINITIONS ...........................................................................................................................................6 3.1 Conformance Keywords 6 3.2 Acronyms and Abbreviations 7 3.3 Terms 7 3.4 Data Syntax Notation 7 4. OVERVIEW AND ARCHITECTURE.........................................................................................................7 4.1 Application Scenarios 7 4.2 Architecture 8 5. FORWARD CHANNEL TRANSPORT .....................................................................................................8 5.1 Compatibility Descriptor 9 5.2 Signaling 9 5.3 Encapsulation 9 5.3.1 DownloadInfoIndication (DII) 9 5.3.1.1 descriptorStructure 10 5.3.1.2 ModuleInfoDescriptor 10 5.3.2 DownloadDataBock (DDB) 12 5.3.3 DownloadServerInitiate (DSI) 12 5.4 Announcement 12 5.5 Buffer Model 13 3 ATSC Software Download Data Service Standard 16 November 2004 Index of Tables and Figures Table 5.1 descriptorStructure 10 Table 5.2 ModuleInfoDescriptor 11 Table 5.3 Encoding Values 11 Table 5.4 signatureType Values 11 Table 5.5 Schedule Descriptor 12 Figure 5.1 T-STD model for software download. 14 Figure 5.2 T-STD context (informative). 14 4 ATSC Software Download Data Service Standard 16 November 2004 ATSC Standard: Software Download Data Service 1. SCOPE 1.1 Purpose This document specifies a data service that may be used to download software to a terminal device using a [MPEG2] Transport Stream via an appropriate physical layer. This service may be used to effect updates or upgrades of firmware, operating system software, device driver software, native application software, middleware, and other types of software that reside in a terminal device. This document specifies standard announcement, signaling, and encapsulation for the delivery of this download data service. The content and format of the software download data is not defined by this Standard. The formats and interpretations of the software download payload are defined by each user of this Standard. 1.2 Application The behavior and facilities of this Standard are intended to apply primarily to terrestrial television broadcast systems and receivers. In addition, the same behavior and facilities may be specified and/or applied to other transport systems (such as cable or satellite). 1.3 Organization This specification is organized as follows: • Section 1 – Describes purpose, application and organization of this specification • Section 2 – Enumerates normative and informative references • Section 3 – Defines acronyms, terminology, and conventions • Section 4 – Provides an overview of the software download data service • Section 5 – Specifies forward channel transport of software download data service This Standard makes use of certain notational devices to provide valuable informative and explanatory information in the context of normative and, occasionally, informative sections. These devices take the form of paragraphs labeled as Example or Note. In each of these cases, the material is to be considered informative in nature. 2. REFERENCES This section defines the normative and informative references employed by this specification. 2.1 Normative References The following documents contain provisions which, through reference in this specification, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All referenced documents are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent edition of the referenced document. 5 ATSC Software Download Data Service Standard 16 November 2004 When a conflict exists between this specification and a referenced document, this specification takes precedence. Note: This specification uses a reference notation based on acronyms or convenient labels for identifying a reference (as opposed to using numbers). [A90] ATSC Data Broadcast Standard, Sections 6, 7 & 13, ATSC Standard A/90, 26 July 2000, ATSC. [A65] Program and System Information Protocol for Terrestrial Broadcast and Cable, Revision B, ATSC Standard A/65B, 18 March 2003, ATSC. [UTF8] Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane., ISO/IEC 10646-1:2000. [MPEG2] Information technology – Generic coding of moving pictures and associated audio information – Part 1: Systems, ISO/IEC 13818-1:2000, ISO. 2.2 Informative References [CDS] HOST-POD Interface Standard, Section 8.15, ANSI/SCTE 28, SCTE. [DVBD] Digital Video Broadcasting (DVB); Specification for System Software Update in DVB Systems, ETSI 102 006, ETSI. [OUI] IEEE OUI and Company_id Assignments, http://standards.ieee.org/regauth/oui/index.shtml. [PKCS7] PKCS #7: Cryptographic Message Syntax Standard, RSA Data Security, ftp://ftp.rsasecurity.com/pub/pkcs/ps/pkcs-7.ps. See also, IETF RFC 2315. [SCTE23] Data-Over-Cable Systems 1.1, Baseline Privacy Plus Interface Specification, SCTE 23-2 2002, SCTE. [SCTE28] HOST-POD Interface Standard, SCTE 28 2003, SCTE . 2.3 Reference Acquisition ATSC Standards – Advanced Television Systems Committee (ATSC), 1750 K Street N.W., Suite 1200, Washington, DC 20006 USA; Phone: +1 202 872-9160; Fax: +1 202 872-9161; http://www.atsc.org/. ISO Standards – International Organization for Standardization (ISO), 1, rue de Varembé, Case postale 56, CH-1211 Geneva 20, Switzerland; Phone: +41 22 749 01 11; Fax: +41 22 733 34 30; http://www.iso.ch/. SCTE Standards – Society of Cable Telecommunications Engineers, 140 Philips Road, Exton, PA 19341, USA; Phone: +1 610 363 6888; Fax: +1 610 363 5898; http://www.scte.org/. ETSI Standards and Reports – 650 Route des Lucioles, F-06921 Sophia Antipolis Cedex – France; Phone +33 4 92 94 42 00; Fax: +33 4 93 65 47 16; http://www.etsi.org. 3. DEFINITIONS This section defines conformance keywords, acronyms and abbreviations, and terms as employed by this specification. 3.1 Conformance Keywords As used in this document, the conformance keyword shall denotes a mandatory provision of the standard. The keyword should denotes a provision that is recommended but not mandatory. The 6 ATSC Software Download Data Service Standard 16 November 2004 keyword may denotes a feature whose presence does not preclude compliance, that may or may not be present at the option of the implementers. 3.2 Acronyms and Abbreviations bslbf – bit serial leftmost bit first uimsbf – unsigned integer most significant bit first OUI – Organizationally Unique Identifier POD – Point Of Deployment SDO – Standards Development Organization 3.3 Terms carousel – A download scenario where the modules are repeated. See [A90]. download scenario – The collection of DSM-CC control and data messages with the same DownloadID value. See [A90]. software download data service – A data service as defined by this specification. module – The payload data that is delivered to the receiver. See [A90]. group – A collection of messages and modules. See [A90]. 3.4 Data Syntax Notation This document contains symbolic references to syntactic elements. 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). 4. OVERVIEW AND ARCHITECTURE The entirety of this section and its subsections is informative. 4.1 Application Scenarios In order to better understand the design rationale, outlined here are several application scenarios. Scenario 1: A carousel broadcasts modules targeting a single device. • Typically used in an environment where there is no aggregator and a single manufacturer is creating a carousel to support only one hardware/software model. • The carousel targets a single hardware/software version at a time. • Additional hardware/software versions would be supported by terminating the carousel and restarting with new announcement, signaling, and data. • This is the simplest model. Scenario 2: A carousel broadcasts modules targeting multiple devices. • Typically used in an environment where there is an aggregator supporting multiple manufacturers or where a single manufacturer would like to support multiple hardware/software versions on a single carousel. • The carousel targets multiple hardware/software versions at a time. 7 ATSC Software Download Data Service Standard 16 November 2004 • Announcements are a critical part of the functionality of this scenario. Scenario 3: Multiple carousels. • Typically used in an environment where there is a combination of aggregators and/or individual manufacturers all creating carousels for a single transport. • Each virtual channel may contain carousel(s) of Scenario 1 or Scenario 2. • Multiple Virtual Channels containing carousels for software downloads may exist on a single transport. Note: Scenario 1 is a simplification of 2, and Scenario 2 is a simplification of Scenario 3. 4.2 Architecture The software download data service is based on the “2-layer carousel scenario” of [A90], including the DSI, DII and DDB messages as describe in Section 7 of [A90]. Top level signaling is accomplished via a new VCT [A65] service_type. Announcement is accomplished via schedule information added to the DSI. Thus, the DSI is used for both signaling and announcement; and the DII is used for some parts of the module signaling. For more information on this underlying design and architecture, please see [A90], Section 7, and [DVBD]. The application scenarios described above are supported by this design as follows: • Scenario 1 is a single carousel in a single Virtual Channel and contains only a single Group. Multiple downloads are managed serially through complete version changes of all DSI and DII messages. • Scenario 2 is also a single carousel in a single Virtual Channel, but it makes use of multiple Groups. Multiple downloads are managed concurrently through changes to the DSI and DII messages as needed. • Scenario 3 is a combination of scenarios 1 and/or 2 in multiple Virtual Channels. Multiple downloads are managed as in those scenarios on a per Channel basis. 5. FORWARD CHANNEL TRANSPORT This section specifies the transport of a software download data service in the forward (broadcast) channel in the terms of the following mechanisms: • Announcement • Signaling • Encapsulation Signaling is the indication of what is being carried in the transport “now”. Announcement is the signaling of future times for the download. Encapsulation is the binding of the download payload to the transport. The software download data service shall comply with the 2-layer carousel scenario as defined in [A90], Section 7, except as constrained and extended by this Standard. 8 ATSC Software Download Data Service Standard 16 November 2004 5.1 Compatibility Descriptor Both announcement and signaling of a software download data service shall use the Compatibility Descriptor as defined in [A90] Section 6, (also known as the [A90] groupCompatibility) with the following constraints applied: 1) The descriptorCount field shall be 0x0001 or greater. 2) The descriptorType field of the first descriptor shall be 0x01 (system hardware). 3) The specifierType field of the first descriptor shall be 0x01 (IEEE OUI). 4) The specifierData field of the first descriptor shall be an OUI value assigned by IEEE to the manufacturer of the terminal device(s) to which the software download is intended to be applied. See [OUI]. 5) The descriptorType field of the second descriptor, when present, shall be 0x02 (system software) and constraints (3) and (4) above shall apply. The model and version fields are required, and their meaning should be defined by the manufacturer identified by the OUI value in the specifierData field. Manufacturers may define and use the subDescriptor field per [A90]. 5.2 Signaling A software download data service shall be signaled in the ATSC Transport using a Virtual Channel with a VCT service_type of 0x05. A Virtual Channel with this service_type value shall have exactly one Program Element of stream_type 0x0B, and may have one Program Element of stream_type 0x95. The Program Element of stream_type 0x0B shall contain a “DSM-CC carousel scenario” as more fully defined here and in [A90]. The Program Element shall contain the minimum DSI, DII, and DDB messages as further defined in the encapsulation Section 5.3 below. Each DII message shall contain information for only one manufacturer. Optionally, multiple Virtual Channels of service_type 0x05 may be used in a single Transport Stream. As constrained by [A90], the downloadId field is constant on any one Program Element. 5.3 Encapsulation Each manufacturer’s data shall be encapsulated as one or more modules signaled in a unique DII message as defined by [A90] Section 7. The organization and content of the module(s) that comprise the data associated with a single manufacturer are not defined by this specification, but are expected to be defined by each implementer. 5.3.1 DownloadInfoIndication (DII) The DownloadInfoIndication (DII) messages of [A90] Section 7 are transmitted for each manufacturer, as identified by each related groupCompatibility structure in the DSI. The DII fields shall be as described in [A90]. In addition, they are constrained as follows: 1) The moduleInfoByte field shall be set to the descriptorStructure defined in Section 5.3.1.1, and may contain one or more descriptors. It may contain the moduleInfoDescriptor and scheduleDescriptor. When more than one module is being signaled, it shall contain the moduleInfoDescriptor. 9 ATSC Software Download Data Service Standard 16 November 2004 2) The privateDataByte field shall be set to the descriptorStructure defined in Section 5.3.1.1 and may contain one or more descriptors. As required by [A90], the moduleId field is unique across all DII messages within any one Program Element (and thus Virtual Channel containing this data service). 5.3.1.1 descriptorStructure The descriptorStructure is a generic descriptor loop used to contain either module or group-specific descriptors. It is defined in Table 5.1 below. Table 5.1 descriptorStructure Syntax No. of Bits Format descriptorStructure() { for ( i = 0; i < N; i++ ) { descriptor() 8 uimsbf } } descriptor – this field may contain zero or more MPEG-2 compliant descriptors as further described in this Standard. 5.3.1.2 ModuleInfoDescriptor The moduleInfoDescriptor is used to define module-specific information. The syntax of the descriptor shall be as defined in Table 5.2. 10 ATSC Software Download Data Service Standard 16 November 2004 Table 5.2 ModuleInfoDescriptor Syntax No. of Bits Format moduleInfoDescriptor() { descriptorTag 8 uimsbf descriptorLength 8 uimsbf encoding 8 uimsbf nameLength 8 uimsbf for ( i = 0; i