ГОСТ Р 71168-2023. Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Спецификация LoRaWAN RU
6.2 Формат сообщений на MAC-уровне
Структура восходящего радиосообщения на физическом уровне приведена на рисунке 3.
Рисунок 3 - Структура восходящего радиосообщения
на физическом уровне
Структура нисходящего радиосообщения на физическом уровне приведена на рисунке 4.
Рисунок 4 - Структура нисходящего радиосообщения
на физическом уровне
Структура восходящего радиосообщения с запросом на присоединение к сети приведена на рисунке 5.
Рисунок 5 - Структура восходящего радиосообщения
с запросом на присоединение к сети
Структура нисходящего радиосообщения с подтверждением о присоединении к сети приведена на рисунке 6.
Рисунок 6 - Структура нисходящего радиосообщения
с подтверждением о присоединении к сети
Поле "Преамбула" (Preamble) имеет длину 8 символов ЛЧМ и предназначена для синхронизации приемного устройства перед демодулированием радиосообщения.
В радиосообщениях используется режим явного заголовка радиопакета, в который включены поле "Физический заголовок" (PHDR) и поле "Контрольная сумма физического заголовка" (PHDR_CRC).
В поле "Физический заголовок" (PHDR) передается: длина поля "Данные" (PHYPayload) в байтах, масштаб кода исправления ошибок и наличие/отсутствие поля "Циклическая контрольная сумма" (CRC).
Поле "Циклическая контрольная сумма" (CRC) имеет длину 2 байта и предназначена для контроля целостности поля "Данные" (PHYPayload).
Поле "Данные" (PHYPayload) имеет один из следующих форматов:
- в восходящем и нисходящем сообщениях поле "Данные" (PHYPayload) начинается с поля "MAC-заголовок" (MHDR) размером 1 байт, затем передается поле "MAC-сообщение" (MACPayload), и заканчивается полем "Код целостности сообщения" (MIC) размером 4 байта.
Поле "MAC-заголовок" (MHDR) описано в 6.2.2.
Поле "MAC-сообщение" (MACPayload) описано в 6.2.3;
- в сообщении с запросом на присоединение к сети поле "Данные" (PHYPayload) начинается с поля "MAC-заголовок" (MHDR) размером 1 байт, затем передается поле "Запрос на присоединение к сети" (Join-Request) или "Запрос на повторное присоединение к сети" (Rejoin-Request), и завершается полем "Код целостности сообщения" (MIC) размером 4 байта. Поле "Запрос на присоединение к сети" (Join-Request) описано в 6.4.2.2. Поле "Запрос на повторное присоединение к сети" (Rejoin-Request) описано в 6.4.2.4;
- в сообщении с подтверждением о присоединении к сети поле "Данные" (PHYPayload) начинается с поля "MAC-заголовок" (MHDR) размером 1 байт, затем передается поле "Подтверждение присоединения (переприсоединения) к сети" (Join-Accept). При передаче "Подтверждение присоединения (переприсоединения) к сети" (Join-Accept) поле "Код целостности сообщения" (MIC) включено в состав передаваемых данных и не передается отдельным полем. Поле "Подтверждение присоединения (переприсоединения) к сети" (Join-Accept) описано в 6.4.2.3.
6.2.1 Поле "Данные" (PHYPayload)
Структура поля "Данные" (PHYPayload) приведена на рисунке 7.
Размер (в байтах) | 1 | 7 ... M | 4 |
Данные (PHYPayload) | MAC-заголовок (MHDR) | MAC-сообщение (MACPayload) | Код целостности сообщения (MIC) |
Рисунок 7 - Структура поля "Данные" (PHYPayload)
Максимальная длина (M) поля "MAC-сообщение" (MACPayload) зависит от скорости передачи сообщения и является региональным параметром (см. 9.1.6). При передаче подтверждения присоединения к сети длина MAC-сообщения (MACPayload) равна длине поля "Подтверждение присоединения (переприсоединения) к сети" (Join-Accept) (см. 6.4.2.3) и поле "Код целостности сообщения" (MIC) отсутствует.
6.2.2 Поле "MAC-заголовок" (MHDR)
Структура поля "MAC-заголовок" (MHDR) с указанием битов полей приведена на рисунке 8.
Биты | 7 .. 5 | 4 .. 2 | 1 .. 0 |
MAC-заголовок (MHDR) | Тип сообщения (MType) | RFU | Основная версия формата данных (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-сообщение (MACPayload) | Заголовок MAC-сообщения (FHDR) | Порт (FPort) | Прикладные данные (FRMPayload) |
Рисунок 9 - Структура поля "MAC-сообщение" (MACPayload)
Поле "Прикладные данные" (FRMPayload) имеет размер 0 ... N байт, определяемый согласно региональным параметрам 9.1.6.
Поле "Заголовок MAC-сообщения" (FHDR) предназначено для адресации оконечных устройств и описано в 6.2.3.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) и процедура подтверждения
При получении сообщения, требующего уведомления о получении данных, получатель должен ответить сообщением, в котором установлено значение поля "Подтверждение получения сообщения" (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 v.1.0;
- схема с двумя счетчиками, в которой первый счетчик NFCntDown используется для MAC-команд на порт 0 или когда поле FPort отсутствует. Второй счетчик AFCntDown используется для всех других портов, когда устройство работает по спецификации LoRaWAN v.1.1.
В схеме с двумя счетчиками счетчик NFCntDown управляется сервером сети, а счетчик AFCntDown управляется сервером приложений.
Примечание - Спецификации LoRaWAN v.1.0 и более ранние версии поддерживают только один счетчик FCntDown (общий по всем портам), и сетевой сервер должен обеспечить поддержку схемы для устройств, работающих по спецификации LoRaWAN с версией до 1.1.
Всякий раз, когда устройство с активацией по воздуху (OTAA) успешно обрабатывает сообщение подтверждения присоединения (переприсоединения) к сети (Join-Accept), счетчик кадров на устройстве (FCntUp) и счетчики кадров на стороне сети (NFCntDown и AFCntDown) для этого оконечного устройства сбрасываются до 0.
Устройства с активацией через персонализацию (ABP, 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 байт, которые присоединяются к кадру данных. Список MAC-команд приведен в 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 (от 0x01 до 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-сообщение (MACPayload) | Заголовок MAC-сообщения (FHDR) | Порт (FPort) | Прикладные данные (FRMPayload) |
Рисунок 13 - Структура поля "MAC-сообщение" (MACPayload)
N - число байтов прикладных данных. Допустимый диапазон N является региональным параметром и определяется в разделе 9. N должно быть равным или меньшим, чем:
N <= M - 1 - (длина поля "Заголовок MAC-сообщения"
(FHDR) в байтах),
где M - максимальная длина данных в поле "MAC-сообщение" (MACPayload).
Подписаться на обновления