[aprssig] Multi control station situational awareness - Using original Bulletin protocol!

[Greg D]

Hi Bob,

Thanks for taking the time to weigh in.  Much appreciated.

So, trying to understand first, before reacting...

BLN messages can be multi-line, which is great, but I presume it's a
client implementation topic for how many lines, and how long they might
be.  I don't know what the limits are of the applications I use, and
need to check this out.  Thanks for bringing it up.

But if I understand their use, an example might be assigning BLN1 to be
the status of gas station outages, BLN2 the availability of ice (to save
refrigerator contents), BLN3 power status by area, BLN4 for grocery
stores open/close, etc.  So if there are a half dozen gas stations being
reported on, would that mean a half dozen lines of BLN1 information that
would be repeated every, say 10-30 minutes?  Multiply that by, say, a
half dozen bulletin types, with repeats, and I'm thinking this could get
unwieldy rather quickly.  Do I have this right? 

I've been assuming that we'd be using a local simplex channel for this,
in order to not QRM the entire region with our troubles.  Going without
a Digi, however, could be problematic depending on where the NC stations
are located, as the terrain here is very hilly, and there are a lot of
shadowed areas.  We do not have the luxury of putting a digi at our club
repeater site, at least not at the current time, so we may be forced to
use the 144.390 channel (which does have a high level Digi support). 
That means whatever we come up with must be compatible with that broader
scope, including the Internet IS backbone.  How do BLN messages that
collide with other events doing the same thing in other areas get
handled?  Or, are BLN messages not passed beyond an "n" hop range (i.e.
not injected into APRS-IS for possible retransmission elsewhere)?  I'm
trying to understand how this kept local, yet scale at the same time.

As I noted originally, the need is for a shared, but geographically
distributed, Net Control function, and the ability to hand NC duties off
from one operator or operators to another over time.  Last year we had
power outages that lasted for several days and covered a wide area. 
With it went much of our internet and cell phone service.  So this needs
to be able to operate in an RF-only environment, but where operator
equipment isn't available 24x7 (to conserve battery power).  The ability
for a new NC to quickly get brought up to speed when their shift starts
is important.  That means distributed storage, and the ability to get it
sync'd from the current NC staff, without waiting for the network update
time to get refreshed by the usual methods, and without a centralized
repository. 

I think that all of the normal APRS message types, including perhaps
bulletins, can apply.  They're well understood and cover pretty much all
the bases.  It's just that we need a way to hold and pass on the
situation map and chronological log from one set of NCSs to the next, in
the absence of the usual infrastructure.  Andrew's idea of using News
might provide that foundation, instead of reinventing the whole thing. 
Are there any other utilities that provide a similar, light weight,
multi-node data storage and sync function?

Greg  KO6TH


Robert Bruninga wrote:
> Actually existing APRS can provide a lot of your suggested Public
> Bulletin functionality as-is depending on whether Clients properly
> implemented the original APRS spec Bulletin protocol.  Here is how
> bulletins were SUPPOSED to work (as in the original APRSdos). so that
> everyone got a maintained copy of any multi-line bulletin from any source.
>
> 1) Bulletins are numbered BLNx where X is numeric or alphabetic to
> establish a -sequence- to the lines in the bulletin.
> 2) The local EOC (or anyone) could maintain a multi-line bulletin that
> is captured by EVERY APRS station in real time, or for late comers too.
> 3) BLNx lines are repeated ad nausium but at a decaying rate.
> 4) Thus every station gets every line and they are always displayed as
> sorted by line number
> 5) The EOC can edit or change a line (number of beds, number of
> ambulances, etc) and it will REPLACE the previous same-numbered line.
> 6) Thus everyone in APRSdom always has the latest full copy of the
> multi line bulletin (worst case every 10 minutes or 30 minutes
> depending on the overall timeout plan for the given situation...
>
> The PROBLEMS with some implementations after APRSdos that undermines
> the beauty of the design I think are some of these:
>
> a) Many clients did not implement the decaying algorithm. They
> transmit at fixed intervals and then quit.  This prevents all lines
> from being continuously updated even after a few hours for new commers
> on the frequency.  The original was transmitted once, then 15 sec
> later, then 30 sec later, then one minute later, then 2 minutes later,
> then 5 minutes later and then ten minutes later and then every 30
> minutes forever (though a 12 hour or 24 hour time out wouild be
> nice).  Also, a decay to 10 minute or 30 minute cycle could be set
> depending on the urgency and dynamics of the situation.
>
> b) Many clients just logged each BLNx line as received instead of
> always sorthing the ones from the same sender always in sequence. 
> This makes multiline contiguous bulletins worthless.
>
> c) Same as b) in that replacement of a new BLNy should overwrite an
> old BLNy was not implemented.  Thus to update a bulletin, the entire
> thing would have to be sent again.  Thus exploding the needed
> bandwidth in a dynamic situation.  Insatead of the single refreshed
> line protocol.
>
> Can we at least identify any clients that fully implemented the
> original Bulleting protocol?
>
> - Kenwood - NOT.  TX's 1 per minute for 5 minutes and stops.  Does not
> sort on receipt.  Does not replace identical line numbers.
> - WinAPRS - Not.  Same as above
> - YAAC - ?
> - APRSIS32 - ?
> - XASTIR - ?
>
> Curious... Bob
{snip for posting length purposes}