Обзор технологии LoRa

Архитектура сетей LoRa

---

Сеть LoRaWAN состоит из следующих элементов: конечное устройство, шлюзы, сетевой сервер и сервер приложений.
Конечное устройство - предназначено для осуществления управляющих или измерительных функций. Содержит набор необходимых датчиков и управляющих элементов.

Шлюз – устройство, принимающее данные от конечных устройств с помощью радиоканала и передающее их в транзитную сеть. В качестве транзитной сети могут выступать сеть Ethernet, WiFi или сети подвижной радиотелефонной связи. Шлюз и конечные устройства образуют сетевую топологию типа звезда. Обычно данное устройство содержит многоканальные приёмопередатчики для обработки сигналов в нескольких каналах одновременно или даже, нескольких сигналов в одном канале. Соответственно, несколько таких устройств обеспечивает зону радиопокрытия сети и прозрачную двунаправленную передачу данных между конечными устройствами и сервером.

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

Сервер приложений - может удаленно контролировать работу конечных устройств и собирать необходимые данные с них.

Рис. 4.

В конечном итоге, LoRaWAN сеть имеет топологию звезда из звёзд, имеет конечные устройства, которые через шлюзы, образующие прозрачные мосты, общаются с центральным сервером сети. При таком подходе обычно предполагается, что шлюзами и центральным сервером владеет оператор сети, а конечными устройствами – абоненты. Абоненты имеют возможность прозрачной двунаправленной и защищенной передачи данных до конечных устройств.

Сильные и слабые стороны технологии

---

Преимущества LoRaWAN:
 -  Большая дальность передачи радиосигнала по сравнению с другими беспроводными технологиями, используемыми для телеметрии, достигает 10—15 км.
 -  Низкое энергопотребление у конечных устройств, благодаря минимальным затратам энергии на передачу небольшого пакета данных.
 -  Высокая проникающая способность радиосигнала в городской застройке при использовании частот субгигагерцового диапазона.
 -  Высокая масштабируемость сети на больших территориях.
 -  Отсутствие необходимости получения частотного разрешения и платы за радиочастотный спектр, вследствие использования нелицензируемых частот (ISM band).
Недостатки LoRaWAN:
 -  Относительно низкая пропускная способность, варьируется в зависимости от используемой технологии передачи данных на физическом уровне, составляет от нескольких сотен бит/с до нескольких десятков кбит/с.
 -  Задержка передачи данных от датчика до конечного приложения, связанная с временем передачи радиосигнала, может достигать от нескольких секунд до нескольких десятков секунд.
 -  Отсутствие единого стандарта, который определяет физический слой и управление доступом к среде для беспроводных LPWAN-сетей.
 -  Риски зашумленности спектра нелицензированного диапазона частот.
 -  Проприетарная технология модуляции LoRa, «закрытая» патентом Semetech.
 -  Ограничение мощности сигнала.

Радиоинтерфейс LoRa

---

Радиосигнал с линейной частотной модуляцией (ЛЦМ)

---

Физический радиоинтерфейс LoRa основан на использовании широкополосных радиосигналов с большой базой B, много большей единицы. Данный вид радиосигналов имеет две главные особенности:

• ширина спектра радиосигнала BW значительно больше скорости передачи данных R _b (BW >> R_b);
• корреляционная функция существенно уже корреляционной функции узкополосного радиосигнала с базой B ~1.

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

Широкополосный радиосигнал LoRa представляет собой сигнал с линейной частотной модуляцией (ЛЧМ) или CSS (Chirp Spread Spectrum). Частота CSS радиосигнала может как увеличиваться (up-chirp), так и уменьшаться (down-chirp). Математически ЛЧМ сигнал представляется в виде выражения:

и описывается следующими параметрами:

BW – ширина спектра радиосигнала;
     – центральная (несущая) частота радиосигнала;

 – нижняя частота радиосигнала;

 – верхняя частота радиосигнала;

SF – коэффициент расширения спектра (изменяется в диапазоне от 7 до 12);
T_sym = 2^SF/BW – длительность радиосигнала;
  – скорость изменения частоты радиосигнала;

B = BW•T_sym = 2^SF – база радиосигнала.

Здесь коэффициент расширения спектра (SF) определяет разрядность символа данных (в битах), передаваемого через радиоинтерфейс за время T_sym.
На Рис. 5 приведен вид ЛЧМ сигнала во временной области, а на Рис. 6 и Рис. 7 показан его спектр с BW=125кГц и базой равной 128 (SF=7) и 4096 (SF=12) соответственно.

Рис. 5:

Рис. 6:

Рис. 7:

Передатчики LoRa формируют CSS радиосигналы с шириной спектра (BW) 125, 250 или 500 кГц (однако проект регионального частотного диапазона для Российской Федерации, подразумевает использование только полосы 125кГц). При фиксированной ширине спектра радиосигнала BW изменение его базы осуществляется за счет изменения длительности T_sym и скорости изменения частоты (Рис. 8).

Рис. 8:

Синхронизация приемника и передатчика

---

Для успешного функционирования любой системы обмена информацией необходима взаимная синхронизация приемника и передатчика, позволяющая определить временные границы приема-передачи как целого блока данных (или кадра), так и единичных символов.
Технология LoRa использует асинхронный режим приема-передачи при котором передатчик может начать генерацию радиосигнала в любой момент времени. В этом случае требуется механизм, обеспечивающий синхронизацию приемника по сигналу от передатчика (аналог "старт-бита" протокола RS232). В качестве такого механизма используется преамбула, предшествующая каждому сеансу связи. Преамбула включает в себя последовательность символов, позволяющих приемнику обнаружить активность передатчика, определить используемый передатчиком коэффициент расширения спектра (SF) и выполнить символьную синхронизацию. Длительность преамбулы является конфигурируемой величиной и должна быть не менее, чем T₁+2•T₂, где T₁ определяет максимальное время нахождения приемника в состоянии "сна" (Sleep), T₂ – определяет время поиска приемником преамбулы (Рис. 9).

Рис. 9:

По завершении преамбулы следует слово синхронизации (Sync Word) и блок данных физического уровня. Длина слова синхронизации настраивается в диапазоне от 1 до 8 байт. Спецификацией LoRa определен ряд специфических значений Sync Word – 0x34 для публичных сетей (public networks), 0x12 – для частных сетей (private networks) и 0xC194C1 – для каналов с FSK модуляцией.
На Рис. 10 приведена общая структура кадра, обеспечивающего передачу одного блока данных.

Рис. 10:

Детектирование CSS сигнала

---

Механизм функционирования детектора преамбулы основан на использовании согласованного фильтра (СФ), чья импульсная характеристика комплексно сопряжена с CSS радиосигналом в частотной области и имеет зеркальное отображение его во времени:

Принцип передачи символов информации блока данных физического уровня (PHY DATA UNIT) посредством широкополосного радиосигнала LoRa заключается в частотном смещении  относительно опорного ЛЧМ радиосигнала , где k=0,1,2,…,2^SF – информационный символ, размерностью SF бит (Рис. 11):

Рис. 11:

Пример зависимости частоты радиосигнала от времени для LoRa кадра показан на Рис. 12.

Рис. 12:

Возможная схема приемника сигнала LoRa, переносящего блок данных физического уровня, показана на Рис. 13.

Рис. 13:

Здесь:

  – эталонный ЛЧМ сигнал,

– аддитивный белый Гаусовский шум,

Де-chirped сигнал:

Рис. 14:

Рис. 15:

Отбросив в выражении для y(t) вторые слагаемые в фигурных скобках (как высокочастотные составляющие):

