Cellular IoT in Practice: What I've Learned Deploying SIM-Backed Gateways Internationally

Resensys ships sensors to customers in dozens of countries, and getting the cellular gateways to actually connect — APN configuration, carrier registration, jurisdiction-specific roaming quirks — has been a recurring teacher over the past four years. Here are the failure modes I've seen most often, the diagnostic patterns that actually work, and the surprising number of issues that come down to a misconfigured APN. It's also a brief tour of what “deployed cellular IoT” actually means once you cross a border, which turns out to be more complicated than “the sensor connects to a tower.”

The architecture, briefly

Resensys's deployments use a gateway-and-sensor pattern. Wireless sensors talk to a local gateway over short-range radio. The gateway then uses cellular backhaul — LTE/4G modem with a carrier SIM — to push data to the cloud. The customer mostly never thinks about the cellular layer because it works most of the time. The failure modes I'm going to describe are the cases where it doesn't, and the patterns I've learned for diagnosing them quickly.

The most common failure: APN misconfiguration

The most boring problem I see most often is an incorrect APN. The Access Point Name is the configuration that tells the cellular modem how to talk to the carrier's data network. Different carriers use different APNs. Different SIM types (consumer, IoT, M2M) often use different APNs even on the same carrier. International SIMs sometimes need carrier-specific APNs depending on which country the device is registering in.

The symptom is consistent: the device sees the cell tower, registers, attaches to the network, and then can't send any data. From the cellular layer's perspective, everything is fine. From the customer's perspective, the device is offline. From a debugging perspective, you check the APN before you check anything else.

The lesson here, if you're new to cellular IoT troubleshooting: a device that's “on the network” isn't necessarily “on the data network.” Registration and data attach are different states. APN issues live in the gap between them, which is why they don't show up as obvious failures unless you're looking for them.

International deployments add jurisdiction-specific quirks

Domestic deployments are mostly straightforward. International deployments are where the texture of cellular IoT gets interesting. A few of the things I've learned from deployments across multiple countries:

• Permanent roaming is restricted in some countries. A SIM that's roaming “sometimes” is normal cellular behavior. A SIM that's roaming “forever” — because the device is permanently deployed in a country other than the SIM's home country — is restricted by some carriers' agreements with local regulators. The result is that a SIM might work for the first few weeks of deployment and then stop working when the carrier's anti-permanent-roaming policy kicks in. The fix is to use SIMs from the right carrier for the deployment country, or to use multi-IMSI SIMs that can switch identities to behave like a local SIM.

• Some carriers prefer specific Radio Access Technologies. LTE-M and NB-IoT are common for IoT devices, but availability varies. A device configured to prefer LTE-M will fail to attach in a region where the local carrier doesn't support it well. The diagnostic is to check what RATs the carrier actually supports in the deployment region, then make sure the modem's preference list matches.

• Carrier handoff during travel is its own category. For a stationary deployment, the device picks one tower and stays. For a moving one (vehicle tracking, fleet monitoring), the device hands off between towers and sometimes between carriers. Handoff failures show up as periodic disconnections that look intermittent but are actually “happens every time the truck reaches the edge of carrier A's coverage.”

• Time zones and carrier billing cycles matter for usage tracking. A device that hits its data cap will stop transmitting until the cap resets. If you're running a fleet across time zones, the cap resets aren't synchronized, and customers will report “my devices stopped working at 8 PM” for reasons that look mysterious until you realize it's the carrier's billing cycle in the device's home time zone.

The diagnostic pattern that actually works

When I'm called in on a customer's connectivity issue, the diagnostic goes from broad to narrow:

First, is the device powered on and the modem responding? Trivial-sounding, but I've spent more time than I care to admit on “offline” devices that turned out to be unplugged.

Second, is the SIM inserted and recognized by the modem? SIM removal, damage, or insertion issues account for a noticeable fraction of “device can't connect” cases. Modern SIMs (eSIM, embedded SIM) reduce this category but don't eliminate it.

Third, is the device registering on a carrier network? The modem's registration state tells you whether you're seeing a tower at all. If not, you're looking at coverage, antenna, or signal-strength issues. If yes, you've eliminated a whole category of physical-layer problems.

Fourth, is the device attached to a data session, with a valid APN and IP address? This is where most of the actual failures live. If the device is registered but not attached, you're almost always looking at APN or carrier policy issues.

Fifth, can the device actually send data through the established session? If attach is good but data isn't flowing, you're looking at firewall, DNS, or destination-server issues — problems on top of the cellular layer rather than within it.

Each of these layers has a distinct diagnostic vocabulary, and skipping layers is the most common mistake in cellular IoT troubleshooting. The temptation is to jump straight to “why isn't my data getting through?” when the actual problem is “the device never finished registration in the first place.” The discipline is to start at the bottom of the stack and walk up.

What I'd tell someone starting out

Cellular IoT troubleshooting is the kind of skill that develops slowly through accumulated incidents rather than from any single source. A few things I'd suggest if you're getting into this work:

Read your modem's AT command set documentation. Even if the application talks to the modem through an abstraction layer, knowing what AT commands return state for registration, attach, and signal quality lets you diagnose much faster than relying on the abstraction's logging.

Keep a SIM and modem on your desk that you can test against. Diagnosing a deployment issue from a customer report is hard. Diagnosing it from a customer report while you also have a working device in front of you to compare against is much easier.

Build a mental model of the carrier infrastructure layer. Cellular IoT failures rarely live in the device alone or in the data center alone — they live in the carrier's network in between, which is invisible to most software engineers most of the time. Spending time understanding what's actually happening at that layer will make you significantly better at diagnosing failures, especially the international ones.

The bigger picture

Cellular IoT is increasingly the substrate of how the physical world reports back to the digital one. Sensors monitoring infrastructure, fleets of trackers across continents, agricultural systems in remote locations, smart-city deployments that span jurisdictions — all of it depends on a cellular layer that mostly works, sometimes doesn't, and breaks in ways that are surprising the first dozen times you see them.

The good news is that the failure modes are finite. After enough deployments, you start to recognize the shapes of common problems before customers fully describe them. APN issues feel one way; permanent-roaming issues feel another; carrier-handoff issues feel a third. That recognition is what experience in this space buys you, and it's a fun skill to develop — not unlike learning the shapes of common bugs in any other technical domain.