ГОСТ Р 71168-2023. Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Спецификация LoRaWAN RU

6.4 Активация оконечного устройства

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

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

6.4.1 Данные об активации, сохраняемые в устройстве

6.4.1.1 Перед активацией

а) JoinEUI

JoinEUI является глобальным идентификатором приложения в [1] EUI64 адресного пространства, который однозначно идентифицируется сервером присоединения к сети (Join-Server), который обеспечивает выполнение процедуры присоединения к сети и производства сеансовых ключей.

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

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

б) DevEUI

DevEUI - это глобальный идентификатор оконечного устройства в [1] EUI64 адресном пространстве, который однозначно идентифицирует оконечное устройство.

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

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

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

Примечание - Рекомендуется использовать DevEUI также в качестве этикетки устройства (номенклатурного номера) и для управления устройством (учета и сопровождения).

в) Первичные ключи устройства (AppKey и NwkKey)

Ключи NwkKey и AppKey являются первичными ключами, индивидуальными для одного экземпляра оконечного устройства. Ключи NwkKey и AppKey назначаются оконечному устройству при его производстве. В ходе процедуры присоединения оконечного устройства к сети методом активации по воздуху NwkKey используется для получения сеансовых ключей FNwkSIntKey, SNwkSIntKey, NwkSEncKey (LoRaWAN v.1.1) и NwkSkey (LoRaWAN v.1.0); и AppKey используется для получения сеансового ключа AppSKey.

Примечание - При работе с сетевым сервером LoRaWAN v.1.1 для получения сеансового ключа приложения используется только AppKey, поэтому NwkKey может быть использован в сети для управления процедурой присоединения без возможности оператора сети раскодировать данные приложений.

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

Для обеспечения обратной совместимости с LoRaWAN v.1.0 и более ранних версий сетевых серверов, которые не поддерживают два первичных ключа, оконечные устройства по умолчанию должны быть настроены на использование при присоединении к сети схемы с одним первичным ключом. Признаком такого состояния оконечного устройства является установленный в ноль бит N 7 "OptNeg" в поле DLsetting в сообщении Join-Accept.

Устройство в этом случае должно:

- использовать NwkKey для получения сеансовых ключей AppSKey и FNwkSIntKey, как указано в спецификации LoRaWAN v.1.0;

- установить SNwkSIntKey и NwkSEncKey равными FNwkSIntKey. Один и тот же сетевой сеансовый ключ используется для расчета MIC восходящих и нисходящих сообщений и кодирования кадров данных (MACPayload) в соответствии со спецификацией LoRaWAN v.1.0.

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

NwkKey не требуется оконечным устройствам, поддерживающим только процедуру ABP.

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

AppKey не требуется оконечным устройствам, поддерживающим только процедуру ABP.

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

Примечание - Поскольку все оконечные устройства оснащены уникальными для каждого оконечного устройства первичными ключами AppKey и NwkKey, то в случае извлечения AppKey/NwkKey из оконечного устройства компрометируется только это одно оконечное устройство.

г) Формирование JSIntKey и JSEncKey

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

- JSIntKey используется для формирования MIC в сообщении с запросом Rejoin-Request первого типа и ответа Join-Accept;

- JSEncKey используется для кодирования Join-Accept, сформированного в ответ на запрос Rejoin-Request.

Рекомендуется использовать алгоритм блочного шифрования. Описание и выбор конкретных алгоритмов шифрования данных выходят за рамки настоящего стандарта.

Для вычисления JSIntKey с помощью ключа NwkKey кодированию подлежит сообщение:

message = 0x06 || DevEUI || Pad₁₆.

Для вычисления JSEncKey с помощью ключа NwkKey кодированию подлежит сообщение:

message = 0x05 || DevEUI || Pad₁₆.

6.4.1.2 После активации

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

- короткий адрес оконечного устройства (DevAddr);

- три сетевых сеансовых ключа (NwkSEncKey/SNwkSIntKey/FNwkSIntKey);

- сеансовый ключ приложения (AppSKey).

а) Короткий адрес оконечного устройства (DevAddr)

DevAddr состоит из 32 битов, идентифицирующих оконечное устройство в текущей (существующей) сети. Структура DevAddr приведена на рисунке 52.

Биты	От 31 до 32-N	От 31-N до 0
DevAddr	AddrPrefix	NwkAddr

Рисунок 52 - Структура DevAddr

N - целое число в диапазоне [7:24].

