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. 

[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?

[Jørgen Holmefjord]

I have not tried that myself, but the code of the two examples does not look too comprehensive. I believe it should be doable within a reasonable amount of time. Most likely you need to remove/merge some handlers and function calls to get everything working, but it seems that the client and server code are separated into modules outside of the main application in both samples.