After reading this, you’ll know why EV chargers are a strong fit for SGP.32, and what to check before committing a fleet to an eIM provider.

An eSIM, an embedded or software-based SIM that replaces a physical, removable card, isn’t new. What’s new is SGP.32, the GSMA specification that finally builds remote carrier management for IoT devices the way it should have worked from the start. For EV chargers specifically, a device class that sits in the field for years and is expensive to physically revisit, that specification solves a problem that’s been costing operators money since the first unit shipped.

Why EV chargers are a natural fit for SGP.32

Three things about EV chargers make them an obvious candidate for this standard. They stay in the field for years, often a decade or more, over which network conditions, carrier pricing, and coverage all shift. They’re distributed across sites that range from urban parking structures to remote highway corridors, many without convenient physical access. And a technician visit to swap a SIM or reconfigure a modem, a truck roll, costs real money every time it happens, multiplied across however many chargers need the same fix.

If you want SGP.32 explained from first principles before going further, we’ve covered the standard itself in detail elsewhere. This piece stays focused on what it means specifically for a charging fleet already in the ground.

What changes with an eIM: remote profile management explained

SGP.32 introduces the eIM, a management server that handles carrier profiles remotely instead of requiring physical access to the device. An eIM is what actually lets an operator switch carriers over the air, sending a new profile to the charger’s eSIM and activating it without anyone touching the hardware. For a fleet manager, that turns a carrier change from a truck-roll-per-unit project into a remote operation that can, in principle, be pushed to an entire site or region at once.

Retrofitting existing chargers without replacing hardware

The retrofit question is usually the one that stalls a fleet upgrade before it starts: does moving to SGP.32 mean replacing chargers already installed in the field? For units built with the right SIM-side support, the answer is no. IPAe, the SIM-side implementation of SGP.32’s profile assistant function, handles the profile management logic on the SIM itself rather than requiring changes to the charger’s own software or hardware.

Carrier independence: renegotiating rates without a site visit

The operational win compounds into a commercial one. A fleet locked to a single carrier by physical SIM logistics has no real negotiating leverage at contract renewal, since switching means paying for truck rolls across every affected site. A fleet on an eIM-managed eSIM can move carriers, or split a fleet across multiple carriers by region, without that cost standing in the way. That changes the conversation at renewal time from “what can we tolerate” to “what’s actually the best rate available this year.”

What to ask an eIM provider before you commit a fleet

Not every eIM is built the same way, and the difference matters more once a fleet depends on it for years. The most important distinction is whether the eIM was built in-house by a team with SIM and carrier-grade platform expertise, or assembled by relying on a single EUM (eUICC manufacturer) or MNO (mobile network operator) for the pieces that actually make profile switching work.

An eIM built by a team that’s tested against multiple eUICC manufacturers, rather than one, is generally a stronger long-term bet than one tied to a single manufacturer’s roadmap. We’ve written a fuller checklist for evaluating an eIM provider if you want to go deeper before signing anything.

For a fleet of EV chargers already in the field, the retrofit question isn’t whether SGP.32 is worth adopting, it’s whether the provider behind it can actually deliver a retrofit without a truck roll to every site. Talk to our engineering team if you want to walk through what that looks like for your fleet specifically.

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

The post eSIM for EV Chargers: Retrofitting with SGP.32 first appeared on Simplex Wireless.

It decides whether a question about your fleet takes one query or three carrier logins.

Picture 40 devices in a warehouse going quiet at once. The first job is working out whose problem it is, so you open one carrier portal, then another, then a spreadsheet of ICCIDs (the serial number printed on each SIM). By the time you find the SIM that burned through its data pool, the shift is over.

What a connectivity management platform is, and how it works

A connectivity management platform (CMP) is software that sits between your devices’ SIM cards (Subscriber Identity Modules) and the carrier networks they connect to. It gives you one interface and one API (application programming interface) for every SIM in the fleet, instead of a separate login for each mobile network operator (MNO).

The work falls into four jobs. Lifecycle covers activating, suspending, re-planning, and retiring SIMs. Visibility covers session status, data used per device, which network each SIM attached to, and where it is roaming. Control covers usage caps and alerts that act before the invoice does. Billing turns usage records from several carriers into one invoice you can reconcile. Figure 1 shows where the platform sits.

Figure 1: Where a CMP sitsDevices and SIMsEvery ICCID in the fleet→Carrier networksSeveral MNOs, several countries→CMPOne inventory, one API→Your team and systemsAlerts, billing, reportsDevice traffic still runs over the carrier. The CMP works alongside it, reading usage records and sending commands back.

