<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Why won't it work Bob? Let's consider your long chain of cities one
hop apart... a 1 dimsional model for simplicity's sake.<br>
<br>
NSR rules say that if a NSR digi hears a packet direct (or via a known
home station) it will swap the path for it's own callsign... so what
starts as<br>
kd4rdb-14>WIDE1-1,WIDE2-1:<my data here><br>
becomes<br>
kd4rdb-14>wb4apr*:<my data here><br>
<br>
Any other NSR digi that has been programmed to "know" the originating
digipeater as "local" will digipeat the packet one time and one time
only. I'd guess that the average digipeater would need to know only 4
or 5 others to consider local, but just to make sure, let's say that a
digi may need to have a list of digipeater 32 stations long.<br>
<br>
Now, let's say I'm in the Baltimore area. The digi's in Baltimore,
Philly and DC consider wb4apr to be local and will digipeat packets
that _originate_ from wb4apr. I'm seen in Philly, Baltimore and DC.<br>
<br>
Now, let's say I'm in the Philly area as I travel north. I'm heard by
a digi in downtown Philly... Now the digi's in Philly and Baltimore and
NYC consider packets originating from Philly to be local and I'm seen
in Philly, Baltimore and NYC. Meanwhile, the digi in DC heard the
packet when it was digi'ed by wb4apr (for the benefit of his local
users), but because it originated from a Philly area digi, it is not
considered local to DC and is not digipeated in DC.<br>
<br>
Now, lets say I'm in NYC area. I get digi'ed by some digi on long
island.... The digi in Philly recognizes the digi in long island as in
it's local area, and digipeats. The Bob in balimore decided that there
was too much traffic coming in from NYC, so he did not program the
wb4apr digi to recognize traffic originating from the NYC area. I'm
still seen in NYC and Philly... and if we keep extending the model -
Hartford CT.<br>
<br>
You see, it's not a rigid boundary lan. (I get the feeling you may
think it is). It can be.... but it can also be a smooth hand off from
one overlapping coverage area to the next. I used big cities in my
example for everyone's sake.. I expect this model to be downsized to
actually fit the aloha circle of a given area, realizing that the
boundaries may actually be towns with names like Mayberry MD, and
Whistlestop VA instead of Philly, DC and NYC.<br>
<br>
Wes<br>
<br>
Robert Bruninga wrote:
<blockquote cite="mids2b9d5e2.007@FSGWHUB.usna.edu" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:HamLists@ametx.com">HamLists@ametx.com</a> 06/22/05 7:42 PM >>>
</pre>
</blockquote>
<pre wrap="">That is, that it also means the only thing you will be able
to do with the channel is what your local SYSOP decides
you can do. My experience is that this approach usually
[fails in many areas]...
</pre>
</blockquote>
<pre wrap="">No such thing. It does say that you can't define your
path (or that if you do, it is ignored)...
</pre>
</blockquote>
<pre wrap=""><!---->
Let me re-iterate, Pete's system is an excellent
solution and it will work in many areas where there
are consistent expectations. Dallas is a good example..
a large APRS density surrounded by very low density
operations and even in those areas, the focus on
communications still pertains to Dallas. It should work
very well, and I doubt there is any problem setting
up a well defined system.
But this model completely falls apart on the East coast
where I am. We have probably 1000 users in one
long chain of cities (all one digi hop apart) from
DC, Baltimore, Philly, Trenton, NJ, NYC, Long Island
Connecticut, rhode Island, Massachussetts through
NH and VT to Maine.
Yes, people in Baltimore CITY could concevibly agree on
the boundaries of a Baltimore net, and so could most of
the denizens of Wash DC city only. But the problem is
that MOST hams live in the suburbs inbetween, and fully
HALF of those in the same area, claim the opposite city as
their sphere of interest. Ether because of where they work
or school, or play.
There is no such thing as ever being able to define
a boundary of where one particular digi will allow
its users packets to go. Because half the people
in each SAME neighborhood could care less about the
other city and its comms needs in many cases, and
it is this way for 500 miles and 1000 users between
13 different "sphere's of influence".
In this area, WIDE2-2 is the ideal path because
no matter where one is, he can comunicate
with everyone around him out 2 hops and even if he
is Far into Baltimore subburbs, but wants to maintain
his association with Washignton, he may do that
easily. He simply choses the route DIGI1,DIGI2,
etc to get his packets to his area of interest.
So we have to be careful when trying to compare
"network ideas". Some ideas work very well in some areas
and different ideas work every well in other areas.
So I appoligize where I implied that the SYSOP-knows-
all solution just wont work. It can clearly work well
where you can get ALL digis and ALL sysops to agree
on the settings for each digi and the route each digi
will allow or not.
What I meant was that it just wont work along the
congested eastern Seaboard which is my experience
base. I am sure it will work very well in isloated
areas where expectations are consistent and easy
to define.
I dont want this to a this-net-is-better-than
that-net. Just recognize that there are better
optimum solutions for diferernt areas. And lastly
that no matter what a local area decides to do,
it must respond consistently to all mobiles
everywhere. Or again, the consistency of
APRS as a service for mobiles is lost.
Bob
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>