Почему подключение LoRaWAN-устройства вообще было проблемой

LoRaWAN-сеть сложнее обычной связи между двумя LoRa-модулями.

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

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

• LoRaWAN MAC version;
• Regional Parameters version;
• поддерживаемые классы устройства;
• возможности ADR;
• параметры MAC;
• часть параметров радиорежима;
• особенности конкретной модели.

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

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

TS014: сетевой сервер получает Device Profile автоматически

TS014-1.0.0 называется End Device Capabilities API.

Спецификация определяет стандартный интерфейс, через который home Network Server, или hNS, может получить Device Profile с отдельного Device Profile Server.

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

Для описания интерфейса используется OpenAPI Definition.

Что это даёт

Если экосистема производителей и Network Server реализует новый механизм, оператору не придётся каждый раз вручную искать и переносить характеристики конкретной модели.

Система сможет сама запросить нужный профиль.

Что такое Device Profile

Device Profile не следует путать с данными конкретного пользователя или показаниями датчика.

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

Проще представить его как технический паспорт модели, который может автоматически читать сетевой сервер.

TS018: QR-код становится частью автоматического onboarding

Вторая новая спецификация называется TS018-1.0.0 LoRaWAN Device Identification QR Codes for Automated Onboarding.

Её задача заключается в стандартизации маркировки LoRaWAN-устройств QR-кодами для упрощения их добавления в сеть.

В новой схеме QR-код может содержать информацию, позволяющую определить Device Profile Server.

Получается цепочка:

Главная цель проста: уменьшить количество мест, где оператор способен вручную ошибиться.

Как это может выглядеть на реальном объекте

Представим монтаж 300 LoRaWAN-датчиков.

С ручной настройкой

1. определить модель;
2. найти документацию производителя;
3. выбрать или создать Device Profile;
4. проверить параметры;
5. внести сведения об устройстве;
6. повторить процедуру для разных моделей.

С автоматизированным onboarding

1. отсканировать стандартизированный QR-код;
2. получить идентификационные данные;
3. автоматически определить источник Device Profile;
4. загрузить профиль через стандартный API;
5. выполнить необходимые действия регистрации на Network Server.

Конкретный интерфейс будет зависеть от реализации сетевой платформы, но сам формат взаимодействия перестаёт быть полностью проприетарным.

Почему это важно именно для больших систем

LoRaWAN часто используют там, где устройств не десять и не двадцать.

Типичные проекты:

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

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

По данным самой LoRa Alliance, мировой парк развёрнутых LoRaWAN end devices уже превышает 125 млн устройств.

QR-код не означает, что все секретные ключи нужно печатать открыто

Автоматизированный onboarding не отменяет требований безопасности LoRaWAN.

Нужно различать:

• идентификацию устройства;
• получение Device Profile;
• секретные параметры активации и криптографические ключи.

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

TS014 и TS018 работают вместе, но это разные документы

Эти спецификации хорошо дополняют друг друга.

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

TR016: почему LoRa Alliance отдельно занялась Relay

Третий документ из нового пакета называется TR016-1.0.0 LoRaWAN Relay Technical Recommendations.

Здесь особенно важно не перепутать рекомендацию со спецификацией нового протокола.

Зачем LoRaWAN вообще понадобился Relay

Обычная LoRaWAN-сеть строится примерно так:

Но иногда датчик находится там, куда gateway нормально не достаёт.

Например:

• в глубоком подвале;
• за несколькими железобетонными перекрытиями;
• в техническом помещении;
• в металлическом шкафу;
• под землёй;
• в удалённой точке без возможности установить полноценный gateway и backhaul.

Тогда между устройством и gateway может работать Relay.

Relay передаёт LoRaWAN-кадры в обе стороны между конечным устройством и сетью.

Почему просто поставить ещё один gateway не всегда удобно

Gateway требует не только питания.

Обычно ему также необходим канал связи с Network Server:

• Ethernet;
• Wi-Fi;
• LTE;
• другая IP-связь.

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

Relay даёт дополнительный инструмент для подобных зон покрытия.

Почему TR016 важен, если Relay уже существовал

Наличие стандарта ещё не гарантирует, что все производители одинаково хорошо реализуют его на практике.

TR016 направлен на то, чтобы разработчики создавали устройства, которые:

• корректно работают с механизмом Relay;
• предсказуемо взаимодействуют с сетью;
• не создают неправильное поведение в радиоэфире;
• лучше совместимы с оборудованием других производителей.

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

LoRaWAN Relay и Meshtastic mesh: это не одно и то же

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

Это неверно.

Поэтому выбирать между LoRaWAN Relay и Meshtastic только по слову «ретранслятор» неправильно.

Это разные архитектуры для разных задач.

Пример: датчик воды в подвале

Допустим, в здании установлен LoRaWAN gateway на верхнем техническом этаже.

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

Возможные варианты:

1. перенести gateway;
2. поставить второй gateway;
3. изменить расположение антенны;
4. использовать Relay при наличии совместимой инфраструктуры;
5. выбрать другую архитектуру связи.

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

Пример: металлический шкаф

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

Сначала всё равно нужно проверить физическую причину:

• антенну;
• её расположение;
• кабель;
• возможность вынести антенну;
• местоположение gateway.

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

Что новые документы действительно меняют на практике

QR-код сам по себе ничего не автоматизирует

Это важное ограничение.

Чтобы схема заработала полностью, новые спецификации должны поддерживать несколько сторон:

• производитель устройства;
• производитель Network Server;
• Device Profile Server;
• программное обеспечение onboarding.

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

Это инфраструктурный стандарт, распространение которого будет зависеть от поддержки экосистемой.

Можно ли будет смешивать оборудование разных производителей

Именно уменьшение зависимости от собственных проприетарных механизмов является одним из смыслов стандартизации.

Но реальная совместимость по-прежнему зависит от:

• поддерживаемой версии LoRaWAN;
• Regional Parameters;
• реализации конкретного устройства;
• Network Server;
• поддержки новых API и QR-форматов.

Само наличие логотипа LoRaWAN ещё не означает поддержку TS014 или нового onboarding-процесса конкретной платформой.

Что проверить перед покупкой LoRaWAN-оборудования после этих изменений

1. Поддерживает ли устройство нужный регион и диапазон.
2. Какая версия LoRaWAN используется.
3. Есть ли LoRaWAN Certification.
4. Поддерживает ли производитель стандартизированный QR onboarding.
5. Есть ли Device Profile Server.
6. Поддерживает ли ваш Network Server TS014.
7. Нужен ли Relay вообще.
8. Поддерживает ли конкретное оборудование Relay.
9. Можно ли решить задачу правильным размещением gateway.

Главное изменение не в радиосвязи, а в эксплуатации

TS014 и TS018 не делают LoRa быстрее и не увеличивают дальность датчика.

Их эффект находится в другом месте:

Для массового IoT это может оказаться значительно важнее очередного небольшого улучшения радиохарактеристик.

А TR016 развивает другую сторону проблемы

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

Вместе получается интересная логика развития LoRaWAN:

Итог

Объявление LoRa Alliance от 4 августа 2026 года не принесло новую версию радиопротокола, которая внезапно увеличивает дальность LoRaWAN.

Изменения менее эффектны визуально, но важны для зрелости экосистемы.

TS014 стандартизирует получение Device Profile.

TS018 стандартизирует QR-onboarding и помогает указать системе источник профиля устройства.

TR016 даёт разработчикам практические рекомендации по реализации уже существующего LoRaWAN Relay.

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