Чем Castalia не является это ориентированной на конкретную платформу. Castalia обеспечивает общий надежный и реалистичный способ проверки алгоритма прежде чем перейти к реализации на конкретной платформе.

Castalia использует OMNeT++ в качестве своей базы поэтому предполагается, что у вас есть четкое понимание основных понятий OMNeT хотя это и не требуется, особенно если вы хотите использовать Castalia без создания собственных протоколов / приложений

OMNeT основан на понятиях модулей и сообщений. Простой модуль является основной единицей исполнения. Он принимает сообщения от других модулей или непосредственно, и в соответствии с сообщением, он выполняет часть кода. Этот код может хранить состояние, которое изменяется при приеме сообщений и может отправить новые сообщения. Есть также составные модули. Составной модуль просто способ построения простых и / или других композитных модулей

Размещено на http://www.allbest.ru/

Рисунок 9 Структура модулей в Castalia

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

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

Размещено на http://www.allbest.ru/

Рисунок 10 Структура модуля узла

Описание модулей осуществляется с использованием языка OMNeT++ NED. С помощью этого языка мы можем легко определить модули, т. е. определить имя модуля, параметры модуля и модуля интерфейса и возможную структуру подмодуля (если это композитный модуль). Сам код модуля пишется на языке C++.

4. Анализ работоспособности беспроводных сенсорных сетей

В данной главе описываются модели надежности для беспроводной сенсорной сети. Проводится исследование в системе Castalia.

4.1 Модель надежности беспроводной сенсорной сети

Наибольшее распространение в последнее время получили беспроводные сенсорные сети, параметры которых регламентируются стандартом IEEE 802.15.4 [11]. Далее будем вести речь именно о таких сетях.

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

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

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

4.1.1 Модель надежности передачи пакета данных между двумя узлами

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

Здесь и далее предполагается, что отправка пакетов -ым узлом в процессе работы сети образует простейший поток событий с интенсивностью , а прием пакетов этим же узлом - простейший поток с интенсивностью , где - множество узлов, которые могут передать пакет в адрес -го узла; - множество узлов, которым может быть передан пакет от -го узла (см. Рис. 11)

Рисунок 11 Потоки событий на i -ом узле сети

Величиной на Рис. 11 обозначена интенсивность потока событий, соответствующих безуспешным попыткам передачи пакета -ым узлом. Эту величину можно определить следующим образом[21]:

где - математическое ожидание количества попыток передачи пакета от -го узла -му, необходимое для успешного его приема:

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

Таким образом, можно записать:

Алгоритм расчета вероятности основан на одном из возможных принципов работы механизма маршрутизации в беспроводных сенсорных сетях [16]. Пусть на каждом -ом узле имеется ограниченная таблица маршрутизации (определяющая множество соседних с -ым узлов, которым им может быть передан пакет данных). Записи в этой таблице ранжированы по предпочтительности использования каждого направления при передаче пакета. Для каждого нового пакета, поступающего на -ый узел и нуждающегося в дальнейшей ретрансляции, делается максимум попыток его передачи -му узлу из множества , указанному первым в таблице маршрутизации -го. Если все попытки оказались неудачными, то из множества выбирается узел, соответствующий следующей записи в таблице маршрутизации, и -ый узел пытается передать пакет ему, и т.д. Пакет, который до поступления на -ый узел следующего пакета не удалось передать ни одному из узлов, указанных в таблице, удаляется из системы (теряется).

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

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

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

- максимальное количество неудачных попыток передачи пакета одному узлу; - вероятность передачи пакета с -ой попытки:

где - вероятность передачи пакета с первой попытки:

где - вероятность работоспособности (надежность) -го узла беспроводной сенсорной сети; - надежность коммуникации между узлами, определяемая параметрами радиоканала; - вероятность коллизии, обусловленной эффектом «скрытого узла»[29].

- вероятность того, что узел сможет осуществить попыток передачи пакета за время . Эта вероятность определяется механизмом конкурентного доступа к среде, используемым в беспроводных сенсорных сетях и регламентированным стандартом IEEE 802.15.4 [11].

Очевидно, что успешная передача пакета может быть осуществлена только при выполнении условия[23]:

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

- время, затрачиваемое узлом непосредственно на процесс передачи (приема) пакета фиксированной длинны байт, , где - скорость передачи данных, байт/сек;

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

где - среднее значение времени, которое может быть затрачено -ым узлом на передачу одного из пакетов ретранслируемого им потока:

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

Таким образом, выражение для определения вероятности можно записать в виде:

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

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

4.1.2 Модель надежности узла

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

Запишем выражение для определения вероятности работоспособности -го узла на заданный момент времени в виде[16]:

где - вероятность случайных отказов -го узла, закон распределения которых можно в первом приближении принять экспоненциальным [21]:

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

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

где - среднее время непрерывной работы узла до разряда батареи при приеме/передаче данных с максимально возможной плотностью, - время трансляции пакета;

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

Будем полагать, что по истечении времени . с момента замены батареи узел теряет работоспособность с вероятностью 1. Замена разряженных батарей узлов осуществляется с периодичностью (одновременно для всех узлов)[16]. Таким образом, для величины можно записать:

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

4.1.3 Модель надежности коммуникации между узлами

