Internet of things

Канальный уровень OpenUNB сильно отличается от всего, что мы видели. Так получилось из-за заложенной в OpenUNB возможности только односторонней передачи: от оконечного устройства к сети. Тем не менее, разработчики вложили много усилий в создание протокола канального уровня, чтобы устройства и сеть OpenUNB не потеряли простоту, энергоэффективность и безопасность. Давайте посмотрим, что у них получилось.

Так как канальный уровень OpenUNB довольно сложен, я решил разбить его на подсистемы и описывать их в отдельных статьях. Кстати, приведу список всех наших статей об OpenUNB:

• Интернет вещей по-русски. Минимализм и открытость OpenUNB
• Интернет вещей по-русски. Многоканальная мощь физуровня базовой станции OpenUNB
• Интернет вещей по-русски. Помехоустойчивое кодирование в OpenUNB

Сегодняшняя будет про канальный уровень OpenUNB в общем и в частности про принцип адресации устройств OpenUNB. Сегодня за бортом останется безопасность и активация в сети OpenUNB. Хотя принцип адресации завязан на процедуры безопасности OpenUNB, я решил описать его в отдельной статье, чтобы не ввергать читателя в пучину лонгрида. По прочтении всех статей по канальному уровню, у вас сложится представление.

Канальный уровень отвечает за механизм управления доступом устройств к радиоканалу (Media Access Control, MAC) и механизм управления логической связью (Logical Link Control, LLC) между устройствами и сервером сети.

Канальный уровень определяет:

1. механизм множественного доступа устройств к радиоканалу;
2. механизм повторных передач пакетов;
3. формат пакетов канального уровня и алгоритм их формирования;
4. схему адресации устройств;
5. процедуру активации (аутентификации и регистрации) устройств на сервере;
6. механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).

Сегодня мы рассмотрим первые четыре пункта списка.

Для обеспечения множественного доступа устройств к радиоканалу в сети используется неслотированная частотная ALOHA. Частота передачи каждого пакета должна выбираться устройством случайно из всей полосы рабочих частот приема шлюзов. В случае если передача пакета осуществляется с повторами, для каждой очередной передачи должна выбираться случайная частота отличная от частот, выбранных для предыдущих передач пакета.

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

Формат пакета OpenUNB по уровням:

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

В эти шесть байт входят адрес (DevAddr) и проверочное слово (MIC). Обе эти части имеют одинаковый размер (три байта) и простые, но тщательно отточенные разработчиками свойства.

Слово DevAddr это временный адрес устройства. В лирическом отступлении можно отметить, что мало можно найти протоколов IoT, в которые внедрена концепция временных адресов, хотя в сотовой связи она присутствует начиная со стандартов 2G. В OpenUNB временный адрес (меняется каждые 4 часа) формируется криптографически из базового ключа K0, привязанного к DevID, назначение которого имеет необыкновенную гибкость. Во-первых, DevID может не быть уникальным. Пользователь даже может назначить DevID случайным образом. Уникальность DevID придаст назначение соответствующего ему базового секретного ключа K0. Во-вторых, нет даже требований к длине DevID. Стандарт требует иметь его длину не менее 4 байт, но рекомендует длину 16 байт. В-третьих, такая гибкость приводит к возможности назначать DevID в разных сетях децентрализовано, не сверяясь друг с другом.

Если говорить точно, временный адрес DevAddr вырабатывается так:

где Ne номер эпохи (время), а Ka ключ активации, который получается так:

где Na номер активации, а K0 базовый секретный ключ.

Процедуры ECB и CTR здесь это криптопреобразования "режим простой замены" и "режим гаммирования", соответственно. Эти процедуры определены в стандартах шифрования ГОСТ.

Таким образом, если считать криптопреобразования стойкими, а ключ K0 секретным, связь между DevID и DevAddr экономически оправданным способом установить не получится. Поэтому третья сторона не может сопоставить пакеты в эфире с конкретным устройством IoT, не зная ключ K0. Какой еще протокол IoT может похвастаться таким удивительным свойством?!

Слово MIC, проверочное слово, уникально. Оно имеет по меньшей мере две ипостаси: это имитовставка и слово контроля целостности в одном лице. За счет этого двойного назначения получается немалая экономия в объеме данных, а значит и в энергии, потребляемой устройством. Есть еще третья функция MIC, скрытая от неискушенного читателя. Это конкретизация соответствия DevAddr и DevID. Очевидно, ввиду малости длины DevAddr, это поле не будет уникальным для всех DevID, по крайней мере это не гарантируется криптопреобразованиями. Но существует связь DevAddr и MIC, которая определяется секретным ключом K0 и другими параметрами. Если говорить точно, то чудо-слово MIC получается так:

где значение вектора P зависит от длины блока n и длины поля MACPayload. Пусть len
однобайтная целочисленная беззнаковая переменная, равная длине полезных данных
MACPayload в битах (переменная len может принимать значения 16 или 48), тогда:

если len = 48 и n = 64, то

в остальных случаях

Процедура CMAC24 здесь это криптопреобразование "режим выработки имитовставки" согласно ГОСТ.

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

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

Как обычно, теоретическая проработка у нас сразу вытекает в практику. Исходники криптопреобразований для оконечного устройства уже можно найти на Github.

