Lora wan что это

Сеть LoRaWAN

Лампочка, радиатор, телевизор, светофор, вентиляция, станок, парковка, автобус – казалось бы, что связывает все эти достаточно далекие друг от друга системы и приборы, зачастую относящиеся к абсолютно разным классам. Взаимосвязь есть, причем во всех смыслах. В нашем XXI веке все это управляется, а заодно контролируется цифровыми потоками данных.
В общем виде: информация с датчиков, которые могут быть любого вида – GPS автобуса, тепловые, пожарные или энергетические, расположенные в домах, заводских помещениях, а также любые другие – кодируются, затем передаются бинарными потоками на центральный управляющий «пункт», где обрабатываются. Или наоборот (ну или совместно с обработкой): коды команд в цифровом виде отправляются на контроллеры различных устройств, станков производственных линий, выключатели, регуляторы или конечные высокоинтеллектуальные приборы. У таких коммуникаций есть и свое, определенное название – интернет вещей или Internet of Things (IoT).

Коммуникации в IoT

Интернет вещей

• Беспроводные, высокоскоростные – WIFI, firewire, WAN, радиоточка. Относительные невеликие расстояния, но возможность передавать данные без искажений с высокой плотностью обмена. Конечно, для потребителей это большой плюс. Вот только энергопотребление на конечных устройствах довольно высоко, а к примеру, какому-либо датчику не нужно перегнать по каналу мегабайты или гигабайты информации, достаточно просто сообщить с определенным периодом (или по запросу) о своем состоянии. Причем не затрачивая на это большое количество энергии, которую ему (то есть датчику) еще нужно откуда-то брать. Опять же – для подобных систем связи в Российской Федерации есть определенные ограничения на ширину диапазона передачи, частотные полосы и максимальную мощность излучателей для них. Например, официально нельзя, чтобы сила радиосигнала превышала 25 мВт и работала за пределами частот 2400, 5000, 864-865,5 и 868,7-869,2 МГц, при спектральной ширине канала более 125 кГц. А чем больше нужно вместить данных в этот, достаточно узкий, промежуток и передать их дальше, тем более потребляющий энергию и «умный» ретранслятор нужен.

• Сотовая связь. Опять же, высокое потребление энергии. Кроме того, ограниченность количества устройств. В этом типе коммуникации важны центральные ретрансляторы-точки соты. Скорость обработки и передачи данных в подобных сетях сильно зависит от количества конечных абонентов. При слишком большом размере, скажем нескольких сотен тысяч датчиков – связь станет очень медленной, да и для обработки запросов клиентов понадобится довольно серьезная техника на каждом участке сети. Имеются в виду не только сервера – обработчики подключения или приемники\передатчики, но и клиентские (датчики или контролеры), а конкретнее их электронные компоненты, отвечающие за осуществление связи с базовой станцией. Вся эта система попросту будет экономически невыгодна.
• Световые и лазерные коммуникации. Собственно, использовать такие системы для связи от каждого устройства с управляющим процессором – просто не реально. Тут нужна прямая видимость и отсутствие препятствий.
• Проводные сети LAN, USB, RS-232, RS-485. А в этом случае как раз все упирается в расстояния для некоторых из них (LAN-Ethernet и USB). Опять же, физические каналы для подобного оборудования – кабель, а его возможность проложить существует далеко не всегда. Да и для высокоскоростных вариантов канала, для достаточной их длины, части линии должны быть соединены через высокотехнологичные повторители или коммутаторы.

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

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

Относятся такие сети к типу LPWAN, то есть Low Power Wide Area Network — «глобальная сеть малой мощности», а само название расшифровывается как Long Range – «большая дальность», которое хорошо характеризует суть использования и возможности, предоставляемые сетью. Буклет сетей LoRa

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

Датчики

Основная структура LoRaWAN – сеть типа «звезда». Если просто объяснить эту систему, то выглядит она так: несколько приборов контроля или сигнализации подключаются беспроводным сигналом к шлюзу, который работает в режиме коммутатора\повторителя. Сам он не производит обработку информации, а просто служит ретранслятором, объединяющим несколько клиентских устройств.

