Stop trusting the map. Start trusting the device.

The coverage map showed full bars. You deployed 300 devices. Half of them couldn’t connect. If you’ve been through this once, you don’t want to go through it again. If you haven’t — this article is how you avoid it.

Why Coverage Maps Are Built for the Wrong Device

Carrier coverage maps are not dishonest. They’re just optimized for a different device than yours.

The data behind them is collected from handsets held at roughly head height, outdoors, moving through streets and roads. Signal models are then extrapolated to fill in the areas between measurement points. The result is an accurate picture of whether someone standing outside at an intersection can make a phone call. It is not a reliable picture of whether your device, in its actual enclosure, at its actual mounting location, can maintain a stable data session.

IoT devices defy almost every assumption built into that model. They sit in locked metal utility boxes where RF signal loses 10–20 dB passing through the enclosure walls. They’re bolted to concrete ceilings in parking structures, buried in equipment racks, mounted on rooftops in areas that appear geographically covered but sit on the wrong side of a ridge. They don’t move, so they can’t self-correct by drifting toward a better signal. And they don’t have a user who notices when something is wrong.

A coverage map that reads “excellent” in your deployment area may be completely accurate for the carrier’s test methodology and completely useless for your use case.

The Indoor Penetration Problem

This is where most deployments get surprised. Coverage that looks solid outdoors can be significantly weaker inside a metal utility box, behind reinforced concrete, or in a basement equipment room.

Signal attenuation varies by construction material. Wood-frame interiors cause modest loss. Concrete floors and walls cause significant loss. Metal enclosures cause severe loss. A device inside a steel meter cabinet in an area shown as “good coverage” may be operating with a signal that would cause frequent disconnections or prevent registration entirely.

The penetration problem compounds with frequency band selection. Higher frequency bands (like many 5G bands) penetrate building materials less effectively than lower frequency bands. CAT-M and NB-IoT operate on low-band spectrum specifically to improve penetration and range, which is part of why they’re designed for IoT. But even within CAT-M coverage, whether a specific tower supports CAT-M on its low-band carriers matters, and coverage maps often don’t distinguish between LTE coverage and CAT-M availability on a tower-by-tower basis.

What Signal Metrics to Measure — and What They Mean

Coverage maps give you a qualitative picture. Field testing gives you numbers. The three that matter for LTE-based IoT connectivity are RSSI, RSRQ, and SINR.

RSSI (Received Signal Strength Indicator) is total received signal power including interference and noise. It’s a reasonable proxy for whether a signal exists, but not for whether it’s usable. A location can have a strong RSSI and still have poor throughput if the interference level is high.

RSRQ (Reference Signal Received Quality) measures signal quality relative to total noise. It’s more diagnostic than RSSI. For most IoT applications, an RSRQ above -12 dB indicates reliable operation. Below -15 dB, expect intermittent connectivity.

SINR (Signal-to-Interference-plus-Noise Ratio) is the clearest indicator of data throughput potential. Above 12 dB is good for IoT. Between 3 and 12 is acceptable. Below 3 dB, and you’re likely to see frequent retransmissions and latency spikes.

These values are readable via AT commands on most IoT modules. On Quectel modules, AT+QCSQ returns the relevant values. On Sierra Wireless, AT!GSMINFO. On Telit, AT#MONI. If you don’t know the AT command for your module, the manufacturer’s AT command reference has it. Most field engineers use a laptop, USB-to-serial adapter, and a terminal application for this during site surveys.

The Multi-Carrier Advantage in Coverage Testing

This is where the SIM you use for testing changes what you learn.

If you test with a single-carrier SIM, you’re learning whether one carrier performs adequately at your deployment locations. If that carrier has a bad tower or an outage six months from now, you’ll find out when your devices go offline.

Testing with a multi-carrier SIM tells you the best available signal at each location across all the carriers the SIM can access. You’re testing the ceiling of what’s available, not one carrier’s floor. At locations where multi-carrier coverage is excellent, you have genuine redundancy. At locations where even multi-carrier coverage is marginal, you’ve identified a deployment risk before you’ve committed hardware.

A trial SIM from your intended provider is the right tool for site surveys. Most quality IoT SIM providers will send trial SIMs before a deployment commitment. If a provider requires volume commitment before you can test, that’s worth noting.

Four Edge Cases That Fool Coverage Maps

Understanding how carrier selection and multi-carrier networks actually work helps you anticipate where maps mislead. These four cases account for a large share of surprise failures in the field.

How to Sample Before You Scale

Full pre-deployment coverage testing across every location isn’t always feasible. For large deployments, a sampling approach is both practical and effective.

Test 5–10% of planned deployment locations before committing the fleet. Choose the sample to represent the range of conditions your deployment will encounter: rural and urban locations, indoor and outdoor, above-grade and below-grade, high-rise and ground-floor. If your deployment spans multiple regions, sample from each region.

At each sampled location, run the device for at least 24 hours of active connectivity and log the signal metrics and connection stability. You’re looking for two things: locations where average RSRQ is consistently below -15 dB (marginal coverage), and locations where the device drops and reconnects more than two or three times per day without obvious cause.

For large-scale deployments, sampling 5–10% before committing hardware catches coverage gaps that would otherwise require truck rolls to fix. The cost of 30 site visits is far lower than the cost of dispatching field technicians to 300 under-performing devices.

If your sampled locations show consistently strong RSRQ and SINR, you can deploy the remaining locations with reasonable confidence. If sampled locations cluster into “strong,” “marginal,” and “no-go” categories, you have the data to make site-specific decisions rather than a fleet-wide gamble.

What to Do When Coverage Is Marginal

Not every deployment location can be fixed by switching carriers. When field testing identifies a genuinely marginal site, you have three options worth considering.

The first is antenna optimization. External antennas mounted outside an enclosure, oriented toward the dominant tower, can recover 6–12 dB of signal in many installations. For fixed devices in permanent locations, an external antenna is often a cost-effective fix for marginal indoor coverage. Verify the antenna gain and connector type match your module’s specifications before purchasing.

The second is technology selection. If LTE coverage at a location is marginal, CAT-M may perform better because it operates on lower-band spectrum with better penetration characteristics, even if the LTE coverage map shows the same geographic footprint. Testing both technologies at a marginal location takes 20 minutes and may resolve the issue entirely.

The third is accepting the location as a known risk and planning accordingly. For non-critical monitoring devices, a site with occasional connectivity gaps may be acceptable if the data model can tolerate it. For safety-critical or revenue-generating devices, marginal coverage is a deployment blocker, not a deployment risk.

The right answer depends on what the device does and what the cost of a failed connection is. For a deep dive on quantifying that cost, the real cost of IoT connectivity failures post in this series covers the business-case math.

How Simplex Supports Coverage Validation

Simplex SIMs give you access to 500+ networks in 191 countries, including tier-1 carriers across North America. That coverage depth means you’re testing against the best available network at each location, not a single carrier’s footprint.

For pre-deployment validation, Simplex ships trial SIMs without unnecessary registration requirements. The SIM that goes into your test device is the same SIM you’ll deploy into production. There’s no APN change, no configuration difference, no gap between what you tested and what you deployed.

