[aprssig] NetNodes, the future

[Robert Bruninga]

>>> HamLists at ametx.com 12/29/04 10:23:42 AM >>>
>So you now want to discourage APRS use?  
>Bob, time to come back to earth.

YES, Absolutely, I want to discourage the use of the 1200
baud APRS universal one-to-many local network that works 
WELL, from what you call "thousands of appliance operators"
who want to transfer mega-bytes of information and simply
don't understand the limitations of the RF end-user channel.

APRS should be used for APRS.   APRS should simply provide
the "local pointer" to the FREQ of the local NETgate
node to provide everything else the HAM user could possibly
want on RF via his Laptop and radio with no other need
for hardware or specialized software.

>APRS usage world-wide over the past year =  ZERO growth! 
>The more difficult you make APRS to use by imposing
>artificial barriers....

There is nothing at all "artificaial" about the limits of a 1200
baud channel shared by 40,000 people...  What is limiting
its growth is that it is unusable in many areas because of
the WIDEn-N abuse.  In a busy area, try to MSG QSO on
APRS using the currently popular software and it is practically
useless for real time communications.

>the more likely that there will be a significant decline in usage 
>over the next few years. 

Yes, if people keep trying to cram more and more into it.  That
is why we must use APRS as the local (yet global) connectivity as 
a "know-all" calling or signalling channel for which it was designed, 
but serve  ALL point-to-point bulk transfers of data and all the
new neat things we can do off to another channel...

>But, there are ways to handle this without turning away the 
>thousands of appliance operators who want nothing more 
>than a simple tracking system with some messaging.

We have that already.  And if we can just get eveyrone to
endorse the new n-N paradigm so that the network itself is
protected (by design, and not by user education) from 
abusive paths then it will work as well as it used to.  

>Your ways are neither simple nor conducive to bring in new 
>operators.

Again,we disagree completely.  The new n-N paradigm would solve
the overload,  and , what is "complicated" about:

1) Using APRS as-is for what it was intended with a universal
path in busy areas of SS2-2

2) If you want to send a big email or message or file, then
    Look on your APRS screen and see the location, Freq
    callsign and status of the LOCAL-to-you NETgate.

3) Turn your radio to that channel, connect to the NETgate
    and then "connect" to anyone on the planet to do any
    application you want.

>If you want to know why WinLink has become popular...
>all you need to do is look at what a user has to do use it
> (use any standard email software which the user already 
>has).  Bob, that is KISS.  

Yes, and WINlink is *exactly* what we need!  I agree completely.
It is the perfect adjunct for bulk traffic that APRS is not.
I'm just going one step further and saying why limit such a
simple basic connection to only Email and files?  When with
the same simplicity it could be a transparent connection for
anything using NETgates.

Why not let it be a completely transparent end-to end using 
the simplest AX.25 connection on which all of packet is based?  
That is what NetROM and TheNET were.  Their only 
shortcoming was trying to do multi-multi-hop long
paths on RF at 1200 baud.  Doing the backbone on the
internet solves all of that completely...

>RELAY,WIDE is KISS.
>I352-2,I302-2, etc. is not KISS.  

Thats because that example appears to completely miss-
understand  the LINKn-N system.  That system is NOT 
FOR LINKING APRS.  It's a fact of life that a 1200 baud 
layer-2 digipeating system, simply cannot do multi-hops for 
ack based message traffic on a channel shared by hundreds.


The LINKn-N systems are NOT for links.  THey are for the
long haul traveler on a known well established National
corridor to be seen by other similar long-haul travelers through
the wilderness via their one-way APRS type packets.

Thus, there would never be any 3 digit short-range-local
interstates in the LINKn-N system such as your I-352 and 
I-302 examples.

Further, all other APRS should use the universal SS2-2
path to get just about anywhere in his area.  That's all
APRS at 1200 baud can ever be.  A LOCAL system for
tactical real-time delivery of everything of immediate local
interest to the APRS mobile user and/or his local 
connection to the global APRS system.

>Making connections via AE5PL-10 from a mobile is not
>KISS.  Multiple frequencies for APRS operations is not KISS.

Those statememts dont seem to udnerstand the concept
of APRS and its limitations.  APRS is a *single-channel*
system.  To work correctly, it must provide universal connectivity
for everyone everywhere on that single channel. But
conversly, this also means that all other DATA-TRANSFER
applications that are not "APRS" should not be there and
SHOULD be somewhere else (with an APRS pointer to
where it is...).

And further. if you want to establish a connection to a distant
station for point-to-point transfer, I'm sorry to say, will require
you to establish a "connection" to that distant point.  I dont
think that "C XXXXX" is that hard for most people to understand
where XXXXX is the name of the applicaiton they want to 
connect to..(anywhere on the planet)...

>Flame away.  I have better things to do than pursue this thread
further
>(like making an APRS midlet for cell phones and supporting APRS-IS).

I think such talents would be more beneficial to APRS by not trying
to jam more stuff on APRS which seems to make it more of an internet 
video game for (as you call) "appliance operators" but would instead 
turn those talents towards adding services for the mobile 
or portable operator with communications needs... using his existing
radio and laptop...

We have at least a DOZEN win-link systems in our local metro
area (though none of them appear as objects on APRS).  This
shows how simple it is to connect a radio and a PC to the system.
I'm simply suggesting we can do the same thing, yet offer a 
lot more than store-and-forward Email!
 
Bob