[aprssig] APRS routing strategies (was: New n-N success in North Carolina)

Robert Bruninga bruninga at usna.edu
Tue Feb 15 08:14:12 CST 2005

>>> mckeehan at mckeehan.homeip.net 2/14/05 3:53:44 PM >>>
>I'm thinking about having some paths like this:

Its a reasonable concept but is equivalent to this:

WIDE3-3 = COUNTY   <== saturates channel in dense areas
WIDE4-4 = REGION    <== saturates channel in dense areas
SS5-5      = STATE

Problem is it would take all new hardware at over 1000
digipeaters and would not make sense until the majority
had switched over.  APRS for travelers needs consistency.


CITY would be equivilant to a single hop path, like a WIDE.
COUNTY would restrict the packet travel to the COUNTY
REGION would restrict the packet travel to the REGION (depending on
where you
are in the world, this could have different meanings)
STATE would restrict it to the STATE
IGATE would only be digi'd if the DIGI has recently heard an IGATE

This would let the user define how far out his beacon should propogate
- yeah,
it would require some more smarts on the part of the digi's and it may
not be
something that can easily be accomplished.

I think this would work well for position beacons, but not very well
sending messages. For messages, I see source routing as a pain and
would like
to simply address messages like an e-mail and have the digi's know how
to get
the message to the destination; this could be pretty easy with the
but I do not see how to do it with RF only without source routing.

Just some ideas - rip it apart :-)

On Mon, February 14, 2005 3:01 pm, Jason Winningham said:
> On Feb 12, 2005, at 4:20 PM, Wes Johnston wrote:
>> I love a good discussion....
> yep. (:
>> Well, yes, we are kinda saying the same thing.... what you are
>> is putting
>> a cap on the number of hops a packet can take beyond you.... what
>> suggesting is that we pass it along as-is it hasn't hopped too many
>> times
>> already....
> OK, I see the difference now, and I see some merits for both
> approaches.  I need to draw myself some pictures.  There may be a
> to use a combined approach, or have it user-configurable for the
> digi/router operator.
> I haven't brought it up yet to keep examples simple, but when the
> router is calculating the requested number of hops (or the number of
> hops already taken) it should examine the _entire_ path, not just
> first unflagged call.  some example pseudo-code:
> total_hops_requested=0
> for each call in path
> 	total_hops_requested = total_hops_requested + hops requested by
> call
> ... and the hop count limit code from before:
> hop_count=total_hops_requested
> if total_hops_requested > max_allowed_hops
> 	hop_count = max_allowed_hops
> hop_count--
> if hop_count > 0
> 	transmit packet
> This would allow only a sane number of hops for a path like
> WIDE2-2,WIDE2-2,WIDE2-2,WIDE2-2,WIDE2-2,WIDE2-2.  We'd need to
> on a mechanism for rewriting such a path; probably a total rewrite
> in order.
> While we're talking about hypothetical new hardware, we can designate
> new path specification: Hn, the letter H followed by a single digit
> indicating the number of hops requested.  H3 would be equivalent to
> R,W,W, or R,W2-2, R,R,R, etc.  Or, we could stick with WIDEn-n,
> for an abbreviation of Wn-n and drop RELAY.
> I'm not sure of the consensus on the value of a path trace, but it
> would be simple to make adding the call of the router to the path,
> e.g., H3 is path received by router KG4WSV-7, "KG4WSV-7*,H2" is the
> path as transmitted.  I haven't examined the possibility of adding
> flags, but maybe something like inserting a call of "FLxyz*"
> as digipeated) as the first call in the path would work.  We could
> flags for things like
> - "add a trace to this packet"
> - "digipeat only until I get to an Igate"
> - "this packet should stay within the area/state/region/etc"
> - "this is a serious situation and I _need_ for this packet to go 7
> hops" (to override hopcount reduction)
> There should probably be a "first hop only" router, analogous to the
> current RELAY only digi.  This device would transmit a packet only
> it had not been transmitted by another digi/router.
> There is also the issue of the APRS router acting as a standard
> digipeater.  We are making assumptions on the path and modifying it
> suite an ARPS network, and the operations may not be compatible with
> standard AX.25 operation.  Once choice is to designate this device
> ARPS-only - no other AX.25 operations would be allowed.  Another
> would be to try and figure out if we're handling an APRS packet or
> and act accordingly.  This may be possible by examining the
> address, and see if it matches one of the generic APRS addresses or
> ALTNET designated by the digi/router operator.
> It seems to me that the APRS network is busy enough without non-APRS
> traffic on the frequency, so it wouldn't necessarily be a bad thing
> "break" non-APRS packet operation.
> -Jason
> kg4wsv
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 

William McKeehan
Internet: mckeehan at mckeehan.homeip.net 

aprssig mailing list
aprssig at lists.tapr.org 

More information about the aprssig mailing list