В связи с особенностями эксплуатации беспроводных сенсорных сетей имеют место потери пакетов из-за наличия шумов, вызванных как другими устройствами в конкурирующем диапазоне, так и наличием собственных эхо-сигналов. Вероятность успешной передачи сообщения длиной байт от -го узла -му можно определить из соотношения: , где - вероятность безошибочного приема символа данных. Зависимость от вероятности битовой ошибки может быть получена путем интерполирования расчетных значений для диапазона частот в 2.45 ГГц[16], где используется избыточное кодирование в соответствии со стандартом IEEE 802.15.4 [11]:

где - вероятность битовой ошибки, которая может быть определена из следующего соотношения:

где - энергия бита трансляции, равна произведению мощности на приемной антенне -го узла и продолжительности трансляции бита , что определяется скоростью передачи данных [16];

- спектральная плотность шумов (ее положительная часть) на приемной антенне -го узла, складывается не только из собственных тепловых шумов приемника и шумов других источников излучения (BlueTooth, Wi-Fi, GSM и др.), но еще и суммы эхо-сигналов[27];

- гауссов интеграл ошибок:

Отношение можно представить как: , где - амплитуда принимаемого сигнала, - амплитуда шума, - ширина частотной полосы, - скорость передачи данных. При =5Мгц и =250кб/с [16].

Амплитуда принимаемого сигнала определяется из следующего соотношения: , где - сопротивление антенны (50 Ом)[24].

Так как сигнал, с которым синхронизируется узел - это, как правило, прямой (наиболее мощный) сигнал для условия прямой видимости и квази-сферичности диаграммы направленности антенны, его мощность можно определить из известного соотношения[16]:

где , - мощности принимаемого и излучаемого сигнала соответственно, -расстояние между узлами, - длина волны ( 0,125m ? ), - коэффициент усиления канала связи ( 0.8 ? ).

Амплитуда шума является случайной величиной, и может быть описана распределением Рэлея [29], плотность распределения которого имеет вид:

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

4.2 Исследование надежности передачи пакета данных между двумя узлами в системе Castalia

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

Для простоты рассмотрения надежности передачи пакета между двумя узлами будем рассматривать беспроводную сенсорную сеть из девяти узлов (рисунок 12). Будем считать, что узлы расположены в пространстве на одной плоскости в области размера 30м. на 30м. Расположены по сетке.

Размещено на http://www.allbest.ru/

Рисунок 12 Схема простой сети из девяти узлов

Для задания параметров моделирования в системе Castalia используются конфигурационные файлы[3] (обычно такой файл принято называть omnetpp.ini), располагаться такой файл должен в папке данного моделирования (у нас interNodes), которая в свою очередь должна находиться в папке Simulations системы Castalia. Полный текст приведён в приложении А.

Для задания данной пространственной конфигурации используются параметры: SN.field_x = 30, SN.field_y = 30, SN.numNodes = 9, SN.deployment = "3x3"

Время моделирования задаем в 100с. (параметр sim-time-limit = 100s), стоит отметить, что моделирование в системе Castalia происходит не в реальном времени, то есть реальное время проведения эксперимента будет не 100с.

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

Для моделирования надежности передачи пакета данных между двумя узлами разработан модуль приложения InterNodes, представленный файлами interNodes.ned, interNodes.h, interNodes.cc. Исходный код приведён в приложении А.

Каждый узел с интервалом 100мс. (в приложении заведен соответствующий таймер) отправляет сообщение на щироковещательный адрес (равномерный поток сообщений образуется), всего отправляет 100 таких сообщений.

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

Размещено на http://www.allbest.ru/

newRec.timesRx = 1;

Рисунок 13 Структура таблицы соседей

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

В настройках моделирования указываем приложение (параметр SN.node[*].ApplicationName = "interNodes")

Отметим, что для идеализации коммуникационной среды между узлами мы отключим параметры, отвечающие за помехи канала (параметр SN.wirelessChannel.sigma = 0).

Система Castalia позволяет в файле с параметрами моделирования задавать различные конфигурации (различаться будут значениями параметров). Каждая конфигурация задается секцией, которые разделяются именем секции в квадратных скобках. Конфигурация General (задается [General]) является обязательной.

Для запуска моделирования используется команда Castalia. На рисунке 14 представлен запуск моделирования с конфигурацией General и выводом в файл res.txt. Как видно, моделирование не заняло много времени.



Рисунок 14 Запуск моделирования в системе Castalia

Для обработки данных полученных в процессе моделирования в системе Castalia используется команда CastaliaResults. На рисунке 15 выводится общая информация о собранных в ходе моделирования данных, сохраненных в файле res.txt. Каждый модуль системы может собирать различные данные. Например, в нашем модуле Application мы собирали данные о полученных пакетах от соседей и записывали как Packets received, что и отражено здесь. Величина Dimensions характеризует сколько узлов и данные какой размерности писали.

На рисунке 16 показано, что в среднем каждый узел получил 88 пакетов. Таким образом видно, что в идеальных условиях коммуникационной среды не все пакеты были получены, то есть можем говорить о надежности связи между узлами с определенной вероятностью.

Рисунок 15 Вывод общих сведений о результатах моделирования в системе Castalia

Рисунок 16 Среднее число пакетов полученных каждым узлом

Рисунок 17 Число пакетов полученных каждым узлом

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

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

Проведя наше моделирование сто раз, на рисунке 18 видно, что в целом полученные данные практически идентичны тем, что получены без многократного повторения. Поэтому подробнее рассмотрим первые.

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

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

Рисунок 18 Количество пакетов полученных узлами при стократном повторении моделирования

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

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

Размещено на http://www.allbest.ru/

