Choosing the Right Data Plan for IoT and M2M

ALCHEMY SIM · 18 min read

IoT and M2M projects fail at an alarming rate. Industry surveys consistently put the figure somewhere between 60 and 75 per cent, depending on who you ask and how they define failure. The reasons are varied, but connectivity problems account for a disproportionate share. Not connectivity hardware, which has become remarkably good. The problem is almost always the data plan: the wrong type, the wrong size, the wrong commercial model, or a single-network SIM that cannot get a signal at the one location where it matters most.

This article is a practical guide to choosing IoT and M2M data plans using Alchemy SIM, our multi-network SIM platform. It covers data consumption patterns across common use cases, the mechanics of multi-network carrier selection, data pooling, private APNs, coverage planning, SIM management at scale, and integration with Peplink routers for deployments that need more than basic connectivity. If you are planning a deployment of ten devices or ten thousand, the principles are the same.

Why IoT Connectivity Is Different

Before getting into specific data plans, it is worth understanding why IoT and M2M connectivity requires a fundamentally different approach to consumer or enterprise mobile broadband.

Consumer SIMs are designed for a single user with a single device who moves around and uses data in unpredictable bursts. Enterprise mobile broadband is typically a handful of high-bandwidth connections backing up a wired primary. IoT is neither of these things. IoT deployments typically involve large numbers of devices, each consuming very small amounts of data, often in fixed locations, operating unattended for months or years at a time. The failure modes are different. The commercial dynamics are different. The support requirements are different.

Here is what makes IoT connectivity distinct:

• Low and predictable data usage. Most IoT devices consume between 1 MB and 500 MB per month. A GPS tracker might use 5 MB. An environmental sensor sending readings every fifteen minutes might use 2 MB. A CCTV camera will use 30 to 150 GB. The range is vast, but within each use case, consumption is remarkably predictable.
• Long deployment lifetimes. Consumer contracts run for 12 to 24 months. IoT devices stay deployed for 5 to 15 years. The SIM and the data plan need to survive that entire period, including carrier network changes, technology migrations (3G sunset, 4G sunset eventually), and price adjustments.
• Unattended operation. Nobody is going to walk out to a remote water monitoring station to swap a SIM because the carrier changed their APN settings. The connectivity layer needs to be self-healing or at least remotely manageable.
• Fixed locations with variable coverage. A fleet tracking device moves and needs nationwide coverage. A remote sensor sits in one spot and needs coverage at that exact spot. Both are valid IoT use cases, but they need very different coverage strategies.
• Scale economics matter enormously. When you are buying one SIM, a pound or two per month is irrelevant. When you are buying five thousand SIMs, every penny per megabyte compounds into a significant budget line.

Data Consumption Patterns by Use Case

Getting the data plan size right starts with understanding how much data each device actually needs. The following table covers the most common IoT and M2M use cases we deploy connectivity for, with realistic monthly consumption figures based on actual deployments rather than theoretical calculations.

Use Case	Typical Monthly Data	Traffic Pattern
GPS fleet tracking (position only)	2 to 10 MB	Small packets every 10 to 60 seconds during operating hours
Fleet tracking with driver behaviour	15 to 50 MB	Continuous accelerometer and gyroscope data during driving
Environmental sensors (temperature, humidity, air quality)	1 to 5 MB	Small payloads at fixed intervals, typically every 5 to 30 minutes
Water level or flow monitoring	2 to 8 MB	Periodic readings plus event-triggered alerts during flooding
Industrial machine monitoring (vibration, temperature)	10 to 100 MB	Frequent small readings with occasional large diagnostic dumps
Remote CCTV (720p, motion-triggered)	30 to 80 GB	Bursty, depends entirely on how much motion occurs
Remote CCTV (1080p, continuous recording)	100 to 300 GB	Continuous high-bandwidth upstream
Digital signage (content updates only)	500 MB to 5 GB	Large downloads when content is refreshed, near-zero otherwise
Digital signage (cloud-managed, interactive)	5 to 30 GB	Persistent connection, periodic content sync, usage telemetry
Smart metering (electricity, gas, water)	0.5 to 3 MB	Very small readings at regular intervals, occasionally on-demand reads
Vending machine telemetry	5 to 20 MB	Stock level updates, payment processing, occasional firmware updates
Agricultural soil sensors	1 to 4 MB	Readings every 15 to 60 minutes, seasonal variation

