Разработка методов мультипотоковой передачи видеоданных на прикладном уровне в сетях БПЛА тема диссертации и автореферата по ВАК РФ 05.12.13, кандидат наук Кайсина Ирина Алексеевна

• Кайсина Ирина Алексеевна
• кандидат наук
• 2021

Оглавление диссертации кандидат наук Кайсина Ирина Алексеевна

ВВЕДЕНИЕ

ГЛАВА 1. АНАЛИЗ МЕТОДОВ ПЕРЕДАЧИ ПОТОКОВЫХ ДАННЫХ В СЕТИ БПЛА

1.1 Особенности уровней передачи данных в сети БПЛА

1.2 Анализ методов передачи и коррекции потоковых видеоданных для улучшения QoS

1.3 Анализ сценариев передачи потоковых видеоданных в сети БПЛА

1.4 Постановка задачи исследования

1.5 Выводы по главе

ГЛАВА 2. РАЗРАБОТКА МЕТОДОВ И АЛГОРИТМОВ МУЛЬТИПОТОКОВОЙ ПЕРЕДАЧИ ДАННЫХ В СЕТИ БПЛА С НЕСКОЛЬКИМИ ИСТОЧНИКАМИ

2.1 Модели процесса передачи потоковых данных на уровне приложений

2.2 Разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных прикладного уровня

2.3 Разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном летающем узле

2.4 Выводы по главе

ГЛАВА 3. ИССЛЕДОВАНИЕ ХАРАКТЕРИСТИК КАЧЕСТВА МУЛЬТИПОТОКОВОЙ ПЕРЕДАЧИ ВИДЕОДАННЫХ МЕТОДОМ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ

3.1 Разработка системы имитационного моделирования и эмуляции мультипотоковой передачи данных

3.2 Программная реализация алгоритма MS-AL-ARQ для проведения компьютерного моделирования

3.3 Компьютерное моделирование работы алгоритма ЫС-Е

3.4 Эмуляция совместной работы алгоритмов MS-AL-ARQ и ЫС-Е

3.5 Выводы по главе

ГЛАВА 4. ЭКСПЕРИМЕНТАЛЬНЫЕ ИССЛЕДОВАНИЯ КАЧЕСТВА ПЕРЕДАЧИ МУЛЬТИПОТОКОВЫХ ДАННЫХ

4.1 Задачи экспериментальных исследований

4.2 Постановка экспериментального исследования эффективности работы алгоритма MS-AL-ARQ с раздельными входными буферами

4.3 Постановка экспериментального исследования эффективности работы алгоритма MS-AL-ARQ с общим входным буфером

4.4 Выводы по главе

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ А

ПРИЛОЖЕНИЕ Б

ПРИЛОЖЕНИЕ В

ПРИЛОЖЕНИЕ Г

Введение диссертации (часть автореферата) на тему «Разработка методов мультипотоковой передачи видеоданных на прикладном уровне в сетях БПЛА»

ВВЕДЕНИЕ

Актуальность темы исследования. Беспилотные летательные аппараты (БПЛА) активно используются для решения задач мониторинга обширных наземных территорий (например, видеомониторинг местности), снятия различных показаний с помощью датчиков (например, электромагнитного поля Земли). Большинство научных исследований в этой области в настоящее время проводятся для сценариев с одним летающим узлом-источником, который передает данные на наземную станцию через узлы-ретрансляторы. Такая сеть является летающей самоорганизующейся сетью (Flying Ad Hoc Networks - FANET) с одним источником. Новые решения находят отклик при проектировании таких сетей; так, технология для межмашинного взаимодействия (М2М) LoRa может использоваться для решений задач «умного города».

Самоорганизующиеся сети БПЛА решают задачи увеличения площади охвата исследуемой территории и повышения качества передачи данных. Однако время выполнения миссии при этом остается значительным ввиду того, что источником данных является лишь один узел, которому необходимо облетать всю намеченную территорию. Всё это может негативно сказаться на выполнении миссии в режиме чрезвычайных ситуаций (ЧС), когда важна быстрая и качественная передача данных с борта БПЛА на наземную станцию. Использование в сети нескольких летающих узлов-источников может позволить разделить обследуемую территорию на части согласно маршрутам их движения и одновременно вести регистрацию и передачу данных в мультипотоковом режиме с видеокамер или датчиков на наземную станцию в реальном времени, что приведет к существенному сокращению времени выполнения миссии. При этом возникает проблема ухудшения качества обслуживания в сети (Quality of Service - QoS), так как передача данных с сенсоров (видеокамера, датчики) множества одновременно летающих узлов-источников по сети БПЛА к наземной станции способна вызвать перегрузки на маршрутах между летающими узлами.

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

На сегодняшний день в сценариях с одним узлом-источником более широкое применение нашли следующие методы передачи данных: автоматический запрос повторной передачи ARQ (Automatic Repeat Request) и прямое исправление ошибок FEC (Forward Error Correction). Данные методы продемонстрировали свою эффективность в проводных и беспроводных сетях. Однако сценарии применения этих методов в самоорганизующейся сети с несколькими источниками не были достаточно исследованы. Применение ARQ на канальном уровне в сети БПЛА с несколькими источниками может вызвать перегрузку входных буферов данных летающих узлов, потери пакетов и задержки, что может негативно сказываться на качестве получаемых данных. Применение FEC подразумевает добавление избыточности, что также может оказать негативное влияние на объеме и минимальной требуемой скорости передаваемых данных. Также для производителей БПЛА важным вопросом являются экономические затраты на разработку, производство и эксплуатацию. При реализации методов передачи данных на канальном и физическом уровнях становится необходимой закупка нового оборудования либо серьезные затраты на его разработку, в некоторых случаях также необходимо пересматривать конструкторские особенности БПЛА. В этой связи наилучшим путем решения задач повышения качества передачи данных является сосредоточение усилий по исследованию и разработке новых методов и алгоритмов передачи данных на вышестоящих уровнях (сетевом, транспортном, уровне приложений), где новые алгоритмы реализуются программным способом без внесения каких-либо изменений в аппаратную часть.

Диссертационная работа направлена на поиск решений, которые обеспечат улучшение характеристик QoS для передачи потоковых данных в сети БПЛА с несколькими узлами-источниками на уровне приложений модели OSI. Задачи, связанные с улучшением качества передачи видеоданных с нескольких, в частности с двух узлов-источников к наземной станции при решении задач мониторинга, являются сегодня актуальными, в том числе для промышленного сектора в области производства и эксплуатации систем БПЛА. После разработки методов и алгоритмов для улучшения качества доставки мультипотоковых данных с нескольких узлов -источников перспективными направлениями могут стать методы и алгоритмы для установки гибкой приоритезации среди нескольких узлов-источников.

Степень разработанности темы. Сеть беспилотных летательных аппаратов представляет собой частный случай сети MANET, в которой каждый летающий узел, как правило, высокомобилен и связан с другими узлами с помощью беспроводных технологии, например, WiFi, LoraWAN, LTE, 5G или других. В сети могут возникать потери доставки данных вследствие разрыва маршрута или из-за беспроводной природы среды передачи. Решению задач, связанных с повышением качества передачи данных в таких сетях, посвящено множество работ отечественных ученых, таких как: Кучерявый А.Е., Кучерявый Е.А., Киричек Р.В., Ляхов А.И., Прозоров Д.Е., Сухов А.М., Хоров Е.М, Парамонов А.И., Росляков А.В., Вишневский В.М., Самуйлов К.Е., а также зарубежных ученых: Bekmezci I., Sahingoz O. K., Temel S., Bok P.-B., Tuchelmann Y., Robinson W., Lauf A., Rosati S., Traynard L.F., Rimoldi B., Gupta L., Edison Pignaton de Freitas, C.Bettstetter и др.

Известны работы, направленные на улучшение качества передачи данных в сети БПЛА за счет совершенствования известных протоколов маршрутизации, используемых для сетей MANET, например, протоколы AODV, OLSR и другие. Отдельно стоит выделить методы повышения качества передачи данных в сети с большим количеством малых БПЛА, образующих «рой» беспроводных летающих узлов, которые исследуются в последние годы авторами: Wei Y., Blake M.B., Madey G.R., Ho D., Grotli E.I., Shimamoto S., Johansen T.A.

Задачи повышения качества передачи данных в сетях БПЛА решались лабораториями Communication System and Networks (г.Тампере), Lakeside Labs GmbH (г. Клагенфурт), EPFL (г. Лозанна), Universität Bern (г. Берна).

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

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

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

Цели и задачи диссертационной работы.

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

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

2. Разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных прикладного уровня на основе повторной передачи от нескольких летающих узлов-источников (MultiSource Application Layer ARQ - MS-AL-ARQ), позволяющих повысить коэффициент доставки пакетов (Packet Delivery Ratio - PDR).

3. Разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном летающем узле (Network Coding for FANETs - NC-F), позволяющих уменьшить полезную нагрузку прикладного уровня в самоорганизующейся сети БПЛА.

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

Научная новизна диссертационной работы заключается в следующем.

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

2. Разработаны метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных прикладного уровня, отличающиеся от известных тем, что используют повторную передачу от нескольких летающих узлов-источников (MS-AL-ARQ), и позволяющие повысить коэффициент доставки пакетов (PDR).

3. Разработаны метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном летающем узле (NC-F), отличающиеся от известных тем, что могут использоваться совместно с MS-AL-ARQ, и позволяющие уменьшить полезную нагрузку прикладного уровня в самоорганизующейся сети БПЛА.

Теоретическая и практическая значимость.

Теоретическая значимость. Предложенные в диссертационной работе аналитические и имитационные модели мультипотоковой передачи видеоданных в сетях БПЛА позволяют описывать процесс передачи фрагментов данных прикладного уровня модели OSI.

Практическая значимость полученных результатов заключается в повышении качества передачи мультипотоковых видеоданных в самоорганизующихся се-

тях БПЛА за счет использования повторной передачи потерянных фрагментов данных прикладного уровня от нескольких летающих узлов-источников (MS-AL-ARQ). Результаты экспериментальных исследований показали, что разработанные метод и алгоритм позволяют улучшить характеристики качества мультипотоковой передачи видеоданных в самоорганизующихся сетях БПЛА с несколькими летающими узлами-источниками.

Основные результаты диссертационной работы внедрены при разработке алгоритмического и программного обеспечения в ООО «ФИНКО», ГК «Беспилотные системы» для передачи мультипотоковых данных с нескольких БПЛА, что подтверждается соответствующими актами. Также полученные результаты внедрены в учебный процесс ФГБОУ ВО «ИжГТУ имени М.Т. Калашникова» кафедры «Сети связи и телекоммуникационные системы» при преподавании дисциплин «Информатика (специальные главы)», «Программное обеспечение инфокоммуникацион-ных сетей и устройств».

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

Положения, выносимые на защиту.

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

2. Метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных прикладного уровня, отличающиеся от известных тем, что используют повторную передачу от нескольких летающих узлов-источников (MS-AL-ARQ), и позволяющие повысить коэффициент доставки пакетов (PDR).

3. Метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном летающем узле (ЫС-Р), отличающиеся от известных тем, что могут использоваться совместно с

MS-AL-ARQ, и позволяющие уменьшить полезную нагрузку прикладного уровня в самоорганизующейся сети БПЛА.

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

Апробация работы. Основные положения диссертационного исследования докладывались и обсуждались: на V Форуме молодых исследователей (г. Ижевск, 2017 год), весенней сессии Выставки инноваций (г. Ижевск, 2017 год), 18 конференции International Conference on Next Generation Wired/Wireless Advanced Networks and Systems NEW2AN 2017 (г. Санкт-Петербург, 29-31 августа, 2017 год), конференции SIBCON (г. Москва, 2018 год), конференции FRUCT25 (Финляндия, 5-8 ноября, 2019 год), осенней сессии Выставки инноваций (г. Ижевск, 2019 год), конференции АВИАТОР (г. Воронеж, 13-14 февраля, 2020 год), конференции АПИН0-2020 (г. Санкт-Петербург, 26-27 февраля, 2020 год), семинаре MWENT 2020 (г. Москва, 13-14 марта, 2020 года), конференции FRUCT26 (г. Ярославль, 2324 апреля, 2020 года,), конференции FRUCT27 (Италия, 7-8 сентября, 2020 год).

