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

Wed Apr 1 12:14:31 EDT 2020

To answer some of your questions about APRS Bulletins:

1) The original spec limited the total Public Bulletin board to 40 lines
(one full screen at a time on the original PC).  That limit was arbitrary
and does not need to be implemented.  But if bulletins get so many and so
big, it defeats the purpose of public information...

2) If there are 30 lines of bulletins that have all decayed to the once
every 30 minute default rate (so late comers will get a copy) then that is
one packet per minute and a very small load on the network while keeping
everyone informed.

3) I wonder about your statement: "Or, are BLN messages not passed beyond
an "n" hop range (i.e. not injected into APRS-IS for possible
retransmission elsewhere)?" Bulletins or all APRS traffic in a given local
area should only use an N hop suitable to the local area.  In most cases
that is a hop of ONE.  Our local EOC's are by city and county and usually
one hop from any EOC can cover its area of interest.  Further, APRS was not
designed or intended to be re-injected back to RF from the APRS-IS.  Though
of course it can be done if needed.

4) I wouild think that reporting of open/closed gas stations and food
storew would best be handled with objects rather than text in a bulletin.

5) What goes into a bulletin is a judgment call, weighing urgency with
latency, and with network load.

6) APRS was designed from the gt-go to allow anyone to take over reporting
responsibility  for any positions and objects.  But unfortuately it does
not provide for one station taking over another stations bulletins.  But
that is one advantage of the overall 40 line limit.  If an EOC or net op
goes off line and his bulletins begin to age, then they can be forced off
the bulletim board by another net op uploading enough new info to push the
abandoned bulletin off the page.  Or the new net control operator can
momentarily use the originators call and send overwriting BLNx line numbers
to earase the originals.  THen take over as net operator with his own new
bulletins.

7) There are lots of features of the original APRSdos that were left out by
many follow-on clients.  They are enumerated on this page:
http://aprs.org/APRS-tactical.html but please take that page with a grain
of salt.  It was written in 2008 at the depths of my frustration of APRS
only being viewed as a tracking system.  And not being used for rapid
real-time community on-air information resource.

Hope that helps.
Bob

On Wed, Apr 1, 2020 at 12:37 AM Greg D <ko6th.greg at gmail.com> wrote:

> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200401/15fd8ac3/attachment.html>