In 1775, Paul Revere took a midnight ride through the Massachusetts countryside to warn residents that British regulars were approaching; he’d been tipped off by a pre-arranged lantern signal. We might think of him as the precursor to our modern Emergency Alert System — the first EAS volunteer.
The author says regulators have created a nationwide wireless daisy chain in order to deliver a message that has never been sent in 65 years.
credit: iStockphoto/zhudifeng President Truman in 1951 created the Emergency Broadcast System with Executive Order 10312, setting the stage for a national alerting plan in reaction to the threat of nuclear war. Over 65 years, subsequent executive orders were issued so that the president could address the nation if necessary. The modern Emergency Alert System was established in 1997 under the Clinton administration.
Millions of dollars have been spent on plans, equipment purchases and regulatory actions to prepare for presidential messages — though oddly, the system has seen few end-to-end tests.
Communication infrastructure has seen dramatic changes over those six-plus decades. We have multiple cable news channels dedicated to 24/7 news coverage; we have radio and TV news networks linked via satellite. In short, we have multiple channels ready to delivery video/audio real-time alerts.
But in their design and redesign work, EAS regulators have created a nationwide wireless daisy chain of radio/TV/cable carriers intended to activate on a presidential EAN header �� providing for an immediate rude takeover of their facilities — in order to deliver a message that has never been sent in 65 years!
One has to ask, “What is the message?”
A quarter of the 104 pages in the recent FCC notice of proposed rulemaking focused on security discussions. Migration to Common Alerting Protocol and the Integrated Public Alert & Warning System opened the door to the internet for alert transmission; now we have the legacy continental U.S. daisy chain and the IPAWS internet represented in one encoding/decoding device.
But barring a total system redesign, the legacy daisy chain isn’t going anywhere soon. The legacy component exists to carry real-time presidential message audio. A benefit is you don’t need a data decoder to be aware of alerts like severe weather warnings. Just monitor your analog audio. After replacement of legacy encoder/decoders we now have the ability to cross-check FIPS code — one for all of the continental United States was just added — as well as originator ID and date stamp. The original legacy equipment looked only for an EAN header and the trigger was immediate, with no cross-checks. With the replacement hardware, the IP input alert also include cross-checks of FIPS location code, date-time and originator. EAN header is the only code that has no time limit (others alert headers all have a time out of two minutes).
In the legacy system or IP input, no security checks for the EAN are monitored except for originator, FIPS location code and date-time stamp. If you set “strict time” to OFF, the date stamp check is void. The encoder/decoder will relay (forward) EAN unimpeded if strict time matches. EAN is the only code with no time limit; all other alert codes time out in two minutes — that is to say, the message cannot exceed two minutes in duration.
But the internet involves passwords, fire walls and so forth. I don’t trust any of that, and signing off on security becomes a leap of faith.
The FCC proposal to require a “certifying official” to declare that an EAS participant is following “best security practices” creates a moving target involving software patch updates, account management, network segmentation and CAP message certifications. It’s much more than “just changing passwords.”
The proposal also estimates the time involved at 15 minutes of recordkeeping. In reality it is more like four hours. Such a certification is difficult to sign; I myself would never do so, knowing what I know about the security weaknesses.
The FCC also proposes to require EAS participants to report the issuance or retransmission of a false EAS message. I suppose if a broadcaster does not catch an anomaly and report it, a fine will follow? What defines a false alert? Does a mistimed or missed Required Monthly Test sent from governmental authorities qualify? Will a report result in a fine? Will there be a fine for failure to report any anomalies from a flawed system?
The commission also wants to require participants to report instances in which their EAS equipment causes a “lockout” downstream. But broadcasters may not even know what equipment they locked out. Further, this requirement would dissuade broadcasters from becoming or staying a Local Primary, given the liability issues involved. (On the other hand, FCC proposals regarding alert authentications and alert validations are reasonable and good processes that would help make the system more resilient and secure.)
NO MORE BOBBY BONES INCIDENTS
This leads to the subject of iHeartCommunications and its $1 million civil penalty and consent decree last year to resolve an FCC investigation into misuse of EAS tones.
This is a case study of how inadvertent action can have big consequences. A syndicated host wanted to demonstrate how critical minutes of a baseball game were interrupted by a monthly EAS test. A quick YouTube search brought up a 2011 “hot code EAN” from a planned end-to-end test to air over all of the continental United States.
Airing the outdated test apparently was deemed harmless by the show staff. Little did they know that many hardware boxes down the daisy chain had their “strict time” set to OFF. (Again, why is this even an option?) So the hot code EAN took on a life of its own and interrupted many stations downstream. To make matters worse, this involved a network feed to 82 stations, and the incident ultimately affected 32 states, per the FCC.
Given a penalty of this magnitude, it’s clear that errors and omissions, trivial or not, can take on massive consequences.
In this instance the safe road for radio/cable/TV operators is to do the minimum required: Relay EAN (with “strict time” set to ON), as well as Required Weekly Tests and Required Monthly Tests — and no more. Clear out all filters. This will make any incoming alerts as “log only” events for analysis. Instruct operating staff to be at the ready to abort any alert that could be suspicious. Educate staff that no EAS tone should make it to air in any commercial, PSA or show segment. If necessary use the iHeart case as a classroom training aid. (Search “EB-IHD-15-00018252” to find the FCC document.)
Where is all this heading?
Wisconsin State Emergency Communications Chair Gary Timm identified about 166 action items in the NPRM. When last I checked there had been 101 comments filed, with an estimated 5,500 pages of comments! You would need to read 21 pages a day for a year to cover them all.
Regulators have created an EAS toolbox so complex it could crumple under its own weight.
I researched an earthquake auxiliary communications recovery plan for eight Midwest broadcast associations and found that the critical LP station — the area’s critical message relay station that all downstream stations monitor — would be the regional station to support by the local county emergency management agency.
We also concluded that a Ku band dish type subscription (wireless) to monitor cable news services would provide an insight for that critical LP station of how bad conditions are after an earthquake.
Could one of these national satellite services be the replacement for the daisy chain of hundreds of stations handing off an EAN? The necessary hardware is an off-the-shelf consumer Ku band antenna and set-top box; now you have a direct connection for the EAN. A side benefit for the LP station is that your newsroom gets a national news service feed for breaking national stories.
Maybe it’s time to rethink Part 11?
Warren Shulz is a retired major-market radio engineer who chaired the Illinois State Emergency Communications Committee for 16 years and served on the board of the Primary Entry Point Advisory Committee for 15 years. He is a life member of IEEE, AES and SBE.
Comment on this or any story to firstname.lastname@example.org.