Кстати, физический уровень нами уже сделан и сейчас проходит проверку на местности. Вы уже можете взять исходники передатчика оконечного устройства и приемника базовой станции и опробовать дальность работы самостоятельно. Для этого нужно минимальное железо. Заинтересованных прошу обращаться. Мы поможем консультацией первым энтузиастам. Наш бессменный программист deef137 всегда на связи.

Пока писалась эта статья, пришла отличная новость: стандарт опубликован на сайте Сколтеха. Теперь полная картина не ускользнет от вас.

Односторонний характер протокола OpenUNB накладывает отпечаток на все процедуры протокола. Разработчики OpenUNB, стремясь разработать защищенный протокол, создали на первый взгляд довольно сложную процедуру вхождения устройства в сеть активацию. Давайте разберем ее в деталях.

Чтобы сделать протокол защищенным, нужно разделять между двумя сторонами некоторую информацию, неизвестную третьим лицам. Это реализуется через разделения одинакового ключа. Для защиты от повторов этого недостаточно. Необходимо, чтобы эти две стороны разделяли еще некоторую информацию, которая даже не должна быть секретной, а может быть известна всем.

В обычных, двусторонних системах такая информация вставляется в передаваемый информационный пакет. Грубо говоря, пакеты нумеруются. В экономичных система передачи типа Интернета вещей такой метод расточителен. В таких системах выгоднее вести счетчики времени на двух сторонах отдельно, а не передавать его в пакете. В стремлении к совершенству, так и было сделано в OpenUNB.

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

В OpenUNB активация устройства производится пользователем. Также необходим доверенный канал между пользователем и сервером сети. Схема взаимодействия представлена ниже:

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

В стадии "запрос на активацию" пользователь должен по служебному каналу отправить на сервер запрос на активацию, в котором передается идентификатор DevID активируемого конечного устройства. Если активация возможна, то сервер сообщает об этом. Далее пользователь делает "запуск процедуры активации на устройстве". Это может быть пакет по радио-интерфейсу или другому, удобному. Это также может быть нажатие кнопки "активация" или просто включение питания устройства. После этого события устройство передает "служебный пакет активации", в котором содержится номер текущей активации.

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

Рассмотрим подробно процедуру со стороны устройства и со стороны сервера.

Со стороны устройства процедура выглядит так:

1. проверяется текущее значение счетчика активаций Na. Если счетчик активаций уже достиг максимально возможного значения, то данное устройство больше не может использоваться, и выключается;
2. увеличивается значение счетчика активаций: Na = Na + 1;
3. вырабатывается ключ активации Ka;
4. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
5. формируется служебный пакет активации, в поле MACPayload которого содержится текущее значение счетчика активаций Na, а в качестве адреса указывается DevAddr0 = CRC24(DevID). При этом поле MACPayload передается в открытом виде (не шифруется), а поле имитовставки MIC рассчитывается на ключе Km для номера Nn = 0. Сформированный служебный пакет активации должен быть отправлен MAX_PKT_TX_NUM раз подряд для повышения вероятности его доведения;
6. устройство считает активацию успешно завершенной и может передавать пакеты полезных данных.

Напомним формат пакета OpenUNB:

Сервер по приему пакета активации ищет адрес из пакета в списке адресов активированных устройств. Для каждого из найденных совпадений:

1. сохраняется полученное значение счетчика активаций устройства Na. Если для данного устройства ранее уже осуществлялась успешная активация, то сервер должен дополнительно проверить, что текущее значение Na больше чем значение Na, полученное при предыдущей успешной активации. Если эта проверка завершается неуспешно, то сервер переходит к следующему найденному устройству;
2. вырабатывается ключ активации Ka;
3. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
4. для пакета проверяется совпадение имитовставки MIC на ключе Km для номера Nn = 0.

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

Детали работы процедур активации OpenUNB смотрите в первоисточнике на сайте Сколтеха.

Реализованные процедуры активации и другие процедуры безопасности доступны в исходниках здесь.

Наш бессменный мастер Интернета вещей deef137 всегда на связи и готов помочь с вопросами по коду.

В настоящее время в эпоху развитого интернета мы настолько привыкли к хорошей информационной безопасности протоколов передачи информации, что тема создания новых протоколов несколько ушла в тень. Зачем что-то еще изобретать? Просто выбери из имеющихся. Но Интернет вещей поднимает эту тему заново.

Для иллюстрации актуальности я приведу в пример протокол CRISP, кстати, отечественной разработки. Наличие такой разработки, доведенной уже до статуса методических рекомендаций Технического комитета по стандартизации "Криптографическая защита информации", подтверждает практическую непригодность обычных "тяжелых" протоколов безопасности для Интернета вещей. Они оказываются слишком ресурсоемкими.

Различных радио-протоколов Интернета вещей сейчас наплодилось огромное множество, но в сфере LPWAN не везде разработчики протокола передачи берут на себя тяжелую ношу защиты информации. Можно долго спорить, нужно ли вообще включать защиту в радио-протокол LPWAN, а не перекладывать ее на вышележащие уровни, но если предложенная схема хороша, то стоит надеяться на большую вероятность внедрения стандарта в индустрию. Главный тезис: вообще без защиты в Интернете вещей сейчас уже нельзя. И она должна быть на уровне.

Так же рассуждали и разработчики OpenUNB, ставя во главу угла энергоэффективность и встроенную безопасность информации. Тем, кто еще ничего не знает про OpenUNB, я советую прочитать предыдущие статьи на эту тему:

