Hot Shareware 32/hot34.iso/ficheros/VUBBS/800TO814.ZIP/README/APRSNET.TXT

Text File | 1998-03-27 | 16KB | 302 lines

APRSnet.txt  ver .010
Bob Bruninga, WB4APR

     APRSnet is based on the pioneering work of Steve Dimse, K4HG, who
wrote APRServ as a system for linking together APRS internet IGATES
so that APRS traffic nationwide could be distributed among such sites
via the very high bandwidth of the internet.  APRSnet means two things:

   1) APRSnet.exe is APRSdos streamlined for use on the internet

   2) APRSnet is a whole new concept for nationwide connectivity.

This new APRSnet concept is an extension of Steve's original plan, to
not only provide nationwide connectivity between APRS internet users,
but to also provide on-the-air nationwide connectivity to mobiles and
other stations without direct internet access.  This also provdes the
mechanism for extending the APRSnet into disaster areas or areas that
have lost internet connectivity!  APRSnet is completely compatible with
the existing nationwide APRS tracking network on two meters and just
provides for the long haul of data nation/worldwide.  The system
exchanges all of the standard APRS type packets, Position, Status,
Objects, and Message\Bulletins.  See Steve's paper in the DCC
proceedings or on http://aprs.miamisci.org/usa.html.

     Simply said, any APRS station that connects to one of Steve's
APRServe sites has access to all packets nationwide for tracking,
weather monitoring, and messaging.  The network is distributive in
that each such station not only receives packets from the internet,
but also FEEDS any packets he hears into the same network for everyone
else.  This way the network is very flexible and not dependent on a fixed
system of sites.   APRSnet.EXE is a version of APRSdos that was
modified for the greater tracking capacity (up to 500) and some hot-keys
were added to facilitate opening a telnet connection to the APRServe
site.  Mac/WinAPRS and APRSa4 have TcpIp drivers built in.

     When I wrote APRSnet in Nov 97 there were only a few permanent nodes,
and dozens of temporary dial in nodes all over the country.  Most of
this had been going on for about a year using MacAPRS which had always
had TcpIp built in.  Once WinAPRS added TcpIp, then everyone logged on
now can feed every packet heard on VHF/HF/Satellite to each other.

APRSNET CONCEPT FOR 2 METER LANS:   The APRSnet concept extends this
worldwide internet connectivity to local users on dedicated local
APRSnet channels.  Whereas Steve's APRServe software serves all of the
internet sites, APRSnet PC's take this data and STREAM it on a local
APRSnet channel for local listeners.

DEFINITIONS:

NATIONWIDE APRS CHANNEL:  This is the single nationwide tracking
channel currently endorese by the ARRL and AMSAT as 144.39 where
available.  All mobiles report their positions and status on this
nationwide APRS frequency in their local area.  As more and more
APRSnet sites come on line, mobiles and fixed stations need
only a minimum path length to cover their local area and make sure
their packets at least get to a nearby APRSnet site.

APRSnet Channel:  This is an optional local channel fed by an APRSnet
PC that is logged onto APRServe.  This APRSnet channel is preferably
different in each area, needing a clear channel coordination.  It
transmits a near continuous stream of packets of everything heard via
the internet on this channel.  This is similar to the PACSAT protocol
that assumes that everyone is listening and will collect what he needs
just by monitoring the channel.  This continuous distribution of packets
is called streaming.  Any user desiring to see the national APRS picture,
tunes into this channel.

IGATE:  This is Steve's generic term for any Internet Gateway station.
It can serve as a local user terminal logged onto APRServe, and as
gateway for feeding locally monitored VHF packets into APRServe and
lastly as gateway for internet traffic back over the air to local
VHF linked users.

APRServe:  This is the software written by K4HG to do the internet
packet serving to everyone connected to his site.

APRSnet.EXE:  My simple DOS program to do the IGATE functions.  It has
several capabilities. as follows:

    INTERNET PORT:  Use this comm port to telnet to www.aprs.net

    TNC PORT:       Your TNC can either stay on 144.39 or be a server

    FEEDING:        In this mode, everything heard by your TNC is feed
                    into APRServe via the telnet connection.

    STREAMING:      This streams all of your stations heard on the P
                    and L -lists to your community on your APRSnet channel

    USER:           This is standard APRS mode with only the TNC port
                    active.  You use APRSnet.exe since it has more rooom
                    for the hundreds of stations than normal APRSdos.

CAUTION!!!          You must not activate STREAMING if your TNC is
                    listening on the same channel it is serving.
                    Otherwise you will form an infinite loop of packets!

