What are the limits on the number of friendships a friend node can support?

[jkyle]

I saw in this reply that the number of friendships a friend node can handle was limited by available RAM on the friend node. I set MESH_FRIEND_FRIENDSHIP_COUNT to 50 and after building the memory usage window in SES showed I still had 100KB of RAM free. After downloading and running, NRF_MESH_ASSERT on line 219 of core_tx.c was triggered:

    NRF_MESH_ASSERT(m_bearer_count < CORE_TX_BEARER_COUNT_MAX);

core_tx.h had the following comment:

/** Maximum number of concurrent bearers. Limited by the number of bits in the
 * core_tx_bearer_bitmap_t type. */
#define CORE_TX_BEARER_COUNT_MAX 32

It seems like setting MESH_FRIEND_FRIENDSHIP_COUNT to anything over 29 triggers this mesh assert.

Does this mean 29 is the max LPN's a friend node can establish friendship with at one time regardless of available RAM?

Are there any other limitations on the number of friendships a friend node can handle?

Development Setup:

Custom development board using Fanstel BT840F module based on nRF52840

nRF5 SDK 16.0.0

nRF5 SDK for Mesh 4.0.0

SoftDevice 7.0.1 S140: Bluetooth 5

[tesc]

Hi,

From what I can tell your observations are correct. My understanding is that the actual number of bitmap slots available to friendships may depend on other settings for the node (e.g. use of proxy feature), which means you may see a higher/lower maximum depending on what features you enable for the node. I am not aware of other factors limiting the number of friendships.

What number of friendships would you like to support?

I have sent a request to our mesh team asking them for comments. You should expect an update within a few days.

Regards,
Terje

[jkyle]

I don't have a specific number of friendships in mind. Our mesh network consists of a large number (>500) of low power sensor nodes publishing at regular intervals with gateways that subscribe to the sensor group and act as friend nodes. We are currently working out how many gateways will be required. It seems like the main limits for us will be RF coverage and the number of friendships a friend node can support.

[tesc]

Hi,

Reports from the team are that the limitations are the core_tx_bearer_bitmap_t data type and RAM.

FRIEND_RECENT_LPNS_LIST_COUNT, MESH_FRIEND_FRIENDSHIP_COUNT, MESH_FRIEND_QUEUE_SIZE and MESH_FRIEND_SUBLIST_SIZE all have an impact on RAM usage.

In addition there will be practical limitations. Mainly packet collisions (either because of LPNs of the same PollTimeout drifts into the same packet timings, or simply because of congestion), which may lead to friendship termination.

Regarding the core_tx_bearer_bitmap_t, since this is part of the mesh stack any changes may void qualification. My advice is to not do any changes there. Unfortunately we do not seem to have any plans for changing this part of the stack implementation in the near future.

Regards,
Terje

[joao]

Hello,
I have the same problem and I have some questions.

1.a) according to what you said (core_tx_bearer_bitmap_t, since this is part of the mesh stack any changes may void qualification) what would be the impacts of increasing the number of low power devices?
1.b) If it is possible to increase the core_tx_bearer_bitmap_t what parameters do I need to change to increase the number of devices?
I tried increasing the CORE_TX_BEARER_COUNT_MAX setting but when I finish provisioning I get the error (Mesh assert at 0x0003385A) which is probably related to the function:(mesh_gatt_packet_alloc (connection_index (p_connection)). Are there any other parameters that I should take into account?

2A) If option 1 is not really possible, could I start and end the friendship relationship to increase the number of devices?
I am aware that if I do this I will not be able to send data from the friendly node to the low power node, however, that would not be a problem for me because my project does not need simultaneous communications.

[tesc]

Hi,

1.a) The impact from modifying the stack (such as this) is that you cannot use our QDID (qualified design ID) when qualifying your product. From a technical standpoint it is perfectly possible to have more friendships than what our stack currently can handle.

1.b) I am afraid we do not have a full overview over the required changes. Anything handling the core_tx_bearer_bitmap_t datatype in some way would need to be updated. It is not a question of parameters, it is a question of the data type used. If you choose to go down that path, then I am sorry to say you need to figure out the details on your own.

2A) Yes, you can terminate the friendship. Please note however that when terminating a friendship, any messages for the LPN stored on the Friend side gets deleted. This means any such messages will not reach the LPN (even if the Friend node has ACKed them on behalf of the LPN.)

Regards,
Terje