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?

[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