Рисунок 19 Вероятности доставки сообщении между узлами

4.2.1 Влияние помех на надежность коммуникационной среды между двумя узлами в системе Castalia

Рассмотрим теперь случай, когда присутствуют помехи.

Помехой называется стороннее возмущение, действующее в системе передачи и препятствующее правильному приёму сигналов[24,29].

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

Величина помех в системе Castalia задается параметром SN.wirelessChannel.sigma, а сама величина помех рассчитывается по формуле[3]:

Где, потери передачи на расстояние , является известным значением потери на начальном расстоянии , -показатель потерь, и является случайной величиной со стандартным отклонением . Именно с помощью нее в системе можно менять величину помех.

Для рассмотрения влияния помех мы определили в настройках моделирования конфигурацию varySigma, при которой будет запущено моделирование (рисунок 20) с вариацией этого параметра (SN.wirelessChannel.sigma = ${Sigma=0,1,3,5})

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

Рисунок 20 Моделирование с вариациями уровня помех

Рисунок 21 Количество пакетов, полученных при разном уровне помех

Для визуализации полученных данных в системе Castalia есть команда CastaliaPlot, которая позволяет строить различные визуальные представления (графики, диаграммы и т. д.) из данных, что были получены командой CastaliaResults[3].

Рисунок 22 Влияние помех на число полученных пакетов

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

На рисунке 22 представлена диаграмма, иллюстрирующая сколько пакетов получил пятый узел от остальных. Где Sigma - параметр, отвечающий за уровень помех; node - узлы, пронумерованные от 0 до 8 и обозначенные разными цветами; число на оси ординат соответствует общему числу полученных сообщений пятым узлом, каждый цветной сегмент показывает сколько пакетов получено от соответствующего цвету узла. Видно, что при отсутствии помех было получено около семисот пакетов. С возрастанием величины помех начиная с 3 видно, что число полученных пакетов не падает значительно, то есть можем говорить, что надёжность здесь уже не зависит от уровня помех, что может быть обусловлено хорошим протоколом канального уровня.

4.2.2 Влияния мощности радио-модуля на надежность коммуникационной среды между двумя узлами в системе Castalia

Рассмотрим влияние мощности радио-модуля при передаче сообщений.

Для рассмотрения влияния мощности радио-модуля мы определили в настройках моделирования конфигурацию varyTxPower, при которой будет запущено моделирование с вариацией этого параметра (SN.node[*].Communication.Radio.TxOutputPower = ${TXpower="0dBm","-1dBm","-3dBm","-5dBm"})

На рисунке 23 представлена диаграмма, иллюстрирующая сколько пакетов получил пятый узел от остальных. Где TXpower - параметр, отвечающий за уровень мощности радио-модуля; node - узлы, пронумерованные от 0 до 8 и обозначенные разными цветами; число на оси ординат соответствует общему числу полученных сообщений пятым узлом, каждый цветной сегмент показывает сколько пакетов получено от соответствующего цвету узла. Видно, что при уровне мощности в -5dBm было получено около семисот пакетов. С возрастанием величины мощности начиная с -3dBm видно, что число полученных пакетов возросло до восьмисот и стабильно, то есть можем говорить, что надёжность здесь уже не зависит от уровня мощности радио-модуля.

Рисунок 23 Влияние уровня мощности радио-модуля на число полученных пакетов

4.3 Исследование надежности сбора информации сетью в системе Castalia

Для простоты рассмотрения надежности сбора информации сетью будем рассматривать беспроводную сенсорную сеть из 36 узлов (рисунок 24). Будем считать, что узлы расположены в пространстве на одной плоскости в области размера 100м. на 100м. Расположены по сетке.

Размещено на http://www.allbest.ru/

Рисунок 24 Схема простой сети из 36 узлов

Для задания параметров моделирования в системе Castalia используются конфигурационные файлы[3] (обычно такой файл принято называть omnetpp.ini), располагаться такой файл должен в папке данного моделирования (у нас reliabilityFullNet), которая в свою очередь должна находиться в папке Simulations системы Castalia. Полный текст приведён в приложении Б.

Для задания данной пространственной конфигурации используются параметры: SN.field_x = 100, SN.field_y = 100, SN.numNodes = 36, SN.deployment = "6x6"

Время моделирования задаем в 600с. (параметр sim-time-limit = 600s), стоит отметить, что моделирование в системе Castalia происходит не в реальном времени, то есть реальное время проведения эксперимента будет не 600с.

Говоря о сборе данных беспроводной сенсорной сетью, мы подразумеваем, что один из узлов сети является шлюзом между БСС и внешними системами, куда попадают собранные данные. Пусть шлюзом будет четвёртый узел (параметр SN.node[3].Application.isSink = true).

Для того чтобы собирать данные нам необходима модель функционирования узла, для этого был разработан модуль приложения DataToSink, представленный файлами DataToSink.ned, DataToSink.h, DataToSink.cc. Исходный код приведён в приложении Б.

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

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

В настройках моделирования указываем приложение (параметр SN.node[*].ApplicationName = " DataToSink ")

Для того, чтобы информация от узлов шла к шлюзу был разработан модуль простой маршрутизации MultipathRingsRouting, представленный файлами MultipathRingsRouting.ned, MultipathRingsRouting.h, MultipathRingsRouting.cc. Исходный код приведён в приложении Б.