Диссертационное исследование проводилось при поддержке Российского фонда фундаментальных исследований (РФФИ) по проектам: РФФИа/ААВ-16 (1508-09093/17), «Методы доставки потоковых данных для сенсорных самоорганизующихся сетей беспилотных летательных аппаратов», 2016-2018; РФФИ-мол_а/ВДС-18 (18-37-00218/18), «Метод ретрансляции потоковых данных в самоорганизующихся сетях малых беспилотных летательных аппаратов на основе сетевого кодирования», 2018-2019; РФФИмк (19-29-06076), «Методы мультипотоко-вой передачи данных от множества источников в сенсорных летающих сетях», 2019-2022. Работа также финансировалась Фондом содействия инноваций по программе «УМНИК-2018» по теме «Разработка программы для имитационного моделирования передачи данных в сети беспилотных летательных аппаратов».

Публикации. Основное содержание диссертации отражено в 22 опубликованных работах, в том числе: 6 статьей в рецензируемых журналах из перечня, рекомендованного ВАК Минобрнауки России для публикации результатов диссертационных исследований; 8 публикаций, опубликованных в изданиях, индексируемых в международных базах данных Scopus или Web of Science; 8 публикаций, опубликованных в других изданиях и материалах конференций; 3 свидетельства о государственной регистрации программы для ЭВМ.

Соответствует паспорту специальности 05.12.13 «Системы, сети и устройства телекоммуникаций» в областях: «2. Исследование процессов генерации, представления, передачи, хранения и отображения аналоговой, цифровой, видео-, аудио- и мультимедиа информации; разработка рекомендаций по совершенствованию и созданию новых соответствующих алгоритмов и процедур», «4. Исследование путей совершенствования управления информационными потоками», «11. Разработка научно-технических основ технологии создания сетей, систем и устройств телекоммуникаций и обеспечения их эффективного функционирования» и «14. Разработка методов исследования, моделирования и проектирования сетей, систем и устройств телекоммуникаций».

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

ГЛАВА 1. АНАЛИЗ МЕТОДОВ ПЕРЕДАЧИ ПОТОКОВЫХ ДАННЫХ

В СЕТИ БПЛА

1.1 Особенности уровней передачи данных в сети БПЛА

БПЛА нашли широкое применение в различных отраслях. Они могут использоваться при частной видеосъемке (например, панорамы города), для контроля сельхозугодий, мониторинга местности, в поисково-спасательных операциях и других задачах. Однако в перечисленных примерах в качестве узла-источника чаще используется один БПЛА, а в роли узла-получателя - наземная станция. С развитием беспроводных технологий и программных средств стало возможно разворачивание самоорганизующейся сети из нескольких БПЛА (Flying Ad Hoc Network) (рисунок 1.1) [1-3]. На рисунке 1.1 узел-источник обозначен как S (source), узлы-ретрансляторы как R (relays) и узел-получатель как D (destination).

R3

D

Рисунок 1.1 - Самоорганизующаяся сеть БПЛА

Применение таких сетей может рассматриваться как альтернативное дополнение существующих сотовых систем для достижения более высокой эффективности передачи с увеличенной зоной покрытия. В разделе 1. 1 рассматривается самоорганизующаяся сеть БПЛА в соответствии с уровнями базовой эталонной модели OSI и моделью TCP/IP.

Уровень сетевого доступа

При рассмотрении процесса передачи данных от летающего узла к наземной станции используются беспроводные технологии передачи данных, такие как 802.11, LTE, 5G и LoRa. Изначально большинство научных статей базировалось на рассмотрении применения стандартов семейства 802.11 (рисунок 1.2) к самоорганизующимся сетям БПЛА, в настоящее время более широкое распространение получили 802.11 n/g [4]. Детально ещё не исследован новый «гигабитный» стандарт 802.11 ас, который в будущем может найти широкое применение в самоорганизующихся сетях БПЛА. Перечисленные стандарты наиболее часто применяются при постановке научных экспериментов ввиду своей доступности и встроенной реализации в некоторых микрокомпьютерах.

802.11 802.11b 802.11a 802.11g 802.11n 802.11ac 802.11ax

Год ратификации 1997 1999 1999 2003 2009 2014 2017-2019

Рабочая частота 2.4 GHz/IR 2.4 GHz 5 GHz 2.4 GHz 2.4/5 GHz 5 GHz 2.4/5 GHz

Частотные каналы 20 MHz 20 MHz 20 MHz 20 MHz 20/40 MHz 20/40/80/160 MHz 20/40/80/16 0 MHz

Пиковая физическая скорость (PHY) 2 Mbps 11 Mbps 54 Mbps 54 Mbps 600 Mbps 6.8 Gbps 10 Gbps

Макс кол SU-потоков (SU Streams) 1 1 1 1 4 8 8

Макс кол MU-потоков (MU Streams) NA NA NA NA NA 4 8

Модуляция DSSS, FHSS DSSS, CCK OFDM OFDM OFDM OFDM OFDM, OFDMA

Макс тип и скорость кодирования DQPSK CCK 64-QAM, 3/4 64-QAM, 3/4 64-QAM, 5/6 256-QAM, 5/6 1024-QAM, 5/6

Макс кол тонов OFDM NA NA 64 64 128 512 2048

Разнесение субтонов NA NA 312.5kHz 312.5 kHz 312.5kHz 312.5 kHz 78.125 kHz

Рисунок 1.2 - Сравнительные данные для стандарта 802.11

При реализации реальных проектов (таких как удаленная система мониторинга) нашел применение беспроводной стандарт LTE [5,6]. В отличие от семейства стандартов 802.11 дальность передачи данных может быть увеличена до нескольких километров, скорость передачи данных также может быть выше. В стандарте LTE Advanced уже реализована поддержка активных антенных систем, более эффективное кодирование и модуляция, агрегация нескольких частотных каналов, уменьшенная задержка на уровне радиоинтерфейса. Последние исследования связаны с использованием технологии 5 G и миллиметровых волн при передаче данных [7-9]. В отличие от предыдущих поколений сетей связи (2G, 3G, 4G), для каждого из которых разрабатывался новый радиоинтерфейс, в сети 5G [7] планируется применять как новый радиоинтерфейс (New Radio, NR), так и уже существующий.

Также в последние годы большое внимание научного сообщества уделяется технологии LoRa, которая объединяет в себе метод модуляции LoRa в беспроводных сетях LPWAN и открытый протокол LoRaWAN. Технология LoRa обеспечивает межмашинное взаимодействие на расстоянии до 15 км при минимальном потреблении электроэнергии на несколько лет автономной работы на одном аккумуляторе АА. Диапазон применений данной технологии огромен - от домашней автоматизации до умных городов [10,11]. Применение данной технологии целесообразно при передаче малого количества данных с датчика на борту БПЛА к наземной станции.

Сетевой уровень

Самоорганизующиеся сети БПЛА могут использоваться при выполнении различных миссий, среди которых анализ трубопровода в труднодоступных районах или съемка местности. При выполнении подобных задач важно увеличить дальность связи, что может быть достигнуто благодаря введению узла-ретранслятора и применению протоколов маршрутизации на нём. В самоорганизующихся сетях БПЛА для ретрансляции данных нашли применение протоколы из самоорганизующихся сетей беспилотных автомобилей (VANET) и другие. Все протоколы маршрутизации можно разделить на четыре класса: статические, проактивные, реактивные и гибридные (рисунок 1.3) [12-15].

Рисунок 1.3 - Протоколы маршрутизации в самоорганизующихся сетях

Особенностью статической маршрутизации является загрузка таблицы маршрутизации на узлы БПЛА до выполнения миссии, т.е. таблицы маршрутизации не могут обновляться во время выполнения миссии. Статическая маршрутизация используется для сценариев с фиксированной топологией сети БПЛА [16]. Каждый узел поддерживает информацию о нескольких соседних летающих узлах или о наземной станции. В случае сбоя (БПЛА или наземной станции) для обновления таблиц необходимо дождаться окончания миссии [17,18].

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

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

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

• медленная реакция при изменении топологии или сбое сети.

Среди проактивных протоколов маршрутизации можно выделить следующие: OLSR, DSDV, WRP, Babel, B.A.T.M.A.N [19].

Главной особенностью реактивных протоколов маршрутизации является выстраивание маршрута от узла-источника до узла-получателя по «требованию». В отличие от проактивных протоколов реактивные не используют периодическую рассылку для поддержания сведений об активных маршрутах. Вместо этого в реактивных протоколах используется два типа сообщений: сообщения RouteRequest и сообщения RouteReply. Сообщения RouteRequest генерируются и отправляются в сеть с узла-источника, узел-получатель отвечает на это сообщением RouteReply. При получении сообщения RouteReply начинается передача, в результате чего каждый узел поддерживает только те маршруты, которые используются в данный момент. В этих протоколах нет периодических сообщений, следовательно, реактивные протоколы являются более эффективными для полосы пропускания. Недостатком является затрачиваемое время на поиск маршрута, поэтому в реактивных протоколах может возникать задержка. Можно выделить следующие реактивные протоколы маршрутизации: AODV, DSR, DYMO [20].

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

использовании гибридных протоколов маршрутизации сеть разделяется на кластеры. В кластере используются проактивные протоколы маршрутизации, вне кластера - реактивные протоколы маршрутизации. Среди гибридных протоколов маршрутизации можно выделить: HRP, ZRP, HWMP, ZHLS, TORA [21,22].

Транспортный уровень и уровень приложений

Для передачи видео в реальном режиме времени с борта БПЛА на наземную станцию на транспортном уровне чаще используется протокол UDP, для улучшения передачи данных и уменьшения задержек «поверх» UDP на прикладном уровне реализуются дополнительные программы. В качестве борта БПЛА могут использоваться микрокомпьютеры, т.е. видео подается с микрокомпьютера, а на выходе оказывается на ноутбуке. Основные требования, которым должно удовлетворять видео при передаче в реальном режиме:

• отсутствие задержек при начале трансляции;

• высокое качество картинки потоковой передачи;

• минимальная задержка в процессе потоковой передачи.

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

Рисунок 1.4 - Причины задержек при передаче видео

При передаче видео с борта БПЛА идет с камеры, после попадает в видеобуфер (где задержки минимальны - около 0,15 миллисекунд). На следующем этапе

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

Само видео можно рассматривать как набора кадров: I, P и B-frame (рисунок 1.5).

• I-frame - является расширением jpg. Опорный кадр, не зависит от других кадров, содержит четкую картинку.

• P-frame - зависит от последовательности предыдущих кадров.

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

Для избавления от B-frame сегодня применяют следующий методы.

1. Включение профиля Baseline (применяется в недорогих продуктах, требующих дополнительной устойчивости к потерям. Используется для видеоконференций и в мобильных продуктах) [23].

2. Настройка кодека для уменьшения задержки на последующие кадры.

3. Включение сервиса CBR. Представляет собой наиболее простой класс сервиса ATM. Когда сетевое приложение устанавливает соединение CBR, оно устанавливает пиковую скорость трафика ячеек (PCR), которая является максимальной

Список литературы диссертационного исследования кандидат наук Кайсина Ирина Алексеевна, 2021 год

источники ния QoS.

- узел-получатель» и разработка новых методов и алгоритмов улучше-

Рисунок 1.17 - Самоорганизующаяся сеть БПЛА с несколькими источниками

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

1. Разработаны модели мультипотоковой передачи видеоданных в сетях БПЛА с несколькими летающими узлами-источниками, позволяющие создавать

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

2. Разработаны метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных прикладного уровня на основе повторной передачи от нескольких летающих узлов-источников (MS-AL-ARQ), позволяющие повысить коэффициент доставки пакетов (PDЯ).

3. Разработаны метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном летающем узле (ЫС-Р), позволяющие уменьшить полезную нагрузку прикладного уровня в самоорганизующейся сети БПЛА.

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

1.5 Выводы по главе

В первой главе рассмотрены различные стандарты, технологии и протоколы применительно к самоорганизующейся сети БПЛА. Отдельная часть посвящена анализу существующих методов и алгоритмов, направленных на улучшение QoS в сетях БПЛА. Выделены основные критерии для передачи видео в режиме реального времени с борта БПЛА, к критически важным относятся: отсутствие задержек при начале трансляции, высокое качество картинки потоковой передачи и минимальная задержка в процессе передачи. В разделе 3 рассмотрены ранее изученные сценарии передачи данных в самоорганизующихся сетях БПЛА («узел-источник -узел-получатель»; «узел-источник - узел-ретранслятор - узел-получатель»; «узел-источник - рой узлов-ретрансляторов - узел-получатель») и методы улучшения QoS в них. Сделан вывод, что на сегодняшний день мало исследован сценарий с несколькими узлами-источниками. В то же время такой сценарий является актуальным в режимах ЧС и при задачах проведения мониторинга обширной наземной

