APRS OBJECT-Caching SPEC:                               7 June 2004
-------------------------------------------------------------------
                                                             WB4APR

OBJECTIVE:  A format to signal to a digipeater or other specialized 
APRS station to cache, or take over reporting responsibility  for a
given object/station. This technique improves channel efficiency by 
more than a factor of two for these objects because it eliminates 
the uplink contention to the  digi on all subsequent repetitions, 
and because the DIGI has better CSMA performance, it assures better 
reliability on delivery.

OBJECT FORMAT:  Identical to existing OBJECT format
   Fully backwards compatible in all respects.  No chnages 
   to any existing APRS formats nor client software are
   required.
                           
TARGET DIGI:    The digi or station to cache the OBJECT
   is specified as the FIRST digi in the  path.  The DIGI 
   call must be an explicit match, must be first,  and that 
   digi must have heard the packet DIRECT.

TOCALL:   To signal a cache request to the DIGI to take 
   over responsibility,  the object packet will use the special 
   APRS TOCALL of AP0Cxy (that's a zero).
   Where:       x = expiration time in hours from now
                y = final periodiciy in TENS-of-minutes

DIGIPEATER OR STATION RESPONSE:  On receipt
  of a Cache Request, that meets the criteria above,
  the designated digipeater will add the OBJECT format
  to its OBJECT cache but will change the TOCALL
  from AP0Cxy to  AP0Oxy for subsequent transmission.
  As time elapses, the "x" expiration time counts        
  down so that it can be interpreted as hours to go.

CACHED OBJECT ACKNOWLEDGEMENT:  On receipt 
  of the Cache request, the DIGI/station taking over 
  responsibility will acknowledge that fact by simply 
  sending out  the first copy of the cached object.  ALL 
  existing APRS spec compliant code will already see 
  that response and will relinquish any uplink responsibility.

CACHED OBJECT TIMING:  Since such a request is
  usually the result of a NEW object or a changed position
  of an object, the Caching digi should implement the
  usual decayed rate algorithm before settling in to the
  requested ultimate refresh rate to make sure that all
  stations on the net had a higher than normal probabilly
  of receipt of this new data.  A suggested implementation
  algorithm is to send the second Cached OBJECT one
  minute later, then 2, then 4, then 8, then 16 minutes
  later and so on until the final requested rate is reached.
  This is the original APRS decaying algorithm for new data.
  Authors are allowed flexibility in the details of this 
  routine as long as an effort is made to have at least
  a few copies transmitted within the first few minutes.

CACHED OBJECT PATH:  The Cached OBject path
  can ONLY be direct.  The intent of this process is
  to OPTIMALLY serve only the local area with the
  multifold improvement in reliability.  PLEASE NOTE:
  If this rule is violated and the OBJECT is sent out
  for further digipeating, then the fundamental 
  objectives of the whole idea is lost, since now the
  packet is no different with respect to collisions
  and doubling of channel capacity.

  The one exception to this rule is under DIGIPEATER
  SYSOP control who may specify an alternate
  REQUIRED path for all such cached objects.  A good
  example here is a special event which requires 3
  main digis to serve the entire venue.   This is known
  in advance and so the SYSOP for these 3 digis
  establishes a specified explicit CACHE path that includes
  the other two digis.

  The other objective of this DIRECT-ONLY rule is
  to prevent remote SPAMING of distant areas.

CACHED OBJECT CANCELLATION:  The rules for the cancellation   
of the cached object from the digi are no different than
existing APRS1.0.  That is, it will automatically cancel
the object immediately on receipt of any other identically
named object from anyone.

BACKGROUND AND DETAILS:   This caching idea has been in 
APRSdos since about 1995 or so and is compatible with the 
existing spec.  The only difference here is that in APRSdos, 
the process was called OBJECT-NET-CONTROL where APRSdos, 
IF-ENABLED by the SYSOP for a one-time event, would 
automatically take over reporting responsibility for ALL 
objects at the event.

Then in 2004, Scott Miller suggested that the originator
of an object should be able to request such action
remotely.  This spec is the result of these two ideas.

NOTES on HOW OBJECTS ARE HANDLED BY APRS1.0.  
None of this is impacted in any way:

1) Taking over responsiblity for objects has always 
been fundamental to APRS.  This means that ANY station
that is SENDING an object, will, on seeing the SAME
object name (case dependent) from a different station,
will CEASE its own uplinking and will accept as a
replacement the new OBJECT data from the new
station.  

2)  Clients are required to always retain the identify of
the SENDING station so that end users can easily tell 
who has responsibility at any instant.

3) Due to the promiscuous nature of Object ownership
all client programs SHOULD display the data AT ALL
TIMES and on the MAP as well whether the object
is owned by THIS station or another station.  Example:
APRSdos always displays OWN-STATION active
objects as YELLOW, and other station objects as
Purple.  Notice these color can toggle at any time
and on a packet-by-packet basis... and so these
provisions assure the operators are fully aware of
the changing ownership.  Without these ON-THE-MAP
distinctions, it is very dangerous, because you can
never be sure if the object you placed at location X
is still there, or actually has been moved across
the street without your knowledge!


Anything I missed?
Thanks.
de WB4APR, Bob