ПНСТ 820-2023 Информационные технологии. Интернет вещей. Протокол передачи данных для высокоемких сетей на основе сверхузкополосной модуляции радиосигнала (OpenUNB)

        ПНСТ 820-2023

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

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

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

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

Information technology. Internet of things. Wireless protocol based on ultra narrow band RF modulation (OpenUNB)

ОКС 35.020

35.110

Срок действия с 2023-03-31

до 2026-03-31

Предисловие

1 РАЗРАБОТАН центром компетенций НТИ "Сквозные технологии беспроводной связи и интернета вещей" АНОО ВПО "Сколковский институт науки и технологий"

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

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва, Инновационный Центр Сколково, Большой бульвар, д.30, стр.1 и/или в Федеральное агентство по техническому регулированию и метрологии: 123112 Москва, Пресненская набережная, д.10, стр.2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе "Национальные стандарты" и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

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

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

Связь между конечными устройствами и шлюзами осуществляется с использованием сверхузкополосных сигналов с модуляцией DBPSK (Differential Binary Phase Shift Keying) или FSK (Frequency Shift Keying) и помехоустойчивого полярного кодирования. Это позволяет добиться высокой дальности, энергоэффективности и емкости (пропускной способности) сети.

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

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

Сети OpenUNB, построенные в соответствии с настоящим стандартом, относятся к классу энергоэффективных сетей дальнего радиуса действия или Low Power Wide Area Network (LPWAN).

Протокол OpenUNB предназначен для односторонней передачи данных от множества конечных устройств (например, датчиков и счетчиков) до центрального сервера сети с ретрансляцией через множество шлюзов. Связь между конечными устройствами и шлюзами осуществляется по радиоканалу с использованием сверхузкополосных сигналов с модуляцией DBPSK (Differential Binary Phase Shift Keying) или FSK (Frequency Shift Keying) и помехоустойчивого полярного кодирования. Это позволяет добиться высокой дальности и энергоэффективности передачи и высокой емкости (пропускной способности) сети.

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

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

Высокая энергоэффективность передачи данных позволяет применять настоящий стандарт для построения сетей, работающих в нелицензируемых диапазонах частот, имеющих ограничения на мощность излучаемого передатчиком сигнала, например в диапазоне 868.7-869.2 МГц.

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

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

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

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

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

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

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

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

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

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

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

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

3.6 эпоха: Ограниченный период времени, в течение которого конечное устройство передает пакеты данных серверу сети.

4 Обозначения и сокращения

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

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

- константы записываются в формате CONST_PARAM_NAME;

- названия полей в форматах передаваемых пакетов записываются в формате PacketFieldName;

- названия временных переменных в процедурах записываются в формате variable_name.

5 Архитектура сети OpenUNB

5.1 Общая архитектура

На рисунке 1 представлена общая архитектура сети.

Рисунок 1 - Архитектура сети

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

Архитектура сети OpenUNB удовлетворяет требованиям международных стандартов, описывающих архитектуру беспроводных сетей LPWAN со сверхузкополосной модуляцией (см., например, [1]*). Сеть OpenUNB предусматривает три уровня сетевого взаимодействия:

- физический уровень;

- канальный уровень;

- уровень приложений.

5.2 Функции физического уровня

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

Функции конечных устройств:

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

- формирование пакетов;

- модуляция радиосигнала.

Функции шлюзов сети:

- демодуляция радиосигнала;

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

- помехоустойчивое декодирование принятых пакетов;

- пересылка успешно принятых пакетов на сервер сети.

5.3 Функции канального уровня

Канальный уровень отвечает за механизм управления доступом устройств к радиоканалу (Media Access Control, MAC) и механизм управления логической связью (Logical Link Control, LLC) между устройствами и сервером сети.

Канальный уровень определяет:

- формат пакетов канального уровня;

- схему адресации конечных устройств;

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

- механизм повторных передач пакетов;

- процедуру активации (аутентификации и регистрации) устройств на сервере;

- механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).

Канальный уровень протокола реализуется на конечных устройствах и сервере сети.

Функции конечных устройств:

- зашифрование и имитозащита данных;

- формирование и отправка пакетов активации;

- формирование и отправка пакетов данных.

