Optimizing Dynamic Ad Insertion for ATSC 3.0 in Low Broadband Access Markets

Liam Power

Abstract –This paper builds on previous work presented at the 2024 NAB Broadcast Engineering and Information Technology (BEIT) conference, which explored Dynamic Ad Insertion (DAI) within the ATSC 3.0 framework using MPEG Media Transport (MMT) [1]. The current study extends this research by developing a robust broadcast-only transmission solution within encoder/packager systems to enable targeted ad delivery. The implementation supports precise control over ad breaks and allows for real-time event tracking by leveraging broadcaster applications, NRT data distribution, and DASH EventStream technologies. Additionally, this architecture integrates with mobile devices featuring local application storage, allowing for preloading and personalized selection of advertisements based on individual user preferences and service viewing history. Designed with the India D2M (Direct-to-Mobile) Project in mind, this paper examines the unique requirements and solutions developed to address an environment in which all ad distribution and decision logic must be completed in a broadcast-only system, with no guarantee of broadband access.

Introduction and Summary

In recent years, one of the key advantages for streaming video has been the ability for streaming services to insert advertising on a viewer-by-viewer basis, increasing the value of each avail by matching the profile of the viewer to the most relevant ad. Linear broadcast ads, on the other hand, have been limited to a ‘one size fits all’ method of delivery for the most part. It was therefore important for the ATSC 3.0 standard to meet or exceed this capability for broadcast television. This was particularly challenging for the implementation for India that is part of ONE Media Technologies’ Direct-to-Mobile(D2M) project, where we’re working to implement a broadcast offload system to alleviate the immense cellular congestion in the market, as traditional internet-based methods are not viable.

Over the course of this process, refinements were made not only to the broadcast workflow, but also to the base broadband methodology. This paper outlines the decision points, and the solutions developed:

• Section 1 presents an overview of DAI and the benefits to broadcasters.
• Section 2 looks at various options for implementing DAI within ATSC 3.0.
• Section 3 provides a description of the chosen workflow.
• Section 4 examines the limitations imposed by a broadcast-only model.
• Section 5 describes the solutions developed to handle the broadcast-only implementation.
• Section 6 lays out a series of future-facing optimizations to improve both broadband and broadcast DAI.

Section 1: DAI Overview and Benefits

Dynamic Ad Insertion (DAI) is a well-known concept, but this section will seek to familiarize the reader with the basics, as well as why it is relevant to a broadcaster. In a traditional linear ad sales model (depicted in Figure 1), ads are sold ahead of time in varying categories, which establishes a set of rules on what ads need to be aired at what time, in what order, and next to what content or ads. These rules are then used by the broadcaster’s traffic department to assemble the advertising logs for each day, normally set out the day before. This results in a fairly static set of spots, though programming variances on live shows can sometimes cause more or fewer spots to be aired than planned. These variances are in turn often handled by a series of rules, with replacement spot or spots cutting priority being laid out in advance, though some broadcasters, particularly cable sports broadcasters, have been known to simply provide the dollar value of each spot in the logs to allow the operator to make rapid judgments in the moment. Regardless of this, each spot is sold on and shown to all viewers, with some exceptions as noted below.

By contrast, dynamic ads on streaming video services are generally sold in the moment, with an ‘instant auction’ being held to determine which spot should air. This is often handled by an external marketplace, such as Google Ads, Magnite, or The Trade Desk to name a few. This is an almost fully automated system, with advertisers selecting budgets and audiences, then allowing the ad platform to handle the rest.

In this method, depicted in Figure 2, the stream contains an indicator of when an ad is available. These can take many forms, and some will be explored in the next section. Regardless of method, it allows the client, generally controlled by the streamer, to determine when an avail begins and ends. When this information is received, the application, be it a website or native app, reaches out to the ad server to request an ad, generally giving information on the viewer, the avail location, and the duration. The server in turn offers the block up on an ad exchange. The Demand Side Platforms (DSP) contain the rules for airing the ad, the advertiser’s budget for the campaign, and the ad content and metadata. The DSP uses this information to place bids for the block.

Once a winner is determined, the exchange then hands the ad back to the ad server, which in turn tells the client which ad to play. This whole process happens in a matter of milliseconds, ensuring a decision is made rapidly with no interruption to the viewer. [2]