Протокол LoRaWAN RU поддерживает различные типы сетевых адресов с разным размером адресного пространства. Переменный размер поля AddrPrefix является производным от уникального идентификатора сервера сети NetID (см. 6.4.2.3), за исключением значений AddrPrefix, зарезервированных для экспериментальных/частных сетей. Поле AddrPrefix позволяет сетевым серверам обнаруживать и в реальном времени управлять устройствами в роуминге. Устройства, которые не соблюдают это правило, не смогут переподключаться между двумя сетями, т.к. будет невозможно найти их домашний сетевой сервер.

Младшие (32-N) биты DevAddr - это сетевой адрес оконечного устройства (NwkAddr), который может назначаться по усмотрению администратора сети.

Значения AddrPrefix, указанные на рисунке 53, могут быть использованы любой частной/экспериментальной сетью и не будут взаимодействовать в роуминге.

AddrPrefix, зарезервированные для частных/экспериментальных сетей

N = 7

AddrPrefix = 7'b0000000 или AddrPrefix = 7'b0000001

NwkAddr - это 25 бит, назначаются по усмотрению администратора сети

Рисунок 53 - Значения AddrPrefix

б) Сетевой сеансовый ключ целостности восходящих сообщений (FNwkSIntKey)

FNwkSIntKey (forwarding network session integrity key) - это сетевой сеансовый ключ, определенный для оконечного устройства. Он используется оконечным устройством для вычисления MIC или части MIC всех восходящих сообщений с данными для обеспечения их целостности.

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

в) Сетевой сеансовый ключ целостности нисходящих сообщений (SNwkSIntKey)

SNwkSIntKey (serving network session integrity key) - это сетевой сеансовый ключ, определенный для оконечного устройства. Он используется оконечным устройством для проверки MIC всех нисходящих сообщений с данными для обеспечения целостности данных и вычисления половины MIC восходящих сообщений.

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

Когда устройство подключается к сети LoRaWAN 1.0, сетевой сервер использует один и тот же ключ для расчета MIC как восходящих, так и нисходящих сообщений, в этом случае SNwkSIntKey принимает значение, совпадающее с FNwkSIntKey.

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

г) Сетевой сеансовый ключ кодирования (NwkSEncKey)

NwkSEncKey (network session encryption key) - это сетевой сеансовый ключ, определенный для оконечного устройства. Он используется для кодирования и раскодирования восходящих и нисходящих MAC-команд, передаваемых в поле прикладных данных FRMPayload на порт 0 или в поле FOpt. Когда устройство подключается к сети LoRaWAN 1.0, сервер использует один и тот же ключ для кодирования MAC-сообщения (MACPayload) и расчета MIC. В этом случае NwkSEncKey принимает значение, совпадающее с FNwkSIntKey.

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

д) Сеансовый ключ приложения (AppSKey)

AppSKey (application session key) - это сеансовый ключ приложения, определенный для оконечного устройства. Он используется сервером приложений и оконечным устройством для кодирования и декодирования поля прикладных данных (FRMPayload) в информационных сообщениях при условии значения поля FPort от 1 до 224. AppSKey должен храниться таким образом, чтобы предотвратить извлечение и повторное использование злоумышленниками.

е) Контекст сеанса связи

Контекст сеанса связи включает параметры сетевого сеанса и параметры сеанса приложения.

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

- FNwkSIntKey/SNwkSIntKey - сетевые сеансовые ключи целостности;

- NwkSEncKey - сетевой сеансовый ключ кодирования;

- FCntUp - счетчик восходящих по сети кадров;

- FCntDown (LoRaWAN 1.0) и NFCntDown (LoRaWAN 1.1) - счетчики нисходящих по сети кадров;

- DevAddr - адрес оконечного устройства.

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

- AppSKey - сеансовый ключ приложения;

- FCntUp - счетчик восходящих кадров;

- FCntDown (LoRaWAN 1.0) и AFCntDown (LoRaWAN 1.1) - счетчики нисходящих кадров.

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

По окончании процедуры авторизации OTAA или ABP устанавливается новый безопасный сеанс связи между сервером сети (или сервером приложений) и оконечным устройством. Ключи и адрес оконечного устройства являются фиксированными в течение всего срока сеанса связи (FNwkSIntKey, SNwkSIntKey, AppSKey, DevAddr). Счетчики кадров увеличиваются по факту обмена пакетами в течение сеанса связи (FCntUp, FCntDown, NFCntDown, AFCntDown).

