Помехоустойчивое кодирование, Недостатки турбокодов Опции

[Goose]

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

Хотелось бы одинаковой помехоустойчивости для пакетов разной длины. Какие бы вы посоветовали варианты? Может быть другие помехоустойчивые коды?

[Goose]

Передумал делать постоянную длину пакета ,слишком уж большие затраты при частых маленьких пакетах.
Посоветовали посмотреть в стандарт 802.15.4, так там используется такая схема кодирования с переменной длиной пакета:
сначала Рид-соломон (K+8,K), потом сверточный код (кодовая скорость 1/2). Так у них получается итоговая кодовая скорость 0.44.
Хотелось бы понять, действительно ли здесь не существенно на помехоустойчивость влияет размер пакета (вопрос в том, не так ли как в турбокодах вероятность ошибки от длины пакета гуляет в тысячи и десятки тысяч раз)?

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

 

[Dr.Alex]

Передумал делать постоянную длину пакета

Мда.. Столько нелепостей высказано, что не знаешь с чего начать.. :-о

1) Длина пакета определяется допустимой задержкой. Если задержка может быть бОльшей (условно), то вы просто ждёте, пока накопится информация на целый пакет, и никаких """больших затрат при частых маленьких пакетах""" не будет.

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

3) Вы как-то странно трактуете график. Разницу между кодами характеризуют вовсе не """вероятностью ошибки в 10000 раз""", а децибеллами, при которых достигается НЕОБХОДИМАЯ вероятность. В данном случае разница между кодами составляет не более 2 дб, если не брать уж совсем позорно короткие экземпляры. А это не так уж много, учитывая разницу в длине в 20 раз!!

4) Не понял, почему вы решили, что для convolutional+RS длина не имеет значения? :-))))) Это могло бы означать только одно:: код крайне плох или просто не подходит для гауссова канала.
В действительности convolutional+RS применялся в старом DVB и теперь заменён на LDPC, на чём было выиграно ~3 дБ.
Так что ваш turbo-conv точно лучше чем conv+RS, и поэтому задаваться вопросом, как на него влияет длина, вообще бессмысленно.

[Goose]

насчет вакуума понял, у меня GMSK. но графики вроде бы достаточно информативны и без модуляции.

Мда.. Столько нелепостей высказано, что не знаешь с чего начать.. :-о

1) Длина пакета определяется допустимой задержкой. Если задержка может быть бОльшей (условно), то вы просто ждёте, пока накопится информация на целый пакет, и никаких """больших затрат при частых маленьких пакетах""" не будет.

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

3) Вы как-то странно трактуете график. Разницу между кодами характеризуют вовсе не """вероятностью ошибки в 10000 раз""", а децибеллами, при которых достигается НЕОБХОДИМАЯ вероятность. В данном случае разница между кодами составляет не более 2 дб, если не брать уж совсем позорно короткие экземпляры. А это не так уж много, учитывая разницу в длине в 20 раз!!

4) Не понял, почему вы решили, что для convolutional+RS длина не имеет значения? :-))))) Это могло бы означать только одно:: код крайне плох или просто не подходит для гауссова канала.
В действительности convolutional+RS применялся в старом DVB и теперь заменён на LDPC, на чём было выиграно ~3 дБ.
Так что ваш turbo-conv точно лучше чем conv+RS, и поэтому задаваться вопросом, как на него влияет длина, вообще бессмысленно.

1) В нашем случае длина пакета влияет на занятость эфира, система с множеством пользователей и CSMA/CA. и скорости существенно отличаются (в 64 раза максимальная и минимальная), то есть крайне нежелательно например на минимальной скорости передавать 2 байтное сообщение в пакете из 256 байт, так как станции которые хотят передать 1ms сообщение наполненное информацией на большой скорости будет ждать избыточного траффика 300ms, который вообще ничего не несет, задержка важна, но не только она.
2) и приоритет тоже предполагается разный, голос и данные, голос -приоритетный.
3)давайте посчитаем. как вы говорите в 20 раз различающиеся длины пакетов: пусть 5144 и 256 бит. Учитываем, что пакет с одной ошибкой отбрасывается (необходимы только полностью корректные пакеты). К примеру по уровню Eb/N0 = 1.
а) 5144, Вероятность ошибки(график)=10^(-4)=0.0001. Вероятность успешной передачи одного бита = 0.9999. Вероятность успешно (без единой ошибки) передать все сообщение (а это 5144бит) = (0.9999)^5144 = 59.8%
б) 256, Вероятность ошибки(график)=10^(-2)=0.01. Вероятность успешной передачи одного бита = 0.99. Вероятность успешно (без единой ошибки) передать все сообщение (а это 256 бит) = (0.99)^256 = 7.6%
Это существенное различие. Или нельзя ориентироваться на такое Eb/N0. При Eb/N0=2, уже получается 93% и 99,99% - уже конечно не существенно. Но по расстоянию получается разница почти в 1,5 раза. Значит буду при получении битого пакета переходить на более низкую скорость.
4) я не решил, в этом и заключается вопрос. хотелось бы посмотреть на его характеристики. к сожалению не обладаю этими графиками. Спасибо, за помощь)




