ГОСТ Р 70036-2022

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР 70036— 2022

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол беспроводной передачи данных на основе узкополосной модуляции радиосигнала (NB-Fi)

Издание официальное

Москва Российский институт стандартизации 2022

Предисловие

• 1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Телематические Решения» (ООО «Телематические Решения») и Ассоциацией участников рынка интернета вещей

• 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 «Кибер-физические системы»

• 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 марта 2022 г. № 118-ст

• 4 ВВЕДЕН ВПЕРВЫЕ

• 5 ДЕЙСТВУЕТ ВЗАМЕН ПНСТ 354—2019

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующие информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «РСТ», 2022

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

Содержание

• 1 Область применения

• 2 Нормативные ссылки

• 3 Термины и определения

• 4 Сокращения

• 5 Физический уровень (Physical layer)

• 5.1 Общие положения

• 5.2 UPLINK-пакет

• 5.3 DOWNLINK-пакет

• 5.4 Режим работы LBT (Listen Before Talk)

• 6 МАС-уровень (Media Access Control layer, MAC)

• 6.1 Общие положения

• 6.2 UPLINK-пакет

• 6.3 DOWNLINK-пакет

• 7 Транспортный уровень (Transport layer)

• 7.1 Общие положения

• 7.2 Описание функций транспортного уровня

• 7.3 Описание пакетов данных транспортного уровня

Приложение А (обязательное) Описание алгоритмов определения частоты приема и передачи

Приложение Б (справочное) Описание алгоритма компенсации нестабильности частот задающего генератора

Приложение В (справочное) Фрагменты исходных кодов реализации МАС-уровня

Приложение Г (обязательное) Защита данных в протоколе NB-Fi

Приложение Д (обязательное) Исходные коды программной реализации помехоустойчивого кодирования

Приложение Е (обязательное) Алгоритм определения преамбулы DOWNLINK-пакета

Приложение Ж (обязательное) Таблица и функции, используемые для ZIGZAG-кодирования данных

Приложение И (справочное) Описание системы, использующей протокол NB-Fi

Приложение К (обязательное) Фрагменты исходных кодов реализации для определения преамбулы DOWNLINK-пакета

Библиография

Введение

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

Беспроводные сети, построенные с применением стандарта NB-Fi, являются сетями класса LPWAN (Low-power Wide-area Network — энергоэффективная сеть дальнего радиуса действия), которые характеризуются высокой энергоэффективностью передачи данных и высокой емкостью сети, что позволяет использовать стандарт NB-Fi для построения телеметрических систем с большим количеством абонентов. Высокая энергоэффективность дает возможность применять в работе нелицензируе-мые диапазоны частот, в которых установлены ограничения на излучаемую передатчиками мощность. В основе стандарта лежит использование узкополосных фазоманипулированных сигналов, которые в сочетании с помехоустойчивым кодированием позволяют достигать очень высоких значений чувствительности приема, при этом суммарная полоса частот для одновременной передачи большого количества каналов является сравнительно узкой.

Сеть NB-Fi, по аналогии с мобильными сетями, использует топологию «звезда». В подобной архитектуре узловые элементы (базовые станции) должны осуществлять прием и передачу многих сигналов одновременно.

Для приема восходящих пакетов (UPLINK-пакетов) данных со стороны базовой станции применяется принцип SDR-систем (Software-Defined Radio — программно-определяемая радиосистема), где входной радиосигнал оцифровывается во всей полосе приема и в дальнейшем подвергается программной обработке. Это позволяет выполнять демодуляцию и декодирование входных пакетов данных одновременно по всем каналам во всей полосе частот. В данной системе не существует сетки каналов, пакет данных принимается базовой станцией вне зависимости от частоты, на которой выполнена отправка. Это является ключевым свойством стандарта, позволяющим использовать недорогие генераторы частоты для формирования радиосигнала. Ввиду применения простых видов модуляции UPLINK-пакеты могут быть сформированы при помощи практически любого серийного интегрального радиотрансивера. Прием UPLINK-пакетов возможен только базовой станцией. В связи с этим для реализации передачи пакетов данных в обратном, нисходящем (DOWNLINK), направлении, применяются виды модуляции и скорости передачи, поддерживаемые используемым радиотрансивером.

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

ГОСТ Р 70036—2022

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол беспроводной передачи данных на основе узкополосной модуляции радиосигнала (NB-Fi)

Information technology. Internet of things. Wireless protocol based on narrow band RF modulation (NB-Fi)

Дата введения — 2022—04—01

• 1 Область применения

В настоящем стандарте установлены требования к протоколу обмена для интернета вещей в узкополосном спектре (NB-Fi), включая требования:

• - к физическому уровню (раздел 5);

• - МАС-уровню (раздел 6);

• - транспортному уровню (раздел 7).

• 2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 14254 (IEC 60529:2013) Степени защиты, обеспечиваемые оболочками (Код IP)

ГОСТ Р 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ Р 34.13 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

• 3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

• 3.1 радиотрансивер: Интегральная схема, предназначенная для приема-передачи данных с использованием радиосигналов (в том числе посредством протокола NB-Fi).

Издание официальное

• 3.2 устройство приема-передачи данных/модем: Программно-аппаратный комплекс со встроенным радиотрансивером, являющийся либо самостоятельным оборудованием, либо встроенным компонентом в оконечное устройство, применяемый для приема или передачи данных с использованием радиотрансивера.

• 3.3 оконечное устройство: Оборудование с устройством приема-передачи данных (модемом).

• 3.4 базовая станция NB-Fi: Программно-аппаратный комплекс, обеспечивающий прием и передачу данных посредством радиосигналов от оконечных устройств, работающих по протоколу NB-Fi, с одной стороны, и взаимодействие с сервером NB-Fi с использованием широкополосного канала связи, с другой стороны.

• 3.5 сервер NB-Fi: Программно-аппаратный комплекс, являющийся центральным узлом, выполняющим информационное взаимодействие со множеством оконечных устройств по протоколу транспортного уровня NB-Fi с использованием распределенной сети базовых станций NB-Fi.

• 3.6 пакет восходящего направления (UPLINK-пакет): Пакет данных, передаваемый устройствами и принимаемый базовыми станциями.

• 3.7 пакет нисходящего направления (DOWNLINK-пакет): Пакет данных, передаваемый передатчиком базовой станции и принимаемый устройствами.

• 4 Сокращения

В настоящем стандарте применены следующие сокращения:

«Магма» — алгоритм симметричного блочного шифрования согласно ГОСТ Р 34.12;

ОФМн-2 — относительная двоичная фазовая манипуляция несущей;

ФМн-2 — двоичная фазовая манипуляция несущей;

ЧМн — частотная манипуляция несущей;

LBT — режим прослушивания перед излучением (Listen Before Talk);

CRC — циклический избыточный код (Cyclic Redundancy Check);

LPWAN — энергоэффективные сети связи дальнего радиуса действия (Low-power Wide-area network).

• 5 Физический уровень (Physical layer)

  • 5.1 Общие положения

Физический уровень обеспечивает механизм приема-передачи произвольной информации по среде распространения. В данном разделе установлены требования к техническим характеристикам физического уровня для двух типов пакетов данных:

• - UPLINK-пакет (см. 5.2);

• - DOWNLINK-пакет (см. 5.3).

• 5.2 UPLINK-пакет

UPLINK-пакет представляет собой модулированные последовательности двоичных данных, сгруппированных в байты.

Описание UPLINK-пакета приведено в таблице 1. Значения параметров, приведенных в таблице 1, определены для диапазона рабочих температур от минус 40 °C до плюс 70 °C.

Таблица 1 — Основные технические характеристики UPLINK-пакета

Окончание таблицы 1

• 5.3 DOWNLINK-пакет

DOWNLINK-пакет представляет собой модулированные последовательности двоичных данных, сгруппированных в байты.

Описание DOWNLINK-пакета приведено в таблице 2. Значения параметров, приведенных в таблице 2, определены для диапазона рабочих температур от минус 40 °C до плюс 70 °C.

Таблица 2 — Основные технические характеристики DOWNLINK-пакета

Окончание таблицы 2

• 5.4 Режим работы LBT (Listen Before Talk)

При включенном режиме работы LBT (Listen Before Talk — режим прослушивания перед излучением) устройство, прежде чем выполнить переход в режим передачи для отправки пакетов, должно переключиться в режим оценки уровня сигнала в полосе частот, в котором предполагается отправка данных. Если уровень сигнала не превышает установленного значения, что означает отсутствие передачи другим устройством, то переход в режим передачи и отправка данных могут быть выполнены. В противном случае устройство не должно выполнять передачу до тех пор, пока уровень сигнала в данной полосе частот не упадет ниже установленного значения. Для включения/выключения режима работы LBT необходимо использовать конфигурационный флаг транспортного уровня FLG_LBT [см. 7.3.2.7, перечисление п)].

• 6 МАС-уровень (Media Access Control layer, MAC)

  • 6.1 Общие положения

МАС-уровень обеспечивает передачу датаграммы (информационного пакета) на выбранном физическом уровне и описывает следующие параметры:

• - формат полей пакета;

• - способы адресации;

• - методы защиты данных;

• - методы контроля целостности данных;

• - методы восстановления ошибок.

Описание МАС-уровня приведено в таблице 3.

Таблица 3 — Основные технические характеристики МАС-уровня

6.2 UPLINK-пакет

Общая длина UPLINK-пакета должна составлять 36 байт. Размер поля Payload (данные транспортного уровня) должен составлять 9 байт. Программный код реализации функции формирования UPLINK-пакета на языке Си приведен в В.1 приложения В.

Формат UPLINK-пакетов одинаков для различных скоростей передачи данных. Порядок следования битов в байтах UPLINK-пакета — от старшего к младшему.

Структура формата UPLINK-пакета приведена в таблице 4.

Таблица 4 — Структура формата UPLINK-пакета

• 6.2.1 Поле Preamble (Преамбула)

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

• 6.2.2 Поле Modem_ID (Идентификатор, присвоенный устройству)

Поле ModemJD содержит идентификатор, присвоенный устройству. Поле ModemJD должно иметь размер 32 бита (номерная емкость сети составляет 232, т. е. 4 294 967 296 устройств). Порядок следования байт — от старшего к младшему.

• 6.2.3 Поле Crypto Iter (Криптоитератор)

Поле Crypto Iter используется для реализации механизма защиты данных. Поле Crypto Iter должно иметь размер 8 бит. Формирование поля Crypto Iter (криптоитератора) должно выполняться в соответствии с алгоритмом, описанным в Г.2 приложения Г.

• 6.2.4 Поле Payload (Данные транспортного уровня)

Поле Payload должно иметь размер 9 байт. Данное поле должно содержать зашифрованное значение пакета данных транспортного уровня. Поле Payload должно быть зашифровано в соответствии с алгоритмом, описанным в Г.З приложения Г.

• 6.2.5 Поле М1С0_7 (Имитовставка)

Поле М1С0_7 используется для реализации механизма защиты данных. Поле М1С0_7 должно иметь размер 24 бита. Формирование поля М1С0_7 должно выполняться в соответствии с алгоритмом, описанным в Г.4 приложения Г.

• 6.2.6 Поле Packet CRC (Контрольная сумма пакета данных)

Поле Packet CRC содержит контрольную сумму CRC32 полей ModemJD, Crypto Iter, Payload и MIC0_7 (с 1-го по 17-й байт поля Error correction code source). Используются три младших байта данного значения. Порядок следования байт — от старшего к младшему. Программный код реализации функции вычисления данного параметра (CRC32) на языке Си приведен в В.5 приложения В.

• 6.2.7 Поле Error correction code (Помехоустойчивый код)

Поле Error correction code является кодовым словом помехоустойчивого кода для коррекции ошибок и должно вычисляться из данных поля Error correction code source.

Поле Error correction code source (входные данные для кодера помехоустойчивого кода) совместно составляют поля ModemJD, Crypto Iter, Payload, MIC0_7 и Packet CRC.

Могут использоваться два различных помехоустойчивых кода:

• - несистематический сверточный код (255, 363) [1], из которого с помощью метода выкалывания получен код скорости 5/8. Исходные коды кодирования и метода выкалывания приведены в Д.1 приложения Д. Базовая станция должна принимать из радиоэфира сообщения, отправленные с использованием данного кода;

• - несистематический полярный код [2] скорости 5/8. При использовании такого кода данные не передаются в канале в явном виде, кодовое слово длиной 32 байта вычисляется на основании поля Error correction code source длиной 20 байт и передается в канал. Используемые таблицы данных для кодирования, а также исходные коды программной реализации помехоустойчивого кодирования на языке Си приведены в Д.2 приложения Д. Поддержка декодирования кода со стороны базовой станции необязательна.

• 6.3 DOWNLINK-пакет

Общая длина DOWNLINK-пакета должна составлять 36 байт. Размер поля Payload (данные транспортного уровня) должен составлять 9 байт. Программный код реализации функции формирования DOWNLINK-пакета на языке Си приведен в В.2 приложения В.

Формат DOWNLINK-пакетов одинаков для различных скоростей передачи данных. Порядок следования битов в байтах DOWNLINK-пакета — от старшего к младшему.

Структура формата DOWNLINK-пакета приведена в таблице 5.

Таблица 5 — Структура формата DOWNLINK-пакета

• 6.3.1 Поле Preamble (Преамбула)

Преамбула служит для обнаружения пакета в эфире. Значение данного поля должно быть сформировано в соответствии с алгоритмом, приведенным в приложении Е.

• 6.3.2 Поле Crypto Iter (Криптоитератор)

Поле Crypto Iter используется для реализации механизма защиты данных. Поле Crypto Iter должно иметь размер 8 бит. Формирование поля Crypto Iter (криптоитератора) должно выполняться в соответствии с алгоритмом, описанным в Г.2 приложения Г.

• 6.3.3 Поле Payload (Данные транспортного уровня)

Поле Payload должно иметь размер 9 байт. Данное поле должно содержать зашифрованное значение пакета данных транспортного уровня. Поле Payload должно быть зашифровано в соответствии с алгоритмом, описанным в Г.З приложения Г.

• 6.3.4 Поле М1С0_7 (Имитовставка)

