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

Прежде чем обмениваться данными с сервером, устройство LoRaWAN проходит активацию. ONS поддерживает два способа: OTAA — устройство само подключается к сети (join) по процедуре LoRaWAN 1.0.x с одним корневым ключом AppKey, и ABP — адрес и сеансовые ключи заранее записаны в устройство и на сервер. На этой странице — что сервер делает с запросом на подключение (Join Request), как проверить результат и почему устройство может не подключиться. Поля устройства в веб-интерфейсе описаны в разделе «Узлы», регистрация через WebSocket API — в команде create_device_req.

Что зарегистрировать на сервере

Что	OTAA	ABP
DevEUI	Обязательно. Уникален среди активных устройств. По нему сервер находит устройство при join — в прямом или обратном порядке байтов	Обязательно. Уникален среди активных устройств
AppKey	Обязательно. Точно такой, как в устройстве: им сервер вычисляет сеансовые ключи и шифрует Join Accept. При несовпадении устройство не сможет принять Join Accept и не подключится	Сервер его не использует; команда create_device_req требует его и для ABP
DevAddr	Не нужен: сервер выдаёт новый адрес при каждом join	Адрес из прошивки устройства. Уникален среди активных устройств
NwkSKey, AppSKey	Не нужны: сервер вычисляет их при join	Ключи из прошивки устройства
Частотный план (поле «Регион», region)	Как в прошивке устройства: по нему сервер выбирает частоты Join Accept	Как в прошивке устройства
Класс	Как в прошивке устройства, см. Классы устройств	Как в прошивке устройства
«Вкл/Выкл»	Включено	Включено

JoinEUI (AppEUI) из Join Request сервер ни с чем не сравнивает: он не обязан совпадать с AppEUI приложения ONS.

Выключенное или удалённое устройство сервер при join не находит, а его DevEUI получает бан на 1 час, см. Защита от шторма join.

Как проходит активация OTAA

1. Защита от шторма. Join Request забаненного устройства сервер не обрабатывает, см. Защита от шторма join.
2. Приём. Join Request слышат один или несколько шлюзов. Первая копия открывает запись для этого DevEUI. Копии, пришедшие в течение 2 секунд после неё, сервер объединяет с ней: добавляет шлюз в список и переключает Join Accept на шлюз, если копия принята с RSSI выше, чем первая. Через 2 секунды сервер закрывает запись, и Join Request, пришедший позже, обрабатывает как новую попытку.
3. Поиск устройства. Сервер ищет включённое и активное устройство по DevEUI. Не нашёл — Join Accept не будет, а DevEUI получает бан «не найдено».
4. AppKey. Ключом AppKey из настроек устройства сервер вычисляет сеансовые ключи и шифрует Join Accept. Если AppKey в настройках не совпадает с ключом в устройстве, устройство не сможет принять Join Accept.
5. Новый адрес и ключи. Сервер выдаёт устройству новый DevAddr и вычисляет новые NwkSKey и AppSKey. Адрес и ключи записываются в настройки устройства и в историю join.
6. Отправка Join Accept. Через 2 секунды после первой копии сервер передаёт Join Accept через один шлюз к окну RX1 — через 5 секунд после Join Request — или к окну RX2 — через 6 секунд. Подробнее — в следующем разделе.
7. Счётчики кадров. FCnt uplink и downlink обнуляются.
8. Радиопараметры. Параметры из панели «Радиопараметры» сервер передаёт устройству после join MAC-командами, см. Радиопараметры и журнал MAC-команд.

Новый DevAddr сервер составляет из NwkID — младших 7 бит NetID — и 25 случайных бит. NetID задаёт параметр запуска --netid компонентов LWServer и LWAuthorizator: первый кладёт NetID в Join Accept, второй составляет DevAddr, поэтому в локальной установке задавайте его в обоих одинаково. По умолчанию — 000021; с ним адреса лежат в диапазоне 0x42000000–0x43FFFFFF.

Join Accept: содержимое и время отправки

Join Accept зашифрован ключом AppKey и содержит:

