ФЕДЕРАЛЬНОЕ АГЕНТСТВО
ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
пнет
354— 2019
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационные технологии ИНТЕРНЕТ ВЕЩЕЙ
Протокол беспроводной передачи данных на основе узкополосной модуляции радиосигнала (NB-Fi)
Издание официальное
Москва Стамдартимформ 2019
Предисловие
1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Телематические Решения» (ООО «Телематические Решения»), Акционерным обществом «Российская венчурная компания» (АО «РВК»), Фондом развития интернет-инициатив (ФРИИ). Ассоциацией участников рынка интернета вещей и Некоммерческим партнерством «Русское общество содействия развитию биометрических технологий, систем и коммуникаций» (Некоммерческое партнерство «Русское биометрическое общество»)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 «Киберфизические системы»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому ре* гулированию и метрологии от 19 февраля 2019 г. № 7-пнст
Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТР 1.16—2011 (разделы 5 и 6).
Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 143026 Москва, территория инновационного центра Сколково. ул. Нобеля, д. 5. лом. 334. тел. 8 (800) 550-51-89. е-таН: info@waviot.ru и/или в Федеральное агентство по техническому регулированию и метрологии: 109074 Москва. Китайгородский проезд, д. 7. стр. 1.
В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.nj)
© Стацдартинформ. оформление. 2019
Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и рас* пространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии
Содержание
1 Область применения
2 Нормативные ссылки
3 Термины и определения
4 Сокращения
5 Физический уровень (Physical layer)
5.1 Общие положения
5.2 UPLINK-пакет
5.3 DOWNLINK-пакет
5.4 Режим работы LBT (Listen Before Talk)
6 МАС-уровень (Media Access Control layer. MAC)
6.1 Общие положения
6.2 UPLINK-пакет
6.3 DOWNLINK-пакет
6.4 Шифрование поля Payload
7 Транспортный уровень (Transport layer)
7.1 Общие положения
7.2 Описание пакетов данных транспортного уровня
8 Уровень представления (Presentation layer)
8.1 Общие положения
8.2 Описание пакетов данных уровня представления
Приложение А (справочное) Описание алгоритма компенсации нестабильности частот
задающего генератора
Приложение Б (справочное) Фрагменты исходных кодов реализации МАС-уровня
Приложение В (справочное) Таблица и функции, используемые для ZIGZAG-кодирования данных
Приложение Г (справочное) Описание транспортных функций и сценариев взаимодействия
Приложение Д (справочное) Описание механизма автоматического выбора оптимальной скорости передачи данных
Приложение Е (справочное) Настройка параметров NB*Fi
Приложение Ж (справочное) Защита данных в протоколе NB-Fi
Приложение И (справочное) Примеры использования протокола NB-Fi
Библиография
Введение
Настоящий стандарт предназначен для построения беспроводных сетей обмена данными между множеством конечных устройств (модемов) с одной стороны и множеством базовых станций с другой стороны. Настоящий стандарт предусматривает возможность дальнейшей интеграции данных е единое серверное пространство. Объединение всех конечных устройств (модемов) в единый сервер позволяет эффективно организовать обмен данными с различными «облачными» сервисами.
Беспроводные сети, построенные с применением стандарта NB-Fi, являются сетями класса LPWAN (Low-power Wide-area Network — энергоэффективная сеть дальнего радиуса действия), кото* рые характеризуются высокой энергоэффективностью передачи данных и высокой емкостью сети, что позволяет использовать стандарт NB-Fi для построения телеметрических систем с большим количе* ством абонентов. Высокая энергоэффективность дает возможность применять в работе нелицензируе-мые диапазоны частот, в которых установлены ограничения на излучаемую передатчиками мощность. В основе стандарта лежит использование сверхузкополосных (Ultra Narrow Band. UNB) фазоманипу-лированных сигналов, которые в сочетании с помехоустойчивым кодированием позволяют достигать очень высоких значений чувствительности приема (не менее минус 150 дБм), при этом суммарная по* лоса частот для одновременной передачи большого количества каналов является достаточно узкой.
Сеть NB*Fi, по аналогии с мобильными сетями, использует топологию «звезда». В подобной архитектуре узловые элементы — базовые станции — должны осуществлять прием и передачу многих каналов одновременно. Для передачи множества каналов необходимо увеличение выходной мощности передатчика базовой станции. Работа в нелиценэируемых диапазонах частот накладывает ограничение на выходную мощность передатчика, в том числе и для базовой станции. Поэтому для всех LPWAN-сетей концептуальной является проблема ограничения пропускной способности нисходящего канала связи.
Для приема восходящих пакетов (UPLINK-пакетов) данных со стороны базовой станции применяется принцип SDR-систем (Software-Defined Radio — программно-определяемая радиосистема), где входной радиосигнал оцифровывается во всей полосе приема и в дальнейшем подвергается программной обработке. Это позволяет выполнять демодуляцию и декодирование входных пакетов данных одновременно по всем каналам во всей полосе частот. По сути, в данной системе не существует сетки каналов, пакет данных принимается базовой станцией вне зависимости от частоты, на которой выполнена отправка. Это является ключевым свойством стандарта, позволяющим использовать недорогие генераторы частоты для формирования радиосигнала, что ранее было ограничивающим фактором при использовании UNB-сигналое. Ввиду применения простых видов модуляции UPLINK-пакеты могут быть сформированы при помощи практически любого серийного интегрального радиотрансивера. Прием UPLINK-пакетов возможен только базовой станцией. В связи с этим для реализации передачи пакетов данных в обратном, нисходящем (DOWNLINK) направлении применяются виды модуляции и скорости передачи, поддерживаемые конкретным радиотрансивером, который используется в конечных устройствах.
Настоящий стандарт подходит для телеметрических систем, в которых преобладает передача данных в восходящем направлении (от устройств к серверу). Обратный канал предназначен для передачи служебной информации сети (подтверждение доставки пакетов, регулирование скорости связи) и для отправки данных для конфигурирования и смены режимов работы устройств.
Для производства конечных устройств и базовых станций могут быть также использованы специализированные радиотрансиверы, которые позволяют использовать UPLINK-пакеты для передачи данных в обоих направлениях. При этом решается проблема ограничения пропускной способности нисходящего канала связи в LPWAN-сети — объемы данных, передаваемых в восходящем и нисходящем направлении, совпадают. Физический уровень протокола NB-Fi в этом случае реализован в самом радиотрансивере.
ПНСТ 354—2019
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационные технологии
ИНТЕРНЕТ ВЕЩЕЙ Протокол беспроводной передачи данных на основе узкополосной модуляции радиосигнала (NB-Fi)
Information technology. Internet of things. Wireless protocol based on narrow band RF modulation (NB-Fi)
Срок действия — с 2019—04—01 до 2022—04—01
1 Область применения
В настоящем стандарте установлены требования к протоколу обмена для интернета вещей в узкополосном спектре (NB-Fi). включая требования:
- к физическому уровню (раздел 5);
- МАС-уровню (раздел в);
* транспортному уровню (раздел 7):
- уровню представления (раздел 8).
2 Нормативные ссылки
8 настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ 14254 (МЭК 529—89) Степени защиты, обеспечиваемые оболочками (код IP)
ГОСТ Р 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры
Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение. в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссыпку.
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 радиотрансивер: Интегральная схема, предназначенная для приема-передачи данных с использованием радиосигналов (в том числе посредством протокола NB-Fi).
3.2 устройство приема-передачи данных/модем: Программно-аппаратный комплекс со встроенным радиотрансивером, являющийся либо самостоятельным оборудованием, либо встроенным
Издание официальное
компонентом в конечное устройство, применяемый для приема или передачи данных с использованием радиитрансивера.
3.3 конечное устройство: Оборудование с устройством приема-передачи данных (модемом).
3.4 пакет восходящего направления (UPLINK-пакет): Пакет данных, передаваемый устройствами и принимаемый базовыми станциями.
3.5 пакет нисходящего направления (DOWNLINK-пакет): Пакет данных, передаваемый передатчиком базовой станции и принимаемый устройствами.
4 Сокращения
В настоящем стандарте применены следующие сокращения:
ФМн-2 — двоичная фазовая манипуляция несущей;
ОФМн-2 — относительная двоичная фазовая манипуляция несущей;
ЧМн — частотная манипуляция несущей;
«Магма* — алгоритм симметричного блочного шифрования согласно ГОСТ Р 34.12.
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. 25 600 бит/с |
Модуляция | ОФМн-2 |
Предельная чувствительность приема для скорости передачи данных, бит/с: - 50 | Минус 150 дБм |
- 400 | Минус 141 дБм |
• 3200 | Минус 132 дБм |
• 25 600 | Минус 123 дБм |
Метод разделения каналов | Частотный |
Количество одновременно принимаемых каналов при скорости 50 бит/с | 1024 |
Количество одновременно принимаемых каналов яри скорости 400 бит/с | 128 |
Количество одновременно принимаемых каналов при скорости 3200 бит/с | 16 |
Окончание таблицы 1
Наименование параметра | Значение (характеристика) параметра |
Предельная пропускная способность приема UPLINK-паквтов одной базовой станцией | 20 Мбит/сут |
Коэффициент ошибочных пакетов | Не более 5 % |
Примечания
ЛГ= -174 * 10 • togl050 = -157 дБм. При входом коэффициенте шума базовой станции, равном 2 дБ. а также отношении сигнап/шум (Signal to Noise Ratio. SNR), равном 5 дБ. при котором достигается частота ошибок по битам (Bit Error Rate. BER) BER = 10"&. вычисляют предельную теоретическую чувствительность S. равную: S = -157 + 2 + 5 =-150 д&м.
|
5.3 DOWNLINK-лакет
DOWNLINK-пакет представляет собой модулированные последовательности двоичных данных, сгруппированных в байты.
Описание DOWNLINK-лакета приведено е таблице 2. Значения параметров, приведенных в таблице 2. определены для диапазона рабочих температур от минус 40 °C до плюс 70 *С.
Таблица 2 — Основные технические характеристики DOWNLINK-лакета
Наименование параметра | Значение {характеристика] параметра |
Полоса рабочих частот (суммарная полоса приема базовой станцией) | 100 кГц |
Скорость передачи данных | 200. 500. 5000. 57 600 бит/с |
Модуляция | ФМн-2 |
Предельная чувствительность приема | Минус 139 дБм |
Метод разделения каналов | Частотно-временной |
Предельная пропускная способность приема DOWN-LINK-пакетов одной базовой станцией | 10 Мбит/сут (при условии работы 100 % устройств на скорости DOWNLINK 57 600 бит/с) |
Коэффициент ошибочных пакетов | Не более 5 % |
Вид модуляции и скорости передачи данных выбраны таким образом, чтобы обеспечить наилучший уровень входной чувствительности при использовании серийных радиотрансиверов, присутствующих на рынке на момент написания настоящего стандарта. Предельные значения чувствительности приема подобных радиотрансиверов составляют значение порядка минус 139 дБм. При использовании скоростей 200 и 500 бит/с неточность формирования частоты задающим генератором может приводить к возникновению проблем, связанных с несовпадением частот передатчика и приемника, что вызывает потери пакетов. Для решения этой проблемы применяется алгоритм компенсации нестабильности частот задающих генераторов. Описание алгоритма компенсации нестабильности частот задающего генератора приведено в приложении А.
5.4 Режим работы LBT (Listen Before Talk)
При включенном режиме работы LBT (Listen Before Talk — «Слушай, прежде чем сказать») устройство. прежде чем выполнить переход в режим передачи для отправки пакетов, должно переключиться в режим оценки уровня сигнала в полосе частот, в которой предполагается отправка данных. Если уровень сигнала не превышает установленного значения, что означает отсутствие передачи другим устройством, то переход в режим передачи и отправка данных могут быть выполнены. В противном случае устройство не должно выполнять передачу до тех пор. пока уровень сигнала в данной полосе частот не упадет ниже установленного значения. Для включения/выключения режима работы LBT используют конфигурационный флаг транспортного уровня FLGJ.BT [см. 7.2.2.2. перечисление г)].
6 МАС-уровень (Media Access Control layer, MAC)
6.1 Общие положения
МАС-уровень обеспечивает передачу датаграммы (информационного пакета) на выбранном физическом уровне и описывает следующие параметры:
- формат полей пакета;
« способы адресации:
- методы защиты данных;
• методы контроля целостности данных;
- методы восстановления ошибок.
Описание МАС-уровня приведено в таблице 3. Значения параметров, приведенных в таблице 3. определены для диапазона рабочих температур от минус 40 *С до плюс 70 ‘С.
Таблица 3 — Основные технические характеристики МАС-уровня
Наименование параметра | Значение (характеристика) параметре |
Номерная емкость сети | 4.3 млрд устройств |
Эффективные скорости передачи данных (UPLINK-пэкет) | 10. 80.640. 5120бит/с |
Вид помехоустойчивого кодировашя | ZIGZAG |
Скорость помехоустойчивого кодирования | 1/2 |
Длина полезных данных одного пакета | 8 байт |
Эффективные скорости передачи данных (DOWNLINK-пакет) | В зависимости от реализации конкретного радиотран-сивера |
Вид помехоустойчивого кодирования (DOWNLINK-пакет) | В зависимости от реализации конкретного радиотран-сивера |
Скорость помехоустойчивого кодирования | В зависимости от реализации конкретного радиотран-сивера (1/2.1/3 и т. п.) |
Длина полезных данных одного пакета | От 8 до 128 байт |
Алгоритм шифрования полезных данных | «Магма» |
Испогъзуемый размер ключа | 256 бит |
Примечание — Вместо алгоритма шифрования «Магма» возможно использование другого алгоритма блочного симметричного шифрования со следующими параметрами: размер блока данных — 64 бита, размер ключа — 256 бит, при наличии достаточных оснований для этого. При этом использование других алгоритмов, не являющихся российским стандартом, может накладывать ограничения на сферу применения настоящего стандарта. |
6.2 UPLINK-пакет
Общая длина UPLINK-пакета должна составлять 40 байт. Размер поля Payload (полезные данные) должен составлять 8 байт. Соотношение эффективной скорости передачи данных к физической должно составлять 2/10. Программный код реализации функции формирования UPLINK-пакета на языке Си приведен в разделе Б.1 приложения Б.
Формат UPLINK-пакетов и рабочая полоса частот одинаковы для различных скоростей передачи данных. Порядок следования бигов в байтах UPLINK-пакета — от старшего к младшему.
Структура формата UPLINK-пакета приведена в таблице 4.
Таблица 4 — Структура формата UPLINK-пакета
Л н * 2 | & Н •о ? S о ? 1 г 5 ? I в Q. С | Data (Данные) | Error detection and correction (Определение ошибки и коррекция) | ||||||||||||||
Header (Заголовок) | С? 3 5 о 2-» a S S £ | Payload CRC (Контрольная суыыа полезных данных) | Packet CRC (Контрольная сумма пакета данных) | 9 9 9 0 9 3 N | |||||||||||||
§ о | ю X о | гЗ к е | 5 | СП О | 8 | Б | 8 | 7 | 6 | 5 | 4—0 | 8 байт | CRC-16 | см | см 9 2 О | см 9 Q | 18 байт |
SYS | АСК | MULTI | ITER | ||||||||||||||
Zigzag source (18 байт) |
6.2.1 Поле Preamble (Преамбула)
Преамбула служит для обнаружения пакета в эфире. Алгоритм демодуляции, реализованный в базовой станции, использует данное поле для обнаружения пакета в эфире и синхронизации его последующей обработки.
6.2.2 Поле Node ID (Идентификатор, присвоенный устройству)
Поле Node ID содержит идентификатор, присвоенный устройству. Поле Node ID должно иметь размер 32 бита [для номерной емкости сети, составляющей 232 (4 294 967 296) устройств]. Порядок следования байт — от старшего к младшему.
6.2.3 Лоле Data (Данные)
Поле Data обрабатывается транспортным уровнем. Поле Data является составным и должно содержать два поля: поле Header (Заголовок) и поле Payload (Полезные данные).
6.2.3.1 Поле Header (Заголовок)
Поле Header является заголовком пакета. Поле Header должно иметь размер 1 байт. Поле Header должно состоять из трех системных флагов и поля ITER (см. раздел 5).
6.2.3.2 Поле Payload (Полезные данные)
Поле Payload должно иметь размер 8 байт. Данное поле может быть зашифровано с помощью блочного кода «Магма» (см. раздел 6.4).
6.2.4 Поле Payload CRC (Контрольная сумма полезных данных)
Поле Payload CRC содержит контрольную сумму незашифрованного содержимого поля Payload и поля Header. Поле Payload CRC должно иметь размер 2 байта. Поле Payload CRC используется также при вычислении частоты отправки пакета. Программный код реализации функции вычисления данного параметра на языке Си приведен в разделе Б.З приложения Б.
6.2.5 Поле Packet CRC (Контрольная сумма пакета данных)
Поле Packet CRC содержит контрольную сумму полей Node ID. Header. Payload CRC и зашифрованного содержимого поля Payload. Используются три младших байта данного значения. Программный код реализации функщы вычисления данного параметра (CRC32) на языке Си приведен в разделе Б.4 приложения Б.
6.2.6 Поле Zigzag code
Поле Zigzag code должно содержать помехоустойчивый код. вычисляемый на основании данных поля Zigzag source. Используемые таблицы данных для кодирования и декодирования, а также исходные коды программной реализации помехоустойчивого кодирования на языке Си приведены в приложении В.
6.3 DOWNLINK-пакет
Пакеты данного типа формируются при помощи аппаратной реализации используемого радиотрансивера. Внутри поля полезных данных пакета, сформированного средствами используемого радиотрансивера. должны быть размещены поле адреса, поле данных транспортного уровня и поле контрольной суммы.
Структура доля данных транспортного уровня DOWNLINK-пакета приведена в таблице 5.
Таблица 5 — Структура поля данных транспортного уровня DOWNLINK-пакета
Node ID (Идентификатор, присвоенный устройству) | Data (Данные) | Payload CRC (Контрольная сумма полезных данных) | |||||||
Header (Заголовок) | Payload (Полезные данные) | ||||||||
ID3 | 1D1 | IDO | CRC- 16 | 7 | 6 | 5 | 4—0 | От 8 до 128 байт, блоками по 8 байт | CRC-16 |
SYS | АСК | MULTI | ITER |
6.3.1 Лоле Node ID (Идентификатор, присвоенный устройству)
Поле Node ID содержит идентификатор, присвоенный устройству. Поле Node ID должно иметь размер 32 бита [для номерной емкости сети, составляющей 232 (4 294 967 296) устройств]. Порядок следования байт — от старшего к младшему.
6.3.2 Поле Data (Данные)
Поле Data обрабатывается транспортным уровнем. Поле Data является составным и должно содержать два поля: поле Header (Заголовок) и поле Payload (Полезные данные).
6.3.2.1 Поле Header (Заголовок)
Поле Header является заголовком пакета. Поле Header должно иметь размер 1 байт. Поле Header должно состоять из трех системных флагов и поля ITER (см. раздел 5).
6.3.2.2 Поле Payload (Полезные данные)
Поле Payload должно иметь размер от 8 до 128 байт, кратно 8 байтам. Данное поле может быть зашифровано при помощи блочного кода «Магма» (см. раздел 6.4).
6.3.3 Поле Payload CRC (Контрольная сумма полезных данных)
Поле Payload CRC содержит контрольную сумму незашифрованного содержимого поля Payload и поля Header. Поле Payload CRC должно иметь размер 2 байта. Поле Payload CRC используется также при вычислении частоты отправки пакета. Программный код реализации функции вычисления данного параметра на языке Си приведен в разделе Б.З приложения Б.
6.4 Шифрование поля Payload
Шифроеание данных должно быть выполнено как для UPLINK-пакетов, так и для DOWNLINK-лакетов. Для шифрования следует применять алгоритм «Магма» с использованием уникального для каждого устройства ключа длиной 256 бит.
Ключ шифрования может быть записан в устройство при производстве, выделен в процессе работы устройства или отсутствовать. Значение ключа, имеющее все нули или все единицы во всех 256 битах. означает отсутствие шифрования данных.
Ключ шифрования, выделенный устройству при производстве либо в процессе работы, также сохраняется на сервере. Наличие ключа шифрования на сервере обеспечивает возможность расшифровки поля Payload.
Шифрование поля Payload для DOWNLINK-пакетов выполняется по всей длине поля блоками по 8 байт.
Механизм выделения нового ключа шифрования МАС-уровня описан в разделе Г.7, приложения Г.
7 Транспортный уровень (Transport layer)
7.1 Общие положения
Транспортный уровень обеспечивает механизмы передачи пользовательских данных и управляющих команд между базовой станцией и устройствами в условиях нестабильной связи, реализуя следующие функции:
• подтверждения доставки сообщений;
- повторной отправки данных;
- разбиения больших пакетов данных на фрагменты и последующего их «склеивания»:
• буферизации отправки данных;
• синхронизации системного времени;
- конфигурирования режимов работы:
• автоматического выбора режима работы (скорости, мощности передачи);
• смены ключа шифрования МАС-уроеня.
Также на транспортном уровне реализованы алгоритмы анализа качества сигнала и выбора оптимальной скорости передачи данных. Дополнительно на транспортном уровне реализован механизм конфигурирования всех параметров функционирования устройства NB-Fi.
Ключевые особенности транспортного уровня NB-Fi. позволяющие протоколу в наибольшей степени соответствовать задачам построения LPWAN-сетей:
• низкое количество «накладных» данных, используемых для транспортного уровня:
- организация группового квитирования пакетов, позволяющего экономить использование канала связи при подтверждении приема;
• реализация специальных режимов работы для устройств с батарейным питанием.
Для передачи данных от устройства к базовой станции используются UPLINK-лакеты. Для передачи данных от базовой станции к устройству применяются DOWNLINK-пакеты либо UPLINK-пакеты для устройств, построенных на специализированных радиотрансиверах. Допускается работа в режиме передачи данных от устройства к устройству («peer-to-peer»), при этом используются DOWNLINK-пакеты либо UPLINK-паквты для устройств, построенных на специализированных радиотрансиверах.
Реализация функций транспортного уровня предполагает буферизацию пакетов данных в виде программного стека. Минимальная глубина приемного буфера составляет 32 пакета. Это обусловлено разрядностью поля ITER (итератор), равной 5 бит. которое используется для циклической нумерации всех пакетов и их последующей идентификации при запросах повторной отправки. Таким образом, передающий узел должен хранить по крайней мере 32 последних отправленных пакета для их возможной переотправки при последующем обмене данными.
Основные режимы работы транспортного уровня и их описание приведены в таблице 6.
Таблица 6 — Основные режимы работы транспортного уровня и их описание
Режим работы | Описание |
NRX(NoRX) | Передача данных от устройства к серверу Устройство передает данные при необходимости, остальное время модем находится в режиме «сон». Не поддерживаются переотправка «потерянных» данных и режим автоматического выбора оптимальной скорости связи |
DRX (Discontinuous RX) | Передача данных в обоих направлениях Устройство передает данные при необходимости и переходит в режим приема на непродолжительное время сразу после окончания передачи. Сервер буферизирует все запросы на отправку данных устройству и выполняет передачу данных во время «открытия» временного «окна», когда устройство переходит в режим приема. Возможна работа в режиме переотправки «потерянных» данных и режиме автоматического выбора скоростей. Данный режим используют для устройств с батарейным питанием |
CRX (Continuous RX) | Передача данных в обоих направлениях Устройство передает данные при необходимости, в остальное время находится в режиме приема. Отправка данных на устройство с сервера возможна в любой момент. Все функции протокола работают е полном объеме. Возможна передача данных epeer-to-peer». Данный режим испогъзуют для устройств со стационарным питанием либо для кратковременного перехода в нега с целью обмена «peer-to-peer» |
7.2 Описание пакетов данных транспортного уровня
7.2.1 Формат пакета транспортного уровня в общем виде
Структура формата пакета транспортного уровня в общем виде приведена в таблице 7.
Таблица 7 — Структура формата пакета транспортного уровня в общем виде
HEADER (Загоном*) | DATA(Данные) | |||
SYS | АСК | MULTI | ITER | |
1 бит | 1 бит | 1 бит | 5 бит | от 1 до MAXLEN байт |
Описание полей:
• SYS —флаг системного пакета;
• АСК — флаг, информирующий о том, что данный пакет требует подтверждения;
- MULTI:
1) флаг групповой посылки;
2) флаг, информирующий приемную сторону о том. что за данным пакетом будет отправлен другой;
- ITER — итератор пакета;
• DATA — поле данных пакета:
• MAXLEN — максимальная длина передачи поля данных.
Пакеты транспортного уровня разделяются:
• на пользовательские пакеты;
• системные пакеты.
Системные пакеты используют для передачи служебной информации, для реализации механизмов транспортного протокола, а также для передачи полезной информации (при передаче пакетов типа GROUP и SHORT).
Полезные данные, длина которых равна параметру MAXLEN. передаются внутри пользовательского пакета.
Полезные данные длиной более чем MAXLEN передаются путем дробления пакетов и объединения их в групповую посылку. При этом первый пакет в группе является системным (GROUP), а остальные — пользовательскими.
Полезные данные, длина которых меньше параметра MAXLEN. передаются внутри системного (SHORT) пакета.
Параметр MAXLEN равен 8 для UPLINK-пакетов и может иметь значения от 8 до 128 для DOWNLINK-пакегов. Параметр MAXLEN не должен изменяться в процессе обмена данными и должен иметь одинаковые значения как у передающего, так и у приемного узла.
Структура формата пользовательского пакета приведена в таблице 8. структура формата системного пакета — в таблице 9.
Таблица 8 — Структура формата пользовательского пакета
HEADER (Заголовок) | DATA (Данные) | |||
SYS (1 бит) | АСК (1 бит) | MULTI (Тбит) | ITER (5 бит) | PAYLOAD |
0 | 0/1 | 0/1 | От 0 до 31 | MAXLEN байт |
Таблица 9 — Структура формата системного пакета
HEADER (Заголовок) | DATA {Данные} | ||||
SYS | АСК | MULTI | ITER | TYPE | SYS.PAYLOAD |
1 | 0/1 | 0/1 | От Одо 31 | 1 байт | От 7 до (MAXLEN-1) байт |
Описание полей:
- SYS —флаг системного пакета;
- АСК — флаг, информирующий о том. что данный пакет требует подтверждения;
- MULTI:
1) флаг групповой посылки;
2) флаг, информирующий приемную сторону о том. что за данным пакетом будет отправлен другой;
- ITER — итератор пакета:
- DATA —поле данных пакета;
• TYPE —тип системного пакета;
- SYS_PAYLOAD — полезная информация:
- MAXLEN — максимальная длина передачи поля данных.
7.2.2 Типы системных пакетов
Основные типы системных пакетов, используемые в протоколе NB-Fi. приведены в таблице 10.
Таблица 10 — Основные типы системных пакетов
СООЕ (код) | TYPE (тип) | SYS.PAYLOAD LENGTH, bytes {Длина полезных данных, байт) | Описание |
ОЫххххххх | SHORT (CM. 7.2.2.1) | ОТ 7 до (MAXLEN-1) | Коротхий пакет данных |
0x00 | АСК Р (см. 7.2”2.2) | 7 | Подтверждение приема |
0x01 | HEARTBEAT (см. 7.2.2.3) | 7 | Информация о параметрах работы устройства |
0x02 | GROUP (см. 7.2.2.5) | 7 | Первый пакет в группе |
0x04 | CLEAR (см. 7.2.2.4) | 0 | Сигнал завершения сеанса передачи данных |
0x06 | CONF (см. 7.2.2.6J | 7 | Настройка параметров NB-Fi |
0x07 | RESET (см. 7.2.2.7) | 7 | Сброс устройства |
0x08 | CLEAR Т (см. 7.2.2.78) | 4 | Сигнал завершения сеанса передачи данных со значением Unix Tmestamp |
0x09 | SENDT1ME (см. 72.2.9) | 4 | Сигнал синхронизации системного времени |
ОхОА | GETNEWKEY (см. 7.2.2.10) | 0 | Запрос на выделение устройством нового ключа шифрования |
0x10—0x14 | KEYO—KEY4 (см. 7.2.2.11) | 7 | Значение ключа шифрования |
7.2.2.1 Пакет SHORT (короткий пакет данных)
Данный системный пакет предназначен для передачи пользовательских данных длиной менее чем MAXLEN.
Структура формата пакета SHORT приведена в таблице 11.
Таблица 11—Структура формата пакета SHORT
CODE (код) | TYPE (тип) | BYTE* (номер байта) | DATA (Данные) |
ОЫххххххх | SHORT | 0 | 0x80 * LENGTH |
— | — | 1 — (MAXLEN-1) | PAYLOAD |
Примечание — Допустимые значения LENGTH (дгыны полезных данных пакета): от 1 до 127 байт.
7.2.2.2 Пакет АСК_Р (подтверждение приема)
Данный системный пакет предназначен для подтверждения приема пакета данных. Структура формата пакета АСК_Р приведена в таблице 12.
Таблица 12 — Структура формата пакета АСК_Р
CODE (код) | TYPE (ran) | BYTE » (номер байта! | ОАТА (Данные) |
0x00 | АСК.Р | 0 | 0x00 |
— | — | 1—4 | MASK (см. 7.2.2.2. а)] |
— | — | 5 | SNR (см. 7.2.2.2. б)] |
— | — | 6 | NOISE OR RTC OFS 0 7 (см. 7.2.22. в)] |
— | — | 7 | MFLAGS (см. 7.2.2.2. г)] |
a) MASK Структура формата поля MASK приведена в таблице 13.
Таблица 13 — Структура формата поля MASK
MASK0 | MASK1 | MASK2 | MASK3 |
bit 0: статус пакета с итератором (i— 32) М 7: статус пакета с итератором (г—25) | bit 0: статус пакета с итератором (/—24) bit 7: статус пакета с итератором (/—17) | bit 0: статус пакета с итератором (/—16) bit 7: статус пакета с итератором (/ — 9) | bit 0: статус пакета с итератором (г — 8) bit 7: статус пакета с итератором (i — 1) |
Примечание — литератор АСК Р пакета равен итератору принятого пакета, в ответ на который отправлен АСК.Р.
Статус сообщения с текущим итератором / не включен в маску, так как факт получения пакета АСК_Р подтверждает успешность доставки пакета с текущим итератором.
б) SNR (Соотношение сигнал/шум пакета)
Соотношение сигнал/шум пакета, в ответ на который отправлен АСК_Р. используют для оценки качества связи при автоматическом выборе скорости и мощности передатчика. Допустимые значения — от 0 до 127 дБ.
в) NOISE_OR.RTC_OFS.0_7 (Уровень входного шума либо 8 младших бит поправки времени)
В данном поле передается уровень входного шума NOISE либо 8 младших бит поправки времени RTC.OFS.0_7. Первый вариант используется при передаче от устройства к серверу в качестве дополнительной информации; второй вариант — при передаче от сервера к устройству в случае применения механизма синхронизации времени. Допустимые значения — от 0 до 255. Данные значения соответствуют уровням шума от минус 150 до плюс 105 дБм либо 8 младшим битам 14-битной поправки времени.
г) MFLAGS
Структура формата поля MFLAGS при передаче АСК_Р от сервера к устройству приведена в таблице 14.
Таблица 14 — Структура формата поля MFLAGS при передаче АСК.Р от сервера к устройству
7 бит | б биг | От $ до Обит |
UL.SPEED NOT.MAX | DL.SPEED NOT.MAX | RTC.OFS.8 13 |
UL_SPEED_NOT_MAX уведомляет устройство о том. что текущая скорость передачи UPLINK-пакетов является немаксимальной для данной базовой станции. Активное значение — 1.
DL_SPEED_NOT_MAX уведомляет устройство о том. что текущая скорость приема DOWNLINK-пакетов является немаксимальной для данной базовой станции. Активное значение — 1.
RTC_OFS_8_13 — старшие 6 бит 14-битной поправки времени — используют при реализации механизма синхронизации системного времени конечного устройства.
Структура формата поля MFLAGS при передаче АСК_Р от устройства к серверу приведена в таблице 15.
Таблица 15 — Структура формата поля MFLAGS при передаче АСК.Р от устройства к серверу
Тбит | в бит | От 5 до 0 бит |
DL.POWER STEP.DOWN | DL.POWER STEP.UP | TX.PWR |
DL_POWER_STEP_DOWN уведомляет сервер о необходимости снизить мощность передатчика базовой станции для данного устройства. Активное значение — 1.
DL_POWER_STEP_UP уведомляет сервер о необходимости повысить мощность передатчика базовой станции для данного устройства. Активное значение — 1.
TX.PWR соответствует уровню текущей мощности передатчика устройства. Допустимые значения — от 0 до RF.MAX.POWER дБм.
7.2.2.3 Пакет HEARTBEAT (информация о параметрах работы устройства)
Данный системный пакет предназначен для передачи информации о параметрах работы устройства. Структура формата пакета HEARTBEAT приведена в таблице 16.
Таблица 16 — Структура формата пакета HEARTBEAT
СООЕ (мм) | TYPE (тип) | BYTE* (номер байта) | DATA (Данные) |
0x01 | HEARTBEAT | 0 | 0x01 |
— | — | 1 | 0x00 |
— | — | 2 | VSUP (см. 7.22.3, а)] |
— | — | 3 | TEMP [см. 7.2.2.3. 6)J |
— | — | 4 | AVER RX SNR (см. 7.2.2.3. в)] |
— | — | 5 | AVER ТХ SNR [см. 7.22.3, г)] |
— | — | 6 | NOISE [см. 7.22.3, fl)J |
— | — | 7 | ТХ PWR (см. 7.22.3. e)J |
а) VSUP (Напряжение питания устройства) Должно быть представлено в следующем формате: Старший бит: 1. если U* ЗВ.
Младшие 7 бит: десятые доли вольта.
Формула для перевода данного поля в вольты следующая:
V = 2 ♦ (D»7) + (D&Ox7F)/100.
б) TEMP (Температура внутри устройства) Тип данных: int8_t.
Допустимые значения: от минус 128 ’С до плюс 128 ’С.
в) AVER_RX_SNR (Среднее значение соотношения сигнал/шум на входе приемника устройства) Среднее значение соотношения сигнал/шум на входе приемника устройства определяют по не-
скольким последним принятым пакетам. Допустимые значения: от 0 до 127 дБ.
г) AVER_TX_SNR (Среднее значение соотношения сигнал/шум на входе приемника базовой станции) Среднее значение соотношения сигнал/шум на входе приемника базовой станции определяют по
нескольким последним принятым пакетам и вычисляют на основании данных, получаемых в поле SNR АСК_Р пакета. Допустимые значения: отО до 127 дБ.
д) NOISE (Уровень шума на входе приемника устройства)
Допустимые значения: от 0 до 255. Данные значения соответствуют уровням шума от минус 150 до плюс 105 дБм.
е) TX_PWR (Уровень текущей мощности передатчика устройства)
Допустимые значения: от минус 10 до RF_MAX_POWER дБм.
7.2.2.4 Пакет CLEAR (сигнал завершения сеанса передачи данных)
Данный системный пакет предназначен для информирования о завершении сеанса передачи данных. Структура формата пакета CLEAR приведена в таблице 17.
Таблица 17 — Структура формата пакета CLEAR
CODE (код) | TYPE (тип) | BYTE в (иомер байта) | ОАТА (Данные) |
0x04 | CLEAR | 0 | 0x04 |
— | — | 1—7 | Зарезервированы |
7.2.2.5 Пакет GROUP (первый пакет в группе)
Данный системный пакет предназначен для определения заголовка (первого пакета) групповой посылки.
Структура формата пакета GROUP приведена в таблице 18.
Таблица 18 — Структура формата пакета GROUP
CODE (код) | TYPE (тип) | BYTE а (номер банта) | DATA(Данные) |
0x02 | GROUP | 0 | 0x02 |
— | — | 1 | GROUPJ.EN [см. 7.Z2.5. а)] |
— | — | 2 | GROUP CRC [см. 7.2.2.5. а)] |
3—7 | PAYLOAD.0.4 [ см. 7.22.5. б)] |
а) GROUPJ.EN
Суммарное количество байт полезных данных во всей групповой посылке.
б) GROUP_CRC
Контрольная сумма CRC8 данных группы.
В) PAYLOAD_0_4
Первые 5 байт полезных данных групповой посылки.
7.2.2.6 Пакет CONF (настройка параметров NB>Fi)
Данный системный пакет предназначен для выполнения настройки параметров NB-Fi. Структура формата пакета CONF приведена в таблице 19.
Таблица 19 — Структура формата пакета CONF
CODE (код) | TYPE (тип) | BYTE в (номер байта) | DATA (Поле данных) |
0x06 | CONF | 0 | 0x06 |
— | — | 1 | CMD&PARAM [см. 7.2.2.6. а)] |
— | — | 2—7 | CONF.DATA |
Поле CONF.DATA определено а 7.2.2.6, перечисления г)—х).
a) CMD&PARAM
Структура формата поля CMD&PARAM приведена в таблице 20.
Таблица 20 — Структура формата поля CMD&PARAM
От 7 во 6 бит | От 5 до 0 бит |
CMD | PARAM |
(см.7.2.2.6. б) | (см. 7.2.2.6, в)] |
б) CMD Структура формата поля CMD приведена в таблице 21.
Таблица 21—Структура формата поля CMD
СООЕ (код) | TYPE (тип) | Описание |
0x00 | READ.CMD | Команда чтения параметра(ов) |
0x01 | WRJTE.CMD | Команда записи лараметра(ов) |
0x02 | WRiTE.CMD.ACK | Команда записи параметра(ов) с верификацией и сохранением в энергонезависимой памяти |
0x03 | WRITE.CMD.SAVE | Команда записи параметра(ов) с сохранением в энергонезависимой памяти |
в) PARAM Структура формата поля PARAM приведена в таблице 22.
Таблица 22 — Структура формата поля PARAM
СООЕ (код) | TYPE (тип) | ReadAVrite (чтение^ запись) | Наименование параметра (ое) |
0x00 | NBFI.PARAM.MODE | RAY | Параметры режима работы NB-Fi |
0x01 | NBFI.PARAM. HANDSHAKE | RAY | Параметры режима квитирования NB-Ft |
0x02 | NBFI.PARAM. MAXLEN | RAY | Параметр MAXLEN |
0x03 | NBFI.PARAM.TXFREQ | RAY | Параметр TXFREQ (частота передачи) |
0x04 | NBFI.PARAM.RXFREQ | RAY | Параметр RXFREQ (частота приема) |
0x05 | NBFI.PARAM.ANT | RAY | Параметры RF-фронтенда (выбор антенн и мощности передачи) |
0x06 | NBFI.PARAM_DL.ADD | RAY | Параметр DL.ADD (адресация DOWNLINK-пакетов) |
0x07 | NBFI.PARAM_HEART.BEAT | RAY | Параметры отправки HEARTBEAT-пакетов |
0x08 | NBFI.PARAM.TX.BRATES | R | Чтение поддерживаемых скоростей передачи |
0x09 | NBFI.PARAM.RX.BRATES | R | Чтение поддерживаемых скоростей приема |
ОхОА | NBFI.PARAM.VERSION | R | Чтение версии исполнения устройства |
ОхОВ | NBFI.ADD.FLAGS | RAY | Параметр ADDITIONAL-FLAGS |
ОхОС | NBFI.QUALITY | R | Чтение параметра QUALITY |
Окончание таблицы 22
CODE (над) | TYPE (тип) | Read/Wnte (чтение/ запись) | Наименование параметра(оа) |
OxOD | NBFI_UL.BASE.FREQ | RM | Параметр UL.BASE.FREQ (базовая частота першами) |
ОхОЕ | NBF1.DL_BASE.FREQ | RM | Параметр DL.BASE.FREQ (базовая частота приема) |
0x0 F | NBFI.QUALITY.EX | R | Чтение параметра QUALITY.EXT |
0x11 | NBFI.APPLY.KEY | W | Команда применения нового ключа |
Описание поля CONF.DATA для каждого параметра таблицы 22 приведено в 7.2.2.6. перечисления г)—х).
г) Значение поля CONF_DATA для параметра N8FI_PARAM_MODE (PARAM = 0x00)
Таблица 23 — Структура формата поля CONF.DATA для параметра NBF1.PARAM.MODE
BYTE в (номер байта) | CONF.OATA |
0 | NBFI.MODE |
1 | NBFI.MACK.MODE |
2 | NBFI.TX.PHY.CHANNEL |
3 | NBFI.RX.PHY.CHANNEL |
4 | NBFJ.TX.PWR |
5 | NBF1.NUM.OF.RETRIES |
NBFI_MODE — режим работы транспортного уровня протокола NB-Fi. Описание поля NBFI.MODE приведено в таблице 24.
Таблица 24 — Описание поля NBFi.MODE
CODE (код) | TYPE (тип) |
0 | NRX |
1 | DRX |
2 | CRX |
3 | TRANSPARENT |
4 | OFF |
NBFI_MACK_MODE — параметр группового квитирования (multiple ack) данных при отправке. Может иметь значения от 0 до 32.
NBFI_TX_PHY_CHANNEL — параметр, определяющий тип и скорость пакетов при отправке UPLINK-пакетов. Описание поля NBFI.TX.PHY.CHANNEL приведено в таблице 25.
Таблица 25 — Описание поля NBFI.TX.PHY.CHANNEL
CODE (код) | TYPE (тип) | Описание |
21 | UL DBPSK 50 PROT E | UPLINK-пакет на скорости 50 бит/с |
22 | UL.PSK.200 | DOWNLlNK-пакет на скорости 200 биг/с |
Окончание таблицы 25
CODE (код) | TYPE (тип) | Описание |
24 | UL DBPSK 400 PROT E | UPLINK-пакбт на скорости 400 бит/с |
25 | UL.PSK.500 | DOWNLINK-пакет на скорости 500 бит/с |
26 | UL.DBPSK 3200.PROT—Е | UPLINK-паквт на скорости 3200 бит/с |
27 | UL.PSK.5000 | DOWNLINK-пакет на скорости 5000 бит/с |
28 | UL D8PSK 25600 PROT E | UPLINK-пакбт на скорости 25 600 бит/с |
29 | UL.PSK.FASTDL | DOWNLINK-пакет на скорости 57 600 бит/с |
50 | UL.CARRIER | Формирование несущей частоты без модуляции |
Примечания
1 DOWNLINK-лакеты применяют для отправки при взаимодействии «реегЧо-реег».
2 UL.CARRIER используют для диагностических целей.
NBFI_RX_PHY_CHANNEL — параметр, определяющий тип и скорость пакетов при приеме DOWNLINK-пакетое. Описание поля NBFI.RX.PHY.CHANNEL приведено в таблице 26.
Таблица 26 — Описание поля NBFI.RX.PHY.CHANNEL
CODE (кед) | TYPE (тип) | Описание |
0 | DL.PSK.200 | DOWNLINK-пакет на скорости 200 бит/с |
1 | DL.PSK.500 | DOWNLINK-пакет на скорости 500 бит/с |
2 | DL.PSK.5000 | DOWNLINK-пакет на скорости 5000 бит/с |
3 | DL.PSK.FASTDL | DOWNLINK-пакет на скорости 57 600 бит/с |
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 приведено в таблице 27.
Таблица 27 — Структураформата поля CONF.DATAдля параметра NBFI.PARAM.HANDSHAKE
BYTE « | CONF DATA |
(номер байга) | |
0 | NBFI.HANDSHAKE.MODE |
1 | NBFI.MACK.MODE |
2—5 | Зарезервированы |
NBFI.HANDSHAKE.MODE — режим квитирования данных. Описание поля NBFI.HANDSHAKE MODE приведено в таблице 28.
Таблица 28 — Описание поля NBFI.HANDSHAKE.MODE
CODE (кед) | TYPE (тип) |
0 | HANDSHAKE.NONE |
1 | HANDSHAKE.SIMPLE |
NBFI_MACK_MODE — параметр группового квитирования (multiple ack) данных при отправке. До-пустимые значения: от 0 до 32.
е) Значение поля CONF_DATA для параметра NBFI_PARAM_MAXLEN (PARAM « 0x02)
Описание структуры формата поля CONF_DATAann параметра NBFI_PARAM_MAXLEN приведено в таблице 29.
Таблица 29 — Структура формата поля CONF_DATAдля параметра NBFI PARAM MAXLEN
BYTE в (номер байта} | CONF-DATA |
0 | MAXLEN |
1—5 | Зарезервированы |
MAXLEN — параметр, определяющий размер полезных данных одного пакета, передаваемого на МАС-уровне. Для UPLINK-пакетов данный параметр соответствует значению 8.
ж) Значение поля CONF_DATA/jnfl параметра NBFI_PARAM_TXFREQ (PARAM = 0x03) Описание структуры формата поля CONF_DATA для параметра NBFI_PARAM_TXFREQ приведено в таблице 30.
Таблица 30 — Структура формата поля CONF_DATAдля параметра NBFI PARAM TXFREQ
BYTE в | CONF ОЛТА |
(номер байта} | |
0—3 | TXFREQ |
4—5 | Зарезервированы |
TXFREQ — параметр, определяющий частоту отправки данных. При TXFREQ = 0 частоту отправки данных вычисляют по формуле
+((/О + С/?С8)%226)100.
где fbaS9 ui — базовая частота отправки UPLINK-пакета (UL_BASE_FREQ);
’/£> — идентификационный номер модема;
CRC8 — одно из полей UPLINK-пакета. равное контрольной сумме поля PAYLOAD.
При TXFREO = 0 чтение данного параметра возвращает значение 0 и не позволяет определить текущую частоту отправки.
При TXFREQ 4 0 частота отправки равна значению TXFREQ.
Порядок следования байт в данном поле данных — старшим байтом вперед.
и) Значение поля CONF_DATA для параметра NBFI_PARAM_RXFREQ (PARAM = 0x04)
Описание структуры формата поля CONF_DATA/uw параметра NBFI_PARAM_RXFREQ приведено в таблице 31.
Таблица 31 — Структура формата поля CONF_DATAдля параметра NBFI PARAM RXFREQ
BYTE в (номер байта} | CONF-OATA |
0—3 | RXFREQ |
4—5 | Зарезервированы |
RXFREQ — параметр, определяющий частоту, на которой выполняется прием данных. При RXFREQ = 0 частоту / вычисляют по формуле
f=^se^/+(/O%276|363.
где fbasa — базовая частота приема DL(DL_BASE_FREQ):
/О — идентификационный номер модема.
При RXFREQ - 0 чтение данного параметра возвращает значение 0 и не позволяет определить текущую частоту приема.
При RXFREQ А 0 частота приема равна значению RXFREQ.
Порядок следования байтов в данном поле данных — старшим байтом вперед.
к) Значение поля CONF_DATA/yifl параметра NBFI.PARAM.ANT (PARAM = 0x05)
Описание структуры формата поля CONF.DATA для параметра NBFI_PARAM_ ANT приведено в таблице 32.
Таблица 32 — Структура формата поля CONF-ОАТАдля параметра NBFI.PARAMANT
BYTE# (номер байта) | CONF.DATA |
0 | NBFI.TX.PWR |
1 | NBFI.TX.ANT |
2 | NBFI.RX.ANT |
3—5 | Зарезервированы |
NBFI.TX.PWR — уровень выходной мощности передатчика. Тип параметра: int8_t Допустимые значения: от минус 10 до RF.MAX.POWER дБм.
NBFI_TX_ANT — параметр, определяющий, какой из RF-трактое используется при передаче. Значения параметра и соответствующие им варианты RF-трактое зависят от конкретной реализации устройства.
NBFI_RX_ANT — параметр, определяющий, какой из RF-трактов используется при приеме. Значения параметра и соответствующие им варианты RF-трактое зависят от конкретной реализации устройства.
л) Значение поля CONF.DATA для параметра NBFI_PARAM_DL_ADD (PARAM = 0x06)
Описание структуры формата поля CONF.DATAflnfl параметра NBFI.PARAM. DL_ADD приведено в таблице 33.
Таблица 33 — Структура формата поля CONF.DATA для параметра NBFI.PARAM_DL.ADD
BYTE » (номер байта) | CONF.DATA |
0—2 | NBFI.DL.ADD |
3—5 | Зарезервированы |
NBFI.DL.ADD — параметр, использующийся для адресации при отправке и приеме DOWNLINK-пакетов. По умолчанию равен ID-адресу устройства. Может быть изменен на адрес другого устройства для приема пакетов только от заданного узла.
м) Значение поля CONF.DATA для параметра NBFI_PARAM_HEART_BEAT (PARAM - 0x07) Описание структуры формата поля CONF.DATA для параметра NBFI_PARAM_ HEART.BEAT приведено в таблице 34.
Таблица 34 — Структура формата поля СОНР_ОАТАдля параметра NBF! PARAM HEART BEAT
BYTE • | CONF ОАТА |
{номер байта) | |
0 | NBF1 HEARTBEAT NUM |
1—2 | NBFI.HEARTBEAT.INTERVAL |
3—5 | Зарезервированы |
NBFI_HEARTBEAT_NUM — параметр, определяющий количество HEARTBEAT-пакетов. которые будут отправлены после сброса устройства. При NBFI_HEART8EAT_NUM = 255 отправка HEARTBEAT* пакетов выполняется неограниченное количество раз.
NBFIJHEARTBEATJNTERVAL — параметр, определяющий периодичность отправки HEARTBEAT-пакетов. Допустимые значения: от 0 до 65 535. Порядок следования байтов в поле параметра: старшим байтом вперед. Порядок расчета периодичности отправки HEARTBEAT-пакетов при разных режимах работы транспортного уровня протокола NB-Fi (NBFI_MODE) приведен в таблице 35.
Таблица 35 — Порядок расчета периодичности отправки HEARTBEAT-пакетов при разных режимах работы транспортного уровня протокола NB-Fi
NBFI.MODE | Периодичность отправки HEARTBEAT-пакетов. с |
NRX. DRX | NBFI HEARTBEAT INTERVAL * 60 |
CRX | NBF1 HEARTBEAT INTERVAL |
н) Значение поля CONF_DATA для параметра NBFI_PARAM_TX_BRATES (PARAM = 0x08) Описание структуры формата поля CONF_DATA для параметра NBFI_PARAM_ TX_BRATES приведено в таблице 36.
Таблица 36 — Структура формата поля СОИР_ОАТАдля параметра NBF1_PARAM_TX_BRATES
BYTE в {номер байта) | CONF_DATA |
0—5 | NBFI TX BRATES |
NBFI_TX_BRATES — в данном поле перечислены все поддерживаемые устройством скорости передачи данных, которые используются при автоматическом выборе оптимальной скорости. Данные представлены в формате значений параметра NBFI_TX_PHY_CHANNEL (см. 7.2.2.В. г)]. Максимально возможное количество поддерживаемых скоростей равно шести. Поддерживаемые скорости перечислены начиная с младшего байта данного поля. Если число скоростей менее шести, старшие (неиспользуемые) байты данного поля равны OxFF.
Примечание — Параметр N8FI_PARAM_TX_BRATES доступен только для чтения.
л) Значение поля CONF_DATA для параметра NBFI_PARAM_RX_BRATES (PARAM - 0x09) Описание структуры формата поля CONF_DATA для параметра NBFI_PARAM_ RX-BRATES приведено в таблице 37.
Таблица 37 — Структура формата поля CONF_DATAahhпараметра NBF1_PARAM_RX_BRATES
BYTE • {номер байта) | CONF_OATA |
0—5 | NBFI.RX.BRATES |
NBFI.RX.BRATES — в данном поле перечислены все поддерживаемые устройством скорости приема данных, которые используются при автоматическом выборе оптимальной скорости. Данные представлены в формате значений параметра NBFI_RX_PHY_CHANNEL [см. 7.2.2.6. г)). Максимально возможное количество поддерживаемых скоростей равно шести. Поддерживаемые скорости перечислены начиная с младшего байта данного поля. Если число скоростей менее шести, старшие (неиспользуемые) байты данного поля равны OxFF.
Примечание — Параметр NBFi_PARAM_RX_BRATES доступен только для чтения.
р) Значение поля CONF_DATA для параметра NBFI.PARAM.VERSION (PARAM - ОхОА) Описание структуры формата поля CONF_DATA для параметра NBFI.PARAM. VERSION приведено в таблице 38.
Таблица 38 — Структура формата поля CONF.DATAAnn параметра
NBFI PARAM VERSION
BYTE# (номер байга) | CONF.DATA |
0 | NBFI.REV |
1 | NBFI.SUBREV |
2 | COMP.CRC |
3 | HARDWARE.© |
4 | HARDWARE.REV |
5 | BAND.© |
NBFI_REV — версия транспортного протокола NB-Fi. Текущее значение равно 2.
NBFI.SUBREV — дополнительная версия транспортного протокола NB-Fi — в данный момент не используется.
COMP.CRC — контрольная сумма С/?С8 даты и времени компиляции программного обеспечения устройства — используется для автоматического контроля модификаций программного обеспечения.
HARDWAREJD — идентификатор аппаратной платформы устройства.
HARDWARE_REV — версия аппаратной платформы устройства.
8ANDJD — идентификатор радиочастотного решения устройства — описывает рабочие частоты приемного и передающего трактов.
Примечание — Параметр NBFI.PARAM.VERSION доступен только для чтения.
с) Значение поля CONFED АТА для параметра NBFI_ADD_FLAGS (PARAM = 0x0В)
Описание структуры формата поля СО№_ОАТАдля параметра NBFI_ ADD_FLAGS приведено в таблице 39.
Таблица 39 — Структура формата поля CONF.DATAatta параметра
NBFI ADD FLAGS
BYTE « | CONF DATA |
(номер байта) | |
0 | NBFl.ADDmONAL.FLAGS |
1—5 | Зарезервированы |
NBFI.ADDITIONAL.FLAGS — параметр, представляющий собой совокупность дополнительных флагов, управляющих определенными функциями протокола, сгруппированных в виде битовой маски. Активное значение каждого флага — 1.
Описание поля NBFI_ADDITIONAL_FLAGS приведено в таблице 40.
Таблица 40 — Описание поля NBFI_ADDIT1ONAL_FLAGS
BIT It (номер бита) | FLAG (дополнительные флаги} |
O(LSB) | FLG FIXED BAUD RATE |
1 | FLG NO RESET TO DEFAULTS |
2 | FLG NO SENDINFO |
3 | FLG.NO.ENC |
4 | FLG DO OSCCAL |
5 | FLG.LBT |
6 | NBF1 OFF MODE ON INIT |
7(MSB) | NBFI FLG DO NOT SEND PKTS ON START |
FLG_FIXED_BAUD_RATE — данный флаг деактивирует механизм автоматического выбора оптимальной скорости и мощности передачи.
FLG_NO_RESET_TO_DEFAULTS — данный флаг деактивирует функцию сброса режима скоростей к значениям по умогманию после неудачного выполнения сеанса передачи данных и используется совместно с FLG_FIXED_BAUD_RATE — флагом при соединениях «peer-to-peer».
FLG_NO_SEND_INFO — данный флаг отключает автоматическую отправку информационных пакетов.
FLG_NO_ENC — данный флаг отключает шифрование данных как для передачи, так и для приема пакетов. Значение данного флага влияет только на поведение устройства и не отключает функции шифрования на сервере. Используется при соединениях «реег-(о-реег».
FLG_DO_OSCCAL — данный флаг активирует механизм периодической калибровки внутреннего RC-генератора. В качестве опорного генератора применяется радиоосциллятор и используется для некоторых решений на радиотрансивере AX8052F143.
FLGJ.BT — данный флаг активирует режим передачи LBT (listen before talk).
NBFI_OFF_MODE_ON_INIT — данный флаг сигнализирует устройству переходить в режим работы OFF при инициализации устройства.
NBFI_FLG_DO_NOT_SEND_PKTS_ON_START — данный флаг отключает отправку системных пакетов CLEAR и CONF при инициализации устройства.
т) Значение поля CONF_DATA для параметра NBFI_QUALITY (PARAM = ОхОС)
Описание структуры формата поля CONF_DATA для параметра NBFI.OUALITY приведено в таблице 41.
Таблица 41 — Структура формата поля CONF_DATA для параметра NBA QUALITY
BYTE в (номер байта} | CONF.OATA |
0—1 | UL.TOTAL |
2—3 | DL.TOTAL |
4 | AVER RX SNR |
5 | AVER.TX.SNR |
UL_TOTAL—общее количество отправленных пакетов с момента сброса устройства. Тип данного параметра: uint16_t Порядок следования байтов в данном поле — старшим байтом вперед.
DL_TOTAL — общее количество принятых пакетов с момента сброса устройства. Тип данного параметра: uint16_t Порядок следования байтов в данном поле — старшим байтом вперед.
AVER_RX_SNR — среднее значение соотношения сигнал/шум на входе приемника устройства, определяемое по нескольким последним принятым пакетам. Допустимые значения: от 0 до 127 дБ.
AVER_TX_SNR — среднее значение соотношения сигнал/шум на входе приемника базовой стан* ции, определяемое по нескольким последним принятым пакетам, вычисляется на основании данных, получаемых в поле SNR АСК_Р пакета. Допустимые значения: от 0 до 127 дБ.
Примечания
1 Параметр NBF1_QUALITY доступен только для чтения.
2 Параметры DL TOTAL. AVER RX SNR. AVER_TX_SNR актуальны только для режимов работы DRX и CRX с NBFI.HANDSHAKE.MODE = HANDSHAKE.SIMPLE.
у) Значение поля CONFED АТА для параметра NBFI_UL_BASE_FREQ (PARAM = OxOD)
Описание структуры формата поля CONF.DATA для параметра NBFI_UL_BASE_FREQ приведено в таблице 42.
Таблица 42 — Структура формата поля CONF DATA для параметра NBFI.UL.BASE.FREQ
BYTE# | CONF DATA |
(номер байта) | |
0—3 | UL BASE FREQ |
4—5 | Зарезервированы |
UL_BASE_FREQ — параметр соответствует базовой частоте, используемой при расчете частоты, на которой отправляются данные.
ф) Значение поля CONF_DATA для параметра NBFI_DL_BASE_FREQ (PARAM - ОхОЕ)
Описание структуры формата поля CONF_DATA для параметра NBFI_ DL_BASE_FREQ приведено в таблице 43.
Таблица 43 — Структура формата поля СОЫР_ОАТАдля параметра NBFI_DL_BASE_FREQ
BYTE « | CONF DATA |
(номер байта) | |
0—3 | DL BASE FREQ |
4—5 | Зарезервированы |
DL_BASE_FREQ — параметр соответствует базовой частоте, используемой при расчете частоты, на которой принимаются данные.
х) Значение поля CONF_DATAjyifl параметра NBFI_QUALrTY_EX (PARAM = OxOF)
Описание структуры формата поля CONF_DATA для параметра NBFI_ QUALITY_EX приведено в таблице 44.
Таблица 44 — Структура формата поля CONF_DATAflnn параметра NBFI.QUAUTY.EX
BYTE » (номер байта) | CONF.DATA |
0 | UL RATlNG |
1 | DL.RATING |
2—3 | UL.SUCCESS.TOTAL |
4—5 | (JL FAULT TOTAL |
UL_RATING — показатель уровня сигнала на входе приемника, вычисляется на основании текущего режима скорости и среднего значения соотношения сигнал/шум на входе приемника. Допустимые значения: от 0 до 10.
DL_RATING — показатель уровня сигнала от данного устройства на входе приемника базовой станции, вычисляется на основании текущего режима скорости и среднего значения соотношения сигнал/шум на входе базовой станции. Допустимые значения: от 0 до 10.
UL.SUCCESS.TOTAL — общее количество успешно доставленных пакетов с момента сброса устройства. Тип данного параметра: uint16_t. Порядок следования байтов в данном поле — старшим байтом вперед. Для режима работы NRX либо в случае NBFI.HANDSHAKE.MODE - HANDSHAKE_ NONE данный параметр равен общему количеству отправленных пакетов.
UL_FAULT_TOTAL — общее количество недоставленных пакетов с момента сброса устройства. Тип данного параметра: uintl6_t. Порядок следования байтов в данном поле: старшим байтом вперед. Пакет считается недоставленным, если его не удалось доставить в результате сеанса передачи данных.
Примечания
1 Параметр NBFI.QUALITY.EX доступен только для чтения.
2 Параметры UL.RATING. DL.RATING. UL.FAULT TOTAL актуальны только для режимов работы DRX и CRX с NSFI.HANDSHAKE.MODE = HANDSHAKE.SIMPLE.
ц) Значение поля CONFED АТА для параметра NBFI_APPLY_KEY (PARAM = 0x11)
Описание структуры формата поля CONF.DATA/jnn параметра NBFI. APPLY.KEY приведено в таблице 45.
Таблица 45 — Структура формата поля CONF.OATAahh параметра
NBFI APPLY KEY
BYTE в (номер байта} | CONF.DATA |
0—3 | KEY.CRC32 |
4—5 | Зарезервированы |
KEY.CRC32 — контрольная сумма ключа шифрования. Программный код реализации функции вычисления данного параметра (CRC32) на языке Си приведен в разделе Б.4 приложения Б.
7.2.27 Пакет RESET (сброс устройства)
Данный системный пакет предназначен для выполнения процедуры программного перезапуска устройства.
Структура формата пакета RESET приведена в таблице 46.
Таблица 46 — Структура формата пакета RESET
CODE (сод) | TYPE (тип} | BYTE # (номер байта) | ОАТА (Данные) |
0x07 | RESET | 0 | 0x07 |
— | — | 1 | OxDE |
— | — | 2 | OxAD |
— | — | 3—7 | Зарезервированы |
7.22.8 Пакет CLEAR.T. Сигнал завершения сеанса передами данных со значением Unix Timestamp Структура формата пакета CLEAR.T приведена в таблице 47.
Таблица 47 — Структура формата пакета CLEAR.T
CODE (кол) | TYPE (тмл) | BYTE# (номер байта) | ОАТА (Данные) |
0x08 | CLEAR.T | 0 | 0x08 |
— | — | 1—4 | LTTS |
— | — | 5—7 | Зарезервированы |
UTS — 4-байтное значение системного времени в формате Unix Timestamp (количество секунд от 1 января 1970 года), соответствующее часовому поясу UTC.
7.2.2.9 Пакет SENDTIME. Сигнал синхронизации системного времени Структура формата пакета SENDTIME приведена в таблице 48.
Таблица 48 — Структура формата пакета SENDTIME
CODE («од) | TYPE (тип) | BYTE* (номер байта) | DATA (Данные) |
0x09 | SENDTIME | 0 | 0x09 |
— | — | 1—4 | UTS |
— | — | 5—7 | Зарезервированы |
UTS — 4-байтное значение системного времени в формате Unix Timestamp (количество секунд от 1 января 1970 г.), соответствующее часовому поясу UTC.
7.2.2.10 Пакет GETNEWKEY. Запрос на выделение устройством нового ключа шифрования Структура формата пакета GETNEWKEY приведена в таблице 49.
Таблица 49 — Структура формата пакета GETNEWKEY
CODE (код) | TYPE (тип) | BYTE в (номер байта) | DATA (Данные) |
0х0А | GETNEWKEY | 0 | ОхОА |
— | — | 1—7 | Зарезервированы |
7.2.2.11 Пакет KEYn. Значение ключа шифрования Структура формата пакета KEYn приведена в таблице 50.
Таблица 50 — Структура формата пакета KEYn
CODE (код) | TYPE (тип) | BYTE а (номер байта) | DATA (Данные) |
0х1п | KEYn | 0 | 0х1п |
— | — | 1—7 (3. для л = 4) | 7 байт ключа шифрова-шя(4 байта, для п - 4) |
— | — | 4—7 | Зарезервировано для л = 4 |
Примечание — Параметр л принимает значения от 0 до 4.
8 Уровень представления (Presentation layer)
8.1 Общие положения
На данном уровне реализованы механизмы, обеспечивающие совместимость устройств на уровне приложения, а также обеспечивающие защиту данных уровня приложений, идентификацию устройств и чтение/запись типов данных специального назначения.
Пакет данных уровня представления передается в обоих направлениях внутри поля Payload транспортного уровня.
Описанные ниже форматы пакетов представляют собой соглашения, выполнение которых обязательно требуется в системах, к которым предъявляются требования в части безопасности передачи данных. В этих системах должен быть использован алгоритм шифрования «Магма».
При наличии достаточных оснований на использование другого алгоритма шифрования или в зависимости от требований безопасности в стране применения стандарта возможен выбор другого алгоритма симметричного блочного шифрования с размером ключа шифрования 256 бит.
8.2 Описание пакетов данных уровня представления
8.2.1 Формат пакета уровня представления
Структура формата пакета уровня представления в общем виде приведена в таблице 51.
Таблица 51 —Структура формата пакета уровня представления
в общем виде
Поле | Размер |
ОхЕО | 1 байт |
CMD | 1 байт |
ITER | 2 байта |
ENC | 2 бита |
TYPE | 6 бит |
CRC16 | 2 байта |
DATA | 1—233 байта |
Описание полей:
• ОхЕО: признак пакета уровня представления;
- CMD: код команды, который определяет назначение пакета: типы команд приведены в таблице 52:
• ITER: итератор пакета — 16-битный параметр, который должен увеличиваться на 1 для каждого нового пакета, позволяет идентифицировать уникальность пакета и реализовать защиту от атаки повторного воспроизведения;
- ENC: тип используемого шифрования; типы шифрования приведены в таблице 53;
- TYPE: тип данных пакета, который определяет тип содержимого поля DATA: типы данных приведены в таблице 54; программный код реализации функции вычисления данного параметра на языке Си приведен в разделе Б.З приложения Б;
- DATA: поле полезных данных пакета, которое может быть зашифровано одним из видов блочного шифрования, приведенных в таблице 53.
8.2.2 Типы команд уровня представления
Таблица 52 — Типы команд уровня представления
CODE (код) | СМ0 (команда) | Наименование команды |
0x00 | NBFI.PL_GET_MAN.ID | Получение идентификатора производителя |
0x01 | NBFI_PL.GET_HW.ID | Получение идентификатора устройства |
0x02 | NBFI_PL_GET.PROT.ID | Получение идентификатора протокола устройства |
0x03—0x1 F | Зарезервировано | |
0x20 | NBFI_PL_ENC_SET_NONE | Запрос на выключение шифрования |
0x21 | NBFI.PL.ENC.SET.MAGMA | Запрос на включение алгоритма шифрования «Магма» |
0x22 | NBFI.PL.ENC.TYPE.CUSTOMCRYPTO1 | Запрос на включение пользовательского шифрования № 1 |
0x23 | NBFI_PL_ENC_TYPE_CUSTOMCRYPTO2 | Запрос на включение пользовательского шифрования N9 2 |
0x24 | NBFI.PL_ENC_NEW.KEY | Запрос иа смену ключа шифрования |
Окончание таблицы 52
CODE (ход) | CMD (команда} | Наименование команды |
0x25 | NBFI.PL_ENC_APPLY.KEY | Команда подтверждения смены ключа шифрования |
0x26—ОхЗР | Зарезервировано | |
0x40—Ox FF | Свободно для использования приложением |
8.2.3 Типы шифрования уровня представления
Таблица 53 — Т«1ы шифрования уровня представления
CODE (код) | ENC | Тип шифрования |
ОЬОО | NBFI PL ENC.TYPE.NONE | Шифрование отсутствует |
0601 | NBFI.PL.ENC.TYPE.MAGMA | «Магма» |
ОЫО | NBFI.PL.ENC.TYPE.CUSTOMCRYPTO! | Другой тип шифрования (пользовательский тип шифрования N? 1) |
0Ы1 | NBFI_PL_ENC_TYPE_CUSTOMCRYPTO2 | Другой тип шифрования (пользовательский тип шифрования № 2) |
8.2.4 Типы данных уровня представления
Таблица 54 — Тилы данных уровня представления
СООЕ (код) | ТУРЕ |т«п) | Наименование типа |
0x00 — ОхЗР | Свободно для использования приложением |
Приложение А (справочное)
Описание алгоритма компенсации нестабильности частот задающего генератора
Суть алгоритма компенсации частот заключается в следующем:
Отправка UPLINK-пахетов устройствами осуществляется на известной (предполагаемой) частоте вычисляемой по формуле
*((Ю+СДС8|%226)1ОО.
(А.1)
где АЫ10 —граничная частота диапазона частот, на которых выпогыяется отправка UPLINK-пакетое; ID — идентификационный номер модема:
CRC8 — одно из полей UPLINK-пакета. равное контрольной сумме поля PAYLOAD.
Отправка DOWNLINK-пакетое базовой станцией осуществляется на известной (предполагаемой) ог* вычисляемой по формуле
частоте
-^.<„*(^276)363.
(А.2)
где !baib ф — граничная частота диапазона частот, на которых выполняется отправка DOWNLINK-пакетое; ID —идентификационный номер модема.
Базовая станция, принимая пакет, вычисляет частоту приема ffxi с разрешением в несколько десятков герц (для скорости 50 бит/с) и затем выполняет вычисление обобщенной ошибки частоты «V, по формуле
(А.З)
В состав данной ошибки входят как погрешность передатчика удаленного модема AAmotfrx. так и ошибка измерения частоты базовой станцией ДАЬ1ЯХ. таким образом
'Ц = *Ч»«7Х * ■
(А.4)
Данные погрешности имеют достаточно стабильные значения, вызванные начальной неточностью генераторов, и при использовании термокомпенсированных осцилляторов незначительно изменяются при колебаниях температуры.
Передатчик базовой станции, используемый для отправки DOWNLlNK-лакетов. также с определенной периодичностью (например, каждые 5 мин) отправляет UPLINK-пакеты на фиксированной частоте ftau 01. которая попадает в полосу частот приема базовой станции. Базовая станция, принимая данный пакет, вычисляет частоту приема t/t2 и затем значение обобщенной ошибки частоты ДАг по формуле
= аг _6>2- (А.5)
В состав данной ошибки входят как погрешность передатчика базовой станции &fbiTx. так и ошибка измерения частоты базовой станцией ДА68ЯХ. таким образом
(А.6)
При отправке DOWNLlNK-пакетов каждый раз вносится поправка 8 частоту передачи базовой станции прибавлением обобщенной ошибки ДА, и вычитанием обобщенной ошибки ДА2 по формуле
(А.7)
Подставляя в формулу (А.7) выражения (А.4) и (А.6). а тахже добавляя ошибку передатчика базовой станции ДАО4ГХ, вычисляют фактическое значение частоты отправки АМе|ГХ по формуле
*МС1ЛГ ~^»х₽,а? + <Ч»ОвТХ +Л*МЯХ "^O»rx ~^ЫЯХ +Д^»7Х
s . Л +MnotfTX’
(А.8)
Для успешного приема сообщения данная частота А^^ должна соответствовать фактической частоте приема модема A<4WRX. которая равна:
^HctRX в . 01 * ^moORX • (А-9)
Когда частота приема и частота передачи модема совладают либо имеют близкие значения, ошибки приема и передачи также приблизительно равны:
(А.Ю)
^тоатх
Таким образом, по формуле (А.7} вычисляют необходимую компенсацию ошибок генераторов для случая
(А.11)
В общем случае формула компенсации погрешностей частот имеет следующий вид:
(А.12)
Подставив в формулу (А.12) формулы (А.З) и (А.5). получаем полную формулу расчета частоты отправки DOWNLINK-пакетоб. при которой выполняется коррекция ошибок всех генераторов:
/ = f ■ **" * -f -f
'ft f V«xp.uS /ж1 '«Ml*.
Овм . vf
Приложение Б (справочное)
Фрагменты исходных кодов реализации МАС-уровня
Б.1 Функция формирования и отправки UPLINK-пакета
nbfl.status.t NBFi.TX.ProtocolE-nbfl.transport.packet_f pkti I
uinte.t ul.buti64|;
uintS.t len C-;
static .Bool parity •
uintl6_t lasr.orelfe;
memset.xdataiul.but, •. ■.sizeof < ul.but< >;
ifnbfl.mode TRANSPARENT- pkt- -phy.data.length*•: for int i-Oj 1-sizeof protE.preambulai; £••>
(
ul.but;len-•i protE_preambula|1);
I
ul.butIlen»•I
ul.but ilen-♦;
ul.but;len-•i
ul.butIlen*•;
if nbf i . tx_phy.channel
UL.DBPSK.SO.PROT.E;
else if>nbfi.tx_phy.channel UL_DBPSK_4OO_PROT_E;
else if nbf1.tx_phy.channel -UL_DBPSK_32OO_PROT_E;
else if nbfi.tx.phy.channel -
UL.DBPSK.2 S6OO.PROT.E;
• nbf i.£ull_ID|0|}
- nbf1.full.IDI1|; nbfi.tull.IDp;; nbf 1. tull.IDt ' 1 •,
dl_dbpsk_5O_prot_et nbf1.tx_phy_channel •
dl_dbpsk_400.₽R0T_E) nbf i.exjahy.channel
DL_DBPSK_32OO_PROT_E- nbfi.tx_phy.channel
DL.DBPSK_25>6OO_PROT_E nbf i. tx_phy.channel
ul.but’len-•1 pkt- -phy.data.header; memcpy.xdatagenerict^ul.buf;len', pkt- -phy.data.payload, pkt- phy.data.lengthi; lastcrclfe CRC16\AUl_buflien - 11, 9, OxFFFF);
if MAGMA.Enabled-- MAGMA .Available*) it ■ inbfi.additional_flags-.NBFI_FLG.NO_ MAGMAi•
I
magma .Encode-iul.bufilen!);
I
len >- 8;
if nbfl.mode - TRANSPARENT-
{
ul_buflien-»| pkt->phy.data.payload;дI; ul.butIlen-»J pkt->phy_data.payload!9j;
I
else
I
ul.but;len-»1 lastcrclbiOxtf;
ul.but Цеп» ♦ 1 (lastcrcl6.-*>8ji0xif;
I
last_pkt_crc - CRC32'.ul.but • 4, 1$»;
ui_but ilen»•; - -uint.8_t > fiast_pKt.crc lfc);
ul.but I len»»1 ■* iuint8_t 1< last jikt.crc -ij
ul.butilen**) ж (uintS.t--last_pkt_crc‘;
if 1nbfi.tx.freq-
tx.freq - nbfi.tx.freq ;
parity * tnbfi.tx.freq •• (nbfi.ul_freq_base • 25000m;
elee
if nbfl.cx_phy_channel • UL_DBPSK_3200_PROT„E)
<
tx_freq - nbfi.ul„freq_base ■ conet uint32„t ’is-ULL^
ID!•lastcrcis)*226» *100! ;
if parity} tx_treq - tx_treq • 27S0Q;
)
elee
tx_£req - nbfi.ul_treq„baee • 1600 • J* conet uint32_t •JFULL.,
id» ’lastcrcie; Ч2Ю1 • iooj;
if parity) tx„treq - tx_treq - 2?S00 • .i.ouj
)
)
2CODE„E_Appendi&ul.but '4, 4>ul_bur len , :i;
if•mbfi.tx„treq> parity iparity;
if nbf 1.mode KRa ii parity!
(
RF„Init:nbfi.txjshy„channel. :rf_antenna_tinb£i.tx„antenna, nbfi.tx_pwr. tx_ freq:;
RR„Trans»itlul_but, len - ZCODE_LEN, PADDING_4TO1, BLOCKING';
nbfl_s ta te.UL_tota1 • <;
return NBFl_TX_ProtoeolE;pkt};
}
RF„lnlt<nbfi.tx_phy_channel. :rf_antenna_ctnbfi.tx_antenna. nbfi.txjpwr, tx_freq:; RF_Transmit!ul_but, len - ZCODE_LEN, PADDIHG_4TO1, NONBLOCKING»; nb£i_state.UL„total--;
return OK;
)
6.2 Функция вычисления контрольной суммы (CRC8)
etatic uneigned char CRCSbyte unsigned char datai
(
uint8_t ere - u; | ||||
if data | 4 | i] | - UxSe; | |
if data | & | 2» | ere | - * Oxbc; |
if data | 4 | 4i | uxc | 0x6i; |
if data | la | HI | ere | 0XC2; |
if data | 4 | 0x10) | «С | *- 0x9d; |
if data | la | 0x20) | ere | '» 0x23; |
if data | 4 | 0x40! | ere | 0x46; |
if data | 4 | 0x80) | ere | 0x8C; |
return ere; |
)
uint8„t CRC6iuint8„t* data, uint8„t leni (
uint8_t ere - 0;
for uint8„t i - 0; 1 • len? 1--1
I
ere - CRCSbyte-data.i: ' urej;
)
return cic;
Б.З Функция вычисления контрольной суммы (CRC16)
«define POLY OxaOOl
uintl6_t CRC16*uint8„t *bufr ulntl6„t len, uintl6_t ere» (
while ilen-->
1
etc - *bui••;
ate | - uc | к | ? | (eta | ’ • | 1) | • PuLY : | ata | lj | ||
crc | - crc | к | 1 | •> | (СГС | 1) | * POLY : | crc | >> | 1; | |
crc | - crc | к | 1 | (СГС | .. | 1) | * POLY : | crc | I; | ||
crc | - crc | к | 1 | •> | (СГС | > '■ | 1) | * POLY : | crc | •• | 1; |
crc | - crc | к | 1 | (СГС | ’■. | 1) | * POLY : | crc | 1J | ||
etc | era | к | 1 | •> | (arc | 1) | ' PuLY : | arc | 1; | ||
crc | crc | к | 1 | 1СГС | » ■ | 1) | ' POLY : | crc | '• > | 1J | |
era | crc | к | 1 | icrc | ... | 1» | ‘ POLY : | crc | 1; |
I
return cicj
1
Б.4 Функция вычисления контрольной суммы (CRC32) uint32_t CRC32'const uintS^t ‘but, uint8_t len* 1
return digital.update.crc32(Oxft!ttt'1, but, lent ' Oxitittiit:
«define WIDTH <d*4i
«define TOPBIT (1 (WIDTH-IM «define POLYNOMIAL iOX1O4C11DB7>
uint32_t crc_table<uint8_t nt
I
uint32_t c;
int k;
c-(<uint32_t ин •• >wIDTH - 8); for k-(j;k:«O;k- • i
{
if с к iuint32_t*TOPBIT*
4
C - («<••-.! I • POLYNOMIAL;
I else
4 c»c<.1;
>
I return c;
I
uint32_t digltal_update_crc32< uint32_t crc, const uintS^t ‘data, uint8_t len I
while :len
crc - crc.tabie'‘data * ((crc •• 24) к Cxft)) " (crc << 8); data*•> len- ч
)
return crc;
>
Приложение В (справочное)
Таблица и функции, используемые для ZIGZAG-кодирования данных
' Zigzag code permutation table
const uintB_t n_e.4 .144; -
(
(0,1,2,3,4,=.6,7,8,9,10,11,12,13,14,15.16,17,16,19,20,21,22,23,24,25,26,27,28,29,30,31.’7
33.34.35.36.37.38.. 39.48.41.42.4 3.44,4b,46,47,48,49.SO.51,52,53,54,55.: " ’ ’ .59,60,61,6,..
63,64,65.66,67,68.0;TO 31,72;73.74,75,76,77,7В,79,BO.81,82,63,84,85,86.87,88,89,90,91.92. 93,94,95,96,97.98,49‘, 100,101,102,103,104.105,106,107,108,109,110,111,112,113,114,115,116, 117.11B,119.320.121,122,323,124,125.126,127,128,129,130,131,132,133,134.135,136,137,138, 139,140,141,142.143].
{128.96,64.32,0,11 3,ai,49,17,130.98.66,34,2,11 .51,19,132,100,68,36.4,117,85,53,21,134,
102.70.38.8.119.87.55.23.136.104.72.40.. .121.89.57.25.138.106.74.42.10.123.91.59.27.140,
108,76,44,12,12й.--,61,29,142,110,78,46,14,12 1,31.1’2,80,48,16,129,97,65,33,1,114,
82,50,18,131,99,67,38,3,116,84,52,2 0.133,101,69,37,5,11:':, 86,54,22,13S,103,71,39,7,120,88, 56.24,137,105,73,41.-.122,90,58,26,139,107,75,43,11,124,92,60,28,141,109,77,45,13,-.ii6,94, 62,30,14 .111,79.4''. 15),
{93,13.. ,34, 7 7, 120, 18, 61,104, 2. 45,88, 131, 29, 72,115,13, 56, 49,142, 40,83,126,24,67,110,6,51,94,137,35,78,121,19,62,105,3,46,8У,132,30,73,116,14,57,100,143, 41,84,127,25,68,111,9,52,95,136,36,79,122,20,63,106,4.47,90,133,31,74,117,15,58,101,42, 55,128,26,69,112,10,S3,96.139,37,80.123,21.64,107;5,48.91,134,32,75,118,16,59,102.0,43,86, 129,27,70,11 J, 11,54,97.140,38,81,124,22 49,92,135.33,76,119,17,60,103,1.44,87,130,
28,71,114,12,55.98,141,39,82,125,23.66,109,7.50J.
(2,8,14,20,26,32,38,44,50,56,62,68,74.80,86,92,98,104,110,116,122,128,134,140,1,7,13,19, 25, . 49,55,61,67,73,79,85,91.97,103,109,115,121,127,133,139,0,6,12,18,24,30,36,42,
48,54,60,66,72,78.84.90,96,102,108,114,120.126.132,138,5,11.17,23,29,35,41,47,S3,59,65,71, 77,83,89,95,101,107,113,119,125,131.137,143,4,10,16,22,28,34,40,46,52,58,64,70.76,82,88, 94,100,106,112,118,124,130,136,142,3.9.15,21,27,33,39,45,51,57,63.69,75,81,87,93,99,105, 111,117,123,129,135,141)
1;
Ydetine ZCODB.LEN 32 void ZCODE_E_Appendiuinc8_c ♦ src_but, uint8_t ♦ dst_but, _Bool parity} (
ulnt8_t bO;
uint8_t bl;
ulnc8_t bprev;
uinta.t res;
Uint8_c code;4.49} - ((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,0,0,0.01);
lor int j“0; J--4; j»»)
(
£orulnt8_t 1-0; £<72; £••<
bO - »src_buf 1 ‘Й <•: I n_e.J! 1 . %8!! & 0x80;
bl :src_but n_e;j> 72*1 /8] <•: i n_e;j;(72’i; :«!! 0x80;
bprev « (codeljj [ (1-1) /8] « ( (1-1) W) & 0x80;
tes • ЬО ' bl ' bprev;
codelj][1/8] I* res » (its);
£or(int 1*0; 1<9;1+*)
1
dat_buf[i] « icodelOMl] & (parity ? OxAA : 0x55)) I (coded! [11 & (parity ?
0x55 : OxAA));
dst_buf Ц+вр '*J(codel2j Ц] & (parity ? OxAA : 0x55)) I (coded! Ц) 1 (parity ? 0x55 ; OxAA)); ' **
I
Приложение Г (справочное)
Описание транспортных функций и сценариев взаимодействия
ГЛ Обеспечение надежной доставки данных
Для обеспечения надежной доставки данных применяется отправка пакетов в режиме HANDSHAKE.S1MPLE. Отправка выполняется посредством сеансов обмена данными между передающим и приемным узлами. При от-лравхе пользовательских пакетов (длина данных равна параметру MAXLEN) количество пакетов, входящих в сеанс отправки, определяется параметром МАСК. Значения МАСК более единицы позволяют уменьшить количество отправляемых пакетов подтверждения приема. При групповой отправке количество пакетов, входящих в сеанс отправки, равно количеству пакетов в группе. Каждый отправляемый пакет содержит в своем заголовке HEADER поле ITER, которое инкрементируется для каждого последующего пакета. Значения поля ITER изменяются в диапазоне 0—31. Передающий узел (устройство или сервер), выполняя отправку последнего пакета из группы, выставляет а нем флаг АСК в заголовке пакета. Данный флаг сигнализирует приемной стороне, что необходимо отправить в ответ системный пакет АСК.Р.
АСК.Р содержит 32-битную маску, каждый бит которой содержит информацию об успешном приеме пакета с номером итератора, соответствующим позиции бита в маске.
Передающий узел обрабатывает АСК.Р-пакет и повторно отправляет один или несколько пакетов, которые не были доставлены и которые соответствуют данному сеансу отправки.
Если передающий узел не получает АСК.Р-пакет в ответ на запрос, он повторяет отправку последнего пакета по истечении заданного интервала времени (тайм-аута) NBFI_RX_TIMEOUT. вычисляемого по формуле
NBFI RX TIMEOUT = NBFI UL.DELAY * NBFI.DL.LISTEN TIME* random()%NBFI_DL_ADD_RND_LISTEN_TIME ' ’
Параметры NBFI.UL.DELAY. NBF1.DL_LISTEN.TIME и NBF1_DL_ADD.RND_LISTEN.TIME зависят от выбранных режимов скорости передачи данных. Их значения приведены в таблицах Г.1—Г.З.
Таблица Г.1 — Значение параметра NBFI_UL_DELAYв зависимости от режима скорости передачи данных
N8Fi TX PH¥CHANNEL | TIMEOUT, c |
UL DBPSK 50 PROT E | 30 |
UL.PSK.200 | 30 |
UL DBPSK 400 PROT E | 5 |
UL PSK 500 | 5 |
UL DBPSK 3200 PROT E | 1 |
UL.PSK.5000 | 1 |
UL DBPSK 25600 PROT E | 0.5 |
UL PSK FASTDL | 0.5 |
Таблица Г2 — Значение параметра NBFI.DL_LISTEN.TIME 8 зависимости от режима скорости передачи данных
NBFl.RX.PHY.CHANNEL | TIMEOUT, c |
DL.PSK.200 | 40 |
tM.PSK.500 | 40 |
CH.PSK.5000 | 40 |
DL.PSK.FASTDL | 40 |
Таблица Г.З — Значение параметра NBFl_DL_ADD_RND_LISTEN_TiME в зависимости от режима скорости передачи данных
NBFI.RX.PHY.CHANNEL | TIMEOUT, c |
DL PSK 200 | 20 |
DL PSK 500 | 20 |
DL PSK 5000 | 20 |
DL PSK FASTDL | 20 |
Повторные отправки пакетов выполняются до тех пор. пока не будет получен ответ либо не будет превышено число повторных отправок, заданное параметром NUM_OF_RETRIES. Повторная отправка пакетов, вызванная получением АСК_Р-пакета. также входит в расчет общего числа повторов и ограничена параметром NUM.OF.RETRIES.
В случае успешной отправки воех пакетов, входящих в сеанс, передающий узел отправляет системный пакет CLEAR, информирующий приемный узел, что вое данные переданы и можно выполнить очистку истории принятых данных.
CLEAR-пакет не является строго обязательным для каждого сеанса отправки, по сути, для успешной работы протокола получателю данных достаточно одного CLEAR-пакета на один полный оборот итератора входных пакетов (32 пакета). Поэтому для снижения объема отправляемых данных можно не выполнять отправку CLEAR-пакетов для одиночных пакетов либо небольших групп пакетов.
При неуспешном выполнении сеанса отправки данных от устройства к серверу передающий узел выполняет сброс всех параметров работы NB-Fi к значениям по умолчанию и отсылает системный пакет CONF с полем данных NBFI_PARAM_MODE. уведомляя сервер о смене режима работы. Сброс параметров и отправка CONF-пакета может быть отключена при помощи флага FLG_NO_RESET_TO_DEFAULTS. содержащегося в параметре NBF1_ADDITIONAL_FLAGS.
На рисунке Г.1 приводен пример успешной отправки группового пакета1. В рамках данного сеанса выполнена отправка пяти пакетов с итераторами 12—18. В ответ на пакет с итератором 16. содержащий флаг АСК. сервер отправил АСК_Р-пакет с масхой. сообщающей, что сообщения с итераторами 12—16 успешно приняты. Приняв данный пакет, передающий узел отправил CLEAR-пакет. означающий успешное завершение сеанса.
i ■■ ill ;
(76?A99“UL|
НТМЧ ULI Л/АЧЧ ULI :70/А99 UL| i 767A9<0LI i 70 JAW ULI
л s-m • !/ • lwii.xiii group. ан olc ммадо m1—-led • <;i iwpsk 4uti_iHDi l
UL - и - 13 - 6Of2$9O3C28A5OO0 - ’\хОе\хГ2Г\хО)\хс2\х8Ы'\хОО' - UL D8PSK400 PftOT D
w. -и - 14 м$90К28Амееее - Лкевт\«13\хс2\18ат\х&в\»е8' - ul obpsk 4во pwjt о
Ul --И • 15 • 59D3C2945100F3$9 - •YXx<J3\w2\x9«0\xM\xf JV - UL DBPSK 466 PRQT 0
Ul -AH - 16 • O3C2945SOOF3D3A5 - ЗЭ59ОЭС28755МЕИ9ОЭС2вАМ8еОе59ОЗС28А54ёбОе59ОЗС294510вР359ОЗС2945$ОвРЗ
dl s- • 16 • eeoeooeooFiioede • 9i97.o - дскм 112. 13. 14. is. 16]. $mr it. - dl psk fastdl
ia s-- - 16 - мееемеоееееем - ок. server ul history - ul obpsk aoo рвот о
Рисунок Г.1 — Пример успешной отправки группового пакета
На рисунке Г2 приведен пример успешной отграеки группового пакета с повторной отправкой пакетов. В рамках данного сеанса выполнена повторная отправка пакета с итератором 13. так как 8 ответ на него не был получен АСК.Р-пакет (несмотря на то что он был отправлен). Также выполнена повторная отправка пакета с итератором 11, так как дэнклл пакет не принят сервером и не перечислен в маве АСК_Р-лакета.
■". ■ • и:: . s- н - iu • CMtu/uш.’укмл • group, пэ-к i «id амгьдо1 atic-itjies - ui иы’ък ъи I4i.it и
<?4в4Г6~Ш> U Н ■ 12 0680960786066069 -\хее\хМ\х66\х62\хЭ6\хМ\хбе\х0в' - Ul DBPSK 56_PR0T D
Р6В4Г6 ULI >'. -АН 13 • 6662888066900609 - \>66\х02\х88\х0О\хО9'.х0в\х06\хе0' • UL DBPSK 50 PROT О
j/MHFk DL> F9047446A8E91A037094
(7М4Г6 м.1 M s - 13 - ееееэебовмтеесо 9i9i:e - Ack«j no. 12. bi. st® 15. - dl psk tos
(7О04Г6 ULI I'. -AM - 13 - 0062886000600000 - Repeat. DL 26dB«. • UL OCPSK $0 PROT 0
(76B4F6 DL) F9C4 7446A8LB1A03O154
<?0B4f6~DL> ol $-■ - 13 - eeooeeooeseooece 9i9i:0 - Ack«i lie. 12. 13]. st® is. - dl psk 200
<7OB4F6_UL| la -AM - 11 • AOOO098B8F0284O6 • 32838259О27ЕА6ОеО988вР6284ООО6ОО0М286О6М5еООв288О0ООООбе 110, 11. 12. S3|
{/•R4I6 DLI G9ACD8137544F718C666
(76B4F6~DLI OL - 11 - 00406060016(00(0 9191:0 - Ack«d 116. 11. 12). SNR 12. • DL PSK 260
?M4F1 ULI Lt S-- ■ 11 ■ 0400000000000000 IX. sorver clear» UL histc.y - UL DtPSK SO PROT L>
Рисунок Г.2 — Пример успешной отправки группового пакета с повторной отправкой пакетов
В режиме работы HANDSHAKE_NONE передающий узел не выполняет запрос АСК_Р-пакетов. и передача данных в этом случав выполняется без контроля успешной доставки (верификации).
Г.2 Передача групповых пакетов
Пакеты данных большой длины (не умещающиеся в одном пакете МАС-уровня) могут быть отправлены при помощи отправки группы пакетов. Максимальное число пакетов в группе равно 30. Для UPLINK-лакетое с параметром MAXLEN. равным 8. суммарная максимальная длина пакета составляет 240 байт.
Групповая отправка может быть выполнена как 8 режимах работы с верификацией доставки данных, так и без нее. Первый пакет в группе является системным пакетом типа GROUP и содержит информацию об общей длине группы, а также контрольную сумму данных, содержащихся в группе. Размер контрольной суммы составляет 1 байт. Каждый пакет группы содержит флаг MULTI а своем заголовке. На приемной стороне выполняются обработка входных пакетов и «склеивание» пакетов в один блок данных. Программный код реализации функции вычисления контрольной суммы на языке Си приведен в разделе Б.2 приложения Б.
Г.З Передача коротких пакетов (длиной менее MAXLEN)
Пакеты, имеющие длину менее чем MAXLEN. отправляются при помощи системных SHORT-пакетов. Длина полезных данных указана 8 младших 7 битах первого байта данных SHORT-пакета. Данный параметр может иметь значения от 1 до 127. но не более чем MAXLEN-1.
Г.4 Разрешение коллизий одновременной передачи
Базовые станции стандарта NB-Fi позволяют вьполнять одновременный прием и передачу множества каналов. Это позволяет не учитывать при реализации транспортного уровня коллизии, вызванные одновременной передачей пакетов различными устройствами. Также прием данных базовой станцией выполняется без снижения качества в момент передачи данных на устройства.
В противовес базовым станциям конечные устройства NB-F» работают в режиме «полудуплекс», выполняя единовременно либо прием, гыбо передачу данных.
Коллизии возникают в тот момент, когда базовая станция и устройство выполняют встречную передачу пакетов.
Для минимизации вероятности возникновения данных коллизий поведение устройств и сервера должно определяться с учетом следующих правил;
1) При отправке очередного пакета данных передающая сторона всегда выставляет в заголовке пакета флаг MULTI в том случае, если вслед за данным пакетом планируется отправка следующего. Приемная сторона, принимая пакет с флагом MULTI, должна продолжать выпогыять прием и не выполнять передачу до получения пакета без флага MULTI либо до истечения заданного интервала времени (тайм-аута) NBFI_DL_L1STEN_TIME. Величина данного тайм-аута различается для разных скоростей приема.
2) При повторных отправках пакетов по причине неполучения АСК_Р-пакега в ответ на запрос флага АСК используемый тайм-аут должен иметь различные значения от повтора к повтору. Это позволяет избежать циклического повторения коллизии из-за постоянства значений тайм-аутов. Переменная составляющая тайм-аута повторов определяется параметром NBFI_DL_ADD_RND_LISTEN_TIME. Величина данного тайм-аута различается для разных скоростей приема.
Г.5 Особенности работы в режиме DRX
Данный режим предназначен для устройств, которые должны обладать очень малыми значениями среднего потребления энергии (например, устройства с батарейным питанием). Проблема реализации радиосвязи в таких устройствах заключается 8 невозможности выполнения приема данных в непрерывном режиме. ORX — это режим, который специально разработан с целью решить данную проблему максимально эффективно.
Отличие от режима CRX состоит в том. что устройство кратковременно переходит в режим приема сразу после окончания передачи последнего пакета из группы пакетов, отправляемых непрерывно друг за другом. Сервер выполняет отправку данных только во время действия данного «временного окна».
Таким образом, сеанс обмена данными происходит по инициативе устройства. Сервер может инициировать дополнительные сеансы обмена, используя флаг MULTI в заголовке последнего пакета, отправляемого устройству в рамках предыдущего сеанса.
Сеанс отправки данных от устройства к серверу выполняется 8 полном объеме до подтверждения приема всех пакетов. Следующий за ним сеанс отправки данных от сервера к устройству может быть прерван из-за потерь данных при плохом уровне сигнала и затем продолжен при следующем «выходе устройства на связь».
Г.6 Синхронизация системного времени
При обмене данными в режиме подтверждения доставки возможна реализация механизма синхронизации времени между сервером и конечными устройствами. Сценарий взаимодействия между сервером и устройством следующий:
• конечное устройство, выполнив отправку данных и получив пакеты, подтверждающие их доставку, отправляет системный пакет CLEAR_T. информирующий приемный узел (сервер) о том. что все данные переданы и можно выполнить очистку истории принятых данных. Помимо этого, в данном пакете содержится значение текущего (на момент отправки пакета) времени системных часов передающего узла (устройства). Время передается в виде 4-байтмого значения, соответствующего формату времени Unix Timestamp (количество секунд от 1 января 1970 гада) и часовому поясу UTC.
Сервер сравнивает полученное время с собственным системным временем и в том случае, если разница превышает значение 8191 с. отсылает системный пакет SENDT1ME. содержащий значение текущего времени s формате Unix Timestamp. Пакет отсылается без запроса подтверждения.
Если разница не превышает значение 8191 с. но более 30 с, то сервер запоминает это значение для того, чтобы при следующем сеансе обмена выполнить коррекцию системного времени устройства, отправив величину данной поправки внутри пакета АСК.Р.
Таким образом, при регулярной отправке данных в режимах работы CRX и DRX выполняется синхронизация времени конечного устройства с точностью (с учетом возможных задержек при прохождении данных через очередь отправки базовой станции и сеть Интернет) от несхогъких секунд до нескольких минут. Преимуществом данного механизма является практически полное отсутствие отправки дополнительных пакетов в обоих направлениях.
Г.7 Смена ключа шифрования МАС-уровня
Выделение нового ключа шифрования выпогмяет конечное устройство по собственной инициативе либо по запросу от сервера при помощи системного пакета GETNEWKEY. Устройство генерирует случайное число размером 32 байта и отправляет его на сервер в виде пяти системных пакетов KEY0—KEY4. При этом шифрование передаваемой информации обеспечивается с использованием старого ключа шифрования.
Сервер, получив ключ шифрования, выполняет отправку пакета CONF (код параметра NBF1.APPLY.KEY). содержащего контрольную сумму ключа размером 4 байта. Устройство, получив этот пакет, сверяет контрольную сумму и в случае совпадения применяет новый ключ. Данный CONF-пакет отправляется сервером командой WRITE.CMD.ACK. что обеспечивает двойное квитирование доставки.
Г.8 Описание способов идентификации устройств
Для идентификации типа устройства необходимо использовать три строковых идентифмеатора. длина которых не должна превышать 128 байт:
• идентификатор производителя — параметр, уникальный для каждого производителя устройств:
• идентификатор устройства — параметр, уникальный для каждого типа устройств:
- идентификатор протокола — параметр, однозначно определяющий формат данных и логику работы устройства на уровне приложения.
Данные идентификаторы сервер приложений запрашивает у устройства при их отсутствии в базе данных сервера либо устройство отправляет их самостоятельно при первом включении периодически или при изменении значений.
Для получения значений идентификаторов сервер должен отправить пакет уровня представления с командами NBFI_PL.GET_MAN.ID. NBFI_PL.GET_HW.1D и NBFI.PL_GET_PROT.ID. Устройство должно прислать ответный пакет с таким же кодом команды и со значением соответствующего идентификатора 8 поле DATA.
Сервер приложений использует данные идентификаторы для определения, поддерживается ли данное устройство и каким образом необходимо выполнять взаимодействие с данным устройством.
Г.9 Описание механизма изменения типа шифрования и смены ключа на уровне представления
Возможно использование трех режимов работы шифрования на уровне представления: без шифрования. «Магма», в также режим шифрования с использованием другого выбранного алгоритма (два варианта выбора). Тип шифрования, который использован для шифрования поля DATA, всегда должен быть указан в none ENC.
Для систем, к которым предъявляются требования в части безопасности передачи данных, включенный режим шифрования на уровне представления является обязательным, поскольку он обеспечивает достоверную идентификацию устройства и целостность данных.
Для смены типа используемого шифрования либо его включения или отключения сервер приложения должен отправить одну из команд:
NBFI.PL.ENC.SET.NONE. NBFl.PL.ENC.SET.MAGMA. NBF1_PL_ENC_SET_CUSTOMCRYPTO1. NBF1_PL_ENC_SET_CUSTOMCRYPTO2.
Если устройство не поддерживает данный тип шифрования, то оно не меняет режим шифрования, и данные продолжают поступать с прежним значением поля ENC.
Выделение нового ключа шифрования выполняет конечное устройство по запросу от сервера при помощи пакета с кодом команды NBFI.PL_ENC_NEW.KEY. Устройство генерирует случайное число размером 32 байта и отправляет его на сервер внутри поля DATA.
Сервер, получив ключ шифрования, выполняет отправку пакета с ходом команды N8FI.PL.ENC.APPLY. KEY. содержащего в поле DATA контрольную сумму ключа размером 4 байта. Устройство, получив этот пакет, сверяет контрольную сумму и в случае совпадения применяет новый ключ.
Описание механизма автоматического выбора оптимальной скорости передачи данных
Устройства, работающие в режимах DRX и CRX. выполняют автоматический контроль качества радиосигнала (как приема, так и передачи) и производят смену скоростей передачи данных, опираясь на средние значения соотношений сигнагУшум (SNR) для UPLINK-пакетое и OOWNLlNK-пакетов.
Расчет SNR на входе приемника устройства выполняется при приеме пакетов, используя данные, предоставляемые аппаратурой радиотрансивера. входящего в состав устройства. Расчет SNR выходного сигнала выполняется на основании данных, которые измеряет базовая станция на входе своего приемника и которые передаются устройству в одном из полей АСК_Р-пакета.
Решения о смене скорости передачи данных UPLINK-пакетое либо DOWNLINK-пакетов принимает устройство. анализируя уровни SNR.
При достаточно высоком знамении SNR (г SNRLEVEL.FOR.UP * TXSNRDEG либо г SNRLEVEL.FOR.UP + RXSNRDEG) выполняется перевод скорости на один уровень выше. Так как сервер принимает одновременно все поддерживаемые скорости передачи UPLINK-пакетое. смена скоростей UPLINK осуществляется без уведомления сервера. При смене скорости OOWNLlNK-пакетов выполняется отправка системного CONF-пакета с полем данных NBFI.PARAM.MODE, содержащим новые параметры скоростного режима. Данный пакет формируется с флагом АСК и требует подтверждения приема. Прием пакета АСК.Р устройство выполняет уже на новой скорости. В отсутствие ответного пакета выполняются повторные отправки CONF-пакетов. Если после определенного числа повторных попыток доставки CONF-пакета. равного NUM.OF.RETRIES. пакет АСК_Р так и не был получен, устройство возвращает свой скоростной режим в предыдущее состояние, отсылая CONF-пакет с полем данных NBFI.PARAM.MODE. содержащим предыдущие значения параметров скорости. В этот раз CONF-пакет отсылается единожды без запроса подтверждения.
Повышение скорости UPLINK либо DOWNLINK выполняется при условии, что базовая станция поддерживает более высокие скоростные режимы. Об этом сервер уведомляет устройство, выставляя флаги UL.SPEED NOT.MAX и DL.SPEED_NOT.MAX. содержащиеся в пакете АСК.Р.
Устройство повышает скорость передачи данных до тех пор. пока уровень SNR не снизится до значения, не позволяющего выполнять дальнейшее повышение, либо пока не будет достигнуто максимальное значение скорости.
Если при достижении максимального уровня скорости передачи UPLINK-пакетое уровень SNR имеет достаточное значение (2 SNRLEVEL.FOR.UP + TXSNRDEG). устройство выполняет постепенное (с шагом 3 дБ) снижение мощности передатчика.
Если при достижении максимального уровня скорости приема DOWNLINK-пакетов уровень SNR имеет достаточное значение (2 SNRLEVEL.FOR.UP * RXSNRDEG). устройство уведомляет сервер о необходимости снижения выходном мощности передатчика базовой станции, выставляя флаг DL_POWER.STEP.DOWN в пакете АСК.Р. отправляемом от устройства к серверу.
Если уровень SNR снижается ниже заданного значения (SNRLEVEL.FOR.DOWN), устройство выполняет обратные действия. Сначала повышается выходная мощность передатчиков устройства или базовой станции, затем выполняется ступенчатое снижение скорости передачи либо приема данных.
Для уведомления сервера о необходимости повышения выходной мощности используется флаг DL.POWER. STEP.UP в пакете АСК.Р. отправляемом от устройства к серверу.
Пороговые уровни для повышения и понижения скоростей либо мощности и поправочные коэффициенты для различных скоростей приведены в таблицах Д.1—Д.З.
Таблица Д.1 — Пороговые уровни для повышения и понижения скоростей либо мощности
Параметр | Значение порога. дБ |
SNRLEVEL.FOR.UP | 15 |
SNRLEVEL.FOR.DOWN | 10 |
Таблица Д.2 — Значение поправочного коэффициента TXSNRDEG для различных скоростей передачи
N8FI.TX.PHY.CHANNEL | Поправочное значение. дБ |
U L.DB PSK.50.PROT.E | 0 |
Окончание таблицы Д.2
NBFI ТХ PHY CHANNEL | Поправочное значение. дБ |
UL DBPSK 400 PROT E | 9 |
UL DBPSK 3200 PROT E | 18 |
UL DBPSK 25600 PROT E | 27 |
Таблица Д.3 — Значение поправочного коэффициента RXSNRDEG для различных скоростей приема
NBF1.RX.PHY.CHANNEL | Поправочное значение. дБ |
DL.PSK.200 | 0 |
DL.PSK.500 | 4 |
DL.PSK.5000 | 14 |
DL.PSK.FASTDL | 25 |
Механизм автоматического выбора скоростного режима работы устройства может быть отключен при помощи флага FLG.F1XED_BAUD.RATE. содержащегося в параметре NBF1.ADDITIONAL.FLAGS.
Механизм автоматического управления мощностью передачи может быть отключен при помощи флага FLG.NO_REDUCE_TX.PWR. содержащегося в параметре NBFI.ADDITIONAL.FLAGS.
На рисунке Д.1 приведен пример сеанса обмена пакетами, выполняющий повышение скоростей передачи и приема2.
UL1 (6FB2f(~DL) <6ГВ2Е<~01_) (Ь(В?К UL) (6FB2EC 0L) (6FB2K 01) (бгвмГии (6FB2EC 0L) (6FB?EC_0L) <6ЕВ2ЕС UL) (bFB2FC_0L)
ОН
SA • 01 • 61«A21Ceeoe«3E0F • Нэ2-п Info: J.34V, 284. Average SMR 01 0. UL 0. Kobe -136, UL 15dBn звиб74ез9Сб2С7ввяеб dl s-- -oi • eeoeo6oeo»456K0 • UL SA- • 02 - 0686Oiei)8816FO2 -6677428вО40А4534Л02£ PL S- 02 0000000000460040
UL SA- - 02 • 6680010L16026F02 -00774286047745343036 DL S- • - 02 - 0006000000360040 -
9297:0 • Acked (I. SNR 69. • PL PSK 206
PHY node: UL_OBPSKjee_PROT_P & PL_PSK_S68 26dB« ■ UL_MP$K_4ee_PfU>1_0
9297:0 Ack«4 tl. S№ 70. - Pl_PSX 508
PHY node: UL_DB₽SK_406_PROT_D & PL_PSk_5O9O 26Ля - UL.PBPSK_4M_₽R0T_P
9297:0 - Ackod (!, SNR 59. ■ PL_PSK_5066
UL SA- • 02 • 0686610118O36F62 • PHY node: UL PBPSK 400 PRO! 0 & PL PSK FASTOL 26свя • UL OBPSK 400 PROT 0 60774288047245342037
Dl S • • 02 • OOOOO6t>9O03[O648 • 9297:0 • Aikcd fl, SkR 62. • Dt ₽SK TASTDL
Рисунок Д.1 — Пример сеанса обмена пакетами, выполняющий повышение скоростей передачи и приема
Настройка параметров NB-Fi
Режимы функционирование протокола NB-Fi конкретного устройства определены совокупностью параметров. объединенных в единую структуру данных NBFI_SETTINGS. Некоторая часть данных параметров должна быть известна серверу для обеспечения нормальной работы протокола. В частности, такими параметрами являются следующие: режим работы устройства, текущие скорости передачи данных, перечень поддерживаемых устройством скоростей, рабочий диапазон частот и t д. Данные параметры записываются в базу данных сервера при выделении лицензии на конкретные устройства и затек! в процессе работы синхронизируются с соответствующими значениями этих параметров в устройстве посредством отправки системных пакетов.
Все параметры NB-Fi устройства доступны для чтения и записи при помощи системных CONF-пакетов. Формат данных пакетов и наименование параметров описаны в 7.2.
Защита данных в протоколе NB-Fi
Шифрование данных выполняется на двух уровнях — МАС-уроене и на уровне представления.
Шифрование на МАС-уроене предназначено для зашиты механизма обмена данными на транспортном уровне. Шифрование данных выполняется как для UPLINK-пакетов. так и для DOWNLINK-пакетов.
Для шифрования данных на МАС-уровне применяется алгоритм «Магма», используются уникальные ключи длиной 256 бит.
Пакеты данных UPLINK и DOWNLINK содержат поле, соответствующее контрольной сумме незашифрованных данных. Это позволяет, выполнив дешифрование пакета, проверить валидность полученных данных и отбросить пакет 8 случае несовпадения ключей сервера и модема. Данный механизм делает систему связи устойчивой не только к попыткам несанкционированного получения данных, но и к попыткам злонамеренного заполнения эфира пакетами со случайным содержанием в поле Payload с целью нарушения нормальной работы устройств.
Возможны два сценария присвоения ключей устройствам — «прошивка* ключей при производстве либо выделение новых ключей при подключении устройства к сети.
В первом варианте ключи шифрования генерируются случайным образом при выделении лицензии на сервере оператора сети. Каждому ID (идентификатору) NB-Fi сопоставляется персональный ключ, который сохраняется на сервере и в выходном файле лицензии, используемом впоследствии при «прошивке» программ в модемы устройств. Данный вариант обеспечивает контроль над уникальностью идентификаторов NB-Fi. выполняет защиту от несанкционированной передачи под «чужим» ID на любом этапе взаимодействия устройства с сервером. Возможен также сценарий «прошивки» в устройство временного ключа шифрования, который при подключении устройства к сети будет изменен по инициативе сервера или устройства.
Во втором варианте устройства изначально не содержат ключ шифрования, и при подключении к сети используется «открытый» обмен данными. По инициативе устройства выполняется регистрация нового идентификатора на сервере и выделяется ключ шифрования. Данная процедура выполняется успешно только в случае отсутствия на сервере информации об уже зарегистрированном устройстве с таким идентификатором.
Шифрование данных на уровне представления позволяет выполнять дополнительное шифрование пользовательских данных с целью сделать их недоступными для оператора сети, обслуживающего транспортный сервер, но не владеющего сервером приложений для данного устройства.
Выделение ключей шифрования выполняется сервером приложений по инициативе сервера.
Используемые алгоритмы шифрования: «Магма», другой выбранный алгоритм (см. 8.1.8.2.3).
Размер ключа шифрования — 256 бит.
Помимо шифрования на уровне представления выполняется присвоение каждому следующему пакету данных нового идентификатора (итератора) размером 16 бит. что позволяет реализовать защиту данных от атаки повторного воспроизведения.
Примеры использования протокола NB-Fi
В настоящем приложении приведен пример создания решения по удаленному сбору данных на протоколе NB-Fi для жилищно-коммунального хозяйства (ЖКХ) и городского хозяйства (2].
И.1 Описание системы
LPWAN-сеть. использующая протокол связи NB-Fi в нелицензируемом диапазоне частот, разработана российской компанией и успешно применяется в России и за рубежом, с суммарным числом установленных устройств в 2017 году более 100 тыс. шт. Компания реализовала проекты по созданию удаленного сбора данных с приборов учета ресурсов ЖКХ в более чем 50 городах России.
Высокая дальность связи и большая емкость сети позволяют обеспечивать сбор данных с большого количества устройств при помощи одной базовой станции.
Например, типовой случай использования данной технологии — установка базовой станции на крыше одного из зданий микрорайона и счетчиков воды и электроэнергии в каждую квартиру близлежащих домов 8 радиусе нескольких километров. При этом осуществляется 100%-ный сбор данных со всех устройств, включая данные с устройств, установленных в металлические щиты и полуподвальные помещения.
И.2 Архитектура системы
Архитектура системы состоит из четырех уровней и включает в себя:
1) устройства, отправляющие и принимающие данные по протоколу стандарта NB-Fi;
2) базовые станции, осуществляющие прием, обработку и передачу сообщений от устройств (UPUNK-пакегы) на телеком-сервер. а также отправку нисходящих сообщений на устройства (DOWNLINK-пэкеты);
3) телеком-сервер, осуществляющий прием, обработку и хранение сообщений от всех базовых станций для всех устройств, а также обеспечивающий интеграцию исходных данных с сервером приложений и со сторонними программно-техническими комплексами;
4) сервер приложений, осуществляющий отображение данных от устройств клиентам и предоставляющий возможность выгрузки отчетов в требуемом виде.
И.З Описание устройств
Компания самостоятельно производит и разрабатывает все компоненты системы: устройства, базовые станции. серверное программное обеспечение. В настоящий момент компания использует микроконтроллер STM32 с радиотрансивером компании ON Semiconductor АХ5043. разработав для данной аппаратной платформы ПО с реализацией протокола передами данных по стандарту NB-Fi.
Компания производит устройства, отправляющие и принимающие данные по протоколу стандарта NB-Fi. среди которых:
• счетчики воды с накладным внешним модемом;
• счетчики воды со встроенным в основную плату модемом:
• однофазные и трвхфазные счетчики электрической энергии со встроенным модемом;
• теплосчетчики со встроенным и внешним модемом;
• счетчики газа со встроенным модемом;
• радиомодемы, подсоединяющиеся к импульсным или цифровым выводам внешних устройств.
Перечисленные выше устройства выпускаются с автономным питанием (от батареи), при этом существует возможность использовать и внешнее питание.
Счетчики воды, газа, тепла отправляют сообщения два раза в сутки и содержат внутри себя данные о почасовом потреблении энергоресурсов.
Счетчики воды с накладным модемом получают показания о потреблении при помощи оптического датчика, который считывает вращение бегунка. Накопленное число вращений передается на сервер приложений, где складывается с начальными показаниями данных счетчика.
Аналогично работает радиомадем. считывающий импугъсы с импульсных выходов устройств: накопленные значения импульсов передаются на сервер приложений, где суммируются с начальными показаниями.
Счетчики воды, тепла, газа со встроенным радиомодулем два раза 8 сутки передают актуальные показания с почасовой разбивкой. Счетчики со встроенным модемом имеют жидкокристаллический дисплей, отображающий показания, и именно эти показания и передаются на сервер приложений.
Счетчики тепла, электроэнергии с внешним радиомодемом с цифровым (RS-485) выходом считывают показания с прибора учета по цифровому интерфейсу. Для отдельных приборов учета разработаны индивидуальные радиомодемы, позволяющие осуществить монтаж радиомодема под крышку устройства. Радиомодемы с батарейным питанием в зависимости от конфигурации отправляют данные с периодичностью от одного раза в месяц до
двух раз 8 сутки. Существует модель радиомодема для электросчетчика с питанием от сети, что позволяет увеличить срок службы радиомодема.
Указанные выше устройства отправляют на сервер только восходящие (UPLINK) сигналы без подтверждения доставки. В случае пропуска сигнала в определенный период на сервере приложений данных за этот период не окажется, и при следующем получении сигнала на сервере приложений будут отображены только имеющиеся данные (последнее значение потребления на приборе учета и почасовая разбивка потребления за периоды, по которым данные переданы).
Выпускаемые компанией электросчетчики осуществляют отправку сообщений на сервер один раз в час. Сообщения содержат данные о потреблении электроэнергии по каждой фазе, а также прочие параметры сети. Устройства работают в режиме CRX (Continuous RX) и обеспечивают постоянный прием нисходящих (DOWNLINK) сообщений от сервера. Отправка данных на электросчетчик с сервера возможна в любой момент. Данный режим работы позволяет отправлять подтверждение доставки сигнала, а также конфигурировать электросчетчик и осуществлять управление реле электросчетчика.
Мощность излучения устройств, как правило, составляет 15 мВт при максимально разрешенном уровне излучения 25 мВт. Расчетный срок работы устройств от батареи составляет свыше 10 лет. Рабочий температурный диапазон устройств составляет от минус 40 *С до плюс 70 *С.
Примеры реализации конечных устройств (импугъснопо модема и платы комплекта разработчика), включающие проекты печатных плат и программное обеспечение в исходных ходах, а также библиотеку реализации протокола N8-Fi. содержатся в файловом архиве [3].
И.4 Описание базовых станций
Базовая радиостанция представляет собой стационарный приемопередатчик радиосигнала. Для приема восходящих (UPLINK) пакетов данных со стороны базовой станции применяется принцип SDR-систем (software-defined radio), где входной радиосигнал оцифровывается во всей полосе приема 50 кГц и в дальнейшем подвергается программной обработке. Прием пакетов выполняется базовой станцией по всей полосе частот, при этом выделяются одновременно пакеты, имеющие различные скорости. Теоретическое количество каналов составляет 1024 для скорости 50 бит/с. и 128.16 и 2 для скоростей 400. 3200 и 25600 бит/с соответственно.
Передача нисходящих (DOWNLINK) пакетов выполняется при помощи цифрового модулятора сигнала, позволяющего передавать одновременно несколько узкополосных каналов, если суммарная мощность передачи не превышает установленного значения. Передача осуществляется в полосе 100 кГц.
За счет разнесения полос приема и передачи по частоте и развязки приемной и передающих антенн по поляризации достигается одновременный прием и передача (полный дуплекс) без ухудшения характеристик радиосвязи.
Габаритные размеры корпуса базовой станции (высота * ширина * глубина, мм) составляют 200 » 120 » 75. Рабочие условия эксплуатации базовой радиостанции позволяют устанавливать базовую станцию на улице — температура окружающей среды от минус 50 *С до плюс 70 *С. относительная влажность (без конденсации алаги) от 40 до 98 %. Степень защиты корпуса от проникновения пыли и воды соответствует IP67 по ГОСТ 14254.
Базовая станция имеет вычислитегънов ядро FPGAArtix 100. Характеристики производительности базовой станции:
- число арифметических операций — свыше 7500 MFLOPS (млн операций/с):
• скорость произвольного доступа к памяти — свыше 100 Гбит/с:
• производительность декодера помехоустойчивого кода — не более 40 000 гипотез/с:
• суммарная информационная скорость декодера помехоустойчивого кода — свыше 5 Мбит/с:
• чувствительность базовой станции — минус 150 dBm (для скорости 50 бит/с).
В зависимости от комплекта поставки базовая станция может комплектоваться одной или несколькими антеннами: принимающая коллинеарная антенна (для приема UPLINK-пакетов). антенна, передающая петлевой вибратор (для отправки DOWNLINK-пакетов). двухдиапаэонная секторная антенна (для UPLINK- и DOWNLINK-пакетов).
В зависимости от исполнения телеком-сервер и сервер приложения могут быть реализованы прямо на базовой станции, что обуславливается требованиями заказчиков к автономности и изолированности используемых систем.
Пример реализации базовой станции, построенной на базе простого SDR-приемника и одноплатного встраиваемого микрокомгъютера Raspberry PI. содержится в файловом архиве (3].
В данном решении прием UPLlNK-лакетое выполняется при помощи программной обработки записанного сигнала с поддержкой скоростей приема 50 и 400 бит/с. Передача DOWNLINK-пакетов выполняется при помощи радиотрансивера компании ON Semiconductor AX8052F143 с поддержкой всех описанных в настоящем стандарте скоростей передачи.
В файловом архиве содержатся проект печатной платы SDR-лриемнжа и программное обеспечение базовой станции в исходных кодах, написанное на языке программирования C++ с использованием библиотеки Q15.
И.5 Описание телеком-сервера
Функциями телеком-сервера являются:
• хранение в базе данных информации об устройствах (идентификаторы, ключи шифрования МАС-уровня, режимы работы транспортного уровня);
• получение восходящих пакетов с данными от множества базовых станций:
• дешифрование данных МАС-уровмя и отбрасывание пакетов, не прошедших проверку целостности да>«ых:
• выделение уникальных пакетов (фильтрация и отбрасывание копий одного и того же пакета, принятого разными станциями):
• реализация функций транспортного уровня NB-Fi;
• выбор наилучшей базовой станции для отправки нисходящих пакетов для каждого устройства:
• сохранение пакетов 8 базу данных:
• взаимодействие с серверным ПО уровня приложений посредством API-интерфейса.
Использование центрального телеком-сервера в качестве ответного узла для всех конечных устройств сети NB-Fi позволяет организовать сеть передачи данных большого радиуса действия, содержащей огромное количество устройств (от сотен тысяч до десятков миллионов). Преимуществом реализации транспортного уровня на стороне сервера является простое разрешение коллизий между пересекающимися по покрытию базовыми станциями при отправке нисходящих пакетов на устройства. В подобной централизованной архитектуре масштабирование сети по расширению покрытия либо по увеличению плотности установки устройств выполняется максимально легко. простым добавлением базовых станций и устройств без необходимости конфигурирования.
Установка телеком-сервера возможна в том числе и на базовые станции. Это позволяет организовать полу-чение/отправку данных непосредственно с базовых станций и на них. При этом возникает необходимость конфигурирования каждой станции в части загрузки в нее информации об устройствах, что делает масштабирование сети проблематичным.
И.6 Описание сервера приложений
Функциями сервера приложений являются:
• поддержка механизма защиты данных уровня представления NB-Fi:
• поддержка конкретных моделей устройств:
а) преобразование пакетов от телеком-сервера 8 данные для отображения потребителю:
б) преобразование команд от потребителя в пакеты для отправки через телеком-сервер:
в) конфигурирование устройств, обновление ПО. диагностика исправности:
• длительное хранение данных:
• предоставление данных и управление устройствами через API-интерфейс:
• предоставление данных и управление устройствами при помощи графического интерфейса пользователя:
• аналитический и статистический анализ данных, выгрузка отчетов:
• другие функции, зависящие от предметной области данного приложения.
Сервер приложений является верхним уровнем телекоммуникационной системы, построенной на базе сети передачи данных NB-Fi. Данный компонент не является стандартным решением со строго определенным перечнем функций. Его задачи зависят от предметной области, для которой используется система (мониторинг ресурсов ЖКХ. система охранной сигнализации, контроль технологических процессов, момгторинг сельского хозяйства и т. д.). Возможна одновременная работа различных серверов приложения, взаимодействующих с единым телеком-сервером.
Сервер приложений может использовать механизм зашиты данных уровня представления, обеспечивая дополнительное шифрование данных приложения, делая их недоступными поставщику телекоммуникационных услуг (владеющему телеком-сервером).
Библиография
[1] //www.ee.cityu.edu.hk/-liping/Research'Jo<jtnal.Zigzag pdf
[2] https://waviot.ru/vse-proekty/
[3] www.w3viot.ru/files/nb-ri/nb-fi-samples.zip
УДК 004.738
ОКС 35.020. 35.110
Ключевые слова: информационные технологии, интернет вещей, протокол беспроводной передачи данных, узкополосная модуляция радиосигнала. NB-Fi
БЗ 1—2019/13
Редактор Л.С. Зиминова
Технический редактор И.Е. Черепкова Корректор Е.Р. Ароян Компьютерная верстка Ю.В. Поповой
Сдано в набор 21.02.2019. Подписано в печать 18.03.2019. Формат 60 « B4'/g. Гарнитура Ариал. Усл. печ. п. 6.59. Уч.-изд. п. 5.02
Подготовлено на основе электронной версии, предоставленной разработчиком стандарта
ИД «Юриспруденция». 115419. Москва, ул. Орджоникидзе. 11. wwvquneizdal.ru y-book@maJ.ru
Создано в единичном исполнении , 117418 Москва. Нахимовский пр-т. д. 31. к. 2.
www.90slinl0.ru info@goelinfo.ru
1
Взят из log-файла обмена на телеком-сервере компании ООО «Телематические Решения» (бренд «WAVIoT»).
2
Взят из log-файла обмена на телеком-сервере компании ООО «Телематические Решения», (бренд «WAVIoT»).