Several things are worth noting from this table. First, the variation between use cases is enormous. A soil moisture sensor and a CCTV camera both count as IoT, but their data requirements differ by a factor of fifty thousand. Treating them the same when buying data plans is a common and expensive mistake.

Second, the figures above are for normal operation. Firmware updates can spike data usage dramatically. A fleet of a thousand trackers pulling a 5 MB firmware update simultaneously generates 5 GB of unexpected traffic. Plan for this, or stagger your rollouts.

Third, some use cases have inherently unpredictable traffic patterns. Motion-triggered CCTV in a quiet location might use 30 GB per month, but the same camera overlooking a busy road could use 80 GB. Build headroom into your plan for these variable workloads.

Multi-Network SIM: Why It Matters for IoT

A multi-network SIM, sometimes called a roaming SIM or multi-IMSI SIM, can connect to more than one mobile carrier. Alchemy SIM connects to all major UK carriers and over 600 networks globally. For IoT deployments, this capability is not a nice-to-have. It is often the difference between a deployment that works and one that does not.

Automatic carrier selection

When an Alchemy SIM powers up in a device, it surveys the available networks at that location and connects to the strongest one. If that network later degrades or goes down, the SIM will re-select and attach to a different carrier. This happens automatically at the SIM level, with no intervention from the device firmware and no action required from your operations team.

For IoT, this behaviour solves a specific and common problem. When you are deploying a thousand devices across varied locations, you cannot predict which carrier will have the best signal at each site. With a single-network SIM, you are gambling. If you pick carrier A and 8 per cent of your sites have poor carrier A coverage, those devices will underperform or fail entirely. With a multi-network SIM, each device finds its own best carrier. The 8 per cent problem disappears.

No single-network dependency

Carrier outages happen. They are infrequent but they do happen, and when they do, they tend to be regional and can last for hours. If your entire IoT estate runs on a single carrier, a regional outage takes down every device in that region simultaneously. For some use cases, that is tolerable. For security cameras, alarm systems, environmental monitoring of hazardous sites, or safety-critical telemetry, it is not.

Multi-network SIM gives you carrier-level redundancy at every site, without the cost and complexity of deploying two SIMs per device. The SIM handles the failover. Your device does not need to know it happened.

Future-proofing against network changes

Mobile networks change. 3G is already being switched off in the UK, with full shutdown expected by 2028. Carriers merge, rebrand, and re-allocate spectrum. If your IoT device is locked to a single carrier and that carrier deprecates the technology your device uses, you have a field recall on your hands. Multi-network SIM reduces this risk substantially. If one carrier drops 2G support but another retains it, the SIM migrates automatically.

Data Pooling Across Devices

Data pooling is one of the most significant cost-saving mechanisms in IoT connectivity, and it is one that many organisations overlook entirely because they are used to consumer mobile contracts where each SIM gets its own individual allocation.

With Alchemy SIM, data pooling means that all SIMs on your account share a single data allowance. If you have 500 SIMs each expected to use around 10 MB per month, your total pool is 5 GB. Some devices will use 15 MB in a given month; others will use 3 MB. As long as the total across all devices stays within the pool, there are no overages.

This matters for IoT because device-level data usage is inherently variable, even within a single use case. An environmental sensor in a building with stable conditions will send fewer alert-triggered readings than one in a greenhouse where temperatures swing daily. Without pooling, you need to size every individual SIM's plan to accommodate the worst-case device, which means paying for unused data on every other device.

How pooling changes the economics

Consider a fleet tracking deployment of 200 vehicles. Average monthly consumption per device is 8 MB, but individual devices range from 3 MB (a vehicle that sits in the depot most days) to 25 MB (a delivery van doing twelve-hour shifts across the country). Without pooling, you would need to put every SIM on a 25 MB plan to avoid overages, buying 5 GB total but only using 1.6 GB. With pooling, you buy a 2 GB shared pool (adding 25 per cent headroom to the 1.6 GB average), and all 200 SIMs draw from it. The cost difference is substantial.

Pooling also simplifies management. Instead of monitoring data usage on 200 individual SIMs and chasing overage alerts, you monitor one pool. One number. One alert threshold.

Private APN for Secure IoT

A standard mobile data connection routes traffic through the carrier's public network and out through their internet gateway. For consumer browsing, that is fine. For IoT devices sending sensitive operational data, it introduces risks that many organisations are not comfortable with.

A private APN (Access Point Name) creates a dedicated, isolated data pathway between your IoT devices and your infrastructure. Traffic from your devices never touches the public internet. Instead, it passes through the carrier's mobile core and is delivered directly to your network via a VPN or dedicated interconnect.

Why this matters for IoT

IoT devices are often deployed in the field with minimal physical security. They run embedded operating systems with limited patching capabilities. They frequently use lightweight protocols (MQTT, CoAP) that were designed for efficiency, not security. Exposing these devices directly to the public internet is asking for trouble.

With a private APN via Alchemy SIM, your devices sit on a completely separate network segment. They can communicate with your servers, your cloud platform, or your on-premises infrastructure, but they cannot reach the internet and the internet cannot reach them. This is not a firewall configuration that could be misconfigured. It is a fundamental network topology separation at the carrier level.

Private APN also gives you static private IP addressing for each device, which simplifies device management enormously. You can SSH into a remote sensor, pull diagnostics from a CCTV recorder, or push firmware updates to a specific device, all addressed by its static IP rather than relying on dynamic DNS or device-initiated connections.

Coverage Considerations: Urban, Rural and International

Coverage is the single biggest variable in any IoT deployment, and it is the one that gets the least attention during planning. Organisations will spend weeks evaluating sensor hardware and days evaluating cloud platforms, then pick a SIM based on a coverage checker on a carrier's website. Those coverage checkers show outdoor population coverage. Your sensor is indoors, underground, or in a metal enclosure in a field. The two have almost nothing in common.

Urban deployments

Urban coverage is generally excellent across all UK carriers, but "excellent" is a relative term. Building penetration varies enormously. A sensor in a basement car park may have no usable signal from carrier A but a strong signal from carrier B, because carrier B has lower-frequency spectrum that penetrates better. Multi-network SIM handles this automatically, selecting whichever carrier reaches the device. For urban deployments inside buildings, test actual signal levels at the installation point. Do not rely on coverage maps.

Rural deployments

Rural coverage is where multi-network SIM earns its keep. In rural UK, coverage varies wildly between carriers. One carrier might have a mast in the village; the others might not. Agricultural IoT, environmental monitoring, flood warning systems, remote CCTV for farms: all of these tend to sit in locations where single-network coverage is patchy at best.

With Alchemy SIM, a device in a rural location can access whichever carrier has the best signal. In practice, this means the device will often connect to a carrier you would not have chosen if you were picking a single network. The carrier with the best national coverage statistics is not necessarily the carrier with the best signal at the specific field gateway on a specific farm in mid-Wales.

For very remote sites where even multi-network coverage is marginal, consider pairing Alchemy SIM with an external antenna. A Peplink MAX BR1 with a roof-mounted antenna can pull usable signal from towers several kilometres away, turning a marginal deployment into a reliable one.

International deployments