• Интернет вещей по-русски. Минимализм и открытость OpenUNB
• Интернет вещей по-русски. Многоканальная мощь физуровня базовой станции OpenUNB
• Интернет вещей по-русски. Помехоустойчивое кодирование в OpenUNB
• Интернет вещей по-русски. Канальный уровень OpenUNB. Общие положения и адресация устройств
• Интернет вещей по-русски. Процедура активации OpenUNB

а также изучить первоисточник на сайте Сколтеха.

Сегодня мы рассмотрим механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).

Чтобы обеспечить базу безопасности, у каждого устройства и сервера должно быть что-то общее, секретное, которое никто не знает. В OpenUNB это секретный ключ шифрования K0, имеющий длину k, равную 128 или 256 бит. Весь остальной протокол должен быть сделан так, чтобы этот базовый, основной ключ не стал бы известен никому никаким образом, а информация при этом была защищена. Поэтому базовый ключ претерпевает такое множество преобразований в своем стремлении встретиться с информацией.

Ключ K0 используется только для формирования (порождения) рабочих ключей, которые непосредственно используются в процедуре криптографической защиты данных. (Чтобы лучше понимать последующее повествование, прочитайте статьи о канальном уровне: первую и вторую). Хотя, я думаю, специалисту по безопасности все должно быть понятно и так.

В недрах устройства и сервера OpenUNB есть счетчик активаций Na и счетчик эпох Ne, которые остаются примерно одинаковыми в процессе работы системы. Сначала вырабатывается ключ активации:

Потом уже по ключу активации вырабатываются рабочие ключ шифрования Km и ключ имитозащиты Ke:

Для криптографических преобразований разработчики OpenUNB рекомендуется использовать блочный шифр Магма, который имеет длину блока n = 64 бита и длину ключа k = 256 бит, определенный в стандарте ГОСТ Р 34.12-2015.

Шифрование выглядит так:

где Nn номер пакета, а выработка имитовставки так:

где значение вектора P зависит от длины блока n и длины поля MACPayload. Пусть len
однобайтная целочисленная беззнаковая переменная, равная длине полезных данных
MACPayload в битах (переменная len может принимать значения 16 или 48), тогда:

если len = 48 и n = 64, то

в остальных случаях

Процедура CMAC24 здесь это криптопреобразование "режим выработки имитовставки" согласно ГОСТ.

Далее эти поля вставляются на свои места. Напомним схему формирования пакета:

Более подробно, со всеми деталями, вы можете прочитать о безопасности в OpenUNB в первоисточнике.

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

Как всегда, исходники крипто-преобразований от deef137 доступны на Github.

Не так давно мы с командой разработали небольшой встраиваемый компьютер для решения задач IIoT и промышленной автоматизации. Первую статью о нашем устройстве можно посмотреть здесь.

Разрабатывать устройство решили на распространенном и оттестированном модуле Raspberry CM3+, что позволило нам создать компьютер с большими вычислительными способностями, огромным сообществом и простотой его использования. Под катом расскажу по этапам, от чего отталкивались и к чему пришли в итоге.

Муки выбора корпуса

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

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


Рисунок 1 Первый вариант корпуса

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

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


Рисунок 2 Пластиковые крышки корпуса

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


Рисунок 3 Металлический корпус

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


Рисунок 4 Гравировка металлического корпус

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

В итоге мы пришли к шелкографии с запеканием в печи (рисунок 5). Эта технология оказалась самой быстрой и очень крепкой. Всё свелось к тому, чтобы заказать единожды шаблон (фотовывод) и по нему делать партию до 50 штук в день.


Рисунок 5 Шелкография корпуса

Исправление недоработок

С корпусом закончили, а вот с платой оставались недоработки. Задумка нашего компьютера в том, чтобы любой пользователь мог спокойно установить дополнительное оборудование в устройство, открутив четыре болта на корпусе, как в свой ноутбук. Я думаю прошли те времена, когда на корпуса клеили наклеечки Не вскрывать, потеря гарантии.

Внутри корпуса есть периферия для прошивки вычислительного модуля, SIM-карта и многое другое. Однако была одна проблема с монтажом платы в корпус, а именно выводные светодиоды на ножках, которые постоянно гнулись у наших клиентов, взявших прототипы на тест (рисунок 6).


Рисунок 6 Выводные светодиоды на ножках

В этой связи пришлось поменять диоды на ножках на SMD-светодиоды, которые светят в бок и проблема с установкой платы в корпус решилась, больше ничего не гнулось (рисунок 7).


Рисунок 7 SMD-светодиоды

Индикация была глубоко внутри корпуса и чтобы увидеть свет приходилось смотреть под прямым углом на торец. В голову пришла идея световодов из полимерных прозрачных материалов (рисунок 8). Оставалось найти бюджетный, но эстетически красивый вариант. В голову пришел молочный плексиглас с прозрачностью 20% с толщиной листа 3 мм, в первой же фирме лазерной резки подобрали диаметр миниатюрного цилиндра, он был равен диаметру отверстия в корпусе. Особенность в том, что станок при лазерной резке дает небольшой скос нижнего диаметра на 0.1 мм и таким образом мы получили мешок миниатюрных усеченных конусов с нижним диаметром 2,9 мм и верхним 3 мм, а высота была 3 мм как и толщина торцов нашего корпуса. Вставляем конус в отверстие и запрессовка крепко загоняет эти световоды в отверстие, а небольшая капелька клея с обратной стороны фиксирует их намертво.


Рисунок 8 Световоды из плексигласа

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

Итог

