Dynamic Advertisement Insertion using a Data Distribution as a Service platform and MPEG Media Transport

Sangsu Kim

Abstract – Over-the-Air (OTA) advertising lacks features provided by its Over-the-Top (OTT) counterpart due to the one-way nature of OTA advertising. The Advanced Television Systems Committee (ATSC) 3.0 standard, which uses Internet Protocol (IP) for broadcasting, helps narrow the gap between broadcast and broadband environments. Broadcasters are now able to deliver regionally addressable advertisements through OTT and OTA (utilizing the ATSC 3.0 standard) using the same signaling format.

This paper introduces two potential solutions to provide targeted advertising through timely insertion of advertisements into live TV programs. We also review a Data Distribution as a Service (DDaaS) platform and the ATSC 3.0 MPEG Media Transport (MMT) protocol, which are integral to making these solutions feasible.

Introduction

The ATSC 3.0 standard introduces two solutions that enable broadcasters to offer advertising services with features similar to those in Over-the-Top (OTT) advertising. However, both solutions require an Internet connection.

The first solution is based on the Server-Side Advertisement Insertion (SSAI) model introduced by PearlTV [5]. This approach includes interactive advertising that utilizes Video Advertisement Serving Templates (VAST) and Dynamic Adaptive Streaming over HTTP (DASH) Advertisement Insertion specifications defined within the ATSC 3.0 standard.

The second solution is based on Society of Cable and Telecommunication Engineers 35 (SCTE-35) [6] messages that are injected into the broadcast stream. An encoder uses these messages to generate DASH streams, which are accompanied by XML Linking Language (XLink) data added to the DASH manifest to connect external resources.

In this paper, we propose two potential Advertisement Insertion solutions for targeted advertising based on MPEG Media Transport (MMT) in the ATSC 3.0 standard, which do not require an Internet connection. We demonstrate how original advertisements in a TV program can be replaced with targeted advertisements distributed via a Data Distribution as a Service (DDaaS) platform. These methods utilize MMT signaling in ATSC 3.0 receivers that support the ATSC 3.0 standard. Additionally, we briefly outline the minimum requirements for the DDaaS platform that make these solutions feasible.

System Components and Distribution Requirements

In this section, we outline the minimum capabilities required for the Data Distribution as a Service (DDaaS) platform to distribute targeted advertisements. We then provide information about related signaling requirements and content structuring.

 The DDaaS platform supports content delivery based on two common advertising criteria: distribution schedules and geographic targeting. Advertisements are handled as Non-Real Time (NRT) files,  which are delivered in advance and identified as advertisements by the receiver.

The proposed Advertisement Insertion methods require the content to be available on receivers before the Advertisement Insertion process begins. These Advertisement Insertion methods are responsible for selecting the appropriate advertisement to display based on contextual factors such as location, timing, or service configuration. Therefore, the platform needs to support scheduling mechanisms for timely delivery. Several parameters contribute to this capability:

• Distribution (Broadcast) Time: The time of day during which the content distribution (broadcast) sessions shall start and end.
• Repeats: How many times during Distribution Time to broadcast the content.
• Recurrence: The frequency of the distribution of the content over days.
• Range of Recurrence: The period during which the content distribution shall occur.

Distribution Time provides broadcasters with flexibility to decide when to broadcast the content. This is important because in the DDaaS platform, resources used to distribute content may not be available during certain times, such as when they are fulfilling other data distribution requests.

Recurrence, Repeats, and Range of Recurrence indicate on which days and how many times content distribution shall take place, respectively. At first glance, these parameters may seem redundant. One might assume that a one-time content distribution should be enough to deliver the content to receivers. However, such a design cannot guarantee the availability of content on all receivers at the proper time (in advance of the Advertisement Insertion process). This is because some receivers may only become available to receive the content when the broadcast session starts. A later section on distribution window description describes a mechanism to help with this scenario.

