BLE network design validation - 1000 low-power devices with periodic data transmission

[benna]

Hi there!

We're designing a system with ~1000 battery-powered moveable devices distributed across a large rectangular area (approx 200m x 1000m) . Each device collects approximately 250kB of data daily in one measurement (takes about a minute) and we are looking for a way to transmit this. Power efficiency is critical so devices sleep most of the time. The data isn't time critical. 

We did some digging and anything mesh seems out of the question due to power requirements, LPWAN is too slow (10 hour wait for data is a bit much) and cellular will be too expensive. So we ended up with the following plan:

• nRF54 series with BLE 5.0 Coded PHY for extended range
• Data buffered in external RAM/flash during sleep
• Multiple data connectors (BLE centrals) positioned around the perimeter
• Simple handshake protocol: device sends connection request indicating data size, central responds with availability or backoff time
  • Exponential backoff if no slots available
  • If available: connection and sending of data, followed by disconnect so the slot frees up

The amount of devices which will be sending data does worry me on this scale, so I'm hoping somebody can give some insights.

Questions:

1. Is this a reasonable approach for this scale, or are we missing fundamental limitations?
2. How many concurrent connections can a single nRF54 central realistically handle for this use case?
3. Any recommendations for the handshake/queuing mechanism? I would really like to avoid reinventing the wheel.

For testing network congestion simulation: We'd like to validate the approach before building 1000 devices, any ideas how we could do this? (Any software tools?) 

Any guidance on testing methodology or design validation would be greatly appreciated.

Thanks!

[JONATHAN LL]

Each device collects approximately 250kB

This is a lot of data, how would it be handled on the receiving side? 

1000 times 250kB every day would likely need a lot of traffic to get it all. Is it cantoer over time or is it a snapshot from the sensor that provides such a big sensor data?


You would need at least 1 central per 20 sensor here so that would also be a lot of centrals if you are going that route. 

External flash would be needed, the DK does have so you could start wit a couple of DK's and test how the data traffic would go. 

Regards,
Jonathan

[benna]

Hi JONATHAN LL ,

Thanks for the reply & insights!

Each sensor collects the 250kB in one measurement over a couple of minutes and will need to store it some external memory. After that, its only job that day is transmitting it over to a data collector whenever a connection is available. After transmission, it would disconnect, freeing the slot for another sensor device.

So if I get this right; it would be around 20 sec transmission time at 100kbps per device per day; which makes around 6 hours of receiving for the BLE central if we only have one and put all the sensors on a pile next to it, thats with one connection at the time - giving me the impression that this is theoretical feasible for the transmission part. (In reality we'll need 10+ gateways probably to cover the ground). 

Concerning the receiving side: this bit should act as a BLE gateway, buffering and transmitting the received data to the cloud. With the amount of data, some decent memory will be needed... I'm also looking at off the shelf solutions for this bit - as this feels like classic BLE gateway functionality... 

My big concern is when a 1000 nRF54's start advertising at the same time (we'll try to schedule these so they don't), will we still be able to pick one out and make a BLE connection? Any experience in this area?

[benna]

I found this interesting blog post which puts me on the right track for testing and calculating the probability: https://ruuvi.com/bluetooth-beacon-maximum-density/

This ticket can be closed