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

[Arif@Lynxemi]

Hi,

I am interested in making an application with BLE Mesh that consists of a few Friend nodes and up to a thousand LPN nodes. I know from this ticket that the SDK for Mesh is limited by memory, timing and the size of the core_tx_bearer_bitmap_t structure in that SDK. I noticed that in the Zephyr SDK, the KConfig file for LPN count has up to a thousand as shown here:

config BT_MESH_FRIEND_LPN_COUNT
    int "Number of supported LPN nodes"
    range 1 1000
    default 2
    depends on BT_MESH_FRIEND && BT_MESH && BT
    help
      Number of Low Power Nodes the Friend can have a Friendship
      with simultaneously.

Has anyone at Nordic evaluated this theoretical maximum or are we still bound by the same limitations as the old SDK?

[Hieu]

Hi Arif@Lynxemi, 

The limit will still be lower due to RAM constraint. Another possibly limiting factor is the chance that LPN polls colliding and causing friendship termination increases as more LPN are registered.

Nordic has not tested this maximum of 1000, at least as of the time of writing.

I haven't been able to find a limit on the number of friendships in the Bluetooth Mesh spec. All that I found is that the range [1, 1000] was added in a commit 5 years ago with the git commit message "Bluetooth: Mesh: Add initial implementation." Thus, my guess is that 1000 is an arbitrarily large number that the author chose then, not an actual theoretical maximum.

This code lies in the part NCS inherits from Zephyr, so if you wish to know the reason behind this maximum, perhaps you would get better information in the Zephyr forums.

Hieu

[Arif@Lynxemi]

Thanks Hieu, I'll cross-check with the Zephyr forums.

Arif

[Arif@Lynxemi]

Hi Hieu,

I've posted on the Zephyr forums and contacted the Intel engineer who made the commit. However, its been days and I've yet to receive a reply on those fronts.

I have now tried compiling the Mesh light example using NCS and ran into a RAM limitation. On build, SRAM overflowed by 1012770 bytes on an nRF52840. That means that 1000 LPNs require 1.3MB of memory. The nRF52840 could support at least 150 LPNs and successfully builds at that number.

Memory reports indicate that _net_buf_friend_buf_pool and net_buf_data_friend_buf_pool take up the majority of memory as expected.

Question: Is it possible to add RAM to a nRF5340 or 52840 via QSPI to allow this to happen? I would have to manually set the address for these two buffers to a specific address to read and write from QSPI.

[Hieu]

Hi Arif,

Currently, SRAM over QSPI is not officially supported at all.

If it is not confidential, could you share the use case with which you require such a large number of LPN?
Also, does one Friend Node need to support all of the LPN in your mesh, or can there be another Friend Node to help?

These configurations also affect how much space a friendship take on RAM. Can you take a look at them and see if they can improve the number of LPNs supported?

CONFIG_BT_MESH_FRIEND_QUEUE_SIZE
CONFIG_BT_MESH_FRIEND_SEG_RX
CONFIG_BT_MESH_FRIEND_SUB_LIST_SIZE

Hieu

[Arif@Lynxemi]

Hi,

Hieu said:

Currently, SRAM over QSPI is not officially supported at all.

That's unfortunate that its unofficially supported but we might try with a QSPI chip.

Hieu said:

If it is not confidential, could you share the use case with which you require such a large number of LPN?

Our use case is for updating a large number of price tags in a supermarket. Numbers of these are close to 6000. The customer wants to keep Friend devices to a minimum but there will be a mesh of around 20-30 Friend nodes, depending on the store. The reason for that is because there are only a few power sockets in any given store and extra cabling is out of the question. There will be one gateway in the entire store that will be connected to Internet that receives regional price updates and disseminates targeted message packets to the tags through the mesh. We expect price updates for a specific tag to be rare but price updates will flood the network all at once due to how they are decided.

As per the use case above, there will be a mesh of Friend nodes in the store but there will likely be loaded with LPNs they have to manage as well. We are debating whether we should put several nRF5340s on one board to address the lack of Friend nodes. We will weigh the cost/benefit of this versus the QSPI-SRAM path.

I will try meddling with those configurations tomorrow and get back to you ASAP.

FYI, we considered regular BLE but we would have to design a custom mesh of our own or make all "Friend Nodes" internet-connected gateways at big cost. The price tags would have been Peripherals that go to sleep and only advertise once or twice a day while the nodes would be Centrals that do a targeted scan and update the tag over GATT. However, it was complicated because all the Centrals had to store the price tag information and then update each other when one of them manages to do an update. I figured BLE Mesh would do a better job at storing message packets as per my prior experience with LPN Sensors.

I'm interested to know Nordic's recommendations for such a use case using their SDK.

[Arif@Lynxemi]

Hieu said:

CONFIG_BT_MESH_FRIEND_QUEUE_SIZE

I set this to a minimum value and was successfully able to build for 1000 LPNs. Had a significant impact on RAM usage.

Hieu said:

CONFIG_BT_MESH_FRIEND_SEG_RX

This value was already at its default minimum.

Hieu said:

CONFIG_BT_MESH_FRIEND_SUB_LIST_SIZE

This reduced RAM consumption somewhat. If the nRF5340's RAM was 96% utilized at 1000 LPNs, then setting this to its minimum value of 1 reduced it to 94%.

Thank you very much for the suggestions. The reduced queue size might impact the use case but I imagine its workable by scheduling the update messages on the gateway side.

[Hieu]

Hi Arif,

Sorry for the late follow up.

Yours is a very interesting use case. I have several concerns, whether you choose to use Bluetooth Mesh or BLE in your project. I had wanted to discuss this with more people here, but my schedule has not allowed it. So below I will share some concerns and feedback I have for the description you have given:

In the Bluetooth Mesh option,

• How would you schedule the update?
  • To avoid all LPNs wake up at around the same time and their messages collide
  • To minimize the latency between when new prices are available and when the tags wake up
• Have you taken into account other features such as storage of the price data and DFU yet? 

In the BLE option,

• How would you ensure security?
  • Manual bonding for such many devices is going to be very cumbersome.
  • How can automatic bonding be designed?
  • Bonding via NFC is possible, and simplify the manual process a lot, but introduce cost.
  • How would the supermarket employees know which Server is bonded to which tag?
  • An alternative would be to use a custom encryption scheme for message data, but otherwise all peripherals are open to be connected to by any centrals.
• How would you schedule the update for the tags?
  • Each nRF device can only support 20 concurrent connections.
  • Latency can also be a concern, same as above.
• I don't think you necessarily need to create your own "mesh."
  Considering the open network with communication encrypted using your own secret key, the price tags can take turns connect to the price server device and get their update.

I am not sure thoughts such as above are what you are looking for. I hope they are helpful somewhat.

As you continue to realize your product, please feel free to raise any technical questions here. When your design becomes more specific and confidentiality concerns arise, please remember you can always open a private ticket. 

Hieu