While this is a drastically different approach from traditional broadcast sales, many broadcasters are already familiar with these methods. Digital, referring to website, social media presence, and other internet-based content from stations, has been rapidly growing across the industry, and is likely to continue doing so. Rather than linear feeds delivered in a unidirectional format, these are fully integrated content delivery systems with bidirectional feedback mechanisms. This has led to most broadcasters implementing some form of ad insertion system, particularly for first-party owned content not normally covered by broadcast ad sales deals.

One other crossover point that must be noted is cable headends. While not fully targeted on an individual basis, these have long been used to do ad insertion on a geographic basis, at varying resolutions. This allows a few key workflows:

• Local Weather: National channels like The Weather Channel will often insert local weather information in their graphics via a keyer at the cable headend, allowing the viewer to see information relevant to their specific area.
• Local News: While this practice has declined, national cable news networks have been known to splice in local news hits in partnership with stations in the area, similar to cut-ins on broadcast network news.
• Cable Ad Separation: Some MVPDs prefer to air different ads for their customers compared to non-customer viewers. This allows them to offer deals only to new customers, while advertising, for example, service upgrades to their current customers. This can happen at the station level, where the station handles the ad insertion and passes a separate feed to the MVPD, or in the MVPD infrastructure, where the station simply provides markers to allow the ad replacement.
• Despite the broader brush, many of the concepts used for the MVPD insertion mechanism can be reused in a broadcast insertion method, as will be explored in the next section. Indeed, vMVPDs such as YouTube TV have begun rolling out ad insertion on linear feeds to enable these streaming ad advantages on a more traditional content model.

Section 2: DAI Options in ATSC 3.0

The ATSC 3.0 standard provides a few options for handling ad insertion. There are distinct pros and cons to each, and so it is important to match the correct solution to a given use case. This section will provide an overview of some of the potential systems that can be used. These cases will focus solely on ROUTE/DASH streams.

XML Linking Language (XLink)

Historically, XLinks have seen the most discussion when it comes to ATSC 3.0 ad insertion solutions. In this mechanism, the broadcaster generates a DASH stream with an xlink:href attribute, generally assigned to a period. This is normally done at the beginning of an ad avail, with the encoder splicing the last segment before the avail to ensure a smooth transition. This creates the layout depicted in the sample media presentation description (MPD, acts like a playlist) in Figure 3.

There are two options when the end device receives this MPD as shown in Figure 4. In the event the xlink:href is pointing to some https location, the receiver can simply reach out as normal under the DASH spec [3] and retrieve the correct content to insert into the MPD at that point. If it has any other URI scheme, it is instead passed to a BA (Broadcaster Application) that has subscribed to the XLink notifications. [4] The BA then determines what content, either specific text or a full MPD, should be inserted at that location, and passes that information back to the receiver. This allows both online and offline ad insertion.

Regardless of which mechanism is utilized, the result is that the receiver is given a response with a new set of text. This will contain the playback information for the specific ad chosen for the client to air, essentially splicing in the period for the ad to the main MPD. The receiver then proceeds to continue through the timeline as normal, returning to the original broadcast content when it reaches the end of the ad period and hits the next linear broadcast period.

One major point in favor of XLinks is the ability for the receiver to resolve them locally, without BA involvement, by using https-based XLinks. This simplifies the process from the broadcaster perspective and means that if a receiver does not support the interactive environment, ad insertion still works. However, XLinks are not as flexible as Events (see DASH Events), require more complex receiver action, and most importantly, are in the process of being removed.

Out of Band Broadcaster Application Insertion

In this method, the broadcaster plays an ad via the BA at a specific time via the Application Media Player (AMP). This is the least elegant of the options described here, as the timing is virtually impossible to align due to the varying nature of reception. Receiver-side delays, such as different player implementations and segment reception times, coupled with delays in the airchain, mean receivers will generally be off by at least several seconds from each other.

However, the method is worth noting as it eliminates any dependency on interaction with the receiver aside from implementing the interactive environment.

DASH Events

The DASH specification defines an EventStream element [5], which essentially form the DASH version of the SCTE [6] markers common to the Serial Digital Interface (SDI) and Transport Stream (TS) worlds. Events signal the time and duration of various data to the receiver. The use cases for events are quite broad; for ad insertion, they contain the full set of information from a SCTE marker, as well as the relative timing within the MPD timeline.

