Thread protocol - one to many communication

Question

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 · Accepted Answer

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 ...

Jørgen Holmefjord · Answer

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

Jørgen Holmefjord · Answer

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".

Thread protocol - one to many communication

Top Replies