[aprssig] IGate design theory

[Jim Alles]

Referencing several previous threads:
[aprssig] IGate Registering for ANSRVR (Messaging failures)
<http://www.tapr.org/pipermail/aprssig/2016-July/045866.html>

[aprssig] IGATE message routing bug?
<http://www.tapr.org/pipermail/aprssig/2016-November/046314.html>

[aprssig] local messaging
<http://www.tapr.org/pipermail/aprssig/2016-November/046360.html>

We have clearly determined that we absolutely need to have an IGate
author's design specification document, if we expect to realize any kind of
consistency using the APRS for messaging while traveling outside of our
local area.

(Regardless, it would be wise to have situational awareness rather than
assumptions, and test your assumptions. Good operating practice, as things
stand, is to get a reasonable position packet out, and test message against
a known sender (i.e. ANSRVR), and observe the response).

To start, I would like to play with some ideas.
First, we have to look at the only thing anyone (author or user) has had to
work with in many cases:

http://www.aprs-is.net/IGateDetails.aspx
specifically, <Gating Criteria>The following is the basic criteria for
what an IGate gates to/from RF.

Gate message packets and associated posits to RF if all of the following
are true:

   1. the receiving station has been heard within range within a
predefined time period (range defined as digi hops, *distance*, or
both).
</Gating Criteria>

We could provide more detail in the new document, include some examples &
reasoning, and make some suggestions for defaults, while recognizing the
various local conditions.

So, taking a shot at #1, I am going to introduce the first idea, while
tightening it up:

1.
The specific message destination station (CALL+SSID throughout this
exercise) has been heard as the source of any packet type on RF, in the
local area*, in a configurable time period, with a default of one hour
(long enough for a station to beacon every 30 minutes, while allowing for
at least one missed transmission). Messages may be transmitted to a
specific list of callsigns of local operators, regardless of being heard
locally, by the discretion of the operator, and depending on the
capabilities of the software used.

*The local area has been coordinated with each of the local IGate operators
and defined to consider:

   1. transmitter power, HAAT, and antenna gain (PHG circle)
   2. the ALOHA circles (packet channel saturation on RF)
   3. local terrain
   4. digipeater coverage

For the purposes of APRS messaging support, if an IGate hears a station
direct, or one hop, it is recommend that messages and courtesy 'sending
station position reports' may be transmitted without regard to distance. In
other words, do not wait for a position report from the destination station.

If an IGate hears a station as being two hops away, the distance may be
used to restrict the status of heard to 'not local' only IF a position
packet has been received. Until then, only messages (including ACKs) should
be exchanged. This distance must be configurable by the local IGate
operator. Once the distance on a two-hop destination has been determined,
the courtesy  'sending station position reports' may be transmitted, the
quantity sent being configurable to 0,1, or 2 by the IGate operator. (This
is not intended to be a track).

In some locales, two hops may inject single packets from hundreds of miles
away, with very little hope of reliably transmitting a message back to them.

It is generally regarded that three or more hops away is not local, but
regional. These stations heard should, by default, be considered NOT local,
until a valid position packet has been received, AND it is within the
locally defined distance. However, the recommendation (default) is to not
to transmit, without a specific configuration option, that contains
sufficient description of the consequences.

Have fun with that, and a good day!

73,
Jim A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161204/3f3fc209/attachment.html>