This workflow will be explored more fully in the next section, but one key item is the use of the AMP vs the Receiver Media Player (RMP). Because the AMP is controlled by the BA, it is very difficult to synchronize the insertion with the actual timeline on the receiver, despite the event notification containing the current and event times. This is due to variances in processing time causing potential offsets thus reducing the chance for a frame accurate insertion.

The RMP method, on the other hand, uses time marks relative to the RMP timeline. Assuming the receiver has correctly implemented the relevant APIs, it can seamlessly jump to the ad and back without misplacing the ad in either direction. This also allows the ad to take full advantage of the RMP’s playback hardware, as not all receivers provide the same decode options to the AMP as they do to the RMP. For this reason, the preference is towards the RMP for ad insertion.

Overall, the Event workflow allows for the best accuracy in insertion with the least complexity on the receiver side. It also maintains the flexibility of SCTE markers, which is advantageous for non-insertion use cases. The spec is fully fleshed out, and well implemented by many receivers, as will be explored in Section 6. The primary downside is that it requires the BA to handle the insertion logic, which means the receiver must implement the interactive environment and the relevant APIs.

Section 3: Connected EventStream Workflow

The best path forward, therefore, is to handle ad insertion with a combination of EventStreams and the RMP workflow. The following outlines this implementation in a connected device environment as depicted in Figure 5. This will form the basis for the implementation of the more complex broadcast implementation covered in section 5.

Transmission Requirements

The first step in any insertion process is to figure out when the ads can be inserted. This is best accomplished at the playout/automation stage, as the master control automation can generate the markers at the precise time the spot begins or ends. This allows the broadcaster to tag each break with the time of the break, the duration of the break, and an ID to allow the ad server to associate the break with a request on the receiver side. The automation system then adds this information, along with other optional functionality, to a SCTE 35 or 104 marker [7], depending on whether the video is being carried via a TS [8] (TS) or SDI [9] transport.

In ATSC 1.0, the SCTE marker would be carried unmodified into the TS stream used for the actual broadcast. However, ATSC 3.0 utilizes more advanced transports in the form of ROUTE/DASH and MMTP, so the markers must be translated into an appropriate format. This paper is focused solely on ROUTE/DASH-based DAI, and so will not discuss the MMTP format, but more detail on this can be found in the paper Dynamic Ad Insertion Using a Data Distribution as a Service Platform and MPEG Media Transport [10] from the 2024 NAB BEIT Conference.

As mentioned earlier, the DASH spec contains an element called ”EventStream.” [5] This comes in two forms: inband, and MPD-based events. Inband events can be found in the emsg box, with an InbandEventStream element in the MPD to indicate which representation contains the emsg box, while MPD-based events are located fully within the EventStream element in a Period of an MPD. Inband events are best used for unexpected events that require immediate action, such as rolling a news cut-in during a live network program and bringing the BA up for the duration of that cut-in.

For ad insertion, the receiver needs enough time to buffer the ad media before the break to ensure a smooth and frame-accurate transition in and out of the inserted ad. MPD-based events are therefore easier to execute in this situation. To achieve this, the encoder doing the DASH packaging must read the SCTE markers on the input, noting the time on each one to ensure the time is maintained relative to the new DASH timeline. It must then splice the segment at the indicated time and generate a new period with a new timeline beginning with the second half of the spliced segment. This ensures a complete Group of Pictures (GOP) at the start of each Period, which is critical to allowing the player to switch between two distinct streams with no interruptions. Without this, it would need to wait for the next I-frame when resuming the live broadcast after an ad, which would lead to some amount of black video. Figure 6 shows an example of segment splicing for event periods.

Once the splicing is completed, the packager must then generate the corresponding MPD for these segments. Each new avail, indicated in the source feed by the SCTE splice_insert markers, generates a new period in the MPD. So, in a workflow where the feed is going program-break-program, with the break listed as one large avail, the MPD would initially have a single period. Around three to ten seconds before the break, the input would receive the first of the SCTE markers. This could either be an open-ended avail with no duration signaled, indicating no specific time to return, as is sometimes seen in live events, or a fixed duration avail, which is common in a broadcast station running fixed ad breaks. In either case, the packager would generate an early available period in the MPD [11]. This is a period that has no segments but indicates that there will be a period in the future. In our case, this period also contains the EventStream element, allowing the receiver to begin processing the event before it comes up in the timeline.

This element has several key attributes:

• presentationTimeOffset: Present in the individual events (non-offset) and the EventStream (offset), this indicates the time within the period that the event occurs. For example, if the event has a PTO of 1100, and the EventStream’s PT is 1000, then the event would occur 100 timescale units into the period.
• schemeIdUri: This identifies the scheme used for the events. The majority of events will be urn:scte:scte35:2013:xml or urn:scte:scte35:2014:xml+bin, but there is a provision in the ATSC spec for the use of custom URIs [12].
• value: This optional attribute allows the receiver to distinguish between events when the BA subscribes to specific values, as described in the BA workflow later in this section.

The EventStream element in turn has several child elements, named Event, which identify the individual events within the element. These events again have a series of attributes to enable the timing:

• presentationTime: This is used as described in the PTO section of EventStream.
• duration: This is optional and not present in open-ended avails. It indicates the expected time of the avail to allow the ad decision server to put together a playlist of appropriate length. This can be modified in later MPD updates if, for example, the program needs to come back early.
• id: This indicates an identifier within the URI and value. The id is most useful as a transfer from the SCTE marker. In this way, the ad logic on the receiver side can determine which ad break is upcoming, as it has a record of the IDs and their corresponding breaks available.
• Data: Within the Event element, the packager can insert arbitrary data in XML form. In the urn:scte:scte35:2014:xml+bin scheme, this is utilized to place the full body of the SCTE marker in base64 encoding within the event, giving 1:1 parity on SCTE features to DASH events.
• At this point, the DASH stream now has a properly spliced set of representations, along with events to indicate the timing and reasoning for each splice. The transmit side must now feed the DASH stream into the ROUTE encapsulator, add the appropriate signaling, and bundle it all into an ATSC 3.0 transmission. Everything after the DASH packager is simply passing along the stream unmodified.

Receiver Requirements

The receiver must now process the essence and signaling, then communicate to and from the BA using the standard interactive content APIs. The core function revolves around two sets of APIs: those pertaining to the events, and those pertaining to changing the RMP source.

When receiving a DASH service, the receiver is expected to monitor the MPDs for new events whenever the MPD version changes. The new events can be supplied not only by the DASH items described above, but also by methods like video watermarking [13] or out-of-band delivery. MPD-based DASH events are the only ones relevant for this DAI workflow (see Figure 7).

When the receiver spots an event, it notes the listed attributes and calculates the current time and the time the event will occur relative to the current media presentation timeline. It then sends a notification to any BA subscribed to events with a matching schemeIdUri and optionally a matching value. The notification contains the currentTime and the eventTime. The BA can now calculate the time until the event and tell the receiver to execute an action relative to the eventTime with a high degree of precision. It also provides the id and duration attributes, and any data contained within the element.

The BA will then process this notification, as explored in the next subsection. At some point between the notification and event, if the BA chooses to insert an ad, it will make a Set RMP URL call to the receiver. There are several operations allowed in this call, but for the purposes of ad insertion, only startRmp and resumeService are necessary. In the initial call, the BA will utilize startRmp, with rmpSyncTime set to the eventTime from the prior notification. This tells the receiver to, at the time the event is set for, switch the Receiver Media Player (RMP) to an alternative MPD with a given URI. This is the critical component for frame accuracy, as the event is placed at the precise time on the timeline where the splice occurs. This provides a dramatic improvement over systems that utilize wall-clock time, as the time remains consistently expressed in terms of the timeline on the player, regardless of how far off the internal time may be. It also means that precise timing on the BA call is unnecessary, as the RMP change is set to a fixed time on the timeline, rather than one relative to the current time.

Ideally, the receiver begins buffering the MPD ahead of the eventTime to ensure a smooth transition with no black sections. If the MPD has not been buffered, it can cause brief interruptions while the receiver acquires the MPD and segments. This can lead to a viewer missing the beginning of the next program block, an unacceptable result for all parties. In the event the receiver does not buffer, however, there is an alternative approach that is explored in Section 6.

In a normal situation, the receiver would play through the presentation referred to by the new MPD, and upon reaching the end, return to the primary MPD by default. However, breaks may end early or otherwise be interrupted. In this scenario, the BA may choose to cut out of the ad early rather than cover programming with a spot. To do so, the BA makes a Set RMP URL call, but instead of specifying a URI and using the startRmp operation, it uses the resumeService operation with no rmpurl. The time is either left empty to immediately resume, or the time is specified to resume based on the time in the event indicating the break is ending early.

