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-95 Transport Stream File System Standard.pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- Doc. A/95 25 February 2003 ATSC Standard: Transport Stream File System Standard Advanced Television Systems Committee 1750 K Street, N.W. Suite 1200 Washington, D.C. 20006 www.atsc.org ATSC Transport Stream File System Standard 25 February 2003 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 Council 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 170 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 Transport Stream File System Standard 25 February 2003 Table of Contents 1. SCOPE........................................................................................................................................................6 1.1 Organization 6 2. REFERENCES............................................................................................................................................6 2.1 Normative References 6 2.2 Informative References 7 3. DEFINITIONS AND STRUCTURES ...........................................................................................................7 3.1 Compliance Notation 7 3.2 Acronyms and Abbreviations 8 3.3 Global Terms 8 3.4 Section and Data Structure Syntax Notation 11 3.5 Elements with Undefined Semantics 12 3.6 Code Points (Informative) 12 4. INTRODUCTION (INFORMATIVE)...........................................................................................................13 5. STRUCTURES..........................................................................................................................................16 5.1 Carousel NSAP Address 16 5.2 Interoperable Object Reference (IOR) Format 17 5.3 References within the Same TSFS 18 5.4 References to Remote Objects 22 5.5 BIOP Message Formats 25 5.6 Uniform Resource Identifiers 33 6. OBJECTINFO DESCRIPTORS ................................................................................................................33 6.1 Descriptor Identification and location 34 6.2 Content Type Descriptor 34 6.3 Time Stamp Descriptor 35 7. TRANSPORT ............................................................................................................................................35 7.1 DSM-CC Message Header 36 7.2 Transport of Service Gateway IOR 37 7.3 Transport of Module Delivery Parameters 39 7.4 Semantics of TransactionId 42 7.5 Signaling of Transport Stream File Systems 43 7.6 Private Usage Collision Avoidance 45 Annex A: Carousel Design (Informative) 47 3 ATSC Transport Stream File System Standard 25 February 2003 Annex B: Object and File System Acquisition (Informative) 48 1. INTRODUCTION.......................................................................................................................................48 2. LOCAL OBJECT ACQUISITION..............................................................................................................48 3. REMOTE OBJECT RESOLUTION ...........................................................................................................51 4. TRANSPORT STREAM FILE SYSTEM ACQUISITION ...........................................................................53 5. URI RESOLUTION....................................................................................................................................54 Annex C: TSFS Objectives (Informative) 51 1. OBJECTIVES FROM RFP........................................................................................................................57 2. ACHIEVEMENT OF OBJECTIVES...........................................................................................................57 2.1 Name Spaces 57 2.2 Selective Acquisition and Browsing 58 2.3 Carriage within Virtual Channels 58 2.4 Optimization Opportunities 58 2.5 Meta-Data Extensibility 59 4 ATSC Transport Stream File System Standard 25 February 2003 Index of Tables and Figures Table 5.1 Carousel NSAP Address Syntax 16 Table 5.2 Definition of the IOR Structure 18 Table 5.3 Value of typeId_bytes 18 Table 5.4 BIOPProfileBody Structure 20 Table 5.5 MessageSelector Structure 22 Table 5.6 Definition of the LiteOptionsProfileBody Structure 23 Table 5.7 Value of kind_data Bytes 24 Table 5.8 Syntax of Directory Message Format 26 Table 5.9 Object Kind and Binding Type Codes 29 Table 5.10 Syntax of File Message Format 31 Table 6.1 objectInfo descriptors and locations 34 Table 6.2 Syntax of ContentTypeDescriptor 34 Table 6.3 Syntax of TimeStamp_descriptor 35 Table 7.1 Syntax of a DSI Message 37 Table 7.2 Syntax of BIOP: ServiceGatewayInfo 38 Table 7.3 Syntax of a DII Message 39 Table 7.4 TransactionId Sub-fields 42 Table 7.5 DST Tap Referencing a Transport Stream File System 44 Table 7.6 TSFS Selector for Tap Referencing a TSFS 45 Table C.7 TSFS Objectives 57 Figure 4.1 Graphical encapsulation overview and relation to other standards. 13 Figure 4.2 (a) Directory object (b) File object. 14 Figure 7.1 Encapsulation and fragmentation of BIOP messages. 36 Figure B1 Resolving an object from its IOR with BIOP profile body. 49 Figure B2 Use of Tap for locating a program element. 50 Figure B3 Finding service gateway from NSAP address (no remultiplexing case). 52 Figure B4 Finding service gateway from NSAP address (remultiplexed case). 53 Figure B5 How to acquire objects in a simple directory structure. 54 Figure B6 URIs derived from TSFS directory structure. 55 5 ATSC Transport Stream File System Standard 25 February 2003 Transport Stream File System Standard 1. SCOPE This standard was prepared by the Advanced Television Systems Committee (ATSC) Technology Group on Distribution (T3). The document was approved by T3 on 15 August 2002 for submission by letter ballot to the full ATSC membership. The document was approved by the members of the ATSC on 25 February 2003. This document1defines the ATSC Transport Stream File System (TSFS) standard for delivery of hierarchical name-spaces, directories and files. This standard builds on the data service delivery mechanism defined in the ATSC Data Broadcast Standard [A90]. It was designed based on responses to an RFP whose requirements are listed in Annex C. 1.1 Organization This document is organized as follows: • Section 1 — Provides this general introduction. • Section 2 — Lists references and applicable documents. • Section 3 — Provides a definition of compliance notation, acronyms, abbreviations, terms, syntax notations, and code points for this document. • Section 4 — Provides an informative description of the relationship of this standard to other standards and the overall architecture of the TSFS structures. • Section 5 — Describes the structures and object messages required by this standard. • Section 6 — Describes the usage of descriptors in the object messages defined in this standard. • Section 7 — Describes the binding of a TSFS to the ATSC transport. • Annex A — Provides an informative discussion of TSFS design. • Annex B — Provides an informative discussion of object acquisition in a TSFS. • Annex C — Provides an informative description of the driving requirements for this standard, and how this standard meets them. 2. REFERENCES 2.1 Normative References [DSMCC] ISO/IEC 13818-6:1998, “Information technology – Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC,” September 1, 1998, Sections 5.6.1, 5.6.3, 11.2.2-11.2.6, 11.3.1, 11.3.2.1-11.3.2.3, 11.3.2.5, 11.3.3. 1 NOTE: The user’s attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of this claim, or of any patent rights in connection therewith. The patent holder has, however, filed a statement of willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the publisher. 6 ATSC Transport Stream File System Standard 25 February 2003 [MPEG] ISO/IEC 13818-1:2000, “Information technology – Generic coding of moving pictures and associated audio information: Systems,” December 1, 2000. [SEC] ISO/IEC 16500-7:1999, “Information Technology – Generic digital audio-visual systems – Part 7: Basic security tools,” December 16, 1999. [A90] ATSC Document A/90, “ATSC Data Broadcast Standard,” July 26, 2000. [A65] ATSC Document A/65A, “ATSC Program and System Information Protocol for Terrestrial Broadcast and Cable”, May 31, 2000. [MIME] IETF RFC 2045, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” section 5, November 1996. [URI] IETF RFC 2396, “Uniform Resource Identifiers: Generic Syntax,” August 1998. [URI-LID] SMPTE 343M-2002, “Declarative Data Essence – Local Identifier (lid:) URI Scheme,” 2000. [IEEE802] IEEE Std 802-1990, “IEEE Standards for Local and Metropolitan Networks: Overview and Architecture,” May 31, 1990. [Trigger] ATSC Document A/93, “ATSC Synchronized/Asynchronous Trigger Standard,” February 4, 2002. 2.2 Informative References [DVB-DB] ETSI EN 301 192 v1.2.1, “Digital Video Broadcasting (DVB); specification for data broadcasting,” June 1999. [DVB-IG] ETSI TR 101 202 v1.1.1 (1999-02), “Digital Video Broadcasting (DVB); Implementation Guidelines for Data Broadcasting,” February 1999. [DVB-MHP] ETSI TS 102 812 v1.1.1 (2001-11), “Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP),” specification 1.1 (November 2001), Annex B (Normative): Object Carousel, section B.2.3.4. [SMPTE-EBU] SMPTE/EBU “Final Report of the Task Force for Harmonized Standards for the Exchange of Program Material and Bitstreams,” July 1998. [MRD] ATSC Technology Group Report T3-548, “ATSC Usage of the MPEG-2 Registration Descriptor,” October 9, 2001. [COLLISION] NTSC Technology Group Report T3-549, “Collision Avoidance for Private Fields and Ranges,” October 9, 2001. [RFP] ATSC T3/S13 Document S13-148, “Request for Proposal for Potential Revisions to ATSC Standards in the Area of Transport Stream File System Functionality,” March 28, 2001. 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. 7 ATSC Transport Stream File System Standard 25 February 2003 3.2 Acronyms and Abbreviations The following acronyms and abbreviations are used within this specification: AFI authority and format identifier BIOP broadcast inter-ORB protocol bslbf bit serial, leftmost bit first CRC cyclic redundancy check DAU data access unit DDB download data block DII download information indication DSI download server initiate DSM-CC digital storage media command and control DST data service table IOR interoperable object reference MPEG Moving Picture Experts Group NRT network resources table NSAP network service access point ORB object request broker OUI organizationally unique identifier, as defined in [IEEE802] PID packet identifier PMT program map table PSIP Program and System Information Protocol TS transport stream TSID transport stream ID TSFS transport stream file system uimsbf unsigned integer, most significant bit first URI uniform resource identifier U-U user-to-user 3.3 Global Terms The following terms are used throughout this document: ATSC Advanced Television Systems Committee. The committee responsible for the coordination and development of voluntary technical standards for advanced television systems. 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. binding A binding is a collection of bytes in a directory object that defines an association between a name and a reference (IOR) to an object. A binding may also contain descriptive information about the bound object. binding name The name that appears in a binding. 8 ATSC Transport Stream File System Standard 25 February 2003 binding structure The DirectoryMessageBody() of a directory object, consisting of a list of bindings associating object names with their locations. BIOP object An object formatted according to the generic BIOP message structure defined in [DSMCC]. carousel A carousel identifies a group of objects transmitted repeatedly from a particular service provider for a specific purpose (service). content type A content-type is the top-level media type used to declare the general type of data, as defined in [MIME]. A subtype is used to convey a specific format for that type of data. For example, a media type of “image/xyz” indicates that the data is an image, even without knowledge of the specific image format “xyz”. CRC The cyclic redundancy check used to verify the correctness of the data. data receiver Any device capable of receiving and consuming data carried in an ATSC transport stream. data service A collection of scheduled applications and associated data elementary streams as signaled in one Data Service Table. A data service is characterized by a profile and level. 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. directory link An alternative term for a binding. directory path A sequence of directory links, in which for each link in the sequence except the last one the object referenced by the link is the directory containing the next link in the sequence. elementary stream (ES) A generic term for one of the coded video, coded audio, or other coded bit streams. One elementary stream is carried in a sequence of PES packets with one and only one stream_id. 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. interoperable object reference A data structure IOP::IOR that contains the information necessary to locate an object in a network; originally developed as part of the CORBA specification, later specialized by the ISO DSM-CC Standard to the case of an MPEG-2 broadcast network. Kbps 1,000 bits per second. lid A URI scheme defined by [URI-LID]. Mbps 1,000,000 bits per second. module delivery parameters The delivery parameters of data modules are conveyed in DownloadInfoIndication messages. One DownloadInfoIndication message can convey the module delivery parameters of multiple data modules of the same U-U Object Carousel. 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. 9 ATSC Transport Stream File System Standard 25 February 2003 multiplexer (mux) A physical device that is capable of inserting MPEG-2 transport stream packets into and deleting MPEG-2 transport stream packets from an MPEG-2 transport stream. NSAP address Network Service Access Point (NSAP) consists of AFI, Type, carouselId, specifier, privateData, as specified in Figure 11-2 of [DSM-CC]. It is a globally unique identifier that is used to identify a particular service domain. object An object is an entity transmitted using the Object Carousel Protocol; it is a serialized object rather than an object definition. This could be raw data representing a file, a directory or a service gateway. object key A collection of bytes that uniquely identifies an object of a TSFS within the data carousel module that contains it. packet A packet is a set of contiguous bytes consisting of a header followed by its payload. packet identifier (PID) A 13-bit identifier appearing in the header of an MPEG-2 Transport Stream packet that is used to associate Transport Stream packets of a program element or other data stream, such as a PSI or PSIP stream. payload The bytes following the header bytes in a packet. The adaptation header of an MPEG-2 Transport Stream packet is not considered part of the payload of the packet. 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 commonly used in the context of a “television program” such as a news broadcast scheduled daily. In this specification the term “event” is used for the latter to avoid ambiguity. program element A generic term for one of the elementary streams or other data streams that may be included in an ISO/IEC 13818-1 (MPEG-2) Program. The MPEG-2 Transport Stream packets conveying a Program Element are referenced by a unique PID value in the MPEG-2 Program. program specific information (PSI) PSI consists of normative data defined in [MPEG] which is necessary for the demultiplexing of transport streams and the successful regeneration of programs. profile A defined subset of data delivery characteristics. This differs from the definition provided in ISO/IEC 13818-2. PSIP ATSC Program and System Information Protocol, which defines a collection of tables describing virtual channel attributes, event features, and other information. 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. All reserved bits are set to ‘1’. section A data structure comprising a portion of an ISO/IEC 13818-1 or ISO/IEC 13818-6- defined table, such as the Program Association Table (PAT), Conditional Access Table (CAT), Program Map Table (PMT), or DSMCC section. All sections begin with the table_id and end with a checksum or a CRC_32 field, and their starting points within a packet payload are indicated by the pointer_field mechanism defined in the ISO/IEC 13818-1 International Standard. 10 ATSC Transport Stream File System Standard 25 February 2003 service description framework The information conveyed in the program element providing the Data Service Table and optionally the Network Resource Table of a single data service. service domain A Service Domain identifies a structured group of objects. It is an abstract entity defined for the purpose of scoping. Each instance of an Object Carousel represents a Service Domain. Each Service Domain is identified by a globally unique NSAP address. Each Service Domain has a Service Gateway serving as its root directory. service gateway A Service Gateway is the one and only entry-point to the content that is broadcast by the Object Carousel. It serves as the root directory of the Object Carousel. There is a Service Gateway associated with each Service Domain. stream An ordered series of bytes. The usual context for the term stream is the series of bytes extracted from Transport Stream packet payloads which have a common unique PID value (e.g., video PES packets or Program Map Table sections). table A collection of re-assembled sections bearing a common table_id and version number. table instance A collection of re-assembled sections with a common table_id, table_id_extension, and version_number. Examples are the PSIP EITs and the Data Broadcasting DETs, where the source_id appears in the table_id_extension field to distinguish different instances of the tables. tap A data structure used to establish a link from an object reference to a lower layer communication channel. 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 [MPEG]. transport stream packet header The leading fields in an MPEG-2 Transport Stream packet up to and including the continuity_counter field. URI Uniform Resource Identifiers (URIs) provide a simple, unified and extensible mechanism for identifying a resource. The URI framework [URI] provides a way to concatenate a base- URI with a relative-URI to form an absolute URI identifying a resource. virtual channel number A virtual channel number is the designation that is recognized by the user as the single entity that will provide access to an analog TV programming 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. virtual channel A virtual channel is an analog TV broadcast or a set of one or more digital TV program elements providing a unified service and identified by a virtual channel number. 3.4 Section and Data Structure Syntax Notation Tables defined in this standard conform to the generic private section syntax defined in [MPEG] and the DSM-CC section format defined in [DSMCC]. 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). 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 11 ATSC Transport Stream File System Standard 25 February 2003 known definition exists for the decoder. Each bit in the fields marked “reserved” shall be set to ‘1’ until such time as they are defined and supported. user_private — A value or range of values of a code point that may be privately defined by users of a particular standard. It must be possible to determine the identity of the standards body or private party specifying a user private value. In instances where the ownership of the definition of the bytes is not otherwise explicit, the MPEG-2 Registration Descriptor shall be used for this purpose. zero — Indicates that the bit or bit field shall have the value zero. 3.5 Elements with Undefined Semantics In a number of places in this standard there appear statements that certain elements (which have been included for compatibility with [DSMCC] and [DVB-MHP]) “have no meaning in this standard.” This means that such elements will normally not be present in Transport Stream File Systems implementing this standard, but implementers should not assume that such elements will never be present. It is possible that there may be a future version of this standard in which some of these elements are used in order to support some kind of extended functionality. 3.6 Code Points (Informative) For convenience, this section lists all values of table_id, stream_type, descriptor_tag, encapsulation_protocol, and selector_type that are used in this standard. 3.6.1 Table ID Values The table_id values defined or used in this standard are: 0x3B DSM-CC section containing DSI or DII message (defined in [DSMCC]). 0x3C DSM-CC section containing DDB message (defined in [DSMCC]). 3.6.2 Stream Type Values The stream_type value used in this standard is: 0x0B DSM-CC sections containing data carousel messages (defined in [DSMCC]). 3.6.3 Descriptor Tag Values The descriptor_tag values used in this standard are: 0x72 Content Type descriptor (defined in [Trigger]). 0xB9 Time Stamp descriptor (defined in this standard). 3.6.4 Encapsulation Protocol Values The encapsulation_protocol value defined in this standard is: 0x0F Transport Stream File System. 3.6.5 Selector Type Values The selector_type values defined or used in this standard are: 0x0001 Message selector (defined in [DSM-CC]). 0x109 TSFS selector (defined in this standard). 12 ATSC Transport Stream File System Standard 25 February 2003 4. INTRODUCTION (INFORMATIVE) This section describes the overall architecture of the ATSC Transport Stream File System. The ATSC Transport Stream File System is based on the Object Carousel design specified in [DSMCC], section 11. Figure 4 shows how this standard fits in with other standards. Applications This Standard service service service service service specific Application specific specific specific specific level interface ATSC TSFS datagram ATSC DSM-CC spec. (eg IP/IPX) data download Object Carousel 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 4.1 Graphical encapsulation overview and relation to other standards. The ATSC TSFS Standard supports the transmission of the following types of BIOP objects defined in section 11.3.2 of [DSMCC]: DSM::Directory, DSM::File, and DSM::ServiceGateway. Carriage of these objects is done by means of the DSM-CC Data Carousel protocol as described in sections 11 and 9 of [DSMCC]. However, the ATSC TSFS standard further constrains the syntax and semantics of the BIOP objects to satisfy the requirements set forth in [RFP]. Each of these objects contains a header giving the object key (unique identifier within the data carousel module containing it) and the type (directory, file, or service gateway) of the object. The header of a DSM::File object also has an objectInfo structure giving the file size, content- type (MIME type), and a “last modified” time stamp. The header of a DSM::Directory or DSM::ServiceGateway object has an objectinfo structure that optionally contains a “last modified” time stamp. It does not convey a content-type, since a content-type as defined in [MIME] is not applicable to directory objects. The body of a DSM::File object is just the file content. The body of 13 ATSC Transport Stream File System Standard 25 February 2003 a DSM::ServiceGateway or DSM::Directory object consists of a list of bindings (references to other objects, with associated binding names). A binding contains a binding name, the object type of the referenced object (directory, file, or service gateway), an IOP::IOR (Interoperable Object Reference) giving the location of the referenced object, and an objectInfo structure that may contain some or all of the same information as the objectInfo structure in the header of the referenced object. A binding is often called a directory link or a directory entry, and an IOP::IOR is often just called an IOR. Figure 4.2 illustrates the general structure of a DSM::Directory object and DSM::File object. A DSM::Directory object includes an objectInfo structure and a binding structure referencing zero or more child objects (DSM::Directory or DSM::File objects). The binding information includes an objectInfo field for the purpose of providing early information about a referenced object. When descriptors are listed in such an objectInfo structure, their contents are identical to the contents of the descriptors listed in the objectInfo structure that appears in the header of the object itself. (a) (b) DSM::Directory object DSM::File object objectInfo objectInfo time-stamp content-size binding structure content-type time-stamp binding file content name IOP::IOR objectInfo content-size content-type time-stamp Figure 4.2 (a) Directory object (b) File object. A DSM::ServiceGateway object is similar to a DSM::Directory object. The main difference between these two objects is simply in the syntax of the name or names listed in the binding structure. For a DSM::ServiceGateway object, a binding name is always a base URI while for a DSM::Directory object a binding name is a relative path. Each TSFS has exactly one Service Gateway object, which serves as the top level directory of the TSFS. The objects in the TSFS can all be reached by following a directory path (sequence of directory links) starting from the Service Gateway. An object in a TSFS can be referenced from multiple directories in the TSFS, so there can be multiple paths from the Service Gateway to an object in the TSFS. Such paths cannot create any circular paths in the directory reference 14 ATSC Transport Stream File System Standard 25 February 2003 structure. For example, the situation where directory A contains a reference to directory B, which in turn contains a reference to directory A, cannot occur. As mentioned above, the names that appear in the binding structures of the Service Gateway object all conform to the syntax of an absolute URI, as specified in [URI], and the names that appear in the binding structures of lower level directories of a TSFS all conform to the syntax of a relative path, as specified in [URI]. The effect of this is that each file or directory object in a TSFS, with the exception of the Service Gateway object itself, has an associated absolute URI that can be used to reference the object, obtained by concatenating the names in a sequence of directory references leading from the Service Gateway to the object, with slashes (/) as delimiters between them. If there are multiple such sequences of directory references leading to the object, then it has multiple URIs associated with it. An IOR referencing an object in the same TSFS contains the object key for the referenced object, the carousel ID and module ID of the data carousel module containing the object, a Tap identifying the Program Element containing the DownloadInfoIndication (DII) message describing the delivery parameters for the module, and optionally a Tap identifying the Program Element containing the DownloadDataBlock (DDB) messages carrying the module itself. The DII message gives such information as the block size, module size, module version, and delivery timeout intervals for the module, together with a Tap identifying the Program Element containing the DDB messages carrying the module. All objects of a TSFS are carried in a single virtual channel. However, it is also possible to have bindings that contain references to objects in other TSFSs (often called “soft links”). These other TSFSs may be in the same virtual channel or a different virtual channel, even a different virtual channel in a different transport stream. Thus, the logical name space of a TSFS may span multiple virtual channels and even multiple transport streams. An IOR referencing an object in a different TSFS identifies the TSFS containing the object and gives the directory path (sequence of directory links) in that TSFS that leads from the Service Gateway of that TSFS to the object. Organization of the ATSC TSFS into the Data Modules of an ATSC Data Carousel [A90] is not specified by this standard. For example, the BIOP Service Gateway and BIOP Directory objects can be located in one or multiple data modules that may or may not be separate from the data modules conveying the BIOP File objects. Such a design can be used to allow more frequent transmissions of the data modules conveying the BIOP Service Gateway and the BIOP Directory objects so upon tuning to a new Virtual Channel, receivers get an opportunity to reconstruct an image of the file hierarchy with minimum latency. There is a constraint imposed by [DSMCC] (in Sections 7.5.4 and 9.2.5) that all the DDB messages carrying the modules of a single data carousel must be in the same program element, and DDB messages carrying modules of different data carousels must be in different program elements. However, the DSI and DII messages of a data carousel can be in the same program elements as the DDB messages or can be in one or more other program elements, and the DSI and DII messages of different data carousels can appear in the same program element. To allow unambiguous identification of a TSFS in an ATSC Transport Stream, a new protocol_encapsulation value is defined for the Data Service Table (DST) of the Data Broadcast Standard [A90] to signal the Object Carousel encapsulation. For each TSFS used by an application in a data service, the DST contains a Tap referencing the Program Element containing the DSI message that signals the location of the Service Gateway object for the TSFS. 15 ATSC Transport Stream File System Standard 25 February 2003 In the case where this Program Element resides in a remote ATSC Virtual Channel or a remote ATSC Transport Stream, it is signaled in the Network Resources Table (NRT). 5. STRUCTURES 5.1 Carousel NSAP Address Each instance of a TSFS represents a Service Domain, which is defined in Section 1.1 of [DSMCC] as “a collection of interfaces to browse and select services” and is later referred to informally in Section 5.1.2 of [DSMCC] as a “directory hierarchy.” Each Service Domain shall have a globally unique identifier associated with it, called the Carousel NSAP (Network Service Access Point) address. Table 5.1 describes the Carousel NSAP address structure, with overall syntax as specified in [DSMCC] and privateData() syntax as specified by this standard. Table 5.1 Carousel NSAP Address Syntax Syntax No. of Bits Format CarouselNSAPaddress() { AFI 8 uimsbf type 8 uimsbf carouselId 32 uimsbf specifierType 8 uimsbf specifierData 24 uimsbf privateData() { transportStreamID 16 uimsbf originalTSID 16 uimsbf program_number 16 uimsbf sourceId 16 uimsbf originalSourceId 16 uimsbf } } AFI — This 8-bit Authority and Format Identifier field shall be set to 0x00, as specified in Section 11.2.2 of [DSMCC]. type — This 8-bit field shall be set to 0x00 indicating that the Carousel NSAP address points to a U-U Object Carousel. The values in the range 0x01 to 0x7F are reserved to ISO/IEC 13818- 6. The values in the range 0x80 to 0xFF are user private and their use is outside the scope of this specification. carouselId — This 32-bit field shall uniquely identify the carousel within the Virtual Channel. specifierType — This 8-bit field shall be set to 0x01 to indicate that the specifierData field is an OUI, as specified in [DSMCC] Chapter 6. specifierData — This 24-bit field shall be set to the IEEE OUI of ATSC, 0x000979. This field, along with the specifierType, uniquely scopes the combination of transportStreamId and source_id fields that follow. 16 ATSC Transport Stream File System Standard 25 February 2003 transportStreamID – This 16-bit field shall contain the transport_stream_id (TSID) of the MPEG-2 transport stream containing the TSFS, as it appears in the Program Association Table of the transport stream. During remultiplexing it may be changed to reflect the TSID of the new transport stream carrying the TSFS. originalTSID – This 16-bit field shall contain the TSID of the MPEG-2 transport stream in which the virtual channel containing this TSFS was originally broadcast. It shall not be changed during remultiplexing operations. Note: Coordination of sources to ensure uniqueness of originalTSID is outside the scope of this standard. program_number – This 16-bit field shall contain the program_number from the program_map_section [MPEG] associated with the Virtual Channel conveying the Service Gateway object of this TSFS. source_id – This 16-bit field shall contain the source_id for the virtual channel carrying the TSFS, as it appears in the Virtual Channel Table. (Note that a TSFS may appear in more than one virtual channel, since virtual channels may have overlapping program elements, so that a TSFS may have more than one NSAP address associated with it. However, a single NSAP address cannot refer to more than one TSFS.) During re-multiplexing it may be changed to reflect a new source_id for the virtual channel. originalSourceId – This 16-bit field shall contain the source_id for the virtual channel in which this TSFS was originally broadcast. It shall not be changed during re-multiplexing operations. Note that if the source_id is in the range 0x1000 to 0xFFFF, so that it is unique at the regional level (per [A65]), then the source_id will never need to change during typical remultiplexing (e.g., for cable carriage), and a receiver will normally be able to find the correct virtual channel containing the TSFS with a given Carousel NSAP Address from the source_id alone. If the source_id is in the range from 0x0001 to 0x0FFF, then the combination of originalTSID and originalSourceId forms an identifier for the virtual channel that is unique and invariant under remultiplexing, but it will take more effort for a receiver to actually locate the TSFS from this identifier. A discussion of the resolution process for a Carousel NSAP address appears in Annex B Section 3. 5.2 Interoperable Object Reference (IOR) Format An ATSC Transport Stream File System is a collection of DSM-CC BIOP object structures of types DSM::Directory, DSM::File, and DSM::ServiceGateway. These objects are organized into a directory hierarchy by means of bindings in the Directory and Service Gateway objects that associate names with references to objects. References to objects in an ATSC TSFS shall follow the format of an IOR, as specified in Sections 5.6 and 11.3.1 of [DSMCC], with the additional constraints specified in this section. Table 5.2 presents the constrained IOR structure. Table 5.3 shows the values of the type_id field corresponding to each type of BIOP object that may be referenced by an IOR according to this standard. Other object types have no meaning in this standard. 17 ATSC Transport Stream File System Standard 25 February 2003 Table 5.2 Definition of the IOR Structure Syntax No. of Bits Format IOP::IOR () { typeId_length 32 uimsbf for (i=0; i, which identifies the object uniquely. The DSM::ConnBinder structure uses the DSM::Tap() structure defined in Section 5.6.1 of [DSMCC] to indicate where the object can be found in the MPEG-2 program. The first Tap in the DSM::ConnBinder structure of the BIOPProfileBody shall identify the Program Element that has the DII message giving the delivery parameters for the module containing the object referenced by the IOR. There may be an additional Tap which identifies a Program Element that has the DDB messages carrying the module itself. Any further taps in the DSM::ConnBinder structure have no meaning in this standard. 19 ATSC Transport Stream File System Standard 25 February 2003 Table 5.4 BIOPProfileBody Structure Syntax No. of Bits Format BIOPProfileBody { profileId_tag 32 uimsbf profile_data_length 32 uimsbf profile_data_byte_order 8 uimsbf component_count 8 uimsbf BIOP::ObjectLocation { objectLocation_tag 32 uimsbf objectLocation_length 8 uimsbf carouselId 32 uimsbf moduleId 16 uimsbf version.major 8 uimsbf version.minor 8 uimsbf objectKey { objectKey_length 8 uimsbf For (k=0; k< objectKey_length; k++) { objectKey_byte 8 bslbf } } } DSM::ConnBinder { connBinder_tag 32 uimsbf connBinder_length 8 uimsbf tap_count 8 uimsbf for (j=0; j 10 ) { for (k = 0; k