[aprssig] IS-to-RF gating... A proposal

[Lynn W. Deffenbaugh (Mr)]

Why don't we just say that -IS to RF IGate software needs to provide an 
easier way for IGate operators to configure selective -IS to RF gating 
of packets for arbitrary stations with good constraints and reasonable 
rules.

I really don't see any need to impose new restrictions and complexities 
on APRS-IS client software authors when the ultimate decision is in the 
hands of the IGate operator.

Also, I suspect doing ANYTHING to the "TCPIP*" being the only path for 
APRS-IS-originated packets (like adding additional path components) will 
have undesirable ripple effects.

KISS - Give a way for IGate operators to do more than the current "gate 
all packets from these specific stations" and leave further decisions up 
to them within the capability of the new tool.

It'll be easier to get 2,000+ IGate operators to (hopefully) upgrade 
software than to get many more thousands of APRS-IS clients to upgrade 
their code.  (Personal opinion: there's nothing "magic" about mobile vs 
stationary APRS-IS clients and no difference between a phone or a PC 
from a mobility standpoint.)  And there's potentially fewer IGate 
software packages that will have to implement the feature than there are 
(or will be) APRS-IS software authors that will have another batch of 
"requirements" to implement.

Just as the -IS to RF messaging path is determined by the IGate 
operator, so the path for anything else gated from -IS to RF should be 
locally determined.  If the IGate software author wants to do 
proportional pathing for gated 3rd party packets, so be it, but it's not 
the responsibility of the (non-RF) packet originator to determine what 
paths would be suitable for RF transmission.

For your far-reaching proposal, every assumption made anywhere within 
the APRS-IS that -IS-originated packets contain only TCPIP* as a path 
would have to change as well as all APRS-IS client software and IGates 
as well.  In my KISS proposal, it's simply a new, more flexible 
configuration available to the IGate operators to determine what 
additional packets should gate from -IS to RF.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  See also http://en.wikipedia.org/wiki/Leaky_bucket and dream of 
being able to apply it at a per station, per callsign, and per interface 
level with independent settings for messages w/courtesy posits vs 
"extra" posits for the local area...


On 12/28/2011 10:28 AM, Bob Bruninga wrote:
> To avoid a lot of misplaced debate on apples and oranges and confusion, the
> following is a collection of -a- proposal so we can all be sure we are
> debating the same thing.  I am not saying we agree to implement this.  I'm
> just making sure we are all looking at the same limited idea and debating
> only its merits, and not all the possible other bugaboos...
>
> PURPOSE:  To give IGate operators a local tool to allow local selective
> IS-to-RF gating while giving him the means to control it based on his local
> environment (his IGate coverage range and channel loading).  For
> identification, lets call this process an RGATE.  Only IS packets
> specifically identified by the IS originator as potential for RF gating are
> considered by the RGATE and then only the rules of the local RGATE owner
> permit transmission.
>
> IS CLIENT REQUIREMENTS:  Authors of mobile phone or other IS applications
> that inject such RF gating request packets into the APRS-IS would adhere to
> a specific set of "rules".  Here are some specifics to limit rates:
>
> 1) Packets intended for consideration for RF must be flagged.  Flag could
> consist of RGATEx-X inserted in the IS path.  Such as:
> WB4APR>APVVVV,TCPIP*,RGATEx-X:packet_data_goes_here...
>
> 2) Packets flagged for RGATEs should be no more often than normal APRS
> packet rates.  Every 30 Minutes for benign fixed stations, every 10 minutes
> for operator-present stations, and a maximum for mobiles of 1 per minute,
> but must also be Decayed and Proportional-Pathed.
>
> 2) Such packets must use the APRS decaying algorithm.  Meaning, if the
> position or data is unchanging, then the period to the next packet is
> doubled down to the final rate of one per 30 minutes (same as all other APRS
> stations).
>
> 3) Such packets must use Proportional Pathing to add a sliding "weight"
> potential to each packet.  This weight can be selectively used by RGATES to
> best match his local loading.  The IS source would send every other packet
> to RGATE0-0. The alternating packets would be sent half the time via
> RGATE1-1 and the other half the time via RGATE2-2.  This in effect
> implements a 1, 2 or 4 minute rate selection potential while maintaining a 1
> minute rate on the APRS-IS.
>
> IGATE RGATING REQUIREMENTS:  The IGATE sysop can choose among a variety of
> settings:
>
> RGATE0-0 RANGE - sets the heard-range where these are gated
> RGATE1-1 RANGE - Sets the heard-range where these are gated
> RGATE2-2 RANGE - sets the heard-range where these are gated
>
> DIRECT = 0-0, 1-1, 2-2 will gate these RGATEn-N packets direct only
> ONEHOP = 1-1, 2-2  ... will gate these RGATEn-N packets only 1 hop
> TWOHOP = 2-2  ...  ... will gate these RGATEn-N packets only 2 hops
>
> RGATE0-0 LIMIT - Sets the number of such packets allowed per minute
> RGATE1-1 LIMIT - Sets the number of such packets allowed per minute
> RGATE2-2 LIMIT - Sets the number of such packets allowed per minute
>
> For example, a typical home IGate that (ideally) only uses a 1 hop RF path
> via the nearest local digipeaters might set his 1-1 RANGE to only include
> the reliable coverage area of his local digis and then set ONEHOP = 2-2.
> The result would be only one packet from any IS-mobile once every 4 minutes.
> Or he could set ONEHOP = 1-1,2-2 and then have these mobiles appear once
> every 2 minutes.  ETC.
>
> He sets the LIMITS as a failsafe mechanism.  There is also a BLOCK list
> where any abusers callsigns can be blocked if they try to induce spam.
>
> Something like that.
>
> Just an idea to consider.  What would need to be changed to allow this?
>
> Bob, WB4APR
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>