Перейти к содержанию

    

Rate matcher/dematcher для турбокода в LTE

Разбираюсь с тем, как производятся данные процедуры. Кто-нибудь реализовывал декодирование LTE? Возник вопрос по соотношению между разными параметрами. В особенности, когда несколько TB передаются в паре RB. Нашёл проекты на GitHub и описание в сети. Не могу понять, как получено значение (https://github.com/ttsou/openphy/blob/master/README.md#run)

Rate match length D=284

С K=280 все понятно, это A = 256 + 24 бита CRC. Откуда взялись ещё 4 бита? Кроме того, длины 284 в отличие от 280 нет в диапазоне от 40 до 6144 битов (размер кодового блока).

Вот тут есть объяснение процедура согласования скоростей: https://ltebasics.wordpress.com/2013/12/24/rate-matching-in-pdsch/amp/

Я бы ещё понял, если бы значение D было кратно 32.

Есть ли в сети исходники какой-нибудь эталонной реализации, чтобы разобраться?

UPD. Как только написал, сразу пришел в голову ответ ;) Это хвостовые 4 бита для выведения решетки в исходное состояние.

Тем не менее вопрос о какой-нибудь верной реализации в Matlab/Octave/C/C++ остаётся открытым. Вдруг уже кто-то работал и проверял. По приведенной выше ссылке и в OpenLTE с виду существенно отличаются. Наверное, в OpenLTE наиболее правильно.

UPD2.: Вот тут вроде бы похоже на истину :) По крайней мере, значения параметров не вызывают сомнений. Код рабочий.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Всё-таки нашлись ошибки. Для блоков с данными, превышающих 6144 бита, что-то сделано неверно при их разбиении на подблоки. Ошибки в размерностях массива.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 08.03.2019 в 23:08, Grizzly сказал:

Всё-таки нашлись ошибки. Для блоков с данными, превышающих 6144 бита, что-то сделано неверно при их разбиении на подблоки. Ошибки в размерностях массива.

В доках 3GPP TS 36.212 длина кодового слова в табличном перемежении (Table 5.1.3-3: Turbo code internal interleaver parameters) не превышает 6144 бит. Может в этом дело?

Мне казалось, что для полиномов с кодовым ограничением 4 нужно 3 терминационных бита, а не 4.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, coding4dsp сказал:

кодовым ограничением 4 нужно 3 терминационных бита, а не 4.

4. После кодирования со скоростью 1/3 будет 12 бит. Это в стандарте написано.

В принципе разобрался, где найти исходники в приведенной мною ссылке на OpenPHY все выглядит сделанным по стандарту. Надо было сразу внимательнее код читать. Он очень хорошо и понятно написан. В учебнике полно ошибок в коде :(

Пошел процесс. Только не все кодовые блоки удаётся декодировать, разбираться ещё много.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
10 минут назад, Grizzly сказал:

4. После кодирования со скоростью 1/3 будет 12 бит. Это в стандарте написано.

3 на систематические биты, 3 на проверочные биты 1-го RSC, 3 на проверочные биты 2 RSC и еще 3 на систематические биты 2-го RSC. 

Изменено пользователем coding4dsp

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 часа назад, coding4dsp сказал:

3 на систематические биты, 3 на проверочные биты 1-го RSC, 3 на проверочные биты 2 RSC и еще 3 на систематические биты 2-го RSC. 

Спасибо, что поправили. Неверно написал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Интересно, а можно ли как-то идентифицировать на приемной стороне скорость кода после rate matcher, не используя данные служебных каналов, в которых передается данная информация в косвенном виде? Надо подумать. Понятно, что примерно можно, турбокод выправит ошибки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
On 3/11/2019 at 10:04 PM, coding4dsp said:

3 на систематические биты, 3 на проверочные биты 1-го RSC, 3 на проверочные биты 2 RSC и еще 3 на систематические биты 2-го RSC. 

Занятно, а ссылок на сравнение Wimax/DVB RSC с этим турбокодом у вас нет? Просто странно почему они не сделали замыкание решетки как в DVB для упрощения декодирования, а ввели терминирование. Или на декодере с однобитным входом это не работает? 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, des00 сказал:

Занятно,

Я делал турбо-кодек только под LTE. Посмотрел DVB - там duo-binary турбо-код с tail-biting, я с таким не сталкивался. Вы же про tail-biting говорите? В рекурсивном сверточном коде последнее состояние от всех данных зависит, а не от k-последних. Однако, если в wimax/dvb используется duo-binary с tail-biting, то, значит, я не до конца разобрался. 

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

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

На приеме с увеличением кол-ва итераций надежность оценки терминационных символов расти, конечно, не будет, так как для них нет Extrinsic'ов. После обратного прохода, эти биты, конечно, отбросят, но декодер ведь шел из известного конечного состояния, а это главное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
10 minutes ago, coding4dsp said:

Я делал турбо-кодек только под LTE. Посмотрел DVB - там duo-binary турбо-код с tail-biting, я с таким не сталкивался. Вы же про tail-biting говорите? В рекурсивном сверточном коде последнее состояние от всех данных зависит, а не от k-последних. Однако, если в wimax/dvb используется duo-binary с tail-biting, то, значит, я не до конца разобрался. 

На приеме с увеличением кол-ва итераций надежность оценки терминационных символов расти, конечно, не будет, так как для них нет Extrinsic'ов. После обратного прохода, эти биты, конечно, отбросят, но декодер ведь шел из известного конечного состояния, а это главное.

Да про него, правда в стандарте эта операция называется "Circulation of Initial State" и проводится без дополнительных бит данных. Методом двойного кодирования. В этом случае начальное и конечное состояние одинаково. Это используется при декодировании.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
9 минут назад, des00 сказал:

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

Когда приходит пора терминации, то активен ключ В. 

rsc_termination.jpg

Изменено пользователем coding4dsp

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
15 minutes ago, coding4dsp said:

Когда приходит пора терминации, то активен ключ В.

Спасибо, теперь понятно. не увидел сразу) Прикольно. Надо запомнить на будущее

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

@coding4dsp а вы реализовывали только кодер/декодер или всю процедуру работы с битами? Не до конца понял стандарт. Если у нас TB больше максимально допустимого кодового слова, происходит деление на блоки. Длина блоков и длина E после rate matcher одинакова должна быть для всех блоков или может быть различной?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, Grizzly сказал:

@coding4dsp а вы реализовывали только кодер/декодер или всю процедуру работы с битами? Не до конца понял стандарт. Если у нас TB больше максимально допустимого кодового слова, происходит деление на блоки. Длина блоков и длина E после rate matcher одинакова должна быть для всех блоков или может быть различной?

 

Только кодер/декодер, по этому с ходу на ваш вопрос не отвечу((

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, coding4dsp сказал:

Только кодер/декодер

У меня на самом деле LTE-like, поэтому вопросов много. Вслепую приходится вытягивать информацию. Непонятно, где ошибаюсь, поскольку настоящего LTE для отработки нет :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация