Mesh network technology selection (Thread vs BLE Mesh vs Zigbee)

[cirlam]

I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:

• The mesh network will be short lived (1-3 hours typically). Each time the mesh network is turned on, it will have a different combination of nodes. This means provisioning the network should be really user friendly.
• All devices will be the same - no bespoke devices to "provision" the network.
• Network setup should be possible without using a phone to provision the network.
• Provisioning the network should be possible over NFC, by touching 2 of the devices together. I'm planning on adding an active NFC IC to every device to allow the possibily of the end device reading NFC tags, as well as acting as a readable tag.
• All devices in the network should be capable of provisioning other devices onto the network.

Some other factors:

• I don't need a connection to the internet with this network.
• All devices will be a small, battery powered embedded device (rechargable is fine - I'm aware of the power implications of mesh networking), with all processing to be done on the Nordic NRF52 device.
• Messages transferred will be small and bespoke - ruling out Zigbee's application layer?
• Messages are to be transferred to all nodes, so flooding is perfectly fine.

BLE Mesh:

• Is it possible to have every node on the network act as a provisioner, and relay node at the same time?
• Is it possible to (assuming I have an active NFC reader IC on the device) provision new devices over NFC?

Thread:

• I've seen the Nordic example of commissioning over NFC with the border router. I'd like to commission devices over NFC, but with the commissioner acting as a plain old Router Node. Is this possible?

I currently believe Thread to be the most approriate for this, as the commissioning process looks more flexible? – but wanted some other opinions to see what the best choice might be? Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!

[Jørgen Holmefjord]

Hi,

I'm sorry for the slow reply. This is a hard question to give a great and definitive answer to. Most likely both Bluetooth Mesh and Thread are viable solutions for your application, but they both have pros and cons.

In Bluetooth Mesh there is only a single provisioner in the network. The specifications allows more provisioners, but it is not specified how this should be implemented. We do provide a proprietary solution, PB remote client/server, that can be used for this purpose. It will allow other nodes in the network to communicate with the provisioner over the mesh network, to provision devices out of range of the provisioner node.

In Thread, the commissioner must either be the first node in the network, or the node must be assigned the commissioner role from the network leader.

There is no need to use a phone to provision the Bluetooth Mesh network, this implementation is just one that were chosen to allow easy configuration of the devices. It should be perfectly fine to transfer provision configuration data over NFC directly between devices, but we do not provide any examples showing this.

I do not see any issues with doing NFC commissioning between end devices in a Thread network either. Most likely the border router solution was chosen for simplicity with connecting and interfacing the NFC poller device. If the router have been assigned the commissioner role from the leader (typically first device in the network), it should be possible to use NFC for commissioning new devices directly in the network.

One thing you should consider is how stationary the network will be. In Thread, the network is routed and self-healing. If a node goes out of range, the network needs to detect this and every router needs to update its router tables accordingly. If the leader is lost, the network will select a new leader. Whenever a device re-enters the range of the network, it will be joined. There might be multiple partitions of the network if devices are spread, leading to multiple partition mergings/leader selections when nodes rejoin the network. In Bluetooth Mesh, this will be simpler. When a node is within range of the network, it can send and receive packets, otherwise it is simply out of range.

Best regards,
Jørgen