I1. The Mesh Adaptation Daemon (MAD) - Демон настройки Mesh

Цель - реализовать демон, ориентированный на пользователя, который будет настраивать mesh-сеть для улучшения ее масштабируемости и надежности. В будущем возможно использование адаптации для уменьшения потребления энергии.

Демон получает статистику от драйвера или другого подходящего источника и настраивает параметры сети по заданным заранее схемам.

Эвристики работы MAD

Идея: сделать частоту multicast-рассылок зависящей от плотности сети. Для этого нужно определить, через что определять плотность и как ее измерять.

Плотность против периодичности рассылок

В плотной сети увеличивать периодичность multicast/broadcast рассылок.

Периодичность рассылок определяет компромисс между покрытием сети и затрачиваемым временем. Редкие рассылки дойдут до удаленных узлов, но они могут застопорить/перегрузить сеть собой (это долго живущие пакеты) и необходимостью их постоянно пересылать ( непонятный момент). В плотной сети велика вероятность получения кадра при частой рассылке, так как узлы ближе расположены друг к другу и число пересылок в такой сети больше.

Возможным недостатком такой политики может стать обособление отдельных удаленных узлов, которые станут меньше участвовать в работе сети. Необходима проверка, действительно ли эти узлы будут испытывать трудности и в какой степени (если да).

Варианты механизма нахождения активных соседей:

просмотр таблицы маршрутов и расчет числа обратных маршрутов ( вероятно время окончания срока действия маршрута станет адаптивным и тогда оно должно будет влиять на данный алгоритм);

число обнаруженных за определенный интервал кадров-маячков ( требует встраивания в прошивку);

число адресов удаленных источников или пересылающих узлов, обнаруженных за определенный интервал ( требует встраивания в прошивку).

Производительность против метрик

Если узел работает на батарее, он должен акцентировать (показывать) худшие метрики.

Механизм нахождения маршрутов должен в первую очередь обрабатывать узлы, питающиеся от аккумулятора и т.п., что поможет продлить время работы батареи.

Возможный недостаток - появление в маршруте лишних переходов (хопов).

I2. Уменьшение управляющего трафика

Частота, с которой ХО передает управляющий трафик (запросы/ответы специального устройства для сбора информации), может быть уменьшена без ущерба функциональности, что значительно сэкономит время передачи.

добавить подробное описание

I3. Реализация лучшего алгоритма адаптации скорости передачи

Из-за ограниченных ресурсов памяти в ХО встроен простой алгоритм подсчета ошибок передачи кадров, который уменьшает уровень передачи, если заданное число последовательных кадров потеряется, и, аналогично, увеличивает этот показатель, когда заданное число кадров успешно пересылаются. Проблема заключается в том, что когда пакеты теряются из-за перегрузки сети, уменьшение показателя передач сделает ситуацию еще хуже.

добавить подробное описание

I4. Агностицизм сервиса присутствия в сети

Когда сервис присутствия решает, что ХО находится в mesh-сети, он использует mDNS для опубликования и получения информации о присутствии. Когда сервис решает, что в сети есть сервер, он переключается с mDNS- на XMPP-сервер. Сервис присутствия должен выдавать решение, агностическое (независимое?) от наличия или отсутствия сервера.

I5. Разработка нового физического (PHY) уровня

Улучшить mesh через использование 802.11n PHY, который обеспечивает скорость передачи данных до 600 Мб. Улучшения на MAC-уровне в .11n включают агрегирование кадров, что может быть полезно для сети при передаче коротких кадров. В использовании .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.

I6. Подгон затрат (метрик) в каждом пакете PREQ

I7. Улучшение спектральной эффективности при broadcast рассылках

Заставить mesh использовать 802.11n PHY, который обеспечивает скорость до 600 Мбит/с. Улучшения в .11 MAC включают также возможность агрегирования кадров, что полезно при передаче множества коротких кадров. В использовании .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.

I8. Улучшение схемы IP адресации в mesh

Передача между mesh клиентом и mesh порталом испытывает проблемы: XO laptop сам приписывает себе адрес локальной подсети - 169.254; когда он находит портал, тот в свою очередь приписывает XO закрытый адрес подсети - 172.16. Лучше было бы разбить подсеть 169.254.х.х на 3 подсети для использования на каждом канале (1,6,11). Порталы mesh-сети распространяют данные о своем присутствии в сети через mDNS. Предполагается, что управление сетью в Linux уже поддерживает такую конфигурацию, но возможно Avahi потребует дополнительной настройки для работы с нестандартной локальной подсетью.

I9. Новая версия сетевого менеджера