IDEAS.txt 6.2      OTHER SUGGESTED IDEAS FOR SOFTWARE WRITERS!


WIDE-N UNIVERSAL DIGIPEAT MODE!

    This may be the simplest mechanism for making an order of magnitude
improvement in APRS status and position reporting networks.  I am calling it
the WIDE-N mode, since it could be made into a TAPR-2 compatible ROM for
use in any TAPR-2 compatible TNC.  In a WIDE-N network, each WIDE digi
simply repeats ANY packet with the VIA address of WIDE-N; but ONLY ONCE. If it
keeps a copy of the last 30 seconds of packets, and compares each new packet
that it hears with the LAST one that it digipeated, then it could decide NOT
TO TRANSMIT it again!  This would completely eliminate the multiple round-
robin multiplication of packets generated when a mobile station uses the
generic path of WIDE,WIDE,WIDE.  As it is now, such a 3 tier path launched in
the middle of 3 WIDE digipeaters that all hear each other can generate as many
as  3x3x3 or 27 duplicates in the area.  If each WIDE-N only digipeated the
packet once, then there would only be 3 local copies generated, but the packet
would still propogate outward three levels in the usual manner!

    To make this work, there are two considerations.

BONCE-LIMIT:  Using the via path of WIDE-N, each DIGI that repeats the packet
decrements the WIDE-SSID by one.  This way, each packet carries along with it
information on how many times it has bounced through the network.  The user
specifies how far it goes, by the initial setting of the SSID!  If he sets it
to WIDE-15, then the packet could be digipeated as many as 15 times outward.
If he is doing a local test, or event, and wants to limit DX QRM, he simply
sets his path to WIDE-1, and it only gets digipeated ONCE.

AGE-LIMIT:  The WIDE-N digi has to keep a copy of all digipeated packets for
a brief period for comparison with new packets heard.  This is the key to the
WIDE-N algorithm.  Every digi that hears a mobile POSITION report will
digipeat it to ALL other DIGI's, BUT ONLY ONCE.  There needs to be a limit
on how long the DIGI keeps a copy of each packet.  If the time is too long,
then the list is big, and originating stations are prevented from repeating
their SAME packet.  If it is too short, then there is the chance that a
packet may propogate in a circle and get repeated again.  My guess is that
30 seconds is a good default value.  Howie Goldstein, N2WX has improved the
effeciency of this idea, by only saving and comparing the CHECKSUM of the
packets, instead of the whole packet.

    If ALL APRS WIDE area digipeaters changed over to the WIDE-N code, we
would HAVE THE ULTIMATE GENERIC MOBILE GPS NETWORK!  Mobiles traveling within
a 200 mile radius of home could simply set a path of UNPROTO APRS VIA WIDE-5
without fear of clogging the network!  This WIDE-N ROM would not have to do
anything else!  It would be a cake walk to make it fit in any TNC.

ALL TNC's and NODES!  This WIDE-N algorithm should be built into every TNC
with a user definable name. Lets call it MY FLOOD.  This FLOOD callsign
works like the WIDE-N described above, but it becomes a useful generic
FLOOding algorithm on all frequencies.  Any station with an emergency can
use this FLOOD path to ping out in all directions!  My suggestion is that
the default MY FLOOD should be FLOOD.  By making it changeable, then users
can tailor their networks to respond as needed.  APRS reserves the generic
FLOOD calls of RELAY and WIDE for position reporting.


LEVEL FOUR UI FRAME ROUTING!  (this idea IS OBE if the WIDE-N idea works)

    For people with the ability to write code for TAPR-2 clones, there is
a real nead for LEVEL-4 distribution of APRS UI frames through a network.
Rather than using dumb digipeaters with the generic RELAY and WIDE callsigns,
the level-4 network should only need the single NODE-NAME of the HOME
or DESTINATION node for APRS UI frames.  The network should know the routing
and paths to use to deliver the UI frame to that destination node.  There,
the UI frame is transmitted ONCE (or maybe twice some time later) as if it
had been originated locally.

Since APRS UI position reports are redundant, and rapidly become obsolete
as they are refreshed by a moving station, the level-4 NETWORK only has to
make a feeble attempt to route the packets to the desired destination HOME
node.  They need not clutter the Nodes buffers, and can be time-ed out
rather quickly.  For more thoughts on this subject, read the DIGIPTR.txt file.


PRE-EMPTIVE DIGIPEATING (this idea may be OBE if the "ALL"net idea works)

    Until we get level-four routing of UI frames, it shuld be possible to
modify TNC code for pre-emptive digipeating.  This means that a digipeater
will look for its callsign ANYWHERE in the digi-calls list in a packet header
and if it finds itself, it will go ahead and digipeat the packet and cancel
all of the earlier digipeat bits.  This way a mobile only has to provide
a list of DIGI calls in the fartherest sequence that he may travel, and his
packets will all arrive at the last one in the list, no matter where along
the string he is located!  See more in the DIGIPTR.txt file.


AUTODF NETWORK

    Now, if you make an "ALL"net ROM for TNC digipeaters, then there should
be plenty of room for adding the A/D routine to take the LIMITER current from
a DF receiver at the same site, and converting that to a signal strength
value.  Then transmitting that report in an APRS OMNI-SIGNAL-STRENGTH DF
report.  This way, each APRS ALL digipeater site, could also be used as
an OMNI-DF site for reporting DF signal strengths.  See the README\DF.txt
file for details!


CALLSIGN and POSITION DATABASE NETWORK SERVER

     Since APRS includes the single station QUERY format for requesting a
station to respond with his position report, there is no reason why any PC
interfaced with the HAMCALL CD ROM could not listen for such QUERYS, and
respond with a properly formatted APRS POSITION report for that station!
The APRS station sending the single UI frame QUERY gets rewarded by seeing
the location of the requested station SHOW UP ON HIS MAP!  The database PC
would of-course wait about 30 seconds to be sure the requested call is not
LOCAL and then respond with an APRS OBJECT position report, which would
include the station's name and address!

