[Xastir] Smart RELAY digipeating

[James Ewen]

At first I thought Tapio simply didn't understand the workings of the APRS
network, but I think he's onto a good idea here!

> I haven't looked at 
> the source code (yet), but it looks like Xastir digipeats all 
> RELAY packets it hears, as the basic rule goes. This results 
> in my station repeating packets that a WIDE digipeater 10 km 
> away already digipeated. And then the WIDE digipeater 
> digipeats the frame again after Xastir has done the RELAY digipeating.

As is to be expected. Every station that is acting as a RELAY that hears the
mobile using RELAY, will digipeat the packet. That's why I'm not a big fan
of having everyone act as a RELAY station, as some people support. One
should only act as a RELAY station IF their station covers an area that is
NOT covered by a WIDE digipeater, or another RELAY station.

Since most of the digipeaters out there are not "smart digipeaters", every
packet relayed to it will get resent on the WIDE portion of the path, even
if it has been digipeated by that WIDE digipeater any number of times
before.

> Now if Xastir postponed the decision to RELAY or not for a 
> few seconds after receiving frame 1, it could watch the band 
> for possible digipeats of the packet. After seeing in frame 2 
> that a local digipeater W has digipeated the packet, Xastir 
> could decide that the packet has reached the WIDE network and 
> there is no need to generate extra QRM on the frequency.
> 
> After thinking what I wrote above for a moment, maybe this 
> could be done without user specified digipeater configuration 
> so that whenever a packet that is a candidate for RELAYing is 
> heard again on the band, i.e. 
> digipeated by anyone, it would not be sent again.

Now you're onto something here!

> So what do you think, would this be worth the coding trouble? 

I think every APRS client should have this coded into it before they should
be allowed to act as a RELAY!

> If this was implemented, turning RELAY digipeating on would 
> never hurt (much) even in a crowded area. But say if 10 
> stations configured for dumb RELAY digipeating heard a 
> packet, there would be at least 9 extra packets heard on the 
> band. 

Actually, there would be 10 extra packets assuming the WIDE could hear the
mobile as well, and that these 11 digipeaters are all of the digipeaters in
the network.


> If duplicate checking was done before RELAYing, ideally 
> the other nine would not key their transmitters after seeing 
> the packet is digipeated.

This would make sure that even if someone was wandering around with an HT on
.1 watts, they'd be RELAYed while the mobile in the same area with 50 watts
wouldn't trigger the RELAY when he's already been heard by the WIDE
digipeater.

Only those stations that NEED the help would trigger the RELAY.


Curt kind of rambled around a bit then got to the meat of the question:

> I think that's beyond what we want to be doing, although
> we kind of do a similar thing for igating:  If someone 
> else beats us to it we try to skip igating to RF.
> The way to implement this most simply would be to keep a 
> queue of recently heard packets, like we do in the igating
> code, and look up each one before deciding to digipeat.

This sound like the answer! You'd be implementing code similar to what
Kantronics does for it's UIFLOOD and UITRACE algorithms, keep a CRC checksum
of the packet payloads digipeated, and only digipeat unique packets.

The RELAY if no one else has just needs to listen to ALL traffic on the
network, and keep a checksum for each, rather than only looking at packets
it has already digipeated.

The igate code has to be doing this already, since it's listening to ALL
packets on the network to figure out if someone has already gated to RF in
the local area.

If the RELAY section of code could access the queue used by the igate
section, you could look through that queue before deciding to RELAY. If the
packet is in the queue, it's already into the network, so ignore it. If it
is a unique packet, wait for a few seconds and then send it.

Actually, the order of operations should be:

1) RELAY request made by mobile station
2) XASTIR puts packet into to_be_relayed queue
3) XASTIR continues running normal operations until hold off time expires
4) XASTIR checks the recently_heard_packets queue to see if the
to_be_relayed packet has been heard at least 2 times
5) If the to_be_relayed packet has not been heard at least 2 times, then
digipeat the packet.

Why 2 or more you ask? Only once means you're the only person that heard it.
2 or more means it has been heard digipeated by someone else.

James
VE6SRV

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 265.4.3 - Release Date: 11/26/2004