[OZAPRS] Spread the word.... As suggested by Bob, WB4APR

Mike Townsend tasit at unwired.com.au
Thu Oct 26 22:10:34 EST 2006


For those who have not read the following it is written with Europe as the
focus but I see no reason why it should not apply here in Australia.The
New-EU WIDEn-N Paradigm                              19 March 2006
----------------------------------------------------------------------
                                                                WB4APR
Updated 3 July 2006
Updated 21 Sept 2006 

The APRS network in Europe in many areas is unreliable due to the same
lack of consistent user settings and network digipeater settings that 
had evolved in the USA forcing us to finally implement the New-N
Paradigm and get consistency and traceability throughtout the network.
See the map on www.ew.usna.edu/~bruninga/aprs/NewEU-map.GIF 

The following history is important to understand:

RELAY was simple digipeating but NO dupe checking
WIDE was simple digipeating but NO dupe checking*
TRACE was simple digipeating but with call substitution & no dupe ck*
WIDEn-N was N flooding with DUPE-CHECKING, but no traceability
TRACEn-N was N TRACEing with DUPE-CHECKING and with TRACEABLITY.

The BEST APRS networks need n-N Hopping, Dupe Checking and TRACEing.

That is why in the USA we eliminated all dupes by getting rid of
RELAY, and WIDE and TRACE.  And since we wanted n-N hopping AND
Dupe-checking AND TRACEing, there were two choices:

1) Ask ALL users to stop using WIDEn-N and start using TRACEn-N.
       ---- OR -----
2) SImply swap the names WIDEn-N and TRACEn-N at the digis and
let users keep operating as before with the simple path of WIDEn-N.

Since we had to change the parameters at ALL the digis to get rid
of RELAY, WIDE and TRACE anyway, it was just as easy to implement
number 2 above.  Once we put WIDEn-N into the fully-traceable 
UITRACE function, then there was no need for the "TRACEn-N"
any longer.  So this then left UIFLOOD unused.  So we put the STATE
or LOCAL or REGIONAL alias of SSn-N in its place so that the 
"untraceable" UIFLOOD parameter would still be useful without
adding QRM out of the area.

Europe and other non-NorthAmerican countries need to look at the 
significant improvement that was made in the USA under the New-N 
Paradigm starting in 2004.  

*Admittedly, most European digipeaters evolved after the USA, and
so many of them do support callsign substitution on even the older
RELAY and WIDE, and some even do dupe-checking on WIDE and TRACE,
so Europe does not have the bad DUPING problem as bad as the USA,
but still, there is NO REASON ANY MORE for all these different
options.  Lets SIMPLIFY APRS!  Everything is obsolete except:

n-N Hopping, Dupe Checking, and Traceability.

Europe needs to decide if it is easier to convince all the users
to change their PATHS to TRACEn-N or simply change the DIGIS so 
that WIDEn-N becomes Traceable.  

As a starting point, here are the results of 24 hours of 94,000 
packets monitored in Europe on 17 March 2006 (does not include data 
from the UK).  These percentages are the percentages of those using
paths of WIDEn-N or TRACEn-N.  It turns out, this is only about 
half of all paths!  The rest are using the obsolete paths of 
and WIDE and TRACE which should clearly be phased out to simplify
guidance to users and make user education easier.

WIDE7-7    18%    TRACE7-7  9%
WIDE6-6     2%    TRACE6-6  3%
WIDE5-5    10%    TRACE5-5  4%
WIDE4-4     5%    TRACE4-4  1%
WIDE3-3    36%    TRACE3-3  5%
WIDE2-2    12%    TRACE2-2  1%
WIDE1-1     2%    TRACE1-1  0%

Using combinations of both WIDEn-N and TRACEn-N!  5%

The numbers for the UK are similar but they show a 4:1 preference 
for using the TRACEn-N system so that they have packet traceability.

The GOOD news:  Clearly WIDEn-N is favored *and* about half  of the 
users are being considerate and keeping their QRM down with 3-3 and 
2-2 packets.  Also simplifying the network to only use WIDEn-N
can be done with no impact to existing users.  And simply swapping
the WIDEn-N support over to the UITRACE parameter will allow all
WIDEn-N paths to be traceable just like we did in the USA.

