The “5G Broadcast vs. ATSC 3.0” conversation is often framed as a binary choice: embrace 3GPP and abandon ATSC 3.0 or defend ATSC 3.0 as if mobile-first delivery is someone else’s problem. That framing is outdated — and it is needlessly slowing deployment.
ATSC 3.0 was designed from the beginning as an IP-native, one-to-many platform capable of delivering a wide variety of services to fixed, portable, and mobile receivers. In that sense, it is already the better “broadcast-IP” foundation. Meanwhile, 3GPP contributes a familiar mobile services vocabulary and a powerful toolchain for building applications and workflows that the wireless ecosystem understands.
We do not have to choose. We can put them together — now — because there is a documented, repeatable way to time-multiplex LTE-based 5G Broadcast payload windows inside an ATSC 3.0 RF channel while keeping primary ATSC 3.0 services intact.
ATSC 3.0 Was Built for Flexible IP Services, Including Mobile
ATSC 3.0 is not a “prettier TV” standard. It provides a service delivery architecture designed to support multiple service types and multiple receiver classes. That flexibility allows broadcasters to deliver — in the same RF channel — combinations of video, audio, files, software updates, map data, public safety objects, and enterprise payloads, with robustness tuned per service.
This matters because the datacasting opportunity is not limited to the living-room screen. The winning market is cross-device: vehicles, tablets, gateways, industrial IoT, digital signage, and yes, phones — wherever one-to-many economics and resilience beat unicast.
So, when someone says, “we need 5G Broadcast to get into the datacasting world,” the right response is: ATSC 3.0 already provides the broadcast downlink, and it was designed to carry IP services to fixed, portable, and mobile receivers at scale better than any other broadcast standard.
The path ahead is straightforward if one wishes: share a single RF channel in time. During one window, transmit a valid ATSC 3.0 frame. During another window, transmit the LTE-based 5G Broadcast waveform. Receivers on both sides see a predictable cadence. Coexistence is time sliced — not theoretical.
The sidebar below details the three engineering parameters that govern this scheduling — the challenge is coordination, not physics.
It means one RF channel is shared in time. The broadcaster schedules repeatable windows: ATSC 3.0 frames for primary services, and LTE-based 5G Broadcast windows for the secondary waveform.
Three knobs have to agree:
- 5G Broadcast CAS-muting cycle: the 5G Broadcast cell is instructed to stay quiet on its acquisition/control subframes for a programmed pattern, freeing time for ATSC.
- ATSC frame duration: set to a time-aligned duration (in 5 ms steps) so frames fit cleanly inside the inactive window.
- ATSC bootstrap min_time_to_next: select a “next-frame promise” value so it is at least the CAS cycle and absorbs drift between the 1 ms 3GPP grid and the ATSC cadence.
In other words: this is not “waiting for a future handset.” It is an RF scheduling problem with known controls, documented constraints, and field examples.
Mark Aitken
The Device Reality: ‘Chips in Phones’ for ATSC 3.0 Exist Today
A lot of the current rhetoric is framed as a race: which technology will reach commercial handheld devices first? That question misses something important: ATSC 3.0 demodulator chipsets optimized for handheld/mobile receivers exist today, including implementations coming out of the Saankhya Labs lineage (now Tejas Networks). They are designed to output IP streams and to fit within the size and power constraints of mobile and portable devices.
At ONE Media, we have worked across multiple vendors to design and build phones and tablets with what we shorthand as “chips in phones.” That phrase does not mean “a chip alone.” It means the full reception system: demodulator, RF front-end components (antenna, filter, LNA, matching), integration, and the software stack required to make reception a product feature — not a lab demo.
This is why the right question is not merely “will a 5G Broadcast modem appear in a system-on chip?” A baseband capability is not the same as a complete, properly enabled reception subsystem for broadcast bands. The phrase that matters is still “chips in phones” — meaning a whole receiver and antenna system that actually works.
What Really Holds Back the U.S —And Why India Can Unlock It
In the United States, getting any new receive feature into mainstream mobile devices is multifaceted. Three factors matter most:
A business proposition that drives commercial success (clear use cases, measurable value, repeatable revenue).
A business reason for mobile network operators (MNOs) to allow and support it. In practice, nothing significant lands in a U.S. carrier handset portfolio without their direction.
Sufficient success in the business proposition to drive a “bring your own device” pathway —where properly enabled devices enter the market via retail and enterprise channels, not only carrier certification.
This is exactly where the third condition—a BYOD pathway built on market-proven devices — makes India’s Direct-to-Mobile (D2M) trajectory so important. Success at real scale in a major market creates supply chain momentum: reference designs, manufacturing volume, and confidence that can spill into other regions — including the U.S. — via BYOD and enterprise procurement. If India normalizes “chips in phones” for ATSC 3.0-based D2M, it becomes much harder to argue that U.S. markets cannot follow.
A Constructive Plan to Get the Show on the Road
Some 5G Broadcast proponents privately admit their push is partly a hedge: "What if 5G Broadcast gets into phones first?" Hedging is rational—but it shouldn't freeze the deployed broadcast ecosystem while chasing a lengthy regulatory process: new waveform authorizations, service rule updates, contentious policy debates.
The subtext is often that broadcasters should adopt a new waveform while shedding the public interest obligations that historically justified broadcast spectrum. That's a non-starter. Expanding into datacasting should extend broadcasting's public-interest value — not escape it. Instead of debating which logo wins, align on a three-phase deployment plan that gives everyone wins:
- Phase 1 (now): Ship ATSC 3.0 datacasting outcomes at scale
Launch IP data services using existing ATSC 3.0 deployments. Pick two or three high-value use cases (software/firmware updates, map and data refresh, edge caching for streaming, public safety objects) and deliver them with clear APIs, security primitives, and measurable SLAs. Build the business case in-market. This is exactly what Edgebeam is doing — today! - Phase 2 (next): Publish a coexistence profile for “ATSC bearer + 5G Broadcast windows”
Define the scheduling profile (cycle lengths, allowable jitter budgets, configuration guardrails) and publish a simple interop test plan so transmitters, analyzers, and receivers can validate behavior consistently. This is how you turn “clever” into “deployable.” - Phase 3 (later): Expand handheld device pathways where they truly add value
Use India-led scale and proven business outcomes to expand “chips in phones” adoption, including BYOD and enterprise channels. Where MNO support is required, approach it with a demonstrated business case and a clear public-interest story — not hypotheticals.
Conclusion
The industry does not need another standards feud. It needs deployment, results, and visible wins. ATSC 3.0 was designed to carry IP services to fixed, portable, and mobile receivers — and mobile-grade ATSC 3.0 receiver subsystems exist today. At the same time, the technical path to carry LTE-based 5G Broadcast windows inside an ATSC 3.0 RF channel is now documented and repeatable.
So let’s stop debating hypotheticals, publish the coexistence profile, modernize the infrastructure where needed, and ship.
Mark Aitken is senior vice president at Sinclair Broadcast Group and President of ONE Media.
