The Stakes of Gateway Downtime
In a wireless mesh deployment serving HVAC zone control, the gateway is the bridge between the mesh sensor layer and the building management system. A gateway failure does not immediately darken lights or stop fans — the BMS continues running on its own logic, and Thread end devices continue reporting locally. But the BMS loses real-time occupancy and zone temperature data, setpoint writes from the facility management team stop reaching the mesh, and any MQTT-based alerts from the mesh stop flowing to the operations dashboard. In a hospital system or a data center facility, that data gap creates a compliance and safety exposure that facility managers are not willing to accept.
The practical target for gateway availability in mission-critical deployments is 99.9% — three nines, which allows roughly 8.7 hours of downtime per year. That sounds generous, but achieving it in a hardware system requires thinking through failure modes more carefully than most IoT deployments do. Gateway failure modes include: NIC failure, OS crash, PoE switch failure, power outage, and firmware update gone wrong. No single hardware or software design element covers all of these; redundancy has to be layered.
Pattern 1: Active-Standby Gateway Pairing
Active-standby is the simplest and most broadly applicable redundancy pattern. Two MK-GW gateways are deployed at the same location — same building zone, same VLAN, connected to the same PoE switch (on separate switch ports drawing from separate power feeds if possible). The active gateway handles all mesh traffic: it is the Thread Border Router, the BT Mesh provisioner, and the BACnet/IP device presenting the facility's sensor point list to the BMS. The standby gateway monitors the active gateway's heartbeat over a dedicated management VLAN.
When the standby detects heartbeat loss (default timeout: 10 seconds, configurable down to 3 seconds), it promotes itself to active. Promotion involves: announcing itself as the new Thread Border Router on the Thread network (the Thread mesh reconverges around the new Border Router within 5–30 seconds, depending on mesh size), re-registering its BACnet Device Object on the BACnet/IP network (the BMS resumes polling within 1–2 poll cycles, typically 30–60 seconds), and resuming MQTT publishing to the cloud broker. Total failover time from gateway failure to BMS point restoration: 60–120 seconds in our tested deployments.
The limitation of active-standby is the standby gateway is a dormant resource. It consumes power and occupies rack space but handles no production traffic during normal operation. For facilities where rack space is constrained, this is a real cost. The warm-standby variant — where the standby gateway handles a subset of lower-priority mesh traffic during normal operation and takes full load on failover — is an option, but it complicates the mesh configuration and is generally not worth the complexity unless hardware space is genuinely scarce.
Pattern 2: Mesh-Bridged Dual-Gateway
In larger deployments — a 24-floor office tower, for example, where one gateway would have inadequate RF coverage from a single installation point — the redundancy architecture shifts to mesh-bridged dual-gateway, where two gateways each serve a subset of the building's mesh partition and are also connected to each other over a wired Ethernet backhaul. Both gateways run as Thread Border Routers on separate Thread partitions with a partition merge policy configured so that, if one Border Router fails, its partition's nodes migrate to the surviving Border Router's partition through a Thread partition merge event.
Thread's partition merge protocol (defined in the Thread 1.3 specification) handles the re-convergence automatically: when nodes in the failing partition lose their Border Router, they scan for available Border Routers and negotiate partition merger. Convergence time for a 200-node partition to merge into an adjacent partition is typically 30–120 seconds in our measurements, depending on node density and RF conditions. During the merge window, end devices continue reporting locally and buffer data; the buffered reports are delivered after the Border Router association is restored.
At the BACnet/IP layer, the dual-gateway approach requires that both gateways register different BACnet Device Instances but share the point list between them — each gateway owns a subset of BACnet objects. On failover, the surviving gateway can be configured to take ownership of the failed gateway's objects by temporarily registering additional Device Instance identifiers and presenting the failed gateway's point list. This requires pre-configuration of the failover object ownership table in MeshOS; it is not automatic, but it is a one-time commissioning task per deployment.
Pattern 3: Local-Edge Failover with Persistent State
For deployments where the cloud MQTT broker is the primary data sink — not a local BACnet/IP BMS — the gateway redundancy model shifts to local-edge failover with persistent state. Rather than relying on a second gateway to take over the BACnet presentation layer, this pattern focuses on ensuring that sensor data continues to be logged locally when the primary network path fails (cloud disconnection, upstream router failure, ISP outage), and that the buffered data is delivered intact when connectivity restores.
The MK-GW gateway runs a local SQLite store for time-series sensor data with a configurable buffer depth — default 72 hours of data at 60-second reporting intervals per 500 nodes before the oldest records are overwritten. On connectivity restoration, the gateway publishes buffered records in chronological order to the MQTT broker with retained timestamps. The MQTT broker's persistent session and QoS 1 delivery guarantee ensures no records are dropped during the re-delivery sequence.
This pattern does not replace active-standby for BACnet/IP deployments — if the BMS is the primary consumer of sensor data, local buffering does not fill the data gap visible in the BMS trend logs during the outage. But for cloud-first deployments where the BMS is the secondary consumer (or not present at all), local-edge persistence often reduces the practical impact of gateway downtime to near zero from an analytics perspective.
PoE Redundancy and Power Design
Most MK-GW gateway failures we have responded to in the field have not been software failures — they have been power failures. A PoE switch losing power, a blown PoE fuse, or a building power event that drops a PDU while the UPS charges. The gateway hardware failure rate is very low; the power delivery infrastructure failure rate is notably higher.
For active-standby deployments, connect the active and standby gateways to PoE ports on different PoE budget groups on the same switch, or better, to different physical switches on different PDUs. If both gateways lose power from a single switch failure, the failover design is moot. In a hospital or data center setting, the two PoE switches should be on separate UPS circuits — a constraint worth specifying explicitly in the infrastructure design document, because it is frequently missed during rack planning.
The MK-GW-1000 supports 802.3bt (PoE++) input with a maximum input power of 60W per port (though the gateway itself consumes under 15W at peak load). The headroom allows the gateway to tolerate voltage sag on long cable runs without brownout resets — a real issue in older buildings where the patch panels are in electrical rooms 80+ meters from the IDF closet. At 15W draw over 100m of Cat 5e, voltage drop is typically 3–4V, keeping the delivered voltage above the 802.3af minimum of 44V even under worst-case conditions.
Failover Detection Time: Why the Numbers Matter
MQTT broker session handling is the less-obvious latency contributor to failover time. When an active gateway disconnects, the MQTT broker holds its session for the MQTT Keep-Alive interval — default often 60 seconds. Until the broker marks the session expired, the standby gateway cannot re-establish the same MQTT client ID session without a conflict. For this reason, MeshOS configures the active and standby gateways with distinct MQTT client IDs, both subscribed to the same topics. On standby promotion, the new active gateway simply starts publishing under its own client ID — no session conflict, and the broker's subscriber list does not require updating.
We are not saying 60-second failover is always acceptable. For BACnet/IP deployments where the BMS has strict point staleness alarms set to 45 seconds, a 60-second failover will trigger a stale-data alarm during every failover event. The solution is to tune the BMS point staleness alarm threshold above the maximum expected failover time, or to reduce the gateway heartbeat timeout and standby promotion delay to bring total failover time below 45 seconds. The tuning depends on the BMS platform — some platforms allow per-point staleness thresholds; others apply a global value.
Designing redundancy into a facility mesh deployment is not a feature request for large-budget projects. It is a commissioning-phase decision with hard infrastructure consequences — cable routes, switch ports, PoE budgets, and MQTT broker configuration. The time to design for redundancy is before the first gateway is mounted on the DIN rail, not after the first outage-related trouble ticket arrives.