Broadcasters should be able to limit content distribution to specific geographical areas. The DDaaS platform can achieve this by providing tools that allow broadcasters to choose one or more Designated Market Areas (DMAs). While broadcasters are traditionally familiar with DMAs, the DDaaS platform may consider more granular identifiers such as postal codes and county codes. If such identifiers are considered, mechanisms to configure receivers to receive relevant content must also be considered.

Advertisement Insertion further requires additional information, namely Asset ID and Advertisement Time(s). Asset ID is an identifier that uniquely identifies an advertisement. Advertisement Time indicates the actual time at which an advertisement must be displayed. These metadata elements ensure that the appropriate advertisement is played on the correct receiver at the right moment.

MMT Overview

MPEG Media Transport (MMT) [2] is a standard for transporting multimedia data developed by the Moving Picture Experts Group (MPEG). It is a fully developed standard that provides encapsulation, delivery, and presentation of multimedia content, enabling hybrid (broadcast and broadband) content delivery through IP packets. MMT supports important features such as Quality of Service (QoS) and efficient Forward Error Correction (FEC). MMT specifications are mostly defined in three parts: 1) MPEG-MMT Part 1 (MMT, ISO/IEC 23008-1), 2) Part 10 Forward Error Correction (FEC, ISO/IEC 23008-10) Codes, and 3) Part 11 Composition Information (CI, ISO/IEC 23008-11). Part 1 is mainly concerned with encapsulation methods, signaling, and delivery mechanisms.

We provide a brief description of important concepts on MMT in the following sections.

MMT Part 1 defines the structure of the multiple media content that is ready to be fragmented (packetized) for streaming or progressive download. Figure 1 shows the layered structure of MMT that is used for controlling transportation and consumption of fragments. This structure is concerned with encapsulating (Encapsulation Function), content delivery (Delivery Function), and signaling (Signaling Function)

Encapsulation Function (EF) in MMT defines the logical structure of the content and introduces the concepts of Asset and Media Processing Unit (MPU) format. The content structure is based on different asset types that correspond to each elementary stream, such as video, audio, and subtitles. An Asset is a logical group of MPUs that share the same Asset Identifier (Asset ID) for carrying encoded media data. Encoded media data can include timed media such as MPEG-2 TS files, MP4 files, and non-timed media such as web pages, texts, and pictures. Each Asset has its own Asset ID, which can be represented, for example, with a Uniform Resource Identifier (URI) or a Universally Unique Identifier (UUID). An MMT package is a collection of one or more Assets, and an ATSC 3.0 Service can include one or more MMT packages.

An MPU is a self-decodable and self-rendering media unit structured based on the ISO Base Media File Format (ISOBMFF) [5], which is an MPEG standard primarily intended for timing of media data such as audio and video. MPUs in an Asset are distinguished by sequence numbers and do not overlap on the timeline. When these MPUs are delivered through MPEG Media Transport Protocol (MMTP), they are separated into small segments named Media Fragment Unit (MFU), which usually consists of one Access Unit (AU) or part of an AU.

Delivery Function (DF) in MMT has three modes: 1) MPU, 2) Generic File Delivery (GFD), and 3) Signaling Message. MPU mode is for transporting MPUs and can be used for real-time services such as broadcast and streaming. GFD mode is used for download services and is the counterpart of the NRT service in the MPEG-2 TS system. Signaling Message mode is for exchanging signaling messages through MMTP.

ATSC 3.0 introduced the Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol for NRT object delivery. ROUTE works with MPEG-DASH based segments. Both MMTP and ROUTE packets are delivered through User Datagram Protocol (UDP), while in broadband Transmission Control Protocol (TCP) is used.

Signaling Function (SF) in MMT specifies signaling messages that provides information about media consumption and delivery to receivers. These messages can be delivered in a payload of an MMTP packet and are multiplexed with other media packets.

There are five main messages [2] defined in the MMT standard as follows:

