1. Статьи
Заметки пользователей
28.05.2018 11:30
PDF
47547
77

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера

Здравствуйте те, кто занимается или просто интересуется темой Интернета Вещей. В своей прошлой статье я рассказывал о работе компании "Интерсвязь" в сфере IoT. Напомню, примерно год назад мы приступили к реализации проекта по телеметрии. Наша новая услуга подразумевала опрос приборов учета через технологию LoRa. LoRa – это стандарт, специально заточенный под IoT. Весной прошлого года, он был ещё некой неизведанной новинкой. Однако именно в LoRa мы увидели большой потенциал и решили развивать нашу сеть на его основе. Первые итоги по пилоту я описал в прошлой статье.

Прошло 9 месяцев. Проект вышел из стадии пилота и стал вполне самостоятельной услугой, которую предоставляет "Интерсвязь" не только в Челябинске, но и во всех городах присутствия в трёх областях. А наша сеть стала одной из крупнейших в России. В этой статье я хотел бы рассказать о том, с чем мы столкнулись в процессе эксплуатации, что было сделано и куда дальше будет двигаться наш проект, а заодно и сама технология.

LoRa в России, что называется, "взлетела". На данный момент, множество компаний на местах и большинство крупных игроков телекоммуникационного рынка либо строят сети на основе этой технологии, либо включили это в свои ближайшие планы. Надёжность и открытость позволили LoRa с огромным отрывом обойти конкурентов. Какова же она в жизни?

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Города, покрытые сетью LoRa компании "Интерсвязь".

Планируйте правильно!

Итак, многие проблемы мы отловили ещё на стадии пилота, и я уже писал об этом.

LoRa не любит:

  • Размещение на малых высотах;
  • Плохие антенны и некачественный монтаж;
  • Оборудование GSM-900 в непосредственной близости.


За прошедшие месяцы мы ещё раз убедились, насколько важно использовать грамотное радиопланирование! Необходимо помнить, что LoRa – это не волшебство, это модулированный радиосигнал. И он подчиняется всем законам распространения радиоволн.

Сейчас, размещая базовую станцию, мы проводим предварительные расчёты не только покрытия, но и стараемся учесть максимум факторов. К примеру, мало поставить БС на подходящей крыше, мало прикрутить к ней качественную антенну, надо ещё провести расчёт высоты подвеса, чтобы  края крыши не срезали диаграмму направленности. Сейчас мы используем ряд таблиц, составленных нами или позаимствованных у коллег. Для наиболее правильного размещения и удобства монтажа мы разработали собственное крепление, которое отвечает необходимым условиям. Кроме того, уделяем много времени обучению сотрудников, которые устанавливают оборудование "в поле".

Постоянное общение с коллегами из России, Казахстана и Беларуси подтверждает, что именно качество монтажа – главная проблема всех пилотов на LoRa. Не устаём удивляться фантазии некоторых людей в размещении БС и антенн.

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

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Слева - неверное размещение антенны. Часть рабочей поверхности прикручена к креплению, сзади кирпичная стена.
Справа - верное размещение антенны. Высокое крепление с учетом крыши и препятствий.

Либо скорость, либо расстояние

Большая беда LoRa – это весьма агрессивный маркетинг при её продвижении. Когда технологию рекламируют, то ожидаемо используют термин "до". До 10 километров радиус действия БС. До 5,5 килобит/сек – скорость передачи на 125 кГц полосе.

Напомню, в LoRa есть такой параметр – spreading factor (SF). Это целое число, некий аналог индекса модуляции в Wi-Fi. К каждому значению привязан свой набор параметров: максимальный размер пакета или скорость передачи. Чем выше значение SF, тем ниже скорость передачи, и тем выше помехозащищённость. Соответственно, наоборот.

Необходимо понимать, что LoRa – это замечательная технология, которая честно работает на грамотно построенной сети. Но ни о каких десяти километрах в городе говорить нельзя. Два, может быть три – это предельная дальность работы в городских условиях и уже на границе приёма. Десять километров - только в чистом поле, без внешних влияний, да и то не всегда.

