User Tools

Site Tools



Satellite delay

In OpenSAND, propagation delay is emulated on STs and GWs: packets arriving (upward) or departing (downward) from a ST or GW are forced to wait a certain amount of time before continuing. Each waiting time is equal to the equivalent propagation delay between the component (ST or GW) and the satellite. Thus, a data packet going from a ST to a GW will wait before exiting the ST (delay ST-SAT), and upon arrival to the GW (delay SAT-GW). By default, OpenSAND uses a constant satellite delay, emulating the propagation delay of a GEO satellite link. However, the delay can be modified, and even, a variable delay model can be used.

For more information about the delay on Satcom systems, please refer to the knowledge base.

Examples for Iridium and O3B

This wiki also provides here examples on how the orbital satellite delay options can be used for emulating O3B and Iridium constellations.

OpenSAND exploitation

The delay can be configured in from the Advanced configuration window in OpenSAND.

By default, an identical, constant delay is used for all GWs and STs, equal to 125 ms, which translates into a 250 ms single trip time, and a 500 ms round trip time. This delay can be configured through the global.common.delay parameter.

By unmarking the option global.common.global_constant_delay, the delay can be configured individually (Apply must be clicked to apply the changes before continuing) through the delay section that will appear for each component.

The individual delay is implemented using plugins, which can be configured on the lower part of the Advanced dialog. Available delay plugins are: Constant Delay and File Delay.


Constant Delay

The Constant Delay model applies the same delay to every packet coming in or out of the ST or GW. This is the plugin used by default, with a value of 125ms (delay corresponding to a GEO satellite - i.e. 250ms one-way delay).

The parameters are configured in the plugin configuration file constant_delay.conf.

Parameter name Description Value type Range of values Default value
delay Constant value of the delay between this terminal and the satellite, expressed in ms int 0-2000 125

File Delay

The File Delay model is based on values read in a file containing the satellite delay values according to time. The file format is described below. The parameter refresh_period mentioned can be found in the delay section of each terminal.

# Format
# time (expressed in multiples of the value specified by refresh_period) delay (ms)
0 125
10 120
24 110
38 120

Between two values of time, the delay value is obtained with linear interpolation if the channel is refreshed more than once (depending on the granularity).

For example, between times 10 and 24 s (if refresh period is 1000ms = 1s) with a granularity of 1000 ms, we have a constant slope from 120 to 110 ms.

The parameters are configured in the plugin configuration file file_delay.conf.

Parameter name Description Value type Range of values Default value
path The path of the satellite delay file string - /etc/opensand/plugins/satdelay.csv
loop_mode Whether we restart from the beginning of the file once it is completely read boolean true, false true
When changing the satellite delay of each terminal, keep in mind that the value max_satdelay in the Slotted Aloha section has to be updated (this value specifies the maximum delay between any two terminals, on a one-way trip). Slotted Aloha uses timeouts proportional to the satellite delay to function properly. Should the delay be too big, the error “Slotted Aloha timeout too low” may appear. In this case, the timeout parameter in the Slotted Aloha section of each ST should be incremented.


The probes available for each ST and GW are the following:

  • Delay: it displays the current delay between the host (ST or GW) and the satellite.


To verify that the correct delay is emulated, the round trip time can be measured by pinging a GW from a ST (or vice-versa).

The RTT should be equal to two times the sum of the delay of said GW and said ST.

OpenSAND Software Design

Satellite delay is implemented on the Physical Layer block on satellite terminals (STs) and gateways (GWs). Delay is implemented using FIFO queues, that pop the arriving packets after the specified delay has elapsed. On the Upward channel, the delay FIFO queue is placed right after the interface with the SatCarrier Block (upon reception of packets from the lower block); and on the Downward channel, the FIFO queue is placed before the interface with the SatCarrier Block (before sending the packets to the lower block).

The class that implements the FIFO queue is called DelayFifo, which implements the basic methods of a FIFO queue that contains DelayFifoElement elements. Each element contains a packet, as well as the date it is supposed to be dequeued. This date is specified the moment of queueing a packet.

The delay FIFO queue also implements a method that returns the dequeue date of the first packet. If this date has already passed, then the packet is dequeued. The periodicity at which the queue is inspected is defined by the global.advanced.delay_timer parameter. It should be noted that when queueing a new packet, it is always pushed to the back of the queue; if the delay is variable, then the packet with the shortest delay will not necessary be dequeued first.

OpenSAND does not apply delay to Start of Frame (MSG_TYPE_SOF) messages
opensand/emulated_satcom_features/physical/delay/index.txt · Last modified: 2019/12/18 13:39 by kuhnn