[aprssig] APRS Priority bit

[Wes Johnston, AI4PX]

I can't get the page to load to read the priority article.  However, at
first brush, I'm a little bewildered by this.  In the past DWAIT 0 has been
pushed and digipeaters are supposed to digi straight away.  Digi's should
not wait to digipeat a packet. Fracticide and the FM capture effect are
supposed to keep me from hearing multiple digi's of my packet.  An example
of this is in the morning when the band is open, I often see my packet
digipeated by two digi's simultaneously.  Well to be more correct, I'm dead
in the middle between two of them and can't decode either, but I do see the
S9 digi drop first leaving a few milliseconds of the S3 digi's packet.  This
is how it's supposed to work.

To say that a packet would have priority over other packets makes sense when
you have lots of packets queued up and *could* reorder the queue and push
the hi priority packets to the head of the line.  But that's not how it
works on 2m.  Digi's are supposed to respond ASAP, one packet at a time.
There is no possibility to hear a 2nd packet before digipeating in a
properly configured digipeater.  Are we to assume that a digi would
intentionally delay a given packet just in case something of a higher
priority came along in the next few seconds?

Something that was suggested a few years ago focused on the low priority
packets.  Perhaps a different perspective of the same problem... instead of
marking some packets as hi priority, let's mark some packets as low
priority.  Multiple packets could be accumulated and digipeated all at once
at the end of some interval.  For example, a WX station could be said to be
low prority trafic.  So the digipeater queues such packets and at the end of
120(??) seconds would spit all of them out.  The savings would be (N-1) x
txdelay seconds.  Other opportunities for low priority traffic could the the
beacons of other neighboring digipeaters.

As far as where to indicate low priority, I believe it needs to be in the
ax25 header, not embedded inside the data portion of the packet, UI-view
bedamned....  (no offense to UI-View users intended).  As far as I can see,
fixed firmware digipeaters are more of a legacy problem than ui-view in any
case.

Wes
---
Hitler gave great speeches too!


On Wed, Aug 19, 2009 at 10:05, Robert Bruninga <bruninga at usna.edu> wrote:

> APRS needs a priority bit so that the network can make decisions
> about traffic during times of stress.
>
> We have been looking for a way to include a PRIORITY bit in all
> APRS packets for many years, and there are 3 available bits in
> the standard packet, but they cannot be used until UI-view is
> obsolete.
>
> This last week we did find that one of these bits IS backwards
> compatible with UI-view and so we would like to move forward on
> this issue.  Please read:
> http://aprs.org/aprs12/priority-bit.txt
>
> Basically, we will use the CASE of the OVERLAY byte to indicate
> ROUTINE or PRIORITY.  If the overlay byte is UPPERCASE or
> missing, then the packet is ROUUTINE.  If the case of the
> overlay byte is -lowercase- then the packet is PRIORITY.
>
> Last week testing confirmed that UI-view and most other clients
> will display these lower case overlays, or can be updated to do
> so, so this has now been added to the APRS12 addendum.
> www.aprs.org/aprs12.html
>
> This combined with the OPERATOR PRESENT bit which has been
> defined for years, gives operators an easy way to differentiate
> assests of immediate value during times of stress and to
> minimize or ignore routine or unattended systems as needed.
>
> DIGIPEATER code can add a SYSOP parameter that allows a sysop to
> designate a local emergency and to implement a MINIMIZE function
> that lets the digipeater make decisions on traffic load based on
> packet priority or other parameters.
>
> Bob, WB4APR
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090819/e8c86636/attachment.html>