The BAD news:  The biggest LOAD, however, is caused by the huge 
numbers of 7-7 and 5-5 packets and packets with BOTH WIDEn-N and 
TRACEn-N in the same packet!  Remember, for each additional hop, 
the number of QRM copies can triple!  And for only a few 7-7 
users, they can cause QRM over much of the continent.

WIDEn-N works now and will always work.  It is just that it will 
become more traceable as more  and more digis implement the New-EU
Paradigm.

Here then is my final suggestion for the New-EU Paradigm:

1) The best path for fixed stations is WIDEn-N
2) The best path for Mobiles is WIDE1-1,WIDEn-N
3) Educate users to use routine N no larger than their ALOHA area
4) Change the digis (swap TRACEn-N and WIDEn-N) so Wn-N is traceable.

IGATE RULES:  IGates should set their path to their local area only 
(usually one hop, WIDE1-1) and should not flood their area with 
unwanted QRM. 

New-EU Paradigm DIGIPEATER RULES:
1) In saturated areas, TRAP large values of N-N by setting call-
   substitution aliases of WIDE7-7, 6-6, etc.   These will digi 
   once and then stop further routing.

2) Home stations should *not* be digipeaters UNLESS:
    a) Station is high and is -not- covered by a BIG digi.
       THey should  Support WIDEn-N, and regional SSn-N.
    b) -or- Station is needed for a fill-in digi for nearby
        mobiles who cannot be heard by the big digi.
        Support ***only*** the WIDE1-1 alias.

3) For NETWORK reliability, All digipeaters  should:
     a) Put their PHG in their position comment
     b) Put "Wn,SSn" also to show the largest N they support
     c) The SSn shows what regional or sectional SSn-N they support
     d) Use the DIGI syumbol with "E" overlay.
     d) -or- use the "1" overlay for WIDE1-1 ONLY home digis.

4) Move WIDEN-N support to the UITRACE parameter so
    that all WIDEn-N traffic is traceable.

5) Support for WIDE, TRACE or TRACEn-N  is not needed
    anymore.  Replace UIFLOOD parameter if needed with
    SSn-N for your local state or regional traffic to contain
    its impact to only that net's area of interest.

6) With time, WIDEn-N will become fully traceable as DIGI
    owners move WIDEn-N support over to the UITRACE parameter.

7) Set station beacon rates to 1 every 30 minutes if using
    a path of N=3 or greater.  Set to every 20 minutes or more
    if using N=2.  Set to 10 minutes if using N=1 or 0.

TRACKERS:  All future mobile GPS tracker designs should consider
the Proportinal-Pathing algorithm that sends 1 minute updates
local-direct, every 2nd minute via one hop, every 4th minute
via 2 hops and optionally every 8th minute via 3 hops.  See
http://www.ew.usna.edu/~bruninga/aprs/ProportionalPathing.txt

TIPS:
- Use the UI-PHG add-on to see the range and coverage of
  all digipeaters and stations in your area

- Use UI-ALOHA add-on to see the ALOHA range for your UIVIEW
   station.  It analyses traffic heard by your station to compute
   that area that is a 100% saturated 1200 baud APRS channel.  
   Keep your N hops within that area.

About the only difference in the New-N paradigm in the USA
and the New-EU paradigm is that the dupe problem was not as bad
in Europe, but by eliminating everything except WIDEn-N it greatly
simplifies paths for new users and for network analysis.

By simplifying the network to only WIDEn-N and WIDE1-1,WIDEn-N
guidance and telling users to limit their N's to the minimum
needed in their area, then a vast impovement in reliability
and throughput can be achieved in the European System.

For more in-depth understanding, please review the details
in the web page:

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

Good luck!
Spread the word.

de Wb4APR, BobAll I want is a simple and reliable as can possibly be
network.Mike, VK2INT 
_______________________________________________
Ozaprs mailing list
Ozaprs at aprs.net.au
http://aprs.net.au/mailman/listinfo/ozaprs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://second.aprs.net.au/pipermail/ozaprs/attachments/20061026/d0419d7c/attachment.htm 


More information about the Ozaprs mailing list