Once your fleet is live, the Simplex management portal gives you per-device signal and connectivity visibility. Devices that are struggling show up before they become support tickets. That’s the difference between a fleet you manage proactively and one you respond to reactively.

Coverage maps will keep being built for consumer handsets. That’s fine. Your job is to test for your device, in your enclosure, at your installation location. The tools to do that are straightforward. Use them before you deploy, not after.

Request a trial SIM at simplexwireless.com/iot-data-sim and test your actual deployment conditions before you commit the fleet.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post Coverage Maps Lie: How to Actually Verify IoT Cellular Coverage Before You Deploy first appeared on Simplex Wireless.

The SGP.32 (GSMA specification for IoT eSIM remote provisioning) spec is detailed enough that two implementations can each be technically compliant and still fail to work together. The reason is implementation variance — the parts of the spec where vendors make legitimate but different choices about encoding, session handling, or interface behavior. An eIM (eSIM IoT Manager — the server that orchestrates remote profile management for IoT devices) that has only been tested against a single eUICC (embedded SIM chip) manufacturer carries unknown risk for every other chip family it encounters in the field. That risk doesn’t announce itself. It shows up as a profile download that hangs, a session that times out for no apparent reason, or a rollback that doesn’t complete.

Testing against multiple eUICC manufacturers isn’t a quality bonus. It’s the evidence that the eIM actually works.

What Interoperability Testing Involves

The SGP.32 spec defines the interfaces, the message formats, and the state machine that governs how an eIM and an eUICC communicate during a profile operation. What it doesn’t fully standardize is every implementation decision a chip vendor makes within that framework.

An eUICC manufacturer — or EUM, such as Kigen (ARM), ST Microelectronics, or VALID — implements the eUICC’s firmware, its IPA (IoT Profile Assistant) client, and the behavior of the IPAe interface (the interface between the eIM and the SIM-side IPA). Those implementations are compliant with the spec, but they’re not identical. They differ in:

Encoding choices. SGP.32 permits both ASN.1 and JSON message encoding. An eIM that only generates ASN.1 messages will fail against an eUICC that expects JSON. An eIM that generates both, and handles both in responses, works with either.

Session timing and retry behavior. The spec allows for variation in how quickly an eUICC expects an acknowledgment after initiating a BIP (Bearer Independent Protocol) channel. A tight timeout on one chip may cause session failures on an eIM with slightly delayed responses — not a bug in either system individually, but a gap between them.

Profile download state handling. The sequence of states an eUICC moves through during a profile download — from notification to download to enable — can proceed at different speeds depending on the chip’s internal scheduler. An eIM that assumes uniform state transition timing may send the next command before the eUICC is ready to receive it.

Error reporting format. When something goes wrong mid-operation, different eUICC implementations encode error responses differently within the spec’s allowed range. An eIM that hasn’t been tested against a given chip’s error format may fail to parse the response correctly, causing a silent failure instead of a recoverable error.

Interoperability testing surfaces all of these. It requires running actual profile operations — push, enable, disable, delete, rollback — against each chip family, observing failures, and updating the eIM’s handling until operations complete reliably across all tested variants.

Why Compliance Doesn’t Equal Compatibility

This is the part that surprises buyers who assume GSMA certification is a sufficient guarantee. It isn’t — and not because certification is worthless. It’s because certification tests conformance to the spec, not interoperability with every other implementation of the spec.

The consumer eSIM world (SGP.22) had a long period where certified devices and certified SM-DP+ servers failed to work together in ways that weren’t caught until field deployment. SGP.32 is a newer spec, the implementation surface is larger, and the device ecosystem is significantly more fragmented. The conditions for hidden incompatibilities are better, not worse, than in the consumer case.

The practical implication: an eIM vendor that says “we’re SGP.32 compliant” without being able to name the specific eUICC families they’ve tested against is giving you a necessary but insufficient answer. Compliance tells you they’ve implemented the spec. It doesn’t tell you whether their implementation works with the chip inside your device.

As Simplex’s own SGP.32 implementation journey documents, building a carrier-grade eIM requires supporting multiple communication stacks — both normal and compact — as well as both IPAe and IPAd approaches, because the spec allows variation and the real device ecosystem exercises that variation. An eIM that was built against one chip vendor’s reference implementation and never tested further carries implementation assumptions that may not hold elsewhere.

The Four Variables That Break Untested Implementations

Four specific areas of the SGP.32 spec contain enough implementation latitude that an eIM that hasn’t been tested across chip families is likely to have hidden fragility in at least one of them.

What Simplex Has Tested — and Why It Matters

Simplex has completed interoperability testing with Kigen (ARM), ST Microelectronics, and VALID — three of the major eUICC manufacturers. Each test covered the full profile operation lifecycle across both IPAe and IPAd approaches, both ASN.1 and JSON encoding, and both normal and compact communications stacks.

This testing isn’t a marketing claim. It’s the output of building an eIM from scratch with a team that spent 30 years building carrier-grade platforms for tier-1 mobile operators — systems that process tens of thousands of transactions per second with the fault tolerance and operational maturity that entails. As the SGP.32 lessons learned post details, the spec demands predictable, fault-tolerant communication between the eIM, the eUICC, and the IPA. Building for that kind of reliability is not compatible with single-vendor testing assumptions.

The practical consequence is straightforward: if your device uses a Kigen, ST Micro, or VALID eUICC, Simplex’s eIM has been verified to work with it. Not assumed — verified. For the IPAe turnkey SIM approach, where Simplex ships the eUICC-enabled SIM card alongside eIM access, the whole stack is tested end-to-end before it ships. The BIP/STK enablement requirements for each tested modem are documented publicly, so integration teams aren’t starting from scratch.

Simplex is also not an EUM. That neutrality matters: chip manufacturers benefit from testing against an eIM they don’t control, because it validates their own implementation. Simplex’s independence makes it a useful testing partner, not a competing vendor. That’s how testing relationships with multiple EUMs become possible in the first place.

What to Ask Before You Commit to an eIM Provider

When you’re evaluating eIM vendors, interoperability testing history is one of the most revealing questions you can ask — because it’s one of the hardest to fake. “We’re SGP.32 compliant” is a minimum bar. The better questions are:

Which eUICC manufacturers have you tested against? Can you name them specifically, and confirm that testing covered the full profile lifecycle?

What encoding formats does your eIM support — ASN.1, JSON, or both?

Have you tested both IPAe and IPAd approaches? What modems and chipsets have you validated for each?

What happens when a profile operation fails mid-sequence? Does the device recover automatically, and has that recovery been tested on the eUICC families you support?

Is your eIM built in-house or based on third-party software? If third-party, who owns the testing relationship with EUMs?

Honest answers to these questions tell you whether an eIM vendor has done the work or is relying on spec compliance to carry a conversation they haven’t actually had in hardware.

Where Untested Implementations Fail in the Field

The failure modes aren’t always dramatic. A profile push that works in a lab environment on the vendor’s reference chip may fail intermittently in production on a different chip family, under different network conditions, or after a firmware update on the modem changes the BIP session timing.

