[aprssig] APRS Priority bit

[Bob Bruninga]

> 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..

That was not the idea at all.  It is a desimation filter.  There are three possible actions based on PRIORITY depending on the degree of decimation needed..  Starting with the least impact, going to the most impact, depending on the MINIMIZE level set at the digi for the immediate situation...

1) pass priority, subtract an extra -1 to routine
2) pass priority, digipeat routine once
3) pass priority, ignore routine
4) decremet priority an extra -1
5) digipeat priority only once.

I wonder if I was premature in assigning the use of the newly discovered overlay-case-bit to the priority requirement.  Although I believe adding priority was the next most important bit for APRS, maybe we need some more testing.  SIlly me, I didnt even test it yet on the D7 or D700!


I dont care that you cannot enter it in the older radios, but we need to know what they do when they receive an overlay such as lower case "a"...

Ill try to remember to test it tomorrow.

Bob
>   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