GR-CCSDS has LDPC encoding and decoding capability, a necessity when supporting the different CCSDS coding schemes.
Concerning LDPC coding, the relevant CCSDS recommendations are :
***131.0-B-3** : blue book named "CCSDS recommended standard for TM synchronization and channel coding"
***231.0-B-3** : blue book named "Recommended standard for TC synchronization and channel coding"
***130.1-G-2** : green book named "TM synchronization and channel coding - Summary of concept and rationale"
***230.1-G-2** : green book named "TC synchronization and channel coding - Summary of concept and rationale"
## Supported LDPC codes
Currently, GR-CCSDS is capable of decoding all 10 LDPC codes defined in the Telemetry recommendation of the CCSDS protocol family (131.0-B-3). One is the (8176, 7156) code, and the 9 other codes are referred as *AR4JA* codes with code rates 1/2, 2/3, 4/5 and information block length k=1024, 4096 or 16384.
The LDPC codes defined in the Telecommand recommendation (231.0-B-3) remain to be implemented. Implementation of the remaining codes doesn't require any change in the LDPC decode algorithm : only the computation of the corresponding parity check matrices and the generator matrices need to be implemented.
## Construction of LDPC code matrices
The parity check matrices and generator matrices are required respectively for decoding and encoding frames. These matrices could be precomputed and stored in files within the GR-CCSDS module. This solution has not been chosen as the biggest matrices can take up to around 80 MB when compressed. Instead, the corresponding matrices are computed at runtime during instantiation of an encoder or decoder for a specific code.
The parity check matrix for the (8176, 7156) code is constructed according to the structure presented in *section 7.3.2.2* and the specification of Circulants presented in *table 7.1* of 131.0-B-3. The systematic Circulant generator matrix is constructed according to *figure 7-2* and its Circulants presented in *table c-1 of annex C* of 131.0-B-3.
The parity check matrices for the 9 *AR4JA* codes are constructed according to the equations presented in *sections 7.4.2.2 and 7.4.2.3* and constants in *table 7-2, 7-3 and 7-4* of 131.0-B-3. The generator matrices are constructed according to *sections 7.4.3.3, 7.4.3.4 and 7.4.3.5*.
## LDPC encoder and decoder design considerations
The LDPC decoder uses belief-propagation to iteratively update the input LLRs in order to make them converge to a suboptimal solution. There are multiple ways to implement belief propagation.
The decoder implementation is based on the *horizontally-layered message passing schedule*. This means that variable nodes are updated directly after the computation of new messages coming from a common check node. This yields faster convergence to a suboptimal solution compared to the *flooded message passing schedule*.
On check nodes, the update function used is *Min-Sum*. It involves fixed-point arithmetic, minimum, addition, absolute and sign calculations on integers. Compared to *Sum-Product* that involves transcendental functions, *Min-Sum* has lower decode performance with the same iteration count. However, *Min-Sum*, is much faster to execute and therefore its decode performance can be compensated with a higher iteration count.
## Decoder performance
To evaluate the performance of the decoder, the simulated performance shown in section 8.6 of the CCSDS 130.1-G-2 document (TM synchronization and channel coding - Summary of concept and rationale) is taken as a reference. The following plot is the reference :
And the following plots are the simulated performance in terms of Bit-Error-Rate (BER) of the GR-CCSDS LDPC decoder for each supported information block length :
TODO : add plots for codes with k=16384 whenever the performance issue on the GM constructor is solved
TODO : add plot for (8176, 7156) code performance simulation with 200 iterations.
Note that these simulations were executed with an iteration count of 200 and BPSK modulation, the same parameters as the reference simulation in the 130.1-G-2 document.
## Known limitations
Construction of the generator matrices needed for LDPC encoding involve matrix inversions and matrix product. On codes with information block length k=16384, matrix inversions and matrix products take a lot of time (10s of minutes) due to the large size of the matrices involved. This remains to be optimized.
At the same iteration count, the LDPC decoder's performance is lower compared to the reference simulation. While the green book isn't clear about the implementation details of the decoder used for the reference simulation, a few hypotheses on the source of the lower performance are advanced :
* Our implementation uses Min-Sum variant of Belief-Propagation while the reference decoder uses Sum-Product. If the latter is true, then the Sum-Product variant should have the advantage over the Min-Sum variant with the same iteration count.
* Some constants used for the construction of the parity check and generator matrices may be erroneous in the implementation. If this is the case, encoding and decoding might be still possible but with a lower decode performance.
* An implementation error in the decode algorithm might be present. If this is the case, it may be possible that the decoder can still decode but with lower performance than expected.
