[EAS] CAP EAS Logging Question

[Harold Price]

Headline: CAP works fine with county-specific FIPS codes.

Executive summary: The Sage ENDEC treats CAP-derived EAS messages the 
same as over the air messages, including filtering with events and 
FIPS codes, with one exception.  Over the air messages that don't 
match a filter are logged as "ignored".  CAP messages that don't 
match a filter are not logged in any way. (Discussion of why that is 
can be found at the end of this message).

There are a lot of little details and side effects that aren't 
relevant to the larger issue, I'm leaving out much of the low level 
stuff, like the "pre filtering" capability of the IPAWS server that 
makes it possible to not download alerts for areas you don't have any 
filters for.  This substantially reduces the CAP bandwidth at your 
site (and in the aggregate for the IPAWS server).

Details:

Speaking for the Sage ENDEC, here is what we do for CAP messages that 
contain an EAS alert (i.e., this discussion doesn't apply to non EAS 
CAP messages used in other countries).

1) The ENDEC fetches a CAP message.  It compares the CAP unique ids 
against a cache of recent CAP messages, and ignores CAP 
duplicates.  CAP messages are supposed to be universally unique, not 
just unique per server - so it doesn't matter what server you get the 
message from - duplicate CAP messages are detected.  Duplicate CAP 
messages aren't logged.  Unique CAP messages can contain duplicate 
EAS messages, however, and the duplicate EAS message would be logged.

2) The CAP message is translated to EAS - this includes all of the 
EAS items except the callsign, but including all the other fields 
such as event code and FIPS codes.

3) The CAP derived EAS message is checked against the EAS 
filters.  If a matching filter is present, the CAP message will be 
logged, otherwise skip to 4). If it is expired, it will be logged as 
such.  The message is then checked against other active EAS messages, 
from whatever source, using the EAS rules for duplicate 
detection.  Duplicates are logged as such.  If it has an action of 
Log Only, no further processing occurs.  If it is a relay type 
action, the alert may be relayed - following the same rules as for 
EAS messages received on the audio inputs.  In any case, it will have 
been logged, if it matched any filter.  CAP derived message include 
the CAP text as well as the EAS boilterplate text in the log.

4) If the CAP derived EAS message does not match a filter, then the 
message is NOT logged.  This is different than EAS messages received 
"over the air".  If an EAS message received over the air doesn't 
match any filter, the message is logged as "ignored".  CAP messages 
aren't logged as ignored.

Why are over the air EAS messages that don't match a filter logged anyway?

Over the years (and I've been doing this since 1995) we've gotten 
support calls about messages that were heard by ear on the monitor 
receiver, but weren't logged.  We had many requests to log these.  We 
had very little room to log messages in the original 1822 ENDEC - 
only the most recent 80 or so), and while uses hated not getting all 
the messages logged, they hated buying the little rolls of printer 
paper even more.  The 3644 ENDEC has a lot of room for logs, so we 
now log the over the air filterless alert to the browser accessible 
log.  Many folks seemed to like it.  It sure helps debugging when 
alerts that a user think should have gone on the air don't.

Why aren't CAP messages that fail to match a filter not logged like 
the over the air alerts?

We leaned toward logging everything that came in over the air because 
their aren't all the many of them.  Yes, there are a lot of NWS 
messages per day, but not everyone has an NWS monitoring assignment, 
and most that do only monitor one transmitter.  For CAP, however, 
everyone will, in effect, here every transmitted.  On the FEMA test 
server, I've seen more than 1000 alerts on some days.  There is much 
behind the scenes work to reduce that number, as well as working on 
the issue of EAS duplicates in CAP messages.  Once the NWS goes live 
on the IPAWS eas server, there will be many more alerts per day there 
(somewhere between 100 and 1000) nationwide.  No one wants to see 
that many alerts in their log.

Based on recent discussions, however, we will probably add an option 
to allow users turn off the logging of filterless alerts.

Why aren't duplicate CAP messages logged?

Some CAP servers don't have a way to limit what messages are 
available - the ENDEC has to fetch the entire list.  Some don't have 
a reliable method of doing it by a time stamp, so the ENDEC needs to 
specify a fuzzy fetch date with some overlap to make sure messages 
aren't missed.  Some CAP feeds are intentionally redundate - the 
ENDEC always fetch from both feeds, and in normal circumstances will 
always receive each alert twice.  Some CAP alerts are posted to 
multiple providers.

For some simple CAP servers, you get the same active messages each 
time you poll - two messages with a four hour duration would result 
in 960 duplicated.

Duplicates are a fact of life in CAP, and the ENDEC uses a different 
method to show that messages are being received on a particular server.

How can you get a duplicate EAS message in a unique CAP message?

Many ways.  Here are three.

1) The message doesn't start out as a CAP message, for example a 
legacy data feed from the NWS.  If two alert server providers both 
pick up that legacy message and encode it into a CAP message, you'll 
have two unique CAP ids - but inside will be the same EAS message.

2) EAS messages are time stamped to the minute.  CAP messages are 
time stamped to the millsecond.  The EAS timestamp is derived from 
the CAP message.  If, for example, two RWTs are mistakenly sent via 
cap, one at 2013/09/12 12:00:03, and a second one at 2013/09/12 
12:00:53, the time in the EAS resulting EAS message will be 12:00 for 
both.  Two different CAP messages, but the same EAS message.

You will also see a CAP message show up in the log as a duplicate if 
the over the air EAS message was seen first.  This happens because 
stations are polling the CAP server at different times, and loading 
on the server might result in a missed poll, causing one station to 
receive the CAP message a minute or two after another station has 
received it and starting sending it over the air.

Harold

At 05:09 PM 9/11/2013, Brian Law wrote:
>My Point Exactly!
>
>I do not know if this issue is manufacturer specific or not.
>
>Would like to know the skinny on this, if the manufacturers would chime
>in please...
>
>Thanks,
>Brian
>
>On 9/11/2013 2:00 PM, Dave Kline wrote:
> >
> > If cap cannot work on a county level, then what is the point of 
> all of this monkeying around we've been doing over the last couple of years?
> > Does that mean it would be pointless to issue an weather related 
> EAS alert on anything less than an "ALL STATE" level?
> > If I'm not mistaken, our LECC is considering CAP-able gear to 
> generate alerts locally.
> >
> > Dave
> > ************************************************
> > Dave Kline   UNO-TV / KVNO
> > University of Nebraska at Omaha
> > 6001 Dodge St. Omaha, NE  68182  CPACS 200
> >