[aprssig] Paths - Solution proposal

[Robert Bruninga]

I'm sorry to have to offer this rebuttal.  The problem with this scheme is
that it assumes every packet is of equal value, and its goal is to maintain
a constant level of loading on the network independent of any "value" to
the users or the situation.  This is an anathma of human communication and
can be considered almost as a classic definition of maintaining noise level
rather than information throughput...

Only the sender of a packet knows its immediate value, and only the sender
knows where he wants it to go.  The digipeaters are stupid, or a better way
to say it is that they should do what they are told by the sender.

Bob, WB4APR

On Sun, Jul 13, 2014 at 7:53 AM, Mark Cheavens <mcheavens at usa.net> wrote:

> With the most common thread on the APRS sig over the last few months being
> paths I thought it time to remind everyone of why we have the current
> problem and what we should work together to first come up with a needs list
> and to secondly work to solve the issue.
>
> While I have brought this up on the list many years ago, there are many
> new users and it might be time for a reminder.
>
> The current system (Digi backbone) was built with the currently available
> (and surplus) old TNC's. Many at the time were TNC-2's or clones, as well
> as the then "modern" KPC-3 and 3+'s.
>
> The KPC-3+ have suffered from the delayed packet problem, and the TNC-2's
> have been implemented in many cases without UiDigi firmware.
>
> As a result we have been fighting for years to try and educate end users
> (the best of which are on this list) of what their path should be in many
> different operating environments and parts of the country.
>
> Solution:
> Take "paths" and throw them out the window.
> - (During the transition having a path will work with the "old" digi's)
>
> The number of times a packet is digipeated is network specific based upon
> the current load of the network.
>
> The Digipeater should decide whether to throw out the packet, delay it to
> see if it was heard by another digi, or digipeat it immediately.
>
> The digipeater will have to know:
> It's location
> It's PHG (coverage area)
> How many hops it is to a reliable I-Gate
> It's altitude (both average ground elevation for the area and antenna
> elevation above that terrain).
> List of stations it has heard (MHeard)
> - That list will also keep track of the packet location
> Current channel loading
>
> We need the digi to decide!
>
> Examples:
> If a digi hears a packet from one mile away (It knows it's location and
> the location of the packet), and it has not heard a packet from this
> station in X minutes the packet should be repeated!
> (x is variable based upon the number of unique "direct" stations it has
> heard, and has the station moved more than Y distance).
>
> - If the station did not move (horizontally or vertically), and a packet
> was heard from the same station 10 seconds prior should the packet be
> digipeated?
>         - Normally most of us would say "no", but if the channel loading
> is zero, then why not! (Private or test network)
>
> If a digi hears a packet from a station 100 miles away, should the packet
> be digipeated?
> - Was it heard directly?
> - Was it digipeated by another digi?
> - What is the channel loading?
> - Is the station moving or fixed?
> - How long has it been since THIS digi repeated the packet?
>
> ----------------------------
> With modern TNC's available there is no reason not to start working on a
> modern solution.
> - Existing TNC's could be used if put into KISS mode and using small
> single board computers such as a Raspberry Pi.
> - An ideal solution would be a dedicated solution (Tracker3, TNC-X, etc)
>
> The idea of this email was not to list "all" of the needs, but simply to
> point out that until (WE) begin to think of what is needed and begin to
> think of the algorithms needed, we will continue to have "path" problems.
>
> Respectfully,
> Mark Cheavens
> KC5EVE
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140713/8ed819c2/attachment.html>