Более того, десять километров и 5 килобит – это в принципе несовместимые вещи, LoRa никогда не достигнет этих предельных значений одновременно. Если она даже пробьёт 10 км в нашем условном поле, то это будет уже SF = 12 и, соответственно, 292 бит/сек скорости. Потому, стоит трезво оценивать технологию и её возможности. На ней можно построить многое, но когда я слышу про 10 или даже 15 километров в городе на 868 МГц, я понимаю, что человек с LoRa знаком лишь понаслышке.

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Зависимость параметров передачи от SF. Можно заметить существенную разницу в скорости передачи и времени в эфире.
Но лучшие показатели по сигнал/шуму.

Адаптируйте максимально!

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

Если мы говорим про передачу коротких пакетов (например, со счётчика импульсов), то скорость вроде бы особо и неважна, пусть лучше будет гарантированное прохождение сигнала. В нашей терминологии, нужно настраивать все оконечные устройства на работу с SF = 12.

Беда в том, что высокий SF повышает время нахождения устройства в эфире. Разница пакета 51 байт между минимальным SF = 7 (≈120 мс) и максимальным SF = 12 (≈2,8 сек) различается по времени более чем в 20 раз. Это значит не только то, что радиомодуль в двадцать раз дольше занимает драгоценное эфирное время. Он в двадцать раз дольше использует свой передатчик, то есть выедает батарею. Если мы везде выставим SF = 12, то проблем с хождением пакетов почти не будет, но обеспечить время жизни батареи на годы, не удастся.

Из практики скажу, что на SF = 12 и при ежечасном опросе, батарея на 3400 мАч живет порядка девяти месяцев. Этот результат показывает отечественный радиомодуль СИ-11 новосибирской компании Вега.

Другое дело, SF = 7. Конечно, тут зависимость нелинейная, элемент питания стареет и теряет ёмкость даже без потребления. Однако, года два жизни мы радиомодулю гарантированно обеспечим. А если еще снизить частоту опроса и использовать хитрости типа единовременной передачи почасовых показаний раз в сутки…

Кроме того, с ростом числа устройств, места в эфире будет всё меньше и меньше. Работая только на SF=12, мы очень быстро достигнем предела числа датчиков.

Однако низкий SF не всегда обеспечит нам нужной помехозащищённости, мы просто начнем терять данные. Как же быть?

Ответ прост – использовать ADR (адаптивный режим работы), когда радиомодуль подстраивается и выбирает идеальный SF именно для своих условий. Если каждый радиомодуль будет работать в оптимальном для себя режиме, вы избежите избыточного расхода батареи и сэкономите место в эфире. Кроме того, у вас появится отличный инструмент анализа покрытия. Если на карте наметилось явное пятно радиомодулей с высоким SF без явных причин – это повод пересмотреть расположение БС. Или искать помеху.

Тут стоит отметить, что бесплатные решения, которые можно найти на ГитХабе, в том числе популярное решение Брокаара, работают с ADR некорректно, хотя и заявлено, что опция там реализована.

Копайте глубже!

ОК, у вас есть грамотная рабочая сеть, которая адаптируется к внешним условиям, у вас выбраны вендоры и проведен тест оборудования. Вы трезво оцениваете возможности сети, и пришли к клиенту продавать услугу. Будем говорить про ЖКХ, так как мы стартовали именно оттуда.

Первое, с чем вы столкнётесь, это настоящий зоопарк из устройств, которые необходимо подключить. Даже если речь идёт про обычный электро- или водосчётчик. Казалось бы, что проще, чем подключить импульсный выход? Просто прикрутить два контакта в клеммную колодку радиомодуля? Нет.

У многих счётчиков нагло врёт документация. Встречался водосчётчик с "выбитой" на нём ценой импульса и… она была неверной. Методом подбора удалось определить нужное число, и счётчик прекрасно встал на мониторинг.

А ещё у некоторых счетчиков имеет значение полярность подключения (обычно у электро-, но не всегда). И здесь производитель может вам наврать в документации. Приходится выяснять правду методом перебора. Спасибо, что варианта всего два.

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Ожидание и реальность счётчиков в ЖКХ.

Однако, это не главная проблема. Очень скоро вы поймёте, что одними счётчиками импульсов и "датчиками сработки" вы не отделаетесь. Если уж мы идём в промышленный Интернет, то мы должны научиться работать с одним из господствующих там интерфейсов – RS-485 и его производными. Даже на уровне ЖКХ вас чаще всего будут спрашивать про тепло, которое с импульсным выходом почти не работает.