на выходе блока преобразования Фурье (FFT⁺) получаем следующий комплексный сигнал:

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

Рис. 16:

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

Следовательно,

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

Рис. 17:

Рис. 18:

Наконец определяем значение декодированного приемником информационного символа k.
Для этого находим частоту , при которой функция принятия решения принимает максимальное значение ():

Ключевой особенностью радиоинтерфейса LoRa (как уже упоминалось выше) является его высокая помехоустойчивость. Рисунки ниже демонстрируют функционирование описанного детектора сигнала LoRa в условиях аддитивного белого гаусовского шума (отношение сигнал/шум SNR=0dB). А в Табл. 14 приведены результаты моделирования в среде Matlab работы детектора при различных отношениях сигнал/шум и коэффициентах расширения спектра.

Рис. 19:

Рис. 20:

Табл. 14 – "Ошибка детектирования"

SNR/SF	SF7	SF8	SF9	SF10	SF11	SF12
0 дБ	0,9%	0,5%	0,2%	0,1%	0,1%	0,0%
-3 дБ	0,9%	0,6%	0,2%	0,1%	0,1%	0,0%
-6 дБ	2,0%	0,6%	0,2%	0,1%	0,0%	0,0%
-9 дБ	6,9%	1,5%	0,2%	0,1%	0,1%	0,0%
-12 дБ	18,0%	5,8%	1,3%	0,1%	0,0%	0,0%
-15 дБ	42,2%	17,6%	5,4%	0,6%	0,1%	0,0%
-18 дБ	68,9%	44,2%	18,0%	5,1%	1,1%	0,1%
-21 дБ	87,5%	73,7%	49,3%	18,9%	5,2%	0,8%

Характеристики радиоинтерфейса LoRa

---

В заключение отметим основные характеристики радиоинтерфейса LoRа:

• Сводные данные по различным региональным частотным диапазонам (Табл. 15).
• Данные по скорости передачи информации, рассчитанной по формуле R_b=SF•BW/2^SF , для различных скоростей кодирования (Табл. 16).
• Данные по допустимым скоростям передачи данных (Data Rate – DR) в соответствии с проектом регионального частотного диапазона, определенного для Российской Федерации RU 864-869MHz ISM Band (Табл. 17).
• Данные по суммарной агрегированной скорости одного радиоканала с учетом того, что шлюз LoRa имеет возможность в одном радиочастотном канале одновременно принимать сигналы от нескольких конечных устройств, передающих сигнал с различными коэффициентами расширения спектра (Табл. 18).
• Параметры регулировки мощности передатчика конечного устройства по команде от сетевого сервера (Табл. 19).

Табл. 15:

Табл. 16:

SF	7	8	9	10	11	12
W, kHz	125	125	125	125	125	125
Rb, CR=1 (без кодирования FEC), бит/с	6 835,94	3 906,25	2 197,27	1 220,70	671,39	366,21
Rb, CR=4/5, бит/с	5 468,75	3 125,00	1 757,81	976,56	537,11	292,97
Rb, CR=4/6, бит/с	4 557,29	2 604,17	1 464,84	813,80	447,59	244,14
Rb, CR=4/7, бит/с	3 906,25	2 232,14	1 255,58	697,54	383,65	209,26
Rb, CR=4/8, бит/с	3 417,97	1 953,13	1 098,63	610,35	335,69	183,11

Табл. 17:

Скорость передачи данных	Конфигурация (SF/W)	Скорость передачи данных на физическом уровне, бит/с
DR0	LoRa: SF12 / 125 кГц	183 – 293
DR1	LoRa: SF11 / 125 кГц	335 – 537
DR2	LoRa: SF10 / 125 кГц	610 – 976
DR3	LoRa: SF9 / 125 кГц	1 098 – 1 757
DR4	LoRa: SF8 / 125 кГц	1 953 – 3 125
DR5	LoRa: SF7 / 125 кГц	3 417 – 5 468
DR6	LoRa: SF7 / 250 кГц	6 835 – 10 937
DR7	FSK: 50 kbps	50 000
DR8..15	Резерв	Резерв

Табл. 18:

Rb, CR=1 (без кодирования FEC), бит/с	15 197,76
Rb, CR=4/5, бит/с	12 158,2
Rb, CR=4/6, бит/с	10 131,83
Rb, CR=4/7, бит/с	8 684,42
Rb, CR=4/8, бит/с	7 598,88

Табл. 19:

TXPower	Мощность передатчика
0	20 дБм
1	14 дБм
2	11 дБм
3	8 дБм
4	5 дБм
5	2 дБм
6-15	резерв

Классы устройств LoRa

---

Для решения различных задач и применений в сети LoRaWAN предусмотрено три класса конечных устройств:
Двунаправленные конечные устройства «класса А» (Bi-directional end-devices, Class A). Конечные устройства «класса А» позволяют организовать двунаправленный обмен. Причем связь может инициировать только конечное устройство, после чего выделяются два временных окна, в течение которых ожидается ответ от сети. Интервал передачи планируется конечным устройством на основе собственных потребностей в связи с небольшими случайными временными флуктуациями (протокол типа ALOHA). Конечные устройства «класса А» применяются в приложениях, где передача данных от сети возможна только как ответная реакция на получения данных от конечного устройства и требуется максимальное время работы от автономного источника питания.
Двунаправленные конечные устройства «класса Б» (Bi-directional end-devices, Class B) в дополнение к функциям устройств «класса А», открывают дополнительные окна приема по расписанию. Для того, чтобы открыть окно приема, конечное устройство синхронизируется по специальным сигналам от шлюза (по маякам – Beacon). Это позволяет сети знать время, когда конечное устройство готово принимать данные.
Двунаправленные конечные устройства «класса С» с максимальным приемным окном (Bi-directional end-devices, Class C). Конечные устройства «класса С» имеют почти непрерывно открытое окно приема. Приемное окно закрывается только на время передачи данных. Этот тип конечных устройств подходит для задач, когда необходимо получать большие объемы данных и не требуется длительная работа от автономного источника питания.

Базовый стек протоколов LoRa (Class A)

---

На Рис. 21 показан стек протоколов технологии LoRa.

Рис. 21:

Физический уровень (PHY Layer)

---

На физическом уровне обеспечивается негарантированная передача блоков данных между конечным устройством (End Node) и шлюзом LoRa (Gateway).
На стороне передающего устройства выполняется:
 -  прием блока данных от MAC уровня (PHYPayload);
 -  формирование физического заголовка пакета (PHDR + PHDR_CRC);
 -  кодирование физического заголовка пакета (PHDR + PHDR_CRC) с фиксированной скоростью 4/8;
 -  вычисление контрольной суммы блока полезных данных PHYPayload (CRC);
 -  кодирование блока полезных данных (PHYPayload + CRC) с предустановленной скоростью CR;
 -  передача по радиоканалу преамбулы;
 -  модуляция и передача по радиоканалу физического блока данных.
На стороне приемного устройства выполняется:
 -  обнаружение преамбулы и определение начала физического блока данных;
 -  демодуляция сигнала;
 -  декодирование физического заголовка пакета (PHDR + PHDR_CRC) и проверка его контрольной суммы;
 -  декодирование блока полезных данных (PHYPayload + CRC) и проверка его контрольной суммы;
 -  подтверждение принятых данных (для соответствующих типов сообщений);
 -  передача данных на MAC уровень.
На рисунках ниже приведены форматы физических блоков данных нисходящего (DL) и восходящего (UL) каналов:

Рис. 22:

Здесь:
1.  Preamble – преамбула, используемая для синхронизации приемника с входящим потоком и определения начала физического блока данных. Длина преамбулы для чипа Semtech SX1272 является программируемой.
2.  PHDR – физический заголовок пакета. Присутствует только при использовании явного режима (explicit mode) и содержит:
 -  длину полезной нагрузки в байтах;
 -  скорость кодирования;
 -  наличие в физическом блоке данных опционального поля CRC.
При использовании неявного режима (implicit mode) физический заголовок пакета не передается и устройства работают с предустановленными параметрами.
3.  PHDR_CRC – контрольная сумма поля PHDR.
4.  PHYPayload – полезная нагрузка (блок данных, полученный от уровня MAC / передаваемый на уровень MAC).
5.  CRC – контрольная сумма поля PHYPayload (опциональное поле).
При этом заголовок PHDR кодируется избыточным кодом с фиксированной скоростью 4/8; полезная нагрузка – с программируемой скоростью.

MAC уровень

---

На MAC уровне обеспечивается:
 -  передача блоков данных между конечным устройством и сетевым сервером (возможна передача сообщений с подтверждением и без подтверждения получения);
 -  шифрование (на уровне сети) полезной нагрузки, передаваемой между конечным устройством и приложением;
 -  управление выделением окон передачи данных в линии «вниз»;
 -  адаптация скорости передачи данных.
На рисунках ниже приведен формат сообщений MAC уровня:

Рис. 23:

1. MHDR – заголовок пакета MAC уровня. Содержит:
 -  Поле Major (2 бита) – определяет major часть версии формата сообщений процедуры активации по воздуху (OTA – over-the-air). Определена только одна версия (00 – "LoRaWAN R1").
 -  Поле MType – тип сообщения (3 бита). Определены шесть типов сообщений:

MType	Описание
000	Запрос процедуры активации по воздуху (OTA – over-the-air) – join request
001	Подтверждение процедуры активации по воздуху (OTA – over-the-air) – join accept
010	Передача данных без подтверждения "вверх" (unconfirmed data up)
011	Передача данных без подтверждения "вниз" (unconfirmed data down)
100	Передача данных с подтверждением "вверх" (confirmed data up)
101	Передача данных с подтверждением "вниз" (confirmed data down)
110	RFU
111	Для частных решений

2. MACPayload – фрейм данных.
Максимальная длина фрейма данных (M) определяется ограничениями физического уровня. Зависимость M от скорости передачи приведена в таблице ниже:

Скорость передачи	M, октет
0	59
1	59
2	59
3	123
4	230
5	230
6	230
7	230
8..15	Не определено

Фрейм данных (MACPayload) состоит из следующих подполей:
2.1. FHDR – заголовок фрейма. Включает в себя:
2.1.1. DevAddr – адрес конечного устройства.
2.1.2. FCtrl – октет управляющей информации фрейма в составе:
 -  ADR – флаг активации режима адаптации скорости.
 -  ADRACKReq – флаг запроса конечным устройством подтверждения факта получения сетью сообщений от данного устройства. Может устанавливаться в режиме адаптации скорости.
 -  ACK – флаг, индицирующий получение одной стороной (сетью или конечным устройством) сообщения от другой стороны. Используется при передаче данных, требующих подтверждения (MType=100 / 101). Не устанавливается для подтверждения получения сообщений в рамках процедуры адаптации скорости.
 -  FPending (только в DL канале) – флаг, индицирующий наличие запроса со стороны сети на необходимость передачи конечному устройству дополнительных данных сверх объема, который может быть передан в рамках окна передачи.
 -  CLASS-B (только в UL канале) – флаг, индицирующий, что конечное устройство переключено в режим "класс B".
 -  FOptLen – актуальный размер поля опций FOpt заголовка MAC уровня.
2.1.3.  FCnt – номер фрейма.
Конечное устройство и сетевой сервер после процедуры активации по воздуху (OTA – over-the-air) (join accept) инициализируют два счетчика – счетчик кол-ва переданных фреймов и счетчик кол-ва принятых фреймов (FCntUp/FCntDown). Спецификацией допускается использование 16-ти и 32-х битных счетчиков. При передаче сообщения встречной стороне конечное устройство / сетевой сервер указывают номер передаваемого фрейма (в поле FCnt заголовка MAC уровня). При этом, учитывая, что поле FCnt имеет разрядность 16 бит, при использовании 32-х битных счетчиков старшие 16 бит не передаются. При получении каждого нового сообщения принимающая сторона (конечное устройство / сетевой сервер) сравнивает поле FCnt со значением внутреннего счетчика принятых фреймов (FCntUp/FCntDown). Если разница превышает величину MAX_FCNT_GAP, принимается решение о значительном кол-ве потерянных пакетов.
2.1.4.  FOpt – опциональные данные фрейма (до 15-ти октетов). Используются для передачи MAC команд. При этом MAC команды могут отправляться как в поле FOpt (в этом случае FOptLen > 0, FPort > 0), так и в поле полезной нагрузки фрейма FRMPayload (в этом случае FOptLen = 0, FPort = 0).
2.2.  FPort – номер порта фрейма.
 -  значение 0 означает, что поле полезной нагрузки фрейма (FRMPayload) содержит MAC команду (см. п 2.1.4);
 -  значения 1..223 определяются уровнем приложений (application specific);
 -  значения 224-225 зарезервированы для будущего использования.
2.3.  FRMPayload – полезная нагрузка фрейма. Переносит данные между конечным устройством (End Node) и целевым приложением (Application). Содержимое поля FRMPayload шифруется стандарту AES либо на уровне приложения (с использованием ключа AppSKey), либо на уровне сетевого сервера (с использованием ключа NwkSKey). Оба ключа имеют длину 128бит.
3. MIC – код контроля целостности. Вычисляется по всем полям сообщения на основе алгоритма AES128 и секретного ключа NwkSKey.

Окна приема информации

---

Для устройств класса "A" после завершения каждого сеанса передачи данных конечным устройством (в линии «вверх») открываются два коротких временных окна, в течении которых конечное устройство может принять данные от сети (в линии «вниз»). При этом на протяжении длительности окон приема передача данных конечным оборудованием запрещена.
Для передачи данных шлюзом LoRa в первом временном окне (RX1) используются те же параметры передачи (включая номер частотного канала и скорость передачи данных), которые использовались для передачи данных конечным устройством.
Для передачи данных шлюзом LoRa во втором временном окне (RX2) используются предустановленные параметры передачи (включая номер частотного канала и скорость передачи данных).
Длительность временного окна предустанавливается и должна быть достаточной для приема преамбулы. Если сети требуется передать конечному устройству (End Node) больше информации, чем может быть передано в рамках одного окна приёма (receive window), LoRa gateway (шлюз) запрашивает End Node выделение ему дополнительного окна, путём установки бита FPending заголовка MAC уровня. В этом случае End Node должен выполнить передачу up-link сообщения (в т.ч. пустого, если отсутствуют полезные данные для передачи) по окончании которого и будут открыты дополнительные окна для получения данных от сети.

Рис. 24:

Подтверждение получения сообщений

---

