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,

How many devices will the mesh network consist of, and how large of an area will the devices be spread over? Note that there is a limit of 32 active routers at any time in a Thread network.

Will the information be transmitted from a single node to all other nodes, or information between all nodes as well? How often will messages be transferred, and how large will the payload be? 

Best regards,
Jørgen

[cirlam]

Hi Jorgen,

Thanks for the quick response.

32 active routers would be plenty - I imagine 10 -15 nodes would be the typical max number.

The devices are expected to be mobile, and therefore the distance they are spread over will change periodically - some nodes may go out of range, but then due to the expected use case, they should come back within range when messages are due to be sent. When messages are expected to be sent, the devices are expected to be very close - within 10m of each other.

I've yet to define the payload exactly, but I estimate 20 bytes currently. Messages should flood the network - every node will be interested in any messages sent. It should be possible for all nodes to be capable of sending messages.

[cirlam]

Thanks for the quick response.

32 active routers would be plenty - I imagine 10 -15 nodes would be the typical max number.

The devices are expected to be mobile, and therefore the distance they are spread over will change periodically - some nodes may go out of range, but then due to the expected use case, they should come back within range when messages are due to be sent. When messages are expected to be sent, the devices are expected to be very close - within 10m of each other.

I've yet to define the payload exactly, but I estimate 20 bytes currently. Messages should flood the network - every node will be interested in any messages sent. It should be possible for all nodes to be capable of sending messages.

[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