Интернет вещей по-русски. Минимализм и открытость OpenUNB

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


    Меня с моим товарищем по оружию — deef137 — пригласили принять участие в работе Сколтеха по созданию отладочных средств для создаваемого стандарта низкоскоростной передачи по радио OpenUNB. Цель работы — обеспечить быстрое освоение технологии OpenUNB широкими массами инженеров.


    На заре своей инженерной карьеры я участвовал в разработке КВ-радиомодема. Из-за многолучевого распространения радиоволн, радиомодемы этого диапазона обычно не достигают скорости даже 10 кбит/с. Моя любовь к низкоскоростным радио-модемам происходит из воспоминаний о тех прекрасных и трудных временах.


    В списке моих статей вы найдете много про технологии цифрового радио (SDR). Интернету вещей посвящены три статьи:



    Эта статья носит дискуссионный, "теоретический" характер. При этом, мы больше не теоретики, а практики: кое-что по реализации отладочных средств уже сделано. Есть некоторый опорный код для оконечного устройства на Github и сигнал с выхода передатчика во временном и частотном представлениях.


    image


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


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


    Основными, отличительными параметрами всех LPWAN систем являются


    • низкая стоимость оконечного устройства (ОУ);
    • большая площадь покрытия (дальность) при низкой стоимости шлюза — определяет стоимость развертывания и эксплуатации сети;
    • большая пропускная способность шлюза – определяет стоимость сети с большой плотностью КУ;
    • большое время работы ОУ от одной батарейки (энергоэффективность) – ключевой параметр LPWAN систем, определяет стоимость обслуживания КУ;
    • надежность и безопасность доставки информации – обязательное условие функционирования системы;
    • открытость системы – определяет надежность инвестиций в технологию, исключает монополию производителя.

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


    В настоящее время, на рынке присутствует множество LPWAN систем, наиболее распространенными из них являются LoRaWAN, SigFox и NB-IoT. Анализ технических характеристик этих систем показывает, что каждая из них имеет определенные недостатки в задачах сбора информации с датчиков. С целью краткости изложения, эти недостатки будут описываться вместе с достоинствами OpenUNB.


    Низкая стоимость оконечного устройства


    Протокол OpenUNB спроектирован так, чтобы в оконечных устройствах можно использовать разнообразные и массовые радио чипы ведущих мировых производителей. Поэтому, по цене оконечного устройства OpenUNB потенциально не дороже SigFox, дешевле LoRaWAN, так как там используется уникальный не очень дешевый чип компании Semtech, и сильно дешевле NB-IoT в которых используются гораздо более сложные и дорогие чипы.


    Низкая стоимость шлюза


    Приемник шлюза OpenUNB реализован на основных принципах цифрового радио (SDR) с использованием современных методов цифровой обработки сигналов. В приемнике используются доступные компоненты от ведущих мировых производителей. По цене шлюз OpenUNB сравним со шлюзом LoRaWAN и сильно дешевле NB-IoT (это целая базовая станция сотового оператора). Про цену шлюза SigFox ничего определенного мы сказать не можем, так как эта технология распространяется по миру в виде сети, и цену шлюза могут знать только локальные партнеры SigFox по построению сети, но я сомневаюсь даже в том, могут ли они выделить эту цену из затрат на развертывание сети.


    Большая дальность


    Так как максимальная мощность в нелицензируемом диапазоне нормирована, то дальность работы LPWAN-устройств определяется скоростью передачи в эфире, качеством приемника и свойствами эфирного протокола. В условиях естественных помех в эфире, дальность работы шлюза может существенно сократиться. OpenUNB использует сверхузкополосную модуляцию с современными методами помехоустойчивого кодирования, что обеспечивает площадь покрытия шлюза заведомо не меньше, чем у SigFox и в два раза больше LoRaWAN. Мощность устройств и базовых станций NB-IoT на лицензируемых частотах не ограничена так сильно, как на нелицензируемых у конкурирующих стандартов. Поэтому, хотя бюджет радио-линии NB-IoT и меньше, чем у конкурентов, дальность связи может быть больше. А может быть и меньше, если частоты базовых станций пересекаются. Это довольно частое явление из-за экономии оператором частот, ввиду дороговизны спектра.


    Большая пропускная способность


    В протоколе OpenUNB используется узкополосные (UNB) сигналы в полосе 100 или 200 кГц, что обеспечивает пропускную способность шлюза, аналогичную SigFox и более чем на порядок превышающую пропускную способность шлюза LoRaWAN. У NB-IoT потенциальная пропускная способность еще больше, так как скорость передачи информации больше. Некоторое немалое количество полосы пропускания в NB-IoT тратится на накладные расходы. Но вот вопрос: а нужна ли такая большая пропускная способность? Насколько оправданно экономически ее содержание?


    Высокая энергоэффективность


    Время работы от одной батарейки определяется энергией, затрачиваемой на передачу одного сообщения. Эфирный протокол OpenUNB содержит минимально необходимый объем служебной информации. По этому параметру мы в 3,3 раза эффективнее SigFox (стандартное время передачи короткого сообщения 12 бит от датчика у OpenUNB составляет не более 1,8 секунды, у SigFox – три посылки по 2 секунды = 6 секунд). При сравнении с LoRaWAN, необходимо учитывать затраты энергии LoRaWAN на обратный канал. При пересчете на одинаковую площадь покрытия наша технология позволяет расходовать батарейку как минимум в 3 раза эффективнее LoRaWAN, а NB-IoT еще более прожорлив. Этот расчет проведен для использования технологий для сбора информации с датчиков.


    Высокая помехозащищенность


    За счет использования в OpenUNB самых современных методов помехоустойчивого кодирования сигнала (в протоколе применяется полярный код, используемый в последних версиях стандарта сотовой связи пятого поколения 5G), достигнуты высокие показатели защиты от естественных и искусственно созданных помех в эфире, что обеспечивает необходимую дальность связи в безлицензионном диапазоне частот в реальных условиях эксплуатации. Дополнительные серьезные преимущества в помехозащищенности OpenUNB, особенно перед NB-IoT, дает отсутствие обратного канала связи — самым распространенным и доступным методом постановки помех является использование обычной «гушилки» сотовой связи, которая воздействует именно на обратный канал устройства.


    Информационная безопасность


    Ключевым элементом обеспечения безопасности в OpenUNB является система динамического кодирования, обеспечивающая защиту передачи адреса устройства в сети. У всех конкурирующих LPWAN систем (кроме NB-IoT) адрес устройства в сети передается в открытом виде, что создает риски безопасности за счет возможностей анализа активности датчиков в эфире по их идентификатору и возможностей манипуляции сообщениями. Для защиты информации в протоколе OpenUNB используется последовательность из трех ключей шифрования, сеансовый ключ, который меняется автоматически и счетчик сообщений. В качестве отрицательного примера в смысле информационной безопассности можно привести SigFox, где все вопросы шифрования сообщений отданы на откуп пользователям. Это требует от пользователей разрабатывать свои протоколы, делает необходимым удлинять полезную информацию, что еще больше ухудшает ситуацию с энергоэффективностью протокола.


    Открытая система


    У пользователей SigFox и NB-IoT имеется возможность производить свои собственные оконечные устройства, но они могут работать только через сеть и сервер существующих операторов, что не позволяет в этом случае говорить об открытой системе. Доступ к оборудованию и серверному ПО для пользователей LoRaWAN открыт, но реализация микросхем модема LoRa закрыта патентами. OpenUNB – полностью открытый протокол с открытой архитектурой и примерами реализации конечных устройств и шлюзов.


    OpenUNB – протокол односторонней связи без обратного канала


    Обратный канал (Downlink) обычно используется в следующих случаях: управление оконечным устройством (ОУ), изменение настроек ОУ, запрос на внеочередную передачу информации, квитанция о получении сообщения, создание и обновление ключей шифрования, обновление прошивки.


    Использование обратного канала в LPWAN системах приводит к следующим проблемам: увеличивается потребление батарейки и стоимость КУ, появляется возможность подавления канала связи с помощью простой «глушилки». У безлицензионных систем типа LoRaWAN и SigFox это приводит к еще более неприятным последствиям – катастрофически снижается пропускная способность шлюза и появляются пропуски сообщений в прямом канале (специфика шлюза этих систем — во время передачи он перестает принимать сообщения).


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


    Напомню о главных тезисах: OpenUNB — это открытость и минимализм. Открытость обсуждать не нужно, это понятно всем. Описание и код будут публиковаться открыто. Это позволит быстро начать работать со всем стеком технологии и обеспечит много других преимуществ, к которым ведет открытость.


    Минимализм OpenUNB происходит из одного его свойства: в протоколе используется только прямой (Uplink) LPWAN-канал. Это основное свойство OpenUNB я и предлагаю обсудить в первую очередь.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Достаточно ли для вашего приложения IoT одностороннего (Uplink) оконечного устройства?

    • 23,8%Да, совершенно достаточно10
    • 21,4%Может быть достаточно, если убрать лишние функции9
    • 61,9%Нет, никак не достаточно26

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 247 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 36

      +1

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


      Даже если эти проблемы как-то решатся, как вы собираетесь конкурировать с другими сходными протоколами типа лоравана на уровне производителя? Если у меня есть линейка устройств, которые могут работать в режиме только на передачу, и рядом с ней линейка устройств которые могут работать в обе стороны, то я с большой вероятностью поставлю в обе линейки тот же лораван классов А и С соответственно. Мне это снизит стоимость разработки за счёт того, что не надо переучивать персонал и разрабывать шлюзы и ПО заново. А моему потребителю я смогу предложить шлюз который совместим со всеми моими линейками.

        0
        Большое спасибо за вопросы! Отвечу с конца, по порядку повышения сложности ответа.

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

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

        Теперь о самом главном и интересном: о смысле даунлинка. С осмысленностью даунлинка никто не спорит, если он применяется в универсальных системах. Некоторым приложениям действительно нужен даунлинк, по определению. Его применение также не вызывает споров в системах, где канал передачи квитанции надежен. В NB-IoT мало кто станет передавать на лицензионных частотах, передают только БС и их излучения всегда происходят вовремя. В WiFi (который также применяют для локального сбора информации) устройство сначала слушает несущую, а потом передает (LBT, listen before talk), что резко снижает частоту коллизий. В нелицензируемом же диапазоне все передают асинхронно и бесконтрольно. Надежность такого канала передачи квитанций бывает катастрофически плохой. При этом, ввиду малой вычислительной мощности оконечного устройства, сделать приемник хоть сколько-нибудь похожим по помехоустойчивости на приемник базовой станции невозможно. Кстати, эта ассиметрия есть и в NB-IoT: на даунлинке применяется сверточное кодирование вместо Турбо-кодирования на аплинке. Два указанных фактора делают использование даунлинка вообще непрактичным. Ввиду довольно стабильных условия распространения сигнала на аплинке, энергетически (а это основная характеристика системы, определяющая стоимость эксплуатации) более выгодно упразднить его.

        Последний вопрос очень важен для OpenUNB, прошу всех поддержать дискуссию, выразить свое мнение.
        +1
        прошу всех поддержать дискуссию, выразить свое мнение

        Сейчас поддержим и выразим. :)

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

        Т. е. есть специфические задачи, где односторонняя связь уместна и вполне успешно применяется. Но если ваша система поддерживает только одностороннюю передачу, то это резко сужает диапазон её применимости и делает её узко-нишевой (со всеми вытекающими).

        В этом смысле гораздо более вменяемыми видятся универсальные системы, где логика работы (односторонняя или двусторонняя) меняется галочкой в интерфейсе управления.
          0
          Спасибо!

          Мысль как раз была в нишевости, но идеальности в этих нишах. Наибольшее число вариантов испоьлзования будут покрыты NB-IoT, OpenUNB могут достаться только узкие сегменты. Мы не то чтобы сдаемся, просто хотим взять свое)

          А сделать универсальный продукт сможет уже интегратор, который удобно объединит разные технологии.
            +1
            Да, если в какой-то нише нужна только эффективная односторонняя передача, то это вполне может быть востребовано.
              0
              В Вашей практике какой процент реальных проектов может быть выполнен на односторонней системе? Примерно.
                +1
                Боюсь вас огорчить — ни одного. В моей практике односторонняя передача данных используется только в сценарии, когда маловажный (не критический) параметр (например, температура в помещении) передаётся периодически (например, раз в 5 минут) и потеря 1-2 пакетов никак не скажется на работе системы.

                Или в сценарии, когда периодически передаётся не один (текущий) параметр, а накопительный блок параметров — здесь тоже потеря 1-2 пакетов не сыграет никакой роли.

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

                Но! Если у вас поле кукурузы в несколько гектаров, то ваша технология вполне подойдёт, например, для периодической передачи данных о влажности и температуре почвы и т. п. применений или, например, для тех же ЖКХ счётчиков.
                  +1
                  Для ЖКХ, как раз, не подойдет. Для коммерческого учета, во всяком случае.
                    0
                    А что мешает?
                      +1
                      Постановления правительства :-)
                      Там серьезные требования по полноте собранных данных. Вот вырубили электричество на вышке с базовой станцией (что бывает куда чаще, чем хотелось бы) в неподходящий момент, в ночь на первое число — и что делать без обратного канала? Устройство не в курсе, само их по новой не пошлет. Запросить тоже нельзя. Дядьку с тетрадкой посылать? Так и дядька не факт, что очень поможет. Ведутся ли еще архивы на устройстве… И как к ним достукиваться…

                      Ну и тут в теме рядом СПОДЭС обсуждается — это, фактически, ответ про случай учета потребления электроэнергии.
                        0
                        Спасибо, изучим вопрос.
                  +1
                  Скотоводы (отечественные) бьются с трекингом скота. Угоняют коровок. Вообще, asset tracking, пожалуй, единственная вертикаль, которая в голову приходит, где без обратного канала можно жить. Не такая и маленькая, кстати, вертикаль.
                    0
                    Классное приложение! Есть какие-то детали? Если это воровство, то любое устройство могут сразу срезать и уничтожить, чтобы уже ничего нельзя было отслеживать. Тогда остается только возможность определять последнее местоположение. Какова правтика вопроса?
                      +1
                      Если Вы в «Сколтехе» и рядом — без труда узнаете детали из более авторитетных, чем я, источников. Просто поинтересуйтесь. Хотя, возможно, люди будут улыбаться :-) Практика такова, что это уже притча во языцех :-)

                      Хинт — датчик вешается коровке на ухо. Так вот там термометр нужен, определеять, жива ли коровка. или пастух ухо отрезал и в кармане носит, а коровка уже на рынке по частям и сортам разделана.

                      А в целом посмотрите на AGPS. Ну, «Глонасс» в нашем случае. У этого еще есть шанс rкакой-то стать killer app, IMHO.
                        0
                        Спрошу, спасибо. Как раз мое любимое приложение: радионавигация.

                        Хинт «пастуху»: печка для поддержания температуры ушка в кармане.
            +1
            Слабо представляется место, где совсем не нужен обратный канал. Помимо этого ряд бюрократических проблем помешает сделать востребованным OpenUNB.
            Протоколы XNB и NB-Fi позволяют передавать без хендшейка, что означает что ваш протокол будет являться лишь частью уже существующих. Помимо этого, ровно эти два протокола прошли сертификацию в ТОРП (http://arpe.ru/news/IoT_v_Rossii_okrashivaetsya_v_trikolor/), даже у LoRaWAN систем есть с этим проблемы. Собрать средства на сертификацию базовых станций непростая задача, а если при этом для рынка — это места куда не забрались Вега, Вавиот или Стриж, то все совсем грустно.
            С учетом того с какой скоростью принимаются законы, в России скоро придется всю промышленность делать на Российский чипах. В текущей ситуации Вавиот (их же радио WA1470) и Миландр имеют огромное преимущество перед OpenUNB. Вавиот уже открыл некоторые исходники на своем гите, БС там конечно же нет, но и смысла в ней мало без ТОРПа.
            Так что похоже на еще один мертворожденный проект Сколтеха
              0
              Спасибо за комментарий!

              В бюрократии я слабо разбираюсь. Вижу одно конкурентное преимущество OpenUNB перед XNB и NB-Fi — полная открытость:
              1. Код базовой станции будет доступен на Github.
              2. Открытость протокола безопасности приведет к существенно большему доверию к стандарту.
                +1
                Доверию со стороны кого? Организации, за чье доверие есть экономический смысл бороться, это как раз воплощение бюрократии :-) Их вражеским гитхабом не убедишь.
                  0
                  Доверие разработчиков приложений. Открытость позволяет расчитывать на адекватность технических решений и на независимость от мелких обстоятельств.
                    +1
                    Для успеха-то надо доверие потребителей…
                      0
                      Разработчики приложений и есть потребители стандарта.
              +1
              Когда я последний раз видел потроха этого — на публичной презентации в Сколково — это было курсачём двух четверокурскников, причём ну таким, «вижу, старались, так что так и быть, ставлю «хорошо»». Очень на коленке и с пассажами вроде «безопасностью мы пока вообще не занимались, но если надо, потом займёмся».

              Там всё выкинули, включая авторов, и переписали заново?
                0
                Выкинули ли авторов, я не знаю, но там сейчас сильные люди работают над всеми вопросами, включая безопасность. Протокол изменился основательно. Вы оцените документ, когда он выйдет на публику.
                +1
                Спасибо за быстрый ответ!

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

                Обязательная дорогая и долгая сертификация на БС существует
                ->
                Делать свою собственную БС дорого и долго
                ->
                Рынок людей, которые вообще будут лезть внутрь БС, по сути, с 1 декабря этого года равен НУЛЮ
                ->
                Основное преимущество OpenUNB теряет конкурентоспособность 1 декабря.

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

                Про безопасность асинхронного шифрования я бы поговорил, это важно и это здорово, но односторонняя связь нивелирует его. Вряд ли можно сделать что-то сильно лучше чем тот же AES-128 для ультрадешевых устройств.
                  0
                  Спасибо, очень подробно! Я моменты с ТОРП так сразу не могу прокомментировать, нужно тему изучить.

                  По шифрованию скажу, что в следующих статьях оно будет раскрыто. Надеюсь на обсуждение.
                +1
                И да…
                В протоколе OpenUNB используется узкополосные (UNB) сигналы в полосе 100 или 200 кГц


                кГц?
                  0
                  Модулирующая частота 100 Гц, вся полоса системы 100 кГц или 200 кГц.
                    +1
                    Спасибо. Я как-то так и думал, но решил уточнить.
                  +1
                  Добрый день!
                  А можно поподробнее насчет помехозащищенности и полярного кодирования (это что-то типа Манчестерского кода или какое-то новшество). И как чисто программное решение (применение того или иного способа кодирования, если я правильно понял) может влиять на компенсацию физических радиопомех? Было бы супер отдельную главу сделать, очень помогло бы не только с освоением OpenUNB. Спасибо.
                    0
                    Добрый день!
                    В OpenUNB используется полярный код. Мы готовим статью по этой теме.
                    +1

                    Вы пишите, что OpenUNB – это протокол односторонней связи без обратного канала, но в описании протокола первой редакции есть обратный канал. Его не будет в следующей редакции?

                      0
                      Так точно, в новом варианте обратного (downlink) канала не будет.
                        +1

                        Подскажите, пожалуйста, как планируется обеспечить совместимость устройств, разработанных разными компаниями и возможен ли вариант работы таких устройств в рамках одной сети?


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

                          +1
                          Добрый день,
                          поскольку протокол предусматривает использование динамической адресации, то каждый производитель может использовать свои собственные ID — без необходимости их общей синхронизации.
                      +1
                      Особое внимание следует уделить маске спектра и внеполосным излучениям. Методике проведения измерений. Требованиям к приёмной аппаратуре.

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

                      Самое читаемое