Динамическое назначение адресов в сети IoT IEEE 802.15.4 - PullRequest
0 голосов
/ 24 мая 2019

Некоторый контекст

Сначала давайте объясним контекст, для курса мне пришлось создать некоторый протокол для экономии энергопотребления в сети IoT IEEE 802.15.4 (таким образом, как оптимизировать маршрутизацию, обнаружение ошибок, ... для экономии энергии, поскольку устройства работают от батареи). Сеть должна быть древовидной, и у каждого узла есть только один родитель (я знаю, что это не лучшее решение, но это были требования учителя). Мы должны были построить его с помощью трансляции и (r) одноадресной передачи Rime. Адрес Rime - это два 8-битных значения (может быть расширено до двух 16-битных значений, но я бы хотел не использовать их, чтобы пакеты были как можно меньше).

На contiki все работает нормально, поскольку rime автоматически присваивает узлам адрес (основывается на идентификаторе узла, который присваивается при добавлении в симуляцию). При переходе на аппаратное обеспечение все узлы имели одинаково жестко идентифицированный идентификатор (таким образом, тот же адрес) и, конечно, ничего не работало Поэтому я начал думать о , как назначать адреса новым узлам в сети?

Некоторые решения, которые я нашел

Пришли разные решения:

  1. Не делайте этого динамически и жестко кодируйте адреса в каждом новом узле, который вы хотите добавить в сеть. Из того, что я прочитал, это обычная практика, но я не удовлетворен этим, поскольку это не совсем удобно для пользователя, и мы должны поддерживать некоторый список всех заданных адресов для каждой сети.

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

  3. Совершенно та же идея, что и в 2. , но здесь родительский узел не будет давать уникальный адрес своему новому дочернему элементу, но диапазон адресов, дочерний элемент выберет один и сможет дать новый диапазон своим детям (опять же, это то, что делают обычные сети). Это лучшее решение, чем предыдущее, но большой недостаток в том, что мы ограничены в сети (довольно много). Как объяснено выше, адреса представляют собой два 8-битных значения, это составляет 65536 различных адресов, и при таком решении максимальная глубина сети будет равна 6, поэтому в худшем случае в сеть можно добавить только 6 узлов ...

  4. Последняя идея - позволить новому узлу выбрать адрес при загрузке. Это было бы случайное значение. Поэтому я попытался найти вероятность того, что в сети будет два и более одинаковых адреса, и понял, что это та же проблема, что и день рождения . После некоторой математики я нашел следующую статистику: General overview

Мы видим, что это быстро повышает вероятность появления дубликатов, при 300 узлах у нас 50% вероятность дублирования узла. Если мы посмотрим поближе, то увидим, что при 40 узлах вероятность дублирования узлов составляет менее 1%, это становится приемлемой вероятностью.

Closer look

Но у нас все еще будет некоторая вероятность иметь дублированные узлы, и это работает для небольших сетей, для больших сетей потребуется кодировать адреса в двух 16-битных значениях (чего я пытался избежать). Преимущество двух 16-битных значений для адреса состоит в том, что вероятность наличия дублированных узлов будет очень низкой даже для довольно больших сетей (не нужно показывать графики или цифры ... Мой компьютер не любил вычислять 2 ^ 32!)

Мой вопрос

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

На какой вариант мне идти? Простое решение и не пытайтесь сделать это динамически или является динамически возможным решением? Есть ли некоторые протоколы (не уверены, что это правильный термин), которые уже решают эту проблему?

Любой совет или критика по поводу моих рассуждений приветствуются, и любая новая идея приветствуется.

Спасибо, что нашли время, чтобы прочитать все это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...