Привет, Хабр!
Некоторое время тому назад рабочая группа Сколтеха по Интернету вещей опубликовала проект национального стандарта узкополосной связи для IoT под названием «OpenUNB», полный текст которого можно найти здесь. С одной стороны, явление безусловно положительное – если в области стандартов широкополосных существует de facto открытый к применению всеми желающими LoRaWAN, то узкополосные стандарты до сего дня были исключительно проприетарными (Sigfox, XNB компании «Стриж», NB-Fi компании «Вавиот» — хотя последний также опубликован в виде проекта национального стандарта, в нём не открыты существенные для реализации сторонними лицами части).
При этом узкополосные и широкополосные системы имеют каждая свои плюсы и минусы, так что говорить «зачем вам что-то ещё, когда есть LoRaWAN» – не совсем верно. То есть, открытый стандарт на UNB-связь необходим.
Однако, необходимость – это лишь одно из двух условий. Второе – достаточность. Ок, то, что опубликовал Сколтех, необходимо, но достаточно ли оно для практического применения?
Мы ответим на это в формате, похожем на интервью – под катом цитаты из проекта стандарта OpenUNB и комментарии к ним, данные Александром Шептовецким (AS), техническим директором компании GoodWAN, и Олегом Артамоновым (OA), техническим директором компании Unwired Devices.
Итак, поехали. Стилистика, орфография и пунктуация авторов сохранены.
Особенностью протокола является использование сверхузкополосной модуляции (ширина спектра излучения менее 1 кГц), что позволяет добиться высокого соотношения сигнал–шум (при ограничениях на излучаемую мощность в нелицензируемом диапазоне), а значит передавать данные на большие расстояния или через множественные препятствия (бетонные стены, перегородки, металлические шкафы).OA: первая же ошибка авторов стандарта – в том, что они изначально предполагают для сигналов в LPWAN-системах основным требованием высокое SNR (соотношение сигнал-шум) – и из этого в дальнейшем растут ошибки уже в проектировании и реализации самого протокола, такие как выбор преамбулы, например.
Такое возможно, благодаря тому, что абонентские устройства передают данные в эфир без установления соединения с базовой станцией (симплексный режим), как например это делается в мобильных сетях сотовой связи.OA: помимо стилистических и пунктуационных ошибок, отмечу недопустимо небрежное использование терминологии. Симплексный режим, то есть передача сообщений по каналу связи только в одну сторону, к необходимости установления соединения не имеет прямого отношения – и уж точно это не синонимы. Тот же LoRaWAN обеспечивает двустороннюю связь в полудуплексном режиме, но при этом также не требует предварительного установления соединения с БС.
Для упрощения и удешевления конструкции приемопередатчика, прием и передача разнесены по времени, то есть обмен данными с базовой станции осуществляется либо в симплексном режиме (передача от абонентского устройства на базовую станцию), либо в полудуплексном режиме (передача от абонентского устройства на базовую станцию и последующий прием на абонентском устройстве от базовой станции).OA: и буквально через полстраницы оказывается, что и полудуплексный режим в OpenUNB тоже есть! Вообще хочу заметить, что таких внутренних противоречий в проекте стандарта очень много.
Порядок байт в пакете – от старшего к младшему (big-endian)OA: big-endian – это тип компьютерной архитектуры с определённым порядком байт в многобайтовом числе. В пакете же порядок байт всегда один и тот же – от первого к последнему. Повторюсь: для проекта национального стандарта такое небрежное употребление устоявшейся терминологии недопустимо.
Пакеты могут быть разной длины в зависимости от размера полезной нагрузки. Варианты длины полезной нагрузки: 0, 64 или 128 бит. Сообщение с нулевой полезной нагрузкой может быть использовано в качестве регулярного сигнала, о том, что устройство функционирует (heartbeat). Длины пакетов в 64 и 128 бит обусловлены размерами шифроблоков алгоритмов шифрования.AS: Разработчики ограничили длину полезной нагрузки в 0, 64 или 128 бит, оправдывая это удобством шифрования. Это совершенно надуманное ограничение. Иногда необходимо передавать очень короткие сообщения, а придется использовать 64 бита. О какой энергоэффективности можно говорить после этого! Как шифровать короткие посылки длинными ключами, можно почитать, например в LoRaWAN протоколе.
Для достижения высокой дальности передачи в нелицензируемом диапазоне необходима высокое соотношение сигнал–шум. Оно достигается за счет сверхмалой ширины полосы передачи (порядка 100 Гц).AS: в проекте стандарта нет даже единого мнения о ширине полосы – то она «меньше 1 кГц», то «порядка 100 Гц». Разве нельзя было в стандарте прийти к какому-то одному утверждению?..
Некоторые приемопередатчики могут достаточно сильно изменять свои свойства в самом начале передачи. Это может отразиться на частоте и длине модулированного сигнала первых бит в пакете. Для компенсации этого фактора, перед началом передачи преамбулы рекомендуется излучить сигнал на частоте пакета, длительностью, равной длительности передачи 1-2 бит (рисунок 2). […] В конце передачи, после контрольной суммы также следует изучить на 1 бит больше и плавно уменьшить амплитуду сигнала, что увеличит вероятность корректного приема последнего бита
Рекомендованное значение преамбулы для пакета восходящего канала: 10101010101010102. На усмотрение разработчиков значения преамбулы для всей сети может быть изменено. К примеру, это может быть использовано для создания нескольких сетей на одной территории, прием которых тех или иных базовых станций будет разделен на основании различных преамбул.AS: Краткое пояснение. Приемники UNB-сигнала работают на уровне шумов эфира. Как правило, используют приемники прямого преобразования, после которых делают БПФ. Если сигнал имеет фазовую модуляцию, то дальше смотрят за изменением фазы по каждому частотному каналу. Если в каком-либо канале находят цифровую последовательность, соответствующую преамбуле, то принимают решение о наличии полезного сигнала. При этом на каждом корреляторе после БПФ из шумов эфира постоянно идет случайная последовательность нулей и единиц – это означает, что всегда существует вероятность получить преамбулу из шумов эфира. Теперь посмотрим с какой частотой будут появляться ложные преамбулы длиной 16 бит, например, на приемнике, использование которого декларирует «Вавиот» – авторы схожего «проекта национального стандарта». Декларируемая ими полоса приема составляет 200 кГц с шагом БПФ 7 Гц, значит, необходимо более 28 тысяч корреляторов. Для точного попадания в бит длиной 10 мс (скорость передачи 100 б/с) корреляторы запускают каждые 2,5 мс. Итого, каждую секунду надо проверять 11 млн. коррелятов на возможное наличие преамбулы, и из шумов эфира каждую секунду будет сыпаться в среднем 178 ложных преамбул. Каждую ложную преамбулу надо обработать – и при этом не потерять прием истинных преамбул. Это неоправданно избыточная задача для процессора БС, который и так работает на пределе возможностей.
Идентификатор отправителя представляет собой уникальную последовательность из 32 бит назначаемую устройству при его производстве. Дополнительные сведения об идентификаторах приведены в Приложение Е: Формат написания идентификаторов, абонентских устройств, расчета контрольной информации и зарезервированные диапазоны идентификаторов.OA: в стандарте, претендующем на основу единой системы передачи данных в системах учёта потребления ресурсов, не описаны правила, по которым производители выбирают себе идентификаторы – даже не указано, что такие правила когда-либо будут. К чему это приведёт? Правильно, к куче устройств разных производителей, но с одинаковыми идентификаторами, потому что каждый второй производитель будет просто нумеровать устройства с нуля.
Служебная информация состоит из 8-ми бит, причем, самые левые 6 бит зарезервированы для будущего использования. 2 бита отведены для номера пакета в сообщении.OA: очень странный и очень скромный объём служебной информации. Можно было бы указать сквозной номер пакета, тип шифрования, размер пакета, много другого. При этом непонятно, зачем нам вообще нужен «локальный» номер пакета в сообщении – допустим, мы приняли пакет номер 0, а потом номер 1. Должны ли мы отбросить второй? А если это пакет номер 1 уже из следующего сообщения, от которого мы потеряли в эфире номер 0? А если мы не можем отбрасывать пакеты по этому признаку, как вообще мы решаем проблему с тем, что устройство может передать 4 одинаковых пакета подряд – принимаем и учитываем их все, получая на выходе многократное дублирование полезной нагрузки?..
Контрольная сумма пакета вычисляется на основе алгоритма приведенного в Приложении Б: Расчет контрольной суммы пакетов.OA: честно говоря, просто стою с открытым ртом. Никакой, вообще никакой защиты от типовых атак в протоколе просто не предусмотрено! При заявленной безопасности и защищённости протокола, использовании стойких шифров, и прочая, и прочая, любой желающий может поймать чужой пакет, поменять в нём поля, подставить полезную нагрузку от другого пакета, пересчитать контрольную сумму – и передать в эфир, а базовая станция это примет и не никак не сможет отличить подделку от «родного» пакета.
Ключи шифрования должны хранятся на абонентском устройстве и на серверах сети в защищенном хранилище. Для шифрования пакетов восходящего и нисходящего каналов должны использоваться различные ключи шифрования. Для каждого устройства набор ключей шифрования должен быть уникальнымOA: с одной стороны, разработчики OpenUNB записывают себе в заслугу «размеры полей подобраны кратными 8-ми битам, для более эффективной обработке на микропроцессорах» (орфография авторская), с другой – судя по всему, просто не знают про такой эффективный приём оптимизации симметричного шифрования, как возможность держать на конечном устройстве вместо двух процедур – шифровки и расшифровки – только одну, что довольно-таки заметно сокращает размер прошивки на микроконтроллерах. По крайней мере, в проекте стандарта он не упоминается.
Отправка сообщения из нисходящего канала возможна только в ответ на сообщение из восходящего. Это обусловлено несколькими причинами. Во-первых, протокол специализирован для абонентских устройств, не имеющих внешнего питания и рассчитанных на сверхдолгий срок службы от одной батареи, а значит, энергопотребление играет ключевую роль. Так как потребление передатчика в режиме приема достаточно высоко, то переходить в этот режим следует только на короткий промежуток времениOA: не очень понимаю, зачем сознательно ограничивать область применения стандарта, более того – делать её уже, чем заявлено во введении к этому же стандарту. Обычный бытовой электросчётчик имеет внешнее питание? Имеет. Что мешает держать на нём «передатчик в режиме приёма» включённым постоянно? Ничто.
Во-вторых, выбор конкретного временного слота на абонентском устройстве невозможен, так как в целях уменьшения себестоимости абонентских устройств они часто оборудуются малостабильными кварцевыми генераторами и не имеют часов реального времени.OA: это, конечно, не так. Во-первых, забегая на два абзаца вперёд, авторы и так держат огромное по длительности окно приёма – 8 секунд (в том же LoRaWAN окна приёма имеют размер 1-2 секунды). Во-вторых, достаточно посчитать, с какой периодичностью устройство должно синхронизировать часы с базовой станцией (и предусмотреть метод такой синхронизации), чтобы проблема нестабильности кварца не была проблемой. В LoraWAN это сделано в устройствах класса B.
В-третьих, малая стабильность кварцевых генераторов на абонентских устройствах требует применения алгоритма корректировки частоты, описанного в Приложении Д: Корректировка частоты передачи нисходящего канала. Но, так как для вычисления ухода частоты используется последнее сообщение из восходящего канала, а частота кварцевого генератора может меняться во времени (например, при изменении температуры), то время между последним восходящем сообщением и нисходящем должно быть достаточно малым, чтобы изменение отклонения частоты на абонентском устройстве за этот период было незначительным.AS: Судя по подробностям описания, самым главным своим достижением разработчики протокола OpenUNB считают решение проблемы синхронизации down-канала по частоте.
Длительность временного отрезка Tdl выбирается кратно превышающей длительность передачи одного пакета нисходящего канала. Такое увеличение размеров временного окна необходимо, так как на одну станцию обычно приходится множество устройств, что может привести к потребности посылки пакета нисходящего канала нескольким устройствам одновременно.OA: Every magic comes with a price, как говорил герой одного сериала. В случае с планированием радиосетей эту цену необходимо рассчитывать – и то ли авторы проекта стандарта не нашли времени на такие расчёты (но, может, тогда не стоило торопиться с публикацией проекта?), то ли вообще не догадались их сделать.
В случае успешного приема абонентским устройством сообщения из нисходящего канала, оно в ответ отправляет сообщение об успешном приема по восходящему каналу. В пользовательских данных которого должен содержаться указание на сообщение которое подтверждается.OA: И опять здравствуй, безопасность! В качестве подтверждения доставки предлагается отправлять с базовой станции криптографически незащищённый пакет, подделать который может любой желающий за полминуты. Не говоря уже о том, что попробуйте понять из этих двух абзацев – на ACK устройство должно отправлять сообщение о его успешном приёме? Из буквального текста проекта стандарта получается, что должно. ACK на ACK. Но, как минимум, нигде не сказано, что на ACK на ACK базовая станция должна отвечать ACK – а точнее, в проекте стандарта вообще нигде не говорится, как БС должна понимать, подтверждать ей приём пакета или нет. Свойством пакета это не является (хотя при пустующих 6 битах в его заголовке один-то можно было выделить на флаг подтверждения доставки).
[…] Сообщение с нулевой полезной нагрузкой может быть использовано в качестве подтверждения, о том, что базовая станция получила данные от абонентского устройства (acknowledgment).
Стандарт OpenUNB требует минимального количества энергии для пересылки одного бита информации. По результатам предварительных испытаний, сейчас это один из самых энергосберегающих протоколовAS: Спорное, ничем не подтвержденное утверждение. В протоколе присутствует как минимум несколько элементов, говорящих о его невысокой энергетической эффективности:
OpenUNB — универсальный открытый стандарт, абсолютно готовый к практическому применению.AS: Текст стандарта сырой, содержит отрывочные, неполные и неточные описания отдельных выколотых элементов, его применение на практике невозможно. В нем ничего нет о специфике работы ключевого элемента UNB-систем – приемнике базовой станции.
К сожалению, не доступен сервер mySQL