[EAS] BLU Alert Comments.

[Botterell, Arthur@CalOES]

Nail on the head, Mike!  CAP offers us a much larger operational "envelope" than EAS/SAME.  By using a CAP-capable transport, it becomes possible to move all sorts of time-critical and place-specific information, including but not limited to EAS traffic.

Currently as part of our Earthquake Early Warning project in California we're experimenting with using an open-source message "broker" in a Publish/Subscribe pattern to move quake alerts that can't wait for the EAS ritual.  We're using Google infrastructure to shave milliseconds off the message latency.  That could become an enhanced State Relay Network by extending the Internet infrastructure... we're bypassing the local Internet using datacast over digital TV signals in the metro areas... and with a satellite data broadcast system for less urban parts of the state.  All the traffic is digitally signed, just like on IPAWS, to avoid the risk of spoofing or man-in-the-middle attacks.  The datacast "hops" reduce our exposure to denial-of-service attacks, but that's still a concern, again, as with IPAWS.

Of course, broadcasters still lack a mechanism for targeted alert delivery... but there's interesting work being done with digital "subcarriers" over DRM on mediumwave in Asia.  No fundamental reason the same couldn't be done with HD here in the States, although getting the consumer electronics firms on-side is still a challenge.  But by building a warning infrastructure that isn't defined in terms of legacy broadcast technology, we open up ways to solve a lot of other problems.

Art
________________________________________
From: EAS <eas-bounces at radiolists.net> on behalf of Mike McCarthy <towers at mre.com>

Actually this intermediate step is not even needed.  Allow the automation
vendors to access CAP and let them handle the whole thing, including
automatic voice coding...outside of EAS...