Networking Protocol for Mix of Stationary and Mobile Nodes, Thread?

[plazik]

I'm developing an Ultra-Wide-Band indoor localization system consisting of beacons (stationary, hard powered) and tags (mobile, battery powered), and am looking for a suitable networking protocol to connect them all together. The system should be scalable to up to 100 beacons and several 100 tags spread out over several 10000m2. Looking at the available networking protocols that may be able to handle this scale (Zigbee, BLE mesh, Thread), it looks like Thread would be the most suitable one since it dynamically adjusts its network topology. I see two potential problems though that I hope someone on here can clarify:

1. One concern is that the network topology updates may take too long in order to maintain a continuous link between tags that are moving throughout the system and the stationary beacons. Generally it can be expected that a tag (sleepy or synchronized sleepy end device) is in transmission range of at least 4 beacons (routers) at all times, but will have to switch which router it sends data through as it moves. How often does Thread check and potentially update the router assigned to a sleepy (or synchronized sleepy) end device? Is it possible to adjust how often this happens?

2. Thread features a time sync feature which would be very beneficial to my system if it is sufficiently accurate (<1ms). What kind of time sync accuracy can I expect for routers and sleepy end devices?

Thank you for helping!

[Jørgen Holmefjord]

Hi,

How often does Thread check and potentially update the router assigned to a sleepy (or synchronized sleepy) end device? Is it possible to adjust how often this happens?

Thread would usually not be an ideal protocol to use for non-stationary devices, due to the reasons you describe. End devices require a parent router, and you need to wait for the child timeout (configurable) before the child is removed from the parent. The parent will continue caching messages for a sleepy end device until the child node is removed. The paths are also proactively updated in a Thread network, so the routers will maintain router tables to know where to send packets at all time, without having to do a router request for each transfer.

Will your end devices do both TX and RX of packets? Doing TX first may be easier to implement, as you can send responses in return, but if your devices will receive packets first, you may get much unnecessary transfers and packets ending up on the wrong path for the moving devices.

2. Thread features a time sync feature which would be very beneficial to my system if it is sufficiently accurate (<1ms). What kind of time sync accuracy can I expect for routers and sleepy end devices?

I assume you are referring to the Network Time Synchronization feature? I do not have any experience with this, but you may find some more information in this thread. The source code of this feature can be found in this file. I assume that the accuracy of the time will depend on the network topology (number of transfer hops, etc) and traffic (retransmits, lost packets, etc), and configuration (sleepy end device parent poll period, etc). The easiest would probably be to enable the feature in your application and see if the numbers will suit your needs. However, I'm not sure if < 1ms is plausible in a larger network.

Best regards,
Jørgen