Поле М1С0_7 используется для реализации механизма защиты данных. Поле М1С0_7 должно иметь размер 24 бита. Формирование поля М1С0_7 должно выполняться в соответствии с алгоритмом, описанным в Г.4 приложения Г.

• 6.3.5 Поле Packet CRC (Контрольная сумма пакета данных)

Поле Packet CRC содержит контрольную сумму CRC32 полей Crypto Iter, Payload и MIC0_7 (с 5-го по 17-й байт DOWNLINK-пакета). Используются три младших байта данного значения. Порядок следования байт — от старшего к младшему. Программный код реализации функции вычисления данного параметра (CRC32) на языке Си приведен в В.5 приложения В.

• 6.3.6 Поле Error correction code (Помехоустойчивый код)

Поле Error correction code является кодовым словом помехоустойчивого кода для коррекции ошибок и должно вычисляться из данных поля Error correction code source.

Поле Error correction code source (входные данные для кодера помехоустойчивого кода) совместно составляют поля Crypto Iter, Payload, MIC0_7 и Packet CRC.

Для помехоустойчивого кодирования используется Zigzag код [3].

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

• 7 Транспортный уровень (Transport layer)

• 7.1 Общие положения

Транспортный уровень обеспечивает механизмы приема и передачи данных уровня приложения и управляющих команд между оконечным устройством NB-Fi и сервером NB-Fi (используя базовые станции NB-Fi) либо между двумя оконечными устройствами NB-Fi.

Транспортный уровень описывает следующие функции:

• - подтверждения доставки сообщений;

• - повторной отправки данных;

• - разбиения больших пакетов данных на фрагменты и последующего их «склеивания»;

• - буферизации отправки данных;

• - синхронизации системного времени;

• - конфигурирования режимов работы;

• - автоматического выбора режима работы (скорости, мощности передачи);

• - автоматического перехода на более предпочтительные рабочие диапазоны частот.

Ключевые особенности транспортного уровня NB-Fi, позволяющие протоколу в наибольшей степени соответствовать задачам построения LPWAN-сетей:

• - низкое количество «накладных» данных, используемых для транспортного уровня;

• - организация группового квитирования пакетов, позволяющая экономить использование канала связи при подтверждении приема;

• - реализация специальных режимов работы для устройств с батарейным питанием.

Для передачи данных от устройства к базовой станции должны использоваться UPLINK-пакеты. Для передачи данных от базовой станции к устройству должны использоваться DOWNLINK-пакеты. Допускается работа в режиме передачи данных от устройства к устройству (режим «peer-to-peer»), при этом должны использоваться DOWNLINK-пакеты для передачи в обоих направлениях.

Реализация функций транспортного уровня предполагает буферизацию пакетов данных в виде программного стека. Глубина приемного буфера должна составлять 32 пакета. Это обусловлено разрядностью поля ITER (итератор), равной 5 бит, которое должно использоваться для циклической нумерации всех пакетов и их последующей идентификации при запросах повторной отправки. Таким образом, передающий узел должен хранить 32 последних отправленных пакета для их возможной переотправки при последующем обмене данными.

• 7.2 Описание функций транспортного уровня
  
  7.2.1 Режимы работы

  Основные режимы работы транспортного уровня NB-Fi и их описание приведены в таблице 6.

Таблица 6 — Основные режимы работы транспортного уровня (параметр NBFI_MODE)

Режимы подтверждения доставки данных и их описание приведены в таблице 7.

Таблица 7 — Режимы подтверждения доставки данных (параметр NBFI_HANDSHAKE_MODE)

Режимы группового подтверждения доставки данных и их описание приведены в таблице 8.

Таблица 8 — Режимы группового подтверждения доставки данных (параметр NBFI_MACK_MODE)

• 7.2.2 Обеспечение надежности доставки данных в режимах CRX и DRX

Для обеспечения надежности доставки данных должна применяться отправка пакетов в режиме HANDSHAKE_SIMPLE. Отправка должна выполняться посредством сеансов обмена данными между передающим и приемным узлами. При отправке пользовательских пакетов (длина данных составляет 8 байт), количество пакетов, входящих в сеанс отправки, должно определяться параметром МАСК. Значения МАСК более единицы позволяют уменьшить количество отправляемых пакетов подтверждения приема. При групповой отправке количество пакетов, входящих в сеанс отправки, должно быть равно количеству пакетов в группе. Каждый отправляемый пакет должен содержать в своем заголовке HEADER поле ITER, которое должно инкрементироваться для каждого последующего пакета. Значения поля ITER должно изменяться в диапазоне 0—31. Передающий узел (устройство или сервер), выполняя отправку последнего пакета из группы, должен выставлять в нем флаг АСК в заголовке пакета. Данный флаг сигнализирует приемной стороне, что необходимо отправить в ответ системный пакет АСК_Р.

АСК_Р должен содержать 32-битную маску, каждый бит которой должен содержать информацию об успешном приеме пакета с номером итератора, соответствующим позиции бита в маске. Формат пакета АСК_Р описан в 7.3.2.2.

Передающий узел должен обработать АСК_Р пакет и повторно отправить один или несколько пакетов, которые не были доставлены и которые соответствуют данному сеансу отправки.

Если передающий узел не получил АСК_Р пакет в ответ на запрос, он должен повторить отправку последнего пакета по истечении заданного интервала времени (тайм-аута) NBFI_RX_TIMEOUT.

При значении параметра WAIT_ACK_TIMEOUT [см. 7.3.2.7, перечисление ш)], не равном 0, NBFI_ RX_TIMEOUT = WAIT_ACK_TIMEOUT.

При значении параметра WAIT_ACK_TIMEOUT, равном 0, NBFI_RX_TIMEOUT должен вычисляться по следующей формуле:

NBFI_RX_TIMEOUT = NBFI_UL_DELAY + NBFI_DL_LISTEN_TIME +random()%NBFI_DL_ADD_RND_LISTEN_TIME. (1)

Параметры NBFI_UL_DELAY, NBFI_DL_LISTEN_TIME и NBFI_DL_ADD_RND_LISTEN_TIME должны зависеть от выбранных режимов скорости передачи данных. Их значения приведены в таблицах 9—11.

Таблица 9 — Значение параметра NBFI_UL_DELAY в зависимости от режима скорости передачи данных

Таблица 10 — Значение параметра NBFI_DL_LISTEN_TIME в зависимости от режима скорости передачи данных

Таблица 11 — Значение параметра NBFI_DL_ADD_RND_LISTEN_TIME в зависимости от режима скорости передачи данных

Повторные отправки пакетов должны выполняться до тех пор, пока не будет получен ответ либо не будет превышено число повторных отправок, заданное параметром NUM_OF_RETRIES [см. 7.3.2.7, перечисление г)]. Повторная отправка пакетов, вызванная получением АСК_Р пакета, также должна входить в расчет общего числа повторов и быть ограничена параметром NUM_OF_RETRIES.

В случае успешной отправки всех пакетов, входящих в сеанс, передающий узел должен отправить системный пакет CLEAR (см. 7.3.2.6) (либо CLEAR_T [см. 7.3.2.9]), информирующий приемный узел, что все данные переданы и необходимо выполнить очистку истории принятых данных.

При неуспешном выполнении сеанса отправки данных от устройства к серверу передающий узел должен выполнить сброс всех параметров работы NB-Fi к значениям по умолчанию и отослать системный пакет SYNC (см. 7.3.2.11), уведомляющий приемный узел о смене режима работы. Должна быть реализована возможность отключения сброса параметров и отправки SYNC-пакета при помощи флага FLG_NO_RESET_TO_DEFAULTS, содержащегося в параметре NBFI_ADDITIONAL_FLAGS.

На рисунке 1 приведен пример успешной отправки группового пакета1. В рамках данного сеанса выполнена отправка трех пакетов с итераторами 14—16. В ответ на пакет с итератором 16, содержащий флаг АСК, сервер отправил АСК_Р пакет с маской, сообщающей, что сообщения с итераторами 14— 16 успешно приняты. Приняв данный пакет, передающий узел отправил CLEAR_T-naKeT, означающий успешное завершение сеанса и содержащий информацию о текущем времени устройства.

7F03FF)8324095) UL S-M - 14 • 020F67EE00133013 - BS9450 - 16 - UL_DBPSK_25600_PROT_E - New group, clear processed packets, 14 bytes

7F03FFI8324O95) UL --M - 15 - 60007F03FFO82AD1 - BS9450 - 17 - UL_DBPSK_25600_PROT_E

7F03FF(8324O95) UL -AM - 16 - C300D73F01080B17 - BS9450 - 17 - UL_DBPSK_256O0_PROt2e - EE00133ei360007Fe3FF0B2AOlC3

7F03FF(8324095) DL S-- - 16 - 0000000003110000 - BS9450 - - DL_D8PSK_25600_PR0T_D - Acked [16, 15, 14], SNR 17, PWR 23dBm, LOW

7F03FF(8324O95) UL S-- - 16 - 0862AE4C5F2C208F - BS8957 - 33 - UL_DBPSK_25600_PROT_E - OK, server clears UL history, DL_SNR 44, Noise -118, DT: 31.08.2020 11:01:38

Рисунок 1 — Пример успешной отправки группового пакета

На рисунке 2 приведен пример успешной отправки группового пакета с повторной отправкой пакетов. Групповой пакет, состоящий из пакетов с итераторами 26—28, был доставлен в результате следующих шагов:

• а) из трех пакетов, составляющих группу, был принят только пакет с итератором 28, который является завершающим и требующим подтверждения. Сервер отправил АСК_Р пакет, подтверждающий прием только пакета с итератором 28;

• б) передающий узел, получив АСК_Р пакет, отправил повторно пакеты с итераторами 26 и 27, запросив последним пакетом подтверждение доставки;

• в) из двух отправленных пакетов сервер принял только последний пакет с итератором 27 и отправил в ответ АСК Р пакет, подтверждающий прием пакетов с итераторами 27 и 28;

• г) передающий узел, получив АСК_Р пакет, отправил повторно пакет с итератором 26, запросив подтверждение доставки;

• д) сервер получил пакет с итератором 26, успешно сформировал групповой пакет и отправил устройству АСК_Р пакет, подтверждающий прием данного пакета;

• е) приняв данный пакет, передающий узел, отправил CLEAR_T-naKeT, означающий успешное завершение сеанса и содержащий информацию о текущем времени устройства.

  7F08D1(8325329) UL -АМ -

  7F08Dl(8325329) DL S-- -

  7F08D1(8325329) UL -АМ -

  7F08D1(8325329) DL S-- -

  7F08DK8325329) UL SAM -

  7F08DK8325329) DL S-- -

  7F08D1(8325329) UL S-- -

  
  

  C3O03F4001O88E17 - BS9394 • 0OOO00000O1EO0OO - BS9394 -6O0O7FO8D10C17D1 - BS9394 -004000000O1E0000 - BS9394 -Q20F8DEE00133G13 - BS9394 -

  0000000000210000 - BS9394 -08BCB24C5F19208C - BS9394 -

  
  

  30 • UL_D8PSK_256O0_PROT_E

  - DL_DBPSK_256O0_PROT_D

  30 - UL_DBPSK_25600_PROT_E

  - DL_D8PSK_25600_PR0T_D

  33 - UL_DBPSK_256G0_PROT_E

  - DL_DBPSK_25600_PR0T_D

  30 - UL_DBPSK_25600_PROT_E

  
  

  Acked (28], SNR 30, PWR 20dBm, LOW

  Acked [27, 28], SNR 30, PWR 20dBm, LOW

  EE0813301360807FO8D10C17D1C3

  Acked [26], SNR 33, PWR 20dBm, LOW

  OK, server clears UL history, DL_SNR 25, Noise -118, DT: 31.08.2020 11:20:12

  
  

Рисунок 2 — Пример успешной отправки группового пакета с повторной отправкой пакетов

В режиме работы HANDSHAKE_NONE передающий узел не выполняет запрос АСК_Р пакетов, и передача данных в этом случае выполняется без контроля успешной доставки (верификации).

• 7.2.3 Передача групповых пакетов

Пакеты данных большой длины (не умещающиеся в одном пакете МАС-уровня) должны быть отправлены при помощи группы пакетов. Максимальное число пакетов в группе должно быть равно 31, и длина поля DATA (Данные) должна составлять не более 240 байт (см. 7.3.2.4).

Возможность групповой отправки данных должна быть реализована как в режимах работы с верификацией доставки данных, так и без нее. Первый пакет в группе должен являться системным пакетом типа GROUP и содержать информацию об общей длине группы, а также контрольной сумме данных, содержащихся в группе. Размер контрольной суммы должен составлять 1 байт. Каждый пакет группы должен содержать флаг MULTI в своем заголовке. На приемной стороне должна выполняться обработка входных пакетов и «склеивание» пакетов в один блок данных.

Формат пакета GROUP приведен в 7.3.2.4.

Программный код реализации функции вычисления контрольной суммы CRC8 на языке Си приведен в В.З приложения В.

• 7.2.4 Передача коротких пакетов (длиной менее 8 байт)

Пакеты, имеющие длину менее 8 байт, должны отправляться при помощи системных SHORT пакетов. Длина полезных данных должна быть указана в младших 7 битах первого байта данных SHORT пакета. Данный параметр должен иметь значения от 7 до 127. Формат SHORT пакета приведен в 7.3.2.1.

• 7.2.5 Разрешение коллизий одновременной передачи

Базовые станции стандарта NB-Fi должны выполнять одновременный прием множества каналов. Это позволяет не учитывать при реализации транспортного уровня коллизии, вызванные одновременной передачей пакетов различными устройствами.

Так как оконечные устройства NB-Fi работают в режиме «полудуплекс», выполняя единовременно либо прием, либо передачу данных, возможно возникновение коллизий в тот момент, когда базовая станция и устройство выполняют встречную передачу пакетов.

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

• а) при отправке очередного пакета данных передающая сторона должна всегда выставлять в заголовке пакета флаг MULTI в том случае, если вслед за данным пакетом планируется отправка следующего. Приемная сторона, принимая пакет с флагом MULTI, должна продолжать выполнять прием и не выполнять передачу до получения пакета без флага MULTI либо до истечения заданного интервала времени (тайм-аута) NBFI_DL_LISTEN_TIME. Величина данного тайм-аута должна различаться для разных скоростей приема и соответствовать значениям, приведенным в таблице 10;