Структура пакета для маршрутизации представлена на рисунке 25. Здесь Source - адрес отправителя; Destination - адрес получателя; Level - уровень маршрутизации, с которого отправлен пакет; Data - полезная информация для уровня приложения; Type - тип пакета.

Алгоритм состоит из двух фаз, которые разделяются типом пакета.

Первая фаза. Установление уровней. Для этого шлюз шлет в канал пакет с типом MPRINGS_TOPOLOGY_SETUP_PACKET. Узел получая такой пакет, если его собственный уровень не установлен, ставит уровень на единицу больше, запоминает как свой уровень и передает пакет дальше. Аналогично остальные узлы. Таким образом вокруг шлюза формируются «кольца уровней» как показано на рисунке

Размещено на http://www.allbest.ru/

Рисунок 25 Структура пакета для маршрутизации

Размещено на http://www.allbest.ru/

Рисунок 26 «Круговые» уровни вокруг шлюза

Запустим моделирование (рисунок 26).

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

В настройках моделирования указываем протокол маршрутизации (параметр SN.node[*].Communication.RoutingProtocolName = "MultipathRingsRouting")

Как говорилось в 4.1, надежность БСС определяется надежностью обмена пакетами между узлами. Здесь под надежностью сбора информации сетью мы будем понимать надежность получения пакетов шлюзом и рассматриваем вероятность получения пакетов.

Используя ранее рассмотренный аппарат и запустив моделирование c конфигурацией General, получили данные, на основе которых построен график на рисунке 27. Здесь видна информация, по доставке пакетов к четвертому узлу (шлюзу). По оси абсцисс состояния доставки, а по оси ординат их вероятности. Видно, что состояния Failed превалируют, а Received составляют примерно около 0,3. На первый взгляд это может показаться плохим результатом, однако же в силу специфики собираемой информации и других факторов, таких как долгая автономная работа сети, вполне приемлемо.

Рисунок 27 Количество пакетов, полученных шлюзом

На рисунке 28 отображена информация о вероятностях доставки сообщений для всех узлов сети. По оси абсцисс номера узлов, по оси ординат вероятности, а цветами обозначены состояния пакетов. Отсюда видно, что наибольшая надежность доставки пакетов 0,5 обнаруживается для узла 27. Что может послужить предпосылкой использовать в качестве шлюза именно такие узлы.

Рисунок 28 Информация о полученных пакетах для всех узлов

4.3.1 Влияние помех на надежность сбора информации сетью в системе Castalia

Для рассмотрения влияния помех мы определили в настройках моделирования конфигурацию varySigma, при которой будет запущено моделирование с вариацией этого параметра (SN.wirelessChannel.sigma = ${Sigma=0,1,3,5})

На рисунках 29-32 показано как меняется надежность доставки пакетов в зависимости от уровня помех. По оси абсцисс номера узлов, по оси ординат вероятности, а цветами обозначены состояния пакетов. Видна тенденция, что с возрастанием уровня помех возрастает вероятность доставки пакетов. Это может быть обусловлено хорошими алгоритмами канального уровня.

Рисунок 29 Количество пакетов при Sigma 0

Рисунок 30 Количество пакетов при Sigma 1



Рисунок 31 Количество пакетов при Sigma 3

Рисунок 32 Количество пакетов при Sigma 5

Заключение

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

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

Полученные результаты в целом соответствуют результатам других исследователей. [16].

В процессе работы были подготовлены и приняты в печать тезисы доклада «Исследование энергоэффективности алгоритмов маршрутизации в беспроводных сенсорных сетях» на объединенную научную конференцию студентов и аспирантов факультета компьютерных технологий и прикладной математики «Прикладная математика XXI века», проходившую в Краснодаре, 9-12 апреля 2013 г.

Библиографический список

1. Castalia Installation Guide URL: http://castalia.research.nicta.com.au/pdfs/Castalia%20-%20Installation.pdf

2. Castalia official site URL: http://castalia.research.nicta.com.au/

3. Castalia User's manual URL:http://castalia.research.nicta.com.au/pdfs/Castalia%20-%20User%20Manual.pdf

4. Chandra T.D., Toueg S. Unreliable failure detectors for reliable distributed systems. // J. ACM. 1996. V. 43. P. 225-267.

5. Delporte-Gallet C., Devismes S., Fauconnier H. Stabilizing leader election in partial synchronous systems with crash failures. // J. Parallel Distrib. Comput. - 2010. - 70. - P. 45 - 58.

6. E. Egea-Lуpez, J. Vales-Alonso, A. S. Martнnez-Sala, P. Pavуn-Mariсo, J. Garcнa-Haro Simulation Tools for Wireless Sensor Networks // Summer Simulation Multiconference - SPECTS 2005 // - 2005. - P. 2 - 9.

7. Ezio Biglieri Coding for Wireless Channels (Information Technology: Transmission, Processing and Storage) -2005. - P. 428.

8. Fei Yu A Survey of Wireless Sensor Network Simulation Tools URL: http://www1.cse.wustl.edu/~jain/cse567-11/ftp/sensor/index.html

9. Fischer M.J., Lynch N.A., Paterson M.S. Impossibility of distributed consensus with one faulty process. // J. ACM. 1985. V 32. P. 374-382.

10. Garay J.A., Perry K.J. A continuum of failure models for distributed computing. // Proc. 6nd Int. Workshop on Distributed Algorithms (Haifa, 1992) / S. Zaks, A. Segall (eds.). P. 153-156.

11. IEEE Standards 802.15.4. Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs). -- IEEE Computer Society, 2003.

12. Luis Javier Garcнa Villalba , Ana Lucila Sandoval Orozco, Alicia Triviсo Cabrera, Clбudia Jacy Barenco Abbas Routing Protocols in Wireless Sensor Networks // Sensors // - 2009 - 9 - P. 399 - 421.

13. Pease M., Shostak R., Lamport L. Reaching agreement in the presence of faults. // J. ACM. 1984. V. 27. P. 228-234.

14. Roya N., Gub T., Das S.K. Supporting pervasive computing applications with active context fusion and semantic context delivery. // Pervasive and Mobile Computing - 2010. - 6. - P. 21 - 42.

15. Zhang M., Chan M.C., Ananda A.L. Connectivity monitoring in wireless sensor networks. // Pervasive and Mobile Computing - 2010. - 6. - P. 112 - 127.

16. Акимов Е.В., Кузнецов М.Н. Вероятностные математические модели для оценки надежности беспроводных сенсорных сетей // Электронный журнал «Труды МАИ». Выпуск № 40// URL: http://www.mai.ru/science/trudy/

17. Ахо А., Хопкрофт Д., Ульман Д. Структуры данных и алгоритмы. - М.: Вильямс, 2000. -- 384 с.

18. Гейер Дж. Беспроводные сети. Первый шаг. / Пер. с англ. - М.: Вильямc, 2005. - 192 с.

19. Дейтел Х., Дейтел П. Как программировать на С++. - М.: Бином-Пресс, 2008. - 1446 с.

20. Нечаев Д.Ю., Чекмарев Ю.В. Надежность информационных систем. - М.: ДМК Пресс, 2012. - 64 с.

21. Острейковский В.А. Теория надежности. - М.: Высшая школа, 2000. - 464 с.

22. Острейковский В.А. Теория надежности. Учебник для вузов. - М.: Высшая школа, 2003. - 457 с.

23. Половко А.М., Гуров С. В. Основы теории надежности. - СПб.: БХВ-Петербург 2006. - 560 с.

24. Смелянский Р. Л. Компьютерные сети. В 2 томах. Том 1. Системы передачи данных. - М.: Академия, 2011. - 304 с.

25. Страуструп Б. Язык программирования С++. - М.: Бином, 2008. - 1104 с.

26. Тель Ж. Введение в распределенные алгоритмы. Пер. с англ. В. А. Захарова. - М.: МЦНМО, 2009. - 616 с.

27. Ушаков И.А. Вероятностные модели надежности информационно-вычислительных систем. - М.: Радио и связь 1991. - 132 с.

28. Хьюз К., Хьюз Т. Параллельное и распределенное программирование на С++. Пер. с англ. - М.: Издательский дом Вильямс, 2004. - 672 с.

29. Шахнович И.А. Современные технологии беспроводной связи. - М.: Техносфера, 2006. - 288 с.

30. Шубин В.И., Красильникова О. С. Беспроводные сети передачи данных. - М.: Вузовская книга, 2012. - 104 с.

31. Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования. Пер. с англ. - М.: Издательский дом Вильямс, 2003. - 512 с.

Приложение А

Текст файла omnetpp.ini.

[General]

include ../Parameters/Castalia.ini

sim-time-limit = 100s

SN.field_x = 30 # meters

SN.field_y = 30 # meters

SN.numNodes = 9

SN.deployment = "3x3"

# Removing variability from wireless channel

SN.wirelessChannel.bidirectionalSigma = 0

SN.wirelessChannel.sigma = 0

# Select a Radio and a default Tx power

SN.node[*].Communication.Radio.RadioParametersFile = "../Parameters/Radio/CC2420.txt"

SN.node[*].Communication.Radio.TxOutputPower = "-5dBm"

SN.node[*].ApplicationName = "interNodes"

[Config varyTxPower]

SN.node[*].Communication.Radio.TxOutputPower = ${TXpower="0dBm","-1dBm","-3dBm","-5dBm"}

[Config varySigma]

SN.wirelessChannel.sigma = ${Sigma=0,1,3,5}

Текст файла interNodes.ned

simple interNodes like node.application.iApplication {

parameters:

string applicationID = default ("interNodes");

bool collectTraceInfo = default (false);

int packetHeaderOverhead = default (8);

int priority = default (1);

int constantDataPayload = default (8);

int packetSpacing = default (100); // ms

int packetsPerNode = default (100);

int packetSize = default (32); // bytes

gates:

output toCommunicationModule;

output toSensorDeviceManager;

input fromCommunicationModule;

input fromSensorDeviceManager;

input fromResourceManager;

}

Текст файла interNodes.h

#ifndef _INTERNODES_H_

#define _INTERNODES_H_

#include "VirtualApplication.h"

using namespace std;

struct neighborRecord {

int id;

int timesRx;

int receivedPackets;

};

enum interNodesTimers {

SEND_PACKET = 1,

};

class interNodes: public VirtualApplication {

private:

// parameters and variables

int priority;

int packetHeaderOverhead;

bool printConnMap;

int constantDataPayload;

double packetSpacing;

int packetsPerNode;

int packetSize;

vector<neighborRecord> neighborTable;

int packetsSent;

int serialNumber;

int totalSNnodes;

double txInterval_perNode;

double txInterval_total;

protected:

void startup();

void finishSpecific();

void fromNetworkLayer(ApplicationPacket *, const char *, double, double);

void timerFiredCallback(int);

void updateNeighborTable(int nodeID, int theSN);

};