TALKBACK CHANNEL:  To allow for increased capacity IN THE FUTURE and
to avoid cluttering the National APRS channel with keyboard messages
between FIXED stations, each APRSnet node can add a "talkback" channel
where it listens for incomming traffic.  In many instances, it may be
advantageous to use +/- 600 KHz offsets so that normal offset
transceivers can be used.  These talkback channels are again, only
a local coordination issue.  For now, user talkback is simply transmitted
on 144.39 and the IGATE picks it up there...

ZIP-LAN:  This is not related to the internet, but the protocols added
to APRS to handle the IGATES and APRSnet concepts also permits multiple
PC's to be interconnected with nothing but 2 conductor zip cord.  This
is advantageous in the field where many APRS consoles may be connected
to a single TNC and radio in an emergency operations center.  See ZIP-
LAN.txt

MESSAGING:  Since APRSmessages are by nature, point-to-point, they
are already permitted to go both ways through a validated IGATE.  This
means that a user on the internet may send a message via an IGATE to
a nearby station within VHF range of that station.  The local IGATE will
transmit it and will FEED the ack back via APRServe to the originator.
To fit within the FCC rules, only licensed HAMS are permitted to use
this capability.  A validation protocol exists between the various
versions of APRS and the APRServer to authenticate licensed users.

APRSNET DIFFERENCES AND COMMANDS:

To facilitate the specific application of APRSnet.exe, many features were
eliminated from APRSdos, such as DX, Mscatter, DF, and SPACE modes.  The
D page is truncated to 40 bytes and several new commands have been added:

F1-TELNET        - Help pages about APRSnet

OPS-COM-INTERNET - Use this dumb terminal mode to access your TELNET

alt-S-NET-FEED   - Activates feeding packets from your TNC port to TELNET
         -SERVE  - Activates serving status/posits out your TNC port
         -TRANS  - Sets the transmit cycle time on your server channel
         -IGNORE - Toggles IGNORE filter on/off.  When ON, only posits
                   on the current screen will be saved.  This is so you
                   can zoom into an area, and your PLIST will only fill
                   with local packets to that area.
         -DIAL   - Save a DIAL string for your modem access.*  Invoke it
                   on the OPS-COM-INET screen with alt-D
         -LOGGON - Save your LOGGON string.*  Invoke it on the OPS-COM-
                   INET screen with alt-L.
         -CONNCT - Save your CONNECT string (open www.aprs.net:10151).*
                   Invoket it on the OPS-COM-INET screen with alt-C.

                   * Note, these strings are viewable with OPS-DIGI-LIST

CONTROLS-XMT     - Toggles ON/OFF your TNC transmit

JUST-TELNET      - Displays a list of other TELNET stations that are
                   in your P-list.

CAPACITY CONSIDERATIONS:  Even with 1200 stations showing on APRServe,
the overall througput is still only abou 700 baud.  This means for a
while anyway, that you can STREAM this data locally on a 1200 Baud
channel.  As loading increases (now 2 weeks after introducing APRSnet
its up to 1200 from 600 a month ago), we need algorithms to kick in, to
filter redundant transmissions such as from FIXED station positions to
allow mobile position reports to be reported more often.

Beyond that level, 9600 baud or additional streaming channels will
be necessary.  In fact, other usefull APRS data can be distributed
in the same stream, such as EMWIN WX data, and DGPS signals.

Just like with the cellular phone industry, there is no limit to the
capacity of the system.  As more and more users come on board, the
APRSnet "cells" just get smaller and more focused.  One channel may
become the weather channel.  Another may be the EAST coast channel,
another may be the WEST coast channel or another may become the special
event channel....  The user just tunes in the streaming channel of
his current interest.  As more and more users join the internet,
less on-air bandwidth is required.

With the drastic demise of packet BBS systems, there should be plenty
of VHF bandwidth available for these applications.  It is important to
note that these APRSnet channels are in fixed areas and are not even
preferred to be shared.  Therefore coordination is a local issue and
even other bands than 2 meters are quite usable.  Travelers or visitiors
would be alerted to the local APRSnet channels by clicking on any IGATE
symbols he sees on his APRS map.


USER SOFTWARE:  There is no distinction at the user end in APRSnet
traffic or conventional traffic other than once comes from a TNC and
the other comes from the internet.  Home stations simply monitor the
APRSnet channel if they want to watch nationwide activity.  They still
transmit their traffic on the normal APRS national channel, or later,
on an alternate APRSnet talkback channel.  Mobiles will also operate
as normal on the national channel, and will be able to see all local
activity.  Stations with internet access will join the network that
way, thus freeing up valuable RF spectrum for the mobiles and users
without internet access.

NOTE:  The APRSnet channel uses a  slightly different protocol to
handle the fact that the FROM CALL on the APRSnet will always be the
call of the LOCAL IGATE TNC, so newer versions of all user software,
Mac/Win/DOS will be needed to monitor the APRSnet channel.
This capability is in APRS8.0. and all later versions.


