Revert to Section 4.1

The fixed length packetization approach offers flexibility and some additional advantages when attempting to multiplex data related to several applications into a single bit steam.

While digital systems are generally described as flexible, the use of fixed length packets offers a high level of flexibility to allocate channel capacity among video, audio and auxiliary data services. The use of a packet identification field (PID) in the packet header as a means of bit stream identification makes it possible to have a mix of video, audio and ancillary data which is flexible and which need not be specified in advance. The entire channel capacity can be reallocated to meet immediate service needs including allocation of the entire bit stream for delivery of data services. This concept is termed dynamic capacity allocation.

The ability to dynamically allocate system capacity may be exploited to allow additional elementary bit streams to be added at the input of the multiplexer or to allow these elementary bit streams to be multiplexed at a second stage with the original bit stream. The presence of multiple elementary bit streams in the data channel allows the system to be scalable.

The DTTB system was developed with the understanding that there would be future services that could not be anticipated at the introduction of the service. It was, therefore, extremely important that the transport architecture be open-ended. New elementary bit streams could be handled at the transport layer without hardware modifications, by assigning new PIDs at the transmitter and filtering out these new PIDs in the bit stream at the receiver. Backward compatibility was assured when new bit streams were introduced into the transport system since existing decoders would automatically ignore new PIDs. This capability could possibly be used to compatibly introduce newer, higher temporal or spatial resolution services or stereoscopic services by sending augmentation data along with the normal television service data. The presence of multiple elementary bit streams in the data channel and provision for identification of, yet unidentified, future services allows the system to be extensible.

Another fundamental advantage of the fixed length packetization approach is that the fixed length packet can form the basis for handling errors that occur during transmission. Error correction and detection processing (which precedes packet demultiplexing in the receiver subsystem) may be synchronized to the packet structure so that one deals in the decoder at the packet level when handling data loss due to transmission impairments. Essentially, after detecting errors during transmission, one recovers the data bit stream from the first good packet. Recovery of synchronization within each application is also aided by the transport packet header information. Without this approach, recovery of synchronization in the bit streams would be completely dependent on the properties of each elementary bit steam. The presence of fixed length packets improves the system's robustness.

A fixed-length packet based transport system enables simple decoder bit stream demultiplex architectures suitable for high speed implementations. The decoder does not need detailed knowledge of the multiplexing strategy or the source bit-rate characteristics to extract individual elementary bit streams at the demultiplexer. All the receiver requires is the identity of the packets. The necessary information is transmitted in each packet header at fixed and known locations in the bit stream. The only important timing information is related to bit level and packet level synchronization.

The transport resides between the application (e.g. audio, video, or data) encoding/decoding function and the transmission subsystems. At its lowest layer, the encoder transport subsystem is responsible for formatting the encoded bits and multiplexing the different components of the program for transmission. At the receiver, the decoder transport subsystem is responsible for recovering the bit streams for the individual application decoders and for the corresponding error signalling. (At a higher layer, multiplexing and demultiplexing of multiple programs within a single bit stream can be achieved with an additional system level multiplexing or demultiplexing stage before or after the modem in the transmitter or the receiver.) The transport subsystem also incorporates other higher level functionality related to identification of applications and synchronization of the receiver.

A data transport mechanism based on the use fixed length packets that are identified by headers allows for the identification of a particular application bit-stream (also called an elementary bit steam) which forms the payload of the packets. Applications that can be supported include video, audio, data, program and system control information. The elementary bit streams for video and audio can themselves be wrapped in the PES variable length packet structure before transport processing. The PES layer provides functionality for identification, synchronization of decoding, and presentation of the individual application.

Elementary bit steams sharing a common time base can then be multiplexed, along with a control data stream, into programs. These programs and an overall system control data stream are then asynchronously multiplexed to form the system bit stream. Programs in this system are analogous to today's conventional broadcast channels. Using this approach, the transport is made flexible in two ways:

1. It permits defining programs as any combination of elementary bit streams. For example the same elementary bit stream could be present in more than one program (e.g. two bit streams with the same audio), a program could be formed by combining a basic elementary bit stream and a supplementary elementary bit stream (i.e. bit streams for scalable decoders), programs could be tailored for specific needs (e.g. regional selection of language) etc.
2. Flexibility at the systems layer allows different programs to be multiplexed into the system as desired, and allows the system to be reconfigured easily when required. The procedure for extraction of programs from within a system is also simple and well defined.

This approach provides other features that are useful for both normal decoder operation and for the special features required in broadcast and cable applications. These include:

1. Decoder synchronization,
2. Conditional access,
3. Local program insertion,

amongst others.

