[aprssig] Why Not "Gate in Vicinity" (phones)

[Bob Bruninga]

For the sake of discussion... (read it all before responding, since, towards the end, I agreed with Pete about the problem)...

> IGates don't send gated packets with their APRS-IS paths.  > They are sent using third-party format.  
> Paths on APRS-IS have no meaning when gated to RF 
> other than to determine if the packet originated 
> on APRS-IS or on RF.

Agree.  That is why I proposed the new keyword PGATE.  This is a way that a Phone APP can signal its desire to be gated locally.  And it is a target that new IGate software can begin to recognize as such a request..

> But the problem stems back to the IGate becoming 
> the arbiter on what gets gated to RF and must 
> ensure proper operation.  

Agreed.  But I am OK with giving IGates that responsibliity if they want it.

> Since it is impossible to reasonably differentiate 
> between one type of Internet connected client and 
> another and because you can't ensure proper client 
> configuration, the idea of "gating to RF if in the
> vicinity" leaves you open to numerous issues including
> stations "spammng" the local RF.

The PGATEn-N path gives us the differentiation. True, Spamming is a problem to be addressed.

> you are back to having indiscriminate spamming of a 
> frequency... (if the channel is loaded, even a 
> "reasonable" gate rate could cause it to be unusable 
> for communicating). 

Agreed.  But I'm taking the idea that a mobile Ham with a smart phone in an area should get equal access to the local ham channel as anyone else.  Hence the 1 minute direct, 2 minutes via one hop and 4 minutes via 2 hop restriction.

> this is not a "let's see if we can get cell phone 
> generated beacons seen on RF issue"..

Well, actually, that is what I am now focused on, and I think it is a good project to work out if we can find a way.

> This is a more basic issue of what is APRS-IS and 
> what is the function of IGates. ... Everything beyond
> [the classic function] is simply an IGate sysop's 
> decision of what else they can -safely- gate to 
> RF that might be of interest to the local RF operators.

True.  But one of those things is to allow traveling hams in the area (with only their phone) to join in the local RF net.  

> That decision has nothing to do with who might be 
> in the area on APRS-IS only. 

Agree.  It is a two part decision.  The decision by the mobile ham with a smart-phone app to transmit his positions so he can be seen by nnearby RF mobiles, and then the second part of the decision by the local IGate operator to enable the "PGATEn-N function" so that said mobile can be seen.

Now I see Pete's concern. And it is Valid!  Anyone then can generate SPAM in Dallas from anywhere in the world by putting local objects all over the dallas map from the IS.  And that is Pete's point, that there is no way an IGate can smartly separate the spam from the legitimate Phone mobile.

I take the problem as a "challenge", since I think the goal of seeing a mobile PHONE in the area is a good capability to have.

One method is to simply enhance the present IGate Messaging COURTESY position packet.  That a traveling PHone app would not be gated to RF, unless he RECEIVED an APRS message from a local RF station.  Example:

Phone traveler enters an area.  Sees local RF activity on his IS app.  He sends a message to another MOBILE or HUMAN operator saying "CQ, I'm traveling through".  If the HUMAN responds to that message with a response, then that opens the PGATE for his posits for a while.

I like this.  It gets humans talking to humans.  And the responsiblity for opening the PGate is from the inside by a real human.

Something like that?

Bob, WB4APR

>> -----Original Message-----
>> From: Bob Bruninga
>> Sent: Monday, December 26, 2011 12:24 PM
>>
>> Can the APP be required to inject packets using the
>> Proportional Pathing Algorithm.  That is:...