Jump to content

    
des00

Вопросы по итеративному декодированию

Recommended Posts

2 часа назад, des00 сказал:

Как правильно сравнивать вот такие коды? Можно конечно просто уйди в домен SNR

Интересный вопрос. Если смотреть на таблицы в стандарте, касающиеся минимальной требуемой энергетики для различных MCS, то там будет SNR.

Надо подумать)

Share this post


Link to post
Share on other sites

des00

Про 5G ничего не знаю, не понял в чём вопрос.

вычисляем полную энергию на всю посылку

Ну вот N бит передаются символом(не важно как там что кодируется и отбрасывается), вычисляем энергию символа, делим на количество бит N, находим Eb, хотим посчитать BER при EbNo = 5дб, вычисляем No, прибавляем к сигналу шум с No, считаем BER.

Share this post


Link to post
Share on other sites
19 minutes ago, petrov said:

Про 5G ничего не знаю, не понял в чём вопрос.

Попробую расписать вот на таком примере. Положим у нас есть код 1/2 и 100 бит систематических данных, модуляция BPSK.

1. Обычная система связи.

100 бит -> кодер -> 200 бит -> 200 символов -> AWGN -> 200 метрик -> декодер -> 100 бит

2. 5G

100 бит -> кодер -> 200 бит -> выкалыватель 20% систематических данных -> 180 символов -> AWGN -> 180 метрик -> декодер -> 100 бит.

Т.е. в обычной системе, в кодере и в канале скорость кодирования 1/2 и для передачи информации о 100 битах использовалось 100 символов данных + 100 проверочных символов.

А в 5G, в кодере 1/2, в канале 0,44 (80/180) и для передачи информации о 100 символах использовалось 80 символов данных + 100 проверочных символов. Но количество переданной информации(100 бит), в обоих системах одинаковое.

возникает вопрос, эти 20% как должны учитываються в энергии бита? Если в лоб, как в моем вопросе и как вы пишете, то при одинаковых EbNo, SNR на выколотом 5G коде будет хуже. Т.е. код мы сами "ухудшили" (выкололи), еще и гоняем тесты с большей дисперсией). Вот моя логика здравого смысла говорит что, что-то, тут не так)

Share this post


Link to post
Share on other sites

des00

Вот моя логика здравого смысла говорит что, что-то, тут не так)

Возможно кодирование для ещё каких-то целей используется. Для подсчёта BER не важно как там код устроен, вот отображаются 100 бит в символ с какой-то энергией, этого достаточно.

Share this post


Link to post
Share on other sites
On 2/3/2020 at 8:36 PM, petrov said:

 

Возможно кодирование для ещё каких-то целей используется. Для подсчёта BER не важно как там код устроен, вот отображаются 100 бит в символ с какой-то энергией, этого достаточно.

Не, там все четко. Те кто разрабатывал стандарт учли многое, в том числе постановку задачи: зачем делать высокие скорости кодирования (которые на QC-LDPC приводят к большой длине проверочных матриц по горизонтали), если можно просто выколоть систематические биты, на матрице нормальной длины. Ну а дальше там все решает rate matching на циклическом буфере. Где можно дослать выколотых бит) Ну и 5G решает вопрос взять побольше (высокие скорости), плюнуть на 5-10км. Хотя сами матрицы, в самом стандарте описаны как noise floor absence.

Ну и вопрос не как мерить BER, а как сравнивать кривые кодирования. В целом, результаты моих прогонов кодека в матлабе, показывают что надо идти по классическому варианту. А именно, считать что выкалываются проверочные биты(а не систематические), считать "скорость кодирования" ну и при заданном EbNo определять требуемую дисперсию генератора. 

