Why Your Intrusion Panel Misses Alarms During Cellular Failover
The line item on the proposal says "cellular backup communicator," and everyone in the room hears the same thing: if the internet goes down, the alarms still get through. That is the marketing promise. The field reality is that the failover window — the minutes between the primary path dying and the cellular path carrying traffic — is exactly where alarms go missing, and most installations have never tested that window even once.
I have pulled event logs on panels that "had cellular backup" for five years and found multi-minute gaps during every ISP outage in the log history. Nobody noticed, because the panel eventually reconnected and the central station saw a healthy account again. The burglary that happens during those minutes is the one the system was sold to catch.
The "Cellular Backup" Marketing Promise
The promise is built on a quiet conflation: having a second radio is not the same as having a second supervised path. A dual-path communicator has an IP interface and an LTE module. Whether an alarm generated during a primary-path failure actually reaches the receiver depends on four things the spec sheet doesn't headline: how the communicator detects the primary path is dead, how long that detection takes, whether events generated during the detection window are queued or dropped, and whether anyone is supervising the cellular path itself so you find out it's dead before you need it.
Each of those four is a place I have personally watched an alarm disappear.
Why Failover Isn't Hot
Failover on most intrusion communicators is detection-based, not simultaneous. The communicator sends its traffic over IP because IP is cheap, and it only swings to cellular after it decides the IP path has failed. Detection is typically a missed poll or a stack-level timeout, and depending on configuration that can take anywhere from about 30 seconds to several minutes. A communicator polling its receiver every 60 seconds with a 3-strike threshold doesn't even suspect a problem for 3 minutes.
Worse, "IP path up" is not "IP path working." The classic field case: the customer's router is powered and the Ethernet link light is on, but the ISP's upstream is down. The communicator sees link, keeps handing packets to a black hole, and the swing to cellular takes the full timeout window. Meanwhile the panel thinks the communicator accepted the event. Whether that event is retried over cellular after the swing depends on the communicator's queuing behavior — and on some older units, events acknowledged locally but never delivered simply die.
Then there is the LTE module itself. A radio that has been idle for weeks has to wake, register on the network, and establish a session before the first event moves. On a healthy network that is seconds; on a marginal signal — and plenty of communicators live in metal panel cans in basements, where I routinely measure RSSI worse than -105 dBm — registration can take long enough that the panel's transmission attempts time out first.
Supervised vs Unsupervised Path: The Distinction That Matters
A supervised path exchanges regular check-in traffic with the receiver, so the central station learns within a defined window that the path is gone. An unsupervised path is silent until it is needed. The failure pattern writes itself: the primary IP path is supervised at a tight interval, the cellular path is supervised at 24 hours or not at all, the LTE SIM was deactivated in a carrier account cleanup eight months ago, and the first time anyone learns this is during an actual break-in with the ISP down. I found exactly this on a takeover audit of a jewelry retailer — the cellular path had been dead for over a year while the account billed for "dual path" the whole time.
Higher-security configurations supervise both paths at short intervals — commercial high-security setups run check-ins on the order of minutes, not hours. That supervision traffic is why real dual-path service costs more per month than a bare backup SIM. If the monitoring quote is suspiciously cheap, the cellular path is almost certainly on a long supervision interval or none.
Failover Reliability Sizing
When I audit or design a dual-path installation, I score it on the parameters below. The middle column is what typical installed defaults look like; the right column is what I spec for a site where the alarm actually matters.
| Parameter | Typical default | Spec for real coverage |
|---|---|---|
| Primary path poll interval | 60–300 s | ≤60 s |
| Failure detection threshold | 3+ missed polls | ≤2 missed polls |
| Cellular path supervision | 24 h or none | ≤1 h (minutes for high security) |
| Event queuing on path swap | Unverified | Verified by test: events queued and retried |
| Antenna signal at communicator | Whatever the can gives (−105 dBm or worse) | ≥−95 dBm, external antenna if needed |
| Failover test cadence | Never | Every service visit, both directions |
Nothing in that right-hand column is exotic. It is configuration and discipline, not hardware cost — with the occasional exception of a $40 external antenna and 15 minutes on a ladder.
Why a UL Listing Doesn't Cover Every Scenario
UL-listed communicators are tested to the standard's supervision and delivery requirements, and that matters — it is why the listed hardware behaves predictably at the boundaries the standard defines. But the listing certifies the equipment's capability, not your configuration of it. A listed dual-path communicator configured with 24-hour cellular supervision, installed in a basement can with a marginal antenna, on a SIM plan nobody is monitoring, passes no test the standard intended. The listing also says nothing about the failure modes upstream of the box: the carrier retiring a network technology, the monitoring contract's actual supervision interval, or the customer's IT department putting the communicator behind a new firewall during a network refresh. I have seen all three take down "listed" installations. Treat the listing as a floor, not a guarantee.
What the 3G Sunset Taught Us
The 3G shutdowns — completed by the major US carriers back in 2022 — were the largest natural experiment ever run on unsupervised alarm paths, and the results were ugly. Enormous numbers of communicators went dark, and the accounts where the cellular path was the unsupervised backup died silently: no trouble signal, no dealer notification, nothing until a service visit or an event that never arrived. Accounts with supervised cellular paths, by contrast, generated communication-failure signals the day their radios lost registration, and dealers could triage them.
The engineering lesson is not "3G is gone." It is that any unsupervised path decays invisibly — carrier network changes, SIM deactivations, antenna damage, firmware bugs — and the sunset merely made a slow, constant process happen all at once. LTE modules will eventually face their own migration. If your fleet's cellular paths are unsupervised today, you will re-live the sunset in slow motion.
Test-Signal Cadence and Why It Matters
The daily (or better) automatic test signal is the humble mechanism that catches most of this, and it is routinely configured wrong. The test must exercise the path you are worried about. A daily test that rides the IP path proves nothing about the radio. On communicators that support it, alternate the test transmission across paths, or schedule a periodic test forced over cellular. And the central station side has to actually alarm on a missed test — a test signal nobody supervises is a log entry, not a safety net. On DSC PowerSeries panels paired with dual-path communicators, this is all configuration-level work: test interval, path selection, and supervision windows are programmable, which is a large part of why that line remains an integrator favorite — the knobs exist, and the documentation to set them is public. The point isn't the brand; it's that the panel you spec must expose those knobs, because a communicator you cannot force-test over cellular is a communicator you cannot trust.
Designing a Dual-Path That Actually Works
The build recipe, in order. First, power: the communicator must ride the panel's battery backup, sized so the radio survives the same outage window as the panel — a cellular path that dies with mains power protects nothing, and LTE modules pull real current during transmission bursts. Second, signal: measure RSSI at the final mounting location with the can closed, not open on the bench; below about -95 dBm, fit an external antenna and re-measure. Third, configuration: tight polling on the primary, short supervision on the cellular path, verified event queuing across the swap. Fourth, the acceptance test that almost nobody runs — pull the customer's WAN connection, trip a zone during the detection window, and verify at the receiver that the event arrived over cellular, then restore and verify fail-back. Run it in both directions. Fifteen minutes, and it converts the marketing promise into a measured behavior.
Two more wrinkles that surface in takeover audits. First, battery math: an LTE communicator that idles at 60–100 mA can pull 0.5 A or more during registration and transmission bursts. If the installer sized the panel's standby battery for the panel alone — a common shortcut on retrofits where the communicator was added later — the system that is supposed to survive a 4-hour outage on battery actually browns out the radio in the last hour, which is precisely when a cut-line or storm scenario needs it. Recompute the standby calculation with the communicator's transmit current included, and load-test it: run the panel on battery, force a cellular transmission at the end of the target standby window, and confirm delivery. Second, the panel-to-communicator link itself: on installations where the communicator is a separate module wired to the panel's dialer output or keybus, that internal link is a failure point the dual-path design never sees. A keybus connector backed off by vibration gives you a panel that believes it reported and a communicator that never heard — and neither path matters. Supervise that link where the hardware allows it, and physically inspect it on takeovers; I have found more than one "communication failure" that was a screw terminal, not a network.
Finally, write the supervision intervals into the monitoring contract explicitly. "Dual path" on an invoice is not a specification; "60-second primary polling, 1-hour cellular supervision, missed-test escalation to dealer within 24 hours" is.
Deployment takeaway: Treat failover as a measured window, not a feature checkbox. Spec ≤60-second primary polling with a ≤2-poll failure threshold, supervise the cellular path at one hour or tighter, verify the communicator queues and retries events generated during the swap, and measure ≥−95 dBm at the closed can — external antenna if it misses. Then run the pull-the-WAN test at commissioning and every service visit: trip a zone during the detection window and confirm delivery at the receiver over cellular, both failover and fail-back. If the monitoring contract doesn't state the supervision intervals in numbers, the backup path is a hope, not a design.
Where This Fits in a Deployment Program
Communicator path design belongs at the same stage as panel selection, because the panel and communicator have to expose the polling, supervision, and forced-test configuration this whole approach depends on. If you are standardizing a fleet, the DSC intrusion catalog is a sensible place to anchor — the PowerSeries ecosystem's dual-path options give you the programmable supervision the design requires, and you can browse all DSC products to match panel capacity to zone counts. Intrusion rarely deploys alone; if the same project includes badge readers and controlled doors, the Access Control catalog covers that side of the bill of materials. If you have a site where the failover behavior has never been tested — or a takeover where you suspect the cellular path is quietly dead — send over the panel model, communicator, and monitoring contract details, and I'm glad to help you spec the supervision configuration and an acceptance test plan before the next ISP outage runs the test for you.