[aprssig] IS-to-RF alternate proposal - 'marked beacons'

[Lee Bengston]

On Thu, Dec 29, 2011 at 4:38 PM, Bob Bruninga <bruninga at usna.edu> wrote:
> Update:

> I just added one more.
>
> APRS-IS mobiles with VHF, UHF or HF radios in their mobile should also
> include their FFF.FFFMHz monitoring frequency in their position reports.
>
> This gives RGATE operators an additional decision point option.... that is,
> to choose not to gate a mobile that has no means of joining the local RF
> community at least by voice.
>
> Bob, WB4APR

I suggest a simpler approach that applies a unique (TBD) character
sequence in the comment area of a beacon that ID's it as a posit that
needs to be gated to RF.  There's already a precedent for using a
portion of the comment for PHG info.  This approach would provide the
following benefits:

- Existing clients can support - albeit by manually entering the
special sequence in the comment
- Doesn't break anything - existing IGates, IS servers, etc all just
treat it as a beacon - and existing IGates won't gate it to RF
- The user of the client has the option mark the beacon or not so that
simple tracking posits won't be gated to RF.
- Simpler to implement; simpler for most people to understand
- IGate operators who don't want to support gating the marked beacon
to RF can simply do nothing.
- Control is ultimately with the IGate operator using the software of
his choice.

Yes, there is no proportional path scheme, but we don't have that
today for gating messages to RF, anyway.  I think the problem with a
lack of coverage for gating messages is not the path but rather the
lack of Tx capable IGates.

In supporting the above approach, updated IGate software would need to
include rate limiting for gating these marked beacons - the default
limit of course would need to be conservative.  IGates could also
implement a decaying algorithm based on movement or lack thereof.
IGates could also provide configurable paths for these marked beacons
that could be different than the path for gating messages.  Messages
could also be prioritized above these new beacons in throttling
schemes implemented by the IGates.

As clients evolve, they could provide new features such as "mark every
nth beacon as gate to RF" and easier ways to enable marked beacons
without manually entering the marker in the comment.

This approach would, in my opinion, create much less of a kludge and
be simpler and therefore faster for the developers of IGate software
to implement.

I'll be bracing myself for the arrows that come flying in my direction...  :-)

Lee - K5DAT