11.2 Sections, Modules, and Objects

Files and directories are transmitted using a DSM-CC object carousel . Objects are encapsulated in modules, which are encapsulated within modules, which are encapsulated within download data blocks, which are encapsulated within DSM-CC sections, which are encapsulated within MPEG private sections which are assembled from packets (see Figure 11.7). Each module is assembled from the payload of one or more download data messages each defined using the DSM-CC DDB syntax. The number of messages depends on the size of the module and the maximum payload of each download data message. Information describing each module and any logical grouping is provided by download control messages, defined using the DSM-CC DII and Download Server Initiate (DSI) messages. A third control message, Download Cancel (DC), can be used to terminate the download.

Figure 11.7. MPEG-2 Encapsulation of the DCM-CC file system

11.2.1 Packets

As explained earlier, the MPEG-2 transport is composed of a sequence of packets. Each of these packets consists of a 32 bit header and a 184 byte payload (see Figure 11.8). The header contains information about the packet. The payload contains the data carried by the packet; for detailed description of these fields see the MPEG-2 standard (see Table 11.2).

Figure 11.8. The structure of an MPEG-2 Packet.

11.2.2 Sections

MPEG-2 sections are carried directly in the payload of transport stream packets. A pointer_field is an 8 bits long field is used specify how many bytes after the header the receiver needs to count before reading the data carried in the packet's payload. This allows sections not to start immediately after the packet header, and is useful, for example, with very high bit rates to allow receivers and multiplexers to process the header. When the section data does not completely fill the packet, e.g., in the last packet carrying that section, a stuffing area is filed with the value 0xFF.

11.2.3 Tables

MPEG-2 Tables are the basic MPEG-2 content structure (see Table 11.3), assembled from up to 256 MPEG-2 sections. Each section has a header, a payload and a trailer. Each section carries at most 4 kBs. Short tables are composed of a single section (the length field is 12 bits). The syntax of a section bit-stream is specified in Table 11.2.

Table 11.2. The Detailed Description of Fields within a Packet Header

Field	Description	Value	# Bits
sync_byte	Always the first byte of an MPEG-2 packet. This number is used to scan a sequence of bits and identify the beginning of the packet.	0x47	8
transport_error_indicator	Set by transmission system to indicate an uncorrectable error in this packet. Receivers often ignore such packets.	1 = err	1
payload_unit_start_indicator	Set to 1 for the first packet in the section, and 0 for all subsequent packets. In the case of back-to-back sections, when this packet may contain the end of one section and the beginning of the next , this bit is set to 1.	1 = 1st
transport_priority	This bit is used to distinguish high-priority packets from normal packets. This bit is rarely used.		1
Packet Identifier (PID)	Each value identifies a unique data stream within an MPEG-2 transport. All packets having the same PID belong to the same data stream (i.e., MPEG-2 transport component).		13
transport_scrambling_control	00 = unscrambled payload 01,10,11 = user defined.		2
adaptation_field_control	00 = Not allowed (reserved) 01 = No adaptation_field, payload only 10 = Adaptation field only; no payload 11 = Both adaptation field and payload See MPEG-2 specification for the detailed description of the function and use of the adaptation field.		2
continuity_count	Each successive packet has this value incremented by 1 (except when adaptation_field _control is set to 10). A break in the sequence usually indicates lost packets.

Figure 11.9. The structure of MPEG-2 Tables.

Table 11.3. Section Structure for Assembling Tables

Field	Description	Value	# Bits
table_id	Always the firsat byte of a section. Standard organizations maintain lists of predefined table_id to avoid collisions.	0x47	8
section_syntax_indicator	0 indicates that the data begins immediately following the private_section_length field; this is referred to as 'short' section. A value of 1 indicates that fields describing the section follow the private_section_length field; this is referred to as the 'long' section.		1
private_indicator	The meaning of this field depends on the value of table_id. For user-defined values, this bit is user-defined.	1	1
reserved	Reserved fields are usually set to 1's.	0x03	2
private_section_length	The number of types immediately following this field through the end of this section. The maximum value is 0xFFD (i.e., 4093) bytes. If section_syntax_indicator=0, the bytes following this field are the data bytes.	0x000-0xFFD	12
table_id_extension	Present if section_syntax_indicator=1. It specifies proprietary (i.e., non-standard) table type.		16
reserved	Reserved fields should be set to 1's.	0x03	2
version_number	Specifies the version number of the section. To accommodate random tuning, the sections are transmitted repeatedly. Receivers can inspect the version number of this section to determine whether new data is available in the transport. This test is used to avoid automatic reloading of data when it was already acquired .	0x00-0x1F	5
current_next_indicator	A value of 1 indicates that this is the active version of this section; 0 indicates that this is an inactive version. It is used to prevent loading of stale data.		1
section_number	This field specifies the number of this section within the table. This number is used by receivers to assemble the table from a collection of sections. To assemble a table, the receivers needs to wait until all sections within a table have received. The capability to address up to 256 tables implies that the maximum table length is 256 x 4096 = 1 MB.		8
last_section_number	This field indicates the number of the last section in the sequence. A receiver may assemble a table once all section whose section_number field specified all numbers from 0 to this number.		8