The receiver must also supply information on the device and user and confirm an ad has successfully run. The former is accomplished using the Query Device Info API, which provides the deviceId and advertisingId of the receiver to the BA. This allows the BA to associate the receiver with a given profile of a viewer for ad decisioning.

The confirmation that an ad has run is handled using the RMP Media Time Change Notification. When the BA is subscribed, it receives a notification any time the player time changes. This occurs when the Set RMP URL API is used, as the timeline in the ad will be different to that of the main service. The BA knows the notification is caused by the player beginning playback of the ad, and later resuming the main service on completion, because of the ‘source’ section of the API.

Broadcaster Application Requirements

In the model described in this section, where an internet connection is available, the BA has a lighter workload, as many of the responsibilities described in the next two sections are offloaded to remote servers.

When the BA launches via the HELD upon the user selecting the relevant service, the first thing it must do is subscribe to the relevant notifications: events and RMP media time changes, both described above. It should also query the device info to retrieve the two relevant IDs to reduce the delay when it comes time to request an ad from the decision server (see Figure 8). With these tasks accomplished, it can then wait for an event to come through.

When an event indicating an avail does come through, the BA should immediately hand off the advertisingId, avail ID, and duration to the ad decision server to request an ad. The server uses the avail ID to determine what rules should be applied based on the surrounding content. This avoids situations like duplicate spots airing adjacent to each other. The advertisingId, meanwhile, is associated with prior data gathered on the user to enhance the ad selection process. Based on these three items, the server puts together the ad or ads to be aired during the avail, and hands the URL(s) back to the BA, potentially including a callback URL to indicate whether the ad successfully aired. The BA in turn makes the calls noted in the preceding section to begin playback of these ads.

The receiver section covered the case of a single ad, but as noted above, there can be multiple ads in a single block, particularly if breaks are being signaled as one large break. Luckily, this is handled through a slightly different usage of the SetRMPURL API. Rather than setting the rmpSyncTime to nothing or a specific time, it can instead be set to -1.0, which tells the receiver to execute the action upon completion of the current media presentation. Only one call can be queued at a time, however, so it is important to wait until the preceding presentation has begun before calling the next startRmp. This is achieved using the time change notification mentioned earlier, as it triggers just as easily going between ad presentations, as it does going from program to ad and back. The sequence of events can be seen in Figure 9.

• Once the receiver has handed off the URL(s) to the receivers, it listens for the time change notifications and notifies the ad decision server’s API whether the ad has successfully run. And with that, there is a fully functional connected device insertion.

Section 4: Broadcast-Only Reasons and Restrictions

While the combination of functions is relatively new, the system described above is fairly simple to put together with standard-based ”building blocks,” leaning primarily on the existing ad infrastructure used in streaming. This works well in markets like the US or Korea, where broadband access and connected devices are common. In a market such as India, however, this gets more complicated. One of the primary reasons for the push towards ATSC 3.0 in India is the lack of reliable internet access, with many users reliant on mobile data to connect. The availability of mobile data in particular varies wildly in standards, speed, and access. Over 20% of mobile phone users in India have feature phones, and of those, over 75% are still 2G based [14].

As part of our overall Direct-to-Mobile(D2M) effort in India, one of the core features was linear services on mobile devices with ad insertion and minimal internet usage. The goal is to increase efficiency by offloading as much common data as possible to broadcast delivery, while maintaining a minimal internet backchannel that does not require constant availability.

This results in the following restrictions compared to the connected device scenario:

• Ads cannot be retrieved from an external server, and so must be delivered via broadcast
• Ad decision logic must be local to the receiver
• No immediate feedback mechanism for ad reporting is available due to inconsistent internet availability

Section 5: Broadcast-Only Solutions

This section will cover each of the restrictions individually, and explore the solutions devised for each of them.

Locally Sourced Ad Media

The ad media is the most internet intensive component of the broadband solution, as the receiver is effectively streaming the ad for the duration of the spot. This is due to the individualized nature of targeted advertising, which in a US-style broadband environment, makes it preferable to save the broadcast bits for other items. However, when broadband is less reliably present, that equation shifts back towards broadcast.

Other solutions have explored the usage of parallel advertising, in which multiple ads are transmitted simultaneously during a given ad break, with the receiver switching between multiple MPDs to choose the preferred ad for the viewer. While this makes synchronization easier, it negatively affects broadcast efficiency for two reasons.