• Package Access (PA) message: This message includes various information about a Package.
• Media Presentation Information (MPI) message: This message includes Composition Information (CI).
• MMT Package Table (MPT) message: This message includes information about assets in a Package.
• Device Capability Information (DCI) message: This message includes device capability information.
• Clock Relation Information (CRI) message: This message includes mapping information of Network Time Protocol (NTP) timestamps and System Time Clock (STC) of MPEG-2 TS.

MMT includes other messages that are defined in Amendment ISO/IEC 23008-1 [2].

Figure 2 provides detailed information on how a receiver uses MMT signaling to discover and display MMTP packets.

A receiver accesses a stream containing Low Level Signaling (LLS) data using a pre-defined IP address (224.0.23.60) and port number (4937), first. LLS data includes Service List Table (SLT) ① that provides information about the desired broadcasting service. More specifically, SLT supports a rapid channel scan that enables the receiver to build a list of all ATSC 3.0 services. SLT also provides bootstrap information that allows the receiver to locate Service Layer Signaling (SLS). This bootstrap information contains the destination IP address, port number, and the MMTP session that carries SLS for services delivered via MMTP/MPU. MMTP and ROUTE sessions are identified the same way. MMTP includes the destination IP address, port number, and packet_id (a unique identifier).

Before acquiring the delivered content from broadcasters, the receiver parses SLS ②.  SLS is comprised of XML-based fragments of User Service Description (USD) ③ and MPT. SLS describes characteristics of a service, its content components, where to acquire them, and the device capabilities that are needed to present the service meaningfully. USD mainly references MMT Package Table (MPT) ④ message in MMT signaling. MPT provides identification of package ID and location information for assets belonging to the service. MMT signaling messages are delivered by MMTP according to the signaling message mode. MPT that is extracted from MPT message is processed to get the list of MMT assets that comprise a selected service with the designated MMT packet_id. Finally, the first Access Unit (AU) in an MPU from the selected asset ⑤ is decoded by the appropriate decoder and presented at the time specified by the MPU_timestamp.

Advertisement Replacement Using the Data Distribution as a Service (DDaaS) Platform

In this section, we provide an overview of the approach to replace the original advertisements (those already included in a live TV program) with targeted advertisements in real-time using the Data Distribution as a Service (DDaaS) platform and MPEG Media Transport (MMT). In later sections, we provide specific methods to implement Advertisement Insertion.

We propose a Client-Side Advertisement Insertion Method (CCAI). In this method, predefined advertisement time slots are filled with targeted advertisements that are already delivered to the receivers. Initially, the DDaaS platform distributes regionally targeted NRT files containing advertisements to receivers, which receive and cache them. During the processing of live MMT streams, when an advertisement marker (indicating the start of an advertisement) is encountered, the player requests the corresponding advertisement using its Asset ID from the receiver. The receiver responds to the request by providing the advertisement cached, which the player uses to fill the time slot for the advertisement. The basic steps are:

1. An advertisement marker included in the MMT stream indicates when the player should pause the live TV stream playback and switch to new content.
2. The player requests an advertisement previously delivered through broadcast and stored on the receiver.
3. The receiver responds with the designated advertisement.
4. The player pauses the playback of the MMT stream and plays the advertisement.
5. Once the advertisement is complete, the playback of the MMT stream resumes.

The DDaaS platform offers a broadcast network for delivering advertisements. Advertisements configured through the DDaaS platform are broadcast as NRT files via the Broadcast Gateway (Scheduler) and received by receivers. The ATSC 3.0 Broadcast Gateway (BG) supports Low Level Signaling (LLS), Real-Time Object Delivery over Unidirectional Transport (ROUTE), MMT, Electronic Service Guide (ESG), and NRT delivery.

Receivers receive the broadcast, which includes MMTP packets. These packets are de-packetized, and the encapsulated media data is decoded by the appropriate media decoders. Advertisements are delivered as NRT files through ROUTE. To receive the NRT files, the receiver must be provided with the Extended File Delivery Table (EFDT), which includes file metadata. Each delivered file references the Layered Coding Transport (LCT) session using its URI. File URIs are used to identify the delivered EFDT, and the receiver uses the EFDT to process NRT content.

