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

Рисунок 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. Узел получая такой пакет, если его собственный уровень не установлен, ставит уровень на единицу больше, запоминает как свой уровень и передает пакет дальше. Аналогично остальные узлы. Таким образом вокруг шлюза формируются «кольца уровней» как показано на рисунке

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

Рисунок 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 Информация о полученных пакетах для всех узлов