#endif

Текст файла interNodes.cc

#include "interNodes.h"

Define_Module(interNodes);

void interNodes::startup()

{

packetSpacing = (double)par("packetSpacing") / 1000.0;

packetsPerNode = par("packetsPerNode");

packetSize = par("packetSize");

neighborTable.clear();

packetsSent = 0;

totalSNnodes = getParentModule()->getParentModule()->par("numNodes");

txInterval_perNode = packetsPerNode * packetSpacing;

txInterval_total = (txInterval_perNode * totalSNnodes);

if (strtod(ev.getConfig()->getConfigValue("sim-time-limit"), NULL) < txInterval_total) {

trace() << "ERROR: Total sim time should be at least = " << txInterval_total;

opp_error("\nError: simulation time not large enough for the conectivity map application\n");

}

double startTxTime = txInterval_perNode * self;

setTimer(SEND_PACKET, startTxTime);

}

void interNodes::fromNetworkLayer(ApplicationPacket * rcvPacket, const char *source, double rssi, double lqi)

{

updateNeighborTable(atoi(source), rcvPacket->getSequenceNumber());

}

void interNodes::timerFiredCallback(int timerIndex)

{

switch (timerIndex) {

case SEND_PACKET:{

if (packetsSent >= packetsPerNode)

break;

toNetworkLayer(createGenericDataPacket(0.0, packetsSent, packetSize), BROADCAST_NETWORK_ADDRESS);

packetsSent++;

setTimer(SEND_PACKET, packetSpacing);

break;

}

}

}

void interNodes::finishSpecific()

{

declareOutput("Packets received");

for (int i = 0; i < (int)neighborTable.size(); i++) {

collectOutput("Packets received", neighborTable[i].id,

"Success", neighborTable[i].receivedPackets);

}

}

void interNodes::updateNeighborTable(int nodeID, int serialNum)

{

int i = 0, pos = -1;

int tblSize = (int)neighborTable.size();

for (i = 0; i < tblSize; i++)

if (neighborTable[i].id == nodeID)

pos = i;

if (pos == -1) {

neighborRecord newRec;

newRec.id = nodeID;

newRec.timesRx = 1;

if ((serialNum >= 0) && (serialNum < packetsPerNode))

newRec.receivedPackets = 1;

neighborTable.push_back(newRec);

} else {

neighborTable[pos].timesRx++;

if ((serialNum >= 0) && (serialNum < packetsPerNode))

neighborTable[pos].receivedPackets++;

}

}

Приложение Б

Текст файла DataToSink.ned

package node.application.DataToSink;

simple DataToSink like node.application.iApplication {

parameters:

string applicationID = default ("DataToSink");

bool collectTraceInfo = default (true);

int priority = default (1);

int packetHeaderOverhead = default (8); // in bytes

int constantDataPayload = default (12); // in bytes

int maxSampleInterval = default (60000);// in msec

int minSampleInterval = default (1000); // in msec

bool isSink = default (false);

gates:

output toCommunicationModule;

output toSensorDeviceManager;

input fromCommunicationModule;

input fromSensorDeviceManager;

input fromResourceManager;

}

Текст файла DataToSink.h

#ifndef _DATATOSINK_H_

#define _DATATOSINK_H_

#include "VirtualApplication.h"

#include "Packet_m.h"

using namespace std;

enum DataToSinkTimers {

REQUEST_SAMPLE = 1,

SEND_DATA = 2,

};

class DataToSink: public VirtualApplication {

private:

double maxSampleInterval;

double minSampleInterval;

int routingLevel;

double lastSensedValue;

int currSentSampleSN;

double randomBackoffIntervalFraction;

bool sentOnce;

protected:

void startup();

void fromNetworkLayer(ApplicationPacket *, const char *, double, double);

void handleSensorReading(SensorReadingMessage *);

void timerFiredCallback(int);

};

#endif

Текст файла DataToSink.cc

#include "DataToSink.h"

Define_Module(DataToSink);

void DataToSink::startup()

{

maxSampleInterval = ((double)par("maxSampleInterval")) / 1000.0;

minSampleInterval = ((double)par("minSampleInterval")) / 1000.0;

currSentSampleSN = 0;

randomBackoffIntervalFraction = genk_dblrand(0);

sentOnce = false;

setTimer(REQUEST_SAMPLE, maxSampleInterval * randomBackoffIntervalFraction);

}

void DataToSink::timerFiredCallback(int index)

{

switch (index) {

case REQUEST_SAMPLE:{

requestSensorReading();

setTimer(REQUEST_SAMPLE, maxSampleInterval);

break;

}

}

}

void DataToSink::fromNetworkLayer(ApplicationPacket * genericPacket,

const char *source, double rssi, double lqi)

{

DataToSinkDataPacket *rcvPacket = check_and_cast<DataToSinkDataPacket*>(genericPacket);

ValueReportData theData = rcvPacket->getExtraData();

if (isSink)

trace() << "Sink received from: " << theData.nodeID << " \tvalue=" << rcvPacket->getData();

}

void DataToSink::handleSensorReading(SensorReadingMessage * rcvReading)

{

// int sensIndex = rcvReading->getSensorIndex();

// string sensType(rcvReading->getSensorType());

double sensValue = rcvReading->getSensedValue();

// schedule the TX of the value

trace() << "Sensed = " << sensValue;

ValueReportData tmpData;

tmpData.nodeID = (unsigned short)self;

tmpData.locX = mobilityModule->getLocation().x;

tmpData.locY = mobilityModule->getLocation().y;

DataToSinkDataPacket *packet2Net =

new DataToSinkDataPacket("Value reporting pck", APPLICATION_PACKET);

packet2Net->setExtraData(tmpData);

packet2Net->setData(sensValue);

packet2Net->setSequenceNumber(currSentSampleSN);

currSentSampleSN++;

toNetworkLayer(packet2Net, SINK_NETWORK_ADDRESS);

sentOnce = true;

}

Текст файла MultipathRingsRouting.ned

package node.communication.routing.multipathRingsRouting;

simple MultipathRingsRouting like node.communication.routing.iRouting {

parameters:

bool collectTraceInfo = default (false);

int maxNetFrameSize = default (0); // bytes, 0 means no limit

int netBufferSize = default (32); // number of messages

int netDataFrameOverhead = default (14); // bytes

int mpathRingsSetupFrameOverhead = default (13); // bytes

int netSetupTimeout = default (50); // msec

gates:

output toCommunicationModule;

output toMacModule;

input fromCommunicationModule;

input fromMacModule;

input fromCommModuleResourceMgr;

}

Текст файла MultipathRingsRouting.h

#ifndef _MULTIPATHRINGSROUTING_H_

#define _MULTIPATHRINGSROUTING_H_

#include <map>

#include "VirtualRouting.h"

#include "MultipathRingsRoutingPacket_m.h"

#include "MultipathRingsRoutingControl_m.h"

#define NO_LEVEL -110

#define NO_SINK -120

using namespace std;

enum MultipathRingsRoutingTimers {

TOPOLOGY_SETUP_TIMEOUT = 1,

};

class MultipathRingsRouting: public VirtualRouting {

private:

int mpathRingsSetupFrameOverhead; // in bytes

double netSetupTimeout;

// multipathRingsRouting-related member variables

int currentSequenceNumber;

int currentSinkID;

int currentLevel;

int tmpSinkID;

int tmpLevel;

bool isSink; //is a .ned file parameter of the Application module

bool isConnected; //attached under a parent node

bool isScheduledNetSetupTimeout;

protected:

void startup();

void fromApplicationLayer(cPacket *, const char *);

void fromMacLayer(cPacket *, int, double, double);

void sendTopologySetupPacket();

void sendControlMessage(multipathRingsRoutingControlDef);

void timerFiredCallback(int);

void processBufferedPacket();

};

Текст файла MultipathRingsRouting.cc

#include "MultipathRingsRouting.h"

Define_Module(MultipathRingsRouting);

void MultipathRingsRouting::startup()

{

netSetupTimeout = (double)par("netSetupTimeout") / 1000.0;

mpathRingsSetupFrameOverhead = par("mpathRingsSetupFrameOverhead");

// check that the Application module used has the boolean parameter "isSink"

cModule *appModule = getParentModule()->getParentModule()->getSubmodule("Application");

if (appModule->hasPar("isSink"))

isSink = appModule->par("isSink");

else

opp_error("\nMultiPathRings routing has to be used with an application that defines the parameter isSink");

currentLevel = tmpLevel = isSink ? 0 : NO_LEVEL;

currentSinkID = tmpSinkID = isSink ? self : NO_SINK;

isConnected = (isSink) ? true : false;

isScheduledNetSetupTimeout = false;

currentSequenceNumber = 0;

if (isSink)

sendTopologySetupPacket();

}

void MultipathRingsRouting::sendTopologySetupPacket()

{

MultipathRingsRoutingPacket *setupPkt =

new MultipathRingsRoutingPacket("Multipath rings routing setup packet", NETWORK_LAYER_PACKET);

setupPkt->setMultipathRingsRoutingPacketKind(MPRINGS_TOPOLOGY_SETUP_PACKET);

setupPkt->setSource(SELF_NETWORK_ADDRESS);

setupPkt->setDestination(BROADCAST_NETWORK_ADDRESS);

setupPkt->setSinkID(currentSinkID);

setupPkt->setSenderLevel(currentLevel);

toMacLayer(setupPkt, BROADCAST_MAC_ADDRESS);

}

void MultipathRingsRouting::sendControlMessage(multipathRingsRoutingControlDef kind)

{

MultipathRingsRoutingControlMessage *ctrlMsg =

new MultipathRingsRoutingControlMessage("Multipath routing control message",NETWORK_CONTROL_MESSAGE);

ctrlMsg->setMultipathRingsRoutingControlMessageKind(kind);

ctrlMsg->setLevel(currentLevel);

ctrlMsg->setSinkID(currentSinkID);

toApplicationLayer(ctrlMsg);

}

void MultipathRingsRouting::timerFiredCallback(int index)

{

if (index != TOPOLOGY_SETUP_TIMEOUT)

return;

isScheduledNetSetupTimeout = false;

if (tmpLevel == NO_LEVEL) {

setTimer(TOPOLOGY_SETUP_TIMEOUT, netSetupTimeout);

isScheduledNetSetupTimeout = true;

} else if (currentLevel == NO_LEVEL) {

//Broadcast to all nodes of currentLevel-1

currentLevel = tmpLevel + 1;

currentSinkID = tmpSinkID;

if (!isConnected) {

isConnected = true;

sendControlMessage(MPRINGS_CONNECTED_TO_TREE);

trace() << "Connected to " << currentSinkID << " at level " << currentLevel;

if (!TXBuffer.empty())

processBufferedPacket();

} else {

sendControlMessage(MPRINGS_TREE_LEVEL_UPDATED);

trace() << "Reconnected to " << currentSinkID << " at level " << currentLevel;

}

sendTopologySetupPacket();

}

tmpLevel = isSink ? 0 : NO_LEVEL;

tmpSinkID = isSink ? self : NO_SINK;

}

