Overview
In this article:
The Myriota UltraLite Network is designed for low-power, long-life IoT applications that send small amounts of data via satellite. Message latency depends on several factors, including satellite availability, device sky view, message size, queue usage, and network conditions.
For uplink messages, latency is measured from when a message is scheduled for transmission by the Myriota Module using ScheduleMessage(), to when the message is received at the device Destination.
For Device Control messages, latency is measured from when a Device Control message is scheduled in the Myriota Cloud, to when it is transmitted to the target device over the downlink.
Uplink Message Size and Format
The Myriota UltraLite Network supports both 20-byte messages and messages larger than 20 bytes.
A 20-byte message is the standard message size and generally provides the best latency performance.
Messages larger than 20 bytes require additional transmission resources. Depending on the message size, the message data may be transmitted across multiple satellite opportunities, with redundancy included. As a result, larger messages can have higher latency and power consumption than 20-byte messages.
For more information about message size, segmentation, queue usage, and transmission behaviour, see the Message Management article.
Uplink Message Latency
For uplink messages sent from a Myriota-enabled device to a Destination, the expected latency depends on the size of the scheduled message.
| Message Length | 90% Latency | Expected Behaviour |
|---|---|---|
| 20 to 399 bytes | 8 hours | Standard UltraLite latency profile. Typical 20-byte messages may be delivered sooner in practice because less data needs to be transmitted. |
| 400 to 799 bytes | 12 hours | Increased latency due to the larger payload size and additional transmission requirements. |
| 800 to 1,500 bytes | 24 hours | Highest supported uplink payload range, with the longest specified latency. |
90% latency means that nine out of ten messages are expected to be delivered within the specified time, provided the device is operating within the service conditions, the message queue is not overloaded, and the recommended daily data rate is not exceeded.
How Uplink Latency Works
There are two key parts to uplink latency on the Myriota UltraLite Network:
- satellite revisit time
- satellite network to Myriota Cloud latency
Satellite Revisit Time
Satellite revisit time is the time between when a message is scheduled on the Myriota Module and when a satellite passes within clear sky view of the device.
- A message is queued by the User App on the Myriota Module.
- A satellite from the Myriota Network passes within clear sky view.
- The message is transmitted to the satellite.
Satellite Network to Myriota Cloud Latency
Once a message has been received by a satellite, the satellite must come within clear sky view of a Myriota ground station before the message can be forwarded to the Myriota Cloud.
- A message is received by the satellite.
- The satellite continues on its orbital path until it comes within transmission distance of a Myriota ground station.
- The satellite transmits the message payload to the ground station.
- The message data is sent to the Myriota Cloud for processing.
- The Myriota Cloud forwards the message to the device Destination.
Downlink Latency and Device Control
The Myriota Module is capable of receiving messages from the Myriota Network using the downlink.
The downlink is used for Myriota network updates, such as time, satellite orbital parameters, radio configuration, regulatory permission updates, and security updates. It is also used by Device Control to send user-defined messages from the Myriota Cloud to a Myriota-enabled device.
Device Control messages are scheduled using the Device Manager UI or Cloud API. Once scheduled, the message is queued in the Myriota Cloud, uploaded to the satellite constellation, and then transmitted to the target device when a suitable downlink opportunity is available.
For Device Control messages, you can expect:
| Downlink message type | Median latency | 90% latency |
| Device Control message | 24 hours | 36 hours |
Device Control messages have a maximum size of 100 bytes, and only one Device Control message can be scheduled per device per 24-hour period.
A Device Control message marked as complete means the message has been transmitted to the device. It does not necessarily confirm that the user application has received or processed the message. A device may also receive a Device Control message before the message status changes to Complete in the Myriota Cloud.
If your application requires confirmation, implement an application-level acknowledgement by scheduling an uplink message after the Device Control message is received and processed.
Minimising Latency
To minimise latency and ensure data is as fresh as possible:
- Deploy your Myriota device with a clear sky view. See the Myriota Deployment Guide for details.
- Keep uplink payloads as small as practical.
- Avoid overloading the Module message queue.
- Do not exceed the recommended daily data rate for the service.
- Use Warm Start rather than Cold Start where possible. See the Network Info: Warm Start vs Cold Start article for details.
- For Device Control, ensure the device has suitable RX performance and a clear sky view.
- For time-sensitive Device Control workflows, design the application to send an uplink acknowledgement once a control message has been received and processed.