• б) при повторных отправках пакетов по причине неполучения АСК_Р пакета в ответ на запрос флага АСК используемый тайм-аут должен иметь различные значения от повтора к повтору. Это позволяет избежать циклического повторения коллизии из-за постоянства значений тайм-аутов. Переменная составляющая тайм-аута повторов определяется параметром NBFI_DL_ADD_RND_LISTEN_TIME. Величина данного тайм-аута должна различаться для разных скоростей приема и соответствовать случайному числу в диапазоне от 0 до значения, приведенного в таблице 11.

• 7.2.6 Автоматический выбор оптимальной скорости передачи данных

Устройства, работающие в режимах DRX и CRX, должны выполнять автоматический контроль качества радиосигнала (как приема, так и передачи) и производить смену скоростей передачи данных, опираясь на средние значения соотношений сигнал/шум (SNR) для UPLINK и DOWNLINK-пакетов.

Расчет SNR на входе приемника устройства должен выполняться при приеме пакетов, используя данные, предоставляемые аппаратурой радиотрансивера, входящего в состав устройства. Расчет SNR передаваемого сигнала должен выполняться на основании данных, которые измеряет базовая станция на входе своего приемника и которые передаются устройству в одном из полей АСК_Р пакета.

Решения о смене скорости передачи данных UPLINK-пакетов либо DOWNLINK-пакетов должно принимать оконечное устройство, анализируя уровни SNR.

При достаточно высоком значении SNR (>SNRLEVEL_FOR_UP + TXSNRDEG либо >SNRLEVEL_ FOR_UP + RXSNRDEG) устройство должно выполнять перевод скорости на один уровень выше. Так как базовая станция принимает одновременно все поддерживаемые скорости передачи UPLINK-пакетов, смена скоростей UPLINK должна осуществляться без уведомления сервера. При смене скорости DOWNLINK-пакетов устройство должно выполнять отправку системного SYNC пакета, содержащего новые параметры скоростного режима. Данный пакет должен формироваться с флагом АСК и требовать подтверждения приема. В ответ на данный системный пакет сервер должен отправлять 5АСК_Р-пакет (см. 7.3.2.5). Прием пакета SACK_P устройство должно выполнять уже на новой скорости. В отсутствие ответного пакета от сервера устройство должно выполнять повторные отправки SYNC пакетов. Если после определенного числа повторных попыток доставки SYNC пакета, равного NUM_OF_RETRIES, пакет SACK_P так и не был получен, устройство должно возвращать свой скоростной режим в предыдущее состояние, отсылая SYNC пакет, содержащий предыдущие значения параметров скорости. В этот раз SYNC пакет должен отсылаться единожды без запроса подтверждения.

Повышение скорости UPLINK либо DOWNLINK должно выполняться при условии, что базовая станция поддерживает более высокие скоростные режимы. Об этом сервер должен уведомлять устройство, выставляя флаги UL_SPEED_NOT_MAX и DL_SPEED_NOT_MAX, содержащиеся в пакете SACK_P.

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

Если при достижении максимального уровня скорости передачи UPLINK-пакетов уровень SNR имеет достаточное значение (>SNRLEVEL_FOR_UP + TXSNRDEG), устройство должно выполнять постепенное (с шагом 3 дБ) снижение мощности передатчика.

Если при достижении максимального уровня скорости приема DOWNLINK-пакетов уровень SNR имеет достаточное значение (>SNRLEVEL_FOR_UP + RXSNRDEG), устройство должно уведомить сервер о необходимости снижения выходной мощности передатчика базовой станции, выставляя флаг DL_POWER_STEP_DOWN в пакете АСК_Р, отправляемом от устройства к серверу.

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

Для уведомления сервера о необходимости повышения выходной мощности должен использоваться флаг DL_POWER_STEP_UP в пакете АСК_Р, отправляемом от устройства к серверу.

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

Таблица 12 — Пороговые уровни для повышения и понижения скоростей либо мощности

Таблица 13 — Значение поправочного коэффициента TXSNRDEG для различных скоростей передачи

Таблица 14 — Значение поправочного коэффициента RXSNRDEG для различных скоростей приема

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

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

Сервер, отправляя пакет SACK_P, имеет возможность сообщить устройству о необходимости изменения параметра FPLAN, определяющего частотную сетку каналов приема и передачи. Алгоритм определения частоты приема и передачи для оконечного устройства описан в приложении А. Изменяя значение параметра FPLAN, сервер может переключить устройство на работу в другой, более предпочтительной полосе прима и/или передачи.

Пакет SACK_P также содержит значение идентификатора базовой станции, через которую осуществляется обмен данными с сервером, либо значение идентификатора сервера, с которым осуществляется обмен. В случае если сервер выполняет изменение параметра FPLAN, SACK_P пакет должен содержать идентификатор базовой станции, в противном случае — идентификатор сервера.

На рисунке 3 приведен пример сеанса обмена пакетами, выполняющий повышение скоростей передачи и приема2.

7F03FF18324O95) DL S-- - 23 - 00000003FF3A00C0 • BS8957 - - DL_DBPSK_4O0_PROT_D - Acked [23, 22, 21, 20, 19, 18, 17, 16, IS, 14, 13], SNR S8, PWR 26dBm, LOW

7F03FF(8324095) UL S-M - 23 - 08E4C94C5F330E0F ■ BS89S7 - 58 - UL OBPSK 3200 PROT E ■ OK, server clears UL history, DL SNR 51, Noise -136, 0T: 31.08.2020 12:59:00

7F03FF(8324095) UL SA- - 24 - OA2A20OC6OOOOO01 - BS8957 - 48 - UL J>BPSk232O0 J>R0tIe - Mode: CRX NB-Fi v5, PHY: UL_0BPSK_3200_PR0T_E «. DL_OBPSK_32O0_PROT_O FPLAN:38460 CIOL: 2xx

7F03FF(8324095) OL S-- - 24 - 031O0822FO3000C0 - BS8957 • ■ DL_O8PSK_3200_PROT_O • Acked [24], SNR 48 FPLAN:NOCHANGE BS_IO 8957, PWR 26dBm, LOW

7F03FFI8324095) UL SA- - 24 - OA2A210C60000002 - BS8957 - 45 - UL_DBPSK_256O0_PROT_E - Mode: CRX NB-Fi v5, PHY: UL_0BPSK_25600_PR0T_E & DL_DBPSK_320O_PROT_D FPLAN:384&0 CIOL: 3xx

7F03FF(8324O95) DL S-- - 24 - 03100822F0200040 • BS8957 - - OL OBPSK 3200 PROT 0 - Acked [24], SNR 45 FPLAN:NOCHANGE BS 10 8957, PWR 26dBm, LOW

7F03FFI8324095) UL SA- - 24 - 0A2A210060000003 ■ BS8957 - 40 - UL DBPSK_25600~PROT-E ■ Mode: CRX NB-Fi v5, PHY: UL OBPSK 25600 PROT E & OL OBPSK 25600 PROT 0 FPLAN:38440 CIOL: 4xx

7F03FF(8324095) DL S-- - 24 - O31O0822FO28OOOO - BS8957 - - 0L_DBPSK_25600_PR0T 0 - Acked [24], SNR 40 FPLAN:NOCHANGE BS_ID 8957, PWR 26dBm, LOW___________________________________

Рисунок 3 — Пример сеанса обмена пакетами, выполняющий повышение скоростей передачи и приема

• 7.2.7 Работа в режиме DRX

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

Отличие от режима CRX состоит в том, что устройство должно кратковременно переходить в режим приема сразу после окончания передачи последнего пакета из группы пакетов, отправляемых непрерывно друг за другом. Сервер должен выполнять отправку данных только во время действия данного «временного окна», длительность определяется параметром NBFI_RX_TIMEOUT (см. 7.2.2).

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

Сеанс отправки данных от устройства к серверу должен выполняться в полном объеме до подтверждения приема всех пакетов. Следующий за ним сеанс отправки данных от сервера к устройству может быть прерван из-за потерь данных при плохом уровне сигнала и затем должен быть продолжен при следующем «выходе устройства на связь».

• 7.2.8 Синхронизация системного времени

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

• - оконечное устройство, выполнив отправку данных и получив пакеты, подтверждающие их доставку, должно отправить системный пакет CLEAR_T, информирующий приемный узел (сервер) о том, что все данные переданы и можно выполнить очистку истории принятых данных. Помимо этого, в данном пакете должно содержаться значение текущего (на момент отправки пакета) времени системных часов передающего узла (устройства). Время должно передаваться в виде 4-байтного значения, соответствующего формату времени Unix Timestamp (количество секунд от 1 января 1970 года) и часовому поясу UTC. Формат пакета CLEAR_T описан в 7.3.2.9;

• - сервер должен сравнить полученное время с собственным системным временем и в том случае, если разница превышает значение 8191 с, отослать системный пакет SENDTIME, содержащий значение текущего времени в формате Unix Timestamp. Пакет отсылается без запроса подтверждения. Формат пакета SENDTIME описан в 7.3.2.10.

Если разница не превышает значение 8191 с, но более 5 с, то сервер должен сохранить это значение и при следующем сеансе обмена выполнить коррекцию системного времени устройства, отправив величину данной поправки внутри пакета АСК_Р. Формат пакета АСК_Р описан в 7.3.2.2.

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

• 7.2.9 Конфигурирование параметров NB-Fi

Режимы функционирования протокола NB-Fi конкретного устройства должны определяться совокупностью параметров NB-Fi.

Все параметры NB-Fi устройства должны быть доступны для чтения и записи при помощи системных CONF-пакетов. Формат данных пакетов и наименование параметров описаны в 7.3.2.7.

• 7.2.10 Идентификация типа устройства

Для идентификации типа устройства должны быть использованы три идентификатора размером 16 бит:

• - идентификатор производителя;

• - идентификатор устройства — параметр, определяющий тип устройства;

• - идентификатор протокола — параметр, однозначно определяющий формат данных и логику работы устройства на уровне приложения.

Присвоение идентификаторов устройствам должны выполнять производители устройств.

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

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

Отправка идентификаторов типа устройства должна осуществляться при помощи CONF-пакета с полем данных APP_IDS [см. 7.3.2.7, перечисление х)].

Сервер NB-Fi должен использовать данные идентификаторы для передачи их вместе со всеми принятыми от устройства ULAPP-пакетами на уровень приложения, где в зависимости от значения идентификаторов будет определяться, поддерживается ли данное устройство и каким образом необходимо выполнять взаимодействие с данным устройством.

• 7.2.11 Работа в режиме «peer-to-peer»

Данный режим предполагает реализацию обмена данными напрямую между двумя оконечными устройствами без участия базовых станций и сервера NB-Fi.

В режиме «peer-to-peer» для передачи данных в обоих направлениях должны быть использованы DOWNLINK-пакеты.

Параметры скоростей приема и передачи, мощности передачи и значение параметра FPLAN должны быть неизменны на протяжении всей работы в режиме «peer-to-peer».

При соединениях в режиме «peer-to-peer» периодическая смена ключей шифрования не осуществляется. Описание защиты данных при работе в данном режиме приведено в Г.2 приложения Г.

Для работы в режиме «peer-to-peer» необходимо включить флаги FLG_SHORT_RANGE_CRYPTO, FLG_FIXED_BAUD_RATE, FLG_NO_RESET_TO_DEFAULTS [см. 7.3.2.7, перечисление п)].

• 7.3 Описание пакетов данных транспортного уровня
  
  7.3.1 Формат пакета транспортного уровня

  Структура формата пакета транспортного уровня приведена в таблице 15.

Таблица 15 — Структура формата пакета транспортного уровня

Описание полей:

• - SYS — флаг системного пакета;

• - АСК — флаг, информирующий о том, что данный пакет требует подтверждения;

• - MULTI:

• 1) флаг групповой посылки,

• 2) флаг, информирующий приемную сторону о том, что непосредственно вслед за данным пакетом будет отправлен следующий;

• - ITER — итератор пакета;

• - DATA— поле данных пакета.

Пакеты транспортного уровня разделяются на:

• - пользовательские пакеты;

• - системные пакеты.

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

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

Данные уровня приложения длиной более 8 байт передаются путем дробления на пакеты транспортного уровня и объединения их в групповую посылку. При этом первый пакет в группе является системным (GROUP), а остальные — пользовательскими.

Данные уровня приложения, длина которых меньше 8 байт, передаются внутри системного (SHORT) пакета.

Структура формата пользовательского пакета приведена в таблице 16, структура формата системного пакета — в таблице 17.

Таблица 16 — Структура формата пользовательского пакета

Таблица 17 — Структура формата системного пакета

Описание полей:

• - SYS — флаг системного пакета;

• - АСК — флаг, информирующий о том, что данный пакет требует подтверждения;

• - MULTI:

• 1) флаг групповой посылки,

• 2) флаг, информирующий приемную сторону о том, что за данным пакетом будет отправлен другой;

• - ITER — итератор пакета;

• - DATA— поле данных пакета;

• - TYPE — тип системного пакета;

• - PAYLOAD — полезные данные пользовательского пакета;

• - SYS_PAYLOAD — полезные данные системного пакета.

• 7.3.2 Типы системных пакетов

Основные типы системных пакетов, используемые в протоколе NB-Fi, приведены в таблице 18.

Таблица 18 — Основные типы системных пакетов

• 7.3.2.1 Пакет SHORT (короткий пакет данных)

Данный системный пакет предназначен для передачи пользовательских данных длиной менее 8 байт.

Структура формата пакета SHORT приведена в таблице 19.

Таблица 19 — Структура формата пакета SHORT

• 7.3.2.2 Пакет АСК_Р (подтверждение приема пакетов)

Данный системный пакет предназначен для подтверждения приема одного или нескольких пакетов данных.

Структура формата пакета АСК_Р приведена в таблице 20.

Таблица 20 — Структура формата пакета АСК_Р

• a) MASK

Структура формата поля MASK приведена в таблице 21.

Таблица 21 — Структура формата поля MASK

Примечание — /-итератор АСК_Р пакета равен итератору принятого пакета, в ответ на который отправлен АСК_Р.

Статус сообщения с текущим итератором / не включен в маску, так как факт получения пакета АСК_Р подтверждает успешность доставки пакета с текущим итератором.

• б) SNR (Соотношение сигнал/шум пакета)

Соотношение сигнал/шум пакета, в ответ на который отправлен АСК_Р, используют для оценки качества связи при автоматическом выборе скорости и мощности передатчика. Допустимые значения — от 0 до 127 дБ.

• в) NOISE_OR_RTC_OFSO_7 (Уровень входного шума либо 8 младших бит поправки времени)

В данном поле передается уровень входного шума NOISE либо 8 младших бит поправки времени RTC_OFS_0_7. Первый вариант используется при передаче от устройства к серверу в качестве дополнительной информации; второй вариант — при передаче от сервера к устройству в случае применения механизма коррекции времени. Допустимые значения — от 0 до 255. Данные значения соответствуют уровням шума от минус 150 до плюс 105 дБм либо 8 младшим битам 14-битной поправки времени. Значение поля, равное 0 означает отсутствие необходимости коррекции времени.

• г) MFLAGS

Структура формата поля MFLAGS при передаче АСК_Р от сервера к устройству приведена в таблице 22.

Таблица 22 — Структура формата поля MFLAGS при передаче АСК_Р от сервера к устройству

UL_SPEED_NOT_MAX уведомляет устройство о том, что текущая скорость передачи UPLINK-пакетов является немаксимальной для данной базовой станции. Активное значение — 1.

DL_SPEED_NOT_MAX уведомляет устройство о том, что текущая скорость приема DOWNLINK-пакетов является немаксимальной для данной базовой станции. Активное значение — 1.

RTC_OFS_8_13 — старшие 6 бит 14-битной поправки времени — используют при реализации механизма коррекции системного времени оконечного устройства.

Структура формата поля MFLAGS при передаче АСК_Р от устройства к серверу приведена в таблице 23.

Таблица 23 — Структура формата поля MFLAGS при передаче АСК_Р от устройства к серверу

DL_POWER_STEP_DOWN уведомляет сервер о необходимости снизить мощность передатчика базовой станции для данного устройства. Активное значение — 1.

DL_POWER_STEP_UP уведомляет сервер о необходимости повысить мощность передатчика базовой станции для данного устройства. Активное значение — 1.

TX_PWR соответствует уровню текущей мощности передатчика устройства. Допустимые значения — от 0 до RF_MAX_POWER дБм.

• 7.3.2.3 Пакет HEARTBEAT (информация о параметрах работы устройства)

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

Структура формата пакета HEARTBEAT приведена в таблице 24.

Таблица 24 — Структура формата пакета HEARTBEAT

• a) VSUP (Напряжение питания устройства)

Должно быть представлено в следующем формате:

Старший бит: 1,еслиС/>ЗВ.

Младшие 7 бит: десятые доли вольта.

Формула для перевода данного поля в вольты:

V = 2 + (D»7) + (D&0x7F)/100.

(2)

• б) TEMP (Температура внутри устройства)

Тип данных: int8_t-

Допустимые значения: от минус 128 °C до плюс 128 °C.

• в) AVER_RX_SNR (Среднее значение соотношения сигнал/шум на входе приемника устройства)

Среднее значение соотношения сигнал/шум на входе приемника устройства определяют по нескольким последним принятым пакетам. Допустимые значения: от 0 до 127 дБ.

• г) AVER_TX_SNR (Среднее значение соотношения сигнал/шум на входе приемника базовой станции)

Среднее значение соотношения сигнал/шум на входе приемника базовой станции определяют по нескольким последним принятым пакетам и вычисляют на основании данных, получаемых в поле SNR АСК_Р пакета. Допустимые значения: от 0 до 127 дБ.

• д) NOISE (Уровень шума на входе приемника устройства)

Допустимые значения: от 0 до 255. Данные значения соответствуют уровням шума от минус 150 до плюс 105 дБм.

• е) TX_PWR (Уровень текущей мощности передатчика устройства)

Допустимые значения: от минус 10 до RF_MAX_POWER дБм.

• 7.3.2.4 Пакет GROUP (первый пакет в группе)

Данный системный пакет предназначен для определения заголовка (первого пакета) групповой посылки.

Структура формата пакета GROUP приведена в таблице 25.

Таблица 25 — Структура формата пакета GROUP

• a) GROUPJ-EN

Количество байт поля DATA (Данные) в групповой посылке. Значение не должно превышать 240.

• б) GROUP-CRC

Контрольная сумма CRC8 полей DATA (Данные) в групповой посылке.

• в) PAYLOAD_0_4

Первые 5 байт поля DATA (Данные) групповой посылки.

• 7.3.2.5 Пакет SACK_P (подтверждение приема системного пакета)

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

Структура формата пакета SACK_P приведена в таблице 26.

Таблица 26 — Структура формата пакета SACK_P

• a) SET_FPLAN

Данное поле может содержать новое значение параметра FPLAN либо код, означающий, что параметр FPLAN должен остаться без изменений.

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

Значение поля SET_FPLAN, равное 4104 означает, что параметр FPLAN должен остаться без изменений.

Структура формата параметра FPLAN приведена в таблице 27.

Влияние параметров, приведенных в таблице 27, на выбор частот приема и передачи описано в приложении А.

Таблица 27 — Структура формата параметра FPLAN

• б) BS_OR_SERVER_ID

Данное поле предназначено для передачи оконечному устройству значения идентификатора базовой станции BSJD, через которую осуществляется обмен данными, либо идентификатора сервера SERVERJD, с которым выполняется взаимодействие. Тип данного параметра: uint16J. Порядок следования байтов в данном поле: старшим байтом вперед.

При SET_FPLAN = 4104 параметр BS_OR_SERVER_ID содержит идентификатор BS_ID.

При SET_FPLAN # 4104 параметр BS_OR_SERVER_ID содержит идентификатор SERVERJD.

• 7.3.2.6 Пакет CLEAR (Сигнал завершения сеанса передачи данных)

Данный системный пакет предназначен для информирования о завершении сеанса передачи данных.

Структура формата пакета CLEAR приведена в таблице 28.

Таблица 28 — Структура формата пакета CLEAR

• 7.3.2.7 Пакет CONF (настройка параметров NB-Fi)

Данный системный пакет предназначен для выполнения настройки параметров NB-Fi.

Структура формата пакета CONF приведена в таблице 29.

Таблица 29 — Структура формата пакета CONF

Поле CONFJDATA определено в 7.3.2.7, перечисления г)—ш).

• a) CMD&PARAM

Структура формата поля CMD&PARAM приведена в таблице 30.

Таблица 30 — Структура формата поля CMD&PARAM

• б) CMD

Структура формата поля CMD приведена в таблице 31.

Таблица 31 — Структура формата поля CMD

• в) PARAM

Структура формата поля PARAM приведена в таблице 32.

Таблица 32 — Структура формата поля PARAM

Описание поля CONF_DATA для каждого параметра таблицы 32 приведено в пунктах 7.3.2.7, перечисления г)—ш).

• г) Значение поля СОЫР_ОАТАдля параметра NBFI_PARAM_MODE (PARAM = 0x00)

Таблица 33 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_MODE

Окончание таблицы 33

NBFIJMODE — режим работы транспортного уровня протокола NB-Fi. Описание поля NBFI_MODE приведено в таблице 34.

Таблица 34 — Описание поля NBFI_MODE

NBFI_MACK_MODE — параметр группового подтверждения доставки данных (multiple ack) при отправке. Может иметь значения от 0 до 32.

NBFI_TX_PHY_CHANNEL — параметр, определяющий тип и скорость пакетов при отправке UPLINK-пакетов, используемый в текущий момент времени. Описание поля NBFI_TX_PHY_CHANNEL приведено в таблице 35.

Таблица 35 — Описание поля NBFI_TX_PHY_CHANNEL

Примечание - DOWNLINK-пакеты применяют для отправки при взаимодействии в режиме «peer-to-peer».

NBFI_RX_PHY_CHANNEL — параметр, определяющий тип и скорость пакетов при приеме DOWNLINK-пакетов, используемый в текущий момент времени. Описание поля NBFI_RX_PHY_ CHANNEL приведено в таблице 36.

Таблица 36 — Описание поля NBFI_RX_PHY_CHANNEL

NBFI_TX_PWR — уровень выходной мощности передатчика. Тип параметра: int8_t- Допустимые значения: от минус 10 до RF_MAX_POWER дБм.

NBFI_NUM_OF_RETRIES — максимальное количество повторных отправок пакетов в течение одного сеанса отправки данных. Допустимые значения: от 0 до 255.

• д) Значение поля СОЫР_ОАТАдля параметра NBFI_PARAM_HANDSHAKE (PARAM = 0x01)

Описание структуры формата поля СОЫР_ОАТАдля параметра NBFI_PARAM_HANDSHAKE приведено в таблице 37.

Таблица 37 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_HANDSHAKE

NBFI_HANDSHAKE_MODE — режим подтверждения доставки. Описание поля NBFI_HANDSHAKE_ MODE приведено в таблице 38.

Таблица 38 — Описание поля NBFI_HANDSHAKE_MODE

NBFI_MACK_MODE — параметр группового подтверждения доставки данных (multiple ack) при отправке. Допустимые значения: от 0 до 32.

• е) Значение поля СО1МР_ОАТАдля параметра NBFI_PARAM_TXFREQ (PARAM = 0x03)

Описание структуры формата поля СО1\1Р_ОАТАдля параметра NBFI_PARAM_TXFREQ приведено в таблице 39.

Таблица 39 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_TXFREQ

TXFREQ — параметр, определяющий частоту отправки данных. При TXFREQ = 0 частоту отправки данных вычисляют в соответствии с алгоритмом, приведенным в А.1 приложения А.

При TXFREQ = 0 чтение данного параметра возвращает значение 0 и не позволяет определить текущую частоту отправки.

При TXFREQ # 0 частота отправки равна значению TXFREQ.

Порядок следования байт в данном поле данных — старшим байтом вперед.

• ж) Значение поля СОМЕ_ОАТАдпя параметра NBFI_PARAM_RXFREQ (PARAM = 0x04)

Описание структуры формата поля СОЫР_ОАТАдля параметра NBFI_PARAM_RXFREQ приведено в таблице 40.

Таблица 40 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_RXFREQ

RXFREQ — параметр, определяющий частоту, на которой выполняется прием данных. При RXFREQ = 0 частоту Г вычисляют в соответствии с алгоритмом, приведенным в А.2 приложения А.

При RXFREQ = 0 чтение данного параметра возвращает значение 0 и не позволяет определить текущую частоту приема.

При RXFREQ # 0 частота приема равна значению RXFREQ.

Порядок следования байтов в данном поле данных — старшим байтом вперед.

• и) Значение поля CONFJDATA для параметра NBFI_PARAM_ANT (PARAM = 0x05)

Описание структуры формата поля СОЫР_ОАТАдля параметра NBFI_PARAM_ANT приведено в таблице 41.

Таблица 41 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_ANT

NBFI_TX_PWR — уровень выходной мощности передатчика. Тип параметра: int8J. Допустимые значения: от минус 10 до RF_MAX_POWER дБм.

NBFI_TX_ANT — параметр, определяющий, какой из RF-трактов используется при передаче. Значения параметра и соответствующие им варианты RF-трактов зависят от конкретной реализации устройства.

NBFI_RX_ANT — параметр, определяющий, какой из RF-трактов используется при приеме. Значения параметра и соответствующие им варианты RF-трактов зависят от конкретной реализации устройства.

• к) Значение поля СОЫЕ_ОАТАдля параметра NBFI_PARAM_HEART_BEAT (PARAM = 0x07)

Описание структуры формата поля CONFJDATA для параметра NBFI_PARAM_HEART_BEAT приведено в таблице 42.

Таблица 42 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_HEART_BEAT

NBFI_HEARTBEAT_NUM — параметр, определяющий количество HEARTBEAT-пакетов, которые будут отправлены после сброса устройства. При NBFI_HEARTBEAT_NUM = 255 отправка HEARTBEAT-пакетов выполняется неограниченное количество раз.

NBFI_HEARTBEAT_INTERVAL— параметр, определяющий периодичность отправки HEARTBEAT-пакетов. Допустимые значения: от 0 до 65535. Порядок следования байтов в поле параметра: старшим байтом вперед. Порядок расчета периодичности отправки HEARTBEAT-пакетов при разных режимах работы транспортного уровня протокола NB-Fi (NBFI_MODE) приведен в таблице 43.

Таблица 43 — Порядок расчета периодичности отправки HEARTBEAT-пакетов при разных режимах работы транспортного уровня протокола NB-Fi

• л) Значение поля СОИЕ_ОАТАдля параметра NBFI_PARAM_TX_BRATES (PARAM = 0x08)

Описание структуры формата поля СОИР_ОАТАдля параметра NBFI_PARAM_TX_BRATES приведено в таблице 44.

Таблица 44 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_TX_BRATES

NBFI_TX_BRATES — в данном поле перечислены все поддерживаемые устройством скорости передачи данных, которые используются при автоматическом выборе оптимальной скорости. Данные представлены в формате значений параметра NBFI_TX_PHY_CHANNEL (см. таблицу 35).

Максимально возможное количество поддерживаемых скоростей равно шести. Поддерживаемые скорости перечислены, начиная с младшего байта данного поля. Если число скоростей менее шести, старшие (неиспользуемые) байты данного поля равны OxFF. Выбор поддерживаемых скоростей обусловлен техническими возможностями оконечного устройства.

Примечание - Параметр NBFI_PARAM_TX_BRATES доступен только для чтения.

м) Значение поля СОЫР_ОАТАдля параметра NBFI_PARAM_RX_BRATES (PARAM = 0x09)

Описание структуры формата поля СОЫР_ОАТАдля параметра NBFI_PARAM_RX_BRATES приведено в таблице 45.

Таблица 45 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_RX_BRATES

NBFI_RX_BRATES — в данном поле перечислены все поддерживаемые устройством скорости приема данных, которые используются при автоматическом выборе оптимальной скорости. Данные представлены в формате значений параметра NBFI_RX_PHY_CHANNEL (см. таблицу 36). Максимально возможное количество поддерживаемых скоростей равно шести. Поддерживаемые скорости перечислены начиная с младшего байта данного поля. Если число скоростей менее шести, старшие (неиспользуемые) байты данного поля равны OxFF. Выбор поддерживаемых скоростей обусловлен техническими возможностями оконечного устройства.

Примечание - Параметр NBFI_PARAM_RX_BRATES доступен только для чтения.

н) Значение поля CONFJDATA для параметра NBFI_PARAM_VERSION (PARAM = 0x0A)

Описание структуры формата поля СОЫР_ОАТАдля параметра NBFI_PARAM_VERSION приведено в таблице 46.

Таблица 46 — Структура формата поля CONF_DATA для параметра NBFI_PARAM_VERSION

NBFI_REV — версия транспортного протокола NB-Fi. Текущее значение равно 6.

NBFI_SUBREV — дополнительная версия транспортного протокола NB-Fi — в данный момент не используется.

COMP_CRC — контрольная сумма CRC8 даты и времени компиляции программного обеспечения устройства — используется для автоматического контроля модификаций программного обеспечения.

HARDWARE_ID — идентификатор аппаратной платформы устройства. Значение HARDWAREJD определяется производителем оконечных устройств.

HARDWARE_REV — версия аппаратной платформы устройства. Значение HARDWARE_REV определяется производителем оконечных устройств.

BANDJD — идентификатор радиочастотного решения устройства — описывает рабочие частоты приемного и передающего трактов. Значение BANDJD для необходимого радиочастотного плана предоставляется разработчиком сервера NB-Fi.

Примечание - Параметр NBFI_PARAM_VERSION доступен только для чтения.

• п) Значение поля CONFJDATA для параметра NBFI_ADD_FLAGS (PARAM = 0x0В)

Описание структуры формата поля CONF_DATAдля параметра NBFI_ADD_FLAGS приведено в таблице 47.

Таблица 47 — Структура формата поля CONFJDATA для параметра NBFI_ADD_FLAGS

NBFI_ADDITIONAL_FLAGS — параметр, представляющий собой совокупность дополнительных флагов, управляющих определенными функциями протокола, сгруппированных в виде битовой маски. Активное значение каждого флага — 1.

Порядок следования байтов в поле параметра: младшим байтом вперед.

Описание поля NBFI_ADDITIONAL_FLAGS приведено в таблице 48.

Таблица 48 — Описание поля NBFI_ADDITIONAL_FLAGS

FLG_FIXED_BAUD_RATE — данный флаг деактивирует механизм автоматического выбора оптимальной скорости и мощности передачи.

FLG_NO_RESET_TO_DEFAULTS — данный флаг деактивирует функцию сброса режима скоростей к значениям по умолчанию после неудачного выполнения сеанса передачи данных и используется совместно с флагами FLG_FIXED_BAUD_RATE и FLG_SHORT_RANGE_CRYPTO при соединениях в режиме «peer-to-peer».

FLG_NO_SEND_INFO — данный флаг отключает автоматическую отправку информационных пакетов.

FL.G_SEND_AL.OHА—данный флаг включает режим отправки данных «ALOHA», при котором каждый пакет МАС-уровня отсылается дважды на различных частотах с целью снижения вероятности потери пакета в результате коллизии.

FLG_LBT — данный флаг активирует режим передачи LBT (Listen Before Talk).

FLG_OFF_MODE_ON_INIT — данный флаг сигнализирует устройству переходить в режим работы OFF при инициализации устройства.

FLG_DO_NOT_SEND_PKTS_ON_START — данный флаг отключает отправку системных пакетов CLEAR и CONF при инициализации устройства.

FLG_SHORT_RANGE_CRYPTO — данный флаг включает режим защиты данных без смены ключей. Описание данного режима приведено в Г.2 приложения Г. Используется совместно с флагами FLG_ FIXED_BAUD_RATE и FLG_NO_RESET_TO_DEFAULTS при соединениях в режиме «peer-to-peer».

• р) Значение поля СОМЕ_ОАТАдля параметра NBFI_QUALITY (PARAM = ОхОС)

Описание структуры формата поля CONF_DATA для параметра NBFI_QUALITY приведено в таблице 49.

Таблица 49 — Структура формата поля CONF_DATA для параметра NBFI_QUALITY

UL_TOTAL — общее количество отправленных пакетов с момента сброса устройства. Тип данного параметра: uint16_t- Порядок следования байтов в данном поле: старшим байтом вперед.

DL_TOTAL — общее количество принятых пакетов с момента сброса устройства. Тип данного параметра: uint16_t- Порядок следования байтов в данном поле: старшим байтом вперед.

AVER_RX_SNR — среднее значение соотношения сигнал/шум на входе приемника устройства, определяемое по нескольким последним принятым пакетам. Допустимые значения: от 0 до 127 дБ.

AVER_TX_SNR — среднее значение соотношения сигнал/шум на входе приемника базовой станции, определяемое по нескольким последним принятым пакетам, вычисляется на основании данных, получаемых в поле SNR АСК Р пакета. Допустимые значения: от 0 до 127 дБ.

Примечания

• 1 Параметр NBFI_QUALlTY доступен только для чтения. Значение параметра NBFI_QUALITY должно рассчитываться на основе статистики переданных и принятых данных.

• 2 Параметры DL_TOTAL, AVER_RX_SNR, AVER_TX_SNR актуальны только для режимов работы DRX и CRX с NBFI_HANDSHAKE_MODE = HANDSHAKE_SIMPLE.

• с) Значение поля СОЫР_ОАТАдля параметра NBFI_UL_BASE_FREQ (PARAM = OxOD)

Описание структуры формата поля СОМР_ОАТАдля параметра NBFI_UL_BASE_FREQ приведено в таблице 50.

Таблица 50 — Структура формата поля CONF_DATA для параметра NBFI_UL_BASE_FREQ

UL_BASE_FREQ — параметр соответствует базовой частоте, используемой при расчете частоты, на которой отправляются данные.

• т) Значение поля СОЫР_ОАТАдля параметра NBFI_DL_BASE_FREQ (PARAM = 0x0E)

Описание структуры формата поля СОЫР_ОАТАдля параметра NBFI_DL_BASE_FREQ приведено в таблице 51.

Таблица 51 — Структура формата поля CONF_DATA для параметра NBFI_DL_BASE_FREQ

DL_BASE_FREQ — параметр соответствует базовой частоте, используемой при расчете частоты, на которой принимаются данные.

у) Значение поля СОЫЕ_ОАТАдля параметра NBFI_QUALITY_EX (PARAM = OxOF)

Описание структуры формата поля CONFJDATA для параметра NBFI_QUALITY_EX приведено в таблице 52.

Таблица 52 — Структура формата поля CONFJDATA для параметра NBFI_QUALITY_EX

UL_RATING — показатель уровня сигнала на входе приемника — вычисляется на основании текущего режима скорости и среднего значения соотношения сигнал/шум на входе приемника. Допустимые значения: от 0 до 10.

DL_RATING — показатель уровня сигнала от данного устройства на входе приемника базовой станции — вычисляется на основании текущего режима скорости и среднего значения соотношения сигнал/шум на входе базовой станции. Допустимые значения: от 0 до 10.

UL_SUCCESS_TOTAL — общее количество успешно доставленных пакетов с момента сброса устройства. Тип данного параметра: uint16J. Порядок следования байтов в данном поле: старшим байтом вперед. Для режима работы NRX либо в случае NBFI_HANDSHAKE_MODE = HANDSHAKEJXIONE данный параметр равен общему количеству отправленных пакетов.

UL_FAULT_TOTAL — общее количество недоставленных пакетов с момента сброса устройства. Тип данного параметра: uint16J. Порядок следования байтов в данном поле: старшим байтом вперед. Пакет считается недоставленным, если его не удалось доставить в результате сеанса передачи данных.

Примечания

• 1 Параметр NBFIJDUALITYJEX доступен только для чтения. Значение параметра NBFI_QUALITY_EX должно рассчитываться на основе статистики переданных и принятых данных.

• 2 Параметры UL_RATING, DL_RATING, UL_FAULT_TOTAL актуальны только для режимов работы DRX и CRX с NBFI_HANDSHAKE_MODE = HANDSHAKE_SIMPLE.

ф) Значение поля СОЫЕ_ОАТАдля параметра APFJDS (PARAM = 0x11)

Описание структуры формата поля CONFJDATA для параметра APPJDS приведено в таблице 53.

Таблица 53 — Структура формата поля CONFJDATA для параметра APPJDS

MANUFACTURERJD — идентификатор производителя устройства. Тип данного параметра: uint16J. Порядок следования байтов в данном поле: старшим байтом вперед. Значение MANUFACTURERJD предоставляется разработчиком сервера NB-Fi производителю оконечных устройств.

HARDWAREJTYPEJD — идентификатор типа устройства. Тип данного параметра: uint16J. Порядок следования байтов в данном поле: старшим байтом вперед. Значение HARDWAREJTYPEJD определяется производителем оконечных устройств.

PROTOCOLJD — идентификатор протокола уровня приложения. Тип данного параметра: uintl 6J. Порядок следования байтов в данном поле: старшим байтом вперед. Значение PROTOCOLJD определяется производителем оконечных устройств.

Примечание — Параметр APPJDS доступен только для чтения.

х) Значение поля CONFJDATA для параметра BSANDSERVERJDS (PARAM = 0x12)

Описание структуры формата поля CONFJDATA для параметра BSANDSERVERJDS приведено в таблице 54.

Таблица 54 — Структура формата поля CONF_DATA для параметра BSANDSERVERJDS

BSJD — идентификатор базовой станции, через которую осуществляется обмен данными с сервером NB-Fi. Тип данного параметра: uint24_t- Порядок следования байтов в данном поле: старшим байтом вперед.

SERVERJD — идентификатор сервера NB-Fi, с которым осуществляется обмен данными. Тип данного параметра: uint24_t. Порядок следования байтов в данном поле: старшим байтом вперед.

Примечание — Параметр BSANDSERVERJDS доступен только для чтения.

ц) Значение поля CONF_DATAдля параметра FPLAN (PARAM = 0x13)

Описание структуры формата поля CONFJDATA для параметра FPLAN приведено в таблице 55.

Таблица 55 — Структура формата поля CONFJDATA для параметра FPLAN

FPLAN — данный параметр определяет текущее значение рабочей полосы частот, используемой для передачи и приема данных. Тип данного параметра: uint 16_t- Порядок следования байтов в данном поле: старшим байтом вперед.

ш) Значение поля CONF_DATAдля параметра WAIT_ACK_TIMEOUT (PARAM = 0x14)

Описание структуры формата поля CONF_DATAдля параметра WAIT_ACK_TIMEOUT приведено в таблице 56.

Таблица 56 — Структура формата поля CONFJDATA для параметра WAIT_ACK_TIMEOUT

WAIT_ACK_TIMEOUT — параметр, определяющий время ожидания приема АСК_Р пакета, подтверждающего получение данных.

Тип данного параметра: uint16J. Порядок следования байтов в данном поле: старшим байтом вперед.

При WAIT_ACK_TIMEOUT = 0 время ожидания определяется в соответствии с формулой (1) (см. 7.2.2).

При WAIT_ACK_TIMEOUT # 0 время ожидания равно значению WAIT_ACK_TIMEOUT в миллисекундах.

• 7.3.2.8 Пакет RESET (сброс устройства)

Данный системный пакет предназначен для выполнения процедуры программного перезапуска устройства.

Структура формата пакета RESET приведена в таблице 57.

Таблица 57 — Структура формата пакета RESET

• 7.3.2.9 Пакет CLEAR_T (Сигнал завершения сеанса передачи данных со значением Unix Timestamp) Структура формата пакета CLEAR_T приведена в таблице 58.

Таблица 58 — Структура формата пакета CLEAR_T

UTS — 4-байтное значение системного времени в формате Unix Timestamp (количество секунд от 1 января 1970 г.), соответствующее часовому поясу UTC.

• 7.3.2.10 Пакет SENDTIME (Сигнал синхронизации системного времени)

Структура формата пакета SENDTIME приведена в таблице 59.

Таблица 59 — Структура формата пакета SENDTIME

UTS — 4-байтное значение системного времени в формате Unix Timestamp (количество секунд от 1 января 1970 г.), соответствующее часовому поясу UTC.

• 7.3.2.11 Пакет SYNC (Информация о состоянии ключевых параметров NB-Fi)

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

Использование пакета SYNC при взаимодействии оконечного устройства и сервера описан в 7.2.2.

Структура формата пакета SYNC приведена в таблице 60.

Таблица 60 — Структура формата пакета SYNC

Структура формата поля NBFI_MODE_AND_REV приведена в таблице 61.

Таблица 61 — Структура формата поля NBFI_MODE_AND_REV

CRYPTO_ITER_23_16 — значение части криптоитератора передачи от сервера к оконечному устройству от 23-го бита до 16-го бита.

CRYPTO_ITER_15_8 — значение части криптоитератора передачи от сервера к оконечному устройству от 15-го бита до 8-го бита.

Пример системы, использующей протокол NB-Fi, приведен в приложении И.

Приложение А (обязательное)

Описание алгоритмов определения частоты приема и передачи

А.1 Алгоритм определения частоты для отправки UPLINK-пакета

Частота отправки UPLINK-пакета зависит от следующих параметров:

NBFI_UL_BASE_FREQ — базовая частота передачи UPLINK-пакетов [см. 7.3.2.7, с)];

UL_WIDTH — ширина рабочей полосы передачи UPLINK-пакетов (см. 7.3.2.5);

UL_OFFSET — смещение рабочей полосы передачи UPLINK-пакетов, относительно базовой частоты (см. 7.3.2.5);

UL_SIGN — направление смещения рабочей полосы передачи UPLINK-пакетов, относительно базовой частоты (см. 7.3.2.5);

Bitrate — скорость передачи UPLINK-пакетов, бит/с — параметр, определяемый значением параметра NBFI_ TX_PHY_CHANNEL (см. таблицу 35);

ModemJD — идентификатор устройства (см. 6.2.2);

М1С0_7 — младшие 8 бит имитовставки (см. 6.2.5);

Parity — четность передаваемого пакета, имеет значения 0 или 1 и меняет свое значение с каждым последующим пакетом.

Значения частот в приведенных ниже формулах определяется в Гц.

Ширину рабочей полосы частот, в пределах которой должна осуществляться передача UPLINK-пакетов, вычисляют по формуле

ULBandwidth = 6400 • 2DL-WIDTH.

Смещение рабочей полосы частот относительно базовой частоты вычисляют по формуле

ULBandOffset = ULBandwidth • UL_OFFSET ■ (-1) ■ UL_SIGN.

Полосу перестройки несущей частоты передачи UPLINK-пакетов, в зависимости от скорости передачи, вычисляют по формулам:

,_ ULBandwidth-Bitrate-2-2000

ULGap =-----------------------------, если ULBandwidth > Bitrate• 2 + 2000,

ULGap = 0, если ULBandwidth < Bitrate ■ 2 + 2000.

Смещение несущей частоты заданного пакета, в зависимости от содержания пакета, вычисляют по формуле

((Modem ID + MIC0 7)mod 256) ULGap

ULChannelOffset = ------=--------—

255

Частоту для отправки UPLINK-пакета вычисляют по формулам:

ULfreq = NBFI_UL_BASE_FREQ + ULBandOffset + ULChannelOffset, если parity = 1,

ULfreq = NBFI_UL_BASE_FREQ + ULBandOffset - ULChannelOffset, если parity = 0.

A.2 Алгоритм определения частоты для отправки DOWNLINK-пакета

Частота отправки DOWNLINK-пакета зависит от следующих параметров:

NBFI_DL_BASE_FREQ — базовая частота передачи DOWNLINK-пакетов [см. 7.3.2.7, т)];

DL_WIDTH — ширина рабочей полосы передачи DOWNLINK-пакетов (см. 7.3.2.5);

DL_OFFSET — смещение рабочей полосы передачи DOWNLINK-пакетов, относительно базовой частоты (см. 7.3.2.5);

DL_SIGN — направление смещения рабочей полосы передачи DOWNLINK-пакетов, относительно базовой частоты (см. 7.3.2.5);

Bitrate — скорость передачи DOWNLINK-пакетов, бит/с — параметр, определяемый значением параметра NBFI_RX_PHY_CHANNEL (см. таблицу 36);

ModemJD — идентификатор устройства (см. 6.2.2).

Значения частот в приведенных ниже формулах определяется в Гц.

Ширину рабочей полосы частот, в пределах которой должна осуществляться передача DOWNLINK-пакетов, вычисляют по формуле

DKBandwith = 102400 • 2DL-WIDTH. (А.8)

Смещение рабочей полосы частот относительно базовой частоты вычисляют по формуле

DLBandOffset = DLBandwidth • DLJDFFSET • (-1) ■ DL_SIGN. (A.9)

Полосу перестройки несущей частоты передачи DOWNLINK-пакетов, в зависимости от скорости передачи, вычисляют по формулам:

г^. _ DLBandwidth- Bitrate 2 -2000 „ , . _ х

DLGap =-----------------------------, если DLBandwidth > Bitrate • 2 + 2000, (А.10)

DLGap = 0, если DLBandwidth < Bitrate ■ 2 + 2000. (А.11)

Смещение несущей частоты заданного пакета, в зависимости от идентификатора устройства, вычисляют по формуле

1Л„ (Modem ID mod 256) DLGap

DLChannelOffset = ----------------------------. (A. 12)

255

Частота для отправки DOWNLINK-пакета определяется по следующей формуле:

DLfreq = NBFI_DL_BASE_FREQ + DLBandOffset + DLChannelOffset, если ModemJD mod 2 = 1, (A.13)

DLFreq = NDFI_DL_DASE_FREQ + DLBandOffset - DLChannelOffset, если ModemJD mod 2 = 0. (A.14)

Приложение Б (справочное)

Описание алгоритма компенсации нестабильности частот задающего генератора

Суть алгоритма компенсации частот заключается в следующем:

Отправка UPLINK-пакетов устройствами осуществляется на известной (предполагаемой) частоте fexp и1, вычисляемой по формулам (А.6) и (А.7).

Отправка DOWNLINK-пакетов базовой станцией осуществляется на известной (предполагаемой) частоте fexp db вычисляемой по формулам (А. 13) и (А. 14).

Базовая станция, принимая пакет, вычисляет частоту приема frx1 с разрешением в несколько десятков герц (для скорости 50 бит/с) и затем выполняет вычисление обобщенной ошибки частоты ДА, по формуле

△^1 “ ?ехр_и1 ~ ^гхА • (Б-1)

В состав данной ошибки входят как погрешность передатчика оконечного устройства kfmodTX, так и ошибка измерения частоты базовой станцией &fbsRX, таким образом

Д/1 = ^modTX + ^bsRX- (Б-2)

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

Передатчик базовой станции, используемый для отправки DOWNLINK-пакетов, также с определенной периодичностью (например, каждые 5 мин) отправляет UPLINK-пакеты на фиксированной частоте ftest dl, которая попадает в полосу частот приема базовой станции. Базовая станция, принимая данный пакет, вычисляет частоту приема frx2 и затем значение обобщенной ошибки частоты ДА2 по формуле

Д^2 = ftest_dl ~ frx2-

В состав данной ошибки входят как погрешность передатчика базовой станции AfbsTX, так и ошибка измерения частоты базовой станцией &fbsRX, таким образом

ДГ2 = &fbsTX + MbsRX-

При отправке DOWNLINK-пакетов каждый раз вносится поправка в частоту передачи базовой станции прибавлением обобщенной ошибки Д^ и вычитанием обобщенной ошибки ДА2 по формуле

ftx = fexp_dl + - А^2-

Подставляя в формулу (Б.5) выражения (Б.2) и (Б.З), а также добавляя ошибку передатчика базовой станции AfbsTX, вычисляют фактическое значение частоты отправки ffactTX по формуле

ffactTX = fexp_dl + ^modTX + ^bsRX ~ ^bsTX ~ ^fbsRX + ^fbsTX ~ fexp_dl + ^fmodTX‘

Для успешного приема сообщения данная частота ffactTX должна соответствовать фактической частоте приема модема ffactRX, которая равна:

AffactRX ~ ^exp_dl + ^modRX'

Когда частота приема и частота передачи модема совпадают либо имеют близкие значения, ошибки приема и передачи также приблизительно равны:

^modTX ~ ^modRX- (Б ■8)

Таким образом, по формуле (Б.5) вычисляют необходимую компенсацию ошибок генераторов для случая

fbase_ul ~ ^base_db (Б-9)

В общем случае формула компенсации погрешностей частот имеет следующий вид:

ft*=^p_dl + ffbaSe-d'

'base_ul

Подставляя в формулу (Б.10) формулы (Б.1) и (Б.З), получают полную формулу расчета частоты отправки DOWNLINK-пакетов, при которой выполняется коррекция ошибок всех генераторов:

ffx = fexp_dl +Т (^ехр_ul ~ ^гх"\ ~ ffest_dl + ^гх2)• (Б-11)

'base ul

Приложение В (справочное)

Фрагменты исходных кодов реализации МАС-уровня

В.1 Функция формирования и отправки UPLINK-пакета

nbfi_status_t NBFi_MAC_TX_ProtocolE(nbfi_transport_packet_t* pkt) {

const uint8_t protE_preambula[] = {0x97, 0x15, 0x7A, 0x6F};

uint8_t ul_buf[20];

uint8_t ul_buf_encoded[36];

uint8_t len = 0;

static _Bool parity = 0;

uint32_t tx_freq;

uint32_t mic_or_crc32;

ul_buf[len++] ul_buf[len++] ul_buf[len++] ul buf[len++]

= Modem_ID[3] = Modem_ID[2] = Modem_ID[l] = Modem ID[0]

ul_buf[len++] = nbfi_iter.ul;

ul_buf[len++] = pkt->phy_data.header;

memcpy(&ul_buf[len] , pkt->phy_data.payload, pkt->phy_data_length);

NBFi_Crypto_Encode(&ul_buf[len - 1], *((uint32_t*)Modem_ID), nbfi_iter.ul, 9); len += 8;

mic_or_crc32 = NBFi_Crypto_UL_MIC(&ul_buf[len - 9], 9);

nbfi_iter.ul = NBFI_Crypto_inc_iter(nbfi_iter.ul);

ul_buf[len++] = (uint8_t)(mic_or_crc32 >> 16);

ul_buf[len++] = (uint8_t)(mic_or_crc32 >> 8);

ul_buf[len++] = (uint8_t)(mic_or_crc32);

mic_or_crc32 = CRC32(ul_buf, 17);

ul_buf[len++] ul_buf[len++] ul_buf[len++]

(uint8_t)(mic_or_crc32 >> 16);

(uint8_t)(mic_or_crc32 >> 8);

(uint8_t)(mic_or_crc32);

if(nbfi.tx_freq)

{

tx_freq = nbfi.tx_freq ;

parity = (nbfi.tx_freq > (nbfi.ul_freq_base));

}

else

{

tx_freq = NBFi_MAC_get_UL_freq(ul_buf[len - 4], parity); }

for(int i=0; i

{

ul_buf_encoded[i] = protE_preambula[i];

}

PCODE_encode(8, &ul_buf[0], &ul_buf_encoded[4] ) ;

if(!nbfi.tx_freq) parity = [parity;

if((nbfi.additional_flags&NBFI_FLG_SEND_ALOHA) && parity)

NBFi_RF_Init(nbfi.tx_phy_channel,(nbfi_rf_antenna_t)nbfi.tx_antenna, nbfi.tx_pwr, tx_ freq);

NBFi_RF_Transmit(ul_buf_encoded, 36, nbfi.tx_phy_channel, BLOCKING);

return NBFi_MAC_TX_ProtocolE(pkt);

}

NBFi_RF_Init(nbfi.tx_phy_channel, (nbfi_rf_antenna_t)nbfi.tx_antenna, nbfi.tx_pwr, tx freq);

NBFi_RF_Transmit(ul_buf_encoded, 36, nbfi.tx_phy_channel, NONBLOCKING);

return OK; }

• B.2 Функция формирования и отправки DOWNLINK-пакета

nbfi_status_t NBFi_MAC_TX_ProtocolD(nbfi_transport_packet_t* pkt) {

uint8_t ul_buf[64];

uint8_t len = 0;

static _Bool parity = 0;

uint8_t lastcrc8;

uint32_t mic_or_crc32;

nbfi_phy_channel_t phy;

uint32_t tx_freq;

static uint32_t preamble;

memset(ul_buf,0,sizeof(ul_buf));

preamble = preambula(Modem_ID, (uint32_t *)0, (uint32_t *)0);

for(int i=0; i

ul_buf[len++] = ((uint8_t *)&preamble)[sizeof(preamble) -1-1];

ul_buf[len++] = nbfi_iter.ul;

ul_buf[len++] = pkt->phy_data.header;

memcpy(&ul_buf[len], pkt->phy_data.payload, pkt->phy_data_length);

NBFi_Crypto_Encode(&ul_buf[len - 1], Modem_ID, nbfi_iter.ul, 9); len += 8;

mic_or_crc32 = NBFi_Crypto_UL_MIC(&ul_buf[len - 9], 9);

nbfi_iter.ul = NBFI_Crypto_inc_iter(nbfi_iter.ul);

ul_buf[len++] = (uint8_t)(mic_or_crc32 » 16);

ul_buf[len++] = (uint8_t)(mic_or_crc32 » 8);

ul_buf[len++] = (uint8_t)(mic_or_crc32);

mic_or_crc32 = CRC32(ul_buf + 4, 13);

ul_buf[len++] = (uint8_t)(mic_or_crc32 » 16);

ul_buf[len++] = (uint8_t)(mic_or_crc32 >> 8);

ul_buf[len++] = (uint8_t)(mic_or_crc32);

if(nbfi.tx_freq)

{

tx_freq = nbfi.tx_freq ;

} else {

tx_freq = NBFi_MAC_get_DL_freq() ; }

ZCODE_Append(&ul_buf[4] , &ul_buf[len], 1) ;

NBFi_RF_Init(nbfi.tx_phy_channel, (nbfi_rf_antenna_t)nbfi.tx_antenna, nbfi.tx_pwr, freq);

NBFi_RF_Transmit(ul_buf, len + ZCODE_LEN, phy, NONBLOCKING);

tx

return OK;

}

• B.3 Функция вычисления контрольной суммы CRC8 static unsigned char CRC8byte(unsigned char data) { uint8 t crc = 0;

return crc;

uint8_t CRC8(uint8_t* data, uint8_t len)

{

uint8_t crc = 0;

for(uint8_t i = 0; i < len; i++) {

crc = CRC8byte(data[i] Л crc); } return crc;

}

• B.4 Функция вычисления контрольной суммы CRC16

tfdefine POLY OxaOOl

uintlS t CRC16(uint8 t *buf, uintl6 t len,

uintl6_t crc)

while (len--)

{

crc Л= *buf++; crc = crc & 1 crc = crc & 1 crc = crc & 1 crc = crc & 1 crc = crc & 1 crc = crc & 1 crc = crc & 1 crc = crc & 1 } return crc;

? (crc » 1) л POLY ? (crc » 1) л POLY ? (crc » 1) л POLY ? (crc » 1) л POLY ? (crc » 1) л POLY ? (crc » 1) л POLY ? (crc » 1) л POLY ? (crc » 1) л POLY

crc >> 1;

crc » 1;

crc >> 1;

crc >> 1;

crc >> 1;

crc » 1;

crc » 1;

crc >> 1;

• B.5 Функция вычисления контрольной суммы CRC32

uint32_t CRC32(const uint8_t *buf, uint8_t len) {

return digital_update_crc32(Oxffffffff, buf, len) Л Oxffffffff;

}

#define WIDTH (8*4)

tfdefine TOPBIT (1 « (WIDTH-1))

tfdefine POLYNOMIAL (0xl04CllDB7)

uint32_t crc_table(uint8_t n) {

uint32_t c;

int k;

c=((uint32_t)n) « (WIDTH - 8);

for (k=8; k>0; k—) {

if(c & (uint32_t)TOPBIT) { с = (c«l) л POLYNOMIAL; } else { c=c«l ; } } return c;

}

uint32_t digital_update_crc32( uint32_t crc, const uint8_t *data, uint8_t len ) {

while (len > 0) {

crc = crc_table(*data л ((crc >> 24) & Oxff)) л (crc << 8);

data++;

len--;

} return crc;

}

Приложение Г (обязательное)

Защита данных в протоколе NB-Fi

Г.1 Общие положения

Защита данных NB-Fi должна быть реализована на МАС-уровне.

Для защиты данных должно выполняться шифрование блока данных транспортного уровня NB-Fi.

Шифрование данных должно выполняться для отправляемых и принимаемых пакетов данных. И отправляемые, и принимаемые пакеты данных могут иметь тип UPLINK-пакет (см. 6.2) или DOWNLINK-пакет (см. 6.3).

Для шифрования данных должен применяться алгоритм блочного шифрования «Магма».

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

Для шифрования отправляемых и принимаемых пакетов данных должна использоваться схема формирования ключей шифрования, порожденных из корневого ключа, выделенного устройству. Алгоритм формирования данных ключей приведен в Г.2.

Шифрование блока данных транспортного уровня, имеющего размер 9 байт, должно выполняться в соответствии с алгоритмом, который приведен в Г.З.

Проверка «валидности» принятого пакета должна осуществляться при помощи контроля имитовставки. Алгоритм вычисления имитовставки приведен в Г.4.

Для защиты от атаки повторного воспроизведения каждый последующий UPLINK- и DOWNLINK-пакет должен содержать уникальное значение криптоитератора, используемого для формирования ключей и для шифрования данных. Алгоритмы использования значения криптоитератора описаны в Г.2, Г.З.

Г.2 Алгоритм формирования ключей для шифрования отправляемых и принимаемых пакетов данных

Алгоритм формирования ключей должен быть основан на режиме гаммирования симметричного блочного шифрования «Магма» согласно ГОСТ Р 34.12 и ГОСТ Р 34.13.

Должна применяться схема ключей шифрования, состоящая из 6 ключей, по 3 ключа для отправляемых и принимаемых пакетов данных. В каждом комплекте ключей должен находиться мастер-ключ, предназначенный для формирования двух следующих ключей:

• - рабочего ключа, с помощью которого происходит шифрование/расшифрование данных;

• - ключа имитозащиты, с помощью которого выполняется выработка имитовставки пакета.

Первая пара мастер-ключей должна формироваться из корневого ключа, выделенного устройству [формулы (Г.2), (Г.З)].

Каждый комплект ключей должен действовать для обработки 256 отправленных пакетов (т. е. для одного периода оборота криптоитератора). При оборачивании криптоитератора должна происходить смена ключей — из мастер-ключа должен формироваться новый мастер-ключ [формулы (Г.4), (Г.5)] с последующим формированием рабочих ключей [формулы (Г.6), (Г.7)] и ключей имитозащиты [формулы (Г.8), (Г.9)].

В энергонезависимую память оконечного устройства и в базу данных сервера NB-Fi должны быть доверенным образом занесены:

• а) либо мастер-ключи (для отправляемых и принимаемых пакетов данных), порожденные из корневого ключа, выделенного устройству;

• б) либо корневой ключ, выделенный устройству.

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

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

Для работы в режиме «peer-to-peer» необходимо использовать DOWNLINK-пакеты для передачи в обоих направлениях, а также конфигурационный флаг транспортного уровня FLG_SHORT_RANGE_CRYPTO [см. 7.3.2.7, перечисление п)]. При наличии данного флага смена ключей при оборачивании криптоитератора не осуществляется. Таким образом, при работе в режиме «peer-to-peer» обеспечивается более низкий уровень криптозащиты данных, но упрощается реализация механизма синхронизации значений криптоитераторов между узлами «peer-to-peer» соединения. В режиме «peer-to-peer» должно обрабатываться не более 232 пакетов.

Для работы двух устройств в режиме «peer-to-peer» необходимо выделить новый корневой ключ и в каждое из устройств, при производстве или дополнительном конфигурировании перед эксплуатацией, доверенным образом дополнительно занести два мастер-ключа (порожденные из выделенного корневого ключа) или корневой ключ для формирования рабочих ключей и ключей имитозащиты для отправляемых и принимаемых пакетов данных.

Ключи (выделенный корневой ключ или порожденные мастер-ключи) для работы в режиме «peer-to-peer» должны отличаться от ключей, используемых устройствами для работы в режиме передачи данных между устройством и базовой станцией.

При необходимости работы устройства в режиме «peer-to-peer» с несколькими подключаемыми устройствами, для каждой пары подключенных устройств необходимо выделение отдельного корневого ключа (и использование порожденных из него мастер-ключей).

DOWNLINK-пакеты, полученные от различных устройств или базовой станции, отличают по различным ключам шифрования.

Вводится понятие полного криптоитератора: полный криптоитератор — это 32-битный счетчик переданных пакетов, хранящийся на устройстве/сервере.

Младшие 8 бит полного криптоитератора должны передаваться с каждым пакетом МАС-уровня (в поле Crypto Iter — криптоитератор).

Шифрование каждого UPLINK- и DOWNLINK-пакета должно выполняться с использованием нового значения полного криптоитератора, увеличиваемого на единицу для каждого последующего пакета. Формирование полных криптоитераторов должно выполняться отдельно для отправляемых и для принимаемых пакетов данных при обмене данными между устройством и базовой станцией, а также отдельно для отправляемых и для принимаемых пакетов данных для каждой пары устройств, работающих в режиме «peer-to-peer».

Полное значение криптоитераторов для отправляемых и для принимаемых UPLINK- и DOWNLINK-пакетов должно храниться в памяти оконечных устройств и сервера NB-Fi.

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

Для восстановления синхронизации ключей должен быть реализован дополнительный алгоритм синхронизации:

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

• - в случае положительного результата проверки имитовставки на текущем комплекте ключей необходимо обновить младшие 8 бит полного криптоитератора, установив их равными младшим 8 битам из принятого пакета;

• - глубина циклической проверки имитовставки должна быть ограничена в соответствии с необходимыми эксплуатационными требованиями и требованиями безопасности;

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

Основные обозначения:

Основной примитив, блочный шифр «Магма» в режиме гаммирования:

ctrmagma(K< Р)-

Порождение первого мастер-ключа:

Кul master ~ c^rmagma Unroot’ 0х00А4,0х00А32),