Функции сервера сети:

- обработка пакетов активации (аутентификация и регистрация устройств на сервере);

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

- проверка целостности и подлинности пакетов;

- расшифрование пакетов;

- пересылка успешно расшифрованных пакетов на сервер приложений.

5.4 Функции уровня приложений

Сервер приложений отвечает за хранение и обработку прикладных данных, полученных от устройств.

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

5.5 Требования к каналам связи

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

Канал связи "шлюз - сервер сети" обеспечивает двусторонний обмен информацией между шлюзом и сервером сети. Реализация данного канала выходит за рамки настоящего стандарта.

Канал связи "сервер сети - сервер приложений" обеспечивает двусторонний обмен информацией между сервером сети и сервером приложений. Реализация данного канала выходит за рамки настоящего стандарта.

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

6 Физический уровень

6.1 Формат пакетов

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

Рисунок 2 - Формат пакетов

Примечание - В описании формата пакетов порядок следования битов и байтов - от старшего к младшему (big endian).

Общая длина пакета физического уровня составляет 20 байт или 28 байт в зависимости от длины передаваемых полезных данных. Пакет включает два поля:

- Preamble;

- PHYPayload.

Поле Preamble содержит преамбулу пакета физического уровня. Алгоритм демодуляции, реализованный на шлюзе, использует данное поле для обнаружения пакета и синхронизации его последующей обработки. Поле Preamble имеет фиксированную длину 4 байта. В качестве преамбулы рекомендуется использовать различные m-последовательности, которые обладают выраженной автокорреляционной функцией. Рекомендуемое значение преамбулы физического уровня 0x97157A6F.

Поле PHYPayload содержит в себе сформированный пакет канального уровня, закодированный помехоустойчивым кодом. Длина поля PHYPayload с учетом избыточности помехоустойчивого кодирования (скорость кода равняется 1/2) составляет 16 байт или 24 байта.

6.2 Модуляция

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

- дифференциальная (относительная) двоичная фазовая манипуляция (DBPSK).

- двоичная частотная манипуляция (FSK).

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

6.3 Помехоустойчивое кодирование

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

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

Помехоустойчивое кодирование осуществляется для всего пакета канального уровня, который имеет размер 8 или 12 байт. Избыточность помехоустойчивого кода составляет 1/2, поэтому размер закодированного пакета составляет 16 или 24 байта.

Подробное описание используемого алгоритма помехоустойчивого кодирования представлено в приложении А.

7 Канальный уровень

7.1 Формат пакетов

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

Рисунок 3 - Формат пакетов

Примечание - В описании формата пакетов порядок следования битов и байтов - от старшего к младшему (big endian).

Пакет данных канального уровня имеет длину 8 байт или 12 байт в зависимости от длины передаваемых полезных данных. Протокол предусматривает два типа пакетов канального уровня:

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

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

Пакет данных канального уровня включает три поля:

- DevAddr;

- MACPayload;

- MIC.

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

- для служебных пакетов активации значение временного адреса устройства зависит только от идентификатора устройства DevID и вычисляется как DevAddr0=CRC24 (DevID). Описание функции расчета циклического избыточного кода CRC24 представлено в приложении Б;

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

Длина поля MACPayload составляет 2 байта или 6 байт.

Для пакетов полезных данных поле MACPayload содержит в себе информацию уровня приложений, передаваемую устройством на сервер. Эта информация зашифровывается на канальном уровне устройства и расшифровывается на сервере сети (см. раздел 8.2.4). Результат зашифрования поля MACPayload обозначается EncMACPayload. Внутренний формат этой информации выходит за рамки настоящего стандарта.

Поле имитовставки MIC (Message Integrity Code) имеет фиксированную длину 3 байта. Данное поле используется для проверки целостности и подлинности полей DevAddr и MACPayload. Значение поля MIC рассчитывается с помощью функции криптографического преобразования, описание которой представлено в разделе 8.2.5.

7.2 Адресация устройств

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

- DevID - постоянный идентификатор устройства, который хранится в памяти устройства и на сервере сети;

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

7.2.1 Идентификатор устройства DevID

Идентификатор устройства DevID записывается в энергонезависимую память устройства, а также хранится на сервере сети.