территории в ограниченный период времени. Предлагается разработка новых методов и алгоритмов на уровнях выше канального для улучшения QoS. Такая реализация позволит производителям БПЛА не модернизировать существующее оборудование, а лишь добавить новое ПО в уже существующие модели.

ГЛАВА 2. РАЗРАБОТКА МЕТОДОВ И АЛГОРИТМОВ

МУЛЬТИПОТОКОВОЙ ПЕРЕДАЧИ ДАННЫХ В СЕТИ БПЛА С НЕСКОЛЬКИМИ ИСТОЧНИКАМИ

2.1 Модели процесса передачи потоковых данных на уровне приложений

Модель передачи данных от узла-источника к узлу-получателю

Для описания процесса передачи данных с борта БПЛА к наземной станции используются свойства случайных процессов [62,63]. При передаче данных от БПЛА к наземной станции возникает случайный процесс, который характеризуется случайным событием - потеря данных при передаче. Вероятность возникновения потерь данных является случайной величиной, которая может изменять своё состояние в дискретные моменты времени. Тогда процесс передачи данных от БПЛА может быть описан как динамическая система. Основной задачей становится определение закономерностей перехода данных из одного состояния в другое, для чего необходимо описать математическую модель процесса передачи данных. Был выбран метод, основанный на использовании уравнений переменных состояний [64-66].

Рассматривается модель, которая состоит из двух узлов: узел-источник -БПЛА, передающий потоковые данные на наземную станцию, и узел-получатель - наземная станция, принимающая потоковые данные от БПЛА. При передаче данных от БПЛА к наземной станции все данные прикладного уровня модели OSI делятся на блоки, которые состоят из Х фрагментов данных (рисунок 2.1). Фрагменты представляют из себя часть передаваемых данных одинакового размера на уровне приложений. В рамках работы не оговаривается содержимое каждого фрагмента, при этом каждый фрагмент принимается за элементарную единицу данных, которая передается отдельным сегментом транспортного уровня модели OSI.

Рисунок 2.1. - Процесс передачи блоков данных

Каждый переданный блок данных может быть представлен в виде вектора данных Х(д). Узел-получатель оценивает поток данных. Идеальным считается случай, когда все фрагменты в блоке распознаются правильно на узле-получателе. Оценка вектора Х(д) реализуется на интервале времени между моментами к (период одного блока) которые вычисляются как , где V - это скорость передачи фрагментов

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

Рисунок 2.2 - Воздействие потерь данных на передачу блоков данных

Процесс потери фрагментов данных в дискретном канале прикладного уровня модели ОБ! можно описать с помощью вектора потерь данных УУ(д), который после суммирования с Х(д) по правилу сложения по модулю 2 даёт вектор оценки 2(д) (рисунок 2.2).

Поскольку фрагмент данных в модели представлен как двоичный элемент, выдвигается предположение, что формат вектора представлен в виде Х(д) = {х1, х2,.. хп,} = {1,1,.. .1} и не меняется в течение времени передачи потоковых данных, т.е. не зависит от порядкового номера блока к. Элементы «1» в позиции вектора данных обозначают наличие фрагмента данных у узла-источника (содержимое не имеет значения).

Потери фрагментов данных обнаруживаются как преобразования Х(д) и УУ(д) . Следовательно, вектор оценки в качестве примера может быть представлен как 2(д) = {1,1,.. .1} 0 {1,0, ...1}, где второй фрагмент данных был потерян. Следовательно, канал передачи данных с узлом-источником и узлом-получателем может быть описан на основе подхода переменных состояний, который рассмотрен в [61,62] в рамках теории оценки и управления, а именно:

Хк+1(д)=А(к + 1,к)Хк(дУ, (2.1)

гк+1(д) = Хк+1(д) 0 В(к + 1, к)Шк(д), (2.2)

где

А(к + 1, к) - переходная матрица вектора данных; В(к + 1,к) - переходная матрица вектора потерь данных; 0 - групповая операция сложения по модулю 2; к = 0,1,... - порядковый номер вектора оценки.

Достоинством этого метода является возможность создания рекуррентных алгоритмов оценки, используемых в компьютерном моделировании. Уравнение (2.1) описывает поток данных от узла-источника, а уравнение (2.2) - канал прикладного уровня модели ОБ! с учетом потерь фрагментов данных. На

рисунке 2.3 показана структура модели источника и канала передаваемых данных на прикладном уровне модели OSI.

Рисунок 2.3 - Модель источника и канала для имитационного моделирования

Для модели определены следующие условия:

1) размерность всех векторов X;

-» —»

2) начальные условия (к = 0): Х0(д),

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

(2.3)

=

Модель позволяет в динамике описывать процесс передачи данных и разрабатывать имитационные модели для компьютерного моделирования [65]. Так, приведенная выше модель была программно реализована как отдельный модуль для описания процесса передачи данных на уровне приложений модели OSI в сетевом симуляторе Ш-3.

1 0 0 1 1

