In order to study the impact of the beam-hopping implementation on a satellite communication, it will be necessary to set up the DamBOX on an OpenSAND platform previously deployed. The image below describes the architecture used.
DamBOX is deployed at the gateway.
Packets arriving from WS_GW and destined for WS_ST need to be filtered. The necessary following filtering rule needs to be applied on the GW:
iptables –I FORWARD –o opensand –j NFQUEUE
dambox binary needs to be run at the GW with the required parameters.
dambox -ds $ds -f $freq (--debug -d $duration)
More information on how to get and compile
dambox can be found in the Installation Manual.
More information on how to use and parameterize DamBOX can be found in the User Manual.
The purpose of this section is to see how the DamBOX changes the flow profile, latency and jitter on an OpenSAND platform.
In the case of non-beam-hopped communication (No DamBOX or DamBOX with timeline[1.1]), if a UDP flow at rate 22.5 Mbit/s is transmitted by iperf from WS-GW to WS-ST, the profile rate received by the end user is as follows:
Flow peaks are observed every 10ms. Indeed, OpenSAND buffers the packets arriving on the GW to retransmit them every 10ms (default value) to the terminal by adding the desired delay.
If DamBOX is set up on GW with parameters BHS=13 ms and freq=2 (timeline [1.0]), the output rate of the GW (GW opensand_tun interface) has the following profile:
This traffic will then pass through OpenSAND. The flow profile finally received by the ST and the WS-ST end user is as follows:
It could also be interesting to look how the implementation of DamBOX changes latency and jitter on satellite communication performed by OpenSAND. The OpenBACH jobs iperf, fping, owamp_client/owamp_server can be used to obtain these metrics in the 3 cases tested (without DamBOX, with DamBOX and timeline [1, 1] and finally with DamBOX and timeline [1 ,0]):
|Without DamBOX||With DamBOX timeline [1,1]||With DamBOX timeline [1,0]|
|Average jitter (ms)||0.753||0,758||0,770|
|Average latency (ms)||264.994||264.951||268.221|
The integration of DamBOX on OpenSand almost does not change the jitter on the communication. By comparing the latency values for the two cases without intermittency (without DamBOX and with DamBOX and timeline [1, 1]), we identify that the packet passage at the application level does not have a major influence on latency. With the execution of DamBOX with a timeline [1.0], we observe an increase in the average latency of 3.27 ms, which is very close to the theoretically expected value 3.25 ms. More information on the theoretically expected value can be found in the User Manual.