ЗЫ. А сам LDPC в стандарте ИМХО хорош для применения, Жаль только что сделали "кривые" размеры базовых подматриц 3х3, 5х5, 7х7, 9х9, 11х11, 15х15, не кратные 2^N, со списком проверочных матриц и модульными операциями приведения базовых матриц к рабочим. Вот их обрабатывать довольно сложно, на универсальном ПЛИС движке(

Share this post


Link to post
Share on other sites
40 minutes ago, des00 said:

если можно просто выколоть систематические биты, на матрице нормальной длинны

А зачем выкалывать систематическую часть, ведь "классический" вариант - это выкалывать проверку?

Ведь весь смысл систематического кодирования теряется.

 

По поводу интерпритации.

А если бы выкалывались проверочные биты, то как бы вы тогда канальную скорость искали?

Ведь на приемники из этого блока будет извлечены те же самые 100 бит информации.

 Я бы скорость определил как K/N.

Где K - число информационных бит до кодирования, N - число бит в канале.

Share this post


Link to post
Share on other sites
23 минуты назад, Tpeck сказал:

А зачем выкалывать систематическую часть, ведь "классический" вариант - это выкалывать проверку?

Для удобства реализации циклического буфера и схем ретрансмитов, при этом работая с различными скоростями кода, даже очень высокими. А в "старом" стандарте, который 4G, еще и уменьшить деградацию турбокода. Я приводил выше ссылки, где сказано, что в случае турбокода выкалывание большого числа проверочных битов сильнее ухадшает его свойство, чем выкалывание информационных.

Share this post


Link to post
Share on other sites
11 minutes ago, Grizzly said:

Я приводил выше ссылки, где сказано, что в случае турбокода выкалывание большого числа проверочных битов сильнее ухадшает его свойство, чем выкалывание информационных.

Да, специально сделал сравнение 5G "одинаковых" кодов, например 22/26 классический и 22/28 выколотый по систематическим битам до 22/26, так вот, второй обходит первый, по моей базовой модели с неквантованной метрикой на ~0.3-0.5 дб.   

PS. Как будет время, турбокоды из 13ой рекомендации тоже добью и проверю этот эффект, уж больно там перемежитель хороший, всегда хотел сделать турбокодек на 200 мегабит) 

Share this post


Link to post
Share on other sites
24 минуты назад, des00 сказал:

Да, специально сделал сравнение 5G "одинаковых"

Значит, и для LDPC тоже. Не видел нигде явного упоминание про них. Запишем :mail1:

Share this post


Link to post
Share on other sites

Немного интересных результатов. Кривые сняты по 1е8, граф 1, без выкалывания, метрика 4 бита, 2D normalized min-sum, QPSK, AWGN на основе алгоритма Box-Muller.

Кривые ведут себя отлично от других LDPC декодеров, с уменьшением скорости кодирования, особенно на малых длинах, noise-floor заметен не вооруженным глазом. Полагаю что сказывается матрица четности. Жаль что нет вертикальных связей для этих бит и неудачная/нулевая метрика, по сути вычеркивает строку матрицы из декодирования. Зато очень простой декодер) 

Про выкалывание я писал раньше про дельту в 0.5дб, по факту в среднем она 0.25-0.3) но можно подобрать пару точек где она 0.5, на больших длинах. 

И вот тут хотел задать вопрос гуру, о трактовании результатов. Например, возьмем размер 44 бита и коды 22/26 и 22/40. Кривые практически идентичны, но, при одинаковом BER и EbN0, первый будет работать при SNR на ~1,5 дб выше. Может быть еще этот эффект закладывался в стандарте? Ведь там сначала передается часть с выколотыми битами, потом хвост, потом хвост + выколотые. Так последовательно и набирается необходимая помехоустойчивость. Или я ошибаюсь в своих предпосылках?

ldpc_44.png

ldpc_88.png

ldpc_176.png

ldpc_5632.png

Share this post


Link to post
Share on other sites

des00

Два кода, просто некодированная QPSK R=1, и QPSK с повторением каждого символа R=1/2, кривая BER(Eb/N0) у них абсолютно одинаковая. Очевидно для кода R=1/2 нужна вдвое меньшая мощность при тех же N0 и вероятности ошибки. Или я не понял вопроса?

Share this post


Link to post
Share on other sites
46 minutes ago, petrov said:

 

Два кода, просто некодированная QPSK R=1, и QPSK с повторением каждого символа R=1/2, кривая BER(Eb/N0) у них абсолютно одинаковая. Очевидно для кода R=1/2 нужна вдвое меньшая мощность при тех же N0 и вероятности ошибки. Или я не понял вопроса?

Написал не ясно, попробую раскрыть вопрос. Он распадается на 2 части:

1. Это старый спор о том, в чем же сравнивать коды/системы в EbN0 или в SNR. Получается что коды, с разной степенью кодирования, но с одинаковыми кривыми EbN0 (хотя обычно код с более низкой степенью кодирования имеет выигрыш, при прочих равных), все равно отличаются по энергетическим характеристиками системы на разницу 10*log10(coderate). И более мощный код выигрывает, несмотря на то, что по кривой EbN0 они одинаковы. Правильно же я рассуждаю?

2. Как я понял стандарт, код всегда кодируется с минимальной скоростью кодирования, но передается часть данных, соответствующая максимальной скорости. В случае недостаточности декодирования, идет перезапрос на дополнительную часть кода, читаемую из циклического буфера. Таким образом получается, что несмотря на noise floor в кодах с низкой скоростью, по SNR все равно будет выигрыш и вероятность передать битые данные уменьшается.  Верны ли мои предположения о том, для чего rate matching с циклическим буфером, описанный в TS 38.212, реализован именно так?

Share this post


Link to post
Share on other sites

des00

И более мощный код выигрывает, несмотря на то, что по кривой EbN0 они одинаковы. Правильно же я рассуждаю?

Некорректно говорить выигрывает, нет сравнения при прочих равных, в скорости передачи данных проигрывает, так у вас просто низкоскоростная передача без кодирования выигрывать будет. В примитивном примере выше помехоустойчивость одинаковая, просто мы можем разменять скорость передачи на уменьшение требования к мощности сигнала.

Про 5G ничего не знаю.

Share this post


Link to post
Share on other sites
1 час назад, des00 сказал:

Таким образом получается, что несмотря на noise floor в кодах с низкой скоростью, по SNR все равно будет выигрыш и вероятность передать битые данные уменьшается.

Здесь получается всё еще сложнее и запутаннее в плане расчетов. При перезапросе вы проиграете в спектральной эффективности системы, то есть фактическая скорость передачи информациооных битов уменьшится. Кроме того, при ретрансмитах отправляется не только кусочек, чтобы добрать нужную часть битов, а весь кодовый блок такого же размера, как исходный. В таком случае часть битов будет повторена.

Насколько я понимаю, при моделировании подобных систем как раз для этого строят кривые спектральной эффективности от ОСШ, в которых учитываются повторно отправленные кодовые блоки. И обычно всё-таки для SNR, а не EbN0.

Share this post


Link to post
Share on other sites
On 5/15/2020 at 9:41 PM, petrov said:

 

Некорректно говорить выигрывает, нет сравнения при прочих равных, в скорости передачи данных проигрывает, так у вас просто низкоскоростная передача без кодирования выигрывать будет. В примитивном примере выше помехоустойчивость одинаковая, просто мы можем разменять скорость передачи на уменьшение требования к мощности сигнала.

 

Понял, как то этот параметр я выпустил из рассмотрения. спасибо)

On 5/15/2020 at 10:40 PM, Grizzly said:

Здесь получается всё еще сложнее и запутаннее в плане расчетов. При перезапросе вы проиграете в спектральной эффективности системы, то есть фактическая скорость передачи информациооных битов уменьшится. Кроме того, при ретрансмитах отправляется не только кусочек, чтобы добрать нужную часть битов, а весь кодовый блок такого же размера, как исходный. В таком случае часть битов будет повторена.

Насколько я понимаю, при моделировании подобных систем как раз для этого строят кривые спектральной эффективности от ОСШ, в которых учитываются повторно отправленные кодовые блоки. И обычно всё-таки для SNR, а не EbN0.

Да вот кручу характеристики, со всех сторон и мне как раз и не понятно, зачем в стандарт ввели короткие LDPC блоки. Они по сути не работают, особенно на малом графе.

Биты четности, без вертикальных связей не итерируются, если его выбивает(малая или неправильная метрика), то по сути весь ряд матрицы выбрасывается, даже если в ряду все другие метрики сильные. Как бы сама идея такого наращивания скорости кода она интересная, но вот его влияение, на малых размерах блока, при классическом 2D min-sum озадачивает вопросом, о целесообразности такого режима.

Либо нужен другой алгоритм декодирования.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.