Пояснительная записка (1194880), страница 9

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 9)

Рисунок 16 – Результат сборки модулей симулятора NS3

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

Далее осуществляется запуск симуляции при помощи команды

«./waf --run scratch/vanet-routing-compare --vis»

В этой команде флаг «--run» даёт приложению понять, что выполняется запуск симуляции, а в качестве параметра принимается имя файла для запуска и параметры запуска, флаг «--vis» отвечает за вызов визуализатора. После выполнения сборки файла появится экран визуализатора (рисунок 17).

Рисунок 17 – Встроенный визуализатор NS3

После нажатия кнопки «Simulate» симуляция запустится, при этом она не завершится до закрытия окна визуализатора. В окне визуализатора также можно менять настройки представления коммуникации узлов, размер «нодов» и скорость симуляции.

1. Добавление протоколов маршрутизации

Непосредственно по завершению сборки доступны следующие протоколы: OLSR, AODV, DSDV, DSR, поэтому прежде чем приступить к дальнейшей работе необходимо интегрировать в симулятор требуемые протоколы. Протоколы, которые необходимо добавить уже имеют реализацию для симулятора NS3 и предложены сообществу для обзора на сайте codereview.com, откуда и следует их загрузить.

Протокол GPSR не вносит изменений в код других модулей для своей работы, поэтому достаточно сохранить его в каталоге, который содержит исходные коды всех модулей. Однако, протокол CLWPR вносит изменения в структуру других модулей, при этом этот протокол написан для более ранней версии NS3, в связи с чем возникает необходимость проверки изменений между файлами, имеющимися в текущей версии симулятора и рекомендуемыми файлами. В связи с этим потребуется выполнить команду «diff», чтобы выявить части кода стандартных модулей, которые необходимы для работы протокола. После внесения поправок в базовые модули NS3, можно сохранить реализацию CLWPR.

На следующем этапе осуществляется повторная компиляция симулятора, командами «./waf configure» и «./waf».

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

1. Подготовка карты сценария автомагистрали

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

$node_(L) set X_ XXX

$node_(L) set Y_ YYY

$node_(L) set Z_ ZZZ

$ns_ at T "$node_(L) setdest XXX YYY SSS",

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

Для задания движения узла используется следующая команда:

$ns_ at T "$node_(L) setdest XXX YYY SSS".

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

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

Далее выполнить задание базовых переменных. Это точки для начала магистрали по осям X и Y. После этого необходимо вычислить шаг по оси X как отношение длины участка к количеству узлов. Шаг по оси Y, отвечает за ширину полос магистрали и принимается равным небольшой величине, в данном случае 20.

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

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

Также необходимо определить длительность поворота по формуле:

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

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

Теперь можно перейти непосредственно к написанию приложения. Код представлен в приложении А.

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

Рисунок 18 – Сценарий автомагистрали в NS3

1. Подготовка карты сценария города

Для создания карты города использовался некоммерческий сетевой картографический проект OpenStreetMap («открытая карта улиц») по созданию силами сообщества участников-пользователей сети Интернет подробной свободной и бесплатной географической карты всего мира [ CITATION VAN33 \l 1033 ]. Все данные доступны для легального копирования, редактирования и коммерческого использования по свободной лицензии. Для дальнейшей работы выбран город Ноттингем (рисунок 19).

Рисунок 19 – Фрагмент города Ноттингем

Все текущие данные OpenStreetMap (точки, линии, отношения и метки) сохраняются в формате XML. OpenStreetMap API сохраняет эти данные в пределах прямоугольника, указанного в браузере. Это называется запросом карты.

Имеется некоторое ограничение по размеру и сложности запрашиваемых данных. Данные XML могут быть сохранены в файл «*.osm». Именно с таким форматом данных работает симулятор городского движения SUMO (Simulation of Urban MObility). В нём можно увидеть, каким образом автомобили движутся в городе. В дальнейших сценариях города для узлов сети будут использоваться координаты машин, передвигающихся в условиях данной карты (рисунок 20).

Рисунок 20 – Симулятор городского движения SUMO

1. Настройка сценария симуляции

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

Для выполнения симуляции с целью анализа выбранных протоколов файл сценария следует модифицировать следующим образом:

• добавить модель коллизий;

• установить модель распространения сигнала;

• добавить код отвечающий за сбор статистики;

• модифицировать стратегию установки приёмников;

• установить параметры, связанные с картой (время симуляции, количество узлов, файл движения);

• добавить в код выбранные для анализа протоколы;

• установить размер пакетов данных и частоту отправки пакетов.

Для начала выполняется добавление модели коллизий. Для этого достаточно из объекта, отвечающего за беспроводной канал связи вызвать метод «setErrorRateModel()», с указанием в качестве аргумента названия модели которую планируется использовать. В данном случае задаётся модель «YansErrorRateModel» [ CITATION Tho \l 1033 ].

Затем требуется выполнить задание модели распространения сигнала. По умолчанию предлагается выбор из четырёх моделей:

– Two-Ray Ground;

– Friis;

– Log Distance;

– ItuR1411.

Выбор модели очень важен, так как модель определяет реалистичность передачи сообщений, так простейшие модели не учитывают дистанцию между узлами и сигнал не ослабляют, в то время как в реальных системах сигнал слабеет с увеличением дистанции. Согласно [ CITATION Str6P \l 1049 ] использование модели «ThreeLogDistance» вместе с затуханием «Nakagami»[CITATION CSo11 \l 1033 ], является наиболее приближенным к реальности [ CITATION Anj16 \l 1049 ], поэтому использоваться будет именно такое сочетание моделей.

Для установки модели используется метод «addPropagationLoss Model()», принадлежащий к классу канала связи, а в качестве аргумента метод принимает название модели. Также стоит отметить, что модели, добавленные к каналу с использованием этого метода, обладают свойством коммутативности, то есть новая модель накладывается на уже существующие, и эффекты моделей применяются в порядке их добавления.

Для возможности сбора статистики IP уровня модели OSI, нужно дополнить код для запуска симуляции:

Ptr<FlowMonitor> flowMonitor;

FlowMonitorHelper flowHelper;

flowMonitor = flowHelper.InstallAll();

Simulator::Stop (Seconds(stop_time));

Simulator::Run ();

flowMonitor->SerializeToXmlFile("NameOfFile.xml", true, true);

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

Для регулирования количества соединений в сети, сценарий имеет параметр «sinks», отвечающий за количество приёмников. Однако приёмники, созданные в необходимом количестве, будут иметь лишь один узел отправитель, таким образом для значения параметра «sinks» равного 10 в сети будет 10 соединений между приёмником и отправителем. Такое количество соединений является крайне малым и нереалистичным, в связи с этим необходимо модифицировать стратегию назначения приёмников, таким образом, чтобы каждому приёмнику все остальные узлы сети ставились в соответствие как отправители.

Код отвечающий за задание узлов-получателей выглядит следующим образом:

for (uint32_t i = 0; i < m_nSinks; i++){

Ptr<Socket> sink = SetupRoutingPacketReceive (adhocTxInterfaces.GetAddress (i), c.Get (i));

Характеристики

Список файлов ВКР