[0 1 0 X 1 =[ 1

0 0 1 1 1

Модель передачи данных от нескольких узлов-источников к узлу-получателю

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

Х1+1(д)=А1(к + 1,к)Х1к(д) (2.4)

Х*+1(д)=А2(к + 1,к)Х2(д) Х£+1(д)=Ап(к + 1,к)Х£(д)

21+1(3) = $1+1(8) 0 В1 (к + 1,к)Ш1(д) (2 5)

4+1.(9) = 4+1.(9) 0 В2(к + 1, к)Ш*(д) 4+1(9) = 4+1(9 0 Вп(к + 1, к)Ш£(д) где п - количество летающих узлов-источников.

Система уравнений (2.4) описывает передачу потоковых данных от узлов -источников, система уравнений (2.5) - каналы от узлов-источников до узла-получателя. Следует учитывать, что при передаче потоковых видеоданных от каждого узла-источника к узлу-получателю необходимо задавать номера портов и !Р-адреса. Другими словами, необходимо реализовывать работу с соке-тами, которых будет несколько на узле-получателе. Блок-схема на рисунке 2.4 иллюстрирует модель передачи потоковых данных от нескольких узлов-источников к узлу-получателю.

На рисунке 2.4 фрагменты данных представлены в формате векторов

^'к+1(9) и Х]^+1(д), векторы потерь данных представлены через Ж^д), №к(д) и №к(д). При этом для каждой пары векторов формируется отдельный вектор оценки 4+1, 4+1 и 4+1.

Рисунок 2.4 - Блок-схема модели процесса передачи данных от нескольких узлов-источников

к узлу-получателю

Представленная модель процесса передачи данных на уровне приложений модели OSI в дальнейшем используется в имитационном моделировании для описания процессов передачи данных по беспроводным каналам связи с потерями фрагментов данных, например, от БПЛА к наземной станции [68].

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

потерянных фрагментов

Одной из задач диссертационного исследования являются: разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных прикладного уровня на основе повторной передачи от нескольких летающих узлов-источников (МБ-ЛЬ-ЛЯО), позволяющих повысить коэффициент доставки пакетов (РОЯ). Для описания разрабатываемых метода и алгоритма необходимо рассмотреть модель прямого канала передачи данных на уровне приложений с избыточностью (от узла-источника к узлу-получателю), а также модель обратного канала связи на уровне приложений (от узла-получателя к узлу(-ам)-источнику(-ам)).

В общем случае избыточность на уровне приложений модели OSI является переменной (например, ЛRQ или адаптивный РЕС). Размер РЕС-избыточности в блоке не зависит от содержимого потоковой передачи данных, но зависит от информации обратной связи, которая периодически принимается от узла-получателя [69]. ЛЯQ-избыточность зависит от информации обратной связи, только когда фрагменты данных потеряны. Сначала следует отдельно рассмотреть источник данных с избыточностью. Блок данных с избыточностью будет иметь следующую размерность: X = Б + Я, где X - размерность вектора данных в блоках; О - размерность информационного вектор; Я - размерность вектора избыточности. Информационный вектор обозначен как И(д) , а вектор избыточности - как Я(д), каждый из них имеет одинаковую размерность X. Также не учитывается содержимое каждого фрагмента данных, и предполагается, что информационный вектор представлен как 1)(д) = {й1, й2,..., = {1,1,... ,1}. Формат вектора избыточности можно определить следующим образом: Я(д) = {г1, ...гП,гП+1, ...,гв+н} = {0, .,0,1, .,1} ,

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

С учетом избыточности уравнение (2.1) преобразуется следующим образом: 4+1(д) = А(к + 1, к)дк(д) 0 С(к + 1, к)Йк(д) (2 6)

где

С(к + 1,к) - переходная матрица избыточности.

Поскольку векторы Б (д) и Я (д) имеют одинаковую размерность, вектор данных (обозначен как Х(д)) можно представить в виде их суммирования по модулю

2: И(д) = {й1,й2,^,йх}0 {г1,...гп,гп+1,...,гп+к}, например, )((д) = {1,1,...,1}0 {0,... 0,1, .,1} = {1, ..,1,0,... 0}. Как можно заметить, число элементов «1» в информационном векторе Б (д) не соответствует реальному количеству информационных фрагментов данных в блоке, поскольку некоторые из блоков данных являются избыточными, но это необходимо для сопоставления размерности. Что касается вектора данных, элемент «1» обозначает наличие фрагмента данных, а элемент «0» обозначает наличие фрагмента избыточности (он имеет только одну разрешенную комбинацию в случае фиксированной избыточности). Следовательно, структура результирующего вектора данных соответствует структуре блока данных.

Согласно (2.6) в общем случае вектор избыточности Я(д) может генерироваться синхронно порядковым номером вектора оценки к. Это означает, что избыточность блока может изменяться довольно часто с периодом 1к. Однако это приведет к необходимости отправки контрольных фрагментов данных к источнику после каждого отправленного блока, что повысит вероятность перегрузки.

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

ществляется в момент времени т, который может быть определен как текущий порядковый номер интервала измерения коэффициента потерь (рисунок 2.5), составляющего Мблоков фрагментов данных. Интервал между моментами т (период одного измерения) определяется как = г^М (сек). Набор результатов измерения от каждого узла-источника может быть использован для принятия решения об изменении избыточности.

Рисунок 2.5 - Измерения временных интервалов

Для отправки фрагментов обратной связи от узла-получателя к узлам-источникам можно использовать две концепции: периодическая отправка или отправка по запросу. В первом случае фрагменты обратной связи периодически отправляются узлу-источнику на основе результатов одного или нескольких измерений коэффициента потерь фрагментов данных (Packet Loss Rate - PLR). Период отправки сообщения обратной связи в общем случае равен tmF, где F- количество последовательных измерений параметра PLR на узле-получателе. Если предположить, что

F = 1, то это означает, что информация обратной связи отправляется по результату каждого измерения PLR на интервале выборки М Однако в этом случае кратковременные чрезмерно быстрые изменения PLR в сети могут вызывать очень частые изменения избыточности и гораздо большее количество сообщений обратной связи. Чтобы избежать этого, измерение PLR можно проводить за несколько интервалов измерения М в пределах периода обратной связи tf с усреднением результата измерения (рисунок 2.5). Источник в этом случае использует измеренный на узле-получателе параметр PLR и принимает решение об избыточности (например, на основе порогового критерия). Обозначим рассматриваемый показатель степени потери фрагмента PLR как измеренную оценку вероятности потери фрагмента данных. Период обратной связи может быть определен путем компьютерного моделирования. Более того, его можно адаптивно вводить и контролировать на основе нагрузки узла-получателя.

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

Уравнение (2.2) описывает процесс приема перед восстановлением передаваемых фрагментов данных. Для учета процедуры восстановления в модель введен вектор восстановления Y(g). Его роль заключается в компенсации вектора потерь

данных, а способность компенсации зависит от избыточности блока. С учетом процедуры РЕС уравнение для векторов оценки

Кд) = Х(д) © Ш(д) © У(д). (2 7)

Введение вектора У(д) позволяет выделять вектор данных Х(д) из вектора оценки 1(д). Вектор У(д) зависит от вектора избыточности Я(д) и определяется следующим образом:

_ ^(д), если < Гк=1 гк\ (2 8)

X Y^х

{ 0, если %х=1 > %х=1 гк

где,

г и w - векторы избыточности двоичных элементов и ошибок соответственно.

Это означает, что фрагменты данных с избыточностью восстановят все потерянные фрагменты данных, если вес вектора потерь данных (количество фрагментов данных с потерями) равен или меньше веса вектора избыточности (количество избыточных фрагментов данных). В противном случае все элементы вектора У(д) равны «0», и поэтому вектор У(д^) не будет компенсировать вектор УУ(д).

Сообщения обратной связи играют важную роль для поддержки QoS. Они передаются от узла-получателя к узлу-источнику (узлам-источникам) и могут включать информацию об измерениях параметра РЬЯ и контрольную информацию. Однако фрагменты данных с сообщениями обратной связи также могут быть потеряны. Далее описан процесс потери фрагментов данных в канале обратной связи с помощью вектора потерь обратной связи Е(д), который после суммирования с вектором данных обратной связи Р(д) по модулю 2 приводит

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

Рк+1(д) = 0(к + 1,к)Рк(д); (2.9)

ик+1(д) = Рк+1(д) © Ь(к + 1,к)Ек(д), (2.10)

где

Б (к + 1,к) - переходная матрица данных обратной связи;

Ь(к + 1, к) - переходная матрица потерь данных обратной связи; 0 - групповая операция суммирования по модулю 2; К = 0,1, ... - порядковый номер вектора оценки обратной связи.

На основе представленных моделей передачи данных по прямому и обратному каналам на уровне приложений модели 0Б1 рассмотрим общую структуру модели передачи потоковых данных (рисунок 2.6) между двумя узлами: узлом-источником (БПЛА) и узлом-получателем (наземная станция).

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

Рисунок 2.6 - Структура модели передачи потоковых данных с избыточностью

Источник Контроль Прямой канал Обратный канал

Рисунок 2.7 - Модель потоковой передачи данных с блоком управления

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

Модель пакетного процесса Пуассона-Парето для передачи видеоданных

в сети БПЛА

При моделировании передачи данных используются стохастические процессы, которые рассматриваются как модели трафика. Одним из способов выбора стохастического процесса является приведение его статистических характеристик к реальным показателям трафика [70]. Для описания трафика данных обычно используются следующие модели: процесс Пуассона; Пуассоновский процесс, управляемый Марковской цепью (англ. Markov Modulated Poisson Process (MMPP)); авторегрессивный Гауссовский процесс и экспоненциальный авторегрессивный процесс [71,72]. В работе для описания трафика выбрана модель Пуассона-Парето (англ. Poisson Pareto Burst Process (PPBP)), которая является наиболее реалистич-

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

В соответствии с [76] обозначим через 1+ множество неотрицательных целых чисел, а через Я + - неотрицательные действительные числа. Рассмотрим непрерывный временной процесс [Вг: Вг Е !+, I > 0} , который представляет количество активных «всплесков», влияющих на поток трафика данных в момент времени I. В работе [76] определены временные интервалы получения «всплесков» [а^: а Е

= 0,1,2,...} и временные интервалы отправления «всплесков» данных [^: ^ Е = 0,1,2,...}. Значение Вг увеличивается на единицу в момент времени t = а^ и уменьшается на единицу в момент времени t = . В [76] определено, что Ы = а^ + , где ^ (й^ Е Я+) - длительность /-го «всплеска». Значение Вг определяется как

Случайная величина d - продолжительность единичного «всплеска», функция распределения которой имеет вид

где

у - форма распределения Парето; 6 - масштаб распределения Парето;

х - случайная величина. При 8 > 0 и 1 < у < 2 математическое ожидание Е [76]:

(2.11)

> х} = ■

11, х<8

(2.12)

(2.13)

Значение у связано с параметром Херста H, определенным следующим образом [77]:

Н=^. (2.14)

2

Учитывая, что 1 < у < 2 , параметр Херста H принимает значения от 0,5 до 1.

При у < 2 дисперсия бесконечна, то есть поступление пакетов на обслуживание показывает большой разброс между моментами поступления (что является одним из условий самоподобности) [78,79]. Наличие в распределении Парето так называемого «длинного хвоста» обеспечивает свойство пачечности трафика, поскольку в распределении существенно возрастают вероятности длинных интервалов между пачками пакетов (например, отсутствие пакетов на интервале), и для «поддержания» заданного среднего значения количества пачек необходима их концентрация (увеличение) на других интервалах времени [77,80,81]. В [82] также показано, что при 1 < у < 2 процесс Пуассона-Парето можно считать самоподобным при значении параметра Херста из формулы (2.14).

В работе [83] описан инструмент для генерации трафика согласно модели Пуас-сона-Парето в сетевом симуляторе Ш-3. Для реализации модели было необходимо использовать 4 программных модуля в Ш-3: PPBP-application.cc, PPBP-application.h, PPBP-helper.cc, PPBP-helper.h. Использование этих модулей дает возможность генерировать трафик, когда один или несколько пользователей из бесконечной группы начинают или прекращают передачу пачек данных. Модель Пуассона-Парето тесно связана с моделью очереди МЮ/да [84], предложенной в [85]. В модели пачки данных поступают в соответствии с пуассоновским процессом с частотой Хр, а их длина соответствует распределению Парето, характеризующемуся параметром Херста H, (обычно от 0,5 до 0,9), и продолжительностью «всплеска» данных Топ. Каждый поток моделируется с постоянной скоростью г бит/с [83].

Основываясь на законе Липла [86], среднее количество активных пачек данных можно определить как

Е[п] = ТопХЛр. (2.15)

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

^ _ Топ X Яр X г.

(2.16)

В модели Пуассона-Парето сетевого симулятора N8-3 задаются следующие параметры: скорость передачи пачек данных г бит/с., размер пакета данных в байтах, число активных источников Хр, длина пачки пакетов Топ, секунд, параметр Херста Н, 1Р-адрес узла назначения.

Согласно формуле (2.16) можно получить оценку влияния параметра Хр на общую скорость Я при г = 1 Мбит/с для разных значений продолжительности «всплеска» (Топ задается от 0,1 секунд до 0,4 секунд согласно [83]). Результаты расчета по формуле 2.16 представлены на рисунке 2.8.

Из рисунка 2.8 следует, что при увеличении длительности «всплеска» Топ от 0,1 секунд до 0,4 секунд и при увеличении числа активных узлов-источников пропорционально увеличивается общая скорость передачи данных Я, что является подтверждением формулы (2.16).

Рисунок 2.8 - Зависимость Я (Мбит/с) от Ар и Гоп(секунд)

Для исследования влияния мультипотоковой передачи данных от нескольких узлов-источников было проведено имитационное моделирование в сетевом симу-ляторе N8-3. Был выбран сценарий, который соответствует текущим запросам производственного сектора — обеспечение мониторинга большой наземной территории (завода/ангара). Для проведения мониторинга предложено использование нескольких узлов-источников в виде БПЛА. Данные от узлов-источников концентрируются на узле-шлюзе и передаются к узлу-получателю (рисунок 2.9). Летающий узел-шлюз А (БПЛА) передает трафик от сети БПЛА, сгенерированный согласно модели Пуассона-Парето и находится на расстоянии d1 = 1000 метров от узла-получателя В и на расстоянии d2 = 30 метров от поверхности земли. Выбор значений расстояний продиктован результатами исследований [43]. Также в имитационном моделировании была использована модель процесса передачи потоковых данных на уровне приложений, описанная в разделе 2.1. Было оценено влияние числа узлов-источников на полезную нагрузку прикладного уровня (Goodput) или полезную пропускную способность, измеряемую в количестве битов полезных данных доставленных сетью в единицу времени.

Рисунок 2.9 - Летающий узел-шлюз А передает трафик от сети БПЛА на наземную станцию В

При имитационном моделировании были установлены следующие параметры в Ш-3, соответствующие стандарту WiFi 802.11п, представленные в таблице 2.1.

Таблица 2.1 - Параметры для имитационного моделирования

Наименование параметров в NS-3 Значения

TxPower (дБ) 25

RxNoiseFigure (дБ) 7

ChannelWidth (МГц) 40

Frequency (Гц) 5180

PropagationLossModel FriisPropagationLossModel

SystemLoss 1,08

DataMode OfdmRate6Mbps

Type AdhocWifiMac

PacketSize (байт) 1370

SimulationTime (сек.) 3600,0

Transport Layer UDP

При моделировании в Ш-3 согласно программному модулю PPBP-applica-tion.cc изменялись следующие параметры: MeanBurstArrivals (число активных источников Лр), H (параметр Херста) и продолжительность «всплеска» Топ (секунд). Были заданы следующие ограничения для каждого из вышеперечисленных параметров: параметр Херста - от 0,6 до 0,9; продолжительность «всплеска» была задана от 0,1 секунд до 0,5 секунд согласно [83]. Также такая малая продолжительность «всплеска» данных на каждом узле-источнике была обусловлена особенностями выбранного сценария. «Всплески» при передаче видеоданных связаны с резкой сменой кадра, что вызывает большее число отправленных пакетов. При выполнении задач мониторинга определенной наземной территории «всплеск» может быть вызван попаданием постороннего объекта в поле зрения БПЛА, и он имеет непродолжительный характер. Общее время передачи потоковых видеоданных с нескольких БПЛА к наземной станции составило 5 минут.

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

этого параметра был неслучаен и обусловлен использованием математической модели на уровне приложений. Полезная нагрузка на уровне приложений вычислялась по формуле [87]

Ьи/* 1370*8 (2 17)

Goodput =

time

где

buf - число пакетов в буфере на узле-получателе в момент окончания симуляции; 1370 - размер пакета, байт; 8 - число бит в байте;

time - время работы приложения, передающего видеоданные.

По результатам имитационного моделирования были построены зависимости полезной нагрузки на уровне приложений (Goodput) от числа узлов-источников при различных значениях параметра Херста H и различной продолжительности «всплесков», продолжительность «всплеска» была равна 0,1 секунды (рисунок 2.10).

Рисунок 2.10 - Зависимость ОооёрМ от числа узлов-источников при разных значениях параметра Херста Н, продолжительность «всплеска» 0,1 секунды

Из рисунка 2.10 следует, что увеличение числа узлов-источников и величины параметра Херста Н повышает полезную нагрузку на уровне приложений. Также была построена зависимость полезной нагрузку на уровне приложений от продолжительностей «всплесков» для разного числа узлов -источников (от 1 до 4) при Н=0,6 (рисунок 2.11).

Из рисунка 2.11 следует, что увеличение числа узлов-источников и продолжительности «всплеска» повышает полезную нагрузку на уровне приложений. Это является логичным, так как продолжительный «всплеск» генерирует большой объем данных.

Н=0,6

6

о

0,1 0,2 0,3 0,4

Продолжительность "всплеска", сек

Рисунок 2.11 - Зависимости ОооёрМ от продолжительностей «всплесков» для разного числа

узлов-источников при Н=0,6

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

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

2.2 Разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с восстановлением потерянных фрагментов данных

прикладного уровня

Метод восстановления потерянных фрагментов данных прикладного уровня на основе повторной передачи от нескольких летающих узлов-источников

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

Рассмотрим процесс передачи от п узлов-источников на рисунке 2.12.

Первый узел-источник Второй узел-источник п-ый узел-источник

Узел-получатель Рисунок 2.12 - Процесс передачи фрагментов данных от п узлов-источников

Квадраты на рисунке иллюстрируют фрагменты данных, в которых имеется Ш-адрес источника, номер порта (на рисунке первая цифра до точки) и порядковый номер фрагмента данных. Все фрагменты последовательно передаются с п узлов-источников на один узел-получатель. На узле-получателе имеется несколько буферов, в которых хранятся полученные фрагменты данных. При этом буферы обновляются с приходом каждого фрагмента и имеют ограничение по размеру. После заполнения буфера фрагменты данных попадают в приложение для воспроизведения потокового видео, например УЬС Каждое приложение работает с определенным соке-том, т.е. на каждый узел-источник приходится работа отдельного приложения, что связано с разными Ш-адресами и портами. На рисунке 2.13 иллюстрируется процесс передачи потоковых видеоданных с двух узлов-источников (БПЛА) к узлу-получателю и трансляция потокового видео на узле-получателе (наземной станции).

Первый узел-источник Второй узел-источник

Рисунок 2.13 - Передача потоковых данных от двух узлов-источников

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

Рисунок 2.14 - Работа метода в сценарии с двумя узлами-источниками с разными входными буферами

На рисунке 2.14 два узла-источника отправляют фрагменты данных к узлу-получателю. При передаче данных через канал связи у первого узла утерян второй

фрагмент данных, а у второго узла - первый фрагмент. NACK для первого узла приходит в форме ответа на третий фрагмент данных. В это время идет передача четвертого фрагмента, и после этого повторно отправляется второй фрагмент с первого узла-источника. NACK на второй узел-источник приходит после второго фрагмента данных, в это время отправляется третий фрагмент, и после этого повторно высылается первый фрагмент данных от второго узла-источника. Все фрагменты поступают в буфер, после чего в соответствии с номером порта и IP-адресом транслируются в приложение VLC.

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

Первый узел-источник Второй узел-источник

Проигрыватель VLC

Рисунок 2.15 - Работа метода в сценарии с двумя узлами-источниками с общим входным буфером

На рисунке 2.15 два летающих узла-источника отправляют фрагменты данных к узлу-получателю. При передаче данных через канал связи у первого узла утерян второй фрагмент данных, а у второго узла - первый фрагмент. NACK для первого узла приходит в форме ответа на третий фрагмент данных. В это время идет передача четвертого фрагмента, и после этого повторно отправляется второй фрагмент с первого узла-источника. NACK на второй узел-источник приходит после второго фрагмента данных, в это время отправляется третий фрагмент, и после этого повторно высылается первый фрагмент данных от второго узла-источника.

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

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

(MS-AL-ARQ)

На основе ранее описанного метода предложен алгоритм Multi Source Application Layer ARQ (MS-AL-ARQ), который является усовершенствованной версией для мульти-потоковой передачи данных алгоритма AL-ARQ [98]. Одним из основных принципов работы алгоритма является определение потерянного фрагмента с одного из узлов-источников на основе порядкового номера с идентификатором IP-адреса. После определения потерянного фрагмента данных в буфер на узел-источник отправляется NACK. При этом установлен тайм-аут повторной передачи RTO (retransmission time out), по истечению которого NACK отправляется повторно. Данное действие будет повторяться пока: не будет получен фрагмент данных, пока не истечет тайм-аут ожидания фрагмента данных (RTO). В реализации алгоритма планировалось использование нескольких буферов: на узлах-источниках и узле-получателе. Помимо этого, было реализовано несколько вариантов работы алгоритма MS-AL-ARQ: для нескольких входных буферов на узле-получателе и для общего входного буфера на узле-получателе. При этом в момент начала трансляции каждый поток данных транслировался на отдельное приложение, т.е. под каждый узел-

источник необходимо выделить отельный порт. RTO вычисляется на основе аппроксимации статистики о времени цикла двухсторонней передачи RTT (Round Trip Time), также задается значение текущего сглаженного времени цикла SRTT (Smoothed Round Trip Time). Данные значения были взяты из протокола TCP [99]. В TCP используется схема повторной передачи, инициированная отправителем, которая использует тайм-ауты повторной передачи RTO и дублирование подтверждения (ACK).

Оценка RTO в TCP состоит из трех алгортмов. Первый, сглаженный оценщик RTT (SRTT), является экспоненциально взвешенным скользящим средним из прошлых выборок RTT [99,100]

RTT0,i = 0, (2.18)

а) * SRTTi-t + а* RTTit i > 1,

SRTT, = {(1 _

где

ЯТТ, - /-ая выборка задержки RTT, произведенная в момент времени ; а (по умолчанию 1/8) - коэффициент сглаживания, который можно варьировать, чтобы придать больший или меньший вес истории выборок RTT.

Ранее RTO был получен через умножение последних значений SRTT на фиксированный коэффициент от 1,3 до 2,0 [101]. Но было обнаружено, что оценщик RTO генерировал чрезмерное количество, дублирующийся пакетов при передаче. Было предложено добавить второй алгоритм, сглаженный оценщик дисперсии RTT (SVAR) в схему ретрансляции утерянных фрагментов [100]:

ЯТТ0/2,1 = 0, (2.19)

SVAR- = { ^TT0/2,i = 0,

1 {(1 _ Ю * SVARi-1 + $ * VARi, i > 1,

где

P (по умолчанию У ) - коэффициент сглаживания EWMA;

VARt - абсолютное отклонение i-го образца RTT от сглаженного среднего: VARt = \SRTT—1 _ RTTt\.

Настоящая реализация TCP вычисляет RTO, умножая сглаженную дисперсию на четыре и добавляя её к сглаженной двухсторонней задержке [100]:

RTO(t) = п * SRTTt + к * SVARi, (2.20)

где

t - время, в которое вычисляется RTO; n - 1; k - 4;

i - max: tt < t2.

Для MS-AL-ARQ на основе (2.18) вычислялось текущее SRTT, которое учитывало приоритет последних значений:

^РТТтеКущий 7 * 5КТТПредЪщущИй +1 * КТТтеКущий, (221)

где

SRTTTeKyimü - предыдущее сглаженное время цикла; КТТтекущий - текущее время цикла. Текущее отклонение определялось как

DEVj-екущее 1^^^текущий ^ЯТТПредъщущий1. (2.22)

Текущее сглаженное отклонение определялось через (2.19):

БОЕУТекущий = 3 * ^ОЕУпредыдущий + 1 * DEV. (Z23)

Тайм-аут повторной отправки находился на основе (2.20):

RTO = БЯТТтекущий + 2 * БОЕУТекущИй. (2.24)

Формулы (2.22) - (2.24) были заложены программно в реализацию алгоритма мультипотоковой передачи видеоданных в сети БПЛА MS-AL-ARQ.

Работа алгоритма также представлена на рисунке 2.16. Основной принцип работы алгоритма MS-AL-ARQ вне зависимости от версии программной реализации представлен в части «добавление номера пакета в буфер» на рисунке 2.16. Узел-получатель хранит полученные пакеты данных с разных узлов-источников и упорядочивает их, при поступлении нового пакета в буфер узел-получатель проверяет его номер, если пакет входит в последовательность (его номер равен порядковому номеру предыдущего пакета плюс один), то он не добавляется в базу NACK-ов, если же номер пакета не является последовательным, то будет отправлен NACK к соответствующему узлу-источнику, а пакет занесен в буфер NACK-ов. Повторная отправка NACK будет осуществлена после истечения RTO.

Рисунок 2.16 - Блок схема работы алгоритма MS-AL-ARQ

Алгоритм MS-AL-ARQ необходимо реализовывать отдельно на летающих узла-ис-точниках и узле-получателе, так как алгоритм подразумевает работы с разными буферами на узлах-источниках (которые в течении некоторого времени хранят ранее отправленные пакеты видеоданных) и на узле-получателе (для хранения и упорядочивания полученных пакетов данных с разных узлов-источников). Помимо этого в работе было реализовано две версии алгоритма MS-AL-ARQ. одна версия подразумевает создание отдельных буферов на узле-получателе для каждого узла-источника (рисунок 2.14), вторая версия создает общий буфер для всех летающих узлов-источников (рисунок 2.15).

2.3 Разработка метода и алгоритма мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном

летающем узле

Метод мультипотоковой передачи видеоданных в сети БПЛА с применением сетевого кодирования на промежуточном летающем узле Для борьбы с перегрузками на узле-ретрансляторе и уменьшения полезной нагрузки прикладного уровня при одновременной передачи данных с нескольких узлов-источников совместно с MS-AL-ARQ предложено использование метода и алгоритма на основе сетевого кодирования. В разделе 1.2 рассматривался метод сетевого кодирования, который может быть использован не только на канальном уровне модели OSI, но и на более высоких. Так, если рассматривать реализации сетевого кодирования в соответствии с моделью OSI, то можно выделить следующие разновидности: на физическом уровне (аналоговое сетевое кодирование, физическое сетевое кодирование), на канальном уровне и сетевом (COPE-подобное сетевое кодирование, BEND), на транспортном уровень (QUIC) и на уровне приложений (R2) [88]. В [89] проанализирован процесс многоадресной передачи данных в компьютерных сетях с многосвязной топологией с точки зрения теории информации. В классической теории информации рассматриваются соединения вида «точка-точка», а передаваемую информацию описывают как поток данных. По мнению авторов работы [89], представление об информации как о потоке данных,

который в неизменном виде маршрутизируется между узлами сети, подходит лишь для описания процесса передачи между одним источником и одним адресатом. Если же источников и адресатов больше одного (многоадресная передача), то промежуточным узлам следует не только ретранслировать и маршрутизировать пакеты данных, но и кодировать пакеты, поступившие от нескольких источников. Пользуясь математическим аппаратом теории графов, авторы доказали, что в определенных сетевых топологиях оптимальный подход к многоадресной передаче информации включает в себя сложение битов в поле GF(2) (операция XOR, исключающее «ИЛИ») на промежуточных узлах и декодирование этих данных на последующих шагах маршрутизации. Они назвали этот подход сетевым кодированием. Авторы показали, что классический подход к многоадресной передаче в компьютерных сетях не является оптимальным, а эффективная доставка информации в сетях с многосвязной топологией представляет собой не набор независимых потоков от каждого источника до каждого адресата, а смешение нескольких потоков между собой с помощью сетевого кодирования.

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

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

уменьшить количество переданных данных. Для этого в одном из случаев реализации между канальным и сетевым уровнем вставляется специальный заголовок, который позволяет узлу-ретранслятору определить возможность применения кодирования [91]. Пример работы метода сетевого кодирования в сети БПЛА с несколькими узлами-источниками представлен на рис. 2.17.

Оконечные узлы обозначены через £1 и 52, узел-ретранслятор обозначен через Я. На рисунке 2.17а оконечный узел £1 передает данные оконечному узлу £2 через узел-ретранслятор Я, в это же время оконечный узел £2 передает данные оконечному узлу £1 также через узел-ретранслятор Я. Процесс передачи данных требует 4 действия. При использовании СОРЕ-подобного сетевого кодирования (рисунок 2.176) оконечный узел £1 и оконечный узел £2 передают данные друг другу, но узел-ретранслятор не пересылает их сразу, а сначала выполняет их сложение и после чего отправляет одно широковещательное сообщение. В итоге, вместо 4 передач требуется всего 3 [90,91].

Рисунок 2.17 - Пример передачи данных а) без СОРЕ-подобного сетевого кодирования б) с применением СОРЕ-подобного сетевого кодирования

В качестве метрики, позволяющей оценить эффективность COPE-подобного сетевого кодирования, примем выигрыш от кодирования (отношение числа передач в режиме без кодирования к минимальному числу передач в режиме с кодированием для одинакового числа пакетов) [92-96]. Выигрыш от кодирования для примера с рисунка 2.17 определяется как отношение 4 к 3 и равен 1,33.

Алгоритм мультипотоковой передачи видеоданных в сети БПЛА с применением СОРЕ-подобного сетевого кодирования МС-Г)

На основе рассмотренного ранее метода мультипотоковой передачи видеоданных от нескольких узлов-источников с применением COPE-подобного сетевого кодирования разработан соответствующий алгоритм (NC-F) для сети с двумя оконечными узлами и одним летающим узлом-ретранслятором (схема сети на рисунке 2.17). Блок-схемы предложенного алгоритма NC-F для оконечных узлов и узла-ретранслятора представлены на рисунках 2.18 и 2.19 соответственно.

При работе алгоритма в первую очередь все узлы сети формируют таблицы о соседних узлах. Перед отправкой пакетов в сеть оконечные узлы сохраняют их в буфер, после этого на оконечном узле идет процесс передачи и приема данных с летающего узла-ретранслятора. При этом узел-ретранслятор формирует несколько отдельных очередей для двух оконечных узлов, по возможности выполняет объединение пакетов и отправляет один широковещательный пакет. Как только пакет попадает на оконечный узел, выполняется проверка возможности извлечения пакета, для этого оконечный узел проверят буфер на наличие ранее отправленного пакета. Отличительной особенностью реализации алгоритма NC-F является его адаптация к совместному применению с алгоритмом MS-AL-ARQ, а также к сценариям с летающим узлом-ретранслятором.

Формирование таблицы с информацией о соседних узлах

-' I --:

Запись исходящих пакетов в буфер

I

Передача и прием данных

Проверка буфера

Извлечение пакета

Рисунок 2.18 - Блок-схема работы алгоритма ЫС-Р на основе СОРЕ-подобного сетевого

кодирования для оконечных узлов

Запись пакета в очередь источника п-1

Рисунок 2.19 - Блок-схема работы алгоритма на основе COPE-подобного сетевого кодирования для летающего узла-ретранслятора

Запись пакета в очередь источника п

Разработанный алгоритм N0^ дополняет работу протокола маршрутизации B.A.T.M.A.N. Adv [97], который использовался при проведении эмуляции процесса передачи данных с двух оконечных узлов.

2.4 Выводы по главе

1. Во второй главе предложены модели процесса передачи потоковых данных на уровне приложений: модель передачи данных от узла-источника к узлу-получателю, модель передачи данных от нескольких узлов-источников к узлу-получателю, модель передачи данных на уровне приложений с восстановлением потерянных фрагментов данных, модель пакетного процесса Пуассона-Парето для передачи видеоданных в сети БПЛА. В первой модели описан процесс передачи фрагментов данных на уровне приложений модели OSI от летающего узла-источника к узлу-получателю. Во второй модели описан процесс передачи фрагментов данных на уровне приложений модели OSI от нескольких летающих узлов-источников к узлу-получателю, при этом подразумевалась передача фрагментов данных на разные сокеты в соответствии с №-адресом каждого узла-источника и номера порта. Третья модель описывала процесс восстановления потерянных фрагментов данных на уровне приложений. Предполагалось, что в качестве методов восстановления будет использован AЯQ прикладного уровня. Предложенные модели позволяют создавать программы для имитации и эмуляции процесса передачи данных прикладного уровня от нескольких летающих узлов-источников в виде БПЛА. Для характеристики трафика видеоданных описана модель пакетного процесса Пуассона-Парето, которая ранее с помощью нескольких программных модулей была реализована в сетевом симуляторе N8-3. Помимо этого во второй главе проведено имитационное моделирование процесса передачи видеоданных с нескольких узлов-источников в виде БПЛА к наземной станции, при этом использованы все вышеперечисленные модели. Результаты моделирования продемонстрировали, что при увеличении количества узлов-источников увеличивается полезная нагрузка уровня приложений (ОоойриР).

2. Для увеличения коэффициента доставки пакетов (РОЯ) предложены метод и алгоритм мультипотоковой передачи видеоданных в сети БПЛА с вос-

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

3. Для уменьшения полезной нагрузки прикладного уровня (Goodput) в самоорганизующейся сети БПЛА предложены метод и алгоритм мультипото-ковой передачи видеоданных на основе COPE-подобного сетевого кодирования. Отличительной особенностью реализации алгоритма NC-F является возможность его работы совместно с алгоритмом MS-AL-ARQ, а также его адаптация к сценариям с летающим узлом-ретранслятором.

ГЛАВА 3. ИССЛЕДОВАНИЕ ХАРАКТЕРИСТИК КАЧЕСТВА МУЛЬТИПОТОКОВОЙ ПЕРЕДАЧИ ВИДЕОДАННЫХ МЕТОДОМ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ

3.1 Разработка системы имитационного моделирования и эмуляции

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

Для оценки эффективности предложенных методов и алгоритмов передачи потоковых видеоданных в сети БПЛА от нескольких источников было необходимо провести компьютерное моделирование с использованием имитации и/или эмуляции процессов передачи со встроенными функциями измерения параметров качества обслуживания. Для этого была разработана система имитационного моделирования и эмуляции мультипотоковой передачи данных в сети БПЛА при условии одновременной передачи от нескольких источников. Система обеспечивает проведение имитационного моделирования в сетевом симуляторе Ш-3 и эмуляцию с использованием ОС ЦЫПл (канал связи также был смоделирован программными средствами N£-3).

Сетевой симулятор Ш-3 является набором библиотек и вспомогательных модулей для моделирования сетей и сетевого взаимодействия. За счет использования С++ в качестве встроенного языка симулятор представляется гибкой и мощной системой. Имитационная среда Ш-3 подходит для оценки качества доставки потоковых видеоданных и изображений с камеры на борту БПЛА к наземной станции при непредсказуемых нарушениях маршрутов передачи данных через другие узлы в рое летающих узлов сети БПЛА. Сценарий выполнения какой-либо миссии с помощью летающих узлов сети БПЛА в среде Ш-3 представляет собой программный код, написанный на языке С++. По исходному коду можно собрать всю необходимую информацию, касающуюся взаимодействия летающих узлов в сети БПЛА: pcap-файлы (сгенерированные на виртуальных узлах); таблицы маршрутизации; количество переданных и потерянных пакетов данных; время передачи пакета через сеть;

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

Рисунок 3.1 - Структура NS-3

Модули «core» симулятора NS-3 образуют универсальное ядро, позволяющее моделировать мобильные сети передачи данных. Программы в среде NS-3 могут получить доступ к функционалу симулятора, используя программный интерфейс (API) или вспомогательные классы (helper class). С помощью NS-3 можно симулировать беспроводные сети на основе различных стандартов. Это позволяет проводить имитационное моделирование процессов передачи потоковых данных в сети БПЛА с движущимися летающими узлами в трёхмерном пространстве по различным сценариям выполнения миссии на определенной территории (рисунок 3.2) [102].

В левой части рисунка 3.2 изображен сценарий, который может быть реализован в NS-3, где узел-источник в виде БПЛА передает данные с камеры на борту к наземной станции через рой летающих узлов-ретрансляторов. При этом в NS-3 существует возможность для тестирования новых алгоритмов доставки данных (правая часть рисунка 3.2): ARQ прикладного уровня, FEC прикладного уровня, сетевое

кодирования и другие алгоритмы. Также N8-3 позволяет подробно описать параметры на каждом уровне модели OSI, например, мощность передатчика, чувствительность приемника, рабочие частоты и другие.

Рисунок 3.2 - Возможный сценарий передачи данных с борта БПЛА к наземной станции для

тестирования новых алгоритмов

Для проведения симуляции в NS-3 и эмуляции можно выделить некоторые ключевые абстракции (классы): Node, Application, Channel, Net Device и различные помощники в организации топологии. Node - понимается как компьютер или некоторое другое устройство. Application - абстракция пользовательской программы, которая способна генерировать данные (например, отправка видеоданных). Channel - класс, которые помогает описать канал связи между узлами в сети. Net Device (сетевое устройство) - абстракция, которая охватывает программные драйверы и моделируемое оборудование [103].

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

множество узлов-источников (БПЛА), также необходимо получать разрешение на проведение эксперимента с БПЛА, что требует значительных временных и материальных затрат. Проведение эмуляции позволяет избежать закупки оборудования и сократить временные затраты при разработке и исследовании новых методов и алгоритмов для улучшения качества передачи данных в сети БПЛА. Вместе с этим роль летающих узлов выполняют виртуальные машины, которые являются цифровыми двойниками бортовых микрокомпьютеров, например Raspberry Pi. Канал связи между узлами создается через систему моделирования NS-3. Иллюстрация системы проведения эмуляции представлена на рисунке 3.3.

ООО

Рисунок 3.3 - Система эмуляции передачи данных в сетях БПЛА

Если рассматривать архитектуру эмуляции сверху вниз, сначала идет работа с гостевыми машинами с установленными ОС Ubuntu Mate 16.04 в Virtual Box 5.2. Данная ОС была выбрана исходя из того, что она может использоваться на микрокомпьютерах Raspberry Pi, которые являются частью малых БПЛА. На гостевых машинах можно запустить передачу потоковых видеоданных через приложение для воспроизведения видео VLC или gstreamer. Каждая машина имеет собственный сетевой стек и связана с сетевыми устройствами, которые

подключены к мостам Linux, образующим программное соединение с операционной системой основной машины. К каждому из этих мостов также подключен TAP-интерфейс, который доставляет пакеты, переданные приложениями на гостевых машинах в среду имитационного моделирования NS-3, работающую на основной машине. NS-3 может получить доступ к пакетам и, следовательно, моделировать канал связи между гостевыми машинами [104,105].

3.2 Программная реализация алгоритма MS-AL-ARQ для проведения

компьютерного моделирования

Для улучшения качества передачи в самоорганизующейся сети БПЛА с несколькими узлами-источниками на уровне приложений предлагается использование механизмов запроса повторной передачи утерянных фрагментов данных с помощью применения алгоритма MS-AL-ARQ. Также в работе предложено совместное использование MS-AL-ARQ прикладного уровня с алгоритмом NC-F на основе COPE-подобного сетевого кодирования на сетевом уровне. В данном разделе описана программная реализация алгоритма MS-AL-ARQ для работы с разными входными буферами и дальнейшей поддержкой NC-F для сценария с двумя оконечными узлами и одним узлом-ретранслятором.

На рисунке 3.4 представлен фрагмент кода программной реализации алгоритма MS-AL-ARQ на узле-источнике для версии с разными входными буферами, который основан на методе выборочного повторения на прикладном уровне. В соответствии с кодом на рисунке 3.4 алгоритм MS-AL-ARQ распознает, является ли пришедший фрагмент данных видеофрагментом (с борта БПЛА или с видеоплеера), или же это отрицательное подтверждение от узла -получателя.

bufferin [ ] = receive_data (UDP_socket);

If (bytes Ln >=VIDEO_CHUNCK SIZE){ Add data from buffer_in to buffer_out;

Рисунок 3.4 - Фрагмент кода для реализации алгоритма MS- AL-ARQ на узле-источнике

Приложение получает первый байт данных, который является идентификатором (ID). Если полученный ID равен ID отрицательного подтверждения (IDARQNACKAL), то будет выполнена проверка на наличие запрошенного фрагмента в буфере (через порядковые номера sequence number - SN). Если же фрагмент отсутствует в буфере, то узел-источник отправит сообщение отмены, чтобы проинформировать узел-получатель об удалении запрошенного пакета из списка ожидания. Также код, представленный на рисунке 3.4, обрабатывает данные с видеопроигрывателя (или камеры) и формирует новый пакет к узлу-получателю. Формат пакета представлен на рисунке 3.5.

ID RN TN SNg SN VQP T_S Payload

1 1 1 4 4 2 4 Bytes

Рисунок 3.5 - Формат пакета при работе алгоритма MS-AL-ARQ

Первые 13 байт отведены под заголовок MS-AL-ARQ, который содержит различную информацию: ID - идентификатор пакета, RN- идентификатор повторной ретрансляции пакета, SN - порядковые номера пакетов, SNg - глобальный порядковый номер (используется для идентификации номера узла-источника), VQP - параметр для назначения приоритета [111], T-S - добавленная метка времени для определения задержки при передаче на уровне приложений. После генерации заголовка и метки времени приложение добавляет полезную нагрузку данных к пакету и сохраняет в буфере воспроизведения, а затем отправляет его на узел-получатель.

На рисунке 3.6 показан фрагмент кода MS-AL-ARQ на узле-получателе для работы с раздельными входными буферами. Когда данные приходят в сокет UDP, происходит проверка: являются ли они видеоданными, которые можно различить с помощью первого байта данных (идентификатор пакета). Полученный фрагмент данных может быть запрошенным потерянным фрагментом. В этом случае приложение получает значение метки времени из заголовка и вычитает его из текущего значения времени часов (в микросекундах). Также приложение проверяет, есть ли

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

Begin

Initialize bufferjn [], buffer out [], buffer in [ ] ~ receive data (UDP socket); bytes in = buffer in[ ].length; While (bytes in > 0) { Id = bufferjn [0]; If (Id= ID ARQ VIDEO | Id= ID ARQ VIDEO R) { Get_current_time(); Get timestamp from packet header; Pckt_delay = current_time - timestamp; If (SN_packet exist in buffer) {

delete packet; } Else Copy packet to display buffer;

Write packet in log-file for statistics

}

Рисунок 3.6 - Фрагмент кода для реализации алгоритмаMS-AL-ARQ на узле-получателе

Размер пакета при активном алгоритме MS-AL-ARQ был равен 1387 байт. Помимо этого, при работе алгоритма появлялось 2 типа служебных пакетов: первый тип - пакеты NACK, которые узел-получатель отправляет в случае потери полезных данных; второй тип - пакеты, которые отправляет узел-источник, если запрашиваемого NACK пакета нет в буфере. Пакет NACK имеет размер 51 байт, в свою очередь, отрицательные ответы на NACK занимают 49 байт.

В предложенном алгоритме, чтобы определить факт потери фрагментов, используются номера SN из заголовка протокола RTP. Так как эти номера идут в строгой последовательности друг за другом, по их отсутствию в этой последовательности можно вычислить количество последовательно потерянных фрагментов -¡в88_Ь. Данный расчет усложняет то, что номер текущего принятого фрагмента -сиг - может оказаться меньше номера предыдущего фрагментаргву, а также то, что БЫ ограничен максимальным значением 65535 (под поле БЫ в заголовке RTP отводится 2 байта). Случаи нарушения последовательности приема фрагментов относятся к потерянным фрагментам. При этом необходимо выделять ситуацию сброса номера последовательности, в этом случае количество последовательно потерянных фрагментов считается как ¡в88_Ь = сиг + 65535 - ргву.

Для измерения задержки при передаче требовалась синхронизация часов между всеми узлами самоорганизующейся сети. Была выбрана синхронизация времени по протоколу ЫТР [112]. На рисунке 3.7 представлена блок-схема расчёта задержек в реальном времени, которая учитывает потерянные пакеты [113].

Ое1а\ ¡п^-Ое1ау_сигг .ЛКег = Эе1ау шК - ЭНаусигг

Рисунок 3.7 - Блок-схема расчета задержки на уровне приложений

Измерение определяется двумя типами расчета задержки: если полученный пакет является первым пакетом в потоке, то задержка (Delayinit) рассчитывается и сохраняется. Если нет, то будет выполнена проверка, чтобы убедиться, что пакет находится в последовательности. Если пакет не в последовательности, то он будет помечен как первый пакет в потоке.

3.3 Компьютерное моделирование работы алгоритма NC-F

Для имитационного моделирования COPE-подобного сетевого кодирования в NS-3 может использоваться имитационная модель [106,107], которая была реализована в модулях yanci [108] и оценена в [109]. Однако при проведении имитационном моделировании не предоставляется возможность тестирования разработанных программ для микрокомпьютеров, такую возможность может обеспечить лишь проведение эмуляции. Поэтому для оценки эффективности работы алгоритма NC-F на основе COPE-подобного сетевого кодирования была выбрана эмуляция процесса передачи данных с нескольких оконечных узлов через узел-ретранслятор.

Эмуляция работы алгоритма NC-F

Было рассмотрено несколько сценариев представленных на рисунке 3.8. В первом сценарии оконечный узел А передавал потоковые видеоданные оконечному узлу B через зависший в воздухе узел-ретранслятор C, расстояние между узлом A и В было установлено в D = 100 метров. При эмуляции первого сценария изменялась скорость передачи потоковых видеоданных 1,25 Мбит/с, 2 Мбит/c и 5 Мбит/с. Во втором сценарии узел-ретранслятор двигался по кругу с радиусом r = D/4 со скоростью 35 м/с с центром вращения в точке D/2 и имитировал БПЛА самолетного типа, при этом расстояние D между оконечными узлами A и B увеличивалось от 50 до 120 метров с шагом в 5 метров в каждый цикл эмуляции. Все узлы эмулируемой сети были реализованы как виртуальные машины с ОС Ubuntu 16.04 (Linux), а также с предустановленными пакетами реализации протокола маршрутизации

В.А.Т.М.А.М Лёу и алгоритма ЫС-Е. Представленные сценарии моделировали разворачивания сети с труднодоступным районом в режиме ЧС [110].

а)

б)

Рисунок 3.8 - Эмулируемый сценарий передачи данных между двумя оконечными узлами а) через зависший в воздухе узел-ретранслятор б) через мобильный узел-ретранслятор

Для передачи видео использовалась программа §в1хеатег, в каждый шаг эмуляции длительность транслируемого видео устанавливалось в 60 секунд. Как было описано ранее канал связи был смоделирован через Ш-3, использовался стандарт 802.11ас, при этом на канальном уровне был отключен механизм запросов повторной передачи.

Была оценена эффективность предложенного алгоритма NC-F для первого сценария с зависшим в воздухе узлом-ретранслятором при разных значениях скорости передачи на PDR. В разделе 2.1 был описан выигрыш от кодирования, который вычисляется как отношения количества передач без применение сетевого кодирования к числу передач с применением сетевого кодирования. В нашем случае значение выигрыша по полезной нагрузке уровня приложений рассчитывалось как отношение переданных пакетов без применения NC-F к числу переданных пакетов с применением алгоритма NC-F:

С = —, (3.1)

^МС-Р

где

G - выигрыш от применения алгоритма NC-F;

R - количество переданных пакетов без использования алгоритма NC-F;

- количество переданных пакетов с использованием алгоритма NC-F.

На рисунке 3.9 представлены результаты эмуляции работы алгоритма муль-типотоковой передачи видеоданных от двух оконечных узлов на основе СОРЕ-подобного сетевого кодирования NC-F в виде зависимости PDR от скорости передачи данных.

Из графиков зависимости PDR от скорости передачи данных при проведении эмуляции для сценария с зависшим в воздухе узлом-ретранслятором в виде БПЛА следует, что значения PDR без применения алгоритма NC-F на основе СОРЕ-подобного сетевого кодирования и с применением алгоритма NC-F при скорости передачи данных 1,25 Мбит/с равны 1, что свидетельствует о доставке всех пакетов между оконечными узлами. При увеличении скорости передачи данных до 2 Мбит/с значение PDR без алгоритма NC-F равняется 0,9736, а с применением алгоритма NC-F значение PDR принимает значение 0,9868. При дальнейшем увеличении скорости передачи до 5 Мбит/с значение PDR без алгоритма NC-F равняется 0,4037, а с применением алгоритма NC-F значение PDR принимает значение 0,1746. Уменьшение значения PDR при увеличении скорости передачи данных до 5 Мбит/с связано с увеличением времени на процесс нахождения соответствующих

пакетов в буферах (что было описано в разделе 2.2), вследствие чего пакеты начинают отбрасываться.

1,25 2 5

Скорость передачи, Мбит/с

Рисунок 3.9 - Зависимость РОЯ от скорости передачи данных при проведении эмуляции для сценария с зависшим в воздухе узлом-ретранслятором

На рисунке 3.10 представлен выигрыш от применения алгоритма ЫС-Р, рассчитанный по формуле (3.1) на основе измерений по результатам эмуляции.

Результаты, представленные на рисунке 3.10, были получены на основе подсчета отношения числа отправленных пакетов без применения алгоритма ЫС-Р к числу пакетов с применением алгоритма ЫС-Р. Так, при скорости передачи данных в 1,25 Мбит/с число переданных пакетов в среднем без ЫС-Р равнялось 7683, а при использовании ЫС-Р - 5026 при скорости передачи данных 2 Мбит/с число переданных пакетов в среднем без ЫС-Р равнялось 11603, при использовании ЫС-Р -7639 при увеличении скорости до 5 Мбит/с число переданных пакетов в среднем без ЫС-Р равнялось 12027, при использовании ЫС-Р -9635. По итогу средний выигрыш от применения алгоритма ЫС-Р принимал сле-

дующие значения: при скорости передачи 1,25 Мбит/ с - 1,529, при скорости передачи 2 Мбит/с - 1,519, при скорости передачи 5 Мбит/с - 1,248. Очевидно, что чем выше выигрыш от применения предложенного алгоритма ЫС-Г, тем меньше полезная нагрузка прикладного уровня. Из графика на рисунке 3.10 следует, что применение алгоритма ЫС-Г способно уменьшить полезную нагрузку уровня приложений до 50 %.

1,6

о. и В

т 1,1

1,25 2 5

Скорость передачи, Мбит/с

Рисунок 3.10 - Выигрыш по полезной нагрузке уровня приложений от применения алгоритма ЫС-Г при разной скорости передачи данных для сценария с зависшим в воздухе

узлом-ретранслятором

Также был рассмотрен второй сценарий, в котором два оконечных узла удалялись на расстояние В друг от друга от 50 до 120 метров с шагом 5 метров, при этом узел-ретранслятор С двигался по кругу со скоростью 35 м/с, центр движения находился в точке В/2, а радиус движения была равен В/4 (рисунок 3.86).

Как и в предыдущем случае, видеоданные передавалась одновременно от узла А к узлу В и обратно, при этом скорость передачи данных равнялась 1,25

Мбит/с. Метрики РОЯ и О измерялись в зависимости от расстояния О, поскольку потери при передаче варьировались в широком диапазоне в виду мобильности узла-ретранслятора, было необходимо измерить выигрыш относительно количества доставленных пакетов (или относительно РОЯ) Срик:

Срои =

Б _ РИКмс-р

Бмс-Р РОИ

(3.2)

где

СРПК - выигрыш от применения алгоритма ЫС-Р относительно количества доставленных пакетов;

РОЯ - коэффициент доставки пакетов без применения алгоритма ЫС-Р; РОЯмс-Е - коэффициент доставки пакетов при применении алгоритма ЫС-Р.

На рисунке 3.11 представлены результаты эмуляции передачи данных между двумя оконечными узлами через мобильный узел-ретранслятор С (рисунок 3.11) в виде зависимости РОЯ от расстояния О между узлами как с использованием предложенного алгоритма ЫС-Р, так и без его использования.

Рисунок 3.11 - Зависимость РОЯ от расстояния О между оконечными узлами для сценария

с мобильным узлом-ретранслятором

Результаты эмуляции показывают, что по мере роста расстояния D между узлами качество передачи данных снижается. В частности, узлы A и В находятся в пределах прямой видимости на расстоянии D = 60 метров, поэтому узел-ретранслятор C не используется для передачи. При этом значение PDR в среднем без применения алгоритма NC-F равняется 0,9983, а с применением алгоритма NC-F значение PDR равно 0,9996. Дальнейшее увеличение расстояния между двумя оконечными узлами D приводит к уменьшению значения PDR, также в точке 70 метров наблюдается снижение PDR для обоих случаев, что связано с переключением на протокол маршрутизации B.A.T.M.A.N. Adv. Можно наблюдать, что значение PDR при работе алгоритма NC-F ниже, чем без алгоритма, в среднем PDR уменьшается на 9,5% с использованием алгоритма NC-F. Это можно объяснить тем, что протокол маршрутизации B.A.T.M.A.N. Adv совместно с работой алгоритма NC-F использует длинные буферы для хранения пакетов, при этом поиск в буфере занимает относительно много времени, поэтому качество передачи становится хуже в условиях мобильности.

На рисунке 3.12 представлен выигрыш относительно количества доставленных пакетов для сценария с мобильным узлом-ретранслятором С, рассчитанный по формуле (3.2) на основе измерений по результатам эмуляции.

Как следует из графика, представленного на рисунке 3.12, при расстоянии 75 метров наблюдается самое большое значение выигрыша - 1,7, значения PDR были представлены выше, средние значения количества отправленных пакетов без применения алгоритма NC-F - 11195, количество отправленных пакетов с применением алгоритма NC-F - 6121. Из рисунка 3.12 следует, что выигрыш от применения алгоритма NC-F сохраняется для сети с мобильным узлом-ретранслятором и полезная нагрузка уровня приложений может снижаться на 5-70 % в зависимости от расстояния с использованием алгоритма NC-F. При этом общее ухудшение выигрыша и PDR связано с увеличением расстояния между узлами, а также с увеличением задержки, что в свою очередь объясняется работой на поиск нужного пакета в буфере при функционировании алгоритма NC-F совместно с протоколом маршрутизации B.A.T.M.A.N. Adv.

Рисунок 3.12 - Зависимость выигрыша от применения алгоритма ЫС-Е относительно числа доставленных пакетов от расстояния между оконечными узлами для сценария

с мобильным узлом-ретранслятором

По результатам эмуляции можно сделать вывод, что алгоритм на основе СОРЕ-подобного сетевого кодирования ЫС-Е может найти применение в реальных экспериментах при наличии узла-ретранслятора. Метод и алгоритм позволяют снизить полезную нагрузку уровня приложений. Также было показано, что алгоритм может применяться как в сценарии с зависшим в воздухе БПЛА, так и с мобильным летающим узлом. Уменьшение РОЯ и выигрыша в обоих сценариях связаны с увеличением расстояния между узлами, а также с задержками, которые вызваны работой на поиски пакетов в буферах на узлах.

3.4 Эмуляция совместной работы алгоритмов MS-AL-ARQ и МС-Е

Сценарий для проведения эмуляции

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

уровня приложений (Goodput), но значения PDR без применения алгоритма выше, чем с его применением, что связано с длительным временем работы с буфером. Для увеличения количества успешно доставленных пакетов совместно с алгоритмом NC-F на основе COPE-подобного сетевого кодирования предлагается использование алгоритма MS-AL-ARQ прикладного уровня, программная реализация которого описана в разделе 3.2.

Для исследования эффективности совместной работы нескольких алгоритмов (MS-AL-ARQ и NC-F) была проведена эмуляция процесса передачи потоковых видеоданных между двумя оконечными узлами через узел-ретранслятор в самоорганизующейся сети. Оконечный узел А передавал видеопоток HD на другой оконечный узел B через узел-ретранслятор С, используя стандарт 802.11n, при этом узел В также отправлял видео на узел A через тот же узел-ретранслятор С. Было рассмотрено два сценария: со статическим узлом-ретранслятором (как на рисунке 3.8а) и с мобильным узлом-ретранслятором (как на рисунке 3.86). В сценарии с мобильным узлом-ретранслятором узел-ретранслятор двигался по кругу со скоростью 50 м/с и радиусом r = 50 метров с центром вращения в точке D/2, при этом на всех узлах была установлена виртуальная машина с операционной системой Ubuntu Mate 16.04. На каждой виртуальной машине был установлен протокол маршрутизации B.A.T.M.A.N. Adv, в котором была включена опция кодирования через команду «CONFIG_BATMAN_ADV_NC = у», также была подключена программная реализация алгоритма NC-F. Потоковое видео передавалось со встроенной HD-камеры ноутбука с использованием программного обеспечения gstreamer на основе стека протоколов H.264 / UDP / BATMAN & COPE / 802.11n. Стандарт 802.11n и среда передачи эмулировались в NS-3 с помощью виртуального интерфейса TAP в виртуальных машинах. Результаты эмуляции процесса передачи видеоданных между двумя оконечными узлами были измерены для различных протоколов и параметров канала, длительность трансляции видео равнялась одному часу.

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

3.2. Для расчета PLR между оконечными узлами использовалось поле - SN, которое определяет текущий и предыдущий SN, кроме того, на оконечных узлах задано значение интервала измерения по умолчанию в 1000 пакетов. Один оконечный узел передает пакеты другому, в строгом порядке по их SN, исходные пакеты отмечены в буфере нулевым значением в поле retransmission number (RN). Оконечный узел при получении данных подсчитывает входящие исходные пакеты по SN, на основе чего он может обнаружить потерянные пакеты. Если оконечный узел при передаче данных повторно отправляет пакет как ответ на входящий NACK, он использует ненулевое поле RN для указания номера повторной передачи. Оконечный узел, получающий данные, хранит вновь поступившие пакеты (упорядоченные SN) в буфере, а также упорядочивает потерянные пакеты по группам и использует эти группы для формирования NACK для оконечного узла. PLR рассчитывается для пакетов, отправленных из буфера оконечного узла-получателя в gstreamer. Таким образом, каждый узел-получатель может измерить PLR после восстановления пакета и дать представление об эффективности применения алгоритма MS-AL-ARQ. Разница между текущим и предыдущим SN определяет потери пакетов, пакет вне последовательности рассматривается как потерянный пакет.

Во всех циклах эмуляции значения PLR измерялись для каждых 1000 переданных пакетов на основе порядковых номеров, как было описано выше. Средние значения PLR были рассчитаны, чтобы найти зависимости между потерей пакетов и расстояниями между узлами в рассматриваемых сценариях передачи данных с двух оконечных узлов. Сквозная задержка передачи видео зависела от параметров MS-AL-ARQ, в алгоритме размер буфера определяет максимальную задержку прикладного уровня для передачи видео. Было рассмотрено временное значение, определяющее максимальное время хранения пакетов данных в буфере - buf, в диапазоне от 0,5 до 3 секунд для буфера на узлах. Алгоритм мультипотоковой передачи видеоданных от нескольких оконечных узлов на основе COPE-подобного сетевого кодирования NC-F также отрицательно влиял на сквозную за-

держку из-за трудоемкого процесса сложения пакетов по модулю два на узле-ретрансляторе. MS-AL-ARQ вычислял текущее значение RTT, описанное в разделе 2.3, между двумя оконечным узлами во время передачи (значение по умолчанию составляло 0,05 секунд).

Пропускная способность рассматриваемой системы была ограничена технологией физического уровня, рассматривался стандарт 802.11n со схемами кодирования (MCS) 1 и 2, где схемы кодирования MCS1 и MCS2 используют модуляцию QPSK и дают пропускную способность 13 Мбит/с и 19,5 Мбит/с (без MIMO) соответственно.

Алгоритм мультипотоковой передачи видеоданных от нескольких оконечных узлов на основе сетевого кодирования NC-F складывает пакеты по модулю два из двух видеопотоков на узле-ретрансляторе. Во время эмуляции узел-ретранслятор имеет возможность транслировать один широковещательный пакет вместо двух одноадресных пакетов. Было измерено число N сложенных пакетов на узле-ретрансляторе С и доля F(%) сложенных данных во всех пакетах на узле-ретрансляторе во время эмуляции. Эти метрики демонстрируют зависимость показателей эффективности алгоритмов от расстояния D между узлами и размерами буфера в MS-AL-ARQ.

Результаты эмуляции совместной работы алгоритмов MS-AL-ARQ и NC-F На основе рассмотренного ранее сценария была проведена эмуляция процесса передачи данных при совместной работе алгоритма NC-F на сетевом уровне и алгоритма MS-AL-ARQ на уровне приложений. По результатам эмуляции было рассчитано три показателя: PLR, количество кодированных (сложение по модулю 2) пакетов N на узле-ретрансляторе С и доля кодированных фрагментов данных во всех пакетах F(%) на узле-ретрансляторе С. Результаты эмуляции представлены на рисунке 3.13 в виде зависимости метрики PLR от расстояния D между оконечными узлами в сценарии с зависшим в воздухе узлом-ретранслятором. При этом HD-ви-део передавалось с использованием схемы кодирования MCS2 в течение 1 часа эмуляции между оконечными узлами на расстояниях 300, 400 и 500 метров.

Зависимости значений РЬЯ от расстояния между оконечными узлами представлены на рисунке 3.13.

Рисунок 3.13 - Зависимость РЬЯ от расстояния между двумя оконечными узлами

(720р, МСБ2, Ъп/ = 0,5 секунд)

Из результатов эмуляции, представленных на рисунке 3.13, следует, что совместное применение двух алгоритмов NC-F на сетевом уровне и MS-AL-ARQ на уровне приложений дает видимое преимущество. Так, самое большое значение PLR при их совместном использовании равно 0,007 на расстоянии D = 500 метров (на расстояниях 300 и 400 метров значение PLR = 0). При использовании только алгоритма NC-F на основе COPE-подобного сетевого кодирования на расстоянии D = 500 метров PLR = 0,074, на расстоянии D = 400 метров PLR = 0,029, а на расстоянии D = 300 метров PLR = 0,030. Снижение PLR связано с восстановлением потерянных пакетов за счет применения алгоритма MS-AL-ARQ, при этом большее число повторно переданных пакетов предоставляет дополнительные возможности алгоритму NC-F для сложения пакетов на летающем узле-ретрансляторе.

Также по результатам эмуляции было подсчитано общее количество кодированных пакетов Ы на зависшем в воздухе узле-ретрансляторе (рисунок 3.14).

60000 50000 40000 ^ 30000 20000 10000 0

Рисунок 3.14 - Общее количество Ы кодированных пакетов на зависшем в воздухе узле-ретрансляторе для различных расстояний между оконечными узлами

(720р, MCS2, Ьы/ = 0,5 секунд)

Из графиков, представленных на рисунке 3.14 следует, что при увеличении расстояния между оконечными узлами увеличивается число кодированных пакетов на зависшем в воздухе узле-ретрансляторе. Это объясняется тем, что при увеличении расстояния между узлами увеличивается число потерянных пакетов, что приводит в действие алгоритм MS-AL-ARQ, который отправляет NACK-и при обнаружении потерянных пакетов, таким образом возрастает общее число отправленных пакетов, что предоставляет возможность для работы алгоритма ЫС-Е.

Также была построена зависимость доли кодированных данных Е(%) на зависшем в воздухе узле-ретрансляторе для расстояния между узлами О = 500

300 400 500

Д метров

метров при разных значениях временного буфера на узле-ретрансляторе от 0,5 секунд до 3 секунд (рисунок 3.15).

4,9 4.8 4,7 4,6 4,5 ^ 4,4 4,3 4,2 4,1 4 3.9

0,5 1 2 Ьи'/', секунд 3

Рисунок 3.15 - Доля кодированных данных Г(%) на стационарном узле-ретрансляторе для расстояния между узлами В = 500 метров (720р, MCS2)

Из зависимостей на рисунке 3.15 следует, что значение доли кодированных данных Г(%) на зависшем в воздухе узле-ретрансляторе при расстоянии В = 500 метров при временном буфере 0,5 секунд равно 4,3 % (при этом число кодированных пакетов 55548), при временном буфере 1 секунда равно 4,4 % (при этом число кодированных пакетов 57715), при временном буфере 2 секунды Г(%) равно 4,8 % (при этом число кодированных пакетов 75715), при временном буфере 3 секунды Г(%) равно 4,2 % (при этом число кодированных пакетов 54295). Следует, что значение временного буфера в 2 секунды может дать наибольшую возможность для кодирования пакетов на сетевом уровне при работе ЫС-Г.

На основе вышеизложенного для кодирования большего числа потерянных пакетов временной буфер был увеличен и равнялся 2 секундам на всех узлах в самоорганизующейся сети. Были проведены замеры для установления зависимости между количеством кодированных пакетов N при включенном (в1ге = 7) и выключенном ARQ (в1ге = 1) канального уровня (рисунок 3.16).

|Из1гс1 ■ з1гс7

500

Рисунок 3.16 - Общее количество N кодированных пакетов на зависшем в воздухе узле-ретрансляторе в сценариях с включенным ^1гс = 7) и отключенным ^1гс = 1) ARQ канального уровня (720р, MCS2, Ъп/ = 2 секунды)

Из графиков на рисунке 3.16 следует, что при работающем ARQ канального уровня удается кодировать большее число пакетов: при расстоянии О = 500 метров N = 75715 при б1гс = 7 и N = 32843 при б1гс = 1; при расстоянии О = 400 метров N = 30689 при б1гс = 7 и N = 23934 при б1гс = 1; при расстоянии О = 300 метров N = 32749 при б1гс = 7 и N = 24635 при б1гс = 1. Результат является

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

Помимо сценария с зависшим в воздухе узлом-ретранслятором в виде БПЛА был эмулирован сценарий с мобильным узлом-ретранслятором С, который двигался по кругу, с центром в точке D/2. На графиках рисунка 3.17 представлены результаты эмуляции в виде зависимости PLR от расстояния D для случая с работой алгоритма NC-F и для варианта совместной работы двух алгоритмов - NC-F и MS-AL-ARQ.

0,25 0,2 0,15

OS С О,

0,1 0,05 0

Рисунок 3.17 - Зависимость PLR от расстояния D в сценарии с мобильным узлом-ретранслятором (720p, MCS2, buf = 1 секунда)

Из графиков на рисунке 3.17 следует, что совместное использование двух алгоритмов уменьшает значение PLR. Так, на расстоянии D = 400 метров PLR равен 0 при использовании двух алгоритмов и PLR = 0,032 при использовании

алгоритма ЫС-Г; на расстоянии В = 500 метров РЬЯ равен 0,159, при использовании двух алгоритмов РЬЯ = 0,196. Также, как и в случае с зависшим в воздухе узлом-ретранслятором снижение значения РЬЯ связано с восстановлением потерянных пакетов за счет применения алгоритма MS-AЬ-AЯQ, а также с увеличением значения Ьы/ до 1 секунды.

Также была построена временная зависимость мгновенных значений РЬЯ при В = 400 метров. Мгновенные значения РЬЯ измерялись для каждой 1000 пакетов (рисунок 3.18).

Рисунок 3.18 - Мгновенные значения РЬЯ на оконечном узле А в сценарии с мобильным узлом-ретранслятором для В = 400 метров (720р, MCS2, Ьы/ = 1 секунда)