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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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) я не решил, в этом и заключается вопрос. хотелось бы посмотреть на его характеристики. к сожалению не обладаю этими графиками. Спасибо, за помощь)




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

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

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

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

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

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




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



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

всё понятно. для GMSK будет тоже что и для сферического вакуума.
короче для модуляций с большими созвездиями возможно подставлять вероятность верного детектирования бит в функцию FEC-декодирования, в зависимости от расположения этих бит в созвездии, что дает дополнительно ~1,5 дБ для какого-нибудь qam64.
вообще, насколько оправдан ваш выбор?
"64 раза" к сожалению ничего не сказало, поскольку это может быть разница между 64 ОЦК и 2 E1 или 64 E1 и STM-1, ну вы понимаете.

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

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

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

2krux

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

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



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

теперь понятно) спасибо)

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

Спасибо, буду теперь читать

кстати, в том же самом DVB-S2 информация о типе фрейма, модуляции и кодировании передается в заголовке начала пакета

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

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

все верно, но тем не менее как вариант можно глянуть, вреда не будет.


ну можно и другой пример привести: если мне не изменяет память, то у Hughes в VSАТ системе используются фреймы разной длины, причем отличаются они заметно и применяется там как раз сверточный турбокод. но пакеты там, конечно, не 2 байта.

Дак дьявол в деталях. Может быть там иерархический канал, про что я сразу сказал. Но автор похоже хочет в одном канале всё гнать.
К тому же, он на короткие коды нацелился, а в том же TCC длиной 256 это ж всего ~10 байт полезная нагрузка, куда уж меньше.. :-))))

нет там никакой иерархической модуляции как, к примеру, в DVB. это Inroute каналы в TDMA режиме и полезная нагрузка в слоте там от 7 байт (считайте 112 бит кодированный слот для R=1/2) и выше, меньше не получится, потому как кроме плохой помехоустойчивости в довесок еще преамбула, постамбула, защитный интервал и т.д. короче избыточности в малых пакетах достаточно. но пример как раз неплохой, может TC пригодится.

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

Вообще-то при постоянной скорости кода R и помухоустойчивость будет постоянной. Причём тут длина?

т.е. от самого кода помехоустойчивость не зависит по-вашему? только от R?

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

BER одинакова, FER (PER) будет разной

P.S. имеется ввиду для одного и того же кода

С каких щей? Ведь на графиках в самом первом посте всё прекрасно видно. И для всех хороших кодов так..

Это всё можно было проще сказать:: с уменьшением длины кода нужно также снижать его R от исходных 1/3 до тех пор, пока его S/N не сравняется с S/N самого длинного кода.

Только вот если при переходе от 5114 к 1024 придётся снизить R всего от 0.33 до 0.3 (по моим подсчётам), то при дальнейшем укорочении R скорее всего упадёт до немыслимых низот. Считать это при мелких длинах уже бесполезно, можно только смоделировать, а так как нигде не видно графиков для ТСС с очень низким R, то это как бы намекает.... :-о

"Поучайте лучше ваших паучат."

Рад что вы так реагируете. Значит я тут не зря! :-))))))

Главное - себя не обмануть.