Привет. Мы в команде [censored] (да, именно так нас зовут) уже некоторое время создаем стек для построения беспроводных ячеистых сетей с адаптивной маршрутизацией.
И только представьте, это работает! 
И так уж получилось, что пришло время сорвать завесу тайны (та-дам) и рассказать, что мы делаем, почему и какие возможности открывает наш стек-протокол для разработки проектов в сфере Интернета вещей.
и промышленный Интернет. Такого рода рассказ было бы разумно начать с объяснения того, что послужило толчком к началу нашей работы.
Кратко эту причину можно сформулировать так: мы пришли к выводу, что современные мобильные сети имеют ряд недостатков (несовместимых с жизнью в будущем), преодолеть которые невозможно без внедрения технологий с принципиально иной архитектурой, вариант которой мы придумали и решили реализовать.
Кто виноват
На заре появления мобильных сетей некоторые их архитектурные особенности еще не превратились в недостатки: концепция разделения зоны покрытия на отдельные зоны выглядела элегантно и логично, в полном соответствии со стратегией «разделяй и властвуй».Но с момента своего появления рынок мобильных устройств постоянно расширялся, требования к качеству предоставляемых услуг ужесточились, а скорость передачи данных и количество абонентов увеличились в сотни раз.
Этот рост выявил проблемы масштабируемости и гибкости в ставшей классической архитектуре мобильной сети.
Перефразируя классику, 640 КБ было мало.
1. Мобильные сети плохо масштабируются в зависимости от количества ячеек.
Каждая новая сота требует моделирования распространения радиоволн в интересующей зоне, расчета уровня шума, определения подходящих настроек для минимизации взаимных помех (как для новой станции, так и для соседних, если таковые имеются), дорогостоящего оборудования, разрешений от регуляторные услуги, обеспечение резервных линий связи и электроснабжения, работа специалистов по монтажу, настройке и поддержке.
- в общем, время и деньги.
И чем активнее в этой сфере используется радиосвязь, тем выше затраты.
В первую очередь это касается сетей LPWAN. 2. Мобильные сети плохо масштабируются по количеству абонентов.
Каждое устройство, поддерживаемое базовой станцией, резервирует либо частоту (FDMA), временной интервал (TDMA) или кодовую последовательность (CDMA).
Все эти ресурсы ограничены, и когда абонентов слишком много, качество связи начинает страдать: для того, кому не хватает частоты, слота или кода, базовая станция словно перестает существовать, что во многих случаях приводит к абонент «выпадает» из сети.
В то же время рост рынка Интернета вещей приводит к лавинообразному росту количества устройств, требующих доступа к сети.
Количество гаджетов растет в геометрической прогрессии, а разработчики не утруждают себя работой над способами связи, опираясь на уже существующие решения: большинство умных гаджетов либо «живут» в сети домашнего роутера, либо подключаются к Интернету через сети мобильных операторов.
И часто мы видим комичную ситуацию: устройства, находящиеся в одном помещении, общаются друг с другом через облачные сервисы.
И даже если таких устройств сейчас относительно немного, очень скоро пропускной способности как каналов связи, так и станций обработки просто не хватит. Прощай, прекрасная жизнь! 3. Современные сети совершенно не гибки.
Даже в повседневном режиме при изменении основных условий приходится пересчитывать и перенастраивать базовые станции, а в случае возникновения аварийных ситуаций и аварийных ситуаций «падение» одной из станций приводит к резкому наплыву устройств на соседние.
, что чаще всего приводит к обрушению всей сети, что чревато проблемами в случае стихийных бедствий или других чрезвычайных ситуаций.
Просто вспомните любой Новый год, когда ни с кем невозможно дозвониться по телефону, а все абоненты временно не обслуживаются.
И если наплыв под Новый год заканчивается довольно быстро и особых причин для беспокойства нет, то при проведении спасательных работ наличие хоть какой-то связи является жизненно важным фактором.
И уж не говоря о том, что поиск сети еще быстрее разряжает батарею любимого смартфона.
Что делать
Корень всех бед – повсеместное использование топологии «звезда» с достаточно жесткой централизацией.Именно поэтому мы решили разработать инфраструктуру для быстрого развертывания децентрализованной сети, получившую название Ad-Hoc или MESH. Идея состоит в том, чтобы исключить из сети «слабое» звено — базовую станцию, функции связи которой передаются абонентским устройствам.
В результате каждый из них, помимо роли потребителя услуг связи, играет еще и роль поставщика для своих соседей.
Сами устройства в таких сетях традиционно называются узлами.
В таких сетях при появлении новых узлов или выходе из строя существующих сеть автоматически перестраивает маршруты, сохраняя функциональность, что упрощает масштабирование и делает всю систему необычайно гибкой.
Необходимость администрирования и настройки таких сетей сведена к минимуму и может выполняться удаленно.
Именно поэтому обслуживание беспроводных MESH-сетей не требует дорогостоящей инфраструктуры, прокладки кабелей, установки базовых станций и их регулярного администрирования, что делает эксплуатацию этих сетей очень экономичной.
Очевидно, что главной особенностью децентрализованного узла беспроводной сети являются алгоритмы управления процессом маршрутизации, которые должны быть более сложными, чем в обычных маршрутизаторах.
Но поскольку большинство абонентских устройств не обладают большими вычислительными ресурсами, используемые алгоритмы маршрутизации должны быть не только высокоинтеллектуальными, но и не ресурсоемкими.
Мы восприняли этот круг задач как своеобразный вызов.
Что сделано
Около года назад, выдвинув несколько гипотез о том, какие решения необходимо реализовать для построения централизованной беспроводной сети, мы протестировали их на специально созданной имитационной модели.Поскольку до нас люди пытались строить MESH-сети разных типов, важно было преодолеть ограничение, с которым их разработчики сталкивались раньше: сложно объединить более ста, а иногда и дюжины абонентов в один Ad-Hoc. сеть.
Однако результаты моделирования оказались обнадеживающими, и мы приступили к реализации.
Нашим первым партнером стала местная компания, занимающаяся системной интеграцией и решениями в области автоматизации управления.
Нас пригласили поучаствовать в проекте по разработке умной системы уличного освещения, в которой наш стек протоколов занял бы достойное место — обеспечение передачи данных.
Партнерам оставалось лишь спроектировать «железо» и создать приложения для управления освещением, которые стали бы «клиентами» нашего стека.
В результате обсуждения аппаратных требований было принято решение работать с микроконтроллерами NXP LPC1343 и радиопередатчиками Semtech SX1272 (RFM96), поддерживающими стандарт LoRa. На тот момент ресурсов выбранного микроконтроллера казалось достаточно, и впереди нас ждало множество строк кода на чистом C. В минимальной реализации стек представлен тремя уровнями, между которыми происходит постоянный обмен данными: уровень интерфейса, уровень маршрутизации и уровень обслуживания.
Нам не хотелось тратить время и силы на создание собственных примитивов параллельной обработки, поэтому мы решили реализовать стек для FreeRTOS (не без проблем, но с неожиданными успехами).
Кроме того, данное решение обеспечило некоторый кроссплатформенный функционал, который будет полезен при дальнейшем развитии проекта.
Чтобы полностью протестировать стек, мы решили создать отдельную открытую платформу для разработки.
За основу мы выбрали Raspberry Pi, и сделали для него коробку, упрощающую установку необходимой периферии: ЖК-дисплея, GPS-модуля, «шапочной» платы для радиомодулей и т. д. О как это было сделано в конце статьи.
Несмотря на экономное использование ресурсов микроконтроллера, вскоре выяснилось, что стек FLASH объемом 32 КБ не подходит, поэтому требования к оборудованию были увеличены.
Сегодня минимальная версия стека требует следующих характеристик платформы: Микроконтроллер: Кортекс М3 ОС: FreeRTOS ФЛЕШ: 128 КБ ЭСППЗУ: 8 КБ ОЗУ: 32 КБ Кроме того, для генерации псевдослучайных чисел стек использует встроенный в микроконтроллер АЦП, но при необходимости его можно заменить любым подходящим PNG-генератором с сохранением необходимой криптостойкости.
На самом деле этот стек называется MOAR.
Чего ожидать дальше
Следующая цель, которую мы перед собой поставили, — разработать версию стека MOAR для GNU/Linux с поддержкой — насколько это возможно — стандартов POSIX. Полагаем, нет необходимости подробно объяснять причины такого решения в мире, где подавляющее большинство сетевых устройств работают если не под GNU/Linux, то с операционной системой, поддерживающей POSIX. Кроме того, мы планируем публиковать исходный код стека под свободной лицензией.Версия для GNU/Linux, в отличие от первой, включает уже пять различных уровней: к ранее существовавшим добавлены уровень канала и уровень представления.
Вместо очередей, использовавшихся в первой версии, для обмена данными между уровнями теперь используются стандартные сокеты Unix. Каждый из уровней можно перезапускать отдельно от других, что гораздо полезнее.
В стеке есть API, который мы пытаемся приблизить к обычному API сокетов.
Нам кажется, что такой подход существенно облегчит «переезд» разработчикам, которые будут использовать стек как готовое решение.
Кроме того, возможна тонкая настройка стека через конфигурационные файлы с их применением «на лету» и передачей по самой сети — простейшая реализация этого функционала уже есть в первой версии стека, для GNU/Linux. он будет развиваться и расширяться.
Такая гибкость и модульность разработанного стека была выбрана не только из эстетических соображений и простоты разработки.
В планы на будущее входит реализация множества интересных возможностей, таких как адаптивная маршрутизация, которая использует самообучающуюся нейронную сеть для прогнозирования состояний ближайших соседей и приоритетов маршрутов.
Благодаря архитектурным особенностям нашего решения вы можете менять сценарии обработки данных без необходимости перезагрузки всего стека или переобучения нейросети.
Другие запланированные функции связаны с информационной безопасностью, и о них мы подробно поговорим позже.
23 декабря мы опубликуем исходный код стека MOAR под свободной лицензией и будем рады вашим вопросам, идеям, комментариям и даже форкам! Для тех кому интересно фото Помимо релиза Open Source DevKit, мы планируем разместить полную информацию по сборке узла.
К связь Вы можете найти краткую инструкцию по сборке и список необходимых деталей.
Если вы не знаете, чем занять себя в новогодние праздники и устали отвечать на вопрос, что подарить на Новый год, вы можете убить пару зайцев одним выстрелом.
УПД.
Выпускать Теги: #iot #открытый исходный код #открытый исходный код #Разработка Интернета вещей
-
Некоторая Информация О Ремонте Компьютеров
19 Oct, 24 -
120 Дней Бесплатно
19 Oct, 24 -
Embarcadero Technologies Продана Idera
19 Oct, 24 -
Microsoft Обновляет Клиент Zune
19 Oct, 24
