CC BY
44
ABOUT THE BASIC DIRECTIONS OF DEVELOPMENT OF STRATEGY OF DEVELOPMENT OF THE SYSTEM OF UNITED RUSSIAN INSURANCE FUND OF DOCUMENTATION
E.E. Evseev, P.E. Zavalishin, S.Y. Borzenkova, B.S. Yakovlev
The analysis of the existing opportunities to develop a strategy for the development of the unified Russian insurance Fund documentation and methods of its practical implementation at the state level using targeted budget allocations. The basic directions of development strategy development, including the main unified sections with the approximate content of each of them, corresponding to the main goals and objectives of the development of the unified Russian insurance Fund documentation.
Key words: insurance Fund of documentation, strategy of development of insurance Fund, the main unified section of strategy.
Evseev Evgeniy Evgenievich, candidate of technical sciences, director of development, tula3e@yandex.ru, Russia, Tula, «Aurica» Ltd,
Zavalishin Pavel Evgenievich, candidate of philosophical sciences, docent, zavalish-in-p19 75ayandex. ru, Russia, Tula, Tula State University,
Borzenkova Svetlana Yurievna, candidate of technical sciences, docent, tppziatsu. tula. ru, Russia, Tula, Tula State University,
Yakovlev Boris Sergeevich, candidate of technical sciences, docent, bor_ yaka mail. ru, Russia, Tula, Tula State University
УДК 004.057.4
ИССЛЕДОВАНИЕ ПРОТОКОЛА МАРШРУТИЗАЦИИ БЕСПРОВОДНОЙ ДЕЦЕНТРАЛИЗОВАННОЙ САМООРГАНИЗУЮЩЕЙСЯ СЕТИ
Н.И. Хохлов, Д.В. Ларин, А.В. Ларин, А.Н. Ивутин, А.С. Новиков, М.С. Пестин
Проведено исследование протокола маршрутизации в беспроводной децентрализованной самоорганизующейся сети и продемонстрированы результаты ряда экспериментов, выполненных с типовыми сетевыми топологиями для определения производительности протокола и параметров передачи данных. Модель протокола разработана на базе платформы OMNeT++ и позволяет варьировать различные параметры моделирования, задавать сценарии передачи данных и производить изменения топологии сети.
Ключевые слова: протокол маршрутизации, беспроводная децентрализованная самоорганизующаяся сеть, модель беспроводной сети, OMNeT++.
Беспроводная децентрализованная самоорганизующаяся сеть (также называемая ad-hoc-сетью, ДСС) представляет беспроводную одноранговую сеть с неустойчивой топологией [1]. Узлы в данных сетях, помимо
131
прочих, выполняют функции маршрутизаторов, которые участвуют в ретрансляции данных между другими участниками обмена. Для организации сетей данного вида используются специальные протоколы маршрутизации.
Преимуществами подобных сетей являются возможность передачи данных на большие расстояния без высоких затрат на передачу сигнала каждым из узлов, отсутствие необходимости в дополнительной инфраструктуре, высокая скорость и простота развёртывания сети, устойчивость к изменчивости в топологии ее связей. ДСС используются в задачах передачи информации в регионах с неразвитой информационно-коммуникационной инфраструктурой, при организации связи в условиях ведения боевых действий и чрезвычайных ситуаций [3], для обеспечения связи между группами автономных роботов, беспилотными летательными аппаратами [4].
Авторами статьи был разработан реактивный протокол для маршрутизации в ДСС и поддержания устойчивости ее структуры в условиях динамического изменения характеристик окружающей среды.
Описание протокола. Предлагаемый протокол маршрутизации имеет 4 основные процедуры.
1. Установление первоначальной связи между двумя произвольными узлами (процедура «рукопожатия», HANDSHAKE). Предназначена для обнаружения и добавления новых узлов в сеть. Также служит для первоначального формирования топологии сети.
2. Процедура проверки соединений между двумя узлами (процедура HELLO). Для этого соседние узлы опрашиваются при помощи сообщений специального вида с интервалом HELLO_TIME. В случае получения ответа связь с узлом назначения считается актуальной, в ином случае узел-инициатор информирует связанные с ним узлы о потере связи с узлом назначения.
На основе данных, получаемых из сообщений процедур HANDSHAKE и HELLO, формируется двухступенчатый граф сети, который используется в дальнейшем для поиска оптимальных маршрутов передачи данных.
3. Процедура поиска маршрута.
4. Процедура передачи данных по найденному маршруту.
Для препятствия бесконечному копированию пакетов в протокол введены механизмы удаления повторно проходящих по узлу пакетов и пакетов с петлями, а также учет времени жизни пакетов. Протокол поддерживает функции доставки данных, предназначенные для отправки команд от ведущего узла ведомым, низкоприоритетные сообщения, предназначенные для передачи служебных данных о состоянии узла (скорость перемещения, координаты), и сообщения произвольного приоритета с прикладными данными. Сообщения с данными отправляются в виде фреймов, каждый из которых может содержать от 1 до 255 пакетов.
Для исследования функционирования описанного протокола связи была поставлена задача создания имитационной модели, при помощи которой можно было бы провести оценку его характеристик и сравнить их с
132
параметрами известных протоколов [5]. В качестве симулятора сетевой инфраструктуры, который использовался при подготовке модели, была выбрана платформа OMNeT ++ [6].
Требования к модели. Разработанный протокол может быть использован в сетях с разными условиями эксплуатации, которые могут существенно отличаться друг от друга. Поэтому в модели должны были быть опущены эффекты среды передачи данных, которые обычно моделируются в протоколах физического, канального, транспортного уровней. Указанное упрощение позволит провести сравнительный анализ разработанного протокола связи с известными протоколами ad-hoc-сетей.
При пересылке пакетов между двумя узлами должны использоваться временные задержки, равные случайной величине из заданного пользователем интервала. Модель должна автоматически генерировать процедуры HELLO, HANDSHAKE и передачи данных согласно сценариям моделирования, которые могут быть заданы пользователями. Кроме того, должна присутствовать возможность симуляции динамического изменения топологии сети. Пользователи должны иметь функционал для задания значений параметров протокола. В созданной модели должен быть реализован процесс визуализации работы сети: пересылка пакетов между узлами, выделение путей, которые преодолевают пакеты, отображение графа маршрута. По результатам моделирования должен осуществляться сбор следующей статистики о работе сети: среднее время поиска маршрута, среднее время доставки данных, коэффициенты загрузки каналов между узлами и сети в целом. Отдельно должны рассчитывать коэффициенты загрузки полезными и служебными данными.
Реализация модели. OMNeT++ не является сетевым симулятором в чистом виде, а представляет систему дискретно-событийного моделирования. Однако инфраструктура данного симулятора позволяет симулировать сетевые технологии: имеются библиотеки для разработки сетевых узлов, каналов передачи данных, внесение ошибок в данные. Поэтому OMNeT++ и инструменты на его основе часто используются как сетевой симулятор. Данная система обладает графическим пользовательским интерфейсом с широкими возможностями отображения процесса моделирования и отображения результатов и промежуточных данных моделирования.
Модели в OMNeT++ имеют компонентную архитектуру. Они собираются из многократно используемых компонентов, называемых модулями. Модули могут объединяться друг с другом, образуя составные модули. Модуль на верхнем уровне иерархии представляет сеть, а простые модули на нижнем уровне реализуют логику работы модели. Описание модулей производится на встроенном языке NED, а логика модулей реализуется на языке программирования C++.
При создании модели сети было принято решение вынести основной функционал в два отдельных модуля. В первом модуле, названном Robot, реализованы функции протокола маршрутизации. Второй модуль,
названный Transmitter, предназначен для симуляции передачи сообщений на логическом уровне. Данные модули комбинируются в модуль «Node», представляющий узел сети. Массив из модулей «Node» объединен в сеть, представленную модулем «Mainnet». Структура модели представлена на рис. 1.
Рис. 1. Структура модели сети
Рассмотрим подробно реализацию модуля Robot. Он представляет простой модуль, поэтому имеет описание на языке NED и реализацию логики в классе, написанном на языке С++, который подобно другим классам системы, наследован от cSimpleObject. В данном модуле помещена вся логика работы протокола: генерация процедур HELLO, HANDSHAKE и передачи данных, событий тайм-аутов протокола, обработка сообщений, хранение маршрутных таблиц, формирование двухступенчатого графа сети и его визуализация. Данный модуль имеет следующую структуру на языке NED:
simple Robot { parameters: xml xmlFile;
double HND_ANSWER_TIME @unit(s) = default(Oms);
int TTL = default(16); int MIN_PACKET_COUNT = default(l); int MAX_PACKET_COUNT = default(255); int address;
int addressCommand = default(O); gates: inout port;
}
Блок parameters предназначен для описания параметров модуля. В нём определены параметры протокола, генерации пакетов данных, минимальное и максимальное количества пакетов во фрейме данных, адреса текущего и ведущего узлов. Параметр типа xml, как и в других модулях данной модели, содержит ссылку на файл конфигурации и сценариев. В блоке gates указываются ворота - интерфейсы, при помощи которых модули мо-
гут обмениваться данными между собой. В данном случае ворота port предназначены для взаимодействия с модулем Transmitter. Стоит отметить присутствующие в параметрах теги, названию которых предшествует символ @unit - позволяет назначать параметрам единицы измерения, @default - позволяет задавать значение параметра по умолчанию.
В OMNeT++ течение времени основывается на планировании событий. Событие возникает в случае отправки сообщения через определённый интервал времени другому модулю или самому себе для планирования определённых событий (selfmessage). Сообщения в OMNeT++ описываются при помощи файлов с расширением «msg», на основе которых среда генерирует классы на языке С++, унаследованные от cMessage или cPacket (пакеты данных). Для различия сетевых и selfmessage сообщений полю kind в объектах сообщений назначается идентификатор. Для удобства для всех сетевых сообщений протокола определено базовое сообщение BasePacket, содержащее общие поля:
packet BasePacket { unsigned char messageType @enum(TypePacket); unsigned char sourceNode; unsigned char addressedNode;
}
packet AccessAnswer extends BasePacket { messageType = ACCESS_ANSWER; unsigned char neighborCount; unsigned char neighborsList[]; unsigned long additionallnfo;
}
Тег @enum указывает, что параметр должен принимать значения из перечисления TypePacket, в котором перечислены виды сообщений. Пустые квадратные скобки после названия параметра означают, что данное поле представляет массив переменного размера.
В классе для принятия сообщений и обработки событий используется метод handleMessage(cMessage* message) - виртуальная функция, определённая в классе cSimpleObject, от которого унаследованы все модули модели. Благодаря полю kind удаётся отделить обработку сетевых сообщений от selfmessage, а поле messageType в BasePacket позволяет отдельно обрабатывать различные виды сообщений:
void Robot::handleMessage(cMessage *msg) { switch(msg->getKind()) {
case MessageKind: :KIND_FROM_TRANS_EVENT: fromTransEventMessage(msg); break;
void Robot::fromTransEventMessage(cMessage *msg) { BasePacket* packet = static_cast<BasePacket*>(msg);
switch(static_cast<int>(packet->getMessageType())) { case TypePacket: :ACCESS_QUERY: transAccessQueryMessage(msg); break;
void Robot::transAccessQueryMessage(cMessage *msg) { AccessQuery* accQuery = static_cast<AccessQuery*>(msg);
В модуль Transmitter вынесены функции симуляции протоколов канального, физического уровня в упрощённом виде. В данной реализации передача данных между двумя узлами характеризуется задержкой, равной случайному значению в заданном интервале. При этом одновременно по всей сети может пересылаться только один пакет данных. При моделировании считается, что отправка сообщения узлу, с которым отсутствует связь, также загружает сеть.
В данном модуле при помощи матрицы смежности задаются связи между узлами. Поскольку имитируется работа беспроводных каналов, в модуле производится сборка статистики по загруженности каналов и сети в целом. Модуль имеет следующее описание на языке NED:
simple Transmitter { parameters:
double TRANS_DELAY_MIN @unit(ms) = default(lms); double TRANS_DELAY_MAX @unit(ms) = default(lms); gates: inout internalPort; inout externalPort @loose;
}
Параметры TRANS_DELAY_MIN и TRANS_DELAY_MAX задают минимальную и максимальную задержку передачи данных. Ворота internalPort предназначены для обмена информацией с модулей Robot, а externalPort для взаимодействия с другими узлами. Тег @loose означает, что данные ворота могут быть использованы в качестве беспроводного интерфейса.
Составной Модуль Node объединяет модули Robot и Transmitter в логический сетевой узел. Данный модуль имеет только описание на языке NED:
module Node { parameters:
submodules: robot: Robot {
@display("p=43,59"); address = nodeAddress; xmlFile = xmlFileNode; }
transmitter: Transmitter { }
connections: robot.port <--> transmitter.internalPort;
}
В блоке «submodules» задаются дочерние модули, в том числе назначаются их параметры. В блоке «connections» задаётся соединение между модулями Robot и Transmitter. В данном случае используется простой канал без имитации задержек. Тег @display предназначен для задания параметров отображения модуля в графическом интерфейсе.
Модуль Mainnet является верхним в иерархии модели и задаёт сеть. Как и Node, данный компонент содержит только описание на языке NED:
network Mainnet { parameters: int nodesCount;
submodules:
nodes[nodesCount]: Node { }
}
Здесь используется параметр nodesCount, который предназначен для задания количества узлов сети. При помощи данного параметра инициализируется массив из узлов в блоке «submodules».
На основе разработанных модулей и шаблона оконного приложения система OMNeT++ формирует модель в виде исполняемого файла. Пример окна приложения и окна двухступенчатого графа сети на одном из узлов представлен на рис. 2. На основе xml-файла конфигурации формируются начальные связи в сети. В центре экрана расположен граф сети. Текущий маршрут узла выделен жирными линиями, а место текущей передачи маршрута помечено специальным маркером. В нижней части программы расположен текстовый лог процесса моделирования, который можно сохранить в файл. Вверху расположены инструменты для управления моделированием. В левой части приложения расположены навигатор и обозреватели объектов. В них можно просматривать все переменные и события компонентов модели, в том числе промежуточную статистику работы модели. Среди прочих переменных можно выбрать двухступенчатый граф маршрута, при нажатии на который открывается соответствующее окно.
Значения параметров модулей могут быть непосредственно объявлены в виде значений по умолчанию в файлах NED. Тем не менее, правильнее задавать параметры через файл инициализации с расширением «*.ini». К тому же задавать параметры можно из графического пользовательского интерфейса OMNeT++.
т О MNeT++/Q ten v (release)- Loadstar#0 - omnetpp.ini - /home/maxim/Program/omnetpp-5,4.1/samples/DRaDDP/src
File Simulate Inspect View Help
M ► ►► ►►► Ш © «5 О **
Lfl HD STEP RUN FftST EXPRESS UNTIL... ^ШГ \ REC
П, - ?Cb'!>8 97'473:666ms ??? f Cfi 450
Next: 6-»0/(9) /id: 276 (RoisteAnswer, id=190870) In: Mainnet.nodes[3j.transmitter (Transmitter, id=19) At: 97473.882056595854s (now+0.215833987404s)
[ ]
■i> ti t
Mainnet (Main net) td-1
xmlFileMainnet (cPar) nodesCount(cPar) LABEL fcParJ nodes[0] (Node) id=2 ♦ xmlFileNode (cPar ^ node Address (cPa □ robot (Robot) id=1 r~l transmitter (Trans nodes[1] (Node) id=3 nodes [2] (Node) id=1
i
l- t; I1»! "в ■
■■> TTL (cPar) 1 б Ф M!N_PACKET_COl
MAX_PACKET_CO! address (cPar) 3 addressCommand
и my Canvas (cCanva
Mainnet.node: Mainnet.node: Mainnet.node:
Mainnet.node« ▼
_ _
nodes[8]
пск^[1] nodes[4] nodes[7]
wamnet. nodes [.4J.ti Hai.nnet.nodes[6] .tr. Mai n net.nod es[5].tr Matnnet.nodes[5].ro Пересылка ROUTE_AKSWER: ** Event #205587 t=97473.298125424984 Mainnet.no<ies[5].tr
Event #2tb58J Event #205584 Event #205585 Event #205586
t=y/4 / 2.4iüli569444b t=97473.298125424984 t=97473.298125424984 t=97473.298125424984
LoadStar#0: Mainnet
Msg stats: 56 schedu
Рис. 2. Окна программной модели и двухступенчатого графа сети
Использование модели. При экспериментальной проверке построенной модели были получены зависимости следующих характеристик протокола: среднего времени поиска маршрута, среднего времени доставки данных, коэффициентов загрузки сети и отдельных каналов от значения константы HELLO_TIME - периода повторения процедуры HELLO.
Время поиска маршрута (Tr) равняется интервалу времени от момента начала процедуры поиска маршрута до времени получения узлом инициатором пакета с найденным маршрутом.
Время доставки данных (Td) равняется интервалу от момента отправки узлом первого пакетов фреймом в буфер приёмопередатчика до момента получения узлом пакета, подтверждающего доставку данных.
Коэффициент загрузки сети (Kl) считается равным отношению общего количества времени, в которое по сети передавались данные, к общему времени работы сети. Коэффициент загрузки канала между двумя узлами равен отношению времени, когда по каналу производилась передача данных к общему времени работы сети. При этом отдельно для сети и каналов рассчитывались коэффициенты загрузки полезными и служебными данными - отношение времён, занятых на передачу полезных или служебных данных, к общему времени работы сети.
В экспериментах использовались сценарии, согласно которым с периодом в 350 миллисекунд, начиная с 1200 миллисекунды, от одного узлу другому передаётся по 10 фреймов, каждый из которых содержит по 1 пакету. Другие параметры моделирования представлены в табл. 1. Далее рассмотрим результаты трёх таких экспериментов для разных топологий сети.
Таблица 1
Параметры проведения экспериментов_
Параметр Значение
HELLO TIME [50, 150, 250, ... , 1150, 1550] мс.
HND TIME 1000 мс.
HND ANSWER TIME 999 мс.
HELLO OK TIME 0.99 * HELLO TIME
ROUTE SEARCH TIME 100 мс.
ACTUAL ROUTE TIME 101 мс.
DATA ANSWER TIME Больше, чем время моделирования
DATA TRANSFERRED TIME Больше, чем время моделирования
REPEATED DQUERY TIME 1000 мс.
DATA REPEATED TIME 200 мс.
Интервал задержек передачи пакетов [0,3; 1] мс.
TTL 15
Время моделирования 1000 с.
В первом эксперименте использовалась топология, состоящая из 16 узлов, связанных последовательно в линию. При этом данные пересылаются от первого узла в линии самому удалённому. Результаты экспериментов представлены на рис. 3.
360 340 d 320 300
Р 280 260 240 220
Ч а
д
у
V
-г* ** —я
65 60 55 6 50 Й 45 £ 40 35 30 25 20
й
1
\
-р
400 800 1200 1600 200 600 1000 1400 HELLO TIME ж
400 аоо 1200 1600 200 600 100 0 1400 HELLO TIME, не
1
0.8 0,6 0.4 0 2
)2
о 14 ,—
д
■ К загрузки К. з. полезными данными К. з. служебными данными
0 200 400 600 800 1000 1200 1400 1600 HELLO TIME, sic.
Рис. 3. Результаты исследования протокола при использовании топологии «Линия» из 16 узлов: а - среднее время доставки данных; б - среднее время поиска маршрута; в - коэффициенты загрузки сети
Результаты первого эксперимента демонстрируют, что сеть является работоспособной при HELLO_TIME, большей 250 мс, а если HELLO_TIME меньше 150 мс, то сеть будет неработоспособной, так, время поиска маршрута и доставки данных принимают слишком большие значения, а сеть в большей степени загружена служебными данными. Уменьшение объёмов служебных данных происходит благодаря уменьшению общего количества пакетов, которые задействованы в процедуре HELLO.
Во втором эксперименте использовалась топология, состоящая из 16 узлов, которые выстроены в трехлучевую звезду, где равноудалённые от центра узлы также объединены между собой. Аналогичная топология для 10 узлов представлена на рис. 2. При этом данные пересылаются от центрального узла одному из крайних узлов. Результаты экспериментов представлены на рис. 4. Ввиду большего количества связей между узлами общее количество сообщений процедуры HELLO существенно больше, чем в первом эксперименте. Поэтому порог константы HELLO_TIME имеет большее значение, при которой сеть становится неработоспособной. По этой же причине возрастает общее количество служебной информации в трафике сети.
140
Ё 120 н
«я
ко 60
к а
у
1 1 ■
SO
И)
60
ml
н 50
40
30
Ö
400 800 1200 1600 200 600 1000 1400 HELLO TIME, не.
400 800 1200 1600 200 600 1000 1400 HELLO TIME. MC,
1,2 1
0.8 0.6 0.4 0.2
0
1
V— •
в
■ К загрузка - К. з. полезными данными К. з. служебными данными
200 400 бвв 80(1 1000 1200 1400 1600 HELLO TIME мс.
Рис. 4. Результаты исследования протокола при использовании топологии «Звезда» из 16узлов: а - среднее время доставки данных; б - среднее время поиска маршрута; в - коэффициенты загрузки сети
В табл. 2 представлены коэффициенты общей загрузки и полезными данными между каналами центрального узла и смежными с ним узлами при HELLO_TIME = 350 мс. Загрузку полезными данными имеет только канал между узлами с номерами 0 и 3. Это обусловлено тем, что через узел с номером 3 проходит маршрут к конечному узлу, который имеет номер 15. С другой стороны, этот канал имеет минимальный коэффициент загрузки среди других, смежных с нулевым. Это связано с тем, что через данный узел возвращается только один ответ, в то время как через другие -более одного.
В третьем эксперименте рассматривалась топология из 5 узлов, где каждый узел имеет связь со всеми другими. Результаты экспериментов представлены на рис. 5. Так как в данной ситуации узлы находятся в зоне прямой видимости друг друга, поиск маршрута и процедура HANDSHAKE не осуществлялись, и вследствие этого в трафике сети отсутствовали слу-
жебные пакеты, связанные с данными функциями протокола. Поэтому характеристика коэффициента загруженности в сети практически полностью совпадает с характеристикой коэффициента загруженности полезными данными. В то же время исследования показали, что отсутствует чётко выраженная зависимость среднего времени доставки данных от периода повторения процедуры HELLO. Общая загрузка сети при минимальном значении HELLO_TIME = 50 мс остаётся сравнительно небольшой (менее 60 %) по сравнению с данными, полученными в других экспериментах. Это означает, что в случаях, когда узлы находятся в прямой зоне видимости друг друга, сеть наиболее устойчива при передаче больших объёмов полезных данных.
Таблица 2
Номер узла Номер узла
2 3
Kl Klu Kl Klu Kl Klu
0 0,027979 0 0,028038 0 0,113046 0,041711
1 0,023431 0 0,023434 0
2 0,023449 0
н
tlj2 а
!0_5 äO.ii 10.4 10.2 ¡0
Ч
№
[ "
j Щ*. — _
W r—
200
400
S00
600 1000 KF.LLO ТШЕ, чс.
1209
3400
1Ш
■ К загрузи.^
К. з. полезными данными
■ К. з. служебными данными
1000
HELLO TIMF. ис.
Рис. 5. Результаты исследования протокола при использовании полносвязанной сети из 5 узлов: а - среднее время доставки данных; б - среднее время поиска маршрута; в - коэффициенты загрузки сети
В результате проделанной работы была создана программная модель, предназначенная для исследования протокола связи между узлами децентрализованной самоорганизующейся сети. Проведенные с помощью модели эксперименты позволили сделать следующие выводы, которые в дальнейшем позволят оптимизировать функционирование протокола связи и повысить эффективность процедур маршрутизации и передачи данных.
141
1. Чем больше степень связности узлов в сети, тем больше в ней будет существовать коротких маршрутов передачи сообщений между любой парой узлов. В результате время передачи данных в такой ДСС будет значительно меньшим, чем в сетях, состоящих из такого же количества узлов, но с меньшей степенью их связности. Поэтому рекомендуется при построении мобильной сети передачи данных всегда иметь некий резерв узлов для повышения связности сетевой структуры и сокращения маршрутов передачи сообщений между критически значимыми узлами.
2. С уменьшением значения константы HELLO_TIME (меньше 350 миллисекунд) коэффициент загрузки сети растет экспоненциально и при большом количестве узлов, составляющих ДСС, приближается к единице. В этом случае в общий коэффициент загрузки наибольший вклад вносит служебный трафик. С ростом величины параметра HELLO_TIME коэффициент загрузки сети и соответственно коэффициент свободы среды передачи стремятся к асимптотическим значениям, которые определяются характеристиками прикладного трафика и числом транзитных узлов маршрута, который используется для передачи сообщений.
3. При малых значениях константы HELLO_TIME в сети превалирует служебный трафик и отсутствует запас пропускной способности для передачи значительных объемов прикладных данных. Все это приводит к потерям прикладных пакетов, которые наблюдались при исследовании алгоритма передачи данных в сети.
4. При увеличении степени связности узлов в ДСС общий коэффициент загрузки сети при передаче тестового объема данных уменьшается, что можно объяснить существованием более коротких маршрутов для передачи потоков данных и соответственно меньшей нагрузкой на сеть при ретрансляции данных между транзитными узлами. В результате при планировании мобильной сетевой инфраструктуры следует стремиться к максимальной связности между передатчиками данных, чтобы обеспечить как можно более короткие пути для передачи сообщений.
Список литературы
1. Mobile Ad Hoc Networks. Current Status and Future Trands. Loo J., Mauri J.L., Ortiz J.H. 2014. 522 c.
2. Анализ состояния и перспективы развития самоорганизующихся сетей / А.В. Проскочило, А.В. Воробьёв, М.С. Зряхов, А.С. Кравчук // Научные ведомости Белгородского государственного университета. Сер.: Экономика. Информатика. Белгород, 2015. С. 177 - 186.
3. Павлов А. А., Датьев И.О., Шишаев М.Г. Разработка имитационных моделей для тестирования протоколов маршрутизации беспроводных многошаговых сетей // Вестник Иркутского государственного технического университета. 2016. С. 90 - 101.
4. Чаплышкин В. А. Использование беспилотных летательных аппаратов для организации воздушной одноранговой сети // Россия молодая: передовые технологии - в промышленность! Омск, 2015. С. 351-355.
5. Павлов А. А., Датьев И.О. Проблемы использования средств тестирования многошаговых беспроводных сетей // Труды Кольского научного центра РАН. Автоматика. Вычислительная техника, Кольск, 2017. С.116 - 123.
6. Варга А. Документация к системе моделирования OMNeT++ [Электронный ресурс]. URL: https://doc.omnetpp.org/omnetpp/manual/ (дата обращения 23.02.2019).
Хохлов Николай Иванович, канд. техн. наук, заместитель управляющего директора, kbkedr@,tula.net, Россия, Тула, АО «Конструкторское бюро приборостроения им. академика А.Г.Шипунова»,
Ларин Дмитрий Викторович, канд. техн. наук, заместитель начальника отделения, kbkedr@,tula.net, Россия, Тула, АО «Конструкторское бюро приборостроения им. академика А.Г.Шипунова»
Ларин Андрей Викторович, начальник отдела, kbkedr@,tula.net, Россия, Тула, АО «Конструкторское бюро приборостроения им. академика А.Г.Шипунова»
Ивутин Алексей Николаевич, канд. техн. наук, заведующий кафедрой, alexey. ivutin@,gmail. com, Россия, Тула, Тульский государственный университет,
Новиков Александр Сергеевич, канд. техн. наук, доцент, thesis-tsu@yandex. ru, Россия, Тула, Тульский государственный университет,
Пестин Максим Сергеевич, студент, maxime1996rus@mail. ru, Россия, Тула, Тульский государственный университет
RESEARCH OF ROUTING PROTOCOL OF A WIRELESS DECENTRALIZED
SELF-ORGANIZING NETWORK
N.I. Khokhlov, D.V. Larin, A.V. Larin, A.N. Ivutin, A.S. Novikov, M.S. Pestin
A research of the routing protocol in a wireless decentralized self-organizing network was carried out and the results of a series of experiments performed with typical network topologies to determine the protocol performance and data transmission parameters were demonstrated. The protocol model was developed on the basis of the OMNeT ++ platform and allows varying the various modeling parameters, setting data transfer scripts and making network topology changes.
Key words: routing protocol, wireless decentralized self-organizing network, wireless network model, OMNeT + +.
Khokhlov Nikolay Ivanovich, candidate of technical sciences, deputy managing director, kbkedr@,tula.net, Russia, Tula, The JSC «KBP named after Academician A. Shipu-nov»,
Larin Dmitrii Victorovich, candidate of technical sciences, deputy head of division, kbkedr@,tula. net, Russia, Tula, JSC «KBP named after Academician A. Shipunov»
143
Larin Andrey Victorovich, department head, kbkedr@,tula. net, Russia, Tula, JSC «KBP named after Academician A.Shipunov»,
Ivutin Alexey Nikolaevich, candidate of technical sciences, head of department, alexey. ivutin@,gmail. com, Russia, Tula, Tula State University,
Novikov Alexander Sergeevich, candidate of technical sciences, docent, thesis-tsu@yandex. ru, Russia, Tula, Tula State University,
Pestin Maxim Sergeevich, student, maxime1996rus@mail. ru, Russia, Tula, Tula State University
УДК 620.17
РЕЗУЛЬТАТЫ ЭКСПЕРИМЕНТАЛЬНЫХ ИССЛЕДОВАНИЙ
ВЫСОКОСКОРОСТНОГО УДАРА ПО РАЗНЕСЕННОЙ
ЭКРАННОЙ ЗАЩИТЕ
Э.Г. Синельников, М.В. Житный, П.С. Гончаров, Н.М. Тимофеев
Показаны результаты экспериментальных исследований по воздействию высокоскоростного алюминиевого ударника на специальную экранную защиту космического аппарата, выполненную по типу разнесенной преграды. Рассмотрены особенности повреждений защиты и входящих в нее компонентов. Проведено исследование двух вариантов построения защиты.
Ключевые слова: высокоскоростной удар, экспериментальные исследования, космический мусор, двухступенчатая газовая установка, космический аппарат.
Активное освоение околоземного космического пространства привело к резкому увеличению количества искусственных объектов, находящихся на околоземных орбитах. Эти объекты представляют собой как крупные фрагменты космических аппаратов (КА), ракет-носителей, так и малоразмерные твердые частицы, образующиеся в результате разрушения КА. Ударное воздействие таких высокоскоростных объектов на элементы КА с большой вероятностью приводит к повреждению космического аппарата. Так, например, результатом удара 2-мм высокоскоростной стальной сферы в оболочку КА является сквозная пробоина с выходным диаметром порядка 6 мм. Особо следует отметить то обстоятельство, что кроме крупных объектов, также большую опасность представляют и малоразмерные твердые частицы (МТЧ), обладающие большой относительной скоростью, в случае их воздействия на слабозащищенные критичные элементы конструкции КА, такие, как гермооболочки, емкости под давлением, системы терморегулирования, внешние трубопроводы и магистрали электропитания, топливные баки. Повреждение таких элементов КА, в конечном счете, приводит к отказам как в функционировании важных систем КА, так и КА в целом. В связи с этим особую актуальность приобретает задача обеспечения защиты уязвимых элементов конструкции КА от ударного воздействия частиц космического мусора (КМ), представляющего собой МТЧ.
144
