Construction Site Connectivity FAQ: Resilient Site Networks

This FAQ is designed for project, commercial and IT teams that need to understand which failures can take a site down, what an outage during a critical activity can cost, and how to keep essential systems working through disruption.

This resource is a companion to CSL Group’s white paper, The Digital Backbone for Modern Construction, which sets out why site connectivity should be treated as a project delivery dependency, not an IT convenience.

Architecture and resilience

Our site already has a backup connection. Does that not count as true redundancy?

Not necessarily. A backup connection only counts as true redundancy if it does not share the same operator core, carrier dependency, or failure domain as the primary path, and can switch between them seamlessly. For example, if the second connection is a SIM that routes through the same operator core as the first, both paths fail together when that core fails, even though there appear to be two networks available. This is the most common false-redundancy trap on site: BIM, CCTV, and access control all drop at once because they share one core or single point of failure. The test we apply is simple. If a backup network shares the same core as the primary, it is not true redundancy. Genuine independence means two separate operator cores, which is what DUAL-CORE provides, with CSL Outpost extending that to four independent paths.

Is a multi-network SIM the same as DUAL-CORE?

No. A multi-network SIM can attach to more than one operator’s radio access network, which handles radio-side problems such as a single mast going down or coverage degrading in one part of a site. It is the right baseline for reducing localised outages. DUAL-CORE adds the layer that a multi-network SIM does not reach: two fully independent operator cores that overcome core network issues. In CSL’s patented rSIM, the switch between them is autonomous: the SIM monitors its own connectivity, detects problems including silent failures where a connection looks attached but is no longer passing data, and moves to the second core without manual intervention or an external trigger. Multi-IMSI products, which can hold several network profiles, lack that self-monitoring intelligence and therefore the ability to move during an outage, and many still route through a single core or shared service layer, which is often where the widest-impact cellular outages occur. Unless the architecture provides genuinely independent operator cores and the intelligence to switch between them automatically, radio diversity does not remove core-network correlation.

What is a core network, and why is a core failure the worst case?

The core network is the part of a mobile network that authenticates SIMs, validates devices, and routes all traffic. It is, in effect, the brain of the network. When a core fails, every subscriber on that network loses service regardless of location or signal strength, because the failure sits above the radio. Core failures are rarer than local radio problems, but they have the largest blast radius of any single point of failure in cellular connectivity. A device showing full signal bars can still be cut off entirely if the core behind it has failed.

Isn’t 99.9% availability good enough for a site?

Not on its own. It helps to translate the percentage into real time first. Over a year, 99% uptime still allows about 3.65 days of downtime; 99.8% about 17.5 hours; 99.9%, the figure most often quoted, about 8.8 hours; 99.98% around 1.75 hours; and 99.99% about 53 minutes. Each additional nine cuts the permitted downtime roughly tenfold, so the small-looking gap between 99.9% and 99.99% is a tenfold difference, not a rounding detail. Even so, the headline number hides the only question that matters on site: when does the outage land? Two sites can record identical annual downtime and face very different outcomes. Spread across short interruptions it is a productivity nuisance; concentrated into a single outage during a concrete pour or a crane lift, the same hours can mean a failed pour, contractual penalties for delay, and schedule slip. The metric that matters is not aggregate uptime, it is the probability that the network is available when a critical operation runs.

What is the PACE framework?

PACE stands for Primary, Alternate, Contingency, and Emergency, and it is a structured way to layer connectivity so that a site keeps working as paths fail. Primary is the main link for normal operations, typically broadband or primary cellular. Alternate activates automatically when Primary fails and should use a different technology, carrier, or core to avoid hidden correlation. Contingency engages when both have failed, whether that is a third independent path, local caching, or pre-authorised manual procedures. Emergency is last-resort connectivity for safety communications, often Low Earth Orbit (LEO) satellite (although it can also be deployed as the Primary, Alternate or Contingency layer as appropriate to the location). The framework lets you match the depth of resilience to the criticality of each site.

When do we need QUAD-CORE Multi-Link or CSL Outpost rather than DUAL-CORE?

