Edge Computing for Industrial IoT

Why Edge Computing Is Becoming Unavoidable

IoT deployments have grown steadily in scale for the past decade, but the data volumes being generated by modern industrial, transport, and infrastructure applications have started to expose the limits of centralised architectures. Sending every sensor reading, camera frame, and status packet to a remote cloud platform for processing is no longer practical – not on cost grounds, not on latency grounds, and not on reliability grounds.

Three converging pressures are driving the shift to edge computing in 2025 and 2026:

1. Latency requirements that cloud cannot meet

A CCTV tower identifying a security event and triggering a response cannot wait 80-120ms for a round-trip to a cloud analytics engine. Predictive maintenance algorithms running on vibration sensors attached to industrial motors need sub-50ms decision loops. Autonomous guided vehicles on a factory floor need routing updates in near real time. For all of these, edge processing – running the analysis locally and only sending results or exceptions to the cloud – is the only architecture that works.

2. Bandwidth and data cost pressure

A single 4K IP camera generates roughly 8-15 Mbps of continuous data. Multiply that across a 12-camera smart pole deployment on a cellular connection and you have a data transfer problem. Edge inference – running object detection or licence plate recognition locally and transmitting only metadata or flagged clips – can cut data volumes by 90% or more. On cellular SIM plans, that is a direct cost reduction. On constrained backhaul links, it is the difference between a functional deployment and a saturated one.

3. Resilience and offline operation

Connectivity is never guaranteed. WAN outages, cellular congestion, and temporary signal loss are facts of life in field deployments. An architecture that depends entirely on cloud connectivity for decision-making fails the moment the link drops. Edge-capable hardware can buffer, process, and act locally during outages – and synchronise with cloud platforms when the connection is restored. For safety-critical or revenue-generating applications, this is not an optional feature.

Cloud vs Edge: What the Architecture Actually Looks Like

The distinction between cloud, edge, and hybrid architecture is sometimes framed as binary. In practice, most production IoT deployments use a layered model – and understanding where each layer sits helps clarify what your gateway hardware needs to do.

For most industrial IoT deployments, the near-edge layer – the on-site gateway or router – is where the critical work happens. This is the piece of hardware that needs enough compute resource to run containerised workloads, enough connectivity headroom to handle WAN failover, and enough industrial hardening to operate reliably in a plant environment, a roadside cabinet, or the top of a mast.

Why Cellular Resilience and Edge Computing Belong Together

Edge computing reduces dependence on the WAN for real-time decision-making. But the WAN still matters – for telemetry, for synchronising edge models with cloud platforms, for remote management, and for any use case where local processing is not sufficient on its own. A capable edge processor sat behind a poorly specified cellular connection is a bottleneck waiting to reveal itself.

Cellular resilience in this context means more than dual-SIM failover, though that remains essential. It means:

• Multi-network SIM capability – the ability to connect to whichever network offers the best signal at a given location, rather than being locked to a single operator. For deployments across varied UK geographies, roaming SIM solutions and multi-network SIM cards remove the single-operator dependency that has caused failures in rail-side, highway, and rural deployments.
• Automatic WAN failover – detection of link degradation and seamless switchover between SIM slots or WAN sources without human intervention.
• Load balancing – distributing traffic intelligently across available connections to maximise throughput and prevent saturation on any single link.
• 5G SA readiness – as UK operators continue 5G Standalone rollout, the ability to operate in SA mode matters for applications that depend on network slicing, ultra-low latency, or dedicated QoS.

For a broader treatment of cellular connectivity options for IoT, the IoT Connectivity Guide covers LTE categories, 5G SA vs NSA, and UK operator coverage in detail.

Case Study: Teltonika RUTC50 as an Edge and Connectivity Platform

The Teltonika RUTC50 is one of the most capable edge-connectivity platforms available at this price point in the industrial IoT market. It is worth examining in detail because it illustrates exactly what an edge gateway specification should look like – and why the combination of compute, connectivity, and SIM flexibility changes what a single piece of hardware can do.

What makes this specification significant for edge deployments

Most industrial 5G routers are positioned as connectivity devices. The RUTC50 crosses into edge compute territory through a combination of factors that, taken together, change what the hardware can do on-site.

Docker container support is the headline capability. With 1 GB RAM and 8 GB of flash on the eSIM variant, the RUTC50 can host containerised workloads alongside its routing functions – running lightweight analytics applications, local MQTT brokers, protocol converters, or custom scripts without requiring a separate compute device on-site. For deployments where adding an additional server or compute node is not practical, this significantly expands what a single piece of hardware can deliver.

5G SA/NSA with LTE Cat 19/20 fallback means the device does not simply drop performance when 5G is unavailable – it degrades gracefully to the fastest available LTE connection, maintaining throughput rather than failing over to a hard floor. For applications that require sustained bandwidth for edge-to-cloud sync or high-volume telemetry, this matters.

Dual SIM with auto-failover plus integrated eSIM provides three distinct layers of cellular redundancy – a combination covered in more detail in the eSIM section below.

The operating temperature range of -40 to +75 degC is worth noting specifically. Many edge gateway deployments fail not because of software or connectivity issues but because the hardware was not rated for the thermal environment it was installed into – whether a roadside cabinet in winter or a machinery enclosure in a heated factory. The RUTC50 specification covers the range typical for UK outdoor and industrial installations.