11.2.4 Program Specific Information (PSI) Tables

PSI is a collection of pre-defined tables. It includes the PAT, PMT, and the CAT.

The PAT is the entry point into the transport stream. Without the discovery of the PAT, it is not possible for a receiver to understand the transport stream. The discovery of the PAT enables identifying the list of MPEG-2 programs carried in the transport, each specified by a reference to an instance of the PMT. It points to the PMT of each program. The PAT is sent with the well-known PID value of 0x000. To facilitate such discovery and acquisition in situations when random tuning occurs, the PAT is transmitted periodically, for example, every 0.1 seconds.

Each instance of the PMT (pointed to by the PAT) lists all the component streams of this program. These components include the video and audio components of the MPEG-2 program. One of these components , is the stream carrying the broadcasted file system. The PID carrying the PMT is specified by the PAT.

The CAT defines the type of scrambling used and PID values of transport streams that contain the conditional access management and entitlement information. The CAT is sent with the well-known PID value of 0x001.

Figure 11.10 depicts a simplified reference structure used to acquire a TFS MPEG transport stream (which may carry MPEG-4 video, for example). The DSM-CC file system may span multiple streams within a single transport, and even multiple transports. The root directory is specified using the DSM-CC ServiceGateway object. Other directories are specified using the DSM-CC Directory object, and files are specified using the DSM-CC File object.

Figure 11.10. Using PSI to point to the broadcaster file system

11.2.5 Download Protocols

DSM-CC specifies two download protocols: the data and object carousel. The data carousel is simpler and more limited than the object carousel. The data carousel utilizes the DDB to carry the data. The DSI table is used to specify the beginning of a sequence of DDB sections. DDB sections may be long, and therefore it is not practical to retransmit them with high frequency. The DII messages are used to assemble DDB sections into modules when random tuning occurs.

The DSM-CC data carousel supports a single layer and two-layer versions of the protocol. The single layer is a simplified version suitable for smaller data download scenarios. The two layer carousel is suitable for more complex scenarios in which there are too many DDB blocks to use a single DII message for pointing to all of them, or in situation that grouping can improve efficiency of download.

11.2.6 Object Carousel

The DSM-CC object carousel extends the data carousel by standardizing the directory structure is needed for supporting even the most elementary file system. It requires using three object types: the root-directory type, non-root directory objects and file objects. The object carousel standard directory format is based on the Common Data Representation (CDR) structures defined for the Common Object Request Broker Architecture (CORBA) [OMG], designed for use by a variety of programming languages. This format is best for environments where storage and network bandwidth are plentiful. To simplify, improve the efficiency and render the protocol adequate for iTV broadcasting, CDR-Lite was developed, which is a simplified over-the-wire version trading off some reduction in flexibility. It differs from the CDR as follows :

• It uses the maximums on sequences and strings to reduce the size of the encoded length value. An IDL-specified maximum of 255 results in an encoded octet to hold the sequence or string length. An IDL-specified maximum of 65,535 results in encoded unsigned short to hold the sequence or string length.

• It uses byte alignment in order to achieve compact packing of data.

• The CDR Lite delivers the benefits of the CDR while avoiding some storage inefficiencies .

The ATSC Data Broadcast Group recognized that the DSM-CC object carousel has a number of features not required for iTV broadcasts, yet does not standardize information that is required for iTV broadcast. Therefore, it introduced the ATSC A95 TSFS standard, which simplifies the DSM-CC object carousel by disabling some features related to bi-directional interaction [A95]. Further, to allow specifying MIME types of files and modification dates, the ATSC A95 TSFS introduces a number of descriptors within the objectInfo structure which is part of the IOR structure (described in this chapter).

11.2.6.1 Carousel Network Service Access Point (NSAP) Address

Each instance of a DSM-CC file system represents a service domain. Each service domain is associated with a globally unique identifier, called the carousel NSAP address (see Table 5.1). The key issue emerging from the NSAP address structure is the need for remultiplexers to parse and update it.

Table 11.4. Carousel NSAP Address Syntax

Syntax			No. of Bits	Format
AFI			8	uimsbf
	type		8	uimsbf
	carouselId		32	uimsbf
	specifierType		8	uimsbf
	specifierData { Org. Unique. ID }		24	uimsbf
	ServiceLocation () {
		TSID	16	uimsbf
		originalTSID	16	uimsbf
		programNumber	16	uimsbf
		sourceId	16	uimsbf
		originalSourceId	16	uimsbf
	}

