PATHS.TXT         DIGIPEATING PATHS IN APRS
Document version: 8.6.7  24 July 2004       
Author(s):        Bob Bruninga, WB4APR <bruninga@nadn.navy.mil>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Most of this info used to be in DIGIS.TXT from 1994 to 2004.  But
was recently split out because there was a need to separate the
PATH info that users need from the DIGI setup info that DIGIpeater
owners needed.

Understanding APRS paths is absolutely critical for understanding APRS.
Both PATHS.TXT and DIGIS.TXT are a "must read" for anyone who seriously
uses APRS.  Further, users must also read the on-line NEW N-N PARADIGM
concept that tells what is WRONG with many area digipeater
implementations of APRS on 144.39 and how many local nets are totally
saturated and what must be done to fix it.

   http://www.ew.usna.edu/~bruninga/aprs/fix14439.html

Digipeaters are the most important APRS asset, our lifeline if used 
properly, but a source of QRM and inconsistencies if not.  First, some
fundamentals...

APRS is built on these fundamentals:
1) A 1200 baud system operating as an ALOHA random access channel
2) A net cycle time of 10 minutes for local (direct or 1 digi ops)
3) A net cycle time of 30 minutes for area wide operations.
4) An ALOHA channel (with hidden transmitters) has an optimum
   throughput at about 20% of channel capacity for maximum reliability.
 
This means in a 30 minute period the most reliable throughput on
the local RF channel can be about 360 total packets.  Yes, you can
get MORE packets through, but at the EXPENSE of reliability (more
packets are lost due to collisions).  And the reliability falls
off much FASTER than any improvement in throughput.

DIGIPEATERS:  Digipeaters exist to extend the range of your local area
APRS network to serve useful communications needs that strive to use
these 360 packets per 30 minutes in a meaningful way.   Although the
use of APRS can be emotionally debated, it still boils down to the fact
that no more packets can be reliably shared among all people in a net
RELIABLY if these limits are exceeded.  By making some rough assumptions 
about what you want your network to support during EVENTS, or EMERGENCIES
or when you need RELIABLE communications, then it is easy to arrive at
the number of stations YOUR RF network can reliably support and therefore
how many digipeaters can be used to support that task. 

ALOHA CIRCLE:  This magic number of surrounding stations that can be
supported reliably on your local RF LAN is the ALOHA limit.  It is
about 50 users.  Looking at a map, draw a circle around your 50 nearest
users and that is your reliable APRS network range for that area.  It
might be only 15 miles in the middle of LA or it might be over 150 miles
in Wyoming.  The topology doesn't matter.  What matters is the number of
users on the same 1200 baud channel that can share it reliably with APRS.
 
Here is an example of how I came up with about 50 user stations...
 
TYPE STATION         PKTS/30m ea  Total  PCT of LOAD
-------------------  -----------  -----  -----------
30 Home stations            2       60      16  %
 3 LOCAL digis (evy 10m)    3        9       2.5%
 9 2nd-tier digis (evy 30m) 1        9       2.5%
 5 area WX stations         6       30       8  %
 4 Mobiles evy 5m           6       24       6  %
 4 Mobiles evy 3m          10       40      11  %
 4 mobiles evy 2m          15       60      16  %
 4 mobiles evy 1m          30      120      33  %

Since this represents the most number of packets that your local network
can handle in 30 minutes, this is what drives then how many digipeaters
and how many HOPS users must use to be able to communicate within this
network of local users.  

NETWORK OVERLOAD AND QRM:  These days, too many users are totally blind
to the limitations of the 1200 baud APRS national network and are not 
satisfied unless they can see hundreds and hundreds of users from the
5 surrounding states covering millions of square miles.  This is just
impossible and we must get users to only use the path necessary to cover
their ALOHA radius as noted above..  Trying to propogate packets too far
will KILL the APRS network due to too much QRM and lost reliability.

DIGIPEATERS:  The range of any AX.25 packet may be extended by specifying
one or more digipeater callsigns in the UNPROTO PATH.  The packet will 
be relayed by each such digipeater in turn.  After each such digipeat, 
that callsign is marked as used up so that at any instant, only the 
"next" digipeater in the list has the potential to digipeat the packet.  
For conventinoal packet, this requires users to know the complete intended 
path for their packets... But not in APRS.  

GENERIC ALIASES:  APRS satisfies its real-time, emergency tactical needs
without prior knowledge by using generic TO and DIGI callsigns.  Even
home stations in good locations can help surrounding mobiles if given the
generic digipeater callsign alias of RELAY and all digipeaters are aliased
as both RELAY and WIDE.   This way any station can use any digpeater 
by using an UNPROTO path of WIDE or he can use any other station as a 
digipeater by simply addressing the packet VIA RELAY.  With this generic 
digipeating, a mobile, or new station does not have to know anything 
about the network in advance in order to be seen by adjacent nodes.  
After 10 minutes and his map begins to show the location of all local 
stations and digipeaters on frequency, he can  then customize his outgoing 
Unproto path to specific digipeater callsigns to cover his intended
local area without as much QRM.  

ROUTES: It is important that as APRS networks mature with fixed, known 
digipeaters, that users at FIXED stations should avoid using the generic 
RELAY or WIDE addressing.  Although it still makes sense for mobiles to 
use the path of RELAY,WIDE, the path of RELAY should NEVER be used after 
the first hop by ANYONE, and never after a WIDE.  Remember, every packet
addressed via RELAY will key up EVERY APRS station that hears it.  In 
any but the sparsest areas, the result is congestion and collisions
which block anyone from copying the packet.  

APRS WIDE AREA DIGIPEATERS:  Wide area APRS digipeaters in sparse areas
should be widely separated to provide long distance coverage with the
minimum of hops.  If there is a need for interim digipeaters to fill in
weak signal areas or valleys, then a local RELAY should be installed as
needed but ONLY with the RELAY alias.  These days (post 2001) any RELAY
digi should do callsign-substitution so that the source of the packet
and location of the RELAY is included in every such packet.

TRACE DIGIPEATING:  At Dayton 97, PacComm introduced new TNC ROMs which
do callsign-substitution.  They insert their callsigns in place of their
generic RELAY and WIDE aliases whenever a packet is digipeated.  To
distinguish these new digis, we call them TRACE digis.  They show on the
map with an overlayed "T".  The big advantage besides callsign
substitution and route identification is that the substituted call is a
DUPE elimination mechanism because the digi will never digipeat a packet
that has its own callsign already used.  This eliminates looping
duplicate packets and was a great advance for APRS!  This was followed
in 1998 with Kantronics finally implementing my APRS WIDEn-N algorithm
which further improves long multi-hop effeciency.  (Though these days
(post 2003), FLOODING the network with long-hop WIDEn-N packets into
conjested areas is considered bad practice.)  These digis have an "N"
overlay.

WIDE DIGIPEATING:  ALthough in start-up areas any TNC can be used as a
WIDE digi simply by setting its MYALIAS to WIDE and its BText to include
its APRS position, this is NOT recommended today in areas in a mature
APRS environment.  Today, only TNC's with the PacComm 4.0 and
Kantronics 8.2 Roms or any of the newer improvements such as UIdigi and 
DIGI_ned, etc should be used.  Originally, the four generic aliases of
these digis were receommended to be RELAY, WIDE, TRACE and SS.  But now
we have dropped TRACE and so only RELAY, WIDE, and SS are required.
The 4th alias can be a second neighbor state or other local option.
The functions of each of these generic aliases are as follows:

  RELAY - The universal default for all APRS digipeaters and stations
          but ONLY used as the first hop.
  WIDE  - Provides generic WIDE area callsign-substitution digipeating
  TRACE - Identical to WIDE, but was used to distinguish the new
          TRACE digis from older WIDE only digis.  But WIDE only
          digis are obsolete and this distinction is no longer needed.
  SS    - Useful for state wide only digipeating

HOME STATIONS should no longer set their alias to RELAY by default.  That
was good back before we had a permanent network of digis, but is BAD now
unless the home station is in a favorable location, does callsign-
substitution, AND can serve local mobiles that cannot hit the nearest
digi otherwise.

TRACE DIGIPEATERS: The original distinction between WIDE and TRACE
digis was because a WIDE,WIDE,WIDE packet could end up going 27
different dupes in a WIDE only network.  But the equivalent
TRACE,TRACE,TRACE packet would only be digipeated by the new "TRACE"
digis and so duplicaiton wouild be eliminated for a total of only
about 9 packets because of callsign substitution and the resulting
dupe-avoidance.  But WIDE only digis are obsolete and most digis
now do callsign substitution, so these days it is safe to do a
three hop WIDE path again and so TRACE only remains as a naming
convention for these PACCOMM digis.


WIDEn-N DIGIPEATERS:  This was conceived back in 1994 as the most
efficient way to FLOOD APRS packets out multiple hops in all directions.
It was implemented as the UIFLOOD feature in the Kantronics TNC's.
ALthough it has tremendous power for FLOODING the network, it is almost
too much of a good thing now (2003).  This is because we no longer need
it in most populated areas:

  1) In 97 the APRS-IS began to use the Internet as an APRS backbone
  2) The number of users has grown from hundreds in 1995 to 20,000 now
  3) Most areas can't afford FLOODING by packets from far away!

Please see the COMPLETE WIDEn-N section further down this page to understand 
WIDEn-N routing.

MOBILES:  Mobiles typically use the path of RELAY,WIDE because they may
be out of range of a WIDE digipeater but be near someone's home station
acting as a RELAY.  Even if WIDE digipeaters are 30 to 50 miles apart, as
long as every home station and local RELAY digipeater can hit at least
one WIDE, then the mobile path of RELAY,WIDE can cover the local area well!  
Wider ranging mobiles can use the RELAY,WIDE,WIDE path without  
causing too much QRM because of their low antennas.  BUT CONVERSLY, 
paths starting with RELAY should NEVER be used by a *home* stations since 
he will undoubtly hit many home RELAYS all at the same time and therefore 
generate numerous dupes with every packet.

SHORT RANGE FOR MOBILES!  Mobiles have less than HALF the range of what
you expect compared to your normal experince with VOICE repeaters.  The
human ear will not consider a QSO to fail until it gets painfully noisy.
A packet signal will FAIL at the first even ONE millisecond of a single
fade.  And SINCE mobiles ALWAYS pass through 6 to 30 dB fades due to
multipath, then the effective range of a mobile is much less than half
of what it is for voice.  SO be sure to take this into consideration in
your PATH planning.  APRS852 reduced all PHG circles by half to
compensate.

FEWER HOPS:  Although you are tempted to set a LONG path so everyone can
see you, remember that to them, you are just QRM.  Especially since the
amount of QRM you generate grows geometrically with the number of hops
as shown in the following table.  ALSO the probability of a successful
packet also goes down greatly.  The following table shows the decreasing
probability of a successful packet if we assume a 50% probability of
collision and each WIDE can hit 4 other WIDES.

HOPS  PROBABILITY  #COPIES COMMENTS
----  -----------  ------- --------------------------------------
 1        50%         1    For local ops & special events
 2        25%         5    Routine ops
 3        12%        13    extended ops
 4         6%        25    statewide ops Heavy QRM
 5         3%        41    Nothing gets through.  Too much QRM
 6         1%        61    Useless AND totally boggs down network

PLEASE limit your hops to just your local region.  APRS *IS* designed to
assure delivery to EVERYONE in a 1 or 2 hop area for REAL-TIME nets or
events.  It was NOT designed for large extended area nets with thousands
on line...  These days you CAN QSO great distances via the IGates, but
this is still a LOCAL process with only enough hops to get to your IGate.
As MORE people come to APRS, we must begin thinking SMALLER areas...

In general all digipeating should be turned OFF in mobiles except in 
very specifically needed instances of special roving digipeaters.  You 
can imagine what it wouild be like at a Hamfest if as the mobiles
converged they all began digipeating each other...

                                       
OPERATIONS WITH RELAY AND WIDE:

The GENERIC WIDE/RELAY digipeating works very well in local areas to
assure good reliable local coverage.  But care should be given to the
use of WIDEn-N routing in BUSY areas.  In many cases, the abuse of
WIDEn-N large hops by many users brings in just too much DX interference
to local operations.  Users must remember that typically, the 1200 baud
channel can only support about 50 users in any given RF area.  It doesnt
matter if this area covers only 10 miles in LA or a million square miles
in UTAH, a 1200 baud channel just cannot handle any more packets without
severe loss of reliability.

SEE  HF.TXT  for setting up your UNPROTO path for HF and HF/VHF gateways.


*********     WIDEn-n ALL DIRECTION GENERIC DIGIPEATING!     ************
  THE ULTIMATE SOLUTION (back in 1994) FOR MOBILE POSITION REPORTING

Since 1994 I had asked for this capability, and it was finally 
implemented in 1998 Kantronics TNC's.  The WIDEn-n digi simply repeats 
ANY packet with the VIA address of WIDEn-n; but ONLY ONCE.  It keeps a 
copy (or checksum) of the last 30 seconds of packets, and compares each 
new packet that it hears with these last ones to avoid dupes.  This 
eliminates the multiple looping of packets caused by multiple generic
paths such as WIDE,WIDE,WIDE  when callsign substituting digis are not
used (as many as 21 copies!)  In a WIDEn-n  network, however, there
would only be three packets outward bound 3 hops.  (It still generates
over 21 packets because it floods all surrrounding digis with packets,
but at least there are only one copy per digi)...

NUMBER OF HOPS:  The "n" in the WIDEn-n path indicates the number of hops.
Each DIGI that repeats the packet decrements the WIDE-SSID by one.  So the
-n decrmenets to zero but the WIDEn portion indicates the original number
of hops so that recepients know how far it traveled.  A long distance
traveler or special event of wide interest might have used up to WIDE3-3
but a local commuter may have only wanted to use WIDE2-2 to limit QRM.

SHORT PACKETS!  THe advantage of the WIDEn-n routing is that every packet
still only has one DIGIpeater call.  THis means only 7 bytes of overhead
no matter how far the packet goes...   This saves 21 bytes in every
packet for a 4 hop example.  (though 4 hops in most areas is considered
bad practice these days)...

SOURCE IDENTIFICATION:  However, a disadvantage of WIDEN-N routing is
that the SOURCE of where the packet entered the system is not carried
forward.  This is easily solved by users initiating their paths with
the path WIDE,WIDEn-N.  This way, the first digi does call substitution
and then the remainder count down the N's.  This is now the universal
recommendation, to always start a WIDEn-N packet with WIDE,WIDEn-N.
BUT this only works if the local digis have kept the default NOID option
in place so that the subsequent digis don't overwrite the initial call.
DIGI owners must make sure that UIFLOOD settings have ID set to NOID.

VICINITY PLOTTING:
It is FAR MORE IMPORTANT to know the FIRST digipeater that a packet hit,
not the last.  This is very powerful since it lets recepients estimate
the position of a station based on what initial digi he is hitting no
matter what his packet contains. This is automatic in APRSdos which will
plot the station as a QUESTION mark ICON within about 1 mile of the
first DIGI.

These are called "vicinity plots" and give you an approximate area until
you finally get a real position packet later..  HOWEVER, If ID is ON
at ANY digipeater in the path, then the FIRST digi identifier is
obliterated and lost.  Packets then arrive with the wrong DIGI field
and this capability is lost.  So never set ID to ON.  Leave it as the
default of NOID.

For more on this topic and the damage that the "ID" setting does to an
APRS network, be sure to see the file:

          http://www.ew.usna.edu/~bruninga/aprs/id-noid.txt

