How to Configure Store-and-Forward on a Cellular Gateway

Enable Buffering and Preserve Timestamps

Turn on the gateway's store-and-forward or local buffering so that when the uplink is down, readings are written to local storage instead of discarded. The single most important detail is that each buffered reading keeps the timestamp of when it was measured, not when it was eventually sent, because a reading that arrives late but stamped correctly slots into the historian at the right moment, while one stamped at send time smears the whole outage into a single instant and corrupts the trend. The principle is laid out in the guide to store-and-forward telemetry.

Confirm the replay is ordered and complete. When the link returns, the gateway should forward the buffered readings in the order they were taken, so the historian reconstructs the outage period faithfully. Some gateways send a burst of batched readings on reconnect, which is efficient but must preserve order and timestamps to be useful; the batching mechanics are covered in the guide to a gateway uplink payload batch.

Size the Buffer to the Outage You Must Survive

Size the buffer against the worst outage you need to ride out, not the average. The storage needed is roughly the data rate times the outage duration you want to survive: a site that logs many points quickly and must survive a long outage needs a large buffer, while a slow-logging site surviving short drops needs little. Written symbolically, buffer capacity should exceed readings-per-period times the longest tolerable outage, so both a faster log and a longer outage push the buffer bigger. Under-size it and the buffer overflows during a long outage, and you are back to losing the oldest data.

Decide the overflow behavior deliberately, because it is a real choice. When the buffer fills, the gateway either drops the newest readings or overwrites the oldest, and which is correct depends on whether recent or historical data matters more for the site. For most trending, keeping the most recent data is usually preferred, but a compliance or event record may need the opposite. Set this on purpose rather than accepting the default, and size the buffer large enough that you rarely hit the decision at all.

Test With a Real Outage and Confirm No Loss

Prove it with a controlled outage. Drop the uplink, let the site generate a known set of readings for a defined period, then restore the link and confirm that every reading from the outage window arrives, in order, stamped with its original measurement time. Count them: the buffer either delivered the full set or it did not, and a store-and-forward that quietly loses a few readings on every drop is worse than one you know does not buffer, because it lulls you into trusting a trend with hidden holes.

Test the overflow edge too if the site's outages can be long: keep the link down past the buffer's capacity and confirm the overflow behaves the way you configured it, dropping newest or oldest as intended rather than crashing or corrupting. The overflow path is the one nobody tests and the one that bites during the long outage that store-and-forward exists to survive.

Once live, a platform such as Merobix receives the forwarded backlog after an outage and fills in the trend, so a store-and-forward site shows a brief flat gap that back-fills when the link returns rather than a permanent hole. Watching the backlog land confirms the buffering worked in the field, and a gap that never fills tells you the buffer was too small or the replay failed. The configuration sets up the safety net; the filled-in trend proves it caught the fall.

Frequently Asked Questions