Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов Опции

[des00]

Добрый день!

Наконец то появилось время подтянуть себя в вопросах реализации кодов с вероятностным декодированием. Первая задача реализация DVB-RCS/WiMAX CTC кодера на ПЛИС, часть проекта будет выложен в опенсорс. Решил создать отдельную тему для обсуждения вопросов по реализации

После штудирования литературы и примеров сорцов в сети возникла часть вопросов, на которые не хватает ума/настойчивости найти ответы:
1. Для DVB-RCS оговорены выкалывания под скорости кодирования 1/3, 2/5, 1/2, 2/3, 3/4, 4/5, 6/7. Почему не определены скорости 5/6 (удивляет "дырка" между скоростями 4/5 и 6/7) и 7/8? При этому матрица выкалывания под эти скорости возможна.
2. Полиномы RCS для Wimax и DVB одинаковые, но перемежители разные. Это сделано по политическим причинам или это результат "улучшения" характеристик декодера в процессе разработки стандарта?
3. В сверточных бинарных кодах, свойство tail-bitting используется при декодировании: В одной доке нашел что дополняют принятую последовательность вначале и в конце, затем декодируют по витерби и выкусывают нужное. В примере матлаба вообще составляют два фрейма, декодируют один за другим, потом из двух декодированных собирают один результат. Никакого намека на похожие операции в доках на турбокоды не нашел. Почему в алгоритмах SOVA/MAP/... для турбокодов это не делается?
4. По tail-bitting нашел в доках только то, что особым образом инициализируются рекурсия прямой и обратной метрики на первой итерации, а на всех остальных значения между итерациями сохраняются. Но
в сорцах от CML цикл по итерациям выглядит так :

Код

for it = 1:max_iterations
    inx1 = X + inner_extr;
    [outx1, outz1]=DuobinaryCRSCDecode( inx1, inz1, poly, decoder_type);
    
    llrx1 = outx1 - inner_extr;
    inx2(1:3*N) = llrx1( code_interleaver_GF4);
    [outx2, outz2, out_info]=DuobinaryCRSCDecode( inx2, inz2, poly, decoder_type);
    detected_data(code_interleaver.info_intl) = (out_info>0)+0;
    errors(it)= sum( sum(abs(detected_data - data)));
    if (errors(it) == 0)
        break;
    else
        inner_extr(code_interleaver_GF4) = outx2 - inx2;
    end
end

Т.е. видно что последовательные вызовы функции DuobinaryCRSCDecode между собой не обмениваются этой информацией. А в самих функциях

Код

    // initialization  for CRSC code
    for (i =0; i< max_states; i++)
    {
        alpha[i][0] = 0;
        beta[i][len] = 0;
    }

Т.е. не используется даже свойство одинакового начального состояния. Более того, в алгоритмах с оконным расчетом обратной рекурсии тоже забивают на свойство tail-bitting. Так насколько это важно и почему во всех доках настойчиво пишут кодировать данные 2 раза для определения состояния инициализации?
5. В алгоритмах, наследованных от Log-MAP метрика ветки считается как сумма корреляций метрик приемных битов с выходными битами решетки : gamma(Sk-1, S) = Lapri + (ys0*xs0 + ys1*xs1 + yp0*xp0 + yp1*xp1). При этом предполагается что y - надежность принятого символа , x = -1/1 выходной(переданный) бит. В сорцах от CML это место выглядит так :

Код

    int m_input = 2;  // 2 input bits,
    int max_states = 8; // total state numbers
    int M_input = 1<<m_input;
    int i, j, max_trellis = M_input * max_states;
.......
        for (j = 0; j< max_trellis; j++)
        {
            temp_input = j%M_input;
            temp_output = trellis_out[j];
            gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ];   //llr for systematic symbol
            gamma[j] += ( temp_output ==0)? 0: inz[ (temp_output -1)+ i*llr_height ];  //llr for parity symbol
        }

Насколько я понимаю Си gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ] - берет надежности символов кроме нулевого. Диапазон изменения temp_input = 0..3 или в битах 00/01/10/11. Вот этот момент мне совсем не понятен.

Пока всё Прошу помощи тех кто в теме.

[des00]

Перевожу модель в фиксед поинт. Есть глупый вопрос: в документе ETSI TR 101 790 V1.4.1 указаны рекомендации

It has been found in one implementation, using Sub-MAP and at Packet Error Ratio (PER) in the region of 10е-5, that a 3-bit quantization entails a penalty of 0,2 dB compared to a 4-bit quantization. It can be further shown, by simulation, that increasing from 4 bits to 5 bits results in no more than 0,1 dB additional coding gain.

