13.4 North-AmericaUS Advanced Television Systems Committee (ATSC)

13.4 North-America/US Advanced Television Systems Committee (ATSC)

The ATSC, is an international, non-profit membership organization developing voluntary standards for the entire spectrum of advanced television systems [ATSC]. 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 Digital TV Standards include HDTV, SDTV, data broadcasting, multichannel surround-sound audio, and satellite direct-to-home broadcasting.

Below is an overview of the ATSC standards applicable to iTV, and parallel to DVB-SI + DVB-MHP. These are the A65 PSIP, A90 Data broadcast, A94 Application Reference Model, A95 transport stream File System and A100 DASE standards.

13.4.1 Program and System Information Protocol (PSIP)

The PSIP Standard, ATSC A65, provides a methodology for transporting digital television system information. It requires carriage of information used to define virtual channels and map them to MPEG programs to be acquired when receivers tune to those channels. It requires the transmission of information that is used to assemble EPGs. It further enables broadcasters to perform seamless channel changes by issuing a DCC request.

PSIP is a collection of hierarchically arranged tables for describing system information and program guide data. The following tables are used (see Figure 13.9):

• The MGT defining the type, packet identifiers, and versions for all the other PSIP tables in this transport stream, except for the STT.

• The STT, defining the current date and time of day, which is expected to accurate within seconds. The STT enables receivers to perform time- related operations, such as display the show time, or start recording a program; as an example, Cell Phones use a similar concept to determine the local time.

• The VCT carried within the ATSC MPEG-2 transport stream, tabulate virtual channel attributes required for navigation and tuning. Each virtual channel listed in the VCT is associated with a service_location_descriptor. The VCT exists in two versions: one for terrestrial and a second one for cable applications. The terrestrial and cable versions are similar in structure, with the latter redefining the semantics of some fields pertinent to cable operations.

• The RRT defines the TV parental guideline system referenced by any content advisory descriptor carried within the transport stream. Different ratings tables are valid for different regions or countries ; they are often mandated by law.

• The EIT are used to announce up-coming and currently airing programs. The first four EITs (EIT-0, EIT-1, EIT-2 and EIT-3) describing 12 hours of events (TV programs), each with a coverage of 3 hours, and including all of the virtual channels listed in the VCT.

• An ETT is associated with each event to provide its description.

• The DCC Table (DCCT) carries requests for a receiver to switch to specified virtual channels at specified times under specified circumstances; its to and from channel numbers operate both on terrestrial broadcast and cable virtual channels. Several DCCT instances may be present in the TS simultaneously , each is identified by the dcc_ID which is separately referenced in the MGT.

• The DCC Selection Code Table (DCCSCT) permits extension of the basic hard-coded Categorical Genre Code Assignments defined in Table 6.21 of A65/A DCCSCT had been defined only for the purpose of carrying descriptors.

Figure 13.9. Table hierarchy for the PSIP A65/A.

These sections are packetized and multiplexed in MPEG-2 transport streams. The discovery of PSIP data relies on the use of a base PID, which is an explicitly defined hardcoded value of 0x1FFB, and the Table IDs of these tables are listed in the amended A65/A Table 4.2. The MGT may point to additional PIDs for packets carrying EIT.

13.4.1.1 The System Time Table (STT)

The STT provides time of day information to receivers. In PSIP, time of day is represented as the number of seconds that have elapsed since the beginning of "GPS time," 00:00:00 UTC January 6th, 1980. GPS time is referenced to the Master Clock at the US Naval Observatory and steered to Coordinated Universal Time (UTC). UTC is the time source used to set our clocks.

The cycle of the seasons, technically known as the tropical year, is approximately 365.2422 days. Using the Gregorian calendar adjusts for the fractional day by occasionally adding an extra day to the year. Every fourth year is a leap year, except that three leap years in every 400 are skipped (the centennial years not divisible by 400). With this scheme there are 97 leap years in each 400-year span, yielding an average year that is 365.2425 days long.

UTC is occasionally adjusted by one-second increments to ensure that the difference between a uniform time scale defined by atomic clocks does not differ from the Earth's rotational time by more than 0.9 seconds. The timing of occurrence of these "leap seconds" is determined by careful observations of the Earth's rotation; each is announced months in advance. On the days it is scheduled to occur, the leap second is inserted just following 12:59:59 p.m. UTC.

UTC can be directly computed from the count of GPS seconds since January 6th, 1980 by subtracting from it the count of leap seconds that have occurred since the beginning of GPS time. In the months just following January 1, 1999, this offset was 13 seconds. In the A65 protocol, times of future events (e.g., event start times in the EIT) are specified the same as time of day, as the count of seconds since January 6th, 1980. Converting an event start time to UTC and local time involves the same calculation as the conversion of system time to local time. In both cases, the leap seconds count is subtracted from the count of GPS seconds to derive UTC.

GPS time is also used to represent future times because it allows the receiver to compute the time interval to the future event without regard for the possible leap second that may occur in the meantime.

13.4.1.2 The Master Guide Table (MGT)

The purpose of the MGT is to describe everything about the other tables, listing features such as version numbers, table sizes, and PIDs. Figure 13.10 shows a typical Master Guide Table indicating, in this case, the existence in the transport stream of a VCT, the RRT, four EITs, one ETT for channels, and two ETTs for events. If some region's policy makers decided to use more than one instance of an RRT, the MGT would list each base PID, version number, and size.

Figure 13.10. Example content of the Master Guide Table.

