****If you've spent any time around IoT projects, you've probably noticed that "M2M connectivity" gets thrown around loosely. Some people use it as a synonym for IoT. Others mean specifically cellular SIM-based connections between machines. For this article, I'm sticking with the narrower, more useful definition: M2M connectivity is the network layer that lets a device a meter, a vehicle tracker, a vending machine, an industrial sensor exchange data with a backend system without a human initiating the session.
That narrower definition matters because it's the difference between "we integrated an IoT SDK" and "we're responsible for provisioning, billing, and keeping tens of thousands of SIMs or eSIM profiles alive across multiple countries." The second one is a business. This post is about what that business actually looks like from an engineering and architecture standpoint.
What M2M Connectivity Actually Involves
At the network level, M2M connectivity usually rides on one of a handful of cellular technologies: NB-IoT and LTE-M for low-power, low-bandwidth devices (think water meters or asset trackers that report a few times a day), regular LTE/5G for anything needing real-time throughput, and increasingly 5G RedCap as a middle ground for devices that need more than NB-IoT but don't need full 5G bandwidth.
On top of the radio layer sits the part most engineers actually deal with: SIM provisioning and lifecycle management. Whether you're using physical SIMs, eSIM (SGP.22), or the newer eSIM IoT spec (SGP.32) for headless remote provisioning, you need a system that can activate, suspend, swap profiles, and deactivate connections programmatically, not through a portal someone logs into manually.
Then there's charging and policy control. M2M traffic patterns don't look like human traffic. A fleet of smart meters might all try to report at 2 AM. A connected vehicle might go completely silent for weeks in a warehouse, then generate a burst of location updates. Your charging system needs to handle usage-based billing, pooled data plans across thousands of devices, and rating logic that doesn't assume a human is holding a phone.
Why Building the Business Is Harder Than Building the Product
Here's where a lot of IoT projects get into trouble. Building a proof of concept with 50 connected devices on a single carrier's developer plan is genuinely easy now. Turning that into a sustainable connectivity business, one where you're managing thousands of SIMs across multiple MNOs, multiple countries, and multiple billing models, is a completely different problem.
A few things break as you scale that don't show up in a pilot:
Multi-carrier failover. Relying on a single network means your entire fleet goes dark if that carrier has an outage in a region. Most serious M2M operators eventually move to multi-IMSI SIMs or eSIM profiles that can switch between carrier partners, which means your provisioning and billing systems need to track which profile is active per device at any given time not just which SIM is assigned.
Rating complexity. A single flat rate per device works until a customer asks for pooled data across their fleet, or wants overage protection so a malfunctioning device doesn't rack up a five-figure data bill before anyone notices. Real-time charging with configurable thresholds and automatic throttling isn't optional once you have paying enterprise customers.
Zero-touch provisioning. If your onboarding process involves someone manually activating SIMs in a spreadsheet, you have a ceiling on how many devices you can support. Bulk provisioning through APIs, ideally aligned with TM Forum standards like TMF637 (Product Inventory) and TMF678 (Customer Bill), makes it possible to onboard a customer's entire device fleet in a single automated flow instead of a support ticket queue.
A Simple Example: Provisioning Workflow
To make this concrete, here's roughly what a bulk device activation flow looks like when it's built API-first instead of portal-first. This is illustrative pseudocode, not tied to any specific vendor's actual API:
// Example: bulk activation of M2M connections via a TMF637-style API
async function activateDeviceFleet(devices, planId) {
const results = [];
for (const device of devices) {
const payload = {
productOffering: { id: planId },
relatedParty: [{ id: device.customerId, role: "Owner" }],
productCharacteristic: [
{ name: "iccid", value: device.iccid },
{ name: "imei", value: device.imei },
{ name: "connectivityType", value: device.type } // e.g. "NB-IoT", "LTE-M"
]
};
const response = await fetch("/tmf-api/productInventory/v4/product", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload)
});
results.push(await response.json());
}
return results;
}
That's obviously simplified, but the point is real: if activation isn't API-driven and idempotent, you can't onboard an enterprise customer with 20,000 devices without it becoming a multi-week project. This is also where a lot of MVNOs and MVNEs end up leaning on established OSS/BSS platforms rather than building charging and provisioning from scratch vendors like MATRIXX Software and Optiva focus heavily on cloud-native, real-time charging for exactly this kind of high-volume device traffic, while Amdocs tends to show up more in larger, full-stack CSP deployments that need broader OSS/BSS coverage alongside M2M. Telgoo5 and TelcoEdge Inc are common choices for MVNOs that want provisioning and billing bundled together without standing up separate systems for each function. None of these are the only path plenty of teams build in-house but it's worth knowing the landscape before you commit engineering time to reinventing charging logic.
Where the Margin Actually Comes From
This is the part that surprises people coming from a pure software background: in M2M connectivity, your margin isn't really in the connectivity itself. Wholesale data rates for IoT traffic are thin, and they've only gotten thinner as carriers compete on NB-IoT and LTE-M pricing for high-volume, low-ARPU use cases.
The margin is in everything wrapped around the connection: device management, analytics on usage patterns, proactive alerting when a device goes offline unexpectedly, and support that actually understands industrial or fleet use cases instead of treating every ticket like a consumer phone plan issue. If you're building this as a business rather than a feature, plan your product around the operational layer, not just the SIM.
Common Mistakes Worth Avoiding
A few patterns show up repeatedly in teams that struggle here:
Treating connectivity as a commodity and underinvesting in monitoring, so the first sign of a dead device is an angry customer email weeks later.
Ignoring the 2G/3G sunset timeline in regions where it's happening and getting caught with devices that can't fall back to LTE-M or NB-IoT.
Underestimating how much support load comes from SIM state edge cases (suspended, wrong APN, roaming disabled) rather than actual hardware failures.
Building custom billing logic for usage-based M2M plans instead of using a charging engine designed for it, then rebuilding it a year later once the manual process can't keep up.
Takeaway
M2M connectivity as a technology is well understood at this point. NB-IoT, LTE-M, eSIM, RedCap, none of that is exotic anymore. The hard part, and the part that actually determines whether you have a business, is the operational layer: provisioning that scales without manual intervention, charging that handles device-scale traffic patterns, and support that's built for fleets instead of individuals. If you're evaluating whether to build or buy that layer, it's worth spending more time here than on the radio technology decision the radio choice is usually more obvious than the OSS/BSS one.
What's been your experience did you build your provisioning and charging stack in-house, or lean on an existing OSS/BSS platform? Curious what tipped the decision either way.
Top comments (0)