The practical consequences range from inconvenient to operationally serious. A failed profile download that recovers cleanly costs a retry. A failed profile download that leaves the device stranded on a profile it can’t use — because rollback wasn’t tested and doesn’t work — costs a truck roll. At fleet scale, that calculus changes fast.

The xoSIM turnkey approach is partly designed around this problem: shipping the eUICC and the eIM from the same vendor means the combination has been tested together before it reaches a customer’s device. That doesn’t mean every possible integration scenario is covered, but it eliminates the most common source of interoperability unknowns.

For teams bringing their own eUICC and evaluating Simplex’s eIM standalone, the Works With Simplex program provides a documented compatibility list of validated modems and chip combinations. If your hardware is on the list, you have a tested baseline. If it isn’t, that’s a test worth running before deployment, not after.

The spec is the floor. Interoperability testing is what separates a platform that works on the spec from one that works in your fleet. If you’re evaluating eIM providers, ask to see the testing receipts — and if they can’t produce them, factor that into your assessment.

Explore Simplex’s eIM platform and see which eUICC families we’ve tested at simplexwireless.com/xosim.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post Why Interoperability Testing With Multiple eUICCs Matters first appeared on Simplex Wireless.

You know your fleet is generating data. The problem is what it takes to get at it.

A vehicle goes dark in Ohio. A device in a refrigerated trailer shows an unusual session termination. Three trackers in the southeast haven’t reported in six hours. These aren’t hypotheticals — they’re the kind of events fleet operations teams deal with every shift. And in every case, the first obstacle isn’t fixing the problem. It’s finding out what’s actually happening.

The Connectivity Challenge Fleet Operations Actually Faces

Fleet connectivity is not a static problem. Vehicles cross carrier coverage boundaries constantly. A tracker that was on T-Mobile US in Atlanta may hand off to a different operator by the time it reaches rural Tennessee. Devices that were healthy yesterday may show session anomalies today tied to a carrier behavior change you didn’t trigger and weren’t notified about.

At the same time, the questions fleet ops teams ask are operational and immediate. Which devices are active right now? Which ones dropped a session in the last four hours and why? Is the data consumption on this vehicle normal for its route? Which carrier is it on, and is that carrier supporting LTE (Long-Term Evolution) in that region?

These aren’t complex analytical questions. They’re basic situational awareness. But answering them requires navigating a management portal that was designed for configuration and control, not rapid-fire operational queries. GPS asset trackers across fleet, logistics, and construction verticals all share this constraint: the connectivity layer generates rich session data, but surfacing it quickly enough to be operationally useful requires either deep platform knowledge or a faster interface.

Most fleet teams have neither.

Why This Problem Is More Acute in Fleet Than Other IoT Verticals

A smart meter sitting in a fixed location generates predictable session behavior. If something goes wrong, the failure mode is usually binary — it’s connected or it isn’t — and the timeline for response is measured in hours or days.

Fleet devices don’t behave that way. They’re mobile, they cross coverage zones, and the session patterns are inherently variable because the devices themselves are in motion. A termination cause of “Admin-Reset” on a stationary sensor is worth investigating. The same cause on a vehicle tracker that just crossed a state line may be completely normal.

This means fleet ops teams need context alongside data. Not just “this session ended” but “this session ended, here’s the carrier, here’s the cell tower, here’s how it compares to the last 30 days of behavior for this device.” Deploying cellular connectivity across a fleet is the first challenge. Understanding what that fleet is doing in production, at scale, across multiple carriers, is the ongoing one.

The standard management portal gives you the data. It doesn’t give you the context fast enough to act on it during a shift.

What the Right Visibility Layer Looks Like for Fleet Teams

Fleet operations teams don’t need more data. They need faster access to the data they already have. The right visibility layer for a connected fleet has three characteristics.

First, it answers questions in plain language. “How many devices are active in Florida right now” and “which tracker used the most data this week” should not require a filter, a report, or a portal walkthrough. These are operational questions that get asked multiple times a day. The interface should match how the team actually works.

Second, it surfaces anomalies before they become incidents. Unusual traffic spikes, drop-rate changes, and session termination pattern shifts should be flagged automatically — not discovered during a manual review. Selecting the right cellular IoT SIM provider for fleet tracking is part of avoiding these problems at the infrastructure level. But an intelligent visibility layer catches what configuration alone can’t prevent.

Third, it gives every team member access, not just the person who knows the platform. Network ops, customer support, dispatchers, and management all need to answer connectivity questions. If only one person can pull that data effectively, every connectivity question becomes a dependency on that person.

How SimplexAI Works for Fleet Operations

SimplexAI is built into the Simplex platform and answers operational questions in plain English — no SQL, no BI tools, no specialist knowledge of the portal required.

For fleet teams specifically, it means a dispatcher can ask “which devices are active in Texas right now” and get an immediate answer. A support rep can ask “what did the last session for this tracker look like” and see the carrier, the cell tower, the termination cause, and the data consumed — without opening a separate view. A manager can ask “which SIM used the most data last week” and have the answer before the conversation ends.

Historical session data goes back 30 days and is fully queryable. Carrier coverage intelligence across 100+ operators worldwide is built in, so questions like “does AT&T support LTE-M on this route” get answered directly. For fleets already using eSIM (eUICC) across multiple carrier profiles, SimplexAI surfaces which profile is active on any device at any time.

The data your fleet generates every day doesn’t change. The time it takes your team to act on it does.

See how Simplex serves connected fleet operations — and try SimplexAI in your account today.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post Why Fleet Operations Teams Spend More Time Finding IoT Data Than Acting On It first appeared on Simplex Wireless.

The data is there. The problem is everything between the question and the answer.

A device stops reporting. A carrier changes behavior. Data consumption on one SIM jumps overnight. You know the event happened — your devices are generating session records, usage logs, and connection timestamps constantly. What you don’t have is a fast path from “something’s wrong” to “here’s what’s happening and why.”

That gap is what this piece is about.

What “Getting an Answer” Actually Involves Today

Ask most IoT teams how they’d answer a question like “how many devices are currently active in Germany” and you’ll get a version of the same workflow: open the portal, find the right filter, set the time window, wait for the report to load, export to a spreadsheet if the numbers need to go somewhere, and then interpret what you’re looking at.

That’s on a good day, when you know exactly where to look. For less routine questions — which devices are showing unusual session termination patterns, what the trend looks like across the last 30 days by time of day, which carrier is accounting for the anomaly — the path gets longer. You might open multiple views. You might pull data from different parts of the platform. You might ask someone who knows the portal better than you do.

The underlying data hasn’t changed. The session records, the APN assignments, the carrier connections, the data volumes — all of it is there. What’s missing is the ability to ask a direct question and get a direct answer, without the interface becoming the obstacle.

Understanding what a well-structured IoT APN configuration looks like helps — but even with a clean setup, the visibility layer sitting above it hasn’t kept pace with the questions operators actually ask in production.

Why IoT Makes This Harder Than Regular IT Visibility

Enterprise IT visibility tools work reasonably well because the assets are stable: servers, laptops, network appliances. The inventory changes slowly. The monitoring layer has time to mature alongside the infrastructure.