Идентификатор DevID должен иметь длину не менее 4 байт, а его формат может быть различным (например, в разных сетях может использоваться свой формат идентификаторов). Рекомендуется использовать идентификаторы DevID длиной не менее 128 бит.

7.2.2 Временный адрес устройства DevAddr

Временный адрес устройства DevAddr имеет фиксированную длину 3 байта.

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

- начальное значение временного адреса DevAddr0=CRC24 (DevID). Этот адрес передается только в служебных пакетах активации, которые отправляются при активации устройства для его аутентификации и регистрации на сервере сети;

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

7.3 Выбор частоты передачи пакета

Для обеспечения множественного доступа устройств к радиоканалу в сети используется неслотированная частотная ALOHA. Частота передачи каждого пакета должна выбираться устройством случайно из всей полосы рабочих частот приема шлюзов. В случае если передача пакета осуществляется с повторами (см. раздел 7.4), для каждой очередной передачи должна выбираться случайная частота, отличная от частот, выбранных для предыдущих передач пакета.

Примечания

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

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

7.4 Повторные передачи пакета

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

Передача служебных пакетов активации должна всегда осуществляться MAX_PKT_TX_NUM раз подряд.

Количество передач одного пакета полезных данных может быть от 1 до MAX_PKT_TX_NUM. Необходимость использования повторных передач для пакетов полезных данных определяется для каждого конечного устройства независимым образом.

8 Обеспечение информационной безопасности с использованием криптографических средств

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

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

Для каждого конечного устройства должны быть заданы:

- DevID - идентификатор устройства, определенный ранее в разделе 7.2.1;

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

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

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

8.2 Базовые криптографические алгоритмы и ключевая система

8.2.1 Используемый блочный шифр

Для криптографической защиты информации должен использоваться алгоритм блочного шифрования с длиной блока 64 бит и длиной ключа 256 бит, регламентируемый ГОСТ Р 34.12.

8.2.2 Ключевая система

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

8.2.3 Формирование временного адреса DevAddr

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

8.2.4 Шифрование данных

Шифрование содержащихся в поле MACPayload пакета данных канального уровня осуществляется по формуле

Расшифрование содержащихся в поле EncMACPayload пакета данных канального уровня осуществляется по формуле

8.2.5 Имитозащита данных

Имитозащита данных, содержащихся в полях DevAddr и EncMACPayload, обеспечивается с использованием имитовставки. Имитовставка вырабатывается по формуле

8.3 Активация устройства

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

Процедура активации конечного устройства состоит из следующих шагов:

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

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

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

Отправку сообщения об активации следует выполнять в следующих случаях:

- при первом подключении конечного устройства к источнику питания;

- при восстановлении конечного устройства после технических неполадок;

- при исчерпании счетчика эпох;

- при смене ключевой информации.

Алгоритм отправки сообщения об активации реализуется на канальном уровне.

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

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

8.4 Отправка пакетов данных конечным устройством

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

1) определяется номер текущей минуты от момента активации устройства:

t_min = целое количество минут от (t-t_act),

где t - текущее время по часам устройства;

t_act - время активации устройства по часам устройства;

2) определяется номер текущей эпохи:

n_e = целая часть от деления t_min на EPOCH_DURATION;

3) если номер текущей эпохи n_e больше номера эпохи, в которой был передан предыдущий пакет данных, то:

- формируется новый временный адрес устройства DevAddr;

где cur_min - номер текущей минуты в рамках текущей эпохи

cur_min=остаток от деления t_min на EPOCH_DURATION;

5) поле MACPayload пакета зашифровывается;

6) для пакета вырабатывается имитовставка MIC;

7) процедура формирования пакета успешно завершается.

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

8.5 Прием пакетов сервером сети

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

- dev_id - идентификатор устройства DevID, определенный в разделе 7.2.1;

- t_act - время активации устройства по часам сервера;

- n_a - текущий номер активации устройства;

- k_a - текущий ключ активации устройства;

- n_e - текущий номер эпохи на устройстве;

- dev_addr - временный адрес устройства для эпохи n_e;

- k_e - сессионный ключ шифрования для эпохи n_e;

