Peter Mataga /
03.01.2011
Originally featured on BroadcastEngineering.com
Mobile DTV widgets
Widgets provide a flexible tool for distributing content alongside Mobile DTV audio/video channels.

The standardization of a mobile/handheld-oriented digital television technology represents one of the most exciting recent developments in North American broadcasting. ATSC Mobile DTV (A/153, also known as ATSC-M/H) provides a backward-compatible, robust mechanism for transmission of digital television to power-constrained moving devices. In 2011, Mobile DTV is emerging from trials and tests into full-fledged market deployment and commercial device availability, as evidenced by announcements from the Mobile Content Venture (MCV) and its Pearl partners, from the Mobile 500 forum, and with significant commitments by the Corporation for Public Broadcasting and PBS member stations.

























While television on the go is clearly the target “application” of the original standard, the underlying, IP-based technology also enables a host of new services that go beyond traditional TV. For reasons that this article explores in more detail, the non-real-time (NRT) broadcast distribution of file-based content is one of the most important. Often referred to as mobile DTV widgets for short, a first step has been taken towards standardization of such services by the recent availability of the ATSC Non-Real-Time Content Delivery Candidate Standard.







Example user experience

Widgets provide broadcasters a powerful, flexible tool for distributing a variety of file and data content alongside Mobile DTV audio/video channels. This content may provide a standalone service to the user, or be loosely synchronized with a specific TV or radio channel. The bit rate required to deliver the content may vary widely, depending on the amount of data and the required acquisition time — anywhere from overnight push-of-video collections to almost-real-time stock ticker data or emergency notifications.

A good way to understand the power of NRT and mobile DTV widgets is to take a look at a typical consumer use case. In this scenario, a user is viewing a television program from a broadcaster. The user's device is able to discover that, in addition to the primary video stream, an associated set of secondary content services is available. A series of icons, provided by the content guide transmitted by the station, is displayed to the user — in this case showing news, weather, sports and traffic information.

Selecting the “headline news” widget brings up a list of headlines and news articles, which are also being broadcast over the air. The list of articles is continually updated throughout the day, and the user is alerted when new content arrives.

Selection of an individual headline brings up the full news article. The full article contains images, complex layout, hypertext and other features that should be reminiscent of Web-based content consumption. One way to think of the delivery of the article is that a small piece of a website has been pushed to all devices listening to the broadcast, and then browsed in the same way that offline caching and browsing is possible in the Internet world. In the present example, in fact, a common implementation would be to deliver an RSS index file and a set of HTML files and graphics for each article.

The effect of the widget is that a passive, schedule-constrained mobile broadcast TV experience has been extended with Web-like, on-demand content all while leveraging the reach, economics and user experience of broadcast.

Just as importantly, the broadcast content need not be completely self-contained. In the example scenario, the article can contain links to Internet-accessible additional content, such as related stories, the broadcaster's own website or advertising click-throughs.

ATSC Mobile DTV background

Non-real-time services represent a relatively small addition to the functionality already in place in the ATSC Mobile DTV standard. Space doesn't permit anything like a full MDTV overview here, but it's worth reviewing the key features of A/153 that make this possible.

First, unlike ATSC, the mobile standard is IP-based. All content, A/V or otherwise, is transported as multicast IP packets encapsulated by the mobile preprocessor and embedded in the existing ATSC signal in a backward-compatible fashion. Figure 1 summarizes the protocol layering involved; almost all the protocols above the IP layer are taken from existing technology. This allows Mobile DTV to reuse existing standards and products for IP A/V delivery — that is, television and radio services — but also provides a foundation for any other services that can be based on IP multicasting.

The Mobile DTV standard focuses on TV services but has been designed to be extensible to other service types. Moreover, the standard already includes a service type based on file delivery. Part 4 of A/153 specifies an optional but recommended feature known as Announcement, which provides a service guide (SG), often also referred to as an Electronic Program Guide (EPG). For a TV service, the SG includes information about the channels and programs, including rich program descriptions, channel logos and so forth. The delivery technology is based on an Open Mobile Alliance (OMA) specification for SG delivery, which in turn makes use of an IETF standard for File Delivery over Unidirectional Transport (FLUTE).

The inclusion of the OMA SG and provision for signaling of FLUTE components in A/153 means that many vendors have already implemented a significant part of the functionality needed for non-real-time file delivery services. In addition, the SG itself provides a mechanism for announcing NRT services and content.

ATSC NRT

The ATSC Non-Real-Time Content Delivery Candidate Standard (NRT CS), published at the end of 2010, provides a unified approach to NRT file delivery for both existing ATSC DTV transmissions (referred to as “fixed” for convenience in the NRT CS) and for Mobile DTV. There are differences in the way that the guide to services and content is provided in the two cases, but a common model for content delivery and consumption is followed.

The CS makes use of IP-based file delivery using FLUTE, which allows files to be segmented, transmitted in packetized form and reassembled at the receiver. It also introduces the concept of a “content item,” which represents a collection of one or more files intended to be rendered to the user as a single experience. In the simplest case, this could be a single media file such as a video clip, but a more general example would be a set of Web pages and associated graphical resources that can be downloaded and browsed locally on a receiver device. In the initial version of the standard, content is displayed to the user on demand rather than being tightly synced with rendering of broadcast TV.