IoT fleets don’t behave that way. A fleet of a few hundred SIM-connected devices generates session data continuously, across multiple carriers, across multiple countries, often with variable connection patterns tied to the physical behavior of the device itself — a tracker that only connects when a vehicle is moving, a sensor that only transmits at the top of the hour. The visibility problem isn’t just volume. It’s that the data is inherently multi-dimensional, and the questions you need to ask of it change depending on what’s happening in the field.

Choosing the right SIM and cellular strategy accounts for the deployment side. But operational visibility — knowing what your fleet is doing right now, which devices are behaving differently than they were yesterday, which carrier is responsible for a connectivity dip — is a separate problem that sits on top of the connectivity layer.

Most management portals were built to let you configure and control your fleet. They weren’t built to answer operational questions quickly. That distinction matters more as fleets grow.

What Goes Wrong When Visibility Is Slow

The most common failure mode isn’t a single device going offline. It’s a pattern that develops over hours or days that nobody catches until a customer reports a problem.

A traffic spike that starts small looks like noise. By the time it’s clearly anomalous, it’s already affected sessions across multiple devices. If spotting that pattern requires a manual check — opening a specific view, running a report, comparing against a baseline you had to build yourself — the window between “something is changing” and “we know about it” stays wide.

Data overages follow the same logic. Right-sizing your IoT connectivity plan requires knowing what your devices actually consume. If you can only answer that question in aggregate, or by pulling device-level reports manually, you’ll consistently find out about outliers after they’ve already cost you. The device consuming ten times what it should have been was generating that data the whole time — it just wasn’t visible.

Support escalations are the third failure mode. A field technician asks which carrier a device is on, what its last session showed, whether the termination cause was normal. If the answer requires a portal lookup by someone back at the office, that’s a delay baked into every support interaction. The information exists. The access path is the bottleneck.

Three Things That Close the Gap

1. Know what questions your team actually asks. Most operational questions are variations on a small set: what’s active, what’s consuming unusually high data, what changed recently, is a specific device behaving normally. If your platform can answer those questions directly, the visibility problem shrinks considerably. If it can’t, you’re building workarounds.

2. Treat anomaly detection as a requirement, not a feature. Waiting to be told something is wrong is reactive by design. A platform built for IoT fleet management should flag unusual traffic patterns automatically, without requiring you to build the baseline yourself or check manually on a schedule.

3. Make device-level data accessible to everyone who needs it. Network ops, customer support, and management ask different questions of the same fleet data. If answering those questions requires specialist knowledge of a portal interface, you’ve created a dependency. Access to session history, carrier status, and data consumption should require a question, not a training session.

That’s exactly what SimplexAI is built to do. Ask in plain English — “which SIM used the most data last week,” “are there any anomalies in the last 24 hours,” “what carrier is this device connected to right now” — and you get the answer directly, without navigating a dashboard or opening a report. Try SimplexAI in your Simplex account today.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post Your IoT Network Data Exists. Getting an Answer From It Shouldn’t Take This Long. first appeared on Simplex Wireless.

Ten questions that separate production-ready eIM platforms from pilot projects — and the answers that should disqualify a vendor before you sign anything.

The SGP.32 eIM market is early. That means buyers don’t have years of vendor track records to compare, analyst reports to benchmark against, or colleagues who’ve already been through a full procurement cycle. What most enterprises do instead is evaluate eIM providers the same way they evaluate any software vendor: demo, pricing, a few references. That framework misses the dimensions that actually matter for production IoT deployments.

An eIM (eSIM IoT Manager) is the server that manages profile operations — push, switch, delete — for every eUICC (embedded Universal Integrated Circuit Card) in your fleet. If it goes down, your remote provisioning goes down with it. If it’s not validated against your device’s chip, it may work in the lab and fail in the field. And if it’s bundled with your connectivity contract, you haven’t escaped carrier lock-in — you’ve moved it up one layer.

This checklist gives you the framework to evaluate eIM providers properly before you commit.

What to evaluate

The ten dimensions below determine whether an eIM platform is genuinely production-ready — or only looks that way in a demo.

Independence from connectivity. The most important structural question. An eIM sold or managed by your MNO gives that MNO leverage over your profile operations. If you can only switch to profiles the same provider controls, the freedom SGP.32 promises is theoretical. A genuinely independent eIM works with any carrier’s profiles — including ones you’ve sourced elsewhere.

EUM interoperability. EUMs (eUICC Manufacturers) — the companies that make the chips inside your SIM cards — implement the SGP.32 specification with variation. An eIM tested against one EUM’s chips is a pilot. An eIM tested and validated against multiple EUMs is a production platform. Ask for the specific chip families, not a generic “yes, we’re compatible.”

Interface and protocol coverage. SGP.32 supports two client interfaces (IPAe and IPAd), two profile management modes (Direct and Indirect), and two encoding formats (ASN.1 and JSON). Full coverage means the platform works with whatever hardware your fleet contains — now and as it evolves. Partial coverage means you’ll hit a ceiling at scale.

Scale and hosting model. What is the documented throughput ceiling — requests per second under load? And is the platform hosted on the vendor’s own infrastructure or on a public cloud? Private hosting matters for data security posture and SLA accountability. A platform processing hundreds of requests per second is a pilot platform; a production fleet needs carrier-grade throughput.

Commercial flexibility. Does the vendor offer both SaaS and licensed deployment models? Monthly and one-time fee options? Full API access alongside a portal? Lock-in can happen at the commercial layer too — if the only option is a long-term SaaS contract with one pricing tier, you’re constrained before you’ve provisioned a single device.

Support location and telco depth. Where is the support team? What are their SLA commitments in writing? And what is the vendor’s actual telecoms background — were they building carrier-grade platforms before SGP.32 existed, or did the spec create the company?

Three mistakes buyers make when evaluating eIM providers

Treating the eIM as a connectivity add-on. An enterprise asks their existing MNO whether they support SGP.32, the MNO says yes, and the deal gets done. What they’ve purchased is profile management that only works within that MNO’s ecosystem. The leverage SGP.32 was designed to create — the ability to switch carriers without a truck roll — disappears the moment your eIM and your connectivity come from the same vendor. You’ve traded physical SIM lock-in for management layer lock-in.

Accepting “SGP.32 compliant” without asking what that means. The specification covers a lot of ground. A vendor can claim compliance while supporting only IPAd (not IPAe), only Direct mode (not Indirect), only one EUM’s chips, and only ASN.1. Each gap is a constraint you’ll discover in production. Ask for the specific subset of the spec they’ve implemented and tested — and ask for evidence, not assurances.

Underweighting hosting and SLA accountability. When an eIM is hosted on a public cloud by a vendor who built on top of it, accountability for uptime is split. The vendor points at the cloud provider; the cloud provider has no SLA with you. If your profile operations depend on this platform, you need to know exactly who is responsible when it goes down — and whether that person has a direct line you can call.

How Simplex addresses each criterion

Independence from connectivity. The Simplex eIM operates independently from Simplex’s own connectivity offering. Customers can bring their own carrier contracts and use the eIM for profile management only — or use Simplex connectivity, or a mix of both. The platform has no commercial relationship with the profiles it manages. That independence is the product, not a feature of a connectivity bundle.