- k_m - сессионный ключ имитозащиты для эпохи n_e;

- received_pkt_list - список номеров успешно принятых пакетов в эпохе n_e.

Примечания

1 В общем случае, протокол OpenUNB допускает возможность неверного определения сервером номера текущей эпохи n_e конечного устройства:

- вследствие рассинхронизации времени сервера и конечного устройства;

- вследствие задержки пакетов в канале "шлюз - сервер сети".

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

2 Допускается компенсация расхождения часов конечного устройства и сервера посредством дополнительной поправки для значения времени t_act, хранимой сервером для каждого конечного устройства. Алгоритм расчета значения дополнительной поправки настоящим стандартом не регламентируется. Пример реализации такого алгоритма представлен в приложении В.

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

1) на вход процедуры подаются следующие значения:

- pkt_dev_addr - адрес пакета,

- pkt_mac_payload - данные пакета,

- pkt_mic - код целостности пакета,

- t - время приема пакета;

2) осуществляется поиск устройств, для которых временный адрес dev_addr_0 или dev_addr совпадает с адресом pkt_dev_addr;

3) если на шаге 2 данной процедуры найдено хотя бы одно устройство, для которого dev_addr_0 совпадает с pkt_dev_addr, то принятый пакет обрабатывается как пакет активации. Для каждого найденного устройства выполняется процедура:

- вычисляются временные значения ключей активации tmp_k_a, шифрования tmp_k_e и имитозащиты tmp_k_m, соответствующие номеру активации pkt_mac_payload и номеру эпохи 0;

- с использованием ключа tmp_k_m проверяется корректность значения имитовставки pkt_mic принятого пакета:

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

в противном случае устройство считается успешно активированным и сервер сохраняет время активации (t_act = t), номер активации (n_a = pkt_mac_payload), номер эпохи (n_e = 0) и значения ключей (k_a = tmp_k_a, k_e = tmp_k_e и k_m = tmp_k_m), а также вычисляет временный адрес устройства dev_addr;

4) если на шаге 2 данной процедуры найдено хотя бы одно устройство, для которого dev_addr совпадает с pkt_dev_addr, то принятый пакет обрабатывается как пакет данных. Для каждого найденного устройства выполняется процедура:

- определяется интервал возможных значений номера n принятого пакета:

а значения переменных prev_n и next_n должны удовлетворять следующим требованиям:

- с использованием ключа k_m проверяется корректность значения имитовставки pkt_mic принятого пакета. При этом проверка имитовставки осуществляется для всего диапазона номеров n, определенного на предыдущем шаге, за исключением номеров, которые содержатся в списке received_pkt_list.

Если для какого-то номера n имитовставка сходится, то пакет расшифровывается на ключе k_e, а номер n добавляется в список received_pkt_list;

иначе осуществляется переход к следующему найденному устройству.

Примечание - Точный алгоритм определения сервером значений переменных prev_n и next_n настоящим стандартом не регламентируется, однако его реализация должна учитывать возможное расхождение времени на конечном устройстве и сервере сети. В приложении В представлен один из возможных примеров реализации такого алгоритма.

8.6 Таблица параметров

Параметры протокола OpenUNB приведены в таблице 1.

Таблица 1

Приложение А

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

Помехоустойчивое кодирование

А.1 Общее описание

На физическом уровне протокола осуществляется помехоустойчивое кодирование пакетов с помощью полярного кода.

Помехоустойчивое кодирование осуществляется для всего пакета канального уровня, который включает в себя поля DevAddr, MACPayload и MIC. Таким образом размер посылки для помехоустойчивого кода может равняться K=64 или 96 бит (в зависимости от размера поля MACPayload).

Избыточность помехоустойчивого кода составляет 1/2, поэтому размер закодированного пакета может равняться N=128 или 192 бита.

Кодирование передаваемых пакетов осуществляется на конечном устройстве. Описание процедуры кодирования представлено в разделе А.2.

Декодирование принимаемых пакетов осуществляется на шлюзе. Описание процедуры кодирования представлено в разделе А.3.

А.2 Кодирование