Kdl master ~ c^rmagma ^root’ 0xFFA4,0x00A32).

Смена мастер-ключей:

Кul master ~ c^rmagma ^ulmaster 0x0FA4,0x00A32),

Kdl master ~ c^rmagma (^dl master 0x0FA4,0x00A32),

Формирование ключей шифрования:

*ul work ~ c^rmagma ^ulmaster 0xFFA4,0x00A32),

K(jl work ~ c^rmagma ^dl master 0xFFA4,0x00A32),

Формирование ключей имитозащиты:

Kul mac = «'magma

^dlmac ~ с^тадта ^dl mastert’ 0х00л4,0х00л32).

Г.З Алгоритм шифрования блока данных транспортного уровня

В качестве алгоритма шифрования должен использоваться алгоритм симметричного блочного шифрования «Магма» в режиме гаммирования согласно ГОСТ Р 34.12 и ГОСТ Р 34.13 [формула (Г.10)].

С^тадта (KXxwork’ РУ (F-10)

Для стартового вектора /одолжен использоваться полный криптоитератор, что позволяет задать уникальные начальные условия для шифрования каждого пакета.

Г.4 Алгоритм вычисления имитовставки

В качестве алгоритма вычисления имитовставки должен использоваться алгоритм симметричного блочного шифрования «Магма» в режиме выработки имитовставки согласно ГОСТ Р 34.12 и ГОСТ Р 34.13.

Выработка имитовставки должна производиться методом Encrypt-then-mac, т. е. сначала должны шифроваться данные, затем — формироваться имитовставка, вычисляемая от зашифрованных данных, дополненных полным криптоитератором (формула Г.11). В пакет должны быть включены три младших байта сгенерированного результата

М^тадта^хтас- C\\full_cryptO_iter). (Г.11)

Приложение Д (обязательное)

Исходные коды программной реализации помехоустойчивого кодирования

Д.1 Исходные коды кодирования для сверточного кода

ttdefine constraint_length 8

_Bool G_polys[2][8] = { {1, 0, 1, 0, 1, 1, 0, 1}, {1, 1, 1, 1, 0, 0, 1,1} };

_Bool state[constraint_length] = { 0,3, 0, 0, 0, 0, 0, 0 };

