You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't fully formed and is this the outcome of a thought experiment I was doing yesterday afternoon to address the major issues I have and see with the mesh in my area and for my application. I had originally planned to adapt a custom firmware for myself which I still may do but I would like to open the discussion and share ideas.
I have reviewed some of the issues and discussions on here briefly but I happily will admit I have not exhaustively reviewed the full codebase, I have attempted to review the overall structure and packet architecture to make sure these ideas would however fit around minimal changes. So I will start by apologising now for any glaring lack of knowledge but I'd like to think together we could address any obvious holes constructively.
Background
I am in a relatively remote/rural location with limited mesh connectivity partially due to the topography of the area causing many blind spots, although there are several users in the area from traffic I have seen. I am deploying several repeaters to help but I often work remotely in different areas. In these locations it is not possible for me to deploy fixed repeaters and nor would I have permission to do so.
I have built in repeaters on both my ATV and my vehicle which by parking strategically I can often extend the network into areas, with my truck having both companion and repeaters present to enable remote functions. My issue is often where I park I can potentially see other mesh users but no repeaters. I don't believe I am the only one with issues similar to this from discussions I have seen and from looking at repeater map.
Why?
I believe it would have potential to drastically improved the coverage of the mesh in some areas and be considerably more robust. With the added benefit of allowing the network to heal and extend should key repeaters be removed or fail. In my area there are several key repeaters with the failure of any of them at present huge areas of coverage would be completely broken and limited to zero hops.
Summary
The proposal is to introduce a "Adaptive Repeater / Companion" mode (AR/C?) for Meshcore companions, allowing them to adaptively forward traffic when they detect a connectivity gap and stand down when existing routes provide equivalent connectivity. Set limits could prevent this form of repeating meaningfully congesting traffic although I feel that in the areas where traffic is high careful gating surrounding it would simply not activate it.
I believe much of the information needed is already available from existing mesh traffic, potentially allowing the adaptive logic to operate without additional periodic discovery packets or control traffic. Additional airtime would primarily come from the useful forwarding itself. Companions can by observing the flood traffic already present and using repeater/path information identify likely connectivity gaps.
This proposal would allow them to step in and extend the mesh, bridging isolated repeaters, and forming temporary isolated meshes until other routes become available via ideally permanent repeaters. This would also be particularly valuable if a single key repeater was to fail by allowing networks to potentially heal around them over time rather than fully collapse.
I picture the requirements to activate a adaptive repeater or companion gated in a way that requires multiple failed connectivity events and it not be immediately event driven to prevent false triggering during packet loss etc... and for there to be limits to airtime usage so adaptive routing cannot congest a network or activate in one.
I think that almost all this could be achieved without any additional information and observation over time, But I feel ideally to speed things up 2 bits of the FEAT1 bytes could be used to indicate a)A node is acting as a repeater B)a node is not able to "discover or hear" a repeater.
Potentially there could also be an advantage to identifying AR/C nodes within observed forwarding paths by correlating their hashes with previously received advertisements, particularly when deciding which adaptive nodes can safely stand down. I don't believe this is a core requirement but a refinement. With it in this current iteration at its core aiming to form a usable network in areas where one is not present rather than forming a perfectly optimal one.
The how...
-----Proposed logic steps of Implementation 1 & 2----
Observe: Monitor flooded packets and paths, including duplicates before normal deduplication occurs.
Identify gaps: Comparing flood traffic from neighbouring nodes/repeaters, a node can gradually build a partial picture of observed connectivity between nearby companions and repeaters, identifying potential bridging opportunities where independent forwarding paths are not observed. If two groups have no observed independent forwarding path, it can flag a potential bridging opportunity.
Trial forwarding: Temporarily activate AR/C mode forward eligible floods to test whether the companion can connect the groups. Observing subsequent retransmissions containing the companion's hop hash between the groups indicating that forwarding is likely productive.
Maintain: Continue forwarding while the identified connectivity gap remains dependent on this bridge.
Stand down: Upon repeated observations confirming an independent path that maintains the original connectivity, the adaptive companion could cease general flood forwarding while continuing to forward directed messages using previously established routes through it. This would minimise disruption to existing connections and allow flood forwarding to reactivate should the alternative fail.
Recover/loop: Reactivating by the same means if the alternative path disappears.
Stages
I have broke the structure into 3 main implementation stages with different benefits and solving individual issues.
------ Implementation 1
Simple bridging of existing repeaters where connectivity is consistently not present.
--Example Implementation 1 behaviour--
Two repeaters, R1 and R2, cannot communicate directly, but a companion (C1) can hear both.
C1 detects the apparent separation from flood observations seeing R1 floods are consistently not repeated on R2. So it trails activating as a repeater and begins forwarding. Once R1 and R2 exchange traffic through C1, it remains active.
If another route subsequently connects R1 and R2 without C1, it verifies that connection and stands down.
To prevent multiple companions activating adaptive routing all at once my thoughts jumped to using a rand seed chance of activation, but equally random delay or simply optional pop up on the device asking if a user wishes opt into assisting the mesh could work but I think in Implementation 1 I prefer an opt in at setup and then automatic activation when needed for R-R traffic bridging.
An isolated companion (C1) is on the edge of a larger mesh. It can hear another companion (C2) & C2 can hear a repeater (R1). C2 can infer a lack of communication by C1 to the wider network from observing traffic relating to C1 not repeated by R1. There is also potentially a benefit here or case for using a bit flag in adverts from C1 to indicate C1 has no repeaters in range to speed up detection of isolated nodes.
Once C2 has confirmed that traffic is not above thresholds on the wider network and that C1 is isolated it could adaptively become a repeater bridging traffic to R1 and extending the mesh.
By extension of this now C1 can now hear an adaptive repeater (C2) and so the process can repeat to other nodes upstream and the network can cascade down the line with nodes adaptively bridging the network to the closest repeater, this would potentially with Implementation 3 assist in camp mode situations to bridge out remote users.
------ Implementation 3
Dealing with fully isolated companion networks no repeaters nearby.
At present any communication is limited to zero hops even though potential routes are there, and proposals I have seen for "camp mode" mean isolation from any wider network should one become reachable along the way or connectivity be intermitted.
--Example Implementation 3 behaviour - Nucleation of isolated companion meshes.
In this example picture an isolated a group of companions with no repeaters, with the implementation of 2 there would now be logic to build out meshes adaptively but it relies on the presence of a repeater to initiate the formation.
In this situation the companions are able to see that they are part of a network as they can observe neighbour companion traffic, they are also aware they are out of range of a repeater. Thanks to Implementation 2 they can infer that the surrounding companions are out of range of repeaters also, either using the proposed bit flag quickly or overtime simply due to the fact that Implementation 2 would likely have caused a neighbour companion to adaptively bridged the repeater to the companion in question if one was present ( or individuals have opted out i suppose).
In this situation the proposed Implementation 2 logic will not work as there are no repeaters for the network to nucleate around. There needs to be a trigger event to create a adaptive "repeater" which will then in turn start the cascade of adaptive network formation by companions.
There are a couple of options I have considered from rand seed chance of activation and random delays to prevent multiple nodes activating at once but I think also in these isolated examples potentially a very simple solution is after someone pushes and advert have a pop up on the device just ask the user if they would like to volunteer to assist the mesh.
After an advert is sent or discovery ( indicating a user is actively looking to make connections) have something along the lines of
No nearby repeaters detected locally (potentially in X time)
Your device may be able to help connect nearby Meshcore users by manually initiating as an adaptive repeater.
It will return to normal operation when alternative connectivity is confirmed.
Would you like to initiate adaptive repeating manually now?
By doing this the node would then activate as a repeater, advertising its self using a bit flag in FEAT1 and cause other nodes to actively bridge nearby nodes using Implementation 1 and 2 logic to form an isolated "self healing" mesh.
Unlike approaches that require switching to a separate camping frequency, this proposal aims to maintain compatibility with the existing mesh and extend its coverage when possible. eg when a true repeater is then detected this would be bridged to the isolated mesh allowing all the users in the isolated mesh to use it. One issue with existing companion repeating is the firmware's restrictions on permitted repeat frequencies, which currently prevent its straightforward use on the established EU/UK Narrow preset. I appreciate this may involve regulatory and congestion considerations that would need addressing.
Appropriate airtime limits, activation thresholds and gradual stand down should help minimise the impact on existing networks, although this would need to be tested under realistic traffic conditions.
Final thoughts
There is the obvious downside of higher airtime usage where adaptive repeaters activate but in the areas where it would likely activate I don't think airtime is an issue as currently Meshcore simply doesn't form effective meshes for this to disrupt. With proper logic and gating I don't believe it would cause significant issues as in areas where this could potentially be an issue eg where there are a high number of users there are robust repeater networks in place.
It would however assist in remote, rural and low infrastructure areas, and add much more resilience by allowing the network to bridge communications via companions when repeaters fail or users are out of range.
In addition there are obvious questions to address sure as timeouts and deactivations if Companions disappear or move on and out of range, as well as other generalisations and simplifications I have made both for ease and unintentionally.
Obviously subject to terms and conditions testing and the will of the gods...Discuss...
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Feature Request/discussion: Adaptive Companion Repeating
Preface:
This isn't fully formed and is this the outcome of a thought experiment I was doing yesterday afternoon to address the major issues I have and see with the mesh in my area and for my application. I had originally planned to adapt a custom firmware for myself which I still may do but I would like to open the discussion and share ideas.
I have reviewed some of the issues and discussions on here briefly but I happily will admit I have not exhaustively reviewed the full codebase, I have attempted to review the overall structure and packet architecture to make sure these ideas would however fit around minimal changes. So I will start by apologising now for any glaring lack of knowledge but I'd like to think together we could address any obvious holes constructively.
Background
I am in a relatively remote/rural location with limited mesh connectivity partially due to the topography of the area causing many blind spots, although there are several users in the area from traffic I have seen. I am deploying several repeaters to help but I often work remotely in different areas. In these locations it is not possible for me to deploy fixed repeaters and nor would I have permission to do so.
I have built in repeaters on both my ATV and my vehicle which by parking strategically I can often extend the network into areas, with my truck having both companion and repeaters present to enable remote functions. My issue is often where I park I can potentially see other mesh users but no repeaters. I don't believe I am the only one with issues similar to this from discussions I have seen and from looking at repeater map.
Why?
I believe it would have potential to drastically improved the coverage of the mesh in some areas and be considerably more robust. With the added benefit of allowing the network to heal and extend should key repeaters be removed or fail. In my area there are several key repeaters with the failure of any of them at present huge areas of coverage would be completely broken and limited to zero hops.
Summary
The proposal is to introduce a "Adaptive Repeater / Companion" mode (AR/C?) for Meshcore companions, allowing them to adaptively forward traffic when they detect a connectivity gap and stand down when existing routes provide equivalent connectivity. Set limits could prevent this form of repeating meaningfully congesting traffic although I feel that in the areas where traffic is high careful gating surrounding it would simply not activate it.
I believe much of the information needed is already available from existing mesh traffic, potentially allowing the adaptive logic to operate without additional periodic discovery packets or control traffic. Additional airtime would primarily come from the useful forwarding itself. Companions can by observing the flood traffic already present and using repeater/path information identify likely connectivity gaps.
This proposal would allow them to step in and extend the mesh, bridging isolated repeaters, and forming temporary isolated meshes until other routes become available via ideally permanent repeaters. This would also be particularly valuable if a single key repeater was to fail by allowing networks to potentially heal around them over time rather than fully collapse.
I picture the requirements to activate a adaptive repeater or companion gated in a way that requires multiple failed connectivity events and it not be immediately event driven to prevent false triggering during packet loss etc... and for there to be limits to airtime usage so adaptive routing cannot congest a network or activate in one.
I think that almost all this could be achieved without any additional information and observation over time, But I feel ideally to speed things up 2 bits of the FEAT1 bytes could be used to indicate a)A node is acting as a repeater B)a node is not able to "discover or hear" a repeater.
Potentially there could also be an advantage to identifying AR/C nodes within observed forwarding paths by correlating their hashes with previously received advertisements, particularly when deciding which adaptive nodes can safely stand down. I don't believe this is a core requirement but a refinement. With it in this current iteration at its core aiming to form a usable network in areas where one is not present rather than forming a perfectly optimal one.
The how...
-----Proposed logic steps of Implementation 1 & 2----
Observe: Monitor flooded packets and paths, including duplicates before normal deduplication occurs.
Identify gaps: Comparing flood traffic from neighbouring nodes/repeaters, a node can gradually build a partial picture of observed connectivity between nearby companions and repeaters, identifying potential bridging opportunities where independent forwarding paths are not observed. If two groups have no observed independent forwarding path, it can flag a potential bridging opportunity.
Trial forwarding: Temporarily activate AR/C mode forward eligible floods to test whether the companion can connect the groups. Observing subsequent retransmissions containing the companion's hop hash between the groups indicating that forwarding is likely productive.
Maintain: Continue forwarding while the identified connectivity gap remains dependent on this bridge.
Stand down: Upon repeated observations confirming an independent path that maintains the original connectivity, the adaptive companion could cease general flood forwarding while continuing to forward directed messages using previously established routes through it. This would minimise disruption to existing connections and allow flood forwarding to reactivate should the alternative fail.
Recover/loop: Reactivating by the same means if the alternative path disappears.
Stages
I have broke the structure into 3 main implementation stages with different benefits and solving individual issues.
------ Implementation 1
Simple bridging of existing repeaters where connectivity is consistently not present.
--Example Implementation 1 behaviour--
Two repeaters, R1 and R2, cannot communicate directly, but a companion (C1) can hear both.
C1 detects the apparent separation from flood observations seeing R1 floods are consistently not repeated on R2. So it trails activating as a repeater and begins forwarding. Once R1 and R2 exchange traffic through C1, it remains active.
If another route subsequently connects R1 and R2 without C1, it verifies that connection and stands down.
To prevent multiple companions activating adaptive routing all at once my thoughts jumped to using a rand seed chance of activation, but equally random delay or simply optional pop up on the device asking if a user wishes opt into assisting the mesh could work but I think in Implementation 1 I prefer an opt in at setup and then automatic activation when needed for R-R traffic bridging.
----- Implementation 2
Would be dealing with isolated remote companions.
--Example Implementation 2 behaviour - Bridging isolated companions
An isolated companion (C1) is on the edge of a larger mesh. It can hear another companion (C2) & C2 can hear a repeater (R1). C2 can infer a lack of communication by C1 to the wider network from observing traffic relating to C1 not repeated by R1. There is also potentially a benefit here or case for using a bit flag in adverts from C1 to indicate C1 has no repeaters in range to speed up detection of isolated nodes.
Once C2 has confirmed that traffic is not above thresholds on the wider network and that C1 is isolated it could adaptively become a repeater bridging traffic to R1 and extending the mesh.
By extension of this now C1 can now hear an adaptive repeater (C2) and so the process can repeat to other nodes upstream and the network can cascade down the line with nodes adaptively bridging the network to the closest repeater, this would potentially with Implementation 3 assist in camp mode situations to bridge out remote users.
------ Implementation 3
Dealing with fully isolated companion networks no repeaters nearby.
At present any communication is limited to zero hops even though potential routes are there, and proposals I have seen for "camp mode" mean isolation from any wider network should one become reachable along the way or connectivity be intermitted.
--Example Implementation 3 behaviour - Nucleation of isolated companion meshes.
In this example picture an isolated a group of companions with no repeaters, with the implementation of 2 there would now be logic to build out meshes adaptively but it relies on the presence of a repeater to initiate the formation.
In this situation the companions are able to see that they are part of a network as they can observe neighbour companion traffic, they are also aware they are out of range of a repeater. Thanks to Implementation 2 they can infer that the surrounding companions are out of range of repeaters also, either using the proposed bit flag quickly or overtime simply due to the fact that Implementation 2 would likely have caused a neighbour companion to adaptively bridged the repeater to the companion in question if one was present ( or individuals have opted out i suppose).
In this situation the proposed Implementation 2 logic will not work as there are no repeaters for the network to nucleate around. There needs to be a trigger event to create a adaptive "repeater" which will then in turn start the cascade of adaptive network formation by companions.
There are a couple of options I have considered from rand seed chance of activation and random delays to prevent multiple nodes activating at once but I think also in these isolated examples potentially a very simple solution is after someone pushes and advert have a pop up on the device just ask the user if they would like to volunteer to assist the mesh.
After an advert is sent or discovery ( indicating a user is actively looking to make connections) have something along the lines of
No nearby repeaters detected locally (potentially in X time)
Your device may be able to help connect nearby Meshcore users by manually initiating as an adaptive repeater.
It will return to normal operation when alternative connectivity is confirmed.
Would you like to initiate adaptive repeating manually now?
By doing this the node would then activate as a repeater, advertising its self using a bit flag in FEAT1 and cause other nodes to actively bridge nearby nodes using Implementation 1 and 2 logic to form an isolated "self healing" mesh.
Unlike approaches that require switching to a separate camping frequency, this proposal aims to maintain compatibility with the existing mesh and extend its coverage when possible. eg when a true repeater is then detected this would be bridged to the isolated mesh allowing all the users in the isolated mesh to use it. One issue with existing companion repeating is the firmware's restrictions on permitted repeat frequencies, which currently prevent its straightforward use on the established EU/UK Narrow preset. I appreciate this may involve regulatory and congestion considerations that would need addressing.
Appropriate airtime limits, activation thresholds and gradual stand down should help minimise the impact on existing networks, although this would need to be tested under realistic traffic conditions.
Final thoughts
There is the obvious downside of higher airtime usage where adaptive repeaters activate but in the areas where it would likely activate I don't think airtime is an issue as currently Meshcore simply doesn't form effective meshes for this to disrupt. With proper logic and gating I don't believe it would cause significant issues as in areas where this could potentially be an issue eg where there are a high number of users there are robust repeater networks in place.
It would however assist in remote, rural and low infrastructure areas, and add much more resilience by allowing the network to bridge communications via companions when repeaters fail or users are out of range.
In addition there are obvious questions to address sure as timeouts and deactivations if Companions disappear or move on and out of range, as well as other generalisations and simplifications I have made both for ease and unintentionally.
Obviously subject to terms and conditions testing and the will of the gods...Discuss...
All reactions