Уровнем выше находится сетевой сервер, к которому присоединяются шлюзы LoRa. Причем соединение между повторителем и узлом выше может быть достигнуто с помощью сетей другого, как физического, так и программного типа. В этом случае обычно уже используют как чистый Ethernet, так и другие беспроводные технологии WIFI, LTE, 3G, WAN. Причина – сумма собранных на шлюз информационных пакетов уже имеет намного больший размер, чем передаваемая от одного датчика, ведь она ретранслируется со многих из них. То же самое касается и управляющих последовательностей – пришедший от сервера общий пакет шлюз уже делит и распределяет по контролирующим устройствам. Один из наборов для создания сетей LoRa

Сервер

Что касается самого сервера, – он служит для общего управления топологией и устройствами сети, хранения и обработки данных, контроля скорости передачи.

Сервер приложений

Уровнем выше уже идут так называемые «сервера приложений», а конкретно – цифровые станции в виде персональных компьютеров, тонких клиентов сети, планшетов, смартфонов, КПК, на которых работают программы, контролирующие пришедшую информацию и отдающие команды программному обеспечению центра ниже уровнем.

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

Что такое LoRaWan

Напомню, что термином IoT (Internet of Things) обозначают различные устройства, которые используют выход в сеть для взаимодействия друг с другом. К примеру, умная розетка подключается к Интернету не затем, чтобы сидеть в социальных сетях. Она получает из Сети команды, которые отправляет ее владелец. И она вещь. Вещь, которая пользуется Интернетом.

К буму IoT готовились давно. И почти сразу стало ясно, что для стабильной работы существующие стандарты передачи данных подходят мало.

Зачем что-то новое?

На первый взгляд, у нас уже есть готовые и обкатанные решения. Wi-Fi, LTE, почему не использовать их?

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

Объем. На один жилой дом из 400 квартир придется 1200 счетчиков-пользователей. У них будет копеечный траффик, но если все они будут висеть, к примеру, на базовой станции LTE, то места для людей на этой базовой станции уже не останется. И это один дом. А ведь базовую станцию, обычно, ставят на микрорайон или даже больше.

Потребление. Если электросчетчику еще можно обеспечить питание, то тянуть кабель к водосчетчику не слишком удобно. Значит радиомодуль водосчетчика должен работать от батарейки. Но даже хорошую батарейку Wi-Fi и LTE съедят за несколько суток. Мы же хотим, чтобы менять элемент питания не приходилось минимум год.

Другие приоритеты. Нам не нужен канал связи в 5 мбит/c, чтобы раз в сутки передать, сколько кубов воды набежало по каждой квартире. Хватит считанных бит. Мы ограничены по мощности передатчика, надо чтобы он не ел батарейку. Значит, можно использовать правило «больше энергии в один бит – выше вероятность приема» таким образом, что канал связи на минимальной скорости и с минимальной мощностью гарантированно пройдет нужное расстояние. Даже если сигнал будет ниже уровня шума.

После тщательного анализа рынка компания Интерсвязь приняла решение строить свою сеть на базе стандарта LoRa.

Что такое LoRa?

Строго говоря, аббревиатурой LoRa (Long Range) обозначают лишь вид модуляции, то есть уровень l1 по модели OSI. Протокол канального уровня носит имя LoRaWAN. Но чаще всего «Лорой» называют совокупную систему, использующую LoRa на физическом и LoRaWAN на канальном уровне.

Работает это следующим образом. Базовая станция слушает эфир в заданном диапазоне частот. Когда она слышит запрос от какого-либо из устройств, то отвечает ему на частоте обращения. Ширина канала при этом составляет 125 кГц, максимальная скорость – чуть более 5 килобит/c. Да-да, вы не ослышались. Именно 5 и именно килобит/c. Этот стандарт Интернета вещей не создан для просмотра потокового видео. Его задача максимально быстро и гарантированно передать небольшое сообщение от датчика на базовую станцию. В зависимости от радиоусловий выбирается оптимальный набор параметров связи. За это отвечает SF (spreading factor) – коэффициент, к которому привязываются параметры передачи и приема. SF – это целое число, в стандарте он предусмотрен от 12 до 7. Чем выше SF, тем лучше помехозащищенность линии, но тем ниже скорость и тем больше времени в эфире занимает передача. Для примера, максимальная помехозащищенность достигается на SF=12. При этом время пакета в эфире составляет 2,466 сек, а скорость – 292 бит/сек.

