Problems with the EAS system surfaced in the 2011 nationwide test; now the Commission is looking to fix them, but it could take a while and be pricey for EAS participants.

Following up on the request for comments released last September, the Commission has issued a Notice of Proposed Rulemaking (NPRM) seeking comment on a number of possible changes to its Emergency Alert System (EAS) rules in the wake of the first-ever national EAS test conducted nearly three years ago.

While the test went reasonably well, all things considered, it did reveal a number of rough spots that need smoothing over. A couple of the problems involve header codes; others relate to the accessibility of messages, particularly for those with disabilities. Despite the fact that the changes may seem minor, though, they could impose some hefty new costs on EAS participants – so attention should be paid.

As to the header codes, first some explanation. The EAS system is, of course, a “daisy-chain” arrangement by which alerts percolate down through EAS participants and out to the public. An EAS alert – real or test – is triggered when a message is sent by an authorized person or office. The message contains a “header” consisting of certain coded components that permit EAS equipment down the daisy-chain to identify the originator of the message, the type of event in question, the geographic area affected by the alert and other useful information. It is obviously important that this coded information – particularly the “event” and “location codes” – be interpreted correctly by EAS gear downstream so that the message is accurately transmitted to the audience.

The goal of the 2011 test was to see how the EAS system would work if a nationwide Emergency Action Notification (EAN) – the kind of notice the President would transmit to all of us in an actual emergency – were to be sent.

Header Problem No. 1: The EAS rules don’t include a location code for “nationwide”. So in 2011 the Commission improvised, using the Washington, D.C. location code (since that would be a likely place from which the President might issue an alert). While most EAS participants received and transmitted the test, some ran into problems because their gear read the D.C. header to indicate that the emergency was “out of area”; they ended up cutting off the message part way through.

In response, the Commission is proposing an easy fix: designating “000000” (six zeroes) as the national location code. All EAS participants would be required to receive and process the code accordingly. According to the Commission, most EAS equipment already in the field can accommodate this change with minimum hassle or expense.

Header Problem No. 2: The rules currently contain no “event” code for a nationwide test. While there is an event code for periodic testing (i.e., NPT, short for National Periodic Test), the NPT doesn’t work exactly right for an EAN situation. EAN’s, being national and all, are required to be given the highest priority:  EAS gear is required to bump any and all other emergency messages when an EAN comes knocking. Also, the rules provide that EAS equipment can be programmed to reset itself after two minutes, allowing the receiving station or operator to return to normal operation even if no “end of message” (EOM) code is sent. In effect, that means that normal EAS alerts are no longer than two minutes long. The NPT code is subject to that same limitation. But EAN’s can be of any length at all. That being the case, the NPT does not perfectly emulate an EAN.

Back in 2011, the Commission (which initially envisioned a three-minute nationwide test) used the “live” EAN code, rather than the NPT code. That eliminated the possibility that the test would be overridden by some local EAS alert or cut short at the two-minute mark. But, because EAN messages include no reassuring “This is only a test” notices, use of the EAN code required many EAS participants to improvise by providing their own “This is not a test” notices while the actual message, triggered by the EAN, contrarily announced a national emergency.

The Commission is now thinking about requiring that the rules regarding the NPT code be amended to specify that that code “fully emulate” the EAN code, meaning that it would override all other messages and permit messages of indeterminate length. That proposal is not without its own drawbacks, though. While no significant changes to already-deployed EAS gear are believed necessary to accommodate the “six zeroes” national location code, it would be considerably more expensive, and time-consuming, to develop and deploy an EAN-emulating NPT code.

That puts the Commission in a bind. An NPT code that acts just like an EAN would provide a more reliable gauge of the likely effectiveness of the EAS system in a nationwide emergency – and that would be good. But to achieve that could be expensive for EAS participants, which would be bad. Also bad: the delay factor. As the NPRM ominously observes, a presidentially-initiated national emergency alert “could come at any time”. Additionally, FEMA has advised the Commission that FEMA would like to run another test in the relatively near future – but such tests could be seriously delayed if significant changes in the system must be made first.

Rather than resolve the emulation issue, the FCC solicits more input on such questions as:

  • How much would it cost to develop an EAN-emulating NPT;
  • How much time would it take;
  • Are there any reliable alternatives (e.g., a test-bed set-up) that might be used to determine whether any or all of the EAS daisy-chain system would reset after two minutes in an NPT situation;
  • Would an EAN-emulating NPT really take as long as three years to develop.

Header Problem No. 3: The header includes a coded element that specifies “when the message was initially released” by the originator. The problem there is that the time code in a message’s header may be different from the time that the message is received downstream. But the Commission’s rules provide that EAS messages are to be retransmitted as soon as they are received by EAS participants.

This problem surfaced during the 2011 test, when the message that FEMA sent out included a 2:03 p.m. time code, even though the test had long been announced, and promoted, as occurring at 2:00 p.m. Some EAS participants received the message at 2:00 but held off on transmitting it until 2:03, as the header code seemed to direct. Wrong. As the Commission now makes clear, “EAS equipment must transmit the EAN immediately upon receipt, regardless of the Time of Release provided by the alert originator.”  Accordingly, EAS equipment should be programmed to, in effect, ignore any time code in the header that would delay any retransmission of the message.

With respect to accessibility questions, the Commission notes that, during the 2011 test, some viewers had trouble reading visual comments. Accordingly, it plans to adopt “minimum standards” for crawl speed, completeness and placement of EAS visual crawls. Acknowledging that its existing video captioning rules address precisely such accessibility questions, the FCC says it’s ready to utilize the same general approach taken in those rules to tweak the EAS rules. (Curiously, the Commission asks for comments on some of the nitty-gritty standards that should be imposed, which suggests that, in their current form, the captioning rules – which one might have thought to be a reliable source for such things – don’t provide adequate answers.)

Also, because the visual and aural components of EAS messages are not necessarily generated by an identical source, in some instances during the 2011 test the two components appeared to be giving inconsistent information. The Commission’s response? “We believe that for an EAS alert to be fully accessible, the audio and visual elements should convey the same message.” It’s hard to argue with that. But the FCC’s unsure about how to achieve such conformity, so it’s asking for suggestions.

In addition to the technical operation of the system, the FCC is also looking to make permanent the reporting process it used in 2011, but with a couple of minor tweaks that should make life a bit easier for all concerned.

Bottom line on all this: It’s clear that some changes to the EAS system are on their way, but it’s still not clear precisely what those changes will be, how much they will cost, or how much time will be available to come into compliance. (On that last question, the Commission is currently figuring that six months should be plenty of time once the final rules are adopted.)

Reflecting the Commission’s concern about imposing unwarranted costs on EAS participants, the NPRM also requests detailed cost/benefit analyses. But don’t expect such analyses to be especially persuasive. The FCC estimates that the total cost of the changes it envisions would top out at $13.6 million – not an insignificant sum. But the Commission then observes that a risk-reduction model used by Department of Transportation “estimates the value of risk reduction, measured in terms of an expected life saved, to be $9.1 million”. So all it would take would be two lives saved to offset the anticipated $13.6 million upgrade costs. If the DoT model is going to be used, the upgrade costs aren’t likely to amount to much, no matter how high they may appear.

Nevertheless, there are obviously a lot of open questions about which the FCC seems sincerely to be seeking input. If anybody has any good ideas, now is the time to toss them in. The deadlines for comments and reply comments have not yet been set. Check back here for updates.