Under the hood, a CMP typically reads each carrier’s usage and session records and sends commands back, such as suspend or change plan. Every action available in the portal should also exist in the API, because nobody at fleet scale clicks through 10,000 rows. Our guide to what a dashboard should show lists the views worth demanding.

One boundary worth drawing: a CMP is not an eSIM IoT Remote Manager (eIM). A CMP manages subscriptions and connections on the connectivity side. An eIM manages which carrier profiles sit on an eSIM (embedded SIM) under SGP.32, the GSMA specification for IoT remote provisioning. You can run one without the other, though fleets that switch carriers over the air tend to want both, because every new profile still has to show up in your management view.

Why it matters for IoT specifically

A phone has an owner who notices when it stops working. An IoT device has none. It sits inside an EV charger, a trailer, or a field sensor, and nobody knows it dropped off the network until something downstream breaks. That one difference changes what management has to do.

Consumer plans assume a person watches the line, one carrier is enough, and a monthly bill is the feedback loop. A fleet inverts each assumption. Devices span carriers and countries, per-device data use is tiny but multiplied across thousands of SIMs, and one misbehaving unit can drain a pool shared by hundreds. The CMP is where you notice.

It is also where your bargaining position in a carrier relationship lives. If your only view of the fleet is your carrier’s own portal, switching carriers means losing history, alerts, and integrations all at once. A carrier-neutral CMP keeps them with you, which is why carrier lock-in shows up as a cost long before a contract renews. Simplex’s Bring Your Own Operator (BYOO) service follows that logic to its end: you keep your existing MNO contracts and manage them in one portal.

What goes wrong

Most CMP failures are quiet. Five patterns are worth knowing, and Figure 2 sets the before and after side by side once they are fixed.

The runaway device. A firmware bug puts a device into a retry loop, and it spends data meant for a shared pool. Without a per-device threshold, you learn about it from the invoice.

“Active” does not mean online. A SIM’s status usually shows whether the subscription is enabled, not whether the device has a session. Teams read the green status as health and miss silent devices.

The API gap. The portal can suspend a SIM; the API can’t. Automation stalls, and someone ends up scripting a browser.

Border crossings. A device on a truck crosses into another country and starts roaming. If nothing alerts on foreign roaming, the first signal is a charge.

Zombie SIMs. Inventory lives in a spreadsheet that drifts from reality, and decommissioned SIMs keep billing because nobody canceled them.

What to do about it

Three steps, before you buy or renew anything.

First, build one inventory: every SIM, its ICCID, carrier, plan, and the person who owns it. If producing that list takes more than an afternoon, you’ve found your first requirement.

Second, time your most common questions. Which SIM used the most data last week? How many devices are online in Germany right now? Which devices haven’t connected in a day? If each answer takes a login and a spreadsheet, that’s the cost to fix. The questions every IoT team asks their network make a good starting list.

Third, set thresholds before deployment, not after the first surprise: per-device usage ceilings, roaming alerts, and a silent-device alert. Then test them by pushing a trial SIM past its cap and confirming the alert fires. Figure 3 turns the three steps into a pass/fail test for any platform you evaluate.

Figure 3: What a CMP should passWorks across SIMs from more than one carrierEvery portal action is available through the APIPer-device usage history, not only pool totalsAlerts for usage spikes, foreign roaming, and silent devicesAnswers in plain language, without a BI tool

Back in the warehouse, a CMP turns those 40 silent devices into one filter and one list. The Simplex portal covers data consumption trending, real-time usage, sub-accounts, and alerts for sudden foreign roaming and rogue device behavior, and it works with your existing carrier contracts through BYOO. Explore the Simplex portal to see what that view looks like for your 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 What Is a Connectivity Management Platform? first appeared on Simplex Wireless.

A single dropped carrier shouldn’t mean a dropped crew. Here’s what actually happens inside a PTT radio when the network switches underneath it.

A Push-to-Talk over Cellular (PoC) radio only works if the SIM inside it has signal. Lose that signal mid-shift and the radio isn’t a radio anymore — it’s a brick with a talk button. Most teams don’t find this out in a lab. They find out on a jobsite, in a parking structure, or on the edge of a coverage area, exactly when the call mattered.

What a Multi-Carrier SIM Actually Does for a PoC Device

A standard SIM ties a device to one carrier’s network, permanently. If that carrier has a dead zone at the loading dock, a tower outage during a storm, or congestion during a shift change, the radio goes silent until the SIM’s one and only network comes back. There’s no fallback, because there’s nothing to fall back to.

