Примеры использования и рекомендации для LoRaWAN

Важное примечание: Link Labs является разработчиком Symphony Link, альтернативного протокола для LoRa, ориентированного на высоконадежные промышленные и корпоративные сценарии использования. Подробнее ниже.

Когда вы хотите понять LoRaWAN, его идеальные варианты использования и ограничения, важно немного разобраться в истории. LoRaWAN (тогда называвшийся LoRaMAC) был разработан Semtech (единственный владелец LoRa PHY IP) в сотрудничестве с IBM Research (впоследствии они покинули проект). При разработке протокола были приняты следующие допущения:

• Для использования в сетях операторов мобильной связи.
• В единой скоординированной сети
• В нелицензируемом диапазоне частот 868 МГц.

Это важные предположения, потому что итоговый протокол имеет:

• 1% предела рабочего цикла (как для всех передатчиков, так и для шлюза)
• Общая карта частотных каналов.
• Обработка MAC (уровень 2) только в облаке

В частности, для поддержки ограничения рабочего цикла в 1% для шлюза необходимо сделать много компромиссов:

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

Поскольку все сообщения восходящей линии связи не подтверждены и не скоординированы, LoRaWAN считается схемой «чисто алоха». Такая сеть имеет КПД около 18%. Это означает, что 82% пакетов теряются при полном использовании сети LoRaWAN. Поскольку большинство сообщений не подтверждены, конечный узел не знает, что его сообщение было пропущено. Чтобы предотвратить это, некоторые пользователи могут передавать чаще, что усугубляет проблему. Прочтите этот простой для понимания пост об Aloha Networks.

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

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

Еще одно важное соображение для LoRaWAN - проблема ближнего / дальнего радиуса действия. Поскольку LoRa имеет только 20-30 дБ динамического диапазона в совмещенном канале, узлы, расположенные близко к шлюзу, заглушают узлы, находящиеся далеко. Это не вызывает беспокойства в больших сетях MNO, поскольку в идеале в пределах досягаемости находится несколько шлюзов.

Наши друзья из The Things Network также подготовили эту статью об ограничениях LoRaWAN.

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

• Простые датчики, которым необходимо передавать данные нечасто.
• Иногда можно пропустить 5–85% данных.
• Невозможно управлять этим устройством.
• Нет возможности обновлять прошивку устройства по воздуху.
• Развертываются от десятков до сотен.
• Можно развернуть несколько шлюзов для покрытия каждого узла.

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

Symphony Link решает многие из этих проблем. Вкратце, вот как:

1. Обрамление: Шлюз передает заголовок кадра каждые 2 секунды, который содержит информацию о том, какие каналы восходящей связи доступны и когда открывается окно восходящей связи.

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

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

4. Временной интервал восходящего канала: Из-за синхронного кадрирования окна восходящего канала разделяются, что увеличивает пропускную способность примерно на 100%. Это дополнительно увеличивается за счет добавления переменного окна CSMA перед каждой передачей.

5. Переменная мощность и коэффициент расширения: Конечный узел получает RSSI кадрирующего сообщения шлюза и динамически регулирует свою мощность и коэффициент расширения, чтобы соответствовать каналу плюс настраиваемый коэффициент запаса. Это максимизирует емкость, уменьшает быстрое замирание и предотвращает проблему ближнего / дальнего расстояния, упомянутую выше.

6. Качество обслуживания . Узлы регистрируют коэффициент QOS (0-15) на шлюзе, и это ограничивает их возможность доступа к каналам в каждом кадре. Он также позволяет шлюзу ограничивать исходящие каналы во время перегрузки.

7. Многоадресная рассылка: При назначении групп узлов в группы многоадресной рассылки количество нисходящих каналов, необходимых для управления и потоковой передачи файлов, ограничивается.

8. Фиксированный 256-байтовый MTU: 12 байт слишком мало для большинства приложений. Symphony Link обеспечивает фиксированный MTU в 256 байт и обрабатывает все подпакеты (с помощью SF) и повторные попытки на уровне MAC.

9. Прошивка по воздуху: Благодаря мощным функциям многоадресной рассылки в Symphony Link файлы прошивки могут быть отправлены на узлы.

10. Сеансовые ключи AES на основе PKI . Symphony Link не использует шифрование с фиксированным ключом. Каждый узел установил безопасный сеанс AES с помощью Диффи-Хельмана с открытым ключом узла, предоставленным сервером. Это широко известная в отрасли схема шифрования каналов с наибольшим уровнем безопасности.

Хотите узнать больше? Свяжитесь с нами.