Перед непосредственным применением полярного кода для кодирования передаваемого пакета к нему необходимо применить циклический избыточный код длины 10 бит, задаваемый в виде 0x327. Данная операция осуществляется путем деления многочлена, коэффициенты которого соответствуют двоичному представлению передаваемого пакета, на многочлен 0x327. Двоичные коэффициенты, полученные в остатке данного деления, приписываются справа к передаваемому пакету (младшие 10 бит). Полученная таким образом последовательность (длиной 74 бита для K=64 или 106 бит для K=96) подается на вход кодера полярного кода и рассматривается как информационная последовательность для него.

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

2) Позиции строки cwd, обозначенные в конфигурационном файле для данной длины символом 1, последовательно заменяют символами информационной последовательности. В случае K=96 к символам информационной последовательности дополнительно добавляются 64 нуля справа (младшие биты) и для полученных 170 символов осуществляется аналогичная процедура;

3) Позиции строки u, обозначенные в конфигурационном файле для данной длины символом 0, принимаются равными 0;

А.3 Декодирование

Для декодирования рекомендуется использовать списочный алгоритм декодирования Тала-Варди на основе логарифмов отношения правдоподобия, описанный в [2]. При этом предполагается, что на вход декодера поступает строка, содержащая логарифмы отношений правдоподобия для каждого из символов принятой последовательности. Также входом декодера является длина кода N, конфигурационный файл для нее и максимальная длина используемого списка L.

Примечание - Значение L должно равняться степени двойки. Рекомендуемое значение L=16, что обосновано балансом между вычислительной сложностью и корректирующей способностью кода. Если позволяют вычислительные ресурсы, то может быть использовано большее значение L (например, 32 или 64).

Из всех оставшихся в списке кодовых векторов в качестве передаваемого выбирают тот, в котором метрика пути в алгоритме Тала-Варди минимальна.

В качестве передаваемой информации выбираем первые K бит, соответствующие символу 1 в конфигурационном файле.

А.4 Конфигурационные файлы

Конфигурационные файлы для полярного кода приведены в таблице А.1.

Таблица А.1

Примечания

1 Отметим, что здесь и далее перевод двоичных векторов в шестнадцатеричные осуществляется таким образом, что первый элемент двоичного вектора является наиболее значимым. Например, вектор 00111101 переводится в 0x3D.

А.5 Тестовые последовательности

Тестовые последовательности приведены в таблице А.2.

Таблица А.2

Приложение Б

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

Функция вычисления CRC24

CRC24 - циклический избыточный код длиной 24 бита, использующий полином 0x5D6DCB, начальное заполнение 0xFFFFFF и XOR выхода: 0xFFFFFF.

Далее представлен пример исходного кода, реализующего функцию вычисления CRC24:

#define CRC24_INIT 0xFFFFFFUL

#define CRC24_POLY 0x5D6DCBUL

#define CRC24_XOR_OUT 0xFFFFFFUL

uint32_t crc24(unsigned char* octets, size_t len)

{

uint32_t crc=CRC24_INIT;

int i;

while (len--) {

crc ^=(*octets++) << 16;

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

crc <<= 1;

if (crc & 0x1000000)

crc ^=CRC24_POLY;

}

}

return (crc & 0xFFFFFFL) ^ CRC24_XOR_OUT;

}

Контрольные примеры расчета CRC24 представлены в таблице Б.1.

Таблица Б.1

Приложение В

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

Примеры алгоритмов отправки и приема пакетов

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

В.1 Отправка пакетов данных конечным устройством

Конечное устройство хранит следующие переменные:

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

1) определяется номер текущей минуты от момента активации устройства:

t_min = целое количество минут от (t - t_act),

где t - текущее время по часам устройства,

t_act - время активации устройства по часам устройства;

2) определяется номер текущей эпохи

n_e = целая часть от деления t_min на EPOCH_DURATION;

3) если n_e>last_n_e, то:

- формируется новый временный адрес устройства DevAddr;

4) для пакета определяется номер n_n с помощью следующей последовательности шагов:

- определяется номер текущей минуты в рамках текущей эпохи

cur_min = остаток от деления t_min на EPOCH_DURATION;

- если n_e > last_n_e, то n_n = cur_min;

- иначе если n_e == last_n_e, то:

если last_n_n<cur_min, то n_n=cur_min;

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

