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

[William McKeehan]

I have been watching this discussion with some interest.

Being new to APRS, I don't have the best understanding of how all of this
works, but I do have an idea that I would like to toss to the group for
discussion.

I'm thinking about having some paths like this:
CITY
COUNTY
REGION
STATE
IGATE

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 for
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 APRS-IS,
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 doing
>> is putting
>> a cap on the number of hops a packet can take beyond you.... what I'm
>> 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 way
> 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 the
> 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 this
> 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 decide
> on a mechanism for rewriting such a path; probably a total rewrite is
> in order.
>
>
>
> While we're talking about hypothetical new hardware, we can designate a
> 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, provide
> 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*" (flagged
> as digipeated) as the first call in the path would work.  We could use
> 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 if
> it had not been transmitted by another digi/router.
>
>
> There is also the issue of the APRS router acting as a standard AX.25
> digipeater.  We are making assumptions on the path and modifying it to
> suite an ARPS network, and the operations may not be compatible with
> standard AX.25 operation.  Once choice is to designate this device as
> ARPS-only - no other AX.25 operations would be allowed.  Another method
> would be to try and figure out if we're handling an APRS packet or not
> and act accordingly.  This may be possible by examining the destination
> address, and see if it matches one of the generic APRS addresses or an
> 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 to
> "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
KI4HDU
Internet: mckeehan at mckeehan.homeip.net
http://mckeehan.homeip.net