For an asset so remote that no cellular tower reaches it - a wellhead in the backcountry, a pipeline valve in the desert, a buoy at sea - the connection often has to come from space. Iridium Short Burst Data is a satellite service built precisely for that case, moving tiny messages to and from anywhere on Earth. It is not fast and it is not cheap by the byte, but it works where nothing terrestrial does. This guide explains what SBD is, its mobile-originated and mobile-terminated message model, how its per-byte cost structure works, and why report-by-exception is essential to keep the satellite bill under control.
Iridium SBD in one line: Iridium Short Burst Data (SBD) is a satellite messaging service that carries small data messages between a remote field device and a central system over the global Iridium constellation, without needing any cellular or terrestrial coverage. It uses a mobile-originated model for data the device sends up and a mobile-terminated model for data sent down to the device, is billed largely per message and per byte, and is intended for small, infrequent payloads from truly remote assets.
Iridium is a satellite constellation whose spacecraft orbit low enough and are numerous enough to provide coverage over the entire surface of the planet, including the poles, oceans, and empty interiors where no cellular network exists. Short Burst Data is the service designed to send small messages across that constellation. Rather than trying to move large amounts of data, SBD embraces the opposite: it carries short bursts, typically small payloads on the order of a modest number of bytes per message, which is exactly the shape of a telemetry reading - a pressure, a level, a status word, a position.
The value of SBD is coverage, not capacity. Its whole reason to exist is to connect assets that terrestrial links cannot reach, so its design accepts small payloads and modest latency in exchange for the ability to communicate literally anywhere. Messages are relatively low-latency for a satellite service - a burst can cross the network in seconds rather than the long delays associated with far-off geostationary links - which makes SBD responsive enough for periodic monitoring and even for time-sensitive alarms from a remote site, provided the payloads stay small.
This makes SBD a natural fit for the most isolated tier of SCADA telemetry. Where a site has any cellular or radio option, that is usually cheaper and higher-capacity; SBD comes into its own precisely at the sites that have no such option at all. It is the connection of last resort that happens to work everywhere, which is exactly what a remote, unmanned asset with no other path back to the control room needs.
SBD moves data in two directions, and it names them from the device's point of view. A mobile-originated message is one the field device sends up - a reading, an alarm, a status report - that travels through the constellation and is delivered to the central system, typically arriving at a host application or being forwarded on to wherever the data needs to go. This is the workhorse direction for telemetry, because most of what a monitoring site does is report its own state outward, and mobile-originated messages are how those reports leave the site.
A mobile-terminated message travels the other way: it is queued by the central system for a particular device and delivered to it when the device next checks in or is reachable. This is how a host sends a command, a configuration change, or an acknowledgment down to a remote unit. Because a device may be conserving power and not constantly listening, mobile-terminated messages often wait in a queue until the device initiates contact, at which point any pending downlink is delivered along with the device's next uplink. The pattern is device-driven: the remote unit reaches out on its schedule, sends what it has, and collects whatever is waiting for it.
This two-way model gives SBD enough capability to support real monitoring and control at a remote site while keeping the traffic small and orderly. The device reports outward with mobile-originated messages and receives instructions with mobile-terminated ones, and because both directions are message-based and small, the whole exchange fits the constrained, power-conscious reality of a satellite-connected field unit that may only wake periodically.
The economics of SBD are fundamentally different from a flat-rate cellular plan, and they drive how the system must be designed. SBD is billed around the messages and bytes actually sent, so every message and every byte has a direct cost, and a device that chatters or sends bloated payloads runs up a bill quickly. This is the opposite of a bandwidth-rich link where an extra field or an extra report costs nothing - on SBD, traffic is money, and the cost scales with how much and how often the device transmits.
The essential response to this cost structure is report-by-exception: instead of sending readings on a rigid fast timer, a satellite-connected device sends a report only when something meaningful changes - a value crosses a threshold, a state flips, an alarm sets - plus an occasional heartbeat to prove it is still alive. Between events the device stays quiet, and because most monitoring points are stable most of the time, this collapses the message count dramatically compared with constant polling. Payloads are also packed tight, encoding a reading in as few bytes as possible, so that each message that does go out is as cheap as it can be. Together, exception reporting and lean payloads are what keep a satellite telemetry bill sane.
For a cloud SCADA platform such as Merobix serving remote oil and gas and other isolated operations, SBD is the backhaul for the sites that have no other way to connect, and the platform's job is to make exception-based satellite telemetry work well. That means ingesting sparse, event-driven reports rather than expecting a steady stream, distinguishing a healthy quiet site from a failed one using heartbeats, and letting operators send commands as mobile-terminated messages that the remote unit collects on its next check-in. Designed this way, an operator gets trustworthy visibility and control over an asset that no cellular network can reach, without the satellite bill spiraling out of control.
SBD connects truly remote field assets that have no cellular or terrestrial coverage - backcountry wellheads, desert pipeline valves, offshore equipment - by carrying small telemetry messages over the global Iridium satellite constellation. It is used for periodic readings, alarms, and remote commands where the payloads are small and infrequent. Where any cellular or radio option exists it is usually preferred, so SBD serves the most isolated sites.
The names are from the device's perspective. A mobile-originated message is one the field device sends up - a reading, alarm, or status report - to the central system, and it is the main direction for telemetry. A mobile-terminated message is queued by the host and delivered down to the device, used for commands and configuration, often waiting until the device next checks in to collect it.
Because SBD is billed largely per message and per byte, so constant reporting runs up a large bill. Report-by-exception sends data only when something meaningful changes, plus an occasional heartbeat, which drastically cuts the number of messages since most monitoring points are stable most of the time. Combined with tightly packed payloads, exception reporting is what keeps a satellite telemetry bill under control while still capturing the events that matter.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.