A multi-carrier SIM is provisioned across several networks at once — typically the major U.S. carriers — and picks whichever one is strongest at that moment. The mechanism isn’t exotic: the SIM continuously reads signal quality and, when the current network degrades past a threshold, authenticates on the next-best carrier without anyone touching the device. This is the same failure mode we’ve written about for IoT devices in general — a PTT radio is just a version of it where the outage is audible in real time instead of showing up as a gap in a data log.

Why This Matters More for PTT Than for a Phone

A phone call that drops gets redialed. A push-to-talk session doesn’t work that way — it’s a half-duplex, always-on channel where the whole point is that pressing a button gets you through instantly, to one person or the whole crew. If the network drops for even a few seconds during that press, the message doesn’t queue and retry. It just doesn’t arrive, and nobody involved necessarily knows that.

This is also where PoC radios reveal what they really are: connected computers running an app, not analog walkie-talkies. Some of them run full Android, which is its own management challenge — we’ve covered what that means for data usage and control — but the connectivity layer underneath is what determines whether any of that software works at all. Security patrols moving between buildings, construction crews spread across a site, delivery fleets crossing county lines — all of them cross coverage boundaries that a single carrier simply doesn’t cover evenly. A multi-carrier SIM is the thing that makes “nationwide” an honest claim instead of a marketing one.

What to Check Before Choosing a Multi-Carrier PTT SIM

Not every SIM sold as “multi-network” behaves the same way once it’s actually deployed. A few things separate the ones that work from the ones that just say they do — see Figure 2 below for the full list.

The two worth calling out specifically: how many networks are actually tested and working, not just named on a spec sheet, and how the switch behaves during an active session rather than only at idle. A provider claiming three carriers but only routinely reaching one in your service area isn’t giving you failover — they’re giving you a single point of failure with extra steps. Coverage maps themselves are notoriously optimistic, which is exactly why real-world testing matters more than the marketing page.

The other detail buyers often skip is who’s actually behind the multiple networks. A SIM that reaches three carriers through three separate wholesale agreements behaves differently under load than one built on direct network partnerships negotiated for exactly this purpose — ask how the switching decision gets made, and by whom.

Multi-Carrier vs. Wi-Fi Failover: Using Both

Wi-Fi failover gets marketed alongside multi-carrier support, and it’s worth having, but the two aren’t interchangeable. Wi-Fi only helps where there’s a known network to join — inside a warehouse, an office, a facility with configured access points. It does nothing for a crew on a highway, a farm, or a construction site with no infrastructure at all. Cellular is the layer that covers the radio everywhere; Wi-Fi is a useful supplement indoors, not a replacement outdoors. See Figure 3 below.

The right setup uses both, in the right order: multi-carrier cellular as the default connection, Wi-Fi as an automatic assist in buildings where cell signal doesn’t reach. Radios configured with only one of the two will have predictable blind spots — indoors, or outdoors, depending on which one got left out.

How Simplex’s Multi-Network SIM Fits PoC Deployments

Simplex’s PTT SIM cards carry the same multi-network access we build into every IoT SIM: automatic selection across the major U.S. carriers, with data breakout points in the USA, Europe, and APAC for fleets that operate outside a single country.

A dropped carrier is a bad time to find out your SIM only had one network to fall back on. If your team is evaluating connectivity for a PoC deployment, our engineering team can walk through exactly how the failover behaves in your coverage area before you commit a fleet to it.

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 Multi-Carrier SIM Failover for Push-to-Talk Radios: How It Works first appeared on Simplex Wireless.

How to connect media towers, kiosks, and directories without depending on a network you don’t control.

Picture a media tower in a busy venue concourse. The screen works, the content player works, and the display is still dark. The weak link is the network behind it, and the integrator who installed the tower doesn’t own that network.

The connectivity challenge in public venues

Integrators who build and manage digital signage often reach their displays over the venue’s own network. That makes the venue operator part of your uptime. Simplex’s comparison of cellular versus Wi-Fi makes this point for EV chargers, and it carries over to signage. Wi-Fi usually means joining a network the site operator doesn’t fully control, so someone else’s outages, updates, and security choices become your device’s problem too.

Wi-Fi also runs on unlicensed spectrum shared with every other device on the band. A signal that tested fine on install day can degrade as more devices join around it.

The same logic applies to a kiosk on an airport concourse or a media tower in a library atrium. The display isn’t the variable. The network path is.

Why standard SIMs fail here

The obvious fix is a cellular modem inside the enclosure, which takes the venue network out of the path. But it only helps if the SIM is the right one. A single-carrier SIM ties the display to one network, and Simplex has named that as a common cause of unexplained outages.

