SMS is a poor channel for sensor data and an excellent one for signalling. Deployments that treat the two as the same job end up paying per-message rates for telemetry that a data session would carry for a fraction of the cost.
This article sets out why SMS remains useful for signalling, how data backhaul differs from message signalling, how the SIM estate is managed for devices that are physically distributed, and what to select hardware for when the deployment spans many sites.
Why are industrial modems still useful for IoT sensor data signalling?
Because it works when a data session does not.
Short messages travel over the signalling channel and do not require a data session, an IP address or a working configuration on the device.
That property is what makes SMS valuable for a narrow set of jobs: waking a device, requesting a status, delivering a configuration change, or reporting an event when the data path is down. None of those need volume, and all of them benefit from the fact that a message arrives without the device having to establish anything first. The framework that carries the message is defined in ETSI TS 123 040, and the subscription states a device passes through before either a message or a session is possible are defined in 3GPP TS 24.301.
The limit is equally clear. A message carries a small payload, arrives with no ordering guarantee relative to other messages, and costs a per-message rate that scales with the number of devices and the reporting frequency. For a fleet reporting every minute, the arithmetic is unworkable; for a fleet reporting an exception, it is the cheapest reliable channel available.
| Job | Channel that fits | Why |
|---|---|---|
| Exception or threshold alert | SMS | Rare, small and must arrive without a session |
| Wake, status request, configuration change | SMS | Signalling rather than payload |
| Continuous telemetry | Data session | Volume makes per-message cost unworkable |
| Firmware or bulk update | Data session | Size and integrity requirements |
| Fallback when data is down | SMS | Arrives without an established session |
Data backhaul versus message signalling
They are different products on the same subscription.
Backhaul moves volume and is priced by it, while signalling moves events and is priced per message or per event.
The design decision is therefore about where the boundary sits. A device that reports a measurement every minute is doing backhaul and should use a data session with a tariff sized for the volume. A device that reports when a threshold is crossed is doing signalling. The failure mode in between is a deployment that has no threshold and reports everything, which converts a signalling job into a backhaul job at signalling prices.
The second half of the boundary is what happens when backhaul fails. Where a device cannot establish a data session, a message that reports the fact is what turns silence into information, and it is the reason the estate keeps a signalling capability even when the primary channel is data. Designing that report is a small piece of work, and omitting it leaves a deployment that cannot distinguish a device with nothing to say from a device that has stopped working.
SIM estate management for distributed devices
The estate is the operational problem, not the radio.
A deployment of many devices in many locations accumulates subscriptions that have to be inventoried, switched between operators and retired.
Three practices keep that manageable. Key the register on the card and the network identity, described in ITU-T E.118 and ITU-T E.212, so that a device can be located by either field. Record the purpose and owner of each device rather than only its location, so that a subscription whose device has been removed can be retired. And reconcile the register against reported state on a schedule, because a device that has been unplugged looks the same in the register as one that is still installed.
Where the deployment spans markets, the estate is per market for the reason that applies to any subscription: the number belongs to the issuing operator, and capacity in one market cannot cover another. That makes the plan a set of local arrangements rather than a global pool, and it makes the per-market record the primary document rather than an appendix.
Registration and roaming across sites
Registration is local, and coverage is too.
A device registers with whatever network covers its location, and the quality of that registration depends on the site rather than on the hardware.
Two consequences follow for a distributed deployment. The first is that performance varies by site, so a device that works at one location may be marginal at another, and the commissioning record should note the conditions at each. The second is that radio characteristics under load matter, and the reference for terminal transmission and reception is 3GPP TS 45.005, with the harmonised terminal standard for the European market published as ETSI EN 301 511. A device specified for one environment may be unsuited to another, and the specification is what says so.
Roaming adds a commercial dimension to the same question. A device that roams across borders depends on an agreement between operators, and the arrangement can change without any hardware changing. Where a deployment spans a border, the roaming behaviour should be measured rather than assumed, and the measurement should be repeated when the subscription arrangement changes.
Alert delivery when a device goes dark
Silence has to be detectable.
A device that stops reporting produces no event, so the absence of data has to become an event somewhere above the device.
The standard pattern is a heartbeat: each device reports at a defined interval, and the platform raises an alert when the expected report does not arrive within a defined tolerance. The heartbeat interval and the tolerance determine how quickly silence becomes information, and both are design decisions rather than defaults. For a device on a signalling channel, the heartbeat is itself a message, so the interval is also a cost decision; for a device on a data session, the same calculation applies to the tariff.
Where the platform can also reach the device, a status request on the signalling channel distinguishes the two causes of silence: a device that is present but not reporting, and a device that is not reachable at all. That distinction is what determines whether the response is a configuration change or a site visit, and it is worth designing before the first device goes dark. Record-keeping practice for the alerts and their outcomes is covered in NIST SP 800-92.
Hardware selection criteria for IoT
Select for the environment and the estate, not for the peak rate.
The criteria that matter for a distributed deployment are durability, remote management and the cost of the subscription behind each device.
Four criteria are worth weighing together. The environmental range the device is specified for, because an installation in a cabinet or an outdoor enclosure is a different physical problem from one in a room. Remote management, because a device that requires a site visit for a configuration change is expensive at scale. The signalling and session capabilities the design needs, which differ between a device that reports exceptions and one that streams measurements. And the SIM arrangements, because a large estate is constrained by the commercial terms as much as by the hardware.
Where the deployment has an existing estate, the selection question is usually about the replacement cycle rather than about a new build: which devices to replace first, and what to standardise on. Standardising on a small number of models reduces the spare pool and the configuration surface, and both of those are larger operational costs than the unit price difference between candidates.
A deployment outline
The outline separates the signalling workload from the data workload and then designs them independently, because the two have different cost profiles and different tolerances. Each step produces a decision that constrains the next, starting with what the device has to report and how often.
- Separate the jobs into signalling and backhaul, and assign a channel to each.
- Define the threshold that decides when a device reports, and the heartbeat that defines silence.
- Record the environmental conditions at each site, and check the device specification against them.
- Key the register on the card and network identity, with a purpose and an owner.
- Reconcile the register against reported state on a schedule.
- Plan the estate per market, with the operator arrangement recorded for each.
- Decide what a status request can determine, and design the response for each outcome.
The outline treats the estate as the subject and the hardware as one of its components, which is the correct emphasis for a distributed deployment. Most of the operational cost of an IoT fleet is in managing the subscriptions and the devices rather than in the radios.
One further practice belongs with the estate: record why each device exists. A register that lists a location and a subscription but not a purpose becomes a list of things nobody dares remove, and the estate grows by accumulation in the same way an unmanaged SIM inventory does. A purpose and an owner against each device turns decommissioning into a routine task rather than a decision nobody will take.
Where the deployment spans several regions, keep the signalling plan per region as well. The channel that works for exception alerts in one market may be more expensive or less reliable in another, and the difference is usually commercial rather than technical. The per-region record is what lets a new region be added by copying a template rather than by repeating the analysis.
Separate signalling from backhaul before you size anything. Send your device count, reporting profile and market list to service@telarvo.com, or review the published configurations on the SMS modem range and the SK-SMS Gateway range. Telarvo publishes the SIMBANK and SIMPOOL ranges on its product pages, and the configurations referenced above come from those listings.
FAQ
Should IoT devices report by SMS or over a data session?
It depends on the job rather than on the device. Exception alerts and signalling fit SMS, because they are rare, small and must arrive without a session. Continuous telemetry belongs on a data session, because the per-message cost of signalling scales with every reading rather than with every event. Record the decision per device class rather than per site, because the workloads differ within one deployment and the cost profile follows the workload.
How do we know when a device has gone dark?
Through a heartbeat with a defined interval and tolerance, so that the absence of a report becomes an alert. A heartbeat is itself traffic, so the interval is a cost decision as well as a detection one, and both should be set deliberately rather than left at a default. Set the interval from what a device does rather than from the update rate, and record the reasoning with the configuration.
Can one SIM estate cover devices in several countries?
The estate can be administered centrally, and the subscriptions are still local, because a number belongs to the operator that issued it. Capacity in one market cannot cover another, so the plan is a set of per-market arrangements rather than one global pool. Keep the per-market arrangements in one register, because the capacity in one market is what a later plan will try to assume.
What matters most when choosing hardware for a distributed estate?
The environmental range, remote management, the signalling and session capabilities the design needs, and the commercial terms behind each subscription. Port density and peak rate matter less, because most IoT workloads are constrained by the cost of the subscription rather than by the capabilities of the radio. Ask for the environmental class in writing, because an enclosure that is adequate for an office is not automatically adequate for a cabinet at a roadside site.