• Welcome
  • News
  • Blog
  • Technology
  • Research
  • About

Efficient OTA update of ground devices on a LEO constellation

January 08, 2020 - Steinwurf ApS

The ability to update content (e.g. firmware) in IoT and other satellite connected ground devices is a necessity to keep offering competitive features to customers and for bug-fixing and improvements.

On satellite networks the update of ground devices is most efficiently done by broadcasting to all devices in parallel, minimizing the satellite transmission time. Certain content updates can be too large to complete during a single satellite pass. Such updates will take multiple satellite passes to receive the complete update leading to a complex situation where devices end up missing different parts of the update. At the final phase of the transmission most devices will be wasting time and power looking for the missing parts (a classic example of the Coupon Collectors Problem).

The solution

Steinwurf has solved this problem by coding the update so every data packet received by the device contributes to the completion of the transfer. In this way, the transfer of the update is complete when enough data packets have been received. I.e. each device just needs to receive a fixed number of packets and will never end in a situation where the device waits for a specific data packet, minimizing the time for and resources required to broadcast an update to all devices.

This is demonstrated in the below animation where an update is sent to a population of ground devices using two different approaches:

  1. Uncoded – where each device needs to receive each and every part of the update at least once, relying on chance to hope devices receive new parts of the update during each satellite pass, and
  2. Using the OTAcast algorithm – where each data packet received is useful.



Even with a small file (split into 100 packets) and a few ground devices (15) the simulation shows that all devices quickly receive the complete file using the OTAcast solution, whereas most devices waste time waiting for their missing parts, when packets are transmitted uncoded. The improvement will be even greater if the number of packets to be transmitted is increased or the population of ground devices is increased.

Use cases

In addition to e.g. firmware updates, the OTAcast solution is equally well suited to other broadcast applications, where data needs to be sent to a population of ground devices, e.g. map updates (weather, ice), broadcast of intelligence information, updates of media files in crew welfare solutions, updates to AI-coefficients in feature extractors etc.

If you want to experiment with our solution - or have a chat about how the solution can be licensed and integrated into your products, please do get in touch.

Share this blog:

Recent Blog Posts

  • 22 Jan 2021 | Hardware Acceleration

    Erasure correcting codes (ECC/FEC) provide elegant solutions to many networking problems. Whether you want to build reliable super low latency applications or efficiently send data to 1000s of devices simultaneously, ECC/FEC can provide compelling advantages. However, one common concern when integrating an ECC/FEC algorithm is often how big is the computational overhead?

  • 07 Jan 2021 | Multicast ECC/FEC

    A typical use-case for broadcast/multicast is when we need to transmit the same data (e.g. a file) to multiple receivers simultaneously. The use of multicast/broadcast means that multiple devices may benefit from a single transmission increasing the efficiency of the system. However, a challenge in such systems is how to efficiently deal with packet loss. In the following we will show how using an erasure correcting code/Forward Erasure correction (ECC/FEC) can lead to significant bandwidth savings over a traditional retransmission based system.

  • 30 Oct 2020 | Content-Aware ECC/FEC

    In some of our previous posts we have discussed some of the challenges when implementing a reliability scheme targeting low latency applications. For example in Coding for low latency (block codes) we discuss how large block codes such as RaptorQ or LDPC can be problematic in low latency communication. Similarly in In our post What about the latency, stupid we discuss the latency penalty of using a retransmission based reliability scheme. In this post we will consider what can happen when we want to protect the traffic coming from a latency sensitive application where the structure of the content is important.

  • Twitter
  • Facebook
  • Linkedin
  • Mail
  • Github
  • Youtube
Design: TEMPLATED