Здравствуйте. Мы в команде [censored] (да, так и называемся) уже некоторое время творим стек для построения беспроводных mesh-сетей с адаптивной маршрутизацией. И, представьте себе, получается!
И так уж вышло, что настало время сорвать покров тайны (та-дам) и рассказать, что мы делаем, почему и какие возможности для разработки проектов в сфере того самого Интернета вещей и промышленного интернета открывает наш стек-протокол.
Подобного рода рассказ было бы разумно начать с объяснения тому, что же стало толчком к началу нашей работы. Кратко эту причину можно сформулировать так: мы пришли к выводу, что современные мобильные сети имеют ряд недостатков (несовместимых с жизнью в будущем), преодоление которых невозможно без внедрения технологии с принципиально иной архитектурой, вариант которой мы придумали и решили воплотить в жизнь.
Кто виноват
На заре появления мобильных сетей некоторые их архитектурные особенности ещё не успели обернуться недостатками: концепция разбиения зоны покрытия на отдельные области выглядела элегантно и логично, в полном соответствии со стратегией «разделяй и властвуй». Но с момента своего возникновения рынок мобильных устройств непрерывно расширялся, ужесточались требования к качеству предоставляемых услуг, в сотни раз возросли скорости передачи данных и количество абонентов. Этот рост позволил выявить проблемы масштабируемости и гибкости ставшей уже классической архитектуры мобильных сетей. Перефразируя классику, 640 Кб не хватило.
1. Мобильные сети плохо масштабируются по числу сот. Каждая новая сота – это моделирование распространения радиоволн в интересующем районе, расчёт уровня шума, определение подходящих настроек для минимизации взаимных помех (как для новой станции, так и для окружающих, если они есть), дорогое оборудование, разрешения от надзорных служб, обеспечение резервных линий связи и питания, работа специалистов по монтажу, настройке и сопровождению … – в общем, время и деньги. И чем активнее используется в этом районе радиосвязь – тем больше затраты. В первую очередь это касается LPWAN сетей
2. Мобильные сети плохо масштабируются по числу абонентов. Каждый поддерживаемый базовой станцией аппарат резервирует либо частоту (FDMA), либо временной слот (TDMA), либо кодовую последовательность (CDMA). Все эти ресурсы ограничены, и когда абонентов становится слишком много, начинает страдать качество связи: для того, кому не хватило частоты, слота или кода, базовая станция словно перестаёт существовать, что во многих случаях оборачивается «выпадением» абонента из сети.
В то же время рост рынка Интернета вещей приводит к лавинообразному росту числа устройств, требующих доступ в сеть. Число гаджетов растет по экспоненте, а разработчики не утруждают себя работой над способами связи, полагаясь на уже существующие решения: большая часть умных гаджетов либо «живёт» в сети домашнего роутера, либо подключается к Интернет через сети мобильных операторов. И часто мы видим комичную ситуацию: устройства, находящиеся в одной комнате, общаются между собой через облачные сервисы. И даже если сейчас таких устройств сравнительно немного, то совсем скоро пропускной способности как каналов связи, так и станций обработки просто не хватит. Гудбай, красивая жизнь!
3. Современные сети совершенно не гибкие. Даже в повседневном режиме при изменении базовых условий необходимо провести перерасчет и перенастройку базовых станций, а в случае экстренных и чрезвычайных ситуаций «падение» одной из станций ведет к резкому наплыву устройств на соседние, что чаще всего приводит к падению всей сети, что чревато проблемами в случае стихийных бедствий или других чрезвычайных ситуаций.
Просто вспомните любой Новый Год, когда ни до кого невозможно дозвониться, а все абоненты временно не обслуживаются. И если наплыв во время Нового Года довольно быстро заканчивается и особых поводов переживать нет, то во время спасательных мероприятий наличие хоть какой-нибудь связи является жизненно важным фактором. А уж про то, что от поиска сети батарейка вашего любимого смартфона разряжается еще быстрее, можно и не говорить.
Что делать
Корнем всех бед является обычное для всех применение топологии «звезды» с довольно жесткой централизацией. Поэтому мы и решили заняться разработкой инфраструктуры для быстрого развертывания децентрализованной сети, которые называются Ad-Hoc или MESH. Идея состоит в исключении из сети «слабого» звена – базовой станции – для чего функции обеспечения связности перекладываются на абонентские устройства. В итоге каждое из них, помимо роли потребителя услуг связи также выполняет роль их поставщика для своих соседей. Сами устройства в таких сетях традиционно именуются нодами. В таких сетях при появлении новых нод или выхода из строя существующих сеть автоматически перестраивает маршруты, сохраняя работоспособность, что упрощает масштабирование и делает всю систему непривычно гибкой. Необходимость администрирования и настройки таких сетей сводится к минимуму и может выполняться удаленно. Именно поэтому поддержание беспроводных MESH-сетей не требует дорогостоящей инфраструктуры, прокладки кабелей, монтажа базовых станций и их регулярного администрирования, что делает эти сети весьма экономичными в эксплуатации.
Очевидно, что главной особенностью узла децентрализованной беспроводной сети являются алгоритмы, управляющие процессом маршрутизации, которые должны быть сложнее таковых в привычных маршрутизаторах. Но поскольку большинство абонентских устройств не обладают большими вычислительными ресурсами, применяемые алгоритмы маршрутизации должны быть не только высокоинтеллектуальными, но и не ресурсоёмкими. Этот спектр задач был принят нами как своего рода вызов.
Что сделано
Примерно год назад, выдвинув несколько гипотез о том, какие решения необходимо реализовать для построения централизованной беспроводной сети, мы проверили их на специально созданной имитационной модели. Поскольку разного вида MESH-сети пытались строить и до нас, важно было преодолеть ограничение, с которым их разработчики сталкивались раньше: затруднительно объединить в одной Ad-Hoc сети более сотни, а порой даже десятка абонентов. Однако результаты моделирования были обнадёживающими, и мы принялись за реализацию.
Первым нашим партнёром стала местная компания, занимающаяся системной интеграцией и решениями в области автоматизации управления. Нас пригласили участвовать в проекте по разработке системы умного уличного освещения, в которой наш стек протоколов занял бы подобающее место – обеспечение передачи данных. Партнерам же оставалось спроектировать аппаратную часть и создать приложения для управления фонарями, которые стали бы «клиентами» нашего стека. В результате обсуждения аппаратных требований было решено работать с микроконтроллерами NXP LPC1343 и радиопередатчиками Semtech SX1272 (RFM96), поддерживающими стандарт LoRa. На тот момент ресурсов выбранного микроконтроллера казалось достаточно, и впереди нас ждало очень много строк кода на чистом С.
В минимальной реализации стек представлен тремя уровнями, между которыми постоянно происходит обмен данными: интерфейсным уровнем, уровнем маршрутизации и сервисным уровнем. Уделять время и силы созданию собственных примитивов параллельной обработки нам не хотелось, поэтому было решено реализовывать стек под FreeRTOS (не без проблем, зато с неожиданными успехами). К тому же, это решение обеспечивало некоторую кроссплатформенность, что было бы полезно при дальнейшем развитии проекта.
Для полноценной проверки стека мы решили создать отдельную открытую платформу для разработки. В качестве основы мы выбрали Raspberry Pi, и сделали для неё бокс, облегчающий монтаж необходимой периферии: LCD-дисплея, GPS-модуля, платы-«шляпы» для радиомодулей и т.д… О том, как это было сделано, можно почитать в конце статьи.
Несмотря на экономное расходование ресурсов микроконтроллера, довольно скоро обнаружилось, что в 32 Кб FLASH стек не помещается, поэтому требования к аппаратной части были повышены. Сегодня минимальная версия стека требует следующих характеристик платформы:
MCU: Cortex M3
OS: FreeRTOS
FLASH: 128 Кб
EEPROM: 8 Кб
RAM: 32 Кб
Кроме того, для генерации псевдослучайных чисел стек использует встроенный в микроконтроллер АЦП, однако при необходимости его можно заменить любым подходящим генератором ПСЧ с соблюдением требуемой криптографической стойкости. Собственно говоря, этот стек и называется MOAR.
Чего ждать дальше
Следующая цель, которую мы перед собой поставили – это разработка GNU/Linux-версии стека MOAR, причём с поддержкой – насколько это будет возможно – стандартов POSIX. Полагаем, нет необходимости детально объяснять причины этого решения в мире, где абсолютное большинство сетевых устройств работает если не под управлением GNU/Linux, то с операционной системой, поддерживающей POSIX. Кроме того, в наших планах публикация исходных кодов стека под свободной лицензией.
Версия для GNU/Linux, в отличие от первой, включает в себя уже пять различных уровней: к имевшимся ранее добавились канальный уровень и уровень представления. Вместо очередей, использовавшихся в первой версии, для обмена данными между уровнями теперь используются стандартные сокеты Unix. Каждый из уровней может быть перезапущен отдельно от остальных, что уже гораздо полезнее.
Стек обладает API, который мы стараемся приблизить к привычному API сокетов. Как нам кажется, такой подход сильно облегчит «переезд» разработчикам, которые будут использовать стек как готовое решение. Кроме того, тонкая настройка стека возможна посредством конфигурационных файлов, с их применением «на лету» и передачей посредством самой сети – простейшая реализация этого функционала есть уже в первой версии стека, для GNU/Linux она будет развита и расширена.
Такая гибкость и модульность разрабатываемого стека была выбрана не только из эстетических соображений и удобства разработки. В дальнейшие планы входит реализация многих захватывающих дух возможностей как, например, адаптивный роутинг, использующий самообучающуюся нейросеть для предсказания состояний ближайших соседей и приоритетов маршрутов. Благодаря архитектурным особенностям нашего решения можно менять сценарии обработки данных без необходимости перезагружать стек целиком или заново обучать нейросеть. Другие запланированные возможности относятся к сфере информационной безопасности, и о них мы подробно расскажем позже.
23 декабря мы опубликуем исходные коды стека MOAR под свободной лицензией и с нетерпением будем ждать ваших вопросов, идей, замечаний и даже форков!
Автор: Apuzakov
