Простой вопрос по защите данных с помощью CRC Опции

[_Pasha]

Доброго времени суток.
Дано: протокольчик связи между устройствами в одномастерной сети. Некое сообщение из, допустим, 4-х байт, защищено CRC7. Поле адреса устройства считается при подсчете CRC7, но реально не передается. Принимающая сторона при приеме сообщения учитывает свой адрес при подсчете CRC, проверяя таким образом валидность.
Я понимаю, что передать сообщение в виде (адрес)-(данные)-(CRC) или (данные)-(CRC) - это две большие разницы. Кто в теме, подскажите, чем можно оценить вероятность приема ложного сообщения во втором случае.

[i-mir]

По закону распределения ошибок в канале такого типа - сказать ничего не могу

Все равно нужно от чего-то оттолкнуться если нет экспериментальных данных.
Например ГОСТ 26.205-88 КОМПЛЕКСЫ И УСТРОЙСТВА ТЕЛЕМЕХАНИКИ, п.2.11.2.
Укажите согласно ГОСТу требования к вашему устройству на каналы связи.
Если это устройства "критического использования" - то нужно использовать
другие отраслевые документы.

После этого можно будет прикинуть помехозащищенность вашего протокола
и его соответствие требованием. Если уровень защиты CRC "в лоб" будет не
высоким, тогда рассматриваются другие типы кодирования.
Скажите в чем необходимость 8B/10B ? Выравнивание потока 0/1 для оптики ?

В качестве примера, для очень зашумленного канала (р=10е-3) вероятности
необнаруживаемого пропуска ошибок CRC8/16 привел на рис. Видно что
заголовок у вас защищен в три раза лучше чем поле данных.
Абсолютные значения вероятностей будут зависить от исходных данных
и выбранных вами требований.

Сообщение отредактировал i-mir - Apr 27 2011, 14:30

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

 

Прикрепленные файлы

 _____26_205_88.pdf ( 983.09 килобайт ) Кол-во скачиваний: 998

 

[Krys]

Уважаемый i-mir, спасибо за конкретную помощь.

Все равно нужно от чего-то оттолкнуться если нет экспериментальных данных.
Например ГОСТ 26.205-88 КОМПЛЕКСЫ И УСТРОЙСТВА ТЕЛЕМЕХАНИКИ, п.2.11.2.
Укажите согласно ГОСТу требования к вашему устройству на каналы связи.
Если это устройства "критического использования" - то нужно использовать
другие отраслевые документы.

Спасибо за ГОСТ. Думаю, категория 3я, ну максимум 2я. Не критического использования. Внутри поля данных этого пакета будут инкапсулированы пакеты других протоколов, у них будет своя защита от ошибок. К тому же ещё 8B/10B часть ошибок выловит. Он ловит все единичные ошибки в пределах одного символа.

Скажите в чем необходимость 8B/10B ? Выравнивание потока 0/1 для оптики ?

Да, устранение постоянной составляющей, самосинхронизация битов и байтовая синхронизация.

В качестве примера, для очень зашумленного канала (р=10е-3) вероятности
необнаруживаемого пропуска ошибок CRC8/16 привел на рис. Видно что
заголовок у вас защищен в три раза лучше чем поле данных.
Абсолютные значения вероятностей будут зависить от исходных данных
и выбранных вами требований.

У меня здесь следующие непонятности:
1. Где Вы взяли такие графики? Их считает программа? А Вы могли бы ей поделиться?
2. Может быть, более наглядно было бы построить графики для той же вероятности, что фигурирует в ГОСТе (т.е. 1e-4)?
3. "вероятности необнаруживаемого пропуска ошибок" - этот термин какому соответствует в табл. 3 ГОСТа?
4. Как Вы рассчитали, что в 3 раза лучше заголовок защищён? Я смотрю на графики, там для CRC8 для длины 32 байта вероятность неотличима от нуля. Или это для длины в битах? Тогда для графика CRC16 нет данных для длины 2 кБ. В любом случае вижу, что защищённость поля данных никакая...
5. Как вообще трактовать такую вероятность? Это обратная величина от среднего количества пакетов, спустя которые ошибка в одном пакете не будет обнаружена? Например, смотрим на график для CRC8, для значения длины 256 (попугаев), вероятность 2,5e-5. Обратная величина это 40 000. Т.е. правильно ли я понимаю, что, 40 000 пакетов принимаются, если в них появляется ошибка, то она обнаруживается, а потом 40 001-й пакет проходит, и в нём ошибка не обнаруживается? Или как правильно трактовать?
Извиняюсь за глупые вопросы, в этом мои знания неглубоки, а вузовский курс тервера давно благополучно забыт, к сожалению.