Unlike NTSC VBI-based data services, DTV data services are an integral part of the broadcast signal. DTV data shares the same multiplex with the video and audio, and DTV uses the same fundamental MPEG-2 acquisition mechanisms to acquire data, video and audio signals. It also allows data services such as video/audio programming to be announced in a program guide.
This composite photo gives an example of the on-screen information made possible by the data broadcasting system. Photo courtesy Triveni Digital.
The ATSC data broadcast standard, described in ATSC document A/90, specifies the following key elements:
- Data services announcement
- Data delivery models
- Application signaling
- MPEG-2 systems tools
- Protocols
The data broadcast standard can be used for a number of applications, including:
- Delivering declarative data such as HTML code
- Delivering procedural data such as Java code
- Delivering software, images and graphics
- MPEG-4 or H.263 video streams, and MPEG-4 audio streams
- Carouselling MPEG-2 video files
- Carouselling MP3 audio files
Figure 1 shows the ATSC data broadcast system. The standard covers the delivery of data from the last part of the distribution chain (multiplexer/emission transmitter) to a receiver.
Figure 1. This diagram illustrates the overall structure of the ATSC data broadcast standard.
The data broadcast system
The ATSC data broadcast standard assumes that receivers vary greatly in the number of services they can present and in their ability to store data or process that data in some meaningful way. Some receivers may decode and present several audio/video broadcasts along with multiple data services. Others may perform a single function (such as delivering a stock ticker) as inexpensively as possible.
The A/90 standard supports the carriage of data objects using the non-flow-controlled scenario and the data-carousel scenario of the digital-storage-media command and control (DSM-CC) user-to-network download protocol. ATSC use of the DSM-CC download protocol supports the transmission of the following elements:
- Asynchronous data modules
- Asynchronous data streaming
- Non-streaming synchronized data
The protocol can detect transmission errors in the data it carries, since the DSM-CC sections employed include a CRC/checksum field for that purpose.
The data carousel sends (and repeats) data at intervals to obviate a flow-control system, as well as repetitions for error protection. Figure 2 illustrates the headend infrastructure.
Figure 2. This figure illustrates the headend infrastructure of the data carousel server.
The non-flow-control scenario embodies the unidirectional, one-time transmission of a bounded data image to a data receiver. The data carousel cyclically repeats the contents of the carousel one or more times. If a data decoder wants to access a particular module from the data carousel, it can simply wait for the next time that the data for the requested module is broadcast. Figure 3 illustrates a data-carousel implementation of the download protocol.
The A/90 standard defines transmission of datagrams (such as IP) in the payload of MPEG-2 transport stream (TS) packets by encapsulating the datagrams in DSM-CC addressable sections. This mechanism is used to asynchronously deliver datagrams having the following characteristics:
- No MPEG-2 systems timing is associated with the delivery of data.
- The smoothing buffer can go empty for indeterminate periods of time.
The A/90 standard supports synchronous and synchronized data streaming using the packetized elementary stream (PES). Synchronous data streaming is defined as the streaming of data with timing requirements in the sense that the data and clock can be regenerated at the receiver into a synchronous data stream. Synchronous data streams have no strong timing association with other data streams and are carried in PES packets.
Figure 3. In the data-carousel scenario of the DSM-CC download protocol, information is repeated cyclically so that a data decoder has several opportunities to obtain the data requested.
Synchronized data streaming implies a strong timing association between PES streams referenced by different packet identifiers (PIDs). PES packets carry synchronized streaming data. An example is application data associated with time instances in a video stream. The standard defines data piping as a mechanism to deliver arbitrary, user-defined data inside an MPEG-2 TS. Data piping inserts data directly into the payload of MPEG-2 TS packets. The standard does not specify methods for fragmentation or reassembly of data sent in this manner.
A data service, as defined in document A/90, is a collection of one or more data broadcast types. For example, a data service may include streaming synchronized data and asynchronous multiprotocol encapsulated data.
Operational details
The basis of the data broadcast standard is formed by the MPEG-2 transport stream as defined in ISO/IEC 13818-1 (MPEG-2 systems) and Amendments 1 and 2 specifying registration procedures for the copyright identifier and the format identifier, respectively. Figure 4 identifies what is standardized and by which body, specifically:
- ISO has standardized the MPEG-2 TS in ISO/IEC 13818-1 and the DSM-CC framework in ISO/IEC 13818-6.
- IETF has standardized the Internet Protocol (IP) in RFC 791.
ATSC has specified within the data broadcast standard the ATSC data-piping protocol, the data-streaming encapsulation, the DSM-CC addressable-section encapsulation, and the download protocol.
Within Figure 4, the encapsulation of IP is just an example. Other network protocols can also be encapsulated.
Figure 4. The data broadcast standard specifies different encapsulation protocols for different application areas. The figure also shows the relation.
As shown, the data broadcast standard specifies different encapsulation protocols for different application areas.
As specified in the data broadcast standard, each data service may be composed of one or more applications integrated to the remaining ATSC infrastructure by means of announcement, discovery and binding functions. The announcement and discovery specification is part of the A/65 standard (Program and System Information Protocol), along with additional elements documented in A/90. Additionally, further discovery definition and application binding are part of the service description framework (SDF) that is described in A/90. Figure 5 illustrates the packetization, synchronization and protection layers of the ATSC data broadcast protocols.
PSIP and SDF for data broadcasting
The PSIP and SDF are integral elements of the data broadcasting system. These structures provide two main functions:
- Announcement of the available services
- Detailed instructions for assembling all the components of the data services as they are delivered
Figure 5. The ATSC data broadcast protocol contains packetization, synchronization and protection layers.
Generally, data of any protocol type is divided and subdivided into packets before transmission. PES packets are up to 64kB long, sections are up to 4kB, and transport-stream packets are 188 bytes. Protocol standards document the rules for this orderly subdivision (and reassembly). All information is transmitted in 188-byte TS packets. The receiver sees the packets and, by using the PlD in the header of each packet, routes each packet to the appropriate location within the receiver so that the information can be recovered by reversing the subdivision process.
A data service can be announced in either an event-information table (EIT) or a data-event table (DET) in conjunction with additional entries in the virtual-channel table (VCT) of the PSIP standard. These tables use the MPEG section structure. Single data services associated with a video program are announced in the EIT.
The DET is used to support direct announcement of data services that are either stand-alone or are associated with a video program, but start and stop at different times within that program. Like the EIT, there are four required DETs that are used for separately announced data services. DETs contain the start time and duration of each event, the data-ID number, and a data-broadcast descriptor. This descriptor contains information about the type of service profile, the necessary buffer sizes and synchronization information.
There are three profiles for services that need constant or guaranteed delivery rates:
- G1—up to 384kb/s
- G2—up to 3.84Mb/s
- G3—up to the full 19.4Mb/s transport stream
While the instantaneous bandwidth required to carry the video program will vary, the bandwidth of the transport pipe is constant. Rather than transmit null packets, opportunistic data packets may be sent instead. For services that are delivered opportunistically, at up to the full transport data rate, the profile is called A1. Figure 6 illustrates the concept of opportunistic bandwidth for transmitting data.
The VCT contains the virtual channel information for each data service. The ATSC PSIP data service is intended to facilitate human interaction through a program guide that contains a linkage to the service-description framework (SDF), which provides the actual road map for reassembly of the fragmented information. The process of following this roadmap is known as discovery and binding. The SDF information is part of the bandwidth of the data service, not part of the broadcaster’s overhead bandwidth (PSIP is in the overhead).
Figure 6. Video programs do not always take the full bandwidth of the transport pipe. In these cases, opportunistic data packets can be sent rather than transmit null packets.
The SDF contains two distinct structures, the data-services table (DST) and the network-resources table (NRT). (Each use MPEG-2 private sections.) The MPEG-2 transport-stream packets conveying the DST and the NRT for each data service are referenced by the same PID, which is different from the PID value used for the SDF of any other data service. The DST provides the information necessary to bind components within the current transport stream, while the NRT provides the information for components in other locations (including the Internet). The DST must be sent at least once during the delivery of the data service. Key elements in the DST include the following:
A descriptor defining compatibility and the requirements of an application
- The name of the application
- Method of data encapsulation
- List of author-created associations and application data structure parameters
- Association tags, which allow binding to MPEG-2 program elements carrying data components
Some services will not need the NRT because it contains information to link to data services outside the TS.
New services and capabilities
The ATSC data broadcast standard provides a rich set of protocols and functionalities that allow progressive deployment of increasingly sophisticated services. The A/90 standard specifies delivery of data for broadcast and pseudo-interactive services and, at the same time, lays the ground for interactive services. As with other ATSC standards, harmonization of the data broadcast standard with DVB and cable efforts has been a high priority.
All of the elements are now in place to make DTV data broadcasting a reality. A number of possible commercial applications have been proposed, and more will emerge as broadcasters learn by doing. One thing is certain: Data broadcasting will be an integral part of the television station of the future.
Richard Chernock, Ph.D., is a senior member of the technical staff at Triveni Digital. Jerry Whitaker is technical director of the ATSC.
