firmware
firmware copied to clipboard
meshtastic
[Feature Request]: Range check and mesh complexity: Proposed Backwards compatible Meshtastic protocol improvement
Platform
NRF52, ESP32
Description
Proposed Backwards compatible Meshtastic protocol improvement
Proposed change
Place the original hop count in the unused bits of the Packet Header Flag. For the purpose of this document I will call this HopStart
Objectives
The objective of the change is to provide a hop count for every Meshtastic packet in a way that is back compatible with the current protocol. Further development of the support applications would provide two useful metrics.
- Range check (ie identify nodes that are zero hops away)
- Mesh size by identifying nodes that have a minimum hop count that is large.
This can be done without extra mesh traffic and without the requirement for all nodes to upgrade to this protocol. It may even be the case that nodes running current firmware would participate in the propagation of the extra information without modification.
Assumptions
These assumptions are made in this proposal but may require additional effort to verify.
- The active protocol is as described in https://meshtastic.org/docs/overview/mesh-algo/ and will continue to be used into the near future.
- The unused bits of the Packet Header Flag are set to all zeros or all ones and are not uninitialized to random values.
- That the current firmware retransmits the Packet Header Flags intact, except for decrementing the
HopLimit. OR (less desirably) with the unused bits set all to zero or all to ones.
Notes about trace route
The trace route functionality provides a similar solution but requires custom communication and is found to be unreliable where mesh condition are poor. The trace Route process provides addition information about nodes that are used in the hopping.
Example uses
Range check
Any packet received with a HopLimit that the matches the HopStart is now know to be a direct connection from the sender. If the senders location is known then the receive range can be calculated or the node added to a map showing the receive range.
Mesh size
The difference between the HopStart and HopCount indicates how many hops occurred in the transmission of the packet from the originator. A record of the smallest hop count for the node can be kept indicating the minimal numbers of hops need to reach the node. This could be displayed along with the nodes location on a map.
Good idea, I would be in favor. In fact, I already proposed it as part of #2856, but that PR is a breaking change. This change however can be implemented now; I verified when adding the viaMQTT bit that the currently unused bits are set to zero now.
It would also remove the confusion of seeing a high RSSI/SNR value for a remote node that is far away, because those values are from the last relayer and not the original transmitter.
So the idea here is that any incoming packet will include data on how many hops it made to arrive? This seems like a very good idea. Would remove a lot of confusion, as @GUVWAF said.
Yes, or actually it includes the hop limit with which it started and the current hop limit. So the difference between these values will be how many hops it traveled.
I picked the necessary change for this into this branch.
If others agree to use the remaining three unused bits in the header for this, I will open a PR.
So on arrival, a packet would include both the original hop limit as well as the remaining hops available, allowing receiving device to infer whether a packet was relayed and if so how many times.
Though it seems it should be relatively trivial to implement the ability to determine whether a packet was relayed at all without using packets - simply compare the originating nodeID with the nodeID from which the packet was received - if they don't match, it was relayed. This would not use any of those extra bits.
But the problem is we don't add the nodeID when relaying a packet. Only the original transmitter and destination are set. Besides, then you only know who the last relayer was (if any), and not how many hops it needed in total.
But the problem is we don't add the nodeID when relaying a packet. Only the original transmitter and destination are set. Besides, then you only know who the last relayer was (if any), and not how many hops it needed in total.
But we know who we received the packet from, as in which node transmitted the packet that we received, right?
Anyway, yes, you're right that this wouldn't tell us how many hops total - but would at least give metadata that a hop was used.
But we know who we received the packet from, as in which node transmitted the packet that we received, right?
No. We only know who the original transmitter was. When a node relays, the packet is an exact copy of the original packet except for bumping down the hop limit by one.
When a packet arrives, is the radio that sent that packet not known? I was not aware of that.
On Sat, Feb 17, 2024, 16:48 GUVWAF @.***> wrote:
But we know who we received the packet from, as in which node transmitted the packet that we received, right?
No. We only know who the original transmitter was. When a node relays, the packet is an exact copy of the original packet except for bumping down the hop limit by one.
— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/3239#issuecomment-1950227484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJXK4IV6SS4JVIAJC6JFDBLYUC7KBAVCNFSM6AAAAABDNG75YGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQGIZDONBYGQ . You are receiving this because you commented.Message ID: @.***>
No, unfortunately not. The header only includes the original sender and this is never changed when relaying.
Interesting. Then yes, this is a very good idea and would really help with troubleshooting. Being backwards compatible is the cherry on top.
On Sat, Feb 17, 2024 at 5:01 PM GUVWAF @.***> wrote:
No, unfortunately not. The header https://meshtastic.org/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging only includes the original sender and this is never changed when relaying.
— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/3239#issuecomment-1950230321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJXK4ITPMK5ZMYBVGXHSA4LYUDA6FAVCNFSM6AAAAABDNG75YGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQGIZTAMZSGE . You are receiving this because you commented.Message ID: @.***>
You can infer hops and you know the originator. You do not know the nodes it hopped through. The last hop is only a receive path. No guarantee you can tx to that node. However it would be a very good indicator of how well your antenna is receiving. If the field is zero the sender does not support the feature. (I guess further checks could be made against the sw version of sender if known.But I don't think it is required) We may be lucky and current sw will tx the flags as is apart from the decrement so only sender and receiver need to have the feature. This will help rollout without a need to update legacy relay nodes. Also, as someone pointed out, this can be used to remove the confusion that the signal metrics that are only for the last hop. Now we know it's not direct and can visual differentiate in app between metrics from the actual originator and those from an unknown intermediate node.
So the idea here is that any incoming packet will include data on how many hops it made to arrive? This seems like a very good idea. Would remove a lot of confusion, as @GUVWAF said.
The hop count is inferred from the initial count and the current limit.
But the problem is we don't add the nodeID when relaying a packet. Only the original transmitter and destination are set. Besides, then you only know who the last relayer was (if any), and not how many hops it needed in total.
But we know who we received the packet from, as in which node transmitted the packet that we received, right?
Anyway, yes, you're right that this wouldn't tell us how many hops total - but would at least give metadata that a hop was used.
I think you know the originator, remaining hops and the original hop count. From which you can deduce the number of hops.
A simpler (non-standard and breaking) solution would be to start with hop=0 and count upwards until the limit is reached. Then you don't need additional fields and calculations.
That’s indeed also a solution, but that would need to be for version 3.0. However, it also changes the routing logic because then each relayer decides whether the packet still needs to be forwarded, whereas now the original transmitter decides it for everyone.
A simpler (non-standard and breaking) solution would be to start with hop=0 and count upwards until the limit is reached. Then you don't need additional fields and calculations.
This is not compatible with current repeaters. Setting HopStart and making it fixed would be as repeaters should just decrement the HopLimit.