Поле	Значение
AppNonce	3 случайных байта
NetID	Значение параметра --netid компонента LWServer, по умолчанию 000021
DevAddr	Новый адрес устройства
DLSettings	Смещение DR для RX1 — 0 во всех частотных планах; скорость RX2 — из частотного плана устройства
RXDelay	1 секунда во всех частотных планах
CFList	До 5 опциональных каналов uplink из частотного плана устройства; в планах US915 и AU915 — маска включённых каналов плана

Параметры из панели «Радиопараметры» — скорость и частота RX2, смещение DR и задержка RX1, дополнительные каналы — в Join Accept не попадают. После join сессия начинается с параметров частотного плана и каналов из CFList, а к заданным значениям сервер доводит устройство MAC-командами.

Как сервер выбирает окно, частоту и скорость:

• Время. Кадр уходит не немедленно, а в заданный момент по счётчику шлюза: момент приёма Join Request этим шлюзом плюс 5 секунд для RX1 или плюс 6 секунд для RX2. Эти задержки одинаковы во всех частотных планах.
• Окно задаёт поле «Rx окно» устройства (rx_window), по умолчанию RX1. Устаревшее значение 0 сервер считает RX2.
• RX1. Частота — канал downlink, который в частотном плане устройства соответствует частоте и скорости Join Request; если соответствия нет — канал 0. Скорость — по таблице RX1 частотного плана со смещением 0: во всех планах, кроме US915 и AU915, — та же, что у Join Request; в планах US915 и AU915 — соответствующая скорость downlink (DR8–DR13).
• RX2. Частота и скорость из частотного плана устройства, например: KZ865-868 (код 6) — 866,7 МГц, DR0; RU (код 2) — 869,1 МГц, DR0; EU863-870 (код 7) — 869,525 МГц, DR0.
• Опоздание к RX1. Если по оценке сервера кадр не успеет к RX1 — время с приёма Join Request плюс половина RTT до шлюза плюс 0,15 секунды больше 5 секунд, — сервер переносит отправку на момент окна RX2 и пишет в журнал JOIN_ACCEPT_RX_FALLBACK. Частоту и скорость кадра при этом сервер не меняет: они остаются от RX1.
• Шлюз. Join Accept уходит только через выбранный шлюз. Если сервер не знает адреса шлюза — шлюз не присылал PULL_DATA, — кадр не отправляется.
• Без повтора. Join Accept передаётся один раз: в другое окно сервер его не повторяет.

Каналы, окна RX1 и RX2 и скорости всех 38 планов — в разделе Частотные планы; краткая таблица с окном RX2 — «Коды регионов».

Сеансовые ключи и счётчики кадров

Ключи сервер вычисляет по схеме LoRaWAN 1.0.x:

Значение	Как вычисляется
MIC Join Request	AES-CMAC(AppKey, MHDR | AppEUI | DevEUI | DevNonce)
NwkSKey	AES-ECB(AppKey, 0x01 | AppNonce | NetID | DevNonce | дополнение нулями)
AppSKey	AES-ECB(AppKey, 0x02 | AppNonce | NetID | DevNonce | дополнение нулями)

Новые ключи и DevAddr сервер записывает в настройки устройства и в историю join. У устройства OTAA поля «Ключ сенса сети» (так в интерфейсе) и «Ключ сеанса приложения» в карточке только для чтения.

Как сервер проверяет uplink:

• MIC кадра проверяется ключом NwkSKey. Кадр с неверным MIC отбрасывается и в данные устройства не попадает.
• FRMPayload расшифровывается ключом AppSKey при FPort больше 0 и ключом NwkSKey при FPort = 0.
• Копии кадра с тем же FCnt — приём несколькими шлюзами и повторные передачи устройства — сервер объединяет в один кадр.

Счётчики кадров FCnt uplink и downlink при каждом join обнуляются — в памяти сервера и в полях «Seq up» и «Seq down».

Предел FCnt. MIC сервер проверяет только для значений FCnt, у которых старшие 16 бит равны 0 или 1. Uplink с FCnt больше 131071 (0x1FFFF) не проходит проверку MIC и отбрасывается. У устройства OTAA счётчик обнуляется при каждом join. Устройство ABP, которое не сбрасывает счётчик, сервер перестанет принимать, когда FCnt превысит 131071.