The RUTC50 is available with eSIM capability via RouterStore, which stocks the UK-ready eSIM variant alongside a range of complementary Teltonika hardware.

eSIM and the Remote Management Advantage for Edge Deployments

The eSIM variant of the RUTC50 ships with a permanently soldered eUICC chip capable of storing up to 7 eSIM profiles. This changes the deployment and operational model for cellular connectivity in ways that are particularly relevant for edge installations.

Why eSIM matters for edge hardware

Traditional SIM-based deployments require physical SIM card changes when switching operators, changing tariffs, or handling a SIM that has been blocked or expired. For an edge gateway installed 8 metres up a smart pole, inside a sealed outdoor cabinet, or in a restricted access plant room, a physical SIM change is a costly site visit. With eSIM, operator profile changes are provisioned over the air.

The RUTC50 supports consumer-type eSIM with profile download and removal. Combined with physical dual-SIM slots, the result is a device with three independent paths to cellular connectivity – SIM slot 1, SIM slot 2, and the integrated eSIM – with auto-failover routing traffic across whichever is available and performing.

For the connectivity layer itself, the SIM strategy is equally important. A multi-network SIM – one that is not locked to a single UK operator’s roaming agreements – provides the network diversity that makes the hardware-level failover genuinely useful. If both the primary and failover SIM draw on the same underlying network infrastructure, a regional outage can still take both paths down simultaneously. Roaming SIMs and true multi-network SIM solutions are specifically designed to address this.

SGP.32 and the evolving eSIM standard for IoT

The eUICC standard that governs eSIM in IoT devices has been moving through several GSMA specifications. SGP.02 (M2M) and SGP.22 (consumer) have been the dominant frameworks, but SGP.32 – the IoT-specific consumer eSIM architecture – is emerging as the standard most relevant for industrial deployments that need over-the-air provisioning at scale without the M2M SM-DP+ infrastructure overhead.

A detailed treatment of SGP.32 and what it means for IoT eSIM provisioning is available at SGP32.co.uk, along with broader eUICC technical reference at euicc.co.uk. For organisations managing eSIM profiles across a fleet of deployed edge devices, eSIM IoT Manager provides the tooling to handle profile lifecycle management without a full-scale M2M SM-SR deployment.

For more background on SIM and eSIM fundamentals in an IoT context, the IoT SIM Explained guide covers the full stack from physical SIM form factors through to eUICC architecture and UK MVNO options.

A Practical Deployment Scenario: Industrial Site Monitoring

To ground the above in something concrete, consider a typical industrial IoT deployment that highlights where edge computing and cellular resilience interact.

The scenario

A UK logistics and distribution facility needs real-time monitoring across a 40-acre site – covering perimeter security cameras, temperature and humidity monitoring in cold storage zones, access control event logging, and predictive maintenance data from conveyor motor sensors. The site has an existing MPLS connection to HQ but it is not sufficient for the camera bandwidth, and the MPLS is the only WAN path – meaning any disruption to it takes down all site monitoring.

The conventional approach and its problems

The default approach – routing everything to a cloud platform and running analytics centrally – fails on three counts here. First, camera data volume saturates the MPLS. Second, predictive maintenance alerts require sub-second response times that cloud analytics cannot provide. Third, a single WAN path means a single point of failure for all monitoring.

The edge-plus-cellular approach

With a RUTC50-based edge architecture, the deployment looks significantly different:

• The RUTC50 acts as the primary gateway for the cellular WAN connection, running in parallel with the MPLS via dual-WAN configuration. If the MPLS fails, cellular takes over automatically with no manual intervention.
• A Docker containerised NVR application runs locally on the RUTC50, handling camera motion detection and event clipping on-site. Only flagged clips and metadata are transmitted to the cloud, cutting camera data transmission by over 90%.
• A lightweight MQTT broker running as a container on the device handles sensor telemetry locally, applying threshold logic and generating alerts without requiring a cloud round-trip. Motor vibration anomalies trigger alerts within 15ms.
• The eSIM profile is set to a multi-network SIM from roamingsim.co.uk, with the physical SIM slots holding SIMs from two different MVNO providers for maximum network diversity. Even in the event that one UK operator has a regional outage, connectivity is maintained.
• GNSS data from the RUTC50 is used to cross-reference asset location data from forklift tracking modules across the facility.
• Remote management via Teltonika RMS and eSIM profile management via eSIM IoT Manager mean that firmware updates, connectivity changes, and configuration adjustments are handled entirely from a central dashboard – with no site visits required.

What to Look for in Edge-Capable Industrial Gateway Hardware

The RUTC50 is a strong example, but not every deployment requires its specific specification. When evaluating edge gateway hardware for an industrial IoT project, the following criteria are worth treating as baseline requirements rather than optional features.

For a broader comparison of cellular router categories and which classification maps to which use case, Cellular Router Classifications Explained covers the full spectrum from basic CPE to dual-modem industrial gateways.

Security configuration is equally important when deploying edge compute nodes – a device running containerised applications on an industrial network is a more significant attack surface than a standard routing device. The IoT Security Guide covers hardening approaches for cellular gateways in detail.