Coverage is also local. A carrier that’s strong in one part of a building can be weak in another, which is why coverage maps are a starting point and not proof. When a display drops, you need to know whether the SIM attached and to which network. Without that, the only way to find out is a site visit.

Figure 1 compares the two connection models.

What the right connectivity looks like

Start with a multi-carrier SIM. It can attach to more than one mobile network operator (MNO), so a gap in one carrier’s coverage doesn’t have to take the display down. It improves your odds, but it isn’t a guarantee. Simplex has written about why “multi-network” on a spec sheet isn’t the same promise it sounds like, so ask how a SIM chooses and switches networks, not just how many it lists.

Next, look at how the traffic is routed. An access point name (APN) is the gateway a cellular device uses to reach a network. A private APN can route your display traffic to your own content servers instead of the public internet.

Then plan for the long life of the hardware. A media tower can outlast a carrier contract. SGP.32 is the GSMA’s eSIM IoT specification. It lets an eSIM IoT Remote Manager (eIM) switch carrier profiles over the air, so changing carriers doesn’t mean pulling a physical SIM from the enclosure.

How Simplex fits

Multi-carrier data SIMs. Simplex’s IoT data SIMs offer carrier-redundant connectivity across multiple MNOs. They come as plug-in SIMs (2FF, 3FF, 4FF), as soldered MFF2, or as eSIM, so the form factor can match your kiosk hardware.

Visibility. The dashboard and REST API cover SIM provisioning and reporting. SimplexAI lets you ask about your network in plain English, such as how many devices are online or which SIM used the most data.

eSIM management. Simplex built its eIM in-house and runs it on its own bare metal. Simplex eSIM management is available on its own, so you can keep your existing MNO contracts, or paired with Simplex’s multi-carrier SIMs. It’s built and supported from Atlanta, Georgia.

Four checks before you deploy

Whichever provider you choose, don’t rely on the datasheet. Test the connection on the actual display, in the actual spot, before the install schedule locks in. Figure 2 lists the four checks we’d run first.

The display was never the weak link. The network path was. Build a path you control, with more than one carrier behind it, and test it before the install date rather than after the first dark screen. To see how Simplex can connect your displays, talk to our engineering team.

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 Keeping Public Venue Screens Online: IoT Connectivity for Arenas, Airports and Libraries first appeared on Simplex Wireless.

“Simplex has been a great connectivity partner for ezVOLTz. Their SIMs integrated seamlessly into our charger deployments and connectivity has been reliable. When we need support, they pick up the phone and help us solve the problem. That combination of reliable technology and real human support is exactly what we want in a partner.”

Read the full ezVOLTz Case Study here

The post Case Study: ezVOLTZ first appeared on Simplex Wireless.

After reading this, you’ll know exactly where the gap sits between “OCPP says the charger is fine” and “the driver couldn’t start a session,” and what to monitor to close it.

A charger reports a clean heartbeat. Session status: available. Then a driver plugs in and nothing happens. The operator pulls up the dashboard, sees green across the board, and has no idea where to even start looking. This isn’t a rare edge case, it’s the predictable result of watching only one layer of a system that has several.

OCPP tells you about the charger. Not the connection.

OCPP, the Open Charge Point Protocol, is the standard that lets EV chargers talk to a central management system: reporting status, transactions, availability, and errors, and accepting remote commands like start, stop, or firmware updates. It’s the layer charging network operators watch most closely, and for good reason. It’s also, by design, only reporting on what the charger itself knows.

OCPP can tell you the charger booted successfully, that it’s not mid-session, and that its last heartbeat came through on schedule. What it can’t tell you is whether the network path underneath that heartbeat is healthy, or one dropped packet away from failing the next transaction. That path lives beneath OCPP, not inside it, and if nothing is watching that layer, an operator only finds out about a problem when a driver reports one.

Where the blind spot sits: between the SIM and the backend

Between the charger’s OCPP client and the backend management system sits a stack most dashboards never surface: the SIM’s APN configuration that governs how the connection gets routed, any VPN tunnel encrypting that traffic, the routing itself, and the health of the gateway or router handling the cellular link. Any one of these can degrade without ever showing up as a charger-side error, because from the charger’s point of view, it’s still sending its heartbeat successfully.

Why a charger can report “available” and still fail a session

The mechanics are straightforward once you separate the layers. A heartbeat only needs a thin, intermittent connection to succeed, a small packet, sent occasionally, that either gets through or times out and retries. A payment authorization or a session-start command needs a stable, low-latency path held open long enough to complete the round trip. A connection degraded enough to still pass heartbeats can fail exactly the traffic that matters to the driver standing at the charger, and OCPP has no visibility into that difference. It only knows the last heartbeat succeeded.