Files containing advertisements must be DASH segments that include Media Presentation Description (MPD). This is achieved by encapsulating MPUs into DASH segments. Broadcast Gateways (BG) are used to broadcast advertisements according to data distribution schedules and generate markers in the MPT to signal the replacement of advertisements in live MMT streams. These markers are part of the MPT table and contain Asset location information and presentation time. The BG checks whether the Asset included in the live MMT stream matches the Asset ID of the advertisement created in the DDaaS platform. If there is a match, the BG updates the information in the MPT table from the live asset to the advertisement information.

At minimum, one service with proper signaling must be created (or available) to deliver NRT files. ATSC 3.0 standard documentation A/331 (Signaling, Delivery, Synchronization, and Error Protection) [1] specifies different methods of file delivery. The methods should not impact the existing broadcast (media) services:

• Using a dedicated ROUTE session that could be HIDDEN,
• Using a private service (User Defined Service with LLS table ID 0xFF)

Distribution Window Description (DWD) is thoroughly defined in [1]. Using DWD, NRT file delivery schedules can be communicated to receivers in advance of the actual broadcast time. DWD includes “indication of the specific files that will be transmitted during a given distribution window” [1]. Receivers can use this information to plan for their availability when NRT files are broadcast. To ensure that a file is delivered in its entirety, one method is to broadcast it multiple times. This is important in situations where a receiver is already tuned to a different service during a distribution window. Using this method, the receiver can receive the file during the later broadcast sessions.

To ensure that receivers only process NRT files of interest, such as advertisements designed for specific postal codes, two pieces of information, AppContextID and Filter Codes, included in DWD can be used by the receiver. Each distribution window instance can include one or more AppContextID elements, which in turn may contain one or more Filter Codes. Filter Codes are 32-bit unsigned integers and are unique within the context of their corresponding AppContextID instance.

Receiver operations and requirements include multiple functions necessary to support AI. When switching from an MPU to a DASH segment, the player in a receiver uses the latest MPD contained in an MPT message to make a local request for a DASH segment before the transition. The received DASH segment is buffered in advance and made available to the player for decoding. It’s important to note that the DASH segment and MPU must have the same video/audio format.

A receiver needs to tune to one or more broadcast channels used for NRT file distribution to receive advertisements. This can be accomplished by performing a channel scan to search for fingerprints that identify which advertisements to accept. Fingerprints can be specific AppContextId and/or Filter Codes, for example.

Advertisement files are received and stored on file systems. Receivers can use the information in the DWD and similar information at the Service, Session, and Object levels to filter which files to accept. Eligible files are received and stored on storage available to the receiver. However, the information used to accept or ignore files does not provide the level of control needed to manage the storage. To manage the storage, the following functionalities are necessary:

• Cache Management: Manage the cache when the amount of content exceeds the available cache size.
• File Management: Remove NRT files that are no longer required or have timed out from the local cache.
• Cache Miss Management: Implement a fallback method for obtaining NRT files if they are not saved in the local cache when requested.
• Cache Population: Instruct the receiver to store received NRT files from ROUTE sessions.
• Content Download: Receive the required NRT files, potentially requiring re-tuning the receiver at a specific time when it is not in use for other purposes.

To provide necessary metadata for advertisements, include the following information:

• Asset ID: Unique identifier for the advertisement.
• Name: Name or title of the advertisement.
• Received Time: Time when the advertisement was received by the receiver.
• Complete/Incomplete: Indicates whether the advertisement was received completely or incompletely.
• Size: Size of the advertisement file.
• Duration: Length of the advertisement in seconds.
• File Signature (MD5/SHA256 Hash): Has value to verify the integrity of the advertisement file.
• Validity Start Time: Start time for the validity of the advertisement.
• Validity End Time: End time of the validity of the advertisement.
• Application Context ID: Identifier for the application context related to the advertisement.
• Filter Codes: Codes used filter and select specific advertisements.
• Content type: Type of content (e.g., video, audio, image).
• Content Location in the Cache (URI): URI pointing to the location of the advertisement in the local cache.

