How Should Operators Rate Store-and-Forward Satellite IoT Traffic Accurately?

What is store-and-forward satellite IoT, and why does it change billing?

Satellite IoT is one of the most practical near-term uses of non-terrestrial networks (NTN), which deliver connectivity through satellites rather than cell towers. Asset trackers, agricultural sensors, maritime containers and remote utility meters all need connectivity in places towers will never reach. 3GPP NTN specifications support this through store-and-forward operation: a device caches its readings locally, then transmits them in one burst once a satellite passes overhead.

Because usage from these devices is sparse and irregular rather than continuous, operators are not billing it like a phone plan. Many are moving to per-message or per-satellite-pass pricing, where the charge depends on how many times a device checked in and transmitted, not how many megabytes it used. It is a sensible model for the traffic pattern, but a different proposition for the rating engine.

What goes wrong when a rating engine bills a batch as a single event?

A rating engine built for continuous, per-session usage tends to see one transmission when a store-and-forward device connects. But that single transmission can contain readings from several hours, or several separate sensor events, bundled together because the device was waiting for a satellite. If the engine bills the transmission as one event, it is not billing for what actually happened. The revenue leakage runs in two directions:

• If charges are not based on the count of events inside a batch, the operator bills for one pass when, say, five billable readings were delivered.
• Mismatched charges. If events are counted without applying the satellite-pass tariff the customer is on, the operator charges for usage that does not match what the device actually did.

Satellite IoT is being planned at very large scale, with thousands and eventually millions of low-cost sensors, so even a small per-device counting error becomes a meaningful revenue gap across the base. And because the data arrives late and in batches, this leakage does not show up as an obvious error. It quietly understates or overstates revenue, month after month.

How can operators rate store-and-forward traffic correctly?

The core principle is to rate the events inside a transmission, not the transmission itself. Controls that can be considered:

• Preserve event-level detail through the batch. Make sure the timestamps and event markers a device records before caching survive all the way through mediation, so the rating engine sees individual readings, not one bundled file.
• Rate at the right unit. Treat per-message and per-satellite-pass tariffs as their own rating models, with configurable templates, rather than forcing satellite IoT traffic through logic designed for per-MB or per-minute billing.
• Reconcile counts, not just charges. Regularly compare the number of events the network reports a device generated against the number actually billed, so drift between the two is caught early.
• Watch the pattern across the fleet. A rating issue repeated across a large device fleet is a real revenue problem, so monitor is as a trend.

How Subex approaches satellite IoT rating assurance

Subex extends revenue assurance rating verification to store-and-forward satellite IoT at the event level. Batched transmissions are unpacked into individual events, each event is verified against the tariff the customer is actually on, per-message and per-pass rating models are supported alongside usage-based ones, and network-reported event counts are reconciled against billed counts so any drift surfaces as an exception before it compounds across the device base.