This is compounded on cellular links because registration and handoff behavior isn’t instantaneous. A modem re-registering after a brief signal drop can look fine on the next heartbeat while having missed the exact window a driver tried to authenticate.

Building a full-stack view: OCPP plus connectivity telemetry

Closing this gap means pairing OCPP data with telemetry from the connectivity layer itself, and this is where most fleets are underserved. A SIM management platform worth using surfaces more than a green or red status dot: signal quality trends per site, APN and VPN tunnel state, data session duration and drop frequency, and gateway-level health separate from the charger’s own reporting.

Cutting truck rolls with combined visibility

The payoff for combining these views isn’t just faster root-cause analysis, it changes what a technician needs to do about a report of a failed session. Without connectivity telemetry, “the driver says it didn’t work” usually means a site visit to find out why, because OCPP alone gave no clue. With it, an operator can often see the degraded tunnel or the gateway that was struggling before the driver ever called, and that difference is the gap between a dispatched truck roll and a five-minute remote fix.

For EV charging operators running fleets across dozens or hundreds of sites, that combined view isn’t a nice-to-have. It’s the difference between chasing every complaint one call at a time and catching the pattern before it becomes one.

If your team is still troubleshooting failed sessions one driver complaint at a time, talk to our engineering team about what connectivity telemetry would show you before the next call comes in.

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 OCPP Over Cellular: What Remote Diagnostics Miss first appeared on Simplex Wireless.

What to verify at each stage of an SGP.32 device’s journey, so your first batch tells you what a full rollout will do.

An SGP.32 deployment rarely fails at the concept level. It fails at a specific stage: a bootstrap profile that lapsed on a shelf, a device that switches on abroad with roaming disabled, a profile switch nobody tested until it was needed. A pilot is the cheapest place to find those problems, but only if it is designed to look for them.

The journey a pilot has to cover

An SGP.32 device leaves the factory with a bootstrap profile, a minimal connectivity profile whose job is to reach the eSIM IoT Manager (eIM), the server that tells the device what to do next. Between the two sits the IoT Profile Assistant (IPA), which carries instructions between the eUICC (the embedded SIM chip that holds operator profiles) and the eIM. The IPA runs either on the SIM itself (IPAe) or in the device (IPAd). Simplex’s guide to how bootstrap works and its explainer on what the eIM actually does cover the mechanics. This piece assumes them and asks a different question: what should you check, and when?

A device passes through five stages, and each one is a place where something can quietly break. Figure 1 shows them, with the first power-on highlighted because it is the moment the whole chain is exercised for the first time, in the place a customer will switch the device on.

How this differs from testing a traditional SIM

With a conventional SIM, the profile is fixed at manufacture. A pilot mostly asks one question: does the device attach and pass data? If it does on the bench and in a few field sites, the odds are good it will keep doing so.

SGP.32 turns connectivity into a sequence. The device connects on bootstrap, reaches the eIM, receives an instruction, downloads a profile, and enables it. Each handoff depends on a different party, and a gap in any one of them looks the same from the outside: a device that is powered on and silent. That is why remote SIM provisioning is easy to demonstrate and harder to validate.

Four layers have to agree. The first is the SIM and eUICC: is it certified for SGP.32, and does the IPA run on the SIM (IPAe) or rely on the device (IPAd)? The second is the module and firmware: does the modem firmware support the chosen approach, and is roaming enabled so bootstrap can attach abroad? The third is the eIM and service: is the APN reachable, and can the eIM talk to the profile source you plan to use? The fourth is connectivity and commercial: are bootstrap and operational agreements active in every target country, with terms that allow a later switch?

It also changes what “working” means. Attaching once proves very little. The capability you are buying is the ability to change connectivity later, so the pilot has to test that change, not only the first connection.

What this means in practice

Run the pilot on a small batch and make it deliberately uncomfortable. Three habits separate a useful pilot from a demo.

Test in the countries you will ship to, not the one your lab is in. Bootstrap attaches on a visited network, so a device that connects perfectly on your bench can stall abroad if roaming is off or the APN, the access point name that routes its data, is wrong. Send a few units through your real logistics route so the first power-on happens where a customer will do it.

Age some devices on purpose. Hold a subset in storage for the longest period your supply chain realistically allows, then power them on. Whether a bootstrap profile survives long shelf time depends on your SIM and network agreements, so ask for the answer in writing and then test it. In-factory profile provisioning changes what is loaded before shipment, which makes this test more relevant, not less.

