почему CRC32 нелинейный в gnuradio?

У меня вопрос по поводу нелинейности CRC32 в gnuradio.

Я работаю над проектом, в котором мне нужен линейный CRC32, означающий, что: crc(a xor b) = crc(a) xor crc(b), где a и b представляют пакет.

Реализация CRC32 в gnuradio по умолчанию нелинейна, поэтому мне пришлось изменить код, чтобы сделать его линейным.

Я провел некоторое исследование теории CRC и обнаружил 2 причины нелинейной реализации CRC:

1- с линейным CRC мы можем иметь один и тот же CRC для 2 разных пакетов нулей, например crc(0000 0000) = crc(00000 00 00000). Поэтому, если я добавлю дополнительные нули к пакету, содержащему только нули, CRC не сможет обнаружить ошибки (дополнительные нули).

2- вторая причина в том, что с линейным CRC, если я добавлю нули в начало пакета, CRC не сможет обнаружить ошибки. например: crc(10010 1101) = crc(0000 1000 1101)

Теперь мой вопрос: при передаче пакетов между двумя USRP биты могут иметь ошибки (например, из-за плохого SNR), поэтому бит «1» может стать битом «0» и наоборот. Тем не менее, я не думаю, что биты могут быть добавлены (как в двух случаях, указанных выше) к пакетам, и поэтому причины реализации нелинейного CRC не должны относиться к gnuradio.

Так почему же у нас по умолчанию в gnuradio нелинейная CRC?

И если я использую линейный CRC при передаче между двумя USRP, будет ли это проблемой?

Спасибо,


crc32 gnuradio gnuradio-companion usrp telecommunication
person nader    schedule 10.04.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Такие CRC по-прежнему линейны, только с добавленной константой. По аналогии, y = a x является линейным, но также и y = a x + b, где b — ненулевая константа.

В этом случае crc(a xor b) xor crc(a) xor crc(b) является константой для всех сообщений одинаковой длины a и b. Эта константа — crc(0), то есть CRC всех нулей той же длины сообщения.

С такой линейностью нет абсолютно никаких проблем, и на самом деле она имеет свои преимущества. В частности, изменение в сообщении, добавляющее префикс из нулей, будет считаться ошибкой.

person Mark Adler    schedule 10.04.2017