[aprssig] APRS CSMA Settings

Kenneth Finnegan kennethfinnegan2007 at gmail.com
Mon May 19 15:53:02 EDT 2014


My apologies for digging up all of our skeletons today.

Reading the APRS specs, I haven't seen any mention of the layer 1
channel access behavior other than that APRS is based on the ALOHAnet
work from the 1970s. As far as I can tell, the competing CSMA
behaviors are:

1. None. Transmit as soon as you have traffic
1a. Time slotting. Transmit during your allocated time slot (seconds
since top of hour modulus beacon interval).
2. DWait. Wait for a specific period of quiet time before transmitting
any pending traffic
3. P-persistent. Randomly transmit during a quiet time slot.

Deaf trackers obviously must follow the first algorithm.

Reading the archives, it seems that Bob, et. al usually promotes no
CSMA (algorithm 1) for digipeaters as well, due to:
* Effective channel access further multiplying bandwidth consumption
since each local digi will repeat a packet further in the future.
* The theory that FM capture effect allows all the digis to double
each other. I haven't seen any experimental evidence that this works,
and doubt it'd work for moving receivers.
* The argument that APRS networks have so many split horizons that
it's a waste of time.

I've been trying to reconcile this with the ALOHA channel statistical
models and Bob's assertion that we need to support 60 stations on the
local network.

I'm not sure where the original 60 number came from, but my modeling
for APRS is coming up with a maximum station count oddly close to 60,
but this is using all the optimistic assumptions like Poisson packet
arrival, p-pers channel access, etc. that Abramson used in his packet
broadcast channel work in the 1970s. Taking away p-pers hurts the
channel throughput, as does the much lower level of entropy in the
actual arrival times of packets on RF. (I haven't figured out how to
quantify the actual arrival time entropy, but since many trackers
don't insert any randomness in their fixed X second interval the
Poisson models seem optimistic...)

I understand that part of the concern is that super-high digis will
never hear any free channel time, but that doesn't seem to mean that
we can't be using p-pers to better application on the lower levels of
the network. Here's the channel distribution on a low level digi in
San Luis Obispo, CA, which is a grossly under-loaded network:
http://i.imgur.com/jSphYCY.png (the first bar is up at 5,000)

The strongest counter-argument I see for using p-pers is the fact that
unlike every other application of AX.25, we have a 30 second deadline
on the life of a specific packet, so any sort of queuing in
digipeaters is dangerous, and even computer-based digis with KISS
modems can't overcome the limitation that KISS doesn't support tagging
packets with a deadline for when it should be dropped instead of
transmitted late. This is unfortunate since channel acquisition is
such a large fraction of transmit time in APRS (my tests are showing
we can't depend on anything less than 300ms for TXDelay), so having
digis queue packets and dump them in a single burst every N seconds
would be an interesting improvement (unless you're trying to use a
Kenwood in KISS mode).

It would seem that a reasonable recommendation would be DWait=0 for
high level digis (unless we could implement hard deadlines) and
statistical channel access for low level digis to enjoy better
throughput in the smaller cells. Thoughts?

Unfortunately, this is one of the places where we probably can't give
definitive recommendations in the spec, since exact L1 behavior is
going to depend on the local network design.

This is all ignoring the interesting "viscous delay" layer 3 channel
access behavior, but that argument was had with the Helsinki guys back
in 2009.

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SLO_rfarrival.png
Type: image/png
Size: 19881 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140519/a77dc0e8/attachment.png>


More information about the aprssig mailing list