EUM interoperability. Simplex has validated its eIM against four EUM chip families, with Kigen (ARM), ST Microelectronics, and VALID publicly nameable. That breadth matters in production: whatever chip is inside your deployed devices, the platform has been tested against it. Most eIM vendors haven’t done this work because it requires genuine investment in interoperability testing — and most eIM vendors are either EUMs themselves or startups without the resources to run it.

Interface and protocol coverage. Simplex supports IPAe and IPAd, Direct and Indirect profile management, and both ASN.1 and JSON encodings. Full spec coverage means the platform adapts to your fleet — not the other way around.

Scale and hosting. The platform is hosted on bare metal infrastructure owned and operated by Simplex in Atlanta, Georgia — not on AWS, Azure, or GCP. Throughput is carrier-grade: the team that built this platform spent decades building and supporting mission-critical systems for Tier 1 operators. The SLA sits with Simplex directly, not a cloud provider SLA that Simplex passes through to you.

Commercial models. Simplex offers both SaaS (monthly fee, managed service) and licensed deployment (for enterprises that need to run the eIM inside their own infrastructure or white-label it). Both models include API access alongside the portal. One honest limitation: the licensing model is designed for larger enterprise deployments and may not be the right fit for smaller fleets in early evaluation — the SaaS tier is the right starting point for most.

Support and telco depth. The support team is in Alpharetta, Georgia. The founding team has over 30 years of carrier-grade telecom experience, including direct work with Tier 1 operators before SGP.32 existed. That background is the difference between a platform built by people who understand what production cellular infrastructure actually requires, and one built by people who learned the spec last year.

Questions to ask any eIM provider — including us

These aren’t the same questions as the criteria above restated. These are the follow-up questions — the ones to ask after a vendor has given you a confident answer on every dimension.

1. If your eIM platform goes offline for four hours, walk me through exactly what happens to in-flight profile operations — and how they recover.
2. Can you show me a profile switch running live against a device with a chip from an EUM you haven’t mentioned yet?
3. What percentage of your current customer base uses BYOO (Bring Your Own Operator) vs. Simplex connectivity — and why does that split look the way it does?
4. Has your platform ever failed an interoperability test with a specific eUICC implementation? What was the issue and how was it resolved?
5. If we license the platform and run it internally, what does the handoff of knowledge look like — and what breaks first when your team isn’t available?
6. What is the one thing about your eIM that your most technically demanding customer has pushed back on?

A provider who answers all six without deflecting has earned the next conversation.

Evaluating an eIM provider is ultimately a question of whether the platform can do what SGP.32 promises — at production scale, with your hardware, without creating a new form of the lock-in you were trying to escape. The checklist above won’t make the decision for you, but it will surface the gaps before they become production problems. Explore the xoSIM to see how Simplex approaches every one of these criteria in practice.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post How to Evaluate an eIM Provider: The Enterprise Checklist for SGP.32 Fleet Management first appeared on Simplex Wireless.

Most IoT SIM buying decisions are made on two criteria. There are six that actually matter.

A SIM card commitment for a large IoT deployment isn’t a monthly subscription you cancel if it doesn’t work out. Devices get shipped, APN configurations get hardcoded, and support teams get trained on one portal. Switching providers 18 months in — because the coverage turned out to be single-carrier in disguise, or the bill was impossible to audit, or support stopped responding after the sale — is an operational project nobody wants.

The providers who win on price comparisons and coverage maps aren’t necessarily the ones you’ll still want to be working with in year three. Price and coverage are two of six criteria that separate a reliable long-term partner from a vendor who looked good in a demo.

This guide gives you the framework to evaluate providers properly. The criteria are designed to be genuinely useful regardless of which vendor you’re looking at — including Simplex. A provider who meets all six is worth a conversation. A provider who struggles on any of them is worth a harder question.

What to evaluate

Coverage redundancy — not just country count. A coverage map that shows 191 countries tells you nothing about how many carriers are active per country, whether failover is automatic or manual, or whether the SIM has actually been tested in your deployment geography. The architecture that determines whether your devices will stay connected is which carriers are in the provider’s network and how the SIM behaves when one goes down — not the number on the brochure.

Pricing transparency — can you read the bill? Hidden fees, minimum revenue commitments, and surprise rounding are how IoT connectivity bills become unpredictable at scale. Before committing, ask to see a sample invoice for a fleet similar to yours. If it takes a sales call to explain what each line means, that’s the answer.

Portal and API capability. A dashboard that shows connection status is the baseline. A useful portal shows real-time data usage per device, triggers alerts when a device stops transmitting, surfaces anomalous usage that signals fraud or misconfiguration, and exposes an API so you can integrate fleet visibility into your own tooling. The difference between these two things is the difference between visibility and guesswork.

Support model — person or ticket queue? Where is support staffed, and what’s the realistic response time when something goes wrong at 2am? A support team in a different time zone that operates on tickets is a different product than a team you can call. Find out before you’re in an incident.

Contract terms — what’s the exit path? Revenue minimums, volume commitments, and lock-in periods are where providers recover the margin they gave away on the per-MB rate. Read the contract before signing and ask specifically: what do I owe if I reduce fleet size by 30% in year two?

Future-proofing — is there an eSIM path? Devices deployed today may run for five to ten years. A provider with no SGP.32 eSIM capability means any future carrier switch on those devices will require a physical SIM swap. That’s a truck roll problem you’re building into your fleet before you’ve shipped a single unit.

Three mistakes buyers make

Optimizing for the lowest per-MB rate. The per-MB rate is the most visible number in any comparison, and the least reliable predictor of total cost. A provider with a lower rate but a revenue minimum, a pooled plan that penalizes low-usage devices, or a billing model that rounds up to the nearest MB will cost more at scale than a provider with a slightly higher rate and no hidden structure. Model total cost against your actual usage distribution — not the per-MB headline.

Skipping coverage validation in actual deployment locations. A carrier’s coverage map shows theoretical signal boundaries — not device-level performance inside a steel enclosure in a basement, or under a bridge, or in a concrete utility vault. Validating with trial SIMs at your actual deployment locations before committing a full fleet is not optional for any deployment where downtime has a measurable cost. The cost of a trial is trivial compared to the cost of a failed deployment.

Ignoring support quality until the first outage. Support capability doesn’t reveal itself in a demo. It reveals itself at 11pm on a Tuesday when 15% of your fleet goes offline and you need an answer fast. Ask for a reference from a customer who had an incident — not a customer who had a smooth deployment. Those are different stories, and you need to hear both.

How Simplex addresses each criterion

Coverage redundancy. Simplex SIM cards access 550+ networks across 191 countries, with automatic multi-carrier failover — not steered roaming that routes through a single preferred carrier. In the US, that means AT&T, T-Mobile, and Verizon on a single SIM. Failover is a function of the SIM’s network access configuration, not a manual intervention. Trial SIMs are available to validate coverage before committing.