AFI : This Authority and Format Identifier (AFI) is defined in ISO 8348 Annex B as designating NSAP addresses reserved for private use. As such, the rest of the NSAP address fields are available for private definition.

type : A value of 0x00 indicates 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.

carouselId : This 32-bit field uniquely identifies the carousel within a transport stream.

specifierType : A value of 0x01 indicates that the specifierData field is an Organizational Unique Identifier (OUI) as specified in chapter 6 of the DSM-CC specification [DSM-CC].

specifierData : This 24-bit field is set to the OUI; for ATSC, the value is 0x000979. This field, along with the specifierType, uniquely scope the combination of TSID and program_number that follow.

TSID : This 16-bit field contains the TSID of the MPEG-2 transport stream carrying the DSM-CC file system, as it appears in the PAT for the transport stream. During remultiplexing the value of this field may need to be changed.

originalTSID : This is the original TSID before any changes were performed through remultiplexing. The original TSID is needed to resolve TSID references within the object carousel structures; remultiplexers do not parse object carousel structures and thus cannot fix dangling TSID references.

programNumber : Each data carried in an MPEG transport stream is associated with a program number. This 16-bit field associates this file system with the number of the program containing the number of the MPEG-2 program. During remultiplexing, this number may be changed to reflect a new program number for the program.

sourceId : This 16-bit field contains the identifier of the virtual channel associated with this file system. All the files of iTV programs associated with that virtual channel are carried within this file system. A DSM-CC file system may be associated with multiple NSAP addresses structures, and thus may carry applications associated with multiple virtual channels. During remultiplexing, this field may be changed to reflect a new sourceId for the virtual channel.

originalSourceId : This 16-bit field contains the original virtual channel identifier before introducing changes by any remultiplexing operations. In ATSC transport streams, this field is in the range 0x1000 to 0xFFFF, and is unique at the regional level. For values in the range from 0x0001 to 0x0FFF, the combination of originalTSID and originalSourceId still forms an identifier for the virtual channel that is unique and invariant under remultiplexing, but it takes more effort for a receiver to actually locate the file system.

reserved : This field is set to 0xFFFF.

11.2.6.2 IOR versus URI

The IOR of a DSM-CC object serves as a pointer to an object. It carries all the information pertaining to an object that in particular can be used to resolve it within a service domain via the 3-tuple < carouselId , moduleId , objectKey >; when a service domain spans multiple transport, identification of an object further requires the TSID of the transport within which the object is carried. The data pointed to by an IOR (the actual file or directory content) is carried in a Basic Input Output Protocol (BIOP) data message, which is a serialization format of an object. Each such serialization consists of a header, a subheader, and a message body.

The URI was developed by the W3C to provide a simple unified and extensible mechanism for identifying a resource [URI]. A URI can be viewed as the concatenation of the base-URI with the relative-URI. The URI framework merges URLs (RFC 1738) and Relative URLs (RFC 1808) in order to define a single, generic syntax for all URIs. As a result, a URI can be classified as a locator, a name , or both. The term URL refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network location), rather than identifying the resource by name or some other attribute of that resource. URN refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable.

