[sbe-eas] FCC NPRM on the national test
acb at incident.com
Thu Mar 11 16:33:40 EST 2010
On Mar 11, 2010, at 3/11/10 12:54 PM, Suzanne Goucher wrote:
> Maybe our Alaska friends can weigh in on this, and maybe I'm confused, but doesn't sending an EAN alert mean they also have to send another, separate, EAT alert to end the EAN?
Although the current FCC rules and also the current FNPRM do provide for an EAN being followed by a separate EAT, the SAME-based EAS protocol doesn't actually seem to require it, since the EOM associated with the EAN has pretty much the same effect. There was no EAT transmitted in the Alaska exercise and, although there were a few hiccups, none of them would have been solved by an EAT.
I'm thinking the EAN/EAT pairing may simply have been carried over reflexively from the earlier EBS procedures. Back in the day, the plan was for the Emergency Action Notification to go out by teletype to tell broadcasters to activate the audio relay system until the Emergency Action Termination message came over the wire telling them they could return to normal programming. It was an "out-of-band signaling" arrangement, where the control of the system went over a separate network from the program content.
When we moved to EAS, the signaling was moved in-band via the data bursts. The EOM burst became the effective equivalent of the EAT. But the idea of a separate EAT message was preserved without, as far as I know, any explicit reason. I suspect there may simply have been a fear of potential unanticipated side-effects if it were dropped.
(In CAP, by the way, we actually return to an out-of-band signaling approach, which is necessary because the CAP messages will activate other warning delivery systems in addition to EAS. For most alert types each CAP message is "atomic," which is to say it's a complete entity in itself. But since an EAN launches a broadcast of indeterminate duration, it requires a slightly different approach. The initial "EAN" CAP message serves as an announcement that the extended presidential broadcast is beginning and provides a "pointer" to the audio stream. A corresponding CAP "cancel" message will indicate the end of the broadcast.)
Anyway, this illustrates the importance of actually exercising the systems we build, preferably before we cast them in regulatory cement!
More information about the sbe-eas