Обновить
Комментарии 13
Интересно, но несколько сумбурно
Совершенно не ясен смысл такого исходного текста декодера — он ничего толком не поясняет. Код процедур с комментариями был бы уместнее.
Аналогично про умножению на матрицу — «Умножение на матрицу Арикана осуществляется с помощью функции, приведенной ниже:» и дальше название функции. Что, где, куда, зачем ?! Можно было бы сразу и код функции привести.
Непонятно как зачем вообще такие исходники показывать :) Плюс, интересна реализация декодра.
Если не забыть про первую вставку, по коду видно, какие параметы у вызова. А про умножение на матрицу раскрывать нечего, оно и есть умножение на матрицу.

Реализация декодера в Гитхабе, просто откройте и посмотрите. Если будут вопросы, милости присим, задавайте сюда.
Стоит заметить, что при умножении на матрицу Арикана, все сложения выполняются по модулю 2.
Зачем-то прочитал стандарт openUNB.
Так себе стандарт, если честно. Если хуже не сказать. А описание вообще ужасное.
Есть, например, стойкое ощущение (или даже уверенность), что протокол очень уязвим к целому спектру атак. Шифруются только данные, используется постоянный ключ при длине шифроблока 64/128 бит, пакеты-подтверждения не шифруются. Т.е., как минимум, возможны запись и повторная передача зашифрованных сообщений, отправка поддельных подтверждений о приёме и подделка пакетов с нулевой длинной данных. Одно это уже ого-го дыра.
А постоянный ключ 64 бита с учётом известных уязвимостей алгоритма шфирования, вероятно, может быть подобран за время порядка месяца на вполне доступном оборудовании.
Для тех же бытовых счётчиков сразу приходит на ум примитивная атака с передачей одних и тех же показаний, либо нужно уже поверх протокола какие-то костыли городить.
Принципиально нет широковещательных пакетов, и при большом количестве абонентов становятся просто невозможными некоторые типовые операции — от массового переконфигурирования устройств, до синхронизации времени. Ведь каждому устройству должен быть передан адресный пакет. В результате базовая станция может обработать лишь очень небольшое число абонентов. В то же время, в условиях города их могут быть тысячи и десятки тысяч.
Нет возможности полноценного пакетного обмена с устройствами — один цикл обмена занимает не менее 48 секунд! В результате типовая операция «получить данные от устройства, выдать команду устройству, получить ответ» занимает 48x3 — не менее 144 секунд. Это по оптимистичному сценарию. Если прикинуть максимальное количество абонентов, которых можно обслуживать по такому протоколу для случая те же бытовых счётчиков, то получается весьма печальная картина.
Почему-то принципиально исключена возможность инициации связи по нисходящему каналу. «Потому что, устройства не имеют часов реального времени». ?!!! Это более чем спорное утверждение, т.к. сейчас нет проблемы в часах реального времени — они есть или могут быть «бесплатно» реализованы практически во всех устройствах IoT, а их потребление не является определяющим (единицы микроампер или даже сотни наноампер). А довод о низкой точности генераторов у абонентских устройств в данном контексте вообще ложный — малопотребляющие кварцевые резонаторы на 32,768 кГц сейчас стоят практически везде, и даже в самом дешёвом исполнении во всём температурном диапазоне обеспечивают точность порядка секунды-двух в сутки, чего более чем достаточно для грубой синхронизации временных интервалов. При этом развитие идёт в сторону усложнения даже самых простых устройств IoT.
Возможности подстройки часов и синхронизации времени абонентских устройств тоже нет. Только через костыли в виде отправки отдельного информационного пакета каждому устройству. Хотя, это крайне востребованная функция.
И из-за принципиальных ограничений низкоуровневого протокола решить все эти проблемы какими-то мерами на более высоких уровнях протокола обмена будет проблематично. Не говоря о том, что смысл нового протокола должен быть в том, чтобы покрыть текущие и перспективные потребности рынка, а не в том, чтобы сразу городить поверх него костыли.
Короче, те же газовые счётчики по требованиям Газпрома не подключить. Электро-счётчики — аналогично. И вообще только очень небольшой класс устройств можно таким протоколом подключить.
И это преподносится, как универсальный супер-протокол.
А всего-то нужно было отказаться от неверного предположения об обязательном отсутствии часов реального времени у абонентских устройств и изучить реальные потребности самых массовых сегментов КОММЕРЧЕСКОГО рынка IoT-устройств. Вместо этого взяли какую-то узкую конкретную задачу, узкий класс устройств, отказались учитывать вектор развития IoT-устройств и сгородили крайне ограниченный и уже устаревший протокол.
Я прошу прощения, но это уже совсем другой OpenUNB. Старый вариант переработан полностью. Прошу подождать немного до публикации нового варианта. Эти статьи выходят немного заранее, чтобы к моменту публикации были готовы средства разработки. Я прошу посмотреть мои предыдущие публикации по этой теме, все станет ясно.
Было бы еще интересно посмотреть на PER. Бывает, что на BER наблюдается выигрыш ощутимый, однако на PER выигрыш значительно меньше.
BER выходит на полку или у этого кода такой проблемы нет?
А последний график? Зависимость вероятности потери пакета от ОСШб.
А, просто я не привык к такому графику, он у Вас в линейном масштабе и на нем не видно ошибки уровня 1e-2, 1e-3 и тд. Ну и интересна зависимость от EbN0.
И ещё проблема. Это неплохой алгоритм коррекции ошибок, но что-то мне подсказывает, что у вас в протоколе нет стойкой к искажениям синхронизации начала пакета. В реальной жизни будут довольно частые ошибки потери бита или, даже, вставки бита. особенно в преамбуле и самом начале пакета. Против них это кодирование не помогает же.
Можете конкретнее сказать, что вам подсказывает, что в протоколе нет стойкой синхронизации? В предыдущей статье есть описание поиска преамбулы, исходники поиска есть на Гитхибе. Вы имеете все исходные данные для доказательной критики. Прошу критиковать, это нам будет очень полезно.

Я не вижу причин для появления ошибок потери или вставки бита в системе OpenUNB. Поясните ваш тезис.
Нет времени пока исходники детально изучать, а описания протокола у вас так и нет ;)
Я лучше потом поизучаю описание протокола, когда и если оно будет.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.