Однако чем больше датчиков будут использовать базовую станцию, тем больше времени в эфире они займут. Потому, при хороших радиоусловиях, SF будет меньше. Растет скорость — падает время передачи.

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

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

Почему именно LoRa?

На данный момент существует несколько десятков стандартов Интернет-вещей. Часть из них универсальны, часть приспособлены решать свой круг задач. Все они более-менее придерживаются вышеописанных принципов. Есть даже стандарты на базе Wi-Fi и LTE. Так почему именно LoRa?

1. LoRa использует частотный диапазон, разрешенный для использования в России. Существуют системы LoRa для диапазона 433 МГц, но в нашей стране больше прижились частоты из диапазона 868. Там у нас есть 1,5 МГц нелицензируемого спектра. 864-865 МГц и 868,7-869,2. В первом интервале у нас есть ограничение по времени нахождения передатчика в эфире (не более 0,1%) и по мощности (не более 25 мВТ). Во втором – только по мощности (те же 25 мВт). Так же есть оговорки по поводу использования вблизи аэропортов. Как уже было упомянуто, ширина канала LoRa – 125 кГц. В стандарте предусмотрены 250 и 500, но в России их обычно не используют. Итак, в 1,5 Мгц нам надо «запихнуть» 8 основных частот и одну резервную (RX2, второе окно, которое используется, если не проходит связь по основному каналу). Это возможно? Если строго придерживаться рекомендаций разработчика Semtech, то защитный интервал между каналами должен составлять 75 кГЦ. Значит, удастся разместить только 7 каналов. Не 9, но тоже хорошо. Есть надежда, что со временем ГКРЧ даст разрешение на расширение этого спектра.
2. LoRa как раз разрабатывалась для работы на мощности 25 мВт. И тут не нарушаем. Пусть вас не смущает столь низкий уровень – технология может работать ниже уровня шума.
3. LoRa – это открытый стандарт. Чипы для конечных устройств в свободной продаже, есть вся документация, и она открыта любому желающему. Датчики и радиомодули под этот стандарт только в России делают несколько компаний. Она не «вещь в себе», даже если пропадет один из производителей, останутся другие.
4. LoRa имеет хороший радиус действия, она может принимать информацию от устройств в подвале дома или в километре от базовой станции. На самом деле, может принять информацию и от датчика в 4 километрах городских условий. Но тут страдает стабильность, поскольку начинается потеря пакетов. Однако, километр или два мы имеем.
5. Датчики LoRa живут от батарейки минимум год. А то и больше. Тут есть зависимость от класса датчика (А, В или С). Самый живучий – А-класс — может продержаться несколько лет.

Выбор вендора

Российский рынок похож на спринтера, который замер в ожидании старта. Предложений по технологиям LoRa множество. Но половина фирм оказываются «перекупами», которые технологию в глаза не видели и готовы на заказ привезти что-то там из-за рубежа.

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

Встал вопрос – на каких базовых станциях будем работать?

По сути, на рынке сейчас не так уж много предложений. Мы выбрали на тест три варианта:

БС Kerlink (Франция).
БС Вега (Россия).
БС Cisco (США).

Прошу обратить внимание, что я пишу только национальную принадлежность компании-производителя. Сказать, что БС собраны по месту прописки будет не совсем верно. Например, Вега собирает станции в России, но использует для этого те же чипы Semtech. Потому каждая станция является некой солянкой.

Первоначально тесты проводились на штатных антеннах. Замеряли карту покрытия, считали две зоны охвата.

Зона 1 – гарантированно проходят все пакеты

Зона 2 – идут незначительные потери, не более 15 процентов.

В целом, все БС показали сходные результаты. У Веги и Kerlink Зона1 оказалась в радиусе 800-900 метров. Cisco за счет системы «одна антенна на передачу-две на прием» показала результаты на 30 процентов лучше. Зона 2 у всех трех станций оказалась примерно одинаковой.

Зона 1 (полное прохождение пакетов)

Зона 2 (потеря не более 15 процентов)

Надо понимать, что берутся усредненные показания. Скажем, глухой подвал в радиусе 500 метров не всегда возможно покрыть. А до квартиры на 9 этаже в прямой видимости от БС «добьет» и на 2,5 км без потерь.

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

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

