Exploring OpenThread for Location Inference in a Large Industry 4.0 Warehouse

[gcb]

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)
• Software: All devices are running Thread CLI sample 

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 (left picture), 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 (right picture)

         

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. In the Thread CLI sample, regarding the TX power, does the shell command ot txpower configure only the SoC output power? When using an nRF21540DK or nRF21540EK attached to an nRF52840DK, does this shell command configure only the TX power of the nRF52840 SoC?
4. In the Thread CLI sample from the official open-source OpenThread repository, there is information about the commands ot fem and ot fem lnagain. Initially, I assumed these commands could be used to configure the RX sensitivity of the nRF21540 FEM. However, these commands are not recognized in the Nordic Thread CLI sample.
5. 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:
   1. Cost: It would require 16 Border Routers, dramatically increasing implementation expenses.
   2. Maintenance: Devices are frequently removed and replaced in different areas (periodically each 20-30 days). Managing their network assignments would become labor-intensive.
6. Are there better ways to infer location within OpenThread’s capabilities?

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

Best regards.

[Edvin]

Hello,

Indoor locationing is difficult.

1: No, I don't think you can tweak this. It isn't necessarily the hop count that will be the selected route. The routing table is generated based on signal strength and number of hops. 

2: I would say that the ones in the middle of the room would either way pick a random router, so I am not sure it helps to decrease the TX power. 

3: I don't remember whether it actually adjusts the FEM. It does adjust both the TX power related registers in the nRF53. I would think it also adjusts the FEM.

4: I am not sure whether digging into these RX and TX numbers are really the way to go. It doesn't change the fact that you are not guaranteed to get the closest parent. 

5: 16 different networks will make sure that it is in the correct room, but that requires you to have it connect to the correct network. So if you were thinking that it would make it automagically pick the closest network, then no. You need to speciffy what network it should connect to.

6: In my opinion, openthread may not be the greatest alternative for location tracking. I am tempted to recommend BLE advertising and scanning. Perhaps even Bluetooth Mesh. This way, you only need to know the location of the powered nodes/scanners, and you can also have them scan for particular BLE advertisements. Then they can report back to a gateway node the address of the advertisement packet it picked up, as well as the signal strength. Then you can use some application running on your computer to determine which node it probably is closest to. 

In general, both OpenThread and Zigbee are bad for moving devices. OpenThread has a self-healing mechanism that kicks in if devices disappear, updating the router table, but nodes tend to stick to the parent they are assigned to until they are no longer able to reach them. Then it takes a handful of minutes before they decide that they need to try to connect to the network again, via some other node. Bluetooth Mesh is simpler, because as long as these nodes are just scanning for regular BLE beacons (and you don't use the Bluetooth Mesh's friend node/low power node feature), and they can forward this information to the gateway. (there is no standard gateway, so this would have to be a node that you write the application for, and forward the information to wherever you need it, computer, phone or whatever you need to handle the data. There are low power nodes in OpenThread as well, but they are only almost as good (low power) as a standard BLE advertiser.

These are my initial thoughts. 

Best regards,

Edvin

[gcb]

5: 16 different networks will make sure that it is in the correct room, but that requires you to have it connect to the correct network. So if you were thinking that it would make it automagically pick the closest network, then no. You need to speciffy what network it should connect to.

Do you think it would be feasible for the End Devices to, upon waking up, run a discovery mechanism to identify available OpenThread networks, connect to the one with the highest RSSI, and thereby assume it is the network where the router devices are closest to them?

6. In my opinion, OpenThread may not be the greatest alternative for location tracking. I am tempted to recommend BLE advertising and scanning. Perhaps even Bluetooth Mesh.

I considered Bluetooth Mesh, but unlike OpenThread, where there are numerous articles showcasing high-density networks with hundreds of devices, the situation is different for Bluetooth Mesh. While the theoretical maximum number of BLE Mesh devices is 32,767 (based on the 16-bit unicast address), I could only find articles describing networks with setups of up to 30 devices. But I'll look again at the possibility of Bluetooth Mesh.

In general, both OpenThread and Zigbee are bad for moving devices.

The devices will remain stationary for 20-30 days at a time. In this application, the devices will be attached to boxes placed on pallets. An automated factory robot will arrange the pallets within the warehouse, and the devices will stay in the same location for up to 20-30 days. During this period, the devices will wake up periodically every 5-10 minutes to measure data from several sensors and report it to the backend infrastructure. The warehouse area where the devices are located (e.g., Area 1, 2, 3…16) will also need to be reported. After the 20-30 days, the automated factory robot will move the pallets out of the warehouse, and the devices will be detached from the boxes. These devices will then be reattached to different pallets, potentially placed in a new warehouse area. Therefore, the location of the devices cannot be hardcoded as it will change dynamically. Since the devices will be stationary most of the time, could OpenThread be a potential candidate to solve this problem?

Then it takes a handful of minutes before they decide that they need to try to connect to the network again.

Regarding this situation, I have already changed the default value of the detach parameter from 240 seconds to 60 seconds to ensure it doesn't take too much time. However, even 60 seconds could be critical in ensuring the device can operate within a single battery cycle for up to 30 days.