[EAS] EAS time stamp usage

[Sean Donelan]

A comment was submitted to the FCC about the usage of the EAS time stamp 
field (JJJHHMM) in the EAS protocol.

http://fjallfoss.fcc.gov/ecfs/document/view?id=7021750843

The comment does a good job covering a lot of time issues.  However, I 
think one area that it doesn't cover is the expected EAS operating 
environment.  After a catastrophe, what conditions is EAS expected to
work?  Are GPS, WWV, NTP, etc time signals expected to still be working or 
accurate.  Or will we be using sundials to keep clocks synchronized.

For example, one of the operating environment assumptions for the WRSAME
protocol in the early 1990's was weather receivers/decoders often did not 
have clocks, and if they had clocks they could be wrong. Splitting 
the event time into two parts (duration and issue time stamp) supported
weather receiver/decoders without real-time clocks because they could
use a simple count-down timer starting at reception.  With the WRSAME 
protocol only the encoder at the national weather service transmitter 
needed a real-time clock.  A decoder in a weather receiver could set its 
clock using the WRSAME message time-stamp at reception, although no 
weather receivers actually do, because WRSAME is a single link-hop 
protocol. But it seemes that the WRSAME message timestamp is set at the 
beginning of the message composition process, rather than at transmission,
so its not as accurate as it could be.

With the WRSAME protocol, messages are valid immediately when transmitted
until the message purge time.

The EAS protocol is a more complicated operating environment than the 
WRSAME protocol environment. Although the protocols are compatible, there
is not a requirement they handle everything the same way.  Frank Lucia or
or someone involved in authoring the EAS protocol in the early 1990's 
may be able to answer what was intended or just accidental in the protocol
description.

As a practical matter, assuming an operating environment with perfectly 
synchronized clocks after a catastophe, let alone under normal 
conditions, may make an alert/warning protocol too brittle.  On the other
hand, the EAS protocol relies on the message timestamp as part of its 
loop/duplicate detection process, so ignoring the message timestamp 
completely can result in other problems.

If the EAS/SAME protocol was being updated, it would make sense to clean 
up some of these issues.

Most EAS decoder processing should be based on time of reception and
message duration.  Automatic EAS encoder forwarding should allow for a 
clock skew window, and require manual override if the message valid time 
period is too far outside the clock skew window compared to the local 
clock.

  - Allow automatic forwarding of the EAS message within the valid time
    period window plus or minus 15(MM) minute clock skew, e.g. message
    timestamp (JJJHHMM) is 15(MM) minutes in the future compared to the
    local clock or message purge time (JJJHHMM+TTTT) is 15(MM) minutes in
    the past compared to the local clock.
        Allowable clock skew, i.e. 15 minutes, should be less than message
        duration (+TTTT)

        Do not delay processing the message because the message time stamp
        (JJJHHMM) is in the future compared to the local clock.

  - Do not automatically transmit an EAS message outside of the message's
    valid time period window, including clock skew, in the future or past
        All messages, including EAN/EAT messages, are only automatically
        forwarded within the message's valid time period including clock
        skew to prevent replay attacks and message loops.

        Warn operator if the message's valid message time period is too far
        in the future or past before manually transmitting, e.g. operator
        realizes the local clock is wrong and forces the message
        transmission

  - Keep transmitted and forwarded EAS message headers for 18(HH * 3)
    hours after local time of transmission for duplication detection
    instead of deleting after the message's valid time period expiration
    from the message time stamp (JJJHHMM+TTTT).
        This assumes the longest message duration is 6(HH) hours.

- Incoming valid messages are purged after message duration (+TTTT) from
   time of reception, not from message's time stamp (JJJHHMM)
        This allows review by the operator of a message received just
        after the message's valid time period expired in case the local
        clock is wrong

        Messages would still have to pass valid time period checks
        for automatic transmission

        Purged "after" can mean anytime after, not immediately after,
        for EAS equipment with lots of storage.  EAS equipment with
        limited storage may only have storage for the last 10
        incoming message headers.  In limited storage EAS equipment,
        transmitted message headers shouldn't be overwritten by incoming
        message headers, because transmitting a duplicate message is worse
        than receiving multiple duplicate messages.

  - Warn operator if incoming RWT message timestamp from a required
    monitoring source is more than +/- 2 minutes different from local
    clock.
        Either the local clock or remote clock could be incorrect and
        needs investigation

        Optionally update local clock based on RWT message timestamp
        if remote clock source is reliable, which would help keep EAS
        decoder clocks synchronized with area required monitoring sources.

        Only RWT (required weekly test) is always single-hop transmission,
        with a timestamp near the time of reception.  One RWT a week
        would keep even low quality clock chips synchronize within +/- 2
        minutes without external clock sources at every EAS box.