Спасибо за внимание! Надеемся, что мы вдохновим читателей на переработку Ваших личных проектов в более масштабное производство с коммерческими перспективами. В нашей великой стране на полочках у инициаторов пылятся действительно нужные вещи, которые могут заменять зарубежные производства.

В следующей статье мы расскажем Вам историю тестирования и тонкости настройки mPCIe 3G-модема Huawei и mPCIe LoraWan-модуля MikroTik.

В сфере промышленной автоматизации существует негласная парадигма, в которой многие производители промышленного оборудования делают контроллеры отдельно, а модемы отдельно. Как правило, каждое устройство помещается в свой корпус, имеет своё питание, большие габариты и высокую стоимость. Такой вариант разделения функционала имеет свои преимущества и недостатки, но, по нашему мнению, он ведет, скорее, к бльшей коммерциализации, чем обусловлен какими-то объективными причинами. Поэтому мы решили пойти немного по другому пути и сделали универсальное устройство, которое представляет из себя свободно программируемый контроллер на базе Linux с модемом в едином корпусе. Это нам позволило в своих проектах практически совсем отказаться от привычных всем щитов автоматизации и прийти к более мобильным решениям.

Под катом этой статьи мы поделимся с Вами тонкостями настройки модема и несколькими полезными скриптами для более стабильного 3G-соединения.

Предпосылки и решения

При разработке своего устройства мы руководствовались тем, что оно должно выходить в мобильный интернет, чтобы подключаться к облачным платформам. Было два пути: напаивать модем на плату, либо использовать mPCIe-разъемы. Мы остановились на втором варианте и предусмотрели сразу два mPCIe-разъема (рисунок 1), поскольку такой вариант нам показался более интересным и гибким. Ведь установка и замена модема занимает считанные секунды, плюс для пользователя появляется необходимая вариативность и он может использовать такие комбинации mPCIe-модулей, которые ему необходимы под конкретный проект. Кроме 3G-модема это может быть LoraWan или Wi-Fi модули. Плюс ко всему mPCIe-решения зарекомендовали себя как достаточно надежные и качественные.


Рисунок 1 mPCIe-разъемы

В качестве основного 3G-модуля для нашего устройства мы рассматривали следующие варианты:

• MikroTik R11e-LTE6
• Quectel EC25-E
• YUGA CLM920 TE5
• HUAWEI MU709s-2p

Однако после проведения тестов наиболее предпочтительным для нас в плане надежности и соотношения цена-качество оказался модем фирмы HUAWEI (рисунок 2). Мы взяли его за основу и устанавливаем опционально в наши устройства. Поэтому в дальнейшем мы будем рассматривать настройку и скрипты относительного модема этой модели. Возможно, этот скрипт будет универсальным и будет полезен для других модемов, однако стабильность работы с другими моделями не гарантируется. Для Rasbian Buster и HUAWEI MU709s-2p всё работает отлично.


Рисунок 2 Модем HUAWEI MU709s-2p, установленный на плату устройства

Использование скрипта для перезагрузки 3G-модема

Для более устойчивой и безотказной работы мы написали скрипт, который будет пинговать заданный IP-адрес, а если же определенное в настройках количество пингов не прошло, то GSM-модем перезагрузится, тем самым восстанавливая зависшее сетевое соединение. Стоит отметить, что модем определяется в системе как сетевая карта lan1.

Архив со всеми необходимыми файлами можно скачать по этой ссылке. Также текст самих скриптов представим ниже.

Файл check_inet.sh необходим для проверки наличия интернет соединения. Если заданный IP-адрес не пингуется, то мы дергаем 19 ногу и перезапускаем модем по питанию. Код из себя представляет следующий вид:

#!/bin/bash#count=0;#echo "Start script"#echo 19 > '/sys/class/gpio/export'while [ true ]; do# sleep 30. /home/pi/igate.conf#echo $usb_port#echo 'AT^NDISDUP=1,1,''"'$apn'"''\r\n' #echo 'AT^NDISDUP=1,1,"internet.mts.ru"\r\n' flag=0for ((i = 1; i <= $ping_count; i++)); do#for i in {1..$ping_count}; do #делаем 5 пингов до сервера#ping -I eth1 -c 1 8.8.8.8 > /dev/null || flag=$(($flag+1))ping -I $interface -c 1 $ping_ip || flag=$(($flag+1))sleep 1doneif [ "$flag" -ge "$ping_error" ]; then #если потерь пакетов больше 3х#echo "рестарт модема - начало"#count=$((count+1))#echo $count#рестарт модемаsudo ifconfig eth1 downecho 19 > '/sys/class/gpio/export'echo out > '/sys/class/gpio/gpio19/direction'echo 0 > '/sys/class/gpio/gpio19/value'sleep 1echo 1 > '/sys/class/gpio/gpio19/value'sleep 15sudo ifconfig eth1 upsleep 1#echo -en 'AT^NDISDUP=1,1,"internet.mts.ru"\r\n' > /dev/ttyUSB3#АТ команда для записи настроек точки доступа APNecho -en 'AT^NDISDUP=1,1,''"'$apn'"''\r\n' > $usb_port#echo "рестарт модема - конец"fisleep $timeoutdone 

Файл start_inet.sh запускает check_inet.sh после перезагрузки устройства:

#!/bin/bash### BEGIN INIT INFO# Provides:          start_inet# Required-Start:    $remote_fs $syslog# Required-Stop:     $remote_fs $syslog# Default-Start:     2 3 4 5# Default-Stop:      0 1 6# Short-Description: Example initscript# Description:       This service is used to manage a servo### END INIT INFOcase "$1" in     start)        echo "Starting check_inet"        sudo /home/pi/check_inet.sh > /dev/null 2>&1 &        #/home/pi/check_inet.sh        ;;    stop)        echo "Stopping check_inet"        #killall servod        sudo kill -USR1 $(ps ax | grep 'check_inet' | awk '{print $1}')        ;;    *)        echo "Usage: /etc/init.d/check_inet start|stop"        exit 1        ;;esacexit 0

Также в архиве находится файл конфигурации igate.conf

Последовательность настройки:
1. Добавьте правило соответствия физического подключения COM-порта модема к концентратору USB. Для этого поправьте файл по следующему пути:

sudo nano /etc/udev/rules.d/99-com.rules

2. Добавьте в файл следующую строку:

KERNEL==ttyUSB*, KERNELS==1-1.5:2.4, SYMLINK+=GSM

3. Сохраните правила и перезагрузите устройство. Теперь порт Вашего модема будут определять по удобному псевдониму /dev/GSM;
4. Скачайте архив по предложенной выше ссылки, либо самостоятельно создайте файлы check_inet.sh, start_inet.sh и igate.conf;
5. Скопируйте файл check_inet.sh в папку:

/home/pi/

6. Сделайте файл check_inet.sh исполняемым:

sudo chmod +x /home/pi/check_inet.sh

7. Скопируйте файл start_inet.sh в папку:

/etc/init.d/

8. Сделайте файл start_inet.sh исполняемым:

sudo chmod +x /etc/init.d/start_inet.sh

9. Обновите конфигурацию автозагрузки выполнив команду:

sudo update-rc.d start_inet.sh defaults

10. Скопируйте файл igate.conf в папку:

/home/pi/

11. Настройте файл конфигурации. Ниже представлен файл конфигурации с комментариями:

#ip-адрес пинга. Скрипт будет пытаться пинговать этот ip-адрес, если определенное в параметре [ping_error] количество пингов не прошло, скрипт будет перезагружать GSM-модем, тем самым восстанавливая зависшее сетевое соединение.ping_ip=8.8.8.8#точка доступа APN. Это адрес точки доступа Вашего интернет-провайдера, он выдается вместе с сим-картой.apn=internet.mts.ru#период проверки соединения 3G (период пинга). Период выполнения скрипта. Каждые 30 секунд будет осуществляться проверка пингов.timeout=30#количество пингов. Общее количество пингов.ping_count=5#количество неуспешных пингов для рестарта модема. Количество неуспешных пингов, после которых необходимо выполнять перезагрузку модема. Не может быть больше чем [ping_count]. Процент потерянных пакетов нужно подбирать индивидуально в зависимости от качества покрытия сети.ping_error=3#LAN интерфейс модема. Сетевой интерфейс модема, обычно на устройстве AntexGate определяется как [eth1], посмотреть название можно выполнив команду ifconfiginterface=eth1#USB порт модема. Физический USB порт к которому подключена сетевая карта, обычно на устройстве AntexGate определяется как [ttyUSB4]usb_port=/dev/GSM

Управление скриптом

Запуск в фоновом режиме файла скрипта check_inet.sh:

/etc/init.d/start_inet.sh start

Остановить check_inet.sh:

/etc/init.d/start_inet.sh stop

Скрипт также автоматически запускается после перезагрузки устройства.

Варианты применения устройства

Рассмотрим основные задачи, под которые можно использовать устройство:

1. Контроллер с выходом в интернет для передачи данных в облако;
2. 3G-роутер для задач в поле;
3. Контроллер для умного дома с резервирующим каналом 3G. То есть можно использовать LAN-порт как основной канал связи, а 3G в качестве резервного, чтобы всегда был доступ к устройству;
4. Базовая станция LoRaWAN, то есть опрос устройств по LoRaWAN и передача данных в облако через сеть 3G или LTE;
5. Устройство для мониторинга транспорта (подключение по CAN и стыковка с различными сервисами)

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

OpenUNB продолжаем! И так, мы сформировали сигнал OpenUNB согласно проекту стандарта (исходники на Гитхабе). Сигнал вылетел в эфир, показав нам свои прелести на приборе. Теперь нам нужно его конвертировать в цифровую форму, отделить от других возможных сигналов и от шума и определить по частоте и по времени. В полосе ни много, ни мало, а 1000 каналов. Чудеса цифровой обработки сигналов! И вы удивитесь, на каком простом железе их можно совершить.

Напомню, OpenUNB предполагает односторонню связь. (Кстати, согласно опросу, около 40 процентов проголосовавших с таким подходом согласны.) То есть, базовая станция (БС) простой приемник. Это сильно упрощает нам жизнь для реализации минимального набора OpenUNB нам не нужны дорогие SDR и средства обработки. Нам достаточно грошёвого RTL-SDR и компьютера типа Raspberry.

Так вот, берем в руки сладкую парочку: RTL-SDR и Raspberry. Берем также голову в руки и пишем код приемника. Приемник должен обнаруживать все пакеты соответствующего формата в полосе OpenUNB, демодулировать их, декодировать и проверять на ошибки. На этом формально работа физического уровня OpenUNB заканчивается. Сегодня мы уделим внимание первым двум этапам обработки: обнаружение и демодуляция пакетов OpenUNB.