The NRT CS also specifies a way for NRT services to be announced, and for content information and delivery schedules to be provided to a receiver. In particular, the signaling of “essential capabilities” required for the receiver to render a service or a specific content item allows a receiver device to determine not only the available services, but whether a service should be offered to the user of the device. For the most part (though other aspects are involved as well), these capabilities can be thought of as media types, and the intent is to take advantage of the existing capabilities of receivers in rendering content such as JPEG and PNG files, MP3 Audio and H.264 video clips, HTML pages, and RSS feeds.

For Mobile DTV, the NRT CS represents a reuse and extension of technology already in use for Signaling and Announcement purposes. (See Figure 1.) A new service type is introduced, and minor extensions are made to the existing FLUTE component signaling. Content items are delivered using FLUTE (with some extensions introduced to group files together). The XML elements within the OMA SG have been extended with NRT-specific information.

Broadcaster deployment

For the technical and historical reasons sketched above, the incremental investment required by transmission equipment and receiver device vendors to develop NRT platforms and middleware is likely to be relatively modest. Several companies have had IP multicast server and client product lines based on the FLUTE protocol for a number of years, including applications to mobile broadcast technologies such as DVB-H, MediaFLO and MBMS. Pre-standard implementations of M/H widget services have already been deployed, and Harris, KLAS-TV, LG Electronics and Roundbox recently demonstrated an interoperable ATSC-NRT-CS-compliant coupon delivery application over the air at CES 2011.

Because NRT services piggyback on the multicast transport intrinsic to ATSC Mobile DTV, deployment involves an incremental, relatively low-cost enhancement of the infrastructure broadcasters have already put in place for Mobile DTV. For most stations, deploying widgets would be a straightforward software upgrade of their existing ATSC-M/H Signaling and Announcement servers. Figure 2 on page 35 sketches the high-level architecture of a Mobile DTV solution, and indicates three main additional functions or interfaces that need to be provided to enable widgets: NRT data stream generation, SG integration and file data ingest.

The FLUTE streams carrying the files must be generated by an NRT server function. For the most part, these multicast IP streams are handled by the rest of the system in the same way that IP audio/video streams are for TV: multicast over a local LAN and received and encapsulated by the mobile mux. The NRT server must provide bandwidth control and scheduling for the datacast streams.

The content items being transmitted, and their descriptions and delivery schedule, must be coordinated with the Announcement Server generating the SG, and the Announcement Server functionality must be enhanced to include the NRT content guide functions. For this reason, the NRT Server and Announcement Server will often be software modules on the same physical server.

Finally, the NRT server must be able to ingest the files and their metadata (including schedule) from one or more data sources. This back end aspect is not standardized by the NRT CS. A content management system could be built into the NRT server, but a more common approach is for the files to be populated in a remote system that can be accessed using familiar protocols.

Leveraging station Web investments

The reuse of Web-oriented systems in the back end of an NRT solution is more than a technology nicety. Basing widgets on Web technologies can immediately extend a station's Web business investments. AdWeek, quoting Borrell & Associates, noted that in the last few years, station Web properties have become a billion dollar business in aggregate and continue to grow at more than 50 percent year over year.

As a result, broadcasters have significant expertise in packaging, delivering and selling advertising against Web-based content. Mobile DTV widgets take this experience and provide stations new carriage over an old medium — broadcast. Moreover, because the broadcast widget content can include links usable by an Internet-connected receiver device (and most mobile devices will have Internet access via 3G/4G or WiFi networking), it should be thought of as a hook to pull users into richer, targeted and monetizable interactions at a broadcaster's or advertiser's website.

Specialized applications

The ATSC NRT CS provides a framework for interoperable distribution of content, with the primary goal of allowing a wide range of receiver devices to display collections of more or less arbitrary content compiled by the broadcaster. It is also possible to employ the NRT machinery in more specialized ways for specific public service or commercial uses of broadcast spectrum. Such applications may be operated directly by a broadcaster, or be part of a business model in which Mobile DTV bandwidth is leased to a third party.

An obvious use case for widgets is the delivery of emergency alert material to broadcasters' communities. The Emergency Alert System (EAS) recently standardized a new, nationwide alert format known as the Common Alerting Profile (CAP). Because EAS-CAP alerts leverage a variety of Internet technologies, they can easily be integrated with Mobile DTV widgets to support widely deployed broadcaster initiatives such as Amber Alerts.

Conclusion

Mobile DTV Widgets are a powerful new opportunity for stations to use broadcast technology to deliver more than TV. By leveraging station investments in and consumer familiarity with Web content, Mobile DTV widgets can be quickly deployed alongside traditional TV services to deliver consumers the on-demand, Web-like content services they love, in a way that takes advantage of the reach, economy of scale and congestion-free character of the broadcast system.

Given the new generation of media consumers and their favored devices, NRT technology provides broadcasters not only an extended audience for TV, but also opportunities for new, revenue-generating services that integrate the best of the Web, mobile and broadcast technologies.


Peter Mataga, Ph.D., is CTO of Roundbox.



Comments
Post New Comment
If you are already a member, or would like to receive email alerts as new comments are
made, please login or register.

Enter the code shown above:

(Note: If you cannot read the numbers in the above
image, reload the page to generate a new one.)

No Comments Found




Monday 6:39AM
What Price Reliability?
Digitally delivered TV has seen a pile o’ fail lately.


 
Featured Articles
Discover TV Technology