Первой мыслью станет использование LoRa в качестве прозрачного канала. Подгоним счетчик под SF = 7, получим наши 5,5 килобит/сек, худо-бедно нам на опрос хватит.

К сожалению, это тупик. Если отдельными пакетами забить эфир сложно, то прозрачным каналом RS-485 – только так. Для ТЕКУЩЕГО опроса одной из моделей электросчётчика вам нужно прогнать пять пакетов. Это текущие данные, это даже не архив. Я уж молчу о том, что почти нереально обеспечить работу всех радиомодулей на SF = 7. Если начнём тянуть архив, то счёт пакетов пойдёт совсем другими цифрами. А это значит, что вы либо положите эфир целиком, либо будете вылетать по тайм-ауту, потому что скорости для опроса не хватает.

А еще RS-485 – это всего лишь среда передачи. Что там по ней ходит, зависит от устройства, которое мы опрашиваем. Значит, наш сервер приложений придётся обучать опросу каждого типа счётчика или устройства. КАЖДОГО. Свой скрипт опроса на каждую модель.

Тут можно немного срезать угол и взять универсальный софт, который это уже умеет. Конкретно для ЖКХ есть много предложений со скриптами опроса на 200-300 различных моделей счётчиков. Но это платно, плюс затраты на интеграцию в вашу систему. А главное – мы не решаем проблему занятости эфира.

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

Решение кроется в интеграции скрипта опроса в сам радиомодуль. Это требует усилий, но результат того стоит. Кто-то может сказать, что при таком решении у нас зашкалит энергопотребление. Однако, RS-485 всегда близко к электричеству. К примеру, тот же теплосчетчик "Эльф" без внешнего питания вам ничего не выдаст. Потому те радиомодули, что работают с RS-485 – это обычно устройства класса С, то есть не подразумевающие батарейное питание. Это логично, ведь работая через прозрачный канал, мы можем обратиться к устройству в любой момент. Значит, радиомодуль должен быть всегда готов установить связь. А это класс С.

Интегрируя скрипт внутрь, мы можем передавать в эфир лишь сухие данные. Дальше: оптимизируй - не хочу. Опрос можно настроить по расписанию, архив хранить на сервере и прочие хитрости. Да, с высокой вероятностью придётся отказаться от батареи. Но мы всё же получаем компактный беспроводной модуль с отличной помехозащищённостью, который требует лишь питания. А питание рядом с RS-485 найдётся.

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Учитесь работать с RS-485.

Только своё

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

В принципе, на первое время хватит. Однако дальше вы поймёте, что требуется то одно, то другое. Специфичные запросы будут поступать от клиентов. И на бесплатном софте вы далеко не уедете. А потому надо писать своё. Насколько глубоко – решать вам, но интерфейс клиента точно должен быть свой. С хорошей базой данных (не SQLite, которой станет плохо уже к третьей сотне устройств), с нужными полями, с необходимыми аналитическими инструментами. И заделом на расширение в ту сторону, в которую вы двигаетесь.

На рисунке 6 приведен скрин нашего интерфейса. Любой пользователь видит показания своих счётчиков через личный кабинет, он доступен из Интернета. В личном кабинете есть не только показания счетчиков, там же сгруппированы другие наши услуги, вроде теледомофонов или обращений в ЖКХ (эти продукты компании "Интерсвязь" заслуживают отдельного описания, и в данной статье мы их не будем касаться).

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Интерфейс пользователя компании "Интерсвязь".

Война с проприетарностью

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

Это не пустые слова. Не так давно к нам обратился клиент, который хотел использовать свои, купленные на стороне, радиомодули. Долго рассказывать предысторию не буду, передам суть. У него радимодули не компании Вега, т.е. не те, что используем мы.

Для начала работы потребовалось лишь разграничить ответственность и подогнать наш интерфейс под формат пакетов (что не слишком сложно). И всё. Это работает почти как мобильный телефон! Не важно, где вы купили телефон и чья симка, если они соответствуют стандарту, они будут совместимы между собой и будут работать в сети оператора!

Ау, проприетарность? Возможно такое в Стриже или NB-Fi?

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

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

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

Безопасно ли?

Еще одним моментом, на который часто обращают внимание в LoRaWAN – безопасность.

Напомню, безопасность в стандарте реализуется двумя ключами. Любой пакет шифруется ключом сетевого сервера и сервера приложений. Безопасность в квадрате.

