hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
зволяетдобиться этого,но не стесняйтесь экспериментировать сдру-					to
											m
	w Click
гими значениями в диапазоне от 7 до 12.	w			df-x chan
		w								o
		.							.c
			p					g
									e

Еслифункцияrfm9x.receive() ничегонеполучилавтечениезадан- ноговремени,онавозвращаетNone ,затеммывыводимсоответству- ющее сообщение на последовательную консоль и возвращаемся к на- чалуцикла.Еслимыполучаемпакет,топечатаемегонеобработанные байты и затем пытаемся декодировать их в ASCII . Часто пакет мо- жет содержать символы,не входящие в ASCII,из-за повреждения или шифрования,и для перехвата исключений у нас есть обработчик UnicodeError, иначе наша программа завершится с ошибкой. Наконец, мы выводим в консоль уровень принятого сигнала последнего полу- ченного сообщения, считывая регистр RSSI нашего чипа с помощью­ функции  rfm9x.rssi().

Если вы оставите работающую последовательную консоль PuT- TY, вы должны увидеть перехваченные сообщения, как показано на рис. 13.9.

Рис.13.9.Последовательная консоль в PuTTY показывает нам перехваченные сообщения LoRa с устройства CatWAN

Декодирование протокола LoRaWAN

В этом разделе мы рассмотрим беспроводной протокол LoRaWAN, который является протоколом верхнего уровня для LoRa. Чтобы луч- ше понять протокол, мы рекомендуем вам прочитать официальную спецификацию на сайте LoRa Alliance по адресу https://lora-alliance.org/ lorawan-for-developers/.

Формат пакета LoRaWAN

LoRaWAN определяетуровни модели OSI поверх LoRa (уровеньOSI 1). Онвосновномработаетнауровнеуправлениядоступомксредепере-

дачиданных (MediumAccess Control,MAC) (уровеньOSI 2),хотя вклю-

чаетнекоторые элементы сетевого уровня (уровеньOSI 3).Например, сетевой уровень охватывает такие задачи, как подключение узлов ксетямLoRaWAN(см.раздел«ПрисоединениексетямLoRaWAN»),как пакеты пересылаются и т.д.

Формат пакета LoRaWAN дополнительно делит сетевой уровень на уровни MAC и приложения. Эти слои показаны на рис. 13.10.

372  Глава 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m	Преамбула
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

PHDR PHDR_CRC PHYPayload

CRC

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

to

LoRa–

w Click

m

w

физический

w

df

n

o

.

.c

p

g

-x cha

e

уровень(OSI 1)

		MHDR	MACPayload	MIC			LoRaWAN–
							уровеньMAC
Сетевой
							(OSI 2)
уровень
(OSI 3)
			FHDR FPort FRMPayload			Уровень
						приложения

Рис.13.10.Формат пакета LoRaWAN

Чтобы понять, как взаимодействуют эти три уровня, вам сначала нужно понять принцип применения трех 128-битных ключей AES, которые использует LoRaWAN.NwkSKey –это сетевой сеансовый ключ, который узел и сетевой сервер используютдля вычисления и провер- ки кода целостности всех сообщений (Message Integrity Code, MIC), обеспечивая целостностьданных.AppSKey –это ключ сеанса приложе- ния,который конечное устройство и сервер приложений (можетбыть тем же объектом, что и сетевой сервер) используют для шифрования и дешифрования полезной нагрузки уровня приложения. AppKey (об- ратите внимание: в названии ключа нет буквы S) – это ключ прило- жения, известный узлу и серверу приложения и используемый для метода беспроводной активации (Over-the-Air Activation, OTAA), как описано в разделе «Присоединение к сетям LoRaWAN».

Физический уровень LoRa определяет радиоинтерфейс, схему мо- дуляции и дополнительный CRC для обнаружения ошибок. Он также несет полезную информацию для уровня MAC.Он состоит из следую­ щих частей:

