This tutorial will focus on the details of the signaling and announcement standards making up ATSC 3.0, in particular, the data structures, their interrelations, and how they are expected to be used by receivers compared with PSIP.

Digging Deep Into the ATSC 3.0 Protocol Stack

Comparing the ATSC 3.0 protocol stack with ATSC 1.0, there are several significant changes, the biggest of which is that IP is now part of both the broadcast and broadband stack in the new system. (See Figures 1 and 2.) Delving deeper, each layer of the protocol stack makes an impact on signaling and announcements.

At the bottom of the protocol stack, the physical layer is essentially the bootstrap. This layer carries information about how to decode the rest of the protocol stack. Important features include an emergency alert wakeup capability, allowing broadcasters to signal emergency alerts in the receiver. This layer also offers physical layer pipe (PLP) data, such as sIP (source IP address), dIP (destination IP address), dPort (destination port number), as well as information about whether the PLP contains a service list table (SLT).

The ATSC Link Layer (ALP) comes next. This part of the ATSC 3.0 protocol stack is fundamentally link layer signaling consisting of a header, links, and payloads. The link layer protocol hides various transport types from the physical layer. Leveraging ALP, broadcasters can perform IP and TS packet encapsulation, segmentation and reassembly, concatenation, and header compression. Included in the ALP layer is a Link Mapping Table (LMT) that describes how upper layer sessions are mapped to PLPs. The ROHC-U Description Table (RDT) is a header compression description for decompression purposes.

Following ALP is the UDP and IP multicast layers. It’s important to note that all of the streams that come through ATSC 3.0 are multicast and are based on a range of IP destination addresses (e.g., 224.0.0.0 to 239.255.255.255). ATSC 3.0 defines a specific IP address and port number for elementary streams instead of using PIDs, as was the case with ATSC 1.0.

The Low Level Signaling (LLS) layer of ATSC 3.0 can be found by the receiver via a dedicated multicast stream (i.e., 224.0.23.60/4937). LLS carries four table types as gzip’d XML with a binary header, including a Service List Table (SLT), Rating Region Table (RRT), System Time Fragment (SystemTime) based on the universal time clock (UTC), and Common Alerting Protocol Fragment (CAP). It’s recommended that broadcasters carry LLS on most robust PLP to allow guaranteed service discovery.

ATSC 3.0 relies on ROUTE (Real-time Object delivery over Unidirectional Transport) for delivery of all data streams, including essence streams (i.e., audio, video and captioning). MMTP (Multimedia Multiplexing Transport Protocol) is also included as a transport protocol, whereby MPUs wrap ISO BMFF files with metadata for broadcast delivery. For broadband delivery, HTTP is utilized.

ISO BMFF (Base Media File Format) provides a general file structure for time-based media files. With ISO BMFF, broadcasters can package content essence into manageable segments and presentation metadata. Each of the files is a collection of object-oriented “boxes” with its own type and length, and they are typically nested. Media Source Extensions (MSE) and Encrypted Media Extensions (EME) specify definitions for initialization segments, media segments, and random access points for carriage of video, audio and captioning.

The next layer, NRT (Non real time) file delivery, is pushed via ROUTE (broadcast) or pulled via HTTP (broadband). Any type of content can be delivered, and it’s signaled like any other service and referenced via URL from other metadata. Announcement and consumption model standards are still under development, but will likely be similar to what the industry is already doing with regards to live service delivery.

Comparing Roles: PSIP Versus ATSC 3.0 Signaling and Announcement

With ATSC 1.0, service discovery was enabled by program IDs (PIDs) described in the virtual channel table (VCT) via a service location descriptor (SLD). In the ATSC 3.0 standard, service discovery happens as a result of IP addresses found in in the SLT.

Service description will also change with the transition from ATSC 1.0 to ATSC 3.0. The ATSC 1.0 system carried PSIP metadata about each channel in the extended text table (ETT). ATSC 3.0 enables broadcasters to define service descriptions as well as service icons to maximize promotion of their service.

Content/program promotion consisted of event title and description text in the PSIP environment. While the text could be complicated, broadcasters were limited to how much text they could use. ATSC 3.0 has been developed in such a way to where broadcasters can define and utilize a program title, program description, as well as mechanisms for including program icons, preview clips, and program genre, allowing EPGs to be much more sophisticated. This also enables broadcasters to promote programs and events in a much cleaner and more interesting way than what was previously available.

Announcements are XML fragments based on OMA BCAST with extensions for ATSC 3.0. These are carried in a Service Guide Delivery Unit (SGDU), which is a binary header wrapped around individual SG XML fragments. There is also a Service Guide Delivery Descriptor (SGDD), an XML containing an exhaustive list of SGDUs in this service guide. (See Figure 3.)

For broadcast delivery the SGDDs are delivered on a single ROUTE LCT channel referred to as the “Service Guide Announcement Channel.” SGDUs may be delivered on one or more LCT channels. For broadband delivery the SGDDs and SGDUs are delivered via HTTP. Data units of SGDUs are basically referenced by SGDD. Icons and preview data are referenced by URLs and may be delivered via NRT (ROUTE) or broadband.

Conclusion

Currently, broadcasters are in experimentation mode. Korea is deploying the next-generation system for the 2018 Olympics. It is expected that early U.S. deployments will be a simulcast phase of both ATSC 1.0 and ATSC 3.0. Broadcasters would benefit to deploy a unified PSIP and ATSC 3.0 metadata generator due to commonalities of inputs and content elements. This will greatly simplify the transition, enabling broadcasters to generate and manage both types of metadata with the same UI and workflow. Unified metadata generation systems also offer common listing ingest and an integrated ROUTE option, minimizing training.