[Grizzly 0]

12 часов назад, des00 сказал:

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

В LTE существует 4 различных варианта ретрансмитов. Обычно при первой отправке данных выкалывают только проверочные биты (но если нужная высокая скорость, то приходится выкалывать и информационные (систематические)). На приемной стороне эти позиции заполнятся нулями. Если декодировали, то всё OK. Если CRC не сошлась, то приемник делает перезапрос. В результате будет отправлен новый блок (либо такой же, либо прочитанный, начиная с другой позиции кругового буфера). А дальше уже в зависимости от того, как был осуществлен ретрансмит, на приемной стороне происходит комбинирование битов (ну или сложение "мягких" решений). Таких ретрансмитов может быть несколько. Вроде бы 8-ю обычно ограничивают, но это не точно :)

Вот тут про турбокоды хорошо описано в части II A. Systematic Bit Puncturing, почему лучше выкалывать систематические, а не только проверочные:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.667.268&rep=rep1&type=pdf

P.S. Про LDPC в 15-м релизе я пока не прочитал :)

UPD. Вот здесь есть некое описание от 3GPP: https://list.etsi.org/scripts/wa.exe?A3=ind1701C&L=3GPP_TSG_RAN_WG1_NR&E=base64&P=67179646&B=--%3D_mixed+006452C7882580AD_%3D&T=application%2Fzip; name="R1-1701473.zip"&N=R1-1701473.zip&attachment=q&XSS=3

Не факт, что это именно принятый вариант, но что-то похоже. Нужно еще почитать и подумать. С LTE я работал, а в схемы кодирования для 5G глубоко не вдавался.

[Grizzly 0]

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

ЗЫ. А вы не разбирались, почему первые 2Z битов данных на входе кодера отбрасываются и не передаются?

Здесь довольно хорошо описано про схемы согласования, но про 2Z нет подробностей: https://ieeexplore.ieee.org/abstract/document/8417496

Посмотрел более подробно zip от 3GPP. Насколько я понимаю, 2Z битов не передаются в случае RV0. Для других схем повторной передачи, например, RV2, они могут быть переданы. Видимо, это сделано для удобства реализации кругового буфера и получения различных вариантов передачи систематических/проверочных битов.

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

[des00 25]

11 hours ago, Grizzly said:

Посмотрел более подробно zip от 3GPP. Насколько я понимаю, 2Z битов не передаются в случае RV0. Для других схем повторной передачи, например, RV2, они могут быть переданы. Видимо, это сделано для удобства реализации кругового буфера и получения различных вариантов передачи систематических/проверочных битов.

Спасибо за разъяснение и ссылки. Пошел изучать.

А про 2Z битов не увидел что написан выбор схем. Момент, про который я написал вопрос, вот тут: псевдокод 5.3.2   Low density parity check coding.

Берутся исходные биты для кодирования "The bit sequence input for a given code block to channel coding is denoted by c0, c1...cK-1, where  is the number of bits to encode as defined in Subclause 5.2.2" и в шаге 2 кодирование начинается с 2)   for k = 2Zc  to K-1.

Хотя в разделе 5.2.2      Low density parity check coding, в псевдокоде информационные биты кладутся в том числе в c0, c1 и т.д.

Возможно конечно что там какая то служебка, но граница плавающая, Zc же изменяется.

[Grizzly 0]

9 минут назад, des00 сказал:

"The bit sequence input for a given code block to channel coding is denoted by c0, c1...cK-1, where  is the number of bits to encode as defined in Subclause 5.2.2" и в шаге 2 кодирование начинается с 2)   for k = 2Zc  to K-1.

А с этим мне тоже непонятно...

[des00 25]

1 hour ago, Grizzly said:

А с этим мне тоже непонятно...

из материалов по вашим ссылкам

Quote

The LDPC codes for NR, support flexible information block-size (maximum of 8448 bits), coarse shift sizes (Z) for expansion ( 384 max = Z ), and filler bits (or zero-padding). In order to improve performance, built-in puncturing of the first 2ˑZ systematic bits is also adopted. 

т.е. это для всех режимов так), похоже система всегда работает с ошибкой. А что, так можно было (с)

