ПНСТ 516-2021 Информационные технологии (ИТ). Интернет вещей. Спецификация LoRaWAN RU.
ПНСТ 516-2021
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационные технологии
ИНТЕРНЕТ ВЕЩЕЙ
Спецификация LoRaWAN RU
Information technology. Internet of things. LoRaWAN RU specification
ОКС 35.020, 35.110
Срок действия с 2021-07-01
до 2024-07-01
Предисловие
1 РАЗРАБОТАН Ассоциацией участников рынка интернета вещей и Акционерным обществом "Российская венчурная компания" (АО "РВК")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 "Кибер-физические системы"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 января 2021 г. N 5-пнст
Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).
Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва, Инновационный центр Сколково, ул.Нобеля, д.1; e-mail: info@tc194.ru и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д.10, стр.2.
В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе "Национальные стандарты" и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Настоящий стандарт определяет телеметрический протокол с адаптивной полосой (LoRaWAN RU), оптимизированный для оконечных устройств с батарейным питанием, которые могут быть мобильными или стационарными.
В базовой конфигурации сеть LoRaWAN RU имеет топологию "звезда из звезд" (star-of-stars). В расширенной конфигурации сеть LoRaWAN RU может иметь конфигурацию, заложенную разработчиком в оконечное устройство (Р-2-Р Mesh-сети и др.) В базовой конфигурации шлюзы* ретранслируют сообщения между оконечными устройствами** и центральным сервером сети. Сервер сети маршрутизирует пакеты с каждого устройства сети на соответствующий сервер приложений.
________________
* Шлюзы также известны как концентраторы или базовые станции.
** Оконечные устройства также называют "мотами".
Шлюзы подключаются к серверу сети через IP-соединения. Оконечные устройства используют прямую передачу данных на один или несколько шлюзов с линейно-частотной модуляцией***. Обмен данными двусторонний, однако предполагается, что объем данных в восходящей линии связи (от оконечного устройства к серверу сети) будет преобладать над объемом данных в нисходящей линии связи (от сервера сети к оконечным устройствам).
________________
*** В настоящем стандарте не рассматривается поддержка промежуточных элементов-повторителей, и рассматриваются ограничения полезной нагрузки для издержек инкапсуляции. Повторитель определен как использующий протокол LoRaWAN RU в качестве механизма обратного рейса.
Связь между оконечными устройствами и шлюзами распределяется по различным частотным каналам и скоростям передачи данных. Выбор скорости передачи данных - это компромисс между максимальной дальностью связи и минимальной продолжительностью сообщения в радиоэфире. Одновременная связь с разными оконечными устройствами на одной частоте, но с разными скоростями передачи данных не создает взаимных помех. Скорость передачи данных по протоколу LoRaWAN RU составляет от 0,3 кбит/с до 50 кбит/с. Чтобы максимально увеличить время автономной работы оконечных устройств и общую пропускную способность сети, сервер сети может управлять скоростью передачи данных и выходной мощностью радиопередатчика для каждого оконечного устройства индивидуально, посредством схемы адаптивной скорости передачи данных (ADR, adaptive data rate).
Оконечные устройства могут передавать данные по любому доступному частотному каналу в любое время, используя любую доступную скорость передачи данных, если соблюдаются следующие правила:
- оконечное устройство для каждой передачи выбирает частотный канал псевдослучайным образом. Данное распределение по частотам делает систему связи более устойчивой к помехам;
- оконечное устройство учитывает ограничение на максимальный рабочий цикл передачи (DutyCycle) для используемого диапазона частот;
- оконечное устройство учитывает ограничение на максимальную длительность передачи (TimeOnAir) для используемого диапазона частот.
Примечание - Максимальный рабочий цикл передачи и максимальная длительность передачи на каждый поддиапазон являются региональными параметрами и определены в 6.1.
________________
1 Область применения
Целью настоящего стандарта является создание основы для скоординированной разработки инфраструктуры в области "интернета вещей" (IoT, Internet of Things).
Областью применения, описанной в настоящем документе технологии связи, является обмен данными с бытовым и промышленным оборудованием (приборы, датчики, пломбы, исполнительные устройства и т.п.) имеющим свойства:
- низкие требования к пропускной способности каналов связи;
- высокие требования к помехоустойчивости каналов связи;
- высокие требования к времени автономной работы (до 10 лет и более);
- предназначены для хранения и/или передачи общедоступной информации и информации ограниченного доступа, не содержащий сведений, относимых к государственной тайне (конфиденциальная информация);
- не предназначены для хранения и/или передачи информации, содержащие сведения составляющие государственную тайну.
Настоящий стандарт беспроводной связи обеспечивает обратную совместимость со стандартами LoRaWAN v.1.1 final release 11.11.2017 (кроме устройств класса "В") и LoRaWAN v.1.0.2 final 07.2016 (кроме устройств класса "В").
Выбор конкретных алгоритмов шифрования данных определяет разработчик оконечного устройства в зависимости от целевого назначения оконечного устройства и действующих нормативных документов. Например, для систем класса критической информационной инфраструктуры (КИИ) могут использоваться криптографические преобразования. Используемые в оконечном устройстве алгоритмы шифрования данных должны быть указаны в эксплуатационной документации на соответствующее оконечное устройство. Рекомендуется использовать алгоритм блочного шифрования. Описание и выбор конкретных алгоритмов шифрования данных выходит за рамки настоящего стандарта.
В настоящем стандарте используются следующие форматы записей:
- MAC-команды записываются в формате LinkCheckReq;
- константы записываются в формате RECEIVE_DELAY1.
В настоящем стандарте структура сообщений изложена с учетом:
- порядка следования байт и бит для всех полей - "от младшего к старшему" (little-endian);
- бита RFU (Reserved For Future), обозначающего поле для будущего использования. По умолчанию данный бит должен быть установлен на нуль передатчиком сообщения и должен быть проигнорирован на приемной стороне.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий стандарт:
ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р ИСО/МЭК 7498-1, а также следующие термины с соответствующими определениями.
3.1 активация (activation): Процедура присоединения оконечного устройства к сети.
3.2 активация "по воздуху"; OTAA (over the air activation): Способ активации оконечного устройства в сети через запрос-ответ.
3.3 активация через персонализацию; ABP (activation by personalization): Способ активации оконечного устройства в сети через предустановленные параметры контекста сеанса связи.
3.4 контекст сеанса связи (session context): Набор параметров сетевого сеанса и параметров сеанса приложения.
3.5 многоадресная рассылка (multicast): Режим передачи нисходящего сообщения нескольким оконечным устройствам одновременно.
3.6 оконечное устройство (end-device): Программно-аппаратное решение, являющееся узлом сети, который может обмениваться сообщениями по протоколу LoRaWAN RU.
3.7 параметры сеанса приложения (application session parameters): Набор ключей и счетчиков, поддерживаемый оконечным устройством и сервером приложений.
3.8 параметры сетевого сеанса (network session parameters): Набор ключей и счетчиков, поддерживаемый оконечным устройством и сервером сети.
3.9 рабочий цикл устройства (duty-cycle): Безразмерная величина, обратная скважности и равная отношению длительности передаваемого радиосообщения к периоду передачи.
3.10 сеансовый ключ (session key): Производный ключ от первичных ключей, хранящихся в оконечном устройстве.
3.11 uplink-канал (uplink): Канал связи восходящих сообщений от оконечного устройства к серверу сети.
3.12 downlink-канал (downlink): Канал связи нисходящих сообщений от сервера сети к оконечному устройству.
3.13 RFU: Зарезервировано для будущих применений.
4 Обозначения
В настоящем стандарте применены следующие обозначения:
DevEUI - идентификатор оконечного устройства;
JoinEUI - идентификатор сервера присоединения к сети;
AppKey - прикладной первичный ключ оконечного устройства;
NwkKey - сеансовый первичный ключ оконечного устройства;
DevAddr - короткий адрес оконечного устройства;
AppSKey - сеансовый ключ приложения - для кодирования прикладных данных в нисходящих и восходящих сообщениях;
NwkSEncKey - сетевой сеансовый ключ кодирования МАС-команд в нисходящих и восходящих сообщениях;
SNwkSIntKey - сетевой сеансовый ключ целостности нисходящих сообщений;
FNwkSIntKey - сетевой сеансовый ключ целостности восходящих сообщений;
JSIntKey - ключ целостности восходящего сообщения с запросом Rejoin-Request первого типа и нисходящего сообщения ответа Join-Accept;
JSEncKey - ключ кодирования Join-Accept в случае получения запроса Rejoin-Request;
Join-Request - запрос на присоединение к сети;
DevNonce - счетчик запросов на присоединение к сети;
Rejoin-Request - запрос на переприсоединение к сети;
Join-Accept - подтверждение присоединения (переприсоединения) к сети;
JoinNonce - счетчик подтверждений присоединения (переприсоединения) к сети;
MIC - код целостности сообщения (message integrity code).
"||" - знак конкатенации строк;
"[x:y]" - последовательность бит, где "х" - старший бит, а "у" - младший бит;
5 Классы устройств LoRaWAN RU
Все оконечные устройства должны реализовать базовую функциональность класса А, определенного в настоящем стандарте.
Некоторые оконечные устройства могут дополнительно реализовать вариант протокола с изменением до класса C, определенного в настоящем стандарте. Любое оконечное устройство должно поддерживать совместимость с классом A.
Сеть LoRaWAN RU различает базовый класс устройств (класс A) и класс с дополнительными функциями (класс C) (рисунок 1).
 |
