Маршрутные метрики многошаговых беспроводных самоорганизующихся сетей

УДК 004.057.4

И.О. Датьев

Институт информатики и математического моделирования технологических процессов Кольского НЦ РАН

МАРШРУТНЫЕ МЕТРИКИ МНОГОШАГОВЫХ БЕСПРОВОДНЫХ САМООРГАНИЗУЮЩИХСЯ СЕТЕЙ

Аннотация

На сегодняшний день, многошаговые беспроводные сети являются перспективнейшим направлением информационно-коммуникационных сетей. В работе представлена попытка обобщения опыта прошлых лет различных авторов в вопросах разработки метрик маршрутизации, ориентированных на особенности передачи данных в многошаговых беспроводных сетях. В частности, приводятся характеристики беспроводной передачи, которые рекомендуется учитывать при разработке метрик маршрутизации. Кроме того, обсуждаются достоинства и недостатки наиболее ярких примеров уже созданных для беспроводных многошаговых сетей маршрутных метрик.

Ключевые слова:

многошаговые беспроводные сети, компоненты метрики маршрутизации.

I.O. Datyev

ROUTING METRICS OF MULTIHOP WIRELESS AD-HOC NETWORKS Abstract

To date, multihop wireless networks are a promising direction of information and communication networks. The paper presents an attempt of different authors past experience generalization in the development of routing metrics based on multihop wireless networks data transmission features. In particular, characteristics of wireless transmission that are recommended to be considered during the design of routing metrics are reviewed. In addition, discuss the advantages and disadvantages of the most striking routing metrics examples already created for multihop wireless networks.

Keywords:

multihop wireless networks, routing metric components.

Введение

На сегодняшний день, выявление лучшего для передачи пакета данных маршрута, подразумевает использование протоколами маршрутизации т.н. «метрики». Метрика представляет числовую, как правило, характеристику маршрута. При формировании этой характеристики могут учитываться различные факторы. Наиболее распространенными из них являются [1]:

• количество передач (хопов), которое необходимо совершить для доставки пакета;

• полоса пропускания канала;

• стоимость передачи данных по каналу;

• надежность;

• задержка и т.д.

Таким образом, метрика используется алгоритмами маршрутизации для определения наилучшего пути к получателю данных.

115

С целью упрощения процесса поиска маршрута алгоритмы маршрутизации создают и регулярно обновляют таблицы маршрутизации, в которых содержится информация о маршрутах. Информация о маршрутах меняется в соответствии с правилами, заложенными в используемом алгоритме маршрутизации.

В случае статической маршрутизации значение метрики обычно не изменяется в пределах сессии. Но когда сеть представляет собой совокупность перемещающихся узлов, например, мобильная самоорганизующаяся сеть -MANET [2], вместе с изменением маршрутов меняется метрика.

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

С конца 90-х, инженерный совет интернет (IETF) [3] вступил на путь разработки протоколов маршрутизации для сетей со все более ненадежными соединениями малой пропускной способности, обладающими непредсказуемой связностью и ограниченными ресурсами маршрутизаторов. В 1997 году запланировали создание рабочей группы MANET (мобильные самоорганизующиеся сети), затем в 2006 и 2008 годах, были созданы рабочие группы 6LoWPAN (трафик IPv6 в сетях низкой мощности WPAN) и ROLL (Routing over low power and lossy networks - маршрутизация в сетях низкой мощности с потерями (LLN - Low power and lossy networks)).

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

Hекоторые протоколы маршрутизации многошаговых беспроводных сетей позволяют использовать различные метрики, например, протокол AODVv2 [4]. При использовании различных метрик, даже в рамках одного

116

протокола маршрутизации и передачи данных, меняются и характеристики передачи данных сети. Следует отметить, что, хотя протоколом AODVv2 предусмотрена возможность использования нескольких метрик, по умолчанию предполагается использование метрики Hop-Count, т.е. количество передач между узлами, которое необходимо осуществить для доставки пакета данных от источника к получателю.

Таким образом, вопрос разработки метрик для современных типов организации сетей - MANET, MESH, VANET, LLN, концепции IoT и на сегодняшний день остается актуальным и значимым.

Используемые в качестве компонент маршрутных метрик характеристики

Беспроводные самоорганизующиеся сети, сегодня, всё больше создаются на основе другого класса сетей, называемых зарубежными авторами «Сети низкого энергопотребления (малой мощности) с потерями - Low power and lossy networks - LLNs)» [5], в которых маршрутизаторы и соединения находятся в условиях ограничений. Маршрутизаторы LLN обычно работают с ограничениями по вычислительной мощности, памяти, и энергии (батареи питания). Сетевые соединения характеризуются высокими показателями потерь пакетов, низкой скоростью передачи данных, и нестабильностью. LLNs могут состоять от нескольких десятков до тысячи маршрутизаторов. Поддерживаются следующие транспортные потоки: точка-точка (между устройствами внутри LLN), точка-многоточка (из центрального контрольного пункта к подмножеству устройств внутри LLN), и многоточка-точка (из устройств внутри LLN к центральной контрольной точке).

В спецификации RFC6551 рабочая группа ROLL организации IETF выделяет следующие существенные характеристики, которые могут быть использованы в качестве составляющих метрик и ограничений сетей класса LLN, на базе которых сегодня создаются также сети MESH и MANET.

Характеристики подразделяются на две группы:

1) метрики/ограничения узлов сети;

2) метрики/ограничения сетевых соединений.

Кроме того, в этом же документе определяются форматы представления для передачи этих характеристик на сетевом уровне модели OSI [6] посредством DAG Metric Container.

