SMS in IoT: What is Changing, and What We are Doing About It

TL:DR

• SMS is still critical in IoT, but 2G/3G sunsets mean it no longer works the same way on every network.
• Before relying on SMS, test it with the real device, network, and radio technology in each target market.
• Soracom closes SMS to outside senders, adds message tracking, and lets devices send SMS as a backup when data fails.

---

Working in Telco, you hear the same story every few weeks: A customer has trackers or terminals in the field, something has stopped behaving, and the recovery plan is “we will just send it an SMS.” Then the SMS does not land, the error log says absent subscriber, and nobody in the room is sure what to do or whose problem it is.

SMS may be the oldest thing in the IOT suite, but it is still one of the most commonly used. It is also the part of the stack that has quietly evolved the most in the last few years and most of that change can seem invisible – until the SMS just stops delivering. In this piece, we will look at how SMS actually gets to a device, the three different methods of delivery, and what it means if you have devices in the field that depend on it.

---

Why SMS is Still Here

SMS is not data, and that is the whole point of it.

A traditional SMS, or short message, rides the signalling channel rather than a data bearer, meaning it works without a PDP context (data session). A modem in a low power state can be paged, wake up, and take delivery without ever creating a data session. The payload is tiny, 140 octets of user data, which is 160 characters in GSM-7.

 That combination is why SMS refuses to die in IoT. It is often the wake-up mechanism for a device in eDRX or PSM. It is the configuration channel for an enormous percentage of trackers, alarm panels, and industrial gateways. These types of devices typically ship with a set of AT configuration commands or a proprietary SMS command set, often without other means if setting the device up. It is how many SIM-level OTA’s get pushed to the card. When a device cannot get a data session up, SMS is often the only remaining door to the device.

The awkward part is that the path to that door is being repaved underneath us, network by network.

---

Three Ways an SMS Reaches a Device

Same message, same encoding, three completely different transports. If you have ever wondered why SMS works on one network and not another on the same device, this could be why.

Traditional SMS, over the circuit-switched core.
The classic path. Your SMSC does a Send-Routing-Info-for-SM to the HLR over a protocol called GSM MAP. This finds the serving MSC/VLR, and sends the forward short message over to the VLR for delivery. 

This is often referred to as the “Store and forward” method, and the SS7 protocol underneath has been around over thirty years, with all other methods having been built around it. 

Before we move further, let’s make a quick detour to talk about LTE and other such technologies. They use something called Diameter signalling, instead of a traditional GSM MAP. In the following sections I will use terminology such as SGs and SGd. These are called Diameter interfaces, and they are used to make the protocol do different tasks within the same flows. Knowing the exact definition of each is not critical to those outside of the MNO world, as a simple “SMS over diameter” is often enough.

For LTE, this got extended with SGs: the MME talks to the legacy MSC (these are the components within a 4G and 3G that control the routing of messages to the SIM) and the message is delivered to the device over NAS signalling. It works well, but note what it depends on. There is still a traditional MSC in the picture. When an operator decommissions its full 2G and 3G core, that MSC -and anything hanging off SGs – goes with it too.

SMS over SGd, sometimes called SMS in MME.
This is the 4G-native replacement, defined in the 3GPP standards. The LTE core speaks Diameter directly to the SMSC over SGd, with additional diameter between the SMSC and the 4G core taking over the routing lookup that occurs in traditional telco. The MSC is gone from the path entirely. The device side is unchanged. It is still SMS over NAS, still the same CP and RP layers, so devices do not need to know anything about it.

The reason SGd is significant is due to the roaming landscape. SGs does not cross network borders, but other diameter protocols do. SGd can use the same Diameter layers and DRAs that already carry roaming signalling, so a visited network can deliver to a home SMSC without either party keeping legacy kit alive. The GSMA has landed on SMS over Diameter as the sustainable option for LTE and 5G, with SGs treated as an interim measure.

SMS over IMS, what most people mean when they say VoLTE SMS.
Here, the message is carried in a SIP Message, and an IP-SM-GW interworks it back to the SMSC. The device has to register to IMS and advertise the capability, Adding the +g.3gpp.smsip tag in the Contact headers, usually over a separate IMS APN with VoLTE enabled.

For handsets, that is fine – for IoT, not so much. It requires a full IMS and SIP stack on the module, which cheaper LTE-M and NB-IoT chipsets typically do not have, and it is a heavy way to move 140 octets. It’s no simpler with 5G, either. Rather than standardizing on IMS, 5G core added a service-based interface that does not widely support roaming yet. So there are arguably as many as four transport methods in the field, not one.

