-
Notifications
You must be signed in to change notification settings - Fork 6
delay
Table of content
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 Satcom system overview.
Examples for Iridium and O3B
This wiki also provides examples here on how the orbital satellite delay options can be used for emulating O3B and Iridium constellations.
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 in the parameters.
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.
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).
| 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 |
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.
| 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 |
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.
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 signaling (MSG_TYPE_SOF) messages