Network bonding, especially of 5G and LEO, is increasingly being used to deliver broadcast signals. But there is a big difference between the way broadcast bonding solutions, e.g Zixi in our 5G Flyaway, work compared to general purpose IT solutions for web browsing e.g Peplink. While, IT solutions “might work”, only a broadcast specific solution can provide the guarantees and confidence as they are specifically designed for the use-case.
To summarise, network bonding solutions allow use of multiple network connections to both aggregate bandwidth as well as provide network resiliency.
| Broadcast Bonding (e.g Zixi) | IT Bonding (e.g Peplink) | |
| Load Share | ✅ | ✅ |
| Latency Aware | ✅ | ❌ |
| Retransmissions down all links | ✅ | ❌ |
| Null packet removal | ✅ | ❌ |
The overarching difference between a broadcast bonding solution compared to an IT bonding solution is that the design of a broadcast solution is based around *fixed latency*. This means that the bonding solution is configured to use a fixed latency and runs its bonding and error recovery with the fixed latency in mind.
General purpose IT solutions are essentially black boxes, designed for general web surfing. In particular IT bonding solutions are not aware of latency. When surfing the web it doesn’t matter if your web page is half a second late vs half a second of no video. There may be a protocol like SRT running transparently inside the IT bonding that is latency aware but it knows nothing about the fact there’s bonding going on.
The main implementation improvements between broadcast and IT bonding essentially follow from being fixed latency aware and aware the content is video:
Retransmissions down all links
One of the most important things in a latency limited environment is to recover lost packets within the latency window by retransmitting them. One of the major advantages of doing bonding and packet recovery with the same system is that packet recoveries can be sent down all links, maximising the chances of recovery. Zixi is capable of doing this, meaning a lower overall latency is possible.
On the other hand, an IT bonding protocol with SRT running transparently underneath has no idea what is an urgent packet recovery and just sends it on one link. This means a lower chance of recovery and a longer latency is needed overall to account for this. This is assumes the packets are even recoverable on a single link in the latency window.
Null packet deletion
We have written in previous blog posts about the need to maintain Constant Bitrate in order to be compliant with third party decoders. This is done by making sure null packets containing no data are present. But it is wasteful to transmit these packets if they contain no data. Bonding solutions like Zixi can strip null packets and reinsert them after debonding. Furthermore Zixi’s use of adaptive FEC means it can use this bandwidth to perform additional error recovery.
IT bonding solutions are not aware of the underlying content and so wastefully transmits the null packet data. This increases data bills, especially during content like colour bars, which compress heavily and thus have a lot of null packets.
There are some single vendor SRT solutions, which include our own, that can strip and replace null packets, but they don’t have the same level of sophistication as Zixi with regards to replacing Null packets with adaptive FEC. Such single vendor SRT could be used with IT bonding solution to gain some, but not all, of the benefits.
Content Aware
A transport protocol that is content aware can also prioritise content such as audio so that under heavy packet loss audio continues, or I-frames in video so that errors can be masked more easily by the decoder.
Conclusion
We’ve shown in this blog post how broadcast bonding systems are superior to general purpose IT systems. By using a broadcast aware solution such as Zixi in our 5G Flyaway, the highest reliability can be achieved without having to use a large latency.
