Skip to main content

MAPS Handling of Satellite Links

MAPS Messaging is designed to handle the unique challenges of satellite communication, such as long latency, intermittent connectivity, and high transmission costs.

Key Features​

  • Protocol Agnostic Bridging
    Satellite-specific delays are hidden behind standard MQTT, AMQP, or NATS interfaces.
    Applications interact with MAPS as if they were on a normal low-latency network.

  • Retry & Queuing
    Outgoing messages are queued until a satellite session is active.
    MAPS manages retransmission windows automatically, tuned for GEO link behavior.

  • Timeouts & Acknowledgements
    Timeouts are configurable for seconds rather than milliseconds, aligning with typical satellite RTTs.
    Acknowledgements from the other end of the link are tracked to ensure reliable delivery.

  • Offline Resilience
    MAPS provides store-and-forward, allowing local ingestion and buffering of events even when the satellite link is unavailable.
    Buffered messages are flushed once connectivity is restored.

  • Cost Awareness
    MAPS can filter redundant or unimportant data before uplink, deduplicate events, and batch messages to minimize satellite transmission costs.

Data-Package Mechanism​

To move data efficiently across satellite links, both the modem end and the REST API end use a data-package mechanism:

  • Per-topic event capture
    For each topic or queue, MAPS can package either:

    • Only the most recent event, or
    • The last n events, depending on configuration.
    • Filtered events based on a simple filter or an advanced ML mode

  • Packaging & Integrity

    • Events are grouped into a data-package structure.
    • A CRC checksum is applied to detect corruption.
    • Data is compressed to reduce transmission size.
    • Data is encrypted to ensure confidentiality over satellite links.

  • Chunking for transport

    • Large data-packages are split into numbered chunks.
    • Chunks are transmitted sequentially over the satellite channel.
    • Missing chunks are detected and retransmitted automatically.

  • Reassembly at the other end

    • Chunks are reassembled into the original data-package.
    • The data is decompressed and decrypted.
    • CRC validation confirms integrity.
    • Events are published back into the correct topics/queues within MAPS.

Data-Package Flow​

Why It Matters​

This approach ensures:

  • Compression ratio on json/string based events compression is around 75% reducing the data required to send
  • Efficient transmission even on narrow-band links.
  • Integrity and reliability despite intermittent connectivity.
  • Consistency across both ends, whether using direct modem integration or REST APIs.

Applications never see the complexity — they simply subscribe and publish via MAPS, while the satellite-specific handling occurs transparently under the hood.

Future Releases​

Statistics / Topic​

We will be implementing "stats" based updates in that an event feed from a topic can be configured so that specific keys have

  • First value
  • Average value
  • Highest value
  • Lowest value
  • Last value
  • Number of values

This would enable remote monitoring systems to have a better understanding of values over times, especially important for things like sensor readings etc

Remote Updates​

With the remote site being out of range of internet updates, inband updates for

  • ML Models can be pushed down to the remote server to help focus the events reported
  • Server Updates with small changes to the server could be pushed down, security enabled, to update the remote end