[aprssig] MGATES for IS-Mobiles

[Bob Bruninga]

Topic:  How does a mobile-APP with IS-access get to be seen on the local RF
net?

> But there is only one path component for an
> APRS-IS-originated packet and that was, is, 
> (and must always be for backward compatibility) 
> TCPIP* per the link I quoted [below].

But, I think it is time to consider moving forward...

>> http://www.aprs-is.net/Connecting.aspx
>> Packets originating from the client should only
>> have TCPIP* in the path, nothing more or less
>> (AE5PL-TS>APRS,TCPIP*:my packet...).

OK, but there is no restriction on the TOCALL.  So I suggest then that the
TOCALL for a mobile Phone/Tablet/Laptop client with direct APRS-IS access
then could use the TOCALLs of MGATE0, or MGATE1 or MGATE2 based on the
PROPORTIONAL PATHING sending algorithm for the every-1minute packet, for the
every-other-2minute packet and for the every-other-4minute packet.

> The local MGate sees that "MGATE-N request" and then compares
> it to its own RF path settings to determine if this is a 
> packet to be gated to RF (in range).  Once that decision is made, 
> on that one packet, then the packet is actually gated to RF 
> following all existing rules.

So, This establishes the following concepts for APRS-IS packets with these
TOCALLS:

Mobile APRS APP - ORIGINATION RULES:

MGATE0 - Originated no more often than once a minute
MGATE1 - Originated no more often than once every other minute
MGATE2 - Originated no more often than once every 4 minutes

Fixed IGATE HANDLING CONCEPTS for HANDLING MGATEx packets:  The decision of
the MGate is based entirely on its own outgoing path for IS-to-RF packets.
Also, the object should be within X, Y or Z distance of the MGATE to be
considered for RF.   If the MGATE's existing path is:

SIMPLEX, DIRECT - Then OK to TX-to-RF any MGATE0 packet
One - local HOP - Then OK to TX-to-RF any MGATE1 or MGATE2 packet
Two - area hops - Then OK to TX-to-RF only MGATE2 packets

The result is that the wireless IS mobile passing through then is
transmitted locally using the same Proportional Pathing Algorithm as we have
implemented in all Kenwoods and yaesu's.  Thus the mobile with this APP
appears to all nearby RF mobiles as part of the net.  I think this is a
legitimate objective.

Now then,  there probably need to be additional heuristic tests to protect
against spamming.  That is a risk I am willing to take given the benefit to
APRS when this capability is used correctly.  With the 3 different rates of
1, 2 and 4, already there is a 4-to-one throtteling capability based on the
MGATE's own decisions.  If this capability is abused, then simply that IGate
operator turns off the MGATE function.

We have got to find a way to accept these mobile hams into the APRS-RF
network as long as they do not generate any more traffic than a similar
mobile on RF would generate.  Remember, our objective for the last several
years for APRS communicating is "any ham device, any time to be able to
communicate with any other ham with any other wireless device".  This goal
was developed for TEXTING, but we also need to see where the other guy is.
I know this is already provided for under existing architecture, but the
"courtesy packet" is very unreliable since it is only TXed once every 30
minutes.

Bob, WB4APR