The next entries in the MGT correspond to the four EITs (i.e., EIT-0...EIT-3) delivered in the transport stream. Broadcasters are free to choose their EIT PIDs as long as they are unique in the MGT list of PIDs. After the EITs, the MGT indicates the existence of the ETTs.

Descriptors can be added for each entry as well as for the entire MGT. By using descriptors, future improvements can be incorporated without modifying the basic structure of the MGT. The MGT is like a flag table that continuously informs the decoder about the status of all the other tables (except the STT which has an independent function). The MGT is continuously monitored at the receiver to prepare and anticipate changes in the channel and event structure. When tables are changed at the broadcast side, their version numbers are incremented and the new numbers are listed in the MGT. Based on the version updates and the memory requirements, the decoder can reload the newly defined tables for proper operation.

13.4.1.3 The Virtual Channel Table (VCT)

As opposed to analog TV broadcasts, DTV broadcast identify channels to viewers using major and minor channel numbers . The major channel number is typically associated with selection of a transport stream through tuning. The minor channel numbers are associated with virtual channels selected through demultiplexing the transport selected by the major channel number. However, it is possible for a transport to contain more than one major channel number.

The VCT contains a list of virtual channels carried within a transport stream. For each of these channels, the basic information contained in the VCT table body includes transport stream ID, major and minor channel numbers, short channel name , carrier frequency, program number (used to extract the content for this channel), access controlled flag, location field for extended text messages, and service type marking a distinction between analog, digital audio, digital video and data service broadcasts. Additional information may be carried by descriptors that may be placed in the descriptor loop after the basic information; for example a service_location descriptor is required for every active channel.

The VCT is an MPEG-2 table carried within private sections with table id 0xC8. As such, it has a 5 bit version_number field. It is transmitted periodically, with a maximum cycle time of 400 ms. When a receiver detects a VCT whose version number is different than the previously received VCT, it needs to update its channel binding. As an example, the receiver might be require to extract a different program from the transport than previously extracted. In other words, the response time to configuration changes is of the order of half a second.

For example, Figure 13.11 illustrates a VCT structure that contains the list of channels available in a sample transport stream. For convenience, it is possible to include analog channels and even other digital channels found in different transport streams.

Figure 13.11. Example content of the Virtual Channel Table.

A VCT describes only those channels from a particular transport stream. Therefore, virtual channels added to the VCT at arbitrary times are not detected by the receiver until it is tuned to that particular transport stream. For this reason, channel changes are made in advance to give the receivers the opportunity to scan the frequencies and detect the channel presence.

The major channel number, is used to group all channels that are to be identified as belonging to a particular broadcast corporation (or particular identifying number such as 12 in this case). The minor channel number specifies a particular channel within the group.

The field short name is a seven-character channel name typically used for text-based access and navigation. The transport stream ID and program number are included to link the VCT with the PAT and PMT. The flags following these fields indicate : (a) if the channel is hidden, (b) if the channel has a long text message in the VCT-ETT, and (c) if the channel is visible in general or has some CA constraints. After the flags, appears a description of the type of service is included. Subsequently, is the source id, which is simply an internal index for representing the particular logical channel. The EIT and ETT use this number to provide a list of associated events or text messages respectively.

In normal applications, as in Figure 13.11, all channel information fits into one section. However, there may be rare times when most of the physical channel is used to convey dozens of low-bandwidth services such as audio-only and data channels in addition to one video program. In those cases, the channel information may be larger than the VCT section limit of 1 Kbyte and therefore VCT segmentation is required. In that case, the VCT may be segmented into as many as 256 sections. One section may contain information for several virtual channels, but the information for one virtual channel cannot be segmented and put into two or more sections. The partitioning of the VCT sections should be performed so that the resulting sections are less than 1 Kbyte each.

13.4.1.4 The Event Information Table (EIT)

The EIT contains information for events on defined virtual channels (titles, start times, and so on). Typically, an event is a TV program. Each of the EITs list events for the virtual channels described in the VCT. The EITs are sequentially and chronologically organized from EIT-0 to EIT-127. The first table (EIT-0), corresponds to the currently valid list of events. The second table (EIT-1) corresponds to the next time window, and so on. The EITs rely on, and are synchronized against, the STT.

For example, Figure 13.12 illustrates three events programmed for a 3-hour period for NBZ-S. The event ID field is a number used to identify each event. If an event time period extends over more than one EIT, the same event ID has to be used. Each event is associated with an Extended Text Message (ETM), and each ETT conveys a collection of ETMs. The event ID is used to link events with their messages within in the ETT, and therefore it has to be unique only within a virtual channel and a 3- hour interval defined by EITs. For each event, its start time and length in seconds is specified.

Figure 13.12. Content of EIT for NBZ-S.

The ETM is carried on a private section with table ID 0xCB. During remultiplexing, EIT tables that originally existed in separate transport streams may be multiplexed into a common transport stream or vice versa. For this reason, it is very convenient to synchronize the start times and durations of the EITs. Start times for EITs are restricted to 0:00 (midnight), 3:00, 6:00, 9:00, 12:00 (noon), 15:00, 18:00 and 21:00. All of these times are UTC. EIT-0 lists all of the available events for the current 3-hour time segment. EIT-1 lists all of the available events for the next 3-hour time segment, and likewise, non-overlapping sequential time windows are allocated for all of the other EITs.

