Введение в LoRaWAN
Типовая беспроводная сеть LoRaWAN представляет собой совокупность шлюзов (gateways), пересылающих сообщения между оконечными устройствами (end-devices) и центральным сервером (Network Server, NS), и характеризуется «звездной» топологией «star-of-stars».
Шлюзы называют также концентраторами (concentrators) и базовыми станциями (base stations). Оконечные устройства часто называют motes.
Связь между шлюзами и центральным сервером осуществляется через стандартные IP-соединения, а между шлюзами и оконечными устройствами — через беспроводные соединения, использующие широкополосную модуляцию LoRa или FSK. Модуляция LoRa была разработана компанией Semtech и предназначена для низкоскоростной беспроводной передачи данных на расстояния до нескольких километров в безлицензионных диапазонах частот (Европа — 433 и 868 МГц).
Связь между шлюзами и оконечными устройствами является двусторонней, но предполагается, что основной объем данных передается от оконечных устройств к шлюзам. Технология LoRa обеспечивает скорость передачи в беспроводном канале от 0.3 до 50 кбит/с. Для разделения каналов используется как набор частотных каналов, так и скоростей передачи (data rates).
Для оптимизации работы системы используется адаптивное изменение скорости передачи — ADR (adaptive data rate). Cетевой сервер оценивает качество сигнала, принимаемого от оконечного устройства, и может управлять как скоростью передачи, так и мощностью передатчика этого устройства.
Оконечное устройство может передавать данные на любом доступном канале и любой скорости передачи, учитывая следующее:
- Каждый раз при передаче сообщения частотный канал выбирается оконечным устройством случайным образом из списка доступных каналов.
- Перед началом передачи оконечное устройство должно убедиться в том, что канал свободен (Listen Before Talk, LBT). Канал считается свободным, если измеренное мгновенное значение RSSI меньше, чем RSSI_FREE_TH. Если канал занят, то устройство переходит на другой канал и повторяет процедуру LBT.
- Оконечное устройство должно принимать во внимание ограничения местных регулирующих органов относительно процента времени, в течение которого устройство может занимать частотный канал.
Основные преимущества сетей LoRaWAN
Основные преимущества беспроводных сетей LoRaWAN обусловлены использованием широкополосной модуляции LoRa и безлицензионных диапазонов частот. Сети LoRaWAN:
- совместимы с существующими сетями/технологиями беспроводной передачи данных;
- обладают высокой помехоустойчивостью;
- способны обслуживать десятки и сотни тысяч устройств;
- обеспечивают большую зону охвата и малое энергопотребление оконечных устройств.
Варианты применения беспроводных сетей LoRaWAN
Пара слов о возможных применениях:
- считывание показаний счетчиков газа, воды, электричества;
- Smart Grid (мониторинг электрических сетей нового поколения;
- мониторинг автотранспорта и грузов на определенной территории (определение местоположения, информация о состоянии транспортных средств и грузов);
- контроль состояния контейнеров/емкостей на производстве (нефтехимические производства, контейнеры для отходов производства, контейнеры с опасными веществами);
- мониторинг производственного оборудования (уменьшение простоя, контроль параметров, обеспечение безопасности персонала);
- умные парковки (мониторинг доступности парковочных мест);
- мониторинг мусорных баков (оптимизация процессов утилизации мусора);
- умное уличное и пр. освещение (удаленное управление, контроль состояния);
- мониторинг погодных условий;
- контроль состояния люков (предотвращение несанкционированных проникновений);
- контроль наличия вредных веществ в атмосфере;
- сбор данных о состоянии окружающей среды (загрязнение, шум, дождь, ветер и пр.);
- пожарная, охранная сигнализация;
- автоматизация зданий (контроль температуры, влажности, управление воротами, жалюзи).
Классы оконечных устройств LoRaWAN
Вернемся к спецификации LoRaWAN и посмотрим, какие бывают устройства. На конец 2016 г. спецификация определяет 3 класса оконечных устройств LoRaWAN: A, B и C, отличающиеся друг от друга режимами приема. Устройства данных классов являются двунаправленными. Класс А является базовым и должен поддерживаться всеми устройствами.
Класс А (обязательный для всех)
Устройства класса А после каждой передачи открывают два коротких временных окна на прием (обозначаются как RX1 и RX2).
Интервалы от конца передачи до открытия первого и второго временных окон могут конфигурироваться, но должны быть одинаковыми для всех устройств в данной сети (RECEIVE_DELAY1, RECEIVE_DELAY2). Для европейского диапазона 868 МГц рекомендованное значение RECEIVE_DELAY1 составляет 1 секунду. Значение RECEIVE_DELAY2 должно равняться (RECEIVE_DELAY1 + 1) секунда.
Используемые частотные каналы и скорости передачи для интервалов RX1 и RX2 могут отличаться. Рекомендуемые значения приведены в отдельном документе — «LoRaWAN Regional Parameters», доступном на сайте LoRa Alliance.
Устройства класса А являются самыми низкопотребляющими, но для передачи сообщения от сервера к оконечному устройству необходимо дождаться следующего исходящего сообщения от этого устройства.
Класс B (Beacon)
В добавок к окнам приема, определенным для устройств класса А, устройства класса B открывают дополнительные окна приема по расписанию. Для синхронизации времени открытия дополнительных окон приема шлюзы излучают маячки (beacons). Все шлюзы, входящие в состав одной сети, должны излучать маячки одновременно. Маячок содержит идентификатор сети и метку времени (UTC).
Использование класса В гарантирует, что при опросе оконечных устройств задержка отклика не будет превышать определенную величину, определяемую периодом маячков.
Класс C (Continuous)
Устройства класса C находятся в режиме приема практически всё время за исключением промежутков, когда они передают сообщения. За исключением временного окна RX1 оконечное устройство использует параметры приема RX2.
Класс С может применяться там, где не нужно изо всех сил экономить энергию (счетчики электрической энергии) или где необходимо опрашивать оконечные устройства в произвольные моменты времени.
Итак, с основами LoRaWAN и классами устройств немного разобрались — в следующей статье обсудим способы активации оконечных устройств.
Ссылки по теме:
Комментарии (18)
avan
09.12.2016 09:52Или сами, или есть несколько западных облачных IoT-сервисов — можно через шлюз к ним подцепиться и греть чайники. Вообще, упомянутый Network Server может работать и на шлюзе. И не только он. Может станет чуть понятнее, если глянуть «Настраиваем шлюз LoRaWAN и создаем наше первое IoT-приложение».
ukt
09.12.2016 13:08Как одно из возможных применений вы пишите:
считывание показаний счетчиков газа, воды, электричества;
Сразу встает разумный вопрос о возможном количестве датчиков, возможных на определенной площади.
Современные дома это около 400 квартир, с кухней и ванной, из-за вертикальной разводки требуется по два датчика(холодную и горячую воду) на помещение, такая же история и теплосчетчиком. Возьмем сферическую квартиру, с одной жилой комнатой и кухней, получим:
1) датчики воды 2*2 = 4 шт.
2) счетчик газа 1 шт.
3) теплосчетчик = 2.
Итого 7 штук. Квартир 400, что в итоге дает 400*7 = 2800 датчиков.
Рядом стоят ещё дома, аналогичные, 5 шт.
Собственно вопрос: что произойдет с помехозащищенностью, способностью к считыванию датчиков в данном кейсе?aquamakc
09.12.2016 14:01Те дома (многоэтажные), что я знаю:
1) Не снабжаются газом (разве-что котельная рядом с домом)
2) Теплосчётчик общедомовой
3) Таки оснащены электросчётчиками.
Итого 2 на воду + 1 электро = 3 счётчика.
По вопросу — заинтересовался. Нашёл ссылку: (не хватает рейтинга)
Емкость сети зависит от того числа пакетов, которые могут быть получены в данный момент времени. Один шлюз на SX1301 с 8 каналами, используя протокол LoRaWAN, способен получить около 1,5 млн. пакетов в день. Так что, если ваш узел отправляет один пакет в час, то один шлюз на SX1301 может с успехом обслуживать до 62500 таких конечных устройств
ukt
09.12.2016 15:041) Дом может быть вполне и не многоэтажный, а широким, или куча малоэтажек, как сейчас строят новые районы в средних городах, вроде академгородков.
2) Это пока общедомовой, в старых домах, в новых — ФЗ №261 от 23.11.2009 г, не прихоть, а ФЗ.
Итог не правильный, счетчиков на воду 4е шт. итого 5 шт., каждый счетчик на воду, законченное устройство имеющее свой уникальный номер, необходимый для поверки.
Их в нашем кейсе требуется 4 штуки = два в ванной, два на кухне.
Сейчас показания снимаются раз в месяц, так вы пишете — для выставления счета.
Но и смысла тогда не много, раз в месяц можно и карандашиком рядышком постоять.
Не видно преимуществ такого решения.
Однако, если мониторить потребление ресурсов(и выставленных счетов), самостоятельно, а так уже можно будет делать на сайте управляющей с 01. 01. 2017, уже не вписывается раз в месяц.
Вопрос то не в «сколько станция базовая может принять», а в «сколько датчиков могут одновременно работать, не мешая друг другу». И вполне естественно, что вторая цифра будет меньше первой.
Так же логично предположить, что базовая станция — 1 шт. на один дом. Т.к. это имущество собственников жилья. И будет очень обидно, когда с базовой станцией установленной в/на другом доме, (на общем собрании собственников будет создано ТСЖ), будут произведены какие либо действия.
62500 устройств очень уж хорошая цифра, она возможна в случае, если все устройства будут отправлять без ошибок, строго последовательно.
И опять же что будет, в случае пяти базовых станций, на расстоянии 50-150 метров?
Пусть будет по вашему, будут высотки, но без газа, я в прошлый раз не посчитал электросчетчик, получаем в нашей однокомнатной квартире:
1) вода холодная, горячая = 2 счетчика*2(ванная, кухня) = 4
2) газа у нас нет(пусть высотка), но есть электричество = 1 датчик
3) индивидуальный теплосчетчик = 1 шт*2 (кухня, жилая комната).
Итого: 7 шт., и 8 штук, если есть газ(пока он не обязателен).
avan
09.12.2016 13:19ukt, спасибо. Вопрос, безусловно, не праздный.
Но если запрашивать показания как мы сдаем их сейчас — раз в месяц — то вроде всё не так страшно?
А вообще, конечно, практика — критерий истины, это да.ukt
09.12.2016 15:07Если раз в месяц, никакие передатчики не нужны. Достаточно раз в месяц взять листочек и ручку.
avan
09.12.2016 15:12ОК, а как часто хотите передавать?
ukt
09.12.2016 20:01Все зависит от уровня, на котором нужно собирать метрики.
Если владелец жилья, то в принципе достаточно несколько раз в день, например, убедиться, что новый холодильник или стиралка высокой энергоэффективности, действительно энергоэффективны.
С точки зрения ЖКЖ, раз в час, что бы убедиться, что потребление в пределах допуска.
С точки зрения биллинга — несколько раз в месяц, Пара для проверок счетчиков, и один для выставления счетов.
С точки зрения АСУТПшника — в реалтайме, или, сколько времени потребуется для считывания со всех датчиков. Батарейки надолго не хватит. Тут Лора и поломается, загадив эфир. Как в том анекдоте про пилу.
Ведь очень странно не предоставлять возможность считывания показаний счетчиков владельцу помещения.
И возможен и такой случай что, считывают одновременно пользователь и ЖКХ, биллинг.
Сразу предвосхищая вопрос, а почему, собственно, не считывать данные, а пользователю не предоставлять доступ уже считанных? Отвечу: с этой точки зрения, мы возвращаемся к тому, что для пользователя опять достаточно листочка и карандашика. Зачем ему платить за вундервафлю, если конкретно для него ничего не изменилось?
И опять же если данные будут откуда то «оттуда», то возникает вопрос к достоверности данных, как и сейчас — доступа у жильцов к счетчикам(общедомовым нет), поэтому какая там реально цифра должна быть в платежке — никто не знает, кроме заинтересованных лиц.
Kepp
09.12.2016 19:29Подскажите какова стоимость владения в этой технологии?
Насколько я понял, это ежегодные лицензионные отчисления, которые зависят от количества устройств, шлюзов и серверов, плюс стоимость самих устройств.
Допустим, мне нужно 1000 устройств, 100 шлюзов и 10 серверов, сколько это будет стоить в год?
AHTOLLlKA
Хочу создать свою изолированную сеть с чайниками (например) какой софт нужно поставить чтобы в админ панели мог видеть все эти чайники и управлять каждым по отдельности?
aquamakc
Сдаётся мне, тот — который напишете сами. Лора — это транспортный уровень, причём за маршрутизацию шлюз-конечное устройство отвечает сам шлюз. Обмен данными ПК-шлюз происходит через стандартный TCP сокет (с лорой не работал, но это было бы логично, UDP здесь не нужен). Протокол обмена зависит от софта ваших чайников.
Повторюсь — я не как оно там на самом деле, но этот сценарий наиболее логичен.
Ens0
Самый простой способ — прийти к одному из операторов связи, у которого есть подходящее для вас решение (маловероятно, что оно найдется).
Ну или иметь деньги для разработки полностью своей софтины, которая будет обрабатывать какой-нибудь web-socket от оператора.
AHTOLLlKA
нашел вот такой мануал, может кто экспериментировал уже?
https://docs.mbed.com/docs/lora-with-mbed/en/latest/intro-to-lora/