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

Christensen, Eric CHRISTENSENE at MAIL.ECU.EDU
Tue Feb 15 10:58:45 EST 2005 

We see the same thing here in Eastern NC...  A guy was using two hops to
cover the state yesterday (or that is when we really noticed...)

73s,
Eric KF4OTN


> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org 
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of William McKeehan
> Sent: Tuesday, February 15, 2005 09:50
> To: aprssig at lists.tapr.org
> Subject: Re: [aprssig] APRS routing strategies (was: New n-N 
> success in North Carolina)
> 
> 
> 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
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>

More information about the aprssig mailing list