Test the second switch, not just the first. Getting a device onto its operational profile proves activation. Moving it to a different profile later proves the thing you adopted SGP.32 for. Do it on live pilot devices, at least once with a change of network.

Where pilots go wrong

The common failures are mundane. A device powers on, attaches to a tower and produces no data, and the team blames coverage when the cause is roaming or an APN. A pilot passes on the bench and fails in the field because nobody tested the destination country. A team validates activation, skips the second switch, and finds the problem only after devices are deployed.

The failure that costs the most is untested recovery. SGP.32 deployments depend on three safeguards: rollback, so a device that switches profiles and loses connectivity can return to the previous one; fallback, so an interrupted download does not corrupt a profile; and a bootstrap profile that keeps a minimal link alive. Simplex’s lessons from its own SGP.32 work describes all three. Do not assume yours works. Cause a failure on purpose and watch the path in Figure 2.

A pilot that only proves the happy path tells you the architecture works when nothing goes wrong. The value is in the stages you break on purpose: shelf time, the destination country, the second switch, and the failed one. If a small batch passes all four, scaling becomes a logistics problem rather than a technical one.

If you want a second set of eyes on your plan, Simplex can run an SGP.32 readiness review of your device, SIM, and firmware setup before you commit to a pilot batch.

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 Testing SGP.32 Before You Scale: A Stage-by-Stage Pilot From Factory to Field first appeared on Simplex Wireless.

Every connectivity quote leads with a headline number: a rate per megabyte, a flat fee per device, sometimes a bundled annual price. That number is the easiest thing to compare across vendors side by side. It’s also the least reliable predictor of what a fleet will actually cost once it’s running.

The gap between the quoted rate and the real bill usually isn’t fraud or fine print, though it happens. More often it’s a line item nobody priced into the comparison at procurement time: a fee for activation, a device that went quiet six months in but is still billed, an overage the one month traffic spiked. None of those show up on the rate card (Figure 1). All of them show up on the invoice. What follows is a way to model total cost before you sign, not after your first quarterly bill surprises you.

What actually determines total cost

The base rate, and the model behind it. Part of the base rate depends on which pricing structure fits your traffic, pay-as-you-go, pooled, or prepaid. That choice matters, and it’s covered in depth in why your IoT SIM bill runs higher than it should. It’s one variable in the total, not the whole calculation, which is why it isn’t the focus here.

Activation and deactivation fees. Charged per SIM, separate from the monthly rate, and easy to miss when a quote only shows the recurring cost.

Inactive device carrying cost. The quiet one. A device that stops transmitting doesn’t stop being billed unless someone catches it and deactivates the SIM. At fleet scale, this is often the single largest gap between quoted and actual spend.

Overage and top-up pricing. What happens the month a device uses more data than planned, and whether that rate is disclosed up front or discovered on the invoice.

Regional and roaming multipliers. The same SIM, same plan, can cost meaningfully different amounts depending on which country the device actually operates in.

Support and portal access. Whether fleet visibility and account support are included in the base rate or billed as a separate line.

Common pitfalls

Comparing only the advertised rate across vendors, without running it against your own usage pattern first.

Not budgeting for the devices that go quiet. Most cost comparisons assume every deployed device stays active and billed correctly, which almost no real fleet does.

Treating regional pricing as flat. A plan that looks identical on the rate card can behave very differently once devices are spread across multiple countries.

How Simplex addresses each line item

Simplex’s IoT SIM pricing is published, not quoted case by case, and structured modularly around what a deployment actually needs rather than sold as a fixed bundle. Activation isn’t hidden inside a separate fee schedule; it’s part of the same published rate.

On inactive devices, Simplex’s portal surfaces devices that have gone quiet so they can be deactivated deliberately rather than discovered on an invoice, which is the silent cost fleet operations teams spend the most time chasing.

On pooled data specifically, Simplex’s data pooling lets high-usage and low-usage devices offset each other inside one deployment, which changes the overage math significantly for mixed fleets.

On regional pricing, coverage runs across 190-plus countries and 500-plus networks under one rate structure, so the multiplier a buyer needs to model is disclosed up front rather than negotiated per region after the fact.

On support and portal access, visibility into usage and device status is part of the base offering rather than a paid add-on.

One limit worth naming: no vendor, Simplex included, can hand you an accurate inactive-device percentage on day one. That number comes from your own deployment’s field behavior, not from a rate card, and it’s usually the single biggest swing factor in which pricing model actually wins. Simplex can model it with you once you have even rough field data, but we can’t estimate it blind, and any provider who quotes you a confident number without asking about your device history is guessing.

Questions to ask about pricing