Слабым моментом этого метода является тот факт, что ключи либо заданы изначально (метод ABP) либо генерируются в момент активации устройства (OTAA). И всё! Они будут использоваться вечно (ABP), либо до переактивации устройства (OTAA). Даже в последнем случае счёт может идти на месяцы.

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

На практике там ключи AES-128 бит с режимом CBC. Я не буду останавливаться подробно на том что это, кому интересно погуглите. Тема безопасности в LoRaWAN вообще заслуживает отдельной статьи.

Факт остается фактом. Истории пока неизвестны примеры взломов LoRaWAN. А уже в октябре прошлого года вышла спецификация LoRаWAN 1.1 где в архитектуре появляется join server. Он решает проблему старых ключей. Словом, дыра в безопасности очень условная и по факту уже закрыта.   

Куда дальше?

Несомненно, что LoRa и LoRaWAN уже стали общепризнанным стандартом Интернета Вещей. Разумеется, в своей нише. И да, их конкуренты по-прежнему не дремлют. Мы не забыли ни про NBIoT, ни про SigFox. Однако именно LoRa становится самым активноразвивающимся стандартом. Сети на его основе строят уже сотовые операторы, которым вроде только на NBIoT бы и сидеть.

Что будет дальше? Дальше будет расширяться покрытие сетей, будет расширяться линейка устройств. Водо-, электро-, теплосчётчики с интегрированными модулями LoRaWAN уже обыденность.

Будут внедряться улучшения спецификации 1.1 и будут выходить новые. Кстати, теперь LoRa Альянс официально утвердил российский частотный план.

Практический опыт эксплуатации сети LoRaWAN. Заметки IoT-провайдера
Российский ЧП в спецификации LoRaWAN 1.1

Операторы на местах будут расширять линейку услуг. К примеру, "Интерсвязь" будет увеличивать объём поддерживаемых устройств, в зависимости от потребностей, глубже заходить на рынок промышленного Интернета, предлагать свои услуги мониторинга и контроля уже не только ЖКХ, ресурсоснабжающим компаниям и ритейлу, а предприятиям и заводам.

Не забыт и потребительский сектор

"Интерсвязь" готовится выпустить на рынок герконы с LoRaWAN. Это небольшие устройства, с ответной частью. Крепите такое на дверь, ответную часть на косяк и каждый раз при размыкании геркона (т.е. открытии двери) будет приходить оповещение в наше Мобильное Приложение. Можно использовать для наблюдения за объектом или просто контролировать, пришёл ли ребенок домой из школы. Никаких проводов, только небольшая батарейка. Просто и удобно.

Вот так незаметно будущее приходит в нашу жизнь и делает её удобнее, безопаснее и проще.


Олег Плотников
Директор Центра Промышленного Интернета, компания "Интерсвязь"

От редакции

Мы попросили прокомментировать эту статью одного из ведущих технических специалистов компании "НАГ", Дмитрия Полякова. И вот что он сказал: 

Компания НАГ не делает ставку на какую-то одну транспортную технологию. В частности, если позволяет инфраструктура, наши решения могут быть подключены не только по беспроводным каналам, но и через кабель. Для этого у нас имеется целое семейство устройств удалённого контроля SNR-ERD. Из беспроводных систем мы используем, например, решение от "Веги", но не забываем и о стандарте NB-IoT, закладываясь на возможность его использования уже на стадии проектирования. А наработанный опыт позволяет достаточно оптимистично смотреть на возможность освоения и любой другой системы передачи данных вообще. 

77 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews
Материал: Здравствуйте, уважаемые читатели. Те, кто занимается или просто интересуется темой Интернета Вещей. В своей прошлой статье я рассказывал о работе компании «Интерсвязь» в сфере IoT. Напомню, примерно год назад мы приступили к реализации проекта по телеметрии. Наша новая услуга подразумевала опрос приборов учета через технологию LoRa. LoRa – это стандарт, специально заточенный под IoT. Полный текст
hobohobo
hobohobo
Отличная была бы статья, если б не табличка про время в эфире и иже с ним. Цифры там кривые. Длина преамбулы в LoRaWAN восемь символов, а при расчете данных для таблички явно использовалась длина в шесть символов. Для SF11 и SF12 не учитывалась low data rate optimization. 51 байт - это ограничение на application payload, а размер PHYPayload для вычисления time on air в этом случае будет 64. В uplink сообщениях есть CRC, в downlink - нет, это тоже влияет. Ну и coding rate, понятно, существенно влияет. После этого рассказы про радиопланирование выглядят неубедительно.
Олег Плотников
Олег Плотников
1 час назад, hobohobo сказал:

Отличная была бы статья, если б не табличка про время в эфире и иже с ним. Цифры там кривые. Длина преамбулы в LoRaWAN восемь символов, а при расчете данных для таблички явно использовалась длина в шесть символов. Для SF11 и SF12 не учитывалась low data rate optimization. 51 байт - это ограничение на application payload, а размер PHYPayload для вычисления time on air в этом случае будет 64. В uplink сообщениях есть CRC, в downlink - нет, это тоже влияет. Ну и coding rate, понятно, существенно влияет. После этого рассказы про радиопланирование выглядят неубедительно.

Именно потому я добавил в строчку с временем нахождения в эфире слово "примерно")

Чтобы ориентировочно оценить это самое время. Если обратите внимание, то расчет везде ведется для 51 байта полезной нагрузки. Преамбула везде 8, но на SF12-SF10 у меня, очевидно, залип калькулятор. Там правда получается 6, сейчас специально еще раз пересчитал.

С калькулятором такое бывает. А вот low dara rate optimization не учел, это уже чистая ошибка. В общем, не очень корректно сделал подсчеты, признаю.

 

Что же касается подсчетов отдельно для up и down link и прочего - если выкатывать полностью все для всего - получится несколько избыточно.

Общей сути это не меняет. Я хотел показать разницу различных SF и то, насколько там отличаются параметры. Думаю, читатели прониклись)

 

Что же касается радиопланирования - тут вступают совсем иные факторы. Диаграмма направленности антенны, высота подвеса, расположение относительно рельефа и других зданий, расположение относительно оконечных устройств. Семтеховский калькулятор вам не поможет сделать такие расчеты, он несколько про другое.

 

 

 

hobohobo
hobohobo
Чистая ошибка - это что explicit headers не были включены :-) И получается там от 2.4 до 3.5 секунд, в зависимости от CR. Все-таки солидная разница с 1.9 сек., считать ли эти цифры примерно одинаковыми - вопрос вкуса :-) SF - это, в общем, степень двойки. В калькуляторе четко видно, что разница в symbol duration между смежными SF два раза. Про 51 байт... Полезная нагрузка - это же payload, так? Так который? У Вас в расчетах это явно phy payload, т.е. по данные приложения остается 38 байт. Но беды тут нет, в общем. В смысле, на точности расчетов не сказывается. По поводу CRC - важно понимать, как байты в пакете пересчитываются в символы LoRa, и не забывать рассказывать это людям. Добавление одного байта (например, CRC :-) ) может вообще не повлиять на время передачи пакета, а может его изрядно (на продолжительность одного символа) увеличить.
hobohobo
hobohobo
И из любопытства - а что конкретно вас (и лично Вас) в реализации ADR Арне Брокааром не устроило?
sdy_moscow
sdy_moscow

Чем-то это мне напоминает "пионер нет" на 2,4 ГГц с допиленными линксисами, PCI картами и т.д. Как только вырастет плотность устройств и количество базовых станций - всё это превратиться в "вечно не работающий" вай-фай. У подобных систем на не лицензируемых частотах перспектив особо нет, а на лицензируемые придут пионеры 2-го поколения с ЛоРа "юбикьюти", и придется ставить по 2 базовые станции на подъезд, что-бы хоть как-то работало.

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

hobohobo
hobohobo
8 минут назад, sdy_moscow сказал:

В многоквартирных домах - боюсь эфир быстро превратится в "какашку", особенно если жильцы начнут ставить что-то у себя в квартирах.

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

 

16 минут назад, sdy_moscow сказал:

 и придется ставить по 2 базовые станции на подъезд, что-бы хоть как-то работало.

 

Да :-) Для этого уже есть модные названия "picocell" и "femtocell" :-) И уже есть места, где по две стоят :-) И не только в подъездах.

askue-map.jpg