Технология LoRa определяет два типа сообщений – сообщения, требующее подтверждения получения и сообщения без подтверждения. Тип сообщения - Confirmed (UL/DL) / Unconfirmed (UL/DL), определяется значением поля MType (MessageType) заголовка MAC уровня.
Если отправителем сообщения, требующего подтверждения, является конечное устройство (End Node), то сеть подтверждает получение такого сообщения внутри окон приёма, открытых конечным устройством сразу после сеанса передачи.
Если отправителем сообщения, требующего подтверждения, является сеть (LoRa gateway - шлюз), то момент передачи подтверждения определяется конечным устройством (End Node). Подтверждение может быть послано немедленно (в т.ч. в составе пустого сообщения), что упрощает логику функционирования End Node, либо в составе очередного сообщения, несущего полезную нагрузку, что сокращает загрузку радиоканала.
В любом случае, подтверждается всегда только последнее полученное сообщение. Сообщение, являющееся подтверждением, характеризуется установленным битом ACK заголовка MAC уровня. Повторная передача подтверждений не предусмотрена.
Необходимость повторной передачи неподтвержденных сообщений (либо его удаление), а также моменты передачи и кол-во повторов определяется логикой функционирования сетевого сервера и конечного устройства соответственно. При каждой повторной передаче возможно понижение скорости потока данных (dara rate), что повышает помехозащищеность. Также предусмотрена возможность провижининга параметров повторной передачи в конечные устройства со стороны сети.
В случае неполучения сетевым сервером предустановленного числа подтверждений от конечного устройства, данное конечное устройство может быть промаркировано как недоступное (unreachable) вплоть до получения от него любого первого входящего сообщения.

Адаптивная скорость передачи (Adaptive Data Rate – ADR)

---

В технологии LoRa предусмотрены механизмы адаптации скорости передачи данных конечных устройств с тем, чтобы оптимизировать загрузку сети и обеспечить каждому конечному устройству возможность работы на максимальных скоростях, обеспечивающих надлежащую помехоустойчивость в тех радиоусловиях, в которых данное устройство находится.
Адаптацию скорости передачи данных конечных устройств (End Node) выполняет сетевой сервер посредством соответствующих MAC команд. Решение о выборе той или иной скорости принимается на основании оценки качества принятого от End Node сигнала.
Механизмы адаптации скорости уместно использовать только на устройствах, местоположение которых постоянно и не меняется со временем (статичные устройства), т.к. для таких устройств и радиоусловия в целом будут достаточно стабильны от одного сеанса связи до другого. На мобильных устройствах, например, установленных на автомобилях, животных и пр. радиоусловия между сеансами связи изменяются непредсказуемо. Следовательно, на таких устройствах уместно использовать постоянные (установленные по дефолту) скорости передачи. Статичные устройства должны инициировать использование сетью режима адаптации посредством установки ADR бита заголовка MAC уровня.
Если конечное устройство использует скорость передачи данных выше предустановленной дефолтной скорости (в соответствии с командой MAC уровня, полученной от сетевого сервера), оно должно периодически контролировать факт получения сетью сообщений (даже при использовании режима передачи без подтверждения) в соответствии со следующей процедурой:
 -  конечное устройство (End Node) инкрементирует счетчик ADR_ACK_CNT при каждом переданном в восходящем канале сообщении (UL-Msg) и сбрасывает его при получении входящего сообщения по нисходящему каналу (DL-Msg) в окне приёма (receive window);
 -  при достижении счетчиком ADR_ACK_CNT порога ADR_ACK_LIMIT конечное устройство (посредством установки бита ADRACKReq) запрашивает сеть направить ему любой DL-Msg, подтвердив тем самым, что сообщения от данного конечного устройства достигают цели; подтверждение должно быть направлено в окне приёма одного из последующих UL-Msg (но не более, чем задано порогом ADR_ACK_DELAY);
 -  при отсутствии подтверждения конечное устройство снижает скорость передачи на один шаг;
 -  дальнейшее снижение скорости передачи на один шаг будет происходить после передачи каждых ADR_ACK_LIMIT UL-Msg до получения подтверждения, либо до достижения предустановленной дефолтной скорости.

Основные константы стека протоколов LoRaWAN

---

RECEIVE_DELAY1 (длительность временного окна приема RX1) – 1 сек.

RECEIVE_DELAY2 (длительность временного окна приема RX2) – 2 сек.

(=RECEIVE_DELAY1 + 1 сек.)

JOIN_ACCEPT_DELAY1 – 5 сек.

JOIN_ACCEPT_DELAY2 – 6 сек.

MAX_FCNT_GAP (максимальная разница значений внутреннего счетчика принятых пакетов и номера полученного фрейма – FCNT) – 16384.

ADR_ACK_LIMIT (в режиме адаптации скорости передачи – предельное кол-во фреймов, направив которые, конечное устройство запрашивает подтверждение со стороны сети) – 64.

ADR_ACK_DELAY (в режиме адаптации скорости – время ожидания подтверждения со стороны сети после запроса конечным устройством) – 32.

ACK_TIMEOUT – случайное значение в диапазоне от 1 до 3 сек

Команды MAC уровня

---

MAC команды могут отправляться как в поле FOpt (в этом случае FOptLen > 0, FPort > 0), так и в поле полезной нагрузки фрейма FRMPayload (в этом случае FOptLen = 0, FPort = 0). Команды MAC уровня приведены в Табл. 20.

Табл. 20:

CID	Команда	Передается		Описание
		EN	GW
0x02	LinkCheckReq	X		Используется конечным устройством для проверки подключения к сети.
0x02	LinkCheckAns		X	Отвечает на команду LinkCheckReq. Содержит оценку качество приема и кол-во шлюзов (LoRa Gateway), принявших команду LinkCheckReq от конечного устройства.
0x03	LinkADRReq		X	Запрашивает конечное устройство на изменение скорости передачи данных, мощности передачи, кол-ва повторения каждого сообщения и списка доступных для передачи "вверх" каналов.
0x03	LinkADRAns	X		Подтверждает прием LinkRateReq команды.
0x04	DutyCycleReq		X	Устанавливает максимальный совокупный рабочий цикл передачи конечного устройства. Изменяется в пределах от 1 (доступ без ограничений) до 2-15.
0x04	DutyCycleAns	X		Подтверждает прием DutyCycleReq команды.
0x05	RXParamSetupReq		X	Устанавливает параметры окон приема. Для RX1 – изменение скорости передачи в линии «вниз» по сравнению со скоростью передачи в линии «вверх». Для RX2 – частотный канал и изменение скорости передачи.
0x05	RXParamSetupAns	X		Подтверждает прием RXParamSetupReq команды.
0x06	DevStatusReq		X	Запрашивает состояние конечного устройства.
0x06	DevStatusAns	X		Возвращает состояние конечного устройства, а именно уровень заряда батареи и качество принимаемого сигнала.
0x07	NewChannelReq		X	Разрешает использование конечным устройством определенных радиоканалов, устанавливает их частоту (за исключением 3-х радиоканалов, установленных по умолчанию соответствующим региональным стандартом), а также допустимые границы скорости.
0x07	NewChannelAns	X		Подтверждает прием NewChannelReq команды
0x08	RXTimingSetupReq		X	Устанавливает временную задержку между окончанием передачи по линии «вверх» (UL) и открытием первого окна приема. Второе окно приема открывается через одну секунду после первого.
0x08	RXTimingSetupAns	X		Подтверждает прием RXTimingSetupReq команды.
0x80-0xFF	Proprietary	X	X	Зарезервировано для частных решений.

Безопасность в сетях LoRa

---