5) last_n_n = n_n;

6) last_n_e = n_e;

7) поле MACPayload пакета зашифровывается;

8) для пакета вырабатывается имитовставка MIC;

9) алгоритм формирования пакета успешно завершается.

В.2 Прием пакетов данных сервером сети

В.2.1 Информация об активированных устройствах, хранимая на сервере сети

Сервер должен хранить список временных адресов DevAddr всех успешно активированных конечных устройств в сети.

Так как каждое конечное устройство вырабатывает новый временный адрес DevAddr для каждой эпохи, сервер также должен периодически обновлять адреса DevAddr всех активированных конечных устройств. Кроме того, так как между часами сервера и конечного устройства может быть ошибка синхронизации, то для каждого конечного устройства на границе двух его эпох сервер должен хранить сразу два адреса DevAddr (dev_addr_1 и dev_addr_2). Например:

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

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

Так как используемая схема вычисления временных адресов DevAddr не гарантирует их уникальность, на сервере допустимо появление одинаковых адресов DevAddr для различных конечных устройств. Разрешение возможных коллизий временных адресов разных конечных устройств осуществляется на сервере сети при расшифровании принятых пакетов на этапе проверки имитовставки MIC (см. раздел В.2.3).

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

- dev_id - идентификатор устройства DevID;

- t_act - время активации конечного устройства по часам сервера;

- d_t - поправка времени, компенсирующая расхождение часов сервера и конечного устройства;

- n_a - текущий номер активации устройства;

- k_a - текущий ключ активации устройства;

- last_pkt_rx_time - время приема последнего пакета от устройства;

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

- n_e_2 - второй номер эпохи, в рамках которой сервер ожидает получения пакетов от данного конечного устройства. Значение n_e_2=n_e_1+1;

- dev_addr_1 - временный адрес устройства для эпохи n_e_1;

- dev_addr_2 - временный адрес устройства для эпохи n_e_2;

- k_e_1 - сессионный ключ шифрования для эпохи n_e_1;

- k_e_2 - сессионный ключ шифрования для эпохи n_e_2;

- k_m_1 - сессионный ключ имитозащиты для эпохи n_e_1;

- k_m_2 - сессионный ключ имитозащиты для эпохи n_e_2;

- received_pkt_list_1 - список номеров успешно принятых пакетов в эпохе n_e_1;

- received_pkt_list_2 - список номеров успешно принятых пакетов в эпохе n_e_2.

В.2.2 Алгоритм пересчета адресов и ключей для активированных устройств

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

Один раз за время, равное EPOCH_DURATION/2, сервер для каждого успешно активированного конечного устройства выполняет следующие действия (здесь t - текущее время по часам сервера):

- n_e_1 = n_e_2;

- n_e_2 = n_e_2+1;

- dev_addr_1 = dev_addr_2;

- dev_addr_2 равняется новому временному адресу DevAddr, вычисленному для эпохи с номером n_e_2;

- k_e_1 = k_e_2;

- k_e_2 равняется новому сессионному ключу шифрования, вычисленному для эпохи с номером n_e_2;

- k_m_1 = k_m_2;

- k_m_2 = равняется новому сессионному ключу имитозащиты, вычисленному для эпохи с номером n_e_2;

- received_pkt_list_1 = received_pkt_list_2;

- received_pkt_list_2 равняется пустому списку.

Примечание - В случае использования данного алгоритма для каждого конечного устройства сервер всегда хранит два временных адреса DevAddr. При этом в интервале времени от 1/4 от начала текущей эпохи до 3/4 от начала текущей эпохи сервер удаляет всю информацию о предыдущей эпохе и добавляет информацию о следующей эпохе. Данный алгоритм может быть оптимизирован. Например, можно сделать так, чтобы сервер хранил два временных адреса для конечного устройства только в пределах некоторого малого интервала на границе смены эпох, а в остальное время хранил только один временный адрес. Это уменьшит общее количество временных адресов конечных устройств, хранимое на сервере, и ускорит поиск конечного устройства-отправителя для принятого пакета. Однако в таком случае на сервере вырастет вычислительная нагрузка, вызванная необходимостью более частого поиска конечных устройств, для которых требуется обновить хранимые временные адреса.

