Thread protocol - one to many communication

[Amadeus]

Hello,

We are considering using the Thread protocol for in an application where we have one or more central devices distributing data to several peripheral devices. However, it is important that the peripheral devices are saving power in between receiving messages. Therefore, we need to synchronize the peripheral devices and the central device(s) in order to preserve the maximum amount of power. Thus, strategies such as mesh routing would not work since the peripheral devices won't necessarily be awake at the same time. Therefore, we need to use the Thread protocol in a one-to-many messaging strategy, perhaps utilizing a second central device for relaying messages to the peripheral devices.

Is this possible to achieve with Thread, or are there som other protocol more suitable for our application?

[awneil]

But Thread is a mesh system!

"Thread is a low-power wireless mesh networking protocol"
https://www.threadgroup.org/what-Is-thread

Amadeus said:

are there som other protocol more suitable for our application

Anything that isn't  mesh!

On Nordic 2.4GHz devices:

• Straight BLE
• Nordic's Proprietary protocols
• Your own proprietary protocol
• IEEE 802.15.4 can be used in non-mesh systems
• ANT

and, of course, other bands & chipmakers are available ...

[Amadeus]

Thank you for your reply.

Indeed it is a mesh system, but as far as I can see, it does not mean that it is completely infeasible for our application.

According to this https://openthread.io/guides/thread-primer/node-roles-and-types, by configuring our central device(s) as parents/routers and our peripheral devices as children/end devices, it looks to me that we can achieve what we want. That is, it seems to me that the mesh is formed between the routers and each router have a one-to-many communication strategy with the end devices. Maybe I am mistaken, therefore I wanted to ask to be perfectly sure. 

[awneil]

But why would you choose a protocol which is specifically designed as a mesh when you specifically don't want a mesh?!

[Amadeus]

Good question. 

We have used BLE before and now we want to learn more about Thread. And, in addition, since we may need to add additional central devices both for redundancy and to reach peripheral devices located some distance away from the central device, it seems to me that Thread is an OK choice since we can use these redundant devices to relay messages to the distant children according to the above topology. 

My first concern was that Thread utilized any device in the Thread network for relaying messages, which. as I can understand, won't work for our application since our peripheral devices should be asleep as much as possible. Our central devices do not need power saving, so there is no concern there. Therefore, using these as routers in our network looks to me like a feasible solution.

Of course, if the wanted functionality is hard to achieve with Thread, we will change to a more suitable protocol.

[Jørgen Holmefjord]

Hi,

Amadeus said:

My first concern was that Thread utilized any device in the Thread network for relaying messages

The Thread specifications allow a maximum of 32 active routers in the network at any time. Other nodes can be Router Eligible End Devices (REED), or (Sleepy) End Devices ((S)ED) that does not support routing. This is configurable in the stack/application. The parent-polling interval is also configurable in the application, giving you full control over the sleep-period of the SED nodes.

Amadeus said:

And, in addition, since we may need to add additional central devices both for redundancy and to reach peripheral devices located some distance away from the central device, it seems to me that Thread is an OK choice since we can use these redundant devices to relay messages to the distant children according to the above topology. 

If you require this, Thread may be a good choice for your application. However, you need to make sure to balance the data throughput in the network based on the available routers. How many nodes will a typical network consist of?

Best regards,
Jørgen

[Amadeus]

Thank you for your answer.

A typical network will consist of about 30-50 nodes. Two (or perhaps three) of these will be connected to a constant power source and do not require any power saving. Thus, I reckon we could use those as routers. The other nodes may use battery power and should, in that case, save as much power as possible. All of these nodes are scattered around an area of maybe 25 * 3 m2 - with some thin walls and stuff in between.

I am curious about the parent-polling you mentioned. For the record, our end devices are not going to send data to the parents; they are going to receive data from the parents, and, depending on the received data, e.g. signal something. Since we are planning to make the end devices sleep as much as possible, my initial thought was that this could be a problem, since we need to synchronize (using a RTC, which drifts?) the end devices with the parents. Could you elaborate more around this parent-polling scheme (or in this case, parent-pushing) and how to synchronize these devices? And if there are some caveats about this set up we are not thinking about, I would be glad to hear about them.