[aprssig] New WIDEn-N Paradigm (MAJOR MOD)

[Robert Bruninga]

Wes, 
What you are missing is that we want ALL digipeaters to
capture and stop at least WIDE5-5, 6-6, 7-7, and then 
there is no where that the packets can get into the system, 
therefore you wont get any 7-3's into your area either.  
Its a big plan.  But each digi that switches over, helps out 
ALL digis around it...  And eventually the network is better.

Bob

>>> Wes Johnston <aprs at kd4rdb.com> 2/6/05 8:28:10 AM >>>
Bob...

I know your recommendations are always grounded in pracitcality.  But
until the
TNC manu's come out with firmware that lets us limit UIFLOOD or UITRACE
hop
count (ie only digipeat UIFLOOD < 2-2), this solution is hokey at
best.

The 3rd recommendation below defies belief... (the others too, but I'm
going to
pick on number 3)

1- RELAY, WIDE5-5, WIDE6-6, WIDE7-7 in wilderness areas
2- RELAY, WIDE4-4, WIDE5-5, WIDE6-6 in rural areas more than 3 hops
from Metro
Areas
3- RELAY, WIDE3-3, WIDE4-4, WIDE5-5 in populated areas where even 3-3
is too
much
4- RELAY, WIDE2-2, WIDE2-1, WIDE3-3 with UIFLOOD and UITRACE OFF in
Very High
Density local area

I understand that UIDIGI settings take precedence over UIFLOOD
settings.  So you
can put a callsign in there with the SSID such as WIDE5-5... and when a
WIDE5-5
is heard he'd be digipeated using the UIDIGI setting and get one hop
and no
more.  But this still does nothing to stop the WIDE5-4 that my
neighbor's digi
just repeated.  Or the WIDE7-3 that my neighbor just digipeated that
originated
350 miles away.  I still end up with my local lan flooded with the lids
from
>200 miles away!  In order for this plan to work, every digi has to
catch the
WIDE7-7 or WIDE5-5 on the first hop.  And if the first digi to hear
WIDE7-7
doesn't "gobble it up" with a digipeat under the UIDIGI rules (ie
doesn't
decrement N and does set the HID flag), then that packet becomes
WIDE7-6 which
I can't filter out.  There are too many permutations - we're limited to
FOUR in
the UIDIGI setting.

The whole point for me to switching away from WIDEn-n was to segment
the network
becuase we _didn't_ have a way to filter packets based on the value of
"n".  I
realize that the SSn-n is still recommended, but I just can't see
supporting
WIDEn-n anymore.  My network is working better than ever since the
switch to
SCn-n here.

If we start digipeating WIDEn-n here, even with the suggested settings,
we'll
end up seeing as much traffic as we used to as the WIDE7-7's and
WIDE5-5's come
rolling in at various stages of 7-6,7-5,7-4,7-3,7-2 or 5-4,5-3,5-2,5-1.
 I never
saw any WIDE7-7's locally.  I never saw any WIDE5-5's locally... they
were all
WIDE7-1 or 7-3... how would I stop them?  Ideally, the digipeaters in
VA would
catch these packets under the UIDIGI setting, but practically speaking,
they
will not have setup their digipeaters to catch them, and will allow
these
network cluttering packets to propagate outward as WIDEn-n's.

FWIW, the local digi for me is KC4PL and he runs javaaprs which
supports count
limits. It counts all hops in a packet (ie RELAY,WIDE counts as 2
hops,
RELAY,WIDE5-5 counts as 6 hops) and will not digipeat any packet with
>x
hops(here, x is set for 3 hops).  They don't even get one hop.... They
do get
IGATED, but do not propagate on RF.  So a trucker passing thru running
WIDE7-7
gets to the internet as he obviously is trying to do, but does not
damage our
RF network.

I do really like the idea of giving the WIDE7-7's one hop... so they
emirge from
the digi as WIDE7-7*.  This is so much better than budlisting the guy
because
when he isn't digipeated, he'll get angry and up his RF power and get
very
creative with his paths.

Wes
--



Quoting Robert Bruninga <bruninga at usna.edu>:

> After a lot of debate over the last 2 months we have again
> modified the plan for the New n-N Paradigm to an even better
> and simpler design.  See the web page:
>
> http://web.usna.navy.mil/~bruninga/aprs/fix14439.html 
>
> Summary:
>
> WIDEn-N    works everywhere,  but large N's are traped
>                    depending on the area.
> WIDE2-2     is guaranteed to work everywhere
> SSn-N         is also supported for area use
> ##LNKn-N  interstate idea is abandoned
>
> Secondary effects:
>
> TRACE and TRACEn-N are not supported
> WIDEn-N replaces it and is Traceable everywhere
> RELAY,WIDE and WIDE,WIDE are no longer desired
> WIDE may eventually be dropped if this all works.
>
> All digis will include a list of what they support
> in a consistent manner in the Position Text that
> will show up well on mobiles.
>
> This plan even works in the highest density system
> in the USA in the Los Angeles Basin and a test of it
> was initiated there last week.
>
> I have not completely re-editied all of my old WEB
> pages to reflect all thse changes, so if you find
> conflicts, then point me to them so I can fix them.  But
> in general, the above plan is what is currently on the
> table.
>
> Thanks
> Bob, Wb4APR
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>