First, if an ad is going to be reused, it is sent multiple times, once in each break. In the first airing, it requires the same number of bits as a Non-Real Time (NRT) solution. However, each subsequent break will double, then triple etc. the number of bits required by the parallel solution. The receiver could cache the ads after they’re received, but that loses the timing advantage over the NRT solution.

Second, broadcasts have a fixed number of bits available in a time unit. Therefore, when real time delivery is required, the transmission of the ad media can’t simply be averaged over a long period. Instead, it must utilize the live bitrate of the media. Broadcasters max out their PLP payloads, so there isn’t normally bitrate available for the additional video bitrate necessitated by the ad. Workarounds like running the ads at a lower bitrate or using a dynamic spectrum allocation tool [15] run into issues if multiple services go to a break simultaneously.

Instead, the best option is to deliver the ads as NRT files. This means sending the media in a bundle in advance, ideally during non-peak hours when more spectrum is available. Because this media is not critical to the user experience, as the service can always fall back to the linear feed, it does not need to be sent 24/7, which reaps significant savings in bit consumption over the parallel approach.

One downside, however, is storage usage. Caching every possible ad can get quite unwieldy, particularly in a model where the phone is designed to act as a nano-CDN for other applications, which means local storage can become a premium. Luckily, there are a few workarounds to avoid this:

First, proper signaling. The ATSC 3.0 spec includes an optional ‘validUntil’ [16] attribute for individual files within a package. This enables the receiver to discard the files when no longer needed, reducing the cache load. For example, if the broadcaster knows an ad campaign will only run through a given date, they can signal the validUntil for that date.

Second, the use of filter codes [17]. These are a set of identifiers unique within a single appContextId which can be used to filter files by relevancy. Once the application has built a user profile, it requests the receiver to only retrieve files matching the filter codes, which correspond to ads relevant to the viewer. For example, if the viewer consistently watches cooking shows, cricket matches, and soap operas, the BA selects the filter codes corresponding to kitchen tools, sports memorabilia, and soap opera promos. Filter codes are 32-bit unsigned integers, so it is easy to get as granular as desired in the selection of ads. These workarounds ensure a slim cache while keeping relevant ads available, all with a minimum of spectrum usage.

Scheduling is also key, as a tuner shouldn’t constantly remain tuned to receive ad media, particularly on battery-dependent mobile devices where every watt counts. Fortunately, the Distribution Window Description (DWD) table within the Service Layer Signaling (SLS) contains the start date, end date and time for each file transmission, as well as a label to distinguish duplicates, the AppContextId and filter codes for each file. The DWD is analogous to the Electronic Service Guide (ESG) but for file delivery [18]. Using this table, the receiver can tune to the signal at the scheduled time and cease tuning once the file is received. The filter codes ensures only relevant files are received.

Offline Ad Decision Logic

The ad decision logic is the next piece of the puzzle. We can run the logic wholly within a lightweight BA using the typical ad insertion workflow described in Section 3. Our goal for the pilot in India was to prove the concept, so the actual user data and ad categories were limited, as were the rules for airing the spots. However, there is no reason this same methodology would not apply to a full production system.

We initially explored using filter codes to communicate all of a file’s metadata, but this became unwieldy as we began to add more detail to each piece of ad media. Instead, we created a separate ad manifest containing the metadata for each piece of content available on the broadcast. This allowed the logic engine to determine which files should be downloaded off the air and to build ad playlists using the rules described in the manifest.

Some key attributes are as follows:

• advertiserId: Identifies the advertiser, e.g. Bob’s Discount Cars, or Coca-Pepsi.
• advertisementNo: A unique identifier for an individual spot.
• duration: Length in seconds of spot.
• languageID: Identifies the language used in the ad to ensure the viewer can understand it.
• genre: One or more genres the advertisement is relevant too, e.g. news, movies, music, sports, travel, shopping, or finance.
• presentationImpressionNumber: Indicates the maximum number of times an ad can be played on a given device, with 0 indicating no limit.
• forceDeliver: Overrides all other rules to air a spot for a given genre, with the repeat number indicating how many times.

The file is transmitted as part of the BA and updated with new ads via the validFrom field to indicate when a new version is available. Once the BA has the manifest file, it calls the relevant APIs to set the filter codes, then checks for upcoming media via the DWD.

The workflow for the event processing is then virtually identical to the connected method (see Figure 13). Some key differences are as follows:

• The rmpUrl points to an MPD inside the Application Context Cache, rather than an internet one, corresponding to the chosen ad.
• The BA must check what ads are available in the cache before choosing one, as receivers can discard files from the cache at will.
• The decision logic is done according to the manifest rules, rather than calling the decision server API.
• Precaching, explored in Section 6, is unnecessary, as the files are already in the cache.

Inconsistent Feedback Mechanism

• The whole purpose of dynamic ad insertion is to increase the value of each spot. However, much like a tree in the forest, if a targeted ad airs but no one knows about it, how does the broadcaster get paid? This is the problem with the inconsistent return channel and the lack of internet-delivered ad media. With a connected device, the BA can send a message to the ad server to indicate an ad was successfully run, and the advertiser knows a device accessed the ad from their server at a specific time. With a disconnected device, both of those options are gone. The solution was to accumulate a record of the ad airings and send them in bulk the next time the device connects to the internet. This, of course, has high potential for fraud, so this component needs the most additional work, as will be seen in the next section.

Section 6: Future Plans and Optimizations

Now that we’ve proven out the core functions of this methodology, for both connected and low-connectivity markets, we can begin to optimize and advance the system with the following refinements:

Preloading Content

In the connected model, there is a danger the receiver may wait until the syncTime to begin buffering the segments. This would result in delays entering and exiting the avail, causing black at the start and overlap at the end. Ideally, receivers would simply begin buffering upon receiving the Set RMP call, but this cannot be guaranteed. Luckily, the cache request API can be used specifically for this situation. The API allows the BA to cache the necessary segments from a DASH MPD.

Under this model, the BA processes the event like normal, but instead of directly setting the URL in the Set RMP call, it calls the cache request API repeatedly until it confirms that all files are in cache. Once this is received, the BA would call Set RMP and point to the local MPD instead of the remote one. This should enable near perfect frame accuracy regardless of the receiver’s buffer model, as it will instantly have the full MPD available.

Common Data Services

Currently, files intended for a BA are transmitted alongside each service. This leads to inefficiencies in distribution, as multiple services will likely be consuming the same ad media. Unfortunately, no default tune service for files exists the way it does for service information via the ESG. The new Data Service category fulfills the role well for private file distribution, but it’s specifically intended to be ignored by receivers that do not know the group service identifier (GSID). A “common service” intended for files consumed by multiple services would address this. The Common Data Service would eliminate duplicate files, with backwards compatibility maintained via signaling the file transmissions in each service for those receivers that don’t update to the new category.

Ad Skipping

One potential danger of providing a receiver with each ad’s start and end times is it enables DVRs to easily skip past all the ads in a recorded broadcast. While this is a narrow case, particularly as most DVRs are very capable when it comes to automatic commercial detection, it is a topic worth exploring in future modifications. There may be some form of obfuscation that can be used to raise the bar above the lowest hanging fruit.

Receiver Support

While the APIs in question are part of the NextGenTV logo suite, that does not necessarily guarantee all receivers will behave the same way. Initial testing has been done to validate the presence of the APIs and the viability of the workflow, as can be seen in Table 1, with the manufacturer names altered for confidentiality reasons.

Receiver	Multiperiod	Event Subscribe	Event Notification	Time Change	startRMP	resumeService	Device Info
Receiver 1	Y	Y	Y[1]	Y	Y	Y	Y
Receiver 2	Y	Y	Y1	Y	Y	Y	Y
Receiver 3	Y	Y	Y	Y	Y	Y	Y
Receiver 4	Y	N/A[2]	N/A2	N/A2	N/A2	N/A2	N/A2
Receiver 5	N	Y	N[3]	Y	Y	Y	Y
Receiver 6	Y	Y	Y	Y	Y	Y	Y
Receiver 7	Y	N/A[4]	N/A4	N/A4	N/A4	N/A4	N/A4
Receiver 8	Y	N/A4	N/A4	N/A4	N/A4	N/A4	N/A4

Additionally, we’ve validated the timing possibilities with our in-house receiver stack, using a test system with a series of countdown timers, as shown in the sequence in Figure 14.

While not all receivers are fully up-to-snuff, the testing has given us confidence that the average receiver should be able to achieve this. Luckily, failure simply means the insertion does not occur and the linear feed will play as normal. The only exception is Receiver 5, which does not support multi-period video, and so will require a fix before deployment.

