ГОСТ Р 70036-2022 Информационные технологии. Интернет вещей. Протокол беспроводной передачи данных на основе узкополосной модуляции радиосигнала (NB-Fi)

ГОСТ Р 70036-2022

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

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

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

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

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

ОКС 35.020,

35.110

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

Предисловие

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

- MAC-уровню (раздел 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 Сокращения

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

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

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

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

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

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

5.2 UPLINK-пакет

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

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

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

Наименование параметра	Значение (характеристика) параметра
Минимальная ширина полосы рабочих частот приема базовой станции	51,2 кГц
Скорость передачи данных	50, 400, 3200, 25600 бит/с
Длина пакета	288 бит
Модуляция	ОФМн-2
Справочно: предельная чувствительность приема для скорости передачи данных, бит/с:
- 50	Минус 150 дБм
- 400	Минус 141 дБм
- 3200	Минус 132 дБм
- 25600	Минус 123 дБм
Метод разделения каналов	Частотный
Количество одновременно принимаемых каналов при скорости 50 бит/с и ширине полосы частот 51,2 кГц	1024
Количество одновременно принимаемых каналов при скорости 400 бит/с и ширине полосы частот 51,2 кГц	128
Количество одновременно принимаемых каналов при скорости 3200 бит/с и ширине полосы частот 51,2 кГц	16
Количество одновременно принимаемых каналов при скорости 25600 бит/с и ширине полосы частот 51,2 кГц	1
Минимальная пропускная способность приема UPLINK-пакетов одной базовой станцией	20 Мбит/сут
Примечания 1 Ввиду малых значений ширины полосы сигналов используется относительная фазовая манипуляция с целью минимизации влияния ухода частоты опорного генератора за время отправки пакета. Для самой низкой скорости передачи (50 бит/с) время отправки 1 бита данных будет составлять 20 мс. Необходимую стабильность частоты обеспечивают кварцевые осцилляторы с температурной нестабильностью не более 0,5 ppm. 2 ОФМн-2 с низкой скоростью передачи битов данных может быть сформирована на аппаратном уровне не всеми радиотрансиверами. Для формирования данного вида модуляции может быть использована ЧМн с более высокой скоростью передачи битов данных. 3 Мощность тепловых шумов в полосе 50 Гц при температуре 290 К составляет: дБм. При входном коэффициенте шума базовой станции, равном 2 дБ, а также отношении сигнал/шум (Signal to Noise Ratio, SNR), равном 5 дБ, при котором достигается частота ошибок по битам (Bit Error Rate, BER) вычисляют предельную теоретическую чувствительность , равную: дБм. 4 Ширина рабочей полосы частот приема базовой станцией должна быть не менее значения, указанного в настоящей таблице. В данной полосе частот должен осуществляться прием одновременно всех скоростей передачи данных на всех каналах, количество которых для каждой скорости указано в настоящей таблице. 5 Частота передачи сигналов должна определяться псевдослучайным образом в пределах рабочей полосы частот в зависимости от ряда параметров. Алгоритм определения частоты передачи сигналов UPLINK-пакетов приведен в А.1 приложения А.

5.3 DOWNLINK-пакет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наименование параметра	Значение (характеристика) параметра
Номерная емкость сети	4294967296 ( ) устройств
Эффективные скорости передачи данных (UPLINK-пакет)	12,5, 100, 800, 6400 бит/с
Виды помехоустойчивого кодирования (UPLINK-пакет)	Несистематический сверточный код, несистематический полярный код
Скорость помехоустойчивого кодирования (UPLINK-пакет)	5/8
Длина полезных данных одного пакета (UPLINK-пакет)	9 байт
Эффективные скорости передачи данных (DOWNLINK-пакет)	12,5, 100, 800, 6400 бит/с
Вид помехоустойчивого кодирования (DOWNLINK-пакет)	ZIGZAG код
Скорость помехоустойчивого кодирования (DOWNLINK-пакет)	1/2
Длина полезных данных одного пакета (DOWNLINK-пакет)	9 байт
Алгоритм шифрования полезных данных	"Магма"
Используемый размер ключа	256 бит

6.2 UPLINK-пакет

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

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

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

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

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

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

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

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

, т.е. 4294967296 устройств). Порядок следования байт - от старшего к младшему.

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

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

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

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

