Концепция переноса обработки сигналов в облако не нова. Во-первых, VRAN (virtual radio access network) это основной способ построения сети операторов сотовой связи. Во-вторых, IoT-сеть компании SigFox строится по тому же принципу, это видно из ее патентов. Проще говоря, это все нереальная круть! Так что же можем сделать мы с вами, чтобы не сидеть на обочине прогресса, а приобщиться к теме?
История вопроса такова: я уже давно занимаюсь радионавигацией, и не смог пройти мимо такого распространенного стандарта радио в интернете вещей, как LoRa. Жутко захотелось сделать для него позиционирование.
Наиболее экономичный способ позиционирования — разностно-дальномерный, в англо-язычной терминологии time difference of arrival (TDOA). Измерители при этом способе могут быть одноканальными, что выгодно отличает их от многоканальных при угломерных методах позиционирования (angle of arrival, AOA). Метод требует измерения относительного времени прихода сигналов на разнесенные в пространстве измерители.
Есть два варианта: первый, привязывать измерения к одной опорной шкале времени, второй, вычислять взаимное время прихода напрямую по взаимной корреляционной функции. Второй требует значительно большей пропускной способности каналов связи с измерителем, но обладает потенциально лучшей помехоустойчивостью. Я выбрал этот подход.
Нужно заметить, что для простоты изложения я пока опускаю вопрос синхронизации несущей частоты и частоты отсчетов измерителей. Этот вопрос надеюсь осветить в следующих публикациях.
Математически второй подход базируется на взаимнокорреляционной функции (ВКФ). Технически это означает, что выборки сигналов должны быть переданы в одно место для вычисления ВКФ. При этом необходимо на всех измерителях, участвующих в позиционировании, выделить по времени отсчеты одного источника излучения. То есть, для построения задуманной системы TDOA-позиционирования LoRa, надо поставить на каждый измеритель по SDR-приемнику с программным демодулятором LoRa, например, таким, какой описан в этой русскоязычной популярной статье. Далее, на каждом SDR-измерителе-приемнике нужно выделять ID излучающего средства и отправлять в центральный вычислитель выборку отсчетов с этим ID. Центральный вычислитель тогда сможет при приеме пакетов отсчетов с одним ID запустить процедуру вычисления ВКФ и процедуру позиционирования. Эта структура показалась мне слишком требовательной к производительности оборудования и сложности софта измерителя. Да и при пиковой нагрузке она давала бы излишнюю нагрузку на канал связи. Поэтому я вспомнил подход к построению структуры обработки сигналов сотовых сетей, который они используют уже давно, а в поколении 5G этот подход должен стать обязательным.
Этот подход называется Virtual Radio Access Network (V-RAN). Можете погуглить по этому сочетанию слов. Я нашел какое-то описание только на английском. Чего-то осмысленно в Wiki по V-RAN нет, зато есть по самой последней концепции — Cloud Radio Access Network или Centralized Radio Access Network (C-RAN). Концепция кажется далекой от реальности — "космические корабли бороздят просторы вселенной".
Как следует из названия, основная особенность заключается в том, что демодуляция сигнала и все последующие стадии обработки переносятся в облако (Baseband hotel). При таком подходе затраты на покупку оборудование снижаются, но появляются затраты на аренду облачных вычислителей, количество которых можно регулировать довольно быстро и удобно, и главное — в соответствии с насущными требованиями. Это приносит экономию. Экономия поверхностно рассматривается в этой статье. А это более подробное изучение концепции.
Удивительно, но низкоскоростная природа IoT делает возможным применение такого "космического" подхода в народном хозяйстве!
Для этого нужно взять Raspberry (или любой другой комп с Linux с поддержкой RTL-SDR и SOAPY) и саму RTL-SDR, которые сейчас имеются у относительно большого числа домохозяйств людей, скачать исходники или бинарники программы, подключиться к облаку и наблюдать сообщения в агрегаторе IoT-сообщений LoRa, таком, например, как The Things Network.
И вам потребуется быстрый интернет. Сейчас поток рассчитывается так: 200 кГц * 32 бита (I, Q) = 6.4 Мбит/с. Потом этот поток сжимается, получается около 3-4 Мбит/с выходит из Raspberry в сторону нашего сервера непрерывно.
Теперь давайте разберем процесс сборки и запуска поэтапно.
Вот RTL-SDR, вставленный в Raspberry Pi 3.
Здесь исходники софта, который берет отсчеты с RTL-SDR, фильтрует и прореживает их и отправляет по вашему интернету в облако. Это делается, чтобы уменьшить скорость передачи данных, требуемую для доставки цифрового сигнала в облако. Софт можно собрать такими необычайно оригинальными командами:
mkdir build
cd build
cmake ..
makeЗатем надо настроить частоту приема (по умолчанию 868.1 МГц), адрес и порт сервера обработки при запуске:
./Bolt5_Client host port [frequency]и запустить программу. Если она выдаст
, то все идет нормально и можно конфигурировать The Things Network (TTN). Это подробно описано здесь.
Для передачи сообщения вам понадобится LoRa-нод. Мы для простоты использовали такой комплект на Arduino:
Затем нужно собственно передать тестовое сообщение и убедиться, что облачная LoRa работает. Пример отправки сообщения с помощью Arduino и LoraWAN shield можно найти тут.
В данный момент возможна отправка сообщения по системе ABP (Activation By Personalization, Активация путем персонализации).
В нашем случае отправляемое сообщение выглядит так:
Сообщение, принятое и записанное в TTN выглядит так:
Сейчас система работает в опытном, ручном режиме. Возможны разные чудеса, но мы стремимся, чтобы все стало стабильно как можно скорее. Так как основной нашей целью является позиционирование LoRa, то мы ищем добровольцев, готовых подключить свое железо (RTL-SDR и Raspberry или другой компьютер) к нашему серверу только в одном определенном районе Санкт-Петербурга: метро Пионерская, Удельная и Коломяги. У нас уже есть два измерителя: один на перекрестке Коломяжского проспекта и улицы Королева, второй в БЦ "Лайнер" на Вербной улице. Мы хотим с вашей помощью создать сеть с геометрией, которая позволит позиционировать LoRa в районе Удельного парка.
Мы со своей стороны обещаем писать о системе здесь. Надеюсь, у нас хватит ресурсов месяца на три, чего должно быть достаточно для создания системы позиционирования LoRa.
Включайтесь вместе с нами в майнинг радио-эфира для интернета вещей!
Основным разработчиком сего чуда является deef137, прошу любить и жаловать.
Комментарии (20)
itsar Автор
17.06.2019 18:261. Самодельная антенна, широкополосная, объемный вибратор.
2. Это у Вас есть, как я понял. Хорошо!
3. Не понял, поясните.
4. Спасибо! Посмотрели, будем знать.
Черт, не туда отправил, сорри.
webhamster
17.06.2019 20:22+1Наверно, стоит пояснить, что имеется в виду под майнингом радио-эфира. Что получает майнер? Я так понимаю, как минимум, бесплатное обслуживание потока его гейтвея, а следовательно и всех устройств, которыми владеет майнер и которые подключены через этот самый гейтвей? А LoRa сервис в свою очередь получает от гейтвея данные всех устройств, которые видит гейтвей (там могут быть не только устройства майнера, но и все устройства поблизости), я правильно понял?
itsar Автор
17.06.2019 20:26Сейчас рано об этом говорить, нам самим пока не очень ясны детали, но майнер обычно получает ДЕНЬГИ :)
alexandershelupinin
17.06.2019 22:391)Cloud RAN — идея переноса бэйсбанда в облако. У Вас в статье переносится в облако НЕ бэйбанд, а обработка user plane Лоры. User plane НЕ равно бэйсбанд. В классическом радио-понимани бэйсбанд — это обработка физического уровня радиосигнала на уровне модуляции и коррекции ошибок и обработка control plane. «сообщения в агрегаторе IoT-сообщений LoRa» — НЕ относится к бэйсбанду.
2) Baseband hotel НЕ равно облако. Baseband hotel — это в простейшем случае собранный на одной площадке недалеко от радиомодулей НЕ клаудный бэйсбанд. Пример — стадион, где куча радимодулей а весь бэйсбанд собран в одной аппаратной под центральной трибуной.
3)Cloud RAN — фейковая НЕ взлетающая технология которая в случае своего полноценного применения требует каналов с экстра-минимальной задержкой между радиомодулем и бэйсбандом, например для LTE при выносе бэйсбанда в облако rtt задержки должны быть гарантированно лучше чем 0.2 мс. Таких задержек на реальных сетях нет. В облако можно выносить только non-real time baseband, который например для технолгии LTE занимает не более 20% всего бэйсбанда, оставшиеся 80% выносить в облако нельзя до тех пор пока гарантированные rtt задержки между радио и бэйсбандом не будут лучше 0.2 мс (для LTE)
4)сейчас у некоторых производителей мобильной связи есть опции выноса небольшого процента non-real time baseband в облако, но это НЕ дает никаких существенных преимуществ т.к. выносится только малая non real-time часть.itsar Автор
17.06.2019 22:42Большое спасибо за комментарий от профессионала!
1) Мы выносим именно baseband.
2) Очень интересно!
3) У нас как раз передача полностью отвязана от приема, передачи сейчас нет вообще. IoT такое допускает, даже приветствует.
4) Очень интересно!
Еще раз спасибо!alexandershelupinin
17.06.2019 23:101) У Вас на картинке RTL-SDR есть часть радиопередающего блока непосредственно связанная с антенной. RTL-SDR это и есть бэйсбанд от радиопередатчика и он никуда не выносится. Выносится как я понял обработка LoRы, это по-сути User Plane, т.е. пользовательские данные, а не радиомодуляция на физическом уровне. Вот если бы Вы перенесли RTL-SDR на облачный сервер — вот это был бы настоящий Cloud RAN. Но он работает только на картинках, в реальной жизни на реальных каналах связи нет таких маленьких задержек. (ну это как если бы Вы PCI шину на материнке попытались бы через Интернет прокинуть на видеокарту расположенную в другом конце города)
3)прием и демодуляция физического уровня радиосигнала, судя по картинке, находятся там где указано RTL-SDR, и он никуда не выносится.
Ну тоесть то что у Вас на картинке — это что угодно только НЕ Cloud RAN.
olartamonov
17.06.2019 23:14RTL-SDR лору демодулировать не может, ему нечем. Он тупо цифрует эфир и шлёт его на сервер.
Проект с коммерческой точки зрения всё равно нежизнеспособный совершенно, но по другим причинам. Как упражнение в обработке радиосигнала — ок.alexandershelupinin
17.06.2019 23:23>RTL-SDR лору демодулировать не может, ему нечем. Он тупо цифрует эфир и шлёт его на сервер.
Правильно, я потому и говорю что нарисованная на картинке система — что угодно только не Cloud RAN. Вот если бы RTL-SDR вынесли на удаленный сервер — вот тогда это был бы Cloud RAN.olartamonov
18.06.2019 07:15В C-RAN на сервер будет отправляться что, аналоговый сигнал с антенны по коаксиалу?
alexandershelupinin
18.06.2019 12:21модуляция-демодуляция и аналого-цифровое и цифро-аналоговое преобразование — на площадке присутствия радиопередатчика.
Контроль ошибок, логика выделения радиоресурсов, выделение кодовой схемы MCS и режимов MIMO — все это в теории должно переносится в облако.
Но это только в теории. На практике построить такой канал связи по которому будет бегать real-time baseband просто тупо дороже чем иметь бэйсбанд на площадке где расположен радиопередатчик.
Вот картинка с опциами переноса в облако бэйсбанда. ibb.co/nPdjxZh
Самая теоретически-правильная — крайняя левая, она же самая экономически не эффективная.
Картинка — для 5G. Но даже для LTE для переноса бэйсбанда в облако нужно иметь скорость линка 30-40 Gbps и гарантированные задержки RTT лучше чем 0.2 мс.
Поэтому выносить в облако реально можно только non-real time baseband который для LTE(например) занимает не более 20% от всего бэйсбанда, и смысла в этом особого нет т.к. экономии нет, один геморой.
Вообще «клауд» на радиоподсистему мобильной связи плохо перекладывается.
Например супер-современные клаудные контроллеры(BSC,RNC) для мобильных сетей 2G/3G заметно заметно хуже(не лучше, а хуже) железных контроллеров 10-летней давности по занимаемой площади на площадке оператора и по энергопотреблению на единицу траффика(по Ваттам мощности на Эрланг траффика в два раза хуже).
Ответ на вопрос «почему так» на самом деле простой — специализированная железка по энергоэффективности всегда лучше железки общего пользования на которую переложили какую-то одну частную нишевую задачу.
(зы Я занимался этой темой и попытками понять экономическую эффективность выноса радио-бэйсбанда в облако, результать — кейс экономически не эффективен.)olartamonov
18.06.2019 13:33+1модуляция-демодуляция и аналого-цифровое и цифро-аналоговое преобразование — на площадке присутствия радиопередатчика.
Контроль ошибок, логика выделения радиоресурсов, выделение кодовой схемы MCS и режимов MIMO — все это в теории должно переносится в облако.
Здесь так и сделано. RTL-SDR — это просто аналого-цифровой фронтенд, мозгов у него нет ни на что.
Но это только в теории. На практике построить такой канал связи по которому будет бегать real-time baseband просто тупо дороже чем иметь бэйсбанд на площадке где расположен радиопередатчик.
Ну и здесь то же самое, несколько мегабит потока ради лоры — это очень много.
dmitryrf
18.06.2019 12:11А можно пару слов об этих причинах?
По-моему, это похоже на подход FlightRadar, когда энтузиасты ставят у себя дополнительные приемники и получают привилегированный доступ к сервису.
webhamster
18.06.2019 12:37> то все идет нормально и можно конфигурировать The Things Network (TTN). Это подробно описано здесь.
А здесь перевод этой статьи на русский язык:
Использование платы радиомодема LoRa и RaspberryPi для создания шлюза стандарта LoRaWAN
webhamster
18.06.2019 13:31+1> У нас уже есть два измерителя: один на перекрестке Коломяжского проспекта и улицы Королева, второй в БЦ «Лайнер» на Вербной улице. Мы хотим с вашей помощью создать сеть с геометрией, которая позволит позиционировать LoRa в районе Удельного парка.
А почему только в районе Удельного парка? Измерители стоят на расстоянии 1,6 км. Слева жилой район с высотной застройкой, посередине еще какой-то старый микрорайон, куча пространства до Скобелевского проспекта:
Там позиционирование работать будет? И с углами в левой части карты от линии между измерителями проблем не будет? Почему-то для теста выбрано место четко справа от линии между измерителями.itsar Автор
18.06.2019 13:41В парке можно найти более-менее открытые во все стороны места. Сейчас пока нет откликов из района, так что круг расширяется. Пишите в личку.
С позиционированием все будет зависеть от геометрии. Ваше предложение хорошее.
webhamster
18.06.2019 14:52В общем, вам сейчас нужны энтузиасты, которые в радиусе ~2Км от ваших станций живут или работают. Через коротковолновиков не пытались искать? Эта тема с ними вроде как перекликается.
x893
1. Что за антенна подключена у Вас в SDR?
2. Есть и ноды и шлюз в TTN, но под Москвой.
3. SDR есть и RPi
4. KPN вместе с сообщением от ноды присылает location сообщение. Но страна NL.
itsar Автор
1. Самодельная антенна, широкополосная, объемный вибратор.
2. Это у Вас есть, как я понял. Хорошо!
3. Не понял, поясните.
4. Спасибо! Посмотрели, будем знать.