OPERATIONS:  When you start APRSnet.EXE you will see several pages of
description.  You may return to these later with the F1-TELNET command.
Next you log on to APRS and give the COM port (1 or 2) of your TELNET
connection and TNC.

Next you alt-S-SAVE your config file so you wont have to do all that
again.  Finally, you go to OPS-COM-INTERNET screen which is nothing more
than a DUMB TERMINAL SCREEN and do what ever you have to do to open a
TELNET session to www.aprs.net.  If you use a dial up line, you will
need to tell your modem to dial the phone.  This is simply the command:

ATDT #########  (AuTo Dial, Tone )

(Save this string and others using the alt-S-NET-DIAL, etc commands.)
Once you are logged in, you will need to open a TELNET connection.  Of the
three systems where I work, there are three different formats!  THey are

   OPEN www.aprs.net
   C www.aprs.net @23
   www.aprs.net 23

Here the 23 is the port number on APRServe for live data.  If you open
to port 10151, you will get a fast dump of the mroe than 1000 stations
heard in the last 24 hours before the live feed kicks in.  APRSdos
cannot really handle this high speed dump.  So it is best to only go to
the default 23 port.

Once you are logged on, still on the dumb terminal screen, you will hit
the usual ESC to escape back into APRSnet.  If you connected to port
10151, you will have to hit the ESC within a fraction of a second
to avoid completely overrunning the dumb terminal screen.  There is a
packet counter displayed during the initial dump.  I am seeing 1200 to
2600 packets in the 12 hour buffer.  APRSnet only keeps the last 500
for now..

Once you are back into APRSnet you should be able to do everything you
normally do.  THere is ONE new command, JUST-TELNET on the DIGIpath page
which will display a list of only the other APRServe and APRSnet users.
If you do an OPS-QUERY 4096 miles, then all other APRServe stations
should respond within a few minutes.

If you plan on operating an APRSnet site, you should begin frequency
planning now.  Your site is probably not a good VHF site, so you will
need to transmit your APRSnet stream on one channel and then maybe
have digipeater sites to the north, south, east and west of town.
There are several possibilities:

SPEED DIALING:  Once you figure out your modem dial string and your
required LOGGON and CONNECT string, you may use the alt-S-NET-DIAL,
LOGGON and CONNECT commands to save these strings (alt-S-SAVE).  Then
when you are on the OPS-COM-INTERNET screen, you can just do alt-D to
dial, alt-L to loggon, and alt-C to connect...

INITIAL TRIALS FOR SERVING AN APRSNET CHANNEL:  You can transmit at a
50% duty cycle on channel A and then have the outlying DIGIS all
digipeat those packets back onto channel A.  Crude, and people that can
hear 2 digis will have problems and if APRSnet catches on, your 50% duty
cycle may not handle the load.

DUAL FREQUENCY:  Same as above, but have each of the other digis
listen on A but transmit on their own channels.  Still 50%, but
everyone gets a clear channel.  Also harder to find 4 channels.
OR, if you can get enough frequency separation, all of these digis
and your site can operate 100%, just tell the digis to operate full
duplex.

DUAL BAND:  THis is probably the best.  Transmit on BAND A and then
have the outlying digis transmit on band B (multiple freqs)

9600 BAUD:  Do all this at 9600 baud!  Remember, 5 watt 9600 baud data
radios are less than $150...


FREQUENCY PLANNING:  The need for a single nationwide APRS mobile
channel is as important as ever.  But, in addition, the APRSnet system
will need a minimum of one other local APRSnet channel for the internet
streaming channel.  Notice that this channel does NOT need anything
other than local coordination, since it is for a fixed site application
for fixed users.  As activity grows, an additional talkback channel
may be required.  Careful planning early on could arrange for the
talkback channel to be +/- 600 KHz from the streaming channel so that
normal T/R offsets can be used.  For example, if 145.63 is the APRSnet
channel in an area, then 145.03 could possibly be used as the low
duty cycle "talkback" channel to APRSnet.  Probably the 440 band is
ideal for this kind of expansion...

TRANSITION:  Unfortunately the APRSnet concept required a new on-air
protocol.  THis means that only new software (after APRSdos 796, Mac
2.0.7 and WinAPRS x.x.x is required to see these new packets.  This
APRSnet.EXE should work fine too...

In a pinch, you can use plain ole APRSdos to logont APRServe.  Just go
to the dumb terminal screen and logon to yoru TELNET account and then
ESC back into APRS.  It will capture and plot like APRSnet.exe, but
will be limited to only the last 150 stations heard.  But still, you
can zoom into an area and still see EVERYONE pop up on your map, although
only the last 150 seen will be on your P-LIST.

de WB4APR