Для устройств OTAA счетчики кадров не должны повторно использоваться при одних и тех же сеансовых ключах, поэтому новый сеанс должен быть установлен до момента переполнения счетчиков кадров. Таким образом, количество отправленных сообщений с одними и теми же сеансовыми ключами не может превышать 4 294 967 295 сообщений.

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

6.4.2 Активация по воздуху (OTAA)

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

Прежде чем начнется процедура присоединения к сети, необходимо, чтобы оконечное устройство было персонализировано следующей информацией: DevEUI, JoinEUI, NwkKey и AppKey.

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

6.4.2.1 Процедура присоединения к сети

Со стороны оконечного устройства процедура присоединения к сети представляет собой отправку оконечным устройством запроса на присоединение к сети (Join-Request) или повторное присоединение к сети (Rejoin-Request) и получение подтверждения присоединения (переприсоединения) к сети (Join-Accept).

6.4.2.2 Сообщение с запросом на присоединение к сети (Join-Request)

Процедура присоединения всегда инициируется оконечным устройством путем отправки сообщения с запросом на присоединение. Структура сообщения приведена на рисунке 54.

Размер (в байтах)	8	8	2
Запрос на присоединение к сети	JoinEUI	DevEUI	DevNonce

Рисунок 54 - Структура сообщения

с запросом на присоединение к сети

Сообщение с запросом на присоединение к сети содержит JoinEUI и DevEUI оконечного устройства с последующим полем случайного значения из 2 байтов (DevNonce).

DevNonce - идентификатор запросов на присоединение, должен быть случайным числом (для обратной совместимости со спецификациями LoRaWAN v.1.0.x) или счетчиком (для обратной совместимости со спецификацией LoRaWAN v.1.1).

Если DevNonce - это счетчик, то его значение начинается с 0, когда устройство изначально включается и увеличивается с каждым JoinRequest. Значение DevNonce никогда не должно использоваться повторно для заданного значения JoinEUI. Если оконечное устройство может быть выключено и включено, то DevNonce не должен изменяться (должен сохраняться в энергонезависимой памяти). Сброс DevNonce без изменения JoinEUI вызовет отклонение сетевым сервером запроса устройства на присоединение к сети. Для каждого оконечного устройства сетевой сервер отслеживает значения DevNonce, использованные оконечным устройством, и игнорирует запросы на присоединение к сети, если DevNonce не изменился (не увеличился). Когда счетчик DevNonce переполняется (предыдущее значение счетчика равно 16 777 215), эксплуатация оконечного устройства завершается.

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

Значение MIC для сообщения с запросом на присоединение рассчитывается с помощью первичного сеансового ключа оконечного устройства - NwkKey.

Кодированию с помощью ключа первичного сеансового ключа оконечного устройства (NwkKey) подлежит сообщение:

message = MHDR || JoinEUI || DevEUI || DevNonce.

Сообщение с запросом на присоединение к сети не кодируется и может передаваться на любой скорости передачи данных и частоте, случайным образом выбранной из возможных для присоединения каналов. Рекомендуется использовать различные скорости передачи данных. Интервалы между передачами запросов на присоединение должны соблюдать условия, описанные в 6.5. Для каждой следующей передачи запроса на подключение устройство должно увеличить значение DevNonce.

6.4.2.3 Сообщение с подтверждением присоединения (переприсоединения) к сети (Join-Accept)

Сетевой сервер отвечает на сообщение с запросом на присоединение (или повторное присоединение) сообщением с подтверждением присоединения (переприсоединения) к сети, если оконечному устройству разрешено присоединение к сети. Сообщение с подтверждением соединения отправляется как обычное нисходящее сообщение, но использует задержки JOIN_ACCEPT_DELAY1 или JOIN_ACCEPT_DELAY2 (вместо RECEIVE_DELAY1 и RECEIVE_DELAY2 соответственно). Частота канала и скорость передачи данных, используемых для получения этих двух окон приема, идентичны тем, которые используются для окон приема RX1 и RX2.

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

Сообщение с присоединением (переприсоединением) к сети содержит поле случайного значения (JoinNonce) из 3 байтов, сетевой идентификатор (NetID), адрес оконечного устройства (DevAddr), поле с параметрами нисходящей линии связи (DLSettings), задержку между TX и RX (RxDelay) и дополнительный список сетевых параметров (CFList & CFListType) для сети, к которой присоединилось оконечное устройство (см. рисунок 55). Дополнительные поля CFList & CFListType являются региональными настройками и определены в разделе 9.

