[aprssig] Packet routing, path specification.

[Robert Bruninga]

Actually, I did not mean for this too sound so strongly. 
 I only wanted to point out that different people use APRS 
in different ways, and there are pitfalls in trying to 
force a single "solution" on end users...  I think it best
to minimize restrictions, but just lay groundrules and
ask users to respect the bandwidth shared by all is
the best way.  Bob

>>> bruninga at usna.edu 06/22/05 1:35 PM >>>
>>> rtg at aapsc.com 06/22/05 12:58 PM >>>
>   I keep coming back to the desire that the network 
>manage itself, and minimize or eliminate the need 
>for the end-user to know the topology of the network

This is ideal if you can get everyone to agree exactly
what the single application is.  But APRS was never
intended as a single solution to only one aspect of
HAM radio.  THis approach that the local SYSOP will 
decide how APRS is used violates the fundamental
intent of APRS.  It forces all uses of APRS to one and 
only one application concept and only the application in 
the mind of the local sysop.

APRS was not an end in itself.  It is only the end
user display of information.  There are all kinds
of uses (ignored by many pepole who only see
it as vehicle tracking):  DFing, WX, SAR, local
nets, ECHOlink user facilitation, Satellite
tracking, and on and on..

There is no one-network fits all applications.
I think the user is the one who SHOULD best
know how to use the network for his specific
immediate need.  Having draconian sysops
forcing their view on where your packets should
go is one way to pretty much kill the flexibility
of APRS.

>>> rtg at aapsc.com 06/22/05 12:58 PM >>>
>   I keep coming back to the desire that the network 
>manage itself, and minimize or eliminate the need 
>for the end-user to know the topology of the network

 in the neighborhood they just happen to be passing thru.
   I keep coming back to the following concept:

   A digipeater sysop manages local traffic by defining their own service 
area, and refuses to digipeat any packets originating outside that service 
area, no matter what the path specification.

   Out of this basic concept, we get only three possible path 
specifications:

   a)  No VIA.  Local point-to-point coverage only.  Great for high-density 
special events like Dayton, Aeronautical mobiles, etc.  Will be gated to 
APRS-IS if heard by an IGate.

   b)  VIA APRS.  Means 'digi me as far as congestion allows'.  The digi 
looks at the position in the packet and will digi if it's in the current 
service area.  Will be gated to APRS-IS if heard by an IGate. (if the 
'already digipeated' bit is on, perform dup-checking before 
digipeating again.)

   c)  VIA XXyy.  WHere XXyy is a Maidenhead grid square.  Digis will treat 
this like VIA APRS, and IGates will gate this back to RF only if XXyy is 
within their service area.  Since the object position itself is 'remote', 
such packets will not be further digipeated once gated back to RF.

   This third option allows for Bob's special needs, taking advantage of 
the APRS-IS as a 'tunnel'.  The Cadets at the academy can watch the 
football, even if the RF network is saturated that weekend, and the sysops 
have shrunken their service areas accordingly.  His Mother can watch his 
progress to Thanksgiving dinner.  Long-haul truckers could also 'direct' 
their packets back to home, etc.  And congested areas in between wouldn't 
have to suffer from the additional traffic...

-- 
Rick Green

"They that can give up essential liberty to obtain a little
  temporary safety, deserve neither liberty nor safety."
                                   -Benjamin Franklin

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig