DIGIS.TXT         DIGIPEATER SET UP IN APRS
Document version: 8.7.3 19 Feb 2005 (Previous was 867 of  24 July 2004)
Author(s):        Bob Bruninga, WB4APR <bruninga@nadn.navy.mil>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In Nov 2004 and then in earnest in Feb 2005, we launched a major new
Paradigm for APRS digipeating called the New n-N Paradigm.  In summary,
it brings about a drastic reduction in QRM to the APRS network by
encouraging the use of WIDEn-N for small values of N and by discouraging
the old WIDE,WIDE and RELAY,WIDE paths that can produce 3 to 5 times
the number of dupes as the more efficient WIDEn-N system.  It also
provides custom traps for large values of N depending on local loads.
This is important because WIDE7-7 for example can generate
as many as 200 packets!  The New n-N Paradigm also introduces SSn-N
systems for state wide communications for special events (not routine).

In July 2004, much of the USER PATH information was split from this
file and placed in PATHS.TXT  and only the DIGIPEATER information
needed by DIGI sysops was retained in this file.  But SYSOPS must
be fully familiair with PATHS.TXT also.

BACKGROUND: This file originated in 1994 to describe the detail
objectives of the unique generic APRS approach to digipeating.
It is a MUST READ for anyone who seriously uses APRS including the
web page below.

http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
Or   google for "fix14439.html"

Digipeaters are the most important APRS asset, our lifeline if used 
properly, but a source of QRM and inconsistencies if not.  First, here
is what an APRSdigi using typical KPC-3+ firmware, or UIDIGI ROMS,
or DIGI_NED software is expected to do:

1) Digipeat with callsign substitution for the alias of RELAY.  This
   is for backwards compatibility.  In general using RELAY is now
   discourged because it can cause multiplication of dupes.  Prior to
   2005, the alias list included WIDE, TRACE and SS state abbreviation
   but these are no longer needed.

2) Under the New n-N Paradigm, the additional aliases are more
   useful as *traps* for large values of N.  By adding the UIDIGI aliases
   of WIDE4-4, WIDE5-5, WIDE6-6 the digi will effectively trap the
   large hop 4-4, 5-5 and 6-6 paths from any further propogation.
   They will be digipeated once, but then the digi's call will be
   substituded and they go nor farther.  The very large path of WIDE7-7
   will be trapped by peer pressure and user education.

2) UIFLOOD should be set to SS, 30 where SS is the state abbreviation
   or ARRL section (for big states).  This allows the use of SSn-N
   propogation in the state, but eliminates QRM from going beyond the
   borders.  Larger values of N for special events or nets is possible
   because there are only so many digis to hit.  Also the ID parameter
   should be enabled.

3) UITRACE should be set to support WIDEn-N so that all paths are
   traceable.  WIDEn-N (typically 2-2, 3-3 or 4-4) can now become the
   universal path, since abuse can be trapped in most cases.

4) DIGI's should identify themselves with a position packet once every
   10 minutes LOCALLY and DIRECT only.  Then every 30 minutes via one
   hop, and no more than once every hour or more for 2 hops.  A special
   technique using the LText, LTPath and BLT functions is used to
   implement this complex technique but with no dupes.

5) The POSITION packet should indicate the proper ICON and overlay
   character and in its comment field identify the type of functions
   supported.  The "L" is the new overlay character for the New n-N
   Paradigm digis with these Limits on N.  Also the old PacComm "T"
   Trace digis can now be improved to "P" digis which are compatible
   with the New n-N Paradigm too.

6) The unused BText may be used at a low rate LOCALLY and DIRECT to
   also put one special local object of local interest on the map
   periodically, such as the local voice repeater most used by
   travelers and APRS users.

DIGIPEATER LOCAL NETWORK SIZE:
As noted in PATHS.TXT, a local network cannot possibly support more than
about 60 to 100 or so users on the 144.39 channel because that is the
number of stations that can statistically generate a 100% busy channel!
Users and DIGI owners must understand that their RF APRS Network can
be no larger that this or else reliability drastically suffers.  In a
local area with no digipeaters and everyone operating direct, actually
300 stations might be able to share the channel.  But one digi and one
hop will drop this to about 150.  The typical 2 hops in the big
cities drops this to the 60 to 100 count we generall refer to. In big
cities, this might only be a 20 mile radius needing only one DIGI.
In other sparse areas, it might be 150 miles and need 9 digis to cover
the typical 50 or so users.  This range is called the ALOHA circle and
is easily determined anywhere.  Everyone should operate with a path only
sufficient to hit only their ALOHA area.  Anything beyond that is just
causing QRM to everyone else.

FEWER HOPS:  This table from PATHS.TXT is repeated here because it shows
the futility of long multi-hop paths.  It is just not worth it and is
not the design of APRS to go beyond its own local network of 60 or so
users.  If users want a bigger picture, they should go to the internet!

HOPS  PROBABILITY  #COPIES COMMENTS
----  -----------  ------- --------------------------------------------
 1        50%         1    Local ops & special events (The APRS mission)
 2        25%         5    Routine ops  (24/7 monitoring for experience)
 3        12%        13    extended ops (only occassionally)
 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


THE NEW n-N PARADIGM:
---------------------

In 2003, we realized that over the last 11 years, APRS had grown by
orders of magnitude above its self-replicating beginnings, and that the
original goals of omni-local flooding of all packets to all nearby
digipeaters was killing the network.  In busy areas, anything beyond
1 hop is usually going to hit more than 60 surruounding users!

To combat this, the new N-N PARADIGM was defined to give local SYSOPS
several tools they could use to regain control of the traffic in their
local area without significantly having  to modify user behavior:

1) Simply trap large values of WIDEn-N by placing WIDE7-7,WIDE6-6,
   WIDE5-5,WIDE4-4 in the UIDIGI or ALIAS list.

2) MOVE WIDEn-N support to the UITRACE parameter.  This allows all
   WIDEn-N traffic to be traced.  This eliminates the need for the
   old WIDE,WIDEn-N type of path to find out where the packet
   originated.  Any path that begins with WIDE (or RELAY) generates
   from 3 to 5 times the number of dupes of a WIDEn-N packet.

3) Now use UIFLOOD for supporting SSn-N for your state use.  In small
   states, it inherently limits QRM from crossing state borders.  Turn
   the ID parameter on so that at least we get to see the last digi
   used.


ALT-CHANNEL INPUTS:

Another very powerful local improvement in reliabilty can be achieved
by adding an additional local digipeater input channel such as 144.99
if available in your area.  It will only hear locals and not the other
98% of QRM on 144.39.  This is the only reliable way that lower power
devices can be heard.  Digis on 144.39 hear 98% of channel QRM from out
of area.      GOOGLE:  alt-channel.html


DEDICATED WIDE AREA APRS DIGIPEATER SET UP

The BEST digi was the Kantronics KPC-3 or 3+.  Others could not do any
of the n-N algorithms.  But these days there are many comparable
options.  DIGI_NED is simply software that runs on any old 286PC or clone
via any old TNC in KISS mode.  UIDIGI is a ROM system that can plug into
ANY old TAPR-2 compatible TNC (there are hundreds of thousands of these
out there gathering dust)...  Since I cannot address all of the various
settings in every type of TNC, here are the settings for the KPC-3:

   MYCall W3XYZ-x                       
   UIDIGI ON RELAY, WIDE4-4,WIDE5-5,WIDE6-6  <= these do callsign
                                                substitution.
   UIFLOOD SS,30,ID             <= Supports SSn-N for your state
   UITRACE WIDE,30              <= Supports WIDEn-N
   HID OFF
   LT 1 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456
   LT 2 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456
   LT 3 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456
   LT 4 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456
   LTP 1 APRS
   LTP 2 APRS 
   LTP 3 APRS VIA WIDE1-1
   LTP 4 APRS VIA WIDE3-3 
   BLT 1 E 00:30:00 START 00:00:00  at 00 and 30
   BLT 2 E 00:30:00 START 00:10:00  at 10 and 40
   BLT 3 E 01:00:00 START 00:20:00  at 20 
   BLT 4 E 02:00:00 START 00:50:00  at 50 every other hour

   The result is one local packet every 10 minutes and one area packet
   every 30 minutes which covers the two APRS standard net-cycle times.
   And once every 2 hours it lets the area know of its presence.

   Note that HID MUST BE OFF.  See HID.TXT.

POSIT TEXT:  The posit text above is standard APRS posit as follows:

   !                    means it is a fixed, non moving posit
   DDMM.mmN/DDDMM.mmW   is LAT/LONG in degrees and minutes
   PHGphgd              where p is power as the SQRT of P 
                              h is log2(HAAT/10)
                              G is gain in dBd
                              d is directivity in deg/45
   #                    means it is a digipeater
   /                    The separator between the LAT/LONG
                        should be:  1 for 1 hop enforced (no n-N support)
                                    R for RELAY-only digis
                                    W for WIDE-RELAYS  (obsolete)
                                    P for PacComm TNC's
                                    N for old WIDEn-n digis
                                    L for new Limited WIDEn-N digis
   /A=xxxxxx            is altitude in feet for 3D.  Put at end
                        of comment field to preserve first 20
                        chars that can be seen by Mobiles.  This
                        field is optional and not needed if you have
                        something else more important to say.

You can see by the integers in the POWER-HEIGHT-GAIN (PHG) string,
there are only 10 possible values for each of these fields as follows:

  DIGITS   0  1  2   3   4   5   6    7    8    9  as used in the PHG field
  -------------------------------------------------------------------------
  POWER    0, 1, 4,  9, 16, 25, 36,  49,  64,  81  watts  SQR(P)
  HEIGHT  10,20,40, 80,160,320,640,1280,2560,5120  feet   LOG2(H/10)
  GAIN     0, 1, 2,  3,  4,  5,  6,   7,   8,   9  dB
  DIR   OMNI,NE, E, SE,  S, SW,  W,  NW,   N,   .  This offsets the range
                                                   circle in the indicated
                                                   direction
           
HEIGHT ABOVE AVERAGE TERRAIN:  Although formulas exist, use common sense.
If your DIGI is only a hundred feet or so up, estimate the average terrain
going out 10 miles around the digi.  If it is above several hundred feet
assess average terrain going out 20 or more miles.  Subtract the altitude
of this surrounding terrain from the height of the antenna to get your
HAAT.   You may be at 2000 feet above sea level and have a 150 foot
tower, but if the ground around you is at 2200 feet, then your HAAT is
-50 feet!!!  Be honest!
Your PHG circle should go no further than the distance to which you can
reliably copy an HT.

Even though you have an OMNI antenna, if the terrain favors a certain
direction, then put that in for your directivity.  APRS will offset the
circle in that direction by about 6 dB

If your HAAT is in the thousands of feet, fudge the values to give
reliable PHG circle that matches actual coverage.  A 5000 elevation
never gives a HAAT of 5000 feet unless it is on an island.

SYSOP REMINDERS!

HID should be OFF.  It is just a wasted pacekt every 10 minutes.
We used to insist that UIFLOOD must be set to NOID and NOT to ID!
This was so that WIDEn-N packets could be traced by preceeding them
with WIDE,WIDEn-N to force callsign substitution on the first hop.
Problem was, this also generates multiple dupes.  Since WIDEn-N
will now be fully traced, this is not an issue and since UIFLOOD
is now for SSn-N routing, it will be best to have ID ON to at
least show how packets arrive.

Also be sure to see the entire new n-N paradigm and all the other
problems we need to fix on the global APRS network (144.39 in
North America).

  GOOGLE:   fix14439.html

RELIABILITY is the goal of APRS, NOT seeing how many stations you can
see.  If you are seeing more than about 60 stations on your RF channel
then your local reliability is suffering and weak signals or new
data cannot get through reliably.  Keeping paths short and using the
new LINKn-N, SSn-N and LANn-N limited networks can make your local
area less vulnerable to abuse by user mistakes.

See PATHS.TXT


ORIGINAL LEVEL FOUR NETWORK CONSIDERATIONS:

These concepts were proposed in the early days of APRS (1994) but
have never caught on...  THey are retained here for historical purposes.

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.

de WB4APR, Bob
