Никто не интересовался, какой из стандартизованных турбокодов работает ближе всего к шеннону?
Интересуют только коды длиной менее килобита. Лучше даже ближе к 512 битам.
Понятно что от декодера тоже зависит, но будем считать что декодер оптимален.

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

сейчас изучаю стандарт 802.16. для коротких турбокодов там используются коды с проверкой на четность и коды хэминга. Причем в более навороченном варианте (OFDMA) предпочтение отдано кодам Хэминга. Помимо этого в таблице LDPC кодов (OFDMA) указаны коды с длинной от 576 бит. Может быть порыть в той степи ?

По-видимому, там нужна более высокая помехоустойчивость


Ага, вспомнил, где это я мог видеть )))

Смотря что под этим подразумевать. На примере LDPC знаю, что чем меньше избыточность (выше R), тем код может быть ближе к пределу Шеннона для BIAWGN. Но штука в том, что чем выше R, тем сам предел BIAWGN дальше от "предела Шеннона вообще".
Чтобы не быть голословным:
- при R = 1/4 предел BIAWGN всего на 0.05 дБ выше предела "вообще"
- при R = 1/2 предел BIAWGN на 0.188 дБ выше предела "вообще"
- при R = 9/10 предел BIAWGN почти на 2 дБ выше предела "вообще"
- при дальнейшем приближении R к единице разница быстро уходит на бесконечность

Поэтому с точки зрения приближения к Шеннону коды с рэйтом более 1/2 невыгодны.




Ну эффективность всё-таки сначала нужно как-то задефайнить.
Существует код LDPC длины 512 (1/2), работающий на расстоянии ~2.5 дБ от Шеннона. Сомневаюсь, что старый Витерби+RS может его побить, иначе его бы и не прекращали использовать.
Но мне казалось, что турбосвёрточные всё-таки получше должны работать при таких длинах. (У меня с ними практического опыта нет, в отличие от LDPC, поэтому вот пытаюсь разобраться.) А на короткие LDPC сейчас огромные усилия исследователей направлены в основном из-за того, что они свободны, в отличие от турбо, требующих лицензирования, роялти и всё такое, так думалось мне.
Но пока почему-то не вижу стандартизованных турбо, которые бы обошли вышеупомянутый LDPC, от чего испытываю когнитивный диссонанс.

так я о том же самом и говорил


честно говоря, не совсем понятно, что имеется ввиду


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


да, кстати, сверточные турбокоды (циркулярные) как бинарные, так и небинарные используются в современных стандартах и как раз на таких коротких фреймах (можете глянуть DVB-RCS (2)).

То что я назвал "предел Шеннона вообще" - это предел без ограничения на тип модуляции, и он задаётся известной всем нам с детства формулой C=W*log2(1+S/N).
Но если у нас скажем QPSK, то предел уже другой (BIAWGN), и он выше (хуже) предела "вообще".
При R стремящемся к 0 пределы сливаются, при R стремящемся к 1 (что соответствует отсутствию кодирования) разница становится бесконечной. (Физический смысл очевиден: QPSK без кодирования может обеспечить сколь угодно малую вероятность ошибки только если шума вообще нет.)

Другими словами::
Если к примеру S/N > 0 дБ, то мы можем передавать 1 бит/c/Гц без ошибок, это и есть предел "вообще".
Но если у нас BIAWGN, то это возможно только при S/N > 0.188 дБ.
И с увеличением спектральной эффективности свыше 1 бит/c/Гц эта поправка быстро растёт и стремится к бесконечности.



Мда, первая же найденная статья удивила.

Если ей верить, то их LDPC и CTC одинаковой длины 576 (1/2) и работают одинаково (те же упомянутые мной ~2.5 дБ до Шеннона, что забавно), и не понятно, зачем они оба нужны? :-/

Dr.Alex а не проще рассматривать всю эту совокупность параметров в зависимости от Eb/No, как это и принято делать?

Не понял, вы не согласны только с использованием S/N?
Действительно мне S/N гораздо привычнее Eb/No. Я бы взялся объяснить неудобность и даже нелепость Eb/No (с моей точки зрения), но это на самом деле не имеет значения.
Кстати, при R=1/2 Eb/No и S/N численно совпадают.

Я не согласен с тем, что в том контексте, в котором вы задали вопрос, модуляции здесь вообще касаться незачем, мы рассматриваем пока вопросы кодирования, а не системы в целом, поэтому и предел Шеннона может быть только один для конкретно выбранного типа модуляции


интересно было бы почитать, иначе почему везде пользуются именно Eb/No


как частный случай для QPSK

Я и не касаюсь модуляции, это был только пример. Просто вы почему-то хотите рассматривать код только относительно предела BIAWGN, а я считаю это совершенно бесполезным, и сравниваю всё c Channel Capacity имени Шеннона.




Ну во-первых не везде. Никто не объявлял бойкота S/N, и во многих статьях оно используется.
Вообще, нелепость Eb/No многогранна, и на ночь глядя всё не описать.
Пока предлагаю решить элементарную задачку::

Инженер использует в своей системе связи код с R=1/4. Напоминаю, что предел Eb/No для него равен минус 0.8 дБ.
В какой-то момент выясняется, что скорость передачи данных недостаточна, и он решает просто увеличить R до 1/2 (предел Eb/No = 0.2 дБ).
На сколько дБ нужно увеличить мощность передатчика, чтобы сохранить энергетический запас (бюджет) канала неизменным?

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


при фиксированном значении спектральной эффективности R/W и для обеспечения той же самой вероятности битовой ошибки Pb, очевидно, что надо увеличить Eb/No на 1 дБ, только к чему это все?

А кто сказал "при фиксированном значении спектральной эффективности"?
По условию изменилось только R кода, значит и спектральная эффективность изменилась.

в конце указано что при прочих равных LDPC декодируются проще. И еще у CTC там 8 итераций, а у LDPC 100. И мне показалось странным что они не рассматривали BTC коды.

Кину свои несколько копеек - BTC предлагались как альтернатива для высоких (R здорово больше чем 1/2) скоростей кодирования. На сколько помню, у них проблемы когда нужна гибкость (несколько поддерживаемых одной схемой скоростей кодирования и более-менее плавное изменение размеров блока). Как по этим параметрам обстоят дела у совеременных LDPC просто не знаю.