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