В некоторых местах откровенно парами БС стоят. Надо понимать, потому как в полудуплексе работают :-) Одна в эфир гадит, другая ответы принимает. Судя по тому, что видно в эфире... Да еще и на вражьих неразрешенных частотах.

Связной (С)
Связной (С)

864 - 865 МГц 

устройства малого радиуса

Максимальная ЭИМ = 25 мВт

 

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

 

4 часа назад, sdy_moscow сказал:

Как только вырастет плотность устройств и количество базовых станций - всё это превратиться

- устройства малого радиуса действия не должны создавать недопустимых помех и не должны требовать защиты от помех со стороны радиоэлектронных средств.

sdy_moscow
sdy_moscow
3 часа назад, Связной (С) сказал:

864 - 865 МГц 

устройства малого радиуса

Максимальная ЭИМ = 25 мВт

 

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

 

- устройства малого радиуса действия не должны создавать недопустимых помех и не должны требовать защиты от помех со стороны радиоэлектронных средств.

Это вы расскажите "пионэрам", которые выкручивают мощность и ставят бустеры с направленными антеннами. К сожалению всё это пройденные этапы. В конечном итоге, искать кто гадит в эфире особо никто не будет,  а даже если и найдут - ничего ему не сделается.

Олег Плотников
Олег Плотников
11 часов назад, hobohobo сказал:

Чистая ошибка - это что explicit headers не были включены :-) И получается там от 2.4 до 3.5 секунд, в зависимости от CR. Все-таки солидная разница с 1.9 сек., считать ли эти цифры примерно одинаковыми - вопрос вкуса :-) SF - это, в общем, степень двойки. В калькуляторе четко видно, что разница в symbol duration между смежными SF два раза. Про 51 байт... Полезная нагрузка - это же payload, так? Так который? У Вас в расчетах это явно phy payload, т.е. по данные приложения остается 38 байт. Но беды тут нет, в общем. В смысле, на точности расчетов не сказывается. По поводу CRC - важно понимать, как байты в пакете пересчитываются в символы LoRa, и не забывать рассказывать это людям. Добавление одного байта (например, CRC :-) ) может вообще не повлиять на время передачи пакета, а может его изрядно (на продолжительность одного символа) увеличить.

И вновь вы абсолютно правы)

PHYPayload = MAC Header (1 байт) +  MAC Payload (в SF=12 до 59 байт) + MIC (4 байта). Из них полезного только 51 байт и то если управляющих команд от сервера не поступит.

Разбирая все обратно 51 - MAC Header (1 байт) - MIC (4 байта) - 8 байт из MAC Payload, в которых не передать полезную нагрузку, выходит как раз 38 байт.

 

 

8 часов назад, sdy_moscow сказал:

Чем-то это мне напоминает "пионер нет" на 2,4 ГГц с допиленными линксисами, PCI картами и т.д. Как только вырастет плотность устройств и количество базовых станций - всё это превратиться в "вечно не работающий" вай-фай. У подобных систем на не лицензируемых частотах перспектив особо нет, а на лицензируемые придут пионеры 2-го поколения с ЛоРа "юбикьюти", и придется ставить по 2 базовые станции на подъезд, что-бы хоть как-то работало.

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

Думаю, что это случится не скоро. Давайте прикинем. Пусть у нас все плохо и все устройства работают на SF=12. Но с подтверждением. На обмен пакетами нужно 4-5 секунд. Все остальное время устройства спят, а БС молчит.

Допустим, у нас стоят счетчики в каждой квартире. Тепло, две воды, электро. Пусть это все по отдельности - на каждом свой радиомодуль. Каждому по максимуму - по 5 секунд в эфире. Да что там, давайте 10, еще ж переповторы будут, коллизии там всякие.  Получается, что в час мы сможем прокачать 360 устройств или 90 квартир. Если выставить отправку показаний раз в сутки, то за сутки - 8640 устройств или больше 2000 квартир. Это 4 огромных дома. Или 10 пятиэтажек.

А теперь представим, что БС работает на небольшом радиусе, значит SF у нас будет пониже. Запросто получим цифры на порядок больше.

А если вспомнить, что у нас есть целых 1,5 МГц и там 7 частот, то можно вообще использовать частотное планирование, как в сотовой связи. Оставить каждому кластеру по три частоты для работы. А если еще применить секторные антенны... В общем, с масштабированием как раз проблем нет. Можно еще несколько хитростей применить)