void MultipathRingsRouting::processBufferedPacket()

{

while (!TXBuffer.empty()) {

toMacLayer(TXBuffer.front(), BROADCAST_MAC_ADDRESS);

TXBuffer.pop();

}

}

void MultipathRingsRouting::fromApplicationLayer(cPacket * pkt, const char *destination)

{

string dst(destination);

MultipathRingsRoutingPacket *netPacket =

new MultipathRingsRoutingPacket("Multipath rings routing data packet", NETWORK_LAYER_PACKET);

netPacket->setMultipathRingsRoutingPacketKind(MPRINGS_DATA_PACKET);

netPacket->setSource(SELF_NETWORK_ADDRESS);

netPacket->setDestination(destination);

netPacket->setSinkID(currentSinkID);

netPacket->setSenderLevel(currentLevel);

encapsulatePacket(netPacket, pkt);

if (dst.compare(SINK_NETWORK_ADDRESS) == 0 || dst.compare(PARENT_NETWORK_ADDRESS) == 0) {

netPacket->setSequenceNumber(currentSequenceNumber);

currentSequenceNumber++;

if (bufferPacket(netPacket)) {

if (isConnected)

processBufferedPacket();

else

sendControlMessage(MPRINGS_NOT_CONNECTED);

} else {

//Here we could send a control message to upper layer informing that our buffer is full

}

} else { //++++ need to control flooding

toMacLayer(netPacket, BROADCAST_MAC_ADDRESS);

}

}

void MultipathRingsRouting::fromMacLayer(cPacket * pkt, int macAddress, double rssi, double lqi)

{

MultipathRingsRoutingPacket *netPacket = dynamic_cast <MultipathRingsRoutingPacket*>(pkt);

if (!netPacket)

return;

switch (netPacket->getMultipathRingsRoutingPacketKind()) {

case MPRINGS_TOPOLOGY_SETUP_PACKET:{

if (isSink)

break;

if (!isScheduledNetSetupTimeout) {

isScheduledNetSetupTimeout = true;

setTimer(TOPOLOGY_SETUP_TIMEOUT, netSetupTimeout);

tmpLevel = NO_LEVEL;

tmpSinkID = NO_SINK;

}

if (tmpLevel == NO_LEVEL || tmpLevel > netPacket->getSenderLevel()) {

tmpLevel = netPacket->getSenderLevel();

tmpSinkID = netPacket->getSinkID();

}

break;

}

case MPRINGS_DATA_PACKET:{

string dst(netPacket->getDestination());

string src(netPacket->getSource());

int senderLevel = netPacket->getSenderLevel();

int sinkID = netPacket->getSinkID();

if (dst.compare(BROADCAST_NETWORK_ADDRESS) == 0 ||

dst.compare(SELF_NETWORK_ADDRESS) == 0) {

// We are not filtering packets that are sent to this node directly or to

// broadcast network address, making application layer responsible for them

toApplicationLayer(pkt->decapsulate());

} else if (dst.compare(SINK_NETWORK_ADDRESS) == 0) {

if (senderLevel == currentLevel + 1) {

if (self == sinkID) {

// Packet is for this node, if filter passes, forward it to application

if (isNotDuplicatePacket(pkt))

toApplicationLayer(decapsulatePacket(pkt));

else

trace() << "Discarding duplicate packet from node " << src;

} else if (sinkID == currentSinkID) {

// We want to rebroadcast this packet since we are not its destination

// For this, a copy of the packet is created and sender level field is

// updated before calling toMacLayer() function

MultipathRingsRoutingPacket *dupPacket = netPacket->dup();

dupPacket->setSenderLevel(currentLevel);

toMacLayer(dupPacket, BROADCAST_MAC_ADDRESS);

}

}

} else if (dst.compare(PARENT_NETWORK_ADDRESS) == 0) {

if (senderLevel == currentLevel + 1 && sinkID == currentSinkID) {

// Packet is for this node, if filter passes, forward it to application

if (isNotDuplicatePacket(pkt))

toApplicationLayer(decapsulatePacket(pkt));

else

trace() << "Discarding duplicate packet from node " << src;

}

}

break;

}

}

}

Текст файла omnetpp.ini.

[General]

include ../Parameters/Castalia.ini

sim-time-limit = 600s

SN.field_x = 100 # meters

SN.field_y = 100 # meters

SN.numNodes = 36

SN.deployment = "6x6"

SN.node[*].Communication.Radio.RadioParametersFile = "../Parameters/Radio/CC2420.txt"

SN.node[*].Communication.RoutingProtocolName = "MultipathRingsRouting"

SN.node[*].Communication.MACProtocolName = "TMAC"

SN.node[*].ApplicationName = "DataToSink"

SN.node[*].Communication.Routing.collectTraceInfo = true

SN.node[3].Application.isSink = true

[Config varyTxPower]

SN.node[*].Communication.Radio.TxOutputPower = ${TXpower="0dBm","-1dBm","-3dBm","-5dBm"}

[Config varySigma]

SN.wirelessChannel.sigma = ${Sigma=0,1,3,5}

Размещено на Allbest.ru