[Feature Request]: Introduce a link inequality offset for nodes with asymmetric tx/rx capabilities

[NomDeTom]

More and more nodes are coming onstream that have gross inequality between their ability to transmit vs receive, such as the T100000e and the Station G2. In the case of the T1000000e, it may believe it has a good chance to pass on a message via rebroadcast, when in fact it is simply the increased sensitivity of the LR1110 is much higher than other radio chips. Combined with the relatively small antenna and close proximity to the user, this means it may need to offset the contention window for rebroadcast to prevent it from broadcasting earlier and less powerfully than a more suitable node.

Alternatively, nodes could perform a "sound check" at switch-on and periodically as time goes, on, sending and receiving 0-hop "traceroutes" and using that to determine an inequality factor for sending and receiving messages.

The BATMAN IV protocol provides some information on how to identify and calculate asymmetric links: https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_IV

[korbinianbauer]

If the T1000e's receiver is more sensitive, doesn't that increase the SNR it perceives and make it rebroadcast later already?

BATMAN_IV assumes we want to use the strongest links to transport a message, but Meshtastics managed flooding does the opposite.

[NomDeTom]

If the T1000e's receiver is more sensitive, doesn't that increase the SNR it perceives and make it rebroadcast later already?

The scenario I imagined was where the tracker is further away, and hears the original rebroadcast at the same SNR as a closer, better-placed one. By rebroadcasting in the same contention window as the better node, it has the potential to sink or hop-gobble packets.

BATMAN_IV assumes we want to use the strongest links to transport a message, but Meshtastics managed flooding does the opposite.

Yes, I was looking at it to see if there was anything of value to help the other routing protocols under consideration, or to quantify a nodes relative effectiveness, so that it can be used as a modifier for the current managed flooding implementation.

[korbinianbauer]

The scenario I imagined was where the tracker is further away, and hears the original rebroadcast at the same SNR as a closer, better-placed one.

Meshtastic usually considers the node that's further away the better candidate to rebroadcast.

If the tracker is further away and you still don't want it to be the one that rebroadcasts, then it should probably just be set to client_mute

[NomDeTom]

Meshtastic usually considers the node that's further away the better candidate to rebroadcast.

If the tracker is further away and you still don't want it to be the one that rebroadcasts, then it should probably just be set to client_mute

This request is about incorporating such a binary choice into an adaptive part of the system - the potential reach that a node has Vs it's ability to receive should influence whether it is considered the better candidate.

It is worth considering the reverse situation: should a node with a broken antenna be considered a good candidate?

[Ryu945]

If the T1000e's receiver is more sensitive, doesn't that increase the SNR it perceives and make it rebroadcast later already?

BATMAN_IV assumes we want to use the strongest links to transport a message, but Meshtastics managed flooding does the opposite.

You miss read. He is saying the LR1110 is more sensitive.

Meshtastic`s goal is to make the further away node broadcast. We ideally want the stronger nodes broadcasting. The problem is that there is nothing implemented to see if a node is further away or if it is just a weaker node. They look the same to the protocol. He wants to implement some system that should be able to distinguish the different between a weaker node verse a further away node. Then the rebroadcast time can be adapted based on the results. I am not sure how to accomplish this myself which is why I suggested letting the user manually set a node as a stronger node.

[korbinianbauer]

I don't follow how "rx capabilities", "tx capabilities", "weak", "strong", "more sensitive", "further away" relate to each other in the context of this proposal then.

Does a LR1110-node broadcast earlier or later than it should in your opinion, and why?

[Ryu945]

I don't follow how "rx capabilities", "tx capabilities", "weak", "strong", "more sensitive", "further away" relate to each other in the context of this proposal then.

Does a LR1110-node broadcast earlier or later than it should in your opinion, and why?

The Meshtastic protocol broadcast earlier the weaker the signal appears to be. From what I understand he is saying, LR1110 is a stronger antenna so the signal will always appear stronger when viewed from that antenna. Thus a LR1110 device will always broadcast later then a T1000E at any given distance. T1000E has an early broadcast advantage over LR1110 since T1000E has such a weak antenna.

Logically though, we want the stronger antenna node to be the broadcaster. To fix this problem, we need some way to tell the algorithm to give a preference to the stronger antenna. This could be something like my idea of having a three tier system so that better placed nodes are given a preference.

https://github.com/meshtastic/firmware/issues/8117

You could also implement some way to determine which nodes communicate better like NomeDeTom has suggested.

Another possibility is to put a timing offset in the algorithm for every single model of meshtastic device. This would remove the rebroadcast speed advantage of low gain antennas and flip it the other way so that higher gain devices have the rebroadcast advantage.

[wlockwood]

Metric such as "percent of my messages that I heard retransmits of", "percent of successful DMs/traceroute" or a combination "average 0-hop SNR" and "number of nodes I've heard in the last X minutes" seem like promising candidates for this effort.

[NomDeTom]

Metric such as:

• percent of my messages that I heard retransmits of
• percent of successful DMs/traceroute

or a combination of

• average 0-hop SNR and
• number of nodes I've heard in the last X minutes

seem like promising candidates for this effort.

@wlockwood are there any others you can think of? Just wondering if this information is already in one of the existing metrics.

[wlockwood]

Thinking about it a bit more:

• Median distance of direct and/or active nodes - A device with better reach may determine that by the real-world distance if it's available. Using median and a lower threshold (>5 nodes?) should let us avoid random ghost plane nodes.
• Local noise level - A device with a high local noise level could de-rate itself based off of background noise. This one needs some noodling - it feels promising but also could be problematic: how should this metric de-rate a mountaintop repeater on a radio tower?
• Active node count where a node counts as 1/[number of hops] with direct nodes counting as half a hop. This should prefer nodes that have wider coverage, since anything that sees a lot through this node will have a lower number than the forwarding device.
• Active bidirectional node count. As above, but only count them as active if we've had some form of bidirectional communication (DM, traceroute, direct). This is probably the best one for handling asymmetric links.

I hope that doesn't sound too dumb, 1PM-brain wants a nap.

[github-actions[bot]]

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.

[wlockwood]

I don't know that anybody has done work on this, but it also probably shouldn't be closed simply due to inactivity.