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

Tue Feb 15 09:50:05 EST 2005

I totally disagree with CITY being equivalent to WIDE2-2 and COUNTY being
equivalent to WIDE3-3.

In my area, one hop will cover CITY and COUNTY, two hops will cover the REGION
(all of East Tennessee), three hops are bringing in packets from over 300
miles away in all directions.

For me, a three hop path (WIDE,WIDE,WIDE) is bringing in packets from the
Florence, South Carolina to Birmingham, Alabama to Lexington, Kentucky to
Harrisburg, Virginia.

Certainly a bit larger than any county that I have lived in!

On Tue, February 15, 2005 9:14 am, Robert Bruninga said:
>>>> mckeehan at mckeehan.homeip.net 2/14/05 3:53:44 PM >>>
>>I'm thinking about having some paths like this:
> CITY
> COUNTY
> REGION
> STATE
> IGATE
>
> Its a reasonable concept but is equivalent to this:
>
> WIDE2-2 = CITY
> WIDE3-3 = COUNTY   <== saturates channel in dense areas
> WIDE4-4 = REGION    <== saturates channel in dense areas
> SS5-5      = STATE
> WIDE2-2 = WORLD
>
> 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.
>
> Bob
>
>
>
> 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
>
> _______________________________________________
> 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