Protocol
Introduction
Astrocast, in partnership with Airbus and Thuraya, is oprerating a network of leading-edge nanosatellites in Low Earth Orbit to provide cost-effective IoT services to the 90% of the world not covered by cellular systems.
Uplink message
An uplink message is a message transmitted from an Astronode S module to an Astrocast satellite.
Message data format
Each uplink message can include between 0 and 160 bytes of user data. An additional 8 bytes of geolocation data can be sent per uplink message without impacting the user data size. What's more, the geolocation data will be available and displayed in the Astrocast Portal. The Astrocast API will return latitude and longitude properties on messages retrieved.
| Geolocation data | User data |
|---|---|
| 8 Bytes | 0 - 160 Bytes |
Geolocation data format
| Byte offset | Format | Name | Description |
|---|---|---|---|
| 0 | Int32 | Latitude | Degrees latitude * 107 The valid range is between -90° to 90° |
| 4 | Int32 | Longitude | Degrees longitude * 107 The valid range is between -180° to 180° |
Acknowledgement
The satellite sends an ACK message back to the module to confirm it received the uplink message.
Downlink Command
A downlink command is a command initiated by API or in the Astrocast portal, and transmitted via an Astrocast satellite to the receiving Astronode S.
A command is always received after sending an uplink message. A device not sending any uplink message will not receive any downlink command.
Command data format
Each command may contain either 8 or 40 bytes of user data.
| User data |
|---|
| 8 or 40 Bytes |
Acknowledgement
The Astronode S module sends an ACK message back to the satellite to confirm it received the downlink command. The acknowledgment will then be displayed in the Portal/API as Received Date.
End-to-end Latency
The current satellite constellation can provide an average latency of 5-7 hours to any device on the planet.
The Astrocast Latency represents the following:
Satellite revisit time
- Your asset enqueues a message in the Astronode S
- The Astronode S waits for the next satellite pass opportunity
Satellite-to-Cloud Latency
- The message is stored onboard a satellite
- A ground station collect the message
- The message is decoded into the Astrocast Data Service
- The message is delivered in the Astrocast Portal and via API
Radio Frequencies
L-band spectrum
Astrocast is the only NewSpace IoT LEO network with access to the L-band spectrum.
Characteristics
L-band is the radio spectrum from 1 to 2 gigahertz (GHz) and it is the most efficient spectrum for Satellite M2M/IoT communication.
It has superior performance characteristics for IoT, such as smaller antennas, lower-cost RF components, better signal propagation (no rain fade, lower power requirements), and fewer interference risks than other bands.
| RF Path | Frequence Min | Frequence Max |
|---|---|---|
| Uplink (Tx) | 1626.5 MHz | 1660.5 MHz |
| Downlink (Rx) | 1525.0 MHz | 1559.0 MHz |
Ephemerides
Ephemerides are used by the modules to calculate next passes and avoid seeking/searching for a satellite continuously.
This feature is active by default but can be deactivated.
The command details can be found here: CFG_W Configuration Write.
High-level operation
At each pass, the satellite broadcasts the following to all modules in range:
- Current UTC Time
- Number of satellites in the constellation
A module updates its ephemerides information every time it receives a broadcast message.
When an asset requests to send a message, the module wakes up only in the time windows it expects a satellite to be in range. If after 24 hours a message has not been sent, the module will wake up and continuously search for a satellite pass.
The ephemerides system should be deactivated in 2 cases:
- If the device has access to a power supply and therefore has no power consumption constraints. It will provide the best possible latency.
- If the device is mobile from a protocol perspective - see below.
What is a mobile asset from a protocol perspective?
A mobile device is a device that is moving more than 1,000 kilometres between 2 communications.
A fixed device is either a stationary device or a device that is moving in a region smaller that 1000 km diameter.
This distinction is important when deciding to use or not use the ephemerides feature:
- If the ephemerides feature is ON and the device is moving great distances, then the device may not wake up when there is a satellite pass.
- If the ephemerides feature is OFF and the device is not moving, then its power consumption could increase significantly unnecessarily.
Time synchronization
- Time information is included in the broadcast message.
- The Astronode S internal Real Time Clock (RTC) is synchronized with every satellite broadcast message that is demodulated.
- The RTC in the module is continuously running, the RTC time is updated in flash memory every time a new message is created.
- Initial time: Frame Number starts at Astrocast Epoch (1st January 2018 at 00:00:00).
Portal & API
Astrocast provides a web portal for Device Management, User Management and API Tokens Management.
An API is also available to retrieve your messages to your own platform.
Security
Astrocast is using a state-of-the-art secure protocol to keep your devices and transmissions secure. Each Astronode S has a private and unique encryption key. Messages are encrypted both on the application and the transport layer with industrial AES 256-bit encryption.
Layers of encryption
On Enqueue Payload Request PLD_ER, a new message payload is sent to the Astronode S via the UART serial port. Before storing the content in its message buffer, the Astronode S applies the application encryption (Key 1 in the figure above).
At the next satellite contact, the message is split in fragments and the Astronode S applies the transport encryption (Key 2 in the figure above) to the individual fragments before sending them over the network.
Only once all the fragments have arrived at the data management, they get decrypted and reassembled into the original messages. The fragments and reassembled messages are at all time stored on an encrypted database.
Messages are sent to the customer following API requests, secured by HTTPS.
Ground system
Communications between the ground stations and the Astrocast Data Management (DM) platform and portal are encrypted and authenticated to ensure data privacy and integrity.
Astrocast Portal
Users are required to log in using Multi-Factor Authentication (MFA).
Key management
Astrocast uses highly secured processes to exchange keys with its production partners and assesses their key handling and security. The keys are not meant to be changed or erased during lifetime of the products and therefore stored in a secured and non-volatile memory with no possibility of external read access.
Astrocast API
API authentication is performed with a random token. The API runs on an encrypted connection secured by SSL/TLS (HTTPS).
Customer's responsibilities
Asset
Payload sent to the Astronode S is immediately encrypted. However, care must be taken for securing data on the payload originator (e.g asset MCU) and travelling on the UART lines between the originator and the Astronode S.
Data management
The Astrocast API provides a secure way of retrieving your data from the Astrocast database. The data comes from our encrypted database and is sent over secured HTTPS. It is in the customer’s interest to securely store the retrieved data in its destination database and encrypt it if required.