[balakhonoff 0]

Всем доброго времени суток,

Проектирую радиоканал, выявилась такая проблема:

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

Можно конечно делать пакет из N блоков (N-любое), но так сразу падает помехоустойчивость.

 

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

[petrov 6]

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

 

Для приближения к пределу Шеннона принципиально требуется большая длина блока от нескольких тысяч, на коротких такой же помехоустойчивости достичь невозможно.

[DASM 0]

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

 

«на пальцах» очень хорошо расжевано у Б. Скляра

 

На AWGN не нужно, а именно на радио. Если объекты нестационарны в пространстве

[Grumbler_2002 0]

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

133K.pdf

[Grumbler_2002 0]

Туда же в тему.

44it07_macmullan.pdf

[balakhonoff 0]

Спасибо, решил делать постоянную длину пакета.

[balakhonoff 0]

Передумал делать постоянную длину пакета ,слишком уж большие затраты при частых маленьких пакетах.

Посоветовали посмотреть в стандарт 802.15.4, так там используется такая схема кодирования с переменной длиной пакета:

сначала Рид-соломон (K+8,K), потом сверточный код (кодовая скорость 1/2). Так у них получается итоговая кодовая скорость 0.44.

Хотелось бы понять, действительно ли здесь не существенно на помехоустойчивость влияет размер пакета (вопрос в том, не так ли как в турбокодах вероятность ошибки от длины пакета гуляет в тысячи и десятки тысяч раз)?

[krux 8]

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

[Dr.Alex 0]

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

 

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

 

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

 

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

 

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

 

4) Не понял, почему вы решили, что для convolutional+RS длина не имеет значения? :-))))) Это могло бы означать только одно:: код крайне плох или просто не подходит для гауссова канала.

В действительности convolutional+RS применялся в старом DVB и теперь заменён на LDPC, на чём было выиграно ~3 дБ.

Так что ваш turbo-conv точно лучше чем conv+RS, и поэтому задаваться вопросом, как на него влияет длина, вообще бессмысленно.

[balakhonoff 0]

насчет вакуума понял, у меня 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 0]

1) Отличный пример. В смысле, длина сообщения 2 байта это великолепно :-)))

Передать их близко к Шеннону НЕВОЗМОЖНО, примите это как данность, а значит не изобретайте вечный двигатель, а измените что-то другое в своей системе.

К тому же, 2 байта не несут какой-то значимой инфрмации в системе, которая в среднем гонит в сотни раз больше. Поэтому просто подождите, пока накопится гораздо больше, и тогда передавайте.

 

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

 

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

[balakhonoff 0]

1) Отличный пример. В смысле, длина сообщения 2 байта это великолепно :-)))

Передать их близко к Шеннону НЕВОЗМОЖНО, примите это как данность, а значит не изобретайте вечный двигатель, а измените что-то другое в своей системе.

К тому же, 2 байта не несут какой-то значимой инфрмации в системе, которая в среднем гонит в сотни раз больше. Поэтому просто подождите, пока накопится гораздо больше, и тогда передавайте.

 

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

 

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

 

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

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

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

 

[Dr.Alex 0]

когда это служебные 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 разной длины. Но если очень хочется....

[krux 8]

всё понятно. для GMSK будет тоже что и для сферического вакуума.

короче для модуляций с большими созвездиями возможно подставлять вероятность верного детектирования бит в функцию FEC-декодирования, в зависимости от расположения этих бит в созвездии, что дает дополнительно ~1,5 дБ для какого-нибудь qam64.

вообще, насколько оправдан ваш выбор?

"64 раза" к сожалению ничего не сказало, поскольку это может быть разница между 64 ОЦК и 2 E1 или 64 E1 и STM-1, ну вы понимаете.

 

И, таки-да, пакеты разной длины обычно не делают.

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

 

Вообще, вспомните где раньше исторически стал применяться FEC. ЕМНИП, в "дальнем космосе", т.е. это медленная передача длинными блоками, которые могут быть декодированы гарантированно (сеансы связи ограничены геометрией, и переповторы просто невозможны из-за накопления новых данных). Вот в смежных областях, где FEC можно было стянуть почти как кальку он и поселился. Сейчас FEC стали применять в широкополосных каналах, в которых блок данных набирается достаточно быстро.

Если у вас модемный канал, быстрого накопления блоков вы не получите, соответственно целесообразность применения FEC в вашем случае с CSMA/CA может быть вообще под вопросом и тогда стоит думать что применить вместо простейшего CSMA/CA.

Изменено 23 сентября, 2013 пользователем krux

[balakhonoff 0]

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

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

 

2krux

 

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

А что бы Вы предполагаете целесообразнее? я не совсем понимаю, поясните пожалуйста.