For example, a broadcast group operating in the Eastern time zone of the U.S. at 15:30 EDT (19:30 UTC) is required to carry EIT-0 describing events from 14:00 to 17:00 EDT (18:00 to 21:00 in UTC time) plus EIT-1, EIT-2, and EIT-3 covering the next 9-hour interval between 17:00 and 2:00 EDT. At 17:00 EDT, the first table, EIT-0 is obsolete, whereas EIT-1 still valid. At this time, simply by shifting the listed PID values in the MGT, EIT-1 becomes EIT-0 and EIT-2 becomes EIT-1. Updating tables then becomes a process of shifting the list of PIDs in the MGT and their corresponding version numbers.

Up to 128 EITs may be transmitted and each of them is referred to as EIT-k, with k = 0, 1, 127. Each EIT-k can have multiple instances, each of which contains information for one virtual channel. Each EIT-k instance may be segmented into as many as 256 sections. One section may contain information for several events, but the information for one event is not segmented and put into two or more sections. At least the first four EITs are required to be included in the transport stream. Any event programmed for a time interval that extends over one or more EITs are described in each of these EITs, with the same event ID. For instance, an event that starts at 17:30 UTC and lasts until 19:30 UTC appears in two EITs with the same event ID, the EIT covering 15:00 “18:00 (UTC) and the EIT covering 18:00 “21:00 (UTC). For a particular virtual channel, an event ID identifies uniquely each of the events programmed for the 3-hour interval of an EIT.

Events are specified in the order of their starting times, namely the start time of the first event is ahead of that of the second event, and the start time of the last event in section one is equal or less than that of the first event in section two with the equality holding only when both events are the same. Each virtual channel defined in the VCT has a corresponding instance of EIT-k, unless the virtual channel belongs to a group sharing the same source ID; this occurs in applications such as NVOD.

13.4.1.5 The Extended Text Table (ETT)

Optional ETTs contain ETMs providing detailed descriptions of virtual channels (channel ETM) and events (event ETM). An ETM is a multiple string data structure where each string corresponding to a different language. The ETM is carried on a private section with table ID 0xCC. Each description is distinguished by its unique 32-bit ETM ID.

13.4.1.6 The Rating Region Table (RRT)

The RRT defines the rating standard that is applicable for each region or country; typically, its content does not change much over time. Figure 13.13 shows an example of one instance of an RRT, defined as the first rating region and carrying the MPAA standard rating system. Several instances of the RRT can be constructed and carried in the transport stream simultaneously. Each instance is identified by a different table ID extension value and corresponds to a single region.

Figure 13.13. An example content of the RRT.

To allow detections of updates to each RRT instance separately, an RRT instance has a distinct version number which is also carried in the MGT.

13.4.1.7 Directed Channel Change (DCC)

The PSIP standard also includes an amendment that provides new functionality known as DCC. This feature allows broadcasters to tailor programming or advertising based on parameters defined by the viewer such as postal, zip or location code, program identifier, demographic category, and content subject category. Potential applications include customized programming services, commercials based on demographics and localized weather and traffic reports .

13.4.1.8 Tuning and Access

The first step in channel tuning is to extract the VCT from the transport stream that contains the current list of available services (see Figure 13.14). Once the VCT has been collected, a user can tune to any virtual channel present in the transport stream by referring to the major and minor channel numbers. Assuming that in this case, the user selects channel 5.11 (i.e., major channel number is 5 and minor number is 11), the process for decoding the audio and video components is activated. The relationship between the major-minor number and the PIDs of the program elements making up each virtual channel not be changed when the programs (events) change. This enables faster channel changes through use of the last PID selection, with a verification once the identification tables cycle.

Figure 13.14. Tuning and extraction of a VCT from the transport stream.

For terrestrial broadcast, the existence of a service location descriptor in the VCT is mandatory and therefore there is no need to access the PAT or PMT for tuning to the principal television program services. Those features have been included in PSIP to minimize the time required for changing and tuning to channels. However, PAT and PMT information is required to be in the transport stream for MPEG-2 compliance reasons.

Access to data or other supplemental services may require access to or monitoring of the PAT or PMT. Cable systems may choose not to carry the service location descriptor, and therefore the information contained therein (minus the language code) may be found in the PMT.

13.4.1.9 Transport of PSIP

Typically, the MGT, STT, VCT, and each instance of the RRT and EIT has one or at most a few sections (see Figure 13.15). For each table, the sections are appended one after the other, and then segmented into 184-byte segments. After adding the 4-byte header, the 188-byte packets are multiplexed with other components of the transport stream.

Figure 13.15. Packetization and transport of PSIP Tables.

According to ATSC A65/A, typical table sizes are as follows :

• The typical size of the STT is 20 bytes, with the assumption of having no descriptors.

• The typical size of the MGT is 50 bytes plus 22 bytes for each EIT (from 4 to 128).

• The typical size of the VCT is 16 bytes plus 52 bytes for each virtual channel, plus 23 bytes for each digital channel per EIT.

• The typical size of the EIT is 14 bytes plus 42 bytes per event plus 3 bytes for each event-rating pair, plus two bytes for each rating, dimension, and event triplet .

• The typical size of the EIT is 520 bytes.

• The typical size of the RRT is 37 bytes plus 14 bytes per regional rating dimension plus 26 bytes for each dimension-value pair.

13.4.2 Data Broadcast

The ATSC Data Broadcast Standard, A90, defines protocols for data transmission over MPEG transport streams and standardizes signaling and announcement of data services. The A90 standard was ported (by the author of this book) to Cable environments and published as the ANSI/SCTE 80 standard, which adopts A90 and extends it with out-of- band announcement of data services. These standards supports data services that are both TV program related and non-program related. A90 enables enhanced television, Webcasting, and streaming video services. Data broadcasting receivers may include PCs, televisions , set-top boxes, or other devices. The standard provides mechanisms for download of data, delivery of datagrams and streaming data.