The right choice depends on a project’s risk profile, not its size. DUAL-CORE removes core-network correlation and is a practical starting point for most schedule-critical work, delivered through rSIM or a CSL IoT router. QUAD-CORE Multi-Link earns its place at the higher-exposure end, where a project cannot tolerate any single-mode failure, whether cellular, broadband, or satellite. CSL Outpost delivers this as four independent managed paths under SD-WAN orchestration with automatic failover, available as four cellular cores or as a mix of cellular, broadband, and LEO satellite.

The four bearers are not only there for failover: they are bonded, so their bandwidth is aggregated and load-balanced across the links, letting a single Outpost provide Wi-Fi coverage across the site from the pooled connection as well as surviving the loss of any one path. For critical-path projects, or large and busy sites that need resilience and shared bandwidth together, that combination is what justifies stepping up from DUAL-CORE.

The cost of downtime

How much can a single connectivity outage actually cost?

More than the lost hours suggest, because construction risk is non-linear. The direct cost of idle hours, standing plant, re-planning, and minor rework is real, but it is largely recoverable. What dominates is what the outage triggers: a missed inspection window that pushes the critical path, leaving follow-on trades idle and exposing the programme to liquidated damages. A single correlated outage that lands on a critical activity can consume a meaningful share of a project’s margin in one window, well beyond what the downtime hours alone would imply. The cascade, not the brief loss of connectivity, is what dominates.

Why model outage risk with Monte Carlo rather than a simple average?

Because a single average cannot capture the shape of this risk. Outage frequency, duration, and timing are all uncertain, and the cost depends heavily on whether an outage lands during a critical window such as a pour or a lift. A Monte Carlo simulation runs many synthetic project-years and produces the full cost distribution rather than one number. What it reveals is that the risk is strongly skewed: the median year looks modest, while a small number of tail years dominate the expected loss. That is the same logic insurers and risk reserves use, and it is the right basis for a resilience business case.

We have never lost serious money to a connectivity failure. Why invest now?

A clean record so far is reassuring, but it reflects timing as much as low risk: the correlated outage that lands on a critical pour, lift, or inspection simply has not happened yet. The exposure sits on every schedule-critical activity whether or not it has been realised. What makes DUAL-CORE straightforward to justify is that it removes the correlated failure mode with the largest blast radius, a shared operator core, and it can be built into the site connectivity design from the outset rather than treated as a late-stage add-on: rSIM or a CSL IoT router adds it to existing devices without re-engineering. The business case borrows from how risk reserves and insurance work, pricing against the loss you cannot absorb rather than the average year. Because the safeguard is inexpensive and the exposure is already present, there is little to gain from waiting for the event that proves the point.

On site: deployment and coverage

Broadband will not be live for weeks. What covers us in the meantime?

A resilient cellular setup covers the gap from day one. On many sites, fixed broadband is unavailable for the first weeks or months, which leaves cellular as the sole primary connection during early phases. That is exactly the period when resilience matters and is most often overlooked. A CSL IoT router with DUAL-CORE switching in firmware provides resilient, DUAL-CORE connectivity from day one, with no fixed-line dependency, remote management, and automatic failover. It deploys immediately and removes the broadband lead-time risk rather than waiting for an installation date. Where the early-phase site needs more capacity, CSL Outpost offers the same fixed-line-free, rapid deployment but with four bonded bearers, pooling their bandwidth and providing Wi-Fi coverage across the site. Either option can add fixed broadband once it is installed, and LEO satellite where cellular coverage is weak, so the early-phase setup evolves rather than being ripped out and replaced.

Can the site team not just fall back to mobile phones?

Phones cover voice and messaging, but not the failure modes that matter on a digitised site. Safety and IoT systems such as CCTV, access control, and sensors are embedded devices that cannot tether off a handset, and BIM, CDE, and right-to-work applications run on approved corporate infrastructure rather than personal phones. Core outages are also not always shared across networks: a consumer network failure can take handsets down with the site, while an IoT or roaming core failure can leave handsets working, but working handsets still cannot substitute for embedded site systems. A personal phone is a voice fallback, not a substitute for resilient site connectivity.

Read more: CSL managed site connectivity

What is the difference between a CSL IoT router and an rSIM?