В.2.3 Алгоритм обработки принятого пакета данных

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

1) на вход процедуры подаются следующие значения:

- pkt_dev_addr - адрес пакета,

- pkt_mac_payload - данные пакета,

- pkt_mic - код целостности пакета,

- t - время приема пакета по часам шлюза,

2) в списке активированных конечных устройств осуществляется поиск устройств, для которых временный адрес (dev_addr_1 или dev_addr_2) совпадает с адресом принятого пакета pkt_dev_addr;

3) если на шаге 2 алгоритма устройств не найдено, то алгоритм завершается;

4) для каждого конечного устройства, найденного на шаге 2 алгоритма, выполняется процедура:

- в зависимости от того, какой из временных адресов устройства (dev_addr_1 или dev_addr_2) совпал с pkt_ dev_addr на шаге 2 алгоритма, для устройства определяется номер эпохи, сессионные ключи и список успешно принятых пакетов:

- если pkt_dev_addr == dev_addr_1, то:

n_e = n_e_1;

k_e = k_e_1;

k_m = k_m_1;

received_pkt_list = received_pkt_list_1;

- если pkt_dev_addr == dev_addr_2, то:

n_e = n_e_2;

k_e = k_e_2;

k_m = k_m_2;

received_pkt_list = received_pkt_list_2;

- определяется интервал возможных значений номера n принятого пакета:

где:

- prev_n = next_n=2+rx_window,

- rx_window - размер окна поиска номера пакета, который определяется сервером исходя из возможной рассинхронизации часов сервера и устройства (см. раздел В.2.4):

При этом если значения prev_n и next_n превышают предельно допустимые значения MAX_PREV_N и MAX_NEXT_N, то работа данного конечного устройства должна быть заблокирована на сервере (оно считается неисправным, и должна быть проведена либо его повторная активация, либо замена) и осуществляется переход к следующему найденному устройству;

- с использованием ключа k_m проверяется корректность значения имитовставки pkt_mic принятого пакета. При этом проверка имитовставки осуществляется для номеров n из диапазона, определенного на предыдущем шаге, за исключением номеров, которые содержатся в списке received_pkt_list;

5) если на шаге 4 алгоритма имитовставка совпала сразу для нескольких устройств или не совпала ни для одного из устройств, то принятый пакет должен быть отброшен, и алгоритм завершается;

6) иначе если на шаге 4 алгоритма для одного из устройств совпала имитовставка для некоторого номера n, то обрабатываемый пакет считается принятым от этого устройства, и выполняются следующие действия:

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

- номер n добавляется в список received_pkt_list,

- обновляется значение last_pkt_rx_time = t,

- при необходимости обновляется значение d_t:

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

В.2.4 Синхронизация часов сервера на часы конечного устройства

Однако синхронизация часов сервера и конечного устройства осуществляется с ошибкой, значение которой включает в себя следующие составляющие:

- ошибка синхронизации часов сервера и шлюзов. Время приема всех пакетов определяется на шлюзах сети. Часы шлюзов и сервера должны быть засинхронизированы на абсолютное время, например по протоколу NTP или по сигналу от ГНСС (GPS/ГЛОНАСС). Предполагается, что ошибка синхронизации часов шлюзов и сервера не превышает одной секунды и поэтому ею можно пренебречь;

- ошибка начальной синхронизации сервера и устройства. Начальная синхронизация сервера с конечным устройством осуществляется по времени получения от него служебного пакета активации. Однако так как передача служебного пакета активации осуществляется MAX_PKT_TX_NUM раз подряд, а сервер не имеет возможности определить, какой именно из этих пакетов был принят, то ошибка начальной синхронизации времени между сервером и конечным устройством не превышает 15 секунд (каждый пакет может быть передан не более MAX_PKT_ TX_NUM = 6 раз подряд, а передача одного пакета длится 1,6 или 2,24 секунды для пакета длиной 20 и 28 байт соответственно);

Приложение Г

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

Контрольные примеры

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

Г.1 Служебные пакеты активации

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

Таблица Г.1

Г.2 Пакеты полезных данных

Контрольные примеры формирования пакетов полезных данных приведены в таблице Г.2.

Таблица Г.2

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