Maximum amount of nodes in Thread star topology

[Aleksandr]

Hello,

We are evaluating now a new project and I am struggling to get a feeling about one moment of Thread network and its particular implementation with nRF52840.

In our particular implementation we want to create a Thread star topology network with as maximum (300-400) possible end-nodes connected to one router. Router is a network coordinator/border router in the same time. 

The topology is fixed and created once during installation

One important fact that almost all of the nodes are in deep sleep mode and only maximum of 20-30 of them are active. 

My question is if it possible to create such a network? During a search through this forum I encountered the information that the maximum amount of nodes is limited by the amount of FLASH/ RAM on the router side. Is it true? Considering nRF52840 with 1Mb of Flash is it possible to maintain the information about such a big network? If no, can we extend use external flash to store the data? 

Thank you very much

[Jørgen Holmefjord]

Hi,

The theoretical maximum number of childrens for a single router in Thread is 511 nodes. The maximum number of supported devices will be limited by the RAM, as routers need to store information about nodes, and also buffer messages for sleepy end devices. The minimum required by the spec is 10 nodes.

When you say that the devices will be in deep sleep mode, I assume that they will not be a part of the network in this state? In that case, I think it should be possible for a router to maintain 20-30 nodes, but I have not tested this myself. If you want all 300-400 nodes to be part of the network at all time (sleepy end devices), I do not think this will be possible.

What will be the total network size, i.e., are you planning to have multiple routers with this amount of children?

Best regards,
Jørgen

[Aleksandr]

Hi Jorgen,

Thank you for the reply!

We would like it to be a part of a network all time. The reason behind this is that we need a very short time from wake-up till starting of messages receiving from the router. I expect that when a node sleeps and is excluded from the network it would take larger time to re-establish connection again (like discovery/advertisement delay in BLE). We need a reaction time of 0.5s since a device wakes-up. 

The network will be consisting of one router and 200-300 nodes. We don't want to have a mesh network because all devices will be battery powered. 

But shouldn't it be possible to store the information about the network in the FLASH? I believe it will require additional SW effort? 

Aleksandr   

[Jørgen Holmefjord]

Frequent flash writes/erases will heavily affect the performance of the device, as the CPU/radio is blocked during these operations. The number of flash write/erase cycles are also limited, and this will cause rapid weardown of flash. Modifying this will require large changes to the OpenThread stack, and is not something I can recommend that you do.

Routers need to buffer messages for end devices. The default in our prebuilt OpenThread stack is 32 children and 160 buffers (each 128 bytes large). You can try modifying these numbers, but I'm not sure a single node can service that many nodes.

[Aleksandr]

Hi Jorgen,

Thank you for the reply. I got your point

In case we would use Raspberry Pi (or BeagleBone) as Border Router&Network Leader&Router can we solve this problem? The host then has a lot of DDR RAM.

In case we will follow your the first advice in the first post (to have only active device in the network) how much time will take to get connected the network from the wake-up till get the first message? May be you have some estimations? 

Aleksandr 

[Jørgen Holmefjord]

It would not help to run this on the Raspberry Pi/BeagleBone platforms, as the full OpenThread stack still runs on the NCP and you are limited by the capabilities of the NCP device. For this to be possible, you would need the architecture described in Host/802.15.4 Controller platform documentation. This platform is currently not supported in our SDK.

I did some quick tests with network attachment, by toggling a GPIO in start of main function, and when receiving the CHANGED_ROLE flag. By resetting the board at different intervals, I see varying time ranging from 40 ms to 3 seconds. It seems to take longer if the child have timed out from the network.