В сети LoRaWAN обеспечивается полная конфиденциальность данных при прохождении всех задействованных в цепочке устройств, при этом содержимое пакета доступно только отправителю (конечному устройству) и получателю (приложению), для которого оно предназначено. Сетевой сервер оперирует данными в зашифрованном виде, производит аутентификацию и проверяет целостность каждого пакета, но при этом не имеет доступа к полезной нагрузке, т.е. к информации от подключенных сенсоров (за исключением использования нерекомендуемых сценариев, в которых шифрование полезной нагрузки выполняет сетевой сервер с использованием ключа NwkSKey, а не сервер приложений; в дальнейшем данный сценарий не рассматривается).

Рис. 25:

В сети используются три вида ключей. Ключ аутентификации приложения AppKey известен только конечному устройству и серверу приложений. В случае если конечное устройство подключается к сети в режиме Over-The-Air-Activation (OTAA), ключ аутентификации приложения AppKey используется для вычисления сетевого ключа NwkSKey и ключа приложения AppSKey. В случае если конечное устройство подключается к сети в режиме Activation By Personalization (ABP), ключи NwkSKey и AppSKey предустановлены на конечном устройстве. Ключ NwkSKey известен сетевому серверу и конечному устройству и используется для проверки целостности каждого сообщения, используя Message Integrity Code (MIC). MIC вычисляется по алгоритму AES-CMAC, который аналогичен контрольной сумме, за исключением того, что он предотвращает умышленную подделку сообщений. Ключ приложения AppSKey используется для шифрования полезной нагрузки, используя алгоритм AES-128, между конечным устройством и сервером приложений.

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

---

Для подключения к сети LoRaWAN каждое конечное устройство должно быть идентифицировано и активировано в сети.
Предусмотрено два режима активации конечных устройств, активация по воздуху – Over-The-Air Activation (OTAA) и активация персонализацией – Activation by Personalization (ABP).

Активация по воздуху – Over-The-Air Activation (OTAA)
При активации по воздуху конечные устройства LoRa не привязаны жестко к какой-то конкретной сети. На конечных устройствах LoRa прописываются идентификатор устройства (DevEUI), индификатор приложения (AppEUI) и ключ приложения (AppKey). Конечное устройство при активации инициирует JOIN процедуру. Ключи шифрования (AppSKey и NwkSKey), необходимые для передачи информации, вычисляются самим конечным устройством. Данный метод активации обеспечивает высокий уровень безопасности и рекомендуется для использования.

Рис. 26:

Формат сообщений JOIN_REQUEST и JOIN_ACCEPT показан на рисунках ниже:

Здесь:
 - AppEUI - идентификатор приложения в адресном пространстве IEEE EUI64.
 - DevEUI - глобальный идентификатор устройства в адресном пространстве IEEE EUI64.
 - DevNonce - случайное число, генерируемое конечным устройством (используется при расчете NwkSKey и AppSKey).
 - AppNonce - случайное число, генерируемое сервером приложений (используется при расчете NwkSKey и AppSKey).
 - NetID - идентификатор сети, старшие 7 бит которого (31..25) соответствуют идентификатору NwkID, младшие 17 бит могут произвольно назначаться оператором.
 - DevAddr - адрес конечного устройства, старшие 7 бит которого соответствуют идентификатору NwkID, младшие 25 бит являются адресом конечного устройства в сети NwkAddr.
 - DLSettings - указывает на смещение скорости передачи данных в DL канале окна приема RX1 (относительно скорости передачи данных в UL канале) и скорость передачи данных в DL канале окна приема RX2.
 - RXDelay - задержка между завершением передачи данных в UL канале и открытием окна приема RX1.
 - CFList - список радиочастотных каналов с Freq Ch4 по Freq Ch8 (первые три канала являются обязательными и неизменными).

Формулы вычисления сетевого ключа NwkSKey и ключа приложения AppSKey приведены ниже:

Активация персонализацией – Activation by Personalization (ABP)
При активации персонализацией конечные устройства жестко прописываются для работы в конкретной сети оператора. Конечные устройства прошиваются с определенными сетевым ключом (NwkSKey) и ключом приложения (AppSKey). Данный метод активации (в связи с низким уровнем безопасности и сложностью реализации) не рекомендуется использовать для коммерческих сетей.

Рис. 27:

Особенности работы устройств Class-B

---

Передача данных в канале "вниз"

---

Функциональность класса "В" оптимизирована для мобильных и стационарных конечных устройств, работающих от автономных источников питания.
Конечные устройства осуществляют работу в классе "В" при наличии запросов на открытие приемных окон в фиксированные интервалы времени для возможности обеспечения отсылки сообщений в DL канале по требованию сервера.
Для сети с поддержкой конечных устройств класса "В" все шлюзы должны синхронно передавать сигнал маяка (beacon), обеспечивая отсчеты синхронизации для конечных устройств. Основываясь на этих отсчетах синхронизации, конечные устройства могут периодически открывать приемные окна (ping slots), которые могут использоваться сетевой инфраструктурой для инициации передачи по каналу DL. Инициированная сетью передача в DL канале в одном из приемных окон (ping slot), называется «ping». Шлюз, предназначенный для передачи данных в DL канале, выбирается сетевым сервером, основываясь на индикаторах качества сигнала конечного устройства в UL канале (в рамках последнего сеанса связи). В связи с этим, при перемещении конечного устройства и обнаружении изменений идентификатора в принимаемом маяке, конечное устройство должно отправить сообщение по UL каналу сетевому серверу, чтобы сервер обновил базу данных пути маршрутизации канала DL.

Все конечные устройства начинают работу как конечные устройства класса "А". Сервер приложений может принять решение о переключении конечного устройства в класс "В". Это происходит выполнением следующей процедуры:
1. В рамках окна приема класса "A" сервер приложений запрашивает конечное устройство на переключение в режим класса "В". Конечное устройство ищет маяк сети и возвращает значение BEACON_LOCKED если маяк сети был обнаружен и принят, либо значение BEACON_NOT_FOUND в противном случае. Для ускорения обнаружения маяка может использоваться команда «BeaconTimingReq», которая будет описана позднее.
2. Основываясь на мощности сигнала маяка и ограничениях по сроку службы батареи, сервер приложений выбирает скорость передачи данных и периодичность окон приема (ping slot), после чего запрашивает установку данных параметров на конечном устройстве.
3. При работе в режиме класса "В" конечное устройство устанавливает в единицу флаг CLASS-B (4-ый бит поля FCtrl уровня MAC) в каждом передаваемом кадре UL, указывая тем самым сетевому серверу, что устройство переключено в режим класса "В". Когда прием маяка проведен успешно, конечное устройство пересылает содержимое маяка приложению вместе с измеренным уровнем радиосигнала. Конечное устройство при приеме сообщения в DL канале учитывает максимально возможный сдвиг синхронизации (уход частоты) при планировании времени открытия приемного слота маяка и ping slot. Когда переданное в DL сообщение успешно демодулировано конечным устройством в течение ping slot, оно обрабатывается также, как сообщение DL, описанное в спецификации на устройства класса "А".
4. Мобильное конечное устройство должно периодически информировать сетевой сервер о собственном местоположении для обновления маршрута передачи сообщений в канале DL. Это достигается путем передачи обычного (возможно пустого) «неподтверждаемого» или «подтверждаемого» сообщения в канале UL. Этот функционал может быть реализован более эффективно, если приложение будет определять перемещение устройства на основе анализа содержания маяка. В данном случае, для предотвращения коллизий при передаче в канале UL, конечное устройство должно применять случайную задержку (как определено в разделе Требования к обновлению маршрута в канале DL сети) между приемом маяка и передачей сообщения.
5. Если маяк не принимался в течение определенного периода (определенного в разделе Увеличение времени работы в режиме потери маяка), синхронизация с сетью считается потерянной. В этом случае конечное устройство переключается обратно в режим класса "А" и, как следствие, сбрасывает в 0 флаг CLASS-B во всех сообщениях UL канала. Сервер приложений периодически может предпринимать попытки переключения устройства обратно в класс "В". Это приведет к перезапуску процесса, начиная с поиска сигнала маяка.

Следующая диаграмма показывает концепцию приемного слота маяка и ping slots.

Рис. 28:

В данном примере (ось времени не показана на рисунке) период посылки сигнала маяка составляет 128 секунд, конечное устройство открывает приемный ping slot каждые 32 секунды для возможности приема сообщения ping. Большую часть времени ping slot не используются сервером и, следовательно, приемное окно конечного устройства закрывается, как только радиоприемник понимает, что преамбула в радиоканале отсутствует. Если преамбула обнаруживается, радиоприемник остается включенным до тех пор, пока кадр DL не будет демодулирован. Далее МАС-уровень конечного устройства будет обрабатывать кадр, проверяя, что поле адреса соответствует адресу конечного устройства и что сообщение Message Integrity Check корректно, перед передачей ответа на сервер приложений.

Формат кадра Ping в DL канале (при работе в режиме класса "В")

Формат кадра физического уровня
В канале DL сообщение Ping использует тот же формат, что при работе в режиме класса "A", но может следовать другому плану частотного канала.

Индивидуальные и групповые МАС сообщения
Сообщения разделяются на «индивидуальные» и «многоадресные». Индивидуальные сообщения посылаются единичному конечному устройству, многоадресные сообщения рассылаются на несколько конечных устройств. Все устройства в многоадресной группе совместно используют один и тот же групповой адрес и связанный с ним ключ шифрования. Спецификация LoRaWAN для устройств класса "В" не определяет средства для удаленной настройки таких многоадресных групп или безопасного распределения материалов необходимых для группового ключа. Это выполняется либо через индивидуальную настройку каждого конечного устройства, либо через уровень приложения.

Формат индивидуального сообщения канального уровня
МАС Payload в индивидуальном сообщении Ping в DL канале использует формат, определенный в спецификации к классу "А".

Формат многоадресного сообщения канального уровня
Многоадресные кадры имеют в основном тот же формат, что и индивидуальные с некоторыми исключениями:
-    они не могут переносить МАС-команды ни в поле FOpt, ни в полезной нагрузке (с FPort=0), поскольку многоадресная рассылка в DL не имеет такой же надежности аутентификации, как индивидуальные кадры;
-    флаги ASK и ADRASKReq заголовка MAC уровня должны быть сброшены (=0);
-    поле MType должно нести значение Unconfirmed Data Down.
Наличие бита FPending указывает, что есть дополнительные данные для многоадресной рассылки. Если данный бит установлен, в следующем многоадресном приемном слоте будут передаваться данные. Если данный бит не установлен, в следующем слоте данные могут передавать или не передаваться. Данный бит может использоваться конечными устройствами для определения приоритетов для конфликтующих слотов приема.

Синхронизация временного интервала в DL канале для устройств класса "В"
Для корректной работы в режиме В, конечное устройство должно открывать приемные слоты в точно определенные моменты времени по отношению к инфраструктуре маяка.
Интервал между двумя последовательными маяками называется beacon period. Передача кадра маяка совмещена с началом интервала BEACON_RESERVED. Каждому маяку предшествует защитный временной интервал, в котором не может располагаться ping slot. Длина защитного интервала определяется временем в эфире самого длинного доступного кадра. Это сделано, чтобы гарантировать, что передача сообщения в канале DL, инициированная во время интервала ping slot, будет иметь достаточно времени для завершения передачи без пересечения с передачей маяка. В связи с этим, приемлемый временной интервал для ping slot располагается между окончанием зарезервированного временного интервала маяка (BEACON_RESERVED) и началом следующего защитного интервала маяка (BEACON_GUARD).

Рис. 29:

Табл. 21:

Beacon_period	128 секунд
Beacon_reserved	2,12 секунды
Beacon_guard	3,00 секунд
Beacon_window	122,88 секунды

Кадр маяка в радиоэфире на самом деле более короткий, чем зарезервированный временной интервал маяка (BEACON_RESERVED), чтобы в дальнейшем иметь возможность добавления широковещательного кадра сетевого управления.
Интервал окна маяка (beacon window) разделен на 2¹² = 4096 ping slot по 30 мс каждый, пронумерованных от 0 до 4095 (N – slot index).
Конечное устройство, использующее ping slot номер N, должно включить приемник точно через T_on секунд после начала маяка, где:
T_on=beacon_reserved+N•30мс
Последний ping slot начинается через beacon_reserved+4095•30мс=124 970мс после начала маяка или за 3 030 мс перед началом передачи следующего маяка.

Случайный выбор слота
Чтобы избежать систематических коллизий или вероятности прослушивания (over-hearing), индекс слота для конкретного конечного устройства случаен и меняется в каждом новом периоде маяка. Для этого используются следующие параметры:

DevAddr	32 битный сетевой адрес устройства (индивидуальный или многоадресный)
pingNb	Количество «ping slot» конечного устройства в периоде маяка. Оно должно быть целым числом степени двойки: pingNb=2k, где 1<=k<=7
pingPeriod	Период, в течение которого приемник устройства включен, выражается в количестве слотов: pingPeriod=212/pingNb
pingOffset	Случайное смещение вычисляется при каждом запуске маяка. Значение находится в диапазоне от 0 до (pingPeriod-1)
beaconTime	Время определяется в поле BCNPayload. Это время, непосредственно предшествующее кадру маяка.
slotLen	Длина одного ping slot = 30 мс

В каждый период маяка конечное устройство и сервер вычисляют новое псевдослучайное смещение для выравнивания приемного слота. Для определения псевдослучайного значения используется AES шифрование с фиксированным ключом из всех нулей:

Key = 16 x 0х00

Rand = aes128_encrypt(Key, beaconTime | DevAddr | pad16)

pingOffset=(Rand[0] + Rand[1]х256)modulo8

Слот, используемый для данного периода маяка (beacon period): pingOffset + N • pingPeriod, где N=[0:pingNb - 1]

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

Slot 1	Beacon_reserved + pingOffset x slotLen
Slot 2	Beacon_reserved + (pingOffset + pingPeriod) x slotLen
Slot 3	Beacon_reserved + (pingOffset + 2 x pingPeriod) x slotLen
…	…

Если конечное устройство обслуживает одновременно индивидуальный и один или более многоадресных слотов, данный расчет выполняется несколько раз в начале каждого нового периода маяка. Один раз для индивидуального адреса (адрес конечного устройства сети) и один раз для каждого многоадресного адреса (multicast group address).
В случае, когда многоадресный ping slot и индивидуальный ping slot пресекаются, и не могут обслуживаться приемником конечного устройства, конечное устройство должно предпочтительно слушать многоадресный слот. Если коллизия возникла между многоадресными приемными слотами, значение бита FPending предыдущего многоадресного кадра может использоваться для установки приоритетов.
Случайная схема распределения предотвращает систематические коллизии между индивидуальными и многоадресными слотами. Если коллизия возникает в течение периода одного маяка, то вряд ли она повторится в течение следующего периода.

Частотные каналы DL для индивидуальной и групповой передачи

EU 863-870MHz ISM Band
Все индивидуальные и многоадресные сообщения, направляемые конечным устройствам класса "В", используют один частотный канал, определенный МАС-командой «PingSlotChannelReq». Частота, установленная по умолчанию – 869,525MHz.

