Mobile DTV
Oct 1, 2008 12:00 PM, By Jay C. Adrick and Wayne E. Bretl
Find out how to integrate ATSC M/H technology into your station.
The U.S. television broadcast world will undergo major changes in the months ahead with the end of analog broadcasting and the beginning of mobile DTV service by some broadcasters. The industry has been abuzz for the past year, with demonstrations of mobile technology from several companies. The ATSC Technical Standards Group (TSG) has been busy, along with the Open Mobile Video Coalition (OMVC), with the selection of technology and documentation leading up to an ATSC Mobile/Handheld (M/H) standard.
Frame Grab: Number of homes with an HDTV set up 8 percent
Click to enlarge
Several years ago, broadcasters and equipment manufacturers began to realize that over-the-air broadcast television would soon see competition from new players who wanted to reach an ever-growing audience of on-the-go viewers. The competition was coming from companies that planned to use the 700MHz spectrum that was recently auctioned off by the FCC and from 3G wireless operators. Broadcasters realized that they needed to compete, but there was one problem: The ATSC DTV system was not designed to reach mobile devices.
In the mid-1990s, when the ATSC DTV system was developed, the main focus was to achieve as much digital payload as possible within the 6MHz of allotted RF spectrum. This was necessary to allow for the then-nascent MPEG-2 HDTV encoding. As technology advanced, the bit rate necessary for HD encoding decreased, allowing broadcasters to dedicate bits for additional services, such as multichannel or mobile.
ATSC-M/H technology overview
The ATSC-M/H system is based on technology developed by Harris, LG and Zenith in their MPH system, blended with some parts of the A-VSB technology developed by Samsung. The system technology is made up of three layers of activity:
-
the physical layer, which is all about getting the bits from the station to the handheld and mobile receiving devices;
-
the management layer, which includes signaling and announcement information on services, conditional-access system (CAS) information, digital rights management and electronic service guide (ESG) information; and
-
the presentation layer, which includes audio and video encoding, closed captioning and interactive applications.
The mobile services are based on IP transport rather than legacy MPEG. However, the transport of the M/H data from the integration point with the conventional ATSC signal to the transmitter exciter requires that the IP datagrams be encapsulated into the MPEG-2 transport. The IP-based transport methodology allows for an easy integration of both real-time and non-real-time services. It also offers support of multiple program streams in each M/H channel or “parade.”
The magic is in the physical layer
Each M/H channel can typically carry about 600Kb/s of payload. Depending on the level of robustness selected by the system operator, each M/H channel will occupy about 2Mb/s of the main ATSC stream due to the additional channel processing required to make the mobile data withstand the rigors and impairments found in mobile reception.
Figure 1. During precoding, M/H data and its code bytes are packaged into ATSC data packets. These packets are then processed in the usual legacy process, which changes the solid block of M/H data to a sawtooth-shape region for transmission.
Program content is encoded using H.264 v1.3 for video and HE-AAC for audio. Video resolution is scalable up to 416 × 240 supporting 16:9 aspect ratio presentations, and the audio is stereo with future capability for surround. All real-time streams are encapsulated using RTP/RTCP, while non-real-time content is encapsulated using File Delivery over Unidirectional Transport (FLUTE) protocol.
Rather than create all services from scratch, the ATSC TSG S4 working group has selected elements of services, such as the ESG from existing mobile standards like the Open Mobile Alliance Mobile Broadcast Services Enable Suite (OMA BCAST). More details on the various services will be revealed by the ATSC in the near future.
The M/H data needs to be specially coded to serve the M/H receiver for reception under rapidly varying signal conditions, and at the same time appear the same as ordinary 8-VSB data to legacy receivers so that they are not disturbed. This is accomplished by precoding the M/H data and then passing it through the legacy ATSC process in the form of normal-appearing data packets.
ATSC-M/H system architecture
The precoding is done at two levels, first as data bytes and then as channel symbols. M/H data bytes are cross-interleaved and coded with both Reed-Solomon and cyclic redundancy check (CRC) codes. The data and its code bytes are packaged into normal ATSC data packets, which then are processed in the usual legacy process, including interleaving. This changes the solid block (or “group”) of M/H data to a sawtooth-shape region for transmission. In the second level of coding, normal ATSC trellis coding is augmented with a serial concatenated convolutional code (SCCC) for the M/H data. (See Figure 1.)
The group of M/H packets also contains known data sequences at regular intervals. These training sequences allow the M/H receiver to make accurate and frequent estimates of the channel multipath conditions. In fact, the M/H receiver can successfully receive a single, isolated group because of its instantaneous measurement of the channel.
| Want to use this article? Click here for options! |  |
