[aprssig] Packet routing, path specification.
Robert Bruninga bruninga at usna.eduWed Jun 22 19:09:43 UTC 2005
- Previous message: [aprssig] NOSaprs update - cross port digi with callsign substitution
- Next message: [aprssig] Packet routing, path specification.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
And that was another reason for the New-N was simply to greatly simplify APRS paths for the user down to only one universal receommendation WIDEn-N. Then user education can do its job. Before we had a mess of confusion in RELAY, WIDE, TRACE ,SS ,WIDEn-N and TRACEn-N not all of whcih worked everywhere. No wonder user educatino didint work, because there everywhere was different.. Now we can get back to education. Let the users then learn how to properly use APRS to do the job that they have at hand. Bob >>> bruninga at usna.edu 06/22/05 2:43 PM >>> 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 _______________________________________________ aprssig mailing list aprssig at lists.tapr.org https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
- Previous message: [aprssig] NOSaprs update - cross port digi with callsign substitution
- Next message: [aprssig] Packet routing, path specification.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