6.2.5 Поле MIC0_7 (Имитовставка)

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

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

Поле Packet CRC содержит контрольную сумму CRC32 полей Modem_ID, 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 (входные данные для кодера помехоустойчивого кода) совместно составляют поля Modem_ID, 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 lter используется для реализации механизма защиты данных. Поле Crypto Iter должно иметь размер 8 бит. Формирование поля Crypto Iter (криптоитератора) должно выполняться в соответствии с алгоритмом, описанным в Г.2 приложения Г.

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

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

6.3.4 Поле MIC0_7 (Имитовставка)

Поле MIC0_7 используется для реализации механизма защиты данных. Поле MIC0_7 должно иметь размер 24 бита. Формирование поля MIC0_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 байт), количество пакетов, входящих в сеанс отправки, должно определяться параметром MACK. Значения MACK более единицы позволяют уменьшить количество отправляемых пакетов подтверждения приема. При групповой отправке количество пакетов, входящих в сеанс отправки, должно быть равно количеству пакетов в группе. Каждый отправляемый пакет должен содержать в своем заголовке HEADER поле ITER, которое должно инкрементироваться для каждого последующего пакета. Значения поля ITER должно изменяться в диапазоне 0-31. Передающий узел (устройство или сервер), выполняя отправку последнего пакета из группы, должен выставлять в нем флаг ACK в заголовке пакета. Данный флаг сигнализирует приемной стороне, что необходимо отправить в ответ системный пакет ACK_P.

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

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

Если передающий узел не получил ACK_P пакет в ответ на запрос, он должен повторить отправку последнего пакета по истечении заданного интервала времени (тайм-аута) 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, перечисление г)]. Повторная отправка пакетов, вызванная получением ACK_P пакета, также должна входить в расчет общего числа повторов и быть ограничена параметром 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 приведен пример успешной отправки группового пакета*. В рамках данного сеанса выполнена отправка трех пакетов с итераторами 14-16. В ответ на пакет с итератором 16, содержащий флаг ACK, сервер отправил ACK_P пакет с маской, сообщающей, что сообщения с итераторами 14-16 успешно приняты. Приняв данный пакет, передающий узел отправил CLEAR_T-пакет, означающий успешное завершение сеанса и содержащий информацию о текущем времени устройства.

_________________

* Взят из log-файла обмена на телеком-сервере WAVIoT компании ООО "Телематические Решения".

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

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

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

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

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

г) передающий узел, получив ACK_P пакет, отправил повторно пакет с итератором 26, запросив подтверждение доставки;

д) сервер получил пакет с итератором 26, успешно сформировал групповой пакет и отправил устройству ACK_P пакет, подтверждающий прием данного пакета;

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

При достаточно высоком значении SNR (

SNRLEVEL_FOR_UP+TXSNRDEG либо

NRLEVEL_FOR_UP+RXSNRDEG) устройство должно выполнять перевод скорости на один уровень выше. Так как базовая станция принимает одновременно все поддерживаемые скорости передачи UPLINK-пакетов, смена скоростей UPLINK должна осуществляться без уведомления сервера. При смене скорости DOWNLINK-пакетов устройство должно выполнять отправку системного SYNC пакета, содержащего новые параметры скоростного режима. Данный пакет должен формироваться с флагом ACK и требовать подтверждения приема. В ответ на данный системный пакет сервер должен отправлять SACK_P-пакет (см. 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 в пакете ACK_P, отправляемом от устройства к серверу.

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

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

Пороговые уровни для повышения и понижения скоростей либо мощности и поправочные коэффициенты для различных скоростей приведены в таблицах 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 приведен пример сеанса обмена пакетами, выполняющий повышение скоростей передачи и приема*.

_________________

* Взят из log-файла обмена на телеком-сервере WAVIoT компании ООО "Телематические Решения".

Рисунок 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 с, то сервер должен сохранить это значение и при следующем сеансе обмена выполнить коррекцию системного времени устройства, отправив величину данной поправки внутри пакета ACK_P. Формат пакета ACK_P описан в 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 - флаг системного пакета;

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

- MULTI:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 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 Пакет ACK_P (подтверждение приема пакетов)

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

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

Таблица 20 - Структура формата пакета ACK_P

а) MASK

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

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