13.4.2.1 Signaling and Announcement

Among the many features that iTV Broadcast standards address, two key issues are announcement and signaling.

• Announcement : Announcement is for the benefit of EPGs applications. Whereas PSIP's EIT and ETT tables address the announcement and EPG construction for video (and audio) content, A90's Data Event Table (DET) addresses the announcement of data services such as music downloads of educational iTV applications.

• Signaling : Signaling enables the acquisition of data service resources. According to the MPEG standard, on tuning to a channel, receivers use the PMT to discover which streams (i.e., PIDs) the video and audio streams are carried in. Discovery refers to the task of following the trail of references, through multiple levels of encapsulation (i.e., multiple layers in the onion model), until the data of interest is recovered. With A90, the PMT includes a reference to the streams carrying the data service resources (i.e., files and nonaudio and nonvideo data streams).

13.4.2.2 Merging TV with the Internet

One of the key features of the ATSC A90 can serve as a bridge between broadcast MPEG Audio/Video programming, and an Internet connection (see Figure 13.16). The specification introduces the SDF, which enables the bridging through the introduction of a DST linking with broadcast MPEG transports, side-by-side with an NRT linking with Internet content (see Figure 13.16). Whereas the DST points to a collection of data elementary streams, the NRT points to other types of communications channels, such as a DOCSIS broadcast channel or Internet resources.

Figure 13.16. Datacasting serves as a bridge between MPEG broadcasts and the Internet.

The A90 specification explains how the SDF is used for the discovery of program elements and the binding of applications to these program elements. Additionally, the specification describes the additions to the PSIP that enable announcement using PSIP-like facilities for enhancing EPG with information about features iTV applications.

With ATSC, the primary method for discovering data services is through virtual channels. Using a combination of PSIP VCT and the A90 DST, each virtual channel is associated with data services (see Figure 13.17). Specifically, each virtual channel in the VCT points to a program number, which uniquely identifies a PMT pointing to a single DST stream that constitutes the signaling of the data services for a virtual channel. This implies a model in which each virtual channel is associated with a collection of data elementary streams (see Figure 13.17).

Figure 13.17. Components of a Virtual Channel carrying data services.

13.4.2.3 Broadcasting Non-Streaming Data in the presence of Random Tuning

Whereas streaming content is continuously broadcast, nonstreaming content, such as images and MP3 files, has a short well defined broadcast time interval; for example, a 1 Mbyte file can be broadcast through 384 Kbps within < 21 seconds. Because viewers typically switch channels, they may tune to a channel carrying the nonstreaming content at random time point. Therefore, if a receiver is turned to a channel after the transmission of a file begins, the receiver would not be able to download this file. This problem is referred to as the random tuning problem.

With A90 (and MHP), nonstreaming content can be delivered using data or object carousel encapsulation, which periodically retransmits nonstreaming content. For example, if the data file is re-transmitted every 10 seconds, then the receiver can download the file within at most 10 seconds of tuning to the channel.

13.4.2.4 Service Description Framework (SDF)

A data service is the collection of applications and associated resources signaled in the DST of the SDF. A data service is required to have one program element (data elementary stream) conveying the DST and optionally the NRT. A virtual channel, as described by the PSIP VCT, may include a maximum of a single data service. The minor channel number of a data-only channel ( service_type 0x04 in the VCT) must be in the range 100 “999 . A data service may be composed of any number of program elements and other resources, and the program elements may include any combination of the encapsulation protocols specified in A90.

With A90, the discovery of a data service can be performed either through PSIP or without PSIP: both the VCT and PAT can be used to identify the appropriate PMT. Because it is central to the A90 specification, the detailed specification of DST is presented in Table 13.14.

13.4.2.5 Data Encapsulations

There are multiple ways to encapsulate data within the ATSC Transport multiplex . The mechanisms have different characteristics concerning timing, filtering, overhead, size, and so on. The selection of the appropriate mechanism is based on the specific requirements of the target application (see Table 13.15). The level of detail of the ATSC Data Broadcast Standard varies for the different encapsulation protocols. In the case of the DSM-CC addressable section encapsulation and the Download protocol, the specification is very detailed. In the case of the other protocols, there is significant freedom for implementers to make their own decisions.

Generally, data of any protocol is transmitted in a hierarchy of packetized forms, where each level of the packetization hierarchy comprises data entities that may have different lengths. Transport packets have a fixed length of 188 bytes (184 bytes payload). Data entities of higher complexity, such as MPEG sections and PES packets, are often split at the transmission side and re- assembled at the reception device. For the splitting of the data entities, there are several possible encapsulation mechanisms:

• Data piping : The data piping specification provides minimal information on how to acquire and assemble the data bytes from the MPEG-2 transport stream. It only specifies how to put data into the MPEG-2 transport stream packets.

• Data streaming : The data streaming specification provides additional functionality, especially for timing. It is possible to achieve synchronous data broadcast or synchronized data broadcast. The data streaming specification is based on PES packet.

The key advantage of MPEG-2 PES is the provision of a mechanism to transmit data entities of variable size with a maximum length of 64 kBs. Additionally, it provides the facility to synchronize different data streams accurately (as used in MPEG-2 for synchronization of video and audio). MPEG-2 PES was chosen by A90 for the transmission of all synchronous data streams and for synchronized data streaming.