Рисунок 1 - Классы устройств LoRaWAN RU
Двунаправленные оконечные устройства (класс A): Оконечные устройства класса A предназначены для обеспечения двунаправленной связи, в которой за каждой передачей сообщения оконечным устройством в восходящую линию связи следуют два коротких окна приема для нисходящей линии связи. Интенсивность передачи каждым оконечным устройством зависит от его собственной потребности в связи с небольшим отклонением времени начала передачи сообщения на случайную величину (протокол ALOHA). Класс А обеспечивает экономичный расход энергии и подходит в случаях, когда приемлема связь по нисходящей линии связи от сервера только после передачи по восходящей линии связи. Сервер сети для передачи сообщения по нисходящей линии связи должен дождаться следующего сообщения от оконечного устройства по восходящей линии связи.
Двунаправленные оконечные устройства с максимальными окнами приема (класс C): У оконечных устройств класса С большую часть времени открыто одно из окон приема (за исключением времени передачи сообщения по восходящей линии связи). Оконечное устройство класса С будет расходовать больше энергии по сравнению с устройством класса А, но при этом иметь минимальную задержку передачи сообщения от сервера сети к оконечному устройству.
6 Оконечные устройства класса А
6.1 Режимы связи и окна приема в оконечных устройствах класса А
6.1.1 Режимы связи оконечного устройства
Оконечное устройство различает 2 режима связи:
- передача восходящего сообщения в сервер сети;
- прием нисходящего сообщения от сервера сети.
Настоящий протокол предполагает наличие между оконечным устройством и сервером сети одного нисходящего радиоканала и множества восходящих радиоканалов. С целью повышения емкости нисходящего радиоканала в структуре нисходящего сообщения отсутствует поле "Циклическая контрольная сумма" (CRC).
6.1.2 Окна приема (класс A)
После каждой передачи восходящего сообщения оконечное устройство должно открыть два коротких окна приема. Момент открытия окон RX1 и RX2 приема нисходящих сообщений задается относительно времени окончания передачи восходящего сообщения (рисунок 2).
 |
