[aprssig] MGATES for IS-Mobiles

[Georg Lukas]

* Bob Bruninga <bruninga at usna.edu> [2011-12-27 22:19]:
> > WHY?  Why are they any different than the thousands of other 
> > Internet-only connected clients?  
> Because they are local, in the RF area, and doing something... with a
> real-live-HAM-operator present.  Unlike most of the other
> lights-on-nobody-home stations...

That might or might not be true for any other APRS-IS client. I think
that "run on a smartphone" is the least usable distinguishing factor. I
would rather suggest one of the following:

 * mobile (i.e. changing its position)
 * operated by a human (any kind of activity on the UI)

which would then trigger a "forward this to RF please" flag (see later
for details).

> We should be working for a way to enhance it for the mobile operator, not
> stay stagnant with the limitations of the 1997 APRS-IS.

Amen!

> > As I said before, your intent is noble, the implementations proposed
> > are not.
> OK, I am completely open to any suggestions on how to enable this.  I'm just
> making suggestions because I do not see anyone else taking a positive
> attitude towards finding ways to make it possible.

So far we have seen two different issues which might need solving:

a) APRS-IS authentication (to prevent abuse); I wrote a lengthy post on
it at the end of http://tapr.org/pipermail/aprssig/2011-December/038279.html

and

b) IS-to-RF forwarding (IMHO, best implemented as an option on the
igate, with range limitation and throttling per callsign + message /
callsign + other packet, and global throttling to prevent flooding by
different IS stations)

> > No one should ever assume that just because they have a broken 
> > TOCALL (your suggestion causes us to not know what software 
> > is generating the packets and it does not adhere to your TOCALL 
> > standards).
> Easily fixed.  Make it MGvvvN where MG means a mobile-gate request.  VVV is
> the version number and N is the hop number.

I am strictly against changing the TOCALL to implement _even more_
semantics. However, IIRC, the path before the TCPIP* is ignored anyway
(as it contains the path before a packet reached IS), so I would rather
see it an option to add a path element there which asks for forwarding
via HF.

However, I still do not see the reason for distinguishing between
classes of IS applications (some which want to be forwarded to RF, and
others which don't? why would anyone want to implement the latter at
all?). I would rather use a "station has moved" semantic on the iGate,
even if it is not perfect either.

> I do agree with you about the potential for SPAM.  But I'd prefer to look
> for ways to control that, rather than not do anything at all.

I think that a throttling setting, which the igate op has to adapt to
his local channel conditions (1/min on an idle channel; 1/5min on a
crowded channel) can successfully solve that problem, even in the case
where somebody tries to abuse local RF.


73 de Georg DO1GL
-- 
APRSdroid - Open Source APRS Client for Android ++ http://aprsdroid.org/m
     ++ https://market.android.com/details?id=org.aprsdroid.app ++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20111227/d76fdafa/attachment.asc>