Efficient multicast of updates to satellite connected devices

Satellite connected devices will from time to time need software updates, updates to built-in maps, updated weather maps, updated ice maps, updates to AI-models for feature extraction, new videos and TV-shows for crew welfare programs etc. Updates, that are common to a population of devices or users.

Multicast or broadcast solves the capacity problem

Currently, terrestrial links (like cable, fiber, Wi-Fi, mobile) have a very high bandwidth and capacity, so updates are just sent directly to each device as needed. On satellite links however the available bandwidth is a scarce resource and will continue to be scare for years to come. Using broadcast or multicast for distributing the common update from the ground via the satellite(s) to all devices or users in need, can save a substantial load on the satellite links. In many cases the use of broadcasting or multicasting are the only viable solution to update the devices.

Complications from broadcasting or multicasting data on error prone and intermittent satellite links to hundreds or thousands of devices can easily result in each device missing some parts of the update. Each device will therefore need to request retransmissions of the missing parts to complete an update, the inefficiency of which further loads the system and may jeopardize the primary use of the system.

Efficient multicast using erasure coding

Steinwurf has developed a highly optimized coding algorithm where all data-packets received by the device are useful in completing the update. This makes sure the device will receive the full update without the need for requesting retransmissions. The coding also eliminates the need for routing and coordination of the broadcast data in a constellation of satellites because any data-packet received is useful irrespective of when and from where the data-packet is received. Each satellite uses its best effort to broadcast the update when having idle transmission time slots.

No retransmissions or return channel needed

The coding also eliminates the need for a return channel to acknowledge successful reception of data-packets. There is no need to acknowledge reception of each packet because a lost data-packet does not matter. The device just has to receive another data-packet.

When the device has received enough data-packets, it is able to finish the decoding of the packet and the update will be ready for use by the device.

Every packet helps

The coding converts the update to a set of linear equations. The equations are sent to the device and when the device has collected enough equations to solve the linear equation system then the decoding can finish such that the update is ready for use. It does not matter which equations are received. What matters is that enough equations have been received. This is the real advantage which eliminates the need for a return channel and the coordination of retransmissions simplifying broadcast or multicast of data to devices using the bare minimum of resources.

Performance

The coding is based on a highly optimized use of Random Linear Network Coding and is able to effectively code/decode big files (GB’s) for transmission using standard embedded ARM or x86 platforms. Typical encoding/decoding speeds can be seen in the table below.

Raspberry Pi 3 Model B+ (ARM) Dell Optiplex 9020 (x86) Dell Optiplex 9020 (x86)
Specification Cortex-A53, 64-bit SoC @ 1.4GHz, 1GB LPDDR2 SDRAM Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 16GB DDR3 RAM Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 16GB DDR3 RAM
Block size 250 MB 250 MB 1000 MB
Encode 37.9 Mbit/s 487.5 Mbit/s 538.2 Mbit/s
Decode 15.6 Mbit/s 297.6 Mbit/s 132.4 Mbit/s
Channel loss 1% 1% 30%
Overhead 0.066875% 0.065625% 0.981%

If you want to experiment with our solution for your use-case - or have a chat about how they could improve your users’ quality of experience please do get in touch at contact@steinwurf.com.

Previous
Previous

File delivery over multicast: UFTP vs. Filoop

Next
Next

Kodo Throughput Benchmarks Comparison (RaptorQ)