Put these to any vendor, not just Simplex, before you compare a rate card:

The bottom line

The rate card tells you what a vendor charges. It doesn’t tell you what your fleet will cost, because that depends on variables only your deployment history can supply: how many devices go quiet, how usage spikes in a bad month, how spread out your fleet actually is by country.

Send Simplex your device count, the countries you operate in, and your expected monthly usage per device, and we’ll build a real cost comparison against your numbers instead of a guess against a rate 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 What Your IoT Connectivity Quote Doesn’t Show You: A Line-by-Line Cost Worksheet first appeared on Simplex Wireless.

After reading this, you’ll know why “multi-network” on a spec sheet isn’t the same guarantee it sounds like, and what to check before you trust a SIM with your charging network’s uptime.

A charger goes dark. The dashboard shows a healthy signal bar right up until the moment it disconnects, and three other stations at the same site drop within the same minute. The SIM was sold as multi-network. It still went down with everything else on site. That gap between what “multi-network” promises and what it actually protects against is worth understanding before it costs you a truck roll, or worse, a failed charging session a driver blames on your hardware.

What “multi-network” actually means on a SIM

A multi-network SIM roams across more than one mobile network operator instead of locking a device to a single carrier. In practice, that means the SIM can pick up signal from whichever tower has the strongest reach at a given site, which solves a real problem: coverage gaps that would otherwise leave a charger unreachable. For EV charging stations spread across highway corridors, parking structures, and retail lots, that flexibility is genuinely valuable.

The word to watch is “roams.” Roaming describes radio access, which network tower the device talks to. It says nothing about what happens after that tower hands the connection off to the rest of the network.

The hidden single point of failure: shared core infrastructure

Here’s the part a spec sheet doesn’t show. Behind the radio layer, most multi-network SIMs still route every session through a single mobile core, the backend infrastructure that handles authentication, session management, and data routing regardless of which tower the charger connected to. If that core has a bad day, radio diversity doesn’t help. Every charger on that SIM provider’s network can go down at once, even though each individual charger appears to have a strong connection.

This is the distinction between radio diversity and core independence, and it’s the one that decides whether “multi-network” is a real redundancy strategy or a marketing term. Understanding why comes down to how the SIM’s underlying network relationship is structured. A SIM provider that resells access through one carrier partnership, however many networks that partnership lets a device roam across, still depends on that one partnership’s infrastructure holding up.

The four ways EV chargers actually go down

Not every outage looks the same, and lumping them together is how operators miss the pattern. Four distinct failure modes show up in charging networks, and only one of them is a coverage problem at all.

A device-uptime gap is when the charger reports itself as available to the backend, but a driver still can’t start a session, because the failure sits somewhere between the two, not in either system alone. A correlated site or estate-wide outage is when several chargers drop within the same window because they share one upstream dependency, not because each one failed independently. A payment-path or authorization failure is when the connection is technically up, but the specific route to a payment processor or authentication service is down. And an unreachable management path is when nobody can remotely diagnose or reboot the charger, because the same outage that broke the driver’s session also broke the operator’s visibility into it.

Only the first kind gets caught by a stronger radio signal. The other three are architecture problems, and they’re the ones that make “the SIM said it had coverage” a frustrating thing to hear from a vendor after a bad night.

What true redundancy requires

Real redundancy means the SIM carries independent operator profiles, each with its own core network, its own authentication path, and its own routing, not just multiple radio options sitting on top of one shared backend. If one profile’s core has an outage, the device fails over to a genuinely separate infrastructure path, not a different antenna pointed at the same failure.

That distinction also determines what happens during a switch. A profile change that doesn’t correctly re-establish routing, VPN tunnels, and remote management access isn’t a completed failover, it’s a connection that looks recovered on paper while the operator still can’t reach it.

Evaluating a connectivity provider’s failover architecture

Before signing a multi-year contract on the promise of multi-network resilience, a short list of direct questions does more good than another line on a spec sheet.

If you’re comparing providers on exactly this question, our engineering team can walk through your site list and show you where carrier partnership structure actually matters for your fleet, and what a correlated outage would cost versus the truck roll a single bad SIM decision can trigger.

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 Multi-Network SIMs Don’t Guarantee EV Uptime first appeared on Simplex Wireless.

One switches carriers at the network layer, the other swaps the whole SIM profile — knowing which does what changes how you build your fleet.

A fleet manager evaluating SGP.32 for the first time usually already has some multi-IMSI SIMs deployed somewhere in the field. So the question isn’t abstract: it’s “do I rip these out, or do the two systems play together?” The honest answer is that they solve different problems, sit at different layers, and in most fleets, the right answer is neither “replace” nor “combine” — it’s knowing which one you actually need for which device.