Codecs are another concern as not all RMPs support the same codecs, including many common ones used in streaming. Audio has been a particularly mixed bag historically. The ingest workflow for ads will be key to ensure the viewer does not experience silent audio or video due to poor media choice. This, however, is a user-by-user issue, so codec requirements can be set in the BA on a per-model basis, allowing the BA to choose not to air an ad with an unsupported codec. Fortunately, this is a situation that has improved over the years, as the table in Figure 15 showing the results of various codecs in the RMPs of common receivers.

Receiver	HEVC	AVC	AC-4	EAC-3	AC-3	LC-AAC
Receiver 1	Y	Y	Y	Y	Y	Y
Receiver 2	Y	Y	Y	Y	Y	Y
Receiver 3	Y	Y	Y	Y	Y	Y
Receiver 5	Y	Y	Y	Y	Y	Y
Receiver 7	Y	Y	Y	Y	Y	Y

Conclusion

We believe this solution is the most viable method for both connected and broadcast-only ad insertion. It avoids problems discovered in previous solutions, while adding additional functionality, including for non-content replacement-based use cases. It also makes use of long-established standards and APIs that are well-supported on all but a few receivers. We plan to continue testing out each aspect of this system to ensure full viability, both in our lab and at interoperability events throughout the year.

References

---

• Kim, S. “Dynamic Ad Insertion through [Data Distribution as a Service System (DDaaS) – MMT Protocol – Broadcast Application] without Internet Connection,” BEITC Proceedings, No. 2024.
• Yuan, Shuai. Wang, Jun. Zhao, Xiaoxue. “Real-time Bidding for Online Advertising: Measurement and Analysis,” ADKDD ’13: Proceedings of the Seventh International Workshop on Data Mining for Online Advertising, No. 3, August 11, 2013, pp. 1-8.
•  “Information technology – Dynamic adaptive streaming over HTTP (DASH),” ISO-IEC 23009-1:2022(E), p.108-110.
• “ATSC Standard: ATSC 3.0 Interactive Content,” A/344:2024-04, 3 April 2024, pp. 162-167.
• “Information technology – Dynamic adaptive streaming over HTTP (DASH),” ISO-IEC 23009-1:2022(E), p.135-146.
• “Digital Program Insertion Cueing Message,” ANSI/SCTE 35 2023r1.
• “Automation System to Compression System Communications Applications Program Interface (API),” ANSI/SCTE 104 2023.
• “Information technology – Generic coding of moving pictures and associated audio information – Part 1: Systems,” ISO/IEC DIS 13818-1.
• “3 Gb/s Signal/Data Serial Interface,” SMPTE 424M-2006.
• “MPEG media transport (MMT),” ISO/IEC 23008-1:2023.
• “Dynamic adaptive streaming over HTTP (DASH),” ISO-IEC 23009-1:2022(E), p.34.
• “ATSC Standard: Application Event Delivery,” A/337:2024-04, 3 April 2024, p. 5.
• “ATSC Standard: Video Watermark Emission,” A/335:2024-04, 3 April 2024.
• Counterpoint Research, “India Smartphone Market Share: Quarterly,” 25 Nov 2024.
• Hottinger, N. “Optimizing ATSC 3.0 Spectrum Utilization with Dynamic Resource Allocation and Management,” Proceedings of the 2025 NAB Broadcast Engineering and Information Technology Conference, April 2025
• “ATSC Standard: ATSC 3.0 Interactive Content,” A/344:2024-04, 3 April 2024, pp. 23-24.
• “ATSC Standard: Signaling, Delivery, Synchronization, and Error Protection,” A/331:2024-04, pp. 155-156.
• “ATSC Standard: Signaling, Delivery, Synchronization, and Error Protection,” A/331:2024-04, pp. 73-77.

Acknowledgments

• Nick Hottinger, Sangsu Kim, and the ONE Media Lab for their support and advice
• Viktor Matiash and the Middleware group for their able work on the proof-of-concept receiver
• Sanjay Yadav and Saankhya Labs for their efforts in the D2M project
• Mike Dolan of Pearl for his assistance with alternate content replacement methods

---

[1] The core event notification functionality is present, but with some bugs that require adaptations on the transmit side.

[2] The BA fails to run the Javascript, instead only displaying the HTML, which causes the other tests to fail. This appears to be due to a BAAppear implementation.  

[3] Event notifications are unable to be tested without multi-period support in our implementation, making this an automatic fail.

[4] Receiver does not implement A/344.