The specific design adopted by ATSC A95 TSFS improves the DSM-CC object carousel data serialization format by standardizing the mapping between IORs and URIs [A95]. The TSFS requires populating the binding structures within the entries of the root directory, the service gateway, with the base-URI of the directory tree pointed to that entry (recall Figure 11.4 above). The name specified by the base-URI (e.g., http://fox.tv ) is regarded as the prefix of all URIs of each file in the entire directory sub-tree referenced. Subdirectories in that tree specify a path segment, recursively, until the last name segment is actually the name of a file (recall Figure 11.5).

Whereas the IOR is anticipated to be useful for transport decoders, the URI namespace is anticipated to be useful for application environments. The use of a base-URI in the service gateway decouples the URI namespace from the object carousels namespace. This approach enables the decoupling of transport topologies from application namespaces, virtually eliminating ramification of object carousel design constraints up-stream the emission station. An an example of this decoupling, a DCM-CC file system can have its service gateway contain a flat list of files (i.e., each file is placed under the root directory) each associated with a URI. A more effective design would place in the ServiceGateway object a few directories each having a few sub-directories or files recursively. Further, the DSM-CC object carousel allows the use of multiple parents, thus enabling a file or directory to have multiple names (recall Figure 11.4).

11.2.6.3 Selective Acquisition and Browsing

With the DSM-CC object carousel, there is no need to acquire the entire file system when only a portion of the resources are needed. For example, when only one directory is needed, it is only necessary to acquire the files referenced by this directory. This is achieved by identifying the DII messages pointing to the module's DDB in which the desired files are present. Acquisition of a DII message provides all the information necessary for acquiring each module separately, and enables selective acquisition of modules. In each stream carrying a DSM-CC object carousel there should be at least one DII message.

11.2.6.4 IOR Format

An IOR is a structure containing necessary information for locating an object. Two types of IORs are commonly used, one containing a BIOP::ProfileBody that is used to reference objects in the same file system, and one containing a LiteOptionsProfileBody that is used to reference objects in a remote file system (which may be in the same virtual channel, a different virtual channel in the same transport stream, or a different virtual channel in a different transport stream).

The IOR format, defined by CORBA and used by the DSM-CC object carousel standard, contains the mandatory LiteComponent , ObjectLocation and ConnBinder structures. Each IOR has a typeId, specifying its type, and a sequence of tagged profile structures. A tagged profile structure is meta-data describing the type of serialization of an object (e.g., directory or file) in the object carousel. Each of these structures have the same Interface Definition Language (IDL) syntax as their counterpart CDR profiles. However, only a subset of those profiles is used which have smaller footprint. For example, the LiteComponentProfile is used as a multicomponent profile to conserve space. Each element in the LiteComponentProfile is a LiteComponent structure, each binding a component ID to its data.

Table 11.5. The IOR Structure.

Syntax				No. of Bits	Format
typeId_length				32	uimsbf
typeId_byte				typeId_length * 8	uimsbf
taggedProfile_count				32	uimsbf
for (i=0, i<taggedProfile_count-1; i++) {
	IOP::TaggedProfile() {
			BIOPProfileBody() or LiteOptionsProfileBody()
			}
}

typeId_length : This 32-bit field is the length of a null terminating string specifying the name of the type of this object. Typically, the types used are "dir", "fil" and "srg", implying of a value of 0x04 is used.

typeId_byte : This is the content of the type string; typically the values of "dir", "fil" and "srg" to indicate a directory, file and ServiceGateway object respectively. In each case the typeId_byte string is terminated by a byte with value 0x00.

taggedProfile_count : This 32-bit field specifies the number of tagged profiles.

11.2.6.5 ConnBinder

The ConnBinder structure is used to create a binding (or mapping) between the IORs of an object and its physical location within a transport. A ConnBinder structure is a list of Transport Access Partitions (TAP) carried in the IOR. Each element of this list servers as a pointer to a component of the data referred to by that IOR. The TAP has the following information (see Figure 11.11):

• An tapId which is unique within the transport.

• A tapUse enumerator that indicates the type of the component it points to.

• An association_tag that identifies a program component identified in the PMT by the same exact association tag value; association tags enable remultiplexing without decoding streams by avoiding hard-coding PIDs in the stream (see the MPEG standard for details).

• A selector is used for filtering out portions of the transport bit-stream (i.e., MPEG transport component) carrying it (e.g., a TAP selector might specify a single PID). The meaning of the selector value depends on the value of the tapUse field within that same TAP structure.

Figure 11.11 The IDL Definition of the TAP Structure.

 struct tap {            u_short tapUse;                // the use for the TAP            u_short id;                    // identifier            u_short assocTag;              // the group identifier                                              for network resource                                              descriptors            sequence<octet, 255> selector; // upper protocol                                              selection info }; typedef sequence<tap, 255> ConnBinder;    // typically have request                                              and data channels 

11.2.6.6 Object Location Structure

An ObjectLocation structure uniquely locates the object within the MPEG-2 Transport Stream. It contains a carouselId , a moduleId , a version number and an objectKey . The carouselId and moduleId are used to identify which elementary stream (i.e., PID) contains the object. The objectKey , which is a sequence of up to 255 bytes (i.e., octets), is used to specify which object within the module is referenced (recall that a module may contain many objects). The IDL definition for the object location structure is described in Figure 11.12.

Figure 11.12 The IDL Definition of the ObjectLocation Structure.

 struct ObjectLocation {      unsigned long               carouselId;      unsigned short              moduleId;      DSM::Version                version;      sequence <octet, 255> objectKey; }; 

11.2.6.7 The BIOPProfileBody Structure

References to objects within the same object carousel file system are made using an IOR containing a BIOPProfileBody . All such objects for a single object carousel (which may contains portions of multiple file systems) are carried in packets that belong to the same MPEG program that carries the IOR. The BIOPProfileBody carries information that is used to locate that object within a service domain specified by an NSAP address via the 3-tuple < carouselId , moduleId , objectKey >. In ATSC transports, the two components in the BIOPProfileBody are typically ObjectLocation and ConnBinder , in that order.

Table 11.6. Definition of the BIOPProfileBody Structure in ATSC Transports

Syntax						No. of Bits	Value
BIOPProfileBody {
	profileId_tag					32	0x49534F06
	profile_data_length					32	uimsbf
	profile_data_byte_order					8	uimsbf
	component_count					8	0x02
	BIOP::ObjectLocation {
		objectLocation_tag				32	0x49534F50
		objectLocation_length				8	uimsbf
		carouselId				32	uimsbf
		moduleId				16	uimsbf
		version.major				8	0x01
		version.minor				8	0x00
		objectKey_length				8	uimsbf
		objectKey_data				objectKey_length * 8	uimsbf
	}
	DSM::ConnBinder {
		connBinder_tag				32	0x49534F40
		connBinder_length				8	uimsbf
		tap_count				8	uimsbf
		for (j=0; j<tap_count 1; j++) {
			BIOP::TAP {
				tapId		16	uimsbf
				tapUse		16	uimsbf
				association_tag		16	uimsbf
				selector() {
					selector_length	8	uimsbf
					selector_type	16	uimsbf
					transactionId	32	uimsbf
					timeout	32	uimsbf
				}
		} // close TAP
	} // close connBinder
}

profileId_tag : This 32-bit field is set to 0x49534F06 indicating that this is a BIOP Protocol Profile (as per [DSM-CC] section 5.6.3.5).

profile_data_length : This 32-bit field specifies the total number of bytes in this BIOPProfileBody structure excluding this field and excluding the profileId_tag field.

profile_data_byte_order : This 8-bit field indicates whether big-endian or little-endian byte ordering is used; in ATSC it is to 0x00 (=FALSE) is required indicating big-endian byte ordering.

component_count : This 8-bit field specifies the number of components in this BIOPProfileBody structure. In ATSC, this field is set to 0x02, the first component is an ObjectLocation structure and is a ConnBinder structure.

objectLocation_tag : This 32-bit field is set to 0x49534F50 indicating that this is an ObjectLocation structure.

objectLocation_length : This 8-bit field specifies the number of bytes in the ObjectLocation structure following this field (not including this field).

carouselId : This 32-bit field specifies the unique carouselId value for the carousel containing the object. It is typically recommended (and required by ATSC) that all DDB and DII messages within the carousel share the same carouselId .

moduleId : This 16-bit field specifies the Id of the module containing the object; this Id must be unique within the carousel, namely the combination of carouselId and moduleId uniquely identifies the module.

version_major : This 8-bit field contains the major version number of the BIOP protocol used in this message. In ATSC, the major version number is 1.

version_minor : This 8-bit field contains the minor version number of the BIOP protocol used in this message. In ATSC, the major version number is 0.

objectKey_length : This 8-bit field specifies the number of bytes that the objectKey occupies; ATSC requires that the maximum value of this field (and length of the object key) is 0x08 because the object key is restricted to be at most 64 bits.

objectKey : This field uniquely identifies the object within the module carrying the serialization of this object. Two objects in the same module are regarded as equivalent if and only if their objectKey_bytes are identical. objectKey s are only required to be unique within a specific module and do not need to be unique within the file system. Some carousel generators, however, use object keys which are unique within the entire file system, a practice that may require long object keys.

connBinder_tag : This 32-bit field is set to 0x49534F40 indicating that this is a ConnBinder structure.

connBinder_length : This 8-bit field is set to the total length in bytes of all the TAPs in this ConnBinder structure (excluding this field and the connBinder_tag field).

tap_count : This 8-bit field specifies the number of TAPs in the ConnBinder .

tapId : The value of this 16-bit field is sometimes used as a unique identifier of this TAP to enable references to it from other locations; it is not recommended to use TAP references, and only object references should be used. Receivers typically ignore this field.

tapUse : ATSC allows at most two TAPs in a ConnBinder . The tapUse of the first TAP is set to 0x0016 (=BIOP_DELIVERY_PARA_USE) indicating that this TAP identifies the program element containing the DII message describing the delivery parameters for the module containing the object. The second TAP is optional and identifies the program element containing the DDB messages conveying the module itself. If such a TAP is present, the tapUse field for this TAP is set to 0x0017 (=BIOP_OBJECT_USE).

association_tag : This 16-bit field uniquely identifies a program element listed in the Program Map Section for the current virtual channel. The value of this field matches the value of the association_tag field of an association_tag_descriptor in the PMT.

selector_length : This 8-bit field specifies the number of bytes in the TAP structure following (i.e., excluding) this field. When tapUse is 0x0016 (=BIOP_DELIVERY_PARA_USE) the value of this field is 0x10. When tapUse is 0x0017 (=BIOP_OBJECT_USE) the value of this field is 0x00, and the remaining fields of the selector() are omitted.

selector_type : When tapUse is BIOP_DELIVERY_PARA_USE, this 16-bit field is set to 0x01 to indicate the use of a MessageSelector . When tapUse is BIOP_OBJECT_USE, this 16-bit field is omitted.

transactionId : When tapUse is BIOP_DELIVERY_PARA_USE, this 32-bit field is set to the transactionId of the DII message that contains the module delivery parameters. When tapUse is BIOP_OBJECT_USE this 32-bit field is omitted.

timeOut : When tapUse is BIOP_DELIVERY_PARA_USE, this 32-bit field indicates the timeout period to be used to time out the acquisition of the DII message. The units of the timeout field are microseconds (see [DSM-CC] Chapter 11). When tapUse is BIOP_OBJECT_USE, this 32-bit field is omitted.

11.2.6.8 The LiteOptionProfileBody Structure

References to objects within a different object carousel (but the same file system) are made using an IOR containing a LiteOptionsProfileBody (see Table 11.7). This means that the other object carousels can have a different carouselId , different sourceId , or different TSID. The LiteOptionsProfileBody contains a ServiceLocation component, which contains the NSAP address of the remote object carousel and a specification for the path from the ServiceGateway to the referenced object.

In ATSC, the LiteOptionsProfileBody it may only reference a directory or file, but may not reference a ServiceGateway . This is because of the use of base-URIs in the ServiceGateway . In other words, the LiteOptionsProfileBody must imply a base-URI, because the LiteOptionsProfileBody already has a base-URI associated with it through its own ServiceGateway object.

Table 11.7. Definition of the LiteOptionsProfileBody Structure in ATSC Transports

Syntax					No. of Bits	Value
LiteOptionsProfileBody {
	profileId_tag				32	0x49534F05
	profile_data_length				32	uimsbf
	profile_data_byte_order				8	0x00
	component_count				8	0x01
	DSM::ServiceLocation {
		componentId_tag			32	0x49534F46
		component_data_length			8	uimsbf
		carouselNSAPaddress_length			8	0x14
		carouselNSAPaddress()			160
		Name() {
			nameComponents_count		32	uimsbf
			for (j=0; j<nameComponents_count ; j++) {
				nameComponent_length	32	uimbsf
				nameComponent_data	nameComponent_length * 8
				kind_length	32	0x00000004
				kind_data	32	either 'dir,' 'fil,' or 'srg'
			} // end name component
		} // end name
		InitialContext_length			32	0x00000000
	} // end DSM					ServiceLocation
}

profileId_tag : This 32-bit field is set to 0x49534F05 indicating that this is a Lite Options Protocol Profile (see the DSM-CC specification section 5.6.3.4).

profile_data_length : This 32-bit field specifies the total number of bytes in this LiteOptionsProfileBody structure following (i.e., excluding) this field.

profile_data_byte_order : This 8-bit field indicates whether big-endian or little-endian byte ordering is used. In ATSC, this field is set to 0x00 (=FALSE) indicating big-endian byte ordering for the subsequent fields of the message.

component_count : This 8-bit field is set to the number of components in this LiteOptionsProfileBody . In ATSC A95 only a single component ( ServiceLocation ) is used [A95].

componentId_tag : This 32-bit field is set to 0x49534F46, indicating that this is an ServiceLocation structure.

component_data_length : This 8-bit field specifies the number of bytes in the ServiceLocation structure following this field (not including this field).

carouselNSAPaddress_length : This 8-bit field is set to 0x14, indicating that the Carousel NSAP Address is 20 bytes long.

CarouselNSAPaddress() : This 20-byte field contains the carousel NSAP address of the remote object carousel (see Table 11.4).

nameComponents_count : This 8-bit field indicating the number of segment used to describe the path from this directory to the child directory or file. For example, going back to the example in Figure 11.5, one can use two components of olympic and history to represent the link between the directory whose base-URI is http://pbs.org and the directory whose base-URI is http://pbs.org/olympic/history/ .

nameComponent_length : This 32-bit field specifies the length of the segment's name, including the null terminating byte.

nameComponent_data : This field contains a null terminating string, which is regarded as the segment's name, whose length is specified by the nameComponent_length.

kind_length : This 32-bit field specifies the length of the object kind string. In ATSC this field is set to 0x04. indicating the use of the 3-char alias with a null byte terminator for the object type of the bound object for this link in the path.

kind_data : This 4-byte field contains a null terminating string specifying the object type. In ATSC only the strings "dir," "fil," and "srg" are used.

InitialContext_length : This 32-bit field is set to the length of the Initial Context data. In ATSC, the initial context data is ignored and therefore the value should be 0x00.

11.2.7 IOR Usage

Now that the IOR has been described, it is appropriate to describe its usage. Figure 11.13 illustrates the acquisition sequence for acquiring all the objects in a DSM-CC file system with a simple hierarchical directory structure. The IOR of the ServiceGateway object can be extracted from the DSI message. Given the IOR for the service gateway, the ServiceGateway object can be parsed from the data module carrying it. From the binding structure inside the ServiceGateway object, the IORs for Directory object D and File object F ₂ can be extracted. Given the IOR for F ₂ , the file data for F ₂ can be acquired from the data module carrying the F ₂ object. Given the IOR for D , Directory object D can be extracted, from which the IORs for F and F ₁ can be obtained. Similarly, given the IOR for F and the IOR for F ₁ , the file data for F and F ₁ can be acquired. Thus, the IORs for objects in the directory structure are acquired in the following sequence: IOR-SG, IOR-D , IOR-F ₂ , IOR-F and IOR-F ₁ . Apparently, once an IOR of an object is obtained, the object can then be retrieved from the stream.

Figure 11.13. Acquiring a simple directory structure.

If the directory structure is not a strict tree, but rather a more general acyclic graph, the process is just a little more complex. Some bookkeeping is required to avoid acquiring the same object more than once, and to keep track of the multiple URIs associated with some objects (resulting from the multiple paths leading to them from the service gateway).

An IOR that refers to an object within the same DCM-CC file system (DSM-CC object carousel) contains a BIOPProfileBody that contains the information necessary to locate the BIOP messages that convey the object data and attributes. This BIOPProfileBody comprises an ObjectLocation component and a ConnBinder component.

The ConnBinder component always includes one TAP that tells where to find the DII message that conveys the module delivery parameters of the module containing the object. For simplicity, the tapUse field should be set to BIOP_DELIVERY_PARA_USE and the tapId field of this tap is not used. The association_tag field of this TAP is an indirect reference to the program element containing the DII message. The selector field of the TAP gives the transactionId of the DII message and also the timeout interval for acquiring the DII message, namely the maximum interval between transmissions of the message.

A DII message is uniquely determined within a virtual channel by its carouselId and transactionId . Thus, the receiver can use the association_tag value in the BIOP_DELIVERY_PARA_USE TAP of the ConnBinder component to identify the program element containing the DII message, and then use the transaction_id in this TAP and the carouselId from the ObjectLocation component to identify the DII message within the program element. It can then use the moduleId to identify the entry in the DII message giving the delivery parameters for the DDB messages carrying the desired module.

Figure 11.14 illustrates the process of using the information in the IOR to acquire the object. Figure 11.15 explains how the DII message could be located given the information specified in a TAP. From the DII message pointed to the TAP in a directory entry the receiver can get a TAP identifying the program element containing the DDB messages, and it can use the carouselId and moduleId to identify these DDB messages within that program element. It also gets the block size (size of the payload of each DDB message), total module size, module version, and various time-out parameters. With this information it can allocate buffers of appropriate size, make sure it has acquired all the blocks of the module, and use the time-out intervals to detect errors in transmission.

Figure 11.14. Acquiring an Object from a DSM-CC Object Carousel.

Figure 11.15. The use of TAPs for locating a program element.

Once the receiver has acquired the module containing the object, it can proceed to parse the module from the top down looking for the correct object, as identified by its objectKey . If the objectKey is not the desired value, the value of the message_size field in the object message is used to get the start index of the next BIOP object message in the same data module. This is done until an objectKey in the MessageSubHeader structure of a target BIOP object message is found that matches the desired value.

11.2.7.1 Remote Object Resolution

As explained earlier, an IOR that refers to an object from another DCM-CC file system contains a LiteOptionsProfileBody that provides the information necessary to locate the ServiceGateway of the remote file system, plus the logical directory path in that file system from the service gateway to the object itself. This information comes in the form of a ServiceLocation component that provides a carouselNSAPaddress and a sequence of bindings representing a path from the service gateway to the referenced object.

The steps for resolving the NSAP address in ATSC A95 transports are described in Figure 11.16, where the numbers within the circles denote step number. The resolution process would be straightforward if there was no possibility that the remote transport stream may have been involved in a remultiplexing operation without the knowledge of the server that generated the IOR. The NSAP address is a unique identifier for the service domain. This identifier includes TSID, OriginalTSID , ProgramNumber , sourceId , OriginalSourceId , and carouselId fields that allow a receiver to locate the service gateway for the service domain. The OriginalTSID and OriginalSourceId fields are the TSID and sourceId of the virtual channel in which the remote file system was originally broadcast. The DST is the A90 table used to bind data (step 6); its DVB equivalent is the AIT.

Figure 11.16. Acquiring the Service Gateway from its NSAP Address.

As illustrated in Figure 11.16, a receiver goes through the following steps:

1. In the receiver's cached channel map, locate the transport stream corresponding to the TSID in the NSAP address, tune to that transport stream, and acquire its PAT.

2. In the program loop of that PAT, locate the entry for the MPEG-2 program corresponding to the program_number in the NSAP address.

3. Using the PMT_PID field of that entry, acquire the PMT section for that program.

4. When acquiring that PMT section, confirm that the program_number in that PMT section matches the ProgramNumber being looked for.

5. Find the PID of the program element containing the DST by looking in the stream loop of the PMT section for a program element with stream_type 0x95, and acquire the DST.

6. Find the TAP in the DST (or AIT) with encapsulation_protocol value 0x0F and carouselId value in its selector field matching the carouselId value in the NSAP address.

7. Look at the association_tag value of this TAP and locate the stream entry in the PMT section with an association_tag descriptor that has a matching association_tag value.

8. The PID for this entry identifies the program element that contains the DSI message for the desired service domain.

9. Acquire from this program element the DSI message that has a carouselId matching the carouselId of the NSAP address.

10. Use the service gateway IOR in this DSI message to acquire the ServiceGateway object.

These steps are needed to locate a service gateway from its NSAP address in the case when the TSID and program_number in the NSAP address are correct, either because there has been no remultiplexing of the target virtual channel, or because the NSAP address has been corrected in some way to reflect the remultiplexing.

Once the service gateway is acquired, it is a simple matter to walk down the directory hierarchy to the desired object, matching a name in the desired path to a directory entry at each step, picking up the corresponding IOR, and resolving it according to the process in section B.1 to get to the next object down the hierarchy.

The resolution process becomes more complex if the path was in the form of a single URI, instead of a sequence of path terms. Additional complications arise when the value of TSID and possibly sourceId of the remote file system have changed because of a remultiplexing operation, and the server that generated the IOR containing the NSAP address was not aware of the change. In such a situation the receiver is not able to find a match for the TSID in the channel map, because transport streams should be unique at a regional level, and a remultiplexed transport stream should never retain the transport stream of any of the original input streams.

11.2.7.2 URI Resolution

The IOR and URI namespaces and usage patterns are linked by a URI resolution mechanism. Although not required by the DSM-CC specification, it is recommended that the service gateway contain a base-URIs for each entry, which serves as the base-URI for all the files and directories in the subtree rooted at that entry.

To resolve the URI, take, as input, the URI to be resolved, and perform the following steps (the output is the requested file data.):

1. Acquire the AIT (in DVB MHP) or DST (in ATSC) for the data service and check all the TAPs of the relevant application to generate the list of all the file systems within which to search.

2. For each file system in the list that has a URI in the selector of its TAP, restricting the scope of the TAP, check to see if the URI in the selector matches some left most substring of the input URI. If not, discard that file system. If so, put that file system at the head of the list, since it is an especially likely candidate.

3. For each file system in the list, perform steps 4 through 7 below.

4. Use the association tag in the TAP to identify the program element that has the DSI message containing the ServiceGatewayInfo for the file system. Check all DSI messages that appear in that program element for one with a carouselId in the carouselNSAPaddress that matches the carouselId in the TAP selector. This is the DSI message for the file system.

5. Extract the IOR of the ServiceGateway object from this DSI message.

6. A very easy way to handle the recursive search down the directory tree is to utilize a list in which each list item consists of a pair of components, an IOR and a character string (where the character string consists of an unmatched portion of the input URI). The initial list contains just one item, consisting of the service gateway IOR and the input URI.

7. Go down the list in order. For each item in the list and perform the following:

   1. If the object referenced is a File object, the desired object is found, the file can be returned, and the algorithm can be terminated.

   2. If the object referenced by is a Directory object (or a ServiceGateway object), check each binding in the object to see if the binding name matches some left most substring. For each match that is found, create a new list item containing the IOR associated with the binding and a new character string obtained. Add each such new item to the end of the list.

   3. At the end of the list, where there are no more items to process, then the original URI has no matching in this file system. In that case, go on to the next file system.

8. When reaching the end of the list of candidate File Systems without success, then the original URI has no matching file in this data service.

This description assumes that the data service and the DST (or AIT) application containing the file are known. If this assumption does not hold, the receiver must perform this algorithm for all applications in the DST (or AIT). This usually demands little extra effort. If the data service is not known, the receiver must scan through all the virtual channels it can receive, and perform this algorithm for every DST application of every data service it encounters until is succeeds in finding the file.

It is further assumed that there no caching is performed, i.e., there no service information is being kept in memory by any means. When an intelligent caching mechanism is employed, which caches all Directory objects, steps 17 could be performed directly from memory without significant latency.