Связь в интернете вещей: LoRa против UNB. Часть 3: технические тонкости

    Третья из серии статей, посвящённая описанию основных отличий технологий маломощной дальнобойной радиосвязи, получающей сейчас распространение в системах Интернета вещей: широкополосной связи LoRa от узкополосных (UNB, Ultra Narrow Band) систем, таких как Sigfox и «Стриж», а также вопросам их практического применения.



    Привет, GT.

    После первых двух статей, а также живых рассказов по данной теме меня несколько раз просили подробнее рассказать о базовых технических аспектах работы LoRa и UNB-сетей несколько подробнее, чем я рассказывал в первой статье:

    • Разделение каналов в UNB-системах
    • Проблема обратной связи в UNB-системах
    • Разделение каналов в LoRa
    • Адаптивные скорости в UNB и LoRa
    • Помехозащищенность в UNB-системах и в LoRa




    Что ж, приступим. Ниже будет, как обычно, много текста и мало картинок.

    Разделение каналов в UNB-системах


    Одним из достоинств UNB-систем считается эффективное использование ими радиочастотного спектра — в России с минимальными ограничениями доступна лишь скромная полоса шириной 500 кГц (868,7—869,2 МГц), однако при ширине рабочего канала UNB-системы всего 100 Гц таких каналов даже в ней можно уместить тысячи.

    Однако частотное разделение (FDMA) существует лишь постольку, поскольку существует несущая частота — которой разные каналы и отличаются. В обычном радиоприёмном тракте после входного усилителя стоит демодулятор, задача которого — выделить низкочастотную составляющую сигнала, убрав высокочастотную несущую. Очевидно, после такого демодулятора несколько частотных каналов сольются в единую кашу, поэтому никакого FDMA не получится.

    Даже самая сложная проблема имеет простое и очевидное неправильное решение. Таким решением в UNB-системе будет использование нескольких радиоканалов, настроенных на разные частоты. Казалось бы — десять каналов позволят принять десять абонентов одновременно, и все будут счастливы. Увы.

    Одна из серьёзных технических проблем UNB-систем — нестабильность частоты кварцевых резонаторов, задающих рабочую частоту абонентского устройства. Типовой хороший кварц имеет суммарную погрешность ±25 ppm, то есть при частоте несущей 869 МГц реальное отклонение от неё может достигать 21,725 кГц. В результате указывать точную частоту канала, на котором вещает абонентское устройство, совершенно бессмысленно — в реальности это будет плюс-минус лапоть. Никаких способов эту частоту заранее уточнить нет — кроме использования вместо кварцевых резонаторов дорогих термокомпенсированных генераторов (TCXO), которые позволяют уменьшить погрешность вдесятеро.

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

    Более продвинутый вариант, который на практике в серьёзных БС и используется — это оцифровка и последующий спектральный анализ широкого диапазона радиоэфира (десятки-сотни килогерц) в реальном времени. То есть, например, БС принимает широкую полосу в 100 кГц, оцифровывает её, находит в ней отдельные сигналы абонентских устройств, каким-то относительно случайным образом разбросанные по этой полосе, выделяет каждый из них и передаёт дальше на декодеры сигнала. Фактически, современная базовая станция UNB-системы представляет собой SDR-приёмник очень высокой производительности, спаренный с не менее производительным чипом, перемалывающим полученные из приёмника данные.

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

    Практическим следствием из этого является трудность создания бюджетных и при этом эффективных базовых станций для UNB-систем. БС Sigfox стоит в районе 3000 евро, стоимость БС «Стрижа» на сайте не сообщается (но вряд ли составляет менее 100 тыс. руб.), одна из самых популярных БС LoRaWAN — Kerlink — стоит 1200 евро. При этом Kerlink можно считать дорогим решением, ценник которого обусловлен в значительной степени не очень высоким естественным спросом на базовые станции. Готовая плата с трансивером SX1301, к которой для получения полноценной БС остаётся добавить немного мозгов, интерфейс для аплинка, корпус и питание, стоит $180. В общем, по мере наращивания производства LoRa есть куда падать по цене — при том, что уже сейчас Sigfox на её фоне смотрится бледно.

    Кроме того, из этого же следует, что когда вам предлагают некую дешёвую фемтосоту для UNB-системы — надо внимательно изучать, что у неё внутри и каковы её реальные рабочие характеристики.

    Проблема обратной связи в UNB-системах


    Большая относительная нестабильность частоты частотозадающего кварцевого резонатора является прямой причиной одной из наиболее существенных — с точки зрения практического применения — проблем UNB-систем: техническую невозможность симметричной обратной связи, то есть связи БС → абонент.

    Чтобы абонент принял что-то от БС — БС должна вещать на его частоте. Однако в UNB-системе мы заранее попросту не знаем рабочую частоту абонента — в нём стоит кварц, дающий разброс частот в сотни раз больше ширины канала. Просто так увеличить ширину канала приёма на абоненте мы также не можем: это приведёт к ухудшению соотношения сигнал/шум, то есть к уменьшению дальности связи (мы собираем мощность шума со всего широкого канала). Реализовать на абонентском устройстве спектральный анализ — невозможно тем более, слишком маленькие вычислительные мощности.

    Единственный способ что-то передать абоненту в UNB-системе — это дождаться, пока он сам выйдет в эфир, определить на БС его фактическую рабочую частоту и ответить ему на ней же.

    В LoRa выделяются три класса абонентских устройств:
    • Класс A: передав что-то в эфир, устройство непродолжительное время ждёт ответа от БС, после чего выключает приёмник до следующего сеанса связи.
    • Класс B: устройство включает приёмник по заранее заданному расписанию. БС знает это расписание и может передавать данные на устройство в соответствии с ним.
    • Класс C: приёмник включён всегда, БС может передавать данные в любой момент.


    Эти классы — результат компромисса между энергопотреблением и задержкой обратной связи. Например, для многих устройств сбора данных обратная связь если и реализуется вообще, то по классу А: отправили данные на БС, получили от неё подтверждение их получения.

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

    Однако тут мы возвращаемся к UNB-системам: так как, как было сказано выше, БС не может ничего передать абоненту, пока тот сам не вышел в эфир, для них технически возможны только устройства класса А. В этом причина того, что на Sigfox и «Стриже» строят различные системы сбора данных, но вот если вы попытаетесь найти АСУНО с использованием UNB-радио, вас постигнет неудача.

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

    Обратная связь и реальная ёмкость сети


    Один из важных моментов, который необходимо понимать применительно к любым системам связи в IoT, будь то LoRa или UNB-системы — использование обратной связи для подтверждения доставки пакетов от абонента к БС сильно уменьшает реальную ёмкость сети.

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

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

    Кроме того, как правило, для типовых систем подтверждение доставки данных абоненту не требуется: например, счётчик в ЖКХ может ежесуточно сбрасывать на БС текущие показание, и если сегодня они из-за помех в эфире не дошли — ну, скорректируются завтра, невелика беда. Тем не менее, если вы планируете строить радиочастотную сеть с гарантированной доставкой данных от абонентов к БС, необходимо учитывать, что это сильно уменьшает её ёмкость.

    Тем не менее, в локальных сетях с не слишком большим количеством абонентов — до нескольких сотен штук, например, для которых важна регулярность отправки данных, подтверждение доставки имеет право на жизнь. В случае, если доставка не состоялась из-за какой-то кратковременной помехи или коллизии с другим абонентом, конечное устройство может попробовать её несколько раз повторить — пока либо не получит подтверждение от БС, либо не убедится в том, что проблема носит перманентный характер.

    Разделение каналов в LoRa



    Технологически LoRa — весьма интересное изобретение: если тот же Sigfox использует стандартные механизмы модуляции (дифференциальную фазовую модуляцию, DBPSK), благодаря чему может работать на различных чипах с соответствующим программным стеком, то для LoRa была разработана своя собственная схема модуляции, реализуемая в железе.

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

    LoRa уходит корнями в DSSS — широкополосную модуляцию с прямым расширением спектра, при которой исходный информационный сигнал искусственно размазывается на широкий кусок спектра. Принцип работы широкополосных систем напрямую следует из предела Шеннона (он же теорема Шеннона-Хартли) на максимальную скорость безошибочной передачи данных в канале с ограниченной полосой пропускания в присутствии шума:

    S = W × log2(1 + P/WN0), где

    S — максимальная скорость в канале связи, бит/с
    W — ширина канала, Гц
    P — мощность сигнала на входе приёмника, Вт
    N0 — средняя спектральная мощность шума на входе приёмника, Вт/Гц
    P/WN0 — отношение сигнал/шум (SNR) на входе приёмника

    С одной стороны, использование широкой полосы при прочих равных ухудшает соотношение сигнал/шум — так как шум интегрируется приёмником со всего прослушиваемого им диапазона, то в простейшем случае (при отсутствии в эфире узкополосных помех и N(f) = const) мощность шума прямо пропорциональна полосе сигнала. С другой стороны — SNR в уравнении внутри логарифма, а вот ширина полосы сигнала — снаружи, поэтому на практике увеличение полосы оказывается выгодным с точки зрения увеличения скорости передачи.

    NB: одним из распространённых заблуждений является мнение, что невозможно принять сигнал, лежащий ниже уровня шума. Как очевидно из уравнения, это не так — возможно принять любой сигнал, мощность которого на входе передатчика отлична от нуля, вопрос только в том, какой скорости передачи данных вы сможете достичь. Все современные IoT-системы дальней связи способны принимать сигналы, лежащие ниже уровня шума.

    Перед разработчиками LoRa — кстати, в оригинале это был не Semtech, а небольшая компания, впоследствии купленная Semtech — стояла задача адаптировать DSSS так, чтобы его можно было эффективно реализовать в недорогой системе с низким энергопотреблением. Собственно, им это удалось. При этом, в отличие от UNB-систем, LoRa, как я уже неоднократно подчёркивал — система абсолютно симметричная, поэтому любой чип с поддержкой LoRa может с равным успехом выступать как приёмником, так и передатчиком.

    Строго говоря, модуляция LoRa может использоваться с самыми разными параметрами сигнала — например, используемые нами в модемах чипы SX1276 поддерживают полосу от 7,8 кГц до 500 кГц, то есть вообще-то могут работать и в узкополосном режиме (правда, при полосе 62,5 кГц и меньше они столкнутся с той же проблемой ухода частота из-за неидеальности кварца, что и в UNB-системах). Впрочем, на практике применительно к LoRa обычно говорят о полосе 125 кГц и, реже, 250 кГц — потому что именно эти полосы используются в сетях LoRaWAN (125 кГц как основная, 250 кГц как дополнительный высокоскоростной канал). Младшие чипы, такие как SX1272, и вовсе не поддерживают ширину полосы менее 125 кГц.

    Вторым параметром кодирования сигнала в LoRa является spreading factor — как очевидно из названия, SF определяет, как именно размазывается исходный сигнал по широкому спектру. Именно SF — основное средство разделения каналов в LoRa: все трансиверы LoRa поддерживают 7 значений SF, ортогональных друг другу; то есть, говоря человеческим языком, позволяющих выделить передачу, закодированную с конкретным SF, при наличии в эфире одновременных трансляций, закодированных с другими значениями SF. Фактически, SF — это реализация кодового разделения каналов (CDMA) на физическом уровне системы.

    У SF есть и второй смысл — он определяет скорость передачи данных. Конкретно с полосой 125 кГц и семью используемыми SF она составляет от 300 бит/с до 5 кбит/с. Какой в этом смысл? Дело в том, что само по себе CDMA-разделение не очень эффективно — помимо не слишком большого количества ортогональных кодов, для работы CDMA необходимо, чтобы одновременно вещающие абоненты не слишком отличались по мощности. В задаче выделения сигнала каждого конкретного абонента все остальные, кто вещает в данный момент — это шум, который решению задачи мешает; один мощный абонент в результате способен забить сигналы от более слабых.

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

    В результате LoRa не всегда корректно сравнивать с UNB-системами по абонентской ёмкости напрямую: если взять набор равноудалённых на близкое к предельному расстояние устройств, то UNB-системы окажутся впереди, но если абонентов расставить на различных расстояниях от БС — как оно в реальности и происходит — то LoRa за счёт более высоких скоростей передачи близких к БС абонентов может выиграть.

    Что касается практических вопросов реализации CDMA в LoRa, то для этого на приёмном устройстве требуются несколько аппаратных демодуляторов. Для полноценных базовых станций Semtech предлагает чип SX1301 — в нём сразу 49 «виртуальных» демодуляторов LoRa и ещё один GFSK, чтобы вам скучно не было. Однако SX1301 достаточно дорог ($80), требует сложной внешней обвязки (у него нет интегрированного радиотракта) и продаётся только напрямую самим Semtech — поэтому в локальных проектах обычно используются базовые станции на одном или нескольких чипах серии SX127x, официально предназначенных для абонентских устройствах. Один SX127x имеет один демодулятор, однако ровным счётом ничто не мешает поставить в микро-БС несколько таких чипов — собственно, если поставить сразу 8 штук, то получится уже фемтосота, способная полноценно работать с LoRaWAN (он требует 7×SF в полосе 125 кГц и 1×SF в полосе 250 кГц), хоть и имеющая чувствительность пониже, чем у полноценной БС на SX1301, но зато и значительно более дешёвая.

    NB: под 49 виртуальными демодуляторами Semtech имеет в виду сложную схему, в которой есть 9 физических демодуляторов, при этом один работает на фиксированном SF, а оставшиеся 8 могут работать каждый с любым прилетевшим из эфира SF, да ещё и на своей собственной частоте. Считать их 48 демодуляторами не всегда корректно, потому что, очевидно, если все восемь их все на одну частоту, они смогут разгребать всего семь одновременных сообщений (по числу SF) — но так указывает Semtech.

    Прелесть LoRa — именно в дешевизне, простоте и абсолютной симметричности решений для абонентских устройств и БС. Если в UNB-системах на БС мы моментально погружаемся в вопросы использования многогигагерцовых АЦП и цифровой обработки радиосигнала в реальном времени, то в LoRa любое абонентское устройство может использоваться в качестве микро-БС при установке на него соответствующей прошивки. При желании, одноканальную базовую станцию LoRa можно за вечер соорудить дома из готового LoRa-модема и Raspberry Pi — чего нельзя сказать про UNB-системы. Такая БС позволяет собирать данные с сотен абонентов на площади в несколько квадратных километров — и этого более чем достаточно, например, для большинства задач мониторинга в сельском хозяйстве и на производственных объектах.

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

    При этом FDMA в LoRa, как правило, не используется, хотя технически ничто не мешает сделать базовую станцию с 2-3 частотными каналами. При этом каждое абонентское устройство будет получать фиксированный частотный канал — схема с быстрой псевдослучайной перестройкой частоты в LoRa неэффективна из-за длинной преамбулы в сигнале абонентского устройства. В больших БС на SX1301 такую схему можно реализовать на одном чипе — 8 вышеупомянутых физических демодуляторов LoRa в нём позволяют настраиваться на индивидуальные частоты с отклонением до ±2 МГц от центральной; но надо понимать, что если на один частотный канал настроен один демодулятор, то в этом канале кодовое разделение работать не будет: абонентские устройства могут вещать с любым SF, но в каждый конкретный момент времени демодулятор сможет обрабатывать только один конкретный SF.

    Адаптивные скорости в UNB и LoRa


    Если уж мы заговорили об адаптивной скорости в LoRa, то стоит пролить свет и на вопрос, почему адаптивные скорости не столь популярны в UNB-системах. Конечно, у них — при достаточной вычислительной мощности БС — меньше проблем с разделением абонентов, но с другой стороны, адаптивная скорость — это не только больше свободного эфира, но и меньшее энергопотребление на стороне абонента.

    Увы, помимо скромной ширины канала, в UNB-системах два обстоятельства затрудняют увеличение скорости сверх типичных 100 бит/с.

    Во-первых, это производительность процессора базовой станции. Как мы увидели выше, для эффективной работы БС должна делать спектральный анализ принимаемого широкополосного сигнала в реальном времени, выделяя из него узкополосные сигналы отдельных абонентов. Слова «в реальном времени» имеют здесь вполне конкретный количественный смысл: частота вычисления БПФ — это частота дискретизации сигналов абонентов. Поэтому любая попытка серьёзно увеличить скорость связи с абонентами в UNB-системе требует столь же серьёзного увеличения производительности системы цифровой обработки сигнала. А при том, что мы говорим о ЦОС с исходной частотой почти в гигагерц — приятного в таком требовании мало.

    Во-вторых, есть и ещё одно ограничение, которое не позволит увеличить скорости UNB-систем до уровня LoRa при сохранении их прочих характеристик — это вышеупомянутый предел Шеннона:

    S = W × log2(1 + P/WN0), где

    Если подставить в это уравнение конкретные числа — мы увидим, что при SNR в 60 дБ UNB-система ограничена скоростью масштаба 2 кбит/с, LoRa же уходит в мегабиты (естественно, такие скорости на практике не реализуются, так что по факту такой результат означает, что в рамках используемых технологий теоретических ограничений по скорости с этой стороны мы в LoRa не имеем).

    На практике это приводит к тому, что адаптивные скорости в UNB в случае с Sigfox не реализуются вообще, а в случае со «Стрижом» понять, что и как там реализуется, традиционно невозможно: представители компании здесь, на GT, пишут, что адаптивные скорости есть, но на официальном сайте для устройств, включая собственно базовые станции, указана фиксированная скорость 100 бит/с, в табличке сравнения с LoRa там же — аж 25600 бит/с, но тут уже Шеннон, Котельников и Хартли с очевидностью передают теплый привет и настойчиво просят урезать осетра.

    Помехозащищенность в UNB-системах и в LoRa


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

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

    LoRa достаточно чувствительна к широкополосным помехам: так, две БС LoRa, работающие рядом на одной частоте, будут довольно сильно мешать друг другу. Одновременно с этим, чувствительность LoRa к узкополосным помехам часто преувеличивается — на практике в LoRa есть избыточность кодирования, достаточная, чтобы спокойно переживать соседство с узкополосными системами, в том числе системами с псевдослучайной перестройкой частоты. Узкополосной системой, сыпящей в эфир непрерывным потоком сообщений, LoRa заглушить можно — и я даже знаю некоторые прецеденты, как компании, продвигающие такие системы, пытались устроить такое глушение на сравнительных испытаниях, однако это, очевидно, не было случаем штатной работы узкополосной системы, и должно рассматриваться в первую очередь в свете Гражданского Кодекса. Не говоря уж о том, что такая работа одной UNB-системы создаст проблемы другим UNB-системам, если такие будут работать в том же диапазоне — даже если не удастся заглушить их полностью, процент корректно доставленных сообщений резко упадёт.

    Тем не менее, если в эфире есть сильная помеха — LoRa от неё деться некуда. В то же время абонентское устройство UNB-системы имеет возможность перестроиться на полсотни килогерц в любую сторону — в силу описанной выше общей неопределённости с конкретной рабочей частотой базовая станция его сигнал всё равно поймает. В частности, в UNB-системах можно эффективно реализовывать схему listen-before-talk: устройство перед включением передатчика слушает эфир, если в нём на его полосе слишком шумно, оно переключается для передачи в другую полосу. Эта схема не будет работать, если источник шума расположен далеко от устройства и близко к БС, однако во многих случах может помочь. Впрочем, реализована ли эта схема вообще в том же «Стриже» и если да, то как — вопрос открытый, компания на своём сайте на него не отвечает.

    В целом же надо заметить, что помехозащищённость систем дальней связи для IoT — это вопрос не только технический, но и политический. Ситуация, когда крупные системы связи строятся в слаборегулируемом безлицензионном диапазоне, привлекательна с точки зрения их раннего внедрения, но бесконечно продолжаться не может — безлицензионные диапазоны эффективны лишь до тех пора, пока в них не слишком много желающих занять эфир. Весьма вероятно, что в течение нескольких лет — по мере развития глобальных IoT-сетей — начнут обсуждаться изменения в распределении спектра с тем, чтобы выделить для таких сетей лицензируемые частоты и тем самым как упростить их развёртывание, так и избежать случаев прямого саботажа одним оператором работы своих конкурентов. Безлицензионный диапазон при этом останется для проектов масштаба объекта — где сеть находится в полном распоряжении владельцев этого объекта, а потому ни с кем не конкурирует.

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

    Вместо послесловия




    Это, конечно, очень грубая табличка, сравнивающая лишь определённые аспекты трёх коммерческих доступных в настоящее время технологий. В реальности тема IoT-связи большой дальности сколь популярна, столь и необъятна — про разные её аспекты, от радиопланирования до программного обеспечения, можно говорить долго. При этом понимание этих аспектов среди что системных интеграторов, что потенциальных заказчиков таких систем до сих пор крайне низко и базируется в основном на бравурных пресс-релизах некоторых компаний о том, как они уже обслуживают десятки тысяч квадратных километров и целые города-миллионники (на самом деле ни у одной компании в России на данный момент ещё нет живых крупных проектов в этой области).

    Вживую осветить эти же темы я планирую на грядущей конференции Highload++ 2016, в которой в этом году появился раздел IoT.

    Если же ваша компания заинтересована как в ликбезе по современным беспроводным IoT-технологиям, так и в сотрудничестве по разработке конечных устройств для сетей 6LoWPAN и LoRa и проработке проектов на их базе — обращайтесь. Мы это немного умеем.

    Компания Unwired Devices занимается разработкой и производством модулей связи для ячеистых сетей 6LoWPAN и сетей дальней связи LoRa, а также датчиков и других оконечных устройств для данных сетей, включая как аппаратную часть, так и прошивки с поддержкой необходимых сетевых технологий. В случае с сетями LoRa мы разрабатываем все возможные топологии: ячеистые и статические радиорелейные сети, объектовые сети типа «звезда» с одной БС и устройства для глобальных сетей LoRaWAN.
    Unwired Devices LLC
    0,00
    Мы делаем вещи для Интернета Вещей
    Поддержать автора
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 20

      +1
      Интересно, спасибо. Сразу несколько вопросов, сначала простых:

      1. Реально ли использовать в LoRa CDMA поверх семи spreading factor'ов? Или 7 — это предел абонентов, если не используется TDMA?

      2. Почему битрейт на самом быстром SF решили ограничить 5 кбит/с, если Шеннон сотоварищи обещают нам много больше?

      И чуть более философских:

      3. Пусть у нас ширина канала 125 кГц, а на улице жаркий солнечный день. Кварц абонента уходит на 25 кГц, и когда он говорит на самом быстром SF, его сигнал начинает вылезать за границы канала с одного из краев. Наблюдается ли это на практике? И если да, то что делать — смириться с потерями, перейти на меньший SF, что-то еще?

      4. Обратная связь БС → абонент. Насколько уменьшается емкость сети с ее появлением (на вашем опыте)? Здравый смысл подсказывает, что проблемы начинаются, когда ресурсы TDMA исчерпаны. Но при этом, казалось бы, никто не мешает зарезервировать 5 секунд в конце каждой минуты для получения коротких сообщений от БС в духе «абонент такой-то, прием подтверждаю» — это 10% всего эфира, не более.
        +1
        1. Нет. Даташит описывает только семь валидных значений для соответствующего конфигурационного регистра чипа, как он будет реагировать на что-то иное в нём — одному Семтеку известно. Скорее всего, ошибкой.

        2. Шеннон с коллегами устанавливает теоретический предел. Практический много чем определяется — той же работой демодуляторов, например.

        3. При уходе частоты на 30 % от ширины полосы (т.е. в стандартном случае — на 37,5 кГц) будет 10 % ошибок в принятых пакетах. С потерями ничего не делать — изначально проектировать систему так, чтобы они были приемлемыми; для LoRa в этом нет принципиальных сложностей — на абонентское устройство ставится кварц с ±10±15 ppm, на БС — TCXO, там лишний доллар стоимости роли не играет.

        4. Ёмкость сферической сети в вакууме в таких системах вообще не имеет смысл — я морщусь каждый раз, когда читаю что-то в духе «наша супер-пупер БС может обслуживать миллион абонентов». Ну да, может, если каждый из них передаёт два байта раз в неделю. А если пятнадцать байт и раз в час — то не может.

        Поэтому надо считать на конкретном примере: сколько абонентов, с какой периодичностью выходят в эфир, сколько данных передают. А там уже можно думать и о прикручивании TDMA, причём описанная вами схема — это чрезмерное усложнение, если мы можем рассортировать абонентов и выделить каждому слот для передачи, достаточно работать по классу А, когда подтверждение отправляется сразу после приёма данных. А если у нас каша и ничего мы рассортировать не можем, то для начала абонент и не узнает, когда случатся эти 5 секунд (это, кстати, типичный класс B — абоненту назначают время, когда ему надо слушать эфир, но не надо в него ничего передавать; класс B удобен для рассылки броадкастов абонентам, сидящим на батарейном питании — можно всем поставить один и тот же короткий слот приёма, а всё остальное время они будут спать).
          0

          Вопрос на самом деле про включение в сеть новых абонентов, когда ресурсы TDMA уже исчерпаны.


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


          В принципе, с тем же успехом можно зарезервировать один из SF для передатчика БС. Наверное, еще какие-нибудь приемы есть, было бы интересно узнать.

            0
            Так а в чём практический смысл этих 5 секунд? Новенький стучится в сеть, получает временной слот для передачи (например, +400 секунд), ждёт его, передаёт свои данные, тут же получает ACK, в котором указан следующий временной слот для передачи. Все счастливы. Если у нас сеть с известными абонентами, а не публичный LoRaWAN — хорошая гибкая схема.

            Отдельный SF для передатчика резервировать бессмысленно — если передатчик работает, всё остальное умерло. Тупо потому, что даже если его вывести на отдельный чип и отдельную антенну, она всё равно на БС будет стоять в 20 см от приёмных антенн — и забьёт на них любые прочие сигналы. Кроме того, фиксированный SF — это с многоканальной БС неэффективно: выбрать низкую скорость — потерять эффективность работы с близкими абонентами, выбрать высокую — не достучаться до дальних.
              0

              Смысл с одной стороны в том, чтобы иметь строгое расписание — так сказать, ordnung =).


              А если серьезно, то в нагруженной системе БС во время ответа новенькому наверняка пропустит сообщения от других абонентов. Им придется повторять посылку, что может привести к наложению на других абонентов, и так далее — в итоге есть опасение, что нагрузка на эфир только возрастет.


              Про передатчик БС понятно — когда говорят пушки, музы молчат.

                0
                Так в системе с тотальным орднунгом БС знает, когда другие абоненты хотя послать сообщение — так что новенькому ответить в ближайший свободный слот (новенький при джойне в сеть, очевидно, должен ждать первого ответа какое-то разумное время).
                  0

                  Так по сути оба решения ("5 секунд" и "когда получится") — одного поля ягоды: новенький ждет какое-то время ответа и потом добавляется в расписание. Разница в количестве орднунга.


                  Да, по поводу расписания. Пусть один из абонентов послал данные на БС, но не получил подтверждения и нового времени ожидания. Тогда он попробует передать данные еще раз. Понятно, что при полном орднунге вторая попытка наступит ровно через один период орднунга.


                  А вот если орднунга нет, то какое время ожидания будет оптимальным? То, которое было в прошлый раз — так это долго, плюс не факт, что не будет коллизии. Рандомное небольшое число секунд — это быстро, но вероятность коллизии становится еше выше.

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

                      А что предпочтительнее из вашего опыта — орднунг или его отсутствие?


                      И про абонентов: у них есть часы реального времени? Или же счетчика тактовых импульсов достаточно?

                        0
                        Зависит от сети. Если она под вашим полным контролем — логично устроить орднунг, если это LoRaWAN, в которой вы пускаете толпы третьих лиц — полноценного орднунга не получится по определению.

                        Что есть у абонента — определяется его конструкцией. RTC обязательным элементом не является.
        +1
        А зачем в SX1301 49 демодуляторов, если кодов ортогональных только 7?
          +1
          Там навороченная система из этих демодуляторов внутри:

          * 1 канал FSK
          * 1 канал LoRa, работающий с полосой 125, 250 или 500 кГц с одним конкретным выбранным SF
          * 8 каналов LoRa, работающих только с полосой 125 кГц, зато с любым SF (без его предварительного указания) и с произвольным сдвигом частоты для каждого канала на ±2 МГц от центральной

          Собственно, вот эти 8 каналов Semtech рассматривает как «эмуляцию 48 каналов LoRa».

          Сейчас дополню в статье, чтобы было понятнее.
          0
          Из статьи:
          …оцифровка и последующий спектральный анализ широкого диапазона радиоэфира (десятки-сотни килогерц) в реальном времени… Такая система действительно позволяет принимать большое число абонентских устройств одновременно, но это — цифровая обработка сигнала на близкой к гигагерцу частоте в реальном времени, то есть, тяжелая вычислительная задача, требующая от БС весьма серьёзных ресурсов.

          Ниже:
          Как мы увидели выше, для эффективной работы БС должна делать спектральный анализ принимаемого широкополосного сигнала в реальном времени, выделяя из него узкополосные сигналы отдельных абонентов. Слова «в реальном времени» имеют здесь вполне конкретный количественный смысл: частота вычисления БПФ — это частота дискретизации сигналов абонентов. Поэтому любая попытка серьёзно увеличить скорость связи с абонентами в UNB-системе требует столь же серьёзного увеличения производительности системы цифровой обработки сигнала. А при том, что мы говорим о ЦОС с исходной частотой почти в гигагерц — приятного в таком требовании мало..

          Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость. Хотя да, для реализации приёма, близкого к оптимальному, вычислений много — Стриж пишет, что NVIDIA CUDA применяет в «больших» БС. Вы пишите так, будто бы с точки зрения обработки LoRa нужно меньше ресурсов. Если обработка и там, и там оптимальна, то необходимая производительность определяется лишь количеством информации, которое необходимо получить. Для полноценной LoRaWAN полоса обрабатываемого эфира ещё шире, поэтому «рилтаймовость» даже больше. Просто до поры до времени она от вас спрятана в относительно скромном чипе.

          olartamonov, а здесь вы пишите:
          Одна из серьёзных технических проблем UNB-систем — нестабильность частоты кварцевых резонаторов, задающих рабочую частоту абонентского устройства. Типовой хороший кварц имеет суммарную погрешность ±25 ppm, то есть при частоте несущей 869 МГц реальное отклонение от неё может достигать 21,725 кГц.

          И ниже в комментариях:
          3. При уходе частоты на 30 % от ширины полосы (т.е. в стандартном случае — на 37,5 кГц) будет 10 % ошибок в принятых пакетах. С потерями ничего не делать — изначально проектировать систему так, чтобы они были приемлемыми; для LoRa в этом нет принципиальных сложностей — на абонентское устройство ставится кварц с ±10±15 ppm, на БС — TCXO, там лишний доллар стоимости роли не играет.

          Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN. Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах. Не замерял, возможно, со случайным сдвигом между передачами. Так что побоку повышенная точность кварцев — можно использовать дешёвые. Доллар в пользу UNB.

          Если на стороне БС для UNB удастся реализовать оптимальное декодирование DBPSK с избыточностью, то не исключаю возможности успешного декодирования сообщений даже при их взаимном наложении в эфире. Если взаимные помехи модемов не мультипликативны и сообщения не когерентны, то сигнал-шум упадёт, но возможнось расшифровки не пропадет полностью. В общем, чем ближе методы приёма к оптимальным, тем размытее граница между широкополосными и узкополосными модуляциями. Остаются лишь соотношения энергий сигнала и шума за время и в полосе сообщения. И мне нравится фундаментальное преимущество узкой полосы — низкая энергия посторонних шумов эфира и приёмного тракта в полосе сигнала.

          В защиту LoRaWAN скажу, что сеть будет внедряться и работать повсеместно. Протоколы взаимодействия хорошие, гибкие. Все проблемы решаются спросом. Будет спрос — буду БС стоять хоть в каждом квартале, каждом дворе — пикосоты. Проблемы ёмкости отпадают с увеличением количества малых БС.
            0
            Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость


            В антенну прилетел почти гигагерц — соответственно, этот почти гигагерц таки надо как минимум оцифровать. С хорошим частотным и временным разрешением.

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


            Не порите чушь, ей больно. В LoRa задача найти в 500 кГц эфира, где именно тут только что квакнул передатчик с полосой 100 Гц, вообще не стоит.

            Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN


            Вообще-то ±10±15 ppm — это максимально возможный уход частоты на 21,7 кГц. Что, как нетрудно заметить, значительно меньше вышеупомянутых 37,5 кГц, при которых LoRa ещё работает.

            Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах


            Смешались в кучу кони, люди. Почему они наплевали на стабильность — написано в тексте: потому что у них нет технически разумных способов эту стабильность обеспечить. Почему они передают последовательно на двух частотах — полагаю, это оригинальный способ борьбы с коллизиями и помехами, «хоть один дойдёт».
              0
              В антенну прилетел почти гигагерц — соответственно, этот почти гигагерц таки надо как минимум оцифровать. С хорошим частотным и временным разрешением.

              Не нужно оцифровывать гигагерц. Используем прямой перенос спектра (естественно, с хорошим временным разрешением) и АЦП с частотой дискретизации чуть выше, чем желаемая полоса эфира. То есть, после переноса спектра, который не слишком сложен, используются обычные, чуть ли не аудио АЦП. Не нужен «рилтайм» на ГГц. Достаточно квадратурного смесителя с контролируемым джиттером.

              image

              На выходе квадратурные составляющие, из которых восстанавливается целый спектр шириной плюс-минус частота дискретизации от 1/4 частоты опорного генератора. Для субгигагерца немногим сложнее, чем на рисунке. Или в LoRa не так делается? Они гигагерц напрямую оцифровывают? Вряд ли.

              Не порите чушь, ей больно. В LoRa задача найти в 500 кГц эфира, где именно тут только что квакнул передатчик с полосой 100 Гц, вообще не стоит.

              Угу. Задача декодирования широкополосного сигнала много проще, по-вашему. ПМСМ, обработку успешно упаковали в чип, поэтому она вам кажется такой простой.

              Про стабильность частоты: не можешь побороть? Возглавь! Весма действенный принцип. Нет смысла достигать стабильности высокой ценой (стоимость и потребление TXCO) в то время как вероятность коллизй с потерей данных невысока даже при активности сотни нескоординированных модемов в полосе ~200кГц.

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


                Почитайте что-нибудь на досуге. Потом ответьте сами себе на вопрос, надо ли вообще оцифровывать несущую или куда-либо её переносить в LoRa.

                Угу. Задача декодирования широкополосного сигнала много проще, по-вашему. ПМСМ, обработку успешно упаковали в чип, поэтому она вам кажется такой простой.


                Мне она кажется простой, потому что я немного знаю схему модуляции LoRa, а также держу в руках крошечный копеечный чип, способный эту модуляцию демодулировать. А не Jetson TK1 с NVIDIA CUDA, которому вентилятор нужен, чтобы он от натуги не сдох (кстати, интересно, как оно будет работать в необслуживаемом варианте зимой на крыше дома, кхм).

                Вообще удивительно, как вы игнорируете физический уровень, который у LoRa и Стрижа тупо разный.

                Про стабильность частоты: не можешь побороть? Возглавь! Весма действенный принцип. Нет смысла достигать стабильности высокой ценой (стоимость и потребление TXCO) в то время как вероятность коллизй с потерей данных невысока даже при активности сотни нескоординированных модемов в полосе ~200кГц.


                Ну то есть CUDA и отсутствие полноценной обратной связи вы считаете низкой ценой?
                  +1
                  Почитайте что-нибудь на досуге. Потом ответьте сами себе на вопрос, надо ли вообще оцифровывать несущую или куда-либо её переносить в LoRa.

                  Почитал. В статье "Возможности использования радиотрансиверов компании Semtech" картинка (с моими пометками):
                  image
                  Стандартная схема. Во всех ВЧ радиоинтерфейсах стараются сразу перенести полосу сигнала на нижние частоты при помощи простых квадратурных смесителей. В на картинке после смесителя АЦП с передискретизацией, поэтому частота работы модуляторов дельта-сигма АЦП больше итоговой частоты дискретизации полосы сигнала. Дальше дециматор/ФНЧ. На демодулятор отсчёты квадратурных составляющих сигнала поступают уже с частотой дискретизации лишь чуть больше полосы принимаемого сигнала. И это даже не десятки МГц, а в лучшем случае единицы МГц.
                  То же самое и у UNB Стрижа. АЦП и ЦОС работают с частотами дискретизации порядка 200кГц-500кГц, не более. Поэтому меня покоробило ваше утверждение, что нужно производить обработку сигнала на гигагерце в реальном времени. Оно, по моему, не соответствует действительности.
                  Вообще удивительно, как вы игнорируете физический уровень, который у LoRa и Стрижа тупо разный.

                  Разный он только с точки зрения модуляции и протокола. На уровне радиочастотной части (до АЦП включительно) принципиальных отличий нет. Так же при оптимальном приёме — с точки зрения радиочастотного ресурса и соотношения энергий все способы передачи равноценны. Вопрос лишь в том, насколько оптимальный приём удаётся организовать.

                  Мне она кажется простой, потому что я немного знаю схему модуляции LoRa, а также держу в руках крошечный копеечный чип, способный эту модуляцию демодулировать. А не Jetson TK1 с NVIDIA CUDA, которому вентилятор нужен, чтобы он от натуги не сдох (кстати, интересно, как оно будет работать в необслуживаемом варианте зимой на крыше дома, кхм).

                  И этот крошечный чип может одновременно декодировать сотни сигналов модемов?
                  Конечно, в нормальных условиях за счёт работы ближних LoRaWAN модемов на высоких скоростях, у вашего копеечного чипа хватит ресурсов на много пользователей. На большой скорости модемы быстрее «отстерляются» в эфир, чем UNB. Но количество одновременно декодируемых каналов меньше, чем у UNB BS с мощным DSP. На больших площадях покрытия с низкими SF уже вопрос, какая БС окажется эффективнее.
                  Насколько мне известно, уже доступны маленькие БС Стриж как наружного исполнения, так и для помещений. Наверняка они имеют меньшую производительность и ёмкость, чем большие БС на CUDA. И меньшую стоимость.

                  Ну то есть CUDA и отсутствие полноценной обратной связи вы считаете низкой ценой?

                  Вопрос в применении. Для БС операторского класса на большую площадь покрытия, с учётом того, что модемы UNB пока дешевле, узкополосная система может быть выгодна. Кроме того, вопрос обратного канала (на LoRaWAN или на 433МГц — я ещё не разобрался) у Стрижа решён — держал в руках и тестировал оборудование, на котором нисходящий канал работает. Для применения уровня ТСЖ — да, LoRaWAN интересное решение, может быть собрано «на коленках». С другой стороны, у Стрижа уже есть маленькие БС. Так что это уже вопрос предпочтений: ценит ли заказчик открытость решений и возможнотсь выбора поставщиков радиомодулей и сильно ли ему нужно создавать свою независимую сеть?
                    0
                    Разный он только с точки зрения модуляции и протокола. На уровне радиочастотной части (до АЦП включительно) принципиальных отличий нет


                    Ага. Примерно как гигабитный эзернет и RS232 — на уровне медной проволоки принципиальных отличий нет.

                    Только дальше у LoRa случается несложный демодулятор, легко реализуемый в дешёвом кремнии,, а у UNB — БПФ по всему каналу в реальном времени, требующий конской вычислительной мощности. Как тут недавно в комментариях выразились — на достаточно низкой скорости LoRa можно вручную декодировать с помощью линейки с миллиметровыми делениями.

                    Насколько мне известно, уже доступны маленькие БС Стриж как наружного исполнения, так и для помещений


                    Насколько мне известно, если большая БС имеет мозгов на сканирование 500 кГц полосы, а маленькая — только на 50 кГц, то сети под эти БС внезапно оказываются друг с другом несовместимы.

                    Интересно, не поэтому ли «Стриж» скромно умалчивает о технических деталях своих решений?

                    И этот крошечный чип может одновременно декодировать сотни сигналов модемов?


                    Он может декодировать как минимум один сигнал. Крошечный чип в UNB может декодировать ровно ноль сигналов.

                    Кроме того, вопрос обратного канала (на LoRaWAN или на 433МГц — я ещё не разобрался) у Стрижа решён — держал в руках и тестировал оборудование, на котором нисходящий канал работает


                    Какой LoRaWAN, какие 433 МГц у Стрижа? Вы вообще о чём? Вопрос обратного канала у них решён только в оборудовании класса А, потому что никак иначе его в UNB решить за разумные деньги технически невозможно.
                      0
                      Грубо говоря, на уровне медной проволоки, до демодулятора, подходы одинаковы.
                      Хочу убедиться, что вы понимаете, что никакой «цифровой обработки сигнала на близкой к гигагерцу частоте в реальном времени» в UNB-системах, равно как и в LoRa, не ведётся. Эта ваша формулировка недвусмысленно предполагает, что цифровая обработка сигнала ведётся на частоте выборки порядка 1ГГц. Это не соответствует действительности для практических реализаций ни UNB, ни LoRaWAN систем. И там, и там используются приёмники прямого преобразования и принцип нулевой промежуточной частоты, когда частота выборок сигнала, на которой ведётся цифровая обработка, лишь немного превышает ширину обрабатываемой полосы эфира. Поправьте, пожалуйста, в статье.

                      По полосе эфира малой БС попробую спросить у Стрижа. Если полоса уже, то под эту БС нужен отдельная серия («батч») модемов прошитых на конкретную частоту. Что не отменяет совместимости этих модемов с «большой» БС.

                      Касательно обратного канала Стрижа. При проверке БС я не увидел в полосе 868МГц передачи от БС, но обратный канал при этом срабатывал. Впрочем, я мог принять сигнал БС за часть ответа модема, который даётся после получения сообщения от БС. Ещё, антенна обратного канала отдельная. Из поставки Стрижа — диполь. И мне она показалась великоватой для 868МГц. Так что мне пока совсем непонятно, на какой частоте и с какой модуляцией реализован обратный канал.
                        +1
                        У Стрижа было решение с обратной связью на 446 МГц с конской мощностью в полватта. Объяснять, почему это — костыли на велосипеде, я полагаю, не надо.

                        Что такое «поставка Стрижа» — вообще одному Стрижу ведомо. У них минимум три аппаратные платформы чисто по приёмопередатчикам (SiLabs, SX1276, Axsem), а уж что там по протоколам и антеннам…

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

          Самое читаемое