MASK0	MASK1	MASK2	MASK3
bit 0: статус пакета с итератором ( -32)	bit 0: статус пакета с итератором ( -24)	bit 0: статус пакета с итератором ( -16)	bit 0: статус пакета с итератором ( - 8)
-	-	-	-
bit 7: статус пакета с итератором ( -25)	bit 7: статус пакета с итератором ( -17)	bit 7: статус пакета с итератором ( -9)	bit 7: статус пакета с итератором ( -1)

Примечание -

-итератор ACK_P пакета равен итератору принятого пакета, в ответ на который отправлен ACK_P.

Статус сообщения с текущим итератором

не включен в маску, так как факт получения пакета ACK_P подтверждает успешность доставки пакета с текущим итератором.

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

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

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

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

г) MFLAGS

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

Таблица 22 - Структура формата поля MFLAGS при передаче ACK_P от сервера к устройству

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

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

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

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

Таблица 23 - Структура формата поля MFLAGS при передаче ACK_P от устройства к серверу

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

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

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

Старший бит:	1, если 3 В.
Младшие 7 бит:	десятые доли вольта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а) GROUP_LEN

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

б) GROUP_CRC

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

в) PAYLOAD_0_4

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

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

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

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

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

а) SET_FPLAN

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

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

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

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

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

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

б) BS_OR_SERVER_ID

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

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

При SET_FPLAN

4104 параметр BS_OR_SERVER_ID содержит идентификатор SERVER_ID.

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

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

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

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

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

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

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

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

а) 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, перечисления г)-ш).

г) Значение поля CONF_DATA для параметра NBFI_PARAM_MODE (PARAM=0x00)

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

NBFI_MODE - режим работы транспортного уровня протокола 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.

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

Описание структуры формата поля CONF_DATA для параметра 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.

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

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

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

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

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

При TXFREQ

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

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

ж) Значение поля CONF_DATA для параметра NBFI_PARAM_RXFREQ (PARAM = 0x04)

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

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

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

вычисляют в соответствии с алгоритмом, приведенным в А.2 приложения А.

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

При RXFREQ

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

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

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

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

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

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

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

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

к) Значение поля CONF_DATA для параметра NBFI_PARAM_HEART_BEAT (PARAM=0x07)

Описание структуры формата поля CONF_DATA для параметра 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

л) Значение поля CONF_DATA для параметра NBFI_PARAM_TX_BRATES (PARAM=0x08) Описание структуры формата поля CONF_DATA для параметра NBFI_PARAM_TX_BRATES приведено в таблице 44.

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

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

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

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

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

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

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

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

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

н) Значение поля CONF_DATA для параметра NBFI_PAFRAM_VERSION (PAFRAM=0x0A)

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

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

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

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

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

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

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

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

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

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

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

Таблица 47 - Структура формата поля CONF_DATA для параметра 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 - данный флаг отключает автоматическую отправку информационных пакетов.

FLG_SEND_ALOHA - данный флаг включает режим отправки данных "ALOHA", при котором каждый пакет MAC-уровня отсылается дважды на различных частотах с целью снижения вероятности потери пакета в результате коллизии.

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".

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

Описание структуры формата поля 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 ACK_P пакета. Допустимые значения: от 0 до 127 дБ.

Примечания

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

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

с) Значение поля CONF_DATA для параметра NBFI_UL_BASE_FREQ (PARAM=0x0D)

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

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

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

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

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

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

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

у) Значение поля CONF_DATA для параметра NBFI_QUALITY_EX (PARAM=0x0F)

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

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

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

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

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

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

Примечания

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

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

ф) Значение поля CONF_DATA для параметра APP_IDS (PARAM=0x11)

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

Таблица 53 - Структура формата поля CONF_DATA для параметра APP_IDS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WAIT_ACK_TIMEOUT - параметр, определяющий время ожидания приема ACK_P пакета, подтверждающего получение данных.

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

При 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);

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

MIC0_7 - младшие 8 бит имитовставки (см. 6.2.5);

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

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

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