This approach to a bit stream configuration directly addresses issues related to the storage and playback of programs. Although this is not directly related to the DTTB transmission problem, the ability to create programs in advance, store them as a compressed multiplexed bit stream and play them back at the desired time is a desirable feature. The most efficient means of storing programs is in the same format in which they are transmitted, as transport bit streams. The preferred implementation should provide "hooks" to support consumer digital products based on recording and playback of these bit streams, including the use of "trick modes" that are available on current analogue VCRs. It should be noted that the issues related to storage and play back of digitally compressed video bit streams are quite different from those that need to be considered for conventional analogue television systems.

It is desirable that the DTTB transport bit stream be easily carried on other communication systems, and that the DTTB transport bit stream be capable of carrying bit streams generated by other communication systems.

The overall multiplexing approach can be described as a combination of multiplexing at two different layers. In the first layer one forms program transport streams by multiplexing one or more elementary bit streams at the transport layer, and in the second layer the program transport streams are combined (using asynchronous packet multiplexing) to form the overall system. The functional layer in the system that contains both this program and system level information is called PSI or Program Specific Information. This example represents one way of constructing the system, but it is not the only way, and for some architectures, it may not represent the preferred way.

figure 27

A program transport bit stream can be formed by multiplexing individual transport packetised elementary bit streams (with or without PES packetization) sharing a common time-base, and a control bit stream that describes the program. Each elementary bit stream, and the control bit stream (also called the elementary stream map) are identified by their unique PIDs in the link header field. The organization of this multiplex function is illustrated in Fig. 27. The control bit stream contains the program_map_table that describes the elementary stream map. The program_map_table includes information about the PIDs of the transport streams that make up the program, the identification of the applications that are being transmitted on these bit streams, the relationship between these bit streams, etc.

The transport syntax allows a program to be comprised of a large number of elementary bit streams, with no restriction on the types of applications required within a program. A program transport stream does not need to contain compressed video or audio bit streams. It could contain multiple audio bit streams for a given video bit stream. The data applications that can be carried are flexible, the only constraint being that there should be an appropriate stream_type ID assignment for recognition by a compatible decoder of the application corresponding to the bit stream.

Note that many of the link level functions are carried out independently, without program level coordination for the different elementary bit streams that make up a program. This includes functions such as PID manipulation, bit stream filtering, scrambling and descrambling, definition of random entry packets, etc. The coordination between the elements of a program is primarily controlled at the presentation (display) stage based on the use of the common time base. This common time base is set up by the fact that all elementary bit streams in a program derive timing information from a single clock, the information for which is transmitted via the PCR (program clock reference) on one of the elementary bit streams that constitute the program. The data for timing of presentation is present in the elementary bit streams for individual applications.

figure 28

The system multiplex allows multiplexing of different program transport streams. In addition to the transport bit streams (with their corresponding PIDs) that define the individual programs, a system level control bit stream with PID=0 is defined. This bit stream carries the program_association_table that maps program identities to their program transport streams. The program identity is represented by a number in the program_association_table. A program corresponds to what is traditionally called a channel in conventional television systems. The map indicates the PID of the bit stream containing the program_map_table for a program. Thus, the process of identifying a program and its contents takes place in two stages: first one uses the program_association_table in the PID = 0 bit steam carrying the program_map_table for the program, and in the next stage one obtains the PIDs of the elementary bit streams that make up the program from the appropriate program_map_table. Once this step is completed, the filters at a demultiplexer can be set to receive the transport bit streams that correspond to the program of interest.

The system layer of multiplexing is shown in Fig. 28. During the process of system level multiplexing, there is the possibility of receiving identical PIDs on different program streams. This poses a problem since PIDs for different bit streams need to be unique. One solution would be to modify the PIDs just before the multiplexing stage. The changes need to be recorded in both the program_association_table and the program_map_table. Hardware implementation of the PID reassignment function in real time is helped by the fact that this process is synchronous at the packet clock rate.

figure 29

This process can be made scalable by multiplexing multiple system level bit streams on a higher bandwidth channel by extracting the program_association_tables from each system multiplexed bit stream and reconstructing a new PID=0 bit stream.

Figure 29 illustrates one possible implementation approach to extracting elementary bit streams for a program at a receiver, although not necessarily the most efficient approach. In practice the same demultiplexer hardware could be used to extract both the program_association_table and the program_map_table control bit streams. This also represents the minimum functionality required at the transport layer to extract any application bit stream (including those that may be private). Figure 30 shows an example of data access flow in the receiver in a different fashion.

It is important to clarify here that the layered approach to defining the multiplexing function does not necessarily imply that program and system multiplexing should always be implemented in separate stages. A hardware implementation that includes both the program and system level multiplexing within a single multiplexer stage can be considered as long as the multiplexed output bit stream has the desired properties.

Continue to Section 4.4

Return to DTTB Tutorial Table Of Contents

Return to Tutorial Index Page