Do I need a BODi at only one end or at both ends?

1) When you have a BODi at only one end of a connection, you can do load sharing over multiple GSM connections. Let me explain this in more detail. For example, consider having two GSM connections, which in fact, could be different carriers. You start a video session and it will be transported over the first GSM connection for the entire session, until it is finished. If you start a second video session while the first continues, it will go to the second GSM connection for transport. Therefore the load is shared over the two GSM links, but each session is one, and only one, GSM link.

2) On the other hand, Bonding requires a BODi at each end. (In fact, true bonding of multiple streams needs to have some type of device at each end, such as in MLPPP.) In the bonding scenario with a single video session, the packets (or frames) are distributed in round-robin fashion to the multiple bonded GSM links. In other words for an example with three GSM links, packet #1 goes to GSM link #1, packet #2 goes to GSM link #2, packet #3 goes to GSM link #3, and then it repeats by sending packet #4 to GSM link #1, etc.
In this scenario, the single video session would use all the GSM links (that make up one bonded point-to-point connection) to carry the video traffic.

1 + 1 = 1?

Another question that often comes up when evaluating BODi rS bonding performance is that

I have 15Mbps on one 4G LTE. How come when I bond two 4G LTE, the bonded bandwidth is still 15Mbps?

There is something behind the scene.

Fixed Bandwidth Pool

First thing first. It is important to make sure that we are measuring BODi rS bandwidth properly. Here are steps for evaluating Patton BODi rS.

Here the problem is likely to do with

4G LTE mobile carriers have a fixed pool of bandwidth at the backhaul and they share this fixed pool between their SIM cards.

This way regardless of how many 4G LTE connections we use on the Patton routers, the total bonded BODi rS bandwidth will be limited by this 15Mbps fixed bandwidth pool at the carrier backend.

And it is rather easy to verify.

Speed Test. In Parallel.

If the problem is with bandwidth sharing at the 4G LTE carrier backhaul, we should be able to reproduce it without using Patton BODi rS at all.

To isolate this problem, we will go back to an old friend – speedtest.net.

Speedtest.net measures how much bandwidth each of the two 4G LTE connections has to the nearest speedtest.net server.

If we do two speed tests at the same time on the two 4G LTE connections, we will be able to see how much bandwidth the 4G LTE mobile carriers can provide to each of the two 4G LTE, when they are used concurrently.

This is our setup.

Setup #1 on the left is connected to one BODi with one 4G LTE SIM card from VZW, a 4G LTE carrier in the US.

Setup #2 on the right is connected to another BODi with also one 4G LTE from VZW.

The two setups are completely separate. Simply two laptops each with one 4G LTE connection via a BODi. There is no Patton BODi rS bandwidth bonding.

If you do not have a BODi, you can insert the 4G LTE SIM cards in two different smartphones or two 4G routers of any kind and do the same test.

Now we do speed tests.   

First, we do a speed test on the setup #1.

14Mbps of download bandwidth and 13.4 upload bandwidth to the speedtest.net server.  Decent.

And then we do a speed test on setup #2.

10.4Mbps of download bandwidth and 15.2 upload bandwidth to the speedtest.net server. Not so much different than the other setup.

Now it gets interesting. We do the speed tests at the same time.

Imagine.

In a world where there is no bandwidth limitation and bandwidth sharing at the 4G LTE carrier backhaul, if we do the two speed tests concurrently we should expect roughly the same results on each of the 4G LTE as when we do the two speed tests separately.

The world never fails to amaze us.

Bandwidth Ceiling

These are the speed test results when the tests are done concurrently.

When speed tests are done concurrently, download and upload bandwidth of each of the 4G LTE drop to roughly half of what we had before.

This points to a fixed bandwidth pool of around 15Mbps download and upload at the 4G LTE carrier backhaul – shared between the two 4G LTE connections.

If we do BODi rS bandwidth bonding on these two 4G LTE SIM cards, with each of the 4G LTE giving roughly half of 15Mbps, BODi rS will bond them to a throughput of 15Mbps.

This 15Mbps bonded throughput will mislead the users to believe that BODi rS is not bonding the two 4G LTE connections.

In fact, if we take into account the fact that the two 4G LTE are constantly nudging each other for more bandwidth in a fixed bandwidth pool, and we take away the 10-20% bandwidth cost from packet encapsulation, user may see bonding two 4G LTE gives less bandwidth than using only one 4G LTE i.e. 1 + 1 = 0.9.

Is there a way around this?

Bonding 4G LTE

From our experience,

This bandwidth sharing problem is quite common for 4G LTE from the same mobile carriers. And sometimes we do also see this problem for 4G LTE from different mobile carriers, especially when they are sharing the backhaul infrastructure.

Be sure to do the parallel speed test above if you suspect that you have fallen a victim of this bandwidth sharing problem.

A number of 4G LTE mobile carriers also have 4G LTE connection offerings with dedicated or guaranteed bandwidth. These will be ideal for bandwidth bonding.

And keep in mind that there is a world of connectivity options other than 4G LTE that BODi rS can use to boost bandwidth and increase resiliency.