Рисунок 2 - Временные сегменты приема оконечного устройства
6.1.2.1 Канал, скорость передачи данных и время открытия первого окна приема
Первое окно приема RX1 использует частоту, значение которой зависит от частоты в восходящей линии связи, и скорость приема данных в окне RX1, которая зависит от скорости передачи данных предыдущего восходящего сообщения. Окно приема RX1 открывается с задержкой RECEIVE_DELAY1 секунд (+/-20 микросекунд) после окончания модуляции восходящего сообщения (RECEIVE_DELAY1 и RECEIVE_DELAY2 определены в 9.1.8). Отношение между скоростью передачи данных в восходящей линии связи и скоростью передачи нисходящих данных в окне приема RX1 является региональным параметром и определено в 9.1.7. По умолчанию, скорость передачи нисходящего сообщения в первом окне приема RX1 равна скорости передачи данных, использованной при передаче последнего восходящего сообщения.
6.1.2.2 Канал, скорость передачи данных и время открытия второго окна приема
Второе окно приема RX2 использует фиксировано заданные частоту приема и скорость передачи данных и открывается с задержкой RECEIVE_DELAY2 секунд (+/-20 микросекунд) после окончания модуляции восходящего сообщения (RECEIVE_DELAY1 и RECEIVE_DELAY2 определены в 9.1.8). Частота и скорость передачи данных, используемые в окне RX2, могут быть изменены с помощью MAC команд (см. 6.3). Значения частоты и скорости передачи данных по умолчанию являются региональными параметрами и указаны в 9.1.8.
6.1.2.3 Длительность окон приема
Длина окна приема должна быть не менее времени, необходимого радиоприемнику оконечного устройства для эффективного распознавания преамбулы нисходящего сообщения.
6.1.2.4 Активность приемника во время окна приема
Если поле "Преамбула" (Preamble) обнаружено во время одного из окон приема, то радиоприемник остается активным до окончания демодуляции нисходящего сообщения. Если сообщение распознано и затем демодулировано в пределах первого окна приема RX1, и кадр был адресован этому оконечному устройству после проверки адреса и MIC, то оконечное устройство не должно открывать второе окно приема RX2.
6.1.2.5 Отправка сообщения на оконечное устройство
Если необходимо передать оконечному устройству нисходящее сообщение, то сервер сети должен инициировать передачу точно в начале хотя бы одного из двух окон приема. Если нисходящее сообщение передается в течение обоих окон, то должны передаваться идентичные пакеты в каждое окно.
6.1.2.6 Примечание об окнах приема
Оконечное устройство не должно передавать следующее восходящее сообщение до того, как получит нисходящее сообщение в первом или втором окне приема, открытых по факту предыдущей передачи, или пока не закроется второе окно приема, открытое по факту предыдущей передачи.
6.1.2.7 Прием или передача по другим протоколам
Оконечное устройство может принимать или передавать данные по другим протоколам в свободные промежутки времени между передачей по протоколу LoRaWAN RU и окнами приема RX1/RX2 до тех пор, пока устройство не нарушает региональных регуляторных ограничений и требований протокола LoRaWAN RU.
6.2 Формат сообщений на МАС-уровне
Структура восходящего радиосообщения на физическом уровне представлена на рисунке 3.
 |
Рисунок 3 - Структура восходящего радиосообщения на физическом уровне
Структура нисходящего радиосообщения на физическом уровне представлена на рисунке 4.
 |
Рисунок 4 - Структура нисходящего радиосообщения на физическом уровне
Структура восходящего радиосообщения с запросом на присоединение к сети представлена на рисунке 5.
 |
Рисунок 5 - Структура восходящего радиосообщения с запросом на присоединение к сети
Структура нисходящего радиосообщения с подтверждением о присоединении к сети представлена на рисунке 6.
 |