US 902-928MHz ISM Band
По умолчанию используется функция определения канала DL устройств класса "В" на основании значения поля времени последнего маяка (см. содержание Beacon Frame) и значения поля DevAddr.
Class B downlink channel=[DevAddr+целая часть((Beacon_Time)/(Beacon_Period))]  modulo 8,
где:
    Beacon_time – 32-х битное поле Time текущего периода маяка;
    Beacon_period – длина периода маяка (128 секунд);
    Целая часть (х) обозначает округление числа х вниз до целого значения;
    DevAddr – 32 битный сетевой адрес конечного устройства.
Канал DL устройств класса "В" последовательно совершает прыжки через 8 каналов в ISM диапазоне и все конечные устройства класса В равномерно распределяются между 8 каналами DL.
Если команда «PingSlotChannelReq» с корректным не нулевым аргументом используется для установки частоты DL класса В, тогда все последующие ping slot должны быть открыты на этой единой частоте независимо от последней частоты передачи маяка.
Если команда «PingSlotChannelReq» посылается с нулевым аргументом, конечным устройствам следует возобновить частотный план по умолчанию, при этом идентификатор ping slot устройств класса "В" будет перескакивать через 8 каналов.
Основная идея – позволить сетевым операторам, имеющим выделенный частотный ресурс, конфигурировать конечные устройства для использования одной лицензированной частоты для передачи DL сообщений устройствам класса "В", и сохранить возможность большого частотного разноса при использовании ISM диапазона.

Синхронизация с сетью

---

Получение и сопровождение радиомаяка
Перед переключением из класса "А" в класс "В" конечное устройство должно сначала получить один из сетевых маяков для выравнивания частоты синхронизации ВЗГ с сетью. После перехода конечного устройства в класс "В", устройство должно периодически искать и принимать маяки сети для компенсации девиации частоты ВЗГ относительно синхронизации сети.
Устройство класса В может быть временно не в состоянии принимать маяки (находится вне зоны действия шлюзов, наличие интерференции и т.д.). В данном случае конечное устройство должно постепенно расширять свое окно для приема маяка и ping slot’а, тем самым учитывая возможный уход частоты ВЗГ.

Примечание: Если в устройстве точность ВЗГ составляет +/- 10 ppm, девиация может достигать +/- 1.3 мс за каждый период маяка.

Минимальное время работы с потерей маяка
В случае потери маяка, в устройстве должна быть предусмотрена возможность работы в режиме класса "В" на протяжении 2-х часов (120 минут) после получения сигнала последнего маяка. Временная работа устройства класса "В" без маяка называется «beacon-less». При этом устройство опирается на собственный ВЗГ для сохранения синхронизации.
Во время работы в режиме «beacon-less» индивидуальные и многоадресные слоты, а также слоты приема маяков пропорционально увеличиваются в связи с возможным уходом частоты ВЗГ конечного устройства.

Рис. 30:

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

Минимизация девиации синхронизации
Конечные устройства могут использовать маяки (когда они доступны) для точной калибровки ВЗГ и соответственно уменьшать изначальную погрешность частоты генератора. Поскольку задающие генераторы имеют вполне определенный частотный сдвиг, зависящий от текущей температуры, использование датчика температуры позволяет обеспечить возможность дальнейшего уменьшения девиации частоты синхронизации.

Beaconing – Описание маяков (дополнительно для устройств класса В)

Физический уровень сообщения маяка
Кроме передачи сообщений между конечными устройствами и сетевыми серверами, все шлюзы принимают участие в обеспечении механизма временной синхронизации путем посылки маяков с жестко определенными интервалами, конфигурируемыми сетью (BEACON_INTERVAL). Все маяки передаются в радио пакетах в скрытом виде, то есть без физического заголовка LoRa:

PHY

Preamble

BCNPayload

Преамбула маяка начинается с 10 немодулированных символов (большего количества, чем по умолчанию в преамбуле). Это позволяет конечным устройствам применить поиск маяка методом, не требующим больших затрат энергии.
Полезная нагрузка маяка BCNPayload состоит из двух частей – общей сетевой части (network common part) и специфичной части LoRa-шлюза (gateway-specific part). При этом размер отдельных полей определяется региональной спецификой.

Размер (байт)	3	4	1/2	7		0/1	2
BCNPayload	Network common part			Gateway-specific part
	NetID	Time	CRC	GwSpecific		RFU	CRC
				InfoDesc	Info

Общая сетевая часть (Network common part) содержит:
 -  Идентификатор сети, посылающей маяк (NetID). Семь младших бит поля NetID называются NwkID и равны семи старшим битам короткого адреса конечного устройства. Соседние или повторяющиеся сети должны иметь различные NwkID.
 -  Метку времени (Time) в секундах начиная с 00:00:00 всемирного координированного времени (UTC), 1 января 1970 года.
 -  Циклический избыточный код (CRC), вычисляемый по полям NetID и Time в соответствии с рекомендацией IEEE 802.15.4-2003 (глава 7.2.1.8). Если применяется 8-битный CRC, то используются 8 младших битов (LSB) из рассчитанного CRC-16.

Специфичная часть LoRa-шлюза (Gateway-specific part) содержит:
-  Поле описания передаваемой специфичной информации LoRa-шлюза (InfoDesc – Information Description).
-  Специфичную информацию LoRa-шлюза (Info).
-  Неиспользуемый в отдельных региональных спецификациях байт информации (RFU), который в этом случае должен быть установлен в значение 0x00.
-  Циклический избыточный код (CRC), вычисляемый по полям GwSpecific и RFU.

InfoDesc	Значение
0	Координаты GPS с первой антенны шлюза
1	Координаты GPS со второй антенны шлюза
2	Координаты GPS с третьей антенны шлюза
3..127	RFU
128..255	Зарезервировано для пользовательских широковещательных специальных сетей

Для одной антенны с круговой диаграммой направленностью шлюза значение InfoDesc указывается равным «0» в случае передачи GPS координат в эфир. Для сайта с тремя секторными антеннами, первая антенна передает маяк с InfoDesc = 0, вторая антенна с InfoDesc = 1 и так далее.

В случае, если значение поля InfoDesc равно 0, 1 или 2, поле Info содержит кодированные GPS координаты, которые каждый сектор шлюза передает в поле маяка.

Широта и долгота (Lat и Lng соответственно) кодируют географическое положение шлюза следующим образом:
 -  Широта (север-юг) кодируется, используя 24-битное слово, где «-223» соответствует 90° южной широты (южный полюс), и «223» соответствует 90° северной широты (северный полюс). Экватору соответствует значение поля, равное «0».
 -  Долгота (восток-запад) кодируется, используя 24-битное слово, где «-223» соответствует 180° западной долготы и «223» соответствует 180° восточной долготы. Гринвичскому меридиану соответствует значение поля, равное «0».

Региональная специфика EU 863-870MHz ISM Band
Маяки передаются, используя следующие установки:

DR	3	Соответствует SF9, с полосой 125 MHz
CR	1	Скорость кодирования (coding rate) = 4/5
frequency	869,525 MHz	Рекомендованная частота. Операторы могут использовать различные частоты

Кадр маяка выглядит следующим образом:

Размер (байт)	3	4	1	7	2
BCNPayload	NetID	Time	CRC	GwSpecific	CRC

Пример: Корректный кадр маяка по региональной спецификации EU868:

Поле	NetID	Time	CRC	InfoDesc	Lat	Lon	CRC
Значение, Hex	CC BB AA	CC 02 00 00	7E	0	00 20 01	03 81 00	55 DE