Рельеф местности. Челябинск не отличается ровным рельефом, все-таки Урал. Потому мы заметили явное увеличение зоны покрытия на снижениях и уменьшение — на подъемах.

Сам по себе сигнал оказался крайне устойчив к индустриальным помехам. Единственной слабостью технологии стали антенны GSM-900. На крышах рядом с ними БС заметно теряли эффективность. Однако, сотовые антенны других диапазонов существенного влияния не оказывали.

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

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

После мы повторили тесты, используя антенны Радиал с лучшим коэффициентом усиления, нежели штатные антенны БС (10 dBi против 6 dBi). Новые антенны улучшили карту покрытия Cisco в среднем на 15 процентов, а карта покрытия Веги подскочила аж на 40 процентов (штатные антенны российского производителя не отличаются хорошими характеристиками). Kerlink к тому времени не рассматривали из-за необоснованной дороговизны.

Таким образом, Вега не сильно уступила своему заокеанскому конкуренту.

В итоге, оказалось, что на стабильное и качественное покрытие такого города как Челябинск требуется порядка 40-50 БС.

Пилотная зона

В рамках тестов мы подключили к нашей сети общедомовые водосчетчики одной из управляющих компаний. Водосчетчики Zenner имели импульсные выходы, для съема информации использовали датчики Вега СИ-11. Это простой счетчик импульсов с автономным питанием в компактном корпусе с радиомодулем LoRa. Крепится на DIN-рейку.

Для качественной оценки параметров был установлен минимальный период отправки показаний – 1 час. Далее, полученные показания периодически сверялись с тем, что выдает счетчик на своем циферблате. Если цена импульса выставлена верно, и счётчик Zenner исправен, то отклонений в показаниях не наблюдалось.

Т.к. подобные приборы учета ставятся в подвалах, мы получили хороший опыт практического применения технологии LoRa. В целом, результаты совпали с нашими тестами. В зависимости от рельефа, застройки и конфигурации подвала шлюз мог установить связь с датчиками на расстоянии 500-2300 метров. На приведенной карте случай среднего подвала со слуховыми окнами. Он находится на расстоянии 1,5 км от шлюза. Потери пакетов не происходит. Отметим, что по прямой распространения сигнала находится хороший кусок частного сектора, который не вносит большого затухания.

Масштабирование сети

Базовые станции LoRa, подключенные к одному сетевому серверу, работают как единый механизм. Т.к. большую часть времени конечные устройства молчат, то коллизии в эфире – случай крайне редкий. Обычно, когда датчик выходит на связь, его слышат сразу несколько БС. Но ответит только одна. Это не обязательно самая ближняя к датчику БС, но всегда та, у которой лучшие качественные характеристики канала связи.

Сеть очень легко нарастить – нужно просто подключать настроенную БС к сетевому серверу через Ethernet или мобильные сети. Но увлекаться слишком большой плотностью станций на единицу площади нельзя:

1. Это экономически нецелесообразно. Станции стоят денег, слишком высокая плотность приведет к необоснованным тратам.
2. Станция всегда должна находиться на доминирующей высоте. Если ваша станция находится на 16-этажном доме и хорошо покрывает микрорайон, то большая часть информации пойдет через нее. Какая-нибудь дополнительная БС у нее под боком, скорее всего, будет большую часть времени простаивать.
3. Каждая БС, так или иначе, может занимать в эфире драгоценное место. Слишком высокая плотность БС повышает риск коллизий.

Что дальше?

Главный вопрос, который задают скептики. Замечательно, у вас есть технологии. Потребители-то где?

Да вот они! Прямо перед вами. На данный момент компания «Интерсвязь» реализует масштабный проект по подключению различных общедомовых счетчиков к единому центру сбора данных. В перспективе подключение других общедомовых приборов учета. Опрос устройства производится именно через технологию LoRa.

При этом счетчику совсем не обязательно иметь встроенный радиомодуль. Достаточно импульсного выхода, RS-232 или RS-485. В этом случае, рядом с ним устанавливается внешний радиомодуль с необходимым интерфейсом, который собирает и передает показания.

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

