Комментарии 36
В статье вы пишите, что целью создания технологии является в том числе обеспечение надёжного и безопасного канала сбора информации с датчиков. Как вы обеспечите надёжность передачи данных без даунлинка и квитанции о получении? И какой протокол вы хотите использовать для обеспечения безопасной передачи в отсутствии всякого хендшейка?
Даже если эти проблемы как-то решатся, как вы собираетесь конкурировать с другими сходными протоколами типа лоравана на уровне производителя? Если у меня есть линейка устройств, которые могут работать в режиме только на передачу, и рядом с ней линейка устройств которые могут работать в обе стороны, то я с большой вероятностью поставлю в обе линейки тот же лораван классов А и С соответственно. Мне это снизит стоимость разработки за счёт того, что не надо переучивать персонал и разрабывать шлюзы и ПО заново. А моему потребителю я смогу предложить шлюз который совместим со всеми моими линейками.
Большое спасибо за вопросы! Отвечу с конца, по порядку повышения сложности ответа.
Как я понимаю, основное конкурентное преимущество — заточенность на массовый сбор информации с датчиков. Протокол обеспечивает минимальное потребление оконечного устройства, не теряя в помеховой и инфомационной защищенности. Большое спасибо за ваше мнение и раскрытие логики принятия решения!
Полное описание протокола безопасности готовится. Оно сейчас проходит зкспертизу и будет опубликовано в ближайшее время. Надеюсь, ваше ожидание окупится степенью проработки вопросов безопасности. Создатели протокола уделяют ей много сил и времени.
Теперь о самом главном и интересном: о смысле даунлинка. С осмысленностью даунлинка никто не спорит, если он применяется в универсальных системах. Некоторым приложениям действительно нужен даунлинк, по определению. Его применение также не вызывает споров в системах, где канал передачи квитанции надежен. В NB-IoT мало кто станет передавать на лицензионных частотах, передают только БС и их излучения всегда происходят вовремя. В WiFi (который также применяют для локального сбора информации) устройство сначала слушает несущую, а потом передает (LBT, listen before talk), что резко снижает частоту коллизий. В нелицензируемом же диапазоне все передают асинхронно и бесконтрольно. Надежность такого канала передачи квитанций бывает катастрофически плохой. При этом, ввиду малой вычислительной мощности оконечного устройства, сделать приемник хоть сколько-нибудь похожим по помехоустойчивости на приемник базовой станции невозможно. Кстати, эта ассиметрия есть и в NB-IoT: на даунлинке применяется сверточное кодирование вместо Турбо-кодирования на аплинке. Два указанных фактора делают использование даунлинка вообще непрактичным. Ввиду довольно стабильных условия распространения сигнала на аплинке, энергетически (а это основная характеристика системы, определяющая стоимость эксплуатации) более выгодно упразднить его.
Последний вопрос очень важен для OpenUNB, прошу всех поддержать дискуссию, выразить свое мнение.
Как я понимаю, основное конкурентное преимущество — заточенность на массовый сбор информации с датчиков. Протокол обеспечивает минимальное потребление оконечного устройства, не теряя в помеховой и инфомационной защищенности. Большое спасибо за ваше мнение и раскрытие логики принятия решения!
Полное описание протокола безопасности готовится. Оно сейчас проходит зкспертизу и будет опубликовано в ближайшее время. Надеюсь, ваше ожидание окупится степенью проработки вопросов безопасности. Создатели протокола уделяют ей много сил и времени.
Теперь о самом главном и интересном: о смысле даунлинка. С осмысленностью даунлинка никто не спорит, если он применяется в универсальных системах. Некоторым приложениям действительно нужен даунлинк, по определению. Его применение также не вызывает споров в системах, где канал передачи квитанции надежен. В NB-IoT мало кто станет передавать на лицензионных частотах, передают только БС и их излучения всегда происходят вовремя. В WiFi (который также применяют для локального сбора информации) устройство сначала слушает несущую, а потом передает (LBT, listen before talk), что резко снижает частоту коллизий. В нелицензируемом же диапазоне все передают асинхронно и бесконтрольно. Надежность такого канала передачи квитанций бывает катастрофически плохой. При этом, ввиду малой вычислительной мощности оконечного устройства, сделать приемник хоть сколько-нибудь похожим по помехоустойчивости на приемник базовой станции невозможно. Кстати, эта ассиметрия есть и в NB-IoT: на даунлинке применяется сверточное кодирование вместо Турбо-кодирования на аплинке. Два указанных фактора делают использование даунлинка вообще непрактичным. Ввиду довольно стабильных условия распространения сигнала на аплинке, энергетически (а это основная характеристика системы, определяющая стоимость эксплуатации) более выгодно упразднить его.
Последний вопрос очень важен для OpenUNB, прошу всех поддержать дискуссию, выразить свое мнение.
прошу всех поддержать дискуссию, выразить свое мнение
Сейчас поддержим и выразим. :)
Как практик IoT и автоматизации, могу сказать, что в реальных проектах требуются оба варианта (односторонней и двусторонней передачи), в зависимости от свойств системы и условий решаемой задачи.
Т. е. есть специфические задачи, где односторонняя связь уместна и вполне успешно применяется. Но если ваша система поддерживает только одностороннюю передачу, то это резко сужает диапазон её применимости и делает её узко-нишевой (со всеми вытекающими).
В этом смысле гораздо более вменяемыми видятся универсальные системы, где логика работы (односторонняя или двусторонняя) меняется галочкой в интерфейсе управления.
Спасибо!
Мысль как раз была в нишевости, но идеальности в этих нишах. Наибольшее число вариантов испоьлзования будут покрыты NB-IoT, OpenUNB могут достаться только узкие сегменты. Мы не то чтобы сдаемся, просто хотим взять свое)
А сделать универсальный продукт сможет уже интегратор, который удобно объединит разные технологии.
Мысль как раз была в нишевости, но идеальности в этих нишах. Наибольшее число вариантов испоьлзования будут покрыты NB-IoT, OpenUNB могут достаться только узкие сегменты. Мы не то чтобы сдаемся, просто хотим взять свое)
А сделать универсальный продукт сможет уже интегратор, который удобно объединит разные технологии.
Да, если в какой-то нише нужна только эффективная односторонняя передача, то это вполне может быть востребовано.
В Вашей практике какой процент реальных проектов может быть выполнен на односторонней системе? Примерно.
Боюсь вас огорчить — ни одного. В моей практике односторонняя передача данных используется только в сценарии, когда маловажный (не критический) параметр (например, температура в помещении) передаётся периодически (например, раз в 5 минут) и потеря 1-2 пакетов никак не скажется на работе системы.
Или в сценарии, когда периодически передаётся не один (текущий) параметр, а накопительный блок параметров — здесь тоже потеря 1-2 пакетов не сыграет никакой роли.
В остальных случаях или в критических приложениях используется, конечно же, передача с обратной связью и гарантированной доставкой сообщения.
Но! Если у вас поле кукурузы в несколько гектаров, то ваша технология вполне подойдёт, например, для периодической передачи данных о влажности и температуре почвы и т. п. применений или, например, для тех же ЖКХ счётчиков.
Или в сценарии, когда периодически передаётся не один (текущий) параметр, а накопительный блок параметров — здесь тоже потеря 1-2 пакетов не сыграет никакой роли.
В остальных случаях или в критических приложениях используется, конечно же, передача с обратной связью и гарантированной доставкой сообщения.
Но! Если у вас поле кукурузы в несколько гектаров, то ваша технология вполне подойдёт, например, для периодической передачи данных о влажности и температуре почвы и т. п. применений или, например, для тех же ЖКХ счётчиков.
Для ЖКХ, как раз, не подойдет. Для коммерческого учета, во всяком случае.
А что мешает?
Постановления правительства :-)
Там серьезные требования по полноте собранных данных. Вот вырубили электричество на вышке с базовой станцией (что бывает куда чаще, чем хотелось бы) в неподходящий момент, в ночь на первое число — и что делать без обратного канала? Устройство не в курсе, само их по новой не пошлет. Запросить тоже нельзя. Дядьку с тетрадкой посылать? Так и дядька не факт, что очень поможет. Ведутся ли еще архивы на устройстве… И как к ним достукиваться…
Ну и тут в теме рядом СПОДЭС обсуждается — это, фактически, ответ про случай учета потребления электроэнергии.
Там серьезные требования по полноте собранных данных. Вот вырубили электричество на вышке с базовой станцией (что бывает куда чаще, чем хотелось бы) в неподходящий момент, в ночь на первое число — и что делать без обратного канала? Устройство не в курсе, само их по новой не пошлет. Запросить тоже нельзя. Дядьку с тетрадкой посылать? Так и дядька не факт, что очень поможет. Ведутся ли еще архивы на устройстве… И как к ним достукиваться…
Ну и тут в теме рядом СПОДЭС обсуждается — это, фактически, ответ про случай учета потребления электроэнергии.
Скотоводы (отечественные) бьются с трекингом скота. Угоняют коровок. Вообще, asset tracking, пожалуй, единственная вертикаль, которая в голову приходит, где без обратного канала можно жить. Не такая и маленькая, кстати, вертикаль.
Классное приложение! Есть какие-то детали? Если это воровство, то любое устройство могут сразу срезать и уничтожить, чтобы уже ничего нельзя было отслеживать. Тогда остается только возможность определять последнее местоположение. Какова правтика вопроса?
Если Вы в «Сколтехе» и рядом — без труда узнаете детали из более авторитетных, чем я, источников. Просто поинтересуйтесь. Хотя, возможно, люди будут улыбаться :-) Практика такова, что это уже притча во языцех :-)
Хинт — датчик вешается коровке на ухо. Так вот там термометр нужен, определеять, жива ли коровка. или пастух ухо отрезал и в кармане носит, а коровка уже на рынке по частям и сортам разделана.
А в целом посмотрите на AGPS. Ну, «Глонасс» в нашем случае. У этого еще есть шанс rкакой-то стать killer app, IMHO.
Хинт — датчик вешается коровке на ухо. Так вот там термометр нужен, определеять, жива ли коровка. или пастух ухо отрезал и в кармане носит, а коровка уже на рынке по частям и сортам разделана.
А в целом посмотрите на AGPS. Ну, «Глонасс» в нашем случае. У этого еще есть шанс rкакой-то стать killer app, IMHO.
Слабо представляется место, где совсем не нужен обратный канал. Помимо этого ряд бюрократических проблем помешает сделать востребованным OpenUNB.
Протоколы XNB и NB-Fi позволяют передавать без хендшейка, что означает что ваш протокол будет являться лишь частью уже существующих. Помимо этого, ровно эти два протокола прошли сертификацию в ТОРП (http://arpe.ru/news/IoT_v_Rossii_okrashivaetsya_v_trikolor/), даже у LoRaWAN систем есть с этим проблемы. Собрать средства на сертификацию базовых станций непростая задача, а если при этом для рынка — это места куда не забрались Вега, Вавиот или Стриж, то все совсем грустно.
С учетом того с какой скоростью принимаются законы, в России скоро придется всю промышленность делать на Российский чипах. В текущей ситуации Вавиот (их же радио WA1470) и Миландр имеют огромное преимущество перед OpenUNB. Вавиот уже открыл некоторые исходники на своем гите, БС там конечно же нет, но и смысла в ней мало без ТОРПа.
Так что похоже на еще один мертворожденный проект Сколтеха
Протоколы XNB и NB-Fi позволяют передавать без хендшейка, что означает что ваш протокол будет являться лишь частью уже существующих. Помимо этого, ровно эти два протокола прошли сертификацию в ТОРП (http://arpe.ru/news/IoT_v_Rossii_okrashivaetsya_v_trikolor/), даже у LoRaWAN систем есть с этим проблемы. Собрать средства на сертификацию базовых станций непростая задача, а если при этом для рынка — это места куда не забрались Вега, Вавиот или Стриж, то все совсем грустно.
С учетом того с какой скоростью принимаются законы, в России скоро придется всю промышленность делать на Российский чипах. В текущей ситуации Вавиот (их же радио WA1470) и Миландр имеют огромное преимущество перед OpenUNB. Вавиот уже открыл некоторые исходники на своем гите, БС там конечно же нет, но и смысла в ней мало без ТОРПа.
Так что похоже на еще один мертворожденный проект Сколтеха
Спасибо за комментарий!
В бюрократии я слабо разбираюсь. Вижу одно конкурентное преимущество OpenUNB перед XNB и NB-Fi — полная открытость:
1. Код базовой станции будет доступен на Github.
2. Открытость протокола безопасности приведет к существенно большему доверию к стандарту.
В бюрократии я слабо разбираюсь. Вижу одно конкурентное преимущество OpenUNB перед XNB и NB-Fi — полная открытость:
1. Код базовой станции будет доступен на Github.
2. Открытость протокола безопасности приведет к существенно большему доверию к стандарту.
Когда я последний раз видел потроха этого — на публичной презентации в Сколково — это было курсачём двух четверокурскников, причём ну таким, «вижу, старались, так что так и быть, ставлю «хорошо»». Очень на коленке и с пассажами вроде «безопасностью мы пока вообще не занимались, но если надо, потом займёмся».
Там всё выкинули, включая авторов, и переписали заново?
Там всё выкинули, включая авторов, и переписали заново?
Спасибо за быстрый ответ!
Незнание не освобождает от ответственности, крайне рекомендую ознакомиться с ТОРП. Ведь именно дорогая сертификации инициирует последовательность, обесценивающую ваш труд.
Обязательная дорогая и долгая сертификация на БС существует
->
Делать свою собственную БС дорого и долго
->
Рынок людей, которые вообще будут лезть внутрь БС, по сути, с 1 декабря этого года равен НУЛЮ
->
Основное преимущество OpenUNB теряет конкурентоспособность 1 декабря.
Я согласен с тем что законы просто обрубают на корню все мелкие проекты, но законы есть законы.
Возможно, вы планировали делать свои собственные БС, но при этом делать их максимально открытыми и кастомизируемыми.
В этом случае, для того чтобы сделать дешево вам нужна серийность, что означает что вам нужна промышленность, что означает что вам нужно тягаться с Вегой, Стрижем и Вавиотом, что скорее всего невозможно без обратной связи.
В случае если, вам не важна цена, на первый план выйдет Лора.
Про безопасность асинхронного шифрования я бы поговорил, это важно и это здорово, но односторонняя связь нивелирует его. Вряд ли можно сделать что-то сильно лучше чем тот же AES-128 для ультрадешевых устройств.
Незнание не освобождает от ответственности, крайне рекомендую ознакомиться с ТОРП. Ведь именно дорогая сертификации инициирует последовательность, обесценивающую ваш труд.
Обязательная дорогая и долгая сертификация на БС существует
->
Делать свою собственную БС дорого и долго
->
Рынок людей, которые вообще будут лезть внутрь БС, по сути, с 1 декабря этого года равен НУЛЮ
->
Основное преимущество OpenUNB теряет конкурентоспособность 1 декабря.
Я согласен с тем что законы просто обрубают на корню все мелкие проекты, но законы есть законы.
Возможно, вы планировали делать свои собственные БС, но при этом делать их максимально открытыми и кастомизируемыми.
В этом случае, для того чтобы сделать дешево вам нужна серийность, что означает что вам нужна промышленность, что означает что вам нужно тягаться с Вегой, Стрижем и Вавиотом, что скорее всего невозможно без обратной связи.
В случае если, вам не важна цена, на первый план выйдет Лора.
Про безопасность асинхронного шифрования я бы поговорил, это важно и это здорово, но односторонняя связь нивелирует его. Вряд ли можно сделать что-то сильно лучше чем тот же AES-128 для ультрадешевых устройств.
И да…
кГц?
В протоколе OpenUNB используется узкополосные (UNB) сигналы в полосе 100 или 200 кГц
кГц?
Добрый день!
А можно поподробнее насчет помехозащищенности и полярного кодирования (это что-то типа Манчестерского кода или какое-то новшество). И как чисто программное решение (применение того или иного способа кодирования, если я правильно понял) может влиять на компенсацию физических радиопомех? Было бы супер отдельную главу сделать, очень помогло бы не только с освоением OpenUNB. Спасибо.
А можно поподробнее насчет помехозащищенности и полярного кодирования (это что-то типа Манчестерского кода или какое-то новшество). И как чисто программное решение (применение того или иного способа кодирования, если я правильно понял) может влиять на компенсацию физических радиопомех? Было бы супер отдельную главу сделать, очень помогло бы не только с освоением OpenUNB. Спасибо.
Вы пишите, что OpenUNB – это протокол односторонней связи без обратного канала, но в описании протокола первой редакции есть обратный канал. Его не будет в следующей редакции?
Так точно, в новом варианте обратного (downlink) канала не будет.
Подскажите, пожалуйста, как планируется обеспечить совместимость устройств, разработанных разными компаниями и возможен ли вариант работы таких устройств в рамках одной сети?
Кроме того, кто будет обеспечивать уникальность идентификатора абонентского устройства? Если это делает производитель, то в случае, когда в одной сети работают устройства разных производителей, могут возникнуть конфликты, связанные с одинаковостью этих идентификаторов.
Особое внимание следует уделить маске спектра и внеполосным излучениям. Методике проведения измерений. Требованиям к приёмной аппаратуре.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интернет вещей по-русски. Минимализм и открытость OpenUNB