UNIVERSAL APRS USER PATH:
--------------------------

Now for all the reasons above, the universal APRS path is WIDE,WIDE2-2
ion areas that support WIDEn-N.  (Though these days to minimize QRM
most areas are encouraging only 2 hop WIDE,WIDE paths)....  By starting
each path with WIDE, there are two advantages:  1) it is universal and
will work anywhere.  2) It does callsign subsititution so that the
same digi will never digipeat that packet again and so that you can see 
where the packet entered the network.


TROUBLESHOOTING AND TRACING:
----------------------------

Notice, however, that WIDEn-n packets arrive as WIDEn-0, showing that it
took n hops, but the receiver has no idea how it got to him.  Originaly,
all WIDEn-n digis also supported TRACEn-n, which not only decrements the n,
but also INSERTS its own call.  This way a TRACEn-n packet arrives as
DIGIa,DIGIb,DIGIc etc.  Although this is very powerful, it also makes the
packets grow in length for longer hops.  But these days, since long hops
are not desired anyway many areas are renaming the TRACEn-N function for
other special applications called LINKn-N, LANn-N and others.  See the
web page: (google for fix14439.html).

***** WARNING:  These WIDEn-N, TRACEn-N and other special digipeater
functions are so powerful, that they should never be enabled at homes,
but ONLY at HIGH WIDE sites.  If it is enabled at any  home stations,
this will SEVERLY QRM the network... Only the UIDIGI alias of RELAY
can be used at user stations.

ORIGINAL LEVEL FOUR NETWORK CONSIDERATIONS:

These concepts were proposed in the early days of APRS but have never
caught on...

Since NODES are smarter than digipeating, the ultimate we should have
NODES do all UI frame routing via high speed  backbones.  The APRS
station simply sends his UI frame TO APRS VIA HOME;  Any NODE hearing
that transmission that has knowledge of the route to HOME, will send
the single packet via the NODE network (level 4) to the HOME node!
When it arrives at the HOME node, it is transmitted once as a UI frame.
With this arrangement, a mobile only has to specify his one intended
destination, no matter where he travels!  In this example I use
the DIGI call of HOME just to represent the digi near someone's HOME...

DIGI/NODE COMPATIBILITY:  Mobiles should be able to specify a path that is 
compatible with both nodes and digipeaters.  The nodes should only look at 
the LAST digi field in an UNPROTO list for the final NODE destination.  
Any preceeding fields are assumed to be DIGI's only.  This way a path of
APRS VIA WIDE,HOME would be repeated by any WIDE that heard it, but any
level 4 node that heard it would forward it to the HOME NODE.  If only one 
field is included in the digipeater string, it would be interpreted as 
both a digi and a HOME destination without any difficulty.  Digi's and 
NODEs would digipeat it, and nodes (hearing it direct) would forward it at 
level-4.

SPECIFIC NOTES FOR APRSdos USERS:

NOTE: In APRSdos your maximum reporting period is dependent on the length
of your digipath.  This is so that at a special event or local area, using
direct or one hop, then your net-cycle time is 10 minutes.  Two hops is
20 minutes, 3 hops is 30 minutes etc up to the maximum value in your
CFIGxxx.APR file.  Currently the MaxTime defaults to 30 minutes.

WHERE ARE THE DIGIS?   Use the MAPS-OVERLAY-DIGIS command to see the 
location and range of all APRS digis no matter where you are.  Please 
NOTIFY Jeff of dididahdahdidit.com of any new digipeaters so
that he can update the original DIGIS.POS file.

The DIGIpath page in APRSdos lets you see what digi paths other stations 
are using and it also marks stations that you can hear direct.  Also under 
the OPS-DIGI command, users can save up to 12 different unique DIGIpeater 
paths.  Users can select any given path that is optimum for their present 
application with a single key stroke.  The MAPS-PLOTS-POWER command will 
display a range circle around all stations proportional to their power, 
and antenna.  Users can use these plots to estimate what paths, through
what stations, might be useful.


de WB4APR, Bob