Формат передачи маршрутной информации: DAG Metric Container. DAG Metric Container - это опция, которая может присутствовать в сообщениях DIO (DODAG Information Object (DIO) или DAO (Destination Advertisement Object) [7]. Формат DAG Metric Container выглядит следующим образом:

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+........

| Type = 0x02 | Option Length | Metric Data

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------

Рис. 1. Формат опции DAG Metric Container

117

Option Type (тип опции): 0x02.

Option Length (длина опции): Поле Option Length (длина опции) содержит выраженную в октетах длину метрических данных.

Metric Data (метрические данные): Порядок, контент и кодирование данных DAG Metric Container определено в RFC6551[5].

DAG Metric Container используется для передачи метрической информации внутри DODAG.

DAG Metric Container может содержать количество отдельных узлов, соединений, аггрегированные маршрутные метрики и ограничения, определенные в RFC6551, выбранных конкретными компаниями или лицами, разрабатывающими программное обеспечение в соответствии с RFC6550 [7].

DAG Metric Container может появляться несколько раз в одном и том же служебном сообщении, например протокола RPL [7], чтобы вместить метрическую информацию длиной более 256 байт.

Обработка и передача DAG Metric Container регулируется конкретной программной реализацией специальных функций.

Метрики/Ограничения узлов

Объект «Состояние узла и атрибуты». Объект «Состояние узла и атрибуты» (NSA - Node State and Attribute) используется для предоставления информации о характеристиках узла.

Объект NSA может быть представлен в формате DAG Metric Container [7]. DAG Metric Container не должен содержать более одного объекта NSA в качестве ограничения и более одного объекта NSA в качестве метрики. Кроме того, объект NSA может содержать набор полей TLV (Туре Length Value), используемых для передачи различных характеристик узла. Примеры таких TLV на сегодняшний день нормативными документами не определены.

Типу метрики маршрутизации или ограничению NSA организацией IANA [8] присвоено значение 1.

Формат объекта NSA представлен следующим образом:

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

Рис. 2. Формат объекта NSA

Флаги Res (8 бит): зарезервированное поле. Должно быть равно 0 при передаче и должно игнорироваться при приеме информации узлом.

Флаговое поле (8 бит). Следующие два бита определены таким образом:

• Флаг ’A’: атрибут агрегации данных (data Aggregation Attribute). Некоторые приложения могут использовать этот флаг при маршрутизации для того, чтобы уменьшить объем сетевого трафика, и как следствие, увеличить время жизни узла в случае использования батареи питания. Приложения, в которых ожидаются большие потоки данных в направлении определенных узлов, могут получить преимущество от использования маршрутизации с

118

поддержкой агрегации данных. Когда флаг установлен, это означает, что узел может выступать в роли агрегатора трафика.

• Флаг ’O’: загрузку узла сложно определить и выразить скалярной величиной. Однако нагрузка на узел может быть полезной для вычисления метрики пути, в частности, когда задержки в очереди должны быть сокращены для т.н. «чувствительного» трафика уровня Medium Access Control (MAC). Флаг ’ O’ может быть установлен при перегрузке центрального процессора узла, нехватке памяти, или других связанных с узлом условиях. Использование простого однобитного флага для характеристики загрузки узла предоставляет существенный уровень детализации, подобный биту «перегрузка» в протоколе маршрутизации IS-IS. Установленный бит сигнализирует, что узел перегружен и может оказаться неспособным обработать трафик.

Неопределенные поля флагов должны быть установлены в ноль при передаче и игнорироваться при приеме.

Поля флагов NSA метрики/ограничений разработаны и управляются IANA. Не назначенные биты подразумеваются зарезервированными.

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

Мощность и энергия являются наиболее критическими ресурсами в большинстве сетей класса LLN. До сих пор не разработано простой абстракции, которая бы адекватно представляла все типы источников и накопителей энергии, используемых в узлах современных LLN. Узлы сети могут быть подключены к центральной электрической сети, аккумуляторам, т.н. альтернативным источникам энергии (солнечным батареям, ветряным мельницам, различного рода преобразователям вибраций в электроэнергию и т.д.) и другой непредсказуемой энергии.

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

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

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

119

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

Учитывая сложность попытки сформулировать такой широкий набор ограничений, документ RFC6551 определяет два уровня точности.

Самое простое решение основывается на 2-битовом поле, кодирующем три вида источников питания: "подключенный к централизованной сети", "аккумулятор", и "альтернативный" (солнечная, виброэнергия и т.д.).

Этот простой подход может быть достаточным для многих приложений.

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

Для узлов с источником питания типа «альтернативный», 8-битное значение представляет собой мощность, предоставляемую «альтернативным» источником Pin, деленную на мощность, потребляемую приложением Pout:

E _ E = P _ in / P _ out.

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

Для устройств с батарейным питанием, E_E будет равно текущей ожидаемой продолжительности жизни, деленной на желаемый минимальный срок службы, в процентах. Оценка оставшейся энергии батареи и фактическое энергопотребление могут быть сложны для расчета. Рассмотрим два примера. Если узел может измерить своё среднее энергопотребление, то E_E можно расчитать как отношение желаемой максимальной мощности (начальная энергия E_0 деленная на желаемый срок службы Т) к фактической мощности:

E _E = P_max/ P_now .

Другим примером является случай, когда есть оценки энергии в аккумуляторе E_bat и известно общеее прошедшее время жизни t. Тогда E_E может быть рассчитана как количество оставшейся энергии, деленное на желаемое значение оставшейся энергии:

E _ E = E _ bat /[ E _0 х

Примером оптимизированного маршрута может служить макс(мин(Е_Е)) для всех питающихся от батарей узлов маршрута, при условии ограничения, что E_E> = 100 для всех узлов маршрута с питанием альтернативного типа.

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

Объект «Энергия узла» (NE) может быть представлен в формате DAG Metric Container. DAG Metric Container не должен содержать более одного объекта NE в качестве ограничения и более одного объекта NE в качестве метрики.

Типу NE метрики маршрутизации или ограничению организацией IANA присвоено значение 2.

120

Формат объекта NE выглядит следующим образом:

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

| NE подобъекты

Рис. 3. Формат объекта NE

Формат подобъекта NE выглядит следующим образом:

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

Рис. 4. Формат подобъекта NE

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

Поле Флаги (8 бит). На сегодняшний день определены следующие флаги:

1 (Included): ’I’ бит имеет значение только тогда, когда Тип узла используется в качестве ограничения. Например, путь должен проходить только через питающиеся от сети узлы. Наоборот, узлы на батареях должны быть исключены. Когда бит ‘I’ установлен, это указывает на то, что узлы, Тип которых указан в поле «Тип узла» должны быть включены в маршрут. И наоборот, когда бит сброшен, это означает, что узлы типа, указанного в поле «Тип узла» должны быть исключены из маршрута.

T (node Type - Тип узла): 2-битовое поле, определяющее Тип узла Т=0 обозначает, что узел питается от центральной сети, Т=1 - питание от батареи узла, Т=2 - узел типа «поглотитель».

Е (Estimation - Оценка): когда бит " Е " установлен в 1 это значит, что 8битовое поле E_E содержит предполагаемый процент оставшейся энергии на узле. Когда бит установлен в 0, оценка процента оставшейся энергии не предусматривается. Когда бит " Е " используется для ограничения, поле E_E определяет порог для включения/исключения: если включение, то узлы со значениями выше порогового включаются в маршрут; если исключение, то узлы со значениями ниже порогового должны быть исключены из маршрута.

E_E (Estimated-Energy - Оставшаяся Энергия): 8-битное беззнаковое целое поле, указывающее приблизительный процент оставшейся энергии. Поле E_E имеет значение только тогда, когда флаг ’Е’ установлен.

Если объект NE состоит из нескольких подобъектов при использовании в качестве ограничений, каждый подобъект добавляет или вычитает подмножества узлов маршрута по мере обработки подобъектов в порядке их следования. Начальный набор (полный или пустой) определяется битом ’I’ из первого подобъекта: полный, если бит ’ I’ сброшен, пустой, если бит ’ I’ установлен в 1.

121

Одним из примеров использования характеристики «Энергия узла» в составе метрики маршрутизации является работа [9] зарубежных авторов, где предлагаемая метрика основана на пропускной способности, энергии, количестве хопов и времени и должна повысить энергоэффективность протокола маршрутизации PCBR (Position Changes Based Routing Protocol).

Количество передач (шагов, хопов). Количество хопов используется для предоставления отчетов о числе пройденных узлов во время следования по маршруту.

Формат объекта Hop Count (HC) выглядит следующим образом:

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4

| Res | Flags | Hop Count | Optional TLVs

Рис. 5. Формат объекта HC

Флаги Res (4 бита): Зарезервированное поле. Это поле должно быть равным нулю при передаче и должно игнорироваться при приеме.

В настоящее время, поля Res и Flags не определены. Не назначенные биты считаются зарезервированными. Они должны быть установлены в ноль на передаче и должны быть проигнорированы при приеме.

Объект «Количество хопов» (HC) может быть представлен в формате DAG Metric Container. DAG Metric Container не должен содержать больше, чем один объект HC в качестве ограничения и больше, чем один объект HC в качестве метрики.

Типу метрики маршрутизации или ограничению HC организацией IANA присвоено значение 3.

Объект HC может быть использован в качестве ограничения или метрики. При использовании в качестве ограничения, начало DAG Metric Container указывает на максимальное количество хопов, которое может содержать маршрут. Когда это число будет достигнуто, никакой другой узел не сможет быть присоединен к этому пути. При использовании в качестве метрики, каждый промежуточный узел просто увеличивает поле Hop Count.

Следует отметить, что метрика «Количество хопов» принята в качестве метрики по умолчанию в сетях MANET. Так, например, даже в новой версии протокола AODVv2, по умолчанию используется метрика «Количество хопов». Однако в AODVv2, возможно использование т.н. «альтернативных метрик», не определенных в самой спецификации этого протокола. Механизм использования разных метрик организован следующим образом. Каждая метрика в AODVv2 имеет свой тип - MetricType. MetricType выделены организацией IANA, как это указано в RFC6551 [5]. Использование альтернативной метрики требует включения в MetricType элемента данных в соответствующем сообщении RteMsg (Route Message). Маршруты ищутся согласно типам метрики, и промежуточные маршрутизаторы обрабатывают RteMsg в соответствии с назначенным одинаковым типом метрики. Для каждого типа метрики, определяется

122

максимальное значение и обозначается MAX_METRIC[i], где 'i' - это тип метрики(МеШсТуре). AODVv2 не может хранить маршруты в своих таблицах маршрутизации, значение метрики которых превышает MAX_METRIC[i]. В целях упрощения хранения описания стоимостей маршрутов в таблице маршрутизации, определена функция стоимости. Эта функция возвращает стоимость передвижения по маршруту ('Cost(R)') или соединению ('Cost(L)'). Описание функций стоимости для альтернативных метрик в спецификации AODVv2 не приводится.

Поскольку определение наличия циклов, зависит от сравнения Cost(R1) предлагаемого нового маршрута с существующим сохраненным Cost(R2) с помощью той метрики того же типа, AODVv2 включает в себя вызов функции называемой "LoopFree (R1, R2)". LoopFree (R1, R2) возвращает True, когда R1 гарантированно не зависит от маршрута R2, т. е. R2 не является подмаршрутом маршрута R1. В AODVv2 маршрутизатор вызывает функцию LoopFree(), чтобы сравнить предлагаемый маршрут с сохраненным маршрутом. Предлагаемый маршрут называется AdvRte и обозначается R1, сохраненный маршрут обозначается как маршрут R2. Диапазон и тип данных каждой такой альтернативной метрики может отличаться, что необходимо принимать во внимание при разработке программных реализаций, основанных на спецификации AODV. Следует отметить, что в некоторых ситуациях метрика «Количество хопов» может стать причиной выбора наихудших из возможных маршрутов, именно поэтому спецификация AODVv2 позволяет использовать другие метрики. Однако описание таких метрик и примеров их использования в самой спецификации не приводится, что в некоторой степени снимает ответственность с авторов за эффективность функционирования протокола.

Метрики/ограничения соединений

Как указано в RFC6551 следующие характеристики можно учитывать для вычисления метрики или ограничений.

Пропускная способность. Многие сети LLN поддерживают широкий диапазон пропускной способности. Для некоторых соединений, причиной этого может быть переменное кодирование. Для циклично-нагруженных соединений, присущих многим сетям LLN, изменчивость возникает в результате расплаты потреблением мощности за битрейт (скорость передачи). Существует несколько протоколов MAC-уровня, которые допускают изменение скорости передачи данных соединения в интервале более чем трех порядков с соответствующим изменением в энергопотреблении. Для эффективной работы, желательно, чтобы узлы сообщали диапазон пропускной способности, который их соединения могут обрабатывать в дополнение к имеющейся в настоящее время пропускной способности.

Объект «пропускная способность» состоит из подобъектов и должен содержать, по крайней мере, один подобъект.

Пропускная способность объекта может присутствовать в DAG контейнере. Первый подобьект должен являться наиболее актуальной оценкой пропускной способности. Длина каждого подобьекта фиксирована и равна четы-

123

рем байтам. Объект «пропускная способность» не содержит дополнительных полей TLV.

Типу обьекта «пропускная способность» организацией IANA присвоено значение, равное 4.

Задержка. Аналогично пропускной способности, задержки многих уровней MAC в LLN могут отличаться на несколько порядков, соответствуя изменениям в энергопотреблении. Некоторые уровни MAC в LLN позволяют корректировать задержку в масштабе подсети, конкретного соединения и не только. Другие MAC-уровни предполагают, что для каждого соединения задержка должна быть фиксированной.

Объект «задержка» может быть представлен в формате DAG Metric Container. DAG Metric Container не должен содержать более одного объекта «задержка» в качестве ограничения и более одного объекта «задержка» в качестве метрики.

Объект «задержка» состоит из подобьектов и должен содержать хотя бы один подобъект.

Длина каждого подобъекта равна 4 байтам.

Объект «задержка» не содержит дополнительных полей TLV.

Типу объекта «задержка» организацией IANA присвоено значение 5.

Объект «задержка» является метрикой или ограничением.

Формат объекта «задержка» выглядит следующим образом:

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (sub-object).

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рис. 6. Формат объекта «задержка»

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рис. 7. Формат подобъекта «задержка»

Задержка кодируется 32 -мя битами в беззнакового целого и выражается в микросекундах. Объект «задержка» может использоваться в качестве ограничения или метрики маршрута. Например, если задержка не должна превышать заданного значения. В этом случае общий заголовок объекта «задержка» индицирует, что содержащееся значение представляет собой ограничение. В другом примере, объект «задержка» может быть использован как агрегированная аддитивная метрика, где его значение обновляется во время следования по маршруту для отражения задержки маршрута.

124

Надежность соединения. В сетях LLN, надежность соединения может снизиться по ряду причин: затухание сигнала, интерференции различных форм и др. Шкалы времени изменяются от миллисекунд до нескольких дней, часто являются периодическими и связаны с человеческой деятельностью. Некоторые показатели, например, количество ошибок в пакете могут быть измерены напрямую, а другие, например, частота появления ошибок по битам, среднее время между отказами вычисляются на основе этих измерений. Такое разнообразие характеристик не является специфичным только для беспроводной связи, но также применяется для соединений PLC (power line communication).

Изменение качества связи может повлиять на связность сети; таким образом, качество соединений можеть быть принято во внимание в роли критической метрики маршрутизации.

Количество метрик может быть определено различными аспектами надежности. Две метрики надежности определены в RFC6551: уровень качества соединения (LQL) и метрика ETX. Причем, следует отметить, что эти метрики могут использоваться как по отдельности, так и вместе.

Цвет (раскраска) соединений. В RFC655Юбъект Цвет соединения (ЦС) -административное 10-битное ограничение канала (которое может регулироваться, как статически так и динамически), используемое чтобы избежать или, наоборот использовать определенные соединения для конкретных типов трафика. Объект Цвет соединения может быть использован в качестве метрики или в качестве ограничения.

Цвет определяется как определенный набор битовых значений: другими словами, это 10-битовое поле - это поле флага, а не скаляр. Каждый узел может затем использовать ЦС для выбора родительских узлов на основе определенных пользователем правил (например, "выберите путь с максимальным количеством соединений, у которых первый бит равен 1 (например, зашифрованные соединения). ЦС может передаваться с помощью DAG.

Вычисление динамических метрик и атрибутов

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

125

Маршрутные метрики

Link quality level (LQL). Уровень качества соединения (LQL - link quality level) применяется для количественной оценки надежности, используя дискретное значение, от 0 до 7, где 0 означает, что качество соединения неизвестно и 1 означает высший уровень качества соединения, 7 означает самый низкий уровень качества. Механизмы и алгоритмы, используемые для вычисления LQL определяются конкретной реализацией. LQL может быть использован как в качестве метрики, так и в качестве ограничения. Объект LQL может быть представлен в контейнере DAG, где не должно содержаться более одного объекта LQL в качестве ограничения и более одного объекта LQL в качестве метрики.

Expected Number of Transmissions (ETX). Метрика ETX - это количество передач, которые узел рассчитывает произвести, чтобы успешно доставить пакет к месту назначения. В противоположность метрики маршрутизации LQL, ETX является дискретным значением (которое может не быть целым числом), вычисленным по определенной формуле. Например, реализация может использовать следующую формулу:

ETX

1

Df х Dr ’

где Df - измеренная вероятность того, что пакет получен соседним узлом,

Dr - измеренная вероятность получения пакета подтверждения.

Документ RFC6551 [5] не определяет использование конкретных формул для вычисления значения ETX. Объект ETX также может присутствовать в контейнере DAG, где не должно быть использовано более одного объекта ETX в качестве ограничения и более одного объекта ETX в качестве метрики. Кроме того, в документе [5] указывается, что объект ETX состоит из подобъектов ETX и должен, как минимум, содержать один подобъект ETX. Каждый ETX подобъект имеет фиксированную длину 16 бит.

Преимущества:

1. Метрика ETX основана на коэффициенте доставленных пакетов, который, в свою очередь, непосредственно связан с пропускной способностью и учитывает влияние и ассиметрию коэффициента потерь конкретного соединения.

2. ETX способствует выбору пути с более высокой пропускной способностью и меньшим количеством шагов (хопов), поскольку длинные пути имеют меньшую пропускную способность из-за внутрипотоковых [ 18] помех.

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

4. ETX является изотонической [10], и, следовательно, допускает эффективное вычисление кратчайшего маршрута без зацикливаний.

Недостатки:

1. Метрика ETX предназначена для одноканальной многошаговой беспроводной сети.

126

2. ETX учитывает только коэффициент потерь соединения, игнорируя помехи, которые оказывают существенное влияние на качество соединения и скорость передачи данных.

3. ETX не учитывает различий в скоростях передачи.

4. Поскольку скорость передачи зондовых пакетов, как правило, низка, метрика не точно отражает коэффициент потери скорости фактического трафика.

5. ETX не дает никакой информации о совместном использовании соединений.

6. ETX может прокладывать маршруты через высоконагруженные соединения, поскольку не учитывает загрузку соединений.

7. ETX не учитывает различий между маршрутами, использующими один и тот же канал и маршрутами, использующими разные каналы. Таким образом, ETX не делает попыток, чтобы свести к минимуму внутрипотоковую интерференцию.

8. В высокомобильных одноканальных средах, ETX показывает плохую скорость из-за длительного временного окна, в течение которого происходит передача маршрутной информации.

Expected Transmission Time (ETT). Ожидаемое время передачи ETT (expected transmission time)[11], является расширением ETX.

В этой метрике [12] принимается во внимание различие скоростей соединений маршрута. ETT представляет собой ожидаемое время успешной передачи пакета на подуровне MAC и определяется для одного соединения следующим образом:

-

ETT = ETХ х -,

B

где S - средний размер пакета,

B - пропускная способность соединения.

ETT всего пути рассчитывается посредством сложения всех значений ETT для отдельных соединений, составляющих этот путь.

Преимущества ETT:

1. За счет учета пропускной способности каждого соединения может быть увеличена общая пропускная способность пути и соответственно, производительность сети в целом.

2. ETT является изотонической (isotonic).

Недостатки:

1. ETT сохраняет много недостатков ETX.

2. Не учитывает загрузку соединений явно, вследствии чего возможны перегрузки соединений и узлов сети.

3. Не предназначена для multiradio сетей, поэтому не минимизирует взаимные помехи узлов.

Weighted Cumulative Expected Transmission Time (WCETT). Взвешенное совокупное ожидаемое время передачи (WCETT) [12] является расширением ETT. В WCETT метрика пути p, определяется следующим образом:

127

WCETTp = (1 -a)x£ETTtaxX},

iG p

где X  - сумма ETT соединений, использующих канал j в системе ортогональных каналов, a - это настраиваемый параметр, 0 <а< 1, который позволяет регулировать соотношение важности длины пути и отличия используемых каналов.

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

Преимущества:

1. WCETT учитывает интерференцию и способствует выбору пути с соединениями, использующими разные каналы.

2. Сохраняет все преимущества ETT, кроме изотоничности.

3. Улучшается производительность мульти-радио беспроводных сетей с соединениями разных скоростей по сравнению с более простыми метриками, такими как ETT, ETX и Hop Count. 4. Две взвешенные компоненты настраиваются а, представляют собой простые суммы ETT и позволяют балансировать между пропускной способностью и задержкой.

Недостатки:

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

2. Поскольку метрика не изотоническая, ее очень сложно использовать в протоколах маршрутизации, основанных на состоянии канала.

3. WCETT не явно учитывает влияние взаимных помех, поэтому может способствовать выбору маршрутов с высоким уровнем помех.

4. Метрика обладает схожими с ETX и ETT недостатками и не предусматривает эффективного совместного использования соединений.

Модификация WCETT, названная WCETT-LB (load-balancing) [11] призвана улучшить характеристики данной метрики в области балансировки нагрузки. Следует отметить работу [13], в которой производится исследование различных методов балансировки нагрузки для беспроводных сетей.

Metric of Interference and Channel switching (MIC). Метрика помех и коммутации каналов (MIC) [14] предназначена для поддержки маршрутизации с балансировкой нагрузки, учитывает помехи между различными потоками и помехи внутри одного потока. MIC маршрута p определяется следующим образом:

128

MIC

1

N x min

i ’

link i^p

где N - число узлов сети,

min(ETT)link - самое маленькое ETT в сети,

IRU (Interference-aware Resource Usage - помехи, сопряженные с использованием ресурсов) и CSC (Channel Switching Cost - стоимость коммутации каналов) определяются следующим образом:

где N - множество соседей, которые создают помехи на линии i;

CH(i) - канал передачи узла i; prev(i) - предшествующий i-тому узлу хоп по маршруту р.

Преимущества:

1. Метрика MIC учитывает внутрипотоковую и межпотоковую интерференцию и может быть изотонична, если применить декомпозицию на виртуальные узлы при использовании поиска наикратчайшего пути с помощью алгоритмов подобных алгоритму Дейкстры.

Недостатки:

1. Затраты (служебный трафик), необходимые для поддержания обновления информации ETT для каждого соединения может значительно повлиять на производительность сети в случае больших объемов передаваемой информации.

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

3. Компонент CSC учитывает внутрипотоковые помехи только для двух последовательных соединений.

Load Aware ETT (LAETT). Главные цели LAETT [15] - это формирование маршрута, который удовлетворяет требованию пропускной способности потока и освобождает место для будущих запросов, балансируя нагрузку по всей сети. LAETT сочетает в себе характеристик беспроводной передачи и оценки загрузки. Основана на адаптации ETT, которая вычисляется следующим образом:

где ETXjj - ожидаемое количество передач между узлами i и j (метрика ETX);

S - размер пакета;

B  - эффективный битрейт.

IRU = ETT x N.

CSC = w1 if CH(prev(i)) * CH(i).

CSC = w2 if CH(prev(i)) = CH(i) ,0 < w1 < w2.

ETT„ = ETX<, xS.

4

4

129

B

ij

A

ytj ’

B - скорость передачи узла i;

yy . - параметр качества соединения.

у = 1, если качество соединения хорошее, при ухудшении качества

соединения параметр yy . увеличивается;

Для осуществления балансировки нагрузки, для каждого узла i вводится характеристика, названная остаточной пропускной способностью RCt и вычисляется по формуле:

N

RC, = B,-£ fy ,

к=1

где fik - скорость N потоков, проходящих через узел i в данное время.

Оценка остаточной пропускной способности регулируется yik, поскольку при хорошем качестве соединения требуется меньше ресурсов для передачи информации.

Алгоритм «packet-pair» может быть использован для оценки доступной

полосы пропускания соединения с параметром yik .

Метрика LAETT рассчитывается следующим образом:

LAETT, = ETX,х--------------

ij ij (RC, + RC,)/2yu

Второй множитель учитывает остаточную пропускную способность конечных узлов i и j. Когда два маршрута имеют один и тот же вес ETX, метрика LAETT способствует выбору маршрута с большей остаточной емкостью

Преимущества:

LAETT представляет собой изотоническую метрику, осуществляющую балансировку нагрузки по всей сети.

2. LAETT учитывает качество и загруженность соединения.

Недостатки:

Не учитывается внутрипотоковая интерференция. Кроме того, межпотоковая интерференция в явном виде тоже не рассматривается.

Exclusive Expected Transmission Time (EETT). Эксклюзивное ожидаемое время передачи (EETT) [16] - это метрика, учитывающая помехи и способствующая выбору многоканальных маршрутов с наименьшими помехами с целью максимизации пропускной способности между двумя конечными узлами маршрута. Данная метрика используется для получения более точной оценки многоканального пути. Для любого заданного соединения l, определяется множество IS (Interference Set) - множество соединений, создающих помехи друг другу. Также IS включает непосредственно сам узел l.

130

EETT для соединения l определяется следующим образом:

EETT, = £ ETTi ,

linkiGIS

где IS (l) - множество соединений, создающих помехи соединению l.

Вес пути (маршрута) определяется как сумма метрик EETT каждого соединения маршрута.

Преимущества:

1. Метрика EETT обладает всеми достоинствами метрики ETT.

2. EETT учитывает внутрипотоковые помехи и, неявным образом, межпотоковые помехи.

3. EETT является изотонической.

Недостатки:

EETT соединения l представляет степень занятости канала, используемого соединением l. Это наихудшая (наибольшая) оценка времени передачи по соединению l.

Interference Load Aware (ILA). Метрика ILA [17] построена на основе метрики MIC. ILA состоит из двух компонентов: метрики помехи в канале (Metric of channel interference - MTI) и стоимости коммутации канала (channel switching cost - CSC). Компонента CSC такая же, как в метрике MIC. MTI

определяется следующим образом:

MTIt

MTI

AILtj (C) - cредняя загрузка соседей, которые могут создать помехи при передаче между узлами i и j через канал С.

En ILAC)

AIL,j

N l

где IL (C) - загрузка соседей, создающих помехи узлам i и j,

N (C ) - множество узлов, создающих помехи узлам i и j.

В итоге, вес маршрута p рассчитывается следующим образом:

ILA

linkiGp nodeiGp

Для балансировки разности шкал этих двух слагаемых применяется нормировочный коэффициент а :

— = min(ETT) х min(AIL), N (C) * 0, (19) а

— = min

а

где min(ETT) и min(AIL) - минимальное значение ETT и AIL в сети.

Важным вопросом реализации этой метрики является оценивание загрузки соседей, создающих помехи при передаче.

131

Преимущества:

1. Эта метрика устраняет недостатки следующих метрик: Hop Count, ETT, ETX, WCETT, MIC для беспроводных самоорганизующихся сетей.

2. ILA способствует выбору маршрута с меньшими перегрузками, низким уровнем помех, меньшим коэффициентом отбрасывания пакета и высокой скоростью передачи данных.

3. ILA, в отличие от MIC, рассчитывает межпотоковые помехи посредством учета количества трафика, генерируемого создающими помехи соседями.

Недостатки:

Компонент CSC учитывает внутрипотоковые помехи только двух последовательных соединений.

Interference Aware routing metric (iAWARE). iAWARE [18] является первой метрикой маршрутизации для мультирадио MESH-сетей, учитывающей межпотоковые и внутрипотоковые помехи с помощью модели интерфейса физического уровня. В этой модели соединение между узлами u и v является успешным, если SINR (отношение сигнал/(шум и помехи)) в приемнике выше определенного порога, который зависит от желаемых характеристик передачи (канал, скорость передачи данных и т. д.).

P (и) - мощность сигнала пакета от узла u в узле v. Тогда пакет на

соединении (и, v) от узла u к узлу v корректно получен, если:

Pv

N + Т Р

Z—iweV' v v J

^P ,

где N - фоновый шум;

V ' - множество одновременно осуществляющих передачу узлов;

P - константа, зависящая от скорости данных, характеристик канала,

схемы модуляции и т.д.

SINR (и) - отношение сигнал/(шум и помехи) на соединении i узла u; SNR (и) - отношение сигнал/шум на соединении i узла u;

P

SNR

1 N

SINR

Р

N + Z wsU(u)T(w)Pu (w)’

где Л(и) - множество узлов, которые находятся в зоне радиодоступа узла u,

t(w) - нормализованная средняя за период времени скорость, с которой узел w генерирует трафик, t(w) равно 1, когда узел рассылает пакеты на максимально доступной скорости. z(w') используется в качестве весового коэффициента мощности сигнала создающего помехи узла w, поскольку t(w) представляет собой часть времени, когда канал занят узлом w.

132

iAWARE метрика маршрута p определяется следующим образом:

П

iAWARE

i=1

где X  - то же, что и в метрике WCETT,

iAWARE метрика соединения j вычисляется следующим образом:

ETT

iAWARE, =  1

IR,

где IR - коэффициент интерференции (помех) соединения j между узлами u и v,

IRi = min(IRi (u). IRi(v)),

SINR

IR (u) =

SNRг

Преимущества:

1. iAWARE учитывает эффект изменения коэффициента потери пакетов, отличия в скорости передачи, а также внутри- и межпотоковые помехи.

2. iAWARE сохраняет многие свойства WCETT за исключением обработки измерений межпотоковой интерференции. iAWARE напрямую измеряет среднее значение радиопомех, создаваемых соседними узлами.

3. Введение SINR является значимым открытием для вычисления межпотоковой интерференции маршрутизации по сравнению с другими основанными на ETX метриками: MIC, ETX, WCETT и др.

Недостатки:

1. iAWARE не является изотонической метрикой маршрутизации.

2. Недостатком данной метрики является придание большей значимости ETT, нежели помехам соединения.

В качестве примера модификации метрики для компенсации её недостатков iAWARE можно привести работу [19].

Airtime Link Cost. Airtime Link Cost [20] - метрика времени передачи по беспроводному каналу - введена стандартом IEEE 802.11s и является обязательной для совместимости всех устройств в рамках данного стандарта. Она задается формулой:

C =

где O и Bt - константы, определенные стандартом для различных физических реализаций (802.11a, 802.11b): Bt - число битов в тестовом пакете (8192),

O - накладные расходы доступа к каналу, которые включают в себя заголовки пакетов, кадры протоколов доступа и т.д. (выраженные во времени); r - скорость передачи данных в канале (Мбит/с); ef - вероятность возникновения ошибки (измеряется экспериментально на пакетах длиной Bt). Эта метрика представляет собой оценку времени передачи (в секундах) пробного пакета длиной Bt с учетом возможных ретрансляций при потерях в канале.

133

Способ определения параметров r и ef в стандарте не приводится, однако можно предположить, что для этого должна использоваться периодическая рассылка пробных пакетов длиной Bt = 8192 бит.

В основе метода выбора пути для передачи данных в стандарте IEEE 802.11s лежит механизм профилей. Этот механизм обеспечивает совместимость устройств от разных производителей, которые могут поддерживать как стандартизованные механизмы, так и собственные. Профиль - это запись вида ^Идентификатор профиля> <Идентификатор протокола маршрутизации> ^Идентификатор метрики протокола маршрутизации>. Устройство может поддерживать несколько профилей работы, но единовременно лишь один из них может быть активным. Обязательный для реализации профиль использует протокол HWMP и метрику времени передачи Airtime Link Metric.

В работе [21] предлагается использовать метрику, основанную на Airtime Link Cost и названную Load-aware Airtime Link Cost metric. Данная метрика призвана регулировать трафик в зависимости от нагрузки узлов. Функция балансировки нагрузки в предлагаемой метрике называется TL (traffic load) определяется на основе средней длины очереди узла и числа соседних узлов, разделяющих один канал. Нагрузка для каждого интерфейса узла вычисляется следующим образом:

Qx х N

TL = Саг х -

где Са -значение метрики airtime link cost для конкретного узла и соединения 1;

Qx - средняя длина очереди, которая представляет собой среднее число битов в очереди, измеренных на х - интерфейсе узла;

r - это скорость передачи данных в Мбит/с, такая же как в airtime link cost. Для получения фактического времени передачи данных используется деление на r . Для представления концентрации трафика каждого узла используется число N , представляющее собой количество узлов, разделяющих один канал. Например, если большее количество соседних узлов выберет 1 в качестве следующего хопа для передачи пакета, трафик узла увеличивается и соответственно такой узел имеет более высокую вероятность оказаться перегруженным. В итоге, предлагаемая авторами [21] метрика рассчитывается следующим образом:

Metric = (1 -а) х ^ Са + а х max (TLj),

i=1

i<j<k

где TLj - расчетное значение нагрузки на узел j. Предполагается, что максимальное значение нагрузки трафика находится на маршруте, поскольку на маршруте может встретиться узел с повышенной нагрузкой, который будет являться т.н. «узким» местом. В итоге, общая пропускная способность маршрута будет определяться перегруженным узлом или соединением, которые имеет наибольшее значение TL ;

k - количество хопов маршрута; а - это настраиваемый параметр, 0 < а < 1.

r

134

Предложенная метрика встроена в протокол маршрутизации RHMR для обеспечения балансировки нагрузки в тактических мобильных одноранговых сетях.

Следует отметить, что существует множество модификаций [22] представленных, а также других метрик, обсуждение которых выходит за рамки данной работы.

Заключение

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

Литература

1. NetConfig - Сетевые технологии. Маршрутизатор. - Режим доступа: http://www.netconfig.ru/server/router/

2. MANET. Материал из Википедии - свободной энциклопедии. - Режим доступа: https://ru.wikipedia.org/wiki/MANET

3. The Internet Engineering Task Force. - Режим доступа: http://www.ietf.org

4. Perkins, C. Ad Hoc On-demand Distance Vector Routing Version 2 (AODVv2) Internet-Draft. - Режим доступа: https://tools.ietf.org/html/draft-ietf-manet-aodvv2-12

5. Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks

6. Сетевая модель OSI. Материал из Википедии - свободной энциклопедии.

- Режим доступа:

https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0

%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI

7. RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks PROPOSED STANDARD (RFC6550). - Режим доступа: http://tools.ietf.org/html/rfc6550

135

8. The Internet Assigned Numbers Authority

9. Manikandan, S. Power Saving Improved Position Changes Based Routing Protocol Using Backtracking For Mobile Ad Hoc Networks / S. Manikandan, Joseph Raymond. V // IJEDR - 2014. - Vol. 2, Issue 1. - С.821-827.

10. VenkatMohan, S. ETX Based Routing Metrics / S. VenkatMohan., Dr. N. Kasivis-wanath // (IJCSIT) International Journal of Computer Science and Information Technologies. - 2011. - Vol. 2(4). - С.1537-1548.

11. Liang, M. A routing metric for load-balancing in wireless mesh networks / M. Liang, M.K. Denko // Proceedings of the 21st International Conference on Advanced Information Networking and Applications Workshops/Symposia (AINAW '07). - 2007. - Vol. 2. -С.409-414.

12. Draves, R. Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks / Richard Draves, Jitendra Padhye and Brian Zill // ACM Mobicom. - 2004. -Режим доступа: http://www.cs.jhu.edu/~cs647/class-papers/Routing/p114-

draves.pdf

13. Panicker, A.S. Survey on Various Load Balancing Techniques in Wireless Mesh Networks / Anjaly Sara Panicker, Seetha S, Sharmila J. // International Journal of Advanced Research in Electronics and Communication Engineering (IJARECE).

- 2013. - Vol. 2, Issue 3. - С.341-344.

14. Yang, Y. Designing Routing Metrics for Mesh Networks / Yaling Yang, Jun Wang and Robin Kravets // IEEE INFOCOM - The 27th Conference on Computer Communications, IEEE. - 2008. - C.1615-1623.

15. A load dependent metric for balancing Internet traffic in Wireless Mesh Networks. Aiache, H. etc. Proc. IEEE MeshTech. - 2008. - C.629-634.

16. Optimizing Routing Metrics for Large-Scale Multi-Radio Mesh Networks. Jiang, W., etc. Wireless Communications, Networking and Mobile Computing. - 2007.

- C.1550-1553.

17. LanTienNguyen. An interference and load aware routing metric for Wireless Mesh Networks / LanTienNguyen, RazvanBeuran, YoichiShinoda. Int. J. // Ad Hoc and Ubiquitous Computing. - 2011. - Vol.7, No. 1. - C.25-37.

18. Interference Aware Routing in Multi-Radio Wireless Mesh Networks A.P. Subramanian, etc. IEEE Workshop Wireless Mesh Networks (WiMesh 2006). -C.55-63.

19. Siraj, M. A load balancing interference aware routing metric (LBIARM) for multi hop wireless mesh network / Mohammad Siraj, Kamalrulnizam Abu Bakar //International Journal of the Physical Sciences. - 2012. - Vol.7(3). - C.456- 461.

20. Маршрутизация в широкополосных беспроводных mesh-сетях стандарта IEEE 802.11s /В.М. Вишневский // Журнал Электроника НТБ. - 2008. - № 6. - С.64-69.

21. Choi, J. Multi-path Routing with Load-aware Metric for Tactical Ad Hoc Networks / J.Y. Choi, Y.B. Ko // International Conference on Information and Communication Technology Convergence (ICTC). - 2010.

22. Routing Metrics. - Режим доступа: http://ilab.cs.byu.edu/wiki/Routing_Metrics

Сведения об авторе

Датьев Игорь Олегович - к.т.н., научный сотрудник, е-mail: datyev@iimm.ru

Igor O. Datyev - Ph.D. (Tech. Sci.), researcher

136