The National Association of Broadcasters believes the FCC should allow software-based EAS and do it quickly. This spring the commission took comments from broadcasters and other alerting stakeholders.
The voluntary use of software alternatives would enhance EAS security and robustness, NAB believes. Encoding and decoding currently must be done by physical devices, based on rules written in 1995; NAB wants to see EAS “freed from this physical requirement and can instead, at a broadcaster’s discretion, reside elsewhere within a broadcaster’s plant, running on trusted and certified hardware platforms.”
NAB says the approach contemplates autonomous EAS functions at the edge of a broadcaster’s operation, as in other resilient and secure software systems in modern broadcast frameworks. A virtual implementation would be backwards-compatible to operation of EAS, and products brought to market would interoperate with legacy equipment.
Broadcasters would not be required to transition; if they would like to continue using the legacy approach, they could do so.
Supporters cite the industry’s experience with software that encodes for Nielsen’s PPM rating watermarking system, which now can be built into other products rather than requiring its own dedicated box.
A dissenting voice has been Digital Alert Systems, the sole active manufacturer of EAS encoder/decoder hardware. It advocates a hybrid virtual system that would require a device but bring the emergency alert process into the interconnected AoIP ecosystem. DAS urged the FCC not to rush its decision. It also says that modern EAS devices are technically superior to proposed software substitutes.
Both plans are “high-level architecture initiatives” that would have a major impact on broadcasters and how they fulfill their EAS obligations, one observer said.
Baseline functionality
Under NAB’s plan, broadcasters could choose to use discrete hardware, multi-purpose hardware or EAS as a software module, most likely running in another device or process critical to a radio, television or cable system’s transmissions. NAB has stressed that software-based products would have to function seamlessly within the EAS system and that baseline functionality must not be affected.
“In its simplest form this would be software running, perhaps in a virtual environment, on an appropriately provisioned and configured PC,” said Kelly Williams, VP of engineering and technical policy for NAB.
[Related: “NAB’s Roadmap for the FCC”]
“As such, this software-implemented EAS functionality would likely reside in the same place in a station’s air chain as it does now. That, of course, will vary based on how each station is designed.”
He said NAB has identified security, reliability and certification as important issues. It believes that software-based EAS is as secure — if not more secure — than a hardware-based EAS implementation. Stations will need to use the same level of enterprise-based cybersecurity as they do now, for example firewalls, passwords and access control, to protect their EAS apparatus.
“Further we believe that software-based EAS can be inherently more reliable because, currently if an EAS device fails typically it needs to be shipped back to the manufacturer for repair, potentially leaving a station without an EAS device for some period of time,” he told Radio World.
“With software, if there is a failure it can typically be fixed remotely, or if there is a hardware failure, another instance of the EAS software could be spun up on another PC.”
Certification would likely work much as it does now. “The software provider will self-certify that the application meets Part 11 and other applicable parts of the FCC rules,” he said.
One area of focus will be conformance with the Integrated Public Alert and Warning System. When IPAWS launched, FEMA created a process to test EAS equipment for connection to the system. According to Williams that process no longer exists.
“If FEMA wants to ensure that new EAS products meet those requirements, they will have to stand up a new conformance process.”
Virtualizing EAS may also put even more pressure on broadcast engineers to expand their IT and networking skills.
“But from an EAS operations perspective, nothing would functionally change,” Williams said. “The physical EAS box would simply be replaced by a PC running EAS software, so from the outside looking in, operationally, things would remain the same.”
Supporters also say that if EAS software is integrated into other existing vendor products, the burden of the architecture shifts to R&D experts rather than broadcast engineers in the field.
Numerous benefits
Other voices in the engineering community have been supportive of the proposal.
Steve Shultis, chief technology officer of New York Public Radio, has led EAS virtualization efforts in the NAB Radio Technology Committee (NABRTC). Its focus has been on benefits to public safety, though he says maintaining a homogenous, IP-based audio routing and control technical plant also would benefit broadcasters.
Software-based EAS, he said, would mean shorter recovery time in case of a failure thanks to automated, instantaneous fail-over of multiple instances of software configured for high availability and alerting staff.
The change also would allow “quicker system upgrades, modifications and updates through software rather than shipping hardware to the manufacturer for firmware/hardware changes or electromechanical repairs.”
He said the mean time between security patches would be reduced, as would the time needed to respond to vulnerabilities and exposures. Broadcasters also would have more flexibility to adjust their systems to keep pace with business or programming modernization initiatives.
Shultis credits the contributions of the NABRTC Next-Generation Architecture Working Group for its efforts on this topic. He said that broadcasters, using “tried-and-true technology and standards from the IT industry,” have created a broadcast plant and associated platforms running on resilient audio-over-IP infrastructure utilizing virtualized elements of the air chain — “all with interoperability between software systems: from play-out system, router, mixing and intercom platforms, to metadata services and audio processing,” he said.
“This infrastructure has proven to deliver much-improved operational readiness, flexibility and security to our broadcast elements, and it is clearly time to move EAS into this environment.”
Reduce complexities
Moving to software-based EAS would not change the EAS daisy chain; stations would still monitor local broadcast sources. No computing decisions would be made in the cloud.
Engineering consultant Alan Jurison, active in the NAB Radio Technology Committee and closely involved with software-based EAS discussions, says broadcasters hope to work with existing alerting vendors for “trusted solutions” to improve EAS.
“The industry is not asking for a free shareware version of EAS. We are not asking to go to a website for a free 30-day download for an evaluation — I think some are worried about that. No one in the process is looking to undermine EAS. Priority number one is security, and then maintaining what we have, or hopefully improving EAS in this country,” he said.
Jurison believes that EAS software, if approved by the FCC, would likely be built into the radio broadcast ecosystem in audio processors, transmitters and the AoIP infrastructure of studios. Similar parallels are contemplated for television and cable ecosystems.
Jurison believes that in “short order, software EAS will leapfrog the current hardware in place and allow it to move forward with other improvements.”
For instance, “No one has anything against multilingual messaging for EAS, but there is just no way to do it with 1995 technology. If EAS were software-based, you could easily put it just ahead of the audio or video encoding process, whether it is a legacy broadcast chain or something more modern, like ATSC 3.0 or even an internet stream,” he said.
“It would be super easy to configure one of the 13 languages on a program stream if you had a software model.”
Jurison says software-defined EAS has existed for years, as in a CAP-compliant software product from DAS that runs on Linux.
Supporters of the proposal say this approach has proven to be reliable but that the broadcast industry is now asking the commission to approve running the EAS software/process on more hardened, robust and redundant systems that exist in modern radio, television and cable ecosystems.
Sage Alerting last year stopped building new EAS hardware for broadcasters, citing supply chain constraints and legacy component obsolescence; it continues to provide support for devices in the field. Sage favors NAB’s petition and says if the FCC adopts the change, it would bring software-based EAS products to market.
“The reality is that the broadcast industry will continue to require its technical staff to accomplish more with fewer resources,” Sage President Harold Price told Radio World.
“This trend is driving a need to reduce integration complexities, including wiring, the overall number of hardware boxes, analog/digital format conversions and protocol compatibility.”
Urging caution
However, Digital Alert Systems has raised concerns about the NAB proposal, and it asked the FCC to take a cautious and deliberative approach.
In filed comments, DAS wrote: “While the goal of modernizing alerting infrastructure is a valid and worthwhile objective, we are concerned that this petition fails to take into account a substantial array of unresolved regulatory, procedural, cybersecurity, operational and intellectual property questions.” It said its concerns are foundational, not just about implementation details.
It would be “irresponsible to rush into a regulatory environment that lacks clear rules, exposes EAS participants to increased cyber risk and fails to address the operational burden on EAS participants.”
Chief among its concerns is cybersecurity. “There is currently no robust EAS cybersecurity standard tailored to EAS software platforms,” DAS wrote. It worries about denial-of-service attacks, spoofing and disinformation; it believes the FCC would need to partner with cybersecurity agencies to develop new compliance regimes involving encryption, authentication and incident reporting.
It also believes a software approach brings higher long-term costs for IT support, compliance and maintenance. Contrary to the arguments of supporters, DAS believes broadcasters would have to assume many EAS responsibilities now handled by hardware vendors.
It also raised concerns about “compromising the uniformity of EAS solution behavior,” of “creating asymmetrical certification and oversight regimes for EAS solutions,” and of complicating the FCC’s ability to conduct site visits or hardware-based testing.
DAS said the NAB petition does not adequately propose an alternative certification regime or consider the ramifications of having separate regimes for hardware- and software-based systems.
And it acknowledged that the proposal stands to be harmful to its business.
“Vendors of physical EAS devices — who have invested heavily in testing, FCC certification, cybersecurity, hardware validation and ongoing compliance updates — would find themselves disadvantaged relative to software developers who could bypass these obligations entirely,” it wrote.
DAS said it wants to collaborate with NAB and other stakeholders to modernize the EAS framework thoughtfully.
“We believe that modern EAS devices are not only technically superior to proposed software substitutes, but also cost-effective, widely available and supported by decades of commission oversight.”
Emotional debate
In subsequent reply comments to the FCC, the discussion grew more strident and emotional. The NAB criticized DAS as the lone naysayer and dissenting voice in its petition.
DAS dismissed NAB’s comments in its reply and said that NAB’s characterization of DAS as being the “lone, self-interested objector was unfortunate.” The company said this distracts from legitimate technical and operational concerns.
“Rather than engaging with the specifics of Digital Alert Systems’ questions, it was disappointing to see ad hominem insinuations about market motivation and attempts to dismiss critical input as obstructionist. This approach undermines a productive, and evidence-based policy,” DAS told the FCC.
Richard Rudman and Barry Mishkind of the Broadcast Warning Working Group sided with DAS and voiced concern in their comments about the risks of moving too quickly from the current EAS certification model without a replacement framework strategy that is well thought out and tested, based on a comprehensive software product certification process.
Rudman and Mishkind said they support innovation and agree with NAB and SBE that EAS must evolve, but they said this is not the time for a “Ready-Aim-Fire” approach.
“We urge the commission to reject the NAB petition in its current form and to initiate a broader, more deliberate proceeding — one that includes input from state EAS committees, broadcasters of all sizes, cybersecurity experts and manufacturers — before considering changes to Part 11.”
Read more comments and coverage from Radio World about this issue.
[Read a followup story on this topic with further comments from the participant.]