Pricing transparency. No activation fees, no platform fees, no revenue minimums, no contracts. Three plan models — PAYG, pooled, and prepaid — with published pricing. Postpaid plans (PAYG and pooled) have a 10-SIM minimum order; prepaid starts at a single SIM for testing. One honest note: Simplex’s online pricing is structured around self-serve enrollment, and very large deployments with complex custom requirements are better handled through a direct conversation with the sales team than through the standard pricing page.

Portal and API capability. The Simplex portal provides real-time usage monitoring per device, configurable alerts, anomaly detection, sub-accounts for fleet segmentation, and a full API for integration into external tooling. The portal is visible from day one — you don’t need to hit a device count threshold to access fleet visibility features.

Support model. Support is staffed in Alpharetta, Georgia. US business hours, direct access — not a global ticket queue with an offshore tier-one filter. The Livelox team referenced this specifically: when integration questions came up, Simplex’s support team responded with answers, not ticket numbers.

Contract terms. No contracts, no revenue minimums, no lock-in. Start with a single prepaid SIM for testing. Scale to a fleet without committing to a volume floor. Exit when you need to without an exit fee.

Future-proofing. Simplex’s xoSIM is an eUICC SIM card with on-SIM IPAe built in — meaning any device running a xoSIM can be upgraded to full SGP.32 eSIM management without a hardware swap. For fleets with a five-to-ten year device lifespan, that’s the difference between a carrier switch being a software operation and a truck roll.

Questions to put to any provider — including Simplex

These aren’t the criteria above restated as questions. These are the stress-test questions for after a vendor has given you a confident answer on every dimension.

1. If your primary carrier in our main deployment region has a four-hour outage tonight, walk me through exactly what happens to our devices — second by second.
2. Show me last month’s invoice for a fleet similar to ours in size and usage. Walk me through every line.
3. What happens to our SIM cards and device configurations if we decide to leave your platform in 18 months?
4. Give me a reference from a customer who had a connectivity incident — not just a smooth deployment. I want to hear what the support experience was actually like under pressure.
5. If we scale from 500 to 5,000 devices in two years, what changes in our pricing structure, our support tier, and our contract terms?
6. Your coverage map shows our deployment region as covered. Which specific carriers are active there, and have you tested device-level performance in that geography — not just theoretical signal boundaries?

A provider who answers all six directly has earned the next step.

Choosing an IoT SIM provider is a multi-year decision that compounds — in either direction. The right framework surfaces the gaps before they become production problems, and the right provider clears every bar without hedging. If you’re ready to put Simplex through the same checklist, explore our IoT SIM cards and request a trial SIM to test coverage in your actual deployment locations.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post How to Evaluate an IoT SIM Provider: A Due Diligence Guide for Multi-Year Deployments first appeared on Simplex Wireless.

SGP.32 gives you two paths for connecting devices to an eIM. One requires no changes to your deployed hardware. The other does. Here’s the practical difference.

When companies first hear about SGP.32, the question that comes up fastest isn’t “what can it do?” It’s “what do we have to change?” For most SMEs with hundreds or thousands of devices already in the field, that’s the right question.

The answer hinges on a specific design choice inside the SGP.32 specification: whether the IoT Profile Assistant (IPA) — the component that handles communication between the device and the eIM server — lives on the SIM card or on the device itself.

The two IPA approaches: where they live and what they require

SGP.32 defines two variants of the IoT Profile Assistant:

IPAe (IPA on the eUICC) is embedded directly in the SIM card. The logic for receiving, executing, and confirming profile management commands runs on the eUICC — the chip inside the SIM. The device it’s installed in doesn’t need to know about any of this. It just needs to support Bearer Independent Protocol (BIP) and SIM Toolkit (STK) commands, which the vast majority of modern cellular modems already do.

IPAd (IPA on the Device) is a software component that runs on the device’s operating system or application layer. It handles the same profile management communication — but this time, it’s the device doing it, not the SIM. That means the device needs to have IPAd integrated: the software must be present, updated, and correctly configured before the device can participate in SGP.32 profile management at all.

The distinction matters immediately once you have hardware in the field. IPAe is a SIM-side capability — you carry it with you when you swap the card. IPAd is a device-side capability — it’s either there or it isn’t, and adding it after deployment typically means a firmware update or an OS-level change.

How this differs from previous specs

The consumer eSIM standard, SGP.22, relied on the LPA — Local Profile Assistant — which ran on the device OS and required user interaction to trigger profile downloads. It worked for smartphones because users are present and the OS is actively managed. Neither of those conditions applies to most IoT fleets.

SGP.32 replaced the LPA with the IPA specifically to remove the device OS dependency — but it hedged: device-firmware integration (IPAd) is still available for situations where the engineer wants device-side control, while eUICC-embedded integration (IPAe) is available for situations where the device shouldn’t need to change.

The consumer eSIM transition took years partly because it required OEMs to integrate LPA support at the OS level. SGP.32’s IPAe path exists precisely to avoid repeating that problem for IoT. A SIM card that carries its own IPA client makes any compatible device SGP.32-capable without waiting for module makers, OEMs, or OS vendors to ship an update.

The earlier M2M standard, SGP.02, kept profile management tightly coupled to the MNO’s SM-SR server — enterprises had no direct control. SGP.32 breaks that coupling regardless of which IPA variant you use. But only IPAe does it without touching the device.

What this means in practice for deployed fleets

If your devices are already in the field on physical SIMs or legacy eSIM, IPAe is almost always the practical path. The device doesn’t care that the SIM has changed — it still sees a cellular modem presenting normal connectivity. The only configuration change is on the modem side: BIP and STK need to be active.

Most modern modems from the major manufacturers — Quectel, Telit, Sierra Wireless, Fibocom, Cinterion — have BIP support built in but disabled by default. We’ve documented the exact AT commands for each in our guide to enabling BIP/STK on your modem. Once that’s done, the IPAe-enabled SIM handles everything else: it opens the channel, contacts the eIM, and processes profile commands autonomously, without any host-side coordination.

IPAd deployments are different. Adding IPAd to an existing device means writing or integrating new software, testing it against the device OS, pushing a firmware update, and validating across the whole fleet. For devices that are actively managed, have capable hardware, and sit on a maintained development roadmap — this can make sense, especially when deep device-side control over profile operations adds value. But for a fixed IoT installation that’s been running in a remote enclosure for two years with no established firmware update path, IPAd isn’t a retrofit option.

Where it goes wrong

The most common failure mode we’ve seen from our fieldwork with IPAe deployments is treating BIP enablement as a formality. It isn’t. Each modem manufacturer uses a slightly different command set, and some require specifically disabling manual STK triggering for autonomous BIP operation to work. Enabling BIP incorrectly produces no visible error — the modem appears functional, but the IPAe client can’t open its channel to the eIM, and profile operations fail silently.

The second failure mode is assuming that any eUICC-based SIM automatically includes IPAe. It doesn’t. A SIM can be eUICC-compliant under SGP.22 without carrying an IPAe client for SGP.32. If you’re sourcing SIM cards for an SGP.32 deployment, confirm explicitly that IPAe is present and ask the vendor which eIM configurations they support.

A third failure, specific to IPAd, is version drift: the device OS gets updated independently of the IPAd component, and an API change breaks the integration. This doesn’t affect IPAe deployments — the SIM is isolated from OS changes — but it’s a real maintenance burden for large IPAd fleets where firmware cycles aren’t tightly controlled.

