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 Myriota Cloud, to when it is transmitted to the target device over the downlink.
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.
For typical short messages, the Myriota UltraLite Network offers a median message latency of 4 hours and a 90% latency of 8 hours. Median latency means that half of all messages are expected to arrive within this time.
For more information about message size, segmentation, queue usage, and transmission behaviour, see the Message Management article.
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 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 processed and sent to Myriota Cloud.
- 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 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 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. If your application requires confirmation, implement an application-level acknowledgement by scheduling an uplink message after the Device Control message is received.
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.
- Use the Module System API BeforeSatelliteTransmit() to schedule message transmission and sensor readings just prior to a satellite pass.
- 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.