Visiting exhibits at an NAB Show can sometimes be less than fulfilling. Presenters can be distracted. The ambient buzz of the show hall makes it hard to understand every spoken word about intricate and complicated topics. This year above all, the most remarkable new technology at the 2020 NAB Show Express and its iterations was the “Back 10 seconds” button at virtual events.

Triveni Digital took advantage of the situation with an ATSC 3.0 Broadcast Gateway Product Overview webinar. It covered the hardware, software and UI of Triveni’s Broadcast Gateway for Nextgen TV systems and where it fits into the ATSC 3.0 broadcast chain. It was the same information that would have been presented in the exhibit, but comprehending the creation and control of ATSC 3.0 signals was much easier to with a ‘Back’ button and an ATSC Glossary nearby, in the peace and quiet of home. Triveni sales engineer Rubin Araza explained much of the following information in his webinar.

What is it?

ATSC 3.0 aggregates OTA and broadband data to add features, messages and other data to linear broadcast content. It becomes much more complicated when more than one TV channel is broadcast. Multiple components are required to create, control and manage not only the typical TV channel content, but individually for multiple Physical Layer Pipes (PLPs). PLPs are logical channels carrying one or more services, with a modulation scheme and robustness particular to that individual pipe. The are many ways to create and manage ATSC 3.0 transmission. Triveni has led the way into consolidating control and monitoring of the new ATSC 3.0 technology and its controllable variables into one solution.

The Broadcast Gateway/Scheduler is the core of ATSC 3.0 because it maps all the signaling from the generator out to the RF layer. Eventually mapping will be automated, but for now, manual control and stored dynamic settings are the best choice for early ATSC 3.0 broadcasting. It controls the ATSC RF layer provisioning for single or multiple PLP configurations, via a Signaling and Announcement generator such as the GuideBuilder XM, which is also a Real-time Object delivery over Unidirectional Transport (ROUTE) encoder.

The ROUTE encoder is an IP-centric, transport protocol compatible with layered environments, based on Internet Engineering Task Force (IETF) protocols. In ATSC 3.0, it is used to carry a Dynamic Adaptive Streaming over Hyper-Text Transfer Protocol (DASH) session of multimedia content. DASH is a method to stream packets of video and audio over IP for broadband and broadcast delivery.

Bundling Streams

All the DASH streams are bundled into the ROUTE or MultiMedia Transport Protocol (MMTP) multicast streams, and it provides the interpretation of what various PLPs are signaled for, mapping that data over to the proper PLP, sizing it with the proper configurations, and preparing it for transmission.

Frames and Sub frames are defined in the Gateway and can be provisioned with forward error correction (FEC) in the modulation encoding which is needed for each PLP, and signaling for OTA transmission with data loss protection. Ingested streams from the ROUTE or MMTP encoder are then multiplexed into a Studio to Transmitter Link Transport Protocol (STLTP) stream and sent to the ATSC 3.0 exciter for broadcast.

The Gateway also references the preamble signal for each PLP, and a defined Modulation and Code Rate (MODCOD) is then generated for the RF layer. This is what defines the RF characteristics for each of the PLPs. Each PLP can be different. One PLP can be for HD OTA reception, with other PLPs with various modulation and code rates for mobile and other types of applications that can all be provisioned on the RF layer.

The Broadcast Gateway/Scheduler can distribute both realtime and non-realtime (NRT) content. In conjunction with the GuideBuilder XM it can provision NRT content such as data, apps, and additional or supplemental video, as well as hyper-targeted ad insertion.

The Gateway works in conjunction with the Signaling and Announcement generator to provision data from either live sources or NRT sources and distribute it. Changes for PLP configurations can be saved and loaded by the user for service changes during the broadcast day. Stations can develop templates for various presets or settings that allow different types of broadcast scenarios for testing to eventually hone-in settings specific for station PLPs.

Where it Fits

Live or NRT content is HEVC encoded typically with Dolby AC-4 audio codecs and packaged into OTT ISO/IEC base media file format (BMFF) files. The files are segments that are delivered to the GuideBuilder XM, where they are combined with other relevant streams. The ESG listing service hasn't changed with ATSC 3.0 but it is now ingested into the GuideBuilder XM Signaling & Announcement Generator. The generator is also able to ingest incoming EAS AEA messages and package them for Signaling & Announcement. These incoming ancillary data sources and the video and audio segments are wrapped up in the ROUTE encoding. Once the PLPs are defined, the structure is related to the service list table (SLT) and service layer signaling (SLS) signaling tables. All those streams are then bundled into the ROUTE or MMPT encoder and sent to the Broadcast Gateway.

The Broadcast Gateway uses ATSC Link-layer Protocol (ALP) to encapsulate and encode these inputs to begin processing them for distribution over the various PLPs. The Broadcast Gateway maps and schedules input data to output RF subchannels or layers, and it converts the final signal to a STLTP stream for connection to the exciter.

The structure signal from the GuideBuilder to the Broadcast Gateway via the ROUTE or MMTP encoder begins with video, audio, all of the signaling and any NRT data become multicast streams that are ROUTE-encoded and pushed or pulled into the Gateway, depending on the scenario.

The ROUTE services are then alpha-encapsulated and mapped to PLPs as per Signaling, and an FEC scheme, modulation and encoding rate is applied based upon the application. A few PLP examples might include a HEVC carrier for fixed antennas, NRT for mobile, and perhaps a PLP dedicated for the electronic service guide (ESG), as well as some SD channel PLPs.

Cloud Alternative

The ATSC 3.0 Broadcast Gateway/Scheduler can be in a server or Cloud-based, and it can provide Cloud-based STLTP delivery with Secure Reliable Transport (SRT) and FEC as well. The Cloud-based model can offset some of the hardware expenses of putting an ATSC 3.0 channel on the air until the market begins to grow and develop. With Cloud access, operators can login to the same components and make the same adjustments as would be the case with on-site systems.

Cloud-based delivery content is also encoded locally into ISO BMFF files but delivered to the cloud, where all the previously described functions are performed. Output is from the cloud is a STLTP stream, wrapped with SRT for secure transmission. It is typically tunneled to provide an additional level of security on top of security and delivered to the exciter. The STLTP stream includes Signaling/SLT/SLS/LLS/NRT Data. It is ROUTE or MMTP encoded with the video and audio services, and then ALP encapsulated/mapped to PLPs per the signaling and FEC/MODCOD configuration is applied in the Gateway.

Operators are provided with a variety of screens in addition to the main screen shown above. As shown in Figure 1, The Monitor screen displays performance and bitrates of PLP streams over time. The Subframe/PLP details tab is the user sets up the RF layer to configure, insert or delete subframes or PLPs to create the structure of how to map those PLPs from the GuideBuilder XM through the Broadcast Gateway. Everything in the MODCOD can be defined in this tab. There are myriad of various settings because PLP technology allows for different schemes for different applications that can all be saved or stored.

Deep-access into similarly powerful settings and options choices for all other functions are found under the tabs for STL-TP, Network, Data/Time, Presets, Logs and System.