Насколько я понимаю речь идет о квантовании LLR метрик битов. Изучение других материалов показало, что 1 бит под дробную часть не эффективно, минимально рекомендуемое 2 бита. Делаю вывод, что в случае 4-х бит речь идет о формате представления чисел s2.2. Т.е. знаковое число, 2 бита под целую часть и 2 бита под дробную. В таком случае диапазон LLR метрик битов -4.00 ... +3.75 (вероятность нуля 0.98... вероятность единицы 0.97). Эти значения как раз совпадают со значением LLR битов нормированного QPSK созвездия -+1 -+1i, при попадании точно в точку. Тут все понятно. Нормируем созвездие на эквалайзере/ару, считаем евклидовы метрики, делаем ограничение на уровень -4...3.75.

Чуть ниже в этом же документе написано

Measurements, using samples from a real demodulator with Automatic Gain Control, have put into evidence that the position of the "sample clouds" within the quantizer range could be optimized for Turbo decoding. One implementation uses the following rule-of-thumb: "multiply the analogue samples of the demodulator by a constant so that after 4-bit quantization, the average of the unsigned values is equal to Rate × 8, Rate being the Turbo code rate (6/7, 4/5, 3/4, etc.)

И тут у меня взрывается мозг. Судя по доке, рекомендуемые уровни для кодирования [1/3 1/2 2/3 3/4 4/5 6/7] = [2.6 4.0 5.3 6.0 6.4 6.8]. Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом? Второй вопрос, судя по всему предполагается квантование сигнала в формате s3.0, но в таком случае диапазон чисел -8...+7, т.е. при кодировании 6/7, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ?

[andyp]

Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом?

Давай сначала - что такое канальные LLR (случай BPSK,AWGN)

LLR = log(p(x=1|r)/p(x = 0|r)) = log(exp(-(r-a)^2/sigma^2)/exp(-(r+a)^2/sigma^2)) =
=4*a/sigma^2*r;

r - сигнал на входе демаппера;
sigma^2 - дисперсия шума
a - точка, соответствующая чистому сигналу на входе приемника (фактически, это мат. ожидание абс. величины сигнала на выходе приемника).

АРУ на входе демаппера увеличит в К_agc раз sigma^2 и a, поэтому формула для LLR не изменится. Т.е. это математически это все равно - скалить сигнал на входе или созвездие в демаппере.

Второй вопрос, судя по всему предполагается квантование сигнала в формате s3.0, но в таком случае диапазон чисел -8...+7, т.е. при кодировании 6/7, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ?

На счет 3.0 vs 2.1 - если рассмотреть алгоритм MAXLOG-MAP, то он не чувствителен к постоянному множителю в канальных LLR, т.е. суть вопроса от меня ускользает - можно отскалить вход как это будет удобно. Именно поэтому при реализации смело плюют на a/sigma^2 в знаменателе канальных LLR, если диспресия шума постоянна на кодовом блоке.

Давай теперь перейдем к квантованию. Сначала проще ограничение на входе рассмотреть. Мой опыт говорит, что ограничение на входе декодера полезно даже без квантования. Фактически оно приводит к тому, что в декодер попадает меньше шума, экстремальные всплески которого просто срезаются ограничителем. Я обычно выбираю уровень ограничения, равный a+(1.5...2)*sigma. a/sigma - худший рабочий SNR декодера. Авторы рекомендаций используют мало уровней квантования, так что им нужно сбалансировать шум квантования и шум от ограничения динамического диапазона входа ограничителем. Для больших скоростей они посчитали, что дисперсия шума на входе будет меньше (рабочая точка декодера смещается вправо по шкале SNR) и потому решили сузить динамический диапазон относительно +/- a и уменьшить шум квантования малых LLR. Видимо, провели моделирование какое-то, чтобы подтвердить результаты.

[des00]

Т.е. это математически это все равно - скалить сигнал на входе или созвездие в демаппере.
...
суть вопроса от меня ускользает - можно отскалить вход как это будет удобно.

Согласен с вами во всем, похоже вопрос задал не совсем понятно. Задам с графическим материалом.
На рисунке qpsk - классический QPSK, с точками {4,4} и SNR 5дб, по стандарту так должно быть отмасштабировано созвездие для кодирования 1/2. На рисунке qpsk_sat тоже созведие, но после ограничения диапазона [-8,7]. Видно что такое ограничение не особо критично. На рисунке qpsk_6by7 созвездие перед ограничением отмасштабировано с коэффициентом (6/7)/(1/2). Видно что большая часть точек, ушла в зону ограничения. Это я и назвал термином "насыщение квантователя". Т.е. большую часть статистической информации тупо выкинули.

что ограничение на входе декодера полезно даже без квантования.

Да, вы про это уже писали. Возражений тут никаких, единственное что уровень ограничения в ПЛИС я делаю меньше, т.е. для QAM16 с уровнями 1 и 3, беру 2 бита запаса в сигнале в ару и перед декодированием ограничиваю по уровню 4, мне так проще в ПЛИС.

Видимо, провели моделирование какое-то, чтобы подтвердить результаты.

Похоже что вы правы, сам не додумался. ИМХО это сильно на шаманство похоже. Вырезать актуальную информацию из канала, вместо того что бы 1 бит в метрику накинуть или нелийнейное квантование сделать.

Эскизы прикрепленных изображений