Создание и настройка Mesh-сети на собственном опыте, а также немного цифр и аналитики
Все началось с того, что на очередном обсуждении дальнейшей судьбы проекта, над которым я тогда работал, кто-то сказал: «А давайте прикрутим меш-сети, ведь это круто, модно и молодёжно!». И именно с этого момента началась моя неравная борьба с меш-сетями, из которой мы с товарищем вышли победителями. Хоть и с небольшой оговоркой.
Итак, что у нас имелось на текущий момент: несколько умных устройств (на базе nrf52840), уже умевших общаться с телефоном по «блютусу», странная среда разработки и я, абсолютно непонимающий, что такое меш-сети. То, как я неделю колдовал с бубном, чтобы arm-овский компилятор съел NRF mesh SDK – это отдельная история. Но после поражения в этой битве и переход на GCC дела пошли быстрее.
Давайте для начала разберемся в том, что такое меш-сеть. Это распределенная сеть, в которой каждый узел может отправлять и принимать сообщения. Узлы, по сути своей, делятся на два типа – проивижионер (создатель сети) и провижиони (рядовой узел сети). В чем их отличие: провижионер – это создатель сети, тот, кто выдает всем адреса, конфигурирует остальные узлы и вообще следит за тем, жива сеть или нет. Если по какой-то причине такой узел выпадает из сети, то сеть не умирает, но пропадает возможность удалять и добавлять узлы. В моем случае — это было равносильно смерти всей сети. Провижиони сам ничего не умеет, он способен только отправлять и принимать сообщения и то, при условии, что провижионер дал ему адрес. Выделяют два отдельных процесса: провижионинг (добавление в сеть и выделение адреса) и конфигурирование, при котором узлу сообщается кому он может слать свои сообщения. Сами сообщения бывают двух видов: юникаст и бродкаст. Каждый узел знает группу, к которой он принадлежит. Адрес этой группы задает проивижионер при конфигурировании. На основе этого адреса он фильтрует входящие сообщения, предназначенные только его группе.
На каждом узле (железке) меш-сети должна находиться модель. Модель – это сущность, которой провижионер присваивает уникальный адрес, и которая может, если она клиент, отправлять запросы, а если сервер – то отвечать на них. Для моей задачи требовалось сделать возможным, чтобы модель могла бы и принимать сообщения, и отправлять их сама. В принципе, никто не запрещает вам на одной железке создать несколько моделей с разными адресами, одна из которых будет отвечать за передачу сообщений, а другая – за прием. Единственное, о чем вам стоит помнить, что конфигурация узла происходит в полуручном режиме. То есть вы не можете написать в коде провижионера: if (state == Configure)
Кстати, я говорил, что на вашем узле может располагаться несколько сущностей, и по умолчанию, у вас уже будет находиться health-client/server, config-client/server. Health-client находится на провижионере и отвечает за опрос health-server на обычных узлах. Этот уровень абстракции позволяет провижионеру контролировать состояние сети, кто жив, а кто мертв. Между девайсами постоянно будут летать сообщения с подобными опросами. Config-client также находится на провижионере, и его задача – просто последовательно выполнить те команды конфигурации, которые вы ему задали изначально. Никакой гибкости здесь не предполагается – что написано один раз, будет выполняться для каждого узла независимо от внешних параметров системы. Аналогично, config-server находится на стандартных узлах, и его цель – отвечать на запросы клиентов.
Итак, когда основные моменты рассмотрены, давайте перейдем к архитектуре. Я в то время находился под сильным впечатлением от прочтения Code Complete, да и уровень сокомандников не позволял написать откровенный говнокод. Тогда я решил акцентировать внимание на подобии архитектуры, а не просто запихнуть весь код в один крутой мега-класс. Ну, или сделал вид.
Вот что из этого получилось:
- У нас есть класс BLEMesh, у которого есть методы Send и Receive, соответственно для приема и отправки сообщений по меш-сети. Также, есть метод SetGroup, с помощью которого можно выставить, к какой группе принадлежит узел. StartProvisioning, как нетрудно догадаться, делает узел провижионером и начинает создавать сеть, последовательно добавляя в нее всех соседей.
- Чтобы не засорять главный интерфейс реализацией, а уж тем более обращениями к SDK, был создан класс BLEMEshImpl. Инстанс этого класса является полем BLEMesh, который, в свою очередь, просто обращается к нему и вызывает соответствующие методы. Здесь реализованы методы по инициализации и запуску всего стека BLE и BLE Mesh, а также регистрируется куча колбеков на разные случаи жизни. Здесь же инициализируется третья сущность – модель.
- Модель в моем случае представляет из себя класс, отвечающий только за передачу и прием данных по меш-сети. При попытке отправить сообщение, модель проверяет, содержится ли в сообщении уникальный адрес или адрес группы и, в зависимости от этого, вызывает разные функции из SDK. Если уникальный адрес не выставлен – сообщение отправляется в группу, то есть всем.
Также, уже изначально была заложена возможность покрытия всего этого шедевра юнит-тестами, а каждый класс был унаследован от интерфейса с приставкой I. Это нужно было сделать, чтобы в последствии безболезненно замокать обращения к Mesh SDK.
В процессе разработки также выяснилось несколько интересных моментов. Класс, который у нас все время занимался записью данных во флэш, перестал работать. Почему? Да потому что BLE Mesh забирал себе все процессорное время, и бедный StorageManager бессильно возвращал коды ошибок. Предложенный же библиотекой MeshStorageManager представлял из себя обычную мапу (словарь) и не мог удовлетворить наших потребностей. Нам нужно было не просто сохранять данные куда-то в память. Нам важно было самим обозначить конкретный адрес. И поэтому, мы не нашли ничего лучше, чем просто отключать BLE Mesh на время записи во флэш.
Следующее, что стало для нас открытием – провижиони не может в ран-тайме становиться профижионером и требует перезагрузки всего узла. Возможно, все-таки существует какой-нибудь способ, но мы его не нашли.
Третий пункт плавно вытекает из нашей задачи: прикрутить BLE Mesh к уже работающему девайсу. А ведь уже был написан код, позволяющий общаться с устройством по блютус с телефона. Как же нам совместить два таких разных SDK? Хорошо, что в комплекте с SDK шел пример их сосуществования, позволивший немного упростить нашу задачу. Почему немного, а потому что она до сих пор не была нами решена. Поколдовав с настройками и приоритетами, мы пришли к следующему. Если устройство когда-то было спэйрино с телефоном, но на телефоне были удалены настройки, то повторный пейринг не проходит. Скорее всего это проблема конкретно нашей реализации, но пока это лечится только отключением пересылки событий SoftDevice в меш стек, как описано здесь. Костыли наше все. Во всех остальных случаях нет никаких проблем с пейрингом устройства и приложения, установлением подключения и работы с Mesh в роли профижионера или профижиони. Может быть в дальнейшем получится исправить эту проблему, и я добавлю заветный UPD.
Ну и настало время аналитики, которую мы делали для себя. Моим коллегой был собран следующий тестовый стенд: четыре узла, один из которых подключен проводом к ПК (через переходник USB-UART). Он будет являться провижионером в нашей сети, а также именно с него будут уходить все запросы в сеть. В том числе у нас есть планшет, с помощью которого мы будем измерять помехи в работе меш-сети, при использовании обычного блютуса. На ПК используется модифицированная программа modpoll, которая реализует тестовые сценарии и выводит в файл результаты измерений. В программе реализовано измерение круговой задержки (RTT) — интервала времени между отправкой запроса и получением ответа. Есть ограничение для круговой задержки — все что больше 1000 мс считается потерей.
Очевидно, что при совместном сосуществовании BLE и Mesh невозможно обойтись без потерь. В наше случае мы рассматривали простейший случай, когда провижионер опрашивает одного провижиони без пересылок. Для оценки выполнялось 100 запросов подряд.
В «case 1» ни одно устройство не подключено к приложению, в «case 2» провижиони подключен к приложению и имеет место некоторый трафик через BLE, а в «case 3» провижионер подключен к приложению. Первый график показывает распределение потерь, второй – распределение круговой задержки. Как мы видим из первого графика — работа провижионера на «два фронта» обходится в дополнительные 5% потерь. В случае с быстродействием получается, что, когда установлено соединение, снижается нагрузка на стек BLE (прекращается сканирование эфира), и обработка событий Mesh происходит быстрее.
Надеюсь, этот короткий обзор Mesh-сетей и анализа их производительности был вам полезен и интересен. Еще увидимся!
Источник
Настраиваем Mesh-сеть на Keenetic: теория и практика
Сегодня все производители домашнего сетевого оборудования активно продвигают технологию Mesh, обещая масштабировать вашу беспроводную сеть на любые площади. Ещё бы, ведь вместо одного устройства в руки под соусом «Mesh» можно продать 3-4 устройства каждому пользователю, чтобы тот устанавливал по Wi-Fi-споту в каждой комнате, включая ванную и туалет. Мы уже тестировали достаточно дорогие комплекты Multy X для MESH-сетей от компании Zyxel, и сегодня пришло время поговорить о рабоче-крестьянском методе реализации одноранговой сети на «Кинетиках».
Зачем вам Mesh?
Wi-Fi активно переходит на диапазон 5 ГГц, где эфир чище и скорости существенно выше просто в силу новых стандартов (802.11ac и уже ранних реализаций 802.11ax). Однако сигнал 5 ГГц хуже распространяется через преграды, поэтому сеть нуждается в большем числе точек доступа, тщательном планировании их взаимодействия и управления.
Там, где раньше были две точки доступа, теперь появляется и третья, и пойди ещё размести её так, чтобы она не мешала двум соседним. Да, конечно, 5-гигагерцовая радиоволна затухает раньше, чем 2,4-гигагерцовая, и сигнал от расположенных по соседству точек доступа меньше перекрывает друг друга, но на практике не всегда удаётся разместить хот-споты так, чтобы они не мешали друг другу, и это — целое искусство. Не менее важно в дальнейшем уметь переключать клиентов на наименее загруженные точки доступа, всегда поддерживая балансировку и не допуская перегрузки оборудования.
В чём плюс Mesh перед традиционными репитерами? Еще недавно домашний пользователь особо не заморачивался на единой Wi-Fi-сети, а увеличивал покрытие обычными беспроводными повторителями (репитерами), так как это дёшево и сердито, но с ними возникают и проблемы. Основная заключается в том, что для роутера все устройства, работающие через репитер, имеют один общий MAC-адрес, его беспроводной интерфейс независим и представляет собой совершенно изолированную Wi-Fi-сеть (да еще и в разных диапазонах). А это значит, что вы не сможете настраивать различные ограничения для смартфонов, отключать им доступ в интернет или выделять отдельные сегменты (например, для умных вещей), не можете гарантировать бесшовный роуминг и непрерывную передачу данных, не можете централизованно (и согласованно когда их несколько) репитером управлять.
Mesh — это уже «умная» сеть с динамической древовидной топологией. Либо полностью децентрализованная, либо (чаще) с назначаемым контроллером. Давайте рассмотрим ситуацию, в которой вы, для примера, расширяете mesh-точкой покрытие в беседке вашего коттеджа. Эта точка видит ближайшую к себе аналогичную точку в гостиной с высоким уровнем сигнала и главную (первичную) точку в чулане, за двумя стенами, к которой и подходит интернет-канал от провайдера, но уровень сигнала у нее — ниже, хотя и достаточный. Казалось бы, подключайся к ближайшему узлу, и делов-то? Но всё не так просто: хоть ближайший узел и даёт более высокую скорость соединения, он представляет собой ещё один преобразователь на пути в интернет, и в каких-то случаях выгоднее будет подключаться к первичной точке. Вот эту выгоду и должна рассчитывать mesh-сеть, меняя свою топологию в зависимости от условий радиоэфира и состояния своих членов.
В чём отличие дорогого Mesh от дешёвого?
Формально mesh-сетью принято называть конструкцию, в которой узлы между собой обмениваются данными по радиоканалу, именуемому backhaul. Ключевое отличие дорогих mesh-комплектов в том, что для бэкхоула они используют отдельный радиомодуль со своими антеннами (обычно в 5 ГГц), чтобы клиенты и интерконнект использовали разные радиоканалы и не мешали друг другу. Такие системы обычно называют трехдиапазонными: 2,4 ГГц пользовательский + 5 ГГц пользовательский + 5 ГГц бэкхоул (который служит только для связи узлов между собой).
Антенная группа точки доступа Zyxel Multy X (источник: Smallnetbuilder.com)
На фотографии выше как раз такой случай: точка доступа Zyxel Multy X имеет 5 антенн для Backhaul-канала на частоте 5 ГГц, и всего по 2 антенны для клиентских подключений в диапазонах 2.4 ГГц и 5 ГГц. Есть там и Bluetooth, что в общем-то, объясняет цену одного хот-спота, начисто лишённого технических изысков, в 11500 рублей.
Недорогие mesh-решения, как правило, являются двухдиапазонными. По сути это обычный 2,4+5 ГГц роутер со схемой 2х2 или 3х3, у которого один из радиоинтерфейсов параллельно с обслуживанием пользователей передает необходимые данные между узлами сети, то есть поддерживает связь с соседними точками. Скорость доступа в интернет в такой двухдиапазонной сети падает пропорционально удалению от главной точки, однако если нужна локальная передача данных между соседними узлами — такая система может справляться ничуть не хуже трехдиапазонной.Яркими примерами удачных двухдиапазонных сетей можно считать Google Wi-Fi, а также испытуемое в этой статье решение от Keenetic.
Конечно, можно пойти дальше и поговорить о том, что mesh-контроллер должен регулировать мощность точек доступа, чтобы снижать интерференции, отвечать за аутентификацию пользователя, перебрасывать соединение между точками доступа в зависимости от загруженности радиоканала, но в этом случае мы плавно перейдём к Enterprise-оборудованию с 6-значными ценами и потеряем пролетарский настрой «сделать всё дёшево двумя кликами мышки».
Что у Keenetic?
У Keenetic-ов уже был реализован «Wi-Fi контроллер», модуль интерфейса, который позволял строить беспроводную сеть из нескольких роутеров, соединяя их через Ethernet. Мы рассматривали это решение, когда тестировали работу бесшовного роуминга, и в принципе, реализация Mesh просилась сама собой, не хватало только того самого выделенного беспроводного Backhaul-канала по радио, ведь связывать разношёрстные роутеры в одну сеть, не взирая на цену и класс, они научились ещё в конце 2018 года.
Разработчики Keenetic давно полюбили технологию VLAN для нарезки одной беспроводной сети на сегменты. Так, например, вы могли совершенно безопасно сделать одну WLAN-сеть для всяких умных вещей, не имеющую доступа к вашему NAS’у с бэкапами, вторую WLAN-сеть — для гостей, не имеющую доступа никуда кроме как в интернет, и третью WLAN-сеть — для себя любимого, с полным доступом ко всему и 32-значным паролем. Ну так почему бы не сделать ещё одну служебную WLAN-сеть со скрытым SSID-ом в пока ещё свободном 5-ГГц диапазоне и не отдать её под Backhaul? Схематически на примере Keenetic Ultra нарезку радиоэфира 5 ГГц на сегменты WLAN можно представить так:
Для связи между роутерами используются все пространственные потоки, имеющиеся на устройстве, так что вы можете устанавливать 4-потоковую Keenetic Ultra (его радиомодуль имеет 4 передатчика и 4 приёмника) в центре сети как физически, так и логически, а на периферии — более дешёвые устройства. На какой-нибудь аллее или в длинном коридоре можно вообще не заморачиваться и тянуть сеть по воздуху на чём-то типа Keenetic City.
Забегая вперед, конкретно по оборудованию Keenetic, на практике и после разъяснений производителя, выяснилось, например, что не всем в mesh-сети управляет контроллер. Дальние ретрансляторы (которые контроллер банально может не слышать и, соответственно, ничего не знать о них) самостоятельно организуются в цепочки, чтобы затем уже предстать перед контроллером как достойные члены сети.
Разработчики Keenetic гордятся тем, что на любом уровне сети любые узлы могут быть соединены друг с другом Ethernet-кабелем, и тогда Backhaul-канал между ними не использует радио. Это наиболее полезная функция, потому что, во-первых, вы сможете постепенно прокладывать кабель там, где нет радиосвязи, а во-вторых, вы сможете проходить любые препятствия, как бы далеко от основного роутера они ни располагались бы. Ни 2-метровые дореволюционные своды казематов, ни настенные телевизоры не помешают. То есть, не нужно заранее думать, как там, через 100 метров, будут соединяться Wi-Fi-узлы вашей сети: где-то по кабелю, а где-то по воздуху, но связь будет. Идеальный вариант для тех, кто сначала делает, а потом думает. С другой стороны, если вдруг кабель случайно будет выдернут или разрушен, при достаточной дальности бэкхоула сеть переорганизуется на беспроводное соединение без вашей помощи.
Конечно, Mesh в «Кинетиках» — это подарок для пользователей-энтузиастов, функция, которой раньше не было, и вдруг она появилась, так что предъявлять повышенные требования к ним не стоит, но давайте сразу расставим все точки над i и приведём список того, чего пока нет в mesh-системе Keenetic:
- Автоматической регулировки мощности точек доступа
- Централизованной регулировки мощности точек доступа из единого интерфейса
- Подробной информации о радио сигнале каждой точки доступа из единого интерфейса
- Обнаружения поддельных точек доступа (Rogue AP)
- Хоть какой-то диаграммы или картинки, куда направлено излучение от антенн каждого из Keenetic-ов, ведь их разновидностей уже больше 10 штук, и все могут использоваться в Mesh-сети.
И вот теперь, как говорится, облегчив душу и высказав своё «фи» отсутствием профессиональных фишечек в домашних устройствах, можно приступить к настройке. Для наглядности возьмём совершенно разнородные устройства, начиная от 100-мегабитной Keenetic Extra и заканчивая Keenetic Ultra.
Перво-наперво настраиваем основной роутер, обновляя прошивку до версии 3.1. Мы пропускаем всё, что связано с доступом в интернет, и переходим к Wi-Fi: включаем контроллер беспроводной сети.
Теперь каждый из Keenetic-ов, которые мы хотим добавить в Mesh-систему, нужно так же обновить и переключить в режим «усилитель», а затем подключить проводом к основному роутеру со включенным контроллером беспроводной сети или использовать «WPS-снюхивание», если у вас аллергия на провода. Через пару минут новые «кинетики» появятся в списке устройств, управление которыми можно возложить на контроллер Wi-Fi, и всё, что для этого надо — нажать соответствующую кнопку в интерфейсе.
Наконец-то можно отключить Ethernet-провод и разнести точки доступа (в терминологии Keenetic — ретрансляторы) с контроллером по разным помещениям: для передачи данных они будут использовать Wi-Fi канал. Обратите внимание: ни имя точки доступа (SSID), ни пароль для вновь прибывших хот-спотов указывать не нужно, всё это вы задаёте в контроллере Wi-Fi на головном устройстве.
Конечно, основной плюс mesh-комплектов — это наличие приложения для мобильного телефона, которое облегчает процесс настройки оборудования (да, в 2019 году настройка Wi-Fi всё ещё вызывает у кого-то сложности). У Keenetic специально для новых возможностей Wi-Fi-системы не так давно вышло новое одноименное приложение Keenetic. Оно уже имеет более подробные сведения о вашей Wi-Fi инфраструктуре, но всё равно пока не располагает мобильным помощником для расстановки точек доступа по дому. С другой стороны, благодаря веб-интерфейсу вы можете всё настроить, даже не имея доступа к интернету (хотя обновление при первичной настройке очень желательно).
Для использования программа Keenetic требует регистрации в облаке, и благодаря этому получает возможность посылать вам на мобильник уведомления об отключении одного из узлов вашей Mesh-сети.
Тестирование и общие впечатления
У многих пользователей обоснованно возникают сомнения касаемо скорости выхода в интернет в Mesh-системах, особенно на дальних узлах, связанных по беспроводному каналу. Конечно, каждый новый узел в цепочке повышает и задержку на прохождение пакета, и как следствие — общую скорость соединения. Давайте проверим, насколько это критично, для чего соберём тестовый стенд из трёх «Кинетиков», как показано на схеме ниже:
Как вы можете видеть, интернет подключен к Keenetic Viva, выполняющему роль роутера и контроллера Wi-Fi-системы. Связь с первым коленом нашей беспроводной сети идёт на скорости 780 Мбит/с, а уже третье колено в виде Keenetic City ограничено в скорости Backhaul своим приемопередатчиком 1х1 до 433 Мбит/с. Здесь же заметим, что в двухдиапазонных моделях Keenetic, выпускаемых в последние два года, бэкхоул всегда работает только в диапазоне 5 ГГц. Для пользовательской сети 2,4 ГГц его с натяжкой можно считать выделенным, а для 5 ГГц — он безусловно разделяемый. Бояться этого не надо, потому что более половины приемлемых по цене mesh-комплектов имеет аналогичную двухдиапазонную натуру.
Для начала создадим тестовую клиентскую сеть в диапазоне 5 ГГц и проверим скорость выхода в интернет со смартфона (802.11ac c максимальным линкрейтом 433 Мбит/с) и ноутбука (802.11n с линкрейтом до 300 Мбит/с) при подключении к каждому из «Кинетиков».
Тест скорости Mesh системы на 5 ГГц
Источник