[aprssig] The Current Meaning of WIDEn-N

[Kenneth Finnegan]

Gentlemen,

I've been working on analyzing the APRS network stack behavior for my
masters thesis in EE at Cal Poly SLO and I've been collecting a few
questions that I haven't been able to find satisfying answers to in
the 43,000 emails in the SIG archive and the rest of the stacks of
primary sources I've dug through.

What is the CURRENT meaning of the first n in WIDEn-N? As I have
traced the two or three "new" paradigms for replacing RELAY,WIDE,WIDE
the meaning of the first number in WIDEn-N has gotten quite muddled to
the point that I can't convince myself that it means anything.

According to my research:

Originally, WIDEn-N replaced repeated WIDE,WIDE,WIDE, yielding a much
shorter routing path that allowed each digipeater to decrement the
second number until it reached zero instead of marking another WIDE
alias as used. Therefore, an incoming packet with a route of WIDE3-1
would indicate that the originating station requested three hops and
there is one remaining. This was important at this point since TRACE
was still a separate concept and without an originating request
number, you wouldn't know how far the packet has already gone.

This left us still with the non-"n-N" RELAY alias, so a typical path
would look like "RELAY,WIDE2-2" Due to a bug (omission?) in a major
digipeater firmware revision, they did not perform duplicate
suppression between these two aliases (any two aliases? any non-n-N
aliases?). I haven't been able to find any primary sources on this,
but it appears that at some point around 2005 we deprecated RELAY.
This left us without a low level digi alias for less intelligent digis
to use for hardware that didn't support WIDEn-N.

The solution was to dedicate the alias WIDE1-1 to replace RELAY, which
leaves us with the issue that there is no "proper" way to express a
single WIDE hop correctly. This was solved by "pre-consuming" the
first hop in a two hop request and start packets with WIDE2-1. As far
as I can tell, this brings us to the present, where low level digis
respond to WIDE1-1 and high level routing paths start as either
WIDE2-1, WIDE2-2 or WIDE3-3.

I found this very surprising, since that was not how I had originally
been explained the WIDEn-N concept several years ago by my Elmers.
They had explained it that WIDE1-N was requesting hops from "level 1"
or low level digis. WIDE2-N was then requesting "level 2" hops through
higher level digis, and so on.

What bothers me is that using the first number as a "level" of the
alias makes more sense to me than as the originating number of hops,
since we have also deprecated TRACE at some point in the last nine
years, so the need for knowing how far a packet has already gone can
now be met by the fact that every well behaving digi should trace on
every packet (I think?). The "originally requested hop count" value is
redundant, and meaningless since we're promoting originating paths
like "WIDE1-1,WIDE2-1."

Another change since the original deprecation of RELAY is the
development of the idea of preemptive digipeating, where a path of
"DIGIA,DIGIB" received by DIGIB would be handled by marking both hops
as used before re-transmitting it ("DIGIA,DIGIB" --DIGIB-->
"DIGIA*,DIGIB*"). It seems like this concept in addition to distinct
aliases for high and low level digis would be useful for the network;
particularly so in places like California where I'm doing my testing.
When my mobile path of "WIDE1-1,WIDE2-1" reaches an 8000' high WIDE
digi directly, it only consumes the first hop and I'm left requesting
a second hop from the next ring of California digis 150 miles out.
When I change my path to a single WIDE2-1 or WIDE1-1 (I don't know
which is correct), I can finally stay within my ALOHA circle but the
low level digis in places like San Luis Obispo county (tight hilly
areas with very deep valleys) consume my single hop and I'm never
repeated by the high level digis and heard beyond 3-5 miles.

Even if the low level digis only responded to WIDE1-1 (a behavior
which I don't see), this leaves me with the dilemma of either
requesting WIDE1-1 and having my hops consumed by low-level digis,
WIDE2-1 and never get digipeated by low digis so 80-90% of my traffic
is lost in valleys, or WIDE1-1,WIDE2-1 and intermittently show up 200
miles away.

Furthermore, analysis of bulk APRS traffic from APRS-IS is showing
850ppm of packets being Igated with paths containing hops such as
WIDE1-2 or WIDE2-3, which are complete non-sense according to any of
the official meanings for WIDEn-N.

Have I missed one of the new "new" paradigms with respect to WIDEn-N,
or am I seeing evidence of confusion on the part of users?

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/