Последовательность CRC-16 для полей NetID и Time будет равна 0xC87E, но в данном случае используются только младшие 8 бит.
По радиоэфиру байты передаются в следующей последовательности:
AA BB CC | 00 00 02 CC | 7E | 00 | 01 20 00 | 00 81 03 | DE 55

Региональная специфика US 902-928MHz ISM Band
Маяки передаются, используя следующие установки:

DR	10	Соответствует SF10, с полосой 500 MHz
CR	1	Скорость кодирования (coding rate) = 4/5
frequency	923,3 - 927,5 МГц с шагом 600 кГц	Передача маяка выполняется на том же самом канале что и обычный DL трафик как определено в спецификации для конечных устройств класса "А"

Канал DL для маяка определяется следующим образом:
Channel=[целая часть((beacon_time)/(beacon_period))]  modulo 8,

где:
 -  beacon_time – целое число из 4-х байт поля «Time» в кадре маяка;
 -  beacon_period – период повторения маяков, 128 секунд;
 -  Целая часть (х) обозначает округление числа х вниз до целого значения.

Пример: Первый маяк будет передаваться на частоте 923,3MHz, второй – 923,9, девятый маяк снова будет передаваться на частоте 923,3 MHz.

Номер канала маяка	Частота, MHz
0	923,3
1	923,9
2	924,5
3	925,1
4	925,7
5	926,3
6	926,9
7	927,5

Кадр маяка выглядит следующим образом:

Размер (байт)	3	4	2	7	1	2
BCNPayload	NetID	Time	CRC	GwSpecific	RFU	CRC

Пример: Корректный кадр маяка по региональной спецификации US900:

Поле	NetID	Time	CRC	InfoDesc	Lat	Lng	RFU	CRC
Значение, Hex	CC BB AA	CC 02 00 00	C8 7E	0	00 20 01	03 81 00	00	D4 50

По радиоэфиру байты передаются в следующей последовательности:
AA BB CC | 00 00 02 CC | 7E С8 | 00 | 01 20 00 | 00 81 03 | 00 | 50 D4
Стационарному конечному устройству в режиме класса "В" достаточно декодировать только поля общей сетевой части маяка (network common part).
Мобильное конечное устройство должно также декодировать поля специфичной части LoRa-шлюза (Gateway-specific part) маяка, чтобы иметь возможность информировать сетевой сервер всякий раз, когда конечное устройство перемещается из зоны действия одного шлюза в зону действия другого.

Примечание: Как уже упоминалось, все шлюзы посылают маяки в точно определенный момент времени (так называемая временная синхронизация), так что для network common part BCNPayload коллизии в радиоэфире для принимающего конечного устройства возникать не будут, даже если конечное устройство одновременно принимает маяки с нескольких шлюзов. Что касается gateway-specific part сообщения BCNPayload, коллизии возможны, но конечное устройство, расположенное рядом с более чем одним шлюзом, по-прежнему с высокой долей вероятности будет иметь возможность декодировать маяк с самым сильным уровнем сигнала.

Формирование точной синхронизации маяка (beaconing precise timing)
Маяк посылается каждые 128 секунд в моменты времени BT секунд после 00:00:00 UTC, 1 января 1970 года, где
B_T=k•128+NwkID+TBeaconDelay,
k – это наименьшее целое, для которого выполняется условие k•128+NwkID>T,
T – секунды, начиная с 00:00:00 UTC,1 января 1970 год.
TBeaconDelay – специфическая задержка сети, лежащая в пределах от 0 до 50 мс и одинаковая для всех шлюзов в одной сети.

Примечание: Т – это не системное время Unix. Аналогично времени GPS и в отличие от системного времени Unix, Т строго монотонно увеличивается и не корректируется координирующими секундами.

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

Требования к обновлению маршрута в канале DL сети
Когда сеть пытается установить соединение с конечным устройством, используя канал DL для устройств класса "В", сообщение передается в DL канале с ближайшего к конечному устройству шлюза, определяемому по последней передаче в UL канале конечного устройства. Следовательно, сетевому серверу требуется сохранять данные грубого местоположения для каждого конечного устройства класса "В".
Всякий раз, когда конечное устройство класса "В" перемещается и меняет шлюз, оно должно запросить сетевой сервер на обновление маршрута для канала DL. Это обновление может быть выполнено простой посылкой подтвержденного или неподтвержденного сообщения в UL канале, возможно без полезного сообщения.

Конечное устройство может использовать две основных стратегии:
 -  Систематическая периодическая отправка сообщений по каналу UL: самый простой метод, который не требует демодулировать поле «gateway specific» в сообщении маяка. Данный способ применим только для медленно перемещающихся или стационарных конечных устройств. Никаких требований, предъявляемых к периодической отправке сообщений по каналу UL, в данном случае нет.
 -  Отправка сообщения по каналу UL при смене соты: конечное устройство демодулирует поле «gateway specific» в сообщении маяка, определяет, что в демодулированном сообщении маяка изменился идентификатор (ID) соты и после этого отправляет сообщение по каналу UL. В данном случае конечное устройство должно обеспечить псевдослучайную задержку в диапазоне от 0 до 120 секунд между демодуляцией сообщения маяка и передачей сообщения в UL канале. Это требуется для гарантии того, что сразу после передачи маяка одновременно не будут передаваться UL сообщения о смене соты от множества конечных устройств класса "В".

Отсутствие сообщения от конечного устройства об изменении соты приводит к тому, что передача сообщений в канале DL для устройства класса "В" временно не будет организована. Сетевой сервер будет ожидать следующего сообщения в канале UL от конечного устройства для передачи трафика в DL канале.

Особенности работы устройств Class-C

---

Конечные устройства класса "С" – это устройства с постоянно открытым приемным окном в DL канале. Такие устройства используются в случаях, когда имеется достаточная емкость по питанию и в связи с этим не требуется ограничивать время работы приемника. Конечные устройства класса "С" не могут работать в режиме класса "В".
Конечные устройства класса "С" постоянно слушают радиоэфир с параметрами окна RX2, за исключением случаев, когда устройство передает данные или открывает приемное окно RX1 в соответствии с описанием класса "А". Таким образом, приемное окно с параметрами RX2 открывается конечным устройством:
 -  между окончанием передачи в UL канале и началом приемного окна RX1;
 -  после закрытия приемного окна RX1 и вплоть до начала передачи в UL канале.

Рис. 31:

Примечание: Спецификация LoRa не определяет конкретных сообщений конечного устройства для информирования сетевого сервера о том, что устройство работает в режиме класса "С". Только сервер приложений знает, что конечное устройство работает в классе "С" на основании прошедшей процедуры активации.

Групповая передача сообщений для устройств класса С

---

Так же, как и в классе "В", устройства класса "С" могут принимать многоадресные кадры от LoRa-шлюза. Многоадресный адрес, ключ сессии сети и ключ сессии приложения должны быть получены от сервера приложений. При этом аналогичные ограничения, как и для класса "В", применяются к устройствам класса "С":
 -  не разрешается применять МАС-команды ни в поле FOpt, ни в полезной нагрузке на порту 0, поскольку групповое сообщение не обладает той же надежностью аутентификации, что и индивидуальный кадр;
 -  биты ASK и ADRACKReq должны быть равны «0»;
 -  поле MType должно нести значение Uniformed Data Down;
 -  бит FPending показывает, что есть дополнительные групповые данные для отправки (учитывая, что устройство класса "С" сохраняет свой приемник включенным в течение длительного времени, бит FPending не вызывает какой-либо реакции конечного устройства).