[aprssig] MGATES for IS-Mobiles

[Andre]

Op 27-12-2011 19:48, Bob Bruninga schreef:
> 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
>
>
Bob, why do you keep insisting on cludging up an already messed up 
system of tocalls and paths?
using the tocall for selecting localised gating means the mobile phone 
can not use mic-e for it's position nor can it use altnets, worse it 
will be seen as altnet by other software and might not display them or 
if any other software is being used they will not process any other 
stations, bad idea.

73 Andre PE1RDW