В полосе OpenUNB 1000 номинальных каналов в полосе 100 кГц. (Правда, дальше мы увидим, что на практике приходится нарезать по меньшей мере вдвое больше каналов.) Пакет излучается на одном частотном канале с модуляцией DBPSK с частотой 100 Гц. Мы не будем делать прием только одного канала, это никому не нужно. Во-первый, в стандарте заложена возможность повторов на разных частотах для улучшения чувствительности. Во-вторых, неточность опорных генераторов оконечных устройств (ОУ) в диапазоне температур их работы все равно приводит к миграции частоты передачи в пределах нескольких частотных каналов на приеме БС.

Придет время, и устройств интернета вещей должно быть много, поэтому БС нового стандарта должна проектироваться так, чтобы принимать сразу множество датчиков. Поэтому мы сразу делаем обнаружение во всей полосе. Для начала нужно разделить полосу приема 100 кГц на элементарные полосы, соответствующие полосе сигнала. Теоретически, полоса сигнала 100 Гц. Давайте это проверим по спектру излучаемого сигнала.

Мы видим, что в реальности полоса чуть меньше.

Исходя их этих измерений, задаем требования к амплитудно-частотной характеристике (АЧХ) фильтра основной избирательности (ФОС) и рассчитываем его импульсную характеристику (ИХ). Получается 12500 коэффициентов ИХ с АЧХ следующего вида.

На самом деле, при задании требований к АЧХ ФОС в такой многоканальном системе должен разрешаться очень серьезный компромис. С одной стороны, мы не должны уменьшить энергию полезного сигнала, должны держать полосу ФОС достаточно широкой, чтобы основная часть энергии попала в фильтр. С другой, мы должны уменьшить мешающее влияние других сигналов, делая границу полосы задержания как можно меньше. Эта тема может быть предметом даже не инженерных, а научных изысканий. Стандарты на системы передачи иногда задают маску АЧХ приемника, чтобы инженеры не занимались наукой. Мы сейчас остановимся на том, что есть, оставив эту оптимизацию напотом, еще и потому, что дальше вы увидите, что эту полосу нужно будет немного увеличить по другим соображениям.

С точки зоения вычислительной эффективности (не забывайте, мы хотим уложиться в очень недорогое железо и должны экономить), расфильтровывать полосу приема нужно "быстрыми" методами. Нужно делать так называемую гребенку фильтров с помощью быстрого преобразования Фурье (БПФ). Здесь я только приведу схему обработки, а подробности вы сможете посмотреть в Интернете или в моей статье на эту тему.

Пусть мы определились с частотой отсчетов на выходе гребенки, она соответствуюет символьной скорости 100 Гц. Теперь нам нужно определить сетку частот гребенки фильтров. Если бы оконечные устройства излучали сигнал с точной настройкой, то мы должны были бы делать гребенку с частотным шагом 100 Гц. Так как частота сигналов ОУ мигрирует на величину более одного канала, то мы обязаны считать, что частота на приеме будет любой. Тогда требование к сетке частот будет устанавливать следующий блок в тракте приема обнаружитель пакетов.

Здесь следует оговориться, что вариантов обнаружителя пакетов может быть много, с разной степенью практичности для реализации в столь слабом железе. Мы готовы поддержать дискуссию и изменить алгоритм, если вы найдете другой, более экономичный вычислительно и/или более помехоустойчивый. Мало того, вы можете форкнуть код приемника на Гитхабе и реализовать и протестировать его сами (благо железо недорого и может даже оказаться у вас под рукой) и всем потом рассказать. Это будет реально круто! Только не забывайте держать код открытым, это же OpenUNB.

Рассмотрим практически приемлемый вариант обнаружителя пакетов. Исходя из опыта нескольких разработок в области UNB, экономичным методом реализации обнаружителя пакетов является обнаружитель на жестких решениях. И мы на этом этапе не будем изобретать велосипед. Цель обнаружителя: находить преамбулы одновременно во всей полосе приема. Длина преамбулы 32 бита. Поиск преамбулы происходит по выходу относительно-фазового дискриминатора, работающего по каждому выходу гребенки фильтров. Например, если шаг гребенки у нас будет 50 Гц, а частота отсчетов с гребенки 100 Гц, то в секунду будет 200000 (двести тысяч) проверок на преамбулу. Напомню, что шаг гребенки мы еще только хотим определить, исходя из характеристик работа обнаружителя.

Прикидка показывает, что в таком варианте качество работы обнаружителя не будет сильно страдать при отстройке сигнала от центра фильтра на 25(?) Гц. Эта прикидка была проверена на практике. Теперь мы можем считать достаточной сетку гребенки 50 Гц. Только полосу пропускания ФОС нам нужно также увеличить на 25 Гц, чтобы не терять энергию сигнала при максимальных отстройках. Все, с расфильтровкой покончено.

Код умножения на ИХ выглядит так:

for (unsigned int ch=0; ch < numOfChannels; ch++) {            float iC = 0.0;            float qC = 0.0;            for (int j=0; j < BL_125K_to_100/numOfChannels; j++) {                iC += dataIn[i + ch + j*numOfChannels][0] * B_125K_to_100[ch + j*numOfChannels];                qC += dataIn[i + ch + j*numOfChannels][1] * B_125K_to_100[ch + j*numOfChannels];            }            fftw_in[ch][0] = iC;            fftw_in[ch][1] = qC;        }

БПФ используется библиотечное:

fftwf_execute(fftw_p);

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