Перезапуск сервера. Сессия переживает перезапуск сервера и потерю его кэша. Если DevAddr нет ни в памяти, ни в Redis, сервер запрашивает в базе включённое активное устройство с этим DevAddr — в прямом или обратном порядке байтов — и получает ключи, счётчики кадров и состояние MAC-сессии. Устройству OTAA после перезапуска сервера повторный join не нужен. Кадры с DevAddr, которого нет в базе, сервер 300 секунд отбрасывает без запроса к базе, затем спрашивает снова.

Особенности ABP

• Join нет. Сервер обслуживает устройство с первого uplink по DevAddr, NwkSKey и AppSKey из базы.
• На первом uplink, пока «Seq up» равен 0, сессия начинается с параметров частотного плана без опциональных каналов. Каналы сервер передаёт позже MAC-командой NewChannelReq.
• Ключи, сохранённые в веб-интерфейсе, сервер начинает использовать сразу. Когда устройство получает изменения, сделанные через WebSocket API, написано на странице update_device_req.
• Поле join_request_time в сообщении realtime_data у устройства ABP всегда null.
• Действует предел FCnt: когда FCnt превысит 131071, сервер перестанет принимать uplink, пока счётчик в устройстве не будет сброшен.

Защита от шторма join

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

Бан	Когда	Длительность по умолчанию
За частоту	Join Request стал бы 20-м за 600 секунд	1 час
«Не найдено»	Join Request от DevEUI, которого база не вернула: устройство не зарегистрировано, выключено или удалено	1 час

• Join Request забаненного устройства сервер не обрабатывает: в данных устройства нет строки JR, в истории join нет записи.
• Бан «не найдено» снимает создание устройства — в веб-интерфейсе, импортом, через REST API или командой create_device_req. Правка устройства, в том числе повторное включение, бан не снимает.
• Устройство с отметкой «Тестовое устройство» не банится ни за частоту, ни как «не найдено». Отметку ставят только пользователи staff и суперпользователь, см. Параметры узла LoRaWAN. Освобождение действует по умолчанию сутки и продлевается при каждом успешном join и каждом сохранении устройства. Выключенное или удалённое устройство освобождения не получает.

Для локальной установки ONS числа меняют параметры запуска сервера: --jr_limit — порог, --jr_ban_timeout и --jr_notfound_ban_timeout — длительность банов в секундах, --jr_exempt_ttl — срок освобождения тестового устройства в секундах. Окно 600 секунд параметром не задаётся.

Как проверить, что устройство подключилось

1. Колонка «Последнее соединение» в списке узлов показывает время последнего join. Подсказка при наведении — статус: MIC OK, MIC ERROR или LATE JOIN ACCEPT; красная ячейка — статус не MIC OK. Что устройство приняло Join Accept, эта колонка не показывает — признак этого первый uplink (пункт 3). Время обновляется, как только сервер нашёл устройство по DevEUI, и при каждой записи в историю join, с любым статусом.
2. Таблица «Данные» на вкладке «Мониторинг». Строка JR (uplink, в данных — DevNonce) появляется на первой копии Join Request, ещё до того, как сервер подготовит Join Accept, поэтому она есть, даже если Join Accept не отправлен. Строку JR сервер пишет только для устройства, которое есть в базе. Строка JA (downlink, в данных — AppNonce) появляется после отправки Join Accept.
3. Первый uplink после JA с новым DevAddr — признак того, что устройство приняло Join Accept.

Статус в колонке «Последнее соединение» говорит только о том, что сервер принял Join Request. Если Join Accept потерян, устройство должно прислать новый Join Request.

Почему устройство не подключается