zzпреамбулы – преамбулы радиопакета, которая содержит функ- цию синхронизации и определяетсхему модуляции пакета.Дли- тельность преамбулы обычно составляет 12,25 Т;

zzPHDR – заголовка физического уровня, который содержиттакую информацию, как длина полезной информации и наличие CRC полезной информации;

zzPHDR_CRC – CRC физического заголовка (PHDR). PHDR и PHDR_ CRC составляют в общей сложности 20 бит;

zzPHYPayload – полезной информации физического уровня, кото- рая содержит фрейм MAC;

zzCRC–необязательного 16-битного CRCдля PHYPayload.Сообще- ния, отправленные с сетевого сервера на узел, никогда не содер- жат это поле по причинам оптимизации производительности.

MAC-уровеньLoRaWANопределяеттипсообщенияLoRaWANиMIC, а также несет полезную информацию для уровня приложения выше.

Радио дальнего действия: LPWAN  373

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

hang

e

C

E

X

-

d

F

i

t

P

D

o

NOW!

r

BUY

Он состоит из следующих частей:

to

w

m

w Click

o

w

.

.c

zzMHDR–заголовкаMAC(MHDR),которыйопределяеттипсообще-

p

df

e

g

n

-x cha

ния(MType)форматафреймаиверсиюспецификацииLoRaWAN. Трехбитовый MType указывает,какой из шести различныхтипов

MAC-сообщений у нас есть: Join-Request, Join-Accept, непод-

твержденные данные «вверх/вниз» и подтвержденные данные «вверх/вниз». «Вверх» в этом случае относится к передаче дан- ных от узла к сетевому серверу, а «вниз» указывает на передачу данных в противоположном направлении;

zzMACPayload – полезной информации MAC, которая содержит фрейм уровня приложения. Для сообщений Join-Request (или ReJoin-Request) полезная информация MAC имеет свой соб- ственный формат и не несет типичной полезной информации прикладного уровня;

zzMIC–четырехбайтовогоMIC,которыйобеспечиваетцелостность данных и предотвращает подделку сообщения. Он рассчитыва- ется по всем полям сообщения (msg = MHDR | FHDR | FPort | FRM- Payload) с использованием NwkSKey.Имейте в виду,что в сообще- ниях Join-Request и Join-Accept мы вычисляем MIC по-разному, потому что это особый тип полезной информации MAC.

Уровень приложения содержит данные для конкретного приложе- ния и адрес конечного устройства (DevAddr (адрес конечного устрой- ства), который однозначно идентифицирует узел в текущей сети. Он состоит из следующих частей:

zzFHDR – заголовка кадра (FHDR), который содержит DevAddr, байт управления фреймом (FCtrl), двухбайтовый счетчик фреймов (FCnt) и от нуля до 15 байт параметров фрейма (FOpts). Обрати- те внимание, что FCnt увеличивается каждый раз при передаче сообщенияииспользуетсядляпредотвращенияатакповторного воспроизведения;

zzFPort – порта фрейма, используемого для определения того, со- держит ли сообщение только MAC-команды (например, запрос на присоединение) или данные, относящиеся к приложению;

zzFRMPayload – фактические данные (например, значение темпе- ратуры датчика). Эти данные зашифрованы с по­мощью AppSKey.

Присоединение к сетям LoRaWAN

Узлы могут присоединиться к сети LoRaWAN двумя способами: OTAA

и активацией спомощью­ персонализации (Activation by Personalization, ABP). В этом разделе мы обсудим оба метода.

Обратите внимание, что в сетевой архитектуре LoRaWAN сервер приложений может быть отдельным компонентом сервера сети, но для простоты мы будем предполагать, что один и тот же объект вы- полняет обе функции. Официальная спецификация LoRaWAN делает то же предположение.

374  Глава 13

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
OTAA					to
	w Click										m
	w
		w								o
		.							.c
			p					g
				df			n		e
В OTAA узлы следуют процедуре соединения, прежде чем смогут от-
					-x cha

правлять данные в сеть и сервер приложений. Рисунок 13.11 иллю- стрирует эту процедуру.

Сетевой сервер

Шлюз

Узел

Рис.13.11.Поток сообщений OTAA

Сначала узел LoRa отправляет запрос соединения , содержащий идентификатор приложения (AppEUI), идентификатор конечного устройства (DevEUI) и случайное значение из двух байтов (DevNonce). Сообщение подписано (но не зашифровано) с использованием ключа AES-128, специфичного для узла, называемого AppKey.

Узел вычисляет эту подпись – MIC, описанный в предыдущем раз- деле – следующим образом:

cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce) MIC = cmac[0..3]

