[aprssig] The new D710 and Smart Beaconing?

[Robert Bruninga]

Ah, this is a common trap to fall into... 

> Possibly a better algorithm would be to have it 
> beacon *less* frequently if it heard its own 
> packet digipeated *unless* it hears very little 
> traffic overall.  

Ah, but it is nearly impossible for a TNC in a mobile to tell
the difference between a saturated/overloaded channel from a
lightly loaded one.  Both of them have fewer decoded packets.  

> If the channel is lightly loaded, then increasing 
> the frequency of the beacon will not hurt, and 
> it is more likely that you are in a more remote 
> area where it may take a few tries 
> to get a packet through unscathed.

This is simply not possible to assume.  And that is why this
kind of approach assures network melt-down (grid lock) above a
certain threshold.  Let me explain.

1) The mobile can only hear the output of a digi.
2) When the channel is overloaded, the digi hears far more
collisions and actually FEWER packets get through the digi.
3) The mobile cannot tell the difference between low numbers of
packets due to low useage, or low numbers due to total overload
and collisions at the input of the digis.

This is fundamental to packet radio and goes all the way back to
the 1960's and the first ALOHA networks.  Starting with a clear
channel, as  you add users, the throughput goes up linearly.
But as you add more users, the throughput begins to taper
slightly.  Add more users and the throughput almost flattens
out.  Add more users and the throughput starts to drop off
rapidly.  Add more users, and throughput rapidly approaches
zero.

The optimum point has been proven to be at about 18% of channel
capacity for an ALOHA network.   It can be as high as 36% if
everyone can hear everyone else simplex.  (This is NOT APRS)...

But in any case, since the "throughput" curve goes up and also
back down, then there are two meanings to any "measured
throughput".  One meaning is lightly loaded.  The other is
saturated.  But they both have the same value and it is
impossible for the mobile to tell the difference.  Notice also
that the curve crashes faster above the optimum loading than it
does going up.  That  is why we try hard to reduce QRM on the
APRS channel whereever possible.

Yes, the DIGI can tell the difference if it compares CARRIER
squelch-open times to decoded packet times.  But the mobile
cannot..  So the mobile should never thrown more packets on the
channel when it sees less success!

Bob, WB4APR

> ----Original Message Follows----
> From: Earl Needham via Kubuntu <needhame1 at plateautel.net>
> Reply-To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
> To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
> Subject: Re: [aprssig] The new D710 and Smart Beaconing?
> Date: Wed, 23 May 2007 11:43:09 -0600
> 
> On Wednesday 23 May 2007 11:25:56 scott at opentrac.org wrote:
>  > The Tracker2 has a new feature I'd like to see more widely 
> implemented -
>  > you can set it so that if it hears its own packet 
> digipeated, it'll skip
>  > the next n transmissions.  This means you can set a fairly 
> high beacon 
> rate
>  > to get a better success rate out in the middle of nowhere, 
> but when you 
> get
>  > into an area with better coverage it automatically cuts 
> back on beacons.
> 
> 	The HamHUD had a similar feature some years ago.  If it 
> did NOT hear it's 
> own
> packet repeated, it would send it again.  I believe it would 
> send a total of
> three of these before it gave up.  I believe this feature was
finally 
> deleted
> due to complaints of "over-beaconing".
> 
> 7 3
> Earl
> KD5XB
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
>
________________________________________________________________
_
> More photos, more messages, more storage-get 2GB with Windows 
> Live Hotmail. 
> http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_
TAGHM_migration_HM_mini_2G_0507
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>