Exploring OpenThread for Location Inference in a Large Industry 4.0 Warehouse

[gc0rreiab]

Context:
I am working on a project to monitor up to 880 devices in an Industry 4.0 warehouse. The warehouse is divided into 16 areas, with each area housing 30–55 devices, which are placed within box pallets. These devices wake up periodically (every 5–10 minutes), acquire sensor data, and transmit it to a backend infrastructure. The aim is to process this data dynamically and adjust warehouse ambient conditions. This picture provides a representative view of the warehouse.

To achieve this, I need to infer the location of the devices, i.e., determine which of the 16 areas the data originates from. However, implementing precise indoor location methods has proven challenging:

• BLE Indoor Location: Using devices as beacons and deploying anchors would require extensive infrastructure due to the warehouse’s large size (110m x 25m x 11m), making it impractical.
• LoRaWAN Gateways: While adding a gateway per area and determining device location based on RSSI values from multiple gateways is a possibility, it would require up to 16 gateways, significantly increasing costs.

Why OpenThread?
After further research and reading the papers below, I am considering OpenThread as a promising alternative. It’s an opportunity to explore and learn more about this protocol, which I have not worked with before.

• IEEE 802.15.4 Thread Mesh Network – Data Transmission in Harsh Environment
• Interference Resilience of Thread: A Practical Performance Evaluation

My Proposed Approach Using OpenThread
The concept is that each end-device will connect to one of the two nearest routers, and the routers will create a network among themselves to ensure messages can reach one of the Border Routers. Whenever an end-device wakes up, it identifies its parent router, retrieves its MAC address, and includes it in the message payload. Each router's MAC address is mapped to a specific area within the warehouse. However this approach relies on End Devices always connecting to the nearest Thread Router. If this condition is met, the parent’s MAC address will reliably indicate the End Device’s location. The network proposed:

• Each area will host 30–55 Sleepy End Devices transmitting sensor data periodically (every 5–10 minutes).
• Each area will have two Thread Routers, adhering to the Thread network's limit of 32 routers.
• Since RLOC IDs (used by Thread devices) can change whenever the network topology changes, I plan to include the parent Thread Router’s MAC address in the data payload.

It's also important to note that, while the diagram is represented in 2D, the warehouse is actually a 3D space. Therefore, end-devices can be positioned at any point (x, y, z) within their designated area.

Initial Tests and Observations
Current Setup:

• Thread Routers:
  • 3x nRF21540DK (with nRF21540 FEM for higher TX power and RX sensitivity)
  • 1x nRF52840 Dongle connected to the nRF Thread Topology Monitor desktop app.
• Thread End Devices:
  • 1x nRF52840DK.
  • 1x nRF52833DK
  • 1x nRF9160DK (utilizing the onboard nRF52840 SoC)

I have started testing in a small setup but observed a significant challenge: End Devices do not always connect to the nearest Thread Router. For example, in the setup below, Node 3 connects to Router B instead of the closer Router C. This behavior aligns with OpenThread’s self-balancing mechanism, which optimizes hop counts and routing efficiency rather than physical proximity, right? The image below illustrates the Thread Topology in my house, showing the placement of Thread Routers and Thread End Devices along with their respective connections. This representation is based on the visualization provided by the nRF Thread Topology Monitor app.

If Node 3 connects to:

• Router B: 3 hops to Node 1 and 2 hops to Node 2.
• Router C: 3 hops to Node 1 and 3 hops to Node 2.

Thus, Router B is preferred even though it is farther away physically.

To address this I will try:

• increase device density per area: more devices might encourage End Devices to connect to the nearest router.
• reducing transmission power on End Devices: could force them to connect to the closest router.

Unfortunately, I need additional development boards to fully test these ideas, as shown in the image below. I am currently waiting to receive more nRF52840DKs and nRF54L15DKs to proceed with testing these concepts.

Questions:

1. Is there any OpenThread configuration or mechanism to ensure End Devices connect to the nearest Thread Router rather than optimizing for hop count?
2. Would increasing network density or reducing TX power help achieve this?
3. Would it be feasible to set up independent OpenThread networks for each area (16 networks in total)? While this approach eliminates the issue of location inference within the same OT network and prevents end-devices from connecting to routers in different areas, it has two major drawbacks for my use case:

• Cost: It would require 16 Border Routers, dramatically increasing implementation expenses.
• Maintenance: Devices are frequently removed and replaced in different areas (periodically each 20-30 days). Managing their network assignments would become labor-intensive.

4. Are there better ways to infer location within OpenThread’s capabilities?
5. Any advice on optimizing OpenThread’s topology for a large-scale, multi-area deployment?

Any suggestions or feedback on this approach would be greatly appreciated.

Best regards.

[jwhui]

1. Is there any OpenThread configuration or mechanism to ensure End Devices connect to the nearest Thread Router rather than optimizing for hop count?

SEDs consider a number of parameters when selecting a parent, but two-way link margin is the top priority:

openthread/src/core/thread/mle.cpp

Line 2949 in 8d39758

bool Mle::IsBetterParent(uint16_t aRloc16,

However, by default, once a SED selects a parent, it will remain attached to that parent until it loses connectivity. You can change this by enabling the Parent Search feature for all devices (including MTDs):

openthread/src/core/config/parent_search.h

Line 88 in 8d39758

#define OPENTHREAD_CONFIG_PARENT_SEARCH_ENABLE OPENTHREAD_FTD

2. Would increasing network density or reducing TX power help achieve this?

I would suggest using the Parent Search feature.

3. Would it be feasible to set up independent OpenThread networks for each area (16 networks in total)? While this approach eliminates the issue of location inference within the same OT network and prevents end-devices from connecting to routers in different areas, it has two major drawbacks for my use case:

• Cost: It would require 16 Border Routers, dramatically increasing implementation expenses.
• Maintenance: Devices are frequently removed and replaced in different areas (periodically each 20-30 days). Managing their network assignments would become labor-intensive.

Yes, it is feasible to do so.

4. Are there better ways to infer location within OpenThread’s capabilities?

Link state information to neighboring devices is probably the best Thread can offer today.

5. Any advice on optimizing OpenThread’s topology for a large-scale, multi-area deployment?

Multiple border routers and potentially multiple Thread networks is useful to increase coverage and capacity.