OpenSAND implements different Modulation and Coding schemes, just like DVB-S2/RCS2, in order to adapt performances to different link conditions.
The type of MODCOD used in each frame has an impact in the amount of data transmitted, and in the minimum SNR needed for QEF decoding (refer to the Link Budget page for more information).
By default, OpenSAND implements the exact same MODCODs used by DVB-S2 and DVB-RCS2 (and DVB-RCS), but they can be configured by the user. Three schemes of MODCOD utilization on the forward link are available in OpenSAND:
On the return link, different MODCODs are available depending on the type of access used (DAMA, Slotted Aloha or SCPC).
In OpenSAND, each carrier can have a different MODCOD configuration. By default, each forward link carrier uses Adaptive Coding and Modulation (ACM), but it can be changed from the Carrier configuration window, by clicking the
Configure button. A window will pop-up, with three different choices of (
Access Type) for this carrier at the left:
Depending on the
Access Type chosen, you may choose only one, or many of the available MODCODs to be used in this carrier.
On the return link, the MODCODs used depend on the type of multiple access used (DAMA, Slotted Aloha or SCPC).
The list of available MODCODs for each standard (DVB-S2, DVB-RCS2, DVB-RCS), with their definition can be found in the
Advanced dialog, in the
Configuration tab. They are available in the
physical_layer section, under
Edit, the MODCOD definitions can be modified. Each line defines a new MODCOD, with the following values separated by spaces:
modcod_number: the MODCOD ID.
modulation: the modulation type (e.g. QPSK, 16APSK, etc.).
coding_rate: the coding rate of the MODCOD (e.g. 1/4, 3/4, etc.). This coding rate is the one used on the MODCOD name, and corresponds to the outer code. The real coding rate is smaller, since it considers also the inner code.
spectral_efficiency: the spectral efficiency.
required_Es/N0: the required Es/N0 (energy per symbol to noise power spectral density), in dB, to decode a packet using this MODCOD with QEF (probability of error < 10^-7)
burst_length(in symbols), since this standard defines multiple burst lengths. Even though any number can be specified, only 536 and 1616 burst lengths can be selected from the OpenSAND Manager.
There are several probes that allow to keep track of the evolution of the MODCODs used. These are available only for each terminal (ST), in the
Probes tab of the OpenSAND Manager. The probes are:
Up_Return_modcod→Sent_modcod: represents the MODCOD used for packets sent by the terminal (towards the satellite). While there is no packet being sent, 0 is displayed.
Down_Forward_modcod→Received_modcod: represents the MODCOD of a decoded packet received by the terminal (from the satellite). While there is no decoded packet received, 0 is displayed.
Down_Forward_modcod→Rejected_modcod: represents the MODCOD of a undecoded packet (because of insufficient SNR) received by the terminal (from the satellite). While there is no undecoded packet received, 0 is displayed.
Down_Forward_modcod→Required_modcod: represents maximum MODCOD the terminal is able to decode (available only when attenuation is not enabled).
MODCODs are used both in the Block Physical Layer and Block DVB. The MODCOD ID used to encode a packet (BBFrame and RCS Bursts) is carried in its header.
In the Block Physical Layer, the Es/N0 of arriving packets is compared against the Es/N0 needed for QEF decoding (which depends on the MODCOD, and is defined in the MODCOD definition file), only when attenuation is enabled (see Link Budget page).
In the Block DVB, the MODCOD to use for a packet is defined (depending on whether ACM, VCM or CCM is used) and its ID is stored in the header.