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.

[Jørgen Holmefjord]

Amadeus said:

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.

There is no need for synchronization in the application, this is handled by the stack during child to parent attachment. The parent/router will have the radio in RX mode, whenever it does not transmit, being ready to receive packets from the child nodes and/or other routers. The child node will use the indirect transmission method to check for incoming data from the parent at the set poll interval. If the ack from the parent indicates no pending data, the SED node can go back to sleep. The parent needs to store incoming packets for all its associated children. For more details, I would recommend you to read chapter 4.7 in Thread 1.1.1 specifications about "Network Attaching".

[Amadeus]

Thank you for your answer, that is good news.

However, let's say the network has 30-50 End Devices which are regularly polling a parent for information (each minute). Would it be advantageous to configure the End Devices such that the are polling at different time intervals? If so. how can this be achieved without any synchronization?

Update: Could any network congestion occur with 30-50 End Devices polling from a Router that often - at the same time? Whenever new data is present, I reckon the package size would be around 30-50 bytes.

Furthermore, approximately for how long does the End Device need to activate its radio for polling data each time when:

- There are no new data
- There are new data of maybe around 30-50 bytes

I need to make an estimate of power consumption.

Also, about the Border Router, our plan is to use a Thingy91-like device for connecting to LPWAN protocols. Thus, a device which integrates both nRF9160 and nRF5240. This device will receive som data over LPWAN; transfer it to the nRF52840 (Router) and distribute it further to polling End Devices. Are there some caveats about this set up we are not thinking about? Do we even need to think about the Border Router role in this setup? To me, it sounds like we have created an alternative Border Router by using a Thingy91-like device.

Update: I forgot to ask, on https://openthread.io/guides/thread-primer/node-roles-and-types, the Border Router is not connected to any End Devices. I reckon End Devices easily could be connected to a Border Router?

[Amadeus]

Also, if we have e.g. two Routers communicating with a set of End Devices (half of them, in that case), what happens if one of the Routers malfunction? Could the End Devices communicating with that Router automatically connect to the operating Router and continue its operation?