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?

[Jørgen Holmefjord]

Amadeus said:

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?

I'm not aware of any ready-made synchronization mechanisms for this, it must be implemented on the application layer if you find it necessary in your network. Thread implements Carrier Sense Multiple Access - Collision Avoidance (CSMA-CD) and uses Clear Channel Assessment (CCA) with energy detection to check for on-air activity before transmitting. If it detects other transmitting devices, it will do a backoff before retrying. 

Amadeus said:

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

See page 6 of this whitepaper from the Thread group.

Amadeus said:

I need to make an estimate of power consumption.

I have previously done some measurements for some similar use-cases on the nRF52840, I have copied the results here as it may be useful for your power estimations:

I recently did some measurements for another customer for a similar use-case with nRF52840 (+8 dBm output power and DCDC regulator enabled, 3.0 V supply voltage). Here are some of the results:

Activity	Average current [µA]	Activity duration [µs]
Sleep/Idle (Full 256 kB RAM retention)	3.5	N/A
Sleep/Idle (96 kB RAM retention)	2.2	N/A
Parent poll interval (0-byte RX data, 0 dBm)	2400	5.85
Parent poll interval (0-byte RX data, +8 dBm)	3800	5.85
Parent poll interval (28-byte RX data, 0 dBm)	4700	10
Parent poll interval (28-byte RX data, +8 dBm)	6700	10
10-byte TX	9100	3.6

The commissioning phase will depend on the commissioner, which in most cases are unknown. I did two tests with the nRF52840 and nRF52833 as commissioner:

• Fast commissioner (nRF52840 with HW crypto-engine) - approximately 6.5 mA average current for ~8 seconds
• Slow commissioner (nRF52833 with SW crypto-engine) - approximately 6.8 mA average current for ~30 seconds

DFU will depend on the image size and parent poll interval. I did two tests for this as well, with a 300 kB image:

• 1000 ms parent poll interval - approximately 150 µA average current for ~4520 seconds
• 100 ms parent poll interval - approximately 940 µA average current for ~721 seconds

Note that all there measurements are taken in a clear environment. High on-air traffic will occasionally cause retransmissions and increased current consumption.

Amadeus said:

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.

If you do not need IPv6 connectivity to the end node, there is nothing preventing you from using another type of gateway than the specified border router solutions. The responsibility of the border router role is to forward packets between the thread network and another network (typically Ethernet/WiFi). It does not normally do packet processing/translations, even though such features can be implemented in a border router as well (one example is the MQTT-SN gateway that we run on our Border Router solution).

Amadeus said:

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?

Yes, the border router is an FTD, which operates in a router/leader role. It can have children attached like any other router.

Amadeus said:

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?

Yes, a Thread network is a self-healing network with no single-points of failure. If one router goes down, the children will try to attach to other routers within range. However, you need to make sure that the other router is capable of attaching that many devices and that the router is within range of all the end nodes.

[Amadeus]

Thank you!

One more thing, the nRF Connect SDK includes some sample projects for building a Thread application, such as Coap Client and Coap Server. Is it possible to merge those two projects into a single Coap Agent without a considerable amount of work, or does it require a lot of changes to the source code?