Узел использует код аутентификации сообщения на основе шифра

(Cipher-based MessageAuthentication Code,CMAC),который представ-

ляет собой хеш-функцию с ключом, основанную на блочном шифре с симметричным ключом (в этом случае AES-128). Узел формирует сообщение для аутентификации путем объединения MHDR, AppEUI, DevEUI и DevNonce. Функция aes128_cmac генерирует 128-битный код аутентификации сообщения, и его первые четыре байта образуют MIC, потому что MIC может содержатьтолько четыре байта.

  ПРИМЕЧАНИЕ    Вычисление MIC отличается для сообщений с данны- ми(любоесообщение,кромесообщенияJoin-Request иJoin-Accept).До- полнительную информацию о CMAC можно найти в RFC4493.

Любой шлюз , который получает пакет Join-Request, пересылает его в свою сеть. Устройство шлюза не мешает передаче сообщения; оно только действует как ретранслятор.

Узел не отправляет AppKey в запросе на присоединение. Поскольку сетевой сервер знает AppKey,он может пересчитать MIC на основе по-

Радио дальнего действия: LPWAN  375

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

hang

e

C

E

X

-

d

F

t

D

i

r

P

NOW!

o

BUY

лученных значений MHDR, AppEUI,

DevEUI и DevNonce в сообщении. Если

to

m

w Click

w

w

df-x chan

o

у конечного устройства не было правильного ключа приложения,MIC

.

.c

p

g

e

в Join-Request не будетсовпадать с рассчитанным сервером,и сервер

не будет проверять устройство.

Если MIC совпадают, устройство считается действительным, и сер-

вер отправляет ответ Join-Accept , содержащий идентификатор

сети (NetID), DevAddr и одноразовое число (AppNonce), а также некото-

рые настройки сети,такие как список частотканаловдля сети.Сервер

шифрует Join-Accept с помощью­

AppKey. Сервер также вычисляет два

сеансовых ключа, NwkSKeyи AppSKey, следующим образом:

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)

Сервер вычисляет оба ключа с помощью­ AES-128 – шифрования конкатенации 0x01 (для NwkSKey) или 0x02 (для AppSKey), AppNonce, NetID, DevNonce и некоторого заполнения нулевых байтов, поэтому общая длина ключа кратна 16. В качестве ключа AES используется

AppKey.

Шлюз с самым сильным сигналом к устройству пересылает от- вет Join-Accept устройству . Затем узел  сохраняет NetID, DevAddr и настройки сети и использует AppNonce для генерации тех же клю- чей сеанса, NwkSKey и AppSKey, что и сетевой сервер, используя ту же формулу.С этого момента узел и сервер используютNwkSKey иAppSKey для проверки, шифрования и дешифрования данных, которыми об- мениваются.

ABP

В ABP нет процедуры запроса или подтверждения присоединения

(Join-Request или Join-Accept). Вместо этого DevAddr и два сеансовых ключа,NwkSKeyиAppSKey,ужежесткозапрограммированывузле.Эти значениятакже предварительно зарегистрированы на сетевом серве- ре.На рис.13.12 показано,как узел отправляет сообщение на сетевой сервер, используя ABP.

Сетевой сервер

Шлюз

Узел

Рис.13.12.Поток сообщений ABP

376  Глава 13