-
Notifications
You must be signed in to change notification settings - Fork 6
modulation and coding
Table of content
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:
- Constant Coding and Modulation (CCM): The MODCOD is constant during the simulation.
- Variable Coding and Modulation (VCM): More than one MODCOD is used during the simulation, depending on the QoS FIFO used.
- Adaptive Coding and Modulation (ACM): MODCOD is changed dynamically in order to minimize the packet losses.
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 (by default).
- Slotted Aloha.
- SCPC.
There are several probes that allow to keep track of the evolution of the MODCODs used. These are available for each terminal (ST) and gateway (GW), 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 the MODCOD required for next DVB bursts (only available for STs). Correspond to the value put in SAC.
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.