Данная услуга пользуется спросом у управляющих компаний. Теперь им не надо посылать слесаря дядю Петю в подвал, чтобы он там переписал показания счетчиков (точно ли сходит. ). Раз в час радиомодуль сообщит показания на сервер, а тот передаст в биллинг.

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

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

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

Все эти пожелания оформляются в виде задач нашим инженерам и передаются в работу. Еще многое предстоит сделать, однако уже сейчас мы можем сказать. «Интернет вещей теперь в вашем доме!»

Lora wan что это

Получение показаний со счетчиков газа, воды, электричества, тепла, протечек.

Транспорт

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

Производство

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

Умный город

Контроль и управление освещением, мусорных контейнеров, погодных условий, выбросов, контроль люков и безопасность объектов.

Технология LoRaWAN

LoRaWAN — это один из типов LPWAN сетей, расшифровывается как Low-power Wide-area Network — «энергоэффективная сеть дальнего радиуса действия».

LPWAN сети являются беспроводными и имеют широкий радиус охвата, основной плюс таких сетей является низкое энергопотребление, а объем передачи данных в таких сетях измеряется в байтах, но этого достаточно что бы передавать необходимую телеметрию с конечного устройства на сервер диспетчера. Время жизни таких конечных устройств несколько лет от одной батареи и зависит от расписания передачи данных.

В основном устройства с LPWAN подключением — типичные микроконтроллеры с минимальным потреблением энергии и беспроводным сетевым интерфейсом. Такие устройства как правило связываются со своим шлюзом (базовой станцией), который имеет IP адрес для выхода в интернет.

LoRaWAN это технологический стандарт разработанный и поддерживаемый Lora Альянсом, данный Альянс состоит из международных телекоммуникационных компаний и производителей, а также интеграторов. Технологическая платформа LoRaWAN может сегментироваться на два компонента:
• LoRa: Проприетарная технология с радио модуляцией LoRaWAN, использующая беспроводную связь для подключения между конечными устройствами и шлюзами.
• LoRaWAN: Протокол управления доступом, использующий для идентификации MAC адрес (MAC — media access control — Управление доступом к среде) для передачи и управления сообщениями между Cетевым Cервером LoRaWAN и конечным устройством.

Архитектура

В диаграмме показаны четыре ключевых элемента сети:
Устройства: Конечные IoT устройства которые отправляют и получают сообщения в беспроводной сети LoRA.
Шлюзы: Шлюз работает как ретранслятор и его задача отправлять все сообщения от конечных устройств и передавать их на сервер сети и обратно.
Сетевой сервер: занимается управлением и обслуживанием сети LoRA
Сервер приложений: Все устройства отправляют сообщение с payload в конечное приложение клиента.

На диаграмме показано, что топология сети имеет тип «Звезда» (Звезда — базовая топология компьютерной сети, в которой все компьютеры/устройства сети присоединены к центральному узлу, образуя физический сегмент сети.) с сетевым сервером соединяющим несколько шлюзов, которые в свою очередь соединяются с устройствами по беспроводной сети LoRA. Связь является двунаправленной, но преобладающий тип связи принятие данных от конечных устройств.

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

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

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

Данные

/>

Шлюзы отправляют LoRaWAN сообщения по беспроводному интерфейсу используя протокол сообщений шлюза (Gateway Message Protocol), определенный в соответствии со спецификацией интерфейса LoRaWAN Gateway to Server. Сообщения LoRaWAN и вложенные в него данные отправляются в JSON кодированном формате используя UDP/IP

LoRaWAN спецификация не определяет не описывает как сетевой сервер будет взаимодействовать с сервером приложения (диспетчера). Обычно для обмена сообщениями между сетевым сервером и сервером приложения используют стандарты IoT, такие как MQTT, AMPQ, HTTP и другие.

LoRa Устройства

Конечные устройства обмениваются сообщениями LoRaWAN со шлюзами на разных частотных каналах и скоростях передачи данных, которые определены документом региональных параметров LoRa Альянса.

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

Региональные стандарты

Ниже представлена таблица с рекомендованными настройками для сетевого сервера, в разных регионах, для России параметр RU868

