Mesh DFU relaying stop condition

[Thomas-Brilliant]

I've been playing with Mesh DFU and I was wondering about the relay feature. When does a device know it's time to stop relaying a Mesh DFU packet? How does Mesh DFU prevent the same packet from bouncing around a network indefinitely?

[Edvin]

Hello,

The mesh relay is controlled by the TTL counter and the packet ID, the same way as other mesh packets are. This mechanism prevents messages from bouncing around forever.

First, there is a define in nrf_mesh_config_core.h called CORE_TX_REPEAT_RELAY_DEFAULT. This is the number of times that any mesh message is relayed when received once. 

Similairly there is a define called CORE_TX_REPEAT_ORIGINATOR_DEFAULT, which is how many times each message is sent from the originator node.

In addition, each packet has a TTL (time to live). When a node picks up a message and relay it, it will decrement TTL by 1. If TTL reaches 0, the message is no longer relayed. 

Next, the mesh packets are marked with a message ID. Let us say you have 3 nodes, A, B and C.

If A sends a message, both B and C will pick it up. Then B will relay the message (after a random delay), and node C picks up that packet as well. Node C will see that this is the same packet that is already received from A (by comparing the message ID), so it will discard the packet sent from C, and relay the packet originating from A n times after decrementing the TTL.

n = CORE_TX_REPEAT_RELAY_DEFAULT.

Hope that clears things up.

Best regards,

Edvin

[Thomas-Brilliant]

Hey Edvin,

Sorry, I don't think I was very clear in my initial post. I was actually asking about the mesh-DFU packets. According to the documentation, those packets are transmitted as normal BLE Advertising packets. When they're sent out, other DFU-enabled devices can rebroadcast them. I was looking at the mesh-DFU packet fields but I didn't notice any flag or field that served as a TTL of some sort. Am I overlooking something?

Thanks,

-Thomas

[Edvin]

Hello Thomas,

Sorry. You are correct. They don't actually use TTL. According to the guy who wrote our implementation, they have a slightly more timing based optimization algorithm based on the Trickle-specification from IETF, and it uses large message chaches instead of TTL. 

The challenge in restricting when to send these packets is that these packets are not inside your mesh network. Imagine if you have a network with different types of nodes, perhaps from different vendors. You would still want your network to be able to transmit dfu packets even though they are different devices, right? So even if the image is not for that specific node, you may still want to forward it. So if you don't know whether the packets are intended for any other nodes in the network, it is "safer" to push them onward.

One way to work around this if you want total control is to send the packets in a custom model in your mesh network instead of "outside" it. However, that would require a bit of work to set up, and even if you did, if some of the nodes in the network isn't using this implementation, you would still want to relay the DFU messages intended for other nodes.

If you want a "quick fix" this could be done by changing the fw_updated_event_is_for_me() function in main.c in the dfu example. This is the function that checks the application ID, version and company ID.

Best regards,

Edvin