. (А.1)

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

. (А.2)

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

, если

, (А.3)

, если

. (А.4)

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

. (А.5)

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

, если

, (А.6)

, если

. (А.7)

А.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);

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

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

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

. (А.8)

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

. (А.9)

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

, если

, (А.10)

, если

. (А.11)

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

. (А.12)

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

, если

, (А.13)

, если

. (А.14)

Приложение Б

(справочное)

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

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

Отправка UPLINK-пакетов устройствами осуществляется на известной (предполагаемой) частоте

, вычисляемой по формулам (А.6) и (А.7).

Отправка DOWNLINK-пакетов базовой станцией осуществляется на известной (предполагаемой) частоте

, вычисляемой по формулам (А.13) и (А.14).

Базовая станция, принимая пакет, вычисляет частоту приема

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

по формуле

. (Б.1)

В состав данной ошибки входят как погрешность передатчика оконечного устройства

, так и ошибка измерения частоты базовой станцией

, таким образом

. (Б.2)

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

Передатчик базовой станции, используемый для отправки DOWNLINK-пакетов, также с определенной периодичностью (например, каждые 5 мин) отправляет UPLINK-пакеты на фиксированной частоте

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

и затем значение обобщенной ошибки частоты

по формуле

. (Б.3)

В состав данной ошибки входят как погрешность передатчика базовой станции

, так и ошибка измерения частоты базовой станцией

, таким образом

. (Б.4)

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

и вычитанием обобщенной ошибки

по формуле

. (Б.5)

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

, вычисляют фактическое значение частоты отправки

по формуле

. (Б.6)

Для успешного приема сообщения данная частота

должна соответствовать фактической частоте приема модема

, которая равна:

. (Б.7)

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

. (Б.8)

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

. (Б.9)

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

. (Б.10)

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

. (Б.11)

Приложение В

(справочное)

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

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

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++]=Modem_ID [3];

ul_buf [len++]=Modem_ID [2];

ul_buf [len++]=Modem_ID [1];

ul_buf [len++]=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++]=(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;

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<sizeof (protE_preambula); 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;

}

В.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<sizeof (preamble); i++)

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

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, tx_freq);

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

return OK;

}

В.3 Функция вычисления контрольной суммы CRC8

static unsigned char CRC8byte (unsigned char data)

{

uint8_t crc=0;

if (data & 1) crc^=0x5e;

if (data & 2) crc^=0xbc;

if (data & 4) crc^=0x61;

if (data & 8) crc^=0xc2;

if (data & 0x10) crc^=0x9d;

if (data & 0x20) crc^=0x23;

if (data & 0x40) crc^=0x46;

if (data & 0x80) crc^=0x8c;

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;

}

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

#define POLY 0xa001

uint16_t CRC16 (uint8_t *buf, uint16_t len, uint16_t crc)

{

while (len--)

{

crc^=*buf++;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

crc=crc & 1 ? (crc>>1) ^ POLY : crc>>1;

}

return crc;

}

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

uint32_t CRC32 (const uint8_t *buf, uint8_t len)

{

return digital_update_crc32 (0xf f f f f f f f, buf, len) ^ 0xf f f f f f f f;

}

#define WIDTH (8*4)

#define TOPBIT (1 << (WIDTH-1))

#define POLYNOMIAL (0x104C11DB7)

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=(c<<1) ^ POLYNOMIAL;

}

else

{

c=c<<1;

}

}

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) & 0xff)) ^ (crc<<8);

data++;

len--;

}

return crc;

}

Приложение Г

(обязательное)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый комплект ключей должен действовать для обработки 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" должно обрабатываться не более

пакетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	- ключи, длиной 256 бит;
	- стартовый вектор 32 бит;
	- открытый текст;
	- закрытый текст (зашифрованные данные);
	- количество повторяемых байт;
	- корневой ключ;
	- мастер-ключ;
	- рабочий ключ;
	- ключ имитозащиты;
	- ключ отправляемых пакетов данных;
	- ключ принимаемых пакетов данных;
	- полный криптоитератор.

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

. (Г.1)

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

, (Г.2)

. (Г.3)

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

, (Г.4)

, (Г.5)

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

, (Г.6)

