Two Different Network Architectures
Thread and Bluetooth Mesh are both 2.4 GHz mesh protocols built for low-power wireless devices, and that surface similarity causes facility engineers to treat them as interchangeable. They are not. Thread is an IPv6 mesh network built on IEEE 802.15.4 radio, designed around routable IP packets and the Thread Border Router as an IP gateway. Bluetooth Mesh is a publish-subscribe flooding network built on Bluetooth 5.x advertising channels, designed for proximity-scale group control without IP routing infrastructure. The architectural difference has significant consequences when you are deploying across a multi-floor commercial building.
Thread uses 802.15.4 at the physical layer: 250 kbps data rate, 2 MHz channel bandwidth, DSSS modulation. Its mesh routing is based on the OpenThread stack (the reference implementation) with RPL (Routing Protocol for Low-Power and Lossy Networks) for path selection. Every Thread router node maintains a routing table. The Thread Border Router terminates the 802.15.4 mesh and bridges to the IP backbone — meaning Thread sensor data arrives at the gateway as native IPv6/UDP packets. The MK-GW-1000 runs the OpenThread Border Router stack on its Thread co-processor, giving Thread nodes a routable address reachable from any IP host on the facility network.
Bluetooth Mesh uses Bluetooth 5.x advertising at the physical layer: 1 Mbps or 2 Mbps data rate (vs Thread's 250 kbps), but with a managed-flood publish-subscribe topology rather than source routing. Devices are assigned to groups; a lighting command published to group address 0xC000 reaches every luminaire subscribed to that group address, propagated via relay nodes within range. There is no explicit routing table — the network relies on message TTL decrements and the relay node density to bound propagation depth.
Latency: What the Numbers Actually Mean
Thread, with its routable packet-switched architecture, delivers predictable single-hop latency in the 5–15 ms range for CoAP requests between a Border Router and a Thread end device. Across a 3–4 hop path, expect 30–80 ms end-to-end under normal load. This is deterministic enough for HVAC control loops — a VAV controller receiving an occupancy setpoint update at 50 ms latency is well within the 1–5 second control response time of typical zone damper actuators.
Bluetooth Mesh latency for a published group command is harder to characterize because it depends on relay node density and RF conditions. In a well-planned deployment with adequate relay coverage, expect 100–500 ms for a group command to propagate across 3–4 relay hops. For lighting on/off control, 300 ms is imperceptible. For HVAC setpoint writes that need sub-second confirmation, the lack of acknowledged delivery in publish-subscribe BT Mesh operation is a design concern. BT Mesh does support friendship protocol with acknowledged messages for specific unicast transmissions — but group lighting scenes are generally unacknowledged by design.
We are not saying Bluetooth Mesh is slow — in its intended application domain (lighting group control, not control loops), latency requirements are less stringent. The point is that Thread and Bluetooth Mesh optimize for different latency characteristics, and matching protocol to application is where most deployment mistakes originate.
Node Density and Network Capacity
A single Thread network partition — one Thread Border Router with one active channel — supports up to 511 devices in the Thread 1.3 specification, though practical field deployments above 150–200 nodes per partition start to show routing table pressure on router-class devices. For a dense office floor with 80+ sensors, a single Thread partition is comfortable. For a 24-floor tower with 1,200 sensors, you need multiple Thread partitions, each with its own Border Router instance — all of which can be co-located on one MK-GW gateway running multiple virtual Border Router instances on separate 802.15.4 channels.
Bluetooth Mesh has a different constraint: the 7-bit primary element address space limits a single BT Mesh subnet to 32,767 elements (nodes with multiple elements count multiply). In practice, relay flood management means you want fewer than 150–200 nodes per physical area before splitting to a second subnet with a separate provisioner. On the MK-GW, each BT Mesh subnet gets its own subnet key and provisioner identity, managed from the MeshOS dashboard. A 1,200-node lighting deployment typically splits into 8–10 BT Mesh subnets across the building.
Wi-Fi Coexistence in Dense Environments
Both protocols operate in 2.4 GHz, and coexistence with the building's Wi-Fi infrastructure is a real commissioning concern — particularly in dense office environments with dozens of Wi-Fi 6 access points. Thread's 802.15.4 channels are 2 MHz wide and fit in the gaps between the three non-overlapping Wi-Fi 802.11 channels (1, 6, 11). Thread channels 15, 20, and 25 are commonly used to avoid the Wi-Fi channel 1, 6, and 11 center frequencies respectively — a well-known frequency planning practice codified in the Thread coexistence guidelines.
Bluetooth Mesh uses frequency hopping across 40 BLE advertising channels during connection events, but BT Mesh advertising PDUs use three primary advertising channels (37, 38, 39) that map to 2402, 2426, and 2480 MHz. Those fall in Wi-Fi channels 1, 6, and 11 center band edges. In a high-density Wi-Fi environment, BT Mesh advertising retry rates can increase, slightly degrading throughput. The practical impact is small — BT Mesh is designed for resilience under interference — but it is a factor in environments with 2.4 GHz channel saturation, such as hospital wards with dense medical device Wi-Fi.
When to Run Both in Parallel
The most pragmatic answer for a large commercial building is not Thread or Bluetooth Mesh — it is Thread for sensor reporting and HVAC control, Bluetooth Mesh for lighting group control. The application requirements are genuinely different. Thread's IPv6 native transport makes sensor data easy to forward to the BMS over CoAP or MQTT without protocol translation. BT Mesh's group publish-subscribe model matches how DALI-2 lighting zones are conceptually organized — scenes and groups, not individual addressed devices.
The MK-GW-1000 runs Thread and Bluetooth Mesh simultaneously on separate co-radio chipsets with hardware-level coexistence arbitration (PTA — Packet Traffic Arbitration — between the two 2.4 GHz radios). Commissioning both networks from MeshOS is straightforward: Thread nodes appear in the Thread partition topology view, BT Mesh nodes appear in the BT Mesh subnet provisioner view. The gateway bridges both to the upstream MQTT broker and BACnet/IP stack independently. You do not choose one protocol for the building — you choose the right protocol for each subsystem.
Matter and the Long-Term Protocol Landscape
The Matter smart home standard built on Thread's IPv6 foundation has accelerated Thread silicon adoption significantly — Thread chipsets are now commodity hardware in devices from dozens of manufacturers. This is good news for facility IoT: Thread node hardware costs have dropped, and the supply chain for Thread-capable sensor modules is much healthier in 2025 than it was in 2021. The MK-NODE-TH node uses the same 802.15.4 chipset generation that powers Matter devices, though it runs the OpenThread stack with facility-specific firmware rather than the Matter application layer.
Bluetooth Mesh is also gaining traction through the DALI Alliance's DA-21 standard, which defines how DALI-2 commands map onto BT Mesh model types. This formalization means BT Mesh lighting products from multiple vendors are increasingly interoperable at the protocol level — not just within proprietary ecosystems. For facility engineers specifying a BT Mesh lighting system, vendor interoperability is improving, but commissioning tool compatibility (especially for scene programming and emergency lighting commissioning) still varies by manufacturer.
The decision framework remains what it was: Thread for metered sensor data and control loops requiring IP-native delivery; Bluetooth Mesh for group lighting control and low-latency zone actuation. Buildings that try to run one protocol across both application types will encounter either the limitations of BT Mesh's non-IP architecture for BMS integration, or the limitations of Thread's unicast model for lighting group commands. Run both — and design the gateway to handle both.