Mesh TTL clarification

RE: Mesh TTL clarification

ftjandra — Fri, 12 Mar 2021 21:08:10 GMT

Thanks for the help.

RE: Mesh TTL clarification

tesc — Fri, 12 Mar 2021 14:52:00 GMT

Hi,

The message cache size is configurable.

In the old nRF5 SDK for Mesh, the setting MSG_CACHE_ENTRY_COUNT in nrf_mesh_config_core.h has a default value of 32.

In the new nRF Connect SDK, the setting is CONFIG_BT_MESH_MSG_CACHE_SIZE, and the default value varies from example to example, but typically 10 or 30.

Regards,
Terje

RE: Mesh TTL clarification

ftjandra — Fri, 12 Mar 2021 00:39:58 GMT

Hi Terje,

How big is the message cache, how many 'past' messages does it store?

Ah, makes sense about the scenario where you don't want a packet to traverse the entire network if you know that the recipient is close by.

Thanks.

RE: Mesh TTL clarification

tesc — Thu, 11 Mar 2021 12:59:40 GMT

Hi,

You are correct that a Bluetooth mesh nodes will only handle packets once. If they receive a packet several times, only the first time will count, and subsequent receptions will get discarded. It does however rely on the original packet still being saved in the (limited) rolling log of received packets.

You are also correct that these packets normally will die out quickly, due to the "only handle once" mechanisms.

For the example of 20 nodes all seeing each other, please note that depending on radio usage there might still be nodes that need to get the message relayed from time to time. But in any case I would not expect any packet to deplete a TTL of 100 in that exact scenario.

Depending on your network topology, you may have a situation where you know that a packet will need to travel very short compared to the full extent of the network. In that situation, it is wise to set TTL low, as the packet will then not propagate to far parts of the network, reducing network congestion in those far-away parts.

From what I understand there may be a small theoretical possibility that a packet moves around in the network - getting relayed several times by the same node - e.g. if network traffic is so high and the network so big that messages can leave the message cache of a node before the (lower TTL) same message reaches the node again. (And thereby the node thinks it is an unseen message.) Therefore it might still be a good idea to set the TTL to a reasonably low setting.

Regards,
Terje