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:
- Is there any OpenThread configuration or mechanism to ensure End Devices connect to the nearest Thread Router rather than optimizing for hop count?
- Would increasing network density or reducing TX power help achieve this?
- 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?
- 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.
- 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.
- Are there better ways to infer location within OpenThread’s capabilities?
Any suggestions or feedback on this approach would be greatly appreciated.
Best regards.