If your IoT devices operate across multiple countries, roaming costs and carrier agreements become critical. Consumer roaming is expensive and often blocked on IoT-style usage patterns. Alchemy SIM provides access to over 600 carrier networks globally, with a consistent rate card and no surprise roaming charges. For fleet tracking across European borders, maritime tracking, or multinational industrial deployments, this simplifies both procurement and ongoing cost management.

SIM Management at Scale

Managing ten SIMs is admin work. Managing a thousand SIMs without a management platform is a full-time job that nobody wants. Alchemy SIM includes a web-based management portal that gives you visibility and control across your entire SIM estate.

What you can do from the portal

• Activate and suspend SIMs remotely. When a device is installed, activate its SIM from the portal. When a device is decommissioned or stolen, suspend it immediately. No phone calls to a carrier. No waiting for a support ticket to be processed.
• Monitor data usage in near-real-time. See per-SIM and pooled usage across your estate. Set alerts when individual SIMs or the pool as a whole approach thresholds.
• Set data caps per SIM. Prevent a malfunctioning device from consuming your entire data pool. If a CCTV camera firmware bug causes it to stream 24/7 at maximum resolution, a per-SIM cap limits the damage.
• View network attachment history. See which carrier each SIM is currently connected to, and which carriers it has used historically. This is invaluable for diagnosing intermittent connectivity problems.
• Manage SIM lifecycle. Track SIMs from provisioning through active use to suspension and decommissioning. Know exactly which SIMs are in stock, deployed, or retired.
• Export usage data. Pull CSV exports for billing reconciliation, capacity planning, or integration with your own systems.

API access for automated management

For large-scale deployments, manual portal management is not practical. Alchemy SIM provides API access for programmatic SIM management. This lets you integrate SIM activation into your device provisioning workflow, pull usage data into your monitoring dashboards, automate suspension rules, and build custom alerting logic.

A typical integration pattern: your warehouse management system scans a device barcode during dispatch, triggers an API call to activate the embedded SIM, and logs the SIM ICCID against the device serial number in your asset database. When the device reaches the installation site and powers on, it is already activated and ready to connect. No manual steps, no delays, no human error.

Integration with Peplink Routers

For IoT deployments that need more than a SIM in a sensor, Peplink routers provide the connectivity backbone. Two models are particularly relevant for IoT and M2M.

Peplink MAX BR1 for remote sites

The MAX BR1 is a compact cellular router designed for remote and mobile deployments. It takes a single SIM card, supports external antenna connections, and provides Wi-Fi and Ethernet connectivity to local devices. For IoT, the BR1 serves as a site gateway: it takes the Alchemy SIM, establishes the cellular connection, and provides local network connectivity for multiple sensors, cameras, or controllers at that site.

A typical remote monitoring installation uses one BR1 with an Alchemy SIM to connect three or four sensors, a local controller, and perhaps a CCTV camera. The BR1 handles the cellular uplink, provides DHCP and routing for the local devices, and can establish a SpeedFusion VPN tunnel back to head office for secure data transport. One SIM, one router, multiple devices.

For sites with marginal coverage, the BR1's external antenna ports are essential. A small omnidirectional antenna on a short mast can make the difference between a connection that drops every few hours and one that runs for months without interruption. For truly challenging sites, a directional antenna pointed at the nearest tower can recover usable signal from surprising distances.

Peplink Balance for aggregation

When you need to bring together data from multiple remote sites, a Peplink Balance at your central location acts as the aggregation point. It terminates SpeedFusion VPN tunnels from every remote BR1, giving you a single secure network that spans all your remote sites.

This architecture is common in larger IoT deployments. A water utility monitoring 200 remote pumping stations, each with a BR1 and Alchemy SIM, terminates all tunnels on a Balance 380 at headquarters. The SCADA system at headquarters sees every remote site as if it were on the local network. No port forwarding, no dynamic DNS, no exposed public IP addresses. Just a flat, routed network with end-to-end encryption.

