Вот попытка с некоторыми идеями, взятыми из http://en.wikipedia.org/wiki/Frame_Relay.
Начинайте каждый 64-битный блок с фиксированным заголовком 01110. Если у вас есть больше информации заголовка (например, порядковый номер или чередующийся битовый флаг, контрольная сумма ...), вы, вероятно, можете договориться о том, чтобы битовый массив 01110 никогда не появлялся. Для произвольных данных замените любое вхождение 0111 на 01111 - это означает, что эффективная скорость передачи данных теперь зависит от базовых данных. Попросите поставщика данных для этого уровня убедиться, что данные в значительной степени случайны, например, применяя http://en.wikipedia.org/wiki/Randomizer. я думаю, что ваша общая потеря данных здесь составляет около 6 битов, что соответствует 6 битам, необходимым для описания сдвига 0,63.
В приемнике найдите 01110, чтобы отметить истинное начало блока. Если вы не видите точно такой шаблон, вы знаете, что фрагмент искажен. Я думаю, что требуется как минимум двухбитная ошибка, чтобы уничтожить существующий 01110 и создать поддельный.
Искажения, которые вызывают смещение чанка, не похожи на обычные биты, поэтому вычисления частоты ошибок CRC не будут применяться "из коробки". Я бы включил контрольную сумму не-CRC в каждый блок - возможно, вычисленный по модулю мод 31 или мод 961, чтобы избежать запрещенного 5-битного паттерна 01110, хотя в зависимости от того, что примыкает к этому, вам может потребоваться более строгие ограничения. В этом случае вероятность того, что ошибка не будет обнаружена, будет примерно 1 к 31 или 1 к 961, без какой-либо конкретной гарантии по всем отдельным ошибкам, в отличие от полиномиальной CRC.
Я не думаю, что у вас достаточно места для разумного исправления ошибок для каждого блока, но вы можете включать N блоков исправления ошибок после каждых M обычных блоков, используя, например, SECDED применяется вниз по столбцам. Вы могли бы иметь, например, 57 фрагментов, несущих данные, а затем 6 фрагментов с исправлением ошибок, обрабатывая каждую позицию бита полезной нагрузки как несущую 57 бит данных, а затем 6 бит контрольной суммы. Это должно хорошо работать, если ошибки приводят к повреждению всего или ни одного фрагмента, например вызвав сбой перестройки чанка.
после комментария -
РЕДАКТИРОВАТЬ
ОК, с одним непрерывно передаваемым сообщением у вас меньше пропускная способность, но относительно больше процессор. На ум приходят две вещи:
1) При наличии любого вида контрольной суммы или другого ограничения на сообщение вы можете добиться некоторого ограниченного исправления ошибок, например, например. с учетом всех однобитовых ошибок, переворачивания полученного сообщения и проверки работоспособности контрольной суммы.
2) Можно проверить сообщение, чтобы увидеть, соответствует ли предложенная выше схема вставки битов, просмотрев только 5-битное окно, переданное над сообщением. Я думаю, что это справедливо, даже если вам нужно настроить его для правильной работы в цикле. Это означает, что сообщение может быть проверено BDD гибкого размера (Knuth 4A, раздел 7.1.4). Это означает, что вы можете подсчитать количество 64-битных сообщений, которые соответствуют схеме битовой вставки, и эффективно конвертировать между номером сообщения и сообщением (тот же раздел). Таким образом, вы можете использовать эту схему без основной рандомизации или наихудших предположений относительно данных, подлежащих отправке, просто рассматривая ее как кодирование числа в диапазоне 0..N (где N должно быть вычислено с помощью BDD) и 64-битное сообщение. На самом деле, менее элегантно, я думаю, вы могли бы использовать динамическое программирование с 5-битным состоянием вместо BDD.