Рисунок 6 - Структура нисходящего радиосообщения с подтверждением о присоединении к сети
Преамбула (Preamble) имеет длину 8 символов ЛЧМ и предназначена синхронизации приемного устройства перед демодулированием радиосообщения.
В радиосообщениях используется режим явного заголовка радиопакета, в который включены физический заголовок (PHDR) плюс Контрольная сумма физического заголовка (PHDR_CRC).
В PHDR передается: длина поля "Данные" (PHYPayload) в байтах, масштаб кода исправления ошибок, и наличие/отсутствие поля "Циклическая контрольная сумма" (CRC).
Циклическая контрольная сумма (CRC) имеет длину 2 байта и предназначена для контроля целостности поля "Данные" (PHYPayload).
Поле "Данные" (PHYPayload), имеет один из следующих форматов:
- в восходящем и нисходящем сообщениях, поле "Данные" (PHYPayload), начинается с поля "МАС-заголовок" (MHDR) размером 1 байт, затем передается поле "MAC-сообщение" (MACPayload), и заканчивается полем "Код целостности сообщения" (MIC) размером 4 байта.
Поле "МАС-заголовок" (MHDR) описано в 6.2.2.
Поле "MAC-сообщение" (MACPayload) описано в 6.2.3.
- в сообщении с запросом на присоединение к сети, поле "Данные" (PHYPayload) начинается с поля "МАС-заголовок" (MHDR) размером 1 байт, затем передается поле "Запрос на присоединение к сети" (Join-Request) или "Запрос на повторное присоединение к сети" (Rejoin-Request), и полем MIC размером 4 байта. Поле "Запрос на присоединение к сети" (Join-Request) описано в 6.4.2.2. Поле "Запрос на повторное присоединение к сети" (Rejoin-Request) описано в 6.4.2.4;
- в сообщении с подтверждением о присоединении к сети, поле "Данные" (PHYPayload) начинается с поля "МАС-заголовок" (MHDR) размером 1 байт, затем передается поле "Подтверждение присоединения к сети" (Join-Accept). При передаче "Подтверждение присоединения к сети" (Join-Accept) поле MIC включено в состав передаваемых данных и не передается отдельным полем. Поле "Подтверждение присоединения к сети" (Join-Accept) описано в 6.4.2.3.
6.2.1 Поле "Данные" (PHYPayload)
Структура поля "Данные" (PHYPayload) с указанием размера полей представлена на рисунке 7.
Размер | 1 | 7...M | 4 |
(в байтах) |
|
|
|
Данные | MAC-заголовок | MAC-сообщение | Код целостности |
(PHYPayload) | (MHDR) | (MACPayload) | сообщения (MIC) |
Рисунок 7 - Структура поля "Данные" (PHYPayload)
Максимальная длина (M) поля "МАС-сообщение" (MACPayload) зависит от скорости передачи сообщения и является региональным параметром (см. 9.1.6). При передаче подтверждения присоединения к сети длина МАС-сообщения (MACPayload) равна длине поля Join-Accept (см. 6.4.2.3), и поле MIC (4 байта) отсутствует.
6.2.2 Поле "MAC-заголовок" (MHDR)
Структура поля "MAC-заголовок" (MHDR) с указанием битов полей представлена на рисунке 8.
Биты | 7..5 | 4..2 | 1..0 |
MAC-заголовок | Тип сообщения | RFU | Основная версия формата |
(MHDR) | (MType) |
| данных (Major) |
Рисунок 8 - Структура поля "MAC-заголовок" (MHDR)
6.2.2.1 Поле "Тип сообщения" (MType)
Согласно настоящему стандарту, в протоколе LoRaWAN RU различают восемь различных типов MAC сообщений (таблица 1).
Таблица 1 - Типы MAC-сообщений
Значение поля | Описание |
000 | Запрос на присоединение (Join-Request) |
001 | Подтверждение присоединения (Join-Accept) |
010 | Неподтверждаемые восходящие данные (Unconfirmed Data Up) |
011 | Неподтверждаемые нисходящие данные (Unconfirmed Data Down) |
100 | Подтверждаемые восходящие данные (Confirmed Data Up) |
101 | Подтверждаемые нисходящие данные (Confirmed Data Down) |
110 | Запрос на повторное присоединение (Rejoin-Request) |
111 | Сообщения собственного протокола (Proprietary protocol messages) |
а) Сообщения "Запрос на присоединение" (Join-Request), "Подтверждение присоединения" (Join-Accept) и "Запрос на повторное присоединение" (Rejoin-Request)
Сообщения: "Запрос на присоединение" (Join-Request), "Подтверждение присоединения" (Join-Accept) и "Запрос на повторное присоединение" (Rejoin-Request) используются в процедуре активации по воздуху, описанной в 6.4.2, и в целях роуминга.
б) Сообщения с данными
Сообщения с данными используются для передачи MAC команд и данных приложений (прикладных данных), которые могут быть объединены вместе в одном сообщении. Подтвержденное сообщение с данными, требующее уведомления о получении сообщения, должно быть подтверждено получателем, в то время как неподтвержденное сообщение не требует отправки уведомления (подробная временная диаграмма работы механизма подтверждения приведена в разделе 8). Собственные типы сообщений могут использоваться для реализации нестандартных форматов сообщений, которые не совместимы со стандартными сообщениями, но должны использоваться для поддержки устройств (между устройствами), имеющими общее понимание собственных (нестандартных) расширений. Когда оконечное устройство или сетевой сервер получают сообщение неизвестного нестандартного формата, они должны его проигнорировать.
Целостность сообщения обеспечивается разными способами для разных типов сообщения, что определяется ниже для каждого типа сообщения.
6.2.2.2 Поле "Основная версия формата данных" (Major)
Значения поля "Основная версия формата данных" (Major) и их описание представлены в таблице 2.
Таблица 2 - Значения поля "Основная версия формата данных" (Major)
Значения поля | Описание |
00 | LoRaWAN RU |
01..11 | RFU |
Примечание - Значения поля "Основная версия формата данных" (Major) определяют формат сообщений, которыми обмениваются в ходе процедуры присоединения к сети (активации) (см. 6.4.2), и первые четыре байта поля "MAC-сообщение" (MACPayload). Для каждой основной версии формата данных оконечные устройства могут реализовывать разные неосновные версии формата данных. Неосновная версия, используемая оконечным устройством, должна быть известна сетевому серверу до ее использования (например, как часть информации, персонализирующей устройство). Если устройство или сервер сети получают данные неизвестной или неподдерживаемой версии формата данных, то они должны быть проигнорированы.
6.2.3 Поле "MAC-сообщение" (MACPayload)
Структура поля "MAC-сообщение" (MACPayload) представлена на рисунке 9 и содержит поля "Заголовок MAC-сообщения" (FHDR), необязательное поле "Порт" (FPort) и необязательное поле "Прикладные данные" (FRMPayload).
Размер (в байтах) | 7…22 | 0…1 | 0...N |
MAC-сообщение | Заголовок MAC- | Порт (FPort) | Прикладные данные |
(MACPayload) | сообщения (FHDR) |
| (FRMPayload) |
Рисунок 9 - Структура поля "MAC-сообщение" (MACPayload)
Поле "Прикладные данные" (FRMPayload) имеет размер 0...N байт, определяемый согласно региональным параметрам 9.1.6.
Поле "Заголовок MAC-сообщения" (FHDR) предназначено для адресации оконечных устройств и описано в 6.2.З.1.
Поле "Порт" (FPort) предназначено для адресации поля "Прикладные данные" (FRMPayload) на уровне устройства и описано в 6.2.3.2.
Поле "Прикладные данные" (FRMPayload) предназначено для передачи данных по целевому назначению устройства.
Поле "MAC-сообщение" (MACPayload), состоящее только из поля "Заголовок MAC-сообщения" (FHDR), является корректным.
6.2.3.1 Поле "Заголовок MAC-сообщения" (FHDR)
Структура поля "Заголовок MAC-сообщения" (FHDR) с указанием размеров элементов представлена на рисунке 10.
Размер (в байтах) | 4 | 1 | 2 | 0..15 |
Заголовок MAC- | Короткий адрес | Управление | Счетчик | Параметры |
сообщения (FHDR) | оконечного устройства (DevAddr) | кадром (FCtrl) | кадров (FCnt) | кадра (FOpts) |
Рисунок 10 - Структура поля "Заголовок MAC-сообщения" (FHDR)
Для нисходящих сообщений поле "Управление кадром" (FCtrl) имеет структуру, указанную на рисунке 11.
Номер бита | 7 | 6 | 5 | 4 | [3..0] |
Управление кадром (FCtrl) | Адаптивная скорость передачи данных (ADR) | RFU | Получение подтверждения сообщения (ACK) | Отложенные кадры (FPending) | Длина параметров кадра (FOptsLen) |
Рисунок 11 - Структура поля "Управление кадром" (FCtrl) для нисходящих сообщений
Для восходящих сообщений поле "Управление кадром" (FCtrl) имеет структуру, указанную на рисунке 12.
Номер бита | 7 | 6 | 5 | 4 | [3..0] |
Управление кадром (FCtrl) | Адаптивная скорость передачи данных (ADR) | Запрос подтверждения адаптивной скорости передачи данных (ADRACKReq) | Получение подтверждения сообщения (ACK) | RFU | Длина параметров кадра (FOptsLen) |
Рисунок 12 - Структура поля "Управление кадром" (FCtrl) для восходящих сообщений
а) Адаптивное управление скоростью передачи данных (поля "Адаптивная скорость передачи данных" (ADR), "Запрос подтверждения адаптивной скорости передачи данных (ADRACKReq))
Сеть LoRaWAN RU позволяет оконечным устройствам индивидуально настраивать любые из допустимых скоростей передач данных и выходную мощность передатчика. Эта особенность используется в протоколе LoRaWAN RU для адаптации и оптимизации скорости передачи данных и выходной мощности передатчика стационарных и малоподвижных оконечных устройств. Для указания данного свойства используется поле "Адаптивная скорость передачи данных" (ADR) и в этом случае сеть будет оптимизирована для использования самой быстрой возможной скорости передачи данных.
Адаптивное управление скоростью передачи данных становится невозможным, когда затухание сигнала в радио канале быстро и постоянно меняется. Когда сетевой сервер не в состоянии управлять скоростью передачи данных устройства, управление должно осуществляться на уровне приложения оконечного устройства. В этом случае рекомендуется использовать различные скорости передачи данных. Уровень приложения должен всегда минимизировать общее эфирное время с учетом состояния сети.
Если бит поля "Адаптивная скорость передачи данных" (ADR) восходящего сообщения установлен, то сеть будет управлять скоростью передачи данных и выходной мощностью передатчика оконечного устройства через соответствующие MAC команды. Если бит поля "Адаптивная скорость передачи данных" (ADR) не установлен, то сеть не будет управлять скоростью передачи данных и выходной мощностью передатчика оконечных устройств независимо от качества принимаемого сигнала. Дополнительно, с целью снижения количества потерянных пакетов, сервер сети может посылать команды, изменяющие маску канала или количество повторений для каждого восходящего сообщения.
Если бит поля "Адаптивная скорость передачи данных" (ADR) нисходящего сообщения установлен, то он информирует оконечное устройство, что сетевой сервер может посылать ADR-команды. Оконечное устройство может устанавливать/снимать бит поля "Адаптивная скорость передачи данных" (ADR) восходящего сообщения.
Если бит поля "Адаптивная скорость передачи данных" (ADR) нисходящего сообщения не установлен, то для оконечного устройства это означает, что из-за быстрых изменений в радиоканале сеть временно не может оценить лучшую скорость передачи данных. В этом случае у устройства есть следующий выбор:
- сбросить бит поля "Адаптивная скорость передачи данных" (ADR) восходящего сообщения и управлять своей скоростью передачи данных в восходящей линии связи с использованием собственной стратегии. Эта стратегия должна быть типовой для мобильных оконечных устройств;
- игнорировать (сохранить поля "Адаптивная скорость передачи данных" (ADR) восходящего сообщения установленным) и применить нормальную сниженную скорость передачи данных при отсутствии нисходящих ADR-команд. Эта стратегия должна быть типовой для неподвижных оконечных устройств.
Бит поля "Адаптивная скорость передачи данных" (ADR) может быть установлен и сброшен оконечным устройством или сетью по запросу. Однако, по мере возможности, ADR-схема должна быть включена, чтобы увеличить время автономной работы оконечного устройства и увеличить производительность сети.
Примечание - В некоторых случаях мобильные оконечные устройства большую часть времени являются неподвижными. Поэтому, в зависимости от состояния мобильности, оконечное устройство может запросить сеть оптимизировать скорость передачи данных, используя бит поля "Адаптивная скорость передачи данных" (ADR) восходящего сообщения.
По умолчанию выходная мощность передатчика равна максимальной допустимой мощности передачи для устройства, с учетом ограничений, описанных в разделе 9. Устройство должно использовать этот уровень мощности, пока не будет запроса об уменьшении от сети через MAC команду LinkADRReq.
Если скорость передачи данных устройства оптимизирована сетью и превышает скорость передачи данных устройства по умолчанию или выходная мощность передатчика ниже чем по умолчанию, то устройство должно периодически проверять, что сеть по-прежнему получает восходящие пакеты. Каждый раз, как увеличивается счетчик восходящих кадров (для каждого нового восходящего сообщения при повторных передачах счетчик не увеличивается), устройство увеличивает значение счетчика ADR_ACK_CNT. После превышения счетчиком ADR_ACK_CNT (ADR_ACK_CNT>=ADR_ACK_LIMIT) порогового значения ADR_ACK_LIMIT восходящих сообщений без какого-либо ответа сервера сети, устройство устанавливает бит поля "Запрос подтверждения адаптивной скорости передачи данных" (ADRACKReq). Сервер сети должен отреагировать нисходящим кадром в течение следующих ADR_ACK_DELAY кадров (восходящих), любой полученный нисходящий пакет сбрасывает счетчик ADR_ACK_CNT восходящей линии связи. Бит поля "Подтверждение получения сообщения" (ACK) в нисходящем сообщении устанавливать не нужно, так как любой ответ в окно приема оконечного устройства указывает на то, что шлюз (базовая станция) все еще получает восходящие сообщения от этого устройства. Если ответ не будет получен в течение ближайших ADR_ACK_DELAY восходящих сообщений (т.е. после превышения количества восходящих сообщений, оставшихся без ответа со стороны сервера сети более чем ADR_ACK_LIMIT+ADR_ACK_DELAY), то устройство должно попытаться восстановить связь путем наращивания выходной мощности передатчика до значения по умолчанию, если это возможно, и затем переключиться на более низкую скорость передачи данных, что увеличивает дальность связи. Оконечное устройство должно продолжать снижать свою скорость передачи данных шаг за шагом, всякий раз при достижении ADR_ACK_DELAY. После того, как устройство достигло самой низкой скорости передачи данных, оно должно повторно включить все частотные каналы восходящей линии связи по умолчанию.
Бит поля "Запрос подтверждения адаптивной скорости передачи данных" (ADRACKReq) не должен быть установлен, если устройство использует скорость передачи данных и выходную мощность передатчика по умолчанию, потому что в этом случае никакие действия не могут быть предприняты для улучшения качества связи.
Примечания
1 Отсутствие необходимости немедленного ответа на запрос подтверждения ADR обеспечивает гибкость сети при оптимальном планировании своих передач по нисходящей линии связи.
2 При передаче по восходящей линии связи бит поля "Запрос подтверждения адаптивной скорости передачи данных" (ADRACKReq) устанавливается, если ADR_ACK_CNT>=ADR_ACK_LIMIT и текущая скорость передачи данных больше, чем определенная для устройства минимальная скорость передачи данных, или мощность передачи меньше, чем по умолчанию, или текущая маска канала использует только подмножество всех каналов по умолчанию. При других условиях он обнуляется.
В таблице 3 приведен пример обратной последовательности снижения скорости передачи данных при условии, что константы ADR_ACK_LIMIT=32 и ADR_ACK_DELAY=32.
Таблица 3 - Пример обратной последовательности снижения скорости передачи данных
Значение счетчика ADR_ACK_CNT | Поле "Запрос подтверждения адаптивной скорости передачи данных" (ADRACKReq) | Скорость передачи данных | Выходная мощность передатчика (дБм) | Маска канала |
От 0 до 63 | 0 | SF11 | 9 | Текущий список каналов |
От 64 до 95 | 1 | SF11 | 9 | Текущий список каналов |
От 96 до 127 | 1 | SF11 | 14 | Текущий список каналов |
От 128 до 159 | 1 | SF12 | 14 | Текущий список каналов |
Более 160 | 0 | SF12 | 14 | Все доступные каналы |
б) Поле "Подтверждение получения сообщения" (ACK) и процедура подтверждения
При получении сообщения, требующего уведомления получения данных, получатель должен ответить сообщением, в котором установлен бит поля "Подтверждение получения сообщения" (АСК). Если отправителем является оконечное устройство, сеть попытается отправить подтверждение, используя одно из окон приема, открытое оконечным устройством после операции отправки. Если отправителем является шлюз, оконечное устройство передает уведомление по своему усмотрению (см. примечание ниже).
Подтверждение отправляется только в ответ на последнее полученное сообщение и никогда не ретранслируется.
Примечание - Оконечному устройству разрешено насколько возможно упростить процедуру подтверждения и иметь несколько вариантов ее выполнения. Оконечное устройство может передавать явное (возможно пустое) сообщение с подтверждением получения данных сразу после получения сообщения с данными, требующее подтверждения получения. Кроме того, оконечное устройство может отложить передачу подтверждения, прикрепив его к следующему сообщению данных.
в) Процедура повторной передачи
Нисходящий кадр (требующий или не требующий подтверждения от оконечного устройства) не должен повторно отправляться сервером сети с использованием одного и того же счетчика значения нисходящих кадров. Если после отправки нисходящего сообщения, требующего подтверждения, сервер сети не получил от устройства уведомление о доставке, то сервер сети должен уведомить об этом сервер приложения. Сервер приложения принимает решение о целесообразности повторной передачи нисходящего сообщения, требующего подтверждения.
Восходящие кадры (требующие и не требующие подтверждения) передаются число раз, равное NbTrans (см. 6.3.3), за исключением, если получено корректное нисходящее сообщение в ходе одной следующей передачи. Параметр NbTrans может использоваться администратором сети, чтобы контролировать избыточность восходящих пакетов узла связи для получения заданного качества обслуживания. Оконечное устройство должно выполнять скачкообразное переключение частоты, между повторными передачами. После каждого повторения оно должно ждать, пока не закроется окно приема. Задержка между повторными передачами остается на усмотрение оконечного устройства и может быть различной для каждого оконечного устройства.
Устройство должно остановить любую дальнейшую ретрансляцию восходящих кадров, требующих подтверждения, если получен соответствующий нисходящий кадр с подтверждением.
Устройства класса C должны прекратить любую дальнейшую ретрансляцию восходящих кадров, когда корректное нисходящее сообщение получено в окно приема RX1.
Устройства класса A должны прекратить любую дальнейшую ретрансляцию восходящих кадров, когда корректное нисходящее сообщение получено в окно приема RX1 или RX2.
Если сервер сети получает один и тот же восходящий кадр более NbTrans раз, то это может быть признаком атаки на сервер или неисправности устройства. В этом случае сервер сети не должен обрабатывать избыточные кадры.
Примечание - Сервер сети, обнаружив атаку в виде повторных передач, может принять дополнительные меры, такие как уменьшение параметра NbTrans на 1 или удаление дублирующих восходящих кадров, принятых через один и тот же канал, или другие механизмы.
г) Поле "Отложенные кадры" (FPending), только для нисходящих сообщений
Поле "Отложенные кадры" (FPending) используется только в нисходящей линии связи и указывает на то, что сеть имеет данные, ожидающие своей отправки, и поэтому запрашивает оконечное устройство максимально быстро открыть еще одно окно приема посредством отправки другого восходящего сообщения.
Подробное использование поля "Отложенные кадры" (FPending) описано в 8.3.
д) Поле "Счетчик кадров" (FCnt)
Каждое оконечное устройство имеет три счетчика кадров, чтобы отслеживать и хранить число кадров данных, переданных в восходящую линию связи сетевому серверу (FCntUp), и отправленных в нисходящую линию связи сервером сети на оконечное устройство (AFCntDown и NFCntDown).
В нисходящем направлении существует две разных схемы счетчиков кадров:
- единая схема счетчика, в котором все порты используют один и тот же счетчик кадров AFCntDown=NFCntDown=FCntDown, когда оконечное устройство работает по спецификации LoRaWAN 1.0;
- схема с двумя счетчиками, в которой первый счетчик NFCntDown используется для MAC команд на порт 0, или когда поле FPort отсутствует. Второй счетчик AFCntDown используется для всех других портов, когда устройство работает по спецификации LoRaWAN 1.1.
В схеме с двумя счетчиками счетчик NFCntDown управляется сервером сети, а счетчик AFCntDown управляется сервером приложений.
Примечание - Спецификации LoRaWAN 1.0 и более ранние версии поддерживают только один счетчик FCntDown (общий по всем портам), и сетевой сервер должен обеспечить поддержку схемы для устройств, работающих по спецификации LoRaWAN с версией до 1.1.
Всякий раз, когда устройство с активацией по воздуху (OTAA, Over The Air Activation) успешно обрабатывает сообщение подтверждения присоединения (Join-Accept), счетчик кадров на устройстве (FCntUp) и счетчики кадров на стороне сети (NFCntDown и AFCntDown) для этого оконечного устройства сбрасываются до 0.
Устройства с активацией через персонализацию (АВР, Activation By Personalization) имеют свои счетчики кадров, которые инициализируются в 0 при изготовлении. На устройствах с активацией через персонализацию счетчики кадров не должны сбрасываться на протяжении времени жизни устройства. Если оконечное устройство подвергается отключению питания во время срока службы (например, замена аккумуляторной батареи), счетчики кадров должны сохраняться.
Впоследствии счетчик кадров FCntUp увеличивается с каждым восходящим сообщением. Счетчик кадров NFCntDown увеличивается с каждым нисходящим сообщением в случае, когда значение в поле "Порт" (FPort) равно нулю, или данное поле отсутствует. Счетчик кадров AFCntDown увеличивается с каждым нисходящим сообщением при значении поля "Порт" (FPort), отличном от нуля. На стороне получателя, соответствующий счетчик будет синхронизироваться с полученным значением при условии, что полученное значение было увеличено по сравнению с текущим значением счетчика и поле "Код целостности сообщения" (MIC) соответствует значению кода целостности сообщения, вычисленному локально с использованием соответствующего сетевого сеансового ключа. Счетчик FCnt не увеличивается при многократных передачах кадров, требующих и не требующих подтверждения получения (см. параметр NbTrans). Сетевой сервер должен отбрасывать прикладные данные из повторно принятых кадров и передавать серверу приложений только один экземпляр кадра.
Счетчики кадров имеют размерность 32 бита. В поле "Счетчик кадров" (FCnt) передаются только младшие 16 бит из 32-х битного счетчика кадров (т.е. от счетчика FCntUp для кадров данных, передаваемых в восходящую линию связи, и счетчика AFCntDown/NFCntDown для кадров данных, передаваемых по нисходящей линии).
Примечание - Порядок следования байт - little-endian.
Оконечное устройство не должно использовать те же значения счетчика данных FCntUp с одним и тем же сеансовым ключом приложения или сеансовым сетевым ключом, за исключением случаев ретрансляции одного и того же кадра с подтверждением или без подтверждения.
Оконечное устройство не должно обрабатывать любые повторные передачи нисходящих кадра. Последующие повторные передачи должны игнорироваться без обработки.
Примечания
1 Это означает, что устройство будет отправлять подтверждение единожды, только после приема нисходящего кадра, требующего подтверждения. Аналогично устройство будет генерировать только одно восходящее сообщение после приема кадра с установленным битом поля "Отложенные кадры" (FPending).
2 Поскольку поле "Счетчик кадров" (FCnt) несет только младшие 16 бит из 32-х бит счетчика кадров, сервер должен вычислить 16 старших битов счетчика кадров из наблюдений за трафиком.
е) Параметры кадра (поле "Длина параметров кадра" (FOptsLen) и поле "Параметры кадра" (FOpts))
Поле "Длина параметров кадра" (FOptsLen) в поле "Управление кадром" (FCtrl) указывает фактическую длину поля "Параметры кадра" (FOpts), включенного в кадр.
Поле "Параметры кадра" (FOpts) передает MAC команды длиной до 15 байт, которые присоединяются к кадру данных. Список МАС команд приведен в 6.3.
Если значение поля "Длина параметров кадра" (FOptsLen) равно нулю, то поле "Параметры кадра" (FOpts) должно отсутствовать. Если значение поля "Длина параметров кадра" (FOptsLen) отличается от нуля, т.е. если MAC команды присутствуют в поле "Параметры кадра" (FOpts), то не может быть использовано нулевое значение в поле "Порт" (FPort) (поле должно отсутствовать, или значение отличаться от нуля).
MAC команды не могут одновременно присутствовать в поле "Данные" (FRMPayload) и в поле "Параметры кадра" (FOpts). Если это произойдет, то устройство должно игнорировать кадр.
Если в заголовке кадра имеется поле "Параметры кадра" (FOpts), то поле "Параметры кадра" (FOpts) должно быть закодировано до того, как будет рассчитано значение поля "Код целостности сообщения" (MIC).
6.2.3.2 Поле "Порт" (FPort)
Если поле "Прикладные данные" (FRMPayload) не является пустым, то поле "Порт" (FPort) должно присутствовать. При наличии поля "Порт" (FPort) значение, равное 0, указывает, что поле "Прикладные данные" (FRMPayload) содержит только MAC команды, и любые полученные кадры в этом случае будут обработаны на уровне реализации LoRaWAN RU (список допустимых MAC команд представлен в 6.3). Значения поля "Порт" (FPort) в диапазоне от 1 до 223 (от 0х01 до 0xDF) выделены под приложения, и любые полученные кадры в этом случае должны быть доступны на уровне приложения. Значение поля "Порт" (FPort), равное 224, выделено под протокол испытаний LoRaWAN RU уровня MAC. Реализация LoRaWAN RU должна стирать любые запросы передачи от уровня приложения, где значение поля "Порт" (FPort) не входит в диапазон от 1 до 224.
Примечание - Значение поля "Порт" (FPort), равное 224, предназначено для сценариев беспроводных испытаний соответствия окончательной версии устройства MAC настоящей спецификации, без необходимости полагаться на определенные испытательные версии устройств для прикладных задач. Испытание не должно совпадать со штатными операциями, но реализация MAC уровня устройства должна быть точно той, как используется для обычного приложения.
Протокол испытания работает на прикладном уровне и определяется за рамками настоящего стандарта, так как он является протоколом прикладного уровня.
Значения поля "Порт" (FPort) в диапазоне от 225 до 255 (от 0xE1 до 0xFF) зарезервированы для будущих стандартизированных расширений приложений.
Размеры элементов поля "MAC-сообщение" (MACPayload) указаны на рисунке 13.
Размер (в байтах) | От 7 до 22 | 0 или 1 | От 0 до N |
MAC-сообщение | Заголовок MAC- | Порт (FPort) | Прикладные данные |
(MACPayload) | сообщения (FHDR) |
| (FRMPayload) |
Рисунок 13 - Размеры элементов поля "MAC-сообщение"
N - число байт прикладных данных. Допустимый диапазон N является региональным параметром и определяется в разделе 9. N должно быть равным или меньшим, чем:
где M - максимальная длина данных в поле "МАС-сообщение" (MACPayload).
6.3 МАС-команды
Набор MAC-команд предназначен для сетевого администрирования и может быть использован для обмена между сервером сети и оконечным устройством на MAC-уровне (таблица 4). Команды МАС-уровня не обрабатываются сервером приложений и приложением, запущенным на устройстве.
Один кадр данных может содержать любую последовательность MAC-команд, вставленную в поле "Параметры кадра" (FOpts) или отправленную в отдельном кадре данных, в поле "Прикладные данные" (FRMPayload) с значением поля "Порт" (FPort), равным 0.
MAC-команды, передаваемые в поле "Параметры кадра" (FOpts), отправляются в кодированном виде и не должны превышать 15 байт. MAC-команды, отправляемые в поле "Прикладные данные" (FRMPayload), всегда кодируются и их длина не должна превышать максимальную длину поля "Прикладные данные" (FRMPayload).
MAC-команда состоит из поля "Идентификатор команды" (CID) размером 1 байт и поля "Атрибуты команды" размером от 0 байт до 14 байт. Для некоторых команд поле "Атрибуты команды" может быть пустым.
MAC-команды со значениями идентификаторов команды (CID) от 0х01 до 0x7F предназначены для использования во всех сетях LoRaWAN RU.
Приемная сторона отвечает/подтверждает получение MAC-команд в том же порядке, как они передаются. Ответ для каждой MAC-команды последовательно добавляется в буфер. На все MAC-команды, полученные в одном кадре, ответы должны быть переданы в одном кадре (т.е. буфер, содержащий ответы на МАС-команды, должен быть отправлен в одном кадре). Если длина буфера с MAC-ответами больше, чем максимальная длина поля "Параметры кадра" (FOpts), устройство должно отправить буфер в поле "Прикладные данные" (FRMPayload) на порт 0. Если устройству надо отправить прикладные данные и MAC ответы, и они не помещаются в один кадр, то MAC ответы должны быть отправлены в первую очередь. Если длина буфера превышает максимальный используемый размер поля "Прикладные данные" (FRMPayload), устройство перед сборкой кадра должно уменьшить буфер до максимального размера поля "Прикладные данные" (FRMPayload). Поэтому ответы на последние MAC-команды могут быть неполными. В любом случае, полный список MAC команд выполняется, даже если буфер, содержащий MAC-ответы, должен быть обрезан. Сетевой сервер не должен генерировать последовательность MAC-команд, на которые оконечное устройство не может ответить одним восходящим кадром. Сетевой сервер должен вычислять максимальный размер поля "Прикладные данные" (FRMPayload) для ответов на MAC команды, следующим образом:
- если поле "Адаптивная скорость передачи данных" (ADR) последнего восходящего сообщения имеет значение 0, то необходимо устанавливать максимальный размер поля "Прикладные данные" (FRMPayload), соответствующий самой низкой скорости передачи данных;
- если поле "Адаптивная скорость передачи данных" (ADR) последнего восходящего сообщения имеет значение 1, то необходимо устанавливать максимальный размер поля "Прикладные данные" (FRMPayload) соответствующим скорости передачи данных, используемой устройством для передачи последнего восходящего сообщения.
Примечание - При получении обрезанного MAC-ответа сервер сети может ретранслировать MAC-команды, на которые не получил ответ.
Таблица 4 - MAC-команды
CID | Команда | Передается | Краткое описание | |
|
| оконечному устройству | базовой станции |
|
0x01 | ResetInd | x | - | Используются устройствами с активацией через персонализацию для индикации сброса и согласования версий протокола |
0x01 | ResetConf | - | x | Подтверждает команду ResetInd |
0x02 | LinkCheckReq | x | - | Используется оконечным устройством для проверки его подключения к сети |
0x02 | LinkCheckAns | - | x | Ответ на команду LinkCheckReq.
Содержит оценку мощности полученного сигнала, указывающую на качество приема оконечного устройства (устойчивость связи) |
0x03 | LinkADRReq | - | x | Запрашивает оконечное устройство изменить скорость передачи данных, мощность передачи, количество повторений или канал |
0x03 | LinkADRAns | x | - | Подтверждает команду LinkADRReq |
0x04 | DutyCycleReq | - | x | Устанавливает максимальное агрегированное значение рабочего цикла устройства на передачу |
0x04 | DutyCycleAns | x | - | Подтверждает команду DutyCycleReq |
0x05 | RXParamSetupReq | - | x | Устанавливает параметры окон приема |
0x05 | RXParamSetupAns | x | - | Подтверждает команду RXParamSetupReq |
0x06 | DevStatusReq | - | x | Запрашивает статус оконечного устройства |
0x06 | DevStatusAns | x | - | Возвращает статус (состояние) оконечного устройства, а именно уровень заряда его батареи и отношение сигнал/шум (оценка демодуляции) |
0x07 | NewChannelReq | - | x | Создает или изменяет определение радиоканала |
0x07 | NewChannelAns | x | - | Подтверждает команду NewChannelReq |
0x08 | RXTimingSetupReq | - | x | Устанавливает временные интервалы для окон приема |
0x08 | RXTimingSetupAns | x | - | Подтверждает команду RXTimingSetupReq |
0x09 | TxParamSetupReq | - | x | Используется сервером сети, чтобы установить максимально допустимое время задержки (dwell time) и максимальную эффективную изотропную мощность излучения (EIRP) оконечного устройства, на основе локальных соглашений и нормативных актов |
0x09 | TxParamSetupAns | x | - | Подтверждает команду TxParamSetupReq |
0x0A | DlChannelReq | - | x | Изменяет определение нисходящего радиоканала окна приема RX1 путем смещения частоты передачи нисходящей линии от частоты восходящей линии связи (т.е. создание асимметричного канала) |
0x0A | DlChannelAns | x | - | Подтверждает команду DlChannelReq |
0x0B | RekeyInd | x | - | Используется устройством с активацией по воздуху для оповещения об обновлении сеанса связи устройства с сервером сети (обновление ключей) |
0x0B | RekeyConf | - | x | Подтверждает команду RekeyInd |
0x0C | ADRParamSetupReq | - | x | Используется сервером сети для установки ADR_ACK_LIMT и ADR_ACK_DELAY параметров оконечного устройства |
0x0C | ADRParamSetupAns | x | - | Подтверждает команду ADRParamSetupReq |
0x0D | DeviceTimeReq | x | - | Используется оконечным устройством для запроса текущей даты и времени |
0x0D | DeviceTimeAns | - | x | Сеть отправляет ответ на запрос DeviceTimeReq |
0x0E | ForceRejoinReq | - | x | Посылается сетью для запроса немедленного повторного присоединения (Rejoin) устройства, дополнительно указывается количество и периодичность повторов |
0x0F | RejoinParamSetup Req | - | x | Используется сетью для установки периодичности отправки устройством запросов на повторное присоединение (Rejoin) |
0x0F | RejoinParamSetup Ans | x | - | Подтверждает команду RejoinParamSetupReq |
От 0x80 до 0xFF | Проприетарные команды | x | x | Зарезервировано для команд, действующих только в региональных сетях |
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.