This is the third in a series about proposals by the Federal Communications Commission to improve the Emergency Alert System and Wireless Emergency Alerts.
Part 1: “Polygons and Circles: FCC Seeks to ‘Incentivize’ EAS”
Part 2: “FCC Explores EAS Message Authentication”
The commission is taking public comments on its further notice of proposed rulemaking, or FNPRM, through Aug. 31. These changes would be on top of the recently enacted new cybersecurity rules involving passwords, software updates and firewalls.
One of the most notable proposed changes would allow EAS participants, including radio and TV stations, to use software-based encoder/decoder technology instead of a dedicated hardware box to process EAS alerts.
The commission devotes 14 pages and around 6,600 words just to this issue.
The National Association of Broadcasters had asked the FCC to open a rulemaking to permit software. The FCC now has agreed to explore the idea officially.
“EAS still depends heavily on standalone hardware located outside the core processing systems that broadcast, cable and satellite services now use daily,” it wrote, adding that some requirements are based on outdated assumptions, so a review is appropriate as the industry shifts toward IP‑centric architectures.
A software approach could reduce burdens on participants, supporters say. It could encourage streamlined operations, improve remote maintenance and control, and increase security.
Hardware‑based EAS can present significant repair delays and reliability challenges, the FCC noted.
The Society of Broadcast Engineers told the FCC that when equipment malfunctions, “stations often have to locate, schedule and deploy a contract engineer to physically diagnose and repair the malfunction,” and a box may have to be shipped back to the manufacturer.
Software could facilitate repairs and updates, eliminate single points of failure through multiple instances of software in diverse locations, and facilitate routing and targeting.
Moving ahead
There were some voices urging against opening this proceeding. The FCC devoted several paragraphs to explaining why it didn’t agree.
Specifically, manufacturer Digital Alert Systems said the NAB had provided no details about how software-based systems would be verified, authorized or audited for compliance. It said the FCC has no process for certifying EAS software, and that cybersecurity is a real concern.
The commission acknowledged the arguments but said its proceeding can address such issues.
It also rejected DAS’s argument that NAB’s proposal “may confer greater relative benefits on radio broadcasters — particularly those with simpler technical operations — than on television or cable operators, which already rely heavily on integrated, IP-capable workflows.”
The FCC said the possibility that some participants might be able to implement a software approach more easily is not grounds for not considering the idea.
Further, the FCC said, software-performed EAS might enable “an immediate fail-over of functionality” to backup EAS software in other locations. This could boost the effectiveness of EAS when broadcasters are forced to abandon their physical facilities during emergencies.
The commission asked for comment on this “automatic failover” benefit, which NAB has said would help “when the public needs emergency messaging the most.”
Implementing EAS software
Overall the FCC said it heard broad support for EAS in software, including from the Society of Broadcast Engineers.
Among other things, SBE pointed out that some stations use dedicated hardware that is no longer being manufactured, so a software approach would be a “potential lifeline.”
The commission anticipates that software would be adaptable and could help drive the adoption of advanced alerting capabilities.
It wants to know whether there are aspects of using software that would help stations and other participants to voluntarily analyze and process audio/visual messages, photos, maps or other information in a CAP EAS alert.
“Would software EAS be adept at performing geotargeting calculations, text-to-speech, speech-to-text or other alerting functions?” it asked.
“Would EAS software be capable of generating or passing through CAP alerts over secondary channels or subcarriers for consumption by end-user devices capable of processing them? Are there any specific functions that EAS software could provide that are not available to EAS hardware devices and would be particularly beneficial to alert originators?”
The FCC also proposes to allow participants to install software in a single server or computer that manages EAS functions. Alternatively, it could allow software to be installed across multiple components within a system, enabling integration of different EAS functions across multiple system components.
It thinks this flexibility could make compliance easier and spur innovation in alert capabilities. For instance, manufacturers of transmitters and cable equipment could integrate encoder/decoder software into their products. Again it wants to hear back about these assumptions.
But the FCC said it wants to balance these goals with the need to ensure reliability.
It heard from alert originators about the importance of ensuring delivery and of redundancy. For that reason the FCC proposes to require that the software, however it is integrated, be located at the local facility used to provide service.
For a broadcaster this would mean that EAS software would be required to be installed at the studio or transmitter site.
In turn this would preclude EAS from being generated in cloud-based systems.
The FCC expressed concerns about the resilience of such IP-based connections for alerting. A reliance on IP networks “could cause EAS participants to be cut off from their EAS capabilities during emergencies that involve power outages or infrastructure damage, which are types of emergencies for which EAS has historically demonstrated to be useful.”
It believes emergency planning should assume that commercial IP traffic and communications are unavailable in a wide area, and it added that the NAB has not asked for an “off-premises,” cloud-based approach.
The FCC invited comment on all this thinking and also asked if there are other locations at which it should permit the use of EAS software.
For instance, “If we allow these kinds of network designs that require EAS software to be located at the transmitter as the fail-over location, should we also require that monitored sources be received at the same location so they also avoid being blocked by inoperable IP connections?”
Market factors
Some filers in earlier comments mentioned market considerations.
The NAB pointed out that Sage Alerting Systems, one of two remaining device vendors, has ceased production of its device “due in large part to supply-chain problems acquiring legacy parts for original EAS hardware-only designs.”
Cox Media Group (CMG) told the FCC that any supply chain issues are only likely to get worse. It asked what would happen “if the last vendor can no longer manufacture the required device or if a repair backlog results in communities missing crucial EAS messages.”
CMG said the FCC “should not force broadcasters to rely on one vendor to provide EAS service.”
However, Digital Alert Systems, the other device vendor, argued that NAB’s “inferred focus on [Sage’s] specific legacy technology should not be taken to suggest a broader industry challenge, whether that be in terms of supply chain, product availability or capabilities to serve modern advanced air chain requirements.”
DAS argued that modern encoder/decoder systems have adapted to the requirements of contemporary broadcast facilities “and do not face the same integration challenges that may affect older or end-of-life devices.”
It said that if participants “are encountering operational friction due to outdated EAS infrastructure or legacy EAS workflows, that should be addressed through narrowly tailored policy mechanisms — such as limited waivers, technical guidance or updates to certification criteria — rather than a sweeping rule change.”
In the absence of continuing demand for hardware, DAS told the FCC, “manufacturers may redirect their resources away from research and development for physical equipment,” thus potentially “stifling innovation in areas such as hardware security, system resilience and compatibility with new standards.”
The FCC didn’t comment on those arguments but it asked for public comment on them, and on whether software would be affected by supply chain shortages and what the impact on the market for EAS solutions would be of its proposals.
It noted that its equipment certification proposals “are intended to ensure regulatory parity between EAS software and stand-alone EAS encoder/decoder devices.”
The commission also asked whether elements of EAS software functionality are patented, and who holds them.
DAS told the FCC that it has been “made aware of several published patents and provisional patents that appear to cover key aspects of the software-based EAS model,” calling this “undisclosed intellectual property [that] may introduce significant concerns related to policy and competition in the marketplace.”
Certification
The FCC notice then devotes a considerable discussion to certification.
We won’t delve into the details here as they get both technical and legalistic. But the commission wants to know what approval framework should apply.
It notes that software may raise issues that are not addressed by its existing certification framework for devices like broadcast transmitters, garage door openers and personal computers.
It tentatively thinks that EAS software should be submitted to an approved entity for testing and then to a certification body for approval. It wants to know what functions should be tested, what procedures used and what entities would be best suited to perform testing.
Also, it asks how many of the physical and electrical specifications that apply to the hardware aspects of dedicated EAS equipment should be applied to EAS software.
You can read the certification portion starting with paragraph 104 on page 55 of the FNPRM.
Cybersecurity
The FCC knows that securing EAS from bad actors is crucial.
“Cybersecurity is plainly a cause for concern in the EAS environment, as exemplified by the many hacking incidents that have resulted in false alerts, and in the process, prevented the transmission of legitimate, lifesaving alerts,” it stated.
It proposes that before any EAS software can be marketed, the party seeking certification should be required to demonstrate to the FCC that it has taken appropriate steps to secure the software.
The FCC wants to know how best to prove that, which might include a declaration of conformity with certain standards or best practices, a cybersecurity audit or test report, or other evidence.
It noted that there are cybersecurity certification programs for software in the marketplace, each with different focuses; perhaps one of those would serve as a basis.
Also, if it adopted cyber requirements for EAS software, should it impose requirements on standalone EAS gear too? And should foreign-produced EAS software be prohibited where national security is implicated?
Digital Alert Systems told the FCC that allowing EAS in software would shift many responsibilities to stations and other EAS participants. Those responsibilities include implementing secure hardware configurations, maintaining firmware integrity, performing vulnerability testing and ensuring end-to-end system hardening.
DAS believes many EAS participants may lack the necessary technical expertise or resources to do all that. The FCC asked for comment on that.
Other matters
The FCC also proposes to shorten the time given to EAS participants to repair or replace defective EAS software before notifying the commission from 60 days, which is the rule for EAS hardware, to 72 hours.
“We believe that EAS software is unlikely to be defective for very long and in many cases, EAS can continue to be provided by backup EAS software. In addition, we believe that EAS software may be more prone to cyberattack by virtue of its IP interconnectedness. Accordingly, there is a heightened need for commission awareness of lingering EAS software defects that may derive from ransomware, viruses or other cyberattacks.”
It also invited ideas about additional or alternative requirements, changes or limitations to ensure that software “meets or exceeds the reliability, security, and availability provided by current EAS equipment.”
It also said that in the most recent nationwide EAS test report, an “appreciable number” of participants were unable to participate in testing due to equipment failure, despite advance notice of the test, “suggesting that equipment failures are not addressed by EAS participants as swiftly as reasonably possible and that more needs to be done to improve EAS operational readiness.”
And it believes that allowing the use of software could ease stresses on the industry’s repair cycle so it wonders if it should shorten the notification deadline for EAS hardware users as well.
Comments on the FCC’s proposals are due Aug. 31. You can read its discussion about software-based EAS starting at paragraph 88 on page 47 of the FNPRM.