[Grizzly 0]

5 минут назад, des00 сказал:

performance

Интересно, что они подразумевают под этим? Удобство получения разных скоростей, простота кругового буфера для разных ретрансмитов RV0...RV3, что-то еще?

[des00 25]

1 hour ago, Grizzly said:

Интересно, что они подразумевают под этим? Удобство получения разных скоростей, простота кругового буфера для разных ретрансмитов RV0...RV3, что-то еще?

По первому впечатлению, после прочтения документов, во главу поставлена скорость передачи данных. В случае чего, могут переспросить  и получить полный набор данных на низкой скорости))

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

Вообще хочу реализовать гибкий LDPC кодек, на скорости от 1/2 до 9/10, с переменным размером блока, с перестройкой на лету) Уже вплотную подошел к насчитыванию матриц QC-LDPC кода, но тут решил посмотреть как в LTE это реализовано. А тут.....кругом обман) 

[Grizzly 0]

@des00 Что-то все равно обман где-то кроется) Если 2Zc бит не передавать на вход декодера, то будет совершенно иное кодовое слово на выходе. В этом случае мы не сможем безошибочно декодировать исходный полный информационный блок. За latency тоже идёт борьба, поэтому в повторных передачах никто не заинтересован. В RV2, получается, не эти ли 2Z битов передаются?

 

[des00 25]

7 minutes ago, Grizzly said:

@des00 Что-то все равно обман где-то кроется) Если 2Zc бит не передавать на вход декодера, то будет совершенно иное кодовое слово на выходе. В этом случае мы не сможем безошибочно декодировать исходный полный информационный блок. За latency тоже идёт борьба, поэтому в повторных передачах никто не заинтересован. В RV2, получается, не эти ли 2Z битов передаются?

 

почему? нулевые метрики туда подать и все. Будет как в статье про турбокоды, 6% систематических бит для RV0 просто выбрасываются) а ведь именно RV0 идет первым, значит ему не нужно для декодирования эта часть бит)

[Grizzly 0]

30 минут назад, des00 сказал:

нулевые метрики туда подать и все

В декодере да. Так и делается. Согласен.

Мне показалось из описания процедуры кодирования, что кодер не принимает первые 2Z информационных бит. Этому сильно удивился. В таком случае происходит отображение в совершенно другое кодовое слово, а исходное невозможно восстановить. Видимо, не так понял. Кодировать надо все информационные биты, а уж что выкалывать, дело вкуса :)

[des00 25]

2 minutes ago, Grizzly said:

В декодере да. Так и делается. Согласен.

Мне показалось из описания процедуры кодирования, что кодер не принимает первые 2Z информационных бит. Этому сильно удивился. В таком случае происходит отображение в совершенно другое кодовое слово, а исходное невозможно восстановить. Видимо, не так понял. Кодировать надо все информационные биты, а уж что выкалывать, дело вкуса :)

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

[Grizzly 0]

24 минуты назад, des00 сказал:

да, там процедура кодирования систематических бит описана как присвоение выходных битов кодера входным систематическим битам, с тем самым смещением. А вычисление проверочных бит, идет по всем битам)

Спасибо! Сильно невнимательно про это прочитал. Теперь всё встало на свои места.

[Grizzly 0]

@des00 недавно обновилась версия статьи по полярным кодам в 5G: https://arxiv.org/abs/1804.04389

В ней рассматривается согласование скоростей. Если интересно, то прочитайте. На рис. 11 схема кругового буфера. Обман продолжается :)

[des00 25]

10 hours ago, Grizzly said:

@des00 недавно обновилась версия статьи по полярным кодам в 5G: https://arxiv.org/abs/1804.04389

В ней рассматривается согласование скоростей. Если интересно, то прочитайте. На рис. 11 схема кругового буфера. Обман продолжается :)

Благодарю). Я пока ушел в быстрые турбо и гибкие LDPC (как раз прям сейчас пилю корку 5G LDPC). На полярных кодах остановился на проблемах реализации стекового декодирования и достижения высоких скоростей кодирования на длинных кодах (подбор замороженных бит, для достижения высоких скоростей обработки). Но когда буду готов, планирую вернуться к ним)