This metadata can be used for managing, tracking, and displaying advertisements in the broadcast system.

Receivers are required to support a lightweight web server that enables a file consumer to access the files through http protocol. The application running on a receiver uses this capability to access the files that are accepted and stored on the storage. In addition to playing live broadcast content, a receiver shall also be able to playout NRT advertisement files that are stored in the Cache. This capability is also provided through the lightweight web server which in conjunction with the storage can be viewed as localized mini-Content Delivery Network (CDN).

When receivers are not actively functioning, for example, videos are not being played, they should support a Standby mode so that they can still become available to receive new data. In other words, the Standby mode enables the receiver to wake up and receive new data, based on previously signalled schedules such as those defined in DWD.

Advertisement Replacement

This section describes two methods for replacing live TV advertisements, transmitted through MMT, with advertisement distributed by the Data Distribution as a Service (DDaaS) platform. One method leverages static signaling embedded in the MMT Package Table, while the other uses dynamic Event Stream notifications that enable metadata-driven advertisement switching.

The first method uses the MMT Package Table. To explain this, we first provide background on how a TV program is received in MMT-based broadcasting systems, followed by the replacement mechanism.

The process of receiving and rendering media components in MMT-based broadcasting systems is as follows:

• Identification: The receiver identifies MMTP packets carrying MPUs through MFUs.
• Decoding: The receiver decodes the received MFUs to extract the media data.
• Rendering: The decoded media data is rendered at the designated time, allowing the viewer to watch the desired TV program.

An Asset represents a media component and is equivalent to a series of MPUs. In MMT-based broadcasting systems, a TV program is an MMT Package, which includes one or more Assets and the corresponding signaling information. A Package Access Message (PAM) is an MMT-Service Information (MMT-SI). The MPT included in the PAM identifies the Assets that make up a TV program. To retrieve the PAM, a receiver should look for MMTP packets with ‘packet_id’ equal to zero (‘packet_id=0’). Receivers parse the PAM to extract the MPT.

A receiver uses the MPT to identify ‘packet_id’s of MMTP packets that carry the required MPUs (parts of the Asset) for a TV program. Additionally, it obtains the display time of the MPU by referring to the MPU Timestamp Descriptor included in the MPT. Multiple services might be multiplexed into one IP data flow. Therefore, the receiver should verify whether the ‘packet_id’ of the acquired MPT corresponds to the desired ‘service_id’. If there is a mismatch, the receiver should acquire the Package List Table (PLT) included in PAM. The PLT provides information corresponding to the MPT of the desired service.

To replace an Asset in a live TV program with an advertisement stored locally, the receiver requires an advertisement marker to indicate when an advertisement should be displayed. Additionally, the receiver needs information about the type and location of the locally stored Asset for the replacement advertisement. Figure 3 illustrates how this information is obtained.

The location reference information for the Asset, as shown in Figure 3 [2], is detailed in Table 57. For Asset locations, the value of ‘location_type’ shall be either ‘0x00’ or ‘0x06’. A value of ‘0x00’ indicates that an Asset is in the same MMTP packet flow as the live TV program, while ‘0x06’ indicates a private location, such as a location in the receiver’s local cache.

When utilizing the MMT package table for replacing the advertisement, the ‘location_type’ field is set to ‘0x06’ to specify the location of the advertisement stored in the receiver’s local cache. The ‘byte’ value of this field shall be the URI referencing the MPD of a DASH segment that contains the advertisement. This allows the receiver to locate and retrieve the advertisement from its local cache for playback. The method to replace the advertisement involves the following steps:

1. A packet in the live MMT stream contains an Asset with a ‘location_type’ of ‘0x06’, which serves as an advertisement marker. This marker indicates when the live stream should break from the playback and switch over to the advertisement.
2. The player reads the advertisement marker and requests the receiver to retrieve an advertisement stored in the local cache using the URI indicated by the marker.
3. The receiver responds with the correct advertisement.
4. The player pauses the playback of the MMT stream and plays the advertisement.
5. Once the advertisement is finished, the playback of the MMT stream resumes.

While AEI supports pre-scheduled advertisement markers, some use cases require more adaptive signaling. For such scenarios, the Inband Event Descriptor (IED) provides a dynamic alternative.

The second method for advertisement replacement involves the use of Event Stream signaling. To explain this method, we first provide a brief background on how Events are received. Events serve as notifications to inform a receiver or Broadcast Application that something has changed, such as the availability of new signaling data.

ATSC 3.0 services carried by MMTP use MMTP-specific signaling messages specified in Clause 10 of ISO/IEC 23008-1 [2], delivered in binary format by MMTP packets according to the Signaling Message Mode specified in sub-clause 9.3.4 of ISO/IEC 23008-1. This sub-clause specifies that the value of the ‘packet_id’ field of MMTP packets carrying SLS shall be set to ‘0x0000’. Additionally, another message called MMT ATSC3 (MA3) message (‘mmt_atsc3_message()’) carries system metadata that are specific to ATSC 3.0 services such as SLS. The value assigned to ‘message_id’ for MA3 message [1] is defined as ‘0x8100’, and each message is described in the following Figure 4.

In this research, we utilize Application Event Information (AEI) (0x0004) and Inband Event Descriptor (IED) (0x0007), collectively known as Event Stream in Figure 4. Both AEI and IED are used to notify a receiver when unexpected updates to signaling metadata objects become available.

The EventStream element is especially well suited for “static” Events, i.e., Events for which the timing is known well ahead of time. When delivered via broadcast in an MMT-based broadcasting system, Events may be delivered in an XML document called an Application Event Information (AEI) [3] document (Figure 5).

Each EventStream element has an ‘@assetId’ attribute and a ‘@schemeIdUri’ attribute to identify the type and location of Events with an advertisement marker in the EventStream.

To replace an Asset in the live MMT stream with an advertisement stored in the cache, the receiver should first check whether the ‘@assetId’ is valid and whether an advertisement from the location indicated by the URI pointing to the MPD of a DASH segment is available.

The steps to insert a new advertisement are:

1. A live MMT stream has an AEI which is used as an advertisement marker. This marker is used to indicate when the live stream should break from the playback and switch over to the advertisement.
2. The player reads the advertisement marker and requests the receiver to retrieve an advertisement stored in the local cache using the URI indicated by ‘@schemdIdUri’.
3. The receiver responds with the right advertisement.
4. The player pauses the playback of the MMT stream and plays the advertisement.
5. Once the advertisement is finished, the playback of the MMT stream resumes.

In addition to AEI, another signaling method involves the use of the Inband Event Descriptor (IED), which indicates the presence of Events in the MPUs. The IED table (Figure 6) contains ‘@assetId’ and ‘@schemeIdUri’. These attributes function similarly to those in AEI.

Events in MMT-based broadcasting systems can be carried in ‘evti’ boxes. Files conforming to the MMT media file format are formed as a series of objects, called “boxes”, which contain all media/metadata. The “box” is an object-oriented building block defined by a unique type identifier and length. Advertisement markers in MPUs can be represented in ‘evti’ boxes. This method is particularly suitable for “dynamic” Events, i.e., Events for which the timing only becomes known at the last minute. The structure of an ‘evti’ box is indicated below, using the usual form of specification for a box in an ISO BMFF file [5].

An evti box may appear at the beginning of the file, after the ‘ftyp’ box, but before the ‘moov’ box, or it may appear immediately before any ‘moof’ box.

Aligned (8) class EventInformationBox extends FullBox ('evti', version = 0, flags = 0) {          
string scheme_id_uri;              
string value;  
unsigned int(32) timescale;              
unsigned int(32) event_id;              
unsigned int(32) event_presentation_time_delta;              
unsigned int(32) event_duration;              
unsigned int(8) event_data[]; }    
}  

Figure 7. Table 4.2 Syntax of an evti box

To replace an Asset in the live MMT stream with an advertisement stored in the cache, the receiver should first check whether the ‘@assetId’ in IED is valid and whether an advertisement from the URI indicated by ‘scheme_id_uri’ in ‘evti’, pointing MPD of a DASH segment, is available in the local cache.

Because IED is an MMT Signaling message, it can be transmitted prior to an MMT MPU with ‘evti’. This informs the receiver in advance that the Asset in the live stream may be replaced with another advertisement. The steps to insert a new advertisement are as follows:

1. A live MMT stream has an IED which is used as an advertisement marker. This marker is used to indicate when the live stream should break from the playback and switch over to the advertisement.
2. The player checks an ‘assetID’ from IED and requests the receiver to retrieve an advertisement using ‘scheme_id_uri’ from ‘evti’ of MMT MPU. An URI points to a file in the local cache.
3. The receiver responds with the right advertisement.
4. The player pauses the playback of the MMT stream and plays an advertisement.
5. Once the advertisement is finished, the playback of the MMT stream resumes.

Beyond receiver-side replacement, advertisement logic can also be controlled by a Broadcast Application (BA), which interfaces with the receiver through standardized signaling Application Programming Interfaces (APIs). In such cases, the BA should use the A/344 API [4]. Initially, the BA should utilize the subscription API (9.3.1.1 Integrated Subscribe API in A/344) to start receiving the desired notifications, such as AEI. The Signaling Data Change Notification is issued by the receiver to the currently executing BA if a new version of signaling data is received. The BA may respond to the notification of a change to the signaling data by using the Query Signaling Data API specified in Section 9.2.10 of A/344. The receiver will continue to send subscribed notifications until the BA requests the Integrated Unsubscribe API.

The BA can proceed with the same procedure as the receiver did above with the AEI. However, advertisement playback should be delivered to the Receiver Media Player (RMP) managed by the receiver. This allows the BA to take advantage of an optimized media player provided by the receiver. The BA may use the Set RMP URL API (9.7.3 Set RMP URL API in A/344) to request the receiver to use its RMP to play the advertisement retrieved from the URI specified in the AEI. Once the receiver is notified to play the advertisement from the BA-provided URI, the RMP stops rendering the broadcast content and begins rendering the advertisement referenced by the new URI.

Test Environment

In our experiments, the test environment (Figure 9) consisted of three components that are described in this section.

To model the distribution of NRT files corresponding to advertisements, we utilized the Data Distribution as a Service (DDaaS) platform sponsored by Sinclair Broadcast Group. This platform enabled us to seamlessly specify the content, time, and DMAs for our experimental advertisements. Figures 10, 11, and 12 illustrate how data distribution requests, corresponding to advertisements, are modeled.

In the ATSC 3.0 air chain, we used a DigiCaster packager and a DigiCaster scheduler, whose output was sent to an exciter. Due to transmission restrictions in a lab environment, the output of the exciter was routed directly to the receiver using antenna coax cables. Figure 13 illustrates the configuration of the scheduler, which mirrors the setup for one of Sinclair’s hosted stations.

To receive the broadcast content, we used a HomeCaster device provided by DigiCAP Co., Ltd. This device includes two tuners capable of receiving both ATSC 1.0 and 3.0 signals. Its primary function is to receive and demodulate ATSC signals, then demux them into media sources. It can also be configured as a node in a Local Area Network (LAN), allowing us to access received content through API calls supported by the device.

The HomeCaster Middleware performs several key functions, including re-transmitting media sources using RTP, UDP, HLS, and DASH. It also provides access to NRT files via an integrated Apache HTTP server. Figure 14 shows a snapshot of the HomeCaster’s Download page, which can be used to verify received broadcast content.

Test Result

Our experiments involved on-demand broadcasting of files ranging from 1MB to 100MB in size. Using Sinclair’s Data Distribution as a Service (DDaaS) platform, we scheduled these files for broadcast at various times throughout the day. We confirmed that the receiver successfully received each file and verified the integrity of the files by calculating their SHA256 hash.