Код обнаружителя:

        corr1[ch] = q1[ch]*q2[ch] + i1[ch]*i2[ch];        corr[ch] = (corr[ch] >> 1) | ((corr1[ch] > 0 ? 1:0) << 31);        const uint32_t prea = 0x97157A6F;        int err1 =  bitDif(corr[ch], prea);

Следует опять отметить, что все эти эмпирически принятые решения могут быть вами обоснованно оспорены. Мы будем внимательно прислушиваться и воплощать в код все самые лучшие модификации. В этом и состоит большая часть смысла открытости OpenUNB.

После обнаружения преамбулы считается, что есть некоторая вероятность, что в данное время в данном частотном канале был принят пакет. Чтобы подтвердить или опровергнуть эту гипотезу, нужный отрезок сигнала проходит процедуру демодуляции в мягкие решения, которые поступают на вход декодеру корректирующего кода и далее на блок проверки контрольной суммы пакета. Если контрольная сумма пакета сошлась, гипотеза о приеме пакета считается истинной и пакет отправляется на криптографическую обработку.

Формирование мягких решений о символах пока сделано упрощенно:

std::vector<float> data;for (int i=1; i< pp->data.size(); i++) {     float corr;     corr = pp->data[i - 1].real() * pp->data[i].real() + pp->data[i - 1].imag() * pp->data[i].imag();}

На этом обнаружитель пакетов и демодулятор заказчиваются.

Подведем итог. Мы вчерне прикинули и проверили на практике технические решения по первичному приему OpenUNB на простом железе. Гребенка должна быть с шагом 50 Гц, фильтр основной избирательности должен иметь полосу пропускания 100 Гц. Код обнаружителя пакетов реализован, проверен на столе в работе в том числе и с малыми SNR и находится в Гитхабе. Проверка на местности еще впереди.

Обоснование выбора корректирующего ошибки кода и описание его реализации будет приведено в следующей статье.

Хочется выразить огромную благодарность за проделанную работу нашему основному программисту deef137. На все вопросы по коду ответит он. По обработке сигналов спрашивайте меня.

Доступ к среде (MAC, Media Access Control) в OpenUNB очень прост случаен и асинхронен. Этот вид доступа еще называют асинхронная ALOHA. Даже WiFi может похвастаться более сложным вариантом MAC. За счет этого упрощения оконечные устройства OpenUNB могут сильно экономить в потребляемой энергии и стоимости оборудования. Но такой способ доступа к среде приводит к ошибкам при передаче, которые чаще происходят группами. Поэтому, хотя и не только поэтому, помехоустойчивому кодированию в OpenUNB уделено достаточно много внимания.

В настоящее время примером качественно спроектированных систем радиосвязи являются стандарты сотовой связи. Этот факт доказывается колоссальным прогрессом в способах передачи информации по радио, изменившим всю нашу жизнь. Детали реализации стандартов сотовой связи даже используются в профильных университетах, как условия задач. Создатели OpenUNB также не стали изобретать чего-то нового в смысле помехоустойчивого кодирования, а взяли пример со стандарта Интернета вещей от 3GPP NB-IoT. Там при передаче в сторону базовой станции применяется полярное кодирование.

К слову, на Хабре есть отличные статьи по помехоустойчивому кодированию вообще и по кодированию LDPC в частности. Тем, кто путается в терминах и базовых понятиях, будет полезно их прочитать.

В настоящее время особую популярность набирает новый вид помехоустойчивых кодов, называемых полярными кодами. Как было доказано в [1], предложенные Ариканом полярные коды способны асимптотически достигать границы Шенона. Данное преимущество позволяет использовать полярные коды в современных телекоммуникационных системах мобильной связи. За довольно короткое время развития полярных кодов было предложено множество алгоритмов декодирования. Идея традиционного алгоритма декодирования [1] для полярных кодов заключается в последовательной оценке информационных бит. Таким образом, если на каком то шаге декодирования происходит ошибка, то и оценка всех остальных бит тоже будет ошибочной. Такой алгоритм декодирования известен, как алгоритм последовательного исключения (ПИ). Одним из способов преодоления зависимости от оценок предшествующих бит является использование списочного алгоритма Тала-Варди.

В настоящей статье рассматривается списочный алгоритм Тала Варди, предложенный в [2] для декодирования полярных кодов, который существенно уменьшает вероятность ошибки декодирование и позволяет реализовать декодирование почти по максимуму правдоподобия уже для небольшого размера списка (L = 16).

Основная идея, лежащая в основе алгоритмов кодирования и декодирования полярных кодов поляризация канала. Поляризацией канала является операция преобразования канала связи в N независимых его копий, в которых вероятность ошибки при передаче данных стремится к 0, или к 1. Каналы с единичной вероятностью ошибки будем называть замороженными. Таким образом появляется возможность эффективного использования канала связи и передачу сообщений через множество каналов, обладающих низкой вероятностью ошибки. Полярные коды строятся на основе использования матрицы вида:

Матрица G называют ядром Арикана, а через m обозначают ее кронекеровскую степень. Формально алгоритм кодирования полярного кода состоит из двух основных этапов, а именно: формирования кодовой последовательности и умножения на матрицу Арикана. Под формированием кодового слова понимается вставка информационных бит в незамороженные позиции кодовой последовательности, и дальнейшее умножение этой последовательности на матрицу Арикана. Степень матрицы соотносится с длинной кодовой последовательности как N = 2^m.

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

