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

[Steve Dimse]

The only way to make this work without rewriting all IGates (impossible since most are not actively supported) is to run a separate program that looks at the traffic on the APRS-IS and decides what to transmit. When it finds a position it wants to put on its local RF network it can either send directly if it has a radio, or inject a message from the Internet station to a local but unmanned RF station into the APRS-IS, thereby having the local IGate do the heavy lifting of sending the courtesy posit along with the message. The down side of using the APRS-IS to force the posit is the message does go on RF, wasting local bandwidth. It does mean running this program in every local area, or at maybe writing a central one that users could configure for their own area. It would be a long time until this would be something people would expect to find in a given area.

And for those who aim to prevent new features based on potential for abuse, this program would certainly have that!

Steve



On Dec 28, 2011, at 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
>