Mix of Stationary and Mobile Devices Doable?

[patricklazik]

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?

[jwhui]

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.

Thanks for reaching out and sharing your project with us! I'm glad to hear you're considering Thread!

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?

Thread is intentionally flexible when and how often a sleepy end device will search for a more suitable parent.

A sleepy can proactively search for a more suitable parent. OpenThread implements a Periodic Parent Search feature which allows a sleepy to periodically look for a more suitable parent. With Thread, searching for a parent involves multicasting an MLE Parent Request message and listening for unicast MLE Parent Responses. The listening period for responses is 750 milliseconds and the radio receiver is on during that duration. As a result, searching for a more suitable parent can be expensive in terms of energy.

A sleepy can also reactively search for a more suitable parent. When a sleepy attempts to send a message to its current parent but does not receive an acknowledgment, the sleepy can then start searching for a parent.

The best solution will largely depends on your application requirements and goals.

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?

Thread does perform time synchronization to support synchronized sleepy devices (using Coordinated Sampled Listening). The time precision is in microseconds, but the accuracy will largely depends on the device capabilities (crystal accuracy, message timestamp accuracy, etc). However, synchronized sleepies only maintain relative time sync - phase and period of the sleepy's receiver wake schedule. I'm not sure if that would meet your application needs.

At the same time, Thread is intended to be application agnostic. Synchronized sleepies only synchronize with their parent. If you wanted to piggyback on that time synchronization in some way, the you necessarily assume that your application is running on both the parent and child.

Hope that helps.