Размер (в байтах)	3	3	4	1	1	15	1
Подтверждение присоединения (переприсоединения) к сети	JoinNonce	Home_NetID	DevAddr	DLSettings	RxDelay	CFList	CFListType

Рисунок 55 - Структура сообщения с подтверждением

присоединения (переприсоединения) к сети

JoinNonce содержит значение счетчика повторных присоединений для конкретного устройства (значения счетчика никогда не повторяются), предоставленное сервером присоединения (Join-Server) и используемое оконечным устройством для получения сеансовых ключей FNwkSIntKey, SNwkSIntKey, NwkSEncKey и AppSKey. JoinNonce увеличивается с каждым сообщением с подтверждением присоединения (переприсоединения) (Join-Accept).

Устройство отслеживает значение JoinNonce, использованное в последнем успешно обработанном Join-Accept (соответствует последней успешной генерации ключей). Устройство принимает Join-Accept, только если в поле MIC корректное значение и JoinNonce строго больше, чем записанное ранее. В этом случае новое значение JoinNonce заменяет ранее сохраненное.

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

Уникальный идентификатор сети (NetID) составляет 24 бита, за исключением следующих значений NetID, отведенных для экспериментальных/частных сетей, управление которыми не осуществляется.

Выделяется 2¹⁵ зарезервированных значений NetID для частных/экспериментальных сетей, формируемых согласно рисунку 56.

Биты	23:21	20:7	6:0
Значение	000	XXXXXXXXXXXXXX Произвольное 14-битное значение	0000000 или 0000001

Рисунок 56 - Формирование значений NetID

для частных/экспериментальных сетей

Поле Home_NetID в Join-Accept соответствует NetID домашней сети устройства.

Сеть, которая присваивает DevAddr, и домашняя сеть могут быть разными в состоянии роуминга.

Поле "Параметры нисходящей линии связи" (DLsettings) содержит конфигурацию нисходящей линии связи согласно рисунку 57.

Биты	7	6:4	3:0
DLsettings	OptNeg	RX1DRoffset	RX2 Data rate

Рисунок 57 - Структура поля DLsettings

Бит OptNeg указывает, какую версию протокола реализует сетевой сервер: LoRaWAN v.1.0 (бит не установлен), v.1.1 и выше (бит установлен).

Когда бит OptNeg установлен, то:

- будет использоваться протокол версии LoRaWAN v.1.1 (или более поздний), соглашение между оконечным устройством и сетевым сервером осуществляется через обмен MAC-командами RekeyInd/RekeyConf;

- устройство вычисляет FNwkSIntKey & SNwkSIntKey & NwkSEncKey из NwkKey;

- устройство вычисляет AppSKey из AppKey.

Когда бит OptNeg не установлен, то:

- устройство использует LoRaWAN v.1.0;

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

- устройство вычисляет FNwkSIntKey и AppSKey из NwkKey;

- устройство устанавливает значения ключей SNwkSIntKey и NwkSEncKey эквивалентными FNwkSIntKey.

Четыре сеансовых ключа FNwkSIntKey, SNwkSIntKey, NwkSEncKey и AppSKey формируются следующим образом.

Если OptNeg не установлен, то сеансовые ключи рассчитываются из NwkKey.

Сеансовый ключ приложения AppSKey рассчитывается с помощью первичного сеансового ключа NwkKey и сообщения:

message = 0x02 || JoinNonce || NetID || DevNonce || Pad₁₆.

Функция Pad₁₆ добавляет нулевой байт таким образом, чтобы длина данных стала кратной 16.

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

Сетевой сеансовый ключ целостности восходящих сообщений FNwkSIntKey рассчитывается с помощью первичного сеансового ключа NwkKey и сообщения:

message = 0x01 || JoinNonce || NetID || DevNonce || Pad₁₆

SNwkSIntKey = NwkSEncKey = FNwkSIntKey.

Значение MIC для сообщения подтверждения присоединения рассчитывается с помощью первичного сеансового ключа NwkKey и сообщения:

message = MHDR || JoinNonce || NetID || DevAddr ||

DLSettings || RxDelay || CFList || CFListType.

Используются младшие 4 байта полученного значения.

Если OptNeg установлен, то AppSKey рассчитывается из AppKey следующим образом.

Сеансовый ключ приложения AppSKey рассчитывается с помощью прикладного первичного ключа AppKey и сообщения:

message = 0x02 || JoinNonce || JoinEUI || DevNonce || Pad₁₆.

Сетевой сеансовый ключ FNwkSIntKey рассчитывается из NwkKey и сообщения:

message = 0x01 || JoinNonce || JoinEUI || DevNonce || Pad₁₆.

Сетевой сеансовый ключ SNwkSIntKey рассчитывается из NwkKey и сообщения:

message = 0x03 || JoinNonce || JoinEUI || DevNonce || Pad₁₆.

Сетевой сеансовый ключ NwkSEncKey рассчитывается из NwkKey и сообщения:

message = 0x04 || JoinNonce || JoinEUI || DevNonce || Pad₁₆.

В этом случае значение MIC для сообщения подтверждения присоединения рассчитывается с помощью JSIntKey (ключ целостности восходящего сообщения с запросом Rejoin-Request первого типа и нисходящего сообщения ответа Join-Accept) и сообщения:

message = JoinEUI || DevNonce || MHDR || JoinNonce ||

NetID || DevAddr || DLSettings || RxDelay ||

CFList || CFListType.

Используются младшие 4 байта полученного значения.

JoinReqType представляет собой одно байтовое поле для кодирования типа запроса на присоединение (JoinRequest или RejoinRequest), инициировавшего ответ Join-Accept (таблица 16).

Таблица 16

Кодирование JoinReqType

Тип JoinReqType	Значение JoinReqType
JoinRequest	0xFF
RejoinRequest type 0	0x00
RejoinRequest type 1	0x01
RejoinRequest type 2	0x02

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

Таблица 17

Значение ключа кодирования Join-Accept

Тип запроса	Ключ кодирования Join-Accept
JoinRequest	NwkKey
RejoinRequest type = 0 или 1 или 2	JSEncKey

Сообщение с подтверждением присоединения (переприсоединения) к сети (Join-Accept) кодируется с помощью ключа NwkKey (или JSEncKey) и сообщения:

message = JoinNonce || NetID || DevAddr || DLSettings ||

RxDelay || CFList || CFListType || MIC.

Длина сообщения 16 или 32 байта.

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

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

Задержка RxDelay следует тому же соглашению, что и поле Delay в команде RXTimingSetupReq.

Поля CFlist и CFlistType являются необязательными, но должны либо оба присутствовать, либо оба отсутствовать.

Если сообщение с подтверждением присоединения (переприсоединения) к сети (Join-Accept) получено после передачи:

- запроса на присоединение (или запроса на повторное присоединение типа 0 или 1) и если поле CFlist отсутствует, то устройство переходит на частотные каналы по умолчанию. Если CFlist присутствует, то он переопределяет все ранее заданные каналы. Параметры MAC-уровня (RXdelay1, скорость передачи данных RX2, ...) должны быть сброшены в значения по умолчанию;

- запроса на повторное присоединение типа 2 и если поле CFlist отсутствует, то устройство должно сохранить свои текущие частотные каналы без изменений. Если CFlist присутствует, то он переопределяет все определенные ранее каналы. Все остальные параметры MAC-уровня (за исключением счетчиков кадров, которые сбрасываются) остаются без изменения.

Во всех случаях после успешной обработки сообщения Join-Accept устройство передает MAC-команду RekeyInd, пока не получит команду RekeyConf (см. 6.3.10). Прием восходящей команды RekeyInd используется сетевым сервером как сигнал для перехода к новому сеансу.

6.4.2.4 Сообщение с запросом на повторное присоединение к сети (Rejoin-Request)

После активации устройство может периодически передавать запрос на повторное присоединение к сети (Rejoin-Request) (помимо обмена данными, определенного приложением). Это сообщение с запросом повторного присоединения дает возможность периодически, на стороне сервера, инициализировать новый сеанс для оконечного устройства. С этой целью сеть (сетевой сервер) отвечает сообщением подтверждения присоединения к сети (Join-Accept). Это может быть использовано для передачи (перемещения) устройства между двумя сетями или в исходной сети для замены ключей и/или изменения devAddr устройства.

Сетевой сервер может также использовать окна приема RX1/RX2 после запроса повторного присоединения для передачи нормальных подтвержденных или неподтвержденных нисходящих сообщений, дополнительно передавая MAC-команды. Эта возможность полезна для сброса параметров приема устройства в случае, если состояние MAC-уровня рассинхронизовалось между устройством и сетевым сервером.

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

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

Примечание - В любое время сетевой сервер обрабатывает запросы на повторное присоединение (типа 0, 1 или 2) и генерирует сообщения с подтверждением присоединения к сети, он должен поддерживать как старый сеанс (ключи и счетчики, если они есть), так и новый, пока не получит первый успешный пакет из восходящей линии связи, используя новый сеанс, после чего старый сеанс следует удалить. Во всех случаях обработка сообщения с запросом на повторное присоединение сетевым сервером похожа на обработку стандартного сообщения с запросом на присоединение к сети, в котором сетевой сервер в начале обработки сообщения определяет, должен ли он передать его серверу присоединения (Join-Server) для формирования подтверждения присоединения к сети (Join-Accept) в ответ.

Существует три типа сообщений с запросом на повторное присоединение, которые могут быть переданы оконечным устройством и соответствуют трем различным целям. Первый байт сообщения с запросом на повторное присоединение называется "Тип повторного присоединения" (Rejoin Type) и используется для кодирования типа запроса на повторное присоединение. В таблице 18 описано назначение каждого типа сообщения с запросом на повторное присоединение к сети.

Таблица 18

Типы сообщений с запросом на повторное присоединение к сети

Тип запроса	Описание и назначение
0	Содержит NetID+DevEUI. Используется для закрытия соединения на уровне сеанса с устройством, включая все параметры радио (devAddr, ключи сеанса, счетчики кадров, параметры радио). Такие сообщения могут направляться устройствами только на домашние сетевые сервера, не на сервер присоединения (JoinServer). MIC этого сообщения может быть проверен только при транзитном обслуживании или домашним сетевым сервером
1	Содержит JoinEUI+DevEUI. В точности эквивалентно исходному запросу присоединения Join-Request, но может передаваться поверх обычного прикладного трафика без отключения устройства. Только получающий его сетевой сервер может перенаправить на соответствующий устройству сервер Join. Используется для восстановления утерянного контекста сеанса (например, сетевой сервер потерял ключи сеанса и не может связать (ассоциировать) устройство с JoinServer). Только JoinServer способен проверить MIC этого сообщения
2	Содержит NetID+DevEUI. Используется для замены ключей устройства или изменения его devAddr (devAddr, сеансовые ключи, счетчики кадров). Параметры радио остаются неизменными. Эти сообщения могут направляться на домашний сетевой сервер только посещаемыми сетями (из роуминга). Не могут быть отправлены сервером присоединения Join оконечного устройства. MIC этого сообщения может быть проверен только при переправке (транзитном обслуживании) или домашним сетевым сервером

а) Сообщение с запросом на повторное присоединение типа 0 или 2

Сообщение с запросом на повторное присоединение типа 0 или 2 содержит NetID (идентификатор домашней сети устройства), DevEUI оконечного устройства и значение 16-битного счетчика (RJcount0) (см. рисунок 58).

Размер (в байтах)	1	3	8	2
ReJoin-Request	Rejoin Type = 0 или 2	NetID	DevEUI	RJcount0

Рисунок 58 - Структура сообщения с запросом

на повторное присоединение

RJcount0 - счетчик, значение которого увеличивается с каждым переданным запросом на повторное присоединение типа 0 или 2. RJcount0 инициализируется в 0 каждый раз, когда подтверждение присоединения успешно обработано оконечным устройством. Для каждого оконечного устройства сетевой сервер должен отслеживать и хранить последнее значение RJcount0 (так называемый RJcount0_last), использованное оконечным устройством. Он игнорирует запросы на повторное присоединение, если (RJcount0 <= RJcount0_last).

RJcount0 никогда не повторяется (не должен использоваться в цикле при переполнении). Если RJcount0 достигает 2¹⁶ - 1, устройство должно прекратить передачу запроса на повторное присоединение типа 0 или 2. Устройство может вернуться к состоянию присоединения к сети.

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

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

Message = MHDR || Rejoin Type || NetID ||

DevEUI || RJcount0.

Используются младшие 4 байта полученного значения.

Сообщение с запросом на повторное присоединение не кодируется.

Коэффициент "рабочий цикл устройства" (duty-cycle) при передаче запросов на повторное присоединение типа 0 или 2 должен быть менее 0,1%.

Примечания

1 Сообщение с запросом на повторное присоединение типа 0 предполагается передавать (по замыслу) от одного раза в час до одного раза в несколько дней, в зависимости от варианта использования устройства. Это сообщение также может быть передано MAC-командой ForceRejoinReq. Это сообщение может использоваться для переподключения мобильного устройства к гостевой сети при роуминге. Также может быть использовано для замены ключей или изменения devAddr статического устройства. Мобильные устройства, как ожидается, перемещаясь между сетями, должны передавать это сообщение чаще, чем статические устройства.

2 Сообщение с запросом на повторное присоединение типа 2 предназначено только для обеспечения замены ключей оконечного устройства. Это сообщение может передаваться только MAC-командой ForceRejoinReq.

б) Сообщение с запросом на повторное присоединение типа 1

Аналогично запросу на присоединение сообщение с запросом на повторное присоединение типа 1 содержит JoinEUI и DevEUI оконечного устройства (см. рисунок 59). Поэтому сообщение с запросом на повторное присоединение типа 1 может быть направлено серверу присоединения оконечного устройства (Join-Server) любым сетевым сервером, принявшим его. Запрос на повторное присоединение типа 1 может использоваться для восстановления связи с оконечным устройством в случае полной потери сетевого сервера. Рекомендуется передавать сообщение с запросом на повторное присоединение типа 1 не реже одного раза в месяц.

Размер (в байтах)	1	8	8	2
ReJoin-Request	Rejoin Type = 1	JoinEUI	DevEUI	RJcount1

Рисунок 59 - Структура сообщения с запросом

на повторное присоединение к сети типа 1

RJcount1 для запроса на повторное присоединение к сети типа 1 - это другой счетчик, не RJCount0 (который используется для запроса на повторное присоединение типа 0).

RJcount1 - счетчик, значение которого увеличивается с каждым переданным запросом на повторное присоединение типа 1. Для каждого оконечного устройства сервер присоединения (Join-Server) отслеживает и хранит последнее значение RJcount1 (так называемый RJcount1_last), использованное оконечным устройством. Он игнорирует запросы на повторное присоединение, если (RJcount1 <= RJcount1_last).

RJcount1 никогда не повторяется для выданного JoinEUI. Периодичность отправки запроса на повторное присоединение типа 1 должна быть такой, чтобы не могло произойти переполнение счетчика и повторное использование его значений в период жизни устройства с заданным значением JoinEUI.

MIC для сообщения с запросом на повторное присоединение типа 1 рассчитывается с помощью ключа JSIntKey (ключ кодирования Join-Accept в случае получения запроса Rejoin-Request) и сообщения:

Message = MHDR || Rejoin Type || JoinEUI ||

DevEUI || RJcount1.

Используются младшие 4 байта полученного значения.

Сообщение с запросом на повторное присоединение типа 1 не кодируется.

Рабочий цикл устройства (duty-cycle) при передаче запросов на повторное присоединение типа 1 всегда должен быть < 0,01%.

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

в) Передача запроса на повторное присоединение

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

Таблица 19

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

запроса на повторное присоединение

Тип запроса на повторное присоединение (RejoinRequest)	Передается автономно и периодически оконечным устройством	Передается с MAC-командой ForceRejoinReq
0	x	x
1	x
2		x

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

Запрос на повторное присоединение типа 2 должен передаваться по любому включенному в настоящий момент каналу на соответствующих случайно переключаемых (выбираемых) частотах.

Запросы на повторное присоединение типов 0 и 2, передаваемые с помощью команды ForceRejoinReq, должны использовать скорость передачи данных, указанную в MAC-команде.

Запросы на повторное присоединение типа 0 [передаются периодически и автономно оконечным устройством (с максимальной периодичностью, установленной командой RejoinParamSetupReq)] и запросы на повторное присоединение типа 1 должны использовать:

- скорость передачи данных и выходную мощность передатчика, используемые в настоящий момент для передачи прикладных данных (payload), если включен ADR;

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

г) Обработка запроса на повторное присоединение

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

- сообщением с подтверждением присоединения (как описано в 6.4.2.3), если он хочет изменить сетевой идентификатор устройства (роуминг или замена ключей). В этом случае RJcount (0 или 1) заменяет DevNonce в процедуре получения ключей;

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

В большинстве случаев на попутные запросы на повторное присоединение типа 0 или 1 сеть не будет реагировать.