Parameter	EU868	US902	CN779	RU868
Coding Rate	4/5	4/5	4/5	4/5
RX1 Join Delay (s)	5	5	5	5
RX2 Join Delay (s)	6	6	6	6
RX1 Delay (s)	1	1	1	1
RX2 Delay (s)	2	2	2	2
Gateway Power	16	26	12	16
Max EIRP (dBm)	16	30	12.15	16
Max Power	Max	Max	Max	Max
Min Power	Max — 14dB	Max — 20dB	Max — 10dB	Max — 14dB
Max Data Rate	SF7 125 kHz	SF8 500 kHz	SF7 125 kHz	SF7 125 kHz
Initial Duty Cycle	100%	100%	100%	100%
Initial RX1 DR Offset	0	0	0	0
Initial RX2 DR	SF12 125 kHz	SF12 500 kHz	SF12 125 kHz	SF12 125 kHz
Initial RX2 Freq (MHz)	869.525	923.3	786	869.1
Initial Channels	0-2	0-71	0-2	0-1

Частотный план LoRaWAN для РФ

MultiSF 125 kHz

MultiSF 125 kHz

MultiSF 125 kHz

MultiSF 125 kHz

MultiSF 125 kHz

MultiSF 125 kHz

MultiSF 125 kHz

FSK 250 kHz, 50kbps

Оптимизация передачи данных

Скорость обмена данными определена уровнями модуляции и коэффициентом SF (Spreading Factors) в комбинации с шириной полосы канала. Все эти параметры влияют на физическую битовую скорость и время в эфире.

Значения: 7, 8, 9, 10, 11, 12

Больше число – большая энергия на бит и большая возможность

обработки, но большее время в эфире.

Рассмотрим значение передачи данных для частотного плана RU868.

Для максимального увеличения времени автономной работы устройств LoRA использует схему адаптивной скорости передачи данных (ADR). ADR управляет индивидуальными скоростями для каждого подключенного устройства. Конечные устройства могут передавать по любому доступному каналу в любое время используя любую доступную скорость ADR при условии соблюдения следующих правил:

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

Документ региональных параметров LoRaWAN v 1.0.3

Документ региональных параметров LoRaWAN v 1.1

Термины и определения

Activation by Personalization

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

AppEUI

(8-ми байтный, EUI64) глобально уникальный идентификатор приложения для маршрутизации полученных данных сервером сети (Network Server), на сервер приложений (AppServer)

AppKey

уникальный (16-ти байтный, AES-128) ключ шифрования, сгенерированный сервером приложений (AppServer) для данного конкретного устройства

AppServer

сервер приложений клиента

DevEUI

8-ми байтный, EUI64) глобально уникальный идентификатор устройства (End-device identifier). Может быть присвоен производителем устройства (по аналогии с MAC адресом), в ограниченном количестве может быть получен из доступного пула идентификаторов оператора, либо получен владельцем узла в составе пула в IEEE

DevAddr

32-битный (четырехбайтный) сетевой адрес для адресации пакетов на сетевом уровне, имеет уникальное значение в пределах сети оператора (можно провести аналогию c MAC адресом, который тоже обеспечивает адресацию на 2 уровне модели OSI в сетях Ethernet, но способ получения DevAddr при OTAA сходен с получением динамического IP адреса, получаемого от DHCP сервера в TCP/IP сетях). Старшие 7 бит DevAddr содержат адрес сети оператора NwkID, это значение должно быть уникальными для находящихся рядом сетей и для сетей, имеющих перекрывающиеся зоны покрытия. Чаще всего, для обозначения DevAddr, используют четырехбайтную последовательность (например: 02:D1:D2:01), в которой старший байт является адресом сети NwkID

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

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

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

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

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

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

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

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

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

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

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

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

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

Широкополосный радиосигнал 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) соответственно.

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

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

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

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

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

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

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

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

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

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

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

Де-chirped сигнал:

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

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

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

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

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

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

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

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

SNR/SF

SF7

SF8

SF9

SF10

SF11

SF12

0 дБ

-3 дБ

-6 дБ

-9 дБ

-12 дБ

-15 дБ

-18 дБ

-21 дБ

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

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

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

Параметр

Европа

Северная Америка

Россия

Частотный диапазон, МГц

Максимальное количество каналов

Ширина спектра радиосигнала UL, кГц

Ширина спектра радиосигнала канала DL, кГц

Мощность передачи UL, дБм

2-14
20 (опционально)

2-20 (спецификация LoRa)
2-14 (ограничение в РФ)