Что видно	Причина	Что сделать
На вкладке «Мониторинг» нет строк JR	Join Request не услышал ни один шлюз, устройство забанено, или его нет в базе: не зарегистрировано или удалено	Проверьте, что рядом с устройством есть шлюз, подключённый к серверу. Сверьте DevEUI. Бан снимется через 1 час; бан «не найдено» снимает и создание устройства
Статус LATE JOIN ACCEPT	Сервер не успел найти устройство в базе за 2 секунды, и Join Accept не отправлен	Дождитесь следующей попытки устройства. В локальной установке проверьте нагрузку на базу
Есть JR, нет JA	Сервер не знает адреса выбранного шлюза: шлюз не присылал PULL_DATA. Или у устройства план AS923-1 (код 10): в текущей версии сервер не отправляет такому устройству Join Accept	Проверьте подключение шлюза к серверу. Для устройства AS923-1 выберите в поле «Регион» AS923-2 (код 11) или AS923-4 (код 13), см. Частотные планы
Есть JR, нет uplink с нового DevAddr	AppKey в настройках не совпадает с ключом в устройстве, частотный план («Регион») не совпадает с прошивкой или Join Accept потерян	Введите AppKey из устройства как есть и дождитесь следующего Join Request. Исправьте «Регион». После потери Join Accept устройство должно повторить Join Request
Устройство выключили и снова включили, а оно не подключается	Join Request выключенного устройства получил бан «не найдено» на 1 час; включение бан не снимает	Подождите до 1 часа или отметьте «Тестовое устройство»
ABP: uplink нет в данных	Неверный DevAddr или NwkSKey — кадр не проходит MIC; FCnt больше 131071; устройство выключено или удалено	Сверьте DevAddr и ключи с прошивкой и сохраните устройство в веб-интерфейсе; сбросьте счётчик кадров в устройстве; включите устройство
ABP: uplink есть, данные не расшифровываются	Неверный AppSKey	Сверьте AppSKey с прошивкой

Журнал сервера

В локальной установке ONS ход join виден в журнале компонента LWServer. Устройство в базе ищет компонент LWAuthorizator.

Запись в журнале	Что значит
JOIN_ACCEPT_SENT	Join Accept передан шлюзу. В записи — шлюз, окно, частота и скорость
JOIN_ACCEPT_TIMEOUT	Через 2 секунды после первой копии Join Accept не готов: LWAuthorizator не ответил
JOIN_ACCEPT_NOT_FOUND	Устройство не найдено в базе: не зарегистрировано, выключено или удалено. DevEUI получает бан «не найдено»
JOIN_ACCEPT_LATE	Ответ LWAuthorizator пришёл после отведённых 2 секунд. В историю join записан статус LATE JOIN ACCEPT
JOIN_ACCEPT_NO_GATEWAY	Адрес выбранного шлюза неизвестен, Join Accept не отправлен
JOIN_ACCEPT_RX_FALLBACK	Сервер не успевал к RX1 и перенёс отправку на момент RX2
DevEui: <EUI> banned, skip join	Join Request отброшен баном
DevEui: <EUI> banned (rate|not_found) for Ns	Причина бана — за частоту или «не найдено» — и сколько секунд он ещё продлится
MIC ERROR for: <DevAddr>	Uplink с неверным MIC отброшен

Что важно знать

• Если на вкладке «Мониторинг» есть строки JR и JA, а uplink с нового DevAddr нет, первым делом сверьте AppKey с ключом в устройстве.
• Если Join Accept потерян, устройство должно прислать новый Join Request.
• Uplink с FCnt больше 131071 не проходит проверку MIC.
• Rejoin-request из LoRaWAN 1.1 сервер не обрабатывает.
• Join Accept несёт только параметры частотного плана; «Радиопараметры» устройство получает после join MAC-командами.
• Выключенное и снова включённое устройство может ждать снятия бана до 1 часа.

См. также

• Узлы — поля OTAA и ABP, «Тестовое устройство», колонка «Последнее соединение».
• Создать устройство — регистрация устройства OTAA или ABP через WebSocket API.
• Изменить настройки устройства — когда устройство OTAA и ABP получает новые настройки и ключи.
• Частотные планы — каналы, окна RX1 и RX2 и скорости всех 38 планов.
• Классы устройств — когда устройство слушает эфир и получает downlink.