They deliver the same DUAL-CORE resilience in two forms, chosen by context. A CSL IoT router carries the dual-core switching logic in its firmware, and CSL configures and supports it to route across two fully independent operator cores. That managed configuration is what makes it genuinely DUAL-CORE, not a generic dual-SIM router that may only switch radios while sharing a single core. A generic device may also lack two things a managed CSL deployment provides: intelligent, autonomous failover logic, and secure, private system and data pathways such as a private APN and encrypted tunnel that keep site traffic off the public internet. The CSL router is the preferred form factor for site-level connectivity: ruggedised, enterprise-grade, built for harsh environments, deployable with no fixed-line dependency, and remotely managed.

An rSIM puts the same switching intelligence into a SIM, designed for third-party devices that cannot have CSL firmware installed but still need resilient connectivity, such as telematics gateways, alarm panels, CCTV appliances, and lone-worker pendants. In practice, many sites use the router for the site network and rSIM inside the equipment around it.

Read more: rSIM (resilient SIM)

What happens on sites with poor or patchy coverage?

Survey the site first, then add link diversity where it is needed. Coverage on a construction site is not fixed: signal quality varies by zone, changes as structures rise, and is affected by materials, plant, and terrain. The first step is to remove the guesswork with a coverage survey using the CSL Signal Analyser, which maps signal quality and identifies dead zones before an architecture is chosen. Where cellular alone is not enough, link-type diversity is added through broadband or LEO satellite, delivered as Multi-Link or CSL Outpost. For remote and off-grid sites, a managed satellite and cellular service can provide connectivity from day one where terrestrial broadband is unreliable or absent.

How do we keep working through an outage we cannot prevent?

Resilient connectivity is the first line of defence: it reduces how often outages occur and how long they last, and it keeps the real-time and safety-critical systems live, such as CCTV, access control, lone-worker monitoring, and central oversight, that an offline cache cannot replace.

Offline-first working is the complementary backstop that helps maintain operations, covering the workflows that can tolerate store-and-forward: the latest drawings, models, and specifications cached locally so field tablets hold what the next task needs; offline-capable apps that save inspections, timesheets, and permits and sync accordingly. The two are complementary, not alternatives, and offline capability is not a substitute for the connection: it keeps document-based work moving through a short dropout, but the systems that depend on a live link still need one. A dependable site relies on resilient connectivity first, with offline capability underneath it.

Standards and compliance

Does connectivity resilience affect CDM 2015 compliance?

It can, where safety-critical systems depend on the site network. Under CDM 2015, principal contractors must plan, manage, monitor, and coordinate the construction phase, with suitable and sufficient arrangements for foreseeable emergencies, including evacuation procedures. Where CCTV, access control, or lone-worker monitoring rely on site connectivity, a network failure can create a safety-management and assurance risk. The duty is to plan for foreseeable communication breakdowns rather than to assume the network will always be available, which is what a tested fallback path is intended to support. Resilient connectivity can support that assurance, but it does not by itself guarantee compliance, which rests on the contractor’s wider arrangements.

How does this relate to the Building Safety Act golden thread?

Indirectly, yes. For higher-risk buildings in England, the Building Safety Act regime and associated guidance require golden-thread information to be kept digitally, securely, and available when needed. BIM models, CDE documents, and inspection records becoming inaccessible during an outage can interrupt that information flow at the point design and safety decisions are being made on site. Connectivity resilience materially supports the objective by keeping that information reachable when it is needed. It is one practical input to helping maintain golden-thread assurance.

About CSL

CSL helps construction contractors and their project teams specify resilient connectivity for site networks and the equipment connected to them, from multi-network IoT SIMs and DUAL-CORE rSIM through to Multi-Link and CSL Outpost, and runs the managed service layer above it. You can see this in practice in our remote construction site case study.

Talk to us about your sites, your critical activities, and the exposure you are trying to protect.

Contact CSL: https://www.csl-group.com/contact-us/

Construction Site Connectivity FAQ. CSL Group, June 2026. Companion to the white paper The Digital Backbone for Modern Construction.

About CSL: a UK connectivity provider for critical IoT and safety applications, including life-critical connectivity, alarm signalling, construction, logistics, EV charging, and healthcare.