---

What That Means if You Have Devices Out There

The practical consequence is that SMS availability is no longer a certain fact. It is now dependent on the SIM, the device, the radio technology, the visited network, and the roaming agreement, evaluated together at the moment you press send.

A few things I would check before designing anything that depends on SMS.

Whether the device even registers for SMS.
This one catches people off guard constantly. If the modem is configured PS-only, it may never request SMS registration – meaning the device will sit there ONLINE, happily passing data, unable to receive a single message. For typical LTE devices that support combined attach, is generally what you want, because it requests both EPS and non-EPS registration while staying data-centric. 

Whether the visited network offers SMS over NAS at all.
In markets that have already sunset 2G and 3G, this depends entirely on whether that operator stood up SGd and exposed it to roaming partners. Some did it early and cleanly. Others have not, and that is where IoT fleets get stranded. France is the near-term one to watch in Europe, with all three operators ending 2G in 2026.

Whether SMS is even available on your radio technology.
NB-IoT is the obvious trap: SMS is often not available on NB-IoT at all. Be sure to test in the destination market rather than on your desk. A device that takes SMS perfectly on a UK network can fail completely in Spain.

---

How Soracom Keeps SMS Safer

This point is more important than it may seem, because it comes up in almost every security review I sit in. I mentioned earlier that most devices come with a set of AT commands or SMS commands you can use to configure or change settings on the device. Almost all networks leave that door open, and it’s up to you to set passwords per device to stop people getting to it. 

Soracom SMS is a closed loop, not a public messaging service. Three paths are supported, and nothing else:

• Platform to SIM. From the User Console, API or CLI, to a SIM in your own account. Only the operator that owns the SIM can send to it, and every API call is authenticated with credentials and SAM permissions behind it.
• SIM to SIM. Between IoT SIMs registered to the same operator.
• SIM to platform service. From a SIM to Beam, Funnel, Funk or Harvest Data.

Everything else is refused. A SIM cannot text an ordinary mobile number, and our SMSC does not forward messages originating from the external number space, so a leaked or guessed MSISDN does not give anyone a way in.

I would not claim that makes SMS an entirely secure protocol, because it is not. There is published work showing that IoT devices which authenticate an administrator by the originating number of a message can be fooled by origin spoofing, and plenty of field kits still accept clear-text passwords over SMS. What the closed number space does is remove the open front door and make every message that reaches your device attributable to an authenticated caller on your own account. That is accountability rather than cryptography, and for a command channel it is worth a great deal.

---

More Visibility, and Bulk Sending

The gap has always come from what happens after you press send. You’ll probably get an error log entry if delivery fails, and not much else. If you have ever tried to work out whether a batch of configuration messages actually delivered across a few hundred SIMs, you will know the feeling.

Within Soracom, that is being addressed. We have some new features currently in early beta access. The first phase is a per Subscriber SMS view in the console covering history, status and per-message detail, so you can see what was sent, to which SIM, and how it ended up, without reconstructing it from error logs. The phase after this is the ability to Bulk send and manage through the console. If you are running fleet-wide reconfiguration today by looping the API and keeping your own record of what came back, this is aimed squarely at you.

---

Sending the Other Way, With Beam

The direction people forget is MO SMS (Mobile Originated, from the device out). A device can send an SMS into the platform and have it come out as an HTTPS request to your application, with no data session involved.

Each service has a fixed short number: Beam is 901011, Funnel 901021, Harvest 901031, and Unified Endpoint 901001. Point the device at Beam’s number and configure the destination in the group, and Beam converts the message into an HTTP or HTTPS POST to your endpoint. The device needs no TLS stack, no certificates and no data attach.

The pattern I like most here is HTTP first with SMS as the fallback. The device tries its normal POST, and if the data attach fails or the POST times out, it sends the same payload as an SMS to the platform instead. The telemetry still arrives, over a completely different transport, and you find out the device is alive rather than assuming it is dead.

---

Where This Leaves Us

SMS in IoT is not going away, but the assumption that it simply works everywhere has already expired. The transport underneath it is fragmenting into circuit-switched legacy, SGd, IMS and 5G NAS, availability now varies per network and per radio technology, and the operators sunsetting 2G and 3G are the ones setting the pace.

If SMS is load-bearing in your deployment, treat it like any other dependency. Know which transport your target networks actually offer, confirm the device registers for it, and make sure you can see what happened to every message you send.

---

If you would like to speak to us about how we can help your SMS-based deployments, please get in touch.