Для начала давайте проверим идею, что полярные коды действительно так хороши для нашего случая. Для этого сравним их с обычными конкурентами: БЧХ, Рида-Соломона, Голея. (Здесь следует заметить, что полярный код чувствителен к виду модуляции и что он особенно хорош именно при DBPSK.) Проведем имитационное моделирование в Matlab вероятности битовой ошибки в зависимости от отношения сигнал-шум на бит (ОСШб) указанных кодов с примерно одинаковыми скоростями. Результаты моделирования приведены на рисунке. По графикам видно, что даже в области малых значений ОСШб полярный код немного, но лидирует.

Выигрыш в 1 дБ или меньше может показаться мелочью, не достойной усилий. Но подумайте о радиоинженере, которому вы предложите уменьшить коэффициент шума уже вылизанного до предела приемника на 1 дБ, чтобы догнать конкурентов. Или подумайте о создателе сети IoT, которому нужно будет ставить базовые станции на 10 процентов чаще, чем конкурентам.

Следует отметить, что при более больших ОСШб разрыв полярного кода от конкурентов увеличивается. При ОСШб около 7.5 дБ вероятности ошибок уже отличаются на порядок, что будет приводить к значительно меньшим потерям пакетов.

Перейдем в практическую плоскость. Кодер полярного кода реализован в микроконтроллере, исходники здесь. В OpenUNB есть два варианта размера информационного блока: 64 и 96. Согласно алгоритму кодирования полярным кодом, необходимо сформировать промежуточную кодовую последовательность, которая будет содержать биты информационного блока в известных информационных позициях, а биты во всех замороженных позициях будут равны нулю. Код алгоритма представлен ниже:

int n_polar = _frozen_indicator.size();std::vector<uint8_t> iwd_s(n_polar);std::vector<int> inf_idx;std::vector<uint8_t> u(n_polar);for (int i = 0, j = 0; i < iwd_s.size(); i++) {    if (_frozen_indicator[i] == 0) {        iwd_s[i] = _iwd[j++];        inf_idx.push_back(i + 1);    }    else {        iwd_s[i] = 0;    }    u[i] = 0;}

Результатом работы данного алгоритма является промежуточное кодовая последовательность размером 128 или 196 бит, соответственно. Далее для того, что бы умножить промежуточную кодовую последовательность на матрицу Арикана, необходимо дополнить промежуточную кодовую последовательность нуля до целой степени двойки. Умножение на матрицу Арикана осуществляется с помощью функции, приведенной ниже:

return solve_recursively_prep(inf_idx, u, iwd_s, n_polar);

Декодер реализован в приложении на Raspberry. Декодер получает от демодулятора DBSPK мягкие решения и реализует алгоритм декодирования Тала Варди.

Основная идея списочного алгоритма декодирования состоит в том, чтобы обрабатывать сразу блок из не более чем L символов за одну итерацию алгоритма. То есть задача декодирования сводится к построению кодового дерева, где на каждой итерации вычисляется значение метрики пути, и строится не более чем L наиболее вероятных продолжений этого пути. В качестве примера приведем кодовое дерево (4,3), где 3 число информационных бит.

На рисунке, приведенном выше, сплошными линиями обозначены наиболее вероятные пути, причем количество этих путей определяется размером списка L.

По окончанию декодирования результатом будет являться список из L кодовых слов. Более того, было замечено, что правильное кодовое слово практически всегда присутствует в списке, формируемом этим алгоритмом. В связи с этим будем добавлять к данным, кодируемым полярным кодом, контрольную сумму CRC, значение которой можно использовать для выбора из списка решения задачи декодирования. В случае если несколько кодовых слов прошли проверку CRC, то решение принимается в пользу, того кодового слова, для которого значение модуля метрики будет минимальным.

Декодер:

std::vector<std::vector<float>> prob;std::vector<std::vector<uint8_t>> dec = pcscl_prep(8, 16, llr, &prob, info_bit_pattern_96);dec = polar_transform_noperm(dec);dec = extract_with_filter(dec, crc_mask_96, num_of_nonzero_bits_96 - short_96);std::vector<uint8_t> crc_err;crc_err = crc_ok_array(0x327, dec);

Чтобы проверить соответствие реализации полярного кода идее, проводим натурное моделирование. Для этого создаем на столе такой стенд: подключаем RTL-SDR к Raspberry, включаем запись с эфира, запускаем передатчик и через аттенюатор записываем сигнал в файл. В софте читаем сигнал из файла, делаем измерение ОСШ и подмешивание к принимаемому сигналу шума. Далее запускаем процесс сбора статистики и уходим спать. По приходу мы имеем в распоряжении такой график:

График с точностью до погрешностей совпадает с графиком из модели в Matlab.

Попутно получаем график вероятности потери пакета в зависимости от ОСШ:

.

Последний график внушает оптимизм, зовет нас на местность, на улицу, пройтись с передатчиком, чтобы почувствовать мощь физического уровня OpenUNB.

P.S.

Хочется выразить благодарность нашему бессменному программисту deef137 и примкнувшему в нам специалисту по помехоустойчивому кодированию RadioTech34.

[1] Arikan E. Channel polarization: A method for constructing capacity achieving codes for symmetric binary-input memoryless channels // IEEE Transactions on Information Theory. 2009. July. Vol.55, no. 7. P. 30513073.
[2] Tal I., Vardy A. List decoding of polar codes // Proceedings of IEEE International Symposium on Information Theory. 2011. P. 15.