What each one actually does

A multi-IMSI SIM stores several subscriber identities (IMSIs) on a single physical card and switches between them using an on-SIM applet. The switch happens automatically, in the background, based on signal strength or a pre-configured roaming priority list. It’s fast and doesn’t require any external server involvement once the card ships. What it can’t do is add a brand-new operator relationship after deployment — the set of IMSIs on the card is fixed at manufacture.

An eIM, the eSIM IoT Manager introduced in the GSMA’s SGP.32 specification, works at a different layer entirely. Instead of choosing among a pre-loaded set of identities, it orchestrates full profile downloads and swaps on an eUICC, the embedded SIM chip that receives and stores those operator profiles. See Figure 1 above for how the two compare mechanically. The eIM doesn’t live on the device — it’s server-side infrastructure that a fleet operator, or their connectivity provider, controls remotely, deciding when a device gets a new profile and from which operator.

The practical distinction: multi-IMSI is a SIM doing its own job quietly, choosing among options it already has. An eIM is a person, or a policy engine, making a deliberate decision to give a device an option it didn’t previously have.

Why eIM changes the calculus

Multi-IMSI has been the default answer to “what if my primary carrier goes down in this region” for years, and it still works for that narrow case. What it was never built for is renegotiating your entire connectivity contract, or onboarding a carrier that wasn’t on the card when it shipped. If a better rate becomes available in a market eighteen months into a deployment, a multi-IMSI fleet has no path to it without a physical SIM swap.

SGP.32 addresses this with two download models: direct download, where the client on the device or SIM talks straight to the profile source, and indirect download, which routes through the eIM as a central orchestrator. That indirect path is what makes eIM fundamentally different from multi-IMSI’s fixed menu — it can hand a device a profile from an operator that didn’t exist as an option on day one. For the mechanics of what actually happens during that download and activation sequence, the provisioning process itself is worth understanding before you plan around it.

Where the two actually meet in a real fleet

For most operators, this isn’t an either-or decision at the fleet level — it’s a segmentation question. Devices with tight power budgets, no eUICC, and a narrow, well-understood roaming footprint are often well served by multi-IMSI exactly as they are today. Devices with a longer service life, unpredictable regulatory exposure, or a real chance of needing a new carrier relationship down the line are the ones where an eUICC and an eIM relationship earn their keep. If you haven’t yet worked through how to choose a SIM and cellular strategy at the fleet level, that’s the right starting point before segmenting individual devices.

The scenario grid above (Figure 2) maps this out by two variables that matter most: whether the device carries an eUICC, and whether the fleet needs long-term carrier flexibility. Most active fleets sit across more than one of these quadrants at once, which is exactly why the two systems coexist at the portfolio level even when they never touch the same device.

Where it goes wrong

The failure mode isn’t usually technical incompatibility — it’s ownership confusion. Multi-IMSI’s applet and an eIM’s profile orchestration operate on genuinely different objects, so there’s no direct protocol collision to worry about on a properly specified eUICC. The real risk shows up in process, not silicon:

Assuming eUICC support where there isn’t any. Some fleets have devices with a multi-IMSI SIM and assume that’s “basically the same as eSIM.” It isn’t. If the hardware doesn’t carry an eUICC, there’s no eIM path available at all without a physical SIM change.

Treating multi-IMSI as a substitute for carrier renegotiation. Automatic network failover solves an outage, not a contract problem. Fleets that rely on multi-IMSI as their long-term flexibility plan tend to discover the ceiling only when they actually need a new operator relationship, usually at the worst possible time.

Losing track of which devices are which. Mixed fleets — some multi-IMSI, some eUICC-and-eIM — need a clear inventory of which strategy applies to which device population. This kind of operational discipline is exactly what teams building an in-house eIM at carrier-grade reliability had to solve for themselves before offering it to customers. Without that discipline on your side too, provisioning decisions get made against the wrong assumption.

Figure 3 above walks through the order these questions should actually get resolved for any device before a provisioning decision is made.

The bottom line

Multi-IMSI and eIM aren’t competing standards, they’re tools for different jobs, and most active fleets will run both across their portfolio simultaneously without either one interfering with the other. The mistake worth avoiding is picking one as a blanket policy for every device instead of classifying by eUICC capability and flexibility need first. Simplex’s xoSIM platform supports both IPAe and IPAd, so the classification work above doesn’t force a second vendor relationship once you’ve sorted your 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 eIM and Multi-IMSI: Can You Run Both Strategies at Once? first appeared on Simplex Wireless.