, (Г.7)

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

, (Г.8)

. (Г.9)

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

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

. (Г.10)

Для стартового вектора

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

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

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

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

. (Г.11)

Приложение Д

(обязательное)

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

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

#define 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, 0, 0, 0, 0, 0, 0, 0};

void conv_encoder (umt8_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 u1=input_b [n];

_Bool u2=input_b [n];

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

{

if (G_polys [0] [m])

u1=u1 ^ state [m-1];

if (G_polys [1] [m])

u2=u2 ^ state [m-1];

}

output_d [n * 2]=u1;

output_d [n * 2+1]=u2;

for (int i=constraint_length; i>0; i--)

state [i]=state[i-1];

state [0]=input_b [n];

}

uint16_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, 163,

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

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

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

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

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

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 sl;

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) << 1);

out [i]=out [i] ^ ((out [i] & 0x33) << 2);

out [i]=out [i] ^ ((out [i] & 0x0F) << 4);

}

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

{

sl=(1 << (i-2));

uint32_t temp=(1 << (power - 3)) / sl;

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 b0;

uint8_t b1;

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++)

{

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

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

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

res=b0 ^ b1 ^ bprev;

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

}

}

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

{

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

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

}

}

Приложение И

(справочное)

Описание системы, использующей протокол NB-Fi

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

И.1 Архитектура системы

Архитектура системы состоит из четырех уровней и включает в себя:

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

2) базовые станции, осуществляющие прием, обработку и передачу сообщений от устройств (UPLINK-пакеты) на сервер NB-Fi, а также отправку нисходящих сообщений на устройства (DOWNLINK-пакеты);

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

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

И.2 Описание устройств

Устройства, используемые для сбора данных с приборов учета в сфере жилищно-коммунального хозяйства, построены с использованием интегрального радиотрансивера К5553ВВ015, поддерживающего аппаратную реализацию физического и MAC-уровня протокола 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°С до плюс 70°С.

И.3 Описание базовых станций

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

Для приема восходящих пакетов данных (UPLINK-пакетов) со стороны Базовой станции NB-Fi применяется принцип SDR-систем (Software-Defined Radio), где входной радиосигнал оцифровывается во всей полосе приема 51,2 кГц, и в дальнейшем подвергается программной обработке. Прием пакетов выполняется Базовой станцией NB-Fi по всей полосе частот, при этом выделяются одновременно пакеты, имеющие различные скорости. Теоретическое количество каналов составляет 1024 для скорости 50 бит/с, и 128, 16 и 1 для скоростей 400, 3200 и 25600 бит/с соответственно.

Передача нисходящих пакетов данных (DOWNLINK-пакетов) выполняется при помощи цифрового модулятора сигнала, позволяющего передавать одновременно несколько узкополосных каналов, если суммарная мощность передачи не превышает установленного значения. Передача осуществляется в полосе 102,4 кГц.

Для работы сети передачи данных по протоколу NB-Fi в Российской Федерации используется нелицензируемый в Российской Федерации диапазон частот 868,7-869,2 МГц. Максимальная выходная мощность передачи Базовой станции NB-Fi составляет 100 мВт.

В некоторых вариантах реализации Базовая станция NB-Fi может обладать следующими характеристиками:

- рабочий температурный диапазон составляет от минус 50°С до плюс 70°С;

- степень защиты корпуса от проникновения пыли и воды соответствует IP66 по ГОСТ 14254;

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

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

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

И.4 Описание сервера NB-Fi

Функциями сервера NB-Fi являются:

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

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

- дешифрование данных MAC-уровня и отбрасывание пакетов, не прошедших проверку целостности данных;

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

- реализация функций транспортного уровня 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_

#define _PREAMBULA_H_

#ifdef _cplusplus

extern "C"

{

#endif

#include <stdint.h>

#define RAND_MULL 0x1234

#define RAND_ADD 0x10

#define MAX_ITER 100

#define MAX_COEFF 6

uint32_t preambula (uint32_t seed, uint32_t *iter, uint32_t *coeff);

#ifdef _cplusplus

}

#endif

#endif

//preambula.c

#include "preambula.h"

#include <stdint.h>

#include <stdlib.h>

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;

}

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