Table 13.14. The Data Service Table

Field				Value	Description
Data_Service_Table_bytes() {
	sdf_protocol_version			8 uimsbf	This 8-bit field is used to specify the version of the SDF protocol. This field is set to 0x01.
	app_count			8 uimsbf	This 8-bit field specifies the number of applications listed in the DST section.
	for(j = 0; j <app_count; j++) {
		compatibility_descriptor()		*	This structure contains a DSM-CC compatibility descriptor.
		app_id_len		16 uimsbf	This 16-bit field specifies the number of bytes used to identify the application. The value of this field accounts for the length of both the app_id_description field and the app_id_byte fields that follow. The value 0x0000 indicates that no app_id_description field or app_id_byte fields follow. The value 0x0001 is forbidden.
		if(app_id_len > 1) {
			app_id_description	16 uimsbf	This 16-bit field specifies the format and semantics of the following application identification bytes.
			app_id_bytes	app_id_len*8 -16	Represents the data bytes of the application identifier.
		tap_count		8 uimsbf	This 8-bit field specifies the number of Tap() structures used by this application.
		for( i = 0; i <tap_count; i++)
			protocol_encapsulation	8 uimsbf	This 8-bit field specifies the type of protocol encapsulation used to transmit the particular data element referred to by the Tap(). 0x00 Not in an MPEG-2 transport stream 0x01 Async non-flow controlled DSM-CC download. 0x02 Non-streaming Synchronized Download protocol encapsulated in DSM-CC sections 0x03 Asynchronous multiprotocol datagrams in Addressable Sections using LLC/SNAP header 0x04 Async IP datagrams in Addressable Sections 0x05 Synchronized streaming data in PES 0x06 Synchronous streaming data in PES 0x07 Synchronized streaming multiprotocol datagrams in PES using LLC/SNAP header 0x08 Synchronous streaming multiprotocol datagrams in PES using LLC/SNAP header 0x09 Synchronized streaming IP datagrams in PES 0x0A Synchronous streaming IP datagrams in PES 0x0B Proprietary Data Piping 0x0C SCTE 54 asynchronous protocol 0x0D Asynchronous carousel scenario of the DSM-CC Download protocol in DSM-CC sections 0x0E Reserved for compatibility with other standards 0x0F-0x7F ATSC reserved 0x80-0xFF User defined
			action_type	7 uimsbf	This 7-bit field indicates the nature of the data: 0x00 Run-time data 0x01 Bootstrap data 0x02-0x3F ATSC reserved 0x40-0x7F User defined
			resource_location	1 bslbf	This 1-bit field specifies the location of the associationTag field matching the association_tag value listed in the following Tap structure. This bit is set to 0 when the matching association_tag resides in the PMT of the current MPEG-2 program. This bit is set to 1 when the matching associationTag resides in a DSM-CC Resource Descriptor within the NRT.
			Tap()	*	A Tap() is used to find an application-level data element contained in a lower-layer communication channel. An association is made between the application-level data element and the Tap() through the use of an association_tag field. The value of the association_tag field in a Tap structure corresponds to the value of either an association_tag field located in one Association Tag descriptor residing in the current PMT or an associationTag in the dsmccResourceDescriptor descriptors residing in the NRT.
			tap_info_length	16 uimsbf	This 16-bit field specifies the number of bytes of the descriptors following it.
			tap_descriptors	*	Descriptors applicable to the resources referenced by this Tap().
		}
		app_info_length		8 uimsbf	This 8-bit field specifies the number of bytes of the descriptors following it.
		app_info_descriptors		app_info_length*8	The descriptors applicable to the application referenced.
		app_data_length		8 uimsbf	This 16-bit field specifies the length in bytes of the following app_data_bytes field.
		app_data_bytes		app_data_length*8	The application's input parameters and other private data fields associated with the application.
	}
	service_info_length			8 uimsbf	This 16-bit field specifies the length in bytes of the following the service_info_bytes field.
	service_info_bytes			app_data_length*8	MPEG-2 descriptors associated with the entire service rather than with a specific application.
	service_private_data_length			8 uimsbf	This 16-bit field specifies the length in bytes of the following service_private_data_bytes field.
	service_private_data_bytes			app_data_length*8	Private data associated with the entire service rather than with a specific application.

• Private and addressable sections : The ATSC addressable section encapsulation and the ATSC download protocol specifications are built from components of the DSM-CC framework. Addressable sections are used for the carriage of data entities like IP datagrams. These sections are designed to engage the section filtering capability of receivers.

13.4.2.6 Asynchronous Data Elementary Streams

The delivery of asynchronous data elementary streams is not subject to any timing constraints derived from the presence of MPEG-2 Systems time stamps (see encapsulations in Table 13.15). In essence, asynchronous data elementary streams are not time sensitive streams and the bytes of such streams are delivered at a fixed leak rate from a well-defined T-STD buffer model to the data receiver.

13.4.2.7 Synchronous Data Elementary streams

Synchronous data elementary streams are used for applications requiring continuous streaming of data to the receiver at a regular and piece-wise constant data rate (see encapsulations in Table 13.15). Synchronous data is delivered as a stream of 2-byte DAU, each DAU being associated with a precise delivery time derived directly from the PTS field in the PES packet header and a leak rate specified either in the PES packet header or the synchronous data header structure at the beginning of the PES packet payload. The PTS in the headers of PES packets specify the time of presentation of the first synchronous DAU in the PES packet relative to the STC reconstructed from the PCR fields in the ATSC transport stream. The leak rate is then used to infer the delivery time for each of the following synchronous access units within the same PES packet. Delivery of the synchronous DAUs in the next PES packet starts at the time specified by the PTS of that next PES packet. The PCR timestamps may be delivered in the transport packets conveying the synchronous data elementary stream. The delivery of synchronous DAUs is governed by a well-defined T-STD buffer model. The difference between synchronous data and asynchronous data is the fact that synchronous DAUs have been defined for the sole purpose of delivering bytes out of the T-STD buffer model according to a strict timing tied to the receiver's 27 MHz STC.

13.4.2.8 Synchronized Data Elementary Streams

Synchronized data elementary streams are used for applications requiring presentation of data at precise but not necessarily regular instants (see encapsulations in Table 13.15). The presentation times are typically, but not necessarily , relative to the PCR time line carried in the video, audio or data elementary stream. Synchronized data is delivered as a series of DAUs spanning one or several PES packets. The time separating two consecutive synchronized DAUs is arbitrary. A synchronized data elementary stream includes PTSs. The PCR timestamps are typically delivered in the MPEG-2 transport stream packets of a reference elementary stream, but they may be in the same elementary stream as the synchronized data. The purpose of the PTS timestamps is to specify the instant in time, relative to the STC, at which time a DAU are rendered or displayed. The T-STD buffer model for synchronized data elementary streams includes an additional buffer for reassembling data bytes into synchronized DAU. Therefore, as opposed to synchronous DAUs, synchronized DAUs have been defined for the purpose of presenting data at precise times. Also as opposed to synchronous DAUs, consecutive synchronized DAUs may not be of the same size. Consequently, the T-STD buffer model for synchronized data elementary streams goes one step further by providing a buffer for collecting data bytes pertaining to a DAU before it is decoded and presented at a precise instant of the receiver STC.

Table 13.15. Encapsulation Protocol Applicability Matrix

	Bounded	Streaming	IP Datagrams
Asynchronous	Asynchronous Data Download protocol	Asynchronous Data StreamingProtocol	DSM-CC Addressable Sections
Synchronous		Synchronous Data Streaming protocol	Synchronous Data Streaming protocol
Synchronized	Synchronized Data Download protocol	Synchronized Data Streaming protocol	Synchronized Data Streaming protocol

13.4.2.9 Data Blobs and Files

A data blob or a data module could be a representation of a file, a group of files, a directory of files, a group of directories containing files, a module, a hierarchy of modules, an object, a group of objects, or a bounded data entity with boundaries that are known to the content author.

Data modules that are to be repetitively delivered should use the data carousel option of the asynchronous Download protocol. Otherwise , the non-flow controlled scenario of the Download protocol should be used. Synchronized data modules should be delivered using the synchronized Download protocol.

13.4.2.10 Network Datagrams

Network datagrams, for example IP datagrams or Internetwork Packet eXchange (IPX) datagrams, and broadcast IP multicast with SDP sessions can be encapsulated in various manners. As an example, broadcast IP multicast with SDP sessions is neither unidirectional nor bi-directional Multicast (see ATSC A92 and SCTE 42); the SDP (as opposed to the Media Access Control (MAC) address) is used for the discovery of the IP address of the data streams.

The different encapsulation methods are intended to meet specific needs of different applications. DSM-CC addressable sections are the method of delivery for asynchronous network datagrams. Datagrams that do not have any timing or synchronization requirements associated with them should be delivered using the DSM-CC addressable sections encapsulation. For example, this method of delivery would be useful for delivering Web-pages, providing turbo-Internet service, or delivering ATVEF content. Datagrams that are synchronized to a program using a PTS are conveyed in the synchronized streaming protocol. Synchronous datagrams are carried using the synchronous streaming protocol.

13.4.3 DTV Application Software Environment (DASE)

The ATSC DASE is the North American counterpart of the DVB-MHP standard [DTV]. It defines a middleware layer that allows programming content and applications to run on a common receiver. Interactive and enhanced applications need access to common receiver features in a platform-independent manner. This environment provides enhanced and interactive content producers with the specifications necessary to ensure that their applications execute uniformly (or otherwise exhibit predictable behavior) on all brands and models of receivers that are compliant with the standard. Manufacturers thus are able to choose hardware platforms and operating systems for receivers, but provide the commonality necessary to support applications made by many content producers .

This section focuses on some significant differences between MHP and DASE. The detailed DASE specification is available online at the ATSC Web-site. The DASE standard comprises the following parts :

• Part 1 : Introduction, Architecture, and Common Facilities

• Part 2 : Declarative Applications and Environment

• Part 3 : Procedural Applications and Environment

• Part 4 : Application Programming Interface

• Part 5 : ZIP Archive Resource Format

• Part 6 : Security

• Part 7 : Application Delivery System ”ARM Binding

• Part 8 : Conformance

13.4.3.1 Architecture

DASE applications are classified into two categories, declarative and procedural applications, distinguished by the MIME content type of their initial file (or entry point). An example of a declarative application is a multimedia document composed of XHTML markup, style rules, scripts, embedded Java TV Xlets (using the <object/> element) and embedded graphics, video, and audio. Instead of XHTML, DASE introduces the eXtensible DTV Markup Language (XDML). An example of a procedural application is a Java TV Xlet composed of compiled Java byte code in conjunction with other multimedia content such as graphics, video, and audio; that Xlet may utilize a library of XHTML components to render markup content.

Application environments are similarly classified into the two categories declarative and procedural application environments (see Figure 13.18). An example of a declarative application environment is a multimedia document (XDML) browser. An example of a procedural application environment is a JVM and its associated API implementation.

• Declarative application environment : A DASE declarative application environment (DAE) is a logical subsystem of the DASE system that processes markup, stylesheet, and script content. A key component of the declarative application environment is the declarative content decoding engine in the form of an XDML parser and a stylesheet and script interpreter.

• Procedural application environment : A DASE procedural application environment (PAE) is a logical subsystem of the DASE system that processes active object content. A key component of the procedural application environment is the procedural content execution engine, which takes the form of a JVM which is a part of the PAE. Java APIs provide procedural applications with access to the receiver's functions.

Figure 13.18. DASE Architecture.

13.4.3.2 Announcement

The future availability of an application for possible processing and presentation by an application environment should be announced by an application delivery system. The intention of application announcement is to notify a viewer of the future availability of the application so that the viewer can take appropriate action to schedule use of the application. This announcement may be accompanied using the following meta-data:

• Application identifier : A UUID;

• Application name : A short name which could be used within a menu;

• Application description : A short paragraph describing the application;

• Application level : The Level of DASE (a concept similar to MPEG levels);

• Application availability : Time and Duration: this is the programming time slot;

• Application rating information : Similar to the audio/video rating system;

• Application languages : Similar to the audio and video language specifications.

13.4.3.3 Signaling

The signaling of applications indicating their current availability (or imminent arrival) for processing and presentation is signaled by means of the ATSC A90 Data Broadcast Standard. The signaling of an application is accompanied by an application meta-data resource that describes the application as a whole as well as the application's resources (e.g., XHTML files, class files, image files, etc.). This meta-data resource specifies the following information, that should match the announcement transmitted independently:

• Application Identifier : A UUID;

• Application Level : The Level of DASE (a concept similar to MPEG levels);

• Application Initial Entity Resource Identifier : The URI of the application's entry point.

Although each data service may have a single autostart application, there may be multiple application that do not start on reception. Receivers are free to develop whatever user interface is appropriate for assembling menus , that are populated based on the content of the data service and used to launch any non-autostart application.

13.4.3.4 Security Signaling

The signaling of an application may be accompanied by application meta-data that describes the application permission entity resource identifier, which is a reference to a file containing all the security settings for that application, and the application parameters service a role that is similar to command-line parameters or parameters submitted via a URL to a server side script application. Signaling meta-data is not expected to be presented to a viewer; instead, it is expected to be consumed by receivers and other broadcasting equipment.

13.4.3.5 Resources and Their Identifiers

Applications are composed of files and streams, collectively referred to as application resources, each of which consist of an identifier (which is a URI), content type (which is a MIME type) and the actual content data. Additional optional information associated with a resource includes cache directives and last modified time.

Resource identifiers may have three possible prefixes indicating their types: archive: , lid: and tv: The archive: type enables pointing directly to resources within archived. The lid: type points to a resource available in the transport and the tv: points to a virtual channel.

The archive identifier, based on a similar identifier used in Java, uses a the following syntax which departs from the MHP specification:

 archive_URI : "archive:" restricted_URI "!" abs_path [ "#" fragment ] 

The token restricted_URI is subject to the following constraints (after un-escaping):

• It adheres to the syntax prescribed by RFC 2396;

• It does not take the form of an archive identifier (i.e., prevent recursive references);

• It does not contain a query or fragment component, and

• It does not contain the "!" character.

If restricted_URI takes the form of a relative URI, then the absolutized form of this URI also adhere to these restrictions.

The semantics of resolving an archive identifier are as follows: (a) resolve restricted_URI to a resource of an archive content type, (b) resolve abs_path to an entry within the archive resource, and (c) if fragment is specified, resolve to the referenced fragment within the archive entry. For example, the following identifier uses an embedded absolute identifier to reference the archive resource: archive:lid://xyz.com/app/app.zip!/top/doc.xml#gohere . The following specifies an example of an archive identifier used to reference a Java class file within a JAR archive: archive:app.jar!/com/xyz/MyXlet.class . This identifier uses an embedded relative identifier to reference the archive resource.

13.4.3.6 Application Lifecycle

The DASE application lifecycle specification is defined in terms of states and events that cause transitions between them.

Events

The application's lifecycle is affected by the events of activate, initialize, suspend, resume or terminate, each of which can be generated by the application, the execution environment or the transport. The application generates an event using the API. The execution environment generates events, typically on behalf of viewers, using common operating-system techniques. Transport events are generated by modifying the content of the DST or the NRT; these events are specified by the ATSC A94 Application Reference Model (ARM).

• Initialize Event : This event is generated by the transport decoder when it discovers changes in the DST, or by the DASE system, on behalf of the viewer, in response to an application load request. An application load request is generated internally within a DAE as a side effect of certain operations that cause an application to be replaced by a new application.

• Activate Event : This event is generated by the DASE system in response to successful application initialization. No mechanism is provided for an application to activate itself.

• Suspend Event : A suspend event may be generated by the transport decoder when it discovers changes in the DST, or by the DASE system in response to an implementation dependent request. No mechanism is provided for an application to suspend itself.

• Resume Event : A resume event may be generated by the transport decoder when it discovers changes in the DST, or by the DASE system in response to an implementation dependent request. No mechanism is provided for an application to resume itself.

• Terminate Event : A terminate event may be generated by the transport decoder when it discovers changes in the DST, or by the DASE system in response to an application initiated request (using the API), an abort condition, or an implementation dependent condition. The process of generating a terminate event is also referred to as aborting an application.

States

A DASE application may be in one of four possible lifecycle states: active, initialized , suspended and uninitialized . This state is not directly exposed to an application, but can be inferred through events dispatched to the application or actions performed on the application by the DASE system. An application's lifecycle state is affected by the events described earlier; by the state of the delivery system and the state of the application environment.

• Initialized state : An application is transitioned from the uninitialized state to the initialized state on receipt of an initialize event (generated in response to an application load request) and the subsequent successful decoding of its meta-data content file (see Example 13.2) as well as its initial JavaTV class file implementing the Xlet interface or its initial XDML file. This transition is referred to as application initialization. While in the initialized state, an application may consume any environment resource other than an application instantiated thread. Only one DASE application may be in the initialized state at a given time within a DASE system.

• Active state : An application is transitioned from the initialized state to the active state on the successful decoding of its initial entity. This transition is referred to as application activation. An application is transitioned from the suspended state to the active state on the resumption (activation) of any application-defined thread. This transition is referred to as application resumption. While in the active state, an application may consume any environment resource. Only one DASE application may be in the active state at a given time within a DASE system.

• Suspended state : An application is transitioned from the active state to the suspended state on the receipt of a suspend event and the subsequent successful suspension of all application instantiated threads. This transition is referred to as application suspension. While in the suspended state, an application releases all exclusive environment resources and suspends all application instantiated threads. Multiple DASE applications may be in the suspended state at a given time within a DASE system. If a DASE system does not have sufficient resources to maintain a DASE application in a suspended state, it may cause the suspended application to transition to the uninitialized state.

• Uninitialized state : An application begins and ends its lifecycle in the uninitialized state. If an application is not in an active, suspended or initialized state, then it is in the uninitialized state.

Any transition to the uninitialized state is referred to as application termination. While in the uninitialized state, an application does not consume any environment resource. A DASE system may consume cache resources to retain an application's resources while it is in an uninitialized state. The determination of whether or not to cache an uninitialized application's resources is not defined by the DASE specification. Multiple DASE applications may be in the uninitialized state at a given time within a DASE system.

A transition from initialized to uninitialized occurs in the following situations:

• on a failure to decode the application's initial entity;

• when an uncaught exception occurs during the execution of the initial entity, or

• on the receipt of a terminate event.

An application transitions from the active state to the uninitialized state on an occurrence of an uncaught exception during the processing of an application entity or the receipt of a terminate event. An application transitions from the suspended state to the uninitialized state on the receipt of a terminate event.

13.4.3.7 Content Types Supported

DASE requires support for Java class files as well as the XDML format (a variation of XHTML). Each of these two formats is used to encode and deliver application code. DASE requires support for the following content type categories: application meta-data content, graphics content, nonstreaming video content, nonstreaming audio content, streaming video content, streaming audio content, font content, archive content, and trigger content.

With the exception of the application meta-data content and the trigger content, DASE does not depart significantly from MHP. The application meta-data resource is an ATSC-specific format (see Example 13.2) that is part of the application signaling (Section 13.4.3.3). The trigger content (see Example 13.1) is an ATSC-specific format used to enable broadcasters to pass-through (rather than intercept) triggers that applications could consume (in contrast to triggers used by broadcasters to control applications, which are transmitted in the DST).

Example 13.1 Trigger Content.

  <?xml version="1.0" encoding="UTF-8" standalone="no"?>   <!DOCTYPE trigger PUBLIC "-//ATSC//DTD DASE Trigger 1.0//EN" "">   <trigger>   <event type="script" target="lid://fbs.com/app.xml#t1">   <param name="code" value="fire(1)"/>   </event>   <event type="script" target="lid://fbs.com/app.xml#t2">   <param name="code" value="fire(2)"/>   </event>   </trigger>  

Example 13.2 An Application Meta-data Resource.

  <?xml version="1.0" encoding="UTF-8" standalone="no"?>   <!DOCTYPE application PUBLIC "-//ATSC//DTD DASE 1.0//EN" "">   <application>   <identifier uuid="7cd89e0a-ad29-4145-8b31-013635801f8d"/>   <entityset>   <entity entitytype="initial" uri="app.xml"/>   <entity entitytype="permissionRequest" uri="prm.xml"/>   </entityset>   <descset xml:lang="en">   <name>my declarative application</name>   <desc>my application is an example dase-1 declarative application.</desc>   </descset>   <condset>   <cond qualifier="require" capability="system">   <param name="level"   value="1"/>   </cond>   <cond qualifier="require" capability="graphics">   <param name="widthpx" value="640"/>   <param name="heightpx" value="480"/>   <param name="samplebitsr" value="2"/>   <param name="samplebitsg" value="3"/>   <param name="samplebitsb" value="2"/>   <param name="samplebitsa" value="1"/>   </cond>   <cond qualifier="request" capability="cache">   <param name="minsize" value="2m"/>   </cond>   <cond qualifier="request" capability="memory">   <param name="initial" value="1m"/>   </cond>   <cond qualifier="request" capability="graphics">   <param name="widthpx" value="960"/>   <param name="heightpx" value="540"/>   <param name="samplebitsr" value="4"/>   <param name="samplebitsg" value="4"/>   <param name="samplebitsb" value="4"/>   <param name="samplebitsa" value="4"/>   </cond>   </condset>   <cacheset>   <cache target="-" directives="no-cache"/>   <cache target="images/splash.jpg" directives="preload"/>   </cacheset>   </application>