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 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

[Arif@Lynxemi]

Hi Hieu,

Thank you for your detailed queries. Happy to answer them.

Hieu said:

How would you schedule the update?

I plan to send them one at a time, waiting for an acknowledgement before sending the next in the queue.

Hieu said:

• 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

I intend to use a long enough PollTimeout and ReceiveWindow interval such that the chances of collisions are low. I expect PollTimeout to be in the order of a few hours or more.

Latency will be an issue yes, but I'm betting that it would still be much faster compared to manual tag replacements.

Hieu said:

Have you taken into account other features such as storage of the price data and DFU yet? 

Yes, the price data isn't a floating point value, a single 32 bit unsigned integer suffices. It should fit well inside one transport PDU. The latest price data will then be stored in flash on the receiving tag. DFU on LPN devices follows the same procedure as regular BLE, we use a secure bootloader with buttonless DFU with the option to set it to DFU mode manually if we bridge some pins.

Hieu said:

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.

Before BLE Mesh was sufficiently mature, we had a system using simple single passkey authentication with LESC for low security "meshed" devices such as environment sensors. There is not much that a bad actor could do by cracking the passkey and uploading their own firmware via DFU besides flooding the Central device with data that would be sanitized anyway. An alternative would be to display a random passkey on the price tag on bonding, but that is cumbersome for so many devices.

The shop employees' will not have any knowledge of bonding information. Their backend would only display the unique IDs of their price tags along with a modifiable price field. At any rate, the bonding information is only temporary, the bonding would have been cut after a data transaction has taken place successfully.

Hieu said:

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.

We would set them to do low power advertising by default while the Central device (gateway or nodes) scans only for tags that it has data for. In this case, the messages would also store the advertising name/ID of the targeted device. Connections would only be temporary, one at a time, and only to transfer data. The latency would be better than BLE Mesh, as its only dependent on the speed at which the Central can filter through the scan data. We had decent latency results with our old projects using this topology.

Hieu said:

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.

The main issue is that due to the size or construction of some stores, many tags could be out of radio range of the Server device. Poor RSSI connections could also have an impact on battery life. The expensive Server devices would be better supplemented by "Relays" that extend the radio range.

BLE ESL 

I saw my email yesterday that BLE SIG are releasing a new standard for Electronic Shelf Labels (ESL). I think this is extremely promising for my project. Obviously BLE 5.4 is not available yet on the nRF SDK or softdevices. I have a feeling that it may take a while for Nordic to adopt this specification so we may have to proceed with our main idea for now. Do you know if Nordic has any plans for this soon?

Regards,

Arif

[Hieu]

Hi Arif,

It seems that you have given a lot of thoughts and considerations into your solution. My concerns seem unfound. Thank you for sharing your idea with me.

Impeccable timing with your question regarding BLE ESL. We just announced it today 
https://www.linkedin.com/posts/nordic-semiconductor_bluetooth-bluetoothlowenergy-bluetoothle-activity-7029412996565118976-SvCG
(I didn't even know about it until you asked, which prompted me to ask about it internally)

Best regards,

Hieu