void conv_encoder(uint8_t* input, uint8_t* output, uint8_t len) {

_Bool* input_b = (_Bool*)malloc(len * 8 * sizeof(_Bool));

_Bool* output_d = (_Bool*)malloc(len * 2 * 8 * sizeof(_Bool));

_Bool* output_b = (_Bool*)malloc(len * 2 * 8 * sizeof(_Bool));

for (int n = 0; n < len * 8; n++) {

uint8_t b = 7 - n % 8;

input_b[n] = (input[n/8] » b) & 1;

}

for (int n = 0; n < len * 8; n++) {

_Bool input_d = input_b[n];

_Bool ul = input_b[n];

_Bool u2 = input_b[n];

for (int m = 1; m < constraint_length; m++) {

if (G_polys[0][m])

ul = ul Л state[m-1];

if (G_polys[1][m]) u2 = u2 A state[m-1];

}

output_d[n * 2] = ul;

output_d[n * 2 + 1] = u2;

for (int i = constraint_length; i > 0; i--) state[i] = state[i—1];

state[0] = input_b[n]; }

uintl6_t ptr_out = 0;

for (int i = 0; i < 2 * len * 8; i++) {

if (!(i % 10 == 3 || i % 10 == 8)) {

output_b[ptr_out] = output_d[i]; ptr_out += 1;

}

}

for (int i = 0; i < len; i++) {

output[i] = 0;

for (int b = 0; b < 8; b++) {

output[i] |= output_b[i * 8 + b] « (7 - b) ; }

}

free(input_b);

free(output_d); free(output_b);

Д.2 Исходные коды кодирования для полярного кода

const uint8_t PCODE_indexes[160] = { 31, 47, 55, 57, 58, 59, 60, 61, 62, 63, 78, 79, 83, 85, 86, 87,89, 90, 91, 92, 93, 94, 95, 99, 101, 102, 103, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 135

139, 141, 142, 143, 147, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 162,

164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180,

182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 193, 194, 195, 196, 197, 198, 199,

201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217,

219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235,

237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253,

255 };

void PCODE_encode(uint8_t power, uint8_t* in, uint8_t* out) {

uint8_t data_20_i = 0;

uint8_t data_20_sum[20];

uint8_t t;

uint32_t si;

for (int i=0; i<20; i++) {

data_20_sum[i] = 0;

for (int j=0;j<8;j++) {

data_20_sum [i] += ( ( (in [i] » (7-j ) ) & 1) * (1«(7 - j))); data_20_i+= 1;

} }

for (int i=0; i<32; i++) out[i] = 0;

for (int i=0; i<160; i++) {

t = (data_20_sum[i/8] » (7-(i%8))) & 1;

out[PCODE_indexes[i]/8] |= t « (7 - PCODE_indexes[i] % 8); }

for (int i=0; i < 32; i++) {

out[i] = out[i] Л ((out[i] & 0x55) «

out[i] = out[i] л ((out[i] & 0x33) «

out[i] = out[i] л ((out[i] & OxOF) «

}

for (uint8_t i = 3; i < power; i++) {

si = (1 « (i - 2) ) ;

uint32_t temp = (1 « (power - 3)) / si;

for (uint32_t j=0; j < temp; j++) {

for (uint32_t t = j*sl; t < j*sl+sl/2; t++) {

out[t] = out[t] л out[t + sl/2]; }

}

}

Приложение Е (обязательное)

Алгоритм определения преамбулы DOWNLINK-пакета

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

Фрагменты исходных кодов реализации данного алгоритма приведены в приложении К.

Приложение Ж (обязательное)

Таблица и функции, используемые для ZIGZAG-кодирования данных

const uint8_t n [4][128] =

{

{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32, 33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62, 63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92, 93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116 117,118, 119, 120, 121,122, 123,124,125,126, 127},

{104,52,43,96,31,7,71,78,58,37,93,25,125,85,42,111,6,95,72,117,27,51,63,84,91,35,120,26,97, 45,110,70,1,28,86,114,53,67,12,127,40,101,73,94,115,61,20,126,3,46,92,116,9,56,87,77,109 44,65,54,100,118,2,34,21,41,76,14,69,124,90,18,103,48,113,36,0,81,13,62,24,38,105,68,15,75, 88,50,122,29,83,102,8,16,108,23,32,49,99,112,19,55,89,11,107,82,47,98,22,30,60,80,66,121 10,57,17,39,79,4,64,123,33,59,106,74,5,119},

{26,10,105,48,38,84,76,57,23,125,115,3,106,33,77,99,71,113,22,1,44,87,8,31,111,96,2,42,70, 81,13,93,122,37,114,88,63,107,50,40,82,116,68,6,127,16,51,73,61,83,46,0,126,104,78,67,41 119,28,11,56,47,4,21,52,66,15,98,24,7,30,91,112,35,55,124,64,5,95,32,49,9,85,65,43,18,92 36,12,86,118,60,25,72,53,80,123,45,58,102,110,120,89,34,17,75,94,27,100,62,20,39,108,90,69, 117,97,59,79,109,101,19,121,54,29,14,74,103},

{0,93,104,36,87,125,23,97,44,107,11,3,70,35,60,77,29,84,6,91,126,15,76,56,4,89,115,99,43 22,122,16,105,55,2,113,78,51,63,14,120,102,8,19,68,111,86,47,64,32,121,72,59,108,96,80,25, 67,118,12,58,127,20,90,9,37,103,53,62,69,85,10,110,34,100,119,39,73,1,83,48,112,30,54,65 45,5,123,101,26,88,18,46,95,40,109,7,27,57,66,116,38,75,92,21,52,61,28,106,114,94,33,17,79, 42,71,124,50,82,13,31,41,117,74,98,81,24,49}

};

#define ZCODE_LEN 16

void ZCODE_Append(uint8_t * src_buf, uint8_t * dst_buf, _Bool parity) {

uint8_t bO;

uint8_t bl;

uint8_t bprev;

uint8_t res;

uint8_t code[4][8]= {

{0,0,0,0,0,0,0,0},

{0,0,0,0,0,0,0,0},

{0,0,0,0,0,0,0,0},

{0,0,0,0,0,0,0,0}

};

for(int j=0; j<4; j++) {

for(uint8_t i=0; i<64; i++) {

bO = (src_buf[ n[j][ i ] /8] << ( n[j][ i ] %8)) & 0x80;

bl = (src_buf[ n[j][64+i] /8] « ( n[j][64+i] %8)) & 0x80;

bprev = (code[j][ (i-1) /8] « ( (i-1) %8)) & 0x80;

res = bO Л bl Л bprev;

code[j][i/8] |= res » (i%8); }

}

for(int i=0; i<8;i++)

{

dst_buf[i] = (code[0][i] & (parity ? OxAA : 0x55)) | (codefl][i] & (parity ? 0x55 : OxAA));

dst_buf[i+8] = (code[2][i] & (parity ? OxAA : 0x55)) | (code[3][i] & (parity ? 0x55 : OxAA) ) ;

}

Приложение И (справочное)

Описание системы, использующей протокол NB-Fi

В настоящем приложении приведено описание информационной системы, использующей протокол NB-Fi на примере создания решения по дистанционному сбору данных с приборов учета энергоресурсов [4].

И.1 Архитектура системы

Архитектура системы состоит из четырех уровней и включает в себя:

• 1) оконечные устройства (приборы учета энергоресурсов), отправляющие и принимающие данные по протоколу стандарта NB-Fi;

• 2) базовые станции, осуществляющие прием, обработку и передачу сообщений от устройств (UPLINK-пакеты) на сервер NB-Fi, а также отправку нисходящих сообщений на устройства (DOWNLINK-пакеты);

• 3) NB-Fi сервер, осуществляющий прием, обработку и хранение сообщений от всех базовых станций для всех устройств, а также обеспечивающий интеграцию данных с сервером приложений и со сторонними программно-техническими комплексами (информационно-вычислительными комплексами верхнего уровня);

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

И.2 Описание устройств

Устройства, используемые для сбора данных с приборов учета в сфере жилищно-коммунального хозяйства, построены с использованием интегрального радиотрансивера К5553ВВ015, поддерживающего аппаратную реализацию физического и МАС-уровня протокола NB-Fi. Транспортный уровень протокола NB-Fi реализован при помощи программной библиотеки, исполняемой на микроконтроллере STM32L0X. Библиотека NB-Fi и примеры ее использования содержатся в файловом архиве [5].

Система содержит оконечные устройства NB-Fi, обеспечивающие учет потребления коммунальных ресурсов и сбор данных с существующих приборов учета, среди которых:

• - счетчики воды с накладным внешним модемом;

• - счетчики воды со встроенным в основную плату модемом;

• - однофазные и трехфазные счетчики электрической энергии со встроенным модемом;

• - теплосчетчики со встроенным и внешним модемом;

• - счетчики газа со встроенным модемом;

• - радиомодемы, подсоединяющиеся к импульсным или цифровым выводам внешних устройств.

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

Счетчики воды, газа, тепла отправляют сообщения два раза в сутки и содержат внутри себя данные о почасовом потреблении энергоресурсов.

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

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

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

Счетчики тепла, электроэнергии с внешним радиомодемом с цифровым (RS-485) выходом считывают показания с прибора учета по цифровому интерфейсу. Для отдельных приборов учета разработаны индивидуальные радиомодемы, позволяющие осуществить монтаж радиомодема под крышку устройства. Радиомодемы с батарейным питанием, в зависимости от конфигурации, отправляют данные с периодичностью от одного раза в месяц до двух раз в сутки. Существует модель радиомодема для электросчетчика с питанием от сети, что позволяет увеличить срок службы радиомодема.

Указанные выше устройства работают в режимах NRX либо DRX.

Счетчики электроэнергии осуществляют отправку сообщений на сервер один раз в час или чаще, в зависимости от конфигурации. Сообщения содержат данные о потреблении электроэнергии по каждому тарифу, а также другие параметры сети, в зависимости от настроек. Устройства работают в режиме CRX (Continuous RX) и обеспечивают постоянный прием нисходящих (DOWNLINK) сообщений от сервера. Отправка данных на электросчетчик с сервера возможна в любой момент. Данный режим работы предназначен конфигурировать электросчетчик и осуществлять управление размыкающего реле.

При работе в режиме NRX (а также в режимах DRX и CRX при низком уровне радиосигнала) возможны потери отправленных пакетов. В случае пропуска данных в определенный период на сервере приложений данных за этот период не окажется. Для режимов DRX и CRX пропущенные данные могут быть впоследствии запрошены повторно сервером приложений.

Мощность излучения устройств составляет 25 мВт при максимально разрешенном уровне излучения 100 мВт (для нелицензируемого диапазона частот 868,7—869,2 МГц). Расчетный срок работы устройств от батареи составляет свыше 10 лет. Рабочий температурный диапазон устройств составляет от минус 40 °C до плюс 70 °C.

И.З Описание базовых станций

Базовая станция NB-Fi является оборудованием базовых станций сетей радиодоступа и предназначена для приема-передачи маломощного радиосигнала узкополосной беспроводной технологии связи в субгигагерцовом диапазоне радиочастот. Базовая станция NB-Fi обеспечивает прием и передачу информации посредством радиоэфира с приборами учета энергоресурсов, с радиомодемами, подсоединенными к приборам учета энергоресурсов, с прочими датчиками (далее — устройствами), работающими в пределах рабочей частоты приемника и передатчика, и передачу этой информации на серверы и информационно-вычислительные комплексы верхнего уровня автоматизированных систем через стандартные интерфейсы и каналы связи, в том числе по сети Интернет или посредством изолированных локальных сетей.

Для приема восходящих пакетов данных (UPLINK-пакетов) со стороны Базовой станции NB-Fi применяется принцип SDR-систем (Software-Defined Radio), где входной радиосигнал оцифровывается во всей полосе приема 51,2 кГц, и в дальнейшем подвергается программной обработке. Прием пакетов выполняется Базовой станцией NB-Fi по всей полосе частот, при этом выделяются одновременно пакеты, имеющие различные скорости. Теоретическое количество каналов составляет 1024 для скорости 50 бит/с, и 128, 16 и 1 для скоростей 400, 3200 и 25 600 бит/с соответственно.

Передача нисходящих пакетов данных (DOWNLINK-пакетов) выполняется при помощи цифрового модулятора сигнала, позволяющего передавать одновременно несколько узкополосных каналов, если суммарная мощность передачи не превышает установленного значения. Передача осуществляется в полосе 102,4 кГц.

Для работы сети передачи данных по протоколу NB-Fi в Российской Федерации используется нелицензиру-емый в Российской Федерации диапазон частот 868,7—869,2 МГц. Максимальная выходная мощность передачи Базовой станции NB-Fi составляет 100 мВт.

В некоторых вариантах реализации Базовая станция NB-Fi может обладать следующими характеристиками:

• - рабочий температурный диапазон составляет от минус 50 °C до плюс 70 °C;

• - степень защиты корпуса от проникновения пыли и воды соответствует IP66 по ГОСТ 14254;

• - сервер NB-Fi и сервер приложения могут быть реализованы прямо на Базовой станции NB-Fi, что обусловливается требованиями заказчиков к автономности и изолированности используемых систем;

• - за счет разнесения полос приема и передачи по частоте и развязки приемной и передающих антенн по поляризации Базовые станции NB-Fi обеспечивают одновременный прием и передачу данных (режим передачи данных «полный дуплекс») без ухудшения характеристик радиосвязи;

• - базовые станции NB-Fi обеспечивают прием и передачу данных по одному каналу связи, но с разделением по времени (режим передачи данных «полудуплекс»), могут иметь более низкий динамический диапазон приемной части и меньшую чувствительность приема.

И.4 Описание сервера NB-Fi

Функциями сервера NB-Fi являются:

• - хранение в базе данных информации об устройствах (идентификаторы, ключи шифрования МАС-уровня, режимы работы транспортного уровня);

• - получение восходящих пакетов с данными от множества базовых станций;

• - дешифрование данных МАС-уровня и отбрасывание пакетов, не прошедших проверку целостности данных;

• - выделение уникальных пакетов (фильтрация и отбрасывание копий одного и того же пакета, принятого разными станциями);

• - реализация функций транспортного уровня NB-Fi;

• - выбор наилучшей базовой станции для отправки нисходящих пакетов для каждого устройства;

• - сохранение пакетов в базу данных;

• - взаимодействие с серверным программным обеспечением уровня приложений посредством API-интерфейса.

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

Установка сервера NB-Fi возможна в том числе и на Базовые станции NB-Fi. Это позволяет организовать получение/отправку данных непосредственно с базовых станций и на них. При этом возникает необходимость конфигурирования каждой станции в части загрузки в нее информации об устройствах, что усложняет масштабирование сети.

И.5 Описание сервера приложений

Функциями сервера приложений являются:

• - поддержка моделей оконечных устройств;

• - преобразование пакетов от сервера NB-Fi в данные, пригодные для отображения пользователю устройств;

• - преобразование команд от пользователя устройств в пакеты для отправки через сервер NB-Fi;

• - конфигурирование устройств, обновление внутреннего программного обеспечения устройств, диагностика исправностей;

• - длительное хранение данных;

• - предоставление данных и управление устройствами через API-интерфейс;

• - предоставление данных и управление устройствами при помощи графического интерфейса пользователя;

• - аналитический и статистический анализ данных, выгрузка отчетов;

• - другие функции, зависящие от предметной области данного приложения.

Сервер приложений является верхним уровнем телекоммуникационной системы, построенной на базе сети передачи данных NB-Fi. Данный компонент не является стандартным решением со строго определенным перечнем функций. Его задачи зависят от предметной области, для которой используется система (автоматизированная система коммерческого учета энергоресурсов, системы мониторинга и сигнализации, контроль технологических процессов для промышленности и сельского хозяйства и т. д.). Возможна одновременная работа различных серверов приложения, взаимодействующих с единым сервером NB-Fi.

Приложение К (обязательное)

Фрагменты исходных кодов реализации для определения преамбулы DOWNLINK-пакета

//preambula.h

#ifndef _PREAMBULA_H_

tfdefine _PREAMBULA_H_

#ifdef __cplusplus

extern "C"

{ tfendif

#include

#define RAND_MULL 0x1234

#define RAND_ADD 0x10

#define MAX_ITER 100

tfdefine MAX_COEFF 6

uint32_t preambula(uint32_t seed, uint32_t *iter, uint32_t *coeff);

#ifdef __cplusplus

}

#endif

tfendif

//preambula.c

#include "preambula.h"

#include

tfinclude

static uint32_t _alu(uint32_t data, uint32_t tmp) {

uint32_t test = data Л tmp;

int32_t count = 0;

while (test)

count += test & 0x01, test >>= 1;

count = abs(count - (32 - count)) » 1;

return count;

static uint32_t _factor(uint32_t data) (

uint32_t i, count, tmp, max = 0;

for (i = 0, tmp = data; i < 32; i++) {

count = _alu(data, tmp);

tmp «= 1;

if (count > max && i) max = count;

}

for (i = 0, tmp = data; i < 32; i++) {

count = _alu(data, tmp);

tmp >>= 1;

if (count > max && i) max = count;

}

return max;

static uint32_t _random(uint32_t seed) {

static uint32_t _seed;

if (!seed)

{

_seed = _seed * RAND_MULL + RAND_ADD; _seed = _seed « 7 | _seed » 23;

}

else

seed = seed;

return seed;

uint32_t preambula(uint32_t seed, uint32_t *iter, uint32_t *coeff) {

uint32_t _rand, _coeff, _iter = 0;

_random(seed);

while (_iter < MAX_ITER)

{

_rand = _random(0);

_coeff = _factor(_rand) ;

_iter++;

if (_coeff < MAX_COEFF)

break;

}

if (iter)

• *iter = _iter;

if (coeff)

• *coeff = coeff;

return _rand;

}

Библиография

• [1] Золотарев В.В., Овечкин Г.В. Помехоустойчивое кодирование. Методы и алгоритмы: Справочник— М.: Горячая линия —Телеком, 2004

• [2] Erdal Arikan, “Channel polarization: A method for constructing capacity-achieving codes for symmetric binary-input memoryless channels” (Метод построения кодов, достигающих максимальной емкости, для симметричных двоичных каналов), URL: https://arxiv.org/abs/0807.3917, дата обращения: 05.11.2020

• [3] Li Ping, Xiaoling Huang, and Nam Phamdo, “Zigzag Codes and Concatenated Zigzag Codes” (Зигзагообразные коды и составные зигзагообразные коды), URL:

https://pdfs.semanticscholar.org/3091/6eb78443174658fbf8d4464a5bf966846399.pdf, дата обращения: 05.11.2020

• [4] Проекты компании ООО «Телематические Решения», URL: https://waviot.ru/solutions/, дата обращения: 05.11.2020

• [5] Корпоративный файловый репозиторий компании ООО «Телематические Решения», URL: https://github.com/ waviot/NBFi_WA1470, дата обращения: 05.11.2020

  УДК 004.738:006.354

  
  

ОКС 35.020,

35.110

Ключевые слова: информационные технологии, интернет вещей, протокол беспроводной передачи данных, узкополосная модуляция радиосигнала, NB-Fi

Редактор Н.В. Таланова Технический редактор В.Н. Прусакова Корректор М.И. Першина Компьютерная верстка Е.О. Асташина

Сдано в набор 09.03.2022. Подписано в печать 25.03.2022. Формат 60x84%. Гарнитура Ариал. Усл. печ. л. 6,05. Уч.-изд. л. 5,88.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.

1

Взят из log-файла обмена на тепеком-сервере WAVIoT компании ООО «Телематические Решения».

2

Взят из log-файла обмена на телеком-сервере WAVIoTкомпании ООО «Телематические Решения».