Silicon Labs has successfully deployed a 200-node Matter-over-Thread validation network to demonstrate the scalability of commercial IoT hardware.
The chipmaker revealed this real-world deployment at the Connectivity Standards Alliance (CSA) first-ever Unify event. The test results offer concrete proof that the Matter standard can handle large-scale environments like commercial buildings, factories, and apartment complexes. The industry is now moving beyond basic compatibility testing and focusing on real-world validation at genuine enterprise scale.
Daniel Cooley, CTO of Silicon Labs, commented: “Matter is quickly growing from a smart home solution into a platform ready for much larger deployments.
“This project shows not just that Matter-over-Thread can theoretically support thousands of devices, but also how Silicon Labs is enabling customers to deploy, manage, and future-proof these networks through advances in Matter, Thread, and Concurrent Multiprotocol technologies.”
Real-world setup design
Engineers built the validation network within the Silicon Labs Boston Connectivity Lab and adjacent office areas to assess performance in everyday conditions. Rather than using a controlled lab setup, the team spread hardware throughout a space filled with interference from active office equipment, including twelve Wi-Fi networks, Bluetooth devices, and regular corporate Thread traffic.
The layout included 40 separate connectivity clusters across the facility floor. Each cluster held six ‘Wireless Starter Kits’ with a dedicated radio board, forming a dense mesh network with a maximum span of roughly 50 metres between the most distant nodes. Every device was set up as a Full Thread Device.
While typical commercial installations combine edge devices with routers, the team configured every node as a router. This design intentionally put extra strain on the system to handle heavy background traffic from routine network maintenance tasks.
The hardware was based on BRD4187C development boards with EFR32MG24 wireless system-on-chips. The software ran on FreeRTOS, using thirteen separate operating system threads to manage simultaneous operations, message handling, and security processes.
Silicon Labs’ Bluetooth stack stayed enabled on the chips during testing but did not handle active data. A 4GB Raspberry Pi running Ubuntu 22.01.2 LTS and an OpenThread Border Router served as the central controller.
Overcoming technical challenges
Setting up a 200-node network in a live office environment uncovered several technical issues that needed engineering fixes.
The original plan used Bluetooth Low Energy to commission devices onto the network. However, testing showed clear limits in Bluetooth Low Energy’s range and capacity when handling large-scale automated setup. The short signal range often caused automated scripts to fail before completing fabric credentials for all nodes.
To work around these limitations, the team switched to an on-network commissioning approach. With this method, devices first join the Thread mesh using a network dataset sent through the OpenThread Border Router command-line interface.
After joining the mesh, each node registered a Service Registration Protocol instance. The system then sent an on-network commissioning command, finishing fabric registration securely over the existing Thread network without needing close-range Bluetooth connections. This revised method achieved a 100% commissioning success rate across repeated tests, averaging seven seconds per node.
A second challenge involved data collection and latency measurement. Early testing used standard command-line outputs and software logging to track message delivery times.
The team found that the processing time needed to create text logs through the software stack added roughly 50% to application-layer latency. This overhead skewed the performance results, making them unreliable for measuring real user experience, such as the delay between flipping a switch and lights responding.
Engineers fixed this by turning off all software-level Matter logging and instead routing data through the physical ‘Packet Trace Interface’. This hardware-level debugging tool captures live radio frequency traffic and internal debug events directly from the wireless chip via dedicated GPIO pins.
By pulling timing data through a physical backchannel to a host computer, the team measured application-layer events with microsecond precision, completely removing software logging overhead from the final results.
Measured performance results
The tests focused on multicast messaging, unicast communication, and long-term network stability under real deployment conditions.
Data from the 50, 100, and 150-node tests showed a very stable latency pattern. Across these sizes, average application-layer latency held steady at about 91 milliseconds, with 95% of commands completing within 110 milliseconds regardless of payload size.
Performance shifted noticeably when scaling to the full 200-node network. Average latency rose to 116.51 ms for 8-byte payloads, 125.45 ms for 16-byte, 124.11 ms for 32-byte, and 129.76 ms for 64-byte payloads. More significantly, 95th percentile latency jumped sharply: 320 ms for 8 bytes, 350 ms for 16 bytes, 330 ms for 32 bytes, and 340 ms for 64 bytes.
Analysis of the data pointed to a clear physical cause for this difference rather than a protocol flaw. Automated scripts activated devices in order of network address. The last 50 nodes needed to grow from 150 to 200 devices were located in a corner hallway area of the Boston office. This section had only a single line of sight to the main floor, creating a major wireless bottleneck at the hallway entrance.
The building layout forced the network to depend on multi-hop forwarding and heavy packet flooding to reach the isolated hallway nodes. Structural concrete columnswithin the office space further blocked direct radio frequency paths, forcing the network to take additional hops to route around perpendicular walls. This localized topological constraint directly caused the latency spike observed at the tail end of the data distribution.
Despite these physical limitations, the network maintained continuous operation, exhibiting less than one percent packet loss for standard payload sizes during a three-hour continuous stress test.
Controlled unicast testing and long-term stability
To isolate the specific incremental latency introduced by multi-hop forwarding from open-air office interference, engineers performed separate unicast testing within a controlled laboratory setting. This assessment utilized Ramsey STE330 isolation boxes conductively connected via shielded coaxial cables to create a fixed, multi-hop topology spanning one to seven hops.
The unicast testing tracked the latency of Certificate Authenticated Session Establishment along with application-layer command round-trip times. Security session setup is an infrequent yet essential computational process required before application messaging can begin.
Laboratory results showed that session setup latency increased linearly with distance, measuring 65 milliseconds for a single hop, 150 milliseconds at three hops, 251 milliseconds at five hops, and reaching a maximum of 352 milliseconds across a seven-hop span.
Application-layer round-trip times followed an equally predictable pattern based on payload size and hop count. A single-hop unicast message averaged 62 milliseconds for an 8-byte payload, increasing to 105 milliseconds for a 296-byte payload.
At four hops, the average round-trip time increased to 204 milliseconds for 8 bytes and 324 milliseconds for 296 bytes. At the maximum distance of seven hops, the hardware recorded average round-trip latencies of 341 milliseconds for minimal 8-byte payloads and 473 milliseconds for maximum 296-byte payloads.
The system experienced zero packet loss across all tested hop counts during these unicast assessments. The steady increase in response times results directly from standard cryptographic decoding overhead, packet parsing within the multithreaded software layer, and transmission fragmentation required by the underlying Thread radio layer.
This data defines clear deployment guidelines, confirming that while Matter-over-Thread naturally accommodates large physical areas without manual routing configurations, localized physical layout choices and structural materials determine final network responsiveness.
See also: Industrial automation drives private 5G past 2,000 deployments
Want to learn more about the IoT from industry leaders? Check out IoT Tech Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including AI & Big Data Expo and the Cyber Security Expo. Click here for more information.
IoT News is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
