Когда использовать спецификацию LoRaWAN: руководство для MNO и частных сетей

LoRaWAN, созданный LoRa Alliance, — беспроводной протокол, управляющий LoRa LPWA технологией Semtech. Изначально разработанный IBM Research и Semtech для европейских мобильных операторов (MNO), эксплуатирующих широкополосные публичные сети, спецификация теперь поддерживается LoRa Alliance — коалицией, посвященной глобальному развертыванию LoRaWAN в сетях MNO. Следовательно, спецификация воплощает допущения, адаптированные под среды MNO.

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

• Все частотные каналы фиксированы.
  Так как спецификация создана для единой MNO-сети, эксплуатация нескольких некоординированных сетей в одном диапазоне ведет к Layer-2 интерференциям. Для глубокого погружения читайте этот блог-пост.
• Сеть полностью асинхронна. Всякий раз, когда шлюз передает, он не может слушать uplink-трафик, а узлы не знают, что приемник шлюза офлайн. В крупных MNO-развертываниях наличие множественных шлюзов — идеально с одним в режиме «прослушивания» — помогает смягчить это ограничение.

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

Вам следует внедрить спецификацию LoRaWAN в проекте, если выполнены оба условия:

1. Есть необходимость подключиться к существующей LoRaWAN MNO-сети. Очевидно, подключиться к MNO-сети без LoRaWAN невозможно.
2. Юзкейс — низкой плотности, редко передающий и uplink-центричный. LoRaWAN сияет, когда downlink-трафик и подтверждения минимальны. Автоматическое считывание счетчиков (AMR) — яркий пример: большинство счетчиков не требуют частых опросов, а доступная плотность шлюзов обычно дает достаточное uplink-пропускание. Идеально, если рядом нет других LoRaWAN-сетей — интерференция деградировала бы производительность. Сервис EnerTrac/Senet мониторинга топливных баков демонстрирует пригодность LoRaWAN для таких сценариев.

Когда избегать спецификации LoRaWAN:

1. Высокая надежность критична. Некоординированный асинхронный дизайн LoRaWAN делает его лосси-протоколом. В средах с множественными LoRaWAN-сетями интерференция повышает packet-error rate. Кроме того, ограниченный ко-канальный динамический диапазон LoRa означает, что узлы у шлюза могут заглушить дальние без замкнутого контроля мощности.
2. Требуется централизованное управление ключами. Каждый узел должен быть провижен уникальным набором ключей на заводе, которые затем передаются на сервер/шлюз. Для малых развертываний это управляемо, но для тысяч устройств это раздувает стоимость и сложность. MNO управляют этим через SIM-подобные механизмы; частные сети часто находят это громоздким. Для глубокого погружения в структуру ключей и безопасность LoRaWAN см. этот независимый анализ.
3. Нужно расширение покрытия через репитеры. Спецификация LoRaWAN не предлагает поддержку репитеров, поэтому нужно разворачивать дополнительные интернет-подключенные шлюзы. Даже дешевые DIY-шлюзы в 5–10 раз дороже простого репитера.
4. Требуются OTA-обновления прошивки. Ограниченная downlink-емкость LoRaWAN предотвращает эффективные мультикаст-обновления. Устройствам понадобятся физические апгрейды или дизайн без прошивки.

Link Labs адресует многие из этих ограничений. Узнайте больше о Symphony Link, де-факто стандарте для частных LoRa-сетей, здесь.