The choice between IPAe and IPAd isn’t purely technical — it’s about which side of the stack owns the profile management capability, and what it costs to bring the other side up. For most SMEs with devices already deployed, IPAe is the answer that doesn’t require touching the hardware.

If you’re evaluating SGP.32 eSIM management for an existing fleet and want to talk through your specific device landscape, our engineering team in Atlanta is the right starting point. Explore the xoSIM to see how Simplex delivers IPAe-enabled SGP.32 compliance in a single SIM card.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post IPAe vs IPAd: Why the SIM-Side Approach Matters for Retrofits first appeared on Simplex Wireless.

A device stops reporting. A carrier changes behavior. Data consumption on one SIM jumps overnight. You know the event happened — your devices are generating session records, usage logs, and connection timestamps constantly. What you don’t have is a fast path from “something’s wrong” to “here’s what’s happening and why.”

That gap is what this piece is about.

What “Getting an Answer” Actually Involves Today

Ask most IoT teams how they’d answer a question like “how many devices are currently active in Germany” and you’ll get a version of the same workflow: open the portal, find the right filter, set the time window, wait for the report to load, export to a spreadsheet if the numbers need to go somewhere, and then interpret what you’re looking at.

That’s on a good day, when you know exactly where to look. For less routine questions — which devices are showing unusual session termination patterns, what the trend looks like across the last 30 days by time of day, which carrier is accounting for the anomaly — the path gets longer. You might open multiple views. You might pull data from different parts of the platform. You might ask someone who knows the portal better than you do.

The underlying data hasn’t changed. The session records, the APN assignments, the carrier connections, the data volumes — all of it is there. What’s missing is the ability to ask a direct question and get a direct answer, without the interface becoming the obstacle.

Understanding what a well-structured IoT APN configuration looks like helps — but even with a clean setup, the visibility layer sitting above it hasn’t kept pace with the questions operators actually ask in production.

Why IoT Makes This Harder Than Regular IT Visibility

Enterprise IT visibility tools work reasonably well because the assets are stable: servers, laptops, network appliances. The inventory changes slowly. The monitoring layer has time to mature alongside the infrastructure.

IoT fleets don’t behave that way. A fleet of a few hundred SIM-connected devices generates session data continuously, across multiple carriers, across multiple countries, often with variable connection patterns tied to the physical behavior of the device itself — a tracker that only connects when a vehicle is moving, a sensor that only transmits at the top of the hour. The visibility problem isn’t just volume. It’s that the data is inherently multi-dimensional, and the questions you need to ask of it change depending on what’s happening in the field.

Choosing the right SIM and cellular strategy accounts for the deployment side. But operational visibility — knowing what your fleet is doing right now, which devices are behaving differently than they were yesterday, which carrier is responsible for a connectivity dip — is a separate problem that sits on top of the connectivity layer.

Most management portals were built to let you configure and control your fleet. They weren’t built to answer operational questions quickly. That distinction matters more as fleets grow.

What Goes Wrong When Visibility Is Slow

The most common failure mode isn’t a single device going offline. It’s a pattern that develops over hours or days that nobody catches until a customer reports a problem.

A traffic spike that starts small looks like noise. By the time it’s clearly anomalous, it’s already affected sessions across multiple devices. If spotting that pattern requires a manual check — opening a specific view, running a report, comparing against a baseline you had to build yourself — the window between “something is changing” and “we know about it” stays wide.

Data overages follow the same logic. Right-sizing your IoT connectivity plan requires knowing what your devices actually consume. If you can only answer that question in aggregate, or by pulling device-level reports manually, you’ll consistently find out about outliers after they’ve already cost you. The device consuming ten times what it should have been was generating that data the whole time — it just wasn’t visible.

Support escalations are the third failure mode. A field technician asks which carrier a device is on, what its last session showed, whether the termination cause was normal. If the answer requires a portal lookup by someone back at the office, that’s a delay baked into every support interaction. The information exists. The access path is the bottleneck.

Three Things That Close the Gap

1. Know what questions your team actually asks. Most operational questions are variations on a small set: what’s active, what’s consuming unusually high data, what changed recently, is a specific device behaving normally. If your platform can answer those questions directly, the visibility problem shrinks considerably. If it can’t, you’re building workarounds.

2. Treat anomaly detection as a requirement, not a feature. Waiting to be told something is wrong is reactive by design. A platform built for IoT fleet management should flag unusual traffic patterns automatically, without requiring you to build the baseline yourself or check manually on a schedule.

3. Make device-level data accessible to everyone who needs it. Network ops, customer support, and management ask different questions of the same fleet data. If answering those questions requires specialist knowledge of a portal interface, you’ve created a dependency. Access to session history, carrier status, and data consumption should require a question, not a training session.

That’s exactly what SimplexAI is built to do. Ask in plain English — “which SIM used the most data last week,” “are there any anomalies in the last 24 hours,” “what carrier is this device connected to right now” — and you get the answer directly, without navigating a dashboard or opening a report. Try SimplexAI in your Simplex account today.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post Your IoT Network Data Exists. Getting an Answer From It Shouldn’t Take This Long. first appeared on Simplex Wireless.

ATLANTA, GA — June 10^th, 2026 — Simplex Wireless, a provider of global IoT connectivity and eSIM management solutions, today announced the launch of SimplexAI, a conversational intelligence platform that allows enterprises to interact with their IoT connectivity environments using natural language. Instead of navigating dashboards, exporting reports, or relying on specialized analytics teams, users can simply ask questions about devices, usage, coverage, and network performance and receive immediate answers.

As IoT deployments continue to scale globally, organizations are managing larger deployments of connected devices across multiple carriers, countries, and technologies. While connectivity has become more sophisticated, the way users access operational information has changed very little. Many teams still rely on dashboards, reports, spreadsheets, and specialized analytics tools to understand what is happening across their deployments.

SimplexAI was developed to eliminate that friction. Built directly into the Simplex Wireless connectivity platform, the solution transforms IoT operational data into a conversational experience, allowing users to retrieve information about devices, SIMs, usage patterns, network performance, coverage availability, and device activity simply by asking questions in plain English.

“For years, the IoT industry has focused on making networks smarter while leaving the user experience largely unchanged,” said Raimo Järvenpää, Chief Product Officer at Simplex Wireless. “Customers still spend too much time navigating dashboards and searching for answers. With SimplexAI, we wanted to make interacting with an IoT network as simple as asking a question.”

Whether an operations team needs to determine how many devices are currently online, identify the highest data consumers across the devices, investigate unusual traffic patterns, verify LTE-M support from a mobile operator, or troubleshoot connectivity issues affecting a deployment, SimplexAI delivers immediate answers through a natural-language interface. Instead of requiring users to build reports or search through multiple systems, the platform provides direct access to operational intelligence in seconds.

The platform combines real-time operational visibility with historical analytics, global coverage intelligence, and install base wide device awareness. Users can investigate network activity, monitor usage trends, review device behavior, validate carrier capabilities, and explore connectivity data from across their entire environment without specialized training or business intelligence expertise.