Future Work

In this section, we provide some information about future work to show how a complete AI process might function.

In our experiments, we utilized the Data Distribution as a Service (DDaaS) platform to demonstrate how advertisements can be delivered to receivers in a timely manner for AI. While Sinclair’s DDaaS platform supports the use of AppContextId and Filter Codes for targeting specific audiences, the current lack of receivers that support this feature prevented us from experimenting with it at this time. We have communicated our requirements to several producers of ATSC 3.0 receivers and are awaiting broader receiver availability to conduct detailed experiments involving AppContextId and Filter Codes.

The two proposed methods for AI in this paper are theoretical and require further exploration. So far, we have verified that advertisements transmitted from the DDaaS platform are reliably stored in receivers. Our next step is to confirm that advertisements included in live MMT streams are correctly replaced with stored advertisements at the appropriate times.

In 2023, the ATSC 3.0 specification was enhanced with additional features, including DRM and Application/Signaling Signing. This development indicates that MMT specifications have now reached a level of organization similar to ROUTE/DASH. Furthermore, MMT has gained popularity in mobility use cases, with several projects in the 3rd Generation Partnership Project (3GPP) adopting it. However, there are currently few receivers that fully support MMT. As the MMT specification continues to evolve, we plan to provide test environments where companies developing Broadcast Gateway and TV/Receiver devices can build and validate their MMT-based solutions.

The proposed AI solution offers the advantage of being inexpensive and easy to deploy, especially for one-way OTA environments. However, it currently delivers the same advertisement to all receivers tuned to the same channel in a given region. To address this, we propose a method to provide more granular advertising by segmenting the audience into smaller groups based on viewing patterns and behavioral data, using third-party Ad-Decision solutions. Segmentation may be based on geographic factors such as country, state, or city, as well as content criteria such as channel genre or time of day.

Conclusion

MMT is designed to efficiently deliver multimedia content over IP networks, enabling dynamic adjustments based on network conditions and device capabilities. This allows broadcasters to deliver high-quality content, including 4K UHD broadcasts, simultaneously to consumers at home and on mobile devices. MMT also helps reduce real-time media encoding delays and channel change times at the receiver, thereby enhancing the viewer’s perceived quality of experience. Sinclair Broadcast Group has successfully deployed MMT—including Scalable HEVC (SHVC)—as part of its OFDM transmission system in Baltimore, Maryland, Washington, D.C., and Las Vegas.

The Data Distribution as a Service (DDaaS) platform is built to facilitate on-demand data distribution via broadcasting, supporting both NRT file delivery and streaming content applications in alignment with the ATSC 3.0 standard.

In this paper, we proposed AI solutions tailored for the OTA environment by leveraging the DDaaS platform and the MMT protocol. These solutions, along with continued technical advancements, offer broadcasters a path toward increased service flexibility and potential revenue growth through targeted advertising.

References

[1] ATSC: “ATSC Standard: Signaling, Delivery, Synchronization, and Error Protection,” Doc. A/331:2023-12.
[2] ISO/IEC: “Information technology – High efficiency coding and media delivery in heterogeneous environments – Part 1: MPEG media transport (MMT),” Doc. ISO/IEC 23008-1:2017(E).
[3] ATSC: “ATSC Standard: Application Event Delivery,” Doc. A/337:2023-03.
[4] ATSC: “ATSC Candidate Standard Working Draft: Revision of A/344:2023-05, ATSC 3.0 Interactive Content,” S38-479r6 15 December 2023
[5] ISO/IEC: “Information technology – Coding of audio-visual objects – Part 12: ISO base media file format,” Doc.  ISO/IEC  14496-12:2015, International Organization for Standardization/International Electrotechnical Commission, Geneva Switzerland.
[5] PearlTV News: https://pearltv.com/news/pearl-tv-adds-digital-monetization-capabilities-to-nextgen-tv/
[6] ANSI/SCTE 35 2019