[EAS] EAS/IPAWS is ripe (and overdue) for disruption

[John Willkie]

All;
 
One of the "hot" areas of smart phone development is geo-awareness. People have driven onto the Fairbanks, AK airport twice in recent weeks due to bad data in Apple maps that they were using for turn-by-turn navigation, as an example.

I think we should ponder how well coarse, "county-boundary" based EAS/IPAWS messages will inform those drivers of a pending emergency. Does a person who drives across an active airport runway even know the name of the county they are in?

Possibly not, but what if their map display or turn-by-turn audio information also told them the roadway they are approaching is subject to flooding and that there is a severe rainstorm right now uphill in the watershed?

I live in a county that is not the largest on the mainland, but which is larger than three states and about the same size as Connecticut. Connecticut has eight counties. My county has at least four distinct environments: semi-tropical coastal, low savannah, semi-alpine, and desert. Severe rainstorms in the desert portion are irrelevant to the rest of us; the water rolls into a different county, but the rest of us are alerted to these largely irrelevant warnings.

Severe rainstorms in the mountain zone can occur in the mountain areas with only distant clouds visible to the bulk of the county's population. If that is the case, being in an arid zone, the rainstorms are "all good" because rain is highly valued in arid areas, particularly when it only means more water in nearby reservoirs in coming weeks. Likewise, people near the crest of mountains will have a different "peril profile" than people driving in mountain valleys in watersheds where the runoff might quickly accumulate. If the ground cover has been eradicated due to fire damage, that peril will come quicker without trees, grass and underbrush to absorb and feast on the rain.

All these areas get the same alerts today. This might have worked - roughly - in the 1950's when Conelrad first came about; at best we are dealing with an anachronism.

Compare this to FourSquare. If I am walking or driving around with a FourSquare app on my phone it will tell me when I am geographically close to fellow "FourSquare" friends. The app pays attention (when told to do so) of my location in real time, and it continually calculates the distance and directions to my friends.

Compare this also to Waze, a "crowdsourced" navigation/road condition application that is unlikely to ever guide a second person across the runways at Fairbanks because the first person who was so guided would put out an alert that others would know of immediately, not "weeks later" when a slow Apple bureaucracy get around to wending through their list of needed updates.

How much attention will people who have become accustomed to real-time geographical feedback and alerts pay to EAS messages addressing a (to them) non-issue 100 miles away? Add in the RWT/RMTs that interrupt radio and TV programming for what are essentially "promotional messages." Sure, transmission of those messages is logged. Is "reception" or "use" of these messages logged?

A BIG assumption is that people - even people with GPS navigation units - know where they are. Sure, they may have lat/long data, but will they know that a message addressing "Ranchita" is relevant to them? What if those messages and roadsigns are in a different language? (A good friend, while visiting Mexico a few years back, would see exit signs saying "Salida" and would tell his wife "lookup Salida on the map." Salida is Spanish for "exit.")

Our existing systems assume that everybody in a very wide area is equally in peril at the same time, that they know what county they are in and what the nearby place names are. None of those is a reasonable assumption.

Alerting people to non-perils means they will tune out your alerts. I don't care if the alert comes on their cell phone, their radio or their television set. RWT/RMT messages that interrupt audio and video are even worse; a simple on-screen icon will indicate that a message was received.

Telling people who aren't in peril that a warning or watch will expire in four hours means that they are likely to ignore, once they discern they are not in peril, any future messages until at least that time has come and gone.

Sending out delayed information - without indicating it is delayed - to fulfill legal requirements is somewhere between absurd and "felony stupid." But, this is the "new" system we have with IPAWS/EAS/M-EAS.

I speak not of eliminating what we have today. I speak of preparing for the present and letting the existing system slowly die after we have replaced it.

Let us first get rid of the "unfunded mandate" meme. Providing emergency messages to the public is simply the cost of owning a relevant cable system, television or radio station or mobile phone system. Nobody was forced into these businesses and all are free to exit the field at will. Too many people already believe today that broadcast uses of RF spectrum is a drain on public resources: "unfunded mandate" language just supports those "funny unthought half-ideas."

Let us assume that cable TV system serve a tightly-described geographic area and do not serve areas outside of their franchised areas. Based on this common-sense assumption, let us design a system where cable television viewers are provided with EAS messages that could directly affect them at home, and let them subscribe to additional messages anywhere else in the country, using IP connectivity and the eCM (embedded cable modem) built into every modern digital set-top box.

Make cable companies employ set top boxes that will not only recognize and log receipt of EAS messages, but will note when those messages are actually presented to viewers. Replace the audio/video cut-ins of "test messages" with a beep and a temporary EAS on-screen icon. The current messages are captured in full - as if relevant - when a show is recorded using a DVR. RWTs and RMTs delivered to the public as today are basically "your government at work" advertising messages.

Let us send specific geographic information: lat/long of the "centroid", plus geo-outlines of affcted areas using digital means via TV metadata and RDS. A time stamp will indicate the time of the geo-fix. Additional information will tell the time and distance of the previous geo-fix (if there is one). With these data points, the location and direction of the weather issue can be identified. For devices that provide geo-awareness, the device itself can warn users of the relative importance of the danger and whether it is heading their way, or is in the direction of their intended travel path.

I have seen comments that RDS is inadequate for this task, and even that RDS doesn't extend as far as a station's coverage area. I haven't run tests that compare signal level versus RDS reliability, but in my experience, this is simply an implementation detail. Few to none radio receivers cache RDS song titles: the information presented is effectively real-time. If one of the RDS data segments isn't fully received, no attempt to recover the data is employed; the entire text string is ignored until a new one is transmitted. Song titles simply change less often than reception levels. By caching song titles and comparing the bits as transmitted, a radio can determine if the information has changed from that which has been cached. In addition, just like "auto-correct" in cell phones works "okay" even missing bytes in the first transmission of title/artist information can be inferred. Song titles and artist names are not random text strings; the words are actually from rather vocabulary. How many artists have the first name "Bruce"?

Beyond artist names/song titles, RDS can convey long-form data, and forward-error correction/error identification methods (in addition to those already in digital bit-streams and the RDS spec) without much additional data overhead.

The cable emergency alert standard (SCTE-18 (2007) used by cable systems can be modified to provide the information I have identified, and the ATSC Non-Real-Time (think of this as being audio/video/data that isn't exactly real time) and Mobile-EAS standards can be modified, if there is enough interest, to provide the needed actionable information.

Then, I think back of the horror of time, money and effort that led to the CAP standard and IPAWS system and the results. (A friend and colleague was deeply involved and became a cynical man during and as a result of his involvement.)

I hope I don't sound like a 20-something, as my twenties were more than a few decades ago. But, said simply, this is an area ripe for disruption by a start up company.

After more than 50 years of development and deployment, we finally have an emergency alert system that might have been workable during the Cuban Missile Crisis. Our emergencies are less predictable these days, occur with less advance notice, and the demands by citizens for real-time information are a "given."
 
The initiation and delivery of emergency information is too important and timely to rely on government alone to provide. I'm willing to bet that a focused, citizen-centric approach can provide deeper and more timely information than all the current approaches together.  For starters, it wouldn't support the notion that an elephant is a mouse designed by a government-sponsored committee.
 

John Willkie johnwillkie at hotmail.com johnwillkie at etherguidesystems.com
telephone (Google Voice) +1 619 567-9486
skype: jmwillkie
Google Plus: John Willkie