Simplex Wireless believes conversational access to operational data represents the next evolution of IoT connectivity management. As deployments continue to grow in scale and complexity, organizations need faster ways to access information and make decisions without increasing operational overhead.

“Connectivity data is incredibly valuable, but historically it has been difficult to access and interpret quickly,” added Järvenpää. “Our vision with SimplexAI is to make IoT operational intelligence immediate, accessible, and useful for the entire organization—not just telecom specialists or data analysts. We believe the future of IoT operations is conversational.”

SimplexAI is part of the company’s broader strategy to modernize IoT connectivity through software-driven infrastructure, automation, AI-assisted operations, and next-generation eSIM technologies, including GSMA SGP.32-based eSIM management services. The platform is available immediately for eligible Simplex Wireless IoT connectivity customers.

For more information about SimplexAI and Simplex Wireless IoT connectivity solutions, visit https://www.simplexwireless.com/simplexai/

About Simplex Wireless

Simplex Wireless is a U.S.-based provider of IoT connectivity with presence in Europe, eSIM management, and cellular network solutions for enterprise and industrial deployments worldwide. The company delivers global IoT connectivity services, managed eSIM infrastructure, and operational tools designed to simplify and modernize connected device deployments across industries. Headquartered in Atlanta, Georgia, Simplex Wireless supports customers across North America and global markets with carrier-flexible connectivity solutions and in-house developed IoT technologies.

The post Press Release: Simplex Wireless Introduces SimplexAI™ first appeared on Simplex Wireless.

The data bill is never the problem. The problem is everything that happens after the device goes offline.

A fleet of 2,000 asset trackers. One carrier experiences a regional outage at 11pm on a Wednesday. By morning, 340 devices haven’t reported. The operations team assumes a firmware issue. An engineer spends half a day ruling that out. Someone eventually calls the carrier. The outage is acknowledged. The devices come back. Total cost of the data disruption: zero dollars. Total cost of the response: a day of engineering time, a delayed shipment investigation, and a customer who noticed the gap in tracking and started asking questions.

This is how connectivity failures actually cost money — and why the cost almost never shows up on the connectivity bill.

The four cost categories

A connectivity failure has four distinct cost categories, and only one of them is the data you didn’t transmit.

Direct costs are the most obvious: lost transactions, missed SLA commitments, regulatory penalties for data gaps in metered or medical devices. For some industries these are measurable and contractual — a missed delivery window, a failed payment at an EV charger, a billing gap in a metering cycle. These show up on a spreadsheet.

Operational costs are often larger and harder to see. A technician dispatched to reboot or swap a SIM card is the most visible form — what the industry calls a truck roll. The cost combines travel time, technician labor, and device downtime for the duration — a number that scales quickly with site remoteness and fleet size. Multiply that by the number of single-carrier failures in a year across a fleet of thousands, and it stops looking like a connectivity cost and starts looking like a staffing cost.

Reputational costs are the hardest to quantify and the longest to recover from. A customer whose GPS tracker went dark during a critical shipment doesn’t forget. A field service operator whose monitoring platform showed a gap during an audit has a conversation they’d rather not have. These costs don’t appear on any invoice.

Invisible costs are the most dangerous. A device that fails silently — where the SIM registers as active but the device isn’t transmitting — looks fine on every dashboard that doesn’t know what to look for. Your fleet shows green. Your carrier reports no outages. Your device is sitting there, doing nothing, and you don’t know.

The truck roll problem and the silent failure problem

The truck roll is the cost that gets the most attention because it’s the most visible. Someone has to physically go somewhere. That trip has a number attached: travel time, labor time, parts if needed. For a device deployed in a city, that might be a two-hour round trip. For a device on a remote utility installation, it might be half a day. Multiply by however many single-carrier outages your fleet experiences in a year — and then consider that multi-carrier failover eliminates most of those trips entirely by switching to a backup carrier automatically when the primary drops.

The silent failure problem is harder to solve because it requires active visibility, not just better hardware. A device running on a single-carrier SIM can lose signal and the SIM will show as registered. The carrier’s network accepted the SIM — it just isn’t routing traffic. Without a portal that monitors actual data transmission (not just SIM registration), this failure mode is invisible until something downstream triggers an alert: a customer complaint, a gap in a report, a missed alert that should have fired.

The difference between knowing about a silent failure in minutes versus days is the difference between a recoverable blip and an operational incident.

Where the cost is highest — and why

Not all IoT downtime costs the same. The industries below represent the highest downtime exposure — not because connectivity failures are more likely, but because the consequence of each failure is larger.

EV charging stations generate revenue per session. A charger that drops offline during peak hours loses those sessions permanently — they don’t queue up for later. Operators also face chargebacks and support calls when a payment fails mid-session because the device lost connectivity at the wrong moment.

Fleet and asset tracking carries liability exposure. A vehicle that goes dark for two hours may have missed location events that matter in a compliance audit, an insurance claim, or a customer SLA dispute. The device not reporting isn’t just an operational inconvenience — it’s a data gap in a record that someone may later need.

Medical monitoring is the highest-stakes category. Devices that transmit patient data or environmental readings in clinical settings are subject to regulatory requirements around data continuity. A connectivity gap isn’t a billing problem — it’s a documentation problem, and in some cases a patient safety concern.

Metering — utility meters, sub-meters, industrial consumption monitoring — depends on continuous data for accurate billing. A device that stops transmitting for 24 hours creates a billing gap that either goes unresolved or requires manual estimation — neither is acceptable at scale.

How to calculate your fleet’s downtime exposure

You don’t need an outage to know what one would cost. Run this exercise before your next deployment decision.

Count your single points of failure. How many devices in your fleet run on a single-carrier SIM? Each one is an outage waiting for a carrier to have a bad day. If that number is more than a handful, the exposure is real.

Estimate your truck roll rate. How many field dispatches in the last 12 months were connectivity-related? Multiply by your average dispatch cost — travel time, labor rate, device downtime. That’s your baseline: the cost you’re already paying.

Identify your silent failure risk. Does your current portal alert you when a device stops transmitting data — or only when the SIM deregisters? If you can’t answer that question immediately, assume the answer is no. That gap is where silent failures live undetected.

Apply your industry multiplier. A connectivity failure in an EV charging network at 6pm on a Friday costs more than the same failure on a metering device at 3am. Adjust your exposure estimate for when and where your devices run.

The Livelox team ran a version of this exercise before switching to multi-carrier SIM cards. Their GPS trackers across Nordic race venues had been dropping signal in remote forests — not because the technology was wrong, but because no single carrier covers everywhere. The switch to multi-carrier eliminated the drops. The overhead of managing fragmented carrier contracts disappeared with it.

Connectivity redundancy isn’t an insurance policy you hope never to use. For most deployed IoT fleets, it’s the cheaper option once you total up what single-carrier failures actually cost. If you’re ready to see what multi-carrier coverage looks like for your deployment, explore Simplex IoT SIM cards and request a trial SIM.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post The Real Cost of IoT Connectivity Failures: Downtime, Truck Rolls, and What’s Actually at Risk first appeared on Simplex Wireless.