IOT - BLE 5 Mesh scale Challenges

[Cameron]

I'm working with a customer on an IOT device that utilize a mesh network for: inter-device communications, configuration and reporting.  We're at the network design stage and can foresee some challenges ahead and wanted to know if anyone has solved the network scale challenges and how.

Functional Requirements

• No gateway for basic installation
• Devices will be enrolled with a thrid party device (eg phone, tablet, computer)
• IoT device senses multiple environmental variables and performs a switching function
• IoT device can act as a group/zone (when configured) ie one device triggers a behavior in the group (needs to be reliable).
• IoT device records data and can be retrieved later for analysis.
• IoT device has a schedule for behavior

Non functional requirements:

• Up to 8 meters between devices
• Typical install size 100 IoT devices
• Max install size 1000 IoT devices
• Firmware up to 2MB

Challenges that we're foreseeing:

1. Size of the mesh - up to 1000 devices
   1. Modelling show that with BLE 5 we can go quite high but perhaps not 1000.
   2. Priority messages (eg acting as a zone) get exponentially slower with the size of the network.
   3. We've not been able to find practical examples of a scale of 400+ devices
   4. Is there a way to segment/separate the network.
2. Performance of the mesh
   1. Getting a message from one edge to another will be slow.
   2. The performance impact of getting an ACK from the far edge of the network will be high.
   3. Prioritizing network traffic for certain events
3. Keeping clocks in sync - I would have thought this would be built into BLE 5 and was surprised it's not.  Is CheepSync the solution or is there another?

I was wondering if anyone has some case studies they can share or know if anyone who has tackled some of the above problems and understands the limits of the network.

Presumably something like wirepass would solve the problem if it ran on BLE 5.

[renald.gallis@thinxtra.com]

What about using LPWAN technology such as Sigfox?

You don't need to create a mesh network anymore (expensive to do, always some gateways that needs to be fixed, and pairing configuration & issues). With Sigfox, assume the network is already here (you can check current coverage at thinxtra.com/coverage), the device connects directly (no pairing) via Sigfox to your cloud.

Happy to discuss further at renald.gallis@thinxtra.com

[Heath Raftery]

Fascinating project. You're really at the bleeding edge of Bluetooth so it would be beneficial to work directly with some techs from the Bluetooth SIG - I'm sure they would be very interested in having your project be a case study. BT Mesh is only 6 months old or so, so there wont be too many people doing what you're doing.

Sounds like you've considered most of the parameters. A couple more:

• It's going to get really noisy where device density is high. Consider a scheme that disables relaying for nodes that have a lot of neighbours - if you keep the relaying nodes down so you have just enough mesh paths, you'll avoid it turning into a shouting match where no one gets heard.
• All relaying nodes need to listen all the time - your relaying nodes wont last long on battery. Make sure you have a continuous power source available for them.
• The network can be segmented into "groups". But it's really just a logical layer - every node still participates in the mesh (see the dot point about limiting the number of relaying nodes), but some also take action if they're within the "group".

There's probably not many BT Mesh projects of similar scale to refer to. You could consider widening your search to include Zigbee case studies - mesh has been run and done and cursed and succeeded with Zigbee for a lot longer. Generally the need to continuously power the relaying nodes kills most use cases for mesh, but there'll be some exceptions out there.

Otherwise you'd really benefit from seeking out some Bluetooth experts, rather than general IoT experts. Start with the SIG and see who you can find from there.