Кстати еще такой вопрос, при раскодировании такого пакета надо заранее знать его длину. как обычно это делается? она посылается в начале пакета, сильно закодированная от помех?

[Dr.Alex]

1) Отличный пример. В смысле, длина сообщения 2 байта это великолепно :-)))
Передать их близко к Шеннону НЕВОЗМОЖНО, примите это как данность, а значит не изобретайте вечный двигатель, а измените что-то другое в своей системе.
К тому же, 2 байта не несут какой-то значимой инфрмации в системе, которая в среднем гонит в сотни раз больше. Поэтому просто подождите, пока накопится гораздо больше, и тогда передавайте.

3) Зачем вы всё это считали? Поскольку кривая очень быстро спадает, в любом случае между 256 и 5114 всего ~2 дБ, и не надо никакие разы и проценты считать. А 2 дБ по расстоянию в вакууме это 25%, а в наших условиях и того гораздо меньше..

5) "обычно" это вообще не делается, а так конечно можно и другим кодом..

[Goose]

1) Отличный пример. В смысле, длина сообщения 2 байта это великолепно :-)))
Передать их близко к Шеннону НЕВОЗМОЖНО, примите это как данность, а значит не изобретайте вечный двигатель, а измените что-то другое в своей системе.
К тому же, 2 байта не несут какой-то значимой инфрмации в системе, которая в среднем гонит в сотни раз больше. Поэтому просто подождите, пока накопится гораздо больше, и тогда передавайте.

3) Зачем вы всё это считали? Поскольку кривая очень быстро спадает, в любом случае между 256 и 5114 всего ~2 дБ, и не надо никакие разы и проценты считать. А 2 дБ по расстоянию в вакууме это 25%, а в наших условиях и того гораздо меньше..

5) "обычно" это вообще не делается, а так конечно можно и другим кодом..

1) когда это служебные 2 байта при прокладывании пути в mesh-сети то их нельзя накапливать, а я могу предположить что это не единственный пример.
3) объясните про какие 2 дБ Вы все время говорите.
5) обычно что не делается? как Вы узнаете какой block-size заранее?

[Dr.Alex]

когда это служебные 2 байта при прокладывании пути в mesh-сети то их нельзя накапливать

Это никого не волнует. Как я уже сказал, пакет в 2 байта надёжно передать невозможно. На этом вопрос исчерпан. Ищите другие варианты.

объясните про какие 2 дБ Вы все время говорите.

Посмотрите расстояние в Eb/No между графиками 256 и 5114 на уровне, скажем, BER=10-6. Там примерно 2 дБ.
Вы конечно справедливо заметили, что нужно считать PER, а не BER, но поскольку кривые спадают почти отвесно, то если для 256 брать Eb/No при BER=10-6, а для 5114 при BER=10-7, то расстояние почти не изменится. На самом деле оно даже уменьшится.
Поэтому я и говорю, что расстояние между кодами 2 дБ. Это совсем неплохо, от добра добра не ищут.

обычно что не делается? как Вы узнаете какой block-size заранее?

Не делают пакеты FEC разной длины. Но если очень хочется....

[Goose]

Не делают пакеты FEC разной длины. Но если очень хочется....

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

2krux

В моем случае "в 64 раза" - это GMSK c технической скоростью 2048кбит/с и GMSK со скоростью 32кбит/с (я забыл написать).
А что бы Вы предполагаете целесообразнее? я не совсем понимаю, поясните пожалуйста.

[Serg76]

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

Делают, в различного рода адаптивных системах, где может меняться не только длина пакета (правда не в десятки раз), но модуляция и скорость кодирования. В качестве примера можно посмотреть уже упомянутые здесь стандарты широкополосной связи такие, как DVB-S2 и Comtech VersaFEC.

[Dr.Alex]

Делают, в различного рода адаптивных системах, где может меняться не только длина пакета (правда не в десятки раз), но модуляция и скорость кодирования. В качестве примера можно посмотреть уже упомянутые здесь стандарты широкополосной связи такие, как DVB-S2 и Comtech VersaFEC.

Вы кажется что-то недопоняли. В DVB код "на ходу" не меняется. Он меняется по команде с земли, если допустим условия приёма в одном из лучей резко ухудшились, ему могут скорость кода снизить. VersaFEC не знаю, но наверняка то же самое.

А Афтор хочет буквально для каждого пакета длину FEC менять. Набралось данных на длинный пакет - шлём длинный, набралось 2 байта - шлём 2 байта, а на сэкономленное время освобождаем канал.. :-)))