For cloud-hosted applications, FusionHub (Peplink's virtual appliance) serves the same aggregation role but runs in AWS, Azure, or any other cloud provider. Your IoT data flows from Alchemy SIM through the BR1, through a SpeedFusion tunnel, into FusionHub, and directly into your cloud application. The entire path is encrypted, and the devices never touch the public internet.

Cost Modelling: Getting the Numbers Right

IoT connectivity costs are deceptively simple on the surface but compound in unexpected ways at scale. Here is a framework for modelling the true cost of your IoT data plan.

The basic calculation

Start with three numbers: number of devices, average monthly data per device, and cost per megabyte. Multiply them together and you have your baseline monthly cost. For a fleet of 500 GPS trackers using 8 MB each at £0.02 per MB, that is 500 × 8 × £0.02 = £80 per month, or £960 per year.

Simple enough. But that calculation misses several cost factors that become significant at scale.

Hidden cost factors

• Overage charges. If any device exceeds its individual allocation (without pooling), overage rates are typically three to ten times the in-bundle rate. Even a small number of devices going over can double your monthly bill. Pooling eliminates this risk almost entirely.
• SIM management time. Every hour your operations team spends managing SIMs, chasing overages, calling carriers, or manually activating and suspending SIMs is a cost. At scale, this can easily exceed the cost of the data itself.
• Minimum contract terms. Many IoT SIM providers require 12 or 24-month minimum commitments. If your deployment timeline is uncertain, or you expect to decommission devices partway through the contract, those commitments become a liability.
• Downtime costs. This is the cost nobody puts in the spreadsheet but everybody pays. When a SIM loses connectivity because the single carrier it relies on has an outage, the cost is not the data plan refund. The cost is the missed alarm, the lost telemetry data, the truck roll to investigate, the SLA penalty. Multi-network SIM has a higher per-SIM cost than the cheapest single-network alternative, but the avoidance of downtime events often pays for the premium many times over.
• Firmware update data. Budget for periodic firmware updates across your fleet. A 10 MB update pushed to 1,000 devices uses 10 GB. That needs to be in your data plan, or you need a strategy for staggered rollouts across billing periods.

Total cost of ownership over five years

IoT devices have long lifetimes. A five-year TCO calculation for connectivity should include: SIM procurement (typically a one-off cost per SIM), monthly data charges, platform access fees (for management portals and APIs), any minimum commitment obligations, estimated overage costs based on usage variability, and the cost of your team's time managing the connectivity layer. When you run the numbers properly, the cheapest per-megabyte SIM is often not the cheapest overall solution.

Common Mistakes in IoT Connectivity Procurement

Over the years, we have seen the same mistakes made repeatedly. Some are expensive. Some are project-ending. All are avoidable.

Mistake 1: Buying consumer SIMs for IoT devices

Consumer SIMs are cheap and readily available, which makes them tempting. But consumer SIMs are designed for phones. They have fair usage policies that restrict tethering, throttle data after a certain threshold, and sometimes block non-handset traffic entirely. Some carriers actively detect and disconnect SIMs that appear to be in IoT devices rather than phones. Your deployment works fine for three months, then the carrier's fraud detection system flags it and kills the connections across your fleet. Use SIMs that are designed and rated for M2M use from the start.

Mistake 2: Choosing a carrier based on coverage maps

Carrier coverage maps show theoretical outdoor coverage based on signal propagation models. They are useful for getting a rough idea of which carriers operate in a given area. They are nearly useless for predicting whether a specific device in a specific location will get a usable signal. The only way to know for sure is to test at the deployment site, ideally with the actual device and antenna configuration you plan to use. Or, use a multi-network SIM and let the device find the best carrier on its own.

Mistake 3: Ignoring data variability

Taking the average data usage from a pilot of ten devices and multiplying by a thousand will give you a number, but it will not give you an accurate number. Usage variability increases with fleet size. At a thousand devices, you will have outliers that use five or ten times the average. Without pooling, those outliers generate expensive overages. Without per-SIM caps, a single malfunctioning device can consume gigabytes in a day.

Mistake 4: No remote management capability

If you cannot remotely activate, suspend, and monitor your SIMs, you are going to spend a lot of time on the phone to carrier support desks. At ten SIMs, this is annoying. At a thousand SIMs, it is unsustainable. Insist on a management portal and API access from day one, even if you think you will not need it.

Mistake 5: Forgetting about the network sunset

If your IoT device uses a 2G or 3G modem, it has a finite operational life that is not determined by the hardware but by the carrier's network roadmap. 3G is being switched off now. 2G has a reprieve in some countries but not indefinitely. If you are deploying new devices today, use 4G Cat-1 or Cat-M1 modems at a minimum. If you are deploying devices with a ten-year expected life, consider devices that support firmware-upgradeable radio modules, so you can transition to 5G when the time comes.

Mistake 6: No consideration for security

Putting IoT devices on the public internet with nothing more than a username and password is a recipe for compromise. Many IoT devices have default credentials, known vulnerabilities, and no automatic update mechanism. Use a private APN to keep them off the public internet entirely, or at minimum route all traffic through a VPN. The additional cost of a private APN is trivial compared to the cost of a security breach involving your operational technology.

Mistake 7: Procuring connectivity separately from hardware

The SIM and the router or modem are not independent purchasing decisions. They interact. The SIM's supported carriers need to match the modem's supported frequency bands. The data plan needs to work with the router's failover logic. The APN configuration needs to be compatible with the device's firmware. Buying hardware from one vendor and SIMs from another without verifying compatibility is a common source of deployment delays. When you source Alchemy SIM alongside Peplink hardware, compatibility is guaranteed because we configure and test both together.

Choosing the Right Plan: A Decision Framework

Given everything above, here is a practical framework for selecting the right Alchemy SIM data plan for your IoT or M2M deployment.

1. Categorise your devices by use case. Do not treat a mixed fleet as a single procurement. CCTV cameras and GPS trackers need different plans. Group devices that have similar data consumption profiles.
2. Measure actual data usage from a pilot. Deploy ten to twenty devices in representative locations for at least one full month. Measure per-device usage daily. Note the minimum, maximum and average. Note any anomalous spikes and understand what caused them.
3. Size your pool at 130 per cent of expected average usage. The 30 per cent headroom accommodates natural variability, firmware updates, and unexpected spikes. If your pilot shows high variability, increase the headroom to 150 per cent.
4. Set per-SIM data caps. Even with pooling, set a cap on individual SIMs to prevent a single malfunctioning device from consuming the entire pool. Set the cap at three to five times the expected average per-device usage.
5. Use multi-network SIM unless you have a compelling reason not to. The per-SIM cost premium is typically 10 to 30 per cent over the cheapest single-network alternative. The reduction in coverage failures and carrier outage risk is worth that premium for almost every deployment.
6. Evaluate private APN for any deployment involving sensitive data, critical infrastructure, or devices that cannot be patched regularly. The additional cost is modest. The security improvement is substantial.
7. Plan for five-year TCO, not monthly cost. The cheapest SIM today is not necessarily the cheapest over the life of the deployment when you factor in overages, management time, downtime costs, and carrier migration risks.

Getting Started

If you are planning an IoT or M2M deployment and want to get the connectivity right from the start, talk to us. We can provide Alchemy SIM trial packs for pilot deployments, advise on data plan sizing based on your specific use case, configure Peplink hardware to work with Alchemy SIM out of the box, and set up private APN and VPN infrastructure for secure deployments.

We also supply the full range of Peplink routers suitable for IoT gateway applications, from the compact MAX BR1 for single remote sites to the Balance range for central aggregation. Everything is pre-configured and tested before it ships.

IoT connectivity is not glamorous. Nobody wins an innovation award for choosing the right SIM. But the wrong SIM will quietly undermine your entire deployment, and by the time you notice, the cost of fixing it in the field will dwarf the cost of getting it right at the start.