Мощность передачи UL, мВт

1-25
100 (опционально)

1-100 (спецификация LoRa)
1-25 (ограничение в РФ)

Мощность передачи DL, дБм

20 (спецификация LoRa)
14 (ограничение в РФ)

Фактор расширения спектра
SF (Spreading Factor)

SF

7

8

9

10

11

12

W, kHz

Rb, CR=1 (без кодирования FEC), бит/с

Rb, CR=4/5, бит/с

Rb, CR=4/6, бит/с

Rb, CR=4/7, бит/с

Rb, CR=4/8, бит/с

Скорость передачи данных

Конфигурация (SF/W)

Скорость передачи данных на физическом уровне, бит/с

LoRa: SF12 / 125 кГц

LoRa: SF11 / 125 кГц

LoRa: SF10 / 125 кГц

LoRa: SF9 / 125 кГц

LoRa: SF8 / 125 кГц

LoRa: SF7 / 125 кГц

LoRa: SF7 / 250 кГц

Rb, CR=1 (без кодирования FEC), бит/с

TXPower

Мощность передатчика

Классы устройств 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.

Физический уровень (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) каналов:

Здесь:
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 уровня:

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

MType

Описание

Запрос процедуры активации по воздуху (OTA – over-the-air) – join request

Подтверждение процедуры активации по воздуху (OTA – over-the-air) – join accept

Передача данных без подтверждения «вверх» (unconfirmed data up)

Передача данных без подтверждения «вниз» (unconfirmed data down)

Передача данных с подтверждением «вверх» (confirmed data up)

Передача данных с подтверждением «вниз» (confirmed data down)

Для частных решений

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

Скорость передачи

M, октет

Фрейм данных (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 сообщения (в т.ч. пустого, если отсутствуют полезные данные для передачи) по окончании которого и будут открыты дополнительные окна для получения данных от сети.

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

Технология 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 _ DELAY 1 (длительность временного окна приема RX 1) – 1 сек.

RECEIVE _ DELAY 2 (длительность временного окна приема RX 2) – 2 сек.

(=RECEIVE_DELAY1 + 1 сек .)

JOIN_ACCEPT_DELAY1 – 5 сек.

JOIN _ ACCEPT _ DELAY 2 – 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.

CID

Команда

Передается

Описание

Используется конечным устройством для проверки подключения к сети.

Отвечает на команду LinkCheckReq. Содержит оценку качество приема и кол-во шлюзов (LoRa Gateway), принявших команду LinkCheckReq от конечного устройства.

Запрашивает конечное устройство на изменение скорости передачи данных, мощности передачи, кол-ва повторения каждого сообщения и списка доступных для передачи «вверх» каналов.

Подтверждает прием LinkRateReq команды.

Устанавливает максимальный совокупный рабочий цикл передачи конечного устройства. Изменяется в пределах от 1 (доступ без ограничений) до 2-15.

Подтверждает прием DutyCycleReq команды.

Устанавливает параметры окон приема. Для RX1 – изменение скорости передачи в линии «вниз» по сравнению со скоростью передачи в линии «вверх». Для RX2 – частотный канал и изменение скорости передачи.

Подтверждает прием RXParamSetupReq команды.

Запрашивает состояние конечного устройства.

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

Разрешает использование конечным устройством определенных радиоканалов, устанавливает их частоту (за исключением 3-х радиоканалов, установленных по умолчанию соответствующим региональным стандартом), а также допустимые границы скорости.

Подтверждает прием NewChannelReq команды

Устанавливает временную задержку между окончанием передачи по линии «вверх» (UL) и открытием первого окна приема. Второе окно приема открывается через одну секунду после первого.

Подтверждает прием RXTimingSetupReq команды.

Зарезервировано для частных решений.

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

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

В сети используются три вида ключей. Ключ аутентификации приложения 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), необходимые для передачи информации, вычисляются самим конечным устройством. Данный метод активации обеспечивает высокий уровень безопасности и рекомендуется для использования.

Формат сообщений 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). Данный метод активации (в связи с низким уровнем безопасности и сложностью реализации) не рекомендуется использовать для коммерческих сетей.

Особенности работы устройств 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.

В данном примере (ось времени не показана на рисунке) период посылки сигнала маяка составляет 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).