Comments 20
1. Что за антенна подключена у Вас в SDR?
2. Есть и ноды и шлюз в TTN, но под Москвой.
3. SDR есть и RPi
4. KPN вместе с сообщением от ноды присылает location сообщение. Но страна NL.
2. Есть и ноды и шлюз в TTN, но под Москвой.
3. SDR есть и RPi
4. KPN вместе с сообщением от ноды присылает location сообщение. Но страна NL.
1. Самодельная антенна, широкополосная, объемный вибратор.
2. Это у Вас есть, как я понял. Хорошо!
3. Не понял, поясните.
4. Спасибо! Посмотрели, будем знать.
Черт, не туда отправил, сорри.
2. Это у Вас есть, как я понял. Хорошо!
3. Не понял, поясните.
4. Спасибо! Посмотрели, будем знать.
Черт, не туда отправил, сорри.
Наверно, стоит пояснить, что имеется в виду под майнингом радио-эфира. Что получает майнер? Я так понимаю, как минимум, бесплатное обслуживание потока его гейтвея, а следовательно и всех устройств, которыми владеет майнер и которые подключены через этот самый гейтвей? А LoRa сервис в свою очередь получает от гейтвея данные всех устройств, которые видит гейтвей (там могут быть не только устройства майнера, но и все устройства поблизости), я правильно понял?
1)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 часть.
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 часть.
Большое спасибо за комментарий от профессионала!
1) Мы выносим именно baseband.
2) Очень интересно!
3) У нас как раз передача полностью отвязана от приема, передачи сейчас нет вообще. IoT такое допускает, даже приветствует.
4) Очень интересно!
Еще раз спасибо!
1) Мы выносим именно baseband.
2) Очень интересно!
3) У нас как раз передача полностью отвязана от приема, передачи сейчас нет вообще. IoT такое допускает, даже приветствует.
4) Очень интересно!
Еще раз спасибо!
1) У Вас на картинке RTL-SDR есть часть радиопередающего блока непосредственно связанная с антенной. RTL-SDR это и есть бэйсбанд от радиопередатчика и он никуда не выносится. Выносится как я понял обработка LoRы, это по-сути User Plane, т.е. пользовательские данные, а не радиомодуляция на физическом уровне. Вот если бы Вы перенесли RTL-SDR на облачный сервер — вот это был бы настоящий Cloud RAN. Но он работает только на картинках, в реальной жизни на реальных каналах связи нет таких маленьких задержек. (ну это как если бы Вы PCI шину на материнке попытались бы через Интернет прокинуть на видеокарту расположенную в другом конце города)
3)прием и демодуляция физического уровня радиосигнала, судя по картинке, находятся там где указано RTL-SDR, и он никуда не выносится.
Ну тоесть то что у Вас на картинке — это что угодно только НЕ Cloud RAN.
3)прием и демодуляция физического уровня радиосигнала, судя по картинке, находятся там где указано RTL-SDR, и он никуда не выносится.
Ну тоесть то что у Вас на картинке — это что угодно только НЕ Cloud RAN.
RTL-SDR лору демодулировать не может, ему нечем. Он тупо цифрует эфир и шлёт его на сервер.
Проект с коммерческой точки зрения всё равно нежизнеспособный совершенно, но по другим причинам. Как упражнение в обработке радиосигнала — ок.
Проект с коммерческой точки зрения всё равно нежизнеспособный совершенно, но по другим причинам. Как упражнение в обработке радиосигнала — ок.
>RTL-SDR лору демодулировать не может, ему нечем. Он тупо цифрует эфир и шлёт его на сервер.
Правильно, я потому и говорю что нарисованная на картинке система — что угодно только не Cloud RAN. Вот если бы RTL-SDR вынесли на удаленный сервер — вот тогда это был бы Cloud RAN.
Правильно, я потому и говорю что нарисованная на картинке система — что угодно только не Cloud RAN. Вот если бы RTL-SDR вынесли на удаленный сервер — вот тогда это был бы Cloud RAN.
В C-RAN на сервер будет отправляться что, аналоговый сигнал с антенны по коаксиалу?
модуляция-демодуляция и аналого-цифровое и цифро-аналоговое преобразование — на площадке присутствия радиопередатчика.
Контроль ошибок, логика выделения радиоресурсов, выделение кодовой схемы 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-летней давности по занимаемой площади на площадке оператора и по энергопотреблению на единицу траффика(по Ваттам мощности на Эрланг траффика в два раза хуже).
Ответ на вопрос «почему так» на самом деле простой — специализированная железка по энергоэффективности всегда лучше железки общего пользования на которую переложили какую-то одну частную нишевую задачу.
(зы Я занимался этой темой и попытками понять экономическую эффективность выноса радио-бэйсбанда в облако, результать — кейс экономически не эффективен.)
Контроль ошибок, логика выделения радиоресурсов, выделение кодовой схемы 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-летней давности по занимаемой площади на площадке оператора и по энергопотреблению на единицу траффика(по Ваттам мощности на Эрланг траффика в два раза хуже).
Ответ на вопрос «почему так» на самом деле простой — специализированная железка по энергоэффективности всегда лучше железки общего пользования на которую переложили какую-то одну частную нишевую задачу.
(зы Я занимался этой темой и попытками понять экономическую эффективность выноса радио-бэйсбанда в облако, результать — кейс экономически не эффективен.)
модуляция-демодуляция и аналого-цифровое и цифро-аналоговое преобразование — на площадке присутствия радиопередатчика.
Контроль ошибок, логика выделения радиоресурсов, выделение кодовой схемы MCS и режимов MIMO — все это в теории должно переносится в облако.
Здесь так и сделано. RTL-SDR — это просто аналого-цифровой фронтенд, мозгов у него нет ни на что.
Но это только в теории. На практике построить такой канал связи по которому будет бегать real-time baseband просто тупо дороже чем иметь бэйсбанд на площадке где расположен радиопередатчик.
Ну и здесь то же самое, несколько мегабит потока ради лоры — это очень много.
А можно пару слов об этих причинах?
По-моему, это похоже на подход FlightRadar, когда энтузиасты ставят у себя дополнительные приемники и получают привилегированный доступ к сервису.
По-моему, это похоже на подход FlightRadar, когда энтузиасты ставят у себя дополнительные приемники и получают привилегированный доступ к сервису.
> то все идет нормально и можно конфигурировать The Things Network (TTN). Это подробно описано здесь.
А здесь перевод этой статьи на русский язык:
Использование платы радиомодема LoRa и RaspberryPi для создания шлюза стандарта LoRaWAN
А здесь перевод этой статьи на русский язык:
Использование платы радиомодема LoRa и RaspberryPi для создания шлюза стандарта LoRaWAN
> У нас уже есть два измерителя: один на перекрестке Коломяжского проспекта и улицы Королева, второй в БЦ «Лайнер» на Вербной улице. Мы хотим с вашей помощью создать сеть с геометрией, которая позволит позиционировать LoRa в районе Удельного парка.
А почему только в районе Удельного парка? Измерители стоят на расстоянии 1,6 км. Слева жилой район с высотной застройкой, посередине еще какой-то старый микрорайон, куча пространства до Скобелевского проспекта:
Там позиционирование работать будет? И с углами в левой части карты от линии между измерителями проблем не будет? Почему-то для теста выбрано место четко справа от линии между измерителями.
А почему только в районе Удельного парка? Измерители стоят на расстоянии 1,6 км. Слева жилой район с высотной застройкой, посередине еще какой-то старый микрорайон, куча пространства до Скобелевского проспекта:
Там позиционирование работать будет? И с углами в левой части карты от линии между измерителями проблем не будет? Почему-то для теста выбрано место четко справа от линии между измерителями.
В общем, вам сейчас нужны энтузиасты, которые в радиусе ~2Км от ваших станций живут или работают. Через коротковолновиков не пытались искать? Эта тема с ними вроде как перекликается.
Sign up to leave a comment.
Интернет вещей по-русски. Baseband-отель LoRaWAN для владельцев RTL-SDR